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 <[email protected]>
---
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
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 <[email protected]>
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
>
On Mon, Sep 18, 2023 at 11:01:15PM +0200, Paul Cercueil wrote:
> The datasheet does say a 5ms sleep time is necesary after a reset. I
> assume the 120ms delay you quote is when a *software* reset is
> performed in Sleep-out mode. The code here does a hard-reset.
>
> Cheers,
> -Paul
Hello Paul,
Section 7.3 of the data sheet (AC characteristic) says that the reset can take
up to 120ms to complete if the reset is applied during sleep out mode.
John.
On Mon, Sep 18, 2023 at 01:19:03PM -0700, Jessica Zhang wrote:
> 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
Hi Jessica,
Thank you for the feedback.
This patch here is required by the data sheet if the screen was already running
and was reset. This is necessary if for example the bootloader set up and had
the screen running. However I have not tested this, it's possible the specific
panels have shorter tolerances for resets. This is purely precautionary at
this stage based on what the data sheet says.
That said I will be investigating this specific use case with this panel over
the next few months. I am okay separating out this patch until I have proof it's
needed for my particular display. I don't know anything about the ltk display.
The second sleep patch can probably be omitted as I don't think the panel being
prepared then unprepared in rapid succession is a realistic situation, but I
figured I might as well propose it to see if it's the right thing to do.
Thanks for your time and review,
John.
On Mon, Sep 18, 2023 at 11:34:51PM +0200, Paul Cercueil wrote:
> The driver is guaranteed to always reset the panel in sleep-in mode -
> as long as the panel was off when the driver started.
>
> What I'd suggest if you really need to support a case where the panel
> was enabled by the bootloader, is to read the 0x0a register after
> enabling the regulator to read the mode, and sleep 120ms if it was in
> sleep-out mode.
>
> But that's only if it's a case that you can test with. I won't accept a
> patch that makes sense on the surface if it addresses a corner case
> that nobody ever tested for.
>
> For what I know, this patch just adds a huge delay to panel boot-up for
> all existing users for no valid reason.
>
>
> Cheers,
> -Paul
Thank you very much for this feedback. I am more than happy to throw these
sleep patches in the trash and come back later with a proper solution when
I have an actual hardware setup and use case to test on.
John.
Le mardi 19 septembre 2023 à 07:08 +1000, John Watts a écrit :
> On Mon, Sep 18, 2023 at 11:01:15PM +0200, Paul Cercueil wrote:
> > The datasheet does say a 5ms sleep time is necesary after a reset.
> > I
> > assume the 120ms delay you quote is when a *software* reset is
> > performed in Sleep-out mode. The code here does a hard-reset.
> >
> > Cheers,
> > -Paul
>
> Hello Paul,
>
> Section 7.3 of the data sheet (AC characteristic) says that the reset
> can take
> up to 120ms to complete if the reset is applied during sleep out
> mode.
>
> John.
The driver is guaranteed to always reset the panel in sleep-in mode -
as long as the panel was off when the driver started.
What I'd suggest if you really need to support a case where the panel
was enabled by the bootloader, is to read the 0x0a register after
enabling the regulator to read the mode, and sleep 120ms if it was in
sleep-out mode.
But that's only if it's a case that you can test with. I won't accept a
patch that makes sense on the surface if it addresses a corner case
that nobody ever tested for.
For what I know, this patch just adds a huge delay to panel boot-up for
all existing users for no valid reason.
Cheers,
-Paul
Hi John,
Le mardi 19 septembre 2023 à 06:52 +1000, John Watts a écrit :
> On Mon, Sep 18, 2023 at 01:19:03PM -0700, Jessica Zhang wrote:
> > 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
>
> Hi Jessica,
>
> Thank you for the feedback.
>
> This patch here is required by the data sheet if the screen was
> already running
> and was reset. This is necessary if for example the bootloader set up
> and had
> the screen running. However I have not tested this, it's possible the
> specific
> panels have shorter tolerances for resets. This is purely
> precautionary at
> this stage based on what the data sheet says.
>
> That said I will be investigating this specific use case with this
> panel over
> the next few months. I am okay separating out this patch until I have
> proof it's
> needed for my particular display. I don't know anything about the ltk
> display.
>
> The second sleep patch can probably be omitted as I don't think the
> panel being
> prepared then unprepared in rapid succession is a realistic
> situation, but I
> figured I might as well propose it to see if it's the right thing to
> do.
>
> Thanks for your time and review,
> John.
The datasheet does say a 5ms sleep time is necesary after a reset. I
assume the 120ms delay you quote is when a *software* reset is
performed in Sleep-out mode. The code here does a hard-reset.
Cheers,
-Paul