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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022-03-21 08:12, Geert Uytterhoeven wrote:
Hi Robin,

On Fri, Mar 18, 2022 at 9:50 PM Robin Murphy <robin.murphy@xxxxxxx> wrote:
On 2022-02-25 21:13, Heiner Kallweit wrote:
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 <afaerber@xxxxxxx>.

Co-developed-by: Andreas Färber <afaerber@xxxxxxx>
Signed-off-by: Andreas Färber <afaerber@xxxxxxx>
Signed-off-by: Heiner Kallweit <hkallweit1@xxxxxxxxx>

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

+
+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?

/me searches up a datasheet...

Keypad-wise, it appears so, however the display side of this 1618/1628/1638 family is very much tuned for 7-segment displays rather than arbitrary dot-matrix ones.

I do recall when I was digging a few years ago, turning up an old Holtek VFD driver which looked suspiciously like it might be the origin of the particular 3-wire protocol and command set (including weird non-linear brightness scale) which all these LED driver clones seem to borrow from, but I can't now remember the part number :(

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

I think the display side of Heiner's binding is fine for what these chips can do - I've finally had a bit more time to play with this series, and (with minor driver hacks) it works just fine to describe my TM1638 breakout board with an 8-digit display, where segments 8 and 9 of each grid are respectively a decimal point and a discrete indicator LED, managed as separate LED nodes.

However, I think you've indirectly addressed my outstanding concern there - I wasn't aware of the "linux,keymap" property, but since that brings its own implicit (row,column) addresses distinct from the DT address space, it looks like that might be sufficient as a neat standard way to extend this binding in future *without* any other changes.

Thanks,
Robin.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux