Deep understanding of the Linux kernel v4l2 framework videobuf2 "Go"

Turn from: 8444193

Videobuf2 Frame

1. What is the VIDEOBUF2 framework?

It is a V4L2 compatible driver framework for multimedia devices and is the middle tier for user space applications and device drivers. It provides a much lower level of modular memory management for the driver.

It can make the development of the drive simple, reduce the amount of code, and help the reasonable continuous implementation of the V4L2 interface in the drive .

VIDEOBUF2 's memory management is fully modular, allowing for the ability to customize memory management methods for devices and platforms without changing the higher-level buffer management framework.

The framework provides three types of:

• V4l2_ioctl flow control and file operation are realized.

• Advanced video buffering, video queuing and state management

• Video buffer memory allocation and management

2. why should a new framework be developed?

In the current VIDEOBUF implementation, there are a lot of problems, in the year of the Horschinki summit highlighted the following:

• V4l2 API unexpected and faulty memory management design

• Cannot stop stream request, buffer is released at Streamoff

• Vidioc_reqbufs does not release memory, nor can it reallocate memory

• Mmap is present inthe video, qbuf or page error is assigned

• Each buffer has a waiting queue

• Not enough extensibility, especially for embedded multimedia devices

• Difficult to add custom memory allocation and management mechanisms

• No support for cache coherency and Iommu devices

• Not flexible enough, only a set of all functions to handle memory locking, caching, sg-list creation

• Many unused fields, as well as code duplication, obscure cryptic naming

Many driver authors publish base components that are based on VIDEOBUF. Developers also acknowledge Videobuf 's exploits and are happy to use it, but cannot do so because of the lack of flexibility.

3. purpose of re-design

• Fixed v4l2api implementation to fix videobuf problems and defects

• Detach buffer queue management and memory management

• More flexibility in the allocation and management of memory, which can be embedded in custom mechanisms

• More targeted driver callback functions, called in different places

• Support for new V4L2API extensions, such as support for multi-plane video frame storage

4. Driver callback function

Symmetric drive callback function design:

• Buf_init is called once the memory is allocated or a new userptr buffer is queued, such as for locking pages, verifying continuity, setting Iommu mappings, and so on.

• Buf_prepare Each qbuf is called to synchronize the cache, copy the data to buffer, etc.

• Buf_finish each dqbuf call, used to synchronize the cache, retrieve data from buffer, etc.

• Buf_cleanup is called when free/release memory.

The rest of the callback functions are also redesigned:

• Queue_negotiate now incorporates multiple planes of expansion, the number of buffers required to return the drive, and the number of planes per buffer.

• Plane_setup Drive Returns the dimension size of the plane

These two calls take the place of the old Buf_setup

• Buf_queue retains its original function and puts the buffer into the request queue.

5. memory allocation and processing

Memory processing This block is designed to be more personalized, allowing memory allocations to be customized and custom functions placed in a struct called v4l2_alloc_ctx. Its purpose is to provide videobuf with operational functions and to store some private data. Private data can be embedded in a larger number of structures.

Struct Vb2_alloc_ctx {

const struct VB2_MEM_OPS *mem_ops;

}

struct VB2_FOO_ALLOC_CONF {

STRUCDT Vb2_alloc_ctx Alloc_ctx;

/* Private data*/

}

More importantly, the concept of a buffer context structure is introduced, after each allocation, the allocator returns their own, custom, and per -buffer structures. This structure can be passed as a cookie to other memory processing methods.

Memory operations stored in the allocator context can be replaced by other allocators, and detailed documentation can refer to Videobuf2-core.h.

A very good example from the Samsung Galaxy S series Android phone kernel source code in the VIDEBUF2-CMA.C, can look at this example.

Deep understanding of the Linux kernel v4l2 framework videobuf2 "Go"