[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move hsw GT w/a to engine initialisation

[Patchwork]

== Series Details ==

Series: drm/i915: Move hsw GT w/a to engine initialisation
URL   : https://patchwork.freedesktop.org/series/33095/
State : failure

== Summary ==

Series 33095v1 drm/i915: Move hsw GT w/a to engine initialisation
https://patchwork.freedesktop.org/api/1.0/series/33095/revisions/1/mbox/

Test chamelium:
Subgroup dp-hpd-fast:
skip   -> INCOMPLETE (fi-bdw-5557u)
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Test gem_exec_reloc:
Subgroup basic-cpu-read-active:
pass   -> FAIL   (fi-gdg-551) fdo#102582

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

fi-bdw-5557u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:377s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:543s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:510s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:503s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:505s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:491s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:690s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-gdg-551   total:289  pass:177  dwarn:1   dfail:0   fail:2   skip:109 
time:269s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:579s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:427s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:481s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:575s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:582s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:580s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:599s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:652s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:523s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:573s

2faf7577f4edf6e233c89b3b217440bcb87b651f drm-tip: 2017y-11m-02d-15h-33m-01s UTC 
integration manifest
002aa0c059a5 drm/i915: Move hsw GT w/a to engine initialisation

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: set minimum CD clock to twice the BCLK.

[Prusty, Subhransu S]

> 
> On 10/30/2017 5:21 PM, Pandiyan, Dhinakaran wrote:
> > On Sun, 2017-10-29 at 03:04 +, Kumar, Abhay wrote:
> >> + Subhransu
> >>
> >> -Original Message-
> >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf 
> >> Of
> Kumar, Abhay
> >> Sent: Thursday, October 26, 2017 12:10 PM
> >> To: Jani Nikula ; Dhinakaran Pandiyan
> ; subransu.s.pru...@intel.com
> >> Cc: intel-gfx@lists.freedesktop.org; Nujella, Sathyanarayana
> 
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915: set minimum CD clock to twice 
> >> the
> BCLK.
> >>
> >>
> >>
> >> On 10/26/2017 1:45 AM, Jani Nikula wrote:
> >>> On Wed, 25 Oct 2017, Dhinakaran Pandiyan
>  wrote:
>  On Wednesday, October 25, 2017 3:02:12 PM PDT abhay.ku...@intel.com
> wrote:
> > From: Abhay Kumar 
> >
> > In glk when device boots with only 1366x768 panel, HDA codec doesn't
> comeup.
> > This result in no audio forever as cdclk is < 96Mhz.
> >>> Forever... or until next modeset with audio enabled?
> >> Soundcard probing/detection and creation happens only during bootup.  So
> even though we do modeset later there is no soundcard driver to handle the
> event.
> > This chagne will ensure CD clock to be twice of  BCLK.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937
> > Signed-off-by: Abhay Kumar 
> > ---
> >drivers/gpu/drm/i915/intel_cdclk.c | 2 +-
> >1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> > b/drivers/gpu/drm/i915/intel_cdclk.c index
> > e8884c2ade98..185a70f0921c
> > 100644
> > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > @@ -1920,7 +1920,7 @@ int intel_crtc_compute_min_cdclk(const struct
> > intel_crtc_state *crtc_state) /* According to BSpec, "The CD clock
> > frequency must be at least twice * the frequency of the Azalia
> > BCLK." and BCLK is 96 MHz by default. */
> > -   if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
> > +   if (INTEL_GEN(dev_priv) >= 9)
>  Why should cdclk be increased when audio is not being enabled?
> >>> Indeed. I can easily imagine a counter-bug reporting excessive cdclk
> >>> when audio is not enabled.
> >> During bootup time audio driver is trying to acquire HDA audio power well
> inside i915 and then it will send HDA verb commands.
> >> since cdclk is lower than 96Mhz  HDA will not comeup resulting in timeout.
> This was working fine  before SKL/APL since there was no 2 PPC .
> >>
> >> Is it ok to bump  up cdclk while bootup of system/HDA and then reduce to
> needed CDCLK?
> > I think it is worth exploring, do you have code to test whether it
> > solves this particular issue?
> No i don't have test code for this but what i learned from other OS that
> glk run at 148000 and cnl 96000*2 due to this limitation all the time.
> 
> @Shubhransu : can you please answer this doubt which we all have. This
> we should be able to get from HDA specs.

This clock setting is specific to idisp codec and HDA spec may not have details 
on this.
Yes we can test the changes with skylake audio driver. I believe Sathya has 
already
tested with the changes.

Regards,
Subhransu

> 
> >
> >> wondering if this approach can cause any issue to subsequent HDA verb
> commands ..
> >>
> >>
> >>> BR,
> >>> Jani.
> >>>
> > min_cdclk = max(2 * 96000, min_cdclk);
> >
> > if (min_cdclk > dev_priv->max_cdclk_freq) {
>  ___
>  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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: set minimum CD clock to twice the BCLK.

[Prusty, Subhransu S]

> >> b/drivers/gpu/drm/i915/intel_cdclk.c index
> >> e8884c2ade98..185a70f0921c
> >> 100644
> >> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> >> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> >> @@ -1920,7 +1920,7 @@ int intel_crtc_compute_min_cdclk(const struct
> >> intel_crtc_state *crtc_state) /* According to BSpec, "The CD clock
> >> frequency must be at least twice * the frequency of the Azalia
> >> BCLK." and BCLK is 96 MHz by default. */
> >> -  if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
> >> +  if (INTEL_GEN(dev_priv) >= 9)
> > Why should cdclk be increased when audio is not being enabled?
>  Indeed. I can easily imagine a counter-bug reporting excessive cdclk
>  when audio is not enabled.
> >>> During bootup time audio driver is trying to acquire HDA audio power well
> inside i915 and then it will send HDA verb commands.
> >>> since cdclk is lower than 96Mhz  HDA will not comeup resulting in timeout.
> This was working fine  before SKL/APL since there was no 2 PPC .
> >>>
> >>> Is it ok to bump  up cdclk while bootup of system/HDA and then reduce to
> needed CDCLK?
> >> I think it is worth exploring, do you have code to test whether it
> >> solves this particular issue?
> > No i don't have test code for this but what i learned from other OS that
> > glk run at 148000 and cnl 96000*2 due to this limitation all the time.
> 
> Is there an HSD for this? It's a bit surprising you can't even probe the
> driver without a higher cdclk.

Hi Jani,

The driver probe happens based on vendor id and revision id read from the 
codec, and
the vendor/revision are read from the codec over HDA bus. 

Since codecs are enumerable, without successful match of vendor/revision id  
the driver
probe will not happen.

Regards,
Subhransu

> 
> BR,
> Jani.
> 
> >
> > @Shubhransu : can you please answer this doubt which we all have. This
> > we should be able to get from HDA specs.
> >
> >>
> >>> wondering if this approach can cause any issue to subsequent HDA verb
> commands ..
> >>>
> >>>
>  BR,
>  Jani.
> 
> >>min_cdclk = max(2 * 96000, min_cdclk);
> >>
> >>if (min_cdclk > dev_priv->max_cdclk_freq) {
> > ___
> > 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
> >
> 
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Move hsw GT w/a to engine initialisation

[Chris Wilson]

In commit b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to
avoid it clobbering watermarks") init_clock_gating was called earlier in
the module load sequence, moving it before we acquired the forcewake
used to initialise the engines. This revealed that on Haswell, at least,
some of those GT w/as had been moved into the power context, and so as
we were now setting them outside of the power context, those settings
were being lost. Now, strictly we want to set power context registers
using LRI (that ensures there is a power context loaded!), we can
restore the earlier behaviour by moving the GT register writes back to
the same point in the module initialisation sequence.

Reported-by: Mark Janes 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549
Fixes: b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it 
clobbering watermarks")
Signed-off-by: Chris Wilson 
Cc: Mark Janes 
Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Cc: Oscar Mateo 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_pm.c | 38 --
 drivers/gpu/drm/i915/intel_ringbuffer.c | 41 +
 2 files changed, 41 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 308439dd89d4..8a72526d491e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8588,49 +8588,11 @@ static void hsw_init_clock_gating(struct 
drm_i915_private *dev_priv)
 {
ilk_init_lp_watermarks(dev_priv);
 
-   /* L3 caching of data atomics doesn't work -- disable it. */
-   I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
-   I915_WRITE(HSW_ROW_CHICKEN3,
-  
_MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE));
-
/* This is required by WaCatErrorRejectionIssue:hsw */
I915_WRITE(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG,
I915_READ(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG) |
GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB);
 
-   /* WaVSRefCountFullforceMissDisable:hsw */
-   I915_WRITE(GEN7_FF_THREAD_MODE,
-  I915_READ(GEN7_FF_THREAD_MODE) & ~GEN7_FF_VS_REF_CNT_FFME);
-
-   /* WaDisable_RenderCache_OperationalFlush:hsw */
-   I915_WRITE(CACHE_MODE_0_GEN7, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
-
-   /* enable HiZ Raw Stall Optimization */
-   I915_WRITE(CACHE_MODE_0_GEN7,
-  _MASKED_BIT_DISABLE(HIZ_RAW_STALL_OPT_DISABLE));
-
-   /* WaDisable4x2SubspanOptimization:hsw */
-   I915_WRITE(CACHE_MODE_1,
-  _MASKED_BIT_ENABLE(PIXEL_SUBSPAN_COLLECT_OPT_DISABLE));
-
-   /*
-* BSpec recommends 8x4 when MSAA is used,
-* however in practice 16x4 seems fastest.
-*
-* Note that PS/WM thread counts depend on the WIZ hashing
-* disable bit, which we don't touch here, but it's good
-* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
-*/
-   I915_WRITE(GEN7_GT_MODE,
-  _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
-
-   /* WaSampleCChickenBitEnable:hsw */
-   I915_WRITE(HALF_SLICE_CHICKEN3,
-  _MASKED_BIT_ENABLE(HSW_SAMPLE_C_PERFORMANCE));
-
-   /* WaSwitchSolVfFArbitrationPriority:hsw */
-   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
-
/* WaRsPkgCStateDisplayPMReq:hsw */
I915_WRITE(CHICKEN_PAR1_1,
   I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3321b801e77d..3a2287b0d9f4 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -707,6 +707,47 @@ static int init_render_ring(struct intel_engine_cs *engine)
if (IS_GEN(dev_priv, 6, 7))
I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
 
+
+   if (IS_HASWELL(dev_priv)) {
+   /* L3 caching of data atomics doesn't work -- disable it. */
+   I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
+   I915_WRITE(HSW_ROW_CHICKEN3,
+  
_MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE));
+
+   /* WaVSRefCountFullforceMissDisable:hsw */
+   I915_WRITE(GEN7_FF_THREAD_MODE,
+  I915_READ(GEN7_FF_THREAD_MODE) & 
~GEN7_FF_VS_REF_CNT_FFME);
+
+   /* WaDisable_RenderCache_OperationalFlush:hsw */
+   I915_WRITE(CACHE_MODE_0_GEN7, 
_MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
+
+   /* enable HiZ Raw Stall Optimization */
+   I915_WRITE(CACHE_MODE_0_GEN7,
+  _MASKED_BIT_DISABLE(HIZ_RAW_STALL_OPT_DISABLE));
+
+   /* WaDisable4x2SubspanOptimization:hsw */
+   I915_WRITE(CACHE_MODE_1,
+

Re: [Intel-gfx] [PATCH 05/20] drm/i915: Save all GT WAs and apply them at a later time

[Chris Wilson]

Quoting Joonas Lahtinen (2017-10-31 14:14:52)
> On Mon, 2017-10-30 at 13:17 -0700, Oscar Mateo wrote:
> > By doing this, we can dump these workarounds in debugfs for validation 
> > (which,
> > at the moment, we are only able to do for the contexts WAs).
> > 
> > v2:
> >   - Wrong macro used for MMIO set bit masked
> >   - Improved naming
> >   - Rebased
> > 
> > v3:
> >   - GT instead of MMIO (Chris, Mika)
> >   - Leave L3_PRIO_CREDITS_MASK for a separate patch
> >   - Rebased
> > 
> > v4: Carry the init_early nomenclature over (Chris)
> > 
> > Signed-off-by: Oscar Mateo 
> > Cc: Mika Kuoppala 
> > Cc: Ville Syrjälä 
> > Reviewed-by: Chris Wilson 
> 
> This and the following patch are still a no-go and won't be merged. The
> required changes for the series to be accepted (to make it more
> declarative) were clearly described previously. If there are further
> questions, we should discuss those instead wasting time looking at
> respins that do not address the input given.

I would like draw everyone's attention to

https://bugs.freedesktop.org/show_bug.cgi?id=103549

As much as I don't like gem_workarounds for its incestrous relationship
with the kernel it purports to be testing, that bug is exactly the type
of regression it prevents. It could not find this regression because it
requires us to be very formal in our w/a handling, i.e. we had not
declared the w/a for it to check; such formality being sought after here.

Whatever the design outcome, a good test plan is essential.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 2/5] drm/i915/guc : Removing i915_modparams.enable_guc_loading module

[Chris Wilson]

Quoting Rodrigo Vivi (2017-11-02 23:52:45)
> On Wed, Oct 4, 2017 at 6:07 AM, Joonas Lahtinen
>  wrote:
> > On Tue, 2017-10-03 at 15:56 -0700, Sujaritha Sundaresan wrote:
> >> We currently have two module parameters that control GuC: 
> >> "enable_guc_loading" and "enable_guc_submission".
> >> Whenever we need i915_modparams.enable_guc_submission=1, we also need 
> >> enable_guc_loading=1.
> >> We also need enable_guc_loading=1 when we want to verify the HuC,
> >> which is every time we have a HuC (but all platforms with HuC have a GuC 
> >> and viceversa).
> >
> > Long lines in commit message, please give a look at:
> >
> > https://www.kernel.org/doc/html/v4.13/process/submitting-patches.html
> >
> > Section "14) The canonical patch format".
> >
> > Then, about the patch. I think the commit message should be more clear
> > about the fact that if we have HuC firmware to be loaded, we need to
> > have GuC to actually load it. So if an user wants to avoid the GuC from
> > getting loaded, they must not have a HuC firmware to be loaded, in
> > addition to not using GuC submission.
> >
> >>
> >> v2: Clarifying the commit message (Anusha)
> >>
> >> v3: Unify seq_puts messages, Re-factoring code as per review (Michal)
> >>
> >> v4: Rebase
> >>
> >> v5: Separating message unification into a separate patch
> >>
> >> Cc: Michal Wajdeczko 
> >> Cc: Anusha Srivatsa 
> >> Cc: Oscar Mateo 
> >> Cc: Sagar Arun Kamble 
> >> Signed-off-by: Sujaritha Sundaresan 
> >
> > Try to keep the tags in chronological order, so start with Suggested-
> > by: (if any), Signed-off-by:, Cc: and so on.
> 
> Could we agree on have
> Suggested-by:
> Cc:
> Signed-off-by:
> as the initial chronological order and then follow the chronological

But CCs come after a s-o-b, because they are added after the commit. (I
write some code, then think who might be interested; usually by looking
at who previously worked on the same code). Then you also add new CCs
later on based on review feedback; a comment on v1 gets a CC on v2.
Bugzilla/reported-by/suggested-by are before since they presumably
prompted the commit to be written in the first place (plus also they
deserve extra credit for their effort in alerting us to the issue).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+

[Patchwork]

== Series Details ==

Series: drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+
URL   : https://patchwork.freedesktop.org/series/33087/
State : warning

== Summary ==

Series 33087v1 drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+
https://patchwork.freedesktop.org/api/1.0/series/33087/revisions/1/mbox/

Test gem_ctx_switch:
Subgroup basic-default-heavy:
pass   -> INCOMPLETE (fi-glk-dsi) fdo#103359
Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-kbl-7567u) fdo#102846

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:449s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:526s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:507s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:507s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:496s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:432s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:267s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:585s
fi-glk-dsi   total:32   pass:22   dwarn:0   dfail:0   fail:0   skip:9  
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:433s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:430s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:489s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:576s
fi-kbl-7567u total:245  pass:228  dwarn:0   dfail:0   fail:0   skip:16 
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:585s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:570s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:594s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:650s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:525s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-snb-2520m total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:568s
fi-cfl-s failed to connect after reboot

2faf7577f4edf6e233c89b3b217440bcb87b651f drm-tip: 2017y-11m-02d-15h-33m-01s UTC 
integration manifest
60b48de7835a drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+

== Logs ==

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

Re: [Intel-gfx] [PATCH v5 2/5] drm/i915/guc : Removing i915_modparams.enable_guc_loading module

[Rodrigo Vivi]

On Wed, Oct 4, 2017 at 6:07 AM, Joonas Lahtinen
 wrote:
> On Tue, 2017-10-03 at 15:56 -0700, Sujaritha Sundaresan wrote:
>> We currently have two module parameters that control GuC: 
>> "enable_guc_loading" and "enable_guc_submission".
>> Whenever we need i915_modparams.enable_guc_submission=1, we also need 
>> enable_guc_loading=1.
>> We also need enable_guc_loading=1 when we want to verify the HuC,
>> which is every time we have a HuC (but all platforms with HuC have a GuC and 
>> viceversa).
>
> Long lines in commit message, please give a look at:
>
> https://www.kernel.org/doc/html/v4.13/process/submitting-patches.html
>
> Section "14) The canonical patch format".
>
> Then, about the patch. I think the commit message should be more clear
> about the fact that if we have HuC firmware to be loaded, we need to
> have GuC to actually load it. So if an user wants to avoid the GuC from
> getting loaded, they must not have a HuC firmware to be loaded, in
> addition to not using GuC submission.
>
>>
>> v2: Clarifying the commit message (Anusha)
>>
>> v3: Unify seq_puts messages, Re-factoring code as per review (Michal)
>>
>> v4: Rebase
>>
>> v5: Separating message unification into a separate patch
>>
>> Cc: Michal Wajdeczko 
>> Cc: Anusha Srivatsa 
>> Cc: Oscar Mateo 
>> Cc: Sagar Arun Kamble 
>> Signed-off-by: Sujaritha Sundaresan 
>
> Try to keep the tags in chronological order, so start with Suggested-
> by: (if any), Signed-off-by:, Cc: and so on.

Could we agree on have
Suggested-by:
Cc:
Signed-off-by:
as the initial chronological order and then follow the chronological
after that as well?

Few reasons for that:
1. For my brain this is the regular chronological message flow:
someone suggested, you message some one and last thing you do before
sending the message is to sign-off.
2. git commit --amend -s adds it to the end.
3. Signed-off-by: at the end of the message was always our standard
and every patch that I see around in the kernel seems to prefer this
style
4. When I look to the first email and I see cc below the first thing
that I think is: "This developer forgot to sign-off his own patch!".

Thanks,
Rodrigo.

>
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Stop caching the "golden" renderstate

[Chris Wilson]

Quoting Rodrigo Vivi (2017-11-02 23:34:52)
> On Thu, Nov 02, 2017 at 10:36:26PM +, Oscar Mateo wrote:
> > 
> > 
> > On 11/02/2017 07:56 AM, Joonas Lahtinen wrote:
> > > On Thu, 2017-11-02 at 07:54 -0700, Rodrigo Vivi wrote:
> > > > On Thu, Nov 02, 2017 at 02:43:16PM +, Joonas Lahtinen wrote:
> > > > > On Thu, 2017-11-02 at 12:42 +, Chris Wilson wrote:
> > > > > > As we now record the default HW state and so only emit the "golden"
> > > > > > renderstate once to prepare the HW, there is no advantage in 
> > > > > > keeping the
> > > > > > renderstate batch around as it will never be used again.
> > > > So, with this in place we really don't need that null context for CNL.
> > > > to fullfill all Mesa needs, right?!
> > > Separate issue, this only fixes isolation. This patch just releases it
> > > from memory after it's been applied to the default context states to be
> > > stored.
> > > 
> > > But yes, we also decided not to have null context for new platforms.
> > 
> > At last until, two years from now, we find out that there is a very subtle
> > reason why we need it :)
> 
> :( - Yeap, for me just to be on the safe side and start with a clean context
> would be a good reason already...

That is not what golden renderstate does.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Stop caching the "golden" renderstate

[Rodrigo Vivi]

On Thu, Nov 02, 2017 at 10:36:26PM +, Oscar Mateo wrote:
> 
> 
> On 11/02/2017 07:56 AM, Joonas Lahtinen wrote:
> > On Thu, 2017-11-02 at 07:54 -0700, Rodrigo Vivi wrote:
> > > On Thu, Nov 02, 2017 at 02:43:16PM +, Joonas Lahtinen wrote:
> > > > On Thu, 2017-11-02 at 12:42 +, Chris Wilson wrote:
> > > > > As we now record the default HW state and so only emit the "golden"
> > > > > renderstate once to prepare the HW, there is no advantage in keeping 
> > > > > the
> > > > > renderstate batch around as it will never be used again.
> > > So, with this in place we really don't need that null context for CNL.
> > > to fullfill all Mesa needs, right?!
> > Separate issue, this only fixes isolation. This patch just releases it
> > from memory after it's been applied to the default context states to be
> > stored.
> > 
> > But yes, we also decided not to have null context for new platforms.
> 
> At last until, two years from now, we find out that there is a very subtle
> reason why we need it :)

:( - Yeap, for me just to be on the safe side and start with a clean context
would be a good reason already...

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

[Intel-gfx] [PATCH] drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+

[James Ausmus]

Since GLK, some plane configuration settings have moved to the
PLANE_COLOR_CTL register. Refactor handling of the register to work like
PLANE_CTL. This also allows us to fix the set/read of the plane Alpha
Mode for GLK+.

Signed-off-by: James Ausmus 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h  | 12 +---
 drivers/gpu/drm/i915/intel_display.c | 60 +---
 drivers/gpu/drm/i915/intel_drv.h |  5 +++
 drivers/gpu/drm/i915/intel_sprite.c  | 14 +
 4 files changed, 76 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 68a58cce6ab1..520ff9a15222 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6263,7 +6263,7 @@ enum {
 #define _PLANE_CTL_2_A 0x70280
 #define _PLANE_CTL_3_A 0x70380
 #define   PLANE_CTL_ENABLE (1 << 31)
-#define   PLANE_CTL_PIPE_GAMMA_ENABLE  (1 << 30)
+#define   PLANE_CTL_PIPE_GAMMA_ENABLE  (1 << 30)   /* Pre-GLK */
 #define   PLANE_CTL_FORMAT_MASK(0xf << 24)
 #define   PLANE_CTL_FORMAT_YUV422  (  0 << 24)
 #define   PLANE_CTL_FORMAT_NV12(  1 << 24)
@@ -6273,7 +6273,7 @@ enum {
 #define   PLANE_CTL_FORMAT_AYUV(  8 << 24)
 #define   PLANE_CTL_FORMAT_INDEXED ( 12 << 24)
 #define   PLANE_CTL_FORMAT_RGB_565 ( 14 << 24)
-#define   PLANE_CTL_PIPE_CSC_ENABLE(1 << 23)
+#define   PLANE_CTL_PIPE_CSC_ENABLE(1 << 23) /* Pre-GLK */
 #define   PLANE_CTL_KEY_ENABLE_MASK(0x3 << 21)
 #define   PLANE_CTL_KEY_ENABLE_SOURCE  (  1 << 21)
 #define   PLANE_CTL_KEY_ENABLE_DESTINATION (  2 << 21)
@@ -6286,13 +6286,13 @@ enum {
 #define   PLANE_CTL_YUV422_VYUY(  3 << 16)
 #define   PLANE_CTL_DECOMPRESSION_ENABLE   (1 << 15)
 #define   PLANE_CTL_TRICKLE_FEED_DISABLE   (1 << 14)
-#define   PLANE_CTL_PLANE_GAMMA_DISABLE(1 << 13)
+#define   PLANE_CTL_PLANE_GAMMA_DISABLE(1 << 13) /* Pre-GLK */
 #define   PLANE_CTL_TILED_MASK (0x7 << 10)
 #define   PLANE_CTL_TILED_LINEAR   (  0 << 10)
 #define   PLANE_CTL_TILED_X(  1 << 10)
 #define   PLANE_CTL_TILED_Y(  4 << 10)
 #define   PLANE_CTL_TILED_YF   (  5 << 10)
-#define   PLANE_CTL_ALPHA_MASK (0x3 << 4)
+#define   PLANE_CTL_ALPHA_MASK (0x3 << 4) /* Pre-GLK */
 #define   PLANE_CTL_ALPHA_DISABLE  (  0 << 4)
 #define   PLANE_CTL_ALPHA_SW_PREMULTIPLY   (  2 << 4)
 #define   PLANE_CTL_ALPHA_HW_PREMULTIPLY   (  3 << 4)
@@ -6332,6 +6332,10 @@ enum {
 #define   PLANE_COLOR_PIPE_GAMMA_ENABLE(1 << 30)
 #define   PLANE_COLOR_PIPE_CSC_ENABLE  (1 << 23)
 #define   PLANE_COLOR_PLANE_GAMMA_DISABLE  (1 << 13)
+#define   PLANE_COLOR_ALPHA_MASK   (0x3 << 4)
+#define   PLANE_COLOR_ALPHA_DISABLE(0 << 4)
+#define   PLANE_COLOR_ALPHA_SW_PREMULTIPLY (2 << 4)
+#define   PLANE_COLOR_ALPHA_HW_PREMULTIPLY (3 << 4)
 #define _PLANE_BUF_CFG_1_A 0x7027c
 #define _PLANE_BUF_CFG_2_A 0x7037c
 #define _PLANE_NV12_BUF_CFG_1_A0x70278
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e2ac976844d8..0883e857dda9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3466,6 +3466,29 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return 0;
 }
 
+static u32 glk_plane_ctl_format(uint32_t pixel_format)
+{
+   /* GLK+ moves the alpha mask to a different register */
+   return skl_plane_ctl_format(pixel_format) & ~PLANE_CTL_ALPHA_MASK;
+}
+
+static u32 glk_plane_color_ctl_alpha(uint32_t pixel_format)
+{
+   switch (pixel_format) {
+   /*
+* XXX: For ARBG/ABGR formats we default to expecting scanout buffers
+* to be already pre-multiplied. We need to add a knob (or a different
+* DRM_FORMAT) for user-space to configure that.
+*/
+   case DRM_FORMAT_ABGR:
+   return PLANE_COLOR_ALPHA_SW_PREMULTIPLY;
+   case DRM_FORMAT_ARGB:
+   return PLANE_COLOR_ALPHA_SW_PREMULTIPLY;
+   default:
+   return PLANE_COLOR_ALPHA_DISABLE;
+   }
+}
+
 static u32 skl_plane_ctl_tiling(uint64_t fb_modifier)
 {
switch (fb_modifier) {
@@ -3522,14 +3545,16 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
*crtc_state,
 
plane_ctl = PLANE_CTL_ENABLE;
 
-   if (!IS_GEMINILAKE(dev_priv) && !IS_CANNONLAKE(dev_priv)) {
+   if (!IS_GEMINILAKE(dev_priv) && !(INTEL_GEN(dev_priv) >= 10)) {
plane_ctl |=
PLANE_CTL_PIPE_GAMMA_ENABLE |
PLANE_CTL_PIPE_CSC_ENABLE |
   

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Stop caching the "golden" renderstate

[Oscar Mateo]

On 11/02/2017 07:56 AM, Joonas Lahtinen wrote:

On Thu, 2017-11-02 at 07:54 -0700, Rodrigo Vivi wrote:

On Thu, Nov 02, 2017 at 02:43:16PM +, Joonas Lahtinen wrote:

On Thu, 2017-11-02 at 12:42 +, Chris Wilson wrote:

As we now record the default HW state and so only emit the "golden"
renderstate once to prepare the HW, there is no advantage in keeping the
renderstate batch around as it will never be used again.

So, with this in place we really don't need that null context for CNL.
to fullfill all Mesa needs, right?!

Separate issue, this only fixes isolation. This patch just releases it
from memory after it's been applied to the default context states to be
stored.

But yes, we also decided not to have null context for new platforms.


At last until, two years from now, we find out that there is a very 
subtle reason why we need it :)



Regards, Joonas


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

[Intel-gfx] [i-g-t ] igt/kms_frontbuffer_tracking: Indefinite blocking with PSR HW tracking [Draft]

[Vyas, Tarun]

The patch https://patchwork.freedesktop.org/patch/166512/ which relies on HW 
tracking for frontbuffer flushes/invalidations leads to an indefinite block 
when running any of the *psr* subtests of the kms_frontbuffer_tracking test.

===Failure analysis===

Subtest: kms_frontbuffer_tracking --run-subtest psr-1p-rte

The test gets blocked (indefinitely) at the openat system call while trying to 
open "crtc-%d/crc/data" (crtc-0 in this  case). On the kernel side, the 
crtc_crc_open call waits in the crc wait queue until the 
display_pipe_crc_irq_handler wakes it up which never happens.
On the PSR side, the intel_psr_flush returns without the SW initiating psr_exit 
since we are relying on HW tracking.

So either the HW tracking is not working as expected (because pipe CRC 
generation is stuck) OR the test is not designed for HW tracking. Either way, 
it should not get blocked indefinitely. 

Can we have:
A timeout in this igt test. OR
Wait_event_interruptible_lock_irq_timeout instead of 
Wait_event_interruptible_lock_irq inside crtc_crc_open() OR
Skip the test if HW tracking is enabled.




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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log.

[Chris Wilson]

Quoting Anusha Srivatsa (2017-11-02 20:28:10)
> On Wed, Nov 01, 2017 at 01:24:15PM +, Chris Wilson wrote:
> > Quoting Michal Wajdeczko (2017-11-01 13:14:33)
> > > On Wed, 01 Nov 2017 01:11:20 +0100, Anusha Srivatsa  
> > > > @@ -172,13 +174,18 @@ static int guc_ucode_xfer_dma(struct  
> > > > drm_i915_private *dev_priv,
> > > >*/
> > > >   ret = wait_for(guc_ucode_response(dev_priv, &status), 100);
> > > > + load_time = ktime_ms_delta(ktime_get(), start_load);
> > > > +
> > > >   DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
> > > >   I915_READ(DMA_CTRL), status);
> > > >   if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
> > > >   DRM_ERROR("GuC firmware signature verification failed\n");
> > > >   ret = -ENOEXEC;
> > > > - }
> > > > + } else if (load_time > 20)
> > > > + DRM_NOTE("GuC load takes more than acceptable 
> > > > threshold\n");
> > > 
> > > Please add threshold and actual load time to the message to let user
> > > know that times
> > 
> > The more important question is why are we telling the user this at all;
> > a significant but normal condition. What do we expect them to do? It
> > doesn't impair any functionality of the driver, it just took longer than
> > you expected -- which may be simply because the system was doing
> > something else and we slept for longer.
> 
> Chris, I am inclining to have this info more for us than the user. It is more 
> of
> a debug print to give us some data. We can see if firmware takes peculiarly
> long time to load. We know its normal to be within 20ms range. So, alert
> if it takes longer than that...

Sure, but the impact is that this is a user facing message, even marked
as a significant message. We are quite capable of parsing debug
messages; even capable of setting up ftrace to extract this timing info
without adding the dmesg in the first place...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log.

[Anusha Srivatsa]

On Wed, Nov 01, 2017 at 01:24:15PM +, Chris Wilson wrote:
> Quoting Michal Wajdeczko (2017-11-01 13:14:33)
> > On Wed, 01 Nov 2017 01:11:20 +0100, Anusha Srivatsa  
> > > @@ -172,13 +174,18 @@ static int guc_ucode_xfer_dma(struct  
> > > drm_i915_private *dev_priv,
> > >*/
> > >   ret = wait_for(guc_ucode_response(dev_priv, &status), 100);
> > > + load_time = ktime_ms_delta(ktime_get(), start_load);
> > > +
> > >   DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
> > >   I915_READ(DMA_CTRL), status);
> > >   if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
> > >   DRM_ERROR("GuC firmware signature verification failed\n");
> > >   ret = -ENOEXEC;
> > > - }
> > > + } else if (load_time > 20)
> > > + DRM_NOTE("GuC load takes more than acceptable threshold\n");
> > 
> > Please add threshold and actual load time to the message to let user
> > know that times
> 
> The more important question is why are we telling the user this at all;
> a significant but normal condition. What do we expect them to do? It
> doesn't impair any functionality of the driver, it just took longer than
> you expected -- which may be simply because the system was doing
> something else and we slept for longer.

Chris, I am inclining to have this info more for us than the user. It is more of
a debug print to give us some data. We can see if firmware takes peculiarly
long time to load. We know its normal to be within 20ms range. So, alert
if it takes longer than that...

> -Chris

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for tests: add device information tests (rev2)

[Patchwork]

== Series Details ==

Series: tests: add device information tests (rev2)
URL   : https://patchwork.freedesktop.org/series/32764/
State : warning

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-B:
pass   -> DMESG-WARN (shard-hsw)

shard-hswtotal:2544 pass:1431 dwarn:3   dfail:0   fail:8   skip:1102 
time:9279s

== Logs ==

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

Re: [Intel-gfx] [PATCH v8 4/6] drm/i915/guc : Updating GuC and HuC firmware select function

[Sujaritha]

On 10/25/2017 08:56 AM, Michal Wajdeczko wrote:
On Tue, 24 Oct 2017 19:21:23 +0200, Sujaritha Sundaresan 
 wrote:



Updating GuC and HuC firmware select function to support removing
i915_modparams.enable_guc_loading module parameter.


Hmm, is it correct order of patches ? this modparam was already 
removed in 2/6


I will move this to be the third patch. Since the change to uc.c was 
separated from 2/6,

I had included that as 3/6.




v2: Clarifying the commit message (Anusha)

v3: Unify seq_puts messages, Re-factoring code as per review (Michal)

v4: Rebase

v5: Separating message unification into a separate patch

v6: Re-factoring code (Sagar, Michal)
    Rebase

v7: Separating from previuos patch (Sagar)
    Rebase

v8: Including change to intel_uc.c
    Applying review comments (Michal)

Signed-off-by: Sujaritha Sundaresan 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_guc_fw.c | 10 +++---
 drivers/gpu/drm/i915/intel_guc_fw.h |  2 +-
 drivers/gpu/drm/i915/intel_huc.c    |  3 ++-
 drivers/gpu/drm/i915/intel_uc.c |  6 ++
 4 files changed, 12 insertions(+), 9 deletions(-)

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

index ef67a36..b9f834f 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -60,10 +60,8 @@
  * intel_guc_fw_select() - selects GuC firmware for uploading
  *
  * @guc:    intel_guc struct
- *
- * Return: zero when we know firmware, non-zero in other case
  */
-int intel_guc_fw_select(struct intel_guc *guc)
+void intel_guc_fw_select(struct intel_guc *guc)
 {
 struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -90,11 +88,9 @@ int intel_guc_fw_select(struct intel_guc *guc)
 guc->fw.major_ver_wanted = GLK_FW_MAJOR;
 guc->fw.minor_ver_wanted = GLK_FW_MINOR;
 } else {
-    DRM_ERROR("No GuC firmware known for platform with GuC!\n");
-    return -ENOENT;
+    DRM_ERROR("No GuC FW known for platform with GuC!\n");
+    return;
 }
-
-    return 0;
 }
/*
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.h 
b/drivers/gpu/drm/i915/intel_guc_fw.h

index 023f5ba..7f6ccaf 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.h
+++ b/drivers/gpu/drm/i915/intel_guc_fw.h
@@ -27,7 +27,7 @@
struct intel_guc;
-int intel_guc_fw_select(struct intel_guc *guc);
+void intel_guc_fw_select(struct intel_guc *guc);
 int intel_guc_fw_upload(struct intel_guc *guc);
#endif
diff --git a/drivers/gpu/drm/i915/intel_huc.c 
b/drivers/gpu/drm/i915/intel_huc.c

index c8a48cb..4e700ab 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -108,7 +108,8 @@ void intel_huc_select_fw(struct intel_huc *huc)
 huc->fw.major_ver_wanted = GLK_HUC_FW_MAJOR;
 huc->fw.minor_ver_wanted = GLK_HUC_FW_MINOR;
 } else {
-    DRM_ERROR("No HuC firmware known for platform with HuC!\n");
+    if (HAS_GUC(dev_priv))
+    DRM_ERROR("No HuC FW known for platform with HuC!\n");
 return;
 }
 }
diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index 9369ade..dc978a0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -82,11 +82,17 @@ void intel_uc_sanitize_options(struct 
drm_i915_private *dev_priv)

void intel_uc_init_early(struct drm_i915_private *dev_priv)
 {
+    struct intel_guc *guc = &dev_priv->guc;
+    struct intel_huc *huc = &dev_priv->huc;


Please run checkpatch and add separation line here


Will do.



intel_guc_init_early(&dev_priv->guc);


You can now pass 'guc' as param


Will do.



+    intel_guc_fw_select(guc);
+    intel_huc_select_fw(huc);


To avoid redundant checks in select_fw() functions we can
exit earlier with


I will add the early exit condition.

Thanks for the review.


if (!HAS_GUC(dev_priv))
    return;


 }
void intel_uc_init_fw(struct drm_i915_private *dev_priv)
 {
+    if (!HAS_GUC(dev_priv))
+    return;
 intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
 intel_uc_fw_fetch(dev_priv, &dev_priv->guc.fw);
 }


Regards,
Sujaritha
___
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: Plane assert/readout cleanups etc. (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915: Plane assert/readout cleanups etc. (rev8)
URL   : https://patchwork.freedesktop.org/series/31758/
State : success

== Summary ==

Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_flip:
Subgroup vblank-vs-suspend:
pass   -> SKIP   (shard-hsw) fdo#103375
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw)
Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-WARN (shard-hsw) fdo#102707

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707

shard-hswtotal:2539 pass:1430 dwarn:2   dfail:0   fail:9   skip:1098 
time:9202s

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log.

[Anusha Srivatsa]

On Wed, Nov 01, 2017 at 02:14:33PM +0100, Michal Wajdeczko wrote:
> On Wed, 01 Nov 2017 01:11:20 +0100, Anusha Srivatsa
>  wrote:
> 
> >Calculate the time that GuC takes to load using
> >jiffies. This information could be very useful in
>   ^^^
> This is no longer true.

True. Will sending an all new patch with updated 
approach(using ktime instead of jiffies) be good?
Or stick to this with change in commit message?

> >determining if GuC is taking unreasonably long time
> >to load in a certain platforms.
> >
> >v2: Calculate time before logs are collected.
> >Move the guc_load_time variable as a part of
> >intel_uc_fw struct. Store only final result
> >which is to be exported to debugfs. (Michal)
> >Add the load time in the print message as well.
> >
> >v3: Remove debugfs entry. Remove local variable
> >guc_finish_load. (Daniel, Tvrtko)
> >
> >v4: Use ktime_get() instead of jiffies. Use DRM_NOTE
> >if time taken to load is more than the threshold. On
> >load times within acceptable range, use DRM_DEBUG_DRIVER
> >(Tvrtko)
> >
> >v5: Rebased. Do not expose the load time variable in a global
> >struct (Tvrtko, Joonas)
> >
> >Cc: Chris Wilson 
> >Cc: Daniel Vetter 
> >Cc: Michal Wajdeczko 
> >Cc: Oscar Mateo 
> >Cc: Sujaritha Sundaresan 
> >Cc: Tvrtko Ursulin 
> >Signed-off-by: Anusha Srivatsa 
> >---
> > drivers/gpu/drm/i915/intel_guc_fw.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
> >b/drivers/gpu/drm/i915/intel_guc_fw.c
> >index ef67a36..4ce9a30 100644
> >--- a/drivers/gpu/drm/i915/intel_guc_fw.c
> >+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
> >@@ -133,7 +133,8 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
> >*dev_priv,
> > unsigned long offset;
> > struct sg_table *sg = vma->pages;
> > u32 status, rsa[UOS_RSA_SCRATCH_MAX_COUNT];
> >-int i, ret = 0;
> >+int i, ret = 0, load_time;
> 
> Note that ktime_ms_delta() return type is s64 not int.
> 
> >+ktime_t start_load;
> 
> s/start_load/now ?

I think start_load is verbose. 
 
> > /* where RSA signature starts */
> > offset = guc_fw->rsa_offset;
> >@@ -160,6 +161,7 @@ static int guc_ucode_xfer_dma(struct drm_i915_private
> >*dev_priv,
> > I915_WRITE(DMA_ADDR_1_HIGH, DMA_ADDRESS_SPACE_WOPCM);
> > /* Finally start the DMA */
> >+start_load = ktime_get();
> 
> Maybe we should either update comment with note about taking start time
> or move ktime_get call before that comment to avoid confusion..

I prefer the latter.
 
> > I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(UOS_MOVE | START_DMA));
> > /*
> >@@ -172,13 +174,18 @@ static int guc_ucode_xfer_dma(struct
> >drm_i915_private *dev_priv,
> >  */
> > ret = wait_for(guc_ucode_response(dev_priv, &status), 100);
> >+load_time = ktime_ms_delta(ktime_get(), start_load);
> >+
> > DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
> > I915_READ(DMA_CTRL), status);
> > if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
> > DRM_ERROR("GuC firmware signature verification failed\n");
> > ret = -ENOEXEC;
> >-}
> >+} else if (load_time > 20)
> >+DRM_NOTE("GuC load takes more than acceptable threshold\n");
> 
> Please add threshold and actual load time to the message to let user
> know that times
 
> >+else
> >+DRM_DEBUG_DRIVER("GuC loaded in %d ms\n", load_time);
> 
> And I'm not sure that we can rely on 'load_time' on timeout in wait_for.

Hmm we  are checking the DMA status right after that which means
the firmware load should have happened by then thats why I 
am calculating it there

 
> > DRM_DEBUG_DRIVER("returning %d\n", ret);

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

Re: [Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.04 for Kabylake

[Pandiyan, Dhinakaran]

On Thu, 2017-11-02 at 07:27 -0700, Rodrigo Vivi wrote:
> On Thu, Nov 02, 2017 at 10:34:37AM +, Jani Nikula wrote:
> > On Wed, 01 Nov 2017, Anusha Srivatsa  wrote:
> > > There is a new version of DMC available for KBL.
> > 
> > Nobody's going to pull this to linux-firmware if you don't send it to
> > the linux-firmware folks...
> 
> That's intentional. The idea is to send to linux-firmware only after it
> passes our CI. So, prepare already in a way that it is easy to just forward 
> when
> that happens.
> 
> But what I believe we can change is to send that in the cover-letter of
> the series.
> So cover-letter with pull-request that CI would get automatically,
> all related patches on the series, so right now it could be:
> patch 0: pull-request
> patch 1: kbl dmc 1.04
> patch 2: skl dmc 1.27
This patch updates only KBL firmware. Is there an upcoming 1.27 release
for SKL?
> 
> > 
> > > The release notes mentions:
> > > 1. Fix for the issue where DC_STATE was getting enabled even
> > > when disabled by driver causing data corruption.
> > >
> > > Adding the pull request here as an experiment-
> > > The following changes since commit 
> > > bf04291309d3169c0ad3b8db52564235bbd08e30:
> > >
> > >   WHENCE: Add new qed firmware (2017-10-09 18:03:26 +0100)
> > >
> > > are available in the git repository at:
> > >
> > >   https://github.com/anushasr/linux-firmware.git KBL_DMC
> > 
> > We should have a shared repo for this at freedesktop.org instead of your
> > private repo at github.
> 
> I had never seen a particularly need for that before, but with
> this new process in place I believe it makes tons of sense.
> Who could help to setup a repo and right permissions?
> Daniel Stone?
> 
> > And we should use signed tags for pull requests.
> 
> Yes, tags are essencial here. Specially with this process
> of sending here first for CI and only after passing CI fwding
> that to linux-firmware.git we need to have tags.
> 
> Thanks,
> Rodrigo.
> 
> > 
> > BR,
> > Jani.
> > 
> > >
> > > for you to fetch changes up to 2f2b42764455856c2ba63d2154b3b2fbb7424236:
> > >
> > >   linux-firmware: DMC firmware for kabylake v1.04 (2017-11-01 19:22:21 
> > > -0700)
> > >
> > > 
> > > Anusha Srivatsa (1):
> > >   linux-firmware: DMC firmware for kabylake v1.04
> > >
> > >  WHENCE   |   4 
> > >  i915/kbl_dmc_ver1_04.bin | Bin 0 -> 8840 bytes
> > >  2 files changed, 4 insertions(+)
> > >  create mode 100644 i915/kbl_dmc_ver1_04.bin
> > >
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: Anusha Srivatsa 
> > > ---
> > >  drivers/gpu/drm/i915/intel_csr.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> > > b/drivers/gpu/drm/i915/intel_csr.c
> > > index 3e1f86d..5842777 100644
> > > --- a/drivers/gpu/drm/i915/intel_csr.c
> > > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > > @@ -40,9 +40,9 @@
> > >  #define I915_CSR_CNL "i915/cnl_dmc_ver1_06.bin"
> > >  #define CNL_CSR_VERSION_REQUIRED CSR_VERSION(1, 6)
> > >  
> > > -#define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
> > > +#define I915_CSR_KBL "i915/kbl_dmc_ver1_04.bin"
> > >  MODULE_FIRMWARE(I915_CSR_KBL);
> > > -#define KBL_CSR_VERSION_REQUIRED CSR_VERSION(1, 1)
> > > +#define KBL_CSR_VERSION_REQUIRED CSR_VERSION(1, 4)
> > >  
> > >  #define I915_CSR_SKL "i915/skl_dmc_ver1_26.bin"
> > >  MODULE_FIRMWARE(I915_CSR_SKL);
> > 
> > -- 
> > Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Cannonlake perf support (rev2)

[Patchwork]

== Series Details ==

Series: i915: Cannonlake perf support (rev2)
URL   : https://patchwork.freedesktop.org/series/32762/
State : failure

== Summary ==

Test kms_flip:
Subgroup blocking-wf_vblank:
pass   -> FAIL   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw)
Subgroup extended-modeset-hang-newfb-with-reset-render-B:
pass   -> DMESG-WARN (shard-hsw)
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912

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

shard-hswtotal:2539 pass:1430 dwarn:2   dfail:0   fail:10  skip:1097 
time:9297s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 8/9] drm/i915: expose eu topology to userspace

[Lionel Landwerlin]

On 02/11/17 16:35, Chris Wilson wrote:

Quoting Lionel Landwerlin (2017-11-02 16:29:48)

+/* Query various aspects of the topology of the GPU. Below is a list of the
+ * currently supported queries. The motivation of this more detailed query
+ * mechanism is to expose asynmetric properties of the GPU. Starting with CNL,
+ * slices might have different sizes (for example 3 subslices in slice0 and 2
+ * subslices in slice1+). This means we cannot rely on PARAM_SUBSLICE_MASK
+ * anymore.
+ *
+ * When using this parameter, getparam value should point to a structure of
+ * type drm_i915_topology_t. Call this once with query set to the relevant
+ * information to be queried and data_size set to 0. The kernel will then set
+ * params and data_size to the expected length of data[]. The should make sure
+ * memory is allocated to the right length before making a second getparam
+ * with data_size already set. The kernel will then populate data[]. The
+ * meaning of params[] elements is described for each query below.
+ */
+#define I915_PARAM_TOPOLOGY 51
+typedef struct drm_i915_topology {

Oh crumbs. Please join the intel_engine_info_ioctl discussion.

As it stands, lets not introduce multiplexing into an already multiplexed
getparam ioctl.
-Chris


Hey Tvrtko,

Is your intel_engine_info ioctl implementation available anywhere?

Thanks,

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

[Intel-gfx] ✓ Fi.CI.BAT: success for tests: add device information tests (rev2)

[Patchwork]

== Series Details ==

Series: tests: add device information tests (rev2)
URL   : https://patchwork.freedesktop.org/series/32764/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
6d16875736b9fb1ebf4bf3dc5a941f9e431d58e0 lib/igt_debugfs: Remove support for 
legacy CRC api.

with latest DRM-Tip kernel build CI_DRM_3309
fca2506bc5d4 drm-tip: 2017y-11m-02d-13h-10m-58s UTC integration manifest

Testlist changes:
+igt@intel_device_info@cs-timestamp-frequency
+igt@intel_device_info@topology-coherent-slice-mask
+igt@intel_device_info@topology-invalid-params
+igt@intel_device_info@topology-matches-eu-total
+igt@intel_device_info@topology-pre-gen8

Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6700k) fdo#103546 +1
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-kbl-7560u) fdo#102846

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:444s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:387s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:539s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:279s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:507s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:510s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:513s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:491s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:546s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:615s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:431s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:580s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:498s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:438s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:436s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:432s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:484s
fi-kbl-7560u total:245  pass:228  dwarn:0   dfail:0   fail:0   skip:16 
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:590s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:573s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:599s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:653s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:523s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:573s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] kms_atomic_transition: Split out modeset tests on internal panels

[Chris Wilson]

Quoting Imre Deak (2017-11-02 13:38:09)
> Doing modeset on internal panels may have a considerable overhead due to
> the panel specific power sequencing delays. To avoid long test runtimes
> in the CI fast-feedback test split out the testing of internal panels
> from the plane modeset subtests. Create fast and slow versions of these
> new subtests. In the fast one only combinations with all enabled, all
> planes disabled or a single plane enable are tested. In the slow one all
> plane combinations are tested.

> @@ -528,6 +529,10 @@ run_transition_test(igt_display_t *display, enum pipe 
> pipe, igt_output_t *output
> }
>  
> for (i = 0; i < iter_max; i++) {
> +   if (type == TRANSITION_MODESET_PLANES_FAST &&
> +   hweight32(i) != 1 && hweight32(i) != pipe_obj->n_planes)

So reduce number of iterations to a power of two, and only operate if
pipe_obj->n_planes == 1

Why repeat hweight32(i) when you've already proved it is 1? That reads
very fishily.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for kms_atomic_transition: Split out modeset tests on internal panels

[Patchwork]

== Series Details ==

Series: kms_atomic_transition: Split out modeset tests on internal panels
URL   : https://patchwork.freedesktop.org/series/33052/
State : warning

== Summary ==

Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking:
pass   -> DMESG-WARN (shard-hsw)
Test drv_module_reload:
Subgroup basic-reload:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw)

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

shard-hswtotal:2543 pass:1436 dwarn:1   dfail:0   fail:9   skip:1097 
time:9266s

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/3] drm/i915: Check if the stolen memory "reserved" area is enabled or not

[Ville Syrjälä]

On Thu, Nov 02, 2017 at 04:34:26PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/3] drm/i915: Check if the stolen memory 
> "reserved" area is enabled or not
> URL   : https://patchwork.freedesktop.org/series/33060/
> State : warning
> 
> == Summary ==
> 
> Test kms_busy:
> Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
> dmesg-warn -> PASS   (shard-hsw)
> Subgroup extended-modeset-hang-newfb-with-reset-render-B:
> pass   -> DMESG-WARN (shard-hsw)

Hmm. The warn was there already AFAICS. I wonder why this is claiming
things were passing?

Also shard-glkb didn't seem to get any results from this run. No idea
why, nor why this summary fails to mention that fact.

Oh and BTW the boot/dmesg links from the shard results don't seem to
work very well. Sometimes it just gets you an empty log and you have
to manually find a file that has some actual content in it.

> 
> shard-hswtotal:2539 pass:1432 dwarn:2   dfail:0   fail:8   skip:1097 
> time:9313s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6930/shards.html

Looking at the results we go from
<7>[2.822784] [drm:i915_ggtt_probe_hw [i915]] GTT stolen size = 128M
<7>[2.826115] [drm:i915_gem_init_stolen [i915]] Stolen reserved area
[0x0110 - 0x0120] outside stolen memory
[0xc7a0 - 0xcfa0]

to
<7>[2.909693] [drm:i915_ggtt_probe_hw [i915]] GTT stolen size = 128M
<7>[2.912226] [drm:i915_gem_init_stolen [i915]] Memory reserved for
graphics device: 131072K, usable: 131072K

on shard-snb6 at least.

After going through the dmesgs for all the other machines we have in ci,
it doesn't look like there were any other changes in the amount of stolen
memory we detect (well, couldn't check shard-glkb due to lack fo results).

-- 
Ville Syrjälä
Intel OTC
___
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: Plane assert/readout cleanups etc. (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915: Plane assert/readout cleanups etc. (rev8)
URL   : https://patchwork.freedesktop.org/series/31758/
State : success

== Summary ==

Series 31758v8 drm/i915: Plane assert/readout cleanups etc.
https://patchwork.freedesktop.org/api/1.0/series/31758/revisions/8/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6700k) fdo#103546 +1

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:438s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:378s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:540s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:504s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:504s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:484s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:606s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:262s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:587s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:493s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:439s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:424s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:492s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:574s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:584s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:566s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:597s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:652s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:526s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:579s

fca2506bc5d492609e3f1b6e59d667e376a1eb3f drm-tip: 2017y-11m-02d-13h-10m-58s UTC 
integration manifest
5dddaaf97854 drm/i915: Use enum i9xx_plane_id for the .get_fifo_size() hooks
33b9349ae2c9 drm/i915: s/enum plane/enum i9xx_plane_id/
894968974f00 drm/i915: Redo plane sanitation during readout
27e9f7a84447 drm/i915: Add .get_hw_state() method for planes

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.04 for Kabylake

[Srivatsa, Anusha]

>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Thursday, November 2, 2017 3:35 AM
>To: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Cc: Vivi, Rodrigo 
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.04 for Kabylake
>
>On Wed, 01 Nov 2017, Anusha Srivatsa  wrote:
>> There is a new version of DMC available for KBL.
>
>Nobody's going to pull this to linux-firmware if you don't send it to the 
>linux-
>firmware folks...
>
>> The release notes mentions:
>> 1. Fix for the issue where DC_STATE was getting enabled even when
>> disabled by driver causing data corruption.
>>
>> Adding the pull request here as an experiment- The following changes
>> since commit bf04291309d3169c0ad3b8db52564235bbd08e30:
>>
>>   WHENCE: Add new qed firmware (2017-10-09 18:03:26 +0100)
>>
>> are available in the git repository at:
>>
>>   https://github.com/anushasr/linux-firmware.git KBL_DMC
>
>We should have a shared repo for this at freedesktop.org instead of your 
>private
>repo at github. And we should use signed tags for pull requests.
Hi Jani,

I will see to it that a freedesktop repo is created for this purpose moving 
forward. I will use signed tags too.

Thanks,
Anusha

>BR,
>Jani.
>
>>
>> for you to fetch changes up to 2f2b42764455856c2ba63d2154b3b2fbb7424236:
>>
>>   linux-firmware: DMC firmware for kabylake v1.04 (2017-11-01 19:22:21
>> -0700)
>>
>> 
>> Anusha Srivatsa (1):
>>   linux-firmware: DMC firmware for kabylake v1.04
>>
>>  WHENCE   |   4 
>>  i915/kbl_dmc_ver1_04.bin | Bin 0 -> 8840 bytes
>>  2 files changed, 4 insertions(+)
>>  create mode 100644 i915/kbl_dmc_ver1_04.bin
>>
>> Cc: Rodrigo Vivi 
>> Signed-off-by: Anusha Srivatsa 
>> ---
>>  drivers/gpu/drm/i915/intel_csr.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_csr.c
>> b/drivers/gpu/drm/i915/intel_csr.c
>> index 3e1f86d..5842777 100644
>> --- a/drivers/gpu/drm/i915/intel_csr.c
>> +++ b/drivers/gpu/drm/i915/intel_csr.c
>> @@ -40,9 +40,9 @@
>>  #define I915_CSR_CNL "i915/cnl_dmc_ver1_06.bin"
>>  #define CNL_CSR_VERSION_REQUIREDCSR_VERSION(1, 6)
>>
>> -#define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
>> +#define I915_CSR_KBL "i915/kbl_dmc_ver1_04.bin"
>>  MODULE_FIRMWARE(I915_CSR_KBL);
>> -#define KBL_CSR_VERSION_REQUIREDCSR_VERSION(1, 1)
>> +#define KBL_CSR_VERSION_REQUIREDCSR_VERSION(1, 4)
>>
>>  #define I915_CSR_SKL "i915/skl_dmc_ver1_26.bin"
>>  MODULE_FIRMWARE(I915_CSR_SKL);
>
>--
>Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: Cannonlake perf support (rev2)

[Patchwork]

== Series Details ==

Series: i915: Cannonlake perf support (rev2)
URL   : https://patchwork.freedesktop.org/series/32762/
State : success

== Summary ==

Series 32762v2 i915: Cannonlake perf support
https://patchwork.freedesktop.org/api/1.0/series/32762/revisions/2/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> DMESG-FAIL (fi-kbl-7500u) fdo#102514
Test gem_ctx_switch:
Subgroup basic-default-heavy:
pass   -> INCOMPLETE (fi-glk-dsi) fdo#103359
Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6700k) fdo#103546 +1

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#103546 https://bugs.freedesktop.org/show_bug.cgi?id=103546

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:455s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:379s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:538s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:504s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:507s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:504s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:501s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:609s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:262s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:582s
fi-glk-dsi   total:32   pass:22   dwarn:0   dfail:0   fail:0   skip:9  
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:432s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:1   fail:0   skip:24  
time:497s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:576s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:579s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:571s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:593s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:651s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:520s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:508s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:641s
fi-cfl-s failed to connect after reboot
fi-kbl-7567u failed to connect after reboot

fca2506bc5d492609e3f1b6e59d667e376a1eb3f drm-tip: 2017y-11m-02d-13h-10m-58s UTC 
integration manifest
778e02fb0445 drm/i915/debugfs: reuse max slice/subslices already stored in sseu
19e052b34f25 drm/i915: expose eu topology to userspace
683edd45e040 drm/i915/perf: reuse timestamp frequency from device info
177dac23af0c drm/i915: expose command stream timestamp frequency to userspace
be5697a8b0e4 drm/i915/perf: enable perf support on CNL
2e226815b00f drm/i915: fix register naming
7a971330dc93 drm/i915/perf: refactor perf setup
89f3787ed275 drm/i915/perf: add support for Coffeelake GT3
b2d7402277b3 drm/i915/perf: complete whitelisting for OA programming on HSW

== Logs ==

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

[Intel-gfx] [PATCH v2 10/10] drm/i915: Add rudimentary plane state verification

[Ville Syrjala]

From: Ville Syrjälä 

Check that the planes are in the state we expect them to be. For
now we can only check whether each plane is correctly enabled or
disabled. In the future we may want to expand the plane state
readout to support a more through verification.

v2: Verify all planes part of the state as long as at lest
one crtc is doing a modeset (Daniel)

Cc: Daniel Vetter 
Suggested-by: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c23dad6d3c24..96e0a5fd69cf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11537,6 +11537,18 @@ verify_crtc_state(struct drm_crtc *crtc,
 }
 
 static void
+intel_verify_planes(struct intel_atomic_state *state)
+{
+   struct intel_plane *plane;
+   const struct intel_plane_state *plane_state;
+   int i;
+
+   for_each_new_intel_plane_in_state(state, plane,
+ plane_state, i)
+   assert_plane(plane, plane_state->base.visible);
+}
+
+static void
 verify_single_dpll_state(struct drm_i915_private *dev_priv,
 struct intel_shared_dpll *pll,
 struct drm_crtc *crtc,
@@ -12329,6 +12341,9 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
intel_modeset_verify_crtc(crtc, state, old_crtc_state, 
new_crtc_state);
}
 
+   if (intel_state->modeset)
+   intel_verify_planes(intel_state);
+
if (intel_state->modeset && intel_can_enable_sagv(state))
intel_enable_sagv(dev_priv);
 
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH v8 2/6] drm/i915/guc : Removing i915_modparams.enable_guc_loading module parameter

[Sujaritha]

On 10/25/2017 08:26 AM, Michal Wajdeczko wrote:
On Tue, 24 Oct 2017 19:21:21 +0200, Sujaritha Sundaresan 
 wrote:



We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1.We also need
loading=1 when we want to want to verify the HuC, which
is every time we have a HuC (but all platforms with HuC
have a GuC and viceversa).

Also if we have HuC have firmware to be loaded, we need to
have GuC to actually load it. So if the user wants to avoid
the GuC from getting loaded, they must not have a HuC
firmware to be loaded, in addition to not using submission.


Hmm, I'm not sure that removal of HuC firmware file is the best
way for the user to stop undesired GuC loading.

I know that we want to minimize number of modparams, but maybe
new i915.enable_huc=auto(-1)|never(0)|if available(1)|required(2)
will solve here ...

Alternatively we can replace both existing modparams with single:

i915.enable_guc = off(0) | auto(1) | submission(2) | huc(4)

then we could cover almost all cases:

0 = GuC loading disabled (no GuC submission, no HuC)
1 = GuC loading auto
2 = GuC loading enabled, GuC submission required, HuC disabled
3 = GuC loading enabled, GuC submission enabled,  HuC disabled
4 = GuC loading enabled, GuC submission disabled, HuC required
5 = GuC loading enabled, GuC submission disabled, HuC enabled
6 = GuC loading enabled, GuC submission required, HuC required
7 = GuC loading enabled, GuC submission enabled,  HuC enabled


This is a really good idea. I will include the new modparams in the next 
revision.





v2: Clarifying the commit message (Anusha)

v3: Unify seq_puts messages, Re-factoring code as per review (Michal)

v4: Rebase

v5: Separating message unification into a separate patch

v6: Re-factoring code (Sagar, Michal)
    Rebase

v7: Applying review comments (Sagar)
    Rebase

v8: Change to NEEDS_GUC_FW (Chris)
    Applying review comments (Michal)
    Clarifying commit message (Joonas)

Suggested by: Oscar Mateo 
Signed-off-by: Sujaritha Sundaresan 
Cc: Anusha Srivatsa 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h |  9 +++--
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
 drivers/gpu/drm/i915/i915_irq.c |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  4 ---
 drivers/gpu/drm/i915/i915_params.h  |  1 -
 drivers/gpu/drm/i915/intel_uc.c | 57 
+++--

 8 files changed, 34 insertions(+), 44 deletions(-)

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

index 8edd029..25c47a0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2465,7 +2465,7 @@ static bool check_guc_submission(struct 
seq_file *m)

