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
