Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4141949ybi; Mon, 29 Jul 2019 20:10:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqyDazyjO/0qMUSsR31siSLY+0n0fL3gh3xmhQ6IPR/49KzFROryg747jx4opgVhCcMf2ut6 X-Received: by 2002:a17:90b:95:: with SMTP id bb21mr116340485pjb.8.1564456221818; Mon, 29 Jul 2019 20:10:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564456221; cv=none; d=google.com; s=arc-20160816; b=TimsPfztzw4WGS97RUpv5fQqxHRMXwujQS/qEyyBn5j0EP2gQ6TAP/qIKM3tLH+Su4 TAhDGEax0EwySlgPEi5DkFcfTz2Cd2TBPw7hXpyDsL+EENSZqtKVC8TYEQ1TTgnrNsuv DLP7r6Zn+goX1zgfLodTGkiVFGoGRPGuVa/DZfpLmsNCwKGTOkZeL63+iH7uBvorvyUp ZW+aVVyZdajXXSQygkx5DTw2qxpA8xvjlHNO71Qzg0bhk0KTHDBI2xU4FQJYkzLy6pBa YmYufrV7IysQUnr6Kt/OYb0uiihvxHLfRWqHqmDH0fr8c4AO14Wl2zoZ55sqvc/0b+ip 2ptQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=hWkU2/nir7ZQfvW4i66MunEPrc2ksPHZ+kI417Vwor0=; b=b0RvuYZZAiAA0qU2agyQ4WjCn/CX4Ck8K9G6X7ea1iwEXQiC9s8sl0lz4500ZXHguk mdYTPirJrc28CMGHyNTDpywR6YDLG1iHboH2944fcootn3wYnFwLzMEi8NMCsN9W7mdf KcJs5FuyCSkvfioOdYWhruEJ39bR8VYbDs2kvU1msfzzmJBIRh0tfhPByL/isMUkX52U 1kPvUEfioSxoyMtOhdtC8seh9QrBMHR6tv/5XLfAnrTcEna63txCX5pFiqjHNNyalp5K zZpLXgnj/fgiAWnOXRCxfXKOoTvI2sSZScFkdc1sqdFJmYM6rxHoFNYmmsoaq2amKaRG VwMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=YSpTPlMe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6si27886818pll.82.2019.07.29.20.10.07; Mon, 29 Jul 2019 20:10:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=YSpTPlMe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729058AbfG2WEG (ORCPT + 99 others); Mon, 29 Jul 2019 18:04:06 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:36310 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728667AbfG2WEG (ORCPT ); Mon, 29 Jul 2019 18:04:06 -0400 Received: by mail-oi1-f195.google.com with SMTP id q4so17262799oij.3 for ; Mon, 29 Jul 2019 15:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hWkU2/nir7ZQfvW4i66MunEPrc2ksPHZ+kI417Vwor0=; b=YSpTPlMeCYYov7BuvMIOVP4Mbjnyr+tyM3byOHdUesUddEkSMTdk3VN0J5EVFcO5AA 60elu2KlvLQ7lbDIJNkKFyLm/z9m97CbYD/J723A4PhsO4MTQiDYTKtSefUUNGurPUOQ Ol+MGNxjX5/jPtRV8JWa3rmBQ9b9icxpWWGsc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hWkU2/nir7ZQfvW4i66MunEPrc2ksPHZ+kI417Vwor0=; b=LozsS2q6u83LfNUozO9ZIdEbQkoE70pwBJvFcpg/sGNt3nC8/F/pZle44XnbEeeGrM b8ANQrFnTfoufGm91sHj+jHVi0qQj/tsKgK5gAi/DSr83mgMXbpkOcIFKpxvVXgYg9PP 74jOGNu9+Nck1vJi/f3hIW4OhVvQ1Gfnxt/6eYpS5n2ko+AlYqycbYlZMujLCfzuhyMh ZXKd0B9wZjaIGy3plMKeYWEBYW2V4PrfUlyJ30GGLmPPWe5YNnjMQufyUFyUyFVQVg5D qnddr54zNM46op2Hs65LfSNq9QkX1ovqHrpUi5vVhfeqQftxWHfenh27hoPh5nyVLRE3 g3NQ== X-Gm-Message-State: APjAAAW2FJJezSdRNZKGwn4lSXVNoTJ/e1oF1OX9yR+7O3zsB8/LdZLo LttIa95nClWN81OBJEo+Es1+QozstS5lCcIPUmU= X-Received: by 2002:a05:6808:118:: with SMTP id b24mr56856483oie.128.1564437844733; Mon, 29 Jul 2019 15:04:04 -0700 (PDT) MIME-Version: 1.0 References: <20190725110520.26848-1-oleksandr.suvorov@toradex.com> <20190725113237.d2dwxzientte4j3n@flea> In-Reply-To: From: Daniel Vetter Date: Tue, 30 Jul 2019 00:03:53 +0200 Message-ID: Subject: Re: [PATCH 0/1] This patch fixes connection detection for monitors w/o DDC. To: Oleksandr Suvorov Cc: "maxime.ripard@free-electrons.com" , Andrzej Hajda , Neil Armstrong , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Igor Opaniuk , "stable@vger.kernel.org" , Marcel Ziswiler , Jonas Karlman , David Airlie , Jernej Skrabec , Laurent Pinchart , Suvorov Alexander Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 29, 2019 at 12:58 PM Oleksandr Suvorov wrote: > > On Thu, Jul 25, 2019 at 5:41 PM maxime.ripard@free-electrons.com > wrote: > > > > On Thu, Jul 25, 2019 at 11:05:23AM +0000, Oleksandr Suvorov wrote: > > > > > > Even in source code of this driver there is an author's description: > > > /* > > > * Even if we have an I2C bus, we can't assume that the cable > > > * is disconnected if drm_probe_ddc fails. Some cables don't > > > * wire the DDC pins, or the I2C bus might not be working at > > > * all. > > > */ > > > > > > That's true. DDC and VGA channels are independent, and therefore > > > we cannot decide whether the monitor is connected or not, > > > depending on the information from the DDC. > > > > > > So the monitor should always be considered connected. > > > > Well, no. Like you said, we cannot decided whether is connected or > > not. > > Maxime, thanks, I agree that's a bad solution. > But I still think we should be able to define the DT node of a device for > this driver to claim the connector is always connected. > Please see my following thoughts. > > > > Thus there is no reason to use connector detect callback for this > > > driver: DRM sub-system considers monitor always connected if there > > > is no detect() callback registered with drm_connector_init(). > > > > > > How to reproduce the bug: > > > * setup: i.MX8QXP, LCDIF video module + gpu/drm/mxsfb driver, > > > adv712x VGA DAC + dumb-vga-dac driver, VGA-connector w/o DDC; > > > * try to use drivers chain mxsfb-drm + dumb-vga-dac; > > > * any DRM applications consider the monitor is not connected: > > > =========== > > > $ weston-start > > > $ cat /var/log/weston.log > > > ... > > > DRM: head 'VGA-1' found, connector 32 is disconnected. > > > ... > > > $ cat /sys/devices/platform/5a180000.lcdif/drm/card0/card0-VGA-1/status > > > unknown > > > > And that's exactly what's being reported here: we cannot decide if it > > is connected or not, so it's unknown. > > > > If weston chooses to ignore connectors that are in an unknown state, > > I'd say it's weston's problem, since it's much broader than this > > particular device. > > If we look at the code of drm_probe_helper.c, we can see, the > drm_helper_probe_detect_ctx() assume the cable is connected if there is no > detect() callback registered. > ... > if (funcs->detect_ctx) > ret = funcs->detect_ctx(connector, &ctx, force); > else if (connector->funcs->detect) > ret = connector->funcs->detect(connector, force); > else > ret = connector_status_connected; > ... > > The driver dumb-vga-dac supports both DT configurations: > - with DDC channel, that allows us to detect if the cable is connected; > - without DDC channel. In this case, IMHO, the driver should behave > the same way as a > connector driver without registered detect() callback. > > So what about the patch like? Still no. The "always connected" case is for outputs which are physically always connected and typing a dummy function which would unconditionally return connected would be silly. Like built-in panels. This is _not_ for external screens. -Daniel > > @@ -81,6 +81,13 @@ dumb_vga_connector_detect(struct drm_connector > *connector, bool force) > { > struct dumb_vga *vga = drm_connector_to_dumb_vga(connector); > > + /* > + * If I2C bus for DDC is not defined, asume that the cable > + * is always connected. > + */ > + if (PTR_ERR(vga->ddc) == -ENODEV) > + return connector_status_connected; > + > /* > * Even if we have an I2C bus, we can't assume that the cable > * is disconnected if drm_probe_ddc fails. Some cables don't > > -- > Best regards > Oleksandr Suvorov > > Toradex AG > Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500 > 4800 (main line) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch