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-rtc@vger.kernel.org,
	Alessandro Zummo <a.zummo@towertech.it>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	linux-realtek-soc@lists.infradead.org,
	Mark Brown <broonie@kernel.org>,
	linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org,
	devicetree@vger.kernel.org, Rob Herring <robh@kernel.org>,
	Dan Murphy <dmurphy@ti.com>,
	linux-leds@vger.kernel.org, linux-amlogic@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>
Subject: Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers
Date: Sat, 21 Dec 2019 22:07:44 +0100
Message-ID: <e26f985b-ceca-ca2c-a709-e7dc40c7fdd1@suse.de> (raw)
In-Reply-To: <20191221182057.GA32732@amd>

Hi Pavel,

[- Roc He, - chipset vendors]

Am 21.12.19 um 19:20 schrieb Pavel Machek:
>> It goes on to add a "text" attribute to the driver that enables DT-configured
>> seven-segment displays; I was expecting to find precedence in auxdisplay
>> subsystem but came up empty. So my driver currently integrates its own
>> generic (but incomplete) character-to-8-segments mapping, as well as in a
>> second step a combined-characters-to-8-segments mapping, which then gets
>> mapped to the chipset's available output lines. Doing this as sysfs
>> device
> 
> I did not investigate this in great detail; but if it is displaying
> characters, auxdisplay is probably right subsystem to handle that.

ausdisplay does not have any common API AFAICS. Most of them are 
high-level displays with some parallel interface to set text and 
metadata. Half of them hardcode the text to Linux or maybe offer a 
Kconfig option to override it; the other half implements their own 
character device file with ABI specific to that driver.

> I
> guess LEDs can still take the low-level parts...

I'd hope so, but I believe we're missing multiple things there:

1) A bulk-update API for setting multiple LEDs at once. 
.brightness_set[_blocking]() is all we have on the device side, which 
here results in two SPI commands. led_set_brightness[_sync]() is all I 
see on the API side. We'd need an API that takes an array of LEDs and 
brightness values and allows a common driver rather than individual 
devices to update the Display RAM via SPI from an internal buffer.

2) DT is currently limited to one node per LED device. We'd need 
#led-cells, with current LED nodes defaulting to zero. That way we could 
address LEDs from an external, e.g., auxdisplay driver via a two-cell 
index for these LED controllers, without needing to have DT nodes for 
each and every display segment.

3) Better LED device names. More "function" values, or a reversal of the 
label deprecation. Or an alternative API to register LEDs with manual name.

4) LED triggers controlling more than one LED. linux,default-trigger 
seems to assign one per LED, so that two heartbeats are quickly out of 
sync. Doing it from code would probably be simpler than finding a way to 
model this in DT, but I don't yet see how.

Alternatively we could expose those LED output lines as a gpiochip, 
which we can already index in DT, and consider the display GPIO-based, 
but then we're in the situation again that GregKH was telling people to 
either go screw themselves in userspace or move things into leds, which 
now you're against.

Also, if you don't allow displays in leds, then we can't have LED 
triggers for them either.

> 
> Oh, and common dimming for many LEDs is seen on other hardware, too
> (Turris routers). Not sure how to handle that, either :-(.

That part I have indeed successfully solved with a backlight device.

My current problem (WIP blocking a push) is the key input handling - not 
sure how to model both LEDs and keys as DT child nodes - do we need a 
compatible to distinguish between them? Unit addresses and reg values 
would be in different ranges, making this awkward, not to mention the 
problem of naming a compatible, given the incredible diverse chipsets.

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 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
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 [this message]
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=e26f985b-ceca-ca2c-a709-e7dc40c7fdd1@suse.de \
    --to=afaerber@suse.de \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-amlogic@lists.infradead.org \
    --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=linux-rtc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=robh@kernel.org \
    /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