Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-realtek-soc@lists.infradead.org,
	linux-leds@vger.kernel.org,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Dan Murphy <dmurphy@ti.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com>
Subject: Re: [RFC 22/25] leds: tm1826: Add combined glyph support
Date: Sat, 21 Dec 2019 22:49:09 +0100
Message-ID: <1b3fc7f2-3c10-9b11-37ac-1bc7b0aa47d8@suse.de> (raw)
In-Reply-To: <20191221210406.GA13125@amd>

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>
> 
> 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)

> 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. 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.

Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

  reply index

Thread overview: 58+ 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 [this message]
     [not found]           ` <CANiq72nA9OLa0SjY8W055J_2A32tcp7S98SruKSdWH2dm25VKw@mail.gmail.com>
2019-12-22  3:14             ` Andreas Färber
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
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=1b3fc7f2-3c10-9b11-37ac-1bc7b0aa47d8@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