Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp330417pxa; Wed, 26 Aug 2020 11:48:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxeCfIADIDt+4zw9AvLeBUl6kHC1ZRQo5qqis+f67dgYuLS6c+wg4xJyY+ZuMOHRt9nBfKd X-Received: by 2002:a17:906:a0c2:: with SMTP id bh2mr1075276ejb.493.1598467692634; Wed, 26 Aug 2020 11:48:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598467692; cv=none; d=google.com; s=arc-20160816; b=t5VY6KddmIrlIfI1dQAQGviZ5McPTe0yXzDKxWyqoiSOaMv94UvkPPKtMhcFDS9dOE S6JiehSPUrYOlYq61nnViyb1GSpyvnPkAmiOZV7hWAs9CgnqOmpKO5NR4C7ujn7sqa24 5BJkE6rKkZiKVG/6AgMXs85Mr1gKKu0sxcjIoDIcC70e2QZVRVgarPBiXxeQelmUUMnT Ly5XZQU8hOqaVVNHTnBl21T1A6QEyV/eQ2xeBSuHmAuWu/PuqmnpO1MmHCvO4WFWQY4J pYKzRouf8li1a6N/xQRY7a/ODzAuO4lnM7zhopi1YD7aPTS96FYX4T/CM2Ypnb0RctQY AJ9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=YltNAJgIG0VwSE/4E8W4XDB0plNLiHDFeoZYECss5I8=; b=bCkAQcn2BjYsg11S4iG8lkTwxoyYNJqjDHi0lS1qguWZ/VxApJEm3l0wAQ6DC2NFqp 7fdb4YdB5dRWkIiTEad7aFqEjNis/F6UEkmsx14Kzcb0TC2LI8QcSYVw2gYLpuUdYJHM qvzOzbs60rcVIcyM15HvDvDUjfG+rk0kf6M6RmVkRlSheIaMcp+r924+1Lqdea6Kr7ks fAujkk7rrqnTbYGk3S95kwwX73bf8zS6CzSi5ocalefarqq/WsWTpuvzKD2db8ndWvCI Qv/WJpC9jCcgk5f+DCLx1hZq9P7DU3ubVhRK8ajy14CeJMPiMp97Hg4aGGkV8iF+aCWE wCnA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e15si2178976eja.467.2020.08.26.11.47.49; Wed, 26 Aug 2020 11:48:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726995AbgHZSrH (ORCPT + 99 others); Wed, 26 Aug 2020 14:47:07 -0400 Received: from asavdk3.altibox.net ([109.247.116.14]:47328 "EHLO asavdk3.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726802AbgHZSrF (ORCPT ); Wed, 26 Aug 2020 14:47:05 -0400 Received: from ravnborg.org (unknown [188.228.123.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by asavdk3.altibox.net (Postfix) with ESMTPS id 3C3DF200CE; Wed, 26 Aug 2020 20:46:58 +0200 (CEST) Date: Wed, 26 Aug 2020 20:46:57 +0200 From: Sam Ravnborg To: Enric Balletbo i Serra Cc: linux-kernel@vger.kernel.org, Collabora Kernel ML , matthias.bgg@gmail.com, drinkcat@chromium.org, hsinyi@chromium.org, laurent.pinchart@ideasonboard.com, Andrzej Hajda , Daniel Vetter , David Airlie , Jernej Skrabec , Jonas Karlman , Neil Armstrong , dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 5/5] drm/bridge: ps8640: Rework power state handling Message-ID: <20200826184657.GA419312@ravnborg.org> References: <20200826081526.674866-1-enric.balletbo@collabora.com> <20200826081526.674866-6-enric.balletbo@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200826081526.674866-6-enric.balletbo@collabora.com> X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=CaYmGojl c=1 sm=1 tr=0 a=S6zTFyMACwkrwXSdXUNehg==:117 a=S6zTFyMACwkrwXSdXUNehg==:17 a=kj9zAlcOel0A:10 a=QX4gbG5DAAAA:8 a=s0PHMXKsYlyJJz0d3o0A:9 a=CjuIK1q_8ugA:10 a=AbAUZ8qAyYyZVLSsDulk:22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Enric. On Wed, Aug 26, 2020 at 10:15:26AM +0200, Enric Balletbo i Serra wrote: > The get_edid() callback can be triggered anytime by an ioctl, i.e > > drm_mode_getconnector (ioctl) > -> drm_helper_probe_single_connector_modes > -> drm_bridge_connector_get_modes > -> ps8640_bridge_get_edid > > Actually if the bridge pre_enable() function was not called before > get_edid(), the driver will not be able to get the EDID properly and > display will not work until a second get_edid() call is issued and if > pre_enable() is called before. The side effect of this, for example, is > that you see anything when `Frecon` starts, neither the splash screen, > until the graphical session manager starts. > > To fix this we need to make sure that all we need is enabled before > reading the EDID. This means the following: > > 1. If get_edid() is called before having the device powered we need to > power on the device. In such case, the driver will power off again the > device. > > 2. If get_edid() is called after having the device powered, all should > just work. We added a powered flag in order to avoid recurrent calls > to ps8640_bridge_poweron() and unneeded delays. > > 3. This seems to be specific for this device, but we need to make sure > the panel is powered on before do a power on cycle on this device. > Otherwise the device fails to retrieve the EDID. > > Signed-off-by: Enric Balletbo i Serra > --- > > Changes in v2: > - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg) > > drivers/gpu/drm/bridge/parade-ps8640.c | 64 +++++++++++++++++++++++--- > 1 file changed, 58 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c > index 9f7b7a9c53c5..c5d76e209bda 100644 > --- a/drivers/gpu/drm/bridge/parade-ps8640.c > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > @@ -65,6 +65,7 @@ struct ps8640 { > struct regulator_bulk_data supplies[2]; > struct gpio_desc *gpio_reset; > struct gpio_desc *gpio_powerdown; > + bool powered; > }; > > static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e) > @@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct ps8640 *ps_bridge, > return 0; > } > > -static void ps8640_pre_enable(struct drm_bridge *bridge) > +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge) > { > - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge); > struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL]; > unsigned long timeout; > int ret, status; > > + if (ps_bridge->powered) > + return; > + > ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies), > ps_bridge->supplies); > if (ret < 0) { > @@ -164,6 +167,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge) > goto err_regulators_disable; > } > > + ps_bridge->powered = true; > + > return; > > err_regulators_disable: > @@ -171,12 +176,12 @@ static void ps8640_pre_enable(struct drm_bridge *bridge) > ps_bridge->supplies); > } > > -static void ps8640_post_disable(struct drm_bridge *bridge) > +static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge) > { > - struct ps8640 *ps_bridge = bridge_to_ps8640(bridge); > int ret; > > - ps8640_bridge_vdo_control(ps_bridge, DISABLE); > + if (!ps_bridge->powered) > + return; > > gpiod_set_value(ps_bridge->gpio_reset, 1); > gpiod_set_value(ps_bridge->gpio_powerdown, 1); > @@ -184,6 +189,28 @@ static void ps8640_post_disable(struct drm_bridge *bridge) > ps_bridge->supplies); > if (ret < 0) > DRM_ERROR("cannot disable regulators %d\n", ret); > + > + ps_bridge->powered = false; > +} > + > +static void ps8640_pre_enable(struct drm_bridge *bridge) > +{ > + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge); > + int ret; > + > + ps8640_bridge_poweron(ps_bridge); > + > + ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE); > + if (ret < 0) > + ps8640_bridge_poweroff(ps_bridge); > +} The impleimentation of ps8640_bridge_poweron() versus ps8640_bridge_poweroff() is confusing. ps8640_bridge_poweron() includes ps8640_bridge_vdo_control(.., ENABLE), but ps8640_bridge_poweroff() does not include ps8640_bridge_vdo_control(..., DISABLE). This is inconsistent and confusing. At least it was for me when reviewing. Can this be improved - or maybe just use naming that does not indicate they are the reverse of each other? > + > +static void ps8640_post_disable(struct drm_bridge *bridge) > +{ > + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge); > + > + ps8640_bridge_vdo_control(ps_bridge, DISABLE); > + ps8640_bridge_poweroff(ps_bridge); > } > > static int ps8640_bridge_attach(struct drm_bridge *bridge, > @@ -249,9 +276,34 @@ static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge, > struct drm_connector *connector) > { > struct ps8640 *ps_bridge = bridge_to_ps8640(bridge); > + bool poweroff = !ps_bridge->powered; > + struct edid *edid; > + > + /* > + * When we end calling get_edid() triggered by an ioctl, i.e > + * > + * drm_mode_getconnector (ioctl) > + * -> drm_helper_probe_single_connector_modes > + * -> drm_bridge_connector_get_modes > + * -> ps8640_bridge_get_edid > + * > + * We need to make sure that what we need is enabled before reading > + * EDID, for this chip, we need to do a full poweron, otherwise it will > + * fail. > + */ > + drm_bridge_chain_pre_enable(bridge); > > - return drm_get_edid(connector, > + edid = drm_get_edid(connector, > ps_bridge->page[PAGE0_DP_CNTL]->adapter); > + > + /* > + * If we call the get_edid() function without having enabled the chip > + * before, return the chip to its original power state. > + */ > + if (poweroff) > + drm_bridge_chain_post_disable(bridge); > + > + return edid; > } The use of drm_bridge_chain_pre_enable() and drm_bridge_chain_post_disable() was exactly what I was asking for - looks good. I have not really considered the idea from Balil that we should provide better infrastructure support powering on the bridge chain when reading the edid. Maybe an idea for later? Sam > > static const struct drm_bridge_funcs ps8640_bridge_funcs = { > -- > 2.28.0