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

[Rob Herring]

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. 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.

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

Rob