Can't get CSI2PHY to receive MIPI traffic

The MIPI interfaces are not supported in OMAP3530 or DM3730.  For this specific problem I believe that if the camera itself is not supplying a clock on the MIPI lines then the reset will never complete as you're seeing.  Hopefully that helps solve your problem.  You've just about tapped out all my MIPI knowledge though, so I hope this solves all your problems!!! ;)

This is actually an OMAP3 SOM-LV, I guess :-)  I'm still trying to get differential probes working, but just looking at trace-to-ground, it seems like the data and clock is probably OK.

In figure 12-53 of the TRM, there is a line marked "PPI+SCP" between the CSIA and the the Complex IO.  Does that represent a resource that the PHY needs?  I also see that it is common to enable voltage regulators before resetting the CSI, but I assume that is for the sake of the sensor and not the ISP?

It also seems like the CSIA uses the CTX lanes to filter input based on Virtual channel and format, and I'm assuming that there are format tags in the MIPI protocol that it uses somehow to decide which CTX to employ.  But even if my formats are mismatched, I would assume that I would still get the frame start and end interrupts from the Complex IO.

Thanks for your help.

I'm starting to believe that there is something other than the PHY not right here.  Now I have tried keeping the camera power off, and manually writing short packets, headers and payload to the debug registers, and still there is nothing.

My writes are:

    for(frame=1; frame<30; frame++) {
        short_packet = frame << 8;
        printk(KERN_INFO "writing short packet %8.8x to %p", short_packet, base+17);
        __raw_writel(short_packet, base+17);  // CSI2_DBG_H  write FS
        short_packet = 0x0A1234 << 8;
        __raw_writel(short_packet, base+17); // A generic short packet with a trace value

                                                                      // so I can see something in CSI2_SHORT_PACKET
       
        for (line=0; line < 480; line++) {
            packet_header = (0x1E<<24)+(1280<<8);  // YUYV format 640x480x2 bytes
            __raw_writel(packet_header, base+17);  // CSI2_DBG_H

            for(i=0; i<(1280/4)+1; i++) {
                __raw_writel(0xCAFEBABE, base+26); // CSI2_DBG_P
            }
        }
        short_packet = (1<<24)|(frame << 8);
        printk(KERN_INFO "writing short packet %8.8x to %p", short_packet, base+17);
        __raw_writel(short_packet, base+17); // Write Frame End
    }

I still see nothing.  No interrupts, no short packet in 480B:D85C, frame counter stuck on 1.

  
480bd800:00000010 00000000 00000000 00000000
480bd810:00001001 00000001 00000000 00007f01
480bd820:00000000 00000000 00000000 00000000
480bd830:00000000 00000000 00000000 00000000
480bd840:00008981 00000000 0000000b 00000000
480bd850:0b000021 00000000 00000000 00000000
480bd860:07ffffff 00000000 00000000 7fffe1ff
480bd870:00010089 0001001e 00000000 00000000
480bd880:00000000 00000003 00000000 00000000

Have you gotten the reset to work?  I wouldn't expect anything to work if you can't get the reset to work.  Did you verify there is a clock on the MIPI lines provided by your camera?  That was critical to another customer.

Yes--there is a clock and data the look reasonable (hardware people have the board right now, double checking).  The reset works as far as the isp.c driver in the BSP is concerned, but it doesn't satisfy the procedure in the TRM.

I'm a little more concerned now about not being able to stimulate the ISP with the CSI2_DBG_{H,P} ports.  I'm loading what i think should be good artificial image that meets the format requirements of the CTX0, and passing some generic short packets besides in hopes of seeing them in CSI2_SHORT_PACKET, but I see nothing...no IRQSTATUS anywhere.  It looks like clocks are all on:

48004f00:00000003 00000000 00000000 00000000

48004f10:00000001 00000000 00000000 00000000

48004f20:00000000 00000000 00000000 00000000

48004f30:00000001 00000000 00000000 00000000

48004f40:00000004 00000002 00000003 00000001

Trying to get the debug ports working on a development board now to validate my expectations at least.

Brad,

When you write "MIPI is not supported in the 3530," do you mean that the the serial protocol that the Complex IO understands is not MIPI compatible?

I can't get my hands on a MIPI spec, so I was assuming that the short packet/long  packet protocols describe in the TRM were basically what constituted MIPI.  Am I mistaken there?

-jk

John Kelly said:

 When you write "MIPI is not supported in the 3530," do you mean that the the serial protocol that the Complex IO understands is not MIPI compatible?

Table 1-3 "Subsystem, Co-Processor, and Peripheral Support on OMAP35x Devices" of the TRM shows which peripherals in the device are supported.  By "supported" I mean "things on which we can answer questions".  Generally speaking I recommend that you steer clear of unsupported features because if/when you run into trouble there is very little help that we can provide you.  Although it's not officially supported I was trying to provide whatever help I could.  Unfortunately I think you've just about exhausted the tiny bit of knowledge I have related to this peripheral!

OK--the reason they CSI2 was catatonic was that VDDS_CSI2 wasn't being properly applied.

Now I am getting these IRQSTATUSes:

omap3isp omap3isp: isp_csi2_isr ISPCSI2_IRQSTATUS 00000200
omap3isp omap3isp: CSI2: ComplexIO Error IRQ 110000

omap3isp omap3isp: isp_csi2_isr ISPCSI2_IRQSTATUS 00000200
omap3isp omap3isp: CSI2: ComplexIO Error IRQ 118000

...Indicating control errors for the lanes, and that the lanes are in ultra low power mode.

I'm trying to defeat this ULPM transition in CSI2_COMPLEXIO_CFG1[24],  but I still get the same result.

Any suggestions?

bash-4.2# cat /proc/isp/CSI2A
phys: 480BD800 mapped: FA0BD800 Size 368

480bd800:00000010 00000000 00000000 00000000
480bd810:00001001 00000001 00000000 00007F01
480bd820:00000000 00000000 00000000 00000000
480bd830:00000000 00000000 00000000 00000000
480bd840:00008905 00000000 0000000B 00000000
480bd850:0A000021 00000000 00000000 00000000 
480bd860:07FFFFFF 00000000 00000000 7FFF61FF
480bd870:000100A9 0000009E 00000000 00000000
480bd880:00000000 00000003 00000000 00000000

Have you correctly programmed the clock/data positions/polarities in CSI2_COMPLEXIO_CFG1?

It seems odd that you're seeing ERRSOTSYNCHS5.  I don't know why there's an error on lane 5 when you only have 2 lanes in use (clock and data).

Yes, though right now I'm not at all confident about the input signals, so we are still researching that end of it.  The camera programming has been pretty well vetted now, but it almost seems as though we are getting parallel rather than serial output from the sensor.