[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: move dpll_info inside intel_shared_dpll (rev2)

== Series Details == Series: drm/i915: move dpll_info inside intel_shared_dpll (rev2) URL : https://patchwork.freedesktop.org/series/40251/ State : success == Summary == Known issues: Test kms_flip: Subgroup flip-vs-panning-vs-hang: pass -> DMESG-WARN

[Intel-gfx] ✗ Fi.CI.IGT: warning for meson: Chamelium depends on GSL

== Series Details == Series: meson: Chamelium depends on GSL URL : https://patchwork.freedesktop.org/series/40328/ State : warning == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-128x128-suspend: pass -> SKIP (shard-snb)

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection (rev2)

== Series Details == Series: drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection (rev2) URL : https://patchwork.freedesktop.org/series/40315/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-flip-vs-expired-vblank: pass ->

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/6] Revert "drm/atomic-helper: Fix leak in disable_all"

== Series Details == Series: series starting with [1/6] Revert "drm/atomic-helper: Fix leak in disable_all" URL : https://patchwork.freedesktop.org/series/40321/ State : success == Summary == Known issues: Test kms_cursor_crc: Subgroup cursor-256x256-suspend:

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

On Tue, Mar 20, 2018 at 12:18:48AM +, Chris Wilson wrote: > Catch up with the inflight CSB events, after disabling the tasklet > before deciding which request was truly guilty of hanging the GPU. > > Signed-off-by: Chris Wilson > Cc: Michał Winiarski

[Intel-gfx] [PATCH 2/2] HAX enable guc for CI

Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 ---

[Intel-gfx] [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values

In current code, we only compare the locked WOPCM register values with the calculated values. However, we can continue loading GuC/HuC firmware if the locked (or partially locked) values were valid for current GuC/HuC firmware sizes. This patch added a new code path to verify whether the locked

[Intel-gfx] [PATCH 3/5] drm/i915: Enable edp psr error interrupts on bdw+

From: Daniel Vetter Plug in the bdw+ irq handling for PSR interrupts. bdw+ supports psr on any transcoder in theory, though the we don't currenty enable PSR except on the EDP transcoder. v2: From DK * Rebased on drm-tip Cc: Rodrigo Vivi

[Intel-gfx] [PATCH 2/5] drm/i915: Drop reg_write from the PSR mask

From: Ville Syrjälä v2: from DK * Rebased on drm-tip * Explananation in commit message. REG_WRITE is necessary for HW to exit PSR when plane/pipe registers are written to. Cc: Rodrigo Vivi Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 1/5] drm/i915: Enable edp psr error interrupts on hsw

From: Daniel Vetter The definitions for the error register should be valid on bdw/skl too, but there we haven't even enabled DE_MISC handling yet. Somewhat confusing the the moved register offset on bdw is only for the _CTL/_AUX register, and that _IIR/IMR stayed where

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

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 Cc: Rodrigo Vivi Cc: Ville Syrjälä Cc:

[Intel-gfx] [PATCH 5/5] drm/i915/psr: Timestamps for PSR entry and exit interrupts.

Timestamps are useful for IGT tests that trigger PSR exit and/or wait for PSR entry. Cc: Ville Syrjälä Cc: Rodrigo Vivi Cc: Daniel Vetter Signed-off-by: Dhinakaran Pandiyan ---

[Intel-gfx] [PATCH 0/5] PSR interrupts

I have revived the PSR interrupt patches that Daniel and Ville had worked on [1], added debugfs control for the interrupts and exposed interrupt timestamps via debugfs. The idea is to provide a mechanism for CI tests to know whether a PSR exit event succeeded and if PSR re-enters when it is

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: move dpll_info inside intel_shared_dpll (rev2)

== Series Details == Series: drm/i915: move dpll_info inside intel_shared_dpll (rev2) URL : https://patchwork.freedesktop.org/series/40251/ State : success == Summary == Series 40251v2 drm/i915: move dpll_info inside intel_shared_dpll

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: move dpll_info inside intel_shared_dpll (rev2)

== Series Details == Series: drm/i915: move dpll_info inside intel_shared_dpll (rev2) URL : https://patchwork.freedesktop.org/series/40251/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9ddcc8463efd drm/i915: move dpll_info to header ccdf20dad80f drm/i915: add dpll_info inside

[Intel-gfx] [PATCH v2 1/7] drm/i915: move dpll_info to header

This will allow the struct to be embedded in intel_shared_dpll. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/intel_dpll_mgr.c | 7 --- drivers/gpu/drm/i915/intel_dpll_mgr.h | 10 ++ 2 files changed, 10 insertions(+), 7 deletions(-) diff --git

[Intel-gfx] [PATCH v2 5/7] drm/i915: use id from intel_shared_dpll.info

Replace all users of pll->id to use pll->info->id. In functions using this more than once it was preferred to add an id variable to make the code easier to read. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +-

[Intel-gfx] [PATCH v2 3/7] drm/i915: use funcs from intel_shared_dpll.info

Replace all users of pll->funcs.* to use pll->info->funcs->*. The extra indirection here is not on any critical path and we can leave all const data together. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/intel_display.c | 16

[Intel-gfx] [PATCH v2 7/7] drm/i915: reorder dpll_info members

Remove 4-bytes hole in this struct an reorder tables accordingly. This also changes the last element of the tables to be more future-proof. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/intel_dpll_mgr.c | 48 +--

[Intel-gfx] [PATCH v2 4/7] drm/i915: use name from intel_shared_dpll.info

Replace all users of pll->name to use pll->info->name. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/i915_debugfs.c | 3 ++- drivers/gpu/drm/i915/intel_display.c | 7 --- drivers/gpu/drm/i915/intel_dpll_mgr.c | 26 ++

[Intel-gfx] [PATCH v2 6/7] drm/i915: use flags from dpll_info embedded in intel_shared_dpll

Replace all users of pll->flags to use pll->info.flags. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 -- drivers/gpu/drm/i915/intel_dpll_mgr.h | 18 -- 3 files changed, 9

[Intel-gfx] [PATCH v2 2/7] drm/i915: add dpll_info inside intel_shared_dpll

This way we can stop copying fields from dpll_info to intel_shared_dpll one by one. The migration of each field will come on separate patches. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 + drivers/gpu/drm/i915/intel_dpll_mgr.h | 5

[Intel-gfx] [PATCH v2 0/7] drm/i915: move dpll_info inside intel_shared_dpll

v2: - Make dpll_info a pointer inside intel_shared_dpll - Add a patch to reorder dpll_info members Lucas De Marchi (7): drm/i915: move dpll_info to header drm/i915: add dpll_info inside intel_shared_dpll drm/i915: use funcs from intel_shared_dpll.info drm/i915: use name from

Re: [Intel-gfx] [PATCH 1/7] drm/i915: move dpll_info to header

On Tue, Mar 20, 2018 at 2:56 AM, Ville Syrjälä wrote: > On Mon, Mar 19, 2018 at 11:24:17PM -0700, Lucas De Marchi wrote: >> This will allow the struct to be embedded in intel_shared_dpll. >> >> Signed-off-by: Lucas De Marchi >> --- >>

[Intel-gfx] ✓ Fi.CI.BAT: success for meson: Chamelium depends on GSL

== Series Details == Series: meson: Chamelium depends on GSL URL : https://patchwork.freedesktop.org/series/40328/ State : success == Summary == IGT patchset tested on top of latest successful build 94e886203a99ef19b8319489a45cd348e76e8ccd igt: Replace 'all-engines' magic numbers with macro

[Intel-gfx] [PATCH i-g-t] meson: Chamelium depends on GSL

Chamelium support requires igt_frame to be built, which requires both GSL and Pixman. Signed-off-by: Daniel Stone --- meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meson.build b/meson.build index ef7017cb..5b783e5d 100644 ---

Re: [Intel-gfx] [PATCH] RFC: debugobjects: capture stack traces at _init() time

On Tue, 20 Mar 2018, Daniel Vetter wrote: > Sometimes it's really easy to know which object has gone boom and > where the offending code is, and sometimes it's really hard. One case > we're trying to hunt down is when module unload catches a live debug > object, with a module with lots of them. >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection (rev2)

== Series Details == Series: drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection (rev2) URL : https://patchwork.freedesktop.org/series/40315/ State : success == Summary == Series 40315v2 drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Unify parameters of public CT functions (rev2)

== Series Details == Series: drm/i915/guc: Unify parameters of public CT functions (rev2) URL : https://patchwork.freedesktop.org/series/40197/ State : success == Summary == Known issues: Test kms_setmode: Subgroup basic: pass -> FAIL (shard-apl)

[Intel-gfx] [PATCH v4] drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection

From: Kelvin Gardiner This patch adds support to detect ICL, slice, subslice and EU fuse settings. Add addresses for ICL 11 slice, subslice and EU fuses registers. These register addresses are the same as previous platforms but the format and / or the meaning of the

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] Revert "drm/atomic-helper: Fix leak in disable_all"

== Series Details == Series: series starting with [1/6] Revert "drm/atomic-helper: Fix leak in disable_all" URL : https://patchwork.freedesktop.org/series/40321/ State : success == Summary == Series 40321v1 series starting with [1/6] Revert "drm/atomic-helper: Fix leak in disable_all"

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection

== Series Details == Series: drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection URL : https://patchwork.freedesktop.org/series/40315/ State : success == Summary == Series 40315v1 drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection

[Intel-gfx] ✓ Fi.CI.IGT: success for RFC: debugobjects: capture stack traces at _init() time

== Series Details == Series: RFC: debugobjects: capture stack traces at _init() time URL : https://patchwork.freedesktop.org/series/40294/ State : success == Summary == Known issues: Test gem_exec_suspend: Subgroup basic-s3: pass -> SKIP (shard-snb)

[Intel-gfx] [PATCH 2/6] drm/atomic-helper: Make drm_atomic_helper_disable_all() update the plane->fb pointers

From: Ville Syrjälä drm_atomic_helper_shutdown() needs to release the reference held by plane->fb, so we want to use drm_atomic_clean_old_fb() in drm_atomic_helper_disable_all(). However during suspend/resume, gpu reset and load detection we should probably leave

[Intel-gfx] [PATCH 4/6] drm/atomic-helper: WARN if legacy plane fb pointers are bogus when committing duplicated state

From: Ville Syrjälä drm_atomic_helper_commit_duplicated_state() should only be called resume/reset/load_detect paths where plane->old_fb should always be NULL and plane->fb should be equal to the new_plane_state->fb. Assert that is indeed the case. Cc:

[Intel-gfx] [PATCH 5/6] drm/i915: Restore planes after load detection

From: Ville Syrjälä Actually turn the planes back on after were done with the load detection. Fixes: 20bdc112bbe4 ("drm/i915: Disable all planes for load detection, v2.") Cc: Maarten Lankhorst Cc: Daniel Vetter

[Intel-gfx] [PATCH 3/6] drm: Clear crtc->primary->crtc when disabling the crtc via setcrtc()

From: Ville Syrjälä Keep the primary->crtc in sync with the state->crtc (also with primary->fb and state->fb) when disabling the crtc (and thus also the primary) via setcrtc(). Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 6/6] drm/i915: Make force_load_detect effective even w/ DMI quirks/hotplug

From: Ville Syrjälä When doing forced load detection testing we should totally ignore any hotplug status for the connector. This is mostly relevant for machines where we already ignore the hotplug status based on the DMI quirks. On other machines we would currently

[Intel-gfx] [PATCH 1/6] Revert "drm/atomic-helper: Fix leak in disable_all"

From: Ville Syrjälä Currently we're leaking fbs on load detect on account of nothing setting up plane->old_fb for the drm_atomic_clean_old_fb() call in drm_atomic_helper_commit_duplicated_state(). Removing the drm_atomic_clean_old_fb() call seems like the right

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection

== Series Details == Series: drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection URL : https://patchwork.freedesktop.org/series/40315/ State : warning == Summary == $ dim checkpatch origin/drm-tip f61c5df8f12d drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection -:32:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915/guc: Unify naming of private GuC action functions

== Series Details == Series: series starting with [CI,1/3] drm/i915/guc: Unify naming of private GuC action functions URL : https://patchwork.freedesktop.org/series/40311/ State : success == Summary == Series 40311v1 series starting with [CI,1/3] drm/i915/guc: Unify naming of private GuC

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Handle GuC log flush event in dedicated function

On Mon, Mar 19, 2018 at 12:50:49PM +, Michal Wajdeczko wrote: > We already try to keep all GuC log related code in separate file, > handling flush event should be placed there too. This will also > allow future code reuse. > > v2: rebased > > Signed-off-by: Michal Wajdeczko

Re: [Intel-gfx] [PATCH v3] drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection

On 20/03/18 18:37, Oscar Mateo wrote: From: Kelvin Gardiner This patch adds support to detect ICL, slice, subslice and EU fuse settings. Add addresses for ICL 11 slice, subslice and EU fuses registers. These register addresses are the same as previous platforms but

Re: [Intel-gfx] [RFC v1] drm/i915: Add Exec param to control data port coherency.

On 3/19/2018 7:14 AM, Lis, Tomasz wrote: On 2018-03-19 13:43, Chris Wilson wrote: Quoting Tomasz Lis (2018-03-19 12:37:35) The patch adds a parameter to control the data port coherency functionality on a per-exec call basis. When data port coherency flag value is different than what it

[Intel-gfx] [PATCH v3] drm/i915/icl: Added ICL 11 slice, subslice and EU fuse detection

From: Kelvin Gardiner This patch adds support to detect ICL, slice, subslice and EU fuse settings. Add addresses for ICL 11 slice, subslice and EU fuses registers. These register addresses are the same as previous platforms but the format and / or the meaning of the

[Intel-gfx] [CI 3/3] drm/i915/guc: Move enable/disable msg functions to GuC header

While today we are modifying GuC enabled msg mask only in GuC log, this code should be defined as generic GuC to allow future code reuse. Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski Cc: Sagar Arun Kamble

[Intel-gfx] [CI 2/3] drm/i915/guc: Drop union guc_log_control

Usually we use shift/mask macros for bit field definitions. Union guc_log_control was not following that pattern. Additional bonus: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-25 (-25) Function old new delta intel_guc_log_level_set

[Intel-gfx] [CI 1/3] drm/i915/guc: Unify naming of private GuC action functions

We should avoid using guc_log prefix for functions that don't operate on GuC log, but rather request action from the GuC. Better to use guc_action prefix. v2: rebase + naming compromise v3: rebase Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Warn if rps max frequency is not set

Quoting Mika Kuoppala (2018-03-20 16:28:20) > Mika Kuoppala writes: > > > Warn on enabling rps when our hw max is invalid. > > > > Cc: Chris Wilson > > Signed-off-by: Mika Kuoppala > > --- > >

Re: [Intel-gfx] [RFC v1] drm/i915: Add Exec param to control data port coherency.

On 2018-03-19 15:26, Chris Wilson wrote: Quoting Lis, Tomasz (2018-03-19 14:14:19) On 2018-03-19 13:43, Chris Wilson wrote: Quoting Tomasz Lis (2018-03-19 12:37:35) The patch adds a parameter to control the data port coherency functionality on a per-exec call basis. When data port

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Unify parameters of public CT functions (rev2)

== Series Details == Series: drm/i915/guc: Unify parameters of public CT functions (rev2) URL : https://patchwork.freedesktop.org/series/40197/ State : success == Summary == Series 40197v2 drm/i915/guc: Unify parameters of public CT functions

[Intel-gfx] ✓ Fi.CI.BAT: success for RFC: debugobjects: capture stack traces at _init() time

== Series Details == Series: RFC: debugobjects: capture stack traces at _init() time URL : https://patchwork.freedesktop.org/series/40294/ State : success == Summary == Series 40294v1 RFC: debugobjects: capture stack traces at _init() time

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Warn if rps max frequency is not set

Mika Kuoppala writes: > Warn on enabling rps when our hw max is invalid. > > Cc: Chris Wilson > Signed-off-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_pm.c | 2 ++ > 1 file changed, 2

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

There is no need to mix parameter types in public CT functions as we can always accept intel_guc_ct. v2: fix 'Return' doc, s/dev_priv/i915 (Sagar) Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFC: debugobjects: capture stack traces at _init() time

== Series Details == Series: RFC: debugobjects: capture stack traces at _init() time URL : https://patchwork.freedesktop.org/series/40294/ State : warning == Summary == $ dim checkpatch origin/drm-tip bf60db68fbc5 RFC: debugobjects: capture stack traces at _init() time -:124: CHECK:SPACING:

Re: [Intel-gfx] [PATCH] drm/i915/guc: enable guc interrupts unconditionally in uc_resume

On Mon, Mar 19, 2018 at 05:56:54PM -0700, Michel Thierry wrote: > Probably lost while rebasing commit eacd8391f977 ("drm/i915/guc: Keep GuC > interrupts enabled when using GuC"). > > Not really needed since i915_gem_init_hw is called before uc_resume, but > it brings symmetry to uc_suspend. > >

[Intel-gfx] [PATCH] RFC: debugobjects: capture stack traces at _init() time

Sometimes it's really easy to know which object has gone boom and where the offending code is, and sometimes it's really hard. One case we're trying to hunt down is when module unload catches a live debug object, with a module with lots of them. Capture a full stack trace from debug_object_init()

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Avoid setting ring freq on invalid rps freqs

== Series Details == Series: series starting with [1/2] drm/i915: Avoid setting ring freq on invalid rps freqs URL : https://patchwork.freedesktop.org/series/40289/ State : warning == Summary == Series 40289v1 series starting with [1/2] drm/i915: Avoid setting ring freq on invalid rps freqs

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev3)

On Tue, Feb 27, 2018 at 12:08:25PM +0200, Ville Syrjälä wrote: > On Wed, Feb 07, 2018 at 10:57:59AM -, Patchwork wrote: > > == Series Details == > > > > Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev3) > > URL : https://patchwork.freedesktop.org/series/36068/ > > State : warning >

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/pm: Warn if rpm frequencies are not set

== Series Details == Series: drm/i915/pm: Warn if rpm frequencies are not set URL : https://patchwork.freedesktop.org/series/40281/ State : warning == Summary == Possible new issues: Test kms_mmio_vs_cs_flip: Subgroup setcrtc_vs_cs_flip: pass -> SKIP

[Intel-gfx] [PATCH 2/2] drm/i915: Warn if rps max frequency is not set

Warn on enabling rps when our hw max is invalid. Cc: Chris Wilson Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_pm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c

[Intel-gfx] [PATCH 1/2] drm/i915: Avoid setting ring freq on invalid rps freqs

Looping through rps frequencies when both min and max are zero ends up into an endless loop. This can happen during hardware enablement. Bail out early if rps frequencies are not correctly set yet. Cc: Chris Wilson Signed-off-by: Mika Kuoppala

Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.

This functionality is used by new OCL drvier (aka. NEO): https://github.com/intel/compute-runtime Starting from commit: 933312e0986d3a7c1ef557e511eb4ced301ea292 -Original Message- From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] Sent: Monday, March 19, 2018 2:54 PM To:

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

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 to mix parameter types in public CT functions as we can always accept intel_guc_ct.

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add control flags to i915_handle_error()

Quoting Michel Thierry (2018-03-20 14:11:03) > On 3/20/2018 3:04 AM, Chris Wilson wrote: > > Not all callers want the GPU error to handled in the same way, so expose > > a control parameter. In the first instance, some callers do not want the > > heavyweight error capture so add a bit to request

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Don't try to enable GuC logging when we're not using GuC (rev3)

Quoting Patchwork (2018-03-20 14:52:05) > == Series Details == > > Series: drm/i915/guc: Don't try to enable GuC logging when we're not using > GuC (rev3) > URL : https://patchwork.freedesktop.org/series/40239/ > State : success > > == Summary == > No more editing, pushed! Thanks, -Chris

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Don't try to enable GuC logging when we're not using GuC (rev3)

