From: "Andreas Färber" <afaerber@suse.de>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Dan Murphy <dmurphy@ti.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Pavel Machek <pavel@ucw.cz>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
linux-realtek-soc@lists.infradead.org
Subject: Re: [RFC 22/25] leds: tm1826: Add combined glyph support
Date: Sun, 22 Dec 2019 04:14:12 +0100 [thread overview]
Message-ID: <56f7cd23-2156-a6e4-15fe-3efd5ccf851b@suse.de> (raw)
In-Reply-To: <CANiq72nA9OLa0SjY8W055J_2A32tcp7S98SruKSdWH2dm25VKw@mail.gmail.com>
Hi Miguel,
Am 22.12.19 um 00:12 schrieb Miguel Ojeda:
> On Sat, 21 Dec 2019 at 22:49 Andreas Färber <afaerber@suse.de
> <mailto:afaerber@suse.de>> wrote:
>
> Hi,
>
> Am 21.12.19 um 22:04 schrieb Pavel Machek:
> >>>> Allow to squeeze the text "HEllO" into a 4-digit display,
> >>>> as seen on MeLE V9 TV box.
> >>>>
> >>>> Enable this combining mode only if the text would overflow.
> >>>
> >>> "HEll,nO"!
> >>>
> >>> :-)
> >>>
> >>> Ok, it is kind of cool, but... Can you take a look at
> >>> drivers/auxdisplay/charlcd.c ? It seems to support some kind of
> text
> >>> displays...
> >>
> >> Why don't you look at it before making such a suggestion? ;) It
> is in no way
> >> useful, as I pointed out in my cover letter. The only thing
> related today,
> >> as Geert pointed out, is in the input subsystem.
> >
> > Okay, so maybe we should get
> >
> > AUXILIARY DISPLAY DRIVERS
> > M: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com
> <mailto:miguel.ojeda.sandonis@gmail.com>>
> >
> > on the Cc: list?
>
> Let's see if that email still exists - the code looked ancient, full of
> platform_data and driver-specific exported functions...
>
> (the Yealink input driver was from 2005, too)
>
>
> The code may look ancient, but the email surely exists ;)
>
>
>
> > What you really have is a display, not a bunch of LEDs.
>
> We have an LED Controller connected to zero, one or more displays.
> They are most certainly _not_ the same thing.
>
> >> If you don't want this in leds, you'll have to help make leds
> subsystem more
> >> useful to external users - the latest function refactoring has
> been anything
> >> but helpful here, as you've seen with the indicators, and we're
> completely
> >> lacking any indexing or bulk operations on the LED controller
> level, since
> >> you treat each LED as a standalone device. That's precisely why
> this code is
> >> here in leds although - as I pointed out - it shouldn't belong here.
> >
> > Well, your introduction mail was kind of long :-).
> >
> > If someone wants to do heartbeat on
> >
> > --
> > | | <- this segment
> > --
> > | |
> > --
> >
> > they are probably crazy. We may not want to support that. What about
> > doing it as auxdisplay driver, and then exporting the indicators
> > around that as LEDs?
>
> You're really just discussing which directory to put this file into -
> moving it around is the easiest thing...
>
> >
> > Having USB activity trigger on 'USB' icon makes sense, on the other
> > hand. That would still be supported.
>
> Actually I disagree about those indicators - that was the reason
> they're
> indicators and not, e.g., "usb". IMO people would go crazy if large
> text
> like that blinked during USB transfers. I assumed the meaning of those
> LEDs were to indicate whether a USB/SD medium is connected, which I did
> not see any better function for, and I'm not aware of us having such
> triggers today.
>
> Maybe you also overread that with trigger I was referring to using RTC
> as trigger for a) the colon blinking every half-second and b) the text
> getting updated based on avsilable RTC interrupts?
>
> You could also think of GPIO-connected LEDs that you may want to
> animate
> without two different heartbeats/timers getting out of sync. Or
> think of
> an RGB LED that today we sadly need to model as multiple GPIO LEDs
> instead of as one with a color property we can change (and hardcoding a
> color in DT/name is not helping that use case either).
>
> auxdisplay offers no API that I could register with to drive output,
> nor
> any triggers to automate such output - that's unique to LEDs. Like I
> said, we can place this spi_driver file into auxdisplay/, but that
> doesn't solve the driver design.
>
>
> I think it would be alright to put it in auxdisplay.
Please find the full series on, e.g., LAKML:
https://patchwork.kernel.org/cover/11286939/
> So I really think we need to decouple
> the two and keep the LED Controller driver in leds and the display
> logic
> elsewhere, with suitable new APIs to connect them. We're lacking
> suggestions for the how, on DT and API levels - see my response on
> [...]the
> cover letter.
As explained in the cover letter, the problem here is that I don't know
the model or manufacturer of these unmarked white-plastic-frame LED
displays. So we have neither a filename to use in auxdisplay/ nor a DT
compatible string to use for those displays.
Cheers,
Andreas
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
next prev parent reply other threads:[~2019-12-22 3:14 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-12 3:39 [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers Andreas Färber
2019-12-12 3:39 ` [RFC 01/25] dt-bindings: vendor-prefixes: Add Xnano Andreas Färber
2019-12-19 22:26 ` Rob Herring
2019-12-12 3:39 ` [RFC 02/25] dt-bindings: arm: realtek: Add Xnano X5 Andreas Färber
2019-12-19 22:27 ` Rob Herring
2019-12-12 3:39 ` [RFC 03/25] arm64: dts: realtek: rtd1295: " Andreas Färber
2019-12-12 3:39 ` [RFC 04/25] spi: gpio: Implement LSB First bitbang support Andreas Färber
2019-12-12 8:40 ` Geert Uytterhoeven
2019-12-12 15:14 ` Andreas Färber
2019-12-12 17:19 ` Mark Brown
2019-12-12 21:08 ` Andreas Färber
2019-12-13 11:42 ` Mark Brown
2019-12-12 3:39 ` [RFC 05/25] dt-bindings: vendor-prefixes: Add Titan Micro Electronics Andreas Färber
2019-12-19 22:31 ` Rob Herring
2019-12-12 3:39 ` [RFC 06/25] dt-bindings: leds: Add Titan Micro Electronics TM1628 Andreas Färber
2019-12-19 23:04 ` Rob Herring
2019-12-12 3:39 ` [RFC 07/25] " Andreas Färber
2019-12-14 9:48 ` Andreas Färber
2019-12-12 3:39 ` [RFC 08/25] arm64: dts: realtek: rtd129x-zidoo-x9s: Add TM1628 LED controller Andreas Färber
2019-12-12 3:39 ` [RFC 09/25] arm64: dts: realtek: rtd1295-zidoo-x9s: Add regular LEDs to TM1628 Andreas Färber
2019-12-12 3:39 ` [RFC 10/25] dt-bindings: vendor-prefixes: Add Fuda Hisi Microelectronics Andreas Färber
2019-12-19 23:04 ` Rob Herring
2019-12-12 3:39 ` [RFC 11/25] dt-bindings: leds: tm1628: Add Fuda Hisi Microelectronics FD628 Andreas Färber
2019-12-19 23:05 ` Rob Herring
2019-12-12 3:39 ` [RFC 12/25] " Andreas Färber
2019-12-12 3:39 ` [RFC 13/25] arm64: dts: realtek: rtd1295-xnano-x5: Add FD628 LED controller Andreas Färber
2019-12-12 3:39 ` [RFC 14/25] arm64: dts: realtek: rtd1295-xnano-x5: Add regular LEDs to FD628 Andreas Färber
2019-12-21 20:21 ` Pavel Machek
2019-12-12 3:39 ` [RFC 15/25] dt-bindings: vendor-prefixes: Add Fude Microelectronics Andreas Färber
2019-12-19 23:05 ` Rob Herring
2019-12-12 3:39 ` [RFC 16/25] dt-bindings: leds: tm1628: Add Fude Microelectronics AiP1618 Andreas Färber
2019-12-19 23:06 ` Rob Herring
2019-12-12 3:39 ` [RFC 17/25] leds: tm1628: Prepare " Andreas Färber
2019-12-21 19:55 ` Andreas Färber
2019-12-12 3:39 ` [RFC 18/25] dt-bindings: leds: tm1628: Define display child nodes Andreas Färber
2019-12-12 3:39 ` [RFC 19/25] leds: tm1628: Add 7-segment display support Andreas Färber
2019-12-12 8:33 ` Geert Uytterhoeven
2019-12-12 14:10 ` Andreas Färber
2019-12-21 20:23 ` Pavel Machek
2019-12-12 3:39 ` [RFC 20/25] arm64: dts: realtek: rtd1295-zidoo-x9s: Add display to TM1628 Andreas Färber
2019-12-12 3:39 ` [RFC 21/25] arm64: dts: realtek: rtd1295-xnano-x5: Add display to FD628 Andreas Färber
2019-12-12 3:39 ` [RFC 22/25] leds: tm1826: Add combined glyph support Andreas Färber
2019-12-21 20:27 ` Pavel Machek
2019-12-21 20:41 ` Andreas Färber
2019-12-21 21:04 ` Pavel Machek
2019-12-21 21:49 ` Andreas Färber
[not found] ` <CANiq72nA9OLa0SjY8W055J_2A32tcp7S98SruKSdWH2dm25VKw@mail.gmail.com>
2019-12-22 3:14 ` Andreas Färber [this message]
2020-01-15 14:31 ` Miguel Ojeda
2019-12-12 3:39 ` [RFC 23/25] WIP: leds: tm1628: Prepare TM1628 keys Andreas Färber
2019-12-12 3:39 ` [RFC 24/25] WIP: leds: tm1628: Prepare FD628 keys Andreas Färber
2019-12-12 3:39 ` [RFC 25/25] WIP: leds: tm1628: Prepare AiP1618 keys Andreas Färber
2019-12-12 13:14 ` [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers Robin Murphy
2019-12-12 20:55 ` Andreas Färber
2019-12-13 14:07 ` Robin Murphy
2019-12-13 14:36 ` Geert Uytterhoeven
2020-02-25 21:42 ` Ezra Buehler
2020-02-26 13:03 ` Pavel Machek
2019-12-21 18:20 ` Pavel Machek
2019-12-21 21:07 ` Andreas Färber
2020-01-15 13:34 ` Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56f7cd23-2156-a6e4-15fe-3efd5ccf851b@suse.de \
--to=afaerber@suse.de \
--cc=dmurphy@ti.com \
--cc=geert@linux-m68k.org \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-realtek-soc@lists.infradead.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).