Re: [Intel-gfx] [RFC 2/2] drm/i915: Make intel_guc_wopcm_size() inline
Looks good to me.
Nitpicks:
1. s/dev_priv/i915 in intel_guc_wopcm_size
2. We are updating the parameter type of intel_guc_wopcm_size. Will it
be necessary to update that change log and intent in the commit message?
Thanks
Sagar
On 9/26/2017 10:18 PM, Michal Wajdeczko wrote:
It's small and we are using this function sporadically.
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_guc_loader.c | 11 ---
drivers/gpu/drm/i915/intel_uc.c | 4 ++--
drivers/gpu/drm/i915/intel_uc.h | 13 -
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index c9e25be..387d105a 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -250,17 +250,6 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
*dev_priv,
return ret;
}
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv)
-{
- u32 wopcm_size = GUC_WOPCM_TOP;
-
- /* On BXT, the top of WOPCM is reserved for RC6 context */
- if (IS_GEN9_LP(dev_priv))
- wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
-
- return wopcm_size;
-}
-
/*
* Load the GuC firmware blob into the MinuteIA.
*/
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 2774778..1ef2de6 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -188,7 +188,7 @@ static void fetch_uc_fw(struct drm_i915_private *dev_priv,
size = uc_fw->header_size + uc_fw->ucode_size;
/* Top 32k of WOPCM is reserved (8K stack + 24k RC6 context). */
- if (size > intel_guc_wopcm_size(dev_priv)) {
+ if (size > intel_guc_wopcm_size(&dev_priv->guc)) {
DRM_ERROR("Firmware is too large to fit in WOPCM\n");
goto fail;
}
@@ -374,7 +374,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
}
/* init WOPCM */
- I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(dev_priv));
+ I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(guc));
I915_WRITE(DMA_GUC_WOPCM_OFFSET,
GUC_WOPCM_OFFSET_VALUE | HUC_LOADING_AGENT_GUC);
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index b0e8849..b65ba5c 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -63,6 +63,18 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
}
+static inline u32 intel_guc_wopcm_size(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ u32 wopcm_size = GUC_WOPCM_TOP;
+
+ /* On BXT, the top of WOPCM is reserved for RC6 context */
+ if (IS_GEN9_LP(dev_priv))
+ wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
+
+ return wopcm_size;
+}
+
static inline u32 guc_ggtt_offset(struct i915_vma *vma)
{
u32 offset = i915_ggtt_offset(vma);
@@ -88,7 +100,6 @@ int intel_guc_select_fw(struct intel_guc *guc);
int intel_guc_init_hw(struct intel_guc *guc);
int intel_guc_suspend(struct drm_i915_private *dev_priv);
int intel_guc_resume(struct drm_i915_private *dev_priv);
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
/* i915_guc_submission.c */
int i915_guc_submission_init(struct drm_i915_private *dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Allow 2 pixel per clock on Cannonlake.
== Series Details == Series: drm/i915/cnl: Allow 2 pixel per clock on Cannonlake. URL : https://patchwork.freedesktop.org/series/30924/ State : success == Summary == Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 Test kms_flip: Subgroup flip-vs-expired-vblank: fail -> PASS (shard-hsw) fdo#102367 Subgroup plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#102367 https://bugs.freedesktop.org/show_bug.cgi?id=102367 shard-hswtotal:2429 pass:1336 dwarn:1 dfail:0 fail:9 skip:1083 time:9986s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5825/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: stolen_reserved_base is also dma_addr_t
== Series Details == Series: series starting with [1/2] drm/i915: stolen_reserved_base is also dma_addr_t URL : https://patchwork.freedesktop.org/series/30923/ State : failure == Summary == Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 +1 Test kms_flip: Subgroup flip-vs-expired-vblank: fail -> PASS (shard-hsw) fdo#102367 Subgroup plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) Test gem_exec_capture: Subgroup capture-render: pass -> INCOMPLETE (shard-hsw) fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102367 https://bugs.freedesktop.org/show_bug.cgi?id=102367 shard-hswtotal:2375 pass:1297 dwarn:1 dfail:0 fail:10 skip:1066 time:9618s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5824/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce DVFS.
== Series Details == Series: Introduce DVFS. URL : https://patchwork.freedesktop.org/series/30922/ State : success == Summary == Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 Test kms_flip: Subgroup flip-vs-expired-vblank: fail -> PASS (shard-hsw) fdo#102367 Subgroup plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#102367 https://bugs.freedesktop.org/show_bug.cgi?id=102367 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2429 pass:1335 dwarn:1 dfail:0 fail:10 skip:1083 time:9986s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5823/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for igt/gem_exec_scheduler: HAS_SCHEDULER no longer means HAS_PREEMPTION (rev2)
== Series Details == Series: igt/gem_exec_scheduler: HAS_SCHEDULER no longer means HAS_PREEMPTION (rev2) URL : https://patchwork.freedesktop.org/series/30860/ State : warning == Summary == Test gem_eio: Subgroup throttle: pass -> DMESG-WARN (shard-hsw) fdo#102886 Test kms_cursor_legacy: Subgroup flip-vs-cursor-legacy: pass -> FAIL (shard-hsw) fdo#102670 Subgroup basic-busy-flip-before-cursor-atomic: pass -> DMESG-WARN (shard-hsw) Test kms_flip: Subgroup plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) Subgroup flip-vs-expired-vblank: fail -> PASS (shard-hsw) fdo#102367 Test kms_vblank: Subgroup wait-busy: pass -> DMESG-WARN (shard-hsw) Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 Test prime_mmap: Subgroup test_userptr: pass -> DMESG-WARN (shard-hsw) fdo#102939 fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#102367 https://bugs.freedesktop.org/show_bug.cgi?id=102367 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102939 https://bugs.freedesktop.org/show_bug.cgi?id=102939 shard-hswtotal:2429 pass:1329 dwarn:5 dfail:0 fail:12 skip:1083 time:9902s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_253/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] Adding NV12 support
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Tuesday, September 26, 2017 5:17 PM > To: Kristian Høgsberg > Cc: Daniel Vetter ; Srinivas, Vidya > ; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 0/6] Adding NV12 support > > On Tue, Sep 19, 2017 at 02:56:17PM -0700, Kristian Høgsberg wrote: > > On Mon, Aug 28, 2017 at 3:17 PM, Daniel Vetter wrote: > > > On Mon, Aug 28, 2017 at 04:22:16PM +0530, Vidya Srinivas wrote: > > >> This patch series is adding NV12 support for Broxton display after > > >> rebasing on latest drm-intel-nightly. Initial series of the patches > > >> can be found here: > > >> https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.ht > > >> ml > > >> > > >> Previous revision history: > > >> Patches were initial reviewed last when floated but currently there > > >> was a design change with respect to > > >> - the way fb offset is handled > > >> - the way rotation is handled > > >> Rebase of the current NV12 patch series has been done as per the > > >> current changes on drm-intel-nightly. > > >> Review comments from Ville (12th June 2017) have been addressed > > >> Review comments from Clinton A Taylor (7th July 2017) have been > > >> addressed Review comments from Clinton A Taylor (10th July 2017) > > >> have been addressed. Had missed out tested-by/reviewed-by in the > > >> patches. > > >> Fixed that error in this series. > > >> Review comments from Ville (11th July 2017) addressed. > > >> Review comments from Paauwe, Bob (29th July 2017) addressed. > > >> > > >> Update from last rev: > > >> Rebased the series as Ville's patches are merged. Previously, this > > >> series included those floating patches. > > >> > > >> Chandra Konduru (6): > > >> drm/i915: Set scaler mode for NV12 > > >> drm/i915: Update format_is_yuv() to include NV12 > > >> drm/i915: Upscale scaler max scale for NV12 > > >> drm/i915: Add NV12 as supported format for primary plane > > >> drm/i915: Add NV12 as supported format for sprite plane > > >> drm/i915: Add NV12 support to intel_framebuffer_init > > > > > > Needs serious work on the plane scaling igt (it's atm all broken, > > > and doesn't test any atomic interactions). > > > > > > Then this needs serious work on the nv12 plane igts (which don't yet > > > exist). > > > > > > Then this probably needs pile more igts to test interactions between > > > everything (e.g. rotation, ...). > > > > > > In short: This needs itgs. Lots of them :-) > > > > > > Before those exist, and before we've tracked down the bug in the > > > existing code you're building on it imo makes no sense to start > > > reviewing these here. > > > > Also, this series need to advertise which modifiers work with the new > > NV12 format by adding a case to > > skl_sprite_plane_format_mod_supported() and skl_mod_supported(). > I am trying to cover as many test cases as possible. Thank you. > Oh right, which also means we need igts to test the plane formats against > more modifiers! Well that's kinda part of the tiling tests I guess, at least > for > nv12. In the current igt test that I have been enhancing, I have added tests for Tiling and nv12 combination. I have also added sprite and nv12 combination. Will try to float them as soon as possible. Facing slight issues for larger Resolution panels (4K) (maybe related to WM etc). Once I test them, Will float the IGT. Thank you. > -Daniel > > > > Kristian > > > > > Thanks, Daniel > > > > > >> > > >> drivers/gpu/drm/i915/i915_reg.h | 1 + > > >> drivers/gpu/drm/i915/intel_atomic.c | 8 - > > >> drivers/gpu/drm/i915/intel_display.c | 67 > +--- > > >> drivers/gpu/drm/i915/intel_drv.h | 3 +- > > >> drivers/gpu/drm/i915/intel_sprite.c | 34 ++ > > >> 5 files changed, 92 insertions(+), 21 deletions(-) > > >> > > >> -- > > >> 1.9.1 > > >> > > >> ___ > > >> Intel-gfx mailing list > > >> Intel-gfx@lists.freedesktop.org > > >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation http://blog.ffwll.ch > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [RFC,1/2] drm/i915/uc: Move uC related types into dedicated header
== Series Details == Series: series starting with [RFC,1/2] drm/i915/uc: Move uC related types into dedicated header URL : https://patchwork.freedesktop.org/series/30918/ State : failure == Summary == Test kms_flip: Subgroup flip-vs-expired-vblank: fail -> PASS (shard-hsw) fdo#102367 Subgroup plain-flip-ts-check-interruptible: fail -> PASS (shard-hsw) Test gem_exec_store: Subgroup pages-default: pass -> FAIL (shard-hsw) fdo#102367 https://bugs.freedesktop.org/show_bug.cgi?id=102367 shard-hswtotal:2429 pass:1334 dwarn:1 dfail:0 fail:11 skip:1083 time:9970s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5822/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: allow HDMI 2.0 clock rates
Please ignore this patch.
Freq is wrong... shoudl be 594000 as GLK but also other parts are
missing. Causes blank screen on CNL with HDMI 2.0 panel.
On Tue, Sep 26, 2017 at 3:13 PM, Rodrigo Vivi wrote:
> From: Shashank Sharma
>
> From GLK onwards, Intel platforms contain native HDMI 2.0
> controller, which is capable of driving clocks upto 600Mhz.
> This patch updates the max tmds clock limit for the same.
>
> V2: check for gen 10 and above (Ville)
> align the gen10 condition with upper line (Ander)
> V3: rebase on top of patch-2-v3
> v4: (by Rodrigo): Besides rebasing it s/gen9_lp/glk+ on this
> commit message.
>
> Cc: Ville Syrjälä
> Cc: Paulo Zanoni
> Signed-off-by: Shashank Sharma
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index e6f8f30ce7bd..f70591a024f0 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1222,6 +1222,8 @@ static int intel_hdmi_source_max_tmds_clock(struct
> drm_i915_private *dev_priv)
> {
> if (IS_G4X(dev_priv))
> return 165000;
> + else if (INTEL_INFO(dev_priv)->gen >= 10)
> + return 60;
> else if (IS_GEMINILAKE(dev_priv))
> return 594000;
> else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
> --
> 2.13.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/selftests: Replace wmb() with i915_gem_chipset_flush()
== Series Details == Series: drm/i915/selftests: Replace wmb() with i915_gem_chipset_flush() URL : https://patchwork.freedesktop.org/series/30916/ State : warning == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-indfb-draw-render: pass -> SKIP (shard-hsw) shard-hswtotal:2429 pass:1327 dwarn:5 dfail:0 fail:13 skip:1084 time:9837s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5821/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [maintainer-tools PATCH] qf: Handle unused patches on sub-directories.
Most of internal patches are nowadays organized in
quilt subdirectories, but qf was never updated to check
for unused patches there.
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
qf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/qf b/qf
index 0c9d28edb3f0..cafbdc44e1bc 100755
--- a/qf
+++ b/qf
@@ -300,7 +300,7 @@ function qf_clean_patches
cd_toplevel
repo_check 0
- for patch in patches/*.patch ; do
+ for patch in patches/{*/,/}*.patch ; do
if grep "^${patch##patches/}$" patches/series &> /dev/null ;
then
continue
fi
@@ -486,7 +486,7 @@ function qf_list_unused_patches
cd_toplevel
repo_check 1
- for patch in patches/*.patch ; do
+ for patch in patches/{*/,/}*.patch ; do
if ! grep "^${patch#patches/}$" patches/series > /dev/null ;
then
if [[ "$1" != --purge ]] ; then
echo $patch
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/execlists: Notify context-out for lost requests (rev3)
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Notify context-out for lost requests (rev3) URL : https://patchwork.freedesktop.org/series/30895/ State : success == Summary == Test perf: Subgroup blocking: pass -> FAIL (shard-hsw) fdo#102252 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2381 pass:1298 dwarn:4 dfail:0 fail:14 skip:1065 time:9438s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5820/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for igt/gem_workarounds: Read the workaround registers from the active context
== Series Details == Series: igt/gem_workarounds: Read the workaround registers from the active context URL : https://patchwork.freedesktop.org/series/30930/ State : warning == Summary == IGT patchset tested on top of latest successful build 2885b10f99b4beeb046e75af8b8488c229f629d3 igt/gem_exec_schedule: Ignore set-priority failures on old kernels with latest DRM-Tip kernel build CI_DRM_3141 13d4fadfbe07 drm-tip: 2017y-09m-26d-20h-03m-18s UTC integration manifest Test gem_workarounds: Subgroup basic-read: pass -> SKIP (fi-blb-e6850) pass -> SKIP (fi-pnv-d510) pass -> SKIP (fi-bwr-2160) pass -> SKIP (fi-elk-e7500) pass -> SKIP (fi-ilk-650) pass -> SKIP (fi-snb-2520m) pass -> SKIP (fi-snb-2600) pass -> SKIP (fi-ivb-3520m) pass -> SKIP (fi-ivb-3770) pass -> SKIP (fi-byt-j1900) pass -> SKIP (fi-byt-n2820) pass -> SKIP (fi-hsw-4770) pass -> SKIP (fi-hsw-4770r) Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (fi-cfl-s) fdo#102294 Test drv_module_reload: Subgroup basic-reload-inject: dmesg-warn -> PASS (fi-glk-1) fdo#102777 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:454s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:474s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:418s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:528s fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:279s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:511s fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:500s fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:508s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:538s fi-cnl-y total:289 pass:258 dwarn:0 dfail:0 fail:4 skip:27 time:671s fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:420s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:565s fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:427s fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:409s fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:436s fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:490s fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:471s fi-kbl-7500u total:289 pass:263 dwarn:1 dfail:0 fail:1 skip:24 time:459s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:582s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:589s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:546s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:456s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:753s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:493s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:478s fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:575s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:421s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_255/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: allow HDMI 2.0 clock rates
== Series Details == Series: drm/i915/cnl: allow HDMI 2.0 clock rates URL : https://patchwork.freedesktop.org/series/30929/ State : success == Summary == Series 30929v1 drm/i915/cnl: allow HDMI 2.0 clock rates https://patchwork.freedesktop.org/api/1.0/series/30929/revisions/1/mbox/ Test chamelium: Subgroup dp-crc-fast: fail -> PASS (fi-kbl-7500u) fdo#102514 Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (fi-cfl-s) fdo#102294 Test drv_module_reload: Subgroup basic-reload-inject: dmesg-warn -> PASS (fi-glk-1) fdo#102777 fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:437s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:469s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:417s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:527s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:505s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:491s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:500s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:535s fi-cnl-y total:289 pass:258 dwarn:0 dfail:0 fail:4 skip:27 time:641s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:418s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:564s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:426s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:402s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:435s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:487s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:469s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:471s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:578s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:591s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:542s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:745s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:488s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:477s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:576s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:412s 13d4fadfbe072f2952fb0fda72f2176434b609f5 drm-tip: 2017y-09m-26d-20h-03m-18s UTC integration manifest b0dfaaa5a7c8 drm/i915/cnl: allow HDMI 2.0 clock rates == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5827/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for GEM/GuC Suspend/Resume/Reset fixes and restructuring (rev2)
== Series Details == Series: GEM/GuC Suspend/Resume/Reset fixes and restructuring (rev2) URL : https://patchwork.freedesktop.org/series/30802/ State : success == Summary == shard-hswtotal:2429 pass:1328 dwarn:5 dfail:0 fail:13 skip:1083 time:9867s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5818/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] igt/gem_workarounds: Read the workaround registers from the active context
The workarounds are only valid whilst the GPU is active. To be sure we
are reading the registers in the right state, issue the reads from the GPU.
Signed-off-by: Chris Wilson
---
tests/gem_workarounds.c | 138 +++-
1 file changed, 77 insertions(+), 61 deletions(-)
diff --git a/tests/gem_workarounds.c b/tests/gem_workarounds.c
index d6641bd5..e5db1b39 100644
--- a/tests/gem_workarounds.c
+++ b/tests/gem_workarounds.c
@@ -44,66 +44,100 @@ struct intel_wa_reg {
static struct intel_wa_reg *wa_regs;
static int num_wa_regs;
-static void wait_gpu(void)
-{
- int fd = drm_open_driver(DRIVER_INTEL);
- gem_quiescent_gpu(fd);
- close(fd);
-}
-
-static void test_hang_gpu(void)
-{
- int fd = drm_open_driver(DRIVER_INTEL);
- igt_post_hang_ring(fd, igt_hang_ring(fd, I915_EXEC_DEFAULT));
- close(fd);
-}
-
static void test_suspend_resume(void)
{
igt_info("Suspending the device ...\n");
igt_system_suspend_autoresume(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
}
-static int workaround_fail_count(void)
+#define MI_STORE_REGISTER_MEM (0x24 << 23)
+
+static int workaround_fail_count(int fd)
{
- int i, fail_count = 0;
+ const int gen = intel_gen(intel_get_drm_devid(fd));
+ struct drm_i915_gem_exec_object2 obj[2];
+ struct drm_i915_gem_relocation_entry *reloc;
+ struct drm_i915_gem_execbuffer2 execbuf;
+ uint32_t result_sz, batch_sz;
+ uint32_t *base, *out;
+ int fail_count = 0;
+
+ reloc = calloc(num_wa_regs, sizeof(*reloc));
+ igt_assert(reloc);
+
+ result_sz = 4 * num_wa_regs;
+ result_sz = (result_sz + 4095) & -4096;
+
+ batch_sz = 16 * num_wa_regs;
+ batch_sz = (batch_sz + 4 + 4095) & -4096;
+
+ memset(obj, 0, sizeof(obj));
+ obj[0].handle = gem_create(fd, result_sz);
+ gem_set_caching(fd, obj[0].handle, 1);
+ obj[1].handle = gem_create(fd, batch_sz);
+ obj[1].relocs_ptr = to_user_pointer(reloc);
+ obj[1].relocation_count = num_wa_regs;
+
+ out = base = gem_mmap__cpu(fd, obj[1].handle, 0, batch_sz, PROT_WRITE);
+ for (int i = 0; i < num_wa_regs; i++) {
+ *out++ = MI_STORE_REGISTER_MEM | ((gen >= 8 ? 4 : 2) - 2);
+ *out++ = wa_regs[i].addr;
+ reloc[i].target_handle = obj[0].handle;
+ reloc[i].offset = (out - base) * sizeof(*out);
+ reloc[i].delta = i * sizeof(uint32_t);
+ reloc[i].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
+ reloc[i].write_domain = I915_GEM_DOMAIN_INSTRUCTION;
+ *out++ = reloc[i].delta;
+ if (gen >= 8)
+ *out++ = 0;
+ }
+ *out++ = MI_BATCH_BUFFER_END;
+ munmap(base, batch_sz);
+
+ memset(&execbuf, 0, sizeof(execbuf));
+ execbuf.buffers_ptr = to_user_pointer(obj);
+ execbuf.buffer_count = 2;
+ gem_execbuf(fd, &execbuf);
- /* There is a small delay after coming ot of rc6 to the correct
- render context values will get loaded by hardware (bdw,chv).
- This here ensures that we have the correct context loaded before
- we start to read values */
- wait_gpu();
+ gem_set_domain(fd, obj[0].handle, I915_GEM_DOMAIN_CPU, 0);
igt_debug("Address\tval\t\tmask\t\tread\t\tresult\n");
- for (i = 0; i < num_wa_regs; ++i) {
- const uint32_t val = intel_register_read(wa_regs[i].addr);
- const bool ok = (wa_regs[i].value & wa_regs[i].mask) ==
- (val & wa_regs[i].mask);
+ out = gem_mmap__cpu(fd, obj[0].handle, 0, result_sz, PROT_READ);
+ for (int i = 0; i < num_wa_regs; i++) {
+ const bool ok =
+ (wa_regs[i].value & wa_regs[i].mask) ==
+ (out[i] & wa_regs[i].mask);
+ char buf[80];
- igt_debug("0x%05X\t0x%08X\t0x%08X\t0x%08X\t%s\n",
- wa_regs[i].addr, wa_regs[i].value, wa_regs[i].mask,
- val, ok ? "OK" : "FAIL");
+ snprintf(buf, sizeof(buf),
+"0x%05X\t0x%08X\t0x%08X\t0x%08X",
+wa_regs[i].addr, wa_regs[i].value, wa_regs[i].mask,
+out[i]);
if (!ok) {
- igt_warn("0x%05X\t0x%08X\t0x%08X\t0x%08X\t%s\n",
-wa_regs[i].addr, wa_regs[i].value,
-wa_regs[i].mask,
-val, ok ? "OK" : "FAIL");
+ igt_warn("%s\tFAIL\n", buf);
fail_count++;
+ } else {
+ igt_debug("%s\tOK\n", buf);
}
}
+ munmap(out, result_sz);
+
+ gem_close(fd, obj[1].handle);
+ gem_close(fd, obj[0].handle);
+ free(reloc);
return fail_count;
}
-stati
[Intel-gfx] [PATCH] drm/i915/cnl: allow HDMI 2.0 clock rates
From: Shashank Sharma
From GLK onwards, Intel platforms contain native HDMI 2.0
controller, which is capable of driving clocks upto 600Mhz.
This patch updates the max tmds clock limit for the same.
V2: check for gen 10 and above (Ville)
align the gen10 condition with upper line (Ander)
V3: rebase on top of patch-2-v3
v4: (by Rodrigo): Besides rebasing it s/gen9_lp/glk+ on this
commit message.
Cc: Ville Syrjälä
Cc: Paulo Zanoni
Signed-off-by: Shashank Sharma
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index e6f8f30ce7bd..f70591a024f0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1222,6 +1222,8 @@ static int intel_hdmi_source_max_tmds_clock(struct
drm_i915_private *dev_priv)
{
if (IS_G4X(dev_priv))
return 165000;
+ else if (INTEL_INFO(dev_priv)->gen >= 10)
+ return 60;
else if (IS_GEMINILAKE(dev_priv))
return 594000;
else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid using dev_priv->info.gen directly.
On Tue, Sep 26, 2017 at 09:21:43PM +, Paulo Zanoni wrote:
> Em Ter, 2017-09-26 às 14:13 -0700, Rodrigo Vivi escreveu:
> > Let's stop this usage before it spreads so much.
> >
> > 1. This check is not part of usual searches happening when adding
> > new platform.
> > 2. There is already a duplication here with INTEL_INFO(dev_priv)->gen
> > and INTEL_GEN(dev_priv).
> >
> > So let's please avoid yet another way.
> >
> > Fixes: b22ca995ba1c ("drm/i915: prepare pipe for YCBCR420 output")
> > Fixes: 27082493e9c6 ("drm/i915/skl: Update DDB values atomically with
> > wms/plane attrs")
>
> Not sure if the Fixes tags are appropriate since this is not a bug fix.
I wondered that... but since "dim fixes" provided me that tag along with the
list of people I should cc I decided to include here. I thought it
wouldn't hurt and also maybe good to propagate that to everywhere possible so
we don't recieve more code based on that usage.
But I won't merge today to give time to get Jani's view on that.
>
> Reviewed-by: Paulo Zanoni
>
> > Cc: Lyude
> > Cc: Ville Syrjälä
> > Cc: Daniel Vetter
> > Cc: Radhakrishna Sripada
> > Cc: Hans de Goede
> > Cc: Matt Roper
> > Cc: Maarten Lankhorst
> > Cc: Paulo Zanoni
> > Cc: Ville Syrjala
> > Cc: Imre Deak
> > Cc: Shashank Sharma
> > Cc: Jani Nikula
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 487b43ba3139..fba76f1bb6dd 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -9310,11 +9310,11 @@ static bool haswell_get_pipe_config(struct
> > intel_crtc *crtc,
> > pipe_config->gamma_mode =
> > I915_READ(GAMMA_MODE(crtc->pipe)) &
> > GAMMA_MODE_MODE_MASK;
> >
> > - if (IS_BROADWELL(dev_priv) || dev_priv->info.gen >= 9) {
> > + if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9) {
> > u32 tmp = I915_READ(PIPEMISC(crtc->pipe));
> > bool clrspace_yuv = tmp &
> > PIPEMISC_OUTPUT_COLORSPACE_YUV;
> >
> > - if (IS_GEMINILAKE(dev_priv) || dev_priv->info.gen >=
> > 10) {
> > + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv)
> > >= 10) {
> > bool blend_mode_420 = tmp &
> > PIPEMISC_YUV420_MODE_F
> > ULL_BLEND;
> >
> > @@ -14217,7 +14217,7 @@ void intel_init_display_hooks(struct
> > drm_i915_private *dev_priv)
> > dev_priv->display.fdi_link_train =
> > hsw_fdi_link_train;
> > }
> >
> > - if (dev_priv->info.gen >= 9)
> > + if (INTEL_GEN(dev_priv) >= 9)
> > dev_priv->display.update_crtcs = skl_update_crtcs;
> > else
> > dev_priv->display.update_crtcs = intel_update_crtcs;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid using dev_priv->info.gen directly.
== Series Details == Series: drm/i915: Avoid using dev_priv->info.gen directly. URL : https://patchwork.freedesktop.org/series/30926/ State : success == Summary == Series 30926v1 drm/i915: Avoid using dev_priv->info.gen directly. https://patchwork.freedesktop.org/api/1.0/series/30926/revisions/1/mbox/ Test chamelium: Subgroup dp-edid-read: pass -> FAIL (fi-kbl-7500u) fdo#102672 Subgroup dp-crc-fast: fail -> PASS (fi-kbl-7500u) fdo#102514 Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (fi-cfl-s) fdo#102294 Test drv_module_reload: Subgroup basic-no-display: pass -> DMESG-WARN (fi-glk-1) fdo#102777 +1 fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:440s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:466s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:422s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:517s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:495s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:496s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:497s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:539s fi-cnl-y total:289 pass:258 dwarn:0 dfail:0 fail:4 skip:27 time:639s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:418s fi-glk-1 total:289 pass:259 dwarn:1 dfail:0 fail:0 skip:29 time:564s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:423s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:405s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:433s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:491s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:460s fi-kbl-7500u total:289 pass:263 dwarn:1 dfail:0 fail:1 skip:24 time:469s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:577s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:589s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:549s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:454s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:748s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:487s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:475s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:575s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:414s 13d4fadfbe072f2952fb0fda72f2176434b609f5 drm-tip: 2017y-09m-26d-20h-03m-18s UTC integration manifest a457f6bb37eb drm/i915: Avoid using dev_priv->info.gen directly. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5826/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/22] drm/i915: introduce simple gemfs
On Tue, Sep 26, 2017 at 04:21:47PM +0300, Joonas Lahtinen wrote: > On Tue, 2017-09-26 at 09:52 +0200, Greg Kroah-Hartman wrote: > > On Mon, Sep 25, 2017 at 07:47:17PM +0100, Matthew Auld wrote: > > > Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so > > > moves us away from the shmemfs shm_mnt, and gives us the much needed > > > flexibility to do things like set our own mount options, namely huge= > > > which should allow us to enable the use of transparent-huge-pages for > > > our shmem backed objects. > > > > > > v2: various improvements suggested by Joonas > > > > > > v3: move gemfs instance to i915.mm and simplify now that we have > > > file_setup_with_mnt > > > > > > v4: fallback to tmpfs shm_mnt upon failure to setup gemfs > > > > > > v5: make tmpfs fallback kinder > > > > Why do this only for one specific driver? Shouldn't the drm core handle > > this for you, for all other drivers as well? Otherwise trying to figure > > out how to "contain" this type of thing is going to be a pain (mount > > options, selinux options, etc.) > > We actually started quite grande by making stripped down version of > shmemfs for drm core, but kept running into nacks about how we were > implementing it (after getting a recommendation to try implementing it > some way). After a few iterations and massive engineering time, we have > been progressively reducing the amount of changes outside i915 in the > hopes to get this merged. > > And all the while clock is ticking, so we thought the best way to get > something to support our future work is to implement this first locally > with minimal external changes outside i915 and then once we have > something working, it'll be easier to generalize it for the drm core. > Otherwise we'll never get to work with the huge page support, for which > gemfs is the stepping stone here. > > So we're not planning on sitting on top of it, we'll just incubate it > under i915/ so that it'll then be less pain for others to adopt when > the biggest hurdles with core MM interactions are sorted out. But by doing this, you are now creating a new user/kernel api that you have to support for forever, right? Will it not change if you make it "generic" to the drm core eventually? Worse case, name it a generic name that everyone will end up using in the future, and then you can just claim that all other drivers need to implement it :) thanks, greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid using dev_priv->info.gen directly.
On Tue, Sep 26, 2017 at 02:13:46PM -0700, Rodrigo Vivi wrote:
> Let's stop this usage before it spreads so much.
>
> 1. This check is not part of usual searches happening when adding
> new platform.
> 2. There is already a duplication here with INTEL_INFO(dev_priv)->gen
> and INTEL_GEN(dev_priv).
>
> So let's please avoid yet another way.
>
> Fixes: b22ca995ba1c ("drm/i915: prepare pipe for YCBCR420 output")
> Fixes: 27082493e9c6 ("drm/i915/skl: Update DDB values atomically with
> wms/plane attrs")
> Cc: Lyude
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Radhakrishna Sripada
> Cc: Hans de Goede
> Cc: Matt Roper
> Cc: Maarten Lankhorst
> Cc: Paulo Zanoni
> Cc: Ville Syrjala
> Cc: Imre Deak
> Cc: Shashank Sharma
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Matt Roper
Maybe we could make dim use coccinelle to flag these kinds of patterns
in the future to prevent them from sneaking back into the code?
Matt
> ---
> drivers/gpu/drm/i915/intel_display.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 487b43ba3139..fba76f1bb6dd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9310,11 +9310,11 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->gamma_mode =
> I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
>
> - if (IS_BROADWELL(dev_priv) || dev_priv->info.gen >= 9) {
> + if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9) {
> u32 tmp = I915_READ(PIPEMISC(crtc->pipe));
> bool clrspace_yuv = tmp & PIPEMISC_OUTPUT_COLORSPACE_YUV;
>
> - if (IS_GEMINILAKE(dev_priv) || dev_priv->info.gen >= 10) {
> + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10) {
> bool blend_mode_420 = tmp &
> PIPEMISC_YUV420_MODE_FULL_BLEND;
>
> @@ -14217,7 +14217,7 @@ void intel_init_display_hooks(struct drm_i915_private
> *dev_priv)
> dev_priv->display.fdi_link_train = hsw_fdi_link_train;
> }
>
> - if (dev_priv->info.gen >= 9)
> + if (INTEL_GEN(dev_priv) >= 9)
> dev_priv->display.update_crtcs = skl_update_crtcs;
> else
> dev_priv->display.update_crtcs = intel_update_crtcs;
> --
> 2.13.5
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid using dev_priv->info.gen directly.
Em Ter, 2017-09-26 às 14:13 -0700, Rodrigo Vivi escreveu:
> Let's stop this usage before it spreads so much.
>
> 1. This check is not part of usual searches happening when adding
> new platform.
> 2. There is already a duplication here with INTEL_INFO(dev_priv)->gen
> and INTEL_GEN(dev_priv).
>
> So let's please avoid yet another way.
>
> Fixes: b22ca995ba1c ("drm/i915: prepare pipe for YCBCR420 output")
> Fixes: 27082493e9c6 ("drm/i915/skl: Update DDB values atomically with
> wms/plane attrs")
Not sure if the Fixes tags are appropriate since this is not a bug fix.
Reviewed-by: Paulo Zanoni
> Cc: Lyude
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Radhakrishna Sripada
> Cc: Hans de Goede
> Cc: Matt Roper
> Cc: Maarten Lankhorst
> Cc: Paulo Zanoni
> Cc: Ville Syrjala
> Cc: Imre Deak
> Cc: Shashank Sharma
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_display.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 487b43ba3139..fba76f1bb6dd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9310,11 +9310,11 @@ static bool haswell_get_pipe_config(struct
> intel_crtc *crtc,
> pipe_config->gamma_mode =
> I915_READ(GAMMA_MODE(crtc->pipe)) &
> GAMMA_MODE_MODE_MASK;
>
> - if (IS_BROADWELL(dev_priv) || dev_priv->info.gen >= 9) {
> + if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9) {
> u32 tmp = I915_READ(PIPEMISC(crtc->pipe));
> bool clrspace_yuv = tmp &
> PIPEMISC_OUTPUT_COLORSPACE_YUV;
>
> - if (IS_GEMINILAKE(dev_priv) || dev_priv->info.gen >=
> 10) {
> + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv)
> >= 10) {
> bool blend_mode_420 = tmp &
> PIPEMISC_YUV420_MODE_F
> ULL_BLEND;
>
> @@ -14217,7 +14217,7 @@ void intel_init_display_hooks(struct
> drm_i915_private *dev_priv)
> dev_priv->display.fdi_link_train =
> hsw_fdi_link_train;
> }
>
> - if (dev_priv->info.gen >= 9)
> + if (INTEL_GEN(dev_priv) >= 9)
> dev_priv->display.update_crtcs = skl_update_crtcs;
> else
> dev_priv->display.update_crtcs = intel_update_crtcs;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Avoid using dev_priv->info.gen directly.
Let's stop this usage before it spreads so much.
1. This check is not part of usual searches happening when adding
new platform.
2. There is already a duplication here with INTEL_INFO(dev_priv)->gen
and INTEL_GEN(dev_priv).
So let's please avoid yet another way.
Fixes: b22ca995ba1c ("drm/i915: prepare pipe for YCBCR420 output")
Fixes: 27082493e9c6 ("drm/i915/skl: Update DDB values atomically with wms/plane
attrs")
Cc: Lyude
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
Cc: Matt Roper
Cc: Maarten Lankhorst
Cc: Paulo Zanoni
Cc: Ville Syrjala
Cc: Imre Deak
Cc: Shashank Sharma
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 487b43ba3139..fba76f1bb6dd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9310,11 +9310,11 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->gamma_mode =
I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
- if (IS_BROADWELL(dev_priv) || dev_priv->info.gen >= 9) {
+ if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9) {
u32 tmp = I915_READ(PIPEMISC(crtc->pipe));
bool clrspace_yuv = tmp & PIPEMISC_OUTPUT_COLORSPACE_YUV;
- if (IS_GEMINILAKE(dev_priv) || dev_priv->info.gen >= 10) {
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10) {
bool blend_mode_420 = tmp &
PIPEMISC_YUV420_MODE_FULL_BLEND;
@@ -14217,7 +14217,7 @@ void intel_init_display_hooks(struct drm_i915_private
*dev_priv)
dev_priv->display.fdi_link_train = hsw_fdi_link_train;
}
- if (dev_priv->info.gen >= 9)
+ if (INTEL_GEN(dev_priv) >= 9)
dev_priv->display.update_crtcs = skl_update_crtcs;
else
dev_priv->display.update_crtcs = intel_update_crtcs;
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add defines for latency in sink
On Tue, Sep 26, 2017 at 1:37 PM, Puthikorn Voravootivat wrote: > > > On Tue, Sep 26, 2017 at 10:37 AM, Puthikorn Voravootivat > wrote: >> >> >> >> On Mon, Sep 25, 2017 at 10:11 PM, Daniel Vetter wrote: >>> >>> On Thu, Sep 21, 2017 at 07:42:07AM -0700, Rodrigo Vivi wrote: >>> > On Wed, Sep 20, 2017 at 02:32:34PM +, vathsala nagaraju wrote: >>> > > Add defines for dpcd register 2009 (synchronization latency >>> > > in sink). >>> > > >>> > > Cc: Rodrigo Vivi >>> > > CC: Puthikorn Voravootivat >>> > > Signed-off-by: Vathsala Nagaraju >>> > >>> > I keep forgetting to update my eDP spec 1.4 to this 1.4b... >>> >>> Maybe the patch should then make this clear, by annotating it with >>> /* eDP 1.4b */ That's missing, which isn't all that great really, since >>> it >>> makes specs hunts like yours necessary. >>> >> It's actually in eDP 1.4 spec, table 5-6 page 86 > > Copy and paste the wrong one. > 0x2009 is actually in eDP 1.4 spec, Table 6-7: DPCD – Sink Device PSR Status > Field page 124 you are absolutely right! eDP 1.4 has it. even the eDP 1.4a had... I definitely had a strange version here... All updated locally here. For the patch I will update when merging. No need to send a newer version. I intend to merge patches tomorrow if no one has any other comment or concern on those. > >> >> >>> >>> Please fix up before applying. >>> -Daniel >>> > >>> > >>> > Reviewed-by: Rodrigo Vivi >>> > >>> > >>> > >>> > > --- >>> > > include/drm/drm_dp_helper.h | 3 +++ >>> > > 1 file changed, 3 insertions(+) >>> > > >>> > > diff --git a/include/drm/drm_dp_helper.h >>> > > b/include/drm/drm_dp_helper.h >>> > > index 11c39f1..846004e6 100644 >>> > > --- a/include/drm/drm_dp_helper.h >>> > > +++ b/include/drm/drm_dp_helper.h >>> > > @@ -735,6 +735,9 @@ >>> > > # define DP_PSR_SINK_INTERNAL_ERROR 7 >>> > > # define DP_PSR_SINK_STATE_MASK 0x07 >>> > > >>> > > +#define DP_SINK_SYNCHRONIZATION_LATENCY0x2009 >>> > > +# define DP_MAX_RESYNC_FRAME_CNT_MASK 0xf >>> > > + >>> > > #define DP_RECEIVER_ALPM_STATUS0x200b /* eDP 1.4 */ >>> > > # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0) >>> > > >>> > > -- >>> > > 1.9.1 >>> > > >>> > ___ >>> > dri-devel mailing list >>> > dri-de...@lists.freedesktop.org >>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >>> -- >>> Daniel Vetter >>> Software Engineer, Intel Corporation >>> http://blog.ffwll.ch >> >> > > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v8,1/8] drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors
== Series Details == Series: series starting with [v8,1/8] drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors URL : https://patchwork.freedesktop.org/series/30905/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-indfb-draw-render: skip -> PASS (shard-hsw) Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2429 pass:1327 dwarn:5 dfail:0 fail:14 skip:1083 time:9856s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5817/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add defines for latency in sink
On Tue, Sep 26, 2017 at 10:37 AM, Puthikorn Voravootivat < put...@chromium.org> wrote: > > > On Mon, Sep 25, 2017 at 10:11 PM, Daniel Vetter wrote: > >> On Thu, Sep 21, 2017 at 07:42:07AM -0700, Rodrigo Vivi wrote: >> > On Wed, Sep 20, 2017 at 02:32:34PM +, vathsala nagaraju wrote: >> > > Add defines for dpcd register 2009 (synchronization latency >> > > in sink). >> > > >> > > Cc: Rodrigo Vivi >> > > CC: Puthikorn Voravootivat >> > > Signed-off-by: Vathsala Nagaraju >> > >> > I keep forgetting to update my eDP spec 1.4 to this 1.4b... >> >> Maybe the patch should then make this clear, by annotating it with >> /* eDP 1.4b */ That's missing, which isn't all that great really, since it >> makes specs hunts like yours necessary. >> >> It's actually in eDP 1.4 spec, table 5-6 page 86 > Copy and paste the wrong one. 0x2009 is actually in eDP 1.4 spec, Table 6-7: DPCD – Sink Device PSR Status Field page 124 > > >> Please fix up before applying. >> -Daniel >> > >> > >> > Reviewed-by: Rodrigo Vivi >> > >> > >> > >> > > --- >> > > include/drm/drm_dp_helper.h | 3 +++ >> > > 1 file changed, 3 insertions(+) >> > > >> > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h >> > > index 11c39f1..846004e6 100644 >> > > --- a/include/drm/drm_dp_helper.h >> > > +++ b/include/drm/drm_dp_helper.h >> > > @@ -735,6 +735,9 @@ >> > > # define DP_PSR_SINK_INTERNAL_ERROR 7 >> > > # define DP_PSR_SINK_STATE_MASK 0x07 >> > > >> > > +#define DP_SINK_SYNCHRONIZATION_LATENCY0x2009 >> > > +# define DP_MAX_RESYNC_FRAME_CNT_MASK 0xf >> > > + >> > > #define DP_RECEIVER_ALPM_STATUS0x200b /* eDP 1.4 */ >> > > # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0) >> > > >> > > -- >> > > 1.9.1 >> > > >> > ___ >> > dri-devel mailing list >> > dri-de...@lists.freedesktop.org >> > https://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch >> > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Allow 2 pixel per clock on Cannonlake.
== Series Details == Series: drm/i915/cnl: Allow 2 pixel per clock on Cannonlake. URL : https://patchwork.freedesktop.org/series/30924/ State : success == Summary == Series 30924v1 drm/i915/cnl: Allow 2 pixel per clock on Cannonlake. https://patchwork.freedesktop.org/api/1.0/series/30924/revisions/1/mbox/ Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (fi-cfl-s) fdo#102294 Test drv_module_reload: Subgroup basic-reload-inject: pass -> DMESG-WARN (fi-glk-1) fdo#102777 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:437s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:474s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:426s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:518s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:511s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:493s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:497s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:544s fi-cnl-y total:289 pass:257 dwarn:0 dfail:0 fail:5 skip:27 time:641s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:419s fi-glk-1 total:289 pass:259 dwarn:1 dfail:0 fail:0 skip:29 time:626s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:425s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:402s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:430s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:489s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:470s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:470s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:572s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:586s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:544s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:748s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:488s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:472s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:561s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:412s c4c623d58e38d49e692dc9141250b35e39170e6b drm-tip: 2017y-09m-26d-16h-37m-12s UTC integration manifest a12c05ce96e5 drm/i915/cnl: Allow 2 pixel per clock on Cannonlake. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5825/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: use size_t instead of u32 for stolen memory size variables
Quoting Paulo Zanoni (2017-09-26 20:29:08)
> Stolen memory pointers are dma_addr_t, which means they can be 64 bit
> things. By using u32 we leave room for bugs in case we ever get huge
> amounts of stolen memory. By using size_t we don't risk running into
> those problems.
>
> Cc: Chris Wilson
> Signed-off-by: Paulo Zanoni
> ---
> drivers/char/agp/intel-gtt.c | 10 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c| 2 +-
> drivers/gpu/drm/i915/i915_gem_gtt.h| 6 +++---
> drivers/gpu/drm/i915/i915_gem_stolen.c | 19 +--
> include/drm/intel-gtt.h| 2 +-
> 5 files changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> index 9b6b602..a1db230 100644
> --- a/drivers/char/agp/intel-gtt.c
> +++ b/drivers/char/agp/intel-gtt.c
> @@ -80,7 +80,7 @@ static struct _intel_private {
> unsigned int needs_dmar : 1;
> phys_addr_t gma_bus_addr;
> /* Size of memory reserved for graphics by the BIOS */
> - unsigned int stolen_size;
> + size_t stolen_size;
What is size_t? How does that correspond to a physical or dma addr?
You either meant kernel_size_t or unsigned long, or a proper type for
the address space.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: use size_t instead of u32 for stolen memory size variables
Quoting Paulo Zanoni (2017-09-26 20:29:08) > Stolen memory pointers are dma_addr_t, which means they can be 64 bit > things. By using u32 we leave room for bugs in case we ever get huge > amounts of stolen memory. By using size_t we don't risk running into > those problems. What platform? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: stolen_reserved_base is also dma_addr_t
Quoting Paulo Zanoni (2017-09-26 20:29:07)
> The chunk added by this patch was missed by these commits:
> * 920bcd1820a6 ("drm/i915: make i915_stolen_to_physical() return phys_addr_t")
> * c88473878d47 ("drm/i915: Treat stolen memory as DMA addresses")
>
> The stolen_reserved_base variable contains a memory address for stolen
> memory and our code uses dma_addr_t for pointers to stolen, so it
> makes sense to make it also be dma_addr_t. Notice that the local
> variable inside i915_gem_init_stolen() that stores this pointer is
> even already dma_addr_t.
>
> This change essentially converts the size to 64 bits where applicable,
> making sure things work in case we ever get crazy enough to put stolen
> that far in memory.
It's defined as residing in the low 4G. Do you have a platform in mind?
-Chris
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for lib: Ask the kernel to quiescent the GPU
Quoting Patchwork (2017-09-26 19:13:26) > == Series Details == > > Series: lib: Ask the kernel to quiescent the GPU > URL : https://patchwork.freedesktop.org/series/30890/ > State : failure > > == Summary == > > IGT patchset tested on top of latest successful build > 2885b10f99b4beeb046e75af8b8488c229f629d3 igt/gem_exec_schedule: Ignore > set-priority failures on old kernels > > with latest DRM-Tip kernel build CI_DRM_3140 > c4c623d58e38 drm-tip: 2017y-09m-26d-16h-37m-12s UTC integration manifest > > Test chamelium: > Subgroup dp-crc-fast: > pass -> FAIL (fi-kbl-7500u) fdo#102514 > Test gem_sync: > Subgroup basic-all: > pass -> DMESG-FAIL (fi-blb-e6850) > pass -> DMESG-FAIL (fi-pnv-d510) > Test gem_workarounds: > Subgroup basic-read: > pass -> FAIL (fi-bdw-5557u) > pass -> FAIL (fi-bdw-gvtdvm) > pass -> FAIL (fi-bsw-n3050) > pass -> FAIL (fi-skl-6700k) > pass -> FAIL (fi-skl-6770hq) > pass -> FAIL (fi-skl-gvtdvm) > pass -> FAIL (fi-bxt-j4205) > pass -> FAIL (fi-kbl-7500u) > pass -> FAIL (fi-kbl-7560u) > pass -> FAIL (fi-kbl-r) > pass -> FAIL (fi-glk-1) > pass -> FAIL (fi-cfl-s) It is using quiescent_gpu to load a context. Abuse of the old implementation. Furthermore the test is bogus, since it should be executing those reads from inside the context. But we've known that since its inception. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix SSEU Device Status.
On Fri, Sep 22, 2017 at 06:32:04PM +, Rodrigo Vivi wrote:
> On Fri, Sep 22, 2017 at 04:44:38PM +, Oscar Mateo wrote:
> >
> >
> > On 09/22/2017 06:15 AM, Rodrigo Vivi wrote:
> > > CNL adds an extra register for slice/subslice information.
> > > Although no SKU is planed with an extra slice let's already
> > > handle this extra piece of information so we don't have the
> > > risk in future of getting a part that might have chosen this
> > > part of the die instead of other slices or anything like that.
> > >
> > > Also if subslice is disabled the information of eu ack for that
> > > is garbage, so let's skip checks for eu if subslice is disabled
> > > as we skip the subslice if slice is disabled.
> > >
> > > The rest is pretty much like gen9.
> > >
> > > v2: Remove IS_CANNONLAKE from gen9 status function.
> > >
> > > v3: Consider s_max = 6 and ss_max=4 to run over all possible
> > > slices and subslices possible by spec. Although no real
> > > hardware will have that many slices/subslices.
> > > To match with sseu info init.
> > > v4: Fix offset calculation for slices 4 and 5.
> > > Removed Oscar's rv-b since this change also needs review.
> > >
> > > Cc: Oscar Mateo
> > > Signed-off-by: Rodrigo Vivi
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 54
> > > +++--
> > > drivers/gpu/drm/i915/i915_reg.h | 6 +
> > > 2 files changed, 58 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index ca6fa6d122c6..e197e5d99277 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -4575,6 +4575,54 @@ static void cherryview_sseu_device_status(struct
> > > drm_i915_private *dev_priv,
> > > }
> > > }
> > > +static void gen10_sseu_device_status(struct drm_i915_private *dev_priv,
> > > + struct sseu_dev_info *sseu)
> > > +{
> > > + const struct intel_device_info *info = INTEL_INFO(dev_priv);
> > > + int s_max = 6, ss_max = 4;
> > > + int s, ss;
> > > + u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
> > > +
> > > + for (s = 0; s < s_max; s++) {
> > > + s_reg[s] = I915_READ(GEN10_SLICE_PGCTL_ACK(s));
> > > + eu_reg[2 * s] = I915_READ(GEN10_SS01_EU_PGCTL_ACK(s));
> > > + eu_reg[2 * s + 1] = I915_READ(GEN10_SS23_EU_PGCTL_ACK(s));
> > > + }
> > > +
> > > + eu_mask[0] = GEN9_PGCTL_SSA_EU08_ACK |
> > > + GEN9_PGCTL_SSA_EU19_ACK |
> > > + GEN9_PGCTL_SSA_EU210_ACK |
> > > + GEN9_PGCTL_SSA_EU311_ACK;
> > > + eu_mask[1] = GEN9_PGCTL_SSB_EU08_ACK |
> > > + GEN9_PGCTL_SSB_EU19_ACK |
> > > + GEN9_PGCTL_SSB_EU210_ACK |
> > > + GEN9_PGCTL_SSB_EU311_ACK;
> > > +
> > > + for (s = 0; s < s_max; s++) {
> > > + if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
> > > + /* skip disabled slice */
> > > + continue;
> > > +
> > > + sseu->slice_mask |= BIT(s);
> > > + sseu->subslice_mask = info->sseu.subslice_mask;
> > > +
> > > + for (ss = 0; ss < ss_max; ss++) {
> > > + unsigned int eu_cnt;
> > > +
> > > + if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
> > > + /* skip disabled subslice */
> > > + continue;
> >
> > You are going to hate me, but I found something else:
>
> Should I hate you for being a good reviewer? ;)
> You should hate me for not noticing that before...
> Thanks a lot for the patience
>
> >
> > SLICE0_PGCTL_ACK has powergate acknowledge bits for subslices 0, 1 & 2, but
> > not for subslice 3
> > SLICEn_PGCTL_ACK (where n = 1-5) has powergate acknowledge bits for
> > subslices 0 & 1, but not for subslices 2 & 3
>
> hmmm... :(
> I will check...
>
> >
> > I have no idea where the missing bits went (maybe the BSpec is wrong?).
>
> Do you know anyone at your end that could help us to clarify that?
Based on the emails it seems that it is a spec bug. But we are
not going to merge this patch 2/2 while we don't get the official confirmation.
Meanwhile we need the first patch for userspace, so
I merged the first patch on dinq while we solve this mistery.
Thanks for all the reviews.
>
> Thanks,
> Rodrigo.
>
> >
> > > +
> > > + eu_cnt = 2 * hweight32(eu_reg[2 * s + ss / 2] &
> > > +eu_mask[ss % 2]);
> > > + sseu->eu_total += eu_cnt;
> > > + sseu->eu_per_subslice = max_t(unsigned int,
> > > + sseu->eu_per_subslice,
> > > + eu_cnt);
> > > + }
> > > + }
> > > +}
> > > +
> > > static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
> > > struct sseu_dev_info *sseu)
> > > {
> > > @@ -46
Re: [Intel-gfx] [PATCH 7/8] drm/i915/pmu: Wire up engine busy stats to PMU
Quoting Tvrtko Ursulin (2017-09-26 13:32:25) > > On 25/09/2017 18:48, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2017-09-25 16:15:42) > >> From: Tvrtko Ursulin > >> > >> We can use engine busy stats instead of the MMIO sampling timer > >> for better efficiency. > >> > >> As minimum this saves period * num_engines / sec mmio reads, > >> and in a better case, when only engine busy samplers are active, > >> it enables us to not kick off the sampling timer at all. > > > > Or you could inspect port_isset(execlists.port). > > You can avoid the mmio for this case also by just using HWSP. It's just > > that I never enabled busy tracking in isolation, so I always ended up > > using the mmio. > > This would be for execlists only. I could change the main patch to do > this, you think it is worth it? I'm thinking we do the busy = last_seqno != current_seqno approach for the first patch. Then this patch is purely about the accuracy improvement for execlists, taking advantage of the existing interrupts. We could do something similar by forcing the user interrupt and treating that as context-out, likely to be much more fiddly than execlists and those processors did not take kindly to a flood of interrupts from the gpu. (Or that may just be a side-effect of the interrupt handler from a few years ago.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915/pmu: Wire up engine busy stats to PMU
Quoting Rogozhkin, Dmitry V (2017-09-26 19:46:48) > On Tue, 2017-09-26 at 13:32 +0100, Tvrtko Ursulin wrote: > > On 25/09/2017 18:48, Chris Wilson wrote: > > > Quoting Tvrtko Ursulin (2017-09-25 16:15:42) > > >> From: Tvrtko Ursulin > > >> > > >> We can use engine busy stats instead of the MMIO sampling timer > > >> for better efficiency. > > >> > > >> As minimum this saves period * num_engines / sec mmio reads, > > >> and in a better case, when only engine busy samplers are active, > > >> it enables us to not kick off the sampling timer at all. > > > > > > Or you could inspect port_isset(execlists.port). > > > You can avoid the mmio for this case also by just using HWSP. It's just > > > that I never enabled busy tracking in isolation, so I always ended up > > > using the mmio. > > > > This would be for execlists only. I could change the main patch to do > > this, you think it is worth it? > > You know, I wonder why we limit this by execlists? Because there's only one ringbuffer for legacy and we don't virtualise the contexts to have distinct buffers onto which we build the different execlists. It's not impossible to emulate execlists on top; the only win would be to remove the sema interengine waits (and external waits) and replace them with cpu waits, unblocking the pipeline. Reducing ringbuffer to execlist performance isn't appealing however. > Is that because > scheduler is working only for execlists and doesn't work for ringbuffers > on older HW? But consider the following. If we don't have a scheduler, > then we have FIFO queue and either hw semaphore or sw sync. For the > userspace applications real execution and wait are not actually > distinguishable: for him engine is busy, it either executes or it is > stalled and can't execute anything else, thus - it is busy. I've used the sema stall notification to reduce said stalls and allow greater parallelism, knowing that they are caused by inter-engine dependencies. The question is whether knowing e.g. global statistics on the number of requests waiting for external fences is interesting, or just the runnable length. For the application, the question is more or less what is the length of the dependency for this batch -- how early can I expect this to run? Such questions will vary based on the scheduler policy. > From this perspective we can consider to extend what we do currently for > execlists to cover FIFO ringbuffers. You mean how to extend the ringbuffer counters to cover execlists, and beyond. > How do you think? Other metrics > like SEMA or WAIT would be second level of details and will mean > distribution of BUSY time: we spent SEMA time on semaphore or WAIT time > on the wait and actively ran something BUSY-SEMA(WAIT) time. That's what they mean currently (and how I tried to display them in overlay). > By the way, with the BDW+ and execlists, is my understanding right that > we report WAIT metric and SEMA is always 0? WAIT is still used under execlists. SEMA I'm hopping that MI_SEMA_WAIT | POLL results in the RING_CTL bit being asserted, that will be useful for Vulkan, for example. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: stolen_reserved_base is also dma_addr_t
== Series Details == Series: series starting with [1/2] drm/i915: stolen_reserved_base is also dma_addr_t URL : https://patchwork.freedesktop.org/series/30923/ State : success == Summary == Series 30923v1 series starting with [1/2] drm/i915: stolen_reserved_base is also dma_addr_t https://patchwork.freedesktop.org/api/1.0/series/30923/revisions/1/mbox/ Test chamelium: Subgroup dp-crc-fast: pass -> FAIL (fi-kbl-7500u) fdo#102514 Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (fi-cfl-s) fdo#102294 Test drv_module_reload: Subgroup basic-reload-inject: pass -> DMESG-WARN (fi-glk-1) fdo#102777 fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:441s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:470s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:416s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:513s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:496s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:494s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:494s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:539s fi-cnl-y total:289 pass:256 dwarn:0 dfail:0 fail:6 skip:27 time:652s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:413s fi-glk-1 total:289 pass:259 dwarn:1 dfail:0 fail:0 skip:29 time:562s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:424s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:404s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:433s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:490s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:461s fi-kbl-7500u total:289 pass:263 dwarn:1 dfail:0 fail:1 skip:24 time:459s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:575s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:591s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:546s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:458s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:754s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:491s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:473s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:567s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:413s c4c623d58e38d49e692dc9141250b35e39170e6b drm-tip: 2017y-09m-26d-16h-37m-12s UTC integration manifest 104afd136698 drm/i915: use size_t instead of u32 for stolen memory size variables 4d7c08ff drm/i915: stolen_reserved_base is also dma_addr_t == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5824/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Allow 2 pixel per clock on Cannonlake.
On Tue, Sep 26, 2017 at 12:43 PM, Rodrigo Vivi wrote:
> This is heavily based on a initial patch provided by Ville
> plus all changes provided later by Ander.
>
> As Geminilake, Cannonlake also supports 2 pixels per clock.
>
> Different from Geminilake we are not implementing the 99% Wa.
> But we can revisit that decision later if we find out
> any limitation on later CNL SKUs.
>
> v2: Rebase on top of commit 'd305e0614601 ("drm/i915: Track
> minimum acceptable cdclk instead of "minimum dotclock")'
>
> Cc: Paulo Zanoni
> Cc: Ville Syrjälä
> Cc: Dhinakaran Pandiyan
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_cdclk.c | 7 +--
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 3 ++-
> 3 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index d6befabd6ed5..eabaf57b83ef 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1995,12 +1995,7 @@ static int intel_compute_max_dotclk(struct
> drm_i915_private *dev_priv)
> int max_cdclk_freq = dev_priv->max_cdclk_freq;
>
> if (INTEL_GEN(dev_priv) >= 10)
> - /*
> -* FIXME: Allow '2 * max_cdclk_freq'
> -* once DDI clock voltage requirements are
> -* handled correctly.
> -*/
this actually depends on https://patchwork.freedesktop.org/series/30922/
So I will probably resend this after that patch is merged, but I'd
appreciate early reviews.
> - return max_cdclk_freq;
> + return 2 * max_cdclk_freq;
> else if (IS_GEMINILAKE(dev_priv))
> /*
> * FIXME: Limiting to 99% as a temporary workaround. See
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 026fa5460fe5..487b43ba3139 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12801,7 +12801,7 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct
> intel_crtc_state *crtc_state
> crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
> max_dotclk =
> to_intel_atomic_state(crtc_state->base.state)->cdclk.logical.cdclk;
>
> - if (IS_GEMINILAKE(dev_priv))
> + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> max_dotclk *= 2;
>
> if (WARN_ON_ONCE(!crtc_clock || max_dotclk < crtc_clock))
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index c66af09e27a7..52c4c194aa51 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3932,6 +3932,7 @@ skl_pipe_downscale_amount(const struct intel_crtc_state
> *crtc_state)
> int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
> struct intel_crtc_state *cstate)
> {
> + struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> struct drm_crtc_state *crtc_state = &cstate->base;
> struct drm_atomic_state *state = crtc_state->state;
> struct drm_plane *plane;
> @@ -3974,7 +3975,7 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc
> *intel_crtc,
> crtc_clock = crtc_state->adjusted_mode.crtc_clock;
> dotclk = to_intel_atomic_state(state)->cdclk.logical.cdclk;
>
> - if (IS_GEMINILAKE(to_i915(intel_crtc->base.dev)))
> + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> dotclk *= 2;
>
> pipe_max_pixel_rate = div_round_up_u32_fixed16(dotclk,
> pipe_downscale);
> --
> 2.13.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/cnl: Allow 2 pixel per clock on Cannonlake.
This is heavily based on a initial patch provided by Ville
plus all changes provided later by Ander.
As Geminilake, Cannonlake also supports 2 pixels per clock.
Different from Geminilake we are not implementing the 99% Wa.
But we can revisit that decision later if we find out
any limitation on later CNL SKUs.
v2: Rebase on top of commit 'd305e0614601 ("drm/i915: Track
minimum acceptable cdclk instead of "minimum dotclock")'
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Cc: Dhinakaran Pandiyan
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_cdclk.c | 7 +--
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index d6befabd6ed5..eabaf57b83ef 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1995,12 +1995,7 @@ static int intel_compute_max_dotclk(struct
drm_i915_private *dev_priv)
int max_cdclk_freq = dev_priv->max_cdclk_freq;
if (INTEL_GEN(dev_priv) >= 10)
- /*
-* FIXME: Allow '2 * max_cdclk_freq'
-* once DDI clock voltage requirements are
-* handled correctly.
-*/
- return max_cdclk_freq;
+ return 2 * max_cdclk_freq;
else if (IS_GEMINILAKE(dev_priv))
/*
* FIXME: Limiting to 99% as a temporary workaround. See
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 026fa5460fe5..487b43ba3139 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12801,7 +12801,7 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct
intel_crtc_state *crtc_state
crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
max_dotclk =
to_intel_atomic_state(crtc_state->base.state)->cdclk.logical.cdclk;
- if (IS_GEMINILAKE(dev_priv))
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
max_dotclk *= 2;
if (WARN_ON_ONCE(!crtc_clock || max_dotclk < crtc_clock))
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c66af09e27a7..52c4c194aa51 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3932,6 +3932,7 @@ skl_pipe_downscale_amount(const struct intel_crtc_state
*crtc_state)
int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
struct intel_crtc_state *cstate)
{
+ struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
struct drm_crtc_state *crtc_state = &cstate->base;
struct drm_atomic_state *state = crtc_state->state;
struct drm_plane *plane;
@@ -3974,7 +3975,7 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc
*intel_crtc,
crtc_clock = crtc_state->adjusted_mode.crtc_clock;
dotclk = to_intel_atomic_state(state)->cdclk.logical.cdclk;
- if (IS_GEMINILAKE(to_i915(intel_crtc->base.dev)))
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
dotclk *= 2;
pipe_max_pixel_rate = div_round_up_u32_fixed16(dotclk, pipe_downscale);
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce DVFS.
== Series Details ==
Series: Introduce DVFS.
URL : https://patchwork.freedesktop.org/series/30922/
State : success
== Summary ==
Series 30922v1 Introduce DVFS.
https://patchwork.freedesktop.org/api/1.0/series/30922/revisions/1/mbox/
Test drv_module_reload:
Subgroup basic-reload-inject:
pass -> DMESG-WARN (fi-glk-1) fdo#102777
fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777
fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21
time:443s
fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24
time:480s
fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64
time:421s
fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46
time:538s
fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105
time:279s
fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29
time:503s
fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34
time:505s
fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38
time:497s
fi-cfl-s total:289 pass:222 dwarn:35 dfail:0 fail:0 skip:32
time:539s
fi-cnl-y total:289 pass:208 dwarn:12 dfail:31 fail:6 skip:31
time:652s
fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59
time:424s
fi-glk-1 total:289 pass:259 dwarn:1 dfail:0 fail:0 skip:29
time:569s
fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26
time:427s
fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26
time:406s
fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60
time:440s
fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28
time:491s
fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28
time:465s
fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24
time:478s
fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19
time:578s
fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27
time:592s
fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65
time:547s
fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20
time:455s
fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24
time:761s
fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20
time:495s
fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23
time:480s
fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38
time:571s
fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39
time:421s
c4c623d58e38d49e692dc9141250b35e39170e6b drm-tip: 2017y-09m-26d-16h-37m-12s UTC
integration manifest
6dd2e3d2f1dc drm/i915: Extend DVFS function back to Skylake.
0b6ee028eacd drm/i915/cnl: DVFS for PLL disabling
d53bc8bce9dc drm/i915/cnl: DVFS for PLL enabling
5f4344381ec4 drm/i915/cnl: Expose DVFS change functions
efb033fbb119 drm/i915/cnl: extract cnl_dvfs_{pre, post}_change
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5823/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: use size_t instead of u32 for stolen memory size variables
Stolen memory pointers are dma_addr_t, which means they can be 64 bit
things. By using u32 we leave room for bugs in case we ever get huge
amounts of stolen memory. By using size_t we don't risk running into
those problems.
Cc: Chris Wilson
Signed-off-by: Paulo Zanoni
---
drivers/char/agp/intel-gtt.c | 10 +-
drivers/gpu/drm/i915/i915_gem_gtt.c| 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.h| 6 +++---
drivers/gpu/drm/i915/i915_gem_stolen.c | 19 +--
include/drm/intel-gtt.h| 2 +-
5 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 9b6b602..a1db230 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -80,7 +80,7 @@ static struct _intel_private {
unsigned int needs_dmar : 1;
phys_addr_t gma_bus_addr;
/* Size of memory reserved for graphics by the BIOS */
- unsigned int stolen_size;
+ size_t stolen_size;
/* Total number of gtt entries. */
unsigned int gtt_total_entries;
/* Part of the gtt that is mappable by the cpu, for those chips where
@@ -333,13 +333,13 @@ static void i810_write_entry(dma_addr_t addr, unsigned
int entry,
writel_relaxed(addr | pte_flags, intel_private.gtt + entry);
}
-static unsigned int intel_gtt_stolen_size(void)
+static size_t intel_gtt_stolen_size(void)
{
u16 gmch_ctrl;
u8 rdct;
int local = 0;
static const int ddt[4] = { 0, 16, 32, 64 };
- unsigned int stolen_size = 0;
+ size_t stolen_size = 0;
if (INTEL_GTT_GEN == 1)
return 0; /* no stolen mem on i81x */
@@ -417,7 +417,7 @@ static unsigned int intel_gtt_stolen_size(void)
}
if (stolen_size > 0) {
- dev_info(&intel_private.bridge_dev->dev, "detected %dK %s
memory\n",
+ dev_info(&intel_private.bridge_dev->dev, "detected %zuK %s
memory\n",
stolen_size / KB(1), local ? "local" : "stolen");
} else {
dev_info(&intel_private.bridge_dev->dev,
@@ -1422,7 +1422,7 @@ int intel_gmch_probe(struct pci_dev *bridge_pdev, struct
pci_dev *gpu_pdev,
EXPORT_SYMBOL(intel_gmch_probe);
void intel_gtt_get(u64 *gtt_total,
- u32 *stolen_size,
+ size_t *stolen_size,
phys_addr_t *mappable_base,
u64 *mappable_end)
{
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 64d7852..733fbff 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3316,7 +3316,7 @@ int i915_ggtt_probe_hw(struct drm_i915_private *dev_priv)
DRM_INFO("Memory usable by graphics device = %lluM\n",
ggtt->base.total >> 20);
DRM_DEBUG_DRIVER("GMADR size = %lldM\n", ggtt->mappable_end >> 20);
- DRM_DEBUG_DRIVER("GTT stolen size = %uM\n", ggtt->stolen_size >> 20);
+ DRM_DEBUG_DRIVER("GTT stolen size = %zuM\n", ggtt->stolen_size >> 20);
if (intel_vtd_active())
DRM_INFO("VT-d active for gfx access\n");
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index dd2ef5b..d0356be7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -363,10 +363,10 @@ struct i915_ggtt {
* avoid the first page! The upper end of stolen memory is reserved for
* hardware functions and similarly removed from the accessible range.
*/
- u32 stolen_size;/* Total size of stolen memory */
- u32 stolen_usable_size; /* Total size minus reserved ranges */
+ size_t stolen_size; /* Total size of stolen memory */
+ size_t stolen_usable_size; /* Total size minus reserved ranges */
dma_addr_t stolen_reserved_base;
- u32 stolen_reserved_size;
+ size_t stolen_reserved_size;
/** "Graphics Stolen Memory" holds the global PTEs */
void __iomem *gsm;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 507c9f0..7c9913a 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -286,7 +286,7 @@ void i915_gem_cleanup_stolen(struct drm_device *dev)
}
static void g4x_get_stolen_reserved(struct drm_i915_private *dev_priv,
- dma_addr_t *base, u32 *size)
+ dma_addr_t *base, size_t *size)
{
struct i915_ggtt *ggtt = &dev_priv->ggtt;
uint32_t reg_val = I915_READ(IS_GM45(dev_priv) ?
@@ -309,7 +309,7 @@ static void g4x_get_stolen_reserved(struct drm_i915_private
*dev_priv,
}
static void gen6_get_stolen_reserved(struct drm_i915_private *dev_priv,
-dma_addr_t *base, u32 *size)
+dma_addr_t *ba
[Intel-gfx] [PATCH 1/2] drm/i915: stolen_reserved_base is also dma_addr_t
The chunk added by this patch was missed by these commits:
* 920bcd1820a6 ("drm/i915: make i915_stolen_to_physical() return phys_addr_t")
* c88473878d47 ("drm/i915: Treat stolen memory as DMA addresses")
The stolen_reserved_base variable contains a memory address for stolen
memory and our code uses dma_addr_t for pointers to stolen, so it
makes sense to make it also be dma_addr_t. Notice that the local
variable inside i915_gem_init_stolen() that stores this pointer is
even already dma_addr_t.
This change essentially converts the size to 64 bits where applicable,
making sure things work in case we ever get crazy enough to put stolen
that far in memory.
Cc: Chris Wilson
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index f62fb90..dd2ef5b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -365,7 +365,7 @@ struct i915_ggtt {
*/
u32 stolen_size;/* Total size of stolen memory */
u32 stolen_usable_size; /* Total size minus reserved ranges */
- u32 stolen_reserved_base;
+ dma_addr_t stolen_reserved_base;
u32 stolen_reserved_size;
/** "Graphics Stolen Memory" holds the global PTEs */
--
2.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] Introduce DVFS.
This Display Voltage and Frequency Switching Sequence
exist for a while, but now on CNL it got a separated doc in spec
and more attention since it is required to be called for more places.
So this series from Paulo and mostly from Mika addresses the changes
required specially for CNL.
Last patch in the series is optional and only aims to avoid code
duplication on SKL code. I know that this could be the first thing
in the series or squashed to Paulo's initial patch, but since this
is optional and I didn't wan't to disrupt and change the original
code from Paulo and Mika, I decided to do as the last patch on top
of their original work.
Thanks,
Rodrigo.
Kahola, Mika (3):
drm/i915/cnl: Expose DVFS change functions
drm/i915/cnl: DVFS for PLL enabling
drm/i915/cnl: DVFS for PLL disabling
Paulo Zanoni (1):
drm/i915/cnl: extract cnl_dvfs_{pre,post}_change
Rodrigo Vivi (1):
drm/i915: Extend DVFS function back to Skylake.
drivers/gpu/drm/i915/intel_cdclk.c| 50
drivers/gpu/drm/i915/intel_dpll_mgr.c | 71 +++
drivers/gpu/drm/i915/intel_drv.h | 2 +
3 files changed, 82 insertions(+), 41 deletions(-)
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Extend DVFS function back to Skylake.
Although SKL Spec doesn't explicit call this sequence
as DVFS, that is exactly what it is.
So let's remove a bit of code duplication and re-use
CNL functions.
No functional change.
Cc: Ville Syrjälä
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_cdclk.c| 25 ++---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 8
drivers/gpu/drm/i915/intel_drv.h | 4 ++--
3 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 86ef4d0add70..d6befabd6ed5 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -924,21 +924,10 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv,
int cdclk = cdclk_state->cdclk;
int vco = cdclk_state->vco;
u32 freq_select, pcu_ack;
- int ret;
WARN_ON((cdclk == 24000) != (vco == 0));
- mutex_lock(&dev_priv->rps.hw_lock);
- ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
- SKL_CDCLK_PREPARE_FOR_CHANGE,
- SKL_CDCLK_READY_FOR_CHANGE,
- SKL_CDCLK_READY_FOR_CHANGE, 3);
- mutex_unlock(&dev_priv->rps.hw_lock);
- if (ret) {
- DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
- ret);
- return;
- }
+ skl_dvfs_pre_change(dev_priv);
/* set CDCLK_CTL */
switch (cdclk) {
@@ -975,9 +964,7 @@ static void skl_set_cdclk(struct drm_i915_private *dev_priv,
POSTING_READ(CDCLK_CTL);
/* inform PCU of the change */
- mutex_lock(&dev_priv->rps.hw_lock);
- sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, pcu_ack);
- mutex_unlock(&dev_priv->rps.hw_lock);
+ skl_dvfs_post_change(dev_priv, pcu_ack);
intel_update_cdclk(dev_priv);
}
@@ -1510,7 +1497,7 @@ static void cnl_cdclk_pll_enable(struct drm_i915_private
*dev_priv, int vco)
dev_priv->cdclk.hw.vco = vco;
}
-int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv)
+int skl_dvfs_pre_change(struct drm_i915_private *dev_priv)
{
int ret;
@@ -1528,7 +1515,7 @@ int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv)
return ret;
}
-void cnl_dvfs_post_change(struct drm_i915_private *dev_priv, int level)
+void skl_dvfs_post_change(struct drm_i915_private *dev_priv, int level)
{
mutex_lock(&dev_priv->rps.hw_lock);
sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, level);
@@ -1542,7 +1529,7 @@ static void cnl_set_cdclk(struct drm_i915_private
*dev_priv,
int vco = cdclk_state->vco;
u32 val, divider, pcu_ack;
- if (!cnl_dvfs_pre_change(dev_priv))
+ if (!skl_dvfs_pre_change(dev_priv))
return;
/* cdclk = vco / 2 / div{1,2} */
@@ -1590,7 +1577,7 @@ static void cnl_set_cdclk(struct drm_i915_private
*dev_priv,
I915_WRITE(CDCLK_CTL, val);
/* inform PCU of the change */
- cnl_dvfs_post_change(dev_priv, pcu_ack);
+ skl_dvfs_post_change(dev_priv, pcu_ack);
intel_update_cdclk(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index cc288534dcc6..c08ca8f03e90 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2046,7 +2046,7 @@ static void cnl_ddi_pll_enable(struct drm_i915_private
*dev_priv,
* requirement, follow the Display Voltage Frequency Switching
* (DVFS) Sequence Before Frequency Change
*/
- ret = cnl_dvfs_pre_change(dev_priv);
+ ret = skl_dvfs_pre_change(dev_priv);
/* 6. Enable DPLL in DPLL_ENABLE. */
val = I915_READ(CNL_DPLL_ENABLE(pll->id));
@@ -2072,7 +2072,7 @@ static void cnl_ddi_pll_enable(struct drm_i915_private
*dev_priv,
portclk = cnl_get_port_clock(val);
level = cnl_get_dvfs_level(cdclk, portclk);
- cnl_dvfs_post_change(dev_priv, level);
+ skl_dvfs_post_change(dev_priv, level);
}
/*
@@ -2097,7 +2097,7 @@ static void cnl_ddi_pll_disable(struct drm_i915_private
*dev_priv,
* requirement, follow the Display Voltage Frequency Switching
* (DVFS) Sequence Before Frequency Change
*/
- ret = cnl_dvfs_pre_change(dev_priv);
+ ret = skl_dvfs_pre_change(dev_priv);
/* 3. Disable DPLL through DPLL_ENABLE. */
val = I915_READ(CNL_DPLL_ENABLE(pll->id));
@@ -2118,7 +2118,7 @@ static void cnl_ddi_pll_disable(struct drm_i915_private
*dev_priv,
* (DVFS) Sequence After Frequency Change
*/
if (ret == 0)
- cnl_dvfs_post_change(dev_priv, 0);
+ skl_dvfs_post_change(dev_priv, 0);
/* 6. Disable DPLL power in DPLL_ENABLE. */
val = I915_READ(CNL_DPLL_ENABLE(pll->id))
[Intel-gfx] [PATCH 1/5] drm/i915/cnl: extract cnl_dvfs_{pre, post}_change
From: Paulo Zanoni
These functions even have their own page in our spec,
so extract them from cnl_set_cdclk().
Cc: Ville Syrjälä
Signed-off-by: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_cdclk.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 87fc42b19336..a7f3e4615a44 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1510,12 +1510,8 @@ static void cnl_cdclk_pll_enable(struct drm_i915_private
*dev_priv, int vco)
dev_priv->cdclk.hw.vco = vco;
}
-static void cnl_set_cdclk(struct drm_i915_private *dev_priv,
- const struct intel_cdclk_state *cdclk_state)
+static int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv)
{
- int cdclk = cdclk_state->cdclk;
- int vco = cdclk_state->vco;
- u32 val, divider, pcu_ack;
int ret;
mutex_lock(&dev_priv->rps.hw_lock);
@@ -1524,11 +1520,30 @@ static void cnl_set_cdclk(struct drm_i915_private
*dev_priv,
SKL_CDCLK_READY_FOR_CHANGE,
SKL_CDCLK_READY_FOR_CHANGE, 3);
mutex_unlock(&dev_priv->rps.hw_lock);
- if (ret) {
+
+ if (ret)
DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
ret);
+
+ return ret;
+}
+
+static void cnl_dvfs_post_change(struct drm_i915_private *dev_priv, int level)
+{
+ mutex_lock(&dev_priv->rps.hw_lock);
+ sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, level);
+ mutex_unlock(&dev_priv->rps.hw_lock);
+}
+
+static void cnl_set_cdclk(struct drm_i915_private *dev_priv,
+ const struct intel_cdclk_state *cdclk_state)
+{
+ int cdclk = cdclk_state->cdclk;
+ int vco = cdclk_state->vco;
+ u32 val, divider, pcu_ack;
+
+ if (!cnl_dvfs_pre_change(dev_priv))
return;
- }
/* cdclk = vco / 2 / div{1,2} */
switch (DIV_ROUND_CLOSEST(vco, cdclk)) {
@@ -1575,9 +1590,7 @@ static void cnl_set_cdclk(struct drm_i915_private
*dev_priv,
I915_WRITE(CDCLK_CTL, val);
/* inform PCU of the change */
- mutex_lock(&dev_priv->rps.hw_lock);
- sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, pcu_ack);
- mutex_unlock(&dev_priv->rps.hw_lock);
+ cnl_dvfs_post_change(dev_priv, pcu_ack);
intel_update_cdclk(dev_priv);
}
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915/cnl: Expose DVFS change functions
From: "Kahola, Mika"
DVFS computation needs cnl_dvfs_{pre,post}_change() functions to be exposed.
These functions will be used when computing DVFS levels in intel_dpll_mgr.c
Cc: Ville Syrjälä
Signed-off-by: Kahola, Mika
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_cdclk.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index a7f3e4615a44..86ef4d0add70 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1510,7 +1510,7 @@ static void cnl_cdclk_pll_enable(struct drm_i915_private
*dev_priv, int vco)
dev_priv->cdclk.hw.vco = vco;
}
-static int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv)
+int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv)
{
int ret;
@@ -1528,7 +1528,7 @@ static int cnl_dvfs_pre_change(struct drm_i915_private
*dev_priv)
return ret;
}
-static void cnl_dvfs_post_change(struct drm_i915_private *dev_priv, int level)
+void cnl_dvfs_post_change(struct drm_i915_private *dev_priv, int level)
{
mutex_lock(&dev_priv->rps.hw_lock);
sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, level);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0cab667fff57..f9d7b48584d3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1322,6 +1322,8 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv);
void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
void cnl_init_cdclk(struct drm_i915_private *dev_priv);
void cnl_uninit_cdclk(struct drm_i915_private *dev_priv);
+int cnl_dvfs_pre_change(struct drm_i915_private *dev_priv);
+void cnl_dvfs_post_change(struct drm_i915_private *dev_priv, int level);
void bxt_init_cdclk(struct drm_i915_private *dev_priv);
void bxt_uninit_cdclk(struct drm_i915_private *dev_priv);
void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv);
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915/cnl: DVFS for PLL enabling
From: "Kahola, Mika"
Display Voltage and Frequency Switching (DVFS) is used to adjust the
display voltage to match the display clock frequencies. If voltage is
set too low, it will break functionality. If voltage is set too high,
it will waste power. Voltage level is selected based on CD clock and
DDI clock.
The sequence before frequency change is the following and it requests
the power controller to raise voltage to maximum
- Ensure any previous GT Driver Mailbox transaction is complete.
- Write GT Driver Mailbox Data Low = 0x3.
- Write GT Driver Mailbox Data High = 0x0.
- Write GT Driver Mailbox Interface = 0x8007.
- Poll GT Driver Mailbox Interface for Run/Busy indication cleared (bit 31 = 0).
- Read GT Driver Mailbox Data Low, if bit 0 is 0x1, continue, else restart the
sequence.
Timeout after 3ms
The sequence after frequency change is the following and it requests
the port controller to raise voltage to the requested level.
- Write GT Driver Mailbox Data Low
* For level 0, write 0x0
* For level 1, write 0x1
* For level 2, write 0x2
* For level 3, write 0x3
- Write GT Driver Mailbox Data High = 0x0.
- Write GT Driver Mailbox Interface = 0x8007.
For Cannonlake, the level 3 is not used and it aliases to level 2.
v2: reuse Paulo's work on cdclk. This patch depends on Paulo's patch
[PATCH 02/12] drm/i915/cnl: extract cnl_dvfs_{pre,post}_change
v3: (By Rodrigo): Remove duplicated commend and fix typo on Paulo's name.
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Signed-off-by: Kahola, Mika
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 57 ++-
1 file changed, 49 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index a2a3d93d67bd..9927df6294da 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1966,10 +1966,48 @@ static const struct intel_dpll_mgr bxt_pll_mgr = {
.dump_hw_state = bxt_dump_hw_state,
};
+static int cnl_get_port_clock(uint32_t val)
+{
+ if (val & DPLL_CFGCR0_LINK_RATE_810)
+ return 2*81000;
+ else if (val & DPLL_CFGCR0_LINK_RATE_1350)
+ return 2*135000;
+ else if (val & DPLL_CFGCR0_LINK_RATE_2700)
+ return 2*27;
+ else if (val & DPLL_CFGCR0_LINK_RATE_1620)
+ return 2*162000;
+ else if (val & DPLL_CFGCR0_LINK_RATE_1080)
+ return 2*108000;
+ else if (val & DPLL_CFGCR0_LINK_RATE_2160)
+ return 2*216000;
+ else if (val & DPLL_CFGCR0_LINK_RATE_3240)
+ return 2*324000;
+ else if (val & DPLL_CFGCR0_LINK_RATE_4050)
+ return 2*405000;
+
+ return -EINVAL;
+}
+
+static int cnl_get_dvfs_level(int cdclk, int portclk)
+{
+ if (portclk == -EINVAL)
+ return 2;
+
+ if (cdclk == 168000 && portclk < 594000)
+ return 0;
+ else if (cdclk == 336000 && portclk < 594000)
+ return 1;
+ else
+ return 2;
+}
+
static void cnl_ddi_pll_enable(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll)
{
uint32_t val;
+ int ret;
+ int level;
+ int cdclk, portclk;
/* 1. Enable DPLL power in DPLL_ENABLE. */
val = I915_READ(CNL_DPLL_ENABLE(pll->id));
@@ -2006,11 +2044,9 @@ static void cnl_ddi_pll_enable(struct drm_i915_private
*dev_priv,
/*
* 5. If the frequency will result in a change to the voltage
* requirement, follow the Display Voltage Frequency Switching
-* Sequence Before Frequency Change
-*
-* FIXME: (DVFS) is used to adjust the display voltage to match the
-* display clock frequencies
+* (DVFS) Sequence Before Frequency Change
*/
+ ret = cnl_dvfs_pre_change(dev_priv);
/* 6. Enable DPLL in DPLL_ENABLE. */
val = I915_READ(CNL_DPLL_ENABLE(pll->id));
@@ -2028,11 +2064,16 @@ static void cnl_ddi_pll_enable(struct drm_i915_private
*dev_priv,
/*
* 8. If the frequency will result in a change to the voltage
* requirement, follow the Display Voltage Frequency Switching
-* Sequence After Frequency Change
-*
-* FIXME: (DVFS) is used to adjust the display voltage to match the
-* display clock frequencies
+* (DVFS) Sequence After Frequency Change
*/
+ if (ret == 0) {
+ val = pll->state.hw_state.cfgcr0;
+ cdclk = dev_priv->cdclk.hw.cdclk;
+ portclk = cnl_get_port_clock(val);
+
+ level = cnl_get_dvfs_level(cdclk, portclk);
+ cnl_dvfs_post_change(dev_priv, level);
+ }
/*
* 9. turn on the clock for the DDI and map the DPLL to the DDI
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915/cnl: DVFS for PLL disabling
From: "Kahola, Mika"
Display Voltage and Frequency Switching (DVFS) is used to adjust the
display voltage to match the display clock frequencies. To save power the
voltage is set to minimum when disabling PLL.
The sequence before frequency change is the following and it requests
the power controller to raise voltage to maximum
- Ensure any previous GT Driver Mailbox transaction is complete.
- Write GT Driver Mailbox Data Low = 0x3.
- Write GT Driver Mailbox Data High = 0x0.
- Write GT Driver Mailbox Interface = 0x8007.
- Poll GT Driver Mailbox Interface for Run/Busy indication cleared (bit 31 = 0).
- Read GT Driver Mailbox Data Low, if bit 0 is 0x1, continue, else restart the
sequence.
Timeout after 3ms
The sequence after frequency change is the following and it requests
the port controller to lower voltage to the minimum.
- Write GT Driver Mailbox Data Low = 0x0
- Write GT Driver Mailbox Data High = 0x0.
- Write GT Driver Mailbox Interface = 0x8007.
v2: reuse Paulo's work on cdclk. This patch depends on Paulo's patch
[PATCH 02/12] drm/i915/cnl: extract cnl_dvfs_{pre,post}_change
v3: (By Rodrigo): Fix typo on Paulo's name.
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Signed-off-by: Kahola, Mika
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 9927df6294da..cc288534dcc6 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2085,6 +2085,7 @@ static void cnl_ddi_pll_disable(struct drm_i915_private
*dev_priv,
struct intel_shared_dpll *pll)
{
uint32_t val;
+ int ret;
/*
* 1. Configure DPCLKA_CFGCR0 to turn off the clock for the DDI.
@@ -2094,11 +2095,9 @@ static void cnl_ddi_pll_disable(struct drm_i915_private
*dev_priv,
/*
* 2. If the frequency will result in a change to the voltage
* requirement, follow the Display Voltage Frequency Switching
-* Sequence Before Frequency Change
-*
-* FIXME: (DVFS) is used to adjust the display voltage to match the
-* display clock frequencies
+* (DVFS) Sequence Before Frequency Change
*/
+ ret = cnl_dvfs_pre_change(dev_priv);
/* 3. Disable DPLL through DPLL_ENABLE. */
val = I915_READ(CNL_DPLL_ENABLE(pll->id));
@@ -2116,11 +2115,10 @@ static void cnl_ddi_pll_disable(struct drm_i915_private
*dev_priv,
/*
* 5. If the frequency will result in a change to the voltage
* requirement, follow the Display Voltage Frequency Switching
-* Sequence After Frequency Change
-*
-* FIXME: (DVFS) is used to adjust the display voltage to match the
-* display clock frequencies
+* (DVFS) Sequence After Frequency Change
*/
+ if (ret == 0)
+ cnl_dvfs_post_change(dev_priv, 0);
/* 6. Disable DPLL power in DPLL_ENABLE. */
val = I915_READ(CNL_DPLL_ENABLE(pll->id));
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/execlists: Notify context-out for lost requests
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Notify context-out for lost requests URL : https://patchwork.freedesktop.org/series/30895/ State : success == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 +1 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2429 pass:1327 dwarn:4 dfail:0 fail:15 skip:1083 time:9946s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5816/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for lib/igt_kms: Convert properties to be more atomic-like.
== Series Details == Series: lib/igt_kms: Convert properties to be more atomic-like. URL : https://patchwork.freedesktop.org/series/30903/ State : failure == Summary == IGT patchset tested on top of latest successful build 2885b10f99b4beeb046e75af8b8488c229f629d3 igt/gem_exec_schedule: Ignore set-priority failures on old kernels with latest DRM-Tip kernel build CI_DRM_3140 c4c623d58e38 drm-tip: 2017y-09m-26d-16h-37m-12s UTC integration manifest Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: pass -> FAIL (fi-ilk-650) pass -> FAIL (fi-snb-2520m) fdo#100215 +5 pass -> FAIL (fi-skl-6700k) pass -> FAIL (fi-kbl-7500u) dmesg-warn -> FAIL (fi-cfl-s) fdo#102294 +8 Subgroup basic-busy-flip-before-cursor-legacy: pass -> FAIL (fi-ilk-650) pass -> FAIL (fi-skl-6700k) pass -> FAIL (fi-kbl-7500u) Subgroup basic-flip-after-cursor-atomic: pass -> FAIL (fi-ilk-650) pass -> FAIL (fi-skl-6700k) pass -> FAIL (fi-kbl-7500u) Subgroup basic-flip-after-cursor-legacy: pass -> FAIL (fi-ilk-650) pass -> FAIL (fi-snb-2520m) pass -> FAIL (fi-skl-6700k) pass -> FAIL (fi-skl-6770hq) pass -> FAIL (fi-kbl-7500u) Subgroup basic-flip-after-cursor-varying-size: pass -> FAIL (fi-ilk-650) pass -> FAIL (fi-snb-2520m) pass -> FAIL (fi-skl-6700k) pass -> FAIL (fi-skl-6770hq) pass -> FAIL (fi-kbl-7500u) Subgroup basic-flip-before-cursor-atomic: pass -> FAIL (fi-ilk-650) pass -> FAIL (fi-snb-2520m) pass -> FAIL (fi-skl-6700k) pass -> FAIL (fi-skl-6770hq) pass -> FAIL (fi-kbl-7500u) Subgroup basic-flip-before-cursor-legacy: pass -> FAIL (fi-ilk-650) pass -> FAIL (fi-snb-2520m) pass -> FAIL (fi-skl-6700k) pass -> FAIL (fi-skl-6770hq) pass -> FAIL (fi-kbl-7500u) Subgroup basic-flip-before-cursor-varying-size: pass -> FAIL (fi-ilk-650) pass -> FAIL (fi-snb-2520m) pass -> FAIL (fi-skl-6700k) pass -> FAIL (fi-skl-6770hq) pass -> FAIL (fi-kbl-7500u) fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:445s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:471s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:421s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:536s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:282s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:503s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:505s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:503s fi-cfl-s total:245 pass:188 dwarn:18 dfail:0 fail:8 skip:30 fi-cnl-y total:289 pass:257 dwarn:0 dfail:0 fail:5 skip:27 time:668s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:426s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:570s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:425s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:403s fi-ilk-650 total:289 pass:221 dwarn:0 dfail:0 fail:8 skip:60 time:424s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:497s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:465s fi-kbl-7500u total:289 pass:256 dwarn:1 dfail:0 fail:8 skip:24 time:461s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:582s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:589s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:544s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:462s fi-skl-6700k total:289 pass:257 d
Re: [Intel-gfx] [PATCH 7/8] drm/i915/pmu: Wire up engine busy stats to PMU
On Tue, 2017-09-26 at 13:32 +0100, Tvrtko Ursulin wrote: > On 25/09/2017 18:48, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2017-09-25 16:15:42) > >> From: Tvrtko Ursulin > >> > >> We can use engine busy stats instead of the MMIO sampling timer > >> for better efficiency. > >> > >> As minimum this saves period * num_engines / sec mmio reads, > >> and in a better case, when only engine busy samplers are active, > >> it enables us to not kick off the sampling timer at all. > > > > Or you could inspect port_isset(execlists.port). > > You can avoid the mmio for this case also by just using HWSP. It's just > > that I never enabled busy tracking in isolation, so I always ended up > > using the mmio. > > This would be for execlists only. I could change the main patch to do > this, you think it is worth it? You know, I wonder why we limit this by execlists? Is that because scheduler is working only for execlists and doesn't work for ringbuffers on older HW? But consider the following. If we don't have a scheduler, then we have FIFO queue and either hw semaphore or sw sync. For the userspace applications real execution and wait are not actually distinguishable: for him engine is busy, it either executes or it is stalled and can't execute anything else, thus - it is busy. From this perspective we can consider to extend what we do currently for execlists to cover FIFO ringbuffers. How do you think? Other metrics like SEMA or WAIT would be second level of details and will mean distribution of BUSY time: we spent SEMA time on semaphore or WAIT time on the wait and actively ran something BUSY-SEMA(WAIT) time. By the way, with the BDW+ and execlists, is my understanding right that we report WAIT metric and SEMA is always 0? > > > Stronger argument is that this method give more precise timing than > > stochastic sampling. > > > >> > >> v2: Rebase. > >> v3: > >> * Rebase, comments. > >> * Leave engine busyness controls out of workers. > >> v4: Checkpatch cleanup. > >> v5: Added comment to pmu_needs_timer change. > >> v6: > >> * Rebase. > >> * Fix style of some comments. (Chris Wilson) > >> > >> Signed-off-by: Tvrtko Ursulin > > > > With a better explanation of why this is preferred, > > Reviewed-by: Chris Wilson > > Thanks, > > Tvrtko > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_exec_scheduler: HAS_SCHEDULER no longer means HAS_PREEMPTION (rev2)
== Series Details == Series: igt/gem_exec_scheduler: HAS_SCHEDULER no longer means HAS_PREEMPTION (rev2) URL : https://patchwork.freedesktop.org/series/30860/ State : success == Summary == IGT patchset tested on top of latest successful build 2885b10f99b4beeb046e75af8b8488c229f629d3 igt/gem_exec_schedule: Ignore set-priority failures on old kernels with latest DRM-Tip kernel build CI_DRM_3140 c4c623d58e38 drm-tip: 2017y-09m-26d-16h-37m-12s UTC integration manifest Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (fi-cfl-s) fdo#102294 Test drv_module_reload: Subgroup basic-no-display: pass -> DMESG-WARN (fi-glk-1) fdo#102777 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:442s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:469s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:419s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:519s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:279s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:503s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:504s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:503s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:541s fi-cnl-y total:289 pass:257 dwarn:0 dfail:0 fail:5 skip:27 time:671s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:410s fi-glk-1 total:289 pass:259 dwarn:1 dfail:0 fail:0 skip:29 time:572s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:425s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:404s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:439s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:491s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:465s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:474s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:576s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:585s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:462s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:754s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:494s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:474s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:574s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:417s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_253/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 03/11] tests/perf: update max buffer size for reading reports
On 31 August 2017 at 11:35, Lionel Landwerlin wrote: > Signed-off-by: Lionel Landwerlin Maybe add the why to the commit message? Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for lib: Ask the kernel to quiescent the GPU
== Series Details == Series: lib: Ask the kernel to quiescent the GPU URL : https://patchwork.freedesktop.org/series/30890/ State : failure == Summary == IGT patchset tested on top of latest successful build 2885b10f99b4beeb046e75af8b8488c229f629d3 igt/gem_exec_schedule: Ignore set-priority failures on old kernels with latest DRM-Tip kernel build CI_DRM_3140 c4c623d58e38 drm-tip: 2017y-09m-26d-16h-37m-12s UTC integration manifest Test chamelium: Subgroup dp-crc-fast: pass -> FAIL (fi-kbl-7500u) fdo#102514 Test gem_sync: Subgroup basic-all: pass -> DMESG-FAIL (fi-blb-e6850) pass -> DMESG-FAIL (fi-pnv-d510) Test gem_workarounds: Subgroup basic-read: pass -> FAIL (fi-bdw-5557u) pass -> FAIL (fi-bdw-gvtdvm) pass -> FAIL (fi-bsw-n3050) pass -> FAIL (fi-skl-6700k) pass -> FAIL (fi-skl-6770hq) pass -> FAIL (fi-skl-gvtdvm) pass -> FAIL (fi-bxt-j4205) pass -> FAIL (fi-kbl-7500u) pass -> FAIL (fi-kbl-7560u) pass -> FAIL (fi-kbl-r) pass -> FAIL (fi-glk-1) pass -> FAIL (fi-cfl-s) Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (fi-cfl-s) fdo#102294 fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fi-bdw-5557u total:289 pass:267 dwarn:0 dfail:0 fail:1 skip:21 time:443s fi-bdw-gvtdvmtotal:289 pass:264 dwarn:0 dfail:0 fail:1 skip:24 time:465s fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:1 fail:0 skip:64 time:436s fi-bsw-n3050 total:289 pass:242 dwarn:0 dfail:0 fail:1 skip:46 time:514s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:279s fi-bxt-j4205 total:289 pass:259 dwarn:0 dfail:0 fail:1 skip:29 time:498s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:492s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:486s fi-cfl-s total:289 pass:222 dwarn:34 dfail:0 fail:1 skip:32 time:536s fi-cnl-y total:289 pass:256 dwarn:0 dfail:0 fail:6 skip:27 time:655s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:418s fi-glk-1 total:289 pass:259 dwarn:0 dfail:0 fail:1 skip:29 time:561s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:426s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:404s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:433s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:484s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:472s fi-kbl-7500u total:289 pass:262 dwarn:1 dfail:0 fail:2 skip:24 time:457s fi-kbl-7560u total:289 pass:269 dwarn:0 dfail:0 fail:1 skip:19 time:577s fi-kbl-r total:289 pass:261 dwarn:0 dfail:0 fail:1 skip:27 time:583s fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:1 fail:0 skip:65 time:553s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:456s fi-skl-6700k total:289 pass:264 dwarn:0 dfail:0 fail:1 skip:24 time:743s fi-skl-6770hqtotal:289 pass:268 dwarn:0 dfail:0 fail:1 skip:20 time:491s fi-skl-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:1 skip:23 time:469s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:563s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:416s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_252/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 11/11] tests/perf: add support for Coffeelake
On 31 August 2017 at 11:35, Lionel Landwerlin
wrote:
> Using the same timestamp frequency as Skylake/Kabylake.
>
> Signed-off-by: Lionel Landwerlin
> ---
> tests/perf.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tests/perf.c b/tests/perf.c
> index 070dee97..a4d3f663 100644
> --- a/tests/perf.c
> +++ b/tests/perf.c
> @@ -1145,6 +1145,9 @@ init_sys_info(void)
> } else if (IS_GEMINILAKE(devid)) {
> test_set_uuid =
> "dd3fd789-e783-4204-8cd0-b671bbccb0cf";
> timestamp_frequency = 1920;
> + } else if (IS_COFFEELAKE(devid)) {
> + test_set_uuid =
> "74fb4902-d3d3-4237-9e90-cbdc68d0a446";
> + timestamp_frequency = 1200;
Hmm so not CFL GT2 ?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/dp: Add defines for latency in sink
== Series Details == Series: series starting with [1/2] drm/dp: Add defines for latency in sink URL : https://patchwork.freedesktop.org/series/30893/ State : warning == Summary == Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test pm_rpm: Subgroup legacy-planes-dpms: pass -> SKIP (shard-hsw) Test kms_cursor_crc: Subgroup cursor-256x256-suspend: pass -> SKIP (shard-hsw) Test kms_flip: Subgroup plain-flip-fb-recreate: pass -> FAIL (shard-hsw) fdo#102504 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#102504 https://bugs.freedesktop.org/show_bug.cgi?id=102504 shard-hswtotal:2381 pass:1294 dwarn:4 dfail:0 fail:18 skip:1065 time:9678s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5815/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 09/11] tests/perf: estimate number of blocking/polling based on time spent
On 31 August 2017 at 11:35, Lionel Landwerlin wrote: > Blocking & polling tests define an amount of time to spend in the test > and then estimate the number of syscalls that should successfully > return. The problem is that while running the test we might spend > slightly more time than initiallly planned. This change estimates the > number of syscalls based on time spent after the fact. > > Signed-off-by: Lionel Landwerlin Ok. Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/2] drm/i915/uc: Move uC related types into dedicated header
== Series Details == Series: series starting with [RFC,1/2] drm/i915/uc: Move uC related types into dedicated header URL : https://patchwork.freedesktop.org/series/30918/ State : success == Summary == Series 30918v1 series starting with [RFC,1/2] drm/i915/uc: Move uC related types into dedicated header https://patchwork.freedesktop.org/api/1.0/series/30918/revisions/1/mbox/ Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (fi-cfl-s) fdo#102294 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:449s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:474s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:416s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:513s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:512s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:489s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:485s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:537s fi-cnl-y total:289 pass:257 dwarn:0 dfail:0 fail:5 skip:27 time:644s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:421s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:567s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:430s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:405s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:430s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:493s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:473s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:468s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:579s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:592s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:548s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:453s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:748s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:487s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:481s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:574s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:416s c4c623d58e38d49e692dc9141250b35e39170e6b drm-tip: 2017y-09m-26d-16h-37m-12s UTC integration manifest 8bcc49c080ce drm/i915: Make intel_guc_wopcm_size() inline cb01c1b473e0 drm/i915/uc: Move uC related types into dedicated header == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5822/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 07/11] tests/perf: make enable-disable more reliable
On 31 August 2017 at 11:35, Lionel Landwerlin
wrote:
> Estimation of the amount of reports can only refer to periodic ones,
> as context switch reports completely depend on what happens on the
> system. Also generate some load to prevent clock frequency changes to
> impact our measurement.
>
> Signed-off-by: Lionel Landwerlin
> ---
> tests/perf.c | 96
>
> 1 file changed, 90 insertions(+), 6 deletions(-)
>
> diff --git a/tests/perf.c b/tests/perf.c
> index 15a43cf8..3b2e1763 100644
> --- a/tests/perf.c
> +++ b/tests/perf.c
> @@ -2796,10 +2796,18 @@ test_enable_disable(void)
> int n_full_oa_reports = oa_buf_size / report_size;
> uint64_t fill_duration = n_full_oa_reports * oa_period;
>
> + load_helper_init();
> + load_helper_run(HIGH);
> +
> stream_fd = __perf_open(drm_fd, ¶m);
>
> for (int i = 0; i < 5; i++) {
> int len;
> + uint32_t n_periodic_reports;
> + struct drm_i915_perf_record_header *header;
> + uint32_t first_timestamp = 0, last_timestamp = 0;
> + uint32_t last_periodic_report[64];
> + double tick_per_period;
>
> /* Giving enough time for an overflow might help catch whether
> * the OA unit has been enabled even if the driver might at
> @@ -2819,18 +2827,91 @@ test_enable_disable(void)
>
> nanosleep(&(struct timespec){ .tv_sec = 0,
> .tv_nsec = fill_duration / 2 },
> - NULL);
> + NULL);
>
> - while ((len = read(stream_fd, buf, buf_size)) == -1 && errno
> == EINTR)
> - ;
> + n_periodic_reports = 0;
>
> - igt_assert_neq(len, -1);
> + /* Because of the race condition between notification of new
> +* reports and reports landing in memory, we need to rely on
> +* timestamps to figure whether we've read enough of them.
> +*/
> + while (((last_timestamp - first_timestamp) *
> oa_exponent_to_ns(oa_exponent)) <
(last_timestamp - first_timestamp) * oa_period
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add defines for latency in sink
On Mon, Sep 25, 2017 at 10:11 PM, Daniel Vetter wrote: > On Thu, Sep 21, 2017 at 07:42:07AM -0700, Rodrigo Vivi wrote: > > On Wed, Sep 20, 2017 at 02:32:34PM +, vathsala nagaraju wrote: > > > Add defines for dpcd register 2009 (synchronization latency > > > in sink). > > > > > > Cc: Rodrigo Vivi > > > CC: Puthikorn Voravootivat > > > Signed-off-by: Vathsala Nagaraju > > > > I keep forgetting to update my eDP spec 1.4 to this 1.4b... > > Maybe the patch should then make this clear, by annotating it with > /* eDP 1.4b */ That's missing, which isn't all that great really, since it > makes specs hunts like yours necessary. > > It's actually in eDP 1.4 spec, table 5-6 page 86 > Please fix up before applying. > -Daniel > > > > > > Reviewed-by: Rodrigo Vivi > > > > > > > > > --- > > > include/drm/drm_dp_helper.h | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > > > index 11c39f1..846004e6 100644 > > > --- a/include/drm/drm_dp_helper.h > > > +++ b/include/drm/drm_dp_helper.h > > > @@ -735,6 +735,9 @@ > > > # define DP_PSR_SINK_INTERNAL_ERROR 7 > > > # define DP_PSR_SINK_STATE_MASK 0x07 > > > > > > +#define DP_SINK_SYNCHRONIZATION_LATENCY0x2009 > > > +# define DP_MAX_RESYNC_FRAME_CNT_MASK 0xf > > > + > > > #define DP_RECEIVER_ALPM_STATUS0x200b /* eDP 1.4 */ > > > # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0) > > > > > > -- > > > 1.9.1 > > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use memset64() to prefill the GTT page
== Series Details == Series: drm/i915: Use memset64() to prefill the GTT page URL : https://patchwork.freedesktop.org/series/30892/ State : success == Summary == Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-hswtotal:2429 pass:1325 dwarn:4 dfail:0 fail:17 skip:1083 time:9976s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5814/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dim: Accept author x signed-off based on email.
On Tue, Sep 26, 2017 at 01:24:35PM +, Jani Nikula wrote: > On Tue, 26 Sep 2017, Daniel Vetter wrote: > > On Thu, Sep 21, 2017 at 06:27:28AM -0700, Rodrigo Vivi wrote: > >> On Thu, Sep 21, 2017 at 11:12:52AM +, Jani Nikula wrote: > >> > On Wed, 20 Sep 2017, Rodrigo Vivi wrote: > >> > > It seems Patchwork or SMTP servers are messing some patches > >> > > and changing the original git's author name on git per "Last, First". > >> > > So we end up with a mismatch were signed-off uses one name format > >> > > and author is using another format. > >> > > > >> > > So, let's check for email addresses instead. > >> > > > >> > > v2: Avoid useles warning and only check for email. > >> > > > >> > > Cc: Jani Nikula > >> > > Cc: Joonas Lahtinen > >> > > Signed-off-by: Rodrigo Vivi > >> > > >> > Reviewed-by: Jani Nikula > >> > >> pushed, thanks. > > > > Yeah except this breaks funny people like me who use different mails for > > stuff. My idea with fixing this was that we parse the mail name and check > > for both "Last, First" and "First Last" to work around the outlook crap. The name parsing with last and first can be really nasty and end up having other corner cases soon. Like, my legal name in us is still: de Oliveira Vivi, Rodrigo not Vivi, Rodrigo de Oliveira I can imagine many other possible combinations with this and other names. > > > > I really don't want to send mail from @intel.com to anywhere near public > > stuff. I'm not sure if it is outlook fault honestly. On my patches where this funny mess happenend I checked my email on the mailing list and original and everything seemed sane there. The only place where Last, First started was post pwclient. > > Ok, I'm fine with reverting, and finding another way. I'm fine with the revert as well, but before reverting let me propose one thing that is name_match || email_match so we cover both cases. What do you think? > > BR, > Jani. > > > -Daniel > > > >> > >> > > >> > > --- > >> > > dim | 2 +- > >> > > 1 file changed, 1 insertion(+), 1 deletion(-) > >> > > > >> > > diff --git a/dim b/dim > >> > > index dbaeb1ec944d..a63000fb67a8 100755 > >> > > --- a/dim > >> > > +++ b/dim > >> > > @@ -689,7 +689,7 @@ function checkpatch_commit_push > >> > >sha1=$1 > >> > > > >> > ># use real names for people with many different email addresses > >> > > - author=$(git show -s $sha1 --format="format:%an") > >> > > + author=$(git show -s $sha1 --format="format:%ae") > >> > >committer=$(git show -s $sha1 --format="format:%cn") > >> > > > >> > ># check for author sign-off > >> > > >> > -- > >> > Jani Nikula, Intel Open Source Technology Center > >> ___ > >> Intel-gfx mailing list > >> Intel-gfx@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 1/2] drm/i915/uc: Move uC related types into dedicated header
In old header structure we were mixing type definitions and
declarations that prevent us from exposing some functions
as inline. Lets try to fix that.
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/intel_guc_ct.c | 1 +
drivers/gpu/drm/i915/intel_guc_log.c | 1 +
drivers/gpu/drm/i915/intel_uc.h | 180 +++---
drivers/gpu/drm/i915/intel_uc_types.h | 172
7 files changed, 193 insertions(+), 165 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_uc_types.h
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b4a6ac6..8f85add 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -30,6 +30,7 @@
#include
#include
#include "intel_drv.h"
+#include "intel_uc.h"
static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
{
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b7cba89..521af91 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -58,7 +58,6 @@
#include "intel_uncore.h"
#include "intel_bios.h"
#include "intel_dpll_mgr.h"
-#include "intel_uc.h"
#include "intel_lrc.h"
#include "intel_ringbuffer.h"
@@ -73,6 +72,7 @@
#include "i915_vma.h"
+#include "intel_uc_types.h"
#include "intel_gvt.h"
/* General customization:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 73eeb6b..fa70b7c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -35,6 +35,7 @@
#include "intel_drv.h"
#include "intel_frontbuffer.h"
#include "intel_mocs.h"
+#include "intel_uc.h"
#include
#include
#include
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index c4cbec1..cbeecd2 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -23,6 +23,7 @@
#include "i915_drv.h"
#include "intel_guc_ct.h"
+#include "intel_uc.h"
enum { CTB_SEND = 0, CTB_RECV = 1 };
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
b/drivers/gpu/drm/i915/intel_guc_log.c
index 6571d96..024e3b1 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -24,6 +24,7 @@
#include
#include
#include "i915_drv.h"
+#include "intel_uc.h"
static void guc_log_capture_logs(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 6966349..b0e8849 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -24,62 +24,8 @@
#ifndef _INTEL_UC_H_
#define _INTEL_UC_H_
-#include "intel_guc_fwif.h"
-#include "i915_guc_reg.h"
-#include "intel_ringbuffer.h"
-#include "intel_guc_ct.h"
-#include "i915_vma.h"
+#include "intel_uc_types.h"
-struct drm_i915_gem_request;
-
-/*
- * This structure primarily describes the GEM object shared with the GuC.
- * The specs sometimes refer to this object as a "GuC context", but we use
- * the term "client" to avoid confusion with hardware contexts. This
- * GEM object is held for the entire lifetime of our interaction with
- * the GuC, being allocated before the GuC is loaded with its firmware.
- * Because there's no way to update the address used by the GuC after
- * initialisation, the shared object must stay pinned into the GGTT as
- * long as the GuC is in use. We also keep the first page (only) mapped
- * into kernel address space, as it includes shared data that must be
- * updated on every request submission.
- *
- * The single GEM object described here is actually made up of several
- * separate areas, as far as the GuC is concerned. The first page (kept
- * kmap'd) includes the "process descriptor" which holds sequence data for
- * the doorbell, and one cacheline which actually *is* the doorbell; a
- * write to this will "ring the doorbell" (i.e. send an interrupt to the
- * GuC). The subsequent pages of the client object constitute the work
- * queue (a circular array of work items), again described in the process
- * descriptor. Work queue pages are mapped momentarily as required.
- */
-struct i915_guc_client {
- struct i915_vma *vma;
- void *vaddr;
- struct i915_gem_context *owner;
- struct intel_guc *guc;
-
- uint32_t engines; /* bitmap of (host) engine ids */
- uint32_t priority;
- u32 stage_id;
- uint32_t proc_desc_offset;
-
- u16 doorbell_id;
- unsigned long doorbell_offset;
-
- spinlock_t wq_lock;
- /* Per-engine counts of GuC submissions */
- uint64_t submissions[I915_NUM_ENGINES];
-};
-
-enum intel_uc_fw_status {
- INTEL_UC_FIRMWARE_FAIL = -1,
-
[Intel-gfx] [RFC 2/2] drm/i915: Make intel_guc_wopcm_size() inline
It's small and we are using this function sporadically.
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_guc_loader.c | 11 ---
drivers/gpu/drm/i915/intel_uc.c | 4 ++--
drivers/gpu/drm/i915/intel_uc.h | 13 -
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index c9e25be..387d105a 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -250,17 +250,6 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
*dev_priv,
return ret;
}
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv)
-{
- u32 wopcm_size = GUC_WOPCM_TOP;
-
- /* On BXT, the top of WOPCM is reserved for RC6 context */
- if (IS_GEN9_LP(dev_priv))
- wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
-
- return wopcm_size;
-}
-
/*
* Load the GuC firmware blob into the MinuteIA.
*/
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 2774778..1ef2de6 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -188,7 +188,7 @@ static void fetch_uc_fw(struct drm_i915_private *dev_priv,
size = uc_fw->header_size + uc_fw->ucode_size;
/* Top 32k of WOPCM is reserved (8K stack + 24k RC6 context). */
- if (size > intel_guc_wopcm_size(dev_priv)) {
+ if (size > intel_guc_wopcm_size(&dev_priv->guc)) {
DRM_ERROR("Firmware is too large to fit in WOPCM\n");
goto fail;
}
@@ -374,7 +374,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
}
/* init WOPCM */
- I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(dev_priv));
+ I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(guc));
I915_WRITE(DMA_GUC_WOPCM_OFFSET,
GUC_WOPCM_OFFSET_VALUE | HUC_LOADING_AGENT_GUC);
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index b0e8849..b65ba5c 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -63,6 +63,18 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
}
+static inline u32 intel_guc_wopcm_size(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ u32 wopcm_size = GUC_WOPCM_TOP;
+
+ /* On BXT, the top of WOPCM is reserved for RC6 context */
+ if (IS_GEN9_LP(dev_priv))
+ wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
+
+ return wopcm_size;
+}
+
static inline u32 guc_ggtt_offset(struct i915_vma *vma)
{
u32 offset = i915_ggtt_offset(vma);
@@ -88,7 +100,6 @@ int intel_guc_select_fw(struct intel_guc *guc);
int intel_guc_init_hw(struct intel_guc *guc);
int intel_guc_suspend(struct drm_i915_private *dev_priv);
int intel_guc_resume(struct drm_i915_private *dev_priv);
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
/* i915_guc_submission.c */
int i915_guc_submission_init(struct drm_i915_private *dev_priv);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Replace wmb() with i915_gem_chipset_flush()
== Series Details == Series: drm/i915/selftests: Replace wmb() with i915_gem_chipset_flush() URL : https://patchwork.freedesktop.org/series/30916/ State : success == Summary == Series 30916v1 drm/i915/selftests: Replace wmb() with i915_gem_chipset_flush() https://patchwork.freedesktop.org/api/1.0/series/30916/revisions/1/mbox/ Test drv_module_reload: Subgroup basic-no-display: dmesg-warn -> PASS (fi-glk-1) fdo#102777 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:436s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:486s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:420s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:511s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:505s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:489s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:501s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:544s fi-cnl-y total:289 pass:257 dwarn:0 dfail:0 fail:5 skip:27 time:641s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:418s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:564s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:422s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:402s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:434s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:496s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:465s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:472s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:578s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:587s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:544s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:739s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:491s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:476s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:568s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:412s bf490952b4a476211cb01f4f2fe3e44007983b8f drm-tip: 2017y-09m-26d-14h-00m-42s UTC integration manifest 514842758428 drm/i915/selftests: Replace wmb() with i915_gem_chipset_flush() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5821/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Notify context-out for lost requests (rev3)
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Notify context-out for lost requests (rev3) URL : https://patchwork.freedesktop.org/series/30895/ State : success == Summary == Series 30895v3 series starting with [1/2] drm/i915/execlists: Notify context-out for lost requests https://patchwork.freedesktop.org/api/1.0/series/30895/revisions/3/mbox/ Test drv_module_reload: Subgroup basic-no-display: dmesg-warn -> PASS (fi-glk-1) fdo#102777 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:442s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:478s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:421s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:514s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:510s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:496s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:491s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:539s fi-cnl-y total:289 pass:257 dwarn:0 dfail:0 fail:5 skip:27 time:640s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:416s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:556s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:426s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:402s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:430s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:498s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:463s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:469s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:579s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:590s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:540s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:750s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:493s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:477s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:567s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:414s bf490952b4a476211cb01f4f2fe3e44007983b8f drm-tip: 2017y-09m-26d-14h-00m-42s UTC integration manifest d73062045ada drm/i915/execlists: Distinguish the incomplete context notifies 9b02669dc193 drm/i915/execlists: Notify context-out for lost requests == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5820/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Don't mix inline functions with declarations
== Series Details == Series: drm/i915: Don't mix inline functions with declarations URL : https://patchwork.freedesktop.org/series/30908/ State : warning == Summary == Series 30908v1 drm/i915: Don't mix inline functions with declarations https://patchwork.freedesktop.org/api/1.0/series/30908/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: dmesg-warn -> INCOMPLETE (fi-cfl-s) fdo#102294 Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (fi-kbl-7500u) Test drv_module_reload: Subgroup basic-no-display: dmesg-warn -> PASS (fi-glk-1) fdo#102777 fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:439s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:475s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:422s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:522s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:278s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:508s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:498s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:502s fi-cfl-s total:231 pass:188 dwarn:17 dfail:0 fail:0 skip:25 fi-cnl-y total:289 pass:257 dwarn:0 dfail:0 fail:5 skip:27 time:671s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:414s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:570s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:428s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:405s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:432s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:495s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:463s fi-kbl-7500u total:289 pass:263 dwarn:2 dfail:0 fail:0 skip:24 time:467s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:582s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:589s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:547s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:458s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:753s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:491s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:477s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:570s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:422s bf490952b4a476211cb01f4f2fe3e44007983b8f drm-tip: 2017y-09m-26d-14h-00m-42s UTC integration manifest a94517961ae3 drm/i915: Don't mix inline functions with declarations == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5819/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Replace wmb() with i915_gem_chipset_flush()
Currently, we are being fairly lazy and only using a wmb() following an
update to an active batch. Previously, we have found that to be
insufficient to ensure that a write from the CPU reaches memory in a
timely fashion, and in some caches we may need to flush a chipset cache.
To that end, we have i915_gem_chipset_flush() so use it.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/selftests/i915_gem_request.c | 10 +++---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 7 +--
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_request.c
b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
index 6664cb2eb0b8..78b9f811707f 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
@@ -418,7 +418,10 @@ static struct i915_vma *empty_batch(struct
drm_i915_private *i915)
err = PTR_ERR(cmd);
goto err;
}
+
*cmd = MI_BATCH_BUFFER_END;
+ i915_gem_chipset_flush(i915);
+
i915_gem_object_unpin_map(obj);
err = i915_gem_object_set_to_gtt_domain(obj, false);
@@ -605,8 +608,8 @@ static struct i915_vma *recursive_batch(struct
drm_i915_private *i915)
*cmd++ = lower_32_bits(vma->node.start);
}
*cmd++ = MI_BATCH_BUFFER_END; /* terminate early in case of error */
+ i915_gem_chipset_flush(i915);
- wmb();
i915_gem_object_unpin_map(obj);
return vma;
@@ -625,7 +628,7 @@ static int recursive_batch_resolve(struct i915_vma *batch)
return PTR_ERR(cmd);
*cmd = MI_BATCH_BUFFER_END;
- wmb();
+ i915_gem_chipset_flush(batch->vm->i915);
i915_gem_object_unpin_map(batch->obj);
@@ -858,7 +861,8 @@ static int live_sequential_engines(void *arg)
I915_MAP_WC);
if (!IS_ERR(cmd)) {
*cmd = MI_BATCH_BUFFER_END;
- wmb();
+ i915_gem_chipset_flush(i915);
+
i915_gem_object_unpin_map(request[id]->batch->obj);
}
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 377c1de766ce..08159b268893 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -165,6 +165,7 @@ static int emit_recurse_batch(struct hang *h,
*batch++ = lower_32_bits(vma->node.start);
}
*batch++ = MI_BATCH_BUFFER_END; /* not reached */
+ i915_gem_chipset_flush(h->i915);
flags = 0;
if (INTEL_GEN(vm->i915) <= 5)
@@ -231,7 +232,7 @@ static u32 hws_seqno(const struct hang *h,
static void hang_fini(struct hang *h)
{
*h->batch = MI_BATCH_BUFFER_END;
- wmb();
+ i915_gem_chipset_flush(h->i915);
i915_gem_object_unpin_map(h->obj);
i915_gem_object_put(h->obj);
@@ -275,6 +276,8 @@ static int igt_hang_sanitycheck(void *arg)
i915_gem_request_get(rq);
*h.batch = MI_BATCH_BUFFER_END;
+ i915_gem_chipset_flush(i915);
+
__i915_add_request(rq, true);
timeout = i915_wait_request(rq,
@@ -765,7 +768,7 @@ static int igt_reset_queue(void *arg)
pr_info("%s: Completed %d resets\n", engine->name, count);
*h.batch = MI_BATCH_BUFFER_END;
- wmb();
+ i915_gem_chipset_flush(i915);
i915_gem_request_put(prev);
}
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp: Avoid needless delay while link training
== Series Details == Series: drm/dp: Avoid needless delay while link training URL : https://patchwork.freedesktop.org/series/30891/ State : success == Summary == shard-hswtotal:2429 pass:1325 dwarn:4 dfail:0 fail:17 skip:1083 time:9960s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5813/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 2/8] drm/i915: Update GEM suspend/resume flows considering GuC and GEM fences
On 9/26/2017 8:18 PM, Chris Wilson wrote: Subject includes the word "fences". That was quite surprising as it doesn't involve either dma, sw or guc fences; or the fence registers. -Chris This was related to fence registers whose state is updated in i915_gem_restore_fences. With this patch I had moved the this to i915_gem_resume from i915_restore_state. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Set our shrinker->batch to 4096 (~16MiB)
Quoting Joonas Lahtinen (2017-09-20 14:28:40) > On Wed, 2017-08-16 at 14:55 +0100, Chris Wilson wrote: > > Quoting Joonas Lahtinen (2017-08-16 14:39:00) > > > On Sat, 2017-08-12 at 12:51 +0100, Chris Wilson wrote: > > > > Prefer to defer activating our GEM shrinker until we have a few > > > > megabytes to free; or we have accumulated sufficient mempressure by > > > > deferring the reclaim to force a shrink. The intent is that because our > > > > objects may typically be large, we are too effective at shrinking and > > > > are not rewarded for freeing more pages than the batch. It will also > > > > defer the initial shrinking to hopefully put it at a lower priority than > > > > say the buffer cache (although it will balance out over a number of > > > > reclaims, with GEM being more bursty). > > > > > > > > Signed-off-by: Chris Wilson > > > > --- > > > > drivers/gpu/drm/i915/i915_gem_shrinker.c | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c > > > > b/drivers/gpu/drm/i915/i915_gem_shrinker.c > > > > index 5b8bc0e4f336..8bb17e9a52de 100644 > > > > --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c > > > > +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c > > > > @@ -461,6 +461,7 @@ void i915_gem_shrinker_init(struct drm_i915_private > > > > *dev_priv) > > > > dev_priv->mm.shrinker.scan_objects = i915_gem_shrinker_scan; > > > > dev_priv->mm.shrinker.count_objects = i915_gem_shrinker_count; > > > > dev_priv->mm.shrinker.seeks = DEFAULT_SEEKS; > > > > + dev_priv->mm.shrinker.batch = 4096; > > > > > > Did you try how this alone effects the runtime of two consequtive > > > gem.testlist runs? Is there some specific test/usecase that benefits > > > from this. We'd be the first one to set this, md/raid5.c sets it to 128 > > > which is the default (0). > > > > My testing was trying to play a game that was hitting swap on an old > > hdd. So not very quantifiable, and vmscan is very unintuitive. > > > > Note also that we are special in that we don't report objects but pages. > > Not that it makes any difference, upon reclaim every slab is basically > > asked to give up some %% of what it reports, with some hysteresis thrown > > in on top. > > > > The only way we can do anything here is to throw it at lots of systems > > and see how that helps. My gut feeling says that the batch size should > > be approximately the typical object size in the freeable list, to try to > > reduce the amount of inefficient work. Now, the value is read before > > scan->count is called, but we can always improve the estimate for the > > next pass. > > For documentation purposes, from IRC, this is; > > Reviewed-by: Joonas Lahtinen And for reference, I took a stab at measuring vmpressure with gem_syslatency https://patchwork.freedesktop.org/patch/178777/ -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/execlists: Distinguish the incomplete context notifies
Let the listener know that the context we just scheduled out was not
complete, and will be scheduled back in at a later point.
v2: Handle CONTEXT_STATUS_PREEMPTED in gvt by aliasing it to
CONTEXT_STATUS_OUT for the moment, gvt can expand upon the difference
later.
Signed-off-by: Chris Wilson
Cc: "Zhenyu Wang"
Cc: "Wang, Zhi A"
Cc: Michał Winiarski
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gvt/scheduler.c | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index d5892d24f0b6..f6ded475bb2c 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -174,6 +174,7 @@ static int shadow_context_status_change(struct
notifier_block *nb,
atomic_set(&workload->shadow_ctx_active, 1);
break;
case INTEL_CONTEXT_SCHEDULE_OUT:
+ case INTEL_CONTEXT_SCHEDULE_PREEMPTED:
atomic_set(&workload->shadow_ctx_active, 0);
break;
default:
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 61cac26a8b05..79fe5f807098 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -580,7 +580,7 @@ execlist_cancel_port_requests(struct intel_engine_execlists
*execlists)
while (num_ports-- && port_isset(port)) {
struct drm_i915_gem_request *rq = port_request(port);
- execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
+ execlists_context_status_change(rq,
INTEL_CONTEXT_SCHEDULE_PREEMPTED);
i915_gem_request_put(rq);
memset(port, 0, sizeof(*port));
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 314adee7127a..689fde1a63a9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -61,6 +61,7 @@
enum {
INTEL_CONTEXT_SCHEDULE_IN = 0,
INTEL_CONTEXT_SCHEDULE_OUT,
+ INTEL_CONTEXT_SCHEDULE_PREEMPTED,
};
/* Logical Rings */
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for GEM/GuC Suspend/Resume/Reset fixes and restructuring (rev2)
== Series Details == Series: GEM/GuC Suspend/Resume/Reset fixes and restructuring (rev2) URL : https://patchwork.freedesktop.org/series/30802/ State : success == Summary == Series 30802v2 GEM/GuC Suspend/Resume/Reset fixes and restructuring https://patchwork.freedesktop.org/api/1.0/series/30802/revisions/2/mbox/ Test drv_module_reload: Subgroup basic-no-display: dmesg-warn -> PASS (fi-glk-1) fdo#102777 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:442s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:475s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:422s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:518s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:277s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:504s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:491s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:488s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:540s fi-cnl-y total:289 pass:256 dwarn:0 dfail:0 fail:6 skip:27 time:637s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:411s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:580s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:425s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:407s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:436s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:490s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:468s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:468s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:571s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:591s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:548s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:747s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:485s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:471s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:562s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:416s bf490952b4a476211cb01f4f2fe3e44007983b8f drm-tip: 2017y-09m-26d-14h-00m-42s UTC integration manifest 51cce7cb1c70 drm/i915/guc: Fix GuC cleanup in unload path 9809effa85d1 drm/i915/guc: Disable GuC submission and suspend it prior to i915 reset 5fc1018c35e6 drm/i915/guc: Update GuC suspend functionality in intel_uc_suspend 4134124ca0ce drm/i915/guc: Update GuC ggtt.invalidate/interrupts/communication across RPM suspend/resume 0606b7832893 drm/i915/guc: Introduce intel_guc_sanitize d00805fe6bc9 drm/i915: Create uC runtime and system suspend/resume helpers a005dc836c4b drm/i915: Update GEM suspend/resume flows considering GuC and GEM fences 80712fec4a3e drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5818/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 2/8] drm/i915: Update GEM suspend/resume flows considering GuC and GEM fences
Subject includes the word "fences". That was quite surprising as it doesn't involve either dma, sw or guc fences; or the fence registers. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't mix inline functions with declarations
Quoting Michal Wajdeczko (2017-09-26 15:37:23) > We group function forward declarations by file. There is no > reason to mix these declarations with our unline functions. Can of worms, can of worms. Our headers are a mess because we mix types and inlines, and so we end up with code being placed not logically where one would expect, but because CPP dictates it so. If you want to make a good improvements towards cleaning them up, spitting out the types would be my first step. /wishlist -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 2/8] drm/i915: Update GEM suspend/resume flows considering GuC and GEM fences
Quoting Sagar Arun Kamble (2017-09-26 15:24:15) > > > On 9/26/2017 7:12 PM, Chris Wilson wrote: > > Quoting Sagar Arun Kamble (2017-09-26 14:24:39) > >> diff --git a/drivers/gpu/drm/i915/i915_gem.c > >> b/drivers/gpu/drm/i915/i915_gem.c > >> index dbe181b..5dcd8c0 100644 > >> --- a/drivers/gpu/drm/i915/i915_gem.c > >> +++ b/drivers/gpu/drm/i915/i915_gem.c > >> @@ -2022,11 +2022,22 @@ int i915_gem_fault(struct vm_fault *vmf) > >> intel_runtime_pm_put(i915); > >> } > >> > >> +/** > >> + * i915_gem_runtime_suspend() - Finish GEM suspend > >> + * @dev_priv: i915 device private > >> + * > >> + * This function suspends GuC, removes userspace mappings for all GEM > >> obejcts > >> + * currently on userfault list and marks fences if any being used as lost. > >> + * > >> + * Return: non-zero code on error > >> + */ > >> +/** > >> + * i915_gem_runtime_resume() - Restore GEM state > >> + * @dev_priv: i915 device private > >> + * > >> + * This function inits swizzling, restores fences and resumes GuC. > >> + * > >> + * Return: non-zero code on error > >> + */ > >> +/** > >> + * i915_gem_suspend() - Suspend all GT activity. > >> + * @dev_priv: i915 device private > >> + * > >> + * This function disables RPS, flushes all executing context ensuring > >> + * GEM/GT/Engines idleness, cancels all work that needs GT access and > >> suspends > >> + * GuC. In the end currently, it also reset the GEM state and GPU HW. > >> + * > >> + * Return: non-zero code on error > >> + */ > >> +/** > >> + * i915_gem_resume() - Resume GT activity. > >> + * @dev_priv: i915 device private > >> + * > >> + * This function restores GTT mappings, restores fences and resets the > >> + * context images and resumes GuC. > >> + * > >> + * Return: non-zero code on error > >> + */ > > I can very much read what the functions do. These comments blocks are > > for telling me when to call them, under what pre/post-conditions and the > > overall intent of the function. > > > > Who are these blocks for? This isn't a library interface we expect to be > > used, these are hooks. > > -Chris > Since these functions are exported from i915_gem.c and are being used > from respective drm functions, to make > the semantics available in kernel docs I have added these comments. My point is that this isn't functionality that was exported for somebody to call, this was functionality that was pulled from i915_drv.c for a singular purpose. It is driven by that context, and not for general purpose. So who is the consumer? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't mix inline functions with declarations
We group function forward declarations by file. There is no
reason to mix these declarations with our unline functions.
Signed-off-by: Michal Wajdeczko
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uc.h | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 6966349..ae4cd0d 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -201,6 +201,24 @@ struct intel_huc {
/* HuC-specific additions */
};
+static inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32
len)
+{
+ return guc->send(guc, action, len);
+}
+
+static inline void intel_guc_notify(struct intel_guc *guc)
+{
+ guc->notify(guc);
+}
+
+static inline u32 guc_ggtt_offset(struct i915_vma *vma)
+{
+ u32 offset = i915_ggtt_offset(vma);
+ GEM_BUG_ON(offset < GUC_WOPCM_TOP);
+ GEM_BUG_ON(range_overflows_t(u64, offset, vma->size, GUC_GGTT_TOP));
+ return offset;
+}
+
/* intel_uc.c */
void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
void intel_uc_init_early(struct drm_i915_private *dev_priv);
@@ -213,16 +231,6 @@ int intel_guc_send_nop(struct intel_guc *guc, const u32
*action, u32 len);
int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
-static inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32
len)
-{
- return guc->send(guc, action, len);
-}
-
-static inline void intel_guc_notify(struct intel_guc *guc)
-{
- guc->notify(guc);
-}
-
/* intel_guc_loader.c */
int intel_guc_select_fw(struct intel_guc *guc);
int intel_guc_init_hw(struct intel_guc *guc);
@@ -244,14 +252,6 @@ int i915_guc_log_control(struct drm_i915_private
*dev_priv, u64 control_val);
void i915_guc_log_register(struct drm_i915_private *dev_priv);
void i915_guc_log_unregister(struct drm_i915_private *dev_priv);
-static inline u32 guc_ggtt_offset(struct i915_vma *vma)
-{
- u32 offset = i915_ggtt_offset(vma);
- GEM_BUG_ON(offset < GUC_WOPCM_TOP);
- GEM_BUG_ON(range_overflows_t(u64, offset, vma->size, GUC_GGTT_TOP));
- return offset;
-}
-
/* intel_huc.c */
void intel_huc_select_fw(struct intel_huc *huc);
void intel_huc_init_hw(struct intel_huc *huc);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 2/8] drm/i915: Update GEM suspend/resume flows considering GuC and GEM fences
On 9/26/2017 7:12 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-09-26 14:24:39) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index dbe181b..5dcd8c0 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2022,11 +2022,22 @@ int i915_gem_fault(struct vm_fault *vmf) intel_runtime_pm_put(i915); } +/** + * i915_gem_runtime_suspend() - Finish GEM suspend + * @dev_priv: i915 device private + * + * This function suspends GuC, removes userspace mappings for all GEM obejcts + * currently on userfault list and marks fences if any being used as lost. + * + * Return: non-zero code on error + */ +/** + * i915_gem_runtime_resume() - Restore GEM state + * @dev_priv: i915 device private + * + * This function inits swizzling, restores fences and resumes GuC. + * + * Return: non-zero code on error + */ +/** + * i915_gem_suspend() - Suspend all GT activity. + * @dev_priv: i915 device private + * + * This function disables RPS, flushes all executing context ensuring + * GEM/GT/Engines idleness, cancels all work that needs GT access and suspends + * GuC. In the end currently, it also reset the GEM state and GPU HW. + * + * Return: non-zero code on error + */ +/** + * i915_gem_resume() - Resume GT activity. + * @dev_priv: i915 device private + * + * This function restores GTT mappings, restores fences and resets the + * context images and resumes GuC. + * + * Return: non-zero code on error + */ I can very much read what the functions do. These comments blocks are for telling me when to call them, under what pre/post-conditions and the overall intent of the function. Who are these blocks for? This isn't a library interface we expect to be used, these are hooks. -Chris Since these functions are exported from i915_gem.c and are being used from respective drm functions, to make the semantics available in kernel docs I have added these comments. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 3/8] drm/i915: Create uC runtime and system suspend/resume helpers
On 9/26/2017 7:13 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-09-26 14:24:40) @@ -2077,7 +2079,7 @@ int i915_gem_runtime_suspend(struct drm_i915_private *dev_priv) reg->dirty = true; } - return 0; + return ret; OI! These are written as return 0 because you are very much not meant to reach this point with an error. -Chris What if GuC suspend fail? Do we still want to return 0. It might cause issues as GuC will be active when PCI Device is set to D3. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 4/8] drm/i915/guc: Introduce intel_guc_sanitize
On 9/26/2017 7:16 PM, Chris Wilson wrote:
Quoting Sagar Arun Kamble (2017-09-26 14:24:41)
Currently GPU is reset at the end of suspend via i915_gem_sanitize.
On resume, GuC will not be loaded until intel_uc_init_hw happens
during GEM resume flow but action to exit sleep wll be send to GuC
considering the FW load status. To make sure we don't invoke that
action update GuC FW load status through new helper
intel_guc_sanitize. Conditional check based on FW fetch status should
take care of driver init flow.
v2: Rebase.
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/intel_uc.c | 8
drivers/gpu/drm/i915/intel_uc.h | 1 +
3 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8e6e2bd..0d9a107 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4528,6 +4528,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
mutex_unlock(&i915->drm.struct_mutex);
}
+ intel_guc_sanitize(&i915->guc);
+
/*
* If we inherit context state from the BIOS or earlier occupants
* of the GPU, the GPU may be in an inconsistent state when we
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index b9376e4..29d43f8 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -581,3 +581,11 @@ int intel_guc_sample_forcewake(struct intel_guc *guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
}
+
+void intel_guc_sanitize(struct intel_guc *guc)
+{
+ if (guc->fw.fetch_status == INTEL_UC_FIRMWARE_SUCCESS)
+ guc->fw.load_status = INTEL_UC_FIRMWARE_PENDING;
+ else
+ guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
No, sanitize should not be carrying old state over. We are supposed to
be scrubbing hw state. (Elsewhere we detaint user state.)
-Chris
Will make this " guc->fw.load_status = INTEL_UC_FIRMWARE_NONE; "
unconditionally as GuC FW will not be loaded from hereon.
Will not depend on fetch status.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt/gem_exec_schedule: Ignore set-priority failures on old kernels
Quoting Michał Winiarski (2017-09-26 15:11:15)
> On Mon, Sep 25, 2017 at 09:21:15PM +0100, Chris Wilson wrote:
> > When plugging the device, we need to submit batches at highest priority
> > so that they cannot be gazumped by the queued requests. On older kernels
> > that do not support the user changing context priority, all contexts
> > therefore have max priority and we can ignore the error.
>
> All context have equal priority, we can ignore the error, it's not MAX.
>
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/gem_exec_schedule.c | 39 +++
> > 1 file changed, 19 insertions(+), 20 deletions(-)
> >
> > diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
> > index e9b928f1..0b1925f1 100644
> > --- a/tests/gem_exec_schedule.c
> > +++ b/tests/gem_exec_schedule.c
> > @@ -152,33 +152,32 @@ static void unplug(struct cork *c)
> > close(c->device);
> > }
> >
> > +static uint32_t create_highest_priority(int fd)
> > +{
> > + uint32_t ctx = gem_context_create(fd);
> > +
> > + /* If no priority support, all contexts have equal and max priority */
>
> Same here. It's DEFAULT (0), not MAX. We still do PI for display AFAICS.
Ssh. From the user perspective, one priority rules them all, I was
trying to emphasize that we could not submit a higher priority context
ourselves that would escape the plug. Hence the language focusing around
this being the maximum priority that we would see.
> That's just to handle fifo test even if we don't have userspace control,
> right?
Right. Just the test that doesn't depend upon context priorities as it
is checking that equal priority requests submitted in order are executed
in order. Hmm, could do with that being fifo at different priorities
just in case we happen to treat default as a special case.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 7/8] drm/i915/guc: Disable GuC submission and suspend it prior to i915 reset
On 9/26/2017 7:22 PM, Chris Wilson wrote:
Quoting Sagar Arun Kamble (2017-09-26 14:24:44)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index d710f0d..aec3f6b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -562,6 +562,14 @@ int intel_uc_resume(struct drm_i915_private *dev_priv)
return 0;
}
+int intel_uc_reset_prepare(struct drm_i915_private *dev_priv)
+{
+ if (i915_modparams.enable_guc_submission)
+ i915_guc_submission_disable(dev_priv);
General rule of thumb is that in disable we want to check some dependent
state setup by enable, not a user parameter.
-Chris
Ok. then will update the disable path to check if execbuf_client is
setup and call it without checking for modparam.
Thanks.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 6/8] drm/i915/guc: Update GuC suspend functionality in intel_uc_suspend
On 9/26/2017 7:27 PM, Michał Winiarski wrote: On Tue, Sep 26, 2017 at 02:49:48PM +0100, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-09-26 14:24:43) With this patch we disable GuC submission in i915_drm_suspend path. This will destroy the client which will be setup back again. We also reuse the complete sanitization done via intel_uc_runtime_suspend in this path. Post i915_drm_resume, this state is recreated by intel_uc_init_hw hence we need not have similar reuse for intel_uc_resume. This also fixes issue where intel_uc_fini_hw was being called after GPU reset happening in i915_gem_suspend during i915_driver_unload. v2: Rebase w.r.t removal of GuC code restructuring. Added struct_mutex protection for i915_guc_submission_disable. v3: Rebase w.r.t updated GuC suspend function name. v4: Added lockdep assert in i915_guc_submission_enable/disable. Refined intel_uc_suspend to remove unnecessary locals and simplify return. (Michal Winiarski) Removed comment in guc_client_free about ignoring failure for destroy_doorbell. (Oscar) Rebase w.r.t i915_modparams change. Cc: Michal Wajdeczko Cc: Michał Winiarski Reviewed-by: Michał Winiarski Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_guc_submission.c | 15 --- drivers/gpu/drm/i915/intel_uc.c| 11 +++ 2 files changed, 19 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index d1d6c0d..0c56765 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -885,9 +885,6 @@ static void guc_client_free(struct i915_guc_client *client) * Be sure to drop any locks */ - /* FIXME: in many cases, by the time we get here the GuC has been -* reset, so we cannot destroy the doorbell properly. Ignore the -* error message for now */ destroy_doorbell(client); guc_stage_desc_fini(client->guc, client); i915_gem_object_unpin_map(client->vma->obj); @@ -1154,6 +1151,12 @@ int i915_guc_submission_enable(struct drm_i915_private *dev_priv) sizeof(struct guc_wq_item) * I915_NUM_ENGINES > GUC_WQ_SIZE); + /* +* Assert that drm.struct_mutex is held. Ahem. +* Needed for GuC client vma binding. +*/ + lockdep_assert_held(&dev_priv->drm.struct_mutex); If you don't directly depend on struct_mutex, don't assert it. Otherwise the person who removes that requirement will get very confused and upset. -Chris My bad - I suggested that. Failed to notice *why* we're taking the mutex, and that we're already have lockdep assert in the right place (__i915_gem_object_release_unless_active). Sorry :) -Michał Will remove this. Thanks. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt/gem_exec_schedule: Ignore set-priority failures on old kernels
On Mon, Sep 25, 2017 at 09:21:15PM +0100, Chris Wilson wrote:
> When plugging the device, we need to submit batches at highest priority
> so that they cannot be gazumped by the queued requests. On older kernels
> that do not support the user changing context priority, all contexts
> therefore have max priority and we can ignore the error.
All context have equal priority, we can ignore the error, it's not MAX.
>
> Signed-off-by: Chris Wilson
> ---
> tests/gem_exec_schedule.c | 39 +++
> 1 file changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
> index e9b928f1..0b1925f1 100644
> --- a/tests/gem_exec_schedule.c
> +++ b/tests/gem_exec_schedule.c
> @@ -152,33 +152,32 @@ static void unplug(struct cork *c)
> close(c->device);
> }
>
> +static uint32_t create_highest_priority(int fd)
> +{
> + uint32_t ctx = gem_context_create(fd);
> +
> + /* If no priority support, all contexts have equal and max priority */
Same here. It's DEFAULT (0), not MAX. We still do PI for display AFAICS.
That's just to handle fifo test even if we don't have userspace control, right?
Reviewed-by: Michał Winiarski
-Michał
> + __ctx_set_priority(fd, ctx, MAX_PRIO);
> +
> + return ctx;
> +}
> +
> static void unplug_show_queue(int fd, struct cork *c, unsigned int engine)
> {
> - igt_spin_t *spin;
> - uint32_t ctx;
> -
> - ctx = gem_context_create(fd);
> - ctx_set_priority(fd, ctx, MAX_PRIO);
> -
> - spin = igt_spin_batch_new(fd, ctx, engine, 0);
> - for (int n = 0; n < BUSY_QLEN; n++) {
> - struct drm_i915_gem_exec_object2 obj = {
> - .handle = spin->handle,
> - };
> - struct drm_i915_gem_execbuffer2 execbuf = {
> - .buffers_ptr = to_user_pointer(&obj),
> - .buffer_count = 1,
> - .flags = engine,
> - };
> - gem_execbuf(fd, &execbuf);
> + igt_spin_t *spin[BUSY_QLEN];
> +
> + for (int n = 0; n < ARRAY_SIZE(spin); n++) {
> + uint32_t ctx = create_highest_priority(fd);
> + spin[n] = igt_spin_batch_new(fd, ctx, engine, 0);
> + gem_context_destroy(fd, ctx);
> }
>
> unplug(c); /* batches will now be queued on the engine */
> -
> igt_debugfs_dump(fd, "i915_engine_info");
> - igt_spin_batch_free(fd, spin);
>
> - gem_context_destroy(fd, ctx);
> + for (int n = 0; n < ARRAY_SIZE(spin); n++)
> + igt_spin_batch_free(fd, spin[n]);
> +
> }
>
> static void fifo(int fd, unsigned ring)
> --
> 2.14.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v8,1/8] drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors
== Series Details == Series: series starting with [v8,1/8] drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors URL : https://patchwork.freedesktop.org/series/30905/ State : success == Summary == Series 30905v1 series starting with [v8,1/8] drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors https://patchwork.freedesktop.org/api/1.0/series/30905/revisions/1/mbox/ Test drv_module_reload: Subgroup basic-reload-inject: dmesg-warn -> PASS (fi-glk-1) fdo#102777 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:438s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:464s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:422s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:520s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:279s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:506s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:493s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:493s fi-cfl-s total:289 pass:223 dwarn:34 dfail:0 fail:0 skip:32 time:539s fi-cnl-y total:289 pass:256 dwarn:0 dfail:0 fail:6 skip:27 time:640s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:416s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:565s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:429s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:406s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:432s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:489s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:464s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:469s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:574s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:599s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:549s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:748s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:492s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:478s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:564s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:411s 6ca114186dba29c0ba0f3e379cbf33fff04faa67 drm-tip: 2017y-09m-26d-13h-21m-14s UTC integration manifest 4d19130569b8 drm/i915/guc: Fix GuC cleanup in unload path e7d3b96c6a6d drm/i915/guc: Disable GuC submission and suspend it prior to i915 reset ade16970b7ed drm/i915/guc: Update GuC suspend functionality in intel_uc_suspend 44b688a6e0d6 drm/i915/guc: Update GuC ggtt.invalidate/interrupts/communication across RPM suspend/resume eb9d53327682 drm/i915/guc: Introduce intel_guc_sanitize fb500df9fbeb drm/i915: Create uC runtime and system suspend/resume helpers 3a2044a41fcd drm/i915: Update GEM suspend/resume flows considering GuC and GEM fences e237bcd3d31b drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5817/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 6/8] drm/i915/guc: Update GuC suspend functionality in intel_uc_suspend
On Tue, Sep 26, 2017 at 02:49:48PM +0100, Chris Wilson wrote: > Quoting Sagar Arun Kamble (2017-09-26 14:24:43) > > With this patch we disable GuC submission in i915_drm_suspend path. > > This will destroy the client which will be setup back again. We also > > reuse the complete sanitization done via intel_uc_runtime_suspend in > > this path. Post i915_drm_resume, this state is recreated by > > intel_uc_init_hw hence we need not have similar reuse for intel_uc_resume. > > This also fixes issue where intel_uc_fini_hw was being called after GPU > > reset happening in i915_gem_suspend during i915_driver_unload. > > > > v2: Rebase w.r.t removal of GuC code restructuring. Added struct_mutex > > protection for i915_guc_submission_disable. > > > > v3: Rebase w.r.t updated GuC suspend function name. > > > > v4: Added lockdep assert in i915_guc_submission_enable/disable. > > Refined intel_uc_suspend to remove unnecessary locals and simplify > > return. (Michal Winiarski) > > Removed comment in guc_client_free about ignoring failure for > > destroy_doorbell. (Oscar) > > Rebase w.r.t i915_modparams change. > > > > Cc: Michal Wajdeczko > > Cc: Michał Winiarski > > Reviewed-by: Michał Winiarski > > Signed-off-by: Sagar Arun Kamble > > --- > > drivers/gpu/drm/i915/i915_guc_submission.c | 15 --- > > drivers/gpu/drm/i915/intel_uc.c| 11 +++ > > 2 files changed, 19 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c > > b/drivers/gpu/drm/i915/i915_guc_submission.c > > index d1d6c0d..0c56765 100644 > > --- a/drivers/gpu/drm/i915/i915_guc_submission.c > > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c > > @@ -885,9 +885,6 @@ static void guc_client_free(struct i915_guc_client > > *client) > > * Be sure to drop any locks > > */ > > > > - /* FIXME: in many cases, by the time we get here the GuC has been > > -* reset, so we cannot destroy the doorbell properly. Ignore the > > -* error message for now */ > > destroy_doorbell(client); > > guc_stage_desc_fini(client->guc, client); > > i915_gem_object_unpin_map(client->vma->obj); > > @@ -1154,6 +1151,12 @@ int i915_guc_submission_enable(struct > > drm_i915_private *dev_priv) > > sizeof(struct guc_wq_item) * > > I915_NUM_ENGINES > GUC_WQ_SIZE); > > > > + /* > > +* Assert that drm.struct_mutex is held. > > Ahem. > > > +* Needed for GuC client vma binding. > > +*/ > > + lockdep_assert_held(&dev_priv->drm.struct_mutex); > > If you don't directly depend on struct_mutex, don't assert it. Otherwise > the person who removes that requirement will get very confused and upset. > -Chris My bad - I suggested that. Failed to notice *why* we're taking the mutex, and that we're already have lockdep assert in the right place (__i915_gem_object_release_unless_active). Sorry :) -Michał > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 7/8] drm/i915/guc: Disable GuC submission and suspend it prior to i915 reset
Quoting Sagar Arun Kamble (2017-09-26 14:24:44)
> diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
> index d710f0d..aec3f6b 100644
> --- a/drivers/gpu/drm/i915/intel_uc.c
> +++ b/drivers/gpu/drm/i915/intel_uc.c
> @@ -562,6 +562,14 @@ int intel_uc_resume(struct drm_i915_private *dev_priv)
> return 0;
> }
>
> +int intel_uc_reset_prepare(struct drm_i915_private *dev_priv)
> +{
> + if (i915_modparams.enable_guc_submission)
> + i915_guc_submission_disable(dev_priv);
General rule of thumb is that in disable we want to check some dependent
state setup by enable, not a user parameter.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 6/8] drm/i915/guc: Update GuC suspend functionality in intel_uc_suspend
Quoting Sagar Arun Kamble (2017-09-26 14:24:43) > With this patch we disable GuC submission in i915_drm_suspend path. > This will destroy the client which will be setup back again. We also > reuse the complete sanitization done via intel_uc_runtime_suspend in > this path. Post i915_drm_resume, this state is recreated by > intel_uc_init_hw hence we need not have similar reuse for intel_uc_resume. > This also fixes issue where intel_uc_fini_hw was being called after GPU > reset happening in i915_gem_suspend during i915_driver_unload. > > v2: Rebase w.r.t removal of GuC code restructuring. Added struct_mutex > protection for i915_guc_submission_disable. > > v3: Rebase w.r.t updated GuC suspend function name. > > v4: Added lockdep assert in i915_guc_submission_enable/disable. > Refined intel_uc_suspend to remove unnecessary locals and simplify > return. (Michal Winiarski) > Removed comment in guc_client_free about ignoring failure for > destroy_doorbell. (Oscar) > Rebase w.r.t i915_modparams change. > > Cc: Michal Wajdeczko > Cc: Michał Winiarski > Reviewed-by: Michał Winiarski > Signed-off-by: Sagar Arun Kamble > --- > drivers/gpu/drm/i915/i915_guc_submission.c | 15 --- > drivers/gpu/drm/i915/intel_uc.c| 11 +++ > 2 files changed, 19 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c > b/drivers/gpu/drm/i915/i915_guc_submission.c > index d1d6c0d..0c56765 100644 > --- a/drivers/gpu/drm/i915/i915_guc_submission.c > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c > @@ -885,9 +885,6 @@ static void guc_client_free(struct i915_guc_client > *client) > * Be sure to drop any locks > */ > > - /* FIXME: in many cases, by the time we get here the GuC has been > -* reset, so we cannot destroy the doorbell properly. Ignore the > -* error message for now */ > destroy_doorbell(client); > guc_stage_desc_fini(client->guc, client); > i915_gem_object_unpin_map(client->vma->obj); > @@ -1154,6 +1151,12 @@ int i915_guc_submission_enable(struct drm_i915_private > *dev_priv) > sizeof(struct guc_wq_item) * > I915_NUM_ENGINES > GUC_WQ_SIZE); > > + /* > +* Assert that drm.struct_mutex is held. Ahem. > +* Needed for GuC client vma binding. > +*/ > + lockdep_assert_held(&dev_priv->drm.struct_mutex); If you don't directly depend on struct_mutex, don't assert it. Otherwise the person who removes that requirement will get very confused and upset. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 4/8] drm/i915/guc: Introduce intel_guc_sanitize
Quoting Sagar Arun Kamble (2017-09-26 14:24:41)
> Currently GPU is reset at the end of suspend via i915_gem_sanitize.
> On resume, GuC will not be loaded until intel_uc_init_hw happens
> during GEM resume flow but action to exit sleep wll be send to GuC
> considering the FW load status. To make sure we don't invoke that
> action update GuC FW load status through new helper
> intel_guc_sanitize. Conditional check based on FW fetch status should
> take care of driver init flow.
>
> v2: Rebase.
>
> Cc: Michal Wajdeczko
> Cc: Michał Winiarski
> Signed-off-by: Sagar Arun Kamble
> ---
> drivers/gpu/drm/i915/i915_gem.c | 2 ++
> drivers/gpu/drm/i915/intel_uc.c | 8
> drivers/gpu/drm/i915/intel_uc.h | 1 +
> 3 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 8e6e2bd..0d9a107 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4528,6 +4528,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
> mutex_unlock(&i915->drm.struct_mutex);
> }
>
> + intel_guc_sanitize(&i915->guc);
> +
> /*
> * If we inherit context state from the BIOS or earlier occupants
> * of the GPU, the GPU may be in an inconsistent state when we
> diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
> index b9376e4..29d43f8 100644
> --- a/drivers/gpu/drm/i915/intel_uc.c
> +++ b/drivers/gpu/drm/i915/intel_uc.c
> @@ -581,3 +581,11 @@ int intel_guc_sample_forcewake(struct intel_guc *guc)
>
> return intel_guc_send(guc, action, ARRAY_SIZE(action));
> }
> +
> +void intel_guc_sanitize(struct intel_guc *guc)
> +{
> + if (guc->fw.fetch_status == INTEL_UC_FIRMWARE_SUCCESS)
> + guc->fw.load_status = INTEL_UC_FIRMWARE_PENDING;
> + else
> + guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
No, sanitize should not be carrying old state over. We are supposed to
be scrubbing hw state. (Elsewhere we detaint user state.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 3/8] drm/i915: Create uC runtime and system suspend/resume helpers
Quoting Sagar Arun Kamble (2017-09-26 14:24:40) > @@ -2077,7 +2079,7 @@ int i915_gem_runtime_suspend(struct drm_i915_private > *dev_priv) > reg->dirty = true; > } > > - return 0; > + return ret; OI! These are written as return 0 because you are very much not meant to reach this point with an error. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 2/8] drm/i915: Update GEM suspend/resume flows considering GuC and GEM fences
Quoting Sagar Arun Kamble (2017-09-26 14:24:39) > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index dbe181b..5dcd8c0 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -2022,11 +2022,22 @@ int i915_gem_fault(struct vm_fault *vmf) > intel_runtime_pm_put(i915); > } > > +/** > + * i915_gem_runtime_suspend() - Finish GEM suspend > + * @dev_priv: i915 device private > + * > + * This function suspends GuC, removes userspace mappings for all GEM obejcts > + * currently on userfault list and marks fences if any being used as lost. > + * > + * Return: non-zero code on error > + */ > +/** > + * i915_gem_runtime_resume() - Restore GEM state > + * @dev_priv: i915 device private > + * > + * This function inits swizzling, restores fences and resumes GuC. > + * > + * Return: non-zero code on error > + */ > +/** > + * i915_gem_suspend() - Suspend all GT activity. > + * @dev_priv: i915 device private > + * > + * This function disables RPS, flushes all executing context ensuring > + * GEM/GT/Engines idleness, cancels all work that needs GT access and > suspends > + * GuC. In the end currently, it also reset the GEM state and GPU HW. > + * > + * Return: non-zero code on error > + */ > +/** > + * i915_gem_resume() - Resume GT activity. > + * @dev_priv: i915 device private > + * > + * This function restores GTT mappings, restores fences and resets the > + * context images and resumes GuC. > + * > + * Return: non-zero code on error > + */ I can very much read what the functions do. These comments blocks are for telling me when to call them, under what pre/post-conditions and the overall intent of the function. Who are these blocks for? This isn't a library interface we expect to be used, these are hooks. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Try to recover from a wedged GPU during reset tests
Chris Wilson writes:
> Quoting Mika Kuoppala (2017-09-26 13:48:17)
>> Chris Wilson writes:
>>
>> > If we see the seqno stop progressing, we abandon the test for fear that
>> > the GPU died following the reset. However, during test teardown we still
>> > wait for the GPU to idle before continuing, but we have already
>> > confirmed that the GPU is dead. Furthermore, since we are inside a reset
>> > test, we have disabled the hangchecker, and so there is no safety net and
>> > we wait indefinitely. Detect the stuck GPU and declare it wedged as a
>> > state of emergency so we can escape.
>> >
>> > Signed-off-by: Chris Wilson
>> > Cc: Jari Tahvanainen
>> > Cc: Mika Kuoppala
>> > ---
>> > drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 25
>> > +++-
>> > 1 file changed, 20 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
>> > b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
>> > index 02e52a146ed8..913fe752f6b4 100644
>> > --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
>> > +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
>> > @@ -165,6 +165,7 @@ static int emit_recurse_batch(struct hang *h,
>> > *batch++ = lower_32_bits(vma->node.start);
>> > }
>> > *batch++ = MI_BATCH_BUFFER_END; /* not reached */
>> > + wmb();
>> >
>>
>> Why not the big hammer with i915_gem_chipset_flush() here?
>
> It didn't cross my mind, I was just doodling :)
>
>>
>> > flags = 0;
>> > if (INTEL_GEN(vm->i915) <= 5)
>> > @@ -621,7 +622,12 @@ static int igt_wait_reset(void *arg)
>> > __i915_add_request(rq, true);
>> >
>> > if (!wait_for_hang(&h, rq)) {
>> > - pr_err("Failed to start request %x\n", rq->fence.seqno);
>> > + pr_err("Failed to start request %x, at %x\n",
>> > +rq->fence.seqno, hws_seqno(&h, rq));
>> > +
>> > + i915_reset(i915, 0);
>> > + i915_gem_set_wedged(i915);
>> > +
>> > err = -EIO;
>> > goto out_rq;
>> > }
>> > @@ -708,10 +714,14 @@ static int igt_reset_queue(void *arg)
>> > __i915_add_request(rq, true);
>> >
>> > if (!wait_for_hang(&h, prev)) {
>> > - pr_err("Failed to start request %x\n",
>> > -prev->fence.seqno);
>> > + pr_err("Failed to start request %x, at %x\n",
>> > +rq->fence.seqno, hws_seqno(&h, rq));
>>
>> As you pointed out the debug in here is for wrong request.
>>
>> Reviewed-by: Mika Kuoppala
>
> Happy if I drop the wmb() for a later patch and replace it with a
> chipset flush instead?
Will be happy.
-Mika
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 1/8] drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors
Quoting Sagar Arun Kamble (2017-09-26 14:24:38)
> drivers/gpu/drm/i915/i915_drv.c | 34 --
> drivers/gpu/drm/i915/i915_drv.h | 5 +++--
> drivers/gpu/drm/i915/i915_gem.c | 20 ++--
> 3 files changed, 41 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 7056bb2..a3bbf18 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1655,6 +1655,7 @@ static int i915_suspend_switcheroo(struct drm_device
> *dev, pm_message_t state)
> static int i915_drm_resume(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> + struct pci_dev *pdev = dev_priv->drm.pdev;
> int ret;
>
> disable_rpm_wakeref_asserts(dev_priv);
> @@ -1666,7 +1667,9 @@ static int i915_drm_resume(struct drm_device *dev)
>
> intel_csr_ucode_resume(dev_priv);
>
> - i915_gem_resume(dev_priv);
> + ret = i915_gem_resume(dev_priv);
> + if (ret)
> + dev_err(&pdev->dev, "GEM resume failed\n");
>
> i915_restore_state(dev_priv);
> intel_pps_unlock_regs_wa(dev_priv);
> @@ -2615,14 +2617,18 @@ static int intel_runtime_resume(struct device *kdev)
>
> intel_enable_ipc(dev_priv);
>
> + ret = i915_gem_runtime_resume(dev_priv);
> + if (!err)
> + err = ret;
> +
> enable_rpm_wakeref_asserts(dev_priv);
>
> - if (ret)
> - DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret);
> + if (err)
> + DRM_ERROR("Runtime resume failed, disabling it (%d)\n", err);
> else
> DRM_DEBUG_KMS("Device resumed\n");
>
> - return ret;
> + return err;
What we've tried to do is to limit the damage that can happen if we
fail to re-enable GEM. We have tried to let the device resume, but
mark the device as wedged to prevent future execution, and so let the
device live long enough to be able to show error messages and whatnot
(system critical clients should also survive and fallover to alternative
paths).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 2/8] drm/i915: Update GEM suspend/resume flows considering GuC and GEM fences
This patch moves GuC suspend/resume handlers to corresponding GEM handlers
and orders them properly in the runtime and system suspend/resume flows.
It also adds documentation for GEM suspend/resume handlers.
i915_gem_restore_fences is GEM resumption task hence it is moved to
i915_gem_resume from i915_restore_state.
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Imre Deak
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Michal Wajdeczko
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_drv.c | 6 -
drivers/gpu/drm/i915/i915_gem.c | 47 ++---
drivers/gpu/drm/i915/i915_suspend.c | 2 --
3 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a3bbf18..8d67b8c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1698,8 +1698,6 @@ static int i915_drm_resume(struct drm_device *dev)
}
mutex_unlock(&dev->struct_mutex);
- intel_guc_resume(dev_priv);
-
intel_modeset_init_hw(dev);
spin_lock_irq(&dev_priv->irq_lock);
@@ -2504,8 +2502,6 @@ static int intel_runtime_suspend(struct device *kdev)
return ret;
}
- intel_guc_suspend(dev_priv);
-
intel_runtime_pm_disable_interrupts(dev_priv);
ret = 0;
@@ -2591,8 +2587,6 @@ static int intel_runtime_resume(struct device *kdev)
if (intel_uncore_unclaimed_mmio(dev_priv))
DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
- intel_guc_resume(dev_priv);
-
if (IS_GEN9_LP(dev_priv)) {
bxt_disable_dc9(dev_priv);
bxt_display_core_init(dev_priv, true);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dbe181b..5dcd8c0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2022,11 +2022,22 @@ int i915_gem_fault(struct vm_fault *vmf)
intel_runtime_pm_put(i915);
}
+/**
+ * i915_gem_runtime_suspend() - Finish GEM suspend
+ * @dev_priv: i915 device private
+ *
+ * This function suspends GuC, removes userspace mappings for all GEM obejcts
+ * currently on userfault list and marks fences if any being used as lost.
+ *
+ * Return: non-zero code on error
+ */
int i915_gem_runtime_suspend(struct drm_i915_private *dev_priv)
{
struct drm_i915_gem_object *obj, *on;
int i;
+ intel_guc_suspend(dev_priv);
+
/*
* Only called during RPM suspend. All users of the userfault_list
* must be holding an RPM wakeref to ensure that this can not
@@ -2069,6 +2080,14 @@ int i915_gem_runtime_suspend(struct drm_i915_private
*dev_priv)
return 0;
}
+/**
+ * i915_gem_runtime_resume() - Restore GEM state
+ * @dev_priv: i915 device private
+ *
+ * This function inits swizzling, restores fences and resumes GuC.
+ *
+ * Return: non-zero code on error
+ */
int i915_gem_runtime_resume(struct drm_i915_private *dev_priv)
{
/*
@@ -2078,6 +2097,8 @@ int i915_gem_runtime_resume(struct drm_i915_private
*dev_priv)
i915_gem_init_swizzling(dev_priv);
i915_gem_restore_fences(dev_priv);
+ intel_guc_resume(dev_priv);
+
return 0;
}
@@ -4521,6 +4542,16 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
}
}
+/**
+ * i915_gem_suspend() - Suspend all GT activity.
+ * @dev_priv: i915 device private
+ *
+ * This function disables RPS, flushes all executing context ensuring
+ * GEM/GT/Engines idleness, cancels all work that needs GT access and suspends
+ * GuC. In the end currently, it also reset the GEM state and GPU HW.
+ *
+ * Return: non-zero code on error
+ */
int i915_gem_suspend(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = &dev_priv->drm;
@@ -4553,8 +4584,6 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
i915_gem_contexts_lost(dev_priv);
mutex_unlock(&dev->struct_mutex);
- intel_guc_suspend(dev_priv);
-
cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
cancel_delayed_work_sync(&dev_priv->gt.retire_work);
@@ -4571,6 +4600,8 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
if (WARN_ON(!intel_engines_are_idle(dev_priv)))
i915_gem_set_wedged(dev_priv); /* no hope, discard everything */
+ intel_guc_suspend(dev_priv);
+
/*
* Neither the BIOS, ourselves or any other kernel
* expects the system to be in execlists mode on startup,
@@ -4601,6 +4632,15 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
return ret;
}
+/**
+ * i915_gem_resume() - Resume GT activity.
+ * @dev_priv: i915 device private
+ *
+ * This function restores GTT mappings, restores fences and resets the
+ * context images and resumes GuC.
+ *
+ * Return: non-zero code on error
+ */
int i915_gem_resume(struct drm_i915_private *dev_priv)
{
struct
[Intel-gfx] [PATCH v9 6/8] drm/i915/guc: Update GuC suspend functionality in intel_uc_suspend
With this patch we disable GuC submission in i915_drm_suspend path.
This will destroy the client which will be setup back again. We also
reuse the complete sanitization done via intel_uc_runtime_suspend in
this path. Post i915_drm_resume, this state is recreated by
intel_uc_init_hw hence we need not have similar reuse for intel_uc_resume.
This also fixes issue where intel_uc_fini_hw was being called after GPU
reset happening in i915_gem_suspend during i915_driver_unload.
v2: Rebase w.r.t removal of GuC code restructuring. Added struct_mutex
protection for i915_guc_submission_disable.
v3: Rebase w.r.t updated GuC suspend function name.
v4: Added lockdep assert in i915_guc_submission_enable/disable.
Refined intel_uc_suspend to remove unnecessary locals and simplify
return. (Michal Winiarski)
Removed comment in guc_client_free about ignoring failure for
destroy_doorbell. (Oscar)
Rebase w.r.t i915_modparams change.
Signed-off-by: Sagar Arun Kamble
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Reviewed-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_guc_submission.c | 15 ---
drivers/gpu/drm/i915/intel_uc.c| 11 +++
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d1d6c0d..0c56765 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -885,9 +885,6 @@ static void guc_client_free(struct i915_guc_client *client)
* Be sure to drop any locks
*/
- /* FIXME: in many cases, by the time we get here the GuC has been
-* reset, so we cannot destroy the doorbell properly. Ignore the
-* error message for now */
destroy_doorbell(client);
guc_stage_desc_fini(client->guc, client);
i915_gem_object_unpin_map(client->vma->obj);
@@ -1154,6 +1151,12 @@ int i915_guc_submission_enable(struct drm_i915_private
*dev_priv)
sizeof(struct guc_wq_item) *
I915_NUM_ENGINES > GUC_WQ_SIZE);
+ /*
+* Assert that drm.struct_mutex is held.
+* Needed for GuC client vma binding.
+*/
+ lockdep_assert_held(&dev_priv->drm.struct_mutex);
+
if (!client) {
client = guc_client_alloc(dev_priv,
INTEL_INFO(dev_priv)->ring_mask,
@@ -1204,6 +1207,12 @@ void i915_guc_submission_disable(struct drm_i915_private
*dev_priv)
{
struct intel_guc *guc = &dev_priv->guc;
+ /*
+* Assert that drm.struct_mutex is held.
+* Needed for GuC client vma unbinding.
+*/
+ lockdep_assert_held(&dev_priv->drm.struct_mutex);
+
guc_interrupts_release(dev_priv);
/* Revert back to manual ELSP submission */
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 7c34bc6..d710f0d 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -468,9 +468,6 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
if (!i915_modparams.enable_guc_loading)
return;
- if (i915_modparams.enable_guc_submission)
- i915_guc_submission_disable(dev_priv);
-
guc_disable_communication(&dev_priv->guc);
if (i915_modparams.enable_guc_submission) {
@@ -549,7 +546,13 @@ int intel_uc_runtime_resume(struct drm_i915_private
*dev_priv)
int intel_uc_suspend(struct drm_i915_private *dev_priv)
{
- return intel_guc_suspend(dev_priv);
+ if (i915_modparams.enable_guc_submission) {
+ mutex_lock(&dev_priv->drm.struct_mutex);
+ i915_guc_submission_disable(dev_priv);
+ mutex_unlock(&dev_priv->drm.struct_mutex);
+ }
+
+ return intel_uc_runtime_suspend(dev_priv);
}
int intel_uc_resume(struct drm_i915_private *dev_priv)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 7/8] drm/i915/guc: Disable GuC submission and suspend it prior to i915 reset
Before i915 reset, we need to disable GuC submission and suspend GuC
operations as it is recreated during intel_uc_init_hw. We can't reuse the
intel_uc_suspend functionality as reset path already holds struct_mutex.
v2: Rebase w.r.t removal of GuC code restructuring. Updated reset_prepare
function as struct_mutex is not needed.
v3: Fixed typo in commit message. Made return from intel_uc_reset_prepare
simpler. (Michal)
Rebase w.r.t i915_modparams change.
Signed-off-by: Sagar Arun Kamble
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/intel_uc.c | 8
drivers/gpu/drm/i915/intel_uc.h | 1 +
3 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0d9a107..64b278c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2882,6 +2882,8 @@ int i915_gem_reset_prepare(struct drm_i915_private
*dev_priv)
i915_gem_revoke_fences(dev_priv);
+ intel_uc_reset_prepare(dev_priv);
+
return err;
}
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index d710f0d..aec3f6b 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -562,6 +562,14 @@ int intel_uc_resume(struct drm_i915_private *dev_priv)
return 0;
}
+int intel_uc_reset_prepare(struct drm_i915_private *dev_priv)
+{
+ if (i915_modparams.enable_guc_submission)
+ i915_guc_submission_disable(dev_priv);
+
+ return intel_uc_runtime_suspend(dev_priv);
+}
+
int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len)
{
WARN(1, "Unexpected send: action=%#x\n", *action);
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 6163ff9..9b12f3c 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -212,6 +212,7 @@ struct intel_huc {
int intel_uc_runtime_resume(struct drm_i915_private *dev_priv);
int intel_uc_suspend(struct drm_i915_private *dev_priv);
int intel_uc_resume(struct drm_i915_private *dev_priv);
+int intel_uc_reset_prepare(struct drm_i915_private *dev_priv);
int intel_guc_sample_forcewake(struct intel_guc *guc);
void intel_guc_sanitize(struct intel_guc *guc);
int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 4/8] drm/i915/guc: Introduce intel_guc_sanitize
Currently GPU is reset at the end of suspend via i915_gem_sanitize.
On resume, GuC will not be loaded until intel_uc_init_hw happens
during GEM resume flow but action to exit sleep wll be send to GuC
considering the FW load status. To make sure we don't invoke that
action update GuC FW load status through new helper
intel_guc_sanitize. Conditional check based on FW fetch status should
take care of driver init flow.
v2: Rebase.
Signed-off-by: Sagar Arun Kamble
Cc: Michal Wajdeczko
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/intel_uc.c | 8
drivers/gpu/drm/i915/intel_uc.h | 1 +
3 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8e6e2bd..0d9a107 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4528,6 +4528,8 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
mutex_unlock(&i915->drm.struct_mutex);
}
+ intel_guc_sanitize(&i915->guc);
+
/*
* If we inherit context state from the BIOS or earlier occupants
* of the GPU, the GPU may be in an inconsistent state when we
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index b9376e4..29d43f8 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -581,3 +581,11 @@ int intel_guc_sample_forcewake(struct intel_guc *guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
}
+
+void intel_guc_sanitize(struct intel_guc *guc)
+{
+ if (guc->fw.fetch_status == INTEL_UC_FIRMWARE_SUCCESS)
+ guc->fw.load_status = INTEL_UC_FIRMWARE_PENDING;
+ else
+ guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 0a79e17..6163ff9 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -213,6 +213,7 @@ struct intel_huc {
int intel_uc_suspend(struct drm_i915_private *dev_priv);
int intel_uc_resume(struct drm_i915_private *dev_priv);
int intel_guc_sample_forcewake(struct intel_guc *guc);
+void intel_guc_sanitize(struct intel_guc *guc);
int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len);
int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 5/8] drm/i915/guc: Update GuC ggtt.invalidate/interrupts/communication across RPM suspend/resume
Apart from configuring interrupts, we need to update the ggtt invalidate
interface and GuC communication on suspend/resume. This functionality
can be reused for other suspend and reset paths.
v2: Rebase w.r.t removal of GuC code restructuring.
v3: Removed GuC specific helpers as tasks other than send H2G for
sleep/resume are to be done from uc generic functions. (Michal Wajdeczko)
v4: Simplified/Unified the error messaging in uc_runtime_suspend/resume.
(Michal Wajdeczko). Rebase w.r.t i915_modparams change.
Added documentation to intel_uc_runtime_suspend/resume.
Signed-off-by: Sagar Arun Kamble
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_guc_submission.c | 5 ---
drivers/gpu/drm/i915/intel_uc.c| 60 +-
2 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 04f1281..d1d6c0d 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1226,8 +1226,6 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
- gen9_disable_guc_interrupts(dev_priv);
-
ctx = dev_priv->kernel_context;
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
@@ -1252,9 +1250,6 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
- if (i915_modparams.guc_log_level >= 0)
- gen9_enable_guc_interrupts(dev_priv);
-
ctx = dev_priv->kernel_context;
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 29d43f8..7c34bc6 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -481,14 +481,70 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
i915_ggtt_disable_guc(dev_priv);
}
+/**
+ * intel_uc_runtime_suspend() - Suspend uC operation.
+ * @dev_priv: i915 device private
+ *
+ * This function invokes GuC OS suspension, makes ggtt_invalidate function to
+ * point to non-GuC variant, disables GuC interrupts and disable communication
+ * with GuC.
+ *
+ * Return: non-zero code on error
+ */
int intel_uc_runtime_suspend(struct drm_i915_private *dev_priv)
{
- return intel_guc_suspend(dev_priv);
+ int ret;
+
+ if (!i915_modparams.enable_guc_loading)
+ return 0;
+
+ ret = intel_guc_suspend(dev_priv);
+ if (ret)
+ goto out;
+
+ i915_ggtt_disable_guc(dev_priv);
+ gen9_disable_guc_interrupts(dev_priv);
+ guc_disable_communication(&dev_priv->guc);
+
+out:
+ if (ret)
+ DRM_ERROR("uC runtime suspend failed (%d)\n", ret);
+ return ret;
}
+/**
+ * intel_uc_runtime_resume() - Resume uC operation.
+ * @dev_priv: i915 device private
+ *
+ * This function enables communication with GuC, enables GuC interrupts,
+ * makes ggtt_invalidate function to point to GuC variant and invokes
+ * GuC OS resumption.
+ *
+ * Return: non-zero code on error
+ */
int intel_uc_runtime_resume(struct drm_i915_private *dev_priv)
{
- return intel_guc_resume(dev_priv);
+ int ret;
+
+ if (!i915_modparams.enable_guc_loading)
+ return 0;
+
+ ret = guc_enable_communication(&dev_priv->guc);
+ if (ret)
+ goto out;
+
+ if (i915_modparams.guc_log_level >= 0)
+ gen9_enable_guc_interrupts(dev_priv);
+ i915_ggtt_enable_guc(dev_priv);
+
+ ret = intel_guc_resume(dev_priv);
+ if (ret)
+ goto out;
+
+out:
+ if (ret)
+ DRM_ERROR("uC runtime resume failed (%d)\n", ret);
+ return ret;
}
int intel_uc_suspend(struct drm_i915_private *dev_priv)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 8/8] drm/i915/guc: Fix GuC cleanup in unload path
We ensure that GuC is completely suspended and client is destroyed
in i915_gem_suspend during i915_driver_unload. So now intel_uc_fini_hw
should just take care of cleanup,
hence s/intel_uc_fini_hw/intel_uc_cleanup. Correspondingly
we also updated as s/i915_guc_submission_fini/i915_guc_submission_cleanup
Other functionality to disable communication, disable interrupts and
update of ggtt.invalidate is taken care by intel_uc_suspend.
v2: Rebase w.r.t removal of GuC code restructuring.
v3: Removed intel_guc_cleanup. (Michal Wajdeczko)
v4: guc_free_load_err_log() needs to be called without checking
i915.enable_guc_loading as this param is cleared on GuC load failure.
(Michal Wajdeczko)
Signed-off-by: Sagar Arun Kamble
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_drv.c| 2 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_uc.c| 14 --
drivers/gpu/drm/i915/intel_uc.h| 4 ++--
4 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8bfebe3..4c0a5b5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -603,7 +603,7 @@ static void i915_gem_fini(struct drm_i915_private *dev_priv)
i915_gem_drain_workqueue(dev_priv);
mutex_lock(&dev_priv->drm.struct_mutex);
- intel_uc_fini_hw(dev_priv);
+ intel_uc_cleanup(dev_priv);
i915_gem_cleanup_engines(dev_priv);
i915_gem_contexts_fini(dev_priv);
i915_gem_cleanup_userptr(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 0c56765..176cf55 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1053,7 +1053,7 @@ int i915_guc_submission_init(struct drm_i915_private
*dev_priv)
return ret;
}
-void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
+void i915_guc_submission_cleanup(struct drm_i915_private *dev_priv)
{
struct intel_guc *guc = &dev_priv->guc;
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index aec3f6b..b8e1f97 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -439,7 +439,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
guc_capture_load_err_log(guc);
err_submission:
if (i915_modparams.enable_guc_submission)
- i915_guc_submission_fini(dev_priv);
+ i915_guc_submission_cleanup(dev_priv);
err_guc:
i915_ggtt_disable_guc(dev_priv);
@@ -461,21 +461,15 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
return ret;
}
-void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
+void intel_uc_cleanup(struct drm_i915_private *dev_priv)
{
guc_free_load_err_log(&dev_priv->guc);
if (!i915_modparams.enable_guc_loading)
return;
- guc_disable_communication(&dev_priv->guc);
-
- if (i915_modparams.enable_guc_submission) {
- gen9_disable_guc_interrupts(dev_priv);
- i915_guc_submission_fini(dev_priv);
- }
-
- i915_ggtt_disable_guc(dev_priv);
+ if (i915_modparams.enable_guc_submission)
+ i915_guc_submission_cleanup(dev_priv);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 9b12f3c..936d947 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -207,7 +207,7 @@ struct intel_huc {
void intel_uc_init_fw(struct drm_i915_private *dev_priv);
void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
int intel_uc_init_hw(struct drm_i915_private *dev_priv);
-void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
+void intel_uc_cleanup(struct drm_i915_private *dev_priv);
int intel_uc_runtime_suspend(struct drm_i915_private *dev_priv);
int intel_uc_runtime_resume(struct drm_i915_private *dev_priv);
int intel_uc_suspend(struct drm_i915_private *dev_priv);
@@ -240,7 +240,7 @@ static inline void intel_guc_notify(struct intel_guc *guc)
int i915_guc_submission_init(struct drm_i915_private *dev_priv);
int i915_guc_submission_enable(struct drm_i915_private *dev_priv);
void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
-void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
+void i915_guc_submission_cleanup(struct drm_i915_private *dev_priv);
struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
/* intel_guc_log.c */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 3/8] drm/i915: Create uC runtime and system suspend/resume helpers
Prepared generic helpers intel_uc_suspend, intel_uc_resume,
intel_uc_runtime_suspend, intel_uc_runtime_resume. These are
called from respective GEM functions.
v2: Rebase w.r.t removal of GuC code restructuring.
v3: Calling intel_uc_resume from i915_gem_resume post resuming
i915 gem setup. This is symmetrical with i915_gem_suspend.
Removed error messages from i915 suspend/resume routines as
uC suspend/resume routines will have those. (Michal Wajdeczko)
Declare wedged on uc_suspend failure and uc_resume failure.
(Michał Winiarski)
Added DRM_DEBUG message about skipping changes in intel_uc_resume.
Keeping the uC suspend/resume function definitions close to other
uC functions.
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_drv.c | 1 -
drivers/gpu/drm/i915/i915_gem.c | 32 +++-
drivers/gpu/drm/i915/intel_uc.c | 22 ++
drivers/gpu/drm/i915/intel_uc.h | 4
4 files changed, 49 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8d67b8c..8bfebe3 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2518,7 +2518,6 @@ static int intel_runtime_suspend(struct device *kdev)
DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
intel_runtime_pm_enable_interrupts(dev_priv);
- intel_guc_resume(dev_priv);
i915_gem_runtime_resume(dev_priv);
enable_rpm_wakeref_asserts(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5dcd8c0..8e6e2bd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2034,9 +2034,11 @@ int i915_gem_fault(struct vm_fault *vmf)
int i915_gem_runtime_suspend(struct drm_i915_private *dev_priv)
{
struct drm_i915_gem_object *obj, *on;
- int i;
+ int i, ret;
- intel_guc_suspend(dev_priv);
+ ret = intel_uc_runtime_suspend(dev_priv);
+ if (ret)
+ return ret;
/*
* Only called during RPM suspend. All users of the userfault_list
@@ -2077,7 +2079,7 @@ int i915_gem_runtime_suspend(struct drm_i915_private
*dev_priv)
reg->dirty = true;
}
- return 0;
+ return ret;
}
/**
@@ -2097,9 +2099,7 @@ int i915_gem_runtime_resume(struct drm_i915_private
*dev_priv)
i915_gem_init_swizzling(dev_priv);
i915_gem_restore_fences(dev_priv);
- intel_guc_resume(dev_priv);
-
- return 0;
+ return intel_uc_runtime_resume(dev_priv);
}
static int i915_gem_object_create_mmap_offset(struct drm_i915_gem_object *obj)
@@ -4600,7 +4600,9 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
if (WARN_ON(!intel_engines_are_idle(dev_priv)))
i915_gem_set_wedged(dev_priv); /* no hope, discard everything */
- intel_guc_suspend(dev_priv);
+ ret = intel_uc_suspend(dev_priv);
+ if (ret)
+ i915_gem_set_wedged(dev_priv); /* no hope, discard everything */
/*
* Neither the BIOS, ourselves or any other kernel
@@ -4644,6 +4646,7 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
int i915_gem_resume(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = &dev_priv->drm;
+ int ret;
WARN_ON(dev_priv->gt.awake);
@@ -4656,10 +4659,21 @@ int i915_gem_resume(struct drm_i915_private *dev_priv)
* it and start again.
*/
dev_priv->gt.resume(dev_priv);
- intel_guc_resume(dev_priv);
+
+ /*
+* NB: Full gem reinitialization is being done in i915_drm_resume
+* after gem_resume, so currently intel_uc_resume will be of no use.
+* Hence, intel_uc_resume is nop currently. If full reinitialization is
+* removed, will need to put functionality to resume from sleep in
+* intel_uc_resume.
+*/
+ ret = intel_uc_resume(dev_priv);
+ if (ret)
+ i915_gem_set_wedged(dev_priv);
+
mutex_unlock(&dev->struct_mutex);
- return 0;
+ return ret;
}
void i915_gem_init_swizzling(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 2774778..b9376e4 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -481,6 +481,28 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
i915_ggtt_disable_guc(dev_priv);
}
+int intel_uc_runtime_suspend(struct drm_i915_private *dev_priv)
+{
+ return intel_guc_suspend(dev_priv);
+}
+
+int intel_uc_runtime_resume(struct drm_i915_private *dev_priv)
+{
+ return intel_guc_resume(dev_priv);
+}
+
+int intel_uc_suspend(struct drm_i915_private *dev_priv)
+{
+ return intel_guc_suspend(dev_priv);
+}
+
+int intel_uc_resume(struct drm_i915_private *dev
[Intel-gfx] [PATCH v9 1/8] drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors
Prepared helper i915_gem_runtime_resume to recreate gem setup.
Returning status from i915_gem_runtime_suspend and i915_gem_resume.
This will be placeholder for handling any errors from uC suspend/resume
in upcoming patches. Restructured the suspend/resume routines w.r.t setup
creation and rollback order.
This also fixes issue of ordering of i915_gem_runtime_resume with
intel_runtime_pm_enable_interrupts.
v2: Fixed return from intel_runtime_resume. (Michał Winiarski)
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Imre Deak
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Michal Wajdeczko
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_drv.c | 34 --
drivers/gpu/drm/i915/i915_drv.h | 5 +++--
drivers/gpu/drm/i915/i915_gem.c | 20 ++--
3 files changed, 41 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7056bb2..a3bbf18 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1655,6 +1655,7 @@ static int i915_suspend_switcheroo(struct drm_device
*dev, pm_message_t state)
static int i915_drm_resume(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
+ struct pci_dev *pdev = dev_priv->drm.pdev;
int ret;
disable_rpm_wakeref_asserts(dev_priv);
@@ -1666,7 +1667,9 @@ static int i915_drm_resume(struct drm_device *dev)
intel_csr_ucode_resume(dev_priv);
- i915_gem_resume(dev_priv);
+ ret = i915_gem_resume(dev_priv);
+ if (ret)
+ dev_err(&pdev->dev, "GEM resume failed\n");
i915_restore_state(dev_priv);
intel_pps_unlock_regs_wa(dev_priv);
@@ -2495,7 +2498,11 @@ static int intel_runtime_suspend(struct device *kdev)
* We are safe here against re-faults, since the fault handler takes
* an RPM reference.
*/
- i915_gem_runtime_suspend(dev_priv);
+ ret = i915_gem_runtime_suspend(dev_priv);
+ if (ret) {
+ enable_rpm_wakeref_asserts(dev_priv);
+ return ret;
+ }
intel_guc_suspend(dev_priv);
@@ -2515,6 +2522,8 @@ static int intel_runtime_suspend(struct device *kdev)
DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
intel_runtime_pm_enable_interrupts(dev_priv);
+ intel_guc_resume(dev_priv);
+ i915_gem_runtime_resume(dev_priv);
enable_rpm_wakeref_asserts(dev_priv);
return ret;
@@ -2567,7 +2576,7 @@ static int intel_runtime_resume(struct device *kdev)
struct pci_dev *pdev = to_pci_dev(kdev);
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_i915_private *dev_priv = to_i915(dev);
- int ret = 0;
+ int err = 0, ret;
if (WARN_ON_ONCE(!HAS_RUNTIME_PM(dev_priv)))
return -ENODEV;
@@ -2593,16 +2602,9 @@ static int intel_runtime_resume(struct device *kdev)
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
hsw_disable_pc8(dev_priv);
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
- ret = vlv_resume_prepare(dev_priv, true);
+ err = vlv_resume_prepare(dev_priv, true);
}
- /*
-* No point of rolling back things in case of an error, as the best
-* we can do is to hope that things will still work (and disable RPM).
-*/
- i915_gem_init_swizzling(dev_priv);
- i915_gem_restore_fences(dev_priv);
-
intel_runtime_pm_enable_interrupts(dev_priv);
/*
@@ -2615,14 +2617,18 @@ static int intel_runtime_resume(struct device *kdev)
intel_enable_ipc(dev_priv);
+ ret = i915_gem_runtime_resume(dev_priv);
+ if (!err)
+ err = ret;
+
enable_rpm_wakeref_asserts(dev_priv);
- if (ret)
- DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret);
+ if (err)
+ DRM_ERROR("Runtime resume failed, disabling it (%d)\n", err);
else
DRM_DEBUG_KMS("Device resumed\n");
- return ret;
+ return err;
}
const struct dev_pm_ops i915_pm_ops = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 61a4be9..69370c1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3471,7 +3471,8 @@ struct i915_vma * __must_check
int i915_gem_object_unbind(struct drm_i915_gem_object *obj);
void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
-void i915_gem_runtime_suspend(struct drm_i915_private *dev_priv);
+int i915_gem_runtime_suspend(struct drm_i915_private *dev_priv);
+int i915_gem_runtime_resume(struct drm_i915_private *dev_priv);
static inline int __sg_page_count(const struct scatterlist *sg)
{
@@ -3674,7 +3675,7 @@ void i915_gem_reset_engine(struct intel_engine_cs *engine,
int i915_gem_wait_for_i
[Intel-gfx] [PATCH v9 0/8] GEM/GuC Suspend/Resume/Reset fixes and restructuring
Fixed patch 1 based on review inputs from Michal Winiarski. Rebased all patches. Updated ordering of cc, s-o-b, r-b tags for all patches. Sagar Arun Kamble (8): drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors drm/i915: Update GEM suspend/resume flows considering GuC and GEM fences drm/i915: Create uC runtime and system suspend/resume helpers drm/i915/guc: Introduce intel_guc_sanitize drm/i915/guc: Update GuC ggtt.invalidate/interrupts/communication across RPM suspend/resume drm/i915/guc: Update GuC suspend functionality in intel_uc_suspend drm/i915/guc: Disable GuC submission and suspend it prior to i915 reset drm/i915/guc: Fix GuC cleanup in unload path drivers/gpu/drm/i915/i915_drv.c| 41 ++-- drivers/gpu/drm/i915/i915_drv.h| 5 +- drivers/gpu/drm/i915/i915_gem.c| 85 ++-- drivers/gpu/drm/i915/i915_guc_submission.c | 22 +++--- drivers/gpu/drm/i915/i915_suspend.c| 2 - drivers/gpu/drm/i915/intel_uc.c| 103 +++-- drivers/gpu/drm/i915/intel_uc.h| 10 ++- 7 files changed, 221 insertions(+), 47 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 1/8] drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors
And I have forgot to amend the ordering of tags cc, s-o-b etc. Sorry for
the same.
On 9/26/2017 6:54 PM, Sagar Arun Kamble wrote:
Prepared helper i915_gem_runtime_resume to recreate gem setup.
Returning status from i915_gem_runtime_suspend and i915_gem_resume.
This will be placeholder for handling any errors from uC suspend/resume
in upcoming patches. Restructured the suspend/resume routines w.r.t setup
creation and rollback order.
This also fixes issue of ordering of i915_gem_runtime_resume with
intel_runtime_pm_enable_interrupts.
v2: Fixed return from intel_runtime_resume. (Michał Winiarski)
Cc: Chris Wilson
Cc: Imre Deak
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_drv.c | 34 --
drivers/gpu/drm/i915/i915_drv.h | 5 +++--
drivers/gpu/drm/i915/i915_gem.c | 20 ++--
3 files changed, 41 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7056bb2..a3bbf18 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1655,6 +1655,7 @@ static int i915_suspend_switcheroo(struct drm_device
*dev, pm_message_t state)
static int i915_drm_resume(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
+ struct pci_dev *pdev = dev_priv->drm.pdev;
int ret;
disable_rpm_wakeref_asserts(dev_priv);
@@ -1666,7 +1667,9 @@ static int i915_drm_resume(struct drm_device *dev)
intel_csr_ucode_resume(dev_priv);
- i915_gem_resume(dev_priv);
+ ret = i915_gem_resume(dev_priv);
+ if (ret)
+ dev_err(&pdev->dev, "GEM resume failed\n");
i915_restore_state(dev_priv);
intel_pps_unlock_regs_wa(dev_priv);
@@ -2495,7 +2498,11 @@ static int intel_runtime_suspend(struct device *kdev)
* We are safe here against re-faults, since the fault handler takes
* an RPM reference.
*/
- i915_gem_runtime_suspend(dev_priv);
+ ret = i915_gem_runtime_suspend(dev_priv);
+ if (ret) {
+ enable_rpm_wakeref_asserts(dev_priv);
+ return ret;
+ }
intel_guc_suspend(dev_priv);
@@ -2515,6 +2522,8 @@ static int intel_runtime_suspend(struct device *kdev)
DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
intel_runtime_pm_enable_interrupts(dev_priv);
+ intel_guc_resume(dev_priv);
+ i915_gem_runtime_resume(dev_priv);
enable_rpm_wakeref_asserts(dev_priv);
return ret;
@@ -2567,7 +2576,7 @@ static int intel_runtime_resume(struct device *kdev)
struct pci_dev *pdev = to_pci_dev(kdev);
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_i915_private *dev_priv = to_i915(dev);
- int ret = 0;
+ int err = 0, ret;
if (WARN_ON_ONCE(!HAS_RUNTIME_PM(dev_priv)))
return -ENODEV;
@@ -2593,16 +2602,9 @@ static int intel_runtime_resume(struct device *kdev)
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
hsw_disable_pc8(dev_priv);
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
- ret = vlv_resume_prepare(dev_priv, true);
+ err = vlv_resume_prepare(dev_priv, true);
}
- /*
-* No point of rolling back things in case of an error, as the best
-* we can do is to hope that things will still work (and disable RPM).
-*/
- i915_gem_init_swizzling(dev_priv);
- i915_gem_restore_fences(dev_priv);
-
intel_runtime_pm_enable_interrupts(dev_priv);
/*
@@ -2615,14 +2617,18 @@ static int intel_runtime_resume(struct device *kdev)
intel_enable_ipc(dev_priv);
+ ret = i915_gem_runtime_resume(dev_priv);
+ if (!err)
+ err = ret;
+
enable_rpm_wakeref_asserts(dev_priv);
- if (ret)
- DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret);
+ if (err)
+ DRM_ERROR("Runtime resume failed, disabling it (%d)\n", err);
else
DRM_DEBUG_KMS("Device resumed\n");
- return ret;
+ return err;
}
const struct dev_pm_ops i915_pm_ops = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 61a4be9..69370c1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3471,7 +3471,8 @@ struct i915_vma * __must_check
int i915_gem_object_unbind(struct drm_i915_gem_object *obj);
void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
-void i915_gem_runtime_suspend(struct drm_i915_private *dev_priv);
+int i915_gem_runtime_suspend(struct drm_i915_private *dev_priv);
+int i915_gem_runtime_resume(struct drm_i915_private *dev_priv);
static inline int __sg_page_count(const struct scatterlist *sg)
{
@@ -3674,7 +367
