auxdisplay: Add TM16xx 7-segment LED matrix display controllers driver

Add documentation for TM16xx-compatible 7-segment LED display controllers with keyscan.

Signed-off-by Jean-François Lessard <[email protected]>

---

Notes:
The 'segments' property is intentionally not vendor-prefixed as it defines a generic hardware description concept applicable to any 7-segment display controller. The property describes the fundamental grid/segment coordinate mapping that is controller-agnostic and could be reused by other LED matrix display bindings. Similar to how 'gpios' describes GPIO connections generically, 'segments' describes segment connections in a standardized way using uint32-matrix format.

The property uses explicit coordinate pairs to handle real-world hardware variations. Some board manufacturers use standard layouts (same grid, different segments per digit) while others use transposed layouts (same segment, different grids per digit). The coordinate-pair approach accommodates both patterns without requiring separate arrays or boolean flags, as confirmed acceptable by DT maintainers.

Retained 'properties:' wrapper for spi-3wire in conditional block. Rob Herring suggested removing it, but dt_binding_check requires explicit 'properties:' context when referencing peripheral properties within allOf conditional sections to satisfy unevaluatedProperties validation. This follows the pattern in spi-controller.yaml itself.

 .../bindings/auxdisplay/titanmec,tm16xx.yaml  | 465 ++++++++++++++++++
 MAINTAINERS                                   |   5 +
 2 files changed, 470 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml

Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml new file +199 -0

new file mode 100644
index 000000000000..a852d8b8882c
@@ -0,0 +1,465 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/auxdisplay/titanmec,tm16xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Auxiliary displays based on TM16xx and compatible LED controllers
+
+maintainers:
+  - Jean-François Lessard <[email protected]>
+
+description: |
+  LED matrix controllers used in auxiliary display devices that drive individual
+  LED icons and 7-segment digit groups through a grid/segment addressing scheme.
+  Controllers manage a matrix of LEDs organized as grids (columns/banks in
+  vendor datasheets) and segments (rows/bit positions in vendor datasheets).
+  Maximum brightness and grid/segment indices are controller-specific.
+  Controller-specific maximum are validated in the driver.
+
+  The controller is agnostic of the display layout. Board-specific LED wiring is
+  described through child nodes that specify grid/segment coordinates for
+  individual icons and segment mapping for 7-segment digits.
+
+  The bindings use separate 'leds' and 'digits' containers to accommodate
+  different addressing schemes:
+  - LEDs use 2-cell addressing (grid, segment) for matrix coordinates
+  - Digits use 1-cell addressing with explicit segment mapping
+
+  The controller node exposes a logical LED-like control for the aggregate
+  display brightness. Child nodes describe individual icons and 7-seg digits.
+  The top-level control supports only label and brightness-related properties
+  and does not support other common LED properties such as color or function.
+  Child LED nodes use the standard LED binding.
+
+  Optional keypad scanning is supported when both 'linux,keymap' and
+  'poll-interval' properties are specified.
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - fdhisi,fd628
+              - princeton,pt6964
+              - wxicore,aip1628
+          - const: titanmec,tm1628
+      - items:
+          - enum:
+              - wxicore,aip1618
+          - const: titanmec,tm1618
+      - items:
+          - enum:
+              - fdhisi,fd650
+              - wxicore,aip650
+          - const: titanmec,tm1650
+      - enum:
+          - fdhisi,fd620
+          - fdhisi,fd655
+          - fdhisi,fd6551
+          - titanmec,tm1618
+          - titanmec,tm1620
+          - titanmec,tm1628
+          - titanmec,tm1638
+          - titanmec,tm1650
+          - winrise,hbs658
+
+  reg:
+    maxItems: 1
+
+  label:
+    description:
+      The label for the top-level LED. If omitted, the label is taken from the
+      node name (excluding the unit address). It has to uniquely identify a
+      device, i.e. no other LED class device can be assigned the same label.
+
+  max-brightness:
+    minimum: 0  # 0=off
+    maximum: 8  # Maximum across all TM16xx controllers
+    description:
+      Normally the maximum brightness is determined by the hardware and this
+      property is not required. This property is used to put a software limit
+      on the brightness apart from what the driver says, as it could happen
+      that a LED can be made so bright that it gets damaged or causes damage
+      due to restrictions in a specific system, such as mounting conditions.
+
+  default-brightness:
+    minimum: 0  # 0=off
+    maximum: 8  # Maximum across all TM16xx controllers
+    description:
+      Brightness to be set if LED's default state is on. Used only during
+      initialization. If the option is not set then max brightness is used.
+
+  digits:
+    type: object
+    description: Container for 7-segment digit group definitions
+    additionalProperties: false
+
+    properties:
+      "#address-cells":
+        const: 1
+      "#size-cells":
+        const: 0
+
+    patternProperties:
+      "^digit@[0-9a-f]+$":
+        type: object
+        unevaluatedProperties: false
+
+        properties:
+          reg:
+            description:
+              Digit position identifier numbered sequentially left-to-right,
+              with reg=0 representing the leftmost digit position as displayed
+              to the user.
+            maxItems: 1
+
+          segments:
+            $ref: /schemas/types.yaml#/definitions/uint32-matrix
+            description: |
+              Array of grid/segment coordinate pairs for each 7-segment position.
+              Each entry is <grid segment> mapping to standard 7-segment positions
+              in order: a, b, c, d, e, f, g
+
+              Standard 7-segment layout:
+                 aaa
+                f   b
+                f   b
+                 ggg
+                e   c
+                e   c
+                 ddd
+            items:
+              items:
+                - description: Grid index
+                - description: Segment index
+            minItems: 7
+            maxItems: 7
+
+        required:
+          - reg
+          - segments
+
+  leds:
+    type: object
+    description: Container for individual LED icon definitions
+    additionalProperties: false
+
+    properties:
+      "#address-cells":
+        const: 2
+      "#size-cells":
+        const: 0
+
+    patternProperties:
+      "^led@[0-9a-f]+,[0-9a-f]+$":
+        type: object
+        description:
+          Individual LED icon addressed by <grid>,<segment> matrix coordinates.
+        $ref: /schemas/leds/common.yaml#
+        unevaluatedProperties: false
+
+        properties:
+          reg:
+            description:
+              Grid and segment indices as <grid segment> of this individual LED icon
+
+        required:
+          - reg
+
+dependencies:
+  poll-interval:
+    - linux,keymap
+  linux,keymap:
+    - poll-interval
+  autorepeat:
+    - linux,keymap
+    - poll-interval
+
+required:
+  - compatible
+  - reg
+
+allOf:
+  - $ref: /schemas/leds/common.yaml#
+    properties:
+      color: false
+      function: false
+      function-enumerator: false
+  - $ref: /schemas/input/input.yaml#
+  - $ref: /schemas/input/matrix-keymap.yaml#
+  # SPI controllers require 3-wire (combined MISO/MOSI line)
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - fdhisi,fd620
+              - fdhisi,fd628
+              - princeton,pt6964

Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml new file +2 -0

+      required:
+        - spi-3wire

Add driver for TM16xx family LED controllers and compatible chips from multiple vendors including Titan Micro, Fuda Hisi, i-Core, Princeton, and Winrise. These controllers drive 7-segment digits and individual LED icons through either I2C or SPI buses.

Successfully tested on various ARM TV boxes including H96 Max, Magicsee N5, Tanix TX3 Mini, Tanix TX6, X92, and X96 Max across different SoC platforms (Rockchip, Amlogic, Allwinner).

drivers/auxdisplay/tm16xx.h new file +14 -0

+/* I2C controller addresses and control settings */
+#define TM1650_CMD_CTRL		0x48
+#define TM1650_CMD_READ		0x4F
+#define TM1650_CMD_ADDR		0x68
+#define TM1650_CTRL_BR_MASK	GENMASK(6, 4)
+#define TM1650_CTRL_ON		(1 << 0)
+#define TM1650_CTRL_SLEEP	(1 << 2)
+#define TM1650_CTRL_SEG_MASK	BIT(3)
+#define TM1650_CTRL_SEG8_MODE	(0 << 3)
+#define TM1650_CTRL_SEG7_MODE	(1 << 3)
+#define TM1650_KEY_ROW_MASK	GENMASK(1, 0)
+#define TM1650_KEY_COL_MASK	GENMASK(5, 3)
+#define TM1650_KEY_DOWN_MASK	BIT(6)
+#define TM1650_KEY_COMBINED	GENMASK(5, 3)

drivers/auxdisplay/tm16xx.h new file +3 -0

+struct tm16xx_display;
+struct tm16xx_digit;
+struct tm16xx_led;

+struct tm16xx_display {

drivers/auxdisplay/tm16xx.h new file +17 -0

+	struct device *dev;
+	const struct tm16xx_controller *controller;
+	struct linedisp linedisp;
+	u8 *spi_buffer;
+	u8 num_hwgrid;
+	u8 num_hwseg;
+	struct led_classdev main_led;
+	struct tm16xx_led *leds;
+	u8 num_leds;
+	struct tm16xx_digit *digits;
+	u8 num_digits;
+	struct work_struct flush_init;
+	struct work_struct flush_display;
+	int flush_status;
+	struct mutex lock; /* prevents concurrent work operations */
+	unsigned long *state;
+};

drivers/auxdisplay/tm16xx_core.c new file +14 -0

+#include <linux/bits.h>
+#include <linux/bitfield.h>
+#include <linux/bitmap.h>
+#include <linux/cleanup.h>
+#include <linux/container_of.h>
+#include <linux/device.h>
+#include <linux/leds.h>
+#include <linux/map_to_7segment.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/property.h>
+#include <linux/sysfs.h>
+#include <linux/types.h>
+#include <linux/workqueue.h>

+}

drivers/auxdisplay/tm16xx_core.c new file +6 -0

+	struct tm16xx_digit *digit;
+	int seg_pattern, ret = 0;
+	unsigned int i, j;
+	bool val;
+
+	for (i = 0; i < display->num_digits; i++) {

drivers/auxdisplay/tm16xx_core.c new file +14 -0

+			}
+		} else {
+			seg_pattern = 0;
+		}
+
+		for (j = 0; j < TM16XX_DIGIT_SEGMENTS; j++) {
+			val = seg_pattern & BIT(j);
+			tm16xx_set_seg(display, digit->hwgrids[j], digit->hwsegs[j], val);
+		}
+	}
+
+	schedule_work(&display->flush_display);
+	return ret;
+}

drivers/auxdisplay/tm16xx_core.c new file +10 -0

+static int tm16xx_parse_fwnode(struct device *dev, struct tm16xx_display *display)
+{
+	unsigned int max_hwgrid = 0, max_hwseg = 0;
+	u32 segments[TM16XX_DIGIT_SEGMENTS * 2];
+	struct tm16xx_digit *digit;
+	struct tm16xx_led *led;
+	unsigned int i, j;
+	u32 reg[2];
+	int ret;
+

drivers/auxdisplay/tm16xx_core.c new file +8 -0

+			if (ret < 0)
+				return ret;
+
+			for (j = 0; j < TM16XX_DIGIT_SEGMENTS; ++j) {
+				digit->hwgrids[j] = segments[2 * j];
+				digit->hwsegs[j] = segments[2 * j + 1];
+				max_hwgrid = umax(max_hwgrid, digit->hwgrids[j]);
+				max_hwseg = umax(max_hwseg, digit->hwsegs[j]);

drivers/auxdisplay/tm16xx_core.c new file +28 -0

+			if (ret < 0)
+				return ret;
+
+			led->hwgrid = reg[0];
+			led->hwseg = reg[1];
+			max_hwgrid = umax(max_hwgrid, led->hwgrid);
+			max_hwseg = umax(max_hwseg, led->hwseg);
+			i++;
+		}
+	}
+
+	if (max_hwgrid >= display->controller->max_grids) {
+		dev_err(dev, "grid %u exceeds controller max_grids %u\n",
+			max_hwgrid, display->controller->max_grids);
+		return -EINVAL;
+	}
+
+	if (max_hwseg >= display->controller->max_segments) {
+		dev_err(dev, "segment %u exceeds controller max_segments %u\n",
+			max_hwseg, display->controller->max_segments);
+		return -EINVAL;
+	}
+
+	display->num_hwgrid = max_hwgrid + 1;
+	display->num_hwseg = max_hwseg + 1;
+
+	return 0;
+}

drivers/auxdisplay/tm16xx_core.c new file +21 -0

