Re: [PATCH 3/8] spi: davinci: limit the transfer size if DMA enabled

[Frode Isaksen <fisaksen@xxxxxxxxxxxx>]

On 22/03/2017 13:20, Peter Ujfalusi wrote:
> On 03/22/2017 01:35 PM, Sekhar Nori wrote:
>> On Wednesday 22 March 2017 04:41 PM, Frode Isaksen wrote:
>> I guess this means that most IPs continue to get more missed sync events
>> even after the first sync event is generated at end of MAX_NR_SG PaRAMs.
>> And may be even that first sync event miss is a problem because the IP
>> does not pause and ends up shifting data in the shift register anyway.
>>
>> If this is so broken, should edma driver not refuse to handle more than
>> MAX_NR_SG for all transfers but mem-to-mem transfers?
>
> DM355, OMAP-L138, etc have only 128 paRAM slots. If we lift the restriction on
> the number of paRAM slots a channel can take, then DMA will most likely going
> to stop working: If any peripherals request 128 long SG transfer (and MMC
> easily does that alone) then we will have no available paRAM slot for other
> clients.
>
> It might be possible to start the paRAM slot update for the next batch already
> when we have 1 or 2 slots to be processed, but that is going to be tricky and
> not even reliable.
Note that with SPI, a workaround for this issue has been found by using the rx
buffer as the dummy tx buffer when doing read-only transfers (this is the case
that fails). With this, the rx and tx paRAM slots are reconfigured at the same time.

Thanks,
Frode
>
> Note: audio also sets limit on the number of periods to avoid this
> reconfiguration of paRAM slots.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html