On Sun, 30 Oct 2016 10:06:20 +0800 Chen-Yu Tsai wens@csie.org wrote:
Yes, I know that the burst size is always a power of 2. The best way to check it would be to change the {src,dts}_maxburst to a bitmap of the possible bursts as 0x0d for 1,4 and 8 bytes. But this asks for a lot of changes...
To be honest, I'm not really a big fan of those tree wide changes without any way to maintain compatibility. It ends up in a single, huge patch if we want to maintain bisectability that just isn't reviewable.
Looking at the dmaengine API, I believe we got it wrong.
max_burst in dma_slave_config denotes the largest amount of data a single transfer should be, as described in dmaengine.h:
- @src_maxburst: the maximum number of words (note: words, as in
- units of the src_addr_width member, not bytes) that can be sent
- in one burst to the device. Typically something like half the
- FIFO depth on I/O peripherals so you don't overflow it. This
- may or may not be applicable on memory sources.
- @dst_maxburst: same as src_maxburst but for destination target
- mutatis mutandis.
The DMA engine driver should be free to select whatever burst size that doesn't exceed this. So for max_burst = 4, the driver can select burst = 4 for controllers that do support it, or burst = 1 for those that don't, and do more bursts.
This also means we can increase max_burst for the audio codec, as the FIFO is 64 samples deep for stereo, or 128 samples for mono.
If we agree on the above I can send some patches for this.
That's fine to me, but this does not solve the main problem which is how/where are defined the possible bursts of a SoC.