On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
>
> On Thu, 11 Mar 2021, Lee Jones wrote:
>
> > On Thu, 11 Mar 2021, Daniel Vetter wrote:
> >
> > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote:
> > > > On Fri, 05 Mar 2021, Roland Scheidegge
On Sat, Mar 6, 2021 at 1:44 AM Brian Welty wrote:
>
>
> On 2/11/2021 7:34 AM, Daniel Vetter wrote:
> > On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote:
> >>
> >> On 2/9/2021 2:54 AM, Daniel Vetter wrote:
> >>> On Tue, Jan 26, 2021 at 01:
> Christian König (1):
> drm/ttm: make ttm_bo_unpin more defensive
>
> Junlin Yang (1):
> drm/omap: dsi: fix unsigned expression compared with zero
>
> drivers/gpu/drm/omapdrm/dss/dsi.c | 7 ---
> include/drm/ttm/ttm_bo_api.h | 6 --
> 2 files
array_create(int
> > num_fences,
> > bool dma_fence_match_context(struct dma_fence *fence, u64 context);
> > +struct dma_fence *dma_fence_array_first(struct dma_fence *head);
> > +struct dma_fence *dma_fence_array_next(struct dma_fence *head,
> > + unsigned int index);
> > +
> > #endif /* __LINUX_DMA_FENCE_ARRAY_H */
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote:
>
> On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
> >
> > On Thu, 11 Mar 2021, Lee Jones wrote:
> >
> > > On Thu, 11 Mar 2021, Daniel Vetter wrote:
> > >
> > > > On Mon, Mar 08, 2021
> - * callers need to make sure to eventually unreference the returned property
> + * callers need to make sure to eventually unreferenced the returned property
> * again, using drm_property_blob_put().
> *
> * Return:
> --
> 2.26.2
>
--
Daniel Vetter
Software Engin
int ret;
>
> + /* PWRITE is disallowed for all platforms after TGL-LP. This also
> + * covers all platforms with local memory.
> + */
> + if (INTEL_GEN(i915) >= 12 && !IS_TIGERLAKE(i915))
> + return -EOPNOTSUPP;
> +
> if
ttm_tt_shrinker_scan(&mm_shrinker, &sc));
> + memalloc_nofs_restore(flags);
> fs_reclaim_release(GFP_KERNEL);
>
> return 0;
> --
> 2.25.1
>
> ___
> dri-devel m
On Fri, Mar 19, 2021 at 08:24:07AM +, Lee Jones wrote:
> On Thu, 18 Mar 2021, Daniel Vetter wrote:
>
> > On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote:
> > >
> > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
> > > >
&g
On Fri, Mar 19, 2021 at 07:53:48PM +0100, Christian König wrote:
> Am 19.03.21 um 18:52 schrieb Daniel Vetter:
> > On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian König wrote:
> > > Don't print a warning when we fail to allocate a page for swapping things
> > >
On Mon, Mar 01, 2021 at 10:52:53AM +0100, Daniel Vetter wrote:
> Nothing checks userptr.ro except this call to pup_fast, which means
> there's nothing actually preventing userspace from writing to this.
> Which means you can just read-only mmap any file you want, userptr it
> and
On Mon, Mar 01, 2021 at 02:26:01AM -0800, John Hubbard wrote:
> On 3/1/21 01:52, Daniel Vetter wrote:
> > There's no mmu notifier or anything like that, releasing this pin is
> > entirely up to userspace. Hence FOLL_LONGTERM.
> >
> > No cc: stable for this patch s
where c is the color buffer
> tile
> + * size in bytes covered by one entry in the status buffer and s is the
> number
> + * of status bits per entry.
Might be worth it to go into alignment/rounding/stride requirements
here too, if you know them. Either way lgtm.
Acked-by: Daniel Vett
On Sat, Mar 20, 2021 at 10:04 AM Christian König
wrote:
>
> Am 19.03.21 um 20:06 schrieb Daniel Vetter:
> > On Fri, Mar 19, 2021 at 07:53:48PM +0100, Christian König wrote:
> >> Am 19.03.21 um 18:52 schrieb Daniel Vetter:
> >>> On Fri, Mar 19, 2021 at 03:08:
share some insight on this?
It's the official registry for drm_fourcc codes and drm modifiers.
Whether the kernel ever uses it or not doesn't matter.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mail
On Mon, Mar 22, 2021 at 12:22 PM Christian König
wrote:
>
> Don't print a warning when we fail to allocate a page for swapping things out.
>
> v2: only stop the warning
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
It is kinda surprising that page al
d between multiple
> clients.
>
> Otherwise series seems to work. Failing tests can be blacklisted going
> forward. Ack to merge and merge itself, after review, I leave to maintainers
> since personally I am not supportive of this mechanism.
Yeah I think we have some leftovers to look
On Sun, Mar 21, 2021 at 03:18:28PM +0100, Christian König wrote:
> Am 20.03.21 um 14:17 schrieb Daniel Vetter:
> > On Sat, Mar 20, 2021 at 10:04 AM Christian König
> > wrote:
> > > Am 19.03.21 um 20:06 schrieb Daniel Vetter:
> > > > On Fri, Mar 19, 2021 at 07:
On Mon, Mar 22, 2021 at 10:20:45AM +0100, Lucas Stach wrote:
> Hi Christian,
>
> Am Montag, dem 22.03.2021 um 09:54 +0100 schrieb Christian Gmeiner:
> > Am Sa., 20. März 2021 um 20:11 Uhr schrieb Daniel Vetter :
> > >
> > > On Sat, Mar 20, 2021 at 10:28
WARNING: use scnprintf or sprintf
>
> Signed-off-by: Tian Tao
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_sysfs.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> i
> #else
> -#define vga_put(pdev, rsrc)
> +static inline void vga_put(struct pci_dev *pdev, unsigned int rsrc)
> +{
> +}
> #endif
>
>
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > - if (!(local.flags & BIT(bit)))
> > - continue;
> > -
> > - err = fn[bit](dst, src);
> > - if (err)
> > - return err;
> > - }
> > -
> > - return 0;
> > + return -EINVA
d/amdkfd/kfd_topology.h | 10 +-
> include/uapi/linux/kfd_ioctl.h| 171 +-
> 26 files changed, 4681 insertions(+), 249 deletions(-)
> create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
> create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_migrate.h
> cre
On Mon, Mar 22, 2021 at 02:05:48PM +, Matthew Wilcox wrote:
> On Mon, Mar 22, 2021 at 02:49:27PM +0100, Daniel Vetter wrote:
> > On Sun, Mar 21, 2021 at 03:18:28PM +0100, Christian König wrote:
> > > Am 20.03.21 um 14:17 schrieb Daniel Vetter:
> > > > On Sat, Mar
On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin
wrote:
>
>
> On 22/03/2021 14:09, Daniel Vetter wrote:
> > On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote:
> >>
> >> On 19/03/2021 22:38, Jason Ekstrand wrote:
> >>> This API allows one con
it cite ' will give you the nice reference with
> > 12 chars of sha1 regardless of core.abbrev config.
> >
> >
> > BR,
> > Jani.
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
> ___
> dri-devel mailing list
> dri-devel@lists.free
On Mon, Mar 22, 2021 at 4:31 PM Tvrtko Ursulin
wrote:
>
>
> On 22/03/2021 14:57, Daniel Vetter wrote:
> > On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 22/03/2021 14:09, Daniel Vetter wrote:
> >>> On
;
> +
> + fence = drm_syncobj_fence_get(eb.gem_context->syncobj);
> + err = i915_request_await_dma_fence(eb.request, fence);
> + if (err)
> + goto err_ext;
> + }
> +
> if (in_fence) {
> if (args->flags & I915_EXEC
On Mon, Mar 22, 2021 at 5:06 PM Michal Hocko wrote:
>
> On Mon 22-03-21 14:05:48, Matthew Wilcox wrote:
> > On Mon, Mar 22, 2021 at 02:49:27PM +0100, Daniel Vetter wrote:
> > > On Sun, Mar 21, 2021 at 03:18:28PM +0100, Christian König wrote:
> > > > Am 20.03.
On Mon, Mar 22, 2021 at 5:07 PM Felix Kuehling wrote:
>
> Am 2021-03-22 um 10:15 a.m. schrieb Daniel Vetter:
> > On Mon, Mar 22, 2021 at 06:58:16AM -0400, Felix Kuehling wrote:
> >> Since the last patch series I sent on Jan 6 a lot has changed. Patches 1-33
> >> are
fc) to get gem/gt back
on track, like we've e.g. done with DAL/DC to get that in shape.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Jason Ekstrand
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/TODO.txt | 36 +++
1 f
Motivated by the pre-review process for i915 gem/gt features, but
probably useful in general for complex stuff.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Jason Ekstrand
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
Documentation/gpu/index.rst | 1 +
Documentation/gpu
On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote:
> On Mon 22-03-21 20:34:25, Christian König wrote:
> > Am 22.03.21 um 18:02 schrieb Daniel Vetter:
> > > On Mon, Mar 22, 2021 at 5:06 PM Michal Hocko wrote:
> > > > On Mon 22-03-21 14:05:48, Matthew Wilco
ficial to other graphis drivers moving forward as well.
>
> Cc: Christian Koenig
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: linux...@kvack.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Si
t; means there should not be a performance difference anymore, but this
> needs to be verified.
>
> Cc: Christian Koenig
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: linux...@kvack.org
> Cc: dri-devel@lists.freedeskto
On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote:
> On Tue, 23 Mar 2021, Daniel Vetter wrote:
> > We've discussed a bit how to get the gem/gt team better integrated
> > and collaborate more with the wider community and agreed to the
> > following:
> &
On Tue, Mar 23, 2021 at 12:51:13PM +0100, Christian König wrote:
>
>
> Am 23.03.21 um 12:46 schrieb Michal Hocko:
> > On Tue 23-03-21 12:28:20, Daniel Vetter wrote:
> > > On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote:
> > [...]
> > > > &g
On Tue, Mar 23, 2021 at 08:37:07AM -0400, Rodrigo Vivi wrote:
> On Tue, Mar 23, 2021 at 09:44:53AM +0100, Daniel Vetter wrote:
> > Motivated by the pre-review process for i915 gem/gt features, but
> > probably useful in general for complex stuff.
> >
> > Cc: Jani Niku
On Tue, Mar 23, 2021 at 01:04:03PM +0100, Michal Hocko wrote:
> On Tue 23-03-21 12:48:58, Christian König wrote:
> > Am 23.03.21 um 12:28 schrieb Daniel Vetter:
> > > On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote:
> > > > I think this is where I don
On Tue, Mar 23, 2021 at 09:44:52AM +0100, Daniel Vetter wrote:
> We've discussed a bit how to get the gem/gt team better integrated
> and collaborate more with the wider community and agreed to the
> following:
>
> - all gem/gt patches are reviewed on dri-devel for now. That
On Tue, Mar 23, 2021 at 08:34:55AM -0400, Rodrigo Vivi wrote:
> On Tue, Mar 23, 2021 at 12:57:39PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote:
> > > On Tue, 23 Mar 2021, Daniel Vetter wrote:
> > > > We've discuss
On Tue, Mar 23, 2021 at 09:14:36AM +, Tvrtko Ursulin wrote:
>
> On 22/03/2021 16:43, Daniel Vetter wrote:
> > On Mon, Mar 22, 2021 at 4:31 PM Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 22/03/2021 14:57, Daniel Vetter wrote:
> >
e we would put that in here but it would be good to call out.
I'll add a suggestion to that extend, it's a good one.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Mar 24, 2021 at 04:15:37AM +0200, Laurent Pinchart wrote:
> On Wed, Jan 20, 2021 at 06:38:03PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 20, 2021 at 6:12 PM Paul Cercueil wrote:
> > > Le mer. 20 janv. 2021 à 17:03, Daniel Vetter a écrit :
> > > > On Wed
ake scheduler changes going
> forward. Second is that, together with deleting the CLONE_CONTEXT API,
> we should now have a 1:1 mapping between intel_context and
> intel_timeline which may help us reduce locking.
Yeah I think this captures everything we need to say here.
Acked-by: Daniel V
5_gem_execbuffer.c
> > index 96403130a373d..2e9748c1edddf 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -3295,6 +3295,16 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> >
gt;
> >
> > Also, I feel like this code to install "pte_special" huge pages does
> > not belong in the drm subsystem..
>
> I could add helpers in huge_memory.c:
>
> vmf_insert_pfn_pmd_prot_special() and
> vmf_insert_pfn_pud_prot_special()
sk3.amr.corp.intel.com
> >
> Hmm, yes with that patch it will obviously not work as intended.
>
> Given that, I think we'll need to disable the TTM huge pages for now until
> we can sort out and agree on using a page table entry bit.
Yeah :-/
I think going full pud
;open));
>
> spin_lock(&obj->vma.lock);
> - vma = vma_lookup(obj, vm, view);
> + vma = i915_vma_lookup(obj, vm, view);
> spin_unlock(&obj->vma.lock);
>
> /* vma_create() will resolve the race if another
ages of the object into kernel space */
> >> void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
> >> + struct i915_gem_ww_ctx *ww,
> >> enum i915_map_type type)
> >> {
> >> enum i915_map_type has_type;
> >> @@ -408,13 +409,25 @@ void *i915_gem_object_pin_map(struct
> >> drm_i915_gem_object *obj,
> >> void *i915_gem_object_pin_map_unlocked(struct drm_i915_gem_object *obj,
> >>enum i915_map_type type)
> >> {
> >> + struct i915_gem_ww_ctx ww;
> >> void *ret;
> >> + int err;
> >>
> >> - i915_gem_object_lock(obj, NULL);
> >> - ret = i915_gem_object_pin_map(obj, type);
> >> - i915_gem_object_unlock(obj);
> >> + i915_gem_ww_ctx_init(&ww, true);
> >> +retry:
> >> + err = i915_gem_object_lock(obj, &ww);
> >> + if (!err)
> >> + ret = i915_gem_object_pin_map(obj, &ww, type);
> >> + if (IS_ERR(ret))
> > This looks a little dodgy, since ret might not be initialized here,
> > say if we encounter an error when grabbing the lock?
> >
> > Also maybe s/ret/ptr/? Seeing ret makes me think it's a plain integer.
>
> Ack, good catch!
>
> Will send a new version to fix it.
Can you pls just update this patch with in-reply-to? I'm starting to
apply.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
t_has_pages(obj)) {
> + if (!__i915_gem_object_put_pages_locked(obj)) {
> try_to_writeback(obj, shrink);
> count += obj->base.size >> PAGE_SHIFT;
>
if (err)
> + return err;
> +
> + err = i915_gem_object_lock_interruptible(obj, NULL);
> + if (!err) {
> + /*
> + * Since we only check validity, not use the pages,
> + * it doesn't matter
alloc a page with relevant gfp attributes, copy and
> add_to_swap_cache()? Or perhaps that doesn't work well from a shrinker
> either?
So before we toss everything and go an a great rewrite-the-world tour,
what if we just try to split up big objects. So for objects which are
On Wed, Mar 24, 2021 at 01:00:28PM +0100, Christian König wrote:
> Am 24.03.21 um 12:55 schrieb Daniel Vetter:
> > On Wed, Mar 24, 2021 at 11:19:13AM +0100, Thomas Hellström (Intel) wrote:
> > > On 3/23/21 4:45 PM, Christian König wrote:
> > > > Am 23.03.21
r = i915_gem_object_lock(vma->obj, &ww);
> + if (!err)
> + err = i915_vma_pin_ww(vma, &ww, size, alignment, flags);
> + if (err == -EDEADLK) {
> + err = i915_gem_ww_ctx_backoff(&ww);
> + if (!err)
> + goto retry;
> +
i915_gem_object_unpin_map(obj);
> }
> + i915_gem_object_unlock(obj);
> }
> }
>
> --
> 2.31.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
>
+ (write_domain ? I915_WAIT_ALL : 0),
> + MAX_SCHEDULE_TIMEOUT);
> + if (write_domain)
> + i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
> + }
>
> -out_unpin:
> -
sh);
> - if (ret) {
> - i915_gem_object_unlock(obj);
> - return ret;
> - }
> + if (ret)
> + goto err_unpin;
>
> - fence = i915_gem_object_lock_fence(obj);
> i915_gem_object_finish_access(obj);
> i
> +
> i915_vma_unpin_and_release(&batch, 0);
> out_scratch:
> i915_vma_unpin_and_release(&scratch, 0);
> @@ -820,7 +855,7 @@ static int scrub_whitelisted_registers(struct
> intel_context *ce)
> if (IS_ERR(batch))
> return PTR_ERR(batch);
>
> - cs = i915_gem_object_pin_map(batch-
ni(&ww);
> +
> + if (err)
> + return err;
>
> return len;
> }
> --
> 2.31.0
>
> ___
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
(rq);
>
> - cmd = i915_gem_object_pin_map(obj, I915_MAP_WC);
> + cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
> if (IS_ERR(cmd)) {
> err = PTR_ERR(cmd);
> goto out_vm;
> --
> 2.31.0
>
> _
again. */
> --
> 2.31.0
>
> ___
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
sizeof(cache->node));
> mutex_lock(&ggtt->vm.mutex);
> --
> 2.31.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
I915_MAP_WC);
> if (IS_ERR(time)) {
> err = PTR_ERR(time);
> goto out_obj;
> --
> 2.31.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.
On Wed, Mar 24, 2021 at 07:15:36PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 24, 2021 at 06:00:12PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 23, 2021 at 04:50:52PM +0100, Maarten Lankhorst wrote:
> > > We get a lockdep splat when the reset mutex is held, because it can b
l it a false positive, that's always a
bit a bold statement for lockdep splats which needs extroadinary evidence.
So maybe drop that part.
Also maybe good to reference the commit which added async ggtt pte writes
for reference here.
With those things on the commit message addressed:
Acked-by:
t; struct intel_vgpu *vgpu;
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 2e4f06eaacc1..fc92fed7a04a 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i91
On Wed, Mar 24, 2021 at 09:52:11AM -0300, Jason Gunthorpe wrote:
> On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
> > follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
On Wed, Mar 24, 2021 at 01:07:44PM +0100, Christian König wrote:
>
>
> Am 24.03.21 um 13:01 schrieb Daniel Vetter:
> > On Wed, Mar 24, 2021 at 01:00:28PM +0100, Christian König wrote:
> > > Am 24.03.21 um 12:55 schrieb Daniel Vetter:
> > > > On Wed, Mar
ount;
> - mm_shrinker.scan_objects = ttm_tt_shrinker_scan;
> - mm_shrinker.seeks = 1;
> - return register_shrinker(&mm_shrinker);
> -}
> + if (!ttm_pages_limit)
> + ttm_pages_limit = num_pages;
>
>
w it's
just the TODO file
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Jason Ekstrand
Cc: Dave Airlie
Acked-by: Dave Airlie
Acked-by: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/TODO.txt | 41 +++
1 file changed, 41 insert
Airlie
Acked-by: Rodrigo Vivi
Acked-by: Dave Airlie
Signed-off-by: Daniel Vetter
---
Documentation/gpu/index.rst | 1 +
Documentation/gpu/rfc.rst | 17 +
2 files changed, 18 insertions(+)
create mode 100644 Documentation/gpu/rfc.rst
diff --git a/Documentation/gpu/index.rst b
On Thu, Mar 25, 2021 at 9:07 AM Christian König
wrote:
>
> Am 24.03.21 um 20:29 schrieb Daniel Vetter:
> > On Wed, Mar 24, 2021 at 02:48:45PM +0100, Christian König wrote:
> >> The shrinker based approach still has some flaws. Especially that we need
> >> tempor
vers/gpu/drm/xen/xen_drm_front_conn.h
> > @@ -16,7 +16,6 @@
> > struct drm_connector;
> > struct xen_drm_front_drm_info;
> >
> > -struct xen_drm_front_drm_info;
> >
> > int xen_drm_front_conn_init(struct xen_drm_fro
'll fix for tomorrow.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Mar 25, 2021 at 10:16 AM Daniel Vetter wrote:
>
> On Thu, Mar 25, 2021 at 7:53 AM Oleksandr Andrushchenko
> wrote:
> >
> > Hi,
> >
> > On 3/25/21 8:19 AM, Wan Jiabing wrote:
> > > struct xen_drm_front_drm_info has been declared.
> > > R
On Thu, Mar 25, 2021 at 10:27 AM Christian König
wrote:
>
> Am 25.03.21 um 09:31 schrieb Daniel Vetter:
> > On Thu, Mar 25, 2021 at 9:07 AM Christian König
> > wrote:
> >> Am 24.03.21 um 20:29 schrieb Daniel Vetter:
> >>> On Wed, Mar 24, 2021 at
7;t stable
> >> and
> >> can be zapped and refaulted under us while we do the walk.
> > I didn't say it would be simple :) But we also need to stop hacking
> > around the sides of all this huge page stuff and come up with sensible
> > APIs that drivers
On Thu, Mar 25, 2021 at 10:48 AM Tvrtko Ursulin
wrote:
>
>
> On 24/03/2021 17:18, Jason Ekstrand wrote:
> > On Wed, Mar 24, 2021 at 6:36 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 24/03/2021 09:52, Daniel Vetter wrote:
> >>> On
arily) required.
> > Changes since v6:
> > - Ensure userptr validity is checked in set_domain through a special path.
> > Changes since v7:
> > - Chane kvfree to kvfree().
>
> v8: Change "Chane kvfree to kvfree()" to "Change kfree() to kvfree()" ?
ries.
On the series: Acked-by: Daniel Vetter
> ---
> tests/meson.build | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/tests/meson.build b/tests/meson.build
> index 54a1a3c7..8e3cd390 100644
> --- a/tests/meson.build
> +++ b/tests/meson.build
>
On Wed, Mar 24, 2021 at 08:17:10PM +0100, Daniel Vetter wrote:
> On Wed, Mar 24, 2021 at 09:52:11AM -0300, Jason Gunthorpe wrote:
> > On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > > Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
) contained somewhere separate (Jason)
Cc: Simon Ser
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Jason Ekstrand
Cc: Dave Airlie
Acked-by: Jason Ekstrand
Acked-by: Simon Ser
Acked-by: Rodrigo Vivi
Acked-by: Dave Airlie
Signed-off-by: Daniel Vetter
---
Documentation/gpu/index.rst
d i915_request_cancel().
>
> Associated timeout value is stored in rq->context.watchdog.timeout_us.
>
> v2:
> * Log expiration.
>
> v3:
> * Include more information about user timeline in the log message.
>
> v4:
> * Remove obsolete comment and fix formatting
niel
>
> > skipped by the execlists_schedule_in (which is called per ELSP port, not
> > per request).
> >
> > Signed-off-by: Tvrtko Ursulin
> Reviewed-by: Matthew Auld
> ___
> Intel-gfx mailing list
> intel-...@lis
t; Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vetter
> Acked-by: Daniel Vetter
Entire series merged, thanks for the patches.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +++--
> drivers/gpu/drm/i915/i915_params.c | 5 +
> drivers/gpu/drm/i915/i915_
On Thu, Mar 25, 2021 at 11:58:59PM +0100, Daniel Vetter wrote:
> Motivated by the pre-review process for i915 gem/gt features, but
> probably useful in general for complex stuff.
>
> v2: Add reminder to not forget userspace projects in the discussion
> (Simon, Jason)
>
>
drivers/gpu/drm/i915/i915_params.h| 1 +
> drivers/gpu/drm/i915/i915_request.c | 129 ++-
> drivers/gpu/drm/i915/i915_request.h | 16 +-
> drivers/gpu/drm/i915/selftests/i915_request.c | 201 ++
> 17 files changed, 479 insertions
ocess doc (me)
- i915_ prefix for vma_lookup (Liam Howlett) just because I spotted it
and put it in here too
Ashutosh Dixit (1):
drm/i915: Disable pread/pwrite ioctl's for future platforms (v3)
Chris Wilson (1):
drm/
On Fri, Mar 26, 2021 at 2:31 PM Jani Nikula wrote:
>
> On Fri, 26 Mar 2021, Daniel Vetter wrote:
> > The rough plan we discussed somewhat ad-hoc with Jani&Rodrigo (Joonas was
> > out this week, but back next) is that they send out a pull with what's
> > the
renoir_ppt.c| 9 +-
> drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c | 12 ---
> drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 28 +
> drivers/gpu/drm/amd/pm/swsmu/smu_cmn.h | 2 +
> drivers/gpu/drm/radeon/radeon_asic.c | 3 +
> drive
On Wed, Jan 13, 2021 at 10:08 PM Chris Wilson wrote:
> Quoting Daniel Vetter (2021-01-13 20:50:11)
> > On Wed, Jan 13, 2021 at 4:43 PM Chris Wilson
> > wrote:
> > >
> > > Quoting Daniel Vetter (2021-01-13 14:06:04)
> > > > We have too many peopl
cluded should have been very small.
-Daniel
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Jan 14, 2021 at 4:27 AM Jerome Glisse wrote:
>
> On Wed, Jan 13, 2021 at 09:31:11PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 13, 2021 at 5:56 PM Jerome Glisse wrote:
> > > On Fri, Jan 08, 2021 at 03:40:07PM +0100, Daniel Vetter wrote:
> > > > On Thu,
On Thu, Jan 14, 2021 at 10:23 AM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2021-01-14 09:02:57)
> > On Wed, Jan 13, 2021 at 10:08 PM Chris Wilson
> > wrote:
> > > Quoting Daniel Vetter (2021-01-13 20:50:11)
> > > > On Wed, Jan 13, 2021
initializer
> macro.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vc4/vc4_bo.c | 14 --
> drivers/gpu/drm/vc4/vc4_drv.c | 7 +--
> drivers/gpu/drm/vc4/vc4_drv.h | 3 ---
> 3 files changed, 1 insertion(+), 23 del
On Thu, Jan 14, 2021 at 09:45:37AM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2021-01-14 09:30:32)
> > On Thu, Jan 14, 2021 at 10:23 AM Chris Wilson
> > wrote:
> > > The only other problem I see with the implementation is that there's
> > > n
On Thu, Jan 14, 2021 at 10:11:01AM +0100, Daniel Vetter wrote:
> On Thu, Jan 14, 2021 at 10:04 AM Jani Nikula
> wrote:
> >
> > On Wed, 13 Jan 2021, Lee Jones wrote:
> > > On Wed, 13 Jan 2021, Sam Ravnborg wrote:
> > >
> > >> Hi Lee,
> > &
On Thu, Jan 14, 2021 at 10:26 AM Daniel Vetter wrote:
>
> On Thu, Jan 14, 2021 at 4:27 AM Jerome Glisse wrote:
> >
> > On Wed, Jan 13, 2021 at 09:31:11PM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 13, 2021 at 5:56 PM Jerome Glisse wrote:
> > > > O
On Thu, Jan 14, 2021 at 11:49 AM Christian König
wrote:
>
> Am 13.01.21 um 17:56 schrieb Jerome Glisse:
> > On Fri, Jan 08, 2021 at 03:40:07PM +0100, Daniel Vetter wrote:
> >> On Thu, Jan 07, 2021 at 11:25:41AM -0500, Felix Kuehling wrote:
> >>> Am 2021-01-07 u
701 - 800 of 23565 matches
Mail list logo
