Hi Dave,
Fixes for v6.9, description below
The following changes since commit 4be445f5b6b6810baf397b2d159bd07c3573fd75:
drm/msm/dpu: capture snapshot on the first commit_done timeout
(2024-03-04 11:44:03 +0200)
are available in the Git repository at:
On Tue, Apr 9, 2024 at 8:23 AM Dmitry Baryshkov
wrote:
>
> On Tue, Apr 09, 2024 at 05:12:46PM +0200, Konrad Dybcio wrote:
> >
> >
> > On 4/6/24 04:56, Dmitry Baryshkov wrote:
> > > On Fri, Apr 05, 2024 at 10:41:31AM +0200, Konrad Dybcio wrote:
> > > > From: Neil Armstrong
> > > >
> > > >
On Wed, Apr 3, 2024 at 11:37 AM Adrián Larumbe
wrote:
>
> Up to this day, all fdinfo-based GPU profilers must traverse the entire
> /proc directory structure to find open DRM clients with fdinfo file
> descriptors. This is inefficient and time-consuming.
>
> This patch adds a new device class
On Thu, Mar 28, 2024 at 11:54 AM Simon Ser wrote:
>
> On Thursday, March 28th, 2024 at 19:47, Rob Clark wrote:
>
> > any chance I could talk you into pushing to drm-misc-fixes?
>
> Oh sorry, I thought you had access… Pushed with a minor edit to remove
> unnecessary parent
On Tue, Mar 26, 2024 at 2:15 AM Simon Ser wrote:
>
> Makes sense to me!
>
> Reviewed-by: Simon Ser
Thanks.. any chance I could talk you into pushing to drm-misc-fixes?
BR,
-R
wrote:
>
> It also fixes importing virtgpu blobs into real hardware, for instance amdgpu
> for DRI_PRIME rendering.
>
> On Fri, Mar 22, 2024 at 2:48 PM Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> virtgpu "vram" GEM objects do not implement
From: Rob Clark
virtgpu "vram" GEM objects do not implement obj->get_sg_table(). But
they also don't use drm_gem_map_dma_buf(). In fact they may not even
have guest visible pages. But it is perfectly fine to export and share
with other virtual devices.
Reported-by: Domini
On Thu, Mar 2, 2023 at 6:35 AM Simon Ser wrote:
>
> drm_gem_map_dma_buf() requires drm_gem_object_funcs.get_sg_table
> to be implemented, or else WARNs.
>
> Allow drivers to leave this hook unimplemented to implement purely
> local DMA-BUFs (ie, DMA-BUFs which cannot be imported anywhere
> else
On Fri, Mar 15, 2024 at 4:46 AM Dmitry Baryshkov
wrote:
>
> Currently display-related register headers are generated from XML files
> shipped withing Mesa source tree. This is not fully optimal: it requires
> multi-stage process of the changes first being landed to Mesa and only
> then synced to
On Fri, Mar 15, 2024 at 2:28 AM Jani Nikula wrote:
>
> On Thu, 14 Mar 2024, Rob Clark wrote:
> > When we first merged drm/ci I was unsure if it would need it's own
> > -next branch. But after using it for a couple releases, a few times
> > I've found myself wanting to
When we first merged drm/ci I was unsure if it would need it's own
-next branch. But after using it for a couple releases, a few times
I've found myself wanting to backmerge drm/ci changes without
necessarily backmerging all of drm-misc-next.
So, maybe it makes some sense to have a drm-ci-next
Hi Dave,
This is the last bit for v6.9, which was waiting on
drm-misc-next-2024-02-29. Description below.
The following changes since commit 177bce60cd10a4ffdc9881bf6f2dff7880408c1d:
Merge tag 'drm-misc-next-2024-02-29' into msm-next (2024-03-03 18:32:11 -0800)
are available in the Git
On Wed, Mar 6, 2024 at 3:24 PM Ville Syrjälä
wrote:
>
> On Wed, Mar 06, 2024 at 07:37:16AM -0800, Rob Clark wrote:
> > On Wed, Mar 6, 2024 at 7:06 AM Ville Syrjälä
> > wrote:
> > >
> > > On Wed, Mar 06, 2024 at 06:49:15AM -0800, Rob Clark wrote:
> >
On Wed, Mar 6, 2024 at 7:06 AM Ville Syrjälä
wrote:
>
> On Wed, Mar 06, 2024 at 06:49:15AM -0800, Rob Clark wrote:
> > On Wed, Mar 6, 2024 at 4:18 AM Thomas Zimmermann
> > wrote:
> > >
> > > Hi,
> > >
> > > sorry that I did not see the
On Wed, Mar 6, 2024 at 4:18 AM Thomas Zimmermann wrote:
>
> Hi,
>
> sorry that I did not see the patch before.
>
> Am 27.02.24 um 23:19 schrieb Douglas Anderson:
> > Even though the UDL driver converts to RGB565 internally (see
> > pixel32_to_be16() in udl_transfer.c), it advertises XRGB for
On Mon, Mar 4, 2024 at 5:38 PM Gurchetan Singh
wrote:
>
>
>
>
> On Fri, Mar 1, 2024 at 10:54 AM Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> Perfetto can use these traces to track global and per-process GPU memory
>> usage.
>>
>> Sign
On Fri, Mar 1, 2024 at 10:53 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Perfetto can use these traces to track global and per-process GPU memory
> usage.
>
> Signed-off-by: Rob Clark
> ---
> I realized the tracepoint that perfetto uses to show GPU memory usage
From: Rob Clark
Perfetto can use these traces to track global and per-process GPU memory
usage.
Signed-off-by: Rob Clark
---
I realized the tracepoint that perfetto uses to show GPU memory usage
globally and per-process was already upstream, but with no users.
This overlaps a bit with fdinfo
rm/msm/dpu: Only enable DSC_MODE_MULTIPLEX if dsc_merge is enabled
Neil Armstrong (4):
dt-bindings: display/msm/gmu: Document Adreno 750 GMU
dt-bindings: arm-smmu: fix SM8[45]50 GPU SMMU if condition
dt-bindings: arm-smmu: Document SM8650 GPU SMMU
drm/msm: add support for
Hi Dave,
A late revert to address a displayport hpd regression.
The following changes since commit 8c7bfd8262319fd3f127a5380f593ea76f1b88a2:
drm/msm: Wire up tlb ops (2024-02-15 08:51:31 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.git
On Wed, Feb 21, 2024 at 6:36 PM Dmitry Baryshkov
wrote:
>
> On Tue, 20 Feb 2024 at 16:31, Helen Koike wrote:
> >
> >
> >
> > On 20/02/2024 09:17, Dmitry Baryshkov wrote:
> > > Bump IGT revision to pick up Rob Clark's fixes for the msm driver:
> > >
> > > -
Dmitry Baryshkov (1):
drm/msm/a6xx: set highest_bank_bit to 13 for a610
Rob Clark (3):
drm/msm/gem: Fix double resv lock aquire
Revert "drm/msm/gpu: Push gpu lock down past runpm"
drm/msm: Wire up tlb ops
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/g
On Wed, Feb 14, 2024 at 11:34 PM Johan Hovold wrote:
>
> On Tue, Feb 13, 2024 at 09:23:40AM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > The brute force iommu_flush_iotlb_all() was good enough for unmap, but
> > in some cases a map operation could requ
From: Rob Clark
The brute force iommu_flush_iotlb_all() was good enough for unmap, but
in some cases a map operation could require removing a table pte entry
to replace with a block entry. This also requires tlb invalidation.
Missing this was resulting an obscure iova fault on what should
On Mon, Feb 12, 2024 at 1:55 PM Rob Clark wrote:
>
> From: Rob Clark
>
> DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
> which means we can't rely too much on variable initializers.
>
> Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable
From: Rob Clark
DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
which means we can't rely too much on variable initializers.
Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable use")
Signed-off-by: Rob Clark
---
I have mixed feel
Hi Dave,
A few fixes for v6.8, description below
The following changes since commit d4ca26ac4be0d9aea7005c40df75e6775749671b:
drm/msm/dp: call dp_display_get_next_bridge() during probe
(2023-12-14 09:27:46 +0200)
are available in the Git repository at:
Hi Dave,
A few fixes for v6.8, description below
The following changes since commit d4ca26ac4be0d9aea7005c40df75e6775749671b:
drm/msm/dp: call dp_display_get_next_bridge() during probe
(2023-12-14 09:27:46 +0200)
are available in the Git repository at:
From: Rob Clark
Since commit 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap
operations"), the resv lock is already held in the prime vmap path, so
don't try to grab it again.
v2: This applies to vunmap path as well
v3: Fix fixes commit
Fixes: 79e2cf2e7a19 (&quo
From: Rob Clark
Since commit 56e5abba8c3e ("dma-buf: Add unlocked variant of vmapping
functions"), the resv lock is already held in the prime vmap path, so
don't try to grab it again.
v2: This applies to vunmap path as well
Fixes: 56e5abba8c3e ("dma-buf: Add unlocked vari
From: Rob Clark
Since commit 56e5abba8c3e ("dma-buf: Add unlocked variant of vmapping
functions"), the resv lock is already held in the prime vmap path, so
don't try to grab it again.
Fixes: 56e5abba8c3e ("dma-buf: Add unlocked variant of vmapping functions")
Sign
On Fri, Jan 12, 2024 at 7:57 AM Rob Clark wrote:
>
> On Fri, Jan 12, 2024 at 3:42 AM Vignesh Raman
> wrote:
> >
> > Hi Rob,
> >
> >
> > On 09/01/24 01:20, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > The msm tests shoul
On Fri, Jan 12, 2024 at 3:42 AM Vignesh Raman
wrote:
>
> Hi Rob,
>
>
> On 09/01/24 01:20, Rob Clark wrote:
> > From: Rob Clark
> >
> > The msm tests should skip on non-msm hw, so I think it should be safe to
> > enable everywhere.
> >
> > Sign
On Wed, Jan 10, 2024 at 2:50 AM Daniel Vetter wrote:
>
> On Tue, Jan 09, 2024 at 10:22:17AM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > This reverts commit abe2023b4cea192ab266b351fd38dc9dbd846df0.
> >
> > Changing the locking order means t
From: Rob Clark
This reverts commit abe2023b4cea192ab266b351fd38dc9dbd846df0.
Changing the locking order means that scheduler/msm_job_run() can race
with the recovery kthread worker, with the result that the GPU gets an
extra runpm get when we are trying to power it off. Leaving the GPU
On Mon, Jan 8, 2024 at 6:13 PM Rob Clark wrote:
>
> On Mon, Jan 8, 2024 at 2:58 PM Abhinav Kumar
> wrote:
> >
> >
> >
> > On 1/8/2024 11:50 AM, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > The msm tests should skip on non-msm
On Mon, Jan 8, 2024 at 2:58 PM Abhinav Kumar wrote:
>
>
>
> On 1/8/2024 11:50 AM, Rob Clark wrote:
> > From: Rob Clark
> >
> > The msm tests should skip on non-msm hw, so I think it should be safe to
> > enable everywhere.
> >
> > Signed-off
From: Rob Clark
The msm tests should skip on non-msm hw, so I think it should be safe to
enable everywhere.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/ci/testlist.txt | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/ci/testlist.txt b
On Thu, Dec 7, 2023 at 10:02 AM Alex Deucher wrote:
>
> Show buffers as shared if they are shared via dma-buf as well
> (e.g., shared with v4l or some other subsystem).
>
> Signed-off-by: Alex Deucher
> Cc: Rob Clark
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm
On Tue, Jan 2, 2024 at 12:12 PM Konrad Dybcio wrote:
>
> On 2.01.2024 20:33, Rob Clark wrote:
> > From: Rob Clark
> >
> > We'd miss actually activating LLC.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
From: Rob Clark
We'd miss actually activating LLC.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index a5660d63535b
On Fri, Dec 22, 2023 at 11:58 AM Akhil P Oommen
wrote:
>
> On Mon, Dec 18, 2023 at 07:59:24AM -0800, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > a6xx_recover() is relying on the gpu lock to serialize against incoming
> > submits doing a runpm get, as
From: Rob Clark
a6xx_recover() is relying on the gpu lock to serialize against incoming
submits doing a runpm get, as it tries to temporarily balance out the
runpm gets with puts in order to power off the GPU. Unfortunately this
gets worse when we (in a later patch) will move the runpm get out
On Mon, Dec 11, 2023 at 2:09 PM Marijn Suijten
wrote:
>
> On 2023-12-11 10:19:55, Rob Clark wrote:
> > From: Rob Clark
> >
> > When we start getting these, we get a *lot*. So ratelimit it to not
> > flood dmesg.
> >
> > Signed-off-by: Rob Clark
> &
From: Rob Clark
When we start getting these, we get a *lot*. So ratelimit it to not
flood dmesg.
Signed-off-by: Rob Clark
---
dpu should probably stop rolling it's own trace macros, but that would
be a larger cleanup.
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 5 -
drivers/gpu/drm
On Wed, Dec 6, 2023 at 4:29 AM Konrad Dybcio wrote:
>
>
>
> On 12/5/23 23:03, Rob Clark wrote:
> > From: Rob Clark
> >
> > Split into a separate table per generation, in preparation to move each
> > gen's device table to it's own file.
> >
> > Sig
From: Rob Clark
Move the CP_PROTECT settings into the hw catalog.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 246 -
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 255 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2
From: Rob Clark
Introduce a6xx_info where we can stash gen specific stuff without
polluting the toplevel adreno_info struct.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 55 +--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +-
drivers/gpu/drm
From: Rob Clark
Move the hwcg tables into the hw catalog.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 560 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 558 -
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 -
3 files
From: Rob Clark
Split each gen's gpu table into it's own file. Only code-motion, no
functional change.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 5 +
drivers/gpu/drm/msm/adreno/a2xx_catalog.c | 53 ++
drivers/gpu/drm/msm/adreno/a3xx_catalog.c | 75
From: Rob Clark
Split into a separate table per generation, in preparation to move each
gen's device table to it's own file.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 59 +++---
1 file changed, 51 insertions(+), 8 deletions(-)
diff --git
From: Rob Clark
Split the single flat gpulist table into per-gen tables that exist in
their own per-gen files, and start moving more info into the device
table. This at least gets all the big tables of register settings out
of the heart of the a6xx_gpu code. Probably more could be moved
From: Rob Clark
This does unfortunately require a mesa fix to avoid turnip hanging, but
we don't have a good way to know the userspace version. Fortunately
that fix is now in mesa-23.3.0-rc3 and later[1].
[1]
https://gitlab.freedesktop.org/mesa/mesa/-/commit
From: Rob Clark
Container fences have burner contexts, which makes the trick to store at
most one fence per context somewhat useless if we don't unwrap array or
chain fences.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/scheduler/sched_main.c | 47 ++
1 file changed
On Tue, Dec 5, 2023 at 8:56 AM Rob Clark wrote:
>
> On Tue, Dec 5, 2023 at 7:58 AM Christian König
> wrote:
> >
> > Am 05.12.23 um 16:41 schrieb Rob Clark:
> > > On Mon, Dec 4, 2023 at 10:46 PM Christian König
> > > wrote:
> > >> Am 04.12.23
On Tue, Dec 5, 2023 at 7:58 AM Christian König wrote:
>
> Am 05.12.23 um 16:41 schrieb Rob Clark:
> > On Mon, Dec 4, 2023 at 10:46 PM Christian König
> > wrote:
> >> Am 04.12.23 um 22:54 schrieb Rob Clark:
> >>> On Thu, Mar 23, 2023 at 2:30 PM Rob Clark wr
On Mon, Dec 4, 2023 at 10:46 PM Christian König
wrote:
>
> Am 04.12.23 um 22:54 schrieb Rob Clark:
> > On Thu, Mar 23, 2023 at 2:30 PM Rob Clark wrote:
> >> [SNIP]
> > So, this patch turns out to blow up spectacularly with dma_fence
> > refcnt underflows when
On Thu, Mar 23, 2023 at 2:30 PM Rob Clark wrote:
>
> On Thu, Mar 23, 2023 at 7:03 AM Christian König
> wrote:
> >
> > Am 23.03.23 um 14:54 schrieb Rob Clark:
> > > On Thu, Mar 23, 2023 at 12:35 AM Christian König
> > > wrote:
> > >> Am 22.
From: Rob Clark
The UBWC settings need to match between the display and GPU. When we
updated the GPU settings, we forgot to make the corresponding update on
the display side.
Reported-by: Steev Klimaszewski
Fixes: 07e6de738aa6 ("drm/msm/a690: Fix reg values for a690")
Signed-off-by:
On Thu, Nov 30, 2023 at 5:13 AM Christian König
wrote:
>
> Am 28.11.23 um 18:52 schrieb Rob Clark:
> > On Tue, Nov 28, 2023 at 6:28 AM Alex Deucher wrote:
> >> On Tue, Nov 28, 2023 at 9:17 AM Christian König
> >> wrote:
> >>> Am 17.11.23 um 20:56 sch
On Tue, Nov 28, 2023 at 6:28 AM Alex Deucher wrote:
>
> On Tue, Nov 28, 2023 at 9:17 AM Christian König
> wrote:
> >
> > Am 17.11.23 um 20:56 schrieb Alex Deucher:
> > > Add shared stats. Useful for seeing shared memory.
> > >
> > > Signed-off-by: Alex Deucher
> > > ---
> > >
On Tue, Nov 21, 2023 at 5:14 AM Dmitry Baryshkov
wrote:
>
> On Tue, 21 Nov 2023 at 04:26, Rob Clark wrote:
> >
> > On Wed, Nov 15, 2023 at 11:33 AM Dmitry Baryshkov
> > wrote:
> > >
> > > On Wed, 15 Nov 2023 at 20:46, Dipam Turkar wrote:
> > &
From: Danylo Piliaiev
KGSL doesn't support a690 so all reg values were the same as
on a660. Now we know the values and they are different from the
windows driver.
This fixes hangs on D3D12 games and some CTS tests.
Signed-off-by: Danylo Piliaiev
Signed-off-by: Rob Clark
---
drivers/gpu/drm
From: Danylo Piliaiev
Downstream always set BIT(7)
Signed-off-by: Danylo Piliaiev
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno
On Tue, Nov 21, 2023 at 4:41 PM Abhinav Kumar wrote:
>
>
>
> On 10/24/2023 12:01 PM, Abhinav Kumar wrote:
> >
> >
> > On 10/23/2023 4:03 PM, Dmitry Baryshkov wrote:
> >> On Tue, 24 Oct 2023 at 01:36, Rob Clark wrote:
> >>>
> >>>
Hi Dave,
A few fixes for v6.7, description below
The following changes since commit b08d26dac1a1075c874f40ee02ec8ddc39e20146:
drm/msm/a7xx: actually use a7xx state registers (2023-10-16 09:38:56 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.git
From: Danylo Piliaiev
KGSL doesn't support a690 so all reg values were the same as
on a660. Now we know the values and they are different from the
windows driver.
This fixes hangs on D3D12 games and some CTS tests.
Signed-off-by: Danylo Piliaiev
Signed-off-by: Rob Clark
---
drivers/gpu/drm
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
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
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 place
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 objects
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 deletions(-)
diff
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 VkImage
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.
Ro
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 i
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 VkImage
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.
Ro
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 to g
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 VkImage
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
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 place
1 - 100 of 5720 matches
Mail list logo
