[alsa-devel] [PATCH][ASoC v2] Update Freescale MPC8610HPCD fabric driver to support multiple codecs
timur at freescale.com
Fri Jun 13 16:26:04 CEST 2008
Jon Smirl wrote:
> On 6/13/08, Mark Brown <broonie at opensource.wolfsonmicro.com> wrote:
>> On Thu, Jun 12, 2008 at 10:57:39PM -0400, Jon Smirl wrote:
>> > In my model a lot of the code in your fabric driver would be pushed
>> > into the ssi driver. So if you used ssi and a codec in the standard
>> > manner, the board wouldn't need a fabric driver at all. That would
>> > probably be the case for most AC97/HDA systems.
>> I'd certainly like to see some standard support for setting up at least
>> AC97 DAI links automatically based on the probed codec. That bit could
>> probably be done by the core. HDA should be amenable to this model too
>> but I haven't looked at it in anything more than passing detail yet.
>> That's only part of the story, though. What's much more tricky is
>> making the decision that you've got all the components for the sound
>> subsystem - for example, there are AC97 codecs like the WM9712 and
>> WM9713 which also have I2S interfaces. You also get systems which need
>> to jump through hoops to set up the clocking since they're doing
>> non-standard things. Simple systems would probably need an explict flag
>> to say that they could be handled as such, which isn't a million miles
>> off having something to load a generic machine driver.
> We can't eliminate a fabric driver is all cases, I'd just like to
> minimize its need. This code has the card and codec creation code in
> the fabric driver, I would push down into the ssi driver. Code in the
> ssi would locate the codec and load it. The model needs to be able to
> function if there is no need for a fabric driver.
Like I said earlier, I don't like this idea. I don't want all this gunk in the
SSI driver, and I don't see anything wrong with the fabric driver being the
master that sets up all the inter-device connections.
> That also flips things around, now the ssi driver needs to locate the
> fabric driver, not the other way around. In this model the fabric
> driver doesn't need to make a device, it just becomes a library of
> code called by the ssi driver.
The DMA driver is already a library that is called by the SSI. It registers
itself as a regular driver, but under ASoC V2, it really acts like a library.
> Code in the ssi driver could make a
> list of codec parameters, pass it to the fabric driver for
> modification, and then set it into the codec.
That sounds too complicated.
> We're missing a cross platform way to set parameters into a codec.
No we're not. ASoC already provides an API for sending parameters to a codec,
and if we need more than that, we can create platform resources and pass those
to the codec.
Linux kernel developer at Freescale
More information about the Alsa-devel