[alsa-devel] [PATCH][ASoC v2] Update Freescale MPC8610HPCD fabric driver to support multiple codecs

[Jon Smirl]

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.

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. 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.

We're missing a cross platform way to set parameters into a codec. A
quick fix is to pass the device tree handle in and use arch specific
code in the codec, but that will need to be removed in the longer
term.

>
>  Things get a lot more tricky for I2S due to the complexity of the
>  available clocking configurations - there are so many possible ways of
>  connecting devices, especially once you start to take into account codec
>  internal clocking and systems which support more than two devices
>


-- 
Jon Smirl
jonsmirl at gmail.com