mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Rob Clark <robdclark@gmail.com>, dri-devel@lists.freedesktop.org
Cc: freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	Rob Clark <robdclark@chromium.org>,
	Linux Kernel Functional Testing <lkft@linaro.org>,
	Anders Roxell <anders.roxell@linaro.org>,
	Sean Paul <sean@poorly.run>,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/msm/gpu: Fix crash on devices without devfreq support
Date: Wed, 23 Feb 2022 06:11:28 +0300	[thread overview]
Message-ID: <6f1225ea-d889-9cf8-3a3d-181e319bd453@linaro.org> (raw)
In-Reply-To: <20220219183310.557435-1-robdclark@gmail.com>

On 19/02/2022 21:33, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> Avoid going down devfreq paths on devices where devfreq is not
> initialized.
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> Reported-by: Anders Roxell <anders.roxell@linaro.org>
> Signed-off-by: Rob Clark <robdclark@chromium.org>
> ---
>   drivers/gpu/drm/msm/msm_gpu_devfreq.c | 31 +++++++++++++++++++++------
>   1 file changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> index 9bf319be11f6..26a3669a97b3 100644
> --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> @@ -83,12 +83,17 @@ static struct devfreq_dev_profile msm_devfreq_profile = {
>   static void msm_devfreq_boost_work(struct kthread_work *work);
>   static void msm_devfreq_idle_work(struct kthread_work *work);
>   
> +static bool has_devfreq(struct msm_gpu *gpu)
> +{
> +	return !!gpu->funcs->gpu_busy;

I see that devfreq init will be skipped if gpu_busy is NULL.
Can we use gpu->devfreq instead of this condition?

I noticed that you have replaced some of gpu->devfreq checks with 
has_devreq() calls. Is there any difference?

> +}
> +
>   void msm_devfreq_init(struct msm_gpu *gpu)
>   {
>   	struct msm_gpu_devfreq *df = &gpu->devfreq;
>   
>   	/* We need target support to do devfreq */
> -	if (!gpu->funcs->gpu_busy)
> +	if (!has_devfreq(gpu))
>   		return;
>   
>   	dev_pm_qos_add_request(&gpu->pdev->dev, &df->idle_freq,
> @@ -149,6 +154,9 @@ void msm_devfreq_cleanup(struct msm_gpu *gpu)
>   {
>   	struct msm_gpu_devfreq *df = &gpu->devfreq;
>   
> +	if (!has_devfreq(gpu))
> +		return;
> +
>   	devfreq_cooling_unregister(gpu->cooling);
>   	dev_pm_qos_remove_request(&df->boost_freq);
>   	dev_pm_qos_remove_request(&df->idle_freq);
> @@ -156,16 +164,24 @@ void msm_devfreq_cleanup(struct msm_gpu *gpu)
>   
>   void msm_devfreq_resume(struct msm_gpu *gpu)
>   {
> -	gpu->devfreq.busy_cycles = 0;
> -	gpu->devfreq.time = ktime_get();
> +	struct msm_gpu_devfreq *df = &gpu->devfreq;
>   
> -	devfreq_resume_device(gpu->devfreq.devfreq);
> +	if (!has_devfreq(gpu))
> +		return;
> +
> +	df->busy_cycles = 0;
> +	df->time = ktime_get();
> +
> +	devfreq_resume_device(df->devfreq);
>   }
>   
>   void msm_devfreq_suspend(struct msm_gpu *gpu)
>   {
>   	struct msm_gpu_devfreq *df = &gpu->devfreq;
>   
> +	if (!has_devfreq(gpu))
> +		return;
> +
>   	devfreq_suspend_device(df->devfreq);
>   
>   	cancel_idle_work(df);
> @@ -185,6 +201,9 @@ void msm_devfreq_boost(struct msm_gpu *gpu, unsigned factor)
>   	struct msm_gpu_devfreq *df = &gpu->devfreq;
>   	uint64_t freq;
>   
> +	if (!has_devfreq(gpu))
> +		return;
> +
>   	freq = get_freq(gpu);
>   	freq *= factor;
>   
> @@ -207,7 +226,7 @@ void msm_devfreq_active(struct msm_gpu *gpu)
>   	struct devfreq_dev_status status;
>   	unsigned int idle_time;
>   
> -	if (!df->devfreq)
> +	if (!has_devfreq(gpu))
>   		return;
>   
>   	/*
> @@ -253,7 +272,7 @@ void msm_devfreq_idle(struct msm_gpu *gpu)
>   {
>   	struct msm_gpu_devfreq *df = &gpu->devfreq;
>   
> -	if (!df->devfreq)
> +	if (!has_devfreq(gpu))
>   		return;
>   
>   	msm_hrtimer_queue_work(&df->idle_work, ms_to_ktime(1),


-- 
With best wishes
Dmitry

  parent reply	other threads:[~2022-02-23  3:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-19 18:33 Rob Clark
2022-02-19 18:37 ` Rob Clark
2022-02-23  3:11 ` Dmitry Baryshkov [this message]
2022-02-23 15:46   ` Rob Clark
2022-03-03  7:06     ` Dmitry Baryshkov
2022-03-07  8:37 ` Naresh Kamboju
2022-03-14 12:31   ` Naresh Kamboju

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6f1225ea-d889-9cf8-3a3d-181e319bd453@linaro.org \
    --to=dmitry.baryshkov@linaro.org \
    --cc=airlied@linux.ie \
    --cc=anders.roxell@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkft@linaro.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®