diff mbox series

[v2,2/4] dt-bindings: auxdisplay: Add bindings for generic 7 segment LED

Message ID 20240227212244.262710-3-chris.packham@alliedtelesis.co.nz
State New
Headers
Series auxdisplay: 7 segment LED display |

Commit Message

Chris Packham Feb. 27, 2024, 9:22 p.m. UTC 
  Add bindings for a generic 7 segment LED display using GPIOs.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---

Notes:
    Changes in v2:
    - Use compatible = "generic-gpio-7seg" to keep checkpatch.pl happy

 .../auxdisplay/generic-gpio-7seg.yaml         | 40 +++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml

Comments

Rob Herring Feb. 27, 2024, 10:19 p.m. UTC | #1 
On Wed, 28 Feb 2024 10:22:42 +1300, Chris Packham wrote:
> Add bindings for a generic 7 segment LED display using GPIOs.
> 
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> 
> Notes:
>     Changes in v2:
>     - Use compatible = "generic-gpio-7seg" to keep checkpatch.pl happy
> 
>  .../auxdisplay/generic-gpio-7seg.yaml         | 40 +++++++++++++++++++
>  1 file changed, 40 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename
 	 $id: http://devicetree.org/schemas/auxdisplay/generic,gpio-7seg.yaml
 	file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240227212244.262710-3-chris.packham@alliedtelesis.co.nz

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Andy Shevchenko Feb. 28, 2024, 12:03 a.m. UTC | #2 
On Tue, Feb 27, 2024 at 11:22 PM Chris Packham
<chris.packham@alliedtelesis.co.nz> wrote:

..

> +  segment-gpios:
> +    description:
> +      An array of GPIOs one per segment.

This is a vague description. Please explain the order (e.g., LSB =
'a', MSB = 'g'), use of DP (optional?), etc.

> +    minItems: 7

maxItems?

..

> +    led-7seg {

Probably it should be more human readable. DT people might suggest
something better.

> +        compatible = "generic-gpio-7seg";
> +        segment-gpios = <&gpio 0 GPIO_ACTIVE_LOW
> +                         &gpio 1 GPIO_ACTIVE_LOW
> +                         &gpio 2 GPIO_ACTIVE_LOW
> +                         &gpio 3 GPIO_ACTIVE_LOW
> +                         &gpio 4 GPIO_ACTIVE_LOW
> +                         &gpio 5 GPIO_ACTIVE_LOW
> +                         &gpio 6 GPIO_ACTIVE_LOW>;

Dunno how to handle DP. Either we always expect it to be here (as
placeholder) or with additional property.

> +    };
Chris Packham Feb. 28, 2024, 1:53 a.m. UTC | #3 
On 28/02/24 13:03, Andy Shevchenko wrote:
> On Tue, Feb 27, 2024 at 11:22 PM Chris Packham
> <chris.packham@alliedtelesis.co.nz> wrote:
>
> ...
>
>> +  segment-gpios:
>> +    description:
>> +      An array of GPIOs one per segment.
> This is a vague description. Please explain the order (e.g., LSB =
> 'a', MSB = 'g'), use of DP (optional?), etc.
>
>> +    minItems: 7
> maxItems?
>
> ...

I plan on saying maxItems: 7 (more discussion below)

