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.

Linux/DRA76P: J6P Linux CAL driver is not working

Part Number: DRA76P

Tool/software: Linux

Hi experts,

we tried to enable J6P CAL Linux driver (kernel version 4.4.110)following the CAL guide from http://processors.wiki.ti.com/index.php/Linux_Core_CAL_User%27s_Guide

and met some issues. The signal path in our HW design is like this: (ov10635 -> DS90UB913)  x 4  -> DS90UB964 -> J6P MIPI-CSI2 in.

Firstly, we are using 964 internal pattern,for example 1280x720@30fps YUV422, to debug CAL driver.

However, we can never capture MIPI signal from cal driver, from log we always see this timeout log when start capture, and no any data can be captured, grep /proc/interrupts, no CAL intterrupt generated.

cal-000: CAL_CSI2_COMPLEXIO_CFG(1) = 0x4a054321 Complex IO Reset Done (250) (timeout)

the message is from function: csi2_wait_for_phy [drivers/media/platform/ti-vpe/cal.c], what's the problem?

And i checked registers

0x4a009030 = 0x00070000,

0x4a009000 = 0x00001202,

we can see VIP3_GCLK is NOT in working status. However, from TRM, CAL needs VIP3_GCLK to work.

I don't know how to force 0x4a009030 to a working status in cal  driver, so i manually set this register to 0x00040001 with omapconf tool before" insmod ov1063x.ko".

But result is same. Could you tell me how to deal with this?

Another thing is regarding the value of " ctx->external_rate" in CAL driver, I consider it as the pixel freq, however, for 964 pattern mode, how to calculate its value, i tried 800Mhz, because i set 964 CSI TX to 800Mbps, unfortunately, it's not working and keep same issue.

I also checked other important registers, like the lane configuration registers:

0x4a0026dc = F8000900

0x489b0304 = 4A054321

the value looks ok, all match our HW design

