Re: [PATCH v1 1/6] dt-bindings: soc: mediatek: Add DVFSRC bindings for MT8183 and MT8195

From: Conor Dooley
Date: Wed Apr 17 2024 - 11:26:07 EST


On Wed, Apr 17, 2024 at 10:26:06AM +0200, AngeloGioacchino Del Regno wrote:
> Il 16/04/24 19:30, Conor Dooley ha scritto:
> > On Tue, Apr 16, 2024 at 06:28:58PM +0100, Conor Dooley wrote:
> > > On Tue, Apr 16, 2024 at 05:38:00PM +0200, AngeloGioacchino Del Regno wrote:
> > > > Add bindings for the MediaTek Dynamic Voltage and Frequency Scaling
> > > > Resource Collector (DVFSRC), a hardware module used to collect all the
> > > > requests from both software and the various remote processors embedded
> > > > into the SoC and decide about a minimum operating voltage and a minimum
> > > > DRAM frequency to fulfill those requests in an effort to provide the
> > > > best achievable performance per watt.
> > > >
> > > > This hardware IP is capable of transparently performing direct register
> > > > R/W on all of the DVFSRC-controlled regulators and SoC bandwidth knobs.
> > > >
> > > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx>
> > > > ---
> > > > .../soc/mediatek/mediatek,mt8183-dvfsrc.yaml | 57 +++++++++++++++++++
> > > > 1 file changed, 57 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml
> > > > new file mode 100644
> > > > index 000000000000..12bcc3fdfd07
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml
> > > > @@ -0,0 +1,57 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/soc/mediatek/mediatek,mt8183-dvfsrc.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: MediaTek Dynamic Voltage and Frequency Scaling Resource Collector (DVFSRC)
> > > > +
> > > > +description:
> > > > + The Dynamic Voltage and Frequency Scaling Resource Collector (DVFSRC) is a
> > > > + Hardware module used to collect all the requests from both software and the
> > > > + various remote processors embedded into the SoC and decide about a minimum
> > > > + operating voltage and a minimum DRAM frequency to fulfill those requests in
> > > > + an effort to provide the best achievable performance per watt.
> > > > + This hardware IP is capable of transparently performing direct register R/W
> > > > + on all of the DVFSRC-controlled regulators and SoC bandwidth knobs.
> > > > +
> > > > +maintainers:
> > > > + - AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx>
> > > > + - Henry Chen <henryc.chen@xxxxxxxxxxxx>
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + oneOf:
> > > > + - items:
> > >
> > > This items should not be needed with the enum, right?
> > >
>
> Whoops. Yep items is not needed.
>
> > > > + - enum:
> > > > + - mediatek,mt8183-dvfsrc
> > > > + - mediatek,mt8195-dvfsrc
> > > > + - items:
> > > > + - const: mediatek,mt8192-dvfsrc
> > > > + - const: mediatek,mt8195-dvfsrc
> > > > +
> > > > + reg:
> > > > + maxItems: 1
> > > > + description: DVFSRC common register address and length.
> > > > +
> > > > +patternProperties:
> > > > + "@[0-9a-f]+$":
> > > > + type: object
> > >
> > > Why is there no enforcement of what a child could be here?
> >
> > Seems like you know exactly what the children are: regulators and an
> > interconnect? What am I missing?
> >
>
> I wasn't sure whether that would've been a good idea, given that there will
> be more possible children in the future - as in - more drivers that need the
> DVFSRC communication.

If there's no additional hardware, just additional drivers wanting to
use this, there's no need to modify the dt, you just call
platform_device_register() to spin up the new drivers.

> But anyway yes, for now, it's just the regulator and interconnect drivers.

We can always free it up whenever new requirements appear.

> > > > +required:
> > > > + - compatible
> > > > + - reg
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > + soc {
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > +
> > > > + dvfsrc@10012000 {
> > >
> > > "dvfsrc" looks like something my (imaginary given allergies) cat would
>
> (allergies: ugh, same here - feel you)
>
> > > produce from sitting on my keyboard. Could you use full words for the
> > > node name and make it something that attempts to be generic please?
> > >
>
> I'm not entirely sure that I can find a generic name for this... I wonder if
> "remoteproc" could work - as this is a remote processor (a MCU, actually).
>
> To give you context, this doesn't need firmware to be loaded, and does not have
> any remoteproc driver.

I dunno, I don't think having to load firmware to something or interact
with a remoteproc driver in linux changes what the hardware actually is.
>
> Because then, I don't think that "performance-controller" would be correct,
> even though I have this N.2 choice... ideas?

My lot call this type of thing a "system controller" in our specs. Any of
firmware, remote-processor, performance-controller all seem valid to me.

> Cheers,

Cheers,
Conor.

Attachment: signature.asc
Description: PGP signature