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.