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

[Akhil P Oommen]

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.

-Akhil.