<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/msm/msm_gpu.h, branch v6.1</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-09-30T16:01:41+00:00</updated>
<entry>
<title>drm/msm/gpu: Fix crash during system suspend after unbind</title>
<updated>2022-09-30T16:01:41+00:00</updated>
<author>
<name>Akhil P Oommen</name>
<email>quic_akhilpo@quicinc.com</email>
</author>
<published>2022-09-28T07:19:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=76efc2453d0e8e5d6692ef69981b183ad674edea'/>
<id>urn:sha1:76efc2453d0e8e5d6692ef69981b183ad674edea</id>
<content type='text'>
In adreno_unbind, we should clean up gpu device's drvdata to avoid
accessing a stale pointer during system suspend. Also, check for NULL
ptr in both system suspend/resume callbacks.

Signed-off-by: Akhil P Oommen &lt;quic_akhilpo@quicinc.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/505075/
Link: https://lore.kernel.org/r/20220928124830.2.I5ee0ac073ccdeb81961e5ec0cce5f741a7207a71@changeid
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/msm/a6xx: Ensure CX collapse during gpu recovery</title>
<updated>2022-08-28T16:29:27+00:00</updated>
<author>
<name>Akhil P Oommen</name>
<email>quic_akhilpo@quicinc.com</email>
</author>
<published>2022-08-18T20:22:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1f6cca404918d2d3bc476afb31b371a406009c06'/>
<id>urn:sha1:1f6cca404918d2d3bc476afb31b371a406009c06</id>
<content type='text'>
Because there could be transient votes from other drivers/tz/hyp which
may keep the cx gdsc enabled, we should poll until cx gdsc collapses.
We can use the reset framework to poll for cx gdsc collapse from gpucc
clk driver.

This feature requires support from the platform's gpucc driver.

Signed-off-by: Akhil P Oommen &lt;quic_akhilpo@quicinc.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Patchwork: https://patchwork.freedesktop.org/patch/498397/
Link: https://lore.kernel.org/r/20220819015030.v5.5.I176567525af2b9439a7e485d0ca130528666a55c@changeid
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/msm/gem: Convert to using drm_gem_lru</title>
<updated>2022-08-27T16:32:45+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-08-02T15:51:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b352ba54a82072614f44c5ea352b5ea6e7f7b4c0'/>
<id>urn:sha1:b352ba54a82072614f44c5ea352b5ea6e7f7b4c0</id>
<content type='text'>
This converts over to use the shared GEM LRU/shrinker helpers.  Note
that it means we are no longer tracking purgeable or willneed buffers
that are active separately.  But the most recently pinned buffers should
be at the tail of the various LRUs, and the shrinker is already prepared
to encounter objects which are still active.

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/496131/
Link: https://lore.kernel.org/r/20220802155152.1727594-11-robdclark@gmail.com
</content>
</entry>
<entry>
<title>drm/msm: Split out idr_lock</title>
<updated>2022-08-27T16:32:44+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-08-02T15:51:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=05ba44b3704e2115251c340fc72db609a0b97f3b'/>
<id>urn:sha1:05ba44b3704e2115251c340fc72db609a0b97f3b</id>
<content type='text'>
Otherwise if we hit reclaim pinning objects in the submit path, we'll be
blocking retire_worker trying to free a submit.

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/496116/
Link: https://lore.kernel.org/r/20220802155152.1727594-4-robdclark@gmail.com
</content>
</entry>
<entry>
<title>drm/msm/gpu: Add GEM debug label to devcore</title>
<updated>2022-07-07T01:54:41+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-06-29T21:19:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=18514c3848cf86f3e2843c9cfc218c8471a1984e'/>
<id>urn:sha1:18514c3848cf86f3e2843c9cfc218c8471a1984e</id>
<content type='text'>
When trying to understand an iova fault devcore, once you figure out
which buffer we accessed beyond the end of, it is useful to see the
buffer's debug label.

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/491910/
Link: https://lore.kernel.org/r/20220629211919.563585-3-robdclark@gmail.com
</content>
</entry>
<entry>
<title>drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy</title>
<updated>2022-07-06T15:38:06+00:00</updated>
<author>
<name>Douglas Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2022-06-10T19:47:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6694482a70e9536efbf2ac233cbf0c302d6e2dae'/>
<id>urn:sha1:6694482a70e9536efbf2ac233cbf0c302d6e2dae</id>
<content type='text'>
From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device". Unfortunately the current a6xx_gpu_busy() grabs a
reference to the GMU's "struct device".

The fact that we were grabbing the wrong reference was easily seen to
cause crashes that happen if we change the GPU's pm_runtime usage to
not use autosuspend. It's also believed to cause some long tail GPU
crashes even with autosuspend.

We could look at changing it so that we do pm_runtime_get_if_in_use()
on the GPU's "struct device", but then we run into a different
problem. pm_runtime_get_if_in_use() will return 0 for the GPU's
"struct device" the whole time when we're in the "autosuspend
delay". That is, when we drop the last reference to the GPU but we're
waiting a period before actually suspending then we'll think the GPU
is off. One reason that's bad is that if the GPU didn't actually turn
off then the cycle counter doesn't lose state and that throws off all
of our calculations.

Let's change the code to keep track of the suspend state of
devfreq. msm_devfreq_suspend() is always called before we actually
suspend the GPU and msm_devfreq_resume() after we resume it. This
means we can use the suspended state to know if we're powered or not.

NOTE: one might wonder when exactly our status function is called when
devfreq is supposed to be disabled. The stack crawl I captured was:
  msm_devfreq_get_dev_status
  devfreq_simple_ondemand_func
  devfreq_update_target
  qos_notifier_call
  qos_max_notifier_call
  blocking_notifier_call_chain
  pm_qos_update_target
  freq_qos_apply
  apply_constraint
  __dev_pm_qos_update_request
  dev_pm_qos_update_request
  msm_devfreq_idle_work

Fixes: eadf79286a4b ("drm/msm: Check for powered down HW in the devfreq callbacks")
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Reviewed-by: Rob Clark &lt;robdclark@gmail.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/489124/
Link: https://lore.kernel.org/r/20220610124639.v4.1.Ie846c5352bc307ee4248d7cab998ab3016b85d06@changeid
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: Expose client engine utilization via fdinfo</title>
<updated>2022-07-05T03:01:11+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-06-09T17:42:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cfebe3fd599634540960ec37e3a6c2eb8b5bed2f'/>
<id>urn:sha1:cfebe3fd599634540960ec37e3a6c2eb8b5bed2f</id>
<content type='text'>
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for msm.

Example output:

	# cat /proc/`pgrep glmark2`/fdinfo/6
	pos:	0
	flags:	02400002
	mnt_id:	21
	ino:	162
	drm-driver:	msm
	drm-client-id:	7
	drm-engine-gpu:	1734371319 ns
	drm-cycles-gpu:	1153645024
	drm-maxfreq-gpu:	800000000 Hz

See also: https://patchwork.freedesktop.org/patch/468505/

v2: Add dev-maxfreq-$engine and update drm-usage-stats.rst
v3: spelling and compiler warning

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Acked-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/488906/
Link: https://lore.kernel.org/r/20220609174213.2265938-2-robdclark@gmail.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: return the average load over the polling period</title>
<updated>2022-04-21T22:05:23+00:00</updated>
<author>
<name>Chia-I Wu</name>
<email>olvaffe@gmail.com</email>
</author>
<published>2022-04-16T00:33:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=78f815c1cf8fc5f05dc5cec29eb1895cb53470e9'/>
<id>urn:sha1:78f815c1cf8fc5f05dc5cec29eb1895cb53470e9</id>
<content type='text'>
simple_ondemand interacts poorly with clamp_to_idle.  It only looks at
the load since the last get_dev_status call, while it should really look
at the load over polling_ms.  When clamp_to_idle true, it almost always
picks the lowest frequency on active because the gpu is idle between
msm_devfreq_idle/msm_devfreq_active.

This logic could potentially be moved into devfreq core.

Fixes: 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS constraints")
Signed-off-by: Chia-I Wu &lt;olvaffe@gmail.com&gt;
Cc: Rob Clark &lt;robdclark@chromium.org&gt;
Link: https://lore.kernel.org/r/20220416003314.59211-3-olvaffe@gmail.com
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: simplify gpu_busy callback</title>
<updated>2022-04-21T22:05:23+00:00</updated>
<author>
<name>Chia-I Wu</name>
<email>olvaffe@gmail.com</email>
</author>
<published>2022-04-16T00:33:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=15c411980bacddf294452fd1cf7308b14f3f8c63'/>
<id>urn:sha1:15c411980bacddf294452fd1cf7308b14f3f8c63</id>
<content type='text'>
Move tracking and busy time calculation to msm_devfreq_get_dev_status.

Signed-off-by: Chia-I Wu &lt;olvaffe@gmail.com&gt;
Cc: Rob Clark &lt;robdclark@chromium.org&gt;
Link: https://lore.kernel.org/r/20220416003314.59211-2-olvaffe@gmail.com
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/msm/gpu: Drop duplicate fence counter</title>
<updated>2022-04-21T22:03:11+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-04-11T21:58:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f9d5355fa5b6b25c3b6e1727bc36d11bb8c8ee24'/>
<id>urn:sha1:f9d5355fa5b6b25c3b6e1727bc36d11bb8c8ee24</id>
<content type='text'>
The ring seqno counter duplicates the fence-context last_fence counter.
They end up getting incremented in lock-step, on the same scheduler
thread, but the split just makes things less obvious.

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Link: https://lore.kernel.org/r/20220411215849.297838-3-robdclark@gmail.com
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
</feed>
