<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/msm/msm_atomic.c, branch v6.19.11</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-03-05T02:33:33+00:00</updated>
<entry>
<title>drm/msm/dpu: don't set crtc_state-&gt;mode_changed from atomic_check()</title>
<updated>2025-03-05T02:33:33+00:00</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@linaro.org</email>
</author>
<published>2025-01-23T12:43:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2dde2aadaed113feb724c19063ac61e2f6ba61a4'/>
<id>urn:sha1:2dde2aadaed113feb724c19063ac61e2f6ba61a4</id>
<content type='text'>
The MSM driver uses drm_atomic_helper_check() which mandates that none
of the atomic_check() callbacks toggles crtc_state-&gt;mode_changed.
Perform corresponding check before calling the drm_atomic_helper_check()
function.

Fixes: 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output")
Reported-by: Simona Vetter &lt;simona.vetter@ffwll.ch&gt;
Closes: https://lore.kernel.org/dri-devel/ZtW_S0j5AEr4g0QW@phenom.ffwll.local/
Reviewed-by: Abhinav Kumar &lt;quic_abhinavk@quicinc.com&gt;
[DB: dropped the WARN_ON]
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/633400/
Link: https://lore.kernel.org/r/20250123-drm-dirty-modeset-v2-4-bbfd3a6cd1a4@linaro.org
</content>
</entry>
<entry>
<title>drm/msm/dpu: rate limit snapshot capture for mmu faults</title>
<updated>2025-02-26T10:15:49+00:00</updated>
<author>
<name>Abhinav Kumar</name>
<email>quic_abhinavk@quicinc.com</email>
</author>
<published>2025-02-19T19:49:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=89839e69f6154feecd79bd01171375225b0296e9'/>
<id>urn:sha1:89839e69f6154feecd79bd01171375225b0296e9</id>
<content type='text'>
There is no recovery mechanism in place yet to recover from mmu
faults for DPU. We can only prevent the faults by making sure there
is no misconfiguration.

Rate-limit the snapshot capture for mmu faults to once per
msm_atomic_commit_tail() as that should be sufficient to capture
the snapshot for debugging otherwise there will be a lot of DPU
snapshots getting captured for the same fault which is redundant
and also might affect capturing even one snapshot accurately.

Signed-off-by: Abhinav Kumar &lt;quic_abhinavk@quicinc.com&gt;
Signed-off-by: Jessica Zhang &lt;quic_jesszhan@quicinc.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/638362/
Link: https://lore.kernel.org/r/20250219-abhinavk-smmu-fault-handler-v3-5-aa3f0bf4434a@quicinc.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
</content>
</entry>
<entry>
<title>treewide: Introduce kthread_run_worker[_on_cpu]()</title>
<updated>2025-01-08T17:15:03+00:00</updated>
<author>
<name>Frederic Weisbecker</name>
<email>frederic@kernel.org</email>
</author>
<published>2024-09-26T22:49:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b04e317b522630b46f78ee62ecbdc5734e8d43de'/>
<id>urn:sha1:b04e317b522630b46f78ee62ecbdc5734e8d43de</id>
<content type='text'>
kthread_create() creates a kthread without running it yet. kthread_run()
creates a kthread and runs it.

On the other hand, kthread_create_worker() creates a kthread worker and
runs it.

This difference in behaviours is confusing. Also there is no way to
create a kthread worker and affine it using kthread_bind_mask() or
kthread_affine_preferred() before starting it.

Consolidate the behaviours and introduce kthread_run_worker[_on_cpu]()
that behaves just like kthread_run(). kthread_create_worker[_on_cpu]()
will now only create a kthread worker without starting it.

