cache sharing of the physical pages, we need to
explicitly flush the cache lines of those pages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c | 8 ++--
drivers/gpu/drm/drm_gem_shmem_helper.c | 8 +++-
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2
Quoting Daniel Vetter (2020-10-09 17:16:06)
> On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson wrote:
> >
> > vgem is a minimalistic driver that provides shmemfs objects to
> > userspace that may then be used as an in-memory surface and transported
> > across dma-buf t
elper.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/vgem/vgem_drv.c | 281 ++--
drivers/gpu/drm/vgem/vgem_drv.h | 11 --
3 files changed, 13 insertions(+), 280 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gp
Quoting Souza, Jose (2020-10-06 18:46:45)
> +Rodrigo and Jani
>
> On Tue, 2020-10-06 at 14:56 +, Kamati Srinivas wrote:
> > Removing force probe protection from EHL platform. Did
> > not observe warnings, errors, flickering or any visual
> > defects while doing ordinary tasks like browsing and
Quoting Gustavo A. R. Silva (2020-09-25 16:35:12)
> Hi all,
>
> Friendly ping: who can take this?
We had picked up the same patch from Dan Carpenter, thanks.
commit 68ba71e3ae6dd86a23486655e33c5f8c9bd90777
Author: Dan Carpenter
Date: Fri Sep 11 10:52:43 2020 +0300
drm/i915: Fix an error
Quoting Jason A. Donenfeld (2020-09-28 11:35:07)
> It seems likely this block was pasted from internal_get_user_pages_fast,
> which is not passed an mm struct and therefore uses current's. But
> __get_user_pages_locked is passed an explicit mm, and current->mm is not
> always valid. This was hit wh
Quoting Jani Nikula (2020-08-19 13:34:41)
> On Wed, 19 Aug 2020, Chris Wilson wrote:
> > Quoting Andy Shevchenko (2020-08-19 12:53:53)
> >> In preparation for unconditionally passing the struct tasklet_struct
> >> pointer to all tasklet callbacks, switch to using the n
Quoting Andy Shevchenko (2020-08-19 12:53:53)
> In preparation for unconditionally passing the struct tasklet_struct
> pointer to all tasklet callbacks, switch to using the new tasklet_setup()
> and from_tasklet() to pass the tasklet pointer explicitly.
>
> Signed-off-by: Andy Shevchenko
Reviewed
Quoting Jordan Crouse (2020-08-13 00:55:44)
> This is an RFC because I'm still trying to grok the correct behavior.
>
> Consider a dma_fence_array created two two fence and signal_on_any is true.
> A reference to dma_fence_array is taken for each waiting fence.
>
> When the client calls dma_fence
engine->gt;
> > - int err;
> > + int err = 0;
>
> you don't need the initialization here.
But it's close enough that I can munge the patch inline.
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Daniel Vetter (2020-07-27 20:32:45)
> On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson wrote:
> >
> > An unfortunate sequence of events, but it turns out there is a valid
> > usecase for being able to free/decouple the driver objects before they
> > are freed by
Quoting Tang, CQ (2020-07-23 18:44:08)
>
>
> > -Original Message-
> > From: Chris Wilson
> > Sent: Thursday, July 23, 2020 10:21 AM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org; Chris Wilson
> >
is freed so that concurrent access (e.g. debugfs)
does not following the dangling pointer.
The legacy marker was adding in the code movement from drp_fops.c to
drm_file.c
References: 9acdac68bcdc ("drm: rename drm_fops.c to drm_file.c")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
C
the pointers within the context are stable and will remain valid
as we inspect their tables.
Signed-off-by: Chris Wilson
Cc: CQ Tang
Cc: Daniel Vetter
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i
peek at the drm core objects. If the context is closed during the
peeking, we may attempt to dereference a stale core object.
Signed-off-by: Chris Wilson
Cc: CQ Tang
Cc: Daniel Vetter
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_drv.c | 7 ++-
1 file changed, 6 insertions(+), 1
Quoting Jisheng Zhang (2020-07-17 07:11:38)
> The i915 doesn't depend on IOSF_MBI, asm/iosf_mbi.h already defines
> isof_mbi_* APIs when ISOF_MBI is disabled.
>
> Don't force IOSF_MBI to allow disabling IOSF_MBI for non SoC platforms.
But it is required for Valleyview/Cherryview and we want to su
Quoting Daniel Vetter (2020-07-15 15:03:34)
> On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson wrote:
> > There's a further problem in that we call INIT_LIST_HEAD on the
> > dma_fence_cb before the signal callback. So even if list_empty_careful()
> > confirms the dma
Quoting Chris Wilson (2020-07-15 13:21:43)
> Quoting Daniel Vetter (2020-07-15 13:10:22)
> > On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > > When waiting with a callback on the stack, we must remove the callback
> > > upon wait completion. Since t
Quoting Daniel Vetter (2020-07-15 13:10:22)
> On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > When waiting with a callback on the stack, we must remove the callback
> > upon wait completion. Since this will be notified by the fence signal
> > callback, the r
ady signaled before we take the contended lock.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/dma-fence.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 8d5bdfce638e..b910d7bc0854 100644
--- a/drivers/dma-buf/dma-fence.c
++
Rearrange the code to pull the operations beore the fence->lock critical
section, and remove a small amount of redundancy:
Function old new delta
dma_fence_add_callback 156 145 -11
Signed-off-by: Chris Wilson
---
driv
Quoting Bas Nieuwenhuizen (2020-07-15 11:23:35)
> Hi Chris,
>
> My concern with going in this direction was that we potentially allow
> an application to allocate a lot of kernel memory but not a lot of fds
> by creating lots of fences and then closing the fds but never
> signaling them. Is that n
d1fb30d ("dma-buf/sw_sync: Synchronize signal vs syncpt free")
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Chris Wilson
Cc: Gustavo Padovan
Cc: Christian König
Cc:
---
drivers/dma-buf/sw_sync.c | 32 +++-
1 file changed, 7 insertions(+), 25 deletions(-
let's add a few trivial selftests to make sure that once
fixed again, it stays fixed.
Signed-off-by: Chris Wilson
Cc: Bas Nieuwenhuizen
Reviewed-by: Bas Nieuwenhuizen
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-sw_sync.c
dma_fence_release() objects to a fence being freed before it is
signaled, so instead of playing fancy tricks to avoid handling dying
requests, let's keep the syncpt alive until signaled. This neatly
removes the issue with having to decouple the syncpt from the timeline
upon fence release.
-Chris
Quoting YueHaibing (2020-07-15 04:21:04)
> It is not used since commit 058179e72e09 ("drm/i915/gt: Replace
> hangcheck by heartbeats")
>
> Signed-off-by: YueHaibing
Indeed, it is no more.
Reviewed-by: Chris Wilson
-Chris
___
the callback out of the timeline obj->lock.
Fixes: d3c6dd1fb30d ("dma-buf/sw_sync: Synchronize signal vs syncpt free")
Cc: Sumit Semwal
Cc: Chris Wilson
Cc: Gustavo Padovan
Cc: Christian König
Cc:
Signed-off-by: Bas Nieuwenhuizen
Signed-off-by: Chris Wilson
--
in the sync_pt as we cannot use the common
fence->lock trick to find our parent anymore.
Suggested-by: Bas Nieuwenhuizen
Signed-off-by: Chris Wilson
Cc: Bas Nieuwenhuizen
---
drivers/dma-buf/sw_sync.c| 40 +---
drivers/dma-buf/sync_debug.c | 2 +-
drivers/
let's add a few trivial selftests to make sure that once
fixed again, it stays fixed.
Signed-off-by: Chris Wilson
Cc: Bas Nieuwenhuizen
Reviewed-by: Bas Nieuwenhuizen
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-sw_sync.c
Take 2. dma_fence_parent() relied on fence->lock pointing into the
sync_timeline which is no more, so we need a sync_pt->timeline
backpointer instead.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailma
Nieuwenhuizen
Signed-off-by: Chris Wilson
Cc: Bas Nieuwenhuizen
---
drivers/dma-buf/sw_sync.c| 33 -
drivers/dma-buf/sync_debug.h | 2 ++
2 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index
let's add a few trivial selftests to make sure that once
fixed again, it stays fixed.
Signed-off-by: Chris Wilson
Cc: Bas Nieuwenhuizen
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-sw_sync.c | 279 +++
dr
Since we decouple the sync_pt from the timeline tree upon release, in
order to allow releasing the sync_pt from a signal callback we need to
separate the sync_pt signaling lock from the timeline tree lock.
Suggested-by: Bas Nieuwenhuizen
Signed-off-by: Chris Wilson
Cc: Bas Nieuwenhuizen
the callback out of the timeline obj->lock.
Fixes: d3c6dd1fb30d ("dma-buf/sw_sync: Synchronize signal vs syncpt free")
Cc: Sumit Semwal
Cc: Chris Wilson
Cc: Gustavo Padovan
Cc: Christian König
Cc:
Signed-off-by: Bas Nieuwenhuizen
Signed-off-by: Chris Wilson
--
Quoting Chris Wilson (2020-07-14 19:30:39)
> Quoting Bas Nieuwenhuizen (2020-07-14 19:17:21)
> > On Tue, Jul 14, 2020 at 6:26 PM Chris Wilson
> > wrote:
> > >
> > > Quoting Bas Nieuwenhuizen (2020-07-14 16:41:02)
> > > &g
Quoting Bas Nieuwenhuizen (2020-07-14 19:17:21)
> On Tue, Jul 14, 2020 at 6:26 PM Chris Wilson wrote:
> >
> > Quoting Bas Nieuwenhuizen (2020-07-14 16:41:02)
> > > Calltree:
> > > timeline_fence_release
> > > drm_sched_entity_wakeup
> > > d
e nobody will be able to trigger
>the release function from the signal function.
>
> Fixes: d3c6dd1fb30d ("dma-buf/sw_sync: Synchronize signal vs syncpt free")
> Cc: Sumit Semwal
> Cc: Chris Wilson
> Cc: Gustavo Padovan
> Cc: Christian König
> Cc:
> Signed-of
Quoting Colin King (2020-07-13 15:25:51)
> From: Colin Ian King
>
> There is an error condition where err is not being set and an uninitialized
> garbage value in err is being returned. Fix this by assigning err to an
> appropriate error return value before taking the error exit path.
>
> Addre
Quoting Sudeep Holla (2020-07-09 16:49:31)
> Both cmp_u32 and cmp_u64 are comparing the pointers instead of the value
> at those pointers. This will result in incorrect/unsorted list. Fix it
> by deferencing the pointers before comparison.
>
> Cc: Chris Wilson
> Cc: Mika Kuop
ncorrectly fault in remote pages belonging to another
device, where there may not even be a struct page.
v2: Use the default drm_gem_dumb_map_offset() callback
Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
Cc: # v4.
ncorrectly fault in remote pages belonging to another
device, where there may not even be a struct page.
v2: Use the default drm_gem_dumb_map_offset() callback
Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
Cc: # v4.
Quoting Daniel Vetter (2020-07-08 10:56:19)
> On Tue, Jul 07, 2020 at 05:00:12PM +0100, Chris Wilson wrote:
> > drm_gem_dumb_map_offset() now exists and does everything
> > vgem_gem_dump_map does and *ought* to do.
> >
> > Signed-off-by: Chris Wilson
> > ---
>
Quoting lepton (2020-07-07 19:17:51)
> On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote:
> >
> > Quoting lepton (2020-07-07 18:05:21)
> > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson
> > > wrote:
> > > >
> > > > If we assign ob
Quoting lepton (2020-07-07 18:05:21)
> On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote:
> >
> > If we assign obj->filp, we believe that the create vgem bo is native and
> > allow direct operations like mmap() assuming it behaves as backed by a
> > shmemfs inode. Wh
s: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Signed-off-by: Chris Wilson
Cc: Lepton Wu
Cc: Daniel Vetter
Cc: Christian König
Cc: Thomas Hellström (Intel)
Cc: # v4.13+
---
drivers/gpu/drm/vgem/vgem_drv.c | 27 +--
1 file changed, 17 insertions(
drm_gem_dumb_map_offset() now exists and does everything
vgem_gem_dump_map does and *ought* to do.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/vgem/vgem_drv.c | 28 +---
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b
Quoting Thomas Hellström (Intel) (2020-07-07 13:05:31)
>
> On 7/7/20 1:07 PM, Chris Wilson wrote:
> > Quoting Christian König (2020-07-07 11:58:26)
> >> Am 07.07.20 um 10:59 schrieb Daniel Vetter:
> >>> On Tue, Jul 7, 2020 at 9:27 AM Lepton Wu wrote:
> >&
Quoting Christian König (2020-07-07 11:58:26)
> Am 07.07.20 um 10:59 schrieb Daniel Vetter:
> > On Tue, Jul 7, 2020 at 9:27 AM Lepton Wu wrote:
> >> For pages which are allocated in ttm with transparent huge pages,
> >> tail pages have zero as reference count. The current vgem code use
> >> get_pa
Quoting Lepton Wu (2020-07-07 05:21:00)
> For pages which are allocated in ttm with transparent huge pages,
> tail pages have zero as reference count. The current vgem code use
> get_page on them and it will trigger BUG when release_pages get called
> on those pages later.
>
> Here I attach the mi
efine OAREPORTTRIG5_EDGE_LEVEL_TRIGGER_SELECT_MASK 0x /* 0=level */
Ok, these names are not copied straight from the docs, so renaming them
will not hinder us when finding the relevant fields.
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Lionel Landwerlin (2020-06-26 13:21:00)
> Trying to explain a bit how this thing works. In my opinion diagrams
> are a bit easier to understand than words.
>
> Signed-off-by: Lionel Landwerlin
> ---
> drivers/dma-buf/dma-fence-chain.c | 37 +++
> 1 file change
Quoting Lionel Landwerlin (2020-06-25 14:23:25)
> On 25/06/2020 16:18, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-06-25 13:34:43)
> >> There was probably a misunderstand on how the dma-fence-chain is
> >> supposed to work or what dma_fence_chain_find_seqno()
Quoting Lionel Landwerlin (2020-06-25 13:34:43)
> There was probably a misunderstand on how the dma-fence-chain is
> supposed to work or what dma_fence_chain_find_seqno() is supposed to
> return.
>
> dma_fence_chain_find_seqno() is here to give us the fence to wait upon
> for a particular point in
Quoting Daniel Vetter (2020-06-19 10:43:09)
> On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2020-06-19 09:51:59)
> > > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson
> > > wrote:
> > > > Forcing a generic primiti
Quoting Daniel Vetter (2020-06-19 09:51:59)
> On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson
> wrote:
> > Forcing a generic primitive to always be part of the same global map is
> > horrible.
>
> And no concrete example or reason for why that's not possible.
> B
Quoting Daniel Stone (2020-06-11 10:01:46)
> Hi,
>
> On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote:
> > On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote:
> > > Introducing a global lockmap that cannot capture the rules correctly,
> >
> > Can you docu
"drm/i915/gt: Prevent timeslicing into unpreemptable
> requests")
> Signed-off-by: Gustavo A. R. Silva
Fair enough, I had sent out a patch that included this, but never split
it out for early adoption.
Reviewed-by: Chris Wilson
-Chris
___
Quoting Sumit Semwal (2020-06-16 13:42:13)
> Hello,
>
> If there are no objections to this, I will plan to merge it soon.
I was going to suggest running it against our CI, but that's unavailable
at the moment.
There's a particularly nasty BUG_ON() in dma_buf_release that we hit
irregularly, that
rwise.
>
> v3: Kerneldoc.
>
> v4: Some spelling fixes from Mika
>
> Cc: Mika Kuoppala
> Cc: Thomas Hellstrom
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-...@list
:
> https://lore.kernel.org/lkml/b08611018fdb6d88757c6008a5c02fa0e07b32fb.ca...@perches.com
> Signed-off-by: Kees Cook
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Daniel Vetter (2020-06-04 10:21:46)
> On Thu, Jun 4, 2020 at 10:57 AM Thomas Hellström (Intel)
> wrote:
> >
> >
> > On 6/4/20 10:12 AM, Daniel Vetter wrote:
> > ...
> > > Thread A:
> > >
> > > mutex_lock(A);
> > > mutex_unlock(A);
> > >
> > > dma_fence_signal();
> > >
> >
Quoting Arnd Bergmann (2020-05-29 21:43:47)
> On Fri, May 29, 2020 at 10:26 PM Chris Wilson
> wrote:
> > Quoting Arnd Bergmann (2020-05-29 21:15:26)
>
> > >
> > > diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
> > > b/drivers/gpu/drm/selfte
Quoting Arnd Bergmann (2020-05-29 21:15:26)
> The check_reserve_boundaries() function has a large array on the stack,
> over 500 bytes. It gets inlined into __igt_reserve, which has multiple
> other large structures as well but stayed just under the stack size
> warning limit of 1024 bytes until on
Quoting Nirmoy (2020-05-29 16:40:53)
> This works correctly most of the times but sometimes
>
> 20k insertions can take more than 8 times of 10k insertion time.
The pressure is on to improve then :)
> Regards,
>
> Nirmoy
>
> On 5/29/20 6:33 PM, Nirmoy Das wrote:
> > This patch introduces fragm
Quoting Nirmoy Das (2020-05-29 15:04:01)
> Fixes: 0cdea4455acd350a ("drm/mm: optimize rb_hole_addr rbtree search")
Hmm. Indeed. Now, do you have a test case on your end that hits this?
One of us should add one for drm-mm.
-Chris
___
dri-devel mailing lis
Quoting Nirmoy Das (2020-05-28 14:05:56)
> This patch introduces fragmentation in the address range
> and measures time taken by 10k insertions for each modes.
>
> ig_frag() will fail if one of the mode takes more than 1 sec.
If you cc intel-...@lists.freedesktop.org, the test case will be run
by
Quoting Nirmoy Das (2020-05-28 14:05:56)
> This patch introduces fragmentation in the address range
> and measures time taken by 10k insertions for each modes.
>
> ig_frag() will fail if one of the mode takes more than 1 sec.
>
> Output:
>
> [ 37.326723] drm_mm: igt_sanitycheck - ok!
> [ 37.
Quoting Arnd Bergmann (2020-05-27 15:05:10)
> gcc has a problem following values through IS_ERR/PTR_ERR macros,
> leading to a false-positive warning in allmodconfig, with any
> compiler version:
>
> In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5892:
> drivers/gpu/drm/i915/gt/selftest
or: 'rsvd' may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
>
> I could not figure out a good way to do this in a way that gcc
> understands better, so initialize the variable to zero, as last
> resort.
Does it look neater if we initialise it
there are not a lot of them elsewhere.
gcc v8:
add/remove: 1/0 grow/shrink: 0/1 up/down: 99/-164 (-65)
Function old new delta
engine_sample - 99 +99
i915_sample 871 707-164
Which is c
eadonly bit is static, that would be interesting
if that was allowed to change mid gup :)
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting John Hubbard (2020-05-22 00:38:41)
> Include FOLL_FAST_ONLY in the list of flags to *not* WARN()
> on, in internal_get_user_pages_fast().
>
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jani Nikula
> Cc: "Joonas Lahtinen"
> C
Quoting John Hubbard (2020-05-19 01:21:20)
> This needs to go through Andrew's -mm tree, due to adding a new gup.c
> routine. However, I would really love to have some testing from the
> drm/i915 folks, because I haven't been able to run-time test that part
> of it.
CI hit
<4> [185.667750] WARNIN
Quoting Ayaz A Siddiqui (2020-05-21 11:41:52)
> In order to avoid functional breakage of mis-programmed applications that
> have grown to depend on unused MOCS entries. It has been decided to
> program those entries to be equal to fully cached ("L3 + LLC") entry.
"It has been" appears to be you ha
Quoting Emil Velikov (2020-05-20 15:25:05)
> Reviewed-by: Emil Velikov
>
> I'm half way through checking the callers and I've noticed a handful of bugs.
> Will send the series in due time, although your patch is a perfect
> intermediate solution.
Pushed the compromise patch. That should keep us
Quoting Nirmoy (2020-05-20 17:28:04)
> Hi Chris,
>
> On 5/20/20 12:56 AM, Chris Wilson wrote:
> > Quoting Nirmoy Das (2020-05-19 09:44:36)
> >> +#define DRM_MM_ALIGN_SHIFT 6
> >> #define HOLE_SIZE(NODE) ((NODE)->hole_size)
> >> #define H
/0x20
[ 11.584434] do_syscall_64+0x5f/0x240
[ 11.584438] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 11.584440] RIP: 0033:0x7f0ef80f7227
Reported-by: Nirmoy Das
Fixes: b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and
__drm_gem_object_put()")
Signed-off-by: Chris
Quoting Christian König (2020-05-20 13:54:55)
> Am 20.05.20 um 14:49 schrieb Chris Wilson:
> > Quoting Christian König (2020-05-20 13:19:42)
> >> Am 20.05.20 um 14:14 schrieb Nirmoy Das:
> >>> drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
&g
Quoting Christian König (2020-05-20 13:19:42)
> Am 20.05.20 um 14:14 schrieb Nirmoy Das:
> > drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
> > [ 11.584209] BUG: kernel NULL pointer dereference, address:
> >
> > [ 11.584213] #PF: supervisor write access
Quoting Nirmoy Das (2020-05-19 09:44:36)
> +#define DRM_MM_ALIGN_SHIFT 6
> #define HOLE_SIZE(NODE) ((NODE)->hole_size)
> #define HOLE_ADDR(NODE) (__drm_mm_hole_node_start(NODE))
> +#define HOLE_SIZE_ALIGN(NODE) ((NODE->hole_size << DRM_MM_ALIGN_SHIFT) | \
> + ffs(HOLE
gt; + rb_hole_addr);
> +
> + new->subtree_max_hole = old->subtree_max_hole;
> + augment_callbacks_compute_max_hole(old, false);
> +}
> +
> +static const struct rb_augment_callbacks augment_callbacks = {
> + .propagate = augment_callbacks_propagate,
> + .copy = augment_callbacks_copy,
> + .rotate = augment_callbacks_rotate
> +};
Faithful expansion of the macros,
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Nirmoy Das (2020-05-19 09:44:36)
> Userspace can still abuse alignment while allocating buffer object
> to slow down rb_hole_addr rbtree search. This patch improves search
> in fragmented rb_hole_addr rbtree by storing maximum subtree hole
> alignment and use that to skip a complete subtree
ot;VMware Graphics"
> Cc: Oded Gabbay
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Christian König
Quoting Aishwarya Ramakrishnan (2020-05-18 16:03:36)
> Prefer ARRAY_SIZE instead of using sizeof
>
> Fixes coccicheck warning: Use ARRAY_SIZE
>
> Signed-off-by: Aishwarya Ramakrishnan
Reviewed-by: Chris Wilson
-Chris
___
dri-devel m
Quoting Emil Velikov (2020-05-18 17:23:21)
> On Sat, 16 May 2020 at 22:23, Chris Wilson wrote:
> >
> > drivers/gpu/drm/drm_client_modeset.c: In function
> > ‘drm_client_firmware_config’:
> > ./include/linux/bits.h:26:28: warning: comparison of unsigned expression <
Quoting Daniel Vetter (2020-05-18 15:47:44)
> On Sat, May 16, 2020 at 10:23:28PM +0100, Chris Wilson wrote:
> > drivers/gpu/drm/drm_client_modeset.c: In function
> > ‘drm_client_firmware_config’:
> > ./include/linux/bits.h:26:28: warning: comparison of unsigned expression <
Quoting Christophe JAILLET (2020-05-17 09:50:49)
> The label of the last gotos must be switched for the error handling code to
> work as expected.
>
> Fixes: 83bc4ec37210 ("drm/mm: Add a search-by-address variant to only inspect
> a single hole")
> Signed-off-by: Christophe JAILLET
> ---
> driv
drivers/gpu/drm/drm_client_modeset.c: In function ‘drm_client_firmware_config’:
./include/linux/bits.h:26:28: warning: comparison of unsigned expression < 0 is
always false [-Wtype-limits]
__builtin_constant_p((l) > (h)), (l) > (h), 0)))
Signed-off-by: Chris Wilson
---
driver
drivers/gpu/drm/drm_dp_helper.c:1598: warning: Function parameter or member
'dp_rev' not described in 'drm_dp_set_phy_test_pattern'
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_dp_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_dp_he
ed_release(struct drm_device *dev)
Fixes: c6603c740e0e ("drm: add managed resources tied to drm_device")
Signed-off-by: Chris Wilson
Cc: Sam Ravnborg
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_managed.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_managed
g: missing braces around
initializer
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 70455e304a26..1bdf3cfeeebb 10
erfluous inlines")
> Signed-off-by: Arnd Bergmann
Reviewed-b: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ld test robot
> Signed-off-by: Nathan Chancellor
I forgot to ping Mika about this,
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Daniel Vetter (2020-05-12 10:08:47)
> On Tue, May 12, 2020 at 10:04:22AM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2020-05-12 09:59:29)
> > > Design is similar to the lockdep annotations for workers, but with
> > > some twists:
> > >
h calls, defeating the point. Therefore these annotations
> cannot be sprinkled over the code entirely mindless to avoid false
> positives.
>
> v2: handle soft/hardirq ctx better against write side and dont forget
> EXPORT_SYMBOL, drivers can't use this otherwise.
>
> Cc:
ists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Christian König
> Signed-off-by: Daniel Vetter
> ---
> drivers/dma-buf/dma-fence.c | 3 +++
> 1
Quoting Daniel Vetter (2020-05-11 10:54:33)
> - worse, neither vk nor gl (to my knowledge) have a concept of events
> for when the gpu died. The only stuff you have is things like
> arb_robustness which says a) everything continues as if nothing
> happened b) there's a function where
Quoting Daniel Vetter (2020-05-11 10:11:41)
> No need to micro-optmize when we're waiting in a mocked object ...
It's setting up the expected return values for the test.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.free
Now that atomic64_fetch_add() exists we can use it to return the base
context id, rather than the atomic64_add_return(N) - N concoction.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/dma-buf/dma-fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Quoting Jason Ekstrand (2020-05-07 16:36:00)
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is
> only supported by iris which nev
101 - 200 of 3784 matches
Mail list logo
