分类： LINUX
2012-01-19 14:29:06
Contents [hide] |
Media Controller is a framework for developing V4L2 based drivers which, compared the earlier implementation of plain V4L2 has a broader view device architecture. While the plain v4L2 had a view of the device as a plain DMA based image drabber which connects the input data to the host memory, the Media Controller takes into consideration the fact that a typical video device might consist of multiple sub-devices in form of either sensors, video decoders, video encoders working in tandem, and also the fact that image grabbing and display is not a simple DMA but might consist of smaller sub-blocks which might do some processing like resizing, format conversion etc. The document below explains these changes in design philosophy and elaborates on the nuts and bolts that make the media Controller as it is today. It also dwells upon the DM365 specifics implementation details for the VPFE capture driver.
Media DeviceA Media device is the umbrella device under which multiple sub-entities called Media entities can be accessed, modified and worked upon. The Media Device is exposed to the user in form of a device file, which can be opened to enumerate, set and get the parameters of each of the media entities. For example, in DM365 implementation the entire VPFE capture device with its IPIPE, IPIPEIF, CCDC etc is exposed as a Media Device - /dev/media0. If there were a display driver, it would be exposed as a Media device too.
Media EntityA Media entity is a sub-block of a a particular media device which usually does a particular function, can be though about as an connect-able but self-contained block which might have a register set f its own for setting the parameters and can be programed in an independent way. This could be a sub-IP, or a helping device on the same board which offloads a particular function like RAW Capture, YUV Capture, filter etc. On DM365 all the sensors, Video Decoders are media entities and the core itself has been modeled with CCDC, Previewer, Resizer, H3A, AEW as entities. These could be enumerated in the standard V4L2 way using the Media device as the enumerating device. Each of these entities has one or more input and output pads, and is connect-able to another entity through a 'link', between the pads.
Sub-devicesConceptually similar to a media Entity, a subdevice is viewed as sub-block of a V4L2 Video device which is independently configurable through its own set of file operations. The file operations are exposed through V4L2 -like IOCTLS particular to subdevs.Each sub-device is exposed to the user level through device files starting with “subdev-*”. User applications need to configure V4L2 related settings like format, crop,, size parameters through these device handles for each of the sub-devices to make the work in tandem. Structurally, there is almost an one-to-one correspondence between a Media Entity and a sub-device.
“Pads” are input and output connect-able points of a Media Entity. Depending on the number of connections the entity can have the pads are pre-fixed in the driver. Typically, a device like a sensor or a video decoder would have only an output pad since it only feeds video into the system, and a /dev/video pad would be modeled as an input pad since it is the end of the stream. The other entities like Resizer, previewer would have typically an input and an output pad and sometimes more depending on the capability.
LinkA link is a 'connection' between pads of different entities. These links can be set, get and enumerated through the Media Device. The application, for proper working of a driver is responsible for setting up of the links properly so that the driver understands the source and destination of the video data.
Entity GraphAn entity graph is the complete setup of different entities, pads, and the links. For proper working of the software, an entity graph should be properly setup, and the driver, before it can start streaming will validate for the proper graph and the appropriate settings on the sub-device to get to know the intent of the application. Choice of if the video input is RAW BAYER or YUV video is determined by the appropriate setup of the entity graph.
The DM365 supports the following fixed entity and pad configuration.
Continuous Mode refers to the configuration where the input data stream is regulated by the standard capture format like NTSC/720p etc and where the data is input from an external source t be stored int DDR. Here the input data is “streamed” to the DDR and thereby the exchange of buffers between drivers and applications happen on a continuous basis regulated by the interrupts generated at every field or frame. So, the sink is invariably a video node whereas the source is an external sensor or decoder or an inbuilt ADC. The streaming mode supported here is the standard V4L2 mode of streaming.
As opposed to “continuous mode”, “single-shot mode” is referred to setup where the data input is from DDR as opposed to an external source, and the output is DDR again. So here both the source and sinks are video nodes. To facilitate this kind of interface, the input DDR source is mapped to a separate Video device, which is only used in case of single shot modes. Here the input video node supports a source media device pad, and the output video node supports a sink media device pad.
The driver here supports buffer exchanges on input and output using the standard V4L2 calls, with an exception that the present driver supports a single buffer at a time. In DM365, the list of Single shot drivers is as follows:
