linux-kernel - Re: [PATCH] drm/bridge: parade-ps8640: Ensure bridge is suspended in .post

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=XjpSbqJ=qb0BiuUCAww6=OLHuxxSot6o_u_vKYBYQ57w@mail.gmail.com>
Date: Mon, 8 Jan 2024 14:46:40 -0800
From: Doug Anderson <dianders@...omium.org>
To: Pin-yen Lin <treapking@...omium.org>
Cc: Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Robert Foss <rfoss@...nel.org>, Laurent Pinchart <Laurent.pinchart@...asonboard.com>, 
	Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>, linux-kernel@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, Sean Paul <seanpaul@...omium.org>
Subject: Re: [PATCH] drm/bridge: parade-ps8640: Ensure bridge is suspended in .post_disable()

Hi,

On Wed, Dec 27, 2023 at 2:43 AM Pin-yen Lin <treapking@...omium.org> wrote:
>
> Disable the autosuspend of runtime PM and use completion to make sure
> ps8640_suspend() is called in ps8640_atomic_post_disable().
>
> The ps8640 bridge seems to expect everything to be power cycled at the
> disable process, but sometimes ps8640_aux_transfer() holds the runtime
> PM reference and prevents the bridge from suspend.
>
> Instead of force powering off the bridge and taking the risk of breaking
> the AUX communication, disable the autosuspend and wait for
> ps8640_suspend() being called here, and re-enable the autosuspend
> afterwards.  With this approach, the bridge should be suspended after
> the current ps8640_aux_transfer() completes.
>
> Fixes: 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power management")
> Signed-off-by: Pin-yen Lin <treapking@...omium.org>
> ---
>
>  drivers/gpu/drm/bridge/parade-ps8640.c | 33 +++++++++++++++++++++++++-
>  1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c
> index 8161b1a1a4b1..f8ea486a76fd 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -107,6 +107,7 @@ struct ps8640 {
>         struct device_link *link;
>         bool pre_enabled;
>         bool need_post_hpd_delay;
> +       struct completion suspend_completion;
>  };
>
>  static const struct regmap_config ps8640_regmap_config[] = {
> @@ -417,6 +418,8 @@ static int __maybe_unused ps8640_suspend(struct device *dev)
>         if (ret < 0)
>                 dev_err(dev, "cannot disable regulators %d\n", ret);
>
> +       complete_all(&ps_bridge->suspend_completion);
> +
>         return ret;
>  }
>
> @@ -465,11 +468,37 @@ static void ps8640_atomic_post_disable(struct drm_bridge *bridge,
>                                        struct drm_bridge_state *old_bridge_state)
>  {
>         struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +       struct device *dev = &ps_bridge->page[PAGE0_DP_CNTL]->dev;
>
>         ps_bridge->pre_enabled = false;
>
>         ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> -       pm_runtime_put_sync_suspend(&ps_bridge->page[PAGE0_DP_CNTL]->dev);
> +
> +       /*
> +        * The ps8640 bridge seems to expect everything to be power cycled at
> +        * the disable process, but sometimes ps8640_aux_transfer() holds the
> +        * runtime PM reference and prevents the bridge from suspend.
> +        * Instead of force powering off the bridge and taking the risk of
> +        * breaking the AUX communication, disable the autosuspend and wait for
> +        * ps8640_suspend() being called here, and re-enable the autosuspend
> +        * afterwards.  With this approach, the bridge should be suspended after
> +        * the current ps8640_aux_transfer() completes.
> +        */
> +       reinit_completion(&ps_bridge->suspend_completion);
> +       pm_runtime_dont_use_autosuspend(dev);
> +       pm_runtime_put_sync_suspend(dev);
> +
> +       /*
> +        * Mostly the suspend completes under 10 ms, but sometimes it could
> +        * take 708 ms to complete.  Set the timeout to 2000 ms here to be
> +        * extra safe.
> +        */
> +       if (!wait_for_completion_timeout(&ps_bridge->suspend_completion,
> +                                        msecs_to_jiffies(2000))) {
> +               dev_warn(dev, "Failed to wait for the suspend completion\n");
> +       }
> +
> +       pm_runtime_use_autosuspend(dev);

Thanks for tracking this down! I agree with your analysis and it seems
like we've got to do something about it.

I spent a little time trying to think about a cleaner way. What do you
think about adding a "aux_transfer" mutex? You'd grab this mutex for
the entire duration of ps8640_aux_transfer() and
ps8640_atomic_post_disable(). That way you don't need the weird
completion / timeout and don't need to hackily turn off/on
autosuspend. You shouldn't need the mutex in
ps8640_wait_hpd_asserted() because that will never be called at the
same time as ps8640_atomic_post_disable().

-Doug