[PATCH v3 2/5] dt-bindings: auxdisplay: Add Titan Micro Electronics TM1628

[Rob Herring]

On Thu, Feb 24, 2022 at 2:56 PM Heiner Kallweit <hkallweit1 at gmail.com> wrote:
>
> On 24.02.2022 21:22, Rob Herring wrote:
> > On Wed, Feb 23, 2022 at 06:59:31PM +0100, 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>
> >> Co-Developed-by: Heiner Kallweit <hkallweit1 at gmail.com>
> >> Signed-off-by: Heiner Kallweit <hkallweit1 at gmail.com>
> >> ---
> >> v3:
> >> - fix remaining YAML issues
> >> - use Co-Developed-by
> >> ---
> >>  .../bindings/auxdisplay/titanmec,tm1628.yaml  | 92 +++++++++++++++++++
> >>  1 file changed, 92 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml
> >> new file mode 100644
> >> index 000000000..2a1ef692c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml
> >> @@ -0,0 +1,92 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/auxdisplay/titanmec,tm1628.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Titan Micro Electronics TM1628 LED controller
> >> +
> >> +maintainers:
> >> +  - Andreas Färber <afaerber at suse.de>
> >> +  - Heiner Kallweit <hkallweit1 at gmail.com>
> >> +
> >> +allOf:
> >> +  - $ref: /schemas/spi/spi-peripheral-props.yaml#
> >> +
> >> +properties:
> >> +  compatible:
> >> +    const: titanmec,tm1628
> >> +
> >> +  reg:
> >> +    maxItems: 1
> >> +
> >
> >> +  grid:
> >> +    description:
> >> +      Mapping of display digit position to grid number.
> >> +      This implicitly defines the display size.
> >> +    $ref: /schemas/types.yaml#/definitions/uint8-array
> >> +    minItems: 1
> >> +    maxItems: 7
> >> +
> >> +  segment-mapping:
> >> +    description:
> >> +      Mapping of 7 segment display segments A-G to bit numbers 1-12.
> >> +    $ref: /schemas/types.yaml#/definitions/uint8-array
> >> +    minItems: 7
> >> +    maxItems: 7
> >
> > Are these properties useful for any 7 segment display or specific to
> > this controller?
> >
> Both are controller-specific. E.g. the functionally similar driver
> ht16k33 uses different properties.

Then they both need a vendor prefix.

> > The commit msg mentions 11 segment display. Does this need to be?:
> >
> > oneOf:
> >   - minItems: 7
> >     maxItems: 7
> >   - minItems: 11
> >     maxItems: 11
> >
> The controller would be able to drive 11 segments, but the driver
> supports 7 segments only (at least for now). Therefore a 11 segment
> display can be used, but only the 7 segment part will be active.
> All devices with this controller I've seen and heard of have
> 7 segment displays.

Bindings should be complete, not just what a particular version of a
driver supports. However, if all known h/w is just 7 seg, then it is
fine.

Rob