i.MX6 MIPI/CSI-2 virtual channels

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX6 MIPI/CSI-2 virtual channels

Jump to solution
3,358 Views
Contributor III


I'm working on the i.MX6Q board with toshiba chip tc358743 (HDMI->CSI2) and trying to get interlaced modes working. But it only supports one way to distinguish top and bottom fields: through custom Data Identifier of CSI2 packets. So I'm trying to set top field to use 0th channel and bottom field - 1st. But I can't get 1st (or any other except 0th) channel on i.MX6 side.

 

As I understand, these are the steps I need to change virtual channel:

- use corresponding ipu/csi (ipu0 csi1 is for 1st channel for instance);

- configure CSI_MIPI_DI register with the received data type

- configure SMFC_MAP to connect needed channel to csi port

- (optional) configure IOMUX_GPR1 (for i.mx6q) to select MIPI input for ipu0/csi0 or ipu1/csi1 if needed.

 

For configuring MIPI itself there is also a question of correct clocking and other minor stuff. But I get the output correctly when 0th channel is configured. When on tc358743 side I configure different Data Type (for instance 0x23 instead of 0x24) I see that video changes indeed. So this setting works. But when I specify 0x64 (Data Type 0x24, virtual channel 1) I get no frames, playback doesn't start and imx reports:

ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0

 

I'm testing output with the simplest gstreamer pipe:

$ gst-launch-1.0 imxv4l2videosrc ! fakesink

 

I attach dump of all related registers. What am I missing? How can I debug it? I highly doubt that tc358743 may fail to write Data Id of channels != 0 into MIPI packet header.

 

Side question: is it possible to perform interlace between buffers captured by different CSI_MEM channels using custom CPMEM configuration?

Original Attachment has been moved to: 1st-virtual-channel.log.zip

Tags (2)
1 Solution
117 Views
NXP Employee
NXP Employee

To support more virtual channels, you need apply the patch "0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch" first.

It can be got from "iMX6DQ MAX9286 MIPI CSI2 720P camera surround view solution for Linux BSP "

The default BSP has some issue to set the different MIPI CSI2 virtual channel, which will cause CSI_MIPI_DI  = 0xffff24ff, this is wrong, it should be CSI_MIPI_DI  = 0xffffff24 for all virtual channels.

By the way, for the chip tc358743, you should also make sure it can send both MIPI long package (video data) and short package (timing data) to virtual channel 1, some chips can only send long package to virtual channel 1~3 and the short packages are always be sent on virtual channel 0, they can't be supported by iMX6.

View solution in original post

4 Replies
117 Views
Contributor I

how did you fix the issue?i have met the same issue!

thank x alot!

0 Kudos
117 Views
NXP Employee
NXP Employee

And if you are using the old version BSP, such as 3.0.35, then you can apply this patch "0001-Correct-mipi-camera-virtual-channel-setting-in-ipu_c.patch". From "Sample code for iMX6 SabreSD to use MIPI CSI camera with virtual channel 3 ". It can also fix this MIPI virtual channel issue.

0 Kudos
118 Views
NXP Employee
NXP Employee

To support more virtual channels, you need apply the patch "0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch" first.

It can be got from "iMX6DQ MAX9286 MIPI CSI2 720P camera surround view solution for Linux BSP "

The default BSP has some issue to set the different MIPI CSI2 virtual channel, which will cause CSI_MIPI_DI  = 0xffff24ff, this is wrong, it should be CSI_MIPI_DI  = 0xffffff24 for all virtual channels.

By the way, for the chip tc358743, you should also make sure it can send both MIPI long package (video data) and short package (timing data) to virtual channel 1, some chips can only send long package to virtual channel 1~3 and the short packages are always be sent on virtual channel 0, they can't be supported by iMX6.

View solution in original post

117 Views
Contributor III

Sorry for the long absence of the reply. I have switched to a different task, and the de-interlace was dropped for now. I have confirmed that from the side of tc358743 I did everything correctly. So the issue is indeed in the way I have configured i.MX or in the short/long packages from the chip.

For now, this issue is postponed/worked around so I will try later to check if the patch you've mentioned contains anything I haven't tried (from the first look it doesn't). But since I don't know if I will have time for it now, I'm closing the issue. Thanks for the leads.

0 Kudos