vc4: HDMI Sink doesn't support RGB, something's wrong.

[Dave Stevenson]

Hi Stefan

On Tue, 15 Oct 2024 at 22:13, Stefan Wahren <wahrenst at gmx.net> wrote:
>
> Hi Dave,
>
> Am 15.10.24 um 11:32 schrieb Dave Stevenson:
> > On Mon, 14 Oct 2024 at 22:16, Stefan Wahren <wahrenst at gmx.net> wrote:
> >>
> >> Am 14.10.24 um 12:54 schrieb Dave Stevenson:
> >>> On Mon, 14 Oct 2024 at 10:04, Maxime Ripard <mripard at kernel.org> wrote:
> >>>> Hi,
> >>>>
> >>>> On Sun, Oct 13, 2024 at 09:57:58PM GMT, Stefan Wahren wrote:
> >>>>> Am 13.10.24 um 21:11 schrieb Dave Stevenson:
> >>>>>> Hi Stefan.
> >>>>>>
> >>>>>> On Sun, 13 Oct 2024, 18:19 Stefan Wahren, <wahrenst at gmx.net> wrote:
> >>>>>>
> >>>>>>       Hi,
> >>>>>>
> >>>>>>       i recently switch for my suspend2idle tests from Raspberry Pi Bullseye
> >>>>>>       to Bookworm. After that testing suspend2idle shows a new warning
> >>>>>>       which i
> >>>>>>       never saw before:
> >>>>>>
> >>>>>>       HDMI Sink doesn't support RGB, something's wrong.
> >>>>>>
> >>>>>>
> >>>>>> Can you provide the edid of your display please?
> >> ...
> >>>>>
> >>>>> The failure is coming from sink_supports_format_bpc()[1], but the flag
> >>>>> for DRM_COLOR_FORMAT_RGB444 should have been set from
> >>>>> update_display_info()[2] parsing the EDID.
> >>>>>
> >>>>> Loading that EDID in via drm.edid_firmware has given me a console at
> >>>>> 1920x1200 at 60 without any issues, so I'm a little confused as to what
> >>>>> is going on.
> >> Since this warning only occurs on resume and not during normal boot, i
> >> would assume there is no issue with EDID. Maybe the flag get lost. I
> >> should have mention that X11 doesn't recover in this case and the
> >> display stays black.
> > Ah, I hadn't realised you meant it was only on resume that it didn't
> > come back up.
> >
> > I suspect you're right that the state gets lost somehow. It may be
> > triggered by the returning of connector_status_unknown on the
> > connector, but haven't traced it back.
> >
> > If I pick up your patches, what do I need to add to replicate this?
> i prepared a branch for you, which contains the latest suspend2idle patches:
>
> https://github.com/lategoodbye/linux-dev/commits/v6.12-pm/
>
> Steps:
> 1. Flash latest Raspberry Pi OS (32 bit) on SD card
> 2. Build Kernel from repo above with arm/multi_v7_defconfig
> 3. Replace Kernel, modules + DTB on SD card with build ones
> 4. add the following to confix.txt
> device_tree=bcm2837-rpi-3-b-plus.dtb
> enable_uart=1
> 5. change/add the following to cmdline.txt
> console=ttyS1,115200
> no_console_suspend=1
> 6. connect the following devices to Raspberry Pi 3 B+ :
> USB mouse
> USB keyboard
> HDMI monitor
> Debug UART adapter (USB side to PC)
> 7. Power on board and boot into X11
> 8. Change to root
> 9. Enable wakeup for ttyS1

So I remember for next time
echo enabled > /sys/class/tty/ttyS1/power/wakeup

> 10. Trigger suspend to idle via X11 (echo freeze > /sys/power/state)
> 11. Wakeup Raspberry Pi via Debug UART

I don't get the error you are seeing, but I also don't get the display resuming.
pm has obviously killed the power to the HDMI block, and it has the
reset values in as can be seen via /sys/kernel/debug/dri/0/hdmi_regs.
Nothing in the driver restores these registers, and I'm not sure if it
is meant to do so.
Run kmstest or similar from this state and the change of mode
reprogrammes the blocks so we get the display back again.

I've also enabled CONFIG_DRM_LOAD_EDID_FIRMWARE so that I can use your
EDID, and get the same results.

Knee-capping the HDMI block on suspend seems an unlikely mechanism to
work reliably. On the more recent Pis there is a need to be quite
careful in disabling the pipeline to avoid getting data stuck in
FIFOs.
I feel I must be missing something here.

  Dave