ADV7280M (MIPI) with i.MX6DQ

[oliverg]

I am working on a custom board with linux-fslc 3.14 and am having trouble receiving a data stream from the adv7280m.

I have a hardware mux which switches the CSI pins to an ov5640 MIPI camera - in this case everything works fine. For the adv7280m, I have a simple driver based on ov5640_mipi.c and from the script file ADV7280M_Cust-VER.4.1.txt from ADV7280 / ADV7280-M Design Support Files | EngineerZone. I'm using the script titled "Color Bars 576p MIPI Out".

As with the ov5640_mipi driver, I'm using IPU0-CSI1 and virtual channel 1. These are currently hard-coded in my driver, and the only change I've made to the commands suggested by the Analog Devices script is to set virtual channel 1 (write 0x04 to register 0x0D in the CSI map)

When running v4ltest from userspace, no frames are received. It looks like we never get an end-of-frame interrupt.

I'm following the debug steps posted here: Debug steps for customer MIPI sensor.docx. I see 0 in both MIPI_CSI_ERR registers, but instead of 0x330 in MIPI_CSI_PHY_STATE I see 0x300. Given that the ADV7280M uses only 1 MIPI lane instead of 2, I expected to see 0x310. Do I need "Data Lane 0 in Stop State"? In any case, how can I debug this further?

Thanks for any advice!

[jasongaiser]

Having the same issue with a very similar configuration here.  So far, I've:

Updated the device tree to use only 1 lane.

Updated imx6q_csi_mux_init() to set GPR1[20:19] = 0 so MIPI Virtual Channel 0 is routed to IPU1, CSI0.

Set mipi_dphy_clk to 0x26.

Configured the ADV7280-M for free-run colorbar mode using 480i.

Modified adv7280_mipi_tvin.c (found on this forum) to re-initialize the ADV7280M after powering up the MIPI CSI2 interface.

Sprinkled debug statements everywhere.

I'm seeing MIPI_CSI_PHY_STATE==0x300, with no errors present.  If I try:

gst-launch-1.0 imxv4l2videosrc device=/dev/video0 ! filesink location=test.out

I see 

ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0

and test.out is zero bytes.  

I will try sniffing the MIPI interface with a differential scope to see if things look ok, but as far as I can tell the clock is making it OK.  If I pick an incorrect clock value, I see errors on the data lane, so I think data is hooked up but I need to verify.

Did you ever have any luck getting this working?

Thanks!

[oliverg]

In the end I moved to kernel 4.1, and it worked there

[jasongaiser]

OK, thanks for the reply.  I'll take a look and see if there are some fixes I can back-port to 3.14.

I can now get video from the camera, but:

- Vsync is wrong.  I had to use gated mode(mclk=27000000) because BT656 mode never seems to detect SAV/EAV in the stream.

- Colors/format are wrong.  If I capture a raw video using mxc_v4l2_capture.out, I get pink/purple video which looks to be in planar format, not packed as I would expect.

[igorpadykov]

Hi oliverg

please check mipi one lane settings as in

Using only one lane on OV5640 MIPI + i.MX6 SabreSD 

also useful hints provided on

i.MX6Q video capture issue with ADV7280-M 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[oliverg]

Hi igorpadykov,

Thanks for your reply. I had already changed "lanes" in &mipi_csi to 1, and I have hard-coded "mipi_csi2_set_lanes(mipi_csi2_info, 1);" in my driver.

I neglected to mention, I have also set "mipi_dphy_clk" in &mipi_csi to 0x26. The ADV7280M datasheet specifies 108MHz (I am using the recommended 28.636MHz external crystal), but because I am using the chip's integrated interlaced-to-progressive converter I am expecting a 216MHz clock, which if I am not mistaken corresponds to mipi_dphy_clk=0x26.

As stathisv‌ suggests in the thread you linked, I have tried setting "v_channel" in the &mipi_csi node to 0 despite being on virtual channel 1, but so far I didn't see that it affected anything