On Sun, 30 Oct 2016 10:06:20 +0800
Chen-Yu Tsai <wens@xxxxxxxx> 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.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
