Re: [PATCH v8 3/5] arm64: dts: qcom: sc7180: Enable SoC sleep stats

From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Maulik Shah <mkshah@codeaurora.org>,
	evgreen@chromium.org, mka@chromium.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	agross@kernel.org, dianders@chromium.org, linux@roeck-us.net,
	rnayak@codeaurora.org, lsrao@codeaurora.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v8 3/5] arm64: dts: qcom: sc7180: Enable SoC sleep stats
Date: Sat, 5 Jun 2021 22:42:54 -0500	[thread overview]
Message-ID: <YLxEPkQdKKYNDHqv@builder.lan> (raw)
In-Reply-To: <CAE-0n511_GHcyPDSeDaf5QSqVQqyHOqxJCGaSWNr=x9uotegLg@mail.gmail.com>

On Fri 04 Jun 16:53 CDT 2021, Stephen Boyd wrote:

> Quoting Bjorn Andersson (2021-06-02 19:44:40)
> > On Wed 02 Jun 19:26 CDT 2021, Stephen Boyd wrote:
> >
> > > Quoting Bjorn Andersson (2021-05-31 10:57:03)
> > > > On Wed 26 May 18:30 CDT 2021, Stephen Boyd wrote:
> > > >
> > > > > Quoting Maulik Shah (2021-05-21 04:26:09)
> > > > > > @@ -3223,6 +3223,11 @@
> > > > > >                         #power-domain-cells = <1>;
> > > > > >                 };
> > > > > >
> > > > > > +               rpmh-sleep-stats@c3f0000 {
> > > > > > +                       compatible = "qcom,rpmh-sleep-stats";
> > > > > > +                       reg = <0 0x0c3f0000 0 0x400>;
> > > > > > +               };
> > > > > > +
> > > > >
> > > > > Does this need to be in DT? Can the sc7180-aoss-qmp driver use the
> > > > > aux-bus and stick the sleep stats device on there?
> > > > >
> > > >
> > > > The AOSS memory space has N chunks of "message ram", one is used for the
> > > > QMP protocol (presumably the APSS specific one), a different one is used
> > > > for the sleep stats.
> > > >
> > > > I presume we could have come up with a binding for the entire AOSS/AOP
> > > > and then describe (either implicit or explicitly) the QMP and
> > > > debug-stats under that.
> > > >
> > > > But we'd also have to come up with the same container-device for the RPM
> > > > case.
> > >
> > > Because the rpm node doesn't include this region of memory today? I
> > > still fail to see why we're changing the existing binding and adding a
> > > DT node for this new region that is basically a debug feature.
> >
> > We're not changing the binding, the memory region for the "AOSS QMP"
> > thing was never larger than 0x400.
> >
> > 0x100000 is the size of all the AOSS "msg_ram" regions. We don't have
> > this whole thing described in a binding and we don't have an
> > implementation for the whole thing.
> >
> > If we're going for that we'd need to extend the binding to indicate
> > which of the msg_ram regions are used for APSS QMP and for debug stats
> > on particular platform (either by compatible, explicit properties or as
> > some subnodes).
> 
> Fair enough. At the least, can we change the name of the node then to
> 'sram' or 'ram'? The 'rpmh-sleep-stats' node name is nonsense.
> 

Yes, "ram" sounds like a better node name for both the qmp and
sleep-stats region - in the RPMH case.

> >
> >
> > That said, as I looked into my other objection, for the RPM
> > (non-hardened) case it seems that we're actually describing the RPM
> > region. So there it would make sense to describe it as such in DT - but
> > we don't have any other code (that I'm aware of) that would implement
> > the "qcom,<platform>-rpm".
> >
> 
> I only half parsed this part. Are you saying that because we don't have
> a driver for qcom,<platform>-rpm we shouldn't keep it all within the rpm
> node?

What I was trying to say is that in the RPM (non-H) case the described
memory region is not a chunk of "ram" (or "sram"), but seems to rather
be the RPM region. So there it seems more reasonable to have a non-debug
compatible, but I don't think we have any other use for it than the
debug-stats...

Regards,
Bjorn