From: Chris Paterson <Chris.Paterson2@renesas.com>
To: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
Hans Verkuil <hverkuil@xs4all.nl>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Antti Palosaari <crope@iki.fi>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: RE: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding
Date: Thu, 19 Jan 2017 17:46:32 +0000 [thread overview]
Message-ID: <HK2PR0601MB132923F9E0A7C7CB21567757B77E0@HK2PR0601MB1329.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <HK2PR06MB0545BF36C3DD2D4D1B951C3FC3670@HK2PR06MB0545.apcprd06.prod.outlook.com>
Hello Hans,
Do you have any further feedback on this?
Thanks, Chris
> From: Ramesh Shanmugasundaram
> Sent: 10 January 2017 09:31
> Hi Laurent,
>
> > > >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram
> wrote:
> > > >>>> Add binding documentation for Renesas R-Car Digital Radio
> > > >>>> Interface
> > > >>>> (DRIF) controller.
> > > >>>>
> > > >>>> Signed-off-by: Ramesh Shanmugasundaram
> > > >>>> <ramesh.shanmugasundaram@bp.renesas.com> ---
> > > >>>>
> > > >>>> .../devicetree/bindings/media/renesas,drif.txt | 202
> > +++++++++++++
> > > >>>> 1 file changed, 202 insertions(+) create mode 100644
> > > >>>>
> > > >>>> Documentation/devicetree/bindings/media/renesas,drif.txt
> > > >>>>
> > > >>>> diff --git
> > > >>>> a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > > >>>> b/Documentation/devicetree/bindings/media/renesas,drif.txt new
> > > >>>> file mode 100644 index 0000000..1f3feaf
> > > >>>> --- /dev/null
> > > >>>> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > > >>>>
> > > >>>> +Optional properties of an internal channel when:
> > > >>>> + - It is the only enabled channel of the bond (or)
> > > >>>> + - If it acts as primary among enabled bonds
> > > >>>> +--------------------------------------------------------
> > > >>>> +- renesas,syncmd : sync mode
> > > >>>> + 0 (Frame start sync pulse mode. 1-bit
> > > >>>> +width
> > > >>>> pulse
> > > >>>> + indicates start of a frame)
> > > >>>> + 1 (L/R sync or I2S mode) (default)
> > > >>>> +- renesas,lsb-first : empty property indicates lsb bit is
> > received
> > > >>>> first.
> > > >>>> + When not defined msb bit is received
> > > >>>> +first
> > > >>>> +(default)
> > > >>>> +- renesas,syncac-active: Indicates sync signal polarity, 0/1
> > > >>>> +for
> > > >>>> low/high
> > >
> > > Shouldn't this be 'renesas,sync-active' instead of syncac-active?
> > >
> > > I'm not sure if syncac is intended or if it is a typo.
> > >
> > > >>>> + respectively. The default is 1 (active high)
> > > >>>> +- renesas,dtdl : delay between sync signal and start of
> > > >>>> reception.
> > > >>>> + The possible values are represented in
> > > >>>> + 0.5
> > clock
> > > >>>> + cycle units and the range is 0 to 4. The
> > default
> > > >>>> + value is 2 (i.e.) 1 clock cycle delay.
> > > >>>> +- renesas,syncdl : delay between end of reception and sync
> > > >>>> signal edge.
> > > >>>> + The possible values are represented in
> > > >>>> + 0.5
> > clock
> > > >>>> + cycle units and the range is 0 to 4 & 6.
> > > >>>> + The
> > > >>>> default
> > > >>>> + value is 0 (i.e.) no delay.
> > > >>>
> > > >>> Most of these properties are pretty similar to the video bus
> > > >>> properties defined at the endpoint level in
> > > >>> Documentation/devicetree/bindings/media/video-interfaces.txt. I
> > > >>> believe it would make sense to use OF graph and try to
> > > >>> standardize these properties similarly.
> > >
> > > Other than sync-active, is there really anything else that is similar?
> > > And even the sync-active isn't a good fit since here there is only
> > > one sync signal instead of two for video (h and vsync).
> >
> > That's why I said similar, not identical :-) My point is that, if we
> > consider that we could connect multiple sources to the DRIF, using OF
> > graph would make sense, and the above properties should then be
> > defined per endpoint.
>
> Thanks for the clarifications. I have some questions.
>
> - Assuming two devices are interfaced with DRIF and they are represented
> using two endpoints, the control signal related properties of DRIF might still
> need to be same for both endpoints? For e.g. syncac-active cannot be
> different in both endpoints?
>
> - I suppose "lsb-first", "dtdl" & "syncdl" may be defined per endpoint.
> However, h/w manual says same register values needs to be programmed
> for both the internal channels of a channel. Same with "syncmd" property.
>
> We could still define them as per endpoint property with a note that they
> need to be same. But I am not sure if that is what you intended?
>
> If we define them per endpoint we should then also try
> > standardize the ones that are not really Renesas-specific (that's at
> > least syncac-active).
>
> OK. I will call it "sync-active".
>
> For the syncmd and lsb-first properties, it could also
> > make sense to query them from the connected subdev at runtime, as
> > they're similar in purpose to formats and media bus configuration
> > (struct v4l2_mbus_config).
>
> May I know in bit more detail about what you had in mind? Please correct me
> if my understanding is wrong here but when I looked at the code
>
> 1) mbus_config is part of subdev_video_ops only. I assume we don't want to
> support this as part of tuner subdev. The next closest is pad_ops with "struct
> v4l2_mbus_framefmt" but it is fully video specific config unless I come up
> with new MEDIA_BUS_FMT_xxxx in media-bus-format.h and use the code
> field? For e.g.
>
> #define MEDIA_BUS_FMT_SDR_I2S_PADHI_BE 0x7001
> #define MEDIA_BUS_FMT_SDR_I2S_PADHI_LE 0x7002
>
> 2) The framework does not seem to mandate pad ops for all subdev. As the
> tuner can be any third party subdev, is it fair to assume that these properties
> can be queried from subdev?
>
> 3) Assuming pad ops is not available on the subdev shouldn't we still need a
> way to define these properties on DRIF DT?
>
> >
> > I'm not an SDR expert, so I'd like to have your opinion on this.
> >
> > > >> Note that the last two properties match the those in
> > > >> Documentation/devicetree/bindings/spi/sh-msiof.txt.
> > > >> We may want to use one DRIF channel as a plain SPI slave with the
> > > >> (modified) MSIOF driver in the future.
> > > >
> > > > Should I leave it as it is or modify these as in video-interfaces.txt?
> > > > Shall we conclude on this please?
> >
>
> Thanks,
> Ramesh
next prev parent reply other threads:[~2017-01-19 17:47 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 15:44 [PATCH 0/5] Add V4L2 SDR (DRIF & MAX2175) driver Ramesh Shanmugasundaram
2016-11-09 15:44 ` [PATCH 1/5] media: v4l2-ctrls: Reserve controls for MAX217X Ramesh Shanmugasundaram
2016-11-09 15:44 ` [PATCH 2/5] media: i2c: max2175: Add MAX2175 support Ramesh Shanmugasundaram
2016-11-11 7:16 ` Antti Palosaari
2016-11-11 11:50 ` Laurent Pinchart
2016-11-11 13:21 ` Hans Verkuil
2016-11-11 13:48 ` Laurent Pinchart
2016-11-11 13:58 ` Hans Verkuil
2016-11-14 15:54 ` Ramesh Shanmugasundaram
2016-11-14 19:41 ` Rob Herring
2016-11-17 12:41 ` Ramesh Shanmugasundaram
2016-11-09 15:44 ` [PATCH 3/5] media: Add new SDR formats SC16, SC18 & SC20 Ramesh Shanmugasundaram
2016-11-11 13:24 ` Hans Verkuil
2016-11-11 13:48 ` Laurent Pinchart
2016-11-11 13:49 ` Laurent Pinchart
2016-11-14 16:20 ` Ramesh Shanmugasundaram
2016-11-14 16:52 ` Hans Verkuil
2016-11-09 15:44 ` [PATCH 4/5] doc_rst: media: New " Ramesh Shanmugasundaram
2016-11-10 8:18 ` Laurent Pinchart
2016-11-09 15:44 ` [PATCH 5/5] media: platform: rcar_drif: Add DRIF support Ramesh Shanmugasundaram
2016-11-10 9:22 ` Laurent Pinchart
2016-11-14 19:52 ` Rob Herring
2016-11-14 20:04 ` Geert Uytterhoeven
2016-11-15 15:09 ` Ramesh Shanmugasundaram
2016-11-11 13:38 ` Hans Verkuil
2016-11-14 16:11 ` Ramesh Shanmugasundaram
2016-12-21 8:10 ` [PATCH v2 0/7] Add V4L2 SDR (DRIF & MAX2175) driver Ramesh Shanmugasundaram
2016-12-21 8:10 ` [PATCH v2 1/7] media: v4l2-ctrls: Reserve controls for MAX217X Ramesh Shanmugasundaram
2016-12-21 8:10 ` [PATCH v2 2/7] dt-bindings: media: Add MAX2175 binding description Ramesh Shanmugasundaram
2016-12-21 8:10 ` [PATCH v2 3/7] media: i2c: max2175: Add MAX2175 support Ramesh Shanmugasundaram
2016-12-21 8:10 ` [PATCH v2 4/7] media: Add new SDR formats PC16, PC18 & PC20 Ramesh Shanmugasundaram
2016-12-21 8:10 ` [PATCH v2 5/7] doc_rst: media: New " Ramesh Shanmugasundaram
2016-12-21 8:10 ` [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding Ramesh Shanmugasundaram
2016-12-22 17:05 ` Laurent Pinchart
2016-12-22 19:05 ` Geert Uytterhoeven
2017-01-03 15:20 ` Ramesh Shanmugasundaram
2017-01-09 13:36 ` Hans Verkuil
2017-01-09 14:42 ` Ramesh Shanmugasundaram
2017-01-09 23:09 ` Laurent Pinchart
2017-01-10 9:31 ` Ramesh Shanmugasundaram
2017-01-19 17:46 ` Chris Paterson [this message]
2017-01-27 11:20 ` Hans Verkuil
2017-01-27 13:51 ` Ramesh Shanmugasundaram
2016-12-21 8:10 ` [PATCH v2 7/7] media: platform: rcar_drif: Add DRIF support Ramesh Shanmugasundaram
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=HK2PR0601MB132923F9E0A7C7CB21567757B77E0@HK2PR0601MB1329.apcprd06.prod.outlook.com \
--to=chris.paterson2@renesas.com \
--cc=crope@iki.fi \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=geert@linux-m68k.org \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mchehab@kernel.org \
--cc=ramesh.shanmugasundaram@bp.renesas.com \
--cc=robh+dt@kernel.org \
--cc=sakari.ailus@linux.intel.com \
/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).