Received-SPF: pass (google.com: domain of linux-kernel+bounces-77453-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>
In-Reply-To: <9d00e1b1-120b-4c2b-89c5-0ac736bf6441@alliedtelesis.co.nz>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Fri, 23 Feb 2024 00:13:47 +0200
Message-ID: <CAHp75VdnXtVwrLrcGjnYMfNx7roBvQm9DMr6_ndjZeAbRDbs_Q@mail.gmail.com>
Subject: Re: Linux support for a 7 segment LED display
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>, 
	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

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:
> >>>> Hi Blinkenlight enthusiasts,
> >>>>
> >>>> 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 that=
 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 loo=
king
> >>>> in the wrong place. Or maybe it's the kind of thing on PC hardware t=
hat
> >>>> is just driven by the BIOS without the operating system knowing abou=
t 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 that=
 use
> >>> 7-segment LED displays to be connected to.
> >>>
> >>> What you need is something else, i.e. special case of leds-gpio (whic=
h should
> >>> be somewhere else) that does something like this. To me it sounds lik=
e a
> >>> mixture between line-display.h (from auxdisplay) and gpio-aggregator.
> >>>
> >>> How many digits do you want to connect? How are they going to be conn=
ected
> >>> (static display, or dynamic when you need to refresh in certain perio=
ds of
> >>> time)? Depending on the answer it might take one or another approach.
> >> It sounds like a auxdisplay driver might be the way to go. My hardware
> >> 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 do
> >> 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 GPIO=
s)

With this it's indeed belongs directly to auxdisplay as we have almost
everything is done already there.

> >> The information we want to display is mostly static (basically a numer=
ic
> >> unit identifier) but there are cases where we may want to alternate
> >> between this and "F" to indicate some fault condition

--=20
With Best Regards,
Andy Shevchenko