[REGRESSION] bcm2835-audio fails to register on vchiq-bus in monolithic kernels since 6.19 (VCHIQ destaging?)

[REGRESSION] bcm2835-audio fails to register on vchiq-bus in monolithic kernels since 6.19 (VCHIQ destaging?)

[Martin Wetterwald]

Hi,

After moving from 6.18.52 to 6.19 (still present in 7.2.6), the bcm2835
Headphones sound card no longer appears on my Raspberry Pi 3 Model B Rev 1.2
(arm64). 6.18.52 works with the exact same userspace.

dmesg shows:

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

and /proc/asound/cards reports "--- no soundcards ---".

My kernel is monolithic (no module support), with:

  CONFIG_BCM2835_VCHIQ=y
  CONFIG_SND_BCM2835=y
  CONFIG_BCM2835_VCHIQ_MMAL is not set
  CONFIG_VCHIQ_CDEV is not set

Analysis: both drivers are built in and use module_init(), i.e. the same
initcall level (6), so they run in link order.
vchiq_driver_init() registers vchiq_bus_type, and bcm2835_alsa_driver_init()
registers a driver on that bus, so VCHIQ must run first. In 6.18 it does, but
in 6.19 the order is reversed.
System.map (same initcall level, lower address runs first):

  6.18: vchiq_driver_init            ffff800080646704
        bcm2835_alsa_driver_init     ffff800080646708

  6.19: bcm2835_alsa_driver_init     ffff800080646698
        vchiq_driver_init            ffff80008064669c

In 6.18 both drivers lived under drivers/staging/vc04_services/. In 6.19 the
VCHIQ interface lives in drivers/platform/raspberrypi/, while bcm2835-audio
stayed in drivers/staging/. drivers/Makefile links staging/ before platform/
(line 154/155 in v6.19), which matches the flipped order.

After boot the bus does exist (/sys/bus/vchiq-bus is present); it is only
registered after the audio driver has already failed. Without module support
there is no way to retry.

My suspect is this commit:

  aa125180c673881f88b528600b57865dc158b3a7
  ("platform/raspberrypi: Destage VCHIQ interface")

I could not bisect to a single commit, but what I know for sure is: v6.18.52
works, v6.19 and v7.2.6 fail, and the initcall ordering above explains the
failure.

#regzbot introduced: v6.18..v6.19

Possible fixes I can think of, none tested yet: register the bus earlier (e.g.
postcore_initcall or subsys_initcall for the bus registration in the VCHIQ
interface), or defer the bcm2835-audio registration to a later initcall level.

I'm happy to test patches and I can do it on 1B rev 2, 1B+, 2B, 3B and 4B if
necessary.

Thanks!
Martin

Re: [REGRESSION] bcm2835-audio fails to register on vchiq-bus in monolithic kernels since 6.19 (VCHIQ destaging?)

[Thorsten Leemhuis]

On 9/21/26 12:07, Martin Wetterwald wrote:

> After moving from 6.18.52 to 6.19 (still present in 7.2.6), the bcm2835
> Headphones sound card no longer appears on my Raspberry Pi 3 Model B Rev 1.2
> (arm64). 6.18.52 works with the exact same userspace.
> [...]
> My suspect is this commit:
> 
>   aa125180c673881f88b528600b57865dc158b3a7
>   ("platform/raspberrypi: Destage VCHIQ interface")
> 
> I could not bisect to a single commit,

Hmm, no answer, so it seems nobody really cares. A bisection might help.
Or at least validating your suspicion, hence: why can't you check the
parent of aa125180c6738 and aa125180c6738 itself? Or at least the range
with that commit in it? And is latest 7.3-rc still broken?

Ciao, Thorsten

Re: [REGRESSION] bcm2835-audio fails to register on vchiq-bus in monolithic kernels since 6.19 (VCHIQ destaging?)

[Jai Luthra]

Hi Martin, Thorsten,

Quoting Thorsten Leemhuis (2026-10-12 18:53:13)
> On 9/21/26 12:07, Martin Wetterwald wrote:
> 
> > After moving from 6.18.52 to 6.19 (still present in 7.2.6), the bcm2835
> > Headphones sound card no longer appears on my Raspberry Pi 3 Model B Rev 1.2
> > (arm64). 6.18.52 works with the exact same userspace.
> > [...]
> > My suspect is this commit:
> > 
> >   aa125180c673881f88b528600b57865dc158b3a7
> >   ("platform/raspberrypi: Destage VCHIQ interface")
> > 
> > I could not bisect to a single commit,
> 
> Hmm, no answer, so it seems nobody really cares. A bisection might help.
> Or at least validating your suspicion, hence: why can't you check the
> parent of aa125180c6738 and aa125180c6738 itself? Or at least the range
> with that commit in it? And is latest 7.3-rc still broken?
> 

Sorry, this got lost in my inbox last month. It's likely my series that 
destaged VCHIQ broke the ordering as Martin suspects. I always tested with 
modules enabled so didn't encounter this issue.

I'll look into how we can ensure the VCHIQ bus gets registered before 
peripheral drivers (like audio here) when CONFIG_MODULES=n. If someone 
already knows what to do, pointers are appreciated :-)

> Ciao, Thorsten

Thanks,
Jai

Re: [REGRESSION] bcm2835-audio fails to register on vchiq-bus in monolithic kernels since 6.19 (VCHIQ destaging?)

