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
