On Fri, Feb 21, 2020 at 1:48 PM Lukasz Luba <lukasz.luba@xxxxxxx> 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@xxxxxxx>
> ---
> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
