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@xxxxxxxxxxxxxx> > > > --- > > > 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@xxxxxxxxxxxxxx/ > > 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.
