Hi Nischal,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v5.9-rc1 next-20200819]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On Wed, Aug 19, 2020 at 07:29:24PM -, Patchwork wrote:
> == Series Details ==
>
> Series: Return head pages from find_get_entry and find_lock_entry (rev2)
> URL : https://patchwork.freedesktop.org/series/80818/
> State : failure
>
> == Summary ==
>
> CALLscripts/checksyscalls.sh
>
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via
sysfs").
The bot has tested the following trees: v5.8.1, v5.7.15.
v5.8.1: Failed to apply! Possible dependencies:
On Wed, 2020-08-19 at 12:54 +0100, Chris Wilson wrote:
> Just in case the caller passes in 0 for both slow timeouts, make
> sure we initialise the stack value returned. Add an assert so that we
> don't make the mistake of passing 0 timeouts for the wait.
>
>
== Series Details ==
Series: drm/i915: Initialise outparam for error return from wait_for_register
URL : https://patchwork.freedesktop.org/series/80802/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8907_full -> Patchwork_18373_full
On Thu, 2020-08-13 at 03:28 +, Patchwork wrote:
> Patch Details
> Series: drm/i915: Apply Wa_14011264657:gen11+ (rev2)
> URL: https://patchwork.freedesktop.org/series/78430/
> State:success
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18349/index.html
>
On Wed, 2020-08-12 at 14:07 -0700, Matt Atwood wrote:
> Add minimum width to planes, variable with specific formats for gen11+
> to reflect recent bspec changes.
>
> Signed-off-by: Matt Atwood <
> matthew.s.atw...@intel.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 54
== Series Details ==
Series: series starting with [1/5]
Critical-KclockWork-Fixes-intel_atomi.c-PossibleNull
URL : https://patchwork.freedesktop.org/series/80798/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8907_full -> Patchwork_18371_full
== Series Details ==
Series: drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not
supported
URL : https://patchwork.freedesktop.org/series/80821/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8908 -> Patchwork_18380
On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
> > [...]
> > > > Since both threads seem to have petered out, let me suggest in
> > > > kernel.h:
> > > >
> > > > #define cast_out(ptr, container, member) \
> > > > container_of(ptr, typeof(*container), member)
> > > >
> > > > It does what you
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Replace reloc chain with
terminator on error unwind
URL : https://patchwork.freedesktop.org/series/80795/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8907_full -> Patchwork_18370_full
(adding Ville and Imre to the cc here, they might be interested to know about
this, comments down below)
On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote:
> On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:
> > We're going to be doing the same probing process in nouveau for
> >
On 11.08.2020 03:04, Daniele Ceraolo Spurio wrote:
>
>
> On 8/7/2020 10:46 AM, john.c.harri...@intel.com wrote:
>> From: John Harrison
>>
>> Update to the latest GuC firmware. This includes some significant
>> changes to the interface.
>
> A high level overview of the changes would be nice
== Series Details ==
Series: drm/i915/tgl: Fix stepping WA matching
URL : https://patchwork.freedesktop.org/series/80820/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8908 -> Patchwork_18379
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/tgl: Fix stepping WA matching
URL : https://patchwork.freedesktop.org/series/80820/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0a625a7a4c3e drm/i915/tgl: Fix stepping WA matching
-:180: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' -
Let's not try and use PAT attributes for I915_MAP_WC is the CPU doesn't
support PAT.
Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps")
Signed-off-by: Chris Wilson
Cc: # v5.6+
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +++
1 file changed, 3 insertions(+)
diff
TGL made stepping a litte mess, workarounds refer to the stepping of
the IP(GT or Display) not of the GPU stepping so it would already
require the same solution as used in commit 96c5a15f9f39
("drm/i915/kbl: Fix revision ID checks").
But to make things even more messy it have a different IP
U relocations only")
>
> seems to at least build.
>
> Pavel, does doing those three reverts make things work for you?
Ok, so Chris' patches resulted in (less severe?) crash, let me try this.
pavel@amd:/data/l/linux-next-32$ git reset --hard
8eb858df0a5f6bcd371b5d5637255c987278b8c
pdpt = 31b0b001 *pde =
> > > [ 7744.718500] Oops: 0002 [#1] PREEMPT SMP PTI
> > > [ 7744.718506] CPU: 0 PID: 3004 Comm: Xorg Not tainted
> > > 5.9.0-rc1-next-20200819+ #134
> > > [ 7744.718509] Hardware name: LENOVO 17097HU/17097HU,
PTI
> > [ 7744.718506] CPU: 0 PID: 3004 Comm: Xorg Not tainted
> > 5.9.0-rc1-next-20200819+ #134
> > [ 7744.718509] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 )
> > 03/31/2011
> > [ 7744.718518] EIP: eb_relocate_vma+0xdbf/0xf20
>
> To save me guess
7744.718473] BUG: unable to handle page fault for address: f8c0
> [ 7744.718484] #PF: supervisor write access in kernel mode
> [ 7744.718487] #PF: error_code(0x0002) - not-present page
> [ 7744.718491] *pdpt = 31b0b001 *pde =
> [ 7744.718500] Oops: 0002 [#1]
lt for address: f8c0
[ 7744.718484] #PF: supervisor write access in kernel mode
[ 7744.718487] #PF: error_code(0x0002) - not-present page
[ 7744.718491] *pdpt = 31b0b001 *pde =
[ 7744.718500] Oops: 0002 [#1] PREEMPT SMP PTI
[ 7744.718506] CPU: 0 PID: 3004 Comm: Xorg Not
== Series Details ==
Series: Return head pages from find_get_entry and find_lock_entry (rev2)
URL : https://patchwork.freedesktop.org/series/80818/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK
== Series Details ==
Series: series starting with [1/3] drm/i915/display/tgl: Use TGL DP tables for
eDP ports without low power support
URL : https://patchwork.freedesktop.org/series/80819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8908 -> Patchwork_18377
On Wed, Aug 19, 2020 at 07:48:43PM +0100, Matthew Wilcox (Oracle) wrote:
> Provide this functionality from the swap cache. It's useful for
> more than just mincore().
The build bot showed I was missing this for some configs:
diff --git a/mm/swap_state.c b/mm/swap_state.c
index
On Wed, Aug 19, 2020 at 07:06:17PM -, Patchwork wrote:
> CC mm/swap_state.o
> mm/swap_state.c: In function ‘find_get_swap_page’:
> mm/swap_state.c:435:7: error: implicit declaration of function
> ‘shmem_mapping’; did you mean ‘page_mapping’?
> [-Werror=implicit-function-declaration]
>
On Wed, Aug 19, 2020 at 07:06:17PM -, Patchwork wrote:
> == Series Details ==
>
> Series: Return head pages from find_get_entry and find_lock_entry
> URL : https://patchwork.freedesktop.org/series/80818/
> State : failure
>
> == Summary ==
>
> CALLscripts/checksyscalls.sh
> CALL
== Series Details ==
Series: series starting with [1/3] drm/i915/display/tgl: Use TGL DP tables for
eDP ports without low power support
URL : https://patchwork.freedesktop.org/series/80819/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
368c77e8c5f2 drm/i915/display/tgl: Use
== Series Details ==
Series: Return head pages from find_get_entry and find_lock_entry
URL : https://patchwork.freedesktop.org/series/80818/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
being used when the eDP port don't support low power voltage swing table.
Cc: Lee Shawn C
Cc: Khaled Almahallawy
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 52
This avoids a call to compound_head().
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/filemap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 6594baae7cd2..8c354277108d 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1667,7 +1667,6
The current code does not protect against swapoff of the underlying
swap device, so this is a bug fix as well as a worthwhile reduction in
code complexity.
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/memcontrol.c | 25 ++---
1 file changed, 2 insertions(+), 23 deletions(-)
Avoid bumping the refcount on pages when we're only interested in the
swap entries.
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/proc/task_mmu.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 5066b0251ed8..e42d9e5e9a3c
Update with latest tunning in the table.
BSpec: 21257
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
being used when the eDP port don't support low power voltage swing table.
Cc: Lee Shawn C
Cc: Khaled Almahallawy
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 20 +---
1
i915 does not want to see value entries. Switch it to use
find_lock_page() instead, and remove the export of find_lock_entry().
Signed-off-by: Matthew Wilcox (Oracle)
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 ++--
mm/filemap.c | 1 -
2 files changed, 2
This patch seris started out as part of the THP patch set, but it has
some nice effects along the way and it seems worth splitting it out and
submitting separately.
Currently find_get_entry() and find_lock_entry() return the page
corresponding to the requested index, but the first thing most
There are only three callers remaining of find_get_entry().
find_get_swap_page() is happy to get the head page instead of the subpage.
Add find_subpage() calls to find_lock_entry() and pagecache_get_page()
to avoid auditing all their callers.
Signed-off-by: Matthew Wilcox (Oracle)
---
/boolreturn.cocci
CC: Nischal Varide
Signed-off-by: kernel test robot
---
url:
https://github.com/0day-ci/linux/commits/Nischal-Varide/Critical-KclockWork-Fixes-intel_atomi-c-PossibleNull/20200819-193249
base: git://anongit.freedesktop.org/drm-intel for-linux-next
intel_atomic.c |2 +-
1
Convert the one caller of find_lock_entry() to cope with a head page
being returned instead of the subpage for the index.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/pagemap.h | 12
mm/filemap.c| 25 +++--
mm/shmem.c | 15
Instead of calling find_get_entry() for every page index, use an XArray
iterator to skip over NULL entries, and avoid calling get_page(),
because we only want the swap entries.
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/madvise.c | 21 -
1 file changed, 12 insertions(+),
Provide this functionality from the swap cache. It's useful for
more than just mincore().
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/swap.h | 7 +++
mm/mincore.c | 28 ++--
mm/swap_state.c | 31 +++
3 files
Hi Nischal,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v5.9-rc1 next-20200819]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Quoting Pavel Machek (2020-08-19 18:23:31)
> Hi!
>
> > If we hit an error during construction of the reloc chain, we need to
> > replace the chain into the next batch with the terminator so that upon
> > flushing the relocations so far, we do not execute a hanging batch.
>
> Thanks for the
On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote:
> On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:
> > We're going to be doing the same probing process in nouveau for
> > determining downstream DP port capabilities, so let's deduplicate the
> > work by moving i915's code for
Hi!
> If we hit an error during construction of the reloc chain, we need to
> replace the chain into the next batch with the terminator so that upon
> flushing the relocations so far, we do not execute a hanging batch.
Thanks for the patches. I assume this should fix problem from
"5.9-rc1:
> [...]
> > > Since both threads seem to have petered out, let me suggest in
> > > kernel.h:
> > >
> > > #define cast_out(ptr, container, member) \
> > > container_of(ptr, typeof(*container), member)
> > >
> > > It does what you want, the argument order is the same as
> > > container_of with
On 19. 08. 20, 14:43, Jiri Slaby wrote:
> On 09. 07. 20, 14:33, Daniel Vetter wrote:
>> Exactly matches the one in the helpers.
>
> It's not that exact. The order of modeset_enables and planes is
> different. And this causes a regression -- no fb in qemu.
>
> So if I run drm-tip, no fb.
> If I
On 09. 07. 20, 14:33, Daniel Vetter wrote:
> Exactly matches the one in the helpers.
It's not that exact. The order of modeset_enables and planes is
different. And this causes a regression -- no fb in qemu.
So if I run drm-tip, no fb.
If I revert 73f15a9, it works.
If I then switch the two calls
> > > > > > > >
> > > > > > > > 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.
> > > > > > >
>
Hi!
> > I think there's been some discussion about reverting that change for
> > other reasons, but it's quite likely the culprit.
>
> Hmm. It reverts cleanly, but the end result doesn't work, because of
> other changes.
>
> Reverting all of
>
>763fedd6a216 ("drm/i915: Remove
On 8/19/20 9:24 AM, Allen wrote:
>> [...]
Since both threads seem to have petered out, let me suggest in
kernel.h:
#define cast_out(ptr, container, member) \
container_of(ptr, typeof(*container), member)
It does what you want, the argument order is the same
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST (rev3)
URL : https://patchwork.freedesktop.org/series/78749/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8908 -> Patchwork_18375
Summary
---
On Tue, Aug 11, 2020 at 04:04:56PM -0400, Lyude Paul wrote:
> Since DP 1.3, it's been possible for DP receivers to specify an
> additional set of DPCD capabilities, which can take precedence over the
> capabilities reported at DP_DPCD_REV.
>
> Basically any device supporting DP is going to need
On Tue, Aug 11, 2020 at 04:04:53PM -0400, Lyude Paul wrote:
> And of course, we'll also need to read the sink count from other drivers
> as well if we're checking whether or not it's supported. So, let's
> extract the code for this into another helper.
>
> Signed-off-by: Lyude Paul
> ---
>
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST (rev3)
URL : https://patchwork.freedesktop.org/series/78749/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST (rev3)
URL : https://patchwork.freedesktop.org/series/78749/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
75835fa85a82 drm/i915: Fix sha_text population code
-:72: WARNING:LINE_SPACING: Missing a blank
On Tue, Aug 11, 2020 at 04:04:52PM -0400, Lyude Paul wrote:
> Since other drivers are also going to need to be aware of the sink count
> in order to do proper dongle detection, we might as well steal i915's
> DP_SINK_COUNT helpers and move them into DRM helpers so that other
> dirvers can use them
== Series Details ==
Series: drm/i915: Correct the locking hierarchy in gem, v2.
URL : https://patchwork.freedesktop.org/series/80810/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8908 -> Patchwork_18374
Summary
---
On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:
> We're going to be doing the same probing process in nouveau for
> determining downstream DP port capabilities, so let's deduplicate the
> work by moving i915's code for handling this into a shared helper:
>
Hi Andy,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.9-rc1 next-20200819]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented
On Tue, Aug 11, 2020 at 04:04:46PM -0400, Lyude Paul wrote:
> Just a tiny drive-by cleanup, we can consolidate i915's code for
> checking for MST support into a helper to be shared across drivers.
>
Reviewed-by: Sean Paul
> Signed-off-by: Lyude Paul
> ---
>
== Series Details ==
Series: drm/i915: Correct the locking hierarchy in gem, v2.
URL : https://patchwork.freedesktop.org/series/80810/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Wed, 2020-08-19 at 07:00 -0600, Jens Axboe wrote:
> On 8/18/20 1:00 PM, James Bottomley wrote:
[...]
> > Since both threads seem to have petered out, let me suggest in
> > kernel.h:
> >
> > #define cast_out(ptr, container, member) \
> > container_of(ptr, typeof(*container), member)
> >
>
== Series Details ==
Series: drm/i915: Correct the locking hierarchy in gem, v2.
URL : https://patchwork.freedesktop.org/series/80810/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9d40440069d8 Revert "drm/i915/gem: Async GPU relocations only"
-:6:
Hi,
On 13/08/2020 11:36, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in omapdrm.
>
> Signed-off-by: Thomas Zimmermann
> ---
>
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Cc: Lyude Paul
Reviewed-by: Anshuman Gupta
Reviewed-by: Lyude Paul
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
#v4
Link:
This reverts commit 0f1dd02295f3 ("drm/i915/gem: Split eb_vma into
its own allocation") and also moves all unreserving to a single
place at the end, which is a minor simplification.
With the WW locking, we will drop all references only at the
end when unlocking, so refcounting can now be removed.
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Ensure that execbuf selftests keep passing by using ww handling.
Changes since v2:
- Fix i915_gem_context finally.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
This reverts commit 964a9b0f611ee ("drm/i915/gem: Use chained reloc batches")
and commit 0e97fbb080553 ("drm/i915/gem: Use a single chained reloc batches
for a single execbuf").
When adding ww locking to execbuf, it's hard enough to deal with a
single BO that is part of relocation execution.
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
Signed-off-by: Maarten Lankhorst
Reviewed-by:
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Thomas Hellström
---
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1
Use ww locking for pin_to_display_plane for all the pinning and locking.
With the locking removed from set_cache_level, we need to fix
i915_gem_set_caching_ioctl to take the object reservation lock.
As this is a single lock, we don't need to use the ww dance.
Changes since v1:
- Do not use ww
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.
We also functionally revert ef398881d27d ("drm/i915/gem: Limit
struct_mutex to
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by:
First start with a few reverts, to get to a good starting base for this
series:
- Async gpu relocations are not the way to go, for new platforms we will
disable gpu relocations altogether.
- We also need the relocation slowpath (EFAULT handling) back.
- The eb_vma no longer needs to be
Instead of sharing pages with breadcrumbs, give each timeline a
single page. This allows unrelated timelines not to share locks
any more during command submission.
As an additional benefit, seqno wraparound no longer requires
i915_vma_pin, which means we no longer need to worry about a
potential
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add
This reverts commit 9e0f9464e2ab ("drm/i915/gem: Async GPU relocations only"),
and related commit 7ac2d2536dfa7 ("drm/i915/gem: Delete unused code").
Async GPU relocations are not the path forward, we want to remove
GPU accelerated relocation support eventually when userspace is fixed
to use
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
We want to start requiring the reservation_lock instead of obj->mm.lock
for pinning objects, take the ww lock inside vm_fault_gtt as a first step
towards the legacy lock removal.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file
On Wed, Aug 19, 2020 at 01:46:14PM +0100, Chris Wilson wrote:
> 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
Chris Wilson writes:
> We want to recognise future devices (gen = -1u) and treat them as an
> extension of the latest known device, which is typically true.
>
> Signed-off-by: Chris Wilson
CI failures looked to be unrelated to those changes so
Acked-by: Lukasz Fiedorowicz
> ---
>
On Wed, Aug 19, 2020 at 07:17:19AM -0600, Jens Axboe wrote:
> On 8/19/20 6:11 AM, Greg KH wrote:
> > On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
> >> On 8/18/20 1:00 PM, James Bottomley wrote:
> >>> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> On 8/17/20 12:48 PM,
On Wed, Aug 19, 2020 at 02:43:28PM +0200, Jiri Slaby wrote:
> On 09. 07. 20, 14:33, Daniel Vetter wrote:
> > Exactly matches the one in the helpers.
>
> It's not that exact. The order of modeset_enables and planes is
> different. And this causes a regression -- no fb in qemu.
Does
On 8/19/20 6:11 AM, Greg KH wrote:
> On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
>> On 8/18/20 1:00 PM, James Bottomley wrote:
>>> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
On 8/17/20 12:48 PM, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens
On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
> On 8/18/20 1:00 PM, James Bottomley wrote:
> > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> >> On 8/17/20 12:48 PM, Kees Cook wrote:
> >>> On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
> On 8/17/20 12:29 PM,
On 8/18/20 1:00 PM, James Bottomley wrote:
> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
>> On 8/17/20 12:48 PM, Kees Cook wrote:
>>> On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
On 8/17/20 12:29 PM, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens
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 new tasklet_setup()
> >> and
1 - 100 of 126 matches
Mail list logo
