[v2] mtd: rawnand: cadence: improvement and fixes

[PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

Posted by niravkumar.l.rabara@intel.com 2 weeks, 6 days ago

From: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>

Use deferred driver probe in case the DMA driver is not probed.
When ARM SMMU is enabled, all peripheral device drivers, including NAND,
are probed earlier than the DMA driver.

Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem")
Cc: stable@vger.kernel.org
Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
---
 drivers/mtd/nand/raw/cadence-nand-controller.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/cadence-nand-controller.c b/drivers/mtd/nand/raw/cadence-nand-controller.c
index 8d1d710e439d..5e27f5546f1b 100644
--- a/drivers/mtd/nand/raw/cadence-nand-controller.c
+++ b/drivers/mtd/nand/raw/cadence-nand-controller.c
@@ -2908,7 +2908,7 @@ static int cadence_nand_init(struct cdns_nand_ctrl *cdns_ctrl)
 		if (!cdns_ctrl->dmac) {
 			dev_err(cdns_ctrl->dev,
 				"Unable to get a DMA channel\n");
-			ret = -EBUSY;
+			ret = -EPROBE_DEFER;
 			goto disable_irq;
 		}
 	}
-- 
2.25.1

Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

Posted by Miquel Raynal 2 weeks, 1 day ago

Hello,

On 16/01/2025 at 11:21:52 +08, niravkumar.l.rabara@intel.com wrote:

Typo (prob) in the title.

> From: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
>
> Use deferred driver probe in case the DMA driver is not probed.

Only devices are probed, not drivers.

> When ARM SMMU is enabled, all peripheral device drivers, including NAND,
> are probed earlier than the DMA driver.
>
> Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem")
> Cc: stable@vger.kernel.org
> Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
> ---
>  drivers/mtd/nand/raw/cadence-nand-controller.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/cadence-nand-controller.c b/drivers/mtd/nand/raw/cadence-nand-controller.c
> index 8d1d710e439d..5e27f5546f1b 100644
> --- a/drivers/mtd/nand/raw/cadence-nand-controller.c
> +++ b/drivers/mtd/nand/raw/cadence-nand-controller.c
> @@ -2908,7 +2908,7 @@ static int cadence_nand_init(struct cdns_nand_ctrl *cdns_ctrl)
>  		if (!cdns_ctrl->dmac) {
>  			dev_err(cdns_ctrl->dev,
>  				"Unable to get a DMA channel\n");
> -			ret = -EBUSY;
> +			ret = -EPROBE_DEFER;

Does it work if there is no DMA channel provided? The bindings do not
mention DMA channels as mandatory.

Also, wouldn't it be more pleasant to use another helper from the DMA
core that returns a proper return code? So we now which one among
-EBUSY, -ENODEV or -EPROBE_DEFER we get?

Thanks,
Miquèl

RE: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

Posted by Rabara, Niravkumar L 1 week ago

Hi Miquèl,


> -----Original Message-----
> From: Miquel Raynal <miquel.raynal@bootlin.com>
> Sent: Tuesday, 21 January, 2025 5:52 PM
> To: Rabara, Niravkumar L <niravkumar.l.rabara@intel.com>
> Cc: Richard Weinberger <richard@nod.at>; Vignesh Raghavendra
> <vigneshr@ti.com>; linux@treblig.org; Shen Lichuan <shenlichuan@vivo.com>;
> Jinjie Ruan <ruanjinjie@huawei.com>; u.kleine-koenig@baylibre.com; linux-
> mtd@lists.infradead.org; linux-kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when
> DMA is not ready
> 
> 
> Typo (prob) in the title.
> 
> > From: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
> >
> > Use deferred driver probe in case the DMA driver is not probed.
> 
> Only devices are probed, not drivers.

I will fix the title and commit message in v3.
> 
> > --- a/drivers/mtd/nand/raw/cadence-nand-controller.c
> > +++ b/drivers/mtd/nand/raw/cadence-nand-controller.c
> > @@ -2908,7 +2908,7 @@ static int cadence_nand_init(struct cdns_nand_ctrl
> *cdns_ctrl)
> >  		if (!cdns_ctrl->dmac) {
> >  			dev_err(cdns_ctrl->dev,
> >  				"Unable to get a DMA channel\n");
> > -			ret = -EBUSY;
> > +			ret = -EPROBE_DEFER;
> 
> Does it work if there is no DMA channel provided? The bindings do not mention
> DMA channels as mandatory.
> 

The way Cadence NAND controller driver is written in such a way that it uses 
has_dma=1 as hardcoded value, indicating that slave DMA interface is connected
to DMA engine. However, it does not utilize the dedicated DMA channel information
from the device tree.

Driver works without external DMA interface i.e. has_dma=0. 
However current driver does not have a mechanism to configure it from device tree. 

> Also, wouldn't it be more pleasant to use another helper from the DMA core
> that returns a proper return code? So we now which one among -EBUSY, -
> ENODEV or -EPROBE_DEFER we get?
> 

Agree.
I will change to "dma_request_chan_by_mask" instead of "dma_request_channel "
so it can return a proper error code. 
  
		cdns_ctrl->dmac = dma_request_chan_by_mask(&mask);
		if (IS_ERR(cdns_ctrl->dmac)) {
			ret = PTR_ERR(cdns_ctrl->dmac);
			if (ret != -EPROBE_DEFER)
				dev_err(cdns_ctrl->dev,
					"Failed to get a DMA channel:%d\n",ret);
			goto disable_irq;
		}

Is this reasonable? 

Thanks,
Nirav

Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

Posted by Miquel Raynal 1 week ago

Hello,

>> > --- a/drivers/mtd/nand/raw/cadence-nand-controller.c
>> > +++ b/drivers/mtd/nand/raw/cadence-nand-controller.c
>> > @@ -2908,7 +2908,7 @@ static int cadence_nand_init(struct cdns_nand_ctrl
>> *cdns_ctrl)
>> >  		if (!cdns_ctrl->dmac) {
>> >  			dev_err(cdns_ctrl->dev,
>> >  				"Unable to get a DMA channel\n");
>> > -			ret = -EBUSY;
>> > +			ret = -EPROBE_DEFER;
>> 
>> Does it work if there is no DMA channel provided? The bindings do not mention
>> DMA channels as mandatory.
>> 
>
> The way Cadence NAND controller driver is written in such a way that it uses 
> has_dma=1 as hardcoded value, indicating that slave DMA interface is connected
> to DMA engine. However, it does not utilize the dedicated DMA channel information
> from the device tree.

This is not ok.

> Driver works without external DMA interface i.e. has_dma=0. 
> However current driver does not have a mechanism to configure it from
> device tree.

What? Why are you requesting a DMA channel from a dmaengine in this case?

Please make the distinction between the OS implementation (the driver)
and the DT binding which describe the HW and only the HW.

>> Also, wouldn't it be more pleasant to use another helper from the DMA core
>> that returns a proper return code? So we now which one among -EBUSY, -
>> ENODEV or -EPROBE_DEFER we get?
>> 
>
> Agree.
> I will change to "dma_request_chan_by_mask" instead of "dma_request_channel "
> so it can return a proper error code. 
>   
> 		cdns_ctrl->dmac = dma_request_chan_by_mask(&mask);
> 		if (IS_ERR(cdns_ctrl->dmac)) {
> 			ret = PTR_ERR(cdns_ctrl->dmac);
> 			if (ret != -EPROBE_DEFER)
> 				dev_err(cdns_ctrl->dev,
> 					"Failed to get a DMA channel:%d\n",ret);
> 			goto disable_irq;
> 		}
>
> Is this reasonable?

It is better, but maybe you can use dev_err_probe() instead to include
the EPROBE_DEFER error handling.

Thanks,
Miquèl

RE: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

Posted by Rabara, Niravkumar L 6 days, 10 hours ago

Hi Miquel,

> >> Does it work if there is no DMA channel provided? The bindings do not
> >> mention DMA channels as mandatory.
> >>
> >
> > The way Cadence NAND controller driver is written in such a way that
> > it uses
> > has_dma=1 as hardcoded value, indicating that slave DMA interface is
> > connected to DMA engine. However, it does not utilize the dedicated
> > DMA channel information from the device tree.
> 
> This is not ok.
> 
> > Driver works without external DMA interface i.e. has_dma=0.
> > However current driver does not have a mechanism to configure it from
> > device tree.
> 
> What? Why are you requesting a DMA channel from a dmaengine in this case?
> 
> Please make the distinction between the OS implementation (the driver) and
> the DT binding which describe the HW and only the HW.
> 

Let me clarify from bindings(hw) and driver prospective. 

Bindings :-
Cadence NAND controller HW has MMIO registers, so called slave DMA interface
for page programming or page read. 
        reg = <0x10b80000 0x10000>,
              <0x10840000 0x10000>;
        reg-names = "reg", "sdma"; // sdma =  Slave DMA data port register set

It appears that dt bindings has captured sdma interface correctly.   

Linux Driver:-
Driver can read these sdma registers directly or it can use the DMA.
Existing driver code has hardcoded has_dma with an assumption that
an external DMA is always used and relies on DMA API for data transfer. 
Thant is why it requires to use DMA channel from dmaengine. 

In my previous reply, I tried to describe this driver scenario but maybe I mixed up. 
has_dma=0, i.e. accessing sdma register without using dmaengine is also working.
However, currently there is no option in driver to choose between using dmaengine and
direct register access.



> > 		cdns_ctrl->dmac = dma_request_chan_by_mask(&mask);
> > 		if (IS_ERR(cdns_ctrl->dmac)) {
> > 			ret = PTR_ERR(cdns_ctrl->dmac);
> > 			if (ret != -EPROBE_DEFER)
> > 				dev_err(cdns_ctrl->dev,
> > 					"Failed to get a DMA
> channel:%d\n",ret);
> > 			goto disable_irq;
> > 		}
> >
> > Is this reasonable?
> 
> It is better, but maybe you can use dev_err_probe() instead to include the
> EPROBE_DEFER error handling.
> 

Got it. I will update the code as below. 

		cdns_ctrl->dmac = dma_request_chan_by_mask(&mask);
		if (IS_ERR(cdns_ctrl->dmac)) {
			ret = dev_err_probe(cdns_ctrl->dev, PTR_ERR(cdns_ctrl->dmac),
				    "%d: Failed to get a DMA channel\n",ret);		
			goto disable_irq;
		}

Thanks,
Nirav

Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

Posted by Miquel Raynal 5 days, 22 hours ago

Hello,

>> > Driver works without external DMA interface i.e. has_dma=0.
>> > However current driver does not have a mechanism to configure it from
>> > device tree.
>> 
>> What? Why are you requesting a DMA channel from a dmaengine in this case?
>> 
>> Please make the distinction between the OS implementation (the driver) and
>> the DT binding which describe the HW and only the HW.
>> 
>
> Let me clarify from bindings(hw) and driver prospective. 
>
> Bindings :-
> Cadence NAND controller HW has MMIO registers, so called slave DMA interface
> for page programming or page read. 
>         reg = <0x10b80000 0x10000>,
>               <0x10840000 0x10000>;
>         reg-names = "reg", "sdma"; // sdma =  Slave DMA data port register set
>
> It appears that dt bindings has captured sdma interface correctly.

Slave DMA is very confusing because in Linux we make the distinction
between:
1- external DMA (generic DMA controller) driven
   through the dmaengine API, through which we interact using the so
   called slave API
2- peripheral DMA (DMA controller embedded in the NAND IP) when there is
   no "external/generic" engine. In this case we control DMA transfers
   using the registers of the NAND controller (or a nearby range, in
   this case), the same driver handles both the NAND and the DMA part.

You used the wording Slave DMA (#1), but it feels like you are talking
about the other (#2). Can you please confirm in which case we are?

> Linux Driver:-
> Driver can read these sdma registers directly or it can use the DMA.
> Existing driver code has hardcoded has_dma with an assumption that
> an external DMA is always used and relies on DMA API for data
> transfer.

I am sorry but DMA API does not mean much. There are 3 APIs:
- dma-mapping, for the buffers and the coherency
- dmaengine, used in case #1 only, to drive the external DMA controllers
- dma-buf to share buffers between areas in the kernel (out of scope)

> Thant is why it requires to use DMA channel from dmaengine.

If I understand it right, no :-)

Either you have an external DMA controller (#2) or an internal one (#1)
but in this second case there is no DMA channel request nor any
engine-related API. Of course you need to use the dma-mapping API for
the buffers.

> In my previous reply, I tried to describe this driver scenario but maybe I mixed up. 
> has_dma=0, i.e. accessing sdma register without using dmaengine is
> also working.

But do you have an external DMA engine in the end? Or is it specific to
the NAND controller?

> However, currently there is no option in driver to choose between using dmaengine and
> direct register access.
>

Thanks,
Miquèl

RE: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

Posted by Rabara, Niravkumar L 1 day, 6 hours ago

Hi Miquel,

> -----Original Message-----
> From: Miquel Raynal <miquel.raynal@bootlin.com>
> Sent: Thursday, 30 January, 2025 11:20 PM
> To: Rabara, Niravkumar L <niravkumar.l.rabara@intel.com>
> Cc: Richard Weinberger <richard@nod.at>; Vignesh Raghavendra
> <vigneshr@ti.com>; linux@treblig.org; Shen Lichuan
> <shenlichuan@vivo.com>; Jinjie Ruan <ruanjinjie@huawei.com>; u.kleine-
> koenig@baylibre.com; linux-mtd@lists.infradead.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob
> when DMA is not ready
> 
> Hello,
> 
> >> > Driver works without external DMA interface i.e. has_dma=0.
> >> > However current driver does not have a mechanism to configure it
> >> > from device tree.
> >>
> >> What? Why are you requesting a DMA channel from a dmaengine in this
> case?
> >>
> >> Please make the distinction between the OS implementation (the
> >> driver) and the DT binding which describe the HW and only the HW.
> >>
> >
> > Let me clarify from bindings(hw) and driver prospective.
> >
> > Bindings :-
> > Cadence NAND controller HW has MMIO registers, so called slave DMA
> > interface for page programming or page read.
> >         reg = <0x10b80000 0x10000>,
> >               <0x10840000 0x10000>;
> >         reg-names = "reg", "sdma"; // sdma =  Slave DMA data port
> > register set
> >
> > It appears that dt bindings has captured sdma interface correctly.
> 
> Slave DMA is very confusing because in Linux we make the distinction
> between:
> 1- external DMA (generic DMA controller) driven
>    through the dmaengine API, through which we interact using the so
>    called slave API
> 2- peripheral DMA (DMA controller embedded in the NAND IP) when there is
>    no "external/generic" engine. In this case we control DMA transfers
>    using the registers of the NAND controller (or a nearby range, in
>    this case), the same driver handles both the NAND and the DMA part.
> 
> You used the wording Slave DMA (#1), but it feels like you are talking about
> the other (#2). Can you please confirm in which case we are?
>

My apologies for the confusion.
Slave DMA terminology used in cadence nand controller bindings and
driver is indeed confusing.  

To answer your question it is, 
1 - External DMA (Generic DMA controller).

Nand controller IP do not have embedded DMA controller (2 - peripheral DMA). 

FYR, how external DMA is used. 
https://elixir.bootlin.com/linux/v6.13.1/source/drivers/mtd/nand/raw/cadence-nand-controller.c#L1962

 
> > Linux Driver:-
> > Driver can read these sdma registers directly or it can use the DMA.
> > Existing driver code has hardcoded has_dma with an assumption that an
> > external DMA is always used and relies on DMA API for data transfer.
> 
> I am sorry but DMA API does not mean much. There are 3 APIs:
> - dma-mapping, for the buffers and the coherency
> - dmaengine, used in case #1 only, to drive the external DMA controllers
> - dma-buf to share buffers between areas in the kernel (out of scope)
> 
> > Thant is why it requires to use DMA channel from dmaengine.
> 
> If I understand it right, no :-)
> 
> Either you have an external DMA controller (#2) or an internal one (#1) but in
> this second case there is no DMA channel request nor any engine-related
> API. Of course you need to use the dma-mapping API for the buffers.
> 
> > In my previous reply, I tried to describe this driver scenario but maybe I
> mixed up.
> > has_dma=0, i.e. accessing sdma register without using dmaengine is
> > also working.
> 
> But do you have an external DMA engine in the end? Or is it specific to the
> NAND controller?
> 

Yes I am using external DMA engine. 

Thanks,
Nirav

Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

Posted by Miquel Raynal 1 day, 4 hours ago

Hello,

> My apologies for the confusion.
> Slave DMA terminology used in cadence nand controller bindings and
> driver is indeed confusing.  
>
> To answer your question it is, 
> 1 - External DMA (Generic DMA controller).
>
> Nand controller IP do not have embedded DMA controller (2 - peripheral DMA). 
>
> FYR, how external DMA is used. 
> https://elixir.bootlin.com/linux/v6.13.1/source/drivers/mtd/nand/raw/cadence-nand-controller.c#L1962

In this case we should have a dmas property (and perhaps dma-names), no?

Miquèl

RE: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

Posted by Rabara, Niravkumar L 1 day, 3 hours ago

Hi Miquel,

> -----Original Message-----
> From: Miquel Raynal <miquel.raynal@bootlin.com>
> Sent: Tuesday, 4 February, 2025 5:20 PM
> To: Rabara, Niravkumar L <niravkumar.l.rabara@intel.com>
> Cc: Richard Weinberger <richard@nod.at>; Vignesh Raghavendra
> <vigneshr@ti.com>; linux@treblig.org; Shen Lichuan <shenlichuan@vivo.com>;
> Jinjie Ruan <ruanjinjie@huawei.com>; u.kleine-koenig@baylibre.com; linux-
> mtd@lists.infradead.org; linux-kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when
> DMA is not ready
> 
> Hello,
> 
> > My apologies for the confusion.
> > Slave DMA terminology used in cadence nand controller bindings and
> > driver is indeed confusing.
> >
> > To answer your question it is,
> > 1 - External DMA (Generic DMA controller).
> >
> > Nand controller IP do not have embedded DMA controller (2 - peripheral
> DMA).
> >
> > FYR, how external DMA is used.
> > https://elixir.bootlin.com/linux/v6.13.1/source/drivers/mtd/nand/raw/c
> > adence-nand-controller.c#L1962
> 
> In this case we should have a dmas property (and perhaps dma-names), no?
> 
No, I believe.
Cadence NAND controller IP do not have dedicated handshake interface to connect
with DMA controller.
My understanding is dmas (and dma-names) are only used for the dedicated handshake
interface between peripheral and the DMA controller.

Thanks,
Nirav

Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

Posted by Miquel Raynal 1 day ago

On 04/02/2025 at 10:43:20 GMT, "Rabara, Niravkumar L" <niravkumar.l.rabara@intel.com> wrote:

> Hi Miquel,
>
>> -----Original Message-----
>> From: Miquel Raynal <miquel.raynal@bootlin.com>
>> Sent: Tuesday, 4 February, 2025 5:20 PM
>> To: Rabara, Niravkumar L <niravkumar.l.rabara@intel.com>
>> Cc: Richard Weinberger <richard@nod.at>; Vignesh Raghavendra
>> <vigneshr@ti.com>; linux@treblig.org; Shen Lichuan <shenlichuan@vivo.com>;
>> Jinjie Ruan <ruanjinjie@huawei.com>; u.kleine-koenig@baylibre.com; linux-
>> mtd@lists.infradead.org; linux-kernel@vger.kernel.org; stable@vger.kernel.org
>> Subject: Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when
>> DMA is not ready
>> 
>> Hello,
>> 
>> > My apologies for the confusion.
>> > Slave DMA terminology used in cadence nand controller bindings and
>> > driver is indeed confusing.
>> >
>> > To answer your question it is,
>> > 1 - External DMA (Generic DMA controller).
>> >
>> > Nand controller IP do not have embedded DMA controller (2 - peripheral
>> DMA).
>> >
>> > FYR, how external DMA is used.
>> > https://elixir.bootlin.com/linux/v6.13.1/source/drivers/mtd/nand/raw/c
>> > adence-nand-controller.c#L1962
>> 
>> In this case we should have a dmas property (and perhaps dma-names), no?
>> 
> No, I believe.
> Cadence NAND controller IP do not have dedicated handshake interface to connect
> with DMA controller.
> My understanding is dmas (and dma-names) are only used for the dedicated handshake
> interface between peripheral and the DMA controller.

I don't see well how you can defer if there is no resource to grab. And
if there is a resource to grab, why is it not described anywhere?

Thanks,
Miquèl

RE: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when DMA is not ready

Posted by Rabara, Niravkumar L 23 hours ago

Hi Miquel,

> -----Original Message-----
> From: Miquel Raynal <miquel.raynal@bootlin.com>
> Sent: Tuesday, 4 February, 2025 9:33 PM
> To: Rabara, Niravkumar L <niravkumar.l.rabara@intel.com>
> Cc: Richard Weinberger <richard@nod.at>; Vignesh Raghavendra
> <vigneshr@ti.com>; linux@treblig.org; Shen Lichuan <shenlichuan@vivo.com>;
> Jinjie Ruan <ruanjinjie@huawei.com>; u.kleine-koenig@baylibre.com; linux-
> mtd@lists.infradead.org; linux-kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH v2 1/3] mtd: rawnand: cadence: support deferred prob when
> DMA is not ready
> 
> On 04/02/2025 at 10:43:20 GMT, "Rabara, Niravkumar L"
> <niravkumar.l.rabara@intel.com> wrote:
> >> Hello,
> >>
> >> > My apologies for the confusion.
> >> > Slave DMA terminology used in cadence nand controller bindings and
> >> > driver is indeed confusing.
> >> >
> >> > To answer your question it is,
> >> > 1 - External DMA (Generic DMA controller).
> >> >
> >> > Nand controller IP do not have embedded DMA controller (2 -
> >> > peripheral
> >> DMA).
> >> >
> >> > FYR, how external DMA is used.
> >> > https://elixir.bootlin.com/linux/v6.13.1/source/drivers/mtd/nand/ra
> >> > w/c
> >> > adence-nand-controller.c#L1962
> >>
> >> In this case we should have a dmas property (and perhaps dma-names), no?
> >>
> > No, I believe.
> > Cadence NAND controller IP do not have dedicated handshake interface
> > to connect with DMA controller.
> > My understanding is dmas (and dma-names) are only used for the
> > dedicated handshake interface between peripheral and the DMA controller.
> 
> I don't see well how you can defer if there is no resource to grab. And if there is
> a resource to grab, why is it not described anywhere?
> 

Since NAND controller do not have handshake interface with DMA controller.
Driver is using external DMA for memory-to-memory copy. 

Your point is since the driver is using external DMA and it should be described in bindings? 

Thanks,
Nirav