linux-kernel - Re: [RFC PATCH v2 3/9] drm/panel: nv3052c: Sleep for 150ms after reset

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: <7fc1ca68-ca7c-59b2-0b70-27bc34d83cee@quicinc.com>
Date:   Mon, 18 Sep 2023 13:19:03 -0700
From:   Jessica Zhang <quic_jesszhan@...cinc.com>
To:     John Watts <contact@...kia.org>, <dri-devel@...ts.freedesktop.org>
CC:     Neil Armstrong <neil.armstrong@...aro.org>,
        Sam Ravnborg <sam@...nborg.org>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Heiko Stuebner <heiko@...ech.de>,
        Chris Morgan <macromorgan@...mail.com>,
        Jagan Teki <jagan@...eble.ai>,
        Paul Cercueil <paul@...pouillou.net>,
        Christophe Branchereau <cbranchereau@...il.com>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 3/9] drm/panel: nv3052c: Sleep for 150ms after
 reset



On 9/18/2023 5:58 AM, John Watts wrote:
> The current code waits after resets for 5 to 20 milliseconds.
> This is appropriate when resetting a sleeping panel, but an awake panel
> requires at least 120ms of waiting.
> 
> Sleep for 150ms so the panel always completes it reset properly.
> 
> Signed-off-by: John Watts <contact@...kia.org>

Hi John,

Just wondering, is there some context to this change? I.e., was this 
made to fix a specific issue?

This seems like a pretty significant increase in wait time so, if it's 
not a fix, I'm not sure if this would be an improvement on the current 
behavior.

Thanks,

Jessica Zhang

> ---
>   drivers/gpu/drm/panel/panel-newvision-nv3052c.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
> index 90dea21f9856..2526b123b1f5 100644
> --- a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
> +++ b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
> @@ -258,7 +258,7 @@ static int nv3052c_prepare(struct drm_panel *panel)
>   	gpiod_set_value_cansleep(priv->reset_gpio, 1);
>   	usleep_range(10, 1000);
>   	gpiod_set_value_cansleep(priv->reset_gpio, 0);
> -	usleep_range(5000, 20000);
> +	msleep(150);
>   
>   	for (i = 0; i < ARRAY_SIZE(nv3052c_panel_regs); i++) {
>   		err = mipi_dbi_command(dbi, nv3052c_panel_regs[i].cmd,
> -- 
> 2.42.0
>