On Wed, Jun 19, 2024 at 01:31:37AM +0200, Danilo Krummrich wrote:
> From: Asahi Lina
>
> DRM drivers need to be able to declare which driver-specific ioctls they
> support. Add an abstraction implementing the required types and a helper
> macro to generate the ioctl definition inside the DRM driv
On Wed, Jun 19, 2024 at 01:31:36AM +0200, Danilo Krummrich wrote:
> This patch series implements some basic DRM Rust abstractions and a stub
> implementation of the Nova GPU driver.
>
> Nova is intended to be developed upstream, starting out with just a stub
> driver
> to lift some initial requir
On Wed, Jun 19, 2024 at 01:31:39AM +0200, Danilo Krummrich wrote:
> Implement the DRM driver abstractions.
>
> The `Driver` trait provides the interface to the actual driver to fill
> in the driver specific data, such as the `DriverInfo`, driver features
> and IOCTLs.
>
> Co-developed-by: Asahi L
On Mon, Sep 02, 2024 at 12:58:54PM +0200, Christian König wrote:
> Am 31.08.24 um 00:28 schrieb Matthew Brost:
> > On Fri, Aug 30, 2024 at 12:40:57PM +0200, Boris Brezillon wrote:
> > > dma_fence objects created by drm_sched might hit other subsystems, which
> > > means the fence object might poten
On Thu, Aug 29, 2024 at 01:48:34PM -0700, Jessica Zhang wrote:
> If the clone mode enabled status is changing, a modeset needs to happen
> so that the resources can be reassigned
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 ++
> 1 file changed, 6 ins
On Mon, Sep 02, 2024 at 12:43:45PM +0200, Christian König wrote:
> Am 30.08.24 um 23:43 schrieb Matthew Brost:
> > On Fri, Aug 30, 2024 at 10:14:18AM +0200, Christian König wrote:
> > > Am 29.08.24 um 19:12 schrieb Boris Brezillon:
> > > > dma_fence objects created by an entity might outlive the
>
On Thu, Aug 29, 2024 at 03:55:56PM +, Matthew Brost wrote:
> On Thu, Aug 29, 2024 at 12:14:53PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 27, 2024 at 07:48:57PM -0700, Matthew Brost wrote:
> > > Wire xe_bo_move to GPUSVM migration to SRAM with trylocking
On Thu, Aug 29, 2024 at 09:48:11PM +, Matthew Brost wrote:
> On Thu, Aug 29, 2024 at 11:24:26AM +0200, Christian König wrote:
> >Am 28.08.24 um 18:06 schrieb Daniel Vetter:
> >
>
> A lot to unpack here. Will try to address as much as I can in this
> single repl
On Mon, Sep 02, 2024 at 01:01:45PM +0200, Christian König wrote:
> Am 30.08.24 um 00:12 schrieb Matthew Brost:
> > On Thu, Aug 29, 2024 at 01:02:54PM +0200, Daniel Vetter wrote:
> > > On Thu, Aug 29, 2024 at 11:53:58AM +0200, Thomas Hellström wrote:
> > > > But
On Thu, Aug 29, 2024 at 10:12:53PM +, Matthew Brost wrote:
> On Thu, Aug 29, 2024 at 01:02:54PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 29, 2024 at 11:53:58AM +0200, Thomas Hellström wrote:
> > > But as Sima pointed out in private communication, exhaustive eviction
&
Jumping in here in the middle, since I think it's a solid place to drop my
idea of "align with core mm" gpusvm locking ...
On Thu, Aug 29, 2024 at 08:56:23PM +, Matthew Brost wrote:
> On Thu, Aug 29, 2024 at 09:18:29PM +0200, Thomas Hellström wrote:
> Issues with removing a SVM range:
>
> - X
On Fri, Aug 30, 2024 at 11:16:53AM +0200, Thomas Hellström wrote:
> Hi, Matthew
>
> On Tue, 2024-08-27 at 19:48 -0700, Matthew Brost wrote:
> > +/**
> > + * DOC: Overview
> > + *
> > + * GPU Shared Virtual Memory (GPU SVM) layer for the Direct
> > Rendering Manager (DRM)
> > + *
> > + * The GPU SV
On Mon, Sep 02, 2024 at 01:20:02PM +0200, Maarten Lankhorst wrote:
> The most recent merge commits introduced some fails to drm/drm-next,
> I've noticed these when looking at the xe patches.
>
> Solve it!
>
> Signed-off-by: Maarten Lankhorst
I dropped the first hunk, since that was broken in dr
On Thu, Aug 29, 2024 at 05:27:13PM +, Matthew Brost wrote:
> On Thu, Aug 29, 2024 at 11:45:08AM +0200, Daniel Vetter wrote:
> > On Tue, Aug 27, 2024 at 07:48:38PM -0700, Matthew Brost wrote:
> > > This patch introduces support for GPU Shared Virtual Memory (SVM) in the
>
On Thu, Aug 29, 2024 at 04:49:15PM +, Matthew Brost wrote:
> On Wed, Aug 28, 2024 at 08:50:02PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 27, 2024 at 07:48:38PM -0700, Matthew Brost wrote:
> > > +int drm_gpusvm_migrate_to_sram(struct drm_gpusvm *gpusvm,
> > > +
On Fri, Aug 30, 2024 at 05:00:11AM +, Matthew Brost wrote:
> On Wed, Aug 28, 2024 at 04:31:19PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 27, 2024 at 07:48:38PM -0700, Matthew Brost wrote:
> > > + if (!ctx->mmap_locked) {
> > > + /*
>
On Thu, Aug 29, 2024 at 04:40:47PM +, Matthew Brost wrote:
> On Wed, Aug 28, 2024 at 06:25:18PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 28, 2024 at 03:43:48PM +, Matthew Brost wrote:
> > > On Wed, Aug 28, 2024 at 04:46:24PM +0200, Christian König wrote:
> >
On Mon, Sep 02, 2024 at 09:01:48AM +0200, Philipp Stanner wrote:
> On Fri, 2024-08-30 at 15:15 +0200, Christian König wrote:
> > Am 28.08.24 um 11:30 schrieb Philipp Stanner:
> > > On Mon, 2024-08-26 at 14:25 +0200, Christian König wrote:
> > > > The current implementation of drm_sched_start uses a
On Wed, Aug 28, 2024 at 05:35:45PM +0200, Andi Shyti wrote:
> Hi Sima,
>
> On Wed, Aug 28, 2024 at 03:47:21PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 28, 2024 at 10:20:15AM +0200, Andi Shyti wrote:
> > > Hi Sima,
> > >
> > > first of all, thanks for
On Wed, Aug 28, 2024 at 02:20:34PM +0200, Christian König wrote:
> Am 27.08.24 um 19:53 schrieb Daniel Vetter:
> > On Tue, Aug 27, 2024 at 06:52:13PM +0200, Daniel Vetter wrote:
> > > On Thu, Aug 22, 2024 at 03:19:29PM +0200, Christian König wrote:
> > > > Completely
On Tue, Aug 27, 2024 at 02:24:27PM -0400, Alex Deucher wrote:
> On Tue, Aug 27, 2024 at 12:58 PM Daniel Vetter wrote:
> >
> > [machine died, new one working now, I can read complicated mails again an
> > answer.]
> >
> > On Thu, Aug 22, 2024 at 03:19:29PM +0200
On Mon, Sep 02, 2024 at 11:26:11AM +0200, Maxime Ripard wrote:
> Hi,
>
> On Wed, Aug 07, 2024 at 03:19:23PM GMT, Tomi Valkeinen wrote:
> > On 25/07/2024 14:28, Maxime Ripard wrote:
> > > On Mon, Jul 15, 2024 at 11:32:34AM GMT, Tomi Valkeinen wrote:
> > > > On 02/07/2024 14:43, Maxime Ripard wrote:
On Thu, Aug 29, 2024 at 05:37:30PM -0400, James Zhu wrote:
> Since the default number 256 can't handle large modern systems
> with large numbers of GPUs, specify a more reasonable default.
>
> -v2: update drm_core_exit to unregister more drm device nodes
>
> Signed-off-by: James Zhu
We've merge
s the winning ww ticket. The core
mm design otoh does isolate pages and remove them from the lru when
they're acquired, so that they don't gunk up other processes from trying
to make forward progress and are better hidden. Which reduces temporary
page references (from lru walk) preventing migration and stuff like that.
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
that by looping over _all_ possible mappings of a page with
the rmap_walk infrastructure.
The only reason when we need the mmap lock (or vma lock or whatever) is if
we need to be coherent with other concurrent mm updates of a specific mm.
That should only be the case when migrating to vram, where the gpusvm->mm
is the special one, and when migrating to sram due to cpu faults, where
the vmf->vma->mm is special (and might at best have a tenous relationship
to the gpusvm->mm). But that's the only cases where a specific mm and vma
have any relevance to svm vram allocations.
-Sima
> +
> + return drm_gpusvm_migrate_to_sram(range->base.gpusvm, &range->base,
> + &ctx);
> +}
> +
> #define xe_svm_notifier_lock(vm__) \
> drm_gpusvm_notifier_lock(&(vm__)->svm.gpusvm)
>
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Aug 27, 2024 at 07:48:38PM -0700, Matthew Brost wrote:
> This patch introduces support for GPU Shared Virtual Memory (SVM) in the
> Direct Rendering Manager (DRM) subsystem. SVM allows for seamless
> sharing of memory between the CPU and GPU, enhancing performance and
> flexibility in GPU c
+ continue;
> + }
> +
> + src_pfns[i] = migrate_pfn(src_pfns[i]) | MIGRATE_PFN_MIGRATE;
> + }
> +
> + migrate_device_unmap(src_pfns, npages, NULL);
> + mmu_notifier_invalidate_range_end(&range);
> +
> + retur
ong.
So probably want a bunch of these testcases too to make sure that all
works, and we're not stuck with memory allocations in vram that we can't
move out.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Aug 28, 2024 at 06:06:47PM +0200, Daniel Vetter wrote:
> On Tue, Aug 27, 2024 at 07:48:56PM -0700, Matthew Brost wrote:
> > Migration is implemented with range granularity, with VRAM backing being
> > a VM private TTM BO (i.e., shares dma-resv with VM). The lifetime of th
On Wed, Aug 28, 2024 at 03:43:48PM +, Matthew Brost wrote:
> On Wed, Aug 28, 2024 at 04:46:24PM +0200, Christian König wrote:
> > Am 28.08.24 um 16:31 schrieb Daniel Vetter:
> > > On Tue, Aug 27, 2024 at 07:48:38PM -0700, Matthew Brost wrote:
> > > > +
+ }
> + }
> +
> err = drm_gpusvm_range_get_pages(&vm->svm.gpusvm, r, &ctx);
> if (err == -EFAULT || err == -EPERM)/* Corner where CPU mappings
> have change */
> goto retry;
> @@ -567,6 +644,8 @@ int xe_svm_handle_pagefault(struct xe_vm *vm, struct
> xe_vma *vma,
> dma_fence_put(fence);
>
> err_out:
> + xe_bo_put(bo);
> +
> return err;
> }
>
> diff --git a/drivers/gpu/drm/xe/xe_svm.h b/drivers/gpu/drm/xe/xe_svm.h
> index 8b72e91cc37d..3f432483a230 100644
> --- a/drivers/gpu/drm/xe/xe_svm.h
> +++ b/drivers/gpu/drm/xe/xe_svm.h
> @@ -18,6 +18,7 @@ struct xe_svm_range {
> struct list_head garbage_collector_link;
> u8 tile_present;
> u8 tile_invalidated;
> + u8 migrated :1;
> };
>
> int xe_devm_add(struct xe_tile *tile, struct xe_mem_region *mr);
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; +
> +bool drm_gpusvm_range_pages_valid(struct drm_gpusvm *gpusvm,
> + struct drm_gpusvm_range *range);
> +
> +int drm_gpusvm_range_get_pages(struct drm_gpusvm *gpusvm,
> + struct drm_gpusvm_range *range,
> +
On Wed, Aug 28, 2024 at 10:20:15AM +0200, Andi Shyti wrote:
> Hi Sima,
>
> first of all, thanks for looking into this series.
>
> On Tue, Aug 27, 2024 at 07:31:21PM +0200, Daniel Vetter wrote:
> > On Fri, Aug 23, 2024 at 03:08:40PM +0200, Andi Shyti wrote:
> > &g
ad of
> plumbing it into drm mst code.
Yeah ec5fa9fcdeca ("drm/amd/display: Adjust the MST resume flow") promised
a follow-up, but that seems to have never materialized. Really should
materialize though. Patch lgtm
Reviewed-by: Daniel Vetter
> ---
> .../gpu
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 39f1dc45
ally lgtm
Reviewed-by: Daniel Vetter
Reading code a bit I did wonder whether we could have send/receive macros
that just work for compile-time statically sized types ... but not even
kmalloc is there yet I think, at least haven't seen anything.
-Sima
> ---
> .../gpu/drm/amd/d
On Thu, Aug 22, 2024 at 08:42:52PM +0300, Jani Nikula wrote:
> Prefer the struct drm_edid based functions for allocating the EDID and
> updating the connector.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Daniel Vetter
>
> ---
>
> Cc: Hans de Goede
> Cc: Maar
_len, GFP_KERNEL);
> + imxpd->drm_edid = drm_edid_alloc(edidp, edid_len);
Randomly wondering whether drm_edid_alloc should at least sanity check the
edid size ... but for another time. On this:
Reviewed-by: Daniel Vetter
>
> ret = of_property_read_string
On Thu, Aug 22, 2024 at 08:42:50PM +0300, Jani Nikula wrote:
> Prefer the struct drm_edid based functions for reading the EDID and
> updating the connector.
>
> Signed-off-by: Jani Nikula
This time a slightly less blind ...
Reviewed-by: Daniel Vetter
:-)
>
> ---
>
; - edid = drm_get_edid(connector, hdata->ddc_adpt);
> - if (!edid)
> + drm_edid = drm_edid_read_ddc(connector, hdata->ddc_adpt);
hdmi_create_connector seems to set up the right ddc already, so I think
drm_edid_read should be working. With that:
Reviewed-by: Daniel Vetter
&g
On Thu, Aug 22, 2024 at 08:42:48PM +0300, Jani Nikula wrote:
> Look up display dimensions from display_info instead of the EDID
> directly. This will be helpful for the follow-up work.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Daniel Vetter
>
> ---
>
> Cc: Inki
On Tue, Aug 27, 2024 at 06:52:13PM +0200, Daniel Vetter wrote:
> On Thu, Aug 22, 2024 at 03:19:29PM +0200, Christian König wrote:
> > Completely agree that this is complicated, but I still don't see the need
> > for it.
> >
> > Drivers just need to use pm_ru
rivers using
drm/sched, but patches 2-4 make me happy, thanks a lot for creating them,
so on those.
Acked-by: Daniel Vetter
Cheers, Sima
> ---
> Documentation/gpu/todo.rst | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/gpu/todo.rst b
(ccs_mode);
> +
> void intel_gt_sysfs_ccs_init(struct intel_gt *gt)
> {
> if (sysfs_create_file(>->sysfs_gt, &dev_attr_num_cslices.attr))
> gt_warn(gt, "Failed to create sysfs num_cslices files\n");
> +
> + /*
> + * Do not create the ccs_mode file for non DG2 platforms
> + * because they don't need it as they have only one CCS engine
> + */
> + if (!IS_DG2(gt->i915))
> + return;
> +
> + if (sysfs_create_file(>->sysfs_gt, &dev_attr_ccs_mode.attr))
> + gt_warn(gt, "Failed to create sysfs ccs_mode files\n");
> }
> --
> 2.45.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; * considerations.
> *
> + * drm_sched_job_cleanup() can be used to disarm the job again - but only
> + * _before_ the job's fences have been published. Once a drm_sched_fence was
> + * published, the associated job needs to be submitted to and processed by
> the
> + *
c| 2 +-
> .../gpu/drm/i915/gt/selftest_workarounds.c| 14 +-
> drivers/gpu/drm/i915/gt/sysfs_engines.c | 79 ++--
> drivers/gpu/drm/i915/gt/sysfs_engines.h | 2 +
> drivers/gpu/drm/i915/i915_cmd_parser.c| 2 +
> drivers/gpu/drm/i915/i915_debugfs.c | 4 +
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/i915_gem.c | 4 +
> drivers/gpu/drm/i915/i915_perf.c | 8 +-
> drivers/gpu/drm/i915/i915_pmu.c | 11 +-
> drivers/gpu/drm/i915/i915_query.c | 21 +-
> 37 files changed, 643 insertions(+), 193 deletions(-)
>
> --
> 2.45.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ll _arm that it becomes a real fence.
I think just renaming _arm to _init, so that we follow the standard naming
pattern for splitting _create() into kzalloc and everything else is all
that's needed here?
Plus updating the kernel doc to make it really clear that _alloc doesn't
give you
ivate
> *i915)
> err_object:
> kobject_put(kobj);
> err_engine:
> - dev_err(kdev, "Failed to add sysfs engine '%s'\n",
> - engine->name);
> - break;
> +
What we perhaps could do is register a driver lockdep key (which is
static), that runtime pm core code could optionally use when set?
Hm, thinking about this some more, if we embed this in struct
device_driver when it's statically created, this could work perhaps
automatically?
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[machine died, new one working now, I can read complicated mails again an
answer.]
On Thu, Aug 22, 2024 at 03:19:29PM +0200, Christian König wrote:
> Am 22.08.24 um 11:23 schrieb Daniel Vetter:
> > On Wed, Aug 21, 2024 at 10:14:34AM +0200, Christian König wrote:
> > > Am 20.08.2
On Thu, Aug 22, 2024 at 07:32:15PM +0300, Jani Nikula wrote:
> On Mon, 24 Jun 2024, Daniel Vetter wrote:
> > On Tue, May 14, 2024 at 03:55:15PM +0300, Jani Nikula wrote:
> >> Prefer the struct drm_edid based functions for reading the EDID and
> >> updating the connecto
y 2024 14:01:19 +0200
> Daniel Vetter wrote:
>
> > On Mon, May 20, 2024 at 02:01:48PM +0200, Luca Ceresoli wrote:
> > > Hello Daniel,
> > >
> > > On Thu, 16 May 2024 15:22:01 +0200
> > > Daniel Vetter wrote:
> > >
> > > > Ap
On Mon, Aug 26, 2024 at 04:15:26PM -0400, Alex Deucher wrote:
> Hi Dave, Sima,
>
> New stuff for 6.12.
>
> The following changes since commit 627a24f5f25d689682f395f3df1411273be4436b:
>
> Merge tag 'amd-drm-fixes-6.11-2024-07-18' of
> https://gitlab.freedesktop.org/agd5f/linux into drm-next (
| 5 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
> drivers/gpu/drm/i915/i915_mm.c | 12 +++-
> drivers/gpu/drm/i915/i915_mm.h | 3 +-
> drivers/gpu/drm/i915/i915_perf.c | 33 --
> drivers/gpu/drm/i915/intel_memory_region.c | 6 +-
> drivers/gpu/drm/i915/intel_uncore.c| 7 ++-
> .../gpu/drm/i915/selftests/intel_memory_region.c | 2 +-
> 23 files changed, 150 insertions(+), 81 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-
> drivers/gpu/drm/xe/xe_pci.c | 10 +-
> drivers/gpu/drm/xe/xe_pm.c| 11 +-
> drivers/gpu/drm/xe/xe_preempt_fence.c | 3 +-
> drivers/gpu/drm/xe/xe_preempt_fence_types.h | 2 +
> drivers/gpu/drm/xe/xe_pt.c
gpu/drm/vc4/vc4_hdmi.c | 44 +-
> drivers/gpu/drm/vc4/vc4_hvs.c |4 +-
> drivers/gpu/drm/vc4/vc4_irq.c |2 +-
> drivers/gpu/drm/vc4/vc4_v3d.c | 24 +-
> drivers/gpu/drm/vc4/vc4_validate.c |8 +-
> drivers/gpu/drm/vc4/vc4_vec.c | 10 +-
> include/drm/drm_mipi_dsi.h |2 +
> include/linux/string.h | 12 +
> 41 files changed, 1830 insertions(+), 1478 deletions(-)
> create mode 100644 drivers/gpu/drm/ast/ast_sil164.c
> create mode 100644 drivers/gpu/drm/ast/ast_vga.c
>
> --
> 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)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
is for Xe as I
> don't want to remove force probe with an incongruence in behavior from
> the i915 or have a mesa use case broken.
I've actually gone back to the ggtt fix, and I don't see the security
aspect. Like sure if you do a partial unmap you screw up the offset
calculation and get unexpected aliasing and a mess and the igt you've
linked will fail. But I don't see how that's a security bug?
And if it is, then it's a drm wide issue, because they all work like that.
And so probably we need a drm wide fix first.
So yeah I'm still stuck on the fundamentals here of why this is even done.
And for the uapi extension of allowing partial mmaps, we need the full
uapi dance. Which means some driver flag so userspace can figure out this
is supported, and a link to the mesa MR that uses this all.
Without a link to a mesa MR this won't go anywhere, because that's the
rules for new uapi.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Aug 19, 2024 at 05:31:36PM +0200, Andi Shyti wrote:
> Hi Sima,
>
> On Mon, Aug 19, 2024 at 04:17:01PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 14, 2024 at 02:08:49AM +, Matthew Brost wrote:
> > > On Tue, Aug 13, 2024 at 07:08:02PM +, Matthew Brost wrote
ay drivers can assume that all bo have been swapped out from vram
already, and there's no need to acquire bo or ttm locks in the suspend
path that could block the resume path.
Which would then allow unconditional runtime_pm_get in the shrinker paths.
Unfortunately this will be all really tricky to implement and I think
needs to be done in the rumtime pm core.
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
> drivers/gpu/drm/vkms/vkms_drv.c| 6 +-
> drivers/gpu/vga/vga_switcheroo.c | 3 +-
> include/drm/drm_drv.h | 28 ---
> include/drm/drm_edid.h | 2 -
> include/drm/drm_fb_helper.h| 6 -
> include/drm/drm_fixed.h| 3 +-
> include/drm/drm_mipi_dsi.h | 10 ++
> include/drm/drm_mode_config.h | 16 --
> include/drm/drm_panic.h| 21 +--
> include/uapi/drm/drm_mode.h| 2 +
> 55 files changed, 471 insertions(+), 416 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)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
@@ -383,7 +376,6 @@ static void vkms_destroy(struct vkms_config *config)
>
> drm_dev_unregister(&config->dev->drm);
> drm_atomic_helper_shutdown(&config->dev->drm);
> - devres_release_group(&pdev->dev, NULL);
> platform_device_unregister(pdev);
>
> config->dev = NULL;
>
> --
> 2.44.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
actually as drm-resident.
> > >
> > > Signed-off-by: Tvrtko Ursulin
> > > Cc: Alex Deucher
> > > Cc: Christian König
> > > Cc: Rob Clark
> >
> > Reviewed-by: Rob Clark
>
> Thanks!
>
> So this one is stand alone and cou
On Wed, Aug 14, 2024 at 02:08:49AM +, Matthew Brost wrote:
> On Tue, Aug 13, 2024 at 07:08:02PM +, Matthew Brost wrote:
> > On Tue, Aug 13, 2024 at 04:09:55PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 13, 2024 at 02:54:31AM +, Matthew Brost wrote:
> > > &
asically all the restartable LRU work was motivated by this use-
> case in mind, so making that private I must say comes as a pretty major
> surprise.
>
> I could have a look at the
>
> for_each_bo_on_lru_locked(xxx)
> driver_shrink();
>
> approach, but having TTM just blindly return a single bo without
> context will not work IMO.
Another thing to keep in mind is that at least experience from really
resource-starved igpu platforms says that cpu consumption for shrinking
matters. So really need to not toss list walk state, and also at least
from I think msm experience and maybe also i915 (i915-gem's a bit ... too
complex to really understand it anymore) is that parallelism matters too.
Eventually under memory pressures multiple cpu cores just aboslutely
hammer the shrinkers, so being stuck on locks is no good.
But maybe let's get this off the ground first.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Aug 15, 2024 at 03:55:30PM +0300, Jani Nikula wrote:
> On Mon, 24 Jun 2024, Daniel Vetter wrote:
> > On Tue, May 14, 2024 at 03:55:08PM +0300, Jani Nikula wrote:
> >> Prefer the struct drm_edid based functions for reading the EDID and
> >> updating the connector
;s not easily achievable
> > in all cases.
> >
> > Signed-off-by: Thomas Hellström
>
> Resurrecting the discussion on this one. I can't see a situation where we
> would miss *relevant* locking
> order violation warnings with this patch. Ofc if we have a scheduler
&g
On Tue, Aug 13, 2024 at 02:54:31AM +, Matthew Brost wrote:
> On Mon, Aug 12, 2024 at 04:45:32PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 12, 2024 at 01:51:30PM +0200, Andi Shyti wrote:
> > > Hi Daniel,
> > >
> > > On Mon, Aug 12, 2024 at 11:11:21AM +0
On Mon, Aug 12, 2024 at 01:51:30PM +0200, Andi Shyti wrote:
> Hi Daniel,
>
> On Mon, Aug 12, 2024 at 11:11:21AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 09, 2024 at 11:20:56AM +0100, Andi Shyti wrote:
> > > On Fri, Aug 09, 2024 at 10:53:38AM +0200, Daniel Vetter wrote
On Mon, Aug 12, 2024 at 12:41:39PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 12.08.24 um 12:18 schrieb Daniel Vetter:
> > On Mon, Aug 12, 2024 at 11:23:44AM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote:
> &g
On Mon, Aug 12, 2024 at 11:23:44AM +0200, Daniel Vetter wrote:
> On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote:
> > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from
> > their lastclose callbacks. Call it from drm_lastclose(), so that the
>
On Mon, Aug 12, 2024 at 10:28:28AM +0200, Thomas Zimmermann wrote:
> The function is unused. Remove it.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 15 ---
> include/drm/drm_fb_helper.h | 6
On Mon, Aug 12, 2024 at 10:28:27AM +0200, Thomas Zimmermann wrote:
> The old callbacks lastclose and output_poll_changed are deprecated and
> unused. Remove them from the documentation.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/d
e().
>
> v2:
> - update commit description
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
> drivers/gpu/drm/nouveau/nouveau_vga.c | 7 ---
> drivers/gpu/drm/nouveau/nouveau_vga.h | 1 -
>
rm_lastclose().
>
> v2:
> - update commit message
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 17 -
still a midlayer mess,
where the locking is at the wrong layers resulting in the can_switch check
potentially being racy. But that's a different can of worms.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_file.c | 4
> drivers/gpu/vga/vga_switcheroo.c | 3 +--
&
>
> /**
> * struct drm_plane_size_hint - Plane size hints
> + * @width: The width of the plane in pixel
> + * @height: The height of the plane in pixel
> *
> * The plane SIZE_HINTS property blob contains an
> * array of struct drm_plane_size_hint.
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Aug 09, 2024 at 11:20:56AM +0100, Andi Shyti wrote:
> Hi Sima,
>
> On Fri, Aug 09, 2024 at 10:53:38AM +0200, Daniel Vetter wrote:
> > On Wed, Aug 07, 2024 at 11:05:19AM +0100, Andi Shyti wrote:
> > > This patch series concludes on the memory mapping fixes a
t_description() (Sima)
> * Add drm_panic_clear_description() to make sure the stack allocated pointer
> won't be used. (Sima)
> * use the macro PANIC_MSG_LINES also in draw_panic_static_user()
Reviewed-by: Daniel Vetter
>
> drivers/gpu/drm/drm_panic.c | 56
/drm/i915/gem/i915_gem_mman.c | 10 ++
> drivers/gpu/drm/i915/i915_mm.c | 12 +++-
> drivers/gpu/drm/i915/i915_mm.h | 3 ++-
> 3 files changed, 19 insertions(+), 6 deletions(-)
>
> --
> 2.45.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_helper_hotplug_event()
> - * to call this hook to inform the fbdev helper of output changes.
> - *
> - * This hook is deprecated, drivers should instead implement fbdev
> - * support with struct drm_client, which takes care of any necessary
> - * hotplug
On Wed, Aug 07, 2024 at 10:41:38AM +0200, Thomas Zimmermann wrote:
> The function is unused. Remove it.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Without the next patch to remove ->lastclose there's some confusion text
left in the DOC: section in drm_fb
ermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_vga.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
> b/drivers/gpu/drm/nouveau/nouveau_vga.c
> index ee637f1fe03d..ab4e11dc0b
ebuffer_create(struct drm_device *dev,
>
> static const struct drm_mode_config_funcs nouveau_mode_config_funcs = {
> .fb_create = nouveau_user_framebuffer_create,
> - .output_poll_changed = drm_fb_helper_output_poll_changed,
> };
>
>
> --
> 2.46.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
his, it needs to be in drm core. Otherwise
the vgaswitcheroo delayed switching stops working if you disable fbdev
support. Which doesn't make much sense.
-Sima
> +
> }
> EXPORT_SYMBOL(drm_fb_helper_lastclose);
>
> --
> 2.46.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
rences instead of TTMs
>
> Christoph Fritz (1):
> drm/bridge: synopsys: dw-mipi-dsi: enable EoTp by default
>
> Christophe JAILLET (1):
> drm/stm: Fix an error handling path in stm_drm_platform_probe()
>
> Claudiu Beznea (1):
> drm/stm: ltdc: check m
long that even on
a 4k panel with a small font it will overflow. I worry otherwise that
there will be a bug in that logic, taking down the machine at the worst
possible moment ...
Reminds me, I think a bunch of kunit testcases to make sure the drm panic
code is absolutely solid (there's a bunch of math in there after all)
would be really good to add.
Cheers, Sima
> }
> return count;
> }
> --
> 2.45.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jul 23, 2024 at 11:11:33AM +0200, Jocelyn Falempe wrote:
> Move the copyright notice to the top of drm_panic.h, and add the
> missing Red Hat copyright notice.
>
> Suggested-by: Thomas Zimmermann
> Signed-off-by: Jocelyn Falempe
Patches 1-4 are Reviewed-by: Daniel Vetter
On Tue, Aug 06, 2024 at 04:09:43PM +0200, Maxime Ripard wrote:
> On Tue, Aug 06, 2024 at 03:01:44PM GMT, Daniel Vetter wrote:
> > On Mon, Jul 01, 2024 at 06:01:41PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 01/07/2024 10:25, Maarten Lankhorst wrote:
> > &g
gt; Would these make different cgroup devices, or different cgroup regions?
> >
> > Each driver would register a device, whatever feels most logical for that
> > device I suppose.
> >
> > My guess is that a prefix would also be nice here, so register a device
> > with name of drm/$name or v4l2/$name, heap/$name. I didn't give it much
> > thought and we're still experimenting, so just try something. :)
> >
> > There's no limit to amount of devices, I only fixed amount of pools to
> > match TTM, but even that could be increased arbitrarily. I just don't think
> > there is a point in doing so.
>
> Do we need a plan for top level controls which do not include region names?
> If the latter will be driver specific then I am thinking of ease of
> configuring it all from the outside. Especially considering that one cgroup
> can have multiple devices in it.
>
> Second question is about double accounting for shmem backed objects. I think
> they will be seen, for drivers which allocate backing store at buffer
> objects creation time, under the cgroup of process doing the creation, in
> the existing memory controller. Right?
We currently don't set __GFP_ACCOUNT respectively use GFP_KERNEL_ACCOUNT,
so no. Unless someone allocates them with GFP_USER ...
> Is there a chance to exclude those from there and only have them in this new
> controller? Or would the opposite be a better choice? That is, not see those
> in the device memory controller but only in the existing one.
I missed this, so jumping in super late. I think guidance from Tejun was
to go the other way around: Exclude allocations from normal system
memory from device cgroups and instead make sure it's tracked in the
existing memcg.
Which might mean we need memcg shrinkers and the assorted pain ...
Also I don't think we ever reached some agreement on where things like cma
allocations should be accounted for in this case.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ro on success, error code on failure.
> */
> @@ -474,6 +476,8 @@ EXPORT_SYMBOL(drmm_connector_init);
> *
> * The connector structure should be allocated with drmm_kzalloc().
> *
> + * The @drm_connector_funcs.destroy hook must be NULL.
> + *
> * Returns:
> * Ze
On Thu, Aug 01, 2024 at 10:53:45AM +0800, Huan Yang wrote:
>
> 在 2024/8/1 4:46, Daniel Vetter 写道:
> > On Tue, Jul 30, 2024 at 08:04:04PM +0800, Huan Yang wrote:
> > > 在 2024/7/30 17:05, Huan Yang 写道:
> > > > 在 2024/7/30 16:56, Daniel Vetter 写道:
> >
rs/gpu/drm/drm_connector.c | 34
> > +++++++
> > include/drm/drm_connector.h | 2 ++
> > 3 files changed, 42 insertions(+)
> > ---
> > base-commit: 36821612eb3091a21f7f4a907b497064725080c3
> > change-id: 20240610-amdgpu-min-backlight-quirk-8402fd8e736a
> >
> > Best regards,
>
> --
> Jani Nikula, Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
n to delete this line too?
Otherwise lgtm.
-Sima
> - return ret;
> + goto err;
> + }
> +
> + udmabuf_folio_cachep = KMEM_CACHE(udmabuf_folio, 0);
> + if (unlikely(!udmabuf_folio_cachep)) {
> + ret = -ENOMEM;
> + goto err;
>
On Tue, Jul 30, 2024 at 08:04:04PM +0800, Huan Yang wrote:
>
> 在 2024/7/30 17:05, Huan Yang 写道:
> >
> > 在 2024/7/30 16:56, Daniel Vetter 写道:
> > > [? daniel.vet...@ffwll.ch ?
> > > https://aka.ms/LearnAboutSenderIdentification?]
>
On Tue, Jul 30, 2024 at 02:06:08PM +0200, Christian König wrote:
> Am 30.07.24 um 10:36 schrieb Daniel Vetter:
> > > In the end you have a really nice circle dependency.
> > Maybe a follow up, so for arb robustness or vk context where we want the
> > context to die and r
, but might not be too
bad.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
e/linux/dma-heap.h
> F: include/uapi/linux/dma-heap.h
> +F: tools/testing/selftests/dmabuf-heaps/
>
> DMC FREQUENCY DRIVER FOR SAMSUNG EXYNOS5422
> M: Lukasz Luba
> --
> 2.33.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
disable polling must be strictly ordered,
> which
> * is automatically the case when they're only call from suspend/resume
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Jul 29, 2024 at 08:43:05PM +0200, Christian König wrote:
> Am 26.07.24 um 16:21 schrieb Daniel Vetter:
> > On Fri, Jul 26, 2024 at 09:55:50AM +0200, Christian König wrote:
> > > The current implementation of drm_sched_start uses a hardcoded
> > > -ECANCELED t
On Mon, Jul 29, 2024 at 02:34:25PM -0400, Lyude Paul wrote:
> On Fri, 2024-07-26 at 15:40 +0200, Daniel Vetter wrote:
> > On Thu, Jul 25, 2024 at 03:35:18PM -0400, Lyude Paul wrote:
> > > On Tue, 2024-07-16 at 11:25 +0200, Daniel Vetter wrote:
> > > > On Mon, Ju
1 - 100 of 3280 matches
Mail list logo
