Re: [RFC v3 09/10] arm64: dts: qcom: sdm845: Add cpu OPP tables

[Matthias Kaehlcke <mka@chromium.org>]

Hi Sibi,

On Wed, Jan 29, 2020 at 07:35:21PM +0530, Sibi Sankar wrote:
> Hey Matthias,
> 
> Thanks for the review!
> 
> On 2020-01-29 06:54, Matthias Kaehlcke wrote:
> > Hi Sibi,
> > 
> > On Tue, Jan 28, 2020 at 01:33:49AM +0530, Sibi Sankar wrote:
> > > Add OPP tables required to scale DDR/L3 per freq-domain on SDM845
> > > SoCs.
> > > 
> > > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> > > ---
> > >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 453
> > > +++++++++++++++++++++++++++
> > >  1 file changed, 453 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > index c036bab49fc03..8cb976118407b 100644
> > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > @@ -199,6 +199,12 @@
> > >  			qcom,freq-domain = <&cpufreq_hw 0>;
> > >  			#cooling-cells = <2>;
> > >  			next-level-cache = <&L2_0>;
> > > +			operating-points-v2 = <&cpu0_opp_table>,
> > > +					      <&cpu0_ddr_bw_opp_table>,
> > > +					      <&cpu0_l3_bw_opp_table>;
> > > +			interconnects = <&gladiator_noc MASTER_APPSS_PROC &mem_noc
> > > SLAVE_EBI1>,
> > > +					<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;
> > 
> > This apparently depends on the 'Split SDM845 interconnect nodes and
> > consolidate RPMh support' series
> > (https://patchwork.kernel.org/project/linux-arm-msm/list/?series=226281),
> > which isn't mentioned in the cover letter.
> > 
> > I also couldn't find a patch on the lists that adds the 'osm_l3'
> > interconnect node for SDM845. The same is true for SC7180 (next
> > patch of this series). These patches may be available in custom trees,
> > but that isn't really helpful for upstream review.
> 
> yeah I missed adding the interconnect
> refactor dependency and the nodes.
> 
> > 
> > I would suggest to focus on landing the dependencies of this series,
> > before proceding with it (or at least most of them), there are plenty
> > and without the dependencies this series isn't going to land, it also
> > makes it hard for testers and reviewers to get all the pieces
> 
> yes I understand but wanted the series
> out asap because since there are a few
> points where we still havn't reached
> a consensus on.

Ok, I just wanted to make sure we are not burning the limited
maintainer/reviewer bandwidth on code with hard dependencies on
things that aren't moving forward.

> > together. In particular the last post of the series 'Add
> > required-opps support to devfreq passive gov'
> > (https://patchwork.kernel.org/cover/11055499/) is from July 2019 ...
> 
> https://lore.kernel.org/lkml/CAGTfZH37ALwUHd8SpRRrBzZ6x1-++YtzS60_yRQvN-TN6rOzaA@mail.gmail.com/
> 
> The pending patch for lazy linking
> was posted a while back. Now that
> it has a tested-by, majority of the
> series should go in since the devfreq
> maintainers wanted the series pulled
> in.

Thanks for the clarification. For reference the post is
https://patchwork.kernel.org/patch/11048277/#23020727

It sems the series will require at least another re-spin:

  "So once that's (lazy linking) added, I should be able to drop a few
  patches in this series, do some minor updates and then this will be
  good to go."

  https://patchwork.kernel.org/cover/11055499/#23001445

So it looks like we are waiting for the lazy linking patch to
land in the PM/Linus' tree and then a re-spin of the 'Add
required-opps support to devfreq passive gov' series.