On Fri, Feb 21, 2020 at 1:48 PM Lukasz Luba lukasz.luba@arm.com wrote:
Add device to the Energy Model framework. It will create a dedicated and unified data structures used i.e. in the thermal framework. The power model used in dev_pm_opp subsystem is simplified and created based on DT 'dynamic-power-coefficient', volatage and frequency. It is
typo.
similar to the CPU model used in Energy Aware Scheduler.
Signed-off-by: Lukasz Luba lukasz.luba@arm.com
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c b/drivers/gpu/drm/panfrost/panfrost_devfreq.c index 413987038fbf..d527a5113950 100644 --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c @@ -105,6 +105,8 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev) } pfdev->devfreq.devfreq = devfreq;
dev_pm_opp_of_register_em(dev, NULL);
Can't fail?
cooling = of_devfreq_cooling_register(dev->of_node, devfreq); if (IS_ERR(cooling)) DRM_DEV_INFO(dev, "Failed to register cooling device\n");@@ -118,6 +120,7 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev) { if (pfdev->devfreq.cooling) devfreq_cooling_unregister(pfdev->devfreq.cooling);
dev_pm_opp_of_unregister_em(&pfdev->pdev->dev); dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
Does it make sense to keep this (and the registration side) as separate calls? Perhaps there's some ordering requirement with everything between dev_pm_opp_of_add_table() and dev_pm_opp_of_register_em()?
While you're just adding 2 lines, it seems there's a lot of complexity exposed to the driver just to initialize devfreq/opp.
Rob