snd_bcm2835: disable HDMI audio when vc4 is used

[hvenev]

Things don't work too well when both the vc4 driver and the firmware
driver are trying to control the same audio output:

[ 763.569406] bcm2835_audio bcm2835_audio: vchi message timeout, msg=5

Hence, when the vc4 HDMI driver is used, let it control audio. This is done
by introducing a new device tree property to the audio node.

Signed-off-by: Hristo Venev [email protected]

[hvenev]

Should I rebase the pull request?

Also, should I add the same change for the Pi <=3 overlay?

[popcornmix]

@pelwell what's your preference for this?
Basically:

dtparam=audio=on
dtoverlay=vc4-kms-v3d (without ,audio=off)

are dangerous if both audio devices are used.
Would this be better handled by firmware's DT mangling? (e.g. if one is detected ensure other is disabled)

[hvenev]

Personally I'd like to keep the ability to use the headphone jack at the same time as HDMI.

[pelwell]

DT mangling is only useful if there is something to observe the change. If there is an existing way to disable the audio support in the KMS driver then this overlay should use it, but I don't think there is one.

An alternative approach would be for the bcm2835 driver to detect the presence of the enabled kms driver automatically, but this is much simpler. You could hide the disabling property if "audio=off" is specified, if there are situations where one might want the bcm2835 driver to control the audio.

[hvenev]

An alternative approach would be for the bcm2835 driver to detect the presence of the enabled kms driver automatically, but this is much simpler. You could hide the disabling property if "audio=off" is specified, if there are situations where one might want the bcm2835 driver to control the audio.

Yes, that would be better. However, on the Pi4 there are two toggles, one for each HDMI port. We need to somehow detect if both are disabled, and only have snd_bcm2835 handle audio then.

My overlay-fu isn't very strong. Do you think the following will work:

vc4-kms-v3d-pi4-overlay.dts

fragment@19 {
	target = <&audio>;
	__overlay__  {
	    brcm,disable-hdmi;
	};
};

__overrides__ {
	audio   = <0>,"!17", <0>,"=19";
	audio1   = <0>,"!18", <0>,"=19";
};

Then &audio brcm,disable-hdmi is not set if both audio=off and audio1=off.

Edit: I'm not sure this works. How will the overrides behave when audio=on,audio1=off? Or audio1=off,audio=on?

[pelwell]

I think it's safer to add a third parameter:

noaudio = <0>,"=17", <0>,"=18",<0>,"!19";

[hvenev]

Maybe <0>,"+17", <0>,"+18", <0>,"-19", so that it can be used as

dtoverlay=vc4-kms-v3d,noaudio

instead of

dtoverlay=vc4-kms-v3d,noaudio=on

?

[pelwell]

If no parameter value is supplied then the default value of 1/on/true is assumed, so my version works with or without =on - the difference is only apparent if someone tries ...,noaudio=off. I have no strong feelings either way, so I'll let you choose. You can also include an underscore in the name for readability if you prefer.

[hvenev]

I added the noaudio parameter to the Pi <=3 and Pi 4 overlays. I haven't actually tested the audio output itself, but alsamixer seems to show the right set of sound cards.

On the Pi 4, the old (current) behaviour can be configured with

dtoverlay=vc4-kms-v3d,noaudio,audio,audio1

This first disables vc4 HDMI audio and lets snd_bcm2835 handle it using the firmware thing, and then also tells vc4 to handle HDMI audio as well.

[pelwell]

I'll give it a spin tomorrow.

[pelwell]

I've added commits that make "audio=off" do the sensible thing for the non-Pi4 case, and idocument the noaudio parameter. If you're happy with these changes I'll squash and merge all three.

[hvenev]

LGTM

[pelwell]

Thanks!