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 [email protected]<mailto:[email protected]> www.datarespons.com<http://www.datarespons.com/> ------------------------------------------------- On 29. mar. 2016, at 22.44, Otavio Salvador <[email protected]<mailto:[email protected]>> wrote: Hello Hans, (Adding Fabio Estevam on Cc) On Tue, Mar 29, 2016 at 4:28 PM, Hans Christian Lønstad <[email protected]<mailto:[email protected]>> 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
-- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
