Re: i.MX6: can't capture on MIPI-CSI2 with DS90UB954
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 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 = 0x0200
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
signature.asc
Description: PGP signature
Re: i.MX6: can't capture on MIPI-CSI2 with DS90UB954
Hi Steve, Le mer. 31 oct. 2018 à 22:52, Steve Longerbeam 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
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...@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
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=3 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 = 0x0200 => just a warning now
imx6-mipi-csi2: clock lane timeout, phy_state = 0x0230
The next one leads to the EOF timeout.
Here is the dts part BTW :
{
status = "okay";
ds90ub954: camera@34 {
compatible = "ti,ds90ub954";
status = "okay";
reg = <0x34>;
clocks = < IMX6QDL_CLK_CKO>;
clock-names = "xclk";
port {
#address-cells = <1>;
#size-cells = <0>;
ds90ub954_out0: endpoint {
remote-endpoint = <_csi2_in>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
};
};
_csi {
status = "okay";
port@0 {
reg = <0>;
mipi_csi2_in: endpoint {
remote-endpoint = <_out0>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
};
If ayone has a suggestion...
Thanks a lot !
Regards,
JM
i.MX6: can't capture on MIPI-CSI2 with DS90UB954
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=3 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 = 0x0200 => just a warning now
imx6-mipi-csi2: clock lane timeout, phy_state = 0x0230
The next one leads to the EOF timeout.
Here is the dts part BTW :
{
status = "okay";
ds90ub954: camera@34 {
compatible = "ti,ds90ub954";
status = "okay";
reg = <0x34>;
clocks = < IMX6QDL_CLK_CKO>;
clock-names = "xclk";
port {
#address-cells = <1>;
#size-cells = <0>;
ds90ub954_out0: endpoint {
remote-endpoint = <_csi2_in>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
};
};
_csi {
status = "okay";
port@0 {
reg = <0>;
mipi_csi2_in: endpoint {
remote-endpoint = <_out0>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
};
If ayone has a suggestion...
Thanks a lot !
Regards,
JM
