Hi Stefan On Fri, 25 Oct 2024 at 14:36, Stefan Wahren <wahrenst@xxxxxxx> wrote: > > Hi Dave, > > Am 23.10.24 um 17:22 schrieb Dave Stevenson: > > On Sat, 19 Oct 2024 at 10:34, Stefan Wahren <wahrenst@xxxxxxx> wrote: > >> Hi, > >> > >> Am 17.10.24 um 17:59 schrieb Maxime Ripard: > >>> On Thu, Oct 17, 2024 at 05:26:46PM GMT, Stefan Wahren wrote: > >>>> Am 17.10.24 um 16:27 schrieb 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@xxxxxxx> wrote: > >>>>>>> Hi Dave, > >>>> ... > >>>>>>> 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. > >>>> Okay, i tried this and it works better (HDMI resumes fast), but it also > >>>> triggers a lot of WARN > >>> vc4_plane_reset deviates from the helper there: > >>> https://elixir.bootlin.com/linux/v6.11.3/source/drivers/gpu/drm/drm_atomic_state_helper.c#L326 > >>> > >>> We should adjust it. > >>> > >>>> and the "doesn't support RGB ..." warnings are still there. > >>>> > >>>> I pushed my changes to the branch and attached the dmesg output. > >>> I can't help you there, it doesn't make sense to me. The EDID should be correct. > >> Maybe I should clarify that I provided the EDID from the X11 log during > >> normal boot (good case). I wasn't aware how to dump the EDID during the > >> suspend. > >> > >> I tested with the new branch and these warning doesn't always occurs > >> during resume. So it seems to be timing related. > >> > >> AFAIU the EDID is read via I2C DDC and the attached clock in this case > >> is VPU clock. Correct? > > Yes. It's derived from the core clock, which is often referred to as > > the VPU clock. > > > >> So I added the following to the config.txt > >> > >> force_turbo=1 > >> > >> After that I wasn't able to reproduce these HDMI Sink warnings. > >> > >> Is it possible that the I2C data get corrupted by VPU clock changes? > > It shouldn't, but that doesn't mean that the monitor doesn't like the > > clock change. It should never exceed the 100kHz rate that the HDMI/DVI > > spec states (HDMI v1.4 spec section 8.4.1). > > > > If you set drm module parameter "debug" to 0x04, then DRM should log > > the hotplug handling and EDID parsing in the kernel log. > > The HDMI spec does say that the HDMI sink (ie monitor) can clock > > stretch the DDC transaction. It doesn't state a maximum amount of time > > that it can stretch for, and most I2C drivers will time out > > transactions after some period. The DRM logging would probably show > > something under these conditions though. > I reproduced it with drm.debug=0x4 [1]. The issue occured 3 times after > 216.395170. > > Not sure this is helpful. > > Best regards > > [1] - https://pastebin.com/TCPqXmpa Based on that log I think your force_turbo=1 is a red-herring, or at least needs further investigation. Is this on a 3B, or 3B+? Snippets from your log as we resume: [ 216.797764] PM: suspend exit [ 216.800473] lan78xx 1-1.1.1:1.0 eth0: Link is Down [ 216.804503] vc4-drm soc:gpu: [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:33:HDMI-A-1] [ 216.804584] vc4-drm soc:gpu: [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:33:HDMI-A-1] status updated from connected to disconnected [ 216.804648] vc4-drm soc:gpu: [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:33:HDMI-A-1] disconnected - So hotplug has signalled disconnected ... [ 216.816990] vc4-drm soc:gpu: [drm:drm_mode_setcrtc] [CONNECTOR:33:HDMI-A-1] [ 216.817079] vc4-drm soc:gpu: [drm:drm_atomic_helper_connector_hdmi_check] Trying with a 8 bpc output [ 216.817107] vc4-drm soc:gpu: [drm:drm_atomic_helper_connector_hdmi_check] Trying RGB output format [ 216.817166] vc4-drm soc:gpu: [drm:drm_atomic_helper_connector_hdmi_check] RGB Format, checking the constraints. [ 216.817186] vc4-drm soc:gpu: [drm] HDMI Sink doesn't support RGB, something's wrong. - This is correct as the output is disconnected ... [ 227.075847] vc4-drm soc:gpu: [drm:update_display_info.part.0] [CONNECTOR:33:HDMI-A-1] HDMI: DVI dual 0, max TMDS clock 0 kHz [ 227.075912] vc4-drm soc:gpu: [drm:update_display_info.part.0] [CONNECTOR:33:HDMI-A-1] ELD monitor HP ZR2440w [ 227.075942] vc4-drm soc:gpu: [drm:update_display_info.part.0] [CONNECTOR:33:HDMI-A-1] HDMI: latency present 0 0, video latency 0 0, audio latency 0 0 [ 227.075971] vc4-drm soc:gpu: [drm:update_display_info.part.0] [CONNECTOR:33:HDMI-A-1] ELD size 36, SAD count 1 [ 227.076014] vc4-drm soc:gpu: [drm:output_poll_execute] [CONNECTOR:33:HDMI-A-1] status updated from disconnected to connected [ 227.076040] vc4-drm soc:gpu: [drm:output_poll_execute] [CONNECTOR:33:HDMI-A-1] epoch counter 3 -> 4 [ 227.076072] vc4-drm soc:gpu: [drm:drm_sysfs_hotplug_event] generating hotplug event [ 227.076170] vc4-drm soc:gpu: [drm:drm_client_dev_hotplug] fbdev: ret=0 - We now get a connect again. The 10 second interval is why I'm suspecting you're on a 3B - we have no interrupts for the GPIO used there (expgpio 4), whereas we do on 3B+ (gpio 28). The poll period is 10seconds in the absence of interrupts. On that suspend you were suspended for 16 seconds. Previous suspends were for 9 and 12 seconds. I suspect your monitor goes to sleep at around 15 seconds and is doing things to hotplug at that point. We've seen it on a couple of monitors here, and with Wayfire or labwc it can wake the display back up again. We haven't come up with a good solution to that one yet other than just ignoring hotplug. Dave
