Video Framebuffer Write IP cores are designed for video applications requiring frame buffers and is designed for high-bandwidth access between the AXI4-Stream video interface and the AXI4-interface.


The driver is currently located in a special branch of the standard Xilinx Linux kernel: https://github.com/Xilinx/linux-xlnx/tree/2017.3_video_ea

Supported IP Features

The following is a list of IP constraints for which there is support in the driver and for which verification
within the context of the listed reference designs has been performed (see below):
  1. Streaming Video Format Support: RGB, YUV 4:2:2, YUV 4:4:4, YUV 4:2:0
  2. Memory Video Format Support: RGB8, BGRX8, RGBX8, YUYV8, YUVX8, RGBX10, YUVX10, Y_UV8, Y_UV8_420, UYVY8, YUV8, Y_UV10, Y_UV10_420, Y8, Y10
  3. Programmable memory video format
  4. Support for 8-bit or 10-bit per color component on stream or memory interface
  5. Resolutions up to 3840x2160

Unsupported IP Features

The following list of IP constraints either has no driver support or has not yet been verified to work in any existing technical reference design:
  1. Streaming Video Format Support: YUV 4:2:0
  2. Resolutions up to 8192x4320

Known Issues

When DMA operations are initiated by a client, the hardware is placed into "autorestart" mode. When the last buffer has been returned to the client as "completed", if the client does not supply a new write buffer location or fails to halt the driver, then the last buffer location written to will continue to be utilized by the driver. In effect, the driver will "spin" on the last location programmed.

Kernel Configuration

The dirver must be enabled in the kernel by selecting option CONFIG_XILINX_FRMBUF

Device Tree Configuration

Complete documentation on the device tree requirements may be found in the Linux source located at <linux_root>/Documentation/devicetree/bindings/dma/xilinx/xilinx_frmbuf.txt

Below is a device tree example for a Framebuffer Write instance configured with 32-bit wide DMA descriptors and support for RGB8 as well as RGBX8 memory formats:
 v_frmbuf_wr_0: v_frmbuf_wr@80000000 {
        #dma-cells = <1>;
        compatible = "xlnx,axi-frmbuf-wr-v2";
        interrupt-parent = <&gic>;
        interrupts = <0 92 4>;
        reset-gpios = <&gpio 80 1>;
        reg = <0x0 0x80000000 0x0 0x10000>;
        xlnx,dma-addr-width = <32>;
        xlnx,vid-formats = "bgr888","xbgr8888";

Interfacing with the Video Framebuffer Driver from DMA Clients

The Linux driver for Framebuffer Write implements the Linux DMA Engine interface semantics for a single channel DMA controller. Because the IP is video format aware, it has capabilities that are not fully served by the dma engine interface. As such, the Video Framebuffer driver exports an API interface that must be used by DMA clients in addition to the Linux DMA Engine interface for proper programming. (see <linux_root>/include/linux/dma/xilinx_frmbuf.h).

The general steps for preparing DMA to write to a specific memory buffer:
  1. Using the Video Framebuffer API, configure the DMA device with the expected memory format for write
  2. Prepare an interleaved template describing the buffer location (note: see section DMA Interleaved Template Requirements below for more details)
  3. Pass the interleaved template to the DMA device using the Linux DMA Engine interface
  4. With the DMA descriptor which is returned from step 3, add a callback and then submit to the DMA device via the DMA Engine interface
  5. Start the DMA write operation
  6. Terminate DMA write operation when frame processing deemed complete by client
/* Abstract V4L2 Client Code Example */
struct dma_chan *frmbuf_dma = to_frmbuf_dma_chan(xdev);
struct dma_interleaved_template dma_tmplt;
dma_addr_t addr = vb2_dma_contig_plane_dma_addr(vb2_buffer_ptr, 0);
/* Step 1 – Configure the dma channel to write out packed RGB */
xilinx_xdma_v4l2_config(frmbuf_dma, V4L2_PIX_FMT_RGB24);
/* Step 2 – Describe the buffer attributes for a 1080p frame */
dma_tmplt.dir = DMA_DEV_TO_MEM;
dma_tmplt.src_sgl = false;
dma_tmplt.dst_sgl = true;
dma_tmplt.dst_start = addr;
dma_tmplt.frame_size = 1; /* single plane pixel format */
dma_tmplt.numf = 1080; /* 1920x1080 frame */
dma_tmplt.sgl[0].size = 5760; /* 3 bytes/pixel x 1920 pixels */
dma_tmplt.sgl[0].icg = 0;
/* Step 3 – Submit the buffer description to the dma channel */
desc = dmaengine_prep_interleaved_dma(frmbuf_dma, &dma_tmplt, flags);
desc->callback = dma_complete;
desc->callback_param = buf;
/* Step 4 – Submit the returned and updated descriptor to the dma channel */
/* Step 5 – Start dma to memory operation */
/* Step 6 – Halt DMA when required frame processing completed */

DMA Interleaved Template Requirements

The Video Framebuffer IP supports two dma address pointers for semi-planar formats: one for luma and one for chroma. As such, data for the two planes need not be strictly contiguous which permits for alignment of plane data within a larger buffer. However, all frame data (luma and chroma) must be contained within a singler, larger contiguous frame buffer and luma plane data should be arranged to come before chroma data within this frame buffer space. Note that this is not a limitation imposed by the IP but by the driver at this moment. When preparing a struct dma_interleaved_template instance to describe a semi-planar format, the following members must be filled out as follows:

From linux/dmaengine.h:

struct dma_interleaved_template:

dst_start = <physical address from which to start reading frame data (any offsets should be added to this value)>
src_sgl = false
dst_sgl = true
numf = <height of frame in pixels; height of luma frame for semi-planar formats>
frame_size = < 1 or 2 depending on whether this is describing a packed or semi-planar format>
sgl = <see struct data_chunk below>

struct data_chunk:

sgl[0].size = <number of bytes devoted to image data for a row>
sgl[0].icg = < number of non-data bytes within a row of image data; padding>
sgl[0].dst_sgl = <the offset in bytes between the end of luma frame data to the start of chroma plane data; only needed for semi-planar formats>

Below is a code example for semi-planar YUV 422 (i.e. NV16) demonstrating how steps 1 and 2 of the above code snippet change in such a case:
/* Step 1 – Configure the dma channel to write out semi-planar YUV 422 */
xilinx_xdma_v4l2_config(frmbuf_dma, V4L2_PIX_FMT_NV16M);
/* Step 2 – Describe the buffer attributes for a 1080p frame */
dma_tmplt.dir = DMA_DEV_TO_MEM;
dma_tmplt.src_sgl = false;
dma_tmplt.dst_sgl = true;
dma_tmplt.dst_start = luma_addr;
dma_tmplt.frame_size = 2; /* two plane pixel format */
dma_tmplt.numf = 1080; /* height of luma frame */
dma_tmplt.sgl[0].size = 1920; /* 1 byte/pixel x 1920 pixels for Y plane */
dma_tmplt.sgl[0].icg = 0;
frame_height = dma_tmplt.numf;
stride = dma_tmplt.sgl[0].size + dma_tmplt.sgl[0].icg;
dma_tmplt.sql[0].dst_icg = chroma_addr – luma_addr – (frame_height * stride);

Driver Operation

The Framebuffer driver manages buffer descriptors in software keeping them in one of four possible states in the following order:
  1. pending
  2. staged
  3. active
  4. done

When a DMA client calls dma_commit(), the buffer descriptor is placed in the driver’s “pending” queue. Multiple buffers can be queued in this manner by the DMA client before proceeding to the next step (see step 4 of Interfacing with the Video Framebuffer Driver from DMA Clients).

When dma_async_issue_pending() is called (step 5 in the client code sample above), the driver begins processing all queued buffers on the “pending” list. A buffer is plucked from the pending list and then stored as “staged”. At this moment, driver programs the registers with data provided within the “staged” buffer descriptor. During normal processing (i.e. all frames except the first frame*), these values will not become active until the currently processed frame completes. As such, there is a one-frame delay between programming and the actual writing data to memory. Hence the term “staged” to describe this part of the buffer lifecycle.

When the currently active frame completed, the buffer descriptor is classified as “active” in the driver. At this point, a new descriptor is plucked from the pending list and this new buffer is marked as “staged” with its values programmed into the IP registers as described earlier. The buffer marked “active” represents the data currently being written to memory. Other than being held in the “active” state, no other action is taken with the buffer

When the active frame completes, it is moved to the “done” list. The driver utilizes a tasklet which is called at the end of the frame interrupt handler. The tasklet will process any buffer descriptors on the done list by removing them from the list and calling any callback the client has linked to the descriptor.

This completes the lifecycle of a buffer descriptor. As can be seen, with four possible states, it is best to allocate at least four buffers to maintain consistent frame processing. Fewer buffers will result in gaps within the pipeline and result in frame data within a given buffer being overwritten one or more times (depending on how few buffers are queued and the number of resulting gaps in the driver’s buffer pipeline).

  • Note: normally, registers programmed while the IP is running will not take effect until the next frame. The very first frame, however, is an exception: the IP is not yet running and, as such, the values take effect immediately. Nevertheless, there is no additional special treatment given the first frame buffer. As such, it will be written to, in effect, twice.

Test Approach

To ensure the Framebuffer Write IP Linux driver has been configured to work properly, a suitable test design will require an input source (i.e. HDMI Rx) connected to the Framebuffer.

Once properly configured, the design can be tested via the tool known as "yavta". Yavta may be found here.

To run yavta, data must be streaming into your media pipeline. To verify the status of your media pipleline, run the tool known as "media-ctl":
root@hdmi_proj:~# media-ctl -p
Media controller API version 0.1.0
Media device information
driver          xilinx-video
model           Xilinx Video Composite Device
bus info
hw revision     0x0
driver version  0.0.0
Device topology
- entity 1: vcap_hdmi output 0 (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
        pad0: Sink
                <- "a0000000.v_hdmi_rx_ss":0 [ENABLED]
- entity 5: a0000000.v_hdmi_rx_ss (1 pad, 1 link)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
        pad0: Source
                [fmt:UYVY/1920x1080 field:none]
                [dv.caps:BT.656/1120 min:0x0@25000000 max:4096x2160@297000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
                [dv.detect:BT.656/1120 1920x1080p60 (2200x1125) stds:CEA-861 flags:CE-video]
                -> "vcap_hdmi output 0":0 [ENABLED]
In the above example, entity 5 represents the HDMI Rx input source which happens to be receiving YUYV-based media at 1080p resolution. The Video Framebuffer driver is managed/controlled by a V4L2 "client" driver represented by entity 1. The above pipeline is suitable for capturing and writing to memory any of the supported YUV 8-bit formats (e.g. YUYV, NV16 or NV16M).

A frame capture to local binary files can now be performed using the yavta tool:
root@hdmi_proj:~# yavta -c10 -f YUYV -s 1920x1080 --skip 7 -F /dev/video0 &
[2] 2362
Device /dev/video0 opened.
Device `vcap_hdmi output 0' on `platform:vcap_hdmi:0' is a video output (without mplanes) device.
Video format set: YUYV (56595559) 1920x1080 field n[ 1393.139514]
one, 1 planes:
 * Stride 3840, buffer size 4147200
[ 1393.747654] xhdmi_s_stream enable = 0
Captured 10 frames in 0.289203 seconds (34.577689 fps, 0.000000 B/s).
8 buffers released.
[2]-  Done                    yavta -c10 -f YUYV -s 1920x1080 --skip 7 -F /dev/video0
root@hdmi_proj:~# ls
frame-000007.bin  frame-000008.bin  frame-000009.bin
The above command syntax specifies 10 frames to capture (-c10) writing to memory in packed YUYV format (-f YUYV) with 1920x1080 dimensions (-s 1920x1080) and to only write out the last 3 frames captured to a file (--skip 7). These instructions are sent to the file descriptor which represents the V4L2 driver controlling, ulimately, the Video Framebuffer (-F /dev/video0).

Lastly, we list the contents of the directory within which we execute the yavta command and we see three files named frame-* . These files can be opened in a viewer utility like yuvplayer.exe an inspected to ensure that frame capture occurred properly.