Signed-off-by: Frederic Weisbecker &lt;frederic@kernel.org&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
</content>
</entry>
<entry>
<title>drm/msm/atomic: Don't try async if crtc not active</title>
<updated>2023-04-24T20:18:36+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2023-04-18T16:41:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ce902336d9b3472d6104316e876e1a8752531916'/>
<id>urn:sha1:ce902336d9b3472d6104316e876e1a8752531916</id>
<content type='text'>
For a similar reason as commit f2c7ca890182 ("drm/atomic-helper: Don't
set deadline for modesets"), we need the crtc to be already active in
order to compute a target vblank time for an async commit.  Otherwise
we get this splat reminding us that we are doing it wrong:

   ------------[ cut here ]------------
   msm_dpu ae01000.mdp: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev))
   WARNING: CPU: 7 PID: 1923 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x148/0x370
   Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun vhost_vsock vhost vhost_iotlb vmw_vsock_virtio_transport_common vsock uinput rfcomm algif_hash algif_skcipher af_alg veth venus_dec venus_enc cros_ec_typec typec qcom_spmi_temp_alarm qcom_spmi_adc_tm5 qcom_spmi_adc5 xt_cgroup qcom_vadc_common qcom_stats hci_uart btqca xt_MASQUERADE venus_core 8021q coresight_tmc coresight_funnel coresight_etm4x coresight_replicator snd_soc_lpass_sc7180 coresight snd_soc_sc7180 ip6table_nat fuse ath10k_snoc ath10k_core ath mac80211 iio_trig_sysfs bluetooth cfg80211 cros_ec_sensors cros_ec_sensors_core ecdh_generic industrialio_triggered_buffer ecc kfifo_buf cros_ec_sensorhub r8153_ecm cdc_ether usbnet r8152 mii lzo_rle lzo_compress zram hid_vivaldi hid_google_hammer hid_vivaldi_common joydev
   CPU: 7 PID: 1923 Comm: DrmThread Not tainted 5.15.107-18853-g3be267609a0b-dirty #16 a1ffc1a66e79c21c3536d8c9a42e819236e39714
   Hardware name: Google Wormdingler rev1+ BOE panel board (DT)
   pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
   pc : drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x148/0x370
   lr : drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x144/0x370
   sp : ffffffc012e2b800
   x29: ffffffc012e2b840 x28: ffffff8083676094 x27: ffffffc012e2bb28
   x26: ffffff8084539800 x25: 0000000000000000 x24: ffffff8083676000
   x23: ffffffd3c8cdc5a0 x22: ffffff80845b9d00 x21: ffffffc012e2b8b4
   x20: ffffffc012e2b910 x19: 0000000000000001 x18: 0000000000000000
   x17: 0000000000000000 x16: 0000000000000010 x15: ffffffd3c8451a88
   x14: 0000000000000003 x13: 0000000000000004 x12: 0000000000000001
   x11: c0000000ffffdfff x10: ffffffd3c973ef58 x9 : 8ea3526b3cc95900
   x8 : 8ea3526b3cc95900 x7 : 0000000000000000 x6 : 000000000000003a
   x5 : ffffffd3c99676cd x4 : 0000000000000000 x3 : ffffffc012e2b4b8
   x2 : ffffffc012e2b4c0 x1 : 00000000ffffdfff x0 : 0000000000000000
   Call trace:
    drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x148/0x370
    drm_crtc_vblank_helper_get_vblank_timestamp+0x20/0x30
    drm_crtc_get_last_vbltimestamp+0x68/0xb0
    drm_crtc_next_vblank_start+0x5c/0xa8
    msm_atomic_commit_tail+0x264/0x664
    commit_tail+0xac/0x160
    drm_atomic_helper_commit+0x160/0x168
    drm_atomic_commit+0xfc/0x128
    drm_atomic_helper_disable_plane+0x8c/0x110
    __setplane_atomic+0x10c/0x138
    drm_mode_cursor_common+0x3a8/0x410
    drm_mode_cursor_ioctl+0x48/0x70
    drm_ioctl_kernel+0xe0/0x158
    drm_ioctl+0x25c/0x4d8
    __arm64_sys_ioctl+0x98/0xd0
    invoke_syscall+0x4c/0x100
    el0_svc_common+0x98/0x104
    do_el0_svc+0x30/0x90
    el0_svc+0x20/0x50
    el0t_64_sync_handler+0x78/0x108
    el0t_64_sync+0x1a4/0x1a8
   ---[ end trace a0f587e1ab9589e8 ]---

Fixes: 52ff0d3073d2 ("drm/msm/atomic: Switch to vblank_start helper")
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Abhinav Kumar &lt;quic_abhinavk@quicinc.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/532727/
Link: https://lore.kernel.org/r/20230418164158.549873-1-robdclark@gmail.com
</content>
</entry>
<entry>
<title>drm/msm/dpu: manage DPU resources if CTM is requested</title>
<updated>2023-04-06T17:29:43+00:00</updated>
<author>
<name>Kalyan Thota</name>
<email>quic_kalyant@quicinc.com</email>
</author>
<published>2023-02-13T11:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=82836692d5d7424660f8fb5f52432cfe2d9e633c'/>
<id>urn:sha1:82836692d5d7424660f8fb5f52432cfe2d9e633c</id>
<content type='text'>
Allow modeset to be triggered during CTM enable/disable.
In the modeset callbacks, DPU resources required for the
CTM feature are managed appropriately.

