Jon Smirl wrote:
On 6/13/08, Mark Brown broonie@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.