From: Joshua Yeong <joshua.yeong@starfivetech.com>
To: Krzysztof Kozlowski <krzk@kernel.org>, Mark Brown <broonie@kernel.org>
Cc: "lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"rahul@summations.net" <rahul@summations.net>,
"anup@brainfault.org" <anup@brainfault.org>,
"lftan.linux@gmail.com" <lftan.linux@gmail.com>,
"robh@kernel.org" <robh@kernel.org>,
"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"pjw@kernel.org" <pjw@kernel.org>,
"palmer@dabbelt.com" <palmer@dabbelt.com>,
"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
"alex@ghiti.fr" <alex@ghiti.fr>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2 1/3] dt-bindings: regulator: Add RPMI voltage service bindings
Date: Fri, 25 Sep 2026 07:14:14 +0000 [thread overview]
Message-ID: <SH0PR01MB0841C933DE1E00C4012BDF53F9802@SH0PR01MB0841.CHNPR01.prod.partner.outlook.cn> (raw)
In-Reply-To: <0db3ed29-8bb8-4dc3-a4cb-cc5b9bf2e893@kernel.org>
On Fri, Sep 25, 2026 at 08:07:40AM +0200, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 25/09/2026 04:21, Joshua Yeong wrote:
> > On Thu, Sep 24, 2026 at 10:00:06PM +0100, Mark Brown <broonie@kernel.org> wrote:
> >> On Wed, Sep 23, 2026 at 10:35:08PM +0200, Krzysztof Kozlowski wrote:
> >>> On 23/09/2026 09:00, Joshua Yeong wrote:
> >>
> >>>> + voltage-service {
> >>
> >>> There is no such service. Don't invent names. See DT spec.
> >>
> >> Looks like it comes from the RPMI spec:
> >>
> >>
> >> https://github.com/riscv-non-isa/riscv-rpmi/blob/main/src/srvgrp-volta
> >> ge.adoc
> >>
> >>>> + "#voltage-domain-cells" on the provider, a consumer lists
> >>>> + "voltage-domains = <&provider DOMAIN_ID>" and names each entry
> >>>> + in "voltage-domain-names", the way it names a voltage power
> >>>> + domain. Both properties belong to the consumer, so a consumer
> >>>> + binding describes them
> >>>> + itself:
> >>
> >>> And where do you explain what is that "voltage domain" and why it is
> >>> completely different than everything else we have?
> >>
> >>> No, don't come up with your own naming for standard things.
> >>
> >> That also looks like what the spec says (some of the description is
> >> copied pretty closely from the spec).
> >
> > The RPMI specification uses the word voltage instead of 'regulator' in the
> > kernel here. We need something like power-domain-cells,
> > performance-domain-cells or clock-cells that isn't supported by regulator
> > framework. While I have no prior history on the regulator framework but
> > the RPMI voltage service drivers trying to upstream here need some
> > mechanism to map just the domain id to the RPMI services.
> >
> > The driver would still work with the existing voltage device tree structure.
> > I understand other drivers may not use voltage-domain like RPMI
> > voltage service, so I only add the support for this on the RPMI
> > voltage driver and not on the framework side.
>
>
> As discussed on IRC #devicetree, that's either power-domains or
> regulator supplies. If you need anything else, you need to explain. Not we.
This is the how the existing regulator would look like this.
user-app-a {
compatible = "...";
vdd-supply = <&volt1>;
};
rpmi-voltage {
mboxes = <0x0c 0x1004 0x00>;
compatible = "riscv,rpmi-voltage";
regulators {
#size-cells = <0x00>;
#address-cells = <0x01>;
volt1: regulator@1 {
reg = <0x01>;
...
};
...
};
};
While the above method works but I'm trying to get the entire simplify to the following.
user-app-b {
compatible = "...";
voltage-domains = <&rpmi-voltage 0x01>;
};
rpmi-voltage: rpmi-voltage {
mboxes = <0x0c 0x1004 0x00>;
#voltage-domain-cells = <0x01>;
compatible = "riscv,rpmi-voltage";
};
The user does not need to map any other information under /rpmi-voltage/regulators/volt1 , since the value are being decided by the platform microcontroller.
The fields like 'names', ' regulator-max-microvolt' and ' regulator-min-microvolt' are being discovered during runtime instead.
>
> Best regards,
> Krzysztof
next prev parent reply other threads:[~2026-09-25 8:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 7:00 [PATCH v2 0/3] Add RISC-V RPMI voltage service support Joshua Yeong
2026-09-23 7:00 ` [PATCH v2 1/3] dt-bindings: regulator: Add RPMI voltage service bindings Joshua Yeong
2026-09-23 20:35 ` Krzysztof Kozlowski
2026-09-24 21:00 ` Mark Brown
2026-09-25 2:21 ` Joshua Yeong
2026-09-25 6:07 ` Krzysztof Kozlowski
2026-09-25 7:14 ` Joshua Yeong [this message]
2026-09-25 15:18 ` Krzysztof Kozlowski
2026-09-25 17:15 ` Mark Brown
2026-09-26 21:21 ` Conor Dooley
2026-09-27 6:37 ` Joshua Yeong
2026-09-25 17:20 ` Mark Brown
2026-09-25 6:11 ` Krzysztof Kozlowski
2026-09-25 17:25 ` Mark Brown
2026-09-23 7:00 ` [PATCH v2 2/3] regulator: Add RPMI voltage service Joshua Yeong
2026-09-23 7:00 ` [PATCH v2 3/3] MAINTAINERS: Add RISC-V RPMI voltage driver Joshua Yeong
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=SH0PR01MB0841C933DE1E00C4012BDF53F9802@SH0PR01MB0841.CHNPR01.prod.partner.outlook.cn \
--to=joshua.yeong@starfivetech.com \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=lftan.linux@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rahul@summations.net \
--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®