Brief introduction to the---Linux ADF (Atomic Display Framework)

Because of the working relationship, there has recently been something related to the ADF (Atomic Display Framework), some of it comes from the internet

The ADF (Atomic display framework) is Google's new display framework to replace Framebuffer. ADF provides a DMA-BUF-based display framework prototype between the Android Hwcomposer Hal and the kernel driver

Structure diagram of the ADF reference from: http://blog.csdn.net/Lost_qwe/article/details/43113301

Let's briefly talk about the effects of these files.

Driver: A program written using the ADF framework custom

ADF_FOPS.C: A file that is responsible for interacting with user space, implements a number of methods (open \ release \ Read \ poll, etc.)

ADF_FOBS32.C: For a file compatible with 32 bits, the implementation will be used to adf_fops.c this file.

ADF_FBDEV.C:FB device external Interface class, is responsible for compatible with FB device.

ADF.C: This is the core file of the entire ADF module, providing various services within the module, mainly providing the message mechanism, synchronization mechanism (fence) and the initialization of the overall ADF.

ADF_CLIENT.C: Mainly used to invoke custom written driver code and wake (Wake up) and so on. Equivalent to the entire fromwork of the final export of the message.

ADF_FORMAT.C: Used to describe which image formats are supported by this boot (RBG \ YUV and specific format definitions).

ADF_SYSFS.C: A file that interacts with SYSFS.

ADF_MEMBLOCK.C: A file with memory management that implements some DMA ops and then registers into the DMA module to implement the memory operation.

ADF_FOPS.C is the gateway to the entire ADF and userspace interactions, and we focus on the adf_file data structure and the IOCTL interface:

• "event_buf" is used to buffer the ADF event signal, where the "Adf_event_vsync" signal is the key to the display screen synchronization

 struct   Adf_file { struct   List_head head;  struct  adf_obj *obj;//sys file node data structure,    Used to create ADF device node Declare_bitmap (event_subscriptions, Adf_event_type_max);    U8 event_buf[ ];//ADF synchronous signal Ring buffer queue     int   Event_head;     int   Event_tail; wait_queue_head_t EVENT_WAIT;//ADF sync Signal Lock};  

enum Adf_event_type {    0    , 1,    +,     255 ,};

• Here is the main channel for the entire ADF and userspace interactions, mainly with Adf_obj_device, adf_obj_interface, and adf_obj_overlay_engine three interfaces

Adf_obj_device---primarily responsible for DMA-BUF, fence,post configuration and management

Adf_obj_interface---primarily responsible for the configuration and management of BLANK,DPM and other interfaces related to DISPC

Adf_obj_overlay_engine---OVERLAY related

LongAdf_file_ioctl (structFile *file, unsignedintCMD, unsignedLongArg) {    structAdf_file *fpriv = file->Private_data; structAdf_obj *obj = fpriv->obj; LongRET =-EINVAL; dev_dbg (&obj->dev,"%s IOCTL%u\n", Dev_name (&obj->Dev), _ioc_nr (cmd)); Switch(obj->type) {     CaseAdf_obj_overlay_engine:ret=adf_overlay_engine_ioctl (Adf_obj_to_overlay_engine (obj), fpriv, CMD, arg);  Break;  CaseAdf_obj_interface:ret=adf_interface_ioctl (Adf_obj_to_interface (obj), fpriv, CMD, arg);  Break;  CaseAdf_obj_device:ret=adf_device_ioctl (Adf_obj_to_device (obj), fpriv, CMD, arg);  Break; }    returnret;}

We'll start by looking at the Read IOCTL,ADF event (including VSync), which will be copied from the kernel space to the user space.

Three different signal statements are provided in ADF.C we take the sync signal out of the DISPC or display driver and then wake up the "event_wait" Wait queue in the Adf_file_queue_event function

After the "event_wait" Wait queue is woken up by the ADF sync signal, the application layer can read through the IOCTL

"adf_device_ioctl" is the configuration and use of the dma-buf,fence that controls the entire ADF, which is the core content of the entire ADF. To understand this piece of content you need to first understand DMA-BUF related API interfaces and fence prototypes

The following references are from the description of "http://blog.csdn.net/YKDSea/article/details/39995075":

Android Fence Sync is a synchronization mechanism introduced in Android, mainly used in the display of graphic buffer synchronization management, can let the operation of buffer can be executed in parallel to reduce the time.
Each buffer in the bufferqueue has a corresponding fence FD, which corresponds to a fence object, which indicates that there is a role in manipulating this buffer when the fence object becomes siganled state. Indicates that the buffer is no longer being manipulated.
Fence can be simply understood as a lock, when it is active to indicate the control of the buffer, when it is signaled state, indicating no longer control buffer, each need to use the role of buffer, Before use, check whether the lock is signaled to carry out safe operation, or wait.

is the flowchart related to "Adf_device_ioctl"

Here is the flowchart related to "Adf_interface_ioctl"

The contents of these two ioctl are many (the figure can be enlarged to see), to figure out that the two ioctl basically the entire ADF framework is understood almost, in the back I will pick out alone to try to analyze (may be fraught)

Brief introduction to the---Linux ADF (Atomic Display Framework)