== Series Details == Series: drm/i915/guc: Don't try to enable GuC logging when we're not using GuC (rev3) URL : https://patchwork.freedesktop.org/series/40239/ State : success == Summary == Known issues: Test kms_flip: Subgroup flip-vs-expired-vblank-interruptible:

Re: [Intel-gfx] [PATCH] drm/i915/pm: Warn if rpm frequencies are not set

Chris Wilson writes: > Quoting Mika Kuoppala (2018-03-20 13:58:42) >> We do end up setting ring frequencies on a hardware >> which is not yet there wrt runtime pm enablement. >> >> Instead of ending up in an endless loop iterating through >> frequencies if min and max

Re: [Intel-gfx] [PATCH 3/8] drm/i915/icl: Update subslice define for ICL 11

Mika Kuoppala writes: > From: Kelvin Gardiner > > ICL 11 has a greater number of maximum subslices. This patch > reflects this. > > v2: GEN11 updates to MCR_SELECTOR (Oscar) > v3: Copypasta error in the new defines (Lionel) > > Bspec:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pm: Warn if rpm frequencies are not set

== Series Details == Series: drm/i915/pm: Warn if rpm frequencies are not set URL : https://patchwork.freedesktop.org/series/40281/ State : success == Summary == Series 40281v1 drm/i915/pm: Warn if rpm frequencies are not set

Re: [Intel-gfx] [PATCH] drm/i915/pm: Warn if rpm frequencies are not set

Quoting Mika Kuoppala (2018-03-20 13:58:42) > We do end up setting ring frequencies on a hardware > which is not yet there wrt runtime pm enablement. > > Instead of ending up in an endless loop iterating through > frequencies if min and max frequencies are still set to zero, > warn and bail out

Re: [Intel-gfx] [PATCH] drm/i915: Select STACKDEPOT for DRM_I915_DEBUG

On Tue, Mar 20, 2018 at 01:19:01PM +, Chris Wilson wrote: > Quoting Daniel Vetter (2018-03-20 12:50:09) > > select in Kconfig isn't recursive, we need to select the stuff our > > selects select, too. Fix that. > > Really? That's quite painful. > > That will limit the usefulness but

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add control flags to i915_handle_error()

On 3/20/2018 3:04 AM, Chris Wilson wrote: Not all callers want the GPU error to handled in the same way, so expose a control parameter. In the first instance, some callers do not want the heavyweight error capture so add a bit to request the state to be captured and saved. v2: Pass msg down to

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Specify which engines to reset following semaphore/event lockups

On 3/20/2018 3:04 AM, Chris Wilson wrote: If the GPU is stuck waiting for an event or for a semaphore, we need to reset the GPU in order to recover. We have to tell the reset routine which engines we want reset, but we were still using the old interface and declaring it as "not-fatal". Fixes:

[Intel-gfx] [PATCH] drm/i915/pm: Warn if rpm frequencies are not set

We do end up setting ring frequencies on a hardware which is not yet there wrt runtime pm enablement. Instead of ending up in an endless loop iterating through frequencies if min and max frequencies are still set to zero, warn and bail out early. Cc: Chris Wilson

[Intel-gfx] [PATCH i-g-t v9] tests/perf_pmu: Improve accuracy by waiting on spinner to start

From: Tvrtko Ursulin More than one test assumes that the spinner is running pretty much immediately after we have create or submitted it. In actuality there is a variable delay, especially on execlists platforms, between submission and spin batch starting to run on the

Re: [Intel-gfx] [PATCH] drm/i915: Select STACKDEPOT for DRM_I915_DEBUG

Quoting Daniel Vetter (2018-03-20 12:50:09) > select in Kconfig isn't recursive, we need to select the stuff our > selects select, too. Fix that. Really? That's quite painful. That will limit the usefulness but on the other hand avoid the illegal configurations all over. >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Select STACKDEPOT for DRM_I915_DEBUG

