| Message ID | 20240908132823.3308029-1-jonas@kwiboo.se (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup | expand |
Hi Jonas, On Sun Sep 8, 2024 at 3:28 PM CEST, Jonas Karlman wrote: > This series ensure poweron/poweroff and CEC phys addr invalidation is > happening under drm mode_config mutex lock, and also ensure EDID is > updated (when the dw-hdmi connector is used) after a hotplug pulse. > > These changes has mainly been tested on Rockchip devices together with a > series [1] that add HDMI 2.0 4K@60Hz support to RK3228, RK3328, RK3399 > and RK3568. I did some tests with this series (together with the 4K60Hz one). Test setup: - TV capable of display 4K@60Hz - monitor capable of displaying 1080p@60Hz - Quartz64 Model-A - Rock64 When I booted up connected to the 4K TV, the boot messages were displayed in 1080p resolution. IIUC it was to be considered an improvement when it would be illegible at 4K, but that did not happen. Neither on the Q64-A or the Rock64. When executing ``cat /sys/class/graphics/*/modes`` it returned ``U:3840x2160p-0``, so that was good. I then went on the HDMI-hot-plug-swap-test and connected it to my 1080p monitor while the system was still online. That did not change the output of the previous command. As my monitor doesn't support 4K it seems to have chosen a 640p or 720p resolution. IOW the letters were rather big. With enough output on the screen, it went off the visible area, so all I could do then was 'blind' typing. If I booted up connected to the 1080p monitor then it reported a 1080p resolution and when swapping to the 4K TV, it kept reporting that value and displaying things in 1080p resolution, but ofc there were no abnormal big letters or output falling off the screen this time. If I did those test when Sway was running, all the data (``swaymsg -t get_outputs --pretty``) showed that a proper resolution switch was made and the display was correctly adjusted accordingly. I then tried to do the keep-swapping-until-output-breaks what Chris reported about in the previous series. At some point I thought I was able to reproduce the issue ... to then conclude I had likely hit the poweroff button when swapping the cables. And another time I thought I had managed to reproduce it ... to then find out display wasn't working at all anymore. Turned out that likely due to all that swapping, it was no longer properly inserted into my monitor. I've tried it a LOT of times, but I have to conclude that I was not able to reproduce the problem and therefor also not the solution. HTH, Diederik
Hi Jonas and Laurent, I may be showing my n00bness ... or I actually found something ... On Fri Sep 13, 2024 at 7:30 PM CEST, Diederik de Haas wrote: > On Sun Sep 8, 2024 at 3:28 PM CEST, Jonas Karlman wrote: > > This series ensure poweron/poweroff and CEC phys addr invalidation is > > happening under drm mode_config mutex lock, and also ensure EDID is > > updated (when the dw-hdmi connector is used) after a hotplug pulse. > > > > These changes has mainly been tested on Rockchip devices together with a > > series [1] that add HDMI 2.0 4K@60Hz support to RK3228, RK3328, RK3399 > > and RK3568. > > I did some tests with this series (together with the 4K60Hz one). > > ... > > I then went on the HDMI-hot-plug-swap-test and connected it to my 1080p > monitor while the system was still online. That did not change the > output of the previous command. As my monitor doesn't support 4K it > seems to have chosen a 640p or 720p resolution. > IOW the letters were rather big. With enough output on the screen, it > went off the visible area, so all I could do then was 'blind' typing. > > If I booted up connected to the 1080p monitor then it reported a 1080p > resolution and when swapping to the 4K TV, it kept reporting that value > and displaying things in 1080p resolution, but ofc there were no > abnormal big letters or output falling off the screen this time. A DT validation on rk3328-rock64.dtb reported this: rockchip/rk3328-rock64.dtb: hdmi@ff3c0000: interrupts: [[0, 35, 4], [0, 71, 4]] is too long That's because `display/bridge/synopsys,dw-hdmi.yaml` dt-binding has interrupts : maxItems : 1 and the rk3328.dtsi file has 2 interrupts in its hdmi node. Easiest solution is to just remove the 2nd one and that makes DT validation happy. Looking at the rk3328 TRM, I found these hdmi related interrupts: 67 hdmi_intr 103 hdmi_intr_wakeup Looking at the rk3399 TRM, I found these hdmi related interrupts: 23 hdmi_irq 24 hdmi_wakeup_irq Looking at the rk3568 TRM, I found these hdmi related interrupts: 76 hdmi_wakeup 77 hdmi So my thinking is: - what if the dt-binding is incorrect? (-> maxItems : 2?) - wakeup 'sounds like' Hot Plug Detection? which makes it relevant for this series and it could mean that the rk3399-base.dtsi and rk356x.dtsi are actually missing an interrupt definition in their DT files? Or I am completely talking nonsense, which is the most likely scenario. Cheers, Diederik