linux-kernel - Re: [PATCH v1] drm/bridge: ti-sn65dsi86: Use HPD in a DP use case

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: <CAD=FV=W=NjbM9ZXLw7gH-_4CnpU7QU=sKCVQVxgmgP-Qpt-3hg@mail.gmail.com>
Date: Thu, 1 May 2025 20:38:15 -0700
From: Doug Anderson <dianders@...omium.org>
To: max.oss.09@...il.com
Cc: max.krummenacher@...adex.com, Jayesh Choudhary <j-choudhary@...com>, 
	Andrzej Hajda <andrzej.hajda@...el.com>, David Airlie <airlied@...il.com>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Jonas Karlman <jonas@...boo.se>, 
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>, 
	Simona Vetter <simona@...ll.ch>, Thomas Zimmermann <tzimmermann@...e.de>, dri-devel@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] drm/bridge: ti-sn65dsi86: Use HPD in a DP use case

Hi,

On Thu, May 1, 2025 at 12:48 AM <max.oss.09@...il.com> wrote:
>
> From: Max Krummenacher <max.krummenacher@...adex.com>
>
> The bridge driver currently disables handling the hot plug input and
> relies on a always connected eDP panel with fixed delays when the
> panel is ready.

Not entirely correct. In some cases we don't have fixed delays and
instead use a GPIO for HPD. That GPIO gets routed to the eDP panel
code.


> If one uses the bridge for a regular display port monitor this
> assumption is no longer true.
> If used with a display port monitor change to keep the hot plug
> detection functionality enabled and change to have the bridge working
> during runtime suspend to be able to detect the connection state.
>
> Note that if HPD_DISABLE is set the HPD bit always returns connected
> independent of the actual state of the hot plug pin. Thus
> currently bridge->detect() always returns connected.

If that's true, it feels like this needs:

Fixes: c312b0df3b13 ("drm/bridge: ti-sn65dsi86: Implement bridge
connector operations for DP")

...and it would be nice to get Laurent to confirm. Seems weird that he
wouldn't have noticed that.


> Signed-off-by: Max Krummenacher <max.krummenacher@...adex.com>
>
> ---
>
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 01d456b955ab..c7496bf142d1 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -333,9 +333,11 @@ static void ti_sn65dsi86_enable_comms(struct ti_sn65dsi86 *pdata)
>          * If HPD somehow makes sense on some future panel we'll have to
>          * change this to be conditional on someone specifying that HPD should
>          * be used.
> +        * Only disable HDP if used for eDP.
>          */
> -       regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG, HPD_DISABLE,
> -                          HPD_DISABLE);
> +       if (pdata->bridge.type == DRM_MODE_CONNECTOR_eDP)
> +               regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG,
> +                                  HPD_DISABLE, HPD_DISABLE);
>
>         pdata->comms_enabled = true;
>
> @@ -357,6 +359,10 @@ static int __maybe_unused ti_sn65dsi86_resume(struct device *dev)
>         struct ti_sn65dsi86 *pdata = dev_get_drvdata(dev);
>         int ret;
>
> +       if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort &&
> +           pdata->comms_enabled)
> +               return 0;
> +

I don't understand this part of the patch. You're basically making
suspend/resume a no-op for the DP case? I don't think that's right...

First, I don't _think_ you need it, right? ...since "detect" is
already grabbing the pm_runtime reference this shouldn't be needed
from a correctness point of view.

Second, if you're looking to eventually make the interrupt work, I
don't think this is the right first step. I think in previous
discussions about this it was agreed that if we wanted the interrupt
to work then we should just do a "pm_runtime_get_sync()" before
enabling the interrupt and then a "pm_runtime_put()" after disabling
it. That'll keep things from suspending.

Does that sound correct, or did I goof up on anything?

-Doug