; > - if (!dma_fence_add_callback(fence, &dcb->cb,
> > - dma_buf_poll_cb)) {
> > - dma_fence_put(fence);
> > - events &= ~EPOLLOUT;
>
On Thu, Jul 15, 2021 at 03:16:08PM -0700, John Harrison wrote:
> On 6/16/2021 03:25, Daniel Vetter wrote:
> > On Thu, Jun 10, 2021 at 10:46 PM wrote:
> > > From: John Harrison
> > >
> > > Various UMDs need to know the L3 bank count. So add a query API for
> > > > the
> > > > simpledrm driver could be used on aarch64 EFI systems as well.
> > > >
> > > > The patches have already been acked by x86 and DRM folks.
> > >
> > > Time to get this merged, I'd say. People are asking for t
> /*
> * struct device based logging
> *
> - * Prefer drm_device based logging over device or prink based logging.
> + * Prefer drm_device based logging over device or printk based logging.
> */
>
> __printf(3, 4)
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; + __drm_dbg(cDRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_VBL(fmt, ...)
> \
> - __drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__)
> + __drm_dbg(cDRM_UT_VBL, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_LEASE(fmt, ...)\
> - __drm_dbg(DRM_UT_LEASE, fmt, ##__VA_ARGS__)
> + __drm_dbg(cDRM_UT_LEASE, fmt, ##__VA_ARGS__)
>
> #define DRM_DEBUG_DP(fmt, ...)
> \
> - __drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
> + __drm_dbg(cDRM_UT_DP, fmt, ## __VA_ARGS__)
>
> -#define __DRM_DEFINE_DBG_RATELIMITED(category, drm, fmt, ...)
> \
> +#define __DRM_DEFINE_DBG_RATELIMITED(DRM_UT, cDRM_UT, drm, fmt, ...) \
> ({ \
> static DEFINE_RATELIMIT_STATE(rs_, \
> DEFAULT_RATELIMIT_INTERVAL, \
> DEFAULT_RATELIMIT_BURST); \
> const struct drm_device *drm_ = (drm); \
> \
> - if (drm_debug_enabled(DRM_UT_ ## category) && __ratelimit(&rs_))\
> - drm_dev_printk(drm_ ? drm_->dev : NULL, \
> -KERN_DEBUG, fmt, ## __VA_ARGS__);\
> + if (drm_debug_enabled(DRM_UT) && __ratelimit(&rs_)) \
> + drm_dev_dbg((drm_) ? (drm_)->dev : NULL,\
> + cDRM_UT, fmt, ##__VA_ARGS__); \
> })
>
> #define drm_dbg_kms_ratelimited(drm, fmt, ...) \
> - __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__)
> + __DRM_DEFINE_DBG_RATELIMITED(DRM_UT_KMS, cDRM_UT_KMS, drm, fmt, ##
> __VA_ARGS__)
>
> #define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) \
> drm_dbg_kms_ratelimited(NULL, fmt, ## __VA_ARGS__)
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
nside is probably that the implementation of
> drm_with_modeset_lock_ctx() is a bit harder to read than a hand
> rolled version on account of being split across three functions,
> but the actual code using it ends up being much simpler.
>
> Cc: Sean Paul
> Cc: Daniel Vetter
>
IO 0x04
> > #define VGA_RSRC_NORMAL_MEM0x08
> > -/* Passing that instead of a pci_dev to use the system "default"
> > - * device, that is the one used by vgacon. Archs will probably
> > - * have to provide their own vga_default_device();
> >
th this.
> >
> > Signed-off-by: Christian König
>
> Acked-by: Alex Deucher
Acked-by: Daniel Vetter
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 +--
> > drivers/gpu/drm/nouveau/nouveau_gem.c| 3 +--
> > drivers/gpu/drm/radeon/ra
drm_ioctl_compat_t(struct file *filp, unsigned
> int cmd,
> unsigned long arg);
>
> #define DRM_IOCTL_NR(n)_IOC_NR(n)
> +#define DRM_IOCTL_TYPE(n) _IOC_TYPE(n)
> #define DRM_MAJOR 226
>
> /**
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jul 20, 2021 at 03:42:45PM +0200, Javier Martinez Canillas wrote:
> On 7/20/21 3:01 PM, Daniel Vetter wrote:
> > On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote:
> >> On Mon, 19 Jul 2021 at 04:59, Dave Airlie wrote:
>
> [snip]
>
> >>&g
ut
it's purely a perf optimization. So it's fine. Plus we're not even
bothering with the iomem vs normal memory distinction here.
Anyway, that aside, all looks good. On the series:
Acked-by: Daniel Vetter
> else
> drm_fb_memcpy(dst, sr
;
> struct drm_device;
> struct drm_fb_helper_surface_size;
> @@ -34,6 +37,9 @@ struct drm_framebuffer *
> drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
>const struct drm_mode_fb_cmd2 *mode_cmd);
>
> +int drm_gem_fb_begin_cpu_access(struct drm_framebuffer *fb, enum
> dma_data_direction dir);
> +void drm_gem_fb_end_cpu_access(struct drm_framebuffer *fb, enum
> dma_data_direction dir);
> +
> #define drm_is_afbc(modifier) \
> (((modifier) & AFBC_VENDOR_AND_TYPE_MASK) == DRM_FORMAT_MOD_ARM_AFBC(0))
Reviewed-by: Daniel Vetter
>
> --
> 2.32.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/msm/msm_gpu.h | 41 ++-
> > drivers/gpu/drm/msm/msm_ringbuffer.c| 70 -
> > drivers/gpu/drm/msm/msm_ringbuffer.h| 12 +
> > drivers/gpu/drm/msm/msm_submitqueue.c | 49 +++-
> > include/drm/drm_gem.h | 2 -
> > include/uapi/drm/msm_drm.h | 10 +-
> > 23 files changed, 440 insertions(+), 359 deletions(-)
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Sat, Jul 17, 2021 at 01:29:06PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Now that no one is using it, remove it.
>
> Signed-off-by: Rob Clark
Yay!
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem.c | 22 --
> include/drm/dr
bcfdda9 ("drm/i915: Make request allocation caches global")
> Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_globals.c | 4 ++--
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
>
rtantly, this
> means that everything from our selftests has the ability to properly
> flush out between i915_init() and i915_exit() because there are a couple
> syscall boundaries in between.
>
> Signed-off-by: Jason Ekstrand
> Fixes: 32eb6bcfdda9 ("drm/i915: Make requ
; -
> static int __init ttm_init(void)
> {
> - ttm_debugfs_root = debugfs_create_dir("ttm", NULL);
> return 0;
> }
>
> static void __exit ttm_exit(void)
> {
> - debugfs_remove(ttm_debugfs_root);
> }
I think you can delete these functions and the lines below too, they
should be optional. With that:
Reviewed-by: Daniel Vetter
-Daniel
>
> module_init(ttm_init);
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jul 20, 2021 at 04:16:56PM +0200, Christian König wrote:
> Am 20.07.21 um 16:07 schrieb Daniel Vetter:
> > On Mon, Jul 19, 2021 at 10:40:57AM +0200, Christian König wrote:
> > > Am 17.07.21 um 22:29 schrieb Rob Clark:
> > > > From: Rob Clark
> > >
tje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say
t; - Add a new patch to the series that moves the call to _drm_lease_held out
> from the section locked by &dev->mode_config.idr_mutex in
> __drm_mode_object_find.
> - Clarify the kerneldoc for dereferencing drm_file.master, as suggested by
> Daniel Vetter.
> - Refactor
i915_exit()
> always tears down exactly the things that i915_init() successfully
> initialized. We also allow early-exit of i915_init() without failure by
> an init function returning > 0. This is useful for nomodeset, and
> selftests. For the mock selftests, we convert them to
return ret;
> > > }
> > >
> > > +/* legacy path for WAIT_FENCE ioctl: */
> > > +int msm_wait_fence(struct msm_fence_context *fctx, uint32_t fence,
> > > + ktime_t *timeout, bool interruptible)
> > > +{
> > > + return wait_fence(fctx, fence, timeout_to_jiffies(timeout),
> > > interruptible);
> > > +}
> > > +
> > > /* called from workqueue */
> > > void msm_update_fence(struct msm_fence_context *fctx, uint32_t fence)
> > > {
> > > @@ -114,10 +114,19 @@ static bool msm_fence_signaled(struct dma_fence
> > > *fence)
> > > return fence_completed(f->fctx, f->base.seqno);
> > > }
> > >
> > > +static signed long msm_fence_wait(struct dma_fence *fence, bool intr,
> > > + signed long timeout)
> > > +{
> > > + struct msm_fence *f = to_msm_fence(fence);
> > > +
> > > + return wait_fence(f->fctx, fence->seqno, timeout, intr);
> > > +}
> > > +
> > > static const struct dma_fence_ops msm_fence_ops = {
> > > .get_driver_name = msm_fence_get_driver_name,
> > > .get_timeline_name = msm_fence_get_timeline_name,
> > > .signaled = msm_fence_signaled,
> > > + .wait = msm_fence_wait,
> > > };
> > >
> > > struct dma_fence *
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jul 21, 2021 at 12:32 AM Rob Clark wrote:
>
> On Tue, Jul 20, 2021 at 1:55 PM Daniel Vetter wrote:
> >
> > On Tue, Jul 20, 2021 at 8:26 PM Rob Clark wrote:
> > >
> > > On Tue, Jul 20, 2021 at 11:03 AM Christian König
> > > wrote:
> >
&glob->bo_count);
> > out:
> > + if (ret)
> > + --ttm_glob_use_count;
> > mutex_unlock(&ttm_global_mutex);
> > return ret;
> > }
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jul 21, 2021 at 11:08 AM Christian König
wrote:
> Am 21.07.21 um 11:06 schrieb Daniel Vetter:
> > On Wed, Jul 21, 2021 at 8:36 AM Christian König
> > wrote:
> >> Am 20.07.21 um 20:13 schrieb Jason Ekstrand:
> >>> If we have a failure, decrement
#include
> >
> > #include "gt/intel_gtt.h"
> >
> > @@ -243,7 +244,7 @@ struct intel_vgpu_oos_page {
> >
> > /* Represent a vgpu shadow page table. */
> > struct intel_vgpu_ppgtt_spt {
> > - atomic_t refcount;
> > + refcount_t refcount;
> > struct intel_vgpu *vgpu;
> >
> > struct {
> > --
> > 2.7.4
> >
> > ___
> > intel-gvt-dev mailing list
> > intel-gvt-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jul 21, 2021 at 6:12 AM Desmond Cheong Zhi Xi
wrote:
> On 21/7/21 2:24 am, Daniel Vetter wrote:
> > On Mon, Jul 12, 2021 at 12:35:03PM +0800, Desmond Cheong Zhi Xi wrote:
> >> Hi,
> >>
> >> In the previous thread on this series we decided to remov
_two_ different subsystems, and it
doesn't make sense to just merge it all in one place (because too much
work, or a refactoring that's too invasive and will cause random conflicts
with subsequent work in the same subsystem, or ...).
Otherwise just acks and then merge in one place. We shou
On Tue, Jul 20, 2021 at 09:55:22AM -0500, Jason Ekstrand wrote:
> On Tue, Jul 20, 2021 at 9:18 AM Daniel Vetter wrote:
> >
> > On Mon, Jul 19, 2021 at 01:30:44PM -0500, Jason Ekstrand wrote:
> > > If the driver was not fully loaded, we may still have globals lying
> &g
c: Pekka Paalanen
> Cc: Daniel Vetter
> Cc: Leandro Ribeiro
> ---
> include/uapi/drm/drm_mode.h | 52 ++---
> 1 file changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 98
On Wed, Jul 21, 2021 at 06:51:30AM +, Simon Ser wrote:
> When a property has the type DRM_MODE_PROP_BITMASK, the value field
> stores a bitshift, not a bitmask, which can be surprising.
>
> Signed-off-by: Simon Ser
> Cc: Pekka Paalanen
> Cc: Daniel Vetter
>
rupts".
Maybe also add here:
New implementations must have an @enable_signalling and dma_fence_signal()
implementation which does not require special handling to make
dma_fence_wait() work.
With these:
Reviewed-by: Daniel Vetter
>*
>* Must return -ERESTARTSYS if th
of your "The caller should" what about:
It is not required to hold rerence to @fence. But since the fence can
disappear as soon as @cb has returned callers generally must hold their
own reference to prevent issues.
With that or something similar that explains when we must do w
river can now try
> + * to find its MIPI-DSI host and can register as a MIPI-DSI device.
> + *
> + * At this point, we're now certain that both the display driver and the
> + * bridge driver are functional and we can't have a deadlock-like
> + * situation when probing.
> + */
> +
> static DEFINE_MUTEX(bridge_lock);
> static LIST_HEAD(bridge_list);
>
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jul 21, 2021 at 02:05:01PM +0200, Daniel Vetter wrote:
> On Tue, Jul 20, 2021 at 03:45:19PM +0200, Maxime Ripard wrote:
> > Interactions between bridges, panels, MIPI-DSI host and the component
> > framework are not trivial and can lead to probing issues when
> > i
herency on shared LLC platforms.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Ville Syrjälä
> Cc: Mika Kuoppala
> ---
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 173 +-
> drivers/gpu/drm/i915/i915_drv.h | 9 -
> 2
On Wed, Jul 21, 2021 at 2:44 PM Desmond Cheong Zhi Xi
wrote:
> On 21/7/21 6:29 pm, Daniel Vetter wrote:
> > On Wed, Jul 21, 2021 at 6:12 AM Desmond Cheong Zhi Xi
> > wrote:
> >> On 21/7/21 2:24 am, Daniel Vetter wrote:
> >>> On Mon, Jul 12, 2021 at 12:35:03P
rjälä
Cc: Gwan-gyeong Mun
Cc: José Roberto de Souza
Cc: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_damage_helper.c | 2 +-
include/drm/drm_damage_he
right mostly, but
better to make sure. At least no one is bypassing the accessor
function.
Cc: Ville Syrjälä
Cc: Gwan-gyeong Mun
Cc: José Roberto de Souza
Cc: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Ve
ä
Cc: Gwan-gyeong Mun
Cc: José Roberto de Souza
Cc: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 4 +--
drivers/gpu/drm/drm_damage_helper.c
On Wed, Jul 21, 2021 at 3:18 PM Christian König
wrote:
> Am 21.07.21 um 13:52 schrieb Daniel Vetter:
> > On Wed, Jul 21, 2021 at 11:21:33AM +0200, Christian König wrote:
> >> That the caller doesn't need to keep a reference is rather
> >> risky and not defens
; Signed-off-by: Thomas Zimmermann
> Fixes: 39a364a19e03 ("drm/hisilicon/hibmc: Convert to Linux IRQ interfaces")
> Reported-by: Dave Airlie
> Cc: Thomas Zimmermann
> Cc: Tian Tao
> Cc: Maxime Ripard
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
Reviewed-by: Daniel Vetter
On Wed, Jul 21, 2021 at 3:57 PM Christian König
wrote:
> Am 21.07.21 um 15:36 schrieb Daniel Vetter:
> > On Wed, Jul 21, 2021 at 3:18 PM Christian König
> > wrote:
> >> Am 21.07.21 um 13:52 schrieb Daniel Vetter:
> >>> On Wed, Jul 21, 2021 at 11:21:33AM +0200
fied table and remove
i915_globals.[hc] entirely.
Cc: David Airlie
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 --
drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 --
drivers/gpu/drm/i915/gt/intel_context.c | 6 --
drivers/gpu/d
> > *objects);
> > +int i915_global_buddy_init(void);
> > +
> > #endif
> > diff --git a/drivers/gpu/drm/i915/i915_globals.c
> > b/drivers/gpu/drm/i915/i915_globals.c
> > index 87267e1d2ad92..e57102a4c8d16 100644
> > --- a/drivers/gpu/drm/i915/i915_globals.c
> > +++ b/drivers/gpu/drm/i915/i915_globals.c
> > @@ -8,6 +8,7 @@
> > #include
> > #include "i915_active.h"
> > +#include "i915_buddy.h"
> > #include "gem/i915_gem_context.h"
> > #include "gem/i915_gem_object.h"
> > #include "i915_globals.h"
> > @@ -87,6 +88,7 @@ static void __i915_globals_cleanup(void)
> > static __initconst int (* const initfn[])(void) = {
> > i915_global_active_init,
> > + i915_global_buddy_init,
> > i915_global_context_init,
> > i915_global_gem_context_init,
> > i915_global_objects_init,
> >
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jul 21, 2021 at 09:34:43AM -0700, Rob Clark wrote:
> On Wed, Jul 21, 2021 at 12:59 AM Daniel Vetter wrote:
> >
> > On Wed, Jul 21, 2021 at 12:32 AM Rob Clark wrote:
> > >
> > > On Tue, Jul 20, 2021 at 1:55 PM Daniel Vetter wrote:
> > > >
>
On Wed, Jul 21, 2021 at 10:17 PM Jason Ekstrand wrote:
>
> On Wed, Jul 21, 2021 at 1:32 PM Daniel Vetter wrote:
> >
> > This essentially reverts
> >
> > commit 84a1074920523430f9dc30ff907f4801b4820072
> > Author: Chris Wilson
> > Date: Wed Jan 2
created,
> the object isn't really in any memory region at all. While I don't
> think obj->mm.region == NULL is allowed or a good idea, it does seem
> closer to the ground truth.
>
> Perhaps what we really want is for i915_gem_object_migrate to
> get_pages before it does the migration to ensure that pages exist.
> The only call to i915_gem_object_migrate in the code-base today is in
> the display code and it's immediately followed by pin_pages(). For
> that matter, maybe the call we actually want is
> i915_object_migrate_and_pin that does the whole lot.
I think long term at least we should track the curren region in the
ttm_resource struct (which can now be subclassed, yay, so we can stuff
anything we want into that one). And maybe make our regions proper
subcla of ttm_resource_manager.
Even on platforms where ttm isn't used, where we will simply use the
same fields until the code is more unified.
With that there should be only the invairant placement list from
create_ext and the current region allocation left, and nothing else.
Also this would give us a very clear design for the objects which
change their type on igfx (like the shmem->phys_object stuff, which
currently just punches out the ->ops table and hopes for the best).
Also, get_pages is just a transition crutch too, we really want to
more explicit manage placement:
- for migration in dma-buf or display and other places where we must
limit the list of placements beyond what the user specified (and fail
it the intersection is empty)
- for execbuf, where we want to limit migration to avoid thrashing,
i.e. get_pages shouldn't just blindly try to move the buffer (but also
should not just never try to move the buffer, either is suboptimal).
All of this should be orthogonal to pin, which just nails something in
place wherever it is. Which is also extremely not what we currently
have, because right now pin is what allows to to say where you need
the object to be - in the old design only holding a pin prevented the
object from slipping away, now we'll move over to dma_resv_lock and
explicit migration, instead of smashing it all into the one pin
function call.
> Thoughts?
I think aside from starting to embed the ttm objects in the right
places and starting to use only those fields were we duplicate I think
we should leave things as-is for now. It's not pretty, but we need a
pile more ttm things in place first.
-Daniel
>
> --Jason
>
> P.S. I'm going to go ahead and send another version with your other
> comments addressed. We can keep this discussion going here for now.
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jul 22, 2021 at 10:42:26AM +0200, Christian König wrote:
> Am 21.07.21 um 21:03 schrieb Daniel Vetter:
> > On Wed, Jul 21, 2021 at 09:34:43AM -0700, Rob Clark wrote:
> > > On Wed, Jul 21, 2021 at 12:59 AM Daniel Vetter wrote:
> > > > On Wed, Jul 21, 202
_tt, dma_ttm);
>
> - ttm_tt_destroy_common(bdev, ttm);
> vmw_ttm_unmap_dma(vmw_be);
> ttm_tt_fini(ttm);
> if (vmw_be->mob)
> diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
> index 818680c6a8ed..e402dab1d0f6 100644
> --- a/include/drm/ttm/ttm_tt.h
> +++ b/include/drm/ttm/ttm_tt.h
> @@ -134,13 +134,6 @@ void ttm_tt_fini(struct ttm_tt *ttm);
> */
> void ttm_tt_destroy(struct ttm_device *bdev, struct ttm_tt *ttm);
>
> -/**
> - * ttm_tt_destroy_common:
> - *
> - * Called from driver to destroy common path.
> - */
> -void ttm_tt_destroy_common(struct ttm_device *bdev, struct ttm_tt *ttm);
> -
> /**
> * ttm_tt_swapin:
> *
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jul 21, 2021 at 10:24:01PM +0200, Daniel Vetter wrote:
> On Wed, Jul 21, 2021 at 10:17 PM Jason Ekstrand wrote:
> >
> > On Wed, Jul 21, 2021 at 1:32 PM Daniel Vetter
> > wrote:
> > >
> > > This essentially reverts
> > >
> > > com
___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jul 21, 2021 at 03:15:09PM -0500, Jason Ekstrand wrote:
> On Wed, Jul 21, 2021 at 1:56 PM Daniel Vetter wrote:
> >
> > On Wed, Jul 21, 2021 at 05:25:41PM +0100, Matthew Auld wrote:
> > > On 21/07/2021 16:23, Jason Ekstrand wrote:
> > > > There's
he whole TTM debugfs directory to match that of the TTM global
> state.
>
> Signed-off-by: Jason Ekstrand
> Reviewed-by: Daniel Vetter
I've pushed this to drm-misc-fixes since I think this entire slab debugfs
story started with 5.15-rc1, so good to get it sorted there.
On Thu, Jul 22, 2021 at 11:02:55AM +0100, Tvrtko Ursulin wrote:
> On 21/07/2021 19:32, Daniel Vetter wrote:
> > This essentially reverts
> >
> > commit 84a1074920523430f9dc30ff907f4801b4820072
> > Author: Chris Wilson
> > Date: Wed Jan 24 11:36:08 2018 +
&
; + *
> + * Objects are leased all together in drm_lease_create(), and are
> + * removed all together when the lease is revoked.
> + */
> struct idr leases;
> +
> + /**
> + * @lessee_idr:
> + *
> + * All lessees under this owner (only used where lessor is NULL).
@lessor so it's highlighted correctly
> + * Protected by &drm_device.mode_config's &drm_mode_config.idr_mutex.
> + */
> struct idr lessee_idr;
> /* private: */
With the nits addressed:
Reviewed-by: Daniel Vetter
Thanks for updating the docs!
-Daniel
> #if IS_ENABLED(CONFIG_DRM_LEGACY)
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
n use the
> drm_file.master_lookup_lock that sits at the bottom of the lock
> hierarchy.
>
> Reported-by: Daniel Vetter
> Signed-off-by: Desmond Cheong Zhi Xi
> ---
> drivers/gpu/drm/drm_auth.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/
pointers in
> vmw_surface_define_ioctl and vmw_gb_surface_define_internal.
>
> This is fixed by replacing drm_master_get with drm_file_get_master.
>
> Signed-off-by: Desmond Cheong Zhi Xi
Reviewed-by: Daniel Vetter
I'll let Zack take a look at this and expect him to push thi
On Thu, Jul 22, 2021 at 11:28:01AM +0200, Christian König wrote:
> Am 22.07.21 um 11:08 schrieb Daniel Vetter:
> > [SNIP]
> > > As far as I know wake_up_state() tries to run the thread on the CPU it was
> > > scheduled last, while wait_event_* makes the thread run on t
ency on shared LLC platforms.
> v3(Daniel):
> - Fix nonsense about "dirtying" the cache with reads.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Ville Syrjälä
> Cc: Mika Kuoppala
> ---
> .../gpu/drm/i915/gem/i915_gem_object_typ
On Thu, Jul 22, 2021 at 3:03 PM Desmond Cheong Zhi Xi
wrote:
>
> On 22/7/21 6:35 pm, Daniel Vetter wrote:
> > On Thu, Jul 22, 2021 at 05:29:28PM +0800, Desmond Cheong Zhi Xi wrote:
> >> In particular, we make it clear that &drm_device.mode_config.idr_mutex
> >&g
On Thu, Jul 22, 2021 at 6:00 PM Boqun Feng wrote:
>
> On Thu, Jul 22, 2021 at 12:38:10PM +0200, Daniel Vetter wrote:
> > On Thu, Jul 22, 2021 at 05:29:27PM +0800, Desmond Cheong Zhi Xi wrote:
> > > Inside drm_is_current_master, using the outer drm_device.master_mutex
>
a_agp sg parport_pc 8139cp parport
> > [ 58.798016] CR2: 017c
> > [ 58.798147] ---[ end trace 732829d39ed65de9 ]---
> >
> >
> > d02117f8efaa5fbc37437df1ae955a147a2a424a is the first bad commit
> >
> > --
> > Ondrej Zary
> >
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jul 22, 2021 at 08:22:43PM +0200, Thomas Zimmermann wrote:
> Hi,
>
> I'm not knowledgeable enougth to give this a full review. If you can just
> answer my questions, fell free to add an
>
> Acked-by: Thomas Zimmermann
>
> to the patch. :)
>
> Am 13.0
On Thu, Jul 22, 2021 at 08:40:56PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > intel-gfx-ci realized that something is not quite coherent anymore on
> > some platforms for our i915+vgem tests, when I tried to switch vgem
>
On Thu, Jul 22, 2021 at 08:50:48PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > Aside from deleting lots of code the real motivation here is to switch
> > the mmap over to VM_PFNMAP, to be more consistent with what real gpu
> &
gs & VM_WRITE))
> >>>return -EINVAL;
> >>>
> >>> ttm_bo_get(bo);
> >>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> >>> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> >>> index e6b1f98ec99f..e4bf7dc99320 100644
> >>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> >>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> >>> @@ -61,6 +61,7 @@ int vmw_mmap(struct file *filp, struct vm_area_struct
> >>> *vma)
> >>>.fault = vmw_bo_vm_fault,
> >>>.open = ttm_bo_vm_open,
> >>>.close = ttm_bo_vm_close,
> >>> + .mprotect = ttm_bo_vm_mprotect,
> >>>#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >>>.huge_fault = vmw_bo_vm_huge_fault,
> >>>#endif
> >>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> >>> index f681bbdbc698..40eb95875355 100644
> >>> --- a/include/drm/ttm/ttm_bo_api.h
> >>> +++ b/include/drm/ttm/ttm_bo_api.h
> >>> @@ -605,6 +605,10 @@ void ttm_bo_vm_close(struct vm_area_struct *vma);
> >>>
> >>>int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr,
> >>> void *buf, int len, int write);
> >>> +
> >>> +int ttm_bo_vm_mprotect(struct vm_area_struct *vma, unsigned long start,
> >>> +unsigned long end, unsigned long newflags);
> >>> +
> >>>bool ttm_bo_delayed_delete(struct ttm_device *bdev, bool remove_all);
> >>>
> >>>vm_fault_t ttm_bo_vm_dummy_page(struct vm_fault *vmf, pgprot_t prot);
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
as a broken one and the
right fix is in the right branch (and already in Linus' tree), so a hard
reset was all it took. So should be all in linux-next on the next update.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jul 23, 2021 at 10:02:39AM +0200, Christian König wrote:
> Am 23.07.21 um 09:36 schrieb Daniel Vetter:
> > On Thu, Jul 22, 2021 at 08:40:56PM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 13.07.21 um 22:51 schrieb Daniel Vetter:
>
José Roberto de Souza
Cc: Ville Syrjälä
Cc: Gwan-gyeong Mun
Cc: José Roberto de Souza
Cc: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_damage_helper.c | 2
g Mun
Cc: José Roberto de Souza
Cc: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c| 2 +-
drivers/gpu/drm/drm_crtc_internal.h | 2 ++
drivers/gpu/drm/d
berto de Souza
Cc: Ville Syrjälä
Cc: Gwan-gyeong Mun
Cc: José Roberto de Souza
Cc: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 4 +--
drivers/gp
; unsigned int i;
>
> + vmw_ttm_unbind(bdev, ttm);
> +
> if (vmw_tt->mob) {
> vmw_mob_destroy(vmw_tt->mob);
> vmw_tt->mob = NULL;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> + if (!lencoder)
> + return -ENOMEM;
> +
> + lencoder->lcrtc = ldev->mode_info[index].crtc;
> + lencoder->ldev = ldev;
> + encoder = &lencoder->base;
> + encoder->possible_crtcs = 1 << index;
> +
> + drm_encod
On Fri, Jul 23, 2021 at 10:33:48AM +0200, Christian König wrote:
>
>
> Am 23.07.21 um 10:21 schrieb Daniel Vetter:
> > On Wed, Jul 14, 2021 at 10:51 AM Christian König
> > wrote:
> > >
> > >
> > > Am 13.07.21 um 17:28 schrieb Alex Deucher:
&
+ /* Paired with get_file in dma_buf_poll */
> >> + fput(dmabuf->file);
> >
> > Is calling fput() in interrupt context ok? IIRC that could potentially
> > sleep.
>
> Looks fine AFAICT: It has
>
> if (likely(!in_interrupt() && !(task->flags & PF_KTHREAD))) {
>
> and as a fallback for that, it adds the file to a lock-less delayed_fput_list
> which is processed by a workqueue.
>
>
> --
> Earthling Michel Dänzer | https://redhat.com
> Libre software enthusiast | Mesa and X developer
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jul 23, 2021 at 11:13 AM Christian König
wrote:
>
> Am 23.07.21 um 10:47 schrieb Daniel Vetter:
> > On Thu, Jul 22, 2021 at 02:41:23PM +0200, Christian König wrote:
> >> Doing this in vmw_ttm_destroy() is to late.
> >>
> >> It turned out that th
;edp_info);
> + int ret = drm_edp_backlight_disable(aux,
> &backlight->edp_info);
> +
> if (ret < 0)
> NV_ERROR(drm, "Failed to disable backlight on
> [CONNECTOR:%d:%s]: %d\n",
> nv_connector->base.base.id,
> nv_connector->base.name, ret);
> }
> +#endif
>
> if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
wed-by: Christian König and I'm
> going to push this to drm-misc-next on Monday if nobody objects.
The boom only happens a lot later when the offending import uses the
attachment again. This here has a good chance to catch that early
drm_buf_put(), so I think it's a good improvement. W
On Fri, Jul 23, 2021 at 12:16:31PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 23, 2021 at 11:25 AM Daniel Vetter wrote:
> >
> > On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> > >
> > > From: Arnd Bergmann
> > >
> > > When the backl
On Fri, Jul 23, 2021 at 5:46 PM Simon Ser wrote:
>
> We already have logging for ADDFB2. Add some logging for RMFB as
> well.
>
> This can be handy when trying to find out why a CRTC gets magically
> disabled.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vette
here.
> > +
> > +Value shall reflect the amount of storage currently consumed by the buffer
> > +object belong to this client, in the respective memory region.
> > +
> > +Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
> > +indicating kibi- or mebi-bytes.
>
> I'm a bit wary of the accounting here. Is it buffer allocations
> originating from the client, in which case it conceptually clashes
> with gralloc? Is it the client which last wrote to the buffer? The
> client with the oldest open handle to the buffer? Other?
>
> Cheers,
> Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
table this now becomes trivial.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 48ea23dd3b5b..0deaeeba2347 100644
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_cache to just a slab_cache.
Cc: Jason Ekstrand
Signed
cbs.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_globals.c | 2 --
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/i915_request.c | 47 -
drivers/gpu/drm/i915/i915_request.h | 3 ++
4 files changed, 24 insertions(+
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_blocks to just a
slab_blocks.
Cc: Jason Ekstrand
Signed
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_ce to just a
slab_ce.
Cc: Jason Ekstrand
Signed-off-by
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_objects to just a
slab_objects.
Cc: Jason Ekstrand
Signed
rv.h include in i915_globals otherwise there's
nothing anymore that pulls in GEM_BUG_ON.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_globals.c | 3 +--
drivers/gpu/drm/i915/i915_globals.h | 3 ---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915
ies.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_globals.c | 2 --
drivers/gpu/drm/i915/i915_globals.h | 2 --
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/i915_scheduler.c | 39 +++
drivers/gpu/drm/i915/i915_s
No longer used.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 -
drivers/gpu/drm/i915/i915_globals.c | 53 ---
drivers/gpu/drm/i915/i915_globals.h | 25
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_luts to just a
slab_luts.
Cc: Jason Ekstrand
Signed-off-by
you talking about a different
> patchset/approach?
That's just how dma_resv works for the exclusive slot.
-Daniel
>
> >
> > It just allows drivers to mess up things in a way which can be easily
> > used to compromise the system.
>
> I must admit I'm a bit lost, so I'm tempted to drop that flag for now
> :-).
>
> [1]https://patchwork.freedesktop.org/patch/443711/?series=92334&rev=3
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Jul 26, 2021 at 05:16:57PM +0200, Maxime Ripard wrote:
> Hi Daniel,
>
> On Wed, Jul 21, 2021 at 02:05:01PM +0200, Daniel Vetter wrote:
> > On Tue, Jul 20, 2021 at 03:45:19PM +0200, Maxime Ripard wrote:
> > > Interactions between bridges, panels, MIPI-DS
On Mon, Jul 26, 2021 at 08:34:14AM +, Simon Ser wrote:
> On Wednesday, July 21st, 2021 at 13:39, Daniel Vetter wrote:
>
> > I think it would be really good to link to
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#modeset-base-object-abstraction
>
ure the
> > GART is clear before unpopulating the TT object sounds like the much
> > more natural thing to do and the state machine is something I certainly
> > don't see in the backend.
> >
>
> I don't think that's the core's responsibility anymore
On Fri, Jul 23, 2021 at 05:43:35PM -0500, Bjorn Helgaas wrote:
> On Fri, Jul 23, 2021 at 10:27:08AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 23, 2021 at 06:51:59AM +0100, Christoph Hellwig wrote:
> > > On Thu, Jul 22, 2021 at 04:29:11PM -0500, Bjorn Helgaas wrote:
> >
On Fri, Jul 23, 2021 at 07:22:46PM +0200, Sam Ravnborg wrote:
> On Fri, Jul 23, 2021 at 10:57:56AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 23, 2021 at 11:12:49AM +0800, lichenyang wrote:
> > > From: Chenyang Li
> > >
> > > This patch adds an initial
, add log messages to
> drm_framebuffer_remove (Daniel)
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_framebuffer.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/driver
On Tue, Jul 27, 2021 at 11:09:13AM +0300, Pekka Paalanen wrote:
> On Mon, 26 Jul 2021 07:50:32 +
> Simon Ser wrote:
>
> > Since there's no struct to attach the docs to, document the IOCTL
> > definition.
> >
> > Signed-off-by: Simon Ser
> > Cc: D
1 - 100 of 23565 matches
Mail list logo
