[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts 
on hsw
URL   : https://patchwork.freedesktop.org/series/40704/
State : success

== Summary ==

 Known issues:

Test kms_flip:
Subgroup blocking-wf_vblank:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-apl) fdo#103925

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

shard-apltotal:3495 pass:1831 dwarn:1   dfail:0   fail:7   skip:1655 
time:12899s
shard-hswtotal:3495 pass:1782 dwarn:1   dfail:0   fail:2   skip:1709 
time:11695s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:6976s
Blacklisted hosts:
shard-kbltotal:3495 pass:1956 dwarn:1   dfail:1   fail:9   skip:1528 
time:9652s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit

[Patchwork]

== Series Details ==

Series: series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit
URL   : https://patchwork.freedesktop.org/series/40702/
State : success

== Summary ==

 Known issues:

Test kms_flip:
Subgroup flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-gtt:
pass   -> DMESG-FAIL (shard-apl) fdo#103167 +1
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-apl) fdo#105685
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-apl) fdo#103925

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

shard-apltotal:3495 pass:1828 dwarn:1   dfail:1   fail:9   skip:1655 
time:12937s
shard-hswtotal:3495 pass:1779 dwarn:1   dfail:0   fail:5   skip:1709 
time:11549s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:7004s
Blacklisted hosts:
shard-kbltotal:3495 pass:1954 dwarn:1   dfail:1   fail:10  skip:1529 
time:9759s

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add NV12 support (rev4)

[Srinivas, Vidya]

> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Monday, March 26, 2018 7:19 PM
> To: Patchwork ; Srinivas, Vidya
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add NV12 support
> (rev4)
> 
> On Mon, 26 Mar 2018, Patchwork 
> wrote:
> > == Series Details ==
> >
> > Series: Add NV12 support (rev4)
> > URL   : https://patchwork.freedesktop.org/series/39670/
> > State : warning
> >
> > == Summary ==
> >
> > $ dim checkpatch origin/drm-tip
> > 0503b1db737a drm/i915/skl+: rename skl_wm_values struct to
> > skl_ddb_values
> > de530aafc1d7 drm/i915/skl+: refactor WM calculation for NV12
> > 7ca6efaada2b drm/i915/skl+: add NV12 in skl_format_to_fourcc
> > 4863044b11a5 drm/i915/skl+: support verification of DDB HW state for
> > NV12 4c4d4f07274c drm/i915/skl+: NV12 related changes for WM
> > 1995882fa722 drm/i915/skl+: pass skl_wm_level struct to wm compute
> > func
> > 7a53eb021631 drm/i915/skl+: make sure higher latency level has higher
> > wm value
> > b756f5e1b974 drm/i915/skl+: nv12 workaround disable WM level 1-7
> > 2f6264f9349f drm/i915/skl: split skl_compute_ddb function
> > -:137: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV)
> > #137: FILE: drivers/gpu/drm/i915/intel_pm.c:5160:
> > +   *changed = true;
> > ^
> 
> Checkpatch being clueless.
> 
> >
> > total: 0 errors, 0 warnings, 1 checks, 194 lines checked d87f6cf26fea
> > drm/i915: Set scaler mode for NV12 ccc7a37f5e0a drm/i915: Update
> > format_is_yuv() to include NV12
> > 17490b4ce656 drm/i915: Upscale scaler max scale for NV12
> > e155048376b9 drm/i915: Add NV12 as supported format for primary plane
> > d7af95f5e1d4 drm/i915: Add NV12 as supported format for sprite plane
> > 483020f92c69 drm/i915: Add NV12 support to intel_framebuffer_init
> > 4ca02e5f9bd0 drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
> > a7f9ce556ab2 drm/i915: Display WA 827
> > 545fe6ed4604 drm/i915: Add checks to primary plane
> > -:108: CHECK:SPACING: No space is necessary after a cast
> > #108: FILE: drivers/gpu/drm/i915/intel_display.c:13052:
> > +   WARN_ON(src->x1 < (int) state->base.src_x ||
> >
> > -:109: CHECK:SPACING: No space is necessary after a cast
> > #109: FILE: drivers/gpu/drm/i915/intel_display.c:13053:
> > +   src->y1 < (int) state->base.src_y ||
> >
> > -:110: CHECK:SPACING: No space is necessary after a cast
> > #110: FILE: drivers/gpu/drm/i915/intel_display.c:13054:
> > +   src->x2 > (int) state->base.src_x + state->base.src_w
> ||
> >
> > -:111: CHECK:SPACING: No space is necessary after a cast
> > #111: FILE: drivers/gpu/drm/i915/intel_display.c:13055:
> > +   src->y2 > (int) state->base.src_y + state-
> >base.src_h);
> >
> 
> I don't mind the spaces after a cast; sadly SPACING category is not
> something I'm willing to ignore completely.
> 
> > -:148: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open
> > parenthesis
> > #148: FILE: drivers/gpu/drm/i915/intel_display.c:13092:
> > +   if (INTEL_GEN(dev_priv) < 9 && (src_w > 2048 || src_h >
> 2048 ||
> > +   width_bytes > 4096 || fb->pitches[0] > 4096)) {
> 
> Pedantically a valid warning, but can be ignored in favor of getting the 
> series
> finally merged.

Thank you. Since this is new patch (sorry, mostly I just copied code from 
intel_sprite.c)
Still RB is needed on this patch. I will fix these mistakes during the next 
push.

> 
> BR,
> Jani.
> 
> >
> > total: 0 errors, 0 warnings, 5 checks, 148 lines checked
> >
> > ___
> > 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] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts 
on hsw
URL   : https://patchwork.freedesktop.org/series/40704/
State : success

== Summary ==

Series 40704v1 series starting with [v2,1/4] drm/i915: Enable edp psr error 
interrupts on hsw
https://patchwork.freedesktop.org/api/1.0/series/40704/revisions/1/mbox/

 Known issues:

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

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:546s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:299s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:521s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:510s
fi-cnl-y3total:285  pass:258  dwarn:1   dfail:0   fail:0   skip:26  
time:584s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:429s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:318s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:477s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:514s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:659s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:542s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:507s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:431s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:575s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:401s
Blacklisted hosts:
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-cnl-psr   total:224  pass:198  dwarn:0   dfail:0   fail:1   skip:24 
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:487s

d439f4eca05fe48c26bf9c3863e56ee19ac1c50b drm-tip: 2018y-03m-27d-00h-15m-56s UTC 
integration manifest
f4ea75bae00f drm/i915/psr: Timestamps for PSR entry and exit interrupts.
07e5a8224b22 drm/i915/psr: Control PSR interrupts via debugfs
d27113364c8d drm/i915: Enable edp psr error interrupts on bdw+
e0e155ae5044 drm/i915: Enable edp psr error interrupts on hsw

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts 
on hsw
URL   : https://patchwork.freedesktop.org/series/40704/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e0e155ae5044 drm/i915: Enable edp psr error interrupts on hsw
-:109: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#109: FILE: drivers/gpu/drm/i915/i915_reg.h:4011:
+#define   EDP_PSR_ERROR(1<<2)
  ^

-:110: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#110: FILE: drivers/gpu/drm/i915/i915_reg.h:4012:
+#define   EDP_PSR_POST_EXIT(1<<1)
  ^

-:111: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#111: FILE: drivers/gpu/drm/i915/i915_reg.h:4013:
+#define   EDP_PSR_PRE_ENTRY(1<<0)
  ^

-:120: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#120: FILE: drivers/gpu/drm/i915/i915_reg.h:6821:
+#define DE_EDP_PSR_INT_HSW (1<<19)
  ^

total: 0 errors, 0 warnings, 4 checks, 78 lines checked
d27113364c8d drm/i915: Enable edp psr error interrupts on bdw+
-:158: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#158: FILE: drivers/gpu/drm/i915/intel_display.h:221:
+#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
+   for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++)  \
+   for_each_if ((__mask) & (1 << (__t)))

-:158: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__t' - possible 
side-effects?
#158: FILE: drivers/gpu/drm/i915/intel_display.h:221:
+#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
+   for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++)  \
+   for_each_if ((__mask) & (1 << (__t)))

-:159: CHECK:SPACING: No space is necessary after a cast
#159: FILE: drivers/gpu/drm/i915/intel_display.h:222:
+   for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++)  \

-:160: WARNING:SPACING: space prohibited between function name and open 
parenthesis '('
#160: FILE: drivers/gpu/drm/i915/intel_display.h:223:
+   for_each_if ((__mask) & (1 << (__t)))

total: 1 errors, 1 warnings, 2 checks, 123 lines checked
07e5a8224b22 drm/i915/psr: Control PSR interrupts via debugfs
f4ea75bae00f drm/i915/psr: Timestamps for PSR entry and exit interrupts.

___
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 [v2,01/10] drm: Add DP PSR2 sink enable bit

[Patchwork]

== Series Details ==

Series: series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit
URL   : https://patchwork.freedesktop.org/series/40702/
State : success

== Summary ==

Series 40702v1 series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit
https://patchwork.freedesktop.org/api/1.0/series/40702/revisions/1/mbox/

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:443s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:540s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:514s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:523s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:513s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:592s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:321s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:435s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:477s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:658s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:553s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:510s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:429s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:449s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:586s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:402s
Blacklisted hosts:
fi-cfl-s3total:285  pass:258  dwarn:0   dfail:0   fail:1   skip:26  
time:565s
fi-cnl-psr   total:224  pass:198  dwarn:0   dfail:0   fail:1   skip:24 
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:485s

d439f4eca05fe48c26bf9c3863e56ee19ac1c50b drm-tip: 2018y-03m-27d-00h-15m-56s UTC 
integration manifest
d816dbeca7de drm/i915/debugfs: Print sink PSR status
c7f3ff827a03 drm/i915/psr: Set DPCD PSR2 enable bit when needed
d64ec6a72ea0 drm/i915/psr: Cache sink synchronization latency
8d70d650ad61 drm/i915/psr: Use PSR2 macro for PSR2
b758759a05ee drm/i915/psr: Do not override PSR2 sink support
3c0441b04e7a drm/i915/psr/cnl: Enable Y-coordinate support in source
42e34d55f628 drm/i915/psr: Tie PSR2 support to Y coordinate requirement
99b23cf0dceb drm/i915/psr: Nuke aux frame sync
b58a3e8a7618 drm: Add DP last received PSR SDP VSC register and bits
38150dd0cc54 drm: Add DP PSR2 sink enable bit

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit

[Patchwork]

== Series Details ==

Series: series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit
URL   : https://patchwork.freedesktop.org/series/40702/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
38150dd0cc54 drm: Add DP PSR2 sink enable bit
b58a3e8a7618 drm: Add DP last received PSR SDP VSC register and bits
99b23cf0dceb drm/i915/psr: Nuke aux frame sync
42e34d55f628 drm/i915/psr: Tie PSR2 support to Y coordinate requirement
3c0441b04e7a drm/i915/psr/cnl: Enable Y-coordinate support in source
-:26: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#26: FILE: drivers/gpu/drm/i915/i915_reg.h:4055:
+#define   EDP_Y_COORDINATE_VALID   (1<<26) /* GLK and CNL+ */
  ^

-:27: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#27: FILE: drivers/gpu/drm/i915/i915_reg.h:4056:
+#define   EDP_Y_COORDINATE_ENABLE  (1<<25) /* GLK and CNL+ */
  ^

-:35: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#35: FILE: drivers/gpu/drm/i915/i915_reg.h:7063:
+#define  VSC_DATA_SEL_SOFTWARE_CONTROL (1<<25) /* GLK and CNL+ */
  ^

total: 0 errors, 0 warnings, 3 checks, 43 lines checked
b758759a05ee drm/i915/psr: Do not override PSR2 sink support
8d70d650ad61 drm/i915/psr: Use PSR2 macro for PSR2
d64ec6a72ea0 drm/i915/psr: Cache sink synchronization latency
c7f3ff827a03 drm/i915/psr: Set DPCD PSR2 enable bit when needed
d816dbeca7de drm/i915/debugfs: Print sink PSR status

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

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

[Dhinakaran Pandiyan]

Interrupts other than the one for AUX errors are required only for debug,
so unmask them via debugfs when the user requests debug.

User can make such a request with
echo 1 > /dri/0/i915_edp_psr_debug

v2: Unroll loops (Ville)
Avoid resetting error mask bits.

Cc: Rodrigo Vivi 
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_irq.c | 55 +++--
 drivers/gpu/drm/i915/intel_drv.h|  2 ++
 drivers/gpu/drm/i915/intel_psr.c| 54 
 5 files changed, 108 insertions(+), 40 deletions(-)

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

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

[Dhinakaran Pandiyan]

Timestamps are useful for IGT tests that trigger PSR exit and/or wait for
PSR entry.

v2: Removed seqlock (Ville)
Removed erroneous warning in irq loop (Chris)

Cc: Ville Syrjälä 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 7 +++
 drivers/gpu/drm/i915/i915_drv.h | 2 ++
 drivers/gpu/drm/i915/intel_psr.c| 9 +++--
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6fd801ef7cbb..c69384d17226 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2686,6 +2686,13 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
}
mutex_unlock(_priv->psr.lock);
 
+   if (READ_ONCE(dev_priv->psr.debug)) {
+   seq_printf(m, "Last attempted entry at: %lld\n",
+  dev_priv->psr.last_entry_attempt);
+   seq_printf(m, "Last exit at: %lld\n",
+  dev_priv->psr.last_exit);
+   }
+
intel_runtime_pm_put(dev_priv);
return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c0224a86344e..41c3268b5de5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -609,6 +609,8 @@ struct i915_psr {
bool alpm;
bool has_hw_tracking;
bool debug;
+   ktime_t last_entry_attempt;
+   ktime_t last_exit;
 
void (*enable_source)(struct intel_dp *,
  const struct intel_crtc_state *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index fdc5e1bf198a..0d338632c2bb 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -125,6 +125,7 @@ void intel_psr_irq_handler(struct drm_i915_private 
*dev_priv, u32 psr_iir)
 {
u32 transcoders = BIT(TRANSCODER_EDP);
enum transcoder cpu_transcoder;
+   ktime_t time_ns =  ktime_get();
 
if (INTEL_GEN(dev_priv) >= 8)
transcoders |= BIT(TRANSCODER_A) |
@@ -137,13 +138,17 @@ void intel_psr_irq_handler(struct drm_i915_private 
*dev_priv, u32 psr_iir)
DRM_DEBUG_KMS("[transcoder %s] PSR aux error\n",
  transcoder_name(cpu_transcoder));
 
-   if (psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder))
+   if (psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
+   dev_priv->psr.last_entry_attempt = time_ns;
DRM_DEBUG_KMS("[transcoder %s] PSR entry attempt in 2 
vblanks\n",
  transcoder_name(cpu_transcoder));
+   }
 
-   if (psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder))
+   if (psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
+   dev_priv->psr.last_exit = time_ns;
DRM_DEBUG_KMS("[transcoder %s] PSR exit completed\n",
  transcoder_name(cpu_transcoder));
+   }
}
 }
 
-- 
2.14.1

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

[Intel-gfx] [PATCH v2 2/4] drm/i915: Enable edp psr error interrupts on bdw+

[Dhinakaran Pandiyan]

From: Ville Syrjälä 

Plug in the bdw+ irq handling for PSR interrupts. bdw+ supports psr on
any transcoder in theory, though the we don't currenty enable PSR except
on the EDP transcoder.

v2: From DK
 * Rebased on drm-tip
v3: Switched author to Ville based on IRC discussion.

Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_irq.c  | 57 
 drivers/gpu/drm/i915/i915_reg.h  |  7 +++--
 drivers/gpu/drm/i915/intel_display.h |  4 +++
 3 files changed, 52 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c2d3f30778ee..8a894adf2ca1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2394,20 +2394,34 @@ static void ilk_display_irq_handler(struct 
drm_i915_private *dev_priv,
 static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
 {
u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
+   u32 edp_psr_imr = I915_READ(EDP_PSR_IMR);
+   u32 mask = BIT(TRANSCODER_EDP);
+   enum transcoder cpu_transcoder;
 
-   if (edp_psr_iir & EDP_PSR_ERROR)
-   DRM_DEBUG_KMS("PSR error\n");
-
-   if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
-   DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
-   I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
-   }
+   if (INTEL_GEN(dev_priv) >= 8)
+   mask |= BIT(TRANSCODER_A) |
+   BIT(TRANSCODER_B) |
+   BIT(TRANSCODER_C);
+
+   for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, mask) {
+   if (edp_psr_iir & EDP_PSR_ERROR(cpu_transcoder))
+   DRM_DEBUG_KMS("Transcoder %s PSR error\n",
+ transcoder_name(cpu_transcoder));
+
+   if (edp_psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
+   DRM_DEBUG_KMS("Transcoder %s PSR prepare entry in 2 
vblanks\n",
+ transcoder_name(cpu_transcoder));
+   edp_psr_imr |= EDP_PSR_PRE_ENTRY(cpu_transcoder);
+   }
 
-   if (edp_psr_iir & EDP_PSR_POST_EXIT) {
-   DRM_DEBUG_KMS("PSR exit completed\n");
-   I915_WRITE(EDP_PSR_IMR, 0);
+   if (edp_psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
+   DRM_DEBUG_KMS("Transcoder %s PSR exit completed\n",
+ transcoder_name(cpu_transcoder));
+   edp_psr_imr &= ~EDP_PSR_PRE_ENTRY(cpu_transcoder);
+   }
}
 
+   I915_WRITE(EDP_PSR_IMR, edp_psr_imr);
I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
 }
 
