[PATCH] dmaengine: bcm2835: Add slave dma support

[Noralf Trønnes]

Den 16.04.2015 08:30, skrev Rogier Wolff:
> On Wed, Apr 15, 2015 at 08:53:07PM +0200, Noralf Trønnes wrote:
>
>> A 16-bit register can't hold a value of 65536.
>> Either the max value is 65535 or the register is 17-bits wide.
> It is common for hardware registers to have the value "0" mean 65536
> in case of a 16-bit register.
>
> The hardware would then FIRST decrement the register and THEN check
> for zero. This results in the behaviour that "1" requires one cycle to
> complete, "10" requires ten cycles, and "0" means the same as the
> total number of bitpatterns possible in the register. (256 for an
> 8-bit register, 65536 for a 16-bit register).
>
> Another way to implement such a register in hardware would "check for
> zero" first, and not do antyhing if the register equals zero. This
> results in differnet behaviour for the "0" value.
>
> That said: IMHO, the overhead of setting up 2 transfers for each 64k
> block as opposed to only one results in such a small performance
> penalty that I'd prefer to play it safe unless you're very sure you
> can adequately test it. (Another option would be to set the maximum
> transfer size to 0xf000: 60kbytes. Less than 10% extra transfers in
> the long run than when aiming for the edge...)

Dom Cobley (Raspberry Pi) has just been in contact with
the hardware designer. He said:
65535 is the maximum transfer length of a LITE channel.
65536 will be treated as zero which is undefined
(it will actually do one transfer then stop)

Additional info from the datasheet about Lite channels:
The internal data structure is 128 bits instead of 256 bits.
This means that if you do a 128 bit wide read burst of more
than 1 beat, the DMA input register will be full and the read
bus will be stalled. The normal DMA engine can accept a read
burst of 2 without stalling. If you do a narrow 32 bit read
burst from the peripherals then the lite engine can cope with
a burst of 4 as opposed to a burst of 8 for the normal engine.

This suggest to me that we could go as far as the last 128-bit
boundary like this: (SZ_64K - 16)