[PATCH 0/5] mtd: nand: Fix support for NAND DMA Prefetch

[PATCH 0/5] mtd: nand: Fix support for NAND DMA Prefetch

[Franklin S Cooper Jr]

NAND dma prefetch has been broken for awhile and seems to have only
worked for sdma based devices.

This patchset fixes DMA prefetch to work on both edma and sdma devices

Tested on:
am335x general purpose evm
am437x general purpose evm
am37x general purpose evm

This patchset depends on Roger Quadros recent v4 GPMC/NAND patchset

https://github.com/rogerq/linux.git
branch: for-v4.4/gpmc-v4

Franklin S Cooper Jr (5):
  mtd: nand: omap2: Support parsing dma channel information from DT
  mtd: nand: omap2: Start dma request before enabling prefetch
  mtd: nand: omap2: Fix high memory dma prefetch transfer
  ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel
  ARM: OMAP2+: Update gpmc and nand DT binding documentation

 .../bindings/memory-controllers/omap-gpmc.txt      |  7 ++++++-
 .../devicetree/bindings/mtd/gpmc-nand.txt          |  2 ++
 arch/arm/boot/dts/am33xx.dtsi                      |  2 ++
 arch/arm/boot/dts/am4372.dtsi                      |  2 ++
 arch/arm/boot/dts/dm816x.dtsi                      |  2 ++
 arch/arm/boot/dts/omap3.dtsi                       |  2 ++
 drivers/mtd/nand/omap2.c                           | 24 ++++++++--------------
 7 files changed, 25 insertions(+), 16 deletions(-)

-- 
2.6.1

[PATCH 0/5] mtd: nand: Fix support for NAND DMA Prefetch

[Franklin S Cooper Jr]

NAND dma prefetch has been broken for awhile and seems to have only
worked for sdma based devices.

This patchset fixes DMA prefetch to work on both edma and sdma devices

Tested on:
am335x general purpose evm
am437x general purpose evm
am37x general purpose evm

This patchset depends on Roger Quadros recent v4 GPMC/NAND patchset

https://github.com/rogerq/linux.git
branch: for-v4.4/gpmc-v4

Franklin S Cooper Jr (5):
  mtd: nand: omap2: Support parsing dma channel information from DT
  mtd: nand: omap2: Start dma request before enabling prefetch
  mtd: nand: omap2: Fix high memory dma prefetch transfer
  ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel
  ARM: OMAP2+: Update gpmc and nand DT binding documentation

 .../bindings/memory-controllers/omap-gpmc.txt      |  7 ++++++-
 .../devicetree/bindings/mtd/gpmc-nand.txt          |  2 ++
 arch/arm/boot/dts/am33xx.dtsi                      |  2 ++
 arch/arm/boot/dts/am4372.dtsi                      |  2 ++
 arch/arm/boot/dts/dm816x.dtsi                      |  2 ++
 arch/arm/boot/dts/omap3.dtsi                       |  2 ++
 drivers/mtd/nand/omap2.c                           | 24 ++++++++--------------
 7 files changed, 25 insertions(+), 16 deletions(-)

-- 
2.6.1

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

[PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr]

Switch from dma_request_channel to allow passing dma channel
information from DT rather than hardcoding a value.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
---
 drivers/mtd/nand/omap2.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d0f2620..957c32f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
 		dma_cap_zero(mask);
 		dma_cap_set(DMA_SLAVE, mask);
 		sig = OMAP24XX_DMA_GPMC;
-		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+		info->dma = dma_request_slave_channel_compat(mask,
+			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
+
 		if (!info->dma) {
 			dev_err(&pdev->dev, "DMA engine request failed\n");
 			err = -ENXIO;
-- 
2.6.1

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> Switch from dma_request_channel to allow passing dma channel
> information from DT rather than hardcoding a value.
> 
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>

Acked-by: Roger Quadros <rogerq@ti.com>

> ---
>  drivers/mtd/nand/omap2.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index d0f2620..957c32f 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>  		dma_cap_zero(mask);
>  		dma_cap_set(DMA_SLAVE, mask);
>  		sig = OMAP24XX_DMA_GPMC;
> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
> +		info->dma = dma_request_slave_channel_compat(mask,
> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
> +
>  		if (!info->dma) {
>  			dev_err(&pdev->dev, "DMA engine request failed\n");
>  			err = -ENXIO;
> 

cheers,
-roger

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> Switch from dma_request_channel to allow passing dma channel
> information from DT rather than hardcoding a value.
> 
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>

Acked-by: Roger Quadros <rogerq@ti.com>

> ---
>  drivers/mtd/nand/omap2.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index d0f2620..957c32f 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>  		dma_cap_zero(mask);
>  		dma_cap_set(DMA_SLAVE, mask);
>  		sig = OMAP24XX_DMA_GPMC;
> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
> +		info->dma = dma_request_slave_channel_compat(mask,
> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
> +
>  		if (!info->dma) {
>  			dev_err(&pdev->dev, "DMA engine request failed\n");
>  			err = -ENXIO;
> 

cheers,
-roger

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

Franklin,

On 14/10/15 14:36, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Switch from dma_request_channel to allow passing dma channel
>> information from DT rather than hardcoding a value.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> 
> Acked-by: Roger Quadros <rogerq@ti.com>
> 
>> ---
>>  drivers/mtd/nand/omap2.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index d0f2620..957c32f 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>  		dma_cap_zero(mask);
>>  		dma_cap_set(DMA_SLAVE, mask);
>>  		sig = OMAP24XX_DMA_GPMC;
>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>> +		info->dma = dma_request_slave_channel_compat(mask,
>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>> +

Just discovered that you are using the parent device node.

How about moving the dma bindings to the nand node instead and using
pdev->dev here?

>>  		if (!info->dma) {
>>  			dev_err(&pdev->dev, "DMA engine request failed\n");
>>  			err = -ENXIO;
>>
> 

cheers,
-roger

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

Franklin,

On 14/10/15 14:36, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Switch from dma_request_channel to allow passing dma channel
>> information from DT rather than hardcoding a value.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> 
> Acked-by: Roger Quadros <rogerq@ti.com>
> 
>> ---
>>  drivers/mtd/nand/omap2.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index d0f2620..957c32f 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>  		dma_cap_zero(mask);
>>  		dma_cap_set(DMA_SLAVE, mask);
>>  		sig = OMAP24XX_DMA_GPMC;
>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>> +		info->dma = dma_request_slave_channel_compat(mask,
>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>> +

Just discovered that you are using the parent device node.

How about moving the dma bindings to the nand node instead and using
pdev->dev here?

>>  		if (!info->dma) {
>>  			dev_err(&pdev->dev, "DMA engine request failed\n");
>>  			err = -ENXIO;
>>
> 

cheers,
-roger

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/14/2015 06:52 AM, Roger Quadros wrote:
> Franklin,
>
> On 14/10/15 14:36, Roger Quadros wrote:
>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>> Switch from dma_request_channel to allow passing dma channel
>>> information from DT rather than hardcoding a value.
>>>
>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>> Acked-by: Roger Quadros <rogerq@ti.com>
>>
>>> ---
>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>> index d0f2620..957c32f 100644
>>> --- a/drivers/mtd/nand/omap2.c
>>> +++ b/drivers/mtd/nand/omap2.c
>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>  		dma_cap_zero(mask);
>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>  		sig = OMAP24XX_DMA_GPMC;
>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>> +
> Just discovered that you are using the parent device node.
>
> How about moving the dma bindings to the nand node instead and using
> pdev->dev here?
Roger,

>From what I can tell the interrupt number and the dma channel will always be
the same no matter what. Doesn't matter if you have multiple nands or a
combination of nands and nors. Since that is the case I think it just makes
sense to leave it in the gpmc parent node and define it once.
>>>  		if (!info->dma) {
>>>  			dev_err(&pdev->dev, "DMA engine request failed\n");
>>>  			err = -ENXIO;
>>>
> cheers,
> -roger
>

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/14/2015 06:52 AM, Roger Quadros wrote:
> Franklin,
>
> On 14/10/15 14:36, Roger Quadros wrote:
>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>> Switch from dma_request_channel to allow passing dma channel
>>> information from DT rather than hardcoding a value.
>>>
>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>> Acked-by: Roger Quadros <rogerq@ti.com>
>>
>>> ---
>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>> index d0f2620..957c32f 100644
>>> --- a/drivers/mtd/nand/omap2.c
>>> +++ b/drivers/mtd/nand/omap2.c
>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>  		dma_cap_zero(mask);
>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>  		sig = OMAP24XX_DMA_GPMC;
>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>> +
> Just discovered that you are using the parent device node.
>
> How about moving the dma bindings to the nand node instead and using
> pdev->dev here?
Roger,

>From what I can tell the interrupt number and the dma channel will always be
the same no matter what. Doesn't matter if you have multiple nands or a
combination of nands and nors. Since that is the case I think it just makes
sense to leave it in the gpmc parent node and define it once.
>>>  		if (!info->dma) {
>>>  			dev_err(&pdev->dev, "DMA engine request failed\n");
>>>  			err = -ENXIO;
>>>
> cheers,
> -roger
>

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
> 
> 
> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>> Franklin,
>>
>> On 14/10/15 14:36, Roger Quadros wrote:
>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>> Switch from dma_request_channel to allow passing dma channel
>>>> information from DT rather than hardcoding a value.
>>>>
>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>> Acked-by: Roger Quadros <rogerq@ti.com>
>>>
>>>> ---
>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>> index d0f2620..957c32f 100644
>>>> --- a/drivers/mtd/nand/omap2.c
>>>> +++ b/drivers/mtd/nand/omap2.c
>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>  		dma_cap_zero(mask);
>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>> +
>> Just discovered that you are using the parent device node.
>>
>> How about moving the dma bindings to the nand node instead and using
>> pdev->dev here?
> Roger,
> 
> From what I can tell the interrupt number and the dma channel will always be
> the same no matter what. Doesn't matter if you have multiple nands or a
> combination of nands and nors. Since that is the case I think it just makes
> sense to leave it in the gpmc parent node and define it once.

Is prefetch/writepost dma used for NOR or any other GPMC peripheral
or only for NAND?

Let's also get Tony's inputs on this.

>>>>  		if (!info->dma) {
>>>>  			dev_err(&pdev->dev, "DMA engine request failed\n");
>>>>  			err = -ENXIO;
>>>>

--
cheers,
-roger

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
> 
> 
> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>> Franklin,
>>
>> On 14/10/15 14:36, Roger Quadros wrote:
>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>> Switch from dma_request_channel to allow passing dma channel
>>>> information from DT rather than hardcoding a value.
>>>>
>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>> Acked-by: Roger Quadros <rogerq@ti.com>
>>>
>>>> ---
>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>> index d0f2620..957c32f 100644
>>>> --- a/drivers/mtd/nand/omap2.c
>>>> +++ b/drivers/mtd/nand/omap2.c
>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>  		dma_cap_zero(mask);
>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>> +
>> Just discovered that you are using the parent device node.
>>
>> How about moving the dma bindings to the nand node instead and using
>> pdev->dev here?
> Roger,
> 
> From what I can tell the interrupt number and the dma channel will always be
> the same no matter what. Doesn't matter if you have multiple nands or a
> combination of nands and nors. Since that is the case I think it just makes
> sense to leave it in the gpmc parent node and define it once.

Is prefetch/writepost dma used for NOR or any other GPMC peripheral
or only for NAND?

Let's also get Tony's inputs on this.

>>>>  		if (!info->dma) {
>>>>  			dev_err(&pdev->dev, "DMA engine request failed\n");
>>>>  			err = -ENXIO;
>>>>

--
cheers,
-roger

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/14/2015 09:11 AM, Roger Quadros wrote:
> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>
>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>> Franklin,
>>>
>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>> information from DT rather than hardcoding a value.
>>>>>
>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>>> Acked-by: Roger Quadros <rogerq@ti.com>
>>>>
>>>>> ---
>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>> index d0f2620..957c32f 100644
>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>>  		dma_cap_zero(mask);
>>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>>> +
>>> Just discovered that you are using the parent device node.
>>>
>>> How about moving the dma bindings to the nand node instead and using
>>> pdev->dev here?
>> Roger,
>>
>> From what I can tell the interrupt number and the dma channel will always be
>> the same no matter what. Doesn't matter if you have multiple nands or a
>> combination of nands and nors. Since that is the case I think it just makes
>> sense to leave it in the gpmc parent node and define it once.
> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
> or only for NAND?
The dma seems tied to the prefetch. From what I can tell the prefetch is only
used by nand.
>
> Let's also get Tony's inputs on this.
Sure.
>
>>>>>  		if (!info->dma) {
>>>>>  			dev_err(&pdev->dev, "DMA engine request failed\n");
>>>>>  			err = -ENXIO;
>>>>>
> --
> cheers,
> -roger

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/14/2015 09:11 AM, Roger Quadros wrote:
> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>
>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>> Franklin,
>>>
>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>> information from DT rather than hardcoding a value.
>>>>>
>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
>>>> Acked-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>>>>
>>>>> ---
>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>> index d0f2620..957c32f 100644
>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>>  		dma_cap_zero(mask);
>>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>>> +
>>> Just discovered that you are using the parent device node.
>>>
>>> How about moving the dma bindings to the nand node instead and using
>>> pdev->dev here?
>> Roger,
>>
>> From what I can tell the interrupt number and the dma channel will always be
>> the same no matter what. Doesn't matter if you have multiple nands or a
>> combination of nands and nors. Since that is the case I think it just makes
>> sense to leave it in the gpmc parent node and define it once.
> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
> or only for NAND?
The dma seems tied to the prefetch. From what I can tell the prefetch is only
used by nand.
>
> Let's also get Tony's inputs on this.
Sure.
>
>>>>>  		if (!info->dma) {
>>>>>  			dev_err(&pdev->dev, "DMA engine request failed\n");
>>>>>  			err = -ENXIO;
>>>>>
> --
> cheers,
> -roger

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

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Tony Lindgren]

* Franklin S Cooper Jr. <fcooper@ti.com> [151014 07:37]:
> 
> 
> On 10/14/2015 09:11 AM, Roger Quadros wrote:
> > On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
> >>
> >> On 10/14/2015 06:52 AM, Roger Quadros wrote:
> >>> Franklin,
> >>>
> >>> On 14/10/15 14:36, Roger Quadros wrote:
> >>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> >>>>> Switch from dma_request_channel to allow passing dma channel
> >>>>> information from DT rather than hardcoding a value.
> >>>>>
> >>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> >>>> Acked-by: Roger Quadros <rogerq@ti.com>
> >>>>
> >>>>> ---
> >>>>>  drivers/mtd/nand/omap2.c | 4 +++-
> >>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >>>>> index d0f2620..957c32f 100644
> >>>>> --- a/drivers/mtd/nand/omap2.c
> >>>>> +++ b/drivers/mtd/nand/omap2.c
> >>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
> >>>>>  		dma_cap_zero(mask);
> >>>>>  		dma_cap_set(DMA_SLAVE, mask);
> >>>>>  		sig = OMAP24XX_DMA_GPMC;
> >>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
> >>>>> +		info->dma = dma_request_slave_channel_compat(mask,
> >>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
> >>>>> +
> >>> Just discovered that you are using the parent device node.
> >>>
> >>> How about moving the dma bindings to the nand node instead and using
> >>> pdev->dev here?
> >> Roger,
> >>
> >> From what I can tell the interrupt number and the dma channel will always be
> >> the same no matter what. Doesn't matter if you have multiple nands or a
> >> combination of nands and nors. Since that is the case I think it just makes
> >> sense to leave it in the gpmc parent node and define it once.
> > Is prefetch/writepost dma used for NOR or any other GPMC peripheral
> > or only for NAND?
> The dma seems tied to the prefetch. From what I can tell the prefetch is only
> used by nand.
> >
> > Let's also get Tony's inputs on this.
> Sure.

Hmm so what would keep other devices from using the prefetch?

Regards,

Tony

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Tony Lindgren]

* Franklin S Cooper Jr. <fcooper-l0cyMroinI0@public.gmane.org> [151014 07:37]:
> 
> 
> On 10/14/2015 09:11 AM, Roger Quadros wrote:
> > On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
> >>
> >> On 10/14/2015 06:52 AM, Roger Quadros wrote:
> >>> Franklin,
> >>>
> >>> On 14/10/15 14:36, Roger Quadros wrote:
> >>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> >>>>> Switch from dma_request_channel to allow passing dma channel
> >>>>> information from DT rather than hardcoding a value.
> >>>>>
> >>>>> Signed-off-by: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
> >>>> Acked-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> >>>>
> >>>>> ---
> >>>>>  drivers/mtd/nand/omap2.c | 4 +++-
> >>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >>>>> index d0f2620..957c32f 100644
> >>>>> --- a/drivers/mtd/nand/omap2.c
> >>>>> +++ b/drivers/mtd/nand/omap2.c
> >>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
> >>>>>  		dma_cap_zero(mask);
> >>>>>  		dma_cap_set(DMA_SLAVE, mask);
> >>>>>  		sig = OMAP24XX_DMA_GPMC;
> >>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
> >>>>> +		info->dma = dma_request_slave_channel_compat(mask,
> >>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
> >>>>> +
> >>> Just discovered that you are using the parent device node.
> >>>
> >>> How about moving the dma bindings to the nand node instead and using
> >>> pdev->dev here?
> >> Roger,
> >>
> >> From what I can tell the interrupt number and the dma channel will always be
> >> the same no matter what. Doesn't matter if you have multiple nands or a
> >> combination of nands and nors. Since that is the case I think it just makes
> >> sense to leave it in the gpmc parent node and define it once.
> > Is prefetch/writepost dma used for NOR or any other GPMC peripheral
> > or only for NAND?
> The dma seems tied to the prefetch. From what I can tell the prefetch is only
> used by nand.
> >
> > Let's also get Tony's inputs on this.
> Sure.

Hmm so what would keep other devices from using the prefetch?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/14/2015 11:18 AM, Tony Lindgren wrote:
> * Franklin S Cooper Jr. <fcooper@ti.com> [151014 07:37]:
>>
>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>> Franklin,
>>>>>
>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>
>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>>>>> Acked-by: Roger Quadros <rogerq@ti.com>
>>>>>>
>>>>>>> ---
>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>> index d0f2620..957c32f 100644
>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>>>>  		dma_cap_zero(mask);
>>>>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>>>>> +
>>>>> Just discovered that you are using the parent device node.
>>>>>
>>>>> How about moving the dma bindings to the nand node instead and using
>>>>> pdev->dev here?
>>>> Roger,
>>>>
>>>> From what I can tell the interrupt number and the dma channel will always be
>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>> combination of nands and nors. Since that is the case I think it just makes
>>>> sense to leave it in the gpmc parent node and define it once.
>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>> or only for NAND?
>> The dma seems tied to the prefetch. From what I can tell the prefetch is only
>> used by nand.
>>> Let's also get Tony's inputs on this.
>> Sure.
> Hmm so what would keep other devices from using the prefetch
Looking at the TRM any references to the prefetch are always with respect to
NAND.

I also see the below mentioned in the TRM.
Pre-fetch and write posting engine associated with system DMA to get full performance from NAND
device with minimum impact on NOR/SRAM concurrent access.
>
> Regards,
>
> Tony

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/14/2015 11:18 AM, Tony Lindgren wrote:
> * Franklin S Cooper Jr. <fcooper-l0cyMroinI0@public.gmane.org> [151014 07:37]:
>>
>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>> Franklin,
>>>>>
>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>
>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
>>>>>> Acked-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>>>>>>
>>>>>>> ---
>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>> index d0f2620..957c32f 100644
>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>>>>  		dma_cap_zero(mask);
>>>>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>>>>> +
>>>>> Just discovered that you are using the parent device node.
>>>>>
>>>>> How about moving the dma bindings to the nand node instead and using
>>>>> pdev->dev here?
>>>> Roger,
>>>>
>>>> From what I can tell the interrupt number and the dma channel will always be
>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>> combination of nands and nors. Since that is the case I think it just makes
>>>> sense to leave it in the gpmc parent node and define it once.
>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>> or only for NAND?
>> The dma seems tied to the prefetch. From what I can tell the prefetch is only
>> used by nand.
>>> Let's also get Tony's inputs on this.
>> Sure.
> Hmm so what would keep other devices from using the prefetch
Looking at the TRM any references to the prefetch are always with respect to
NAND.

I also see the below mentioned in the TRM.
Pre-fetch and write posting engine associated with system DMA to get full performance from NAND
device with minimum impact on NOR/SRAM concurrent access.
>
> Regards,
>
> Tony

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

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Tony Lindgren]

* Franklin S Cooper Jr. <fcooper@ti.com> [151014 09:27]:
> 
> 
> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
> > * Franklin S Cooper Jr. <fcooper@ti.com> [151014 07:37]:
> >>
> >> On 10/14/2015 09:11 AM, Roger Quadros wrote:
> >>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
> >>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
> >>>>> Franklin,
> >>>>>
> >>>>> On 14/10/15 14:36, Roger Quadros wrote:
> >>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> >>>>>>> Switch from dma_request_channel to allow passing dma channel
> >>>>>>> information from DT rather than hardcoding a value.
> >>>>>>>
> >>>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> >>>>>> Acked-by: Roger Quadros <rogerq@ti.com>
> >>>>>>
> >>>>>>> ---
> >>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
> >>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >>>>>>> index d0f2620..957c32f 100644
> >>>>>>> --- a/drivers/mtd/nand/omap2.c
> >>>>>>> +++ b/drivers/mtd/nand/omap2.c
> >>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
> >>>>>>>  		dma_cap_zero(mask);
> >>>>>>>  		dma_cap_set(DMA_SLAVE, mask);
> >>>>>>>  		sig = OMAP24XX_DMA_GPMC;
> >>>>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
> >>>>>>> +		info->dma = dma_request_slave_channel_compat(mask,
> >>>>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
> >>>>>>> +
> >>>>> Just discovered that you are using the parent device node.
> >>>>>
> >>>>> How about moving the dma bindings to the nand node instead and using
> >>>>> pdev->dev here?
> >>>> Roger,
> >>>>
> >>>> From what I can tell the interrupt number and the dma channel will always be
> >>>> the same no matter what. Doesn't matter if you have multiple nands or a
> >>>> combination of nands and nors. Since that is the case I think it just makes
> >>>> sense to leave it in the gpmc parent node and define it once.
> >>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
> >>> or only for NAND?
> >> The dma seems tied to the prefetch. From what I can tell the prefetch is only
> >> used by nand.
> >>> Let's also get Tony's inputs on this.
> >> Sure.
> > Hmm so what would keep other devices from using the prefetch
> Looking at the TRM any references to the prefetch are always with respect to
> NAND.
> 
> I also see the below mentioned in the TRM.
> Pre-fetch and write posting engine associated with system DMA to get full performance from NAND
> device with minimum impact on NOR/SRAM concurrent access.

OK up to you guys to figure out if it may be usable in a generic way then :)

Regards,

Tony

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/14/2015 01:13 PM, Tony Lindgren wrote:
> * Franklin S Cooper Jr. <fcooper@ti.com> [151014 09:27]:
>>
>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
>>> * Franklin S Cooper Jr. <fcooper@ti.com> [151014 07:37]:
>>>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>>>> Franklin,
>>>>>>>
>>>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>>>>>>> Acked-by: Roger Quadros <rogerq@ti.com>
>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>>>> index d0f2620..957c32f 100644
>>>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>>>>>>  		dma_cap_zero(mask);
>>>>>>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>>>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>>>>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>>>>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>>>>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>>>>>>> +
>>>>>>> Just discovered that you are using the parent device node.
>>>>>>>
>>>>>>> How about moving the dma bindings to the nand node instead and using
>>>>>>> pdev->dev here?
>>>>>> Roger,
>>>>>>
>>>>>> From what I can tell the interrupt number and the dma channel will always be
>>>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>>>> combination of nands and nors. Since that is the case I think it just makes
>>>>>> sense to leave it in the gpmc parent node and define it once.
>>>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>>>> or only for NAND?
>>>> The dma seems tied to the prefetch. From what I can tell the prefetch is only
>>>> used by nand.
>>>>> Let's also get Tony's inputs on this.
>>>> Sure.
>>> Hmm so what would keep other devices from using the prefetch
>> Looking at the TRM any references to the prefetch are always with respect to
>> NAND.
>>
>> I also see the below mentioned in the TRM.
>> Pre-fetch and write posting engine associated with system DMA to get full performance from NAND
>> device with minimum impact on NOR/SRAM concurrent access.
> OK up to you guys to figure out if it may be usable in a generic way then :)
Ok I just got clarification from hw folks. DMA for GPMC can be used for any of the
various modes. But the prefetch is specific to NAND.
>
> Regards,
>
> Tony

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/14/2015 01:13 PM, Tony Lindgren wrote:
> * Franklin S Cooper Jr. <fcooper-l0cyMroinI0@public.gmane.org> [151014 09:27]:
>>
>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
>>> * Franklin S Cooper Jr. <fcooper-l0cyMroinI0@public.gmane.org> [151014 07:37]:
>>>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>>>> Franklin,
>>>>>>>
>>>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
>>>>>>>> Acked-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>>>> index d0f2620..957c32f 100644
>>>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>>>>>>  		dma_cap_zero(mask);
>>>>>>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>>>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>>>>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>>>>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>>>>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>>>>>>> +
>>>>>>> Just discovered that you are using the parent device node.
>>>>>>>
>>>>>>> How about moving the dma bindings to the nand node instead and using
>>>>>>> pdev->dev here?
>>>>>> Roger,
>>>>>>
>>>>>> From what I can tell the interrupt number and the dma channel will always be
>>>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>>>> combination of nands and nors. Since that is the case I think it just makes
>>>>>> sense to leave it in the gpmc parent node and define it once.
>>>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>>>> or only for NAND?
>>>> The dma seems tied to the prefetch. From what I can tell the prefetch is only
>>>> used by nand.
>>>>> Let's also get Tony's inputs on this.
>>>> Sure.
>>> Hmm so what would keep other devices from using the prefetch
>> Looking at the TRM any references to the prefetch are always with respect to
>> NAND.
>>
>> I also see the below mentioned in the TRM.
>> Pre-fetch and write posting engine associated with system DMA to get full performance from NAND
>> device with minimum impact on NOR/SRAM concurrent access.
> OK up to you guys to figure out if it may be usable in a generic way then :)
Ok I just got clarification from hw folks. DMA for GPMC can be used for any of the
various modes. But the prefetch is specific to NAND.
>
> Regards,
>
> Tony

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

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

On 14/10/15 23:03, Franklin S Cooper Jr. wrote:
> 
> 
> On 10/14/2015 01:13 PM, Tony Lindgren wrote:
>> * Franklin S Cooper Jr. <fcooper@ti.com> [151014 09:27]:
>>>
>>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
>>>> * Franklin S Cooper Jr. <fcooper@ti.com> [151014 07:37]:
>>>>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>>>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>>>>> Franklin,
>>>>>>>>
>>>>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>>>>>>>> Acked-by: Roger Quadros <rogerq@ti.com>
>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>>>>> index d0f2620..957c32f 100644
>>>>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>>>>>>>  		dma_cap_zero(mask);
>>>>>>>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>>>>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>>>>>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>>>>>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>>>>>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>>>>>>>> +
>>>>>>>> Just discovered that you are using the parent device node.
>>>>>>>>
>>>>>>>> How about moving the dma bindings to the nand node instead and using
>>>>>>>> pdev->dev here?
>>>>>>> Roger,
>>>>>>>
>>>>>>> From what I can tell the interrupt number and the dma channel will always be
>>>>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>>>>> combination of nands and nors. Since that is the case I think it just makes
>>>>>>> sense to leave it in the gpmc parent node and define it once.
>>>>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>>>>> or only for NAND?
>>>>> The dma seems tied to the prefetch. From what I can tell the prefetch is only
>>>>> used by nand.
>>>>>> Let's also get Tony's inputs on this.
>>>>> Sure.
>>>> Hmm so what would keep other devices from using the prefetch
>>> Looking at the TRM any references to the prefetch are always with respect to
>>> NAND.
>>>
>>> I also see the below mentioned in the TRM.
>>> Pre-fetch and write posting engine associated with system DMA to get full performance from NAND
>>> device with minimum impact on NOR/SRAM concurrent access.
>> OK up to you guys to figure out if it may be usable in a generic way then :)
> Ok I just got clarification from hw folks. DMA for GPMC can be used for any of the
> various modes. But the prefetch is specific to NAND.

In that case the dma information must be in the GPMC node.

cheers,
-roger

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

On 14/10/15 23:03, Franklin S Cooper Jr. wrote:
> 
> 
> On 10/14/2015 01:13 PM, Tony Lindgren wrote:
>> * Franklin S Cooper Jr. <fcooper@ti.com> [151014 09:27]:
>>>
>>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
>>>> * Franklin S Cooper Jr. <fcooper@ti.com> [151014 07:37]:
>>>>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>>>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>>>>> Franklin,
>>>>>>>>
>>>>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>>>>>>>> Acked-by: Roger Quadros <rogerq@ti.com>
>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>>>>> index d0f2620..957c32f 100644
>>>>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>>>>>>>  		dma_cap_zero(mask);
>>>>>>>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>>>>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>>>>>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>>>>>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>>>>>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>>>>>>>> +
>>>>>>>> Just discovered that you are using the parent device node.
>>>>>>>>
>>>>>>>> How about moving the dma bindings to the nand node instead and using
>>>>>>>> pdev->dev here?
>>>>>>> Roger,
>>>>>>>
>>>>>>> From what I can tell the interrupt number and the dma channel will always be
>>>>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>>>>> combination of nands and nors. Since that is the case I think it just makes
>>>>>>> sense to leave it in the gpmc parent node and define it once.
>>>>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>>>>> or only for NAND?
>>>>> The dma seems tied to the prefetch. From what I can tell the prefetch is only
>>>>> used by nand.
>>>>>> Let's also get Tony's inputs on this.
>>>>> Sure.
>>>> Hmm so what would keep other devices from using the prefetch
>>> Looking at the TRM any references to the prefetch are always with respect to
>>> NAND.
>>>
>>> I also see the below mentioned in the TRM.
>>> Pre-fetch and write posting engine associated with system DMA to get full performance from NAND
>>> device with minimum impact on NOR/SRAM concurrent access.
>> OK up to you guys to figure out if it may be usable in a generic way then :)
> Ok I just got clarification from hw folks. DMA for GPMC can be used for any of the
> various modes. But the prefetch is specific to NAND.

In that case the dma information must be in the GPMC node.

cheers,
-roger

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/15/2015 02:35 AM, Roger Quadros wrote:
> On 14/10/15 23:03, Franklin S Cooper Jr. wrote:
>>
>> On 10/14/2015 01:13 PM, Tony Lindgren wrote:
>>> * Franklin S Cooper Jr. <fcooper@ti.com> [151014 09:27]:
>>>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
>>>>> * Franklin S Cooper Jr. <fcooper@ti.com> [151014 07:37]:
>>>>>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>>>>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>>>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>>>>>> Franklin,
>>>>>>>>>
>>>>>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>>>>>>>>> Acked-by: Roger Quadros <rogerq@ti.com>
>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>>>>>> index d0f2620..957c32f 100644
>>>>>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>>>>>>>>  		dma_cap_zero(mask);
>>>>>>>>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>>>>>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>>>>>>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>>>>>>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>>>>>>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>>>>>>>>> +
>>>>>>>>> Just discovered that you are using the parent device node.
>>>>>>>>>
>>>>>>>>> How about moving the dma bindings to the nand node instead and using
>>>>>>>>> pdev->dev here?
>>>>>>>> Roger,
>>>>>>>>
>>>>>>>> From what I can tell the interrupt number and the dma channel will always be
>>>>>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>>>>>> combination of nands and nors. Since that is the case I think it just makes
>>>>>>>> sense to leave it in the gpmc parent node and define it once.
>>>>>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>>>>>> or only for NAND?
>>>>>> The dma seems tied to the prefetch. From what I can tell the prefetch is only
>>>>>> used by nand.
>>>>>>> Let's also get Tony's inputs on this.
>>>>>> Sure.
>>>>> Hmm so what would keep other devices from using the prefetch
>>>> Looking at the TRM any references to the prefetch are always with respect to
>>>> NAND.
>>>>
>>>> I also see the below mentioned in the TRM.
>>>> Pre-fetch and write posting engine associated with system DMA to get full performance from NAND
>>>> device with minimum impact on NOR/SRAM concurrent access.
>>> OK up to you guys to figure out if it may be usable in a generic way then :)
>> Ok I just got clarification from hw folks. DMA for GPMC can be used for any of the
>> various modes. But the prefetch is specific to NAND.
> In that case the dma information must be in the GPMC node.
Ok I'll be sending a v2 patchset soon but I'll be leaving this as is.
>
> cheers,
> -roger

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/15/2015 02:35 AM, Roger Quadros wrote:
> On 14/10/15 23:03, Franklin S Cooper Jr. wrote:
>>
>> On 10/14/2015 01:13 PM, Tony Lindgren wrote:
>>> * Franklin S Cooper Jr. <fcooper@ti.com> [151014 09:27]:
>>>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
>>>>> * Franklin S Cooper Jr. <fcooper@ti.com> [151014 07:37]:
>>>>>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>>>>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>>>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>>>>>> Franklin,
>>>>>>>>>
>>>>>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>>>>>>>>> Acked-by: Roger Quadros <rogerq@ti.com>
>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>>>>>> index d0f2620..957c32f 100644
>>>>>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>>>>>>>>>>  		dma_cap_zero(mask);
>>>>>>>>>>>  		dma_cap_set(DMA_SLAVE, mask);
>>>>>>>>>>>  		sig = OMAP24XX_DMA_GPMC;
>>>>>>>>>>> -		info->dma = dma_request_channel(mask, omap_dma_filter_fn, &sig);
>>>>>>>>>>> +		info->dma = dma_request_slave_channel_compat(mask,
>>>>>>>>>>> +			omap_dma_filter_fn, &sig, pdev->dev.parent, "rxtx");
>>>>>>>>>>> +
>>>>>>>>> Just discovered that you are using the parent device node.
>>>>>>>>>
>>>>>>>>> How about moving the dma bindings to the nand node instead and using
>>>>>>>>> pdev->dev here?
>>>>>>>> Roger,
>>>>>>>>
>>>>>>>> From what I can tell the interrupt number and the dma channel will always be
>>>>>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>>>>>> combination of nands and nors. Since that is the case I think it just makes
>>>>>>>> sense to leave it in the gpmc parent node and define it once.
>>>>>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>>>>>> or only for NAND?
>>>>>> The dma seems tied to the prefetch. From what I can tell the prefetch is only
>>>>>> used by nand.
>>>>>>> Let's also get Tony's inputs on this.
>>>>>> Sure.
>>>>> Hmm so what would keep other devices from using the prefetch
>>>> Looking at the TRM any references to the prefetch are always with respect to
>>>> NAND.
>>>>
>>>> I also see the below mentioned in the TRM.
>>>> Pre-fetch and write posting engine associated with system DMA to get full performance from NAND
>>>> device with minimum impact on NOR/SRAM concurrent access.
>>> OK up to you guys to figure out if it may be usable in a generic way then :)
>> Ok I just got clarification from hw folks. DMA for GPMC can be used for any of the
>> various modes. But the prefetch is specific to NAND.
> In that case the dma information must be in the GPMC node.
Ok I'll be sending a v2 patchset soon but I'll be leaving this as is.
>
> cheers,
> -roger

[PATCH 2/5] mtd: nand: omap2: Start dma request before enabling prefetch

[Franklin S Cooper Jr]

The prefetch engine sends a dma request once a FIFO threshold has
been met. No other requests are received until the previous request
is handled.

Starting an edma transfer (dma_async_issue_pending) results in any
previous event for the dma channel to be cleared. Therefore, starting
the prefetch engine before initiating the dma transfer may result in
the prefetch triggering a dma request but instead of it being handled
it can end up being cleared. This will result in a hang since the code
will continue to wait for the dma request to complete.

By initiating the dma request before enabling the prefetch engine this
race condition is avoided and no dma request are missed/cleared.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
---
 drivers/mtd/nand/omap2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 957c32f..94d11de 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -509,6 +509,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
 	tx->callback_param = &info->comp;
 	dmaengine_submit(tx);
 
+	init_completion(&info->comp);
+	dma_async_issue_pending(info->dma);
+
 	/*  configure and start prefetch transfer */
 	ret = omap_prefetch_enable(info->gpmc_cs,
 		PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write, info);
@@ -516,9 +519,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
 		/* PFPW engine is busy, use cpu copy method */
 		goto out_copy_unmap;
 
-	init_completion(&info->comp);
-	dma_async_issue_pending(info->dma);
-
 	/* setup and start DMA using dma_addr */
 	wait_for_completion(&info->comp);
 	tim = 0;
-- 
2.6.1

Re: [PATCH 2/5] mtd: nand: omap2: Start dma request before enabling prefetch

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> The prefetch engine sends a dma request once a FIFO threshold has
> been met. No other requests are received until the previous request
> is handled.
> 
> Starting an edma transfer (dma_async_issue_pending) results in any
> previous event for the dma channel to be cleared. Therefore, starting
> the prefetch engine before initiating the dma transfer may result in
> the prefetch triggering a dma request but instead of it being handled
> it can end up being cleared. This will result in a hang since the code
> will continue to wait for the dma request to complete.
> 
> By initiating the dma request before enabling the prefetch engine this
> race condition is avoided and no dma request are missed/cleared.
> 
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> ---
>  drivers/mtd/nand/omap2.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 957c32f..94d11de 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -509,6 +509,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
>  	tx->callback_param = &info->comp;
>  	dmaengine_submit(tx);
>  
> +	init_completion(&info->comp);
> +	dma_async_issue_pending(info->dma);
> +
>  	/*  configure and start prefetch transfer */
>  	ret = omap_prefetch_enable(info->gpmc_cs,
>  		PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write, info);
> @@ -516,9 +519,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
>  		/* PFPW engine is busy, use cpu copy method */
>  		goto out_copy_unmap;
>  
> -	init_completion(&info->comp);
> -	dma_async_issue_pending(info->dma);
> -
>  	/* setup and start DMA using dma_addr */

Is the above comment misplaced after this change?

>  	wait_for_completion(&info->comp);
>  	tim = 0;
> 

cheers,
-roger

Re: [PATCH 2/5] mtd: nand: omap2: Start dma request before enabling prefetch

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> The prefetch engine sends a dma request once a FIFO threshold has
> been met. No other requests are received until the previous request
> is handled.
> 
> Starting an edma transfer (dma_async_issue_pending) results in any
> previous event for the dma channel to be cleared. Therefore, starting
> the prefetch engine before initiating the dma transfer may result in
> the prefetch triggering a dma request but instead of it being handled
> it can end up being cleared. This will result in a hang since the code
> will continue to wait for the dma request to complete.
> 
> By initiating the dma request before enabling the prefetch engine this
> race condition is avoided and no dma request are missed/cleared.
> 
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> ---
>  drivers/mtd/nand/omap2.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 957c32f..94d11de 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -509,6 +509,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
>  	tx->callback_param = &info->comp;
>  	dmaengine_submit(tx);
>  
> +	init_completion(&info->comp);
> +	dma_async_issue_pending(info->dma);
> +
>  	/*  configure and start prefetch transfer */
>  	ret = omap_prefetch_enable(info->gpmc_cs,
>  		PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write, info);
> @@ -516,9 +519,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
>  		/* PFPW engine is busy, use cpu copy method */
>  		goto out_copy_unmap;
>  
> -	init_completion(&info->comp);
> -	dma_async_issue_pending(info->dma);
> -
>  	/* setup and start DMA using dma_addr */

Is the above comment misplaced after this change?

>  	wait_for_completion(&info->comp);
>  	tim = 0;
> 

cheers,
-roger

Re: [PATCH 2/5] mtd: nand: omap2: Start dma request before enabling prefetch

[Franklin S Cooper Jr.]

On 10/14/2015 06:41 AM, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> The prefetch engine sends a dma request once a FIFO threshold has
>> been met. No other requests are received until the previous request
>> is handled.
>>
>> Starting an edma transfer (dma_async_issue_pending) results in any
>> previous event for the dma channel to be cleared. Therefore, starting
>> the prefetch engine before initiating the dma transfer may result in
>> the prefetch triggering a dma request but instead of it being handled
>> it can end up being cleared. This will result in a hang since the code
>> will continue to wait for the dma request to complete.
>>
>> By initiating the dma request before enabling the prefetch engine this
>> race condition is avoided and no dma request are missed/cleared.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>> ---
>>  drivers/mtd/nand/omap2.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index 957c32f..94d11de 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -509,6 +509,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
>>  	tx->callback_param = &info->comp;
>>  	dmaengine_submit(tx);
>>  
>> +	init_completion(&info->comp);
>> +	dma_async_issue_pending(info->dma);
>> +
>>  	/*  configure and start prefetch transfer */
>>  	ret = omap_prefetch_enable(info->gpmc_cs,
>>  		PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write, info);
>> @@ -516,9 +519,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
>>  		/* PFPW engine is busy, use cpu copy method */
>>  		goto out_copy_unmap;
>>  
>> -	init_completion(&info->comp);
>> -	dma_async_issue_pending(info->dma);
>> -
>>  	/* setup and start DMA using dma_addr */
> Is the above comment misplaced after this change?
Yup you right.
>
>>  	wait_for_completion(&info->comp);
>>  	tim = 0;
>>
> cheers,
> -roger

Re: [PATCH 2/5] mtd: nand: omap2: Start dma request before enabling prefetch

[Franklin S Cooper Jr.]

On 10/14/2015 06:41 AM, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> The prefetch engine sends a dma request once a FIFO threshold has
>> been met. No other requests are received until the previous request
>> is handled.
>>
>> Starting an edma transfer (dma_async_issue_pending) results in any
>> previous event for the dma channel to be cleared. Therefore, starting
>> the prefetch engine before initiating the dma transfer may result in
>> the prefetch triggering a dma request but instead of it being handled
>> it can end up being cleared. This will result in a hang since the code
>> will continue to wait for the dma request to complete.
>>
>> By initiating the dma request before enabling the prefetch engine this
>> race condition is avoided and no dma request are missed/cleared.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
>> ---
>>  drivers/mtd/nand/omap2.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index 957c32f..94d11de 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -509,6 +509,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
>>  	tx->callback_param = &info->comp;
>>  	dmaengine_submit(tx);
>>  
>> +	init_completion(&info->comp);
>> +	dma_async_issue_pending(info->dma);
>> +
>>  	/*  configure and start prefetch transfer */
>>  	ret = omap_prefetch_enable(info->gpmc_cs,
>>  		PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write, info);
>> @@ -516,9 +519,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
>>  		/* PFPW engine is busy, use cpu copy method */
>>  		goto out_copy_unmap;
>>  
>> -	init_completion(&info->comp);
>> -	dma_async_issue_pending(info->dma);
>> -
>>  	/* setup and start DMA using dma_addr */
> Is the above comment misplaced after this change?
Yup you right.
>
>>  	wait_for_completion(&info->comp);
>>  	tim = 0;
>>
> cheers,
> -roger

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

[PATCH 3/5] mtd: nand: omap2: Fix high memory dma prefetch transfer

[Franklin S Cooper Jr]

Based on DMA documentation and testing using high memory buffer when
doing dma transfers can lead to various issues including kernel
panics.

To workaround this simply use cpu copy. The amount of high memory
buffers used are very uncommon so no noticeable performance hit should
be seen.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
---
 drivers/mtd/nand/omap2.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 94d11de..537be2f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -479,17 +479,8 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
 	int ret;
 	u32 val;
 
-	if (addr >= high_memory) {
-		struct page *p1;
-
-		if (((size_t)addr & PAGE_MASK) !=
-			((size_t)(addr + len - 1) & PAGE_MASK))
-			goto out_copy;
-		p1 = vmalloc_to_page(addr);
-		if (!p1)
-			goto out_copy;
-		addr = page_address(p1) + ((size_t)addr & ~PAGE_MASK);
-	}
+	if (addr >= high_memory)
+		goto out_copy;
 
 	sg_init_one(&sg, addr, len);
 	n = dma_map_sg(info->dma->device->dev, &sg, 1, dir);
@@ -545,6 +536,7 @@ out_copy:
 	else
 		is_write == 0 ? omap_read_buf8(mtd, (u_char *) addr, len)
 			: omap_write_buf8(mtd, (u_char *) addr, len);
+
 	return 0;
 }
 
-- 
2.6.1

[PATCH 4/5] ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel

[Franklin S Cooper Jr]

Add dma channel information to the gpmc. Although not enabled by
default this will allow prefetch-dma to be used.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
---
 arch/arm/boot/dts/am33xx.dtsi | 2 ++
 arch/arm/boot/dts/am4372.dtsi | 2 ++
 arch/arm/boot/dts/dm816x.dtsi | 2 ++
 arch/arm/boot/dts/omap3.dtsi  | 2 ++
 4 files changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e065f21..f2d8eed 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -819,6 +819,8 @@
 			ti,no-idle-on-init;
 			reg = <0x50000000 0x2000>;
 			interrupts = <100>;
+			dmas = <&edma 52>;
+			dma-names = "rxtx";
 			gpmc,num-cs = <7>;
 			gpmc,num-waitpins = <2>;
 			#address-cells = <2>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ec8b7a3..c02061b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -841,6 +841,8 @@
 		gpmc: gpmc@50000000 {
 			compatible = "ti,am3352-gpmc";
 			ti,hwmods = "gpmc";
+			dmas = <&edma 52>;
+			dma-names = "rxtx";
 			clocks = <&l3s_gclk>;
 			clock-names = "fck";
 			reg = <0x50000000 0x2000>;
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 68fb444..d2e5d31 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -180,6 +180,8 @@
 			#address-cells = <2>;
 			#size-cells = <1>;
 			interrupts = <100>;
+			dmas = <&edma 52>;
+			dma-names = "rxtx";
 			gpmc,num-cs = <6>;
 			gpmc,num-waitpins = <2>;
 			gpio-controller;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7f212b6..9dbbcf6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -717,6 +717,8 @@
 			ti,hwmods = "gpmc";
 			reg = <0x6e000000 0x02d0>;
 			interrupts = <20>;
+			dmas = <&sdma 4>;
+			dma-names = "rxtx";
 			gpmc,num-cs = <8>;
 			gpmc,num-waitpins = <4>;
 			#address-cells = <2>;
-- 
2.6.1

Re: [PATCH 4/5] ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> Add dma channel information to the gpmc. Although not enabled by
> default this will allow prefetch-dma to be used.
> 
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> ---
>  arch/arm/boot/dts/am33xx.dtsi | 2 ++
>  arch/arm/boot/dts/am4372.dtsi | 2 ++
>  arch/arm/boot/dts/dm816x.dtsi | 2 ++
>  arch/arm/boot/dts/omap3.dtsi  | 2 ++

How about fixing up omap4/5 and dra7 as well?

cheers,
-roger

>  4 files changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index e065f21..f2d8eed 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -819,6 +819,8 @@
>  			ti,no-idle-on-init;
>  			reg = <0x50000000 0x2000>;
>  			interrupts = <100>;
> +			dmas = <&edma 52>;
> +			dma-names = "rxtx";
>  			gpmc,num-cs = <7>;
>  			gpmc,num-waitpins = <2>;
>  			#address-cells = <2>;
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index ec8b7a3..c02061b 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -841,6 +841,8 @@
>  		gpmc: gpmc@50000000 {
>  			compatible = "ti,am3352-gpmc";
>  			ti,hwmods = "gpmc";
> +			dmas = <&edma 52>;
> +			dma-names = "rxtx";
>  			clocks = <&l3s_gclk>;
>  			clock-names = "fck";
>  			reg = <0x50000000 0x2000>;
> diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
> index 68fb444..d2e5d31 100644
> --- a/arch/arm/boot/dts/dm816x.dtsi
> +++ b/arch/arm/boot/dts/dm816x.dtsi
> @@ -180,6 +180,8 @@
>  			#address-cells = <2>;
>  			#size-cells = <1>;
>  			interrupts = <100>;
> +			dmas = <&edma 52>;
> +			dma-names = "rxtx";
>  			gpmc,num-cs = <6>;
>  			gpmc,num-waitpins = <2>;
>  			gpio-controller;
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 7f212b6..9dbbcf6 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -717,6 +717,8 @@
>  			ti,hwmods = "gpmc";
>  			reg = <0x6e000000 0x02d0>;
>  			interrupts = <20>;
> +			dmas = <&sdma 4>;
> +			dma-names = "rxtx";
>  			gpmc,num-cs = <8>;
>  			gpmc,num-waitpins = <4>;
>  			#address-cells = <2>;
> 

Re: [PATCH 4/5] ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> Add dma channel information to the gpmc. Although not enabled by
> default this will allow prefetch-dma to be used.
> 
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> ---
>  arch/arm/boot/dts/am33xx.dtsi | 2 ++
>  arch/arm/boot/dts/am4372.dtsi | 2 ++
>  arch/arm/boot/dts/dm816x.dtsi | 2 ++
>  arch/arm/boot/dts/omap3.dtsi  | 2 ++

How about fixing up omap4/5 and dra7 as well?

cheers,
-roger

>  4 files changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index e065f21..f2d8eed 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -819,6 +819,8 @@
>  			ti,no-idle-on-init;
>  			reg = <0x50000000 0x2000>;
>  			interrupts = <100>;
> +			dmas = <&edma 52>;
> +			dma-names = "rxtx";
>  			gpmc,num-cs = <7>;
>  			gpmc,num-waitpins = <2>;
>  			#address-cells = <2>;
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index ec8b7a3..c02061b 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -841,6 +841,8 @@
>  		gpmc: gpmc@50000000 {
>  			compatible = "ti,am3352-gpmc";
>  			ti,hwmods = "gpmc";
> +			dmas = <&edma 52>;
> +			dma-names = "rxtx";
>  			clocks = <&l3s_gclk>;
>  			clock-names = "fck";
>  			reg = <0x50000000 0x2000>;
> diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
> index 68fb444..d2e5d31 100644
> --- a/arch/arm/boot/dts/dm816x.dtsi
> +++ b/arch/arm/boot/dts/dm816x.dtsi
> @@ -180,6 +180,8 @@
>  			#address-cells = <2>;
>  			#size-cells = <1>;
>  			interrupts = <100>;
> +			dmas = <&edma 52>;
> +			dma-names = "rxtx";
>  			gpmc,num-cs = <6>;
>  			gpmc,num-waitpins = <2>;
>  			gpio-controller;
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 7f212b6..9dbbcf6 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -717,6 +717,8 @@
>  			ti,hwmods = "gpmc";
>  			reg = <0x6e000000 0x02d0>;
>  			interrupts = <20>;
> +			dmas = <&sdma 4>;
> +			dma-names = "rxtx";
>  			gpmc,num-cs = <8>;
>  			gpmc,num-waitpins = <4>;
>  			#address-cells = <2>;
> 

Re: [PATCH 4/5] ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel

[Franklin S Cooper Jr.]

On 10/14/2015 06:44 AM, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Add dma channel information to the gpmc. Although not enabled by
>> default this will allow prefetch-dma to be used.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>> ---
>>  arch/arm/boot/dts/am33xx.dtsi | 2 ++
>>  arch/arm/boot/dts/am4372.dtsi | 2 ++
>>  arch/arm/boot/dts/dm816x.dtsi | 2 ++
>>  arch/arm/boot/dts/omap3.dtsi  | 2 ++
> How about fixing up omap4/5 and dra7 as well?

Shouldn't be a problem for omap4 and omap5.

Dra7 with sdma can't support this feature. With edma it works fine. So I'll
wait until edma support for dra7 makes it into mainline and then I can send
a new patch adding support.
>
> cheers,
> -roger
>
>>  4 files changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index e065f21..f2d8eed 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -819,6 +819,8 @@
>>  			ti,no-idle-on-init;
>>  			reg = <0x50000000 0x2000>;
>>  			interrupts = <100>;
>> +			dmas = <&edma 52>;
>> +			dma-names = "rxtx";
>>  			gpmc,num-cs = <7>;
>>  			gpmc,num-waitpins = <2>;
>>  			#address-cells = <2>;
>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>> index ec8b7a3..c02061b 100644
>> --- a/arch/arm/boot/dts/am4372.dtsi
>> +++ b/arch/arm/boot/dts/am4372.dtsi
>> @@ -841,6 +841,8 @@
>>  		gpmc: gpmc@50000000 {
>>  			compatible = "ti,am3352-gpmc";
>>  			ti,hwmods = "gpmc";
>> +			dmas = <&edma 52>;
>> +			dma-names = "rxtx";
>>  			clocks = <&l3s_gclk>;
>>  			clock-names = "fck";
>>  			reg = <0x50000000 0x2000>;
>> diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
>> index 68fb444..d2e5d31 100644
>> --- a/arch/arm/boot/dts/dm816x.dtsi
>> +++ b/arch/arm/boot/dts/dm816x.dtsi
>> @@ -180,6 +180,8 @@
>>  			#address-cells = <2>;
>>  			#size-cells = <1>;
>>  			interrupts = <100>;
>> +			dmas = <&edma 52>;
>> +			dma-names = "rxtx";
>>  			gpmc,num-cs = <6>;
>>  			gpmc,num-waitpins = <2>;
>>  			gpio-controller;
>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>> index 7f212b6..9dbbcf6 100644
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -717,6 +717,8 @@
>>  			ti,hwmods = "gpmc";
>>  			reg = <0x6e000000 0x02d0>;
>>  			interrupts = <20>;
>> +			dmas = <&sdma 4>;
>> +			dma-names = "rxtx";
>>  			gpmc,num-cs = <8>;
>>  			gpmc,num-waitpins = <4>;
>>  			#address-cells = <2>;
>>

Re: [PATCH 4/5] ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel

[Franklin S Cooper Jr.]

On 10/14/2015 06:44 AM, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Add dma channel information to the gpmc. Although not enabled by
>> default this will allow prefetch-dma to be used.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>> ---
>>  arch/arm/boot/dts/am33xx.dtsi | 2 ++
>>  arch/arm/boot/dts/am4372.dtsi | 2 ++
>>  arch/arm/boot/dts/dm816x.dtsi | 2 ++
>>  arch/arm/boot/dts/omap3.dtsi  | 2 ++
> How about fixing up omap4/5 and dra7 as well?

Shouldn't be a problem for omap4 and omap5.

Dra7 with sdma can't support this feature. With edma it works fine. So I'll
wait until edma support for dra7 makes it into mainline and then I can send
a new patch adding support.
>
> cheers,
> -roger
>
>>  4 files changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index e065f21..f2d8eed 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -819,6 +819,8 @@
>>  			ti,no-idle-on-init;
>>  			reg = <0x50000000 0x2000>;
>>  			interrupts = <100>;
>> +			dmas = <&edma 52>;
>> +			dma-names = "rxtx";
>>  			gpmc,num-cs = <7>;
>>  			gpmc,num-waitpins = <2>;
>>  			#address-cells = <2>;
>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>> index ec8b7a3..c02061b 100644
>> --- a/arch/arm/boot/dts/am4372.dtsi
>> +++ b/arch/arm/boot/dts/am4372.dtsi
>> @@ -841,6 +841,8 @@
>>  		gpmc: gpmc@50000000 {
>>  			compatible = "ti,am3352-gpmc";
>>  			ti,hwmods = "gpmc";
>> +			dmas = <&edma 52>;
>> +			dma-names = "rxtx";
>>  			clocks = <&l3s_gclk>;
>>  			clock-names = "fck";
>>  			reg = <0x50000000 0x2000>;
>> diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
>> index 68fb444..d2e5d31 100644
>> --- a/arch/arm/boot/dts/dm816x.dtsi
>> +++ b/arch/arm/boot/dts/dm816x.dtsi
>> @@ -180,6 +180,8 @@
>>  			#address-cells = <2>;
>>  			#size-cells = <1>;
>>  			interrupts = <100>;
>> +			dmas = <&edma 52>;
>> +			dma-names = "rxtx";
>>  			gpmc,num-cs = <6>;
>>  			gpmc,num-waitpins = <2>;
>>  			gpio-controller;
>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>> index 7f212b6..9dbbcf6 100644
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -717,6 +717,8 @@
>>  			ti,hwmods = "gpmc";
>>  			reg = <0x6e000000 0x02d0>;
>>  			interrupts = <20>;
>> +			dmas = <&sdma 4>;
>> +			dma-names = "rxtx";
>>  			gpmc,num-cs = <8>;
>>  			gpmc,num-waitpins = <4>;
>>  			#address-cells = <2>;
>>

[PATCH 5/5] ARM: OMAP2+: Update gpmc and nand DT binding documentation

[Franklin S Cooper Jr]

Add additional details to the gpmc and nand documentation to clarify
what is needed to enable nand dma prefetch.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
---
 Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 ++++++-
 Documentation/devicetree/bindings/mtd/gpmc-nand.txt                | 2 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
index 704be93..b1e2802 100644
--- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
@@ -33,6 +33,10 @@ Required properties:
 			As this will change in the future, filling correct
 			values here is a requirement.
 
+GPMC DMA information. Required only when GPMC nand prefetch is enabled.
+ - dmas			GPMC nand prefetch dma channel
+ - dma-names		DMA channel name use as a reference within the Nand driver
+
 Timing properties for child nodes. All are optional and default to 0.
 
  - gpmc,sync-clk-ps:	Minimum clock period for synchronous mode, in picoseconds
@@ -119,7 +123,8 @@ Example for an AM33xx board:
 		ti,hwmods = "gpmc";
 		reg = <0x50000000 0x2000>;
 		interrupts = <100>;
-
+		dmas = <&edma 52>;
+		dma-names = "rxtx";
 		gpmc,num-cs = <8>;
 		gpmc,num-waitpins = <2>;
 		#address-cells = <2>;
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index 253e6de..4b0c240 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -61,6 +61,8 @@ Example for an AM33xx board:
 		ti,hwmods = "gpmc";
 		reg = <0x50000000 0x36c>;
 		interrupts = <100>;
+		dmas = <&edma 52>;
+		dma-names = "rxtx";
 		gpmc,num-cs = <8>;
 		gpmc,num-waitpins = <2>;
 		#address-cells = <2>;
-- 
2.6.1

Re: [PATCH 5/5] ARM: OMAP2+: Update gpmc and nand DT binding documentation

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> Add additional details to the gpmc and nand documentation to clarify
> what is needed to enable nand dma prefetch.
> 
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> ---
>  Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 ++++++-
>  Documentation/devicetree/bindings/mtd/gpmc-nand.txt                | 2 ++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
> index 704be93..b1e2802 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
> +++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
> @@ -33,6 +33,10 @@ Required properties:
>  			As this will change in the future, filling correct
>  			values here is a requirement.
>  
> +GPMC DMA information. Required only when GPMC nand prefetch is enabled.
> + - dmas			GPMC nand prefetch dma channel

s/nand/NAND

> + - dma-names		DMA channel name use as a reference within the Nand driver

s/Nand/NAND

This is inevitably going to be "rxtx". So why not say that it should be "rxtx"

Should these bindings go in bindings/mtd/gpmc-nand.txt instead?

> +
>  Timing properties for child nodes. All are optional and default to 0.
>  
>   - gpmc,sync-clk-ps:	Minimum clock period for synchronous mode, in picoseconds
> @@ -119,7 +123,8 @@ Example for an AM33xx board:
>  		ti,hwmods = "gpmc";
>  		reg = <0x50000000 0x2000>;
>  		interrupts = <100>;
> -
> +		dmas = <&edma 52>;
> +		dma-names = "rxtx";

Why not define these in the NAND node instead of gpmc node?

>  		gpmc,num-cs = <8>;
>  		gpmc,num-waitpins = <2>;
>  		#address-cells = <2>;
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> index 253e6de..4b0c240 100644
> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@ -61,6 +61,8 @@ Example for an AM33xx board:
>  		ti,hwmods = "gpmc";
>  		reg = <0x50000000 0x36c>;
>  		interrupts = <100>;
> +		dmas = <&edma 52>;
> +		dma-names = "rxtx";
>  		gpmc,num-cs = <8>;
>  		gpmc,num-waitpins = <2>;
>  		#address-cells = <2>;
> 

cheers,
-roger

Re: [PATCH 5/5] ARM: OMAP2+: Update gpmc and nand DT binding documentation

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> Add additional details to the gpmc and nand documentation to clarify
> what is needed to enable nand dma prefetch.
> 
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> ---
>  Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 ++++++-
>  Documentation/devicetree/bindings/mtd/gpmc-nand.txt                | 2 ++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
> index 704be93..b1e2802 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
> +++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
> @@ -33,6 +33,10 @@ Required properties:
>  			As this will change in the future, filling correct
>  			values here is a requirement.
>  
> +GPMC DMA information. Required only when GPMC nand prefetch is enabled.
> + - dmas			GPMC nand prefetch dma channel

s/nand/NAND

> + - dma-names		DMA channel name use as a reference within the Nand driver

s/Nand/NAND

This is inevitably going to be "rxtx". So why not say that it should be "rxtx"

Should these bindings go in bindings/mtd/gpmc-nand.txt instead?

> +
>  Timing properties for child nodes. All are optional and default to 0.
>  
>   - gpmc,sync-clk-ps:	Minimum clock period for synchronous mode, in picoseconds
> @@ -119,7 +123,8 @@ Example for an AM33xx board:
>  		ti,hwmods = "gpmc";
>  		reg = <0x50000000 0x2000>;
>  		interrupts = <100>;
> -
> +		dmas = <&edma 52>;
> +		dma-names = "rxtx";

Why not define these in the NAND node instead of gpmc node?

>  		gpmc,num-cs = <8>;
>  		gpmc,num-waitpins = <2>;
>  		#address-cells = <2>;
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> index 253e6de..4b0c240 100644
> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@ -61,6 +61,8 @@ Example for an AM33xx board:
>  		ti,hwmods = "gpmc";
>  		reg = <0x50000000 0x36c>;
>  		interrupts = <100>;
> +		dmas = <&edma 52>;
> +		dma-names = "rxtx";
>  		gpmc,num-cs = <8>;
>  		gpmc,num-waitpins = <2>;
>  		#address-cells = <2>;
> 

cheers,
-roger

Re: [PATCH 5/5] ARM: OMAP2+: Update gpmc and nand DT binding documentation

[Franklin S Cooper Jr.]

On 10/14/2015 06:50 AM, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Add additional details to the gpmc and nand documentation to clarify
>> what is needed to enable nand dma prefetch.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>> ---
>>  Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 ++++++-
>>  Documentation/devicetree/bindings/mtd/gpmc-nand.txt                | 2 ++
>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> index 704be93..b1e2802 100644
>> --- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> +++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> @@ -33,6 +33,10 @@ Required properties:
>>  			As this will change in the future, filling correct
>>  			values here is a requirement.
>>  
>> +GPMC DMA information. Required only when GPMC nand prefetch is enabled.
>> + - dmas			GPMC nand prefetch dma channel
> s/nand/NAND
>
>> + - dma-names		DMA channel name use as a reference within the Nand driver
> s/Nand/NAND
>
> This is inevitably going to be "rxtx". So why not say that it should be "rxtx"
I'll fix all three of these
>
> Should these bindings go in bindings/mtd/gpmc-nand.txt instead?
>
>> +
>>  Timing properties for child nodes. All are optional and default to 0.
>>  
>>   - gpmc,sync-clk-ps:	Minimum clock period for synchronous mode, in picoseconds
>> @@ -119,7 +123,8 @@ Example for an AM33xx board:
>>  		ti,hwmods = "gpmc";
>>  		reg = <0x50000000 0x2000>;
>>  		interrupts = <100>;
>> -
>> +		dmas = <&edma 52>;
>> +		dma-names = "rxtx";
> Why not define these in the NAND node instead of gpmc node?
Since we decided that the dma entry will stay in the GPMC node I'll leave these as is.
>
>>  		gpmc,num-cs = <8>;
>>  		gpmc,num-waitpins = <2>;
>>  		#address-cells = <2>;
>> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> index 253e6de..4b0c240 100644
>> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> @@ -61,6 +61,8 @@ Example for an AM33xx board:
>>  		ti,hwmods = "gpmc";
>>  		reg = <0x50000000 0x36c>;
>>  		interrupts = <100>;
>> +		dmas = <&edma 52>;
>> +		dma-names = "rxtx";
>>  		gpmc,num-cs = <8>;
>>  		gpmc,num-waitpins = <2>;
>>  		#address-cells = <2>;
>>
> cheers,
> -roger

Re: [PATCH 5/5] ARM: OMAP2+: Update gpmc and nand DT binding documentation

[Franklin S Cooper Jr.]

On 10/14/2015 06:50 AM, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Add additional details to the gpmc and nand documentation to clarify
>> what is needed to enable nand dma prefetch.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>> ---
>>  Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 ++++++-
>>  Documentation/devicetree/bindings/mtd/gpmc-nand.txt                | 2 ++
>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> index 704be93..b1e2802 100644
>> --- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> +++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> @@ -33,6 +33,10 @@ Required properties:
>>  			As this will change in the future, filling correct
>>  			values here is a requirement.
>>  
>> +GPMC DMA information. Required only when GPMC nand prefetch is enabled.
>> + - dmas			GPMC nand prefetch dma channel
> s/nand/NAND
>
>> + - dma-names		DMA channel name use as a reference within the Nand driver
> s/Nand/NAND
>
> This is inevitably going to be "rxtx". So why not say that it should be "rxtx"
I'll fix all three of these
>
> Should these bindings go in bindings/mtd/gpmc-nand.txt instead?
>
>> +
>>  Timing properties for child nodes. All are optional and default to 0.
>>  
>>   - gpmc,sync-clk-ps:	Minimum clock period for synchronous mode, in picoseconds
>> @@ -119,7 +123,8 @@ Example for an AM33xx board:
>>  		ti,hwmods = "gpmc";
>>  		reg = <0x50000000 0x2000>;
>>  		interrupts = <100>;
>> -
>> +		dmas = <&edma 52>;
>> +		dma-names = "rxtx";
> Why not define these in the NAND node instead of gpmc node?
Since we decided that the dma entry will stay in the GPMC node I'll leave these as is.
>
>>  		gpmc,num-cs = <8>;
>>  		gpmc,num-waitpins = <2>;
>>  		#address-cells = <2>;
>> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> index 253e6de..4b0c240 100644
>> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> @@ -61,6 +61,8 @@ Example for an AM33xx board:
>>  		ti,hwmods = "gpmc";
>>  		reg = <0x50000000 0x36c>;
>>  		interrupts = <100>;
>> +		dmas = <&edma 52>;
>> +		dma-names = "rxtx";
>>  		gpmc,num-cs = <8>;
>>  		gpmc,num-waitpins = <2>;
>>  		#address-cells = <2>;
>>
> cheers,
> -roger