Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
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
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)

  parent reply index

Thread overview: 59+ 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
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 publically 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

Linux-LEDs Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-leds/0 linux-leds/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-leds linux-leds/ https://lore.kernel.org/linux-leds \
		linux-leds@vger.kernel.org
	public-inbox-index linux-leds

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-leds


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git