...
| IP features | 2018.1 | 2018.2 | 2018.3 | 2019.1 | 2019.2 | 2020.1 | 2020.2 | 2021.1 | 2021.2 | 2022.1 | 2022.2 | 2024.1 | 2024.2 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IP version | 2.0 | 2.1 | 2.2 | 2.3 | 2.4 | 2.5 | 3.0 | ||||||
| Compatible string | xlnx,axi-frmbuf-wr-v2.2(2023.1 and above) | ||||||||||||
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 | Added support for Y_U_V8 3 planar video format. | Added support for Y_U_V10 3 planar video format. | Added support for Y_U_V10 3 planar video format. | Added support for Y_U_V12 3 planar video format. Added support for RGBA8, YUVA8, BGRA8. Added Support for Raster to Tile format. (Linux driver support will be available from 2025.1) | |||||||
| 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 | Max 15360 x 8640 Min 64 x 64 | ||||||||||
| Pixel per clock | 1,2,4 ppc | 1,2,4 and 8 ppc in IP Driver supports only 1,2,4 | Driver supports 1, 2, 4 and 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.
- For 2020.2, the field id reported in the IP register may be incorrect due to bug in IP / Vitis HLS tool.
Kernel Configuration
The driver must be enabled in the kernel by selecting option CONFIG_XILINX_FRMBUFDevice Tree Binding
Complete documentation on the device tree requirements may be found in the Linux source located at xilinx_frmbuf.txtTesting 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 | ||
|---|---|---|
| ||
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]
|
| Code Block | ||
|---|---|---|
| ||
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 |
...
2020.2
- Summary
- Correctly free up resources while removing dma
- Fix Y10 v4l2 pixel format
- Fix for Coverity warnins
- Use AP_DONE instead of AP_READY
- Commits
2020.1
- Summary
- Add support 8 ppc
- Commits
- bb91ad8 dmaengine: xilinx: frmbuf: Add support for 8 ppc
2019.2
- Summary
- Add support for low latency capture
- Commits
...