[PATCH v4 4/6] media: synopsys: Add PHY stopstate wait for i.MX93

[Alexander Stein]

Hi,

Am Freitag, 22. Mai 2026, 03:58:56 CEST schrieb G.N. Zhou (OSS):
> > > Thanks for testing. Regarding the lane stop state error on i.MX93 with
> > imx327:
> > >
> > > This error indicates the CSI-2 lanes are not in LP-11 (stop) state
> > > when expected. Please check:
> > >
> > > 1) Verify the sensor PHY is in LP-11 state before returning from the sensor's
> > >    s_stream(1) call. The CSI-2 receiver expects lanes to be in stop state
> > >    initially.
> > 
> > Well, this might be tricky as I don't have D-PHY capable scopes.
> > I can successfully use this sensor on a imx8mp, so I am expecting this to be
> > okay.
> > 
> > > 2) Check if the imx327 driver has a delay between starting the stream and
> > >    returning from s_stream(). If the sensor transitions PHY out of LP-11
> > >    state during this delay, the CSI driver's lane state check will fail
> > >    when it runs later. The sensor should remain in LP-11 until the CSI
> > >    controller completes its initialization.
> > 
> > In imx290_set_stream() and subsequently imx290_start_streaming() setting
> > IMX290_XMSTA starts the stream. I expect this is the point when the sensors
> > switches from LP-11 to HS. But again, I can't verify.
> 
> As mentioned in #2, I reviewed drivers/media/i2c/imx290.c and identified a 30ms
> delay that appears to be the root cause of this issue.
> 
> The problem occurs because:
> 
> The sensor exits LP-11 state and transitions to HS mode after IMX290_XMSTA is written
> The 30ms delay in s_stream() causes the function to return late
> By the time the CSI controller performs its lane state check, the sensor has already switched
> from LP-11 to HS mode, causing the check to fail。

This sounds wrong, see below.

> 
> Proposed fix:
> 
> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> index 21cbc81cb2ed..519aa336249a 100644
> --- a/drivers/media/i2c/imx290.c
> +++ b/drivers/media/i2c/imx290.c
> @@ -1059,7 +1059,6 @@ static int imx290_start_streaming(struct imx290 *imx290,
>  
>         cci_write(imx290->regmap, IMX290_STANDBY, 0x00, &ret);
>  
> -       msleep(30);
>  
>         /* Start streaming */
>         return cci_write(imx290->regmap, IMX290_XMSTA, 0x00, &ret);
> 
> Removing this delay allows s_stream() to return immediately, giving the CSI controller
> time to complete its initialization before the sensor transitions PHY state.
> 
> Could you test this patch and confirm if it resolves the lane state check failure?

Removing these 30ms does not fix the problem. Actually the delay change is
hardly measurable, as the i2c transfer take much more time. I added a message
for start/exit of imx290_enable_streams(). Just the transfers take >600ms.

--8<--
[   40.507273] plane 0: bytesperline=3840 sizeimage=4147200
[   40.512628] mxc-isi 4ae40000.isi: validating link "crossbar":2 -> "mxc_isi.0":0
[   40.519945] mxc-isi 4ae40000.isi: validating stream "crossbar":2:0 -> "mxc_isi.0":0:0
[   40.527789] mxc-isi 4ae40000.isi: validating link "dw-mipi-csi2rx 4ae00000.mipi-csi":1 -> "crossbar":0
[   40.537105] mxc-isi 4ae40000.isi: validating stream "dw-mipi-csi2rx 4ae00000.mipi-csi":1:0 -> "crossbar":0:0
[   40.546940] mxc-isi 4ae40000.isi: validating link "imx327 4-001a":0 -> "dw-mipi-csi2rx 4ae00000.mipi-csi":0
[   40.556680] mxc-isi 4ae40000.isi: validating stream "imx327 4-001a":0:0 -> "dw-mipi-csi2rx 4ae00000.mipi-csi":0:0
[   40.573332] mxc-isi 4ae40000.isi: enable streams "crossbar":2/0x1
[   40.579446] mxc-isi 4ae40000.isi: collect_streams: "crossbar":2: found 0x1 enabled 0x0
[   40.587373] imx290 4-001a: Frame descriptor on pad 0, type CSI-2
[   40.593390] imx290 4-001a:   stream 0, code 0x300f, length 0, flags 0x0000, vc 0, dt 0x2b
[   40.601489] dw-mipi-csi2rx 4ae00000.mipi-csi: Frame descriptor on pad 1, type CSI-2
[   40.609147] dw-mipi-csi2rx 4ae00000.mipi-csi:        stream 0, code 0x300f, length 0, flags 0x0000, vc 0, dt 0x2b
[   40.618894] mxc-isi 4ae40000.isi: enable streams "dw-mipi-csi2rx 4ae00000.mipi-csi":1/0x1
[   40.627082] dw-mipi-csi2rx 4ae00000.mipi-csi: collect_streams: "dw-mipi-csi2rx 4ae00000.mipi-csi":1: found 0x1 enabled 0x0
[   40.638184] mxc-isi 4ae40000.isi: enable streams "imx327 4-001a":0/0x1
[   40.644728] imx290 4-001a: collect_streams: sub-device "imx327 4-001a" does not support streams
[   40.653431] imx290 4-001a: imx290_enable_streams start
[   41.294967] imx290 4-001a: imx290_enable_streams exit
[   41.301064] dw-mipi-csi2rx 4ae00000.mipi-csi: lanes are not in stop state: 0x0, expected 0x10003
[   41.309884] mxc-isi 4ae40000.isi: disable streams "imx327 4-001a":0/0x1
[   41.316534] imx290 4-001a: collect_streams: sub-device "imx327 4-001a" does not support streams
[   41.361401] mxc-isi 4ae40000.isi: enable streams 1:0x1 failed: -110
[   41.367690] mxc-isi 4ae40000.isi: failed to enable streams 0x1 on 'dw-mipi-csi2rx 4ae00000.mipi-csi':1: -110
[   41.379854] mxc-isi 4ae40000.isi: enable streams 2:0x1 failed: -110
[   41.387325] mxc-isi 4ae40000.isi: Failed to enable pipe 0
[   41.399231] video0: VIDIOC_STREAMON: error -110: type=vid-cap-mplane
[   41.408340] videodev: v4l2_release: video0: release
--8<--

Given this I would ague the CSI host initialization order is wrong. The
documentation for enable_streams states:
> The struct v4l2_subdev_pad_ops->enable_streams() and struct
> v4l2_subdev_pad_ops->disable_streams() callbacks are used by the receiver driver
> to control the transmitter driver's streaming state.

So IMHO calling enable_streams it is expected the sensors switched to
HS mode. Unfortunately even checking PHY stopstate before enabling the subdev
streams does not fix this error message.
There is still 
> dw-mipi-csi2rx 4ae00000.mipi-csi: lanes are not in stop state: 0x0, expected 0x10003

I also noticed that before the s_stream call (imx290_set_stream) call the
device is powered down. That might explaing that reversing the order will
not help.

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/