Re: [PATCH] sst: Intel SST audio driver

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

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.