On Wed, Jul 4, 2018 at 12:11 AM, jacopo mondi <jacopo@xxxxxxxxxx> 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@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? >> https://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/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.
