Adv7282 PAL to MIPI CSI Linux Driver Development

actually, i have marked to @ShaneCCC.

Have a check the MIPI spec for the continuous clocks.

From datasheet of ADV7282 i can clearly see it wont support the feature of discontinous clock


so there is no point enabling discontinous clock in DT

so coming back again to the error posted above, i am seeing the registers throwing no error on jetson nano, but still i am seeing the channel error 4000

[ 382.706704] adv7282 7-0021: adv7180_mbus_fmt: w=720, h=576
[ 382.706708] adv7282 7-0021: adv7180_mbus_fmt: w=720, h=576
[ 382.827556] vi 54080000.vi: cil_settingtime was autocalculated
[ 382.827566] vi 54080000.vi: csi clock settle time: 13, cil settle time: 10
[ 382.829220] vi 54080000.vi: tegra_channel_error_status:error 4000 frame 0
[ 383.041201] video4linux video0: frame start syncpt timeout!0
[ 383.046948] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[ 383.046953] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000000
[ 383.046957] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00000000
[ 383.046997] vi 54080000.vi: cil_settingtime was autocalculated
[ 383.047001] vi 54080000.vi: csi clock settle time: 13, cil settle time: 10
[ 383.055122] vi 54080000.vi: tegra_channel_error_status:error 4000 frame 2
[ 383.075031] vi 54080000.vi: tegra_channel_error_status:error 4000 frame 3

kindly help

The discontinous in device tree only configure the host(Nano) you need to configure the device too.
It could be CSI didn’t receive any thing to report the error state.

you meant to say that the IC did not throw any kind of data ? over MIPI Lines ?
i am very much sure the mipi lines are throwing data, any way i shall come back with the probe shots

I mean It could be the output signal have problem get validate data from CSI.

One thing i observed is my MIPI Clock itself is not availble, i asked analog if i did any mistake with the driver, they responded as below

*As part of the MIPI specification the MIPI receiver needs to terminate the signals correctly. The termination required changes depending on the MIPI mode (e.g. high speed, low power mode etc). The receiver needs to detect the mode of operation and dynamically set its termination accordingly.*

does the MIPI Rx of Nvidia wait for transition from HS to LS Modes ?

in which part of the driver i can check if anything is going wrong ?

That’s should be the logic behavior instead of configure by any REG.

Data after launching video capture / cheese


Clock after launching video capture / cheese

clock is kept trigger and very primary sequence of pulses seens over clock and data just after launching video capture command(cheese), is it as per spec ?

green is data, clock is yellow

Hi, from hardware side, is the scope bandwidth enough for MIPI test? Have you checked the signals based on MIPI spec?

the scope is 200MHz, 5gsps,below is the shot from a high freuency scope(2.5GHz,20Gsps), i wanted to see the train of pulses are coming or not as per plan

@Trumany
can we conclude that the electrical connections are proper but the configuration of IC is improper ?
so that i can concentrate on driver rather than doubting the reliability of hardware ?

Kindly respond

@ShaneCCC @Trumany
can you please conclude the issue, so that i will move forward
if the issue is hardware i have design new hardware
if the issue is software i shall jump back to code to see what exactly is going wrong.

I would suggest to debug in discontinuous mode to follow MIPI spec to tune the settle time to try. (Could be the timing of LP state)

sorry for late response, due to my holiday i could not debug
You mean, the scope shots conclude that there is no issue with the hardware side ?
if so i will start debugging the software side one by one.

can you please explain a bit in detail ? already the clock is in discontinous mode.

From software point of view I don’t have any further idea now.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.