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

[Conor Dooley]

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 at collabora.com>
> > > > ---
> > > >   .../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 at collabora.com>
> > > > +  - Henry Chen <henryc.chen at mediatek.com>
> > > > +
> > > > +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 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240417/662b4285/attachment.sig>