[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=UVP22ANJD5xEB6MRHCDjXN6SZhQWQshPxwhi51YRkEjQ@mail.gmail.com>
Date: Fri, 13 Oct 2023 14:43:12 -0700
From: Doug Anderson <dianders@...gle.com>
To: Cong Yang <yangcong5@...qin.corp-partner.google.com>
Cc: sam@...nborg.org, neil.armstrong@...aro.org, daniel@...ll.ch,
hsinyi@...gle.com, linus.walleij@...aro.org, swboyd@...omium.org,
airlied@...il.com, catalin.marinas@....com, will@...nel.org,
dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [v4 2/3] drm/panel: ili9882t: Avoid blurred screen from fast sleep
Hi,
On Fri, Oct 13, 2023 at 2:19 AM Cong Yang
<yangcong5@...qin.corp-partner.google.com> wrote:
>
> At present, we have found that there may be a problem of blurred
> screen during fast sleep/resume. The direct cause of the blurred
> screen is that the IC does not receive 0x28/0x10. Because of the
> particularity of the IC, before the panel enters sleep hid must
> stop scanning, as i2c_hid_core_suspend before ili9882t_disable.
> If move the ili9882t_enter_sleep_mode function to ili9882t_unprepare,
> touch reset will pull low before panel entersleep, which does not meet
> the timing requirements.. So in order to solve this problem, the IC
> can handle it through the exception mechanism when it cannot receive
> 0x28/0x10 command. Handling exceptions requires a reset 50ms delay.
> Refer to vendor detailed analysis [1].
>
> Ilitek vendor also suggested switching the page before entering sleep to
> avoid panel IC not receiving 0x28/0x10 command.
>
> Note: 0x28 is display off, 0x10 is sleep in.
>
> [1]: https://github.com/ILITEK-LoganLin/Document/tree/main/ILITEK_Power_Sequence
>
> Signed-off-by: Cong Yang <yangcong5@...qin.corp-partner.google.com>
> ---
> drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 22 ++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
As talked about in response to the previous version [1], we can work
to see if we can improve the sequencing. However, for now this seems
fine.
Reviewed-by: Douglas Anderson <dianders@...omium.org>
[1] https://lore.kernel.org/r/CAD=FV=W_LT9mPYKjaKP3OvUDeNpsZxkhVN9NP_hQ+Es6Fe3dVw@mail.gmail.com
Powered by blists - more mailing lists