From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> To: Douglas Anderson <dianders@chromium.org>, dri-devel@lists.freedesktop.org Cc: Hsin-Yi Wang <hsinyi@chromium.org>, Sankeerth Billakanti <quic_sbillaka@quicinc.com>, Philip Chen <philipchen@chromium.org>, Robert Foss <robert.foss@linaro.org>, Stephen Boyd <swboyd@chromium.org>, Abhinav Kumar <quic_abhinavk@quicinc.com>, Andrzej Hajda <andrzej.hajda@intel.com>, Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>, Jernej Skrabec <jernej.skrabec@gmail.com>, Jonas Karlman <jonas@kwiboo.se>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Neil Armstrong <narmstrong@baylibre.com>, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 4/4] drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux Date: Thu, 2 Jun 2022 17:56:13 +0300 [thread overview] Message-ID: <075b907c-fd12-2e91-199b-c43d27340ed2@linaro.org> (raw) In-Reply-To: <20220418101725.v3.4.Ie827321ce263be52fdb8c1276f6f8cc00d78029f@changeid> On 18/04/2022 20:17, Douglas Anderson wrote: > This implements the callback added by the patch ("drm/dp: Add > wait_hpd_asserted() callback to struct drm_dp_aux"). > > With this change and all the two "DP AUX Endpoint" drivers changed to > use wait_hpd_asserted(), we no longer need to have an long delay in > the AUX transfer function. It's up to the panel code to make sure that > the panel is powered now. If someone tried to call the aux transfer > function without making sure the panel is powered we'll just get a > normal transfer failure. > > We'll still keep the wait for HPD in the pre_enable() function. Though > it's probably not actually needed there, this driver is used in the > old mode (pre-DP AUX Endpoints) and it may be important for those > cases. If nothing else, it shouldn't cause any big problems. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Minor nit below > --- > > (no changes since v2) > > Changes in v2: > - Change is_hpd_asserted() to wait_hpd_asserted() > > drivers/gpu/drm/bridge/parade-ps8640.c | 34 ++++++++++++++++---------- > 1 file changed, 21 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c > index 9766cbbd62ad..2f19a8c89880 100644 > --- a/drivers/gpu/drm/bridge/parade-ps8640.c > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > @@ -168,23 +168,30 @@ static bool ps8640_of_panel_on_aux_bus(struct device *dev) > return true; > } > > -static int ps8640_ensure_hpd(struct ps8640 *ps_bridge) > +static int _ps8640_wait_hpd_asserted(struct ps8640 *ps_bridge, unsigned long wait_us) > { > struct regmap *map = ps_bridge->regmap[PAGE2_TOP_CNTL]; > - struct device *dev = &ps_bridge->page[PAGE2_TOP_CNTL]->dev; > int status; > - int ret; > > /* > * Apparently something about the firmware in the chip signals that > * HPD goes high by reporting GPIO9 as high (even though HPD isn't > * actually connected to GPIO9). > */ > - ret = regmap_read_poll_timeout(map, PAGE2_GPIO_H, status, > - status & PS_GPIO9, 20 * 1000, 200 * 1000); > + return regmap_read_poll_timeout(map, PAGE2_GPIO_H, status, > + status & PS_GPIO9, wait_us / 10, wait_us); > +} > > - if (ret < 0) > - dev_warn(dev, "HPD didn't go high: %d\n", ret); > +static int ps8640_wait_hpd_asserted(struct drm_dp_aux *aux, unsigned long wait_us) > +{ > + struct ps8640 *ps_bridge = aux_to_ps8640(aux); > + struct device *dev = &ps_bridge->page[PAGE0_DP_CNTL]->dev; > + int ret; > + > + pm_runtime_get_sync(dev); > + ret = _ps8640_wait_hpd_asserted(ps_bridge, wait_us); > + pm_runtime_mark_last_busy(dev); > + pm_runtime_put_autosuspend(dev); I'd add a note here, that the called should have already woken up the device. > > return ret; > } > @@ -323,9 +330,7 @@ static ssize_t ps8640_aux_transfer(struct drm_dp_aux *aux, > int ret; > > pm_runtime_get_sync(dev); > - ret = ps8640_ensure_hpd(ps_bridge); > - if (!ret) > - ret = ps8640_aux_transfer_msg(aux, msg); > + ret = ps8640_aux_transfer_msg(aux, msg); > pm_runtime_mark_last_busy(dev); > pm_runtime_put_autosuspend(dev); > > @@ -369,8 +374,8 @@ static int __maybe_unused ps8640_resume(struct device *dev) > * Mystery 200 ms delay for the "MCU to be ready". It's unclear if > * this is truly necessary since the MCU will already signal that > * things are "good to go" by signaling HPD on "gpio 9". See > - * ps8640_ensure_hpd(). For now we'll keep this mystery delay just in > - * case. > + * _ps8640_wait_hpd_asserted(). For now we'll keep this mystery delay > + * just in case. > */ > msleep(200); > > @@ -406,7 +411,9 @@ static void ps8640_pre_enable(struct drm_bridge *bridge) > int ret; > > pm_runtime_get_sync(dev); > - ps8640_ensure_hpd(ps_bridge); > + ret = _ps8640_wait_hpd_asserted(ps_bridge, 200 * 1000); > + if (ret < 0) > + dev_warn(dev, "HPD didn't go high: %d\n", ret); > > /* > * The Manufacturer Command Set (MCS) is a device dependent interface > @@ -652,6 +659,7 @@ static int ps8640_probe(struct i2c_client *client) > ps_bridge->aux.name = "parade-ps8640-aux"; > ps_bridge->aux.dev = dev; > ps_bridge->aux.transfer = ps8640_aux_transfer; > + ps_bridge->aux.wait_hpd_asserted = ps8640_wait_hpd_asserted; > drm_dp_aux_init(&ps_bridge->aux); > > pm_runtime_enable(dev); -- With best wishes Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> To: Douglas Anderson <dianders@chromium.org>, dri-devel@lists.freedesktop.org Cc: Sankeerth Billakanti <quic_sbillaka@quicinc.com>, Philip Chen <philipchen@chromium.org>, Jonas Karlman <jonas@kwiboo.se>, David Airlie <airlied@linux.ie>, linux-kernel@vger.kernel.org, Neil Armstrong <narmstrong@baylibre.com>, Abhinav Kumar <quic_abhinavk@quicinc.com>, Robert Foss <robert.foss@linaro.org>, Stephen Boyd <swboyd@chromium.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Andrzej Hajda <andrzej.hajda@intel.com>, Hsin-Yi Wang <hsinyi@chromium.org>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Subject: Re: [PATCH v3 4/4] drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux Date: Thu, 2 Jun 2022 17:56:13 +0300 [thread overview] Message-ID: <075b907c-fd12-2e91-199b-c43d27340ed2@linaro.org> (raw) In-Reply-To: <20220418101725.v3.4.Ie827321ce263be52fdb8c1276f6f8cc00d78029f@changeid> On 18/04/2022 20:17, Douglas Anderson wrote: > This implements the callback added by the patch ("drm/dp: Add > wait_hpd_asserted() callback to struct drm_dp_aux"). > > With this change and all the two "DP AUX Endpoint" drivers changed to > use wait_hpd_asserted(), we no longer need to have an long delay in > the AUX transfer function. It's up to the panel code to make sure that > the panel is powered now. If someone tried to call the aux transfer > function without making sure the panel is powered we'll just get a > normal transfer failure. > > We'll still keep the wait for HPD in the pre_enable() function. Though > it's probably not actually needed there, this driver is used in the > old mode (pre-DP AUX Endpoints) and it may be important for those > cases. If nothing else, it shouldn't cause any big problems. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Minor nit below > --- > > (no changes since v2) > > Changes in v2: > - Change is_hpd_asserted() to wait_hpd_asserted() > > drivers/gpu/drm/bridge/parade-ps8640.c | 34 ++++++++++++++++---------- > 1 file changed, 21 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c > index 9766cbbd62ad..2f19a8c89880 100644 > --- a/drivers/gpu/drm/bridge/parade-ps8640.c > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > @@ -168,23 +168,30 @@ static bool ps8640_of_panel_on_aux_bus(struct device *dev) > return true; > } > > -static int ps8640_ensure_hpd(struct ps8640 *ps_bridge) > +static int _ps8640_wait_hpd_asserted(struct ps8640 *ps_bridge, unsigned long wait_us) > { > struct regmap *map = ps_bridge->regmap[PAGE2_TOP_CNTL]; > - struct device *dev = &ps_bridge->page[PAGE2_TOP_CNTL]->dev; > int status; > - int ret; > > /* > * Apparently something about the firmware in the chip signals that > * HPD goes high by reporting GPIO9 as high (even though HPD isn't > * actually connected to GPIO9). > */ > - ret = regmap_read_poll_timeout(map, PAGE2_GPIO_H, status, > - status & PS_GPIO9, 20 * 1000, 200 * 1000); > + return regmap_read_poll_timeout(map, PAGE2_GPIO_H, status, > + status & PS_GPIO9, wait_us / 10, wait_us); > +} > > - if (ret < 0) > - dev_warn(dev, "HPD didn't go high: %d\n", ret); > +static int ps8640_wait_hpd_asserted(struct drm_dp_aux *aux, unsigned long wait_us) > +{ > + struct ps8640 *ps_bridge = aux_to_ps8640(aux); > + struct device *dev = &ps_bridge->page[PAGE0_DP_CNTL]->dev; > + int ret; > + > + pm_runtime_get_sync(dev); > + ret = _ps8640_wait_hpd_asserted(ps_bridge, wait_us); > + pm_runtime_mark_last_busy(dev); > + pm_runtime_put_autosuspend(dev); I'd add a note here, that the called should have already woken up the device. > > return ret; > } > @@ -323,9 +330,7 @@ static ssize_t ps8640_aux_transfer(struct drm_dp_aux *aux, > int ret; > > pm_runtime_get_sync(dev); > - ret = ps8640_ensure_hpd(ps_bridge); > - if (!ret) > - ret = ps8640_aux_transfer_msg(aux, msg); > + ret = ps8640_aux_transfer_msg(aux, msg); > pm_runtime_mark_last_busy(dev); > pm_runtime_put_autosuspend(dev); > > @@ -369,8 +374,8 @@ static int __maybe_unused ps8640_resume(struct device *dev) > * Mystery 200 ms delay for the "MCU to be ready". It's unclear if > * this is truly necessary since the MCU will already signal that > * things are "good to go" by signaling HPD on "gpio 9". See > - * ps8640_ensure_hpd(). For now we'll keep this mystery delay just in > - * case. > + * _ps8640_wait_hpd_asserted(). For now we'll keep this mystery delay > + * just in case. > */ > msleep(200); > > @@ -406,7 +411,9 @@ static void ps8640_pre_enable(struct drm_bridge *bridge) > int ret; > > pm_runtime_get_sync(dev); > - ps8640_ensure_hpd(ps_bridge); > + ret = _ps8640_wait_hpd_asserted(ps_bridge, 200 * 1000); > + if (ret < 0) > + dev_warn(dev, "HPD didn't go high: %d\n", ret); > > /* > * The Manufacturer Command Set (MCS) is a device dependent interface > @@ -652,6 +659,7 @@ static int ps8640_probe(struct i2c_client *client) > ps_bridge->aux.name = "parade-ps8640-aux"; > ps_bridge->aux.dev = dev; > ps_bridge->aux.transfer = ps8640_aux_transfer; > + ps_bridge->aux.wait_hpd_asserted = ps8640_wait_hpd_asserted; > drm_dp_aux_init(&ps_bridge->aux); > > pm_runtime_enable(dev); -- With best wishes Dmitry
next prev parent reply other threads:[~2022-06-02 14:56 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-18 17:17 [PATCH v3 0/4] drm/dp: Introduce wait_hpd_asserted() for the DP AUX bus Douglas Anderson 2022-04-18 17:17 ` Douglas Anderson 2022-04-18 17:17 ` [PATCH v3 1/4] drm/dp: Add wait_hpd_asserted() callback to struct drm_dp_aux Douglas Anderson 2022-04-18 17:17 ` Douglas Anderson 2022-05-12 1:58 ` Stephen Boyd 2022-05-12 1:58 ` Stephen Boyd 2022-05-12 23:24 ` Doug Anderson 2022-05-12 23:24 ` Doug Anderson 2022-05-20 0:34 ` Stephen Boyd 2022-05-20 0:34 ` Stephen Boyd 2022-05-20 15:45 ` Doug Anderson 2022-05-20 15:45 ` Doug Anderson 2022-06-02 10:22 ` Dmitry Baryshkov 2022-06-02 10:22 ` Dmitry Baryshkov 2022-04-18 17:17 ` [PATCH v3 2/4] drm/panel-edp: Take advantage of wait_hpd_asserted() in " Douglas Anderson 2022-04-18 17:17 ` Douglas Anderson 2022-06-02 15:12 ` Dmitry Baryshkov 2022-06-02 15:12 ` Dmitry Baryshkov 2022-06-14 21:57 ` Doug Anderson 2022-06-14 21:57 ` Doug Anderson 2022-04-18 17:17 ` [PATCH v3 3/4] drm/panel: atna33xc20: " Douglas Anderson 2022-04-18 17:17 ` Douglas Anderson 2022-06-02 14:49 ` Dmitry Baryshkov 2022-06-02 14:49 ` Dmitry Baryshkov 2022-04-18 17:17 ` [PATCH v3 4/4] drm/bridge: parade-ps8640: Provide " Douglas Anderson 2022-04-18 17:17 ` Douglas Anderson 2022-06-02 14:56 ` Dmitry Baryshkov [this message] 2022-06-02 14:56 ` Dmitry Baryshkov 2022-05-03 23:26 ` [PATCH v3 0/4] drm/dp: Introduce wait_hpd_asserted() for the DP AUX bus Doug Anderson 2022-05-03 23:26 ` Doug Anderson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=075b907c-fd12-2e91-199b-c43d27340ed2@linaro.org \ --to=dmitry.baryshkov@linaro.org \ --cc=Laurent.pinchart@ideasonboard.com \ --cc=airlied@linux.ie \ --cc=andrzej.hajda@intel.com \ --cc=daniel@ffwll.ch \ --cc=dianders@chromium.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=hsinyi@chromium.org \ --cc=jernej.skrabec@gmail.com \ --cc=jonas@kwiboo.se \ --cc=linux-kernel@vger.kernel.org \ --cc=narmstrong@baylibre.com \ --cc=philipchen@chromium.org \ --cc=quic_abhinavk@quicinc.com \ --cc=quic_sbillaka@quicinc.com \ --cc=robert.foss@linaro.org \ --cc=swboyd@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.