Message-ID: <AC35D0CFBC66A84AAA9DF4334B52828D136F94C7@HI2EXCH01.adit-jv.com>
Date:   Mon, 24 Feb 2020 14:13:08 +0000
From:   "Rodin, Michael (Ferchau; ADITG/ESM1)" <mrodin@...adit-jv.com>
To:     "jacopo@...ndi.org" <jacopo@...ndi.org>
CC:     "niklas.soderlund@...natech.se" <niklas.soderlund@...natech.se>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Friedrich, Eugen (ADITG/ESM1)" <efriedrich@...adit-jv.com>,
        "Rosca, Eugeniu (ADITG/ESM1)" <erosca@...adit-jv.com>,
        "Udipi, Suresh (Wipro; LEADER ; ADITJ/SWG)" 
        <external.sudipi@...adit-jv.com>,
        "akiyama@...-osk.co.jp" <akiyama@...-osk.co.jp>
Subject: RE: [PATCH] [RFC] media: rcar-vin: don't wait for stop state on
 clock lane during start of CSI2

> 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@...adit-jv.com>
> > ---
> >  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
> >

Powered by blists - more mailing lists