On Wed, Nov 15, 2023 at 11:33 AM Dmitry Baryshkov
wrote:
>
> On Wed, 15 Nov 2023 at 20:46, Dipam Turkar wrote:
> >
> > They are not outdated, my bad. I went through the locks' code and saw that
> > they have been updated. But they are probably not necessary here as most of
> > the drivers do no
From: Rob Clark
Replace the ww_mutex locking dance with the drm_exec helper.
v2: Error path fixes, move drm_exec_fini so we only call it once (and
only if we have drm_exec_init()
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/msm_gem.h
From: Rob Clark
In cases where the # is known ahead of time, it is silly to do the table
resize dance.
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers
From: Rob Clark
Now that it only handles unlock duty, drop the superfluous arg and
rename it.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers
From: Rob Clark
This was a small optimization for pre-soft-pin userspace. But mesa
switched to soft-pin nearly 5yrs ago. So lets drop the optimization
and simplify the code.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h| 2 --
drivers/gpu/drm/msm/msm_gem_submit.c | 44
From: Rob Clark
Untangle unpinning from unlock/unref loop. The unpin only happens in
error paths so it is easier to decouple from the normal unlock path.
Since we never have an intermediate state where a subset of buffers
are pinned (ie. we never bail out of the pin or unpin loops) we can
From: Rob Clark
We shouldn't be running the job in error cases. This also avoids having
to think too hard about where the objs get unpinned (and if necessary,
the resv takes over tracking that the obj is busy).. ie. error cases it
always happens synchronously, and normal cases it happens
From: Rob Clark
The only point it is called is before pinning objects, so the "unpin"
part of the name is fiction. Just remove it and call submit_cleanup_bo()
directly.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_gem_submit.c | 10 ++--
From: Rob Clark
Simplify the exec path (removing a legacy optimization) and convert to
drm_exec. One drm_exec patch to allow passing in the expected # of GEM
objects to avoid re-allocation.
I'd be a bit happier if I could avoid the extra objects table allocation
in drm_exec in the first
From: Rob Clark
If we somehow raced with submit retiring, either while waiting for
worker to have a chance to run or acquiring the gpu lock, then the
recover worker should just bail.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 41 +++
1 file
From: Rob Clark
Until various PM devfreq/QoS and interconnect patches land, we could
potentially trigger reclaim from gpu scheduler thread, and under enough
memory pressure that could trigger a sort of deadlock. Eventually the
wait will timeout and we'll move on to consider other GEM ob
From: Rob Clark
The dpu devcore's are already associated with the dpu device. So we
should associate the gpu devcore's with the gpu device, for easier
classification.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletion
From: Rob Clark
The EXT_external_objects extension is a bit awkward as it doesn't pass
explicit modifiers, leaving the importer to guess with incomplete
information. In the case of vk (turnip) exporting and gl (freedreno)
importing, the "OPTIMAL_TILING_EXT" layout depends on Vk
From: Rob Clark
Correct the minor version exposed and error return value for
MSM_INFO_GET_NAME.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b
From: Rob Clark
Add metadata mechanism to provide a back-channel to communicate image
layout information between vk and gl, because EXT_external_objects
doesn't support explicit modifiers and "OPTIMAL_TILING_EXT" is not
enough information for the importer to deduce the layout
On Tue, Oct 31, 2023 at 5:35 AM Johan Hovold wrote:
>
> On Mon, Oct 30, 2023 at 04:23:20PM -0700, Bjorn Andersson wrote:
> > During USB transfers on the SC8280XP __arm_smmu_tlb_sync() is seen to
> > typically take 1-2ms to complete. As expected this results in poor
> > performance, something that
oug) reduces the
> > TLB sync time to below 10us, which means significant less time spent
> > with interrupts disabled and a significant boost in throughput.
> >
> > Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
> > Cc: sta...@vger.kernel.org
> >
On Mon, Oct 30, 2023 at 9:01 AM Christian König
wrote:
>
> Am 30.10.23 um 14:38 schrieb Rob Clark:
> > On Mon, Oct 30, 2023 at 1:05 AM Christian König
> > wrote:
> >> Am 27.10.23 um 18:58 schrieb Rob Clark:
> >>> From: Rob Clark
> >>>
>
From: Rob Clark
Just something I noticed in passing.
Signed-off-by: Rob Clark
---
include/drm/drm_gpuva_mgr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_gpuva_mgr.h b/include/drm/drm_gpuva_mgr.h
index ed8d50200cc3..26a2c0880bac 100644
--- a/include/drm
On Mon, Oct 30, 2023 at 1:05 AM Christian König
wrote:
>
> Am 27.10.23 um 18:58 schrieb Rob Clark:
> > From: Rob Clark
> >
> > In cases where the # is known ahead of time, it is silly to do the table
> > resize dance.
>
> Ah, yes that was my initial implem
From: Rob Clark
The EXT_external_objects extension is a bit awkward as it doesn't pass
explicit modifiers, leaving the importer to guess with incomplete
information. In the case of vk (turnip) exporting and gl (freedreno)
importing, the "OPTIMAL_TILING_EXT" layout depends on Vk
From: Rob Clark
Correct the minor version exposed and error return value for
MSM_INFO_GET_NAME.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
From: Rob Clark
Add metadata mechanism to provide a back-channel to communicate image
layout information between vk and gl, because EXT_external_objects
doesn't support explicit modifiers and "OPTIMAL_TILING_EXT" is not
enough information for the importer to deduce the layout
On Fri, Oct 27, 2023 at 6:16 PM Dmitry Baryshkov
wrote:
>
> On Fri, 27 Oct 2023 at 22:45, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > The EXT_external_objects extension is a bit awkward as it doesn't pass
> > explicit modifiers, leaving the importer
From: Rob Clark
The EXT_external_objects extension is a bit awkward as it doesn't pass
explicit modifiers, leaving the importer to guess with incomplete
information. In the case of vk (turnip) exporting and gl (freedreno)
importing, the "OPTIMAL_TILING_EXT" layout depends on Vk
From: Rob Clark
In cases where the # is known ahead of time, it is silly to do the table
resize dance.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++--
drivers
From: Rob Clark
Replace the ww_mutex locking dance with the drm_exec helper.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/msm_gem.h| 5 +-
drivers/gpu/drm/msm/msm_gem_submit.c | 117 +--
3 files changed, 24
From: Rob Clark
Now that it only handles unlock duty, drop the superfluous arg and
rename it.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers
From: Rob Clark
Untangle unpinning from unlock/unref loop. The unpin only happens in
error paths so it is easier to decouple from the normal unlock path.
Since we never have an intermediate state where a subset of buffers
are pinned (ie. we never bail out of the pin or unpin loops) we can
From: Rob Clark
We shouldn't be running the job in error cases. This also avoids having
to think too hard about where the objs get unpinned (and if necessary,
the resv takes over tracking that the obj is busy).. ie. error cases it
always happens synchronously, and normal cases it happens
From: Rob Clark
The only point it is called is before pinning objects, so the "unpin"
part of the name is fiction. Just remove call submit_cleanup_bo()
directly.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 10 ++
1 file changed, 2 insertions(+), 8
From: Rob Clark
This was a small optimization for pre-soft-pin userspace. But mesa
switched to soft-pin nearly 5yrs ago. So lets drop the optimization
and simplify the code.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h| 2 --
drivers/gpu/drm/msm/msm_gem_submit.c | 44
From: Rob Clark
Simplify the exec path (removing a legacy optimization) and convert to
drm_exec. One drm_exec patch to allow passing in the expected # of GEM
objects to avoid re-allocation.
I'd be a bit happier if I could avoid the extra objects table allocation
in drm_exec in the first
From: Rob Clark
For allocations with userspace controlled size, we should not warn on
allocation failure. Fixes KASAN splat:
WARNING: CPU: 6 PID: 29557 at mm/page_alloc.c:5398
__alloc_pages+0x160c/0x2204
Modules linked in: bridge stp llc hci_vhci tun veth xt_cgroup uinput
xt_MASQUERADE
From: Rob Clark
Error messages resulting from incorrect usage of the kernel uabi should
not spam dmesg by default. But it is useful to enable them to debug
userspace. So demote to DRM_UT_DRIVER.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c| 6 ++---
drivers/gpu/drm
On Mon, Oct 23, 2023 at 3:30 PM Dmitry Baryshkov
wrote:
>
> On Tue, 24 Oct 2023 at 01:12, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Seems like we need to pick INPUT_SEL=1 when CTM is enabled. But not
> > otherwise.
> >
> > Suggested-by
From: Rob Clark
Seems like we need to pick INPUT_SEL=1 when CTM is enabled. But not
otherwise.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1
On Mon, Oct 23, 2023 at 12:56 PM Konrad Dybcio wrote:
>
>
>
> On 10/23/23 21:42, Rob Clark wrote:
> > On Mon, Oct 23, 2023 at 7:29 AM Konrad Dybcio
> > wrote:
> >>
> >> New GPUs still use the lower 2 bytes of the chip id (in whatever form
> >&
On Mon, Oct 23, 2023 at 7:29 AM Konrad Dybcio wrote:
>
> New GPUs still use the lower 2 bytes of the chip id (in whatever form
> it comes) to signify silicon revision. Drop the warning that makes it
> sound as if that was unintended.
>
> Fixes: 90b593ce1c9e ("drm/msm/adreno: Switch to chip-id for
Hi Dave,
(resend as I missed dri-devel@ the first time)
This is the pull for v6.7, see below for description. There are some
conflicts with drm-next and mm trees. The resolution in linux-next
looks correct. Also, just in case, I've pushed the drm-next merge
resolution to msm-next-merge-resolut
On Mon, Oct 16, 2023 at 1:12 PM Akhil P Oommen wrote:
>
> On Tue, Sep 26, 2023 at 08:24:37PM +0200, Konrad Dybcio wrote:
> >
> > Some (many?) devices with A635 expect a ZAP shader to be loaded.
> >
> > Set the file name to allow for that.
> >
> > Signed-off-by: Konrad Dybcio
> > ---
> > drivers/
On Fri, Oct 13, 2023 at 9:28 AM Daniel Stone wrote:
>
> On Fri, 6 Oct 2023 at 18:32, Rob Clark wrote:
> > ssh logging is the default for mesa, as it is generally more reliable.
> > But if there are kernel issues, especially at boot, UART logging is
> > infinitely more us
Hey Dave,
lmk how you want me to handle this to make it easier for you when I
send my pull request for 6.7.. I can merge drm-next to take care of
*that* conflict (either before I send my PR or push it somewhere where
you can see the resolution) but not sure about the mm conflict since
pulling that
sm_platform_driver
> drm/msm: rename msm_drv_shutdown() to msm_kms_shutdown()
> drm/msm: switch to drmm_mode_config_init()
> drm/msm: only register 'kms' debug file if KMS is used
> drm/msm: make fb debugfs file available only in KMS case
> drm/msm: carve out
o pass msm_kms pointer via msm_drv_probe()
>
> Dmitry Baryshkov (4):
> drm/msm: allow passing struct msm_kms to msm_drv_probe()
> drm/msm/dpu: move resource allocation to the _probe function
> drm/msm/mdp4: move resource allocation to the _probe function
> drm/msm/mdp5: move resour
On Sun, Oct 8, 2023 at 4:21 PM Helen Koike wrote:
>
>
>
> On 08/10/2023 16:59, Dmitry Baryshkov wrote:
> > On Sun, 8 Oct 2023 at 20:56, Rob Clark wrote:
> >>
> >> From: Rob Clark
> >>
> >> i-g-t expects the CRC to reflect any applied CTM. B
From: Rob Clark
i-g-t expects the CRC to reflect any applied CTM. But the layer mixer
source is upstream of the DSPP, so it is before the CTM is applied.
Switch the default source to 'encoder' instead so that the CRC is
captured downstream of the DSPP.
Signed-off-by: Rob Clark
--
Hi Dave,
Late fixes for v6.6, description below.
The following changes since commit ce9ecca0238b140b88f43859b211c9fdfd8e5b70:
Linux 6.6-rc2 (2023-09-17 14:40:24 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-fixes-2023-10-07
for you
From: Rob Clark
ssh logging is the default for mesa, as it is generally more reliable.
But if there are kernel issues, especially at boot, UART logging is
infinitely more useful.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/ci/gitlab-ci.yml | 6 ++
1 file changed, 6 insertions(+)
diff
output and into debugfs/dri/N/state file.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_atomic.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>
eable sizes for their BOs.
>
> Signed-off-by: Adrián Larumbe
> Reviewed-by: Boris Brezillon
> Reviewed-by: Steven Price
> Reviewed-by: AngeloGioacchino Del Regno
>
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_file.c | 8 +---
> include/drm/drm_gem.h
From: Rob Clark
Dependency for CONFIG_DRM_PANEL_EDP. Missing this was causing the drm
driver to not probe on devices that use panel-edp.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/ci/arm.config | 1 +
drivers/gpu/drm/ci/arm64.config | 1 +
2 files changed, 2 insertions(+)
diff --git a
On Wed, Sep 20, 2023 at 11:53 AM Helen Koike wrote:
>
> Hi Rob,
>
> Thanks for the patch.
>
> On 20/09/2023 15:10, Rob Clark wrote:
> > On Wed, Sep 20, 2023 at 11:06 AM Rob Clark wrote:
> >>
> >> From: Rob Clark
> >>
> >> There have b
On Wed, Sep 20, 2023 at 11:06 AM Rob Clark wrote:
>
> From: Rob Clark
>
> There have been a few igt test fixes compared to the commit that we were
> currently using. Pull in a newer igt and update expectations.
>
> Signed-off-by: Rob Clark
> ---
> drive
From: Rob Clark
There have been a few igt test fixes compared to the commit that we were
currently using. Pull in a newer igt and update expectations.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/ci/gitlab-ci.yml | 2 +-
.../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 4
>>
> >> Objects with multiple possible placements are reported in multiple regions
> >> for
> >> total and shared sizes, while other categories are counted only for the
> >> currently active region.
> >>
> >> Signed-off-by: Tvrtko Ursulin
On Thu, Sep 14, 2023 at 2:54 AM Maxime Ripard wrote:
>
> Hi,
>
> On Tue, Sep 12, 2023 at 02:16:41PM +0100, Daniel Stone wrote:
> > Hopefully less mangled formatting this time: turns out Thunderbird +
> > plain text is utterly unreadable, so that's one less MUA that is
> > actually usable to send e
From: Rob Clark
So, when you want to get a cmdstream trace of some deqp or piglit test,
but you happen to be running it on the same laptop with full desktop
env, the current dump-everything firehose of `cat $debugfs/dri/n/rd` is
quite a bit too much. Ptrace seemed kind of a natural way to
On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon
wrote:
>
> On Tue, 12 Sep 2023 19:14:35 -0700
> Rob Clark wrote:
>
> > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
> > >
> > > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
> > > wrote:
>
On Mon, Sep 11, 2023 at 2:15 PM Dmitry Baryshkov
wrote:
>
> On 06/09/2023 16:38, Heikki Krogerus wrote:
> > On Wed, Sep 06, 2023 at 03:48:35PM +0300, Dmitry Baryshkov wrote:
> >> On Wed, 6 Sept 2023 at 15:44, Heikki Krogerus
> >> wrote:
> >>>
> >>> On Tue, Sep 05, 2023 at 01:56:59PM +0300, Dmitry
On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
>
> On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
> wrote:
> >
> > On Tue, 12 Sep 2023 09:37:00 +0100
> > Adrián Larumbe wrote:
> >
> > > The current implementation will try to pick the highest availa
On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
wrote:
>
> On Tue, 12 Sep 2023 09:37:00 +0100
> Adrián Larumbe wrote:
>
> > The current implementation will try to pick the highest available size
> > display unit as soon as the BO size exceeds that of the previous
> > multiplier. That can lead to
On Wed, Aug 30, 2023 at 8:51 AM Adrián Larumbe
wrote:
>
> >> The current implementation will try to pick the highest available
> >> unit. This is rather unflexible, and allowing drivers to display BO size
> >> statistics through fdinfo in units of their choice might be desirable.
> >>
> >> The new
;>>> other so we can know when a code change breaks those expectations.
> >>>>>
> >>>>> Also, include a configuration file that points to the out-of-tree
> >>>>> CI scripts.
> >>>>>
> >>>>> This will allo
therwise) to
> systemd-logind.
> """
>
> v2:
> * Fixed typo in commit text and added a fine historical explanation
>from Emil.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: "Christian König"
> Cc: Daniel Vetter
> Acked-by: Christian
On Wed, Aug 23, 2023 at 6:36 PM Adrián Larumbe
wrote:
>
> The current implementation will try to pick the highest available
> unit. This is rather unflexible, and allowing drivers to display BO size
> statistics through fdinfo in units of their choice might be desirable.
>
> The new argument to dr
On Fri, Aug 25, 2023 at 2:11 PM Konrad Dybcio wrote:
>
> SM6375 comes with a patchlevel=1. Fix the chipid up to reflect that.
>
> Fixes: 90b593ce1c9e ("drm/msm/adreno: Switch to chip-id for identifying GPU")
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 2 +-
On Fri, Aug 25, 2023 at 8:06 AM Helen Mae Koike Fornazier
wrote:
>
> On Friday, August 25, 2023 11:41 -03, Rob Clark wrote:
>
> > On Fri, Aug 25, 2023 at 7:34 AM Helen Mae Koike Fornazier
> > wrote:
> > >
> > > On Friday, August 25, 2023 11:30 -03, Rob Cl
On Fri, Aug 25, 2023 at 7:34 AM Helen Mae Koike Fornazier
wrote:
>
> On Friday, August 25, 2023 11:30 -03, Rob Clark wrote:
>
> > On Fri, Aug 25, 2023 at 6:56 AM Jani Nikula
> > wrote:
> > >
> > > On Fri, 25 Aug 2023, Vignesh Raman wrote:
> > >
On Fri, Aug 25, 2023 at 6:56 AM Jani Nikula wrote:
>
> On Fri, 25 Aug 2023, Vignesh Raman wrote:
> > Force db410c to host mode to fix network issue which results in failure
> > to mount root fs via NFS.
> > See
> > https://gitlab.freedesktop.org/gfx-ci/linux/-/commit/cb72a629b8c15c80a54dda510743
From: Rob Clark
This consists of simply storing the most recent deadline, and adding an
ioctl to retrieve the deadline. This can be used in conjunction with
the SET_DEADLINE ioctl on a fence fd for testing. Ie. create various
sw_sync fences, merge them into a fence-array, set deadline on the
From: Rob Clark
Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits. This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can adjust GPU frequency accordingly. An immediate deadline can be
From: Rob Clark
The initial purpose is for igt tests, but this would also be useful for
compositors that wait until close to vblank deadline to make decisions
about which frame to show.
The igt tests can be found at:
https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence
From: Rob Clark
This is a re-post of the remaining patches from:
https://patchwork.freedesktop.org/series/114490/
Part of the hold-up of the remaining uabi patches was compositor
support, but now an MR for kwin exists:
https://invent.kde.org/plasma/kwin/-/merge_requests/4358
The syncobj
On Tue, Aug 22, 2023 at 11:48 AM Rafael J. Wysocki wrote:
>
> On Tue, Aug 22, 2023 at 8:02 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > In the process of adding lockdep annotation for drm GPU scheduler's
> > job_run() to detect potential deadlock
On Tue, Aug 22, 2023 at 11:48 AM Rafael J. Wysocki wrote:
>
> On Tue, Aug 22, 2023 at 8:02 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > In the process of adding lockdep annotation for drm GPU scheduler's
> > job_run() to detect potential deadlock
From: Rob Clark
Now that the runpm/qos/interconnect lockdep vs reclaim issues are
solved, we can enable the fence signalling annotations without lockdep
making it's immediate displeasure known.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_ringbuffer.c | 1 +
1 file chang
From: Rob Clark
Based on
https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
but made to be optional.
Signed-off-by: Rob Clark
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/scheduler/sched_main.c | 9 +
include/drm/gpu_scheduler.h| 2 ++
2
From: Rob Clark
Move runpm enable to just before we enqueue the job to the scheduler,
rather than job_run(). This has the disadvantage of potentially
powering up the GPU before waiting for fences, but it is the only
feasible way to move things like clk_prepare() out of the fence
signalling path
From: Rob Clark
The locking is unneeded here as runpm provides sufficient serialization.
Fixes:
==
WARNING: possible circular locking dependency detected
6.4.3-debug+ #16 Not tainted
From: Rob Clark
Teach lockdep that icc_bw_lock is needed in code paths that could
deadlock if they trigger reclaim.
Signed-off-by: Rob Clark
---
drivers/interconnect/core.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/core.c b/drivers
From: Rob Clark
For cases where icc_bw_set() can be called in callbaths that could
deadlock against shrinker/reclaim, such as runpm resume, we need to
decouple the icc locking. Introduce a new icc_bw_lock for cases where
we need to serialize bw aggregation and update to decouple that from
paths
From: Rob Clark
In the process of adding lockdep annotation for drm GPU scheduler's
job_run() to detect potential deadlock against shrinker/reclaim, I hit
this lockdep splat:
==
WARNING: possible circular locking dependency det
From: Rob Clark
Similar to the previous patch, move the allocation out from under
dev_pm_qos_mtx, by speculatively doing the allocation and handle
any race after acquiring dev_pm_qos_mtx by freeing the redundant
allocation.
Signed-off-by: Rob Clark
---
drivers/base/power/qos.c | 13
From: Rob Clark
Annotate dev_pm_qos_mtx to teach lockdep to scream about allocations
that could trigger reclaim under dev_pm_qos_mtx.
Signed-off-by: Rob Clark
---
drivers/base/power/qos.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/base/power/qos.c b/drivers/base
From: Rob Clark
This will make it easier to catch places doing allocations that can
trigger reclaim under devfreq->lock.
Because devfreq->lock is held over various devfreq_dev_profile
callbacks, there might be some fallout if those callbacks do allocations
that can trigger reclaim, bu
From: Rob Clark
In the process of adding lockdep annotation for GPU job_run() path to
catch potential deadlocks against the shrinker/reclaim path, I turned
up this lockdep splat:
==
WARNING: possible circular locking dependency detected
From: Rob Clark
Inspired by
https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
it seemed like a good idea to get rid of memory allocation in job_run()
fence signaling path, and use lockdep annotations to yell at us about
anything that could deadlock against
On Tue, Aug 22, 2023 at 6:01 AM Christian König
wrote:
>
> Am 18.08.23 um 16:59 schrieb Rob Clark:
> > From: Rob Clark
> >
> > If a signal callback releases the sw_sync fence, that will trigger a
> > deadlock as the timeline_fence_release recurses onto the
splay: msm: sm8450-mdss: document displayport
controller subnode
dt-bindings: display: msm: sm8550-mdss: document displayport
controller subnode
Rob Clark (28):
drm/msm/adreno: Fix warn splat for devices without revn
drm/msm/a690: Remove revn and name
drm/msm/ad
From: Rob Clark
If a signal callback releases the sw_sync fence, that will trigger a
deadlock as the timeline_fence_release recurses onto the fence->lock
(used both for signaling and the the timeline tree).
To avoid that, temporarily hold an extra reference to the signalled
fences until af
On Fri, Aug 18, 2023 at 2:09 AM Christian König
wrote:
>
> Am 17.08.23 um 23:37 schrieb Rob Clark:
> > From: Rob Clark
> >
> > If a signal callback releases the sw_sync fence, that will trigger a
> > deadlock as the timeline_fence_release recurses onto the
From: Rob Clark
If a signal callback releases the sw_sync fence, that will trigger a
deadlock as the timeline_fence_release recurses onto the fence->lock
(used both for signaling and the the timeline tree).
To avoid that, temporarily hold an extra reference to the signalled
fences until af
On Tue, Aug 15, 2023 at 12:23 PM Dave Airlie wrote:
>
> > > Otherwise, there should be something like a drm-ci tree, from which you
> > > can fetch the changes directly.
> >
> > I asked for a pull request so that I could also merge it to msm-next
> > so that I can do CI this cycle. (Unlike the ea
On Tue, Aug 15, 2023 at 5:51 AM Thomas Zimmermann wrote:
>
> Hi Daniel
>
> Am 15.08.23 um 14:35 schrieb Daniel Vetter:
> > On Tue, 15 Aug 2023 at 14:31, Thomas Zimmermann wrote:
> >>
> >> Hi,
> >>
> >> thanks for your patchset.
> >>
> >> Am 15.08.23 um 13:53 schrieb Helen Mae Koike Fornazier:
> >
On Tue, Aug 8, 2023 at 2:03 PM Konrad Dybcio wrote:
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index 49f38edf9854..3e69ef9dde3f 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -
It is in https://gitlab.freedesktop.org/drm/msm/-/merge_requests/75 so
should be in msm-next for v6.6
BR,
-R
On Fri, Aug 11, 2023 at 9:11 AM Fabio Estevam wrote:
>
> Hi Rob,
>
> Any comments, please?
>
> On Mon, Jul 24, 2023 at 5:28 PM Fabio Estevam wrote:
> >
> > Hi Rob,
> >
> > A gentle ping.
On Fri, Aug 11, 2023 at 9:31 AM Konrad Dybcio wrote:
>
> On 11.08.2023 18:21, Rob Clark wrote:
> > On Fri, Aug 11, 2023 at 9:11 AM Konrad Dybcio
> > wrote:
> >>
> >> On 11.08.2023 18:09, Rob Clark wrote:
> >>> On Fri, Aug 11, 2023 at 9:05 AM
On Fri, Aug 11, 2023 at 9:11 AM Konrad Dybcio wrote:
>
> On 11.08.2023 18:09, Rob Clark wrote:
> > On Fri, Aug 11, 2023 at 9:05 AM Rob Clark wrote:
> >>
> >> From: Rob Clark
> >>
> >> There isn't actually a a690_gmu.bin. But it appears th
On Fri, Aug 11, 2023 at 9:05 AM Rob Clark wrote:
>
> From: Rob Clark
>
> There isn't actually a a690_gmu.bin. But it appears that the normal
> a660_gmu.bin works fine. Normally all the devices within a sub-
> generation (or "family") will use the same fw,
201 - 300 of 2055 matches
Mail list logo
