From: Rob Herring <robh@kernel.org> To: Thierry Reding <thierry.reding@gmail.com> Cc: dri-devel <dri-devel@lists.freedesktop.org>, devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Sam Ravnborg <sam@ravnborg.org>, Maxime Ripard <maxime.ripard@bootlin.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com> Subject: Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema Date: Thu, 20 Jun 2019 08:52:36 -0600 [thread overview] Message-ID: <CAL_JsqKC-RDjdMQWM6yk_HiWu-WwuU+vUf946t=TDJAxnqMW7Q@mail.gmail.com> (raw) In-Reply-To: <20190620090122.GB26689@ulmo> On Thu, Jun 20, 2019 at 3:01 AM Thierry Reding <thierry.reding@gmail.com> wrote: > > On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote: > > Convert the common panel bindings to DT schema consolidating scattered > > definitions to a single schema file. > > > > The 'simple-panel' binding just a collection of properties and not a > > complete binding itself. All of the 'simple-panel' properties are > > covered by the panel-common.txt binding with the exception of the > > 'no-hpd' property, so add that to the schema. > > > > As there are lots of references to simple-panel.txt, just keep the file > > with a reference to panel-common.yaml for now until all the bindings are > > converted. > > > > Cc: Thierry Reding <thierry.reding@gmail.com> > > Cc: Sam Ravnborg <sam@ravnborg.org> > > Cc: Maxime Ripard <maxime.ripard@bootlin.com> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > Note there's still some references to panel-common.txt that I need to > > update or just go ahead and convert to schema. > > > > .../bindings/display/panel/panel-common.txt | 101 ------------- > > .../bindings/display/panel/panel-common.yaml | 143 ++++++++++++++++++ > > .../bindings/display/panel/panel.txt | 4 - > > .../bindings/display/panel/simple-panel.txt | 29 +--- > > 4 files changed, 144 insertions(+), 133 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.yaml > > I know it was this way before, but perhaps remove the redundant panel- > prefix while at it? Sure. > > diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml > > new file mode 100644 > > index 000000000000..6fe87254edad > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml > > @@ -0,0 +1,143 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/panel/panel-common.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Common Properties for Display Panels > > + > > +maintainers: > > + - Thierry Reding <thierry.reding@gmail.com> > > + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > + > > +description: | > > + This document defines device tree properties common to several classes of > > + display panels. It doesn't constitue a device tree binding specification by > > + itself but is meant to be referenced by device tree bindings. > > + > > + When referenced from panel device tree bindings the properties defined in this > > + document are defined as follows. The panel device tree bindings are > > + responsible for defining whether each property is required or optional. > > + > > + > > Are the two blank lines here on purpose? No. > The original document had two > blank lines here, but that was mostly for readability I would guess. The > YAML format doesn't really need additional formatting for readability, > so perhaps just remove the extra blank line? > > > +properties: > > + # Descriptive Properties > > + width-mm: > > + description: The width-mm and height-mm specify the width and height of the > > + physical area where images are displayed. These properties are expressed > > + in millimeters and rounded to the closest unit. > > + > > + height-mm: > > + description: The width-mm and height-mm specify the width and height of the > > + physical area where images are displayed. These properties are expressed > > + in millimeters and rounded to the closest unit. > > I suppose there's no way in YAML to share the description between both > the width-mm and height-mm properties? It's a little unfortunate that we > have to copy, but if there's no better way, guess we'll have to live > with it. I could make it a comment instead, but then we loose being able to parse it. I should probably just reword them to be separate: "Specifies the height of the physical area where images are displayed. The property is expressed in millimeters and rounded to the closest unit." Also, just realized I need to make these 2 dependencies on either other (i.e. not valid to only have one). > > + label: > > + description: | > > + The label property specifies a symbolic name for the panel as a > > + string suitable for use by humans. It typically contains a name inscribed > > + on the system (e.g. as an affixed label) or specified in the system's > > + documentation (e.g. in the user's manual). > > + > > + If no such name exists, and unless the property is mandatory according to > > + device tree bindings, it shall rather be omitted than constructed of > > + non-descriptive information. For instance an LCD panel in a system that > > + contains a single panel shall not be labelled "LCD" if that name is not > > + inscribed on the system or used in a descriptive fashion in system > > + documentation. > > + > > + rotation: > > + description: > > + Display rotation in degrees counter clockwise (0,90,180,270) > > + allOf: > > + - $ref: /schemas/types.yaml#/definitions/uint32 > > + - enum: [ 0, 90, 180, 270 ] > > + > > + # Display Timings > > + panel-timing: > > Am I the only one bugged by the redundancy in this property name? What > else is the timing going to express if not the timing of the panel that > it's part of. "timing" really would be enough. Anyway, not much we can > do about it now. I'm just happy we have a defined name. Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org> To: Thierry Reding <thierry.reding@gmail.com> Cc: devicetree@vger.kernel.org, Maxime Ripard <maxime.ripard@bootlin.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Sam Ravnborg <sam@ravnborg.org> Subject: Re: [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema Date: Thu, 20 Jun 2019 08:52:36 -0600 [thread overview] Message-ID: <CAL_JsqKC-RDjdMQWM6yk_HiWu-WwuU+vUf946t=TDJAxnqMW7Q@mail.gmail.com> (raw) In-Reply-To: <20190620090122.GB26689@ulmo> On Thu, Jun 20, 2019 at 3:01 AM Thierry Reding <thierry.reding@gmail.com> wrote: > > On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote: > > Convert the common panel bindings to DT schema consolidating scattered > > definitions to a single schema file. > > > > The 'simple-panel' binding just a collection of properties and not a > > complete binding itself. All of the 'simple-panel' properties are > > covered by the panel-common.txt binding with the exception of the > > 'no-hpd' property, so add that to the schema. > > > > As there are lots of references to simple-panel.txt, just keep the file > > with a reference to panel-common.yaml for now until all the bindings are > > converted. > > > > Cc: Thierry Reding <thierry.reding@gmail.com> > > Cc: Sam Ravnborg <sam@ravnborg.org> > > Cc: Maxime Ripard <maxime.ripard@bootlin.com> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > Note there's still some references to panel-common.txt that I need to > > update or just go ahead and convert to schema. > > > > .../bindings/display/panel/panel-common.txt | 101 ------------- > > .../bindings/display/panel/panel-common.yaml | 143 ++++++++++++++++++ > > .../bindings/display/panel/panel.txt | 4 - > > .../bindings/display/panel/simple-panel.txt | 29 +--- > > 4 files changed, 144 insertions(+), 133 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.yaml > > I know it was this way before, but perhaps remove the redundant panel- > prefix while at it? Sure. > > diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml > > new file mode 100644 > > index 000000000000..6fe87254edad > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml > > @@ -0,0 +1,143 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/panel/panel-common.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Common Properties for Display Panels > > + > > +maintainers: > > + - Thierry Reding <thierry.reding@gmail.com> > > + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > + > > +description: | > > + This document defines device tree properties common to several classes of > > + display panels. It doesn't constitue a device tree binding specification by > > + itself but is meant to be referenced by device tree bindings. > > + > > + When referenced from panel device tree bindings the properties defined in this > > + document are defined as follows. The panel device tree bindings are > > + responsible for defining whether each property is required or optional. > > + > > + > > Are the two blank lines here on purpose? No. > The original document had two > blank lines here, but that was mostly for readability I would guess. The > YAML format doesn't really need additional formatting for readability, > so perhaps just remove the extra blank line? > > > +properties: > > + # Descriptive Properties > > + width-mm: > > + description: The width-mm and height-mm specify the width and height of the > > + physical area where images are displayed. These properties are expressed > > + in millimeters and rounded to the closest unit. > > + > > + height-mm: > > + description: The width-mm and height-mm specify the width and height of the > > + physical area where images are displayed. These properties are expressed > > + in millimeters and rounded to the closest unit. > > I suppose there's no way in YAML to share the description between both > the width-mm and height-mm properties? It's a little unfortunate that we > have to copy, but if there's no better way, guess we'll have to live > with it. I could make it a comment instead, but then we loose being able to parse it. I should probably just reword them to be separate: "Specifies the height of the physical area where images are displayed. The property is expressed in millimeters and rounded to the closest unit." Also, just realized I need to make these 2 dependencies on either other (i.e. not valid to only have one). > > + label: > > + description: | > > + The label property specifies a symbolic name for the panel as a > > + string suitable for use by humans. It typically contains a name inscribed > > + on the system (e.g. as an affixed label) or specified in the system's > > + documentation (e.g. in the user's manual). > > + > > + If no such name exists, and unless the property is mandatory according to > > + device tree bindings, it shall rather be omitted than constructed of > > + non-descriptive information. For instance an LCD panel in a system that > > + contains a single panel shall not be labelled "LCD" if that name is not > > + inscribed on the system or used in a descriptive fashion in system > > + documentation. > > + > > + rotation: > > + description: > > + Display rotation in degrees counter clockwise (0,90,180,270) > > + allOf: > > + - $ref: /schemas/types.yaml#/definitions/uint32 > > + - enum: [ 0, 90, 180, 270 ] > > + > > + # Display Timings > > + panel-timing: > > Am I the only one bugged by the redundancy in this property name? What > else is the timing going to express if not the timing of the panel that > it's part of. "timing" really would be enough. Anyway, not much we can > do about it now. I'm just happy we have a defined name. Rob _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-06-20 14:52 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-19 21:51 [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema Rob Herring 2019-06-19 21:51 ` Rob Herring 2019-06-19 21:51 ` [RFC PATCH 2/4] dt-bindings: display: Convert ampire,am-480272h3tmqw-t01h panel " Rob Herring 2019-06-19 21:51 ` [RFC PATCH 2/4] dt-bindings: display: Convert ampire, am-480272h3tmqw-t01h " Rob Herring 2019-06-20 8:03 ` [RFC PATCH 2/4] dt-bindings: display: Convert ampire,am-480272h3tmqw-t01h " Maxime Ripard 2019-06-20 9:04 ` Thierry Reding 2019-06-19 21:51 ` [RFC PATCH 3/4] dt-bindings: display: Convert panel-lvds " Rob Herring 2019-06-19 21:51 ` Rob Herring 2019-06-20 8:04 ` Maxime Ripard 2019-06-20 8:04 ` Maxime Ripard 2019-06-20 9:06 ` Thierry Reding 2019-06-20 9:06 ` Thierry Reding 2019-06-19 21:51 ` [RFC PATCH 4/4] dt-bindings: display: Convert innolux,ee101ia-01 panel " Rob Herring 2019-06-20 8:05 ` Maxime Ripard 2019-06-20 9:07 ` Thierry Reding 2019-06-20 6:55 ` [RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings " Sam Ravnborg 2019-06-20 6:55 ` Sam Ravnborg 2019-06-20 15:15 ` Rob Herring 2019-06-20 7:57 ` Maxime Ripard 2019-06-20 7:57 ` Maxime Ripard 2019-06-20 9:01 ` Thierry Reding 2019-06-20 9:01 ` Thierry Reding 2019-06-20 14:52 ` Rob Herring [this message] 2019-06-20 14:52 ` Rob Herring 2019-06-20 22:01 ` Rob Herring
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='CAL_JsqKC-RDjdMQWM6yk_HiWu-WwuU+vUf946t=TDJAxnqMW7Q@mail.gmail.com' \ --to=robh@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-kernel@vger.kernel.org \ --cc=maxime.ripard@bootlin.com \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.