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

[Stefan Wahren]

Hi Dave,

Am 23.10.24 um 17:22 schrieb Dave Stevenson:
> On Sat, 19 Oct 2024 at 10:34, Stefan Wahren <wahrenst at gmx.net> 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 at gmx.net> 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