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@xxxxxxxxx> 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:
signature.asc
Description: PGP signature
