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

[Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>]

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?

> 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@xxxxxxxxxxxxxx

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