From: "Andreas Färber" <email@example.com> To: firstname.lastname@example.org, email@example.com Cc: "Jacek Anaszewski" <firstname.lastname@example.org>, "Pavel Machek" <email@example.com>, "Dan Murphy" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, "Andreas Färber" <email@example.com>, firstname.lastname@example.org, "Alessandro Zummo" <email@example.com>, "Alexandre Belloni" <firstname.lastname@example.org>, email@example.com, "Rob Herring" <firstname.lastname@example.org>, email@example.com, "Mark Brown" <firstname.lastname@example.org>, email@example.com, "Roc He" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com Subject: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers Date: Thu, 12 Dec 2019 04:39:27 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) Hello, This patch series implements the LED controllers found in some RTD1295 based TV set-top boxes. Ever since I've had mainline Linux kernels booting on my Zidoo X9S TV box, it's been bugging me that it kept displaying "boot" on its front display. A hot lead was a TM1628 chip on the front display's daughterboard, which English and Chinese datasheets were available for. The biggest hurdle to overcome was whether and how this chip was connected to the SoC. Confusingly the datasheet talks about "Serial Interface" and shows pins DIO, SCLK and STB; whereas neither UART nor SPI DT nodes seemed to be in use for this, no mention of such chipset in the binary vendor DT, and only one seemingly unrelated exported GPIO. Sadly Zidoo have refused to share GPL sourcecode with me, and the public GPL code drops from NAS and SBC vendors didn't seem to include drivers for this chip. Last weekend, review of vendor DT pinctrl nodes revealed a "spi@1" pinctrl node in use by the pinctrl node itself, despite there being only one GSPI block on the SoC. debugfs under Android revealed GPIO pins named "fp_stb", "fp_data" and "fp_clk" (on X5: 3x "vfdtest", unhelpfully). So I hereby present my first 3-wire SPI slave, using standard spi-gpio driver. This required to extend the spi-gpio driver with Little Endian support. 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. This initial RFC implements a SPI slave driver within Linux leds subsystem and lets DT expose individual LED components as two-state LEDs, allowing to assign standard Linux LED triggers and to control them via sysfs. 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 attribute had the advantage of being able to test it quickly; it also leaves timezone management to userspace and lets it choose between wall clock and playback time as needed. LED triggers appeared to be per-LED; otherwise an RTC-implemented interrupt based LED trigger would've been nice for RTD1195+, since my pending irqchip driver exposes interrupts down to half-second that would seem ideal for accurately driving such a display, with blinking colon. Finally, it sketches how keypad handling could be integrated into the leds driver, but I am lacking a test case for that functionality. Distinguishing LEDs and key inputs in DT may get difficult... For brightness control I am still investigating the backlight API and defaulting to the chipset's default (lowest) brightness. Prepended is a new DT for Xnano X5 OTT TV Box, featuring an FD628 display. Displays connected to these controllers didn't have any model or vendor usually, and for the lengthy numbers from my X9S, Google found no hits. Therefore I've been unable to come up with compatible strings for those displays and need to configure it per .dts, even though some may be using the same, e.g., "88:88" type display model. Whereas the same display might be connected to different LED controllers, thus is orthogonal to the controller's compatible string. Another aspect here is that the leds binding expects to have child nodes per LED directly on the LED controller node. So I've gone to lengths to shoehorn my display child node into that scheme via wildcard reg property. The alternative would be to define some special child node, as done for the SPI controller's "slave" node, to use as display. But in theory there might be multiple displays connected to one controller (which is neglected here). And in theory the same display might be wired up differently, so at most the display model could tell us about layout and availability of LEDs, but we'd still need a mapping from the LED controller's to the display's pins. So far neither of the two displays tested actually use the segment lines for the segments, but rather switch segment and grid lines. So in theory we might consider the display as LED controller and implement binding/driver on that level (moving it to DT root node like gpio-leds), if we can hook it up to the actual LED controller in this case on SPI bus? Assuming we can actually identify the display with some compatible string, that is. However, update efficiency has been a concern, with clock display in mind. Thus, forcing two SPI commands (three SPI transfers) per LED segment, as the the current LED API would entail, should better be avoided. This led to the current design of having everything in tm1628 driver, so that we can easily determine the scope of an update operation there (one per LED; all for text, to be optimized through bit field of dirtied bytes). Locking is completely missing still. We'll need at least a mutex to avoid, e.g., a heartbeat LED trigger and a text update conflicting on SPI bus or "hazards" becoming visible on the display during conflicting byte updates. Module remove support is missing, too. We may also need to revisit my error checking and either inline functions or drop checks on the LED bit level, if it becomes a performance bottleneck. On the cosmetic side, some lines are still beyond 80 characters. 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. 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 Have a lot of fun! Cheers, Andreas Cc: email@example.com Cc: Jacek Anaszewski <firstname.lastname@example.org> Cc: Pavel Machek <email@example.com> Cc: Dan Murphy <firstname.lastname@example.org> Cc: email@example.com Cc: Alessandro Zummo <firstname.lastname@example.org> Cc: Alexandre Belloni <email@example.com> Cc: firstname.lastname@example.org Cc: Rob Herring <email@example.com> Cc: firstname.lastname@example.org Cc: Mark Brown <email@example.com> Cc: firstname.lastname@example.org Cc: Roc He <email@example.com> # No email for Xnano Cc: firstname.lastname@example.org Cc: email@example.com # No email for szfdwdz.com Cc: firstname.lastname@example.org Andreas Färber (25): dt-bindings: vendor-prefixes: Add Xnano dt-bindings: arm: realtek: Add Xnano X5 arm64: dts: realtek: rtd1295: Add Xnano X5 spi: gpio: Implement LSB First bitbang support dt-bindings: vendor-prefixes: Add Titan Micro Electronics dt-bindings: leds: Add Titan Micro Electronics TM1628 leds: Add Titan Micro Electronics TM1628 arm64: dts: realtek: rtd129x-zidoo-x9s: Add TM1628 LED controller arm64: dts: realtek: rtd1295-zidoo-x9s: Add regular LEDs to TM1628 dt-bindings: vendor-prefixes: Add Fuda Hisi Microelectronics dt-bindings: leds: tm1628: Add Fuda Hisi Microelectronics FD628 leds: tm1628: Add Fuda Hisi Microelectronics FD628 arm64: dts: realtek: rtd1295-xnano-x5: Add FD628 LED controller arm64: dts: realtek: rtd1295-xnano-x5: Add regular LEDs to FD628 dt-bindings: vendor-prefixes: Add Fude Microelectronics dt-bindings: leds: tm1628: Add Fude Microelectronics AiP1618 leds: tm1628: Prepare Fude Microelectronics AiP1618 dt-bindings: leds: tm1628: Define display child nodes leds: tm1628: Add 7-segment display support arm64: dts: realtek: rtd1295-zidoo-x9s: Add display to TM1628 arm64: dts: realtek: rtd1295-xnano-x5: Add display to FD628 leds: tm1826: Add combined glyph support WIP: leds: tm1628: Prepare TM1628 keys WIP: leds: tm1628: Prepare FD628 keys WIP: leds: tm1628: Prepare AiP1618 keys Documentation/devicetree/bindings/arm/realtek.yaml | 1 + .../devicetree/bindings/leds/titanmec,tm1628.yaml | 134 ++++ .../devicetree/bindings/vendor-prefixes.yaml | 8 + arch/arm64/boot/dts/realtek/Makefile | 1 + arch/arm64/boot/dts/realtek/rtd1295-xnano-x5.dts | 108 +++ arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts | 36 +- drivers/leds/Kconfig | 12 + drivers/leds/Makefile | 1 + drivers/leds/leds-tm1628.c | 727 +++++++++++++++++++++ drivers/spi/spi-bitbang-txrx.h | 68 +- drivers/spi/spi-gpio.c | 42 +- 11 files changed, 1126 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/titanmec,tm1628.yaml create mode 100644 arch/arm64/boot/dts/realtek/rtd1295-xnano-x5.dts create mode 100644 drivers/leds/leds-tm1628.c -- 2.16.4
next reply other threads:[~2019-12-12 3:40 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-12 3:39 Andreas Färber [this message] 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 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers' \ /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
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).