attach CAL block diagram in J6P TRM

  • Hello,

    For capturing video from OV10635 + 913 + UB964, we recommend to use Vision SDK
    It is a RTOS based SDK which deals with the vision related usecases.
    Vision sdk has support for this combination.


    Regards,
    NIkhil D
  • Hi NIkhil,
    Thanks your quick reply!
    So far we have not enabled RTOS (M4) part in our J6P board yet. That maybe cost more time for us. Currently we just want to verify our AVM HW design quickly. And we already have a working Linux kernel & rootfs. So we want to use Linux CAL driver & app to check the capture. Could you help us with the CAL driver issue? Thanks a lot!
  • Hi,

    The reason I recommend to use Vision SDK is because Vision SDK drivers have features required for UB964
    Linux CAL driver does not support virtual channel capture, so you cannot capture 4 channel video from UB964.

    If you want it in Linux, you should write a V4L2 subdevice driver (similar to the OV490.c) and implement few important operations.
    Regarding the Linux issue, I think it is stuck in the PHY reset sequence.
    Now, the CSI PHY is waiting for the LPHS transition sequence to be detected to be able to reset.
    Make sure that the s_stream operation implements the stream ON/OFF functionality for the UB964.

    You have to make sure that, when the s_stream is called, only then the UB964 should start sending the CSI packets, this would make the PHY come out of reset.


    Regards,
    Nikhil D
  • Hello Nikhil,
    Thanks your explanation!
    The moment, we don't need show all 4 camera at same time,so far CAL driver is ok for us.
    There has already a V4L2 subdevice driver for ov10635 sensor chip in kernel folder: drivers/media/i2c/ov1063x.c. And I use it as ov10635 sensor driver.
    Some configurations in ov10635, like xclk = 24MHz, gpio, have been checked.


    For DS90UB913/DS90UB964, they have been init through another built-in FPD driver, befor CAL driver probe starting. The i2c registers value of 964/913 are from vision SDK. When kernel boot is done, I will manually insert ov1063x.ko, then run:
    yavta -c30 -fUYVY -Fvout_1280x720 -s1280x720 /dev/video2.

    I already checked when this command line is issued,CAL function : 'cal_start_streaming' will be called, then ov1063x_s_stream will be called.

    And I can see valid value from 0x73~0x76 (RX port) registers of DS90UB964, that means data from ov10635 has been detected by DS90UB964.
    But I always get same timeout error from CAL driver : "cal-000: CAL_CSI2_COMPLEXIO_CFG(1) = 0x4a054321 Complex IO Reset Done (250) (timeout)", and no cal intterupt can be seen.

    I also tried DS90UB964 internal video pattern instead of getting video from ov10635, but result is same.

    I don't know what's wrong with the CAL driver,I'd like to ask below 4 questions:


    1.  When I issue above yavta capture cmd line, I get below CAL clocks registers value, from these values,can we say CAL clock are working correctly:
    -----------------------------------------
    # omapconf read 0x4a009030
    00040001
    # omapconf read 0x4a009000
    00001602
    ----------------------------------------

    2.  ctx->external_rate value, what's the value should I set?
    Currently, video format is 1280x720@30fps YUV422 8bit (CSI2 type=0x1E).
    If I set DS90UB964 CSI2 tx speed as 800Mbps.(964 register:0x1F), set 'ctx->external_rate = 200MHZ', is right? or other value?

    3.  in probe procedure, I see below debug info, it seems that expecting value differ from actual value, is it ok?
    [ 0.709207] cal: CAL_HL_REVISION = 0x40000300 (expecting 0x40000200)
    [ 0.709212] cal: CAL_HL_HWINFO = 0xa3c90469 (expecting 0xA3C90469)

    4.  our HW engineer use shielded twisted pair(in red circle) to connect AVM board with J6P mipi pin,see the picture.
    is this OK for MIPI signal transmission?

    Could please help? Thanks a lot!

    the kernel version we used is 4.4.110. some CAL driver debug information is as below:

    =============================================================================================

    [ 18.987214] cal-000: cal_start_streaming in <
    [ 18.987219] cal-000: sensor Pixel Rate: 200000000 ( ctx->external_rate)
    [ 18.987248] cal-000: CAL_CSI2_CTX0(1) = 0x00000101
    [ 18.987254] cal-000: CAL_PIX_PROC(1) = 0x000d0015
    [ 18.987259] cal-000: pix_proc_config : ctx->fmt->bpp:16,extract:0xa,pack:0x5
    [ 18.987265] cal-000: CAL_WR_DMA_CTRL(1) = 0x0b404304
    [ 18.987270] cal-000: CAL_WR_DMA_OFST(1) = 0x00000a00
    [ 18.987276] cal-000: CAL_CTRL = 0xff1fe07e
    [ 18.987281] cal-000: CAL_CSI2_COMPLEXIO_CFG(1) = 0x00054321
    [ 18.987306] cal-000: CAL_CSI2_COMPLEXIO_CFG(1) = 0x40054321 De-assert Complex IO Reset
    [ 18.987311] cal-000: num of lane:4,fmt-bpp:16
    [ 18.987315] cal-000: csi2_ddrclk_khz: 400000
    [ 18.987319] cal-000: ths_term: 8 (0x08)
    [ 18.987323] cal-000: ths_settle: 46 (0x2e)
    [ 18.987329] cal-000: CSI2_0_REG0 = 0x0100082e
    [ 18.987335] cal-000: CSI2_0_REG1 = 0xe002e10e
    [ 18.987341] cal-000: CAL_CSI2_TIMING(1) = 0x00004197 Stop States
    [ 18.987347] cal-000: CAL_CSI2_TIMING(1) = 0x0000c197 Force RXMODE
    [ 18.988763] cal-000: CAL_CSI2_COMPLEXIO_CFG(1) = 0x4a054321 Powered UP
    [ 24.104608] cal-000: CAL_CSI2_COMPLEXIO_CFG(1) = 0x4a054321 Complex IO Reset Done (2500) (timeout)
    [ 24.104617] cal-000: CAL_CSI2_TIMING(1) = 0x00004197 Stop State Reached
    [ 24.104624] cal-000: CSI2_0_REG1 = 0xe002e10e (Bit(31,28) should be set!)
    [ 24.104630] cal-000: cal_start_streaming out>

    =============================================================================================

    Regards

    David

  • Hi David,

    CSI clocks are enabled. You would see a L3 warning backtrace if any of the clock was enabled and driver tried to access it.

    Pixel rate and link frequency can be calulated from each other. The CAL driver calulcates the link frequency based on the pixel rate.

    Refer to this document on the details of the V4L2 controls - https://dri.freedesktop.org/docs/drm/media/kapi/csi2.html

    I assume you are setting the link freq to 800Mhz. If so, you can calulate the PIXEL_RATE from the above formula.

    I am not sure about the hardware revision mismatch, I'll check this and get back.

    We have used such cables for connecting MIPI CSI interfaces, but I don't have details on exact hardware parameters.

    As mentioned in my earlier mail, most likely the DPHY timeout because the PHY can't see the LPHS transition by the camera.

    If you implement s_stream to only control the remote camera, it may start/stop the video transmission from the remote side. But as per CSI standard, the CSI transmitter should keep LP11 states before transmitting anything, then V4L2 driver calls s_stream, at which point, the transmission should start (I am talking about CSI transmission here), this state change is detected by the DPHY and you shall see PHY coming out of reset.

    Most likely, you will have to turn off/ turn on the CSI lanes on the UB964 as part of the s_stream implementation. For now, you can just check the DPHY status using omapconf, try to use i2c read/writes to turn off/on the UB964 lanes and see if the DPHY comes out of reset. If you are successful, do it the proper way through s_stream callback.

    I hope this helps

    Regards,

    Nikhil D

  • Hello Nikhil,
    Thanks your quick response!
    I tried your suggestion,but unfortunately, the issue is same as before. register 0x489b0304 bit 29 always keeps '0' -- reset is on going.
    --------------------------------------
    omapconf read 0x489b0304
    4A054321
    --------------------------------------

    I tried both manually and with callback to close/open CSI2 port. The procedure is as below:

    1. I increase checking times of reset done bit (for examples 5000 times) in CAL function: csi2_wait_for_phy, and set CSI2 of 964 to off in FPD driver, only after issued yavta capture command, i will manually set CSI2 to on through i2c tool, and from oscilloscope, I make sure MIPI signal is generated.

    2. I also tried put the above manual operation into ov1063x_s_stream function, only after the stream is on, i will set CSI2 of 964 to on.But result is still same.

    I tried the above cases with ctx->external_rate = 200MHz & 400MHz respectively.

    Below picture is the mipi clock signal captured from oscilloscope:

    Do you have any other suggestions? Thanks a lot!

    Regards
    David

  • Hi David,

    That is the only dependency on the PHY reset. HW should automatically detect the state transitions and set the reset done bits.

    Regards,

    Nikhil D

  • Hello Nikhil,

    If register - 0x489b0304 bit 29 always keeps '0' -- reset is on going, CAL can't work, is that understanding true? If yes, Bit 29 should always keep '1' during capture, right?

    Now, I keep modifications done in last Friday, and add a automatic capture script into system launch script.

    Reboot system several times, and sometimes I can see bit 29 = 1, (0x489b0304 = "A4054321") with the "omapconf", but several seconds later, the value will change to 4A054321, bit 29 =0 again.

    What could be the problem?

    Thanks

    Regards

    David

  • Hello Nikhil,
    The Linux CAL driver is working now in my board, the issue is that all lanes (4 data  + 1 clock ) polarity  are swapped, origin setting is for +/-, actual connection is  -/+ . Previously I was told using +/- polarity. BTW, during capturing, bit 29 should always keep 1.

    Regards
    David

  • Glad to know the issue is resolved

    Nikhil D