linux-kernel - Re: Linux support for a 7 segment LED display

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 22 Feb 2024 22:08:35 +0000
From: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To: Andy Shevchenko <andy.shevchenko@...il.com>, Geert Uytterhoeven
	<geert@...ux-m68k.org>, Krzysztof Kozlowski
	<krzysztof.kozlowski+dt@...aro.org>
CC: Pavel Machek <pavel@....cz>, "lee@...nel.org" <lee@...nel.org>,
	"linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Linux support for a 7 segment LED display


On 23/02/24 10:59, Andy Shevchenko wrote:
> On Thu, Feb 22, 2024 at 11:53 PM Chris Packham
> <Chris.Packham@...iedtelesis.co.nz> wrote:
>> On 23/02/24 10:34, andy.shevchenko@...il.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 looking
>>>> 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 about 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 (which should
>>> be somewhere else) that does something like this. To me it sounds like 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 connected
>>> (static display, or dynamic when you need to refresh in certain periods 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? I was thinking something like 
this in the devicetree

\{
     led-7seg {
         compatible = "kingbright,sa36";
         seg-gpios = <&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>;
     };
};

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