linux.git/drivers/gpu/drm/msm/msm_gpu_devfreq.c, branch v5.17

drm/msm/gpu: Cancel idle/boost work on suspend

2022-01-25T16:54:41+00:00

With system suspend using pm_runtime_force_suspend() we can't rely on
the pm_runtime_get_if_in_use() trick to deal with devfreq callbacks
after (or racing with) suspend.  So flush any pending idle or boost
work in the suspend path.

Signed-off-by: Rob Clark 
Link: https://lore.kernel.org/r/20220108180913.814448-3-robdclark@gmail.com
Signed-off-by: Rob Clark

drm/msm/gpu: Respect PM QoS constraints

2021-11-28T18:01:40+00:00

Re-work the boost and idle clamping to use PM QoS requests instead, so
they get aggreggated with other requests (such as cooling device).

This does have the minor side-effect that devfreq sysfs min_freq/
max_freq files now reflect the boost and idle clamping, as they show
(despite what they are documented to show) the aggregated min/max freq.
Fixing that in devfreq does not look straightforward after considering
that OPPs can be dynamically added/removed.  However writes to the
sysfs files still behave as expected.

v2: Use 64b math to avoid potential 32b overflow

Signed-off-by: Rob Clark 
Link: https://lore.kernel.org/r/20211120200103.1051459-3-robdclark@gmail.com
Signed-off-by: Rob Clark

drm/msm: Increase gpu boost interval

2021-11-28T18:00:20+00:00

Currently, we boost gpu freq after 25ms of inactivity. This regresses
some of the 30 fps usecases where the workload on gpu (at 33ms internval)
is very small which it can finish at the lowest OPP before the deadline.
Lets increase this inactivity threshold to 50ms (same as the current
devfreq interval) to fix this.

Signed-off-by: Akhil P Oommen 
Link: https://lore.kernel.org/r/20211118154903.1.I2ed37cd8ad45a5a94d9de53330f973a62bd1fb29@changeid
Signed-off-by: Rob Clark

drm/msm/gpu: Fix check for devices without devfreq

2021-11-21T20:56:51+00:00

Looks like 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before
clamping freq") was badly rebased on top of efb8a170a367 ("drm/msm:
Fix devfreq NULL pointer dereference on a3xx") and ended up with
the NULL check in the wrong place.

Fixes: 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before clamping freq")
Signed-off-by: Rob Clark 
Link: https://lore.kernel.org/r/20211120200103.1051459-2-robdclark@gmail.com
Signed-off-by: Rob Clark

drm/msm/gpu: Fix idle_work time

2021-11-21T20:56:30+00:00

This was supposed to be a relative timer, not absolute.

Fixes: 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before clamping freq")
Signed-off-by: Rob Clark 
Reviewed-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20211120200103.1051459-1-robdclark@gmail.com
Signed-off-by: Rob Clark

drm/msm/devfreq: Fix OPP refcnt leak

2021-11-21T20:46:28+00:00

Reported-by: Douglas Anderson 
Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
Signed-off-by: Rob Clark 
Reviewed-by: Douglas Anderson 
Tested-By: Steev Klimaszewski 
Reviewed-by: Akhil P Oommen 
Link: https://lore.kernel.org/r/20211105202021.181092-1-robdclark@gmail.com
Signed-off-by: Rob Clark

Merge tag 'drm-msm-next-2021-10-26' of https://gitlab.freedesktop.org/drm/msm into drm-next

2021-10-28T05:07:48+00:00

* eDP support in DP sub-driver (for newer SoCs with native eDP output)
* dpu irq handling cleanup
* CRC support for making igt happy
* Support for NO_CONNECTOR bridges
* dsi: 14nm phy support for msm8953
* mdp5: support for msm8x53, sdm450, sdm632
* various smaller fixes and cleanups

Signed-off-by: Dave Airlie 
From: Rob Clark 
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsH9EwcpqGNNRJeL99NvFFjHX3SUg+nTYu0dHG5U9+QuA@mail.gmail.com

drm/msm/devfreq: Restrict idle clamping to a618 for now

2021-10-18T21:31:57+00:00

Until we better understand the stability issues caused by frequent
frequency changes, lets limit them to a618.

Signed-off-by: Rob Clark 
Tested-by: John Stultz 
Tested-by: Caleb Connolly 
Link: https://lore.kernel.org/r/20211018153627.2787882-1-robdclark@gmail.com
Signed-off-by: Rob Clark

drm/msm/devfreq: Add 1ms delay before clamping freq

2021-10-15T23:35:40+00:00

Add a short delay before clamping to idle frequency on active->idle
transition.  It takes ~0.5ms to increase the freq again on the next
idle->active transition, so this helps avoid extra freq transitions
on workloads that bounce between CPU and GPU.

Signed-off-by: Rob Clark 
Link: https://lore.kernel.org/r/20210927230455.1066297-2-robdclark@gmail.com
Signed-off-by: Rob Clark

drm/msm: Fix devfreq NULL pointer dereference on a3xx

2021-10-12T00:30:53+00:00

There is no devfreq on a3xx at the moment since gpu_busy is not
implemented. This means that msm_devfreq_init() will return early
and the entire devfreq setup is skipped.

However, msm_devfreq_active() and msm_devfreq_idle() are still called
unconditionally later, causing a NULL pointer dereference:

  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
  Internal error: Oops: 96000004 [#1] PREEMPT SMP
  CPU: 0 PID: 133 Comm: ring0 Not tainted 5.15.0-rc1 #4
  Hardware name: Longcheer L8150 (DT)
  pc : mutex_lock_io+0x2bc/0x2f0
  lr : msm_devfreq_active+0x3c/0xe0 [msm]
  Call trace:
   mutex_lock_io+0x2bc/0x2f0
   msm_gpu_submit+0x164/0x180 [msm]
   msm_job_run+0x54/0xe0 [msm]
   drm_sched_main+0x2b0/0x4a0 [gpu_sched]
   kthread+0x154/0x160
   ret_from_fork+0x10/0x20

Fix this by adding a check in msm_devfreq_active/idle() which ensures
that devfreq was actually initialized earlier.

Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
Reported-by: Nikita Travkin 
Tested-by: Nikita Travkin 
Signed-off-by: Stephan Gerhold 
Link: https://lore.kernel.org/r/20210913164556.16284-1-stephan@gerhold.net
Signed-off-by: Rob Clark