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
Dave
