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

[Maxime Ripard]

On Wed, Oct 16, 2024 at 07:16:43PM GMT, Dave Stevenson wrote:
> 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.

I think we're probably missing calls to drm_mode_config_helper_suspend and
drm_mode_config_helper_resume.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20241017/a59e1c2e/attachment.sig>