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
next prev parent reply other threads:[~2022-06-02 14:56 UTC|newest]
Thread overview: 15+ 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 ` [PATCH v3 1/4] drm/dp: Add wait_hpd_asserted() callback to struct drm_dp_aux Douglas Anderson
2022-05-12 1:58 ` Stephen Boyd
2022-05-12 23:24 ` Doug Anderson
2022-05-20 0:34 ` Stephen Boyd
2022-05-20 15:45 ` Doug Anderson
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-06-02 15:12 ` Dmitry Baryshkov
2022-06-14 21:57 ` Doug Anderson
2022-04-18 17:17 ` [PATCH v3 3/4] drm/panel: atna33xc20: " Douglas Anderson
2022-06-02 14:49 ` Dmitry Baryshkov
2022-04-18 17:17 ` [PATCH v3 4/4] drm/bridge: parade-ps8640: Provide " Douglas Anderson
2022-06-02 14:56 ` Dmitry Baryshkov [this message]
2022-05-03 23:26 ` [PATCH v3 0/4] drm/dp: Introduce wait_hpd_asserted() for the DP AUX bus 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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®