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

[Jon Smirl]

On 6/13/08, Timur Tabi <timur at freescale.com> wrote:
> 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 forces every board to copy/paste the fabric driver and then makes
tweaks to it even if it doesn't need board specific code.


>  > 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.
>
>
>  --
>  Timur Tabi
>  Linux kernel developer at Freescale
>


-- 
Jon Smirl
jonsmirl at gmail.com