lkml.org 
[lkml]   [2020]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC v3 09/10] arm64: dts: qcom: sdm845: Add cpu OPP tables
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.

\
 
 \ /
  Last update: 2020-01-29 19:19    [W:0.103 / U:1.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site