Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2497 bytes --]

On Wed, Mar 07, 2012 at 10:23:59PM +0530, Nitin PAI wrote:

Please fix your quoting, you're not attributing and you're double
quoting things.

> >>Well, just write a CODEC driver that matches what you've got down on
> >>your boards.  Usually the driver does need to enforce some kind of
> >>limits (on input format and sample rate normally) even for a simple
> >>device with no software control otherwise the device can get driven
> >>out of spec.

> The CODEC is part of the system integration process. From SOC standpoint
> the machine driver is what needs to be delivered.
> I dont know finally what the final codec will be, its upto the integrator
> to write.  May be he can pick the ones from the asoc:codecs list.

Well, quite - if you're working with a system then you need a machine
driver.

> I dont like the dependency of the machine driver with the codec driver for
> enumeration. Machine driver can self exist without having for the codec
> driver. [USB, PCi, HDMI, S/PDIF]  However the vice-versa is not true and is

In the USB case we're going to be going nowhere near ASoC anyway,
there's a totally orthogonal hardware design and set of drivers at the
ALSA level.  Similarly for PCI, though obviously it's possible to make a
PCI card which is decomposed enough to make sense to support via ASoC.

In the S/PDIF case you do actually have a CODEC - while it's common for
this to be a fixed function hardware CODEC (in which case you need a
stub driver saying what it looks like within the system as I said above)
this isn't always the case.  For example, the WM8804 in mainline is a
S/PDIF transciever with register control.  The effort required to bolt
on fixed function drivers (or try to parameterise a generic one if
someone wants to do that) is so trivial it really doesn't seem worth
caring about.  HDMI is broadly similar to S/PDIF here.

> of no use.  Binding them together will make the usecases easy (power for
> instance, user interaction), but should not have been a hardlimit.  Given
> the thought process, ALSA should allow dummy_codec drivers which it does
> (from spdif_tranceiver.c),  but why not make it completely generic? (remove
> the s/pdif keywords).

Allow me to suggest again (as I did earlier in this thread) munging all
these dumb drivers together so you just have a bunch of things in the
one driver which the driver distinguishes by ID.  To repeat once more
you're always going to need to put in at least some information about
the limits the device has.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]