<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - [SKL][bisected] Screen regularly returns from power save mode" href="https://bugs.freedesktop.org/show_bug.cgi?id=99578#c32">Comment # 32</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - [SKL][bisected] Screen regularly returns from power save mode" href="https://bugs.freedesktop.org/show_bug.cgi?id=99578">bug 99578</a> from <a class="email" href="mailto:rodrigo.vivi@gmail.com" title="Rodrigo Vivi <rodrigo.vivi@gmail.com>"> Rodrigo Vivi</a> <pre>Hi Patrick, Did you have a chance do test without dmc firmware in rootfs nor intiramfs? Your first log for enable_dc=0 is short and without the wake-up part. But if you state that the wake up also happens on that case it is unlikely that this is dmc, but to prove we would need to remove dmc firmware loading completely. And possibly re-do the bisect without dmc firmware installed on all iterations. Also on last commit you mention that wakes up happens around here: [ 161.751305] [drm:0xffffffff8a398d76] Suspending device [ 161.753704] [drm:0xffffffff8a398e44] Device suspended [ 171.773089] [drm:0xffffffff8a43c9af] [CONNECTOR:48:HDMI-A-1] [ 171.789177] [drm:0xffffffff8a39836e] Resuming device [ 171.793424] [drm:0xffffffff8a398433] Device resumed Usually this connector line with no other info are on the path where userspace requested connected connectors information.... (I'm not blaming userspace. If it was something that worked before with same userspace but it is not working now it is a kernel regression bug.) So I believe the bug are around the connector state... Not around DMC firmware. This is why I believe another bisect without dmc firmware in all iterations would be so helpful.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>