From: Maxime Ripard <maxime@cerno.tech>
To: Rob Herring <robh@kernel.org>
Cc: Chen-Yu Tsai <wens@csie.org>,
Jernej Skrabec <jernej.skrabec@siol.net>,
devicetree@vger.kernel.org, Frank Rowand <frowand.list@gmail.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-sunxi@googlegroups.com,
dri-devel <dri-devel@lists.freedesktop.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Sam Ravnborg <sam@ravnborg.org>,
Thierry Reding <thierry.reding@gmail.com>
Subject: Re: [PATCH 10/54] dt-bindings: display: panel-lvds: Document panel compatibles
Date: Mon, 23 Aug 2021 18:31:14 +0200 [thread overview]
Message-ID: <20210823163114.ohmdpc7pn22p5ycd@gilmour> (raw)
In-Reply-To: <CAL_JsqJjnGhXpfvPWU0HM8YHk5PyDup7ors3ewa17vc0bnVCmQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3707 bytes --]
Hi,
On Wed, Aug 18, 2021 at 08:48:46AM -0500, Rob Herring wrote:
> On Wed, Aug 18, 2021 at 7:43 AM Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > Hi Rob, Sam,
> >
> > On Wed, Jul 21, 2021 at 08:29:47PM -0600, Rob Herring wrote:
> > > On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
> > > > The binding mentions that all the drivers using that driver must use a
> > > > vendor-specific compatible but never enforces it, nor documents the
> > > > vendor-specific compatibles.
> > > >
> > > > Let's make we document all of them, and that the binding will create an
> > > > error if we add one that isn't.
> > > >
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > Cc: Sam Ravnborg <sam@ravnborg.org>
> > > > Cc: Thierry Reding <thierry.reding@gmail.com>
> > > > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > > > ---
> > > > .../bindings/display/panel/lvds.yaml | 18 ++++++++++++------
> > > > 1 file changed, 12 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > > > index 49460c9dceea..d1513111eb48 100644
> > > > --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > > > +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > > > @@ -31,12 +31,18 @@ allOf:
> > > >
> > > > properties:
> > > > compatible:
> > > > - contains:
> > > > - const: panel-lvds
> > > > - description:
> > > > - Shall contain "panel-lvds" in addition to a mandatory panel-specific
> > > > - compatible string defined in individual panel bindings. The "panel-lvds"
> > > > - value shall never be used on its own.
> > > > + items:
> > > > + - enum:
> > > > + - advantech,idk-1110wr
> > >
> > > At least this one is documented elsewhere.
> >
> > Indeed, I missed it.
> >
> > > You can add 'minItems: 2' if you want to just enforce having 2 compatibles. Or do:
> > >
> > > items:
> > > - {}
> > > - const: panel-lvds
> > >
> > > Which also enforces the order.
> >
> > It's not just about the order since a missing compatible will also raise
> > a warning.
> >
> > Some of those panels have a binding of their own, but some probably
> > won't (and I can't find anything specific about the one I'm most
> > interested in: tbs,a711-panel)
> >
> > Can we have something like:
> >
> > compatible:
> > oneOf:
> > - items:
> > - enum:
> > - tbs,a711-panel
> > - const: panel-lvds
> >
> > - items:
> > - {}
> > - const: panel-lvds
> >
> > That would work for both cases I guess?
>
> No, both conditions will be true. If you use 'anyOf', then we're never
> really checking the specific compatible.
>
> I think the problem here is trying to mix a common binding (aka an
> incomplete collection of properties) and a specific binding.
I'm not entirely sure why we have specific bindings for this in the
first place.
We currently have 6 specific bindings, and for 5 of them the only
specific thing in there are the data-mapping value to force and their
dimension.
I'd argue that the dimension shouldn't even be set in stone: you could
very well imagine a screen with exactly the same timings but a different
size. We would consider it compatible.
And the data-mapping can be dealt with with an if clause fairly easily.
And for the last one, the specific thing about it is that it's using a
dual-link output, which is a generic binding and could thus be described
in panel-lvds too.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2021-08-23 16:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210721140424.725744-1-maxime@cerno.tech>
2021-07-21 14:03 ` [PATCH 10/54] dt-bindings: display: panel-lvds: Document panel compatibles Maxime Ripard
2021-07-21 14:14 ` Sam Ravnborg
2021-07-22 2:09 ` Rob Herring
2021-07-22 2:29 ` Rob Herring
2021-08-18 12:43 ` Maxime Ripard
2021-08-18 13:48 ` Rob Herring
2021-08-23 16:31 ` Maxime Ripard [this message]
2021-07-21 14:03 ` [PATCH 11/54] dt-bindings: display: simple-bridge: Add corpro, gm7123 compatible Maxime Ripard
2021-07-21 14:16 ` Sam Ravnborg
2021-07-22 9:44 ` Maxime Ripard
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=20210823163114.ohmdpc7pn22p5ycd@gilmour \
--to=maxime@cerno.tech \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=frowand.list@gmail.com \
--cc=jernej.skrabec@siol.net \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-sunxi@googlegroups.com \
--cc=robh@kernel.org \
--cc=sam@ravnborg.org \
--cc=thierry.reding@gmail.com \
--cc=wens@csie.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).