== Series Details == Series: drm/i915: Select STACKDEPOT for DRM_I915_DEBUG URL : https://patchwork.freedesktop.org/series/40274/ State : failure == Summary == Series 40274v1 drm/i915: Select STACKDEPOT for DRM_I915_DEBUG

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

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 to mix parameter types in public CT functions as we can always accept intel_guc_ct. Signed-off-by: Michal Wajdeczko

[Intel-gfx] [PATCH] drm/i915: Select STACKDEPOT for DRM_I915_DEBUG

select in Kconfig isn't recursive, we need to select the stuff our selects select, too. Fix that. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/Kconfig.debug

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Don't try to enable GuC logging when we're not using GuC (rev3)

== Series Details == Series: drm/i915/guc: Don't try to enable GuC logging when we're not using GuC (rev3) URL : https://patchwork.freedesktop.org/series/40239/ State : success == Summary == Series 40239v3 drm/i915/guc: Don't try to enable GuC logging when we're not using GuC

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Specify which engines to reset following semaphore/event lockups

== Series Details == Series: series starting with [1/2] drm/i915: Specify which engines to reset following semaphore/event lockups URL : https://patchwork.freedesktop.org/series/40265/ State : failure == Summary == Possible new issues: Test kms_flip_tiling: Subgroup

[Intel-gfx] [PATCH v3] drm/i915/guc: Don't try to enable GuC logging when we're not using GuC

When changing the default values for guc_log_level, we accidentally left the log enabled on non-guc platforms. Let's fix that. v2: Define the levels used and remove (now obsolete) comments (Chris) v3: Use "IS" rather than "TO" for booleans (Chris) Fixes: 9605d1ce7c6b ("drm/i915/guc: Default to

Re: [Intel-gfx] [PATCH igt 0/8] Non-Intel test suite fixes

Hello, On Monday, 19 March 2018 18:41:05 EET Ulrich Hecht wrote: > On Fri, Mar 16, 2018 at 9:55 AM, Daniel Vetter wrote: > > On Thu, Mar 15, 2018 at 03:45:36PM +0100, Ulrich Hecht wrote: > >> Hi! > >> > >> I have run the tests on a Renesas R-Car M3-W's DU device, and have found

Re: [Intel-gfx] [PATCH igt 1/8] tests/kms_addfb_basic: skip i915-specific tests on other platforms

Hi Ulrich, Thank you for the patch. On Thursday, 15 March 2018 16:45:37 EET Ulrich Hecht wrote: > Add is_i915_device() requirement to tests using Intel-specific APIs. > > Signed-off-by: Ulrich Hecht Reviewed-by: Laurent Pinchart

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

Hi Ulrich, Thank you for the patch. On Thursday, 15 March 2018 16:45:38 EET Ulrich Hecht wrote: > Fixes false negatives on non-i915 platforms. > > Signed-off-by: Ulrich Hecht > --- > tests/kms_panel_fitting.c | 1 + > 1 file changed, 1 insertion(+) > > diff

[Intel-gfx] ✓ Fi.CI.IGT: success for input/psmouse: Don't hold the mutex while calling ->disconnect

== Series Details == Series: input/psmouse: Don't hold the mutex while calling ->disconnect URL : https://patchwork.freedesktop.org/series/40259/ State : success == Summary == Known issues: Test gem_softpin: Subgroup noreloc-s3: dmesg-warn -> PASS

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Don't try to enable GuC logging when we're not using GuC

Quoting Michał Winiarski (2018-03-20 08:49:29) > When changing the default values for guc_log_level, we accidentally left > the log enabled on non-guc platforms. Let's fix that. > > v2: Define the levels used and remove (now obsolete) comments (Chris) > > Fixes: 9605d1ce7c6b ("drm/i915/guc:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Don't try to enable GuC logging when we're not using GuC (rev2)

== Series Details == Series: drm/i915/guc: Don't try to enable GuC logging when we're not using GuC (rev2) URL : https://patchwork.freedesktop.org/series/40239/ State : success == Summary == Known issues: Test gem_exec_suspend: Subgroup basic-s3: pass ->

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Specify which engines to reset following semaphore/event lockups

