On 6/13/08, Timur Tabi <timur@xxxxxxxxxxxxx> wrote: > Jon Smirl wrote: > > On 6/13/08, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
