Re: [PATCH v6 0/7] auxdisplay: Add TM16xx 7-segment LED matrix display controllers driver

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Fri, Nov 21, 2025 at 09:59:00AM -0500, Jean-François Lessard wrote:
> This series adds mainline kernel support for TM16xx family LED matrix
> controllers and compatible chips, widely used in auxiliary displays on TV
> boxes and embedded devices.
> 
> Many consumer devices, particularly TV boxes, use auxiliary displays based
> on TM16xx controllers to show status information such as time, network
> connectivity and system state. Currently, there is no mainline kernel
> support for these displays, forcing users to rely on out-of-tree drivers
> or userspace solutions that access hardware interfaces directly.
> 
> This driver provides unified TM16xx support through the LED subsystem with
> both I2C and SPI communication protocols. It integrates with the LED class
> framework, enabling control via standard sysfs interfaces and LED triggers,
> while supporting keypad input when hardware connections are available.
> 
> The driver supports multiple controller families from various vendors:
> - Titan Micro Electronics: TM1618, TM1620, TM1628, TM1638, TM1650
> - Fuda Hisi Microelectronics: FD620, FD628, FD650, FD655, FD6551
> - i-Core Electronics: AiP650, AiP1618, AiP1628
> - Princeton Technology: PT6964
> - Winrise Technology: HBS658
> 
> Key features:
> - 7-segment display support with flexible digit/segment mapping
> - Individual LED icon control through LED class devices
> - Optional keypad scanning with configurable key mapping
> - Device tree configuration for board-specific wiring layouts
> - LED trigger integration for automatic system event indication
> - I2C and SPI protocol support depending on controller interface
> 
> Device tree bindings describe board-specific display wiring since
> controllers are layout-agnostic. The bindings use separate 'digits' and
> 'leds' containers with specific addressing schemes to accommodate the
> hardware's grid/segment matrix organization.
> 
> Tested on multiple ARM TV boxes (H96 Max, Magicsee N5, Tanix TX3 Mini,
> Tanix TX6, X92, X96 Max) across different SoC platforms (Rockchip, Amlogic,
> Allwinner) in both I2C and SPI configurations.
> 
> User space utilities available at:
> https://github.com/jefflessard/tm16xx-display
> 
> Dependencies:
> - linedisp_attach()/_detach() infrastructure introduced in patch series:
>  "auxdisplay: linedisp: support attribute attachment to auxdisplay devices"
> - fwnode_for_each_available_child_node_scoped() from patch series:
>  "device property: Add scoped fwnode child node iterators"
> 
> Note: This driver is placed in drivers/auxdisplay rather than drivers/leds
> based on previous maintainer guidance. LED maintainer Pavel Machek
> recommended auxdisplay for TM1628-based display drivers:
> https://lore.kernel.org/linux-devicetree/20200226130300.GB2800@duo.ucw.cz/
> 
> Regmap Evaluation:
> TM16xx controllers use command-based 2-wire/3-wire protocols that share
> sufficient commonalities with I2C/SPI to leverage their subsystems, but
> are not fully compliant with standard register-based access patterns:
> - TM1650 example: 0x48 is a control command while 0x4F is a keyscan
>   command. These appear as adjacent I2C "addresses" but are distinct
>   commands with different data directions and payloads, not read/write
>   pairs of the same register.
> - TM1628 example: Initialization requires coordinated sequences followed
>   by indexed data writes. Single regmap read/write calls cannot express
>   these multi-step transactions and timing constraints.
> - Protocol requirements: I2C read operations require I2C_M_NO_RD_ACK flags;
>   SPI write-then-read operations require mandatory inter-transfer delays
>   and CS assertion across phases.
> 
> While regmap provides valuable synchronization, debugfs, and abstraction
> benefits, standard I2C/SPI regmap buses cannot handle these requirements.
> 
> Custom regmap implementation is technically possible via IO accessors, but
> demands complex command routing logic and only partially supports paging.
> It would essentially recreate the existing controller functions while
> forcing them into register semantics they don't naturally fit.
> 
> The current explicit I2C/SPI approach directly expresses the hardware's
> actual command structure and maintains proper controller abstraction.

I think I have reviewed everything (except DT bindings, I will rely on
the respective tags from DT people). There are some comments also given
recently against previous round, please consider them as well.

-- 
With Best Regards,
Andy Shevchenko