Re: [Intel-gfx] [PATCH] drm/i915: Report if an unbannable context is involved in a GPU hang

Chris Wilson writes: > Since unbannable contexts are special and supposed not to be causing GPU > hangs in the first place, make it clear when they are implicated in said > hang. In practice, most unbannable contexts are those created by igt > for the express purpose of

[Intel-gfx] [PATCH] drm/i915: Add some newlines to intel_engine_dump() headers

The headers should be on a separate line for consistency, so add the missing trailing newline in a few intel_engine_dump() callers. Reported-by: Mika Kuoppala Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Fix PMU enable vs execlists tasklet race (rev2)

== Series Details == Series: drm/i915/pmu: Fix PMU enable vs execlists tasklet race (rev2) URL : https://patchwork.freedesktop.org/series/37575/ State : success == Summary == Series 37575v2 drm/i915/pmu: Fix PMU enable vs execlists tasklet race

[Intel-gfx] ✓ Fi.CI.IGT: success for RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read

== Series Details == Series: RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read URL : https://patchwork.freedesktop.org/series/37644/ State : success == Summary == Test perf_pmu: Subgroup busy-double-start-vcs0: pass -> INCOMPLETE (shard-apl)

Re: [Intel-gfx] [PATCH] drm/i915: Always update the no_fbc_reason when disabling

On Sat, 03 Feb 2018, Chris Wilson wrote: > Quoting Chris Wilson (2018-01-25 22:41:22) >> Provide the reason why we call intel_fbc_deactivate() so that debugging >> issues with FBC being delayed is clearer. >> >> Signed-off-by: Chris Wilson > >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Report if an unbannable context is involved in a GPU hang

== Series Details == Series: drm/i915: Report if an unbannable context is involved in a GPU hang URL : https://patchwork.freedesktop.org/series/37648/ State : success == Summary == Test perf: Subgroup enable-disable: pass -> FAIL (shard-apl) fdo#103715 Test

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Ignore minimum lines for level 0 in skl_compute_plane_wm, v2.

== Series Details == Series: drm/i915: Ignore minimum lines for level 0 in skl_compute_plane_wm, v2. URL : https://patchwork.freedesktop.org/series/37654/ State : success == Summary == Series 37654v1 drm/i915: Ignore minimum lines for level 0 in skl_compute_plane_wm, v2.

Re: [Intel-gfx] [PATCH] drm/i915: Add some newlines to intel_engine_dump() headers

Chris Wilson writes: > The headers should be on a separate line for consistency, so add the > missing trailing newline in a few intel_engine_dump() callers. > > Reported-by: Mika Kuoppala > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH v2] drm/i915/pmu: Fix PMU enable vs execlists tasklet race

Quoting Tvrtko Ursulin (2018-02-05 09:34:48) > From: Tvrtko Ursulin > > Commit 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking > inside for busy-stats") added a tasklet_disable call in busy stats > enabling, but we failed to understand that the PMU

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Report if an unbannable context is involved in a GPU hang

== Series Details == Series: drm/i915: Report if an unbannable context is involved in a GPU hang URL : https://patchwork.freedesktop.org/series/37648/ State : success == Summary == Series 37648v1 drm/i915: Report if an unbannable context is involved in a GPU hang

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read

On 05/02/2018 10:31, Patchwork wrote: == Series Details == Series: RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read URL : https://patchwork.freedesktop.org/series/37644/ State : success == Summary == Test perf_pmu: Subgroup busy-double-start-vcs0:

[Intel-gfx] [PATCH i-g-t 1/2] tests/testdisplay: Explicitly use GLIB_CFLAGS

From: Thierry Reding testdisplay.h includes the glib.h header file but the Makefile does not explicitly pass a -I option with the path containing that header, hence causing the build to fail. Note that this doesn't seem to happen with a recent enough version of cairo, which

[Intel-gfx] [PATCH i-g-t 2/2] tools/intel_dp_compliance: Add missing GLIB_CFLAGS

From: Thierry Reding intel_dp_compliance.h includes the glib.h header file but the Makefile does not explicitly pass a -I option with the path containing that header, hence causing the build to fail. Note that this doesn't seem to happen with a recent enough version of cairo,

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Show the GPU state when declaring wedged

Chris Wilson writes: > Dump each engine state when i915_gem_set_wedged() is called to give us > some more clues as to why we had to terminate the GPU. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen >

[Intel-gfx] [PATCH] drm/i915: Ignore minimum lines for level 0 in skl_compute_plane_wm, v2.

According to bspec, result_lines > 31 is only a maximum for latency level 1 through 7. For level 0 the number of lines is ignored, so always write 0 there to prevent overflowing the 5 bits value. This is required to make NV12 work. Changes since v1: - Rebase on top of GEN11 wm changes. It seems

Re: [Intel-gfx] [PATCH] RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read

On 05/02/2018 09:11, Chris Wilson wrote: The pmu_event_read() callchain is in an atomic context which then Call-chain. forbids us sleeping, such as required to wake the device up for rpm. In this case, we can only read our registers iff the device is already s/iff/if/ awake. In the case

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/7] drm/i915/selftests: Flush old resets between engines

== Series Details == Series: series starting with [1/7] drm/i915/selftests: Flush old resets between engines URL : https://patchwork.freedesktop.org/series/37645/ State : warning == Summary == Series 37645v1 series starting with [1/7] drm/i915/selftests: Flush old resets between engines

Re: [Intel-gfx] [PATCH] drm/i915/icl: remove port A/E lane sharing limitation.

On Mon, 05 Feb 2018, "Kumar, Mahesh" wrote: > Hi, > > > On 2/2/2018 6:26 PM, Jani Nikula wrote: >> On Fri, 02 Feb 2018, Mahesh Kumar wrote: >>> Platforms before Gen11 were sharing lanes between port-A & port-E. >>> This limitation is no more

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Show the GPU state when declaring wedged

Quoting Mika Kuoppala (2018-02-05 09:51:42) > Chris Wilson writes: > > > Dump each engine state when i915_gem_set_wedged() is called to give us > > some more clues as to why we had to terminate the GPU. > > > > Signed-off-by: Chris Wilson > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add some newlines to intel_engine_dump() headers

== Series Details == Series: drm/i915: Add some newlines to intel_engine_dump() headers URL : https://patchwork.freedesktop.org/series/37651/ State : failure == Summary == Series 37651v1 drm/i915: Add some newlines to intel_engine_dump() headers

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Ignore minimum lines for level 0 in skl_compute_plane_wm, v2.

== Series Details == Series: drm/i915: Ignore minimum lines for level 0 in skl_compute_plane_wm, v2. URL : https://patchwork.freedesktop.org/series/37654/ State : success == Summary == Test perf: Subgroup enable-disable: pass -> FAIL (shard-apl) fdo#103715

Re: [Intel-gfx] [PATCH] RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read

Quoting Tvrtko Ursulin (2018-02-05 09:47:52) > > On 05/02/2018 09:11, Chris Wilson wrote: > > The pmu_event_read() callchain is in an atomic context which then > > Call-chain. > > > forbids us sleeping, such as required to wake the device up for rpm. > > In this case, we can only read our

Re: [Intel-gfx] [RFC 3/3] drm/i915: obliterate PCH types in favour of direct PCH id use

On Fri, 02 Feb 2018, Chris Wilson wrote: > Quoting Jani Nikula (2018-02-02 20:01:00) >> The PCH type is an unnecessary level of abstraction that's an extra >> maintenance burden. Switch to using PCH ids directly. This also >> simplifies the virtual PCH detection. > > But

Re: [Intel-gfx] [PATCH v2] drm/i915/breadcrumbs: Drop request reference for the signaler thread

Quoting Tvrtko Ursulin (2018-02-05 13:23:54) > > On 03/02/2018 10:19, Chris Wilson wrote: > > @@ -656,41 +705,21 @@ static int intel_breadcrumbs_signaler(void *arg) > >* a new client. > >*/ > > rcu_read_lock(); > > - request =

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read

Quoting Tvrtko Ursulin (2018-02-05 13:37:42) > > On 05/02/2018 13:18, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-02-05 11:45:17) > >> > >> On 05/02/2018 10:31, Patchwork wrote: > >>> == Series Details == > >>> > >>> Series: RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read

Re: [Intel-gfx] [PATCH 1/7] drm/i915/selftests: Flush old resets between engines

Chris Wilson writes: > When injecting rapid resets, we must be careful to at least wait for the > previous reset to have taken effect and the engine restarted. If we > perform a second reset before that has happened, we will notice that the > engine hasn't recovered and

[Intel-gfx] [CI 1/2] drm/i915/selftests: Flush old resets between engines

When injecting rapid resets, we must be careful to at least wait for the previous reset to have taken effect and the engine restarted. If we perform a second reset before that has happened, we will notice that the engine hasn't recovered and declare it lost, wedging the device and failing. In

[Intel-gfx] [CI 2/2] drm/i915/selftests: Use a sacrificial context for hang testing

Avoid injecting hangs in to the i915->kernel_context in case the GPU reset leaves corruption in the context image in its wake (leading to continual failures and system hangs after the selftests are ostensibly complete). Use a sacrificial kernel_context instead. v2: Closing a context is tricky;

Re: [Intel-gfx] [PATCH] drm/crc: Add support for polling on the data fd.

Op 05-02-18 om 15:16 schreef Ville Syrjälä: > On Mon, Feb 05, 2018 at 01:59:05PM +0100, Maarten Lankhorst wrote: >> Op 02-02-18 om 15:46 schreef Ville Syrjälä: >>> On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote: This will make it possible for userspace to know whether

Re: [Intel-gfx] [PATCH v2] drm/i915/breadcrumbs: Drop request reference for the signaler thread

Quoting Chris Wilson (2018-02-05 13:36:36) > Quoting Tvrtko Ursulin (2018-02-05 13:23:54) > > > > On 03/02/2018 10:19, Chris Wilson wrote: > > > @@ -656,41 +705,21 @@ static int intel_breadcrumbs_signaler(void *arg) > > >* a new client. > > >*/ > > >

Re: [Intel-gfx] [PATCH] drm/crc: Add support for polling on the data fd.

On Mon, Feb 05, 2018 at 01:59:05PM +0100, Maarten Lankhorst wrote: > Op 02-02-18 om 15:46 schreef Ville Syrjälä: > > On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote: > >> This will make it possible for userspace to know whether reading > >> will block, without blocking on the fd.

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Remove unbannable context spam from reset

Quoting Chris Wilson (2018-02-05 09:30:27) > Quoting Chris Wilson (2018-02-05 09:22:01) > > During testing, we trigger a lot of resets on an unbannable context > > leading to massive amounts of irrelevant debug spam. Remove the > > ban_score accounting and message for the unbannable context so

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/2] drm/i915/selftests: Flush old resets between engines

== Series Details == Series: series starting with [CI,1/2] drm/i915/selftests: Flush old resets between engines URL : https://patchwork.freedesktop.org/series/37661/ State : warning == Summary == Series 37661v1 series starting with [CI,1/2] drm/i915/selftests: Flush old resets between

Re: [Intel-gfx] [PATCH] drm/crc: Add support for polling on the data fd.

Op 02-02-18 om 15:46 schreef Ville Syrjälä: > On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote: >> This will make it possible for userspace to know whether reading >> will block, without blocking on the fd. This makes it possible to >> drain all queued CRC's in blocking mode,

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read

Quoting Tvrtko Ursulin (2018-02-05 11:45:17) > > On 05/02/2018 10:31, Patchwork wrote: > > == Series Details == > > > > Series: RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read > > URL : https://patchwork.freedesktop.org/series/37644/ > > State : success > > > > == Summary == >

Re: [Intel-gfx] [PATCH] drm/i915: Always update the no_fbc_reason when disabling

Quoting Jani Nikula (2018-02-05 11:05:09) > On Sat, 03 Feb 2018, Chris Wilson wrote: > > Quoting Chris Wilson (2018-01-25 22:41:22) > >> Provide the reason why we call intel_fbc_deactivate() so that debugging > >> issues with FBC being delayed is clearer. > >> > >>

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read

