Hi Doug On Thu, Jul 2, 2026 at 12:33 AM Doug Anderson <[email protected]> wrote: > > Hi, > > On Tue, Jun 30, 2026 at 6:16 PM Haikun Zhou > <[email protected]> wrote: > > > > Hi Doug, thank you very much for your reply, > > > > On Wed, Jul 1, 2026 at 1:33 AM Doug Anderson <[email protected]> wrote: > > > > > > Hi, > > > > > > On Sun, Jun 28, 2026 at 8:09 PM Haikun Zhou > > > <[email protected]> wrote: > > > > > > > > Due to panel characteristics, when the panel wakes up from the S3, the > > > > main link data is not yet ready when the backlight turns on, causing > > > > a garbage appearance on the screen. Delaying the backlight by 1000ms > > > > can avoid this issue. > > > > > > > > Signed-off-by: Haikun Zhou <[email protected]> > > > > --- > > > > drivers/gpu/drm/panel/panel-edp.c | 8 +++++++- > > > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > > > This really doesn't feel right; it seems like a hack papering over a > > > problem whose root cause hasn't been found. If nothing else, what does > > > "S3" have to do with anything? The panel isn't left powered on during > > > S3, right? So, as far as the panel is concerned, S3 should be the same > > > as S5. Why would you see this noise only coming out of S3? > > > > > > -Doug > > > > Yes, this screen issue isn't limited to the S3; the backlight turning > > on first and then > > displaying garbage isn't limited to this issue. On Chromebooks, the > > same phenomenon occurs > > when the backlight is completely turned off and then back on. > > Measurements with EE revealed > > that when the backlight is on, the main link data is already being > > transmitted but is still unstable. > > Turning on the backlight at this time causes the screen to display garbage. > > We had to add sufficient backlight delay to fix this issue, and while > > we could modify it in the DTS > > settings, since this is a screen-related problem, we wanted to fix it > > from the driver. > > OK, fair enough. Sure, if this is truly a problem with this specific > panel then your patch is the correct one. That being said, I'd still > like to confirm a bit more. Specifically: > > 1. Usually the controller on the panel is shared among a family of > displays. Do we understand why this specific panel needs the extra > delay while no other panels do? Is this only because we support so few > KDC panels? > > 2. Have you talked to the panel manufacturer about this problem? Have > they confirmed that they understand the problem and verified that we > truly need a full 1 second delay here? > > The 1-second delay is pretty beefy and can affect things like boot > speed for devices using this panel. > > -Doug
about the 1 question: The limited number of KDC panels is not the cause. Our waveform measurements revealed that after recovery from S3, the complete image from the source output system was only available after 1120ms. We had to delay the blending time to avoid garbage caused by incomplete source output. It's worth noting that adding 1000ms to circumvent the issue is already quite poor; based on the oscilloscope waveform, we would need to add at least 1120ms to completely avoid it. about the 2 question: Yes, we have discussed this with the vendor, based on what's visually perceptible, we confirmed with the vendor that 1000ms is feasible. -Haikun
