linux-kernel - Re: [PATCH v3 4/4] drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <075b907c-fd12-2e91-199b-c43d27340ed2@linaro.org>
Date:   Thu, 2 Jun 2022 17:56:13 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Douglas Anderson <dianders@...omium.org>,
        dri-devel@...ts.freedesktop.org
Cc:     Hsin-Yi Wang <hsinyi@...omium.org>,
        Sankeerth Billakanti <quic_sbillaka@...cinc.com>,
        Philip Chen <philipchen@...omium.org>,
        Robert Foss <robert.foss@...aro.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...ux.ie>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Jonas Karlman <jonas@...boo.se>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 4/4] drm/bridge: parade-ps8640: Provide
 wait_hpd_asserted() in struct drm_dp_aux

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@...omium.org>

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.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