Difference between revisions of "User:DanielDrake/MMP audio"

From OLPC
Jump to: navigation, search
(Created page with 'MMP audio is split up into several drivers that operate the audio-related functionality on the SoC, and a codec driver. This page aims to document my understanding of each softwa…')
(No difference)

Revision as of 18:18, 11 March 2013

MMP audio is split up into several drivers that operate the audio-related functionality on the SoC, and a codec driver. This page aims to document my understanding of each software component.

Driver components

sound/soc/pxa/mmp-sspa.c

This file drives the Synchronous Serial Port for Audio. We program the SSPA registers to request playback or recording, starting vs stopping a stream, as well as setting various parameters such as format and sample rate.

sound/soc/pxa/mmp-pcm.c

This driver coordinates the transfer of PCM (i.e. audio) data to or from the codec into memory.

sound/soc/codecs/rt5631.c

This is the codec driver, which turns digital PCM data into audible, analog sounds for playback, and the opposite for recording.

tdma

Data transfer and DMA

Taking playback as an example:

PCM audio data is written directly into the audio SRAM (this is the way that the driver is currently set up). The ASoC core calls into sspa, mmp-pcm and codec layers as appropriate so that things get set up for playback.

The SSPA layer has previously communicated some DMA parameters to the mmp-pcm layer. Specifically, it has set the DMA device address (dev_addr) in a structure shared between the two via snd_soc_dai_set_dma_data(). In the playback case, dev_addr is set to SSPA register 0x80 (SSPA_TX_DATA).

The mmp-pcm layer then uses the snd-dmaengine API to request that the audio data is copied (via the tdma driver) from audio SRAM to the write port of the SSPA - passing on the dev_addr that was set by the SSPA layer.

The above description might suggest that audio data could alternatively be reproduced by writing data to that register, but Mitch Bradley's investigation on MMP2 shows that this register simply cannot be used in this way, and also that the value of dev_addr is actually completely unused:
Reading from the SSPA RX FIFO via the SSPA_RX_DATA register and writing to the TX FIFO via the SSPA_TX_DATA register doesn't appear to be possible -- the only to move data to/from the FIFOs is by using the DMA engines.
On channel 0, which is the playback channel, all DMA source addresses are interpreted as being in audio SRAM, and all DMA destination addresses are ignored entirely, as channel 0 is hardwired to feed into the corresponding SSPA unit's TX FIFO). Consequently, whether destination address increment or destination address hold mode is chosen makes no difference at all. (similar story for the capture channel)

The data is encoded as a digital electronic signal and is sent to the codec, which then turns it into an analog signal sent to the speakers.