On Mon, Jun 08, 2009 at 04:48:23PM +0200, Manuel Lauss wrote:
What annoys me most is the need to actually have the machine code file in the first place. Or more precisely, the location of it. It should be located where the rest of the board code lives.
Like I say, review and API changes are the main factors here at the minute. You will also always get some machines that are substantial enough to warrant "real" drivers too due to having controls plus complex and configurable clocking and routing (few of these make it mainline ATM).
The other thing is the "soc_audio" platform device itself. Instead of reg- istering a platform device for soc audio, how about a function call to setup an asoc device. Multiple calls create multiple alsa devices, the argument describes the audio fabric.
This is waiting for the multiple card support - if you take a look at how the soc-audio device is implemented at the minute you'll see it calls a function snd_soc_register_card() that's currently not exported. Once multi-card support is there the interface to it will be changed a bit and it will be exposed directly to machine drivers and the soc-audio device will go away, though I'll leave it there for a while in order to provide a transition period for machine drivers.
At the minute you can probably create multiple soc-audio devices and it's likely to work in some configurations but not supported.
Please submit anyway but at some point someone is going to have to convert the driver - I'm intending to leave as long a transition period as I can but at some point it's going to block other enhancements.
I attached an untested patch (an addon to the patch which started this thread) which does this. Please have a look and tell me if this is what suggested initially?
Pretty much, though I suspect there's some confusion between the probe functions going on there (there's far too many of them in ASoC at the minute - I intend to streamline things a bit in the future but first I want to get the new models implemented).
I'd expect it's possible to have standard platform devices declared in the CPU definitions for each PSC that the individual boards can just reference (rather than having to copy out the resources, which presumably are fixed for each CPU) but I'm not sure if that's idiomatic for MIPS code or not. Most of ARM works that way.
I'd be tempted to not bother creating the separate device for the DMA driver in au1xpsc_pcm_add() but that's just my personal preference.
Also, you've missed a name for your audio_dev.