[v2,00/10] drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup

Message

Jonas Karlman Sept. 8, 2024, 1:28 p.m. UTC

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.

Rockchip use the dw-hdmi connector so this should also be validated with
a driver that use the bridge connector.

Changes in v2:
- Add patch to disable scrambler feature when not supported
- Add patch to only notify connected status on HPD interrupt
- Update commit messages
- Collect r-b tags
- Rebased on next-20240906

[1] https://lore.kernel.org/r/[e-mail]/

Jonas Karlman (10):
  drm: bridge: dw_hdmi: Disable scrambler feature when not supported
  drm: bridge: dw_hdmi: Only notify connected status on HPD interrupt
  drm: bridge: dw_hdmi: Call poweron/poweroff from atomic enable/disable
  drm: bridge: dw_hdmi: Use passed mode instead of stored previous_mode
  drm: bridge: dw_hdmi: Fold poweron and setup functions
  drm: bridge: dw_hdmi: Remove previous_mode and mode_set
  drm: bridge: dw_hdmi: Invalidate CEC phys addr from connector detect
  drm: bridge: dw_hdmi: Remove cec_notifier_mutex
  drm: bridge: dw_hdmi: Update EDID during hotplug processing
  drm: bridge: dw_hdmi: Use display_info is_hdmi and has_audio

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 150 +++++++---------------
 1 file changed, 43 insertions(+), 107 deletions(-)

Comments

Diederik de Haas Sept. 13, 2024, 5:30 p.m. UTC | #1

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