Re: [PATCH v5 2/6] dt-bindings: auxdisplay: Add Titan Micro Electronics TM1628

Hi Robin,

On Fri, Mar 18, 2022 at 9:50 PM Robin Murphy [off-list ref] wrote:

On 2022-02-25 21:13, Heiner Kallweit wrote:

quoted

Add a YAML schema binding for TM1628 auxdisplay
(7/11-segment LED) controller.

This patch is partially based on previous work from
Andreas Färber [off-list ref].

Co-developed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>

quoted

--- /dev/null
+++ b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml

quoted

+
+patternProperties:
+  "^.*@[1-7],([1-9]|1[0-6])$":
+    type: object
+    $ref: /schemas/leds/common.yaml#
+    unevaluatedProperties: false
+    description: |
+      Properties for a single LED.
+
+    properties:
+      reg:
+        description: |
+          1-based grid number, followed by 1-based segment bit number.
+        maxItems: 1
+
+    required:
+      - reg

I'm concerned that this leaves us no room to support the additional
keypad functionality in future. Having now double-checked a datasheet,
the inputs are also a two-dimensional mux (sharing the segment lines),
so the device effectively has two distinct but numerically-overlapping
child address spaces - one addressed by (grid,segment) and the other by
(segment,key).

Sounds similar to HT16K33?

Rob, Krysztof, any thoughts on the best DT idiom to leave accommodation
for that? I'm thinking either require an intermediate node to contain
each notional address space, or perhaps add another leading address cell
to select between them? I don't believe any of these things have further
functionality beyond that.

The problem with these devices is that there are thousands of different
ways to wire them, and coming up with a generic wiring description in
DT and writing code to handle that can be very hard.

For HT16K33 non-dot-matrix wirings, I just added extra compatible
values matching the wiring of a few known devices[1].  That way the
driver can handle them efficiently.
It does have the disadvantage that adding support for new devices
means introducing more compatible values, and adding more code.

Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml

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