Mason <slash.tmp@xxxxxxx> writes: > On 17/11/2016 12:42, Måns Rullgård wrote: > >> Mason writes: >> >>> On 15/11/2016 12:02, Mason wrote: >>> >>>> I would like to be able to setup my board's DMA engine at the time when >>>> dma_request_chan() is called by the driver using that specific channel. >>>> (Or some time later, but before an actual transfer is requested.) >>>> >>>> Does dma_request_chan() call back into the DMA driver at some point? >>>> If yes, through which function pointer? >>>> >>>> I see that of_dma_request_slave_channel() calls ofdma->of_dma_xlate() >>>> which is the function registered through of_dma_controller_register() >>>> in the DMA driver, right? >>>> >>>> Currently, the driver sets up the DMA engine at the time when the >>>> device_issue_pending() method is called, but this creates a catch-22 >>>> situation where A must be before B, and B must be before A. >>>> >>>> Looking at struct dma_device ... >>>> http://lxr.free-electrons.com/source/include/linux/dmaengine.h#L637 >>>> Could I use the device_config() call-back for this? >>>> >>>> https://www.kernel.org/doc/Documentation/dmaengine/client.txt >>> >>> Let me try describing the problem on a higher level. >>> >>> I'm currently using this DMA driver on my board: >>> https://github.com/mansr/linux-tangox/blob/master/drivers/dma/tangox-dma.c >> >> You're aware it doesn't work on tango4 and later, right? It's probably >> enough to update the register bitfield locations, but I'm not sure. > > You're right. The geniuses in HW design changed the semantics of the > bits between tango3 and tango4. I have a local patch fixing that up. My understanding is that some of the bits have been moved around but the meanings are unchanged. If that is correct, it should be easy enough to support both. >>> The driver configures the DMA HW in device_issue_pending() in two steps >>> A) switch box (sbox) setup >>> B) memory bus (mbus) channel setup >> >> Since there are more client devices than DMA channels, the driver >> multiplexes them like this. > > This does not work for NAND accesses. The HW engineer I talked to > said it should, so I will test again. > >>> And the DMA engine client (a NAND Flash controller driver) starts a >>> transfer by programming the NFC registers. >>> >>> The problem is that the steps need to be done in this order: >>> 1) SBOX >>> 2) NAND >>> 3) MBUS >>> >>> But in the current design, there is no way to have the NAND step >>> *between* SBOX and MBUS steps. I don't see why the sbox needs to be configured first. It's just a crossbar switch, and until something starts actually issuing requests, it shouldn't matter how it is connected. >>> For now, I have hard-coded the SBOX setup in the driver's probe function, >>> but that's just a hack. IMO, it makes sense to configure the SBOX >>> only once, when the client driver "registers" with the DMA driver >>> (dma_request_chan if I understand correctly) and release the HW >>> channel when the client driver "unbinds". >> >> Then you can only use as many devices as you have channels. > > On Tango4, the possible clients are: > > SBOX_IN0 = MBUS R0 > SBOX_IN1 = MBUS R1 > SBOX_IN2 = MLC FLASH 0 > SBOX_IN3 = MLC FLASH 1 > SBOX_IN4 = HOST CIPHER 0 > SBOX_IN5 = PBUS 0 > SBOX_IN6 = PBUS 1 > SBOX_IN7 = HOST CIPHER 1 > SBOX_IN8 = MBUS R2 > SBOX_IN9 = HOST CIHPER 2 > > The "CIPHER" clients are not used (I was told they are broken). > I'm not sure what the PBUS clients are for (maybe IDE disks). > I'm using one channel for NAND. > The remaining clients are for mem-to-mem DMA copies, I think, > and there is no driver for that, at this time. There are two SATA devices as well, which already puts the number of clients over the number of mbus channels. I also recall seeing quite a few more devices listed, the sbox supporting as many as 14. > I think it makes sense for the DMA driver to offer exclusive > access to a given memory channel. Do you disagree? What would that be good for? If you wanted that, you'd need to design the chip with one real dma channel per device, not like this. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
