mbox series

[v2,0/4] auxdisplay: 7 segment LED display

Message ID 20240227212244.262710-1-chris.packham@alliedtelesis.co.nz
Headers show
Series auxdisplay: 7 segment LED display | expand

Message

Chris Packham Feb. 27, 2024, 9:22 p.m. UTC
This series adds a driver for a 7 segment LED display.

At this point I've decided not to pursue supporting >1 character. I had
a look at what would be required to add a devm_fwnode_gpiod_get_array()
and got bogged down in OF and ACPI code for counting GPIOs.
--
[1] - https://lore.kernel.org/lkml/2a8d19ee-b18b-4b7c-869f-7d601cea30b6@alliedtelesis.co.nz/

Chris Packham (4):
  auxdisplay: Add 7 segment LED display driver
  dt-bindings: auxdisplay: Add bindings for generic 7 segment LED
  ARM: dts: marvell: Add 7 segment LED display on x530
  ARM: dts: marvell: Indicate USB activity on x530

 .../auxdisplay/generic-gpio-7seg.yaml         |  40 ++++++
 .../boot/dts/marvell/armada-385-atl-x530.dts  |  22 +++-
 drivers/auxdisplay/Kconfig                    |  10 ++
 drivers/auxdisplay/Makefile                   |   1 +
 drivers/auxdisplay/seg-led.c                  | 119 ++++++++++++++++++
 5 files changed, 191 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml
 create mode 100644 drivers/auxdisplay/seg-led.c

Comments

Chris Packham Feb. 28, 2024, 12:25 a.m. UTC | #1
On 28/02/24 13:05, Andy Shevchenko wrote:
> On Tue, Feb 27, 2024 at 11:22 PM Chris Packham
> <chris.packham@alliedtelesis.co.nz> wrote:
>> This series adds a driver for a 7 segment LED display.
>>
>> At this point I've decided not to pursue supporting >1 character. I had
>> a look at what would be required to add a devm_fwnode_gpiod_get_array()
>> and got bogged down in OF and ACPI code for counting GPIOs.
> Out of curiosity, why did it happen? gpiod_count() works in an agnostic way.
>
At first I though I could create a fwnode_gpiod_count() out of the body 
of gpiod_count(). But both of_gpio_get_count() and acpi_gpio_count() 
take the dev not the fwnode. It looks like gpiod_count() (and 
of_gpio_spi_cs_get_count()) could probably be re-written (or abstracted) 
to take the device_node instead of the device. I started looking at 
acpi_gpio_count() but I couldn't quite see how I could adapt this.

I'm definitely not saying it can't be done. Just that you probably don't 
want an occasional contributor like me messing with some of these core 
device abstractions.
Andy Shevchenko Feb. 28, 2024, 6:45 p.m. UTC | #2
On Wed, Feb 28, 2024 at 12:25:30AM +0000, Chris Packham wrote:
> 
> On 28/02/24 13:05, Andy Shevchenko wrote:
> > On Tue, Feb 27, 2024 at 11:22 PM Chris Packham
> > <chris.packham@alliedtelesis.co.nz> wrote:
> >> This series adds a driver for a 7 segment LED display.
> >>
> >> At this point I've decided not to pursue supporting >1 character. I had
> >> a look at what would be required to add a devm_fwnode_gpiod_get_array()
> >> and got bogged down in OF and ACPI code for counting GPIOs.
> > Out of curiosity, why did it happen? gpiod_count() works in an agnostic way.
> >
> At first I though I could create a fwnode_gpiod_count() out of the body 
> of gpiod_count(). But both of_gpio_get_count() and acpi_gpio_count() 
> take the dev not the fwnode. It looks like gpiod_count() (and 
> of_gpio_spi_cs_get_count()) could probably be re-written (or abstracted) 
> to take the device_node instead of the device. I started looking at 
> acpi_gpio_count() but I couldn't quite see how I could adapt this.
> 
> I'm definitely not saying it can't be done. Just that you probably don't 
> want an occasional contributor like me messing with some of these core 
> device abstractions.

I just sent a series. With it you may split gpiod_count() to
fwnode_gpio_count() and gpiod_count() that uses the former.
I believe you may do that easily as it won't require any special
knowledge.