Re: LP-11 Timeout on RZ/G2 with ov5640

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Adam,

(CC'ing Sakari)

On Wed, Nov 24, 2021 at 03:16:57PM -0600, Adam Ford wrote:
> I am trying to use an OV5640 camera sensor that I've used on both an
> i.MX6Q and an i.MX8M Mini (with good success) on an RZ/G2[MNH] board
> connected to the 2-lane CSI interface.
> 
> I can get the media-ctl to show the routings, and sometimes I can get
> streaming.  Often, I get a timeout:
> 
>      rcar-csi2 fea80000.csi2: Timeout waiting for LP-11 state
> 
> Looking at the various mailing list e-mails for the LP-11, it's
> unclear to me if the timeout is caused by the sensor not doing
> something correctly or the CSI2 misbehaving.

Before transitioning to the high speed (HS) mode, the D-PHY transmitter
must drive the lane in the LP-11 state. This is the idle state of the
lane when powered up and when not in the ultra low-power state (ULPS).
The transition to HS mode on the receiver side involves observing the
LP-11 state. Many D-PHY RX require configuring the PHY when the lane is
in LP-11 state, and only then starting the sensor to transition to HS.
This requires powering up the D-PHY TX and going to idle mode, which
most sensors support. As we're deprecating the .s_power() subdev
operation, however, we have no way to power up the sensor without
starting it before the D-PHY RX gets configured.

In some cases, the D-PHY RX can handle the power up sequence
automatically. They can be fully configured (from a software point of
view) while the lane is in the power down state LP-00, and they then
handle the transition to the stop state LP-11 and to the HS mode
automatically. This isn't true for all receivers, some need software
configuration after the data lane reaches the LP-11 state and before it
transitions to HS mode. According to the documentation, the R-Car CSI-2
receiver requires software intervention between LP-11 and HS mode at
least on V3M and E3. There's also a software configuration step on H3,
M3N, V3H and V3U, but there's a chance that one could possibly be
bypassed.

> I was hoping someone might have some suggestions of things I can try.

I would first try to power up the sensor at probe time and keep it power
forever, to see if it solves your issue. If it does, then introducing a
CSI-2-specific subdev operation to power up the sensor (or officially
de-deprecating .s_power() for this use case) could be an option to fix
the issue properly.

-- 
Regards,

Laurent Pinchart



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux