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
