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. -- Philippe.
