good to record the links to userspace and igt in the commit
message so it's easier to find. Anyway, Jani asked me to stamp an approval
on this, hence:
Acked-by: Simona Vetter
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
GEM handles") only solved the problem
> partially. They especially don't work for buffer objects without a DRM
> framebuffer associated.
>
> Hence, this revert to going back to using .import_attach->dmabuf.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Simon
int drm_gem_fb_init_with_funcs(struct dr
> > drm_dbg_kms(dev,
> > "GEM object size (%zu) smaller than minimum
> > size (%u) for plane %d\n",
> > objs[i]->size, min_size, i);
> &
On Tue, Jul 15, 2025 at 02:24:52PM +0200, Thomas Zimmermann wrote:
> The backlight interfaces don't require anything from , so
> don't include it.
>
> Signed-off-by: Thomas Zimmermann
I like this very much.
Reviewed-by: Simona Vetter
I guess also my Acked-by for m
On Tue, Jul 15, 2025 at 02:24:42PM +0200, Thomas Zimmermann wrote:
> Make the header self contained for including.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Simona Vetter
> ---
> include/linux/fbcon.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> di
On Tue, Jul 15, 2025 at 02:24:39PM +0200, Thomas Zimmermann wrote:
> Include to declare device_property_read_u32(). Avoids
> dependency on backlight header to include it.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Simona Vetter
> ---
> drivers/gpu/drm/panel/panel
GEM handles") only solved the problem
> partially. They especially don't work for buffer objects without a DRM
> framebuffer associated.
>
> Hence, this revert to going back to using .import_attach->dmabuf.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by:
On Tue, Jul 15, 2025 at 09:41:12AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 14.07.25 um 14:39 schrieb Simona Vetter:
> > On Fri, Jul 11, 2025 at 11:35:15AM +0200, Thomas Zimmermann wrote:
> > > Revert the use of drm_gem_object.dma_buf back to .import_attach->dmabuf
&
On Mon, Jul 14, 2025 at 11:50:32AM +0200, Christian König wrote:
> On 11.07.25 23:55, Simona Vetter wrote:
> > On Fri, Jul 11, 2025 at 10:53:42AM -0400, David Francis wrote:
> >> The drm_gem ioctls were documented in internal file drm_gem.c
> >> instead of uapi header
t. Hence all the reverts.
The patches also need Fixes: and as needed, cc: stable added for merging.
With that and the above text as additional justification added:
Reviewed-by: Simona Vetter
Also we'd need to chase down any addiotional conversions that have only
landed in -next meanwhile
On Mon, Jul 14, 2025 at 10:57:48AM +0530, Riana Tauro wrote:
>
>
> On 7/11/2025 2:29 PM, Simona Vetter wrote:
> > On Thu, Jul 10, 2025 at 11:37:14AM +0200, Christian König wrote:
> > > On 10.07.25 11:01, Simona Vetter wrote:
> > > > On Wed, Jul 09, 2025 at
gt; https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/graph.yaml
> > + * for the bindings.
> >*
> >* Returns zero if successful, or one of the standard error codes if it
> > fails.
> >*/
> >
> > ---
> > base-commit: 6f392f37165008cfb3f89d723aa019e372ee79b9
> > change-id: 20250609-drm-misc-next-2f4dd8f88bb9
> >
> > Best regards,
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
display pm if there is error after display suspend
drm/xe: Release runtime pm for error path of xe_devcoredump_read()
drm/xe/pm: Correct comment of xe_pm_set_vram_threshold()
Simona Vetter (4):
drm/gem: Fix race in drm_gem_handle_create_tail()
Merge tag &#x
ng care of this!
Reviewed-by: Simona Vetter
I'll leave review for the first patch to folks who care about criu, but it
looked good to me too.
-Sima
> ---
> drivers/gpu/drm/drm_gem.c | 30 -
> include/uapi/drm/drm.h| 40 +++--
On Fri, Jul 11, 2025 at 01:34:19PM +0100, Chris Clayton wrote:
> Hi
>
> I've built and installed 6.16 cloned from Linus' tree and am consistently
> getting a warning during system startup.
> The warning is not produced by rc4 but is by rc5, so I've bisected between
> those two points abd the out
ender buffers to a display driver). But better we take
another week to really think this through before rushing things.
The handle_count changes do look reasonable to me too, but for an entirely
different bug around bo import/export. And I think we'll want a testcase
for that to make sure
in_place() the drm::Device in release()
>
> Dave Airlie (1):
> nouveau/gsp: add a 50ms delay between fbsr and driver unload rpcs
>
> Lukas Wunner (1):
> agp/amd64: Check AGP Capability before binding to unsupported devices
>
> Mikko Perttunen (1):
> drm
virtgpu_dma_buf_unmap(bo);
> > dma_resv_unlock(dmabuf->resv);
> >
> > - dma_buf_detach(dmabuf, obj->import_attach);
> > + dma_buf_detach(dmabuf, attach);
> > dma_buf_put(dmabuf);
> > }
> >
>
> Acked-by: Dmitry Osipenko
Thanks, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ernal.h | 2 -
> > drivers/gpu/drm/drm_prime.c | 8 ++-
> > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 4 +-
> > drivers/gpu/drm/virtio/virtgpu_prime.c | 5 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 6 +-
> > include/drm/drm_framebuffer.h| 7 ---
> > 11 files changed, 35 insertions(+), 106 deletions(-)
> >
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jul 11, 2025 at 01:00:03PM +0200, Christian König wrote:
> On 11.07.25 12:08, Simona Vetter wrote:
> > On Fri, Jul 11, 2025 at 11:35:17AM +0200, Thomas Zimmermann wrote:
> >> This reverts commit 5307dce878d4126e1b375587318955bd019c3741.
> >>
> >> We&#
t; - drm_gem_object_handle_put_unlocked(objs[i]);
> + drm_gem_object_put(objs[i]);
> }
> return ret;
> }
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index f921cc73f8b8..9078504e789c 100644
> --- a/drivers/gpu/drm/dr
drm/i915/bios: Apply vlv_fixup_mipi_sequences() to v2 mipi-sequences too
>
> drivers/gpu/drm/i915/display/intel_bios.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
---
> Hans de Goede (1):
> drm/i915/bios: Apply vlv_fixup_mipi_sequences() to v2 mipi-sequences too
>
> drivers/gpu/drm/i915/display/intel_bios.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
5 +-
> drivers/gpu/drm/xe/xe_uc_fw.c | 8 +-
> drivers/gpu/drm/xe/xe_vm.c | 8 +-
> drivers/gpu/drm/xe/xe_wa.c | 16 +
> drivers/gpu/drm/xe/xe_wa_oob.rules | 10 +-
> drivers/i2c/busses/i2c-designware-platdrv.c | 18 +-
> drivers/mtd/devices/Kconfig | 11 +
> drivers/mtd/devices/Makefile| 1 +
> drivers/mtd/devices/mtd_intel_dg.c | 830 +++
> include/drm/drm_gpusvm.h| 96
> include/drm/drm_pagemap.h | 135 +
> include/drm/intel/pciids.h | 5 +-
> include/linux/intel_dg_nvm_aux.h| 32 ++
> include/uapi/drm/xe_drm.h | 8 +-
> 98 files changed, 3981 insertions(+), 1630 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_pagemap.c
> create mode 100644 drivers/gpu/drm/xe/regs/xe_i2c_regs.h
> create mode 100644 drivers/gpu/drm/xe/xe_i2c.c
> create mode 100644 drivers/gpu/drm/xe/xe_i2c.h
> create mode 100644 drivers/gpu/drm/xe/xe_nvm.c
> create mode 100644 drivers/gpu/drm/xe/xe_nvm.h
> create mode 100644 drivers/mtd/devices/mtd_intel_dg.c
> create mode 100644 include/linux/intel_dg_nvm_aux.h
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
e/xe_trace_bo.h| 4 +-
> drivers/gpu/drm/xe/xe_uc.c | 78 +--
> drivers/gpu/drm/xe/xe_uc.h | 5 +-
> drivers/gpu/drm/xe/xe_uc_fw.c | 8 +-
> drivers/gpu/drm/xe/xe_vm.c | 8 +-
> drivers/gpu/drm/xe/xe_wa.c | 16 +
> drivers/gpu/drm/xe/xe_wa_oob.rules | 10 +-
> drivers/i2c/busses/i2c-designware-platdrv.c | 18 +-
> drivers/mtd/devices/Kconfig | 11 +
> drivers/mtd/devices/Makefile| 1 +
> drivers/mtd/devices/mtd_intel_dg.c | 830 +++
> include/drm/drm_gpusvm.h| 96
> include/drm/drm_pagemap.h | 135 +
> include/drm/intel/pciids.h | 5 +-
> include/linux/intel_dg_nvm_aux.h| 32 ++
> include/uapi/drm/xe_drm.h | 8 +-
> 98 files changed, 3981 insertions(+), 1630 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_pagemap.c
> create mode 100644 drivers/gpu/drm/xe/regs/xe_i2c_regs.h
> create mode 100644 drivers/gpu/drm/xe/xe_i2c.c
> create mode 100644 drivers/gpu/drm/xe/xe_i2c.h
> create mode 100644 drivers/gpu/drm/xe/xe_nvm.c
> create mode 100644 drivers/gpu/drm/xe/xe_nvm.h
> create mode 100644 drivers/mtd/devices/mtd_intel_dg.c
> create mode 100644 include/linux/intel_dg_nvm_aux.h
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Ceresoli (3):
> drm/bridge: tc358767: fix uninitialized variable regression
> drm/sti: hdmi: convert to devm_drm_bridge_alloc() API
> drm/sti: hda: convert to devm_drm_bridge_alloc() API
>
> Maarten Lankhorst (1):
> Merge remote-tracking branch 'drm/drm-next' into
0x2a0
> Jul 10 16:12:52 qca-HP-ZBook-14-G2 kernel: ? __pfx_kthread+0x10/0x10
> Jul 10 16:12:52 qca-HP-ZBook-14-G2 kernel: ret_from_fork+0x215/0x2f0
> Jul 10 16:12:52 qca-HP-ZBook-14-G2 kernel: ? __pfx_kthread+0x10/0x10
> Jul 10 16:12:52 qca-HP-ZBook-14-G2 kernel: ret_from_fork_asm+0x1a/0x30
> Jul 10 16:12:52 qca-HP-ZBook-14-G2 kernel:
>
> This doesn't seem to be the cause of the ath12k issue I'm debugging,
> but thought it worth mentioning since I only see one similar report
> on lore, and that didn't have any apparent follow-up:
> https://lore.kernel.org/all/20250202161048.373f89c0@yea/
>
> /jeff
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
potential
> circular dependencies in some cases. With all that said, move RCU related
> API to the rculist.h where it belongs.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Simona Vetter
Also ack for the dmem part for merging through your tree.
-Sima
> ---
> i
On Thu, Jul 10, 2025 at 11:37:14AM +0200, Christian König wrote:
> On 10.07.25 11:01, Simona Vetter wrote:
> > On Wed, Jul 09, 2025 at 12:52:05PM -0400, Rodrigo Vivi wrote:
> >> On Wed, Jul 09, 2025 at 05:18:54PM +0300, Raag Jadav wrote:
> >>> On Wed, Jul 09, 2025
On Thu, Jul 10, 2025 at 03:00:06PM -0400, Rodrigo Vivi wrote:
> On Thu, Jul 10, 2025 at 01:24:52PM +0300, Raag Jadav wrote:
> > On Thu, Jul 10, 2025 at 11:37:14AM +0200, Christian König wrote:
> > > On 10.07.25 11:01, Simona Vetter wrote:
> > > > On Wed, Jul 09, 202
eturn
> values").
>
> Signed-off-by: Sean Christopherson
I guess this'll all land through x86 trees, for that on this and the patch
from Peter to adjust the module exports to include drm and i915:
Acked-by: Simona Vetter
Cheers, Sima
> ---
> drivers/gpu/drm/drm_cac
ODULES(wbinvd_on_cpus_mask,
> "kvm,kvm-amd,agpgart,ccp,drm,i915");
>
> static void __wbnoinvd(void *dummy)
> {
> @@ -35,10 +35,10 @@ void wbnoinvd_on_all_cpus(void)
> {
> on_each_cpu(__wbnoinvd, NULL, 1);
> }
> -EXPORT_SYMBOL_GPL(wbnoinvd_on_all_cpus);
> +EXPORT_SYMBOL_GPL_FOR_MODULES(wbnoinvd_on_all_cpus,
> "kvm-amd,agpgart,ccp,drm,i915");
>
> void wbnoinvd_on_cpus_mask(struct cpumask *cpus)
> {
> on_each_cpu_mask(cpus, __wbnoinvd, NULL, 1);
> }
> -EXPORT_SYMBOL_GPL(wbnoinvd_on_cpus_mask);
> +EXPORT_SYMBOL_GPL_FOR_MODULES(wbnoinvd_on_cpus_mask,
> "kvm-amd,agpgart,ccp,drm,i915");
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jul 10, 2025 at 08:07:40PM +, Simon Ser wrote:
> Bump: would anyone be willing to review this?
Reviewed-by: Simona Vetter
I did check the parenthesis about CRTC that are off and stay off just to
make sure, that code is in drm_atomic_crtc_check() at the very bottom.
-Sima
--
Sim
On Wed, Jul 09, 2025 at 12:52:05PM -0400, Rodrigo Vivi wrote:
> On Wed, Jul 09, 2025 at 05:18:54PM +0300, Raag Jadav wrote:
> > On Wed, Jul 09, 2025 at 04:09:20PM +0200, Christian König wrote:
> > > On 09.07.25 15:41, Simona Vetter wrote:
> > > > On Wed, Jul 09, 2
On Wed, Jul 09, 2025 at 04:48:21PM +0100, Steven Price wrote:
> On 09/07/2025 14:52, Simona Vetter wrote:
> > The object is potentially already gone after the drm_gem_object_put().
> > In general the object should be fully constructed before calling
> > drm_gem_handle_create(
On Mon, Jul 07, 2025 at 05:18:13PM +0200, Simona Vetter wrote:
> Object creation is a careful dance where we must guarantee that the
> object is fully constructed before it is visible to other threads, and
> GEM buffer objects are no difference.
>
> Final publishing hap
iviu Dudau
Signed-off-by: Simona Vetter
Signed-off-by: Simona Vetter
---
drivers/gpu/drm/panthor/panthor_gem.c | 31 +--
drivers/gpu/drm/panthor/panthor_gem.h | 3 ---
2 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_gem.c
dp_comp.c | 1 +
> drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 9 +
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 1 +
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 +++
> drivers/gpu/drm/mediatek/mtk_dpi.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_plane.c|
RECOVERY_NONE BIT(0) /* optional telemetry
> collection */
> #define DRM_WEDGE_RECOVERY_REBINDBIT(1) /* unbind + bind driver */
> #define DRM_WEDGE_RECOVERY_BUS_RESET BIT(2) /* unbind + reset bus device +
> bind */
> +#define DRM_WEDGE_RECOVERY_VENDORBIT(3) /* vendor specific recovery
> method */
>
> /**
> * struct drm_wedge_task_info - information about the guilty task of a wedge
> dev
> --
> 2.47.1
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
y_desc;
> /*
> - * Instead of blindly using registered_fb[0], we use info_idx, set by
> + * Instead of blindly using fbcon_registered_fb[0], we use info_idx,
> set by
>* fbcon_fb_registered();
>*/
> info = fbcon_registered_fb[info_idx];
> --
> 2.25.1
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
s.
Since you're touching this area I think I'd be really nice to also
document the related gem ioctls so that the new docs aren't entirely
floating around in vacuum.
Thanks, Sima
> + /** Current handle of object */
> + __u32 handle;
> +
> + /** Handle to change that object to */
> + __u32 new_handle;
> +};
> +
> /**
> * DRM_CAP_DUMB_BUFFER
> *
> @@ -1305,6 +1314,14 @@ extern "C" {
> */
> #define DRM_IOCTL_SET_CLIENT_NAMEDRM_IOWR(0xD1, struct
> drm_set_client_name)
>
> +/**
> + * DRM_IOCTL_GEM_CHANGE_HANDLE - Move an object to a different handle
> + *
> + * Some applications (notably CRIU) need objects to have specific gem
> handles.
> + * This ioctl changes the object at one gem handle to use a new gem handle.
> + */
> +#define DRM_IOCTL_GEM_CHANGE_HANDLEDRM_IOWR(0xD2, struct
> drm_gem_change_handle)
> +
> /*
> * Device specific ioctls should only be in their respective headers
> * The device specific ioctl range is from 0x40 to 0x9f.
> --
> 2.34.1
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jul 08, 2025 at 10:21:07AM +0100, Liviu Dudau wrote:
> Hi Simona,
>
> On Mon, Jul 07, 2025 at 05:18:14PM +0200, Simona Vetter wrote:
> > The object is potentially already gone after the drm_gem_object_put().
> > In general the object should be fully const
t; include/dt-bindings/power/qcom-rpmpd.h |1 +
> include/linux/soc/qcom/ubwc.h | 75 +
> include/uapi/drm/msm_drm.h | 149 +-
> 179 files changed, 11379 insertions(+), 8072 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml
> delete mode 100644 drivers/gpu/drm/ci/xfails/msm-sdm845-fails.txt
> delete mode 100644 drivers/gpu/drm/ci/xfails/msm-sdm845-flakes.txt
> delete mode 100644 drivers/gpu/drm/ci/xfails/msm-sdm845-skips.txt
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_12_0_sm8750.h
> delete mode 100644 drivers/gpu/drm/msm/dp/dp_catalog.c
> delete mode 100644 drivers/gpu/drm/msm/dp/dp_catalog.h
> delete mode 100644 drivers/gpu/drm/msm/msm_mdss.h
> create mode 100644 drivers/gpu/drm/msm/msm_syncobj.c
> create mode 100644 drivers/gpu/drm/msm/msm_syncobj.h
> create mode 100644 drivers/gpu/drm/msm/registers/adreno/a6xx_descriptors.xml
> create mode 100644 drivers/gpu/drm/msm/registers/adreno/a6xx_enums.xml
> create mode 100644 drivers/gpu/drm/msm/registers/adreno/a6xx_perfcntrs.xml
> create mode 100644 drivers/gpu/drm/msm/registers/adreno/a7xx_enums.xml
> create mode 100644 drivers/gpu/drm/msm/registers/adreno/a7xx_perfcntrs.xml
> create mode 100644 drivers/soc/qcom/ubwc_config.c
> create mode 100644 include/linux/soc/qcom/ubwc.h
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+-
> drivers/gpu/drm/i915/selftests/mock_request.c | 2 +-
> drivers/gpu/drm/i915/soc/intel_dram.c | 5 +-
> drivers/gpu/drm/ttm/ttm_bo_util.c | 26 ++
> drivers/gpu/drm/xe/Makefile| 3 +-
> .../gpu/drm/xe/compat-i915-head
2);
> + done = drm_mock_sched_job_wait_finished(job, MOCK_TIMEOUT / 2);
> KUNIT_ASSERT_FALSE(test, done);
>
> KUNIT_ASSERT_EQ(test,
> job->flags & DRM_MOCK_SCHED_JOB_TIMEDOUT,
> 0);
>
> - done = drm_mock
8] ? __pfx_drm_mode_closefb_ioctl+0x10/0x10
> > [ 795.464533] drm_ioctl_kernel+0xb2/0x110
> > [ 795.464537] drm_ioctl+0x2ea/0x5b0
> > [ 795.464541] ? __pfx_drm_mode_closefb_ioctl+0x10/0x10
> > [ 795.464550] nouveau_drm_ioctl+0x5e/0xc0 [nouveau]
> > [ 795.464783] __x64_sys_ioctl+0xa2/0x100
> > [ 795.464790] x64_sys_call+0x106b/0x2320
> > [ 795.464794] do_syscall_64+0x80/0xe80
> > [ 795.464802] ? __x64_sys_poll+0xd2/0x180
> > [ 795.464808] ? arch_exit_to_user_mode_prepare.isra.0+0xd/0xc0
> > [ 795.464813] ? do_syscall_64+0xb6/0xe80
> > [ 795.464819] ? futex_hash+0xe/0x20
> > [ 795.464823] ? futex_wake+0x89/0x1b0
> > [ 795.464830] ? do_futex+0x18e/0x260
> > [ 795.464835] ? __x64_sys_futex+0x127/0x200
> > [ 795.464839] ? eventfd_write+0xdc/0x200
> > [ 795.464844] ? security_file_permission+0x5b/0x170
> > [ 795.464850] ? arch_exit_to_user_mode_prepare.isra.0+0xd/0xc0
> > [ 795.464854] ? do_syscall_64+0xb6/0xe80
> > [ 795.464862] ? ksys_write+0xd9/0xf0
> > [ 795.464869] ? arch_exit_to_user_mode_prepare.isra.0+0xd/0xc0
> > [ 795.464873] ? do_syscall_64+0xb6/0xe80
> > [ 795.464878] ? do_syscall_64+0xb6/0xe80
> > [ 795.464883] ? arch_exit_to_user_mode_prepare.isra.0+0xd/0xc0
> > [ 795.464888] ? irqentry_exit_to_user_mode+0x2d/0x1d0
> > [ 795.464893] ? irqentry_exit+0x43/0x50
> > [ 795.464897] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > [ 795.464901] RIP: 0033:0x7f0b7ad24ded
> > [ 795.464904] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10
> > c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00
> > 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00
> > 00 00
> > [ 795.464907] RSP: 002b:7ffca5eb8f50 EFLAGS: 0246 ORIG_RAX:
> > 0010
> > [ 795.464912] RAX: ffda RBX: 55b1a8710050 RCX:
> > 7f0b7ad24ded
> > [ 795.464915] RDX: 7ffca5eb8fe0 RSI: c00864d0 RDI:
> > 000c
> > [ 795.464917] RBP: 7ffca5eb8fa0 R08: R09:
> > 7f0b7ae03ac0
> > [ 795.464920] R10: 0008 R11: 0246 R12:
> > 7ffca5eb8fe0
> > [ 795.464922] R13: c00864d0 R14: 000c R15:
> > 2f66b7a8
> > [ 795.464929]
> > [ 795.464931] ---[ end trace ]---
> >
> >
> > --
> > Thanks,
> >
> > Steve
>
>
>
> --
> Thanks,
>
> Steve
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
v2: Fix build issues for !CONFIG_DEBUGFS (Adrián)
Fixes: a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects
over DebugFS")
Cc: Adrián Larumbe
Cc: Boris Brezillon
Cc: Steven Price
Cc: Liviu Dudau
Signed-off-by: Simona Vetter
Signed-off-by: Simona Vetter
---
Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Simona Vetter
Signed-off-by: Simona Vetter
Signed-off-by: Simona Vetter
---
drivers/gpu/drm/drm_gem.c | 10 +-
include/drm/drm_file.h| 3 +++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_g
so for patches 1-5:
Reviewed-by: Simona Vetter
And a-b for the vgaswitcheroo patch for merging through the pci tree or a
dedicated pr to Linus, since I guess that's the simplest way to get that
done.
Cheers, Sima
> ---
> sound/hda/hdac_i915.c | 2 +-
> sound/pci/hda/hda_intel.
ally only about VGA devices.
I missed the earlier version, but wanted to chime in that I concur. vgaarb
is about vga decoding, and modern gpu drivers are trying pretty hard to
disable that since it can cause pain. If we mix in the meaning of "default
display device" into this, we have a mess.
I guess what does make sense is if the kernel exposes its notion of
"default display device", since we do have that in some sense with
simpledrm. At least on systems where simpledrm is a thing, but I think you
need some really old machines for that to not be the case.
Cheers, Sima
> Best regards
> Thomas
>
> >
> > Dave,
> >
> > What is your current temperature on this approach?
> >
> > Do you still think it's best for something in the kernel or is this
> > better done in libpciaccess?
> >
> > Mutter, Kwin, and Cosmic all handle this case in the compositor.
> >
> >
> > >
> > > Alex
> > >
> > > [1]https://lore.kernel.org/all/bc0a3ac2-c86c-43b8-b83f-edfdfa5ee...@suse.de/
> > >
> > >
> >
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jun 17, 2025 at 05:08:57PM +0200, Danilo Krummrich wrote:
> On Tue, Jun 17, 2025 at 04:25:09PM +0200, Simona Vetter wrote:
> > On Tue, Jun 17, 2025 at 04:10:40PM +0200, Danilo Krummrich wrote:
> > > On Tue, Jun 17, 2025 at 03:51:33PM +0200, Simona Vetter wrote:
> >
of better options I think this is
all fine, but please make sure xe_iaf_map_attachment has it all properly
documented - especially if/once that gets exported to other drivers.
Cheers, Sima
> + }
>
> sg_set_page(sg, NULL, size, 0);
> sg_dma_address(sg) = addr;
> @@ -413,7 +418,7 @@ int xe_ttm_vram_mgr_alloc_sgt(struct xe_device *xe,
>
> error_unmap:
> for_each_sgtable_sg((*sgt), sg, i) {
> - if (!sg->length)
> + if (!sg->length || !valid_dma_direction(dir))
> continue;
>
> dma_unmap_resource(dev, sg->dma_address,
> @@ -433,10 +438,14 @@ void xe_ttm_vram_mgr_free_sgt(struct device *dev, enum
> dma_data_direction dir,
> struct scatterlist *sg;
> int i;
>
> - for_each_sgtable_sg(sgt, sg, i)
> + for_each_sgtable_sg(sgt, sg, i) {
> + if (!valid_dma_direction(dir))
> + continue;
> +
> dma_unmap_resource(dev, sg->dma_address,
> sg->length, dir,
> DMA_ATTR_SKIP_CPU_SYNC);
> + }
> sg_free_table(sgt);
> kfree(sgt);
> }
> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> index 18f967ce1f1a6..f3dd38c95deb5 100644
> --- a/drivers/gpu/drm/xe/xe_vm.c
> +++ b/drivers/gpu/drm/xe/xe_vm.c
> @@ -1534,7 +1534,7 @@ static u64 xelp_pte_encode_bo(struct xe_bo *bo, u64
> bo_offset,
> pte |= pte_encode_pat_index(pat_index, pt_level);
> pte |= pte_encode_ps(pt_level);
>
> - if (xe_bo_is_vram(bo) || xe_bo_is_stolen_devmem(bo))
> + if (xe_bo_is_vram(bo) || xe_bo_is_stolen_devmem(bo) || xe_bo_is_iaf(bo))
> pte |= XE_PPGTT_PTE_DM;
>
> return pte;
> --
> 2.45.2
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jun 17, 2025 at 04:10:40PM +0200, Danilo Krummrich wrote:
> On Tue, Jun 17, 2025 at 03:51:33PM +0200, Simona Vetter wrote:
> > On Thu, Jun 12, 2025 at 04:49:54PM +0200, Philipp Stanner wrote:
> > > + * NOTE that sharing &struct drm_sched_init_args.submit_wq
On Tue, 17 Jun 2025 at 16:11, Simona Vetter wrote:
>
> On Fri, Jun 13, 2025 at 04:10:22PM +0200, Simona Vetter wrote:
> > On Fri, Jun 13, 2025 at 04:04:46PM +0200, Simona Vetter wrote:
> > > On Fri, Jun 13, 2025 at 03:12:01PM +0200, Christian König wrote:
> > > >
On Fri, Jun 13, 2025 at 04:10:22PM +0200, Simona Vetter wrote:
> On Fri, Jun 13, 2025 at 04:04:46PM +0200, Simona Vetter wrote:
> > On Fri, Jun 13, 2025 at 03:12:01PM +0200, Christian König wrote:
> > > It is possible through flink or IOCTLs like MODE_GETFB2 to create
> >
On Mon, Jun 16, 2025 at 01:38:17PM +0200, Christian König wrote:
> On 6/16/25 12:38, Simona Vetter wrote:
> >> 6. Now FD2HANDLE is called with 10 and here is what happens:
> >>
> >>drm_prime_lookup_buf_by_handle() is called for handle 10, so we
> >>
use for timeout work. If NULL, the system_wq is
> used.
> + * @timeout_wq: workqueue to use for timeout work. If NULL, the system_wq is
> + * used. An ordered workqueue could be passed to achieve timeout
> + * synchronization. See &DOC: Concurreny in drm/sched and
t; >
> > Well, I can't say I buy this argument. If you can show me any real
> > workload where using a spinlock here vs. going lockless makes a
> > measurable impact, I'd eat my hat. Also, FWIW, this code seemingly
> > violates the DRM locking guidelines we're all supposed to follow… But
> > anyway, I'll go ahead with the fix above.
>
> I probably have to take that back, see another comment below.
>
> >
> > Matt
> >
> >> That was the reason why we replaced the spinlock with the spsc queue
> >> before.
>
> Well we replaced spinlock+kfifo with spsc the for round robing peeking
> implementation.
>
> Background is that because of the spinlock even a "peek" transfers the cache
> line as write to the sheduler thread, and when you do the "peek" even on the
> idle entities then that starts to not scale at all.
>
> Since we now have the FIFO implementation and avoiding peeking all the time
> into the job queue of idle entities that might as well not suck that badly
> any more.
>
> Regards,
> Christian.
>
> >>
> >> Regards,
> >> Christian.
> >>
> >>>
> >>> Matt
> >>
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jun 13, 2025 at 05:03:39PM +0200, Christian König wrote:
> On 6/13/25 16:35, Simona Vetter wrote:
> > On Fri, Jun 13, 2025 at 04:12:47PM +0200, Christian König wrote:
> >> On 6/13/25 16:04, Simona Vetter wrote:
> >>> On Fri, Jun 13, 2025 at 03:12:01P
On Fri, Jun 13, 2025 at 04:12:47PM +0200, Christian König wrote:
> On 6/13/25 16:04, Simona Vetter wrote:
> > On Fri, Jun 13, 2025 at 03:12:01PM +0200, Christian König wrote:
> >> It is possible through flink or IOCTLs like MODE_GETFB2 to create
> >> multiple handles
On Fri, Jun 13, 2025 at 04:04:46PM +0200, Simona Vetter wrote:
> On Fri, Jun 13, 2025 at 03:12:01PM +0200, Christian König wrote:
> > It is possible through flink or IOCTLs like MODE_GETFB2 to create
> > multiple handles for the same underlying GEM object.
> >
> >
> + }
> if (dma_buf > pos->dma_buf)
> p = &rb->rb_right;
> else
> --
> 2.34.1
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
>>> Jani
> >>> Nikula
> >>> Sent: Friday, 13 June 2025 14.02
> >>> To: Tvrtko Ursulin ; Simona Vetter
> >>> ; Christian König
> >>>
> >>> Cc: tzimmerm...@suse.de; dri-devel@lists.freedesktop.org
> >>> Subje
On Fri, Jun 13, 2025 at 12:11:39PM +, Saarinen, Jani wrote:
> Hi,
>
> > -Original Message-
> > From: dri-devel On Behalf Of Jani
> > Nikula
> > Sent: Friday, 13 June 2025 14.02
> > To: Tvrtko Ursulin ; Simona Vetter
> > ; Christian König
&
/scheduler: signal scheduled fence when kill job
Michael Walle (1):
drm/panel-simple: fix the warnings for the Evervision VGG644804
Simona Vetter (2):
Merge tag 'drm-misc-fixes-2025-05-28' of
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
Merge tag 'drm-
On Wed, Jun 04, 2025 at 10:10:21AM -0700, Matthew Brost wrote:
> On Wed, Jun 04, 2025 at 06:53:44PM +0200, Danilo Krummrich wrote:
> > On Wed, Jun 04, 2025 at 09:45:00AM -0700, Matthew Brost wrote:
> > > On Wed, Jun 04, 2025 at 05:07:15PM +0200, Simona Vetter wrote:
> >
ideo/screen_info_pci.c | 75
> +++-
> 7 files changed, 117 insertions(+), 73 deletions(-)
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
pu/drm/scheduler/sched_entity.c | 1 +
> drivers/video/console/dummycon.c | 18 +-
> 6 files changed, 42 insertions(+), 23 deletions(-)
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jun 04, 2025 at 05:36:22PM +0200, Simona Vetter wrote:
> On Wed, Jun 04, 2025 at 01:32:34PM +0200, Christian König wrote:
> > This was added by Sima +10 years ago as a solution to avoid exporting
> > multiple dma-bufs for the same GEM object. I tried to remove it before,
>
break;
> - } else if (member->handle < handle) {
> + } else if (member->dma_buf < dma_buf) {
> rb = rb->rb_right;
> } else {
> rb = rb->rb_left;
> @@ -446,12 +412,6 @@ struct dma_buf *drm_gem_prime_handle_to_dmabuf(struct
> drm_device *dev,
> goto out_unlock;
> }
>
> - dmabuf = drm_prime_lookup_buf_by_handle(&file_priv->prime, handle);
> - if (dmabuf) {
> - get_dma_buf(dmabuf);
> - goto out;
> - }
> -
> mutex_lock(&dev->object_name_lock);
> /* re-export the original imported/exported object */
> if (obj->dma_buf) {
> --
> 2.34.1
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
e never documented that you should do it
> this way.
It is documented, just not here. See the note in
drm_sched_backend_ops.timedout_job at the very bottom.
We should definitely have a lot more cross-links between the various
pieces of this puzzle though, that's for sure :-)
Cheers, Sima
>
> Regards,
> Christian.
>
> > * @score: score atomic shared with other schedulers. May be NULL.
> > * @name: name (typically the driver's name). Used for debugging
> > * @dev: associated device. Used for debugging
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
. Can you send a patch?
Not sure that's what's going on, from the comment and reading the code
(albeit non-exhaustively) I think you can only get positive error return
values from walk_page_range if the ops you provide do so. The hmm ones
don't, so I think this should be ok without any code changes?
Maybe a WARN_ON and patching that up for paranoia, but I don't see how
this can happen.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
w talks further down in this file, if people want to get an
overview over what drm does.
If you want I guess you could add some links to the relevant wikipedia
pages, I think they also do a fairly decent job of explaining the big
picture.
Thanks, Sima
> >
> > Style Guidelines
> >
> >
>
> The patch LGTM, thanks!
>
> Reviewed-by: Bagas Sanjaya
>
> --
> An old man doll... just what I always wanted! - Clara
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
a problem with hyperv_fb,
> > and I found several other related problems, some of which also existed
> > in hyperv_drm. You've seen several small'ish fixes from me and Saurabh
> > as a result, and this issue with mmap()'ing /dev/fb0 is the last one of that
> > set. This fix is definitely a bit bigger, but it's the right fix. On the
> > flip side,
> > if we really get on a path to deprecate hyperv_fb, there are hack fixes for
> > the mmap problem that are smaller and contained to hyperv_fb. I would
> > be OK with a hack fix in that case.
> >
> > Michael
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jun 03, 2025 at 01:45:54PM +0200, Simona Vetter wrote:
> On Mon, Jun 02, 2025 at 05:15:58PM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 28.05.25 um 11:12 schrieb Simona Vetter:
> > > Object creation is a careful dance where we must guarantee
On Mon, Jun 02, 2025 at 05:15:58PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 28.05.25 um 11:12 schrieb Simona Vetter:
> > Object creation is a careful dance where we must guarantee that the
> > object is fully constructed before it is visible to other threads, and
> >
On Wed, May 28, 2025 at 04:47:00PM +0200, Danilo Krummrich wrote:
> On Wed, May 28, 2025 at 04:39:01PM +0200, Danilo Krummrich wrote:
> > On Wed, May 28, 2025 at 09:29:30AM -0400, Alex Deucher wrote:
> > > On Wed, May 28, 2025 at 8:45 AM Simona Vetter
> > > wrote:
>
he past we've had
cases where we thought we should have caught abuse but didn't. And this
isn't the only thing we use, it's just one tool in the box among many
others to keep the flood of driver issues at a manageable level.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Sun, Jun 01, 2025 at 03:06:15PM +0100, Adrián Larumbe wrote:
> Hi Simona,
>
> On 28.05.2025 11:13, Simona Vetter wrote:
> > The object is potentially already gone after the drm_gem_object_put().
> > In general the object should be fully constructed before calling
>
On Wed, May 28, 2025 at 09:15:22AM -0600, Jeff Hugo wrote:
> On 5/28/2025 3:13 AM, Simona Vetter wrote:
> > Handles are per-file, not global, so this makes no sense. Plus it's
> > set only after calling drm_gem_handle_create(), and drivers are not
> > allowed to further
of deps scale with
> > > > > > > the number of
> > > > > > > * engines involved, rather than the number of BOs.
> > > > > > > */
> > > > > > > - xa_for_each(&job->dependencies, index, entry) {
> > > > >
On Wed, May 28, 2025 at 11:13:06AM +0200, Simona Vetter wrote:
> idr_for_each_entry() is fine, but will prematurely terminate on
> transient NULL entries. It should be switched over to idr_for_each,
> which allows you to handle this explicitly.
>
> Note that transient N
On Wed, May 28, 2025 at 11:12:59AM +0200, Simona Vetter wrote:
> Object creation is a careful dance where we must guarantee that the
> object is fully constructed before it is visible to other threads, and
> GEM buffer objects are no difference.
>
> Final publishing hap
from idr_for_each_entry to idr_for_each only fixes temporary premature idr
iteration termination, and so fairly benign impact.
Testing and review very much welcome.
Cheers, Sima
Simona Vetter (8):
drm/gem: Fix race in drm_gem_handle_create_tail()
drm/fdinfo: Switch to idr_for_each
On Wed, May 28, 2025 at 11:13:05AM +0200, Simona Vetter wrote:
> idr_for_each_entry() is fine, but will prematurely terminate on
> transient NULL entries. It should be switched over to idr_for_each,
> which allows you to handle this explicitly.
>
> Note that transient N
On Wed, May 28, 2025 at 11:13:04AM +0200, Simona Vetter wrote:
> idr_for_each_entry() is fine, but will prematurely terminate on
> transient NULL entries. It should be switched over to idr_for_each,
> which allows you to handle this explicitly.
>
> Note that transient N
On Wed, May 28, 2025 at 11:13:00AM +0200, Simona Vetter wrote:
> Unlike idr_for_each_entry(), which terminates on the first NULL entry,
> idr_for_each passes them through. This fixes potential issues with the
> idr walk terminating prematurely due to transient NULL entries the
>
river references to handle
before making it available again"), this is a really old issue.
Since it's just a premature loop terminate the impact should be fairly
benign, at least for any debugfs or fdinfo code.
Signed-off-by: Simona Vetter
Signed-off-by: Simona Vetter
Cc: Zack Rusin
Cc: Br
ed in the light of the revised hotunplug design
we're aiming for. But that's an entirely separate can of worms.
Cc: Alex Deucher
Cc: "Christian König"
Cc: Arvind Yadav
Cc: Shashank Sharma
Cc: Simona Vetter
Cc: Yunxiang Li
Cc: Frank Min
Cc: Kent Russell
Signed-off-by: S
m: Add fdinfo memory stats")
Cc: Rob Clark
Cc: Emil Velikov
Cc: Tvrtko Ursulin
Cc: # v6.5+
Signed-off-by: Simona Vetter
Signed-off-by: Simona Vetter
---
drivers/gpu/drm/drm_file.c | 95 ++
1 file changed, 55 insertions(+), 40 deletions(-)
diff --git a/dri
by: Simona Vetter
Signed-off-by: Simona Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 260165bbe373..aa51930a012b 100644
--- a/d
which can mess up the iterator state. And that's actually
bad.
Signed-off-by: Daniel Vetter
Signed-off-by: Simona Vetter
Cc: Lucas De Marchi
Cc: "Thomas Hellström"
Cc: Rodrigo Vivi
Cc: intel...@lists.freedesktop.org
---
drivers/gpu/drm/xe/xe_drm_client.c | 3 +++
1 file changed,
Since we're still holding a reference to the bo nothing bad can
happen, hence not cc: stable material.
Cc: Jeff Hugo
Cc: Carl Vanderlip
Cc: linux-arm-...@vger.kernel.org
Signed-off-by: Simona Vetter
Signed-off-by: Simona Vetter
---
drivers/accel/qaic/qaic.h | 2 --
drivers/accel/qaic/q
rnel.org
Cc: Jacek Lawrynowicz
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Simona Vetter
Signed-off-by: Simona Vetter
Signed-off-by: Simona Vetter
---
drivers/gpu/drm/drm_gem.c | 10 +-
include/drm/drm_file.h| 3 +++
2 files changed, 12 insert
cleanup.
Fixes: a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects
over DebugFS")
Cc: Adrián Larumbe
Cc: Boris Brezillon
Cc: Steven Price
Cc: Liviu Dudau
Signed-off-by: Simona Vetter
Signed-off-by: Simona Vetter
---
drivers/gpu/drm/panthor/panthor_gem.c | 31 +--
On Wed, Apr 16, 2025 at 11:38:03AM +0200, Simona Vetter wrote:
> On Wed, Apr 16, 2025 at 08:57:45AM +0200, Thomas Zimmermann wrote:
> > Test struct drm_gem_object.import_attach to detect imported objects.
> >
> > During object clenanup, the dma_buf field might be NULL.
t; /**
> > diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-
> > buf.h
> > index
> > 5a6fda66d9adf01438619e7e67fa69f0fec2d88d..f3aba46942042de6a2e3a4cca3e
> > b3f87175e29c9 100644
> > --- a/include/uapi/linux/dma-buf.h
> > +++ b/include/uapi/linux/dma-buf.h
> > @@ -178,5 +178,6 @@ struct dma_buf_import_sync_file {
> > #define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, __u64)
> > #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE _IOWR(DMA_BUF_BASE, 2,
> > struct dma_buf_export_sync_file)
> > #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct
> > dma_buf_import_sync_file)
> > +#define DMA_BUF_IOCTL_GET_DMA_ADDR _IOR(DMA_BUF_BASE, 4, __u64
> > *)
> >
> > #endif
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ut stolen memory.
2. Account, but don't enforce any limits on evictions. This could already
get funny if then system memory allocations start failing for random
reasons due to memory pressure from other processes.
3. Probably at this point we need a memcg aware shrinker in ttm drivers
that want
n
> Cc: Anusha Srivatsa
> Cc: Christian König
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Simona Vetter
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
>
On Tue, Apr 15, 2025 at 03:57:11PM +0200, Christian König wrote:
> Am 15.04.25 um 15:10 schrieb Simona Vetter:
> >> This is for devices who only want to do a vmap of the buffer, isn't it?
> > ... it's for the vmap only case, where you might not even have a struct
>
1 - 100 of 368 matches
Mail list logo
