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
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
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
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
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
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
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
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
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
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
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
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. I'm sorry you lost me again. What do you mean handshake? There is no request line? There is no way the NAND controller can trigger DMA transfers? What do you mean mem-to-mem, how is this useful to the controller? > Your point is since the driver is using external DMA and it should be > described in bindings? Yes. But maybe I still don't get it correctly. Thanks, Miquèl
Hi Miquel, > -----Original Message----- > From: Miquel Raynal <miquel.raynal@bootlin.com> > Sent: Friday, 7 February, 2025 1:02 AM > 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 > >> >> > /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. > > I'm sorry you lost me again. What do you mean handshake? There is no > request line? There is no way the NAND controller can trigger DMA transfers? > Yes, I mean there is no request line, so there is no way the NAND controller can trigger DMA transfer. Sorry I used the terminology based on Synopsys DesignWare AXI DMA Controller that is used with Agilex5 SoCFPGA platform. https://github.com/torvalds/linux/blob/v6.14-rc1/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c#L1372 > What do you mean mem-to-mem, how is this useful to the controller? > I mean system memory to/from NAND MMIO register address for page read/write data transfer. reg = <0x10b80000 0x10000>, <0x10840000 0x1000>; <--- This MMIO address block reg-names = "reg", "sdma"; > > Your point is since the driver is using external DMA and it should be > > described in bindings? > > Yes. But maybe I still don't get it correctly. > dmas is an optional property in cadence nand controller bindings. https://github.com/torvalds/linux/blob/v6.14-rc1/Documentation/devicetree/bindings/mtd/cdns%2Chp-nfc.yaml#L36 Does it need to change to required property in bindings? Please let me know if you have any suggestion/advise. Thanks, Nirav
>> >> >> > 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. >> >> I'm sorry you lost me again. What do you mean handshake? There is no >> request line? There is no way the NAND controller can trigger DMA transfers? >> > Yes, I mean there is no request line, so there is no way the NAND controller can > trigger DMA transfer. > > Sorry I used the terminology based on Synopsys DesignWare AXI DMA Controller > that is used with Agilex5 SoCFPGA platform. > https://github.com/torvalds/linux/blob/v6.14-rc1/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c#L1372 > >> What do you mean mem-to-mem, how is this useful to the controller? >> > I mean system memory to/from NAND MMIO register address for page > read/write data transfer. > > reg = <0x10b80000 0x10000>, > <0x10840000 0x1000>; <--- This MMIO address block > reg-names = "reg", "sdma"; > >> > Your point is since the driver is using external DMA and it should be >> > described in bindings? >> >> Yes. But maybe I still don't get it correctly. >> > dmas is an optional property in cadence nand controller bindings. > https://github.com/torvalds/linux/blob/v6.14-rc1/Documentation/devicetree/bindings/mtd/cdns%2Chp-nfc.yaml#L36 > Does it need to change to required property in bindings? On one side you have a dedicated MMIO region, which imply we should have an external DMA engine that is probably generic. On the other side it feels like only the NAND controller uses it and it should be pictured as a peripheral DMA controller and in this case we should not use the DMA engine API at all. Your case is something in between, I don't like it much. Anyway, we cannot break bindings, so please respin the series because I totally lost your initial target. Miquèl
© 2016 - 2026 Red Hat, Inc.