>
>> +    led-7seg {
> Probably it should be more human readable. DT people might suggest
> something better.
>
>> +        compatible = "generic-gpio-7seg";
>> +        segment-gpios = <&gpio 0 GPIO_ACTIVE_LOW
>> +                         &gpio 1 GPIO_ACTIVE_LOW
>> +                         &gpio 2 GPIO_ACTIVE_LOW
>> +                         &gpio 3 GPIO_ACTIVE_LOW
>> +                         &gpio 4 GPIO_ACTIVE_LOW
>> +                         &gpio 5 GPIO_ACTIVE_LOW
>> +                         &gpio 6 GPIO_ACTIVE_LOW>;
> Dunno how to handle DP. Either we always expect it to be here (as
> placeholder) or with additional property.

My current plan was to ignore it. As you see it my later patch I'm 
(ab)using DP as a discrete gpio-led with a different function.

We could either a separate dp-gpios property or set maxItems to 8. Right 
now the driver won't do anything with either option.To actually do 
something in the linedisp driver we'd need to have a new character map 
that includes the extra LED.

>> +    };
Rob Herring Feb. 28, 2024, 2:04 p.m. UTC | #4 
On Wed, Feb 28, 2024 at 10:22:42AM +1300, Chris Packham wrote:
> Add bindings for a generic 7 segment LED display using GPIOs.
> 
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> 
> Notes:
>     Changes in v2:
>     - Use compatible = "generic-gpio-7seg" to keep checkpatch.pl happy
> 
>  .../auxdisplay/generic-gpio-7seg.yaml         | 40 +++++++++++++++++++
>  1 file changed, 40 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml
> 
> diff --git a/Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml b/Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml
> new file mode 100644
> index 000000000000..46d53ebdf413
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml
> @@ -0,0 +1,40 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/auxdisplay/generic,gpio-7seg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: GPIO based LED segment display
> +
> +maintainers:
> +  - Chris Packham <chris.packham@alliedtelesis.co.nz>
> +
> +properties:
> +  compatible:
> +    const: generic-gpio-7seg

'generic' doesn't add anything of value. 7seg is kind of vague. So, 
gpio-7-segment?


> +
> +  segment-gpios:
> +    description:
> +      An array of GPIOs one per segment.
> +    minItems: 7

How does one know which GPIO is which segment?

Rob
Andy Shevchenko Feb. 28, 2024, 2:57 p.m. UTC | #5 
On Wed, Feb 28, 2024 at 4:04 PM Rob Herring <robh@kernel.org> wrote:
> On Wed, Feb 28, 2024 at 10:22:42AM +1300, Chris Packham wrote:

..

> > +  segment-gpios:
> > +    description:
> > +      An array of GPIOs one per segment.
> > +    minItems: 7
>
> How does one know which GPIO is which segment?

I believe we need just to agree on this. Since anybody can shuffle
GPIOs in the DT, there is no need to support arbitrary orders. And
naturally 'a' is bit 0, 'g' is bit 6, 'dp' bit 7 if present.
Andy Shevchenko Feb. 28, 2024, 5:22 p.m. UTC | #6 
On Wed, Feb 28, 2024 at 01:53:08AM +0000, Chris Packham wrote:
> On 28/02/24 13:03, Andy Shevchenko wrote:
> > On Tue, Feb 27, 2024 at 11:22 PM Chris Packham
> > <chris.packham@alliedtelesis.co.nz> wrote:

..

> >> +  segment-gpios:
> >> +    description:
> >> +      An array of GPIOs one per segment.
> > This is a vague description. Please explain the order (e.g., LSB =
> > 'a', MSB = 'g'), use of DP (optional?), etc.
> >
> >> +    minItems: 7
> > maxItems?

> I plan on saying maxItems: 7 (more discussion below)

..

