<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/msm/msm_gpu.c, branch v5.19</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.19</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.19'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-06-18T16:13:33+00:00</updated>
<entry>
<title>drm/msm: Don't overwrite hw fence in hw_init</title>
<updated>2022-06-18T16:13:33+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-06-18T16:11:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c8af219d18502c52319df8d4e3dcfe29a3ca31ab'/>
<id>urn:sha1:c8af219d18502c52319df8d4e3dcfe29a3ca31ab</id>
<content type='text'>
Prior to the last commit, this could result in setting the GPU
written fence value back to an older value, if we had missed
updating completed_fence prior to suspend.  This was mostly
harmless as the GPU would eventually overwrite it again with
the correct value.  But we should just not do this.  Instead
just leave a sanity check that the fence looks plausible (in
case the GPU scribbled on memory).

Reported-by: Steev Klimaszewski &lt;steev@kali.org&gt;
Fixes: 95d1deb02a9c ("drm/msm/gem: Add fenced vma unpin")
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Tested-by: Steev Klimaszewski &lt;steev@kali.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/490138/
Link: https://lore.kernel.org/r/20220618161120.3451993-2-robdclark@gmail.com
</content>
</entry>
<entry>
<title>drm/msm: Drop update_fences()</title>
<updated>2022-06-18T16:13:32+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-06-18T16:11:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3c7a52217a8c1e674a9e15b71a7239d71a4d9cfd'/>
<id>urn:sha1:3c7a52217a8c1e674a9e15b71a7239d71a4d9cfd</id>
<content type='text'>
I noticed while looking at some traces, that we could miss calls to
msm_update_fence(), as the irq could have raced with retire_submits()
which could have already popped the last submit on a ring out of the
queue of in-flight submits.  But walking the list of submits in the
irq handler isn't really needed, as dma_fence_is_signaled() will dtrt.
So lets just drop it entirely.

v2: use spin_lock_irqsave/restore as we are no longer protected by the
    spin_lock_irqsave/restore() in update_fences()

Reported-by: Steev Klimaszewski &lt;steev@kali.org&gt;
Fixes: 95d1deb02a9c ("drm/msm/gem: Add fenced vma unpin")
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Tested-by: Steev Klimaszewski &lt;steev@kali.org&gt;
Patchwork: https://patchwork.freedesktop.org/patch/490136/
Link: https://lore.kernel.org/r/20220618161120.3451993-1-robdclark@gmail.com
</content>
</entry>
<entry>
<title>drm/msm: Switch ordering of runpm put vs devfreq_idle</title>
<updated>2022-06-13T22:32:32+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-06-08T16:13:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=49e477610087a02c3604061b8f3ee3a25a493987'/>
<id>urn:sha1:49e477610087a02c3604061b8f3ee3a25a493987</id>
<content type='text'>
In msm_devfreq_suspend() we cancel idle_work synchronously so that it
doesn't run after we power of the hw or in the resume path.  But this
means that we want to ensure that idle_work is not scheduled *after* we
no longer hold a runpm ref.  So switch the ordering of pm_runtime_put()
vs msm_devfreq_idle().

v2. Only move the runpm _put_autosuspend, and not the _mark_last_busy()

Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Link: https://lore.kernel.org/r/20210927152928.831245-1-robdclark@gmail.com
Reviewed-by: Akhil P Oommen &lt;quic_akhilpo@quicinc.com&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Link: https://lore.kernel.org/r/20220608161334.2140611-1-robdclark@gmail.com
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: Fix null pointer dereferences without iommu</title>
<updated>2022-05-02T17:11:44+00:00</updated>
<author>
<name>Luca Weiss</name>
<email>luca@z3ntu.xyz</email>
</author>
<published>2022-04-21T20:34:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=36a1d1bda77e1851bddfa9cf4e8ada94476dbaff'/>
<id>urn:sha1:36a1d1bda77e1851bddfa9cf4e8ada94476dbaff</id>
<content type='text'>
Check if 'aspace' is set before using it as it will stay null without
IOMMU, such as on msm8974.

Fixes: bc2112583a0b ("drm/msm/gpu: Track global faults per address-space")
Signed-off-by: Luca Weiss &lt;luca@z3ntu.xyz&gt;
Link: https://lore.kernel.org/r/20220421203455.313523-1-luca@z3ntu.xyz
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>
<entry>
<title>drm/msm: Add a way to override processes comm/cmdline</title>
<updated>2022-04-21T22:01:09+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-03-17T16:51:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d4726d7700688835f4784d3b94de6fff2cbe16c2'/>
<id>urn:sha1:d4726d7700688835f4784d3b94de6fff2cbe16c2</id>
<content type='text'>
In the cause of using the GPU via virtgpu, the host side process is
really a sort of proxy, and not terribly interesting from the PoV of
crash/fault logging.  Add a way to override these per process so that
we can see the guest process's name.

v2: Handle kmalloc failure, add comment to explain kstrdup returns
    NULL if passed NULL [Dan Carpenter]

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Link: https://lore.kernel.org/r/20220317165144.222101-4-robdclark@gmail.com
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: Split out helper to get comm/cmdline</title>
<updated>2022-04-21T22:01:08+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-03-17T16:51:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39ba0c0d6cd13e9ae5fe0a75313efdbb3449d87a'/>
<id>urn:sha1:39ba0c0d6cd13e9ae5fe0a75313efdbb3449d87a</id>
<content type='text'>
Deduplicate this from fault_worker and recover_worker.

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Link: https://lore.kernel.org/r/20220317165144.222101-3-robdclark@gmail.com
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: Add SYSPROF param (v2)</title>
<updated>2022-03-04T19:59:31+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-03-04T00:52:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=90f45c42d7d7b0ec0fd797485c07fc421c474e12'/>
<id>urn:sha1:90f45c42d7d7b0ec0fd797485c07fc421c474e12</id>
<content type='text'>
Add a SYSPROF param for system profiling tools like Mesa's pps-producer
(perfetto) to control behavior related to system-wide performance
counter collection.  In particular, for profiling, one wants to ensure
that GPU context switches do not effect perfcounter state, and might
want to suppress suspend (which would cause counters to lose state).

v2: Swap the order in msm_file_private_set_sysprof() [sboyd] and
    initialize the sysprof_active refcount to one (because the under/
    overflow checking in refcount_t doesn't expect a 0-&gt;1 transition)
    meaning that values greater than 1 means sysprof is active.

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Link: https://lore.kernel.org/r/20220304005317.776110-4-robdclark@gmail.com
</content>
</entry>
<entry>
<title>drm/msm: Use generic name for gpu resources</title>
<updated>2022-02-25T21:29:57+00:00</updated>
<author>
<name>Akhil P Oommen</name>
<email>quic_akhilpo@quicinc.com</email>
</author>
<published>2022-02-25T19:21:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0737ab95a0f4e0e133efe7cfdb0449bc35b3b893'/>
<id>urn:sha1:0737ab95a0f4e0e133efe7cfdb0449bc35b3b893</id>
<content type='text'>
Use generic name for resources like irq and kthread instead of hardware
specific name to make it easier to grep.

Signed-off-by: Akhil P Oommen &lt;quic_akhilpo@quicinc.com&gt;
Link: https://lore.kernel.org/r/20220226005021.v2.1.Id3d2e7391192c86d0783aeb307d3f9fb61f9efee@changeid
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/msm/gpu: Track global faults per address-space</title>
<updated>2022-02-20T17:44:52+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-02-01T16:16:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bc2112583a0b473f5c4ba87c00da84abd5d0b3fd'/>
<id>urn:sha1:bc2112583a0b473f5c4ba87c00da84abd5d0b3fd</id>
<content type='text'>
Other processes don't need to know about faults that they are isolated
from by virtue of address space isolation.  They are only interested in
whether some of their state might have been corrupted.

But to be safe, also track unattributed faults.  This case should really
never happen unless there is a kernel bug (and that would never happen,
right?)

v2: Instead of adding a new param, just change the behavior of the
    existing param to match what userspace actually wants [anholt]

Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5934
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Link: https://lore.kernel.org/r/20220201161618.778455-3-robdclark@gmail.com
Reviewed-by: Emma Anholt &lt;emma@anholt.net&gt;
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
</content>
</entry>
</feed>
