On 1/20/20 3:28 PM, Quentin Perret wrote:
On Monday 20 Jan 2020 at 15:53:35 (+0100), Dietmar Eggemann wrote:Would be really nice if this wouldn't be required. We should really aim for 1 framework == 1 set of interfaces. What happens if someone calls em_get_pd() on a CPU EM? E.g: static struct perf_domain *pd_init(int cpu) { - struct em_perf_domain *obj = em_cpu_get(cpu); + struct device *dev = get_cpu_device(cpu); + struct em_perf_domain *obj = em_pd_get(dev); struct perf_domain *pd; Two versions of one functionality will confuse API user from the beginning ...Agreed, this looks a bit confusing. It should be trivial to make em_dev_get() (or whatever we end up calling it) work for CPUs too, though. And we could always have a em_cpu_get(int cpu) API that is a basically a wrapper around em_dev_get() for convenience.
The problem not only here is that we have a CPU index 'int cpu' and if we ask for device like: struct device *dev = get_cpu_device(cpu); It might be not the same device that was used during the registration, when we had i.e. 4 CPUs for the same policy: int cpu_id = cpumask_first(policy->cpus); struct device *cpu_dev = get_cpu_device(cpu_id); em_register_perf_domain(cpu_dev, nr_opp, &em_cb); That's why the em_cpu_get() is different than em_get_pd(), mainly by: if (cpumask_test_cpu(cpu, em_span_cpus(em_pd))) It won't be simple wrapper, let me think how it could be handled differently than it is now. Regards, Lukasz
Thanks, Quentin
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
