Re: i.MX6: can't capture on MIPI-CSI2 with DS90UB954

[jacopo mondi <jacopo@jmondi.org>]

[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]

Hi Jean-Michel,

On Fri, Nov 02, 2018 at 09:09:42AM +0100, Jean-Michel Hautbois wrote:
> Hi Steve,
>
> Le mer. 31 oct. 2018 à 22:52, Steve Longerbeam <slongerbeam@gmail.com> a écrit :
> >
> > Hi Jean-Michel,
> >
> > We've done some work with another FPD-Link de-serializer (ds90ux940) and
> > IIRC we had some trouble figuring out how to coax the lanes into LP-11
> > state. But on the ds90ux940 it can be done by setting bit 7 in the CSI
> > Enable Port registers (offsets 0x13 and 0x14). But the "imx6-mipi-csi2:
> > clock lane timeout" message is something else and indicates the
> > de-serializer is not activating the clock lane during its s_stream(ON)
> > subdev call.
>
> I have been doing more work on the driver I have, and I had CSI
> enabled before the csi2_dphy_wait_stopstate() call for instance. Now,
> LP-11 state is ok.
> Then, in the s_stream subcall, I added a delay after enabling CSI (and
> the continuous clock) and it is better too, as the clock is seen
> correctly each time.
> But I still get into a EOF timeout, which sounds like another issue.
>
> FYI, I added the NFACK interrupt support in my local kernel just to
> see if New Frames are detected, and it is not the case either.
> Any reason for not using this interrupt (maybe in "debug" mode) ?
>
> Now, I used a scope (not very fast so I can't get into the very fast
> signals) and I can see some weird things.
> In a 1-lane configuration, and a 400MHz clock, I can get the following
> when looking at D0N and D0P (yellow and green, can't remember which
> color is which) :
> https://framapic.org/H65QXHvaWmao/qdyoARz12dNi.png
>
> The purple is the diff result.
>
> First I thought it was a start sequence (but with very bizarre things
> at the very beginning of the sequence) like described here :
> https://cms.edn.com/ContentEETimes/Images/EDN/Design%20How-To/MIPI_Sync-Sequence-in-the-transmitted-pattern.jpg
>
> But Jacopo remarked that the 'starting sequence' is actually sent in
> HS mode, so we should not be able to see it at all.
> He thinks that what we are looking at is actually a bad LP-11 -> LP01
> -> LP00 transition.
>
> And it could be the "HS ZERO" :
> https://cms.edn.com/ContentEETimes/Images/EDN/Design%20How-To/MIPI_HS-Burst-on-Data-Lane.jpg

Sorry, my wording was confusing maybe. I think that what we see in
your trace looks very similar to what the image above reports as "HS
ZERO" followed by "HS DATA". This confused me intially as I thought I
was looking at an "HS Sync Sequence" (as defined by D-PHY specs), while
as you reported, my understanding is that your trace shows LP signals,
before any HS data transmission happens (in the right
side of your trace, if I got this rigth) and we should see a stable
LP-11 state transitioning to LP01 and then LP00.

From my experience with ov5640 the i.MX6 seems more picky than other
devices on this. The ov5640 driver before commit:
aa4bb8b ("media: ov5640: Re-work MIPI startup sequence")
used to work fine on other platforms, while it failed on i.MX6 and
thus that patch.

This contrast with the fact that you now passes the:
imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200
error you had reported in your initial email though :/

So please take my interpreation of that traces with a grain of salt, I
really don't want to mis-lead you to chase things that might actually
be correct.

Thanks
   j
>
> What do you think of this ?
> We will conduce more complex measurements, with high speed analyzers
> in order to check everything, and we are right now focusing on a
> possible hardware issue (coule be the custom PCB which embeds the
> DS90UB954).
>
> Thanks,
> JM

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]