[alsa-devel] [PATCH] [RFC 1/13] Intel SST drivers documentation

[Mark Brown]

On Fri, Jul 03, 2009 at 12:28:30PM +0530, Vinod Koul wrote:

> +There are 3 sound cards that Intel SST hardware supports and enables.
> +Intel SST is the only hardware in the platform that can render to sound card.
> +These sound cards are exposed and mapped through Intel MID driver which is an
> +ALSA driver. This driver uses Intel SST driver to send data and controls to the
> +hardware.

Looking at the code I'm a bit confused about the way things are
structured in hardware terms here.  Do you have any documentation (even
fairly high level stuff) or what exactly a "vendor" is that you could
refer to?  The reason I ask is that a lot of what's going on here sounds
much like the typical embedded hardware supported by the ASoC framework
in the kernel in which case I worry that these drivers may run into many
of the issues which ASoC solves.

The bit that particularly jumps out at me is that what the vendor
drivers are providing appears to be very much like an ASoC CODEC driver
with bits of an ASoC machine driver.  They define register maps with
register names that look very much like those I'd expect to see in audio
CODECs, define some controls for those and do similar things in the
various ALSA API callbacks they get.

The main potential difference that I can see is that it looks like all
the register access to the child devices is indirected via the DSP/PMIC,
though it doesn't look like it's abstracted at all - it seems like it's
just write through if it's anything.  Most embedded systems would have
the CODECs hooked directly to the CPU.  It also looks like your vendor
ID information is only 3 bits which seems very limited and makes me
question my analysis.

Like I say, I don't fully grasp how the hardware looks so I may be
completely off-base here.

> +To make use of the low power playback feature, the application or framework
> +needs to open a Intel SST driver handle and send the encoded stream
> +like MP3, AAC or WMA through this driver to play out. If its a PCM stream

Just thinking back to my previous comment about the DSP possibly being
general purpose - even if it is not possible to use this DSP for other
things the offloaded media decode here is something that other devices
support.  We should try to come up with a general purpose API for using
this which isn't driver-specific so that applications are able to make
use of the functionality without having to code up ways to talk to lots
of different drivers.

For simplicity it may be best to arrange the patch series so that you've
got a driver without the offloaded decode support and then build the
offloaded decode support on top of that.  This should make it easier to
review the more standard ALSA functionality and may help get that code
in more quickly.