This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5708: AM5708 MIPI CSI-2 camera

Part Number: AM5708

Hi:

  
   We use the ar0230 camera sensor on the custom board AM5708 and now we can use some help.

1、hardware design

2、Device tree settings

&i2c3
{
    status = "okay";
    clock-frequency = <400000>;
 
    xc7022@1b {
           compatible = "ovti,xc7022";
           reg = <0x1b>;
 
 reset-gpios = <&gpio5 4 GPIO_ACTIVE_HIGH>
           port {
                csi2_cam0: endpoint@0 {
                       clock-lanes = <0>;
                       data-lanes = <1 2 >;
                       remote-endpoint = <&csi2_phy0>;
                 };
          };
    };
};
&cal {
    status = “okay”;
};
&csi2_0 {
        csi2_phy0: endpoint@0 {
                slave-mode;
                remote-endpoint = <&csi2_cam0>;
        };
};
3、Load the driver, execute the v4l2 application to capture the camera image, the following error will occur
[330.087523] cal-000: no pixel rate control in subdev : xc7022 2-001b

The error, locate the kernel location as drivers/media/platform/ti-vpe/cal.c Under the cal_get_external_info() function
 
 
 

  • Please post which Linux version you use.
  • Hi,

    Looks like the DPHY configuration is not happening properly due to improper handshaking with the sensor driver.

    Please calculate the link rate value for your driver based on your sensor and use case need. You can find a high level documentation about the PIXEL_RATE value calculation from within the kernel documentation (formula show):
    Documentation/media/kapi/csi2.rst (lookup PXIEL_RATE)

    The CAL driver needs to know the link rate (established by camera sensor) to configure the DPHY. CAL driver is based on V4L2 framework and due to the limitation of the framework (only available configurable parameter is V4L2_CID_PIXEL_RATE), it uses pixel rate to calculate the link rate.

    The formula used to pre-calculate the V4L2_CID_PIXEL_RATE value in the reference ov490.c driver is shown near the top of the file (lookup OV490_PIXEL_RATE_PER_LANE) and look at the comment. This value should normally be dynamic based on the resolution, pixel format and number of data lane used. In the ov490 case we only support one resolution and pixel format so the only variable is the number of data lanes being used, hence the hard coded value being used there.
  • Hi:

      SDK: ti-processor-sdk-linux-am57xx-evm-04.03.00.05-Linux-x86-Install.bin

  • Hi
    Camera parameters:
    SENSOR: AR0230 i2c address 0x20
    ISP: XC7022 i2c address 0x36
    ISPout:
    MCLK = 24M
    MIPI lane = 2 lane
    MIPI rate = 960Mbps/lane
    isp output: 1920x1080@30fps_yuv
  • Hi,

    Processor SDK Linux version 4.3 is quite old. I recommend you to migrate to latest Processor SDK.

    You will need to calculate the link rate for your sensor following the document that I pointed earlier and try it out.

    Regards,
    Manisha
  • Hi:
    Camera parameters:
    MIPI lane = 2 lane
    Resolution: 1920x1080@30fps
    Color space:YUV422

    Can you calculate PIXEL_RATE_PER_LANE for me? I don't quite understand how this value is obtained.
  • V4L2 PIXEL_RATE is documented here: www.kernel.org/.../csi2.html

    There you'll see how the pxiel rate is derived from the link frequency.
    Another method, if the sensor's config is correct:

    Given this setup:

    Camera parameters:
    MIPI lane = 2 lane
    Resolution: 1920x1080@30fps
    Color space:YUV422

    Pixel rate is the number of pixels per second so:

    1920 x 1080 x 30 = 62208000

    This would be the value that the driver needs to advertise through the V4L2_CID_PIXEL_RATE control.

    Usually the link frequency method is used if you can read/extract the pll and config directly from the sensor registers as those would be more accurate. What's meant here is that sometime a sensor config mode is labeled as 1920x1080@30fps but the sensor might truly be generating something slightly above or below that which might affect the way we setup the PHY on our side, so the mileage may vary.