Hi, On Fri, Jul 3, 2026 at 2:19 AM Haikun Zhou <[email protected]> wrote: > > 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.
"incomplete source output" makes it sound as if your eDP controller is providing bad data during this time. > 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. I'm trying to understand why this specific model of panel has the problem, but no other panels need such a long delay here. It's very suspicious. Unless we understand what makes this panel different / unique, I feel like the problem is elsewhere in the system and this delay is just hiding it. -Doug
