Sony Imx185

[Lcs Basinger]

has anyone been able to get the Sony imx185 to work with the TX2. I manually edited the shipping tegra186-quill-p3310-1000-c03-00-base.dtb file to enable the imx185 in the tegra-camera-platform as there was an entry for the imx185.

However, the device tree is really complicated. I have a different number of CSI lanes so I need to edit it. It seems like it is sourced from numerous dtsi files. Is there one dtsi file I should focus on editing? Or, should I just edit the final tegra186-quill-p3310-1000-c03-00-base.dts flir.dts?

The camera core library provides all of the controls and performs all ofthe processing between the application and kernel-mode V4L2 drivers.Typical use cases for the camera core library interface include:

In applications that support a direct V4L2 interface, you can use this interfaceto communicate with the NVIDIA V4L2 driver without using the camera corelibrary. Use this path for capturing RAW data from a sensor or forvalidating sensor drivers.

Version 2.0: A new version that uses the new Jetson V4L2 CameraFramework to modularize code, simplify sensor driver architecture,and encapsulate redundant code. NVIDIA recommends using only this versionfor new driver development.

A camera module attached to the target platform can consist of oneor more devices. A typical rear camera module includes a complementarymetal-oxide semiconductor (CMOS) sensor. A typical front camera modulemay include a single CMOS sensor.

Properties in this table can be specified in different DTSI files. Forexample, clock, GPIO, and regulator properties can be specified in theplatform DTSI file and the rest of the properties can be specified inthe sensor DTSI files.

Optional. Specifies the regulator for thedevice, where is the regulator name forthe sensor driver. The value is a referenceto the actual regulator name (definedelsewhere in the device tree files),enclosed in angle brackets.

Optional. A Boolean, default value false. Iftrue, the user mode driver delays sendingupdated gain values by one frame. Iffalse, it sends updated gain values tothe driver immediately.

Optional. A Boolean, default value false. Iftrue, the user mode driver bypasses the defaultmode selection logic and uses the TEGRA_CAMERA_CID_SENSOR_MODE_ID controlto select a specific sensor mode. Iffalse, it uses default mode selectionlogic, which selects a mode based onresolution, color format, and frame rate.

Line Information (LI) header pixels help differentiate Vertical BlankPeriod (VBP) rows and different types of exposure rows. Thus there arethree kinds of LI for the diagram above: VBP, long exposure, and shortexposure. VPB rows are filtered out by the VI (video input) module basedon LI.

num_of_ignored_lines is the Number of rows at the top of each exposureframe that are not included in the output frame. This includes OBrows and Ignored Area Effective Pixel rows, both of which use thesame LI header as the exposure frame on which they reside. Hence,these rows are read by the VI module and are cropped out. For theexample above, this value is 14 rows = 8 OB rows + 6 Ignored AreaEffective Pixel rows.

num_of_lines_offset_0 is the Number of VBP rows appearing in a singleexposure and frame in a two-exposure DOL multi-frame. The same numberof VBP rows appear at the end of a long exposure frame and at thestart of a short exposure frame. For the example above, this value is50 (50 rows at the end of a long exposure frame and 50 rows at thestart of a short exposure frame).

For sensor modules that use serializer/deserializer chips (GMSL or FPDlink), the frames received by the SoC are output from SerDes and not fromthe sensors. Therefore, the SerDes pixel clock must be specifiedcorrectly to configure the SoC-camera interface correctly and avoidbuffer overrun issues.

You can start by checking the deserializer output data rate and ensure it is sufficient to stream all the connected sensors. After you determine the proper data rate, the SerDespixel clock can be calculated by using the following equation:

Port index is used to specify the connection between two differentmodules. For the VI (video input) module, the port index represents the input stream.For the CSI module, it represents the actual CSI port to which thecamera is connected.

The following example code lists the controls and their initializedvalues. The initial ctrls_init() call loops through this list toinitialize each of the controls. Each control is then accessible throughthe ctrls handler in the private data. The set of controls defined herefor IMX185 are the standard ones used by the user-mode library.

When the control handlers call each function, it updates theaddress/value pairs specified in the array based on the control types.The array of address/values pairs are used to program the sensor usingthe register write wrapper functions:

Instead of using the default settings in mode tables, you can alsooverride some of the settings in this function by providing updatedvalues. The code below shows how to override gain, exposure and framerate values immediately after the mode tables are programmed to sensor:

