Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

Quoting Daniel Vetter (2018-03-27 08:01:17) > On Mon, Mar 26, 2018 at 09:08:33PM +0100, Chris Wilson wrote: > > Quoting Patchwork (2018-03-26 17:53:44) > > > Test gem_userptr_blits: > > > Subgroup coherency-unsync: > > > pass -> INCOMPLETE (shard-hsw) > > > > Forgot

Re: [Intel-gfx] [PATCH 14/23] drm/atmel-hlcdc: Stop using plane->fb

On Thu, Mar 22, 2018 at 05:23:04PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->fb on atomic drivers. Stop looking at it. > > Cc: Boris Brezillon > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Use a preemption timeout to enforce interactivity

Quoting Tvrtko Ursulin (2018-03-27 09:35:17) > > On 26/03/2018 12:50, Chris Wilson wrote: > > Use a liberal timeout of 20ms to ensure that the rendering for an > > interactive pageflip is started in a timely fashion, and that > > user interaction is not blocked by GPU, or CPU, hogs. This is at

Re: [Intel-gfx] [PATCH] trace: Default to using trace_global_clock is sched_clock is unstable

Quoting Chris Wilson (2018-03-27 10:55:35) > Across suspend, we may see a very large drift in timestamps if the sched > clock is unstable, prompting the global trace's ringbuffer code to warn > and suggest switching to the global clock. Preempt this request by > detecting when the sched clock is

Re: [Intel-gfx] [PATCH v2 1/1] i915: additional GEM documentation

On 03/02/2018 04:09 PM, kevin.rogo...@intel.com wrote: > From: Kevin Rogovin > > This patch provides additional overview documentation to the > i915 kernel driver GEM. In addition, it presents already written > documentation to i915.rst as well. > > Signed-off-by:

[Intel-gfx] [PATCH] trace: Default to using trace_global_clock is sched_clock is unstable

Across suspend, we may see a very large drift in timestamps if the sched clock is unstable, prompting the global trace's ringbuffer code to warn and suggest switching to the global clock. Preempt this request by detecting when the sched clock is unstable (determined during late_initcall) and

Re: [Intel-gfx] [PATCH 07/23] drm: Make the fb refcount handover less magic

On Thu, Mar 22, 2018 at 05:22:57PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Instead of assigning the plane->fb pointer and clearing the fb pointer > to hand over the reference, let's just do it by grabbing another > referece for plane->fb and let fb

Re: [Intel-gfx] [PATCH igt] igt/perf_pmu: Most-busy requires at least one busy engine

On 27/03/2018 09:37, Chris Wilson wrote: The test is whether with all but one engine busy we record the correct load on each engine. If we only have one engine, this test degenerates into all-idle/all-busy, so we can skip to avoid crashing on the assumption that we have a busy spinner.

Re: [Intel-gfx] [PATCH igt] igt/perf_pmu: Most-busy requires at least one busy engine

Quoting Tvrtko Ursulin (2018-03-27 09:54:35) > > On 27/03/2018 09:37, Chris Wilson wrote: > > The test is whether with all but one engine busy we record the correct > > load on each engine. If we only have one engine, this test degenerates > > into all-idle/all-busy, so we can skip to avoid

Re: [Intel-gfx] [PATCH 08/11] drm/i915/execlists: Force preemption via reset on timeout

Quoting Tvrtko Ursulin (2018-03-27 09:51:20) > > On 26/03/2018 12:50, Chris Wilson wrote: > > Install a timer when trying to preempt on behalf of an important > > context such that if the active context does not honour the preemption > > request within the desired timeout, then we reset the GPU

Re: [Intel-gfx] [PATCH 02/11] drm/i915/execlists: Clear user-active flag on preemption completion

Quoting Chris Wilson (2018-03-27 11:00:32) > Quoting Chris Wilson (2018-03-26 12:50:35) > > When cancelling the requests and clearing out the ports following a > > successful preemption completion, also clear the active flag. I had > > assumed that all preemptions would be followed by an immediate

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

