Mark Brown wrote:
battery life by setting up very big DMAs. On a similar vein is it worth considering making this feature entirely optional and/or falling back to non-SRAM if SRAM allocation fails?
Yes Chris Ring also asked for that, and it is fairly easy to allocate another SDRAM buffer to use for the SRAM. But I'd rather another patch after this
Incremental patches sounds fine to me.
if I need to use plaform data. Maybe audio_sram_buffer_size = 0 in platform data to mean use SDRAM?
The only potential problem I see there is that that'd make disabling the SDRAM the default. I guess if people have been living without it so far that's not a big problem, though, and it'll stop people getting surprised by audio grabbing SDRAM when they weren't expecting it.
I guess if you're using SDRAM there's no need for the double buffering (though that could be a third patch)?
Even when using SDRAM, there is still another advantage to double buffering. That is tolerating very long interrupt latency on dma completion. The current code sets up the next periods dma transfer on dma completion. This could easily lead to underruns. So, even in this case, I think double buffering is worth the extra dma engine copy.
Troy