Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies

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

 



On 13-10-20, 14:53, Lukasz Luba wrote:
> I've started wondering based on the OPP code if this is a good solution.
> We would end up with one (?) instance of opp_table and list of devices
> pinned to it, in: opp_table->dev_list
> It can be seen e.g. in function dev_pm_opp_get_sharing_cpus(),
> where we retrieve the cpumask simply looping through the devices:
> 
> list_for_each_entry(opp_dev, &opp_table->dev_list, node)
> 	cpumask_set_cpu(opp_dev->dev->id, cpumask);
> 
> 
> This means we have a single OPP table for all pinned CPUs.
> I wonder if this is not too strong assumption for still being compliant
> with SCMI spec, when in theory performance levels might differ...
> (please correct me here it that would never happen)
> 
> There is also 2nd function dev_pm_opp_of_get_sharing_cpus() which looks
> more promising. But I still don't know if the framework will allow us
> to have private OPP tables when we use 'shared' in DT.
> 
> Could you clarify if we would get 'private' opp table for each CPU,
> which could be then populated independently, but still 2nd function will
> work?

I think there is some misunderstanding here in your part. The
opp-table in the code is shared between CPUs only when the
"opp-shared" property is present in the OPP table. If that property
isn't available, even if same DT opp-table is pointed at by all the
CPUs, the code will have separate copies of the OPP table.

Though in your case (with performance-levels) it shouldn't matter as
code will never create an OPP table I suppose.

-- 
viresh



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux