cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

overview.rst (3204B)


      1=======================
      2ALSA SoC Layer Overview
      3=======================
      4
      5The overall project goal of the ALSA System on Chip (ASoC) layer is to
      6provide better ALSA support for embedded system-on-chip processors (e.g.
      7pxa2xx, au1x00, iMX, etc) and portable audio codecs.  Prior to the ASoC
      8subsystem there was some support in the kernel for SoC audio, however it
      9had some limitations:-
     10
     11  * Codec drivers were often tightly coupled to the underlying SoC
     12    CPU. This is not ideal and leads to code duplication - for example,
     13    Linux had different wm8731 drivers for 4 different SoC platforms.
     14
     15  * There was no standard method to signal user initiated audio events (e.g.
     16    Headphone/Mic insertion, Headphone/Mic detection after an insertion
     17    event). These are quite common events on portable devices and often require
     18    machine specific code to re-route audio, enable amps, etc., after such an
     19    event.
     20
     21  * Drivers tended to power up the entire codec when playing (or
     22    recording) audio. This is fine for a PC, but tends to waste a lot of
     23    power on portable devices. There was also no support for saving
     24    power via changing codec oversampling rates, bias currents, etc.
     25
     26
     27ASoC Design
     28===========
     29
     30The ASoC layer is designed to address these issues and provide the following
     31features :-
     32
     33  * Codec independence. Allows reuse of codec drivers on other platforms
     34    and machines.
     35
     36  * Easy I2S/PCM audio interface setup between codec and SoC. Each SoC
     37    interface and codec registers its audio interface capabilities with the
     38    core and are subsequently matched and configured when the application
     39    hardware parameters are known.
     40
     41  * Dynamic Audio Power Management (DAPM). DAPM automatically sets the codec to
     42    its minimum power state at all times. This includes powering up/down
     43    internal power blocks depending on the internal codec audio routing and any
     44    active streams.
     45
     46  * Pop and click reduction. Pops and clicks can be reduced by powering the
     47    codec up/down in the correct sequence (including using digital mute). ASoC
     48    signals the codec when to change power states.
     49
     50  * Machine specific controls: Allow machines to add controls to the sound card
     51    (e.g. volume control for speaker amplifier).
     52
     53To achieve all this, ASoC basically splits an embedded audio system into
     54multiple re-usable component drivers :-
     55
     56  * Codec class drivers: The codec class driver is platform independent and
     57    contains audio controls, audio interface capabilities, codec DAPM
     58    definition and codec IO functions. This class extends to BT, FM and MODEM
     59    ICs if required. Codec class drivers should be generic code that can run
     60    on any architecture and machine.
     61
     62  * Platform class drivers: The platform class driver includes the audio DMA
     63    engine driver, digital audio interface (DAI) drivers (e.g. I2S, AC97, PCM)
     64    and any audio DSP drivers for that platform.
     65
     66  * Machine class driver: The machine driver class acts as the glue that
     67    describes and binds the other component drivers together to form an ALSA
     68    "sound card device". It handles any machine specific controls and
     69    machine level audio events (e.g. turning on an amp at start of playback).