Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎08-09-2018

Drivers for a V4L2 source using AXI DMA IP (PG021)

This post is a request for comment / advice / suggestions regarding the use
of AXI DMA (PG021) in a video pipeline where it is highly desirable to
use the Linux V4L2 API to get data from the device to userspace via the
UserPtr method. The goal is to replicate the video pipline architectures
of the ZCU 106 VCU TRD without using framebuffer (PG278) IP.
This post seeks comments regarding the software drivers that would
be required to realize such a design.


a. For the initial design, only video input devices are needed.
b. Also, the driver only needs to support monochrome video.
c. The FW team has already placed AXI DMA (PG021) in their design.

I am seeking answers / opinions to the following questions. The
basis for my questions is in the text that follows.

1) Has this been done before?

2) Does this design seem reasonable or are there other alternatives that
would require a lot less effort and take a lot less risk? Obviously using
a framebuffer would be the ideal solution, but that is not possible for the current FW.

3) Does anyone have any estimates / guesses as to how long it  
would take to accomplish this?

4) What would be the best way of achieving this goal? There are at
least three approaches. Any comments about which one (listed below)
would require the least effort and be the lowest risk.



The ZCU106 VCU TRD contains video pipelines that are managed in software
via V4L2 sources. They consist of several driver modules that work together
as a composite V4L2 device.

For example, Design Module 4 contains a test pattern generator.

function      : name        : driver code

video source  : TPG         : ./media/platform/xilinx/xilinx-tpg.c
dma engine    : framebuffer : ./dma/xilinx/xilinx_frmbuf.c - PG278
composite dev : vipp        : ./media/platform/xilinx/xilinx-vipp.c
video dev     : /dev/videoX : ./media/platform/xilinx/xilinx-dma.c

What I would like to do is reuse this architecture, but with two changes,
a) replace the dma engine with the AXI DMA IP / driver and
b) our custom TPG

function      : name        : driver code

video source  : TPG         : custom driver
dma engine    : AXI DMA     : ./dma/xilinx/xilinx_dma.c - PG021
composite dev : vipp        : ./media/platform/xilinx/xilinx-vipp.c
video dev     : /dev/videoX : ./media/platform/xilinx/xilinx-dma.c

This post is about the change in the dma engine.



It appears that the video device driver xilinix-dma.c assumes / was
only designed to work with xilinx_frmbuf.c.
The latter exports symbols that are called from the former.
Furthermore, the dma engines have different dma channel structure and device structures.
xilinx_dma.c : xilinx_dma_chan & xilinx_dma_device

   -- VS --

xilinx_frmbuf.c : xilinx_frmbuf_chan & xilinx_frmbuf_device.



Based on the constraints already in place by the FW design, what
software changes could be made to realize a V4L2 device with the
UserPtr IO method on top of an AXI DMA engine.

There are at least three ways of achieving this goal. Does anyone have
comments about these approaches or have any alternatives to offer?

1) Custom - Create custom driver(s) that implements only the
features of V4L2 api that are desired but not use any (or very little) of the
V4L2 / VB2 code already in the kernel. This seems like a huge effort,  
not very portable, and not the best solution.

2) API rework - Make a new driver, starting with a copy of xilinx_dma.c,
but modifiying the dma channel and device structures to make it work
with the video device, xilinx-dma.c.

3) HW rework - Make a new driver, starting with a copy of xilinx_frmbuf.c,
but modifying the low level HW accesses to work with the AXI DMA IP
instead of the frmbuf IP.

4) Other(s) not listed here ...

Tags (3)
0 Kudos
2 Replies
Registered: ‎11-09-2015

Hi @lyleg,

The AXI DMA IP is not build for Video data support. You might want to consider using the AXI VDMA instead, which would be a bit better.

However, I believe the V4L2 framework is only supported for the video frame buffer so for both the AXI DMA or VDMA you would need to make all the required changes in the driver to be able to support V4L2.


Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
Registered: ‎08-09-2018

Thanks. The reason for my post was to collect comments / opinion about taking the FW I am being given and making it work with the V4L2 API. I have explained to the FW team that the framebuffer will give our system better performance, but for them its about all about schedule. They know AXI DMA and are solely driven by getting to their "done", with no regard for performance.I have talked with management about this and for the moment, they do not support me.

0 Kudos