Introduction

RidgeRun has more than 12 years experience creating custom Linux V4L2 drivers for embedded systems. The customer selects the hardware sensor or chip and RidgeRun creates the V4L2 driver for it. This wiki describes the services provided by RidgeRun to create a V4L2 driver for your system as well as some of the considerations related to time frame, documentation, hardware, etc. For more information please don't hesitate to contact us.

V4L2 Driver

V4L2 is the official Linux Kernel API to handle capture devices like camera sensors, video decoders or FPGAs feeding video frames to the SoC. The video frames can be component, composite, HDMI, or SDI, or frames from other video encoding standards.

The V4L2 framework defines the API the Linux camera driver supports in order to be V4L2 compliant. The Linux kernel uses the camera driver to initialize the hardware and produce video frames. Each of these functions have an specific implication to the camera sensor. Often the driver interacts with the camera sensor, receiver chip or FPGA using by reading and writing I2C or SPI registers.

Creating a Linux camera driver consists of four steps:

Subdevice driver - camera sensor configuration via I2C, SPI or other low level communication to initialize sensor and support different resolutions. RidgeRun custom drivers support one resolution, other can be added as needed.
Device tree modification
Capture subsystem configuration and video node creation (/dev/video):
- In Tegra X1/X2 involves code needed to configure Video Input (VI) to receive the video coming from the camera. Support to capture from v4l2, libargus and nvcamerasrc (YUV).
- In DM8168 and DM8148, this is the VPSS configuration
- In i.MX6 this is the IPU configuration
- In DM368 this is the VPFE configuration
Application Support:
- Add support to one application like GStreamer, Yavta, etc to grab the frames available in the video node (/dev/video), sometimes this involves creating software patches to support custom color spaces.

Resolutions and controls

Additional CMOS Sensor or V4L2 driver product includes the work to complete each of the stages mentioned above. Its price includes support for one resolution chosen by the customers and others can be added later T&M, normally the hardest part is to get the system capturing frames but once it is working for one resolutions adding others is straight forward.

RidgeRun also provides services to extend the driver to support additional controls like auto white balance, contrast, exposure time, etc if the sensor has this capabilities.

Devices

Some of the devices that might need a V4L2 driver are:

Camera Sensor from different vendors like Sony, Aptina, Omnivision, etc
SDI receivers like Gennum
HDMI receivers
GMSL or FPD Link chips to extend the physical connection of the camera to the SoC
Composite or component decoders
FPGA feeding video

Delivery

Once the driver is done RidgeRun provides the source code of the driver as well as a wiki page with instructions about how to compile and test the driver, normally using applications like GStreamer or Yavta with performance measurements like ARM load and frames per seconds.

Documentation Required

In order to complete the driver RidgeRun needs access to the documentation that describes how to configure the sensor or receiver, this happens normally through i2c or SPI registers unless your driver is a V4L2 driver for a FPGA. For this reason RidgeRun has NDA with:
- Omnivision
- Maxim
- Sony
- Framos
- Aptina
- Toshiba
Although it is not mandatory it is useful to provide the schematics for your board to understand better how are the video receivers connected, details like i2c bus, MIPI CSI2 port, parallel port, clock signal, etc, help RidgeRun engineers to create your driver faster and in some case to detect hardware issues.

Hardware

RidgeRun needs remote or physical access to the hardware to create and test the driver. RidgeRun assumes that there are not hardware issues that would delay the development process (and increase costs). In case of problems with your hardware, RidgeRun will bill up to 20 hours of engineers services for the time needed to inform you what is wrong.
Once we are done with the driver the hardware is shipped back to the customer

Time frame

Creating a V4L2 driver requires between 3 to 4 weeks if RidgeRun doesn't have the driver already done. During this period partial deliveries are provided to the customers as well as progress updates. In case of situations blocking the progress (like hardware issues) these are informed to the customer as well.

Articles related