> >> +    led-7seg {
> > Probably it should be more human readable. DT people might suggest
> > something better.
> >
> >> +        compatible = "generic-gpio-7seg";
> >> +        segment-gpios = <&gpio 0 GPIO_ACTIVE_LOW
> >> +                         &gpio 1 GPIO_ACTIVE_LOW
> >> +                         &gpio 2 GPIO_ACTIVE_LOW
> >> +                         &gpio 3 GPIO_ACTIVE_LOW
> >> +                         &gpio 4 GPIO_ACTIVE_LOW
> >> +                         &gpio 5 GPIO_ACTIVE_LOW
> >> +                         &gpio 6 GPIO_ACTIVE_LOW>;
> > Dunno how to handle DP. Either we always expect it to be here (as
> > placeholder) or with additional property.
> 
> My current plan was to ignore it. As you see it my later patch I'm 
> (ab)using DP as a discrete gpio-led with a different function.

FWIW, I have _no_ indicator _without_ DP. So, my statistics is towards enabling
DP as a part of 7-segment displays.

> We could either a separate dp-gpios property or set maxItems to 8. Right 
> now the driver won't do anything with either option.To actually do 
> something in the linedisp driver we'd need to have a new character map 
> that includes the extra LED.

Yeah, we can leave it open for now.

> >> +    };
Chris Packham Feb. 28, 2024, 8:01 p.m. UTC | #7 
On 29/02/24 03:04, Rob Herring wrote:
> On Wed, Feb 28, 2024 at 10:22:42AM +1300, Chris Packham wrote:
>> Add bindings for a generic 7 segment LED display using GPIOs.
>>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
>>
>> Notes:
>>      Changes in v2:
>>      - Use compatible = "generic-gpio-7seg" to keep http://scanmail.trustwave.com/?c=20988&d=7b3f5fUJGtY-Kala5ZOOxaOVYt2BwN-ZLskYi3hWDQ&u=http%3a%2f%2fcheckpatch%2epl happy
>>
>>   .../auxdisplay/generic-gpio-7seg.yaml         | 40 +++++++++++++++++++
>>   1 file changed, 40 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml b/Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml
>> new file mode 100644
>> index 000000000000..46d53ebdf413
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml
>> @@ -0,0 +1,40 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://scanmail.trustwave.com/?c=20988&d=7b3f5fUJGtY-Kala5ZOOxaOVYt2BwN-ZLsYdhCQAWQ&u=http%3a%2f%2fdevicetree%2eorg%2fschemas%2fauxdisplay%2fgeneric%2cgpio-7seg%2eyaml%23
>> +$schema: http://scanmail.trustwave.com/?c=20988&d=7b3f5fUJGtY-Kala5ZOOxaOVYt2BwN-ZLsYY0X9WDg&u=http%3a%2f%2fdevicetree%2eorg%2fmeta-schemas%2fcore%2eyaml%23
>> +
>> +title: GPIO based LED segment display
>> +
>> +maintainers:
>> +  - Chris Packham <chris.packham@alliedtelesis.co.nz>
>> +
>> +properties:
>> +  compatible:
>> +    const: generic-gpio-7seg
> 'generic' doesn't add anything of value. 7seg is kind of vague. So,
> gpio-7-segment?

Ack.

>> +
>> +  segment-gpios:
>> +    description:
>> +      An array of GPIOs one per segment.
>> +    minItems: 7
> How does one know which GPIO is which segment?

I've expanded the description in v3.

+ An array of GPIOs one per segment. The first GPIO corresponds to the A
+ segment the last GPIO corresponds to the G segment.

Do you think that's sufficient or do I need to add more? In the driver 
itself I've put a little ascii art diagram of the segments.
Geert Uytterhoeven Feb. 29, 2024, 9:23 a.m. UTC | #8 
Hi Andy,

On Wed, Feb 28, 2024 at 3:58 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Wed, Feb 28, 2024 at 4:04 PM Rob Herring <robh@kernel.org> wrote:
> > On Wed, Feb 28, 2024 at 10:22:42AM +1300, Chris Packham wrote:
>
> ...
>
> > > +  segment-gpios:
> > > +    description:
> > > +      An array of GPIOs one per segment.
> > > +    minItems: 7
> >
> > How does one know which GPIO is which segment?
>
> I believe we need just to agree on this. Since anybody can shuffle
> GPIOs in the DT, there is no need to support arbitrary orders. And
> naturally 'a' is bit 0, 'g' is bit 6, 'dp' bit 7 if present.

Note that there are no bits involved at this level, only GPIO specifiers.

Gr{oetje,eeting}s,

                        Geert
Geert Uytterhoeven Feb. 29, 2024, 9:24 a.m. UTC | #9 
Hi Chris,

