== Series Details ==
Series: SAGV support for Gen12+ (rev10)
URL : https://patchwork.freedesktop.org/series/75129/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Start passing latency as parameter
Okay!
Commit: drm/i915: Eliminate magic numb
== Series Details ==
Series: SAGV support for Gen12+ (rev10)
URL : https://patchwork.freedesktop.org/series/75129/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
39ffd9923dd5 drm/i915: Start passing latency as parameter
a35112134535 drm/i915: Eliminate magic numbers "0" and "1"
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
v3: Forbid si
That is a preparation patch before next one where we
introduce old_bw_state and a bunch of other changes
as well.
In a review comment it was suggested to split out
at least that renaming into a separate patch, what
is done here.
v2: Removed spurious space
Reviewed-by: Ville Syrjälä
Signed-off-by
We need a new PCode request commands and reply codes
to be added as a prepartion patch for QGV points
restricting for new SAGV support.
v2: - Extracted those changes into separate patch
(Ville Syrjälä)
v3: - Moved new PCode masks to another place from
PCode commands(Ville)
Signed-off
Let's refactor the whole SAGV logic, moving
the main calculations from intel_can_enable_sagv
to intel_compute_sagv_mask, which also handles
this in a unified way calling gen specific
functions to evaluate if SAGV is allowed for
each crtc. If crtc sagv mask have been changed
we serialize access and
Addressing one of the comments, recommending to extract platform
specific code from intel_can_enable_sagv as a preparation, before
we are going to add support for tgl+.
Current code in intel_can_enable_sagv is valid only for skl,
so this patch adds also proper support for icl, subsequent
patches w
== Series Details ==
Series: SAGV support for Gen12+ (rev5)
URL : https://patchwork.freedesktop.org/series/75129/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/
Add correspondent helpers to be able to get old/new bandwidth
global state object.
v2: - Fixed typo in function call
v3: - Changed new functions naming to use convention proposed
by Jani Nikula, i.e intel_bw_* in intel_bw.c file.
v4: - Change function naming back to intel_atomic* pattern,
== Series Details ==
Series: SAGV support for Gen12+ (rev4)
URL : https://patchwork.freedesktop.org/series/75129/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/
Add correspondent helpers to be able to get old/new bandwidth
global state object.
v2: - Fixed typo in function call
v3: - Changed new functions naming to use convention proposed
by Jani Nikula, i.e intel_bw_* in intel_bw.c file.
v4: - Change function naming back to intel_atomic* pattern,
On 2020.03.31 09:26:44 -0700, Rodrigo Vivi wrote:
> On Tue, Mar 31, 2020 at 03:00:25PM +0800, Zhenyu Wang wrote:
> >
> > Hi,
> >
> > Here's more queued gvt fixes for 5.7. Please see details below.
> >
> > Thanks
> > --
> > The following changes since commit a61ac1e75105a077ec1efd6923ae3c619f8623
== Series Details ==
Series: drm/i915/perf: Do not clear pollin for small user read buffers (rev7)
URL : https://patchwork.freedesktop.org/series/75085/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8242 -> Patchwork_17191
Hi Imre
I guess I did all the requested changes but trybot got some
warnings that I will need more time to understand and fix it.
If you have time please check if is this way that you are asking:
https://github.com/zehortigoza/linux/tree/tccold-v3
Trybot warnings:
https://intel-gfx-ci.01.org/tr
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is smal
On Fri, 2020-03-13 at 18:48 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the final DP_TP_CTL frobbing of port sync to the master
> encoder's enable hook. Now neatly out of sight from the high level
> modeset code.
>
> And thus we've eliminated all the special casing of port sync
>
On Fri, 2020-03-13 at 18:48 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently only port sync pipes do the sequence such that
> we first do the modeset part for every pipe and then do
> the plane/etc. updates. Let's follow that apporach for
> all pipes in skl+ so that we can properly
On Fri, 2020-03-13 at 18:48 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Don't assume there is just one port sync slave. We might have
> several.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 98 ++--
>
> 1 file changed, 49 in
On Thu, Mar 26, 2020 at 04:49:55PM -0700, Swathi Dhanavanthri wrote:
> This workaround now applies to all steppings, not just A0.
> Wa_1409085225 is a temporary A0-only W/A however it is
> identical to Wa_14010229206 and hence the combined workaround
> is made permanent.
> Bspec: 52890
>
> Signed-
== Series Details ==
Series: drm/i915/selftests: Check for has-reset before testing hostile contexts
(rev2)
URL : https://patchwork.freedesktop.org/series/74915/
State : failure
== Summary ==
Applying: drm/i915/selftests: Check for has-reset before testing hostile
contexts
Using index info t
Quoting Pavel Machek (2020-04-02 22:35:07)
> [258096.980089] 3 locks held by kswapd0/1034:
> [258096.980096] #0: 85851c80 (fs_reclaim){}, at:
> __fs_reclaim_acquire+0x0/0x30
> [258096.980114] #1: 85850b40 (shrinker_rwsem){}, at:
> shrink_slab.constprop.79+0x38/0x270
> [2
Hi!
Hardware is thinkpad x220. I had this crash few days ago. And today I
have similar-looking one, with slightly newer kernel. (Will post as a
follow-up).
Any idea what can be wrong?
Pavel
Hi Dave and Daniel,
Here goes drm-intel-next-fixes-2020-04-02:
Only gvt fixes on this round:
- Fix non-privilege access warning (Tina)
- Fix display port type (Tina)
- BDW cmd parser missed SWTESS_BASE_ADDRESS (Yan)
- Bypass length check of LRI (Yan)
- Fix one klocwork warning (Tina)
Thanks,
Ro
In order to kill off a hostile context, we need to be able to reset the
GPU. So check that is supported prior to beginning the test.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 3 +++
1 fil
Chris Wilson writes:
> Now that we can peek at GEM->engines[] and obtain a reference to them
> using RCU, do so for instances where we can safely iterate the
> potentially old copy of the engines. For setting, we can do this when we
> know the engine properties are copied over before swapping, so
Quoting Mika Kuoppala (2020-04-02 21:16:52)
> Chris Wilson writes:
>
> > If we receive the error interrupt before the CS interrupt, we may find
> > ourselves without an active request to reset, skipping the GPU reset.
> > All because the attempt to reset was too early.
> >
>
> With the tracing,
Chris Wilson writes:
> If we cannot trust the reset will flush out the CS event queue such that
> process_csb() reports an accurate view of HW, we will need to search the
> active and pending contexts to determine which was actually running at
> the time we issued the reset.
>
> Signed-off-by: Ch
Chris Wilson writes:
> If we receive the error interrupt before the CS interrupt, we may find
> ourselves without an active request to reset, skipping the GPU reset.
> All because the attempt to reset was too early.
>
With the tracing, we will see the the out of sync situations
so
Reviewed-by:
== Series Details ==
Series: drm/i915: Keep a per-engine request pools (rev2)
URL : https://patchwork.freedesktop.org/series/75427/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8238 -> Patchwork_17189
Summary
---
**
== Series Details ==
Series: drm/i915/gt: move remaining debugfs interfaces into gt (rev3)
URL : https://patchwork.freedesktop.org/series/75333/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8238 -> Patchwork_17188
Summary
Chris Wilson writes:
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:205: warning: Excess function
> parameter 'supported' description in 'intel_uc_fw_init_early'
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:205: warning: Excess function
> parameter 'platform' description in 'intel_uc_fw_init_early'
>
Add a tiny per-engine request mempool so that we should always have a
request available for powermanagement allocations from tricky
contexts. This reserve is expected to be only used for kernel
contexts when barriers must be emitted [almost] without fail.
The main consumer for this reserved reques
Add a tiny per-engine request mempool so that we should always have a
request available for powermanagement allocations from tricky
contexts. This reserve is expected to be only used for kernel
contexts when barriers must be emitted [almost] without fail.
This is an alternative to using a comparat
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_rcs_topology
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forcewake_user
|
+--
== Series Details ==
Series: drm/i915/gt: move remaining debugfs interfaces into gt (rev3)
URL : https://patchwork.freedesktop.org/series/75333/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
db515ae2c79c drm/i915/gt: move remaining debugfs interfaces into gt
-:119: WARNING:FILE
== Series Details ==
Series: drm/i915: Use per-engine request pools (rev8)
URL : https://patchwork.freedesktop.org/series/75415/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8238 -> Patchwork_17187
Summary
---
**SUC
Quoting Andi Shyti (2020-04-02 18:44:17)
> static const struct drm_info_list i915_debugfs_list[] = {
> {"i915_capabilities", i915_capabilities, 0},
> {"i915_gem_objects", i915_gem_object_info, 0},
> @@ -1862,10 +1484,8 @@ static const struct drm_info_list i915_debugfs_list[]
> = {
On Thu, Mar 26, 2020 at 08:36:57PM +0200, Stanislav Lisovskiy wrote:
> According to BSpec 53998, we should try to
> restrict qgv points, which can't provide
> enough bandwidth for desired display configuration.
>
> Currently we are just comparing against all of
> those and take minimum(worst case)
== Series Details ==
Series: drm/i915: Use per-engine request pools (rev7)
URL : https://patchwork.freedesktop.org/series/75415/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8238 -> Patchwork_17186
Summary
---
**SUC
On Thu, Mar 26, 2020 at 08:10:03PM +0200, Stanislav Lisovskiy wrote:
> That is a preparation patch before next one where we
> introduce old_bw_state and a bunch of other changes
> as well.
> In a review comment it was suggested to split out
> at least that renaming into a separate patch, what
> is
On Thu, Mar 26, 2020 at 08:10:02PM +0200, Stanislav Lisovskiy wrote:
> We need a new PCode request commands and reply codes
> to be added as a prepartion patch for QGV points
> restricting for new SAGV support.
>
> v2: - Extracted those changes into separate patch
> (Ville Syrjälä)
>
> Sign
On Thu, Mar 26, 2020 at 08:39:59PM +0200, Stanislav Lisovskiy wrote:
> Let's refactor the whole SAGV logic, moving
> the main calculations from intel_can_enable_sagv
> to intel_compute_sagv_mask, which also handles
> this in a unified way calling gen specific
> functions to evaluate if SAGV is allo
Add a per-engine request mempool so that we should always have a couple
of requests available for powermanagement allocations from tricky
contexts. These reserves are expected to be only used for kernel
contexts when barriers must be emitted [almost] without fail.
When using the mempool, requests
Add a per-engine request mempool so that we should always have a couple
of requests available for powermanagement allocations from tricky
contexts. These reserves are expected to be only used for kernel
contexts when barriers must be emitted [almost] without fail.
When using the mempool, requests
Add a per-engine request mempool so that we should always have a couple
of requests available for powermanagement allocations from tricky
contexts. These reserves are expected to be only used for kernel
contexts when barriers must be emitted [almost] without fail.
When using the mempool, requests
On Thu, Apr 02, 2020 at 07:20:59PM +0300, Ville Syrjälä wrote:
> On Thu, Mar 26, 2020 at 08:09:59PM +0200, Stanislav Lisovskiy wrote:
> > Add correspondent helpers to be able to get old/new bandwidth
> > global state object.
> >
> > v2: - Fixed typo in function call
> > v3: - Changed new functions
On Thu, Mar 26, 2020 at 08:10:00PM +0200, Stanislav Lisovskiy wrote:
> Addressing one of the comments, recommending to extract platform
> specific code from intel_can_enable_sagv as a preparation, before
> we are going to add support for tgl+.
>
> Current code in intel_can_enable_sagv is valid onl
On Thu, Apr 02, 2020 at 07:28:43PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Apr 02, 2020 at 07:17:52PM +0300, Ville Syrjälä wrote:
> > On Thu, Mar 26, 2020 at 08:09:57PM +0200, Stanislav Lisovskiy wrote:
> > > According to many computer science sources - magic values
> > > in code _are_ _bad_.
On 2020-04-02 at 20:59:21 +0530, Manna, Animesh wrote:
>
> On 02-04-2020 18:15, Anshuman Gupta wrote:
> >On 2020-04-01 at 21:23:28 +0530, Manna, Animesh wrote:
> >thanks animesh for review!
> >>On 31-03-2020 17:07, Anshuman Gupta wrote:
> >>>New i915_pm_lpsp igt solution approach relies on connect
On Thu, Apr 02, 2020 at 07:17:52PM +0300, Ville Syrjälä wrote:
> On Thu, Mar 26, 2020 at 08:09:57PM +0200, Stanislav Lisovskiy wrote:
> > According to many computer science sources - magic values
> > in code _are_ _bad_. For many reasons: the reason is that "0"
> > or "1" or whatever magic values c
On Thu, Mar 26, 2020 at 08:09:59PM +0200, Stanislav Lisovskiy wrote:
> Add correspondent helpers to be able to get old/new bandwidth
> global state object.
>
> v2: - Fixed typo in function call
> v3: - Changed new functions naming to use convention proposed
> by Jani Nikula, i.e intel_bw_* i
== Series Details ==
Series: drm/i915: Use per-engine request pools (rev5)
URL : https://patchwork.freedesktop.org/series/75415/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8238 -> Patchwork_17185
Summary
---
**FAI
On Thu, Mar 26, 2020 at 08:09:57PM +0200, Stanislav Lisovskiy wrote:
> According to many computer science sources - magic values
> in code _are_ _bad_. For many reasons: the reason is that "0"
> or "1" or whatever magic values confuses and doesn't give any
> info why this parameter is this value an
On 02/04/2020 15:07, Chris Wilson wrote:
Quoting Chris Wilson (2020-04-02 15:00:57)
Feed a fresh i915 mmap into a read(perf_fd) to teach lockdep about the
potential lock chains should we take a pagefault into our vm_fault
handlers from within perf.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursu
== Series Details ==
Series: series starting with [01/23] perf/core: Only copy-to-user after
completely unlocking all locks, v2.
URL : https://patchwork.freedesktop.org/series/75423/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8238 -> Patchwork_17184
===
Add a per-engine request mempool so that we should always have a couple
of requests available for powermanagement allocations from tricky
contexts. These reserves are expected to be only used for kernel
contexts when barriers must be emitted [almost] without fail.
When using the mempool, requests
On 02-04-2020 18:15, Anshuman Gupta wrote:
On 2020-04-01 at 21:23:28 +0530, Manna, Animesh wrote:
thanks animesh for review!
On 31-03-2020 17:07, Anshuman Gupta wrote:
New i915_pm_lpsp igt solution approach relies on connector specific
debugfs attribute i915_lpsp_info, it exposes whether an o
Add a per-engine request mempool so that we should always have a couple
of requests available for powermanagement allocations from tricky
contexts. These reserves are expected to be only used for kernel
contexts when barriers must be emitted [almost] without fail.
When using the mempool, requests
== Series Details ==
Series: series starting with [01/23] perf/core: Only copy-to-user after
completely unlocking all locks, v2.
URL : https://patchwork.freedesktop.org/series/75423/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e9bb8bda08c5 perf/core: Only copy-to-user after
== Series Details ==
Series: perf/core: Only copy-to-user after completely unlocking all locks, v2.
URL : https://patchwork.freedesktop.org/series/75422/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8238 -> Patchwork_17183
== Series Details ==
Series: perf/core: Only copy-to-user after completely unlocking all locks, v2.
URL : https://patchwork.freedesktop.org/series/75422/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
edcfb0ee5b6f perf/core: Only copy-to-user after completely unlocking all locks
On Thu, Apr 02, 2020 at 04:52:03PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 01, 2020 at 06:53:17PM -0400, Giacomo Comes wrote:
> > Hi,
> > on my Intel Compute Stick STCK1 (baytrail hdmi audio)
> > sound is not working with the kernel 5.6
> >
> > I have bisected the kernel and I found the commit
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.
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Maarten Lankhorst
---
.../gpu/d
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context
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 La
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i
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 take
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
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
This conflicts with the ww mutex handling, which needs to drop
the references after gpu submission anyway, because otherwise we
may risk unlocking a BO after first freeing it.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/
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 fin
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 intel_engine_pm_get/
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 9 -
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rend
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
drivers/g
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: M
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
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 inserti
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..e35e8d0b6938 100644
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
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insert
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
---
drivers/g
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 ww_
We inadvertently create a dependency on mmap_sem with a whole chain.
This breaks any user who wants to take a lock and call rcu_barrier(),
while also taking that lock inside mmap_sem:
<4> [604.892532] ==
<4> [604.892534] WARNING: possible circul
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 call
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
---
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 pass
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 us
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+),
== Series Details ==
Series: drm/i915/gem: Utilize rcu iteration of context engines (rev3)
URL : https://patchwork.freedesktop.org/series/75270/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8238 -> Patchwork_17181
Summary
We inadvertently create a dependency on mmap_sem with a whole chain.
This breaks any user who wants to take a lock and call rcu_barrier(),
while also taking that lock inside mmap_sem:
<4> [604.892532] ==
<4> [604.892534] WARNING: possible circul
Quoting Chris Wilson (2020-04-02 15:00:57)
> Feed a fresh i915 mmap into a read(perf_fd) to teach lockdep about the
> potential lock chains should we take a pagefault into our vm_fault
> handlers from within perf.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> tests/perf_pmu.c | 3
Feed a fresh i915 mmap into a read(perf_fd) to teach lockdep about the
potential lock chains should we take a pagefault into our vm_fault
handlers from within perf.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/perf_pmu.c | 39 +++
1 file changed,
On Thu, 2020-04-02 at 13:16 +0100, Chris Wilson wrote:
> Add a per-engine request mempool so that we should always have a couple
> of requests available for powermanagement allocations from tricky
> contexts. These reserves are expected to be only used for kernel
> contexts when barriers must be em
On Wed, Apr 01, 2020 at 03:48:26PM -0700, Manasi Navare wrote:
> On Wed, Feb 12, 2020 at 07:43:51PM +0200, Jani Nikula wrote:
> > On Wed, 12 Feb 2020, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Make the PFIT_PIPE stuff less ugly via parametrization.
> > >
> > > Signed-off-by: Vill
On Wed, Apr 01, 2020 at 04:53:23PM -0700, Manasi Navare wrote:
> On Wed, Feb 12, 2020 at 06:17:34PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Most of the pfit functions are of the form:
> >
> > func()
> > {
> > if (pfit_enabled) {
> > ...
> > }
> > }
> >
>
On Wed, Apr 01, 2020 at 06:53:17PM -0400, Giacomo Comes wrote:
> Hi,
> on my Intel Compute Stick STCK1 (baytrail hdmi audio)
> sound is not working with the kernel 5.6
>
> I have bisected the kernel and I found the commit that introduced the issue:
>
> commit 58d124ea2739e1440ddd743d46c470fe724a
On 2020-04-01 at 21:23:28 +0530, Manna, Animesh wrote:
thanks animesh for review!
>
> On 31-03-2020 17:07, Anshuman Gupta wrote:
> >New i915_pm_lpsp igt solution approach relies on connector specific
> >debugfs attribute i915_lpsp_info, it exposes whether an output is
> >capable of driving lpsp an
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: cade363a69762c57ffb58f91b47670df7ca520bf
commit: f0b7c5c4d7beea0cd83b2f8659faf9fd406137e6 [9/10] Merge remote-tracking
branch 'drm-intel/topic/core-for-CI' into drm-tip
config: x86_64-allyesconfig (attached as .config)
compiler: cla
Now that we can peek at GEM->engines[] and obtain a reference to them
using RCU, do so for instances where we can safely iterate the
potentially old copy of the engines. For setting, we can do this when we
know the engine properties are copied over before swapping, so we know
the new engines alread
== Series Details ==
Series: series starting with [01/17] drm/i915/audio: use struct drm_device
based logging
URL : https://patchwork.freedesktop.org/series/75414/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8237 -> Patchwork_17179
==
Add a per-engine request mempool so that we should always have a couple
of requests available for powermanagement allocations from tricky
contexts. These reserves are expected to be only used for kernel
contexts when barriers must be emitted [almost] without fail.
When using the mempool, requests
Quoting Chris Wilson (2020-04-02 12:59:08)
> Add a per-engine request mempool so that we should always have a couple
> of requests available for powermanagement allocations from tricky
> contexts. These reserves are expected to be only used for kernel
> contexts when barriers must be emitted [almos
Add a per-engine request mempool so that we should always have a couple
of requests available for powermanagement allocations from tricky
contexts. These reserves are expected to be only used for kernel
contexts when barriers must be emitted [almost] without fail.
When using the mempool, requests
1 - 100 of 158 matches
Mail list logo
