linux-kernel - Re: [PATCH 03/13] opp: Keep track of currently programmed OPP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210128041431.rnfp3yrh7mp7e2gb@vireshk-i7>
Date:   Thu, 28 Jan 2021 09:44:31 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Akhil P Oommen <akhilpo@...eaurora.org>
Cc:     Dmitry Osipenko <digetx@...il.com>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Stephen Boyd <sboyd@...nel.org>, linux-pm@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Sibi Sankar <sibis@...eaurora.org>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 03/13] opp: Keep track of currently programmed OPP

On 27-01-21, 22:01, Akhil P Oommen wrote:
> On 1/22/2021 10:15 AM, Viresh Kumar wrote:
> > On 22-01-21, 00:41, Dmitry Osipenko wrote:
> > > 21.01.2021 14:17, Viresh Kumar пишет:
> > > > @@ -1074,15 +1091,18 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
> > > >   	if (!ret) {
> > > >   		ret = _set_opp_bw(opp_table, opp, dev, false);
> > > > -		if (!ret)
> > > > +		if (!ret) {
> > > >   			opp_table->enabled = true;
> > > > +			dev_pm_opp_put(old_opp);
> > > > +
> > > > +			/* Make sure current_opp doesn't get freed */
> > > > +			dev_pm_opp_get(opp);
> > > > +			opp_table->current_opp = opp;
> > > > +		}
> > > >   	}
> > > 
> > > I'm a bit surprised that _set_opp_bw() isn't used similarly to
> > > _set_opp_voltage() in _generic_set_opp_regulator().
> > > 
> > > I'd expect the BW requirement to be raised before the clock rate goes UP.
> > 
> > I remember discussing that earlier when this stuff came in, and this I
> > believe is the reason for that.
> > 
> > We need to scale regulators before/after frequency because when we
> > increase the frequency a regulator may _not_ be providing enough power
> > to sustain that (even for a short while) and this may have undesired
> > effects on the hardware and so it is important to prevent that
> > malfunction.
> > 
> > In case of bandwidth such issues will not happen (AFAIK) and doing it
> > just once is normally enough. It is just about allowing more data to
> > be transmitted, and won't make the hardware behave badly.
> > 
> I agree with Dmitry. BW is a shared resource in a lot of architectures.
> Raising clk before increasing the bw can lead to a scenario where this
> client saturate the entire BW for whatever small duration it may be. This
> will impact the latency requirements of other clients.

I see. I will make the necessary changes then to fix it. Thanks guys.

-- 
viresh