François Legal <[email protected]> writes:
> Le Vendredi, Août 27, 2021 15:54 CEST, Philippe Gerum <[email protected]> a > écrit: > >> >> François Legal <[email protected]> writes: >> >> > Le Vendredi, Août 27, 2021 15:01 CEST, Philippe Gerum <[email protected]> a >> > écrit: >> > >> >> >> >> François Legal via Xenomai <[email protected]> writes: >> >> >> >> > Hello, >> >> > >> >> > working on a zynq7000 target (arm cortex a9), we have a peripheral that >> >> > generates loads of data (many kbytes per ms). >> >> > >> >> > We would like to move that data, directly from the peripheral memory >> >> > (the OCM of the SoC) directly to our RT application user memory using >> >> > DMA. >> >> > >> >> > For one part of the data, we would like the DMA to de interlace that >> >> > data while moving it. We figured out, the PL330 peripheral on the SoC >> >> > should be able to do it, however, we would like, as much as possible, >> >> > to retain the use of one or two channels of the PL330 to plain linux >> >> > non RT use (via dmaengine). >> >> > >> >> > My first attempt would be to enhance the dmaengine API to add RT API, >> >> > then implement the RT API calls in the PL330 driver. >> >> > >> >> > What do you think of this approach, and is it achievable at all (DMA >> >> > directly to user land memory and/or having DMA channels exploited by >> >> > xenomai and other by linux) ? >> >> > >> >> > Thanks in advance >> >> > >> >> > François >> >> >> >> As a starting point, you may want to have a look at this document: >> >> https://evlproject.org/core/oob-drivers/dma/ >> >> >> >> This is part of the EVL core documentation, but this is actually a >> >> Dovetail feature. >> >> >> > >> > Well, that's quite what I want to do, so this is very good news that it is >> > already available in the future. However, I need it through the ipipe >> > right now, but I guess the process stays the same (through patching the >> > dmaengine API and the DMA engine driver). >> > >> > I would guess the modifications to the DMA engine driver would be then >> > easily ported to dovetail ? >> > >> >> Since they should follow the same pattern used for the controllers >> Dovetail currently supports, I think so. You should be able to simplify >> the code when porting it Dovetail actually. >> > > That's what I thought. Thanks a lot. > > So now, regarding the "to userland memory" aspect. I guess I will somehow > have to, in order to make this happen, change the PTE flags to make these > pages non cacheable (using dma_map_page maybe), but I wonder if I have to map > the userland pages to kernel space and whether or not I have to pin the > userland pages in memory (I believe mlockall in the userland process does > that already) ? > The out-of-band SPI support available from EVL illustrates a possible implementation. This code [2] implements what is described in this page [1]. [1] https://evlproject.org/core/oob-drivers/spi/ [2] https://source.denx.de/Xenomai/xenomai4/linux-evl/-/blob/0969ccef9a5318244e484e847dab52999f6fec5c/drivers/spi/spi.c#L4259 -- Philippe.
