Cc ASoC maintainers.
On 07/26/2014 05:18 PM, jonsmirl@gmail.com wrote:
Allwinner CPUs have an on-chip codec that supports line out. This is a monolithic block that does not implement anything like standard I2S. We have implemented this by internally making a soc_card and then binding the DAI to a dummy NOP codec to make ASoC happy.
But now someone wants to add a MAX9768 amplifier which needs a codec driver to implement volume control.
So how should this be implemented? You want to use simple-audio-card when the MAX9768 is present.
But what about the dummy-codec case? Using simple-audio-card to bind to a dummy-codec clutters things up a lot. Plus the dummy-codec is not currently exposed to device trees.
And then there is the ordering problem, how do I know for sure MAX9768 is not going to be bound so that it is safe to bind to dummy-codec. Or should binding to MAX9768 simply override a binding to the dummy-codec?
If my dummy-codec is exposed into the device trees then this generates a bunch of NOP clutter in the tree using simple-audio-card to bind it.
Another idea, maybe one of those NOP SDPIF codecs could get an alias name like NOP or Dummy.
Hi,
The dummy CODEC is a ASoC specific software construct, it should not appear in the description of the hardware. The reason why ASoC requires CODEC for successfully instantiate is due its history. When ASoC was initially designed and implemented your typical embedded audio system had 3 main components, the DMA, the I2C or AC97 CPU DAI and the CODEC with the CODEC DAI. And while the ASoC framework as gained support for more configurations over the years the basic requirement that at least one CODEC is present in the system has remained. So the correct solution in this case is to adopt the framework so it can properly support this new class of device it was previously not designed to handle. I've been working on removing the requirement that at least one CODEC needs to be present in the system by moving the abstraction level in the ASoC core to snd_soc_component level. This is mostly done and the final missing pieces are scheduled for submission after the next merge window closes.
While this restructuring allows for CODEC-less systems, it does not allow for DAI-less systems yet. At least if you want to have a PCM device. To properly support DAI-less systems 3 major pieces are missing: * Currently the DAIs are entry and exit points of the PCM streams into the DAPM graph. This needs to be reworked so that there is a native representation of the PCM device in the DAPM graph which is used as the entry and exit point instead. * Support for creating a PCM device without specifying a DAI link. Right now the only way in ASoC to create a PCM device is by having a DAI link. For systems without DAIs and DAI links we need an alternative. Preferably the driver for the on-chip CODEC should be able to create the PCM device itself since it is basically embedded in its hardware. * Proper devicetree bindings for this kind of devices
- Lars