[PATCH] platform/raspberrypi: vchiq: register bus at subsys_initcall

[PATCH] platform/raspberrypi: vchiq: register bus at subsys_initcall

[Martin Wetterwald]

Since the VCHIQ interface was moved out of staging, its bus is no longer
guaranteed to be registered before its client drivers. bcm2835-audio,
still in drivers/staging, registers at device_initcall level and now
runs first:

  Driver 'bcm2835-audio' was unable to register with bus_type
  'vchiq-bus' because the bus was not initialized.

Register the bus and the platform driver at subsys_initcall so the bus
exists before any client driver, independently of link order. The
platform driver probe already returns -EPROBE_DEFER while the firmware
is not ready, so probing earlier is safe. When built as modules, this is
equivalent to module_init() and nothing changes.

Tested on Raspberry Pi 1B rev2, 1B+, 2B, 3B and 4B with VCHIQ and
bcm2835-audio both builtin and both as modules.

Fixes: aa125180c673 ("platform/raspberrypi: Destage VCHIQ interface")
Reported-by: Martin Wetterwald <martin@wetterwald.eu>
Link: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
Closes: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
Signed-off-by: Martin Wetterwald <martin@wetterwald.eu>
---
 drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
index e78641703252..d35f5ac5c2e2 100644
--- a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
+++ b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
@@ -1462,7 +1462,7 @@ static int __init vchiq_driver_init(void)
 
 	return ret;
 }
