* [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers @ 2019-12-12 3:39 Andreas Färber 2019-12-12 3:39 ` [RFC 04/25] spi: gpio: Implement LSB First bitbang support Andreas Färber ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: Andreas Färber @ 2019-12-12 3:39 UTC (permalink / raw) To: linux-realtek-soc, linux-leds Cc: Jacek Anaszewski, Pavel Machek, Dan Murphy, linux-arm-kernel, linux-kernel, Andreas Färber, linux-rtc, Alessandro Zummo, Alexandre Belloni, devicetree, Rob Herring, linux-spi, Mark Brown, linux-amlogic, Roc He, zypeng, sales, csd 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: linux-leds@vger.kernel.org Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com> Cc: linux-rtc@vger.kernel.org Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: devicetree@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-spi@vger.kernel.org Cc: Mark Brown <broonie@kernel.org> Cc: linux-amlogic@lists.infradead.org Cc: Roc He <hepeng@zidoo.tv> # No email for Xnano Cc: zypeng@titanmec.com Cc: sales@fdhisi.com # No email for szfdwdz.com Cc: csd@princeton.com.tw 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [RFC 04/25] spi: gpio: Implement LSB First bitbang support 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 ` Andreas Färber 2019-12-12 8:40 ` Geert Uytterhoeven 2019-12-12 13:14 ` [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers Robin Murphy ` (2 subsequent siblings) 3 siblings, 1 reply; 16+ messages in thread From: Andreas Färber @ 2019-12-12 3:39 UTC (permalink / raw) To: linux-realtek-soc, linux-leds Cc: linux-kernel, linux-spi, Mark Brown, Jacek Anaszewski, Pavel Machek, Andreas Färber, linux-arm-kernel, Dan Murphy Add support for slave DT property spi-lsb-first, i.e., SPI_LSB_FIRST mode. Duplicate the inline helpers bitbang_txrx_be_cpha{0,1} as LE versions. Make checkpatch.pl happy by changing "unsigned" to "unsigned int". Conditionally call them from all the spi-gpio txrx_word callbacks. Signed-off-by: Andreas Färber <afaerber@suse.de> --- drivers/spi/spi-bitbang-txrx.h | 68 ++++++++++++++++++++++++++++++++++++++++-- drivers/spi/spi-gpio.c | 42 ++++++++++++++++++++------ 2 files changed, 99 insertions(+), 11 deletions(-) diff --git a/drivers/spi/spi-bitbang-txrx.h b/drivers/spi/spi-bitbang-txrx.h index ae61d72c7d28..999a89325325 100644 --- a/drivers/spi/spi-bitbang-txrx.h +++ b/drivers/spi/spi-bitbang-txrx.h @@ -45,7 +45,7 @@ static inline u32 bitbang_txrx_be_cpha0(struct spi_device *spi, - unsigned nsecs, unsigned cpol, unsigned flags, + unsigned int nsecs, unsigned int cpol, unsigned int flags, u32 word, u8 bits) { /* if (cpol == 0) this is SPI_MODE_0; else this is SPI_MODE_2 */ @@ -77,7 +77,7 @@ bitbang_txrx_be_cpha0(struct spi_device *spi, static inline u32 bitbang_txrx_be_cpha1(struct spi_device *spi, - unsigned nsecs, unsigned cpol, unsigned flags, + unsigned int nsecs, unsigned int cpol, unsigned int flags, u32 word, u8 bits) { /* if (cpol == 0) this is SPI_MODE_1; else this is SPI_MODE_3 */ @@ -106,3 +106,67 @@ bitbang_txrx_be_cpha1(struct spi_device *spi, } return word; } + +static inline u32 +bitbang_txrx_le_cpha0(struct spi_device *spi, + unsigned int nsecs, unsigned int cpol, unsigned int flags, + u32 word, u8 bits) +{ + /* if (cpol == 0) this is SPI_MODE_0; else this is SPI_MODE_2 */ + + u32 oldbit = !(word & 1); + /* clock starts at inactive polarity */ + for (; likely(bits); bits--) { + + /* setup LSB (to slave) on trailing edge */ + if ((flags & SPI_MASTER_NO_TX) == 0) { + if ((word & 1) != oldbit) { + setmosi(spi, word & 1); + oldbit = word & 1; + } + } + spidelay(nsecs); /* T(setup) */ + + setsck(spi, !cpol); + spidelay(nsecs); + + /* sample LSB (from slave) on leading edge */ + word >>= 1; + if ((flags & SPI_MASTER_NO_RX) == 0) + word |= getmiso(spi) << (bits - 1); + setsck(spi, cpol); + } + return word; +} + +static inline u32 +bitbang_txrx_le_cpha1(struct spi_device *spi, + unsigned int nsecs, unsigned int cpol, unsigned int flags, + u32 word, u8 bits) +{ + /* if (cpol == 0) this is SPI_MODE_1; else this is SPI_MODE_3 */ + + u32 oldbit = !(word & 1); + /* clock starts at inactive polarity */ + for (; likely(bits); bits--) { + + /* setup LSB (to slave) on leading edge */ + setsck(spi, !cpol); + if ((flags & SPI_MASTER_NO_TX) == 0) { + if ((word & 1) != oldbit) { + setmosi(spi, word & 1); + oldbit = word & 1; + } + } + spidelay(nsecs); /* T(setup) */ + + setsck(spi, cpol); + spidelay(nsecs); + + /* sample LSB (from slave) on trailing edge */ + word >>= 1; + if ((flags & SPI_MASTER_NO_RX) == 0) + word |= getmiso(spi) << (bits - 1); + } + return word; +} diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c index 7ceb0ba27b75..493723eda844 100644 --- a/drivers/spi/spi-gpio.c +++ b/drivers/spi/spi-gpio.c @@ -135,25 +135,37 @@ static inline int getmiso(const struct spi_device *spi) static u32 spi_gpio_txrx_word_mode0(struct spi_device *spi, unsigned nsecs, u32 word, u8 bits, unsigned flags) { - return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits); + if (unlikely(spi->mode & SPI_LSB_FIRST)) + return bitbang_txrx_le_cpha0(spi, nsecs, 0, flags, word, bits); + else + return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits); } static u32 spi_gpio_txrx_word_mode1(struct spi_device *spi, unsigned nsecs, u32 word, u8 bits, unsigned flags) { - return bitbang_txrx_be_cpha1(spi, nsecs, 0, flags, word, bits); + if (unlikely(spi->mode & SPI_LSB_FIRST)) + return bitbang_txrx_le_cpha1(spi, nsecs, 0, flags, word, bits); + else + return bitbang_txrx_be_cpha1(spi, nsecs, 0, flags, word, bits); } static u32 spi_gpio_txrx_word_mode2(struct spi_device *spi, unsigned nsecs, u32 word, u8 bits, unsigned flags) { - return bitbang_txrx_be_cpha0(spi, nsecs, 1, flags, word, bits); + if (unlikely(spi->mode & SPI_LSB_FIRST)) + return bitbang_txrx_le_cpha0(spi, nsecs, 1, flags, word, bits); + else + return bitbang_txrx_be_cpha0(spi, nsecs, 1, flags, word, bits); } static u32 spi_gpio_txrx_word_mode3(struct spi_device *spi, unsigned nsecs, u32 word, u8 bits, unsigned flags) { - return bitbang_txrx_be_cpha1(spi, nsecs, 1, flags, word, bits); + if (unlikely(spi->mode & SPI_LSB_FIRST)) + return bitbang_txrx_le_cpha1(spi, nsecs, 1, flags, word, bits); + else + return bitbang_txrx_be_cpha1(spi, nsecs, 1, flags, word, bits); } /* @@ -170,28 +182,40 @@ static u32 spi_gpio_spec_txrx_word_mode0(struct spi_device *spi, unsigned nsecs, u32 word, u8 bits, unsigned flags) { flags = spi->master->flags; - return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits); + if (unlikely(spi->mode & SPI_LSB_FIRST)) + return bitbang_txrx_le_cpha0(spi, nsecs, 0, flags, word, bits); + else + return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits); } static u32 spi_gpio_spec_txrx_word_mode1(struct spi_device *spi, unsigned nsecs, u32 word, u8 bits, unsigned flags) { flags = spi->master->flags; - return bitbang_txrx_be_cpha1(spi, nsecs, 0, flags, word, bits); + if (unlikely(spi->mode & SPI_LSB_FIRST)) + return bitbang_txrx_le_cpha1(spi, nsecs, 0, flags, word, bits); + else + return bitbang_txrx_be_cpha1(spi, nsecs, 0, flags, word, bits); } static u32 spi_gpio_spec_txrx_word_mode2(struct spi_device *spi, unsigned nsecs, u32 word, u8 bits, unsigned flags) { flags = spi->master->flags; - return bitbang_txrx_be_cpha0(spi, nsecs, 1, flags, word, bits); + if (unlikely(spi->mode & SPI_LSB_FIRST)) + return bitbang_txrx_le_cpha0(spi, nsecs, 1, flags, word, bits); + else + return bitbang_txrx_be_cpha0(spi, nsecs, 1, flags, word, bits); } static u32 spi_gpio_spec_txrx_word_mode3(struct spi_device *spi, unsigned nsecs, u32 word, u8 bits, unsigned flags) { flags = spi->master->flags; - return bitbang_txrx_be_cpha1(spi, nsecs, 1, flags, word, bits); + if (unlikely(spi->mode & SPI_LSB_FIRST)) + return bitbang_txrx_le_cpha1(spi, nsecs, 1, flags, word, bits); + else + return bitbang_txrx_be_cpha1(spi, nsecs, 1, flags, word, bits); } /*----------------------------------------------------------------------*/ @@ -389,7 +413,7 @@ static int spi_gpio_probe(struct platform_device *pdev) master->bits_per_word_mask = SPI_BPW_RANGE_MASK(1, 32); master->mode_bits = SPI_3WIRE | SPI_3WIRE_HIZ | SPI_CPHA | SPI_CPOL | - SPI_CS_HIGH; + SPI_CS_HIGH | SPI_LSB_FIRST; if (!spi_gpio->mosi) { /* HW configuration without MOSI pin * -- 2.16.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [RFC 04/25] spi: gpio: Implement LSB First bitbang support 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 0 siblings, 1 reply; 16+ messages in thread From: Geert Uytterhoeven @ 2019-12-12 8:40 UTC (permalink / raw) To: Andreas Färber Cc: linux-realtek-soc, linux-leds, Linux Kernel Mailing List, linux-spi, Mark Brown, Jacek Anaszewski, Pavel Machek, Linux ARM, Dan Murphy Hi Andreas, On Thu, Dec 12, 2019 at 4:41 AM Andreas Färber <afaerber@suse.de> wrote: > Add support for slave DT property spi-lsb-first, i.e., SPI_LSB_FIRST mode. > > Duplicate the inline helpers bitbang_txrx_be_cpha{0,1} as LE versions. > Make checkpatch.pl happy by changing "unsigned" to "unsigned int". > > Conditionally call them from all the spi-gpio txrx_word callbacks. > > Signed-off-by: Andreas Färber <afaerber@suse.de> Thanks for your patch! > --- a/drivers/spi/spi-gpio.c > +++ b/drivers/spi/spi-gpio.c > @@ -135,25 +135,37 @@ static inline int getmiso(const struct spi_device *spi) > static u32 spi_gpio_txrx_word_mode0(struct spi_device *spi, > unsigned nsecs, u32 word, u8 bits, unsigned flags) > { > - return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits); > + if (unlikely(spi->mode & SPI_LSB_FIRST)) > + return bitbang_txrx_le_cpha0(spi, nsecs, 0, flags, word, bits); > + else > + return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits); > } Duplicating all functions sounds a bit wasteful to me. What about reverting the word first, and calling the normal functions? if (unlikely(spi->mode & SPI_LSB_FIRST)) { if (bits <= 8) word = bitrev8(word) >> (bits - 8); else if (bits <= 16) word = bitrev16(word) >> (bits - 16); else word = bitrev32(word) >> (bits - 32); } return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits); Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC 04/25] spi: gpio: Implement LSB First bitbang support 2019-12-12 8:40 ` Geert Uytterhoeven @ 2019-12-12 15:14 ` Andreas Färber 2019-12-12 17:19 ` Mark Brown 0 siblings, 1 reply; 16+ messages in thread From: Andreas Färber @ 2019-12-12 15:14 UTC (permalink / raw) To: Geert Uytterhoeven Cc: linux-realtek-soc, linux-leds, Linux Kernel Mailing List, linux-spi, Mark Brown, Jacek Anaszewski, Pavel Machek, Linux ARM, Dan Murphy Hi Geert, Am 12.12.19 um 09:40 schrieb Geert Uytterhoeven: > On Thu, Dec 12, 2019 at 4:41 AM Andreas Färber <afaerber@suse.de> wrote: >> Add support for slave DT property spi-lsb-first, i.e., SPI_LSB_FIRST mode. >> >> Duplicate the inline helpers bitbang_txrx_be_cpha{0,1} as LE versions. >> Make checkpatch.pl happy by changing "unsigned" to "unsigned int". >> >> Conditionally call them from all the spi-gpio txrx_word callbacks. >> >> Signed-off-by: Andreas Färber <afaerber@suse.de> > > Thanks for your patch! NP. I prefer fixing issues at the source over awkward workarounds. :) >> --- a/drivers/spi/spi-gpio.c >> +++ b/drivers/spi/spi-gpio.c >> @@ -135,25 +135,37 @@ static inline int getmiso(const struct spi_device *spi) >> static u32 spi_gpio_txrx_word_mode0(struct spi_device *spi, >> unsigned nsecs, u32 word, u8 bits, unsigned flags) >> { >> - return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits); >> + if (unlikely(spi->mode & SPI_LSB_FIRST)) >> + return bitbang_txrx_le_cpha0(spi, nsecs, 0, flags, word, bits); >> + else >> + return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits); >> } > > Duplicating all functions sounds a bit wasteful to me. Two functions duplicated, eight function calls duplicated. > What about reverting the word first, and calling the normal functions? > > if (unlikely(spi->mode & SPI_LSB_FIRST)) { > if (bits <= 8) > word = bitrev8(word) >> (bits - 8); > else if (bits <= 16) > word = bitrev16(word) >> (bits - 16); > else > word = bitrev32(word) >> (bits - 32); > } > return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits); Hm, wasn't aware of those helpers, so I opted not to loop over the bits for reversing myself, as Thomas Gleixner disliked bit loops in irqchip. Performance appeared to be a concern here, too. Eight functions duplicated then. I don't like that - at least we should pack that into an inline helper or macro, to not copy&paste even more lines around. Who knows, maybe we'll get 64-bit support at one point? Do you think it would be acceptable to instead encapsulate this inside the _be inline helpers? That would lead the name ad absurdum, of course, but we would then need to do it only twice, not eight times. However, either way would seem to make the LSB code path slower than MSB due to the prepended reversal. Delays are already stubbed out, with open TODOs for further inlining functions that are being dispatched today. So from that angle I don't see a better way than either duplicating the functions or using some macro magic to #include the header twice. If we wanted to go down that path, we could probably de-duplicate the existing two functions, too, but I was trying to err on the cautious side, since I don't have setups to test all four code paths myself (and a ton of more relevant but less fun patches to flush out ;)). Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC 04/25] spi: gpio: Implement LSB First bitbang support 2019-12-12 15:14 ` Andreas Färber @ 2019-12-12 17:19 ` Mark Brown 2019-12-12 21:08 ` Andreas Färber 0 siblings, 1 reply; 16+ messages in thread From: Mark Brown @ 2019-12-12 17:19 UTC (permalink / raw) To: Andreas Färber Cc: Geert Uytterhoeven, linux-realtek-soc, linux-leds, Linux Kernel Mailing List, linux-spi, Jacek Anaszewski, Pavel Machek, Linux ARM, Dan Murphy [-- Attachment #1: Type: text/plain, Size: 1104 bytes --] On Thu, Dec 12, 2019 at 04:14:59PM +0100, Andreas Färber wrote: > Am 12.12.19 um 09:40 schrieb Geert Uytterhoeven: > > On Thu, Dec 12, 2019 at 4:41 AM Andreas Färber <afaerber@suse.de> wrote: > >> Add support for slave DT property spi-lsb-first, i.e., SPI_LSB_FIRST mode. > >> Duplicate the inline helpers bitbang_txrx_be_cpha{0,1} as LE versions. > >> Make checkpatch.pl happy by changing "unsigned" to "unsigned int". Separate patch for this? > So from that angle I don't see a better way than either duplicating the > functions or using some macro magic to #include the header twice. If we > wanted to go down that path, we could probably de-duplicate the existing > two functions, too, but I was trying to err on the cautious side, since > I don't have setups to test all four code paths myself (and a ton of > more relevant but less fun patches to flush out ;)). Yeah, I don't think there's any great options here with the potential performance issues - probably the nicest thing would be to autogenerate lots of variants but I think that's far more trouble than it's worth. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC 04/25] spi: gpio: Implement LSB First bitbang support 2019-12-12 17:19 ` Mark Brown @ 2019-12-12 21:08 ` Andreas Färber 2019-12-13 11:42 ` Mark Brown 0 siblings, 1 reply; 16+ messages in thread From: Andreas Färber @ 2019-12-12 21:08 UTC (permalink / raw) To: Mark Brown Cc: Geert Uytterhoeven, linux-realtek-soc, linux-leds, Linux Kernel Mailing List, linux-spi, Jacek Anaszewski, Pavel Machek, Linux ARM, Dan Murphy Am 12.12.19 um 18:19 schrieb Mark Brown: > On Thu, Dec 12, 2019 at 04:14:59PM +0100, Andreas Färber wrote: >> Am 12.12.19 um 09:40 schrieb Geert Uytterhoeven: >>> On Thu, Dec 12, 2019 at 4:41 AM Andreas Färber <afaerber@suse.de> wrote: >>>> Add support for slave DT property spi-lsb-first, i.e., SPI_LSB_FIRST mode. > >>>> Duplicate the inline helpers bitbang_txrx_be_cpha{0,1} as LE versions. >>>> Make checkpatch.pl happy by changing "unsigned" to "unsigned int". > > Separate patch for this? For the checkpatch cleanup? Or helpers preparation vs. spi-gpio.c usage? >> So from that angle I don't see a better way than either duplicating the >> functions or using some macro magic to #include the header twice. If we >> wanted to go down that path, we could probably de-duplicate the existing >> two functions, too, but I was trying to err on the cautious side, since >> I don't have setups to test all four code paths myself (and a ton of >> more relevant but less fun patches to flush out ;)). > > Yeah, I don't think there's any great options here with the potential > performance issues - probably the nicest thing would be to autogenerate > lots of variants but I think that's far more trouble than it's worth. Maybe add another code comment to revisit that idea later then? Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC 04/25] spi: gpio: Implement LSB First bitbang support 2019-12-12 21:08 ` Andreas Färber @ 2019-12-13 11:42 ` Mark Brown 0 siblings, 0 replies; 16+ messages in thread From: Mark Brown @ 2019-12-13 11:42 UTC (permalink / raw) To: Andreas Färber Cc: Geert Uytterhoeven, linux-realtek-soc, linux-leds, Linux Kernel Mailing List, linux-spi, Jacek Anaszewski, Pavel Machek, Linux ARM, Dan Murphy [-- Attachment #1: Type: text/plain, Size: 731 bytes --] On Thu, Dec 12, 2019 at 10:08:24PM +0100, Andreas Färber wrote: > Am 12.12.19 um 18:19 schrieb Mark Brown: > >>>> Duplicate the inline helpers bitbang_txrx_be_cpha{0,1} as LE versions. > >>>> Make checkpatch.pl happy by changing "unsigned" to "unsigned int". > > Separate patch for this? > For the checkpatch cleanup? Or helpers preparation vs. spi-gpio.c usage? At least the checkpatch cleanup. > > Yeah, I don't think there's any great options here with the potential > > performance issues - probably the nicest thing would be to autogenerate > > lots of variants but I think that's far more trouble than it's worth. > Maybe add another code comment to revisit that idea later then? Sure, if you like. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers 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 04/25] spi: gpio: Implement LSB First bitbang support Andreas Färber @ 2019-12-12 13:14 ` Robin Murphy 2019-12-12 20:55 ` Andreas Färber 2019-12-21 18:20 ` Pavel Machek [not found] ` <20191212033952.5967-1-afaerber-l3A5Bk7waGM@public.gmane.org> 3 siblings, 1 reply; 16+ messages in thread From: Robin Murphy @ 2019-12-12 13:14 UTC (permalink / raw) To: Andreas Färber, linux-realtek-soc, linux-leds Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, Roc He, csd, devicetree, sales, Mark Brown, linux-kernel, linux-spi, Rob Herring, Jacek Anaszewski, Pavel Machek, zypeng, linux-amlogic, linux-arm-kernel, Dan Murphy Hi Andreas, On 12/12/2019 3:39 am, Andreas Färber wrote: > 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. It's pretty cool to see this! My Rockchip box has an AiP1618-driven display that I've also spent a bit of time hacking around with - I did get some way into writing an LED driver, but ultimately gave up and wrote a simple thing to bit-bang the GPIO chardev from userspace (and since there are enough clocks in my house, I now have a cpufreq display!) In case it helps, in my research I found that ARTSCHIP are another vendor of these things with accessible datasheets[1], 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. 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. 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 :/ Robin. [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 > > Have a lot of fun! > > Cheers, > Andreas > > Cc: linux-leds@vger.kernel.org > Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com> > Cc: Pavel Machek <pavel@ucw.cz> > Cc: Dan Murphy <dmurphy@ti.com> > > Cc: linux-rtc@vger.kernel.org > Cc: Alessandro Zummo <a.zummo@towertech.it> > Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> > > Cc: devicetree@vger.kernel.org > Cc: Rob Herring <robh+dt@kernel.org> > > Cc: linux-spi@vger.kernel.org > Cc: Mark Brown <broonie@kernel.org> > > Cc: linux-amlogic@lists.infradead.org > > Cc: Roc He <hepeng@zidoo.tv> > # No email for Xnano > > Cc: zypeng@titanmec.com > Cc: sales@fdhisi.com > # No email for szfdwdz.com > Cc: csd@princeton.com.tw > > 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 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers 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 0 siblings, 1 reply; 16+ messages in thread From: Andreas Färber @ 2019-12-12 20:55 UTC (permalink / raw) To: Robin Murphy Cc: linux-realtek-soc, linux-leds, linux-rtc, Alessandro Zummo, Alexandre Belloni, csd, devicetree, sales, Mark Brown, linux-kernel, linux-spi, Rob Herring, Jacek Anaszewski, Pavel Machek, zypeng, linux-amlogic, linux-arm-kernel, Dan Murphy, linux-rockchip 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) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers 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 0 siblings, 2 replies; 16+ messages in thread From: Robin Murphy @ 2019-12-13 14:07 UTC (permalink / raw) To: Andreas Färber Cc: linux-realtek-soc, linux-leds, linux-rtc, Alessandro Zummo, Alexandre Belloni, csd, devicetree, sales, Mark Brown, linux-kernel, linux-spi, Rob Herring, Jacek Anaszewski, Pavel Machek, zypeng, linux-amlogic, linux-arm-kernel, Dan Murphy, linux-rockchip On 12/12/2019 8:55 pm, Andreas Färber wrote: > 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.) It's the Beelink A1, which we have indeed just landed a DT for - I'll certainly share whatever patch I come up with. I also have one of the H96 Max boxes (which I picked up out of curiosity for the mysterious RK3318) with an FD6551, although I've not attacked that one with the logic analyser yet to see how similar it is. > 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. Yeah, I'm not sure that it really matters, as I doubt there are many Linux-capable devices with a real VFD anyway; it just seemed like an interesting datapoint that fell out of scouring the web trying to find any evidence for which the "canonical" 1618 might be (and the Holtek connection was actually a coincidence from a misidentification of the ARTSCHIP part number). >> 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. Aha, yes, I should have engaged the brain a bit more on that one :) > 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. Sure - perhaps at that point text_store() could also grow some caching and partial update logic to decide if writing individual grids is cheaper than clocking out the whole display for a given change, but this initial approach does seem good enough to start with. Lumping colons in with the other miscellaneous indicators many of these displays have does at least have a self-consistent logic in terms of "things that aren't 7-segment grids". Thanks, Robin. > 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] > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers 2019-12-13 14:07 ` Robin Murphy @ 2019-12-13 14:36 ` Geert Uytterhoeven 2020-02-25 21:42 ` Ezra Buehler 1 sibling, 0 replies; 16+ messages in thread From: Geert Uytterhoeven @ 2019-12-13 14:36 UTC (permalink / raw) To: Robin Murphy Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, csd, linux-realtek-soc, open list:ARM/Rockchip SoC..., sales, Linux Kernel Mailing List, Rob Herring, linux-spi, Dan Murphy, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Mark Brown, Jacek Anaszewski, Pavel Machek, zypeng, open list:ARM/Amlogic Meson..., Andreas Färber, linux-leds, Linux ARM Hi Robin, On Fri, Dec 13, 2019 at 3:08 PM Robin Murphy <robin.murphy@arm.com> wrote: > On 12/12/2019 8:55 pm, Andreas Färber wrote: > > Am 12.12.19 um 14:14 schrieb Robin Murphy: > >> 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. > > Yeah, I'm not sure that it really matters, as I doubt there are many > Linux-capable devices with a real VFD anyway; it just seemed like an > interesting datapoint that fell out of scouring the web trying to find > any evidence for which the "canonical" 1618 might be (and the Holtek > connection was actually a coincidence from a misidentification of the > ARTSCHIP part number). My Sony Blu-Ray/Home Theatre has a nice one (14-segment!), also driven by an HT16515. While the specific model predates the arrival of Linux in the next stepping of the hardware, it should be sufficiently powerful to run Linux. Unfortunately it's in active use, so hacking experiments would be vetoed by the family ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers 2019-12-13 14:07 ` Robin Murphy 2019-12-13 14:36 ` Geert Uytterhoeven @ 2020-02-25 21:42 ` Ezra Buehler [not found] ` <E33E27B9-D33C-4182-A5B1-C72FA40470BC-z8Bw++XM6qA@public.gmane.org> 1 sibling, 1 reply; 16+ messages in thread From: Ezra Buehler @ 2020-02-25 21:42 UTC (permalink / raw) To: Robin Murphy, Andreas Färber Cc: linux-realtek-soc, linux-leds, linux-rtc, Alessandro Zummo, Alexandre Belloni, csd, devicetree, sales, Mark Brown, linux-kernel, linux-spi, Rob Herring, Jacek Anaszewski, Pavel Machek, zypeng, linux-amlogic, linux-arm-kernel, Dan Murphy, linux-rockchip Hi Robin, Hi Andreas, > On 13 Dec 2019, at 15:07, Robin Murphy <robin.murphy@arm.com> wrote: > > I also have one of the H96 Max boxes (which I picked up out of curiosity > for the mysterious RK3318) with an FD6551, although I've not attacked > that one with the logic analyser yet to see how similar it is. I have a T9 (RK3328) TV box with the same chip in it. The FD6551 uses an I2C-like protocol. Every digit (and the symbols) have an I2C address, but, the display does not signal ACK. AFAIK the FD650 and FD655 which are used in other boxes (Amlogic) are very similar. So far, I have whipped up a proof-of-cocept driver that uses i2c-gpio. The digits seem to be rotated by 180 degrees. So, in order to use map_to_7segment.h I had to define the BIT_SEG7_* constants differently. My display also has multiple symbols (WIFI, network, pause, play, USB, alarm) that are controlled by writing to the same address as for the colon. I’d love to work on a driver (similar to Andreas’ SPI based driver) for these I2C connected chips. Cheers, Ezra. ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <E33E27B9-D33C-4182-A5B1-C72FA40470BC-z8Bw++XM6qA@public.gmane.org>]
* Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers [not found] ` <E33E27B9-D33C-4182-A5B1-C72FA40470BC-z8Bw++XM6qA@public.gmane.org> @ 2020-02-26 13:03 ` Pavel Machek 0 siblings, 0 replies; 16+ messages in thread From: Pavel Machek @ 2020-02-26 13:03 UTC (permalink / raw) To: Ezra Buehler Cc: Robin Murphy, Andreas Färber, linux-realtek-soc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-leds-u79uwXL29TY76Z2rM5mHXA, linux-rtc-u79uwXL29TY76Z2rM5mHXA, Alessandro Zummo, Alexandre Belloni, csd-uX/v2g6dJhB25pISuqNqZg, devicetree-u79uwXL29TY76Z2rM5mHXA, sales-quSABqrs8DPQT0dZR+AlfA, Mark Brown, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-spi-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Jacek Anaszewski, zypeng-Svy83JD6bw5Wk0Htik3J/w, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Dan Murphy, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r [-- Attachment #1: Type: text/plain, Size: 1418 bytes --] Hi! > > On 13 Dec 2019, at 15:07, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote: > > > > I also have one of the H96 Max boxes (which I picked up out of curiosity > > for the mysterious RK3318) with an FD6551, although I've not attacked > > that one with the logic analyser yet to see how similar it is. > > I have a T9 (RK3328) TV box with the same chip in it. The FD6551 uses an > I2C-like protocol. Every digit (and the symbols) have an I2C address, > but, the display does not signal ACK. AFAIK the FD650 and FD655 which > are used in other boxes (Amlogic) are very similar. > > So far, I have whipped up a proof-of-cocept driver that uses i2c-gpio. > The digits seem to be rotated by 180 degrees. So, in order to use > map_to_7segment.h I had to define the BIT_SEG7_* constants differently. > My display also has multiple symbols (WIFI, network, pause, play, USB, > alarm) that are controlled by writing to the same address as for the > colon. > > I’d love to work on a driver (similar to Andreas’ SPI based driver) for > these I2C connected chips. Create a driver in drivers/auxdisplay for alphanumeric parts. You can then export any remaining symbols as LEDs if it will provide benefits. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers 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 04/25] spi: gpio: Implement LSB First bitbang support 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-21 18:20 ` Pavel Machek 2019-12-21 21:07 ` Andreas Färber [not found] ` <20191212033952.5967-1-afaerber-l3A5Bk7waGM@public.gmane.org> 3 siblings, 1 reply; 16+ messages in thread From: Pavel Machek @ 2019-12-21 18:20 UTC (permalink / raw) To: Andreas Färber Cc: linux-realtek-soc, linux-leds, Jacek Anaszewski, Dan Murphy, linux-arm-kernel, linux-kernel, linux-rtc, Alessandro Zummo, Alexandre Belloni, devicetree, Rob Herring, linux-spi, Mark Brown, linux-amlogic, Roc He, zypeng, sales, csd [-- Attachment #1: Type: text/plain, Size: 1398 bytes --] Hi! > 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 Fun :-). > 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. I guess LEDs can still take the low-level parts... Oh, and common dimming for many LEDs is seen on other hardware, too (Turris routers). Not sure how to handle that, either :-(. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers 2019-12-21 18:20 ` Pavel Machek @ 2019-12-21 21:07 ` Andreas Färber 0 siblings, 0 replies; 16+ messages in thread From: Andreas Färber @ 2019-12-21 21:07 UTC (permalink / raw) To: Pavel Machek Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, linux-realtek-soc, Mark Brown, linux-kernel, linux-spi, devicetree, Rob Herring, Dan Murphy, linux-leds, linux-amlogic, linux-arm-kernel, Jacek Anaszewski 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) ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <20191212033952.5967-1-afaerber-l3A5Bk7waGM@public.gmane.org>]
* Re: [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers [not found] ` <20191212033952.5967-1-afaerber-l3A5Bk7waGM@public.gmane.org> @ 2020-01-15 13:34 ` Andreas Färber 0 siblings, 0 replies; 16+ messages in thread From: Andreas Färber @ 2020-01-15 13:34 UTC (permalink / raw) To: linux-realtek-soc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring Cc: linux-leds-u79uwXL29TY76Z2rM5mHXA, linux-rtc-u79uwXL29TY76Z2rM5mHXA, Alessandro Zummo, Alexandre Belloni, devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Brown, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-spi-u79uwXL29TY76Z2rM5mHXA, Jacek Anaszewski, Pavel Machek, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Dan Murphy Am 12.12.19 um 04:39 schrieb Andreas Färber: > Prepended is a new DT for Xnano X5 OTT TV Box, featuring an FD628 display. [...] > Andreas Färber (25): > dt-bindings: vendor-prefixes: Add Xnano > dt-bindings: arm: realtek: Add Xnano X5 > arm64: dts: realtek: rtd1295: Add Xnano X5 [snip] Applied these three to linux-realtek.git v5.6/dt: https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-realtek.git/log/?h=v5.6/dt Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-02-26 13:03 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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 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 [not found] ` <E33E27B9-D33C-4182-A5B1-C72FA40470BC-z8Bw++XM6qA@public.gmane.org> 2020-02-26 13:03 ` Pavel Machek 2019-12-21 18:20 ` Pavel Machek 2019-12-21 21:07 ` Andreas Färber [not found] ` <20191212033952.5967-1-afaerber-l3A5Bk7waGM@public.gmane.org> 2020-01-15 13:34 ` Andreas Färber
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).