From: Conor Dooley <conor@kernel.org>
To: vamshi gajjela <vamshigajjela@google.com>
Cc: "Stephen Boyd" <sboyd@kernel.org>,
"Abel Vesa" <abelvesa@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Peter Griffin" <peter.griffin@linaro.org>,
"André Draszik" <andre.draszik@linaro.org>,
"Tudor Ambarus" <tudor.ambarus@linaro.org>,
"Jim Wylder" <jwylder@google.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: spmi: Add SmartDV SPMI controller
Date: Tue, 3 Nov 2026 18:16:57 +0000 [thread overview]
Message-ID: <20261103-handiwork-replace-25efd6b3d8be@spud> (raw)
In-Reply-To: <20261103042608.387626-3-vamshigajjela@google.com>
[-- Attachment #1: Type: text/plain, Size: 6751 bytes --]
On Tue, Nov 03, 2026 at 09:56:06AM +0530, vamshi gajjela wrote:
> From: Vamshi Gajjela <vamshigajjela@google.com>
>
> Document the device tree bindings for the SmartDV IP Solutions MIPI SPMI
> master controller ("smartdv,spmi").
>
> This controller IP is integrated in Google Tensor SoCs starting with the
> G5 generation (codename: laguna, canonically written as "lga"), so add
> "google,lga-spmi" with a fallback to "smartdv,spmi".
>
> Signed-off-by: Vamshi Gajjela <vamshigajjela@google.com>
> ---
> .../bindings/spmi/smartdv,spmi.yaml | 126 ++++++++++++++++++
> MAINTAINERS | 6 +
> 2 files changed, 132 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spmi/smartdv,spmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/spmi/smartdv,spmi.yaml b/Documentation/devicetree/bindings/spmi/smartdv,spmi.yaml
> new file mode 100644
> index 000000000000..e0512e60d932
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spmi/smartdv,spmi.yaml
> @@ -0,0 +1,126 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spmi/smartdv,spmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SmartDV IP Solutions SPMI Controller
> +
> +maintainers:
> + - Vamshi Gajjela <vamshigajjela@google.com>
> +
> +description:
> + SmartDV IP Solutions MIPI System Power Management Interface (SPMI) master
> + controller supporting MIPI SPMI Specification versions 1.0 and 2.0.
> +
> +allOf:
> + - $ref: spmi.yaml#
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - const: google,lga-spmi
> + - const: smartdv,spmi
> + - const: smartdv,spmi
I hate compatibles for purchasable IP like this, particularly when
unversioned as they maybe become effectively useless when a new revision
releases. The standalone smartdv,spmi compatible has to go at least,
soc-specific compatibles are mandatory.
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + description:
> + Core clock to the controller from which SPMI SCL is derived. Optional if
> + the controller uses a free-running clock and clock-frequency is specified.
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + clock-frequency:
> + description:
> + Input core clock frequency in Hz when the controller uses a free-running
> + clock not described in clocks.
> +
> + smartdv,master-arb-enable:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1]
> + default: 0
> + description:
> + Enable master bus arbitration phase (0 = disable, 1 = enable).
What aspect of board design governs the decision here?
Why can it not be determined from the soc specific compatible?
> +
> + smartdv,master-id:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 3
> + default: 0
> + description:
> + Master ID for the controller on the SPMI bus.
What aspect of board design governs the decision here?
Why can it not be determined from the soc specific compatible?
> +
> + smartdv,spmi-version:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1]
> + default: 0
> + description:
> + MIPI SPMI specification version used for transfers (0 for MIPI SPMI v1.0,
> + 1 for MIPI SPMI v2.0).
What aspect of board design governs the decision here?
Why can it not be determined from the soc specific compatible?
> +
> + smartdv,arb-retry-limit:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 255
> + default: 32
> + description:
> + Maximum number of times the master retries a command when losing bus
> + arbitration.
What aspect of board design governs the decision here?
Why can it not be determined from the soc specific compatible?
> +
> + smartdv,prescaler:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 255
> + default: 0
> + description:
> + Clock divider value to generate SPMI SCL from the input core clock. Writing
> + 1 divides the system clock by 2; more generally, a non-zero value n
> + divides the system clock by 2 * n.
What aspect of board design governs the decision here?
Why can it not be determined from the soc specific compatible?
> +
> + smartdv,read-latency:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 255
> + default: 32
> + description:
> + Number of SPMI SCL clock cycles to pause during bus turnaround on read
> + commands to allow the target device to fetch data.
What aspect of board design governs the decision here?
Why can it not be determined from the soc specific compatible?
> +
> + smartdv,arb-scl-delay:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 3
> + default: 0
> + description:
> + Delay between arbitration and Sequence Start Condition (SSC) when the
> + controller is the Bus Owner Master (BOM).
What aspect of board design governs the decision here?
Why can it not be determined from the soc specific compatible?
> +
> +required:
> + - compatible
> + - reg
I find it hard to believe that this is the set of required properties.
pw-bot: changes-requested
Thanks,
Conor.
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/spmi/spmi.h>
> +
> + spmi@14853000 {
> + compatible = "google,lga-spmi", "smartdv,spmi";
> + reg = <0x14853000 0x100>;
> + #address-cells = <2>;
> + #size-cells = <0>;
> + clock-frequency = <19200000>;
> + smartdv,master-arb-enable = <1>;
> + smartdv,spmi-version = <1>;
> +
> + pmic@f {
> + reg = <0xf SPMI_USID>;
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index eaeb60c1e1c2..f44c597c2075 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -25243,6 +25243,12 @@ T: git https://github.com/cschaufler/smack-next.git
> F: Documentation/admin-guide/LSM/Smack.rst
> F: security/smack/
>
> +SMARTDV SPMI CONTROLLER DRIVER
> +M: Vamshi Gajjela <vamshigajjela@google.com>
> +L: linux-kernel@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/spmi/smartdv,spmi.yaml
> +
> SMBDIRECT (RDMA Stream Transport with Read/Write-Offload, MS-SMBD)
> M: Steve French <smfrench@gmail.com>
> M: Steve French <sfrench@samba.org>
> --
> 2.56.0.317.g454f8302e1-goog
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-11-03 18:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 4:26 [PATCH 0/3] spmi: Add SmartDV SPMI controller driver and bindings vamshi gajjela
2026-11-03 4:26 ` [PATCH 1/3] dt-bindings: vendor-prefixes: Add smartdv vamshi gajjela
2026-11-04 14:08 ` Krzysztof Kozlowski
2026-11-03 4:26 ` [PATCH 2/3] dt-bindings: spmi: Add SmartDV SPMI controller vamshi gajjela
2026-11-03 18:16 ` Conor Dooley [this message]
2026-11-04 14:14 ` Krzysztof Kozlowski
2026-11-03 4:26 ` [PATCH 3/3] spmi: Add SmartDV SPMI controller driver vamshi gajjela
2026-11-06 16:58 ` Uwe Kleine-König
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=20261103-handiwork-replace-25efd6b3d8be@spud \
--to=conor@kernel.org \
--cc=abelvesa@kernel.org \
--cc=andre.draszik@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jwylder@google.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=peter.griffin@linaro.org \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=tudor.ambarus@linaro.org \
--cc=vamshigajjela@google.com \
/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.