+int tm16xx_probe(struct tm16xx_display *display)
+{
+	struct led_classdev *main = &display->main_led;
+	struct led_init_data led_init = {};
+	struct device *dev = display->dev;
+	struct fwnode_handle *leds_node;
+	struct tm16xx_led *led;
+	unsigned int nbits, i;
+	int ret;
+
+	ret = tm16xx_parse_fwnode(dev, display);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to parse device tree\n");
+
+	nbits = tm16xx_led_nbits(display);
+	display->state = devm_bitmap_zalloc(dev, nbits, GFP_KERNEL);
+	if (!display->state)
+		return -ENOMEM;
+
+	ret = devm_mutex_init(display->dev, &display->lock);
+	if (ret)

drivers/auxdisplay/tm16xx_core.c new file +5 -0

+	/* Initialize main LED properties */
+	led_init.fwnode = dev_fwnode(dev);
+	/* max_brightness: handle default value and enforce hardware ceiling */
+	main->max_brightness = display->controller->max_brightness;
+	device_property_read_u32(dev, "max-brightness", &main->max_brightness);

drivers/auxdisplay/tm16xx_core.c new file +46 -0

+	i = 0;
+	led_init.devicename = dev_name(main->dev);
+	led_init.devname_mandatory = true;
+	led_init.default_label = "led";
+	leds_node = device_get_named_child_node(dev, "leds");
+	fwnode_for_each_available_child_node_scoped(leds_node, child) {
+		led_init.fwnode = child;
+		led = &display->leds[i];
+		/* Individual leds are hardware-constrained to on/off */
+		led->cdev.max_brightness = 1;
+		led->cdev.brightness_set = tm16xx_led_set;
+		led->cdev.flags = LED_RETAIN_AT_SHUTDOWN | LED_CORE_SUSPENDRESUME;
+
+		ret = led_classdev_register_ext(dev, &led->cdev, &led_init);
+		if (ret) {
+			dev_err_probe(dev, ret, "Failed to register LED %s\n",
+				      led->cdev.name);
+			goto unregister_leds;
+		}
+
+		i++;
+	}
+
+	ret = tm16xx_display_init(display);
+	if (ret) {
+		dev_err_probe(dev, ret, "Failed to initialize display\n");
+		goto unregister_leds;
+	}
+
+	ret = linedisp_attach(&display->linedisp, display->main_led.dev,
+			      display->num_digits, &tm16xx_linedisp_ops);
+	if (ret) {
+		dev_err_probe(dev, ret, "Failed to initialize line-display\n");
+		goto unregister_leds;
+	}
+
+	return 0;
+
+unregister_leds:
+	while (i--)
+		led_classdev_unregister(&display->leds[i].cdev);
+
+	led_classdev_unregister(main);
+	return ret;
+}
+EXPORT_SYMBOL_NS_GPL(tm16xx_probe, "TM16XX");

Add support for TM16xx-compatible auxiliary display controllers connected via the I2C bus.

The implementation includes:
- I2C driver registration and initialization
- Probe/remove logic for I2C devices
- Controller-specific handling and communication sequences
- Integration with the TM16xx core driver for common functionality

This allows platforms using TM16xx or compatible controllers over I2C to be managed by the TM16xx driver infrastructure.

drivers/auxdisplay/tm16xx_i2c.c new file +4 -0

+#include <linux/i2c.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/types.h>

drivers/auxdisplay/tm16xx_i2c.c new file +14 -0

+static int tm16xx_i2c_probe(struct i2c_client *client)
+{
+	const struct tm16xx_controller *controller;
+	struct tm16xx_display *display;
+	int ret;
+
+	controller = i2c_get_match_data(client);
+	if (!controller)
+		return -EINVAL;
+
+	display = devm_kzalloc(&client->dev, sizeof(*display), GFP_KERNEL);
+	if (!display)
+		return -ENOMEM;
+

+}

drivers/auxdisplay/tm16xx_i2c.c new file +8 -0

+	int ret;
+
+	ret = i2c_transfer(i2c->adapter, msgs, ARRAY_SIZE(msgs));
+	if (ret < 0)
+		return ret;
+
+	return (ret == ARRAY_SIZE(msgs)) ? 0 : -EIO;
+}

+}

drivers/auxdisplay/tm16xx_i2c.c new file +13 -0

+static int hbs658_init(struct tm16xx_display *display)
+{
+	const enum led_brightness brightness = display->main_led.brightness;
+	u8 cmd;
+	int ret;
+
+	/* Set data command */
+	cmd = TM16XX_CMD_WRITE | TM16XX_DATA_ADDR_AUTO;
+	hbs658_swap_nibbles(&cmd, 1);
+	ret = tm16xx_i2c_write(display, &cmd, 1);
+	if (ret)
+		return ret;
+

+}

drivers/auxdisplay/tm16xx_i2c.c new file +5 -0

+static int hbs658_keys(struct tm16xx_display *display)
+{
+	u8 cmd, keycode;
+	int col;
+	int ret;

Add support for TM16xx-compatible auxiliary display controllers connected via the SPI bus.

The implementation includes:
- SPI driver registration and initialization
- Probe/remove logic for SPI devices
- Controller-specific handling and communication sequences
- Integration with the TM16xx core driver for common functionality

This allows platforms using TM16xx or compatible controllers over SPI to be managed by the TM16xx driver infrastructure.

drivers/auxdisplay/tm16xx_spi.c new file +4 -0

+	}
+
+	return 0;
+}

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/[email protected]/

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.

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/[email protected]/

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.