diff options
| author | jepler <jepler@gmail.com> | 2019-08-28 16:55:17 -0500 |
|---|---|---|
| committer | jepler <jepler@gmail.com> | 2019-08-28 17:00:22 -0500 |
| commit | 30a934637394ab3e58e10100d400e0dbe6f3ca50 (patch) | |
| tree | 9ff729cd5e7cd838a4e5c7b2b339261fe05298bc /shared-module | |
| parent | 0b00787b4dae66c865f81f4e543297b6cb1c1125 (diff) | |
samd: audio_dma: Track channel allocation
Previously, we depended on allocated channels to always be
"dma_channel_enabled". However, (A) sometimes, many operations
would take place between find_free_audio_dma_channel and
audio_dma_enable_channel, and (B) some debugging I did led me to believe
that "dma_channel_enabled" would become false when the hardware ended
a scheduled DMA transaction, but while a CP object would still think it
owned the DMA channel.
((B) is not documented in the datasheet and I am not 100% convinced that
my debugging session was not simply missing where we were disabling the
channel, but in either case, it shows a need to directly track allocated
separately from enabled)
Therefore,
* Add audio_dma_{allocate,free}_channel.
* audio_dma_free_channel implies audio_dma_disable_channel
* track via a new array audio_dma_allocated[]
* clear all allocated flags on soft-reboot
* Convert find_free_audio_dma_channel to audio_dma_allocate_channel
* use audio_dma_allocated[] instead of dma_channel_enabled() to check
availability
* remove find_free_audio_dma_channel
* For each one, find a matching audio_dma_disable_channel to convert
to audio_dma_free_channel
Closes: #2058
Diffstat (limited to 'shared-module')
0 files changed, 0 insertions, 0 deletions