-module_init(vchiq_driver_init);
+subsys_initcall(vchiq_driver_init);
 
 static void __exit vchiq_driver_exit(void)
 {
-- 
2.55.0

Re: [PATCH] platform/raspberrypi: vchiq: register bus at subsys_initcall

[Jai Luthra]

Hi Martin,

Thanks for the quick fix.

Quoting Martin Wetterwald (2026-10-13 18:44:35)
> Since the VCHIQ interface was moved out of staging, its bus is no longer
> guaranteed to be registered before its client drivers. bcm2835-audio,
> still in drivers/staging, registers at device_initcall level and now
> runs first:
> 
>   Driver 'bcm2835-audio' was unable to register with bus_type
>   'vchiq-bus' because the bus was not initialized.
> 
> Register the bus and the platform driver at subsys_initcall so the bus
> exists before any client driver, independently of link order. The
> platform driver probe already returns -EPROBE_DEFER while the firmware
> is not ready, so probing earlier is safe. When built as modules, this is
> equivalent to module_init() and nothing changes.
> 
> Tested on Raspberry Pi 1B rev2, 1B+, 2B, 3B and 4B with VCHIQ and
> bcm2835-audio both builtin and both as modules.
> 
> Fixes: aa125180c673 ("platform/raspberrypi: Destage VCHIQ interface")
> Reported-by: Martin Wetterwald <martin@wetterwald.eu>
> Link: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
> Closes: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
> Signed-off-by: Martin Wetterwald <martin@wetterwald.eu>

Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>

Thanks,
  Jai

> ---
>  drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> index e78641703252..d35f5ac5c2e2 100644
> --- a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> +++ b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> @@ -1462,7 +1462,7 @@ static int __init vchiq_driver_init(void)
>  
>  	return ret;
>  }
> -module_init(vchiq_driver_init);
> +subsys_initcall(vchiq_driver_init);
>  
>  static void __exit vchiq_driver_exit(void)
>  {
> -- 
> 2.55.0
>

Re: [PATCH] platform/raspberrypi: vchiq: register bus at subsys_initcall

[Gaston Gonzalez]

On Tue Oct 13, 2026 at 10:14 AM -03, Martin Wetterwald wrote:
> Since the VCHIQ interface was moved out of staging, its bus is no longer
> guaranteed to be registered before its client drivers. bcm2835-audio,
> still in drivers/staging, registers at device_initcall level and now
> runs first:
>
>   Driver 'bcm2835-audio' was unable to register with bus_type
>   'vchiq-bus' because the bus was not initialized.
>
> Register the bus and the platform driver at subsys_initcall so the bus
> exists before any client driver, independently of link order. The
> platform driver probe already returns -EPROBE_DEFER while the firmware
> is not ready, so probing earlier is safe. When built as modules, this is
> equivalent to module_init() and nothing changes.
>
> Tested on Raspberry Pi 1B rev2, 1B+, 2B, 3B and 4B with VCHIQ and
> bcm2835-audio both builtin and both as modules.
>
> Fixes: aa125180c673 ("platform/raspberrypi: Destage VCHIQ interface")
> Reported-by: Martin Wetterwald <martin@wetterwald.eu>
> Link: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
> Closes: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
> Signed-off-by: Martin Wetterwald <martin@wetterwald.eu>
> ---
>  drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> index e78641703252..d35f5ac5c2e2 100644
> --- a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> +++ b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> @@ -1462,7 +1462,7 @@ static int __init vchiq_driver_init(void)
>  
>  	return ret;
>  }
> -module_init(vchiq_driver_init);
> +subsys_initcall(vchiq_driver_init);
>  
>  static void __exit vchiq_driver_exit(void)
>  {

Hi,

For Raspberry Pi Zero v1.3:

Tested-by: Gaston Gonzalez <gascoar@gmail.com>

Test setup:

- Branch: patch manually applied in staging-next over commit ec1ecf4f23c5
- Setup: RPi Zero v1.3 connected to a HDMI monitor
- OS: standard raspbian with the desktop environment enabled
- Driver built both as a module and built-in.
- The following command was run to test the sound: 'speaker-test -t wav -c 2'
- Result: Both HDMI audio channels worked correctly

I’d be happy to run any additional tests if needed.

Regards,

Gaston

Re: [PATCH] platform/raspberrypi: vchiq: register bus at subsys_initcall

[Martin Wetterwald]

On Thu, Oct 15, 2026 at 11:25 PM Gaston Gonzalez <gascoar@gmail.com> wrote:
> Hi,
>
> For Raspberry Pi Zero v1.3:
>
> Tested-by: Gaston Gonzalez <gascoar@gmail.com>
>
> Test setup:
>
> - Branch: patch manually applied in staging-next over commit ec1ecf4f23c5
> - Setup: RPi Zero v1.3 connected to a HDMI monitor
> - OS: standard raspbian with the desktop environment enabled
> - Driver built both as a module and built-in.
> - The following command was run to test the sound: 'speaker-test -t wav -c 2'
> - Result: Both HDMI audio channels worked correctly

Hello Gaston,
Thanks very much for your test!
It's great to have variety in tests because I don't have the Pi Zero, and I
didn't test it through HDMI, I tested through the Headphones jack (which
doesn't exist on the Pi Zero).

Did you also also reproduce the bug without adding my patch?
If the bug is present, cat /proc/asound/cards should reveal bcm2835_hdmi and
bcm2835_headphones are both not present. And you should see this in the dmesg:
> Driver 'bcm2835-audio' was unable to register with bus_type 'vchiq-bus' because the bus was not initialized.

Regarding your test: there are two ways for the sound to go through the HDMI
port:
- One is through the bcm2835-audio driver (using VCHIQ)
- The other way is through the vc4-hdmi (bypassing VCHIQ)

  # cat /proc/asound/cards
   0 [vc4hdmi        ]: vc4-hdmi - vc4-hdmi
                        vc4-hdmi
   1 [HDMI           ]: bcm2835_hdmi - bcm2835 HDMI
                        bcm2835 HDMI
   2 [Headphones     ]: bcm2835_headpho - bcm2835 Headphones
                        bcm2835 Headphones

Can you make sure that your HDMI sound is really using bcm2835_hdmi ?
If your sound happens to actually go through vc4-hdmi, then you are not testing
my patch. If you can't see the bcm2835_hdmi, you just need to add:

  snd_bcm2835.enable_hdmi=1

to your kernel command line if the driver is built in, or to the modprobe
command as module parameter.

> I’d be happy to run any additional tests if needed.

It would be interesting to test other "clients" of the VCHIQ bus (because I
only tested bcm2835-audio).
But I've just noticed that bcm2835-camera doesn't exist anymore (it was using
VCHIQ via VCHIQ_MMAL).
If I understand correctly, if VCHIQ_MMAL is still there, it's because the
bcm2835-isp and bcm2835-codec drivers will be upstreamed in the future, but
there is not current "client" in the kernel as far as I understand.

The only remaining thing I can think of is /dev/vchiq (CONFIG_VCHIQ_CDEV).

Thanks again for the tests!
Martin

Re: [PATCH] platform/raspberrypi: vchiq: register bus at subsys_initcall

[Gaston Gonzalez]

On Fri Oct 16, 2026 at 6:00 AM -03, Martin Wetterwald wrote:
> On Thu, Oct 15, 2026 at 11:25 PM Gaston Gonzalez <gascoar@gmail.com> wrote:
>> Hi,
>>
>> For Raspberry Pi Zero v1.3:
>>
>> Tested-by: Gaston Gonzalez <gascoar@gmail.com>
>>
>> Test setup:
>>
>> - Branch: patch manually applied in staging-next over commit ec1ecf4f23c5
>> - Setup: RPi Zero v1.3 connected to a HDMI monitor
>> - OS: standard raspbian with the desktop environment enabled
>> - Driver built both as a module and built-in.
>> - The following command was run to test the sound: 'speaker-test -t wav -c 2'
>> - Result: Both HDMI audio channels worked correctly
>
> Hello Gaston,
> Thanks very much for your test!
> It's great to have variety in tests because I don't have the Pi Zero, and I
> didn't test it through HDMI, I tested through the Headphones jack (which
> doesn't exist on the Pi Zero).
>
> Did you also also reproduce the bug without adding my patch?
> If the bug is present, cat /proc/asound/cards should reveal bcm2835_hdmi and
> bcm2835_headphones are both not present. And you should see this in the dmesg:
>> Driver 'bcm2835-audio' was unable to register with bus_type 'vchiq-bus' because the bus was not initialized.
>
> Regarding your test: there are two ways for the sound to go through the HDMI
> port:
> - One is through the bcm2835-audio driver (using VCHIQ)
> - The other way is through the vc4-hdmi (bypassing VCHIQ)
>
>   # cat /proc/asound/cards
>    0 [vc4hdmi        ]: vc4-hdmi - vc4-hdmi
>                         vc4-hdmi
>    1 [HDMI           ]: bcm2835_hdmi - bcm2835 HDMI
>                         bcm2835 HDMI
>    2 [Headphones     ]: bcm2835_headpho - bcm2835 Headphones
>                         bcm2835 Headphones
>
Hi Martin,

cat /proc/asound/cards shows only 'vc4-hdmi'.

After adding the kernel command line you pointed out, the bcm2835_hdmi
interface now appears.

The default interface seems to be vc4-hdmi. I could switch to bcm2835 in
alsamixer, and repeating the test in that conditions works. However,
speaker-test seems to take the vc4-hdmi interface nevertheless.

Running 'speaker-test -t wav -D plughw:1,0 -c 2' crash the system, so
thinks seem not to be working with that interface.

Im trying to debug what happens in that condition; I will need a couple
of days I guess. So far, this is what I could check.

Any feedback on the test or debugging would be appreciated.

Regards,

Gaston


> Can you make sure that your HDMI sound is really using bcm2835_hdmi ?
> If your sound happens to actually go through vc4-hdmi, then you are not testing
> my patch. If you can't see the bcm2835_hdmi, you just need to add:
>
>   snd_bcm2835.enable_hdmi=1
>
> to your kernel command line if the driver is built in, or to the modprobe
> command as module parameter.
>
>> I’d be happy to run any additional tests if needed.
>
> It would be interesting to test other "clients" of the VCHIQ bus (because I
> only tested bcm2835-audio).
> But I've just noticed that bcm2835-camera doesn't exist anymore (it was using
> VCHIQ via VCHIQ_MMAL).
> If I understand correctly, if VCHIQ_MMAL is still there, it's because the
> bcm2835-isp and bcm2835-codec drivers will be upstreamed in the future, but
> there is not current "client" in the kernel as far as I understand.
>
> The only remaining thing I can think of is /dev/vchiq (CONFIG_VCHIQ_CDEV).
>
> Thanks again for the tests!
> Martin

Re: [PATCH] platform/raspberrypi: vchiq: register bus at subsys_initcall

[Martin Wetterwald]

On Sun, Oct 18, 2026 at 9:53 PM Gaston Gonzalez <gascoar@gmail.com> wrote:

> Running 'speaker-test -t wav -D plughw:1,0 -c 2' crash the system, so
> thinks seem not to be working with that interface.
>
> Im trying to debug what happens in that condition; I will need a couple
> of days I guess. So far, this is what I could check.
>
> Any feedback on the test or debugging would be appreciated.

Hi Gaston,
Thanks for digging into this.

The patch only changes when the VCHIQ bus and driver are registered during
boot. So it's enough to check these two cases to validate the patch:
- without my patch: dmesg shows the "unable to register with bus_type
  'vchiq-bus'" error, and bcm2835_hdmi is absent from /proc/asound/cards.
- with my patch: the error is gone and bcm2835_hdmi is present in
  /proc/asound/cards.

(Since the Pi Zero has no Headphones jack, you need to test both cases with
snd_bcm2835.enable_hdmi=1 in the command line. Otherwise the card never shows
up, even when everything works.)

Could you check these two cases?


Testing that you can hear the sound going through bcm2835-audio is a full
functional test that goes even further than the patch: it does not only test
bus registration but also that the audio driver is working.

On my side, without vc4-drm, I can successfully hear sound through both bcm2835
Headphones and bcm2835 HDMI:

  # aplay -l
  **** List of PLAYBACK Hardware Devices ****
  card 0: HDMI [bcm2835 HDMI], device 0: bcm2835 HDMI [bcm2835 HDMI]
  [...]
  card 0: HDMI [bcm2835 HDMI], device 1: IEC958 [IEC958]
  [...]
  card 1: Headphones [bcm2835 Headphones], device 0: bcm2835
Headphones [bcm2835 Headphones]
  [...]

  # speaker-test -D plughw:0,0 # (HDMI)

  # speaker-test -D plughw:1,0 # (Headphones, not on the Pi Zero)


If you still want to output sound through bcm2835_hdmi (optional):

There can only be one owner of the HDMI port: either the firmware or the
kernel.
When the Raspberry Pi boots, the firmware first owns the HDMI and displays a
rainbow splash. Then it launches Linux.

There are 2 ways for the kernel to deal with the video output:

1) With vc4-drm (CONFIG_DRM_VC4), the kernel takes over the HDMI controller
   from the firmware and handles everything itself (this is your case).
2) With simple-framebuffer (CONFIG_DRM_SIMPLEDRM or CONFIG_FB_SIMPLE), the
   kernel leaves the HDMI to the firmware and just writes pixels to a
memory area
   (the framebuffer) set up by the firmware.

I get a similar problem on my side when sending sound through bcm2835_hdmi with
vc4-drm loaded: my screen shuts down (but the kernel is still alive).
It most likely comes from the firmware and the kernel both trying to drive the
same HDMI port: with vc4-drm, the kernel owns the HDMI controller, and the
firmware (which bcm2835-audio talks to through VCHIQ) is not supposed to touch
it.

A simple way to output sound through bcm2835_hdmi is to not use the vc4-drm
driver at all, and use simple-framebuffer if you still want a display.

To remove vc4-drm:
- Do not compile the driver into the kernel (CONFIG_DRM_VC4=n) or blacklist the
  module.
- Remove any vc4 overlay in config.txt file (e.g. remove dtoverlay=vc4-kms-v3d).

To enable simple-framebuffer, use one of the two configs:

  CONFIG_DRM=y
  CONFIG_DRM_SIMPLEDRM=y
  CONFIG_DRM_FBDEV_EMULATION=y
  CONFIG_FRAMEBUFFER_CONSOLE=y

or, the older way:

  CONFIG_FB=y
  CONFIG_FB_SIMPLE=y
  CONFIG_FRAMEBUFFER_CONSOLE=y

(FRAMEBUFFER_CONSOLE=y, and DRM_FBDEV_EMULATION in the DRM case, are only
needed to see the boot messages on the screen, with console=tty1 on the command
line.)

If you have remote access to your Pi Zero (either through network+SSH or
through serial console), you actually don't even need the simple-framebuffer:
you can just remove vc4-drm, and let the firmware display its rainbow splash on
the HDMI port.
Then you can login to your Pi Zero through SSH for example and launch
speaker-test.
As long as the HDMI video output is active, it's enough for the sound to be
able to go through, even if the image was not drawn by Linux.

But again, this full functional test is optional.

Regards,
Martin