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?
Thanks,
Chris
--
[1] - https://www.kingbrightusa.com/images/catalog/SPEC/SA36-11GWA.pdf
On Sun, 11 Feb 2024, Chris Packham wrote:
> 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?
Why would LEDs connected to a bunch of GPIOs in a specific fashion
require a hardware driver? Doesn't drivers/leds/leds-gpio.c already
provide all the support you need?
--
Lee Jones [李琼斯]
Hi!
> 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.
Look at drivers/auxdisplay. I believe we have segment displays there.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
On 20/02/24 04:34, Pavel Machek wrote:
> Hi!
>
>> 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.
> Look at drivers/auxdisplay. I believe we have segment displays there.
Thanks for the pointer. I found ht16k33.c (and
drivers/input/misc/yealink.c) which have support for 7 segment displays.
Still not quite what I'd need to glue it together with GPIOs but I can
see the direction one might head.
Hi Lee,
On 20/02/24 04:13, Lee Jones wrote:
> On Sun, 11 Feb 2024, Chris Packham wrote:
>
>> 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?
> Why would LEDs connected to a bunch of GPIOs in a specific fashion
> require a hardware driver? Doesn't drivers/leds/leds-gpio.c already
> provide all the support you need?
Yes I could expose the individual segments as gpio-ledsbut it would be
nicer if they worked in a more co-ordinated fashion so I didn't have to
care about the individual segments and could just say "display 7" or
"display 0".
On Mon, 19 Feb 2024, Chris Packham wrote:
> Hi Lee,
>
> On 20/02/24 04:13, Lee Jones wrote:
> > On Sun, 11 Feb 2024, Chris Packham wrote:
> >
> >> 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?
> > Why would LEDs connected to a bunch of GPIOs in a specific fashion
> > require a hardware driver? Doesn't drivers/leds/leds-gpio.c already
> > provide all the support you need?
> Yes I could expose the individual segments as gpio-ledsbut it would be
> nicer if they worked in a more co-ordinated fashion so I didn't have to
> care about the individual segments and could just say "display 7" or
> "display 0".
Still not sure this sort of thing should be kernel-side.
Sounds more like the role of a library or middle-layer.
--
Lee Jones [李琼斯]
Hi!
> > >> 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?
> > > Why would LEDs connected to a bunch of GPIOs in a specific fashion
> > > require a hardware driver? Doesn't drivers/leds/leds-gpio.c already
> > > provide all the support you need?
> > Yes I could expose the individual segments as gpio-ledsbut it would be
> > nicer if they worked in a more co-ordinated fashion so I didn't have to
> > care about the individual segments and could just say "display 7" or
> > "display 0".
>
> Still not sure this sort of thing should be kernel-side.
>
> Sounds more like the role of a library or middle-layer.
We do already have 7-segment support in auxdisplay. We should simply
use that interface. Simply create auxdisplay driver that uses gpios
and provides interface similar to what is already there.
(Of course, just using gpio library for userspace will be easier).
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
On 23/02/24 10:34, [email protected] 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.
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.
On Thu, Feb 22, 2024 at 11:53 PM Chris Packham
<[email protected]> wrote:
> On 23/02/24 10:34, [email protected] 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).
> 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.
--
With Best Regards,
Andy Shevchenko
On 23/02/24 10:59, Andy Shevchenko wrote:
> On Thu, Feb 22, 2024 at 11:53 PM Chris Packham
> <[email protected]> wrote:
>> On 23/02/24 10:34, [email protected] 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.
>
On Fri, Feb 23, 2024 at 12:08 AM Chris Packham
<[email protected]> wrote:
> On 23/02/24 10:59, Andy Shevchenko wrote:
> > On Thu, Feb 22, 2024 at 11:53 PM Chris Packham
> > <[email protected]> wrote:
> >> On 23/02/24 10:34, [email protected] 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?
Probably not. we just need to consume GPIOs, no need to provide...
> 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>;
> };
> };
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.
> >> 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
--
With Best Regards,
Andy Shevchenko
Hi!
> > 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";
Please make it something like "generic,7-segment-on-gpio". I assume
there's a ton of similar display units.
BR,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
On 23/02/24 11:13, Andy Shevchenko wrote:
> On Fri, Feb 23, 2024 at 12:08 AM Chris Packham
> <[email protected]> wrote:
>> On 23/02/24 10:59, Andy Shevchenko wrote:
>>> On Thu, Feb 22, 2024 at 11:53 PM Chris Packham
>>> <[email protected]> wrote:
>>>> On 23/02/24 10:34, [email protected] 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?
> Probably not. we just need to consume GPIOs, no need to provide...
>
>> 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>;
>> };
>> };
> 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 = "generic,7-segment-on-gpio";
char-0 {
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>;
};
char-1 {
segment-gpios = <&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.
>
>>>> 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
Hi!
> > 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 = "generic,7-segment-on-gpio";
> ??????????????? char-0 {
> ??????????????? ??? 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>;
> ??????????????? };
> ??????????????? char-1 {
> ??????????????? ??? segment-gpios = <&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.
One solution would be to treat separate digits as separata devices
:-).
Other would be saying you don't have hardware for that, and make it
someone else's future problem.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
Hi Chris,
On Fri, Feb 23, 2024 at 4:46 AM Chris Packham
<[email protected]> wrote:
> On 23/02/24 11:13, Andy Shevchenko wrote:
> > On Fri, Feb 23, 2024 at 12:08 AM Chris Packham
> > <[email protected]> wrote:
> >> On 23/02/24 10:59, Andy Shevchenko wrote:
> >>> On Thu, Feb 22, 2024 at 11:53 PM Chris Packham
> >>> <[email protected]> wrote:
> >>>> On 23/02/24 10:34, [email protected] 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 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?
> > Probably not. we just need to consume GPIOs, no need to provide...
> >
> >> 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>;
> >> };
> >> };
> > 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 = "generic,7-segment-on-gpio";
gpio-7seg?
> char-0 {
> 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>;
> };
> char-1 {
> segment-gpios = <&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
--
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 Pavel,
On Fri, Feb 23, 2024 at 8:47 AM Pavel Machek <[email protected]> wrote:
> > > 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 = "generic,7-segment-on-gpio";
> > char-0 {
> > 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>;
> > };
> > char-1 {
> > segment-gpios = <&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.
>
> One solution would be to treat separate digits as separata devices
> :-).
That's definitely an option, but would prevent you from having a
single display using auxdisplay/line-display.
> Other would be saying you don't have hardware for that, and make it
> someone else's future problem.
;-)
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 Fri, Feb 23, 2024 at 9:52 AM Geert Uytterhoeven <[email protected]> wrote:
> On Fri, Feb 23, 2024 at 4:46 AM Chris Packham
> <[email protected]> wrote:
> > On 23/02/24 11:13, Andy Shevchenko wrote:
..
> > 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 = "generic,7-segment-on-gpio";
>
> gpio-7seg?
>
> > char-0 {
> > 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>;
> > };
> > char-1 {
> > segment-gpios = <&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.
For line display the sequence is the same as in DT, so I'm supporting
the idea of separate subnodes per digit. Note, that we can
theoretically have different displays to form the line, but it makes
things more complex if we ever want to support that combination.
> 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?
LED matrices are the displays (like tinyDRM is for).
--
With Best Regards,
Andy Shevchenko
Hi Andy,
On Fri, Feb 23, 2024 at 1:36 PM Andy Shevchenko
<[email protected]> wrote:
> On Fri, Feb 23, 2024 at 9:52 AM Geert Uytterhoeven <[email protected]> wrote:
> > 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?
>
> LED matrices are the displays (like tinyDRM is for).
TinyDRM is for rectangular matrices.
Multiple 7-segment displays are usually multiplexed using a matrix,
using 7 (or 8) lines shared by the corresponding segments of all
displays, and one common line per display.
https://embedded-lab.com/blog/wp-content/uploads/2011/03/Lab11_Circuit_SevenSegmentMultiplexing.jpg
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 Fri, Feb 23, 2024 at 3:01 PM Geert Uytterhoeven <[email protected]> wrote:
> On Fri, Feb 23, 2024 at 1:36 PM Andy Shevchenko
> <[email protected]> wrote:
> > On Fri, Feb 23, 2024 at 9:52 AM Geert Uytterhoeven <[email protected]> wrote:
> > > 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?
> >
> > LED matrices are the displays (like tinyDRM is for).
>
> TinyDRM is for rectangular matrices.
>
> Multiple 7-segment displays are usually multiplexed using a matrix,
> using 7 (or 8) lines shared by the corresponding segments of all
> displays, and one common line per display.
> https://embedded-lab.com/blog/wp-content/uploads/2011/03/Lab11_Circuit_SevenSegmentMultiplexing.jpg
Yes, that's what I call "dynamic" approach (in my translated
terminology, I dunno the proper English one). With this in mind, you
can read my message(s) above where I referred to it.
--
With Best Regards,
Andy Shevchenko
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.
> [1] - https://www.kingbrightusa.com/images/catalog/SPEC/SA36-11GWA.pdf
--
With Best Regards,
Andy Shevchenko
