[PATCH v5 2/6] dt-bindings: auxdisplay: Add Titan Micro Electronics TM1628
Robin Murphy
robin.murphy at arm.com
Fri Mar 18 13:50:19 PDT 2022
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>
> ---
> v5:
> - add vendor prefix to driver-specific properties
> ---
> .../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
> +
> + titanmec,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
> +
> + titanmec,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
> +
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 0
> +
> +required:
> + - compatible
> + - reg
Would it be fair to say that "spi-lsb-first" and "spi-3wire" are also
required? The chips aren't configurable so won't exactly be usable any
other way. Furthermore I believe the transmission format actually works
out equivalent to SPI mode 3, so should warrant "spi-cpha" and
"spi-cpol" as well.
> +
> +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).
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.
Thanks,
Robin.
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/leds/common.h>
> +
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led-controller at 0 {
> + compatible = "titanmec,tm1628";
> + reg = <0>;
> + spi-3-wire;
> + spi-lsb-first;
> + spi-max-frequency = <500000>;
> + titanmec,grid = /bits/ 8 <4 3 2 1>;
> + titanmec,segment-mapping = /bits/ 8 <4 5 6 1 2 3 7>;
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + alarm at 5,4 {
> + reg = <5 4>;
> + function = LED_FUNCTION_ALARM;
> + };
> + };
> + };
> +...
More information about the linux-amlogic
mailing list