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

[Patchwork]

== Series Details ==

Series: series starting with [v5,1/8] drm/i915: Correctly handle error path in 
i915_gem_init_hw
URL   : https://patchwork.freedesktop.org/series/40759/
State : failure

== Summary ==

 Possible new issues:

Test drm_mm:
Subgroup sanitycheck:
pass   -> INCOMPLETE (shard-apl)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> INCOMPLETE (shard-apl)
Subgroup error-state-capture-blt:
pass   -> INCOMPLETE (shard-apl)
Subgroup hangcheck-unterminated:
pass   -> INCOMPLETE (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> SKIP   (shard-apl)
Subgroup live_hangcheck:
pass   -> DMESG-FAIL (shard-apl)
Test gem_eio:
Subgroup execbuf:
pass   -> INCOMPLETE (shard-apl)
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-apl)
Test gem_mocs_settings:
Subgroup mocs-reset-vebox:
pass   -> INCOMPLETE (shard-apl)
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> INCOMPLETE (shard-apl)
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
dmesg-warn -> PASS   (shard-snb)
Test kms_flip:
Subgroup flip-vs-panning-vs-hang-interruptible:
pass   -> INCOMPLETE (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-cpu:
pass   -> SKIP   (shard-snb)
Test kms_vblank:
Subgroup pipe-a-query-idle-hang:
pass   -> INCOMPLETE (shard-apl)
Subgroup pipe-a-wait-forked-busy:
pass   -> SKIP   (shard-snb)
Subgroup pipe-c-query-busy-hang:
pass   -> INCOMPLETE (shard-apl)
Subgroup pipe-c-query-forked-hang:
pass   -> INCOMPLETE (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)
Test pm_rpm:
Subgroup debugfs-read:
pass   -> DMESG-WARN (shard-apl)

 Known issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl) fdo#103199
Test gem_eio:
Subgroup in-flight-suspend:
pass   -> INCOMPLETE (shard-apl) fdo#103375
Subgroup suspend:
pass   -> INCOMPLETE (shard-apl) fdo#103927
Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup 2x-flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887 +1
Subgroup 2x-plain-flip-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
pass   -> FAIL   (shard-snb) fdo#103925
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252

fdo#103199 https://bugs.freedesktop.org/show_bug.cgi?id=103199
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:2115 pass:1059 dwarn:2   dfail:1   fail:5   skip:1022 
time:3044s
shard-hswtotal:3495 pass:1782 dwarn:1   dfail:0   fail:2   skip:1709 
time:11596s
shard-snbtotal:3495 pass:1371 dwarn:1   dfail:0   fail:4   skip:2119 
time:6949s
Blacklisted hosts:
shard-kbltotal:2098 pass:1095 dwarn:3   dfail:1   fail:3   skip:971 
time:2232s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8506/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Nagaraju, Vathsala]

Selective update testing
 play a video and check 0x60094 , (03, 06) will indicated that system 
is in su state.


-Original Message-
From: Vivi, Rodrigo 
Sent: Wednesday, March 28, 2018 3:07 AM
To: Pandiyan, Dhinakaran 
Cc: Souza, Jose ; intel-gfx@lists.freedesktop.org; 
Nagaraju, Vathsala 
Subject: Re: [Intel-gfx] [PATCH 04/12] drm/i915/psr: Tie PSR2 support to Y 
coordinate requirement

On Fri, Mar 23, 2018 at 07:34:34PM -0700, Pandiyan, Dhinakaran wrote:
> 
> On Fri, 2018-03-23 at 23:51 +, Souza, Jose wrote:
> > On Fri, 2018-03-23 at 15:59 -0700, Pandiyan, Dhinakaran wrote:
> > > 
> > > 
> > > On Thu, 2018-03-22 at 14:48 -0700, José Roberto de Souza wrote:
> > > > Move to only one place the sink requirements that the actual 
> > > > driver needs to enable PSR2.
> > > > 
> > > > Also intel_psr2_config_valid() is called every time the crtc 
> > > > config is computed, wasting some time every time it was checking 
> > > > for Y coordinate requirement.
> > > > 
> > > > This allow us to nuke y_cord_support and some of VSC setup code 
> > > > that was handling a scenario that would never happen(PSR2 
> > > > without Y coordinate).
> > > > 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Rodrigo Vivi 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h  |  1 -  
> > > > drivers/gpu/drm/i915/intel_psr.c | 46 
> > > > +---
> > > > 
> > > >  2 files changed, 19 insertions(+), 28 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h index 
> > > > 7fe00509e51a..cce32686fd75 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -603,7 +603,6 @@ struct i915_psr {
> > > > unsigned busy_frontbuffer_bits;
> > > > bool psr2_support;
> > > > bool link_standby;
> > > > -   bool y_cord_support;
> > > > bool colorimetry_support;
> > > > bool alpm;
> > > > bool has_hw_tracking;
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index d46320a451d9..23f38ab10636 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct 
> > > > intel_dp
> > > > *intel_dp)
> > > > intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));  
> > > > }
> > > >  
> > > > -static bool intel_dp_get_y_cord_status(struct intel_dp 
> > > > *intel_dp)
> > > > +static bool intel_dp_get_y_coord_required(struct intel_dp
> > > > *intel_dp)
> > > >  {
> > > > uint8_t psr_caps = 0;
> > > >  
> > > > @@ -130,22 +130,29 @@ void intel_psr_init_dpcd(struct intel_dp
> > > > *intel_dp)
> > > > drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT, intel_dp-
> > > > >psr_dpcd,
> > > >  sizeof(intel_dp->psr_dpcd));
> > > >  
> > > > -   if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> > > > +   if (intel_dp->psr_dpcd[0]) {
> > > > dev_priv->psr.sink_support = true;
> > > > DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> > > > }
> > > >  
> > > > if (INTEL_GEN(dev_priv) >= 9 &&
> > > > -   (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> > > > -
> > > > -   dev_priv->psr.sink_support = true;
> > > > -   dev_priv->psr.psr2_support = true;
> > > > +   (intel_dp->psr_dpcd[0] ==
> > > > DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
> > > > +   /*
> > > > +* All panels that supports PSR version 03h (PSR2
> > > > +
> > > > +* Y-coordinate) can handle Y-coordinates in VSC
> > > > but we are
> > > > +* only sure that it is going to be used when
> > > > required by the
> > > > +* panel. This way panel is capable to do
> > > > selective update
> > > > +* without a aux frame sync.
> > > 
> > > Can you cite this from the spec please? just the "panel is capable 
> > > to do selective update without a aux frame sync" part. Or you 
> > > could just remove that line so that we can get this patch reviewed 
> > > and merged.
> > 
> > There is no such statement in spec like this, the closest that it 
> > have
> > is:
> > "When the Source device includes the optional Y-coordinate in the 
> > SDP for PSR2 Operation, as described in Table 6-12, the Sink device 
> > can implement a lower-precision GTC Slave  function, as described in 
> > Table 7-1."
> > 
> > But we know that this works by all the previous tests when enabling
> > PSR2 and I also tested it.
> 
> Please do update the comment to say so. Do you know if these tests for
> PSR2 selective update are in IGT? Or were these manual 

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

[Zhenyu Wang]

On 2018.03.27 16:42:28 +0300, Joonas Lahtinen wrote:
> Quoting Zhenyu Wang (2018-03-27 11:39:42)
> > 
> > Hi, Joonas
> > 
> > Here's this week's gvt-next-fixes queued for 4.17. One notable change
> > is to revert previous workaround for gvt context preemption, now it
> > has full support for preemption now. 
> 
> I've pulled the patches, but this revert sounds fishy. Is it something
> that should have been done together with a commit in a batch introduced
> to 4.17? To me, this sounds much like a feature patch, "enable
> pre-emption on GVT context" is even written in the tag.
> 
> So I'm inclined to drop this patch from -fixes pull.
>

The dependent fix has already been queued for 4.17 as commit 702791f7f204
("drm/i915: add schedule out notification of preempted but completed request"),
and before we could revert previous workaround, we had a regression issue which
was later resolved, so this revert was delayed for regression verification and
validation. And now it has passed our full testing, so I consider to push it for
4.17 instead of still keeping previous workaround...

> Is there some specific reason why you don't use Fixes: tagging to
> make it easier to track which patches the fixes apply to, if there are
> some?

yeah, sorry, that's missed. Will fix that against workaround commit and re-send
this pull. Will that be fine for you?

thanks

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: PGP signature
___
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/3] drm/i915/execlists: Reset ring registers on rebinding contexts (rev2)

[Patchwork]

== Series Details ==

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

== Summary ==

Series 40764v2 series starting with [1/3] drm/i915/execlists: Reset ring 
registers on rebinding contexts
https://patchwork.freedesktop.org/api/1.0/series/40764/revisions/2/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (fi-cfl-s3) fdo#100368

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:436s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:443s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:544s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:304s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:515s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:524s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:510s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-cfl-s3total:285  pass:258  dwarn:0   dfail:0   fail:1   skip:26  
time:561s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:594s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:429s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:321s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:477s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:662s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:441s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:498s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:430s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:591s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:523s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:486s

0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC 
integration manifest
f0a06fa9b3f8 drm/i915: Include the HW breadcrumb whenever we trace the 
global_seqno
46afadd21cba drm/i915/execlists: Delay updating ring register state after resume
ef3a65fcec9e drm/i915/execlists: Reset ring registers on rebinding contexts

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8513/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Patchwork]

== Series Details ==

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

== Summary ==

$ dim checkpatch origin/drm-tip
ef3a65fcec9e drm/i915/execlists: Reset ring registers on rebinding contexts
-:36: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV)
#36: FILE: drivers/gpu/drm/i915/intel_lrc.c:1275:
+   ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head;
   ^

total: 0 errors, 0 warnings, 1 checks, 7 lines checked
46afadd21cba drm/i915/execlists: Delay updating ring register state after resume
-:68: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV)
#68: FILE: drivers/gpu/drm/i915/intel_lrc.c:2566:
+   ce->lrc_reg_state[CTX_RING_HEAD+1] = 0;
   ^

-:69: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV)
#69: FILE: drivers/gpu/drm/i915/intel_lrc.c:2567:
+   ce->lrc_reg_state[CTX_RING_TAIL+1] = 0;
   ^

total: 0 errors, 0 warnings, 2 checks, 52 lines checked
f0a06fa9b3f8 drm/i915: Include the HW breadcrumb whenever we trace the 
global_seqno

___
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 [v5,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev5)

[Patchwork]

== Series Details ==

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

== Summary ==

Series 40503v5 series starting with [v5,1/2] drm/i915/cnl: Implement 
WaProgramMgsrForCorrectSliceSpecificMmioReads
https://patchwork.freedesktop.org/api/1.0/series/40503/revisions/5/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (fi-snb-2520m) fdo#100368

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:431s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:448s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:545s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:299s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:515s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:530s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:512s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:508s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:582s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:428s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:320s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:423s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:473s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:433s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:473s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:658s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:444s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:429s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:285  pass:244  dwarn:0   dfail:0   fail:1   skip:40  
time:552s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:248  dwarn:11  dfail:0   fail:0   skip:26  
time:515s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:488s

0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC 
integration manifest
791751056113 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
4c68480f0be0 drm/i915/cnl: Implement 
WaProgramMgsrForCorrectSliceSpecificMmioReads

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8512/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Paulo Zanoni]

Em Ter, 2018-03-27 às 15:42 -0700, Paulo Zanoni escreveu:
> Em Sex, 2018-03-23 às 16:28 +, Lionel Landwerlin escreveu:
> > Hi Mika,
> > 
> > Even after this series, we're still missing support for reading
> > the 
> > timestamp frequency (read_timestamp_frequency in
> > intel_device_info.c).
> > I'm pretty sure someone wrote a patch for it. Do you any idea?
> > 
> > If not, I can send something.
> 
> Yes, we have them. I'll see if I missed them while upstreaming and
> resend in that case.

https://patchwork.freedesktop.org/patch/196710/

Hey Lionel, the Reviewed-by stamp you gave on the patch was before we
upstreamed it, so we need you (or someone else) to re-check the patch
and re-issue the reviewed-by tag. We do this because of the rebasing
that happened between the R-B tag and the upstreaming, since issues can
be introduced in between. If you can check the patch again and validate
the r-b tag (or point the issues) then we can move forward and
hopefully merge it.

Thanks,
Paulo

> 
> > 
> > Thanks,
> > 
> > -
> > Lionel
> > 
> > On 16/03/18 12:14, Mika Kuoppala wrote:
> > > From: Oscar Mateo 
> > > 
> > > In Gen11, the Video Decode engines (aka VDBOX, aka VCS, aka BSD)
> > > and the
> > > Video Enhancement engines (aka VEBOX, aka VECS) could be fused
> > > off.
> > > Also,
> > > each VDBOX and VEBOX has its own power well, which only exist if
> > > the related
> > > engine exists in the HW.
> > > 
> > > Unfortunately, we have a Catch-22 situation going on: we need the
> > > blitter
> > > forcewake to read the register with the fuse info, but we cannot
> > > initialize
> > > the forcewake domains without knowin about the engines present in
> > > the HW.
> > > We workaround this problem by allowing the initialization of all
> > > forcewake
> > > domains and then pruning the fused off ones, as per the fuse
> > > information.
> > > 
> > > Bspec: 20680
> > > 
> > > v2: We were shifting incorrectly for vebox disable (Vinay)
> > > 
> > > v3: Assert mmio is ready and warn if we have attempted to
> > > initialize
> > >  forcewake for fused-off engines (Paulo)
> > > 
> > > v4:
> > >- Use INTEL_GEN in new code (Tvrtko)
> > >- Shorter local variable (Tvrtko, Michal)
> > >- Keep "if (!...) continue" style (Tvrtko)
> > >- No unnecessary BUG_ON (Tvrtko)
> > >- WARN_ON and cleanup if wrong mask (Tvrtko, Michal)
> > >- Use I915_READ_FW (Michal)
> > >- Use I915_MAX_VCS/VECS macros (Michal)
> > > 
> > > v5: Rebased by Rodrigo fixing conflicts on top of:
> > >  commit 33def1ff7b0 ("drm/i915: Simplify intel_engines_init")
> > > 
> > > v6: Fix v5. Remove info->num_rings. (by Oscar)
> > > 
> > > v7: Rebase (Rodrigo).
> > > 
> > > v8:
> > >-
> > > s/intel_device_info_fused_off_engines/intel_device_info_init_mmio
> > > (Chris)
> > >- Make vdbox_disable & vebox_disable local variables (Chris)
> > > 
> > > v9:
> > >- Move function declaration to intel_device_info.h (Michal)
> > >- Missing indent in bit fields definitions (Michal)
> > >- When RC6 is enabled by BIOS, the fuse register cannot be
> > > read
> > > until
> > >  the blitter powerwell is awake. Shuffle where the fuse is
> > > read, prune
> > >  the forcewake domains after the fact and change the commit
> > > message
> > >  accordingly (Vinay, Sagar, Chris).
> > > 
> > > v10:
> > >- Improved commit message (Sagar)
> > >- New line in header file (Sagar)
> > >- Specify the message in fw_domain_reset applies to ICL+
> > > (Sagar)
> > > 
> > > Cc: Paulo Zanoni 
> > > Cc: Vinay Belgaumkar 
> > > Cc: Tvrtko Ursulin 
> > > Cc: Michal Wajdeczko 
> > > Cc: Chris Wilson 
> > > Cc: Daniele Ceraolo Spurio 
> > > Cc: Sagar Arun Kamble 
> > > Signed-off-by: Rodrigo Vivi 
> > > Signed-off-by: Oscar Mateo 
> > > ---
> > >   drivers/gpu/drm/i915/i915_drv.c  |  4 +++
> > >   drivers/gpu/drm/i915/i915_reg.h  |  5 +++
> > >   drivers/gpu/drm/i915/intel_device_info.c | 47
> > > +++
> > >   drivers/gpu/drm/i915/intel_device_info.h |  2 ++
> > >   drivers/gpu/drm/i915/intel_uncore.c  | 56
> > > 
> > >   drivers/gpu/drm/i915/intel_uncore.h  |  1 +
> > >   6 files changed, 115 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 3df5193487f3..83df8e21cec0 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -1033,6 +1033,10 @@ static int i915_driver_init_mmio(struct
> > > drm_i915_private *dev_priv)
> > >   
> > >   intel_uncore_init(dev_priv);
> > >   
> > > + intel_device_info_init_mmio(dev_priv);
> > > +
> > > + intel_uncore_prune(dev_priv);
> > > 

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

[Patchwork]

== Series Details ==

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

== Summary ==

Series 40768v1 series starting with [1/2] drm/dp: Move DPCD_REV_XX to 
drm_dp_helper
https://patchwork.freedesktop.org/api/1.0/series/40768/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:542s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:519s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:529s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:514s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:591s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:423s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:326s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:467s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:517s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:668s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:441s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:543s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:505s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:431s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:520s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:485s

0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC 
integration manifest
553565ba74e0 drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 
1.4
d10b9c355a96 drm/dp: Move DPCD_REV_XX to drm_dp_helper

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8511/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Quoting Tomasz Lis (2018-03-27 16:17:59)
> The patch adds support of preempt-to-idle requesting by setting a proper
> bit within Execlist Control Register, and receiving preemption result from
> Context Status Buffer.
> 
> Preemption in previous gens required a special batch buffer to be executed,
> so the Command Streamer never preempted to idle directly. In Icelake it is
> possible, as there is a hardware mechanism to inform the kernel about
> status of the preemption request.
> 
> This patch does not cover using the new preemption mechanism when GuC is
> active.
> 
> Bspec: 18922
> Signed-off-by: Tomasz Lis 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
>  drivers/gpu/drm/i915/i915_pci.c  |  3 ++-
>  drivers/gpu/drm/i915/intel_device_info.h |  1 +
>  drivers/gpu/drm/i915/intel_lrc.c | 45 
> +++-
>  drivers/gpu/drm/i915/intel_lrc.h |  1 +
>  5 files changed, 45 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 800230b..c32580b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2514,6 +2514,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> ((dev_priv)->info.has_logical_ring_elsq)
>  #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
> ((dev_priv)->info.has_logical_ring_preemption)
> +#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
> +   ((dev_priv)->info.has_hw_preempt_to_idle)
>  
>  #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
>  
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 4364922..66b6700 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -595,7 +595,8 @@ static const struct intel_device_info 
> intel_cannonlake_info = {
> GEN(11), \
> .ddb_size = 2048, \
> .has_csr = 0, \
> -   .has_logical_ring_elsq = 1
> +   .has_logical_ring_elsq = 1, \
> +   .has_hw_preempt_to_idle = 1
>  
>  static const struct intel_device_info intel_icelake_11_info = {
> GEN11_FEATURES,
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 933e316..4eb97b5 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -98,6 +98,7 @@ enum intel_platform {
> func(has_logical_ring_contexts); \
> func(has_logical_ring_elsq); \
> func(has_logical_ring_preemption); \
> +   func(has_hw_preempt_to_idle); \
> func(has_overlay); \
> func(has_pooled_eu); \
> func(has_psr); \
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ba7f783..1a22de4 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -153,6 +153,7 @@
>  #define GEN8_CTX_STATUS_ACTIVE_IDLE(1 << 3)
>  #define GEN8_CTX_STATUS_COMPLETE   (1 << 4)
>  #define GEN8_CTX_STATUS_LITE_RESTORE   (1 << 15)
> +#define GEN11_CTX_STATUS_PREEMPT_IDLE  (1 << 29)
>  
>  #define GEN8_CTX_STATUS_COMPLETED_MASK \
>  (GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
> @@ -183,7 +184,9 @@ static inline bool need_preempt(const struct 
> intel_engine_cs *engine,
> const struct i915_request *last,
> int prio)
>  {
> -   return engine->i915->preempt_context && prio > max(rq_prio(last), 0);
> +   return (engine->i915->preempt_context ||
> +   HAS_HW_PREEMPT_TO_IDLE(engine->i915)) &&

Well, you haven't actually disabled allocating the preempt_context so...

But at any rate, making this an engine->flag would eliminate one pointer
dance.

> +prio > max(rq_prio(last), 0);
>  }
>  
>  /**
> @@ -535,6 +538,25 @@ static void inject_preempt_context(struct 
> intel_engine_cs *engine)
> execlists_set_active(>execlists, EXECLISTS_ACTIVE_PREEMPT);
>  }
>  
> +static void gen11_preempt_to_idle(struct intel_engine_cs *engine)
> +{
> +   struct intel_engine_execlists *execlists = >execlists;
> +
> +   GEM_TRACE("%s\n", engine->name);
> +
> +   /*
> +* hardware which HAS_HW_PREEMPT_TO_IDLE(), always also
> +* HAS_LOGICAL_RING_ELSQ(), so we can assume ctrl_reg is set
> +*/
> +   GEM_BUG_ON(execlists->ctrl_reg != NULL);
> +
> +   /* trigger preemption to idle */
> +   writel(EL_CTRL_PREEMPT_TO_IDLE, execlists->ctrl_reg);

Future plans? Because just inserting the branch into the setter of
inject_preempt_context() resolves a lot of conflicts with other work.

> @@ -962,10 +987,13 @@ static void execlists_submission_tasklet(unsigned long 
> data)
>   status, buf[2*head + 1],
>   execlists->active);
>  
> -   if (status & 

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

[Patchwork]

== Series Details ==

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

== Summary ==

$ dim checkpatch origin/drm-tip
d10b9c355a96 drm/dp: Move DPCD_REV_XX to drm_dp_helper
553565ba74e0 drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 
1.4
-:26: WARNING:TYPO_SPELLING: 'seperate' may be misspelled - perhaps 'separate'?
#26: 
V9: Strip out DPCD_REV_XX into seperate patch

total: 0 errors, 1 warnings, 0 checks, 43 lines checked

___
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/guc: Support for Guc responses and requests (rev5)

[Patchwork]

== Series Details ==

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

== Summary ==

Series 28393v5 drm/i915/guc: Support for Guc responses and requests
https://patchwork.freedesktop.org/api/1.0/series/28393/revisions/5/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#104951

fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:543s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:305s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:517s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:523s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:510s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-y3total:285  pass:258  dwarn:1   dfail:0   fail:0   skip:26  
time:586s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:428s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:321s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:412s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:475s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:437s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:464s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:657s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:432s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:584s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:513s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:487s

0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC 
integration manifest
a5e34053ad2d HAX: Enable GuC for CI
a87384b1c925 drm/i915/guc: Trace messages from CT while in debug
fc751997667a drm/i915/guc: Handle default action received over CT
5f5795f24ab3 drm/i915/guc: Prepare to process incoming requests from CT
f631277cfde8 drm/i915/guc: Implement response handling in send_ct()
afa15bb29b63 drm/i915/guc: Use better name for helper wait function
b7159298221d drm/i915/guc: Prepare to handle messages from CT RECV buffer
58acb5af66e4 drm/i915/guc: Make event handler a virtual function
55dddb9679fe drm/i915/guc: Implement response handling in send_mmio()
e0bdc40b09d3 drm/i915/guc: Prepare send() function to accept bigger response
02a3b07b6d97 drm/i915/guc: Add support for data reporting in GuC responses
8da80e5819e2 drm/i915/guc: Add documentation for MMIO based communication

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8510/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Quoting Zhang, Yunwei (2018-03-27 23:49:27)
> 
> 
> On 3/27/2018 3:27 PM, Chris Wilson wrote:
> > Quoting Yunwei Zhang (2018-03-27 23:14:16)
> >> WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
> >> read into Slice/Subslice specific registers, MCR packet control
> >> register(0xFDC) needs to be programmed to point to any enabled
> >> slice/subslice pair. Otherwise, incorrect value will be returned.
> >>
> >> However, that means each subsequent MMIO read will be forwarded to a
> >> specific slice/subslice combination as read is unicast. This is OK since
> >> slice/subslice specific register values are consistent in almost all cases
> >> across slice/subslice. There are rare occasions such as INSTDONE that this
> >> value will be dependent on slice/subslice combo, in such cases, we need to
> >> program 0xFDC and recover this after. This is already covered by
> >> read_subslice_reg.
> >>
> >> Also, 0xFDC will lose its information after TDR/engine reset/power state
> >> change.
> >>
> >> References: HSD#1405586840, BSID#0575
> >>
> >> v2:
> >>   - use fls() instead of find_last_bit() (Chris)
> >>   - added INTEL_SSEU to extract sseu from device info. (Chris)
> >> v3:
> >>   - rebase on latest tip
> >> v5:
> >>   - Added references (Mika)
> >>   - Change the ordered of passing arguments and etc. (Ursulin)
> >>
> >> Cc: Oscar Mateo 
> >> Cc: Michel Thierry 
> >> Cc: Joonas Lahtinen 
> >> Cc: Chris Wilson 
> >> Cc: Mika Kuoppala 
> >> Cc: Tvrtko Ursulin 
> >> Signed-off-by: Yunwei Zhang 
> >> ---
> >>   drivers/gpu/drm/i915/intel_engine_cs.c | 39 
> >> --
> >>   1 file changed, 37 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> >> b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> index de09fa4..4c78d1e 100644
> >> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> >> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> @@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct 
> >> drm_i915_private *i915, int type)
> >>  }
> >>   }
> >>   
> >> +static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
> >> +{
> >> +   const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
> >> +   u32 slice = fls(sseu->slice_mask);
> >> +   u32 subslice = fls(sseu->subslice_mask[slice]);
> >> +
> >> +   mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
> >> +   mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> >> +
> >> +   return mcr;
> >> +}
> >> +
> >> +static void wa_init_mcr(struct drm_i915_private *dev_priv)
> >> +{
> >> +   u32 mcr;
> >> +
> >> +   mcr = I915_READ(GEN8_MCR_SELECTOR);
> >> +   mcr = calculate_mcr(dev_priv, mcr);
> >> +   I915_WRITE(GEN8_MCR_SELECTOR, mcr);
> >> +}
> >> +
> >>   static inline uint32_t
> >>   read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
> >>int subslice, i915_reg_t reg)
> >> @@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv, 
> >> int slice,
> >>  intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
> >>   
> >>  mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
> >> +
> >>  /*
> >>   * The HW expects the slice and sublice selectors to be reset to 0
> >>   * after reading out the registers.
> >>   */
> >> -   WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
> >> +   WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
> >> +(mcr & mcr_slice_subslice_mask));
> >>  mcr &= ~mcr_slice_subslice_mask;
> >>  mcr |= mcr_slice_subslice_select;
> >>  I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
> >>   
> >>  ret = I915_READ_FW(reg);
> >>   
> >> -   mcr &= ~mcr_slice_subslice_mask;
> >> +   /*
> >> +* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
> >> +* expects mcr to be programed to a enabled slice/subslice pair
> >> +* before any MMIO read into slice/subslice register
> >> +*/
> > So the read was above, where we did set the subslice_select
> > appropriately. Here we are resetting back to 0 *after* the read, as the
> > comment before indicates.
> >
> > So what are you trying to accomplish with this patch? Other than leaving
> > the code in conflict with itself.
> > -Chris
> Hi Chris,
> 
> The comment mentioned 0xFDC needs to be reset to 0 was before this WA 
> was introduced, in later HW, this WA requires 0xFDC to be programmed to 
> a enabled slice/subslice.
> 
> What this patch does it to initialize 0xFDC once at the initialization 
> (also it will be called after engine reset/TDR/coming out of c6) and 
> make sure every time it is changed, it will be reprogrammed to a enabled 
> slice/subslice so that a MMIO
> read will get the correct 

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

