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

[Robin Murphy]

On 2022-03-21 08:12, Geert Uytterhoeven wrote:
> Hi Robin,
> 
> On Fri, Mar 18, 2022 at 9:50 PM Robin Murphy <robin.murphy at arm.com> 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 at suse.de>.
>>>
>>> Co-developed-by: Andreas Färber <afaerber at suse.de>
>>> Signed-off-by: Andreas Färber <afaerber at suse.de>
>>> Signed-off-by: Heiner Kallweit <hkallweit1 at gmail.com>
> 
>>> --- /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.