On Wed, Feb 28, 2024 at 9:02 PM Chris Packham
<Chris.Packham@alliedtelesis.co.nz> wrote:
> On 29/02/24 03:04, Rob Herring wrote:
> > On Wed, Feb 28, 2024 at 10:22:42AM +1300, Chris Packham wrote:
> >> +  segment-gpios:
> >> +    description:
> >> +      An array of GPIOs one per segment.
> >> +    minItems: 7
> > How does one know which GPIO is which segment?
>
> I've expanded the description in v3.
>
> + An array of GPIOs one per segment. The first GPIO corresponds to the A
> + segment the last GPIO corresponds to the G segment.
>
> Do you think that's sufficient or do I need to add more? In the driver
> itself I've put a little ascii art diagram of the segments.

Given users are reading the bindings rather than the driver source,
I would move the diagram to the bindings.

Thanks!

Gr{oetje,eeting}s,

                        Geert
Andy Shevchenko Feb. 29, 2024, 10:42 a.m. UTC | #10 
On Thu, Feb 29, 2024 at 10:23:15AM +0100, Geert Uytterhoeven wrote:
> On Wed, Feb 28, 2024 at 3:58 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Wed, Feb 28, 2024 at 4:04 PM Rob Herring <robh@kernel.org> wrote:
> > > On Wed, Feb 28, 2024 at 10:22:42AM +1300, Chris Packham wrote:

..

> > > > +  segment-gpios:
> > > > +    description:
> > > > +      An array of GPIOs one per segment.
> > > > +    minItems: 7
> > >
> > > How does one know which GPIO is which segment?
> >
> > I believe we need just to agree on this. Since anybody can shuffle
> > GPIOs in the DT, there is no need to support arbitrary orders. And
> > naturally 'a' is bit 0, 'g' is bit 6, 'dp' bit 7 if present.
> 
> Note that there are no bits involved at this level, only GPIO specifiers.

Right, I meant the sequence in the array of GPIOs in the DT.
I implied that it maps 1:1 to the real bits in HW (in some cases).
andy@kernel.org Feb. 29, 2024, 10:44 a.m. UTC | #11 
On Thu, Feb 29, 2024 at 10:24:33AM +0100, Geert Uytterhoeven wrote:
> On Wed, Feb 28, 2024 at 9:02 PM Chris Packham
> <Chris.Packham@alliedtelesis.co.nz> wrote:
> > On 29/02/24 03:04, Rob Herring wrote:
> > > On Wed, Feb 28, 2024 at 10:22:42AM +1300, Chris Packham wrote:

..

> > > How does one know which GPIO is which segment?
> >
> > I've expanded the description in v3.
> >
> > + An array of GPIOs one per segment. The first GPIO corresponds to the A
> > + segment the last GPIO corresponds to the G segment.
> >
> > Do you think that's sufficient or do I need to add more? In the driver
> > itself I've put a little ascii art diagram of the segments.
> 
> Given users are reading the bindings rather than the driver source,
> I would move the diagram to the bindings.

+1 here. We have a diagram already in UAPI headers, but that won't be (quickly)
visible for the real users, duplicating in the code doesn't add any value, but
adding it to DT description will be beneficial.
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml b/Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml
new file mode 100644
index 000000000000..46d53ebdf413
--- /dev/null
+++ b/Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml
@@ -0,0 +1,40 @@ 
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/auxdisplay/generic,gpio-7seg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO based LED segment display
+
+maintainers:
+  - Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+properties:
+  compatible:
+    const: generic-gpio-7seg
+
+  segment-gpios:
+    description:
+      An array of GPIOs one per segment.
+    minItems: 7
+
+required:
+  - segment-gpios
+
+additionalProperties: false
+
+examples:
+  - |
+
+    #include <dt-bindings/gpio/gpio.h>
+
+    led-7seg {
+        compatible = "generic-gpio-7seg";
+        segment-gpios = <&gpio 0 GPIO_ACTIVE_LOW
+                         &gpio 1 GPIO_ACTIVE_LOW
+                         &gpio 2 GPIO_ACTIVE_LOW
+                         &gpio 3 GPIO_ACTIVE_LOW
+                         &gpio 4 GPIO_ACTIVE_LOW
+                         &gpio 5 GPIO_ACTIVE_LOW
+                         &gpio 6 GPIO_ACTIVE_LOW>;
+    };