All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.