> On Tue, Feb 18, 2020 at 12:44:11PM +0100, Michael Rodin wrote:
> > The chapter 7.1 "D-PHY Physical Layer Option" of the CSI2
> > specification states that non-continuous clock behavior is optional,
> > i.e. the Clock Lane can remain in high-speed mode between the transmission
> of data packets.
> > Therefore waiting for the stop state (LP-11) on the Clock Lane is
> > wrong and will cause timeouts when a CSI2 transmitter with continuous
> > clock behavior is attached to R-Car CSI2 receiver. So wait only for
> > the stop state on the Data Lanes.
>
> Am I wrong or the desired behaviour should depend on the presence of the
> clock-noncontinuous property in the CSI-2 input endpoint ?
> If clock-noncontinuous is set, then wait for the clock lane to enter stop state
> too, if not just wait for the data lanes to stop.
>
> If this is correct, it will also require a change to the bindings and that's the
> tricky part. So far the CSI-2 receiver behaved as the clock-noncontinuous
> property was set (wait for both data and clock
> lanes) and older dtb should continue to work under this assumption. If you
> want to support devices with continuous clock then you have to require the
> clock-noncontinuous property to be explicitly set to false, and assume it's true
> if not specified. BUT clock-noncontinuous is a boolean property, whose value
> depends on it's presence only. So I fear we need to add a 'clock-continuous'
> flag to video-interfaces.txt, parse it in the CSI-2 receiver driver, and then ignore
> the clock lane stop state if and only if said property is specified.
>
> Does this make sense ?
>
Hello Jacopo,
- First of all I am not so sure whether I am interpreting the CSI2 spec correctly,
this is also the reason why I marked my patch as [RFC]. So MAYBE waiting for LP-11
on the clock lane IS correct at this point in rcar-csi2 and the issue is somewhere else
and your suggestion was based on my wrong assumption. Is it possible?
- The presence of the "clock-noncontinuous" property is parsed by the V4L2 fwnode library,
which sets either V4L2_MBUS_CSI2_CONTINUOUS_CLOCK or V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK.
I could not find any upstream CSI2 receiver driver, which reads these flags. Would be rcar-csi2
the first driver which reads this property (of a transmitter) at the receiver side?
- Sorry, but I don't understand your concerns about compatibility to old device trees.
If "clock-noncontinuous" exists at the CSI2 transmitter side, it is assumed to be
true (since as you mentioned, all boolean properties are true if present) and we
would wait for LP-11 on clock lane in rcar-csi2 and older dtbs would continue to
work correctly. If this property is not present in a CSI2 transmitter node of an older
dtb although this transmitter has this property, then this is a wrong device tree
configuration. So the suggested new "clock-continuous" property would be a workaround
for supporting incorrect device trees. Should we maintain backwards compatibility in this case?
- Even if we should maintain backwards compatibility to incorrectly configured device trees
(i.e. "clock-noncontinuous" is not specified for CSI2 transmitters with non-continuous clock behavior),
it is possibly not an issue in this particular case because we don't have to wait for
LP-11 on clock lanes at all since the non-continuous clock behavior is optional according
to the chapter 7.1 of the CSI2 specification. So from my understanding a CSI2 receiver
which supports only continuous clock behavior would work with both kinds of clock
behavior at the transmitter side. On the other side a CSI2 receiver which supports only
non-continuous clock behavior (which is currently the behavior implemented in rcar-csi2.c)
can not receive anything from a transmitter with continuous clock behavior and would violate CSI2 spec.
>
> >
> > Signed-off-by: Michael Rodin <mrodin@xxxxxxxxxxxxxx>
> > ---
> > drivers/media/platform/rcar-vin/rcar-csi2.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
> > b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > index faa9fb2..6d1992a 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > @@ -416,8 +416,7 @@ static int rcsi2_wait_phy_start(struct rcar_csi2 *priv)
> > for (timeout = 0; timeout <= 20; timeout++) {
> > const u32 lane_mask = (1 << priv->lanes) - 1;
> >
> > - if ((rcsi2_read(priv, PHCLM_REG) & PHCLM_STOPSTATECKL)
> &&
> > - (rcsi2_read(priv, PHDLM_REG) & lane_mask) == lane_mask)
> > + if ((rcsi2_read(priv, PHDLM_REG) & lane_mask) == lane_mask)
> > return 0;
> >
> > usleep_range(1000, 2000);
> > --
> > 2.7.4
> >
