Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: linux-realtek-soc@lists.infradead.org,
	linux-leds@vger.kernel.org, linux-rtc@vger.kernel.org,
	Alessandro Zummo <a.zummo@towertech.it>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	csd@princeton.com.tw, devicetree@vger.kernel.org,
	sales@fdhisi.com, Mark Brown <broonie@kernel.org>,
	linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org,
	Rob Herring <robh+dt@kernel.org>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>,
	zypeng@titanmec.com, linux-amlogic@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, Dan Murphy <dmurphy@ti.com>,
	linux-rockchip@lists.infradead.org
Subject: Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers
Date: Thu, 12 Dec 2019 21:55:17 +0100
Message-ID: <c86c6bc0-b0e5-c46e-da87-9d910b95f9f3@suse.de> (raw)
In-Reply-To: <7110806f-ddbd-f055-e107-7a1f7e223102@arm.com>

Hi Robin,

[- Roc He, + linux-rockchip]

Am 12.12.19 um 14:14 schrieb Robin Murphy:
> On 12/12/2019 3:39 am, Andreas Färber wrote:
>> This patch series implements the LED controllers found in some RTD1295
>> based
>> TV set-top boxes.
[...]
>> TM1628 and related chipsets have an internal Display RAM, from which they
>> control a two-dimensional array of LED components, often used for
>> seven-segment displays, i.e. clock display, but also for indicators.
>> Individual LEDs can be turned on/off, but brightness is applied globally.
>> Some chipsets also support polling a two-dimensional key pad.
[...]
>> Some more notes:
>> * Public TM1628 V1.1 datasheet is in Chinese only and differs from the
>>    unversioned English version found elsewhere on datasheet sites by
>>    documenting more display modes, included here (guessed from Arabic
>> numbers).
>> * Public FD628 datasheet is Chinese only (guesses based on Arabic
>> numbers).
>>    FD623 appears to have more output lines, which would fit current
>> data types.
>> * AiP1618 links were all broken (404); try Google "site:szfdwdz.com"
>> search
>>    to actually find the documents available on their site.
>> * Princeton PT6964 is another related LED controller with public
>> datasheet
>>    that I did not encounter in my TV boxes yet, thus not included here.
>>    Datasheets are linked only for PT6959 and PT6967, but PT6964 V1.3
>> and V1.4
>>    are available elsewhere. PT6967 has more output lines, which my
>> current
>>    data types could barely hold. Maybe bump them all to u32 type right
>> away?
>> * TM1628 is also found on MeLE V9 TV box, to be tested.
>> * FD628 is also found on Amlogic S905X2 based Vontar X96 Max TV box,
>>    to be tested (once UART is soldered).
>> * AiP1618 was found on Ava and Lake I TV boxes, to be tested.
>> * It remained unclear to me which of these many similar chipsets was
>> first.
>>    My driver name is therefore based on the chip I encountered first.
> 
> It's pretty cool to see this!

Glad someone else finds it useful. :)

> My Rockchip box has an AiP1618-driven
> display [...]

You don't mention the model: Does it have a mainline .dts we can extend?
If not, I'd ask you to get that merged into -next, then I can happily
pick up patches adding the LED controller for your TV box into this
series as it evolves. (I'm expecting at least two more RFC iterations.)

Similarly, I'm planning to drop Xnano X5 in v2, if it doesn't require a
respin, so that no Realtek-specific parts other than .dts node additions
remain here.

> In case it helps, in my research I found that ARTSCHIP are another
> vendor of these things with accessible datasheets[1],

Thanks, their HT1628 indeed looks compatible.

Sunmoon Microelectronics SM1628 also looks compatible.
http://www.chinaasic.com/product.jsp#item=other#style=27#id=138

> and as far as I
> could tell the command set appears to derive from (or is at least common
> to) some old Holtek VFD controllers.

Hmm, HT16515 looks similar and has more lines, RAM and mode bits than I
prepared here.
https://www.holtek.com/productdetail/-/vg/ht16515

So I'd need to make more numbers model-dependent and allocate the
Display RAM buffer dynamically.

Whereas HT16D35A seems incompatible command-wise, and HT16528 appears to
be out of scope, for dot displays and with fancy embedded character map.

No Holtek email alias that I can quickly spot.

But given that I'm proposing vendor-specific compatibles just in case,
the main decisions will be the Kconfig symbol and module name. The
driver code itself we could always refactor after merging, and renaming
the schema file (as opposed to compatible) should also be possible.

> If I can figure out the DT parts (which was one of the areas that
> stalled my attempt) I'll try to have a play with this series over the
> holidays.

That reminded me that I forgot to push - done in the meantime. :)

> One thought to ponder is that I have an "88:88" display where
> the entire middle grid is reserved for the colon (which is wired to just
> one segment) - I'm not sure how that could be sanely described :/

Well, that sounds exactly like my bindings example and X9S. You'll find
the colon configured as LED, separate from the four digits, which don't
need to be contiguous due to separate reg entries per digit.

While it may be possible to put more cleverness into text_store() to set
the colon as part of five-char "88:88" text, we'd likely want to blink
it every half second, which we should better do without updating the
full display text from "88:88" to "88 88". "8888" updated every minute
sounds less problematic.

Ugly with the colon LED is that the redone LED bindings don't yet have a
function defined for this, so I'm currently misusing whatever was there.
I should prepare a bindings addition, if we want to use an LED node.

Regards,
Andreas

> [1]
> http://www.artschip.com/products.asp?lx=small&anid=779&ParentName=Signal%20management%20_I_O%20Extender
> 
>> This series is based on my not-yet-posted RTD1295 pinctrl and GPIO
>> drivers.
>>
>> Latest experimental patches at:
>> https://github.com/afaerber/linux/commits/rtd1295-next
[snip]

-- 
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 [this message]
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=c86c6bc0-b0e5-c46e-da87-9d910b95f9f3@suse.de \
    --to=afaerber@suse.de \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=broonie@kernel.org \
    --cc=csd@princeton.com.tw \
    --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-rockchip@lists.infradead.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sales@fdhisi.com \
    --cc=zypeng@titanmec.com \
    /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