Hmm. Kernel issue. Adding our experts here.

Looks similar to https://bugzilla.suse.com/show_bug.cgi?id=1196632

(In reply to Robert Herb from comment #0)

> [   15.627902] [drm:vc4_vec_bind [vc4]] *ERROR* Failed to get clock: -2
> [   15.627991] vc4-drm soc:gpu: failed to bind 3f806000.vec (ops vc4_vec_ops
> [vc4]): -2
> [   15.832274] vc4-drm soc:gpu: master bind failed: -2
> [   15.832343] vc4-drm: probe of soc:gpu failed with error -2

Indeed this is bsc#1196632

I have copied latest openSUSE-Leap-15.4-ARM-XFCE on my RPi 3B+ Rev 1.3 uSD card, 
I plugged HDMI cable and powered up the board. After a minute I was welcomed
with login dialog. But I don't see above vc4-drm errors, hm...

kernel-default 5.14.21-150400.11.2 
raspberrypi-firmware-dt 2021.11.19-150400.1.1

Which is the version of raspberrypi-firmware-dt that you have?

> Expected Results:  
> After boot graphics (in my case kodi) should appear

Maybe I don't look at the right place, but I don't see Kodi
supported in 15.4 https://software.opensuse.org/package/kodi

Hi,

I used the JeOS image: https://download.opensuse.org/distribution/leap/15.4/appliances/openSUSE-Leap-15.4-ARM-JeOS-raspberrypi.aarch64.raw.xz

I build kodi and some binary-addons on my own, it is running fine on the Pi (using gbm) with 15.3: https://build.opensuse.org/package/show/home:Herbster0815:HTPC/kodi

The firmware packages are the same as you have:
[10:59:33 @ Do Apr 07]mediapc@Kleinerbaer[~/]$rpm -qa | grep firmware
raspberrypi-firmware-dt-2021.11.19-150400.1.1.noarch
raspberrypi-firmware-2021.09.30-150400.2.1.noarch
raspberrypi-firmware-config-2021.09.30-150400.2.1.noarch
bcm43xx-firmware-20180314-150400.27.1.noarch
raspberrypi-eeprom-firmware-2021.04.29-150300.3.3.1.noarch
kernel-firmware-brcm-20220119-150400.2.1.noarch
[10:59:44 @ Do Apr 07]mediapc@Kleinerbaer[~/]$

"I have copied latest openSUSE-Leap-15.4-ARM-XFCE on my RPi 3B+ Rev 1.3 uSD card, 
I plugged HDMI cable and powered up the board. After a minute I was welcomed
with login dialog. But I don't see above vc4-drm errors, hm..."

Installed also the latest XFCE image https://download.opensuse.org/distribution/leap/15.4/appliances/openSUSE-Leap-15.4-ARM-XFCE-raspberrypi.aarch64.raw.xz
--> Same error, black screen

This also appears to affect SLE, so moving over there to get priorized there as well.

I also hit the issue on Tumbleweed, current images boot to a black screen here on a RPi 3B+ with those error messages.

Well, as Guillaume and me noted this is the same as bsc#1196632.
With P5 this is not going anywhere, you know.

What is the exact hardware version of your RPi 3B+?

Mine is a Raspberry 3 Model B Rev. 1.2

Hi,

On my RPi3B+, I see the problem with kernel 5.16.1 on Tumbleweed. IIRC 5.14 still worked. The kernel log says

> dmesg | grep drm
[    8.312548] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    8.683321] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    9.145586] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    9.372717] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    9.607678] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    9.742785] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[    9.961793] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   17.170555] systemd[1]: Starting Load Kernel Module drm...
[   17.405597] systemd[1]: modprobe@drm.service: Deactivated successfully.
[   17.407350] systemd[1]: Finished Load Kernel Module drm.
[   21.763096] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   21.963213] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   22.317886] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   22.373051] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[   22.373391] [drm:vc4_vec_bind [vc4]] *ERROR* Failed to get clock: -2
[   22.373522] vc4-drm soc:gpu: failed to bind 3f806000.vec (ops vc4_vec_ops [vc4]): -2
[   22.552164] vc4-drm soc:gpu: master bind failed: -2
[   22.552232] vc4-drm: probe of soc:gpu failed with error -2

which brings us to

 https://elixir.bootlin.com/linux/v5.17.3/source/drivers/gpu/drm/vc4/vc4_vec.c#L567

There's a call to devm_clk_get() that fails to retrieve some kind of standard clock. That line was added in 2016 by commit e4b81f8c74c8 ("drm/vc4: Add support for the VEC (Video Encoder) IP"). So it's presumably not a recently introduced bug.

Could this be an issue with out-dated firmware?

(In reply to Ivan Ivanov from comment #7)
> Well, as Guillaume and me noted this is the same as bsc#1196632.
> With P5 this is not going anywhere, you know.

P5 means "not evaluated". I reset it to request P1 and now also requested SHIP_STOPPER.

> What is the exact hardware version of your RPi 3B+?

The DT says "Raspberry Pi 3 Model B Plus Rev 1.3".

(In reply to Thomas Zimmermann from comment #11)
> Hi,
> 
> On my RPi3B+, I see the problem with kernel 5.16.1 on Tumbleweed. IIRC 5.14
> still worked.

15 SP4 is also affected and has 5.14, it might be a backport which triggered it.

> ...
> 
> Could this be an issue with out-dated firmware?

15 SP4 has 2021.09.30, Tumbleweed has 2022.03.01.

Hi, I will say it again. Please look here: bsc#1198061. 

I have sent fix upstream already.

https://lore.kernel.org/linux-clk/20220419084058.146509-1-iivanov@suse.de/

Oh, this one bsc#1196632

OBS is building test kernel package with the fix at the moment.

You can watch the build progress at
  https://build.opensuse.org/project/monitor?project=home%3Aiivanov%3Absc1198061-clks-sp4

(In reply to Ivan Ivanov from comment #15)
> Hi, I will say it again. Please look here: bsc#1198061. 
> 
> I have sent fix upstream already.
> 
> https://lore.kernel.org/linux-clk/20220419084058.146509-1-iivanov@suse.de/

Thank you so much.

(In reply to Ivan Ivanov from comment #17)
> OBS is building test kernel package with the fix at the moment.
> 
> You can watch the build progress at
>  
> https://build.opensuse.org/project/
> monitor?project=home%3Aiivanov%3Absc1198061-clks-sp4

I tried that (well, a build from IBS) and unfortunately it doesn't work either.
There is a new line in dmesg:

vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input1
debugfs: Directory '3f902000.hdmi' with parent 'vc4-hdmi' already present!
vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])

of_clk_hw_onecell_get: invalid index 15

[drm:vc4_vec_bind [vc4]] *ERROR* Failed to get clock: -2
vc4-drm soc:gpu: failed to bind 3f806000.vec (ops vc4_vec_ops [vc4]): -2
vc4-drm soc:gpu: master bind failed: -2
vc4-drm: probe of soc:gpu failed with error -2

(In reply to Fabian Vogt from comment #20)
> (In reply to Ivan Ivanov from comment #17)
> > OBS is building test kernel package with the fix at the moment.
> > 
> > You can watch the build progress at
> >  
> > https://build.opensuse.org/project/
> > monitor?project=home%3Aiivanov%3Absc1198061-clks-sp4
> 
> I tried that (well, a build from IBS) and unfortunately it doesn't work
> either.
> There is a new line in dmesg:
> 
> vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
> rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
> input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input1
> debugfs: Directory '3f902000.hdmi' with parent 'vc4-hdmi' already present!
> vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
> 
> of_clk_hw_onecell_get: invalid index 15
> 
> [drm:vc4_vec_bind [vc4]] *ERROR* Failed to get clock: -2
> vc4-drm soc:gpu: failed to bind 3f806000.vec (ops vc4_vec_ops [vc4]): -2
> vc4-drm soc:gpu: master bind failed: -2
> vc4-drm: probe of soc:gpu failed with error -2

Apparently this is because the raspberrypi-firmware provided DTB includes https://github.com/raspberrypi/linux/commit/d417d6684c205e678a72d00ab1182fe88d3c989b, but the kernel isn't ready for that yet (missing https://github.com/raspberrypi/linux/commit/86d395483476993ee8b93a02210966398462516c).

(In reply to Fabian Vogt from comment #20)
> (In reply to Ivan Ivanov from comment #17)
> > OBS is building test kernel package with the fix at the moment.
> > 
> > You can watch the build progress at
> >  
> > https://build.opensuse.org/project/
> > monitor?project=home%3Aiivanov%3Absc1198061-clks-sp4
> 
> I tried that (well, a build from IBS) and unfortunately it doesn't work
> either.

My bad. Missed one more thing. Sorry. Will prepare new package ASAP.

(In reply to Fabian Vogt from comment #22)

> Apparently this is because the raspberrypi-firmware provided DTB includes
> https://github.com/raspberrypi/linux/commit/
> d417d6684c205e678a72d00ab1182fe88d3c989b, but the kernel isn't ready for
> that yet (missing
> https://github.com/raspberrypi/linux/commit/
> 86d395483476993ee8b93a02210966398462516c).

Yep.

Hm, there is something fishy around raspberrypi-firmware-dt 
version 2021.11.19-150400.2.1

This was supposed to contain snapshot of device tree files 
from raspberrypi/linux from 2021.11.19 branch rpi-5.14.y

Commit [1] which change VEC clock from clk-2835 to clk-raspberrypi
was made on 29 Nov 2021??


[1] https://github.com/raspberrypi/linux/commit/7e72dd813a175ea7bf166655217ce60fbd7d4a21

(In reply to Ivan Ivanov from comment #25)
> Hm, there is something fishy around raspberrypi-firmware-dt 
> version 2021.11.19-150400.2.1
> 
> This was supposed to contain snapshot of device tree files 
> from raspberrypi/linux from 2021.11.19 branch rpi-5.14.y
> 
> Commit [1] which change VEC clock from clk-2835 to clk-raspberrypi
> was made on 29 Nov 2021??

On the rpi-5.14.y branch it was changed by 7e72dd813a175ea7bf166655217ce60fbd7d4a21 (resp. 42bfbdc50f407981afe33bbdbadc4f4a7b220ff7 for clk-rpi) already, from 2021-10-19.

> [1]
> https://github.com/raspberrypi/linux/commit/
> 7e72dd813a175ea7bf166655217ce60fbd7d4a21

(In reply to Fabian Vogt from comment #26)
> (In reply to Ivan Ivanov from comment #25)
> > Hm, there is something fishy around raspberrypi-firmware-dt 
> > version 2021.11.19-150400.2.1
> > 
> > This was supposed to contain snapshot of device tree files 
> > from raspberrypi/linux from 2021.11.19 branch rpi-5.14.y
> > 
> > Commit [1] which change VEC clock from clk-2835 to clk-raspberrypi
> > was made on 29 Nov 2021??
> 
> On the rpi-5.14.y branch it was changed by
> 7e72dd813a175ea7bf166655217ce60fbd7d4a21 (resp.
> 42bfbdc50f407981afe33bbdbadc4f4a7b220ff7 for clk-rpi) already, from
> 2021-10-19.

clk-raspberrypi driver changes are relevant before device tree changes.

Device tree changes was made on Nov 29, which is after the date which 
was used in our device tree package (Nov 10) This is what confuse me to think
that the issue is only in Tumbleweed, which uses much newer device tree version,
but this doesn't help me too much right now. :-|

Oh, I wanted to say "clk-raspberrypi driver changes are not relevant before device tree changes."

(In reply to Ivan Ivanov from comment #27)
> (In reply to Fabian Vogt from comment #26)
> > (In reply to Ivan Ivanov from comment #25)
> > > Hm, there is something fishy around raspberrypi-firmware-dt 
> > > version 2021.11.19-150400.2.1
> > > 
> > > This was supposed to contain snapshot of device tree files 
> > > from raspberrypi/linux from 2021.11.19 branch rpi-5.14.y
> > > 
> > > Commit [1] which change VEC clock from clk-2835 to clk-raspberrypi
> > > was made on 29 Nov 2021??
> > 
> > On the rpi-5.14.y branch it was changed by
> > 7e72dd813a175ea7bf166655217ce60fbd7d4a21 (resp.
> > 42bfbdc50f407981afe33bbdbadc4f4a7b220ff7 for clk-rpi) already, from
> > 2021-10-19.
> 
> clk-raspberrypi driver changes are relevant before device tree changes.
> 
> Device tree changes was made on Nov 29, which is after the date which
> was used in our device tree package (Nov 10)

Not sure what you mean. In the rpi-5.14.y branch, the device tree was changed on 2021-10-19, the same day as VEC clk got added to the clk-raspberrypi driver.

> This is what confuse me to think
> that the issue is only in Tumbleweed, which uses much newer device tree
> version,
> but this doesn't help me too much right now. :-|

Created attachment 858281 [details]
Rollback to platform VEC clock

Please test with this package and default kernel.

(In reply to Fabian Vogt from comment #29)

> Not sure what you mean. In the rpi-5.14.y branch, the device tree was
> changed on 2021-10-19, the same day as VEC clk got added to the
> clk-raspberrypi driver.

Mm, no, as you can see from the commit[1] below device tree 
was changed on 29 Nov 2021. Patch creation date was 19 Oct 2021.

Support for VEC was added to clk-raspberrypi on the same date
29 Nov 2021, which is after the date manifested by our 
raspberrypi-firmware-dt package 2021.11.19.


[1]
commit 7e72dd813a175ea7bf166655217ce60fbd7d4a21
Author:     Dom Cobley <popcornmix@gmail.com>
AuthorDate: Tue Oct 19 14:15:45 2021 +0100
Commit:     Dom Cobley <popcornmix@gmail.com>
CommitDate: Mon Nov 29 16:26:09 2021 +0000

    dt: Move VEC clock to clk-raspberrypi

[2]
commit 42bfbdc50f407981afe33bbdbadc4f4a7b220ff7
Author:     Dom Cobley <popcornmix@gmail.com>
AuthorDate: Tue Oct 19 14:13:53 2021 +0100
Commit:     Dom Cobley <popcornmix@gmail.com>
CommitDate: Mon Nov 29 16:26:08 2021 +0000

    clk-raspberrypi: Support VEC clock

Is anyone tested attachment #858281 [details]?

(In reply to Ivan Ivanov from comment #31)
> (In reply to Fabian Vogt from comment #29)
> 
> > Not sure what you mean. In the rpi-5.14.y branch, the device tree was
> > changed on 2021-10-19, the same day as VEC clk got added to the
> > clk-raspberrypi driver.
> 
> Mm, no, as you can see from the commit[1] below device tree 
> was changed on 29 Nov 2021. Patch creation date was 19 Oct 2021.
> 
> Support for VEC was added to clk-raspberrypi on the same date
> 29 Nov 2021, which is after the date manifested by our 
> raspberrypi-firmware-dt package 2021.11.19.

The get-from-git script uses the author date for the package
version. For some reason I get a different date (2021.11.16) for
the revision mentioned in the .changes file, not sure why. The
package update itself was ran a day after the commit date of the
commits.

> [1]
> commit 7e72dd813a175ea7bf166655217ce60fbd7d4a21
> Author:     Dom Cobley <popcornmix@gmail.com>
> AuthorDate: Tue Oct 19 14:15:45 2021 +0100
> Commit:     Dom Cobley <popcornmix@gmail.com>
> CommitDate: Mon Nov 29 16:26:09 2021 +0000
> 
>     dt: Move VEC clock to clk-raspberrypi
> 
> [2]
> commit 42bfbdc50f407981afe33bbdbadc4f4a7b220ff7
> Author:     Dom Cobley <popcornmix@gmail.com>
> AuthorDate: Tue Oct 19 14:13:53 2021 +0100
> Commit:     Dom Cobley <popcornmix@gmail.com>
> CommitDate: Mon Nov 29 16:26:08 2021 +0000
> 
>     clk-raspberrypi: Support VEC clock

(In reply to Ivan Ivanov from comment #30)
> Created attachment 858281 [details]
> Rollback to platform VEC clock
> 
> Please test with this package and default kernel.

Works with both the original and your patched kernel!
Except for the usual message about the already existing directory I couldn't spot any errors or warnings.

(In reply to Fabian Vogt from comment #34)
> Except for the usual message about the already existing directory I couldn't
> spot any errors or warnings.

I guess that's an issue Ivan already fixed once, but it wasn't merged to the upstream as the code being refactored at that time.

I am afraid that even with patched kernel SP4 needs raspberypi-firmware
package update. Because it turns out that current one don't have support
for clock 15 (RPI_FIRMWARE_VEC_CLK_ID). 

So, I think to just revert[1] in current raspberypi-firmware-dt in SP4.
This is what attached rpm do and seems to be enough to fix HDMI issue.

[1] dt: Move VEC clock to clk-raspberrypi

(In reply to Ivan Ivanov from comment #36)
> I am afraid that even with patched kernel SP4 needs raspberypi-firmware
> package update. Because it turns out that current one don't have support
> for clock 15 (RPI_FIRMWARE_VEC_CLK_ID). 
> 
> So, I think to just revert[1] in current raspberypi-firmware-dt in SP4.
> This is what attached rpm do and seems to be enough to fix HDMI issue.
> 
> [1] dt: Move VEC clock to clk-raspberrypi

What are the up and downsides of using the vec clk through the FW driver
instead of directly, i.e. adding RPI_FIRMWARE_VEC_CLK_ID instead of reverting
the change in the DTB?

While I'd argue that it's probably safer to stay with the old way at this
point, it's not like the current state received much testing either, so the
risk is pretty much the same.

(In reply to Fabian Vogt from comment #37)
> (In reply to Ivan Ivanov from comment #36)
> > I am afraid that even with patched kernel SP4 needs raspberypi-firmware
> > package update. Because it turns out that current one don't have support
> > for clock 15 (RPI_FIRMWARE_VEC_CLK_ID). 
> > 
> > So, I think to just revert[1] in current raspberypi-firmware-dt in SP4.
> > This is what attached rpm do and seems to be enough to fix HDMI issue.
> > 
> > [1] dt: Move VEC clock to clk-raspberrypi
> 
> What are the up and downsides of using the vec clk through the FW driver
> instead of directly, i.e. adding RPI_FIRMWARE_VEC_CLK_ID instead of reverting
> the change in the DTB?

Hm, exactly what is written above:
1. There is no upstream Linux support for this clock. 
2. RaspberryPi firmware package have to be updated too.

(In reply to Ivan Ivanov from comment #38)
> (In reply to Fabian Vogt from comment #37)
> > (In reply to Ivan Ivanov from comment #36)
> > > I am afraid that even with patched kernel SP4 needs raspberypi-firmware
> > > package update. Because it turns out that current one don't have support
> > > for clock 15 (RPI_FIRMWARE_VEC_CLK_ID). 
> > > 
> > > So, I think to just revert[1] in current raspberypi-firmware-dt in SP4.
> > > This is what attached rpm do and seems to be enough to fix HDMI issue.
> > > 
> > > [1] dt: Move VEC clock to clk-raspberrypi
> > 
> > What are the up and downsides of using the vec clk through the FW driver
> > instead of directly, i.e. adding RPI_FIRMWARE_VEC_CLK_ID instead of reverting
> > the change in the DTB?
> 
> Hm, exactly what is written above:
> 1. There is no upstream Linux support for this clock.
> 2. RaspberryPi firmware package have to be updated too.

Indeed, that's something that should be avoided.

I am going to send SR for raspberrypi-firmware-dt package which 
revert VEC clock changes. 3, 2, 1...

firmware package is merged for the next build

Can confirm, the attached firmware package fixes the issue. Also with the kernel from Kernel:Stable.Backport-Repo.
Thx for fixing!

Thanks, marking as fixed. Note: Not sure how we should handle Leap 15.4.

Verified in 123.1