Camera Common is a set of kernel functions that are used by thecamera drivers in the NVIDIA kernel and by V4L2 drivers. Camera Commonsets up most of the V4L2 framework. You communicate with it through camera_common_sensor_ops and camera_common_data structures , which youmust define in your driver.

You exercise exposure control with one of two pairs of controls: onepair for 32-bit input parameters (deprecated), and one for 64-bit. Youmay implement and use either pair of controls, but do not implementboth.

The camera core library passesthe frame rate and exposurevalues to the driver with nopreprocessing. The driver isresponsible for converting thesevalues into frame length andcoarse integration timesettings.

If the driver implements the TEGRA_CAMERA_CID_FRAME_RATE and TEGRA_CAMERA_CID_EXPOSURE controls, the received control values are inQ42.22 fixed point format. In this format the upper 42 bits are forstoring integer values and the lower 22 bits are for fraction values.This is a workaround for the lack of floating point capability in thekernel.

Setter-control handlers are the control handlers called by s_ctrl() .They perform additional control-handling operations, such as writes toregisters. The majority of these controls make calls to the controlregister setup functions:

The imx185_ctrls_init() function iterates through ctrl_config_list[] andregisters each control as a new custom control with the V4L2 framework. imx185_s_ctrl() is also called for each control to initialize itsdefault value as defined in ctrl_config_list .

All imager devices must register themselves as sub-devices to the mediacontroller framework. VI (video input) acts as the primary device which controls thebinding, parses the device tree, and establishes the media links onceall of the sub-devices are registered.

Entity is the The unit device represented by the media controllerframework for establishing connections. Each media entity can havemultiple pads. The framework provides a list of known entity typesand corresponding media operations.

Pad is the Determines whether the device behaves as a SINK or a SOURCEport. An imager device must have a SOURCE port which is bound to VI.If an imager device has a SINK port, then the SOURCE port which bindsthe device SINK port must be represented in the device tree tocomplete the binding:

The driver receives control values for the TEGRA_CAMERA_CID_GAIN , TEGRA_CAMERA_CID_FRAME_RATE , TEGRA_CAMERA_CID_EXPOSURE , and TEGRA_CAMERA_CID_EXPOSURE_SHORT controls as fixed point (Q format)values generated using the factor and step properties from the devicetree .dtsi file. It uses fixed point format to avoid using floatingpoint values in the kernel. The driver must convert the fixed pointformat values back to their original precision during finalcalculation.

Control handlers are the actual implementations of the controls. Thereare two types of control handlers in JetsonV4L2 Camera Framework: setter control handlers and fill-string control handlers .

For a version 2.0 driver, the TEGRA_CAMERA_CID_GROUP_HOLD control isrequired. Therefore, each driver must implement the handler for grouphold control. For sensors that do not support hardware group holdfunctionality, create a dummy group hold handler.

All read-only driver-specific controls must have an entry to providevalid data for user space requests. This routine acquires the staticdata from the sensor driver during initialization and assigns it to thecontrols:

Optional. Called during driver initialization toperform critical one-time tasks that are not performedduring normal sensor operations. Examples are readingthe EEPROM/fuse ID and configuring otherperipherals that are needed for sensor operations.

This section describes how the sensor driver is instantiated at kernelboot time. If all steps are performed and no errors are reported, thedriver creates a new V4L2 device tree node for each sensor, and thesensors are ready for use.

LKM is very helpful during sensor driver development, especially fordebugging. Rather than flash a new kernel image to the Jetson device,you can simply unload the driver, update and rebuild the driver, andload the rebuilt driver back into the Linux kernel.

After driver development is complete, you must also add the new deviceinformation to the system kernel device tree so it can be registered(instantiated) when the kernel boots. The below methods are for registeringyour device.

With UEFI boot enabled in this release, the plugin-manager is no longer supported.Now, you need to create a device-tree overlay file to register the camera module.If your camera module has on-board EEPROM and is programmed with a valid camera ID,you can use that to apply the overlay for specific camera module and update thedevice-tree entries with proper information at runtime.Using DTB overlays with EEPROM-ID allows a single system image to support multiple camera devices.To change camera modules, power down the device, replace the camera module, and then reboot.The new module works automatically.

c80f0f1006