Received-SPF: pass (google.com: domain of linux-kernel+bounces-83276-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240225213423.690561-1-chris.packham@alliedtelesis.co.nz>
 <20240226-scabby-fiber-87d5d6e45028@thorsis.com> <fd1c8657-62e6-449c-b47f-a2c3223b405c@alliedtelesis.co.nz>
 <20240227-married-amulet-da532c0a70d3@thorsis.com>
In-Reply-To: <20240227-married-amulet-da532c0a70d3@thorsis.com>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Tue, 27 Feb 2024 15:00:58 +0200
Message-ID: <CAHp75Vd3aza1192YpRHvi6y7oEsrAoYA3+Qcja7Fw22c9+xhRQ@mail.gmail.com>
Subject: Re: [PATCH 0/3] auxdisplay: 7 segment LED display
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>, 
	"ojeda@kernel.org" <ojeda@kernel.org>, "robh+dt@kernel.org" <robh+dt@kernel.org>, 
	"krzysztof.kozlowski+dt@linaro.org" <krzysztof.kozlowski+dt@linaro.org>, 
	"conor+dt@kernel.org" <conor+dt@kernel.org>, "andrew@lunn.ch" <andrew@lunn.ch>, 
	"gregory.clement@bootlin.com" <gregory.clement@bootlin.com>, 
	"sebastian.hesselbarth@gmail.com" <sebastian.hesselbarth@gmail.com>, 
	"andy.shevchenko@gmail.com" <andy.shevchenko@gmail.com>, "geert@linux-m68k.org" <geert@linux-m68k.org>, 
	"pavel@ucw.cz" <pavel@ucw.cz>, "lee@kernel.org" <lee@kernel.org>, 
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
	"linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, 
	"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 27, 2024 at 10:43=E2=80=AFAM Alexander Dahl <ada@thorsis.com> w=
rote:
> Am Mon, Feb 26, 2024 at 08:10:07PM +0000 schrieb Chris Packham:
> > On 27/02/24 05:04, Alexander Dahl wrote:
> > > Am Mon, Feb 26, 2024 at 10:34:20AM +1300 schrieb Chris Packham:
> > >> This series adds a driver for a 7 segment LED display.
> > >>
> > >> I'd like to get some feedback on how this could be extended to suppo=
rt >1
> > >> character. The driver as presented is sufficient for my hardware whi=
ch only has
> > >> a single character display but I can see that for this to be generic=
ally useful
> > >> supporting more characters would be desireable.
> > >>
> > >> Earlier I posted an idea that the characters could be represended by
> > >> sub-nodes[1] but there doesn't seem to be a way of having that and k=
eeping the
> > >> convenience of using devm_gpiod_get_array() (unless I've missed some=
thing).
> > >>
> > >> [1] - https://scanmail.trustwave.com/?c=3D20988&d=3Dtrbc5eARVo-5gepR=
nwbAKbQmiGk1bOSpqZDQx9bx7w&u=3Dhttps%3a%2f%2flore%2ekernel%2eorg%2flkml%2f2=
a8d19ee-b18b-4b7c-869f-7d601cea30b6%40alliedtelesis%2eco%2enz%2f
> > > Read that thread out of curiosity and I'm sorry if I'm late to the
> > > party, but I wondered why this is limited to LEDs connected to GPIOs?
> > >
> > > Would it be possible to somehow stack this on top of some existing
> > > LEDs?  I mean you could wire a 7 segment device to almost any LED
> > > driver IC with enough channels, couldn't you?
> >
> > Mainly because the GPIO version is the hardware I have. I do wonder how
> > this might work with something like the pca9551 which really is just a
> > fancy version of the pca9554 on my board. A naive implementation would
> > be to configure all the pca9551 pins as GPIOs and use what I have as-is=
.
>
> My idea was to do it on top of the LED abstraction, not on top of the
> GPIO abstraction.  Currently you are using the GPIO consumer interface
> and group 7 gpios which are supplied by that pca9554 in your case, but
> could also be coming from a SoC or a 74hc595 etc.
>
> Why not put it a level of abstraction higher, and let it consume LEDs
> instead of GPIOs?  Your usecase would still be possible then.
>
> As far as I could see the concept of a LED consumer can be done, the
> leds-group-multicolor driver in
> drivers/leds/rgb/leds-group-multicolor.c does that, introduced with
> kernel v6.6 not so long ago.  It sets the sysfs entries of the LEDs
> part of the group to readonly so they are not usable on their own
> anymore and one would not disturb the grouped multicolor LED.
>
> This would allow to use LEDs as a 7 segment group driven by any LED
> driver including leds-gpio.

7-segment LEDs are not just a bunch of leds, they have explicit
meaning and using LED infrastructure is an obscuration of what's going
on (too many unrelated details are exposed, too hard to achieve what
user needs). In the auxdisplay we have already the concept of "line
display" with a 7-segment, or 14 (that are two main standards) with
respective character mapping in case somebody wants to print more than
hexadecimal digits on them. If I am mistaken, I would like to see the
concept in the example here on how user space will take care of
displaying (an arbitrary) data. Can you provide a draft of (user-side)
documentation before we even start going this direction?

> > Making a line display out of LED triggers might be another way of doing
> > it but not something I really want to pursue.
>
> Fair enough.  I just wanted to share my idea.  Didn't want to pressure
> you in any direction. :-)


--=20
With Best Regards,
Andy Shevchenko