[alsa-devel] ASOC - Codecs : Renaming of spdif_tranceiver.c

[Mark Brown]

On Wed, Mar 07, 2012 at 12:15:07PM +0530, Nitin PAI wrote:

Adding a CC to Liam.  *ALWAYS* CC the maintainers on mails, I know you
followed up adding Liam but you still missed me off.

> In my project I am feeling of need to have generic_codec.  This will
> provide the required codec_dais for the usecases like

> -HDMI/SPDIF where there is no codec involved.
> -For audio over MOST, where CPLD/glue logic is used

These still need something to say what the capabilities of the device
are - ideally users could just specify the part name and not worry about
that stuff.  If you look at how thin the drivers are it's really not
clear to me what we'd save here, though if someone did the work and it
looked useful...  Another option is to just embed all the data
structures in a single driver which binds to them all and selects the
right data structure based on the probe information, that might be
useful.

> -For complex audio DSPs connected which will be mostly programmed in the
> user-space.

These will need in kernel drivers, if only to export the interfaces
required by the application layer to userspace.  They'll also have
difficulty integrating well with the power management without an in
kernel representation of the device, especially for bypass cases like in
call audio.

> -SOC manufactures who would like to ship their drivers without having to
> know what will be the final codec that will be present in the system.

The CPU side drivers have no dependency on the CODEC drivers, these are
integrated by the machine.  The SoC vendor can easily ship drivers which
will work with any CODEC which works well on Linux.

If you actually mean machine drivers it's not really possible to write a
generic machine driver which will actually work for modern CODECs,
especially those used in smartphones and tablets, the clocking
architectures are far too varied and flexible for this to work usefully.
This is before you get into things that are genuine hardware choices and
need to be enumerated at runtime, and of course most modern devices will
require software to power them on so you need to match them up with the
relevant driver to do that.

In general pluggable reference boards really need to have some means of
identifying the connected boards if they want to support running with
different setups without recompilation.  For example, the Wolfson
reference systems have ID chips on each board which are queried during
boot to allow us to instantiate things based on what's physically
connected.  We can swap boards over and have a single system image boot
successfully without software changes.

> 4) Any other ideas ?

I don't think you've fully thought through what you're suggesting, it
doesn't seem practical for most things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120307/6b0efecb/attachment.sig