lkml.org 
[lkml]   [2015]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] dmaengine: bcm2835: Add slave dma support

Den 15.04.2015 16:37, skrev Martin Sperl:
>> On 15.04.2015, at 11:56, Noralf Trønnes <noralf@tronnes.org> wrote:
>> +#define MAX_LITE_TRANSFER (SZ_64K - 1)
>> +#define MAX_NORMAL_TRANSFER SZ_1G
> ...
>> + if (c->ch >= 8) /* LITE channel */
>> + max_size = MAX_LITE_TRANSFER;
>> + else
>> + max_size = MAX_NORMAL_TRANSFER;
>> + period_len = min(period_len, max_size);
>> + d->frames = (buf_len - 1) / (period_len + 1);
> I wonder if it is wise to split the transfers on 65535 bytes for the
> Lite DMA-channels - especially if you are transferring to word size
> registers (like SPI_FIFO), you still push 16384 words into the register
> and the last word of this transfer (word 16384) still is assumed 4 valid
> bytes by the device and thus gets operated upon - even if the last byte
> contains garbage from the DMA-transfer point of view.
>
> So maybe it is better to separate on SZ_64K-4 or better still SZ_32K to
> be on a power of 2 address boundary.

The datasheet is contradictory:
BCM2835 ARM Peripherals - 4.5 DMA LITE Engines
3. The DMA length register is now 16 bits, limiting the maximum
transferrable length to 65536 bytes.

A 16-bit register can't hold a value of 65536.
Either the max value is 65535 or the register is 17-bits wide.

There is currently no driver that we can use to test >32k buffers.
Unless someone disagrees, I will change this back to the SZ_32K
value from the original driver (and add a comment to explain that
32k is chosen to stay on the safe side).



\
 
 \ /
  Last update: 2015-04-15 21:21    [W:0.085 / U:1.752 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site