[PATCH V3 0/3] Introduce a generic register settings dt-binding

[PATCH V3 0/3] Introduce a generic register settings dt-binding

[Rajesh Gumasta]

SoCs such as NVIDIA Tegra require specific configuration of their
register fields based on various operating mode to achieve optimal
performance and reliability.

In practice, this often boils down to writing specific values into
specific register fields for a given use-case. For instance, configuring
a controller might require programming a specific values into various
register fields. This can be static values that are always written to
the register fields for a given mode of operation, such as setup/hold
times for I2C high-speed mode.

While this data could be stored in the driver itself, over time this
will bloat the driver by adding the necessary data for each SoC that is
supported. Given that this data is SoC or platform specific, it would be
better to store this data in device-tree. This patch proposes a generic
device-tree binding for describing register configurations that can be
used for any SoC. The code for parsing and utilising these bindings is
not included at this time because the initial goal is to see if such a
device-tree binding would be acceptable for storing such data. This is a
follow-on to the series 'Introduce Tegra register config settings' [0].

The examples included demonstrate the use of 'reg-settings' node with
MMC and I2C controllers, however, it is designed to be applicable to
any controller that requires specific register settings for a given
operating mode.

Example device-tree node:

/* MMC register setting example */
  mmc@700b0000 {

    reg-settings {

      default-settings {
        /* Default register setting */
        nvidia,num-tuning-iterations = <0>;
      };

      sdr50 {
        /* SDR50 register setting */
        nvidia,num-tuning-iterations = <4>;
      };

      sdr104 {
        /* SDR104 register setting */
        nvidia,num-tuning-iterations = <2>;
      };

      hs200 {
        /* HS200 register setting */
        nvidia,num-tuning-iterations = <2>;
      };
    };
  };


/* I2C register setting example */

  i2c@3160000 {
    i2c-bus {
      #address-cells = <1>;
      #size-cells = <0>;
    };

    reg-settings {
      default-settings {
        /* Default settings applied during initialization */
        scl-high-period-cycles = <3>;
        scl-low-period-cycles = <8>;
      };

      fast {
        /* fast mode settings */
        scl-high-period-cycles = <2>;
        scl-low-period-cycles = <2>;
        bus-free-time-cycles = <2>;
        stop-setup-time-cycles = <2>;
        start-hold-time-cycles = <2>;
        start-setup-time-cycles = <2>;
      };

      fastplus {
        /* fast plus mode settings */
        scl-high-period-cycles = <2>;
        scl-low-period-cycles = <2>;
        bus-free-time-cycles = <2>;
        stop-setup-time-cycles = <2>;
        start-hold-time-cycles = <2>;
        start-setup-time-cycles = <2>;
      };

      standard {
        /* Standard mode settings */
        scl-high-period-cycles = <7>;
        scl-low-period-cycles = <8>;
        bus-free-time-cycles = <8>;
        stop-setup-time-cycles = <8>;
        start-hold-time-cycles = <8>;
        start-setup-time-cycles = <8>;
      };
    };
  };

A few things to note:
1. This series only includes the device-tree bindings and no example
   code for using these. This is intentional because unless we can agree
   that it is suitable to use device-tree for this then there is little
   value in reviewing any code. The previous versions did include code
   but we have omitted this for now to focus on the bindings.
2. This was discussed during the device-tree session at the 2024
   plumbers conference and there was interest in this from several
   other silicon vendors that would also like a way to describe register
   configurations in device-tree.
3. The examples and example properties are based upon some
   configurations used for Tegra. The property names, units, etc, are
   simply examples that could be refined if deemed generic/common
   properties or made vendor specific if not. What we are looking for
   is some feedback on the overall structure, with having a top-level
   'reg-settings' node and child nodes with configuration for each
   use-case.
4. The I2C bindings are known to fail the binding checks if the fix for
   the I2C schema is not applied [1].
5. The file i2c-controller-common.yaml is added as a place-holder for
   defining the 'reg-settings' nodes for I2C controllers. However, this
   is very much a place-holder for demostration purposes. Ideally, these
   nodes would be part of the main I2C schema.

Changes in V3:
- Renamed as 'generic register settings' as opposed to 'Tegra register
  config settings'.
- Dropped all the associated code to focus on the DT bindings for now.
- Added a 'register-settings.yaml' as a top level binding.
- Made I2C register-setting timing properties generic I2C properties.

Changes in V2:
- Move config settings to a new node
- Use phandles to refer config settings in device node
- Update subject of dt patches

[0] https://lore.kernel.org/linux-tegra/20240701151231.29425-1-kyarlagadda@nvidia.com/
[1] https://lore.kernel.org/linux-tegra/20250709142452.249492-1-jonathanh@nvidia.com/

Rajesh Gumasta (3):
  dt-binding: Add register-settings binding
  dt-binding: i2c: nvidia,tegra20-i2c: Add register-setting support
  dt-binding: mmc: tegra: Add register-setting support

 .../bindings/i2c/i2c-controller-common.yaml   | 73 +++++++++++++++++++
 .../bindings/i2c/nvidia,tegra20-i2c.yaml      | 64 +++++++++++++++-
 .../bindings/mmc/mmc-controller-common.yaml   | 24 ++++++
 .../bindings/mmc/nvidia,tegra20-sdhci.yaml    | 48 ++++++++++++
 .../bindings/regset/register-settings.yaml    | 31 ++++++++
 5 files changed, 237 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-controller-common.yaml
 create mode 100644 Documentation/devicetree/bindings/regset/register-settings.yaml

-- 
2.50.1

[PATCH V3 1/3] dt-binding: Add register-settings binding

[Rajesh Gumasta]

Add a new device-tree binding for a 'reg-settings' node that can be
added to any device. This 'reg-settings' is used to populate register
settings that need to be programmed for a given operating mode of the
device. An example usage of the 'reg-settings' node is shown below for
the NVIDIA Tegra MMC controller which needs to program a specific
'num-tuning-iterations' value in a register field for each operating
mode:

  mmc@700b0000 {

    reg-settings {

      default-settings {
        /* Default register setting */
        nvidia,num-tuning-iterations = <0>;
      };

      sdr50 {
        /* SDR50 register setting */
        nvidia,num-tuning-iterations = <4>;
      };

      sdr104 {
        /* SDR104 register setting */
        nvidia,num-tuning-iterations = <2>;
      };

      hs200 {
        /* HS200 register setting */
        nvidia,num-tuning-iterations = <2>;
      };
    };
  };

The 'reg-settings' child nodes are defined according to the operating
modes supported for a given device. Properties within each operating
mode are then defined by the bindings for the devices that require them.

Signed-off-by: Rajesh Gumasta <rgumasta@nvidia.com>
---
 .../bindings/regset/register-settings.yaml    | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regset/register-settings.yaml

diff --git a/Documentation/devicetree/bindings/regset/register-settings.yaml b/Documentation/devicetree/bindings/regset/register-settings.yaml
new file mode 100644
index 000000000000..4366cdd72813
--- /dev/null
+++ b/Documentation/devicetree/bindings/regset/register-settings.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regset/register-settings.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Register Settings
+
+maintainers:
+  - Thierry Reding <thierry.reding@gmail.com>
+  - Krishna Yarlagadda <kyarlagadda@nvidia.com>
+  - Rajesh Gumasta <rgumasta@nvidia.com>
+  - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+  Register Settings provides a generic way to specify register configurations
+  for any hardware controllers. Settings are specified under a "reg-settings"
+  sub-node under the controller device tree node. It allows defining both
+  default and operating mode specific register settings in the device tree.
+
+properties:
+  reg-settings:
+    type: object
+    description: |
+      Container node for register settings configurations. Each child node
+      represents a specific configuration mode or operating condition.
+
+    additionalProperties:
+      type: object
+
+additionalProperties: true
-- 
2.50.1

[PATCH V3 2/3] dt-binding: i2c: nvidia,tegra20-i2c: Add register-setting support

[Rajesh Gumasta]

Add register setting support for the NVIDIA Tegra20 I2C controllers. An
i2c-controller-common.yaml binding document has been added a top-level
binding document so that all I2C controllers can use this binding. This
new binding document defines some generic register setting properties
for I2C and some standard I2C operating modes that the register settings
need to be programmed for. This new binding document is used by the
NVIDIA Tegra20 I2C binding to enable the use of the 'reg-settings'
binding for this device.

Signed-off-by: Rajesh Gumasta <rgumasta@nvidia.com>
---
 .../bindings/i2c/i2c-controller-common.yaml   | 73 +++++++++++++++++++
 .../bindings/i2c/nvidia,tegra20-i2c.yaml      | 64 +++++++++++++++-
 2 files changed, 134 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-controller-common.yaml

diff --git a/Documentation/devicetree/bindings/i2c/i2c-controller-common.yaml b/Documentation/devicetree/bindings/i2c/i2c-controller-common.yaml
new file mode 100644
index 000000000000..3b5b75d4b98a
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-controller-common.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-controller-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2C Controller Common Properties
+
+maintainers:
+  - Thierry Reding <thierry.reding@gmail.com>
+  - Krishna Yarlagadda <kyarlagadda@nvidia.com>
+  - Rajesh Gumasta <rgumasta@nvidia.com>
+  - Jon Hunter <jonathanh@nvidia.com>
+
+description:
+  These properties are common to multiple I2C controllers.
+
+definitions:
+  reg-settings:
+    properties:
+      scl-low-period-cycles:
+        $ref: /schemas/types.yaml#/definitions/uint8
+        description: Low period of the SCL clock in parent clock cycles.
+      scl-high-period-cycles:
+        $ref: /schemas/types.yaml#/definitions/uint8
+        description: High period of the SCL clock in parent clock cycles.
+      bus-free-time-cycles:
+        $ref: /schemas/types.yaml#/definitions/uint8
+        description: Bus free time between STOP and START conditions in parent
+          clock cycles.
+      start-setup-time-cycles:
+        $ref: /schemas/types.yaml#/definitions/uint8
+        description: Set-up time for START condition in parent clock cycles.
+      stop-setup-time-cycles:
+        $ref: /schemas/types.yaml#/definitions/uint8
+        description: Set-up time for STOP condition in parent clock cycles.
+      start-hold-time-cycles:
+        $ref: /schemas/types.yaml#/definitions/uint8
+        description: Hold time for STOP condition in parent clock cycles.
+
+properties:
+  reg-settings:
+    $ref: /schemas/regset/register-settings.yaml
+
+    properties:
+      default-setting:
+        type: object
+        $ref: "#/definitions/reg-settings"
+        description:
+          Default register settings.
+
+      fast:
+        type: object
+        $ref: "#/definitions/reg-settings"
+        description:
+          Register settings for I2C fast operating mode.
+
+      fastplus:
+        type: object
+        $ref: "#/definitions/reg-settings"
+        description:
+          Register settings for I2C fastplus operating mode.
+
+      standard:
+        type: object
+        $ref: "#/definitions/reg-settings"
+        description:
+          Register settings for I2C standard operating mode.
+
+allOf:
+  - $ref: /schemas/i2c/i2c-controller.yaml
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
index 6b6f6762d122..695ce5ada7d5 100644
--- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
@@ -119,6 +119,28 @@ properties:
       - const: rx
       - const: tx
 
+  reg-settings:
+    $ref: /schemas/i2c/i2c-controller-common.yaml#/properties/reg-settings
+
+    properties:
+      default-setting:
+        $ref: /schemas/i2c/i2c-controller-common.yaml#/definitions/reg-settings
+        unevaluatedProperties: false
+
+      fast:
+        $ref: /schemas/i2c/i2c-controller-common.yaml#/definitions/reg-settings
+        unevaluatedProperties: false
+
+      fastplus:
+        $ref: /schemas/i2c/i2c-controller-common.yaml#/definitions/reg-settings
+        unevaluatedProperties: false
+
+      standard:
+        $ref: /schemas/i2c/i2c-controller-common.yaml#/definitions/reg-settings
+        unevaluatedProperties: false
+
+    unevaluatedProperties: false
+
 required:
   - compatible
   - reg
@@ -127,7 +149,7 @@ required:
   - clock-names
 
 allOf:
-  - $ref: /schemas/i2c/i2c-controller.yaml
+  - $ref: /schemas/i2c/i2c-controller-common.yaml
   - if:
       properties:
         compatible:
@@ -206,6 +228,42 @@ examples:
         dmas = <&apbdma 16>, <&apbdma 16>;
         dma-names = "rx", "tx";
 
-        #address-cells = <1>;
-        #size-cells = <0>;
+        i2c-bus {
+            #address-cells = <1>;
+            #size-cells = <0>;
+        };
+
+        reg-settings {
+            default-setting {
+                scl-high-period-cycles = /bits/ 8 <3>;
+                scl-low-period-cycles = /bits/ 8 <8>;
+            };
+
+            fast {
+                scl-high-period-cycles = /bits/ 8 <2>;
+                scl-low-period-cycles = /bits/ 8 <2>;
+                bus-free-time-cycles = /bits/ 8 <2>;
+                stop-setup-time-cycles = /bits/ 8 <2>;
+                start-hold-time-cycles = /bits/ 8 <2>;
+                start-setup-time-cycles = /bits/ 8 <2>;
+            };
+
+            fastplus {
+                scl-high-period-cycles = /bits/ 8 <2>;
+                scl-low-period-cycles = /bits/ 8 <2>;
+                bus-free-time-cycles = /bits/ 8 <2>;
+                stop-setup-time-cycles = /bits/ 8 <2>;
+                start-hold-time-cycles = /bits/ 8 <2>;
+                start-setup-time-cycles = /bits/ 8 <2>;
+            };
+
+            standard {
+                scl-high-period-cycles = /bits/ 8 <7>;
+                scl-low-period-cycles = /bits/ 8 <8>;
+                bus-free-time-cycles = /bits/ 8 <8>;
+                stop-setup-time-cycles = /bits/ 8 <8>;
+                start-hold-time-cycles = /bits/ 8 <8>;
+                start-setup-time-cycles = /bits/ 8 <8>;
+            };
+        };
     };
-- 
2.50.1

[PATCH V3 3/3] dt-binding: mmc: tegra: Add register-setting support

[Rajesh Gumasta]

Add register setting support for the NVIDIA Tegra20 MMC controllers. The
top-level 'reg-settings' node and child nodes for each MMC operating mode
supported are defined in the mmc-controller-common.yaml binding. The
NVIDIA specific register setting property is defined in the
nvidia,tegra20-sdhci.yaml.

Signed-off-by: Rajesh Gumasta <rgumasta@nvidia.com>
---
 .../bindings/mmc/mmc-controller-common.yaml   | 24 ++++++++++
 .../bindings/mmc/nvidia,tegra20-sdhci.yaml    | 48 +++++++++++++++++++
 2 files changed, 72 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
index 9a7235439759..0bdebc6454d8 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
@@ -308,6 +308,30 @@ properties:
       sequence. To successfully detect an (e)MMC/SD/SDIO card, that
       power sequence must be maintained while initializing the card.
 
+  reg-settings:
+    $ref: /schemas/regset/register-settings.yaml
+
+    properties:
+      default-settings:
+        type: object
+        description:
+          Default MMC register settings.
+
+      sdr50:
+        type: object
+        description:
+          Register settings for MMC sdr50 operating mode.
+
+      sdr104:
+        type: object
+        description:
+          Register settings for MMC sdr104 operating mode.
+
+      hs200:
+        type: object
+        description:
+          Register settings for MMC hs200 operating mode.
+
 patternProperties:
   "^.*@[0-9]+$":
     type: object
diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
index 72987f0326a1..a78b2bd92b18 100644
--- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
@@ -17,6 +17,15 @@ description: |
   This file documents differences between the core properties described by
   mmc-controller.yaml and the properties for the Tegra SDHCI controller.
 
+definitions:
+  reg-settings:
+    properties:
+      nvidia,num-tuning-iterations:
+        description: The number of tuning iterations to be used by tuning circuit.
+        $ref: /schemas/types.yaml#/definitions/uint8
+        minimum: 0
+        maximum: 4
+
 properties:
   compatible:
     oneOf:
@@ -177,6 +186,27 @@ properties:
       operates at a 1.8 V fixed I/O voltage.
     $ref: /schemas/types.yaml#/definitions/flag
 
+  reg-settings:
+    $ref: /schemas/mmc/mmc-controller-common.yaml#/properties/reg-settings
+
+    properties:
+      default-settings:
+        $ref: "#/definitions/reg-settings"
+        unevaluatedProperties: false
+
+      sdr50:
+        $ref: "#/definitions/reg-settings"
+        unevaluatedProperties: false
+
+      sdr104:
+        $ref: "#/definitions/reg-settings"
+        unevaluatedProperties: false
+
+      hs200:
+        $ref: "#/definitions/reg-settings"
+        unevaluatedProperties: false
+    unevaluatedProperties: false
+
 required:
   - compatible
   - reg
@@ -310,4 +340,22 @@ examples:
                           <&tegra_car TEGRA210_CLK_PLL_C4>;
         assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_C4_OUT0>;
         assigned-clock-rates = <200000000>, <1000000000>, <1000000000>;
+
+        reg-settings {
+            default-settings {
+                nvidia,num-tuning-iterations = /bits/ 8 <0>;
+            };
+
+            sdr50 {
+                nvidia,num-tuning-iterations = /bits/ 8 <4>;
+            };
+
+            sdr104 {
+                nvidia,num-tuning-iterations = /bits/ 8 <2>;
+            };
+
+            hs200 {
+                nvidia,num-tuning-iterations = /bits/ 8 <2>;
+            };
+        };
     };
-- 
2.50.1

Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Krzysztof Kozlowski]

On 25/07/2025 07:22, Rajesh Gumasta wrote:
> +description: |
> +  Register Settings provides a generic way to specify register configurations
> +  for any hardware controllers. Settings are specified under a "reg-settings"
> +  sub-node under the controller device tree node. It allows defining both
> +  default and operating mode specific register settings in the device tree.
> +
> +properties:
> +  reg-settings:
> +    type: object
> +    description: |
> +      Container node for register settings configurations. Each child node
> +      represents a specific configuration mode or operating condition.
> +
> +    additionalProperties:
> +      type: object

I don't understand what does this binding bring. It is empty.

Best regards,
Krzysztof

Re: [PATCH V3 0/3] Introduce a generic register settings dt-binding

[Krzysztof Kozlowski]

On 25/07/2025 07:22, Rajesh Gumasta wrote:
> 4. The I2C bindings are known to fail the binding checks if the fix for
>    the I2C schema is not applied [1].
> 5. The file i2c-controller-common.yaml is added as a place-holder for
>    defining the 'reg-settings' nodes for I2C controllers. However, this
>    is very much a place-holder for demostration purposes. Ideally, these
>    nodes would be part of the main I2C schema.
> 
> Changes in V3:
> - Renamed as 'generic register settings' as opposed to 'Tegra register
>   config settings'.
> - Dropped all the associated code to focus on the DT bindings for now.
> - Added a 'register-settings.yaml' as a top level binding.
> - Made I2C register-setting timing properties generic I2C properties.


Where are lore links to previous discussions? There is no v2 nor v1 in
inbox.

Best regards,
Krzysztof

Re: [PATCH V3 2/3] dt-binding: i2c: nvidia,tegra20-i2c: Add register-setting support

[Rob Herring (Arm)]

On Fri, 25 Jul 2025 10:52:24 +0530, Rajesh Gumasta wrote:
> Add register setting support for the NVIDIA Tegra20 I2C controllers. An
> i2c-controller-common.yaml binding document has been added a top-level
> binding document so that all I2C controllers can use this binding. This
> new binding document defines some generic register setting properties
> for I2C and some standard I2C operating modes that the register settings
> need to be programmed for. This new binding document is used by the
> NVIDIA Tegra20 I2C binding to enable the use of the 'reg-settings'
> binding for this device.
> 
> Signed-off-by: Rajesh Gumasta <rgumasta@nvidia.com>
> ---
>  .../bindings/i2c/i2c-controller-common.yaml   | 73 +++++++++++++++++++
>  .../bindings/i2c/nvidia,tegra20-i2c.yaml      | 64 +++++++++++++++-
>  2 files changed, 134 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-controller-common.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.example.dts:24.22-73.11: Warning (i2c_bus_bridge): /example-0/i2c@7000c000: incorrect #address-cells for I2C bus
Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.example.dts:24.22-73.11: Warning (i2c_bus_bridge): /example-0/i2c@7000c000: incorrect #size-cells for I2C bus
Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'i2c_bus_bridge'

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250725052225.23510-3-rgumasta@nvidia.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH V3 0/3] Introduce a generic register settings dt-binding

[Jon Hunter]

On 25/07/2025 07:48, Krzysztof Kozlowski wrote:
> On 25/07/2025 07:22, Rajesh Gumasta wrote:
>> 4. The I2C bindings are known to fail the binding checks if the fix for
>>     the I2C schema is not applied [1].
>> 5. The file i2c-controller-common.yaml is added as a place-holder for
>>     defining the 'reg-settings' nodes for I2C controllers. However, this
>>     is very much a place-holder for demostration purposes. Ideally, these
>>     nodes would be part of the main I2C schema.
>>
>> Changes in V3:
>> - Renamed as 'generic register settings' as opposed to 'Tegra register
>>    config settings'.
>> - Dropped all the associated code to focus on the DT bindings for now.
>> - Added a 'register-settings.yaml' as a top level binding.
>> - Made I2C register-setting timing properties generic I2C properties.
> 
> 
> Where are lore links to previous discussions? There is no v2 nor v1 in
> inbox.

I see the lore link for the V2 at the bottom on the cover-letter. Pasting it again here ...

https://lore.kernel.org/linux-tegra/20240701151231.29425-1-kyarlagadda@nvidia.com/

And V1 is here:

https://lore.kernel.org/linux-tegra/20240506225139.57647-1-kyarlagadda@nvidia.com/

Jon

-- 
nvpublic

Re: [PATCH V3 2/3] dt-binding: i2c: nvidia,tegra20-i2c: Add register-setting support

[Jon Hunter]

On 25/07/2025 08:40, Rob Herring (Arm) wrote:
> 
> On Fri, 25 Jul 2025 10:52:24 +0530, Rajesh Gumasta wrote:
>> Add register setting support for the NVIDIA Tegra20 I2C controllers. An
>> i2c-controller-common.yaml binding document has been added a top-level
>> binding document so that all I2C controllers can use this binding. This
>> new binding document defines some generic register setting properties
>> for I2C and some standard I2C operating modes that the register settings
>> need to be programmed for. This new binding document is used by the
>> NVIDIA Tegra20 I2C binding to enable the use of the 'reg-settings'
>> binding for this device.
>>
>> Signed-off-by: Rajesh Gumasta <rgumasta@nvidia.com>
>> ---
>>   .../bindings/i2c/i2c-controller-common.yaml   | 73 +++++++++++++++++++
>>   .../bindings/i2c/nvidia,tegra20-i2c.yaml      | 64 +++++++++++++++-
>>   2 files changed, 134 insertions(+), 3 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/i2c/i2c-controller-common.yaml
>>
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.example.dts:24.22-73.11: Warning (i2c_bus_bridge): /example-0/i2c@7000c000: incorrect #address-cells for I2C bus
> Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.example.dts:24.22-73.11: Warning (i2c_bus_bridge): /example-0/i2c@7000c000: incorrect #size-cells for I2C bus
> Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'i2c_bus_bridge'


Per the cover letter this is expected and a fix for the DTC has
been sent here:

https://lore.kernel.org/linux-tegra/20250709142452.249492-1-jonathanh@nvidia.com/

Jon

-- 
nvpublic

Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Jon Hunter]

On 25/07/2025 07:47, Krzysztof Kozlowski wrote:
> On 25/07/2025 07:22, Rajesh Gumasta wrote:
>> +description: |
>> +  Register Settings provides a generic way to specify register configurations
>> +  for any hardware controllers. Settings are specified under a "reg-settings"
>> +  sub-node under the controller device tree node. It allows defining both
>> +  default and operating mode specific register settings in the device tree.
>> +
>> +properties:
>> +  reg-settings:
>> +    type: object
>> +    description: |
>> +      Container node for register settings configurations. Each child node
>> +      represents a specific configuration mode or operating condition.
>> +
>> +    additionalProperties:
>> +      type: object
> 
> I don't understand what does this binding bring. It is empty.


Yes this is very much similar to the pinctrl.yaml that defines a 
top-level object that can then be used by different devices and those 
devices can then define the properties they need. So the examples for 
I2C and MMC really demonstrate how this would be used in the subsequent 
patches. Obviously we are open to any ideas on how if there are better 
or preferred ways to do this.

Jon

-- 
nvpublic

Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Krzysztof Kozlowski]

On 29/07/2025 11:15, Jon Hunter wrote:
> 
> On 25/07/2025 07:47, Krzysztof Kozlowski wrote:
>> On 25/07/2025 07:22, Rajesh Gumasta wrote:
>>> +description: |
>>> +  Register Settings provides a generic way to specify register configurations
>>> +  for any hardware controllers. Settings are specified under a "reg-settings"
>>> +  sub-node under the controller device tree node. It allows defining both
>>> +  default and operating mode specific register settings in the device tree.
>>> +
>>> +properties:
>>> +  reg-settings:
>>> +    type: object
>>> +    description: |
>>> +      Container node for register settings configurations. Each child node
>>> +      represents a specific configuration mode or operating condition.
>>> +
>>> +    additionalProperties:
>>> +      type: object
>>
>> I don't understand what does this binding bring. It is empty.
> 
> 
> Yes this is very much similar to the pinctrl.yaml that defines a 
> top-level object that can then be used by different devices and those 

No, it is not similar. pinctrl.yaml defines common properties and common
schema for class of devices - pin controllers.

There is nothing common here, nothing defined except that you have
unspecified children nodes.

> devices can then define the properties they need. So the examples for 
> I2C and MMC really demonstrate how this would be used in the subsequent 
> patches. Obviously we are open to any ideas on how if there are better 
> or preferred ways to do this.

I don't see this part addressing comments from Rob - you need more users
of this. Adding fake (empty, no-op) common schema is not solving it.

Best regards,
Krzysztof

Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]

On Tue, Jul 29, 2025 at 11:28:43AM +0200, Krzysztof Kozlowski wrote:
> On 29/07/2025 11:15, Jon Hunter wrote:
> > 
> > On 25/07/2025 07:47, Krzysztof Kozlowski wrote:
> >> On 25/07/2025 07:22, Rajesh Gumasta wrote:
> >>> +description: |
> >>> +  Register Settings provides a generic way to specify register configurations
> >>> +  for any hardware controllers. Settings are specified under a "reg-settings"
> >>> +  sub-node under the controller device tree node. It allows defining both
> >>> +  default and operating mode specific register settings in the device tree.
> >>> +
> >>> +properties:
> >>> +  reg-settings:
> >>> +    type: object
> >>> +    description: |
> >>> +      Container node for register settings configurations. Each child node
> >>> +      represents a specific configuration mode or operating condition.
> >>> +
> >>> +    additionalProperties:
> >>> +      type: object
> >>
> >> I don't understand what does this binding bring. It is empty.
> > 
> > 
> > Yes this is very much similar to the pinctrl.yaml that defines a 
> > top-level object that can then be used by different devices and those 
> 
> No, it is not similar. pinctrl.yaml defines common properties and common
> schema for class of devices - pin controllers.
> 
> There is nothing common here, nothing defined except that you have
> unspecified children nodes.

This is supposed to be very generic and it needs to be by its nature.

> > devices can then define the properties they need. So the examples for 
> > I2C and MMC really demonstrate how this would be used in the subsequent 
> > patches. Obviously we are open to any ideas on how if there are better 
> > or preferred ways to do this.
> 
> I don't see this part addressing comments from Rob - you need more users
> of this. Adding fake (empty, no-op) common schema is not solving it.

Bjorn, Simon and Nishanth are Cc'ed on this series since they expressed
interest in this kind of functionality, so I expect that we'll see other
users of this eventually.

However, we do have to get the ball rolling and propose something that
we think can work for a number of cases, so that's what this is.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Jon Hunter]

Hi Krzysztof,

On 29/07/2025 15:05, Thierry Reding wrote:
> On Tue, Jul 29, 2025 at 11:28:43AM +0200, Krzysztof Kozlowski wrote:
>> On 29/07/2025 11:15, Jon Hunter wrote:
>>>
>>> On 25/07/2025 07:47, Krzysztof Kozlowski wrote:
>>>> On 25/07/2025 07:22, Rajesh Gumasta wrote:
>>>>> +description: |
>>>>> +  Register Settings provides a generic way to specify register configurations
>>>>> +  for any hardware controllers. Settings are specified under a "reg-settings"
>>>>> +  sub-node under the controller device tree node. It allows defining both
>>>>> +  default and operating mode specific register settings in the device tree.
>>>>> +
>>>>> +properties:
>>>>> +  reg-settings:
>>>>> +    type: object
>>>>> +    description: |
>>>>> +      Container node for register settings configurations. Each child node
>>>>> +      represents a specific configuration mode or operating condition.
>>>>> +
>>>>> +    additionalProperties:
>>>>> +      type: object
>>>>
>>>> I don't understand what does this binding bring. It is empty.
>>>
>>>
>>> Yes this is very much similar to the pinctrl.yaml that defines a
>>> top-level object that can then be used by different devices and those
>>
>> No, it is not similar. pinctrl.yaml defines common properties and common
>> schema for class of devices - pin controllers.
>>
>> There is nothing common here, nothing defined except that you have
>> unspecified children nodes.
> 
> This is supposed to be very generic and it needs to be by its nature.

To add, we want the ability to use the 'reg-settings' child node for any 
device, but because the settings for a given class of device will vary, 
for now we opted to create this empty top-level node. The alternative is 
to define this 'reg-settings' node for every device using it, which is 
fine, if that is preferred. Please let me know what your preference is here?

>>> devices can then define the properties they need. So the examples for
>>> I2C and MMC really demonstrate how this would be used in the subsequent
>>> patches. Obviously we are open to any ideas on how if there are better
>>> or preferred ways to do this.
>>
>> I don't see this part addressing comments from Rob - you need more users
>> of this. Adding fake (empty, no-op) common schema is not solving it.
> 
> Bjorn, Simon and Nishanth are Cc'ed on this series since they expressed
> interest in this kind of functionality, so I expect that we'll see other
> users of this eventually.
> 
> However, we do have to get the ball rolling and propose something that
> we think can work for a number of cases, so that's what this is.

We certainly have more drivers that will use this. However, we want to 
flesh out the device-tree schema for this with just a couple examples to 
keep the review simple and focused.

In the short-term I would like to understand if you agree that we can 
use device-tree to store such hardware register settings? If so, then we 
are happy to re-work the proposal in anyway that you would prefer so 
that we can agree on how such hardware register setting values can be 
stored in device-tree.

Thanks!
Jon

-- 
nvpublic

Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Chintan Vankar]

Hello Rajesh,

On 25/07/25 10:52, Rajesh Gumasta wrote:
> Add a new device-tree binding for a 'reg-settings' node that can be
> added to any device. This 'reg-settings' is used to populate register
> settings that need to be programmed for a given operating mode of the
> device. An example usage of the 'reg-settings' node is shown below for
> the NVIDIA Tegra MMC controller which needs to program a specific
> 'num-tuning-iterations' value in a register field for each operating
> mode:
> 
>    mmc@700b0000 {
> 
>      reg-settings {
> 
>        default-settings {
>          /* Default register setting */
>          nvidia,num-tuning-iterations = <0>;
>        };
> 
>        sdr50 {
>          /* SDR50 register setting */
>          nvidia,num-tuning-iterations = <4>;
>        };
> 
>        sdr104 {
>          /* SDR104 register setting */
>          nvidia,num-tuning-iterations = <2>;
>        };
> 
>        hs200 {
>          /* HS200 register setting */
>          nvidia,num-tuning-iterations = <2>;
>        };
>      };
>    };
> 
> The 'reg-settings' child nodes are defined according to the operating
> modes supported for a given device. Properties within each operating
> mode are then defined by the bindings for the devices that require them.
> 
> Signed-off-by: Rajesh Gumasta <rgumasta@nvidia.com>
> ---
>   .../bindings/regset/register-settings.yaml    | 31 +++++++++++++++++++
>   1 file changed, 31 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/regset/register-settings.yaml
> 
> diff --git a/Documentation/devicetree/bindings/regset/register-settings.yaml b/Documentation/devicetree/bindings/regset/register-settings.yaml
> new file mode 100644
> index 000000000000..4366cdd72813
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regset/register-settings.yaml
> @@ -0,0 +1,31 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regset/register-settings.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Register Settings
> +
> +maintainers:
> +  - Thierry Reding <thierry.reding@gmail.com>
> +  - Krishna Yarlagadda <kyarlagadda@nvidia.com>
> +  - Rajesh Gumasta <rgumasta@nvidia.com>
> +  - Jon Hunter <jonathanh@nvidia.com>
> +
> +description: |
> +  Register Settings provides a generic way to specify register configurations
> +  for any hardware controllers. Settings are specified under a "reg-settings"
> +  sub-node under the controller device tree node. It allows defining both
> +  default and operating mode specific register settings in the device tree.
> +
> +properties:
> +  reg-settings:
> +    type: object
> +    description: |
> +      Container node for register settings configurations. Each child node
> +      represents a specific configuration mode or operating condition.
> +
> +    additionalProperties:
> +      type: object
> +
> +additionalProperties: true

Following your series, I would like to bring to your attention that
Texas Instruments SoCs also have a component which requires similar kind
of configuration, named Timesync Router(TSR). It enables the
multiplexing of M inputs to N outputs, where inputs can be selectively
driven based on N output configuration. A detailed explanation of the
TSR and our attempts we tried to implement TSR can be found in following
RFC series:
https://lore.kernel.org/all/20250605063422.3813260-1-c-vankar@ti.com/
https://lore.kernel.org/all/20250205160119.136639-1-c-vankar@ti.com/

To implement TSR, the relevant registers must be configured via the
device tree. We initially assumed that the device could be handled as a
mux-controller and could be extended in the same subsystem, but it was
ineffective. Having explored both the approaches, we now plan to
implement TSR within misc subsystem, which aligns with the dt-bindings
that you have proposed in this series.

The purpose to replying over this series is to inform you that we also
have a component requiring configuration as outlined in this series. Let
us know if you have any suggestions for this.

Regards,
Chintan.

Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Jon Hunter]

Hi Chintan,

On 29/09/2025 05:39, Chintan Vankar wrote:

...

> Following your series, I would like to bring to your attention that
> Texas Instruments SoCs also have a component which requires similar kind
> of configuration, named Timesync Router(TSR). It enables the
> multiplexing of M inputs to N outputs, where inputs can be selectively
> driven based on N output configuration. A detailed explanation of the
> TSR and our attempts we tried to implement TSR can be found in following
> RFC series:
> https://lore.kernel.org/all/20250605063422.3813260-1-c-vankar@ti.com/
> https://lore.kernel.org/all/20250205160119.136639-1-c-vankar@ti.com/
> 
> To implement TSR, the relevant registers must be configured via the
> device tree. We initially assumed that the device could be handled as a
> mux-controller and could be extended in the same subsystem, but it was
> ineffective. Having explored both the approaches, we now plan to
> implement TSR within misc subsystem, which aligns with the dt-bindings
> that you have proposed in this series.
> 
> The purpose to replying over this series is to inform you that we also
> have a component requiring configuration as outlined in this series. Let
> us know if you have any suggestions for this.

That's great! Thanks for the feedback.

Rob, Krzysztof, Conor, have you guys had chance to look at this series 
some more? We are open to re-working it as necessary to address any 
concerns/comments you have. However, this appears to be stalled at the 
moment and I am not sure what we should do next to push this forward.

Thanks!
Jon

-- 
nvpublic

Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Jon Hunter]

Hi Rob, Krzysztof, Conor,

On 30/09/2025 16:01, Jon Hunter wrote:

...

>> Following your series, I would like to bring to your attention that
>> Texas Instruments SoCs also have a component which requires similar kind
>> of configuration, named Timesync Router(TSR). It enables the
>> multiplexing of M inputs to N outputs, where inputs can be selectively
>> driven based on N output configuration. A detailed explanation of the
>> TSR and our attempts we tried to implement TSR can be found in following
>> RFC series:
>> https://lore.kernel.org/all/20250605063422.3813260-1-c-vankar@ti.com/
>> https://lore.kernel.org/all/20250205160119.136639-1-c-vankar@ti.com/
>>
>> To implement TSR, the relevant registers must be configured via the
>> device tree. We initially assumed that the device could be handled as a
>> mux-controller and could be extended in the same subsystem, but it was
>> ineffective. Having explored both the approaches, we now plan to
>> implement TSR within misc subsystem, which aligns with the dt-bindings
>> that you have proposed in this series.
>>
>> The purpose to replying over this series is to inform you that we also
>> have a component requiring configuration as outlined in this series. Let
>> us know if you have any suggestions for this.
> 
> That's great! Thanks for the feedback.
> 
> Rob, Krzysztof, Conor, have you guys had chance to look at this series 
> some more? We are open to re-working it as necessary to address any 
> concerns/comments you have. However, this appears to be stalled at the 
> moment and I am not sure what we should do next to push this forward.


Please can you respond to this? It is unclear if/how we can move forward 
on this.

Jon

-- 
nvpublic

Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Rob Herring]

