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

[Rajesh Gumasta <rgumasta@nvidia.com>]

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