Re: [Intel-gfx] [PATCH 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles

2020-03-24 Thread Ingo Molnar


* Masahiro Yamada  wrote:

> This series of cleanups was prompted by Linus:
> https://lkml.org/lkml/2020/3/12/726
> 
> First, this series drop always-on CONFIG_AS_* options.
> Some of those options were introduced in old days.
> For example, the check for CONFIG_AS_CFI dates back to 2006.
> 
> We raise the minimal tool versions from time to time.
> Currently, we require binutils 2.21
> (and we plan to bump it to 2.23 for v5.7-rc1).
> 
> After cleaning away the old checks,
> as-instr calls are moved to Kconfig from Makefiles.
> (patch 11)
> 
> This allows more Kconfig / Makefile cleanups.
> Patch 12 is complex, but I double-checked it does the equivalent.
> 
> Patch 14 bumps the binutils version to 2.23,
> and patch 15 removes more CONFIG_AS_* options.
> 
> I folded all relevanet patches into this series,
> as suggested by Jason A. Donenfeld.
> 
> If x86 maintainers take care of this series, that's good.
> 
> If it is OK to queue this up to Kbuild tree,
> I will send a pull request to Linus.
> 
> Thank you.

LGTM. I've got these four from Jason A. Donenfeld queued up in 
tip:WIP.x86/asm:

 bd5b1283e41c: ("crypto: Curve25519 - do not pollute dispatcher based on 
assembler")
 829f32d78588: ("crypto: X86 - rework configuration, based on Kconfig")
 95ef9f80ed63: ("x86/build: Probe assembler from Kconfig instead of Kbuild")
 1651e700664b: ("x86: Fix bitops.h warning with a moved cast")

I suppose these might interact (maybe even conflict), and are topically 
related.

Would you like to pull these into the kbuild tree? You can find them in:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/asm

Thanks,

Ingo
___
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,1/2] drm/dp: DRM DP helper for reading Ignore MSA from DPCD

2020-03-24 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/dp: DRM DP helper for reading Ignore 
MSA from DPCD
URL   : https://patchwork.freedesktop.org/series/75042/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8184_full -> Patchwork_17077_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_17077_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_eio@kms:
- shard-glk:  [PASS][1] -> [TIMEOUT][2] ([i915#1383])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-glk9/igt@gem_...@kms.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-glk5/igt@gem_...@kms.html

  * igt@gem_exec_schedule@implicit-both-bsd1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-iclb4/igt@gem_exec_sched...@implicit-both-bsd1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-iclb8/igt@gem_exec_sched...@implicit-both-bsd1.html

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-iclb6/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html

  * igt@gem_exec_schedule@preempt-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +2 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-iclb6/igt@gem_exec_sched...@preempt-bsd.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-iclb1/igt@gem_exec_sched...@preempt-bsd.html

  * igt@gem_exec_schedule@promotion-bsd1:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +11 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-iclb2/igt@gem_exec_sched...@promotion-bsd1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-iclb8/igt@gem_exec_sched...@promotion-bsd1.html

  * igt@gem_exec_store@cachelines-vcs1:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112080]) +7 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-iclb2/igt@gem_exec_st...@cachelines-vcs1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-iclb8/igt@gem_exec_st...@cachelines-vcs1.html

  * igt@i915_suspend@sysfs-reader:
- shard-kbl:  [PASS][13] -> [DMESG-WARN][14] ([i915#180])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-kbl3/igt@i915_susp...@sysfs-reader.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-kbl1/igt@i915_susp...@sysfs-reader.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding:
- shard-skl:  [PASS][15] -> [FAIL][16] ([i915#54])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html

  * igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-ytiled:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#52] / 
[i915#54])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-skl7/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-ytiled.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-skl6/igt@kms_draw_...@draw-method-xrgb-mmap-gtt-ytiled.html

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl:  [PASS][19] -> [DMESG-WARN][20] ([i915#180] / 
[i915#95])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-apl4/igt@kms_fbcon_...@fbc-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-apl1/igt@kms_fbcon_...@fbc-suspend.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-skl:  [PASS][21] -> [INCOMPLETE][22] ([i915#221])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-skl5/igt@kms_f...@flip-vs-suspend-interruptible.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-skl9/igt@kms_f...@flip-vs-suspend-interruptible.html
- shard-apl:  [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +1 
similar issue
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-apl1/igt@kms_f...@flip-vs-suspend-interruptible.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/shard-apl6/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl:  [PASS][25] -> [FAIL][26] ([fdo#108145]) +1 similar 
issue
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-s

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm_device managed resources (rev7)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm_device managed resources (rev7)
URL   : https://patchwork.freedesktop.org/series/73633/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8184_full -> Patchwork_17074_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17074_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17074_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_17074_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_balancer@nop:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-iclb2/igt@gem_exec_balan...@nop.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/shard-iclb4/igt@gem_exec_balan...@nop.html

  
Known issues


  Here are the changes found in Patchwork_17074_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +16 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-iclb4/igt@gem_b...@busy-vcs1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/shard-iclb7/igt@gem_b...@busy-vcs1.html

  * igt@gem_exec_schedule@implicit-both-bsd1:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) +2 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-iclb4/igt@gem_exec_sched...@implicit-both-bsd1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd1.html

  * igt@gem_exec_schedule@pi-shared-iova-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-iclb3/igt@gem_exec_sched...@pi-shared-iova-bsd.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/shard-iclb1/igt@gem_exec_sched...@pi-shared-iova-bsd.html

  * igt@gem_exec_schedule@preempt-contexts-bsd2:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +21 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-iclb2/igt@gem_exec_sched...@preempt-contexts-bsd2.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/shard-iclb8/igt@gem_exec_sched...@preempt-contexts-bsd2.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +4 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-iclb7/igt@gem_exec_sched...@preemptive-hang-bsd.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/shard-iclb1/igt@gem_exec_sched...@preemptive-hang-bsd.html

  * igt@i915_pm_rc6_residency@rc6-idle:
- shard-skl:  [PASS][13] -> [FAIL][14] ([i915#1520])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-skl7/igt@i915_pm_rc6_reside...@rc6-idle.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/shard-skl7/igt@i915_pm_rc6_reside...@rc6-idle.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#72])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-glk3/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html

  * igt@kms_draw_crc@draw-method-rgb565-render-xtiled:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#52] / [i915#54])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-glk2/igt@kms_draw_...@draw-method-rgb565-render-xtiled.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/shard-glk9/igt@kms_draw_...@draw-method-rgb565-render-xtiled.html

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl:  [PASS][19] -> [DMESG-WARN][20] ([i915#180] / 
[i915#93] / [i915#95])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-kbl6/igt@kms_fbcon_...@fbc-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/shard-kbl1/igt@kms_fbcon_...@fbc-suspend.html

  * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
- shard-glk:  [PASS][21] -> [FAIL][22] ([i915#34])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/shard-glk8/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/shard-glk2/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html

  * ig

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/dp: DRM DP helper for reading Ignore MSA from DPCD

2020-03-24 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/dp: DRM DP helper for reading Ignore 
MSA from DPCD
URL   : https://patchwork.freedesktop.org/series/75042/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8184 -> Patchwork_17077


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/index.html

Known issues


  Here are the changes found in Patchwork_17077 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-snb-2600:[PASS][1] -> [DMESG-WARN][2] ([i915#42])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- fi-cml-s:   [DMESG-FAIL][3] ([i915#877]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17077/fi-cml-s/igt@i915_selftest@live@gem_contexts.html

  
  [i915#42]: https://gitlab.freedesktop.org/drm/intel/issues/42
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877


Participating hosts (40 -> 39)
--

  Additional (6): fi-kbl-soraka fi-hsw-4770r fi-bsw-n3050 fi-byt-j1900 
fi-kbl-7500u fi-cfl-8109u 
  Missing(7): fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus fi-bsw-nick fi-skl-6600u 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8184 -> Patchwork_17077

  CI-20190529: 20190529
  CI_DRM_8184: 1a72c9d9d3140e92190485d766b9d165932c5b86 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5535: d1dcf40cc6869ac858586c5ad9f09af6617ce2ee @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17077: f456eddc0f150e1234121f0c65f91d7b47ceeb7c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f456eddc0f15 drm/i915/dp: Attach and set drm connector VRR property
b3e66fa48b38 drm/dp: DRM DP helper for reading Ignore MSA from DPCD

== Logs ==

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


Re: [Intel-gfx] [PATCH v2 0/6] Re-org uC debugfs files and move them under GT

2020-03-24 Thread Andi Shyti
Hi Daniele,

On Wed, Mar 11, 2020 at 06:16:25PM -0700, Daniele Ceraolo Spurio wrote:
> Rebased on top of Andi's patch. Note that some discussion is still
> ongoing on that patch.
> 
> Also dropped the patch that caused a const->non-const conversion and
> fixed a couple of bugs:
> - keep printing HUC_STATUS register
> - correcly set permissions for writable debugfs files
> 
> Cc: Andi Shyti 
> Cc: Michal Wajdeczko 
> Cc: John Harrison 
> Cc: Matthew Brost  
> 
> Andi Shyti (1):
>   drm/i915/gt: allow setting generic data pointer
> 
> Daniele Ceraolo Spurio (5):
>   drm/i915/guc: drop stage_pool debugfs
>   drm/i915/huc: make "support huc" reflect HW capabilities
>   drm/i915/debugfs: move uC printers and update debugfs file names
>   drm/i915/uc: Move uC debugfs to its own folder under GT
>   drm/i915/uc: do not free err log on uc_fini

is this series getting in at some point or shall I take this
series over?

Andi
___
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/2] drm/dp: DRM DP helper for reading Ignore MSA from DPCD

2020-03-24 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/dp: DRM DP helper for reading Ignore 
MSA from DPCD
URL   : https://patchwork.freedesktop.org/series/75042/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b3e66fa48b38 drm/dp: DRM DP helper for reading Ignore MSA from DPCD
-:11: WARNING:TYPO_SPELLING: 'paramaters' may be misspelled - perhaps 
'parameters'?
#11: 
ignore the MSA video timing paramaters and its ability to support

total: 0 errors, 1 warnings, 0 checks, 14 lines checked
f456eddc0f15 drm/i915/dp: Attach and set drm connector VRR property

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


[Intel-gfx] [PATCH v2 1/2] drm/dp: DRM DP helper for reading Ignore MSA from DPCD

2020-03-24 Thread Manasi Navare
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing paramaters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for the sink to indicate that it is Adaptive sync
capable.

v2:
* Rename to describe what the function does (Jani Nikula)

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 
Signed-off-by: Manasi Navare 
Reviewed-by: Harry Wentland 
---
 include/drm/drm_dp_helper.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 9d87cdf2740a..36655f3c83f8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1315,6 +1315,14 @@ drm_dp_alternate_scrambler_reset_cap(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
DP_ALTERNATE_SCRAMBLER_RESET_CAP;
 }
 
+/* Ignore MSA timing for Adaptive Sync support on DP 1.4 */
+static inline bool
+drm_dp_sink_can_do_video_without_timing_msa(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   return dpcd[DP_DOWN_STREAM_PORT_COUNT] &
+   DP_MSA_TIMING_PAR_IGNORED;
+}
+
 /*
  * DisplayPort AUX channel
  */
-- 
2.19.1

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


[Intel-gfx] [PATCH v2 2/2] drm/i915/dp: Attach and set drm connector VRR property

2020-03-24 Thread Manasi Navare
From: Aditya Swarup 

This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.

v2:
* Just set this in intel_dp_get_modes instead of new hook (Jani)

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Signed-off-by: Aditya Swarup 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index ef2e06e292d5..95db4e783893 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5843,6 +5843,23 @@ intel_dp_force(struct drm_connector *connector)
intel_display_power_put(dev_priv, aux_domain, wakeref);
 }
 
+static bool intel_dp_is_vrr_capable(struct drm_connector *connector)
+{
+   struct intel_dp *intel_dp = 
intel_attached_dp(to_intel_connector(connector));
+   const struct drm_display_info *info = &connector->display_info;
+   struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+   /*
+* DP Sink is capable of Variable refresh video timings if
+* Ignore MSA bit is set in DPCD.
+* EDID monitor range also should be atleast 10 for reasonable
+* Adaptive sync/ VRR end user experience.
+*/
+   return INTEL_GEN(dev_priv) >= 12 &&
+   drm_dp_sink_can_do_video_without_timing_msa(intel_dp->dpcd) &&
+   info->monitor_range.max_vfreq - info->monitor_range.min_vfreq > 
10;
+}
+
 static int intel_dp_get_modes(struct drm_connector *connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -5853,6 +5870,10 @@ static int intel_dp_get_modes(struct drm_connector 
*connector)
int ret = intel_connector_update_modes(connector, edid);
if (ret)
return ret;
+
+   if (intel_dp_is_vrr_capable(connector))
+   drm_connector_set_vrr_capable_property(connector,
+  true);
}
 
/* if eDP has no EDID, fall back to fixed mode */
@@ -6880,6 +6901,9 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct 
drm_connector *connect
connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
 
}
+
+   if (INTEL_GEN(dev_priv) >= 12)
+   drm_connector_attach_vrr_capable_property(connector);
 }
 
 static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
-- 
2.19.1

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Measure the energy consumed while in RC6 (rev4)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Measure the energy consumed while in RC6 (rev4)
URL   : https://patchwork.freedesktop.org/series/75035/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8184 -> Patchwork_17076


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17076 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17076, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17076/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_17076:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_pm:
- fi-icl-guc: [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-icl-guc/igt@i915_selftest@live@gt_pm.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17076/fi-icl-guc/igt@i915_selftest@live@gt_pm.html

  
Known issues


  Here are the changes found in Patchwork_17076 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@execlists:
- fi-bxt-dsi: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927] / 
[i915#529])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17076/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- fi-cml-s:   [DMESG-FAIL][5] ([i915#877]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17076/fi-cml-s/igt@i915_selftest@live@gem_contexts.html

  
 Warnings 

  * igt@i915_selftest@live@gem_contexts:
- fi-cfl-guc: [DMESG-FAIL][7] ([i915#481]) -> [DMESG-FAIL][8] 
([i915#730] / [i915#933])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17076/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html

  
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [i915#481]: https://gitlab.freedesktop.org/drm/intel/issues/481
  [i915#529]: https://gitlab.freedesktop.org/drm/intel/issues/529
  [i915#730]: https://gitlab.freedesktop.org/drm/intel/issues/730
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
  [i915#933]: https://gitlab.freedesktop.org/drm/intel/issues/933


Participating hosts (40 -> 35)
--

  Additional (5): fi-kbl-soraka fi-hsw-4770r fi-byt-j1900 fi-kbl-7500u 
fi-cfl-8109u 
  Missing(10): fi-bdw-samus fi-hsw-peppy fi-byt-squawks fi-bsw-cyan 
fi-ilk-650 fi-ctg-p8600 fi-blb-e6850 fi-byt-n2820 fi-bsw-nick fi-skl-6600u 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8184 -> Patchwork_17076

  CI-20190529: 20190529
  CI_DRM_8184: 1a72c9d9d3140e92190485d766b9d165932c5b86 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5535: d1dcf40cc6869ac858586c5ad9f09af6617ce2ee @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17076: be4a0fbdaf4cb7df9f6278ba72cf83e802314730 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

be4a0fbdaf4c drm/i915/selftests: Measure the energy consumed while in RC6

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/selftests: Measure the energy consumed while in RC6

2020-03-24 Thread Chris Wilson
Measure and compare the energy consumed, as reported by the rapl MSR,
by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
at least halve the energy consumption of RC0, as this more than likely
means we failed to enter RC0 correctly.

If we can't measure the energy draw with the MSR, then it will report 0
for both measurements. Since the measurement works on all gen6+, this seems
worth flagging as an error.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/selftest_rc6.c | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c 
b/drivers/gpu/drm/i915/gt/selftest_rc6.c
index 95b165faeba7..04c3ba71749f 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rc6.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
@@ -12,6 +12,22 @@
 
 #include "selftests/i915_random.h"
 
+static u64 energy_uJ(struct intel_rc6 *rc6)
+{
+   unsigned long long power;
+   u32 units;
+
+   if (rdmsrl_safe(MSR_RAPL_POWER_UNIT, &power))
+   return 0;
+
+   units = (power & 0x1f00) >> 8;
+
+   if (rdmsrl_safe(MSR_PP1_ENERGY_STATUS, &power))
+   return 0;
+
+   return (100 * power) >> units; /* convert to uJ */
+}
+
 static u64 rc6_residency(struct intel_rc6 *rc6)
 {
u64 result;
@@ -31,7 +47,9 @@ int live_rc6_manual(void *arg)
 {
struct intel_gt *gt = arg;
struct intel_rc6 *rc6 = >->rc6;
+   u64 rc0_power, rc6_power;
intel_wakeref_t wakeref;
+   ktime_t dt;
u64 res[2];
int err = 0;
 
@@ -53,22 +71,35 @@ int live_rc6_manual(void *arg)
__intel_rc6_disable(rc6);
msleep(1); /* wakeup is not immediate, takes about 100us on icl */
 
+   dt = ktime_get();
+   rc0_power = energy_uJ(rc6);
res[0] = rc6_residency(rc6);
msleep(250);
res[1] = rc6_residency(rc6);
+   rc0_power = div64_u64(NSEC_PER_SEC * (energy_uJ(rc6) - rc0_power),
+ ktime_to_ns(ktime_sub(ktime_get(), dt)));
if ((res[1] - res[0]) >> 10) {
pr_err("RC6 residency increased by %lldus while disabled for 
250ms!\n",
   (res[1] - res[0]) >> 10);
err = -EINVAL;
goto out_unlock;
}
+   if (!rc0_power) {
+   pr_err("No power measured while in RC0\n");
+   err = -EINVAL;
+   goto out_unlock;
+   }
 
/* Manually enter RC6 */
intel_rc6_park(rc6);
 
+   dt = ktime_get();
+   rc6_power = energy_uJ(rc6);
res[0] = rc6_residency(rc6);
msleep(100);
res[1] = rc6_residency(rc6);
+   rc6_power = div64_u64(NSEC_PER_SEC * (energy_uJ(rc6) - rc6_power),
+ ktime_to_ns(ktime_sub(ktime_get(), dt)));
 
if (res[1] == res[0]) {
pr_err("Did not enter RC6! RC6_STATE=%08x, RC6_CONTROL=%08x, 
residency=%lld\n",
@@ -78,6 +109,14 @@ int live_rc6_manual(void *arg)
err = -EINVAL;
}
 
+   pr_info("GPU consumed %llduW in RC0 and %llduW in RC6\n",
+   rc0_power, rc6_power);
+   if ((rc6_power >> 10) > (rc0_power >> 10) / 2) { /* compare mW */
+   pr_err("GPU leaked energy while in RC6!\n");
+   err = -EINVAL;
+   goto out_unlock;
+   }
+
/* Restore what should have been the original state! */
intel_rc6_unpark(rc6);
 
-- 
2.20.1

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Measure the energy consumed while in RC6 (rev3)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Measure the energy consumed while in RC6 (rev3)
URL   : https://patchwork.freedesktop.org/series/75035/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8184 -> Patchwork_17075


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17075 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17075, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17075/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_17075:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_pm:
- fi-glk-dsi: [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-glk-dsi/igt@i915_selftest@live@gt_pm.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17075/fi-glk-dsi/igt@i915_selftest@live@gt_pm.html
- fi-apl-guc: [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-apl-guc/igt@i915_selftest@live@gt_pm.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17075/fi-apl-guc/igt@i915_selftest@live@gt_pm.html
- fi-icl-guc: [PASS][5] -> [DMESG-FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-icl-guc/igt@i915_selftest@live@gt_pm.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17075/fi-icl-guc/igt@i915_selftest@live@gt_pm.html
- fi-bxt-dsi: [PASS][7] -> [DMESG-FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-bxt-dsi/igt@i915_selftest@live@gt_pm.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17075/fi-bxt-dsi/igt@i915_selftest@live@gt_pm.html

  
Known issues


  Here are the changes found in Patchwork_17075 that come from known issues:

### IGT changes ###

 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- fi-cml-s:   [DMESG-FAIL][9] ([i915#877]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17075/fi-cml-s/igt@i915_selftest@live@gem_contexts.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877


Participating hosts (40 -> 42)
--

  Additional (6): fi-kbl-soraka fi-hsw-4770r fi-bsw-n3050 fi-byt-j1900 
fi-kbl-7500u fi-cfl-8109u 
  Missing(4): fi-ctg-p8600 fi-byt-squawks fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8184 -> Patchwork_17075

  CI-20190529: 20190529
  CI_DRM_8184: 1a72c9d9d3140e92190485d766b9d165932c5b86 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5535: d1dcf40cc6869ac858586c5ad9f09af6617ce2ee @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17075: 73d97df3bf7eca669a5e20e97110111df29f45d3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

73d97df3bf7e drm/i915/selftests: Measure the energy consumed while in RC6

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm_device managed resources (rev7)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm_device managed resources (rev7)
URL   : https://patchwork.freedesktop.org/series/73633/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8184 -> Patchwork_17074


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/index.html

Known issues


  Here are the changes found in Patchwork_17074 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([i915#189])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-icl-dsi/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/fi-icl-dsi/igt@i915_pm_...@module-reload.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- fi-cml-s:   [DMESG-FAIL][3] ([i915#877]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/fi-cml-s/igt@i915_selftest@live@gem_contexts.html

  
 Warnings 

  * igt@i915_selftest@live@gem_contexts:
- fi-skl-lmem:[INCOMPLETE][5] ([i915#424]) -> [DMESG-FAIL][6] 
([i915#481])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html

  * igt@runner@aborted:
- fi-kbl-8809g:   [FAIL][7] ([i915#1209]) -> [FAIL][8] ([i915#1485] / 
[i915#192] / [i915#193] / [i915#194])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8184/fi-kbl-8809g/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17074/fi-kbl-8809g/igt@run...@aborted.html

  
  [i915#1209]: https://gitlab.freedesktop.org/drm/intel/issues/1209
  [i915#1485]: https://gitlab.freedesktop.org/drm/intel/issues/1485
  [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189
  [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
  [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
  [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
  [i915#481]: https://gitlab.freedesktop.org/drm/intel/issues/481
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877


Participating hosts (40 -> 41)
--

  Additional (6): fi-kbl-soraka fi-bsw-n3050 fi-byt-j1900 fi-kbl-7500u 
fi-cfl-8109u fi-kbl-7560u 
  Missing(5): fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 
fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8184 -> Patchwork_17074

  CI-20190529: 20190529
  CI_DRM_8184: 1a72c9d9d3140e92190485d766b9d165932c5b86 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5535: d1dcf40cc6869ac858586c5ad9f09af6617ce2ee @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17074: 1eab7d6989ddec146d7a4c84db4d5e191891b6fd @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1eab7d6989dd drm: Add docs for managed resources
6b5f55ae0e4b drm/udl: drop drm_driver.release hook
a18c3359dd5f drm/udl: Drop explicit drm_mode_config_cleanup call
0b7aec23a492 drm/mipi-dbi: Drop explicit drm_mode_config_cleanup call
b53161c5e59e drm/mipi-dbi: Move drm_mode_config_init into mipi library
ae60691f4e71 drm/repaper: Drop explicit drm_mode_config_cleanup call
0ac911b345c3 drm/gm12u320: Simplify upload work
de2c1853b136 drm/gm12u320: Use helpers for shutdown/suspend/resume
9e8af690b11c drm/gm12u320: Use devm_drm_dev_init
a9be2f852109 drm/gm12u320: More drmm_
43c7dc5664ae drm/tidss: Drop explicit drm_mode_config_cleanup call
f7848b464ea3 drm/mtk: Drop explicit drm_mode_config_cleanup call
171ebef2bd8d drm/shmob: Drop explicit drm_mode_config_cleanup call
60148391818a drm/stm: Drop explicit drm_mode_config_cleanup call
eb1e76dbc719 drm/rockchip: Drop explicit drm_mode_config_cleanup call
582b972d98b2 drm/rcar-du: Drop explicit drm_mode_config_cleanup call
a7a82feb57b6 drm/pl111: Drop explicit drm_mode_config_cleanup call
1d46bf8e3214 drm/meson: Drop explicit drm_mode_config_cleanup call
d91bfa1380e0 drm/mcde: More devm_drm_dev_init
567631ed96bc drm/mcde: Drop explicit drm_mode_config_cleanup call
ea853880511a drm/ingenic: Drop explicit drm_mode_config_cleanup call
d125bb619e9b drm/cirrus: Fully embrace devm_
d3c19b8672e5 drm/cirrus: Drop explicit drm_mode_config_cleanup call
49a81974bfbe drm/bochs: Drop explicit drm_mode_config_cleanup
66b5bf6c1d10 drm/bochs: Remove leftover drm_atomic_helper_shutdown
6108261bffbc drm: Manage drm_mode_config_init with drmm_
f0a630503538 drm: Garbage collect drm_dev_fini
d778e63bdf3d drm: Manage drm_vblank_cleanup with drmm_
f93ff21e

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm_device managed resources (rev7)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm_device managed resources (rev7)
URL   : https://patchwork.freedesktop.org/series/73633/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: mm/sl[uo]b: export __kmalloc_track(_node)_caller
Okay!

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


Re: [Intel-gfx] [PATCH] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission

2020-03-24 Thread Francisco Jerez
Chris Wilson  writes:

> Quoting Francisco Jerez (2020-03-23 22:30:13)
>> Chris Wilson  writes:
>> 
>> > Quoting Francisco Jerez (2020-03-20 22:14:51)
>> >> Francisco Jerez  writes:
>> >> 
>> >> > Chris Wilson  writes:
>> >> >
>> >> >> We dropped calling process_csb prior to handling direct submission in
>> >> >> order to avoid the nesting of spinlocks and lift process_csb() and the
>> >> >> majority of the tasklet out of irq-off. However, we do want to avoid
>> >> >> ksoftirqd latency in the fast path, so try and pull the interrupt-bh
>> >> >> local to direct submission if we can acquire the tasklet's lock.
>> >> >>
>> >> >> v2: Tweak the balance to avoid over submitting lite-restores
>> >> >>
>> >> >> Signed-off-by: Chris Wilson 
>> >> >> Cc: Francisco Jerez 
>> >> >> Cc: Tvrtko Ursulin 
>> >> >> ---
>> >> >>  drivers/gpu/drm/i915/gt/intel_lrc.c| 44 --
>> >> >>  drivers/gpu/drm/i915/gt/selftest_lrc.c |  2 +-
>> >> >>  2 files changed, 36 insertions(+), 10 deletions(-)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
>> >> >> b/drivers/gpu/drm/i915/gt/intel_lrc.c
>> >> >> index f09dd87324b9..dceb65a0088f 100644
>> >> >> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
>> >> >> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
>> >> >> @@ -2884,17 +2884,17 @@ static void queue_request(struct 
>> >> >> intel_engine_cs *engine,
>> >> >>  set_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
>> >> >>  }
>> >> >>  
>> >> >> -static void __submit_queue_imm(struct intel_engine_cs *engine)
>> >> >> +static bool pending_csb(const struct intel_engine_execlists *el)
>> >> >>  {
>> >> >> -struct intel_engine_execlists * const execlists = 
>> >> >> &engine->execlists;
>> >> >> +return READ_ONCE(*el->csb_write) != READ_ONCE(el->csb_head);
>> >> >> +}
>> >> >>  
>> >> >> -if (reset_in_progress(execlists))
>> >> >> -return; /* defer until we restart the engine following 
>> >> >> reset */
>> >> >> +static bool skip_lite_restore(struct intel_engine_execlists *el,
>> >> >> +  const struct i915_request *rq)
>> >> >> +{
>> >> >> +struct i915_request *inflight = execlists_active(el);
>> >> >>  
>> >> >> -if (execlists->tasklet.func == execlists_submission_tasklet)
>> >> >> -__execlists_submission_tasklet(engine);
>> >> >> -else
>> >> >> -tasklet_hi_schedule(&execlists->tasklet);
>> >> >> +return inflight && inflight->context == rq->context;
>> >> >>  }
>> >> >>  
>> >> >>  static void submit_queue(struct intel_engine_cs *engine,
>> >> >> @@ -2905,8 +2905,34 @@ static void submit_queue(struct intel_engine_cs 
>> >> >> *engine,
>> >> >>  if (rq_prio(rq) <= execlists->queue_priority_hint)
>> >> >>  return;
>> >> >>  
>> >> >> +if (reset_in_progress(execlists))
>> >> >> +return; /* defer until we restart the engine following 
>> >> >> reset */
>> >> >> +
>> >> >> +/*
>> >> >> + * Suppress immediate lite-restores, leave that to the tasklet.
>> >> >> + *
>> >> >> + * However, we leave the queue_priority_hint unset so that if we 
>> >> >> do
>> >> >> + * submit a second context, we push that into ELSP[1] immediately.
>> >> >> + */
>> >> >> +if (skip_lite_restore(execlists, rq))
>> >> >> +return;
>> >> >> +
>> >> > Why do you need to treat lite-restore specially here?
>> >
>> > Lite-restore have a noticeable impact on no-op loads. A part of that is
>> > that a lite-restore is about 1us, and the other part is that the driver
>> > has a lot more work to do. There's a balance point around here for not
>> > needlessly interrupting ourselves and ensuring that there is no bubble.
>> >
>> 
>> Oh, I see.  But isn't inhibiting the lite restore likely to be fairly
>> costly in some cases as well if it causes the GPU to go idle after the
>> current context completes for as long as it takes the CPU to wake up,
>> process the IRQ and dequeue the next request?
>
> Yes. It's an amusing diversion to try and think how can we do a single
> context submission (well 2) for a sequence of requests, for those
> clients that like to submit N batches at once. From an idle GPU,
> assuming each batch is non-trivial, we want to do something like submit
> batch 1, accumulate, then submit batches 1-N, i.e. skip the intervening
> lite-restores but complete the submission with all the work queued.
>

I guess ideally you would submit batch 1, then batch 2 (so you don't
have to rush to feed the GPU once batch 1 terminates), then accumulate
any further requests until batch 1 completes.  That would reduce the
number of lite-restores to the minimum you need to keep the GPU at least
one request ahead.  Though I'm guessing that this would involve using
the breadcrumbs IRQ to aid command submission so we can tell when batch
1 terminated, since AFAIUI we won't get any execlists interrupt at that
point if batch 1 and 2 happened to belong to the same context.

Sigh.  Submitting commands

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm_device managed resources (rev7)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm_device managed resources (rev7)
URL   : https://patchwork.freedesktop.org/series/73633/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ccd08fc6b11b mm/sl[uo]b: export __kmalloc_track(_node)_caller
-:58: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 28 lines checked
d5e9e9dffec3 drm/i915: Don't clear drvdata in ->release
-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 0998d0631001 ("device-core: 
Ensure drvdata = NULL when no driver is bound")'
#20: 
commit 0998d0631001288a5974afc0b2a5f568bcdecb4d

-:45: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 1 errors, 1 warnings, 0 checks, 9 lines checked
b262cc982e91 drm: add managed resources tied to drm_device
-:72: WARNING:TYPO_SPELLING: 'unecessary' may be misspelled - perhaps 
'unnecessary'?
#72: 
v8: Remove unecessary {} around if else

-:74: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#74: 
v9: Use kstrdup_const, which requires kfree_const and introducing a free_dr()

-:85: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Neil Armstrong 
driver->release && !dev->managed.final_kfree) {
[...]
-   }
[...]

-:153: WARNING:NEEDLESS_IF: kfree(NULL) is safe and this check is probably not 
required
#153: FILE: drivers/gpu/drm/drm_drv.c:841:
+   } else if (dev->managed.final_kfree)
+   kfree(dev->managed.final_kfree);

-:172: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#172: 
new file mode 100644

-:247: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#247: FILE: drivers/gpu/drm/drm_managed.c:71:
+static __always_inline struct drmres * alloc_dr(drmres_release_t release,

-:275: CHECK:SPACING: No space is necessary after a cast
#275: FILE: drivers/gpu/drm/drm_managed.c:99:
+  dr, dr->node.name, (unsigned long) dr->node.size);

-:287: CHECK:SPACING: No space is necessary after a cast
#287: FILE: drivers/gpu/drm/drm_managed.c:111:
+  dr, dr->node.name, (unsigned long) dr->node.size);

-:293: CHECK:SPACING: No space is necessary after a cast
#293: FILE: drivers/gpu/drm/drm_managed.c:117:
+   WARN_ON(dev < (struct drm_device *) container);

-:295: CHECK:SPACING: No space is necessary after a cast
#295: FILE: drivers/gpu/drm/drm_managed.c:119:
+   (struct drm_device *) (container + ksize(container)));

-:307: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
#307: FILE: drivers/gpu/drm/drm_managed.c:131:
+   dr = alloc_dr(action, data ? sizeof(void*) : 0,

-:402: WARNING:SPDX_LICENSE_TAG: Improper SPDX comment style for 
'include/drm/drm_managed.h', please use '/*' instead
#402: FILE: include/drm/drm_managed.h:1:
+// SPDX-License-Identifier: GPL-2.0

-:402: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#402: FILE: include/drm/drm_managed.h:1:
+// SPDX-License-Identifier: GPL-2.0

-:455: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 3 errors, 7 warnings, 5 checks, 322 lines checked
eb0e9b4246b6 drm: Set final_kfree in drm_dev_alloc
-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 0a6659bdc5e8 ("drm/bochs: new 
driver")'
#15: 
commit 0a6659bdc5e8221da99eebb176fd9591435e38de

-:25: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit b1df3a2b24a9 ("drm/virtio: add 
drm_driver.release callback.")'
#25: 
commit b1df3a2b24a917f8853d43fe9683c0e360d2c33a

-:44: WARNING:BAD_SIGN_OFF: Duplicate signature
#44: 
Cc: Oleksandr Andrushchenko 

-:45: WARNING:BAD_SIGN_OFF: Duplicate signature
#45: 
Cc: xen-de...@lists.xenproject.org

-:87: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 2 errors, 3 warnings, 0 checks, 29 lines checked
f5c3aceaaf48 drm/mipi_dbi: Use drmm_add_final_kfree in all drivers
-:189: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 111 lines checked
b9562b8c0b3b drm/udl: Use drmm_add_final_kfree
-:63: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 27 lines checked
648cc4f29283 drm/qxl: Use drmm_add_final_kfree
-:47: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 22 lines checked
b8bf4addd08d drm/i915: Use drmm_add_final_kfree
-:207: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings,

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v3,1/6] drm/i915/tc/tgl: Implement TCCOLD sequences

2020-03-24 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/6] drm/i915/tc/tgl: Implement TCCOLD 
sequences
URL   : https://patchwork.freedesktop.org/series/75034/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8183_full -> Patchwork_17073_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_17073_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@vecs0-s3:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2] ([i915#69]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl10/igt@gem_ctx_isolat...@vecs0-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-skl5/igt@gem_ctx_isolat...@vecs0-s3.html

  * igt@gem_exec_schedule@implicit-write-read-bsd1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb4/igt@gem_exec_sched...@implicit-write-read-bsd1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-iclb6/igt@gem_exec_sched...@implicit-write-read-bsd1.html

  * igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +2 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb5/igt@gem_exec_sched...@in-order-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-iclb2/igt@gem_exec_sched...@in-order-bsd.html

  * igt@gem_exec_schedule@pi-ringfull-bsd2:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +8 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb4/igt@gem_exec_sched...@pi-ringfull-bsd2.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-iclb6/igt@gem_exec_sched...@pi-ringfull-bsd2.html

  * igt@gem_linear_blits@interruptible:
- shard-apl:  [PASS][9] -> [FAIL][10] ([i915#1263])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-apl7/igt@gem_linear_bl...@interruptible.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-apl4/igt@gem_linear_bl...@interruptible.html

  * igt@i915_selftest@live@execlists:
- shard-apl:  [PASS][11] -> [INCOMPLETE][12] ([fdo#103927] / 
[i915#656])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-apl4/igt@i915_selftest@l...@execlists.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-apl7/igt@i915_selftest@l...@execlists.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding:
- shard-skl:  [PASS][13] -> [FAIL][14] ([i915#54])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl:  [PASS][15] -> [FAIL][16] ([i915#79])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-skl9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
- shard-skl:  [PASS][17] -> [INCOMPLETE][18] ([i915#221])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl2/igt@kms_f...@flip-vs-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-skl1/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-kbl:  [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-kbl3/igt@kms_f...@flip-vs-suspend-interruptible.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-kbl7/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl:  [PASS][21] -> [FAIL][22] ([fdo#108145])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl5/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) 
+1 similar issue
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html

  * igt@kms_psr2_su@page_flip:
- shard-iclb: [PAS

Re: [Intel-gfx] [PATCH] drm: manage drm_minor cleanup with drmm_

2020-03-24 Thread Sam Ravnborg
On Tue, Mar 24, 2020 at 09:39:36PM +0100, Daniel Vetter wrote:
> The cleanup here is somewhat tricky, since we can't tell apart the
> allocated minor index from 0. So register a cleanup action first, and
> if the index allocation fails, unregister that cleanup action again to
> avoid bad mistakes.
> 
> The kdev for the minor already handles NULL, so no problem there.
> 
> Hence add drmm_remove_action() to the drm_managed library.
> 
> v2: Make pointer math around void ** consistent with what Laurent
> suggested.
> 
> v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed
> because of some questions from Thomas. This also means we need to move
> the drmm_add_action_or_reset helper earlier in the series.
> 
> v4: Uh ... fix slightly embarrassing bug CI spotted.
Looks like the one I spotted in my review.
Saw your mail only after posting.

One Q below.

> 
> Cc: Thomas Zimmermann 
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_drv.c | 69 ---
>  drivers/gpu/drm/drm_managed.c | 14 +++
>  include/drm/drm_managed.h |  9 -
>  3 files changed, 46 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index a710c53d13a8..50c56ff24c71 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -93,13 +93,25 @@ static struct drm_minor **drm_minor_get_slot(struct 
> drm_device *dev,
>   }
>  }
>  
> +static void drm_minor_alloc_release(struct drm_device *dev, void *data)
> +{
> + struct drm_minor *minor = data;
> + unsigned long flags;
> +
> + put_device(minor->kdev);
> +
> + spin_lock_irqsave(&drm_minor_lock, flags);
> + idr_remove(&drm_minors_idr, minor->index);
> + spin_unlock_irqrestore(&drm_minor_lock, flags);
> +}
> +
>  static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
>  {
>   struct drm_minor *minor;
>   unsigned long flags;
>   int r;
>  
> - minor = kzalloc(sizeof(*minor), GFP_KERNEL);
> + minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
>   if (!minor)
>   return -ENOMEM;
>  
> @@ -117,46 +129,20 @@ static int drm_minor_alloc(struct drm_device *dev, 
> unsigned int type)
>   idr_preload_end();
>  
>   if (r < 0)
> - goto err_free;
> + return r;
>  
>   minor->index = r;
>  
> + r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
> + if (r)
> + return r;
> +
>   minor->kdev = drm_sysfs_minor_alloc(minor);
> - if (IS_ERR(minor->kdev)) {
> - r = PTR_ERR(minor->kdev);
> - goto err_index;
> - }
> + if (IS_ERR(minor->kdev))
> + return PTR_ERR(minor->kdev);
>  
>   *drm_minor_get_slot(dev, type) = minor;
>   return 0;
> -
> -err_index:
> - spin_lock_irqsave(&drm_minor_lock, flags);
> - idr_remove(&drm_minors_idr, minor->index);
> - spin_unlock_irqrestore(&drm_minor_lock, flags);
> -err_free:
> - kfree(minor);
> - return r;
> -}
> -
> -static void drm_minor_free(struct drm_device *dev, unsigned int type)
> -{
> - struct drm_minor **slot, *minor;
> - unsigned long flags;
> -
> - slot = drm_minor_get_slot(dev, type);
> - minor = *slot;
> - if (!minor)
> - return;
> -
> - put_device(minor->kdev);
> -
> - spin_lock_irqsave(&drm_minor_lock, flags);
> - idr_remove(&drm_minors_idr, minor->index);
> - spin_unlock_irqrestore(&drm_minor_lock, flags);
> -
> - kfree(minor);

> - *slot = NULL;

In drm_minor_alloc_release() there is no equivalent to this
NULL assignment.
Did you consider if there was any real reason for the NULL assignment?

Sam


>  }
>  
>  static int drm_minor_register(struct drm_device *dev, unsigned int type)
> @@ -678,16 +664,16 @@ int drm_dev_init(struct drm_device *dev,
>   if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>   ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>   if (ret)
> - goto err_minors;
> + goto err;
>   }
>  
>   ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
>   if (ret)
> - goto err_minors;
> + goto err;
>  
>   ret = drm_legacy_create_map_hash(dev);
>   if (ret)
> - goto err_minors;
> + goto err;
>  
>   drm_legacy_ctxbitmap_init(dev);
>  
> @@ -695,7 +681,7 @@ int drm_dev_init(struct drm_device *dev,
>   ret = drm_gem_init(dev);
>   if (ret) {
>   DRM_ERROR("Cannot initialize graphics execution manager 
> (GEM)\n");
> - goto err_ctxbitmap;
> + goto err;
>   }
>   }
>  
> @@ -708,10 +694,6 @@ int drm_dev_init(struct drm_device *dev,
>  err_setunique:
>   if (drm_core_check_feature(dev, DRIVER_GEM))
>   drm_gem_destroy(dev);
> -err_ctxbitmap:
> -err_minors:
> -   

Re: [Intel-gfx] [PATCH 22/51] drm: manage drm_minor cleanup with drmm_

2020-03-24 Thread Sam Ravnborg
On Mon, Mar 23, 2020 at 03:49:21PM +0100, Daniel Vetter wrote:
> The cleanup here is somewhat tricky, since we can't tell apart the
> allocated minor index from 0. So register a cleanup action first, and
> if the index allocation fails, unregister that cleanup action again to
> avoid bad mistakes.
> 
> The kdev for the minor already handles NULL, so no problem there.
> 
> Hence add drmm_remove_action() to the drm_managed library.
> 
> v2: Make pointer math around void ** consistent with what Laurent
> suggested.
> 
> v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed
> because of some questions from Thomas. This also means we need to move
> the drmm_add_action_or_reset helper earlier in the series.
> 
> Cc: Thomas Zimmermann 
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_drv.c | 70 ---
>  drivers/gpu/drm/drm_managed.c | 14 +++
>  include/drm/drm_managed.h |  9 -
>  3 files changed, 46 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index a710c53d13a8..25fc2107057c 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -93,13 +93,25 @@ static struct drm_minor **drm_minor_get_slot(struct 
> drm_device *dev,
>   }
>  }
>  
> +static void drm_minor_alloc_release(struct drm_device *dev, void *data)
> +{
> + struct drm_minor *minor = data;
> + unsigned long flags;
> +
> + put_device(minor->kdev);
> +
> + spin_lock_irqsave(&drm_minor_lock, flags);
> + idr_remove(&drm_minors_idr, minor->index);
> + spin_unlock_irqrestore(&drm_minor_lock, flags);
> +}
> +
>  static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
>  {
>   struct drm_minor *minor;
>   unsigned long flags;
>   int r;
>  
> - minor = kzalloc(sizeof(*minor), GFP_KERNEL);
> + minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
>   if (!minor)
>   return -ENOMEM;
>  
> @@ -117,46 +129,19 @@ static int drm_minor_alloc(struct drm_device *dev, 
> unsigned int type)
>   idr_preload_end();
>  
>   if (r < 0)
> - goto err_free;
> + return r;
>  
> - minor->index = r;
> + r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
> + if (r)
> + return r;
>  
> + minor->index = r;

This looks wrong.

We do:
r = idr_alloc(&drm_minors_idr,

And then we loose the value when we reuse r
in the call to drmm_add_action_or_reset().
So the index we assign is the return value of
drmm_add_action_or_reset() and not the ID returned
by idr_alloc()

With this fixed:

Reviewed-by: Sam Ravnborg 

>   minor->kdev = drm_sysfs_minor_alloc(minor);
> - if (IS_ERR(minor->kdev)) {
> - r = PTR_ERR(minor->kdev);
> - goto err_index;
> - }
> + if (IS_ERR(minor->kdev))
> + return PTR_ERR(minor->kdev);
>  
>   *drm_minor_get_slot(dev, type) = minor;
>   return 0;
> -
> -err_index:
> - spin_lock_irqsave(&drm_minor_lock, flags);
> - idr_remove(&drm_minors_idr, minor->index);
> - spin_unlock_irqrestore(&drm_minor_lock, flags);
> -err_free:
> - kfree(minor);
> - return r;
> -}
> -
> -static void drm_minor_free(struct drm_device *dev, unsigned int type)
> -{
> - struct drm_minor **slot, *minor;
> - unsigned long flags;
> -
> - slot = drm_minor_get_slot(dev, type);
> - minor = *slot;
> - if (!minor)
> - return;
> -
> - put_device(minor->kdev);
> -
> - spin_lock_irqsave(&drm_minor_lock, flags);
> - idr_remove(&drm_minors_idr, minor->index);
> - spin_unlock_irqrestore(&drm_minor_lock, flags);
> -
> - kfree(minor);
> - *slot = NULL;
>  }
>  
>  static int drm_minor_register(struct drm_device *dev, unsigned int type)
> @@ -678,16 +663,16 @@ int drm_dev_init(struct drm_device *dev,
>   if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>   ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>   if (ret)
> - goto err_minors;
> + goto err;
>   }
>  
>   ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
>   if (ret)
> - goto err_minors;
> + goto err;
>  
>   ret = drm_legacy_create_map_hash(dev);
>   if (ret)
> - goto err_minors;
> + goto err;
>  
>   drm_legacy_ctxbitmap_init(dev);
>  
> @@ -695,7 +680,7 @@ int drm_dev_init(struct drm_device *dev,
>   ret = drm_gem_init(dev);
>   if (ret) {
>   DRM_ERROR("Cannot initialize graphics execution manager 
> (GEM)\n");
> - goto err_ctxbitmap;
> + goto err;
>   }
>   }
>  
> @@ -708,10 +693,6 @@ int drm_dev_init(struct drm_device *dev,
>  err_setunique:
>   if (drm_core_check_feature(dev, DRIVER_GEM))
>   d

Re: [Intel-gfx] [PATCH 1/3] drm/i915/perf: rework aging tail workaround

2020-03-24 Thread Dixit, Ashutosh
On Tue, 24 Mar 2020 11:54:55 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin 
>
> We're about to introduce an options to open the perf stream, giving
> the user ability to configure how often it wants the kernel to poll
> the OA registers for available data.
>
> Right now the workaround against the OA tail pointer race condition
> requires at least twice the internal kernel polling timer to make any
> data available.
>
> This changes introduce checks on the OA data written into the circular
> buffer to make as much data as possible available on the first
> iteration of the polling timer.

Reviewed-by: Ashutosh Dixit 

>
> v2: Use OA_TAKEN macro without the gtt_offset (Lionel)
> v3: (Umesh)
> - Rebase
> - Change report to report32 from below review
>   https://patchwork.freedesktop.org/patch/330704/?series=66697&rev=1
> v4: (Ashutosh, Lionel)
> - Fix checkpatch errors
> - Fix aging_timestamp initialization
> - Check for only one valid landed report
> - Fix check for unlanded report
> v5: (Ashutosh)
> - Fix bug in accurately determining landed report.
> - Optimize the check for landed reports by going as far as the
>   previously determined aged tail.
>
> Signed-off-by: Lionel Landwerlin 
> Signed-off-by: Umesh Nerlige Ramappa 
> ---
>  drivers/gpu/drm/i915/i915_perf.c   | 204 ++---
>  drivers/gpu/drm/i915/i915_perf_types.h |  28 ++--
>  2 files changed, 97 insertions(+), 135 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 3222f6cd8255..4583ae9b77be 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -223,26 +223,17 @@
>   *
>   * Although this can be observed explicitly while copying reports to 
> userspace
>   * by checking for a zeroed report-id field in tail reports, we want to 
> account
> - * for this earlier, as part of the oa_buffer_check to avoid lots of 
> redundant
> - * read() attempts.
> - *
> - * In effect we define a tail pointer for reading that lags the real tail
> - * pointer by at least %OA_TAIL_MARGIN_NSEC nanoseconds, which gives enough
> - * time for the corresponding reports to become visible to the CPU.
> - *
> - * To manage this we actually track two tail pointers:
> - *  1) An 'aging' tail with an associated timestamp that is tracked until we
> - * can trust the corresponding data is visible to the CPU; at which point
> - * it is considered 'aged'.
> - *  2) An 'aged' tail that can be used for read()ing.
> - *
> - * The two separate pointers let us decouple read()s from tail pointer aging.
> - *
> - * The tail pointers are checked and updated at a limited rate within a 
> hrtimer
> - * callback (the same callback that is used for delivering EPOLLIN events)
> - *
> - * Initially the tails are marked invalid with %INVALID_TAIL_PTR which
> - * indicates that an updated tail pointer is needed.
> + * for this earlier, as part of the oa_buffer_check_unlocked to avoid lots of
> + * redundant read() attempts.
> + *
> + * We workaround this issue in oa_buffer_check_unlocked() by reading the 
> reports
> + * in the OA buffer, starting from the tail reported by the HW until we find 
> a
> + * report with its first 2 dwords not 0 meaning its previous report is
> + * completely in memory and ready to be read. Those dwords are also set to 0
> + * once read and the whole buffer is cleared upon OA buffer initialization. 
> The
> + * first dword is the reason for this report while the second is the 
> timestamp,
> + * making the chances of having those 2 fields at 0 fairly unlikely. A more
> + * detailed explanation is available in oa_buffer_check_unlocked().
>   *
>   * Most of the implementation details for this workaround are in
>   * oa_buffer_check_unlocked() and _append_oa_reports()
> @@ -454,8 +445,8 @@ static u32 gen7_oa_hw_tail_read(struct i915_perf_stream 
> *stream)
>   * (See description of OA_TAIL_MARGIN_NSEC above for further details.)
>   *
>   * Besides returning true when there is data available to read() this 
> function
> - * also has the side effect of updating the oa_buffer.tails[], 
> .aging_timestamp
> - * and .aged_tail_idx state used for reading.
> + * also updates the tail, aging_tail and aging_timestamp in the oa_buffer
> + * object.
>   *
>   * Note: It's safe to read OA config state here unlocked, assuming that this 
> is
>   * only called while the stream is enabled, while the global OA configuration
> @@ -465,28 +456,18 @@ static u32 gen7_oa_hw_tail_read(struct i915_perf_stream 
> *stream)
>   */
>  static bool oa_buffer_check_unlocked(struct i915_perf_stream *stream)
>  {
> + u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma);
>   int report_size = stream->oa_buffer.format_size;
>   unsigned long flags;
> - unsigned int aged_idx;
> - u32 head, hw_tail, aged_tail, aging_tail;
> + u32 hw_tail;
>   u64 now;
>
>   /* We have to consider the (unlikely) possibility that read() errors
> - 

Re: [Intel-gfx] [PATCH 21/51] drm: Use drmm_ for drm_dev_init cleanup

2020-03-24 Thread Sam Ravnborg
Hi Daniel.

On Mon, Mar 23, 2020 at 03:49:20PM +0100, Daniel Vetter wrote:
> Well for the simple stuff at least, vblank, gem and minor cleanup I
> want to further split up as a demonstration.
> 
> v2: We need to clear drm_device->dev otherwise the debug drm printing
> after our cleanup hook (e.g. in drm_manged_release) will chase
> released memory and result in a use-after-free. Not really pretty, but
> oh well.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_drv.c | 48 ---
>  1 file changed, 25 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index c80ebc6811b1..a710c53d13a8 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -580,6 +580,23 @@ static void drm_fs_inode_free(struct inode *inode)
>   *used.
>   */
>  
> +static void drm_dev_init_release(struct drm_device *dev, void *res)
> +{
> + drm_legacy_ctxbitmap_cleanup(dev);
> + drm_legacy_remove_map_hash(dev);
> + drm_fs_inode_free(dev->anon_inode);
> +
> + put_device(dev->dev);
> + /* Prevent use-after-free in drm_managed_release when debugging is
> +  * enabled. Slightly awkward, but can't really be helped. */
> + dev->dev = NULL;
> + mutex_destroy(&dev->master_mutex);
> + mutex_destroy(&dev->clientlist_mutex);
> + mutex_destroy(&dev->filelist_mutex);
> + mutex_destroy(&dev->struct_mutex);
> + drm_legacy_destroy_members(dev);
> +}
> +
>  /**
>   * drm_dev_init - Initialise new DRM device
>   * @dev: DRM device
> @@ -647,11 +664,15 @@ int drm_dev_init(struct drm_device *dev,
>   mutex_init(&dev->clientlist_mutex);
>   mutex_init(&dev->master_mutex);
>  
> + ret = drmm_add_action(dev, drm_dev_init_release, NULL);
> + if (ret)
> + return ret;
> +
>   dev->anon_inode = drm_fs_inode_new();
>   if (IS_ERR(dev->anon_inode)) {
>   ret = PTR_ERR(dev->anon_inode);
>   DRM_ERROR("Cannot allocate anonymous inode: %d\n", ret);
> - goto err_free;
> + goto err;
>   }
>  
>   if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> @@ -688,19 +709,12 @@ int drm_dev_init(struct drm_device *dev,
>   if (drm_core_check_feature(dev, DRIVER_GEM))
>   drm_gem_destroy(dev);
>  err_ctxbitmap:
> - drm_legacy_ctxbitmap_cleanup(dev);
> - drm_legacy_remove_map_hash(dev);
>  err_minors:
>   drm_minor_free(dev, DRM_MINOR_PRIMARY);
>   drm_minor_free(dev, DRM_MINOR_RENDER);
> - drm_fs_inode_free(dev->anon_inode);
> -err_free:
> - put_device(dev->dev);
> - mutex_destroy(&dev->master_mutex);
> - mutex_destroy(&dev->clientlist_mutex);
> - mutex_destroy(&dev->filelist_mutex);
> - mutex_destroy(&dev->struct_mutex);
> - drm_legacy_destroy_members(dev);
> +err:
> + drm_managed_release(dev);
If for example drmm_add_action() fails this will call the following
functions without their init parts called:

drm_legacy_ctxbitmap_cleanup(dev);

This function do:
mutex_lock(&dev->struct_mutex);
idr_destroy(&dev->ctx_idr);
mutex_unlock(&dev->struct_mutex);
Use of struct_mutex - OK
Call to idr_destroy() - I could not convince myself this was OK.
But I did not look too deep into idr_destroy() - thsi is unknown
land for me.

drm_legacy_remove_map_hash(dev);

This function do:
drm_ht_remove(&dev->map_hash); =>
if ((&dev->map_hash)->table) {

->table is NULL is init fucntion is not called - OK


drm_fs_inode_free(dev->anon_inode);

  NOP if anon_inode is NULL - OK

So if idr_destroy() call is OK then error handling looks OK
and the patch is:
Reviewed-by: Sam Ravnborg 

The error handling is even nicer later in this series.
But I looked only at this patch for now.

Sam



> +
>   return ret;
>  }
>  EXPORT_SYMBOL(drm_dev_init);
> @@ -763,20 +777,8 @@ void drm_dev_fini(struct drm_device *dev)
>   if (drm_core_check_feature(dev, DRIVER_GEM))
>   drm_gem_destroy(dev);
>  
> - drm_legacy_ctxbitmap_cleanup(dev);
> - drm_legacy_remove_map_hash(dev);
> - drm_fs_inode_free(dev->anon_inode);
> -
>   drm_minor_free(dev, DRM_MINOR_PRIMARY);
>   drm_minor_free(dev, DRM_MINOR_RENDER);
> -
> - put_device(dev->dev);
> -
> - mutex_destroy(&dev->master_mutex);
> - mutex_destroy(&dev->clientlist_mutex);
> - mutex_destroy(&dev->filelist_mutex);
> - mutex_destroy(&dev->struct_mutex);
> - drm_legacy_destroy_members(dev);
>  }
>  EXPORT_SYMBOL(drm_dev_fini);
>  
> -- 
> 2.25.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: add OA interrupt support (rev8)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm/i915/perf: add OA interrupt support (rev8)
URL   : https://patchwork.freedesktop.org/series/54280/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8183_full -> Patchwork_17072_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_17072_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb2/igt@gem_exec_balan...@smoke.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-iclb3/igt@gem_exec_balan...@smoke.html

  * igt@gem_exec_schedule@implicit-read-write-bsd1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd1.html

  * igt@gem_exec_schedule@pi-shared-iova-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-iclb1/igt@gem_exec_sched...@pi-shared-iova-bsd.html

  * igt@gem_exec_schedule@preempt-queue-bsd1:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +22 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb2/igt@gem_exec_sched...@preempt-queue-bsd1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd1.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +3 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb7/igt@gem_exec_sched...@preemptive-hang-bsd.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-iclb1/igt@gem_exec_sched...@preemptive-hang-bsd.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#54])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#79])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-glk9/igt@kms_f...@flip-vs-expired-vblank.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-glk6/igt@kms_f...@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-kbl:  [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +3 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-kbl3/igt@kms_f...@flip-vs-suspend-interruptible.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-kbl3/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265]) 
+1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html

  * igt@kms_psr2_su@page_flip:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb2/igt@kms_psr2_su@page_flip.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-iclb3/igt@kms_psr2_su@page_flip.html

  * igt@kms_psr@psr2_dpms:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar 
issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb2/igt@kms_psr@psr2_dpms.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-iclb4/igt@kms_psr@psr2_dpms.html

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-apl:  [PASS][23] -> [DMESG-WARN][24] ([i915#180])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-apl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/shard-apl1/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html

  * igt@perf_pmu@busy-vcs1:
- shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#112080]) +11 similar 
issues
   [25]: 
https://intel-gf

[Intel-gfx] [PATCH] drm/i915/selftests: Measure the energy consumed while in RC6

2020-03-24 Thread Chris Wilson
Measure and compare the energy consumed, as reported by the rapl MSR,
by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
at least halve the energy consumption of RC0, as this more than likely
means we failed to enter RC0 correctly.

If we can't measure the energy draw with the MSR, then it will report 0
for both measurements. Since the measurement works on all gen6+, this seems
worth flagging as an error.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/selftest_rc6.c | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c 
b/drivers/gpu/drm/i915/gt/selftest_rc6.c
index 95b165faeba7..0b3368cb6d89 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rc6.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
@@ -12,6 +12,22 @@
 
 #include "selftests/i915_random.h"
 
+#define MCH_SECP_NRG_STTS  _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x592c)
+
+static u64 energy_uJ(struct intel_rc6 *rc6)
+{
+   unsigned long long power;
+   u32 units;
+
+   if (rdmsrl_safe(MSR_RAPL_POWER_UNIT, &power))
+   return 0;
+
+   units = (power & 0x1f00) >> 8;
+   power = intel_uncore_read_fw(rc6_to_uncore(rc6), MCH_SECP_NRG_STTS);
+
+   return (100 * power) >> units; /* convert to uJ */
+}
+
 static u64 rc6_residency(struct intel_rc6 *rc6)
 {
u64 result;
@@ -31,7 +47,9 @@ int live_rc6_manual(void *arg)
 {
struct intel_gt *gt = arg;
struct intel_rc6 *rc6 = >->rc6;
+   u64 rc0_power, rc6_power;
intel_wakeref_t wakeref;
+   ktime_t dt;
u64 res[2];
int err = 0;
 
@@ -53,22 +71,35 @@ int live_rc6_manual(void *arg)
__intel_rc6_disable(rc6);
msleep(1); /* wakeup is not immediate, takes about 100us on icl */
 
+   dt = ktime_get();
+   rc0_power = energy_uJ(rc6);
res[0] = rc6_residency(rc6);
msleep(250);
res[1] = rc6_residency(rc6);
+   rc0_power = div64_u64(NSEC_PER_SEC * (energy_uJ(rc6) - rc0_power),
+ ktime_to_ns(ktime_sub(ktime_get(), dt)));
if ((res[1] - res[0]) >> 10) {
pr_err("RC6 residency increased by %lldus while disabled for 
250ms!\n",
   (res[1] - res[0]) >> 10);
err = -EINVAL;
goto out_unlock;
}
+   if (!rc0_power) {
+   pr_err("No power measured while in RC0\n");
+   err = -EINVAL;
+   goto out_unlock;
+   }
 
/* Manually enter RC6 */
intel_rc6_park(rc6);
 
+   dt = ktime_get();
+   rc6_power = energy_uJ(rc6);
res[0] = rc6_residency(rc6);
msleep(100);
res[1] = rc6_residency(rc6);
+   rc6_power = div64_u64(NSEC_PER_SEC * (energy_uJ(rc6) - rc6_power),
+ ktime_to_ns(ktime_sub(ktime_get(), dt)));
 
if (res[1] == res[0]) {
pr_err("Did not enter RC6! RC6_STATE=%08x, RC6_CONTROL=%08x, 
residency=%lld\n",
@@ -78,6 +109,14 @@ int live_rc6_manual(void *arg)
err = -EINVAL;
}
 
+   pr_info("GPU consumed %llduW in RC0 and %llduW in RC6\n",
+   rc0_power, rc6_power);
+   if ((rc6_power >> 10) > (rc0_power >> 10) / 2) { /* compare mW */
+   pr_err("GPU leaked energy while in RC6!\n");
+   err = -EINVAL;
+   goto out_unlock;
+   }
+
/* Restore what should have been the original state! */
intel_rc6_unpark(rc6);
 
-- 
2.20.1

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


Re: [Intel-gfx] [PATCH] drm/i915/selftests: Measure the energy consumed while in RC6

2020-03-24 Thread Chris Wilson
Quoting Chris Wilson (2020-03-24 20:44:55)
> +   dt = ktime_get();
> +   rc0_power = energy_uJ(rc6);
> res[0] = rc6_residency(rc6);
> msleep(250);
> res[1] = rc6_residency(rc6);
> +   rc0_power = div64_u64(energy_uJ(rc6) - rc0_power,
> + ktime_to_ns(ktime_sub(ktime_get(), dt)));

Did you forget this was in ns? You did!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/6] drm/i915/tc/tgl: Implement TCCOLD sequences

2020-03-24 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/6] drm/i915/tc/tgl: Implement TCCOLD 
sequences
URL   : https://patchwork.freedesktop.org/series/75034/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8183 -> Patchwork_17073


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/index.html

Known issues


  Here are the changes found in Patchwork_17073 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-icl-u2:  [PASS][1] -> [INCOMPLETE][2] ([i915#1185])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/fi-icl-u2/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/fi-icl-u2/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@gtt:
- fi-kbl-soraka:  [PASS][3] -> [INCOMPLETE][4] ([i915#1493])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/fi-kbl-soraka/igt@i915_selftest@l...@gtt.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/fi-kbl-soraka/igt@i915_selftest@l...@gtt.html

  
 Warnings 

  * igt@i915_selftest@live@gem_contexts:
- fi-cfl-guc: [INCOMPLETE][5] ([fdo#106070] / [i915#424]) -> 
[DMESG-FAIL][6] ([i915#481])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17073/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html

  
  [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
  [i915#1185]: https://gitlab.freedesktop.org/drm/intel/issues/1185
  [i915#1493]: https://gitlab.freedesktop.org/drm/intel/issues/1493
  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
  [i915#481]: https://gitlab.freedesktop.org/drm/intel/issues/481


Participating hosts (45 -> 40)
--

  Additional (4): fi-skl-lmem fi-blb-e6850 fi-cfl-8109u fi-kbl-7500u 
  Missing(9): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-cfl-8700k 
fi-ctg-p8600 fi-gdg-551 fi-byt-clapper fi-bsw-nick fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8183 -> Patchwork_17073

  CI-20190529: 20190529
  CI_DRM_8183: 795894daf2cc32246af94541733e08649d082470 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5535: d1dcf40cc6869ac858586c5ad9f09af6617ce2ee @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17073: ae9ffbf9a4cc21805d5481a736c331b8140b4ba9 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ae9ffbf9a4cc drm/i915/dp: Get TC link reference during DP detection
3b031f0ded4f drm/i915/tc/icl: Implement the TC cold exit sequence
4b5d60dcb2a5 drm/i915/display: Add intel_aux_ch_to_power_domain()
bb6945d8d8cf drm/i915/display: Implement intel_display_power_wait_enable_ack()
ca5b103fb97c drm/i915/display: Add intel_display_power_get_without_ack()
125d3dc52b2a drm/i915/tc/tgl: Implement TCCOLD sequences

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/selftests: Measure the energy consumed while in RC6

2020-03-24 Thread Chris Wilson
Measure and compare the energy consumed, as reported by the rapl MSR,
by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
at least halve the energy consumption of RC0, as this more than likely
means we failed to enter RC0 correctly.

If we can't measure the energy draw with the MSR, then it will report 0
for both measurements. Since the measurement works on all gen6+, this seems
worth flagging as an error.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/selftest_rc6.c | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c 
b/drivers/gpu/drm/i915/gt/selftest_rc6.c
index 95b165faeba7..3ac9a8925218 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rc6.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
@@ -12,6 +12,22 @@
 
 #include "selftests/i915_random.h"
 
+#define MCH_SECP_NRG_STTS  _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x592c)
+
+static u64 energy_uJ(struct intel_rc6 *rc6)
+{
+   unsigned long long power;
+   u32 units;
+
+   if (rdmsrl_safe(MSR_RAPL_POWER_UNIT, &power))
+   return 0;
+
+   units = (power & 0x1f00) >> 8;
+   power = intel_uncore_read_fw(rc6_to_uncore(rc6), MCH_SECP_NRG_STTS);
+
+   return (100 * power) >> units; /* convert to uJ */
+}
+
 static u64 rc6_residency(struct intel_rc6 *rc6)
 {
u64 result;
@@ -31,7 +47,9 @@ int live_rc6_manual(void *arg)
 {
struct intel_gt *gt = arg;
struct intel_rc6 *rc6 = >->rc6;
+   u64 rc0_power, rc6_power;
intel_wakeref_t wakeref;
+   ktime_t dt;
u64 res[2];
int err = 0;
 
@@ -53,22 +71,35 @@ int live_rc6_manual(void *arg)
__intel_rc6_disable(rc6);
msleep(1); /* wakeup is not immediate, takes about 100us on icl */
 
+   dt = ktime_get();
+   rc0_power = energy_uJ(rc6);
res[0] = rc6_residency(rc6);
msleep(250);
res[1] = rc6_residency(rc6);
+   rc0_power = div64_u64(energy_uJ(rc6) - rc0_power,
+ ktime_to_ns(ktime_sub(ktime_get(), dt)));
if ((res[1] - res[0]) >> 10) {
pr_err("RC6 residency increased by %lldus while disabled for 
250ms!\n",
   (res[1] - res[0]) >> 10);
err = -EINVAL;
goto out_unlock;
}
+   if (!rc0_power) {
+   pr_err("No power measured while in RC0\n");
+   err = -EINVAL;
+   goto out_unlock;
+   }
 
/* Manually enter RC6 */
intel_rc6_park(rc6);
 
+   dt = ktime_get();
+   rc6_power = energy_uJ(rc6);
res[0] = rc6_residency(rc6);
msleep(100);
res[1] = rc6_residency(rc6);
+   rc6_power = div64_u64(energy_uJ(rc6) - rc6_power,
+ ktime_to_ns(ktime_sub(ktime_get(), dt)));
 
if (res[1] == res[0]) {
pr_err("Did not enter RC6! RC6_STATE=%08x, RC6_CONTROL=%08x, 
residency=%lld\n",
@@ -78,6 +109,14 @@ int live_rc6_manual(void *arg)
err = -EINVAL;
}
 
+   pr_info("GPU consumed %llduW in RC0 and %llduW in RC6\n",
+   rc0_power, rc6_power);
+   if ((rc6_power >> 10) > (rc0_power >> 10) / 2) { /* compare mW */
+   pr_err("GPU leaked energy while in RC6!\n");
+   err = -EINVAL;
+   goto out_unlock;
+   }
+
/* Restore what should have been the original state! */
intel_rc6_unpark(rc6);
 
-- 
2.20.1

___
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 series starting with [v3,1/6] drm/i915/tc/tgl: Implement TCCOLD sequences

2020-03-24 Thread Souza, Jose
On Tue, 2020-03-24 at 20:28 +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v3,1/6] drm/i915/tc/tgl: Implement
> TCCOLD sequences
> URL   : https://patchwork.freedesktop.org/series/75034/
> State : warning
> 
> == Summary ==
> 
> $ dim checkpatch origin/drm-tip
> 125d3dc52b2a drm/i915/tc/tgl: Implement TCCOLD sequences
> ca5b103fb97c drm/i915/display: Add
> intel_display_power_get_without_ack()
> bb6945d8d8cf drm/i915/display: Implement
> intel_display_power_wait_enable_ack()
> 4b5d60dcb2a5 drm/i915/display: Add intel_aux_ch_to_power_domain()
> 3b031f0ded4f drm/i915/tc/icl: Implement the TC cold exit sequence
> -:161: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see
> Documentation/timers/timers-howto.rst
> #161: FILE: drivers/gpu/drm/i915/display/intel_tc.c:549:
> + msleep(1);

Left as is on purpose a x86 is usually configured as tickless and even
when not it supports HZ=1000 that matches 1ms.

> 
> total: 0 errors, 1 warnings, 0 checks, 166 lines checked
> ae9ffbf9a4cc drm/i915/dp: Get TC link reference during DP detection
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm: manage drm_minor cleanup with drmm_

2020-03-24 Thread Daniel Vetter
The cleanup here is somewhat tricky, since we can't tell apart the
allocated minor index from 0. So register a cleanup action first, and
if the index allocation fails, unregister that cleanup action again to
avoid bad mistakes.

The kdev for the minor already handles NULL, so no problem there.

Hence add drmm_remove_action() to the drm_managed library.

v2: Make pointer math around void ** consistent with what Laurent
suggested.

v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed
because of some questions from Thomas. This also means we need to move
the drmm_add_action_or_reset helper earlier in the series.

v4: Uh ... fix slightly embarrassing bug CI spotted.

Cc: Thomas Zimmermann 
Cc: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_drv.c | 69 ---
 drivers/gpu/drm/drm_managed.c | 14 +++
 include/drm/drm_managed.h |  9 -
 3 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a710c53d13a8..50c56ff24c71 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -93,13 +93,25 @@ static struct drm_minor **drm_minor_get_slot(struct 
drm_device *dev,
}
 }
 
+static void drm_minor_alloc_release(struct drm_device *dev, void *data)
+{
+   struct drm_minor *minor = data;
+   unsigned long flags;
+
+   put_device(minor->kdev);
+
+   spin_lock_irqsave(&drm_minor_lock, flags);
+   idr_remove(&drm_minors_idr, minor->index);
+   spin_unlock_irqrestore(&drm_minor_lock, flags);
+}
+
 static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
 {
struct drm_minor *minor;
unsigned long flags;
int r;
 
-   minor = kzalloc(sizeof(*minor), GFP_KERNEL);
+   minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
if (!minor)
return -ENOMEM;
 
@@ -117,46 +129,20 @@ static int drm_minor_alloc(struct drm_device *dev, 
unsigned int type)
idr_preload_end();
 
if (r < 0)
-   goto err_free;
+   return r;
 
minor->index = r;
 
+   r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
+   if (r)
+   return r;
+
minor->kdev = drm_sysfs_minor_alloc(minor);
-   if (IS_ERR(minor->kdev)) {
-   r = PTR_ERR(minor->kdev);
-   goto err_index;
-   }
+   if (IS_ERR(minor->kdev))
+   return PTR_ERR(minor->kdev);
 
*drm_minor_get_slot(dev, type) = minor;
return 0;
-
-err_index:
-   spin_lock_irqsave(&drm_minor_lock, flags);
-   idr_remove(&drm_minors_idr, minor->index);
-   spin_unlock_irqrestore(&drm_minor_lock, flags);
-err_free:
-   kfree(minor);
-   return r;
-}
-
-static void drm_minor_free(struct drm_device *dev, unsigned int type)
-{
-   struct drm_minor **slot, *minor;
-   unsigned long flags;
-
-   slot = drm_minor_get_slot(dev, type);
-   minor = *slot;
-   if (!minor)
-   return;
-
-   put_device(minor->kdev);
-
-   spin_lock_irqsave(&drm_minor_lock, flags);
-   idr_remove(&drm_minors_idr, minor->index);
-   spin_unlock_irqrestore(&drm_minor_lock, flags);
-
-   kfree(minor);
-   *slot = NULL;
 }
 
 static int drm_minor_register(struct drm_device *dev, unsigned int type)
@@ -678,16 +664,16 @@ int drm_dev_init(struct drm_device *dev,
if (drm_core_check_feature(dev, DRIVER_RENDER)) {
ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
if (ret)
-   goto err_minors;
+   goto err;
}
 
ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
if (ret)
-   goto err_minors;
+   goto err;
 
ret = drm_legacy_create_map_hash(dev);
if (ret)
-   goto err_minors;
+   goto err;
 
drm_legacy_ctxbitmap_init(dev);
 
@@ -695,7 +681,7 @@ int drm_dev_init(struct drm_device *dev,
ret = drm_gem_init(dev);
if (ret) {
DRM_ERROR("Cannot initialize graphics execution manager 
(GEM)\n");
-   goto err_ctxbitmap;
+   goto err;
}
}
 
@@ -708,10 +694,6 @@ int drm_dev_init(struct drm_device *dev,
 err_setunique:
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_destroy(dev);
-err_ctxbitmap:
-err_minors:
-   drm_minor_free(dev, DRM_MINOR_PRIMARY);
-   drm_minor_free(dev, DRM_MINOR_RENDER);
 err:
drm_managed_release(dev);
 
@@ -776,9 +758,6 @@ void drm_dev_fini(struct drm_device *dev)
 
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_destroy(dev);
-
-   drm_minor_free(dev, DRM_MINOR_PRIMARY);
-   drm_minor_free(dev, DRM_MINOR_RENDER);
 }
 EXPORT_SYMBOL(drm_dev_fini);
 
diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/d

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/6] drm/i915/tc/tgl: Implement TCCOLD sequences

2020-03-24 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/6] drm/i915/tc/tgl: Implement TCCOLD 
sequences
URL   : https://patchwork.freedesktop.org/series/75034/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
125d3dc52b2a drm/i915/tc/tgl: Implement TCCOLD sequences
ca5b103fb97c drm/i915/display: Add intel_display_power_get_without_ack()
bb6945d8d8cf drm/i915/display: Implement intel_display_power_wait_enable_ack()
4b5d60dcb2a5 drm/i915/display: Add intel_aux_ch_to_power_domain()
3b031f0ded4f drm/i915/tc/icl: Implement the TC cold exit sequence
-:161: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.rst
#161: FILE: drivers/gpu/drm/i915/display/intel_tc.c:549:
+   msleep(1);

total: 0 errors, 1 warnings, 0 checks, 166 lines checked
ae9ffbf9a4cc drm/i915/dp: Get TC link reference during DP detection

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


[Intel-gfx] [PATCH] drm/i915/selftests: Measure the energy consumed while in RC6

2020-03-24 Thread Chris Wilson
Measure and compare the energy consumed, as reported by the rapl MSR,
by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
at least halve the energy consumption of RC0, as this more than likely
means we failed to enter RC0 correctly.

If we can't measure the energy draw with the MSR, then it will report 0
for both measurements. This may be worth flagging as a warning? On the
other hand, it is reported and we can inspect the various machines in CI
to see if the values are reasonable.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/selftest_rc6.c | 29 ++
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c 
b/drivers/gpu/drm/i915/gt/selftest_rc6.c
index 95b165faeba7..7339758b0c77 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rc6.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
@@ -12,6 +12,22 @@
 
 #include "selftests/i915_random.h"
 
+#define MCH_SECP_NRG_STTS  _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x592c)
+
+static u64 energy_uJ(struct intel_rc6 *rc6)
+{
+   unsigned long long power;
+   u32 units;
+
+   if (rdmsrl_safe(MSR_RAPL_POWER_UNIT, &power))
+   return 0;
+
+   units = (power & 0x1f00) >> 8;
+   power = intel_uncore_read_fw(rc6_to_uncore(rc6), MCH_SECP_NRG_STTS);
+
+   return (100 * power) >> units; /* convert to uJ */
+}
+
 static u64 rc6_residency(struct intel_rc6 *rc6)
 {
u64 result;
@@ -31,6 +47,7 @@ int live_rc6_manual(void *arg)
 {
struct intel_gt *gt = arg;
struct intel_rc6 *rc6 = >->rc6;
+   u64 rc0_energy, rc6_energy;
intel_wakeref_t wakeref;
u64 res[2];
int err = 0;
@@ -53,9 +70,11 @@ int live_rc6_manual(void *arg)
__intel_rc6_disable(rc6);
msleep(1); /* wakeup is not immediate, takes about 100us on icl */
 
+   rc0_energy = -energy_uJ(rc6);
res[0] = rc6_residency(rc6);
msleep(250);
res[1] = rc6_residency(rc6);
+   rc0_energy += energy_uJ(rc6);
if ((res[1] - res[0]) >> 10) {
pr_err("RC6 residency increased by %lldus while disabled for 
250ms!\n",
   (res[1] - res[0]) >> 10);
@@ -66,9 +85,11 @@ int live_rc6_manual(void *arg)
/* Manually enter RC6 */
intel_rc6_park(rc6);
 
+   rc6_energy = -energy_uJ(rc6);
res[0] = rc6_residency(rc6);
msleep(100);
res[1] = rc6_residency(rc6);
+   rc6_energy += energy_uJ(rc6);
 
if (res[1] == res[0]) {
pr_err("Did not enter RC6! RC6_STATE=%08x, RC6_CONTROL=%08x, 
residency=%lld\n",
@@ -78,6 +99,14 @@ int live_rc6_manual(void *arg)
err = -EINVAL;
}
 
+   pr_info("GPU consumed %llduJ in RC0 and %llduJ in RC6\n",
+   rc0_energy, rc6_energy);
+   if ((rc6_energy >> 10) > (rc0_energy >> 10) / 2) { /* compare mJ */
+   pr_err("GPU leaked energy while in RC6!\n");
+   err = -EINVAL;
+   goto out_unlock;
+   }
+
/* Restore what should have been the original state! */
intel_rc6_unpark(rc6);
 
-- 
2.20.1

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


[Intel-gfx] [PATCH v3 2/6] drm/i915/display: Add intel_display_power_get_without_ack()

2020-03-24 Thread José Roberto de Souza
To implement ICL TC static sequences is required to get the port aux
powerwell without wait for hardware ack.

Cc: Imre Deak 
Cc: Cooper Chiou 
Cc: Kai-Heng Feng 
Signed-off-by: José Roberto de Souza 
---
 .../drm/i915/display/intel_display_power.c| 71 +++
 .../drm/i915/display/intel_display_power.h| 12 
 2 files changed, 71 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 246e406bb385..9035b220dfa0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -157,14 +157,24 @@ intel_display_power_domain_str(enum 
intel_display_power_domain domain)
}
 }
 
-static void intel_power_well_enable(struct drm_i915_private *dev_priv,
-   struct i915_power_well *power_well)
+static void _intel_power_well_enable(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well,
+bool wait_ack)
 {
drm_dbg_kms(&dev_priv->drm, "enabling %s\n", power_well->desc->name);
-   power_well->desc->ops->enable(dev_priv, power_well);
+   if (wait_ack || !power_well->desc->ops->enable_without_ack)
+   power_well->desc->ops->enable(dev_priv, power_well);
+   else
+   power_well->desc->ops->enable_without_ack(dev_priv, power_well);
power_well->hw_enabled = true;
 }
 
+static void intel_power_well_enable(struct drm_i915_private *dev_priv,
+   struct i915_power_well *power_well)
+{
+   _intel_power_well_enable(dev_priv, power_well, true);
+}
+
 static void intel_power_well_disable(struct drm_i915_private *dev_priv,
 struct i915_power_well *power_well)
 {
@@ -174,10 +184,11 @@ static void intel_power_well_disable(struct 
drm_i915_private *dev_priv,
 }
 
 static void intel_power_well_get(struct drm_i915_private *dev_priv,
-struct i915_power_well *power_well)
+struct i915_power_well *power_well,
+bool wait_ack)
 {
if (!power_well->count++)
-   intel_power_well_enable(dev_priv, power_well);
+   _intel_power_well_enable(dev_priv, power_well, wait_ack);
 }
 
 static void intel_power_well_put(struct drm_i915_private *dev_priv,
@@ -353,8 +364,9 @@ static void gen9_wait_for_power_well_fuses(struct 
drm_i915_private *dev_priv,
  SKL_FUSE_PG_DIST_STATUS(pg), 1));
 }
 
-static void hsw_power_well_enable(struct drm_i915_private *dev_priv,
- struct i915_power_well *power_well)
+static void _hsw_power_well_enable(struct drm_i915_private *dev_priv,
+  struct i915_power_well *power_well,
+  bool wait_ack)
 {
const struct i915_power_well_regs *regs = power_well->desc->hsw.regs;
int pw_idx = power_well->desc->hsw.idx;
@@ -379,7 +391,8 @@ static void hsw_power_well_enable(struct drm_i915_private 
*dev_priv,
val = intel_de_read(dev_priv, regs->driver);
intel_de_write(dev_priv, regs->driver,
   val | HSW_PWR_WELL_CTL_REQ(pw_idx));
-   hsw_wait_for_power_well_enable(dev_priv, power_well);
+   if (wait_ack)
+   hsw_wait_for_power_well_enable(dev_priv, power_well);
 
/* Display WA #1178: cnl */
if (IS_CANNONLAKE(dev_priv) &&
@@ -398,6 +411,12 @@ static void hsw_power_well_enable(struct drm_i915_private 
*dev_priv,
   power_well->desc->hsw.has_vga);
 }
 
+static void hsw_power_well_enable(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
+{
+   _hsw_power_well_enable(dev_priv, power_well, true);
+}
+
 static void hsw_power_well_disable(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well)
 {
@@ -1960,7 +1979,8 @@ intel_display_power_grab_async_put_ref(struct 
drm_i915_private *dev_priv,
 
 static void
 __intel_display_power_get_domain(struct drm_i915_private *dev_priv,
-enum intel_display_power_domain domain)
+enum intel_display_power_domain domain,
+bool wait_ack)
 {
struct i915_power_domains *power_domains = &dev_priv->power_domains;
struct i915_power_well *power_well;
@@ -1969,7 +1989,7 @@ __intel_display_power_get_domain(struct drm_i915_private 
*dev_priv,
return;
 
for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain))
-   intel_power_well_get(dev_priv, power_well);
+   intel_power_well_get(dev_priv, power_well, wait_ack);
 
power_domains->domain_use_count[domain

[Intel-gfx] [PATCH v3 5/6] drm/i915/tc/icl: Implement the TC cold exit sequence

2020-03-24 Thread José Roberto de Souza
This is required for legacy/static TC ports as IOM is not aware of
the connection and will not trigger the TC cold exit.

Just request PCODE to exit TCCOLD is not enough as it could enter
again be driver makes use of the port, to prevent it BSpec states that
aux powerwell should be held.

So before detecting the mode, aux power is requested without wait for
hardware ack, PCODE is requested to exit TCCOLD and the TC detection
sequences follows as normal.
After detection if mode is not static aux can be powered off otherwise
we need to wait for HW ack as future calls to intel_display_power_get()
over aux will not check for HW ack.

v2:
- fixed typo tc_lock_wakeref to tc_cold_wakeref in icl_tc_cold_request()

v3:
- fixed non initialized ret in icl_tc_cold_request()
- added missing sleep step, initially it was not added because I
thought that the aux enable and then HW ack wait would take care of
that but that is not the case

BSpec: 21750
Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1296
Cc: Imre Deak 
Cc: Cooper Chiou 
Cc: Kai-Heng Feng 
Signed-off-by: José Roberto de Souza 
---
 .../drm/i915/display/intel_display_power.c| 30 +-
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_tc.c   | 60 +--
 drivers/gpu/drm/i915/i915_reg.h   |  1 +
 4 files changed, 84 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index a7e531b64e16..71a4c5d790ea 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -573,8 +573,9 @@ static void icl_tc_port_assert_ref_held(struct 
drm_i915_private *dev_priv,
 #define TGL_AUX_PW_TO_TC_PORT(pw_idx)  ((pw_idx) - TGL_PW_CTL_IDX_AUX_TC1)
 
 static void
-icl_tc_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
-struct i915_power_well *power_well)
+_icl_tc_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well,
+ bool wait_ack)
 {
enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
u32 val;
@@ -587,7 +588,7 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private 
*dev_priv,
val |= DP_AUX_CH_CTL_TBT_IO;
intel_de_write(dev_priv, DP_AUX_CH_CTL(aux_ch), val);
 
-   hsw_power_well_enable(dev_priv, power_well);
+   _hsw_power_well_enable(dev_priv, power_well, wait_ack);
 
if (INTEL_GEN(dev_priv) >= 12 && !power_well->desc->hsw.is_tc_tbt) {
enum tc_port tc_port;
@@ -603,6 +604,20 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private 
*dev_priv,
}
 }
 
+static void
+icl_tc_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+   _icl_tc_phy_aux_power_well_enable(dev_priv, power_well, true);
+}
+
+static void
+icl_tc_phy_aux_power_well_enable_without_ack(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+   _icl_tc_phy_aux_power_well_enable(dev_priv, power_well, false);
+}
+
 static void
 icl_tc_phy_aux_power_well_disable(struct drm_i915_private *dev_priv,
  struct i915_power_well *power_well)
@@ -642,6 +657,13 @@ static bool hsw_power_well_enabled(struct drm_i915_private 
*dev_priv,
return (val & mask) == mask;
 }
 
+static void
+hsw_power_well_wait_ack(struct drm_i915_private *dev_priv,
+   struct i915_power_well *power_well)
+{
+   hsw_wait_for_power_well_enable(dev_priv, power_well);
+}
+
 static void assert_can_enable_dc9(struct drm_i915_private *dev_priv)
 {
drm_WARN_ONCE(&dev_priv->drm,
@@ -3582,8 +3604,10 @@ static const struct i915_power_well_ops 
icl_combo_phy_aux_power_well_ops = {
 static const struct i915_power_well_ops icl_tc_phy_aux_power_well_ops = {
.sync_hw = hsw_power_well_sync_hw,
.enable = icl_tc_phy_aux_power_well_enable,
+   .enable_without_ack = icl_tc_phy_aux_power_well_enable_without_ack,
.disable = icl_tc_phy_aux_power_well_disable,
.is_enabled = hsw_power_well_enabled,
+   .wait_enable_ack = hsw_power_well_wait_ack,
 };
 
 static const struct i915_power_well_regs icl_aux_power_well_regs = {
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 176ab5f1e867..42954be80435 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1397,6 +1397,7 @@ struct intel_digital_port {
enum tc_port_mode tc_mode;
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
+   intel_wakeref_t tc_cold_wakeref;
 
void (*write_infoframe)(struct intel_encoder *encoder,
   

[Intel-gfx] [PATCH v3 6/6] drm/i915/dp: Get TC link reference during DP detection

2020-03-24 Thread José Roberto de Souza
As now the cost to lock and use a TC port is higher due the
implementation of the TCCOLD sequences it is worty to hold a reference
of the TC port to avoid all this locking at every aux transaction
part of the DisplayPort detection.

Cc: Imre Deak 
Cc: Cooper Chiou 
Cc: Kai-Heng Feng 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7f1a4e55cda1..6fbf3beee544 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6041,6 +6041,7 @@ intel_dp_detect(struct drm_connector *connector,
struct intel_dp *intel_dp = 
intel_attached_dp(to_intel_connector(connector));
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = &dig_port->base;
+   enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
enum drm_connector_status status;
 
drm_dbg_kms(&dev_priv->drm, "[CONNECTOR:%d:%s]\n",
@@ -6049,12 +6050,17 @@ intel_dp_detect(struct drm_connector *connector,

!drm_modeset_is_locked(&dev_priv->drm.mode_config.connection_mutex));
 
/* Can't disconnect eDP */
-   if (intel_dp_is_edp(intel_dp))
+   if (intel_dp_is_edp(intel_dp)) {
status = edp_detect(intel_dp);
-   else if (intel_digital_port_connected(encoder))
-   status = intel_dp_detect_dpcd(intel_dp);
-   else
-   status = connector_status_disconnected;
+   } else {
+   if (intel_phy_is_tc(dev_priv, phy))
+   intel_tc_port_get_link(dig_port, 1);
+
+   if (intel_digital_port_connected(encoder))
+   status = intel_dp_detect_dpcd(intel_dp);
+   else
+   status = connector_status_disconnected;
+   }
 
if (status == connector_status_disconnected) {
memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
@@ -6132,6 +6138,9 @@ intel_dp_detect(struct drm_connector *connector,
if (status != connector_status_connected && !intel_dp->is_mst)
intel_dp_unset_edid(intel_dp);
 
+   if (intel_phy_is_tc(dev_priv, phy))
+   intel_tc_port_put_link(dig_port);
+
/*
 * Make sure the refs for power wells enabled during detect are
 * dropped to avoid a new detect cycle triggered by HPD polling.
-- 
2.26.0

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


[Intel-gfx] [PATCH v3 4/6] drm/i915/display: Add intel_aux_ch_to_power_domain()

2020-03-24 Thread José Roberto de Souza
This is a similar function to intel_aux_power_domain() but it do not
care about TBT ports, this will be needed by GEN11 TC sequences.

Cc: Imre Deak 
Cc: Cooper Chiou 
Cc: Kai-Heng Feng 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.c | 14 --
 drivers/gpu/drm/i915/display/intel_display.h |  2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 37bd7ce88ecd..bda35c1337de 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7312,7 +7312,17 @@ intel_aux_power_domain(struct intel_digital_port 
*dig_port)
}
}
 
-   switch (dig_port->aux_ch) {
+   return intel_aux_ch_to_power_domain(dig_port->aux_ch);
+}
+
+/*
+ * Converts aux_ch to power_domain without caring about TBT ports for that use
+ * intel_aux_power_domain()
+ */
+enum intel_display_power_domain
+intel_aux_ch_to_power_domain(enum aux_ch aux_ch)
+{
+   switch (aux_ch) {
case AUX_CH_A:
return POWER_DOMAIN_AUX_A;
case AUX_CH_B:
@@ -7328,7 +7338,7 @@ intel_aux_power_domain(struct intel_digital_port 
*dig_port)
case AUX_CH_G:
return POWER_DOMAIN_AUX_G;
default:
-   MISSING_CASE(dig_port->aux_ch);
+   MISSING_CASE(aux_ch);
return POWER_DOMAIN_AUX_A;
}
 }
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index adb1225a3480..ad50119c0453 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -579,6 +579,8 @@ void hsw_disable_ips(const struct intel_crtc_state 
*crtc_state);
 enum intel_display_power_domain intel_port_to_power_domain(enum port port);
 enum intel_display_power_domain
 intel_aux_power_domain(struct intel_digital_port *dig_port);
+enum intel_display_power_domain
+intel_aux_ch_to_power_domain(enum aux_ch aux_ch);
 void intel_mode_from_pipe_config(struct drm_display_mode *mode,
 struct intel_crtc_state *pipe_config);
 void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
-- 
2.26.0

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


[Intel-gfx] [PATCH v3 3/6] drm/i915/display: Implement intel_display_power_wait_enable_ack()

2020-03-24 Thread José Roberto de Souza
This function is meant to be used after
intel_display_power_get_without_ack() this way we can be sure that the
HW tied to the powerdomain will be powered and ready.

Cc: Imre Deak 
Cc: Cooper Chiou 
Cc: Kai-Heng Feng 
Signed-off-by: José Roberto de Souza 
---
 .../drm/i915/display/intel_display_power.c| 29 +++
 .../drm/i915/display/intel_display_power.h|  9 ++
 2 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 9035b220dfa0..a7e531b64e16 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -2328,6 +2328,35 @@ intel_display_power_flush_work_sync(struct 
drm_i915_private *i915)
drm_WARN_ON(&i915->drm, power_domains->async_put_wakeref);
 }
 
+/**
+ * intel_display_power_wait_enable_ack - wait for enabled hardware ack
+ * @dev_priv: i915 device instance
+ * @domain: power domain to reference
+ *
+ * This function must be called after intel_display_power_get_without_ack() and
+ * only in power domains that implements it.
+ */
+void intel_display_power_wait_enable_ack(struct drm_i915_private *dev_priv,
+enum intel_display_power_domain domain)
+{
+   struct i915_power_domains *power_domains = &dev_priv->power_domains;
+   struct i915_power_well *power_well;
+
+   mutex_lock(&power_domains->lock);
+
+   for_each_power_domain_well_reverse(dev_priv, power_well,
+  BIT_ULL(domain)) {
+   if (drm_WARN_ON(&dev_priv->drm,
+   !power_well->desc->ops->wait_enable_ack))
+   break;
+
+   power_well->desc->ops->wait_enable_ack(dev_priv, power_well);
+   break;
+   }
+
+   mutex_unlock(&power_domains->lock);
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
 /**
  * intel_display_power_put - release a power domain reference
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h 
b/drivers/gpu/drm/i915/display/intel_display_power.h
index 5db86cc862c3..108096177deb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -148,6 +148,13 @@ struct i915_power_well_ops {
/* Returns the hw enabled state. */
bool (*is_enabled)(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well);
+
+   /*
+* Waits for hardware enabling ack, this is meant to be used together
+* with enable_without_ack() and also optional.
+*/
+   void (*wait_enable_ack)(struct drm_i915_private *dev_priv,
+   struct i915_power_well *power_well);
 };
 
 struct i915_power_well_regs {
@@ -291,6 +298,8 @@ void __intel_display_power_put_async(struct 
drm_i915_private *i915,
 enum intel_display_power_domain domain,
 intel_wakeref_t wakeref);
 void intel_display_power_flush_work(struct drm_i915_private *i915);
+void intel_display_power_wait_enable_ack(struct drm_i915_private *dev_priv,
+enum intel_display_power_domain 
domain);
 #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
 void intel_display_power_put(struct drm_i915_private *dev_priv,
 enum intel_display_power_domain domain,
-- 
2.26.0

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


[Intel-gfx] [PATCH v3 1/6] drm/i915/tc/tgl: Implement TCCOLD sequences

2020-03-24 Thread José Roberto de Souza
TC ports can enter in TCCOLD to save power and is required to request
to PCODE to exit this state before use or read to TC registers.

For TGL there is a new MBOX command to do that with a parameter to ask
PCODE to exit and block TCCOLD entry or unblock TCCOLD entry.
For GEN11 the sequence is more complex and will be handled in a
separated patch.

BSpec: 49294
Cc: Imre Deak 
Cc: Cooper Chiou 
Cc: Kai-Heng Feng 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_tc.c | 61 -
 drivers/gpu/drm/i915/i915_reg.h |  3 ++
 drivers/gpu/drm/i915/intel_sideband.c   | 22 +
 drivers/gpu/drm/i915/intel_sideband.h   |  4 ++
 4 files changed, 88 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 9b850c11aa78..e4c5de5ce874 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -7,6 +7,7 @@
 #include "intel_display.h"
 #include "intel_display_types.h"
 #include "intel_dp_mst.h"
+#include "intel_sideband.h"
 #include "intel_tc.h"
 
 static const char *tc_port_mode_name(enum tc_port_mode mode)
@@ -496,6 +497,55 @@ bool intel_tc_port_connected(struct intel_digital_port 
*dig_port)
return is_connected;
 }
 
+static inline int tgl_tc_cold_request(struct intel_digital_port *dig_port,
+ bool block)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   u32 low_val, high_val;
+   u8 tries = 0;
+   int ret;
+
+   do {
+   low_val = 0;
+   high_val = block ? 0 : TGL_PCODE_EXIT_TCCOLD_DATA_H_UNBLOCK_REQ;
+
+   ret = sandybridge_pcode_write_read_timeout(i915,
+  TGL_PCODE_TCCOLD,
+  &low_val, &high_val,
+  150, 1);
+   if (ret == 0) {
+   if (block &&
+   low_val & TGL_PCODE_EXIT_TCCOLD_DATA_L_EXIT_FAILED)
+   ret = -EIO;
+   else
+   break;
+   }
+
+   if (ret != -EAGAIN)
+   tries++;
+   } while (tries < 3);
+
+   return ret;
+}
+
+static int tc_cold_request(struct intel_digital_port *dig_port, bool block)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   int ret;
+
+   if (INTEL_GEN(i915) >= 12)
+   ret = tgl_tc_cold_request(dig_port, block);
+   else
+   /* TODO: implement GEN11 TCCOLD sequences */
+   ret = 0;
+
+   drm_dbg_kms(&i915->drm, "Port %s: TCCOLD %sblock %s\n",
+   dig_port->tc_port_name, (block ? "" : "un"),
+   (ret == 0 ? "succeeded" : "failed"));
+
+   return ret;
+}
+
 static void __intel_tc_port_lock(struct intel_digital_port *dig_port,
 int required_lanes)
 {
@@ -506,9 +556,11 @@ static void __intel_tc_port_lock(struct intel_digital_port 
*dig_port,
 
mutex_lock(&dig_port->tc_lock);
 
-   if (!dig_port->tc_link_refcount &&
-   intel_tc_port_needs_reset(dig_port))
+   if (dig_port->tc_link_refcount == 0) {
+   tc_cold_request(dig_port, true);
+   intel_tc_port_needs_reset(dig_port);
intel_tc_port_reset_mode(dig_port, required_lanes);
+   }
 
drm_WARN_ON(&i915->drm, dig_port->tc_lock_wakeref);
dig_port->tc_lock_wakeref = wakeref;
@@ -524,6 +576,9 @@ void intel_tc_port_unlock(struct intel_digital_port 
*dig_port)
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
intel_wakeref_t wakeref = fetch_and_zero(&dig_port->tc_lock_wakeref);
 
+   if (dig_port->tc_link_refcount == 0)
+   tc_cold_request(dig_port, false);
+
mutex_unlock(&dig_port->tc_lock);
 
intel_display_power_put_async(i915, POWER_DOMAIN_DISPLAY_CORE,
@@ -548,6 +603,8 @@ void intel_tc_port_put_link(struct intel_digital_port 
*dig_port)
 {
mutex_lock(&dig_port->tc_lock);
dig_port->tc_link_refcount--;
+   if (dig_port->tc_link_refcount == 0)
+   tc_cold_request(dig_port, false);
mutex_unlock(&dig_port->tc_lock);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c53fe918be6..7e341d9945b3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9019,6 +9019,9 @@ enum {
 #define   GEN6_PCODE_WRITE_D_COMP  0x11
 #define   HSW_PCODE_DE_WRITE_FREQ_REQ  0x17
 #define   DISPLAY_IPS_CONTROL  0x19
+#define   TGL_PCODE_TCCOLD 0x26
+#define TGL_PCODE_EXIT_TCCOLD_DATA_L_EXIT_FAILED   REG_BIT(0)
+#define TGL_PCODE_EXIT_TCCOLD_DATA_H_UNBLOCK_REQ  

Re: [Intel-gfx] [RFC] GPU-bound energy efficiency improvements for the intel_pstate driver (v2).

2020-03-24 Thread Pandruvada, Srinivas
On Tue, 2020-03-24 at 12:16 -0700, Francisco Jerez wrote:
> Francisco Jerez  writes:
> 
> > "Pandruvada, Srinivas"  writes:
> > 
> > > Hi Francisco,
> > > 
> > > On Tue, 2020-03-10 at 14:41 -0700, Francisco Jerez wrote:
> > > > This is my second take on improving the energy efficiency of
> > > > the
> > > > intel_pstate driver under IO-bound conditions.  The problem and
> > > > approach to solve it are roughly the same as in my previous
> > > > series
> > > > [1]
> > > > at a high level:
> > > > 
> > > > In IO-bound scenarios (by definition) the throughput of the
> > > > system
> > > > doesn't improve with increasing CPU frequency beyond the
> > > > threshold
> > > > value at which the IO device becomes the bottleneck, however
> > > > with the
> > > > current governors (whether HWP is in use or not) the CPU
> > > > frequency
> > > > tends to oscillate with the load, often with an amplitude far
> > > > into
> > > > the
> > > > turbo range, leading to severely reduced energy efficiency,
> > > > which is
> > > > particularly problematic when a limited TDP budget is shared
> > > > among a
> > > > number of cores running some multithreaded workload, or among a
> > > > CPU
> > > > core and an integrated GPU.
> > > > 
> > > > Improving the energy efficiency of the CPU improves the
> > > > throughput of
> > > > the system in such TDP-limited conditions.  See [4] for some
> > > > preliminary benchmark results from a Razer Blade Stealth 13
> > > > Late
> > > > 2019/LY320 laptop with an Intel ICL processor and integrated
> > > > graphics,
> > > > including throughput results that range up to a ~15%
> > > > improvement and
> > > > performance-per-watt results up to a ~43% improvement
> > > > (estimated via
> > > > RAPL).  Particularly the throughput results may vary
> > > > substantially
> > > > from one platform to another depending on the TDP budget and
> > > > the
> > > > balance of load between CPU and GPU.
> > > > 
> > > 
> > > You changed the EPP to 0 intentionally or unintentionally. We
> > > know that
> > > all energy optimization will be disabled with this change. 
> > > This test was done on an ICL system.
> > > 
> > 
> > Hmm, that's bad, and fully unintentional.  It's probably a side
> > effect
> > of intel_pstate_reset_vlp() running before intel_pstate_hwp_set(),
> > which
> > could cause it to use an uninitialized value of hwp_req_cached
> > (zero?).
> > I'll fix it in v3.  Thanks a lot for pointing this out.
> > 
> 
> Sigh.  That means that the performance results I got were
> inadvertently
> obtained while using an EPP setting of "performance" (!).  That's
> unlikely to be the case in most systems but still kind of meaningful.
We know that  "performance" mode is not great for workloads which
depends on some power sharing.

Thanks,
Srinivas 

> Need to get updated performance numbers with EPP=0x80 -- The larger
> up
> to ~40% energy efficiency improvements still seem to be visible
> regardless, but the throughput benefit is likely to be lower than
> with
> EPP=0.
> 
> > > Basically without your patches on top of linux-next: EPP = 0x80
> > > $sudo rdmsr -a 0x774
> > > 80002704
> > > 80002704
> > > 80002704
> > > 80002704
> > > 80002704
> > > 80002704
> > > 80002704
> > > 80002704
> > > 
> > > 
> > > After your patches
> > > 
> > > $sudo rdmsr -a 0x774
> > > 2704
> > > 2704
> > > 2704
> > > 2704
> > > 2704
> > > 2704
> > > 2704
> > > 2704
> > > 
> > > I added some prints, basically you change the EPP at startup
> > > before
> > > regular HWP request update path and update on top. So boot up EPP
> > > is
> > > overwritten.
> > > 
> > > 
> > > [5.867476] intel_pstate_reset_vlp hwp_req cached:0
> > > [5.872426] intel_pstate_reset_vlp hwp_req:404
> > > [5.881645] intel_pstate_reset_vlp hwp_req cached:0
> > > [5.886634] intel_pstate_reset_vlp hwp_req:404
> > > [5.895819] intel_pstate_reset_vlp hwp_req cached:0
> > > [5.900958] intel_pstate_reset_vlp hwp_req:404
> > > [5.910321] intel_pstate_reset_vlp hwp_req cached:0
> > > [5.915406] intel_pstate_reset_vlp hwp_req:404
> > > [5.924623] intel_pstate_reset_vlp hwp_req cached:0
> > > [5.929564] intel_pstate_reset_vlp hwp_req:404
> > > [5.944039] intel_pstate_reset_vlp hwp_req cached:0
> > > [5.951672] intel_pstate_reset_vlp hwp_req:404
> > > [5.966157] intel_pstate_reset_vlp hwp_req cached:0
> > > [5.973808] intel_pstate_reset_vlp hwp_req:404
> > > [5.988223] intel_pstate_reset_vlp hwp_req cached:0
> > > [5.995823] intel_pstate_reset_vlp hwp_req:404
> > > [6.010062] intel_pstate: HWP enabled
> > > 
> > > Thanks,
> > > Srinivas
> > > 
> > > 
> > > 
> > > > One of the main differences relative to my previous version is
> > > > that
> > > > the trade-off between energy efficiency and frequency ramp-up
> > > > latency
> > > > is now exposed to device drivers through a new PM QoS class [It
> > > > would
> > > > make sense to expose it to userspace too eventually but that's
> > > > beyond
> > > > the pur

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: add OA interrupt support (rev8)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm/i915/perf: add OA interrupt support (rev8)
URL   : https://patchwork.freedesktop.org/series/54280/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8183 -> Patchwork_17072


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/index.html

Known issues


  Here are the changes found in Patchwork_17072 that come from known issues:

### IGT changes ###

 Warnings 

  * igt@i915_selftest@live@gem_contexts:
- fi-cfl-guc: [INCOMPLETE][1] ([fdo#106070] / [i915#424]) -> 
[DMESG-FAIL][2] ([i915#943])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17072/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html

  
  [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
  [i915#943]: https://gitlab.freedesktop.org/drm/intel/issues/943


Participating hosts (45 -> 42)
--

  Additional (5): fi-kbl-7560u fi-kbl-7500u fi-cfl-8109u fi-skl-lmem 
fi-blb-e6850 
  Missing(8): fi-hsw-4770r fi-hsw-4200u fi-hsw-peppy fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8183 -> Patchwork_17072

  CI-20190529: 20190529
  CI_DRM_8183: 795894daf2cc32246af94541733e08649d082470 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5535: d1dcf40cc6869ac858586c5ad9f09af6617ce2ee @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17072: 72aa75eecb08b19d17cd766043dc0d2ccbbba8f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

72aa75eecb08 drm/i915/perf: add new open param to configure polling of OA buffer
8216331a9ceb drm/i915/perf: move pollin setup to non hw specific code
2dbd12eaa63c drm/i915/perf: rework aging tail workaround

== Logs ==

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


Re: [Intel-gfx] [PATCH 07/12] dma-buf: Proxy fence, an unsignaled fence placeholder

2020-03-24 Thread kbuild test robot
Hi Chris,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next linus/master v5.6-rc7 next-20200324]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-selftests-Add-request-throughput-measurement-to-perf/20200324-043904
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-b003-20200324 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
94cacebccadf1e0821bdab6983d9f5251f73eab0)
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All warnings (new ones prefixed by >>):

   In file included from drivers/dma-buf/dma-fence.c:22:
>> drivers/dma-buf/dma-fence-private.h:13:9: warning: 'DMA_FENCE_PRIVATE_H' is 
>> used as a header guard here, followed by #define of a different macro 
>> [-Wheader-guard]
   #ifndef DMA_FENCE_PRIVATE_H
   ^~~
   drivers/dma-buf/dma-fence-private.h:14:9: note: 'DMA_FENCE_PRIAVTE_H' is 
defined here; did you mean 'DMA_FENCE_PRIVATE_H'?
   #define DMA_FENCE_PRIAVTE_H
   ^~~
   DMA_FENCE_PRIVATE_H
   1 warning generated.

vim +/DMA_FENCE_PRIVATE_H +13 drivers/dma-buf/dma-fence-private.h

  > 13  #ifndef DMA_FENCE_PRIVATE_H
14  #define DMA_FENCE_PRIAVTE_H
15  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/perf: add OA interrupt support (rev8)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm/i915/perf: add OA interrupt support (rev8)
URL   : https://patchwork.freedesktop.org/series/54280/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/perf: rework aging tail workaround
Okay!

Commit: drm/i915/perf: move pollin setup to non hw specific code
-O:drivers/gpu/drm/i915/i915_perf.c:1420:15: warning: memset with byte count of 
16777216
-O:drivers/gpu/drm/i915/i915_perf.c:1476:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1420:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1474:15: warning: memset with byte count of 
16777216

Commit: drm/i915/perf: add new open param to configure polling of OA buffer
Okay!

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


Re: [Intel-gfx] [RFC] GPU-bound energy efficiency improvements for the intel_pstate driver (v2).

2020-03-24 Thread Francisco Jerez
Francisco Jerez  writes:

> "Pandruvada, Srinivas"  writes:
>
>> Hi Francisco,
>>
>> On Tue, 2020-03-10 at 14:41 -0700, Francisco Jerez wrote:
>>> This is my second take on improving the energy efficiency of the
>>> intel_pstate driver under IO-bound conditions.  The problem and
>>> approach to solve it are roughly the same as in my previous series
>>> [1]
>>> at a high level:
>>> 
>>> In IO-bound scenarios (by definition) the throughput of the system
>>> doesn't improve with increasing CPU frequency beyond the threshold
>>> value at which the IO device becomes the bottleneck, however with the
>>> current governors (whether HWP is in use or not) the CPU frequency
>>> tends to oscillate with the load, often with an amplitude far into
>>> the
>>> turbo range, leading to severely reduced energy efficiency, which is
>>> particularly problematic when a limited TDP budget is shared among a
>>> number of cores running some multithreaded workload, or among a CPU
>>> core and an integrated GPU.
>>> 
>>> Improving the energy efficiency of the CPU improves the throughput of
>>> the system in such TDP-limited conditions.  See [4] for some
>>> preliminary benchmark results from a Razer Blade Stealth 13 Late
>>> 2019/LY320 laptop with an Intel ICL processor and integrated
>>> graphics,
>>> including throughput results that range up to a ~15% improvement and
>>> performance-per-watt results up to a ~43% improvement (estimated via
>>> RAPL).  Particularly the throughput results may vary substantially
>>> from one platform to another depending on the TDP budget and the
>>> balance of load between CPU and GPU.
>>> 
>>
>> You changed the EPP to 0 intentionally or unintentionally. We know that
>> all energy optimization will be disabled with this change. 
>> This test was done on an ICL system.
>>
>
> Hmm, that's bad, and fully unintentional.  It's probably a side effect
> of intel_pstate_reset_vlp() running before intel_pstate_hwp_set(), which
> could cause it to use an uninitialized value of hwp_req_cached (zero?).
> I'll fix it in v3.  Thanks a lot for pointing this out.
>

Sigh.  That means that the performance results I got were inadvertently
obtained while using an EPP setting of "performance" (!).  That's
unlikely to be the case in most systems but still kind of meaningful.
Need to get updated performance numbers with EPP=0x80 -- The larger up
to ~40% energy efficiency improvements still seem to be visible
regardless, but the throughput benefit is likely to be lower than with
EPP=0.

>>
>> Basically without your patches on top of linux-next: EPP = 0x80
>> $sudo rdmsr -a 0x774
>> 80002704
>> 80002704
>> 80002704
>> 80002704
>> 80002704
>> 80002704
>> 80002704
>> 80002704
>>
>>
>> After your patches
>>
>> $sudo rdmsr -a 0x774
>> 2704
>> 2704
>> 2704
>> 2704
>> 2704
>> 2704
>> 2704
>> 2704
>>
>> I added some prints, basically you change the EPP at startup before
>> regular HWP request update path and update on top. So boot up EPP is
>> overwritten.
>>
>>
>> [5.867476] intel_pstate_reset_vlp hwp_req cached:0
>> [5.872426] intel_pstate_reset_vlp hwp_req:404
>> [5.881645] intel_pstate_reset_vlp hwp_req cached:0
>> [5.886634] intel_pstate_reset_vlp hwp_req:404
>> [5.895819] intel_pstate_reset_vlp hwp_req cached:0
>> [5.900958] intel_pstate_reset_vlp hwp_req:404
>> [5.910321] intel_pstate_reset_vlp hwp_req cached:0
>> [5.915406] intel_pstate_reset_vlp hwp_req:404
>> [5.924623] intel_pstate_reset_vlp hwp_req cached:0
>> [5.929564] intel_pstate_reset_vlp hwp_req:404
>> [5.944039] intel_pstate_reset_vlp hwp_req cached:0
>> [5.951672] intel_pstate_reset_vlp hwp_req:404
>> [5.966157] intel_pstate_reset_vlp hwp_req cached:0
>> [5.973808] intel_pstate_reset_vlp hwp_req:404
>> [5.988223] intel_pstate_reset_vlp hwp_req cached:0
>> [5.995823] intel_pstate_reset_vlp hwp_req:404
>> [6.010062] intel_pstate: HWP enabled
>>
>> Thanks,
>> Srinivas
>>
>>
>>
>>> One of the main differences relative to my previous version is that
>>> the trade-off between energy efficiency and frequency ramp-up latency
>>> is now exposed to device drivers through a new PM QoS class [It would
>>> make sense to expose it to userspace too eventually but that's beyond
>>> the purpose of this series].  The new PM QoS class provides a latency
>>> target to CPUFREQ governors which gives them permission to filter out
>>> CPU frequency oscillations with a period significantly shorter than
>>> the specified target, whenever doing so leads to improved energy
>>> efficiency.
>>> 
>>> This series takes advantage of the new PM QoS class from the i915
>>> driver whenever the driver determines that the GPU has become a
>>> bottleneck for an extended period of time.  At that point it places a
>>> PM QoS ramp-up latency target which causes CPUFREQ to limit the CPU
>>> to
>>> a reasonably energy-efficient frequency able to at least achieve the
>>> required amount of work in a time window approximately equal to the

[Intel-gfx] [PATCH 1/3] drm/i915/perf: rework aging tail workaround

2020-03-24 Thread Umesh Nerlige Ramappa
From: Lionel Landwerlin 

We're about to introduce an options to open the perf stream, giving
the user ability to configure how often it wants the kernel to poll
the OA registers for available data.

Right now the workaround against the OA tail pointer race condition
requires at least twice the internal kernel polling timer to make any
data available.

This changes introduce checks on the OA data written into the circular
buffer to make as much data as possible available on the first
iteration of the polling timer.

v2: Use OA_TAKEN macro without the gtt_offset (Lionel)
v3: (Umesh)
- Rebase
- Change report to report32 from below review
  https://patchwork.freedesktop.org/patch/330704/?series=66697&rev=1
v4: (Ashutosh, Lionel)
- Fix checkpatch errors
- Fix aging_timestamp initialization
- Check for only one valid landed report
- Fix check for unlanded report
v5: (Ashutosh)
- Fix bug in accurately determining landed report.
- Optimize the check for landed reports by going as far as the
  previously determined aged tail.

Signed-off-by: Lionel Landwerlin 
Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c   | 204 ++---
 drivers/gpu/drm/i915/i915_perf_types.h |  28 ++--
 2 files changed, 97 insertions(+), 135 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3222f6cd8255..4583ae9b77be 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -223,26 +223,17 @@
  *
  * Although this can be observed explicitly while copying reports to userspace
  * by checking for a zeroed report-id field in tail reports, we want to account
- * for this earlier, as part of the oa_buffer_check to avoid lots of redundant
- * read() attempts.
- *
- * In effect we define a tail pointer for reading that lags the real tail
- * pointer by at least %OA_TAIL_MARGIN_NSEC nanoseconds, which gives enough
- * time for the corresponding reports to become visible to the CPU.
- *
- * To manage this we actually track two tail pointers:
- *  1) An 'aging' tail with an associated timestamp that is tracked until we
- * can trust the corresponding data is visible to the CPU; at which point
- * it is considered 'aged'.
- *  2) An 'aged' tail that can be used for read()ing.
- *
- * The two separate pointers let us decouple read()s from tail pointer aging.
- *
- * The tail pointers are checked and updated at a limited rate within a hrtimer
- * callback (the same callback that is used for delivering EPOLLIN events)
- *
- * Initially the tails are marked invalid with %INVALID_TAIL_PTR which
- * indicates that an updated tail pointer is needed.
+ * for this earlier, as part of the oa_buffer_check_unlocked to avoid lots of
+ * redundant read() attempts.
+ *
+ * We workaround this issue in oa_buffer_check_unlocked() by reading the 
reports
+ * in the OA buffer, starting from the tail reported by the HW until we find a
+ * report with its first 2 dwords not 0 meaning its previous report is
+ * completely in memory and ready to be read. Those dwords are also set to 0
+ * once read and the whole buffer is cleared upon OA buffer initialization. The
+ * first dword is the reason for this report while the second is the timestamp,
+ * making the chances of having those 2 fields at 0 fairly unlikely. A more
+ * detailed explanation is available in oa_buffer_check_unlocked().
  *
  * Most of the implementation details for this workaround are in
  * oa_buffer_check_unlocked() and _append_oa_reports()
@@ -454,8 +445,8 @@ static u32 gen7_oa_hw_tail_read(struct i915_perf_stream 
*stream)
  * (See description of OA_TAIL_MARGIN_NSEC above for further details.)
  *
  * Besides returning true when there is data available to read() this function
- * also has the side effect of updating the oa_buffer.tails[], .aging_timestamp
- * and .aged_tail_idx state used for reading.
+ * also updates the tail, aging_tail and aging_timestamp in the oa_buffer
+ * object.
  *
  * Note: It's safe to read OA config state here unlocked, assuming that this is
  * only called while the stream is enabled, while the global OA configuration
@@ -465,28 +456,18 @@ static u32 gen7_oa_hw_tail_read(struct i915_perf_stream 
*stream)
  */
 static bool oa_buffer_check_unlocked(struct i915_perf_stream *stream)
 {
+   u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma);
int report_size = stream->oa_buffer.format_size;
unsigned long flags;
-   unsigned int aged_idx;
-   u32 head, hw_tail, aged_tail, aging_tail;
+   u32 hw_tail;
u64 now;
 
/* 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.
+* could result in an OA buffer reset which might reset the head and
+* tail state.
 */
spin_lock_irqsave(&stream->oa_buffer.ptr_lock, flags);
 
-   /* NB: The head we obs

[Intel-gfx] [PATCH 0/3] drm/i915/perf: add OA interrupt support

2020-03-24 Thread Umesh Nerlige Ramappa
Hi all,

This is a revival of an earlier patch series submitted by Lionel
Landwerlin - https://patchwork.freedesktop.org/series/54280/

The patches enable interrupt support for the perf OA unit in
i915, further details can be found in the orignal series linked
above.

v2: (Umesh)
- This series will split into 2. This revision will only support the addition of
  poll delay parameter to perf OA. If needed a future revision will incorporate
  interrupt support.

Regards,
Umesh


Lionel Landwerlin (3):
  drm/i915/perf: rework aging tail workaround
  drm/i915/perf: move pollin setup to non hw specific code
  drm/i915/perf: add new open param to configure polling of OA buffer

 drivers/gpu/drm/i915/i915_perf.c   | 250 +++--
 drivers/gpu/drm/i915/i915_perf_types.h |  34 ++--
 include/uapi/drm/i915_drm.h|  13 ++
 3 files changed, 144 insertions(+), 153 deletions(-)

-- 
2.20.1

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


[Intel-gfx] [PATCH 3/3] drm/i915/perf: add new open param to configure polling of OA buffer

2020-03-24 Thread Umesh Nerlige Ramappa
From: Lionel Landwerlin 

This new parameter let's the application choose how often the OA
buffer should be checked on the CPU side for data availability. Longer
polling period tend to reduce CPU overhead if the application does not
care about somewhat real time data collection.

v2: Allow disabling polling completely with 0 value (Lionel)
v3: Version the new parameter (Joonas)
v4: Rebase (Umesh)
v5: Make poll delay value of 0 invalid (Umesh)
v6:
- Describe poll_oa_period (Ashutosh)
- Fix comment for new poll parameter (Lionel)
- Drop open_flags in read_properties_unlocked (Lionel)
- Rename uapi parameter (Ashutosh)
v7: Reword the comment in uapi (Ashutosh)

Signed-off-by: Lionel Landwerlin 
Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_perf.c   | 32 --
 drivers/gpu/drm/i915/i915_perf_types.h |  6 +
 include/uapi/drm/i915_drm.h| 13 +++
 3 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4cadf97f94bc..c74ebac50015 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -248,11 +248,11 @@
 #define OA_TAIL_MARGIN_NSEC10ULL
 #define INVALID_TAIL_PTR   0x
 
-/* frequency for checking whether the OA unit has written new reports to the
- * circular OA buffer...
+/* The default frequency for checking whether the OA unit has written new
+ * reports to the circular OA buffer...
  */
-#define POLL_FREQUENCY 200
-#define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)
+#define DEFAULT_POLL_FREQUENCY_HZ 200
+#define DEFAULT_POLL_PERIOD_NS (NSEC_PER_SEC / DEFAULT_POLL_FREQUENCY_HZ)
 
 /* for sysctl proc_dointvec_minmax of dev.i915.perf_stream_paranoid */
 static u32 i915_perf_stream_paranoid = true;
@@ -339,6 +339,8 @@ static const struct i915_oa_format 
gen12_oa_formats[I915_OA_FORMAT_MAX] = {
  * @sseu: internal SSEU configuration computed either from the userspace
  *specified configuration in the opening parameters or a default value
  *(see get_default_sseu_config())
+ * @poll_oa_period: The period in nanoseconds at which the CPU will check for 
OA
+ * data availability
  *
  * As read_properties_unlocked() enumerates and validates the properties given
  * to open a stream of metrics the configuration is built up in the structure
@@ -361,6 +363,8 @@ struct perf_open_properties {
 
bool has_sseu;
struct intel_sseu sseu;
+
+   u64 poll_oa_period;
 };
 
 struct i915_oa_config_bo {
@@ -2600,7 +2604,7 @@ static void i915_oa_stream_enable(struct i915_perf_stream 
*stream)
 
if (stream->periodic)
hrtimer_start(&stream->poll_check_timer,
- ns_to_ktime(POLL_PERIOD),
+ ns_to_ktime(stream->poll_oa_period),
  HRTIMER_MODE_REL_PINNED);
 }
 
@@ -3035,7 +3039,8 @@ static enum hrtimer_restart oa_poll_check_timer_cb(struct 
hrtimer *hrtimer)
wake_up(&stream->poll_wq);
}
 
-   hrtimer_forward_now(hrtimer, ns_to_ktime(POLL_PERIOD));
+   hrtimer_forward_now(hrtimer,
+   ns_to_ktime(stream->poll_oa_period));
 
return HRTIMER_RESTART;
 }
@@ -3424,6 +3429,7 @@ i915_perf_open_ioctl_locked(struct i915_perf *perf,
 
stream->perf = perf;
stream->ctx = specific_ctx;
+   stream->poll_oa_period = props->poll_oa_period;
 
ret = i915_oa_stream_init(stream, param, props);
if (ret)
@@ -3502,6 +3508,7 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
int ret;
 
memset(props, 0, sizeof(struct perf_open_properties));
+   props->poll_oa_period = DEFAULT_POLL_PERIOD_NS;
 
if (!n_props) {
DRM_DEBUG("No i915 perf properties given\n");
@@ -3634,6 +3641,14 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
props->has_sseu = true;
break;
}
+   case DRM_I915_PERF_PROP_POLL_OA_PERIOD:
+   if (value < 10 /* 100us */) {
+   DRM_DEBUG("OA availability timer too small 
(%lluns < 100us)\n",
+ value);
+   return -EINVAL;
+   }
+   props->poll_oa_period = value;
+   break;
case DRM_I915_PERF_PROP_MAX:
MISSING_CASE(id);
return -EINVAL;
@@ -4416,8 +4431,11 @@ int i915_perf_ioctl_version(void)
 * 4: Add DRM_I915_PERF_PROP_ALLOWED_SSEU to limit what contexts can
 *be run for the duration of the performance recording based on
 *their SSEU configuration.
+*
+* 5: Add DRM_I915_PERF_PROP_POLL_OA_PERIOD parameter that controls the
+*interval for the hrtimer us

[Intel-gfx] [PATCH 2/3] drm/i915/perf: move pollin setup to non hw specific code

2020-03-24 Thread Umesh Nerlige Ramappa
From: Lionel Landwerlin 

This isn't really gen specific stuff, so just move it to the common
code.

v2: Rebase (Umesh)
v3: Remove comment, pollin is a per stream state already (Ashutosh)

Signed-off-by: Lionel Landwerlin 
Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_perf.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4583ae9b77be..4cadf97f94bc 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1418,8 +1418,6 @@ static void gen7_init_oa_buffer(struct i915_perf_stream 
*stream)
 * memory...
 */
memset(stream->oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
-
-   stream->pollin = false;
 }
 
 static void gen8_init_oa_buffer(struct i915_perf_stream *stream)
@@ -1474,8 +1472,6 @@ static void gen8_init_oa_buffer(struct i915_perf_stream 
*stream)
 * memory...
 */
memset(stream->oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
-
-   stream->pollin = false;
 }
 
 static void gen12_init_oa_buffer(struct i915_perf_stream *stream)
@@ -1531,8 +1527,6 @@ static void gen12_init_oa_buffer(struct i915_perf_stream 
*stream)
 */
memset(stream->oa_buffer.vaddr, 0,
   stream->oa_buffer.vma->size);
-
-   stream->pollin = false;
 }
 
 static int alloc_oa_buffer(struct i915_perf_stream *stream)
@@ -2600,6 +2594,8 @@ static void gen12_oa_enable(struct i915_perf_stream 
*stream)
  */
 static void i915_oa_stream_enable(struct i915_perf_stream *stream)
 {
+   stream->pollin = false;
+
stream->perf->ops.oa_enable(stream);
 
if (stream->periodic)
@@ -3023,12 +3019,8 @@ static ssize_t i915_perf_read(struct file *file,
 * effectively ensures we back off until the next hrtimer callback
 * before reporting another EPOLLIN event.
 */
-   if (ret >= 0 || ret == -EAGAIN) {
-   /* Maybe make ->pollin per-stream state if we support multiple
-* concurrent streams in the future.
-*/
+   if (ret >= 0 || ret == -EAGAIN)
stream->pollin = false;
-   }
 
return ret;
 }
-- 
2.20.1

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


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: use forced codec wake on all gen9+ platforms

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm/i915: use forced codec wake on all gen9+ platforms
URL   : https://patchwork.freedesktop.org/series/75024/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8183_full -> Patchwork_17070_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_17070_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb2/igt@gem_exec_balan...@smoke.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-iclb5/igt@gem_exec_balan...@smoke.html

  * igt@gem_exec_schedule@implicit-both-bsd2:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb2/igt@gem_exec_sched...@implicit-both-bsd2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-iclb3/igt@gem_exec_sched...@implicit-both-bsd2.html

  * igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +4 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb5/igt@gem_exec_sched...@in-order-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-iclb4/igt@gem_exec_sched...@in-order-bsd.html

  * igt@gem_exec_schedule@pi-common-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb5/igt@gem_exec_sched...@pi-common-bsd.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-iclb4/igt@gem_exec_sched...@pi-common-bsd.html

  * igt@gem_exec_schedule@preempt-queue-bsd1:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +10 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb2/igt@gem_exec_sched...@preempt-queue-bsd1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-iclb5/igt@gem_exec_sched...@preempt-queue-bsd1.html

  * igt@gem_linear_blits@interruptible:
- shard-apl:  [PASS][11] -> [FAIL][12] ([i915#1263])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-apl7/igt@gem_linear_bl...@interruptible.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-apl6/igt@gem_linear_bl...@interruptible.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding:
- shard-skl:  [PASS][13] -> [FAIL][14] ([i915#54])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109349])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-iclb5/igt@kms_dp_...@basic-dsc-enable-edp.html

  * igt@kms_draw_crc@draw-method-xrgb-blt-xtiled:
- shard-snb:  [PASS][17] -> [SKIP][18] ([fdo#109271]) +1 similar 
issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-snb4/igt@kms_draw_...@draw-method-xrgb-blt-xtiled.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-snb2/igt@kms_draw_...@draw-method-xrgb-blt-xtiled.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
- shard-skl:  [PASS][19] -> [FAIL][20] ([i915#34])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl8/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-skl5/igt@kms_flip@basic-flip-vs-wf_vblank.html

  * igt@kms_flip@flip-vs-suspend:
- shard-skl:  [PASS][21] -> [INCOMPLETE][22] ([i915#221])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl2/igt@kms_f...@flip-vs-suspend.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-skl5/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_hdr@bpc-switch-dpms:
- shard-skl:  [PASS][23] -> [FAIL][24] ([i915#1188])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-skl4/igt@kms_...@bpc-switch-dpms.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/shard-skl4/igt@kms_...@bpc-switch-dpms.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl:  [PASS][25] -> [DMESG-WARN][26] ([i915#180])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/shard-apl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.ht

Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot for audio codec init

2020-03-24 Thread Kai Vehmanen
Hey folks,

On Fri, 20 Mar 2020, Shankar, Uma wrote:
> Souza, Jose  wrote:
> > On Wed, 2020-03-18 at 17:00 +0530, Uma Shankar wrote:
> > > This patch fixes the same by triggering a modeset at boot.
> > 
> > We had the same issue for PSR, take a look to the fix:
> > commit 33e059a2e4df454359f642f2235af39de9d3e914
> > drm/i915/psr: Force PSR probe only after full initialization
> > 
> > Maybe make this even more generic.
> 
> Yeah this looks to dealing with almost a similar need. Thanks for pointing 
> this out,
> will try to come up with a generalized solution.

btw, there's an additional regression in the posted patch, reported 
by Michael Marley in:

"HDMI/DisplayPort audio does not work initially on boot with Linux 5.6 
(Bisected)"
https://gitlab.freedesktop.org/drm/intel/issues/1363

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/21] Revert "drm/i915/gem: Drop relocation slowpath"

2020-03-24 Thread Patchwork
== Series Details ==

Series: series starting with [01/21] Revert "drm/i915/gem: Drop relocation 
slowpath"
URL   : https://patchwork.freedesktop.org/series/75026/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8183 -> Patchwork_17071


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17071 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17071, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17071/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_17071:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@mman:
- fi-kbl-8809g:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/fi-kbl-8809g/igt@i915_selftest@l...@mman.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17071/fi-kbl-8809g/igt@i915_selftest@l...@mman.html

  * igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-guc: [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/fi-kbl-guc/igt@kms_force_connector_ba...@force-connector-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17071/fi-kbl-guc/igt@kms_force_connector_ba...@force-connector-state.html

  
Known issues


  Here are the changes found in Patchwork_17071 that come from known issues:

### IGT changes ###

 Warnings 

  * igt@runner@aborted:
- fi-bdw-gvtdvm:  [FAIL][5] ([i915#483]) -> [FAIL][6] ([i915#1485])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/fi-bdw-gvtdvm/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17071/fi-bdw-gvtdvm/igt@run...@aborted.html
- fi-kbl-8809g:   [FAIL][7] ([i915#1209]) -> [FAIL][8] ([i915#1485] / 
[i915#656])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/fi-kbl-8809g/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17071/fi-kbl-8809g/igt@run...@aborted.html

  
  [i915#1209]: https://gitlab.freedesktop.org/drm/intel/issues/1209
  [i915#1485]: https://gitlab.freedesktop.org/drm/intel/issues/1485
  [i915#483]: https://gitlab.freedesktop.org/drm/intel/issues/483
  [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656


Participating hosts (45 -> 21)
--

  ERROR: It appears as if the changes made in Patchwork_17071 prevented too 
many machines from booting.

  Additional (3): fi-skl-lmem fi-blb-e6850 fi-kbl-7560u 
  Missing(27): fi-kbl-soraka fi-apl-guc fi-icl-y fi-byt-n2820 fi-icl-dsi 
fi-skl-6600u fi-cml-u2 fi-bxt-dsi fi-bdw-5557u fi-cml-s fi-tgl-u fi-bsw-n3050 
fi-byt-j1900 fi-glk-dsi fi-ctg-p8600 fi-skl-6700k2 fi-ehl-1 fi-skl-guc 
fi-cfl-8700k fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-cfl-guc 
fi-bsw-kefka fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8183 -> Patchwork_17071

  CI-20190529: 20190529
  CI_DRM_8183: 795894daf2cc32246af94541733e08649d082470 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5535: d1dcf40cc6869ac858586c5ad9f09af6617ce2ee @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17071: a5e02329d0040a10925452a69cf897add229abbd @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a5e02329d004 drm/i915: Ensure we hold the pin mutex
7fd3474aa28d drm/i915: Add ww locking to pin_to_display_plane
358d15462c52 drm/i915: Add ww locking to vm_fault_gtt
f9866d69096e drm/i915: Move i915_vma_lock in the selftests to avoid lock 
inversion
cf9d9e219967 drm/i915: Use ww pinning for intel_context_create_request()
889d75300ec6 drm/i915/selftests: Fix locking inversion in lrc selftest.
b4725537cd4f drm/i915: Dirty hack to fix selftests locking inversion
595a91872a32 drm/i915: Convert i915_perf to ww locking as well
07f6b9485c85 drm/i915: Kill last user of intel_context_create_request outside 
of selftests
bcd26305ed48 drm/i915: Convert i915_gem_object/client_blt.c to use ww locking 
as well, v2.
2668b4a08252 drm/i915: Make sure execbuffer always passes ww state to 
i915_vma_pin.
dc2ed22efdf0 drm/i915: Rework intel_context pinning to do everything outside of 
pin_mutex
4b9677a0176f drm/i915: Pin engine before pinning all objects, v3.
5f90a8dff8ac drm/i915: Nuke arguments to eb_pin_engine
bef2d503c37d drm/i915: Add ww context handling to context_barrier_task
3c3457d2bdc4 drm/i915: Use ww locking in intel_renderstate.
e2de950dd57e drm/i915: Use per object locking in execbuf, v6.
3f8cd593de21 drm/i915: Parse command buffer earlier in eb_relocate(slow)
ed3b18330ea7 drm/i915: Remove locking from i915

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Select the deepest available parking mode for rc6 (rev2)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Select the deepest available parking mode for rc6 (rev2)
URL   : https://patchwork.freedesktop.org/series/75009/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8182_full -> Patchwork_17069_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17069_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17069_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_17069_full:

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rc6_residency@rc6-idle:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-skl6/igt@i915_pm_rc6_reside...@rc6-idle.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/shard-skl6/igt@i915_pm_rc6_reside...@rc6-idle.html

  
 Warnings 

  * igt@i915_pm_rc6_residency@rc6-idle:
- shard-snb:  [FAIL][3] ([i915#1515]) -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-snb6/igt@i915_pm_rc6_reside...@rc6-idle.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/shard-snb1/igt@i915_pm_rc6_reside...@rc6-idle.html

  
Known issues


  Here are the changes found in Patchwork_17069_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_async@concurrent-writes-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-iclb3/igt@gem_exec_as...@concurrent-writes-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/shard-iclb1/igt@gem_exec_as...@concurrent-writes-bsd.html

  * igt@gem_exec_parallel@vcs1:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112080]) +4 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-iclb1/igt@gem_exec_paral...@vcs1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/shard-iclb8/igt@gem_exec_paral...@vcs1.html

  * igt@gem_exec_schedule@fifo-bsd1:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +6 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-iclb1/igt@gem_exec_sched...@fifo-bsd1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/shard-iclb8/igt@gem_exec_sched...@fifo-bsd1.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +5 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-kbl4/igt@gem_workarou...@suspend-resume-fd.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/shard-kbl1/igt@gem_workarou...@suspend-resume-fd.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#72])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#79])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-glk7/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/shard-glk1/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
- shard-hsw:  [PASS][17] -> [INCOMPLETE][18] ([i915#61])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-hsw8/igt@kms_f...@flip-vs-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/shard-hsw5/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-apl:  [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-apl7/igt@kms_f...@flip-vs-suspend-interruptible.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/shard-apl8/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-iclb: [PASS][21] -> [INCOMPLETE][22] ([i915#1185] / 
[i915#250])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-iclb5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/shard-iclb3/igt@kms_pl...@p

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/21] Revert "drm/i915/gem: Drop relocation slowpath"

2020-03-24 Thread Patchwork
== Series Details ==

Series: series starting with [01/21] Revert "drm/i915/gem: Drop relocation 
slowpath"
URL   : https://patchwork.freedesktop.org/series/75026/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f298bf3f0b01 Revert "drm/i915/gem: Drop relocation slowpath"
-:78: WARNING:LINE_SPACING: Missing a blank line after declarations
#78: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1579:
+   int err = __get_user(c, addr);
+   if (err)

total: 0 errors, 1 warnings, 0 checks, 257 lines checked
f79d00fff047 drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
-:506: WARNING:LONG_LINE: line over 100 characters
#506: FILE: drivers/gpu/drm/i915/i915_gem.c:1338:
+   while ((obj = list_first_entry_or_null(&ww->obj_list, struct 
drm_i915_gem_object, obj_link))) {

total: 0 errors, 1 warnings, 0 checks, 481 lines checked
ed3b18330ea7 drm/i915: Remove locking from i915_gem_object_prepare_read/write
3f8cd593de21 drm/i915: Parse command buffer earlier in eb_relocate(slow)
e2de950dd57e drm/i915: Use per object locking in execbuf, v6.
3c3457d2bdc4 drm/i915: Use ww locking in intel_renderstate.
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#10: 
Convert to using ww-waiting, and make sure we always pin intel_context_state,

total: 0 errors, 1 warnings, 0 checks, 202 lines checked
bef2d503c37d drm/i915: Add ww context handling to context_barrier_task
-:19: WARNING:LONG_LINE: line over 100 characters
#19: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:1100:
+   int (*pin)(struct intel_context *ce, struct 
i915_gem_ww_ctx *ww, void *data),

total: 0 errors, 1 warnings, 0 checks, 146 lines checked
5f90a8dff8ac drm/i915: Nuke arguments to eb_pin_engine
4b9677a0176f drm/i915: Pin engine before pinning all objects, v3.
dc2ed22efdf0 drm/i915: Rework intel_context pinning to do everything outside of 
pin_mutex
-:125: CHECK:LINE_SPACING: Please don't use multiple blank lines
#125: FILE: drivers/gpu/drm/i915/gt/intel_context.c:176:
+
+

-:340: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#340: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:3028:
+   *vaddr = i915_gem_object_pin_map(ce->state->obj,
+   
i915_coherent_map_type(ce->engine->i915) |

total: 0 errors, 0 warnings, 2 checks, 445 lines checked
2668b4a08252 drm/i915: Make sure execbuffer always passes ww state to 
i915_vma_pin.
-:80: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#80: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:573:
+   err = i915_vma_pin_ww(vma, &eb->ww,
   entry->pad_to_size, entry->alignment,

-:188: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a 
separate line
#188: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2197:
+* hsw should have this fixed, but bdw mucks it up again. */

total: 0 errors, 1 warnings, 1 checks, 812 lines checked
bcd26305ed48 drm/i915: Convert i915_gem_object/client_blt.c to use ww locking 
as well, v2.
07f6b9485c85 drm/i915: Kill last user of intel_context_create_request outside 
of selftests
595a91872a32 drm/i915: Convert i915_perf to ww locking as well
b4725537cd4f drm/i915: Dirty hack to fix selftests locking inversion
889d75300ec6 drm/i915/selftests: Fix locking inversion in lrc selftest.
cf9d9e219967 drm/i915: Use ww pinning for intel_context_create_request()
f9866d69096e drm/i915: Move i915_vma_lock in the selftests to avoid lock 
inversion
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

total: 0 errors, 1 warnings, 0 checks, 125 lines checked
358d15462c52 drm/i915: Add ww locking to vm_fault_gtt
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

total: 0 errors, 1 warnings, 0 checks, 91 lines checked
7fd3474aa28d drm/i915: Add ww locking to pin_to_display_plane
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

total: 0 errors, 1 warnings, 0 checks, 110 lines checked
a5e02329d004 drm/i915: Ensure we hold the pin mutex
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one

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

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: use forced codec wake on all gen9+ platforms

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm/i915: use forced codec wake on all gen9+ platforms
URL   : https://patchwork.freedesktop.org/series/75024/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8183 -> Patchwork_17070


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/index.html

Known issues


  Here are the changes found in Patchwork_17070 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([i915#189])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/fi-icl-dsi/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/fi-icl-dsi/igt@i915_pm_...@module-reload.html

  
 Warnings 

  * igt@i915_selftest@live@gem_contexts:
- fi-cfl-8700k:   [DMESG-FAIL][3] ([i915#481]) -> [INCOMPLETE][4] 
([i915#424])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
- fi-cfl-guc: [INCOMPLETE][5] ([fdo#106070] / [i915#424]) -> 
[DMESG-FAIL][6] ([i915#481])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8183/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17070/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html

  
  [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
  [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189
  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
  [i915#481]: https://gitlab.freedesktop.org/drm/intel/issues/481


Participating hosts (45 -> 38)
--

  Additional (4): fi-skl-lmem fi-blb-e6850 fi-cfl-8109u fi-kbl-7500u 
  Missing(11): fi-hsw-4200u fi-hsw-peppy fi-glk-dsi fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-ivb-3770 fi-bdw-samus fi-byt-clapper fi-skl-6600u 
fi-snb-2600 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8183 -> Patchwork_17070

  CI-20190529: 20190529
  CI_DRM_8183: 795894daf2cc32246af94541733e08649d082470 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5535: d1dcf40cc6869ac858586c5ad9f09af6617ce2ee @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17070: 0d0abab0d1054b2a6cdc0ae5dbab122c231bc502 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0d0abab0d105 drm/i915: use forced codec wake on all gen9+ platforms

== Logs ==

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


Re: [Intel-gfx] [PATCH 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles

2020-03-24 Thread Linus Torvalds
On Tue, Mar 24, 2020 at 1:49 AM Masahiro Yamada  wrote:
>
> If it is OK to queue this up to Kbuild tree,
> I will send a pull request to Linus.

Looks fine to me, assuming we didn't now get some confusion due to
duplicate patches (I think Jason got his tree added to -next already).

And yeah, that end result looks much better.

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


[Intel-gfx] [PATCH 11/21] drm/i915: Make sure execbuffer always passes ww state to i915_vma_pin.

2020-03-24 Thread Maarten Lankhorst
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.

This also requires changing the order of eb_parse slightly, to ensure
we pass ww at a point where we could still handle -EDEADLK safely.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/display/intel_display.c  |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |   4 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 125 ++
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |   4 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.h  |   4 +-
 drivers/gpu/drm/i915/gt/intel_context.c   |  65 +
 drivers/gpu/drm/i915/gt/intel_context.h   |  13 ++
 drivers/gpu/drm/i915/gt/intel_context_types.h |   3 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c|   2 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   |   5 +-
 drivers/gpu/drm/i915/gt/intel_renderstate.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_ring.c  |  10 +-
 drivers/gpu/drm/i915/gt/intel_ring.h  |   3 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  15 +--
 drivers/gpu/drm/i915/gt/intel_timeline.c  |  12 +-
 drivers/gpu/drm/i915/gt/intel_timeline.h  |   3 +-
 drivers/gpu/drm/i915/gt/mock_engine.c |   3 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |   4 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|   2 +-
 drivers/gpu/drm/i915/i915_drv.h   |  13 +-
 drivers/gpu/drm/i915/i915_gem.c   |  11 +-
 drivers/gpu/drm/i915/i915_vma.c   |  13 +-
 drivers/gpu/drm/i915/i915_vma.h   |  13 +-
 24 files changed, 207 insertions(+), 126 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index ecdba2ccf688..be807230f4bc 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3441,7 +3441,7 @@ initial_plane_vma(struct drm_i915_private *i915,
if (IS_ERR(vma))
goto err_obj;
 
-   if (i915_ggtt_pin(vma, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | base))
+   if (i915_ggtt_pin(vma, NULL, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | base))
goto err_obj;
 
if (i915_gem_object_is_tiled(obj) &&
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 062848951095..f5b01e70eb61 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1145,7 +1145,7 @@ static int context_barrier_task(struct i915_gem_context 
*ctx,
 
i915_gem_ww_ctx_init(&ww, true);
 retry:
-   err = intel_context_pin(ce);
+   err = intel_context_pin_ww(ce, &ww);
if (err)
goto err;
 
@@ -1238,7 +1238,7 @@ static int pin_ppgtt_update(struct intel_context *ce, 
struct i915_gem_ww_ctx *ww
 
if (!HAS_LOGICAL_RING_CONTEXTS(vm->i915))
/* ppGTT is not part of the legacy context image */
-   return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm));
+   return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm), ww);
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d9dd6303658f..b17597445d81 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -394,7 +394,7 @@ eb_pin_vma(struct i915_execbuffer *eb,
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_GTT))
pin_flags |= PIN_GLOBAL;
 
-   if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags)))
+   if (unlikely(i915_vma_pin_ww(vma, &eb->ww, 0, 0, pin_flags)))
return false;
 
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
@@ -535,7 +535,7 @@ static inline int use_cpu_reloc(const struct reloc_cache 
*cache,
obj->cache_level != I915_CACHE_NONE);
 }
 
-static int eb_reserve_vma(const struct i915_execbuffer *eb,
+static int eb_reserve_vma(struct i915_execbuffer *eb,
  struct eb_vma *ev,
  u64 pin_flags)
 {
@@ -569,7 +569,7 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
return err;
}
 
-   err = i915_vma_pin(vma,
+   err = i915_vma_pin_ww(vma, &eb->ww,
   entry->pad_to_size, entry->alignment,
   pin_flags);
if (err)
@@ -1062,9 +1062,10 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
 }
 
 static void *reloc_iomap(struct drm_i915_gem_object *obj,
-struct reloc_cache *cache,
+struct i915_execbuffer *eb,
 unsigned long page)
 {
+   struct reloc_cache *cache = &eb-

[Intel-gfx] [PATCH 01/21] Revert "drm/i915/gem: Drop relocation slowpath"

2020-03-24 Thread Maarten Lankhorst
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.

Cc: Chris Wilson 
Cc: Matthew Auld 
Signed-off-by: Maarten Lankhorst 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 239 +-
 1 file changed, 235 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6b3013d20851..248b0889416b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1480,7 +1480,9 @@ static int eb_relocate_vma(struct i915_execbuffer *eb, 
struct eb_vma *ev)
 * we would try to acquire the struct mutex again. Obviously
 * this is bad and so lockdep complains vehemently.
 */
-   copied = __copy_from_user(r, urelocs, count * sizeof(r[0]));
+   pagefault_disable();
+   copied = __copy_from_user_inatomic(r, urelocs, count * 
sizeof(r[0]));
+   pagefault_enable();
if (unlikely(copied)) {
remain = -EFAULT;
goto out;
@@ -1530,6 +1532,236 @@ static int eb_relocate_vma(struct i915_execbuffer *eb, 
struct eb_vma *ev)
return remain;
 }
 
+static int
+eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
+{
+   const struct drm_i915_gem_exec_object2 *entry = ev->exec;
+   struct drm_i915_gem_relocation_entry *relocs =
+   u64_to_ptr(typeof(*relocs), entry->relocs_ptr);
+   unsigned int i;
+   int err;
+
+   for (i = 0; i < entry->relocation_count; i++) {
+   u64 offset = eb_relocate_entry(eb, ev, &relocs[i]);
+
+   if ((s64)offset < 0) {
+   err = (int)offset;
+   goto err;
+   }
+   }
+   err = 0;
+err:
+   reloc_cache_reset(&eb->reloc_cache);
+   return err;
+}
+
+static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+{
+   const char __user *addr, *end;
+   unsigned long size;
+   char __maybe_unused c;
+
+   size = entry->relocation_count;
+   if (size == 0)
+   return 0;
+
+   if (size > N_RELOC(ULONG_MAX))
+   return -EINVAL;
+
+   addr = u64_to_user_ptr(entry->relocs_ptr);
+   size *= sizeof(struct drm_i915_gem_relocation_entry);
+   if (!access_ok(addr, size))
+   return -EFAULT;
+
+   end = addr + size;
+   for (; addr < end; addr += PAGE_SIZE) {
+   int err = __get_user(c, addr);
+   if (err)
+   return err;
+   }
+   return __get_user(c, end - 1);
+}
+
+static int eb_copy_relocations(const struct i915_execbuffer *eb)
+{
+   struct drm_i915_gem_relocation_entry *relocs;
+   const unsigned int count = eb->buffer_count;
+   unsigned int i;
+   int err;
+
+   for (i = 0; i < count; i++) {
+   const unsigned int nreloc = eb->exec[i].relocation_count;
+   struct drm_i915_gem_relocation_entry __user *urelocs;
+   unsigned long size;
+   unsigned long copied;
+
+   if (nreloc == 0)
+   continue;
+
+   err = check_relocations(&eb->exec[i]);
+   if (err)
+   goto err;
+
+   urelocs = u64_to_user_ptr(eb->exec[i].relocs_ptr);
+   size = nreloc * sizeof(*relocs);
+
+   relocs = kvmalloc_array(size, 1, GFP_KERNEL);
+   if (!relocs) {
+   err = -ENOMEM;
+   goto err;
+   }
+
+   /* copy_from_user is limited to < 4GiB */
+   copied = 0;
+   do {
+   unsigned int len =
+   min_t(u64, BIT_ULL(31), size - copied);
+
+   if (__copy_from_user((char *)relocs + copied,
+(char __user *)urelocs + copied,
+len))
+   goto end;
+
+   copied += len;
+   } while (copied < size);
+
+   /*
+* As we do not update the known relocation offsets after
+* relocating (due to the complexities in lock handling),
+* we need to mark them as invalid now so that we force the
+* relocation processing next time. Just in case the target
+* object is evicted and then rebound into its old
+* presumed_offset before the next execbuffer - if that
+* happened we would make the mistake of assuming that the
+* relocations were valid.
+*/
+   if (!user_access_begin

[Intel-gfx] [PATCH 21/21] drm/i915: Ensure we hold the pin mutex

2020-03-24 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
 drivers/gpu/drm/i915/i915_vma.c | 9 -
 drivers/gpu/drm/i915/i915_vma.h | 1 +
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.c 
b/drivers/gpu/drm/i915/gt/intel_renderstate.c
index c39d73142950..df42ba06711a 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.c
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.c
@@ -207,7 +207,7 @@ int intel_renderstate_init(struct intel_renderstate *so,
if (err)
goto err_context;
 
-   err = i915_vma_pin(so->vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
+   err = i915_vma_pin_ww(so->vma, &so->ww, 0, 0, PIN_GLOBAL | PIN_HIGH);
if (err)
goto err_context;
 
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index ebec7a12a581..0de4a03b9e12 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -892,6 +892,8 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct 
i915_gem_ww_ctx *ww,
 #ifdef CONFIG_PROVE_LOCKING
if (debug_locks && lockdep_is_held(&vma->vm->i915->drm.struct_mutex))
WARN_ON(!ww);
+   if (debug_locks && ww && vma->resv)
+   assert_vma_held(vma);
 #endif
 
BUILD_BUG_ON(PIN_GLOBAL != I915_VMA_GLOBAL_BIND);
@@ -1013,8 +1015,13 @@ int i915_ggtt_pin(struct i915_vma *vma, struct 
i915_gem_ww_ctx *ww,
 
GEM_BUG_ON(!i915_vma_is_ggtt(vma));
 
+   WARN_ON(!ww && vma->resv && dma_resv_held(vma->resv));
+
do {
-   err = i915_vma_pin_ww(vma, ww, 0, align, flags | PIN_GLOBAL);
+   if (ww)
+   err = i915_vma_pin_ww(vma, ww, 0, align, flags | 
PIN_GLOBAL);
+   else
+   err = i915_vma_pin(vma, 0, align, flags | PIN_GLOBAL);
if (err != -ENOSPC) {
if (!err) {
err = i915_vma_wait_for_bind(vma);
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index da577729931f..b730f86e54f4 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -242,6 +242,7 @@ i915_vma_pin_ww(struct i915_vma *vma, struct 
i915_gem_ww_ctx *ww,
 static inline int __must_check
 i915_vma_pin(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
 {
+   WARN_ON_ONCE(vma->resv && dma_resv_held(vma->resv));
return i915_vma_pin_ww(vma, NULL, size, alignment, flags);
 }
 
-- 
2.25.1

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


[Intel-gfx] [PATCH 15/21] drm/i915: Dirty hack to fix selftests locking inversion

2020-03-24 Thread Maarten Lankhorst
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gt/intel_context.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 113d0bda1bcf..5c7acddf9651 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -460,6 +460,18 @@ struct i915_request *intel_context_create_request(struct 
intel_context *ce)
rq = i915_request_create(ce);
intel_context_unpin(ce);
 
+   if (IS_ERR(rq))
+   return rq;
+
+   /*
+* timeline->mutex should be the inner lock, but is used as outer lock.
+* Hack around this to shut up lockdep in selftests..
+*/
+   lockdep_unpin_lock(&ce->timeline->mutex, rq->cookie);
+   mutex_release(&ce->timeline->mutex.dep_map, _RET_IP_);
+   mutex_acquire(&ce->timeline->mutex.dep_map, SINGLE_DEPTH_NESTING, 0, 
_RET_IP_);
+   rq->cookie = lockdep_pin_lock(&ce->timeline->mutex);
+
return rq;
 }
 
-- 
2.25.1

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


[Intel-gfx] [PATCH 16/21] drm/i915/selftests: Fix locking inversion in lrc selftest.

2020-03-24 Thread Maarten Lankhorst
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 6f06ba750a0a..64959a0c68ce 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -4283,6 +4283,7 @@ static int __live_lrc_state(struct intel_engine_cs 
*engine,
 {
struct intel_context *ce;
struct i915_request *rq;
+   struct i915_gem_ww_ctx ww;
enum {
RING_START_IDX = 0,
RING_TAIL_IDX,
@@ -4297,7 +4298,11 @@ static int __live_lrc_state(struct intel_engine_cs 
*engine,
if (IS_ERR(ce))
return PTR_ERR(ce);
 
-   err = intel_context_pin(ce);
+   i915_gem_ww_ctx_init(&ww, false);
+retry:
+   err = i915_gem_object_lock(scratch->obj, &ww);
+   if (!err)
+   err = intel_context_pin_ww(ce, &ww);
if (err)
goto err_put;
 
@@ -4326,11 +4331,9 @@ static int __live_lrc_state(struct intel_engine_cs 
*engine,
*cs++ = i915_ggtt_offset(scratch) + RING_TAIL_IDX * sizeof(u32);
*cs++ = 0;
 
-   i915_vma_lock(scratch);
err = i915_request_await_object(rq, scratch->obj, true);
if (!err)
err = i915_vma_move_to_active(scratch, rq, EXEC_OBJECT_WRITE);
-   i915_vma_unlock(scratch);
 
i915_request_get(rq);
i915_request_add(rq);
@@ -4367,6 +4370,12 @@ static int __live_lrc_state(struct intel_engine_cs 
*engine,
 err_unpin:
intel_context_unpin(ce);
 err_put:
+   if (err == -EDEADLK) {
+   err = i915_gem_ww_ctx_backoff(&ww);
+   if (!err)
+   goto retry;
+   }
+   i915_gem_ww_ctx_fini(&ww);
intel_context_put(ce);
return err;
 }
-- 
2.25.1

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


[Intel-gfx] [PATCH 02/21] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.

2020-03-24 Thread Maarten Lankhorst
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.

To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.

Changes since v1:
- Change ww_ctx and obj order in locking functions (Jonas Lahtinen)

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/display/intel_display.c  |  4 +-
 .../gpu/drm/i915/gem/i915_gem_client_blt.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_domain.c| 10 ++--
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h| 38 +++---
 .../gpu/drm/i915/gem/i915_gem_object_blt.c|  2 +-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  9 
 drivers/gpu/drm/i915/gem/i915_gem_pm.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_tiling.c|  2 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  2 +-
 .../i915/gem/selftests/i915_gem_client_blt.c  |  2 +-
 .../i915/gem/selftests/i915_gem_coherency.c   | 10 ++--
 .../drm/i915/gem/selftests/i915_gem_context.c |  4 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|  4 +-
 .../drm/i915/gem/selftests/i915_gem_phys.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c|  2 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c|  2 +-
 drivers/gpu/drm/i915/gvt/cmd_parser.c |  2 +-
 drivers/gpu/drm/i915/i915_gem.c   | 52 +--
 drivers/gpu/drm/i915/i915_gem.h   | 11 
 drivers/gpu/drm/i915/selftests/i915_gem.c | 41 +++
 drivers/gpu/drm/i915/selftests/i915_vma.c |  2 +-
 .../drm/i915/selftests/intel_memory_region.c  |  2 +-
 26 files changed, 175 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 37bd7ce88ecd..ecdba2ccf688 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2305,7 +2305,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
 
 void intel_unpin_fb_vma(struct i915_vma *vma, unsigned long flags)
 {
-   i915_gem_object_lock(vma->obj);
+   i915_gem_object_lock(vma->obj, NULL);
if (flags & PLANE_HAS_FENCE)
i915_vma_unpin_fence(vma);
i915_gem_object_unpin_from_display_plane(vma);
@@ -17136,7 +17136,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
if (!intel_fb->frontbuffer)
return -ENOMEM;
 
-   i915_gem_object_lock(obj);
+   i915_gem_object_lock(obj, NULL);
tiling = i915_gem_object_get_tiling(obj);
stride = i915_gem_object_get_stride(obj);
i915_gem_object_unlock(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c 
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 0598e5382a1d..5d94a77f9bdd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -287,7 +287,7 @@ int i915_gem_schedule_fill_pages_blt(struct 
drm_i915_gem_object *obj,
dma_fence_init(&work->dma, &clear_pages_work_ops, &fence_lock, 0, 0);
i915_sw_fence_init(&work->wait, clear_pages_work_notify);
 
-   i915_gem_object_lock(obj);
+   i915_gem_object_lock(obj, NULL);
err = i915_sw_fence_await_reservation(&work->wait,
  obj->base.resv, NULL,
  true, I915_FENCE_TIMEOUT,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 50e7580f9337..ac2b88ca00ce 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -113,7 +113,7 @@ static void lut_close(struct i915_gem_context *ctx)
continue;
 
rcu_read_unlock();
-   i915_gem_object_lock(obj);
+   i915_gem_object_lock(obj, NULL);
list_for_each_entry(lut, &obj->lut_list, obj_link) {
if (lut->ctx != ctx)
continue;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 7db5a793739d..cfadccfc2990 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -128,7 +128,7 @@ static int i915_gem_begin_cpu_access(struct dma_buf 
*dma_buf, enum dma_data_dire
if (err)
return err;
 
-   err = i915_gem_object_lock_interruptible(obj);
+   err = i915_gem_object_lock_interruptible(obj, NULL);
if (err)
goto out;
 
@@ -149,7 +149,7 @@ static int i915_gem_end_cpu_access(struct dma_buf *dma_buf, 
enum dma_data_direct
if (err)
 

[Intel-gfx] [PATCH 20/21] drm/i915: Add ww locking to pin_to_display_plane

2020-03-24 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c | 57 --
 1 file changed, 41 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index e9d3b587f562..1833f58fa615 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -197,18 +197,12 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
if (ret)
return ret;
 
-   ret = i915_gem_object_lock_interruptible(obj, NULL);
-   if (ret)
-   return ret;
-
/* Always invalidate stale cachelines */
if (obj->cache_level != cache_level) {
i915_gem_object_set_cache_coherency(obj, cache_level);
obj->cache_dirty = true;
}
 
-   i915_gem_object_unlock(obj);
-
/* The cache-level will be applied when each vma is rebound. */
return i915_gem_object_unbind(obj,
  I915_GEM_OBJECT_UNBIND_ACTIVE |
@@ -255,6 +249,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_gem_caching *args = data;
struct drm_i915_gem_object *obj;
enum i915_cache_level level;
+   struct i915_gem_ww_ctx ww;
int ret = 0;
 
switch (args->caching) {
@@ -293,7 +288,18 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
void *data,
goto out;
}
 
-   ret = i915_gem_object_set_cache_level(obj, level);
+   i915_gem_ww_ctx_init(&ww, true);
+retry:
+   ret = i915_gem_object_lock(obj, &ww);
+   if (!ret)
+   ret = i915_gem_object_set_cache_level(obj, level);
+
+   if (ret == -EDEADLK) {
+   ret = i915_gem_ww_ctx_backoff(&ww);
+   if (!ret)
+   goto retry;
+   }
+   i915_gem_ww_ctx_fini(&ww);
 
 out:
i915_gem_object_put(obj);
@@ -313,6 +319,7 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
 unsigned int flags)
 {
struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   struct i915_gem_ww_ctx ww;
struct i915_vma *vma;
int ret;
 
@@ -320,6 +327,11 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj))
return ERR_PTR(-EINVAL);
 
+   i915_gem_ww_ctx_init(&ww, true);
+retry:
+   ret = i915_gem_object_lock(obj, &ww);
+   if (ret)
+   goto err;
/*
 * The display engine is not coherent with the LLC cache on gen6.  As
 * a result, we make sure that the pinning that is about to occur is
@@ -334,7 +346,7 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
  HAS_WT(i915) ?
  I915_CACHE_WT : I915_CACHE_NONE);
if (ret)
-   return ERR_PTR(ret);
+   goto err;
 
/*
 * As the user may map the buffer once pinned in the display plane
@@ -347,19 +359,32 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
vma = ERR_PTR(-ENOSPC);
if ((flags & PIN_MAPPABLE) == 0 &&
(!view || view->type == I915_GGTT_VIEW_NORMAL))
-   vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment,
-  flags |
-  PIN_MAPPABLE |
-  PIN_NONBLOCK);
-   if (IS_ERR(vma))
-   vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment, flags);
-   if (IS_ERR(vma))
-   return vma;
+   vma = i915_gem_object_ggtt_pin_ww(obj, &ww, view, 0, alignment,
+ flags | PIN_MAPPABLE |
+ PIN_NONBLOCK);
+   if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK))
+   vma = i915_gem_object_ggtt_pin_ww(obj, &ww, view, 0,
+ alignment, flags);
+   if (IS_ERR(vma)) {
+   ret = PTR_ERR(vma);
+   goto err;
+   }
 
vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
 
i915_gem_object_flush_if_display(obj);
 
+err:
+   if (ret == -EDEADLK) {
+   ret = i915_gem_ww_ctx_backoff(&ww);
+   if (!ret)
+   goto retry;
+   }
+   i915_gem_ww_ctx_fini(&ww);
+
+   if (ret)
+   return ERR_PTR(ret);
+
return vma;
 }
 
-- 
2.25.1

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


[Intel-gfx] [PATCH 10/21] drm/i915: Rework intel_context pinning to do everything outside of pin_mutex

2020-03-24 Thread Maarten Lankhorst
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us to take pin refcounts correctly
all the time.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gt/intel_context.c   | 233 +++---
 drivers/gpu/drm/i915/gt/intel_context_types.h |   4 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  34 ++-
 drivers/gpu/drm/i915/gt/intel_renderstate.c   |   1 -
 .../gpu/drm/i915/gt/intel_ring_submission.c   |  13 +-
 drivers/gpu/drm/i915/gt/mock_engine.c |  13 +-
 6 files changed, 191 insertions(+), 107 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index e4aece20bc80..bc0ed268ccb8 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -93,79 +93,6 @@ static void intel_context_active_release(struct 
intel_context *ce)
i915_active_release(&ce->active);
 }
 
-int __intel_context_do_pin(struct intel_context *ce)
-{
-   int err;
-
-   if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))) {
-   err = intel_context_alloc_state(ce);
-   if (err)
-   return err;
-   }
-
-   err = i915_active_acquire(&ce->active);
-   if (err)
-   return err;
-
-   if (mutex_lock_interruptible(&ce->pin_mutex)) {
-   err = -EINTR;
-   goto out_release;
-   }
-
-   if (unlikely(intel_context_is_closed(ce))) {
-   err = -ENOENT;
-   goto out_unlock;
-   }
-
-   if (likely(!atomic_add_unless(&ce->pin_count, 1, 0))) {
-   err = intel_context_active_acquire(ce);
-   if (unlikely(err))
-   goto out_unlock;
-
-   err = ce->ops->pin(ce);
-   if (unlikely(err))
-   goto err_active;
-
-   CE_TRACE(ce, "pin ring:{start:%08x, head:%04x, tail:%04x}\n",
-i915_ggtt_offset(ce->ring->vma),
-ce->ring->head, ce->ring->tail);
-
-   smp_mb__before_atomic(); /* flush pin before it is visible */
-   atomic_inc(&ce->pin_count);
-   }
-
-   GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
-   GEM_BUG_ON(i915_active_is_idle(&ce->active));
-   goto out_unlock;
-
-err_active:
-   intel_context_active_release(ce);
-out_unlock:
-   mutex_unlock(&ce->pin_mutex);
-out_release:
-   i915_active_release(&ce->active);
-   return err;
-}
-
-void intel_context_unpin(struct intel_context *ce)
-{
-   if (!atomic_dec_and_test(&ce->pin_count))
-   return;
-
-   CE_TRACE(ce, "unpin\n");
-   ce->ops->unpin(ce);
-
-   /*
-* Once released, we may asynchronously drop the active reference.
-* As that may be the only reference keeping the context alive,
-* take an extra now so that it is not freed before we finish
-* dereferencing it.
-*/
-   intel_context_get(ce);
-   intel_context_active_release(ce);
-   intel_context_put(ce);
-}
-
 static int __context_pin_state(struct i915_vma *vma)
 {
unsigned int bias = i915_ggtt_pin_bias(vma) | PIN_OFFSET_BIAS;
@@ -225,6 +152,138 @@ static void __ring_retire(struct intel_ring *ring)
i915_active_release(&ring->vma->active);
 }
 
+static int intel_context_pre_pin(struct intel_context *ce)
+{
+   int err;
+
+   CE_TRACE(ce, "active\n");
+
+   err = __ring_active(ce->ring);
+   if (err)
+   return err;
+
+   err = intel_timeline_pin(ce->timeline);
+   if (err)
+   goto err_ring;
+
+   if (!ce->state)
+   return 0;
+
+   err = __context_pin_state(ce->state);
+   if (err)
+   goto err_timeline;
+
+
+   return 0;
+
+err_timeline:
+   intel_timeline_unpin(ce->timeline);
+err_ring:
+   __ring_retire(ce->ring);
+   return err;
+}
+
+static void intel_context_post_unpin(struct intel_context *ce)
+{
+   if (ce->state)
+   __context_unpin_state(ce->state);
+
+   intel_timeline_unpin(ce->timeline);
+   __ring_retire(ce->ring);
+}
+
+int __intel_context_do_pin(struct intel_context *ce)
+{
+   bool handoff = false;
+   void *vaddr;
+   int err = 0;
+
+   if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))) {
+   err = intel_context_alloc_state(ce);
+   if (err)
+   return err;
+   }
+
+   /*
+* We always pin the context/ring/timeline here, to ensure a pin
+* refcount for __intel_context_active(), which prevent a lock
+* inversion of ce->pin_mutex vs dma_resv_lock().
+*/
+   err = intel_context_pre_pin

[Intel-gfx] [PATCH 14/21] drm/i915: Convert i915_perf to ww locking as well

2020-03-24 Thread Maarten Lankhorst
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.

We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_perf.c | 57 +++-
 1 file changed, 42 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3222f6cd8255..030d614d12ae 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1231,24 +1231,39 @@ static struct intel_context *oa_pin_context(struct 
i915_perf_stream *stream)
struct i915_gem_engines_iter it;
struct i915_gem_context *ctx = stream->ctx;
struct intel_context *ce;
-   int err;
+   struct i915_gem_ww_ctx ww;
+   int err = -ENODEV;
 
for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
if (ce->engine != stream->engine) /* first match! */
continue;
 
-   /*
-* As the ID is the gtt offset of the context's vma we
-* pin the vma to ensure the ID remains fixed.
-*/
-   err = intel_context_pin(ce);
-   if (err == 0) {
-   stream->pinned_ctx = ce;
-   break;
-   }
+   err = 0;
+   break;
}
i915_gem_context_unlock_engines(ctx);
 
+   if (err)
+   return ERR_PTR(err);
+
+   i915_gem_ww_ctx_init(&ww, true);
+retry:
+   /*
+* As the ID is the gtt offset of the context's vma we
+* pin the vma to ensure the ID remains fixed.
+*/
+   err = intel_context_pin_ww(ce, &ww);
+   if (err == -EDEADLK) {
+   err = i915_gem_ww_ctx_backoff(&ww);
+   if (!err)
+   goto retry;
+   }
+   i915_gem_ww_ctx_fini(&ww);
+
+   if (err)
+   return ERR_PTR(err);
+
+   stream->pinned_ctx = ce;
return stream->pinned_ctx;
 }
 
@@ -1968,15 +1983,22 @@ emit_oa_config(struct i915_perf_stream *stream,
 {
struct i915_request *rq;
struct i915_vma *vma;
+   struct i915_gem_ww_ctx ww;
int err;
 
vma = get_oa_vma(stream, oa_config);
if (IS_ERR(vma))
return ERR_CAST(vma);
 
-   err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
+   i915_gem_ww_ctx_init(&ww, true);
+retry:
+   err = i915_gem_object_lock(vma->obj, &ww);
if (err)
-   goto err_vma_put;
+   goto err;
+
+   err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_GLOBAL | PIN_HIGH);
+   if (err)
+   goto err;
 
intel_engine_pm_get(ce->engine);
rq = i915_request_create(ce);
@@ -1986,11 +2008,9 @@ emit_oa_config(struct i915_perf_stream *stream,
goto err_vma_unpin;
}
 
-   i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, 0);
if (!err)
err = i915_vma_move_to_active(vma, rq, 0);
-   i915_vma_unlock(vma);
if (err)
goto err_add_request;
 
@@ -2005,7 +2025,14 @@ emit_oa_config(struct i915_perf_stream *stream,
i915_request_add(rq);
 err_vma_unpin:
i915_vma_unpin(vma);
-err_vma_put:
+err:
+   if (err == -EDEADLK) {
+   err = i915_gem_ww_ctx_backoff(&ww);
+   if (!err)
+   goto retry;
+   }
+
+   i915_gem_ww_ctx_fini(&ww);
i915_vma_put(vma);
return err ? ERR_PTR(err) : rq;
 }
-- 
2.25.1

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


[Intel-gfx] [PATCH 09/21] drm/i915: Pin engine before pinning all objects, v3.

2020-03-24 Thread Maarten Lankhorst
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take the fastpath, if not we will take the slowpath and wait for
the throttle request while unlocked.

The engine has to be pinned as first step, otherwise gpu relocations
won't work.

Changes since v1:
- Only need to get a throttled request in the fastpath, no need for
  a global flag any more.
- Always free the waited request correctly.
Changes since v2:
- Use intel_engine_pm_get()/put() to keeep engine pool alive during
  EDEADLK handling.

Signed-off-by: Maarten Lankhorst 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 174 --
 1 file changed, 118 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 32b00c668c06..d9dd6303658f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -16,6 +16,7 @@
 #include "gem/i915_gem_ioctls.h"
 #include "gt/intel_context.h"
 #include "gt/intel_engine_pool.h"
+#include "gt/intel_engine_pm.h"
 #include "gt/intel_gt.h"
 #include "gt/intel_gt_pm.h"
 #include "gt/intel_ring.h"
@@ -55,7 +56,8 @@ enum {
 #define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN | 
__EXEC_OBJECT_HAS_FENCE)
 
 #define __EXEC_HAS_RELOC   BIT(31)
-#define __EXEC_INTERNAL_FLAGS  (~0u << 31)
+#define __EXEC_ENGINE_PINNED   BIT(30)
+#define __EXEC_INTERNAL_FLAGS  (~0u << 30)
 #define UPDATE PIN_OFFSET_FIXED
 
 #define BATCH_OFFSET_BIAS (256*1024)
@@ -288,6 +290,9 @@ struct i915_execbuffer {
 };
 
 static int eb_parse(struct i915_execbuffer *eb);
+static struct i915_request *eb_pin_engine(struct i915_execbuffer *eb,
+ bool throttle);
+static void eb_unpin_engine(struct i915_execbuffer *eb);
 
 static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
 {
@@ -898,7 +903,7 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned long 
handle)
}
 }
 
-static void eb_release_vmas(const struct i915_execbuffer *eb, bool final)
+static void eb_release_vmas(struct i915_execbuffer *eb, bool final)
 {
const unsigned int count = eb->buffer_count;
unsigned int i;
@@ -915,6 +920,8 @@ static void eb_release_vmas(const struct i915_execbuffer 
*eb, bool final)
if (final)
i915_vma_put(vma);
}
+
+   eb_unpin_engine(eb);
 }
 
 static void eb_destroy(const struct i915_execbuffer *eb)
@@ -1715,7 +1722,8 @@ static int eb_prefault_relocations(const struct 
i915_execbuffer *eb)
return 0;
 }
 
-static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb,
+  struct i915_request *rq)
 {
bool have_copy = false;
struct eb_vma *ev;
@@ -1731,6 +1739,21 @@ static noinline int eb_relocate_parse_slow(struct 
i915_execbuffer *eb)
eb_release_vmas(eb, false);
i915_gem_ww_ctx_fini(&eb->ww);
 
+   if (rq) {
+   /* nonblocking is always false */
+   if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
+ MAX_SCHEDULE_TIMEOUT) < 0) {
+   i915_request_put(rq);
+   rq = NULL;
+
+   err = -EINTR;
+   goto err_relock;
+   }
+
+   i915_request_put(rq);
+   rq = NULL;
+   }
+
/*
 * We take 3 passes through the slowpatch.
 *
@@ -1754,14 +1777,25 @@ static noinline int eb_relocate_parse_slow(struct 
i915_execbuffer *eb)
err = 0;
}
 
-   flush_workqueue(eb->i915->mm.userptr_wq);
+   if (!err)
+   flush_workqueue(eb->i915->mm.userptr_wq);
 
+err_relock:
i915_gem_ww_ctx_init(&eb->ww, true);
if (err)
goto out;
 
/* reacquire the objects */
 repeat_validate:
+   rq = eb_pin_engine(eb, false);
+   if (IS_ERR(rq)) {
+   err = PTR_ERR(rq);
+   goto err;
+   }
+
+   /* We didn't throttle, should be NULL */
+   GEM_WARN_ON(rq);
+
err = eb_validate_vmas(eb);
if (err)
goto err;
@@ -1825,14 +1859,47 @@ static noinline int eb_relocate_parse_slow(struct 
i915_execbuffer *eb)
}
}
 
+   if (rq)
+   i915_request_put(rq);
+
return err;
 }
 
 static int eb_relocate_parse(struct i915_execbuffer *eb)
 {
int err;
+   struct i915_request *rq = NULL;
+   bool throttle = true;
 
 retry:
+   rq = eb_pin_engine(eb, throttle);
+   if (IS_ERR(rq)) {
+   err = PTR_ERR(rq);
+ 

[Intel-gfx] [PATCH 17/21] drm/i915: Use ww pinning for intel_context_create_request()

2020-03-24 Thread Maarten Lankhorst
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5c7acddf9651..f70135685552 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -450,15 +450,25 @@ int intel_context_prepare_remote_request(struct 
intel_context *ce,
 
 struct i915_request *intel_context_create_request(struct intel_context *ce)
 {
+   struct i915_gem_ww_ctx ww;
struct i915_request *rq;
int err;
 
-   err = intel_context_pin(ce);
-   if (unlikely(err))
-   return ERR_PTR(err);
+   i915_gem_ww_ctx_init(&ww, true);
+retry:
+   err = intel_context_pin_ww(ce, &ww);
+   if (!err) {
+   rq = i915_request_create(ce);
+   intel_context_unpin(ce);
+   } else if (err == -EDEADLK) {
+   err = i915_gem_ww_ctx_backoff(&ww);
+   if (!err)
+   goto retry;
+   } else {
+   rq = ERR_PTR(err);
+   }
 
-   rq = i915_request_create(ce);
-   intel_context_unpin(ce);
+   i915_gem_ww_ctx_fini(&ww);
 
if (IS_ERR(rq))
return rq;
-- 
2.25.1

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


[Intel-gfx] [PATCH 12/21] drm/i915: Convert i915_gem_object/client_blt.c to use ww locking as well, v2.

2020-03-24 Thread Maarten Lankhorst
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.

With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.

Changes since v1:
- Add intel_engine_pm_get/put() calls to fix use-after-free when using
  intel_engine_get_pool().

Signed-off-by: Maarten Lankhorst 
---
 .../gpu/drm/i915/gem/i915_gem_client_blt.c|  80 +++--
 .../gpu/drm/i915/gem/i915_gem_object_blt.c| 156 +++---
 .../gpu/drm/i915/gem/i915_gem_object_blt.h|   3 +
 3 files changed, 165 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c 
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 5d94a77f9bdd..10df576e785f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -157,6 +157,7 @@ static void clear_pages_worker(struct work_struct *work)
struct clear_pages_work *w = container_of(work, typeof(*w), work);
struct drm_i915_gem_object *obj = w->sleeve->vma->obj;
struct i915_vma *vma = w->sleeve->vma;
+   struct i915_gem_ww_ctx ww;
struct i915_request *rq;
struct i915_vma *batch;
int err = w->dma.error;
@@ -172,17 +173,20 @@ static void clear_pages_worker(struct work_struct *work)
obj->read_domains = I915_GEM_GPU_DOMAINS;
obj->write_domain = 0;
 
-   err = i915_vma_pin(vma, 0, 0, PIN_USER);
-   if (unlikely(err))
+   i915_gem_ww_ctx_init(&ww, false);
+   intel_engine_pm_get(w->ce->engine);
+retry:
+   err = intel_context_pin_ww(w->ce, &ww);
+   if (err)
goto out_signal;
 
-   batch = intel_emit_vma_fill_blt(w->ce, vma, w->value);
+   batch = intel_emit_vma_fill_blt(w->ce, vma, &ww, w->value);
if (IS_ERR(batch)) {
err = PTR_ERR(batch);
-   goto out_unpin;
+   goto out_ctx;
}
 
-   rq = intel_context_create_request(w->ce);
+   rq = i915_request_create(w->ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
goto out_batch;
@@ -224,9 +228,19 @@ static void clear_pages_worker(struct work_struct *work)
i915_request_add(rq);
 out_batch:
intel_emit_vma_release(w->ce, batch);
-out_unpin:
-   i915_vma_unpin(vma);
+out_ctx:
+   intel_context_unpin(w->ce);
 out_signal:
+   if (err == -EDEADLK) {
+   err = i915_gem_ww_ctx_backoff(&ww);
+   if (!err)
+   goto retry;
+   }
+   i915_gem_ww_ctx_fini(&ww);
+
+   i915_vma_unpin(w->sleeve->vma);
+   intel_engine_pm_put(w->ce->engine);
+
if (unlikely(err)) {
dma_fence_set_error(&w->dma, err);
dma_fence_signal(&w->dma);
@@ -234,6 +248,45 @@ static void clear_pages_worker(struct work_struct *work)
}
 }
 
+static int pin_wait_clear_pages_work(struct clear_pages_work *w,
+struct intel_context *ce)
+{
+   struct i915_vma *vma = w->sleeve->vma;
+   struct i915_gem_ww_ctx ww;
+   int err;
+
+   i915_gem_ww_ctx_init(&ww, false);
+retry:
+   err = i915_gem_object_lock(vma->obj, &ww);
+   if (err)
+   goto out;
+
+   err = i915_vma_pin_ww(vma, &ww, 0, 0, PIN_USER);
+   if (unlikely(err))
+   goto out;
+
+   err = i915_sw_fence_await_reservation(&w->wait,
+ vma->obj->base.resv, NULL,
+ true, I915_FENCE_TIMEOUT,
+ I915_FENCE_GFP);
+   if (err)
+   goto err_unpin_vma;
+
+   dma_resv_add_excl_fence(vma->obj->base.resv, &w->dma);
+
+err_unpin_vma:
+   if (err)
+   i915_vma_unpin(vma);
+out:
+   if (err == -EDEADLK) {
+   err = i915_gem_ww_ctx_backoff(&ww);
+   if (!err)
+   goto retry;
+   }
+   i915_gem_ww_ctx_fini(&ww);
+   return err;
+}
+
 static int __i915_sw_fence_call
 clear_pages_work_notify(struct i915_sw_fence *fence,
enum i915_sw_fence_notify state)
@@ -287,18 +340,9 @@ int i915_gem_schedule_fill_pages_blt(struct 
drm_i915_gem_object *obj,
dma_fence_init(&work->dma, &clear_pages_work_ops, &fence_lock, 0, 0);
i915_sw_fence_init(&work->wait, clear_pages_work_notify);
 
-   i915_gem_object_lock(obj, NULL);
-   err = i915_sw_fence_await_reservation(&work->wait,
- obj->base.resv, NULL,
- true, I915_FENCE_TIMEOUT,
- I915_FENCE_GFP);
-   if (err < 0) {
+   err = pin_wait_clear_pages_work(work, ce);
+   if (err < 0)
dma_fence_set_error(&work->dma, err);
-   } else {
-   dma_resv_add_e

[Intel-gfx] [PATCH 06/21] drm/i915: Use ww locking in intel_renderstate.

2020-03-24 Thread Maarten Lankhorst
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.

Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gt/intel_gt.c  | 21 +++---
 drivers/gpu/drm/i915/gt/intel_renderstate.c | 71 ++---
 drivers/gpu/drm/i915/gt/intel_renderstate.h |  9 ++-
 3 files changed, 65 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 2f8d790a6a23..08efadf616a0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -406,21 +406,20 @@ static int __engines_record_defaults(struct intel_gt *gt)
/* We must be able to switch to something! */
GEM_BUG_ON(!engine->kernel_context);
 
-   err = intel_renderstate_init(&so, engine);
-   if (err)
-   goto out;
-
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
err = PTR_ERR(ce);
goto out;
}
 
-   rq = intel_context_create_request(ce);
+   err = intel_renderstate_init(&so, ce);
+   if (err)
+   goto err;
+
+   rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
-   intel_context_put(ce);
-   goto out;
+   goto err_fini;
}
 
err = intel_engine_emit_ctx_wa(rq);
@@ -434,9 +433,13 @@ static int __engines_record_defaults(struct intel_gt *gt)
 err_rq:
requests[id] = i915_request_get(rq);
i915_request_add(rq);
-   intel_renderstate_fini(&so);
-   if (err)
+err_fini:
+   intel_renderstate_fini(&so, ce);
+err:
+   if (err) {
+   intel_context_put(ce);
goto out;
+   }
}
 
/* Flush the default context image to memory, and enable powersaving. */
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.c 
b/drivers/gpu/drm/i915/gt/intel_renderstate.c
index ca533d98d14d..c65554c431f8 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.c
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.c
@@ -27,6 +27,7 @@
 
 #include "i915_drv.h"
 #include "intel_renderstate.h"
+#include "gt/intel_context.h"
 #include "intel_ring.h"
 
 static const struct intel_renderstate_rodata *
@@ -74,10 +75,9 @@ static int render_state_setup(struct intel_renderstate *so,
u32 *d;
int ret;
 
-   i915_gem_object_lock(so->vma->obj, NULL);
ret = i915_gem_object_prepare_write(so->vma->obj, &needs_clflush);
if (ret)
-   goto out_unlock;
+   return ret;
 
d = kmap_atomic(i915_gem_object_get_dirty_page(so->vma->obj, 0));
 
@@ -158,8 +158,6 @@ static int render_state_setup(struct intel_renderstate *so,
ret = 0;
 out:
i915_gem_object_finish_access(so->vma->obj);
-out_unlock:
-   i915_gem_object_unlock(so->vma->obj);
return ret;
 
 err:
@@ -171,33 +169,47 @@ static int render_state_setup(struct intel_renderstate 
*so,
 #undef OUT_BATCH
 
 int intel_renderstate_init(struct intel_renderstate *so,
-  struct intel_engine_cs *engine)
+  struct intel_context *ce)
 {
-   struct drm_i915_gem_object *obj;
+   struct intel_engine_cs *engine = ce->engine;
+   struct drm_i915_gem_object *obj = NULL;
int err;
 
memset(so, 0, sizeof(*so));
 
so->rodata = render_state_get_rodata(engine);
-   if (!so->rodata)
-   return 0;
+   if (so->rodata) {
+   if (so->rodata->batch_items * 4 > PAGE_SIZE)
+   return -EINVAL;
+
+   obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
+
+   so->vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
+   if (IS_ERR(so->vma)) {
+   err = PTR_ERR(so->vma);
+   goto err_obj;
+   }
+   }
 
-   if (so->rodata->batch_items * 4 > PAGE_SIZE)
-   return -EINVAL;
+   i915_gem_ww_ctx_init(&so->ww, true);
+retry:
+   err = intel_context_pin(ce);
+   if (err)
+   goto err_fini;
 
-   obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
-   if (IS_ERR(obj))
-   return PTR_ERR(obj);
+   /* return early if there's nothing to setup */
+   if (!err && !so->rodata)
+   return 0;
 
-   so->vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
-   if (

[Intel-gfx] [PATCH 13/21] drm/i915: Kill last user of intel_context_create_request outside of selftests

2020-03-24 Thread Maarten Lankhorst
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.

Now all those calls are gone outside of selftests. :)

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
 1 file changed, 29 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index e96cc7fa0936..d866f5903554 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1744,6 +1744,7 @@ static int engine_wa_list_verify(struct intel_context *ce,
const struct i915_wa *wa;
struct i915_request *rq;
struct i915_vma *vma;
+   struct i915_gem_ww_ctx ww;
unsigned int i;
u32 *results;
int err;
@@ -1756,29 +1757,34 @@ static int engine_wa_list_verify(struct intel_context 
*ce,
return PTR_ERR(vma);
 
intel_engine_pm_get(ce->engine);
-   rq = intel_context_create_request(ce);
-   intel_engine_pm_put(ce->engine);
+   i915_gem_ww_ctx_init(&ww, false);
+retry:
+   err = i915_gem_object_lock(vma->obj, &ww);
+   if (err == 0)
+   err = intel_context_pin_ww(ce, &ww);
+   if (err)
+   goto err_pm;
+
+   rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
-   goto err_vma;
+   goto err_unpin;
}
 
-   i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
-   i915_vma_unlock(vma);
-   if (err) {
-   i915_request_add(rq);
-   goto err_vma;
-   }
-
-   err = wa_list_srm(rq, wal, vma);
-   if (err)
-   goto err_vma;
+   if (err == 0)
+   err = wa_list_srm(rq, wal, vma);
 
i915_request_get(rq);
+   if (err)
+   i915_request_set_error_once(rq, err);
i915_request_add(rq);
+
+   if (err)
+   goto err_rq;
+
if (i915_request_wait(rq, 0, HZ / 5) < 0) {
err = -ETIME;
goto err_rq;
@@ -1803,7 +1809,16 @@ static int engine_wa_list_verify(struct intel_context 
*ce,
 
 err_rq:
i915_request_put(rq);
-err_vma:
+err_unpin:
+   intel_context_unpin(ce);
+err_pm:
+   if (err == -EDEADLK) {
+   err = i915_gem_ww_ctx_backoff(&ww);
+   if (!err)
+   goto retry;
+   }
+   i915_gem_ww_ctx_fini(&ww);
+   intel_engine_pm_put(ce->engine);
i915_vma_unpin(vma);
i915_vma_put(vma);
return err;
-- 
2.25.1

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


[Intel-gfx] [PATCH 18/21] drm/i915: Move i915_vma_lock in the selftests to avoid lock inversion

2020-03-24 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 .../i915/gem/selftests/i915_gem_coherency.c   | 26 ++-
 drivers/gpu/drm/i915/selftests/i915_request.c | 18 -
 2 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index 99f8466a108a..d93b7d9ad174 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -199,25 +199,25 @@ static int gpu_set(struct context *ctx, unsigned long 
offset, u32 v)
 
i915_gem_object_lock(ctx->obj, NULL);
err = i915_gem_object_set_to_gtt_domain(ctx->obj, true);
-   i915_gem_object_unlock(ctx->obj);
if (err)
-   return err;
+   goto out_unlock;
 
vma = i915_gem_object_ggtt_pin(ctx->obj, NULL, 0, 0, 0);
-   if (IS_ERR(vma))
-   return PTR_ERR(vma);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto out_unlock;
+   }
 
rq = intel_engine_create_kernel_request(ctx->engine);
if (IS_ERR(rq)) {
-   i915_vma_unpin(vma);
-   return PTR_ERR(rq);
+   err = PTR_ERR(rq);
+   goto out_unpin;
}
 
cs = intel_ring_begin(rq, 4);
if (IS_ERR(cs)) {
-   i915_request_add(rq);
-   i915_vma_unpin(vma);
-   return PTR_ERR(cs);
+   err = PTR_ERR(cs);
+   goto out_rq;
}
 
if (INTEL_GEN(ctx->engine->i915) >= 8) {
@@ -238,14 +238,16 @@ static int gpu_set(struct context *ctx, unsigned long 
offset, u32 v)
}
intel_ring_advance(rq, cs);
 
-   i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
-   i915_vma_unlock(vma);
-   i915_vma_unpin(vma);
 
+out_rq:
i915_request_add(rq);
+out_unpin:
+   i915_vma_unpin(vma);
+out_unlock:
+   i915_gem_object_unlock(ctx->obj);
 
return err;
 }
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c 
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 7ac9616de9d8..7f1150fc7767 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -848,6 +848,8 @@ static int live_all_engines(void *arg)
goto out_free;
}
 
+   i915_vma_lock(batch);
+
idx = 0;
for_each_uabi_engine(engine, i915) {
request[idx] = intel_engine_create_kernel_request(engine);
@@ -865,11 +867,9 @@ static int live_all_engines(void *arg)
GEM_BUG_ON(err);
request[idx]->batch = batch;
 
-   i915_vma_lock(batch);
err = i915_request_await_object(request[idx], batch->obj, 0);
if (err == 0)
err = i915_vma_move_to_active(batch, request[idx], 0);
-   i915_vma_unlock(batch);
GEM_BUG_ON(err);
 
i915_request_get(request[idx]);
@@ -877,6 +877,8 @@ static int live_all_engines(void *arg)
idx++;
}
 
+   i915_vma_unlock(batch);
+
idx = 0;
for_each_uabi_engine(engine, i915) {
if (i915_request_completed(request[idx])) {
@@ -967,12 +969,13 @@ static int live_sequential_engines(void *arg)
goto out_free;
}
 
+   i915_vma_lock(batch);
request[idx] = intel_engine_create_kernel_request(engine);
if (IS_ERR(request[idx])) {
err = PTR_ERR(request[idx]);
pr_err("%s: Request allocation failed for %s with 
err=%d\n",
   __func__, engine->name, err);
-   goto out_request;
+   goto out_unlock;
}
 
if (prev) {
@@ -982,7 +985,7 @@ static int live_sequential_engines(void *arg)
i915_request_add(request[idx]);
pr_err("%s: Request await failed for %s with 
err=%d\n",
   __func__, engine->name, err);
-   goto out_request;
+   goto out_unlock;
}
}
 
@@ -993,12 +996,10 @@ static int live_sequential_engines(void *arg)
GEM_BUG_ON(err);
request[idx]->batch = batch;
 
-   i915_vma_lock(batch);
err = i915_request_await_object(request[idx],
batch->obj, false);
if (err == 0)
err = i915_vma_move_to_active(batch, request[idx], 0);
-   i915_vma_unlock(batch);
GEM_BUG_ON(err);
 
i915

[Intel-gfx] [PATCH 03/21] drm/i915: Remove locking from i915_gem_object_prepare_read/write

2020-03-24 Thread Maarten Lankhorst
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.

This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c| 20 ++-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 13 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  1 -
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  5 -
 .../i915/gem/selftests/i915_gem_coherency.c   | 14 +
 .../drm/i915/gem/selftests/i915_gem_context.c | 12 ---
 drivers/gpu/drm/i915/gt/intel_renderstate.c   |  5 -
 drivers/gpu/drm/i915/gvt/cmd_parser.c |  9 -
 drivers/gpu/drm/i915/i915_gem.c   | 20 +--
 9 files changed, 70 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index f4602faa8db9..e9d3b587f562 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -581,19 +581,17 @@ int i915_gem_object_prepare_read(struct 
drm_i915_gem_object *obj,
if (!i915_gem_object_has_struct_page(obj))
return -ENODEV;
 
-   ret = i915_gem_object_lock_interruptible(obj, NULL);
-   if (ret)
-   return ret;
+   assert_object_held(obj);
 
ret = i915_gem_object_wait(obj,
   I915_WAIT_INTERRUPTIBLE,
   MAX_SCHEDULE_TIMEOUT);
if (ret)
-   goto err_unlock;
+   return ret;
 
ret = i915_gem_object_pin_pages(obj);
if (ret)
-   goto err_unlock;
+   return ret;
 
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ ||
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -621,8 +619,6 @@ int i915_gem_object_prepare_read(struct drm_i915_gem_object 
*obj,
 
 err_unpin:
i915_gem_object_unpin_pages(obj);
-err_unlock:
-   i915_gem_object_unlock(obj);
return ret;
 }
 
@@ -635,20 +631,18 @@ int i915_gem_object_prepare_write(struct 
drm_i915_gem_object *obj,
if (!i915_gem_object_has_struct_page(obj))
return -ENODEV;
 
-   ret = i915_gem_object_lock_interruptible(obj, NULL);
-   if (ret)
-   return ret;
+   assert_object_held(obj);
 
ret = i915_gem_object_wait(obj,
   I915_WAIT_INTERRUPTIBLE |
   I915_WAIT_ALL,
   MAX_SCHEDULE_TIMEOUT);
if (ret)
-   goto err_unlock;
+   return ret;
 
ret = i915_gem_object_pin_pages(obj);
if (ret)
-   goto err_unlock;
+   return ret;
 
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE ||
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -685,7 +679,5 @@ int i915_gem_object_prepare_write(struct 
drm_i915_gem_object *obj,
 
 err_unpin:
i915_gem_object_unpin_pages(obj);
-err_unlock:
-   i915_gem_object_unlock(obj);
return ret;
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 28d5a0ce79e8..6e865a034d11 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -960,11 +960,14 @@ static void reloc_cache_reset(struct reloc_cache *cache)
 
vaddr = unmask_page(cache->vaddr);
if (cache->vaddr & KMAP) {
+   struct drm_i915_gem_object *obj =
+   (struct drm_i915_gem_object *)cache->node.mm;
if (cache->vaddr & CLFLUSH_AFTER)
mb();
 
kunmap_atomic(vaddr);
-   i915_gem_object_finish_access((struct drm_i915_gem_object 
*)cache->node.mm);
+   i915_gem_object_finish_access(obj);
+   i915_gem_object_unlock(obj);
} else {
struct i915_ggtt *ggtt = cache_to_ggtt(cache);
 
@@ -999,10 +1002,16 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
unsigned int flushes;
int err;
 
-   err = i915_gem_object_prepare_write(obj, &flushes);
+   err = i915_gem_object_lock_interruptible(obj, NULL);
if (err)
return ERR_PTR(err);
 
+   err = i915_gem_object_prepare_write(obj, &flushes);
+   if (err) {
+   i915_gem_object_unlock(obj);
+   return ERR_PTR(err);
+   }
+
BUILD_BUG_ON(KMAP & CLFLUSH_FLAGS);
BUILD_BUG_ON((KMAP | CLFLUSH_FLAGS) & PAGE_MASK);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 5103067269b0..11b8e27350

[Intel-gfx] [PATCH 19/21] drm/i915: Add ww locking to vm_fault_gtt

2020-03-24 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
 1 file changed, 33 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..e35e8d0b6938 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -283,37 +283,46 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
struct intel_runtime_pm *rpm = &i915->runtime_pm;
struct i915_ggtt *ggtt = &i915->ggtt;
bool write = area->vm_flags & VM_WRITE;
+   struct i915_gem_ww_ctx ww;
intel_wakeref_t wakeref;
struct i915_vma *vma;
pgoff_t page_offset;
int srcu;
int ret;
 
-   /* Sanity check that we allow writing into this object */
-   if (i915_gem_object_is_readonly(obj) && write)
-   return VM_FAULT_SIGBUS;
-
/* We don't use vmf->pgoff since that has the fake offset */
page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
 
trace_i915_gem_object_fault(obj, page_offset, true, write);
 
-   ret = i915_gem_object_pin_pages(obj);
+   wakeref = intel_runtime_pm_get(rpm);
+
+   i915_gem_ww_ctx_init(&ww, true);
+retry:
+   ret = i915_gem_object_lock(obj, &ww);
if (ret)
-   goto err;
+   goto err_rpm;
 
-   wakeref = intel_runtime_pm_get(rpm);
+   /* Sanity check that we allow writing into this object */
+   if (i915_gem_object_is_readonly(obj) && write) {
+   ret = -EFAULT;
+   goto err_rpm;
+   }
 
-   ret = intel_gt_reset_trylock(ggtt->vm.gt, &srcu);
+   ret = i915_gem_object_pin_pages(obj);
if (ret)
goto err_rpm;
 
+   ret = intel_gt_reset_trylock(ggtt->vm.gt, &srcu);
+   if (ret)
+   goto err_pages;
+
/* Now pin it into the GTT as needed */
-   vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
-  PIN_MAPPABLE |
-  PIN_NONBLOCK /* NOWARN */ |
-  PIN_NOEVICT);
-   if (IS_ERR(vma)) {
+   vma = i915_gem_object_ggtt_pin_ww(obj, &ww, NULL, 0, 0,
+ PIN_MAPPABLE |
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
+   if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK)) {
/* Use a partial view if it is bigger than available space */
struct i915_ggtt_view view =
compute_partial_view(obj, page_offset, MIN_CHUNK_PAGES);
@@ -328,11 +337,11 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
 * all hope that the hardware is able to track future writes.
 */
 
-   vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
-   if (IS_ERR(vma)) {
+   vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0, 0, flags);
+   if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK)) {
flags = PIN_MAPPABLE;
view.type = I915_GGTT_VIEW_PARTIAL;
-   vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
+   vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0, 
0, flags);
}
 
/* The entire mappable GGTT is pinned? Unexpected! */
@@ -389,10 +398,16 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
__i915_vma_unpin(vma);
 err_reset:
intel_gt_reset_unlock(ggtt->vm.gt, srcu);
+err_pages:
+   i915_gem_object_unpin_pages(obj);
 err_rpm:
+   if (ret == -EDEADLK) {
+   ret = i915_gem_ww_ctx_backoff(&ww);
+   if (!ret)
+   goto retry;
+   }
+   i915_gem_ww_ctx_fini(&ww);
intel_runtime_pm_put(rpm, wakeref);
-   i915_gem_object_unpin_pages(obj);
-err:
return i915_error_to_vmf_fault(ret);
 }
 
-- 
2.25.1

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


[Intel-gfx] [PATCH 04/21] drm/i915: Parse command buffer earlier in eb_relocate(slow)

2020-03-24 Thread Maarten Lankhorst
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get called from execbuf
relocation fast and slowpath.

Signed-off-by: Maarten Lankhorst 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 68 ++-
 1 file changed, 37 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6e865a034d11..8bb96308362b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -285,6 +285,8 @@ struct i915_execbuffer {
struct hlist_head *buckets; /** ht for relocation handles */
 };
 
+static int eb_parse(struct i915_execbuffer *eb);
+
 static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
 {
return intel_engine_requires_cmd_parser(eb->engine) ||
@@ -814,6 +816,7 @@ static struct i915_vma *eb_lookup_vma(struct 
i915_execbuffer *eb, u32 handle)
 
 static int eb_lookup_vmas(struct i915_execbuffer *eb)
 {
+   struct drm_i915_private *i915 = eb->i915;
unsigned int batch = eb_batch_index(eb);
unsigned int i;
int err = 0;
@@ -827,18 +830,37 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
vma = eb_lookup_vma(eb, eb->exec[i].handle);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
-   break;
+   goto err;
}
 
err = eb_validate_vma(eb, &eb->exec[i], vma);
if (unlikely(err)) {
i915_vma_put(vma);
-   break;
+   goto err;
}
 
eb_add_vma(eb, i, batch, vma);
}
 
+   if (unlikely(eb->batch->flags & EXEC_OBJECT_WRITE)) {
+   drm_dbg(&i915->drm,
+   "Attempting to use self-modifying batch buffer\n");
+   return -EINVAL;
+   }
+
+   if (range_overflows_t(u64,
+ eb->batch_start_offset, eb->batch_len,
+ eb->batch->vma->size)) {
+   drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
+   return -EINVAL;
+   }
+
+   if (eb->batch_len == 0)
+   eb->batch_len = eb->batch->vma->size - eb->batch_start_offset;
+
+   return 0;
+
+err:
eb->vma[i].vma = NULL;
return err;
 }
@@ -1688,7 +1710,7 @@ static int eb_prefault_relocations(const struct 
i915_execbuffer *eb)
return 0;
 }
 
-static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
 {
bool have_copy = false;
struct eb_vma *ev;
@@ -1739,6 +1761,11 @@ static noinline int eb_relocate_slow(struct 
i915_execbuffer *eb)
}
}
 
+   /* as last step, parse the command buffer */
+   err = eb_parse(eb);
+   if (err)
+   goto err;
+
/*
 * Leave the user relocations as are, this is the painfully slow path,
 * and we want to avoid the complication of dropping the lock whilst
@@ -1771,7 +1798,7 @@ static noinline int eb_relocate_slow(struct 
i915_execbuffer *eb)
return err;
 }
 
-static int eb_relocate(struct i915_execbuffer *eb)
+static int eb_relocate_parse(struct i915_execbuffer *eb)
 {
int err;
 
@@ -1791,11 +1818,11 @@ static int eb_relocate(struct i915_execbuffer *eb)
 
list_for_each_entry(ev, &eb->relocs, reloc_link) {
if (eb_relocate_vma(eb, ev))
-   return eb_relocate_slow(eb);
+   return eb_relocate_parse_slow(eb);
}
}
 
-   return 0;
+   return eb_parse(eb);
 }
 
 static int eb_move_to_gpu(struct i915_execbuffer *eb)
@@ -2731,7 +2758,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_context;
 
-   err = eb_relocate(&eb);
+   err = eb_relocate_parse(&eb);
if (err) {
/*
 * If the user expects the execobject.offset and
@@ -2744,33 +2771,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_vma;
}
 
-   if (unlikely(eb.batch->flags & EXEC_OBJECT_WRITE)) {
-   drm_dbg(&i915->drm,
-   "Attempting to use self-modifying batch buffer\n");
-   err = -EINVAL;
-   goto err_vma;
-   }
-
-   if (range_overflows_t(u64,
- eb.batch_start_offset, eb.batch_len,
- eb.batch->vma->size)) {
-   drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
-   

[Intel-gfx] [PATCH 05/21] drm/i915: Use per object locking in execbuf, v6.

2020-03-24 Thread Maarten Lankhorst
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.

This finally allows us to do parallel submission, but because not
all of the pinning code uses the ww ctx yet, we cannot completely
drop struct_mutex yet.

Changes since v1:
- Keep struct_mutex for now. :(
Changes since v2:
- Make sure we always lock the ww context in slowpath.
Changes since v3:
- Don't call __eb_unreserve_vma in eb_move_to_gpu now; this can be
  done on normal unlock path.
- Unconditionally release vmas and context.
Changes since v4:
- Rebased on top of struct_mutex reduction.
Changes since v5:
- Remove training wheels.

Signed-off-by: Maarten Lankhorst 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 271 ++
 1 file changed, 148 insertions(+), 123 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 8bb96308362b..6f7191486e1e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -249,6 +249,8 @@ struct i915_execbuffer {
/** list of vma that have execobj.relocation_count */
struct list_head relocs;
 
+   struct i915_gem_ww_ctx ww;
+
/**
 * Track the most recently used object for relocations, as we
 * frequently have to perform multiple relocations within the same
@@ -404,24 +406,18 @@ eb_pin_vma(struct i915_execbuffer *eb,
return !eb_vma_misplaced(entry, vma, ev->flags);
 }
 
-static inline void __eb_unreserve_vma(struct i915_vma *vma, unsigned int flags)
-{
-   GEM_BUG_ON(!(flags & __EXEC_OBJECT_HAS_PIN));
-
-   if (unlikely(flags & __EXEC_OBJECT_HAS_FENCE))
-   __i915_vma_unpin_fence(vma);
-
-   __i915_vma_unpin(vma);
-}
-
 static inline void
 eb_unreserve_vma(struct eb_vma *ev)
 {
if (!(ev->flags & __EXEC_OBJECT_HAS_PIN))
return;
 
-   __eb_unreserve_vma(ev->vma, ev->flags);
ev->flags &= ~__EXEC_OBJECT_RESERVED;
+
+   if (unlikely(ev->flags & __EXEC_OBJECT_HAS_FENCE))
+   __i915_vma_unpin_fence(ev->vma);
+
+   __i915_vma_unpin(ev->vma);
 }
 
 static int
@@ -515,16 +511,6 @@ eb_add_vma(struct i915_execbuffer *eb,
 
eb->batch = ev;
}
-
-   if (eb_pin_vma(eb, entry, ev)) {
-   if (entry->offset != vma->node.start) {
-   entry->offset = vma->node.start | UPDATE;
-   eb->args->flags |= __EXEC_HAS_RELOC;
-   }
-   } else {
-   eb_unreserve_vma(ev);
-   list_add_tail(&ev->bind_link, &eb->unbound);
-   }
 }
 
 static inline int use_cpu_reloc(const struct reloc_cache *cache,
@@ -628,18 +614,14 @@ static int eb_reserve(struct i915_execbuffer *eb)
 * This avoid unnecessary unbinding of later objects in order to make
 * room for the earlier objects *unless* we need to defragment.
 */
-
-   if (mutex_lock_interruptible(&eb->i915->drm.struct_mutex))
-   return -EINTR;
-
pass = 0;
do {
list_for_each_entry(ev, &eb->unbound, bind_link) {
err = eb_reserve_vma(eb, ev, pin_flags);
if (err)
-   break;
+   return err;
}
-   if (!(err == -ENOSPC || err == -EAGAIN))
+   if (err != -ENOSPC)
break;
 
/* Resort *all* the objects into priority order */
@@ -670,13 +652,6 @@ static int eb_reserve(struct i915_execbuffer *eb)
}
list_splice_tail(&last, &eb->unbound);
 
-   if (err == -EAGAIN) {
-   mutex_unlock(&eb->i915->drm.struct_mutex);
-   flush_workqueue(eb->i915->mm.userptr_wq);
-   mutex_lock(&eb->i915->drm.struct_mutex);
-   continue;
-   }
-
switch (pass++) {
case 0:
break;
@@ -687,19 +662,16 @@ static int eb_reserve(struct i915_execbuffer *eb)
err = i915_gem_evict_vm(eb->context->vm);
mutex_unlock(&eb->context->vm->mutex);
if (err)
-   goto unlock;
+   return err;
break;
 
default:
-   err = -ENOSPC;
-   goto unlock;
+   return -ENOSPC;
}
 
pin_flags = PIN_USER;
} while (1);
 
-unlock:
-   mutex_unlock(&eb->i915->drm.struct_mutex);
return err;
 }
 
@@ -822,7 +794,6 @@ static int eb_lookup_vmas(struct 

[Intel-gfx] [PATCH 07/21] drm/i915: Add ww context handling to context_barrier_task

2020-03-24 Thread Maarten Lankhorst
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 55 ++-
 .../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
 2 files changed, 48 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ac2b88ca00ce..062848951095 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1097,6 +1097,7 @@ I915_SELFTEST_DECLARE(static intel_engine_mask_t 
context_barrier_inject_fault);
 static int context_barrier_task(struct i915_gem_context *ctx,
intel_engine_mask_t engines,
bool (*skip)(struct intel_context *ce, void 
*data),
+   int (*pin)(struct intel_context *ce, struct 
i915_gem_ww_ctx *ww, void *data),
int (*emit)(struct i915_request *rq, void 
*data),
void (*task)(void *data),
void *data)
@@ -1104,6 +1105,7 @@ static int context_barrier_task(struct i915_gem_context 
*ctx,
struct context_barrier_task *cb;
struct i915_gem_engines_iter it;
struct i915_gem_engines *e;
+   struct i915_gem_ww_ctx ww;
struct intel_context *ce;
int err = 0;
 
@@ -1141,10 +1143,21 @@ static int context_barrier_task(struct i915_gem_context 
*ctx,
if (skip && skip(ce, data))
continue;
 
-   rq = intel_context_create_request(ce);
+   i915_gem_ww_ctx_init(&ww, true);
+retry:
+   err = intel_context_pin(ce);
+   if (err)
+   goto err;
+
+   if (pin)
+   err = pin(ce, &ww, data);
+   if (err)
+   goto err_unpin;
+
+   rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
-   break;
+   goto err_unpin;
}
 
err = 0;
@@ -1154,6 +1167,16 @@ static int context_barrier_task(struct i915_gem_context 
*ctx,
err = i915_active_add_request(&cb->base, rq);
 
i915_request_add(rq);
+err_unpin:
+   intel_context_unpin(ce);
+err:
+   if (err == -EDEADLK) {
+   err = i915_gem_ww_ctx_backoff(&ww);
+   if (!err)
+   goto retry;
+   }
+   i915_gem_ww_ctx_fini(&ww);
+
if (err)
break;
}
@@ -1209,6 +1232,17 @@ static void set_ppgtt_barrier(void *data)
i915_vm_close(old);
 }
 
+static int pin_ppgtt_update(struct intel_context *ce, struct i915_gem_ww_ctx 
*ww, void *data)
+{
+   struct i915_address_space *vm = ce->vm;
+
+   if (!HAS_LOGICAL_RING_CONTEXTS(vm->i915))
+   /* ppGTT is not part of the legacy context image */
+   return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm));
+
+   return 0;
+}
+
 static int emit_ppgtt_update(struct i915_request *rq, void *data)
 {
struct i915_address_space *vm = rq->context->vm;
@@ -1265,20 +1299,10 @@ static int emit_ppgtt_update(struct i915_request *rq, 
void *data)
 
 static bool skip_ppgtt_update(struct intel_context *ce, void *data)
 {
-   if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))
-   return true;
-
if (HAS_LOGICAL_RING_CONTEXTS(ce->engine->i915))
-   return false;
-
-   if (!atomic_read(&ce->pin_count))
-   return true;
-
-   /* ppGTT is not part of the legacy context image */
-   if (gen6_ppgtt_pin(i915_vm_to_ppgtt(ce->vm)))
-   return true;
-
-   return false;
+   return !ce->state;
+   else
+   return !atomic_read(&ce->pin_count);
 }
 
 static int set_ppgtt(struct drm_i915_file_private *file_priv,
@@ -1329,6 +1353,7 @@ static int set_ppgtt(struct drm_i915_file_private 
*file_priv,
 */
err = context_barrier_task(ctx, ALL_ENGINES,
   skip_ppgtt_update,
+  pin_ppgtt_update,
   emit_ppgtt_update,
   set_ppgtt_barrier,
   old);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index a9b149d60737..e5a7b2e6f444 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1903,8 +1903,8 @@ static int mock_context_barrier(void *arg)
return -ENOMEM;
 
counter = 0;
-   err = context_barrier_task(ctx, 0,
-

[Intel-gfx] [PATCH 08/21] drm/i915: Nuke arguments to eb_pin_engine

2020-03-24 Thread Maarten Lankhorst
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6f7191486e1e..32b00c668c06 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2414,11 +2414,10 @@ static void eb_unpin_engine(struct i915_execbuffer *eb)
 }
 
 static unsigned int
-eb_select_legacy_ring(struct i915_execbuffer *eb,
- struct drm_file *file,
- struct drm_i915_gem_execbuffer2 *args)
+eb_select_legacy_ring(struct i915_execbuffer *eb)
 {
struct drm_i915_private *i915 = eb->i915;
+   struct drm_i915_gem_execbuffer2 *args = eb->args;
unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
 
if (user_ring_id != I915_EXEC_BSD &&
@@ -2433,7 +2432,7 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
 
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
-   bsd_idx = gen8_dispatch_bsd_engine(i915, file);
+   bsd_idx = gen8_dispatch_bsd_engine(i915, eb->file);
} else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
   bsd_idx <= I915_EXEC_BSD_RING2) {
bsd_idx >>= I915_EXEC_BSD_SHIFT;
@@ -2458,18 +2457,16 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
 }
 
 static int
-eb_pin_engine(struct i915_execbuffer *eb,
- struct drm_file *file,
- struct drm_i915_gem_execbuffer2 *args)
+eb_pin_engine(struct i915_execbuffer *eb)
 {
struct intel_context *ce;
unsigned int idx;
int err;
 
if (i915_gem_context_user_engines(eb->gem_context))
-   idx = args->flags & I915_EXEC_RING_MASK;
+   idx = eb->args->flags & I915_EXEC_RING_MASK;
else
-   idx = eb_select_legacy_ring(eb, file, args);
+   idx = eb_select_legacy_ring(eb);
 
ce = i915_gem_context_get_engine(eb->gem_context, idx);
if (IS_ERR(ce))
@@ -2767,7 +2764,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_destroy;
 
-   err = eb_pin_engine(&eb, file, args);
+   err = eb_pin_engine(&eb);
if (unlikely(err))
goto err_context;
 
-- 
2.25.1

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


Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and CRTC

2020-03-24 Thread Ville Syrjälä
On Tue, Mar 24, 2020 at 03:32:09PM +, Laxminarayan Bharadiya, Pankaj wrote:
> 
> 
> > -Original Message-
> > From: Ville Syrjälä 
> > Sent: 23 March 2020 20:18
> > To: Laxminarayan Bharadiya, Pankaj
> > 
> > Cc: Lattannavar, Sameer ;
> > jani.nik...@linux.intel.com; dan...@ffwll.ch; 
> > intel-gfx@lists.freedesktop.org;
> > dri-de...@lists.freedesktop.org; dani...@collabora.com; Joonas Lahtinen
> > ; Vivi, Rodrigo ;
> > David Airlie ; Chris Wilson ;
> > Maarten Lankhorst ; Souza, Jose
> > ; Deak, Imre ; Shankar, Uma
> > 
> > Subject: Re: [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and 
> > CRTC
> > 
> > On Thu, Mar 19, 2020 at 03:51:03PM +0530, Pankaj Bharadiya wrote:
> > > GEN >= 10 hardware supports the programmable scaler filter.
> > >
> > > Attach scaling filter property for CRTC and plane for GEN >= 10
> > > hardwares and program scaler filter based on the selected filter type.
> > >
> > > changes since v1:
> > > * None
> > > Changes since RFC:
> > > * Enable properties for GEN >= 10 platforms (Ville)
> > > * Do not round off the crtc co-ordinate (Danial Stone, Ville)
> > > * Add new functions to handle scaling filter setup (Ville)
> > > * Remove coefficient set 0 hardcoding.
> > >
> > > Signed-off-by: Shashank Sharma 
> > > Signed-off-by: Ankit Nautiyal 
> > > Signed-off-by: Pankaj Bharadiya
> > > 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 32
> > > ++--  drivers/gpu/drm/i915/display/intel_sprite.c  |
> > > 31 ++-
> > >  2 files changed, 60 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 791dd908aa89..4b3387ee332e 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -6309,6 +6309,25 @@ void
> > skl_scaler_setup_nearest_neighbor_filter(struct drm_i915_private *dev_priv,
> > >   }
> > >  }
> > >
> > > +static u32
> > > +skl_scaler_crtc_setup_filter(struct drm_i915_private *dev_priv, enum pipe
> > pipe,
> > > +   int id, int set, enum drm_crtc_scaling_filter filter) 
> > > {
> > > + u32 scaler_filter_ctl = PS_FILTER_MEDIUM;
> > > +
> > > + if (filter == DRM_CRTC_SCALING_FILTER_NEAREST_NEIGHBOR) {
> > > + skl_scaler_setup_nearest_neighbor_filter(dev_priv, pipe, id,
> > > +  set);
> > > + scaler_filter_ctl = PS_FILTER_PROGRAMMED |
> > > + PS_UV_VERT_FILTER_SELECT(set) |
> > > + PS_UV_HORZ_FILTER_SELECT(set) |
> > > + PS_Y_VERT_FILTER_SELECT(set) |
> > > + PS_Y_HORZ_FILTER_SELECT(set);
> > > +
> > > + }
> > > + return scaler_filter_ctl;
> > 
> > This function does too many things.
> 
> I was thinking to have a common function which configures the filter and also
> provides the register bits (ps_ctrl) to select a desired filter so that we 
> need
> not have extra condition to figure out filter select register bits where this
> function is being called.
> How about renaming this function to some better name like  
> skl_scaler_set_and_get_filter_select() or something else? 
> Or shall I breakdown this function into multiple functions?

I'd just inline the PS_CTRL stuff into the current function.

> 
> Any suggestions?
> 
> > 
> > > +}
> > > +
> > >  static void skl_pfit_enable(const struct intel_crtc_state
> > > *crtc_state)  {
> > >   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > @@ -6316,12 +6335,14 @@ static void skl_pfit_enable(const struct
> > intel_crtc_state *crtc_state)
> > >   enum pipe pipe = crtc->pipe;
> > >   const struct intel_crtc_scaler_state *scaler_state =
> > >   &crtc_state->scaler_state;
> > > + const struct drm_crtc_state *state = &crtc_state->uapi;
> > 
> > Pls don't add this kind of aliases. We're moving away from using the drm_ 
> > types
> > as much as possible.
> 
> OK.
> 
> > 
> > >
> > >   if (crtc_state->pch_pfit.enabled) {
> > >   u16 uv_rgb_hphase, uv_rgb_vphase;
> > >   int pfit_w, pfit_h, hscale, vscale;
> > >   unsigned long irqflags;
> > >   int id;
> > > + int scaler_filter_ctl;
> > 
> > It's a register value so u32. I'd also
> 
> Yes, I missed it. Thanks for pointing out.
> 
> > s/scaler_filter_ctl/filter_select/ or something like that.
> > 
> > Alternatively we could just call it ps_ctrl and have it contain the full 
> > register
> > value for that particular register.
> 
> ps_ctrl sounds better, will use this name.
> 
> > 
> > >
> > >   if (drm_WARN_ON(&dev_priv->drm,
> > >   crtc_state->scaler_state.scaler_id < 0)) @@ -
> > 6340,8 +6361,12 @@
> > > static void skl_pfit_enable(const struct intel_crtc_state *crtc_state)
> > >
> > >   spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> > >
> > > - intel_de_writ

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Introduce scaling filter related registers and bit fields.

2020-03-24 Thread Ville Syrjälä
On Tue, Mar 24, 2020 at 02:36:10PM +, Laxminarayan Bharadiya, Pankaj wrote:
> 
> 
> > -Original Message-
> > From: Ville Syrjälä 
> > Sent: 23 March 2020 20:09
> > To: Laxminarayan Bharadiya, Pankaj
> > 
> > Cc: Lattannavar, Sameer ;
> > jani.nik...@linux.intel.com; dan...@ffwll.ch; 
> > intel-gfx@lists.freedesktop.org;
> > dri-de...@lists.freedesktop.org; dani...@collabora.com; Joonas Lahtinen
> > ; Vivi, Rodrigo ;
> > David Airlie 
> > Subject: Re: [PATCH v2 3/5] drm/i915: Introduce scaling filter related 
> > registers
> > and bit fields.
> > 
> > On Thu, Mar 19, 2020 at 03:51:01PM +0530, Pankaj Bharadiya wrote:
> > > Introduce scaler registers and bit fields needed to configure the
> > > scaling filter in prgrammed mode and configure scaling filter
> > > coefficients.
> > >
> > > changes since v1:
> > > * None
> > > changes since RFC:
> > > * Parametrize scaler coeffient macros by 'set' (Ville)
> > >
> > > Signed-off-by: Shashank Sharma 
> > > Signed-off-by: Ankit Nautiyal 
> > > Signed-off-by: Pankaj Bharadiya
> > > 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h | 48
> > > +
> > >  1 file changed, 48 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h index 9c53fe918be6..d40f12d2a6b5
> > > 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7205,6 +7205,7 @@ enum {
> > >  #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
> > >  #define PS_FILTER_MASK (3 << 23)
> > >  #define PS_FILTER_MEDIUM   (0 << 23)
> > > +#define PS_FILTER_PROGRAMMED   (1 << 23)
> > >  #define PS_FILTER_EDGE_ENHANCE (2 << 23)
> > >  #define PS_FILTER_BILINEAR (3 << 23)
> > >  #define PS_VERT3TAP(1 << 21)
> > > @@ -7219,6 +7220,10 @@ enum {
> > >  #define PS_VADAPT_MODE_MOST_ADAPT  (3 << 5)  #define
> > > PS_PLANE_Y_SEL_MASK  (7 << 5)  #define PS_PLANE_Y_SEL(plane) (((plane)
> > > + 1) << 5)
> > > +#define PS_Y_VERT_FILTER_SELECT(set)   ((set) << 4)
> > > +#define PS_Y_HORZ_FILTER_SELECT(set)   ((set) << 3)
> > > +#define PS_UV_VERT_FILTER_SELECT(set)  ((set) << 2) #define
> > > +PS_UV_HORZ_FILTER_SELECT(set)  ((set) << 1)
> > >
> > >  #define _PS_PWR_GATE_1A 0x68160
> > >  #define _PS_PWR_GATE_2A 0x68260
> > > @@ -7281,6 +7286,25 @@ enum {
> > >  #define _PS_ECC_STAT_2B 0x68AD0
> > >  #define _PS_ECC_STAT_1C 0x691D0
> > >
> > > +#define _PS_COEF_SET0_INDEX_1A  0x68198
> > > +#define _PS_COEF_SET0_INDEX_2A  0x68298
> > > +#define _PS_COEF_SET0_INDEX_1B  0x68998
> > > +#define _PS_COEF_SET0_INDEX_2B  0x68A98
> > > +#define _PS_COEF_SET1_INDEX_1A  0x681A0
> > > +#define _PS_COEF_SET1_INDEX_2A  0x682A0
> > > +#define _PS_COEF_SET1_INDEX_1B  0x689A0
> > > +#define _PS_COEF_SET1_INDEX_2B  0x68AA0
> > > +#define PS_COEE_INDEX_AUTO_INC  (1 << 10)
> > > +
> > > +#define _PS_COEF_SET0_DATA_1A   0x6819C
> > > +#define _PS_COEF_SET0_DATA_2A   0x6829C
> > > +#define _PS_COEF_SET0_DATA_1B   0x6899C
> > > +#define _PS_COEF_SET0_DATA_2B   0x68A9C
> > > +#define _PS_COEF_SET1_DATA_1A   0x681A4
> > > +#define _PS_COEF_SET1_DATA_2A   0x682A4
> > > +#define _PS_COEF_SET1_DATA_1B   0x689A4
> > > +#define _PS_COEF_SET1_DATA_2B   0x68AA4
> > > +
> > >  #define _ID(id, a, b) _PICK_EVEN(id, a, b)
> > >  #define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
> > >   _ID(id, _PS_1A_CTRL, _PS_2A_CTRL),   \
> > > @@ -7310,6 +7334,30 @@ enum {
> > >   _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
> > >   _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> > >
> > > +#define _SKL_PS_COEF_INDEX_SET0(pipe, id)  _ID(pipe,\
> > > + _ID(id, _PS_COEF_SET0_INDEX_1A,
> > _PS_COEF_SET0_INDEX_2A), \
> > > + _ID(id, _PS_COEF_SET0_INDEX_1B,
> > _PS_COEF_SET0_INDEX_2B))
> > > +
> > > +#define _SKL_PS_COEF_INDEX_SET1(pipe, id)  _ID(pipe,\
> > > + _ID(id, _PS_COEF_SET1_INDEX_1A,
> > _PS_COEF_SET1_INDEX_2A), \
> > > + _ID(id, _PS_COEF_SET1_INDEX_1B,
> > _PS_COEF_SET1_INDEX_2B))
> > > +
> > > +#define _SKL_PS_COEF_DATA_SET0(pipe, id)  _ID(pipe, \
> > > + _ID(id, _PS_COEF_SET0_DATA_1A,
> > _PS_COEF_SET0_DATA_2A), \
> > > + _ID(id, _PS_COEF_SET0_DATA_1B,
> > _PS_COEF_SET0_DATA_2B))
> > > +
> > > +#define _SKL_PS_COEF_DATA_SET1(pipe, id)  _ID(pipe, \
> > > + _ID(id, _PS_COEF_SET1_DATA_1A,
> > _PS_COEF_SET1_DATA_2A), \
> > > + _ID(id, _PS_COEF_SET1_DATA_1B,
> > _PS_COEF_SET1_DATA_2B))
> > > +
> > > +#define SKL_PS_COEF_INDEX_SET(pipe, id, set) \
> > > + _MMIO_PIPE(set, _SKL_PS_COEF_INDEX_SET0(pipe, id),
> > \
> > > + _SKL_PS_COEF_INDEX_SET1(pipe, id))
> > > +
> > > +#define SKL_PS_COEF_DATA_SET(pipe, id, set) \
> > > + _MMIO_PIPE(set, _SKL_PS_COEF_DATA_SET0(pipe, id),
> > \
> 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission

2020-03-24 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-03-24 16:11:10)
> 
> On 24/03/2020 12:07, Chris Wilson wrote:
> > We dropped calling process_csb prior to handling direct submission in
> > order to avoid the nesting of spinlocks and lift process_csb() and the
> > majority of the tasklet out of irq-off. However, we do want to avoid
> > ksoftirqd latency in the fast path, so try and pull the interrupt-bh
> > local to direct submission if we can acquire the tasklet's lock.
> 
> Oh and important question - who benefits and how much?

Anything that doesn't want to be deferred to a tasklet like wsim, where
it helps fix a small regression in tip. That and avoiding the worker
where we didn't use to have one. Did not see a difference in syslatency,
so that's still a bone of contention for direction submission.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/2] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission

2020-03-24 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-03-24 16:04:47)
> 
> On 24/03/2020 12:07, Chris Wilson wrote:
> > We dropped calling process_csb prior to handling direct submission in
> > order to avoid the nesting of spinlocks and lift process_csb() and the
> > majority of the tasklet out of irq-off. However, we do want to avoid
> > ksoftirqd latency in the fast path, so try and pull the interrupt-bh
> > local to direct submission if we can acquire the tasklet's lock.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_lrc.c | 6 ++
> >   1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 210f60e14ef4..82dee2141b46 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -2891,6 +2891,12 @@ static void __submit_queue_imm(struct 
> > intel_engine_cs *engine)
> >   if (reset_in_progress(execlists))
> >   return; /* defer until we restart the engine following reset 
> > */
> >   
> > + /* Hopefully we clear execlists->pending[] to let us through */
> > + if (execlists->pending[0] && tasklet_trylock(&execlists->tasklet))
> 
> Does access to pending needs a READ_ONCE?

Yes, we are peeking outside of the tasklet.

>   {
> > + process_csb(engine);
> > + tasklet_unlock(&execlists->tasklet);
> > + }
> > +
> >   __execlists_submission_tasklet(engine);
> >   }
> >   
> > 
> 
> __execlists_submission_tasklet does check with READ_ONCE.
> 
> I think locking is fine, given how normal flow is tasklet -> irqsave 
> engine lock, and here we have the reverse, but a trylock.

And inside process_csb() we don't take the active lock, so we just need
to serialise calls to process_csb(). We don't strictly rely on it as
it's just an optimisation for latency so we can trylock and not worry
about not making forward progress -- the tasklet *running* but waiting
on the execlists lock is sufficient to ensure that a dequeue will happen
after this point if we can't do it ourselves.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 7/8] drm/i915: Immediately execute the fenced work

2020-03-24 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-03-24 16:13:04)
> 
> On 23/03/2020 10:46, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-03-23 10:37:22)
> >>
> >> On 23/03/2020 09:28, Chris Wilson wrote:
> >>> If the caller allows and we do not have to wait for any signals,
> >>> immediately execute the work within the caller's process. By doing so we
> >>> avoid the overhead of scheduling a new task, and the latency in
> >>> executing it, at the cost of pulling that work back into the immediate
> >>> context. (Sometimes we still prefer to offload the task to another cpu,
> >>> especially if we plan on executing many such tasks in parallel for this
> >>> client.)
> >>>
> >>> Signed-off-by: Chris Wilson 
> >>> ---
> >>>drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  2 +-
> >>>drivers/gpu/drm/i915/i915_sw_fence_work.c  |  5 -
> >>>drivers/gpu/drm/i915/i915_sw_fence_work.h  | 12 
> >>>drivers/gpu/drm/i915/i915_vma.c|  2 +-
> >>>4 files changed, 18 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> >>> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> index c2bd5accde0c..e80c6f613feb 100644
> >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> @@ -1784,7 +1784,7 @@ static int eb_parse_pipeline(struct i915_execbuffer 
> >>> *eb,
> >>>dma_resv_add_excl_fence(shadow->resv, &pw->base.dma);
> >>>dma_resv_unlock(shadow->resv);
> >>>
> >>> - dma_fence_work_commit(&pw->base);
> >>> + dma_fence_work_commit_imm(&pw->base);
> >>>return 0;
> >>>
> >>>err_batch_unlock:
> >>> diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c 
> >>> b/drivers/gpu/drm/i915/i915_sw_fence_work.c
> >>> index 997b2998f1f2..a3a81bb8f2c3 100644
> >>> --- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
> >>> +++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
> >>> @@ -38,7 +38,10 @@ fence_notify(struct i915_sw_fence *fence, enum 
> >>> i915_sw_fence_notify state)
> >>>
> >>>if (!f->dma.error) {
> >>>dma_fence_get(&f->dma);
> >>> - queue_work(system_unbound_wq, &f->work);
> >>> + if (test_bit(DMA_FENCE_WORK_IMM, &f->dma.flags))
> >>> + fence_work(&f->work);
> >>> + else
> >>> + queue_work(system_unbound_wq, &f->work);
> >>>} else {
> >>>fence_complete(f);
> >>>}
> >>> diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.h 
> >>> b/drivers/gpu/drm/i915/i915_sw_fence_work.h
> >>> index 3a22b287e201..0719d661dc9c 100644
> >>> --- a/drivers/gpu/drm/i915/i915_sw_fence_work.h
> >>> +++ b/drivers/gpu/drm/i915/i915_sw_fence_work.h
> >>> @@ -32,6 +32,10 @@ struct dma_fence_work {
> >>>const struct dma_fence_work_ops *ops;
> >>>};
> >>>
> >>> +enum {
> >>> + DMA_FENCE_WORK_IMM = DMA_FENCE_FLAG_USER_BITS,
> >>> +};
> >>> +
> >>>void dma_fence_work_init(struct dma_fence_work *f,
> >>> const struct dma_fence_work_ops *ops);
> >>>int dma_fence_work_chain(struct dma_fence_work *f, struct dma_fence 
> >>> *signal);
> >>> @@ -41,4 +45,12 @@ static inline void dma_fence_work_commit(struct 
> >>> dma_fence_work *f)
> >>>i915_sw_fence_commit(&f->chain);
> >>>}
> >>>
> >>> +static inline void dma_fence_work_commit_imm(struct dma_fence_work *f)
> >>> +{
> >>> + if (atomic_read(&f->chain.pending) <= 1)
> >>> + __set_bit(DMA_FENCE_WORK_IMM, &f->dma.flags);
> >>> +
> >>
> >> What is someone bumps pending to 2 at this point?
> > 
> > That's invalid. The sequence is
> > 
> > create a worker
> > ... add all async waits ...
> > commit
> > 
> > Since the worker fires when pending waits hits zero, you cannot add any
> > more async waits after commit in a race free manner. You have to play
> > games, such as "is this fence already signaled? no, let's delay it
> > again". If you are playing such games, you know already and shouldn't be
> > trying to execute synchronously/immediately.
> 
> > A BUG_ON(!dma_fence_signaled(&f->dma)) would suffice to catch most such
> > races.
> 
> So the "if the callers allows" from the commit message means something 
> like "if pending is only one at the time of commit" ?

If the caller allows, means if it is valid to call the callback from
within the current context (i.e. within all the locks the caller holds).
And then there's the clflush where we not only worry about the locks in
the deep callpath, but also where we know that offloading the slow task
means we can parallelise better.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 7/8] drm/i915: Immediately execute the fenced work

2020-03-24 Thread Tvrtko Ursulin



On 23/03/2020 10:46, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-03-23 10:37:22)


On 23/03/2020 09:28, Chris Wilson wrote:

If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we still prefer to offload the task to another cpu,
especially if we plan on executing many such tasks in parallel for this
client.)

Signed-off-by: Chris Wilson 
---
   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  2 +-
   drivers/gpu/drm/i915/i915_sw_fence_work.c  |  5 -
   drivers/gpu/drm/i915/i915_sw_fence_work.h  | 12 
   drivers/gpu/drm/i915/i915_vma.c|  2 +-
   4 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index c2bd5accde0c..e80c6f613feb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1784,7 +1784,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
   dma_resv_add_excl_fence(shadow->resv, &pw->base.dma);
   dma_resv_unlock(shadow->resv);
   
- dma_fence_work_commit(&pw->base);

+ dma_fence_work_commit_imm(&pw->base);
   return 0;
   
   err_batch_unlock:

diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c 
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index 997b2998f1f2..a3a81bb8f2c3 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -38,7 +38,10 @@ fence_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
   
   if (!f->dma.error) {

   dma_fence_get(&f->dma);
- queue_work(system_unbound_wq, &f->work);
+ if (test_bit(DMA_FENCE_WORK_IMM, &f->dma.flags))
+ fence_work(&f->work);
+ else
+ queue_work(system_unbound_wq, &f->work);
   } else {
   fence_complete(f);
   }
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.h 
b/drivers/gpu/drm/i915/i915_sw_fence_work.h
index 3a22b287e201..0719d661dc9c 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.h
@@ -32,6 +32,10 @@ struct dma_fence_work {
   const struct dma_fence_work_ops *ops;
   };
   
+enum {

+ DMA_FENCE_WORK_IMM = DMA_FENCE_FLAG_USER_BITS,
+};
+
   void dma_fence_work_init(struct dma_fence_work *f,
const struct dma_fence_work_ops *ops);
   int dma_fence_work_chain(struct dma_fence_work *f, struct dma_fence *signal);
@@ -41,4 +45,12 @@ static inline void dma_fence_work_commit(struct 
dma_fence_work *f)
   i915_sw_fence_commit(&f->chain);
   }
   
+static inline void dma_fence_work_commit_imm(struct dma_fence_work *f)

+{
+ if (atomic_read(&f->chain.pending) <= 1)
+ __set_bit(DMA_FENCE_WORK_IMM, &f->dma.flags);
+


What is someone bumps pending to 2 at this point?


That's invalid. The sequence is

create a worker
... add all async waits ...
commit

Since the worker fires when pending waits hits zero, you cannot add any
more async waits after commit in a race free manner. You have to play
games, such as "is this fence already signaled? no, let's delay it
again". If you are playing such games, you know already and shouldn't be
trying to execute synchronously/immediately.



A BUG_ON(!dma_fence_signaled(&f->dma)) would suffice to catch most such
races.


So the "if the callers allows" from the commit message means something 
like "if pending is only one at the time of commit" ?


Regards,

Tvrtko


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


Re: [Intel-gfx] [PATCH 1/2] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission

2020-03-24 Thread Tvrtko Ursulin



On 24/03/2020 12:07, Chris Wilson wrote:

We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct submission if we can acquire the tasklet's lock.


Oh and important question - who benefits and how much?

Regards,

Tvrtko


Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/gt/intel_lrc.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 210f60e14ef4..82dee2141b46 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2891,6 +2891,12 @@ static void __submit_queue_imm(struct intel_engine_cs 
*engine)
if (reset_in_progress(execlists))
return; /* defer until we restart the engine following reset */
  
+	/* Hopefully we clear execlists->pending[] to let us through */

+   if (execlists->pending[0] && tasklet_trylock(&execlists->tasklet)) {
+   process_csb(engine);
+   tasklet_unlock(&execlists->tasklet);
+   }
+
__execlists_submission_tasklet(engine);
  }
  


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


Re: [Intel-gfx] [PATCH 1/2] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission

2020-03-24 Thread Tvrtko Ursulin



On 24/03/2020 12:07, Chris Wilson wrote:

We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct submission if we can acquire the tasklet's lock.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/gt/intel_lrc.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 210f60e14ef4..82dee2141b46 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2891,6 +2891,12 @@ static void __submit_queue_imm(struct intel_engine_cs 
*engine)
if (reset_in_progress(execlists))
return; /* defer until we restart the engine following reset */
  
+	/* Hopefully we clear execlists->pending[] to let us through */

+   if (execlists->pending[0] && tasklet_trylock(&execlists->tasklet))


Does access to pending needs a READ_ONCE?

 {

+   process_csb(engine);
+   tasklet_unlock(&execlists->tasklet);
+   }
+
__execlists_submission_tasklet(engine);
  }
  



__execlists_submission_tasklet does check with READ_ONCE.

I think locking is fine, given how normal flow is tasklet -> irqsave 
engine lock, and here we have the reverse, but a trylock.


Regards,

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


Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Add connector dbgfs for all connectors

2020-03-24 Thread Jani Nikula
On Tue, 24 Mar 2020, Anshuman Gupta  wrote:
> Add connector debugfs attributes for each intel
> connector which is getting register.

Okay, so this is a good idea, and for that,

Reviewed-by: Jani Nikula 

> v2:
> - adding connector debugfs for each connector in
>   intel_connector_register() to fix CI failure for legacy connectors.

However, it's *not* a good idea for the purpose of registering the lpsp
debugfs file for every connector out there. There's no point in that, at
all. You need to register the file only when it makes sense in
intel_connector_debugfs_add(), and not for every conceivable connector
out there.

And your igt test absolutely *must* check if the debugfs is there or
not, and handle it gracefully.

BR,
Jani.

>
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_connector.c | 3 +++
>  drivers/gpu/drm/i915/display/intel_dp.c| 3 ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c  | 3 ---
>  3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c 
> b/drivers/gpu/drm/i915/display/intel_connector.c
> index 903e49659f56..0cf5fe326a0b 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.c
> +++ b/drivers/gpu/drm/i915/display/intel_connector.c
> @@ -33,6 +33,7 @@
>  
>  #include "i915_drv.h"
>  #include "intel_connector.h"
> +#include "intel_display_debugfs.h"
>  #include "intel_display_types.h"
>  #include "intel_hdcp.h"
>  
> @@ -123,6 +124,8 @@ int intel_connector_register(struct drm_connector 
> *connector)
>   goto err_backlight;
>   }
>  
> + intel_connector_debugfs_add(connector);
> +
>   return 0;
>  
>  err_backlight:
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7f1a4e55cda1..c4352d013c29 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -48,7 +48,6 @@
>  #include "intel_audio.h"
>  #include "intel_connector.h"
>  #include "intel_ddi.h"
> -#include "intel_display_debugfs.h"
>  #include "intel_display_types.h"
>  #include "intel_dp.h"
>  #include "intel_dp_link_training.h"
> @@ -6204,8 +6203,6 @@ intel_dp_connector_register(struct drm_connector 
> *connector)
>   if (ret)
>   return ret;
>  
> - intel_connector_debugfs_add(connector);
> -
>   DRM_DEBUG_KMS("registering %s bus for %s\n",
> intel_dp->aux.name, connector->kdev->kobj.name);
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 39930232b253..2d4dced7143e 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -44,7 +44,6 @@
>  #include "intel_audio.h"
>  #include "intel_connector.h"
>  #include "intel_ddi.h"
> -#include "intel_display_debugfs.h"
>  #include "intel_display_types.h"
>  #include "intel_dp.h"
>  #include "intel_dpio_phy.h"
> @@ -2813,8 +2812,6 @@ intel_hdmi_connector_register(struct drm_connector 
> *connector)
>   if (ret)
>   return ret;
>  
> - intel_connector_debugfs_add(connector);
> -
>   intel_hdmi_create_i2c_symlink(connector);
>  
>   return ret;

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH i-g-t] i915/i915_pm_rc6_residency: Make ringbuffer rc6 fast

2020-03-24 Thread Andi Shyti
Hi Chris,

On Tue, Mar 24, 2020 at 12:52:33PM +, Chris Wilson wrote:
> The legacy ringbuffer submission lacks a fast soft-rc6
> mechanism as we have no interrupt for an idle ring. As such
> we are at the mercy of HW RC6... which is not quite as
> precise as we need to pass this test. Oh well.
> 
> Since HW is not fast enough to minimise power draw, tell the driver to
> park as soon as we know we are idle. One day, we hope for the driver to
> discover a mechanism to do this for itself, for as this test shows that
> can save us Watts!
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1516
> Signed-off-by: Chris Wilson 

Reviewed-by: Andi Shyti 

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


Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Add i915_lpsp_info debugfs

2020-03-24 Thread Jani Nikula
On Tue, 24 Mar 2020, Anshuman Gupta  wrote:
> New i915_pm_lpsp igt solution approach relies on connector specific
> debugfs attribute i915_lpsp_info, it exposes whether an output is
> capable of driving lpsp and exposes lpsp enablement info.
>
> v2:
> - CI fixup.
>
> Signed-off-by: Anshuman Gupta 
> ---
>  .../drm/i915/display/intel_display_debugfs.c  | 104 ++
>  1 file changed, 104 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 424f4e52f783..eb9d88341d48 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -9,6 +9,7 @@
>  #include "i915_debugfs.h"
>  #include "intel_csr.h"
>  #include "intel_display_debugfs.h"
> +#include "intel_display_power.h"
>  #include "intel_display_types.h"
>  #include "intel_dp.h"
>  #include "intel_fbc.h"
> @@ -611,6 +612,95 @@ static void intel_hdcp_info(struct seq_file *m,
>   seq_puts(m, "\n");
>  }
>  
> +static bool intel_have_embedded_panel(struct drm_connector *connector)
> +{
> + return connector->connector_type == DRM_MODE_CONNECTOR_DSI ||
> + connector->connector_type == DRM_MODE_CONNECTOR_eDP;

I know you don't care for this use case, but the function naming leads
one to believe this checks for at least LVDS panels too.

> +}
> +
> +static bool intel_have_gen9_lpsp_panel(struct drm_connector *connector)
> +{
> + return intel_have_embedded_panel(connector) ||
> + connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort;
> +}
> +
> +static int
> +intel_lpsp_power_well_enabled(struct drm_i915_private *dev_priv,
> +   enum i915_power_well_id power_well_id)
> +{
> + struct i915_power_domains *power_domains = &dev_priv->power_domains;
> + struct i915_power_well *power_well = NULL, *pw_itr;
> + bool is_enabled;
> +
> + mutex_lock(&power_domains->lock);
> +
> + for_each_power_well(dev_priv, pw_itr)
> + if (pw_itr->desc->id == power_well_id) {
> + power_well = pw_itr;
> + break;
> + }

I don't think this code has any business looking inside the guts of the
power well code. I see that intel_hdcp.c does this kind of loop too, and
that *also* shouldn't be doing that.

See intel_display_power_well_is_enabled(). Does what you want, and does
it correctly. So really, the whole intel_lpsp_power_well_enabled()
function shouldn't be added.

> +
> + if (drm_WARN_ON(&dev_priv->drm, !power_well)) {
> + mutex_unlock(&power_domains->lock);
> + /* Assume that BIOS has enabled the power well*/
> + return true;
> + }
> +
> + is_enabled = !!power_well->count;
> + mutex_unlock(&power_domains->lock);
> +
> + return is_enabled;
> +}
> +
> +static void
> +intel_lpsp_capable_info(struct seq_file *m, struct drm_connector *connector)
> +{
> + struct intel_encoder *encoder =
> + intel_attached_encoder(to_intel_connector(connector));
> + struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + bool lpsp_capable = false;
> +
> + if (IS_TIGERLAKE(dev_priv) && encoder->port <= PORT_C) {
> + lpsp_capable = true;
> + } else if (INTEL_GEN(dev_priv) >= 11 && 
> intel_have_embedded_panel(connector)) {
> + lpsp_capable = true;
> + } else if (INTEL_GEN(dev_priv) >= 9 && (encoder->port == PORT_A &&
> +intel_have_gen9_lpsp_panel(connector))) {
> + lpsp_capable = true;
> + } else if ((IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) &&
> +connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> + lpsp_capable = true;
> + } else {
> + seq_puts(m, "LPSP not supported\n");
> + return;
> + }

The whole if ladder above looks suspect, and I'm not sure your helpers
are helping here.

> +
> + lpsp_capable ? seq_puts(m, "LPSP capable\n") : seq_puts(m, "LPSP 
> incapable\n");

lpsp_capable is always true when you end up here.

> +}
> +
> +static void
> +intel_lpsp_enable_info(struct seq_file *m, struct drm_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + bool is_lpsp = false;
> +
> + if (INTEL_GEN(dev_priv) >= 11) {
> + is_lpsp = !intel_lpsp_power_well_enabled(dev_priv,
> +  ICL_DISP_PW_3);
> + } else if (INTEL_GEN(dev_priv) >= 9) {
> + is_lpsp = !intel_lpsp_power_well_enabled(dev_priv,
> +  SKL_DISP_PW_2);
> + } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> + is_lpsp = !intel_lpsp_power_well_enabled(dev_priv,
> +  HSW_DISP_PW_GLOBAL);

The abstraction should probably be to figure out the correct

Re: [Intel-gfx] [PATCH 2/2] drm/i915: move audio CDCLK constraint setup to bind/unbind

2020-03-24 Thread Kai Vehmanen
Hi Ville and others,

On Fri, 13 Mar 2020, Kai Vehmanen wrote:

> I do know that on more recent hardware (gen12), I will get failures if I 
> don't strictly follow the requirement. GLK is a special case as it has the 
> 79Mhz low cdclk. I've not been able to trigger the problem on other old 
> hardware though. So where to draw the line?
> 
> It's a fair point that if the old platforms have worked so far, we should 
> not make the change unless there is at least one data point supporting it. 
> So the constraint would then apply for gen12+ and glk.

given the not-so-great options on the table, I went back (again) looking 
for other solutions and came with a curious finding. The forced Codec Wake 
interface added to gen9 in 2015, seems to fix the gen12 codec probe issues 
as well, without the cdclk bump.

So it looks like the problem is not about the CDCLK being high enough, but 
something in hardware state that is fixed by doing a modeset. Or, as it 
seems to be the case, by using the chickebits to force the codec wake (and 
no need for modeset).

Based on hw specs, there is no valid reason to limit the forced codec wake 
only to gen9, so I went and sent a patch for this now. I've tested this on 
various gen9/10/11/12 platforms and also asked our validation to test it 
out, and seems everything seems good.

I also tried an experiment where I added the codec wake patch, but removed 
the forced cdclk bump on GLK, but that still fails, so on GLK, the CDCLK 
bump is still mandatory, and likely a separate problem. So this doesn't 
solve all the problems, but at least we can fix the currently reported 
bugs without causing any new compromises at system level.

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


Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and CRTC

2020-03-24 Thread Laxminarayan Bharadiya, Pankaj



> -Original Message-
> From: Ville Syrjälä 
> Sent: 23 March 2020 20:18
> To: Laxminarayan Bharadiya, Pankaj
> 
> Cc: Lattannavar, Sameer ;
> jani.nik...@linux.intel.com; dan...@ffwll.ch; intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; dani...@collabora.com; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Chris Wilson ;
> Maarten Lankhorst ; Souza, Jose
> ; Deak, Imre ; Shankar, Uma
> 
> Subject: Re: [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and CRTC
> 
> On Thu, Mar 19, 2020 at 03:51:03PM +0530, Pankaj Bharadiya wrote:
> > GEN >= 10 hardware supports the programmable scaler filter.
> >
> > Attach scaling filter property for CRTC and plane for GEN >= 10
> > hardwares and program scaler filter based on the selected filter type.
> >
> > changes since v1:
> > * None
> > Changes since RFC:
> > * Enable properties for GEN >= 10 platforms (Ville)
> > * Do not round off the crtc co-ordinate (Danial Stone, Ville)
> > * Add new functions to handle scaling filter setup (Ville)
> > * Remove coefficient set 0 hardcoding.
> >
> > Signed-off-by: Shashank Sharma 
> > Signed-off-by: Ankit Nautiyal 
> > Signed-off-by: Pankaj Bharadiya
> > 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 32
> > ++--  drivers/gpu/drm/i915/display/intel_sprite.c  |
> > 31 ++-
> >  2 files changed, 60 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 791dd908aa89..4b3387ee332e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -6309,6 +6309,25 @@ void
> skl_scaler_setup_nearest_neighbor_filter(struct drm_i915_private *dev_priv,
> > }
> >  }
> >
> > +static u32
> > +skl_scaler_crtc_setup_filter(struct drm_i915_private *dev_priv, enum pipe
> pipe,
> > + int id, int set, enum drm_crtc_scaling_filter filter) 
> > {
> > +   u32 scaler_filter_ctl = PS_FILTER_MEDIUM;
> > +
> > +   if (filter == DRM_CRTC_SCALING_FILTER_NEAREST_NEIGHBOR) {
> > +   skl_scaler_setup_nearest_neighbor_filter(dev_priv, pipe, id,
> > +set);
> > +   scaler_filter_ctl = PS_FILTER_PROGRAMMED |
> > +   PS_UV_VERT_FILTER_SELECT(set) |
> > +   PS_UV_HORZ_FILTER_SELECT(set) |
> > +   PS_Y_VERT_FILTER_SELECT(set) |
> > +   PS_Y_HORZ_FILTER_SELECT(set);
> > +
> > +   }
> > +   return scaler_filter_ctl;
> 
> This function does too many things.

I was thinking to have a common function which configures the filter and also
provides the register bits (ps_ctrl) to select a desired filter so that we need
not have extra condition to figure out filter select register bits where this
function is being called.
How about renaming this function to some better name like  
skl_scaler_set_and_get_filter_select() or something else? 
Or shall I breakdown this function into multiple functions? 

Any suggestions?

> 
> > +}
> > +
> >  static void skl_pfit_enable(const struct intel_crtc_state
> > *crtc_state)  {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > @@ -6316,12 +6335,14 @@ static void skl_pfit_enable(const struct
> intel_crtc_state *crtc_state)
> > enum pipe pipe = crtc->pipe;
> > const struct intel_crtc_scaler_state *scaler_state =
> > &crtc_state->scaler_state;
> > +   const struct drm_crtc_state *state = &crtc_state->uapi;
> 
> Pls don't add this kind of aliases. We're moving away from using the drm_ 
> types
> as much as possible.

OK.

> 
> >
> > if (crtc_state->pch_pfit.enabled) {
> > u16 uv_rgb_hphase, uv_rgb_vphase;
> > int pfit_w, pfit_h, hscale, vscale;
> > unsigned long irqflags;
> > int id;
> > +   int scaler_filter_ctl;
> 
> It's a register value so u32. I'd also

Yes, I missed it. Thanks for pointing out.

> s/scaler_filter_ctl/filter_select/ or something like that.
> 
> Alternatively we could just call it ps_ctrl and have it contain the full 
> register
> value for that particular register.

ps_ctrl sounds better, will use this name.

> 
> >
> > if (drm_WARN_ON(&dev_priv->drm,
> > crtc_state->scaler_state.scaler_id < 0)) @@ -
> 6340,8 +6361,12 @@
> > static void skl_pfit_enable(const struct intel_crtc_state *crtc_state)
> >
> > spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> >
> > -   intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id),
> PS_SCALER_EN |
> > - PS_FILTER_MEDIUM | scaler_state-
> >scalers[id].mode);
> > +   scaler_filter_ctl =
> > +   skl_scaler_crtc_setup_filter(dev_priv, pipe, id, 0,
> > +   state->scaling_filter);
> > +   intel_de_write_fw(

[Intel-gfx] [PATCH] drm/i915: use forced codec wake on all gen9+ platforms

2020-03-24 Thread Kai Vehmanen
Commit 632f3ab95fe2 ("drm/i915/audio: add codec wakeup override
enabled/disable callback"), added logic to toggle Codec Wake on gen9.
This is used by audio driver when it resets the HDA controller.

It seems explicit toggling of the wakeline can help to fix problems
with probe failing on some gen12 platforms. And based on specs, there
is no reason why this programming sequence should not be applied to all
gen9+ platforms. No side-effects are seen on gen10/11. So apply
the wake-logic to all gen9+ platforms.

Link: https://github.com/thesofproject/linux/issues/1847
Signed-off-by: Kai Vehmanen 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 62f234f641de..950160f1a89f 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -931,7 +931,7 @@ static void i915_audio_component_codec_wake_override(struct 
device *kdev,
unsigned long cookie;
u32 tmp;
 
-   if (!IS_GEN(dev_priv, 9))
+   if (INTEL_GEN(dev_priv) < 9)
return;
 
cookie = i915_audio_component_get_power(kdev);
-- 
2.17.1

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


Re: [Intel-gfx] [V8 7/9] drm/i915/dsi: Add TE handler for dsi cmd mode.

2020-03-24 Thread Jani Nikula
On Thu, 12 Mar 2020, Vandita Kulkarni  wrote:
> In case of dual link, we get the TE on slave.
> So clear the TE on slave DSI IIR.
>
> v2: Pass only relevant masked bits to the handler (Jani)
>
> v3: Fix the check for cmd mode in TE handler function.
>
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 64 +
>  1 file changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 89489a247276..2e1418515c9f 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2262,6 +2262,62 @@ gen8_de_misc_irq_handler(struct drm_i915_private 
> *dev_priv, u32 iir)
>   drm_err(&dev_priv->drm, "Unexpected DE Misc interrupt\n");
>  }
>  
> +void gen11_dsi_te_interrupt_handler(struct drm_i915_private *dev_priv,
> + u32 te_trigger)
> +{
> + enum pipe pipe = INVALID_PIPE;
> + enum transcoder dsi_trans;
> + enum port port;
> + u32 val, tmp;
> +
> + /*
> +  * Incase of dual link, TE comes from DSI_1
> +  * this is to check if dual link is enabled
> +  */
> + val = I915_READ(TRANS_DDI_FUNC_CTL2(TRANSCODER_DSI_0));
> + val &= PORT_SYNC_MODE_ENABLE;
> +
> + /*
> +  * if dual link is enabled, then read DSI_0
> +  * transcoder registers
> +  */
> + port = ((te_trigger & DSI1_TE && val) || (te_trigger & DSI0_TE)) ?
> +   PORT_A : PORT_B;
> + dsi_trans = (port == PORT_A) ? TRANSCODER_DSI_0 : TRANSCODER_DSI_1;
> +
> + /* Check if DSI configured in command mode */
> + val = I915_READ(DSI_TRANS_FUNC_CONF(dsi_trans));
> + val = val & OP_MODE_MASK;
> +
> + if ((val != CMD_MODE_NO_GATE) && (val != CMD_MODE_TE_GATE)) {
> + DRM_ERROR("DSI trancoder not configured in command mode\n");

drm_err()

> + return;
> + }
> +
> + /* Get PIPE for handling VBLANK event */
> + val = I915_READ(TRANS_DDI_FUNC_CTL(dsi_trans));
> + switch (val & TRANS_DDI_EDP_INPUT_MASK) {
> + case TRANS_DDI_EDP_INPUT_A_ON:
> + pipe = PIPE_A;
> + break;
> + case TRANS_DDI_EDP_INPUT_B_ONOFF:
> + pipe = PIPE_B;
> + break;
> + case TRANS_DDI_EDP_INPUT_C_ONOFF:
> + pipe = PIPE_C;
> + break;
> + default:
> + DRM_ERROR("Invalid PIPE\n");

drm_err()... but don't want to pass INVALID_PIPE to
intel_handle_vblank() below.

> + }
> +
> + /* clear TE in dsi IIR */
> + port = (te_trigger & DSI1_TE) ? PORT_B : PORT_A;
> + tmp = I915_READ(DSI_INTR_IDENT_REG(port));
> + I915_WRITE(DSI_INTR_IDENT_REG(port), tmp);
> +
> + drm_handle_vblank(&dev_priv->drm, pipe);

Please use intel_handle_vblank(). It takes into account pipe might not
match crtc index.

> +}
> +
>  static irqreturn_t
>  gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
>  {
> @@ -2328,6 +2384,14 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   found = true;
>   }
>  
> + if (INTEL_GEN(dev_priv) >= 11) {
> + tmp_mask = iir & (DSI0_TE | DSI1_TE);
> + if (tmp_mask) {
> + 
> gen11_dsi_te_interrupt_handler(dev_priv, tmp_mask);
> + found = true;
> + }
> + }
> +
>   if (!found)
>   drm_err(&dev_priv->drm,
>   "Unexpected DE Port interrupt\n");

-- 
Jani Nikula, Intel Open Source Graphics 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 drm/i915/gt: Select the deepest available parking mode for rc6 (rev2)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Select the deepest available parking mode for rc6 (rev2)
URL   : https://patchwork.freedesktop.org/series/75009/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8182 -> Patchwork_17069


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/index.html

Known issues


  Here are the changes found in Patchwork_17069 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@execlists:
- fi-kbl-7500u:   [PASS][1] -> [INCOMPLETE][2] ([fdo#112259] / 
[i915#1430] / [i915#656])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-kbl-7500u/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/fi-kbl-7500u/igt@i915_selftest@l...@execlists.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- fi-cml-s:   [DMESG-FAIL][3] ([i915#877]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/fi-cml-s/igt@i915_selftest@live@gem_contexts.html

  
 Warnings 

  * igt@gem_linear_blits@basic:
- fi-glk-dsi: [SKIP][5] ([fdo#109271]) -> [INCOMPLETE][6] 
([i915#58] / [k.org#198133])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-glk-dsi/igt@gem_linear_bl...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/fi-glk-dsi/igt@gem_linear_bl...@basic.html

  * igt@i915_selftest@live@gem_contexts:
- fi-cfl-8700k:   [DMESG-FAIL][7] ([i915#481]) -> [DMESG-FAIL][8] 
([i915#730] / [i915#933])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
- fi-skl-lmem:[INCOMPLETE][9] ([i915#424]) -> [DMESG-FAIL][10] 
([i915#481])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17069/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#112259]: https://bugs.freedesktop.org/show_bug.cgi?id=112259
  [i915#1430]: https://gitlab.freedesktop.org/drm/intel/issues/1430
  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
  [i915#481]: https://gitlab.freedesktop.org/drm/intel/issues/481
  [i915#58]: https://gitlab.freedesktop.org/drm/intel/issues/58
  [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
  [i915#730]: https://gitlab.freedesktop.org/drm/intel/issues/730
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
  [i915#933]: https://gitlab.freedesktop.org/drm/intel/issues/933
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (51 -> 43)
--

  Missing(8): fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq 
fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8182 -> Patchwork_17069

  CI-20190529: 20190529
  CI_DRM_8182: e5245084567cd7f6f93b07baaebf8a2b4d914620 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5531: 79e7382202c104b247a672c61a6186d1f51e4958 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17069: 13af5126ab2c821dc4598239827f1508ea657df7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

13af5126ab2c drm/i915/gt: Select the deepest available parking mode for rc6

== Logs ==

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


Re: [Intel-gfx] [V8 5/9] drm/i915/dsi: Use private flags to indicate TE in cmd mode

2020-03-24 Thread Jani Nikula
On Thu, 12 Mar 2020, Vandita Kulkarni  wrote:
> On dsi cmd mode we do not receive vblanks instead
> we would get TE and these flags indicate TE is expected on
> which port.
>
> Signed-off-by: Vandita Kulkarni 
> Reviewed-by: Jani Nikula 

Pushed up to and including this patch.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 949f4867402b..d452037b1ac9 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1550,6 +1550,24 @@ static int gen11_dsi_compute_config(struct 
> intel_encoder *encoder,
>   pipe_config->hw.adjusted_mode.private_flags &=
>   ~I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE;
>  
> + /*
> +  * In case of TE GATE cmd mode, we
> +  * receive TE from the slave if
> +  * dual link is enabled
> +  */
> + if (is_cmd_mode(intel_dsi)) {
> + if (intel_dsi->ports == (BIT(PORT_B) | BIT(PORT_A)))
> + pipe_config->hw.adjusted_mode.private_flags |=
> + I915_MODE_FLAG_DSI_USE_TE1 |
> + I915_MODE_FLAG_DSI_USE_TE0;
> + else if (intel_dsi->ports == BIT(PORT_B))
> + pipe_config->hw.adjusted_mode.private_flags |=
> + I915_MODE_FLAG_DSI_USE_TE1;
> + else
> + pipe_config->hw.adjusted_mode.private_flags |=
> + I915_MODE_FLAG_DSI_USE_TE0;
> + }
> +
>   return 0;
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/gt: Select the deepest available parking mode for rc6

2020-03-24 Thread Andi Shyti
Hi again, Chris,

> > @@ -622,7 +623,14 @@ void intel_rc6_park(struct intel_rc6 *rc6)
> >  
> > /* Turn off the HW timers and go directly to rc6 */
> > set(uncore, GEN6_RC_CONTROL, GEN6_RC_CTL_RC6_ENABLE);
> > -   set(uncore, GEN6_RC_STATE, 0x4 << RC_SW_TARGET_STATE_SHIFT);
> > +
> > +   if (HAS_RC6pp(rc6_to_i915(rc6)))
> > +   target = 0x6; /* deepest rc6 */
> > +   else if (HAS_RC6p(rc6_to_i915(rc6)))
> > +   target = 0x5; /* deep rc6 */
> > +   else
> > +   target = 0x4; /* normal rc6 */
> 
> can we put names to these values?

actually, you are using these only here and there is a comment to
them... givinb those values a meaningful define is a bit of a
formality, I'd say. It's up to you.

Reviewed-by: Andi Shyti 

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


[Intel-gfx] ✗ Fi.CI.BUILD: failure for i915 lpsp support for lpsp igt (rev4)

2020-03-24 Thread Patchwork
== Series Details ==

Series: i915 lpsp support for lpsp igt (rev4)
URL   : https://patchwork.freedesktop.org/series/74648/
State : failure

== Summary ==

Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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


Re: [Intel-gfx] [PATCH] drm/i915/gt: Select the deepest available parking mode for rc6

2020-03-24 Thread Andi Shyti
Hi Chris,

>   struct intel_uncore *uncore = rc6_to_uncore(rc6);
> + unsigned int target;
>  
>   if (!rc6->enabled)
>   return;
> @@ -622,7 +623,14 @@ void intel_rc6_park(struct intel_rc6 *rc6)
>  
>   /* Turn off the HW timers and go directly to rc6 */
>   set(uncore, GEN6_RC_CONTROL, GEN6_RC_CTL_RC6_ENABLE);
> - set(uncore, GEN6_RC_STATE, 0x4 << RC_SW_TARGET_STATE_SHIFT);
> +
> + if (HAS_RC6pp(rc6_to_i915(rc6)))
> + target = 0x6; /* deepest rc6 */
> + else if (HAS_RC6p(rc6_to_i915(rc6)))
> + target = 0x5; /* deep rc6 */
> + else
> + target = 0x4; /* normal rc6 */

can we put names to these values?

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


Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Introduce scaling filter related registers and bit fields.

2020-03-24 Thread Laxminarayan Bharadiya, Pankaj



> -Original Message-
> From: Ville Syrjälä 
> Sent: 23 March 2020 20:09
> To: Laxminarayan Bharadiya, Pankaj
> 
> Cc: Lattannavar, Sameer ;
> jani.nik...@linux.intel.com; dan...@ffwll.ch; intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; dani...@collabora.com; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie 
> Subject: Re: [PATCH v2 3/5] drm/i915: Introduce scaling filter related 
> registers
> and bit fields.
> 
> On Thu, Mar 19, 2020 at 03:51:01PM +0530, Pankaj Bharadiya wrote:
> > Introduce scaler registers and bit fields needed to configure the
> > scaling filter in prgrammed mode and configure scaling filter
> > coefficients.
> >
> > changes since v1:
> > * None
> > changes since RFC:
> > * Parametrize scaler coeffient macros by 'set' (Ville)
> >
> > Signed-off-by: Shashank Sharma 
> > Signed-off-by: Ankit Nautiyal 
> > Signed-off-by: Pankaj Bharadiya
> > 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 48
> > +
> >  1 file changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 9c53fe918be6..d40f12d2a6b5
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7205,6 +7205,7 @@ enum {
> >  #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
> >  #define PS_FILTER_MASK (3 << 23)
> >  #define PS_FILTER_MEDIUM   (0 << 23)
> > +#define PS_FILTER_PROGRAMMED   (1 << 23)
> >  #define PS_FILTER_EDGE_ENHANCE (2 << 23)
> >  #define PS_FILTER_BILINEAR (3 << 23)
> >  #define PS_VERT3TAP(1 << 21)
> > @@ -7219,6 +7220,10 @@ enum {
> >  #define PS_VADAPT_MODE_MOST_ADAPT  (3 << 5)  #define
> > PS_PLANE_Y_SEL_MASK  (7 << 5)  #define PS_PLANE_Y_SEL(plane) (((plane)
> > + 1) << 5)
> > +#define PS_Y_VERT_FILTER_SELECT(set)   ((set) << 4)
> > +#define PS_Y_HORZ_FILTER_SELECT(set)   ((set) << 3)
> > +#define PS_UV_VERT_FILTER_SELECT(set)  ((set) << 2) #define
> > +PS_UV_HORZ_FILTER_SELECT(set)  ((set) << 1)
> >
> >  #define _PS_PWR_GATE_1A 0x68160
> >  #define _PS_PWR_GATE_2A 0x68260
> > @@ -7281,6 +7286,25 @@ enum {
> >  #define _PS_ECC_STAT_2B 0x68AD0
> >  #define _PS_ECC_STAT_1C 0x691D0
> >
> > +#define _PS_COEF_SET0_INDEX_1A0x68198
> > +#define _PS_COEF_SET0_INDEX_2A0x68298
> > +#define _PS_COEF_SET0_INDEX_1B0x68998
> > +#define _PS_COEF_SET0_INDEX_2B0x68A98
> > +#define _PS_COEF_SET1_INDEX_1A0x681A0
> > +#define _PS_COEF_SET1_INDEX_2A0x682A0
> > +#define _PS_COEF_SET1_INDEX_1B0x689A0
> > +#define _PS_COEF_SET1_INDEX_2B0x68AA0
> > +#define PS_COEE_INDEX_AUTO_INC(1 << 10)
> > +
> > +#define _PS_COEF_SET0_DATA_1A 0x6819C
> > +#define _PS_COEF_SET0_DATA_2A 0x6829C
> > +#define _PS_COEF_SET0_DATA_1B 0x6899C
> > +#define _PS_COEF_SET0_DATA_2B 0x68A9C
> > +#define _PS_COEF_SET1_DATA_1A 0x681A4
> > +#define _PS_COEF_SET1_DATA_2A 0x682A4
> > +#define _PS_COEF_SET1_DATA_1B 0x689A4
> > +#define _PS_COEF_SET1_DATA_2B 0x68AA4
> > +
> >  #define _ID(id, a, b) _PICK_EVEN(id, a, b)
> >  #define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
> > _ID(id, _PS_1A_CTRL, _PS_2A_CTRL),   \
> > @@ -7310,6 +7334,30 @@ enum {
> > _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
> > _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> >
> > +#define _SKL_PS_COEF_INDEX_SET0(pipe, id)  _ID(pipe,\
> > +   _ID(id, _PS_COEF_SET0_INDEX_1A,
> _PS_COEF_SET0_INDEX_2A), \
> > +   _ID(id, _PS_COEF_SET0_INDEX_1B,
> _PS_COEF_SET0_INDEX_2B))
> > +
> > +#define _SKL_PS_COEF_INDEX_SET1(pipe, id)  _ID(pipe,\
> > +   _ID(id, _PS_COEF_SET1_INDEX_1A,
> _PS_COEF_SET1_INDEX_2A), \
> > +   _ID(id, _PS_COEF_SET1_INDEX_1B,
> _PS_COEF_SET1_INDEX_2B))
> > +
> > +#define _SKL_PS_COEF_DATA_SET0(pipe, id)  _ID(pipe, \
> > +   _ID(id, _PS_COEF_SET0_DATA_1A,
> _PS_COEF_SET0_DATA_2A), \
> > +   _ID(id, _PS_COEF_SET0_DATA_1B,
> _PS_COEF_SET0_DATA_2B))
> > +
> > +#define _SKL_PS_COEF_DATA_SET1(pipe, id)  _ID(pipe, \
> > +   _ID(id, _PS_COEF_SET1_DATA_1A,
> _PS_COEF_SET1_DATA_2A), \
> > +   _ID(id, _PS_COEF_SET1_DATA_1B,
> _PS_COEF_SET1_DATA_2B))
> > +
> > +#define SKL_PS_COEF_INDEX_SET(pipe, id, set) \
> > +   _MMIO_PIPE(set, _SKL_PS_COEF_INDEX_SET0(pipe, id),
> \
> > +   _SKL_PS_COEF_INDEX_SET1(pipe, id))
> > +
> > +#define SKL_PS_COEF_DATA_SET(pipe, id, set) \
> > +   _MMIO_PIPE(set, _SKL_PS_COEF_DATA_SET0(pipe, id),
> \
> > +   _SKL_PS_COEF_DATA_SET1(pipe, id))
> 
> I'd name those CNL_PS_COEF_{DATA,INDEX}(). Or maybe eeven GLK_ since it
> already has this despite not being officially supported.

All other existing scaler macros start will  SKL_PS_*,  adding new 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm_device managed resources (rev6)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm_device managed resources (rev6)
URL   : https://patchwork.freedesktop.org/series/73633/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8182 -> Patchwork_17067


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17067 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17067, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_17067:

### IGT changes ###

 Possible regressions 

  * igt@core_auth@basic-auth:
- fi-kbl-8809g:   [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-kbl-8809g/igt@core_a...@basic-auth.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-kbl-8809g/igt@core_a...@basic-auth.html

  * igt@kms_addfb_basic@addfb25-bad-modifier:
- fi-icl-y:   [PASS][3] -> [SKIP][4] +82 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-icl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-icl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html

  * igt@kms_addfb_basic@bad-pitch-128:
- fi-cml-u2:  [PASS][5] -> [SKIP][6] +86 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-cml-u2/igt@kms_addfb_ba...@bad-pitch-128.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-cml-u2/igt@kms_addfb_ba...@bad-pitch-128.html

  * igt@kms_addfb_basic@clobberred-modifier:
- fi-icl-guc: [PASS][7] -> [SKIP][8] +82 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-icl-guc/igt@kms_addfb_ba...@clobberred-modifier.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-icl-guc/igt@kms_addfb_ba...@clobberred-modifier.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][9] +91 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-cml-s:   [PASS][10] -> [SKIP][11] +82 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-cml-s/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-cml-s/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html

  * igt@prime_vgem@basic-wait-default:
- fi-icl-dsi: [PASS][12] -> [SKIP][13] +82 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-icl-dsi/igt@prime_v...@basic-wait-default.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-icl-dsi/igt@prime_v...@basic-wait-default.html

  
 Warnings 

  * igt@kms_chamelium@dp-crc-fast:
- fi-icl-dsi: [SKIP][14] ([fdo#109284] / [fdo#111827]) -> 
[SKIP][15] +8 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-icl-dsi/igt@kms_chamel...@dp-crc-fast.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-icl-dsi/igt@kms_chamel...@dp-crc-fast.html
- fi-icl-y:   [SKIP][16] ([fdo#109284] / [fdo#111827]) -> 
[SKIP][17] +8 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-icl-y/igt@kms_chamel...@dp-crc-fast.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-icl-y/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@dp-edid-read:
- fi-icl-guc: [SKIP][18] ([fdo#109284] / [fdo#111827]) -> 
[SKIP][19] +8 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-icl-guc/igt@kms_chamel...@dp-edid-read.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-icl-guc/igt@kms_chamel...@dp-edid-read.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-cml-s:   [SKIP][20] ([fdo#109284] / [fdo#111827]) -> 
[SKIP][21] +8 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-cml-s/igt@kms_chamel...@dp-hpd-fast.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-cml-s/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-cml-u2:  [SKIP][22] ([i915#1004]) -> [SKIP][23] +2 similar 
issues
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/fi-cml-u2/igt@kms_chamel...@hdmi-hpd-fast.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17067/fi-cml-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_chamelium@vga-edid-read:
- fi-cml-u2:  [SKIP][

Re: [Intel-gfx] [PATCH v2 1/5] drm: Introduce plane and CRTC scaling filter properties

2020-03-24 Thread Laxminarayan Bharadiya, Pankaj


> -Original Message-
> From: Ville Syrjälä 
> Sent: 23 March 2020 19:52
> To: Laxminarayan Bharadiya, Pankaj
> 
> Cc: Lattannavar, Sameer ;
> jani.nik...@linux.intel.com; dan...@ffwll.ch; intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; dani...@collabora.com; Maarten Lankhorst
> ; Maxime Ripard ;
> Thomas Zimmermann ; David Airlie 
> Subject: Re: [PATCH v2 1/5] drm: Introduce plane and CRTC scaling filter
> properties
> 
> On Thu, Mar 19, 2020 at 03:50:59PM +0530, Pankaj Bharadiya wrote:
> > Introduce new plane and CRTC scaling filter properties to allow
> > userspace to select the driver's default scaling filter or
> > Nearest-neighbor(NN) filter for upscaling operations on CRTC and
> > plane.
> >
> > Drivers can set up this property for a plane by calling
> > drm_plane_enable_scaling_filter() and for a CRTC by calling
> > drm_crtc_enable_scaling_filter().
> >
> > NN filter works by filling in the missing color values in the upscaled
> > image with that of the coordinate-mapped nearest source pixel value.
> >
> > NN filter for integer multiple scaling can be particularly useful for
> > for pixel art games that rely on sharp, blocky images to deliver their
> > distinctive look.
> >
> > changes since v1:
> > * None
> > changes since RFC:
> > * Add separate properties for plane and CRTC (Ville)
> 
> I actually meant the prop should be per-object, not just separate prop for 
> planes
> and crtcs.

My bad, I misunderstood it ☹.
Will add drm_property in drm_crtc and drm_plane.

Thanks,
Pankaj

> 
> >
> > Signed-off-by: Shashank Sharma 
> > Signed-off-by: Ankit Nautiyal 
> > Signed-off-by: Pankaj Bharadiya
> > 
> > ---
> >  drivers/gpu/drm/drm_atomic_uapi.c |  8 
> >  drivers/gpu/drm/drm_crtc.c| 33 +++
> >  drivers/gpu/drm/drm_mode_config.c | 26 
> >  drivers/gpu/drm/drm_plane.c   | 33 +++
> >  include/drm/drm_crtc.h| 13 
> >  include/drm/drm_mode_config.h | 12 +++
> >  include/drm/drm_plane.h   | 13 
> >  7 files changed, 138 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index a1e5e262bae2..3c72ab52ff62 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct
> drm_crtc *crtc,
> > return ret;
> > } else if (property == config->prop_vrr_enabled) {
> > state->vrr_enabled = val;
> > +   } else if (property == config->crtc_scaling_filter_property) {
> > +   state->scaling_filter = val;
> > } else if (property == config->degamma_lut_property) {
> > ret = drm_atomic_replace_property_blob_from_id(dev,
> > &state->degamma_lut,
> > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > else if (property == config->prop_out_fence_ptr)
> > *val = 0;
> > +   else if (property == config->crtc_scaling_filter_property)
> > +   *val = state->scaling_filter;
> > else if (crtc->funcs->atomic_get_property)
> > return crtc->funcs->atomic_get_property(crtc, state, property,
> val);
> > else
> > @@ -583,6 +587,8 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> > sizeof(struct drm_rect),
> > &replaced);
> > return ret;
> > +   } else if (property == config->plane_scaling_filter_property) {
> > +   state->scaling_filter = val;
> > } else if (plane->funcs->atomic_set_property) {
> > return plane->funcs->atomic_set_property(plane, state,
> > property, val);
> > @@ -641,6 +647,8 @@ drm_atomic_plane_get_property(struct drm_plane
> *plane,
> > } else if (property == config->prop_fb_damage_clips) {
> > *val = (state->fb_damage_clips) ?
> > state->fb_damage_clips->base.id : 0;
> > +   } else if (property == config->plane_scaling_filter_property) {
> > +   *val = state->scaling_filter;
> > } else if (plane->funcs->atomic_get_property) {
> > return plane->funcs->atomic_get_property(plane, state,
> property, val);
> > } else {
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 4936e1080e41..c8d387891dd5 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -748,3 +748,36 @@ int drm_mode_crtc_set_obj_prop(struct
> > drm_mode_object *obj,
> >
> > return ret;
> >  }
> > +
> > +/**
> > + * DOC: CRTC scaling filter property
> > + *
> > + * SCALING_FILTER:
> > + *
> > + * Indicates scaling filter to be used for CRTC scaler
> > + *
> > + * The value of this property can be one of the f

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm_device managed resources (rev6)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm_device managed resources (rev6)
URL   : https://patchwork.freedesktop.org/series/73633/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: mm/sl[uo]b: export __kmalloc_track(_node)_caller
Okay!

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


[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission

2020-03-24 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/execlists: Pull tasklet 
interrupt-bh local to direct submission
URL   : https://patchwork.freedesktop.org/series/75008/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8182_full -> Patchwork_17065_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_17065_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +10 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-iclb2/igt@gem_b...@busy-vcs1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-iclb7/igt@gem_b...@busy-vcs1.html

  * igt@gem_ctx_persistence@engines-mixed-process@bcs0:
- shard-skl:  [PASS][3] -> [FAIL][4] ([i915#679])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-skl2/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-skl1/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html

  * igt@gem_ctx_persistence@engines-mixed-process@vcs0:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([i915#1239])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-skl2/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-skl1/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110841])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-iclb6/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html

  * igt@gem_exec_schedule@implicit-write-read-bsd:
- shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-iclb5/igt@gem_exec_sched...@implicit-write-read-bsd.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-iclb4/igt@gem_exec_sched...@implicit-write-read-bsd.html

  * igt@gem_exec_schedule@promotion-bsd1:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +15 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-iclb2/igt@gem_exec_sched...@promotion-bsd1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-iclb7/igt@gem_exec_sched...@promotion-bsd1.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +3 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-iclb6/igt@gem_exec_sched...@reorder-wide-bsd.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html

  * igt@i915_selftest@live@requests:
- shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([fdo#109644] / 
[fdo#110464])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-iclb4/igt@i915_selftest@l...@requests.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-iclb8/igt@i915_selftest@l...@requests.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl:  [PASS][17] -> [DMESG-WARN][18] ([i915#165] / 
[i915#180])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk:  [PASS][19] -> [FAIL][20] ([IGT#5])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-glk3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-glk2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl:  [PASS][21] -> [FAIL][22] ([i915#79])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-skl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-skl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
- shard-hsw:  [PASS][23] -> [INCOMPLETE][24] ([i915#61])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8182/shard-hsw8/igt@kms_f...@flip-vs-suspend.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17065/shard-hsw5/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_hdr@bpc-switch-dpms:
- shard-skl: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm_device managed resources (rev6)

2020-03-24 Thread Patchwork
== Series Details ==

Series: drm_device managed resources (rev6)
URL   : https://patchwork.freedesktop.org/series/73633/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ac41bc6ebdf2 mm/sl[uo]b: export __kmalloc_track(_node)_caller
-:58: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 28 lines checked
7065ea199d00 drm/i915: Don't clear drvdata in ->release
-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 0998d0631001 ("device-core: 
Ensure drvdata = NULL when no driver is bound")'
#20: 
commit 0998d0631001288a5974afc0b2a5f568bcdecb4d

-:45: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 1 errors, 1 warnings, 0 checks, 9 lines checked
957fcd9d1be3 drm: add managed resources tied to drm_device
-:72: WARNING:TYPO_SPELLING: 'unecessary' may be misspelled - perhaps 
'unnecessary'?
#72: 
v8: Remove unecessary {} around if else

-:74: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#74: 
v9: Use kstrdup_const, which requires kfree_const and introducing a free_dr()

-:85: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Neil Armstrong 
driver->release && !dev->managed.final_kfree) {
[...]
-   }
[...]

-:153: WARNING:NEEDLESS_IF: kfree(NULL) is safe and this check is probably not 
required
#153: FILE: drivers/gpu/drm/drm_drv.c:841:
+   } else if (dev->managed.final_kfree)
+   kfree(dev->managed.final_kfree);

-:172: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#172: 
new file mode 100644

-:247: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#247: FILE: drivers/gpu/drm/drm_managed.c:71:
+static __always_inline struct drmres * alloc_dr(drmres_release_t release,

-:275: CHECK:SPACING: No space is necessary after a cast
#275: FILE: drivers/gpu/drm/drm_managed.c:99:
+  dr, dr->node.name, (unsigned long) dr->node.size);

-:287: CHECK:SPACING: No space is necessary after a cast
#287: FILE: drivers/gpu/drm/drm_managed.c:111:
+  dr, dr->node.name, (unsigned long) dr->node.size);

-:293: CHECK:SPACING: No space is necessary after a cast
#293: FILE: drivers/gpu/drm/drm_managed.c:117:
+   WARN_ON(dev < (struct drm_device *) container);

-:295: CHECK:SPACING: No space is necessary after a cast
#295: FILE: drivers/gpu/drm/drm_managed.c:119:
+   (struct drm_device *) (container + ksize(container)));

-:307: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
#307: FILE: drivers/gpu/drm/drm_managed.c:131:
+   dr = alloc_dr(action, data ? sizeof(void*) : 0,

-:402: WARNING:SPDX_LICENSE_TAG: Improper SPDX comment style for 
'include/drm/drm_managed.h', please use '/*' instead
#402: FILE: include/drm/drm_managed.h:1:
+// SPDX-License-Identifier: GPL-2.0

-:402: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#402: FILE: include/drm/drm_managed.h:1:
+// SPDX-License-Identifier: GPL-2.0

-:455: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 3 errors, 7 warnings, 5 checks, 322 lines checked
63e381527084 drm: Set final_kfree in drm_dev_alloc
-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 0a6659bdc5e8 ("drm/bochs: new 
driver")'
#15: 
commit 0a6659bdc5e8221da99eebb176fd9591435e38de

-:25: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit b1df3a2b24a9 ("drm/virtio: add 
drm_driver.release callback.")'
#25: 
commit b1df3a2b24a917f8853d43fe9683c0e360d2c33a

-:44: WARNING:BAD_SIGN_OFF: Duplicate signature
#44: 
Cc: Oleksandr Andrushchenko 

-:45: WARNING:BAD_SIGN_OFF: Duplicate signature
#45: 
Cc: xen-de...@lists.xenproject.org

-:87: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 2 errors, 3 warnings, 0 checks, 29 lines checked
f16c91668297 drm/mipi_dbi: Use drmm_add_final_kfree in all drivers
-:189: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 111 lines checked
0697ed6f202b drm/udl: Use drmm_add_final_kfree
-:63: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 27 lines checked
c090dddc6b8c drm/qxl: Use drmm_add_final_kfree
-:47: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 22 lines checked
eed2f41d15a5 drm/i915: Use drmm_add_final_kfree
-:207: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch 
author 'Daniel Vetter '

total: 0 errors, 1 warnings,

[Intel-gfx] [PATCH] drm/i915/gt: Select the deepest available parking mode for rc6

2020-03-24 Thread Chris Wilson
On Ivybridge, we can go lower than rc6 to rc6p. And this is required for
Ivybridge to hit the same minimum power consumption as rc6 on other
platforms, so make it so.

v2: Update selftest to include all rc6 residency counters

Fixes: 730eaeb52426 ("drm/i915/gt: Manual rc6 entry upon parking")
Testcase: igt/i915_pm_rc6_residency/rc6-idle
Signed-off-by: Chris Wilson 
Cc: Andi Shyti 
Cc: Mika Kuoppala 
Cc: Imre Deak 
---
 drivers/gpu/drm/i915/gt/intel_rc6.c| 10 +-
 drivers/gpu/drm/i915/gt/selftest_rc6.c | 21 +
 2 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c 
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 50aa63270cdc..09d3e5a45397 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -608,6 +608,7 @@ void intel_rc6_unpark(struct intel_rc6 *rc6)
 void intel_rc6_park(struct intel_rc6 *rc6)
 {
struct intel_uncore *uncore = rc6_to_uncore(rc6);
+   unsigned int target;
 
if (!rc6->enabled)
return;
@@ -622,7 +623,14 @@ void intel_rc6_park(struct intel_rc6 *rc6)
 
/* Turn off the HW timers and go directly to rc6 */
set(uncore, GEN6_RC_CONTROL, GEN6_RC_CTL_RC6_ENABLE);
-   set(uncore, GEN6_RC_STATE, 0x4 << RC_SW_TARGET_STATE_SHIFT);
+
+   if (HAS_RC6pp(rc6_to_i915(rc6)))
+   target = 0x6; /* deepest rc6 */
+   else if (HAS_RC6p(rc6_to_i915(rc6)))
+   target = 0x5; /* deep rc6 */
+   else
+   target = 0x4; /* normal rc6 */
+   set(uncore, GEN6_RC_STATE, target << RC_SW_TARGET_STATE_SHIFT);
 }
 
 void intel_rc6_disable(struct intel_rc6 *rc6)
diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c 
b/drivers/gpu/drm/i915/gt/selftest_rc6.c
index 5f7e2dcf5686..10720722a2ca 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rc6.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
@@ -12,6 +12,19 @@
 
 #include "selftests/i915_random.h"
 
+static u64 rc6_residency(struct intel_rc6 *rc6)
+{
+   u64 result;
+
+   result = intel_rc6_residency_ns(rc6, GEN6_GT_GFX_RC6);
+   if (HAS_RC6p(rc6_to_i915(rc6)))
+   result += intel_rc6_residency_ns(rc6, GEN6_GT_GFX_RC6p);
+   if (HAS_RC6pp(rc6_to_i915(rc6)))
+   result += intel_rc6_residency_ns(rc6, GEN6_GT_GFX_RC6pp);
+
+   return result;
+}
+
 int live_rc6_manual(void *arg)
 {
struct intel_gt *gt = arg;
@@ -38,9 +51,9 @@ int live_rc6_manual(void *arg)
__intel_rc6_disable(rc6);
msleep(1); /* wakeup is not immediate, takes about 100us on icl */
 
-   res[0] = intel_rc6_residency_ns(rc6, GEN6_GT_GFX_RC6);
+   res[0] = rc6_residency(rc6);
msleep(250);
-   res[1] = intel_rc6_residency_ns(rc6, GEN6_GT_GFX_RC6);
+   res[1] = rc6_residency(rc6);
if ((res[1] - res[0]) >> 10) {
pr_err("RC6 residency increased by %lldus while disabled for 
250ms!\n",
   (res[1] - res[0]) >> 10);
@@ -51,9 +64,9 @@ int live_rc6_manual(void *arg)
/* Manually enter RC6 */
intel_rc6_park(rc6);
 
-   res[0] = intel_rc6_residency_ns(rc6, GEN6_GT_GFX_RC6);
+   res[0] = rc6_residency(rc6);
msleep(100);
-   res[1] = intel_rc6_residency_ns(rc6, GEN6_GT_GFX_RC6);
+   res[1] = rc6_residency(rc6);
 
if (res[1] == res[0]) {
pr_err("Did not enter RC6! RC6_STATE=%08x, RC6_CONTROL=%08x, 
residency=%lld\n",
-- 
2.20.1

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


[Intel-gfx] [PATCH v2 2/3] drm/i915: Add i915_lpsp_info debugfs

2020-03-24 Thread Anshuman Gupta
New i915_pm_lpsp igt solution approach relies on connector specific
debugfs attribute i915_lpsp_info, it exposes whether an output is
capable of driving lpsp and exposes lpsp enablement info.

v2:
- CI fixup.

Signed-off-by: Anshuman Gupta 
---
 .../drm/i915/display/intel_display_debugfs.c  | 104 ++
 1 file changed, 104 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 424f4e52f783..eb9d88341d48 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -9,6 +9,7 @@
 #include "i915_debugfs.h"
 #include "intel_csr.h"
 #include "intel_display_debugfs.h"
+#include "intel_display_power.h"
 #include "intel_display_types.h"
 #include "intel_dp.h"
 #include "intel_fbc.h"
@@ -611,6 +612,95 @@ static void intel_hdcp_info(struct seq_file *m,
seq_puts(m, "\n");
 }
 
+static bool intel_have_embedded_panel(struct drm_connector *connector)
+{
+   return connector->connector_type == DRM_MODE_CONNECTOR_DSI ||
+   connector->connector_type == DRM_MODE_CONNECTOR_eDP;
+}
+
+static bool intel_have_gen9_lpsp_panel(struct drm_connector *connector)
+{
+   return intel_have_embedded_panel(connector) ||
+   connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort;
+}
+
+static int
+intel_lpsp_power_well_enabled(struct drm_i915_private *dev_priv,
+ enum i915_power_well_id power_well_id)
+{
+   struct i915_power_domains *power_domains = &dev_priv->power_domains;
+   struct i915_power_well *power_well = NULL, *pw_itr;
+   bool is_enabled;
+
+   mutex_lock(&power_domains->lock);
+
+   for_each_power_well(dev_priv, pw_itr)
+   if (pw_itr->desc->id == power_well_id) {
+   power_well = pw_itr;
+   break;
+   }
+
+   if (drm_WARN_ON(&dev_priv->drm, !power_well)) {
+   mutex_unlock(&power_domains->lock);
+   /* Assume that BIOS has enabled the power well*/
+   return true;
+   }
+
+   is_enabled = !!power_well->count;
+   mutex_unlock(&power_domains->lock);
+
+   return is_enabled;
+}
+
+static void
+intel_lpsp_capable_info(struct seq_file *m, struct drm_connector *connector)
+{
+   struct intel_encoder *encoder =
+   intel_attached_encoder(to_intel_connector(connector));
+   struct drm_i915_private *dev_priv = to_i915(connector->dev);
+   bool lpsp_capable = false;
+
+   if (IS_TIGERLAKE(dev_priv) && encoder->port <= PORT_C) {
+   lpsp_capable = true;
+   } else if (INTEL_GEN(dev_priv) >= 11 && 
intel_have_embedded_panel(connector)) {
+   lpsp_capable = true;
+   } else if (INTEL_GEN(dev_priv) >= 9 && (encoder->port == PORT_A &&
+  intel_have_gen9_lpsp_panel(connector))) {
+   lpsp_capable = true;
+   } else if ((IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) &&
+  connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+   lpsp_capable = true;
+   } else {
+   seq_puts(m, "LPSP not supported\n");
+   return;
+   }
+
+   lpsp_capable ? seq_puts(m, "LPSP capable\n") : seq_puts(m, "LPSP 
incapable\n");
+}
+
+static void
+intel_lpsp_enable_info(struct seq_file *m, struct drm_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->dev);
+   bool is_lpsp = false;
+
+   if (INTEL_GEN(dev_priv) >= 11) {
+   is_lpsp = !intel_lpsp_power_well_enabled(dev_priv,
+ICL_DISP_PW_3);
+   } else if (INTEL_GEN(dev_priv) >= 9) {
+   is_lpsp = !intel_lpsp_power_well_enabled(dev_priv,
+SKL_DISP_PW_2);
+   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
+   is_lpsp = !intel_lpsp_power_well_enabled(dev_priv,
+HSW_DISP_PW_GLOBAL);
+   } else {
+   seq_puts(m, "LPSP not supported\n");
+   return;
+   }
+
+   is_lpsp ? seq_puts(m, "LPSP enabled\n") : seq_puts(m, "LPSP 
disabled\n");
+}
+
 static void intel_dp_info(struct seq_file *m,
  struct intel_connector *intel_connector)
 {
@@ -1987,6 +2077,17 @@ static int i915_hdcp_sink_capability_show(struct 
seq_file *m, void *data)
 }
 DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
 
+static int i915_lpsp_info_show(struct seq_file *m, void *data)
+{
+   struct drm_connector *connector = m->private;
+
+   intel_lpsp_capable_info(m, connector);
+   intel_lpsp_enable_info(m, connector);
+
+   return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(i915_lpsp_info);
+
 static int i915_dsc_fec_support_show(struct seq_file *m, void *data)
 {
struct drm_connecto

  1   2   >