[Chris Wilson]

Now that we reload both RING_HEAD and RING_TAIL when rebinding the
context, we do not need to scrub those registers immediately on resume.

v2: Handle the perma-pinned contexts.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 31 ---
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 654634254b64..2bf5128efb26 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2536,13 +2536,14 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
return ret;
 }
 
-void intel_lr_context_resume(struct drm_i915_private *dev_priv)
+void intel_lr_context_resume(struct drm_i915_private *i915)
 {
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
enum intel_engine_id id;
 
-   /* Because we emit WA_TAIL_DWORDS there may be a disparity
+   /*
+* Because we emit WA_TAIL_DWORDS there may be a disparity
 * between our bookkeeping in ce->ring->head and ce->ring->tail and
 * that stored in context. As we only write new commands from
 * ce->ring->tail onwards, everything before that is junk. If the GPU
@@ -2552,27 +2553,19 @@ void intel_lr_context_resume(struct drm_i915_private 
*dev_priv)
 * So to avoid that we reset the context images upon resume. For
 * simplicity, we just zero everything out.
 */
-   list_for_each_entry(ctx, _priv->contexts.list, link) {
-   for_each_engine(engine, dev_priv, id) {
-   struct intel_context *ce = >engine[engine->id];
-   u32 *reg;
-
-   if (!ce->state)
-   continue;
+   list_for_each_entry(ctx, >contexts.list, link) {
+   for_each_engine(engine, i915, id) {
+   struct intel_context *ce = >engine[id];
 
-   reg = i915_gem_object_pin_map(ce->state->obj,
- I915_MAP_WB);
-   if (WARN_ON(IS_ERR(reg)))
+   if (!ce->ring)
continue;
 
-   reg += LRC_STATE_PN * PAGE_SIZE / sizeof(*reg);
-   reg[CTX_RING_HEAD+1] = 0;
-   reg[CTX_RING_TAIL+1] = 0;
-
-   ce->state->obj->mm.dirty = true;
-   i915_gem_object_unpin_map(ce->state->obj);
-
intel_ring_reset(ce->ring, 0);
+
+   if (ce->pin_count) { /* otherwise done in context_pin */
+   ce->lrc_reg_state[CTX_RING_HEAD+1] = 0;
+   ce->lrc_reg_state[CTX_RING_TAIL+1] = 0;
+   }
}
}
 }
-- 
2.16.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Quoting Chris Wilson (2018-03-27 22:01:56)
> Now that we reload both RING_HEAD and RING_TAIL when rebinding the
> context, we do not need to scrub those registers immediately on resume.

So CI reports that contrary to my belief, we didn't do a
i915_gem_contexts_lost() across suspend. Hmm, nope that's definitely
there in i915_gem_suspend, so all contexts should have been unpinned.
Oh, silly me, that doesn't account for the extra perma-pin we keep on
the kernel contexts to avoid them being evicted.

Ok, that's annoying and has some ramifications for the first patch if we
can contrive a wedging to be injected into the kernel context. Hmm, an
outside possibility to be sure as it would need a full device reset at
precisely the same time as a i915_gem_switch_to_kernel_context,
exceedingly rare. Not so rare as having the kernel context be an
innocent victim (the last context on an idle engine) - that's not
impacted by this, as there we know the breadcrumb has already been
emitted so RING_HEAD will not roll back and reemit on recovery.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Patchwork]

== Series Details ==

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

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/guc: Add documentation for MMIO based communication
Okay!

Commit: drm/i915/guc: Add support for data reporting in GuC responses
Okay!

Commit: drm/i915/guc: Prepare send() function to accept bigger response
Okay!

Commit: drm/i915/guc: Implement response handling in send_mmio()
Okay!

Commit: drm/i915/guc: Make event handler a virtual function
Okay!

Commit: drm/i915/guc: Prepare to handle messages from CT RECV buffer
Okay!

Commit: drm/i915/guc: Use better name for helper wait function
Okay!

Commit: drm/i915/guc: Implement response handling in send_ct()
Okay!

Commit: drm/i915/guc: Prepare to process incoming requests from CT
Okay!

Commit: drm/i915/guc: Handle default action received over CT
Okay!

Commit: drm/i915/guc: Trace messages from CT while in debug
+Error in reading or end of file.

Commit: HAX: Enable GuC for CI
Okay!

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Patchwork]

== Series Details ==

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

== Summary ==

Series 40764v1 series starting with [1/3] drm/i915/execlists: Reset ring 
registers on rebinding contexts
https://patchwork.freedesktop.org/api/1.0/series/40764/revisions/1/mbox/

 Possible new issues:

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-bdw-gvtdvm)
pass   -> INCOMPLETE (fi-bsw-n3050)
pass   -> INCOMPLETE (fi-bxt-j4205)
pass   -> INCOMPLETE (fi-cfl-8700k)
pass   -> INCOMPLETE (fi-cfl-s3)
pass   -> INCOMPLETE (fi-cfl-u)
pass   -> INCOMPLETE (fi-glk-1)
pass   -> INCOMPLETE (fi-kbl-7500u)
pass   -> INCOMPLETE (fi-kbl-r)

 Known issues:

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-bdw-5557u) fdo#104311
pass   -> INCOMPLETE (fi-cnl-y3) fdo#105086
pass   -> INCOMPLETE (fi-kbl-7567u) fdo#103665
pass   -> INCOMPLETE (fi-skl-6260u) fdo#104108 +5

fdo#104311 https://bugs.freedesktop.org/show_bug.cgi?id=104311
fdo#105086 https://bugs.freedesktop.org/show_bug.cgi?id=105086
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108

fi-bdw-5557u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-bdw-gvtdvmtotal:108  pass:103  dwarn:0   dfail:0   fail:0   skip:4  
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:299s
fi-bxt-j4205 total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:529s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:514s
fi-cfl-8700k total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-cfl-s3total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-cfl-u total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-cnl-y3total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:429s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:321s
fi-glk-1 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-kbl-7567u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-kbl-r total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:658s
fi-skl-6260u total:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-skl-6600u total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-6700k2total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-6770hqtotal:108  pass:104  dwarn:0   dfail:0   fail:0   skip:3  
fi-skl-guc   total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-gvtdvmtotal:108  pass:103  dwarn:0   dfail:0   fail:0   skip:4  
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:561s
Blacklisted hosts:
fi-cnl-psr   total:108  pass:96   dwarn:0   dfail:0   fail:0   skip:11 
fi-glk-j4005 failed to collect. IGT log at Patchwork_8509/fi-glk-j4005/run0.log

0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC 
integration manifest
515b83d66afc drm/i915: Include the HW breadcrumb whenever we trace the 
global_seqno
a9473b05fca4 drm/i915/execlists: Delay updating ring register state after resume
f73f2b30c417 drm/i915/execlists: Reset ring registers on rebinding contexts

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8509/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michel Thierry]

On 3/27/2018 2:41 PM, Michal Wajdeczko wrote:

When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.

v2:  filter disabled messages (Daniele)

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Reviewed-by: Michel Thierry  #1

  ^ still applies for v2, but I would wait for Daniele's blessing


Cc: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/intel_guc.c| 8 
  drivers/gpu/drm/i915/intel_guc.h| 1 +
  drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
  3 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..d77dde7 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,14 @@ void intel_guc_to_host_event_handler_mmio(struct intel_guc 
*guc)
I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
spin_unlock(>irq_lock);
  
+	intel_guc_to_host_process_recv_msg(guc, msg);

+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{


(as I said before, this will need to change later on to receive more 
than jut data[1]/payload anyway)



+   /* Make sure to handle only enabled messages */
+   msg &= guc->msg_enabled_mask;
+
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
   INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(>log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len,
  void intel_guc_to_host_event_handler(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
  int intel_guc_sample_forcewake(struct intel_guc *guc);
  int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
  int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
  static void ct_process_request(struct intel_guc_ct *ct,
   u32 action, u32 len, const u32 *payload)
  {
+   struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+   case INTEL_GUC_ACTION_DEFAULT:
+   if (unlikely(len < 1))
+   goto fail_unexpected;
+   intel_guc_to_host_process_recv_msg(guc, *payload);
+   break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
  action, 4 * len, payload);
break;


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Zhang, Yunwei]

On 3/27/2018 3:27 PM, Chris Wilson wrote:

Quoting Yunwei Zhang (2018-03-27 23:14:16)

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

However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.

Also, 0xFDC will lose its information after TDR/engine reset/power state
change.

References: HSD#1405586840, BSID#0575

v2:
  - use fls() instead of find_last_bit() (Chris)
  - added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
  - rebase on latest tip
v5:
  - Added references (Mika)
  - Change the ordered of passing arguments and etc. (Ursulin)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 39 --
  1 file changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index de09fa4..4c78d1e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private 
*i915, int type)
 }
  }
  
+static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)

+{
+   const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+   u32 slice = fls(sseu->slice_mask);
+   u32 subslice = fls(sseu->subslice_mask[slice]);
+
+   mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+   mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+
+   return mcr;
+}
+
+static void wa_init_mcr(struct drm_i915_private *dev_priv)
+{
+   u32 mcr;
+
+   mcr = I915_READ(GEN8_MCR_SELECTOR);
+   mcr = calculate_mcr(dev_priv, mcr);
+   I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+}
+
  static inline uint32_t
  read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
   int subslice, i915_reg_t reg)
@@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv, int 
slice,
 intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
  
 mcr = I915_READ_FW(GEN8_MCR_SELECTOR);

+
 /*
  * The HW expects the slice and sublice selectors to be reset to 0
  * after reading out the registers.
  */
-   WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+   WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
+(mcr & mcr_slice_subslice_mask));
 mcr &= ~mcr_slice_subslice_mask;
 mcr |= mcr_slice_subslice_select;
 I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
  
 ret = I915_READ_FW(reg);
  
-   mcr &= ~mcr_slice_subslice_mask;

+   /*
+* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
+* expects mcr to be programed to a enabled slice/subslice pair
+* before any MMIO read into slice/subslice register
+*/

So the read was above, where we did set the subslice_select
appropriately. Here we are resetting back to 0 *after* the read, as the
comment before indicates.

So what are you trying to accomplish with this patch? Other than leaving
the code in conflict with itself.
-Chris

Hi Chris,

The comment mentioned 0xFDC needs to be reset to 0 was before this WA 
was introduced, in later HW, this WA requires 0xFDC to be programmed to 
a enabled slice/subslice.


What this patch does it to initialize 0xFDC once at the initialization 
(also it will be called after engine reset/TDR/coming out of c6) and 
make sure every time it is changed, it will be reprogrammed to a enabled 
slice/subslice so that a MMIO
read will get the correct value. read_subslice_reg changes the 0xFDC 
value and if it is set to 0, it will cause MMIO read to return invalid 
value for s/ss specific registers.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Paulo Zanoni]

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

Yes, we have them. I'll see if I missed them while upstreaming and
resend in that case.

> 
> Thanks,
> 
> -
> Lionel
> 
> On 16/03/18 12:14, Mika Kuoppala wrote:
> > From: Oscar Mateo 
> > 
> > In Gen11, the Video Decode engines (aka VDBOX, aka VCS, aka BSD)
> > and the
> > Video Enhancement engines (aka VEBOX, aka VECS) could be fused off.
> > Also,
> > each VDBOX and VEBOX has its own power well, which only exist if
> > the related
> > engine exists in the HW.
> > 
> > Unfortunately, we have a Catch-22 situation going on: we need the
> > blitter
> > forcewake to read the register with the fuse info, but we cannot
> > initialize
> > the forcewake domains without knowin about the engines present in
> > the HW.
> > We workaround this problem by allowing the initialization of all
> > forcewake
> > domains and then pruning the fused off ones, as per the fuse
> > information.
> > 
> > Bspec: 20680
> > 
> > v2: We were shifting incorrectly for vebox disable (Vinay)
> > 
> > v3: Assert mmio is ready and warn if we have attempted to
> > initialize
> >  forcewake for fused-off engines (Paulo)
> > 
> > v4:
> >- Use INTEL_GEN in new code (Tvrtko)
> >- Shorter local variable (Tvrtko, Michal)
> >- Keep "if (!...) continue" style (Tvrtko)
> >- No unnecessary BUG_ON (Tvrtko)
> >- WARN_ON and cleanup if wrong mask (Tvrtko, Michal)
> >- Use I915_READ_FW (Michal)
> >- Use I915_MAX_VCS/VECS macros (Michal)
> > 
> > v5: Rebased by Rodrigo fixing conflicts on top of:
> >  commit 33def1ff7b0 ("drm/i915: Simplify intel_engines_init")
> > 
> > v6: Fix v5. Remove info->num_rings. (by Oscar)
> > 
> > v7: Rebase (Rodrigo).
> > 
> > v8:
> >-
> > s/intel_device_info_fused_off_engines/intel_device_info_init_mmio
> > (Chris)
> >- Make vdbox_disable & vebox_disable local variables (Chris)
> > 
> > v9:
> >- Move function declaration to intel_device_info.h (Michal)
> >- Missing indent in bit fields definitions (Michal)
> >- When RC6 is enabled by BIOS, the fuse register cannot be read
> > until
> >  the blitter powerwell is awake. Shuffle where the fuse is
> > read, prune
> >  the forcewake domains after the fact and change the commit
> > message
> >  accordingly (Vinay, Sagar, Chris).
> > 
> > v10:
> >- Improved commit message (Sagar)
> >- New line in header file (Sagar)
> >- Specify the message in fw_domain_reset applies to ICL+ (Sagar)
> > 
> > Cc: Paulo Zanoni 
> > Cc: Vinay Belgaumkar 
> > Cc: Tvrtko Ursulin 
> > Cc: Michal Wajdeczko 
> > Cc: Chris Wilson 
> > Cc: Daniele Ceraolo Spurio 
> > Cc: Sagar Arun Kamble 
> > Signed-off-by: Rodrigo Vivi 
> > Signed-off-by: Oscar Mateo 
> > ---
> >   drivers/gpu/drm/i915/i915_drv.c  |  4 +++
> >   drivers/gpu/drm/i915/i915_reg.h  |  5 +++
> >   drivers/gpu/drm/i915/intel_device_info.c | 47
> > +++
> >   drivers/gpu/drm/i915/intel_device_info.h |  2 ++
> >   drivers/gpu/drm/i915/intel_uncore.c  | 56
> > 
> >   drivers/gpu/drm/i915/intel_uncore.h  |  1 +
> >   6 files changed, 115 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 3df5193487f3..83df8e21cec0 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1033,6 +1033,10 @@ static int i915_driver_init_mmio(struct
> > drm_i915_private *dev_priv)
> >   
> > intel_uncore_init(dev_priv);
> >   
> > +   intel_device_info_init_mmio(dev_priv);
> > +
> > +   intel_uncore_prune(dev_priv);
> > +
> > intel_uc_init_mmio(dev_priv);
> >   
> > ret = intel_engines_init_mmio(dev_priv);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index cf7c837d6a09..982e72e73e99 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -2545,6 +2545,11 @@ enum i915_power_well_id {
> >   #define GEN10_EU_DISABLE3 _MMIO(0x9140)
> >   #define   GEN10_EU_DIS_SS_MASK0xff
> >   
> > +#define GEN11_GT_VEBOX_VDBOX_DISABLE   _MMIO(0x9140)
> > +#define   GEN11_GT_VDBOX_DISABLE_MASK  0xff
> > +#define   GEN11_GT_VEBOX_DISABLE_SHIFT 16
> > +#define   GEN11_GT_VEBOX_DISABLE_MASK  (0xff <<
> > GEN11_GT_VEBOX_DISABLE_SHIFT)
> > +
> >   #define GEN6_BSD_SLEEP_PSMI_CONTROL   _MMIO(0x12050)
> >   #define   

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

[Patchwork]

== Series Details ==

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

== Summary ==

$ dim checkpatch origin/drm-tip
f73f2b30c417 drm/i915/execlists: Reset ring registers on rebinding contexts
-:36: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV)
#36: FILE: drivers/gpu/drm/i915/intel_lrc.c:1275:
+   ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head;
   ^

total: 0 errors, 0 warnings, 1 checks, 7 lines checked
a9473b05fca4 drm/i915/execlists: Delay updating ring register state after resume
515b83d66afc drm/i915: Include the HW breadcrumb whenever we trace the 
global_seqno

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Quoting Yunwei Zhang (2018-03-27 23:14:16)
> WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
> read into Slice/Subslice specific registers, MCR packet control
> register(0xFDC) needs to be programmed to point to any enabled
> slice/subslice pair. Otherwise, incorrect value will be returned.
> 
> However, that means each subsequent MMIO read will be forwarded to a
> specific slice/subslice combination as read is unicast. This is OK since
> slice/subslice specific register values are consistent in almost all cases
> across slice/subslice. There are rare occasions such as INSTDONE that this
> value will be dependent on slice/subslice combo, in such cases, we need to
> program 0xFDC and recover this after. This is already covered by
> read_subslice_reg.
> 
> Also, 0xFDC will lose its information after TDR/engine reset/power state
> change.
> 
> References: HSD#1405586840, BSID#0575
> 
> v2:
>  - use fls() instead of find_last_bit() (Chris)
>  - added INTEL_SSEU to extract sseu from device info. (Chris)
> v3:
>  - rebase on latest tip
> v5:
>  - Added references (Mika)
>  - Change the ordered of passing arguments and etc. (Ursulin)
> 
> Cc: Oscar Mateo 
> Cc: Michel Thierry 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Yunwei Zhang 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 39 
> --
>  1 file changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index de09fa4..4c78d1e 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private 
> *i915, int type)
> }
>  }
>  
> +static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
> +{
> +   const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
> +   u32 slice = fls(sseu->slice_mask);
> +   u32 subslice = fls(sseu->subslice_mask[slice]);
> +
> +   mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
> +   mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> +
> +   return mcr;
> +}
> +
> +static void wa_init_mcr(struct drm_i915_private *dev_priv)
> +{
> +   u32 mcr;
> +
> +   mcr = I915_READ(GEN8_MCR_SELECTOR);
> +   mcr = calculate_mcr(dev_priv, mcr);
> +   I915_WRITE(GEN8_MCR_SELECTOR, mcr);
> +}
> +
>  static inline uint32_t
>  read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
>   int subslice, i915_reg_t reg)
> @@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv, 
> int slice,
> intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
>  
> mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
> +
> /*
>  * The HW expects the slice and sublice selectors to be reset to 0
>  * after reading out the registers.
>  */
> -   WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
> +   WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
> +(mcr & mcr_slice_subslice_mask));
> mcr &= ~mcr_slice_subslice_mask;
> mcr |= mcr_slice_subslice_select;
> I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
>  
> ret = I915_READ_FW(reg);
>  
> -   mcr &= ~mcr_slice_subslice_mask;
> +   /*
> +* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
> +* expects mcr to be programed to a enabled slice/subslice pair
> +* before any MMIO read into slice/subslice register
> +*/

So the read was above, where we did set the subslice_select
appropriately. Here we are resetting back to 0 *after* the read, as the
comment before indicates.

So what are you trying to accomplish with this patch? Other than leaving
the code in conflict with itself.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Yunwei Zhang]

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

However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.

Also, 0xFDC will lose its information after TDR/engine reset/power state
change.

References: HSD#1405586840, BSID#0575

v2:
 - use fls() instead of find_last_bit() (Chris)
 - added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
 - rebase on latest tip
v5:
 - Added references (Mika)
 - Change the ordered of passing arguments and etc. (Ursulin)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 39 --
 1 file changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index de09fa4..4c78d1e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private 
*i915, int type)
}
 }
 
+static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
+{
+   const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+   u32 slice = fls(sseu->slice_mask);
+   u32 subslice = fls(sseu->subslice_mask[slice]);
+
+   mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+   mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+
+   return mcr;
+}
+
+static void wa_init_mcr(struct drm_i915_private *dev_priv)
+{
+   u32 mcr;
+
+   mcr = I915_READ(GEN8_MCR_SELECTOR);
+   mcr = calculate_mcr(dev_priv, mcr);
+   I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+}
+
 static inline uint32_t
 read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
  int subslice, i915_reg_t reg)
@@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv, int 
slice,
intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
 
mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
+
/*
 * The HW expects the slice and sublice selectors to be reset to 0
 * after reading out the registers.
 */
-   WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+   WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
+(mcr & mcr_slice_subslice_mask));
mcr &= ~mcr_slice_subslice_mask;
mcr |= mcr_slice_subslice_select;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
 
ret = I915_READ_FW(reg);
 
-   mcr &= ~mcr_slice_subslice_mask;
+   /*
+* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
+* expects mcr to be programed to a enabled slice/subslice pair
+* before any MMIO read into slice/subslice register
+*/
+   if (INTEL_GEN(dev_priv) < 10)
+   mcr &= ~mcr_slice_subslice_mask;
+   else
+   mcr = calculate_mcr(dev_priv, mcr);
+
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
 
intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
@@ -1307,6 +1339,9 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
struct drm_i915_private *dev_priv = engine->i915;
int ret;
 
+   /* WaProgramMgsrForCorrectSliceSpecificMmioReads: cnl */
+   wa_init_mcr(dev_priv);
+
/* WaDisableI2mCycleOnWRPort:cnl (pre-prod) */
if (IS_CNL_REVID(dev_priv, CNL_REVID_B0, CNL_REVID_B0))
I915_WRITE(GAMT_CHKN_BIT_REG,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Yunwei Zhang]

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

However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.

References: HSDES#1405586840

v2:
 - use fls instead of find_last_bit (Chris)
 - use is_power_of_2() instead of counting bit set (Chris)
v3:
 - rebase on latest tip
v5:
 - Added references (Mika)
 - Move local variable into scope where they are used (Ursulin)
 - use a new local variable to reduce long line of code (Ursulin)

Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Yunwei Zhang 
---
 drivers/gpu/drm/i915/i915_reg.h|  4 
 drivers/gpu/drm/i915/intel_engine_cs.c | 20 
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1bca695f..4f2f5e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2691,6 +2691,10 @@ enum i915_power_well_id {
 #define   GEN10_F2_SS_DIS_SHIFT18
 #define   GEN10_F2_SS_DIS_MASK (0xf << GEN10_F2_SS_DIS_SHIFT)
 
+#defineGEN10_MIRROR_FUSE3  _MMIO(0x9118)
+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK   0x0F
+
 #define GEN8_EU_DISABLE0   _MMIO(0x9134)
 #define   GEN8_EU_DIS0_S0_MASK 0xff
 #define   GEN8_EU_DIS0_S1_SHIFT24
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4c78d1e..7be7a75 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -811,6 +811,26 @@ static u32 calculate_mcr(struct drm_i915_private 
*dev_priv, u32 mcr)
 static void wa_init_mcr(struct drm_i915_private *dev_priv)
 {
u32 mcr;
+   const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+
+   /* If more than one slice are enabled, L3Banks should be all enabled */
+   if (is_power_of_2(sseu->slice_mask)) {
+   /*
+* WaProgramMgsrForL3BankSpecificMmioReads:
+* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+* enabled subslice, no need to redirect MCR packet
+*/
+   u32 slice = fls(sseu->slice_mask);
+   u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+   u8 ss_mask = sseu->subslice_mask[slice];
+   /*
+* Production silicon should have matched L3Bank and
+* subslice enabled
+*/
+   WARN_ON(!((fuse3 & GEN10_L3BANK_MASK) &
+ ((ss_mask | ss_mask >> GEN10_L3BANK_PAIR_COUNT) &
+  GEN10_L3BANK_MASK)));
+   }
 
mcr = I915_READ(GEN8_MCR_SELECTOR);
mcr = calculate_mcr(dev_priv, mcr);
-- 
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/execlists: Reset ring registers on rebinding contexts

[Patchwork]

== Series Details ==

Series: drm/i915/execlists: Reset ring registers on rebinding contexts
URL   : https://patchwork.freedesktop.org/series/40763/
State : success

== Summary ==

Series 40763v1 drm/i915/execlists: Reset ring registers on rebinding contexts
https://patchwork.freedesktop.org/api/1.0/series/40763/revisions/1/mbox/

 Known issues:

Test kms_chamelium:
Subgroup dp-edid-read:
pass   -> FAIL   (fi-kbl-7500u) fdo#102505
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (fi-skl-6770hq) fdo#100368
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> FAIL   (fi-skl-6770hq) fdo#103481

fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:447s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:540s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:522s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:512s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:570s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:513s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:590s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:428s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:326s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:470s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:433s
fi-kbl-7500u total:285  pass:259  dwarn:1   dfail:0   fail:1   skip:24  
time:472s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:515s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:662s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:285  pass:263  dwarn:0   dfail:0   fail:2   skip:20  
time:492s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:432s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:594s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:544s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:486s

0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC 
integration manifest
ad09e66d7bde drm/i915/execlists: Reset ring registers on rebinding contexts

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8508/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[matthew . s . atwood]

From: Matt Atwood 

DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.

With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.

To avoid breaking panels that are not spec compiant we now warn on
invalid values.

V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction
V7: typo
V8: Style
V9: Strip out DPCD_REV_XX into seperate patch

Signed-off-by: Matt Atwood 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_dp_helper.c | 22 ++
 include/drm/drm_dp_helper.h |  1 +
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ffe14ec..f9a8bf9 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,32 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
+ rd_interval);
+
+   if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DPCD_REV_14)
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
+ rd_interval);
+
+   if (rd_interval == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index f77746e..c1ba415 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -124,6 +124,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[matthew . s . atwood]

From: Matt Atwood 

As more differentation occurs between DP spec. Its useful to have these
as macros in a drm_dp_helper.

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/amd/display/include/dpcd_defs.h | 8 
 include/drm/drm_dp_helper.h | 5 +
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/include/dpcd_defs.h 
b/drivers/gpu/drm/amd/display/include/dpcd_defs.h
index d8e52e3..d13e0f4 100644
--- a/drivers/gpu/drm/amd/display/include/dpcd_defs.h
+++ b/drivers/gpu/drm/amd/display/include/dpcd_defs.h
@@ -28,14 +28,6 @@
 
 #include 
 
-enum dpcd_revision {
-   DPCD_REV_10 = 0x10,
-   DPCD_REV_11 = 0x11,
-   DPCD_REV_12 = 0x12,
-   DPCD_REV_13 = 0x13,
-   DPCD_REV_14 = 0x14
-};
-
 /* these are the types stored at DOWNSTREAMPORT_PRESENT */
 enum dpcd_downstream_port_type {
DOWNSTREAM_DP = 0,
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4de97e9..f77746e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
+# define DPCD_REV_100x10
+# define DPCD_REV_110x11
+# define DPCD_REV_120x12
+# define DPCD_REV_130x13
+# define DPCD_REV_140x14
 
 #define DP_MAX_LINK_RATE0x001
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Patchwork]

== Series Details ==

Series: drm/i915/execlists: Reset ring registers on rebinding contexts
URL   : https://patchwork.freedesktop.org/series/40763/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ad09e66d7bde drm/i915/execlists: Reset ring registers on rebinding contexts
-:36: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV)
#36: FILE: drivers/gpu/drm/i915/intel_lrc.c:1275:
+   ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head;
   ^

total: 0 errors, 0 warnings, 1 checks, 7 lines checked

___
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/3] drm: prefer inline over __inline__

[Patchwork]

== Series Details ==

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

== Summary ==

Series 40760v1 series starting with [1/3] drm: prefer inline over __inline__
https://patchwork.freedesktop.org/api/1.0/series/40760/revisions/1/mbox/

 Known issues:

Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-byt-n2820) fdo#104008

fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:545s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:300s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:513s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:529s
fi-byt-n2820 total:285  pass:245  dwarn:0   dfail:0   fail:1   skip:39  
time:511s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:518s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:591s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:426s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:322s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:423s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:475s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:470s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:517s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:669s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:501s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:508s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:431s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:586s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:528s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:485s

0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC 
integration manifest
7c6c58e66770 drm: make drm_core_check_feature() bool that it is
2fd0c80d2347 drm: remove old documentation comment cruft from drmP.h
a139c1128af7 drm: prefer inline over __inline__

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8507/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michal Wajdeczko]

When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.

v2:  filter disabled messages (Daniele)

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Reviewed-by: Michel Thierry  #1
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_guc.c| 8 
 drivers/gpu/drm/i915/intel_guc.h| 1 +
 drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
 3 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..d77dde7 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,14 @@ void intel_guc_to_host_event_handler_mmio(struct intel_guc 
*guc)
I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
spin_unlock(>irq_lock);
 
+   intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{
+   /* Make sure to handle only enabled messages */
+   msg &= guc->msg_enabled_mask;
+
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
   INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(>log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len,
 void intel_guc_to_host_event_handler(struct intel_guc *guc);
 void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
 void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
 int intel_guc_sample_forcewake(struct intel_guc *guc);
 int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
 int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
 static void ct_process_request(struct intel_guc_ct *ct,
   u32 action, u32 len, const u32 *payload)
 {
+   struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+   case INTEL_GUC_ACTION_DEFAULT:
+   if (unlikely(len < 1))
+   goto fail_unexpected;
+   intel_guc_to_host_process_recv_msg(guc, *payload);
+   break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
  action, 4 * len, payload);
break;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Rodrigo Vivi]

On Fri, Mar 23, 2018 at 07:34:34PM -0700, Pandiyan, Dhinakaran wrote:
> 
> On Fri, 2018-03-23 at 23:51 +, Souza, Jose wrote:
> > On Fri, 2018-03-23 at 15:59 -0700, Pandiyan, Dhinakaran wrote:
> > > 
> > > 
> > > On Thu, 2018-03-22 at 14:48 -0700, José Roberto de Souza wrote:
> > > > Move to only one place the sink requirements that the actual driver
> > > > needs to enable PSR2.
> > > > 
> > > > Also intel_psr2_config_valid() is called every time the crtc config
> > > > is computed, wasting some time every time it was checking for
> > > > Y coordinate requirement.
> > > > 
> > > > This allow us to nuke y_cord_support and some of VSC setup code
> > > > that
> > > > was handling a scenario that would never happen(PSR2 without Y
> > > > coordinate).
> > > > 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Rodrigo Vivi 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h  |  1 -
> > > >  drivers/gpu/drm/i915/intel_psr.c | 46 +---
> > > > 
> > > >  2 files changed, 19 insertions(+), 28 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 7fe00509e51a..cce32686fd75 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -603,7 +603,6 @@ struct i915_psr {
> > > > unsigned busy_frontbuffer_bits;
> > > > bool psr2_support;
> > > > bool link_standby;
> > > > -   bool y_cord_support;
> > > > bool colorimetry_support;
> > > > bool alpm;
> > > > bool has_hw_tracking;
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index d46320a451d9..23f38ab10636 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct intel_dp
> > > > *intel_dp)
> > > > intel_display_power_put(dev_priv,
> > > > psr_aux_domain(intel_dp));
> > > >  }
> > > >  
> > > > -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> > > > +static bool intel_dp_get_y_coord_required(struct intel_dp
> > > > *intel_dp)
> > > >  {
> > > > uint8_t psr_caps = 0;
> > > >  
> > > > @@ -130,22 +130,29 @@ void intel_psr_init_dpcd(struct intel_dp
> > > > *intel_dp)
> > > > drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT, intel_dp-
> > > > >psr_dpcd,
> > > >  sizeof(intel_dp->psr_dpcd));
> > > >  
> > > > -   if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> > > > +   if (intel_dp->psr_dpcd[0]) {
> > > > dev_priv->psr.sink_support = true;
> > > > DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> > > > }
> > > >  
> > > > if (INTEL_GEN(dev_priv) >= 9 &&
> > > > -   (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> > > > -
> > > > -   dev_priv->psr.sink_support = true;
> > > > -   dev_priv->psr.psr2_support = true;
> > > > +   (intel_dp->psr_dpcd[0] ==
> > > > DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
> > > > +   /*
> > > > +* All panels that supports PSR version 03h (PSR2
> > > > +
> > > > +* Y-coordinate) can handle Y-coordinates in VSC
> > > > but we are
> > > > +* only sure that it is going to be used when
> > > > required by the
> > > > +* panel. This way panel is capable to do
> > > > selective update
> > > > +* without a aux frame sync.
> > > 
> > > Can you cite this from the spec please? just the "panel is capable to
> > > do
> > > selective update without a aux frame sync" part. Or you could just
> > > remove that line so that we can get this patch reviewed and merged.
> > 
> > There is no such statement in spec like this, the closest that it have
> > is:
> > "When the Source device includes the optional Y-coordinate in the SDP
> > for PSR2 Operation, as described in Table 6-12, the Sink device can
> > implement a lower-precision GTC Slave  function, as described in Table
> > 7-1."
> > 
> > But we know that this works by all the previous tests when enabling
> > PSR2 and I also tested it.
> 
> Please do update the comment to say so. Do you know if these tests for
> PSR2 selective update are in IGT? Or were these manual tests?
> 
> Rodrigo/Vathsala, any idea how selective update was and can be tested?

nope :(

> 
> The patch as such makes sense to me
> Reviewed-by: Dhinakaran Pandiyan  if you
> update the comment.
> 
> 
> > 
> > > 
> > > 
> > > > +*
> > > > +* To support PSR version 02h and PSR version 03h
> > > > without
> > > > +* Y-coordinate requirement panels we would need
> > > > to enable
> > > > +* GTC first.
> > > > + 

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

[Daniele Ceraolo Spurio]

On 27/03/18 14:05, Michal Wajdeczko wrote:
On Tue, 27 Mar 2018 22:03:23 +0200, Michel Thierry 
 wrote:



On 3/27/2018 11:25 AM, Daniele Ceraolo Spurio wrote:

  On 26/03/18 12:48, Michal Wajdeczko wrote:

When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Reviewed-by: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_guc.c    | 5 +
  drivers/gpu/drm/i915/intel_guc.h    | 1 +
  drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
  3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index 118db81..b6d2778 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,11 @@ void 
intel_guc_to_host_event_handler_mmio(struct intel_guc *guc)

  I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
  spin_unlock(>irq_lock);
+    intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 
msg)

+{
  if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
 INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
  intel_guc_log_handle_flush_event(>log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, 
const u32 *action, u32 len,

  void intel_guc_to_host_event_handler(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 
msg);

  int intel_guc_sample_forcewake(struct intel_guc *guc);
  int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
  int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c

index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct 
intel_guc_ct *ct, const u32 *msg)

  static void ct_process_request(struct intel_guc_ct *ct,
 u32 action, u32 len, const u32 *payload)
  {
+    struct intel_guc *guc = ct_to_guc(ct);
+
  switch (action) {
+    case INTEL_GUC_ACTION_DEFAULT:
+    if (unlikely(len < 1))
+    goto fail_unexpected;
 Don't we need to remove the non-enabled messages here? i.e. like we 
do for the mmio receive:

  msg = *payload & guc->msg_enabled_mask;
 otherwise I think we'll try to process log interrupts even if the 
relay is not enabled.


In Daniele's specific example, I still think 
guc_log_enable_flush_events should have been called (and don't do 
anything inside handle_flush_event, the goal was to not serve it).


But it's true that we should filter any unexpected incoming request (& 
guc->msg_enabled_mask), and any new user should be calling 
intel_guc_enable_msg during its setup.


hmm, my understanding was that purpose of msg_enabled_mask was to:

  * Sample the log buffer flush related bits & clear them out now
  * itself from the message identity register to minimize the
  * probability of losing a flush interrupt, when there are back
  * to back flush interrupts.

and is not applicable to messages sent over CTB, as we can't miss msg.

if you still believe that filtering is required, it should not be done
here, as purpose of this function is to verify message completeness and
call actual handler, but in intel_guc_to_host_process_recv_msg(), where
format of received data is known.

/m



The problem is that now we keep the interrupts enabled even if the log 
relay is not enabled. If we handle the interrupt anyway and queue the 
flush_work (from intel_guc_log_handle_flush_event), we end up hitting:


if (WARN_ON(!intel_guc_log_relay_enabled(log)))
goto out_unlock;

inside guc_read_update_log_buffer.

I don't think that the comment you added above referred to the specific 
usage of msg_enabled_mask but more to the fact that we clean the bits 
related to the messages we're going to handle.


Daniele



Thanks,

 Daniele


+    intel_guc_to_host_process_recv_msg(guc, *payload);
+    break;
+
  default:
+fail_unexpected:
  DRM_ERROR("CT: unexpected request %x %*phn\n",
    action, 4 * len, payload);
  break;

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

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

[Pandiyan, Dhinakaran]

On Tue, 2018-03-27 at 11:26 +0100, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-03-27 02:16:22)
> > Interrupts other than the one for AUX errors are required only for debug,
> > so unmask them via debugfs when the user requests debug.
> > 
> > User can make such a request with
> > echo 1 > /dri/0/i915_edp_psr_debug
> > 
> > v2: Unroll loops (Ville)
> > Avoid resetting error mask bits.
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > Cc: Chris Wilson 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/i915_irq.c | 55 
> > +++--
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c| 54 
> > 
> >  5 files changed, 108 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 7816cd53100a..6fd801ef7cbb 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> > return 0;
> >  }
> >  
> > +static int
> > +i915_edp_psr_debug_set(void *data, u64 val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   if (val < 0  || val > 1)
> > +   return -EINVAL;
> > +
> > +   DRM_DEBUG_KMS("%s PSR debug\n", val == 1 ? "Enabling" : 
> > "Disabling");
> > +   intel_psr_debug_control(dev_priv, val);
> > +
> > +   return 0;
> > +}
> 
> A really useful trick for features like this (that we think should be
> used wherever it can) is just to enable debug while the debugfs file is
> open. igt need only do something like
>   openat(debugfs_dir, "i915_edp_psr_debug", O_RDONLY);

That is neat.

We also want to support user enabling/disabling PSR debug via shell. The
semantics get slightly confusing taking that into consideration.

For example,
1) should cat $debugfs/i915_edp_psr_debug 
also enable debug or just print the current status of debug
2) if the file is already open (debug enabled), should
echo 0 > $debugfs/i915_edp_psr_debug disable debug or check for the
refcount to drop to zero.

Choosing the correct solution and implementing it correctly feels like
we'd be over-engineering.


> and then it will be automatically released and the system returned to
> default when terminated. You can then enforce exclusive access or keep an
> open count.
> -Chris
> ___
> 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 [v5,1/8] drm/i915: Correctly handle error path in i915_gem_init_hw

[Patchwork]

== Series Details ==

Series: series starting with [v5,1/8] drm/i915: Correctly handle error path in 
i915_gem_init_hw
URL   : https://patchwork.freedesktop.org/series/40759/
State : success

== Summary ==

Series 40759v1 series starting with [v5,1/8] drm/i915: Correctly handle error 
path in i915_gem_init_hw
https://patchwork.freedesktop.org/api/1.0/series/40759/revisions/1/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:446s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:538s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:517s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:523s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:512s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:430s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:325s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:408s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:477s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:666s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:444s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:544s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:504s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:498s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:432s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:242  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:531s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:489s

0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC 
integration manifest
144a5f9809e1 HAX: Enable GuC for CI
d5e88b21ece7 drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c
a8b655ca5aa7 drm/i915/uc: Use helper functions to detect fw load status
3217ab178f2a drm/i915/uc: Use correct error code for GuC initialization failure
6eb5c9f7705a drm/i915/uc: Fully sanitize uC in uc_fini_hw
24f107d1ea1f drm/i915/guc: Restore symmetric doorbell cleanup
25a5033a07f3 drm/i915/uc: Disable GuC submission during sanitize
1dd9d26952a0 drm/i915: Correctly handle error path in i915_gem_init_hw

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8506/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michal Wajdeczko]

On Tue, 27 Mar 2018 22:03:23 +0200, Michel Thierry  
 wrote:



On 3/27/2018 11:25 AM, Daniele Ceraolo Spurio wrote:

  On 26/03/18 12:48, Michal Wajdeczko wrote:

When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Reviewed-by: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_guc.c| 5 +
  drivers/gpu/drm/i915/intel_guc.h| 1 +
  drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
  3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc.c  
b/drivers/gpu/drm/i915/intel_guc.c

index 118db81..b6d2778 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,11 @@ void intel_guc_to_host_event_handler_mmio(struct  
intel_guc *guc)

  I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
  spin_unlock(>irq_lock);
+intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32  
msg)

+{
  if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
 INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
  intel_guc_log_handle_flush_event(>log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h  
b/drivers/gpu/drm/i915/intel_guc.h

index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc,  
const u32 *action, u32 len,

  void intel_guc_to_host_event_handler(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32  
msg);

  int intel_guc_sample_forcewake(struct intel_guc *guc);
  int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
  int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c  
b/drivers/gpu/drm/i915/intel_guc_ct.c

index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct  
*ct, const u32 *msg)

  static void ct_process_request(struct intel_guc_ct *ct,
 u32 action, u32 len, const u32 *payload)
  {
+struct intel_guc *guc = ct_to_guc(ct);
+
  switch (action) {
+case INTEL_GUC_ACTION_DEFAULT:
+if (unlikely(len < 1))
+goto fail_unexpected;
 Don't we need to remove the non-enabled messages here? i.e. like we do  
for the mmio receive:

  msg = *payload & guc->msg_enabled_mask;
 otherwise I think we'll try to process log interrupts even if the  
relay is not enabled.


In Daniele's specific example, I still think guc_log_enable_flush_events  
should have been called (and don't do anything inside  
handle_flush_event, the goal was to not serve it).


But it's true that we should filter any unexpected incoming request (&  
guc->msg_enabled_mask), and any new user should be calling  
intel_guc_enable_msg during its setup.


hmm, my understanding was that purpose of msg_enabled_mask was to:

 * Sample the log buffer flush related bits & clear them out now
 * itself from the message identity register to minimize the
 * probability of losing a flush interrupt, when there are back
 * to back flush interrupts.

and is not applicable to messages sent over CTB, as we can't miss msg.

if you still believe that filtering is required, it should not be done
here, as purpose of this function is to verify message completeness and
call actual handler, but in intel_guc_to_host_process_recv_msg(), where
format of received data is known.

/m



Thanks,

 Daniele


+intel_guc_to_host_process_recv_msg(guc, *payload);
+break;
+
  default:
+fail_unexpected:
  DRM_ERROR("CT: unexpected request %x %*phn\n",
action, 4 * len, payload);
  break;

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

When we include a request's global_seqno in a GEM_TRACE it often helps
to know how that relates to the current breadcrumb as seen by the
hardware.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_request.c | 28 +---
 drivers/gpu/drm/i915/intel_lrc.c|  6 --
 2 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 2314a26cd7f8..585242831974 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -214,8 +214,11 @@ static int reset_all_global_seqno(struct drm_i915_private 
*i915, u32 seqno)
struct i915_gem_timeline *timeline;
struct intel_timeline *tl = engine->timeline;
 
-   GEM_TRACE("%s seqno %d -> %d\n",
- engine->name, tl->seqno, seqno);
+   GEM_TRACE("%s seqno %d (current %d) -> %d\n",
+ engine->name,
+ tl->seqno,
+ intel_engine_get_seqno(engine),
+ seqno);
 
if (!i915_seqno_passed(seqno, tl->seqno)) {
/* Flush any waiters before we reuse the seqno */
@@ -386,10 +389,11 @@ static void i915_request_retire(struct i915_request 
*request)
struct intel_engine_cs *engine = request->engine;
struct i915_gem_active *active, *next;
 
-   GEM_TRACE("%s(%d) fence %llx:%d, global_seqno %d\n",
- engine->name, intel_engine_get_seqno(engine),
+   GEM_TRACE("%s fence %llx:%d, global_seqno %d, current %d\n",
+ engine->name,
  request->fence.context, request->fence.seqno,
- request->global_seqno);
+ request->global_seqno,
+ intel_engine_get_seqno(engine));
 
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
@@ -508,10 +512,11 @@ void __i915_request_submit(struct i915_request *request)
struct intel_engine_cs *engine = request->engine;
u32 seqno;
 
-   GEM_TRACE("%s fence %llx:%d -> global_seqno %d\n",
- request->engine->name,
+   GEM_TRACE("%s fence %llx:%d -> global_seqno %d, current %d\n",
+ engine->name,
  request->fence.context, request->fence.seqno,
- engine->timeline->seqno + 1);
+ engine->timeline->seqno + 1,
+ intel_engine_get_seqno(engine));
 
GEM_BUG_ON(!irqs_disabled());
lockdep_assert_held(>timeline->lock);
@@ -557,10 +562,11 @@ void __i915_request_unsubmit(struct i915_request *request)
 {
struct intel_engine_cs *engine = request->engine;
 
-   GEM_TRACE("%s fence %llx:%d <- global_seqno %d\n",
- request->engine->name,
+   GEM_TRACE("%s fence %llx:%d <- global_seqno %d, current %d\n",
+ engine->name,
  request->fence.context, request->fence.seqno,
- request->global_seqno);
+ request->global_seqno,
+ intel_engine_get_seqno(engine));
 
GEM_BUG_ON(!irqs_disabled());
lockdep_assert_held(>timeline->lock);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ed2c833a8b20..b5235f52a81b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -454,10 +454,11 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
desc = execlists_update_context(rq);
GEM_DEBUG_EXEC(port[n].context_id = 
upper_32_bits(desc));
 
-   GEM_TRACE("%s in[%d]:  ctx=%d.%d, seqno=%x, prio=%d\n",
+   GEM_TRACE("%s in[%d]:  ctx=%d.%d, seqno=%d (current 
%d), prio=%d\n",
  engine->name, n,
  port[n].context_id, count,
  rq->global_seqno,
+ intel_engine_get_seqno(engine),
  rq_prio(rq));
} else {
GEM_BUG_ON(!n);
@@ -999,10 +1000,11 @@ static void execlists_submission_tasklet(unsigned long 
data)
EXECLISTS_ACTIVE_USER));
 
rq = port_unpack(port, );
-   GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%x, prio=%d\n",
+   GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%d (current %d), 
prio=%d\n",
  engine->name,
  port->context_id, count,
  rq ? rq->global_seqno : 0,
+ intel_engine_get_seqno(engine),
  rq ? rq_prio(rq) : 0);
 
/* Check the context/desc id for this event 

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

[Chris Wilson]

Tvrtko uncovered a fun issue with recovering from a wedge device. In his
tests, he wedged the driver by injecting an unrecoverable hang whilst a
batch was spinning. As we reset the gpu in the middle of the spinner,
when resumed it would continue on from the next instruction in the ring
and write it's breadcrumb. However, on wedging we updated our
bookkeeping to indicate that the GPU had completed executing and would
restart from after the breadcrumb; so the emission of the stale
breadcrumb from before the reset came as a bit of a surprise.

A simple fix is to when rebinding the context into the GPU, we update
the ring register state in the context image to match our bookkeeping.
We already have to update the RING_START and RING_TAIL, so updating
RING_HEAD as well is trivial. This works because whenever we unbind the
context, we keep the bookkeeping in check; and on wedging we unbind all
contexts.

Testcase: igt/gem_eio
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ba7f7831f934..654634254b64 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1272,6 +1272,7 @@ execlists_context_pin(struct intel_engine_cs *engine,
ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
i915_ggtt_offset(ce->ring->vma);
+   ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head;
 
ce->state->obj->pin_global++;
i915_gem_context_get(ctx);
-- 
2.16.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Now that we reload both RING_HEAD and RING_TAIL when rebinding the
context, we do not need to scrub those registers immediately on resume.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 27 ---
 1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 654634254b64..ed2c833a8b20 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2536,13 +2536,14 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
return ret;
 }
 
-void intel_lr_context_resume(struct drm_i915_private *dev_priv)
+void intel_lr_context_resume(struct drm_i915_private *i915)
 {
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
enum intel_engine_id id;
 
-   /* Because we emit WA_TAIL_DWORDS there may be a disparity
+   /*
+* Because we emit WA_TAIL_DWORDS there may be a disparity
 * between our bookkeeping in ce->ring->head and ce->ring->tail and
 * that stored in context. As we only write new commands from
 * ce->ring->tail onwards, everything before that is junk. If the GPU
@@ -2552,26 +2553,14 @@ void intel_lr_context_resume(struct drm_i915_private 
*dev_priv)
 * So to avoid that we reset the context images upon resume. For
 * simplicity, we just zero everything out.
 */
-   list_for_each_entry(ctx, _priv->contexts.list, link) {
-   for_each_engine(engine, dev_priv, id) {
-   struct intel_context *ce = >engine[engine->id];
-   u32 *reg;
-
-   if (!ce->state)
-   continue;
+   list_for_each_entry(ctx, >contexts.list, link) {
+   for_each_engine(engine, i915, id) {
+   struct intel_context *ce = >engine[id];
 
-   reg = i915_gem_object_pin_map(ce->state->obj,
- I915_MAP_WB);
-   if (WARN_ON(IS_ERR(reg)))
+   GEM_BUG_ON(ce->pin_count);
+   if (!ce->ring)
continue;
 
-   reg += LRC_STATE_PN * PAGE_SIZE / sizeof(*reg);
-   reg[CTX_RING_HEAD+1] = 0;
-   reg[CTX_RING_TAIL+1] = 0;
-
-   ce->state->obj->mm.dirty = true;
-   i915_gem_object_unpin_map(ce->state->obj);
-
intel_ring_reset(ce->ring, 0);
}
}
-- 
2.16.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Tvrtko uncovered a fun issue with recovering from a wedge device. In his
tests, he wedged the driver by injecting an unrecoverable hang whilst a
batch was spinning. As we reset the gpu in the middle of the spinner,
when resumed it would continue on from the next instruction in the ring
and write it's breadcrumb. However, on wedging we updated our
bookkeeping to indicate that the GPU had completed executing and would
restart from after the breadcrumb; so the emission of the stale
breadcrumb from before the reset came as a bit of a surprise.

A simple fix is to when rebinding the context into the GPU, we update
the ring register state in the context image to match our bookkeeping.
We already have to update the RING_START and RING_TAIL, so updating
RING_HEAD as well is trivial. This works because whenever we unbind the
context, we keep the bookkeeping in check; and on wedging we unbind all
contexts.

Testcase: igt/gem_eio
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ba7f7831f934..654634254b64 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1272,6 +1272,7 @@ execlists_context_pin(struct intel_engine_cs *engine,
ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
i915_ggtt_offset(ce->ring->vma);
+   ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head;
 
ce->state->obj->pin_global++;
i915_gem_context_get(ctx);
-- 
2.16.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Quoting Jani Nikula (2018-03-27 21:47:22)
> Bool is the more appropriate return type here, use it.
> 
> Signed-off-by: Jani Nikula 

All 3,
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michel Thierry]

On 3/26/2018 12:48 PM, Michal Wajdeczko wrote:

With this series we will be able to receive more data from the Guc.
New Guc firmwares will be required to actually use that feature.

v4: respin series after 1/2 year break
v5: updated after review comments

Michal Wajdeczko (12):
   drm/i915/guc: Add documentation for MMIO based communication
   drm/i915/guc: Add support for data reporting in GuC responses
   drm/i915/guc: Prepare send() function to accept bigger response
   drm/i915/guc: Implement response handling in send_mmio()
   drm/i915/guc: Make event handler a virtual function
   drm/i915/guc: Prepare to handle messages from CT RECV buffer
   drm/i915/guc: Use better name for helper wait function
   drm/i915/guc: Implement response handling in send_ct()
   drm/i915/guc: Prepare to process incoming requests from CT
   drm/i915/guc: Handle default action received over CT
   drm/i915/guc: Trace messages from CT while in debug
   HAX: Enable GuC for CI

  drivers/gpu/drm/i915/Kconfig.debug|  12 +
  drivers/gpu/drm/i915/i915_params.h|   2 +-
  drivers/gpu/drm/i915/intel_guc.c  |  51 +++-
  drivers/gpu/drm/i915/intel_guc.h  |  29 +-
  drivers/gpu/drm/i915/intel_guc_ct.c   | 503 +++---
  drivers/gpu/drm/i915/intel_guc_ct.h   |  12 +
  drivers/gpu/drm/i915/intel_guc_fwif.h | 139 --
  drivers/gpu/drm/i915/intel_uc.c   |   2 +
  8 files changed, 678 insertions(+), 72 deletions(-)



Hi,

My r-b's still apply after addressing Daniele's comment in [v5,10/12].
___
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/gen11: Preempt-to-idle support in execlists.

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: Preempt-to-idle support in execlists.
URL   : https://patchwork.freedesktop.org/series/40747/
State : success

== Summary ==

 Known issues:

Test kms_cursor_legacy:
Subgroup flip-vs-cursor-atomic:
fail   -> PASS   (shard-hsw) fdo#102670
Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup 2x-flip-vs-wf_vblank:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3495 pass:1831 dwarn:1   dfail:0   fail:7   skip:1655 
time:12913s
shard-hswtotal:3495 pass:1781 dwarn:1   dfail:0   fail:3   skip:1709 
time:11676s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:7015s
Blacklisted hosts:
shard-kbltotal:3493 pass:1950 dwarn:5   dfail:0   fail:9   skip:1528 
time:9549s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8505/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jani Nikula]

Remove last users of __inline__.

Signed-off-by: Jani Nikula 
---
 include/drm/drmP.h   | 5 ++---
 include/drm/drm_legacy.h | 4 ++--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index ccd09347..4bbef061c9c0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -123,8 +123,7 @@ static inline bool drm_drv_uses_atomic_modeset(struct 
drm_device *dev)
 #define DRM_SWITCH_POWER_CHANGING 2
 #define DRM_SWITCH_POWER_DYNAMIC_OFF 3
 
-static __inline__ int drm_core_check_feature(struct drm_device *dev,
-int feature)
+static inline int drm_core_check_feature(struct drm_device *dev, int feature)
 {
return ((dev->driver->driver_features & feature) ? 1 : 0);
 }
@@ -143,7 +142,7 @@ static __inline__ int drm_core_check_feature(struct 
drm_device *dev,
 /*@}*/
 
 /* returns true if currently okay to sleep */
-static __inline__ bool drm_can_sleep(void)
+static inline bool drm_can_sleep(void)
 {
if (in_atomic() || in_dbg_master() || irqs_disabled())
return false;
diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
index cf0e7d89bcdf..8fad66f88e4f 100644
--- a/include/drm/drm_legacy.h
+++ b/include/drm/drm_legacy.h
@@ -194,8 +194,8 @@ void drm_legacy_ioremap(struct drm_local_map *map, struct 
drm_device *dev);
 void drm_legacy_ioremap_wc(struct drm_local_map *map, struct drm_device *dev);
 void drm_legacy_ioremapfree(struct drm_local_map *map, struct drm_device *dev);
 
-static __inline__ struct drm_local_map *drm_legacy_findmap(struct drm_device 
*dev,
-  unsigned int token)
+static inline struct drm_local_map *drm_legacy_findmap(struct drm_device *dev,
+  unsigned int token)
 {
struct drm_map_list *_entry;
list_for_each_entry(_entry, >maplist, head)
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jani Nikula]

Bool is the more appropriate return type here, use it.

Signed-off-by: Jani Nikula 
---
 include/drm/drmP.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b5d52a3d7d19..f5099c12c6a6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -115,9 +115,9 @@ static inline bool drm_drv_uses_atomic_modeset(struct 
drm_device *dev)
 #define DRM_SWITCH_POWER_CHANGING 2
 #define DRM_SWITCH_POWER_DYNAMIC_OFF 3
 
-static inline int drm_core_check_feature(struct drm_device *dev, int feature)
+static inline bool drm_core_check_feature(struct drm_device *dev, int feature)
 {
-   return ((dev->driver->driver_features & feature) ? 1 : 0);
+   return dev->driver->driver_features & feature;
 }
 
 /* returns true if currently okay to sleep */
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jani Nikula]

Throw out the leftovers.

Signed-off-by: Jani Nikula 
---
 include/drm/drmP.h | 21 -
 1 file changed, 21 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 4bbef061c9c0..b5d52a3d7d19 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -95,14 +95,6 @@ struct dma_buf_attachment;
 struct pci_dev;
 struct pci_controller;
 
-/***/
-/** \name DRM template customization defaults */
-/*@{*/
-
-/***/
-/** \name Internal types and structures */
-/*@{*/
-
 #define DRM_IF_VERSION(maj, min) (maj << 16 | min)
 
 /**
@@ -128,19 +120,6 @@ static inline int drm_core_check_feature(struct drm_device 
*dev, int feature)
return ((dev->driver->driver_features & feature) ? 1 : 0);
 }
 
-/**/
-/** \name Internal function definitions */
-/*@{*/
-
-   /* Driver support (drm_drv.h) */
-
-/*
- * These are exported to drivers so that they can implement fencing using
- * DMA quiscent + idle. DMA quiescent usually requires the hardware lock.
- */
-
-/*@}*/
-
 /* returns true if currently okay to sleep */
 static inline bool drm_can_sleep(void)
 {
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michal Wajdeczko]

Today uc_fini_hw is subset of uc_sanitize, but remaining
code in sanitize function is also desired for uc_fini_hw.
Instead of duplicating the code, just call uc_sanitize,
but leave as separate function to maintain symmetry with
uc_init_hw.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_uc.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index ec90c81..46c4dc4 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -433,19 +433,9 @@ 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_fini_hw(struct drm_i915_private *i915)
 {
-   struct intel_guc *guc = _priv->guc;
-
-   if (!USES_GUC(dev_priv))
-   return;
-
-   GEM_BUG_ON(!HAS_GUC(dev_priv));
-
-   if (USES_GUC_SUBMISSION(dev_priv))
-   intel_guc_submission_disable(guc);
-
-   guc_disable_communication(guc);
+   intel_uc_sanitize(i915);
 }
 
 int intel_uc_suspend(struct drm_i915_private *i915)
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michal Wajdeczko]

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

Unfortunately since commit 121981fafe69 ("drm/i915/guc: Combine
enable_guc_loading|submission modparams") we stopped using that
error code to avoid unwanted fallback to execlist submission mode.

In result any GuC initialization failure was treated as non-recoverable
error leading to driver load abort, so we could not even read related
GuC error log to investigate cause of the problem.

Fix that by always returning -EIO on uC hardware related failure.

v2: don't allow -EIO from uc_init
don't call uc_fini[_misc] on -EIO
mark guc fw as failed on hw init failure
prepare uc_fini_hw to run after earlier -EIO

v3: update comments (Sagar)
use sanitize functions on failure in init_hw (Michal)
and also sanitize guc/huc fw in fini_hw (Michal)

v4: rebase

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Michal Winiarski 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_gem.c| 17 ++---
 drivers/gpu/drm/i915/intel_guc.h   |  5 +
 drivers/gpu/drm/i915/intel_uc.c| 17 +
 drivers/gpu/drm/i915/intel_uc_fw.h |  5 +
 4 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 65ba104..82000bd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5361,8 +5361,10 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_init_gt_powersave(dev_priv);
 
ret = intel_uc_init(dev_priv);
-   if (ret)
+   if (ret) {
+   GEM_BUG_ON(ret == -EIO);
goto err_pm;
+   }
 
ret = i915_gem_init_hw(dev_priv);
if (ret)
@@ -5409,7 +5411,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
i915_gem_contexts_lost(dev_priv);
intel_uc_fini_hw(dev_priv);
 err_uc_init:
-   intel_uc_fini(dev_priv);
+   if (ret != -EIO)
+   intel_uc_fini(dev_priv);
 err_pm:
if (ret != -EIO) {
intel_cleanup_gt_powersave(dev_priv);
@@ -5423,15 +5426,15 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
mutex_unlock(_priv->drm.struct_mutex);
 
-   intel_uc_fini_misc(dev_priv);
-
-   if (ret != -EIO)
+   if (ret != -EIO) {
+   intel_uc_fini_misc(dev_priv);
i915_gem_cleanup_userptr(dev_priv);
+   }
 
if (ret == -EIO) {
/*
-* Allow engine initialisation to fail by marking the GPU as
-* wedged. But we only want to do this where the GPU is angry,
+* Allow engines or uC initialization to fail by marking the GPU
+* as wedged. But we only want to do this when the GPU is angry,
 * for all other failure, such as an allocation failure, bail.
 */
if (!i915_terminally_wedged(_priv->gpu_error)) {
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 13f3d1d..7325b0e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -155,6 +155,11 @@ static inline int intel_guc_sanitize(struct intel_guc *guc)
return 0;
 }
 
+static inline bool intel_guc_is_loaded(struct intel_guc *guc)
+{
+   return intel_uc_fw_is_loaded(>fw);
+}
+
 static inline void intel_guc_enable_msg(struct intel_guc *guc, u32 mask)
 {
spin_lock_irq(>irq_lock);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 46c4dc4..2d8f5d9 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -426,15 +426,24 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 * Note that there is no fallback as either user explicitly asked for
 * the GuC or driver default option was to run with the GuC enabled.
 */
-   if (GEM_WARN_ON(ret == -EIO))
-   ret = -EINVAL;
-
dev_err(dev_priv->drm.dev, "GuC initialization failed %d\n", ret);
-   return ret;
+
+   /* Sanitize GuC/HuC to avoid clean-up on wedged */
+   intel_huc_sanitize(huc);
+   intel_guc_sanitize(guc);
+   GEM_BUG_ON(intel_guc_is_loaded(guc));
+
+   /* We want to disable GPU submission but keep KMS alive */
+   return -EIO;
 }
 
 void intel_uc_fini_hw(struct drm_i915_private *i915)
 {
+   struct intel_guc *guc = >guc;
+
+   if (!intel_guc_is_loaded(guc))
+   return;
+
intel_uc_sanitize(i915);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h 

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

[Michal Wajdeczko]

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

Suggested-by: Sagar Arun Kamble 
Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 207cda0..26985d8 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -835,18 +835,9 @@ static int guc_clients_doorbell_init(struct intel_guc *guc)
 
 static void guc_clients_doorbell_fini(struct intel_guc *guc)
 {
-   /*
-* By the time we're here, GuC has already been reset.
-* Instead of trying (in vain) to communicate with it, let's just
-* cleanup the doorbell HW and our internal state.
-*/
-   if (guc->preempt_client) {
-   __destroy_doorbell(guc->preempt_client);
-   __update_doorbell_desc(guc->preempt_client,
-  GUC_DOORBELL_INVALID);
-   }
-   __destroy_doorbell(guc->execbuf_client);
-   __update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID);
+   if (guc->preempt_client)
+   destroy_doorbell(guc->preempt_client);
+   destroy_doorbell(guc->execbuf_client);
 }
 
 /**
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michal Wajdeczko]

We don't have to check load status values.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_huc.c | 2 +-
 drivers/gpu/drm/i915/intel_uc.c  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 2912852..975ae61 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -51,7 +51,7 @@ int intel_huc_auth(struct intel_huc *huc)
u32 status;
int ret;
 
-   if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+   if (!intel_uc_fw_is_loaded(>fw))
return -ENOEXEC;
 
vma = i915_gem_object_ggtt_pin(huc->fw.obj, NULL, 0, 0,
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 2d8f5d9..14664fe 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -455,7 +455,7 @@ int intel_uc_suspend(struct drm_i915_private *i915)
if (!USES_GUC(i915))
return 0;
 
-   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+   if (!intel_guc_is_loaded(guc))
return 0;
 
err = intel_guc_suspend(guc);
@@ -477,7 +477,7 @@ int intel_uc_resume(struct drm_i915_private *i915)
if (!USES_GUC(i915))
return 0;
 
-   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+   if (!intel_guc_is_loaded(guc))
return 0;
 
if (i915_modparams.guc_log_level)
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michal Wajdeczko]

Some functions already use i915 name instead of dev_priv.
Let's rename this param in all remaining functions, except
those that still use legacy macros.

v2: don't forget about function descriptions (Sagar)
v3: rebased

Signed-off-by: Michal Wajdeczko 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_uc.c | 87 -
 1 file changed, 43 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 14664fe..fec5514 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -50,10 +50,10 @@ static int __intel_uc_reset_hw(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
-static int __get_platform_enable_guc(struct drm_i915_private *dev_priv)
+static int __get_platform_enable_guc(struct drm_i915_private *i915)
 {
-   struct intel_uc_fw *guc_fw = _priv->guc.fw;
-   struct intel_uc_fw *huc_fw = _priv->huc.fw;
+   struct intel_uc_fw *guc_fw = >guc.fw;
+   struct intel_uc_fw *huc_fw = >huc.fw;
int enable_guc = 0;
 
/* Default is to enable GuC/HuC if we know their firmwares */
@@ -67,11 +67,11 @@ static int __get_platform_enable_guc(struct 
drm_i915_private *dev_priv)
return enable_guc;
 }
 
-static int __get_default_guc_log_level(struct drm_i915_private *dev_priv)
+static int __get_default_guc_log_level(struct drm_i915_private *i915)
 {
int guc_log_level;
 
-   if (!HAS_GUC(dev_priv) || !intel_uc_is_using_guc())
+   if (!HAS_GUC(i915) || !intel_uc_is_using_guc())
guc_log_level = GUC_LOG_LEVEL_DISABLED;
else if (IS_ENABLED(CONFIG_DRM_I915_DEBUG) ||
 IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
@@ -86,7 +86,7 @@ static int __get_default_guc_log_level(struct 
drm_i915_private *dev_priv)
 
 /**
  * sanitize_options_early - sanitize uC related modparam options
- * @dev_priv: device private
+ * @i915: device private
  *
  * In case of "enable_guc" option this function will attempt to modify
  * it only if it was initially set to "auto(-1)". Default value for this
@@ -101,14 +101,14 @@ static int __get_default_guc_log_level(struct 
drm_i915_private *dev_priv)
  * unless GuC is enabled on given platform and the driver is compiled with
  * debug config when this modparam will default to "enable(1..4)".
  */
-static void sanitize_options_early(struct drm_i915_private *dev_priv)
+static void sanitize_options_early(struct drm_i915_private *i915)
 {
-   struct intel_uc_fw *guc_fw = _priv->guc.fw;
-   struct intel_uc_fw *huc_fw = _priv->huc.fw;
+   struct intel_uc_fw *guc_fw = >guc.fw;
+   struct intel_uc_fw *huc_fw = >huc.fw;
 
/* A negative value means "use platform default" */
if (i915_modparams.enable_guc < 0)
-   i915_modparams.enable_guc = __get_platform_enable_guc(dev_priv);
+   i915_modparams.enable_guc = __get_platform_enable_guc(i915);
 
DRM_DEBUG_DRIVER("enable_guc=%d (submission:%s huc:%s)\n",
 i915_modparams.enable_guc,
@@ -119,28 +119,28 @@ static void sanitize_options_early(struct 
drm_i915_private *dev_priv)
if (intel_uc_is_using_guc() && !intel_uc_fw_is_selected(guc_fw)) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
 "enable_guc", i915_modparams.enable_guc,
-!HAS_GUC(dev_priv) ? "no GuC hardware" :
- "no GuC firmware");
+!HAS_GUC(i915) ? "no GuC hardware" :
+ "no GuC firmware");
}
 
/* Verify HuC firmware availability */
if (intel_uc_is_using_huc() && !intel_uc_fw_is_selected(huc_fw)) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
 "enable_guc", i915_modparams.enable_guc,
-!HAS_HUC(dev_priv) ? "no HuC hardware" :
- "no HuC firmware");
+!HAS_HUC(i915) ? "no HuC hardware" :
+ "no HuC firmware");
}
 
/* A negative value means "use platform/config default" */
if (i915_modparams.guc_log_level < 0)
i915_modparams.guc_log_level =
-   __get_default_guc_log_level(dev_priv);
+   __get_default_guc_log_level(i915);
 
if (i915_modparams.guc_log_level > 0 && !intel_uc_is_using_guc()) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
 "guc_log_level", i915_modparams.guc_log_level,
-!HAS_GUC(dev_priv) ? "no GuC hardware" :
- "GuC not enabled");
+!HAS_GUC(i915) ? "no GuC hardware" :
+ "GuC not enabled");
   

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

[Michal Wajdeczko]

v2: except running with HYPERVISOR

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 drivers/gpu/drm/i915/intel_uc.c| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c963603..53037b5 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index fec5514..bbb2c36 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*i915)
enable_guc |= ENABLE_GUC_LOAD_HUC;
 
/* Any platform specific fine-tuning can be done here */
+   if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+   enable_guc = 0;
 
return enable_guc;
 }
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michal Wajdeczko]

In function gem_init_hw() we are calling uc_init_hw() but in case
of error later in function, we missed to call matching uc_fini_hw()

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_gem.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9650a7b..65ba104 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5171,9 +5171,15 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
 
/* Only when the HW is re-initialised, can we replay the requests */
ret = __i915_gem_restart_engines(dev_priv);
+   if (ret)
+   goto cleanup_uc;
 out:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
return ret;
+
+cleanup_uc:
+   intel_uc_fini_hw(dev_priv);
+   goto out;
 }
 
 static int __intel_engines_record_defaults(struct drm_i915_private *i915)
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michal Wajdeczko]

We should not leave GuC submission enabled after sanitize,
as we are going to reset all GuC/HuC hardware.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_uc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 4aad844..ec90c81 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -330,6 +330,9 @@ void intel_uc_sanitize(struct drm_i915_private *i915)
 
GEM_BUG_ON(!HAS_GUC(i915));
 
+   if (USES_GUC_SUBMISSION(dev_priv))
+   intel_guc_submission_disable(guc);
+
guc_disable_communication(guc);
 
intel_huc_sanitize(huc);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michel Thierry]

On 3/26/2018 12:48 PM, Wajdeczko, Michal wrote:

Requests are read from CT in the irq handler, but actual processing
will be done in the work thread. Processing of specific actions will
be added in the upcoming patches.

v2: don't use GEM_BUG_ON (Chris)
 don't kmalloc too large buffer (Michal)
v3: rebased
v4: don't name it 'dispatch' (Michel) and fix checkpatch
 add some documentation (Michal)

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/intel_guc_ct.c | 95 -
  drivers/gpu/drm/i915/intel_guc_ct.h |  6 +++
  2 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 41b071c..aa810ad 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -32,10 +32,17 @@ struct ct_request {
 u32 *response_buf;
  };

+struct ct_incoming_request {
+   struct list_head link;
+   u32 msg[];
+};
+
  enum { CTB_SEND = 0, CTB_RECV = 1 };

  enum { CTB_OWNER_HOST = 0 };

+static void ct_incoming_request_worker_func(struct work_struct *w);
+
  /**
   * intel_guc_ct_init_early - Initialize CT state without requiring device 
access
   * @ct: pointer to CT struct
@@ -47,6 +54,8 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)

 spin_lock_init(>lock);
 INIT_LIST_HEAD(>pending_requests);
+   INIT_LIST_HEAD(>incoming_requests);
+   INIT_WORK(>worker, ct_incoming_request_worker_func);
  }

  static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
@@ -682,13 +691,97 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
 return 0;
  }

+static void ct_process_request(struct intel_guc_ct *ct,
+  u32 action, u32 len, const u32 *payload)
+{
+   switch (action) {
+   default:
+   DRM_ERROR("CT: unexpected request %x %*phn\n",
+ action, 4 * len, payload);
+   break;
+   }
+}
+
+static bool ct_process_incoming_requests(struct intel_guc_ct *ct)
+{
+   unsigned long flags;
+   struct ct_incoming_request *request;
+   u32 header;
+   u32 *payload;
+   bool done;
+
+   spin_lock_irqsave(>lock, flags);
+   request = list_first_entry_or_null(>incoming_requests,
+  struct ct_incoming_request, link);
+   if (request)
+   list_del(>link);
+   done = !!list_empty(>incoming_requests);
+   spin_unlock_irqrestore(>lock, flags);
+
+   if (!request)
+   return true;
+
+   header = request->msg[0];
+   payload = >msg[1];
+   ct_process_request(ct,
+  ct_header_get_action(header),
+  ct_header_get_len(header),
+  payload);
+
+   kfree(request);
+   return done;
+}
+
+static void ct_incoming_request_worker_func(struct work_struct *w)
+{
+   struct intel_guc_ct *ct = container_of(w, struct intel_guc_ct, worker);
+   bool done;
+
+   done = ct_process_incoming_requests(ct);
+   if (!done)
+   queue_work(system_unbound_wq, >worker);
+}
+
+/**
+ * DOC: CTB GuC to Host request
+ *
+ * Format of the CTB GuC to Host request message is as follows::
+ *
+ *  ++-+-+-+-+-+
+ *  |   msg[0]   |   [1]   |   [2]   |   [3]   |   ...   |  [n-1]  |
+ *  ++-+-+-+-+-+
+ *  |   MESSAGE  |   MESSAGE PAYLOAD   |
+ *  +   HEADER   +-+-+-+-+-+
+ *  ||0|1|2|   ...   |n|
+ *  ++=+=+=+=+=+
+ *  | len|request specific data|
+ *  +--+-+-+-+-+-+-+
+ *
+ *   ^---len---^
+ */
+
  static int ct_handle_request(struct intel_guc_ct *ct, const u32 *msg)
  {
 u32 header = msg[0];
+   u32 len = ct_header_get_len(header);
+   u32 msglen = len + 1; /* total message length including header */
+   struct ct_incoming_request *request;
+   unsigned long flags;

 GEM_BUG_ON(ct_header_is_response(header));

-   /* XXX */
+   request = kmalloc(sizeof(*request) + 4 * msglen, GFP_ATOMIC);
+   if (unlikely(!request)) {
+   DRM_ERROR("CT: dropping request %*phn\n", 4 * msglen, msg);
+   return 0; /* XXX: -ENOMEM ? */
+   }
+   memcpy(request->msg, msg, 4 * msglen);
+
+   spin_lock_irqsave(>lock, flags);
+   list_add_tail(>link, >incoming_requests);

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

[Michel Thierry]

On 3/27/2018 11:25 AM, Daniele Ceraolo Spurio wrote:



On 26/03/18 12:48, Michal Wajdeczko wrote:

When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Reviewed-by: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_guc.c    | 5 +
  drivers/gpu/drm/i915/intel_guc.h    | 1 +
  drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
  3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index 118db81..b6d2778 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,11 @@ void intel_guc_to_host_event_handler_mmio(struct 
intel_guc *guc)

  I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
  spin_unlock(>irq_lock);
+    intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{
  if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
 INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
  intel_guc_log_handle_flush_event(>log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, 
const u32 *action, u32 len,

  void intel_guc_to_host_event_handler(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
  int intel_guc_sample_forcewake(struct intel_guc *guc);
  int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
  int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c

index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct 
*ct, const u32 *msg)

  static void ct_process_request(struct intel_guc_ct *ct,
 u32 action, u32 len, const u32 *payload)
  {
+    struct intel_guc *guc = ct_to_guc(ct);
+
  switch (action) {
+    case INTEL_GUC_ACTION_DEFAULT:
+    if (unlikely(len < 1))
+    goto fail_unexpected;


Don't we need to remove the non-enabled messages here? i.e. like we do 
for the mmio receive:


 msg = *payload & guc->msg_enabled_mask;

otherwise I think we'll try to process log interrupts even if the relay 
is not enabled.


In Daniele's specific example, I still think guc_log_enable_flush_events 
should have been called (and don't do anything inside 
handle_flush_event, the goal was to not serve it).


But it's true that we should filter any unexpected incoming request (& 
guc->msg_enabled_mask), and any new user should be calling 
intel_guc_enable_msg during its setup.


Thanks,


Daniele


+    intel_guc_to_host_process_recv_msg(guc, *payload);
+    break;
+
  default:
+fail_unexpected:
  DRM_ERROR("CT: unexpected request %x %*phn\n",
    action, 4 * len, payload);
  break;


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Zhi Wang]

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


Thanks again for the discussion and efforts. :)

Thanks,
Zhi.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

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

Hmm, what CI won't say until it gets around to running on the shards
(i.e. post merge) is that the !contexts tests are expected to pass on
the older gen. This patch will now fail in gem_context_create().

I was only half jokingly suggesting reopen_device().

As CI is only running each subtest individually, I don't think we are
exposed to the issue, that should give us a bit of time to hopefully fix
it. So back to the perplexing puzzle.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Pandiyan, Dhinakaran]

On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote:
> On Mon, Mar 26, 2018 at 06:16:22PM -0700, Dhinakaran Pandiyan wrote:
> > Interrupts other than the one for AUX errors are required only for debug,
> > so unmask them via debugfs when the user requests debug.
> > 
> > User can make such a request with
> > echo 1 > /dri/0/i915_edp_psr_debug
> > 
> > v2: Unroll loops (Ville)
> > Avoid resetting error mask bits.
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > Cc: Chris Wilson 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/i915_irq.c | 55 
> > +++--
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c| 54 
> > 
> >  5 files changed, 108 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 7816cd53100a..6fd801ef7cbb 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> > return 0;
> >  }
> >  
> > +static int
> > +i915_edp_psr_debug_set(void *data, u64 val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   if (val < 0  || val > 1)
> > +   return -EINVAL;
> 
> Can't be < 0.
> 
> > +
> > +   DRM_DEBUG_KMS("%s PSR debug\n", val == 1 ? "Enabling" : "Disabling");
> 
> ==1 seems pointless
> enableddisabled() could be used perhaps.
> 

Will do.

> 
> > +   intel_psr_debug_control(dev_priv, val);
> > +
> > +   return 0;
> > +}
> > +
> > +static int
> > +i915_edp_psr_debug_get(void *data, u64 *val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   *val = READ_ONCE(dev_priv->psr.debug);
> > +   return 0;
> > +}
> > +
> > +DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops,
> > +   i915_edp_psr_debug_get, i915_edp_psr_debug_set,
> > +   "%llu\n");
> > +
> >  static int i915_sink_crc(struct seq_file *m, void *data)
> >  {
> > struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > @@ -4811,7 +4844,8 @@ static const struct i915_debugfs_files {
> > {"i915_guc_log_relay", _guc_log_relay_fops},
> > {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
> > {"i915_ipc_status", _ipc_status_fops},
> > -   {"i915_drrs_ctl", _drrs_ctl_fops}
> > +   {"i915_drrs_ctl", _drrs_ctl_fops},
> > +   {"i915_edp_psr_debug", _edp_psr_debug_fops}
> >  };
> >  
> >  int i915_debugfs_register(struct drm_i915_private *dev_priv)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index c9c3b2ba6a86..c0224a86344e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -608,6 +608,7 @@ struct i915_psr {
> > bool colorimetry_support;
> > bool alpm;
> > bool has_hw_tracking;
> > +   bool debug;
> >  
> > void (*enable_source)(struct intel_dp *,
> >   const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 8a894adf2ca1..e5aaf805c6a8 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2391,40 +2391,6 @@ static void ilk_display_irq_handler(struct 
> > drm_i915_private *dev_priv,
> > ironlake_rps_change_irq_handler(dev_priv);
> >  }
> >  
> > -static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> > -{
> > -   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > -   u32 edp_psr_imr = I915_READ(EDP_PSR_IMR);
> > -   u32 mask = BIT(TRANSCODER_EDP);
> > -   enum transcoder cpu_transcoder;
> > -
> > -   if (INTEL_GEN(dev_priv) >= 8)
> > -   mask |= BIT(TRANSCODER_A) |
> > -   BIT(TRANSCODER_B) |
> > -   BIT(TRANSCODER_C);
> > -
> > -   for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, mask) {
> > -   if (edp_psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> > -   DRM_DEBUG_KMS("Transcoder %s PSR error\n",
> > - transcoder_name(cpu_transcoder));
> > -
> > -   if (edp_psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> > -   DRM_DEBUG_KMS("Transcoder %s PSR prepare entry in 2 
> > vblanks\n",
> > - transcoder_name(cpu_transcoder));
> > -   edp_psr_imr |= EDP_PSR_PRE_ENTRY(cpu_transcoder);
> > -   }
> > -
> > -   if (edp_psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
> > -

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

[Daniele Ceraolo Spurio]

On 26/03/18 12:48, Michal Wajdeczko wrote:

When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Reviewed-by: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_guc.c| 5 +
  drivers/gpu/drm/i915/intel_guc.h| 1 +
  drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
  3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..b6d2778 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,11 @@ void intel_guc_to_host_event_handler_mmio(struct intel_guc 
*guc)
I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
spin_unlock(>irq_lock);
  
+	intel_guc_to_host_process_recv_msg(guc, msg);

+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
   INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(>log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len,
  void intel_guc_to_host_event_handler(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
  int intel_guc_sample_forcewake(struct intel_guc *guc);
  int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
  int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
  static void ct_process_request(struct intel_guc_ct *ct,
   u32 action, u32 len, const u32 *payload)
  {
+   struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+   case INTEL_GUC_ACTION_DEFAULT:
+   if (unlikely(len < 1))
+   goto fail_unexpected;


Don't we need to remove the non-enabled messages here? i.e. like we do 
for the mmio receive:


msg = *payload & guc->msg_enabled_mask;

otherwise I think we'll try to process log interrupts even if the relay 
is not enabled.


Daniele


+   intel_guc_to_host_process_recv_msg(guc, *payload);
+   break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
  action, 4 * len, payload);
break;


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Lis, Tomasz]

On 2018-03-21 20:42, Oscar Mateo wrote:



On 3/21/2018 3:16 AM, Chris Wilson wrote:

Quoting Oscar Mateo (2018-03-20 18:43:45)


On 3/19/2018 7:14 AM, Lis, Tomasz wrote:


On 2018-03-19 13:43, Chris Wilson wrote:

Quoting Tomasz Lis (2018-03-19 12:37:35)

The patch adds a parameter to control the data port coherency
functionality
on a per-exec call basis. When data port coherency flag value is
different
than what it was in previous call for the context, a command to
switch data
port coherency state is added before the buffer to be executed.

So this is part of the context? Why do it at exec level?

It is part of the context, stored within HDC chicken bit register.
The exec level was requested by the OCL team, due to concerns about
performance cost of context setparam calls.


   If exec level
is desired, why not whitelist it?
-Chris

If we have no issue in whitelisting the register, I'm sure OCL will
agree to that.
I assumed the whitelisting will be unacceptable because of security
concerns with some options.
The register also changes its position and content between gens, which
makes whitelisting hard to manage.


I think a security analysis of this register was already done, and the
result was that it contains some other bits that could be dangerous. In
CNL those bits were moved out of the way and the HDC_CHICKEN0 register
can be whitelisted (WaAllowUMDToControlCoherency). In ICL the register
should already be non-privileged.

The previous alternative to whitelisting was running through a command
parser for validation. That's a very general mechanism suitable for a
wide range of sins.
-Chris


Are you suggesting that we enable the cmd parser for every Gen < CNL 
for this particular usage only? :P


It is a solution that would allow to do what we want without any 
additions to module interface.
It may be worth considering if we think the coherency setting will be 
temporary and removed in future gens, as we wouldn't want to have 
obsolete flags.


I think the setting will stay with us, as it is needed to support 
CL_MEM_SVM_FINE_GRAIN_BUFFER flag from OpenCL spec.
Keeping coherency will always cost performance, so we will likely always 
have a hardware setting to switch it.
But the bspec says coherency override control will be removed in future 
projects...



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Rodrigo Vivi]

On Mon, Mar 19, 2018 at 09:41:32PM +, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-03-19 17:37:20)
> > In some places we end up converting switch statements to a series of
> > if/else, particularly when introducing helper functions to handle a
> > group of cases. It's tempting to either leave a wrong warning (since now
> > we don't have a switch case anymore) or to convert to WARN(1, ...),
> > but we can just provide a better message and avoid the doubt when such
> > conversions arrise.
> > 
> > Introducing a warning inside i915_driver_load() just for tests we get:
> > 
> > [ 4535.233717] Missing case (ret == 0)
> > [ 4535.233868] WARNING: CPU: 1 PID: 795 at 
> > drivers/gpu/drm/i915/i915_drv.c:1341 i915_driver_load+0x42/0x10e0 [i915]
> > 
> > which is clear enough.
> > 
> > v2: remove __func__ since this is already on the warning.
> > 
> > Cc: Chris Wilson 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> > Signed-off-by: Lucas De Marchi 
> Reviewed-by: Chris Wilson 

pushed to dinq. thanks for patch and reviews.

> -Chris
> ___
> 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 v2 7/7] drm/i915: reorder dpll_info members

[Rodrigo Vivi]

On Fri, Mar 23, 2018 at 06:25:52PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 20, 2018 at 03:06:37PM -0700, Lucas De Marchi wrote:
> > Remove 4-bytes hole in this struct an reorder tables accordingly. This
> > also changes the last element of the tables to be more future-proof.
> > 
> > Signed-off-by: Lucas De Marchi 
> > ---
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c | 48 
> > +--
> >  drivers/gpu/drm/i915/intel_dpll_mgr.h | 13 ++
> >  2 files changed, 32 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index bda69e1ccd76..d5e114e9660b 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -1908,9 +1908,9 @@ struct intel_dpll_mgr {
> >  };
> >  
> >  static const struct dpll_info pch_plls[] = {
> > -   { "PCH DPLL A", DPLL_ID_PCH_PLL_A, _pch_dpll_funcs, 0 },
> > -   { "PCH DPLL B", DPLL_ID_PCH_PLL_B, _pch_dpll_funcs, 0 },
> > -   { NULL, -1, NULL, 0 },
> > +   { "PCH DPLL A", _pch_dpll_funcs, DPLL_ID_PCH_PLL_A, 0 },
> > +   { "PCH DPLL B", _pch_dpll_funcs, DPLL_ID_PCH_PLL_B, 0 },
> 
> I usually prefer named initializer to be used pretty much everywhere.
> 
> Patches 6-7 are
> Reviewed-by: Ville Syrjälä 
> regardless.

pushed to dinq. Thanks for patches and reviews.

> 
> > +   { },
> >  };
> >  
> >  static const struct intel_dpll_mgr pch_pll_mgr = {
> > @@ -1920,13 +1920,13 @@ static const struct intel_dpll_mgr pch_pll_mgr = {
> >  };
> >  
> >  static const struct dpll_info hsw_plls[] = {
> > -   { "WRPLL 1",DPLL_ID_WRPLL1, _ddi_wrpll_funcs, 0 },
> > -   { "WRPLL 2",DPLL_ID_WRPLL2, _ddi_wrpll_funcs, 0 },
> > -   { "SPLL",   DPLL_ID_SPLL,   _ddi_spll_funcs,  0 },
> > -   { "LCPLL 810",  DPLL_ID_LCPLL_810,  _ddi_lcpll_funcs, 
> > INTEL_DPLL_ALWAYS_ON },
> > -   { "LCPLL 1350", DPLL_ID_LCPLL_1350, _ddi_lcpll_funcs, 
> > INTEL_DPLL_ALWAYS_ON },
> > -   { "LCPLL 2700", DPLL_ID_LCPLL_2700, _ddi_lcpll_funcs, 
> > INTEL_DPLL_ALWAYS_ON },
> > -   { NULL, -1, NULL, },
> > +   { "WRPLL 1",_ddi_wrpll_funcs, DPLL_ID_WRPLL1, 0 },
> > +   { "WRPLL 2",_ddi_wrpll_funcs, DPLL_ID_WRPLL2, 0 },
> > +   { "SPLL",   _ddi_spll_funcs,  DPLL_ID_SPLL,   0 },
> > +   { "LCPLL 810",  _ddi_lcpll_funcs, DPLL_ID_LCPLL_810,  
> > INTEL_DPLL_ALWAYS_ON },
> > +   { "LCPLL 1350", _ddi_lcpll_funcs, DPLL_ID_LCPLL_1350, 
> > INTEL_DPLL_ALWAYS_ON },
> > +   { "LCPLL 2700", _ddi_lcpll_funcs, DPLL_ID_LCPLL_2700, 
> > INTEL_DPLL_ALWAYS_ON },
> > +   { },
> >  };
> >  
> >  static const struct intel_dpll_mgr hsw_pll_mgr = {
> > @@ -1936,11 +1936,11 @@ static const struct intel_dpll_mgr hsw_pll_mgr = {
> >  };
> >  
> >  static const struct dpll_info skl_plls[] = {
> > -   { "DPLL 0", DPLL_ID_SKL_DPLL0, _ddi_dpll0_funcs, 
> > INTEL_DPLL_ALWAYS_ON },
> > -   { "DPLL 1", DPLL_ID_SKL_DPLL1, _ddi_pll_funcs,   0 },
> > -   { "DPLL 2", DPLL_ID_SKL_DPLL2, _ddi_pll_funcs,   0 },
> > -   { "DPLL 3", DPLL_ID_SKL_DPLL3, _ddi_pll_funcs,   0 },
> > -   { NULL, -1, NULL, },
> > +   { "DPLL 0", _ddi_dpll0_funcs, DPLL_ID_SKL_DPLL0, 
> > INTEL_DPLL_ALWAYS_ON },
> > +   { "DPLL 1", _ddi_pll_funcs,   DPLL_ID_SKL_DPLL1, 0 },
> > +   { "DPLL 2", _ddi_pll_funcs,   DPLL_ID_SKL_DPLL2, 0 },
> > +   { "DPLL 3", _ddi_pll_funcs,   DPLL_ID_SKL_DPLL3, 0 },
> > +   { },
> >  };
> >  
> >  static const struct intel_dpll_mgr skl_pll_mgr = {
> > @@ -1950,10 +1950,10 @@ static const struct intel_dpll_mgr skl_pll_mgr = {
> >  };
> >  
> >  static const struct dpll_info bxt_plls[] = {
> > -   { "PORT PLL A", DPLL_ID_SKL_DPLL0, _ddi_pll_funcs, 0 },
> > -   { "PORT PLL B", DPLL_ID_SKL_DPLL1, _ddi_pll_funcs, 0 },
> > -   { "PORT PLL C", DPLL_ID_SKL_DPLL2, _ddi_pll_funcs, 0 },
> > -   { NULL, -1, NULL, },
> > +   { "PORT PLL A", _ddi_pll_funcs, DPLL_ID_SKL_DPLL0, 0 },
> > +   { "PORT PLL B", _ddi_pll_funcs, DPLL_ID_SKL_DPLL1, 0 },
> > +   { "PORT PLL C", _ddi_pll_funcs, DPLL_ID_SKL_DPLL2, 0 },
> > +   { },
> >  };
> >  
> >  static const struct intel_dpll_mgr bxt_pll_mgr = {
> > @@ -2387,10 +2387,10 @@ static const struct intel_shared_dpll_funcs 
> > cnl_ddi_pll_funcs = {
> >  };
> >  
> >  static const struct dpll_info cnl_plls[] = {
> > -   { "DPLL 0", DPLL_ID_SKL_DPLL0, _ddi_pll_funcs, 0 },
> > -   { "DPLL 1", DPLL_ID_SKL_DPLL1, _ddi_pll_funcs, 0 },
> > -   { "DPLL 2", DPLL_ID_SKL_DPLL2, _ddi_pll_funcs, 0 },
> > -   { NULL, -1, NULL, },
> > +   { "DPLL 0", _ddi_pll_funcs, DPLL_ID_SKL_DPLL0, 0 },
> > +   { "DPLL 1", _ddi_pll_funcs, DPLL_ID_SKL_DPLL1, 0 },
> > +   { "DPLL 2", _ddi_pll_funcs, DPLL_ID_SKL_DPLL2, 0 },
> > +   { },
> >  };
> >  
> >  static const struct intel_dpll_mgr cnl_pll_mgr = {
> > @@ -2430,7 +2430,7 @@ void intel_shared_dpll_init(struct drm_device *dev)
> >  
> > dpll_info = dpll_mgr->dpll_info;
> >  
> > -   for (i = 0; dpll_info[i].id >= 0; i++) {
> > +   for (i = 0; 

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

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Support for Guc responses and requests (rev4)
URL   : https://patchwork.freedesktop.org/series/28393/
State : failure

== Summary ==

 Possible new issues:

Test gem_eio:
Subgroup execbuf:
pass   -> INCOMPLETE (shard-apl)
Subgroup throttle:
pass   -> INCOMPLETE (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-pwrite:
fail   -> PASS   (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl) fdo#103199
Test kms_flip:
Subgroup flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#103199 https://bugs.freedesktop.org/show_bug.cgi?id=103199
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3483 pass:1819 dwarn:1   dfail:0   fail:11  skip:1650 
time:12588s
shard-hswtotal:3495 pass:1782 dwarn:1   dfail:0   fail:2   skip:1709 
time:11678s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:6962s
Blacklisted hosts:
shard-kbltotal:3143 pass:1719 dwarn:1   dfail:0   fail:11  skip:1404 
time:7156s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8504/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michal Wajdeczko]

On Mon, 26 Mar 2018 13:23:21 +0200, Sagar Arun Kamble  
 wrote:





On 3/23/2018 8:44 PM, Michal Wajdeczko wrote:

Today uc_fini_hw is subset of uc_sanitize, but remaining
code in sanitize function is also desired for uc_fini_hw.
Instead of duplicating the code, just call uc_sanitize,
but leave as separate function to maintain symmetry with
uc_init_hw.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
We should drop call to uc_fini_hw from gem_fini as part of this patch as  
GuC won't be available then.


But we will need it in gem_fini to properly finish our cleanup on unload.

Maybe to keep symmetry, we should add i915_gem_fini_hw and call it from
there ? See cleanup inside i915_gem_init_hw.

/m


---
  drivers/gpu/drm/i915/intel_uc.c | 14 ++
  1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c  
b/drivers/gpu/drm/i915/intel_uc.c

index 2389828..9ff0c5a 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -434,19 +434,9 @@ 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_fini_hw(struct drm_i915_private *i915)
  {
-   struct intel_guc *guc = _priv->guc;
-
-   if (!USES_GUC(dev_priv))
-   return;
-
-   GEM_BUG_ON(!HAS_GUC(dev_priv));
-
-   if (USES_GUC_SUBMISSION(dev_priv))
-   intel_guc_submission_disable(guc);
-
-   guc_disable_communication(guc);
+   intel_uc_sanitize(i915);
  }
int intel_uc_suspend(struct drm_i915_private *i915)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michal Wajdeczko]

On Mon, 26 Mar 2018 12:36:05 +0200, Sagar Arun Kamble  
 wrote:





On 3/23/2018 8:44 PM, Michal Wajdeczko wrote:

We should not leave GuC submission enabled after sanitize,
as we are going to reset all GuC/HuC hardware.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Either we need now destroy the doorbells cleanly or remove the below  
comment from clients_doorbell_fini:

 /*
  * By the time we're here, GuC has already been reset.
  * Instead of trying (in vain) to communicate with it, let's  
just

  * cleanup the doorbell HW and our internal state.
  */


Good catch!
I'll restore symmetric doorbell cleanup in separate patch right after this  
one.




One additional thing I feel we should do now is remove uc_suspend|resume  
from gem_suspend|resume

because we don't want to do any GuC actions once we suspend it.


Hmm, I would keep it to maintain symmetry with gem, and in us_resume we
already have guard for checking unloaded/sanitized GuC.

/m


---
  drivers/gpu/drm/i915/intel_uc.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uc.c  
b/drivers/gpu/drm/i915/intel_uc.c

index 34f8a2c..2389828 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -331,6 +331,9 @@ void intel_uc_sanitize(struct drm_i915_private  
*i915)

GEM_BUG_ON(!HAS_GUC(i915));
  + if (USES_GUC_SUBMISSION(dev_priv))
+   intel_guc_submission_disable(guc);
+
guc_disable_communication(guc);
intel_huc_sanitize(huc);

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Contexts executing when reset triggers are potentialy corrupt so trying to
use them from a subsequent test (like the default context) can hang the
GPU or even the driver.

Workaround that by always creating a dedicated context which will be
running when GPU reset happens.

Signed-off-by: Tvrtko Ursulin 
---
 tests/gem_eio.c | 96 +++--
 1 file changed, 60 insertions(+), 36 deletions(-)

diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index b824d9d4c9c0..cefe26adf893 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -249,14 +249,34 @@ static int __check_wait(int fd, uint32_t bo, unsigned int 
wait)
return ret;
 }
 
+static uint32_t context_create_safe(int i915)
+{
+   struct drm_i915_gem_context_param param;
+
+   memset(, 0, sizeof(param));
+
+   param.ctx_id = gem_context_create(i915);
+   param.param = I915_CONTEXT_PARAM_BANNABLE;
+   gem_context_set_param(i915, );
+
+   param.param = I915_CONTEXT_PARAM_NO_ERROR_CAPTURE;
+   param.value = 1;
+   gem_context_set_param(i915, );
+
+   return param.ctx_id;
+}
+
 #define TEST_WEDGE (1)
 
 static void test_wait(int fd, unsigned int flags, unsigned int wait)
 {
igt_spin_t *hang;
+   uint32_t ctx;
 
igt_require_gem(fd);
 
+   ctx = context_create_safe(fd);
+
/*
 * If the request we wait on completes due to a hang (even for
 * that request), the user expects the return value to 0 (success).
@@ -267,7 +287,7 @@ static void test_wait(int fd, unsigned int flags, unsigned 
int wait)
else
igt_require(i915_reset_control(true));
 
-   hang = spin_sync(fd, 0, I915_EXEC_DEFAULT);
+   hang = spin_sync(fd, ctx, I915_EXEC_DEFAULT);
 
igt_assert_eq(__check_wait(fd, hang->handle, wait), 0);
 
@@ -276,6 +296,8 @@ static void test_wait(int fd, unsigned int flags, unsigned 
int wait)
igt_require(i915_reset_control(true));
 
trigger_reset(fd);
+
+   gem_context_destroy(fd, ctx);
 }
 
 static void test_suspend(int fd, int state)
@@ -309,6 +331,7 @@ static void test_inflight(int fd, unsigned int wait)
 
for_each_engine(fd, engine) {
struct drm_i915_gem_execbuffer2 execbuf;
+   uint32_t ctx = context_create_safe(fd);
igt_spin_t *hang;
int fence[64]; /* conservative estimate of ring size */
 
@@ -316,7 +339,7 @@ static void test_inflight(int fd, unsigned int wait)
igt_debug("Starting %s on engine '%s'\n", __func__, e__->name);
igt_require(i915_reset_control(false));
 
-   hang = spin_sync(fd, 0, engine);
+   hang = spin_sync(fd, ctx, engine);
obj[0].handle = hang->handle;
 
memset(, 0, sizeof(execbuf));
@@ -340,6 +363,8 @@ static void test_inflight(int fd, unsigned int wait)
igt_spin_batch_free(fd, hang);
igt_assert(i915_reset_control(true));
trigger_reset(fd);
+
+   gem_context_destroy(fd, ctx);
}
 }
 
@@ -350,17 +375,20 @@ static void test_inflight_suspend(int fd)
uint32_t bbe = MI_BATCH_BUFFER_END;
int fence[64]; /* conservative estimate of ring size */
igt_spin_t *hang;
+   uint32_t ctx;
 
igt_require_gem(fd);
igt_require(gem_has_exec_fence(fd));
igt_require(i915_reset_control(false));
 
+   ctx = context_create_safe(fd);
+
memset(obj, 0, sizeof(obj));
obj[0].flags = EXEC_OBJECT_WRITE;
obj[1].handle = gem_create(fd, 4096);
gem_write(fd, obj[1].handle, 0, , sizeof(bbe));
 
-   hang = spin_sync(fd, 0, 0);
+   hang = spin_sync(fd, ctx, 0);
obj[0].handle = hang->handle;
 
memset(, 0, sizeof(execbuf));
@@ -387,23 +415,8 @@ static void test_inflight_suspend(int fd)
igt_spin_batch_free(fd, hang);
igt_assert(i915_reset_control(true));
trigger_reset(fd);
-}
-
-static uint32_t context_create_safe(int i915)
-{
-   struct drm_i915_gem_context_param param;
-
-   memset(, 0, sizeof(param));
 
-   param.ctx_id = gem_context_create(i915);
-   param.param = I915_CONTEXT_PARAM_BANNABLE;
-   gem_context_set_param(i915, );
-
-   param.param = I915_CONTEXT_PARAM_NO_ERROR_CAPTURE;
-   param.value = 1;
-   gem_context_set_param(i915, );
-
-   return param.ctx_id;
+   gem_context_destroy(fd, ctx);
 }
 
 static void test_inflight_contexts(int fd, unsigned int wait)
@@ -411,40 +424,40 @@ static void test_inflight_contexts(int fd, unsigned int 
wait)
struct drm_i915_gem_exec_object2 obj[2];
const uint32_t bbe = MI_BATCH_BUFFER_END;
unsigned int engine;
-   uint32_t ctx[64];
+   uint32_t ctx[65];
 
igt_require_gem(fd);
igt_require(gem_has_exec_fence(fd));
gem_require_contexts(fd);
 
- 

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

[David Lechner]

On 03/27/2018 05:07 AM, Ville Syrjälä wrote:

On Sat, Mar 24, 2018 at 12:26:32PM -0500, David Lechner wrote:

On 03/22/2018 03:27 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

We'll need access to the plane state during .atomic_enable().



Some more details in the commit message would be useful. It is
not clear to me why this change is being made.


"tinydrm enable hook wants to play around with the new fb in
.atomic_enable(), thus we'll need access to the plane state."

Better? Worse?



Better.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michel Thierry]

On 3/16/2018 1:28 PM, Daniele Ceraolo Spurio wrote:



On 16/03/18 05:14, Mika Kuoppala wrote:

From: Michel Thierry 

The bits used to reset the different engines/domains have changed in
GEN11, this patch maps the reset engine mask bits with the new bits
in the reset control register.

v2: Use shift-left instead of BIT macro to match the file style (Paulo).
v3: Reuse gen8_reset_engines (Daniele).
v4: Do not call intel_uncore_forcewake_reset after reset, we may be
using the forcewake to read protected registers elsewhere and those
results may be clobbered by the concurrent dropping of forcewake.

bspec: 19212
Cc: Oscar Mateo 
Cc: Antonio Argenziano 
Cc: Paulo Zanoni 
Cc: Daniele Ceraolo Spurio 
Acked-by: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_reg.h | 11 
  drivers/gpu/drm/i915/intel_uncore.c | 53 
+++--

  2 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h 
b/drivers/gpu/drm/i915/i915_reg.h

index 9eaaa96287ec..f3cc77690124 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -301,6 +301,17 @@ static inline bool i915_mmio_reg_valid(i915_reg_t 
reg)

  #define  GEN6_GRDOM_VECS    (1 << 4)
  #define  GEN9_GRDOM_GUC    (1 << 5)
  #define  GEN8_GRDOM_MEDIA2    (1 << 7)
+/* GEN11 changed all bit defs except for FULL & RENDER */
+#define  GEN11_GRDOM_FULL    GEN6_GRDOM_FULL
+#define  GEN11_GRDOM_RENDER    GEN6_GRDOM_RENDER
+#define  GEN11_GRDOM_BLT    (1 << 2)
+#define  GEN11_GRDOM_GUC    (1 << 3)
+#define  GEN11_GRDOM_MEDIA    (1 << 5)
+#define  GEN11_GRDOM_MEDIA2    (1 << 6)
+#define  GEN11_GRDOM_MEDIA3    (1 << 7)
+#define  GEN11_GRDOM_MEDIA4    (1 << 8)
+#define  GEN11_GRDOM_VECS    (1 << 13)
+#define  GEN11_GRDOM_VECS2    (1 << 14)
  #define RING_PP_DIR_BASE(engine)    _MMIO((engine)->mmio_base+0x228)
  #define RING_PP_DIR_BASE_READ(engine)
_MMIO((engine)->mmio_base+0x518)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c

index 4c616d074a97..cabbf0e682e7 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1909,6 +1909,50 @@ static int gen6_reset_engines(struct 
drm_i915_private *dev_priv,

  return gen6_hw_domain_reset(dev_priv, hw_mask);
  }
+/**
+ * gen11_reset_engines - reset individual engines
+ * @dev_priv: i915 device
+ * @engine_mask: mask of intel_ring_flag() engines or ALL_ENGINES for 
full reset

+ *
+ * This function will reset the individual engines that are set in 
engine_mask.
+ * If you provide ALL_ENGINES as mask, full global domain reset will 
be issued.

+ *
+ * Note: It is responsibility of the caller to handle the difference 
between
+ * asking full domain reset versus reset for all available individual 
engines.

+ *
+ * Returns 0 on success, nonzero on error.
+ */
+static int gen11_reset_engines(struct drm_i915_private *dev_priv,
+   unsigned engine_mask)
+{
+    struct intel_engine_cs *engine;
+    const u32 hw_engine_mask[I915_NUM_ENGINES] = {
+    [RCS] = GEN11_GRDOM_RENDER,
+    [BCS] = GEN11_GRDOM_BLT,
+    [VCS] = GEN11_GRDOM_MEDIA,
+    [VCS2] = GEN11_GRDOM_MEDIA2,
+    [VCS3] = GEN11_GRDOM_MEDIA3,
+    [VCS4] = GEN11_GRDOM_MEDIA4,
+    [VECS] = GEN11_GRDOM_VECS,
+    [VECS2] = GEN11_GRDOM_VECS2,
+    };


Just a thought, but since this function is a copy of gen6_reset_engines 
with the only difference being the array (GEN11_GRDOM_FULL is also the 
same as GEN6_GRDOM_FULL), would it make sense to just add the array to 
the gen6 function? e.g.:


There are more changes for gen11 coming (locking/unlocking the shared 
SFC units), so I don't think it's a good idea to combine them.




 const u32 gen6_hw_engine_mask[] = {
 
 }
 const u32 gen11_hw_engine_mask[] = {
 
 }

 const u32 *hw_engine_mask = INTEL_GEN(dev_priv) >= 11 ?
     gen11_hw_engine_mask : gen6_hw_engine_mask;


My Ack still stands regardless and I also agree with renaming the 
defines to be closer to the specs.


Daniele


+    u32 hw_mask;
+
+    BUILD_BUG_ON(VECS2 + 1 != I915_NUM_ENGINES);
+
+    if (engine_mask == ALL_ENGINES) {
+    hw_mask = GEN11_GRDOM_FULL;
+    } else {
+    unsigned int tmp;
+
+    hw_mask = 0;
+    for_each_engine_masked(engine, dev_priv, engine_mask, tmp)
+    hw_mask |= hw_engine_mask[engine->id];
+    }
+
+    return gen6_hw_domain_reset(dev_priv, hw_mask);
+}
+
  /**
   * __intel_wait_for_register_fw - wait until register matches 
expected state

   * @dev_priv: the i915 device
@@ -2056,7 +2100,10 @@ static int gen8_reset_engines(struct 
drm_i915_private *dev_priv,

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

[Zhang, Yunwei]

On 3/26/2018 9:57 AM, Tvrtko Ursulin wrote:


On 26/03/2018 17:12, Yunwei Zhang wrote:
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any 
MMIO

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

However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all 
cases
across slice/subslice. There are rare occasions such as INSTDONE that 
this
value will be dependent on slice/subslice combo, in such cases, we 
need to

program 0xFDC and recover this after. This is already covered by
read_subslice_reg.

Also, 0xFDC will lose its information after TDR/engine reset/power state
change.

Reference: HSD#1405586840 BSID#0575

v2:
  - use fls() instead of find_last_bit() (Chris)
  - added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
  - rebase on latest tip
v4:
  - Added references (Mika)

Signed-off-by: Yunwei Zhang 
Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
---
  drivers/gpu/drm/i915/i915_drv.h    |  1 +
  drivers/gpu/drm/i915/intel_engine_cs.c | 39 
--

  2 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index 800230b..2db2a04 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2297,6 +2297,7 @@ intel_info(const struct drm_i915_private 
*dev_priv)

    #define INTEL_GEN(dev_priv)    ((dev_priv)->info.gen)
  #define INTEL_DEVID(dev_priv) ((dev_priv)->info.device_id)
+#define INTEL_SSEU(dev_priv)    ((dev_priv)->info.sseu)


If we add this someone gets the job of converting existing users?
This is suggestion from Chris Wilson, I am new here, but I guess if I am 
going to do that, it is better in a separate patch. I will remove this 
in next patchset and submit a new patch later.

    #define REVID_FOREVER    0xff
  #define INTEL_REVID(dev_priv) ((dev_priv)->drm.pdev->revision)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c

index de09fa4..cc19e0a 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct 
drm_i915_private *i915, int type)

  }
  }
  +static u32 calculate_mcr(u32 mcr, struct drm_i915_private *dev_priv)


dev_priv first would be more typical function argument order.


+{
+    const struct sseu_dev_info *sseu = &(INTEL_SSEU(dev_priv));
+    u32 slice = fls(sseu->slice_mask);
+    u32 subslice = fls(sseu->subslice_mask[slice]);
+
+    mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+    mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+
+    return mcr;
+}
+
+static void wa_init_mcr(struct drm_i915_private *dev_priv)
+{
+    u32 mcr;
+
+    mcr = I915_READ(GEN8_MCR_SELECTOR);
+    mcr = calculate_mcr(mcr, dev_priv);
+    I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+}
+
  static inline uint32_t
  read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
    int subslice, i915_reg_t reg)
@@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private 
*dev_priv, int slice,

  intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
    mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
+
  /*
   * The HW expects the slice and sublice selectors to be reset to 0
   * after reading out the registers.
   */
-    WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+    if (INTEL_GEN(dev_priv) < 10)
+    WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);


Can squash to single line WARN_ON_ONCE(INTEL_GEN() < 10 && (mcr & 
...)), if it fits.



  mcr &= ~mcr_slice_subslice_mask;
  mcr |= mcr_slice_subslice_select;
  I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
    ret = I915_READ_FW(reg);
  -    mcr &= ~mcr_slice_subslice_mask;
+    /*
+ * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
+ * expects mcr to be programed to a enabled slice/subslice pair
+ * before any MMIO read into slice/subslice register
+ */
+    if (INTEL_GEN(dev_priv) < 10)
+    mcr &= ~mcr_slice_subslice_mask;
+    else
+    mcr = calculate_mcr(mcr, dev_priv);


Does it make sense to move the conditional and comment to 
calculate_mcr - so here only a single call to it remains?
I am thinking maybe it is better to save jump/return for GENs that don't 
have WA..

+
  I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
    intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
@@ -1307,6 +1339,9 @@ static int cnl_init_workarounds(struct 
intel_engine_cs 

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

[Jeff McGee]

On Mon, Mar 26, 2018 at 12:50:41PM +0100, Chris Wilson wrote:
> Install a timer when trying to preempt on behalf of an important
> context such that if the active context does not honour the preemption
> request within the desired timeout, then we reset the GPU to allow the
> important context to run.
> 
> (Open: should not the timer be started from receiving the high priority
> request...)
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c| 53 
> +
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  8 +
>  2 files changed, 61 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 50688fc889d9..6da816d23cb3 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -533,6 +533,47 @@ static void inject_preempt_context(struct 
> intel_engine_cs *engine)
>  
>   execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
>   execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
> +
> + /* Set a timer to force preemption vs hostile userspace */
> + if (execlists->queue_preempt_timeout) {
> + GEM_TRACE("%s timeout=%uns\n",
> +   engine->name, execlists->queue_preempt_timeout);
> + hrtimer_start(>preempt_timer,
> +   ktime_set(0, execlists->queue_preempt_timeout),
> +   HRTIMER_MODE_REL);
> + }
> +}
> +
> +static enum hrtimer_restart preempt_timeout(struct hrtimer *hrtimer)
> +{
> + struct intel_engine_execlists *execlists =
> + container_of(hrtimer, typeof(*execlists), preempt_timer);
> +
> + GEM_TRACE("%s\n",
> +   container_of(execlists,
> +struct intel_engine_cs,
> +execlists)->name);
> +
> + queue_work(system_highpri_wq, >preempt_reset);
> + return HRTIMER_NORESTART;
> +}
> +
> +static void preempt_reset(struct work_struct *work)
> +{
> + struct intel_engine_cs *engine =
> + container_of(work, typeof(*engine), execlists.preempt_reset);
> +
> + GEM_TRACE("%s\n", engine->name);
> +
> + tasklet_disable(>execlists.tasklet);
> +
> + engine->execlists.tasklet.func(engine->execlists.tasklet.data);
This seems redundant with the execlists_reset_prepare already doing a 
process_csb
at a later time to decide whether to execute or abort the reset. In your
previous proposal you suggested tasklet disable and kill here.

> +
> + if (execlists_is_active(>execlists, EXECLISTS_ACTIVE_PREEMPT))
> + i915_handle_error(engine->i915, BIT(engine->id), 0,
> +   "preemption timed out on %s", engine->name);
> +
> + tasklet_enable(>execlists.tasklet);
>  }
>  
>  static void complete_preempt_context(struct intel_engine_execlists 
> *execlists)
> @@ -542,6 +583,10 @@ static void complete_preempt_context(struct 
> intel_engine_execlists *execlists)
>   execlists_cancel_port_requests(execlists);
>   execlists_unwind_incomplete_requests(execlists);
>  
> + /* If the timer already fired, complete the reset */
> + if (hrtimer_try_to_cancel(>preempt_timer) < 0)
> + return;
> +
>   execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
>  }
>  
> @@ -708,6 +753,7 @@ static void execlists_dequeue(struct intel_engine_cs 
> *engine)
>   kmem_cache_free(engine->i915->priorities, p);
>   }
>  done:
> + execlists->queue_preempt_timeout = 0; /* preemption point passed */
>   execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
>   execlists->first = rb;
>   if (submit)
> @@ -864,6 +910,7 @@ static void execlists_cancel_requests(struct 
> intel_engine_cs *engine)
>  
>   /* Remaining _unready_ requests will be nop'ed when submitted */
>  
> + execlists->queue_preempt_timeout = 0;
>   execlists->queue_priority = INT_MIN;
>   execlists->queue = RB_ROOT;
>   execlists->first = NULL;
> @@ -1080,6 +1127,7 @@ static void queue_request(struct intel_engine_cs 
> *engine,
>  static void __submit_queue(struct intel_engine_cs *engine, int prio)
>  {
>   engine->execlists.queue_priority = prio;
> + engine->execlists.queue_preempt_timeout = 0;
>   tasklet_hi_schedule(>execlists.tasklet);
>  }
>  
> @@ -2270,6 +2318,11 @@ logical_ring_setup(struct intel_engine_cs *engine)
>   tasklet_init(>execlists.tasklet,
>execlists_submission_tasklet, (unsigned long)engine);
>  
> + INIT_WORK(>execlists.preempt_reset, preempt_reset);
> + hrtimer_init(>execlists.preempt_timer,
> +  CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + engine->execlists.preempt_timer.function = preempt_timeout;
> +
>   logical_ring_default_vfuncs(engine);
>   logical_ring_default_irqs(engine);
>  }
> diff --git 

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

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-27 16:41:14)
> 
> [resend for typo in cc]

The small advantage in redundancy, I guess.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jeff McGee]

On Tue, Mar 27, 2018 at 09:51:20AM +0100, Tvrtko Ursulin wrote:
> 
> On 26/03/2018 12:50, Chris Wilson wrote:
> >Install a timer when trying to preempt on behalf of an important
> >context such that if the active context does not honour the preemption
> >request within the desired timeout, then we reset the GPU to allow the
> >important context to run.
> 
> I suggest renaming patch title to "Implement optional preemption
> delay timeout", or "upper bound", or something, as long as it is not
> "force preemption". :)
> 
> >(Open: should not the timer be started from receiving the high priority
> >request...)
> 
> If you think receiving as in execbuf I think not - that would be
> something else and not preempt timeout.
> 
> >Signed-off-by: Chris Wilson 
> >---
> >  drivers/gpu/drm/i915/intel_lrc.c| 53 
> > +
> >  drivers/gpu/drm/i915/intel_ringbuffer.h |  8 +
> >  2 files changed, 61 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index 50688fc889d9..6da816d23cb3 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -533,6 +533,47 @@ static void inject_preempt_context(struct 
> >intel_engine_cs *engine)
> > execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
> > execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
> >+
> >+/* Set a timer to force preemption vs hostile userspace */
> >+if (execlists->queue_preempt_timeout) {
> >+GEM_TRACE("%s timeout=%uns\n",
> 
> preempt-timeout ?
> 
> >+  engine->name, execlists->queue_preempt_timeout);
> >+hrtimer_start(>preempt_timer,
> >+  ktime_set(0, execlists->queue_preempt_timeout),
> >+  HRTIMER_MODE_REL);
> >+}
> >+}
> >+
> >+static enum hrtimer_restart preempt_timeout(struct hrtimer *hrtimer)
> >+{
> >+struct intel_engine_execlists *execlists =
> >+container_of(hrtimer, typeof(*execlists), preempt_timer);
> >+
> >+GEM_TRACE("%s\n",
> >+  container_of(execlists,
> >+   struct intel_engine_cs,
> >+   execlists)->name);
> >+
> >+queue_work(system_highpri_wq, >preempt_reset);
> 
> I suppose indirection from hrtimer to worker is for better than
> jiffie timeout granularity? But then queue_work might introduce some
> delay to defeat that.
> 
> I am wondering if simply schedule_delayed_work directly wouldn't be
> good enough. I suppose it is a question for the product group. But
> it is also implementation detail.
> 
I started with schedule_delayed_work in my implementation hoping for
at least consistent msec accuracy, but it was all over the place.
We need msec granularity for the automotive use cases.
-Jeff

> >+return HRTIMER_NORESTART;
> >+}
> >+
> >+static void preempt_reset(struct work_struct *work)
> >+{
> >+struct intel_engine_cs *engine =
> >+container_of(work, typeof(*engine), execlists.preempt_reset);
> >+
> >+GEM_TRACE("%s\n", engine->name);
> >+
> >+tasklet_disable(>execlists.tasklet);
> >+
> >+engine->execlists.tasklet.func(engine->execlists.tasklet.data);
> 
> Comment on why calling the tasklet directly.
> 
> >+
> >+if (execlists_is_active(>execlists, EXECLISTS_ACTIVE_PREEMPT))
> >+i915_handle_error(engine->i915, BIT(engine->id), 0,
> >+  "preemption timed out on %s", engine->name);
> 
> Can this race with the normal reset and we end up wit
> i915_handle_error twice simultaneously?
> 
> >+
> >+tasklet_enable(>execlists.tasklet);
> >  }
> >  static void complete_preempt_context(struct intel_engine_execlists 
> > *execlists)
> >@@ -542,6 +583,10 @@ static void complete_preempt_context(struct 
> >intel_engine_execlists *execlists)
> > execlists_cancel_port_requests(execlists);
> > execlists_unwind_incomplete_requests(execlists);
> >+/* If the timer already fired, complete the reset */
> >+if (hrtimer_try_to_cancel(>preempt_timer) < 0)
> >+return;
> 
> What about timer which had already fired and queued the worker?
> hrtimer_try_to_cancel will return zero for that case I think.
> 
> >+
> > execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
> >  }
> >@@ -708,6 +753,7 @@ static void execlists_dequeue(struct intel_engine_cs 
> >*engine)
> > kmem_cache_free(engine->i915->priorities, p);
> > }
> >  done:
> >+execlists->queue_preempt_timeout = 0; /* preemption point passed */
> > execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
> > execlists->first = rb;
> > if (submit)
> >@@ -864,6 +910,7 @@ static void execlists_cancel_requests(struct 
> >intel_engine_cs *engine)
> > /* Remaining _unready_ requests will be nop'ed when submitted */
> >+execlists->queue_preempt_timeout = 0;
> > 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen11: Preempt-to-idle support in execlists.

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: Preempt-to-idle support in execlists.
URL   : https://patchwork.freedesktop.org/series/40747/
State : success

== Summary ==

Series 40747v1 drm/i915/gen11: Preempt-to-idle support in execlists.
https://patchwork.freedesktop.org/api/1.0/series/40747/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-cnl-y3) fdo#104951
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:451s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:547s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:302s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:514s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:515s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:529s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:514s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:515s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:594s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:430s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:326s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:285  pass:224  dwarn:0   dfail:0   fail:1   skip:60  
time:421s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:434s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:479s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:660s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:531s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:430s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:449s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:584s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:403s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:255  dwarn:3   dfail:0   fail:1   skip:26  
time:534s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:495s

ff7820832182a0f4bebf9092a74ab17f8b3ae7ef drm-tip: 2018y-03m-27d-14h-31m-00s UTC 
integration manifest
96268839cd00 drm/i915/gen11: Preempt-to-idle support in execlists.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8505/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jeff McGee]

On Tue, Mar 27, 2018 at 12:44:02PM +0100, Chris Wilson wrote:
> Catch up with the inflight CSB events, after disabling the tasklet
> before deciding which request was truly guilty of hanging the GPU.
> 
> v2: Restore checking of use_csb_mmio on every loop, don't forget old
> vgpu.
> 
> Signed-off-by: Chris Wilson 
> Cc: Michał Winiarski 
> CC: Michel Thierry 
> Cc: Jeff McGee 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 127 
> +++
>  1 file changed, 87 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index cf31b0749023..75dbdedde8b0 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -874,34 +874,14 @@ static void execlists_cancel_requests(struct 
> intel_engine_cs *engine)
>   local_irq_restore(flags);
>  }
>  
> -/*
> - * Check the unread Context Status Buffers and manage the submission of new
> - * contexts to the ELSP accordingly.
> - */
> -static void execlists_submission_tasklet(unsigned long data)
> +static void process_csb(struct intel_engine_cs *engine)
>  {
> - struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
>   struct intel_engine_execlists * const execlists = >execlists;
>   struct execlist_port * const port = execlists->port;
> - struct drm_i915_private *dev_priv = engine->i915;
> + struct drm_i915_private *i915 = engine->i915;
>   bool fw = false;
>  
> - /*
> -  * We can skip acquiring intel_runtime_pm_get() here as it was taken
> -  * on our behalf by the request (see i915_gem_mark_busy()) and it will
> -  * not be relinquished until the device is idle (see
> -  * i915_gem_idle_work_handler()). As a precaution, we make sure
> -  * that all ELSP are drained i.e. we have processed the CSB,
> -  * before allowing ourselves to idle and calling intel_runtime_pm_put().
> -  */
> - GEM_BUG_ON(!dev_priv->gt.awake);
> -
> - /*
> -  * Prefer doing test_and_clear_bit() as a two stage operation to avoid
> -  * imposing the cost of a locked atomic transaction when submitting a
> -  * new request (outside of the context-switch interrupt).
> -  */
> - while (test_bit(ENGINE_IRQ_EXECLIST, >irq_posted)) {
> + do {
Wouldn't it be simpler for process_csb to use a while loop here, and for
callers that need a CSB processing point to just call it without themselves
checking irq_posted? Are we really saving much with the if-do-while approach?

>   /* The HWSP contains a (cacheable) mirror of the CSB */
>   const u32 *buf =
>   >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
> @@ -909,28 +889,27 @@ static void execlists_submission_tasklet(unsigned long 
> data)
>  
>   if (unlikely(execlists->csb_use_mmio)) {
>   buf = (u32 * __force)
> - (dev_priv->regs + 
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
> - execlists->csb_head = -1; /* force mmio read of CSB 
> ptrs */
> + (i915->regs + 
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
> + execlists->csb_head = -1; /* force mmio read of CSB */
>   }
>  
>   /* Clear before reading to catch new interrupts */
>   clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
>   smp_mb__after_atomic();
>  
> - if (unlikely(execlists->csb_head == -1)) { /* following a reset 
> */
> + if (unlikely(execlists->csb_head == -1)) { /* after a reset */
>   if (!fw) {
> - intel_uncore_forcewake_get(dev_priv,
> -
> execlists->fw_domains);
> + intel_uncore_forcewake_get(i915, 
> execlists->fw_domains);
>   fw = true;
>   }
>  
> - head = readl(dev_priv->regs + 
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
> + head = readl(i915->regs + 
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
>   tail = GEN8_CSB_WRITE_PTR(head);
>   head = GEN8_CSB_READ_PTR(head);
>   execlists->csb_head = head;
>   } else {
>   const int write_idx =
> - intel_hws_csb_write_index(dev_priv) -
> + intel_hws_csb_write_index(i915) -
>   I915_HWS_CSB_BUF0_INDEX;
>  
>   head = execlists->csb_head;
> @@ -938,8 +917,8 @@ static void execlists_submission_tasklet(unsigned long 
> data)
>   }
>   GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d 

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

[Tvrtko Ursulin]

[resend for typo in cc]

On 27/03/2018 14:59, Chris Wilson wrote:

Quoting Chris Wilson (2018-03-27 14:52:20)

Quoting Chris Wilson (2018-03-27 14:48:43)

If we inject a reset into the target context, there is a risk that the
register state is never saved back to memory. The exact interaction
between reset, the context image and the precise timing of our execution
are not well defined. Since we cannot ensure that the context image
remains valid, force a context switch prior to the reset.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105270
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105457
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105545
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
  tests/gem_ctx_isolation.c | 28 +++-
  1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
index d8109aa0..4968e367 100644
--- a/tests/gem_ctx_isolation.c
+++ b/tests/gem_ctx_isolation.c
@@ -522,6 +522,32 @@ static void isolation(int fd,
  #define S4 (4 << 8)
  #define SLEEP_MASK (0xf << 8)
  
+static void inject_reset_context(int fd, unsigned int engine)

+{
+   igt_spin_t *spin;
+   uint32_t ctx;
+
+   /*
+* Force a context switch before triggering the reset, or else
+* we risk corrupting the target context and we can't blame the
+* HW for screwing up if the context was already broken.
+*/
+
+   ctx = gem_context_create(fd);
+   if (gem_can_store_dword(fd, engine)) {
+   spin = __igt_spin_batch_new_poll(fd, ctx, engine);
+   igt_spin_busywait_until_running(spin);
+   } else {
+   spin = __igt_spin_batch_new(fd, ctx, engine, 0);
+   usleep(1000); /* better than nothing */
+   }


Tvrtko, maybe we want igt_spin_batch_run()? Not sure though, so far we
have an example where you need precise control and a couple of examples
where we just want a running spinner.


I wasn't sure it is in good taste to put a thing with that usleep in 
lib/, since it incurs a delay to unsuspecting callers. And I couldn't 
decide how to handle it better - skip from lib/? Not so great. Return 
value and make callers handle it - even more cumbersome.


It only affects old gens, but do we want tests there suddenly take much 
longer because someone spotted a cool new API and went to use it?


But it is a third user now so not great to copy paste it all around. I 
don't know. Make the lib functions skip where unsupported and add double 
underscore prefix flavour which sleeps where not supported?



Also this whole function might want to make its way into lib/i915 as the
basis of all hang/reset injection. Some improvement required to set
context parameters (e.g. disabling error state capturing) and skipping
if no reset is available or disabled (although that's the job for the
fixture, so may not be required for the library function). I'm sure
someone will catch me reusing this chunk over and over again...


Sounds OK to me.

Regards,

Tvrtko


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Tvrtko Ursulin]

[resend for typo in cc]

On 27/03/2018 14:48, Chris Wilson wrote:

If we inject a reset into the target context, there is a risk that the
register state is never saved back to memory. The exact interaction
between reset, the context image and the precise timing of our execution
are not well defined. Since we cannot ensure that the context image
remains valid, force a context switch prior to the reset.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105270
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105457
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105545
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
  tests/gem_ctx_isolation.c | 28 +++-
  1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
index d8109aa0..4968e367 100644
--- a/tests/gem_ctx_isolation.c
+++ b/tests/gem_ctx_isolation.c
@@ -522,6 +522,32 @@ static void isolation(int fd,
  #define S4 (4 << 8)
  #define SLEEP_MASK (0xf << 8)
  
+static void inject_reset_context(int fd, unsigned int engine)

+{
+   igt_spin_t *spin;
+   uint32_t ctx;
+
+   /*
+* Force a context switch before triggering the reset, or else
+* we risk corrupting the target context and we can't blame the
+* HW for screwing up if the context was already broken.
+*/
+
+   ctx = gem_context_create(fd);
+   if (gem_can_store_dword(fd, engine)) {
+   spin = __igt_spin_batch_new_poll(fd, ctx, engine);
+   igt_spin_busywait_until_running(spin);
+   } else {
+   spin = __igt_spin_batch_new(fd, ctx, engine, 0);
+   usleep(1000); /* better than nothing */
+   }
+
+   igt_force_gpu_reset(fd);
+
+   igt_spin_batch_free(fd, spin);
+   gem_context_destroy(fd, ctx);
+}
+
  static void preservation(int fd,
 const struct intel_execution_engine2 *e,
 unsigned int flags)
@@ -558,7 +584,7 @@ static void preservation(int fd,
igt_spin_batch_free(fd, spin);
  
  	if (flags & RESET)

-   igt_force_gpu_reset(fd);
+   inject_reset_context(fd, engine);
  
  	switch (flags & SLEEP_MASK) {

case NOSLEEP:



Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: Preempt-to-idle support in execlists.
URL   : https://patchwork.freedesktop.org/series/40747/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
96268839cd00 drm/i915/gen11: Preempt-to-idle support in execlists.
-:97: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"execlists->ctrl_reg"
#97: FILE: drivers/gpu/drm/i915/intel_lrc.c:551:
+   GEM_BUG_ON(execlists->ctrl_reg != NULL);

-:149: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#149: FILE: drivers/gpu/drm/i915/intel_lrc.c:1013:
+   buf[2*head + 1] == 
execlists->preempt_complete_status)) {
 ^

total: 0 errors, 0 warnings, 2 checks, 114 lines checked

___
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 [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling (rev2)

[Patchwork]

== Series Details ==

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

== Summary ==

 Possible new issues:

Test gem_ctx_param:
Subgroup invalid-param-get:
pass   -> FAIL   (shard-apl)
pass   -> FAIL   (shard-hsw)
pass   -> FAIL   (shard-snb)
Subgroup invalid-param-set:
pass   -> FAIL   (shard-apl)
pass   -> FAIL   (shard-hsw)
pass   -> FAIL   (shard-snb)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-crc-atomic:
fail   -> PASS   (shard-hsw)
Subgroup short-flip-before-cursor-atomic-transitions:
skip   -> PASS   (shard-snb)

 Known issues:

Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368
Subgroup flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw) fdo#102887 +1
Subgroup modeset-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060 +2
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3495 pass:1830 dwarn:1   dfail:0   fail:9   skip:1655 
time:12892s
shard-hswtotal:3495 pass:1778 dwarn:1   dfail:0   fail:6   skip:1709 
time:11628s
shard-snbtotal:3495 pass:1372 dwarn:1   dfail:0   fail:5   skip:2117 
time:6987s
Blacklisted hosts:
shard-kbltotal:3495 pass:1951 dwarn:1   dfail:0   fail:13  skip:1530 
time:9722s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8503/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Tomasz Lis]

The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result from
Context Status Buffer.

Preemption in previous gens required a special batch buffer to be executed,
so the Command Streamer never preempted to idle directly. In Icelake it is
possible, as there is a hardware mechanism to inform the kernel about
status of the preemption request.

This patch does not cover using the new preemption mechanism when GuC is
active.

Bspec: 18922
Signed-off-by: Tomasz Lis 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_pci.c  |  3 ++-
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 drivers/gpu/drm/i915/intel_lrc.c | 45 +++-
 drivers/gpu/drm/i915/intel_lrc.h |  1 +
 5 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 800230b..c32580b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2514,6 +2514,8 @@ intel_info(const struct drm_i915_private *dev_priv)
((dev_priv)->info.has_logical_ring_elsq)
 #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
((dev_priv)->info.has_logical_ring_preemption)
+#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
+   ((dev_priv)->info.has_hw_preempt_to_idle)
 
 #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 4364922..66b6700 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -595,7 +595,8 @@ static const struct intel_device_info intel_cannonlake_info 
= {
GEN(11), \
.ddb_size = 2048, \
.has_csr = 0, \
-   .has_logical_ring_elsq = 1
+   .has_logical_ring_elsq = 1, \
+   .has_hw_preempt_to_idle = 1
 
 static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 933e316..4eb97b5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -98,6 +98,7 @@ enum intel_platform {
func(has_logical_ring_contexts); \
func(has_logical_ring_elsq); \
func(has_logical_ring_preemption); \
+   func(has_hw_preempt_to_idle); \
func(has_overlay); \
func(has_pooled_eu); \
func(has_psr); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ba7f783..1a22de4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -153,6 +153,7 @@
 #define GEN8_CTX_STATUS_ACTIVE_IDLE(1 << 3)
 #define GEN8_CTX_STATUS_COMPLETE   (1 << 4)
 #define GEN8_CTX_STATUS_LITE_RESTORE   (1 << 15)
+#define GEN11_CTX_STATUS_PREEMPT_IDLE  (1 << 29)
 
 #define GEN8_CTX_STATUS_COMPLETED_MASK \
 (GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
@@ -183,7 +184,9 @@ static inline bool need_preempt(const struct 
intel_engine_cs *engine,
const struct i915_request *last,
int prio)
 {
-   return engine->i915->preempt_context && prio > max(rq_prio(last), 0);
+   return (engine->i915->preempt_context ||
+   HAS_HW_PREEMPT_TO_IDLE(engine->i915)) &&
+prio > max(rq_prio(last), 0);
 }
 
 /**
@@ -535,6 +538,25 @@ static void inject_preempt_context(struct intel_engine_cs 
*engine)
execlists_set_active(>execlists, EXECLISTS_ACTIVE_PREEMPT);
 }
 
+static void gen11_preempt_to_idle(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists *execlists = >execlists;
+
+   GEM_TRACE("%s\n", engine->name);
+
+   /*
+* hardware which HAS_HW_PREEMPT_TO_IDLE(), always also
+* HAS_LOGICAL_RING_ELSQ(), so we can assume ctrl_reg is set
+*/
+   GEM_BUG_ON(execlists->ctrl_reg != NULL);
+
+   /* trigger preemption to idle */
+   writel(EL_CTRL_PREEMPT_TO_IDLE, execlists->ctrl_reg);
+
+   execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
+   execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
 static void execlists_dequeue(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = >execlists;
@@ -594,7 +616,10 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
goto unlock;
 
if (need_preempt(engine, last, execlists->queue_priority)) {
-   inject_preempt_context(engine);
+   if (HAS_HW_PREEMPT_TO_IDLE(engine->i915))
+   gen11_preempt_to_idle(engine);
+   else
+   inject_preempt_context(engine);
goto unlock;
}
 
@@ -962,10 

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

[Joonas Lahtinen]

Hi Dave,

Two human-reported bugs to close for display and a more rare fix
that could result in GPU hang.

There was some unclarity about the GVT pull, so I'm not including
it here.

Happy Easter holidays!

Regards, Joonas

drm-intel-next-fixes-2018-03-27:
- Display fixes for booting with MST hub lid closed and display
  freezing after hibernation (fd.o bugs 105470 & 105196)
- Fix for a very rare interrupt handling race resulting in GPU hang

The following changes since commit 33d009cd889490838c5db9b9339856c9e3d3facc:

  Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2018-03-26 10:01:11 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2018-03-27

for you to fetch changes up to 300efa9eea451bdcf3b5a1eb29e06e85bb2c:

  drm/i915: Fix hibernation with ACPI S0 target state (2018-03-27 11:20:06 
+0300)


- Display fixes for booting with MST hub lid closed and display
  freezing after hibernation (fd.o bugs 105470 & 105196)
- Fix for a very rare interrupt handling race resulting in GPU hang


Chris Wilson (2):
  drm/i915: Specify which engines to reset following semaphore/event lockups
  drm/i915/execlists: Use a locked clear_bit() for synchronisation with 
interrupt

Dhinakaran Pandiyan (1):
  drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.

Imre Deak (1):
  drm/i915: Fix hibernation with ACPI S0 target state

 drivers/gpu/drm/i915/i915_drv.c| 22 ++
 drivers/gpu/drm/i915/i915_drv.h|  2 +-
 drivers/gpu/drm/i915/intel_ddi.c   |  7 ++-
 drivers/gpu/drm/i915/intel_hangcheck.c |  4 ++--
 drivers/gpu/drm/i915/intel_lrc.c   | 21 -
 5 files changed, 23 insertions(+), 33 deletions(-)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Tvrtko Ursulin]

On 27/03/2018 15:28, Chris Wilson wrote:

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

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105712
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  overlay/power.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/overlay/power.c b/overlay/power.c
index 9ac90fde..0f99e2a4 100644
--- a/overlay/power.c
+++ b/overlay/power.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include "igt_perf.h"

@@ -97,12 +98,18 @@ static uint64_t rapl_gpu_power(void)
  
  static double filename_to_double(const char *filename)

  {
-   char buf[64];
+   char *oldlocale;
+   char buf[80];
+   double v;
  
  	if (filename_to_buf(filename, buf, sizeof(buf)))

return 0;
  
-	return strtod(buf, NULL);

+   oldlocale = setlocale(LC_ALL, "C");
+   v = strtod(buf, NULL);
+   setlocale(LC_ALL, oldlocale);
+
+   return v;
  }
  
  static double rapl_gpu_power_scale(void)




Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Joonas Lahtinen]

Quoting Joonas Lahtinen (2018-03-27 16:42:28)
> Quoting Zhenyu Wang (2018-03-27 11:39:42)
> > 
> > Hi, Joonas
> > 
> > Here's this week's gvt-next-fixes queued for 4.17. One notable change
> > is to revert previous workaround for gvt context preemption, now it
> > has full support for preemption now. 
> 
> I've pulled the patches, but this revert sounds fishy. Is it something
> that should have been done together with a commit in a batch introduced
> to 4.17? To me, this sounds much like a feature patch, "enable
> pre-emption on GVT context" is even written in the tag.
> 
> So I'm inclined to drop this patch from -fixes pull.

On a second thought, I'll drop the whole pull to make it less of a
hassle with rebases. Please send and updated pull with just the fix
patches.

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-26 17:57:38)
> 
> On 26/03/2018 17:12, Yunwei Zhang wrote:
> > ---
> >   drivers/gpu/drm/i915/i915_drv.h|  1 +
> >   drivers/gpu/drm/i915/intel_engine_cs.c | 39 
> > --
> >   2 files changed, 38 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 800230b..2db2a04 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2297,6 +2297,7 @@ intel_info(const struct drm_i915_private *dev_priv)
> >   
> >   #define INTEL_GEN(dev_priv) ((dev_priv)->info.gen)
> >   #define INTEL_DEVID(dev_priv)   ((dev_priv)->info.device_id)
> > +#define INTEL_SSEU(dev_priv) ((dev_priv)->info.sseu)
> 
> If we add this someone gets the job of converting existing users?

My bad, I hadn't realised that the INTEL_SSEU conversion was local to my
tree. It must have fallen out as part of the static device_info reform.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

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

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105712
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 overlay/power.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/overlay/power.c b/overlay/power.c
index 9ac90fde..0f99e2a4 100644
--- a/overlay/power.c
+++ b/overlay/power.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "igt_perf.h"
@@ -97,12 +98,18 @@ static uint64_t rapl_gpu_power(void)
 
 static double filename_to_double(const char *filename)
 {
-   char buf[64];
+   char *oldlocale;
+   char buf[80];
+   double v;
 
if (filename_to_buf(filename, buf, sizeof(buf)))
return 0;
 
-   return strtod(buf, NULL);
+   oldlocale = setlocale(LC_ALL, "C");
+   v = strtod(buf, NULL);
+   setlocale(LC_ALL, oldlocale);
+
+   return v;
 }
 
 static double rapl_gpu_power_scale(void)
-- 
2.16.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Mika Kuoppala]

Yunwei Zhang  writes:

> WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
> read into Slice/Subslice specific registers, MCR packet control
> register(0xFDC) needs to be programmed to point to any enabled
> slice/subslice pair. Otherwise, incorrect value will be returned.
>
> However, that means each subsequent MMIO read will be forwarded to a
> specific slice/subslice combination as read is unicast. This is OK since
> slice/subslice specific register values are consistent in almost all cases
> across slice/subslice. There are rare occasions such as INSTDONE that this
> value will be dependent on slice/subslice combo, in such cases, we need to
> program 0xFDC and recover this after. This is already covered by
> read_subslice_reg.
>
> Also, 0xFDC will lose its information after TDR/engine reset/power state
> change.
>
> Reference: HSD#1405586840 BSID#0575

Use plural, and add comma in between.

Move 'References' right before Cc:s after the version log...

>
> v2:
>  - use fls() instead of find_last_bit() (Chris)
>  - added INTEL_SSEU to extract sseu from device info. (Chris)
> v3:
>  - rebase on latest tip
> v4:
>  - Added references (Mika)
>

.. in here.

And we usually do put Cc:s before s-o-b.

For example, see commit 465418c6064c88d4af555abe0480c417eb47eae3

Thanks,
-Mika

> Signed-off-by: Yunwei Zhang 
> Cc: Oscar Mateo 
> Cc: Michel Thierry 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  1 +
>  drivers/gpu/drm/i915/intel_engine_cs.c | 39 
> --
>  2 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 800230b..2db2a04 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2297,6 +2297,7 @@ intel_info(const struct drm_i915_private *dev_priv)
>  
>  #define INTEL_GEN(dev_priv)  ((dev_priv)->info.gen)
>  #define INTEL_DEVID(dev_priv)((dev_priv)->info.device_id)
> +#define INTEL_SSEU(dev_priv) ((dev_priv)->info.sseu)
>  
>  #define REVID_FOREVER0xff
>  #define INTEL_REVID(dev_priv)((dev_priv)->drm.pdev->revision)
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index de09fa4..cc19e0a 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private 
> *i915, int type)
>   }
>  }
>  
> +static u32 calculate_mcr(u32 mcr, struct drm_i915_private *dev_priv)
> +{
> + const struct sseu_dev_info *sseu = &(INTEL_SSEU(dev_priv));
> + u32 slice = fls(sseu->slice_mask);
> + u32 subslice = fls(sseu->subslice_mask[slice]);
> +
> + mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
> + mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> +
> + return mcr;
> +}
> +
> +static void wa_init_mcr(struct drm_i915_private *dev_priv)
> +{
> + u32 mcr;
> +
> + mcr = I915_READ(GEN8_MCR_SELECTOR);
> + mcr = calculate_mcr(mcr, dev_priv);
> + I915_WRITE(GEN8_MCR_SELECTOR, mcr);
> +}
> +
>  static inline uint32_t
>  read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
> int subslice, i915_reg_t reg)
> @@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv, 
> int slice,
>   intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
>  
>   mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
> +
>   /*
>* The HW expects the slice and sublice selectors to be reset to 0
>* after reading out the registers.
>*/
> - WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
> + if (INTEL_GEN(dev_priv) < 10)
> + WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
>   mcr &= ~mcr_slice_subslice_mask;
>   mcr |= mcr_slice_subslice_select;
>   I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
>  
>   ret = I915_READ_FW(reg);
>  
> - mcr &= ~mcr_slice_subslice_mask;
> + /*
> +  * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
> +  * expects mcr to be programed to a enabled slice/subslice pair
> +  * before any MMIO read into slice/subslice register
> +  */
> + if (INTEL_GEN(dev_priv) < 10)
> + mcr &= ~mcr_slice_subslice_mask;
> + else
> + mcr = calculate_mcr(mcr, dev_priv);
> +
>   I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
>  
>   intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
> @@ -1307,6 +1339,9 @@ static int cnl_init_workarounds(struct intel_engine_cs 
> *engine)
>   struct drm_i915_private *dev_priv = engine->i915;
>   int ret;
>  
> + /* WaProgramMgsrForCorrectSliceSpecificMmioReads: cnl */
> + 

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

[Patchwork]

== Series Details ==

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

== Summary ==

 Known issues:

Test kms_cursor_legacy:
Subgroup flip-vs-cursor-atomic:
pass   -> FAIL   (shard-hsw) fdo#102670
Test kms_flip:
Subgroup 2x-flip-vs-wf_vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Subgroup flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-cur-indfb-draw-blt:
pass   -> FAIL   (shard-apl) fdo#103167

fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

shard-apltotal:3495 pass:1830 dwarn:1   dfail:0   fail:8   skip:1655 
time:12877s
shard-hswtotal:3495 pass:1781 dwarn:1   dfail:0   fail:3   skip:1709 
time:11675s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:7068s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8500/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 Documentation patch for batchbuffer submission (rev3)

[Patchwork]

== Series Details ==

Series: Documentation patch for batchbuffer submission (rev3)
URL   : https://patchwork.freedesktop.org/series/38433/
State : failure

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
pass   -> FAIL   (shard-apl)

 Known issues:

Test drv_selftest:
Subgroup live_gtt:
pass   -> INCOMPLETE (shard-apl) fdo#103927
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup 2x-flip-vs-wf_vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +2
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-apl) fdo#103060

fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060

shard-apltotal:3473 pass:1806 dwarn:1   dfail:0   fail:9   skip:1655 
time:12404s
shard-hswtotal:3495 pass:1780 dwarn:1   dfail:0   fail:4   skip:1709 
time:11507s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:6994s
Blacklisted hosts:
shard-kbltotal:3495 pass:1956 dwarn:1   dfail:0   fail:9   skip:1529 
time:9707s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8499/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 trace: Default to using trace_global_clock is sched_clock is unstable

[Patchwork]

== Series Details ==

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

== Summary ==

 Known issues:

Test gem_softpin:
Subgroup noreloc-s3:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_flip:
Subgroup 2x-flip-vs-wf_vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368

fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-apltotal:3495 pass:1831 dwarn:1   dfail:0   fail:7   skip:1655 
time:12919s
shard-hswtotal:3480 pass:1776 dwarn:1   dfail:0   fail:1   skip:1700 
time:11155s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:7016s
Blacklisted hosts:
shard-kbltotal:3495 pass:1954 dwarn:1   dfail:1   fail:9   skip:1530 
time:9709s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8498/shards.html
___
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/guc: Support for Guc responses and requests (rev4)

[Patchwork]

== Series Details ==

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

== Summary ==

Series 28393v4 drm/i915/guc: Support for Guc responses and requests
https://patchwork.freedesktop.org/api/1.0/series/28393/revisions/4/mbox/

 Known issues:

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700k2) fdo#104108
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575

fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:539s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:516s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:521s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:523s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:511s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:513s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:591s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:428s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:322s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:515s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:665s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:532s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:428s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:589s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:401s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:519s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:485s

1a95bcd16cb9db1eca19346e911fea27ab5d1dc4 drm-tip: 2018y-03m-27d-12h-36m-37s UTC 
integration manifest
1ebea50f3714 HAX: Enable GuC for CI
6cf9f23d08da drm/i915/guc: Trace messages from CT while in debug
e483ca83c16f drm/i915/guc: Handle default action received over CT
9929b8a0a514 drm/i915/guc: Prepare to process incoming requests from CT
76c7ae511fbb drm/i915/guc: Implement response handling in send_ct()
8f0de3072e13 drm/i915/guc: Use better name for helper wait function
6a848e5c75d4 drm/i915/guc: Prepare to handle messages from CT RECV buffer
68a6483fd201 drm/i915/guc: Make event handler a virtual function
689b8276f19b drm/i915/guc: Implement response handling in send_mmio()
6526f39007de drm/i915/guc: Prepare send() function to accept bigger response
d9409b06a463 drm/i915/guc: Add support for data reporting in GuC responses
6df3882e6146 drm/i915/guc: Add documentation for MMIO based communication

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8504/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Joonas Lahtinen]

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

I've pulled the patches, but this revert sounds fishy. Is it something
that should have been done together with a commit in a batch introduced
to 4.17? To me, this sounds much like a feature patch, "enable
pre-emption on GVT context" is even written in the tag.

So I'm inclined to drop this patch from -fixes pull.

Is there some specific reason why you don't use Fixes: tagging to
make it easier to track which patches the fixes apply to, if there are
some?

Regards, Joonas

> Others are normal fixes and
> optimizations.
> 
> Thanks
> --
> The following changes since commit d8303075699292008ae5b2c8fc728d455b994c26:
> 
>   drm/i915/gvt: force to set all context control bits from guest (2018-03-19 
> 17:33:30 +0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-03-27
> 
> for you to fetch changes up to 21e6e1af36a3c9b1c34bc441e5fa27cb36fbb830:
> 
>   drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore 
> (2018-03-27 11:20:58 +0800)
> 
> 
> gvt-next-fixes-2018-03-27
> 
> - fix unhandled vfio ioctl return value (Gerd)
> - revert gvt ctx preemption workaround, enable preemption
>   on gvt context! (Weinan)
> - no-op user interrupt for vGPU (Zhipeng)
> - fix eventfd ctx deference (Xiong)
> - misc cleanup
> 
> 
> Gerd Hoffmann (1):
>   drm/i915/gvt: throw error on unhandled vfio ioctls
> 
> Gustavo A. R. Silva (1):
>   drm/i915/gvt: Mark expected switch fall-through in 
> handle_g2v_notification
> 
> Weinan Li (1):
>   Revert "drm/i915/gvt: set max priority for gvt context"
> 
> Xiong Zhang (1):
>   drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore
> 
> Zhipeng Gong (1):
>   drm/i915/gvt: Make MI_USER_INTERRUPT nop in cmd parser
> 
>  drivers/gpu/drm/i915/gvt/cmd_parser.c |  1 +
>  drivers/gpu/drm/i915/gvt/handlers.c   |  1 +
>  drivers/gpu/drm/i915/gvt/kvmgt.c  | 18 --
>  drivers/gpu/drm/i915/gvt/scheduler.c  |  3 ---
>  4 files changed, 18 insertions(+), 5 deletions(-)
> 
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Support for Guc responses and requests (rev4)
URL   : https://patchwork.freedesktop.org/series/28393/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/guc: Add documentation for MMIO based communication
Okay!

Commit: drm/i915/guc: Add support for data reporting in GuC responses
Okay!

Commit: drm/i915/guc: Prepare send() function to accept bigger response
Okay!

Commit: drm/i915/guc: Implement response handling in send_mmio()
Okay!

Commit: drm/i915/guc: Make event handler a virtual function
Okay!

Commit: drm/i915/guc: Prepare to handle messages from CT RECV buffer
Okay!

Commit: drm/i915/guc: Use better name for helper wait function
Okay!

Commit: drm/i915/guc: Implement response handling in send_ct()
Okay!

Commit: drm/i915/guc: Prepare to process incoming requests from CT
Okay!

Commit: drm/i915/guc: Handle default action received over CT
Okay!

Commit: drm/i915/guc: Trace messages from CT while in debug
+Error in reading or end of file.

Commit: HAX: Enable GuC for CI
Okay!

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Quoting Mika Kuoppala (2018-03-27 13:18:06)
> Chris Wilson  writes:
> 
> > Quoting Mika Kuoppala (2018-03-27 12:34:31)
> >> Chris Wilson  writes:
> >> 
> >> > If the request is still waiting on external fences, it has not yet been
> >> > submitted to the HW queue and so we can forgo kicking the submission
> >> > tasklet when re-evaluating its priority.
> >> >
> >> > This should have no impact other than reducing the number of tasklet
> >> > wakeups under signal heavy workloads (e.g. switching between engines).
> >> >
> >> > v2: Use prebaked container_of()
> >> >
> >> > References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between 
> >> > submission ports")
> >> > Signed-off-by: Chris Wilson 
> >> > Cc: Michał Winiarski 
> >> > Cc: Michel Thierry 
> >> > Cc: Mika Kuoppala 
> >> > Cc: Tvrtko Ursulin 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_lrc.c | 15 +++
> >> >  1 file changed, 11 insertions(+), 4 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >> > b/drivers/gpu/drm/i915/intel_lrc.c
> >> > index b4ab06b05e58..104b69e0494f 100644
> >> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> >> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >> > @@ -1051,12 +1051,16 @@ static void queue_request(struct intel_engine_cs 
> >> > *engine,
> >> >   list_add_tail(>link, _priolist(engine, pt, 
> >> > prio)->requests);
> >> >  }
> >> >  
> >> > -static void submit_queue(struct intel_engine_cs *engine, int prio)
> >> > +static void __submit_queue(struct intel_engine_cs *engine, int prio)
> >> >  {
> >> > - if (prio > engine->execlists.queue_priority) {
> >> >   engine->execlists.queue_priority = prio;
> >> >   tasklet_hi_schedule(>execlists.tasklet);
> >> > - }
> >> > +}
> >> > +
> >> > +static void submit_queue(struct intel_engine_cs *engine, int prio)
> >> > +{
> >> > + if (prio > engine->execlists.queue_priority)
> >> > + __submit_queue(engine, prio);
> >> 
> >> You did this...
> >> 
> >> >  }
> >> >  
> >> >  static void execlists_submit_request(struct i915_request *request)
> >> > @@ -1189,7 +1193,10 @@ static void execlists_schedule(struct 
> >> > i915_request *request, int prio)
> >> >   __list_del_entry(>link);
> >> >   queue_request(engine, pt, prio);
> >> >   }
> >> > - submit_queue(engine, prio);
> >> > +
> >> > + if (prio > engine->execlists.queue_priority &&
> >> > + i915_sw_fence_done(_to_request(pt)->submit))
> >> > + __submit_queue(engine, prio);
> >> 
> >> ..to have explicit priority comparison on submit callsite I gather.
> >> Or is there some other reason?
> >
> > No, just because I wanted both checks in this case. On the other path
> > i915_sw_fence_done() isn't technically true as we are in process of
> > performing the i915_sw_fence callback, so just i915_sw_fence_signaled().
> > But we don't want to use i915_sw_fence_signaled() here as I don't want
> > to think about the race. :)
> >
> > So since prio > engine.queue_priority should be cheaper than loading the
> > cacheline for the request->submit.flags, I wanted that tested first as
> > it will only fire, at most, once per engine.
> 
> Ok, didn't see the perf angle of it but makes sense.
> 
> Reviewed-by: Mika Kuoppala 

Fixed up the double indent and pushed. Thanks for the review, and
digging into i915_sw_fence :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[kbuild test robot]

Hi Matt,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.16-rc7 next-20180326]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/matthew-s-atwood-intel-com/drm-dp-Correctly-mask-DP_TRAINING_AUX_RD_INTERVAL-values-for-DP-1-4/20180324-035824
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-federa-25 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/include/dpcd_defs.h:29:0,
from 
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:42:
>> include/drm/drm_dp_helper.h:67:45: error: expected identifier before numeric 
>> constant
# define DPCD_REV_100x10
^
   drivers/gpu/drm/amd/amdgpu/../display/include/dpcd_defs.h:32:2: note: in 
expansion of macro 'DPCD_REV_10'
 DPCD_REV_10 = 0x10,
 ^~~
--
   In file included from 
drivers/gpu//drm/amd/amdgpu/../display/include/dpcd_defs.h:29:0,
from 
drivers/gpu//drm/amd/amdgpu/../display/dc/core/dc_link.c:42:
>> include/drm/drm_dp_helper.h:67:45: error: expected identifier before numeric 
>> constant
# define DPCD_REV_100x10
^
   drivers/gpu//drm/amd/amdgpu/../display/include/dpcd_defs.h:32:2: note: in 
expansion of macro 'DPCD_REV_10'
 DPCD_REV_10 = 0x10,
 ^~~

vim +67 include/drm/drm_dp_helper.h

63  
64  /* AUX CH addresses */
65  /* DPCD */
66  #define DP_DPCD_REV 0x000
  > 67  # define DPCD_REV_100x10
68  # define DPCD_REV_110x11
69  # define DPCD_REV_120x12
70  # define DPCD_REV_130x13
71  # define DPCD_REV_140x14
72  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
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 [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling (rev2)

[Patchwork]

== Series Details ==

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

== Summary ==

Series 40665v2 series starting with [01/11] drm/i915/execlists: Avoid kicking 
the submission too early for rescheduling
https://patchwork.freedesktop.org/api/1.0/series/40665/revisions/2/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (fi-skl-6770hq) fdo#100368

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:542s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:512s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:525s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:512s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:412s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:511s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:579s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:323s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:410s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:477s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:437s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:670s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:532s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:432s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:594s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:404s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:534s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:485s

fc022080c6c72a9b96fe1b730066c182bed98ac5 drm-tip: 2018y-03m-27d-11h-15m-40s UTC 
integration manifest
3d4caa26d478 drm/i915: Allow user control over preempt timeout on the important 
context
e411e7437e76 drm/i915: Use a preemption timeout to enforce interactivity
1521bc101f62 drm/i915/preemption: Select timeout when scheduling
ca960a24beab drm/i915/execlists: Force preemption via reset on timeout
803a762fcd5a drm/i915/execlists: Flush pending preemption events during reset
a891524a59ea drm/i915: Split execlists/guc reset prepartions
e422869adae2 drm/i915: Move engine reset prepare/finish to backends
4a804e342975 drm/i915/execlists: Refactor out complete_preempt_context()
faa8da6b86be drm/i915/execlists: Avoid kicking the submission too early for 
rescheduling

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8503/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Patchwork]

== Series Details ==

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

== Summary ==

$ dim checkpatch origin/drm-tip
faa8da6b86be drm/i915/execlists: Avoid kicking the submission too early for 
rescheduling
-:19: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#19: 
References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between 
submission ports")

-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit f6322eddaff7 
("drm/i915/preemption: Allow preemption between submission ports")'
#19: 
References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between 
submission ports")

total: 1 errors, 1 warnings, 0 checks, 30 lines checked
4a804e342975 drm/i915/execlists: Refactor out complete_preempt_context()
e422869adae2 drm/i915: Move engine reset prepare/finish to backends
a891524a59ea drm/i915: Split execlists/guc reset prepartions
803a762fcd5a drm/i915/execlists: Flush pending preemption events during reset
-:69: WARNING:LONG_LINE: line over 100 characters
#69: FILE: drivers/gpu/drm/i915/intel_lrc.c:892:
+   (i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));

-:87: WARNING:LONG_LINE: line over 100 characters
#87: FILE: drivers/gpu/drm/i915/intel_lrc.c:906:
+   head = readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));

-:104: WARNING:LONG_LINE: line over 100 characters
#104: FILE: drivers/gpu/drm/i915/intel_lrc.c:920:
+ head, GEN8_CSB_READ_PTR(readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",

-:105: WARNING:LONG_LINE: line over 100 characters
#105: FILE: drivers/gpu/drm/i915/intel_lrc.c:921:
+ tail, GEN8_CSB_WRITE_PTR(readl(i915->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");

total: 0 errors, 4 warnings, 0 checks, 192 lines checked
ca960a24beab drm/i915/execlists: Force preemption via reset on timeout
1521bc101f62 drm/i915/preemption: Select timeout when scheduling
e411e7437e76 drm/i915: Use a preemption timeout to enforce interactivity
3d4caa26d478 drm/i915: Allow user control over preempt timeout on the important 
context

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Patchwork]

== Series Details ==

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

== Summary ==

Series 40731v1 Restore "ALSA: hda: Make use of core codec functions to sync 
power state"
https://patchwork.freedesktop.org/api/1.0/series/40731/revisions/1/mbox/

 Possible new issues:

Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> FAIL   (fi-bdw-5557u)
pass   -> FAIL   (fi-hsw-4770)
Subgroup basic-rte:
pass   -> FAIL   (fi-bdw-5557u)
pass   -> FAIL   (fi-hsw-4770)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (fi-skl-6770hq) fdo#100368

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

fi-bdw-5557u total:285  pass:262  dwarn:0   dfail:0   fail:2   skip:21  
time:457s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:446s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:537s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:512s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:521s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:524s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:510s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:583s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:426s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:322s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-hsw-4770  total:285  pass:256  dwarn:0   dfail:0   fail:2   skip:27  
time:425s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:424s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:470s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:662s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:543s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:510s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:432s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:450s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:588s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:539s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:487s

fc022080c6c72a9b96fe1b730066c182bed98ac5 drm-tip: 2018y-03m-27d-11h-15m-40s UTC 
integration manifest
d925f55eae55 Restore "ALSA: hda: Make use of core codec functions to sync power 
state"

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8502/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Mika Kuoppala]

Chris Wilson  writes:

> Quoting Mika Kuoppala (2018-03-27 12:34:31)
>> Chris Wilson  writes:
>> 
>> > If the request is still waiting on external fences, it has not yet been
>> > submitted to the HW queue and so we can forgo kicking the submission
>> > tasklet when re-evaluating its priority.
>> >
>> > This should have no impact other than reducing the number of tasklet
>> > wakeups under signal heavy workloads (e.g. switching between engines).
>> >
>> > v2: Use prebaked container_of()
>> >
>> > References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between 
>> > submission ports")
>> > Signed-off-by: Chris Wilson 
>> > Cc: Michał Winiarski 
>> > Cc: Michel Thierry 
>> > Cc: Mika Kuoppala 
>> > Cc: Tvrtko Ursulin 
>> > ---
>> >  drivers/gpu/drm/i915/intel_lrc.c | 15 +++
>> >  1 file changed, 11 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
>> > b/drivers/gpu/drm/i915/intel_lrc.c
>> > index b4ab06b05e58..104b69e0494f 100644
>> > --- a/drivers/gpu/drm/i915/intel_lrc.c
>> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> > @@ -1051,12 +1051,16 @@ static void queue_request(struct intel_engine_cs 
>> > *engine,
>> >   list_add_tail(>link, _priolist(engine, pt, 
>> > prio)->requests);
>> >  }
>> >  
>> > -static void submit_queue(struct intel_engine_cs *engine, int prio)
>> > +static void __submit_queue(struct intel_engine_cs *engine, int prio)
>> >  {
>> > - if (prio > engine->execlists.queue_priority) {
>> >   engine->execlists.queue_priority = prio;
>> >   tasklet_hi_schedule(>execlists.tasklet);
>> > - }
>> > +}
>> > +
>> > +static void submit_queue(struct intel_engine_cs *engine, int prio)
>> > +{
>> > + if (prio > engine->execlists.queue_priority)
>> > + __submit_queue(engine, prio);
>> 
>> You did this...
>> 
>> >  }
>> >  
>> >  static void execlists_submit_request(struct i915_request *request)
>> > @@ -1189,7 +1193,10 @@ static void execlists_schedule(struct i915_request 
>> > *request, int prio)
>> >   __list_del_entry(>link);
>> >   queue_request(engine, pt, prio);
>> >   }
>> > - submit_queue(engine, prio);
>> > +
>> > + if (prio > engine->execlists.queue_priority &&
>> > + i915_sw_fence_done(_to_request(pt)->submit))
>> > + __submit_queue(engine, prio);
>> 
>> ..to have explicit priority comparison on submit callsite I gather.
>> Or is there some other reason?
>
> No, just because I wanted both checks in this case. On the other path
> i915_sw_fence_done() isn't technically true as we are in process of
> performing the i915_sw_fence callback, so just i915_sw_fence_signaled().
> But we don't want to use i915_sw_fence_signaled() here as I don't want
> to think about the race. :)
>
> So since prio > engine.queue_priority should be cheaper than loading the
> cacheline for the request->submit.flags, I wanted that tested first as
> it will only fire, at most, once per engine.

Ok, didn't see the perf angle of it but makes sense.

Reviewed-by: Mika Kuoppala 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michal Wajdeczko]

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

v2: fix timeout and checkpatch warnings (Michal)
v3: fix checkpatch again (Michel)
update wait function name (Michal)
no need for spinlock_irqsave (MichalWi)
no magic numbers (MichalWi)
must check before use (Jani)
add some more documentation (Michal)
v4: update documentation (Michal)

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Michel Thierry  #2.5
Cc: Michal Winiarski 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_guc_ct.c   | 142 ++
 drivers/gpu/drm/i915/intel_guc_ct.h   |   6 ++
 drivers/gpu/drm/i915/intel_guc_fwif.h |  52 +
 3 files changed, 186 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 2d805a2..41b071c 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -24,6 +24,14 @@
 #include "i915_drv.h"
 #include "intel_guc_ct.h"
 
+struct ct_request {
+   struct list_head link;
+   u32 fence;
+   u32 status;
+   u32 response_len;
+   u32 *response_buf;
+};
+
 enum { CTB_SEND = 0, CTB_RECV = 1 };
 
 enum { CTB_OWNER_HOST = 0 };
@@ -36,6 +44,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
 {
/* we're using static channel owners */
ct->host_channel.owner = CTB_OWNER_HOST;
+
+   spin_lock_init(>lock);
+   INIT_LIST_HEAD(>pending_requests);
 }
 
 static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
@@ -294,7 +305,8 @@ static u32 ctch_get_next_fence(struct intel_guc_ct_channel 
*ctch)
 static int ctb_write(struct intel_guc_ct_buffer *ctb,
 const u32 *action,
 u32 len /* in dwords */,
-u32 fence)
+u32 fence,
+bool want_response)
 {
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head / 4;  /* in dwords */
@@ -331,6 +343,7 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
 */
header = (len << GUC_CT_MSG_LEN_SHIFT) |
 (GUC_CT_MSG_WRITE_FENCE_TO_DESC) |
+(want_response ? GUC_CT_MSG_SEND_STATUS : 0) |
 (action[0] << GUC_CT_MSG_ACTION_SHIFT);
 
cmds[tail] = header;
@@ -401,36 +414,108 @@ static int wait_for_ctb_desc_update(struct 
guc_ct_buffer_desc *desc,
return err;
 }
 
-static int ctch_send(struct intel_guc *guc,
+/**
+ * wait_for_ct_request_update - Wait for CT request state update.
+ * @req:   pointer to pending request
+ * @status:placeholder for status
+ *
+ * For each sent request, Guc shall send bac CT response message.
+ * Our message handler will update status of tracked request once
+ * response message with given fence is received. Wait here and
+ * check for valid response status value.
+ *
+ * Return:
+ * *   0 response received (status is valid)
+ * *   -ETIMEDOUT no response within hardcoded timeout
+ */
+static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
+{
+   int err;
+
+   /*
+* Fast commands should complete in less than 10us, so sample quickly
+* up to that length of time, then switch to a slower sleep-wait loop.
+* No GuC command should ever take longer than 10ms.
+*/
+#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
+   err = wait_for_us(done, 10);
+   if (err)
+   err = wait_for(done, 10);
+#undef done
+
+   if (unlikely(err))
+   DRM_ERROR("CT: fence %u err %d\n", req->fence, err);
+
+   *status = req->status;
+   return err;
+}
+
+static int ctch_send(struct intel_guc_ct *ct,
 struct intel_guc_ct_channel *ctch,
 const u32 *action,
 u32 len,
+u32 *response_buf,
+u32 response_buf_size,
 u32 *status)
 {
struct intel_guc_ct_buffer *ctb = >ctbs[CTB_SEND];
struct guc_ct_buffer_desc *desc = ctb->desc;
+   struct ct_request request;
+   unsigned long flags;
u32 fence;
int err;
 
GEM_BUG_ON(!ctch_is_open(ctch));
GEM_BUG_ON(!len);
GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
+   GEM_BUG_ON(!response_buf && response_buf_size);
 
fence = ctch_get_next_fence(ctch);
-   err = ctb_write(ctb, action, len, fence);
+   request.fence = fence;
+   

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

[Patchwork]

== Series Details ==

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

== Summary ==

$ dim checkpatch origin/drm-tip
d925f55eae55 Restore "ALSA: hda: Make use of core codec functions to sync power 
state"
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 3b5b899ca67d ("ALSA: hda: Make 
use of core codec functions to sync power state")'
#8: 
re-enabling commit 3b5b899ca67db07a4c4825911072221f99e157e2.

-:68: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#68: FILE: sound/pci/hda/hda_local.h:625:
 }
+static inline bool snd_hda_sync_power_state(struct hda_codec *codec,

-:69: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#69: FILE: sound/pci/hda/hda_local.h:626:
+static inline bool snd_hda_sync_power_state(struct hda_codec *codec,
+  hda_nid_t nid, unsigned int target_state)

-:75: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)

total: 2 errors, 0 warnings, 2 checks, 52 lines checked

___
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: Check all requests have been retired on switching to kernel context

[Patchwork]

== Series Details ==

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

== Summary ==

Series 40730v1 drm/i915: Check all requests have been retired on switching to 
kernel context
https://patchwork.freedesktop.org/api/1.0/series/40730/revisions/1/mbox/

 Known issues:

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (fi-skl-6770hq) fdo#100368
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-bxt-dsi) fdo#103927

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:447s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:544s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:300s
fi-bxt-dsi   total:243  pass:216  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:512s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:525s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:513s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:588s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:326s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:472s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:658s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:506s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:427s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:585s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:536s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:491s

fc022080c6c72a9b96fe1b730066c182bed98ac5 drm-tip: 2018y-03m-27d-11h-15m-40s UTC 
integration manifest
84242a8ea607 drm/i915: Check all requests have been retired on switching to 
kernel context

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8501/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Rogovin, Kevin]

Hi,

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

Some comments on just a few of the comments (with massive snipping):

>> +Access. For having the GPU "do work", user space will feed the GPU 
>> +batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2` 
>> +or `DRM_IOCTL_I915_GEM_EXECBUFFER2_WR` (the ioctl 
>> +`DRM_IOCTL_I915_GEM_EXECBUFFER`

>It is actually the same ioctl from i915 point of view. It used to be read-only 
>(from the i915 point of view) and when fences were added
> (AFAIR) it needed to be made writable as well.

What would be better: to call out the individual IOCTL values 
(DRM_IOCTL_I915_GEM_) or the pre-ioctl values (DRM_I915_) for the purpose
of documentation? In truth the legacy DRM_I915 _GEM_EXECBUFFER implementation 
is really just a wrapper over the DRM_I915 _GEM_EXECBUFFER2
implementation. Any advice is appreciated.

>>* Motivation:
>>* GEN8 brings an expansion of the HW contexts: "Logical Ring Contexts".
>>* These expanded contexts enable a number of new abilities, 
>> especially
>> - * "Execlists" (also implemented in this file).
>> + * "Execlists" (also implemented in this file,
>> + * drivers/gpu/drm/i915/intel_lrc.c).

> Why is self-reference to filename required?

The document gets included in the html (or pdf) made with make htmldocs (resp. 
pdfdocs) and I'd like for the documentation
made to also act as a way for new developers to quickly know what file mainly 
does what (indeed this is something I am myself
still working on).

-Kevin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx