Re: [PATCH v1 0/3] Add required-opps support to devfreq passive gov

[Viresh Kumar]

On 26-06-19, 11:10, Saravana Kannan wrote:
> On Tue, Jun 25, 2019 at 11:32 PM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:

> > So, when a CPU changes frequency, we must change the performance state
> > of PM domain and change frequency/bw of the cache synchronously.
> 
> I mean, it's going to be changed when we get the CPUfreq transition
> notifiers. From a correctness point of view, setting it inside the OPP
> framework is not any better than doing it when we get the notifiers.

That's what the problem is. All maintainers now a days ask people to
stay away from notifiers and we are making that base of another new
thing we are starting.

Over that, with many cpufreq drivers we have fast switching enabled
and notifiers disabled. How will they make these things work ? We
still want to scale L3 in those cases as well.

> I see this as "required for good performance". So I don't see it as
> redefining required-opps. If someone wants good performance/power
> balance they follow the "required-opps". Technically even the PM
> pstates are required for good power. Otherwise, the system could leave
> the voltage at max and stuff would still work.
> 
> Also, the slave device might need to get input from multiple master
> devices and aggregate the request before setting the slave device
> frequency. So I don't think OPP  framework would be the right place to
> deal with those things. For example, L3 might (will) have different
> mappings for big vs little cores. So that needs to be aggregated and
> set properly by the slave device driver. Also, GPU might have a
> mapping for L3 too. In which case the L3 slave driver needs to take
> input from even more masters before it decides its frequency. But most
> importantly, we still need the ability to change governors for L3.
> Again these are just examples with L3 and it can get more complicated
> based on the situation.
> 
> Most importantly, instead of always going by mapping, one might decide
> to scale the L3 based on some other governor (that looks at some HW
> counter). Or just set it to performance governor for a use case for
> which performance is more important. All of this comes for free with
> devfreq and if we always set it from OPP framework we don't give this
> required control to userspace.
> 
> I think going through devfreq is the right approach for this. And we
> can always rewrite the software if we find problems in the future. But
> as it stands today, this will help cases like exynos without the need
> for a lot of changes. Hope I've convinced you.

I understand the aggregation thing and fully support that the
aggregation can't happen in OPP core and must be done somewhere else.
But the input can go from OPP core while the frequency is changing,
isn't it ?

-- 
viresh