Page Comparison

Versions Compared

Key

This line was added.
This line was removed.
Formatting was changed.

Comment: Updated for 2019.2

...

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.

IP/Driver Features

IP features	2018.1	2018.2	2018.3	2019.1	2019.2
IP version	2.0	2.0	2.1	2.1
Streaming Video Formats supported	RGB, RGBA, YUV 4:4:4, YUVA 4:4:4, YUV 4:2:2, YUV 4:2:0
Color Formats supported	Video Formats with per Pixel Alpha (valid only for Framebuffer Read) RGBA8, BGRA8, YUVA8 Support for 8 bit Video Formats RGBX8,RGB8, BGRX8,BGR8,YUVX8,YUV8,YUYV8,UYVY8,Y_UV8,Y_UV8_420,Y8 Support for 10 bit Video Formats RGBX10, YUVX10, Y_UV10,Y_UV10_420,Y10			Video Formats with per Pixel Alpha (valid only for Framebuffer Read) RGBA8, BGRA8, YUVA8 Support for 8 bit Video Formats RGBX8,RGB8, BGRX8,BGR8,YUVX8,YUV8,YUYV8,UYVY8,Y_UV8,Y_UV8_420,Y8 Support for 10 bit Video Formats RGBX10, YUVX10, Y_UV10,Y_UV10_420,Y10 Support for 12 bit Video Formats RGBX12, YUVX12, Y_UV12, Y_UV12_420, Y12 Driver supports only RGBX12. Support for 16 bit Video Formats RGB16, YUV16, Y_UV16, Y_UV16_420, Y16. Driver supports only RGB16
Supports progressive and interlaced video	IP supported both progressive and interlaced Driver only supported progressive	IP and Driver both support progressive and interlaced video
Maximum and Minimum spatial resolution	Max 8192x4320 Min 64 x 64			Max 10328 x 7760 (Driver tested for standard resolutions up to 8K only) Min 64 x 64
Pixels per clock	1,2,4 ppc				IP supports 1,2,4 and 8 ppc Driver doesn't support 8 ppc

Missing Features / Known Issues / Limitations in Driver

Tested for standard resolutions up to 8K
YUV 12 and 16 bpc color formats support added in IP in 2019.1 but are not supported in driver in 2019.1.
The first buffer returned by the driver will contain the second frame contents, after this the driver will correctly give the data
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/read 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 driver must be enabled in the kernel by selecting option CONFIG_XILINX_FRMBUF

Device Tree Binding

Complete documentation on the device tree requirements may be found in the Linux source located at xilinx_frmbuf.txt

Testing Procedure

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":

Code Block

theme	Midnight

root@hdmi_proj:~# media-ctl -p
Media controller API version 0.1.0
 
Media device information
------------------------
driver          xilinx-video
model           Xilinx Video Composite Device
serial
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:

Code Block

theme	Midnight

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
 
<snip>
 
[ 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).

...

Boards Supported

ZCU102
ZCU106

Change Log

2019.2

Summary
- Add support for low latency capture
Commits
- 107831e v4l: xilinx: dma: Use early callback mode for low latency capture
- 9308da3 Revert "Revert "dma: xilinx: Release buffers before DMA transfer""
- 4036801 Revert "dma: xilinx: Release buffers before DMA transfer"

2019.1

Summary
- Make max-width, max-height dt properties mandatory
- Support 12,16 bpc RGB color formats
- Support early callback using bitmask
- Call the call back registered just before programming the descriptor in EARLY_CALLBACK_LOW_LATENCY mode.
- Add clock framework support
Commits
- 09e6f94 dmaengine: xilinx: frmbuf: Make max-width and max-height mandatory properties
- 04fc254 dmaengine: xilinx: frmbuf: Add support for 12 and 16 bpc RGB formats
- 6ce7c27 dma: xilinx: Release buffers before DMA transfer
- d0489cb dma: xilinx: Support early callback modes
- 1d2bb41 dma: xilinx: Add clock framework support to Framebuffer driver

...