On Sun, Oct 17, 2010 at 11:02:45AM +0200, Takashi Iwai wrote:
SST driver has been once (sort of) posted and reviewed, but stalled since then. But in general I'm not against merging to the sound main tree at all. The only reason that it didn't occur was that the activity just stopped somehow.
I'm really concerned about this idea. Allowing embedded vendors to push drivers into mainline which don't work with the standard frameworks for what they're doing sets a bad precedent which makes it much harder to push back on other vendors who also want to push their own stacks.
This sort of thing is very common in the embedded space for audio, to a large extent because other OSs don't have any sort of standard framework for representing the hardware. The experience is that it's always pretty painful if there's any active work with the device - hardware changes that should be straightforward like substituting a new CODEC or even changing the physical configuration of the outputs become much more involved. You can see in the current code that the bulk of the audio configuration is register write sequences for various operations, at best you end up needing to replicate those into each vendor's stack for each CODEC that gets deployed and at worst you end up replicating everything per-board rather than per-CPU. This isn't great for anyone, it's a lot more work and a lot less clear.
The Moorestown CPU appears to be very standard embedded audio hardware - a CPU communicating with an external CODEC over I2S/PCM data links - and so I can't see any reason why we should treat it differently to other such hardware.