From: Maxime Ripard <maxime@cerno.tech>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Sam Ravnborg <sam@ravnborg.org>,
Daniel Vetter <daniel.vetter@intel.com>,
David Airlie <airlied@linux.ie>, Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] dt-bindings: display: Turn lvds.yaml into a generic schema
Date: Mon, 22 Nov 2021 15:53:44 +0100 [thread overview]
Message-ID: <20211122145344.47lnihd7hfbo45ne@gilmour> (raw)
In-Reply-To: <YZgpSWVXjKr9secH@pendragon.ideasonboard.com>
Hi,
On Sat, Nov 20, 2021 at 12:46:33AM +0200, Laurent Pinchart wrote:
> On Tue, Nov 16, 2021 at 03:35:02PM +0100, Maxime Ripard wrote:
> > The lvds.yaml file so far was both defining the generic LVDS properties
> > (such as data-mapping) that could be used for any LVDS sink, but also
> > the panel-lvds binding.
> >
> > That last binding was to describe LVDS panels simple enough, and had a
> > number of other bindings using it as a base to specialise it further.
> >
> > However, this situation makes it fairly hard to extend and reuse both
> > the generic parts, and the panel-lvds itself.
> >
> > Let's remove the panel-lvds parts and leave only the generic LVDS
> > properties.
> >
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > ---
> > .../display/panel/advantech,idk-1110wr.yaml | 17 ++++++++++-
> > .../display/panel/innolux,ee101ia-01d.yaml | 21 +++++++++++++-
> > .../bindings/display/panel/lvds.yaml | 29 +------------------
> > .../display/panel/mitsubishi,aa104xd12.yaml | 17 ++++++++++-
> > .../display/panel/mitsubishi,aa121td01.yaml | 17 ++++++++++-
> > .../display/panel/sgd,gktw70sdae4se.yaml | 17 ++++++++++-
> > 6 files changed, 85 insertions(+), 33 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
> > index 93878c2cd370..f27cd2038636 100644
> > --- a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
> > @@ -11,13 +11,23 @@ maintainers:
> > - Thierry Reding <thierry.reding@gmail.com>
> >
> > allOf:
> > + - $ref: panel-common.yaml#
> > - $ref: lvds.yaml#
> >
> > +select:
> > + properties:
> > + compatible:
> > + contains:
> > + const: advantech,idk-1110wr
> > +
> > + required:
> > + - compatible
>
> I've never encountered this before, what does it do ?
select dictates if the schema is applied to a node or not.
It takes a schema, and if this schema is valid, the rest of the schema
will be applied to the current node.
It's mostly unused in the kernel because the dt-validate tool will add a
select clause from the compatible list in most case that would expand in
this case to:
select:
properties:
contains:
enum:
- advantech,idk-1110wr
- panel-lvds
required:
- compatible
ie, it tries to validate with this schema any node that has either the
panel compatible or the generic compatible.
That means we would have that schema applied to all the nodes that have
panel-lvds, including the ones with a different compatible than the
advantech one.
With this clause, we make sure that we ignore the other panels, while
ensuring that the compatible list for the advantech compatible is
correct.
> > +
> > properties:
> > compatible:
> > items:
> > - const: advantech,idk-1110wr
> > - - {} # panel-lvds, but not listed here to avoid false select
> > + - const: panel-lvds
> >
> > data-mapping:
> > const: jeida-24
> > @@ -35,6 +45,11 @@ additionalProperties: false
> >
> > required:
> > - compatible
> > + - data-mapping
> > + - width-mm
> > + - height-mm
> > + - panel-timing
> > + - port
> >
> > examples:
> > - |+
> > diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
> > index a69681e724cb..6e06eecac14e 100644
> > --- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
> > @@ -11,15 +11,26 @@ maintainers:
> > - Thierry Reding <thierry.reding@gmail.com>
> >
> > allOf:
> > + - $ref: panel-common.yaml#
> > - $ref: lvds.yaml#
> >
> > +select:
> > + properties:
> > + compatible:
> > + contains:
> > + const: innolux,ee101ia-01d
> > +
> > + required:
> > + - compatible
> > +
> > properties:
> > compatible:
> > items:
> > - const: innolux,ee101ia-01d
> > - - {} # panel-lvds, but not listed here to avoid false select
> > + - const: panel-lvds
> >
> > backlight: true
> > + data-mapping: true
> > enable-gpios: true
> > power-supply: true
> > width-mm: true
> > @@ -27,5 +38,13 @@ properties:
> > panel-timing: true
> > port: true
> >
> > +required:
> > + - compatible
> > + - data-mapping
> > + - width-mm
> > + - height-mm
> > + - panel-timing
> > + - port
> > +
> > additionalProperties: false
> > ...
> > diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > index 49460c9dceea..5281a75c8bb5 100644
> > --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > @@ -4,7 +4,7 @@
> > $id: http://devicetree.org/schemas/display/panel/lvds.yaml#
> > $schema: http://devicetree.org/meta-schemas/core.yaml#
> >
> > -title: LVDS Display Panel
> > +title: LVDS Display Common Properties
>
> Maybe
>
> title: LVDS Display Panel Common Properties
>
> or do you foresee this being useful for non-panel LBDS sinks too ? In
> that case the title is fine, but the file could be moved in the parent
> directory.
>
> I'm also wondering what we should do with the data-mapping and
> data-mirror properties. For an LVDS panel they're fine at the device
> level, but for an LVDS sink, they may be better placed at the port or
> endpoint level.
That was my intent, but it might not be relevant indeed. Honestly at
this point I just want to have the tbs,a711-panel compatible documented
somewhere :)
Maxime
prev parent reply other threads:[~2021-11-22 14:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 14:35 [PATCH 1/2] dt-bindings: display: Turn lvds.yaml into a generic schema Maxime Ripard
2021-11-16 14:35 ` [PATCH 2/2] dt-bindings: panel: Introduce a panel-lvds binding Maxime Ripard
2021-11-17 2:27 ` Rob Herring
2021-11-18 22:56 ` Rob Herring
2021-11-19 22:48 ` Laurent Pinchart
2021-11-18 22:49 ` [PATCH 1/2] dt-bindings: display: Turn lvds.yaml into a generic schema Rob Herring
2021-11-19 22:46 ` Laurent Pinchart
2021-11-22 14:53 ` Maxime Ripard [this message]
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=20211122145344.47lnihd7hfbo45ne@gilmour \
--to=maxime@cerno.tech \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=frowand.list@gmail.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=robh+dt@kernel.org \
--cc=sam@ravnborg.org \
--cc=thierry.reding@gmail.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