[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zdy_DRAJaHXY7xov@smile.fi.intel.com>
Date: Mon, 26 Feb 2024 18:40:45 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Chris Packham <chris.packham@...iedtelesis.co.nz>
Cc: ojeda@...nel.org, robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
conor+dt@...nel.org, andrew@...n.ch, gregory.clement@...tlin.com,
sebastian.hesselbarth@...il.com, geert@...ux-m68k.org, pavel@....cz,
lee@...nel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-leds@...r.kernel.org
Subject: Re: [PATCH 0/3] auxdisplay: 7 segment LED display
On Mon, Feb 26, 2024 at 04:23:15AM +0200, Andy Shevchenko wrote:
> On Sun, Feb 25, 2024 at 11:34 PM Chris Packham
> <chris.packham@...iedtelesis.co.nz> wrote:
> >
> > 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 support >1
> > character. The driver as presented is sufficient for my hardware which only has
> > a single character display but I can see that for this to be generically 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 keeping the
> > convenience of using devm_gpiod_get_array() (unless I've missed something).
>
> It seems you didn't know that the tree for auxdisplay has been changed.
> Can you rebase your stuff on top of
> https://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay.git/log/?h=for-next?
> It will reduce your code base by ~50%.
I have just updated the branch so it adds one patch that changes the prototype
of linedisp_register().
> WRT subnodes, you can go with device_for_each_child_node() and
> retrieve gpio array per digit. It means you will have an array of
> arrays of GPIOs.
Btw, as Geert proposed for another 7-segment driver, we might gain from the
display-width-chars property. But I think this property has to be parsed on
top of line display library, no need to have it in each affected driver.
> > [1] - https://lore.kernel.org/lkml/2a8d19ee-b18b-4b7c-869f-7d601cea30b6@alliedtelesis.co.nz/
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists