Re: AT32 ASoC Driver Patches on alsa-devel

[Mark Brown]

On Thu, Jun 05, 2008 at 04:22:06PM +0200, Haavard Skinnemoen wrote:

> I have to admit I don't understand the current sound situation at all.
> With this driver, we now have:
>   * A "regular" ALSA driver for the AC97C (not based on ASoC)
>   * Two different "generic" AC97 layers: one in sound/pci/ac97 and one
>     in sound/soc/ac97 (the AC97C driver uses the former)

There is AC97 support in ASoC but there's no sound/soc/ac97?  Briefly,
the generic ALSA AC97 support is focused on handling standard AC97 parts
without additional features while the ASoC layer requires more per-board
setup but supports codecs with large extensions to the AC97 standard
such as the additional of secondary I2S interfaces that can't readily be
accomodated in the vanilla AC97 driver.

For systems using only AC97 codecs with only small non-standard features
the vanilla AC97 driver provides a turnkey solution with no machine
specific code at all.  It should be possible to implement it in terms of
ASoC but nobody has tried yet and it's not 100% clear that it's worth
the code churn.

>   * An OSS driver for the AP7000 Audio Bitstream DAC
>   * An i2s driver for the AT73C213 chip using the SSC controller and SPI

These drivers will be working in the way people were doing embedded
audio prior to ASoC.  Support for each system was provided by a
monolithic driver which implemented support for the codec, the audio
controller on the SoC and any other components on the board.  This
resulted in a lot of redundancy since multiple systems using the same
components would find it hard to share code for them and the
abstractions providing the reuse that did exist often ended up getting
done multiple times.

ASoC improves code reuse here by separating out the support for codecs
and SoC CPUs from the machine drivers, providing a layer for gluing them
together and fitting them into the ALSA core.  An ASoC machine driver
can be little more than the equivalent of "I have a codec of this type
connected to this I2S interface on my CPU and clocked in this way" but
it can support more complex scenarios.

It also provides a generic power management infrastructure for these
systems, allowing unused parts of the audio subsystem to be put into low
power states when they are not being used as part of an active audio
path.

>   * Another SSC driver based on the ASoC layer
>   * Some sort of "AT32 PCM" layer which apparently can only be used
>     with the SSC controller
>   * The above two being essentially identical to similar drivers for
>     AT91

These drivers provide the CPU side support for the system within ASoC.
I suspect from what you are saying that the two Atmel ASoC platform
driver sets could be implemented with a common core with some per-CPU
glue to plug them together but I've never looked at either platform in
sufficient detail.

The PCM layer in these drivers represents the DMA controller part of the
SoC hardware - the DMA control is split out in ASoC because most SoCs
have generic DMA engines which are shared between multiple audio
interface controllers (eg, I2S and AC97) so there's no point in
repeating the code to glue them into ALSA DMA.

> Can someone please help me out here? In particular, what is ASoC and
> why should I want to use it?

Hopefully I answered that above.  There's a more detailed overview in
Documentation/sound/alsa/soc/overview.txt:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/sound/alsa/soc/overview.txt;h=1e4c6d3655f2089c875ff381759ebd5528fe2ad3;hb=HEAD
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/