[alsa-devel] [PATCH 14/18] ASoC: davinci: Add edma dmaengine platform driver

Lars-Peter Clausen lars at metafoo.de
Thu Mar 13 13:09:30 CET 2014


On 03/13/2014 12:56 PM, Peter Ujfalusi wrote:
> On 03/13/2014 12:28 PM, Lars-Peter Clausen wrote:
>> On 03/13/2014 10:18 AM, Peter Ujfalusi wrote: [...]
>>> +static const struct snd_pcm_hardware edma_pcm_hardware = { +    .info
>>> = SNDRV_PCM_INFO_MMAP | +                  SNDRV_PCM_INFO_MMAP_VALID | +
>>> SNDRV_PCM_INFO_BATCH | +                  SNDRV_PCM_INFO_PAUSE |
>>> SNDRV_PCM_INFO_RESUME | +                  SNDRV_PCM_INFO_INTERLEAVED, +
>>> .buffer_bytes_max    = 128 * 1024, +    .period_bytes_min    = 32, +
>>> .period_bytes_max    = 64 * 1024, +    .periods_min        = 2, +
>>> .periods_max        = 19, /* Limit by edma dmaengine driver */ +};
>>
>> The idea is that we can auto-discover all the things using the
>> dma_slave_caps API. Too bad we removed the possibility to specify the
>> maximum number of segments from the API. Maybe we need to add it back. Is
>> the 19 a hard-limit or could it be worked around by software in the
>> dmaengine driver?
>
> The edma dmaengine driver will refuse to configure more than 20 paRAM slots (1
> for the channel + 19 for the periods). Depending on the SoC we might have
> different number of paRAM entries available. The intention with the limit was
> to prevent cases when we run out of paRAM entires for other devices because
> audio took most of them.

The reason why we removed the max_segments field from the slave_caps struct 
was because we though it should be possible to, even when the hardware only 
supports a fixed amount of segments, emulate support for more in software. 
If this is not the case with the edma, we need to bring this field back.



More information about the Alsa-devel mailing list