[meta-freescale] [PATCH] spi-imx -> make DMA optional through DT

[Hans Christian Lønstad]

Thank you for your quick response. Please find my comments inserted below.

BTW: will the current vivante cpu user space code run on the 4.1.15_ga kernel?

Regards

Hans Chr
--------------------------------------------------
Hans Christian Lønstad, CTO
Data Respons AS
Sandviksveien 26
P.O. Box 489
NO-1323 Høvik, Norway


hcl at datarespons.no<mailto:hcl at datarespons.no>
www.datarespons.com<http://www.datarespons.com/>
-------------------------------------------------




On 29. mar. 2016, at 22.44, Otavio Salvador <otavio.salvador at ossystems.com.br<mailto:otavio.salvador at ossystems.com.br>> wrote:

Hello Hans,

(Adding Fabio Estevam on Cc)

On Tue, Mar 29, 2016 at 4:28 PM, Hans Christian Lønstad
<hcl at datarespons.no<mailto:hcl at datarespons.no>> wrote:
This patch applies to kernel 4.1.15_ga and fixes a regression for UBIFS on
SPI NOR introduced by assigning DMA channels in DT

When UBIFS uses SPI NOR devices, the IO buffer allocation using vmalloc
creates problems when the SPI controller is DMA based (as it is for some
ARM SoC's).
Introduce a "nodma" boolean DT attribute as a fix for imx SoC.

Is this a NXP's specific regression? or this is also found on mainline
kernel? If so, we ought to address this on mainline and backport the
referred fixes for the issue.



The issue surfaced after DT introduced the DMA functionality (imx6qdl.dtsi). This applies to mainline kernels (checked 4.1 and up) as well.
It is my understanding that SPI DMA is performed using scatter/gather which should be able to handle vmalloc’ed memory, so the question remains wether the root cause lies within the DMA code or is some kind of coherence issue within the UBIFS code.

Anyway, the benefit from DMA might be questionable for this use case (we are using SPI NOR for VPD product data), so we are happy just disabling it.

The issue must be considered grave as it bricks systemd trying to mount an UBIFS during startup.


--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20160330/4606c1c2/attachment.html>