Bugzilla – Bug 1217512
[RPi4] kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517
Last modified: 2024-01-31 12:10:21 UTC
## Observation openQA test in scenario opensuse-Tumbleweed-JeOS-for-RPi-aarch64-jeos@RPi4 fails in [journal_check](https://openqa.opensuse.org/tests/3760808/modules/journal_check/steps/11) On Raspberry Pi 4, with latest updates, we now have the following kernel trace in journal: kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517 Related updates: raspberrypi-firmware (2023.04.25 -> 2023.11.21) raspberrypi-firmware-config (2023.04.25 -> 2023.11.21) raspberrypi-firmware-dt (2023.05.02 -> 2023.11.21) ## Test suite description Maintainer: fvogt, mnowak Start JeOS from the HDD image, configure it using the firstboot wizard and then run basic tests. console=tty0 added as needed for aarch64. ## Reproducible Fails since (at least) Build [20231123](https://openqa.opensuse.org/tests/3754946) ## Expected result Last good: [20231122](https://openqa.opensuse.org/tests/3750512) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensuse&flavor=JeOS-for-RPi&machine=RPi4&test=jeos&version=Tumbleweed)
Adding DRM experts.
-517 is -EPROBE_DEFER, and this itself isn't wrong. (The driver can use dev_err_probe() for hiding the EPROBE_DEFER error, though.) Doesn't the device work afterward at all?
(In reply to Takashi Iwai from comment #2) > -517 is -EPROBE_DEFER, and this itself isn't wrong. (The driver can use > dev_err_probe() for hiding the EPROBE_DEFER error, though.) > > Doesn't the device work afterward at all? It has been detected on openQA headless RPi4 and my hdmi cable is broken, so I cannot test on my 2nd RPi4. @Ivan, would you be able to test?
(In reply to Takashi Iwai from comment #2) > -517 is -EPROBE_DEFER, and this itself isn't wrong. (The driver can use > dev_err_probe() for hiding the EPROBE_DEFER error, though.) > > Doesn't the device work afterward at all? I'm afraid not, the HDMI output doesn't work.
I checked this issue on my RPi compute module 4 which connected to monitor via HDMI. compute:~ # journalctl | grep PCM Nov 02 00:01:01 localhost kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517 HDMI is not working, no signal at all.
We don't see any issues in the nightly IGT tests so this is likely a firmware or DT issue. Can someone test by rolling back the DT but not the firmware and config packages? That way we can isolate the problem further.
Yes, as suspected update of raspberrypi-firmware-dt makes thing break. I will have to take closer look why this is happening...
My Raspberry Pi 4 running Tubleweed is sadly also affected by the problem. Since updating to raspberrypi-firmware-dt-2023.11.21-1.1.noarch I have no video signal via HDMI. After adding nomodeset to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and then running grub2-mkconfig -o /boot/grub2/grub.cfg, I have HDMI video, but still no audio. The corresponding messages in dmesg are the following (AFAIK): vc4_hdmi fef00700.hdmi: Could not register PCM component: -517 platform gpu: deferred probe pending My HDMI output was able to produce proper video and audio signal up until raspberrypi-firmware-dt-2023.04.25-2.1, so I finally downgraded to these packages from leap in order to regain HDMI video and audio support: raspberrypi-eeprom-2023.01.11-2.1.noarch.rpm raspberrypi-eeprom-firmware-2023.01.11-2.1.noarch.rpm raspberrypi-firmware-2023.01.18-1.1.noarch.rpm raspberrypi-firmware-config-2023.01.18-1.1.noarch.rpm raspberrypi-firmware-dt-2023.01.20-1.1.noarch.rpm (BTW, is there any history-like repository for tubleweed/aarch64 where I can still found 2023.04.25-2.1 ?) Anyway, Red Hat users are also fighting the problem: https://bugzilla.redhat.com/show_bug.cgi?id=2246428 And they say, the root cause might be this patch: https://github.com/raspberrypi/linux/commit/0491a0aecb999b1a013ad4a6ad3816c535ac6e73
Thank you, Tamás! Yep, this is it. I am afraid that vendor changes around new RPi5 makes new device trees unusable without corresponding changes in DMA driver, which I don't see to happen soon. Guillaume, I think the safest resolution for the moment is to revert to prior device tree version.
(In reply to Ivan Ivanov from comment #9) > Thank you, Tamás! Yep, this is it. > > I am afraid that vendor changes around new RPi5 makes new > device trees unusable without corresponding changes in DMA > driver, which I don't see to happen soon. > > Guillaume, I think the safest resolution for the moment is > to revert to prior device tree version. Could we just revert DMA patches, maybe?
(In reply to Guillaume GARDET from comment #10) > Could we just revert DMA patches, maybe? Ok, Let me check ...
(In reply to Ivan Ivanov from comment #11) > (In reply to Guillaume GARDET from comment #10) > > > Could we just revert DMA patches, maybe? > > Ok, Let me check ... I am ashamed how easy this was :-| SR#1132457 is fixing this issue for me. Thank you, Tamás! https://build.opensuse.org/request/show/1132457
(In reply to Ivan Ivanov from comment #12) > (In reply to Ivan Ivanov from comment #11) > > (In reply to Guillaume GARDET from comment #10) > > > > > Could we just revert DMA patches, maybe? > > > > Ok, Let me check ... > > I am ashamed how easy this was :-| > > SR#1132457 is fixing this issue for me. > > Thank you, Tamás! > > https://build.opensuse.org/request/show/1132457 Thank you very-very much for fixing it!
Closing.