Re: [PATCH v3 03/17] arm64: dts: sdm845: Add OPP table for all qup devices

[Rajendra Nayak]

On 4/29/2020 9:40 PM, Matthias Kaehlcke wrote:
> On Wed, Apr 29, 2020 at 08:23:30PM +0530, Rajendra Nayak wrote:
> > On 4/29/2020 7:45 PM, Rajendra Nayak wrote:
> > > On 4/29/2020 5:32 AM, Matthias Kaehlcke wrote:
> > > > Hi Rajendra,
> > > >
> > > > On Tue, Apr 28, 2020 at 07:02:51PM +0530, Rajendra Nayak wrote:
> > > > > qup has a requirement to vote on the performance state of the CX domain
> > > > > in sdm845 devices. Add OPP tables for these and also add power-domains
> > > > > property for all qup instances.
> > > > >
> > > > > Signed-off-by: Rajendra Nayak <rnayak@xxxxxxxxxxxxxx>
> > > > > Signed-off-by: Stephen Boyd <swboyd@xxxxxxxxxxxx>
> > > > > ---
> > > > >  Â arch/arm64/boot/dts/qcom/sdm845.dtsi | 115 +++++++++++++++++++++++++++++++++++
> > > > >  Â 1 file changed, 115 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > > index 8f926b5..36b9fb1 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > > @@ -804,6 +804,25 @@
> > > > >  ÂÂÂÂÂÂÂÂÂÂÂÂÂ clock-names = "core";
> > > > >  ÂÂÂÂÂÂÂÂÂ };
> > > > > +ÂÂÂÂÂÂÂ qup_opp_table: qup-opp-table {
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂ compatible = "operating-points-v2";
> > > > > +
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂ opp-19200000 {
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ opp-hz = /bits/ 64 <19200000>;
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ required-opps = <&rpmhpd_opp_min_svs>;
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂ };
> > > > > +
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂ opp-75000000 {
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ opp-hz = /bits/ 64 <75000000>;
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ required-opps = <&rpmhpd_opp_low_svs>;
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂ };
> > > > > +
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂ opp-100000000 {
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ opp-hz = /bits/ 64 <100000000>;
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ required-opps = <&rpmhpd_opp_svs>;
> > > > > +ÂÂÂÂÂÂÂÂÂÂÂ };
> > > > > +ÂÂÂÂÂÂÂ };
> > > > > +
> > > >
> > > > Judging from SDM845 (which has more OPP tables) the convention seems to be
> > > > to add OPP tables to the nodes that use them, which seems reasonable and
> > > > keeps them out of the device list.
> > > >
> > > > Unfortunately this convention isn't completely suitable for cases like this
> > > > (and the DSI OPPs later in this series), where the same OPP table is used by
> > > > multiple devices. A possible compromise would be to add the table to the
> > > > node of the first device that uses them.
> > >
> > > Sounds fair, I will do that and respin. Thanks.
> >
> > Looking into this some more, I see we do have..
> >
> > static const struct of_device_id of_skipped_node_table[] = {
> >          { .compatible = "operating-points-v2", },
> >          {} /* Empty terminated list */
> > };
> >
> > ..in drivers/of/platform.c, so its not being added to the device list.
>
> sure, I didn't mean that the OPP table is added by the kernel as a device, but
> that the table breaks with the structure of the DT of device nodes ordered by
> address.

Ah ok, got it.

> > And atleast in case of qup, I am having to duplicate the OPP tables once for
> > each qup instance. Not to mention, having them inside the first qup device
> > just makes it a little confusing to read who the OPP table belongs to.
>
> I'm not advocating for duplicating the OPP tables. An alternative to having
> them in the first QUP device could be to have an dedicated node with shared
> opp tables outside of the device list, similar to thermal-zones.

That sounds like a good idea too.

> I tend to like consistency and the sprinkled in OPP tables break with that,
> but ultimately it's up to Bjorn.

Bjorn, any thoughts?

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation