Testing if audio is enabled in config.txt without using the device tree.

[Electron752]

I've been batting around the idea of converting the firmware/vchiq drivers to be non-platform devices and create custom subsystem(s)/bus(s). The concept has been essentially given the green light by the staging tree maintainer/owner in the upstream kernel.

The camera driver is already not a platform driver, but the audio driver is. If I modify the audio driver to load without a DT(only if vchiq and raspberry pi firmware loads correctly), what can I easily put in the probing code to check that config.txt and the firmware have audio enabled?

Also, the non-firmware based HDMI audio driver has been submitted now to upstream. I'm thinking it will probably only work if KMS is enabled(and then only with a userland alsa plugin). Any ideas on how the firmware should select between the open source audio driver and the firmware based audio driver? Could the firmware based driver still be used for the analog headphone jack on the RPI even if the HDMI Audio/VC4 driver is controlling HDMI audio?

[popcornmix]

Yes, arm side hdmi audio should only be used in the kms world.
Currently we disable some conflicting firmware features (e.g 3D, tvservice, dispmanx, qpu code) when kms is enabled. HDMI audio will be added to that list when it reaches our kernel tree.

I don't see a reason why firmware side analogue audio wouldn't work in this setup. The main problem is the current alsa driver supports both firmware side analogue and hdmi audio. It may be enough that firmware returns an error when trying to open hdmi audio, but allows analogue audio.

But I would have thought that an arm side driver for analogue audio would be the right solution (it would be so much easier than the hdmi audio driver).

[Electron752]

ARM side audio probably just never got put on a TODO list, or nobody thought of it. It does sound interesting. It probably wouldn't have had any of the issues that HDMI had such as needing to convert to that ancient encoding in the alsa plug-in.

1. Does the analog jack perhaps use I2S? Upstream already has an I2S driver.
2. Is any public technical documentation available for the analog jack?

Perhaps the best longer term solution would be to simple remove the analog jack support from the firmware based driver and only support analog from arm. These audio drivers appear to be easy to write, so if the information is public perhaps I can even write it.

The firmware based driver was never meant to be a long term solution in upstream and I've mentioned to Anholt a few times about deleting the firmware driver once HDMI audio is online. It was only added to satisfy some people about the issue that vc04_services didn't have anything using it in upstream. But it's received many more changes(although small ones) from people then the camera has, probably because it's easier for people to test. It sounds like it would still be needed if KMS is not enabled so maybe it still has some upstream value.

For my original question, if I open audio from the alsa driver(either HDMI or analog) and audio is not enabled in config.txt, will the firmware return an error?

[Electron752]

I found a bare metal example for the audio jack. Sounds like people just use the PWM peripheral on it to generate sound.

https://github.com/PeterLemon/RaspberryPi/tree/master/Sound

Assuming I or somewhere else wrote a working driver for the analog jack and got it into upstream, would you consider using it instead of the firmware based support?

Would you recommend a regular alsa driver, or a Soc alsa driver? If I we to go with a regular alsa driver, I could do the needed data processing in the driver. If I were to go with the Soc driver(which is what everything seems to be moving to), I would probably need a user mode alsa plugin just like the HDMI driver needed since soc doesn't have a good way to do any signal processing in the driver model.