On Tue, Sep 30, 2025 at 04:01:27PM +0100, Jon Hunter wrote:
> Hi Chintan,
> 
> On 29/09/2025 05:39, Chintan Vankar wrote:
> 
> ...
> 
> > Following your series, I would like to bring to your attention that
> > Texas Instruments SoCs also have a component which requires similar kind
> > of configuration, named Timesync Router(TSR). It enables the
> > multiplexing of M inputs to N outputs, where inputs can be selectively
> > driven based on N output configuration. A detailed explanation of the
> > TSR and our attempts we tried to implement TSR can be found in following
> > RFC series:
> > https://lore.kernel.org/all/20250605063422.3813260-1-c-vankar@ti.com/
> > https://lore.kernel.org/all/20250205160119.136639-1-c-vankar@ti.com/

I fail to see how that is related to this series. I'm not going to 
study these 2 implementations and imagine how it could be implemented 
using this series. If the amount of overlap is just 'reg-settings' node, 
then that's not really enough. More below.

> > To implement TSR, the relevant registers must be configured via the
> > device tree. We initially assumed that the device could be handled as a
> > mux-controller and could be extended in the same subsystem, but it was
> > ineffective. Having explored both the approaches, we now plan to
> > implement TSR within misc subsystem, which aligns with the dt-bindings
> > that you have proposed in this series.
> > 
> > The purpose to replying over this series is to inform you that we also
> > have a component requiring configuration as outlined in this series. Let
> > us know if you have any suggestions for this.
> 
> That's great! Thanks for the feedback.
> 
> Rob, Krzysztof, Conor, have you guys had chance to look at this series some
> more? We are open to re-working it as necessary to address any
> concerns/comments you have. However, this appears to be stalled at the
> moment and I am not sure what we should do next to push this forward.

I fail to see what is generic here? There's a generic node name, but 
that has nothing else common. The 2 examples share nothing because it 
is all bus specific. But then the bus specific stuff is NVIDIA specific. 
It's the bus specific part that should be generic (to the bus type) IMO. 

A concrete second user would go a long way to help. Anything "common" 
from one vendor ends up needing something different from the 2nd user. 
Somehow that 2nd user always shows up a month later... So the rule is 
generally I want to see 2 users. Yeah, it's hard to get others to pay 
attention, but that's not really my problem.

Rob

Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Jon Hunter]

Hi Rob,

On 09/10/2025 17:33, Rob Herring wrote:
> On Tue, Sep 30, 2025 at 04:01:27PM +0100, Jon Hunter wrote:
>> Hi Chintan,
>>
>> On 29/09/2025 05:39, Chintan Vankar wrote:
>>
>> ...
>>
>>> Following your series, I would like to bring to your attention that
>>> Texas Instruments SoCs also have a component which requires similar kind
>>> of configuration, named Timesync Router(TSR). It enables the
>>> multiplexing of M inputs to N outputs, where inputs can be selectively
>>> driven based on N output configuration. A detailed explanation of the
>>> TSR and our attempts we tried to implement TSR can be found in following
>>> RFC series:
>>> https://lore.kernel.org/all/20250605063422.3813260-1-c-vankar@ti.com/
>>> https://lore.kernel.org/all/20250205160119.136639-1-c-vankar@ti.com/
> 
> I fail to see how that is related to this series. I'm not going to
> study these 2 implementations and imagine how it could be implemented
> using this series. If the amount of overlap is just 'reg-settings' node,
> then that's not really enough. More below.
> 
>>> To implement TSR, the relevant registers must be configured via the
>>> device tree. We initially assumed that the device could be handled as a
>>> mux-controller and could be extended in the same subsystem, but it was
>>> ineffective. Having explored both the approaches, we now plan to
>>> implement TSR within misc subsystem, which aligns with the dt-bindings
>>> that you have proposed in this series.
>>>
>>> The purpose to replying over this series is to inform you that we also
>>> have a component requiring configuration as outlined in this series. Let
>>> us know if you have any suggestions for this.
>>
>> That's great! Thanks for the feedback.
>>
>> Rob, Krzysztof, Conor, have you guys had chance to look at this series some
>> more? We are open to re-working it as necessary to address any
>> concerns/comments you have. However, this appears to be stalled at the
>> moment and I am not sure what we should do next to push this forward.
> 
> I fail to see what is generic here? There's a generic node name, but
> that has nothing else common. The 2 examples share nothing because it
> is all bus specific. But then the bus specific stuff is NVIDIA specific.
> It's the bus specific part that should be generic (to the bus type) IMO.

We are looking for a generic way to program values into hardware 
register fields for various different devices such as I2C, SPI, USB, 
PCIe, etc. Device-tree is a good candidate for this, because the values 
can be device or board specific. I know this was a year ago now, but at 
last years plumbers we did discuss with Krzysztof and other vendors at 
the device-tree session also indicated that they had a need to store 
register level data in device-tree to accomplish something similar.

So the idea behind this series is to define a generic binding for 
storing register values in device-tree that could be used for 
potentially any device. The aim of this RFC is to see if there is any 
interest for pursuing this still and if so, what would be a good way to 
describe this data in device-tree. The proposed binding is one idea that 
we had come up but we are not tied to it.

> A concrete second user would go a long way to help. Anything "common"
> from one vendor ends up needing something different from the 2nd user.
> Somehow that 2nd user always shows up a month later... So the rule is
> generally I want to see 2 users. Yeah, it's hard to get others to pay
> attention, but that's not really my problem.

Yes completely makes sense and no problem there. If this does not get 
any traction and is not acceptable, then we could just make all the 
properties we need vendor specific and have various 'nvidia' properties 
for each controller. It is not ideal either, but that could work.

Jon

-- 
nvpublic