ill work, but more a list of extensions that
> > conceivably could work. Normally this should just a matter of the
> > kernel unconditionally adding the newly implemented extension to the
> > list returned in the query call.
> >
> > If a GET_PARAM can be made for the PXP case, then it seems like a
> > query item returning CONTEXT_CREATE extensions could conditionally
> > omit that extension just as easily as implementing the proposed new
> > GET_PARAM.
> >
> > -Jordan
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
o, fb);
>
> /*
>* fb_pan_display() validates this, but fb_set_par() doesn't and just
> @@ -2066,7 +2068,7 @@ static void drm_fb_helper_fill_var(struct fb_info *info,
> info->pseudo_palette = fb_helper->pseudo_palette;
> info->var.xoffset = 0;
>
On Wed, Apr 19, 2023 at 09:30:11AM -0700, Nathan Chancellor wrote:
> On Wed, Apr 19, 2023 at 06:24:37PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 18, 2023 at 07:34:44PM +0100, Mark Brown wrote:
> > > On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote:
&
gt; I may slow to reply, but I really love to reply.
>
>
> On 2023/4/19 23:09, Daniel Vetter wrote:
> > On Tue, 18 Apr 2023 at 20:16, Sui Jingfeng <15330273...@189.cn> wrote:
> > > Hi,
> > >
> > > On 2023/4/19 01:52, Sui Jingfeng wrote:
> > >
On Tue, Apr 18, 2023 at 07:34:44PM +0100, Mark Brown wrote:
> On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote:
>
> > Note there was a ppc compile fail, which is why we pushed the ttm revert.
> > That /should/ be fixed now, but would be good if you can confi
On Tue, 18 Apr 2023 at 20:16, Sui Jingfeng <15330273...@189.cn> wrote:
>
> Hi,
>
> On 2023/4/19 01:52, Sui Jingfeng wrote:
> > Hi,
> >
> > On 2023/4/18 16:32, Daniel Vetter wrote:
> >> On Mon, Apr 17, 2023 at 07:32:19PM +0800, Sui Jingfeng wrote:
&g
On Wed, Apr 05, 2023 at 09:29:02PM +0200, Daniel Vetter wrote:
> On Wed, Apr 05, 2023 at 05:43:01PM +0200, Daniel Vetter wrote:
> > On Tue, Mar 07, 2023 at 11:25:37PM +0900, Asahi Lina wrote:
> > > +/// An armed DRM scheduler job (not yet submitted)
> > > +pub struct A
w the format that the other
> definitions follow.
>
> Signed-off-by: Patrick McLean
Acked-by: Daniel Vetter
for merging through whatever tree this series lands through.
-Daniel
> ---
> drivers/gpu/drm/ast/ast_drv.c | 4 +---
> include/linux/pci_ids.h | 2 ++
> 2 files chan
comm: Overridden task comm, see MSM_PARAM_COMM
> > *
> > -* Accessed under msm_gpu::lock
> > + * Accessed under msm_file_private::lock
> > */
> > char *comm;
> > /**
> > * cmdline: Overridden task cmdline, see MSM_PARAM_CMDLINE
> > *
> > -* Accessed under msm_gpu::lock
> > +* Accessed under msm_file_private::lock
> > */
> > char *cmdline;
> > diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> > b/drivers/gpu/drm/msm/msm_submitqueue.c
> > index 0e803125a325..0444ba04fa06 100644
> > --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> > +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> > @@ -61,6 +61,7 @@ void __msm_file_private_destroy(struct kref *kref)
> > }
> > msm_gem_address_space_put(ctx->aspace);
> > + put_pid(ctx->pid);
> > kfree(ctx->comm);
> > kfree(ctx->cmdline);
> > kfree(ctx);
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
fb->height * helper->fb->pitches[0];
max_off = min(max_off, total_size);
if (min_off < max_off) {
I think that would make it utmost clear on what we're doing and why.
Otherwise we're just going to re-create the same bug again, like we've
done already :-)
-Daniel
> screen_buffer = vzalloc(screen_size);
> if (!screen_buffer) {
> ret = -ENOMEM;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
tion/pvr_rogue_mips_check.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_rogue_mmu_defs.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_stream.c
> create mode 100644 drivers/gpu/drm/imagination/pvr_stream.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_stream_defs.c
> create mode 100644 drivers/gpu/drm/imagination/pvr_stream_defs.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_vendor.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_vm.c
> create mode 100644 drivers/gpu/drm/imagination/pvr_vm.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_vm_mips.c
> create mode 100644 drivers/gpu/drm/imagination/pvr_vm_mips.h
> create mode 100644 drivers/gpu/drm/imagination/vendor/pvr_mt8173.c
> create mode 100644 include/uapi/drm/pvr_drm.h
>
> --
> 2.40.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
b..b057cfbba938 100644
> > > > --- a/drivers/gpu/drm/drm_fbdev_generic.c
> > > > +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> > > > @@ -94,7 +94,7 @@ static int
> > > > drm_fbdev_generic_helper_fb_probe(struct drm_fb_helper
> > > > *fb_helper,
> > > > fb_helper->buffer = buffer;
> > > > fb_helper->fb = buffer->fb;
> > > > - screen_size = buffer->gem->size;
> > > > + screen_size = sizes->surface_height * buffer->fb->pitches[0];
>
> This has been bothering me over the weekend. And I think it's because what
> we want the screen_size to be heigth * pitch, but the mmap'ed memory is
> still at page granularity. Therefore...
>
> [...]
> > >
> > > > screen_buffer = vzalloc(screen_size);
>
> ... this line should explicitly allocate multiples of pages. Something like
>
> /* allocate page-size multiples for mmap */
> vzalloc(PAGE_ALIGN(screen_size))
>
> It has not been a bug so far because vzalloc() always returns full pages
> IIRC. It's still worth fixing.
So gem_bo are supposed to be at least PAGE_SIZE aligned. So maybe we just
put a comment in here why this assumption holds, and reinforce it with a
WARN_ON? I think that would address the concerns here?
But I concur with Sui that this is a separate issue which should be sorted
out in a separate patch.
-Daniel
>
> Best regards
> Thomas
>
>
> > > > if (!screen_buffer) {
> > > > ret = -ENOMEM;
> > >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Apr 17, 2023 at 08:47:19AM +0200, Christian König wrote:
> Am 11.04.23 um 16:13 schrieb Daniel Vetter:
> > On Tue, Apr 11, 2023 at 11:02:55AM +0200, Christian König wrote:
> > > The point is that this not only requires some work in the drm_scheduler,
> > > but
l, which is why we pushed the ttm revert.
That /should/ be fixed now, but would be good if you can confirm?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
.bits_per_pixel);
> > > diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
> > > b/drivers/gpu/drm/drm_fbdev_generic.c
> > > index 8e5148bf40bb..b057cfbba938 100644
> > > --- a/drivers/gpu/drm/drm_fbdev_generic.c
> > > +++ b/drivers/gpu/drm/drm_fbdev_generic
On Fri, Apr 14, 2023 at 07:30:53PM +0800, Sui Jingfeng wrote:
> Hi,
>
> On 2023/4/14 15:56, Daniel Vetter wrote:
> > On Fri, 14 Apr 2023 at 09:34, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 14.04.23 um 07:36 schrieb Daniel Vetter:
> >
On Fri, Apr 14, 2023 at 06:40:27AM -0700, Rob Clark wrote:
> On Fri, Apr 14, 2023 at 1:57 AM Tvrtko Ursulin
> wrote:
> >
> >
> > On 13/04/2023 21:05, Daniel Vetter wrote:
> > > On Thu, Apr 13, 2023 at 05:40:21PM +0100, Tvrtko Ursulin wrote:
> > >>
&g
This
> patch eliminates
> interference from work items outside of i915, which is small but an
> improvement for i915 users.
I think if someone from i915 team triple-checks that i915 really doesn't
use any of the drm workers (hotplug handling, atomic commit, ...) then I
think we should be
On Fri, 14 Apr 2023 at 10:57, Tvrtko Ursulin
wrote:
> On 13/04/2023 21:05, Daniel Vetter wrote:
> > On Thu, Apr 13, 2023 at 05:40:21PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 13/04/2023 14:27, Daniel Vetter wrote:
> >>> On Thu, Apr 13, 2023 at
On Fri, 14 Apr 2023 at 09:34, Thomas Zimmermann wrote:
>
> Hi
>
> Am 14.04.23 um 07:36 schrieb Daniel Vetter:
> > On Fri, 14 Apr 2023 at 06:24, Sui Jingfeng <15330273...@189.cn> wrote:
> >>
> >> Hi,
> >>
> >> On 2023/4/14 04:01, Daniel
On Fri, 14 Apr 2023 at 06:24, Sui Jingfeng <15330273...@189.cn> wrote:
>
> Hi,
>
> On 2023/4/14 04:01, Daniel Vetter wrote:
> > On Thu, Apr 13, 2023 at 09:20:23PM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 13.04.23 um 20:56 schrieb
On Thu, Apr 13, 2023 at 05:40:21PM +0100, Tvrtko Ursulin wrote:
>
> On 13/04/2023 14:27, Daniel Vetter wrote:
> > On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 12/04/2023 20:18, Daniel Vetter wrote:
> > > > On Wed, A
On Thu, Apr 13, 2023 at 09:20:23PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.04.23 um 20:56 schrieb Daniel Vetter:
> [...]
> >
> > This should switch the existing code over to using drm_framebuffer instead
> > of fbdev:
> >
> >
> > dif
Asahi Lina (1):
drm/scheduler: Fix UAF race in drm_sched_entity_push_job()
Christophe JAILLET (1):
drm/armada: Fix a potential double free in an error handling path
Daniel Vetter (6):
fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
Merge tag 'amd-drm-fixes
or
>
>
> Asahi Lina (1):
> drm/scheduler: Fix UAF race in drm_sched_entity_push_job()
>
> Christophe JAILLET (1):
> drm/armada: Fix a potential double free in an error handling path
>
> Daniel Vette
On Fri, Apr 14, 2023 at 01:00:07AM +0800, Sui Jingfeng wrote:
>
> On 2023/4/13 23:56, Daniel Vetter wrote:
> > On Thu, 13 Apr 2023 at 17:35, Sui Jingfeng <15330273...@189.cn> wrote:
> > > Hi,
> > >
> > > On 2023/4/13 01:44, Daniel Vetter wrote:
>
_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 19 +++
> 2 files changed, 20 insertions(+)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, 13 Apr 2023 at 17:35, Sui Jingfeng <15330273...@189.cn> wrote:
>
> Hi,
>
> On 2023/4/13 01:44, Daniel Vetter wrote:
> > On Thu, Apr 13, 2023 at 01:13:37AM +0800, Sui Jingfeng wrote:
> >> Hi,
> >>
> >> On 2023/4/11 22:53, Daniel Vetter wr
On Thu, Apr 13, 2023 at 11:34:45AM +0200, Christian König wrote:
> Am 12.04.23 um 17:11 schrieb Daniel Vetter:
> > On Wed, Apr 12, 2023 at 04:52:04PM +0200, Christian König wrote:
> > > The mutex was completely pointless in the first place since any
> > > parallel a
On Thu, Apr 13, 2023 at 01:58:34PM +0100, Tvrtko Ursulin wrote:
>
> On 12/04/2023 20:18, Daniel Vetter wrote:
> > On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> > > On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter wrote:
> > > >
> > > >
On Thu, 13 Apr 2023 at 11:46, Christian König wrote:
>
> Am 13.04.23 um 10:48 schrieb Daniel Vetter:
> > On Wed, 12 Apr 2023 at 16:18, Christian König
> > wrote:
> >> Am 12.04.23 um 11:08 schrieb Daniel Vetter:
> >>> On Tue, 11 Apr 2023 at 15:45, Dani
+
>
>
> Jani Nikula (1):
> drm/i915/dsi: fix DSS CTL register offsets for TGL+
>
> drivers/gpu/drm/i915/display/icl_dsi.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
>
Some($cmd)
> +},
> +flags: $flags,
> +name:
> $crate::c_str!(::core::stringify!($cmd)).as_char_ptr(),
> +}
> +),*];
> +ioctls
> +};
> +};
> +}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> new file mode 100644
> index ..9ec6d7cbcaf3
> --- /dev/null
> +++ b/rust/kernel/drm/mod.rs
> @@ -0,0 +1,5 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +//! DRM subsystem abstractions.
> +
> +pub mod ioctl;
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index 7903490816bf..cb23d24c6718 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -37,6 +37,8 @@ mod build_assert;
> pub mod delay;
> pub mod device;
> pub mod driver;
> +#[cfg(CONFIG_RUST_DRM)]
> +pub mod drm;
> pub mod error;
> pub mod io_buffer;
> pub mod io_mem;
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_fence_signal {
>
> /* Note: this is an enum so that it can be resolved by Rust bindgen. */
> enum {
> + DRM_IOCTL_VGEM_DUMMY= DRM_IOW(DRM_COMMAND_BASE +
> DRM_VGEM_DUMMY, struct drm_vgem_dummy),
> DRM_IOCTL_VGEM_FENCE_ATTACH = DRM_IOWR(DRM_COMMAND_BASE +
> DRM_VGEM_FENCE_ATTACH, s
On Tue, Apr 11, 2023 at 05:25:47PM +0200, Helge Deller wrote:
> On 4/11/23 16:36, Daniel Vetter wrote:
> > On Fri, Apr 07, 2023 at 10:54:00PM +0200, Helge Deller wrote:
> > > On 4/6/23 15:21, Thomas Zimmermann wrote:
> > > > From: Daniel Vetter
> > > &g
change before the uAPI gets exposed to avoid making a mistake. QAIC is
> > otherwise still functional.
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Jeffrey Hugo
> > Reviewed-by: Pranjal Ramajor Asha Kanojiya
>
> Acked-by: Greg Kroah-Hartman
&
the
> > change before the uAPI gets exposed to avoid making a mistake. QAIC is
> > otherwise still functional.
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Jeffrey Hugo
> > Reviewed-by: Pranjal Ramajor Asha Kanojiya
> Reviewed-by: Stanislaw Gruszka
On Wed, 12 Apr 2023 at 16:18, Christian König wrote:
>
> Am 12.04.23 um 11:08 schrieb Daniel Vetter:
> > On Tue, 11 Apr 2023 at 15:45, Daniel Vetter wrote:
> >> On Tue, Apr 11, 2023 at 02:11:18PM +0200, Christian König wrote:
> >>> Am 11.04.23 um 11:51 schrieb
date drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo
> >
> > Reviewed-by: Daniel Vetter
> > Signed-off-by: Rob Clark
> > ---
> > Documentation/gpu/drm-usage-stats.rst | 10 +++-
> > drivers/gpu/drm/drm_file.c| 35 +
e_payload
>
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 57 --
> drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 6 ++
> .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 4 +-
> .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 87
> ++
On Wed, Apr 12, 2023 at 11:42:07AM -0700, Rob Clark wrote:
> On Wed, Apr 12, 2023 at 11:17 AM Daniel Vetter wrote:
> >
> > On Wed, Apr 12, 2023 at 10:59:54AM -0700, Rob Clark wrote:
> > > On Wed, Apr 12, 2023 at 7:42 AM Tvrtko Ursulin
> > > wrote:
> > >
mode,
> void fb_videomode_to_var(struct fb_var_screeninfo *var,
> const struct fb_videomode *mode)
> {
> + if (!mode)
> + return;
> var->xres = mode->xres;
> var->yres = mode->yres;
> var->xres_virtual = mode->xres;
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> file *f)
> > >
> > > if (dev->driver->show_fdinfo)
> > > dev->driver->show_fdinfo(, file);
> > > +
> > > + print_memory_stats(, file);
> > > }
> > > EXPORT_SYMBOL(drm_fop_show_fdinfo);
> > >
> > > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> > > index dfa995b787e1..e5b40084538f 100644
> > > --- a/include/drm/drm_file.h
> > > +++ b/include/drm/drm_file.h
> > > @@ -41,6 +41,7 @@
> > > struct dma_fence;
> > > struct drm_file;
> > > struct drm_device;
> > > +struct drm_printer;
> > > struct device;
> > > struct file;
> > >
> > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > index 189fd618ca65..213917bb6b11 100644
> > > --- a/include/drm/drm_gem.h
> > > +++ b/include/drm/drm_gem.h
> > > @@ -42,6 +42,14 @@
> > > struct iosys_map;
> > > struct drm_gem_object;
> > >
> > > +/**
> > > + * enum drm_gem_object_status - bitmask of object state for fdinfo
> > > reporting
> > > + */
> > > +enum drm_gem_object_status {
> > > + DRM_GEM_OBJECT_RESIDENT = BIT(0),
> > > + DRM_GEM_OBJECT_PURGEABLE = BIT(1),
> > > +};
> > > +
> > > /**
> > >* struct drm_gem_object_funcs - GEM object functions
> > >*/
> > > @@ -174,6 +182,17 @@ struct drm_gem_object_funcs {
> > >*/
> > > int (*evict)(struct drm_gem_object *obj);
> > >
> > > + /**
> > > + * @status:
> > > + *
> > > + * The optional status callback can return additional object state
> > > + * which determines which stats the object is counted against. The
> > > + * callback is called under table_lock. Racing against object
> > > status
> > > + * change is "harmless", and the callback can expect to not race
> > > + * against object destruction.
> > > + */
> > > + enum drm_gem_object_status (*status)(struct drm_gem_object *obj);
> >
> > Does this needs to be in object funcs and couldn't be consolidated to
> > driver level?
> >
> > Regards,
> >
> > Tvrtko
> >
> > > +
> > > /**
> > >* @vm_ops:
> > >*
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Apr 12, 2023 at 04:12:41PM +0100, Tvrtko Ursulin wrote:
>
> On 12/04/2023 14:51, Daniel Vetter wrote:
> > On Wed, Apr 12, 2023 at 01:32:43PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 11/04/2023 23:56, Rob Clark wrote:
> > > > From: Rob Clark
On Thu, Apr 13, 2023 at 01:13:37AM +0800, Sui Jingfeng wrote:
> Hi,
>
> On 2023/4/11 22:53, Daniel Vetter wrote:
> > On Sun, Apr 09, 2023 at 09:21:10PM +0800, Sui Jingfeng wrote:
> > > From: Sui Jingfeng
> > >
> > > We should setting the screen bu
it a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 3cf12b14232d..c490977ee250 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -318,21 +318,6 @@ struct drm_device {
>*/
> struct dentry *debugfs_root;
>
> - /**
> - * @debugfs_mutex:
> - *
> - * Protects _list access.
> - */
> - struct mutex debugfs_mutex;
> -
> - /**
> - * @debugfs_list:
> - *
> - * List of debugfs files to be created by the DRM device. The files
> - * must be added during drm_dev_register().
> - */
> - struct list_head debugfs_list;
> -
> /* Everything below here is for legacy driver, never use! */
> /* private: */
> #if IS_ENABLED(CONFIG_DRM_LEGACY)
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
uAPI gets exposed to avoid making a mistake. QAIC is
> > otherwise still functional.
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Jeffrey Hugo
> > Reviewed-by: Pranjal Ramajor Asha Kanojiya
> > ---
>
> Daniel,
>
> Assuming you find th
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 5 -
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 45 +++-
> drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 35 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 6 -
> 21 files changed, 465 insertions(+), 303 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
> delete mode 100644
> Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
lass(p, client, i);
> > }
> > #endif
> > diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
> > b/drivers/gpu/drm/i915/i915_drm_client.h
> > index 69496af996d9..ef85fef45de5 100644
> > --- a/drivers/gpu/drm/i915/i915_drm_client.h
> > +++ b/drivers/gpu/drm/i915/i915_drm_client.h
> > @@ -60,7 +60,7 @@ static inline void i915_drm_client_put(struct
> > i915_drm_client *client)
> > struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients
> > *clients);
> > #ifdef CONFIG_PROC_FS
> > -void i915_drm_client_fdinfo(struct seq_file *m, struct file *f);
> > +void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file);
> > #endif
> > void i915_drm_clients_fini(struct i915_drm_clients *clients);
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, 11 Apr 2023 at 15:45, Daniel Vetter wrote:
>
> On Tue, Apr 11, 2023 at 02:11:18PM +0200, Christian König wrote:
> > Am 11.04.23 um 11:51 schrieb Daniel Vetter:
> > > On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote:
> > > > When swappi
On Wed, Apr 12, 2023 at 02:47:52PM +0900, Asahi Lina wrote:
> On 11/04/2023 23.07, Daniel Vetter wrote:
> > On Sat, Apr 08, 2023 at 04:05:20PM +0900, Asahi Lina wrote:
> > > On 04/04/2023 10.58, Matthew Brost wrote:
> > > > On Tue, Apr 04, 2023 at 10:07:48AM +0900,
On Wed, Apr 12, 2023 at 01:36:52AM +0300, Dmitry Baryshkov wrote:
> On 11/04/2023 21:28, Rob Clark wrote:
> > On Tue, Apr 11, 2023 at 10:36 AM Dmitry Baryshkov
> > wrote:
> > >
> > > On Tue, 11 Apr 2023 at 20:13, Rob Clark wrote:
> > > >
> >
Otherwise core changes don't get noticed by the right people. I
noticed this because a patch set from Jagan Teki seems to have fallen
through the cracks.
Signed-off-by: Daniel Vetter
Cc: Jagan Teki
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
size.resident += obj->size;
> + } else {
> + /* If already purged or not yet backed by pages, don't
> + * count it as purgeable:
> + */
> + s &= ~DRM_GEM_OBJECT_PURGEABLE
nfo,
> };
>
> static const struct drm_driver etnaviv_drm_driver = {
> @@ -529,6 +526,7 @@ static const struct drm_driver etnaviv_drm_driver = {
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = etnaviv_debugfs_init,
> #endif
> + .show_fdinfo= etnaviv_fop_show_fdinfo,
> .ioctls = etnaviv_ioctls,
> .num_ioctls = DRM_ETNAVIV_NUM_IOCTLS,
> .fops = ,
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
m-engine-%s:\t%Ld ns\n", amdgpu_ip_name[hw_ip],
> ktime_to_ns(usage[hw_ip]));
> }
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
> index e86834bfea1d..0398f5a159ef 100644
> --- a/d
below, with those
addressed:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_file.c | 39 ++
> include/drm/drm_drv.h | 7 +++
> include/drm/drm_file.h | 4
> 3 files changed, 50 insertions(+)
>
> diff --git a/drive
On Tue, Apr 11, 2023 at 12:37:23PM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 12:21 PM, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:
> > > On 4/11/2023 10:31 AM, Daniel Vetter wrote:
> > > > On Tue, Apr 11, 2023 at 09:29:
On Tue, Apr 11, 2023 at 08:35:48PM +0300, Dmitry Baryshkov wrote:
> On Tue, 11 Apr 2023 at 20:13, Rob Clark wrote:
> >
> > On Tue, Apr 11, 2023 at 9:53 AM Daniel Vetter wrote:
> > >
> > > On Tue, Apr 11, 2023 at 09:47:32AM -0700, Rob Clark wrote:
> > > &
On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 10:31 AM, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> > > On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> > > > On 4/11/2023 9:13 AM, Greg KH wrote:
or helpers that will be developed or modified.
>
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Oded Gabbay
> Signed-off-by: Rodrigo Vivi
> Signed-off-by: Francois Dugast
> Signed-off-by: Luis Strano
> Signed-off-by: Matthew Brost
> Signed-off-by: Thom
ats.rst | 21 +++
> > drivers/gpu/drm/drm_file.c| 79 +++
> > drivers/gpu/drm/msm/msm_drv.c | 25 -
> > drivers/gpu/drm/msm/msm_gpu.c | 2 -
> > include/drm/drm_file.h| 10
> > 5 files changed, 134 insertions(+), 3 deletions(-)
> >
> > --
> > 2.39.2
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 53 +
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 +
> > > drivers/gpu/drm/i915/i915_gpu_error.c | 130 ++
> > > drivers/gpu/drm/i915/i915_gpu_error.h | 8 ++
> > > 4 files changed, 197 insertions(+)
> > >
> > > --
> > > 2.39.1
> > >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> > On 4/11/2023 9:13 AM, Greg KH wrote:
> > > On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> > > > On 4/11/2023 9:01 AM, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 08:02:09AM -0700, Rob Clark wrote:
> On Tue, Apr 11, 2023 at 3:43 AM Daniel Vetter wrote:
> >
> > On Mon, Apr 10, 2023 at 02:06:06PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Add a helper to dump memory stats to
On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the driver-core tr
On Tue, Apr 11, 2023 at 07:55:33AM -0700, Rob Clark wrote:
> On Tue, Apr 11, 2023 at 3:27 AM Daniel Vetter wrote:
> > > Konrad Dybcio (18):
> > > drm/msm/adreno: Use OPP for every GPU generation
> >
> > This had a minor conflict with refactoring from drm-mis
e.
If otoh we need this too, then there's a few more places that need to be
fixed.
> + screen_size = sizes->surface_height * buffer->fb->pitches[0];
> +
> screen_buffer = vzalloc(screen_size);
> if (!screen_buffer) {
> ret = -ENOMEM;
Cheers, Daniel
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
TC, NULL if disabled. Do not this write directly,
> + * Currently bound CRTC, NULL if disabled. Do not write this directly,
>* use drm_atomic_set_crtc_for_plane()
>*/
> struct drm_crtc *crtc;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Apr 07, 2023 at 10:54:00PM +0200, Helge Deller wrote:
> On 4/6/23 15:21, Thomas Zimmermann wrote:
> > From: Daniel Vetter
> >
> > Since vgaarb has been promoted to be a core piece of the pci subsystem
> > we don't have to open code random guesse
On Tue, Apr 11, 2023 at 04:03:24PM +0200, Javier Martinez Canillas wrote:
> Daniel Vetter writes:
>
> > This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
> > restore") - I failed to realize that nasty userspace could set this.
> >
> > I
e submission backend
> > > > > > > > with in
> > > band
> > > > > > > > (relative to main execution function) messages. Messages are
> > > > > > > > backend
> > > > > > > > defined and flexable enough for any use case. In Xe we use these
> > > > > > > > messages to clean up entites, set properties for entites, and
> > > > > > > > suspend /
> > > > > > > > resume execution of an entity [5]. I suspect other driver can
> > > > > > > > leverage
> > > > > > > > this messaging concept too as it a convenient way to avoid
> > > > > > > > races in the
> > > > > > > > backend.
> > > > > > > >
> > > > > > > > - Support for using TDR for all error paths of a scheduler /
> > > > > > > > entity
> > > > > > > >
> > > > > > > > Fix a few races / bugs, add function to dynamically set the TDR
> > > > > > > > timeout.
> > > > > > > >
> > > > > > > > - Annotate dma-fences for long running workloads.
> > > > > > > >
> > > > > > > > The idea here is to use dma-fences only as sync points within
> > > > > > > > the
> > > > > > > > scheduler and never export them for long running workloads. By
> > > > > > > > annotating these fences as long running we ensure that these
> > > > > > > > dma-
> > > fences
> > > > > > > > are never used in a way that breaks the dma-fence rules. A
> > > > > > > > benefit of
> > > > > > > > thus approach is the scheduler can still safely flow control the
> > > > > > > > execution ring buffer via the job limit without breaking the
> > > > > > > > dma-fence
> > > > > > > > rules.
> > > > > > > >
> > > > > > > > Again this a first draft and looking forward to feedback.
> > > > > > > >
> > > > > > > > Enjoy - Matt
> > > > > > > >
> > > > > > > > [1] https://gitlab.freedesktop.org/drm/xe/kernel
> > > > > > > > [2] https://patchwork.freedesktop.org/series/112188/
> > > > > > > > [3] https://patchwork.freedesktop.org/series/114772/
> > > > > > > > [4]
> > > https://patchwork.freedesktop.org/patch/515854/?series=112188=1
> > > > > > > > [5] https://gitlab.freedesktop.org/drm/xe/kernel/-/blob/drm-xe-
> > > > > > > > next/drivers/gpu/drm/xe/xe_guc_submit.c#L1031
> > > > > > > >
> > > > > > > > Matthew Brost (8):
> > > > > > > > drm/sched: Convert drm scheduler to use a work queue rather
> > > > > > > > than
> > > > > > > > kthread
> > > > > > > > drm/sched: Move schedule policy to scheduler / entity
> > > > > > > > drm/sched: Add DRM_SCHED_POLICY_SINGLE_ENTITY scheduling
> > > policy
> > > > > > > > drm/sched: Add generic scheduler message interface
> > > > > > > > drm/sched: Start run wq before TDR in drm_sched_start
> > > > > > > > drm/sched: Submit job before starting TDR
> > > > > > > > drm/sched: Add helper to set TDR timeout
> > > > > > > > drm/syncobj: Warn on long running dma-fences
> > > > > > > >
> > > > > > > > Thomas Hellström (2):
> > > > > > > > dma-buf/dma-fence: Introduce long-running completion fences
> > > > > > > > drm/sched: Support long-running sched entities
> > > > > > > >
> > > > > > > >drivers/dma-buf/dma-fence.c | 142 +++---
> > > > > > > >drivers/dma-buf/dma-resv.c | 5 +
> > > > > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 14 +-
> > > > > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +-
> > > > > > > >drivers/gpu/drm/drm_syncobj.c | 5 +-
> > > > > > > >drivers/gpu/drm/etnaviv/etnaviv_sched.c | 5 +-
> > > > > > > >drivers/gpu/drm/lima/lima_sched.c | 5 +-
> > > > > > > >drivers/gpu/drm/msm/adreno/adreno_device.c | 6 +-
> > > > > > > >drivers/gpu/drm/msm/msm_ringbuffer.c| 5 +-
> > > > > > > >drivers/gpu/drm/panfrost/panfrost_job.c | 5 +-
> > > > > > > >drivers/gpu/drm/scheduler/sched_entity.c| 127 +++--
> > > > > > > >drivers/gpu/drm/scheduler/sched_fence.c | 6 +-
> > > > > > > >drivers/gpu/drm/scheduler/sched_main.c | 278
> > > > > > > > +++--
> > > ---
> > > > > > > >drivers/gpu/drm/v3d/v3d_sched.c | 25 +-
> > > > > > > >include/drm/gpu_scheduler.h | 130 +++--
> > > > > > > >include/linux/dma-fence.h | 60 -
> > > > > > > >16 files changed, 649 insertions(+), 184 deletions(-)
> > > > > > > >
> > > > > > > > --
> > > > > > > > 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
r api
rework, but I think it's also pretty clearly not ever going to get
anywhere with just nothing at all. Writing an entire new scheduler lib
instead of at least trying what minimal semantic changes (instead of just
a pile of hacks without even doc changes for the new rules) does not sound
like a good idea to me :-)
> If you want a workload to try to see if you run into any of these things,
> running and killing lots of things in parallel is a good thing to try (mess
> with the numbers and let it run for a while to see if you can hit any corner
> cases):
>
> while true; do for i in $(seq 1 10); do timeout -k 0.01 0.05 glxgears &
> done; sleep 0.1; done
Maybe xe gets away with this due to synchronously killing everything
related to a ctx, but yeah I'd expect this to go boom in fun ways.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Apr 11, 2023 at 02:11:18PM +0200, Christian König wrote:
> Am 11.04.23 um 11:51 schrieb Daniel Vetter:
> > On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote:
> > > When swapping out, we will split multi-order pages both in order to
> > >
On Tue, Apr 04, 2023 at 09:39:34PM +0200, Daniel Vetter wrote:
> This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
> restore") - I failed to realize that nasty userspace could set this.
>
> It's not pretty to mix up kernel-internal and userspace uapi flags
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -41,6 +41,7 @@
> struct dma_fence;
> struct drm_file;
> struct drm_device;
> +struct drm_printer;
> struct device;
> struct file;
>
> @@ -438,6 +439,15 @@ void drm_send_event_timestamp_lock
th proper color rendering this is changing :-)
> If this is a module parameter instead of a KMS property, what purpose
> does this achieve? What is the use-case? Just trying to understand the
> motivation here.
Just a step to get things going, occasionally that's needed ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
thdr.c | 370 ++
> drivers/gpu/drm/mediatek/mtk_ethdr.h | 25 +
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c| 24 +
> 19 files changed, 1858 insertions(+), 319 deletions(-)
> create mode 100644
> Documentation/devicetree/
return formats;
> +}
> +
> +size_t mtk_mdp_rdma_get_num_formats(struct device *dev)
> +{
> + return ARRAY_SIZE(formats);
> +}
> +
> int mtk_mdp_rdma_clk_enable(struct device *dev)
> {
> struct mtk_mdp_rdma *rdma = dev_get_drvdata(dev);
> --
> 2.18.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
|2 +
> include/uapi/drm/msm_drm.h | 18 +-
> include/uapi/linux/sync_file.h | 37 +-
> 125 files changed, 6659 insertions(+), 4519 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/habanalabs/common/sysfs.c| 6 +-
> drivers/accel/habanalabs/gaudi/gaudi.c | 86 +
> drivers/accel/habanalabs/gaudi/gaudiP.h| 15 -
> drivers/accel/habanalabs/gaudi2/gaudi2.c | 347
> +++--
> drivers/accel/habanala
void)
> return ret;
>
> mqc_dev_major = ret;
> - mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
> + mqc_dev_class = class_create(MHI_QAIC_CTRL_DRIVER_NAME);
> if (IS_ERR(mqc_dev_class)) {
> ret = PTR_ERR(mqc_dev_class);
> goto unregister_chrdev;
> --
> 2.39.2
>
> --
> Cheers,
> Stephen Rothwell
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
for (i = 0; i < TTM_DIM_ORDER; ++i) {
> ttm_pool_type_init(_write_combined[i], NULL,
> ttm_write_combined, i);
> ttm_pool_type_init(_uncached[i], NULL, ttm_uncached, i);
> @@ -790,7 +798,7 @@ void ttm_pool_mgr_fini(void)
> {
> unsigned int i;
>
> - for (i = 0; i < MAX_ORDER; ++i) {
> + for (i = 0; i < TTM_DIM_ORDER; ++i) {
> ttm_pool_type_fini(_write_combined[i]);
> ttm_pool_type_fini(_uncached[i]);
>
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Apr 06, 2023 at 03:06:56PM -0300, Maíra Canal wrote:
> On 4/6/23 14:28, Daniel Vetter wrote:
> > On Thu, 6 Apr 2023 at 19:20, Maíra Canal wrote:
> > >
> > > After commit 8ba1648567e2 ("drm: vkms: Refactor the plane composer to
> > > accept n
0
> R10: R11: 0246 R12:
> R13: 7ffd0e5e571f R14: 7f5372809300 R15: 00022000
>
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syz
On Thu, Apr 06, 2023 at 07:42:44PM +0200, Daniel Vetter wrote:
> But I think there's tools to make sure we don't dig a complete hole with
> these it sounds like. I guess another topic for pestering the rust folks.
Or to put it very bluntly: Could we make Arc at least runtime e
On Fri, Apr 07, 2023 at 02:11:32AM +0900, Asahi Lina wrote:
> On 07/04/2023 00.30, Daniel Vetter wrote:
> > On Thu, Apr 06, 2023 at 11:43:19PM +0900, Asahi Lina wrote:
> > > On 06/04/2023 22.37, Daniel Vetter wrote:
> > > > On Thu, Apr 06, 2023 at 09:2
m/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -113,6 +113,7 @@ struct vkms_config {
> bool writeback;
> bool cursor;
> bool overlay;
> + unsigned long *background_color;
> /* only set when instantiated */
> struct vkms_device *dev;
> };
> @@ -127,6 +128,9 @@ struct vkms_device {
> #define drm_crtc_to_vkms_output(target) \
> container_of(target, struct vkms_output, crtc)
>
> +#define vkms_output_to_vkms_device(target) \
> + container_of(target, struct vkms_device, output)
> +
> #define drm_device_to_vkms_device(target) \
> container_of(target, struct vkms_device, drm)
>
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, 6 Apr 2023 at 18:58, Matthew Brost wrote:
>
> On Thu, Apr 06, 2023 at 08:32:59AM +0200, Daniel Vetter wrote:
> > On Wed, Apr 05, 2023 at 11:58:44PM +, Matthew Brost wrote:
> > > On Wed, Apr 05, 2023 at 03:09:08PM +0200, Daniel Vetter wrote:
> > > > O
Brezillon (1):
drm/panfrost: Fix the panfrost_mmu_map_fault_addr() error path
Daniel Vetter (2):
Merge tag 'drm-intel-fixes-2023-04-05' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Merge tag 'drm-misc-fixes-2023-04-05' of
git://anongit.freedesktop.org/drm/drm-misc
ITE);
> + dma_resv_add_fence(bo->base.resv, job->done_fence,
> DMA_RESV_USAGE_WRITE);
>
> unlock_reservations:
> - drm_gem_unlock_reservations((struct drm_gem_object **)job->bos,
> buf_count, _ctx);
> + drm_gem_unlock_reservations((struct drm_gem_object **)job->bos, 1,
> _ctx);
>
> wmb(); /* Flush write combining buffers */
>
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
delete mode 100644 drivers/gpu/drm/i915/Kconfig.unstable
> create mode 100644 drivers/gpu/drm/i915/display/intel_dp_aux_regs.h
> create mode 100644 drivers/gpu/drm/i915/display/intel_dsb_regs.h
> create mode 100644 drivers/gpu/drm/i915/display/intel_fdi_regs.h
> create mode 100644 drivers/gpu/drm/i915/display/intel_pps_regs.h
> create mode 100644 drivers/gpu/drm/i915/display/intel_psr_regs.h
> create mode 100644 drivers/gpu/drm/i915/display/intel_tv_regs.h
> create mode 100644 drivers/gpu/drm/i915/display/skl_watermark_regs.h
> create mode 100644 drivers/gpu/drm/i915/intel_clock_gating.c
> create mode 100644 drivers/gpu/drm/i915/intel_clock_gating.h
> delete mode 100644 drivers/gpu/drm/i915/intel_pm.c
> delete mode 100644 drivers/gpu/drm/i915/intel_pm.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, 6 Apr 2023 at 17:59, Daniel Vetter wrote:
>
> On Thu, Apr 06, 2023 at 05:33:18PM +0200, Christian König wrote:
> > Am 06.04.23 um 17:24 schrieb Lucas Stach:
> > > Am Donnerstag, dem 06.04.2023 um 16:21 +0200 schrieb Christian König:
> > > > Am 06.0
On Fri, Apr 07, 2023 at 12:53:47AM +0900, Asahi Lina wrote:
> On 06/04/2023 23.15, Daniel Vetter wrote:
> > On Tue, Mar 07, 2023 at 11:25:32PM +0900, Asahi Lina wrote:
> > > drm_mm provides a simple range allocator, useful for managing virtual
> > > address ranges. Add a
t it's not
> > > > unbounded. On a crash/fault the job will be removed from the hardware
> > > > pretty soon.
> > > >
> > > > Well behaved jobs after a application shutdown might take a little
> > > > longer, but I don't really see the new problem with keeping the entity
> > > > alive? As long as a job is active on the hardware, we can't throw out
> > > > the VM or BOs, no difference whether the entity is kept alive or not.
> > > Exactly that's the problem. VM & BOs are dropped as soon as the process
> > > is destroyed, we *don't* wait for the hw to finish before doing so.
> > >
> > > Just the backing store managed by all the house keeping objects isn't
> > > freed until the hw is idle preventing a crash or accessing freed memory.
> > >
> > > This behavior is rather important for the OOM killer since we need to be
> > > able to tear down the process as fast as possible in that case.
> > >
> > Are you talking about the dropping of pending jobs in
> > drm_sched_entity_kill? I'm certainly not trying to change that in any
> > way. Those aren't put onto the hardware yet, so we can always safely
> > drop them and do so as fast as possible.
> >
> > What I'm concerned about are the jobs that are already scheduled on the
> > HW. At least with Vivante hardware there is no race free way to get rid
> > of jobs once they are put on the ring. So whatever the scheduler or DRM
> > core is doing, we have to hold on to the BOs and GPU memory management
> > structures to keep the hardware from operating on freed memory.
> >
> > That's already a lot of memory, so I don't really see the issue with
> > keeping the entity around in a quiescent state until all the currently
> > queued jobs have left the HW.
> >
> > > Changing that is possible, but that's quite a huge change I'm not really
> > > willing to do just for tracking the time spend.
> > >
> > Yea, it's a big change and whether it's a good idea really depends on
> > what we a gaining from it. You seem to see quite low value in "just
> > tracking the time spent" and that might be true, but it also forces all
> > drivers that want to implement fdinfo to roll their own time tracking.
> > I would rather see more of this moved to the scheduler and thus shared
> > between drivers.
>
> That's generally a good idea, but if that means that we need to restructure
> the whole entity handling then I would object. That's simply not worth it
> when we can implement it differently.
>
> What we could do is to keep the submitted fences around in the entity.
> Similar to the tracking amdgpu does, see struct amdgpu_ctx_entity.
>
> This way the entity doesn't needs to stay around after it delivered the job
> to the hw.
I've done a _very_ cursory look, but from that the design seems to be that
we only keep something very small around to avoid oopsing (just
drm_sched_entity) and the overall gpu ctx goes away synchronously (more or
less) when userspace destroys it.
And then the actual fdinfo reporting or any reporting is a pure pull model
where you come from drm_file -> gpu ctx -> amdgpu_ctx_entity and have
borrowed references by holding enough locks.
The push model, where the scheduler job actively pushes the stats all the
way to the userspace/uapi ctx object is imo impossible to get right.
i915-gem tried a few times, and solutions start with sprinkling rcu
everywhere and only get worse. Imo absolute no-go.
If I understand this right then yes I think extracting the
amgpu_ctx_entity split into a bit of helper. Might want to extract the
context xarray and lookup too and put it into drm_file, including the
amdgpu_ctx_mgr->lock and iterating over stats for fdinfo maybe too to make
this really worth it.
Of all the failed attempts I've seen for exposing ctx stats this (amdgpu
push model) is imo the only solid one.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Apr 06, 2023 at 05:28:59PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 6, 2023 at 4:15 PM Daniel Vetter wrote:
> >
> > Documentation:
> >
> > In drm we try to document all the interfaces that drivers use with formal
> > docs. Yes there's some areas that are
On Thu, Apr 06, 2023 at 11:43:19PM +0900, Asahi Lina wrote:
> On 06/04/2023 22.37, Daniel Vetter wrote:
> > On Thu, Apr 06, 2023 at 09:21:47PM +0900, Asahi Lina wrote:
> > > On 06/04/2023 19.09, Daniel Vetter wrote:
> > > > On Thu, Apr 06, 2023 at 06:0
ode.node.start = start;
> +mm_node.node.size = size;
> +mm_node.node.color = color as core::ffi::c_ulong;
> +
> +let guard = self.mm.lock();
> +// SAFETY: We hold the lock and all pointers are valid.
> + to_result(unsafe { bindings::drm_mm_rese
On Thu, Apr 06, 2023 at 02:19:20PM +0200, Lucas Stach wrote:
> Am Donnerstag, dem 06.04.2023 um 14:09 +0200 schrieb Daniel Vetter:
> > On Thu, Apr 06, 2023 at 12:45:12PM +0200, Lucas Stach wrote:
> > > Am Donnerstag, dem 06.04.2023 um 10:27 +0200 schrieb Daniel Vetter:
> >
On Thu, Apr 06, 2023 at 04:18:46PM +0300, Mikko Perttunen wrote:
> On 4/6/23 16:09, Daniel Vetter wrote:
> > On Thu, Apr 06, 2023 at 02:14:04PM +0200, Thierry Reding wrote:
> > > Hi Dave, Daniel,
> > >
> > > The following changes since commit
> >
401 - 500 of 23209 matches
Mail list logo