[Martin Wetterwald]

Hi Jai, Thorsten,

> Hmm, no answer, so it seems nobody really cares. A bisection might help.
> Or at least validating your suspicion, hence: why can't you check the
> parent of aa125180c6738 and aa125180c6738 itself? Or at least the range
> with that commit in it? And is latest 7.3-rc still broken?
>
> Ciao, Thorsten

Thanks Thorsten for the follow up!
I didn't bisect because my image builder tool was not meant for kernel
development: it could only download stable release tarballs signed by Greg.

But now I've found a way around it and I've just bisected the issue! I've
bisected through the 6523 revisions between 6.18 and 6.19-rc1.

(The bisection was made on a Raspberry Pi 1B rev2 this time.)

> aa125180c673881f88b528600b57865dc158b3a7 is the first 'bad' commit
I confirm the issue was introduced by following commit:

> commit aa125180c673881f88b528600b57865dc158b3a7
> Author: Jai Luthra <jai.luthra@ideasonboard.com>
> Date:   Wed Oct 29 16:00:10 2025 +0530
>
>     platform/raspberrypi: Destage VCHIQ interface
>
>     Destage the VCHIQ interface driver to drivers/platform/raspberrypi.
>
>     There is still the remaining TODO item of improving the documentation,
>     which can be handled post destaging.
>
>     Secondly, multimedia drivers like codec and ISP that rely on this
>     interface need to be upstreamed. And lastly, the drivers that facilitate
>     the shared memory between VideoCore and Linux, like the vc-sm-cma driver
>     and vc_mem char driver also need to be upstreamed.
>
>     Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
>     Link: https://patch.msgid.link/20251029-vchiq-destage-v3-6-da8d6c83c2c5@ideasonboard.com
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

#regzbot introduced: aa125180c673881f88b528600b57865dc158b3a7

> Sorry, this got lost in my inbox last month. It's likely my series that
> destaged VCHIQ broke the ordering as Martin suspects. I always tested with
> modules enabled so didn't encounter this issue.
>
> I'll look into how we can ensure the VCHIQ bus gets registered before
> peripheral drivers (like audio here) when CONFIG_MODULES=n. If someone
> already knows what to do, pointers are appreciated :-)

Thanks Jai!
I'm willing to make the patch, but I'm not familiar with initialization order
in the kernel boot sequence.
Would also love if someone has pointers on good ways to influence order of boot
sequence.

Martin

Re: [REGRESSION] bcm2835-audio fails to register on vchiq-bus in monolithic kernels since 6.19 (VCHIQ destaging?)

[Martin Wetterwald]

I also tested current mainline (7.3-rc7), and I confirm the issue is
still there.
Martin

On Tue, Oct 13, 2026 at 9:28 AM Martin Wetterwald <martin@wetterwald.eu> wrote:
>
> Hi Jai, Thorsten,
>
> > Hmm, no answer, so it seems nobody really cares. A bisection might help.
> > Or at least validating your suspicion, hence: why can't you check the
> > parent of aa125180c6738 and aa125180c6738 itself? Or at least the range
> > with that commit in it? And is latest 7.3-rc still broken?
> >
> > Ciao, Thorsten
>
> Thanks Thorsten for the follow up!
> I didn't bisect because my image builder tool was not meant for kernel
> development: it could only download stable release tarballs signed by Greg.
>
> But now I've found a way around it and I've just bisected the issue! I've
> bisected through the 6523 revisions between 6.18 and 6.19-rc1.
>
> (The bisection was made on a Raspberry Pi 1B rev2 this time.)
>
> > aa125180c673881f88b528600b57865dc158b3a7 is the first 'bad' commit
> I confirm the issue was introduced by following commit:
>
> > commit aa125180c673881f88b528600b57865dc158b3a7
> > Author: Jai Luthra <jai.luthra@ideasonboard.com>
> > Date:   Wed Oct 29 16:00:10 2025 +0530
> >
> >     platform/raspberrypi: Destage VCHIQ interface
> >
> >     Destage the VCHIQ interface driver to drivers/platform/raspberrypi.
> >
> >     There is still the remaining TODO item of improving the documentation,
> >     which can be handled post destaging.
> >
> >     Secondly, multimedia drivers like codec and ISP that rely on this
> >     interface need to be upstreamed. And lastly, the drivers that facilitate
> >     the shared memory between VideoCore and Linux, like the vc-sm-cma driver
> >     and vc_mem char driver also need to be upstreamed.
> >
> >     Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
> >     Link: https://patch.msgid.link/20251029-vchiq-destage-v3-6-da8d6c83c2c5@ideasonboard.com
> >     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> #regzbot introduced: aa125180c673881f88b528600b57865dc158b3a7
>
> > Sorry, this got lost in my inbox last month. It's likely my series that
> > destaged VCHIQ broke the ordering as Martin suspects. I always tested with
> > modules enabled so didn't encounter this issue.
> >
> > I'll look into how we can ensure the VCHIQ bus gets registered before
> > peripheral drivers (like audio here) when CONFIG_MODULES=n. If someone
> > already knows what to do, pointers are appreciated :-)
>
> Thanks Jai!
> I'm willing to make the patch, but I'm not familiar with initialization order
> in the kernel boot sequence.
> Would also love if someone has pointers on good ways to influence order of boot
> sequence.
>
> Martin

[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