** Tags added: oem-priority originate-from-1946057 somerville ** Tags added: originate-from-1942069
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.14 in Ubuntu. https://bugs.launchpad.net/bugs/1949321 Title: Fix System hangs on black screen when reboot Status in HWE Next: New Status in linux package in Ubuntu: In Progress Status in linux-oem-5.10 package in Ubuntu: New Status in linux-oem-5.14 package in Ubuntu: New Status in linux source package in Focal: New Status in linux-oem-5.10 source package in Focal: In Progress Status in linux-oem-5.14 source package in Focal: In Progress Status in linux source package in Hirsute: In Progress Status in linux-oem-5.10 source package in Hirsute: New Status in linux-oem-5.14 source package in Hirsute: New Status in linux source package in Impish: In Progress Status in linux-oem-5.10 source package in Impish: New Status in linux-oem-5.14 source package in Impish: New Status in linux source package in Jammy: In Progress Status in linux-oem-5.10 source package in Jammy: New Status in linux-oem-5.14 source package in Jammy: New Bug description: [Impact] System hangs on black screen when reboot [Fix] Looks like our VBIOS/GOP generally fail to turn the DP dual mode adater TMDS output buffers back on after a reboot. This leads to a black screen after reboot if we turned the TMDS output buffers off prior to reboot. And if i915 decides to do a fastboot the black screen will persist even after i915 takes over. Apparently this has been a problem ever since commit b2ccb822d376 ("drm/i915:Enable/disable TMDS output buffers in DP++ adaptor as needed") if one rebooted while the display was turned off. And things became worse with commit fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot") since now we always turn the display off before a reboot. This was reported on a RKL, but I confirmed the same behaviour on my SNB as well. So looks pretty universal. Let's fix this by explicitly turning the TMDS output buffers back on in the encoder->shutdown() hook. Note that this gets called after irqs have been disabled, so the i2c communication with the DP dual mode adapter has to be performed via polling (which the gmbus code is perfectly happy to do for us). We also need a bit of care in handling DDI encoders which may or may not be set up for HDMI output. Specifically ddc_pin will not be populated for a DP only DDI encoder, in which case we don't want to call intel_gmbus_get_adapter(). We can handle that by simply doing the dual mode adapter type check before calling intel_gmbus_get_adapter(). Ref: https://patchwork.freedesktop.org/series/96433/ [Test] 1. install kernel 2. reboot 3. check the monitor works well. [Regression Potential] Medium, patch has sent to patchwork but may have a upgraded version in the furtue. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1949321/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp