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