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

Jagan Teki jagan at amarulasolutions.com
Wed Jul 4 05:18:32 UTC 2018


On Wed, Jul 4, 2018 at 12:11 AM, jacopo mondi <jacopo at jmondi.org> wrote:
> 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 at amarulasolutions.com> 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?
>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg133191.html

Will verify this on my board and let you know the result.

>>
>> 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...

Yes, I've validated through engicam Linux, [1] before verifying to
Mainline. I have similar board which posted on the website on J5 point
20-Polig connector attached to bus to sensor[2]

[1] https://github.com/engicam-stable/engicam-kernel-4.1.15/blob/som_release/arch/arm/boot/dts/icoremx6q-icore-mipi.dts
[2] https://www.engicam.com/vis-prod/101145

Jagan.

-- 
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.


More information about the gstreamer-devel mailing list