On 05/02/2018 13:18, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-02-05 11:45:17) On 05/02/2018 10:31, Patchwork wrote: == Series Details == Series: RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read URL : https://patchwork.freedesktop.org/series/37644/ State : success ==

Re: [Intel-gfx] [PATCH v2] drm/i915/breadcrumbs: Drop request reference for the signaler thread

On 05/02/2018 13:36, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-02-05 13:23:54) On 03/02/2018 10:19, Chris Wilson wrote: @@ -656,41 +705,21 @@ static int intel_breadcrumbs_signaler(void *arg) * a new client. */ rcu_read_lock(); -

Re: [Intel-gfx] [PATCH 2/7] drm/i915/selftests: Use a sacrificial context for hang testing

Chris Wilson writes: > Avoid injecting hangs in to the i915->kernel_context in case the GPU > reset leaves corruption in the context image in its wake (leading to > continual failures and system hangs after the selftests are ostensibly > complete). Use a sacrificial

Re: [Intel-gfx] [PATCH 2/7] drm/i915/selftests: Use a sacrificial context for hang testing

Quoting Mika Kuoppala (2018-02-05 14:02:55) > Chris Wilson writes: > > diff --git a/drivers/gpu/drm/i915/selftests/mock_context.c > > b/drivers/gpu/drm/i915/selftests/mock_context.c > > index bbf80d42e793..501becc47c0c 100644 > > ---

[Intel-gfx] [CI 1/4] drm/i915/selftests: Flush old resets between engines

When injecting rapid resets, we must be careful to at least wait for the previous reset to have taken effect and the engine restarted. If we perform a second reset before that has happened, we will notice that the engine hasn't recovered and declare it lost, wedging the device and failing. In

[Intel-gfx] [CI 4/4] drm/i915: Skip post-reset request emission if the engine is not idle

Since commit 7b6da818d86f ("drm/i915: Restore the kernel context after a GPU reset on an idle engine") we submit a request following the engine reset. The intent is that we don't submit a request if the engine is busy (as it will restart active by itself) but we only checked to see if there were

[Intel-gfx] [CI 3/4] drm/i915/execlists: Move the reset bits to a more natural home

In preparation for the next patch, we want the engine to appear idle after a reset (if there are no requests in flight). For execlists, this entails clearing the active status on reset, it will be regenerated on restarting the engine after the reset. In the process, note that a couple of other

Re: [Intel-gfx] [PATCH 04/10] drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()

On 2018-02-03 12:12 AM, Dhinakaran Pandiyan wrote: > 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the > return type for drm_crtc_vblank_count() to u64. This could cause > potential problems if the return value is used in arithmetic operations > with a 32-bit reference HW vblank

Re: [Intel-gfx] [PATCH 3/7] drm/i915/execlists: Move the reset bits to a more natural home

Chris Wilson writes: > In preparation for the next patch, we want the engine to appear idle > after a reset (if there are no requests in flight). For execlists, this > entails clearing the active status on reset, it will be regenerated on > restarting the engine after

[Intel-gfx] [PATCH 3/6] drm/i915/icl: implement the display init/uninit sequences

This code is similar enough to the CNL code that I considered just adding ICL support to the CNL function, but I think it's still different enough, and having a function specific to ICL allows us to more easily adapt code in case the spec changes more later. We're still missing the power wells

[Intel-gfx] [PATCH 4/6] drm/i915/icl: Enable both DBuf slices during init

From: Mahesh Kumar ICL has 2 slices of DBuf, enable both the slices during display init. Ideally we should only enable the second slice when needed in order to save power, but while we're not there yet, adopt the simpler solution to keep us bug-free. v2 (from Paulo):

[Intel-gfx] [PATCH 2/6] drm/i915/icl: add the main CDCLK functions

This commit adds the basic CDCLK functions, but it's still missing pieces of the display initialization sequence. v2: - Implement the voltage levels. - Rebase. v3: - Adjust to the new "bypass" clock (Imre). - Call intel_dump_cdclk_state() too. - Rename a variable to avoid confusion. -

[Intel-gfx] [PATCH 0/6] ICL display initialization, selected patches

Hi These are 6 selected patches form the series "ICL display initialization and some plane bits". Only patch 2 still needs review, the others are already reviewed. The original series of 17 patches triggered some CI errors that definitely seem to be the fault of the series. Some of the patches

[Intel-gfx] [PATCH 1/6] drm/i915/icl: add ICL support to cnl_set_procmon_ref_values

On ICL we have two sets of registers: one for port A and another for port B. The set of port A registers is the same as the CNL registers. Since the procmon table on ICL is the same we want to reuse the CNL function. To do that we add a port argument and make CNL always call the function passing

[Intel-gfx] [PATCH 5/6] drm/i915/icl: initialize MBus during display init

From: Mahesh Kumar This patch initializes MBus during display initialization. Changes since V2 (from Paulo): - Don't forget to remove the WARN_ON(1) call. Changes since V1: - Rebase to use function like Macros Reviewed-by: Paulo Zanoni

[Intel-gfx] [PATCH 6/6] drm/i915/icl: program mbus during pipe enable

From: Mahesh Kumar This patch program default values of MBus credit during pipe enable. Changes since V2: - We don't need to do anything when disabling the pipe Changes Since V1: - Add WARN_ON (Paulo) - Remove TODO comment - Program 0 during pipe disable - Rebase

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/4] drm/i915/selftests: Flush old resets between engines

== Series Details == Series: series starting with [CI,1/4] drm/i915/selftests: Flush old resets between engines URL : https://patchwork.freedesktop.org/series/37667/ State : warning == Summary == Series 37667v1 series starting with [CI,1/4] drm/i915/selftests: Flush old resets between

[Intel-gfx] [CI 2/2] drm/i915/cmdparser: Do not check past the cmd length.

From: Michal Srb The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2. In that case check_cmd will read bits from the following command, or even past the end of the buffer. If the

[Intel-gfx] [CI 1/2] drm/i915/cmdparser: Check reg_table_count before derefencing.

From: Michal Srb The find_reg function was assuming that there is always at least one table in reg_tables. It is not always true. In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0, implying that no register-accessing commands are allowed. However, the

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/breadcrumbs: Drop request reference for the signaler thread (rev2)

Quoting Patchwork (2018-02-03 11:32:01) > == Series Details == > > Series: drm/i915/breadcrumbs: Drop request reference for the signaler thread > (rev2) > URL : https://patchwork.freedesktop.org/series/36908/ > State : failure > > == Summary == > > Test perf_pmu: > Subgroup

Re: [Intel-gfx] [PATCH v2] drm/i915/breadcrumbs: Drop request reference for the signaler thread

Quoting Tvrtko Ursulin (2018-02-05 13:45:16) > > On 05/02/2018 13:36, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-02-05 13:23:54) > >> How would you view taking the request->lock over this block in the > >> signaler and then being able to call simply > >> intel_engine_cancel_signaling -

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count before derefencing.

== Series Details == Series: series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count before derefencing. URL : https://patchwork.freedesktop.org/series/37669/ State : success == Summary == Series 37669v1 series starting with [CI,1/2] drm/i915/cmdparser: Check reg_table_count

[Intel-gfx] ✗ Fi.CI.BAT: warning for ICL display initialization, selected patches

== Series Details == Series: ICL display initialization, selected patches URL : https://patchwork.freedesktop.org/series/37668/ State : warning == Summary == Series 37668v1 ICL display initialization, selected patches https://patchwork.freedesktop.org/api/1.0/series/37668/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 6/6] drm/i915/icl: program mbus during pipe enable

On Mon, Feb 05, 2018 at 01:40:46PM -0200, Paulo Zanoni wrote: > From: Mahesh Kumar > > This patch program default values of MBus credit during pipe enable. > > Changes since V2: > - We don't need to do anything when disabling the pipe > Changes Since V1: > - Add

Re: [Intel-gfx] [PATCH v3 4/8] drm/i915: Retry HDCP bksv read