if (!guc->execbuf_client) {
 seq_printf(m, "GuC submission %s\n",
-   HAS_GUC_SCHED(dev_priv) ?
+   HAS_GUC(dev_priv) ?
    "disabled" :
    "not supported");


As I already said before, there is also 3rd possible status "failed"

!HAS_GUC(dev_priv) ? "not supported" :
    !HAS_GUC_SCHED(dev_priv) ? "disabled" :
    "failed"

where HAS_GUC_SCHED is

#define HAS_GUC_SCHED(dev_priv) \
    (HAS_GUC(dev_priv) && i915_modparams.enable_guc_submission)

or something similar



Sorry, I missed the third case. I will include it and the change to the 
macro condition

in the next revision.

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

index f01c800..ede5004 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3205,9 +3205,11 @@ static inline unsigned int 
i915_sg_segment_size(void)

  */
 #define HAS_GUC(dev_priv)    ((dev_priv)->info.has_guc)
 #define HAS_GUC_CT(dev_priv) ((dev_priv)->info.has_guc_ct)
-#define HAS_GUC_UCODE(dev_priv)    (HAS_GUC(dev_priv))
-#define HAS_GUC_SCHED(dev_priv)    (HAS_GUC(dev_priv))
-#define HAS_HUC_UCODE(dev_priv)    (HAS_GUC(dev_priv))
+#define HAS_GUC_UCODE(dev_priv) ((dev_priv)->guc.fw.path != NULL)
+#define HAS_HUC_UCODE(dev_priv) ((dev_priv)->huc.fw.path != NULL)
+
+#define NEEDS_GUC_FW(dev_priv) \


Hmm, based on its usage, this name is now little confusing.
Maybe USES_GUC ? See USES_PPGTT|USES_FULL_PPGTT|USES_FULL_48BIT_PPGTT


I would really prefer to keep NEEDS_GUC_FW


+    (HAS_GUC(dev_priv) && \
+    (i915_modparams.enable_guc_submission || 
HAS_HUC_UCODE(dev_priv)))


While unlikely, above will be true even with guc.fw.path == NULL

Also, based on your statement "all platforms with HuC have a GuC
and viceversa" I would assume that corresponding firmwares will
be delivered also in pairs (except short enabling periods).

Thus on every platform with has_guc=1 there wi

Re: [Intel-gfx] [PATCH v2 8/9] drm/i915: expose eu topology to userspace

[Lionel Landwerlin]

On 02/11/17 16:35, Chris Wilson wrote:

Quoting Lionel Landwerlin (2017-11-02 16:29:48)

+/* Query various aspects of the topology of the GPU. Below is a list of the
+ * currently supported queries. The motivation of this more detailed query
+ * mechanism is to expose asynmetric properties of the GPU. Starting with CNL,
+ * slices might have different sizes (for example 3 subslices in slice0 and 2
+ * subslices in slice1+). This means we cannot rely on PARAM_SUBSLICE_MASK
+ * anymore.
+ *
+ * When using this parameter, getparam value should point to a structure of
+ * type drm_i915_topology_t. Call this once with query set to the relevant
+ * information to be queried and data_size set to 0. The kernel will then set
+ * params and data_size to the expected length of data[]. The should make sure
+ * memory is allocated to the right length before making a second getparam
+ * with data_size already set. The kernel will then populate data[]. The
+ * meaning of params[] elements is described for each query below.
+ */
+#define I915_PARAM_TOPOLOGY 51
+typedef struct drm_i915_topology {

Oh crumbs. Please join the intel_engine_info_ioctl discussion.


Where is that?



As it stands, lets not introduce multiplexing into an already multiplexed
getparam ioctl.


But a int* is not enough!


-Chris



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

Re: [Intel-gfx] [PATCH v2 8/9] drm/i915: expose eu topology to userspace

[Chris Wilson]

Quoting Lionel Landwerlin (2017-11-02 16:29:48)
> +/* Query various aspects of the topology of the GPU. Below is a list of the
> + * currently supported queries. The motivation of this more detailed query
> + * mechanism is to expose asynmetric properties of the GPU. Starting with 
> CNL,
> + * slices might have different sizes (for example 3 subslices in slice0 and 2
> + * subslices in slice1+). This means we cannot rely on PARAM_SUBSLICE_MASK
> + * anymore.
> + *
> + * When using this parameter, getparam value should point to a structure of
> + * type drm_i915_topology_t. Call this once with query set to the relevant
> + * information to be queried and data_size set to 0. The kernel will then set
> + * params and data_size to the expected length of data[]. The should make 
> sure
> + * memory is allocated to the right length before making a second getparam
> + * with data_size already set. The kernel will then populate data[]. The
> + * meaning of params[] elements is described for each query below.
> + */
> +#define I915_PARAM_TOPOLOGY 51
> +typedef struct drm_i915_topology {

Oh crumbs. Please join the intel_engine_info_ioctl discussion.

As it stands, lets not introduce multiplexing into an already multiplexed
getparam ioctl.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/3] drm/i915: Check if the stolen memory "reserved" area is enabled or not

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Check if the stolen memory 
"reserved" area is enabled or not
URL   : https://patchwork.freedesktop.org/series/33060/
State : warning

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw)
Subgroup extended-modeset-hang-newfb-with-reset-render-B:
pass   -> DMESG-WARN (shard-hsw)

shard-hswtotal:2539 pass:1432 dwarn:2   dfail:0   fail:8   skip:1097 
time:9313s

== Logs ==

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

[Intel-gfx] [PATCH i-g-t v2] tests: add device information tests

[Lionel Landwerlin]

We can verify that topology is consistent with previous getparam like
EU_TOTAL.

We also verify that CS timestamp frequency is always filled.

v2: Use v2 of kernel uapi (Lionel)
Fix Gen < 8 issue

Signed-off-by: Lionel Landwerlin 
---
 tests/Makefile.sources|   1 +
 tests/intel_device_info.c | 353 ++
 tests/meson.build |   1 +
 3 files changed, 355 insertions(+)
 create mode 100644 tests/intel_device_info.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 2313c12b..c7538cb6 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -168,6 +168,7 @@ TESTS_progs = \
gen3_render_tiledy_blits \
gen7_forcewake_mt \
gvt_basic \
+   intel_device_info \
kms_3d \
kms_addfb_basic \
kms_atomic \
diff --git a/tests/intel_device_info.c b/tests/intel_device_info.c
new file mode 100644
index ..f5032f2c
--- /dev/null
+++ b/tests/intel_device_info.c
@@ -0,0 +1,353 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+
+IGT_TEST_DESCRIPTION("Test device information retrieving through 
i915_getparam.");
+
+static int drm_fd;
+static int devid;
+
+#ifndef I915_PARAM_SLICE_MASK
+#define I915_PARAM_SLICE_MASK   46
+#endif
+
+#ifndef I915_PARAM_SUBSLICE_MASK
+#define I915_PARAM_SUBSLICE_MASK47
+#endif
+
+#ifndef I915_PARAM_CS_TIMESTAMP_FREQUENCY
+#define I915_PARAM_CS_TIMESTAMP_FREQUENCY   50
+#endif
+
+#ifndef I915_PARAM_TOPOLOGY
+/* Query various aspects of the topology of the GPU. Below is a list of the
+ * currently supported queries. The motivation of this more detailed query
+ * mechanism is to expose asynmetric properties of the GPU. Starting with CNL,
+ * slices might have different sizes (for example 3 subslices in slice0 and 2
+ * subslices in slice1+). This means we cannot rely on PARAM_SUBSLICE_MASK
+ * anymore.
+ *
+ * When using this parameter, getparam value should point to a structure of
+ * type drm_i915_topology_t. Call this once with query set to the relevant
+ * information to be queried and data_size set to 0. The kernel will then set
+ * params and data_size to the expected length of data[]. The should make sure
+ * memory is allocated to the right length before making a second getparam
+ * with data_size already set. The kernel will then populate data[]. The
+ * meaning of params[] elements is described for each query below.
+ */
+#define I915_PARAM_TOPOLOGY 51
+typedef struct drm_i915_topology {
+   __u32 query;
+   __u32 data_size;
+
+   /* Query the availability of slices :
+*
+* params[0] : the maximum number of slices
+*
+* Each bit in data indicates whether a slice is available (1) or
+* fused off (0). Formula to tell if slice X is available :
+*
+* (data[X / 8] >> (X % 8)) & 1
+*/
+#define   I915_PARAM_TOPOLOGY_QUERY_SLICE_MASK 0
+   /* Query the availability of subslices :
+*
+* params[0] : slice stride
+*
+* Each bit in data indicates whether a subslice is available (1) or
+* fused off (0). Formula to tell if slice X subslice Y is available :
+*
+* (data[(X * params[0]) + Y / 8] >> (Y % 8)) & 1
+*/
+#define   I915_PARAM_TOPOLOGY_QUERY_SUBSLICE_MASK  1
+   /* Query the availability of EUs :
+*
+* params[0] : slice stride
+* params[1] : subslice stride
+*
+* Each bit in data indicates whether a slice is available (1) or
+* fused off (0). Formula to tell if slice X subslice Y eu Z is
+* available :
+*
+* (data[X * params[0] + Y * param

[Intel-gfx] [PATCH v2 1/9] drm/i915/perf: complete whitelisting for OA programming on HSW

[Lionel Landwerlin]

We were missing some registers and also can name one for which we only had
the offset.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_perf.c |  3 ++-
 drivers/gpu/drm/i915/i915_reg.h  | 14 ++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 59ee808f8fd9..45aef15b9e7c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3023,7 +3023,8 @@ static bool hsw_is_valid_mux_addr(struct drm_i915_private 
*dev_priv, u32 addr)
 {
return gen7_is_valid_mux_addr(dev_priv, addr) ||
(addr >= 0x25100 && addr <= 0x2FF90) ||
-   addr == 0x9ec0;
+   (addr >= HSW_MBVID2_NOA0.reg && addr <= HSW_MBVID2_NOA9.reg) ||
+   addr == HSW_MBVID2_MISR0.reg;
 }
 
 static bool chv_is_valid_mux_addr(struct drm_i915_private *dev_priv, u32 addr)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f0f8f6059652..ee4941a1df20 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1120,6 +1120,20 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 /* RPC unit config (Gen8+) */
 #define RPM_CONFIG _MMIO(0x0D08)
 
+/* NOA (HSW) */
+#define HSW_MBVID2_NOA0_MMIO(0x9E80)
+#define HSW_MBVID2_NOA1_MMIO(0x9E84)
+#define HSW_MBVID2_NOA2_MMIO(0x9E88)
+#define HSW_MBVID2_NOA3_MMIO(0x9E8C)
+#define HSW_MBVID2_NOA4_MMIO(0x9E90)
+#define HSW_MBVID2_NOA5_MMIO(0x9E94)
+#define HSW_MBVID2_NOA6_MMIO(0x9E98)
+#define HSW_MBVID2_NOA7_MMIO(0x9E9C)
+#define HSW_MBVID2_NOA8_MMIO(0x9EA0)
+#define HSW_MBVID2_NOA9_MMIO(0x9EA4)
+
+#define HSW_MBVID2_MISR0   _MMIO(0x9EC0)
+
 /* NOA (Gen8+) */
 #define NOA_CONFIG(i)  _MMIO(0x0D0C + (i) * 4)
 
-- 
2.15.0

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

[Intel-gfx] [PATCH v2 8/9] drm/i915: expose eu topology to userspace

[Lionel Landwerlin]

With the introduction of asymetric slices in CNL, we cannot rely on the
previous SUBSLICE_MASK getparam. Here we introduce a more detailed way of
querying the Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit, because
counters need to be normalized to the number of EUs/subslices/slices. The
current aggregated numbers like EU_TOTAL do not gives us sufficient
information.

This change introduce a new way to query properties of the GPU, making
room for new queries (some media related topology could be exposed in
the future).

As a bonus we can draw representations of the GPU :

https://imgur.com/a/vuqpa

v2: Simplify uapi and make it extensible (Lionel)

Signed-off-by: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  24 +++--
 drivers/gpu/drm/i915/i915_drv.c  |  65 +++-
 drivers/gpu/drm/i915/i915_drv.h  |  23 -
 drivers/gpu/drm/i915/intel_device_info.c | 171 ++-
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 include/uapi/drm/i915_drm.h  |  58 +++
 7 files changed, 283 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0897fd616a1f..8521fc012fa4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4441,7 +4441,7 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask = BIT(0);
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslices_mask[0] |= BIT(ss);
eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
@@ -4488,7 +4488,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask |= BIT(s);
-   sseu->subslice_mask = info->sseu.subslice_mask;
+   sseu->subslices_mask[s] = info->sseu.subslices_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4543,8 +4543,8 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
 
if (IS_GEN9_BC(dev_priv))
-   sseu->subslice_mask =
-   INTEL_INFO(dev_priv)->sseu.subslice_mask;
+   sseu->subslices_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4554,7 +4554,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
/* skip disabled subslice */
continue;
 
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslices_mask[s] |= BIT(ss);
}
 
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
@@ -4576,9 +4576,12 @@ static void broadwell_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
 
if (sseu->slice_mask) {
-   sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
sseu->eu_per_subslice =
INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   sseu->subslices_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
+   }
sseu->eu_total = sseu->eu_per_subslice *
 sseu_subslice_total(sseu);
 
@@ -4597,6 +4600,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool 
is_available_info,
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const char *type = is_available_info ? "Available" : "Enabled";
+   int s;
 
seq_printf(m, "  %s Slice Mask: %04x\n", type,
   sseu->slice_mask);
@@ -4604,10 +4608,10 @@ static void i915_print_sseu_info(struct seq_file *m, 
bool is_available_info,
   hweight8(sseu->slice_mask));
seq_printf(m, "  %s Subslice Total: %u\n", type,
   sseu_subslice_total(sseu));
-   seq_printf(m, "  %s Subslice Mask: %04x\n", type,
-  sseu->subslice_mask);
-   seq_printf(m, "  %s Subslice Per Slice: %u\n", type,
-  hweight8(sseu->subslice_mask));
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   seq_printf(m, "  %s Slice%i Subslice Mask: %04x\n", type,

[Intel-gfx] [PATCH v2 3/9] drm/i915/perf: refactor perf setup

[Lionel Landwerlin]

Gen8/9 aren't very different and we can merge some of this code.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_perf.c | 48 +---
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 7271debe0417..802928c54f06 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3423,41 +3423,46 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
 * worth the complexity to maintain now that BDW+ enable
 * execlist mode by default.
 */
-   dev_priv->perf.oa.ops.is_valid_b_counter_reg =
-   gen7_is_valid_b_counter_addr;
-   dev_priv->perf.oa.ops.is_valid_mux_reg =
-   gen8_is_valid_mux_addr;
-   dev_priv->perf.oa.ops.is_valid_flex_reg =
-   gen8_is_valid_flex_addr;
+   dev_priv->perf.oa.oa_formats = gen8_plus_oa_formats;
 
dev_priv->perf.oa.ops.init_oa_buffer = gen8_init_oa_buffer;
-   dev_priv->perf.oa.ops.enable_metric_set = 
gen8_enable_metric_set;
-   dev_priv->perf.oa.ops.disable_metric_set = 
gen8_disable_metric_set;
dev_priv->perf.oa.ops.oa_enable = gen8_oa_enable;
dev_priv->perf.oa.ops.oa_disable = gen8_oa_disable;
dev_priv->perf.oa.ops.read = gen8_oa_read;
dev_priv->perf.oa.ops.oa_hw_tail_read = gen8_oa_hw_tail_read;
 
-   dev_priv->perf.oa.oa_formats = gen8_plus_oa_formats;
-
-   if (IS_GEN8(dev_priv)) {
-   dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
-   dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
+   if (IS_GEN8(dev_priv) || IS_GEN9(dev_priv)) {
+   dev_priv->perf.oa.ops.is_valid_b_counter_reg =
+   gen7_is_valid_b_counter_addr;
+   dev_priv->perf.oa.ops.is_valid_mux_reg =
+   gen8_is_valid_mux_addr;
+   dev_priv->perf.oa.ops.is_valid_flex_reg =
+   gen8_is_valid_flex_addr;
 
-   dev_priv->perf.oa.timestamp_frequency = 1250;
-
-   dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
if (IS_CHERRYVIEW(dev_priv)) {
dev_priv->perf.oa.ops.is_valid_mux_reg =
chv_is_valid_mux_addr;
}
-   } else if (IS_GEN9(dev_priv)) {
-   dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
-   dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
 
-   dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
+   dev_priv->perf.oa.ops.enable_metric_set = 
gen8_enable_metric_set;
+   dev_priv->perf.oa.ops.disable_metric_set = 
gen8_disable_metric_set;
+
+   if (IS_GEN8(dev_priv)) {
+   dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
+   dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
+
+   dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
+   } else {
+   dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
+   dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
+
+   dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
+   }
 
switch (dev_priv->info.platform) {
+   case INTEL_BROADWELL:
+   dev_priv->perf.oa.timestamp_frequency = 
1250;
+   break;
case INTEL_BROXTON:
case INTEL_GEMINILAKE:
dev_priv->perf.oa.timestamp_frequency = 
1920;
@@ -3468,9 +3473,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.timestamp_frequency = 
1200;
break;
default:
-   /* Leave timestamp_frequency to 0 so we can
-* detect unsupported platforms.
-*/
break;
}
}
-- 
2.15.0

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

[Intel-gfx] [PATCH v2 9/9] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

[Lionel Landwerlin]

Now that we have that information in topology fields, let's just reused it.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8521fc012fa4..90bbfbba317a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4456,11 +4456,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 struct sseu_dev_info *sseu)
 {
const struct intel_device_info *info = INTEL_INFO(dev_priv);
-   int s_max = 6, ss_max = 4;
int s, ss;
-   u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+   u32 s_reg[info->sseu.max_slices],
+   eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
/*
 * FIXME: Valid SS Mask respects the spec and read
 * only valid bits for those registers, excluding reserverd
@@ -4482,7 +4482,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4490,7 +4490,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
sseu->subslices_mask[s] = info->sseu.subslices_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
@@ -4510,17 +4510,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
 {
-   int s_max = 3, ss_max = 4;
+   const struct intel_device_info *info = INTEL_INFO(dev_priv);
int s, ss;
-   u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
-
-   /* BXT has a single slice and at most 3 subslices. */
-   if (IS_GEN9_LP(dev_priv)) {
-   s_max = 1;
-   ss_max = 3;
-   }
+   u32 s_reg[info->sseu.max_slices], eu_reg[2*info->sseu.max_subslices], 
eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
@@ -4535,7 +4529,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4546,7 +4540,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->subslices_mask[s] =
INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (IS_GEN9_LP(dev_priv)) {
-- 
2.15.0

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

[Intel-gfx] [PATCH v2 4/9] drm/i915: fix register naming

[Lionel Landwerlin]

This name was added with the whitelisting of registers for building up OA
configs. It is contained in a range gen8 whitelist :

   addr >= RPM_CONFIG0.reg && addr <= NOA_CONFIG(8).reg

Hence why the name isn't used anywhere.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_reg.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee4941a1df20..d27092ec4f74 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1118,7 +1118,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define RPM_CONFIG1_MMIO(0x0D04)
 
 /* RPC unit config (Gen8+) */
-#define RPM_CONFIG _MMIO(0x0D08)
+#define RPC_CONFIG _MMIO(0x0D08)
 
 /* NOA (HSW) */
 #define HSW_MBVID2_NOA0_MMIO(0x9E80)
-- 
2.15.0

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

[Intel-gfx] [PATCH v2 0/9] i915: Cannonlake perf support

[Lionel Landwerlin]

Hi,

This is a change only on patch 8 (topology) where it makes the uapi a
bit simpler to use and also leaves some room for future queries (one
of the case could be query on media capabilities, where different
Gens/GT have different numbers of media rings).

Cheers,

Lionel Landwerlin (9):
  drm/i915/perf: complete whitelisting for OA programming on HSW
  drm/i915/perf: add support for Coffeelake GT3
  drm/i915/perf: refactor perf setup
  drm/i915: fix register naming
  drm/i915/perf: enable perf support on CNL
  drm/i915: expose command stream timestamp frequency to userspace
  drm/i915/perf: reuse timestamp frequency from device info
  drm/i915: expose eu topology to userspace
  drm/i915/debugfs: reuse max slice/subslices already stored in sseu

 drivers/gpu/drm/i915/Makefile|   4 +-
 drivers/gpu/drm/i915/i915_debugfs.c  |  52 +++---
 drivers/gpu/drm/i915/i915_drv.c  |  72 -
 drivers/gpu/drm/i915/i915_drv.h  |  28 +++-
 drivers/gpu/drm/i915/i915_oa_cflgt3.c| 109 +
 drivers/gpu/drm/i915/i915_oa_cflgt3.h|  34 
 drivers/gpu/drm/i915/i915_oa_cnl.c   | 121 ++
 drivers/gpu/drm/i915/i915_oa_cnl.h   |  34 
 drivers/gpu/drm/i915/i915_perf.c | 105 +++-
 drivers/gpu/drm/i915/i915_reg.h  |  42 -
 drivers/gpu/drm/i915/intel_device_info.c | 270 +--
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 include/uapi/drm/i915_drm.h  |  64 
 14 files changed, 813 insertions(+), 126 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_cflgt3.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_cflgt3.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_cnl.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_cnl.h

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

[Intel-gfx] [PATCH v2 6/9] drm/i915: expose command stream timestamp frequency to userspace

[Lionel Landwerlin]

We use to have this fixed per generation, but starting with CNL userspace
cannot tell just off the PCI ID. Let's make this information available. This
is particularly useful for performance monitoring where much of the
normalization work is done using those timestamps (this include pipeline
statistics in both GL & Vulkan as well as OA reports).

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +
 drivers/gpu/drm/i915/i915_drv.c  |  3 +
 drivers/gpu/drm/i915/i915_drv.h  |  2 +
 drivers/gpu/drm/i915/i915_reg.h  | 21 +++
 drivers/gpu/drm/i915/intel_device_info.c | 99 
 include/uapi/drm/i915_drm.h  |  6 ++
 6 files changed, 133 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 39883cd915db..0897fd616a1f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3246,6 +3246,8 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
   yesno(dev_priv->gt.awake));
seq_printf(m, "Global active requests: %d\n",
   dev_priv->gt.active_requests);
+   seq_printf(m, "CS timestamp frequency: %llu\n",
+  dev_priv->info.cs_timestamp_frequency);
 
p = drm_seq_file_printer(m);
for_each_engine(engine, dev_priv, id)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e7e9e061073b..fdd23e79fb46 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -416,6 +416,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
if (!value)
return -ENODEV;
break;
+   case I915_PARAM_CS_TIMESTAMP_FREQUENCY:
+   value = INTEL_INFO(dev_priv)->cs_timestamp_frequency;
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6cb7cd7f9420..4e804aaeaae1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -886,6 +886,8 @@ struct intel_device_info {
/* Slice/subslice/EU info */
struct sseu_dev_info sseu;
 
+   uint64_t cs_timestamp_frequency;
+
struct color_luts {
u16 degamma_lut_size;
u16 gamma_lut_size;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a2223f01ee2a..f392f28f2cfa 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1119,9 +1119,24 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 
 /* RPM unit config (Gen8+) */
 #define RPM_CONFIG0_MMIO(0x0D00)
+#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT 3
+#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK  (1 << 
GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
+#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ  0
+#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ1
+#define  GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT   1
+#define  GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK(0x3 << 
GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT)
+
 #define RPM_CONFIG1_MMIO(0x0D04)
 #define  GEN10_GT_NOA_ENABLE  (1 << 9)
 
+/* GPM unit config (assuming Gen8+, documentation is fuzzy...) */
+#define GEN8_CTC_MODE  _MMIO(0xA26C)
+#define  GEN8_CTC_SOURCE_PARAMETER_MASK 1
+#define  GEN8_CTC_SOURCE_CRYSTAL_CLOCK 0
+#define  GEN8_CTC_SOURCE_DIVIDE_LOGIC  1
+#define  GEN8_CTC_SHIFT_PARAMETER_SHIFT1
+#define  GEN8_CTC_SHIFT_PARAMETER_MASK (0x3 << GEN8_CTC_SHIFT_PARAMETER_SHIFT)
+
 /* RPC unit config (Gen8+) */
 #define RPC_CONFIG _MMIO(0x0D08)
 
@@ -8865,6 +8880,12 @@ enum skl_power_gate {
 #define ILK_TIMESTAMP_HI   _MMIO(0x70070)
 #define IVB_TIMESTAMP_CTR  _MMIO(0x44070)
 
+#define GEN8_TIMESTAMP_OVERRIDE_MMIO(0x44074)
+#define  GEN8_TIMESTAMP_OVERRIDE_US_COUNTER_SHIFT  0
+#define  GEN8_TIMESTAMP_OVERRIDE_US_COUNTER_MASK   0x3ff
+#define  GEN8_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_SHIFT  12
+#define  GEN8_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_MASK   (0xf << 12)
+
 #define _PIPE_FRMTMSTMP_A  0x70048
 #define PIPE_FRMTMSTMP(pipe)   \
_MMIO_PIPE2(pipe, _PIPE_FRMTMSTMP_A)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index db03d179fc85..9b71a9b6d80e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -329,6 +329,100 @@ static void broadwell_sseu_info_init(struct 
drm_i915_private *dev_priv)
sseu->has_eu_pg = 0;
 }
 
+static u64 read_timestamp_frequency_from_divide(struct drm_i915_private 
*dev_priv)
+{
+   u32 ts_override = I915_READ(GEN8_TIMESTAMP_OVERRIDE);
+   u64

[Intel-gfx] [PATCH v2 7/9] drm/i915/perf: reuse timestamp frequency from device info

[Lionel Landwerlin]

Now that we have this stored in the device info, we can drop it from perf
part of the driver.

Note that this requires to init perf after we've computed the frequency,
hence why we move i915_perf_init() from i915_driver_init_early() to after
intel_device_info_runtime_init().

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.c  |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/i915_perf.c | 32 +++-
 3 files changed, 5 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index fdd23e79fb46..b8e9aca46692 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -929,8 +929,6 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
 
intel_detect_preproduction_hw(dev_priv);
 
-   i915_perf_init(dev_priv);
-
return 0;
 
 err_irq:
@@ -1094,6 +1092,8 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
 
intel_sanitize_options(dev_priv);
 
+   i915_perf_init(dev_priv);
+
ret = i915_ggtt_probe_hw(dev_priv);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4e804aaeaae1..5c4d09a98e88 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2615,7 +2615,6 @@ struct drm_i915_private {
 
bool periodic;
int period_exponent;
-   int timestamp_frequency;
 
struct i915_oa_config test_config;
 
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 00be015e01df..1f9d86b5cad4 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2692,7 +2692,7 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
 static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)
 {
return div_u64(10ULL * (2ULL << exponent),
-  dev_priv->perf.oa.timestamp_frequency);
+  INTEL_INFO(dev_priv)->cs_timestamp_frequency);
 }
 
 /**
@@ -3415,8 +3415,6 @@ static struct ctl_table dev_root[] = {
  */
 void i915_perf_init(struct drm_i915_private *dev_priv)
 {
-   dev_priv->perf.oa.timestamp_frequency = 0;
-
if (IS_HASWELL(dev_priv)) {
dev_priv->perf.oa.ops.is_valid_b_counter_reg =
gen7_is_valid_b_counter_addr;
@@ -3432,8 +3430,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.oa_hw_tail_read =
gen7_oa_hw_tail_read;
 
-   dev_priv->perf.oa.timestamp_frequency = 1250;
-
dev_priv->perf.oa.oa_formats = hsw_oa_formats;
} else if (i915_modparams.enable_execlists) {
/* Note: that although we could theoretically also support the
@@ -3477,23 +3473,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
 
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
}
-
-   switch (dev_priv->info.platform) {
-   case INTEL_BROADWELL:
-   dev_priv->perf.oa.timestamp_frequency = 
1250;
-   break;
-   case INTEL_BROXTON:
-   case INTEL_GEMINILAKE:
-   dev_priv->perf.oa.timestamp_frequency = 
1920;
-   break;
-   case INTEL_SKYLAKE:
-   case INTEL_KABYLAKE:
-   case INTEL_COFFEELAKE:
-   dev_priv->perf.oa.timestamp_frequency = 
1200;
-   break;
-   default:
-   break;
-   }
} else if (IS_GEN10(dev_priv)) {
dev_priv->perf.oa.ops.is_valid_b_counter_reg =
gen7_is_valid_b_counter_addr;
@@ -3509,15 +3488,10 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
 
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
-
-   /* Default frequency, although we need to read it from
-* the register as it might vary between parts.
-*/
-   dev_priv->perf.oa.timestamp_frequency = 1200;
}
}
 
-   if (dev_priv->perf.oa.timestamp_frequency) {
+   if (dev_priv->perf.oa.ops.enable_metric_set) {
hrtimer_init(&dev_priv->perf.oa.poll_check_timer,
CLOCK_MONOTONIC, HRTIMER_MODE_REL);
dev_priv->perf.oa.poll_check_timer.function = 
oa_poll_check_timer_cb;
@@ -3528,7 +3502,7 @@ 

[Intel-gfx] [PATCH v2 5/9] drm/i915/perf: enable perf support on CNL

[Lionel Landwerlin]

This adds new registers to the whitelist to configs emitted from userspace.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_oa_cnl.c | 121 +
 drivers/gpu/drm/i915/i915_oa_cnl.h |  34 +++
 drivers/gpu/drm/i915/i915_perf.c   |  41 -
 drivers/gpu/drm/i915/i915_reg.h|   5 ++
 5 files changed, 202 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_cnl.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_cnl.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3c419455b0af..f7afd44214b5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -163,7 +163,8 @@ i915-y += i915_perf.o \
  i915_oa_kblgt3.o \
  i915_oa_glk.o \
  i915_oa_cflgt2.o \
- i915_oa_cflgt3.o
+ i915_oa_cflgt3.o \
+ i915_oa_cnl.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_oa_cnl.c 
b/drivers/gpu/drm/i915/i915_oa_cnl.c
new file mode 100644
index ..ff0ac3627cc4
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_cnl.c
@@ -0,0 +1,121 @@
+/*
+ * Autogenerated file by GPU Top : https://github.com/rib/gputop
+ * DO NOT EDIT manually!
+ *
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+
+#include "i915_drv.h"
+#include "i915_oa_cnl.h"
+
+static const struct i915_oa_reg b_counter_config_test_oa[] = {
+   { _MMIO(0x2740), 0x },
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0xf080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0xf080 },
+   { _MMIO(0x2770), 0x0004 },
+   { _MMIO(0x2774), 0x },
+   { _MMIO(0x2778), 0x0003 },
+   { _MMIO(0x277c), 0x },
+   { _MMIO(0x2780), 0x0007 },
+   { _MMIO(0x2784), 0x },
+   { _MMIO(0x2788), 0x0012 },
+   { _MMIO(0x278c), 0xfff7 },
+   { _MMIO(0x2790), 0x0012 },
+   { _MMIO(0x2794), 0xffcf },
+   { _MMIO(0x2798), 0x00100082 },
+   { _MMIO(0x279c), 0xffef },
+   { _MMIO(0x27a0), 0x001000c2 },
+   { _MMIO(0x27a4), 0xffe7 },
+   { _MMIO(0x27a8), 0x0011 },
+   { _MMIO(0x27ac), 0xffe7 },
+};
+
+static const struct i915_oa_reg flex_eu_config_test_oa[] = {
+};
+
+static const struct i915_oa_reg mux_config_test_oa[] = {
+   { _MMIO(0xd04), 0x0200 },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x1706 },
+   { _MMIO(0x9840), 0x },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x13034000 },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x07060066 },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x0506 },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x0f080040 },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x07091000 },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x0f041000 },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x1d004000 },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x3500 },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x4900 },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x3d00 },
+   { _MMIO(0x9884), 0x0007 },
+   { _MMIO(0x9888), 0x3100 },
+};
+
+static ssize_t
+show_test_oa_id(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   return sprintf(buf, "1\n");
+}
+
+void
+i915_perf_load_test_config_cnl(struct drm_i915_private *dev_priv)
+{
+   strncpy(dev_priv->perf.oa.test_config.uuid,
+   "db41edd4-d8e7-4730-ad11-b9a2d6833503",
+   UUID_STRING_LEN);
+   dev_priv->perf.oa.test_con

[Intel-gfx] [PATCH v2 2/9] drm/i915/perf: add support for Coffeelake GT3

[Lionel Landwerlin]

We can enable GT3 as well as GT2.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/Makefile |   3 +-
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_oa_cflgt3.c | 109 ++
 drivers/gpu/drm/i915/i915_oa_cflgt3.h |  34 +++
 drivers/gpu/drm/i915/i915_perf.c  |   3 +
 5 files changed, 150 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_cflgt3.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_cflgt3.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1bbc5440db40..3c419455b0af 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -162,7 +162,8 @@ i915-y += i915_perf.o \
  i915_oa_kblgt2.o \
  i915_oa_kblgt3.o \
  i915_oa_glk.o \
- i915_oa_cflgt2.o
+ i915_oa_cflgt2.o \
+ i915_oa_cflgt3.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 72bb5b51035a..6cb7cd7f9420 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3053,6 +3053,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 (INTEL_DEVID(dev_priv) & 0x00F0) == 0x00A0)
 #define IS_CFL_GT2(dev_priv)   (IS_COFFEELAKE(dev_priv) && \
 (dev_priv)->info.gt == 2)
+#define IS_CFL_GT3(dev_priv)   (IS_COFFEELAKE(dev_priv) && \
+(dev_priv)->info.gt == 3)
 
 #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
 
diff --git a/drivers/gpu/drm/i915/i915_oa_cflgt3.c 
b/drivers/gpu/drm/i915/i915_oa_cflgt3.c
new file mode 100644
index ..42ff06fe54a3
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_cflgt3.c
@@ -0,0 +1,109 @@
+/*
+ * Autogenerated file by GPU Top : https://github.com/rib/gputop
+ * DO NOT EDIT manually!
+ *
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+
+#include "i915_drv.h"
+#include "i915_oa_cflgt3.h"
+
+static const struct i915_oa_reg b_counter_config_test_oa[] = {
+   { _MMIO(0x2740), 0x },
+   { _MMIO(0x2744), 0x0080 },
+   { _MMIO(0x2714), 0xf080 },
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2724), 0xf080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2770), 0x0004 },
+   { _MMIO(0x2774), 0x },
+   { _MMIO(0x2778), 0x0003 },
+   { _MMIO(0x277c), 0x },
+   { _MMIO(0x2780), 0x0007 },
+   { _MMIO(0x2784), 0x },
+   { _MMIO(0x2788), 0x0012 },
+   { _MMIO(0x278c), 0xfff7 },
+   { _MMIO(0x2790), 0x0012 },
+   { _MMIO(0x2794), 0xffcf },
+   { _MMIO(0x2798), 0x00100082 },
+   { _MMIO(0x279c), 0xffef },
+   { _MMIO(0x27a0), 0x001000c2 },
+   { _MMIO(0x27a4), 0xffe7 },
+   { _MMIO(0x27a8), 0x0011 },
+   { _MMIO(0x27ac), 0xffe7 },
+};
+
+static const struct i915_oa_reg flex_eu_config_test_oa[] = {
+};
+
+static const struct i915_oa_reg mux_config_test_oa[] = {
+   { _MMIO(0x9840), 0x0080 },
+   { _MMIO(0x9888), 0x1181 },
+   { _MMIO(0x9888), 0x07810013 },
+   { _MMIO(0x9888), 0x1f81 },
+   { _MMIO(0x9888), 0x1d81 },
+   { _MMIO(0x9888), 0x1b930040 },
+   { _MMIO(0x9888), 0x07e54000 },
+   { _MMIO(0x9888), 0x1f908000 },
+   { _MMIO(0x9888), 0x1190 },
+   { _MMIO(0x9888), 0x3790 },
+   { _MMIO(0x9888), 0x5390 },
+   { _MMIO(0x9888), 0x4590 },
+   { _MMIO(0x9888), 0x3390 },
+};
+
+static ssize_t
+show_test_oa_id(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+   return sprintf(buf, "1\n");
+}
+
+void
+i915_perf_load_test_config_cflgt3(struct drm_i915_private *dev_priv)
+{

Re: [Intel-gfx] [PATCH] drm/i915: Remove support for legacy debugfs crc interface

[Ville Syrjälä]

On Thu, Nov 02, 2017 at 05:19:07PM +0200, Jani Nikula wrote:
> On Thu, 02 Nov 2017, Ville Syrjälä  wrote:
> > On Thu, Nov 02, 2017 at 02:56:51PM +0100, Maarten Lankhorst wrote:
> >> This interface is deprecated, and has been replaced by the upstream
> >> drm crc interface.
> >
> > Before we nuke this I would like to see an option in the new interface
> > to not filter out the "bad" CRCs. When analyzing how the hardware
> > behaves seeing every CRC can be valuable. And I'm not at all convinced
> > we should be dropping as many CRCs as we are currently.
> 
> I'm not against it, but do you have a concrete proposal on how that
> option would look like?

Some kind of of filter_bad_crcs file with a bool value perhaps?

> 
> BR,
> Jani.
> 
> >
> >> 
> >> Signed-off-by: Maarten Lankhorst 
> >> Cc: Tomi Sarvela 
> >> Cc: Petri Latvala 
> >> Cc: Jani Nikula 
> >> ---
> >>  drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
> >>  drivers/gpu/drm/i915/i915_drv.h   |  10 -
> >>  drivers/gpu/drm/i915/i915_irq.c   |  79 ++
> >>  drivers/gpu/drm/i915/intel_drv.h  |   2 -
> >>  drivers/gpu/drm/i915/intel_pipe_crc.c | 446 
> >> --
> >>  5 files changed, 23 insertions(+), 521 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> >> b/drivers/gpu/drm/i915/i915_debugfs.c
> >> index 7efe57c0703e..a362370e5a68 100644
> >> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >> @@ -4991,7 +4991,6 @@ static const struct i915_debugfs_files {
> >>{"i915_gpu_info", &i915_gpu_info_fops},
> >>  #endif
> >>{"i915_next_seqno", &i915_next_seqno_fops},
> >> -  {"i915_display_crc_ctl", &i915_display_crc_ctl_fops},
> >>{"i915_pri_wm_latency", &i915_pri_wm_latency_fops},
> >>{"i915_spr_wm_latency", &i915_spr_wm_latency_fops},
> >>{"i915_cur_wm_latency", &i915_cur_wm_latency_fops},
> >> @@ -5008,7 +5007,7 @@ int i915_debugfs_register(struct drm_i915_private 
> >> *dev_priv)
> >>  {
> >>struct drm_minor *minor = dev_priv->drm.primary;
> >>struct dentry *ent;
> >> -  int ret, i;
> >> +  int i;
> >>  
> >>ent = debugfs_create_file("i915_forcewake_user", S_IRUSR,
> >>  minor->debugfs_root, to_i915(minor->dev),
> >> @@ -5016,10 +5015,6 @@ int i915_debugfs_register(struct drm_i915_private 
> >> *dev_priv)
> >>if (!ent)
> >>return -ENOMEM;
> >>  
> >> -  ret = intel_pipe_crc_create(minor);
> >> -  if (ret)
> >> -  return ret;
> >> -
> >>for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++) {
> >>ent = debugfs_create_file(i915_debugfs_files[i].name,
> >>  S_IRUGO | S_IWUSR,
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index d37fd11908d0..f4290c9739e1 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -1948,19 +1948,9 @@ enum intel_pipe_crc_source {
> >>INTEL_PIPE_CRC_SOURCE_MAX,
> >>  };
> >>  
> >> -struct intel_pipe_crc_entry {
> >> -  uint32_t frame;
> >> -  uint32_t crc[5];
> >> -};
> >> -
> >>  #define INTEL_PIPE_CRC_ENTRIES_NR 128
> >>  struct intel_pipe_crc {
> >>spinlock_t lock;
> >> -  bool opened;/* exclusive access to the result file */
> >> -  struct intel_pipe_crc_entry *entries;
> >> -  enum intel_pipe_crc_source source;
> >> -  int head, tail;
> >> -  wait_queue_head_t wq;
> >>int skipped;
> >>  };
> >>  
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index ff00e462697a..be119cb567a4 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -1613,69 +1613,34 @@ static void display_pipe_crc_irq_handler(struct 
> >> drm_i915_private *dev_priv,
> >> uint32_t crc4)
> >>  {
> >>struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
> >> -  struct intel_pipe_crc_entry *entry;
> >>struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> >> -  struct drm_driver *driver = dev_priv->drm.driver;
> >>uint32_t crcs[5];
> >> -  int head, tail;
> >>  
> >>spin_lock(&pipe_crc->lock);
> >> -  if (pipe_crc->source) {
> >> -  if (!pipe_crc->entries) {
> >> -  spin_unlock(&pipe_crc->lock);
> >> -  DRM_DEBUG_KMS("spurious interrupt\n");
> >> -  return;
> >> -  }
> >> -
> >> -  head = pipe_crc->head;
> >> -  tail = pipe_crc->tail;
> >> -
> >> -  if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
> >> -  spin_unlock(&pipe_crc->lock);
> >> -  DRM_ERROR("CRC buffer overflowing\n");
> >> -  return;
> >> -  }
> >> -
> >> -  entry = &pipe_crc->entries[head];
> >> -
> >> -  entry->frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
> >> -  entry->crc[0] = crc0;
> >> -   

[Intel-gfx] ✗ Fi.CI.IGT: warning for tests/debugfs_test: Pretty print subdirectories

[Patchwork]

== Series Details ==

Series: tests/debugfs_test: Pretty print subdirectories
URL   : https://patchwork.freedesktop.org/series/33045/
State : warning

== Summary ==

Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-WARN (shard-hsw) fdo#102707 +1
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-A:
pass   -> DMESG-WARN (shard-hsw)
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw)
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb565-draw-blt:
pass   -> SKIP   (shard-hsw)
Subgroup fbc-1p-primscrn-cur-indfb-draw-mmap-wc:
pass   -> SKIP   (shard-hsw)

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

shard-hswtotal:2539 pass:1429 dwarn:2   dfail:0   fail:9   skip:1099 
time:9297s

== Logs ==

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

Re: [Intel-gfx] [PATCH v8 6/6] drm/i915/guc : Decouple logs and ADS from submission

[Sujaritha]

On 11/02/2017 02:23 AM, Sagar Arun Kamble wrote:



On 10/25/2017 9:49 PM, Michal Wajdeczko wrote:
On Tue, 24 Oct 2017 19:21:25 +0200, Sujaritha Sundaresan 
 wrote:



The Additional Data Struct (ADS) contains objects that are required by
guc post FW load and are not necessarily submission-only (although 
that's
our current only use-case). If in the future we load GuC with 
submission

disabled to use some other GuC feature we might still end up requiring
something inside the ADS, so it makes more sense for them to be always
created if GuC is loaded.

Similarly, we still want to access GuC logs even if GuC submission is
disable to debug issues with GuC loading or with wathever we're using
GuC for.

To make a concrete example, the pages used by GuC to save state during
suspend are allocated as part of the ADS.

v3: Group initialization of GuC objects

v2: Decoupling ADS together with logs

v3: Re-factoring code as per review (Michal)

v4: Rebase

v5: Separating group object initialization into next patch
    Clarifying commit message

v6: Reverting to goto err format (Michal)
    Moved guc_ads functions to dedicated file
    Rebase

v7: Rebase

v8: Applying review comments (Michal)

Signed-off-by: Sujaritha Sundaresan 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_guc_submission.c | 139 
+--
 drivers/gpu/drm/i915/intel_guc_ads.c   | 149 
+

 drivers/gpu/drm/i915/intel_guc_ads.h   |  33 +++
 drivers/gpu/drm/i915/intel_uc.c    |  38 +++-
 5 files changed, 220 insertions(+), 140 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_guc_ads.c
 create mode 100644 drivers/gpu/drm/i915/intel_guc_ads.h

diff --git a/drivers/gpu/drm/i915/Makefile 
b/drivers/gpu/drm/i915/Makefile

index 6c3b048..d7ce07e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -62,6 +62,7 @@ i915-y += i915_cmd_parser.o \
 i915-y += intel_uc.o \
   intel_uc_fw.o \
   intel_guc.o \
+  intel_guc_ads.o \
   intel_guc_ct.o \
   intel_guc_log.o \
   intel_guc_fw.o \
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c

index a2e8114..3a56429 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -72,13 +72,6 @@
  * ELSP context descriptor dword into Work Item.
  * See guc_wq_item_append()
  *
- * ADS:
- * The Additional Data Struct (ADS) has pointers for different 
buffers used by
- * the GuC. One single gem object contains the ADS struct itself 
(guc_ads), the
- * scheduling policies (guc_policies), a structure describing a 
collection of
- * register sets (guc_mmio_reg_state) and some extra pages for the 
GuC to save

- * its internal state for sleep.
- *
  */
static inline bool is_high_priority(struct i915_guc_client* client)
@@ -855,115 +848,6 @@ static void guc_client_free(struct 
i915_guc_client *client)

 kfree(client);
 }
-static void guc_policy_init(struct guc_policy *policy)
-{
-    policy->execution_quantum = POLICY_DEFAULT_EXECUTION_QUANTUM_US;
-    policy->preemption_time = POLICY_DEFAULT_PREEMPTION_TIME_US;
-    policy->fault_time = POLICY_DEFAULT_FAULT_TIME_US;
-    policy->policy_flags = 0;
-}
-
-static void guc_policies_init(struct guc_policies *policies)
-{
-    struct guc_policy *policy;
-    u32 p, i;
-
-    policies->dpc_promote_time = POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
-    policies->max_num_work_items = POLICY_MAX_NUM_WI;
-
-    for (p = 0; p < GUC_CLIENT_PRIORITY_NUM; p++) {
-    for (i = GUC_RENDER_ENGINE; i < GUC_MAX_ENGINES_NUM; i++) {
-    policy = &policies->policy[p][i];
-
-    guc_policy_init(policy);
-    }
-    }
-
-    policies->is_valid = 1;
-}
-
-/*
- * The first 80 dwords of the register state context, containing the
- * execlists and ppgtt registers.
- */
-#define LR_HW_CONTEXT_SIZE    (80 * sizeof(u32))
-
-static int guc_ads_create(struct intel_guc *guc)
-{
-    struct drm_i915_private *dev_priv = guc_to_i915(guc);
-    struct i915_vma *vma;
-    struct page *page;
-    /* The ads obj includes the struct itself and buffers passed to 
GuC */

-    struct {
-    struct guc_ads ads;
-    struct guc_policies policies;
-    struct guc_mmio_reg_state reg_state;
-    u8 reg_state_buffer[GUC_S3_SAVE_SPACE_PAGES * PAGE_SIZE];
-    } __packed *blob;
-    struct intel_engine_cs *engine;
-    enum intel_engine_id id;
-    const u32 skipped_offset = LRC_HEADER_PAGES * PAGE_SIZE;
-    const u32 skipped_size = LRC_PPHWSP_SZ * PAGE_SIZE + 
LR_HW_CONTEXT_SIZE;

-    u32 base;
-
-    GEM_BUG_ON(guc->ads_vma);
-
-    vma = intel_guc_allocate_vma(guc, PAGE_ALIGN(sizeof(*blob)));
-    if (IS_ERR(vma))
-    return PTR_ERR(vma);
-
-    guc->ads_vma = vma;
-
-    page = i915_vma_first_page(vma);
-    blob = kmap(page);
-
-    /*

[Intel-gfx] ✓ Fi.CI.BAT: success for kms_atomic_transition: Split out modeset tests on internal panels

[Patchwork]

== Series Details ==

Series: kms_atomic_transition: Split out modeset tests on internal panels
URL   : https://patchwork.freedesktop.org/series/33052/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
6d16875736b9fb1ebf4bf3dc5a941f9e431d58e0 lib/igt_debugfs: Remove support for 
legacy CRC api.

with latest DRM-Tip kernel build CI_DRM_3309
fca2506bc5d4 drm-tip: 2017y-11m-02d-13h-10m-58s UTC integration manifest

Testlist changes:
+igt@kms_atomic_transition@plane-all-modeset-transition-fencing-internal-panels-fast
+igt@kms_atomic_transition@plane-all-modeset-transition-fencing-internal-panels-slow
+igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels-fast
+igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels-slow

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6700k) fdo#103546 +1

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:446s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:461s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:554s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:508s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:504s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:513s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:491s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:551s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:635s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:431s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:594s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:497s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:435s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:430s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:488s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:575s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:585s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:574s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:601s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:649s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:521s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:464s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:577s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:434s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Set up mocs tables before restarting the engines

[Patchwork]

== Series Details ==

Series: drm/i915: Set up mocs tables before restarting the engines
URL   : https://patchwork.freedesktop.org/series/33051/
State : warning

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-B:
pass   -> DMESG-WARN (shard-hsw)
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw)

shard-hswtotal:2539 pass:1432 dwarn:2   dfail:0   fail:8   skip:1097 
time:9295s

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Force the switch to the i915->kernel_context

[Chris Wilson]

Quoting Mika Kuoppala (2017-11-02 15:40:50)
> Chris Wilson  writes:
> 
> > In the next few patches, we will have a hard requirement that we emit a
> > context-switch to the perma-pinned i915->kernel_context (so that we can
> > save the HW state using that context-switch). As the first context
> > itself may be classed as a kernel context, we want to be explicit in our
> > comparison. For an extra-layer of finesse, we can check the last
> > unretired context on the engine; as well as the last retired context
> > when idle.
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/intel_engine_cs.c | 16 ++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index ddbe5c9bf45a..c15e288bed02 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -1587,8 +1587,20 @@ bool intel_engines_are_idle(struct drm_i915_private 
> > *dev_priv)
> >  
> >  bool intel_engine_has_kernel_context(const struct intel_engine_cs *engine)
> >  {
> > - return (!engine->last_retired_context ||
> > - i915_gem_context_is_kernel(engine->last_retired_context));
> > + const struct i915_gem_context *kctx = engine->i915->kernel_context;
> > + struct drm_i915_gem_request *rq;
> > +
> > + lockdep_assert_held(&engine->i915->drm.struct_mutex);
> > +
> > + /* An unretired request? */
> > + rq = __i915_gem_active_peek(&engine->timeline->last_request);
> > + if (rq)
> > + return rq->ctx == kctx;
> > +
> > + if (!engine->last_retired_context)
> > + return true;
> > +
> > + return engine->last_retired_context == kctx;
> 
> 
> Conside that we would have intel_engine_loaded_context(engine)
> {
> rq = __i915_gem_active_peek(&engine->timeline->last_request);
> if (rq)
>return rq->ctx;
> 
> if (engine->last_retired_context)
> return engine->last_retired_context;
> 
> return NULL;
> }
> 
> and then have simple intel_engine_has_kernel_context_loaded()

Could, just needs refinement on the name first. I'll keep one clumsy
name for the moment ;)
 
> Also further on the patch series we do switch to kernel context
> on init, to grab the hw state. So would it be possible to completely
> get rid of notion that !engine->last_retired_context means kernel
> context? I would rather assert that we have always last retired
> context after init and resume.

Yup, that seems possible.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Force the switch to the i915->kernel_context

[Mika Kuoppala]

Chris Wilson  writes:

> In the next few patches, we will have a hard requirement that we emit a
> context-switch to the perma-pinned i915->kernel_context (so that we can
> save the HW state using that context-switch). As the first context
> itself may be classed as a kernel context, we want to be explicit in our
> comparison. For an extra-layer of finesse, we can check the last
> unretired context on the engine; as well as the last retired context
> when idle.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index ddbe5c9bf45a..c15e288bed02 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1587,8 +1587,20 @@ bool intel_engines_are_idle(struct drm_i915_private 
> *dev_priv)
>  
>  bool intel_engine_has_kernel_context(const struct intel_engine_cs *engine)
>  {
> - return (!engine->last_retired_context ||
> - i915_gem_context_is_kernel(engine->last_retired_context));
> + const struct i915_gem_context *kctx = engine->i915->kernel_context;
> + struct drm_i915_gem_request *rq;
> +
> + lockdep_assert_held(&engine->i915->drm.struct_mutex);
> +
> + /* An unretired request? */
> + rq = __i915_gem_active_peek(&engine->timeline->last_request);
> + if (rq)
> + return rq->ctx == kctx;
> +
> + if (!engine->last_retired_context)
> + return true;
> +
> + return engine->last_retired_context == kctx;


Conside that we would have intel_engine_loaded_context(engine)
{
rq = __i915_gem_active_peek(&engine->timeline->last_request);
if (rq)
   return rq->ctx;

if (engine->last_retired_context)
return engine->last_retired_context;

return NULL;
}

and then have simple intel_engine_has_kernel_context_loaded()

Also further on the patch series we do switch to kernel context
on init, to grab the hw state. So would it be possible to completely
get rid of notion that !engine->last_retired_context means kernel
context? I would rather assert that we have always last retired
context after init and resume.

-Mika

>  }
>  
>  void intel_engines_reset_default_submission(struct drm_i915_private *i915)
> -- 
> 2.15.0
___
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: Check if the stolen memory "reserved" area is enabled or not

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Check if the stolen memory 
"reserved" area is enabled or not
URL   : https://patchwork.freedesktop.org/series/33060/
State : success

== Summary ==

Series 33060v1 series starting with [1/3] drm/i915: Check if the stolen memory 
"reserved" area is enabled or not
https://patchwork.freedesktop.org/api/1.0/series/33060/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6700k) fdo#103546 +1

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:453s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:379s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:553s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:511s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:515s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:512s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:495s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:598s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:436s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:272s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:586s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:492s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:428s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:431s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:501s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:577s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:588s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:571s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:599s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:651s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:518s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:507s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:462s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:571s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:424s

fca2506bc5d492609e3f1b6e59d667e376a1eb3f drm-tip: 2017y-11m-02d-13h-10m-58s UTC 
integration manifest
8c03bce335c0 drm/i915: Use ELK stolen memory reserved detection for ILK
cc31312966c2 drm/i915: Make the report about a bogus stolen reserved area an 
error
f1ec6e9db4ef drm/i915: Check if the stolen memory "reserved" area is enabled or 
not

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Move GT powersaving init to i915_gem_init()

[Sagar Arun Kamble]

On 11/2/2017 8:25 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2017-11-02 14:35:17)


On 11/2/2017 6:12 PM, Chris Wilson wrote:

GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().

Signed-off-by: Chris Wilson 
---
   drivers/gpu/drm/i915/i915_gem.c  | 7 ++-
   drivers/gpu/drm/i915/intel_display.c | 2 --
   drivers/gpu/drm/i915/intel_pm.c  | 2 --
   3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9470ba0c1930..e36a3a840552 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5017,6 +5017,12 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
   goto out_unlock;
   
   ret = i915_gem_init_hw(dev_priv);

+ if (ret)
+ goto out_unlock;
+
+ intel_init_gt_powersave(dev_priv);

Can this be moved before gem_init_hw. That way SLPC can get the initial
platform RP configuration during uc_init.

Not at this point in the series, I would argue. Once we remove
intel_autoenable_gt_powersave(), it looks free to be moved before
i915_gem_init().

Or we split out the autoenable to here (or just after) and then remove
it. Or you just move init_gt_powersave() a bit earlier in a jiffie.
-Chris

Ah. right. Will move later.

Thanks,
Sagar

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Lib: Move __gem_context_create to common ioctl wrapper library. (rev3)

[Patchwork]

== Series Details ==

Series: Lib: Move __gem_context_create to common ioctl wrapper library. (rev3)
URL   : https://patchwork.freedesktop.org/series/31775/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
6d16875736b9fb1ebf4bf3dc5a941f9e431d58e0 lib/igt_debugfs: Remove support for 
legacy CRC api.

with latest DRM-Tip kernel build CI_DRM_3309
fca2506bc5d4 drm-tip: 2017y-11m-02d-13h-10m-58s UTC integration manifest

No testlist changes.

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_busy:
Subgroup basic-flip-b:
pass   -> INCOMPLETE (fi-glk-1)
Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6700k) fdo#103546 +1

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:453s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:462s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:557s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:279s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:510s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:504s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:508s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:498s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:555s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:606s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:434s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:207  pass:184  dwarn:0   dfail:0   fail:0   skip:22 
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:493s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:431s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:496s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:581s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:585s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:577s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:604s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:654s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:528s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:506s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:460s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:577s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:431s

== Logs ==

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

[Intel-gfx] [PATCH 1/3] drm/i915: Check if the stolen memory "reserved" area is enabled or not

[Ville Syrjala]

From: Ville Syrjälä 

Apparently there are some machines that put semi-sensible looking values
into the stolen "reserved" base and size, except those values are actually
outside the stolen memory. There is a bit in the register which
supposedly could tell us whether the reserved area is even enabled or
not. Let's check for that before we go trusting the base and size.

Cc: Tomi Sarvela 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 30 ++
 drivers/gpu/drm/i915/i915_reg.h|  2 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 03e7abc7e043..44a5dbc8c23b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -294,6 +294,12 @@ static void g4x_get_stolen_reserved(struct 
drm_i915_private *dev_priv,
 ELK_STOLEN_RESERVED);
dma_addr_t stolen_top = dev_priv->mm.stolen_base + ggtt->stolen_size;
 
+   if ((reg_val & G4X_STOLEN_RESERVED_ENABLE) == 0) {
+   *base = 0;
+   *size = 0;
+   return;
+   }
+
*base = (reg_val & G4X_STOLEN_RESERVED_ADDR2_MASK) << 16;
 
WARN_ON((reg_val & G4X_STOLEN_RESERVED_ADDR1_MASK) < *base);
@@ -313,6 +319,12 @@ static void gen6_get_stolen_reserved(struct 
drm_i915_private *dev_priv,
 {
uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
 
+   if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
+   *base = 0;
+   *size = 0;
+   return;
+   }
+
*base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
 
switch (reg_val & GEN6_STOLEN_RESERVED_SIZE_MASK) {
@@ -339,6 +351,12 @@ static void gen7_get_stolen_reserved(struct 
drm_i915_private *dev_priv,
 {
uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
 
+   if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
+   *base = 0;
+   *size = 0;
+   return;
+   }
+
*base = reg_val & GEN7_STOLEN_RESERVED_ADDR_MASK;
 
switch (reg_val & GEN7_STOLEN_RESERVED_SIZE_MASK) {
@@ -359,6 +377,12 @@ static void chv_get_stolen_reserved(struct 
drm_i915_private *dev_priv,
 {
uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
 
+   if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
+   *base = 0;
+   *size = 0;
+   return;
+   }
+
*base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
 
switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
@@ -387,6 +411,12 @@ static void bdw_get_stolen_reserved(struct 
drm_i915_private *dev_priv,
uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
dma_addr_t stolen_top;
 
+   if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
+   *base = 0;
+   *size = 0;
+   return;
+   }
+
stolen_top = dev_priv->mm.stolen_base + ggtt->stolen_size;
 
*base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f0f8f6059652..dc2cbc428d1b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -382,6 +382,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define GEN8_STOLEN_RESERVED_2M(1 << 7)
 #define GEN8_STOLEN_RESERVED_4M(2 << 7)
 #define GEN8_STOLEN_RESERVED_8M(3 << 7)
+#define GEN6_STOLEN_RESERVED_ENABLE(1 << 0)
 
 /* VGA stuff */
 
@@ -3398,6 +3399,7 @@ enum i915_power_well_id {
 #define ELK_STOLEN_RESERVED_MMIO(MCHBAR_MIRROR_BASE + 0x48)
 #define G4X_STOLEN_RESERVED_ADDR1_MASK (0x << 16)
 #define G4X_STOLEN_RESERVED_ADDR2_MASK (0xFFF << 4)
+#define G4X_STOLEN_RESERVED_ENABLE (1 << 0)
 
 /* Memory controller frequency in MCHBAR for Haswell (possible SNB+) */
 #define DCLK _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5e04)
-- 
2.13.6

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

[Intel-gfx] [PATCH 2/3] drm/i915: Make the report about a bogus stolen reserved area an error

[Ville Syrjala]

From: Ville Syrjälä 

Now that we should be properly filtering out the cases when the stolen
reserved area is disabled, let's convert the debug message about a
misplaced reserved area into an error.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 44a5dbc8c23b..4f9377b5f4ae 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -503,9 +503,9 @@ int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
if (reserved_base < dev_priv->mm.stolen_base ||
reserved_base + reserved_size > stolen_top) {
dma_addr_t reserved_top = reserved_base + reserved_size;
-   DRM_DEBUG_KMS("Stolen reserved area [%pad - %pad] outside 
stolen memory [%pad - %pad]\n",
- &reserved_base, &reserved_top,
- &dev_priv->mm.stolen_base, &stolen_top);
+   DRM_ERROR("Stolen reserved area [%pad - %pad] outside stolen 
memory [%pad - %pad]\n",
+ &reserved_base, &reserved_top,
+ &dev_priv->mm.stolen_base, &stolen_top);
return 0;
}
 
-- 
2.13.6

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

[Intel-gfx] [PATCH 3/3] drm/i915: Use ELK stolen memory reserved detection for ILK

[Ville Syrjala]

From: Ville Syrjälä 

While I have no solid proof that ILK follows the ELK path when it
comes to the stolen memory reserved area, there are some hints that
it might be the case. Unfortunately my ILK doesn't have this enabled,
and no way to enable it via the BIOS it seems.

So let's have ILK use the ELK code path, and let's toss in a WARN
into the code to see if we catch anyone with an ILK that has this
enabled to further analyze the situation.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 4f9377b5f4ae..1877ae9a1d9b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -300,6 +300,12 @@ static void g4x_get_stolen_reserved(struct 
drm_i915_private *dev_priv,
return;
}
 
+   /*
+* Whether ILK really reuses the ELK register for this is unclear.
+* Let's see if we catch anyone with this supposedly enabled on ILK.
+*/
+   WARN(IS_GEN5(dev_priv), "ILK stolen reserved found? 0x%08x\n", reg_val);
+
*base = (reg_val & G4X_STOLEN_RESERVED_ADDR2_MASK) << 16;
 
WARN_ON((reg_val & G4X_STOLEN_RESERVED_ADDR1_MASK) < *base);
@@ -466,14 +472,12 @@ int i915_gem_init_stolen(struct drm_i915_private 
*dev_priv)
case 3:
break;
case 4:
-   if (IS_G4X(dev_priv))
-   g4x_get_stolen_reserved(dev_priv,
-   &reserved_base, &reserved_size);
-   break;
+   if (!IS_G4X(dev_priv))
+   break;
+   /* fall through */
case 5:
-   /* Assume the gen6 maximum for the older platforms. */
-   reserved_size = 1024 * 1024;
-   reserved_base = stolen_top - reserved_size;
+   g4x_get_stolen_reserved(dev_priv,
+   &reserved_base, &reserved_size);
break;
case 6:
gen6_get_stolen_reserved(dev_priv,
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove support for legacy debugfs crc interface

[Jani Nikula]

On Thu, 02 Nov 2017, Ville Syrjälä  wrote:
> On Thu, Nov 02, 2017 at 02:56:51PM +0100, Maarten Lankhorst wrote:
>> This interface is deprecated, and has been replaced by the upstream
>> drm crc interface.
>
> Before we nuke this I would like to see an option in the new interface
> to not filter out the "bad" CRCs. When analyzing how the hardware
> behaves seeing every CRC can be valuable. And I'm not at all convinced
> we should be dropping as many CRCs as we are currently.

I'm not against it, but do you have a concrete proposal on how that
option would look like?

BR,
Jani.

>
>> 
>> Signed-off-by: Maarten Lankhorst 
>> Cc: Tomi Sarvela 
>> Cc: Petri Latvala 
>> Cc: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
>>  drivers/gpu/drm/i915/i915_drv.h   |  10 -
>>  drivers/gpu/drm/i915/i915_irq.c   |  79 ++
>>  drivers/gpu/drm/i915/intel_drv.h  |   2 -
>>  drivers/gpu/drm/i915/intel_pipe_crc.c | 446 
>> --
>>  5 files changed, 23 insertions(+), 521 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index 7efe57c0703e..a362370e5a68 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -4991,7 +4991,6 @@ static const struct i915_debugfs_files {
>>  {"i915_gpu_info", &i915_gpu_info_fops},
>>  #endif
>>  {"i915_next_seqno", &i915_next_seqno_fops},
>> -{"i915_display_crc_ctl", &i915_display_crc_ctl_fops},
>>  {"i915_pri_wm_latency", &i915_pri_wm_latency_fops},
>>  {"i915_spr_wm_latency", &i915_spr_wm_latency_fops},
>>  {"i915_cur_wm_latency", &i915_cur_wm_latency_fops},
>> @@ -5008,7 +5007,7 @@ int i915_debugfs_register(struct drm_i915_private 
>> *dev_priv)
>>  {
>>  struct drm_minor *minor = dev_priv->drm.primary;
>>  struct dentry *ent;
>> -int ret, i;
>> +int i;
>>  
>>  ent = debugfs_create_file("i915_forcewake_user", S_IRUSR,
>>minor->debugfs_root, to_i915(minor->dev),
>> @@ -5016,10 +5015,6 @@ int i915_debugfs_register(struct drm_i915_private 
>> *dev_priv)
>>  if (!ent)
>>  return -ENOMEM;
>>  
>> -ret = intel_pipe_crc_create(minor);
>> -if (ret)
>> -return ret;
>> -
>>  for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++) {
>>  ent = debugfs_create_file(i915_debugfs_files[i].name,
>>S_IRUGO | S_IWUSR,
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index d37fd11908d0..f4290c9739e1 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1948,19 +1948,9 @@ enum intel_pipe_crc_source {
>>  INTEL_PIPE_CRC_SOURCE_MAX,
>>  };
>>  
>> -struct intel_pipe_crc_entry {
>> -uint32_t frame;
>> -uint32_t crc[5];
>> -};
>> -
>>  #define INTEL_PIPE_CRC_ENTRIES_NR   128
>>  struct intel_pipe_crc {
>>  spinlock_t lock;
>> -bool opened;/* exclusive access to the result file */
>> -struct intel_pipe_crc_entry *entries;
>> -enum intel_pipe_crc_source source;
>> -int head, tail;
>> -wait_queue_head_t wq;
>>  int skipped;
>>  };
>>  
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index ff00e462697a..be119cb567a4 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -1613,69 +1613,34 @@ static void display_pipe_crc_irq_handler(struct 
>> drm_i915_private *dev_priv,
>>   uint32_t crc4)
>>  {
>>  struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
>> -struct intel_pipe_crc_entry *entry;
>>  struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
>> -struct drm_driver *driver = dev_priv->drm.driver;
>>  uint32_t crcs[5];
>> -int head, tail;
>>  
>>  spin_lock(&pipe_crc->lock);
>> -if (pipe_crc->source) {
>> -if (!pipe_crc->entries) {
>> -spin_unlock(&pipe_crc->lock);
>> -DRM_DEBUG_KMS("spurious interrupt\n");
>> -return;
>> -}
>> -
>> -head = pipe_crc->head;
>> -tail = pipe_crc->tail;
>> -
>> -if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
>> -spin_unlock(&pipe_crc->lock);
>> -DRM_ERROR("CRC buffer overflowing\n");
>> -return;
>> -}
>> -
>> -entry = &pipe_crc->entries[head];
>> -
>> -entry->frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
>> -entry->crc[0] = crc0;
>> -entry->crc[1] = crc1;
>> -entry->crc[2] = crc2;
>> -entry->crc[3] = crc3;
>> -entry->crc[4] = crc4;
>> -
>> -head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
>> -pipe_crc->head = head;
>> -
>> -

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/dmc: DMC 1.04 for Kabylake

[Patchwork]

== Series Details ==

Series: drm/i915/dmc: DMC 1.04 for Kabylake
URL   : https://patchwork.freedesktop.org/series/33022/
State : warning

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-B:
pass   -> DMESG-WARN (shard-hsw)
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw)
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368

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

shard-hswtotal:2539 pass:1431 dwarn:2   dfail:0   fail:9   skip:1097 
time:9313s

== Logs ==

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

Re: [Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6

[Jani Nikula]

On Thu, 02 Nov 2017, Joonas Lahtinen  wrote:
> On Thu, 2017-11-02 at 07:47 -0700, Rodrigo Vivi wrote:
>> On Thu, Nov 02, 2017 at 08:06:29AM +, Jani Nikula wrote:
>> > On Wed, 01 Nov 2017, Rodrigo Vivi  wrote:
>> > > On Wed, Nov 01, 2017 at 04:21:08PM +, Ben Widawsky wrote:
>> > > > On 17-11-01 18:09:47, Joonas Lahtinen wrote:
>> > > > > + Kimmo and Paul
>> > > > > 
>> > > > > On Wed, 2017-11-01 at 07:43 -0700, Ben Widawsky wrote:
>> > > > > > On 17-11-01 14:07:28, Joonas Lahtinen wrote:
>> > > > > > > On Mon, 2017-10-30 at 10:48 -0700, Rodrigo Vivi wrote:
>> > > > > > > > On Mon, Oct 30, 2017 at 01:00:51PM +, David Weinehall 
>> > > > > > > > wrote:
>> > > > > > > > > On Fri, Oct 27, 2017 at 01:57:09PM -0700, Daniele Ceraolo 
>> > > > > > > > > Spurio wrote:
>> > > > > > > > > > 
>> > > > > > > > > > 
>> > > > > > > > > > On 26/10/17 03:32, Chris Wilson wrote:
>> > > > > > > > > > > It has been many years since the last confirmed sighting 
>> > > > > > > > > > > (and fix) of an
>> > > > > > > > > > > RC6 related bug (usually a system hang). Remove the 
>> > > > > > > > > > > parameter to stop
>> > > > > > > > > > > users from setting dangerous values, as they often set 
>> > > > > > > > > > > it during triage
>> > > > > > > > > > > and end up disabling the entire runtime pm instead (the 
>> > > > > > > > > > > option is not a
>> > > > > > > > > > > fine scalpel!).
>> > > > > > > > > > > 
>> > > > > > > > > > > Furthermore, it allows users to set known dangerous 
>> > > > > > > > > > > values which were
>> > > > > > > > > > > intended for testing and not for production use. For 
>> > > > > > > > > > > testing, we can
>> > > > > > > > > > > always patch in the required setting without having to 
>> > > > > > > > > > > expose ourselves
>> > > > > > > > > > > to random abuse.
>> > > > > > > > > > > 
>> > > > > > > > > > > v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and 
>> > > > > > > > > > > document the
>> > > > > > > > > > > lack of ilk support better.
>> > > > > > > > > > > v3: Clear intel_info->rc6p if we don't support rc6 
>> > > > > > > > > > > itself.
>> > > > > > > > > > > 
>> > > > > > > > > > > Signed-off-by: Chris Wilson 
>> > > > > > > > > > > Cc: Rodrigo Vivi 
>> > > > > > > > > > > Cc: Joonas Lahtinen 
>> > > > > > > > > > > Cc: Jani Nikula 
>> > > > > > > > > > > Cc: Imre Deak 
>> > > > > > > > > > > Cc: Daniel Vetter 
>> > > > > > > > > > > Acked-by: Daniel Vetter 
>> > > > > > > > > > > ---
>> > > > > > > > > > 
>> > > > > > > > > > I think that for execution/debug on early silicon we might 
>> > > > > > > > > > still want the
>> > > > > > > > > > ability to turn features like RC6 off. Maybe we can add a 
>> > > > > > > > > > debug kconfig to
>> > > > > > > > > > force info->has_rc6 = 0? Not a blocker to this patch but 
>> > > > > > > > > > worth considering
>> > > > > > > > > > IMO.
>> > > > > > > > > 
>> > > > > > > > > Most of the BIOSes I've seen on our RVPs have had an option 
>> > > > > > > > > to disable
>> > > > > > > > > RC6.
>> > > > > > > > 
>> > > > > > > > BIOS option don't block our code to run and set some MMIOs.
>> > > > > > > > Not sure how the GPU will behave on such cases.
>> > > > > > > > 
>> > > > > > > > I like the idea of removing some and keeping the parameters 
>> > > > > > > > clean.
>> > > > > > > > But there are few ones like RC6 and disable_power_wells that 
>> > > > > > > > are very
>> > > > > > > > useful on platform enabling and also when assisting others to 
>> > > > > > > > debug issues.
>> > > > > > > > 
>> > > > > > > > For instance right now that we fixed RC6 on CNL someone told 
>> > > > > > > > that
>> > > > > > > > he believe seeing more hangs, so I immediately asked to boot 
>> > > > > > > > with
>> > > > > > > > i915.enable_rc6=0 to double check. It is easier and 
>> > > > > > > > straighforward
>> > > > > > > > to direct them to the unsafe param than to ask them to compile 
>> > > > > > > > the code
>> > > > > > > > with different options or to use some BIOS options that we are 
>> > > > > > > > not sure.
>> > > > > > > > 
>> > > > > > > > Also on bug triage some options like this are helpful.
>> > > > > > > > 
>> > > > > > > > Also BIOS and compile are saved flags. So if you need to do a 
>> > > > > > > > quick test
>> > > > > > > > you have to save it, and then unsave later. Parameters are 
>> > > > > > > > very convinient
>> > > > > > > > for 1 boot only check.
>> > > > > > > 
>> > > > > > > It's convenient for sure, but the unsafe module parameters seems 
>> > > > > > > to be
>> > > > > > > finding their way into way too many HOWTOs, and from there to 
>> > > > > > > some
>> > > > > > > "productized" use-cases. Chris states that setting .enable_rc6=0 
>> > > > > > > to
>> > > > > > > solving an issue on publicly shipping products has been some 
>> > > > > > > years ago,
>> > > > > > > so I don't see a need for carrying this.
>> > > > > > > 
>> > > > > > > We shouldn't allow the convenience of not having to change one 
>> > > 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move execlists port head instead of memmoving array

[Chris Wilson]

Quoting Mika Kuoppala (2017-10-31 15:27:34)
> From: Mika Kuoppala 
> 
> As all our access to execlist ports are through head and tail
> helpers, we can now move the head instead of memmoving the array.
> 
> v2: use memset (Chris)
> 
> Cc: Michał Winiarski 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 387667fe50d3..011c4b8f1339 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -611,13 +611,13 @@ static inline struct execlist_port *
>  execlists_head_complete(struct intel_engine_execlists * const execlists,
> struct execlist_port * const port)
>  {
> -   const unsigned int m = execlists->port_mask;
> -
> -   GEM_BUG_ON(port_index(port, execlists) != 0);
> +   GEM_BUG_ON(port_index(port, execlists) != execlists->port_head);
> +   GEM_BUG_ON(!port_isset(port));
> GEM_BUG_ON(!execlists_is_active(execlists, EXECLISTS_ACTIVE_USER));
>  
> -   memmove(port, port + 1, m * sizeof(struct execlist_port));
> -   memset(port + m, 0, sizeof(struct execlist_port));
> +   memset(port, 0, sizeof(*port));
> +
> +   execlists->port_head = port_head_add(execlists, 1);

Ok, I would have gone for

port = port_next(port);
execlists->port_head = port - execlists->port;
return port;

That to me looks more natural advance of port as we complete the
requests, and matches the loop in the irq handler.

Care to crunch the numbers and see which gcc favours?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/debugfs_test: Pretty print subdirectories

[Patchwork]

== Series Details ==

Series: tests/debugfs_test: Pretty print subdirectories
URL   : https://patchwork.freedesktop.org/series/33045/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
6d16875736b9fb1ebf4bf3dc5a941f9e431d58e0 lib/igt_debugfs: Remove support for 
legacy CRC api.

with latest DRM-Tip kernel build CI_DRM_3309
fca2506bc5d4 drm-tip: 2017y-11m-02d-13h-10m-58s UTC integration manifest

No testlist changes.

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-glk-dsi) fdo#103167
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6700k) fdo#103546 +1

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103546 https://bugs.freedesktop.org/show_bug.cgi?id=103546

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:448s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:457s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:382s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:540s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:502s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:507s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:512s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:489s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:556s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:607s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:269s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:582s
fi-glk-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:492s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:429s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:503s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:495s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:575s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:584s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:576s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:598s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:647s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:522s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:506s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:465s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:572s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:429s

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce execlist_port_* accessors

[Chris Wilson]

Quoting Mika Kuoppala (2017-11-02 14:32:38)
> From: Mika Kuoppala 
> 
> Instead of trusting that first available port is at index 0,
> use accessor to hide this. This is a preparation for a
> following patches where head can be at arbitrary location
> in the port array.
> 
> v2: improved commit message, elsp_ready readability (Chris)
> v3: s/execlist_port_index/execlist_port (Chris)
> v4: rebase to new naming
> v5: fix port_next indexing
> v6: adapt to preempt
> v7: improved _port_next (Chris)
> 
> Cc: Michał Winiarski 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gpu_error.c  |  6 ++--
>  drivers/gpu/drm/i915/i915_guc_submission.c | 50 
> ++
>  drivers/gpu/drm/i915/intel_engine_cs.c | 18 ++-
>  drivers/gpu/drm/i915/intel_lrc.c   | 49 ++---
>  drivers/gpu/drm/i915/intel_ringbuffer.h| 44 --
>  5 files changed, 119 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 653fb69e7ecb..6d0bdb03b3f0 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1333,11 +1333,13 @@ static void engine_record_requests(struct 
> intel_engine_cs *engine,
>  static void error_record_engine_execlists(struct intel_engine_cs *engine,
>   struct drm_i915_error_engine *ee)
>  {
> -   const struct intel_engine_execlists * const execlists = 
> &engine->execlists;
> +   struct intel_engine_execlists * const execlists = &engine->execlists;
> unsigned int n;
>  
> for (n = 0; n < execlists_num_ports(execlists); n++) {
> -   struct drm_i915_gem_request *rq = 
> port_request(&execlists->port[n]);
> +   struct drm_i915_gem_request *rq;
> +
> +   rq = port_request(execlists_port(execlists, n));
>  
This newline isn't as interesting as the others. No one will shed a tear
if it is removed.

> if (!rq)
> break;

> @@ -665,7 +670,8 @@ static void execlists_dequeue(struct intel_engine_cs 
> *engine)
>  
> if (submit)
> port_assign(port, last);
> -   port++;
> +
> +   port = execlists_port_next(execlists, port);
>  

Spare us this newline as well. Let's have the advance and BUG() tightly
coupled.

> GEM_BUG_ON(port_isset(port));
> }
> @@ -699,8 +705,10 @@ static void execlists_dequeue(struct intel_engine_cs 
> *engine)
>  void
>  execlists_cancel_port_requests(struct intel_engine_execlists * const 
> execlists)
>  {
> -   struct execlist_port *port = execlists->port;
> unsigned int num_ports = execlists_num_ports(execlists);
> +   struct execlist_port *port;
> +
> +   port = execlists_port_head(execlists);
>  
> while (num_ports-- && port_isset(port)) {

for (port = execlists_port_head(execlists);
 num_ports-- && port_isset(port);
 port = execlists_head_complete(execlists, port)) {

Might as well complete the transformation to more normal code ;)

> +static inline struct execlist_port *
> +execlists_head_complete(struct intel_engine_execlists * const execlists,
> struct execlist_port * const port)
>  {
> const unsigned int m = execlists->port_mask;
> @@ -580,6 +618,8 @@ execlists_port_complete(struct intel_engine_execlists * 
> const execlists,
>  
> memmove(port, port + 1, m * sizeof(struct execlist_port));
> memset(port + m, 0, sizeof(struct execlist_port));
> +
> +   return execlists_port_head(execlists);

Hang on a sec, isn't port->head itself meant to advance here? Oh,
that'll be the next patch and this is just prep.

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 v3] drm/i915: Remove unsafe i915.enable_rc6

[Joonas Lahtinen]

On Thu, 2017-11-02 at 07:47 -0700, Rodrigo Vivi wrote:
> On Thu, Nov 02, 2017 at 08:06:29AM +, Jani Nikula wrote:
> > On Wed, 01 Nov 2017, Rodrigo Vivi  wrote:
> > > On Wed, Nov 01, 2017 at 04:21:08PM +, Ben Widawsky wrote:
> > > > On 17-11-01 18:09:47, Joonas Lahtinen wrote:
> > > > > + Kimmo and Paul
> > > > > 
> > > > > On Wed, 2017-11-01 at 07:43 -0700, Ben Widawsky wrote:
> > > > > > On 17-11-01 14:07:28, Joonas Lahtinen wrote:
> > > > > > > On Mon, 2017-10-30 at 10:48 -0700, Rodrigo Vivi wrote:
> > > > > > > > On Mon, Oct 30, 2017 at 01:00:51PM +, David Weinehall wrote:
> > > > > > > > > On Fri, Oct 27, 2017 at 01:57:09PM -0700, Daniele Ceraolo 
> > > > > > > > > Spurio wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 26/10/17 03:32, Chris Wilson wrote:
> > > > > > > > > > > It has been many years since the last confirmed sighting 
> > > > > > > > > > > (and fix) of an
> > > > > > > > > > > RC6 related bug (usually a system hang). Remove the 
> > > > > > > > > > > parameter to stop
> > > > > > > > > > > users from setting dangerous values, as they often set it 
> > > > > > > > > > > during triage
> > > > > > > > > > > and end up disabling the entire runtime pm instead (the 
> > > > > > > > > > > option is not a
> > > > > > > > > > > fine scalpel!).
> > > > > > > > > > > 
> > > > > > > > > > > Furthermore, it allows users to set known dangerous 
> > > > > > > > > > > values which were
> > > > > > > > > > > intended for testing and not for production use. For 
> > > > > > > > > > > testing, we can
> > > > > > > > > > > always patch in the required setting without having to 
> > > > > > > > > > > expose ourselves
> > > > > > > > > > > to random abuse.
> > > > > > > > > > > 
> > > > > > > > > > > v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and 
> > > > > > > > > > > document the
> > > > > > > > > > > lack of ilk support better.
> > > > > > > > > > > v3: Clear intel_info->rc6p if we don't support rc6 itself.
> > > > > > > > > > > 
> > > > > > > > > > > Signed-off-by: Chris Wilson 
> > > > > > > > > > > Cc: Rodrigo Vivi 
> > > > > > > > > > > Cc: Joonas Lahtinen 
> > > > > > > > > > > Cc: Jani Nikula 
> > > > > > > > > > > Cc: Imre Deak 
> > > > > > > > > > > Cc: Daniel Vetter 
> > > > > > > > > > > Acked-by: Daniel Vetter 
> > > > > > > > > > > ---
> > > > > > > > > > 
> > > > > > > > > > I think that for execution/debug on early silicon we might 
> > > > > > > > > > still want the
> > > > > > > > > > ability to turn features like RC6 off. Maybe we can add a 
> > > > > > > > > > debug kconfig to
> > > > > > > > > > force info->has_rc6 = 0? Not a blocker to this patch but 
> > > > > > > > > > worth considering
> > > > > > > > > > IMO.
> > > > > > > > > 
> > > > > > > > > Most of the BIOSes I've seen on our RVPs have had an option 
> > > > > > > > > to disable
> > > > > > > > > RC6.
> > > > > > > > 
> > > > > > > > BIOS option don't block our code to run and set some MMIOs.
> > > > > > > > Not sure how the GPU will behave on such cases.
> > > > > > > > 
> > > > > > > > I like the idea of removing some and keeping the parameters 
> > > > > > > > clean.
> > > > > > > > But there are few ones like RC6 and disable_power_wells that 
> > > > > > > > are very
> > > > > > > > useful on platform enabling and also when assisting others to 
> > > > > > > > debug issues.
> > > > > > > > 
> > > > > > > > For instance right now that we fixed RC6 on CNL someone told 
> > > > > > > > that
> > > > > > > > he believe seeing more hangs, so I immediately asked to boot 
> > > > > > > > with
> > > > > > > > i915.enable_rc6=0 to double check. It is easier and 
> > > > > > > > straighforward
> > > > > > > > to direct them to the unsafe param than to ask them to compile 
> > > > > > > > the code
> > > > > > > > with different options or to use some BIOS options that we are 
> > > > > > > > not sure.
> > > > > > > > 
> > > > > > > > Also on bug triage some options like this are helpful.
> > > > > > > > 
> > > > > > > > Also BIOS and compile are saved flags. So if you need to do a 
> > > > > > > > quick test
> > > > > > > > you have to save it, and then unsave later. Parameters are very 
> > > > > > > > convinient
> > > > > > > > for 1 boot only check.
> > > > > > > 
> > > > > > > It's convenient for sure, but the unsafe module parameters seems 
> > > > > > > to be
> > > > > > > finding their way into way too many HOWTOs, and from there to some
> > > > > > > "productized" use-cases. Chris states that setting .enable_rc6=0 
> > > > > > > to
> > > > > > > solving an issue on publicly shipping products has been some 
> > > > > > > years ago,
> > > > > > > so I don't see a need for carrying this.
> > > > > > > 
> > > > > > > We shouldn't allow the convenience of not having to change one 
> > > > > > > line and
> > > > > > > recompile kernel during development to affect the end-users who 
> > > > > > > are
> > > > > > > Googling how to get the best performance out of their hardware (I 
> > > > >

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Stop caching the "golden" renderstate

[Joonas Lahtinen]

On Thu, 2017-11-02 at 07:54 -0700, Rodrigo Vivi wrote:
> On Thu, Nov 02, 2017 at 02:43:16PM +, Joonas Lahtinen wrote:
> > On Thu, 2017-11-02 at 12:42 +, Chris Wilson wrote:
> > > As we now record the default HW state and so only emit the "golden"
> > > renderstate once to prepare the HW, there is no advantage in keeping the
> > > renderstate batch around as it will never be used again.
> 
> So, with this in place we really don't need that null context for CNL.
> to fullfill all Mesa needs, right?!

Separate issue, this only fixes isolation. This patch just releases it
from memory after it's been applied to the default context states to be
stored.

But yes, we also decided not to have null context for new platforms.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Move GT powersaving init to i915_gem_init()

[Chris Wilson]

Quoting Sagar Arun Kamble (2017-11-02 14:35:17)
> 
> 
> On 11/2/2017 6:12 PM, Chris Wilson wrote:
> > GT powersaving is tightly coupled to the request infrastructure. To
> > avoid complications with the order of initialisation in the next patch
> > (where we want to send requests to hw during GEM init) move the
> > powersaving initialisation into the purview of i915_gem_init().
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >   drivers/gpu/drm/i915/i915_gem.c  | 7 ++-
> >   drivers/gpu/drm/i915/intel_display.c | 2 --
> >   drivers/gpu/drm/i915/intel_pm.c  | 2 --
> >   3 files changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 9470ba0c1930..e36a3a840552 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -5017,6 +5017,12 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
> >   goto out_unlock;
> >   
> >   ret = i915_gem_init_hw(dev_priv);
> > + if (ret)
> > + goto out_unlock;
> > +
> > + intel_init_gt_powersave(dev_priv);
> Can this be moved before gem_init_hw. That way SLPC can get the initial 
> platform RP configuration during uc_init.

Not at this point in the series, I would argue. Once we remove
intel_autoenable_gt_powersave(), it looks free to be moved before
i915_gem_init().

Or we split out the autoenable to here (or just after) and then remove
it. Or you just move init_gt_powersave() a bit earlier in a jiffie.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Stop caching the "golden" renderstate

[Rodrigo Vivi]

On Thu, Nov 02, 2017 at 02:43:16PM +, Joonas Lahtinen wrote:
> On Thu, 2017-11-02 at 12:42 +, Chris Wilson wrote:
> > As we now record the default HW state and so only emit the "golden"
> > renderstate once to prepare the HW, there is no advantage in keeping the
> > renderstate batch around as it will never be used again.

So, with this in place we really don't need that null context for CNL.
to fullfill all Mesa needs, right?!

> > 
> > Signed-off-by: Chris Wilson 
> 
> Reviewed-by: Joonas Lahtinen 
> 
> Regards, Joonas
> -- 
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
> ___
> 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 v3] drm/i915: Remove unsafe i915.enable_rc6

[Rodrigo Vivi]

On Thu, Nov 02, 2017 at 08:06:29AM +, Jani Nikula wrote:
> On Wed, 01 Nov 2017, Rodrigo Vivi  wrote:
> > On Wed, Nov 01, 2017 at 04:21:08PM +, Ben Widawsky wrote:
> >> On 17-11-01 18:09:47, Joonas Lahtinen wrote:
> >> > + Kimmo and Paul
> >> > 
> >> > On Wed, 2017-11-01 at 07:43 -0700, Ben Widawsky wrote:
> >> > > On 17-11-01 14:07:28, Joonas Lahtinen wrote:
> >> > > > On Mon, 2017-10-30 at 10:48 -0700, Rodrigo Vivi wrote:
> >> > > > > On Mon, Oct 30, 2017 at 01:00:51PM +, David Weinehall wrote:
> >> > > > > > On Fri, Oct 27, 2017 at 01:57:09PM -0700, Daniele Ceraolo Spurio 
> >> > > > > > wrote:
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On 26/10/17 03:32, Chris Wilson wrote:
> >> > > > > > > > It has been many years since the last confirmed sighting 
> >> > > > > > > > (and fix) of an
> >> > > > > > > > RC6 related bug (usually a system hang). Remove the 
> >> > > > > > > > parameter to stop
> >> > > > > > > > users from setting dangerous values, as they often set it 
> >> > > > > > > > during triage
> >> > > > > > > > and end up disabling the entire runtime pm instead (the 
> >> > > > > > > > option is not a
> >> > > > > > > > fine scalpel!).
> >> > > > > > > >
> >> > > > > > > > Furthermore, it allows users to set known dangerous values 
> >> > > > > > > > which were
> >> > > > > > > > intended for testing and not for production use. For 
> >> > > > > > > > testing, we can
> >> > > > > > > > always patch in the required setting without having to 
> >> > > > > > > > expose ourselves
> >> > > > > > > > to random abuse.
> >> > > > > > > >
> >> > > > > > > > v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and 
> >> > > > > > > > document the
> >> > > > > > > > lack of ilk support better.
> >> > > > > > > > v3: Clear intel_info->rc6p if we don't support rc6 itself.
> >> > > > > > > >
> >> > > > > > > > Signed-off-by: Chris Wilson 
> >> > > > > > > > Cc: Rodrigo Vivi 
> >> > > > > > > > Cc: Joonas Lahtinen 
> >> > > > > > > > Cc: Jani Nikula 
> >> > > > > > > > Cc: Imre Deak 
> >> > > > > > > > Cc: Daniel Vetter 
> >> > > > > > > > Acked-by: Daniel Vetter 
> >> > > > > > > > ---
> >> > > > > > >
> >> > > > > > > I think that for execution/debug on early silicon we might 
> >> > > > > > > still want the
> >> > > > > > > ability to turn features like RC6 off. Maybe we can add a 
> >> > > > > > > debug kconfig to
> >> > > > > > > force info->has_rc6 = 0? Not a blocker to this patch but worth 
> >> > > > > > > considering
> >> > > > > > > IMO.
> >> > > > > >
> >> > > > > > Most of the BIOSes I've seen on our RVPs have had an option to 
> >> > > > > > disable
> >> > > > > > RC6.
> >> > > > >
> >> > > > > BIOS option don't block our code to run and set some MMIOs.
> >> > > > > Not sure how the GPU will behave on such cases.
> >> > > > >
> >> > > > > I like the idea of removing some and keeping the parameters clean.
> >> > > > > But there are few ones like RC6 and disable_power_wells that are 
> >> > > > > very
> >> > > > > useful on platform enabling and also when assisting others to 
> >> > > > > debug issues.
> >> > > > >
> >> > > > > For instance right now that we fixed RC6 on CNL someone told that
> >> > > > > he believe seeing more hangs, so I immediately asked to boot with
> >> > > > > i915.enable_rc6=0 to double check. It is easier and straighforward
> >> > > > > to direct them to the unsafe param than to ask them to compile the 
> >> > > > > code
> >> > > > > with different options or to use some BIOS options that we are not 
> >> > > > > sure.
> >> > > > >
> >> > > > > Also on bug triage some options like this are helpful.
> >> > > > >
> >> > > > > Also BIOS and compile are saved flags. So if you need to do a 
> >> > > > > quick test
> >> > > > > you have to save it, and then unsave later. Parameters are very 
> >> > > > > convinient
> >> > > > > for 1 boot only check.
> >> > > >
> >> > > > It's convenient for sure, but the unsafe module parameters seems to 
> >> > > > be
> >> > > > finding their way into way too many HOWTOs, and from there to some
> >> > > > "productized" use-cases. Chris states that setting .enable_rc6=0 to
> >> > > > solving an issue on publicly shipping products has been some years 
> >> > > > ago,
> >> > > > so I don't see a need for carrying this.
> >> > > >
> >> > > > We shouldn't allow the convenience of not having to change one line 
> >> > > > and
> >> > > > recompile kernel during development to affect the end-users who are
> >> > > > Googling how to get the best performance out of their hardware (I 
> >> > > > could
> >> > > > mention some distro here).
> >> > > >
> >> > > > This seems the like the best option as I don't think introducing 
> >> > > > kernel
> >> > > > parameters that only exists on debug builds would be too convenient
> >> > > > either. It'd maybe just add more confusion.
> >> > > >
> >> > > > Regards, Joonas
> >> > > 
> >> > > I believe the ability to disable RC6 is valuable not just for debugging
> >> > > purposes. Folks with very la

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Remove support for legacy debugfs crc interface

[Patchwork]

== Series Details ==

Series: drm/i915: Remove support for legacy debugfs crc interface
URL   : https://patchwork.freedesktop.org/series/33053/
State : warning

== Summary ==

Series 33053v1 drm/i915: Remove support for legacy debugfs crc interface
https://patchwork.freedesktop.org/api/1.0/series/33053/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> SKIP   (fi-gdg-551)
pass   -> SKIP   (fi-blb-e6850)
pass   -> SKIP   (fi-pnv-d510)
pass   -> SKIP   (fi-bwr-2160)
pass   -> SKIP   (fi-elk-e7500)
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6600u)
pass   -> SKIP   (fi-skl-6700hq)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-bxt-dsi)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7560u)
pass   -> SKIP   (fi-kbl-7567u) fdo#103165 +1
pass   -> SKIP   (fi-kbl-r)
pass   -> SKIP   (fi-glk-1)
pass   -> SKIP   (fi-glk-dsi)
pass   -> SKIP   (fi-cnl-y)
Subgroup bad-nb-words-3:
pass   -> SKIP   (fi-gdg-551)
pass   -> SKIP   (fi-blb-e6850)
pass   -> SKIP   (fi-pnv-d510)
pass   -> SKIP   (fi-bwr-2160)
pass   -> SKIP   (fi-elk-e7500)
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6600u)
pass   -> SKIP   (fi-skl-6700hq)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-bxt-dsi)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7560u)
pass   -> SKIP   (fi-kbl-7567u)
pass   -> SKIP   (fi-kbl-r)
pass   -> SKIP   (fi-glk-1)
pass   -> SKIP   (fi-glk-dsi)
pass   -> SKIP   (fi-cnl-y)
Subgroup bad-pipe:
pass   -> SKIP   (fi-gdg-551)
pass   -> SKIP   (fi-blb-e6850)
pass   -> SKIP   (fi-pnv-d510)
pass   -> SKIP   (fi-bwr-2160)
pass   -> SKIP   (fi-elk-e7500)
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Stop caching the "golden" renderstate

[Joonas Lahtinen]

On Thu, 2017-11-02 at 12:42 +, Chris Wilson wrote:
> As we now record the default HW state and so only emit the "golden"
> renderstate once to prepare the HW, there is no advantage in keeping the
> renderstate batch around as it will never be used again.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Record the default hw state after reset upon load

[Chris Wilson]

Quoting Ville Syrjälä (2017-11-02 14:23:00)
> On Thu, Nov 02, 2017 at 12:42:24PM +, Chris Wilson wrote:
> > Take a copy of the HW state after a reset upon module loading by
> > executing a context switch from a blank context to the kernel context,
> > thus saving the default hw state over the blank context image.
> > We can then use the default hw state to initialise any future context,
> > ensuring that each starts with the default view of hw state.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/gvt/scheduler.c|  2 -
> >  drivers/gpu/drm/i915/i915_debugfs.c |  1 -
> >  drivers/gpu/drm/i915/i915_gem.c | 69 
> > +
> >  drivers/gpu/drm/i915/i915_gem_context.c | 50 +++-
> >  drivers/gpu/drm/i915/i915_gem_context.h |  4 +-
> >  drivers/gpu/drm/i915/intel_engine_cs.c  |  3 ++
> >  drivers/gpu/drm/i915/intel_lrc.c| 35 ++---
> >  drivers/gpu/drm/i915/intel_ringbuffer.c | 47 +++---
> >  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
> >  9 files changed, 137 insertions(+), 75 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> > b/drivers/gpu/drm/i915/gvt/scheduler.c
> > index f6ded475bb2c..42cc61230ca7 100644
> > --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> > +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> > @@ -723,8 +723,6 @@ int intel_vgpu_init_gvt_context(struct intel_vgpu *vgpu)
> >   if (IS_ERR(vgpu->shadow_ctx))
> >   return PTR_ERR(vgpu->shadow_ctx);
> >  
> > - vgpu->shadow_ctx->engine[RCS].initialised = true;
> > -
> >   bitmap_zero(vgpu->shadow_ctx_desc_updated, I915_NUM_ENGINES);
> >  
> >   return 0;
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 39883cd915db..cfcef1899da8 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1974,7 +1974,6 @@ static int i915_context_status(struct seq_file *m, 
> > void *unused)
> >   struct intel_context *ce = &ctx->engine[engine->id];
> >  
> >   seq_printf(m, "%s: ", engine->name);
> > - seq_putc(m, ce->initialised ? 'I' : 'i');
> >   if (ce->state)
> >   describe_obj(m, ce->state->obj);
> >   if (ce->ring)
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index e36a3a840552..ed4b1708fec5 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4967,6 +4967,71 @@ bool intel_sanitize_semaphores(struct 
> > drm_i915_private *dev_priv, int value)
> >   return true;
> >  }
> >  
> > +static int __intel_engines_record_defaults(struct drm_i915_private *i915)
> > +{
> > + struct i915_gem_context *ctx;
> > + struct intel_engine_cs *engine;
> > + enum intel_engine_id id;
> > + int err;
> > +
> > + /*
> > +  * As we reset the gpu during very early sanitisation, the current
> > +  * register state on the GPU should reflect its defaults values.
> > +  * We load a context onto the hw (with restore-inhibit), then switch
> > +  * over to a second context to save that default register state. We
> > +  * can then prime every new context with that state so they all start
> > +  * from defaults.
> > +  */
> > +
> > + ctx = i915_gem_context_create_kernel(i915, 0);
> > + if (IS_ERR(ctx))
> > + return PTR_ERR(ctx);
> > +
> > + for_each_engine(engine, i915, id) {
> > + struct drm_i915_gem_request *rq;
> > +
> > + rq = i915_gem_request_alloc(engine, ctx);
> > + if (IS_ERR(rq)) {
> > + err = PTR_ERR(rq);
> > + goto out_ctx;
> > + }
> > +
> > + err = i915_switch_context(rq);
> > + if (engine->init_context)
> > + err = engine->init_context(rq);
> > +
> > + __i915_add_request(rq, true);
> > + if (err)
> > + goto out_ctx;
> > + }
> > +
> > + err = i915_gem_switch_to_kernel_context(i915);
> > + if (err)
> > + goto out_ctx;
> > +
> > + err = i915_gem_wait_for_idle(i915, I915_WAIT_LOCKED);
> > + if (err)
> > + goto out_ctx;
> > +
> > + for_each_engine(engine, i915, id) {
> > + if (!ctx->engine[id].state)
> > + continue;
> > +
> > + engine->default_state =
> > + i915_gem_object_get(ctx->engine[id].state->obj);
> > +
> > + err = i915_gem_object_set_to_cpu_domain(engine->default_state,
> > + false);
> > + if (err)
> > + goto out_ctx;
> 
> Should we unmap the default context from the GTT here to make sure
> the GPU never gets a chance to clobber it?

Ah

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Move GT powersaving init to i915_gem_init()

[Sagar Arun Kamble]

On 11/2/2017 6:12 PM, Chris Wilson wrote:

GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c  | 7 ++-
  drivers/gpu/drm/i915/intel_display.c | 2 --
  drivers/gpu/drm/i915/intel_pm.c  | 2 --
  3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9470ba0c1930..e36a3a840552 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5017,6 +5017,12 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
goto out_unlock;
  
  	ret = i915_gem_init_hw(dev_priv);

+   if (ret)
+   goto out_unlock;
+
+   intel_init_gt_powersave(dev_priv);
Can this be moved before gem_init_hw. That way SLPC can get the initial 
platform RP configuration during uc_init.

+
+out_unlock:
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,
@@ -5029,7 +5035,6 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
ret = 0;
}
  
-out_unlock:

intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
mutex_unlock(&dev_priv->drm.struct_mutex);
  
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c

index 737de251d0f8..c3bf87c2036c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15174,8 +15174,6 @@ void intel_modeset_gem_init(struct drm_device *dev)
  {
struct drm_i915_private *dev_priv = to_i915(dev);
  
-	intel_init_gt_powersave(dev_priv);

-
intel_setup_overlay(dev_priv);
  }
  
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c

index 07118c0b69d3..6e1358d4e764 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7900,7 +7900,6 @@ void intel_init_gt_powersave(struct drm_i915_private 
*dev_priv)
intel_runtime_pm_get(dev_priv);
}
  
-	mutex_lock(&dev_priv->drm.struct_mutex);

mutex_lock(&dev_priv->pcu_lock);
  
  	/* Initialize RPS limits (for userspace) */

@@ -7942,7 +7941,6 @@ void intel_init_gt_powersave(struct drm_i915_private 
*dev_priv)
rps->boost_freq = rps->max_freq;
  
  	mutex_unlock(&dev_priv->pcu_lock);

-   mutex_unlock(&dev_priv->drm.struct_mutex);
  
  	intel_autoenable_gt_powersave(dev_priv);

  }


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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Reject unknown syncobj flags (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Reject unknown syncobj flags (rev2)
URL   : https://patchwork.freedesktop.org/series/32893/
State : success

== Summary ==

Test kms_flip:
Subgroup plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup wf_vblank-vs-dpms-interruptible:
skip   -> PASS   (shard-hsw) fdo#102614
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-cur-indfb-draw-blt:
skip   -> PASS   (shard-hsw)
Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt:
skip   -> PASS   (shard-hsw)
Test kms_atomic_transition:
Subgroup plane-all-transition-fencing:
skip   -> PASS   (shard-hsw)
Subgroup plane-all-modeset-transition:
skip   -> PASS   (shard-hsw)
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (shard-hsw) fdo#102707

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

shard-hswtotal:2539 pass:1429 dwarn:3   dfail:0   fail:10  skip:1097 
time:9229s

== Logs ==

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

[Intel-gfx] [PATCH 1/2] drm/i915: Introduce execlist_port_* accessors

[Mika Kuoppala]

From: Mika Kuoppala 

Instead of trusting that first available port is at index 0,
use accessor to hide this. This is a preparation for a
following patches where head can be at arbitrary location
in the port array.

v2: improved commit message, elsp_ready readability (Chris)
v3: s/execlist_port_index/execlist_port (Chris)
v4: rebase to new naming
v5: fix port_next indexing
v6: adapt to preempt
v7: improved _port_next (Chris)

Cc: Michał Winiarski 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gpu_error.c  |  6 ++--
 drivers/gpu/drm/i915/i915_guc_submission.c | 50 ++
 drivers/gpu/drm/i915/intel_engine_cs.c | 18 ++-
 drivers/gpu/drm/i915/intel_lrc.c   | 49 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.h| 44 --
 5 files changed, 119 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 653fb69e7ecb..6d0bdb03b3f0 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1333,11 +1333,13 @@ static void engine_record_requests(struct 
intel_engine_cs *engine,
 static void error_record_engine_execlists(struct intel_engine_cs *engine,
  struct drm_i915_error_engine *ee)
 {
-   const struct intel_engine_execlists * const execlists = 
&engine->execlists;
+   struct intel_engine_execlists * const execlists = &engine->execlists;
unsigned int n;
 
for (n = 0; n < execlists_num_ports(execlists); n++) {
-   struct drm_i915_gem_request *rq = 
port_request(&execlists->port[n]);
+   struct drm_i915_gem_request *rq;
+
+   rq = port_request(execlists_port(execlists, n));
 
if (!rq)
break;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d14c1342f09d..458658e8e99b 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -693,16 +693,18 @@ static void i915_guc_submit(struct intel_engine_cs 
*engine)
 {
struct intel_guc *guc = &engine->i915->guc;
struct intel_engine_execlists * const execlists = &engine->execlists;
-   struct execlist_port *port = execlists->port;
unsigned int n;
 
for (n = 0; n < execlists_num_ports(execlists); n++) {
+   struct execlist_port *port;
struct drm_i915_gem_request *rq;
unsigned int count;
 
-   rq = port_unpack(&port[n], &count);
+   port = execlists_port(execlists, n);
+   rq = port_unpack(port, &count);
+
if (rq && count == 0) {
-   port_set(&port[n], port_pack(rq, ++count));
+   port_set(port, port_pack(rq, ++count));
 
flush_ggtt_writes(rq->ring->vma);
 
@@ -725,10 +727,8 @@ static void port_assign(struct execlist_port *port,
 static void i915_guc_dequeue(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = &engine->execlists;
-   struct execlist_port *port = execlists->port;
+   struct execlist_port *port, *last_port;
struct drm_i915_gem_request *last = NULL;
-   const struct execlist_port * const last_port =
-   &execlists->port[execlists->port_mask];
bool submit = false;
struct rb_node *rb;
 
@@ -739,6 +739,9 @@ static void i915_guc_dequeue(struct intel_engine_cs *engine)
if (!rb)
goto unlock;
 
+   port = execlists_port_head(execlists);
+   last_port = execlists_port_tail(execlists);
+
if (HAS_LOGICAL_RING_PREEMPTION(engine->i915) && port_isset(port)) {
struct guc_preempt_work *preempt_work =
&engine->i915->guc.preempt_work[engine->id];
@@ -754,7 +757,7 @@ static void i915_guc_dequeue(struct intel_engine_cs *engine)
goto unlock;
}
 
-   port++;
+   port = execlists_port_next(execlists, port);
}
 
do {
@@ -771,7 +774,8 @@ static void i915_guc_dequeue(struct intel_engine_cs *engine)
 
if (submit)
port_assign(port, last);
-   port++;
+
+   port = execlists_port_next(execlists, port);
}
 
INIT_LIST_HEAD(&rq->priotree.link);
@@ -799,24 +803,32 @@ static void i915_guc_dequeue(struct intel_engine_cs 
*engine)
spin_unlock_irq(&engine->timeline->lock);
 }
 
-static void i915_guc_irq_handler(unsigned long data)
+static void guc_complete_ready_ports(struct intel_engine_execlists * const 
execlists)
 {
-   struct intel_engine_cs * const engine = (struct intel_engine_cs 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Set up mocs tables before restarting the engines

[Patchwork]

== Series Details ==

Series: drm/i915: Set up mocs tables before restarting the engines
URL   : https://patchwork.freedesktop.org/series/33051/
State : success

== Summary ==

Series 33051v1 drm/i915: Set up mocs tables before restarting the engines
https://patchwork.freedesktop.org/api/1.0/series/33051/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6700k) fdo#103546 +1
Subgroup nonblocking-crc-pipe-b:
pass   -> INCOMPLETE (fi-cnl-y) fdo#102035

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:446s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:448s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:539s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:275s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:513s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:502s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:509s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:496s
fi-cnl-y total:289  pass:210  dwarn:0   dfail:0   fail:0   skip:24 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:262s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:585s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:492s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:433s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:426s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:434s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:484s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:578s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:595s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:569s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:593s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:648s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:522s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:461s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:573s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:425s

fca2506bc5d492609e3f1b6e59d667e376a1eb3f drm-tip: 2017y-11m-02d-13h-10m-58s UTC 
integration manifest
2a7d3ee65ca8 drm/i915: Set up mocs tables before restarting the engines

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.04 for Kabylake

[Rodrigo Vivi]

On Thu, Nov 02, 2017 at 10:34:37AM +, Jani Nikula wrote:
> On Wed, 01 Nov 2017, Anusha Srivatsa  wrote:
> > There is a new version of DMC available for KBL.
> 
> Nobody's going to pull this to linux-firmware if you don't send it to
> the linux-firmware folks...

That's intentional. The idea is to send to linux-firmware only after it
passes our CI. So, prepare already in a way that it is easy to just forward when
that happens.

But what I believe we can change is to send that in the cover-letter of
the series.
So cover-letter with pull-request that CI would get automatically,
all related patches on the series, so right now it could be:
patch 0: pull-request
patch 1: kbl dmc 1.04
patch 2: skl dmc 1.27

> 
> > The release notes mentions:
> > 1. Fix for the issue where DC_STATE was getting enabled even
> > when disabled by driver causing data corruption.
> >
> > Adding the pull request here as an experiment-
> > The following changes since commit bf04291309d3169c0ad3b8db52564235bbd08e30:
> >
> >   WHENCE: Add new qed firmware (2017-10-09 18:03:26 +0100)
> >
> > are available in the git repository at:
> >
> >   https://github.com/anushasr/linux-firmware.git KBL_DMC
> 
> We should have a shared repo for this at freedesktop.org instead of your
> private repo at github.

I had never seen a particularly need for that before, but with
this new process in place I believe it makes tons of sense.
Who could help to setup a repo and right permissions?
Daniel Stone?

> And we should use signed tags for pull requests.

Yes, tags are essencial here. Specially with this process
of sending here first for CI and only after passing CI fwding
that to linux-firmware.git we need to have tags.

Thanks,
Rodrigo.

> 
> BR,
> Jani.
> 
> >
> > for you to fetch changes up to 2f2b42764455856c2ba63d2154b3b2fbb7424236:
> >
> >   linux-firmware: DMC firmware for kabylake v1.04 (2017-11-01 19:22:21 
> > -0700)
> >
> > 
> > Anusha Srivatsa (1):
> >   linux-firmware: DMC firmware for kabylake v1.04
> >
> >  WHENCE   |   4 
> >  i915/kbl_dmc_ver1_04.bin | Bin 0 -> 8840 bytes
> >  2 files changed, 4 insertions(+)
> >  create mode 100644 i915/kbl_dmc_ver1_04.bin
> >
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Anusha Srivatsa 
> > ---
> >  drivers/gpu/drm/i915/intel_csr.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index 3e1f86d..5842777 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -40,9 +40,9 @@
> >  #define I915_CSR_CNL "i915/cnl_dmc_ver1_06.bin"
> >  #define CNL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 6)
> >  
> > -#define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
> > +#define I915_CSR_KBL "i915/kbl_dmc_ver1_04.bin"
> >  MODULE_FIRMWARE(I915_CSR_KBL);
> > -#define KBL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 1)
> > +#define KBL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
> >  
> >  #define I915_CSR_SKL "i915/skl_dmc_ver1_26.bin"
> >  MODULE_FIRMWARE(I915_CSR_SKL);
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove support for legacy debugfs crc interface

[Ville Syrjälä]

On Thu, Nov 02, 2017 at 02:56:51PM +0100, Maarten Lankhorst wrote:
> This interface is deprecated, and has been replaced by the upstream
> drm crc interface.

Before we nuke this I would like to see an option in the new interface
to not filter out the "bad" CRCs. When analyzing how the hardware
behaves seeing every CRC can be valuable. And I'm not at all convinced
we should be dropping as many CRCs as we are currently.

> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Tomi Sarvela 
> Cc: Petri Latvala 
> Cc: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
>  drivers/gpu/drm/i915/i915_drv.h   |  10 -
>  drivers/gpu/drm/i915/i915_irq.c   |  79 ++
>  drivers/gpu/drm/i915/intel_drv.h  |   2 -
>  drivers/gpu/drm/i915/intel_pipe_crc.c | 446 
> --
>  5 files changed, 23 insertions(+), 521 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 7efe57c0703e..a362370e5a68 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4991,7 +4991,6 @@ static const struct i915_debugfs_files {
>   {"i915_gpu_info", &i915_gpu_info_fops},
>  #endif
>   {"i915_next_seqno", &i915_next_seqno_fops},
> - {"i915_display_crc_ctl", &i915_display_crc_ctl_fops},
>   {"i915_pri_wm_latency", &i915_pri_wm_latency_fops},
>   {"i915_spr_wm_latency", &i915_spr_wm_latency_fops},
>   {"i915_cur_wm_latency", &i915_cur_wm_latency_fops},
> @@ -5008,7 +5007,7 @@ int i915_debugfs_register(struct drm_i915_private 
> *dev_priv)
>  {
>   struct drm_minor *minor = dev_priv->drm.primary;
>   struct dentry *ent;
> - int ret, i;
> + int i;
>  
>   ent = debugfs_create_file("i915_forcewake_user", S_IRUSR,
> minor->debugfs_root, to_i915(minor->dev),
> @@ -5016,10 +5015,6 @@ int i915_debugfs_register(struct drm_i915_private 
> *dev_priv)
>   if (!ent)
>   return -ENOMEM;
>  
> - ret = intel_pipe_crc_create(minor);
> - if (ret)
> - return ret;
> -
>   for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++) {
>   ent = debugfs_create_file(i915_debugfs_files[i].name,
> S_IRUGO | S_IWUSR,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d37fd11908d0..f4290c9739e1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1948,19 +1948,9 @@ enum intel_pipe_crc_source {
>   INTEL_PIPE_CRC_SOURCE_MAX,
>  };
>  
> -struct intel_pipe_crc_entry {
> - uint32_t frame;
> - uint32_t crc[5];
> -};
> -
>  #define INTEL_PIPE_CRC_ENTRIES_NR128
>  struct intel_pipe_crc {
>   spinlock_t lock;
> - bool opened;/* exclusive access to the result file */
> - struct intel_pipe_crc_entry *entries;
> - enum intel_pipe_crc_source source;
> - int head, tail;
> - wait_queue_head_t wq;
>   int skipped;
>  };
>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index ff00e462697a..be119cb567a4 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1613,69 +1613,34 @@ static void display_pipe_crc_irq_handler(struct 
> drm_i915_private *dev_priv,
>uint32_t crc4)
>  {
>   struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
> - struct intel_pipe_crc_entry *entry;
>   struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> - struct drm_driver *driver = dev_priv->drm.driver;
>   uint32_t crcs[5];
> - int head, tail;
>  
>   spin_lock(&pipe_crc->lock);
> - if (pipe_crc->source) {
> - if (!pipe_crc->entries) {
> - spin_unlock(&pipe_crc->lock);
> - DRM_DEBUG_KMS("spurious interrupt\n");
> - return;
> - }
> -
> - head = pipe_crc->head;
> - tail = pipe_crc->tail;
> -
> - if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
> - spin_unlock(&pipe_crc->lock);
> - DRM_ERROR("CRC buffer overflowing\n");
> - return;
> - }
> -
> - entry = &pipe_crc->entries[head];
> -
> - entry->frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
> - entry->crc[0] = crc0;
> - entry->crc[1] = crc1;
> - entry->crc[2] = crc2;
> - entry->crc[3] = crc3;
> - entry->crc[4] = crc4;
> -
> - head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
> - pipe_crc->head = head;
> -
> - spin_unlock(&pipe_crc->lock);
> -
> - wake_up_interruptible(&pipe_crc->wq);
> - } else {
> - /*
> -  * For some not yet identified reason, the first CRC is
> -  * bonkers

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Record the default hw state after reset upon load

[Joonas Lahtinen]

On Thu, 2017-11-02 at 12:42 +, Chris Wilson wrote:
> Take a copy of the HW state after a reset upon module loading by
> executing a context switch from a blank context to the kernel context,
> thus saving the default hw state over the blank context image.
> We can then use the default hw state to initialise any future context,
> ensuring that each starts with the default view of hw state.
> 
> Signed-off-by: Chris Wilson 



> @@ -795,11 +770,7 @@ static int do_rcs_switch(struct drm_i915_gem_request 
> *req)
>   return ret;
>   }
>  
> - if (!to->engine[RCS].initialised || i915_gem_context_is_default(to))
> - /* NB: If we inhibit the restore, the context is not allowed to
> -  * die because future work may end up depending on valid address
> -  * space. This means we must enforce that a page table load
> -  * occur when this occurs. */

Maybe add a comment explaining that we never ever assume execution on
the kernel context, so we don't care about the register state.

> + if (i915_gem_context_is_kernel(to))
>   hw_flags = MI_RESTORE_INHIBIT;
>   else if (ppgtt && intel_engine_flag(engine) & ppgtt->pd_dirty_rings)
>   hw_flags = MI_FORCE_RESTORE;



> @@ -2193,11 +2184,28 @@ populate_lr_context(struct i915_gem_context *ctx,
>   }
>   ctx_obj->mm.dirty = true;
>  
> + if (engine->default_state) {
> + void *defaults;
> +
> + defaults = i915_gem_object_pin_map(engine->default_state,
> +I915_MAP_WB);
> + if (IS_ERR(defaults))
> + return PTR_ERR(defaults);
> +
> + memcpy(vaddr + LRC_HEADER_PAGES * PAGE_SIZE,
> +defaults + LRC_HEADER_PAGES * PAGE_SIZE,

Could use somethingsomething_offset variable.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Record the default hw state after reset upon load

[Ville Syrjälä]

On Thu, Nov 02, 2017 at 12:42:24PM +, Chris Wilson wrote:
> Take a copy of the HW state after a reset upon module loading by
> executing a context switch from a blank context to the kernel context,
> thus saving the default hw state over the blank context image.
> We can then use the default hw state to initialise any future context,
> ensuring that each starts with the default view of hw state.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c|  2 -
>  drivers/gpu/drm/i915/i915_debugfs.c |  1 -
>  drivers/gpu/drm/i915/i915_gem.c | 69 
> +
>  drivers/gpu/drm/i915/i915_gem_context.c | 50 +++-
>  drivers/gpu/drm/i915/i915_gem_context.h |  4 +-
>  drivers/gpu/drm/i915/intel_engine_cs.c  |  3 ++
>  drivers/gpu/drm/i915/intel_lrc.c| 35 ++---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 47 +++---
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
>  9 files changed, 137 insertions(+), 75 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index f6ded475bb2c..42cc61230ca7 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -723,8 +723,6 @@ int intel_vgpu_init_gvt_context(struct intel_vgpu *vgpu)
>   if (IS_ERR(vgpu->shadow_ctx))
>   return PTR_ERR(vgpu->shadow_ctx);
>  
> - vgpu->shadow_ctx->engine[RCS].initialised = true;
> -
>   bitmap_zero(vgpu->shadow_ctx_desc_updated, I915_NUM_ENGINES);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 39883cd915db..cfcef1899da8 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1974,7 +1974,6 @@ static int i915_context_status(struct seq_file *m, void 
> *unused)
>   struct intel_context *ce = &ctx->engine[engine->id];
>  
>   seq_printf(m, "%s: ", engine->name);
> - seq_putc(m, ce->initialised ? 'I' : 'i');
>   if (ce->state)
>   describe_obj(m, ce->state->obj);
>   if (ce->ring)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index e36a3a840552..ed4b1708fec5 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4967,6 +4967,71 @@ bool intel_sanitize_semaphores(struct drm_i915_private 
> *dev_priv, int value)
>   return true;
>  }
>  
> +static int __intel_engines_record_defaults(struct drm_i915_private *i915)
> +{
> + struct i915_gem_context *ctx;
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> + int err;
> +
> + /*
> +  * As we reset the gpu during very early sanitisation, the current
> +  * register state on the GPU should reflect its defaults values.
> +  * We load a context onto the hw (with restore-inhibit), then switch
> +  * over to a second context to save that default register state. We
> +  * can then prime every new context with that state so they all start
> +  * from defaults.
> +  */
> +
> + ctx = i915_gem_context_create_kernel(i915, 0);
> + if (IS_ERR(ctx))
> + return PTR_ERR(ctx);
> +
> + for_each_engine(engine, i915, id) {
> + struct drm_i915_gem_request *rq;
> +
> + rq = i915_gem_request_alloc(engine, ctx);
> + if (IS_ERR(rq)) {
> + err = PTR_ERR(rq);
> + goto out_ctx;
> + }
> +
> + err = i915_switch_context(rq);
> + if (engine->init_context)
> + err = engine->init_context(rq);
> +
> + __i915_add_request(rq, true);
> + if (err)
> + goto out_ctx;
> + }
> +
> + err = i915_gem_switch_to_kernel_context(i915);
> + if (err)
> + goto out_ctx;
> +
> + err = i915_gem_wait_for_idle(i915, I915_WAIT_LOCKED);
> + if (err)
> + goto out_ctx;
> +
> + for_each_engine(engine, i915, id) {
> + if (!ctx->engine[id].state)
> + continue;
> +
> + engine->default_state =
> + i915_gem_object_get(ctx->engine[id].state->obj);
> +
> + err = i915_gem_object_set_to_cpu_domain(engine->default_state,
> + false);
> + if (err)
> + goto out_ctx;

Should we unmap the default context from the GTT here to make sure
the GPU never gets a chance to clobber it?

I also had the notion that context might save a copy of its CCID, and
that we'd potentially have to adjust it in every new context image. But
now that I look at the docs it seems pre-HSW CCID was part of the
runlist part of the context which we don't use, and on HSW it seems to
be saved

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce execlist_port_* accessors

[Mika Kuoppala]

Mika Kuoppala  writes:

> Chris Wilson  writes:
>
>> Quoting Mika Kuoppala (2017-11-02 10:38:30)
>>> Chris Wilson  writes:
>>> 
>>> > Quoting Mika Kuoppala (2017-10-31 15:27:33)
>>> >> +static inline struct execlist_port *
>>> >> +execlists_port_next(struct intel_engine_execlists * const execlists,
>>> >> +   const struct execlist_port * const port)
>>> >> +{
>>> >> +   const unsigned int n = __port_add(port_index(port, execlists),
>>> >> + 1,
>>> >> + execlists->port_mask);
>>> >
>>> > How does this compare to
>>> >
>>> >   if (port++ == execlists->port + execlists->port_mask)
>>> >   port = execlists->port;
>>> >
>>> >   return port;
>>> > ?
>>> 
>>> add/remove: 0/0 grow/shrink: 1/1 up/down: 29/-29 (0)
>>> function old new   delta
>>> i915_guc_irq_handler25842613 +29
>>> intel_lrc_irq_handler   29632934 -29
>>> Total: Before=1123627, After=1123627, chg +0.00%
>>
>> Hmm, your functions saw little difference and are twice as big as
>> mine... Weird.
>>
>> I used gcc version 6.3.0 20170516 (Debian 6.3.0-18) with defconfig.
>> Yourself?
>
> I had debugs on, sigh...
>
> Now with the defconfig and gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406:
>
> add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-139 (-139)
> function old new   delta
> i915_guc_irq_handler16201617  -3
> intel_lrc_irq_handler   19261790-136
>
> So we have a clear winner.
>

And to be precise on what diff lead to above:

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 387667fe50d3..9131d66fb628 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -599,12 +599,12 @@ execlists_port_tail(struct intel_engine_execlists * const 
execlists)
 
 static inline struct execlist_port *
 execlists_port_next(struct intel_engine_execlists * const execlists,
-   const struct execlist_port * const port)
+   struct execlist_port *port)
 {
-   const unsigned int n = __port_add(port_index(port, execlists),
- 1,
- execlists->port_mask);
-   return &execlists->port[n];
+   if (port++ == execlists->port + execlists->port_mask)
+   port = execlists->port;
+
+   return port;
 }



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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce execlist_port_* accessors

[Mika Kuoppala]

Chris Wilson  writes:

> Quoting Mika Kuoppala (2017-11-02 10:38:30)
>> Chris Wilson  writes:
>> 
>> > Quoting Mika Kuoppala (2017-10-31 15:27:33)
>> >> +static inline struct execlist_port *
>> >> +execlists_port_next(struct intel_engine_execlists * const execlists,
>> >> +   const struct execlist_port * const port)
>> >> +{
>> >> +   const unsigned int n = __port_add(port_index(port, execlists),
>> >> + 1,
>> >> + execlists->port_mask);
>> >
>> > How does this compare to
>> >
>> >   if (port++ == execlists->port + execlists->port_mask)
>> >   port = execlists->port;
>> >
>> >   return port;
>> > ?
>> 
>> add/remove: 0/0 grow/shrink: 1/1 up/down: 29/-29 (0)
>> function old new   delta
>> i915_guc_irq_handler25842613 +29
>> intel_lrc_irq_handler   29632934 -29
>> Total: Before=1123627, After=1123627, chg +0.00%
>
> Hmm, your functions saw little difference and are twice as big as
> mine... Weird.
>
> I used gcc version 6.3.0 20170516 (Debian 6.3.0-18) with defconfig.
> Yourself?

I had debugs on, sigh...

Now with the defconfig and gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406:

add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-139 (-139)
function old new   delta
i915_guc_irq_handler16201617  -3
intel_lrc_irq_handler   19261790-136

So we have a clear winner.

-Mika
___
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/dmc: DMC 1.04 for Kabylake

[Patchwork]

== Series Details ==

Series: drm/i915/dmc: DMC 1.04 for Kabylake
URL   : https://patchwork.freedesktop.org/series/33022/
State : success

== Summary ==

Series 33022v1 drm/i915/dmc: DMC 1.04 for Kabylake
https://patchwork.freedesktop.org/api/1.0/series/33022/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6700k)
Subgroup nonblocking-crc-pipe-b:
incomplete -> PASS   (fi-skl-6700k)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:449s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:461s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:384s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:534s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:509s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:513s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:508s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:492s
fi-cnl-y total:92   pass:88   dwarn:0   dfail:0   fail:0   skip:4  
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:431s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:268s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:594s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:494s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:433s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:436s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:486s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:578s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:588s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:568s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:601s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:650s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:523s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:521s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:458s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:580s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:422s
fi-cnl-y failed to connect after reboot

fca2506bc5d492609e3f1b6e59d667e376a1eb3f drm-tip: 2017y-11m-02d-13h-10m-58s UTC 
integration manifest
79e0033a464c drm/i915/dmc: DMC 1.04 for Kabylake

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Record the default hw state after reset upon load

[Chris Wilson]

Quoting Mika Kuoppala (2017-11-02 13:56:50)
> Chris Wilson  writes:
> > -
> > - execlists_init_reg_state(vaddr + LRC_STATE_PN * PAGE_SIZE,
> > -  ctx, engine, ring);
> > + regs = vaddr + LRC_STATE_PN * PAGE_SIZE;
> > + execlists_init_reg_state(regs, ctx, engine, ring);
> > + if (!engine->default_state) {
> > + regs[CTX_CONTEXT_CONTROL+1] |=
> > + 
> > _MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
> > + }
> 
> We will get the default state we copy from now with restore inhibit set
> for all copied context. Where do we clear it?

It's one of those magic bits that only affect the next context-switch.
When the context is saved again, the bit it cleared, so the default
state we inherit doesn't have that bit set.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Remove support for legacy debugfs crc interface

[Maarten Lankhorst]

This interface is deprecated, and has been replaced by the upstream
drm crc interface.

Signed-off-by: Maarten Lankhorst 
Cc: Tomi Sarvela 
Cc: Petri Latvala 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
 drivers/gpu/drm/i915/i915_drv.h   |  10 -
 drivers/gpu/drm/i915/i915_irq.c   |  79 ++
 drivers/gpu/drm/i915/intel_drv.h  |   2 -
 drivers/gpu/drm/i915/intel_pipe_crc.c | 446 --
 5 files changed, 23 insertions(+), 521 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7efe57c0703e..a362370e5a68 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4991,7 +4991,6 @@ static const struct i915_debugfs_files {
{"i915_gpu_info", &i915_gpu_info_fops},
 #endif
{"i915_next_seqno", &i915_next_seqno_fops},
-   {"i915_display_crc_ctl", &i915_display_crc_ctl_fops},
{"i915_pri_wm_latency", &i915_pri_wm_latency_fops},
{"i915_spr_wm_latency", &i915_spr_wm_latency_fops},
{"i915_cur_wm_latency", &i915_cur_wm_latency_fops},
@@ -5008,7 +5007,7 @@ int i915_debugfs_register(struct drm_i915_private 
*dev_priv)
 {
struct drm_minor *minor = dev_priv->drm.primary;
struct dentry *ent;
-   int ret, i;
+   int i;
 
ent = debugfs_create_file("i915_forcewake_user", S_IRUSR,
  minor->debugfs_root, to_i915(minor->dev),
@@ -5016,10 +5015,6 @@ int i915_debugfs_register(struct drm_i915_private 
*dev_priv)
if (!ent)
return -ENOMEM;
 
-   ret = intel_pipe_crc_create(minor);
-   if (ret)
-   return ret;
-
for (i = 0; i < ARRAY_SIZE(i915_debugfs_files); i++) {
ent = debugfs_create_file(i915_debugfs_files[i].name,
  S_IRUGO | S_IWUSR,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d37fd11908d0..f4290c9739e1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1948,19 +1948,9 @@ enum intel_pipe_crc_source {
INTEL_PIPE_CRC_SOURCE_MAX,
 };
 
-struct intel_pipe_crc_entry {
-   uint32_t frame;
-   uint32_t crc[5];
-};
-
 #define INTEL_PIPE_CRC_ENTRIES_NR  128
 struct intel_pipe_crc {
spinlock_t lock;
-   bool opened;/* exclusive access to the result file */
-   struct intel_pipe_crc_entry *entries;
-   enum intel_pipe_crc_source source;
-   int head, tail;
-   wait_queue_head_t wq;
int skipped;
 };
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ff00e462697a..be119cb567a4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1613,69 +1613,34 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
 uint32_t crc4)
 {
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
-   struct intel_pipe_crc_entry *entry;
struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
-   struct drm_driver *driver = dev_priv->drm.driver;
uint32_t crcs[5];
-   int head, tail;
 
spin_lock(&pipe_crc->lock);
-   if (pipe_crc->source) {
-   if (!pipe_crc->entries) {
-   spin_unlock(&pipe_crc->lock);
-   DRM_DEBUG_KMS("spurious interrupt\n");
-   return;
-   }
-
-   head = pipe_crc->head;
-   tail = pipe_crc->tail;
-
-   if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
-   spin_unlock(&pipe_crc->lock);
-   DRM_ERROR("CRC buffer overflowing\n");
-   return;
-   }
-
-   entry = &pipe_crc->entries[head];
-
-   entry->frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
-   entry->crc[0] = crc0;
-   entry->crc[1] = crc1;
-   entry->crc[2] = crc2;
-   entry->crc[3] = crc3;
-   entry->crc[4] = crc4;
-
-   head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
-   pipe_crc->head = head;
-
-   spin_unlock(&pipe_crc->lock);
-
-   wake_up_interruptible(&pipe_crc->wq);
-   } else {
-   /*
-* For some not yet identified reason, the first CRC is
-* bonkers. So let's just wait for the next vblank and read
-* out the buggy result.
-*
-* On GEN8+ sometimes the second CRC is bonkers as well, so
-* don't trust that one either.
-*/
-   if (pipe_crc->skipped == 0 ||
-   (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped == 1)) {
-   pipe_crc->skipped++;
-   spin_un

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Record the default hw state after reset upon load

[Mika Kuoppala]

Chris Wilson  writes:

> Take a copy of the HW state after a reset upon module loading by
> executing a context switch from a blank context to the kernel context,
> thus saving the default hw state over the blank context image.
> We can then use the default hw state to initialise any future context,
> ensuring that each starts with the default view of hw state.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c|  2 -
>  drivers/gpu/drm/i915/i915_debugfs.c |  1 -
>  drivers/gpu/drm/i915/i915_gem.c | 69 
> +
>  drivers/gpu/drm/i915/i915_gem_context.c | 50 +++-
>  drivers/gpu/drm/i915/i915_gem_context.h |  4 +-
>  drivers/gpu/drm/i915/intel_engine_cs.c  |  3 ++
>  drivers/gpu/drm/i915/intel_lrc.c| 35 ++---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 47 +++---
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
>  9 files changed, 137 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index f6ded475bb2c..42cc61230ca7 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -723,8 +723,6 @@ int intel_vgpu_init_gvt_context(struct intel_vgpu *vgpu)
>   if (IS_ERR(vgpu->shadow_ctx))
>   return PTR_ERR(vgpu->shadow_ctx);
>  
> - vgpu->shadow_ctx->engine[RCS].initialised = true;
> -
>   bitmap_zero(vgpu->shadow_ctx_desc_updated, I915_NUM_ENGINES);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 39883cd915db..cfcef1899da8 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1974,7 +1974,6 @@ static int i915_context_status(struct seq_file *m, void 
> *unused)
>   struct intel_context *ce = &ctx->engine[engine->id];
>  
>   seq_printf(m, "%s: ", engine->name);
> - seq_putc(m, ce->initialised ? 'I' : 'i');
>   if (ce->state)
>   describe_obj(m, ce->state->obj);
>   if (ce->ring)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index e36a3a840552..ed4b1708fec5 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4967,6 +4967,71 @@ bool intel_sanitize_semaphores(struct drm_i915_private 
> *dev_priv, int value)
>   return true;
>  }
>  
> +static int __intel_engines_record_defaults(struct drm_i915_private *i915)
> +{
> + struct i915_gem_context *ctx;
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> + int err;
> +
> + /*
> +  * As we reset the gpu during very early sanitisation, the current
> +  * register state on the GPU should reflect its defaults values.
> +  * We load a context onto the hw (with restore-inhibit), then switch
> +  * over to a second context to save that default register state. We
> +  * can then prime every new context with that state so they all start
> +  * from defaults.
> +  */
> +
> + ctx = i915_gem_context_create_kernel(i915, 0);
> + if (IS_ERR(ctx))
> + return PTR_ERR(ctx);
> +
> + for_each_engine(engine, i915, id) {
> + struct drm_i915_gem_request *rq;
> +
> + rq = i915_gem_request_alloc(engine, ctx);
> + if (IS_ERR(rq)) {
> + err = PTR_ERR(rq);
> + goto out_ctx;
> + }
> +
> + err = i915_switch_context(rq);
> + if (engine->init_context)
> + err = engine->init_context(rq);
> +
> + __i915_add_request(rq, true);
> + if (err)
> + goto out_ctx;
> + }
> +
> + err = i915_gem_switch_to_kernel_context(i915);
> + if (err)
> + goto out_ctx;
> +
> + err = i915_gem_wait_for_idle(i915, I915_WAIT_LOCKED);
> + if (err)
> + goto out_ctx;
> +
> + for_each_engine(engine, i915, id) {
> + if (!ctx->engine[id].state)
> + continue;
> +
> + engine->default_state =
> + i915_gem_object_get(ctx->engine[id].state->obj);
> +
> + err = i915_gem_object_set_to_cpu_domain(engine->default_state,
> + false);
> + if (err)
> + goto out_ctx;
> + }
> +
> +out_ctx:
> + i915_gem_context_set_closed(ctx);
> + i915_gem_context_put(ctx);
> + return err;
> +}
> +
>  int i915_gem_init(struct drm_i915_private *dev_priv)
>  {
>   int ret;
> @@ -5022,6 +5087,10 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
>  
>   intel_init_gt_powersave(dev_priv);
>  
> + ret = __intel_engines_record_defaults(dev_priv);
> + if (ret)
> + goto out_un

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Inline intel_modeset_gem_init()

[Joonas Lahtinen]

On Thu, 2017-11-02 at 12:42 +, Chris Wilson wrote:
> intel_modeset_gem_init() now only sets up the legacy overlay, so let's
> remove the function and call the setup directly during driver load. This
> should help us find a better point in the initialisation sequence for it
> later.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: silence coverity warning (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: silence coverity warning (rev2)
URL   : https://patchwork.freedesktop.org/series/33041/
State : warning

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
pass   -> DMESG-WARN (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-cur-indfb-draw-blt:
skip   -> PASS   (shard-hsw)
Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt:
skip   -> PASS   (shard-hsw)
Test kms_atomic_transition:
Subgroup plane-all-transition-fencing:
skip   -> PASS   (shard-hsw)
Subgroup plane-all-modeset-transition:
skip   -> PASS   (shard-hsw)
Test kms_flip:
Subgroup wf_vblank-vs-dpms-interruptible:
skip   -> PASS   (shard-hsw) fdo#102614
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-hsw) fdo#102254

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

shard-hswtotal:2539 pass:1429 dwarn:3   dfail:0   fail:10  skip:1097 
time:9315s

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Move GT powersaving init to i915_gem_init()

[Joonas Lahtinen]

On Thu, 2017-11-02 at 12:42 +, Chris Wilson wrote:
> GT powersaving is tightly coupled to the request infrastructure. To
> avoid complications with the order of initialisation in the next patch
> (where we want to send requests to hw during GEM init) move the
> powersaving initialisation into the purview of i915_gem_init().
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Force the switch to the i915->kernel_context

[Joonas Lahtinen]

On Thu, 2017-11-02 at 12:42 +, Chris Wilson wrote:
> In the next few patches, we will have a hard requirement that we emit a
> context-switch to the perma-pinned i915->kernel_context (so that we can
> save the HW state using that context-switch). As the first context
> itself may be classed as a kernel context, we want to be explicit in our
> comparison. For an extra-layer of finesse, we can check the last
> unretired context on the engine; as well as the last retired context
> when idle.
> 
> Signed-off-by: Chris Wilson 



> @@ -1587,8 +1587,20 @@ bool intel_engines_are_idle(struct drm_i915_private 
> *dev_priv)
>  
>  bool intel_engine_has_kernel_context(const struct intel_engine_cs *engine)
>  {
> - return (!engine->last_retired_context ||
> - i915_gem_context_is_kernel(engine->last_retired_context));
> + const struct i915_gem_context *kctx = engine->i915->kernel_context;

*kernel_context = ...

> + struct drm_i915_gem_request *rq;
> +
> + lockdep_assert_held(&engine->i915->drm.struct_mutex);
> +
> + /* An unretired request? */
> + rq = __i915_gem_active_peek(&engine->timeline->last_request);
> + if (rq)
> + return rq->ctx == kctx;
> +
> + if (!engine->last_retired_context)
> + return true;
> +
> + return engine->last_retired_context == kctx;

It might be worthy dropping a comment that a nonexistent context is
considered kernel context to the *cough*nonexistent*cough* kerneldoc.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: silence coverity warning

[Chris Wilson]

Quoting Ville Syrjälä (2017-11-02 13:22:51)
> On Thu, Nov 02, 2017 at 12:06:27PM +, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2017-11-02 11:41:26)
> > > Because dev_priv is 0-ed it's not currently an issue, but since we
> > > have dev_priv->perf.oa.test_config.uuid size at uuid + 1, we could
> > > just copy the null character and silence this warning.
> > 
> > It doesn't copy the nul over exactly, to be complete s/strncpy/strlcpy/
> > as well.
> 
> Or just memcpy(), thugh maybe that'd be more dangerous if the size
> gets changed for some reasonn.

struct uuid { char [UUID_STRING_LEN+1]; }

test_config.uuid = (struct uuid) { "---" };

?

The compiler should then warn if it wants to about the string being the
wrong size; anything too short is nul-extended.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] kms_atomic_transition: Split out modeset tests on internal panels

[Imre Deak]

Doing modeset on internal panels may have a considerable overhead due to
the panel specific power sequencing delays. To avoid long test runtimes
in the CI fast-feedback test split out the testing of internal panels
from the plane modeset subtests. Create fast and slow versions of these
new subtests. In the fast one only combinations with all enabled, all
planes disabled or a single plane enable are tested. In the slow one all
plane combinations are tested.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103334
Cc: Maarten Lankhorst 
Signed-off-by: Imre Deak 
---
 tests/kms_atomic_transition.c | 64 ---
 1 file changed, 60 insertions(+), 4 deletions(-)

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 4c295125..c27e48e1 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -189,6 +189,7 @@ enum transition_type {
TRANSITION_PLANES,
TRANSITION_AFTER_FREE,
TRANSITION_MODESET,
+   TRANSITION_MODESET_PLANES_FAST,
TRANSITION_MODESET_DISABLE,
 };
 
@@ -528,6 +529,10 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output
}
 
for (i = 0; i < iter_max; i++) {
+   if (type == TRANSITION_MODESET_PLANES_FAST &&
+   hweight32(i) != 1 && hweight32(i) != pipe_obj->n_planes)
+   continue;
+
igt_output_set_pipe(output, pipe);
 
wm_setup_plane(display, pipe, i, parms, fencing);
@@ -547,16 +552,20 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output
 
/* i -> i+1 will be done when i increases, can be 
skipped here */
for (j = iter_max - 1; j > i + 1; j--) {
+   if (type == TRANSITION_MODESET_PLANES_FAST &&
+   hweight32(j) != 1 && hweight32(j) != 
pipe_obj->n_planes)
+   continue;
+
wm_setup_plane(display, pipe, j, parms, 
fencing);
 
-   if (type == TRANSITION_MODESET)
+   if (type >= TRANSITION_MODESET)
igt_output_override_mode(output, 
&override_mode);
 
atomic_commit(display, pipe, flags, (void 
*)(unsigned long) j, fencing);
wait_for_transition(display, pipe, nonblocking, 
fencing);
 
wm_setup_plane(display, pipe, i, parms, 
fencing);
-   if (type == TRANSITION_MODESET)
+   if (type >= TRANSITION_MODESET)
igt_output_override_mode(output, NULL);
 
atomic_commit(display, pipe, flags, (void 
*)(unsigned long) i, fencing);
@@ -864,6 +873,19 @@ static void run_modeset_transition(igt_display_t *display, 
int requested_outputs
run_modeset_tests(display, requested_outputs, nonblocking, fencing);
 }
 
+static bool output_is_internal_panel(igt_output_t *output)
+{
+   switch (output->config.connector->connector_type) {
+   case DRM_MODE_CONNECTOR_LVDS:
+   case DRM_MODE_CONNECTOR_eDP:
+   case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_DPI:
+   return true;
+   default:
+   return false;
+   }
+}
+
 igt_main
 {
igt_display_t display;
@@ -914,12 +936,46 @@ igt_main
run_transition_test(&display, pipe, output, 
TRANSITION_AFTER_FREE, true, true);
 
igt_subtest("plane-all-modeset-transition")
-   for_each_pipe_with_valid_output(&display, pipe, output)
+   for_each_pipe_with_valid_output(&display, pipe, output) {
+   if (output_is_internal_panel(output))
+   continue;
run_transition_test(&display, pipe, output, 
TRANSITION_MODESET, false, false);
+   }
 
igt_subtest("plane-all-modeset-transition-fencing")
-   for_each_pipe_with_valid_output(&display, pipe, output)
+   for_each_pipe_with_valid_output(&display, pipe, output) {
+   if (output_is_internal_panel(output))
+   continue;
run_transition_test(&display, pipe, output, 
TRANSITION_MODESET, false, true);
+   }
+
+   igt_subtest("plane-all-modeset-transition-internal-panels-fast")
+   for_each_pipe_with_valid_output(&display, pipe, output) {
+   if (!output_is_internal_panel(output))
+   continue;
+   run_transition_test(&display, pipe, output, 
TRANSITION_MODESET_PLANES_FAST, false, false);
+   }
+
+   igt_subtest("plane-all-modeset-transition-fencing-internal-panels-fast")
+  

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Remove redundant intel_autoenable_gt_powersave()

[Joonas Lahtinen]

On Thu, 2017-11-02 at 12:42 +, Chris Wilson wrote:
> Now that we always execute a context switch upon module load, there is
> no need to queue a delayed task for doing so. The purpose of the delayed
> task is to enable GT powersaving, for which we need the HW state to be
> valid (i.e. having loaded a context and initialised basic state). We
> used to defer this operation as historically it was slow (due to slow
> register polling, fixed with commit 1758b90e38f5 ("drm/i915: Use a hybrid
> scheme for fast register waits")) but now we have a requirement to save
> the default HW state.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] kms_atomic_transition: Add subtest time limit/randomize plane, pipe combinations

[Imre Deak]

On Wed, Nov 01, 2017 at 01:08:47PM +0200, Imre Deak wrote:
> On Wed, Nov 01, 2017 at 10:48:50AM +, Chris Wilson wrote:
> > Quoting Imre Deak (2017-11-01 09:56:22)
> > > On Tue, Oct 31, 2017 at 10:23:25PM +, Chris Wilson wrote:
> > > > Quoting Imre Deak (2017-10-31 13:44:47)
> > > > > Doing modeset on internal panels may have a considerable overhead due 
> > > > > to
> > > > > the panel specific power sequencing delays. To avoid long test 
> > > > > runtimes
> > > > > limit the runtime of each subtest. Randomize the plane/pipe 
> > > > > combinations
> > > > > to preserve the test coverage on such panels at least over multiple 
> > > > > test
> > > > > runs.
> > > > > 
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103334
> > > > > Cc: Maarten Lankhorst 
> > > > > Signed-off-by: Imre Deak 
> > > > > ---
> > > > >  tests/kms_atomic_transition.c | 175 
> > > > > --
> > > > >  1 file changed, 150 insertions(+), 25 deletions(-)
> > > > > 
> > > > > diff --git a/tests/kms_atomic_transition.c 
> > > > > b/tests/kms_atomic_transition.c
> > > > > index 4c295125..ac67fc3a 100644
> > > > > --- a/tests/kms_atomic_transition.c
> > > > > +++ b/tests/kms_atomic_transition.c
> > > > > @@ -39,6 +39,14 @@
> > > > >  #define DRM_CAP_CURSOR_HEIGHT 0x9
> > > > >  #endif
> > > > >  
> > > > > +#define MAX_SUBTEST_DURATION_NS (20ULL * NSEC_PER_SEC)
> > > > > +
> > > > > +struct test_config {
> > > > > +   igt_display_t *display;
> > > > > +   bool user_seed;
> > > > > +   int seed;
> > > > > +};
> > > > > +
> > > > >  struct plane_parms {
> > > > > struct igt_fb *fb;
> > > > > uint32_t width, height;
> > > > > @@ -401,6 +409,28 @@ static void wait_for_transition(igt_display_t 
> > > > > *display, enum pipe pipe, bool non
> > > > > }
> > > > >  }
> > > > >  
> > > > > +/* Copied from https://benpfaff.org/writings/clc/shuffle.html */
> > > > > +static void shuffle_array(uint32_t *array, int size, int seed)
> > > > > +{
> > > > > +   int i;
> > > > > +
> > > > > +   for (i = 0; i < size; i++) {
> > > > > +   int j = i + rand() / (RAND_MAX / (size - i) + 1);
> > > > > +
> > > > > +   igt_swap(array[i], array[j]);
> > > > > +   }
> > > > > +}
> > > > 
> > > > igt_permute_array()
> > > 
> > > Thanks, will use that instead.
> > > 
> > > > Not saying anything, but I was told using CI for stochastic coverage was
> > > > a flat no...
> > > 
> > > Ok, but it would only be the case for slow panels where the alternative
> > > is not to run the test at all. And is this a problem if we can replay a
> > > failing case with --seed?
> > 
> > If the purpose of CI is purely regression testing and not exploratory
> > debugging, each PW run must be with the same seed as the CI_DRM run.
> > 
> > The seed must be clearly displayed in the results so that when comparing
> > CI_DRM runs the flip-flop can be traced to the change in seed.
> 
> Adding Petri and Tomi. So I guess the question is if we want this in CI
> and if it's a reasonable effort to implement it.

Discussing more with Tomi and Martin, the randomization idea is not so
practical at least for now.

So another approach would be to split out the testing on internal panels
from plane-all-modeset-transition and
plane-all-modeset-transition-fencing. We could have fast and slow
version of these internal-panel tests where the fast one would test all
combinations and the slow one only combinations with either all planes
on/off or only a single plane on. We could then include only the fast
versions in the fast-feedback testlist.

Will follow up with a version doing the above.

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

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for tests: add device information tests

[Arkadiusz Hiler]

On Tue, Oct 31, 2017 at 11:02:46AM +, Lionel Landwerlin wrote:
> On 31/10/17 09:21, Petri Latvala wrote:
> > On Mon, Oct 30, 2017 at 02:11:10PM +, Patchwork wrote:
> > > == Series Details ==
> > > 
> > > Series: tests: add device information tests
> > > URL   : https://patchwork.freedesktop.org/series/32764/
> > > State : success
> > > 
> > > == Summary ==
> > > 
> > > Test kms_flip:
> > >  Subgroup basic-flip-vs-wf_vblank:
> > >  fail   -> PASS   (shard-hsw) fdo#100368
> > >  Subgroup wf_vblank-vs-dpms-interruptible:
> > >  pass   -> DMESG-WARN (shard-hsw) fdo#102614
> > > Test kms_busy:
> > >  Subgroup extended-modeset-hang-newfb-with-reset-render-A:
> > >  pass   -> DMESG-WARN (shard-hsw) fdo#102249 +2
> > > 
> > 
> > Status of new tests are not shown here.
> > 
> > Only SNB, HSW and APL execute shards for patchwork, and their results are:
> > 
> > All new tests skipped, except for topology-pre-gen8 which failed on SNB and 
> > HSW.
> > 
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_442/shard-hsw4/igt@intel_device_i...@topology-pre-gen8.html
> > 
> > 
> > 
> Thanks, will check this.

BTW, if you want to give them a spin on the other machines send a series
with a "HAX" commit that adds the tests to fast-feedback list.

> ___
> 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] drm/i915: silence coverity warning

[Ville Syrjälä]

On Thu, Nov 02, 2017 at 12:06:27PM +, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2017-11-02 11:41:26)
> > Because dev_priv is 0-ed it's not currently an issue, but since we
> > have dev_priv->perf.oa.test_config.uuid size at uuid + 1, we could
> > just copy the null character and silence this warning.
> 
> It doesn't copy the nul over exactly, to be complete s/strncpy/strlcpy/
> as well.

Or just memcpy(), thugh maybe that'd be more dangerous if the size
gets changed for some reasonn.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_debugfs: Remove support for legacy CRC api.

[Maarten Lankhorst]

Op 27-10-17 om 14:25 schreef Petri Latvala:
> On Fri, Oct 27, 2017 at 10:05:39AM +0200, Maarten Lankhorst wrote:
>> Op 27-10-17 om 09:39 schreef Jani Nikula:
>>> On Thu, 26 Oct 2017, James Ausmus  wrote:
 On Thu, Oct 26, 2017 at 01:38:51PM +0200, Maarten Lankhorst wrote:
> In kernel v4.10 the legacy crc api has been replaced by a generic
> drm crc API. While at it, fix igt_require_pipe_crc, the file cannot be
> opened any more when the crtc is not active after kernel commit 
> 8038e09be5a3
> ("drm/crc: Only open CRC on atomic drivers when the CRTC is active.").
> Statting the file should be enough for testing it's supported.
 What's the impact of this change on devices running older kernels - such
 as KBL ChromeOS on 4.4?
>>> If you backport kernel features, you either also backport the new kernel
>>> CRC API, or forward port the igt support for the legacy debugfs if you
>>> want to use latest upstream igt?
>> It's part of the DRM api. Either you're using the old v4.4 kernel in which
>> case a lot of tests in IGT would have already failed, or when you backport
>> you backport the drm module too. Too much has changed between v4.4 and
>> drm-tip, there's no way you can just grab a current snapshot of the driver
>> and expect it to work in v4.4
>
> Fair enough.
>
> This is
> Acked-by: Petri Latvala 
>
> but someone(tm) should volunteer to review the actual changes.

Pushed, thanks for review. :)

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

Re: [Intel-gfx] [PATCH 3/5] drm/vmwgfx: Try to fix plane clipping

[Ville Syrjälä]

On Thu, Nov 02, 2017 at 11:12:09AM +0100, Daniel Vetter wrote:
> On Wed, Nov 01, 2017 at 08:29:18PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Try to fix the code to actually clip the plane to the crtc bounds
> > instead of the user provided crtc coordinates (which would be a no-op
> > since those are exactly the coordinates before clipping).
> > 
> > Cc: VMware Graphics 
> > Cc: Sinclair Yeh 
> > Cc: Thomas Hellstrom 
> > Signed-off-by: Ville Syrjälä 
> 
> I kinda wonder whether we shouldn't push this down into the helper ...

Would require quite going through all drivers making sure they are
happy with using the adjusted_mode.crtc_ timings. I think most drivers
use the other adjusted_mode timings currently, and some even use the
user mode timings (which could be an actual bug).

> 
> Either way, Reviewed-by: Daniel Vetter 
> 
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 23 +--
> >  1 file changed, 13 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > index 515b67783a41..efa41c086198 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > @@ -441,20 +441,23 @@ vmw_du_cursor_plane_atomic_update(struct drm_plane 
> > *plane,
> >  int vmw_du_primary_plane_atomic_check(struct drm_plane *plane,
> >   struct drm_plane_state *state)
> >  {
> > +   struct drm_crtc_state *crtc_state = NULL;
> > struct drm_framebuffer *new_fb = state->fb;
> > -   struct drm_rect clip = {
> > -   .x1 = state->crtc_x,
> > -   .y1 = state->crtc_y,
> > -   .x2 = state->crtc_x + state->crtc_w,
> > -   .y2 = state->crtc_y + state->crtc_h,
> > -   };
> > +   struct drm_rect clip = {};
> > int ret;
> >  
> > -   ret = drm_plane_helper_check_state(state, &clip,
> > -   DRM_PLANE_HELPER_NO_SCALING,
> > -   DRM_PLANE_HELPER_NO_SCALING,
> > -   false, true);
> > +   if (state->crtc)
> > +   crtc_state = drm_atomic_get_new_crtc_state(state->state, 
> > state->crtc);
> >  
> > +   if (crtc_state && crtc_state->enable) {
> > +   clip.x2 = crtc_state->adjusted_mode.hdisplay;
> > +   clip.y2 = crtc_state->adjusted_mode.vdisplay;
> > +   }
> > +
> > +   ret = drm_plane_helper_check_state(state, &clip,
> > +  DRM_PLANE_HELPER_NO_SCALING,
> > +  DRM_PLANE_HELPER_NO_SCALING,
> > +  false, true);
> >  
> > if (!ret && new_fb) {
> > struct drm_crtc *crtc = state->crtc;
> > -- 
> > 2.13.6
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Set up mocs tables before restarting the engines

[Chris Wilson]

After a reset, we may immediately begin executing requests on restarting
the engines. Ergo this has to be last step with all re-initialisation
completed beforehand. The mocs setup was after we started executing the
requests; do it earlier!

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 56df32fe5c5d..44f65c8bd254 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4936,13 +4936,10 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
if (ret)
goto out;
 
-   /* Need to do basic initialisation of all rings first: */
-   ret = __i915_gem_restart_engines(dev_priv);
-   if (ret)
-   goto out;
-
intel_mocs_init_l3cc_table(dev_priv);
 
+   /* Only when the HW is re-initialised, can we replay the requests */
+   ret = __i915_gem_restart_engines(dev_priv);
 out:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
return ret;
-- 
2.15.0

___
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/6] drm/i915: Force the switch to the i915->kernel_context

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915: Force the switch to the 
i915->kernel_context
URL   : https://patchwork.freedesktop.org/series/33046/
State : failure

== Summary ==

Series 33046v1 series starting with [1/6] drm/i915: Force the switch to the 
i915->kernel_context
https://patchwork.freedesktop.org/api/1.0/series/33046/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Test gem_exec_reloc:
Subgroup basic-cpu-active:
fail   -> PASS   (fi-gdg-551) fdo#102582 +1
Test kms_busy:
Subgroup basic-flip-a:
pass   -> INCOMPLETE (fi-glk-dsi)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
incomplete -> PASS   (fi-cnl-y) fdo#103339
Test kms_frontbuffer_tracking:
Subgroup basic:
dmesg-warn -> PASS   (fi-bdw-5557u) fdo#102473

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#102582 https://bugs.freedesktop.org/show_bug.cgi?id=102582
fdo#103339 https://bugs.freedesktop.org/show_bug.cgi?id=103339
fdo#102473 https://bugs.freedesktop.org/show_bug.cgi?id=102473

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:455s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:379s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:536s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:503s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:507s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:507s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:492s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:600s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:427s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:264s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:582s
fi-glk-dsi   total:206  pass:183  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:428s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:426s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:485s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:573s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:584s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:570s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:588s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:652s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:520s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:463s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:575s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:422s

dcf7d008f606b543fef53609a6e336097e6b5694 drm-tip: 2017y-11m-02d-08h-43m-13s UTC 
integration manifest
028a928e8aeb drm/i915: Stop caching the "golden" renderstate
b5b2ad90612f drm/i915: Remove redundant intel_autoenable_gt_powersave()
6bb7725f5687 drm/i915: Record the default hw state after reset upon load
dd82c688f3f9 drm/i915: Inline intel_modeset_gem_init()
a3899988bc8e drm/i915: Move GT powersaving init to i915_gem_init()
5325edbb2409 drm/i915: Force the switch to the i915->kernel_context

== Logs ==

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