Add bindings for a generic 7 segment LED display using GPIOs.
Signed-off-by: Chris Packham <[email protected]>
---
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 <[email protected]>
+
+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>;
+ };
--
2.43.2
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 <[email protected]>
> ---
>
> 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/[email protected]
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.
On Tue, Feb 27, 2024 at 11:22 PM Chris Packham
<[email protected]> 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.
> + };
--
With Best Regards,
Andy Shevchenko
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 <[email protected]>
> ---
>
> 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 <[email protected]>
> +
> +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
On Wed, Feb 28, 2024 at 4:04 PM Rob Herring <[email protected]> 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.
--
With Best Regards,
Andy Shevchenko
On 28/02/24 13:03, Andy Shevchenko wrote:
> On Tue, Feb 27, 2024 at 11:22 PM Chris Packham
> <[email protected]> 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.
>> + };
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
> > <[email protected]> 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.
> >> + };
--
With Best Regards,
Andy Shevchenko
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 <[email protected]>
>> ---
>>
>> 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 <[email protected]>
>> +
>> +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.
Hi Andy,
On Wed, Feb 28, 2024 at 3:58 PM Andy Shevchenko
<[email protected]> wrote:
> On Wed, Feb 28, 2024 at 4:04 PM Rob Herring <[email protected]> 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 -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Chris,
On Wed, Feb 28, 2024 at 9:02 PM Chris Packham
<[email protected]> 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
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Feb 29, 2024 at 10:23:15AM +0100, Geert Uytterhoeven wrote:
> On Wed, Feb 28, 2024 at 3:58 PM Andy Shevchenko
> <[email protected]> wrote:
> > On Wed, Feb 28, 2024 at 4:04 PM Rob Herring <[email protected]> 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).
--
With Best Regards,
Andy Shevchenko
On Thu, Feb 29, 2024 at 10:24:33AM +0100, Geert Uytterhoeven wrote:
> On Wed, Feb 28, 2024 at 9:02 PM Chris Packham
> <[email protected]> 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.
--
With Best Regards,
Andy Shevchenko