linux-kernel - Re: [Intel-gfx] [PATCH v2] drm/i915/display/lspcon: Increase LSPCON mode settle timeout

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: <6b49563d-e9e7-ae8e-582e-f4aead06de0a@intel.com>
Date:   Thu, 15 Jun 2023 10:05:10 +0530
From:   "Nautiyal, Ankit K" <ankit.k.nautiyal@...el.com>
To:     Pablo Ceballos <pceballos@...gle.com>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>
CC:     <intel-gfx@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>,
        <dri-devel@...ts.freedesktop.org>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Sam Ravnborg <sam@...nborg.org>
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/display/lspcon: Increase LSPCON
 mode settle timeout


On 6/15/2023 5:24 AM, Pablo Ceballos wrote:
> This is to eliminate all cases of "*ERROR* LSPCON mode hasn't settled",
> followed by link training errors. Intel engineers recommended increasing
> this timeout and that does resolve the issue.
>
> On some CometLake-based device designs the Parade PS175 takes more than
> 400ms to settle in PCON mode. 100 reboot trials on one device resulted
> in a median settle time of 440ms and a maximum of 444ms. Even after
> increasing the timeout to 500ms, 2% of devices still had this error. So
> this increases the timeout to 800ms.

In one of the gitlab issue, it was tried with 1000ms as well, situation 
did improve, but issue didn't get fully resolved. [1].

I was wondering if trying to set LS/PCON mode multiple time will have 
any effect.

Unfortunately I do not have access to machine with Parade LSPCON chip, 
had suggested in yet another git lab issue [2].

I have a patch for this, sent to try-bot, though not sent to intel-gfx 
yet [3].


The timeout value was already increased from 100 ms to 400 ms earlier too.

If there is indeed no other way, perhaps need to have this solution.


[1] https://gitlab.freedesktop.org/drm/intel/-/issues/4516#note_1406500

[2] https://gitlab.freedesktop.org/drm/intel/-/issues/4458#note_1922654

[3] Patch : 
https://patchwork.freedesktop.org/patch/538819/?series=118208&rev=1


Regards,

Ankit


>
> Signed-off-by: Pablo Ceballos <pceballos@...gle.com>
> ---
>
> Changelog since v1:
> - Added more details in the commit message
>
>   drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index bb3b5355a0d9..d7299fdc43ad 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -167,7 +167,7 @@ static enum drm_lspcon_mode lspcon_wait_mode(struct intel_lspcon *lspcon,
>   	drm_dbg_kms(&i915->drm, "Waiting for LSPCON mode %s to settle\n",
>   		    lspcon_mode_name(mode));
>   
> -	wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 400);
> +	wait_for((current_mode = lspcon_get_current_mode(lspcon)) == mode, 800);
>   	if (current_mode != mode)
>   		drm_err(&i915->drm, "LSPCON mode hasn't settled\n");
>