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,
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
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
---
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,
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
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
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:
