mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jean-François Lessard" <jefflessard3@gmail.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: "Andy Shevchenko" <andy@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	devicetree@vger.kernel.org, linux-leds@vger.kernel.org,
	linux-kernel@vger.kernel.org, "Andreas Färber" <afaerber@suse.de>,
	"Boris Gjenero" <boris.gjenero@gmail.com>,
	"Christian Hewitt" <christianshewitt@gmail.com>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Paolo Sabatino" <paolo.sabatino@gmail.com>,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>
Subject: Re: [PATCH v3 2/4] dt-bindings: auxdisplay: add Titan Micro Electronics TM16xx
Date: Thu, 21 Aug 2025 11:16:15 -0400	[thread overview]
Message-ID: <7CD0DD74-EB4A-414B-B22E-E9248ECF8CBC@gmail.com> (raw)
In-Reply-To: <20250821-funny-hasty-poodle-582053@kuoka>

Le 21 août 2025 03 h 48 min 21 s HAE, Krzysztof Kozlowski <krzk@kernel.org> a écrit :
>On Wed, Aug 20, 2025 at 12:31:15PM -0400, Jean-François Lessard wrote:
>> Add documentation for TM16xx-compatible 7-segment LED display controllers with
>> keyscan.
>
>Here and other patches - this is not wrapped.
>
>Please wrap commit message according to Linux coding style / submission
>process (neither too early nor over the limit):
>https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>

Well received. Will wrap at 75 instead of 80 for commit messages.

>> 
>> Signed-off-by: Jean-François Lessard <jefflessard3@gmail.com>
>> ---
>> 
>> Note: 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.
>> 
>>  .../bindings/auxdisplay/titanmec,tm16xx.yaml  | 471 ++++++++++++++++++
>>  1 file changed, 471 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 000000000..b563c6e1e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
>> @@ -0,0 +1,471 @@
>> +# 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 grid and segment indices are controller-specific.
>> +
>> +  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
>> +
>> +  Optional keypad scanning is supported when both 'linux,keymap' and
>> +  'poll-interval' properties are specified.
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      # Controllers with titanmec,tm1628 fallback
>
>Drop comment, obvious. Schema tells that.
>

Well received.

>> +      - items:
>> +          - enum:
>> +              - fdhisi,fd628
>> +              - princeton,pt6964
>> +              - wxicore,aip1628
>> +          - const: titanmec,tm1628
>> +      - const: titanmec,tm1628
>
>This is part of one enum
>
>> +      # Controllers with titanmec,tm1618 fallback
>> +      - items:
>> +          - enum:
>> +              - wxicore,aip1618
>> +          - const: titanmec,tm1618
>> +      - const: titanmec,tm1618
>
>Enum...
>
>> +      # Controllers with titanmec,tm1650 fallback
>> +      - items:
>> +          - enum:
>> +              - fdhisi,fd650
>> +              - wxicore,aip650
>> +          - const: titanmec,tm1650
>> +      - const: titanmec,tm1650
>> +      # Canonical standalone controllers
>
>Drop
>
>> +      - const: fdhisi,fd620
>> +      - const: fdhisi,fd655
>> +      - const: fdhisi,fd6551
>> +      - const: titanmec,tm1620
>> +      - const: titanmec,tm1638
>> +      - const: winrise,hbs658
>
>This is one enum
>

Well received. I followed the older style and will adopt the modern approach:

properties:
  compatible:
    items:
      - enum:
          - fdhisi,fd628
          - princeton,pt6964
          - wxicore,aip1628
          - wxicore,aip1618
          - fdhisi,fd650
          - wxicore,aip650
          - fdhisi,fd620
          - fdhisi,fd655
          - fdhisi,fd6551
          - titanmec,tm1620
          - titanmec,tm1638
          - winrise,hbs658
      - enum:
          - titanmec,tm1628
          - titanmec,tm1618
          - titanmec,tm1650
    minItems: 1
    maxItems: 2

Fallback relationships will be documented explicitly in the binding’s description.

>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  label:
>> +    description: Name of the entire device
>> +    default: display
>
>Huh? Why do you need label? Are you sure auxdisplays have labels?
>
>

Display integrates with the LED subsystem (/sys/class/leds), where label is
a standard property per leds/common.yaml. It ensures predictable LED class
device naming when multiple display instances are present, following established
LED subsystem conventions rather than general DT naming rules.

If helpful, I can add a $ref to /schemas/leds/common.yaml#/properties/label
or include its description explicitly.

>> +
>> +  default-brightness:
>> +    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.
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> +  max-brightness:
>> +    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.
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> +  linux,keymap:
>> +    $ref: /schemas/input/matrix-keymap.yaml#/properties/linux,keymap
>> +
>> +  poll-interval:
>> +    $ref: /schemas/input/input.yaml#/properties/poll-interval
>> +
>> +  autorepeat:
>> +    $ref: /schemas/input/input.yaml#/properties/autorepeat
>
>You rather miss some reference to input or touchscreen.
>

Well received. I will replace the individual references with:

allOf:
  - $ref: /schemas/input/input.yaml#
  - $ref: /schemas/input/matrix-keymap.yaml#

>> +
>> +  digits:
>> +    type: object
>> +    description: Container for 7-segment digit group definitions
>
>additionalProperties go here
>
>and blank line
>
>> +    properties:
>> +      "#address-cells":
>> +        const: 1
>> +      "#size-cells":
>> +        const: 0
>> +
>> +    patternProperties:
>> +      "^digit@[0-9]+$":
>> +        type: object
>
>unevaluatedProperties
>
>Blank line
>
>> +        properties:
>> +          reg:
>> +            description: Digit position identifier
>> +            maxItems: 1
>
>Blank line
>

Well received.

>> +          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
>> +        unevaluatedProperties: false
>> +
>> +    additionalProperties: false
>> +
>> +  leds:
>> +    type: object
>> +    description: Container for individual LED icon definitions
>> +    properties:
>> +      "#address-cells":
>> +        const: 2
>> +      "#size-cells":
>> +        const: 0
>> +
>> +    patternProperties:
>> +      "^led@[0-9]+,[0-9]+$":
>> +        type: object
>> +        $ref: /schemas/leds/common.yaml#
>> +        properties:
>> +          reg:
>> +            description:
>> +              Grid and segment indices as <grid segment> of this individual LED icon
>> +        required:
>> +          - reg
>> +        unevaluatedProperties: false
>> +
>> +    additionalProperties: false
>
>Best regards,
>Krzysztof
>

Thanks for your detailed feedback.

Best regards,
Jean-François Lessard

  reply	other threads:[~2025-08-21 15:16 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-20 16:31 [PATCH v3 0/4] auxdisplay: Add TM16xx 7-segment LED matrix display controllers driver Jean-François Lessard
2025-08-20 16:31 ` [PATCH v3 1/4] dt-bindings: vendor-prefixes: Add fdhisi, titanmec, princeton, winrise, wxicore Jean-François Lessard
2025-08-20 20:08   ` Conor Dooley
2025-08-21 19:35     ` Jean-François Lessard
2025-08-21 20:13       ` Conor Dooley
2025-08-22  2:35         ` Jean-François Lessard
2025-08-20 16:31 ` [PATCH v3 2/4] dt-bindings: auxdisplay: add Titan Micro Electronics TM16xx Jean-François Lessard
2025-08-21  7:48   ` Krzysztof Kozlowski
2025-08-21 15:16     ` Jean-François Lessard [this message]
2025-08-22  6:44       ` Krzysztof Kozlowski
2025-08-22 13:32         ` Jean-François Lessard
2025-08-20 16:31 ` [PATCH v3 3/4] auxdisplay: Add TM16xx 7-segment LED matrix display controllers driver Jean-François Lessard
2025-08-21  7:43   ` Krzysztof Kozlowski
2025-08-21 16:42     ` Jean-François Lessard
2025-08-21  8:08   ` Andy Shevchenko
2025-08-21 19:04     ` Jean-François Lessard
2025-08-21 20:19       ` Andy Shevchenko
2025-08-22  2:20         ` Jean-François Lessard
2025-08-22  6:08           ` Andy Shevchenko
2025-08-22 13:50             ` Jean-François Lessard
2025-08-27  5:32   ` kernel test robot
2025-08-20 16:31 ` [PATCH v3 4/4] MAINTAINERS: Add entry for TM16xx driver Jean-François Lessard
2025-08-20 19:08   ` Andy Shevchenko
2025-08-20 19:51     ` Conor Dooley
2025-08-20 20:29       ` Andy Shevchenko
2025-08-21 17:40         ` Conor Dooley
2025-08-21 19:33           ` Andy Shevchenko
2025-08-21 19:35             ` Andy Shevchenko
2025-08-21 20:11               ` Conor Dooley
2025-08-21 20:23                 ` Andy Shevchenko

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=7CD0DD74-EB4A-414B-B22E-E9248ECF8CBC@gmail.com \
    --to=jefflessard3@gmail.com \
    --cc=afaerber@suse.de \
    --cc=andy@kernel.org \
    --cc=boris.gjenero@gmail.com \
    --cc=christianshewitt@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=hkallweit1@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=paolo.sabatino@gmail.com \
    --cc=robh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®