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

2016-03-31 Thread Fabio Estevam
On Thu, Mar 31, 2016 at 2:30 PM, Hans Christian Lønstad
 wrote:

> Completely agreed, just wandered if you could point me in some direction ,->

I am not familiar with GPU code. Maybe you could start a new thread
explaining in details this GPU issue.
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale


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

2016-03-31 Thread Hans Christian Lønstad


> On 31. mar. 2016, at 19.26, Fabio Estevam  wrote:
> 
> On Thu, Mar 31, 2016 at 2:22 PM, Hans Christian Lønstad
>  wrote:
> 
>> Implying the bug is in the SPI class driver and fixed in 4.6?
>> It appears to be changes in the spi-imx as well, so back porting might need 
>> to include this.
> 
> This issue is not i.MX6 related. There are reports on this issue with
> different SoCs.

As in TI SoC yes.
> 
>> If I find time, I might try out 4.6, but as said earlier, we are fine 
>> disabling DMA for now.
>> What´s more troubling with 4.1.15 is that vivante user space crashes opening 
>>  EGLFS.
>> (I noticed some config/board file changes regarding DMA_CMA that might point 
>> in this direction)
> 
> That's a different bug.

Completely agreed, just wandered if you could point me in some direction ,->

Hans

-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale


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

2016-03-31 Thread Fabio Estevam
On Thu, Mar 31, 2016 at 2:22 PM, Hans Christian Lønstad
 wrote:

> Implying the bug is in the SPI class driver and fixed in 4.6?
> It appears to be changes in the spi-imx as well, so back porting might need 
> to include this.

This issue is not i.MX6 related. There are reports on this issue with
different SoCs.

> If I find time, I might try out 4.6, but as said earlier, we are fine 
> disabling DMA for now.
> What´s more troubling with 4.1.15 is that vivante user space crashes opening  
> EGLFS.
> (I noticed some config/board file changes regarding DMA_CMA that might point 
> in this direction)

That's a different bug.
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale


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

2016-03-31 Thread Hans Christian Lønstad


> On 31. mar. 2016, at 00.42, Fabio Estevam  wrote:
> 
> Hi Hans,
> 
> On Wed, Mar 30, 2016 at 6:02 PM, Fabio Estevam  wrote:
> 
>> Looks like this same issue has been reported before:
>> https://freescale.jiveon.com/thread/375328
> 
> Just tested the steps provided in the community thread on a 4.6-rc1
> kernel and it worked well here.
> 
> I do see the failure on 4.1.15 though running the same sequence.
> 
> Can you also try it on 4.6-rc1 on your side? I think we will need to
> backport some of the fixes in drivers/spi/spi.c.


Implying the bug is in the SPI class driver and fixed in 4.6?
It appears to be changes in the spi-imx as well, so back porting might need to 
include this.

If I find time, I might try out 4.6, but as said earlier, we are fine disabling 
DMA for now.
What´s more troubling with 4.1.15 is that vivante user space crashes opening  
EGLFS.
(I noticed some config/board file changes regarding DMA_CMA that might point in 
this direction)

Hans

-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale


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

2016-03-30 Thread Fabio Estevam
Hi Hans,

On Wed, Mar 30, 2016 at 6:02 PM, Fabio Estevam  wrote:

> Looks like this same issue has been reported before:
> https://freescale.jiveon.com/thread/375328

Just tested the steps provided in the community thread on a 4.6-rc1
kernel and it worked well here.

I do see the failure on 4.1.15 though running the same sequence.

Can you also try it on 4.6-rc1 on your side? I think we will need to
backport some of the fixes in drivers/spi/spi.c.
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale


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

2016-03-30 Thread Fabio Estevam
On Wed, Mar 30, 2016 at 10:58 AM, Fabio Estevam  wrote:

> Thanks for reporting the issue.
>
> It would be better if we could fix the DMA issue instead of disabling it.
>
> If you are able to reproduce this with a mainline kernel, it would be
> nice to report this bug into the linux-spi mailing list, so that other
> people could potentially help with it.

Looks like this same issue has been reported before:
https://freescale.jiveon.com/thread/375328

And here too:
http://lists.infradead.org/pipermail/linux-mtd/2009-August/026817.html

Please report this on linux-mtd list so that we can hopefully have a
proper fix for this issue.
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale


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

2016-03-30 Thread Fabio Estevam
Hi Hans,

On Wed, Mar 30, 2016 at 3:14 AM, Hans Christian Lønstad
 wrote:

> 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.

Thanks for reporting the issue.

It would be better if we could fix the DMA issue instead of disabling it.

If you are able to reproduce this with a mainline kernel, it would be
nice to report this bug into the linux-spi mailing list, so that other
people could potentially help with it.
-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale


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

2016-03-30 Thread 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


h...@datarespons.no
www.datarespons.com
-




On 29. mar. 2016, at 22.44, Otavio Salvador 
> 
wrote:

Hello Hans,

(Adding Fabio Estevam on Cc)

On Tue, Mar 29, 2016 at 4:28 PM, Hans Christian Lønstad
> 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.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750

-- 
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale