Re: i.MX6 MIPI-CSI2 OV5640 Camera testing on Mainline Linux

From: jacopo mondi
Date: Tue Jul 03 2018 - 14:41:28 EST

Hi Fabio,
thanks for pointing Jagan to my series, but..

On Fri, Jun 29, 2018 at 06:46:39PM -0300, Fabio Estevam wrote:
> Hi Jagan,
> On Fri, Jun 1, 2018 at 2:19 AM, Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote:
> > I actually tried even on video0 which I forgot to post the log [4].
> > Now I understand I'm trying for wrong device to capture look like
> > video0 which is ipu1 prepenc firing kernel oops. I'm trying to debug
> > this and let me know if have any suggestion to look into.
> >
> > [ 56.800074] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x000002b0
> > [ 57.369660] ipu1_ic_prpenc: EOF timeout
> > [ 57.849692] ipu1_ic_prpenc: wait last EOF timeout
> > [ 57.855703] ipu1_ic_prpenc: pipeline start failed with -110
> Could you please test this series from Jacopo?
> It seems that it would fix this problem.

... unfortunately it does not :(

I've been able to test on the same platform where Jagan has reported
this issue, and the CSI-2 bus still fails to startup properly...

I do not have CSI-2 receiver driver documentation for the other platform
I am testing on and where my patches improved stability, but the i.MX6 error
reported by Jagan could be useful to help debugging what's wrong with the
serial bus initialization on that platform.

The error comes from register MIPI_CSI_PHY_STATE of the i.MX6 MIPI_CSI-2
interface and reads as:

0x2b0 : BIT(9) -> clock in ULPS state
BIT(7) -> lane3 in stop state
BIT(5) -> lane1 in stop state
BIT(4) -> lane0 in stop state

The i.MX6 driver wants instead that register to be:

0x430 : BIT(10) -> clock in stop state
BIT(5) -> lane1 in stop state
BIT(4) -> lane0 in stop state

So indeed it represents a useful debugging tool to have an idea of what's going
on there.

I'm a bit puzzled by the BIT(7) as lane3 is not connected, as ov5640 is a 2
lanes sensor, and I would have a question for Jagan here: has the sensor been
validated with BSP/vendor kernels on that platform? There's a flat cable
connecting the camera module to the main board, and for high speed
differential signals that's maybe not the best possible solution...

Also, anyone interested in my mumbling on the ov5640 MIPI bus
initialization, I've collected some thoughts here:

Any comment is of course welcome, and if I have a confirmation that
the Engicam platform works with that flat cable, I'll keep working on


> Thanks

Attachment: signature.asc
Description: PGP signature