Re: [PATCH v7 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children

[André Draszik]

On Fri, 2026-03-13 at 08:26 -0500, Rob Herring wrote:
> On Fri, Mar 13, 2026 at 5:48 AM André Draszik <andre.draszik@xxxxxxxxxx> wrote:
> > 
> > On Thu, 2026-03-12 at 10:12 -0500, Rob Herring wrote:
> > > On Fri, Mar 06, 2026 at 10:29:55AM +0000, André Draszik wrote:
> > > 
> > > >      system-controller@17460000 {
> > > >          compatible = "google,gs101-pmu";
> > > >          reg = <0x17460000 0x10000>;
> > > > +        #address-cells = <1>;
> > > > +        #size-cells = <1>;
> > > > +        ranges;
> > > > 
> > > >          google,pmu-intr-gen-syscon = <&pmu_intr_gen>;
> > > > +
> > > > +        pd_g3d: power-domain@1e00 {
> > > > +            compatible = "google,gs101-pd";
> > > > +            reg = <0x1e00 0x80>;
> > > 
> > > I'm assuming 0x1e00 is an offset from 0x17460000. That's not what ranges
> > > says though. It says both addresses are in the same address space
> > > (system-controller@17460000 parent's address space). You need:
> > > 
> > > ranges = <0x0 0x17460000 0x10000>;
> > 
> > Thanks Rob! On gs101, the PD driver can not do direct mmio. Instead it
> > needs to use the regmap that the parent has created and apply the
> > offset from the PD's reg property (using struct resource::start)
> > (patch 7).
> > 
> > When using ranges as per your suggestion that doesn't work anymore,
> > as resource->start isn't the offset anymore but the final physical
> > address, and using that in combination with the parent's regmap
> > doesn't give us the right address anymore.
> 
> You are mixing kernel implementation details and h/w.

Just trying to get to the best solution, considering both.

> Are the
> registers in the child nodes MMIO or not? If not, then drop ranges. If
> they are, then what I suggested for ranges is correct.

While they are MMIO in theory and offsets into the parent's address
space, in practice access from the OS is not possible via mmio APIs,
only via the custom regmap created by the parent (which defers to the
EL3 firmware) - hence the driver's need for the offset from the
parent's base address.

> For MMIO, your kernel implementation options are what you suggested,
> do a regmap for each child, or use of_property_read_reg().

OK, I'll go with the first option then, thanks for your patience Rob!

Cheers,
Andre'