Signed-off-by: Kalyan Thota &lt;quic_kalyant@quicinc.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/522448/
Link: https://lore.kernel.org/r/1676286704-818-5-git-send-email-quic_kalyant@quicinc.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: Check for NULL before calling prepare_commit()</title>
<updated>2023-04-06T17:29:24+00:00</updated>
<author>
<name>Jessica Zhang</name>
<email>quic_jesszhan@quicinc.com</email>
</author>
<published>2023-02-21T18:42:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=078f6ec8657db604a1620da6698fb236e9b96bec'/>
<id>urn:sha1:078f6ec8657db604a1620da6698fb236e9b96bec</id>
<content type='text'>
Add a NULL check before calling prepare_commit() in
msm_atomic_commit_tail()

Signed-off-by: Jessica Zhang &lt;quic_jesszhan@quicinc.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Marijn Suijten &lt;marijn.suijten@somainline.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/523604/
Link: https://lore.kernel.org/r/20230221184256.1436-3-quic_jesszhan@quicinc.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
</content>
</entry>
<entry>
<title>drm/msm/atomic: Switch to vblank_start helper</title>
<updated>2023-03-28T22:46:15+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2023-03-08T15:53:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=52ff0d3073d291f53f70c87656ecce4eb6d527ff'/>
<id>urn:sha1:52ff0d3073d291f53f70c87656ecce4eb6d527ff</id>
<content type='text'>
Drop our custom thing and switch to drm_crtc_next_vblank_start() for
calculating the time of the start of the next vblank period.

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/525819/
Link: https://lore.kernel.org/r/20230308155322.344664-15-robdclark@gmail.com
</content>
</entry>
<entry>
<title>drm/msm: Avoid dirtyfb stalls on video mode displays (v2)</title>
<updated>2022-02-25T15:59:58+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-02-23T19:11:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9e4dde28e9cd34ee13a6b7247f0857fb49fd3f19'/>
<id>urn:sha1:9e4dde28e9cd34ee13a6b7247f0857fb49fd3f19</id>
<content type='text'>
Someone on IRC once asked an innocent enough sounding question:  Why
with xf86-video-modesetting is es2gears limited at 120fps.

So I broke out the perfetto tracing mesa MR and took a look.  It turns
out the problem was drm_atomic_helper_dirtyfb(), which would end up
waiting for vblank.. es2gears would rapidly push two frames to Xorg,
which would blit them to screen and in idle hook (I assume) call the
DIRTYFB ioctl.  Which in turn would do an atomic update to flush the
dirty rects, which would stall until the next vblank.  And then the
whole process would repeat.

But this is a bit silly, we only need dirtyfb for command mode DSI
panels.  So track in plane state whether dirtyfb is required, and
track in the fb how many attached planes require dirtyfb so that we
can skip it when not required.  (Note, mdp4 does not actually have
cmd mode support.)

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Link: https://lore.kernel.org/r/20220223191118.881321-1-robdclark@gmail.com
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: Add hrtimer + kthread_work helper</title>
<updated>2021-10-15T23:35:39+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2021-09-27T23:04:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ddb6e37a50e02736f3c9f1a9f8f873989b22af54'/>
<id>urn:sha1:ddb6e37a50e02736f3c9f1a9f8f873989b22af54</id>
<content type='text'>
Before open-coding this a 2nd time, add a helper.

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Link: https://lore.kernel.org/r/20210927230455.1066297-1-robdclark@gmail.com
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
<entry>
<title>Merge drm/drm-fixes into drm-next</title>
<updated>2021-04-13T21:15:09+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2021-04-13T21:06:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=213cc929cbfd7962164420b300f9a6c60aaff189'/>
<id>urn:sha1:213cc929cbfd7962164420b300f9a6c60aaff189</id>
<content type='text'>
msm-next pull request has a baseline with stuff from -fixes, roll
forward first.

Some simple conflicts in amdgpu, ttm and one in i915 where git gets
confused and tries to add the same function twice.

Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</content>
</entry>
</feed>
