Re: [PATCH v6 5/6] arm64: dts: qcom: sm8450: Add opp table support to PCIe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 19, 2024 at 03:58:34PM +0530, Viresh Kumar wrote:
> On 09-02-24, 22:14, Konrad Dybcio wrote:
> > On 2.02.2024 08:33, Viresh Kumar wrote:
> > > On 01-02-24, 15:45, Konrad Dybcio wrote:
> > >> I'm lukewarm on this.
> > >>
> > >> A *lot* of hardware has more complex requirements than "x MBps at y MHz",
> > >> especially when performance counters come into the picture for dynamic
> > >> bw management.
> > >>
> > >> OPP tables can't really handle this properly.
> > > 
> > > There was a similar concern for voltages earlier on and we added the capability
> > > of adjusting the voltage for OPPs in the OPP core. Maybe something similar can
> > > be done here ?
> > > 
> > I really don't think it's fitting.. At any moment the device may require any
> > bandwidth value between 0 and MAX_BW_PER_LINK_GEN * LINK_WIDTH..
> 
> Okay, I leave it up to you guys to decide on how you want to do it. I still
> believe getting the information via DT is the right thing, but maybe I still
> don't understand the problem fully.
> 

I argued for a different issue, but what Konrad pointed out is not a valid
concern to me. The driver may only require _fixed_ bandwidth between 0 and
(MAX_BW_PER_LINK_GEN * LINK_WIDTH) and DT can pass those bandwidth values.

Chaitanya pointed out that this may end up with long entries in DT once the PCIe
Gen versions start to increase (current Qcom platforms support upto Gen 4 only).
But that shouldn't be a real concern if we look at what DT has to provide.

- Mani

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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux