[alsa-devel] ASoC: Device tree binding to dummy codec

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140728/15f2bd71/attachment.sig>