linux-mediatek.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	"Nicolas Boichat" <drinkcat@chromium.org>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	srv_heupstream <srv_heupstream@mediatek.com>,
	linux-devicetree <devicetree@vger.kernel.org>,
	"Shengnan Wang (王圣男)" <shengnan.wang@mediatek.com>,
	"Louis Kuo" <louis.kuo@mediatek.com>,
	"Sj Huang" <sj.huang@mediatek.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	"Dongchun Zhu" <dongchun.zhu@mediatek.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Cao Bing Bu" <bingbu.cao@intel.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>,
	" <linux-arm-kernel@lists.infradead.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>
Subject: Re: [PATCH v15 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
Date: Mon, 19 Oct 2020 11:27:59 +0300	[thread overview]
Message-ID: <20201019082759.GL13341@paasikivi.fi.intel.com> (raw)
In-Reply-To: <CAAFQd5BVzN=49s4S98E9mGNuxzOt4633dAw9mbyu3Sr-rA61qw@mail.gmail.com>

On Wed, Oct 14, 2020 at 01:48:00PM +0200, Tomasz Figa wrote:
> On Wed, Oct 14, 2020 at 10:31 AM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > On Wed, Oct 14, 2020 at 10:10:18AM +0800, Dongchun Zhu wrote:
> > > Hello Sakari,
> > >
> > > Thanks for your timely review.
> > >
> > > On Tue, 2020-10-13 at 19:19 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Tue, Oct 13, 2020 at 09:05:02PM +0800, Dongchun Zhu wrote:
> > > > > Add YAML device tree binding for OV02A10 CMOS image sensor, and the
> > > > > relevant MAINTAINERS entries.
> > > > >
> > > > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > > > ---
> > > > >  .../bindings/media/i2c/ovti,ov02a10.yaml           | 162 +++++++++++++++++++++
> > > > >  MAINTAINERS                                        |   7 +
> > > > >  2 files changed, 169 insertions(+)
> > > > >  create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > > >
> > >
> > > [snip]...
> > >
> > > > > +  ovti,mipi-clock-voltage:
> > > > > +    description:
> > > > > +      An array of 2-tuples items, and each item consists of link frequency and
> > > > > +      MIPI clock voltage unit like <freq-kHz volt-unit>. Clock voltage unit is
> > > > > +      dependent upon link speed, indicating MIPI transmission speed select that
> > > > > +      controls D-PHY timing setting by adjusting MIPI clock voltage to improve
> > > > > +      the clock driver capability.
> > > > > +    $ref: "/schemas/types.yaml#/definitions/uint32-array"
> > > > > +    minItems: 2
> > > > > +    default: [390000, 4]
> > > >
> > > > Why do you have the link frequency here as well?
> > > >
> > > > In principle this does belong to the endpoint as link frequencies are
> > > > specific to that, but I don't mind; there's just a single port anyway.
> > > >
> > >
> > > This is an optional property which we model as an array of <link speed,
> > > clock voltage> pairs. An example to have all link speeds up to 390MHz
> > > use the value 4 for current driver. If one wants to select different
> > > voltage for different link, they could do so as well.
> >
> > If you think you'd need that, then you need to put this to the endpoint.
> 
> The mipi-clock-voltage property is not a property of the endpoint. The
> link frequency there does not set the link frequency - it only
> specifies which link frequency the given voltage should be used for.

If it is not bound to the endpoint --- that specifies the properties of the
link --- then you could just put it to the driver, couldn't you?

But earlier on, we established that this is specific to a given board, or a
given link. Endpoints are used to describe connections that a device may
have to other devices. Therefore their properties are different.

The graph bindings allow for several endpoints on a single physical port,
some may be disabled in that case. This is admittedly mostly done with
CSI-2 receivers.

Either way, putting this property to the device may affect how DT source is
arranged for boards that have this device. Any similar configuration on
other devices with multiple transmitters or receivers would be in endpoints
anyway --- because they have to, so I don't see why bindings for this
device should be different.

If you put it to endpoint, the driver also doesn't need to match the link
frequencies in kHz and Hz between the two properties, but just use the same
index for both.

-- 
Sakari Ailus

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

  parent reply	other threads:[~2020-10-19  8:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13 13:05 [PATCH v15 0/2] media: i2c: Add support for OV02A10 sensor Dongchun Zhu
2020-10-13 13:05 ` [PATCH v15 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings Dongchun Zhu
2020-10-13 16:19   ` Sakari Ailus
2020-10-14  2:10     ` Dongchun Zhu
2020-10-14  8:31       ` Sakari Ailus
2020-10-14 11:48         ` Tomasz Figa
2020-10-16 17:21           ` Rob Herring
2020-10-19  8:27           ` Sakari Ailus [this message]
2020-10-19 19:20             ` Tomasz Figa
2020-10-26 22:25               ` Tomasz Figa
2020-10-30 16:27               ` Sakari Ailus
2020-11-19 12:58                 ` Dongchun Zhu
2020-10-16 17:21   ` Rob Herring
2020-10-13 13:05 ` [PATCH v15 2/2] media: i2c: Add OV02A10 image sensor driver Dongchun Zhu
2020-10-23 14:31   ` Andy Shevchenko
2020-11-19 13:06     ` Dongchun Zhu
2020-11-19 13:57       ` Andy Shevchenko

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=20201019082759.GL13341@paasikivi.fi.intel.com \
    --to=sakari.ailus@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bingbu.cao@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dongchun.zhu@mediatek.com \
    --cc=drinkcat@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=louis.kuo@mediatek.com \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=shengnan.wang@mediatek.com \
    --cc=sj.huang@mediatek.com \
    --cc=srv_heupstream@mediatek.com \
    --cc=tfiga@chromium.org \
    /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).