From: "Rodin, Michael (Ferchau; ADITG/ESM1)" <mrodin@de.adit-jv.com>
To: "jacopo@jmondi.org" <jacopo@jmondi.org>
Cc: "niklas.soderlund@ragnatech.se" <niklas.soderlund@ragnatech.se>,
"mchehab@kernel.org" <mchehab@kernel.org>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Friedrich, Eugen (ADITG/ESM1)" <efriedrich@de.adit-jv.com>,
"Rosca, Eugeniu (ADITG/ESM1)" <erosca@de.adit-jv.com>,
"Udipi,
Suresh (Wipro; LEADER ; ADITJ/SWG)"
<external.sudipi@jp.adit-jv.com>,
"akiyama@nds-osk.co.jp" <akiyama@nds-osk.co.jp>
Subject: RE: [PATCH] [RFC] media: rcar-vin: don't wait for stop state on clock lane during start of CSI2
Date: Mon, 24 Feb 2020 14:13:08 +0000 [thread overview]
Message-ID: <AC35D0CFBC66A84AAA9DF4334B52828D136F94C7@HI2EXCH01.adit-jv.com> (raw)
In-Reply-To: <20200219172456.hyo2aksvubxpoqrn@uno.localdomain>
> 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@de.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
> >
next prev parent reply other threads:[~2020-02-24 14:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 11:44 [PATCH] [RFC] media: rcar-vin: don't wait for stop state on clock lane during start of CSI2 Michael Rodin
2020-02-19 17:24 ` Jacopo Mondi
2020-02-24 14:13 ` Rodin, Michael (Ferchau; ADITG/ESM1) [this message]
2020-02-26 16:40 ` Jacopo Mondi
2020-03-04 20:02 ` niklas.soderlund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AC35D0CFBC66A84AAA9DF4334B52828D136F94C7@HI2EXCH01.adit-jv.com \
--to=mrodin@de.adit-jv.com \
--cc=akiyama@nds-osk.co.jp \
--cc=efriedrich@de.adit-jv.com \
--cc=erosca@de.adit-jv.com \
--cc=external.sudipi@jp.adit-jv.com \
--cc=jacopo@jmondi.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=niklas.soderlund@ragnatech.se \
--cc=p.zabel@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).