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@xxxxxxx> wrote: > > > > Hi Dave, > > > > Am 15.10.24 um 11:32 schrieb Dave Stevenson: > > > On Mon, 14 Oct 2024 at 22:16, Stefan Wahren <wahrenst@xxxxxxx> wrote: > > >> > > >> Am 14.10.24 um 12:54 schrieb Dave Stevenson: > > >>> On Mon, 14 Oct 2024 at 10:04, Maxime Ripard <mripard@xxxxxxxxxx> 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@xxxxxxx> 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@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
Attachment:
signature.asc
Description: PGP signature
