On Thu, Jun 05, 2008 at 06:40:37PM +0200, Haavard Skinnemoen wrote:
That's pretty much exactly what sound/soc/codecs/ac97.c is doing - it
provides a codec driver which lets a machine connect a SoC AC97
controller driver to the generic ALSA AC97 layer, it doesn't actually
have any code of its own.
It can't completely replace the generic AC97 layer at the minute but the
major issue with that currently is the more general one of providing a
machine driver for a standard AC97 subsystem and then working out when
to use it rather than a system-specific one.
It's more a case of the way people want to program things than anything
else - if someone were to write the relevant drivers for things other
than SoC systems then ASoC would quite happily glue everything together,
the core really doesn't care about what the drivers are actually
controlling.
What's more of an issue for doing this is that the programming model
that ASoC offers really only fits well with decomposed systems where you
have discrete components offering meaningful control. That is the rule
in embedded systems but is much less often the case in other
environments and the further you get from that the more you'd have to
shoehorn things to fit into the ASoC model. If the ASoC model is a good
fit then people may want to use it but it won't be helpful for everyone.
That said, there are also problems due to the current code predating the
device model that prevent you having more than one ASoC card in your
system. There is a new version of ASoC in the asoc-v2-dev branch of
git://opensource.wolfsonmicro.com/linux-2.6-asoc which addresses this
but it's quite invasive so it's not a trivial merge. This is all at the
implementation detail level rather than the core concepts level, though,
and should get resolved in the forseeable future.
In practice the savings you get from this are very small - at worst
you're looking at things like powering up a high-power amplifier and
playing an audio signal through it when it's not actually connected.
These might consume hundreds of miliwatts (at worst) but you can achieve
an awful lot of the saving DAPM makes by simply muting the relevant
output. More typically you're looking at savings in the order of single
or double digit miliwatts.
That's just the convention that's been adopted by people writing
platform support - it's not an ASoC requirement.
If literally the same driver can be used then you probably want to have
a directory (eg, 'atmel') which is shared between the two platforms.
You can do if you like - the ASoC core actually calls this type of
driver a platform driver (the idea is that it should handle anything
that applies over multiple controllers, but in practice that's usually
just DMA).
The subsystem is there and can be used if it makes sense for a given
driver but as outlined above it's not going to work well for everyone.
--
