IPU2 for CSI parallel camera

[harshitsrivasta]

Hi,

I am working on Nitrogen Sabrelite board with extended h/w for enabling dual parallel camera using CSI interface. One camera is working with IPU1-CSI0 combintaion but i am unable to get the second camera up using IPU2-CSI1 parallel interface. I am using current Linux kernel 3.0.35 with release number as 3.0.35_1.1.3. I assume that IPU is initialized properly and we should be able to capture frames atleast.

I have enabled the second camera using board_init functions, required PinMuxes and also additional GPR register setting to enable IPU2-CSI1 connectivity.

mxc_iomux_set_gpr_register(1, 20, 1, 1);

Please guide if there are still things missing from my side.

Regards,

Harshit

[tkwon]

Hello,

I am facing the same issue with the Android Nougat which is using the 4.9 kernel with device tree. 

My device is using the IPU2 and CSI1 as your guys are using. 

Any help will be appreciated. 

Thanks and Regards,

Taehyuk

[harshitsrivasta]

Further to this, i see clock issues when i use IPU2-CSI1. Clock is initially disabled for IPU2, i.e. though we have set it up from U-Boot. Here is the value of register CCM_CCGR3 in start,

1770000F which i changed to 0x1770FFF3 in addition to making changes into CCM_CCOSR register to 0x010E00FB.

When i insert the module, mxc_v4l2_capture.ko, value of register CCM_CCGR3 changes to 0x1770FFF3 which is basically dsiabling of ipu2_ipu_clk_enable. Let me know if somethings is fundamentally wrong in my configuration.

Regards,

Harshit

[EricNelson]

Hi Harshit,

We've successfully connected up an ADV Composite video input device to CSI1, though only recently, on the 4.0.0 branch in our Github repository.

This commit shows the bulk of the work:

     mx6_nitrogen6x: add adv7180 tv input camera · 73898f3 · boundarydevices/linux-imx6 · GitHub

Prior to that, on our 1.1.1 branch we configured the EIM pads as CSI inputs for another customer:

     mx6_sabrelite: setup J12 as CSI1 · 479e101 · boundarydevices/linux-imx6 · GitHub

What kernel tree are you working from? I'm not aware of a release from Freescale with the label "3.0.35_1.1.3".

[harshitsrivasta]

Hii Eric,

Thanks a lot for looking after this issue and response.

We have now moved to imx_3.0.35_4.0.0 and we still see the same issue.

As far as pin muxes are concerned, we are using the below pinmuxes and they seem ok.

MX6Q_PAD_EIM_A17__IPU2_CSI1_D_12,

MX6Q_PAD_EIM_A18__IPU2_CSI1_D_13,

MX6Q_PAD_EIM_A19__IPU2_CSI1_D_14,

MX6Q_PAD_EIM_A20__IPU2_CSI1_D_15,

MX6Q_PAD_EIM_D19__IPU2_CSI1_D_16,

MX6Q_PAD_EIM_A22__IPU2_CSI1_D_17,

MX6Q_PAD_EIM_A23__IPU2_CSI1_D_18,

MX6Q_PAD_EIM_A24__IPU2_CSI1_D_19,

MX6Q_PAD_EIM_DA10__IPU2_CSI1_DATA_EN,

MX6Q_PAD_EIM_DA11__IPU2_CSI1_HSYNC,

MX6Q_PAD_EIM_A16__IPU2_CSI1_PIXCLK,

MX6Q_PAD_EIM_DA12__IPU2_CSI1_VSYNC

In the board config, we have set capture_data for second camera as

static struct fsl_mxc_capture_platform_data capture_data[] = {

{

    .csi = 1,

    .ipu = 1,

    .mclk_source = 0,

    .is_mipi = 0,

},

static struct fsl_mxc_camera_platform_data camera_data = {

    .mclk = 24000000,

    .mclk_source = 0,

    .csi = 0, /* WORKHERE */

    .io_init = mx6q_mipi_sensor_io_init,

    .pwdn = mx6q_mipi_powerdown,

};

This setting is for one camera only as we want to verify this path in isolation first. We are using the CSI1 in parallel mode and disbaled the MIPI/CSI2 interface by setting the GPR register.

Thanks a lot for further inputs on this.

Regards,

Harshit

[EricNelson]

Hi Harsha,

You might want to peruse the patches from a couple of months ago here:

     Commits · boundarydevices/linux-imx6 · GitHub

The ADV718x input device was working in our tree as of June 9.

It's possible that we added something board-specific as in this change:

     mx6_oc: initial addition of board files · ba9038f · boundarydevices/linux-imx6 · GitHub

These "machine_is_x()" calls are the bane of our existence. They usually mean that the

driver writer just didn't take the time to pass in platform-specific data.

This is being addressed quite nicely in the upcoming device-tree kernels.

Regards,

Eric

[harshitsrivasta]

Hi Eric,

Thanks for your help.

After detailed anaylsis and tipps from you, we were able to resolve this issue. Problem was with the Data Enable line and got fixed with the PinMux settings.

Thanks & Regards,

Harshit

[fpp]

Dear Harshit,

I am facing the same problem you describe in your initial post. I also try to get a parallel camera driver to work with IPU2 CSI1 Interface. My System is different from yours because I use Windows Embedded Compact 7. Also I use a different IOMUX MUX configuration because the parallel image sensor is connected to different pads. However:

1) I have programmed the IOMUXC_GPR1, bit 20 to '1', routing the parallel Interface of the sensor to IPU2 CSI1.

2) I have checked, double checked and tripple checked all IOMUX register program code but it seems to be correct from all the documentation I have for the HW I am developing for. Today I even dumped all IOMUX registers after my CSI1 IOMUX setup routine was run to see if the register content really changed to what I intended. I did this to rule out any errors of the DDK-macros involved in programming the IOMUXes. I checked the register dump against the i.MX6 Freescale documentation. But could still not discover any problem. So now I believe it is not the IOMUX programming itself that causes the Problem.

3) I did put IPU2 CSI1 into test mode and YES, if I run the CSI module in test mode I am able to get test images (checker board). That means all the code setting up DMA and delivering images further up the driver stack, is definitly working. But when I switch back to real sensor mode I get no images at all.

4) I have verified the CCM Registers settings, required IPU2 system clocks are switched on (CCM_CCGR3: 0xfffffffc, CCM_CCOSR: 0x000a0001 ).

5) When I connect my sensor to IPU1 CSI0, the real sensor delivers Images. It is only the combination IPU2 CSI1 (parallel sensor interface) that still has problems.

I would be happy if you would be willing to share what exactly you did to the IPU2_CSI1_DATA_EN signal in order to get images from the real sensor. This is the only problem I can think of at the moment.

Regards,

Frank.

[fpp]

Meanwhile I solved problem. I have a HW that is composed of a base board and a processor module (emtrion DIMM-MX6) that actually contains the i.MX6. I did not have access to the outer connection of Ball "D25" (Ball Name: EIM_D23). I assumed n/c. But that proved to be wrong. That signal was pulled low and, thus  IPU2_CSI1_DATA_EN ended up being pulled low - thus no data delivery.

I ended up not mapping IPU2_CSI1_DATA_EN at all now!

Thus, it "hangs in the air" somehow, or, its internal logic value is at least undefined. The Freescale documentation is not clear about the fact what happens, if the IPUn_CSIn_DATA_EN signal is not mapped via IOMUX registers to a pad that eventually would be able to pull the signal up or down, respectively, according to the way the pad is programmed. That would leave HW-Designers however with one pad less to use for other purposes. So I believe now that it seems to be safe not to map DATA_EN for the parallel sensor interfaces.

Regards,

Frank

[Selea]

I have a similar problem (on IMX6), in our hardware CSI1_DATA_EN, is tied low so i always have read error if i try to read from IPU2CSI1 parallel port, so to solve it I need to configure the DATA_EN polarity, but i would like to do it in the DTS file, but i cannot find any label that could change the field

cfg_param.data_en_pol (see: ipu_capture.c file)

it should be a way to configure it for the IPU/CSI....

any suggestion

Thank

Omar

[Selea]

I trie to force the DATA_EN polarity to reverse in the SENS_CONF register (setting =1 the cfg_param.data_en_pol).. but i still have the same problem...

any ideas?

I read above something about CLK CCM setting for IPU2, we are using the 3.10.17 with DTS support, ho to control/set it?

Omar

[fpp]

Omar, do you get images in test mode? If not, you probably do not facing a problem related to DATA_EN. If you get test images check the register settings of the Clock Control Manager - for details see processor doc and discussion above. Finally, I did raise a service request to have Freescale clarify what is happening to a non-muxed DATA_EN. The support answer to this issue was: "Regarding the IPU2_CSI1_DATA_EN signal, its default internal state is Active ("data enabled" state), and it can be changed only by external impact through the IOMUX and external pad...". Hence, by not muxing DATA_EN at all you will receive images. For me not muxing DATA_EN was the solution that got me a working driver.

Regards Frank.

[EricNelson]

Glad to hear it Harshit.