SPRACD8 June   2019 DRA710 , DRA712 , DRA714 , DRA716 , DRA718 , DRA722 , DRA724 , DRA725 , DRA726 , DRA744 , DRA745 , DRA746 , DRA74P , DRA750 , DRA756 , DRA75P , DRA76P , DRA77P , DRA780 , DRA781 , DRA782 , DRA783 , DRA786 , DRA787 , DRA790 , DRA791 , DRA793 , DRA797 , TDA2EG-17 , TDA2HF , TDA2HG , TDA2HV , TDA2LF , TDA2P-ABZ , TDA2P-ACD , TDA2SA , TDA2SG , TDA2SX

 

  1.   Integrating New Cameras With Video Input Port on DRA7xx SoCs
    1.     Trademarks
    2. 1 Introduction
    3. 2 Video Input Port and Possible Video Sources
    4. 3 Kernel Changes to Integrate Camera Devices
      1. 3.1 V4L2 Endpoint Framework
        1. 3.1.1 VIP Device Definition
        2. 3.1.2 Camera Device Definition
      2. 3.2 Interfacing a Multichannel Video Source (TVP5158)
      3. 3.3 Interfacing a Camera Over LVDS Serializer Deserializer
        1. 3.3.1 I2C Address Remapping
        2. 3.3.2 Serializer/Deserializer Configuration
        3. 3.3.3 Serdes Device Definition
      4. 3.4 Setting up Pinmux and IODELAY
        1. 3.4.1 Getting Pinmux and IODELAY Values
      5. 3.5 Setting Up Board Muxes

3.3.3 Serdes Device Definition

The following example demonstrates device node structure for a camera connected using FPDlink3 ser/des. Here, the deserializer and serializer are connected only via the LVDS link. The camera is connected on the serializer I2C bus. The serializer and camera are not connected to the system I2C bus, but it can be accessed from the system I2C bus. The deserializer maps each of the remote slave onto the system I2C bus and acts as a bridge to transfer any messages addressed to the remote devices.

+-------+ |I2C bus| +-------+ | |0x60<real> +------------+ +-----------|Deserializer|0x60 | +------------+ | X | X | X <LVDS link> | X | X | +----------+ | | Remote | | | i2c bus | | +----------+ | | |0x74<alias> | +----------+ | <- - - - +------|Serializer| 0x58 | | +----------+ | | |0x38<alias> | +---------+ | <- - - - +------|OV Camera| 0x30 | | +---------+ | |

The topology in the example above can be described in the device tree as shown below. Note that the i2cbus here is a local I2C bus connected to the SoC. The lvds_des is just a virtual I2C bus representing the I2C bus at the remote end. That is the reason why the camera is described under the virtual bus.

i2cbus { lvds_des: deserializer@60 { compatible = "ti,ds90ub914aq"; reg = <0x60>; gpio-controller; #gpio-cells=1; i2c-bus-num = <5>; }; }; &lvds_des { ranges = <0x58 0x74>, <0x38 0x30>; lvds_ser: serializer@58 { compatible = "ti,ds90ub913aq"; reg = <0x58>; remote-device = <&lvds_des>; gpio-controller; #gpio-cells=1; slave-mode; }; lvds_cam: camera@30 { compatible = "ov10635"; reg = <0x30>; gpios = <&lvds_ser 0>; /* power pin controlled by serializer local gpio */ }; };

Also, note that the range property decides the address mapping from one bus to other. Address referred to as 0x74 on the remote bus will be aliased on address 0x58 on the local bus.

The advantage with this kind of device modeling is that the kernel driver controlling the camera need not know about the aliases, serializer and de-serializer. Once the Serdes link is ready and aliases are setup, the camera driver works independently without even noticing the I2C transactions getting rerouted. The same driver works on a both cameras connected directly or connected through a Serdes pair.