Received-SPF: pass (google.com: domain of linux-kernel+bounces-46057-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Wed, 31 Jan 2024 14:16:45 +0530
From: Manivannan Sadhasivam <mani@kernel.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>,
	Krishna chaitanya chundru <quic_krichai@quicinc.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Johan Hovold <johan+linaro@kernel.org>,
	Brian Masney <bmasney@redhat.com>,
	Georgi Djakov <djakov@kernel.org>, linux-arm-msm@vger.kernel.org,
	vireshk@kernel.org, quic_vbadigan@quicinc.com,
	quic_skananth@quicinc.com, quic_nitegupt@quicinc.com,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 5/6] arm64: dts: qcom: sm8450: Add opp table support
 to PCIe
Message-ID: <20240131084645.GA3481@thinkpad>
References: <20240112-opp_support-v6-0-77bbf7d0cc37@quicinc.com>
 <20240112-opp_support-v6-5-77bbf7d0cc37@quicinc.com>
 <20240129160420.GA27739@thinkpad>
 <20240130061111.eeo2fzaltpbh35sj@vireshk-i7>
 <20240130071449.GG32821@thinkpad>
 <20240130083619.lqbj47fl7aa5j3k5@vireshk-i7>
 <20240130094804.GD83288@thinkpad>
 <20240130095508.zgufudflizrpxqhy@vireshk-i7>
 <20240130131625.GA2554@thinkpad>
 <20240131052335.6nqpmccgr64voque@vireshk-i7>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240131052335.6nqpmccgr64voque@vireshk-i7>

On Wed, Jan 31, 2024 at 10:53:35AM +0530, Viresh Kumar wrote:
> On 30-01-24, 18:46, Manivannan Sadhasivam wrote:
> > Agree. But what I'm saying is, right now there is no DT property in the
> > interconnect consumer nodes to specificy the bw requirements. This is all
> > hardcoded in the respective ICC consumer drivers.
> 
> I thought there are a lot of users already in there..
> 
> $ git grep -i opp.*bps arch/arm64/boot/dts/ | wc -l
> 864

Most of the hits are from CPU nodes... For some reasons, peripheral drivers are
sticking to hardcoded values.

> 
> > But when we use OPP to control bw, the bw requirements come from DT. This is
> > what I see as a difference. Because, only nodes making use of OPP will specify
> > bw in DT and other nodes making use of just ICC will not.
> > 
> > Maybe I'm worrying too much about these details... But it looks like
> > inconsistency to me.
> 
> Right. So is there inconsistency right now ? Yes, there is.
> 
> The important question we need to answer is where do we want to see
> all these drivers (specially new ones) in the future. What's the right
> thing to do eventually ? Hardcode stuff ? Or Move it to DT ?
> 
> The answer is DT for me, so the code can be generic enough to be
> reused. This is just one step in the right direction I guess.
> Eventually the drivers must get simplified, which they are I guess.
> 

I completely agree that hardcoding the bw values is not the right thing, but was
worried about the inconsistency. But anyway, I hope either ICC will also move
towards DT for bw or we will convert all the drivers to use OPP in the future.

Thanks for the discussion so far! It clarified.

- Mani

-- 
மணிவண்ணன் சதாசிவம்