@@ -2555,11 +2569,22 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
if (master_ctl & GEN8_DE_MISC_IRQ) {
iir = I915_READ(GEN8_DE_MISC_IIR);
if (iir) {
+   bool found = false;
+
I915_WRITE(GEN8_DE_MISC_IIR, iir);
ret = IRQ_HANDLED;
-   if (iir & GEN8_DE_MISC_GSE)
+
+   if (iir & GEN8_DE_MISC_GSE) {
intel_opregion_asle_intr(dev_priv);
-   else
+   found = true;
+   }
+
+   if (iir & GEN8_DE_EDP_PSR) {
+   hsw_edp_psr_irq_handler(dev_priv);
+   found = true;
+   }
+
+   if (!found)
DRM_ERROR("Unexpected DE Misc interrupt\n");
}
else
@@ -3326,6 +3351,9 @@ static void gen8_irq_reset(struct drm_device *dev)
 
gen8_gt_irq_reset(dev_priv);
 
+   I915_WRITE(EDP_PSR_IMR, 0x);
+   I915_WRITE(EDP_PSR_IIR, 0x);
+
for_each_pipe(dev_priv, pipe)
if (intel_display_power_is_enabled(dev_priv,
   POWER_DOMAIN_PIPE(pipe)))
@@ -3815,7 +3843,7 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
uint32_t de_pipe_enables;
u32 de_port_masked = GEN8_AUX_CHANNEL_A;
u32 de_port_enables;
-   u32 de_misc_masked = GEN8_DE_MISC_GSE;
+   u32 de_misc_masked = GEN8_DE_MISC_GSE | GEN8_DE_EDP_PSR;
enum pipe pipe;
 
if (INTEL_GEN(dev_priv) >= 9) {
@@ -3840,6 +3868,9 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
else if (IS_BROADWELL(dev_priv))
de_port_enables |= GEN8_PORT_DP_A_HOTPLUG;
 
+   gen3_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
+   I915_WRITE(EDP_PSR_IMR, 0);
+

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

[Dhinakaran Pandiyan]

From: Daniel Vetter 

The definitions for the error register should be valid on bdw/skl too,
but there we haven't even enabled DE_MISC handling yet.

Somewhat confusing the the moved register offset on bdw is only for
the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
on bdw.

v2: Fixes from Ville.

v3: From DK
 * Rebased on drm-tip
 * Removed BDW IIR bit definition, looks like an unintentional change that
should be in the following patch.

v4: From DK
 * Don't mask REG_WRITE.

Cc: Ville Syrjälä 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_irq.c | 34 ++
 drivers/gpu/drm/i915/i915_reg.h |  8 
 2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 27aee25429b7..c2d3f30778ee 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2391,6 +2391,26 @@ static void ilk_display_irq_handler(struct 
drm_i915_private *dev_priv,
ironlake_rps_change_irq_handler(dev_priv);
 }
 
+static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
+{
+   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
+
+   if (edp_psr_iir & EDP_PSR_ERROR)
+   DRM_DEBUG_KMS("PSR error\n");
+
+   if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
+   DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
+   I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
+   }
+
+   if (edp_psr_iir & EDP_PSR_POST_EXIT) {
+   DRM_DEBUG_KMS("PSR exit completed\n");
+   I915_WRITE(EDP_PSR_IMR, 0);
+   }
+
+   I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
+}
+
 static void ivb_display_irq_handler(struct drm_i915_private *dev_priv,
u32 de_iir)
 {
@@ -2403,6 +2423,9 @@ static void ivb_display_irq_handler(struct 
drm_i915_private *dev_priv,
if (de_iir & DE_ERR_INT_IVB)
ivb_err_int_handler(dev_priv);
 
+   if (de_iir & DE_EDP_PSR_INT_HSW)
+   hsw_edp_psr_irq_handler(dev_priv);
+
if (de_iir & DE_AUX_CHANNEL_A_IVB)
dp_aux_irq_handler(dev_priv);
 
@@ -3260,6 +3283,11 @@ static void ironlake_irq_reset(struct drm_device *dev)
if (IS_GEN7(dev_priv))
I915_WRITE(GEN7_ERR_INT, 0x);
 
+   if (IS_HASWELL(dev_priv)) {
+   I915_WRITE(EDP_PSR_IMR, 0x);
+   I915_WRITE(EDP_PSR_IIR, 0x);
+   }
+
gen5_gt_irq_reset(dev_priv);
 
ibx_irq_reset(dev_priv);
@@ -3671,6 +3699,12 @@ static int ironlake_irq_postinstall(struct drm_device 
*dev)
  DE_DP_A_HOTPLUG);
}
 
+   if (IS_HASWELL(dev_priv)) {
+   gen3_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
+   I915_WRITE(EDP_PSR_IMR, 0);
+   display_mask |= DE_EDP_PSR_INT_HSW;
+   }
+
dev_priv->irq_mask = ~display_mask;
 
ibx_irq_pre_postinstall(dev);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index da2f6c623ab2..af6e2b1dd6ba 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3845,6 +3845,13 @@ enum {
 #define   EDP_PSR_TP1_TIME_0us (3<<4)
 #define   EDP_PSR_IDLE_FRAME_SHIFT 0
 
+/* Bspec claims those aren't shifted but stay at 0x64800 */
+#define EDP_PSR_IMR_MMIO(0x64834)
+#define EDP_PSR_IIR_MMIO(0x64838)
+#define   EDP_PSR_ERROR(1<<2)
+#define   EDP_PSR_POST_EXIT(1<<1)
+#define   EDP_PSR_PRE_ENTRY(1<<0)
+
 #define EDP_PSR_AUX_CTL
_MMIO(dev_priv->psr_mmio_base + 0x10)
 #define   EDP_PSR_AUX_CTL_TIME_OUT_MASK(3 << 26)
 #define   EDP_PSR_AUX_CTL_MESSAGE_SIZE_MASK(0x1f << 20)
@@ -6651,6 +6658,7 @@ enum {
 #define DE_PCH_EVENT_IVB   (1<<28)
 #define DE_DP_A_HOTPLUG_IVB(1<<27)
 #define DE_AUX_CHANNEL_A_IVB   (1<<26)
+#define DE_EDP_PSR_INT_HSW (1<<19)
 #define DE_SPRITEC_FLIP_DONE_IVB   (1<<14)
 #define DE_PLANEC_FLIP_DONE_IVB(1<<13)
 #define DE_PIPEC_VBLANK_IVB(1<<10)
-- 
2.14.1

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

[Intel-gfx] [PATCH v2 03/10] drm/i915/psr: Nuke aux frame sync

[José Roberto de Souza]

eDP spec states that aux frame is required to do PSR2 selective
update but i915 don't fully implement it. It sends the aux frame
sync messages but the value is always zero as the GTC is not enabled
in driver.

Through tests was findout that pannels can do selective update when
the y-coordinate is also included in SDP, that is why it is required
to run PSR2 in i915.

A dummy value is not useful at all to sink, so removing everything
related to aux frame sync, if GTC is enabled we can bring this back.

Cc: Vathsala Nagaraju 
Acked-by: Rodrigo Vivi 
Reviewed-by: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_psr.c | 24 +---
 2 files changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 800230ba1c3b..fade9029b6f5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -603,7 +603,6 @@ struct i915_psr {
struct delayed_work work;
unsigned busy_frontbuffer_bits;
bool psr2_support;
-   bool aux_frame_sync;
bool link_standby;
bool y_cord_support;
bool colorimetry_support;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index b8e083e10029..c0a6f63b586f 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -137,16 +137,9 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
 
if (INTEL_GEN(dev_priv) >= 9 &&
(intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
-   uint8_t frame_sync_cap;
 
dev_priv->psr.sink_support = true;
-   if (drm_dp_dpcd_readb(_dp->aux,
- DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
- _sync_cap) != 1)
-   frame_sync_cap = 0;
-   dev_priv->psr.aux_frame_sync = frame_sync_cap & 
DP_AUX_FRAME_SYNC_CAP;
-   /* PSR2 needs frame sync as well */
-   dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
+   dev_priv->psr.psr2_support = true;
DRM_DEBUG_KMS("PSR2 %s on sink",
  dev_priv->psr.psr2_support ? "supported" : "not 
supported");
 
@@ -268,12 +261,6 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 
-
-   /* Enable AUX frame sync at sink */
-   if (dev_priv->psr.aux_frame_sync)
-   drm_dp_dpcd_writeb(_dp->aux,
-   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
-   DP_AUX_FRAME_SYNC_ENABLE);
/* Enable ALPM at sink for psr2 */
if (dev_priv->psr.psr2_support && dev_priv->psr.alpm)
drm_dp_dpcd_writeb(_dp->aux,
@@ -712,11 +699,6 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
i915_reg_t psr_status;
u32 psr_status_mask;
 
-   if (dev_priv->psr.aux_frame_sync)
-   drm_dp_dpcd_writeb(_dp->aux,
-   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
-   0);
-
if (dev_priv->psr.psr2_support) {
psr_status = EDP_PSR2_STATUS;
psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
@@ -860,10 +842,6 @@ static void intel_psr_exit(struct drm_i915_private 
*dev_priv)
return;
 
if (HAS_DDI(dev_priv)) {
-   if (dev_priv->psr.aux_frame_sync)
-   drm_dp_dpcd_writeb(_dp->aux,
-   DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
-   0);
if (dev_priv->psr.psr2_support) {
val = I915_READ(EDP_PSR2_CTL);
WARN_ON(!(val & EDP_PSR2_ENABLE));
-- 
2.16.2

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

[Intel-gfx] [PATCH v2 09/10] drm/i915/psr: Set DPCD PSR2 enable bit when needed

[José Roberto de Souza]

In the 2 eDP1.4a pannels tested set or not set bit have no effect
but is better set it and comply with specification.

Signed-off-by: José Roberto de Souza 
Cc: Dhinakaran Pandiyan 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_psr.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index d079cf0b034c..2d53f7398a6d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -278,18 +278,19 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
+   u8 dpcd_val = DP_PSR_ENABLE;
 
/* Enable ALPM at sink for psr2 */
if (dev_priv->psr.psr2_enabled && dev_priv->psr.alpm)
drm_dp_dpcd_writeb(_dp->aux,
DP_RECEIVER_ALPM_CONFIG,
DP_ALPM_ENABLE);
+
+   if (dev_priv->psr.psr2_enabled)
+   dpcd_val |= DP_PSR_ENABLE_PSR2;
if (dev_priv->psr.link_standby)
-   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG,
-  DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
-   else
-   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG,
-  DP_PSR_ENABLE);
+   dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
+   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, dpcd_val);
 
drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
 }
-- 
2.16.2

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

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

[José Roberto de Souza]

Although i915 don't implement aux sync frame through tests was
findout that pannels can do selective update when the y-coordinate
is also included in SDP, that is why it is required to run PSR2 in
i915.

So moving to only one place the sink requirements that the actual
driver needs to enable PSR2.

Also intel_psr2_config_valid() is called every time the crtc config
is computed, wasting some time every time it was checking for
Y coordinate requirement.

This allow us to nuke y_cord_support and some of VSC setup code that
was handling a scenario that would never happen(PSR2 without Y
coordinate).

Also here renaming intel_dp_get_y_cord_status() to
intel_dp_get_y_coord_required() as it more accurate to the name and
function of bit according to eDP spec.

Cc: Rodrigo Vivi 
Reviewed-by: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_psr.c | 46 +---
 2 files changed, 19 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fade9029b6f5..92cf6f4e9e00 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -604,7 +604,6 @@ struct i915_psr {
unsigned busy_frontbuffer_bits;
bool psr2_support;
bool link_standby;
-   bool y_cord_support;
bool colorimetry_support;
bool alpm;
bool has_hw_tracking;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c0a6f63b586f..fb2d0fe7106b 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct intel_dp *intel_dp)
intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
 }
 
-static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
+static bool intel_dp_get_y_coord_required(struct intel_dp *intel_dp)
 {
uint8_t psr_caps = 0;
 
@@ -130,22 +130,29 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
 sizeof(intel_dp->psr_dpcd));
 
-   if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
+   if (intel_dp->psr_dpcd[0]) {
dev_priv->psr.sink_support = true;
DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
}
 
if (INTEL_GEN(dev_priv) >= 9 &&
-   (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
-
-   dev_priv->psr.sink_support = true;
-   dev_priv->psr.psr2_support = true;
+   (intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
+   /*
+* All panels that supports PSR version 03h (PSR2 +
+* Y-coordinate) can handle Y-coordinates in VSC but we are
+* only sure that it is going to be used when required by the
+* panel. This way panel is capable to do selective update
+* without a aux frame sync.
+*
+* To support PSR version 02h and PSR version 03h without
+* Y-coordinate requirement panels we would need to enable
+* GTC first.
+*/
+   dev_priv->psr.psr2_support = 
intel_dp_get_y_coord_required(intel_dp);
DRM_DEBUG_KMS("PSR2 %s on sink",
  dev_priv->psr.psr2_support ? "supported" : "not 
supported");
 
if (dev_priv->psr.psr2_support) {
-   dev_priv->psr.y_cord_support =
-   intel_dp_get_y_cord_status(intel_dp);
dev_priv->psr.colorimetry_support =
intel_dp_get_colorimetry_status(intel_dp);
dev_priv->psr.alpm =
@@ -191,16 +198,12 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
memset(_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
psr_vsc.sdp_header.HB1 = 0x7;
-   if (dev_priv->psr.colorimetry_support &&
-   dev_priv->psr.y_cord_support) {
+   if (dev_priv->psr.colorimetry_support) {
psr_vsc.sdp_header.HB2 = 0x5;
psr_vsc.sdp_header.HB3 = 0x13;
-   } else if (dev_priv->psr.y_cord_support) {
+   } else {
psr_vsc.sdp_header.HB2 = 0x4;
psr_vsc.sdp_header.HB3 = 0xe;
-   } else {
-   psr_vsc.sdp_header.HB2 = 0x3;
-   psr_vsc.sdp_header.HB3 = 0xc;
}
} else {
/* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
@@ -457,15 +460,6 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
 
-   

[Intel-gfx] [PATCH v2 07/10] drm/i915/psr: Use PSR2 macro for PSR2

[José Roberto de Souza]

Cosmetic change.

Reviewed-by: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_reg.h  | 3 ++-
 drivers/gpu/drm/i915/intel_psr.c | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1c6f463bc919..219a4da284aa 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4063,8 +4063,9 @@ enum {
 #define   EDP_PSR2_TP2_TIME_MASK   (3<<8)
 #define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
 #define   EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
-#define   EDP_PSR2_IDLE_MASK   0xf
 #define   EDP_PSR2_FRAME_BEFORE_SU(a)  ((a)<<4)
+#define   EDP_PSR2_IDLE_FRAME_MASK 0xf
+#define   EDP_PSR2_IDLE_FRAME_SHIFT0
 
 #define EDP_PSR2_STATUS_MMIO(0x6f940)
 #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 5efddd920681..bec455e28943 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -382,7 +382,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
uint32_t val;
uint8_t sink_latency;
 
-   val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
+   val = idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
 
/* FIXME: selective update is probably totally broken because it doesn't
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
-- 
2.16.2

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

[Intel-gfx] [PATCH v2 08/10] drm/i915/psr: Cache sink synchronization latency

[José Roberto de Souza]

This value do not change overtime so better cache it than
fetch it every PSR enable.

Cc: Dhinakaran Pandiyan 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_psr.c | 28 
 2 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 46cae097201c..5373b171bb96 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -608,6 +608,7 @@ struct i915_psr {
bool alpm;
bool has_hw_tracking;
bool psr2_enabled;
+   u8 sink_sync_latency;
 
void (*enable_source)(struct intel_dp *,
  const struct intel_crtc_state *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index bec455e28943..d079cf0b034c 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -122,6 +122,18 @@ static bool intel_dp_get_alpm_status(struct intel_dp 
*intel_dp)
return alpm_caps & DP_ALPM_CAP;
 }
 
+static u8 intel_dp_get_sink_sync_latency(struct intel_dp *intel_dp)
+{
+   u8 val = 0;
+
+   if (drm_dp_dpcd_readb(_dp->aux,
+ DP_SYNCHRONIZATION_LATENCY_IN_SINK, ) == 1)
+   val &= DP_MAX_RESYNC_FRAME_COUNT_MASK;
+   else
+   DRM_ERROR("Unable to get sink synchronization latency\n");
+   return val;
+}
+
 void intel_psr_init_dpcd(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv =
@@ -158,6 +170,8 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
intel_dp_get_colorimetry_status(intel_dp);
dev_priv->psr.alpm =
intel_dp_get_alpm_status(intel_dp);
+   dev_priv->psr.sink_sync_latency =
+   intel_dp_get_sink_sync_latency(intel_dp);
}
}
 }
@@ -379,10 +393,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
 * with the 5 or 6 idle patterns.
 */
uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
-   uint32_t val;
-   uint8_t sink_latency;
-
-   val = idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
+   u32 val = idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
 
/* FIXME: selective update is probably totally broken because it doesn't
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
@@ -392,14 +403,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
}
 
-   if (drm_dp_dpcd_readb(_dp->aux,
-   DP_SYNCHRONIZATION_LATENCY_IN_SINK,
-   _latency) == 1) {
-   sink_latency &= DP_MAX_RESYNC_FRAME_COUNT_MASK;
-   } else {
-   sink_latency = 0;
-   }
-   val |= EDP_PSR2_FRAME_BEFORE_SU(sink_latency + 1);
+   val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
 
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
-- 
2.16.2

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

[Intel-gfx] [PATCH v2 06/10] drm/i915/psr: Do not override PSR2 sink support

[José Roberto de Souza]

Sink can support our PSR2 requirements but userspace can request
a resolution that PSR2 hardware do not support, in this case it
was overwritten the PSR2 sink support.
Adding another flag here, this way if requested resolution changed
to a value that PSR2 hardware can handle, PSR2 can be enabled.

Cc: Dhinakaran Pandiyan 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h |  3 ++-
 drivers/gpu/drm/i915/intel_psr.c| 33 +
 3 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7816cd53100a..16f9977995df 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2630,7 +2630,7 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
   yesno(work_busy(_priv->psr.work.work)));
 
if (HAS_DDI(dev_priv)) {
-   if (dev_priv->psr.psr2_support)
+   if (dev_priv->psr.psr2_enabled)
enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
else
enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
@@ -2678,7 +2678,7 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
 
seq_printf(m, "Performance_Counter: %u\n", psrperf);
}
-   if (dev_priv->psr.psr2_support) {
+   if (dev_priv->psr.psr2_enabled) {
u32 psr2 = I915_READ(EDP_PSR2_STATUS);
 
seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 92cf6f4e9e00..46cae097201c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -602,11 +602,12 @@ struct i915_psr {
bool active;
struct delayed_work work;
unsigned busy_frontbuffer_bits;
-   bool psr2_support;
+   bool sink_psr2_support;
bool link_standby;
bool colorimetry_support;
bool alpm;
bool has_hw_tracking;
+   bool psr2_enabled;
 
void (*enable_source)(struct intel_dp *,
  const struct intel_crtc_state *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 84e1f8be5c48..5efddd920681 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -148,11 +148,12 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
 * Y-coordinate requirement panels we would need to enable
 * GTC first.
 */
-   dev_priv->psr.psr2_support = 
intel_dp_get_y_coord_required(intel_dp);
-   DRM_DEBUG_KMS("PSR2 %s on sink",
- dev_priv->psr.psr2_support ? "supported" : "not 
supported");
+   dev_priv->psr.sink_psr2_support =
+   intel_dp_get_y_coord_required(intel_dp);
+   DRM_DEBUG_KMS("PSR2 %s on sink", dev_priv->psr.sink_psr2_support
+ ? "supported" : "not supported");
 
-   if (dev_priv->psr.psr2_support) {
+   if (dev_priv->psr.sink_psr2_support) {
dev_priv->psr.colorimetry_support =
intel_dp_get_colorimetry_status(intel_dp);
dev_priv->psr.alpm =
@@ -193,7 +194,7 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv = 
to_i915(intel_dig_port->base.base.dev);
struct edp_vsc_psr psr_vsc;
 
-   if (dev_priv->psr.psr2_support) {
+   if (dev_priv->psr.psr2_enabled) {
/* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
memset(_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
@@ -265,7 +266,7 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = to_i915(dev);
 
/* Enable ALPM at sink for psr2 */
-   if (dev_priv->psr.psr2_support && dev_priv->psr.alpm)
+   if (dev_priv->psr.psr2_enabled && dev_priv->psr.alpm)
drm_dp_dpcd_writeb(_dp->aux,
DP_RECEIVER_ALPM_CONFIG,
DP_ALPM_ENABLE);
@@ -424,7 +425,7 @@ static void hsw_psr_activate(struct intel_dp *intel_dp)
 */
 
/* psr1 and psr2 are mutually exclusive.*/
-   if (dev_priv->psr.psr2_support)
+   if (dev_priv->psr.psr2_enabled)
hsw_activate_psr2(intel_dp);
else
hsw_activate_psr1(intel_dp);
@@ -444,7 +445,7 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
 * dynamically during PSR enable, and extracted from sink
 * caps during eDP detection.
 */
-   if 

[Intel-gfx] [PATCH v2 01/10] drm: Add DP PSR2 sink enable bit

[José Roberto de Souza]

To comply with eDP1.4a this bit should be set when enabling PSR2.

Signed-off-by: José Roberto de Souza 
Reviewed-by: Rodrigo Vivi 
---
 include/drm/drm_dp_helper.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 62903bae0221..0bac0c7d0dec 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -478,6 +478,7 @@
 # define DP_PSR_FRAME_CAPTURE  (1 << 3)
 # define DP_PSR_SELECTIVE_UPDATE   (1 << 4)
 # define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 << 5)
+# define DP_PSR_ENABLE_PSR2(1 << 6) /* eDP 1.4a */
 
 #define DP_ADAPTER_CTRL0x1a0
 # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE   (1 << 0)
-- 
2.16.2

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

[Intel-gfx] [PATCH v2 02/10] drm: Add DP last received PSR SDP VSC register and bits

[José Roberto de Souza]

This is a register to help debug what is in the last SDP VSC
packet revived by sink.

Signed-off-by: José Roberto de Souza 
Reviewed-by: Rodrigo Vivi 
---
 include/drm/drm_dp_helper.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 0bac0c7d0dec..91c9bcd4196f 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -795,6 +795,15 @@
 # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_MASK   (0xf << 4)
 # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_SHIFT  4
 
+#define DP_LAST_RECEIVED_PSR_SDP   0x200a /* eDP 1.2 */
+# define DP_PSR_STATE_BIT  (1 << 0) /* eDP 1.2 */
+# define DP_UPDATE_RFB_BIT (1 << 1) /* eDP 1.2 */
+# define DP_CRC_VALID_BIT  (1 << 2) /* eDP 1.2 */
+# define DP_SU_VALID   (1 << 3) /* eDP 1.4 */
+# define DP_FIRST_SCAN_LINE_SU_REGION  (1 << 4) /* eDP 1.4 */
+# define DP_LAST_SCAN_LINE_SU_REGION   (1 << 5) /* eDP 1.4 */
+# define DP_Y_COORDINATE_VALID (1 << 6) /* eDP 1.4a */
+
 #define DP_RECEIVER_ALPM_STATUS0x200b  /* eDP 1.4 */
 # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0)
 
-- 
2.16.2

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

[Intel-gfx] [PATCH v2 05/10] drm/i915/psr/cnl: Enable Y-coordinate support in source

[José Roberto de Souza]

From: "Souza, Jose" 

For Geminilake and Cannonlake+ the Y-coordinate support must be
enabled in PSR2_CTL too.

Spec: 7713 and 7720

Cc: Dhinakaran Pandiyan 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_reg.h  |  3 +++
 drivers/gpu/drm/i915/intel_psr.c | 16 
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1bca695f404b..1c6f463bc919 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4052,6 +4052,8 @@ enum {
 #define EDP_PSR2_CTL   _MMIO(0x6f900)
 #define   EDP_PSR2_ENABLE  (1<<31)
 #define   EDP_SU_TRACK_ENABLE  (1<<30)
+#define   EDP_Y_COORDINATE_VALID   (1<<26) /* GLK and CNL+ */
+#define   EDP_Y_COORDINATE_ENABLE  (1<<25) /* GLK and CNL+ */
 #define   EDP_MAX_SU_DISABLE_TIME(t)   ((t)<<20)
 #define   EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
 #define   EDP_PSR2_TP2_TIME_500(0<<8)
@@ -7058,6 +7060,7 @@ enum {
 #define CHICKEN_TRANS_A 0x420c0
 #define CHICKEN_TRANS_B 0x420c4
 #define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
CHICKEN_TRANS_B)
+#define  VSC_DATA_SEL_SOFTWARE_CONTROL (1<<25) /* GLK and CNL+ */
 #define  DDI_TRAINING_OVERRIDE_ENABLE  (1<<19)
 #define  DDI_TRAINING_OVERRIDE_VALUE   (1<<18)
 #define  DDIE_TRAINING_OVERRIDE_ENABLE (1<<17) /* CHICKEN_TRANS_A only */
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index fb2d0fe7106b..84e1f8be5c48 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -386,8 +386,10 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
/* FIXME: selective update is probably totally broken because it doesn't
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
 * good enough. */
-   val |= EDP_PSR2_ENABLE |
-   EDP_SU_TRACK_ENABLE;
+   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+   val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
+   }
 
if (drm_dp_dpcd_readb(_dp->aux,
DP_SYNCHRONIZATION_LATENCY_IN_SINK,
@@ -569,8 +571,14 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp,
hsw_psr_setup_aux(intel_dp);
 
if (dev_priv->psr.psr2_support) {
-   u32 chicken = PSR2_VSC_ENABLE_PROG_HEADER
- | PSR2_ADD_VERTICAL_LINE_COUNT;
+   u32 chicken = I915_READ(CHICKEN_TRANS(cpu_transcoder));
+
+   if (INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv))
+   chicken |= (PSR2_VSC_ENABLE_PROG_HEADER
+  | PSR2_ADD_VERTICAL_LINE_COUNT);
+
+   else
+   chicken &= ~VSC_DATA_SEL_SOFTWARE_CONTROL;
I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
 
I915_WRITE(EDP_PSR_DEBUG,
-- 
2.16.2

___
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/debugfs: Print sink PSR status

[José Roberto de Souza]

IGT tests could be improved with sink status, knowing for sure that
hardware have activate or exit PSR.

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 16f9977995df..91a8f70ffdd3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2603,6 +2603,26 @@ static const char *psr2_live_status(u32 val)
return "unknown";
 }
 
+static const char *psr_sink_self_refresh_status(u8 val)
+{
+   static const char * const sink_status[] = {
+   "inactive",
+   "transitioning to active",
+   "active",
+   "active receiving selective update",
+   "transitioning to inactive",
+   "reserved",
+   "reserved",
+   "sink internal error"
+   };
+
+   val &= DP_PSR_SINK_STATE_MASK;
+   if (val < ARRAY_SIZE(sink_status))
+   return sink_status[val];
+
+   return "unknown";
+}
+
 static int i915_edp_psr_status(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -2684,6 +2704,15 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
   psr2, psr2_live_status(psr2));
}
+
+   if (dev_priv->psr.enabled) {
+   struct drm_dp_aux *aux = _priv->psr.enabled->aux;
+   u8 val;
+
+   if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, ) == 1)
+   seq_printf(m, "Sink self refresh status: 0x%x [%s]\n",
+  val, psr_sink_self_refresh_status(val));
+   }
mutex_unlock(_priv->psr.lock);
 
intel_runtime_pm_put(dev_priv);
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH 03/12] drm/i915/psr: Nuke aux frame sync

[Souza, Jose]

On Fri, 2018-03-23 at 19:16 -0700, Pandiyan, Dhinakaran wrote:
> On Fri, 2018-03-23 at 23:49 +, Souza, Jose wrote:
> > On Fri, 2018-03-23 at 15:14 -0700, Pandiyan, Dhinakaran wrote:
> > > On Thu, 2018-03-22 at 15:57 -0700, Rodrigo Vivi wrote:
> > > > On Thu, Mar 22, 2018 at 02:48:39PM -0700, José Roberto de Souza
> > > > wrote:
> > > > > Without GTC enabled hardware is sending dummy aux frame sync
> > > > > value
> > > 
> > > Curious, is this something you found by testing?
> > 
> > There this a this bit AUX_FRAME_SYNC Valid in AUX_FRAME_SYNC VALUE
> > register in sink, I'm reading this as valid but the value of aux
> > frame
> > in sink is always 0, the same as GTC_LIVE register in source side
> > by
> > this I guess source is sending 0 in each aux frame sync.
> > 
> > > 
> > > > > that is not useful to sink do selective update, that is why
> > > > > it
> > > > > also
> > > > > require that sink supports and requires the y-coordinate.
> > > > > 
> > > > > So removing everything related to aux frame sync, if GTC is
> > > > > enabled
> > > > > we can bring this back.
> > > > > 
> > > > > Cc: Dhinakaran Pandiyan 
> > > > > Cc: Rodrigo Vivi 
> > > > 
> > > > Cc: Vathsala Nagaraju 
> > > > 
> > > > > Signed-off-by: José Roberto de Souza 
> > > > 
> > > > Acked-by: Rodrigo Vivi 
> > > > (but I would like to give a time for Vathsala to comment on
> > > > this)
> > > > 
> > > 
> > > Reading the spec again,
> > > 
> > > No aux frame sync implies that the driver does not support
> > > selective
> > > update, irrespective of whether we *support y-coordinate or not*.
> > > 
> > > Section 7.1 eDP v1.4b
> > > "AUX_FRAME_SYNC was added to eDP v1.4 for streamlining the RFB
> > > management of a Sink device during PSR2 operation. AUX_FRAME_SYNC
> > > is
> > > required a for PSR2 when using the Selective Update feature
> > > (which is
> > > any time that the SU_VALID bit p is set to 1 in the PSR2 VSC
> > > SDP).
> > > Neither GTC nor AUX_FRAME_SYNC is required for PSR2 when using
> > > only
> > > the
> > > Single-frame Update feature (which means that the SU_VALID bit is
> > > always
> > > cleared to 0 in the PSR2 VSC SDP)."
> > > 
> > > Sending y-coordinate only allows for a lower precision aux frame
> > > sync
> > > functionality, doesn't invalidate the need for aux frame sync.
> > > 
> > > "When the Source device includes the optional Y-coordinate in the
> > > SDP
> > > for PSR2 Operation, as described in Table 6-12, the Sink device
> > > can
> > > implement a lower-precision GTC Slave  function, as described in
> > > Table
> > > 7-1."
> > > 
> > > Aside from the still slightly misleading commit message, this in
> > > my
> > > opinion is a good step. Let's make it obvious and clear that only
> > > full
> > > frame updates are currently supported. We can then start working
> > > on
> > > what's required for selective update and do it properly.
> > > 
> > > 
> > > I'd like you to include relevant portions of the above text in
> > > the
> > > commit message if you agree with the interpretation.
> > > 
> > > -DK
> > 
> > I agree with your interpretation of the spec but by the previous
> > attempts of enabling of PSR/PSR2 and also by my tests the selective
> > update with y-coordinate works at least in the pannels that we have
> > access to.
> 
> I'll take your word on that. How are you checking selective update is
> indeed working?

Doing a lot of reads to i915_edp_psr_status debugfs with all the
patches in this series, I can see sink status as "active receiving
selective update" and on the SDP I can see that the Y-Coordinate is
valid and the image on sink is alright. 

> 
> Vathsala/Rodrigo
> 
> Any idea why selective update seems to be working without aux frame
> sync?
> 
> > And do not makes sense enable any PSR2 if we are going to do full
> > frame
> > updates, that is PSR1.
> 
> Yeah, but we do want to make sure selective update is working without
> aux frame sync.
> 
> As the driver doesn't implement aux frame sync, there's not much
> meaning
> in requiring the sink to support it. So, this patch is
> Reviewed-by: Dhinakaran Pandiyan 
> 
> Please rewrite the commit message stating what's in the spec and
> include
> the contradictory observation you made in the tests. Thanks for all
> the
> work on this patch.

Sure.

Changing it to:


eDP spec states that aux frame is required to do PSR2 selective
update but i915 don't fully implement it. It sends the aux frame
sync messages but the value is always zero as the GTC is not enabled
in driver.

Through tests was findout that pannels can do selective update when
the y-coordinate is also included in SDP, that is why it is required
to run PSR2 in i915.

A dummy value is not useful at all to sink, so removing everything
related to aux frame sync, if GTC is enabled we can bring this back.


> 
> -DK
> 
> > 
> > > 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

[Chris Wilson]

Quoting Chris Wilson (2018-03-26 21:08:33)
> Quoting Patchwork (2018-03-26 17:53:44)
> > Test gem_userptr_blits:
> > Subgroup coherency-unsync:
> > pass   -> INCOMPLETE (shard-hsw)
> 
> Forgot that obj->userptr.mn may not exist.
> 
> > Subgroup dmabuf-sync:
> > pass   -> DMESG-WARN (shard-hsw)
> 
> But this is the tricky lockdep one, warning of the recursion from gup
> into mmu_invalidate_range, i.e.
> 
> down_read(_mmu_notifier->sem);
> down_read(_struct->mmap_sem);
> gup();
> down_write(_mmut_notifier->sem);
> 
> That seems a genuine deadlock... So I wonder how we managed to get a
> lockdep splat and not a dead machine. Maybe gup never triggers the
> recursion for our set of flags? Hmm.

In another universe, CI found

[  255.666496] ==
[  255.666498] WARNING: possible circular locking dependency detected
[  255.666500] 4.16.0-rc6-CI-Trybot_1944+ #1 Tainted: G U  W   
[  255.666502] --
[  255.666503] gem_userptr_bli/4794 is trying to acquire lock:
[  255.666505]  (fs_reclaim){+.+.}, at: [] 
fs_reclaim_acquire.part.12+0x0/0x30
[  255.666510] 
   but task is already holding lock:
[  255.666512]  (>sem){+.+.}, at: [<7c59ba79>] 
i915_gem_userptr_mn_invalidate_range_start+0x3e/0x1a0 [i915]
[  255.666553] 
   which lock already depends on the new lock.

[  255.666555] 
   the existing dependency chain (in reverse order) is:
[  255.666557] 
   -> #2 (>sem){+.+.}:
[  255.666578]i915_gem_userptr_mn_invalidate_range_start+0x3e/0x1a0 
[i915]
[  255.666581]__mmu_notifier_invalidate_range_start+0x73/0xb0
[  255.666584]zap_page_range_single+0xcc/0xe0
[  255.666586]unmap_mapping_pages+0xd4/0x110
[  255.06]i915_vma_revoke_mmap+0x7e/0x1c0 [i915]
[  255.25]i915_vma_unbind+0x60a/0xa10 [i915]
[  255.44]i915_gem_object_set_tiling+0xf6/0x5b0 [i915]
[  255.62]i915_gem_set_tiling_ioctl+0x262/0x2f0 [i915]
[  255.65]drm_ioctl_kernel+0x60/0xa0
[  255.67]drm_ioctl+0x27e/0x320
[  255.69]do_vfs_ioctl+0x8a/0x670
[  255.70]SyS_ioctl+0x36/0x70
[  255.72]do_syscall_64+0x65/0x1a0
[  255.75]entry_SYSCALL_64_after_hwframe+0x42/0xb7
[  255.76] 
   -> #1 (>i_mmap_rwsem){}:
[  255.80]unmap_mapping_pages+0x3d/0x110
[  255.98]i915_vma_revoke_mmap+0x7e/0x1c0 [i915]
[  255.666716]i915_vma_unbind+0x60a/0xa10 [i915]
[  255.666734]i915_gem_object_unbind+0xa0/0x130 [i915]
[  255.666751]i915_gem_shrink+0x2d1/0x5d0 [i915]
[  255.666767]i915_drop_caches_set+0x92/0x190 [i915]
[  255.666770]simple_attr_write+0xab/0xc0
[  255.666772]full_proxy_write+0x4b/0x70
[  255.666774]__vfs_write+0x1e/0x130
[  255.666776]vfs_write+0xbd/0x1b0
[  255.666778]SyS_write+0x40/0xa0
[  255.666779]do_syscall_64+0x65/0x1a0
[  255.666781]entry_SYSCALL_64_after_hwframe+0x42/0xb7
[  255.666783] 
   -> #0 (fs_reclaim){+.+.}:
[  255.666786]fs_reclaim_acquire.part.12+0x24/0x30
[  255.666788]__alloc_pages_nodemask+0x1f1/0x11d0
[  255.666790]__get_free_pages+0x9/0x40
[  255.666792]__pud_alloc+0x25/0xb0
[  255.666794]copy_page_range+0xa75/0xaf0
[  255.666796]copy_process.part.7+0x1267/0x1d90
[  255.666798]_do_fork+0xc0/0x6b0
[  255.666800]do_syscall_64+0x65/0x1a0
[  255.666801]entry_SYSCALL_64_after_hwframe+0x42/0xb7
[  255.666803] 
   other info that might help us debug this:

[  255.666805] Chain exists of:
 fs_reclaim --> >i_mmap_rwsem --> >sem

[  255.666809]  Possible unsafe locking scenario:

[  255.666811]CPU0CPU1
[  255.666812]
[  255.666814]   lock(>sem);
[  255.666815]lock(>i_mmap_rwsem);
[  255.666817]lock(>sem);
[  255.666819]   lock(fs_reclaim);
[  255.666821] 

So a shrinker deadlock. That doesn't look easy to wriggle out of, as we
have a random chunk of code that's between invalidate_range_start and
invalidate_range_end.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Patchwork]

== Series Details ==

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

== Summary ==

 Possible new issues:

Test gem_eio:
Subgroup execbuf:
pass   -> INCOMPLETE (shard-apl)
Subgroup throttle:
pass   -> INCOMPLETE (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl) fdo#103199
Test kms_cursor_legacy:
Subgroup 2x-long-flip-vs-cursor-atomic:
fail   -> PASS   (shard-hsw) fdo#104873
Test kms_flip:
Subgroup plain-flip-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368 +3

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

shard-apltotal:3483 pass:1818 dwarn:1   dfail:0   fail:11  skip:1650 
time:12621s
shard-hswtotal:3495 pass:1782 dwarn:1   dfail:0   fail:2   skip:1709 
time:11735s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:6976s
Blacklisted hosts:
shard-kbltotal:3165 pass:1704 dwarn:22  dfail:0   fail:13  skip:1418 
time:7205s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] lib/gpgpu_fill: Adding missing configuration parameters for gpgpu_fill function

[Daniele Ceraolo Spurio]

+ igt-dev

On 21/03/18 07:23, Katarzyna Dec wrote:

During debugging gpgpu_fill test on various platforms, I found out few
things that can affect newer gens:


this is slightly confusing, as you start with saying that you've found 
something but then below you start with what you've changed. I'd reword 
to make it clearer what were the issues and how they've been fixed.



   Seting number of threads in TS in gen8_fill_interface_descriptor to 1.
This field was omitted in earlier platforms (apparently without any side
effects). Not setting it for newer platforms results in GPU hang.
   Adding pipeline selection mask to gen9_gpgpu_fillfunc, which is
necessary from SKL.
   Changes gen7_emit_interface_descriptor_load to gen8 version.


This last point applies to the gen9 fillfunc only. I'd also mention that 
the gen8 interface descriptor applies to gen9+ as well for extra clarity.




Signed-off-by: Katarzyna Dec 
Cc: Lukasz Kalamarz 
Cc: Daniele Ceraolo Spurio 
---
  lib/gpgpu_fill.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lib/gpgpu_fill.c b/lib/gpgpu_fill.c
index 4d98643d..e7a1edaa 100644
--- a/lib/gpgpu_fill.c
+++ b/lib/gpgpu_fill.c
@@ -336,6 +336,8 @@ gen8_fill_interface_descriptor(struct intel_batchbuffer 
*batch, struct igt_buf *
idd->desc5.constant_urb_entry_read_offset = 0;
idd->desc5.constant_urb_entry_read_length = 1; /* grf 1 */
  
+	idd->desc6.num_threads_in_tg = 1;

+


1 seems like a safe value which applies to all platforms and it doesn't 
change execution time (gem_gpgpu_fill still completes in ~0.2s on SKL 
with this change applied) so it seems reasonable to me to use it, but 
it'd be nice to get an ack by someone more experienced with the gpgpu 
pipeline.



return offset;
  }
  
@@ -790,12 +792,13 @@ gen9_gpgpu_fillfunc(struct intel_batchbuffer *batch,

batch->ptr = batch->buffer;
  
  	/* GPGPU pipeline */

-   OUT_BATCH(GEN7_PIPELINE_SELECT | PIPELINE_SELECT_GPGPU);
+   OUT_BATCH(GEN7_PIPELINE_SELECT | GEN9_PIPELINE_SELECTION_MASK |
+   PIPELINE_SELECT_GPGPU);


need more indent here.

Apart from the various nitpicks the change looks good to me.

Daniele

  
  	gen9_emit_state_base_address(batch);

gen8_emit_vfe_state_gpgpu(batch);
gen7_emit_curbe_load(batch, curbe_buffer);
-   gen7_emit_interface_descriptor_load(batch, interface_descriptor);
+   gen8_emit_interface_descriptor_load(batch, interface_descriptor);
gen8_emit_gpgpu_walk(batch, x, y, width, height);
  
  	OUT_BATCH(MI_BATCH_BUFFER_END);



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

Re: [Intel-gfx] [PATCH 15/23] drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

[Daniel Vetter]

On Mon, Mar 26, 2018 at 10:52:58PM +0200, Daniel Vetter wrote:
> On Thu, Mar 22, 2018 at 05:23:05PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Stop playing around with plane->crtc/fb/old_fb with atomic
> > drivers. Make life a lot simpler when we don't have to do the
> > magic old_fb vs. fb dance around plane updates. That way we
> > can't risk plane->fb getting out of sync with plane->state->fb
> > and we're less likely to leak any refcounts as well.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 55 
> > -
> >  drivers/gpu/drm/drm_atomic_helper.c | 15 +-
> >  drivers/gpu/drm/drm_crtc.c  |  8 --
> >  drivers/gpu/drm/drm_fb_helper.c |  7 -
> >  drivers/gpu/drm/drm_framebuffer.c   |  5 
> >  drivers/gpu/drm/drm_plane.c | 14 ++
> >  drivers/gpu/drm/drm_plane_helper.c  |  4 ++-
> >  include/drm/drm_atomic.h|  3 --
> >  8 files changed, 24 insertions(+), 87 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 7d25c42f22db..b16cc37e2adf 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -692,6 +692,11 @@ drm_atomic_get_plane_state(struct drm_atomic_state 
> > *state,
> >  
> > WARN_ON(!state->acquire_ctx);
> >  
> > +   /* the legacy pointers should never be set */
> > +   WARN_ON(plane->fb);
> > +   WARN_ON(plane->old_fb);
> > +   WARN_ON(plane->crtc);
> 
> I did already review all the users for plane->crtc and found:
> 
> armada + shmob: not atomic, should be fine
> 
> But there's also exynos, msm/mdp5, sti and vc4 doing various silly things
> with setting plane->crtc. I think before you can add this WARN_ON we need
> to clean up that cruft (it looks like 100% cargo culting, so should be
> quit).

Ah, follow-up patches take care of most of this. But note that msm sets
plane->crtc in its _init function, so will trip over your WARN_ON here.

And you seem to have missed sti, which looks at plane->crtc instead of
plane->state->crtc (and appropriate locking) in its debugfs code.
-Daniel

> 
> Going to think about the other patches tomorrow.
> -Daniel
> 
> > +
> > plane_state = drm_atomic_get_existing_plane_state(state, plane);
> > if (plane_state)
> > return plane_state;
> > @@ -2021,45 +2026,6 @@ int drm_atomic_set_property(struct drm_atomic_state 
> > *state,
> > return ret;
> >  }
> >  
> > -/**
> > - * drm_atomic_clean_old_fb -- Unset old_fb pointers and set plane->fb 
> > pointers.
> > - *
> > - * @dev: drm device to check.
> > - * @plane_mask: plane mask for planes that were updated.
> > - * @ret: return value, can be -EDEADLK for a retry.
> > - *
> > - * Before doing an update _plane.old_fb is set to _plane.fb, but 
> > before
> > - * dropping the locks old_fb needs to be set to NULL and plane->fb 
> > updated. This
> > - * is a common operation for each atomic update, so this call is split off 
> > as a
> > - * helper.
> > - */
> > -void drm_atomic_clean_old_fb(struct drm_device *dev,
> > -unsigned plane_mask,
> > -int ret)
> > -{
> > -   struct drm_plane *plane;
> > -
> > -   /* if succeeded, fixup legacy plane crtc/fb ptrs before dropping
> > -* locks (ie. while it is still safe to deref plane->state).  We
> > -* need to do this here because the driver entry points cannot
> > -* distinguish between legacy and atomic ioctls.
> > -*/
> > -   drm_for_each_plane_mask(plane, dev, plane_mask) {
> > -   if (ret == 0) {
> > -   struct drm_framebuffer *new_fb = plane->state->fb;
> > -   if (new_fb)
> > -   drm_framebuffer_get(new_fb);
> > -   plane->fb = new_fb;
> > -   plane->crtc = plane->state->crtc;
> > -
> > -   if (plane->old_fb)
> > -   drm_framebuffer_put(plane->old_fb);
> > -   }
> > -   plane->old_fb = NULL;
> > -   }
> > -}
> > -EXPORT_SYMBOL(drm_atomic_clean_old_fb);
> > -
> >  /**
> >   * DOC: explicit fencing properties
> >   *
> > @@ -2280,9 +2246,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > unsigned int copied_objs, copied_props;
> > struct drm_atomic_state *state;
> > struct drm_modeset_acquire_ctx ctx;
> > -   struct drm_plane *plane;
> > struct drm_out_fence_state *fence_state;
> > -   unsigned plane_mask;
> > int ret = 0;
> > unsigned int i, j, num_fences;
> >  
> > @@ -2322,7 +2286,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
> >  
> >  retry:
> > -   plane_mask = 0;
> > copied_objs = 0;
> > copied_props = 0;
> > fence_state = NULL;
> > @@ -2393,12 +2356,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> 

Re: [Intel-gfx] [PATCH 15/23] drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:23:05PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Stop playing around with plane->crtc/fb/old_fb with atomic
> drivers. Make life a lot simpler when we don't have to do the
> magic old_fb vs. fb dance around plane updates. That way we
> can't risk plane->fb getting out of sync with plane->state->fb
> and we're less likely to leak any refcounts as well.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_atomic.c| 55 
> -
>  drivers/gpu/drm/drm_atomic_helper.c | 15 +-
>  drivers/gpu/drm/drm_crtc.c  |  8 --
>  drivers/gpu/drm/drm_fb_helper.c |  7 -
>  drivers/gpu/drm/drm_framebuffer.c   |  5 
>  drivers/gpu/drm/drm_plane.c | 14 ++
>  drivers/gpu/drm/drm_plane_helper.c  |  4 ++-
>  include/drm/drm_atomic.h|  3 --
>  8 files changed, 24 insertions(+), 87 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7d25c42f22db..b16cc37e2adf 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -692,6 +692,11 @@ drm_atomic_get_plane_state(struct drm_atomic_state 
> *state,
>  
>   WARN_ON(!state->acquire_ctx);
>  
> + /* the legacy pointers should never be set */
> + WARN_ON(plane->fb);
> + WARN_ON(plane->old_fb);
> + WARN_ON(plane->crtc);

I did already review all the users for plane->crtc and found:

armada + shmob: not atomic, should be fine

But there's also exynos, msm/mdp5, sti and vc4 doing various silly things
with setting plane->crtc. I think before you can add this WARN_ON we need
to clean up that cruft (it looks like 100% cargo culting, so should be
quit).

Going to think about the other patches tomorrow.
-Daniel

> +
>   plane_state = drm_atomic_get_existing_plane_state(state, plane);
>   if (plane_state)
>   return plane_state;
> @@ -2021,45 +2026,6 @@ int drm_atomic_set_property(struct drm_atomic_state 
> *state,
>   return ret;
>  }
>  
> -/**
> - * drm_atomic_clean_old_fb -- Unset old_fb pointers and set plane->fb 
> pointers.
> - *
> - * @dev: drm device to check.
> - * @plane_mask: plane mask for planes that were updated.
> - * @ret: return value, can be -EDEADLK for a retry.
> - *
> - * Before doing an update _plane.old_fb is set to _plane.fb, but 
> before
> - * dropping the locks old_fb needs to be set to NULL and plane->fb updated. 
> This
> - * is a common operation for each atomic update, so this call is split off 
> as a
> - * helper.
> - */
> -void drm_atomic_clean_old_fb(struct drm_device *dev,
> -  unsigned plane_mask,
> -  int ret)
> -{
> - struct drm_plane *plane;
> -
> - /* if succeeded, fixup legacy plane crtc/fb ptrs before dropping
> -  * locks (ie. while it is still safe to deref plane->state).  We
> -  * need to do this here because the driver entry points cannot
> -  * distinguish between legacy and atomic ioctls.
> -  */
> - drm_for_each_plane_mask(plane, dev, plane_mask) {
> - if (ret == 0) {
> - struct drm_framebuffer *new_fb = plane->state->fb;
> - if (new_fb)
> - drm_framebuffer_get(new_fb);
> - plane->fb = new_fb;
> - plane->crtc = plane->state->crtc;
> -
> - if (plane->old_fb)
> - drm_framebuffer_put(plane->old_fb);
> - }
> - plane->old_fb = NULL;
> - }
> -}
> -EXPORT_SYMBOL(drm_atomic_clean_old_fb);
> -
>  /**
>   * DOC: explicit fencing properties
>   *
> @@ -2280,9 +2246,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   unsigned int copied_objs, copied_props;
>   struct drm_atomic_state *state;
>   struct drm_modeset_acquire_ctx ctx;
> - struct drm_plane *plane;
>   struct drm_out_fence_state *fence_state;
> - unsigned plane_mask;
>   int ret = 0;
>   unsigned int i, j, num_fences;
>  
> @@ -2322,7 +2286,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
>  
>  retry:
> - plane_mask = 0;
>   copied_objs = 0;
>   copied_props = 0;
>   fence_state = NULL;
> @@ -2393,12 +2356,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   copied_props++;
>   }
>  
> - if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
> - !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
> - plane = obj_to_plane(obj);
> - plane_mask |= (1 << drm_plane_index(plane));
> - plane->old_fb = plane->fb;
> - }
>   drm_mode_object_put(obj);
>   }
>  
> @@ -2419,8 +2376,6 @@ int drm_mode_atomic_ioctl(struct drm_device 

Re: [Intel-gfx] [PATCH 06/23] drm: Adjust whitespace for legibility

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:22:56PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Add a bit of whitespace here and there to make the code look a bit
> more structured.
> 
> Signed-off-by: Ville Syrjälä 

Too lazy to grow a real opinion on whitespace :-)

Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_crtc.c  | 4 +++-
>  drivers/gpu/drm/drm_plane.c | 6 +-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 8552ed419056..537ffaab855c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -434,13 +434,13 @@ int drm_mode_getcrtc(struct drm_device *dev,
>   if (crtc->state->enable) {
>   drm_mode_convert_to_umode(_resp->mode, 
> >state->mode);
>   crtc_resp->mode_valid = 1;
> -
>   } else {
>   crtc_resp->mode_valid = 0;
>   }
>   } else {
>   crtc_resp->x = crtc->x;
>   crtc_resp->y = crtc->y;
> +
>   if (crtc->enabled) {
>   drm_mode_convert_to_umode(_resp->mode, 
> >mode);
>   crtc_resp->mode_valid = 1;
> @@ -592,6 +592,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>   ret = drm_modeset_lock_all_ctx(crtc->dev, );
>   if (ret)
>   goto out;
> +
>   if (crtc_req->mode_valid) {
>   /* If we have a mode we need a framebuffer. */
>   /* If we pass -1, set the mode with the currently bound fb */
> @@ -601,6 +602,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>   ret = -EINVAL;
>   goto out;
>   }
> +
>   fb = plane->fb;
>   /* Make refcounting symmetric with the lookup path. */
>   drm_framebuffer_get(fb);
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 38e2a628bfa2..bedceca7dd06 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -785,6 +785,7 @@ static int drm_mode_cursor_universal(struct drm_crtc 
> *crtc,
>   DRM_DEBUG_KMS("failed to wrap cursor buffer in 
> drm framebuffer\n");
>   return PTR_ERR(fb);
>   }
> +
>   fb->hot_x = req->hot_x;
>   fb->hot_y = req->hot_y;
>   } else {
> @@ -1035,7 +1036,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>  state->src_h,
>  fb);
>   } else {
> - ret = drm_crtc_check_viewport(crtc, crtc->x, crtc->y, 
> >mode, fb);
> + ret = drm_crtc_check_viewport(crtc, crtc->x, crtc->y,
> +   >mode, fb);
>   }
>   if (ret)
>   goto out;
> @@ -1052,10 +1054,12 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>   ret = -ENOMEM;
>   goto out;
>   }
> +
>   e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
>   e->event.base.length = sizeof(e->event);
>   e->event.vbl.user_data = page_flip->user_data;
>   e->event.vbl.crtc_id = crtc->base.id;
> +
>   ret = drm_event_reserve_init(dev, file_priv, >base, 
> >event.base);
>   if (ret) {
>   kfree(e);
> -- 
> 2.16.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/23] drm: Add local 'plane' variable for primary/cursor planes

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:22:55PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Make the code a bit more readable by storing the plane pointer in a
> local variable rather than having to do crtc->{primary,cursor} all the
> time.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_crtc.c  | 32 +++-
>  drivers/gpu/drm/drm_plane.c | 32 ++--
>  2 files changed, 37 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 7a973ada7195..8552ed419056 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -402,6 +402,7 @@ int drm_mode_getcrtc(struct drm_device *dev,
>  {
>   struct drm_mode_crtc *crtc_resp = data;
>   struct drm_crtc *crtc;
> + struct drm_plane *plane;
>  
>   if (!drm_core_check_feature(dev, DRIVER_MODESET))
>   return -EINVAL;
> @@ -410,21 +411,23 @@ int drm_mode_getcrtc(struct drm_device *dev,
>   if (!crtc)
>   return -ENOENT;
>  
> + plane = crtc->primary;
> +
>   crtc_resp->gamma_size = crtc->gamma_size;
>  
> - drm_modeset_lock(>primary->mutex, NULL);
> - if (crtc->primary->state && crtc->primary->state->fb)
> - crtc_resp->fb_id = crtc->primary->state->fb->base.id;
> - else if (!crtc->primary->state && crtc->primary->fb)
> - crtc_resp->fb_id = crtc->primary->fb->base.id;
> + drm_modeset_lock(>mutex, NULL);
> + if (plane->state && plane->state->fb)
> + crtc_resp->fb_id = plane->state->fb->base.id;
> + else if (!plane->state && plane->fb)
> + crtc_resp->fb_id = plane->fb->base.id;
>   else
>   crtc_resp->fb_id = 0;
>  
> - if (crtc->primary->state) {
> - crtc_resp->x = crtc->primary->state->src_x >> 16;
> - crtc_resp->y = crtc->primary->state->src_y >> 16;
> + if (plane->state) {
> + crtc_resp->x = plane->state->src_x >> 16;
> + crtc_resp->y = plane->state->src_y >> 16;
>   }
> - drm_modeset_unlock(>primary->mutex);
> + drm_modeset_unlock(>mutex);
>  
>   drm_modeset_lock(>mutex, NULL);
>   if (crtc->state) {
> @@ -554,6 +557,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>   struct drm_mode_config *config = >mode_config;
>   struct drm_mode_crtc *crtc_req = data;
>   struct drm_crtc *crtc;
> + struct drm_plane *plane;
>   struct drm_connector **connector_set = NULL, *connector;
>   struct drm_framebuffer *fb = NULL;
>   struct drm_display_mode *mode = NULL;
> @@ -580,6 +584,8 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,

Could do the same for setconfig_internal's tmp->primary, if you're bored.

>   }
>   DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
>  
> + plane = crtc->primary;
> +
>   mutex_lock(>dev->mode_config.mutex);
>   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
>  retry:
> @@ -590,12 +596,12 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>   /* If we have a mode we need a framebuffer. */
>   /* If we pass -1, set the mode with the currently bound fb */
>   if (crtc_req->fb_id == -1) {
> - if (!crtc->primary->fb) {
> + if (!plane->fb) {
>   DRM_DEBUG_KMS("CRTC doesn't have current FB\n");
>   ret = -EINVAL;
>   goto out;
>   }
> - fb = crtc->primary->fb;
> + fb = plane->fb;
>   /* Make refcounting symmetric with the lookup path. */
>   drm_framebuffer_get(fb);
>   } else {
> @@ -627,8 +633,8 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>* match real hardware capabilities. Skip the check in that
>* case.
>*/
> - if (!crtc->primary->format_default) {
> - ret = drm_plane_check_pixel_format(crtc->primary,
> + if (!plane->format_default) {
> + ret = drm_plane_check_pixel_format(plane,
>  fb->format->format,
>  fb->modifier);
>   if (ret) {
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 6d2a6e428a3e..38e2a628bfa2 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -756,6 +756,7 @@ static int drm_mode_cursor_universal(struct drm_crtc 
> *crtc,
>struct drm_modeset_acquire_ctx *ctx)
>  {
>   struct drm_device *dev = crtc->dev;
> + struct drm_plane *plane = crtc->cursor;
>   struct drm_framebuffer *fb = 

Re: [Intel-gfx] [PATCH 11/11] drm/i915: Allow user control over preempt timeout on the important context

[Chris Wilson]

Quoting Chris Wilson (2018-03-26 20:52:06)
> Quoting Tvrtko Ursulin (2018-03-26 18:09:29)
> > 
> > On 26/03/2018 12:50, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
> > > b/drivers/gpu/drm/i915/i915_gem_context.h
> > > index 7854262ddfd9..74d4cadd729e 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_context.h
> > > +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> > > @@ -150,6 +150,19 @@ struct i915_gem_context {
> > >*/
> > >   int priority;
> > >   
> > > + /**
> > > +  * @preempt_timeout: QoS guarantee for the high priority context
> > > +  *
> > > +  * Some clients need a guarantee that they will start executing
> > > +  * within a certain window, even at the expense of others. This 
> > > entails
> > > +  * that if a preemption request is not honoured by the active 
> > > context
> > > +  * within the timeout, we will reset the GPU to evict the hog and
> > > +  * run the high priority context instead.
> > > +  *
> > > +  * Timeout is stored in nanoseconds; exclusive max of 1s.
> > 
> > Why did you think we would want to limit it to 1s?
> 
> There's a realistic upper bound of hangcheck interval, say 6s. But
> that's completely internal and so irrelevant to the API. 1s was just in
> case we used any struct timespec and so could completely ignore the
> division, but it really stems from forgetting about ns_to_ktime()...
> 
> Entirely arbitrary. I just couldn't believe setting a hrtimer for longer
> than smallval made sense, so plumped for something safe to fit in 32b.

Also it ties into using hrtimer instead of jiffies. My expectation was
that timeout would be on the order of a millisecond (on the high side);
if we are talking whole seconds we should switch to jiffies.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:22:52PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> drm_atomic_helper_shutdown() needs to release the reference held by
> plane->fb, so we want to use drm_atomic_clean_old_fb() in
> drm_atomic_helper_disable_all(). However during suspend/resume, gpu
> reset and load detection we should probably leave that stuff alone,
> as otherwise we'd have to make sure we put them back again when
> we restore the duplicated state to the device. Seems simpler to me
> to not touch any of it anyway.
> 
> v2: Don't inflict the clean_old_fbs bool to drivers (Daniel)
> 
> Cc: martin.pe...@free.fr
> Cc: ch...@chris-wilson.co.uk
> Cc: Dave Airlie  (v1)

More funny (v1) I just noticed ...
-Daniel

> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 67 
> ++---
>  1 file changed, 40 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c48f187d08de..39a69508d8c9 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2881,31 +2881,9 @@ int __drm_atomic_helper_set_config(struct drm_mode_set 
> *set,
>   return 0;
>  }
>  
> -/**
> - * drm_atomic_helper_disable_all - disable all currently active outputs
> - * @dev: DRM device
> - * @ctx: lock acquisition context
> - *
> - * Loops through all connectors, finding those that aren't turned off and 
> then
> - * turns them off by setting their DPMS mode to OFF and deactivating the CRTC
> - * that they are connected to.
> - *
> - * This is used for example in suspend/resume to disable all currently active
> - * functions when suspending. If you just want to shut down everything at 
> e.g.
> - * driver unload, look at drm_atomic_helper_shutdown().
> - *
> - * Note that if callers haven't already acquired all modeset locks this might
> - * return -EDEADLK, which must be handled by calling drm_modeset_backoff().
> - *
> - * Returns:
> - * 0 on success or a negative error code on failure.
> - *
> - * See also:
> - * drm_atomic_helper_suspend(), drm_atomic_helper_resume() and
> - * drm_atomic_helper_shutdown().
> - */
> -int drm_atomic_helper_disable_all(struct drm_device *dev,
> -   struct drm_modeset_acquire_ctx *ctx)
> +static int __drm_atomic_helper_disable_all(struct drm_device *dev,
> +struct drm_modeset_acquire_ctx *ctx,
> +bool clean_old_fbs)
>  {
>   struct drm_atomic_state *state;
>   struct drm_connector_state *conn_state;
> @@ -2914,6 +2892,7 @@ int drm_atomic_helper_disable_all(struct drm_device 
> *dev,
>   struct drm_plane *plane;
>   struct drm_crtc_state *crtc_state;
>   struct drm_crtc *crtc;
> + unsigned int plane_mask = 0;
>   int ret, i;
>  
>   state = drm_atomic_state_alloc(dev);
> @@ -2956,14 +2935,48 @@ int drm_atomic_helper_disable_all(struct drm_device 
> *dev,
>   goto free;
>  
>   drm_atomic_set_fb_for_plane(plane_state, NULL);
> +
> + if (clean_old_fbs) {
> + plane->old_fb = plane->fb;
> + plane_mask |= BIT(drm_plane_index(plane));
> + }
>   }
>  
>   ret = drm_atomic_commit(state);
>  free:
> + drm_atomic_clean_old_fb(dev, plane_mask, ret);
> +
>   drm_atomic_state_put(state);
>   return ret;
>  }
> -
> +/**
> + * drm_atomic_helper_disable_all - disable all currently active outputs
> + * @dev: DRM device
> + * @ctx: lock acquisition context
> + *
> + * Loops through all connectors, finding those that aren't turned off and 
> then
> + * turns them off by setting their DPMS mode to OFF and deactivating the CRTC
> + * that they are connected to.
> + *
> + * This is used for example in suspend/resume to disable all currently active
> + * functions when suspending. If you just want to shut down everything at 
> e.g.
> + * driver unload, look at drm_atomic_helper_shutdown().
> + *
> + * Note that if callers haven't already acquired all modeset locks this might
> + * return -EDEADLK, which must be handled by calling drm_modeset_backoff().
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + *
> + * See also:
> + * drm_atomic_helper_suspend(), drm_atomic_helper_resume() and
> + * drm_atomic_helper_shutdown().
> + */
> +int drm_atomic_helper_disable_all(struct drm_device *dev,
> +   struct drm_modeset_acquire_ctx *ctx)
> +{
> + return __drm_atomic_helper_disable_all(dev, ctx, false);
> +}
>  EXPORT_SYMBOL(drm_atomic_helper_disable_all);
>  
>  /**
> @@ -2986,7 +2999,7 @@ void drm_atomic_helper_shutdown(struct drm_device *dev)
>   while (1) {
>

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

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:22:54PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> drm_atomic_helper_commit_duplicated_state() should only be called
> resume/reset/load_detect paths where plane->old_fb should always be
> NULL and plane->fb should be equal to the new_plane_state->fb.
> Assert that is indeed the case.
> 
> Cc: martin.pe...@free.fr
> Cc: ch...@chris-wilson.co.uk
> Cc: Dave Airlie  (v1)

The (v1) here looks funny. dim add-missing-cc not working?

> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 39a69508d8c9..1b39ebf2be2e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3106,8 +3106,13 @@ int drm_atomic_helper_commit_duplicated_state(struct 
> drm_atomic_state *state,
>  
>   state->acquire_ctx = ctx;
>  
> - for_each_new_plane_in_state(state, plane, new_plane_state, i)
> + for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> + WARN_ON(plane->crtc != new_plane_state->crtc);
> + WARN_ON(plane->fb != new_plane_state->fb);
> + WARN_ON(plane->old_fb);

Yeah I think with your rework of how this works this holds true now.

Reviewed-by: Daniel Vetter 

> +
>   state->planes[i].old_state = plane->state;
> + }
>  
>   for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
>   state->crtcs[i].old_state = crtc->state;
> -- 
> 2.16.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:22:53PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Keep the primary->crtc in sync with the state->crtc (also with
> primary->fb and state->fb) when disabling the crtc (and thus also
> the primary) via setcrtc().
> 
> Signed-off-by: Ville Syrjälä 

Yeah seems more consistent, and we do the same for atomic already. Only 2
legacy drivers seem to look at this (armada and shmob), and I think both
should be fine.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_crtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 03583887cfec..7a973ada7195 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -471,7 +471,7 @@ static int __drm_mode_set_config_internal(struct 
> drm_mode_set *set,
>  
>   ret = crtc->funcs->set_config(set, ctx);
>   if (ret == 0) {
> - crtc->primary->crtc = crtc;
> + crtc->primary->crtc = fb ? crtc : NULL;
>   crtc->primary->fb = fb;
>   }
>  
> -- 
> 2.16.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Support for Guc responses and requests (rev3)

[Patchwork]

== Series Details ==

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

== Summary ==

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

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-cnl-y3) fdo#103191

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

fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:443s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:541s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:514s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:516s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:520s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:509s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:584s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:431s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:322s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:470s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:428s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:665s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:444s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:536s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:511s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:432s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:590s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:402s
Blacklisted hosts:
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:570s
fi-cnl-psr   total:224  pass:198  dwarn:0   dfail:0   fail:1   skip:24 
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:485s

89eddd507c0ef264c37110f485c78cf9138c8be0 drm-tip: 2018y-03m-26d-19h-50m-03s UTC 
integration manifest
f032db5c2fe5 HAX: Enable GuC for CI
5cb4377932b0 drm/i915/guc: Trace messages from CT while in debug
ce08f71b0a81 drm/i915/guc: Handle default action received over CT
6ee0ce3642da drm/i915/guc: Prepare to process incoming requests from CT
851d45c0d1ac drm/i915/guc: Implement response handling in send_ct()
3ce83cb4aec2 drm/i915/guc: Use better name for helper wait function
9a9a5c5fc140 drm/i915/guc: Prepare to handle messages from CT RECV buffer
70aeb9589bb1 drm/i915/guc: Make event handler a virtual function
d17930ce159d drm/i915/guc: Implement response handling in send_mmio()
a14df2315765 drm/i915/guc: Prepare send() function to accept bigger response
d81e70189827 drm/i915/guc: Add support for data reporting in GuC responses
89147dab30ef drm/i915/guc: Add documentation for MMIO based communication

== Logs ==

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

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

[Daniel Vetter]

On Thu, Mar 22, 2018 at 05:22:52PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> drm_atomic_helper_shutdown() needs to release the reference held by
> plane->fb, so we want to use drm_atomic_clean_old_fb() in
> drm_atomic_helper_disable_all(). However during suspend/resume, gpu
> reset and load detection we should probably leave that stuff alone,
> as otherwise we'd have to make sure we put them back again when
> we restore the duplicated state to the device. Seems simpler to me
> to not touch any of it anyway.
> 
> v2: Don't inflict the clean_old_fbs bool to drivers (Daniel)
> 
> Cc: martin.pe...@free.fr
> Cc: ch...@chris-wilson.co.uk
> Cc: Dave Airlie  (v1)
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 

I think this would be cleaner diff to read if you squash the first 2
patches together. Also avoids the bisect fail. With that (and I trust you
to come up with a suitably merged commit message):

Reviewed-by: Daniel Vetter 

I reviewed this by re-reading the analysis from 49d70aeaeca8f62b72b77 and
trusting my former self :-)

Cheers, Daniel

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 67 
> ++---
>  1 file changed, 40 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c48f187d08de..39a69508d8c9 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2881,31 +2881,9 @@ int __drm_atomic_helper_set_config(struct drm_mode_set 
> *set,
>   return 0;
>  }
>  
> -/**
> - * drm_atomic_helper_disable_all - disable all currently active outputs
> - * @dev: DRM device
> - * @ctx: lock acquisition context
> - *
> - * Loops through all connectors, finding those that aren't turned off and 
> then
> - * turns them off by setting their DPMS mode to OFF and deactivating the CRTC
> - * that they are connected to.
> - *
> - * This is used for example in suspend/resume to disable all currently active
> - * functions when suspending. If you just want to shut down everything at 
> e.g.
> - * driver unload, look at drm_atomic_helper_shutdown().
> - *
> - * Note that if callers haven't already acquired all modeset locks this might
> - * return -EDEADLK, which must be handled by calling drm_modeset_backoff().
> - *
> - * Returns:
> - * 0 on success or a negative error code on failure.
> - *
> - * See also:
> - * drm_atomic_helper_suspend(), drm_atomic_helper_resume() and
> - * drm_atomic_helper_shutdown().
> - */
> -int drm_atomic_helper_disable_all(struct drm_device *dev,
> -   struct drm_modeset_acquire_ctx *ctx)
> +static int __drm_atomic_helper_disable_all(struct drm_device *dev,
> +struct drm_modeset_acquire_ctx *ctx,
> +bool clean_old_fbs)
>  {
>   struct drm_atomic_state *state;
>   struct drm_connector_state *conn_state;
> @@ -2914,6 +2892,7 @@ int drm_atomic_helper_disable_all(struct drm_device 
> *dev,
>   struct drm_plane *plane;
>   struct drm_crtc_state *crtc_state;
>   struct drm_crtc *crtc;
> + unsigned int plane_mask = 0;
>   int ret, i;
>  
>   state = drm_atomic_state_alloc(dev);
> @@ -2956,14 +2935,48 @@ int drm_atomic_helper_disable_all(struct drm_device 
> *dev,
>   goto free;
>  
>   drm_atomic_set_fb_for_plane(plane_state, NULL);
> +
> + if (clean_old_fbs) {
> + plane->old_fb = plane->fb;
> + plane_mask |= BIT(drm_plane_index(plane));
> + }
>   }
>  
>   ret = drm_atomic_commit(state);
>  free:
> + drm_atomic_clean_old_fb(dev, plane_mask, ret);
> +
>   drm_atomic_state_put(state);
>   return ret;
>  }
> -
> +/**
> + * drm_atomic_helper_disable_all - disable all currently active outputs
> + * @dev: DRM device
> + * @ctx: lock acquisition context
> + *
> + * Loops through all connectors, finding those that aren't turned off and 
> then
> + * turns them off by setting their DPMS mode to OFF and deactivating the CRTC
> + * that they are connected to.
> + *
> + * This is used for example in suspend/resume to disable all currently active
> + * functions when suspending. If you just want to shut down everything at 
> e.g.
> + * driver unload, look at drm_atomic_helper_shutdown().
> + *
> + * Note that if callers haven't already acquired all modeset locks this might
> + * return -EDEADLK, which must be handled by calling drm_modeset_backoff().
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + *
> + * See also:
> + * drm_atomic_helper_suspend(), drm_atomic_helper_resume() and
> + * drm_atomic_helper_shutdown().
> + */
> +int drm_atomic_helper_disable_all(struct 

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

[Patchwork]

== Series Details ==

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

== Summary ==

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

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

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

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

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

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

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

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

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

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

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

Commit: HAX: Enable GuC for CI
Okay!

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

Re: [Intel-gfx] [PATCH 09/11] drm/i915/perf: allowing opening the perf stream without sampling

[Matthew Auld]

On 26 March 2018 at 10:08, Lionel Landwerlin
 wrote:
> We want to allow a user to configure the OA hardware so that
> MI_RECORD_PERF_COUNT is functional but without having to deal with the
> OA buffer.
>
> This is an interesting optimization we can apply on Gen7.5 has the OA
> unit perfectly clocks off if you've configured it to filter on a
> particular context id. In this case, the userspace (like the
> INTEL_performance_query extension in Mesa) can use
> MI_RECORD_PERF_COUNT without having to read the OA buffer.
>
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 56 
> ++--
>  1 file changed, 42 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index c91ad447207e..55c7631ad3c2 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -421,6 +421,14 @@ static u32 gen7_oa_hw_tail_read(struct drm_i915_private 
> *dev_priv)
> return oastatus1 & GEN7_OASTATUS1_TAIL_MASK;
>  }
>
> +static bool i915_perf_stream_produces_reports(struct i915_perf_stream 
> *stream)

Maybe just oa_stream_produces_reports ?

> +{
> +   struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> +   return (stream->sample_flags & SAMPLE_OA_REPORT) != 0 &&
> +   dev_priv->perf.oa.periodic;

stream->dev_priv->perf.oa.periodic; then we can drop dev_priv.

> +}
> +
>  /**
>   * oa_buffer_check_unlocked - check for data and update tail ptr state
>   * @dev_priv: i915 device instance
> @@ -453,6 +461,8 @@ static bool oa_buffer_check_unlocked(struct 
> drm_i915_private *dev_priv)
> u32 head, hw_tail, aged_tail, aging_tail;
> u64 now;
>
> +   
> GEM_BUG_ON(!i915_perf_stream_produces_reports(dev_priv->perf.oa.exclusive_stream));
> +
> /* We have to consider the (unlikely) possibility that read() errors
>  * could result in an OA buffer reset which might reset the head,
>  * tails[] and aged_tail state.
> @@ -1153,8 +1163,7 @@ static int i915_oa_wait_unlocked(struct 
> i915_perf_stream *stream)
>  {
> struct drm_i915_private *dev_priv = stream->dev_priv;
>
> -   /* We would wait indefinitely if periodic sampling is not enabled */
> -   if (!dev_priv->perf.oa.periodic)
> +   if (!i915_perf_stream_produces_reports(stream))
> return -EIO;
>
> return wait_event_interruptible(dev_priv->perf.oa.poll_wq,
> @@ -1821,6 +1830,7 @@ static int gen8_enable_metric_set(struct 
> drm_i915_private *dev_priv,
>   const struct i915_perf_stream *stream)
>  {
> struct i915_oa_config *oa_config = stream->oa_config;
> +   u32 oa_debug_value = 0;
> int ret;
>
> /*
> @@ -1847,11 +1857,23 @@ static int gen8_enable_metric_set(struct 
> drm_i915_private *dev_priv,
>  * RPT_ID field.
>  */
> if (IS_GEN9(dev_priv) || IS_GEN10(dev_priv)) {
> -   I915_WRITE(GEN8_OA_DEBUG,
> -  
> _MASKED_BIT_ENABLE(GEN9_OA_DEBUG_DISABLE_CLK_RATIO_REPORTS |
> - 
> GEN9_OA_DEBUG_INCLUDE_CLK_RATIO));
> +   oa_debug_value |=
> +   
> _MASKED_BIT_ENABLE(GEN9_OA_DEBUG_DISABLE_CLK_RATIO_REPORTS |
> +  GEN9_OA_DEBUG_INCLUDE_CLK_RATIO);
> }
>
> +   /*
> +* If the user didn't require OA reports, instruct the hardware not to
> +* emit ctx switch reports (mind your head, we might be disabling the
> +* disable).
> +*/
> +   oa_debug_value |=
> +   (stream->sample_flags & SAMPLE_OA_REPORT) ?
> +   _MASKED_BIT_DISABLE(GEN9_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS) 
> :
> +   _MASKED_BIT_ENABLE(GEN9_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS);
> +
> +   I915_WRITE(GEN8_OA_DEBUG, oa_debug_value);
> +
> /*
>  * Update all contexts prior writing the mux configurations as we need
>  * to make sure all slices/subslices are ON before writing to NOA
> @@ -1960,7 +1982,7 @@ static void i915_oa_stream_enable(struct 
> i915_perf_stream *stream)
>
> dev_priv->perf.oa.ops.oa_enable(dev_priv, stream);
>
> -   if (dev_priv->perf.oa.periodic)
> +   if (i915_perf_stream_produces_reports(stream))
> hrtimer_start(_priv->perf.oa.poll_check_timer,
>   ns_to_ktime(POLL_PERIOD),
>   HRTIMER_MODE_REL_PINNED);
> @@ -1990,7 +2012,7 @@ static void i915_oa_stream_disable(struct 
> i915_perf_stream *stream)
>
> dev_priv->perf.oa.ops.oa_disable(dev_priv);
>
> -   if (dev_priv->perf.oa.periodic)
> +   if (i915_perf_stream_produces_reports(stream))
> hrtimer_cancel(_priv->perf.oa.poll_check_timer);
>  }
>
> @@ -2038,11 +2060,6 @@ static int 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

[Chris Wilson]

Quoting Patchwork (2018-03-26 17:53:44)
> Test gem_userptr_blits:
> Subgroup coherency-unsync:
> pass   -> INCOMPLETE (shard-hsw)

Forgot that obj->userptr.mn may not exist.

> Subgroup dmabuf-sync:
> pass   -> DMESG-WARN (shard-hsw)

But this is the tricky lockdep one, warning of the recursion from gup
into mmu_invalidate_range, i.e.

down_read(_mmu_notifier->sem);
down_read(_struct->mmap_sem);
gup();
down_write(_mmut_notifier->sem);

That seems a genuine deadlock... So I wonder how we managed to get a
lockdep splat and not a dead machine. Maybe gup never triggers the
recursion for our set of flags? Hmm.
-Chris

___
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: Reword warning for missing cases (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Reword warning for missing cases (rev2)
URL   : https://patchwork.freedesktop.org/series/39821/
State : success

== Summary ==

 Possible new issues:

Test kms_rotation_crc:
Subgroup cursor-rotation-180:
fail   -> PASS   (shard-snb)

 Known issues:

Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup 2x-wf_vblank-ts-check:
fail   -> PASS   (shard-hsw) fdo#100368 +2
Subgroup flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887 +1
Test kms_plane_multiple:
Subgroup atomic-pipe-a-tiling-x:
fail   -> PASS   (shard-snb) fdo#103166
Test kms_rotation_crc:
Subgroup primary-rotation-180:
pass   -> FAIL   (shard-snb) fdo#103925

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

shard-apltotal:3495 pass:1831 dwarn:1   dfail:0   fail:7   skip:1655 
time:12860s
shard-hswtotal:3495 pass:1778 dwarn:1   dfail:0   fail:6   skip:1709 
time:11508s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:6948s
Blacklisted hosts:
shard-kbltotal:3495 pass:1955 dwarn:1   dfail:0   fail:9   skip:1530 
time:9694s

== Logs ==

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

Re: [Intel-gfx] [PATCH 11/11] drm/i915: Allow user control over preempt timeout on the important context

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-26 18:09:29)
> 
> On 26/03/2018 12:50, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
> > b/drivers/gpu/drm/i915/i915_gem_context.h
> > index 7854262ddfd9..74d4cadd729e 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> > @@ -150,6 +150,19 @@ struct i915_gem_context {
> >*/
> >   int priority;
> >   
> > + /**
> > +  * @preempt_timeout: QoS guarantee for the high priority context
> > +  *
> > +  * Some clients need a guarantee that they will start executing
> > +  * within a certain window, even at the expense of others. This 
> > entails
> > +  * that if a preemption request is not honoured by the active context
> > +  * within the timeout, we will reset the GPU to evict the hog and
> > +  * run the high priority context instead.
> > +  *
> > +  * Timeout is stored in nanoseconds; exclusive max of 1s.
> 
> Why did you think we would want to limit it to 1s?

There's a realistic upper bound of hangcheck interval, say 6s. But
that's completely internal and so irrelevant to the API. 1s was just in
case we used any struct timespec and so could completely ignore the
division, but it really stems from forgetting about ns_to_ktime()...

Entirely arbitrary. I just couldn't believe setting a hrtimer for longer
than smallval made sense, so plumped for something safe to fit in 32b.
-Chris
___
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 [v4,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev3)

[Patchwork]

== Series Details ==

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

== Summary ==

 Possible new issues:

Test kms_rotation_crc:
Subgroup cursor-rotation-180:
fail   -> PASS   (shard-snb)

 Known issues:

Test kms_flip:
Subgroup plain-flip-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368 +3
Test kms_plane_multiple:
Subgroup atomic-pipe-a-tiling-x:
fail   -> PASS   (shard-snb) fdo#103166
Test kms_rotation_crc:
Subgroup primary-rotation-180:
pass   -> FAIL   (shard-snb) fdo#103925

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

shard-apltotal:3495 pass:1831 dwarn:1   dfail:0   fail:7   skip:1655 
time:12810s
shard-hswtotal:3495 pass:1780 dwarn:1   dfail:0   fail:4   skip:1709 
time:11592s
shard-snbtotal:3495 pass:1374 dwarn:1   dfail:0   fail:3   skip:2117 
time:6975s
Blacklisted hosts:
shard-kbltotal:3495 pass:1956 dwarn:1   dfail:0   fail:9   skip:1529 
time:9631s

== Logs ==

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

[Intel-gfx] [PATCH v5 07/12] drm/i915/guc: Use better name for helper wait function

[Michal Wajdeczko]

In next patch we will introduce another way of waiting for the response
that will use RECV buffer. To avoid misleading names, rename old wait
function to reflect the fact that it is based on descriptor update.

v2: fix comment style (Michal)
v3: use more specific name (Michel)

Signed-off-by: Michal Wajdeczko 
Reviewed-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_guc_ct.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 14f55de..2d805a2 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -351,16 +351,25 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
return 0;
 }
 
-/* Wait for the response from the GuC.
+/**
+ * wait_for_ctb_desc_update - Wait for the CT buffer descriptor update.
+ * @desc:  buffer descriptor
  * @fence: response fence
  * @status:placeholder for status
- * return: 0 response received (status is valid)
- * -ETIMEDOUT no response within hardcoded timeout
- * -EPROTO no response, ct buffer was in error
+ *
+ * Guc will update CT buffer descriptor with new fence and status
+ * after processing the command identified by the fence. Wait for
+ * specified fence and then read from the descriptor status of the
+ * command.
+ *
+ * Return:
+ * *   0 response received (status is valid)
+ * *   -ETIMEDOUT no response within hardcoded timeout
+ * *   -EPROTO no response, CT buffer is in error
  */
-static int wait_for_response(struct guc_ct_buffer_desc *desc,
-u32 fence,
-u32 *status)
+static int wait_for_ctb_desc_update(struct guc_ct_buffer_desc *desc,
+   u32 fence,
+   u32 *status)
 {
int err;
 
@@ -414,7 +423,7 @@ static int ctch_send(struct intel_guc *guc,
 
intel_guc_notify(guc);
 
-   err = wait_for_response(desc, fence, status);
+   err = wait_for_ctb_desc_update(desc, fence, status);
if (unlikely(err))
return err;
if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status))
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 11/12] drm/i915/guc: Trace messages from CT while in debug

[Michal Wajdeczko]

During debug we may want to investigate all communication
from the Guc. Add proper tracing macros in debug config.

v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal)
v3: use dedicated Kconfig (Daniele)
v4: checkpatch

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Acked-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/Kconfig.debug  | 12 +++
 drivers/gpu/drm/i915/intel_guc_ct.c | 43 ++---
 2 files changed, 43 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index dd5bf63..80efee1 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -90,6 +90,18 @@ config DRM_I915_SW_FENCE_CHECK_DAG
 
   If in doubt, say "N".
 
+config DRM_I915_DEBUG_GUC
+bool "Enable additional driver debugging for GuC"
+depends on DRM_I915
+default n
+help
+  Choose this option to turn on extra driver debugging that may affect
+  performance but will help resolve GuC related issues.
+
+  Recommended for driver developers only.
+
+  If in doubt, say "N".
+
 config DRM_I915_SELFTEST
bool "Enable selftests upon driver load"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index e837084..1271221 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -24,6 +24,12 @@
 #include "i915_drv.h"
 #include "intel_guc_ct.h"
 
+#ifdef CONFIG_DRM_I915_DEBUG_GUC
+#define CT_DEBUG_DRIVER(...)   DRM_DEBUG_DRIVER(__VA_ARGS__)
+#else
+#define CT_DEBUG_DRIVER(...)
+#endif
+
 struct ct_request {
struct list_head link;
u32 fence;
@@ -78,8 +84,8 @@ static inline const char *guc_ct_buffer_type_to_str(u32 type)
 static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
u32 cmds_addr, u32 size, u32 owner)
 {
-   DRM_DEBUG_DRIVER("CT: desc %p init addr=%#x size=%u owner=%u\n",
-desc, cmds_addr, size, owner);
+   CT_DEBUG_DRIVER("CT: desc %p init addr=%#x size=%u owner=%u\n",
+   desc, cmds_addr, size, owner);
memset(desc, 0, sizeof(*desc));
desc->addr = cmds_addr;
desc->size = size;
@@ -88,8 +94,8 @@ static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc 
*desc,
 
 static void guc_ct_buffer_desc_reset(struct guc_ct_buffer_desc *desc)
 {
-   DRM_DEBUG_DRIVER("CT: desc %p reset head=%u tail=%u\n",
-desc, desc->head, desc->tail);
+   CT_DEBUG_DRIVER("CT: desc %p reset head=%u tail=%u\n",
+   desc, desc->head, desc->tail);
desc->head = 0;
desc->tail = 0;
desc->is_in_error = 0;
@@ -185,8 +191,8 @@ static int ctch_init(struct intel_guc *guc,
err = PTR_ERR(blob);
goto err_vma;
}
-   DRM_DEBUG_DRIVER("CT: vma base=%#x\n",
-intel_guc_ggtt_offset(guc, ctch->vma));
+   CT_DEBUG_DRIVER("CT: vma base=%#x\n",
+   intel_guc_ggtt_offset(guc, ctch->vma));
 
/* store pointers to desc and cmds */
for (i = 0; i < ARRAY_SIZE(ctch->ctbs); i++) {
@@ -200,8 +206,8 @@ static int ctch_init(struct intel_guc *guc,
 err_vma:
i915_vma_unpin_and_release(>vma);
 err_out:
-   DRM_DEBUG_DRIVER("CT: channel %d initialization failed; err=%d\n",
-ctch->owner, err);
+   CT_DEBUG_DRIVER("CT: channel %d initialization failed; err=%d\n",
+   ctch->owner, err);
return err;
 }
 
@@ -221,8 +227,8 @@ static int ctch_open(struct intel_guc *guc,
int err;
int i;
 
-   DRM_DEBUG_DRIVER("CT: channel %d reopen=%s\n",
-ctch->owner, yesno(ctch_is_open(ctch)));
+   CT_DEBUG_DRIVER("CT: channel %d reopen=%s\n",
+   ctch->owner, yesno(ctch_is_open(ctch)));
 
if (!ctch->vma) {
err = ctch_init(guc, ctch);
@@ -355,6 +361,10 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
 (want_response ? GUC_CT_MSG_SEND_STATUS : 0) |
 (action[0] << GUC_CT_MSG_ACTION_SHIFT);
 
+   CT_DEBUG_DRIVER("CT: writing %*phn %*phn %*phn\n",
+   4, , 4, ,
+   4 * (len - 1), [1]);
+
cmds[tail] = header;
tail = (tail + 1) % size;
 
@@ -545,6 +555,9 @@ static int intel_guc_send_ct(struct intel_guc *guc, const 
u32 *action, u32 len,
if (unlikely(ret < 0)) {
DRM_ERROR("CT: send action %#X failed; err=%d status=%#X\n",
  action[0], ret, status);
+   } else if (unlikely(ret)) {
+   CT_DEBUG_DRIVER("CT: send action %#x 

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

[Michal Wajdeczko]

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

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

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

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 41b071c..aa810ad 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -32,10 +32,17 @@ struct ct_request {
u32 *response_buf;
 };
 
+struct ct_incoming_request {
+   struct list_head link;
+   u32 msg[];
+};
+
 enum { CTB_SEND = 0, CTB_RECV = 1 };
 
 enum { CTB_OWNER_HOST = 0 };
 
+static void ct_incoming_request_worker_func(struct work_struct *w);
+
 /**
  * intel_guc_ct_init_early - Initialize CT state without requiring device 
access
  * @ct: pointer to CT struct
@@ -47,6 +54,8 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
 
spin_lock_init(>lock);
INIT_LIST_HEAD(>pending_requests);
+   INIT_LIST_HEAD(>incoming_requests);
+   INIT_WORK(>worker, ct_incoming_request_worker_func);
 }
 
 static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
@@ -682,13 +691,97 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
const u32 *msg)
return 0;
 }
 
+static void ct_process_request(struct intel_guc_ct *ct,
+  u32 action, u32 len, const u32 *payload)
+{
+   switch (action) {
+   default:
+   DRM_ERROR("CT: unexpected request %x %*phn\n",
+ action, 4 * len, payload);
+   break;
+   }
+}
+
+static bool ct_process_incoming_requests(struct intel_guc_ct *ct)
+{
+   unsigned long flags;
+   struct ct_incoming_request *request;
+   u32 header;
+   u32 *payload;
+   bool done;
+
+   spin_lock_irqsave(>lock, flags);
+   request = list_first_entry_or_null(>incoming_requests,
+  struct ct_incoming_request, link);
+   if (request)
+   list_del(>link);
+   done = !!list_empty(>incoming_requests);
+   spin_unlock_irqrestore(>lock, flags);
+
+   if (!request)
+   return true;
+
+   header = request->msg[0];
+   payload = >msg[1];
+   ct_process_request(ct,
+  ct_header_get_action(header),
+  ct_header_get_len(header),
+  payload);
+
+   kfree(request);
+   return done;
+}
+
+static void ct_incoming_request_worker_func(struct work_struct *w)
+{
+   struct intel_guc_ct *ct = container_of(w, struct intel_guc_ct, worker);
+   bool done;
+
+   done = ct_process_incoming_requests(ct);
+   if (!done)
+   queue_work(system_unbound_wq, >worker);
+}
+
+/**
+ * DOC: CTB GuC to Host request
+ *
+ * Format of the CTB GuC to Host request message is as follows::
+ *
+ *  ++-+-+-+-+-+
+ *  |   msg[0]   |   [1]   |   [2]   |   [3]   |   ...   |  [n-1]  |
+ *  ++-+-+-+-+-+
+ *  |   MESSAGE  |   MESSAGE PAYLOAD   |
+ *  +   HEADER   +-+-+-+-+-+
+ *  ||0|1|2|   ...   |n|
+ *  ++=+=+=+=+=+
+ *  | len|request specific data|
+ *  +--+-+-+-+-+-+-+
+ *
+ *   ^---len---^
+ */
+
 static int ct_handle_request(struct intel_guc_ct *ct, const u32 *msg)
 {
u32 header = msg[0];
+   u32 len = ct_header_get_len(header);
+   u32 msglen = len + 1; /* total message length including header */
+   struct ct_incoming_request *request;
+   unsigned long flags;
 
GEM_BUG_ON(ct_header_is_response(header));
 
-   /* XXX */
+   request = kmalloc(sizeof(*request) + 4 * msglen, GFP_ATOMIC);
+   if (unlikely(!request)) {
+   DRM_ERROR("CT: dropping request %*phn\n", 4 * msglen, msg);
+   return 0; /* XXX: -ENOMEM ? */
+   }
+   memcpy(request->msg, msg, 4 * msglen);
+
+   spin_lock_irqsave(>lock, flags);
+   list_add_tail(>link, >incoming_requests);
+   spin_unlock_irqrestore(>lock, flags);
+
+   

[Intel-gfx] [PATCH v5 06/12] drm/i915/guc: Prepare to handle messages from CT RECV buffer

[Michal Wajdeczko]

GuC can respond to our commands not only by updating SEND buffer
descriptor, but can also send a response message over RECV buffer.
Guc can also send unsolicited request messages over RECV buffer.
Let's start reading those messages and make placeholders
for actual response/request handlers.

v2: misc improvements (Michal)
v3: change response detection (Michal)
invalid status is protocol error (Michal)
v4: rebase
v5: fix checkpatch (Michel)
don't use fields before check (Jani)
add some documentation (Michal)

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Michel Thierry  # 4.5
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_guc_ct.c | 184 +++-
 1 file changed, 183 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index a54bf58..14f55de 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -273,6 +273,24 @@ static u32 ctch_get_next_fence(struct intel_guc_ct_channel 
*ctch)
return ++ctch->next_fence;
 }
 
+/**
+ * DOC: CTB Host to GuC request
+ *
+ * Format of the CTB Host to GuC request message is as follows::
+ *
+ *  ++-+-+-+-+
+ *  |   msg[0]   |   [1]   |   [2]   |   ...   |  [n-1]  |
+ *  ++-+-+-+-+
+ *  |   MESSAGE  |   MESSAGE PAYLOAD |
+ *  +   HEADER   +-+-+-+-+
+ *  ||0|1|   ...   |n|
+ *  ++=+=+=+=+
+ *  |  len >= 1  |  FENCE  | request specific data   |
+ *  +--+-+-+-+-+-+
+ *
+ *   ^-len---^
+ */
+
 static int ctb_write(struct intel_guc_ct_buffer *ctb,
 const u32 *action,
 u32 len /* in dwords */,
@@ -305,7 +323,8 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
if (unlikely(used + len + 1 >= size))
return -ENOSPC;
 
-   /* Write the message. The format is the following:
+   /*
+* Write the message. The format is the following:
 * DW0: header (including action code)
 * DW1: fence
 * DW2+: action data
@@ -427,6 +446,167 @@ static int intel_guc_send_ct(struct intel_guc *guc, const 
u32 *action, u32 len,
return ret;
 }
 
+static inline unsigned int ct_header_get_len(u32 header)
+{
+   return (header >> GUC_CT_MSG_LEN_SHIFT) & GUC_CT_MSG_LEN_MASK;
+}
+
+static inline unsigned int ct_header_get_action(u32 header)
+{
+   return (header >> GUC_CT_MSG_ACTION_SHIFT) & GUC_CT_MSG_ACTION_MASK;
+}
+
+static inline bool ct_header_is_response(u32 header)
+{
+   return ct_header_get_action(header) == INTEL_GUC_ACTION_DEFAULT;
+}
+
+static int ctb_read(struct intel_guc_ct_buffer *ctb, u32 *data)
+{
+   struct guc_ct_buffer_desc *desc = ctb->desc;
+   u32 head = desc->head / 4;  /* in dwords */
+   u32 tail = desc->tail / 4;  /* in dwords */
+   u32 size = desc->size / 4;  /* in dwords */
+   u32 *cmds = ctb->cmds;
+   s32 available;  /* in dwords */
+   unsigned int len;
+   unsigned int i;
+
+   GEM_BUG_ON(desc->size % 4);
+   GEM_BUG_ON(desc->head % 4);
+   GEM_BUG_ON(desc->tail % 4);
+   GEM_BUG_ON(tail >= size);
+   GEM_BUG_ON(head >= size);
+
+   /* tail == head condition indicates empty */
+   available = tail - head;
+   if (unlikely(available == 0))
+   return -ENODATA;
+
+   /* beware of buffer wrap case */
+   if (unlikely(available < 0))
+   available += size;
+   GEM_BUG_ON(available < 0);
+
+   data[0] = cmds[head];
+   head = (head + 1) % size;
+
+   /* message len with header */
+   len = ct_header_get_len(data[0]) + 1;
+   if (unlikely(len > (u32)available)) {
+   DRM_ERROR("CT: incomplete message %*phn %*phn %*phn\n",
+ 4, data,
+ 4 * (head + available - 1 > size ?
+  size - head : available - 1), [head],
+ 4 * (head + available - 1 > size ?
+  available - 1 - size + head : 0), [0]);
+   return -EPROTO;
+   }
+
+   for (i = 1; i < len; i++) {
+   data[i] = cmds[head];
+   head = (head + 1) % size;
+   }
+
+   desc->head = head * 4;
+   return 0;
+}
+
+/**
+ * DOC: CTB GuC to Host response
+ *
+ * Format of the CTB GuC to Host response message is as follows::
+ *
+ *  

[Intel-gfx] [PATCH v5 03/12] drm/i915/guc: Prepare send() function to accept bigger response

[Michal Wajdeczko]

This is a preparation step for the upcoming patches.
We already can return some small data decoded from the command
status, but we will need more in the future.

v2: add explicit response buf size
v3: squash with helper patch

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

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 77bf4e6..a533ff8 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -310,7 +310,8 @@ void intel_guc_init_params(struct intel_guc *guc)
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_BLITTER);
 }
 
-int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len)
+int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len,
+  u32 *response_buf, u32 response_buf_size)
 {
WARN(1, "Unexpected send: action=%#x\n", *action);
return -ENODEV;
@@ -319,7 +320,8 @@ int intel_guc_send_nop(struct intel_guc *guc, const u32 
*action, u32 len)
 /*
  * This function implements the MMIO based host to GuC interface.
  */
-int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len)
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
+   u32 *response_buf, u32 response_buf_size)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
u32 status;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 13f3d1d..7ee0732 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -88,7 +88,8 @@ struct intel_guc {
struct mutex send_mutex;
 
/* GuC's FW specific send function */
-   int (*send)(struct intel_guc *guc, const u32 *data, u32 len);
+   int (*send)(struct intel_guc *guc, const u32 *data, u32 len,
+   u32 *response_buf, u32 response_buf_size);
 
/* GuC's FW specific notify function */
void (*notify)(struct intel_guc *guc);
@@ -97,7 +98,14 @@ struct intel_guc {
 static
 inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)
 {
-   return guc->send(guc, action, len);
+   return guc->send(guc, action, len, NULL, 0);
+}
+
+static inline int
+intel_guc_send_and_receive(struct intel_guc *guc, const u32 *action, u32 len,
+  u32 *response_buf, u32 response_buf_size)
+{
+   return guc->send(guc, action, len, response_buf, response_buf_size);
 }
 
 static inline void intel_guc_notify(struct intel_guc *guc)
@@ -140,8 +148,10 @@ static inline u32 intel_guc_ggtt_offset(struct intel_guc 
*guc,
 void intel_guc_fini_wq(struct intel_guc *guc);
 int intel_guc_init(struct intel_guc *guc);
 void intel_guc_fini(struct intel_guc *guc);
-int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len);
-int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len);
+int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 len,
+  u32 *response_buf, u32 response_buf_size);
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
+   u32 *response_buf, u32 response_buf_size);
 void intel_guc_to_host_event_handler(struct intel_guc *guc);
 int intel_guc_sample_forcewake(struct intel_guc *guc);
 int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index fa52259..a54bf58 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -88,7 +88,7 @@ static int guc_action_register_ct_buffer(struct intel_guc 
*guc,
int err;
 
/* Can't use generic send(), CT registration must go over MMIO */
-   err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action));
+   err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
if (err)
DRM_ERROR("CT: register %s buffer failed; err=%d\n",
  guc_ct_buffer_type_to_str(type), err);
@@ -107,7 +107,7 @@ static int guc_action_deregister_ct_buffer(struct intel_guc 
*guc,
int err;
 
/* Can't use generic send(), CT deregistration must go over MMIO */
-   err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action));
+   err = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
if (err)
DRM_ERROR("CT: deregister %s buffer failed; owner=%d err=%d\n",
  guc_ct_buffer_type_to_str(type), owner, err);
@@ -408,7 +408,8 @@ static int 

[Intel-gfx] [PATCH v5 04/12] drm/i915/guc: Implement response handling in send_mmio()

[Michal Wajdeczko]

We're using data encoded in the status MMIO as return value from send
function, but GuC may also write more data in remaining MMIO regs.
Let's copy content of these registers to the buffer provided by caller.

v2: new line (Michel)
v3: updated commit message

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Oscar Mateo 
Reviewed-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_guc.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index a533ff8..9ce01e5 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -368,11 +368,20 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len,
 " ret=%d status=0x%08X response=0x%08X\n",
 action[0], ret, status,
 I915_READ(SOFT_SCRATCH(15)));
-   } else {
-   /* Use data from the GuC response as our return value */
-   ret = INTEL_GUC_MSG_TO_DATA(status);
+   goto out;
}
 
+   if (response_buf) {
+   int count = min(response_buf_size, guc->send_regs.count - 1);
+
+   for (i = 0; i < count; i++)
+   response_buf[i] = I915_READ(guc_send_reg(guc, i + 1));
+   }
+
+   /* Use data from the GuC response as our return value */
+   ret = INTEL_GUC_MSG_TO_DATA(status);
+
+out:
intel_uncore_forcewake_put(dev_priv, guc->send_regs.fw_domains);
mutex_unlock(>send_mutex);
 
-- 
1.9.1

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

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

[Michal Wajdeczko]

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c963603..53037b5 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
1.9.1

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

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

[Michal Wajdeczko]

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

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

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

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

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

[Michal Wajdeczko]

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

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

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

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

[Intel-gfx] [PATCH v5 05/12] drm/i915/guc: Make event handler a virtual function

[Michal Wajdeczko]

On platforms with CTB based GuC communications, we will handle
GuC events in a different way. Let's make event handler a virtual
function to allow easy switch between those variants.

Credits-to: Oscar Mateo 
Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Oscar Mateo 
Reviewed-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_guc.c |  8 +++-
 drivers/gpu/drm/i915/intel_guc.h | 10 ++
 drivers/gpu/drm/i915/intel_uc.c  |  2 ++
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 9ce01e5..118db81 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -69,6 +69,7 @@ void intel_guc_init_early(struct intel_guc *guc)
mutex_init(>send_mutex);
spin_lock_init(>irq_lock);
guc->send = intel_guc_send_nop;
+   guc->handler = intel_guc_to_host_event_handler_nop;
guc->notify = gen8_guc_raise_irq;
 }
 
@@ -317,6 +318,11 @@ int intel_guc_send_nop(struct intel_guc *guc, const u32 
*action, u32 len,
return -ENODEV;
 }
 
+void intel_guc_to_host_event_handler_nop(struct intel_guc *guc)
+{
+   WARN(1, "Unexpected event: no suitable handler\n");
+}
+
 /*
  * This function implements the MMIO based host to GuC interface.
  */
@@ -388,7 +394,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len,
return ret;
 }
 
-void intel_guc_to_host_event_handler(struct intel_guc *guc)
+void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
u32 msg, val;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 7ee0732..6dc109a 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -91,6 +91,9 @@ struct intel_guc {
int (*send)(struct intel_guc *guc, const u32 *data, u32 len,
u32 *response_buf, u32 response_buf_size);
 
+   /* GuC's FW specific event handler function */
+   void (*handler)(struct intel_guc *guc);
+
/* GuC's FW specific notify function */
void (*notify)(struct intel_guc *guc);
 };
@@ -113,6 +116,11 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
 }
 
+static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
+{
+   guc->handler(guc);
+}
+
 /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
 #define GUC_GGTT_TOP   0xFEE0
 
@@ -153,6 +161,8 @@ int intel_guc_send_nop(struct intel_guc *guc, const u32 
*action, u32 len,
 int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
u32 *response_buf, u32 response_buf_size);
 void intel_guc_to_host_event_handler(struct intel_guc *guc);
+void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
+void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
 int intel_guc_sample_forcewake(struct intel_guc *guc);
 int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
 int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 4aad844..081e424 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -233,6 +233,7 @@ static int guc_enable_communication(struct intel_guc *guc)
return intel_guc_ct_enable(>ct);
 
guc->send = intel_guc_send_mmio;
+   guc->handler = intel_guc_to_host_event_handler_mmio;
return 0;
 }
 
@@ -246,6 +247,7 @@ static void guc_disable_communication(struct intel_guc *guc)
gen9_disable_guc_interrupts(dev_priv);
 
guc->send = intel_guc_send_nop;
+   guc->handler = intel_guc_to_host_event_handler_nop;
 }
 
 int intel_uc_init_misc(struct drm_i915_private *dev_priv)
-- 
1.9.1

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

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

[Michal Wajdeczko]

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

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

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

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

-- 
1.9.1

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

[Intel-gfx] [PATCH v5 01/12] drm/i915/guc: Add documentation for MMIO based communication

[Michal Wajdeczko]

As we are going to extend our use of MMIO based communication,
try to explain its mechanics and update corresponding definitions.

v2: fix checkpatch MACRO_ARG_REUSE

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Kelvin Gardiner 
Reviewed-by: Michel Thierry  #1
---
 drivers/gpu/drm/i915/intel_guc.c  | 20 
 drivers/gpu/drm/i915/intel_guc_ct.c   |  2 +-
 drivers/gpu/drm/i915/intel_guc_fwif.h | 88 ---
 3 files changed, 82 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 8f93f5b..28075e6 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -329,6 +329,9 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
GEM_BUG_ON(!len);
GEM_BUG_ON(len > guc->send_regs.count);
 
+   /* We expect only action code */
+   GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
+
/* If CT is available, we expect to use MMIO only during init/fini */
GEM_BUG_ON(HAS_GUC_CT(dev_priv) &&
*action != INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
@@ -350,18 +353,15 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
 */
ret = __intel_wait_for_register_fw(dev_priv,
   guc_send_reg(guc, 0),
-  INTEL_GUC_RECV_MASK,
-  INTEL_GUC_RECV_MASK,
+  INTEL_GUC_MSG_TYPE_MASK,
+  INTEL_GUC_MSG_TYPE_RESPONSE <<
+  INTEL_GUC_MSG_TYPE_SHIFT,
   10, 10, );
-   if (status != INTEL_GUC_STATUS_SUCCESS) {
-   /*
-* Either the GuC explicitly returned an error (which
-* we convert to -EIO here) or no response at all was
-* received within the timeout limit (-ETIMEDOUT)
-*/
-   if (ret != -ETIMEDOUT)
-   ret = -EIO;
+   /* If GuC explicitly returned an error, convert it to -EIO */
+   if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
+   ret = -EIO;
 
+   if (ret) {
DRM_DEBUG_DRIVER("INTEL_GUC_SEND: Action 0x%X failed;"
 " ret=%d status=0x%08X response=0x%08X\n",
 action[0], ret, status,
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index a726283..1dafa7a 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -398,7 +398,7 @@ static int ctch_send(struct intel_guc *guc,
err = wait_for_response(desc, fence, status);
if (unlikely(err))
return err;
-   if (*status != INTEL_GUC_STATUS_SUCCESS)
+   if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status))
return -EIO;
return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 72941bd..83143e8 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -560,7 +560,68 @@ struct guc_shared_ctx_data {
struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
 } __packed;
 
-/* This Action will be programmed in C180 - SOFT_SCRATCH_O_REG */
+/**
+ * DOC: MMIO based communication
+ *
+ * The MMIO based communication between Host and GuC uses software scratch
+ * registers, where first register holds data treated as message header,
+ * and other registers are used to hold message payload.
+ *
+ * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8
+ *
+ *  +---+-+-+-+
+ *  |  MMIO[0]  | MMIO[1] |   ...   | MMIO[n] |
+ *  +---+-+-+-+
+ *  | header|  optional payload   |
+ *  +==++=+=+=+
+ *  | 31:28|type| | | |
+ *  +--++ | | |
+ *  | 27:16|data| | | |
+ *  +--++ | | |
+ *  |  15:0|code| | | |
+ *  +--++-+-+-+
+ *
+ * The message header consists of:
+ *
+ * - **type**, indicates message type
+ * - **code**, indicates message code, is specific for **type**
+ * - **data**, indicates message data, optional, depends on **code**
+ *
+ * The following message **types** are supported:
+ *
+ * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
+ *   must be priovided in **code** field. Optional action specific 

[Intel-gfx] [PATCH v5 02/12] drm/i915/guc: Add support for data reporting in GuC responses

[Michal Wajdeczko]

GuC may return additional data in the response message.
Format and meaning of this data is action specific. We will
use this non-negative data as a new success return value.
Currently used actions don't return data that way yet.

v2: fix prohibited space after '~' (Michel)
update commit message (Daniele)
v3: rebase

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_guc.c|  3 +++
 drivers/gpu/drm/i915/intel_guc_ct.c | 14 --
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 28075e6..77bf4e6 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -366,6 +366,9 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
 " ret=%d status=0x%08X response=0x%08X\n",
 action[0], ret, status,
 I915_READ(SOFT_SCRATCH(15)));
+   } else {
+   /* Use data from the GuC response as our return value */
+   ret = INTEL_GUC_MSG_TO_DATA(status);
}
 
intel_uncore_forcewake_put(dev_priv, guc->send_regs.fw_domains);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 1dafa7a..fa52259 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -400,7 +400,9 @@ static int ctch_send(struct intel_guc *guc,
return err;
if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status))
return -EIO;
-   return 0;
+
+   /* Use data from the GuC status as our return value */
+   return INTEL_GUC_MSG_TO_DATA(*status);
 }
 
 /*
@@ -410,18 +412,18 @@ static int intel_guc_send_ct(struct intel_guc *guc, const 
u32 *action, u32 len)
 {
struct intel_guc_ct_channel *ctch = >ct.host_channel;
u32 status = ~0; /* undefined */
-   int err;
+   int ret;
 
mutex_lock(>send_mutex);
 
-   err = ctch_send(guc, ctch, action, len, );
-   if (unlikely(err)) {
+   ret = ctch_send(guc, ctch, action, len, );
+   if (unlikely(ret < 0)) {
DRM_ERROR("CT: send action %#X failed; err=%d status=%#X\n",
- action[0], err, status);
+ action[0], ret, status);
}
 
mutex_unlock(>send_mutex);
-   return err;
+   return ret;
 }
 
 /**
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 08/11] drm/i915/perf: add more debug message on open perf open & configs

[Matthew Auld]

On 26 March 2018 at 10:08, Lionel Landwerlin
 wrote:
> This will make it easier to spot issues related to config
> creation/usage.
>
> Signed-off-by: Lionel Landwerlin 

s/open perf open/perf open/ ?

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

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

[Daniel Vetter]

On Mon, Mar 26, 2018 at 05:28:58PM +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-03-26 16:59:20)
> > 
> > On 26/03/2018 15:59, Chris Wilson wrote:
> > > We've always been blatantly ignoring mmu_notifier.h:
> > > 
> > >   * Invalidation of multiple concurrent ranges may be
> > >   * optionally permitted by the driver. Either way the
> > >   * establishment of sptes is forbidden in the range passed to
> > >   * invalidate_range_begin/end for the whole duration of the
> > >   * invalidate_range_begin/end critical section.
> > > 
> > > by not preventing concurrent calls to gup while an invalidate_range is
> > > being processed. Wrap gup and invalidate_range in a paired rw_semaphore
> > > to allow concurrent lookups, that are then interrupted and disabled
> > > across the invalidate_range. Further refinement can be applied by
> > > tracking the invalidate_range versus individual gup, which should be
> > > done using a common set of helpers for all mmu_notifier subsystems share
> > > the same need. I hear HMM is one such toolbox...
> > > 
> > > For the time being, assume concurrent invalidate and lookup are rare,
> > > but not rare enough to completely ignore.
> > 
> > I think I suggested a few times we should just "ban" the object on first 
> > invalidate and never ever for its lifetime allow it to obtain backing 
> > store again. I just don't remember why we decided not to go with that 
> > approach. :( Thinking about it now I still don't see that this 
> > restriction would be a problem and would simplify things.
> 
> You still have the problem where it is being banned as we are trying to
> instantiate it the first time. Imo, we are re-implementing mmap_sem
> crudely. (Even more so when every mmu notifier must implement the same
> code, and more than one will be called everytime the mm is touched.)

Jerome Glisse is promising to get that fixed and provide neater
primitives. Apparently we can reuse parts of the HMM stuff since that's
built as a helper library (even though the docs don't make it clear).

> And we can get perfectly innocent invalidates, e.g. mprotect.

Also hugepage consolidation, memory migration, swapout and everything else
which really should work.

> > With more locks I am quite fearful what lockdep will say, but lets see...
> 
> Same here.

Cross-release enabled lockdep would be even better, because of our various
worker tricks which do hide lock deps from current lockdep. We should
still have the required fixups hanging around in topic/core-for-CI.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/11] drm/i915/perf: pass stream as argument to oa enable vfunc

[Matthew Auld]

On 26 March 2018 at 10:08, Lionel Landwerlin
 wrote:
> This will allow use to program the hardware based on the stream's
> properties in a later commit.

I couldn't see where we need this? Regardless, operating on the stream
itself makes more sense to me.

>
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
>  drivers/gpu/drm/i915/i915_perf.c | 12 +++-
>  2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f1a38c92bb1f..1169f0a5261f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1515,7 +1515,8 @@ struct i915_oa_ops {
> /**
>  * @oa_enable: Enable periodic sampling
>  */
> -   void (*oa_enable)(struct drm_i915_private *dev_priv);
> +   void (*oa_enable)(struct drm_i915_private *dev_priv,
> + const struct i915_perf_stream *stream);

Ditto. We can drop the dev_priv, and can we maybe also do the same for
oa_disable?

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

Re: [Intel-gfx] [PATCH 01/11] drm/i915/perf: pass stream to enable metric set vfuncs

[Matthew Auld]

On 26 March 2018 at 20:21, Matthew Auld  wrote:
> On 26 March 2018 at 10:08, Lionel Landwerlin
>  wrote:
>> We want to use some of the properties of the perf stream to program
>> the hardware in a later commit.
>>
>> Signed-off-by: Lionel Landwerlin 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
>>  drivers/gpu/drm/i915/i915_perf.c | 10 ++
>>  2 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 800230ba1c3b..f1a38c92bb1f 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1504,7 +1504,7 @@ struct i915_oa_ops {
>>  * disabling EU clock gating as required.
>>  */
>> int (*enable_metric_set)(struct drm_i915_private *dev_priv,
>> -const struct i915_oa_config *oa_config);
>> +const struct i915_perf_stream *stream);
>
> We can just drop dev_priv, since we have stream->dev_priv.
>
> With that:
> Reviewed-by: Matthew Auld 

Actually can we also do the same thing for disable_metric_set, for symmetry?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/11] drm/i915/perf: check the value of PROP_SAMPLE_OA uapi parameter

[Matthew Auld]

On 26 March 2018 at 10:08, Lionel Landwerlin
 wrote:
> We've been a bit loose about this opening parameter. We should only
> add the flag for writing OA reports when the value of this parameter
> is != 0.
>
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 3beb24bc9277..9de935501aad 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -2747,7 +2747,8 @@ static int read_properties_unlocked(struct 
> drm_i915_private *dev_priv,
> props->ctx_handle = value;
> break;
> case DRM_I915_PERF_PROP_SAMPLE_OA:
> -   props->sample_flags |= SAMPLE_OA_REPORT;
> +   if (value)
> +   props->sample_flags |= SAMPLE_OA_REPORT;

Oops.
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/11] drm/i915/perf: pass stream to enable metric set vfuncs

[Matthew Auld]

On 26 March 2018 at 10:08, Lionel Landwerlin
 wrote:
> We want to use some of the properties of the perf stream to program
> the hardware in a later commit.
>
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
>  drivers/gpu/drm/i915/i915_perf.c | 10 ++
>  2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 800230ba1c3b..f1a38c92bb1f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1504,7 +1504,7 @@ struct i915_oa_ops {
>  * disabling EU clock gating as required.
>  */
> int (*enable_metric_set)(struct drm_i915_private *dev_priv,
> -const struct i915_oa_config *oa_config);
> +const struct i915_perf_stream *stream);

We can just drop dev_priv, since we have stream->dev_priv.

With that:
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reword warning for missing cases (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Reword warning for missing cases (rev2)
URL   : https://patchwork.freedesktop.org/series/39821/
State : success

== Summary ==

Series 39821v2 drm/i915: Reword warning for missing cases
https://patchwork.freedesktop.org/api/1.0/series/39821/revisions/2/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:448s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:535s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:301s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:515s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:516s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:520s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:510s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:431s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:319s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:519s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:653s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:544s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:507s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:437s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:402s
Blacklisted hosts:
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:495s

bac611eda28af14ef7e2549932c440885bfe58bb drm-tip: 2018y-03m-26d-15h-45m-06s UTC 
integration manifest
82628817d5f1 drm/i915: Reword warning for missing cases

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/scdc-helper: Convert errors into debug messages

[Ville Syrjälä]

On Sat, Mar 24, 2018 at 08:35:43AM +0530, Sharma, Shashank wrote:
> Reviewed-by: Shashank Sharma 

Thanks. Pushed to drm-misc-next.

> 
> Regards
> Shashank
> On 3/23/2018 11:55 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > Since we may attempt to reconfigure SCDC when the sink has already been
> > disconnected we probably shouldn't scare the user with errors in dmesg
> > that are 100% expected in that case. Just leave it up to the caller
> > whether to print an error message or not, and just output debug
> > messages from the helper itself.
> >
> > Cc: Shashank Sharma 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/drm_scdc_helper.c | 10 +-
> >   1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
> > b/drivers/gpu/drm/drm_scdc_helper.c
> > index 657ea5ab6c3f..870e25f1f788 100644
> > --- a/drivers/gpu/drm/drm_scdc_helper.c
> > +++ b/drivers/gpu/drm/drm_scdc_helper.c
> > @@ -141,7 +141,7 @@ bool drm_scdc_get_scrambling_status(struct i2c_adapter 
> > *adapter)
> >   
> > ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );
> > if (ret < 0) {
> > -   DRM_ERROR("Failed to read scrambling status: %d\n", ret);
> > +   DRM_DEBUG_KMS("Failed to read scrambling status: %d\n", ret);
> > return false;
> > }
> >   
> > @@ -168,7 +168,7 @@ bool drm_scdc_set_scrambling(struct i2c_adapter 
> > *adapter, bool enable)
> >   
> > ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );
> > if (ret < 0) {
> > -   DRM_ERROR("Failed to read TMDS config: %d\n", ret);
> > +   DRM_DEBUG_KMS("Failed to read TMDS config: %d\n", ret);
> > return false;
> > }
> >   
> > @@ -179,7 +179,7 @@ bool drm_scdc_set_scrambling(struct i2c_adapter 
> > *adapter, bool enable)
> >   
> > ret = drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config);
> > if (ret < 0) {
> > -   DRM_ERROR("Failed to enable scrambling: %d\n", ret);
> > +   DRM_DEBUG_KMS("Failed to enable scrambling: %d\n", ret);
> > return false;
> > }
> >   
> > @@ -223,7 +223,7 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct 
> > i2c_adapter *adapter, bool set)
> >   
> > ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );
> > if (ret < 0) {
> > -   DRM_ERROR("Failed to read TMDS config: %d\n", ret);
> > +   DRM_DEBUG_KMS("Failed to read TMDS config: %d\n", ret);
> > return false;
> > }
> >   
> > @@ -234,7 +234,7 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct 
> > i2c_adapter *adapter, bool set)
> >   
> > ret = drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config);
> > if (ret < 0) {
> > -   DRM_ERROR("Failed to set TMDS clock ratio: %d\n", ret);
> > +   DRM_DEBUG_KMS("Failed to set TMDS clock ratio: %d\n", ret);
> > return false;
> > }
> >   

-- 
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.CHECKPATCH: warning for drm/i915: Reword warning for missing cases (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Reword warning for missing cases (rev2)
URL   : https://patchwork.freedesktop.org/series/39821/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
82628817d5f1 drm/i915: Reword warning for missing cases
-:41: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#41: FILE: drivers/gpu/drm/i915/i915_utils.h:43:
+#define MISSING_CASE(x) WARN(1, "Missing case (%s == %ld)\n", \
+__stringify(x), (long)(x))

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

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/scdc-helper: Convert errors into debug messages

[Ville Syrjälä]

On Fri, Mar 23, 2018 at 11:53:47PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/scdc-helper: Convert errors into debug messages
> URL   : https://patchwork.freedesktop.org/series/40591/
> State : failure
> 
> == Summary ==
> 
>  Possible new issues:
> 
> Test kms_chv_cursor_fail:
> Subgroup pipe-c-128x128-top-edge:
> pass   -> FAIL   (shard-apl)

Unrelated cursor crc fail
(kms_chv_cursor_fail:1617) DEBUG: Checking CRCs: [0] [1] CRC mismatch at index 
0: 0x4f96bc87 != 0x70b9fd52

> 
>  Known issues:
> 
> Test kms_cursor_crc:
> Subgroup cursor-256x256-suspend:
> pass   -> INCOMPLETE (shard-hsw) fdo#103375
> Test kms_flip:
> Subgroup 2x-plain-flip-fb-recreate-interruptible:
> fail   -> PASS   (shard-hsw) fdo#100368 +3
> Subgroup modeset-vs-vblank-race-interruptible:
> pass   -> FAIL   (shard-hsw) fdo#103060
> Test kms_sysfs_edid_timing:
> warn   -> PASS   (shard-apl) fdo#100047
> 
> fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
> fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
> 
> shard-apltotal:3484 pass:1820 dwarn:1   dfail:0   fail:8   skip:1655 
> time:12986s
> shard-hswtotal:3450 pass:1753 dwarn:1   dfail:0   fail:3   skip:1691 
> time:11281s
> shard-snbtotal:3484 pass:1363 dwarn:1   dfail:0   fail:3   skip:2117 
> time:7010s
> Blacklisted hosts:
> shard-kbltotal:3484 pass:1945 dwarn:1   dfail:1   fail:9   skip:1528 
> time:9848s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8481/shards.html

-- 
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 series starting with [v4,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev3)

[Patchwork]

== Series Details ==

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

== Summary ==

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:436s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:440s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:385s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:539s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:296s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:515s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:517s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:520s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:505s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:412s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:510s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:430s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:318s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:534s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:411s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:473s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:514s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:659s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:537s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:511s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:498s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:427s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:403s
Blacklisted hosts:
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:484s

bac611eda28af14ef7e2549932c440885bfe58bb drm-tip: 2018y-03m-26d-15h-45m-06s UTC 
integration manifest
4faf11aff784 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
530daf66ff2f drm/i915/cnl: Implement 
WaProgramMgsrForCorrectSliceSpecificMmioReads

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v4,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev3)

[Patchwork]

== Series Details ==

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

== Summary ==

$ dim checkpatch origin/drm-tip
530daf66ff2f drm/i915/cnl: Implement 
WaProgramMgsrForCorrectSliceSpecificMmioReads
4faf11aff784 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
-:71: CHECK:SPACING: spaces preferred around that '>>' (ctx:VxV)
#71: FILE: drivers/gpu/drm/i915/intel_engine_cs.c:829:
+  | 
sseu->subslice_mask[slice]>>GEN10_L3BANK_PAIR_COUNT)
   ^

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

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

Re: [Intel-gfx] [PATCH 11/11] drm/i915: Allow user control over preempt timeout on the important context

[Tvrtko Ursulin]

On 26/03/2018 12:50, Chris Wilson wrote:

EGL_NV_realtime_priority?

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem_context.c | 22 ++
  drivers/gpu/drm/i915/i915_gem_context.h | 13 +
  drivers/gpu/drm/i915/i915_request.c |  8 ++--
  drivers/gpu/drm/i915/intel_lrc.c|  2 +-
  include/uapi/drm/i915_drm.h | 12 
  5 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5cfac0255758..dfb0a2b698c3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -749,6 +749,15 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
case I915_CONTEXT_PARAM_PRIORITY:
args->value = ctx->priority;
break;
+   case I915_CONTEXT_PARAM_PREEMPT_TIMEOUT:
+   if (!(to_i915(dev)->caps.scheduler & 
I915_SCHEDULER_CAP_PREEMPTION))
+   ret = -ENODEV;
+   else if (args->size)
+   ret = -EINVAL;
+   else
+   args->value = ctx->preempt_timeout;
+   break;
+
default:
ret = -EINVAL;
break;
@@ -824,6 +833,19 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
}
break;
  
+	case I915_CONTEXT_PARAM_PREEMPT_TIMEOUT:

+   if (args->size)
+   ret = -EINVAL;
+   else if (args->value >= NSEC_PER_SEC)
+   ret = -EINVAL;
+   else if (!(to_i915(dev)->caps.scheduler & 
I915_SCHEDULER_CAP_PREEMPTION))
+   ret = -ENODEV;
+   else if (args->value && !capable(CAP_SYS_ADMIN))
+   ret = -EPERM;
+   else
+   ctx->preempt_timeout = args->value;
+   break;
+
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 7854262ddfd9..74d4cadd729e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -150,6 +150,19 @@ struct i915_gem_context {
 */
int priority;
  
+	/**

+* @preempt_timeout: QoS guarantee for the high priority context
+*
+* Some clients need a guarantee that they will start executing
+* within a certain window, even at the expense of others. This entails
+* that if a preemption request is not honoured by the active context
+* within the timeout, we will reset the GPU to evict the hog and
+* run the high priority context instead.
+*
+* Timeout is stored in nanoseconds; exclusive max of 1s.


Why did you think we would want to limit it to 1s?


+*/
+   u32 preempt_timeout;
+
/** ggtt_offset_bias: placement restriction for context objects */
u32 ggtt_offset_bias;
  
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c

index 9d8dcebd9649..2cd4ea75d127 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1101,8 +1101,12 @@ void __i915_request_add(struct i915_request *request, 
bool flush_caches)
 * run at the earliest possible convenience.
 */
rcu_read_lock();
-   if (engine->schedule)
-   engine->schedule(request, request->ctx->priority, 0);
+   if (engine->schedule) {
+   unsigned int timeout = request->ctx->preempt_timeout;
+   int priority = request->ctx->priority;
+
+   engine->schedule(request, priority, timeout);
+   }
rcu_read_unlock();
  
  	local_bh_disable();

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e266657851e1..e782a621b40b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1148,7 +1148,7 @@ static void execlists_submit_request(struct i915_request 
*request)
spin_lock_irqsave(>timeline->lock, flags);
  
  	queue_request(engine, >priotree, rq_prio(request));

-   submit_queue(engine, rq_prio(request), 0);
+   submit_queue(engine, rq_prio(request), request->ctx->preempt_timeout);
  
  	GEM_BUG_ON(!engine->execlists.first);

GEM_BUG_ON(list_empty(>priotree.link));
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 7f5634ce8e88..6f10bbe90304 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1456,6 +1456,18 @@ struct drm_i915_gem_context_param {
  #define   I915_CONTEXT_MAX_USER_PRIORITY  1023 /* inclusive */
  #define   I915_CONTEXT_DEFAULT_PRIORITY   0
  #define   I915_CONTEXT_MIN_USER_PRIORITY  -1023 /* inclusive */
+
+/*
+ * 

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

[Tvrtko Ursulin]

On 26/03/2018 17:12, Yunwei Zhang wrote:

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

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

v2:
  - use fls instead of find_last_bit (Chris)
  - use is_power_of_2() instead of counting bit set (Chris)
v3:
  - rebase on latest tip
v4:
  - Added referecens (Mika)

References: HSDES#1405586840

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

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1bca695f..4f2f5e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2691,6 +2691,10 @@ enum i915_power_well_id {
  #define   GEN10_F2_SS_DIS_SHIFT   18
  #define   GEN10_F2_SS_DIS_MASK(0xf << GEN10_F2_SS_DIS_SHIFT)
  
+#define	GEN10_MIRROR_FUSE3		_MMIO(0x9118)

+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK   0x0F
+
  #define GEN8_EU_DISABLE0  _MMIO(0x9134)
  #define   GEN8_EU_DIS0_S0_MASK0xff
  #define   GEN8_EU_DIS0_S1_SHIFT   24
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index cc19e0a..3eb763c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -811,7 +811,25 @@ static u32 calculate_mcr(u32 mcr, struct drm_i915_private 
*dev_priv)
  static void wa_init_mcr(struct drm_i915_private *dev_priv)
  {
u32 mcr;
+   u32 fuse3;
+   const struct sseu_dev_info *sseu = &(INTEL_SSEU(dev_priv));
+   u32 slice;


fuse3 and slice can be moved into the is_power_of_2 block below.

  
+	/* If more than one slice are enabled, L3Banks should be all enabled */

+   if (is_power_of_2(sseu->slice_mask)) {
+   /*
+* WaProgramMgsrForL3BankSpecificMmioReads:
+* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+* enabled subslice, no need to redirect MCR packet
+*/
+   slice = fls(sseu->slice_mask);
+   fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+   if (WARN_ON(!((fuse3 & GEN10_L3BANK_MASK)
+  & ((sseu->subslice_mask[slice]
+  | 
sseu->subslice_mask[slice]>>GEN10_L3BANK_PAIR_COUNT)


Spaces around operators to satisfy checkpatch.


+  & GEN10_L3BANK_MASK


Whole conditional is a bit hard to read (maybe it is just me!) so maybe 
store sseu->subslice_mask[slice] to a local? Not sure if that would make 
it better.



+   DRM_WARN("Production silicon should have matched L3Bank and 
subslice enabled\n");


Aren't both WARN_ON and DRM_WARN an overkill? One should be enough I hope.


+   }
mcr = I915_READ(GEN8_MCR_SELECTOR);
mcr = calculate_mcr(mcr, dev_priv);
I915_WRITE(GEN8_MCR_SELECTOR, mcr);



Regards,

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

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

[Tvrtko Ursulin]

On 26/03/2018 17:12, Yunwei Zhang wrote:

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

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

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

Reference: HSD#1405586840 BSID#0575

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

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 800230b..2db2a04 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2297,6 +2297,7 @@ intel_info(const struct drm_i915_private *dev_priv)
  
  #define INTEL_GEN(dev_priv)	((dev_priv)->info.gen)

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


If we add this someone gets the job of converting existing users?

  
  #define REVID_FOREVER		0xff

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


dev_priv first would be more typical function argument order.


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

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


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



mcr &= ~mcr_slice_subslice_mask;
mcr |= mcr_slice_subslice_select;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
  
  	ret = I915_READ_FW(reg);
  
-	mcr &= ~mcr_slice_subslice_mask;

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


Does it make sense to move the conditional and comment to calculate_mcr 
- so here only a single call to it remains?



+
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
  
  	intel_uncore_forcewake_put__locked(dev_priv, fw_domains);

@@ -1307,6 +1339,9 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
struct drm_i915_private *dev_priv = engine->i915;
int ret;
  
+	/* WaProgramMgsrForCorrectSliceSpecificMmioReads: cnl */

+   wa_init_mcr(dev_priv);
+
/* WaDisableI2mCycleOnWRPort:cnl (pre-prod) */
   

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

[Patchwork]

== Series Details ==

Series: drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore
URL   : https://patchwork.freedesktop.org/series/40676/
State : failure

== Summary ==

 Possible new issues:

Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-WARN (shard-snb)
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> DMESG-WARN (shard-hsw)
Test gem_userptr_blits:
Subgroup coherency-unsync:
pass   -> INCOMPLETE (shard-hsw)
pass   -> INCOMPLETE (shard-snb)
Subgroup dmabuf-sync:
pass   -> DMESG-WARN (shard-hsw)
Subgroup dmabuf-unsync:
pass   -> DMESG-WARN (shard-snb)
Subgroup forbidden-operations:
pass   -> DMESG-FAIL (shard-apl)
pass   -> DMESG-FAIL (shard-hsw)
pass   -> DMESG-FAIL (shard-snb)
Subgroup invalid-gtt-mapping:
pass   -> INCOMPLETE (shard-apl)
pass   -> INCOMPLETE (shard-hsw)
pass   -> INCOMPLETE (shard-snb)
Subgroup invalid-null-pointer:
pass   -> INCOMPLETE (shard-apl)
pass   -> INCOMPLETE (shard-hsw)
pass   -> INCOMPLETE (shard-snb)
Subgroup map-fixed-invalidate-busy:
pass   -> DMESG-WARN (shard-hsw)
pass   -> DMESG-WARN (shard-snb)
Subgroup map-fixed-invalidate-busy-gup:
pass   -> DMESG-WARN (shard-apl)
pass   -> DMESG-WARN (shard-hsw)
pass   -> DMESG-WARN (shard-snb)
Subgroup map-fixed-invalidate-gup:
pass   -> DMESG-WARN (shard-snb)
Subgroup map-fixed-invalidate-overlap-busy:
pass   -> DMESG-WARN (shard-apl)
Subgroup map-fixed-invalidate-overlap-gup:
pass   -> DMESG-WARN (shard-apl)
pass   -> DMESG-WARN (shard-hsw)
pass   -> DMESG-WARN (shard-snb)
Subgroup process-exit-busy:
pass   -> DMESG-WARN (shard-hsw)
pass   -> DMESG-WARN (shard-snb)
Subgroup process-exit-gtt-busy:
pass   -> DMESG-WARN (shard-hsw)
pass   -> DMESG-WARN (shard-snb)
Subgroup sync-unmap-cycles:
pass   -> DMESG-WARN (shard-apl)
Subgroup unsync-unmap:
pass   -> INCOMPLETE (shard-apl)
pass   -> INCOMPLETE (shard-hsw)
pass   -> INCOMPLETE (shard-snb)
Subgroup unsync-unmap-after-close:
pass   -> INCOMPLETE (shard-apl)
pass   -> INCOMPLETE (shard-hsw)
pass   -> INCOMPLETE (shard-snb)
Subgroup unsync-unmap-cycles:
pass   -> INCOMPLETE (shard-apl)
pass   -> INCOMPLETE (shard-hsw)
pass   -> INCOMPLETE (shard-snb)
Test kms_addfb_basic:
Subgroup unused-handle:
pass   -> INCOMPLETE (shard-apl)

 Known issues:

Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060 +2
Subgroup 2x-flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup 2x-flip-vs-wf_vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-snb) fdo#103925
Subgroup sprite-rotation-270:
pass   -> FAIL   (shard-apl) fdo#103356

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

shard-apltotal:3262 pass:1693 dwarn:5   dfail:1   fail:7   skip:1549 
time:10290s
shard-hswtotal:3235 pass:1638 dwarn:8   dfail:1   fail:2   skip:1579 
time:9745s
shard-snbtotal:3235 pass:1254 dwarn:9   dfail:1   fail:3   skip:1962 
time:5613s
Blacklisted hosts:
shard-kbltotal:3274 pass:1806 dwarn:13  dfail:2   fail:9   skip:1438 
time:7933s

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 08/13] drm/i915/guc: Implement response handling in send_ct()

[Michal Wajdeczko]

On Mon, 26 Mar 2018 17:35:00 +0200, Jani Nikula  
 wrote:



On Mon, 26 Mar 2018, Michał Winiarski  wrote:

On Fri, Mar 23, 2018 at 02:47:23PM +, Michal Wajdeczko wrote:

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

v2: fix timeout and checkpatch warnings (Michal)

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_guc_ct.c | 137  


 drivers/gpu/drm/i915/intel_guc_ct.h |   5 ++
 2 files changed, 128 insertions(+), 14 deletions(-)



[SNIP]


@@ -418,13 +499,15 @@ static int ctch_send(struct intel_guc *guc,
 static int intel_guc_send_ct(struct intel_guc *guc, const u32  
*action, u32 len,

 u32 *response_buf, u32 response_buf_size)
 {
-   struct intel_guc_ct_channel *ctch = >ct.host_channel;
+   struct intel_guc_ct *ct = >ct;
+   struct intel_guc_ct_channel *ctch = >host_channel;
u32 status = ~0; /* undefined */
int ret;

mutex_lock(>send_mutex);

-   ret = ctch_send(guc, ctch, action, len, );
+	ret = ctch_send(ct, ctch, action, len, response_buf,  
response_buf_size,

+   );
if (unlikely(ret < 0)) {
DRM_ERROR("CT: send action %#X failed; err=%d status=%#X\n",
  action[0], ret, status);
@@ -503,8 +586,13 @@ static int ctb_read(struct intel_guc_ct_buffer  
*ctb, u32 *data)

 static int ct_handle_response(struct intel_guc_ct *ct, const u32 *msg)
 {
u32 header = msg[0];
+   u32 fence = msg[1];
u32 status = msg[2];
u32 len = ct_header_get_len(header) + 1; /* total len with header */
+   u32 payload_len = len - 3; /* len<3 is treated as protocol error */


Magic numbers, please ether define 3 as min payload length or hide this  
behind

macro.


And check len >= 3 before substracting 3.



This was speculative, same as reading 'fence' and 'status', hence comment
about protocol error, but also note that all of them were used after proper
check for unlikely len<3 condition later in the function.

I will reorder existing code to avoid such tricks

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

Re: [Intel-gfx] [PATCH v4 08/13] drm/i915/guc: Implement response handling in send_ct()

[Michal Wajdeczko]

On Mon, 26 Mar 2018 17:29:32 +0200, Michał Winiarski  
 wrote:



On Fri, Mar 23, 2018 at 02:47:23PM +, Michal Wajdeczko wrote:

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

v2: fix timeout and checkpatch warnings (Michal)

Signed-off-by: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Michel Thierry 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_guc_ct.c | 137  


 drivers/gpu/drm/i915/intel_guc_ct.h |   5 ++
 2 files changed, 128 insertions(+), 14 deletions(-)



[SNIP]


@@ -418,13 +499,15 @@ static int ctch_send(struct intel_guc *guc,
 static int intel_guc_send_ct(struct intel_guc *guc, const u32 *action,  
u32 len,

 u32 *response_buf, u32 response_buf_size)
 {
-   struct intel_guc_ct_channel *ctch = >ct.host_channel;
+   struct intel_guc_ct *ct = >ct;
+   struct intel_guc_ct_channel *ctch = >host_channel;
u32 status = ~0; /* undefined */
int ret;

mutex_lock(>send_mutex);

-   ret = ctch_send(guc, ctch, action, len, );
+	ret = ctch_send(ct, ctch, action, len, response_buf,  
response_buf_size,

+   );
if (unlikely(ret < 0)) {
DRM_ERROR("CT: send action %#X failed; err=%d status=%#X\n",
  action[0], ret, status);
@@ -503,8 +586,13 @@ static int ctb_read(struct intel_guc_ct_buffer  
*ctb, u32 *data)

 static int ct_handle_response(struct intel_guc_ct *ct, const u32 *msg)
 {
u32 header = msg[0];
+   u32 fence = msg[1];
u32 status = msg[2];
u32 len = ct_header_get_len(header) + 1; /* total len with header */
+   u32 payload_len = len - 3; /* len<3 is treated as protocol error */


Magic numbers, please ether define 3 as min payload length or hide this  
behind

macro.


Well, it looks that detailed CTB documentation can't wait any more...
(simplified doc was already there:

/* Response message shall at least include header, fence and status */

I'll try to include more docs in next series spin to make these numbers  
more

clear for everyone




+   struct ct_request *req;
+   bool found = false;
+   unsigned long flags;

GEM_BUG_ON(!ct_header_is_response(header));

@@ -518,8 +606,29 @@ static int ct_handle_response(struct intel_guc_ct  
*ct, const u32 *msg)

DRM_ERROR("CT: corrupted response %*phn\n", 4*len, msg);
return -EPROTO;
}
+   spin_lock_irqsave(>lock, flags);


Isn't this called from the irq? We can use plain spin_lock here.


yes, will update, thanks




+   list_for_each_entry(req, >pending_requests, link) {
+   if (req->fence != fence) {
+   DRM_DEBUG_DRIVER("CT: request %u awaits response\n",
+req->fence);
+   continue;


Is this expected?


rather not, tempting to mark that with 'unlikely'


In other words - do we expect out of order responses?


not today, since we're using send_mutex to serialize all requests
(serialization was required for MMIO based comm, but not for CT)


Can we extract this into a helper (find request)?


will try, but can't promise

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

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-26 16:59:20)
> 
> On 26/03/2018 15:59, Chris Wilson wrote:
> > We've always been blatantly ignoring mmu_notifier.h:
> > 
> >   * Invalidation of multiple concurrent ranges may be
> >   * optionally permitted by the driver. Either way the
> >   * establishment of sptes is forbidden in the range passed to
> >   * invalidate_range_begin/end for the whole duration of the
> >   * invalidate_range_begin/end critical section.
> > 
> > by not preventing concurrent calls to gup while an invalidate_range is
> > being processed. Wrap gup and invalidate_range in a paired rw_semaphore
> > to allow concurrent lookups, that are then interrupted and disabled
> > across the invalidate_range. Further refinement can be applied by
> > tracking the invalidate_range versus individual gup, which should be
> > done using a common set of helpers for all mmu_notifier subsystems share
> > the same need. I hear HMM is one such toolbox...
> > 
> > For the time being, assume concurrent invalidate and lookup are rare,
> > but not rare enough to completely ignore.
> 
> I think I suggested a few times we should just "ban" the object on first 
> invalidate and never ever for its lifetime allow it to obtain backing 
> store again. I just don't remember why we decided not to go with that 
> approach. :( Thinking about it now I still don't see that this 
> restriction would be a problem and would simplify things.

You still have the problem where it is being banned as we are trying to
instantiate it the first time. Imo, we are re-implementing mmap_sem
crudely. (Even more so when every mmu notifier must implement the same
code, and more than one will be called everytime the mm is touched.)

And we can get perfectly innocent invalidates, e.g. mprotect.
 
> With more locks I am quite fearful what lockdep will say, but lets see...

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

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

[Yunwei Zhang]

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

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

v2:
 - use fls instead of find_last_bit (Chris)
 - use is_power_of_2() instead of counting bit set (Chris)
v3:
 - rebase on latest tip
v4:
 - Added referecens (Mika)

References: HSDES#1405586840

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

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

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

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

[Yunwei Zhang]

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

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

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

Reference: HSD#1405586840 BSID#0575

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

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

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

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/perf: enable perf support on ICL (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/perf: enable perf support on ICL (rev2)
URL   : https://patchwork.freedesktop.org/series/39689/
State : warning

== Summary ==

 Possible new issues:

Test kms_cursor_legacy:
Subgroup short-flip-before-cursor-toggle:
pass   -> SKIP   (shard-snb)

 Known issues:

Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup 2x-modeset-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060 +1
Subgroup 2x-plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-fullscreen:
pass   -> SKIP   (shard-snb) fdo#103167 +1
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
pass   -> DMESG-WARN (shard-hsw) fdo#103540
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-snb) fdo#103925
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#99912
Test kms_vblank:
Subgroup pipe-b-accuracy-idle:
pass   -> FAIL   (shard-hsw) fdo#102583

fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583

shard-apltotal:3495 pass:1831 dwarn:1   dfail:0   fail:7   skip:1655 
time:12871s
shard-hswtotal:3495 pass:1778 dwarn:2   dfail:0   fail:5   skip:1709 
time:11588s
shard-snbtotal:3495 pass:1371 dwarn:1   dfail:0   fail:3   skip:2120 
time:6932s
Blacklisted hosts:
shard-kbltotal:3495 pass:1916 dwarn:36  dfail:1   fail:9   skip:1532 
time:9613s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

[Tvrtko Ursulin]

On 26/03/2018 15:59, Chris Wilson wrote:

We've always been blatantly ignoring mmu_notifier.h:

  * Invalidation of multiple concurrent ranges may be
  * optionally permitted by the driver. Either way the
  * establishment of sptes is forbidden in the range passed to
  * invalidate_range_begin/end for the whole duration of the
  * invalidate_range_begin/end critical section.

by not preventing concurrent calls to gup while an invalidate_range is
being processed. Wrap gup and invalidate_range in a paired rw_semaphore
to allow concurrent lookups, that are then interrupted and disabled
across the invalidate_range. Further refinement can be applied by
tracking the invalidate_range versus individual gup, which should be
done using a common set of helpers for all mmu_notifier subsystems share
the same need. I hear HMM is one such toolbox...

For the time being, assume concurrent invalidate and lookup are rare,
but not rare enough to completely ignore.


I think I suggested a few times we should just "ban" the object on first 
invalidate and never ever for its lifetime allow it to obtain backing 
store again. I just don't remember why we decided not to go with that 
approach. :( Thinking about it now I still don't see that this 
restriction would be a problem and would simplify things.


With more locks I am quite fearful what lockdep will say, but lets see...



Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
---
  drivers/gpu/drm/i915/i915_gem_userptr.c | 29 -
  1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index d596a8302ca3..938107dffd37 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -47,6 +47,7 @@ struct i915_mm_struct {
  
  struct i915_mmu_notifier {

spinlock_t lock;
+   struct rw_semaphore sem;
struct hlist_node node;
struct mmu_notifier mn;
struct rb_root_cached objects;
@@ -123,6 +124,8 @@ static void 
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
struct interval_tree_node *it;
LIST_HEAD(cancelled);
  
+	down_write(>sem);

+
if (RB_EMPTY_ROOT(>objects.rb_root))
return;
  
@@ -156,8 +159,20 @@ static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,

flush_workqueue(mn->wq);
  }
  
+static void i915_gem_userptr_mn_invalidate_range_end(struct mmu_notifier *_mn,

+struct mm_struct *mm,
+unsigned long start,
+unsigned long end)
+{
+   struct i915_mmu_notifier *mn =
+   container_of(_mn, struct i915_mmu_notifier, mn);
+
+   up_write(>sem);
+}
+
  static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
.invalidate_range_start = i915_gem_userptr_mn_invalidate_range_start,
+   .invalidate_range_end = i915_gem_userptr_mn_invalidate_range_end,
  };
  
  static struct i915_mmu_notifier *

@@ -170,6 +185,7 @@ i915_mmu_notifier_create(struct mm_struct *mm)
return ERR_PTR(-ENOMEM);
  
  	spin_lock_init(>lock);

+   init_rwsem(>sem);
mn->mn.ops = _gem_userptr_notifier;
mn->objects = RB_ROOT_CACHED;
mn->wq = alloc_workqueue("i915-userptr-release",
@@ -504,12 +520,15 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
  
  	pvec = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);

if (pvec != NULL) {
+   struct i915_mmu_notifier *mn = obj->userptr.mm->mn;
struct mm_struct *mm = obj->userptr.mm->mm;
unsigned int flags = 0;
  
  		if (!obj->userptr.read_only)

flags |= FOLL_WRITE;
  
+		down_read(>sem);

+
ret = -EFAULT;
if (mmget_not_zero(mm)) {
down_read(>mmap_sem);
@@ -528,6 +547,8 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
up_read(>mmap_sem);
mmput(mm);
}
+
+   up_read(>sem);
}
  
  	mutex_lock(>mm.lock);

@@ -636,15 +657,21 @@ static int i915_gem_userptr_get_pages(struct 
drm_i915_gem_object *obj)
pinned = 0;
  
  	if (mm == current->mm) {

+   struct i915_mmu_notifier *mn = obj->userptr.mm->mn;
+
pvec = kvmalloc_array(num_pages, sizeof(struct page *),
  GFP_KERNEL |
  __GFP_NORETRY |
  __GFP_NOWARN);
-   if (pvec) /* defer to worker if malloc fails */
+
+   /* defer to worker if malloc fails 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5)

[Patchwork]

== Series Details ==

Series: drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5)
URL   : https://patchwork.freedesktop.org/series/40478/
State : success

== Summary ==

 Known issues:

Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race:
fail   -> PASS   (shard-hsw) fdo#103060 +1
Subgroup 2x-flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup plain-flip-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-snb) fdo#103925
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#99912
Test kms_vblank:
Subgroup pipe-a-accuracy-idle:
pass   -> FAIL   (shard-hsw) fdo#102583

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

shard-apltotal:3386 pass:1767 dwarn:1   dfail:0   fail:6   skip:1611 
time:12568s
shard-hswtotal:3484 pass:1771 dwarn:1   dfail:0   fail:4   skip:1707 
time:11784s
shard-snbtotal:3484 pass:1363 dwarn:1   dfail:0   fail:3   skip:2117 
time:7030s

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 08/13] drm/i915/guc: Implement response handling in send_ct()

[Jani Nikula]

On Mon, 26 Mar 2018, Michał Winiarski  wrote:
> On Fri, Mar 23, 2018 at 02:47:23PM +, Michal Wajdeczko wrote:
>> Instead of returning small data in response status dword,
>> GuC may append longer data as response message payload.
>> If caller provides response buffer, we will copy received
>> data and use number of received data dwords as new success
>> return value. We will WARN if response from GuC does not
>> match caller expectation.
>> 
>> v2: fix timeout and checkpatch warnings (Michal)
>> 
>> Signed-off-by: Michal Wajdeczko 
>> Cc: Oscar Mateo 
>> Cc: Michel Thierry 
>> Cc: Daniele Ceraolo Spurio 
>> ---
>>  drivers/gpu/drm/i915/intel_guc_ct.c | 137 
>> 
>>  drivers/gpu/drm/i915/intel_guc_ct.h |   5 ++
>>  2 files changed, 128 insertions(+), 14 deletions(-)
>> 
>
> [SNIP]
>
>> @@ -418,13 +499,15 @@ static int ctch_send(struct intel_guc *guc,
>>  static int intel_guc_send_ct(struct intel_guc *guc, const u32 *action, u32 
>> len,
>>   u32 *response_buf, u32 response_buf_size)
>>  {
>> -struct intel_guc_ct_channel *ctch = >ct.host_channel;
>> +struct intel_guc_ct *ct = >ct;
>> +struct intel_guc_ct_channel *ctch = >host_channel;
>>  u32 status = ~0; /* undefined */
>>  int ret;
>>  
>>  mutex_lock(>send_mutex);
>>  
>> -ret = ctch_send(guc, ctch, action, len, );
>> +ret = ctch_send(ct, ctch, action, len, response_buf, response_buf_size,
>> +);
>>  if (unlikely(ret < 0)) {
>>  DRM_ERROR("CT: send action %#X failed; err=%d status=%#X\n",
>>action[0], ret, status);
>> @@ -503,8 +586,13 @@ static int ctb_read(struct intel_guc_ct_buffer *ctb, 
>> u32 *data)
>>  static int ct_handle_response(struct intel_guc_ct *ct, const u32 *msg)
>>  {
>>  u32 header = msg[0];
>> +u32 fence = msg[1];
>>  u32 status = msg[2];
>>  u32 len = ct_header_get_len(header) + 1; /* total len with header */
>> +u32 payload_len = len - 3; /* len<3 is treated as protocol error */
>
> Magic numbers, please ether define 3 as min payload length or hide this behind
> macro.

And check len >= 3 before substracting 3.

BR,
Jani.


>
>> +struct ct_request *req;
>> +bool found = false;
>> +unsigned long flags;
>>  
>>  GEM_BUG_ON(!ct_header_is_response(header));
>>  
>> @@ -518,8 +606,29 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
>> const u32 *msg)
>>  DRM_ERROR("CT: corrupted response %*phn\n", 4*len, msg);
>>  return -EPROTO;
>>  }
>> +spin_lock_irqsave(>lock, flags);
>
> Isn't this called from the irq? We can use plain spin_lock here.
>
>> +list_for_each_entry(req, >pending_requests, link) {
>> +if (req->fence != fence) {
>> +DRM_DEBUG_DRIVER("CT: request %u awaits response\n",
>> + req->fence);
>> +continue;
>
> Is this expected?
> In other words - do we expect out of order responses?
> Can we extract this into a helper (find request)?
>
> -Michał
>
>> +}
>> +if (unlikely(payload_len > req->response_len)) {
>> +DRM_ERROR("CT: response %u too long %*phn\n",
>> +  req->fence, 4*len, msg);
>> +payload_len = 0;
>> +}
>> +if (payload_len)
>> +memcpy(req->response_buf, msg + 3, 4*payload_len);
>> +req->response_len = payload_len;
>> +WRITE_ONCE(req->status, status);
>> +found = true;
>> +break;
>> +}
>> +spin_unlock_irqrestore(>lock, flags);
>>  
>> -/* XXX */
>> +if (!found)
>> +DRM_ERROR("CT: unsolicited response %*phn\n", 4*len, msg);
>>  return 0;
>>  }
>>  
>> diff --git a/drivers/gpu/drm/i915/intel_guc_ct.h 
>> b/drivers/gpu/drm/i915/intel_guc_ct.h
>> index 595c8ad..905566b 100644
>> --- a/drivers/gpu/drm/i915/intel_guc_ct.h
>> +++ b/drivers/gpu/drm/i915/intel_guc_ct.h
>> @@ -71,10 +71,15 @@ struct intel_guc_ct_channel {
>>  /** Holds all command transport channels.
>>   *
>>   * @host_channel: main channel used by the host
>> + * @lock: spin lock for pending requests list
>> + * @pending_requests: list of pending requests
>>   */
>>  struct intel_guc_ct {
>>  struct intel_guc_ct_channel host_channel;
>>  /* other channels are tbd */
>> +
>> +spinlock_t lock;
>> +struct list_head pending_requests;
>>  };
>>  
>>  void intel_guc_ct_init_early(struct intel_guc_ct *ct);
>> -- 
>> 1.9.1
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

[Patchwork]

== Series Details ==

Series: drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore
URL   : https://patchwork.freedesktop.org/series/40676/
State : success

== Summary ==

Series 40676v1 drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore
https://patchwork.freedesktop.org/api/1.0/series/40676/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927
incomplete -> PASS   (fi-hsw-4770) fdo#104944

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:443s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:535s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:296s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:515s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:516s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:528s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:509s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:513s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:318s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:427s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:433s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:474s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:519s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:651s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:444s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:510s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:431s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:442s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:591s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:407s
Blacklisted hosts:
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-cnl-psr   total:224  pass:198  dwarn:0   dfail:0   fail:1   skip:24 
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:491s

94f5d9189e61055e246c31106b3810dc17ddee9c drm-tip: 2018y-03m-23d-23h-41m-40s UTC 
integration manifest
42235f2436b0 drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 08/13] drm/i915/guc: Implement response handling in send_ct()

[Michał Winiarski]

On Fri, Mar 23, 2018 at 02:47:23PM +, Michal Wajdeczko wrote:
> Instead of returning small data in response status dword,
> GuC may append longer data as response message payload.
> If caller provides response buffer, we will copy received
> data and use number of received data dwords as new success
> return value. We will WARN if response from GuC does not
> match caller expectation.
> 
> v2: fix timeout and checkpatch warnings (Michal)
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Oscar Mateo 
> Cc: Michel Thierry 
> Cc: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/intel_guc_ct.c | 137 
> 
>  drivers/gpu/drm/i915/intel_guc_ct.h |   5 ++
>  2 files changed, 128 insertions(+), 14 deletions(-)
> 

[SNIP]

> @@ -418,13 +499,15 @@ static int ctch_send(struct intel_guc *guc,
>  static int intel_guc_send_ct(struct intel_guc *guc, const u32 *action, u32 
> len,
>u32 *response_buf, u32 response_buf_size)
>  {
> - struct intel_guc_ct_channel *ctch = >ct.host_channel;
> + struct intel_guc_ct *ct = >ct;
> + struct intel_guc_ct_channel *ctch = >host_channel;
>   u32 status = ~0; /* undefined */
>   int ret;
>  
>   mutex_lock(>send_mutex);
>  
> - ret = ctch_send(guc, ctch, action, len, );
> + ret = ctch_send(ct, ctch, action, len, response_buf, response_buf_size,
> + );
>   if (unlikely(ret < 0)) {
>   DRM_ERROR("CT: send action %#X failed; err=%d status=%#X\n",
> action[0], ret, status);
> @@ -503,8 +586,13 @@ static int ctb_read(struct intel_guc_ct_buffer *ctb, u32 
> *data)
>  static int ct_handle_response(struct intel_guc_ct *ct, const u32 *msg)
>  {
>   u32 header = msg[0];
> + u32 fence = msg[1];
>   u32 status = msg[2];
>   u32 len = ct_header_get_len(header) + 1; /* total len with header */
> + u32 payload_len = len - 3; /* len<3 is treated as protocol error */

Magic numbers, please ether define 3 as min payload length or hide this behind
macro.

> + struct ct_request *req;
> + bool found = false;
> + unsigned long flags;
>  
>   GEM_BUG_ON(!ct_header_is_response(header));
>  
> @@ -518,8 +606,29 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
> const u32 *msg)
>   DRM_ERROR("CT: corrupted response %*phn\n", 4*len, msg);
>   return -EPROTO;
>   }
> + spin_lock_irqsave(>lock, flags);

Isn't this called from the irq? We can use plain spin_lock here.

> + list_for_each_entry(req, >pending_requests, link) {
> + if (req->fence != fence) {
> + DRM_DEBUG_DRIVER("CT: request %u awaits response\n",
> +  req->fence);
> + continue;

Is this expected?
In other words - do we expect out of order responses?
Can we extract this into a helper (find request)?

-Michał

> + }
> + if (unlikely(payload_len > req->response_len)) {
> + DRM_ERROR("CT: response %u too long %*phn\n",
> +   req->fence, 4*len, msg);
> + payload_len = 0;
> + }
> + if (payload_len)
> + memcpy(req->response_buf, msg + 3, 4*payload_len);
> + req->response_len = payload_len;
> + WRITE_ONCE(req->status, status);
> + found = true;
> + break;
> + }
> + spin_unlock_irqrestore(>lock, flags);
>  
> - /* XXX */
> + if (!found)
> + DRM_ERROR("CT: unsolicited response %*phn\n", 4*len, msg);
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_guc_ct.h 
> b/drivers/gpu/drm/i915/intel_guc_ct.h
> index 595c8ad..905566b 100644
> --- a/drivers/gpu/drm/i915/intel_guc_ct.h
> +++ b/drivers/gpu/drm/i915/intel_guc_ct.h
> @@ -71,10 +71,15 @@ struct intel_guc_ct_channel {
>  /** Holds all command transport channels.
>   *
>   * @host_channel: main channel used by the host
> + * @lock: spin lock for pending requests list
> + * @pending_requests: list of pending requests
>   */
>  struct intel_guc_ct {
>   struct intel_guc_ct_channel host_channel;
>   /* other channels are tbd */
> +
> + spinlock_t lock;
> + struct list_head pending_requests;
>  };
>  
>  void intel_guc_ct_init_early(struct intel_guc_ct *ct);
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

[Chris Wilson]

We've always been blatantly ignoring mmu_notifier.h:

 * Invalidation of multiple concurrent ranges may be
 * optionally permitted by the driver. Either way the
 * establishment of sptes is forbidden in the range passed to
 * invalidate_range_begin/end for the whole duration of the
 * invalidate_range_begin/end critical section.

by not preventing concurrent calls to gup while an invalidate_range is
being processed. Wrap gup and invalidate_range in a paired rw_semaphore
to allow concurrent lookups, that are then interrupted and disabled
across the invalidate_range. Further refinement can be applied by
tracking the invalidate_range versus individual gup, which should be
done using a common set of helpers for all mmu_notifier subsystems share
the same need. I hear HMM is one such toolbox...

For the time being, assume concurrent invalidate and lookup are rare,
but not rare enough to completely ignore.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index d596a8302ca3..938107dffd37 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -47,6 +47,7 @@ struct i915_mm_struct {
 
 struct i915_mmu_notifier {
spinlock_t lock;
+   struct rw_semaphore sem;
struct hlist_node node;
struct mmu_notifier mn;
struct rb_root_cached objects;
@@ -123,6 +124,8 @@ static void 
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
struct interval_tree_node *it;
LIST_HEAD(cancelled);
 
+   down_write(>sem);
+
if (RB_EMPTY_ROOT(>objects.rb_root))
return;
 
@@ -156,8 +159,20 @@ static void 
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
flush_workqueue(mn->wq);
 }
 
+static void i915_gem_userptr_mn_invalidate_range_end(struct mmu_notifier *_mn,
+struct mm_struct *mm,
+unsigned long start,
+unsigned long end)
+{
+   struct i915_mmu_notifier *mn =
+   container_of(_mn, struct i915_mmu_notifier, mn);
+
+   up_write(>sem);
+}
+
 static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
.invalidate_range_start = i915_gem_userptr_mn_invalidate_range_start,
+   .invalidate_range_end = i915_gem_userptr_mn_invalidate_range_end,
 };
 
 static struct i915_mmu_notifier *
@@ -170,6 +185,7 @@ i915_mmu_notifier_create(struct mm_struct *mm)
return ERR_PTR(-ENOMEM);
 
spin_lock_init(>lock);
+   init_rwsem(>sem);
mn->mn.ops = _gem_userptr_notifier;
mn->objects = RB_ROOT_CACHED;
mn->wq = alloc_workqueue("i915-userptr-release",
@@ -504,12 +520,15 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
 
pvec = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
if (pvec != NULL) {
+   struct i915_mmu_notifier *mn = obj->userptr.mm->mn;
struct mm_struct *mm = obj->userptr.mm->mm;
unsigned int flags = 0;
 
if (!obj->userptr.read_only)
flags |= FOLL_WRITE;
 
+   down_read(>sem);
+
ret = -EFAULT;
if (mmget_not_zero(mm)) {
down_read(>mmap_sem);
@@ -528,6 +547,8 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
up_read(>mmap_sem);
mmput(mm);
}
+
+   up_read(>sem);
}
 
mutex_lock(>mm.lock);
@@ -636,15 +657,21 @@ static int i915_gem_userptr_get_pages(struct 
drm_i915_gem_object *obj)
pinned = 0;
 
if (mm == current->mm) {
+   struct i915_mmu_notifier *mn = obj->userptr.mm->mn;
+
pvec = kvmalloc_array(num_pages, sizeof(struct page *),
  GFP_KERNEL |
  __GFP_NORETRY |
  __GFP_NOWARN);
-   if (pvec) /* defer to worker if malloc fails */
+
+   /* defer to worker if malloc fails */
+   if (pvec && down_read_trylock(>sem)) {
pinned = __get_user_pages_fast(obj->userptr.ptr,
   num_pages,
   !obj->userptr.read_only,
   pvec);
+   up_read(>sem);
+   }
}
 
active = false;
-- 
2.16.3

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling

[Patchwork]

== Series Details ==

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

== Summary ==

 Possible new issues:

Test gem_ctx_param:
Subgroup invalid-param-get:
pass   -> FAIL   (shard-apl)
pass   -> FAIL   (shard-hsw)
pass   -> FAIL   (shard-snb)
Subgroup invalid-param-set:
pass   -> FAIL   (shard-apl)
pass   -> FAIL   (shard-hsw)
pass   -> FAIL   (shard-snb)

 Known issues:

Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup 2x-modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060 +2
Subgroup 2x-plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-snb) fdo#103925
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-apl) fdo#99912

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

shard-apltotal:3484 pass:1818 dwarn:1   dfail:0   fail:9   skip:1655 
time:12974s
shard-hswtotal:3484 pass:1770 dwarn:1   dfail:0   fail:5   skip:1707 
time:11768s
shard-snbtotal:3484 pass:1361 dwarn:1   dfail:0   fail:5   skip:2117 
time:7006s
Blacklisted hosts:
shard-kbltotal:3484 pass:1942 dwarn:1   dfail:1   fail:11  skip:1529 
time:9857s

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Interface to get GFX shmem usage stats per process

[Jani Nikula]

On Thu, 22 Mar 2018, Patchwork  wrote:
> == Series Details ==
>
> Series: drm/i915: Interface to get GFX shmem usage stats per process
> URL   : https://patchwork.freedesktop.org/series/40464/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip

I don't mind the foo == NULL comparisons leading to warnings
CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!foo"

But everything else here is valid, and should be fixed before submitting
this for real.

BR,
Jani.


> a2507d62bb4c drm/i915: Sysfs interface to get GFX shmem usage stats per 
> process
> -:228: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
> #228: FILE: drivers/gpu/drm/i915/i915_gem.c:6118:
> + if (res > 0 && buffer[res-1] != '\0' && len < PAGE_SIZE)
>^
>
> -:229: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
> #229: FILE: drivers/gpu/drm/i915/i915_gem.c:6119:
> + buffer[res-1] = '\0';
> ^
>
> -:275: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!entry"
> #275: FILE: drivers/gpu/drm/i915/i915_gem.c:6165:
> + if (entry == NULL) {
>
> -:315: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #315: FILE: drivers/gpu/drm/i915/i915_gem.c:6205:
> + DRM_DEBUG("Couldn't find matching tgid %d for obj %p\n",
> + current_tgid, obj);
>
> -:329: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #329: FILE: drivers/gpu/drm/i915/i915_gem.c:6219:
> +static int i915_obj_find_insert_in_hash(struct drm_i915_gem_object *obj,
> + struct pid_stat_entry *pid_entry,
>
> -:336: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #336: FILE: drivers/gpu/drm/i915/i915_gem.c:6226:
> + ret = drm_ht_find_item(_entry->namelist,
> + (unsigned long)>base, _item);
>
> -:338: CHECK:BRACES: braces {} should be used on all arms of this statement
> #338: FILE: drivers/gpu/drm/i915/i915_gem.c:6228:
> + if (ret) {
> [...]
> + } else
> [...]
>
> -:341: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!entry"
> #341: FILE: drivers/gpu/drm/i915/i915_gem.c:6231:
> + if (entry == NULL) {
>
> -:350: CHECK:BRACES: Unbalanced braces around else statement
> #350: FILE: drivers/gpu/drm/i915/i915_gem.c:6240:
> + } else
>
> -:357: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #357: FILE: drivers/gpu/drm/i915/i915_gem.c:6247:
> +static int i915_obj_shared_count(struct drm_i915_gem_object *obj,
> + struct pid_stat_entry *pid_entry,
>
> -:371: CHECK:BRACES: braces {} should be used on all arms of this statement
> #371: FILE: drivers/gpu/drm/i915/i915_gem.c:6261:
> + if (!obj->base.name && !obj->base.dma_buf)
> [...]
> + else if (obj->base.import_attach) {
> [...]
>
> -:429: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
> #429: FILE: drivers/gpu/drm/i915/i915_gem.c:6319:
> + i915_obj_get_shmem_pages_alloced(obj)*PAGE_SIZE;
>^
>
> -:439: CHECK:BRACES: braces {} should be used on all arms of this statement
> #439: FILE: drivers/gpu/drm/i915/i915_gem.c:6329:
> + if (obj_shared_count > 1) {
> [...]
> + } else
> [...]
>
> -:443: CHECK:BRACES: Unbalanced braces around else statement
> #443: FILE: drivers/gpu/drm/i915/i915_gem.c:6333:
> + } else
>
> -:480: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
> "!new_entry"
> #480: FILE: drivers/gpu/drm/i915/i915_gem.c:6370:
> + if (new_entry == NULL) {
>
> -:490: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #490: FILE: drivers/gpu/drm/i915/i915_gem.c:6380:
> + ret = drm_ht_create(_entry->namelist,
> + DRM_DEBUG_MAGIC_HASH_ORDER);
>
> -:519: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
> #519: FILE: drivers/gpu/drm/i915/i915_gem.c:6409:
> +
> + }
>
> -:541: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #541: FILE: drivers/gpu/drm/i915/i915_gem.c:6431:
> + err_puts(m,
> + "\n\n  pid   Total  Shared  Priv   Purgeable  Alloced  
> SharedPHYsize   SharedPHYpropPrivPHYsize   PurgeablePHYsize   process\n");
>
> -:561: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #561: FILE: drivers/gpu/drm/i915/i915_gem.c:6451:
> + list_for_each_entry_safe(new_pid_entry, new_temp_entry,
> + _pid_stats, head) {
>
> -:567: WARNING:MULTILINE_DEREFERENCE: Avoid multiple line dereference - 
> prefer 'new_pid_entry->stats.phys_space_shared_proportion'
> #567: FILE: drivers/gpu/drm/i915/i915_gem.c:6457:
> + new_pid_entry->
> +

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: enable perf support on ICL (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/perf: enable perf support on ICL (rev2)
URL   : https://patchwork.freedesktop.org/series/39689/
State : success

== Summary ==

Series 39689v2 drm/i915/perf: enable perf support on ICL
https://patchwork.freedesktop.org/api/1.0/series/39689/revisions/2/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-hsw-4770) fdo#104944
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:539s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:299s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:518s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:523s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:507s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:413s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:429s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:318s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-hsw-4770  total:242  pass:218  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:517s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:653s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:428s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:242  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:407s
Blacklisted hosts:
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cnl-psr   total:224  pass:198  dwarn:0   dfail:0   fail:1   skip:24 
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-skl-6260u failed to collect. IGT log at Patchwork_8491/fi-skl-6260u/run0.log
fi-skl-6700k2 failed to collect. IGT log at 
Patchwork_8491/fi-skl-6700k2/run0.log

94f5d9189e61055e246c31106b3810dc17ddee9c drm-tip: 2018y-03m-23d-23h-41m-40s UTC 
integration manifest
9813c9041d52 drm/i915/perf: use IS_GEN() instead an or condition
2996b3ba1d5d drm/i915/perf: enable perf support on ICL
778ddd601367 drm/i915/icl: read timestamp frequency information

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: enable perf support on ICL (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/perf: enable perf support on ICL (rev2)
URL   : https://patchwork.freedesktop.org/series/39689/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
778ddd601367 drm/i915/icl: read timestamp frequency information
-:19: WARNING:LONG_LINE: line over 100 characters
#19: FILE: drivers/gpu/drm/i915/i915_reg.h:865:
+#define  GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK (7 << 
GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)

total: 0 errors, 1 warnings, 0 checks, 78 lines checked
2996b3ba1d5d drm/i915/perf: enable perf support on ICL
-:29: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#29: 
new file mode 100644

-:146: WARNING:LONG_LINE: line over 100 characters
#146: FILE: drivers/gpu/drm/i915/i915_oa_icl.c:113:
+   dev_priv->perf.oa.test_config.attrs[0] = 
_priv->perf.oa.test_config.sysfs_metric_id.attr;

-:189: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#189: FILE: drivers/gpu/drm/i915/i915_oa_icl.h:32:
+extern void i915_perf_load_test_config_icl(struct drm_i915_private *dev_priv);

total: 0 errors, 2 warnings, 1 checks, 192 lines checked
9813c9041d52 drm/i915/perf: use IS_GEN() instead an or condition

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

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add NV12 support (rev4)

[Jani Nikula]

On Mon, 26 Mar 2018, Patchwork  wrote:
> == Series Details ==
>
> Series: Add NV12 support (rev4)
> URL   : https://patchwork.freedesktop.org/series/39670/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> 0503b1db737a drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
> de530aafc1d7 drm/i915/skl+: refactor WM calculation for NV12
> 7ca6efaada2b drm/i915/skl+: add NV12 in skl_format_to_fourcc
> 4863044b11a5 drm/i915/skl+: support verification of DDB HW state for NV12
> 4c4d4f07274c drm/i915/skl+: NV12 related changes for WM
> 1995882fa722 drm/i915/skl+: pass skl_wm_level struct to wm compute func
> 7a53eb021631 drm/i915/skl+: make sure higher latency level has higher wm value
> b756f5e1b974 drm/i915/skl+: nv12 workaround disable WM level 1-7
> 2f6264f9349f drm/i915/skl: split skl_compute_ddb function
> -:137: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV)
> #137: FILE: drivers/gpu/drm/i915/intel_pm.c:5160:
> + *changed = true;
>   ^

Checkpatch being clueless.

>
> total: 0 errors, 0 warnings, 1 checks, 194 lines checked
> d87f6cf26fea drm/i915: Set scaler mode for NV12
> ccc7a37f5e0a drm/i915: Update format_is_yuv() to include NV12
> 17490b4ce656 drm/i915: Upscale scaler max scale for NV12
> e155048376b9 drm/i915: Add NV12 as supported format for primary plane
> d7af95f5e1d4 drm/i915: Add NV12 as supported format for sprite plane
> 483020f92c69 drm/i915: Add NV12 support to intel_framebuffer_init
> 4ca02e5f9bd0 drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
> a7f9ce556ab2 drm/i915: Display WA 827
> 545fe6ed4604 drm/i915: Add checks to primary plane
> -:108: CHECK:SPACING: No space is necessary after a cast
> #108: FILE: drivers/gpu/drm/i915/intel_display.c:13052:
> + WARN_ON(src->x1 < (int) state->base.src_x ||
>
> -:109: CHECK:SPACING: No space is necessary after a cast
> #109: FILE: drivers/gpu/drm/i915/intel_display.c:13053:
> + src->y1 < (int) state->base.src_y ||
>
> -:110: CHECK:SPACING: No space is necessary after a cast
> #110: FILE: drivers/gpu/drm/i915/intel_display.c:13054:
> + src->x2 > (int) state->base.src_x + state->base.src_w ||
>
> -:111: CHECK:SPACING: No space is necessary after a cast
> #111: FILE: drivers/gpu/drm/i915/intel_display.c:13055:
> + src->y2 > (int) state->base.src_y + state->base.src_h);
>

I don't mind the spaces after a cast; sadly SPACING category is not
something I'm willing to ignore completely.

> -:148: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
> #148: FILE: drivers/gpu/drm/i915/intel_display.c:13092:
> + if (INTEL_GEN(dev_priv) < 9 && (src_w > 2048 || src_h > 2048 ||
> + width_bytes > 4096 || fb->pitches[0] > 4096)) {

Pedantically a valid warning, but can be ignored in favor of getting the
series finally merged.

BR,
Jani.

>
> total: 0 errors, 0 warnings, 5 checks, 148 lines checked
>
> ___
> 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 v2 3/3] drm/i915/perf: use IS_GEN() instead an or condition

[Lionel Landwerlin]

Make the code a bit more concise.

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

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 30444bb3aaa1..c27a5dfd44bd 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3443,7 +3443,7 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.read = gen8_oa_read;
dev_priv->perf.oa.ops.oa_hw_tail_read = gen8_oa_hw_tail_read;
 
-   if (IS_GEN8(dev_priv) || IS_GEN9(dev_priv)) {
+   if (IS_GEN(dev_priv, 8, 9)) {
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 =
-- 
2.16.3

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

[Intel-gfx] [PATCH v2 0/3] drm/i915/perf: enable perf support on ICL

[Lionel Landwerlin]

Hi,

Adding a patch to the previous series to read the timestamp frequency
on ICL which is required for the perf support. I'm sure I saw this
patch written by somebody before but I can't find it back :( Please
manifest yourself if you did write that patch, it should be attributed
to its rightful author.

Thanks,

Lionel Landwerlin (3):
  drm/i915/icl: read timestamp frequency information
  drm/i915/perf: enable perf support on ICL
  drm/i915/perf: use IS_GEN() instead an or condition

 drivers/gpu/drm/i915/Makefile|   3 +-
 drivers/gpu/drm/i915/i915_oa_icl.c   | 118 +++
 drivers/gpu/drm/i915/i915_oa_icl.h   |  34 +
 drivers/gpu/drm/i915/i915_perf.c |   9 ++-
 drivers/gpu/drm/i915/i915_reg.h  |   6 ++
 drivers/gpu/drm/i915/intel_device_info.c |  48 ++---
 6 files changed, 203 insertions(+), 15 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.h

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

[Intel-gfx] [PATCH v2 1/3] drm/i915/icl: read timestamp frequency information

[Lionel Landwerlin]

We're missing this value which is needed for i915/perf support.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_reg.h  |  6 
 drivers/gpu/drm/i915/intel_device_info.c | 48 
 2 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1bca695f404b..a04348053598 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -861,6 +861,12 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #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  GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT3
+#define  GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK (7 << 
GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
+#define  GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ   0
+#define  GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ 1
+#define  GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_38_4_MHZ 2
+#define  GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_25_MHZ   3
 #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)
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 0d1509e25db8..1fa8399eac6c 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -601,6 +601,8 @@ static u32 read_timestamp_frequency(struct drm_i915_private 
*dev_priv)
u32 f12_5_mhz = 12500;
u32 f19_2_mhz = 19200;
u32 f24_mhz = 24000;
+   u32 f38_4_mhz = 38400;
+   u32 f25_mhz = 25000;
 
if (INTEL_GEN(dev_priv) <= 4) {
/* PRMs say:
@@ -636,7 +638,7 @@ static u32 read_timestamp_frequency(struct drm_i915_private 
*dev_priv)
}
 
return freq;
-   } else if (INTEL_GEN(dev_priv) <= 10) {
+   } else if (INTEL_GEN(dev_priv) <= 11) {
u32 ctc_reg = I915_READ(CTC_MODE);
u32 freq = 0;
u32 rpm_config_reg = 0;
@@ -652,16 +654,40 @@ static u32 read_timestamp_frequency(struct 
drm_i915_private *dev_priv)
u32 crystal_clock;
 
rpm_config_reg = I915_READ(RPM_CONFIG0);
-   crystal_clock = (rpm_config_reg &
-
GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK) >>
-   GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT;
-   switch (crystal_clock) {
-   case GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ:
-   freq = f19_2_mhz;
-   break;
-   case GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ:
-   freq = f24_mhz;
-   break;
+
+   if (INTEL_GEN(dev_priv) == 11) {
+   crystal_clock = (rpm_config_reg &
+
GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK) >>
+   
GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT;
+   switch (crystal_clock) {
+   case 
GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ:
+   freq = f24_mhz;
+   break;
+   case 
GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ:
+   freq = f19_2_mhz;
+   break;
+   case 
GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_38_4_MHZ:
+   freq = f38_4_mhz;
+   break;
+   case 
GEN11_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_25_MHZ:
+   freq = f25_mhz;
+   break;
+   default:
+   MISSING_CASE("Invalid frequency 
setting\n");
+   break;
+   }
+   } else {
+   crystal_clock = (rpm_config_reg &
+
GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK) >>
+   
GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT;
+   switch (crystal_clock) {
+   case 
GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ:
+   freq = f19_2_mhz;
+   break;
+   case 

[Intel-gfx] [PATCH v2 2/3] drm/i915/perf: enable perf support on ICL

[Lionel Landwerlin]

No significant changes from either context offsets, nor report
formats, nor register whitelist.

v2: Also drop slice/unslice clock ratio changes (Matt)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_oa_icl.c | 118 +
 drivers/gpu/drm/i915/i915_oa_icl.h |  34 +++
 drivers/gpu/drm/i915/i915_perf.c   |   7 ++-
 4 files changed, 159 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_icl.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 552e43e9663f..0c79c19223af 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -172,7 +172,8 @@ i915-y += i915_perf.o \
  i915_oa_glk.o \
  i915_oa_cflgt2.o \
  i915_oa_cflgt3.o \
- i915_oa_cnl.o
+ i915_oa_cnl.o \
+ i915_oa_icl.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_oa_icl.c 
b/drivers/gpu/drm/i915/i915_oa_icl.c
new file mode 100644
index ..a5667926e3de
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_icl.c
@@ -0,0 +1,118 @@
+/*
+ * 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_icl.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(0x9840), 0x },
+   { _MMIO(0x9884), 0x },
+   { _MMIO(0x9888), 0x1006 },
+   { _MMIO(0x9888), 0x2206 },
+   { _MMIO(0x9888), 0x1606 },
+   { _MMIO(0x9888), 0x2406 },
+   { _MMIO(0x9888), 0x1806 },
+   { _MMIO(0x9888), 0x1a06 },
+   { _MMIO(0x9888), 0x1206 },
+   { _MMIO(0x9888), 0x1406 },
+   { _MMIO(0x9888), 0x1006 },
+   { _MMIO(0x9888), 0x2206 },
+   { _MMIO(0x9884), 0x0003 },
+   { _MMIO(0x9888), 0x1613 },
+   { _MMIO(0x9888), 0x2401 },
+   { _MMIO(0x9888), 0x0e130056 },
+   { _MMIO(0x9888), 0x1013 },
+   { _MMIO(0x9888), 0x1a13 },
+   { _MMIO(0x9888), 0x541f0001 },
+   { _MMIO(0x9888), 0x181f },
+   { _MMIO(0x9888), 0x4c1f },
+   { _MMIO(0x9888), 0x301f },
+};
+
+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_icl(struct drm_i915_private *dev_priv)
+{
+   strlcpy(dev_priv->perf.oa.test_config.uuid,
+   "a291665e-244b-4b76-9b9a-01de9d3c8068",
+   sizeof(dev_priv->perf.oa.test_config.uuid));
+   

Re: [Intel-gfx] [PATCH] drm/i915: protect macro parameters in SWING_SEL_{UPP, LO}WER

[Jani Nikula]

On Fri, 23 Mar 2018, Paulo Zanoni  wrote:
> Protect the macro parameters with parens in order to avoid priority
> issues on macro evaluation when the macro argument is not a single
> operand.
>
> This is not a problem today, but it could be in the future. I found
> this while reviewing a patch that introduces new callers for the
> macros.
>
> Reference: commit 04416108ccea ("drm/i915/cnl: Add registers related to 
> voltage swing sequences.")
> Cc: Rodrigo Vivi 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index da2f6c623ab2..49c90e1aa796 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1729,9 +1729,9 @@ enum i915_power_well_id {
>  
>  #define CNL_PORT_TX_DW2_GRP(port)_MMIO(_CNL_PORT_TX_DW_GRP((port), 2))
>  #define CNL_PORT_TX_DW2_LN0(port)_MMIO(_CNL_PORT_TX_DW_LN0((port), 2))
> -#define   SWING_SEL_UPPER(x) ((x >> 3) << 15)
> +#define   SWING_SEL_UPPER(x) (((x) >> 3) << 15)
>  #define   SWING_SEL_UPPER_MASK   (1 << 15)
> -#define   SWING_SEL_LOWER(x) ((x & 0x7) << 11)
> +#define   SWING_SEL_LOWER(x) (((x) & 0x7) << 11)

Unrelated to the patch at hand, but why do we have >> 3 and & 7 here
like this? We could have a single SWING_SEL_MASK() and SWING_SEL() that
would do the split to two parts. For future follow-up...

BR,
Jani.


>  #define   SWING_SEL_LOWER_MASK   (0x7 << 11)
>  #define   RCOMP_SCALAR(x)((x) << 0)
>  #define   RCOMP_SCALAR_MASK  (0xFF << 0)

-- 
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 10/11] drm/i915/perf: limit OA buffer size to minimum when unread

[Lionel Landwerlin]

On 26/03/18 10:08, Lionel Landwerlin wrote:

The way our hardware is designed doesn't seem to let us use the
MI_RECORD_PERF_COUNT command without setting up a circular buffer.

In the case where the user didn't request OA reports to be available
through the i915 perf stream, we can set the OA buffer to the minimum
size to avoid consuming memory which won't be used by the driver.

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

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 55c7631ad3c2..f8ec09e2d599 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1372,7 +1372,8 @@ static void gen7_init_oa_buffer(struct drm_i915_private 
*dev_priv)
 * the assumption that new reports are being written to zeroed
 * memory...
 */
There is an issue in both function programming the OA buffer. They still 
program the length of the buffer to 16Mb.

I'll send a v2.

-   memset(dev_priv->perf.oa.oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
+   memset(dev_priv->perf.oa.oa_buffer.vaddr, 0,
+  dev_priv->perf.oa.oa_buffer.vma->size);
  
  	/* Maybe make ->pollin per-stream state if we support multiple

 * concurrent streams in the future.
@@ -1430,7 +1431,8 @@ static void gen8_init_oa_buffer(struct drm_i915_private 
*dev_priv)
 * the assumption that new reports are being written to zeroed
 * memory...
 */
-   memset(dev_priv->perf.oa.oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
+   memset(dev_priv->perf.oa.oa_buffer.vaddr, 0,
+  dev_priv->perf.oa.oa_buffer.vma->size);
  
  	/*

 * Maybe make ->pollin per-stream state if we support multiple
@@ -1439,10 +1441,13 @@ static void gen8_init_oa_buffer(struct drm_i915_private 
*dev_priv)
dev_priv->perf.oa.pollin = false;
  }
  
-static int alloc_oa_buffer(struct drm_i915_private *dev_priv)

+static int alloc_oa_buffer(struct drm_i915_private *dev_priv,
+  struct i915_perf_stream *stream)
  {
struct drm_i915_gem_object *bo;
struct i915_vma *vma;
+   u32 buffer_size = (stream->sample_flags & SAMPLE_OA_REPORT) == 0 ?
+   SZ_128K : OA_BUFFER_SIZE;
int ret;
  
  	ret = i915_mutex_lock_interruptible(_priv->drm);

@@ -1457,7 +1462,7 @@ static int alloc_oa_buffer(struct drm_i915_private 
*dev_priv)
BUILD_BUG_ON_NOT_POWER_OF_2(OA_BUFFER_SIZE);
BUILD_BUG_ON(OA_BUFFER_SIZE < SZ_128K || OA_BUFFER_SIZE > SZ_16M);
  
-	bo = i915_gem_object_create(dev_priv, OA_BUFFER_SIZE);

+   bo = i915_gem_object_create(dev_priv, buffer_size);
if (IS_ERR(bo)) {
DRM_ERROR("Failed to allocate OA buffer\n");
ret = PTR_ERR(bo);
@@ -2148,7 +2153,7 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
intel_runtime_pm_get(dev_priv);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
  
-	ret = alloc_oa_buffer(dev_priv);

+   ret = alloc_oa_buffer(dev_priv, stream);
if (ret)
goto err_oa_buf_alloc;
  



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

Re: [Intel-gfx] [PATCH 04/11] drm/i915/perf: do not warn when OA buffer is already allocated

[Lionel Landwerlin]

On 26/03/18 13:00, Matthew Auld wrote:

On 26 March 2018 at 10:08, Lionel Landwerlin
 wrote:

If 2 processes race to open the perf stream, it's possible that one of them
will see that OA buffer has already been allocated, while a previous process
is still finishing to reprogram the hardware (on gen8+).

But we grab the perf.lock while opening the perf stream, and we only
allow one exclusive stream. Maybe I'm missing something?


Arg, you're right...
The locking situation is really not obvious in this file.
I think we can drop this patch.

Thanks!
___
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: Eliminate plane->fb/crtc usage for atomic drivers (rev5)

[Patchwork]

== Series Details ==

Series: drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5)
URL   : https://patchwork.freedesktop.org/series/40478/
State : success

== Summary ==

Series 40478v5 drm: Eliminate plane->fb/crtc usage for atomic drivers
https://patchwork.freedesktop.org/api/1.0/series/40478/revisions/5/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927
incomplete -> PASS   (fi-hsw-4770) fdo#104944

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:433s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:449s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:537s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:511s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:514s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:519s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:507s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:512s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:428s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:317s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:408s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:472s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:428s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:478s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:651s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:532s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:506s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:508s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:428s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:584s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:399s
Blacklisted hosts:
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cnl-psr   total:224  pass:198  dwarn:0   dfail:0   fail:1   skip:24 
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:484s

94f5d9189e61055e246c31106b3810dc17ddee9c drm-tip: 2018y-03m-23d-23h-41m-40s UTC 
integration manifest
5b47761e238f drm/i915: Make force_load_detect effective even w/ DMI 
quirks/hotplug
d8e5f287c232 drm/i915: Restore planes after load detection
af0596d92fc4 drm/vc4: Stop updating plane->fb/crtc
7ea33fb4ffda drm/virtio: Stop updating plane->crtc
5c81f06359a0 drm/msm: Stop updating plane->fb/crtc
dd5198a96fab drm/exynos: Stop updating plane->crtc
9eb46f68d697 drm/i915: Stop updating plane->fb/crtc
98c28044ce49 drm/amdgpu/dc: Stop updating plane->fb
9295b76b993d drm: Stop updating plane->crtc/fb/old_fb on atomic drivers
ab4d18f860a9 drm/atmel-hlcdc: Stop using plane->fb
213b45d96872 drm/zte: Stop consulting plane->crtc
260aa997ef90 drm/vmwgfx: Stop consulting plane->fb
9aee2233a34a drm/sti: Stop consulting plane->fb
c63ecc6320ad drm/msm: Stop consulting plane->fb
7fe441e1f443 drm/i915: Stop consulting plane->fb
9fd23bc1fc50 drm: Use plane->state->fb over plane->fb
f3e2f2d38a43 drm: Make the fb refcount handover less magic
755974d48345 drm: Adjust whitespace for legibility
c82dc4275c43 drm: Add local 'plane' variable for primary/cursor planes
9847962e92bf drm/atomic-helper: WARN if legacy plane fb pointers are bogus when 
committing duplicated 

Re: [Intel-gfx] [igt-dev] [CI i-g-t] tests/perf_pmu: Avoid RT thread for accuracy test

[Tvrtko Ursulin]

On 26/03/2018 12:17, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-03-26 11:57:58)

  * No self-adjust - instead just report the achieved cycle and let the
parent check against it.


Sniff, I was rather proud of our achievement. I had it in mind as a
template for future autocalibration routines. Is it really useless
overengineering, or worse broken?


It works fine I think, but the problem is I cannot locate a source of 
systematic error which seems proportional to number of loop iterations. 
:( After battling with trying to improve it for a couple days I decided 
to try to see how the simpler approach will fare on the shards.


There's the tasklet delay, which made me think things could be better 
without RT. And then polling on the spinner makes it worse in all cases 
for me, however I fiddle with it. So again, I wanted to try the 
simplification..


The version from this patch seems super stable on my system, but the 50% 
case still has an apparent +.5-6% systematic error. Maybe on the shards 
it will not be as stable..


Regards,

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5)

[Patchwork]

== Series Details ==

Series: drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5)
URL   : https://patchwork.freedesktop.org/series/40478/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
eec2e4920fa9 Revert "drm/atomic-helper: Fix leak in disable_all"
885b9185b11c drm/atomic-helper: Make drm_atomic_helper_disable_all() update the 
plane->fb pointers
-:93: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#93: FILE: drivers/gpu/drm/drm_atomic_helper.c:2952:
 }
+/**

total: 0 errors, 0 warnings, 1 checks, 98 lines checked
565952128dd5 drm: Clear crtc->primary->crtc when disabling the crtc via 
setcrtc()
9847962e92bf drm/atomic-helper: WARN if legacy plane fb pointers are bogus when 
committing duplicated state
c82dc4275c43 drm: Add local 'plane' variable for primary/cursor planes
-:121: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & 
recovery code rather than BUG() or BUG_ON()
#121: FILE: drivers/gpu/drm/drm_plane.c:773:
+   BUG_ON(!plane);

-:122: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"plane->crtc"
#122: FILE: drivers/gpu/drm/drm_plane.c:774:
+   WARN_ON(plane->crtc != crtc && plane->crtc != NULL);

-:171: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"!plane->fb"
#171: FILE: drivers/gpu/drm/drm_plane.c:1014:
+   if (plane->fb == NULL) {

total: 0 errors, 1 warnings, 2 checks, 186 lines checked
755974d48345 drm: Adjust whitespace for legibility
f3e2f2d38a43 drm: Make the fb refcount handover less magic
9fd23bc1fc50 drm: Use plane->state->fb over plane->fb
-:90: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!old_fb"
#90: FILE: drivers/gpu/drm/drm_plane.c:1024:
+   if (old_fb == NULL) {

total: 0 errors, 0 warnings, 1 checks, 79 lines checked
7fe441e1f443 drm/i915: Stop consulting plane->fb
c63ecc6320ad drm/msm: Stop consulting plane->fb
9aee2233a34a drm/sti: Stop consulting plane->fb
260aa997ef90 drm/vmwgfx: Stop consulting plane->fb
213b45d96872 drm/zte: Stop consulting plane->crtc
ab4d18f860a9 drm/atmel-hlcdc: Stop using plane->fb
9295b76b993d drm: Stop updating plane->crtc/fb/old_fb on atomic drivers
98c28044ce49 drm/amdgpu/dc: Stop updating plane->fb
9eb46f68d697 drm/i915: Stop updating plane->fb/crtc
dd5198a96fab drm/exynos: Stop updating plane->crtc
5c81f06359a0 drm/msm: Stop updating plane->fb/crtc
7ea33fb4ffda drm/virtio: Stop updating plane->crtc
af0596d92fc4 drm/vc4: Stop updating plane->fb/crtc
d8e5f287c232 drm/i915: Restore planes after load detection
5b47761e238f drm/i915: Make force_load_detect effective even w/ DMI 
quirks/hotplug

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling

[Patchwork]

== Series Details ==

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

== Summary ==

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

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-hsw-4770) fdo#104944

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

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:546s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:295s
fi-bxt-dsi   total:243  pass:216  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:511s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:521s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:507s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:428s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:316s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:408s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:423s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:472s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:434s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:473s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:515s
fi-pnv-d510  total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  
time:652s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:541s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:509s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:429s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:572s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:403s
Blacklisted hosts:
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cnl-psr   total:224  pass:198  dwarn:0   dfail:0   fail:1   skip:24 
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:490s

94f5d9189e61055e246c31106b3810dc17ddee9c drm-tip: 2018y-03m-23d-23h-41m-40s UTC 
integration manifest
ae480c117350 drm/i915: Allow user control over preempt timeout on the important 
context
b72df86f0c84 drm/i915: Use a preemption timeout to enforce interactivity
1992a69b17b3 drm/i915/preemption: Select timeout when scheduling
ebbe79e61164 drm/i915/execlists: Force preemption via reset on timeout
17bce80a463b drm/i915/execlists: Flush pending preemption events during reset
b9c4fb9ea980 drm/i915: Split execlists/guc reset prepartions
e0fa2379926b drm/i915: Move engine reset prepare/finish to backends
84c375a58791 drm/i915/execlists: Refactor out complete_preempt_context()
d3c6c6e49941 drm/i915: Include submission tasklet state in engine dump
571ee98c9870 drm/i915/execlists: Clear user-active flag on preemption completion
6cd6e46a6275 drm/i915/execlists: Avoid kicking the submission too early for 
rescheduling

== Logs ==

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

[Intel-gfx] [PATCH v3 13/23] drm/zte: Stop consulting plane->crtc

[Ville Syrjala]

From: Ville Syrjälä 

We want to get rid of plane->crtc on atomic drivers. Stop looking at it.

v2: Use old_state->crtc (Maarten)
v3: s/fb/crtc/ in commit message to actually match the patch (Shawn)

Cc: Shawn Guo 
Cc: Maarten Lankhorst 
Signed-off-by: Ville Syrjälä 
Acked-by: Shawn Guo 
---
 drivers/gpu/drm/zte/zx_plane.c | 2 +-
 drivers/gpu/drm/zte/zx_vou.c   | 5 +++--
 drivers/gpu/drm/zte/zx_vou.h   | 3 ++-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 94545adac50d..d1931f5ea0b2 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -268,7 +268,7 @@ static void zx_plane_atomic_disable(struct drm_plane *plane,
struct zx_plane *zplane = to_zx_plane(plane);
void __iomem *hbsc = zplane->hbsc;
 
-   zx_vou_layer_disable(plane);
+   zx_vou_layer_disable(plane, old_state);
 
/* Disable HBSC block */
zx_writel_mask(hbsc + HBSC_CTRL0, HBSC_CTRL_EN, 0);
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 7491813131f3..442311d31110 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -627,9 +627,10 @@ void zx_vou_layer_enable(struct drm_plane *plane)
zx_writel_mask(vou->osd + OSD_CTRL0, bits->enable, bits->enable);
 }
 
-void zx_vou_layer_disable(struct drm_plane *plane)
+void zx_vou_layer_disable(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
 {
-   struct zx_crtc *zcrtc = to_zx_crtc(plane->crtc);
+   struct zx_crtc *zcrtc = to_zx_crtc(old_state->crtc);
struct zx_vou_hw *vou = zcrtc->vou;
struct zx_plane *zplane = to_zx_plane(plane);
const struct vou_layer_bits *bits = zplane->bits;
diff --git a/drivers/gpu/drm/zte/zx_vou.h b/drivers/gpu/drm/zte/zx_vou.h
index 97d72bfce982..5b7f84fbb112 100644
--- a/drivers/gpu/drm/zte/zx_vou.h
+++ b/drivers/gpu/drm/zte/zx_vou.h
@@ -62,6 +62,7 @@ void zx_vou_config_dividers(struct drm_crtc *crtc,
struct vou_div_config *configs, int num);
 
 void zx_vou_layer_enable(struct drm_plane *plane);
-void zx_vou_layer_disable(struct drm_plane *plane);
+void zx_vou_layer_disable(struct drm_plane *plane,
+ struct drm_plane_state *old_state);
 
 #endif /* __ZX_VOU_H__ */
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH 06/11] drm/i915: rename PPGTT/GGTT fields OA registers

[Matthew Auld]

On 26 March 2018 at 10:08, Lionel Landwerlin
 wrote:
> We had a generic field name used across 2 registers but it feels like
> it's clearer we make it obvious what register this field belongs to.
>
> Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx