Hi,
On Thu, Nov 4, 2021 at 9:32 PM Steev Klimaszewski steev@kali.org wrote:
On 11/4/21 5:28 PM, Rob Clark wrote:
From: Rob Clark robdclark@chromium.org
Reported-by: Douglas Anderson dianders@chromium.org Fixes: 9bc95570175a ("drm/msm: Devfreq tuning") Signed-off-by: Rob Clark robdclark@chromium.org
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c b/drivers/gpu/drm/msm/msm_gpu_devfreq.c index d32b729b4616..9bf8600b6eea 100644 --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c @@ -20,8 +20,6 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq, struct msm_gpu *gpu = dev_to_gpu(dev); struct dev_pm_opp *opp;
opp = devfreq_recommended_opp(dev, freq, flags);/* * If the GPU is idle, devfreq is not aware, so just ignore * it's requests@@ -31,6 +29,8 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq, return 0; }
opp = devfreq_recommended_opp(dev, freq, flags);if (IS_ERR(opp)) return PTR_ERR(opp);Testing this here on the Lenovo Yoga C630, and I'm starting to see in my dmesg output
[ 36.337061] devfreq 5000000.gpu: Couldn't update frequency transition information. [ 36.388122] devfreq 5000000.gpu: Couldn't update frequency transition information.
Ah, I think this makes sense. We're now storing a frequency which might not match an actual "opp" and I suppose that we must return it in some cases.
I guess a simple fix is to still call devfreq_recommended_opp() in the idle case but just call dev_pm_opp_put() to fix the leak.
-Doug