Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

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

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

On Wed, Mar 07, 2012 at 09:58:56PM +0530, Nitin PAI wrote:

> >You can add debugfs information to dump the capabilities and whatnot if
> >>that's useful to you...

> If the cards are not enumerated all these dont make any sense.

The DAI and so on drivers come up all by themselves and need to do so
prior to the cards actually instantiating so we can create debugfs stuff
for them as soon as they register if we want to.

> >>You'd still need to do things like set up the clocking even
> >>for the SoC loopback case, everything is going to need to agree on where
> >>the clocks come from and how they flow.

> Clocks need not come from the codec, it can come from on of the other
> masters in the system.

Right, exactly - the point is that the machine driver makes the decision
about the clocking architecture of the given system, the individual
drivers can't reasonably make that decision themselves.

> >>Honestly it just sounds like you want to write some machine drivers for
> >>your systems.

> Yes, thats the purpose, but I want to ship them to for the reasons I
> mentioned above.
> Since the enumeration of the machine driver depends on the linkage with the
> codec driver its not possible for me to write.
> I wish that the spdif_tranceiver was written for more generalized cases and
> not just spdif.

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.

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

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