Received-SPF: pass (google.com: domain of linux-kernel+bounces-77887-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <1f598a72-dd9f-4c6c-af7f-29751f84bd23@alliedtelesis.co.nz>
 <Zde966nsJ76QOuzm@surfacebook.localdomain> <f5e74774-226a-4678-a6f9-b4f17250ad91@alliedtelesis.co.nz>
 <CAHp75Vfq3Pc+Eo3Z5mhORZwwuKF+Y7_47dTO8qARcfba4nmj2w@mail.gmail.com>
 <9d00e1b1-120b-4c2b-89c5-0ac736bf6441@alliedtelesis.co.nz>
 <CAHp75VdnXtVwrLrcGjnYMfNx7roBvQm9DMr6_ndjZeAbRDbs_Q@mail.gmail.com> <2a8d19ee-b18b-4b7c-869f-7d601cea30b6@alliedtelesis.co.nz>
In-Reply-To: <2a8d19ee-b18b-4b7c-869f-7d601cea30b6@alliedtelesis.co.nz>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Fri, 23 Feb 2024 08:51:48 +0100
Message-ID: <CAMuHMdUFW7iTdhQtW4eDnU50zRqsdWsLnTD74UQo8tBU66-dCA@mail.gmail.com>
Subject: Re: Linux support for a 7 segment LED display
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Pavel Machek <pavel@ucw.cz>, 
	"lee@kernel.org" <lee@kernel.org>, "linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Chris,

On Fri, Feb 23, 2024 at 4:46=E2=80=AFAM Chris Packham
<Chris.Packham@alliedtelesis.co.nz> wrote:
> On 23/02/24 11:13, Andy Shevchenko wrote:
> > On Fri, Feb 23, 2024 at 12:08=E2=80=AFAM Chris Packham
> > <Chris.Packham@alliedtelesis.co.nz> wrote:
> >> On 23/02/24 10:59, Andy Shevchenko wrote:
> >>> On Thu, Feb 22, 2024 at 11:53=E2=80=AFPM Chris Packham
> >>> <Chris.Packham@alliedtelesis.co.nz> wrote:
> >>>> On 23/02/24 10:34, andy.shevchenko@gmail.com wrote:
> >>>>> Sun, Feb 11, 2024 at 08:46:12PM +0000, Chris Packham kirjoitti:
> >>>>>> I'm looking for something that I figured must exists but maybe it'=
s so
> >>>>>> niche that no-one has bothered to upstream a driver for it.
> >>>>>>
> >>>>>> I have a requirement to support a 7-segment LED display[1] (one th=
at can
> >>>>>> display a single digit from 0-9). Hardware wise it's just a bunch =
of
> >>>>>> individual GPIOs connected to each segment (plus an extra one for =
a
> >>>>>> dot). I can't see anything obvious in drivers/leds but maybe I'm l=
ooking
> >>>>>> in the wrong place. Or maybe it's the kind of thing on PC hardware=
 that
> >>>>>> is just driven by the BIOS without the operating system knowing ab=
out it.
> >>>>>>
> >>>>>> Is there an existing in-kernel driver for such a thing?
> >>>>> No, and can't be. Here is just a mapping table and other drivers th=
at use
> >>>>> 7-segment LED displays to be connected to.
> >>>>>
> >>>>> What you need is something else, i.e. special case of leds-gpio (wh=
ich should
> >>>>> be somewhere else) that does something like this. To me it sounds l=
ike a
> >>>>> mixture between line-display.h (from auxdisplay) and gpio-aggregato=
r.
> >>>>>
> >>>>> How many digits do you want to connect? How are they going to be co=
nnected
> >>>>> (static display, or dynamic when you need to refresh in certain per=
iods of
> >>>>> time)? Depending on the answer it might take one or another approac=
h.
> >>>> It sounds like a auxdisplay driver might be the way to go. My hardwa=
re
> >>>> happens to have a single 7seg block but there's no reason the driver
> >>>> needs to be restricted to that. At some point it obviously becomes
> >>>> better to fit something like the ht16k33 to offload the character
> >>>> display but for one or 2 digits a PCA953x plus the LED block would d=
o
> >>>> just fine.
> >>> I have hc595 (SPI GPIO) connected to a single digit 7-segment LED.
> >>> Since it can be also serialized, line display APIs seem plausible to
> >>> fit. What we need is a proxy between the two. And I think
> >>> gpio-aggregator is the best for that. It needs an additional
> >>> compatible string and the registration for line display (overall
> >>> something like 50 LoCs). We can even call that hardware compatible as
> >>> line-display-gpio (or so).
> >>>
> >>> Cc: Geert and Krzysztof (for the comments on the idea above).
> >> Would the gpio-aggregator be necessary?
> > Probably not. we just need to consume GPIOs, no need to provide...
> >
> >> I was thinking something like
> >> this in the devicetree
> >>
> >> \{
> >>       led-7seg {
> >>           compatible =3D "kingbright,sa36";
> >>           seg-gpios =3D <&gpioN 0 GPIO_ACTIVE_HIGH>,
> >>               <&gpioN 1 GPIO_ACTIVE_HIGH>,
> >>               <&gpioN 2 GPIO_ACTIVE_HIGH>,
> >>               <&gpioN 3 GPIO_ACTIVE_HIGH>,
> >>               <&gpioN 4 GPIO_ACTIVE_HIGH>,
> >>               <&gpioN 5 GPIO_ACTIVE_HIGH>,
> >>               <&gpioN 6 GPIO_ACTIVE_HIGH>;
> >>       };
> >> };
> > Right, but also with some additional properties, like
> > - type of the indicator (7, 14, etc segments, for now we have only
> > these two supported)
> > - use-dot (+1 led per each digit)
> > - characters (how many digits we have, so we need respective amount of =
GPIOs)
> >
> > With this it's indeed belongs directly to auxdisplay as we have almost
> > everything is done already there.
>
> I've been playing about with this. I've got an auxdisplay driver that's
> basically working (I won't bother spamming list with it yet). But I'm
> wondering how I'd represent multiple characters. I kind of feel the
> natural representation would be something like.
>
>          led-7seg {
>                  compatible =3D "generic,7-segment-on-gpio";

gpio-7seg?

>                  char-0 {
>                      segment-gpios =3D <&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>;
>                  };
>                  char-1 {
>                      segment-gpios =3D <&gpio 8 GPIO_ACTIVE_LOW
>                                       &gpio 9 GPIO_ACTIVE_LOW
>                                       &gpio 10 GPIO_ACTIVE_LOW
>                                       &gpio 11 GPIO_ACTIVE_LOW
>                                       &gpio 12 GPIO_ACTIVE_LOW
>                                       &gpio 13 GPIO_ACTIVE_LOW
>                                       &gpio 14 GPIO_ACTIVE_LOW>;
>                  };
>          };
>
> But having those sub-nodes means I can't just use devm_gpiod_get_array()
> instead I'd have to use device_for_each_child_node() and
> devm_fwnode_gpiod_get_index(). Am I missing something? I could do away
> with the sub-nodes and have properties like "segment-0-gpios",
> "segment-1-gpios" but that feels awkward.

Just use a single segment-gpios property?
The dot is optional, and can be zero.
The number of characters is (the number of elements + 1) / 8.
The "+ 1" serves to accommodate the optional dot for the last character,
but if people find that too complicated, you can enforce a multiple
of 8 instead.

The colon found on many 4-digit displays can be a separate gpios
property.

I do agree subnodes could be more appropriate for more complex
displays, but ideally you need some way to describe relative positions
for such displays, too.

Note that most larger displays are not individual LEDs, but matrices
of LEDs. Do we want to drive/scan them from software, using a
gpio-7seg-matrix driver?

Gr{oetje,eeting}s,

                        Geert

--=20
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
org

In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
                                -- Linus Torvalds