Re: [PATCH v2 2/2] spi: spi-ti-qspi: Use bounce buffer if read buffer is not DMA'ble

[Cyrille Pitchen]

Hi all,

+ Richard and Boris as MTD maintainers

Le 25/04/2017 à 14:18, Vignesh R a écrit :
> 
> 
> On Friday 21 April 2017 10:36 PM, Mark Brown wrote:
>> On Tue, Apr 11, 2017 at 05:22:25PM +0530, Vignesh R wrote:
>>> Flash filesystems like JFFS2, UBIFS and MTD block layer can provide
>>> vmalloc'd or kmap'd buffers that cannot be mapped using dma_map_sg() and
>>> can potentially be in memory region above 32bit addressable region(ie
>>> buffers belonging to memory region backed by LPAE) of DMA, implement
>>> spi_flash_can_dma() interface to inform SPI core not to map such
>>> buffers.
>>
>> I'll apply this since it fixes bugs for your systems but it feels like
>> something that we should be moving further into the core since LPAE
>> isn't specific to your devices.  We should ideally have something
>> (possibly in the DMA mapping code even) which does the remapping without
>> the driver needing to know about it.
>>
> 
> I agree, there is a need to have generic remapping code. Also, I guess,
> once UBIFS is moved to use kmalloc'd buffers SPI flash devices will not
> have to worry much about vmalloc'd buffers.
> 

I've just discussed with Richard and Boris and AFAIK, nothing is planned
at the UBIFS side to replace vmalloc'd buffers by kmalloc'd buffers.
There are reasons for using vmalloc() but Richard can explain better
than me :)

Also, depending on the cache model used by Atmel SoCs, the spi-atmel.c
driver may suffer from the same issue too: using spi_map_buf() hence
mapping vmalloc'ed buffers for DMA usage will be OK with ARM Cortex A5
(PIPT data cache, so no cache aliasing issue at all) hence with SAMA5
series but is not OK for some older cores like ARM926 (VIVT data cache)
hence the SAM9 series.

So to fix the spi-atmel.c driver when used with SAM9 SoCs, we are
thinking about sending a first patch to simply disable the use of DMA
transfers on SAM9 SoCs in case of vmalloc'ed buffers and use CPU
transfers instead.
The code will be left unchanged for SAMA5 SoCs so there would be no
performance loss on those SoCs.
It won't be optimal on SAM9 SoCs but at least it would work.

Then in a new series, if nobody has started to work on this topic yet,
we could propose a generic solution using a bounce buffer at the SPI
core level. however we first need to think how we could do this.

Best regards,

Cyrille