vc4: HDMI Sink doesn't support RGB, something's wrong.
Stefan Wahren
wahrenst at gmx.net
Fri Oct 25 17:12:18 UTC 2024
Hi Dave,
Am 25.10.24 um 18:56 schrieb Dave Stevenson:
> On Fri, 25 Oct 2024 at 17:31, Stefan Wahren <wahrenst at gmx.net> wrote:
>> Hi Dave,
>>
>> Am 25.10.24 um 16:38 schrieb Dave Stevenson:
>>> Hi Stefan
>>>
>>> On Fri, 25 Oct 2024 at 14:36, Stefan Wahren <wahrenst at gmx.net> wrote:
>> ...
>>> 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+?
>> Definitely a 3B+ from the year 2017 (mainline devicetree)
>>> 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
>> AFAIK only the 3B+ has a Microchip LAN7800
> Absolutely right. I was heading down the wrong track there.
>
>>> [ 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.
>> gpiochip0 - 54 lines:
>> line 0: "ID_SDA" unused input active-high
>> line 1: "ID_SCL" unused input active-high
>> line 2: "SDA1" unused input active-high
>> line 3: "SCL1" unused input active-high
>> ...
>> line 27: "GPIO27" unused input active-high
>> line 28: "HDMI_HPD_N" "hpd" input active-low [used]
>> line 29: "STATUS_LED_G" "ACT" output active-high [used]
>> line 30: "CTS0" unused input active-high
> In which case I'm totally bemused by the significant delay.
> I'm not aware of any path in the software that can create this effect,
> so it would point to the connected device (ie HDMI switch).
Another cause could be related to these messages from log:
[ 167.371865] NOHZ tick-stop error: local softirq work is pending,
handler #08!!!
[ 186.932178] NOHZ tick-stop error: local softirq work is pending,
handler #08!!!
Maybe this comes from the lan78xx driver? This messages doesn't occur in
the bad case.
>
>> Sorry, I missed a possible important information. The Raspberry Pi 3B+
>> is not directly connected to the display. There is a passive Logilink
>> HDMI switch in between.
> Is it truly passive? That's unusual for anything handling high
> bandwidth signals such as HDMI. Have you got a product link?
Maybe passive is the wrong wording here. I meant not powered by a power
supply.
http://www.logilink.de/media/datasheets/HD0006.pdf
> There is a low current 5V supply available from all HDMI sources
> (intended for the EDID EEPROM) which can power some of these devices.
>
> We have also seen KVM switches do odd things when they lose the input
> signal, as they try to find another active input.
>
>>> On that suspend you were suspended for 16 seconds. Previous suspends
>>> were for 9 and 12 seconds.
>> I waited 20 seconds multiple times with and without force_hdmi and
>> wasn't able to reproduce it more reliable. But I agree this not a prove.
>>
>> Maybe this is caused by the HDMI switch. At the end this is not
>> critical. My only concern was that this is an in suspend/resume handling.
>>
>> I will try need to investigate this ...Thanks for your help. Stefan
> No problem. I'm interested in solving this one too.
>
> Dave
More information about the dri-devel
mailing list