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

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

[Jean-Michel Hautbois]

Hi there,

I am using the i.MX6D from Digi (connect core 6 sbc) with a mailine
kernel (well, 4.14 right now) and have an issue with mipi-csi2
capture.
First I will give brief explanation of my setup, and then I will
detail the issue.
I have a camera sensor (OV2732, but could be any other sensor)
connected on a DS90UB953 FPD-Link III serializer.
Then a coax cable propagates the signal to a DS90UB954 FPD-Link III
deserializer.

The DS90UB954 has the ability to work in a pattern generation mode,
and I will use it for the rest of the discussion.
It is an I²C device, and I have written a basic driver (for the moment
;)) in order to make it visible on the imx6-mipi-csi2 bus as a camera
sensor.
I can give an access to the driver if necessary.

I then program the MC pipeline :
media-ctl -l "'ds90ub954 2-0034':0 -> 'imx6-mipi-csi2':0[1]" -v
media-ctl -l "'imx6-mipi-csi2':1 -> 'ipu1_csi0_mux':0[1]" -v
media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" -v
media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
media-ctl -V "'ds90ub954 2-0034':0 [fmt:RGB888_1X24/1280x720 field:none]"
media-ctl -V "'imx6-mipi-csi2':1 [fmt:RGB888_1X24/1280x720 field:none]"
media-ctl -V "'ipu1_csi0_mux':2 [fmt:RGB888_1X24/1280x720 field:none]"
media-ctl -V "'ipu1_csi0':2 [fmt:RGB888_1X24/1280x720 field:none]"

Everything works fine, all nodes are correctly configured, and the
DS90UB954 is normaly sending data on 2 lanes, with VC-ID=0.
The pattern is 1280x720@30 RGB888.

Then, I start a Gstreamer pipeline (I tried with v4l2-ctl and have the
same issue though) :
GST_DEBUG="v4l2:5" gst-launch-1.0 v4l2src device=/dev/video4 !
video/x-raw, width=1280, height=720, format=RGB ! fakesink

And... well, I had to use this patch
https://lkml.org/lkml/2017/3/11/270 in order to go further, but I am
finishing into :
[  164.077302] imx-ipuv3-csi imx-ipuv3-csi.0: stream ON
[  164.097955] imx-ipuv3-csi imx-ipuv3-csi.0: FI=33333 usec
[  165.129424] ipu1_csi0: EOF timeout
[  165.142395] imx-ipuv3-csi imx-ipuv3-csi.0: stream OFF
[  166.169299] ipu1_csi0: wait last EOF timeout

Sounds like a recurrent issue on this ML :).
I can think of several things which could explain this, but I tried a
lot and am a bit stuck.
The clock is set to 800MHz on DS90UB954 side.
=> Should CSI2_PHY_TST_CTRL1 be 0x32 ? 0x12 ? or 0x4a (ie 400MHz) ?
I think I have tried all but still the same issue.

Maybe this could be a hint, when booting, the first stream-on leads to:
 imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 => just a warning now
 imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000230
The next one leads to the EOF timeout.

Here is the dts part BTW :
&i2c3 {
    status = "okay";

    ds90ub954: camera@34 {
        compatible = "ti,ds90ub954";
        status = "okay";
        reg = <0x34>;
        clocks = <&clks IMX6QDL_CLK_CKO>;
        clock-names = "xclk";
        port {
            #address-cells = <1>;
            #size-cells = <0>;

            ds90ub954_out0: endpoint {
                remote-endpoint = <&mipi_csi2_in>;
                clock-lanes = <0>;
                data-lanes = <1 2>;
            };
        };
    };
};

&mipi_csi {
    status = "okay";

    port@0 {
        reg = <0>;

        mipi_csi2_in: endpoint {
            remote-endpoint = <&ds90ub954_out0>;
            clock-lanes = <0>;
            data-lanes = <1 2>;
        };
    };
};


If ayone has a suggestion...
Thanks a lot !

Regards,
JM

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

[Steve Longerbeam]

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.

Hope that helps,
Steve


On 10/30/18 9:41 AM, Jean-Michel Hautbois wrote:
> Hi there,
>
> I am using the i.MX6D from Digi (connect core 6 sbc) with a mailine
> kernel (well, 4.14 right now) and have an issue with mipi-csi2
> capture.
> First I will give brief explanation of my setup, and then I will
> detail the issue.
> I have a camera sensor (OV2732, but could be any other sensor)
> connected on a DS90UB953 FPD-Link III serializer.
> Then a coax cable propagates the signal to a DS90UB954 FPD-Link III
> deserializer.
>
> The DS90UB954 has the ability to work in a pattern generation mode,
> and I will use it for the rest of the discussion.
> It is an I²C device, and I have written a basic driver (for the moment
> ;)) in order to make it visible on the imx6-mipi-csi2 bus as a camera
> sensor.
> I can give an access to the driver if necessary.
>
> I then program the MC pipeline :
> media-ctl -l "'ds90ub954 2-0034':0 -> 'imx6-mipi-csi2':0[1]" -v
> media-ctl -l "'imx6-mipi-csi2':1 -> 'ipu1_csi0_mux':0[1]" -v
> media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" -v
> media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
> media-ctl -V "'ds90ub954 2-0034':0 [fmt:RGB888_1X24/1280x720 field:none]"
> media-ctl -V "'imx6-mipi-csi2':1 [fmt:RGB888_1X24/1280x720 field:none]"
> media-ctl -V "'ipu1_csi0_mux':2 [fmt:RGB888_1X24/1280x720 field:none]"
> media-ctl -V "'ipu1_csi0':2 [fmt:RGB888_1X24/1280x720 field:none]"
>
> Everything works fine, all nodes are correctly configured, and the
> DS90UB954 is normaly sending data on 2 lanes, with VC-ID=0.
> The pattern is 1280x720@30 RGB888.
>
> Then, I start a Gstreamer pipeline (I tried with v4l2-ctl and have the
> same issue though) :
> GST_DEBUG="v4l2:5" gst-launch-1.0 v4l2src device=/dev/video4 !
> video/x-raw, width=1280, height=720, format=RGB ! fakesink
>
> And... well, I had to use this patch
> https://lkml.org/lkml/2017/3/11/270 in order to go further, but I am
> finishing into :
> [  164.077302] imx-ipuv3-csi imx-ipuv3-csi.0: stream ON
> [  164.097955] imx-ipuv3-csi imx-ipuv3-csi.0: FI=33333 usec
> [  165.129424] ipu1_csi0: EOF timeout
> [  165.142395] imx-ipuv3-csi imx-ipuv3-csi.0: stream OFF
> [  166.169299] ipu1_csi0: wait last EOF timeout
>
> Sounds like a recurrent issue on this ML :).
> I can think of several things which could explain this, but I tried a
> lot and am a bit stuck.
> The clock is set to 800MHz on DS90UB954 side.
> => Should CSI2_PHY_TST_CTRL1 be 0x32 ? 0x12 ? or 0x4a (ie 400MHz) ?
> I think I have tried all but still the same issue.
>
> Maybe this could be a hint, when booting, the first stream-on leads to:
>   imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 => just a warning now
>   imx6-mipi-csi2: clock lane timeout, phy_state = 0x00000230
> The next one leads to the EOF timeout.
>
> Here is the dts part BTW :
> &i2c3 {
>      status = "okay";
>
>      ds90ub954: camera@34 {
>          compatible = "ti,ds90ub954";
>          status = "okay";
>          reg = <0x34>;
>          clocks = <&clks IMX6QDL_CLK_CKO>;
>          clock-names = "xclk";
>          port {
>              #address-cells = <1>;
>              #size-cells = <0>;
>
>              ds90ub954_out0: endpoint {
>                  remote-endpoint = <&mipi_csi2_in>;
>                  clock-lanes = <0>;
>                  data-lanes = <1 2>;
>              };
>          };
>      };
> };
>
> &mipi_csi {
>      status = "okay";
>
>      port@0 {
>          reg = <0>;
>
>          mipi_csi2_in: endpoint {
>              remote-endpoint = <&ds90ub954_out0>;
>              clock-lanes = <0>;
>              data-lanes = <1 2>;
>          };
>      };
> };
>
>
> If ayone has a suggestion...
> Thanks a lot !
>
> Regards,
> JM

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

[Vladimir Zapolskiy]

Hi Jean-Michel,

On 10/30/2018 06:41 PM, Jean-Michel Hautbois wrote:
> Hi there,
> 
> I am using the i.MX6D from Digi (connect core 6 sbc) with a mailine
> kernel (well, 4.14 right now) and have an issue with mipi-csi2
> capture.
> First I will give brief explanation of my setup, and then I will
> detail the issue.
> I have a camera sensor (OV2732, but could be any other sensor)
> connected on a DS90UB953 FPD-Link III serializer.
> Then a coax cable propagates the signal to a DS90UB954 FPD-Link III
> deserializer.
> 
> The DS90UB954 has the ability to work in a pattern generation mode,
> and I will use it for the rest of the discussion.
> It is an I²C device, and I have written a basic driver (for the moment
> ;)) in order to make it visible on the imx6-mipi-csi2 bus as a camera
> sensor.
> I can give an access to the driver if necessary.

It's sort of indirectly related, anyway, I utterly hope that the
generic IC drivers will be ready and accepted for v4.21, see 
https://lwn.net/ml/devicetree/20181008211205.2900-1-vz@mleia.com/

Adding more ICs and cell devices to the framework is appreciated, 
in the queue there are DS90UB913, DS90Ux929, DS90Ux947, DS90UB964.

Steve, in case if you're unaware, that's FYI also.

--
Best wishes,
Vladimir

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

[Jean-Michel Hautbois]

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

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

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

[jacopo mondi]

[-- 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 --]