== Series Details == Series: series starting with [1/2] drm/i915: Specify which engines to reset following semaphore/event lockups URL : https://patchwork.freedesktop.org/series/40265/ State : success == Summary == Series 40265v1 series starting with [1/2] drm/i915: Specify which engines to

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Specify which engines to reset following semaphore/event lockups

== Series Details == Series: series starting with [1/2] drm/i915: Specify which engines to reset following semaphore/event lockups URL : https://patchwork.freedesktop.org/series/40265/ State : warning == Summary == $ dim checkpatch origin/drm-tip 02b19c71acb4 drm/i915: Specify which engines

[Intel-gfx] [PATCH 1/2] drm/i915: Specify which engines to reset following semaphore/event lockups

If the GPU is stuck waiting for an event or for a semaphore, we need to reset the GPU in order to recover. We have to tell the reset routine which engines we want reset, but we were still using the old interface and declaring it as "not-fatal". Fixes: 14b730fcb8d9 ("drm/i915/tdr: Prepare error

[Intel-gfx] [PATCH 2/2] drm/i915: Add control flags to i915_handle_error()

Not all callers want the GPU error to handled in the same way, so expose a control parameter. In the first instance, some callers do not want the heavyweight error capture so add a bit to request the state to be captured and saved. v2: Pass msg down to i915_reset/i915_reset_engine so that we

Re: [Intel-gfx] [PATCH 0/7] drm/i915: move dpll_info inside intel_shared_dpll

On Mon, Mar 19, 2018 at 11:24:16PM -0700, Lucas De Marchi wrote: > > This is an alternative to my previous patch > "drm/i915: Remove hole and padding from intel_shared_dpll". > > Not sure if I split this too much, but I think it's easier to review > this way. We can always squash them if wanted.

Re: [Intel-gfx] [PATCH 1/7] drm/i915: move dpll_info to header

On Mon, Mar 19, 2018 at 11:24:17PM -0700, Lucas De Marchi wrote: > This will allow the struct to be embedded in intel_shared_dpll. > > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 7 --- > drivers/gpu/drm/i915/intel_dpll_mgr.h |

[Intel-gfx] ✓ Fi.CI.BAT: success for input/psmouse: Don't hold the mutex while calling ->disconnect

== Series Details == Series: input/psmouse: Don't hold the mutex while calling ->disconnect URL : https://patchwork.freedesktop.org/series/40259/ State : success == Summary == Series 40259v1 input/psmouse: Don't hold the mutex while calling ->disconnect

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for input/psmouse: Don't hold the mutex while calling ->disconnect

== Series Details == Series: input/psmouse: Don't hold the mutex while calling ->disconnect URL : https://patchwork.freedesktop.org/series/40259/ State : warning == Summary == $ dim checkpatch origin/drm-tip cc6c0846e22c input/psmouse: Don't hold the mutex while calling ->disconnect -:18:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Don't try to enable GuC logging when we're not using GuC (rev2)

== Series Details == Series: drm/i915/guc: Don't try to enable GuC logging when we're not using GuC (rev2) URL : https://patchwork.freedesktop.org/series/40239/ State : success == Summary == Series 40239v2 drm/i915/guc: Don't try to enable GuC logging when we're not using GuC

[Intel-gfx] ✓ Fi.CI.IGT: success for semaphore: might_lock(->pi_lock) in up()

== Series Details == Series: semaphore: might_lock(->pi_lock) in up() URL : https://patchwork.freedesktop.org/series/40256/ State : success == Summary == Known issues: Test kms_cursor_legacy: Subgroup 2x-long-flip-vs-cursor-legacy: incomplete -> PASS

[Intel-gfx] [drm-intel:drm-intel-next-queued 13/14] drivers/gpu/drm/i915/intel_guc.c:230:12-17: WARNING: Unsigned expression compared with zero: level < 0 (fwd)

Level is unsigned, so not less than 0 (line 230). julia -- Forwarded message -- Date: Tue, 20 Mar 2018 16:39:16 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: [drm-intel:drm-intel-next-queued 13/14]

  1   2   >