From: Rob Herring <robh@kernel.org>
To: "Jean-François Lessard" <jefflessard3@gmail.com>
Cc: Andy Shevchenko <andy@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v5 3/7] dt-bindings: auxdisplay: add Titan Micro Electronics TM16xx
Date: Wed, 1 Oct 2025 21:44:31 -0500 [thread overview]
Message-ID: <20251002024431.GA2926696-robh@kernel.org> (raw)
In-Reply-To: <20250926141913.25919-4-jefflessard3@gmail.com>
On Fri, Sep 26, 2025 at 10:19:04AM -0400, Jean-François Lessard wrote:
> Add documentation for TM16xx-compatible 7-segment LED display controllers
> with keyscan.
>
> Signed-off-by: Jean-François Lessard <jefflessard3@gmail.com>
> ---
>
> Notes:
> The 'segments' property is intentionally not vendor-prefixed as it
> defines a generic hardware description concept applicable to any
> 7-segment display controller. The property describes the fundamental
> grid/segment coordinate mapping that is controller-agnostic and could
> be reused by other LED matrix display bindings. Similar to how 'gpios'
> describes GPIO connections generically, 'segments' describes segment
> connections in a standardized way using uint32-matrix format.
>
> The property uses explicit coordinate pairs to handle real-world
> hardware variations. Some board manufacturers use standard layouts
> (same grid, different segments per digit) while others use transposed
> layouts (same segment, different grids per digit). The coordinate-pair
> approach accommodates both patterns without requiring separate arrays
> or boolean flags, as confirmed acceptable by DT maintainers.
>
> .../bindings/auxdisplay/titanmec,tm16xx.yaml | 463 ++++++++++++++++++
> MAINTAINERS | 5 +
> 2 files changed, 468 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
>
> diff --git a/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
> new file mode 100644
> index 000000000000..d324023bbffb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
> @@ -0,0 +1,463 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/auxdisplay/titanmec,tm16xx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Auxiliary displays based on TM16xx and compatible LED controllers
> +
> +maintainers:
> + - Jean-François Lessard <jefflessard3@gmail.com>
> +
> +description: |
> + LED matrix controllers used in auxiliary display devices that drive individual
> + LED icons and 7-segment digit groups through a grid/segment addressing scheme.
> + Controllers manage a matrix of LEDs organized as grids (columns/banks in
> + vendor datasheets) and segments (rows/bit positions in vendor datasheets).
> + Maximum brightness and grid/segment indices are controller-specific.
> + Controller-specific maximum are validated in the driver.
> +
> + The controller is agnostic of the display layout. Board-specific LED wiring is
> + described through child nodes that specify grid/segment coordinates for
> + individual icons and segment mapping for 7-segment digits.
> +
> + The bindings use separate 'leds' and 'digits' containers to accommodate
> + different addressing schemes:
> + - LEDs use 2-cell addressing (grid, segment) for matrix coordinates
> + - Digits use 1-cell addressing with explicit segment mapping
> +
> + The controller node exposes a logical LED-like control for the aggregate
> + display brightness. Child nodes describe individual icons and 7-seg digits.
> + The top-level control supports only label and brightness-related properties
> + and does not support other common LED properties such as color or function.
> + Child LED nodes use the standard LED binding.
> +
> + Optional keypad scanning is supported when both 'linux,keymap' and
> + 'poll-interval' properties are specified.
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - fdhisi,fd628
> + - princeton,pt6964
> + - wxicore,aip1628
> + - const: titanmec,tm1628
> + - items:
> + - enum:
> + - wxicore,aip1618
> + - const: titanmec,tm1618
> + - items:
> + - enum:
> + - fdhisi,fd650
> + - wxicore,aip650
> + - const: titanmec,tm1650
> + - enum:
> + - fdhisi,fd620
> + - fdhisi,fd655
> + - fdhisi,fd6551
> + - titanmec,tm1618
> + - titanmec,tm1620
> + - titanmec,tm1628
> + - titanmec,tm1638
> + - titanmec,tm1650
> + - winrise,hbs658
> +
> + reg:
> + maxItems: 1
> +
> + label:
> + description:
> + The label for the top-level LED. If omitted, the label is taken from the
> + node name (excluding the unit address). It has to uniquely identify a
> + device, i.e. no other LED class device can be assigned the same label.
> +
> + max-brightness:
> + minimum: 0 # 0=off
> + maximum: 8 # Maximum across all TM16xx controllers
> + description:
> + Normally the maximum brightness is determined by the hardware and this
> + property is not required. This property is used to put a software limit
> + on the brightness apart from what the driver says, as it could happen
> + that a LED can be made so bright that it gets damaged or causes damage
> + due to restrictions in a specific system, such as mounting conditions.
> +
> + default-brightness:
> + minimum: 0 # 0=off
> + maximum: 8 # Maximum across all TM16xx controllers
> + description:
> + Brightness to be set if LED's default state is on. Used only during
> + initialization. If the option is not set then max brightness is used.
> +
> + digits:
> + type: object
> + description: Container for 7-segment digit group definitions
> + additionalProperties: false
> +
> + properties:
> + "#address-cells":
> + const: 1
> + "#size-cells":
> + const: 0
> +
> + patternProperties:
> + "^digit@[0-9]+$":
Unit addresses are typically hex, so: [0-9a-f]+
> + type: object
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + description:
> + Digit position identifier numbered sequentially left-to-right,
> + with reg=0 representing the leftmost digit position as displayed
> + to the user.
> + maxItems: 1
> +
> + segments:
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> + description: |
> + Array of grid/segment coordinate pairs for each 7-segment position.
> + Each entry is <grid segment> mapping to standard 7-segment positions
> + in order: a, b, c, d, e, f, g
> +
> + Standard 7-segment layout:
> + aaa
> + f b
> + f b
> + ggg
> + e c
> + e c
> + ddd
> + items:
> + items:
> + - description: Grid index
> + - description: Segment index
> + minItems: 7
> + maxItems: 7
> +
> + required:
> + - reg
> + - segments
> +
> + leds:
> + type: object
> + description: Container for individual LED icon definitions
> + additionalProperties: false
> +
> + properties:
> + "#address-cells":
> + const: 2
> + "#size-cells":
> + const: 0
> +
> + patternProperties:
> + "^led@[0-9]+,[0-9]+$":
Again, hex please.
I assume this is <grid>,<segment>? Please add a description for the
node and say that.
> + type: object
> + $ref: /schemas/leds/common.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + description:
> + Grid and segment indices as <grid segment> of this individual LED icon
> +
> + required:
> + - reg
> +
> +dependencies:
> + poll-interval:
> + - linux,keymap
> + linux,keymap:
> + - poll-interval
> + autorepeat:
> + - linux,keymap
> + - poll-interval
> +
> +required:
> + - compatible
> + - reg
> +
> +allOf:
> + - $ref: /schemas/leds/common.yaml#
> + properties:
> + color: false
> + function: false
> + function-enumerator: false
> + - $ref: /schemas/input/input.yaml#
> + - $ref: /schemas/input/matrix-keymap.yaml#
> + # SPI controllers require 3-wire (combined MISO/MOSI line)
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - fdhisi,fd620
> + - fdhisi,fd628
> + - princeton,pt6964
> + - titanmec,tm1618
> + - titanmec,tm1620
> + - titanmec,tm1628
> + - titanmec,tm1638
> + - wxicore,aip1618
> + - wxicore,aip1628
> + then:
> + $ref: /schemas/spi/spi-peripheral-props.yaml#
> + properties:
> + spi-3wire: true
You can drop properties.
> + required:
> + - spi-3wire
With those nits fixed,
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
next prev parent reply other threads:[~2025-10-02 2:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 14:19 [PATCH v5 0/7] auxdisplay: Add TM16xx 7-segment LED matrix display controllers driver Jean-François Lessard
2025-09-26 14:19 ` [PATCH v5 1/7] dt-bindings: vendor-prefixes: Add fdhisi, titanmec, princeton, winrise, wxicore Jean-François Lessard
2025-09-26 14:19 ` [PATCH v5 2/7] dt-bindings: leds: add default-brightness property to common.yaml Jean-François Lessard
2025-10-02 2:26 ` Rob Herring (Arm)
2025-10-09 15:06 ` (subset) " Lee Jones
2025-09-26 14:19 ` [PATCH v5 3/7] dt-bindings: auxdisplay: add Titan Micro Electronics TM16xx Jean-François Lessard
2025-10-02 2:44 ` Rob Herring [this message]
2025-10-02 2:58 ` Jean-François Lessard
2025-10-31 17:59 ` Jean-François Lessard
2025-09-26 14:19 ` [PATCH v5 4/7] auxdisplay: Add TM16xx 7-segment LED matrix display controllers driver Jean-François Lessard
2025-10-31 9:41 ` Andy Shevchenko
2025-10-31 17:17 ` Jean-François Lessard
2025-11-01 17:06 ` Andy Shevchenko
2025-11-02 17:04 ` Jean-François Lessard
2025-09-26 14:19 ` [PATCH v5 5/7] auxdisplay: TM16xx: Add keypad support for scanning matrix keys Jean-François Lessard
2025-09-26 14:19 ` [PATCH v5 6/7] auxdisplay: TM16xx: Add support for I2C-based controllers Jean-François Lessard
2025-11-24 7:31 ` Andy Shevchenko
2025-09-26 14:19 ` [PATCH v5 7/7] auxdisplay: TM16xx: Add support for SPI-based controllers Jean-François Lessard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251002024431.GA2926696-robh@kernel.org \
--to=robh@kernel.org \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=jefflessard3@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.