On 07/11/2017 06:09 PM, Nitin Kulkarni wrote: > Hi Philippe, > Thanks for the answer. Can you refer me to any DMA driver that you integrated > with ipipe ?
SDMA often found on the i.MX6 series can be adapted this way. The code supporting TI's EDMA too, although this is more tricky. > I found out that the DMA driver running is that idam64 and as you mentioned > it hooks to the generic DMA engine frame work > with the handlers implemented in idma64.c . > > I still have one question though, Do we adda real-time irq handler or keep > the existing non-realtime interrupt (through request_irq) for the DMA ? We > need the callback to be in real-time, so how is that possible without adding > a realtime irq ? > This is not possible doing sane things, hence the trickiness of dealing with that issue. > I think a reference will help me understand how to port the dma driver. > I'm not the copyright holder of that particular customer code, only the author. Besides, each DMA backend requires a specific implementation for that purpose, I don't think you could generalize the SDMA/EDMA hooks I mentioned in order to use them with another backend. To summarize the idea, the "only" issue is the requirement for sharing the DMA chip with regular Linux operations. This option I mentioned involves: 1- allocating Rx/Tx DMA channels for your rt SPI transfers the usual way, e.g. calling dma_request_slave_channel(). That operation would be done from a non-rt context, so you would get them once at init. 2- providing a rt capable dmaengine handler for kicking the DMA transfer on a channel; rt capable meaning which may be called from primary mode safely. You should see this as a basic, stateless "pulse" mode operation, i.e. when called, the handler routine triggers the DMA transfer immediately on the proper channel. That code needs to go to the idma64 backend driver. Since setting up the DMA for the next pulse has to be a very basic operation, you would have to work with a fixed DMA buffer of coherent memory attached to the channel, that should never change. Or maybe you could just run your channel strictly in continuous cyclic mode, programming your DMA channels to reset themselves after each transfer for the next run, in that case start and stop would be the only operations required. Instead of waiting for a completion IRQ, working asynchronously, maybe you could inspect the DMA channel status (on the chip) directly at some point in time later, to make sure the last transfer has completed right before starting the next one. Assuming your Linux-based SoC is the SPI master and the SPI bus is dedicated to rt traffic, a single software controller is likely to pace the overall transfer anyway. If you really have to work with an async notification of transfer completions, then you could look for a way to have the SPI controller issue the interrupt after a burst is received/sent, not the DMA chip. Maybe playing with the Rx/Tx FIFO thresholds if your SPI controller supports this. If you manage to do that, then grabbing the IRQ source of a SPI controller dedicated to rt processing is fine, you would not have to share this with the regular kernel. Again, it all depends on your requirements, provided you can work with fixed size transfers over a dedicated SPI bus, etc. YMMV. Ok, this is pretty much all I have on that topic. In any case, the key to success is to guarantee that such DMA "fast path" remains transparent with respect to the regular Linux operations using the same DMA engine. -- Philippe. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
