[Intel-gfx] [CI 2/3] drm/i915/gt: Move submission_method into intel_gt

2021-02-02 Thread Chris Wilson
Since we setup the submission method for the engines once, it is easy to assign an enum and use that instead of probing into the backends. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_engine.h | 8 +++-

[Intel-gfx] [CI 3/3] drm/i915/gt: Move CS interrupt handler to the backend

2021-02-02 Thread Chris Wilson
The different submission backends each have their own preferred behaviour and interrupt setup. Let each handle their own interrupts. This becomes more useful later as we to extract the use of auxiliary state in the interrupt handler that is backend specific. v2: An overabundance of caution is

[Intel-gfx] [CI 1/3] drm/i915/gt: Move engine setup out of set_default_submission

2021-02-02 Thread Chris Wilson
Now that we no longer switch back and forth between guc and execlists, we no longer need to restore the backend's vfunc and can leave them set after initialisation. The only catch is that we lose the submission on wedging and still need to reset the submit_request vfunc on unwedging.

[Intel-gfx] ✓ Fi.CI.IGT: success for Oops with "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Patchwork
== Series Details == Series: Oops with "ALSA: jack: implement software jack injection via debugfs" URL : https://patchwork.freedesktop.org/series/86597/ State : success == Summary == CI Bug Log - changes from CI_DRM_9719_full -> Patchwork_19565_full

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove notion of GEM from i915_gem_shrinker_taints_mutex

2021-02-02 Thread Patchwork
== Series Details == Series: drm/i915: Remove notion of GEM from i915_gem_shrinker_taints_mutex URL : https://patchwork.freedesktop.org/series/86586/ State : success == Summary == CI Bug Log - changes from CI_DRM_9718_full -> Patchwork_19560_full

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,01/13] Oops with "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Patchwork
== Series Details == Series: series starting with [CI,01/13] Oops with "ALSA: jack: implement software jack injection via debugfs" URL : https://patchwork.freedesktop.org/series/86599/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9719 -> Patchwork_19566

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,01/13] Oops with "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Patchwork
== Series Details == Series: series starting with [CI,01/13] Oops with "ALSA: jack: implement software jack injection via debugfs" URL : https://patchwork.freedesktop.org/series/86599/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used,

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,01/13] Oops with "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Patchwork
== Series Details == Series: series starting with [CI,01/13] Oops with "ALSA: jack: implement software jack injection via debugfs" URL : https://patchwork.freedesktop.org/series/86599/ State : warning == Summary == $ dim checkpatch origin/drm-tip 27bd3e4245a9 Oops with "ALSA: jack: implement

[Intel-gfx] ✓ Fi.CI.BAT: success for Oops with "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Patchwork
== Series Details == Series: Oops with "ALSA: jack: implement software jack injection via debugfs" URL : https://patchwork.freedesktop.org/series/86597/ State : success == Summary == CI Bug Log - changes from CI_DRM_9719 -> Patchwork_19565

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Oops with "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Patchwork
== Series Details == Series: Oops with "ALSA: jack: implement software jack injection via debugfs" URL : https://patchwork.freedesktop.org/series/86597/ State : warning == Summary == $ dim checkpatch origin/drm-tip 05f71ab54209 Oops with "ALSA: jack: implement software jack injection via

[Intel-gfx] [CI 01/13] Oops with "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Chris Wilson
From: Takashi Iwai On Tue, 02 Feb 2021 17:30:36 +0100, Chris Wilson wrote: > > commit 2d670ea2bd53 ("ALSA: jack: implement software jack injection via > debugfs") is causing issues for our CI as we see a use-after-free on > module unload (on all machines): > >

[Intel-gfx] [CI 04/13] drm/i915/gt: Move CS interrupt handler to the backend

2021-02-02 Thread Chris Wilson
The different submission backends each have their own preferred behaviour and interrupt setup. Let each handle their own interrupts. This becomes more useful later as we to extract the use of auxiliary state in the interrupt handler that is backend specific. v2: An overabundance of caution is

[Intel-gfx] [CI 10/13] drm/i915: Extract request submission from execlists

2021-02-02 Thread Chris Wilson
In the process of preparing to reuse the request submission logic for other backends, lift it out of the execlists backend. It already operates on the common structs, so just a matter of moving and renaming. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin ---

[Intel-gfx] [CI 02/13] drm/i915/gt: Move engine setup out of set_default_submission

2021-02-02 Thread Chris Wilson
Now that we no longer switch back and forth between guc and execlists, we no longer need to restore the backend's vfunc and can leave them set after initialisation. The only catch is that we lose the submission on wedging and still need to reset the submit_request vfunc on unwedging.

[Intel-gfx] [CI 03/13] drm/i915/gt: Move submission_method into intel_gt

2021-02-02 Thread Chris Wilson
Since we setup the submission method for the engines once, it is easy to assign an enum and use that instead of probing into the backends. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_engine.h | 8 +++-

[Intel-gfx] [CI 11/13] drm/i915: Extract request rewinding from execlists

2021-02-02 Thread Chris Wilson
In the process of preparing to reuse the request submission logic for other backends, lift it out of the execlists backend. While this operates on the common structs, we do have a bit of backend knowledge, which is harmless for !lrc but still unsightly. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [CI 08/13] drm/i915/selftests: Exercise priority inheritance around an engine loop

2021-02-02 Thread Chris Wilson
Exercise rescheduling priority inheritance around a sequence of requests that wrap around all the engines. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- .../gpu/drm/i915/selftests/i915_scheduler.c | 225 ++ 1 file changed, 225 insertions(+) diff --git

[Intel-gfx] [CI 05/13] drm/i915: Replace engine->schedule() with a known request operation

2021-02-02 Thread Chris Wilson
Looking to the future, we want to set the scheduling attributes explicitly and so replace the generic engine->schedule() with the more direct i915_request_set_priority() What it loses in removing the 'schedule' name from the function, it gains in having an explicit entry point with a stated goal.

[Intel-gfx] [CI 07/13] drm/i915/selftests: Measure set-priority duration

2021-02-02 Thread Chris Wilson
As a topological sort, we expect it to run in linear graph time, O(V+E). In removing the recursion, it is no longer a DFS but rather a BFS, and performs as O(VE). Let's demonstrate how bad this is with a few examples, and build a few test cases to verify a potential fix. Signed-off-by: Chris

[Intel-gfx] [CI 12/13] drm/i915: Extract request suspension from the execlists

2021-02-02 Thread Chris Wilson
Make the ability to suspend and resume a request and its dependents generic. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- .../drm/i915/gt/intel_execlists_submission.c | 167 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 8 +-

[Intel-gfx] [CI 06/13] drm/i915: Restructure priority inheritance

2021-02-02 Thread Chris Wilson
In anticipation of wanting to be able to call pi from underneath an engine's active.lock, rework the priority inheritance to primarily work along an engine's priority queue, delegating any other engine that the chain may traverse to a worker. This reduces the global spinlock from governing the

[Intel-gfx] [CI 09/13] drm/i915: Improve DFS for priority inheritance

2021-02-02 Thread Chris Wilson
The core of the scheduling algorithm is that we compute the topological order of the fence DAG. Knowing that we have a DAG, we should be able to use a DFS to compute the topological sort in linear time. However, during the conversion of the recursive algorithm into an iterative one, the

[Intel-gfx] [CI 13/13] drm/i915: Extract the ability to defer and rerun a request later

2021-02-02 Thread Chris Wilson
Lift the ability to defer a request until later from execlists into the common layer. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- .../drm/i915/gt/intel_execlists_submission.c | 57 +++-- drivers/gpu/drm/i915/i915_scheduler.c | 63 +--

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [CI,1/3] *** HAX FOR CI *** Revert "rtc: mc146818: Detect and handle broken RTCs"

2021-02-02 Thread Patchwork
== Series Details == Series: series starting with [CI,1/3] *** HAX FOR CI *** Revert "rtc: mc146818: Detect and handle broken RTCs" URL : https://patchwork.freedesktop.org/series/86596/ State : failure == Summary == Applying: *** HAX FOR CI *** Revert "rtc: mc146818: Detect and handle broken

Re: [Intel-gfx] [PATCH] drm/i915/gt: Retire unexpected starting state error dumping

2021-02-02 Thread Andi Shyti
Hi Chris, On Mon, Feb 01, 2021 at 04:42:22PM +, Chris Wilson wrote: > We have not seen an occurrence of the false restart state recenty, and if > we did such an event from inside engine-reset, it would deadlock on > trying to suspend the tasklet to read the register state. Instead, we >

Re: [Intel-gfx] [CI 08/14] drm/i915/selftests: Force a rewind if at first we don't succeed

2021-02-02 Thread Chris Wilson
Quoting Chris Wilson (2021-02-02 21:24:16) > Quoting Chris Wilson (2021-02-02 21:14:35) > > Quoting Chris Wilson (2021-02-02 17:43:53) > > > Let's see how horrible it is to cycle elements on defer. (Curse the > > > irqlock pollution.) > > > > While that did work. I do not have a good idea on how

Re: [Intel-gfx] [CI 08/14] drm/i915/selftests: Force a rewind if at first we don't succeed

2021-02-02 Thread Chris Wilson
Quoting Chris Wilson (2021-02-02 21:14:35) > Quoting Chris Wilson (2021-02-02 17:43:53) > > Let's see how horrible it is to cycle elements on defer. (Curse the > > irqlock pollution.) > > While that did work. I do not have a good idea on how to do list > rotation on an RCU list. I can see that it

[Intel-gfx] [CI] Oops with "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Chris Wilson
From: Takashi Iwai On Tue, 02 Feb 2021 17:30:36 +0100, Chris Wilson wrote: > > commit 2d670ea2bd53 ("ALSA: jack: implement software jack injection via > debugfs") is causing issues for our CI as we see a use-after-free on > module unload (on all machines): > >

[Intel-gfx] [CI 3/3] Oops with "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Chris Wilson
From: Takashi Iwai On Tue, 02 Feb 2021 17:30:36 +0100, Chris Wilson wrote: > > commit 2d670ea2bd53 ("ALSA: jack: implement software jack injection via > debugfs") is causing issues for our CI as we see a use-after-free on > module unload (on all machines): > >

[Intel-gfx] [CI 2/3] drm-tip: 2021y-02m-02d-12h-50m-06s UTC integration manifest

2021-02-02 Thread Chris Wilson
From: Joonas Lahtinen --- integration-manifest | 40 1 file changed, 40 insertions(+) create mode 100644 integration-manifest diff --git a/integration-manifest b/integration-manifest new file mode 100644 index ..d80099bceaa5 --- /dev/null

[Intel-gfx] [CI 1/3] *** HAX FOR CI *** Revert "rtc: mc146818: Detect and handle broken RTCs"

2021-02-02 Thread Chris Wilson
From: Jani Nikula This reverts commit 211e5db19d15a721b2953ea54b8f26c2963720eb. --- drivers/rtc/rtc-cmos.c | 8 drivers/rtc/rtc-mc146818-lib.c | 7 --- 2 files changed, 15 deletions(-) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index

Re: [Intel-gfx] [CI 08/14] drm/i915/selftests: Force a rewind if at first we don't succeed

2021-02-02 Thread Chris Wilson
Quoting Chris Wilson (2021-02-02 17:43:53) > Let's see how horrible it is to cycle elements on defer. (Curse the > irqlock pollution.) While that did work. I do not have a good idea on how to do list rotation on an RCU list. I can see that it must require a pair of synchronize_rcu, and that

Re: [Intel-gfx] [PATCH 1/3] i915/perf: Store a mask of valid OA formats for a platform

2021-02-02 Thread Chris Wilson
Quoting Umesh Nerlige Ramappa (2021-02-02 20:10:44) > On Tue, Feb 02, 2021 at 08:24:15AM +, Chris Wilson wrote: > >Ok, this looks as compact and readable as writing it as a bunch of > >tables. I presume there's a reason you didn't just use generation rather > >than platform. > > > >switch

Re: [Intel-gfx] [PATCH 1/3] i915/perf: Store a mask of valid OA formats for a platform

2021-02-02 Thread Umesh Nerlige Ramappa
On Tue, Feb 02, 2021 at 08:24:15AM +, Chris Wilson wrote: Quoting Umesh Nerlige Ramappa (2021-02-02 07:54:15) Validity of an OA format is checked by using a sparse array of formats per gen. Instead maintain a mask of supported formats for a platform in the perf object. Signed-off-by: Umesh

[Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel-fixes tree

2021-02-02 Thread Stephen Rothwell
Hi all, Commit 44c5bd08518c ("*** HAX FOR CI *** Revert "rtc: mc146818: Detect and handle broken RTCs"") is missing a Signed-off-by from its author and committer. Reverts are commits as well. -- Cheers, Stephen Rothwell pgpKZp048c5Hl.pgp Description: OpenPGP digital signature

[Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Patchwork
== Series Details == Series: Revert "ALSA: jack: implement software jack injection via debugfs" URL : https://patchwork.freedesktop.org/series/86590/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9718 -> Patchwork_19563

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Use a single copy of the mocs table

2021-02-02 Thread Mika Kuoppala
Chris Wilson writes: > Instead of copying the whole table to each category (mocs, l3cc), use a > single table with a pointer to it if the category is enabled. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/gt/selftest_mocs.c | 32

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Patchwork
== Series Details == Series: Revert "ALSA: jack: implement software jack injection via debugfs" URL : https://patchwork.freedesktop.org/series/86590/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6adf76b93ea8 Revert "ALSA: jack: implement software jack injection via debugfs"

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Remove notion of GEM from i915_gem_shrinker_taints_mutex

2021-02-02 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915: Remove notion of GEM from i915_gem_shrinker_taints_mutex URL : https://patchwork.freedesktop.org/series/86587/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9718 -> Patchwork_19561

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [CI,01/14] drm/i915/gt: Move engine setup out of set_default_submission (rev2)

2021-02-02 Thread Patchwork
== Series Details == Series: series starting with [CI,01/14] drm/i915/gt: Move engine setup out of set_default_submission (rev2) URL : https://patchwork.freedesktop.org/series/86585/ State : failure == Summary == Applying: drm/i915/gt: Move engine setup out of set_default_submission

Re: [Intel-gfx] [PATCH 05/57] drm/i915: Take rcu_read_lock for querying fence's driver/timeline names

2021-02-02 Thread Mika Kuoppala
Chris Wilson writes: > The name very often may be freed independently of the fence, with the > only protection being RCU. To be safe as we read the names, hold RCU. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_sw_fence.c | 2 ++ > 1 file

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove notion of GEM from i915_gem_shrinker_taints_mutex

2021-02-02 Thread Patchwork
== Series Details == Series: drm/i915: Remove notion of GEM from i915_gem_shrinker_taints_mutex URL : https://patchwork.freedesktop.org/series/86586/ State : success == Summary == CI Bug Log - changes from CI_DRM_9718 -> Patchwork_19560

Re: [Intel-gfx] [CI 08/14] drm/i915/selftests: Force a rewind if at first we don't succeed

2021-02-02 Thread Chris Wilson
Quoting Tvrtko Ursulin (2021-02-02 16:52:18) > > On 02/02/2021 15:14, Chris Wilson wrote: > > live_timeslice_rewind assumes a particular traversal and reordering > > after the first timeslice yield. However, the outcome can be either > > (A1, A2, B1) or (A1, B2, A2) depending on the path taken

Re: [Intel-gfx] [CI 07/14] drm/i915/selftests: Exercise priority inheritance around an engine loop

2021-02-02 Thread Chris Wilson
Quoting Tvrtko Ursulin (2021-02-02 16:44:26) > > On 02/02/2021 15:14, Chris Wilson wrote: > > + err = 0; > > + count = 0; > > + for_each_uabi_engine(engine, i915) { > > + if (!intel_engine_has_scheduler(engine)) > > + continue; > > + > > +

Re: [Intel-gfx] [CI 08/14] drm/i915/selftests: Force a rewind if at first we don't succeed

2021-02-02 Thread Tvrtko Ursulin
On 02/02/2021 15:14, Chris Wilson wrote: live_timeslice_rewind assumes a particular traversal and reordering after the first timeslice yield. However, the outcome can be either (A1, A2, B1) or (A1, B2, A2) depending on the path taken through the dependency graph. So if we do not get the

Re: [Intel-gfx] [CI 06/14] drm/i915/selftests: Measure set-priority duration

2021-02-02 Thread Tvrtko Ursulin
On 02/02/2021 15:14, Chris Wilson wrote: As a topological sort, we expect it to run in linear graph time, O(V+E). In removing the recursion, it is no longer a DFS but rather a BFS, and performs as O(VE). Let's demonstrate how bad this is with a few examples, and build a few test cases to verify

Re: [Intel-gfx] [CI 07/14] drm/i915/selftests: Exercise priority inheritance around an engine loop

2021-02-02 Thread Tvrtko Ursulin
On 02/02/2021 15:14, Chris Wilson wrote: Exercise rescheduling priority inheritance around a sequence of requests that wrap around all the engines. Signed-off-by: Chris Wilson --- .../gpu/drm/i915/selftests/i915_scheduler.c | 225 ++ 1 file changed, 225 insertions(+)

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Move CS interrupt handler to the backend

2021-02-02 Thread Tvrtko Ursulin
On 02/02/2021 16:15, Chris Wilson wrote: The different submission backends each have their own preferred behaviour and interrupt setup. Let each handle their own interrupts. This becomes more useful later as we to extract the use of auxiliary state in the interrupt handler that is backend

[Intel-gfx] [CI] Revert "ALSA: jack: implement software jack injection via debugfs"

2021-02-02 Thread Chris Wilson
This reverts commit 2d670ea2bd53a9792f453bb5b97cb8ef695988ff. --- Documentation/sound/designs/index.rst | 1 - .../sound/designs/jack-injection.rst | 166 -- include/sound/core.h | 6 - include/sound/jack.h | 1 -

[Intel-gfx] [PATCH v2] drm/i915/gt: Move CS interrupt handler to the backend

2021-02-02 Thread Chris Wilson
The different submission backends each have their own preferred behaviour and interrupt setup. Let each handle their own interrupts. This becomes more useful later as we to extract the use of auxiliary state in the interrupt handler that is backend specific. v2: An overabundance of caution is

Re: [Intel-gfx] [PATCH] drm/i915/gen9bc: Handle TGP PCH during suspend/resume

2021-02-02 Thread Imre Deak
On Tue, Feb 02, 2021 at 08:59:20AM +, Surendrakumar Upadhyay, TejaskumarX wrote: > > > > -Original Message- > > From: Ville Syrjälä > > Sent: 02 February 2021 12:42 > > To: Surendrakumar Upadhyay, TejaskumarX > > > > Cc: intel-gfx@lists.freedesktop.org; Pandey, Hariom > > > >

Re: [Intel-gfx] [CI 03/14] drm/i915/gt: Move CS interrupt handler to the backend

2021-02-02 Thread Chris Wilson
Quoting Chris Wilson (2021-02-02 15:53:41) > Quoting Tvrtko Ursulin (2021-02-02 15:49:59) > > > > On 02/02/2021 15:14, Chris Wilson wrote: > > > The different submission backends each have their own preferred > > > behaviour and interrupt setup. Let each handle their own interrupts. > > > > > >

Re: [Intel-gfx] [CI 03/14] drm/i915/gt: Move CS interrupt handler to the backend

2021-02-02 Thread Chris Wilson
Quoting Tvrtko Ursulin (2021-02-02 15:49:59) > > On 02/02/2021 15:14, Chris Wilson wrote: > > The different submission backends each have their own preferred > > behaviour and interrupt setup. Let each handle their own interrupts. > > > > This becomes more useful later as we to extract the use

Re: [Intel-gfx] [CI 03/14] drm/i915/gt: Move CS interrupt handler to the backend

2021-02-02 Thread Tvrtko Ursulin
On 02/02/2021 15:14, Chris Wilson wrote: The different submission backends each have their own preferred behaviour and interrupt setup. Let each handle their own interrupts. This becomes more useful later as we to extract the use of auxiliary state in the interrupt handler that is backend

Re: [Intel-gfx] Fixes that failed to apply to v5.11-rc4

2021-02-02 Thread Jani Nikula
On Tue, 02 Feb 2021, Imre Deak wrote: > Hi, > > On Tue, Feb 02, 2021 at 09:15:18AM +0200, Jani Nikula wrote: >> On Mon, 18 Jan 2021, Jani Nikula wrote: >> > The following commits have been marked as Cc: stable or fixing something >> > in v5.11-rc4 or earlier, but failed to cherry-pick to >> >

[Intel-gfx] [PATCH 1/2] drm/i915: Remove notion of GEM from i915_gem_shrinker_taints_mutex

2021-02-02 Thread Chris Wilson
Since we dropped the use of dev->struct_mutex from inside the shrinker, we no longer include that as part of our fs_reclaim tainting. We can drop the i915 argument and rebrand it as a generic fs_reclaim tainter. Signed-off-by: Chris Wilson Cc: Thomas Hellström Reviewed-by: Thomas Hellström ---

[Intel-gfx] [PATCH 2/2] drm/i915: Lift marking a lock as used to utils

2021-02-02 Thread Chris Wilson
After calling lock_set_subclass() the lock _must_ be used, or else lockdep's internal nr_used_locks becomes unbalanced. Extract the little utility function to i915_utils.c Signed-off-by: Chris Wilson Cc: Thomas Hellström --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 13 +

Re: [Intel-gfx] [PATCH] drm/i915: Remove notion of GEM from i915_gem_shrinker_taints_mutex

2021-02-02 Thread Thomas Hellström
On Tue, 2021-02-02 at 15:29 +, Chris Wilson wrote: > Since we dropped the use of dev->struct_mutex from inside the > shrinker, > we no longer include that as part of our fs_reclaim tainting. We can > drop the i915 argument and rebrand it as a generic fs_reclaim > tainter. > > Signed-off-by:

[Intel-gfx] [PATCH] drm/i915: Remove notion of GEM from i915_gem_shrinker_taints_mutex

2021-02-02 Thread Chris Wilson
Since we dropped the use of dev->struct_mutex from inside the shrinker, we no longer include that as part of our fs_reclaim tainting. We can drop the i915 argument and rebrand it as a generic fs_reclaim tainter. Signed-off-by: Chris Wilson Cc: Thomas Hellström ---

[Intel-gfx] [CI 02/14] drm/i915/gt: Move submission_method into intel_gt

2021-02-02 Thread Chris Wilson
Since we setup the submission method for the engines once, it is easy to assign an enum and use that instead of probing into the backends. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_engine.h | 8 +++-

[Intel-gfx] [CI 06/14] drm/i915/selftests: Measure set-priority duration

2021-02-02 Thread Chris Wilson
As a topological sort, we expect it to run in linear graph time, O(V+E). In removing the recursion, it is no longer a DFS but rather a BFS, and performs as O(VE). Let's demonstrate how bad this is with a few examples, and build a few test cases to verify a potential fix. Signed-off-by: Chris

[Intel-gfx] [CI 03/14] drm/i915/gt: Move CS interrupt handler to the backend

2021-02-02 Thread Chris Wilson
The different submission backends each have their own preferred behaviour and interrupt setup. Let each handle their own interrupts. This becomes more useful later as we to extract the use of auxiliary state in the interrupt handler that is backend specific. Signed-off-by: Chris Wilson ---

[Intel-gfx] [CI 04/14] drm/i915: Replace engine->schedule() with a known request operation

2021-02-02 Thread Chris Wilson
Looking to the future, we want to set the scheduling attributes explicitly and so replace the generic engine->schedule() with the more direct i915_request_set_priority() What it loses in removing the 'schedule' name from the function, it gains in having an explicit entry point with a stated goal.

[Intel-gfx] [CI 07/14] drm/i915/selftests: Exercise priority inheritance around an engine loop

2021-02-02 Thread Chris Wilson
Exercise rescheduling priority inheritance around a sequence of requests that wrap around all the engines. Signed-off-by: Chris Wilson --- .../gpu/drm/i915/selftests/i915_scheduler.c | 225 ++ 1 file changed, 225 insertions(+) diff --git

[Intel-gfx] [CI 12/14] drm/i915: Extract request suspension from the execlists

2021-02-02 Thread Chris Wilson
Make the ability to suspend and resume a request and its dependents generic. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- .../drm/i915/gt/intel_execlists_submission.c | 167 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 8 +-

[Intel-gfx] [CI 09/14] drm/i915: Improve DFS for priority inheritance

2021-02-02 Thread Chris Wilson
The core of the scheduling algorithm is that we compute the topological order of the fence DAG. Knowing that we have a DAG, we should be able to use a DFS to compute the topological sort in linear time. However, during the conversion of the recursive algorithm into an iterative one, the

[Intel-gfx] [CI 08/14] drm/i915/selftests: Force a rewind if at first we don't succeed

2021-02-02 Thread Chris Wilson
live_timeslice_rewind assumes a particular traversal and reordering after the first timeslice yield. However, the outcome can be either (A1, A2, B1) or (A1, B2, A2) depending on the path taken through the dependency graph. So if we do not get the outcome we need at first, give it a priority kick

[Intel-gfx] [CI 10/14] drm/i915: Extract request submission from execlists

2021-02-02 Thread Chris Wilson
In the process of preparing to reuse the request submission logic for other backends, lift it out of the execlists backend. It already operates on the common structs, so just a matter of moving and renaming. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin ---

[Intel-gfx] [CI 11/14] drm/i915: Extract request rewinding from execlists

2021-02-02 Thread Chris Wilson
In the process of preparing to reuse the request submission logic for other backends, lift it out of the execlists backend. While this operates on the common structs, we do have a bit of backend knowledge, which is harmless for !lrc but still unsightly. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [CI 14/14] drm/i915: Fix the iterative dfs for defering requests

2021-02-02 Thread Chris Wilson
The current implementation of walking the children of a deferred requests lacks the backtracking required to reduce the dfs to linear. Having pulled it from execlists into the common layer, we can reuse the dfs code for priority inheritance. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko

[Intel-gfx] [CI 05/14] drm/i915: Restructure priority inheritance

2021-02-02 Thread Chris Wilson
In anticipation of wanting to be able to call pi from underneath an engine's active.lock, rework the priority inheritance to primarily work along an engine's priority queue, delegating any other engine that the chain may traverse to a worker. This reduces the global spinlock from governing the

[Intel-gfx] [CI 13/14] drm/i915: Extract the ability to defer and rerun a request later

2021-02-02 Thread Chris Wilson
Lift the ability to defer a request until later from execlists into the common layer. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- .../drm/i915/gt/intel_execlists_submission.c | 57 +++-- drivers/gpu/drm/i915/i915_scheduler.c | 63 +--

[Intel-gfx] [CI 01/14] drm/i915/gt: Move engine setup out of set_default_submission

2021-02-02 Thread Chris Wilson
Now that we no longer switch back and forth between guc and execlists, we no longer need to restore the backend's vfunc and can leave them set after initialisation. The only catch is that we lose the submission on wedging and still need to reset the submit_request vfunc on unwedging.

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v14,1/2] drm/i915/display: Support PSR Multiple Instances

2021-02-02 Thread Mun, Gwan-gyeong
On Fri, 2021-01-29 at 11:45 +, Patchwork wrote: > == Series Details == > > Series: series starting with [v14,1/2] drm/i915/display: Support PSR > Multiple Instances > URL   : https://patchwork.freedesktop.org/series/86445/ > State : warning > > == Summary == > > $ dim checkpatch

Re: [Intel-gfx] Fixes that failed to apply to v5.11-rc4

2021-02-02 Thread Imre Deak
Hi, On Tue, Feb 02, 2021 at 09:15:18AM +0200, Jani Nikula wrote: > On Mon, 18 Jan 2021, Jani Nikula wrote: > > The following commits have been marked as Cc: stable or fixing something > > in v5.11-rc4 or earlier, but failed to cherry-pick to > > drm-intel-fixes. Please see if they are worth

Re: [Intel-gfx] [PATCH 19/57] drm/i915: Fix the iterative dfs for defering requests

2021-02-02 Thread Tvrtko Ursulin
On 01/02/2021 08:56, Chris Wilson wrote: The current implementation of walking the children of a deferred requests lacks the backtracking required to reduce the dfs to linear. Having pulled it from execlists into the common layer, we can reuse the dfs code for priority inheritance.

Re: [Intel-gfx] [PULL] topic/adl-s-enabling into drm-intel-next

2021-02-02 Thread Joonas Lahtinen
Quoting Jani Nikula (2021-02-02 13:19:13) > On Mon, 01 Feb 2021, Lucas De Marchi wrote: > > Hi Rodrigo/Jani, > > > > Here are the changes to add basic Alder Lake S support in the driver, with > > patches touching both generic parts, gt and display. Remaining changes don't > > need a topic branch

Re: [Intel-gfx] [PATCH 17/57] drm/i915: Extract request suspension from the execlists

2021-02-02 Thread Tvrtko Ursulin
On 02/02/2021 13:26, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-02-02 13:15:52) On 01/02/2021 08:56, Chris Wilson wrote: +void __i915_sched_resume_request(struct intel_engine_cs *engine, + struct i915_request *rq) +{ + LIST_HEAD(list); + +

Re: [Intel-gfx] [PULL] topic/drm-device-pdev

2021-02-02 Thread Joonas Lahtinen
Quoting Jani Nikula (2021-02-02 14:37:00) > > Hi Joonas - > > This is Thomas's drm_device.pdev removal for i915, the first three > patches from [1]. Let's merge to both drm-intel-next and > drm-intel-gt-next. This is now merged. Regards, Joonas > Zhenyu & Zhi, FYI, this touches gvt too, and

Re: [Intel-gfx] [PATCH 17/57] drm/i915: Extract request suspension from the execlists

2021-02-02 Thread Chris Wilson
Quoting Tvrtko Ursulin (2021-02-02 13:15:52) > > On 01/02/2021 08:56, Chris Wilson wrote: > > Make the ability to suspend and resume a request and its dependents > > generic. > > +bool __i915_sched_suspend_request(struct intel_engine_cs *engine, > > + struct

Re: [Intel-gfx] [PATCH 17/57] drm/i915: Extract request suspension from the execlists

2021-02-02 Thread Chris Wilson
Quoting Tvrtko Ursulin (2021-02-02 13:15:52) > > On 01/02/2021 08:56, Chris Wilson wrote: > > +void __i915_sched_resume_request(struct intel_engine_cs *engine, > > + struct i915_request *rq) > > +{ > > + LIST_HEAD(list); > > + > > +

Re: [Intel-gfx] [PATCH 18/57] drm/i915: Extract the ability to defer and rerun a request later

2021-02-02 Thread Tvrtko Ursulin
On 01/02/2021 08:56, Chris Wilson wrote: Lift the ability to defer a request until later from execlists into the common layer. Signed-off-by: Chris Wilson --- .../drm/i915/gt/intel_execlists_submission.c | 57 +++-- drivers/gpu/drm/i915/i915_scheduler.c | 63

Re: [Intel-gfx] [PATCH 17/57] drm/i915: Extract request suspension from the execlists

2021-02-02 Thread Tvrtko Ursulin
On 01/02/2021 08:56, Chris Wilson wrote: Make the ability to suspend and resume a request and its dependents generic. Signed-off-by: Chris Wilson --- .../drm/i915/gt/intel_execlists_submission.c | 167 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 8 +-

Re: [Intel-gfx] [PATCH 16/57] drm/i915: Extract request rewinding from execlists

2021-02-02 Thread Tvrtko Ursulin
On 01/02/2021 08:56, Chris Wilson wrote: In the process of preparing to reuse the request submission logic for other backends, lift it out of the execlists backend. While this operates on the common structs, we do have a bit of backend knowledge, which is harmless for !lrc but still

Re: [Intel-gfx] [PATCH v6 0/5] drm: Move struct drm_device.pdev to legacy

2021-02-02 Thread Jani Nikula
On Thu, 28 Jan 2021, Thomas Zimmermann wrote: > V6 of the patchset fixes i915/selftests to do the assigment of pdev > in a later patch. This was forgotten in v5. > > The pdev field in struct drm_device points to a PCI device structure and > goes back to UMS-only days when all DRM drivers were for

[Intel-gfx] [PULL] topic/drm-device-pdev

2021-02-02 Thread Jani Nikula
Hi Joonas - This is Thomas's drm_device.pdev removal for i915, the first three patches from [1]. Let's merge to both drm-intel-next and drm-intel-gt-next. Zhenyu & Zhi, FYI, this touches gvt too, and it was getting a bit too complicated to handle all the components separately. Hopefully you

[Intel-gfx] [PULL] drm-misc-fixes

2021-02-02 Thread Thomas Zimmermann
Hi Dave and Daniel, here's this week's PR for drm-misc-fixes. There are 3 patches for the bridge code and one for TTM. Best regards Thomas drm-misc-fixes-2021-02-02: * drm/bridge/lontium-lt9611uxc: EDID fixes; Don't handle hotplug events in IRQ handler * drm/ttm: Use _GFP_NOWARN for huge

Re: [Intel-gfx] [PATCH 08/57] drm/i915/gt: Move submission_method into intel_gt

2021-02-02 Thread Chris Wilson
Quoting Tvrtko Ursulin (2021-02-02 12:03:02) > > diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c > > b/drivers/gpu/drm/i915/gt/selftest_execlists.c > > index 5d7fac383add..9304a35384aa 100644 > > --- a/drivers/gpu/drm/i915/gt/selftest_execlists.c > > +++

Re: [Intel-gfx] [PATCH 08/57] drm/i915/gt: Move submission_method into intel_gt

2021-02-02 Thread Tvrtko Ursulin
On 01/02/2021 08:56, Chris Wilson wrote: Since we setup the submission method for the engines once, it is easy to assign an enum and use that instead of probing into the backends. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_engine.h | 8 +++-

Re: [Intel-gfx] [PATCH 07/57] drm/i915/gt: Move engine setup out of set_default_submission

2021-02-02 Thread Tvrtko Ursulin
On 01/02/2021 08:56, Chris Wilson wrote: Now that we no longer switch back and forth between guc and execlists, we no longer need to restore the backend's vfunc and can leave them set after initialisation. The only catch is that we lose the submission on wedging and still need to reset the

Re: [Intel-gfx] Fixes that failed to apply to v5.11-rc4

2021-02-02 Thread Jani Nikula
On Tue, 02 Feb 2021, Chris Wilson wrote: > Quoting Jani Nikula (2021-02-02 07:15:18) >> On Mon, 18 Jan 2021, Jani Nikula wrote: >> > The following commits have been marked as Cc: stable or fixing something >> > in v5.11-rc4 or earlier, but failed to cherry-pick to >> > drm-intel-fixes. Please

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] i915/perf: Store a mask of valid OA formats for a platform

2021-02-02 Thread Patchwork
== Series Details == Series: series starting with [1/3] i915/perf: Store a mask of valid OA formats for a platform URL : https://patchwork.freedesktop.org/series/86558/ State : success == Summary == CI Bug Log - changes from CI_DRM_9714_full -> Patchwork_19558_full

Re: [Intel-gfx] [PULL] topic/adl-s-enabling into drm-intel-next

2021-02-02 Thread Jani Nikula
On Mon, 01 Feb 2021, Lucas De Marchi wrote: > Hi Rodrigo/Jani, > > Here are the changes to add basic Alder Lake S support in the driver, with > patches touching both generic parts, gt and display. Remaining changes don't > need a topic branch anymore and can be applied individually to each

Re: [Intel-gfx] [PATCH -fixes] drm/i915/display: Prevent double YUV range correction on HDR planes

2021-02-02 Thread Jani Nikula
On Tue, 02 Feb 2021, Ville Syrjala wrote: > From: Andres Calderon Jaramillo > > Prevent the ICL HDR plane pipeline from performing YUV color range > correction twice when the input is in limited range. This is done by > removing the limited-range code from icl_program_input_csc(). > > Before

Re: [Intel-gfx] [PATCH 04/57] drm/i915: Protect against request freeing during cancellation on wedging

2021-02-02 Thread Mika Kuoppala
Chris Wilson writes: > As soon as we mark a request as completed, it may be retired. So when > cancelling a request and marking it complete, make sure we first keep a > reference to the request. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- >

Re: [Intel-gfx] [PATCH] drm/i915/gen9bc: Handle TGP PCH during suspend/resume

2021-02-02 Thread Surendrakumar Upadhyay, TejaskumarX
> -Original Message- > From: Ville Syrjälä > Sent: 02 February 2021 12:42 > To: Surendrakumar Upadhyay, TejaskumarX > > Cc: intel-gfx@lists.freedesktop.org; Pandey, Hariom > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/gen9bc: Handle TGP PCH during > suspend/resume > > On Tue, Feb

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] i915/perf: Store a mask of valid OA formats for a platform

2021-02-02 Thread Patchwork
== Series Details == Series: series starting with [1/3] i915/perf: Store a mask of valid OA formats for a platform URL : https://patchwork.freedesktop.org/series/86558/ State : success == Summary == CI Bug Log - changes from CI_DRM_9714 -> Patchwork_19558

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/display: Prevent double YUV range correction on HDR planes (rev3)

2021-02-02 Thread Patchwork
== Series Details == Series: drm/i915/display: Prevent double YUV range correction on HDR planes (rev3) URL : https://patchwork.freedesktop.org/series/84966/ State : failure == Summary == Applying: drm/i915/display: Prevent double YUV range correction on HDR planes Using index info to

[Intel-gfx] [PATCH -fixes] drm/i915/display: Prevent double YUV range correction on HDR planes

2021-02-02 Thread Ville Syrjala
From: Andres Calderon Jaramillo Prevent the ICL HDR plane pipeline from performing YUV color range correction twice when the input is in limited range. This is done by removing the limited-range code from icl_program_input_csc(). Before this patch the following could happen: user space gives us

Re: [Intel-gfx] Fixes that failed to apply to v5.11-rc4

2021-02-02 Thread Chris Wilson
Quoting Jani Nikula (2021-02-02 07:15:18) > On Mon, 18 Jan 2021, Jani Nikula wrote: > > The following commits have been marked as Cc: stable or fixing something > > in v5.11-rc4 or earlier, but failed to cherry-pick to > > drm-intel-fixes. Please see if they are worth backporting, and please do >

  1   2   >