On Mon, Jul 28, 2014 at 08:24:39AM +0200, Lars-Peter Clausen wrote:
Cc ASoC maintainers.
Jon, you should really know to CC maintainers.
So how should this be implemented? You want to use simple-audio-card when the MAX9768 is present.
You do - why? It's not immediately obvious to me that this fits well, there's a good reason why lots of the functionality there is done as a library...
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:
To be honest I don't see a great need to remove the requirement for a DAI - even with the CODEC baked into the SoC there will often be some form of IP separation and the stubbing isn't really the blocker to supporting anything.
- 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.
Another and probably simpler way of approaching this is to allow more than one thing in the card to provide DAI links. That meshes better with DPCM as it stands and sidesteps the need to deal with carrying digital stream configuration information through DAPM which is where you end up otherwise since you really want DPCM systems to be able to behave in a similar way.
A good proportion of these systems do actually seem to have physical I2S interfaces as well to allow people to change up to a better CODEC if they want so might actually want to be DPCM systems really.
- Proper devicetree bindings for this kind of devices
What bindings would we have? It should be transparent to device tree since shouldn't be representing the internals of devices in the device tree, that's redundant and adds to complication. For device tree we just want the external connection points of each device to be visible and that's already handled.
What we do want is better support for building the card up from multiple sources of data so that all the in-SoC stuff can be done by the drivers for the components in the SoC instead of requring bits of it to be in the machine driver as we do curently with DPCM.