On Sat, Feb 03, 2018 at 03:39:06AM +0530, Ramalingam C wrote: > HDCP specification says that when bksv is identified as invalid > (not with 20 1s), bksv should be re-read and verified. > > This patch adds the above mentioned re-read for bksv. > > v2: > Rephrased the commit msg [Seanpaul] > >

Re: [Intel-gfx] [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec

On Sat, Feb 03, 2018 at 03:39:02AM +0530, Ramalingam C wrote: > This series is developed to address the expectations from HDCP compliance > test specification. > > 6/8 patches are for fixing failures in one or more compliance test cases > 2 patches are Good to have kind. Not related to

Re: [Intel-gfx] [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec

> -Original Message- > From: Sean Paul [mailto:seanp...@chromium.org] > Sent: Monday, February 5, 2018 10:21 PM > To: C, Ramalingam > Cc: intel-gfx@lists.freedesktop.org; seanp...@chromium.org; Vivi, Rodrigo > ; Sharma, Shashank

[Intel-gfx] [PATCH v4] drm/i915: Retry HDCP bksv read

HDCP specification says that when bksv is identified as invalid (not with 20 1s), bksv should be re-read and verified. This patch adds the above mentioned re-read for bksv. v2: Rephrased the commit msg [Seanpaul] v3: do-while to for-loop [Seanpaul] v4: retry only if bksv is invalid and

[Intel-gfx] [PATCH 6/6] drm/i915/icl: program mbus during pipe enable

From: Mahesh Kumar This patch program default values of MBus credit during pipe enable. Changes Since V1: - Add WARN_ON (Paulo) - Remove TODO comment - Program 0 during pipe disable - Rebase Changes since V2: - We don't need to do anything when disabling the pipe

Re: [Intel-gfx] [PATCH v4] drm/i915: Retry HDCP bksv read

On Mon, Feb 05, 2018 at 10:44:41PM +0530, Ramalingam C wrote: > HDCP specification says that when bksv is identified as invalid > (not with 20 1s), bksv should be re-read and verified. > > This patch adds the above mentioned re-read for bksv. > > v2: > Rephrased the commit msg [Seanpaul] > >

Re: [Intel-gfx] [PATCH 2/6] drm/i915/execlists: Remove the startup spam

Chris Wilson writes: > Execlists is now enabled by default and included in the list of > capabilities printed out to dmesg and beyond. We do not need to mention > it again, every time we restart the engine, so kill the spam. > > Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH] RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read

The pmu_event_read() callchain is in an atomic context which then forbids us sleeping, such as required to wake the device up for rpm. In this case, we can only read our registers iff the device is already awake. In the case of rc6 this means that we cannot report the latest values when the whole

[Intel-gfx] [PATCH 1/7] drm/i915/selftests: Flush old resets between engines

When injecting rapid resets, we must be careful to at least wait for the previous reset to have taken effect and the engine restarted. If we perform a second reset before that has happened, we will notice that the engine hasn't recovered and declare it lost, wedging the device and failing. In

[Intel-gfx] [PATCH 7/7] drm/i915: Remove unbannable context spam from reset

During testing, we trigger a lot of resets on an unbannable context leading to massive amounts of irrelevant debug spam. Remove the ban_score accounting and message for the unbannable context so that we improve the signal:noise in the log messages for when the unexpected occurs. Signed-off-by:

[Intel-gfx] [PATCH 2/7] drm/i915/selftests: Use a sacrificial context for hang testing

Avoid injecting hangs in to the i915->kernel_context in case the GPU reset leaves corruption in the context image in its wake (leading to continual failures and system hangs after the selftests are ostensibly complete). Use a sacrificial kernel_context instead. v2: Closing a context is tricky;

[Intel-gfx] [PATCH 6/7] drm/i915/execlists: Remove the startup spam

Execlists is now enabled by default and included in the list of capabilities printed out to dmesg and beyond. We do not need to mention it again, every time we restart the engine, so kill the spam. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala

[Intel-gfx] [PATCH 4/7] drm/i915: Skip post-reset request emission if the engine is not idle

Since commit 7b6da818d86f ("drm/i915: Restore the kernel context after a GPU reset on an idle engine") we submit a request following the engine reset. The intent is that we don't submit a request if the engine is busy (as it will restart active by itself) but we only checked to see if there were

[Intel-gfx] [PATCH 3/7] drm/i915/execlists: Move the reset bits to a more natural home

In preparation for the next patch, we want the engine to appear idle after a reset (if there are no requests in flight). For execlists, this entails clearing the active status on reset, it will be regenerated on restarting the engine after the reset. In the process, note that a couple of other

[Intel-gfx] [PATCH 5/7] drm/i915: Show the GPU state when declaring wedged

Dump each engine state when i915_gem_set_wedged() is called to give us some more clues as to why we had to terminate the GPU. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem.c | 7 +++ 1 file

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Remove unbannable context spam from reset

Chris Wilson writes: > During testing, we trigger a lot of resets on an unbannable context > leading to massive amounts of irrelevant debug spam. Remove the > ban_score accounting and message for the unbannable context so that we > improve the signal:noise in the log

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Remove unbannable context spam from reset

Quoting Mika Kuoppala (2018-02-05 09:25:14) > Chris Wilson writes: > > > During testing, we trigger a lot of resets on an unbannable context > > leading to massive amounts of irrelevant debug spam. Remove the > > ban_score accounting and message for the unbannable

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Remove unbannable context spam from reset

Quoting Chris Wilson (2018-02-05 09:22:01) > During testing, we trigger a lot of resets on an unbannable context > leading to massive amounts of irrelevant debug spam. Remove the > ban_score accounting and message for the unbannable context so that we > improve the signal:noise in the log messages

Re: [Intel-gfx] [PATCH] drm/i915/icl: remove port A/E lane sharing limitation.

Hi, On 2/2/2018 6:26 PM, Jani Nikula wrote: On Fri, 02 Feb 2018, Mahesh Kumar wrote: Platforms before Gen11 were sharing lanes between port-A & port-E. This limitation is no more there. Changes since V1: - optimize the code (Shashank/Jani) - create helper

[Intel-gfx] [PATCH v2] drm/i915/pmu: Fix PMU enable vs execlists tasklet race

From: Tvrtko Ursulin Commit 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking inside for busy-stats") added a tasklet_disable call in busy stats enabling, but we failed to understand that the PMU enable callback runs as an hard IRQ (IPI). Consequence of

[Intel-gfx] ✓ Fi.CI.BAT: success for RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read

== Series Details == Series: RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read URL : https://patchwork.freedesktop.org/series/37644/ State : success == Summary == Series 37644v1 RFC drm/i915/pmu: Avoid sleeping rpm_get under atomic PMU read

[Intel-gfx] [PATCH] drm/i915: Report if an unbannable context is involved in a GPU hang

Since unbannable contexts are special and supposed not to be causing GPU hangs in the first place, make it clear when they are implicated in said hang. In practice, most unbannable contexts are those created by igt for the express purpose of throwing untold thousands of hangs at the GPU and wish

Re: [Intel-gfx] Enabling i915 Panel Self Refresh by default on some devices ?

Hi Hans, On Fri, Feb 02, 2018 at 09:55:32AM +, Hans de Goede wrote: > Hi, > > On 01-02-18 13:31, Hans de Goede wrote: > > Hi All, > > > > As you may have heard I've recently been working on improving > > Linux laptop battery life, specifically the OOTB experience > > without tweaking any

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

Rodrigo Vivi writes: > I didn't checked the drm one close enough yet to decide for that. > DK or Keith? do you guys see anyone suitable for fixes? Yeah, we should probably get 1, 3 and 7 into fixes. 2, 4, 5 and 6 add explicit casts where the compiler would already

Re: [Intel-gfx] i915 PSR test results and cursor lag

> On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi wrote: > >> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote: >>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote: On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski

[Intel-gfx] [PATCH v8 4/6] drm/i915/guc: Add dynamic GuC WOPCM offset and size support for CNL

CNL has its own specific reserved GuC WOPCM size and hardware restrictions on GuC WOPCM size. On CNL A0 and Gen9, there's a hardware restriction that requires the available GuC WOPCM size to be larger than or equal to HuC firmware size. This patch updates GuC WOPCM init code to return the CNL

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Mon, Feb 05, 2018 at 11:54:04PM +, Andy Lutomirski wrote: > > > > On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi wrote: > > > >> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote: > >>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski

Re: [Intel-gfx] Enabling i915 Panel Self Refresh by default on some devices ?

On Thu, 2018-02-01 at 13:31 +0100, Hans de Goede wrote: > Hi All, > > As you may have heard I've recently been working on improving > Linux laptop battery life, specifically the OOTB experience > without tweaking any options such as e.g. powertop --auto-tune > would do, see: > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v8,1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

== Series Details == Series: series starting with [v8,1/6] drm/i915/guc: Move GuC WOPCM related code into separate files URL : https://patchwork.freedesktop.org/series/37704/ State : failure == Summary == Series 37704v1 series starting with [v8,1/6] drm/i915/guc: Move GuC WOPCM related code

[Intel-gfx] [PATCH v3] drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

This workaround should prevent a bug that can be hit on a context restore. To avoid the issue, we must emit a PIPE_CONTROL with CS stall (0x7a04 0x0010 0x 0x) followed by 12DW's of NOOP(0x0) in the indirect context batch buffer, to ensure the engine is idle prior to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3)

== Series Details == Series: drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3) URL : https://patchwork.freedesktop.org/series/37148/ State : success == Summary == Series 37148v3 drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern

[Intel-gfx] [PATCH v8 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

GuC WOPCM registers are write-once registers. Current driver code accesses these registers without checking the accessibility to these registers, this will lead unpredictable driver behaviors if these registers were touch by other components (such as faulty BIOS code). This patch moves the GuC

[Intel-gfx] [PATCH v8 6/6] HAX Enable GuC Submission for CI

Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_guc_wopcm.c | 6 ++ 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c

[Intel-gfx] [PATCH v8 3/6] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

Hardware may have specific restrictions on GuC WOPCM offset and size. On Gen9, the value of the GuC WOPCM size register needs to be larger than the value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size will

[Intel-gfx] [PATCH v8 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files

intel_guc_reg.h should only include definition for GuC registers and related register bits. Non-register related GuC WOPCM macro definitions should not be defined in intel_guc_reg.h This patch creates a better file structure by moving non-register related GuC WOPCM macro definitions into a new

[Intel-gfx] [PATCH v8 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

GuC related exported functions should start with "intel_guc_" prefix and pass intel_guc as the first parameter since its guc related. Current guc_ggtt_offset() failed to follow this code convention and this is a problem for future patches that needs to access intel_guc data to verify the GGTT

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3)

== Series Details == Series: drm/i915/cnl: WaPipeControlBefore3DStateSamplePattern (rev3) URL : https://patchwork.freedesktop.org/series/37148/ State : warning == Summary == Test kms_atomic_transition: Subgroup plane-use-after-nonblocking-unbind-fencing: pass ->

[Intel-gfx] [PATCH v5] drm/i915: Retry HDCP bksv read

HDCP specification says that when bksv is identified as invalid (not with 20 1s), bksv should be re-read and verified. This patch adds the above mentioned re-read for bksv. v2: Rephrased the commit msg [Seanpaul] v3: do-while to for-loop [Seanpaul] v4: retry only if bksv is invalid and

[Intel-gfx] ✓ Fi.CI.BAT: success for Adhering to HDCP1.4 Compliance Test Spec (rev5)

== Series Details == Series: Adhering to HDCP1.4 Compliance Test Spec (rev5) URL : https://patchwork.freedesktop.org/series/37539/ State : success == Summary == Series 37539v5 Adhering to HDCP1.4 Compliance Test Spec https://patchwork.freedesktop.org/api/1.0/series/37539/revisions/5/mbox/

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

On Fri, 2018-02-02 at 12:44 +0200, Jani Nikula wrote: > +Knut, Fengguang > > On Fri, 02 Feb 2018, Greg KH wrote: > > - If clang now builds the kernel "cleanly", yes, I want to take > > warning fixes in the stable tree. And even better yet, if you > >

  1   2   >