[Intel-gfx] [PATCH v4 1/2] drm: Use srcu to protect drm_device.unplugged

From: Noralf Trønnes Use srcu to protect drm_device.unplugged in a race free manner. Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark sections preventing access to device resources that are not available after the device is gone. Suggested-by: Daniel Vetter Signed-off-by: Nora

[Intel-gfx] [PATCH 5/9] Revert "cpufreq: intel_pstate: Drop ->update_util from pstate_funcs"

This reverts commit c4f3f70cacba2fa19545389a12d09b606d2ad1cf. A future commit will introduce a new update_util implementation, so the pstate_funcs table entry is going to be useful. Signed-off-by: Francisco Jerez --- drivers/cpufreq/intel_pstate.c | 15 +-- 1 file changed, 13 insert

[Intel-gfx] [PATCH 7/9] SQUASH: cpufreq/intel_pstate: Enable LP controller based on ACPI FADT profile.

This is provided at Srinivas' request. The LP controller is disabled for the moment on server FADT profiles in order to avoid disturbing the performance behavior of small-core servers. In cases where the default inferred from the BIOS FADT profile is suboptimal, the LP controller can be forcefull

[Intel-gfx] [PATCH 1/9] cpufreq: Implement infrastructure keeping track of aggregated IO active time.

This provides an IO activity statistic to cpufreq governors complementary to the IO wait time currently available to them. An IO utilization estimated from this statistic which is significantly lower than 100% can be interpreted as an indication that no IO devices are utilized to their full throug

[Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

This series attempts to solve an energy efficiency problem of the current active-mode non-HWP governor of the intel_pstate driver used for the most part on low-power platforms. Under heavy IO load the current controller tends to increase frequencies to the maximum turbo P-state, partly due to IO w

[Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq.

This allows cpufreq governors to realize when the system becomes non-CPU-bound due to GPU rendering activity, which will cause the intel_pstate LP controller to behave more conservatively: CPU energy usage will be reduced when there isn't a good chance for system performance to scale with CPU frequ

[Intel-gfx] [PATCH 3/9] Revert "cpufreq: intel_pstate: Shorten a couple of long names"

This reverts one half of commit d77d4888cb8458b098accd4d7555c0f7f6399c4e. It moves back to the old name of get_target_pstate_use_cpu_load(), because a future commit will introduce a new P-state target calculation function. The shortened name of INTEL_PSTATE_SAMPLING_INTERVAL is left untouched. S

[Intel-gfx] [PATCH 6/9] cpufreq/intel_pstate: Implement variably low-pass filtering controller for small core.

This introduces a controller for low-power parts that takes advantage of the IO active time statistic introduced earlier in order to adjust the trade-off between responsiveness and energy efficiency of the heuristic dynamically. This allows it to achieve lower energy consumption when the system is

[Intel-gfx] [PATCH 2/9] Revert "cpufreq: intel_pstate: Replace bxt_funcs with core_funcs"

This reverts commit dbd49b85eec7eb6d7ae61bad8306d5cdd85c142d. A future commit will introduce a new update_util implementation for LP platforms, so the bxt_funcs table comes in handy. Signed-off-by: Francisco Jerez --- drivers/cpufreq/intel_pstate.c | 13 +++-- 1 file changed, 11 inserti

[Intel-gfx] [PATCH 8/9] OPTIONAL: cpufreq/intel_pstate: Expose LP controller parameters via debugfs.

This is not required for the controller to work but has proven very useful for debugging and testing of alternative heuristic parameters, which may offer a better trade-off between energy efficiency and latency -- The default parameters are rather aggressively latency-minimizing in order to keep up

[Intel-gfx] [PATCH 4/9] Revert "cpufreq: intel_pstate: Simplify intel_pstate_adjust_pstate()"

This reverts commit a891283e56362543d1d276e192266069ef52075b. The previous approach of taking an explicit P-state target as argument makes it more easily reusable by a future commit. Signed-off-by: Francisco Jerez --- drivers/cpufreq/intel_pstate.c | 12 +++- 1 file changed, 7 insertion

Re: [Intel-gfx] [PATCH 3/3] drm: make drm_core_check_feature() bool that it is

On Tue, 27 Mar 2018, Chris Wilson wrote: > Quoting Jani Nikula (2018-03-27 21:47:22) >> Bool is the more appropriate return type here, use it. >> >> Signed-off-by: Jani Nikula > > All 3, > Reviewed-by: Chris Wilson Thanks, all pushed to drm-misc-next. BR, Jani. -- Jani Nikula, Intel Open S

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm: prefer inline over __inline__

== Series Details == Series: series starting with [1/3] drm: prefer inline over __inline__ URL : https://patchwork.freedesktop.org/series/40760/ State : success == Summary == Known issues: Test kms_cursor_crc: Subgroup cursor-128x128-suspend: dmesg-warn -> PASS

Re: [Intel-gfx] [PATCH 1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper

On Tue, 27 Mar 2018, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > As more differentation occurs between DP spec. Its useful to have these > as macros in a drm_dp_helper. > > Signed-off-by: Matt Atwood > --- > drivers/gpu/drm/amd/display/include/dpcd_defs.h | 8 > include/dr

[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 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@lists.freedesktop.org; Nagaraju, V

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 preemp

[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 registers

[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 registe

[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 WaP

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). >

[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 https://patchwork.freedeskt

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.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: Corr

[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 https://patchwork.freedesktop.org/api/1.0/series/2839

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 > >> regi

[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 --- drivers/gpu/drm/i915/intel_lrc.c | 31 +

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 that

[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: drm/i915/

[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 reb

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 communicati

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 slice/s

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 not

[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 r

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 valu

[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 subse

[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 inst

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Reset ring registers on rebinding contexts

== Series Details == Series: drm/i915/execlists: Reset ring registers on rebinding contexts URL : https://patchwork.freedesktop.org/series/40763/ State : success == Summary == Series 40763v1 drm/i915/execlists: Reset ring registers on rebinding contexts https://patchwork.freedesktop.org/api/1.

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

From: Matt Atwood DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended receiver capabilities. For panels that use this new feature wait interval would be increased by 512 ms, when spec is max 16 ms. This behavio

[Intel-gfx] [PATCH 1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper

From: Matt Atwood As more differentation occurs between DP spec. Its useful to have these as macros in a drm_dp_helper. Signed-off-by: Matt Atwood --- drivers/gpu/drm/amd/display/include/dpcd_defs.h | 8 include/drm/drm_dp_helper.h | 5 + 2 files changed, 5 ins

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

== Series Details == Series: drm/i915/execlists: Reset ring registers on rebinding contexts URL : https://patchwork.freedesktop.org/series/40763/ State : warning == Summary == $ dim checkpatch origin/drm-tip ad09e66d7bde drm/i915/execlists: Reset ring registers on rebinding contexts -:36: CHEC

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: prefer inline over __inline__

== Series Details == Series: series starting with [1/3] drm: prefer inline over __inline__ URL : https://patchwork.freedesktop.org/series/40760/ State : success == Summary == Series 40760v1 series starting with [1/3] drm: prefer inline over __inline__ https://patchwork.freedesktop.org/api/1.0/

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

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 communication, so some code reuse is still possible. v2:

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

On Fri, Mar 23, 2018 at 07:34:34PM -0700, Pandiyan, Dhinakaran wrote: > > On Fri, 2018-03-23 at 23:51 +, Souza, Jose wrote: > > On Fri, 2018-03-23 at 15:59 -0700, Pandiyan, Dhinakaran wrote: > > > > > > > > > On Thu, 2018-03-22 at 14:48 -0700, José Roberto de Souza wrote: > > > > Move to onl

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

On 27/03/18 14:05, Michal Wajdeczko wrote: On Tue, 27 Mar 2018 22:03:23 +0200, Michel Thierry wrote: On 3/27/2018 11:25 AM, Daniele Ceraolo Spurio wrote:   On 26/03/18 12:48, Michal Wajdeczko wrote: When running on platform with CTB based GuC communication enabled, GuC to Host event data

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

On Tue, 2018-03-27 at 11:26 +0100, Chris Wilson wrote: > 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 > > ech

[Intel-gfx] ✓ Fi.CI.BAT: success 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 : success == Summary == Series 40759v1 series starting with [v5,1/8] drm/i915: Correctly handle error path in i915_

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

On Tue, 27 Mar 2018 22:03:23 +0200, Michel Thierry wrote: On 3/27/2018 11:25 AM, Daniele Ceraolo Spurio wrote: On 26/03/18 12:48, 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. Howe

[Intel-gfx] [PATCH 3/3] drm/i915: Include the HW breadcrumb whenever we trace the global_seqno

When we include a request's global_seqno in a GEM_TRACE it often helps to know how that relates to the current breadcrumb as seen by the hardware. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 28 +--- drivers/gpu/drm/i915/intel_lrc.c| 6 -

[Intel-gfx] [PATCH] drm/i915/execlists: Reset ring registers on rebinding contexts

Tvrtko uncovered a fun issue with recovering from a wedge device. In his tests, he wedged the driver by injecting an unrecoverable hang whilst a batch was spinning. As we reset the gpu in the middle of the spinner, when resumed it would continue on from the next instruction in the ring and write it

[Intel-gfx] [PATCH 2/3] 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. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 27 --- 1 file changed, 8 i

[Intel-gfx] [PATCH 1/3] drm/i915/execlists: Reset ring registers on rebinding contexts

Tvrtko uncovered a fun issue with recovering from a wedge device. In his tests, he wedged the driver by injecting an unrecoverable hang whilst a batch was spinning. As we reset the gpu in the middle of the spinner, when resumed it would continue on from the next instruction in the ring and write it

Re: [Intel-gfx] [PATCH 3/3] drm: make drm_core_check_feature() bool that it is

Quoting Jani Nikula (2018-03-27 21:47:22) > Bool is the more appropriate return type here, use it. > > Signed-off-by: Jani Nikula All 3, Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesk

Re: [Intel-gfx] [PATCH v5 00/12] drm/i915/guc: Support for Guc responses and requests

On 3/26/2018 12:48 PM, Michal Wajdeczko wrote: With this series we will be able to receive more data from the Guc. New Guc firmwares will be required to actually use that feature. v4: respin series after 1/2 year break v5: updated after review comments Michal Wajdeczko (12): drm/i915/guc: Ad

[Intel-gfx] ✓ Fi.CI.IGT: success 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 : success == Summary == Known issues: Test kms_cursor_legacy: Subgroup flip-vs-cursor-atomic: fail -> PASS (s

[Intel-gfx] [PATCH 3/3] drm: make drm_core_check_feature() bool that it is

Bool is the more appropriate return type here, use it. Signed-off-by: Jani Nikula --- include/drm/drmP.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/drm/drmP.h b/include/drm/drmP.h index b5d52a3d7d19..f5099c12c6a6 100644 --- a/include/drm/drmP.h +++ b/include/

[Intel-gfx] [PATCH 1/3] drm: prefer inline over __inline__

Remove last users of __inline__. Signed-off-by: Jani Nikula --- include/drm/drmP.h | 5 ++--- include/drm/drm_legacy.h | 4 ++-- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/include/drm/drmP.h b/include/drm/drmP.h index ccd09347..4bbef061c9c0 100644 --- a/include/drm/

[Intel-gfx] [PATCH 2/3] drm: remove old documentation comment cruft from drmP.h

Throw out the leftovers. Signed-off-by: Jani Nikula --- include/drm/drmP.h | 21 - 1 file changed, 21 deletions(-) diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 4bbef061c9c0..b5d52a3d7d19 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -95,14 +95,6 @

[Intel-gfx] [PATCH v5 4/8] drm/i915/uc: Fully sanitize uC in uc_fini_hw

Today uc_fini_hw is subset of uc_sanitize, but remaining code in sanitize function is also desired for uc_fini_hw. Instead of duplicating the code, just call uc_sanitize, but leave as separate function to maintain symmetry with uc_init_hw. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc

[Intel-gfx] [PATCH v5 5/8] drm/i915/uc: Use correct error code for GuC initialization failure

Since commit 6ca9a2beb54a ("drm/i915: Unwind i915_gem_init() failure") we believed that we correctly handle all errors encountered during GuC initialization, including special one that indicates request to run driver with disabled GPU submission (-EIO). Unfortunately since commit 121981fafe69 ("dr

[Intel-gfx] [PATCH v5 3/8] drm/i915/guc: Restore symmetric doorbell cleanup

In commit 9192d4fb811e ("drm/i915/guc: Extract doorbell creation from client allocation") we introduced asymmetry in doorbell cleanup to avoid warnings due to failed communication with already reset GuC. As we improved our reset/unload paths, we can restore symmetry in doorbell cleanup, as GuC shou

[Intel-gfx] [PATCH v5 6/8] drm/i915/uc: Use helper functions to detect fw load status

We don't have to check load status values. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_huc.c | 2 +- drivers/gpu/drm/i915/intel_uc.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git

[Intel-gfx] [PATCH v5 7/8] drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c

Some functions already use i915 name instead of dev_priv. Let's rename this param in all remaining functions, except those that still use legacy macros. v2: don't forget about function descriptions (Sagar) v3: rebased Signed-off-by: Michal Wajdeczko Reviewed-by: Sagar Arun Kamble --- drivers/g

[Intel-gfx] [PATCH v5 8/8] HAX: Enable GuC for CI

v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h inde

[Intel-gfx] [PATCH v5 1/8] drm/i915: Correctly handle error path in i915_gem_init_hw

In function gem_init_hw() we are calling uc_init_hw() but in case of error later in function, we missed to call matching uc_fini_hw() Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_gem.c | 6 ++ 1 file ch

[Intel-gfx] [PATCH v5 2/8] drm/i915/uc: Disable GuC submission during sanitize

We should not leave GuC submission enabled after sanitize, as we are going to reset all GuC/HuC hardware. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_uc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel

Re: [Intel-gfx] [PATCH v5 09/12] drm/i915/guc: Prepare to process incoming requests from CT

On 3/26/2018 12:48 PM, Wajdeczko, Michal wrote: Requests are read from CT in the irq handler, but actual processing will be done in the work thread. Processing of specific actions will be added in the upcoming patches. v2: don't use GEM_BUG_ON (Chris) don't kmalloc too large buffer (Michal)

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

On 3/27/2018 11:25 AM, Daniele Ceraolo Spurio wrote: On 26/03/18 12:48, 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 o

[Intel-gfx] The behavior of i915_wait_request() after calling i915_gem_suspend_request()

Hi Chris and Joonas: Thanks for the discussion in the IRC for the suspend/resume request APIs. I just a bit curious about the behavior of i915_wait_request() after a caller suspend an i915 request. Will the caller of i915_wait_request() be woken up at this time? or not? This behavior decid

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_eio: Never re-use contexts which were in the middle of GPU reset

Quoting Tvrtko Ursulin (2018-03-27 17:40:56) > From: Tvrtko Ursulin > > Contexts executing when reset triggers are potentialy corrupt so trying to > use them from a subsequent test (like the default context) can hang the > GPU or even the driver. > > Workaround that by always creating a dedicate

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

On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote: > 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 req

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

On 26/03/18 12:48, 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 communicatio

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

On 2018-03-21 20:42, Oscar Mateo wrote: On 3/21/2018 3:16 AM, Chris Wilson wrote: Quoting Oscar Mateo (2018-03-20 18:43:45) 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 t

Re: [Intel-gfx] [PATCH v2] drm/i915: Reword warning for missing cases

On Mon, Mar 19, 2018 at 09:41:32PM +, Chris Wilson wrote: > Quoting Lucas De Marchi (2018-03-19 17:37:20) > > In some places we end up converting switch statements to a series of > > if/else, particularly when introducing helper functions to handle a > > group of cases. It's tempting to either

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

On Fri, Mar 23, 2018 at 06:25:52PM +0200, Ville Syrjälä wrote: > On Tue, Mar 20, 2018 at 03:06:37PM -0700, Lucas De Marchi wrote: > > 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-b

[Intel-gfx] ✗ Fi.CI.IGT: failure 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 : failure == Summary == Possible new issues: Test gem_eio: Subgroup execbuf: pass -> INCOMPLETE (shard-apl)

Re: [Intel-gfx] [PATCH v4 3/7] drm/i915/uc: Fully sanitize uC in uc_fini_hw

On Mon, 26 Mar 2018 13:23:21 +0200, Sagar Arun Kamble wrote: On 3/23/2018 8:44 PM, Michal Wajdeczko wrote: Today uc_fini_hw is subset of uc_sanitize, but remaining code in sanitize function is also desired for uc_fini_hw. Instead of duplicating the code, just call uc_sanitize, but leave as

Re: [Intel-gfx] [PATCH v4 2/7] drm/i915/uc: Disable GuC submission during sanitize

On Mon, 26 Mar 2018 12:36:05 +0200, Sagar Arun Kamble wrote: On 3/23/2018 8:44 PM, Michal Wajdeczko wrote: We should not leave GuC submission enabled after sanitize, as we are going to reset all GuC/HuC hardware. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Ei

[Intel-gfx] [PATCH i-g-t] tests/gem_eio: Never re-use contexts which were in the middle of GPU reset

From: Tvrtko Ursulin Contexts executing when reset triggers are potentialy corrupt so trying to use them from a subsequent test (like the default context) can hang the GPU or even the driver. Workaround that by always creating a dedicated context which will be running when GPU reset happens. Si

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

On 03/27/2018 05:07 AM, Ville Syrjälä wrote: 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 useful

Re: [Intel-gfx] [PATCH 5/8] drm/i915/icl: Add reset control register changes

On 3/16/2018 1:28 PM, Daniele Ceraolo Spurio wrote: On 16/03/18 05:14, Mika Kuoppala wrote: From: Michel Thierry The bits used to reset the different engines/domains have changed in GEN11, this patch maps the reset engine mask bits with the new bits in the reset control register. v2: Use sh

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

On 3/26/2018 9:57 AM, Tvrtko Ursulin wrote: On 26/03/2018 17:12, Yunwei Zhang wrote: 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

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

On Mon, Mar 26, 2018 at 12:50:41PM +0100, 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 r

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_ctx_isolation: Reset a scratch context

Quoting Tvrtko Ursulin (2018-03-27 16:41:14) > > [resend for typo in cc] The small advantage in redundancy, I guess. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

On Tue, Mar 27, 2018 at 09:51:20AM +0100, Tvrtko Ursulin wrote: > > 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

[Intel-gfx] ✓ Fi.CI.BAT: success 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 : success == Summary == Series 40747v1 drm/i915/gen11: Preempt-to-idle support in execlists. https://patchwork.freedesktop.org/api/1.0/series/40747/rev

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

On Tue, Mar 27, 2018 at 12:44:02PM +0100, 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. > > v2: Restore checking of use_csb_mmio on every loop, don't forget old > vgpu. > > Signed-off-b

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_ctx_isolation: Reset a scratch context

[resend for typo in cc] On 27/03/2018 14:59, Chris Wilson wrote: Quoting Chris Wilson (2018-03-27 14:52:20) Quoting Chris Wilson (2018-03-27 14:48:43) If we inject a reset into the target context, there is a risk that the register state is never saved back to memory. The exact interaction bet

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_ctx_isolation: Reset a scratch context

[resend for typo in cc] On 27/03/2018 14:48, Chris Wilson wrote: If we inject a reset into the target context, there is a risk that the register state is never saved back to memory. The exact interaction between reset, the context image and the precise timing of our execution are not well defin

[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: CHECK:COMPARISON_TO_NU

[Intel-gfx] ✗ Fi.CI.IGT: failure 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 : failure == Summary == Possible new issues: Test gem_ctx_param: Subgroup inva

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

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, so the Command Streamer never preempted to idle dir

[Intel-gfx] [PULL] drm-intel-next-fixes

Hi Dave, Two human-reported bugs to close for display and a more rare fix that could result in GPU hang. There was some unclarity about the GVT pull, so I'm not including it here. Happy Easter holidays! Regards, Joonas drm-intel-next-fixes-2018-03-27: - Display fixes for booting with MST hub l

Re: [Intel-gfx] [PATCH igt] overlay: Call setlocale around strtod

On 27/03/2018 15:28, Chris Wilson wrote: strtod() is locale-dependent. The decimal conversion depends on the radix character ('.' for some of us like myself) varies by locale. As the kernel reports its values using the "C" locale, we need to switch to that when parsing; and switch back before re

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

Quoting Joonas Lahtinen (2018-03-27 16:42:28) > 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 no

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

Quoting Tvrtko Ursulin (2018-03-26 17:57:38) > > On 26/03/2018 17:12, Yunwei Zhang wrote: > > --- > > drivers/gpu/drm/i915/i915_drv.h| 1 + > > drivers/gpu/drm/i915/intel_engine_cs.c | 39 > > -- > > 2 files changed, 38 insertions(+), 2 deletions(-) >

[Intel-gfx] [PATCH igt] overlay: Call setlocale around strtod

strtod() is locale-dependent. The decimal conversion depends on the radix character ('.' for some of us like myself) varies by locale. As the kernel reports its values using the "C" locale, we need to switch to that when parsing; and switch back before reporting to the user. Bugzilla: https://bugs

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

Yunwei Zhang writes: > 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.

[Intel-gfx] ✓ Fi.CI.IGT: 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 == Known issues: Test kms_cursor_legacy: Subgroup flip-vs-cursor-atomic: pass

[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:

  1   2   >