On Tue, Mar 27, 2018 at 08:19:33AM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2018-03-27 07:48:00) > > On Mon, Mar 26, 2018 at 11:38:55PM +0100, Chris Wilson wrote: > > > Quoting Chris Wilson (2018-03-26 21:08:33) > > > > Quoting Patchwork (2018-03-26 17:53:44) > > > > > Test

Re: [Intel-gfx] [PATCH i-g-t] lib/gpgpu_fill: Adding missing configuration parameters for gpgpu_fill function

On Mon, Mar 26, 2018 at 02:28:48PM -0700, Daniele Ceraolo Spurio wrote: > + igt-dev > > On 21/03/18 07:23, Katarzyna Dec wrote: > > During debugging gpgpu_fill test on various platforms, I found out few > > things that can affect newer gens: > > this is slightly confusing, as you start with

Re: [Intel-gfx] [PATCH 15/23] drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

On Thu, Mar 22, 2018 at 05:23:05PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Stop playing around with plane->crtc/fb/old_fb with atomic > drivers. Make life a lot simpler when we don't have to do the > magic old_fb vs. fb dance around plane updates.

Re: [Intel-gfx] [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

On Thu, Mar 22, 2018 at 05:22:50PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > I really just wanted to fix i915 to re-enable its planes afer load > detection (a two line patch). This is what I actually ended up with > after I ran into a framebuffer

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Clear user-active flag on preemption completion

Quoting Mika Kuoppala (2018-03-27 09:18:55) > Chris Wilson writes: > > > When cancelling the requests and clearing out the ports following a > > successful preemption completion, also clear the active flag. I had > > assumed that all preemptions would be followed by an

[Intel-gfx] [PULL] more gvt-next-fixes for 4.17

Hi, Joonas Here's this week's gvt-next-fixes queued for 4.17. One notable change is to revert previous workaround for gvt context preemption, now it has full support for preemption now. Others are normal fixes and optimizations. Thanks -- The following changes since commit

Re: [Intel-gfx] [PATCH 02/11] drm/i915/execlists: Clear user-active flag on preemption completion

Quoting Chris Wilson (2018-03-26 12:50:35) > When cancelling the requests and clearing out the ports following a > successful preemption completion, also clear the active flag. I had > assumed that all preemptions would be followed by an immediate dequeue > (preserving the active user flag), but

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

On Mon, Mar 26, 2018 at 09:08:33PM +0100, Chris Wilson wrote: > Quoting Patchwork (2018-03-26 17:53:44) > > Test gem_userptr_blits: > > Subgroup coherency-unsync: > > pass -> INCOMPLETE (shard-hsw) > > Forgot that obj->userptr.mn may not exist. > > >

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

Quoting Daniel Vetter (2018-03-27 07:48:00) > On Mon, Mar 26, 2018 at 11:38:55PM +0100, Chris Wilson wrote: > > Quoting Chris Wilson (2018-03-26 21:08:33) > > > Quoting Patchwork (2018-03-26 17:53:44) > > > > Test gem_userptr_blits: > > > > Subgroup coherency-unsync: > > > >

Re: [Intel-gfx] [PATCH 08/23] drm: Use plane->state->fb over plane->fb

On Thu, Mar 22, 2018 at 05:22:58PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Stop looking at plane->fb on atomic drivers. Use plane->state->fb > instead. > > Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Clear user-active flag on preemption completion

Chris Wilson writes: > When cancelling the requests and clearing out the ports following a > successful preemption completion, also clear the active flag. I had > assumed that all preemptions would be followed by an immediate dequeue > (preserving the active user flag),

[Intel-gfx] [PATCH igt] igt/perf_pmu: Most-busy requires at least one busy engine

The test is whether with all but one engine busy we record the correct load on each engine. If we only have one engine, this test degenerates into all-idle/all-busy, so we can skip to avoid crashing on the assumption that we have a busy spinner. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Include submission tasklet state in engine dump

Chris Wilson writes: > For the off-chance we have an interrupt posted and haven't processed the > CSB. > > v2: Include tasklet enable/disable state for good measure. Reviewed-by: Mika Kuoppala > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 08/11] drm/i915/execlists: Force preemption via reset on timeout

On 26/03/2018 12:50, Chris Wilson wrote: Install a timer when trying to preempt on behalf of an important context such that if the active context does not honour the preemption request within the desired timeout, then we reset the GPU to allow the important context to run. I suggest renaming

Re: [Intel-gfx] [PATCH 08/11] drm/i915/execlists: Force preemption via reset on timeout

Quoting Tvrtko Ursulin (2018-03-27 09:51:20) > > On 26/03/2018 12:50, Chris Wilson wrote: > > +static enum hrtimer_restart preempt_timeout(struct hrtimer *hrtimer) > > +{ > > + struct intel_engine_execlists *execlists = > > + container_of(hrtimer, typeof(*execlists),

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Clear user-active flag on preemption completion

Chris Wilson writes: > When cancelling the requests and clearing out the ports following a > successful preemption completion, also clear the active flag. I had > assumed that all preemptions would be followed by an immediate dequeue > (preserving the active user flag),

Re: [Intel-gfx] [PATCH 15/23] drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

On Tue, Mar 27, 2018 at 09:57:41AM +0200, Daniel Vetter wrote: > On Thu, Mar 22, 2018 at 05:23:05PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Stop playing around with plane->crtc/fb/old_fb with atomic > > drivers. Make life a lot simpler when we

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Use a preemption timeout to enforce interactivity

On 26/03/2018 12:50, Chris Wilson wrote: Use a liberal timeout of 20ms to ensure that the rendering for an interactive pageflip is started in a timely fashion, and that user interaction is not blocked by GPU, or CPU, hogs. This is at the cost of resetting whoever was blocking the preemption,

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Use a preemption timeout to enforce interactivity

On 27/03/2018 09:39, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-03-27 09:35:17) On 26/03/2018 12:50, Chris Wilson wrote: Use a liberal timeout of 20ms to ensure that the rendering for an interactive pageflip is started in a timely fashion, and that user interaction is not blocked by

Re: [Intel-gfx] [PATCH v5 01/12] drm/i915/guc: Add documentation for MMIO based communication

On 3/27/2018 1:18 AM, Michal Wajdeczko wrote: As we are going to extend our use of MMIO based communication, try to explain its mechanics and update corresponding definitions. v2: fix checkpatch MACRO_ARG_REUSE Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo

Re: [Intel-gfx] [PATCH igt 2/8] tests/kms_panel_fitting: check for i915 before checking version

On Wed, Mar 21, 2018 at 10:52:19AM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Wednesday, 21 March 2018 10:34:33 EET Daniel Vetter wrote: > > On Tue, Mar 20, 2018 at 01:24:09PM +0200, Laurent Pinchart wrote: > > > Hi Ulrich, > > > > > > Thank you for the patch. > > > > > > On Thursday,

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

On Mon, Mar 26, 2018 at 11:38:55PM +0100, Chris Wilson wrote: > Quoting Chris Wilson (2018-03-26 21:08:33) > > Quoting Patchwork (2018-03-26 17:53:44) > > > Test gem_userptr_blits: > > > Subgroup coherency-unsync: > > > pass -> INCOMPLETE (shard-hsw) > > > > Forgot

Re: [Intel-gfx] [PATCH 1/2] drm/simple-kms-helper: Plumb plane state to the enable hook

On Sat, Mar 24, 2018 at 12:26:32PM -0500, David Lechner wrote: > On 03/22/2018 03:27 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We'll need access to the plane state during .atomic_enable(). > > > > Some more details in the commit message would be

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

Quoting Daniel Vetter (2018-03-27 11:01:09) > On Tue, Mar 27, 2018 at 08:19:33AM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2018-03-27 07:48:00) > > > On Mon, Mar 26, 2018 at 11:38:55PM +0100, Chris Wilson wrote: > > > > Quoting Chris Wilson (2018-03-26 21:08:33) > > > > > Quoting

Re: [Intel-gfx] [PATCH 01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling

Quoting Mika Kuoppala (2018-03-27 12:34:31) > Chris Wilson writes: > > > If the request is still waiting on external fences, it has not yet been > > submitted to the HW queue and so we can forgo kicking the submission > > tasklet when re-evaluating its priority. > > > >

Re: [Intel-gfx] [PATCH v3 0/6] Documentation patch for batchbuffer submission

Quoting kevin.rogo...@intel.com (2018-03-27 11:26:14) > From: Kevin Rogovin > > Note: I want to make a one or two follow-up series that provide > narration and potentially additional documentation for GUC submission > and the breadcrumbs. > > v3: >More

[Intel-gfx] ✓ Fi.CI.BAT: success for trace: Default to using trace_global_clock if sched_clock is unstable

== Series Details == Series: trace: Default to using trace_global_clock if sched_clock is unstable URL : https://patchwork.freedesktop.org/series/40728/ State : success == Summary == Series 40728v1 trace: Default to using trace_global_clock if sched_clock is unstable

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling (rev2)

== Series Details == Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling (rev2) URL : https://patchwork.freedesktop.org/series/40665/ State : success == Summary == Series 40665v2 series starting with [01/11] drm/i915/execlists:

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

Hi Matt, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on v4.16-rc7 next-20180326] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [Intel-gfx] [PATCH 01/11] drm/i915/perf: pass stream to enable metric set vfuncs

On 26/03/18 20:33, Matthew Auld wrote: On 26 March 2018 at 20:21, Matthew Auld wrote: On 26 March 2018 at 10:08, Lionel Landwerlin wrote: We want to use some of the properties of the perf stream to program the hardware in a later

Re: [Intel-gfx] [PATCH] drm/i915/guc: Unify parameters of public CT functions

On Tue, 20 Mar 2018, Sagar Arun Kamble wrote: > On 3/20/2018 6:30 PM, Michal Wajdeczko wrote: >> On Tue, 20 Mar 2018 08:24:14 +0100, Sagar Arun Kamble >> wrote: >> >>> >>> >>> On 3/19/2018 8:58 PM, Michal Wajdeczko wrote: There is no need

Re: [Intel-gfx] [PATCH v2 1/1] i915: additional GEM documentation

On 02/03/2018 14:09, kevin.rogo...@intel.com wrote: From: Kevin Rogovin This patch provides additional overview documentation to the i915 kernel driver GEM. In addition, it presents already written documentation to i915.rst as well. Signed-off-by: Kevin Rogovin

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for trace: Default to using trace_global_clock if sched_clock is unstable

== Series Details == Series: trace: Default to using trace_global_clock if sched_clock is unstable URL : https://patchwork.freedesktop.org/series/40728/ State : warning == Summary == $ dim checkpatch origin/drm-tip c393b9561028 trace: Default to using trace_global_clock if sched_clock is

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Restore "ALSA: hda: Make use of core codec functions to sync power state"

== Series Details == Series: Restore "ALSA: hda: Make use of core codec functions to sync power state" URL : https://patchwork.freedesktop.org/series/40731/ State : warning == Summary == $ dim checkpatch origin/drm-tip d925f55eae55 Restore "ALSA: hda: Make use of core codec functions to sync

Re: [Intel-gfx] [PATCH 01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling

Chris Wilson writes: > Quoting Mika Kuoppala (2018-03-27 12:34:31) >> Chris Wilson writes: >> >> > If the request is still waiting on external fences, it has not yet been >> > submitted to the HW queue and so we can forgo kicking the

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Clear user-active flag on preemption completion

Quoting Mika Kuoppala (2018-03-27 10:22:11) > Chris Wilson writes: > > > When cancelling the requests and clearing out the ports following a > > successful preemption completion, also clear the active flag. I had > > assumed that all preemptions would be followed by an

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs

On Mon, Mar 26, 2018 at 06:16:22PM -0700, Dhinakaran Pandiyan wrote: > Interrupts other than the one for AUX errors are required only for debug, > so unmask them via debugfs when the user requests debug. > > User can make such a request with > echo 1 > /dri/0/i915_edp_psr_debug > > v2: Unroll

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for trace: Default to using trace_global_clock is sched_clock is unstable

== Series Details == Series: trace: Default to using trace_global_clock is sched_clock is unstable URL : https://patchwork.freedesktop.org/series/40725/ State : warning == Summary == $ dim checkpatch origin/drm-tip e5c9ab3af1d9 trace: Default to using trace_global_clock is sched_clock is

[Intel-gfx] [PATCH v2] trace: Default to using trace_global_clock if sched_clock is unstable

Across suspend, we may see a very large drift in timestamps if the sched clock is unstable, prompting the global trace's ringbuffer code to warn and suggest switching to the global clock. Preempt this request by detecting when the sched clock is unstable (determined during late_initcall) and

Re: [Intel-gfx] [PATCH v3 0/6] Documentation patch for batchbuffer submission

Hi, >>Call out GEM_EXECBUFFER as deprecated. > Oh not it isn't. _WR has a singular purpose that isn't even the recommend > method any more. I had understood that DRM_I915_GEM_EXECBUFFER was considered deprecated. I will fix this mistake on next spin. I had thought that

[Intel-gfx] [PATCH] drm/i915: Check all requests have been retired on switching to kernel context

When asserting the switch to the kernel context is complete, we know that the requests should also have been retired. We can assert that this is so in order to give us some more insight into the state of affairs should we ever see a bug along this path, such as: <4>[ 206.836931]

[Intel-gfx] [CI] Restore "ALSA: hda: Make use of core codec functions to sync power state"

This reverts commit 52e7aa851c22613f9f57e01a6bdb1970e6cb3a41, re-enabling commit 3b5b899ca67db07a4c4825911072221f99e157e2. References: https://bugs.freedesktop.org/show_bug.cgi?id=105069 Cc: Abhijeet Kumar --- sound/pci/hda/hda_codec.c | 28 +---

Re: [Intel-gfx] [PATCH v5 01/12] drm/i915/guc: Add documentation for MMIO based communication

On Tue, 27 Mar 2018 12:05:21 +0200, Sagar Arun Kamble wrote: On 3/27/2018 1:18 AM, Michal Wajdeczko wrote: As we are going to extend our use of MMIO based communication, try to explain its mechanics and update corresponding definitions. v2: fix checkpatch

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Check all requests have been retired on switching to kernel context

== Series Details == Series: drm/i915: Check all requests have been retired on switching to kernel context URL : https://patchwork.freedesktop.org/series/40730/ State : warning == Summary == $ dim checkpatch origin/drm-tip 84242a8ea607 drm/i915: Check all requests have been retired on

Re: [Intel-gfx] [PATCH 01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling

Quoting Mika Kuoppala (2018-03-27 13:18:06) > Chris Wilson writes: > > > Quoting Mika Kuoppala (2018-03-27 12:34:31) > >> Chris Wilson writes: > >> > >> > If the request is still waiting on external fences, it has not yet been > >> >

[Intel-gfx] [PATCH v3 3/5] i915: add documentation for a bit on batchbuffer submission backend

From: Kevin Rogovin Signed-off-by: Kevin Rogovin --- drivers/gpu/drm/i915/intel_ringbuffer.h | 38 + 1 file changed, 38 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h

[Intel-gfx] [PATCH v3 0/6] Documentation patch for batchbuffer submission

From: Kevin Rogovin Note: I want to make a one or two follow-up series that provide narration and potentially additional documentation for GUC submission and the breadcrumbs. v3: More documentation: emphasize that handling of batchbuffer requests creates a request

[Intel-gfx] [PATCH v3 1/5] i915.rst: Narration overview on GEM + minor reorder to improve narration

From: Kevin Rogovin Signed-off-by: Kevin Rogovin --- Documentation/gpu/i915.rst | 129 +--- drivers/gpu/drm/i915/i915_vma.h | 10 +++- 2 files changed, 113 insertions(+), 26 deletions(-) diff --git

[Intel-gfx] [PATCH v3 2/5] i915: add documentation of what happens at the bottom of submitting a batchbuffer

From: Kevin Rogovin Signed-off-by: Kevin Rogovin --- drivers/gpu/drm/i915/intel_ringbuffer.h | 33 + 1 file changed, 33 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h

[Intel-gfx] [PATCH v3 4/5] i915: add doc for synchronization

From: Kevin Rogovin Signed-off-by: Kevin Rogovin --- drivers/gpu/drm/i915/i915_request.h | 28 1 file changed, 28 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_request.h

[Intel-gfx] [PATCH v3 5/5] i915.rst: narration for batchbuffer submission + links to source code doc entries on the subject

From: Kevin Rogovin Signed-off-by: Kevin Rogovin --- Documentation/gpu/i915.rst | 58 +++--- 1 file changed, 49 insertions(+), 9 deletions(-) diff --git a/Documentation/gpu/i915.rst

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs

Quoting Dhinakaran Pandiyan (2018-03-27 02:16:22) > Interrupts other than the one for AUX errors are required only for debug, > so unmask them via debugfs when the user requests debug. > > User can make such a request with > echo 1 > /dri/0/i915_edp_psr_debug > > v2: Unroll loops (Ville) >

[Intel-gfx] ✓ Fi.CI.BAT: success for trace: Default to using trace_global_clock is sched_clock is unstable

== Series Details == Series: trace: Default to using trace_global_clock is sched_clock is unstable URL : https://patchwork.freedesktop.org/series/40725/ State : success == Summary == Series 40725v1 trace: Default to using trace_global_clock is sched_clock is unstable

[Intel-gfx] ✓ Fi.CI.BAT: success for Documentation patch for batchbuffer submission (rev3)

== Series Details == Series: Documentation patch for batchbuffer submission (rev3) URL : https://patchwork.freedesktop.org/series/38433/ State : success == Summary == Series 38433v3 Documentation patch for batchbuffer submission

Re: [Intel-gfx] [PATCH 01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling

Chris Wilson writes: > If the request is still waiting on external fences, it has not yet been > submitted to the HW queue and so we can forgo kicking the submission > tasklet when re-evaluating its priority. > > This should have no impact other than reducing the number

[Intel-gfx] [PATCH v6 08/12] drm/i915/guc: Implement response handling in send_ct()

Instead of returning small data in response status dword, GuC may append longer data as response message payload. If caller provides response buffer, we will copy received data and use number of received data dwords as new success return value. We will WARN if response from GuC does not match

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling (rev2)

== Series Details == Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling (rev2) URL : https://patchwork.freedesktop.org/series/40665/ State : warning == Summary == $ dim checkpatch origin/drm-tip faa8da6b86be drm/i915/execlists:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Support for Guc responses and requests (rev4)

== Series Details == Series: drm/i915/guc: Support for Guc responses and requests (rev4) URL : https://patchwork.freedesktop.org/series/28393/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/guc: Add documentation for MMIO based communication Okay! Commit:

Re: [Intel-gfx] [PATCH 01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling

Chris Wilson writes: > If the request is still waiting on external fences, it has not yet been > submitted to the HW queue and so we can forgo kicking the submission > tasklet when re-evaluating its priority. > > This should have no impact other than reducing the number

[Intel-gfx] [PATCH v2] drm/i915/execlists: Flush pending preemption events during reset

Catch up with the inflight CSB events, after disabling the tasklet before deciding which request was truly guilty of hanging the GPU. v2: Restore checking of use_csb_mmio on every loop, don't forget old vgpu. Signed-off-by: Chris Wilson Cc: Michał Winiarski

Re: [Intel-gfx] [PATCH v2 1/1] i915: additional GEM documentation

Hi, Thankyou for the very thorough read and comments, this is exactly what is needed to give it polish and become a good intro to GEM in i915; I just wished I had waited on posting a v3 just a few more hours and I would have been able to use all this for v3. I will use all of your comments in

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check all requests have been retired on switching to kernel context

== Series Details == Series: drm/i915: Check all requests have been retired on switching to kernel context URL : https://patchwork.freedesktop.org/series/40730/ State : success == Summary == Series 40730v1 drm/i915: Check all requests have been retired on switching to kernel context

[Intel-gfx] ✗ Fi.CI.BAT: failure for Restore "ALSA: hda: Make use of core codec functions to sync power state"

== Series Details == Series: Restore "ALSA: hda: Make use of core codec functions to sync power state" URL : https://patchwork.freedesktop.org/series/40731/ State : failure == Summary == Series 40731v1 Restore "ALSA: hda: Make use of core codec functions to sync power state"

Re: [Intel-gfx] [PATCH 2/3] drm/i915/execlists: Delay updating ring register state after resume

Quoting Chris Wilson (2018-03-27 22:01:56) > Now that we reload both RING_HEAD and RING_TAIL when rebinding the > context, we do not need to scrub those registers immediately on resume. So CI reports that contrary to my belief, we didn't do a i915_gem_contexts_lost() across suspend. Hmm, nope

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

Quoting Zhang, Yunwei (2018-03-27 23:49:27) > > > On 3/27/2018 3:27 PM, Chris Wilson wrote: > > Quoting Yunwei Zhang (2018-03-27 23:14:16) > >> WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO > >> read into Slice/Subslice specific registers, MCR packet control > >>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Support for Guc responses and requests (rev5)

== Series Details == Series: drm/i915/guc: Support for Guc responses and requests (rev5) URL : https://patchwork.freedesktop.org/series/28393/ State : success == Summary == Series 28393v5 drm/i915/guc: Support for Guc responses and requests

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper

== Series Details == Series: series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper URL : https://patchwork.freedesktop.org/series/40768/ State : warning == Summary == $ dim checkpatch origin/drm-tip d10b9c355a96 drm/dp: Move DPCD_REV_XX to drm_dp_helper 553565ba74e0 drm/dp:

Re: [Intel-gfx] [PATCH 1/8] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances

Em Ter, 2018-03-27 às 15:42 -0700, Paulo Zanoni escreveu: > Em Sex, 2018-03-23 às 16:28 +, Lionel Landwerlin escreveu: > > Hi Mika, > > > > Even after this series, we're still missing support for reading > > the > > timestamp frequency (read_timestamp_frequency in > > intel_device_info.c). >

Re: [Intel-gfx] [PATCH 04/12] drm/i915/psr: Tie PSR2 support to Y coordinate requirement

Selective update testing play a video and check 0x60094 , (03, 06) will indicated that system is in su state. -Original Message- From: Vivi, Rodrigo Sent: Wednesday, March 28, 2018 3:07 AM To: Pandiyan, Dhinakaran Cc: Souza, Jose

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v5,1/8] drm/i915: Correctly handle error path in i915_gem_init_hw

== Series Details == Series: series starting with [v5,1/8] drm/i915: Correctly handle error path in i915_gem_init_hw URL : https://patchwork.freedesktop.org/series/40759/ State : failure == Summary == Possible new issues: Test drm_mm: Subgroup sanitycheck: pass

Re: [Intel-gfx] [PATCH 1/8] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances

Em Sex, 2018-03-23 às 16:28 +, Lionel Landwerlin escreveu: > Hi Mika, > > Even after this series, we're still missing support for reading the > timestamp frequency (read_timestamp_frequency in > intel_device_info.c). > I'm pretty sure someone wrote a patch for it. Do you any idea? > > If

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts

== Series Details == Series: series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts URL : https://patchwork.freedesktop.org/series/40764/ State : failure == Summary == Series 40764v1 series starting with [1/3] drm/i915/execlists: Reset ring registers on

Re: [Intel-gfx] [PATCH v1] drm/i915/gen11: Preempt-to-idle support in execlists.

Quoting Tomasz Lis (2018-03-27 16:17:59) > The patch adds support of preempt-to-idle requesting by setting a proper > bit within Execlist Control Register, and receiving preemption result from > Context Status Buffer. > > Preemption in previous gens required a special batch buffer to be executed,

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper

== Series Details == Series: series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper URL : https://patchwork.freedesktop.org/series/40768/ State : success == Summary == Series 40768v1 series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts

== Series Details == Series: series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts URL : https://patchwork.freedesktop.org/series/40764/ State : warning == Summary == $ dim checkpatch origin/drm-tip f73f2b30c417 drm/i915/execlists: Reset ring registers on

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Support for Guc responses and requests (rev5)

== Series Details == Series: drm/i915/guc: Support for Guc responses and requests (rev5) URL : https://patchwork.freedesktop.org/series/28393/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/guc: Add documentation for MMIO based communication Okay! Commit:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev5)

== Series Details == Series: series starting with [v5,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev5) URL : https://patchwork.freedesktop.org/series/40503/ State : success == Summary == Series 40503v5 series starting with [v5,1/2] drm/i915/cnl: Implement

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

Quoting Yunwei Zhang (2018-03-27 23:14:16) > WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO > read into Slice/Subslice specific registers, MCR packet control > register(0xFDC) needs to be programmed to point to any enabled > slice/subslice pair. Otherwise, incorrect

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

On 3/27/2018 3:27 PM, Chris Wilson wrote: Quoting Yunwei Zhang (2018-03-27 23:14:16) WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts (rev2)

== Series Details == Series: series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts (rev2) URL : https://patchwork.freedesktop.org/series/40764/ State : warning == Summary == $ dim checkpatch origin/drm-tip ef3a65fcec9e drm/i915/execlists: Reset ring

Re: [Intel-gfx] [PULL] more gvt-next-fixes for 4.17

On 2018.03.27 16:42:28 +0300, Joonas Lahtinen wrote: > Quoting Zhenyu Wang (2018-03-27 11:39:42) > > > > Hi, Joonas > > > > Here's this week's gvt-next-fixes queued for 4.17. One notable change > > is to revert previous workaround for gvt context preemption, now it > > has full support for

Re: [Intel-gfx] [PATCH v7 10/12] drm/i915/guc: Handle default action received over CT

On 3/27/2018 2:41 PM, Michal Wajdeczko wrote: When running on platform with CTB based GuC communication enabled, GuC to Host event data will be delivered as CT request message. However, content of the data[1] of this CT message follows format of the scratch register used in MMIO based

[Intel-gfx] [PATCH v5 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a MMIO read into L3Bank range will return 0

[Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will be returned. However, that means each

[Intel-gfx] [PATCH v2] drm/i915/execlists: Delay updating ring register state after resume

Now that we reload both RING_HEAD and RING_TAIL when rebinding the context, we do not need to scrub those registers immediately on resume. v2: Handle the perma-pinned contexts. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts (rev2)

== Series Details == Series: series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts (rev2) URL : https://patchwork.freedesktop.org/series/40764/ State : success == Summary == Series 40764v2 series starting with [1/3] drm/i915/execlists: Reset ring

Re: [Intel-gfx] [PULL] more gvt-next-fixes for 4.17

Quoting Zhenyu Wang (2018-03-27 11:39:42) > > Hi, Joonas > > Here's this week's gvt-next-fixes queued for 4.17. One notable change > is to revert previous workaround for gvt context preemption, now it > has full support for preemption now. I've pulled the patches, but this revert sounds fishy.

[Intel-gfx] ✗ Fi.CI.IGT: failure for Documentation patch for batchbuffer submission (rev3)

== Series Details == Series: Documentation patch for batchbuffer submission (rev3) URL : https://patchwork.freedesktop.org/series/38433/ State : failure == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-wc:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gen11: Preempt-to-idle support in execlists.

== Series Details == Series: drm/i915/gen11: Preempt-to-idle support in execlists. URL : https://patchwork.freedesktop.org/series/40747/ State : warning == Summary == $ dim checkpatch origin/drm-tip 96268839cd00 drm/i915/gen11: Preempt-to-idle support in execlists. -:97:

  1   2   >