On 4/23/20 4:12 PM, Daniel Lezcano wrote:
On Fri, Apr 10, 2020 at 09:42:04AM +0100, Lukasz Luba wrote:
Add support for other devices that CPUs. The registration function
does not require a valid cpumask pointer and is ready to handle new
devices. Some of the internal structures has been reorganized in order to
keep consistent view (like removing per_cpu pd pointers). To track usage
of the Energy Model structures, they are protected with kref.
Why not add the energy model structure in the struct device directly?
Do you mean this structure?
https://elixir.bootlin.com/linux/latest/source/include/linux/device.h#L537
and to put something like:
struct device {
...
struct dev_pm_domain *pm_domain;
#ifdef CONFIG_ENERGY_MODEL
struct em_perf_domain *em_pd;
#endif
...
};
For instance for the em_cpu_get() function, the cpu id allows to retrieve the
cpu device and then from there, the energy model instead of browsing another
list. The em_device life cycle will be tied to the struct device.
That would be perfect.
Then when the struct device and the em_device are connected, add the debugfs
with a struct device list for those which are energy aware, so you end up with
a structure:
struct em_device {
struct device *dev;
struct list_head em_dev_list;
};
(a global single dentry for debugfs to do a recursive delete is enough).
Locks when inspecting and add/removal called from the struct device release
function. So no need of an extra refcounting.
Does it make sense?
Indeed it looks much cleaner/simpler.
I will try to address this idea and get rid of refcounting.
This should be doable in this patch (4/10). In the v7 I will keep your
ACKs for other patches that you have already commented.
Thank you for your suggestions and review.
Regards,
Lukasz
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
