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

[Patchwork]

== Series Details ==

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

== Summary ==

= CI Bug Log - changes from CI_DRM_4244_full -> Patchwork_9126_full =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/40747/revisions/4/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368) +1

igt@kms_flip_tiling@flip-to-x-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724)

igt@kms_setmode@basic:
  shard-apl:  PASS -> FAIL (fdo#99912)
  shard-kbl:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@drv_selftest@live_hangcheck:
  shard-apl:  DMESG-FAIL (fdo#106560) -> PASS
  shard-glk:  DMESG-FAIL (fdo#106560) -> PASS

igt@kms_cursor_legacy@cursor-vs-flip-toggle:
  shard-hsw:  FAIL (fdo#103355) -> PASS

igt@kms_flip@2x-dpms-vs-vblank-race-interruptible:
  shard-hsw:  DMESG-FAIL (fdo#103060) -> PASS

igt@kms_flip@2x-modeset-vs-vblank-race:
  shard-glk:  FAIL (fdo#103060) -> PASS

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_flip@dpms-vs-vblank-race:
  shard-hsw:  FAIL (fdo#103060) -> PASS

igt@kms_flip_tiling@flip-x-tiled:
  shard-glk:  FAIL (fdo#104724, fdo#103822) -> PASS

igt@kms_vblank@pipe-a-ts-continuation-modeset:
  shard-apl:  DMESG-WARN (fdo#106247) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#106247 https://bugs.freedesktop.org/show_bug.cgi?id=106247
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4244 -> Patchwork_9126

  CI_DRM_4244: 475c2ec7b8c6e01cce9a360b9839dc0dd0fa9629 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9126: e56337e6a35dc880c13010e17245256799793498 @ 
git://anongit.freedesktop.org/gfx-ci/linux

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pmu: Measure sampler intervals

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Measure sampler intervals
URL   : https://patchwork.freedesktop.org/series/43795/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4243_full -> Patchwork_9124_full =

== Summary - WARNING ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43795/revisions/1/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@pm_rc6_residency@rc6-accuracy:
  shard-snb:  SKIP -> PASS


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_gtt:
  shard-glk:  PASS -> INCOMPLETE (fdo#103359, k.org#198133)

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-glk:  PASS -> FAIL (fdo#105703) +1

igt@kms_flip@2x-plain-flip-ts-check-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368) +1


 Possible fixes 

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  FAIL (fdo#102887, fdo#105363) -> PASS

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_flip_tiling@flip-to-x-tiled:
  shard-glk:  FAIL (fdo#104724) -> PASS

igt@kms_flip_tiling@flip-y-tiled:
  shard-glk:  FAIL (fdo#103822, fdo#104724) -> PASS

igt@kms_setmode@basic:
  shard-apl:  FAIL (fdo#99912) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 4) ==

  Missing(1): shard-kbl 


== Build changes ==

* Linux: CI_DRM_4243 -> Patchwork_9124

  CI_DRM_4243: 7af0b742eec473a202f327e5148757f988b65305 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9124: 1620ac1abdcf8e4c1102eb46b9719b4484db140a @ 
git://anongit.freedesktop.org/gfx-ci/linux

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: fix icl_unmap/map_plls_to_ports (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/icl: fix icl_unmap/map_plls_to_ports (rev2)
URL   : https://patchwork.freedesktop.org/series/43510/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4242_full -> Patchwork_9123_full =

== Summary - WARNING ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43510/revisions/2/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-blt:
  shard-kbl:  PASS -> SKIP

igt@gem_exec_schedule@deep-bsd1:
  shard-kbl:  SKIP -> PASS


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_gtt:
  shard-glk:  PASS -> INCOMPLETE (fdo#103359, k.org#198133)

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
  shard-glk:  PASS -> FAIL (fdo#105703)

igt@kms_atomic_transition@plane-all-modeset-transition:
  shard-hsw:  PASS -> DMESG-WARN (fdo#102614)

igt@kms_flip@2x-modeset-vs-vblank-race:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_flip@plain-flip-fb-recreate-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368) +2

igt@kms_flip_tiling@flip-to-x-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724)

igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt:
  shard-glk:  PASS -> FAIL (fdo#104724, fdo#103167)


 Possible fixes 

igt@kms_cursor_crc@cursor-256x256-suspend:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@kms_flip@2x-plain-flip-ts-check:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_flip_tiling@flip-to-y-tiled:
  shard-glk:  FAIL (fdo#104724) -> PASS

igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt:
  shard-glk:  FAIL (fdo#104724, fdo#103167) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4242 -> Patchwork_9123

  CI_DRM_4242: 0364c498cd9a9e584a7080ee8526e9d17a7d4c67 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9123: 5ea233f0d8ba58cee34c41e139aec7839a6f02e3 @ 
git://anongit.freedesktop.org/gfx-ci/linux

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove stale asserts from i915_gem_find_active_request()

[Patchwork]

== Series Details ==

Series: drm/i915: Remove stale asserts from i915_gem_find_active_request()
URL   : https://patchwork.freedesktop.org/series/43781/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4242_full -> Patchwork_9122_full =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43781/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
  shard-hsw:  PASS -> FAIL (fdo#104873)

igt@kms_flip@2x-plain-flip-fb-recreate:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip_tiling@flip-to-x-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724, fdo#103822)


 Possible fixes 

igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
  shard-glk:  FAIL (fdo#105454, fdo#106509) -> PASS

igt@kms_flip@2x-plain-flip-ts-check:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_flip@plain-flip-fb-recreate:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt:
  shard-glk:  FAIL (fdo#104724, fdo#103167) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
  fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454
  fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4242 -> Patchwork_9122

  CI_DRM_4242: 0364c498cd9a9e584a7080ee8526e9d17a7d4c67 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9122: ce83453c8437968122d49ba7529e8c4860659cee @ 
git://anongit.freedesktop.org/gfx-ci/linux

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Switch to kernel context before idling at runtime

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Switch to kernel context before 
idling at runtime
URL   : https://patchwork.freedesktop.org/series/43808/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4246 -> Patchwork_9132 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43808/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-4200u:   PASS -> DMESG-FAIL (fdo#102614, fdo#106103)
  fi-hsw-peppy:   PASS -> DMESG-FAIL (fdo#102614, fdo#106103)


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


== Participating hosts (44 -> 39) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4246 -> Patchwork_9132

  CI_DRM_4246: 5195e857106a3836274e612b26d9d7c6289d8874 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9132: daac4efc24158d3679c830246c72e971c7d44320 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

daac4efc2415 drm/i915: "Race-to-idle" after switching to the kernel context
89d78161ae1c drm/i915: Switch to kernel context before idling at runtime

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9132/issues.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 Workarounds for Icelake (rev4)

[Patchwork]

== Series Details ==

Series: Workarounds for Icelake (rev4)
URL   : https://patchwork.freedesktop.org/series/42055/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4246 -> Patchwork_9131 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42055/revisions/4/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s4-devices:
  fi-cfl-s3:  PASS -> DMESG-WARN (fdo#104056)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951)


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


== Participating hosts (44 -> 39) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4246 -> Patchwork_9131

  CI_DRM_4246: 5195e857106a3836274e612b26d9d7c6289d8874 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9131: 2eb0165a562e751ffc7ea1005b6b8d0ad5680476 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2eb0165a562e drm/i915/icl: Wa_1406463099
3ef3f3bfbd0c drm/i915/icl: WaEnablePreemptionGranularityControlByUMD
470da3adf07f drm/i915/icl: WaAllowUMDToModifySamplerMode
8145c9ad6df6 drm/i915/icl: WaAllowUmdWriteTRTTRootTable
ee230c83ae4f drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken7
2c075b6f07a4 drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken2
417bfa1c01d2 drm/i915/icl: WaSendPushConstantsFromMMIO
fab7171add4b drm/i915/icl: WaEnableFloatBlendOptimization
2727cb155b10 drm/i915/icl: Wa_2006665173
8cef56bcdc8c drm/i915/icl: WaEnableStateCacheRedirectToCS
61a5eb6c1851 drm/i915/icl: WaDisableImprovedTdlClkGating

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: New interface files for GuC starting in Gen11

[Patchwork]

== Series Details ==

Series: drm/i915/guc: New interface files for GuC starting in Gen11
URL   : https://patchwork.freedesktop.org/series/43806/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4246 -> Patchwork_9130 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43806/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@read-crc-pipe-c-frame-sequence:
  fi-cfl-s3:  PASS -> FAIL (fdo#103481)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951)


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


== Participating hosts (44 -> 39) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4246 -> Patchwork_9130

  CI_DRM_4246: 5195e857106a3836274e612b26d9d7c6289d8874 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9130: b16e12e83432a3647bbad46c1783aadfb5f26e14 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b16e12e83432 drm/i915/guc: New interface files for GuC starting in Gen11

== Logs ==

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

[Intel-gfx] [CI 2/2] drm/i915: "Race-to-idle" after switching to the kernel context

[Chris Wilson]

During suspend we want to flush out all active contexts and their
rendering. To do so we queue a request from the kernel's context, once
we know that request is done, we know the GPU is completely idle. To
speed up that switch bump the GPU clocks.

Switching to the kernel context prior to idling is also used to enforce
a barrier before changing OA properties, and when evicting active
rendering from the global GTT. All cases where we do want to
race-to-idle.

v2: Limit the boosting to only the switch before suspend.
v3: Limit it to the wait-for-idle on suspend.

Signed-off-by: Chris Wilson 
Cc: David Weinehall 
Cc: Mika Kuoppala 
Tested-by: David Weinehall  #v1
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 27 +--
 drivers/gpu/drm/i915/i915_request.h |  1 +
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c93f5dcb1d82..7b5544efa0ba 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3704,7 +3704,29 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file)
 
 static int wait_for_timeline(struct i915_timeline *tl, unsigned int flags)
 {
-   return i915_gem_active_wait(>last_request, flags);
+   struct i915_request *rq;
+   long ret;
+
+   rq = i915_gem_active_get_unlocked(>last_request);
+   if (!rq)
+   return 0;
+
+   /*
+* "Race-to-idle".
+*
+* Switching to the kernel context is often used a synchronous
+* step prior to idling, e.g. in suspend for flushing all
+* current operations to memory before sleeping. These we
+* want to complete as quickly as possible to avoid prolonged
+* stalls, so allow the gpu to boost to maximum clocks.
+*/
+   if (flags & I915_WAIT_FOR_IDLE_BOOST)
+   gen6_rps_boost(rq, NULL);
+
+   ret = i915_request_wait(rq, flags, MAX_SCHEDULE_TIMEOUT);
+   i915_request_put(rq);
+
+   return ret < 0 ? ret : 0;
 }
 
 static int wait_for_engines(struct drm_i915_private *i915)
@@ -4979,7 +5001,8 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
 
ret = i915_gem_wait_for_idle(dev_priv,
 I915_WAIT_INTERRUPTIBLE |
-I915_WAIT_LOCKED);
+I915_WAIT_LOCKED |
+I915_WAIT_FOR_IDLE_BOOST);
if (ret && ret != -EIO)
goto err_unlock;
 
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 17a9fa03..491ff81d0fea 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -267,6 +267,7 @@ long i915_request_wait(struct i915_request *rq,
 #define I915_WAIT_INTERRUPTIBLEBIT(0)
 #define I915_WAIT_LOCKED   BIT(1) /* struct_mutex held, handle GPU reset */
 #define I915_WAIT_ALL  BIT(2) /* used by i915_gem_object_wait() */
+#define I915_WAIT_FOR_IDLE_BOOST BIT(3)
 
 static inline u32 intel_engine_get_seqno(struct intel_engine_cs *engine);
 
-- 
2.17.0

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

[Intel-gfx] [CI 1/2] drm/i915: Switch to kernel context before idling at runtime

[Chris Wilson]

We can reduce our exposure to random neutrinos by resting on the kernel
context having flushed out the user contexts to system memory and
beyond. The corollary is that we then we require two passes through the
idle handler to go to sleep, which on a truly idle system involves an
extra pass through the slow and irregular retire work handler.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  8 ++--
 drivers/gpu/drm/i915/i915_gem.c | 29 -
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a8e7761cdc7d..594ee65a6c06 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4226,8 +4226,12 @@ i915_drop_caches_set(void *data, u64 val)
i915_gem_shrink_all(dev_priv);
fs_reclaim_release(GFP_KERNEL);
 
-   if (val & DROP_IDLE)
-   drain_delayed_work(_priv->gt.idle_work);
+   if (val & DROP_IDLE) {
+   do {
+   flush_delayed_work(_priv->gt.retire_work);
+   drain_delayed_work(_priv->gt.idle_work);
+   } while (READ_ONCE(dev_priv->gt.awake));
+   }
 
if (val & DROP_FREED)
i915_gem_drain_freed_objects(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 05f44ca35a06..c93f5dcb1d82 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -139,6 +139,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
 
 static u32 __i915_gem_park(struct drm_i915_private *i915)
 {
+   GEM_TRACE("\n");
+
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(i915->gt.active_requests);
GEM_BUG_ON(!list_empty(>gt.active_rings));
@@ -193,6 +195,8 @@ void i915_gem_park(struct drm_i915_private *i915)
 
 void i915_gem_unpark(struct drm_i915_private *i915)
 {
+   GEM_TRACE("\n");
+
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(!i915->gt.active_requests);
 
@@ -3504,6 +3508,21 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (!READ_ONCE(dev_priv->gt.awake))
return;
 
+   /*
+* Flush out the last user context, leaving only the pinned
+* kernel context resident. When we are idling on the kernel_context,
+* no more new requests (with a context switch) are emitted and we
+* can finally rest. A consequence is that the idle work handler is
+* always called at least twice before idling (and if the system is
+* idle that implies a round trip through the retire worker).
+*/
+   mutex_lock(_priv->drm.struct_mutex);
+   i915_gem_switch_to_kernel_context(dev_priv);
+   mutex_unlock(_priv->drm.struct_mutex);
+
+   GEM_TRACE("active_requests=%d (after switch-to-kernel-context)\n",
+ READ_ONCE(dev_priv->gt.active_requests));
+
/*
 * Wait for last execlists context complete, but bail out in case a
 * new request is submitted. As we don't trust the hardware, we
@@ -4914,11 +4933,9 @@ static void assert_kernel_context_is_current(struct 
drm_i915_private *i915)
 
 void i915_gem_sanitize(struct drm_i915_private *i915)
 {
-   if (i915_terminally_wedged(>gpu_error)) {
-   mutex_lock(>drm.struct_mutex);
+   mutex_lock(>drm.struct_mutex);
+   if (i915_terminally_wedged(>gpu_error))
i915_gem_unset_wedged(i915);
-   mutex_unlock(>drm.struct_mutex);
-   }
 
/*
 * If we inherit context state from the BIOS or earlier occupants
@@ -4930,6 +4947,9 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
 */
if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+
+   i915_gem_contexts_lost(i915);
+   mutex_unlock(>drm.struct_mutex);
 }
 
 int i915_gem_suspend(struct drm_i915_private *dev_priv)
@@ -4965,7 +4985,6 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
 
assert_kernel_context_is_current(dev_priv);
}
-   i915_gem_contexts_lost(dev_priv);
mutex_unlock(>struct_mutex);
 
intel_uc_suspend(dev_priv);
-- 
2.17.0

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: New interface files for GuC starting in Gen11

[Patchwork]

== Series Details ==

Series: drm/i915/guc: New interface files for GuC starting in Gen11
URL   : https://patchwork.freedesktop.org/series/43806/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b16e12e83432 drm/i915/guc: New interface files for GuC starting in Gen11
-:38: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#38: 
new file mode 100644

-:43: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#43: FILE: drivers/gpu/drm/i915/intel_guc_client_interface.h:1:
+/*

-:110: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#110: FILE: drivers/gpu/drm/i915/intel_guc_client_interface.h:68:
+   u32 : 26;
^

-:127: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#127: FILE: drivers/gpu/drm/i915/intel_guc_client_interface.h:85:
+   u32 : 24;
^

-:247: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#247: FILE: drivers/gpu/drm/i915/intel_guc_client_interface.h:205:
+   u32 : 2;
^

-:277: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#277: FILE: drivers/gpu/drm/i915/intel_guc_client_interface.h:235:
+   u32 : 5;
^

-:304: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#304: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:1:
+/*

-:366: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#366: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:63:
+   u32 : 29;
^

-:525: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#525: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:222:
+   u32 : 24;
^

-:700: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#700: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:397:
+   u32 : 3;
^

-:719: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#719: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:416:
+   u32 : 5;
^

-:733: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#733: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:430:
+   u32 : 3;
^

-:762: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#762: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:459:
+   u32 : 1;
^

-:766: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#766: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:463:
+   u32 : 1;
^

-:770: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#770: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:467:
+   u32 : 1;
^

-:776: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#776: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:473:
+   u32 : 1;
^

-:779: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#779: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:476:
+   u32 : 1;
^

-:786: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#786: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:483:
+   u32 : 1;
^

-:808: CHECK:LINE_SPACING: Please don't use multiple blank lines
#808: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:505:
+
+

-:879: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#879: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:576:
+   u32 : 27;
^

-:897: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#897: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:594:
+   u32 : 1;
^

-:924: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#924: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:621:
+   u32 : 23;
^

-:956: CHECK:LINE_SPACING: Please don't use multiple blank lines
#956: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:653:
+
+

-:962: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#962: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:659:
+   u32 : 30;
^

-:978: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#978: FILE: drivers/gpu/drm/i915/intel_guc_kmd_interface.h:675:
+   u32 : 1;
^

-:979: ERROR:SPACING: space prohibited before that ':' (ctx:WxW)
#979: FILE: 

[Intel-gfx] [PATCH 11/11] drm/i915/icl: Wa_1406463099

[Oscar Mateo]

Prevents an error in the GAM unit. Also known as WaGamTlbPendError

References: HSDES#1406463099
References: HSDES#1406465643
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_reg.h  | 5 +++--
 drivers/gpu/drm/i915/intel_workarounds.c | 7 +++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 42835d79..8a18447 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2306,8 +2306,9 @@ enum i915_power_well_id {
 #define   GAMW_ECO_ENABLE_64K_IPS_FIELD 0xF
 
 #define GAMT_CHKN_BIT_REG  _MMIO(0x4ab8)
-#define   GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING (1<<28)
-#define   GAMT_CHKN_DISABLE_I2M_CYCLE_ON_WR_PORT   (1<<24)
+#define   GAMT_CHKN_DISABLE_L3_COH_PIPE(1 << 31)
+#define   GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING (1 << 28)
+#define   GAMT_CHKN_DISABLE_I2M_CYCLE_ON_WR_PORT   (1 << 24)
 
 #if 0
 #define PRB0_TAIL  _MMIO(0x2030)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 474e498..77929df 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -859,6 +859,13 @@ static void icl_gt_workarounds_apply(struct 
drm_i915_private *dev_priv)
   PMFLUSHDONE_LNICRSDROP |
   PMFLUSH_GAPL3UNBLOCK |
   PMFLUSHDONE_LNEBLK);
+
+   /* Wa_1406463099:icl
+* Formerly known as WaGamTlbPendError
+*/
+   I915_WRITE(GAMT_CHKN_BIT_REG,
+  I915_READ(GAMT_CHKN_BIT_REG) |
+  GAMT_CHKN_DISABLE_L3_COH_PIPE);
 }
 
 void intel_gt_workarounds_apply(struct drm_i915_private *dev_priv)
-- 
1.9.1

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

[Intel-gfx] [PATCH 04/11] drm/i915/icl: WaEnableFloatBlendOptimization

[Oscar Mateo]

Enables blend optimization for floating point RTs

v2: Rebased on top of the WA refactoring
v3: Added References (Mika)

References: HSDES#1406393558
Cc: Mika Kuoppala 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_reg.h  | 3 +++
 drivers/gpu/drm/i915/intel_workarounds.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6e88c6b..f123c3e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2663,6 +2663,9 @@ enum i915_power_well_id {
 #define   GEN8_4x4_STC_OPTIMIZATION_DISABLE(1<<6)
 #define   GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE   (1<<1)
 
+#define GEN10_CACHE_MODE_SS_MMIO(0xe420)
+#define   FLOAT_BLEND_OPTIMIZATION_ENABLE  (1 << 4)
+
 #define GEN6_BLITTER_ECOSKPD   _MMIO(0x221d0)
 #define   GEN6_BLITTER_LOCK_SHIFT  16
 #define   GEN6_BLITTER_FBC_NOTIFY  (1<<3)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 33a1a0c..e9c00b0 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -479,6 +479,9 @@ static int icl_ctx_workarounds_init(struct drm_i915_private 
*dev_priv)
WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
  GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC);
 
+   /* WaEnableFloatBlendOptimization:icl */
+   WA_SET_BIT_MASKED(GEN10_CACHE_MODE_SS, FLOAT_BLEND_OPTIMIZATION_ENABLE);
+
return 0;
 }
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 10/11] drm/i915/icl: WaEnablePreemptionGranularityControlByUMD

[Oscar Mateo]

Apparently HW did not whitelist this register properly.

Do Linux UMDs make use of this? This change has been security
reviewed and the whitelisting approved. Virtualization of other
OSes could certainly use it.

References: HSDES#1305642430
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_workarounds.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 912f8b5..474e498 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -978,6 +978,9 @@ static void icl_whitelist_build(struct whitelist *w)
 
/* WaAllowUMDToModifySamplerMode:icl */
whitelist_reg(w, GEN10_SAMPLER_MODE);
+
+   /* WaEnablePreemptionGranularityControlByUMD:icl */
+   whitelist_reg(w, GEN8_CS_CHICKEN1);
 }
 
 static struct whitelist *whitelist_build(struct intel_engine_cs *engine,
-- 
1.9.1

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

[Intel-gfx] [PATCH 08/11] drm/i915/icl: WaAllowUmdWriteTRTTRootTable

[Oscar Mateo]

Required for TR-TT (Tiled Resource Translation Table) support.

Do Linux UMDs make use of this? This change has been security
reviewed and the whitelisting approved. Virtualization of other
OSes could certainly use it.

v2: For whatever reason, this ended up in KBL (??!!)
v3: Rebased on top of the WA refactoring
v4: Rebased on top of whitelist reg refactoring (Michel)

Cc: Mika Kuoppala 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_reg.h  | 3 +++
 drivers/gpu/drm/i915/intel_workarounds.c | 4 
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f123c3e..1fb86bd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8299,6 +8299,9 @@ enum {
 #define GAMW_ECO_DEV_RW_IA_REG _MMIO(0x4080)
 #define   GAMW_ECO_DEV_CTX_RELOAD_DISABLE  (1 << 7)
 
+#define TR_VA_TTL3_PTR_DW0 _MMIO(0x4DE0)
+#define TR_VA_TTL3_PTR_DW1 _MMIO(0x4DE4)
+
 /* IVYBRIDGE DPF */
 #define GEN7_L3CDERRST1(slice) _MMIO(0xB008 + (slice) * 0x200) /* L3CD 
Error Status 1 */
 #define   GEN7_L3CDERRST1_ROW_MASK (0x7ff<<14)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index cce3e3f..9d6b550 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -971,6 +971,10 @@ static void icl_whitelist_build(struct whitelist *w)
 
/* WaAllowUMDToModifyHalfSliceChicken7:icl */
whitelist_reg(w, GEN9_HALF_SLICE_CHICKEN7);
+
+   /* WaAllowUmdWriteTRTTRootTable:icl */
+   whitelist_reg(w, TR_VA_TTL3_PTR_DW0);
+   whitelist_reg(w, TR_VA_TTL3_PTR_DW1);
 }
 
 static struct whitelist *whitelist_build(struct intel_engine_cs *engine,
-- 
1.9.1

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

[Intel-gfx] [PATCH 02/11] drm/i915/icl: WaEnableStateCacheRedirectToCS

[Oscar Mateo]

Redirects the state cache to the CS Command buffer section for
performance reasons.

v2: Rebased
v3: Rebased on top of the WA refactoring
v3: Added References (Mika)

References: HSDES#1604325460
Cc: Mika Kuoppala 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_reg.h  | 1 +
 drivers/gpu/drm/i915/intel_workarounds.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4eb159f..924b9a6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7227,6 +7227,7 @@ enum {
 #define  DISABLE_PIXEL_MASK_CAMMING(1<<14)
 
 #define GEN9_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
+#define   GEN11_STATE_CACHE_REDIRECT_TO_CS (1 << 11)
 
 #define GEN7_L3SQCREG1 _MMIO(0xB010)
 #define  VLV_B0_WA_L3SQCREG1_VALUE 0x00D3
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 04aa885..1d29803 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -470,6 +470,10 @@ static int icl_ctx_workarounds_init(struct 
drm_i915_private *dev_priv)
WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2,
  GEN11_TDL_CLOCK_GATING_FIX_DISABLE);
 
+   /* WaEnableStateCacheRedirectToCS:icl */
+   WA_SET_BIT_MASKED(GEN9_SLICE_COMMON_ECO_CHICKEN1,
+ GEN11_STATE_CACHE_REDIRECT_TO_CS);
+
return 0;
 }
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 05/11] drm/i915/icl: WaSendPushConstantsFromMMIO

[Oscar Mateo]

Allows UMDs to set 'Disable Gather at Set Shader Common Slice'.

Do Linux UMDs make use of this? This change has been security
reviewed and the whitelisting approved. Virtualization of other
OSes could certainly use it...

v2: Rebased
v3: Rebased on top of the WA refactoring
v4: Rebased on top of the WA whitelist reg refactoring (Michel)
v5: Added References (Mika)

References: HSDES#1405764967
Cc: Mika Kuoppala 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_workarounds.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index e9c00b0..804de04 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -963,6 +963,8 @@ static void cnl_whitelist_build(struct whitelist *w)
 
 static void icl_whitelist_build(struct whitelist *w)
 {
+   /* WaSendPushConstantsFromMMIO:icl */
+   whitelist_reg(w, COMMON_SLICE_CHICKEN2);
 }
 
 static struct whitelist *whitelist_build(struct intel_engine_cs *engine,
-- 
1.9.1

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

[Intel-gfx] [PATCH 03/11] drm/i915/icl: Wa_2006665173

[Oscar Mateo]

Disable blend embellishment in RCC.

Also, some other registers style fixed in passing.

v2: Rebased on top of the WA refactoring
v3: Added References (Mika)
v4:
  - Fixed in B0
  - Mentioned style fixes in commit message

References: HSDES#2006665173
Cc: Mika Kuoppala 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_reg.h  | 18 +++---
 drivers/gpu/drm/i915/intel_workarounds.c |  5 +
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 924b9a6..6e88c6b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7211,13 +7211,17 @@ enum {
 
 /* GEN7 chicken */
 #define GEN7_COMMON_SLICE_CHICKEN1 _MMIO(0x7010)
-# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1<<10) | (1<<26))
-# define GEN9_RHWO_OPTIMIZATION_DISABLE(1<<14)
-#define COMMON_SLICE_CHICKEN2  _MMIO(0x7014)
-# define GEN9_PBE_COMPRESSED_HASH_SELECTION(1<<13)
-# define GEN9_DISABLE_GATHER_AT_SET_SHADER_COMMON_SLICE (1<<12)
-# define GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION (1<<8)
-# define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE  (1<<0)
+  #define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC((1 << 10) | (1 << 26))
+  #define GEN9_RHWO_OPTIMIZATION_DISABLE   (1 << 14)
+
+#define COMMON_SLICE_CHICKEN2  _MMIO(0x7014)
+  #define GEN9_PBE_COMPRESSED_HASH_SELECTION   (1 << 13)
+  #define GEN9_DISABLE_GATHER_AT_SET_SHADER_COMMON_SLICE   (1 << 12)
+  #define GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION (1 << 8)
+  #define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE (1 << 0)
+
+#define GEN11_COMMON_SLICE_CHICKEN3_MMIO(0x7304)
+  #define GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC   (1 << 11)
 
 #define HIZ_CHICKEN_MMIO(0x7018)
 # define CHV_HZ_8X8_MODE_IN_1X (1<<15)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 1d29803..33a1a0c 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -474,6 +474,11 @@ static int icl_ctx_workarounds_init(struct 
drm_i915_private *dev_priv)
WA_SET_BIT_MASKED(GEN9_SLICE_COMMON_ECO_CHICKEN1,
  GEN11_STATE_CACHE_REDIRECT_TO_CS);
 
+   /* Wa_2006665173:icl (pre-prod) */
+   if (IS_ICL_REVID(dev_priv, ICL_REVID_A0, ICL_REVID_A0))
+   WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
+ GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC);
+
return 0;
 }
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 06/11] drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken2

[Oscar Mateo]

Required to dinamically set 'Small PL Lossless Fix Enable'

Do Linux UMDs make use of this? This change has been security
reviewed and the whitelisting approved. Virtualization of other
OSes could certainly use it.

v2: For whatever reason, this ended up in KBL (??!!)
v3: Rebased on top of the WA refactoring
v4: Rebased on top of whitelist reg refactoring (Michel)
v5: Added References (Mika)

References: HSDES#1804860039
Cc: Mika Kuoppala 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_workarounds.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 804de04..e173e17 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -965,6 +965,9 @@ static void icl_whitelist_build(struct whitelist *w)
 {
/* WaSendPushConstantsFromMMIO:icl */
whitelist_reg(w, COMMON_SLICE_CHICKEN2);
+
+   /* WaAllowUMDToModifyHalfSliceChicken2:icl */
+   whitelist_reg(w, HALF_SLICE_CHICKEN2);
 }
 
 static struct whitelist *whitelist_build(struct intel_engine_cs *engine,
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 00/11] Workarounds for Icelake

[Oscar Mateo]

The remaining WA patches that haven't been merged to date, plus
two new ones (WaEnablePreemptionGranularityControlByUMD &
Wa_1406463099).

Oscar Mateo (11):
  drm/i915/icl: WaDisableImprovedTdlClkGating
  drm/i915/icl: WaEnableStateCacheRedirectToCS
  drm/i915/icl: Wa_2006665173
  drm/i915/icl: WaEnableFloatBlendOptimization
  drm/i915/icl: WaSendPushConstantsFromMMIO
  drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken2
  drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken7
  drm/i915/icl: WaAllowUmdWriteTRTTRootTable
  drm/i915/icl: WaAllowUMDToModifySamplerMode
  drm/i915/icl: WaEnablePreemptionGranularityControlByUMD
  drm/i915/icl: Wa_1406463099

 drivers/gpu/drm/i915/i915_reg.h  | 37 +++
 drivers/gpu/drm/i915/intel_workarounds.c | 44 
 2 files changed, 70 insertions(+), 11 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 07/11] drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken7

[Oscar Mateo]

Required to dinamically set 'Trilinear Filter Quality Mode'

Do Linux UMDs make use of this? This change has been security
reviewed and the whitelisting approved. Virtualization of other
OSes could certainly use it.

v2: For whatever reason, this ended up in KBL (??!!)
v3: Rebased on top of the WA refactoring
v4: Rebased on top of the whitelist reg refactoring (Michel)
v5: Added References (Mika)

References: HSDES#1804860157
Cc: Mika Kuoppala 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_workarounds.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index e173e17..cce3e3f 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -968,6 +968,9 @@ static void icl_whitelist_build(struct whitelist *w)
 
/* WaAllowUMDToModifyHalfSliceChicken2:icl */
whitelist_reg(w, HALF_SLICE_CHICKEN2);
+
+   /* WaAllowUMDToModifyHalfSliceChicken7:icl */
+   whitelist_reg(w, GEN9_HALF_SLICE_CHICKEN7);
 }
 
 static struct whitelist *whitelist_build(struct intel_engine_cs *engine,
-- 
1.9.1

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

[Intel-gfx] [PATCH 09/11] drm/i915/icl: WaAllowUMDToModifySamplerMode

[Oscar Mateo]

Required for Bindless samplers.

Do Linux UMDs make use of this? This change has been security
reviewed and the whitelisting approved. Virtualization of other
OSes could certainly use it.

v2: Rebased on top of the WA refactoring (Michel)
v3: Added References (Mika)

References: HSDES#1404695891
Cc: Mika Kuoppala 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_reg.h  | 2 ++
 drivers/gpu/drm/i915/intel_workarounds.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1fb86bd..42835d79 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8302,6 +8302,8 @@ enum {
 #define TR_VA_TTL3_PTR_DW0 _MMIO(0x4DE0)
 #define TR_VA_TTL3_PTR_DW1 _MMIO(0x4DE4)
 
+#define GEN10_SAMPLER_MODE _MMIO(0xE18C)
+
 /* IVYBRIDGE DPF */
 #define GEN7_L3CDERRST1(slice) _MMIO(0xB008 + (slice) * 0x200) /* L3CD 
Error Status 1 */
 #define   GEN7_L3CDERRST1_ROW_MASK (0x7ff<<14)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 9d6b550..912f8b5 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -975,6 +975,9 @@ static void icl_whitelist_build(struct whitelist *w)
/* WaAllowUmdWriteTRTTRootTable:icl */
whitelist_reg(w, TR_VA_TTL3_PTR_DW0);
whitelist_reg(w, TR_VA_TTL3_PTR_DW1);
+
+   /* WaAllowUMDToModifySamplerMode:icl */
+   whitelist_reg(w, GEN10_SAMPLER_MODE);
 }
 
 static struct whitelist *whitelist_build(struct intel_engine_cs *engine,
-- 
1.9.1

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

[Intel-gfx] [PATCH 01/11] drm/i915/icl: WaDisableImprovedTdlClkGating

[Oscar Mateo]

Revert to the legacy implementation.

v2: GEN7_ROW_CHICKEN2 is masked
v3:
  - Rebased
  - Renamed to Wa_2006611047
  - A0 and B0 only
v4:
  - Add spaces around '<<' (and fix the surrounding code as well)
  - Mark the WA as pre-prod
v5: Rebased on top of the WA refactoring
v6: Added References (Mika)
v7: Fixed in B0

References: HSDES#2006611047
Signed-off-by: Oscar Mateo 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_reg.h  | 5 +++--
 drivers/gpu/drm/i915/intel_workarounds.c | 7 +++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6953419..4eb159f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8328,8 +8328,9 @@ enum {
 
 #define GEN7_ROW_CHICKEN2  _MMIO(0xe4f4)
 #define GEN7_ROW_CHICKEN2_GT2  _MMIO(0xf4f4)
-#define   DOP_CLOCK_GATING_DISABLE (1<<0)
-#define   PUSH_CONSTANT_DEREF_DISABLE  (1<<8)
+#define   DOP_CLOCK_GATING_DISABLE (1 << 0)
+#define   PUSH_CONSTANT_DEREF_DISABLE  (1 << 8)
+#define   GEN11_TDL_CLOCK_GATING_FIX_DISABLE   (1 << 1)
 
 #define HSW_ROW_CHICKEN3   _MMIO(0xe49c)
 #define  HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index cea5710..04aa885 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -463,6 +463,13 @@ static int icl_ctx_workarounds_init(struct 
drm_i915_private *dev_priv)
 */
WA_SET_BIT_MASKED(ICL_HDC_MODE, HDC_FORCE_NON_COHERENT);
 
+   /* Wa_2006611047:icl (pre-prod)
+* Formerly known as WaDisableImprovedTdlClkGating
+*/
+   if (IS_ICL_REVID(dev_priv, ICL_REVID_A0, ICL_REVID_A0))
+   WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2,
+ GEN11_TDL_CLOCK_GATING_FIX_DISABLE);
+
return 0;
 }
 
-- 
1.9.1

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

[Intel-gfx] [RFC PATCH] drm/i915/guc: New interface files for GuC starting in Gen11

[Oscar Mateo]

GuC interface has been redesigned (or cleaned up, rather) starting
with Gen11, as a stepping stone towards a new branching strategy
that helps maintain backwards compatibility with previous Gens, as
well as sideward compatibility with other OSes.

The interface is split in two header files: one for the KMD and one
for clients of the GuC (which, in our case, happens to be the KMD
as well). SLPC interface files will come at a later date.

Could we get eyes on the new interface header files, to make sure the
GuC team is moving in the right direction?

Signed-off-by: Oscar Mateo 
Cc: Joonas Lahtinen 
Cc: Kevin Rogovin 
Cc: John A Spotswood 
Cc: Anusha Srivatsa 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Michel Thierry 
Cc: Chris Wilson 
Cc: Michał Winiarski 
Cc: Tomasz Lis 
Cc: Jon Ewins 
Cc: Sujaritha Sundaresan 
Cc: Jalpa Patel 
Cc: Jackie Li 
---
 drivers/gpu/drm/i915/intel_guc_client_interface.h | 255 +++
 drivers/gpu/drm/i915/intel_guc_kmd_interface.h| 847 ++
 2 files changed, 1102 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/intel_guc_client_interface.h
 create mode 100644 drivers/gpu/drm/i915/intel_guc_kmd_interface.h

diff --git a/drivers/gpu/drm/i915/intel_guc_client_interface.h 
b/drivers/gpu/drm/i915/intel_guc_client_interface.h
new file mode 100644
index 000..1ef91a7
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_client_interface.h
@@ -0,0 +1,255 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef _INTEL_GUC_CLIENT_INTERFACE_H_
+#define _INTEL_GUC_CLIENT_INTERFACE_H_
+
+#pragma pack(1)
+
+/*
+ ** Engines **
+ */
+
+#define GUC_MAX_ENGINE_INSTANCE_PER_CLASS  4
+#define GUC_MAX_SCHEDULABLE_ENGINE_CLASS   5
+#define GUC_MAX_ENGINE_CLASS_COUNT 6
+#define GUC_ENGINE_INVALID 6
+
+/* Engine Class that uKernel can schedule on. This is just a SW enumeration.
+ * HW configuration will depend on the Platform and SKU
+ */
+enum uk_engine_class {
+   UK_RENDER_ENGINE_CLASS = 0,
+   UK_VDECENC_ENGINE_CLASS = 1,
+   UK_VE_ENGINE_CLASS = 2,
+   UK_BLT_COPY_ENGINE_CLASS = 3,
+   UK_RESERVED_ENGINE_CLASS = 4,
+   UK_OTHER_ENGINE_CLASS = 5,
+};
+
+/* Engine Instance that uKernel can schedule on */
+enum uk_engine_instance {
+   UK_ENGINE_INSTANCE_0 = 0,
+   UK_ENGINE_INSTANCE_1 = 1,
+   UK_ENGINE_INSTANCE_2 = 2,
+   UK_ENGINE_INSTANCE_3 = 3,
+   UK_INVALID_ENGINE_INSTANCE = GUC_MAX_ENGINE_INSTANCE_PER_CLASS,
+   UK_ENGINE_ALL_INSTANCES = UK_INVALID_ENGINE_INSTANCE
+};
+
+/* Target Engine field used in WI header and Guc2Host */
+struct guc_target_engine {
+   union {
+   struct {
+   /* One of enum uk_engine_class */
+   u8 engine_class : 3;
+   /* One of enum uk_engine_instance */
+   u8 engine_instance : 4;
+   /* All enabled engine classes and instances */
+   u8 all_engines : 1;
+   };
+   u8 value;
+   };
+};
+
+struct guc_engine_class_bit_map {
+   union {
+   /* Bit positions must match enum uk_engine_class value */
+   struct {
+   u32 render_engine_class : 1;
+   u32 vdecenc_engine_class : 1;
+   u32 ve_engine_class : 1;
+   u32 blt_copy_engine_class : 1;
+   u32 reserved_engine_class : 1;
+   u32 other_engine_class : 1;
+   u32 : 26;
+   };
+   u32 value;
+   };
+};
+
+struct guc_engine_instance_bit_map {
+   union {
+   struct {
+   u32 engine0 : 1;
+   u32 engine1 : 1;
+   u32 engine2 : 1;
+   u32 engine3 : 1;
+   u32 engine4 : 1;
+   u32 engine5 : 1;
+   u32 engine6 : 1;
+   u32 engine7 : 1;
+   u32 : 24;
+   };
+   u32 value;
+   };
+};
+
+struct guc_engine_bit_map {
+   struct guc_engine_class_bit_map engine_class_bit_map;
+   struct guc_engine_instance_bit_map
+   engine_instance_bit_map[GUC_MAX_ENGINE_CLASS_COUNT];
+};

Re: [Intel-gfx] [PATCH] drm/i915 : clip yuv primary planes to hw constraints

[Fritz Koenig]

On Fri, May 25, 2018 at 11:12 AM Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:

> On Fri, May 25, 2018 at 11:00:23AM -0700, Fritz Koenig wrote:
> > YUV planes need to be multiples of 2 to scan out. This was
> > handled correctly for planes other than the primary in the
> > intel_check_sprite_plane, where the code fixes up the plane
> > and makes it compliant. Move this code into a location that
> > allows the primary check to access it as well.
> >
> > Signed-off-by: Fritz Koenig 
> > ---
> >
> > Hi,
> >
> > I think this is a better implementation where instead of rejecting
> > yuv planes that are not correctly aligned, they are fixed up.  This
> > is done by reusing the sprite check code that was already doing that.
> >
> >  drivers/gpu/drm/i915/intel_display.c | 170 +++
> >  drivers/gpu/drm/i915/intel_drv.h |   2 +
> >  drivers/gpu/drm/i915/intel_sprite.c  | 154 +---
> >  3 files changed, 175 insertions(+), 151 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
> > index 56004ffbd8bb..1328fb90367f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12854,6 +12854,170 @@ skl_max_scale(struct intel_crtc *intel_crtc,
struct intel_crtc_state *crtc_state
> >   return max_scale;
> >  }
> >
> > +int
> > +intel_clip_src_rect(struct intel_plane *plane,
> > + struct intel_crtc_state *crtc_state,
> > + struct intel_plane_state *state)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > + struct drm_framebuffer *fb = state->base.fb;
> > + int crtc_x, crtc_y;
> > + unsigned int crtc_w, crtc_h;
> > + uint32_t src_x, src_y, src_w, src_h;
> > + struct drm_rect *src = >base.src;
> > + struct drm_rect *dst = >base.dst;
> > + struct drm_rect clip = {};
> > + int hscale, vscale;
> > + int max_scale, min_scale;
> > + bool can_scale;
> > +
> > + *src = drm_plane_state_src(>base);
> > + *dst = drm_plane_state_dest(>base);
> > +
> > + /* setup can_scale, min_scale, max_scale */
> > + if (INTEL_GEN(dev_priv) >= 9) {
> > + /* use scaler when colorkey is not required */
> > + if (!state->ckey.flags) {
> > + can_scale = 1;
> > + min_scale = 1;
> > + max_scale = skl_max_scale(crtc, crtc_state);
> > + } else {
> > + can_scale = 0;
> > + min_scale = DRM_PLANE_HELPER_NO_SCALING;
> > + max_scale = DRM_PLANE_HELPER_NO_SCALING;
> > + }
> > + } else {
> > + can_scale = plane->can_scale;
> > + max_scale = plane->max_downscale << 16;
> > + min_scale = plane->can_scale ? 1 : (1 << 16);
> > + }
> > +
> > + /*
> > +  * FIXME the following code does a bunch of fuzzy adjustments to
the
> > +  * coordinates and sizes. We probably need some way to decide
whether
> > +  * more strict checking should be done instead.
> > +  */
> > + drm_rect_rotate(src, fb->width << 16, fb->height << 16,
> > + state->base.rotation);
> > +
> > + hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale,
max_scale);
> > + BUG_ON(hscale < 0);
> > +
> > + vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale,
max_scale);
> > + BUG_ON(vscale < 0);

> Your baseline is already outdated.


Sorry, I was on the incorrect branch.

I tried to retarget at drm-intel-fixes, but this still appears to be
incorrect as it is still failing to patch.  Should I be targeting
drm-intel-next instead?

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for More ICL display patches (rev11)

[Patchwork]

== Series Details ==

Series: More ICL display patches (rev11)
URL   : https://patchwork.freedesktop.org/series/43546/
State : failure

== Summary ==

Applying: drm/i915/icl: Extend AUX F interrupts to ICL
Applying: drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISC
Applying: drm/i915/icl: introduce tc_port
Applying: drm/i915/icl: Support for TC North Display interrupts
Applying: drm/i915/icp: Add Interrupt Support
Applying: drm/i915/icl: Add register definition for DFLEXDPMLE
Applying: drm/i915/icl: Add DDI HDMI level selection for ICL
Applying: drm/i915/icl: Map VBT DDC Pin to BSpec DDC Pin
Applying: drm/i915/icl: Add Icelake PCH detection
Applying: drm/i915/icl: add icelake_get_ddi_pll()
Applying: drm/i915/icl: Get DDI clock for ICL based on PLLs.
Applying: drm/i915/icl: Calculate link clock using the new registers
Applying: drm/i915/icl: unconditionally init DDI for every port
Applying: drm/i915/icl: start adding the TBT pll
Applying: drm/i915/icl: compute the TBT PLL registers
Applying: drm/i915/icl: Handle hotplug interrupts for DP over TBT
Applying: drm/i915/icl: Add 10-bit support for hdmi
Applying: drm/i915/icl: implement icl_digital_port_connected()
Applying: drm/i915/icl: store the port type for TC ports
Applying: drm/i915/icl: implement the tc/legacy HPD {dis, }connect flow for DP
Applying: drm/i915/icl: implement the legacy HPD {dis, }connect flow for HDMI
Applying: drm/i915/icl: Update FIA supported lane count for hpd.
Applying: drm/i915/icl: program MG_DP_MODE
Applying: drm/i915/icl: toggle PHY clock gating around link training
Applying: drm/i915/icl: fix gmbus gpio pin mapping
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_reg.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_reg.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_reg.h
Patch failed at 0025 drm/i915/icl: fix gmbus gpio pin mapping
The copy of the patch that failed is found in: .git/rebase-apply/patch
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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915 : clip yuv primary planes to hw constraints (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915 : clip yuv primary planes to hw constraints (rev2)
URL   : https://patchwork.freedesktop.org/series/43796/
State : failure

== Summary ==

Applying: drm/i915 : clip yuv primary planes to hw constraints
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_display.c
M   drivers/gpu/drm/i915/intel_drv.h
M   drivers/gpu/drm/i915/intel_sprite.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_sprite.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_sprite.c
Auto-merging drivers/gpu/drm/i915/intel_drv.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_drv.h
Auto-merging drivers/gpu/drm/i915/intel_display.c
Patch failed at 0001 drm/i915 : clip yuv primary planes to hw constraints
The copy of the patch that failed is found in: .git/rebase-apply/patch
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 v2] drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISC

[Chris Wilson]

Quoting Dhinakaran Pandiyan (2018-05-25 20:43:13)
> The Graphics System Event(GSE) interrupt bit has a new location in the
> GU_MISC_INTERRUPT_{IIR, ISR, IMR, IER} registers. Since GSE was the only
> DE_MISC interrupt that was enabled, with this change we don't enable/handle
> any of DE_MISC interrupts for gen11. Credits to Paulo for pointing out
> the register change.
> 
> v2: from DK
> raw_reg_[read/write], branch prediction hint and drop platform check (Mika)
> 
> Cc: Mika Kuoppala 
> Signed-off-by: Dhinakaran Pandiyan 
> [Paulo: bikesheds and rebases]
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 31 ++-
>  drivers/gpu/drm/i915/i915_reg.h |  7 +++
>  2 files changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 2fd92a886789..cdbc23b21df6 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2943,6 +2943,26 @@ gen11_gt_irq_handler(struct drm_i915_private * const 
> i915,
> spin_unlock(>irq_lock);
>  }
>  
> +static void
> +gen11_gu_misc_irq_handler(struct drm_i915_private *dev_priv,
> + const u32 master_ctl)
> +{
> +   void __iomem * const regs = dev_priv->regs;
> +   u32 iir;
> +
> +   if (!(master_ctl & GEN11_GU_MISC_IRQ))
> +   return;
> +
> +   iir = raw_reg_read(regs, GEN11_GU_MISC_IIR);
> +   if (likely(iir)) {
> +   raw_reg_write(regs, GEN11_GU_MISC_IIR, iir);
> +   if (iir & GEN11_GU_MISC_GSE)
> +   intel_opregion_asle_intr(dev_priv);
> +   else
> +   DRM_ERROR("Unexpected GU Misc interrupt 0x%08x\n", 
> iir);

You should be re-enabling the master interrupt *before* doing any work.
No?

Keeping the master interrupt disabled stops all other CPUs from
processing our interrupts; e.g. basically stopping us feeding the GPU
with work while we wait for you.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISC

[Dhinakaran Pandiyan]

The Graphics System Event(GSE) interrupt bit has a new location in the
GU_MISC_INTERRUPT_{IIR, ISR, IMR, IER} registers. Since GSE was the only
DE_MISC interrupt that was enabled, with this change we don't enable/handle
any of DE_MISC interrupts for gen11. Credits to Paulo for pointing out
the register change.

v2: from DK
raw_reg_[read/write], branch prediction hint and drop platform check (Mika)

Cc: Mika Kuoppala 
Signed-off-by: Dhinakaran Pandiyan 
[Paulo: bikesheds and rebases]
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_irq.c | 31 ++-
 drivers/gpu/drm/i915/i915_reg.h |  7 +++
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2fd92a886789..cdbc23b21df6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2943,6 +2943,26 @@ gen11_gt_irq_handler(struct drm_i915_private * const 
i915,
spin_unlock(>irq_lock);
 }
 
+static void
+gen11_gu_misc_irq_handler(struct drm_i915_private *dev_priv,
+ const u32 master_ctl)
+{
+   void __iomem * const regs = dev_priv->regs;
+   u32 iir;
+
+   if (!(master_ctl & GEN11_GU_MISC_IRQ))
+   return;
+
+   iir = raw_reg_read(regs, GEN11_GU_MISC_IIR);
+   if (likely(iir)) {
+   raw_reg_write(regs, GEN11_GU_MISC_IIR, iir);
+   if (iir & GEN11_GU_MISC_GSE)
+   intel_opregion_asle_intr(dev_priv);
+   else
+   DRM_ERROR("Unexpected GU Misc interrupt 0x%08x\n", iir);
+   }
+}
+
 static irqreturn_t gen11_irq_handler(int irq, void *arg)
 {
struct drm_i915_private * const i915 = to_i915(arg);
@@ -2976,6 +2996,8 @@ static irqreturn_t gen11_irq_handler(int irq, void *arg)
enable_rpm_wakeref_asserts(i915);
}
 
+   gen11_gu_misc_irq_handler(i915, master_ctl);
+
/* Acknowledge and enable interrupts. */
raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, GEN11_MASTER_IRQ | master_ctl);
 
@@ -3465,6 +3487,7 @@ static void gen11_irq_reset(struct drm_device *dev)
 
GEN3_IRQ_RESET(GEN8_DE_PORT_);
GEN3_IRQ_RESET(GEN8_DE_MISC_);
+   GEN3_IRQ_RESET(GEN11_GU_MISC_);
GEN3_IRQ_RESET(GEN8_PCU_);
 }
 
@@ -3908,9 +3931,12 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
uint32_t de_pipe_enables;
u32 de_port_masked = GEN8_AUX_CHANNEL_A;
u32 de_port_enables;
-   u32 de_misc_masked = GEN8_DE_MISC_GSE | GEN8_DE_EDP_PSR;
+   u32 de_misc_masked = GEN8_DE_EDP_PSR;
enum pipe pipe;
 
+   if (INTEL_GEN(dev_priv) <= 10)
+   de_misc_masked |= GEN8_DE_MISC_GSE;
+
if (INTEL_GEN(dev_priv) >= 9) {
de_pipe_masked |= GEN9_DE_PIPE_IRQ_FAULT_ERRORS;
de_port_masked |= GEN9_AUX_CHANNEL_B | GEN9_AUX_CHANNEL_C |
@@ -4004,10 +4030,13 @@ static void gen11_gt_irq_postinstall(struct 
drm_i915_private *dev_priv)
 static int gen11_irq_postinstall(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 gu_misc_masked = GEN11_GU_MISC_GSE;
 
gen11_gt_irq_postinstall(dev_priv);
gen8_de_irq_postinstall(dev_priv);
 
+   GEN3_IRQ_INIT(GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
+
I915_WRITE(GEN11_DISPLAY_INT_CTL, GEN11_DISPLAY_IRQ_ENABLE);
 
I915_WRITE(GEN11_GFX_MSTR_IRQ, GEN11_MASTER_IRQ);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6953419881c4..67d392c3ca2c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7025,9 +7025,16 @@ enum {
 #define GEN8_PCU_IIR _MMIO(0x444e8)
 #define GEN8_PCU_IER _MMIO(0x444ec)
 
+#define GEN11_GU_MISC_ISR  _MMIO(0x444f0)
+#define GEN11_GU_MISC_IMR  _MMIO(0x444f4)
+#define GEN11_GU_MISC_IIR  _MMIO(0x444f8)
+#define GEN11_GU_MISC_IER  _MMIO(0x444fc)
+#define  GEN11_GU_MISC_GSE (1 << 27)
+
 #define GEN11_GFX_MSTR_IRQ _MMIO(0x190010)
 #define  GEN11_MASTER_IRQ  (1 << 31)
 #define  GEN11_PCU_IRQ (1 << 30)
+#define  GEN11_GU_MISC_IRQ (1 << 29)
 #define  GEN11_DISPLAY_IRQ (1 << 16)
 #define  GEN11_GT_DW_IRQ(x)(1 << (x))
 #define  GEN11_GT_DW1_IRQ  (1 << 1)
-- 
2.14.1

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

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

[Chris Wilson]

Quoting Michal Wajdeczko (2018-05-25 13:18:58)
> Some functions already use i915 name instead of dev_priv.
> Let's rename this param in all remaining functions, except
> those that still use legacy macros.
> 
> v2: don't forget about function descriptions (Sagar)
> v3: rebased
> v4: rebased
> v5: rebased, pulled out from the series
> 
> Signed-off-by: Michal Wajdeczko 
> Reviewed-by: Sagar Arun Kamble 
> Cc: Chris Wilson 

And pushed, thanks for the patch.
-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 drm: Eliminate plane->fb/crtc usage for atomic drivers (rev6)

[Patchwork]

== Series Details ==

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

== Summary ==

= CI Bug Log - changes from CI_DRM_4244 -> Patchwork_9127 =

== Summary - WARNING ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/40478/revisions/6/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:PASS -> SKIP


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-hsw-4770r:   PASS -> FAIL (fdo#103928)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-cnl-y3:  PASS -> DMESG-FAIL (fdo#103191, fdo#104724)


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


== Participating hosts (43 -> 39) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4244 -> Patchwork_9127

  CI_DRM_4244: 475c2ec7b8c6e01cce9a360b9839dc0dd0fa9629 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9127: 7f9d7932efb396e62959b591979be1d09e530054 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

7f9d7932efb3 drm: Stop updating plane->crtc/fb/old_fb on atomic drivers
217192f8f2a3 drm/vc4: Stop updating plane->fb/crtc
9517aeb8ac60 drm/virtio: Stop updating plane->crtc
4cc88281b0ba drm/msm: Stop updating plane->fb/crtc
85f059cadaac drm/exynos: Stop updating plane->crtc
ec0551051069 drm/i915: Stop updating plane->fb/crtc
cfb513066187 drm/amdgpu/dc: Stop updating plane->fb
ad29dcb1b25d drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc
93f6a97905a9 drm/vmwgfx: Stop using plane->fb in atomic_enable()
bb80c2fb8b58 drm/vmwgfx: Stop updating plane->fb
04e4465a752e drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb()
e5018087df50 drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()
727d70b71efd drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915 : clip yuv primary planes to hw constraints

[Fritz Koenig]

YUV planes need to be multiples of 2 to scan out. This was
handled correctly for planes other than the primary in the
intel_check_sprite_plane, where the code fixes up the plane
and makes it compliant. Move this code into a location that
allows the primary check to access it as well.

Signed-off-by: Fritz Koenig 
---
 drivers/gpu/drm/i915/intel_display.c | 170 +++
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_sprite.c  | 154 +---
 3 files changed, 175 insertions(+), 151 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5f03af455047..e1eb0fb988a6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12856,6 +12856,170 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct 
intel_crtc_state *crtc_state
return max_scale;
 }
 
+int
+intel_clip_src_rect(struct intel_plane *plane,
+   struct intel_crtc_state *crtc_state,
+   struct intel_plane_state *state)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+   struct drm_framebuffer *fb = state->base.fb;
+   int crtc_x, crtc_y;
+   unsigned int crtc_w, crtc_h;
+   uint32_t src_x, src_y, src_w, src_h;
+   struct drm_rect *src = >base.src;
+   struct drm_rect *dst = >base.dst;
+   struct drm_rect clip = {};
+   int hscale, vscale;
+   int max_scale, min_scale;
+   bool can_scale;
+
+   *src = drm_plane_state_src(>base);
+   *dst = drm_plane_state_dest(>base);
+
+   /* setup can_scale, min_scale, max_scale */
+   if (INTEL_GEN(dev_priv) >= 9) {
+   /* use scaler when colorkey is not required */
+   if (!state->ckey.flags) {
+   can_scale = 1;
+   min_scale = 1;
+   max_scale = skl_max_scale(crtc, crtc_state);
+   } else {
+   can_scale = 0;
+   min_scale = DRM_PLANE_HELPER_NO_SCALING;
+   max_scale = DRM_PLANE_HELPER_NO_SCALING;
+   }
+   } else {
+   can_scale = plane->can_scale;
+   max_scale = plane->max_downscale << 16;
+   min_scale = plane->can_scale ? 1 : (1 << 16);
+   }
+
+   /*
+* FIXME the following code does a bunch of fuzzy adjustments to the
+* coordinates and sizes. We probably need some way to decide whether
+* more strict checking should be done instead.
+*/
+   drm_rect_rotate(src, fb->width << 16, fb->height << 16,
+   state->base.rotation);
+
+   hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
+   BUG_ON(hscale < 0);
+
+   vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
+   BUG_ON(vscale < 0);
+
+   if (crtc_state->base.enable)
+   drm_mode_get_hv_timing(_state->base.mode,
+  , );
+
+   state->base.visible = drm_rect_clip_scaled(src, dst, , hscale, 
vscale);
+
+   crtc_x = dst->x1;
+   crtc_y = dst->y1;
+   crtc_w = drm_rect_width(dst);
+   crtc_h = drm_rect_height(dst);
+
+   if (state->base.visible) {
+   /* check again in case clipping clamped the results */
+   hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
+   if (hscale < 0) {
+   DRM_DEBUG_KMS("Horizontal scaling factor out of 
limits\n");
+   drm_rect_debug_print("src: ", src, true);
+   drm_rect_debug_print("dst: ", dst, false);
+
+   return hscale;
+   }
+
+   vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
+   if (vscale < 0) {
+   DRM_DEBUG_KMS("Vertical scaling factor out of 
limits\n");
+   drm_rect_debug_print("src: ", src, true);
+   drm_rect_debug_print("dst: ", dst, false);
+
+   return vscale;
+   }
+
+   /* Make the source viewport size an exact multiple of the 
scaling factors. */
+   drm_rect_adjust_size(src,
+drm_rect_width(dst) * hscale - 
drm_rect_width(src),
+drm_rect_height(dst) * vscale - 
drm_rect_height(src));
+
+   drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
+   state->base.rotation);
+
+   /* sanity check to make sure the src viewport wasn't enlarged */
+   WARN_ON(src->x1 < (int) state->base.src_x ||
+   src->y1 < (int) state->base.src_y ||
+   src->x2 > (int) state->base.src_x + 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Simplify ilk-ivb underrun suppression

[Ville Syrjälä]

On Fri, May 25, 2018 at 04:55:36PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-05-25 16:43:42)
> > On Fri, May 25, 2018 at 04:20:07PM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjala (2018-05-24 20:04:06)
> > > > From: Ville Syrjälä 
> > > > 
> > > > Let's suppress the underruns around every modeset sequence instead
> > > > of trying to avoid it. Planes are disabled at this point anyway so
> > > > we don't really gain anything from keeping the underrun reporting
> > > > enabled. Also for PCH ports we already suppress all underruns here
> > > > anyway so trying avoid it for the CPU eDP doesn't seem all that
> > > > important.
> > > > 
> > > > Maybe this gets rid of some lingering spurious underruns?
> > > 
> > > I'll bite. Isn't the reason for enabling underrung report for the
> > > modeset itself to detect errors in our sequence?
> > 
> > In theory CPU FIFO underruns shouldn't happen until we have some planes
> > enabled. Otherwise we have no data going through the FIFOs and thus
> > reporting an underrun isn't particularly sane. That doesn't stop gen2
> > from doing it though, but gen3+ seem to follow the more reasonable
> > interpretation of what a FIFO underrun means.
> 
> Makes sense.
>  
> > I suppose PCH FIFO underruns are a bit different as there is data flowing
> > as soon as the CPU pipe starts running, whether or not any planes have
> > been enabled. So those could certainly indicate some kind of programming
> > sequence error. Or it could just be totally expected that we start the
> > PCH side of the pipe first and there's a small bit of time when the CPU
> > pipe isn't yet pushing out pixels, and that's when the PCH side reports
> > the underrun.
> > 
> > > 
> > > How certain are we that these are hw limitations vs sw bugs?
> > 
> > To the best of my knowledge we are reasonably close to the sequence
> > listed in bspec. And while it's at least theoretically possible that
> > there's some change we could make to eliminate the underruns I don't
> > suppose anyone has the time or energy to try out all possible
> > variations.
> > 
> > And as long as the underrun (even if it's real) has vanished by the
> > time we enable the planes I think we are reasonably safe wrt. getting
> > the correct looking output to the user's display.
> 
> Also makes sense. And if glitches during modesetting itself, we hope
> nobody complains ;)
> 
> Reviewed-by: Chris Wilson 

Thanks. Pushed.

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

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

[Patchwork]

== Series Details ==

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

== Summary ==

$ dim checkpatch origin/drm-tip
727d70b71efd drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()
e5018087df50 drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#12: 
concluded that the calls originating from vmw_*_primary_plane_atomic_update()

total: 0 errors, 1 warnings, 0 checks, 15 lines checked
04e4465a752e drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb()
bb80c2fb8b58 drm/vmwgfx: Stop updating plane->fb
93f6a97905a9 drm/vmwgfx: Stop using plane->fb in atomic_enable()
ad29dcb1b25d drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc
cfb513066187 drm/amdgpu/dc: Stop updating plane->fb
ec0551051069 drm/i915: Stop updating plane->fb/crtc
85f059cadaac drm/exynos: Stop updating plane->crtc
4cc88281b0ba drm/msm: Stop updating plane->fb/crtc
9517aeb8ac60 drm/virtio: Stop updating plane->crtc
217192f8f2a3 drm/vc4: Stop updating plane->fb/crtc
7f9d7932efb3 drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

___
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/gen11: Preempt-to-idle support in execlists. (rev4)

[Patchwork]

== Series Details ==

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

== Summary ==

= CI Bug Log - changes from CI_DRM_4244 -> Patchwork_9126 =

== Summary - WARNING ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/40747/revisions/4/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:PASS -> SKIP


== Known issues ==

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

  === IGT changes ===

 Possible fixes 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: FAIL (fdo#102575) -> PASS


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


== Participating hosts (43 -> 39) ==

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4244 -> Patchwork_9126

  CI_DRM_4244: 475c2ec7b8c6e01cce9a360b9839dc0dd0fa9629 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9126: e56337e6a35dc880c13010e17245256799793498 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e56337e6a35d drm/i915/gen11: Preempt-to-idle support in execlists.

== Logs ==

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

[Intel-gfx] [PATCH v3 06/24] drm/i915/icl: Add register definition for DFLEXDPMLE

[Manasi Navare]

DFLEXDPMLE register is required to tell the FIA hardware which
main links of DP are enabled on TCC Connectors. FIA uses this
information to program PHY to Controller signal mapping.
This register is applicable in both TC connector's Alternate mode
as well as DP connector mode.

v2:
* Remove _ICL prefix since the reg is first introduced
in ICL (Paulo)
* s/ICL/icl in commit message (Lucas)

Cc: Jani Nikula 
Cc: Animesh Manna 
Cc: Madhav Chauhan 
Cc: Anusha Srivatsa 
Cc: Paulo Zanoni 
Signed-off-by: Manasi Navare 
Reviewed-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6953419..01573e8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1990,6 +1990,11 @@ enum i915_power_well_id {
   _ICL_PORT_COMP_DW10_A, \
   _ICL_PORT_COMP_DW10_B)
 
+/* ICL PHY DFLEX registers */
+#define PORT_TX_DFLEXDPMLE1_MMIO(0x1638C0)
+#define   DFLEXDPMLE1_DPMLETC_MASK(n)  (0xf << (4 * (n)))
+#define   DFLEXDPMLE1_DPMLETC(n, x)((x) << (4 * (n)))
+
 /* BXT PHY Ref registers */
 #define _PORT_REF_DW3_A0x16218C
 #define _PORT_REF_DW3_BC   0x6C18C
-- 
2.7.4

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c

[Patchwork]

== Series Details ==

Series: drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c
URL   : https://patchwork.freedesktop.org/series/43770/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4238_full -> Patchwork_9121_full =

== Summary - WARNING ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43770/revisions/1/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-bsd2:
  shard-kbl:  PASS -> SKIP

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_await@wide-contexts:
  shard-glk:  PASS -> FAIL (fdo#105900)

igt@gem_workarounds@suspend-resume:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-glk:  PASS -> FAIL (fdo#105703)

igt@kms_flip@2x-modeset-vs-vblank-race:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  PASS -> FAIL (fdo#102887)

igt@kms_flip@plain-flip-fb-recreate:
  shard-glk:  PASS -> FAIL (fdo#100368) +1

igt@kms_flip_tiling@flip-to-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724)

igt@perf@blocking:
  shard-hsw:  PASS -> FAIL (fdo#102252)

igt@pm_rps@waitboost:
  shard-apl:  PASS -> FAIL (fdo#102250)


 Possible fixes 

igt@drv_selftest@live_gtt:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@drv_selftest@live_hangcheck:
  shard-apl:  DMESG-FAIL (fdo#106560) -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
  shard-glk:  FAIL (fdo#105703) -> PASS

igt@kms_flip_tiling@flip-to-x-tiled:
  shard-glk:  FAIL (fdo#104724) -> PASS

igt@kms_setmode@basic:
  shard-apl:  FAIL (fdo#99912) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102250 https://bugs.freedesktop.org/show_bug.cgi?id=102250
  fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4238 -> Patchwork_9121

  CI_DRM_4238: 2771a5e6347eb63e43fdfc432a9f15ffb55ef209 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9121: 89d952d130695412fc71593cdb614f0447e2f7ff @ 
git://anongit.freedesktop.org/gfx-ci/linux

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9121/shards.html
___
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/gen11: Preempt-to-idle support in execlists. (rev4)

[Patchwork]

== Series Details ==

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

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/gen11: Preempt-to-idle support in execlists.
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3666:16: warning: expression 
using sizeof(void)

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

[Intel-gfx] [PATCH v2 13/13] drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

[Ville Syrjala]

From: Ville Syrjälä 

Stop playing around with plane->crtc/fb/old_fb with atomic
drivers. Make life a lot simpler when we don't have to do the
magic old_fb vs. fb dance around plane updates. That way we
can't risk plane->fb getting out of sync with plane->state->fb
and we're less likely to leak any refcounts as well.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
Acked-by: Harry Wentland 
---
 drivers/gpu/drm/drm_atomic.c| 55 -
 drivers/gpu/drm/drm_atomic_helper.c | 15 +-
 drivers/gpu/drm/drm_crtc.c  |  8 --
 drivers/gpu/drm/drm_fb_helper.c |  7 -
 drivers/gpu/drm/drm_framebuffer.c   |  5 
 drivers/gpu/drm/drm_plane.c | 14 ++
 drivers/gpu/drm/drm_plane_helper.c  |  4 ++-
 include/drm/drm_atomic.h|  3 --
 8 files changed, 24 insertions(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 41334d0973a2..ee4b43b9404e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -700,6 +700,11 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
 
WARN_ON(!state->acquire_ctx);
 
+   /* the legacy pointers should never be set */
+   WARN_ON(plane->fb);
+   WARN_ON(plane->old_fb);
+   WARN_ON(plane->crtc);
+
plane_state = drm_atomic_get_existing_plane_state(state, plane);
if (plane_state)
return plane_state;
@@ -2051,45 +2056,6 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
return ret;
 }
 
-/**
- * drm_atomic_clean_old_fb -- Unset old_fb pointers and set plane->fb pointers.
- *
- * @dev: drm device to check.
- * @plane_mask: plane mask for planes that were updated.
- * @ret: return value, can be -EDEADLK for a retry.
- *
- * Before doing an update _plane.old_fb is set to _plane.fb, but before
- * dropping the locks old_fb needs to be set to NULL and plane->fb updated. 
This
- * is a common operation for each atomic update, so this call is split off as a
- * helper.
- */
-void drm_atomic_clean_old_fb(struct drm_device *dev,
-unsigned plane_mask,
-int ret)
-{
-   struct drm_plane *plane;
-
-   /* if succeeded, fixup legacy plane crtc/fb ptrs before dropping
-* locks (ie. while it is still safe to deref plane->state).  We
-* need to do this here because the driver entry points cannot
-* distinguish between legacy and atomic ioctls.
-*/
-   drm_for_each_plane_mask(plane, dev, plane_mask) {
-   if (ret == 0) {
-   struct drm_framebuffer *new_fb = plane->state->fb;
-   if (new_fb)
-   drm_framebuffer_get(new_fb);
-   plane->fb = new_fb;
-   plane->crtc = plane->state->crtc;
-
-   if (plane->old_fb)
-   drm_framebuffer_put(plane->old_fb);
-   }
-   plane->old_fb = NULL;
-   }
-}
-EXPORT_SYMBOL(drm_atomic_clean_old_fb);
-
 /**
  * DOC: explicit fencing properties
  *
@@ -2310,9 +2276,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
unsigned int copied_objs, copied_props;
struct drm_atomic_state *state;
struct drm_modeset_acquire_ctx ctx;
-   struct drm_plane *plane;
struct drm_out_fence_state *fence_state;
-   unsigned plane_mask;
int ret = 0;
unsigned int i, j, num_fences;
 
@@ -2352,7 +2316,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
 
 retry:
-   plane_mask = 0;
copied_objs = 0;
copied_props = 0;
fence_state = NULL;
@@ -2423,12 +2386,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
copied_props++;
}
 
-   if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
-   !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
-   plane = obj_to_plane(obj);
-   plane_mask |= (1 << drm_plane_index(plane));
-   plane->old_fb = plane->fb;
-   }
drm_mode_object_put(obj);
}
 
@@ -2449,8 +2406,6 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
}
 
 out:
-   drm_atomic_clean_old_fb(dev, plane_mask, ret);
-
complete_crtc_signaling(dev, state, fence_state, num_fences, !ret);
 
if (ret == -EDEADLK) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 130da5195f3b..232fa11a5e31 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2914,7 +2914,6 @@ static int __drm_atomic_helper_disable_all(struct 
drm_device 

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

[Patchwork]

== Series Details ==

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

== Summary ==

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

-:190: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#190: FILE: drivers/gpu/drm/i915/intel_lrc.c:1056:
+   if ((status & GEN8_CTX_STATUS_IDLE_ACTIVE) &&
+(status & GEN11_CTX_STATUS_PREEMPT_IDLE)) {

-:191: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#191: FILE: drivers/gpu/drm/i915/intel_lrc.c:1057:
+(status & GEN11_CTX_STATUS_PREEMPT_IDLE)) {
+

-:194: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#194: FILE: drivers/gpu/drm/i915/intel_lrc.c:1060:
+   GEM_BUG_ON(execlists_is_active(execlists,
+ EXECLISTS_ACTIVE_HWACK));

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

total: 0 errors, 0 warnings, 5 checks, 184 lines checked

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

[Intel-gfx] [PATCH v2 12/13] drm/vc4: Stop updating plane->fb/crtc

[Ville Syrjala]

From: Ville Syrjälä 

We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.

Cc: Eric Anholt 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index c8650bbcbcb3..dcadf793ee80 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -862,7 +862,6 @@ static int vc4_async_page_flip(struct drm_crtc *crtc,
 * is released.
 */
drm_atomic_set_fb_for_plane(plane->state, fb);
-   plane->fb = fb;
 
vc4_queue_seqno_cb(dev, _state->cb, bo->seqno,
   vc4_async_page_flip_complete);
@@ -1057,7 +1056,6 @@ static int vc4_crtc_bind(struct device *dev, struct 
device *master, void *data)
drm_crtc_init_with_planes(drm, crtc, primary_plane, NULL,
  _crtc_funcs, NULL);
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
-   primary_plane->crtc = crtc;
vc4_crtc->channel = vc4_crtc->data->hvs_channel;
drm_mode_crtc_set_gamma_size(crtc, ARRAY_SIZE(vc4_crtc->lut_r));
drm_crtc_enable_color_mgmt(crtc, 0, false, crtc->gamma_size);
@@ -1093,7 +1091,6 @@ static int vc4_crtc_bind(struct device *dev, struct 
device *master, void *data)
cursor_plane = vc4_plane_init(drm, DRM_PLANE_TYPE_CURSOR);
if (!IS_ERR(cursor_plane)) {
cursor_plane->possible_crtcs = 1 << drm_crtc_index(crtc);
-   cursor_plane->crtc = crtc;
crtc->cursor = cursor_plane;
}
 
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 06/13] drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc

[Ville Syrjala]

From: Ville Syrjälä 

plane->fb/old_fb/crtc should no longer be used by atomic
drivers. Stop messing about with them.

Cc: Deepak Rawat 
Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: VMware Graphics 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 24 
 1 file changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index 54e300365a5c..fcca0487dab6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -439,8 +439,6 @@ static int vmw_fb_compute_depth(struct fb_var_screeninfo 
*var,
 static int vmwgfx_set_config_internal(struct drm_mode_set *set)
 {
struct drm_crtc *crtc = set->crtc;
-   struct drm_framebuffer *fb;
-   struct drm_crtc *tmp;
struct drm_device *dev = set->crtc->dev;
struct drm_modeset_acquire_ctx ctx;
int ret;
@@ -448,29 +446,7 @@ static int vmwgfx_set_config_internal(struct drm_mode_set 
*set)
drm_modeset_acquire_init(, 0);
 
 restart:
-   /*
-* NOTE: ->set_config can also disable other crtcs (if we steal all
-* connectors from it), hence we need to refcount the fbs across all
-* crtcs. Atomic modeset will have saner semantics ...
-*/
-   drm_for_each_crtc(tmp, dev)
-   tmp->primary->old_fb = tmp->primary->fb;
-
-   fb = set->fb;
-
ret = crtc->funcs->set_config(set, );
-   if (ret == 0) {
-   crtc->primary->crtc = crtc;
-   crtc->primary->fb = fb;
-   }
-
-   drm_for_each_crtc(tmp, dev) {
-   if (tmp->primary->fb)
-   drm_framebuffer_get(tmp->primary->fb);
-   if (tmp->primary->old_fb)
-   drm_framebuffer_put(tmp->primary->old_fb);
-   tmp->primary->old_fb = NULL;
-   }
 
if (ret == -EDEADLK) {
drm_modeset_backoff();
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 07/13] drm/amdgpu/dc: Stop updating plane->fb

[Ville Syrjala]

From: Ville Syrjälä 

We want to get rid of plane->fb on atomic drivers. Stop setting it.

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "David (ChunMing) Zhou" 
Cc: Harry Wentland 
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Harry Wentland 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1ce10bc2d37b..82bac02fffd7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3927,8 +3927,6 @@ static void amdgpu_dm_do_flip(struct drm_crtc *crtc,
 
/* Flip */
spin_lock_irqsave(>dev->event_lock, flags);
-   /* update crtc fb */
-   crtc->primary->fb = fb;
 
WARN_ON(acrtc->pflip_status != AMDGPU_FLIP_NONE);
WARN_ON(!acrtc_state->stream);
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 09/13] drm/exynos: Stop updating plane->crtc

[Ville Syrjala]

From: Ville Syrjälä 

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

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Daniel Vetter 
Acked-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index d2a90dae5c71..1b1af359c303 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -263,8 +263,6 @@ static void exynos_plane_atomic_update(struct drm_plane 
*plane,
if (!state->crtc)
return;
 
-   plane->crtc = state->crtc;
-
if (exynos_crtc->ops->update_plane)
exynos_crtc->ops->update_plane(exynos_crtc, exynos_plane);
 }
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 11/13] drm/virtio: Stop updating plane->crtc

[Ville Syrjala]

From: Ville Syrjälä 

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

v2: s/fb/crtc/ in the commit message (Gerd)

Cc: David Airlie 
Cc: Gerd Hoffmann 
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index d6dd769a7ad3..ff9933e79416 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -282,8 +282,6 @@ static int vgdev_output_init(struct virtio_gpu_device 
*vgdev, int index)
drm_crtc_init_with_planes(dev, crtc, primary, cursor,
  _gpu_crtc_funcs, NULL);
drm_crtc_helper_add(crtc, _gpu_crtc_helper_funcs);
-   primary->crtc = crtc;
-   cursor->crtc = crtc;
 
drm_connector_init(dev, connector, _gpu_connector_funcs,
   DRM_MODE_CONNECTOR_VIRTUAL);
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 10/13] drm/msm: Stop updating plane->fb/crtc

[Ville Syrjala]

From: Ville Syrjälä 

We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.

v2: Catch a few more cases

Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst  #v1
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c  | 1 -
 drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 2 --
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c  | 1 -
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 2 --
 4 files changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
index 20f9e5de5f19..457c29dba4a1 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
@@ -665,7 +665,6 @@ struct drm_crtc *mdp4_crtc_init(struct drm_device *dev,
drm_crtc_init_with_planes(dev, crtc, plane, NULL, _crtc_funcs,
  NULL);
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
-   plane->crtc = crtc;
 
return crtc;
 }
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
index 7a1ad3af08e3..782b1e27f040 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
@@ -182,8 +182,6 @@ static void mdp4_plane_set_scanout(struct drm_plane *plane,
msm_framebuffer_iova(fb, kms->aspace, 2));
mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRCP3_BASE(pipe),
msm_framebuffer_iova(fb, kms->aspace, 3));
-
-   plane->fb = fb;
 }
 
 static void mdp4_write_csc_config(struct mdp4_kms *mdp4_kms,
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 76b96081916f..efedcac6e641 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -1198,7 +1198,6 @@ struct drm_crtc *mdp5_crtc_init(struct drm_device *dev,
"unref cursor", unref_cursor_worker);
 
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
-   plane->crtc = crtc;
 
return crtc;
 }
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index f2361f79fdce..6826aa10f3ac 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -1043,8 +1043,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
 src_img_w, src_img_h,
 src_x + src_w, src_y, src_w, src_h);
 
-   plane->fb = fb;
-
return ret;
 }
 
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 05/13] drm/vmwgfx: Stop using plane->fb in atomic_enable()

[Ville Syrjala]

From: Ville Syrjälä 

Instead of looking at the (soon to be deprecated) plane->fb we'll
examing plane->state->fb instead. We can do this because
vmw_du_crtc_atomic_check() prevents us from enabling a crtc
without the primary plane also being enabled.

Due to that same reason, I'm actually not sure what the checks here are
for NULL fb. If we can't enable the crtc without an enabled plane
we should always have an fb. But I'll leave that for someone else
to figure out.

Cc: Deepak Rawat 
Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: VMware Graphics 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Deepak Rawat 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 90445bc590cb..152e96cb1c01 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -414,6 +414,7 @@ static void vmw_stdu_crtc_helper_prepare(struct drm_crtc 
*crtc)
 static void vmw_stdu_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
 {
+   struct drm_plane_state *plane_state = crtc->primary->state;
struct vmw_private *dev_priv;
struct vmw_screen_target_display_unit *stdu;
struct vmw_framebuffer *vfb;
@@ -422,7 +423,7 @@ static void vmw_stdu_crtc_atomic_enable(struct drm_crtc 
*crtc,
 
stdu = vmw_crtc_to_stdu(crtc);
dev_priv = vmw_priv(crtc->dev);
-   fb   = crtc->primary->fb;
+   fb   = plane_state->fb;
 
vfb = (fb) ? vmw_framebuffer_to_vfb(fb) : NULL;
 
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 08/13] drm/i915: Stop updating plane->fb/crtc

[Ville Syrjala]

From: Ville Syrjälä 

We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.

v2: Fix up the comment in intel_crtc_active() and
nuke the rest of the stale comments (Daniel)

Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst  #v1
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 12 
 drivers/gpu/drm/i915/intel_display.c  |  7 +++
 2 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 6d068786eb41..e8bf4cc499e1 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -120,12 +120,6 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
_state->base.adjusted_mode;
int ret;
 
-   /*
-* Both crtc and plane->crtc could be NULL if we're updating a
-* property while the plane is disabled.  We don't actually have
-* anything driver-specific we need to test in that case, so
-* just return success.
-*/
if (!intel_state->base.crtc && !old_plane_state->base.crtc)
return 0;
 
@@ -209,12 +203,6 @@ static int intel_plane_atomic_check(struct drm_plane 
*plane,
const struct drm_crtc_state *old_crtc_state;
struct drm_crtc_state *new_crtc_state;
 
-   /*
-* Both crtc and plane->crtc could be NULL if we're updating a
-* property while the plane is disabled.  We don't actually have
-* anything driver-specific we need to test in that case, so
-* just return success.
-*/
if (!crtc)
return 0;
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 90a6ff00c79d..8e7e87e4e11f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1022,7 +1022,7 @@ bool intel_crtc_active(struct intel_crtc *crtc)
 * We can ditch the adjusted_mode.crtc_clock check as soon
 * as Haswell has gained clock readout/fastboot support.
 *
-* We can ditch the crtc->primary->fb check as soon as we can
+* We can ditch the crtc->primary->state->fb check as soon as we can
 * properly reconstruct framebuffers.
 *
 * FIXME: The intel_crtc->active here should be switched to
@@ -2879,9 +2879,8 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
if (i915_gem_object_is_tiled(obj))
dev_priv->preserve_bios_swizzle = true;
 
-   drm_framebuffer_get(fb);
-   primary->fb = primary->state->fb = fb;
-   primary->crtc = primary->state->crtc = _crtc->base;
+   plane_state->fb = fb;
+   plane_state->crtc = _crtc->base;
 
intel_set_plane_visible(to_intel_crtc_state(crtc_state),
to_intel_plane_state(plane_state),
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 03/13] drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb()

[Ville Syrjala]

From: Ville Syrjälä 

The only caller of vmw_kms_update_implicit_fb() is the page_flip
hook which itself gets called with the plane mutex already held.
Hence we can look at plane->state safely. Toss in a lockdep assert
to make the situation more clear.

Cc: Deepak Rawat 
Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: VMware Graphics 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Deepak Rawat 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 5417eb1b486e..04d51bb639b8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2813,14 +2813,17 @@ void vmw_kms_update_implicit_fb(struct vmw_private 
*dev_priv,
struct drm_crtc *crtc)
 {
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
+   struct drm_plane *plane = crtc->primary;
struct vmw_framebuffer *vfb;
 
+   lockdep_assert_held(>mutex);
+
mutex_lock(_priv->global_kms_state_mutex);
 
if (!du->is_implicit)
goto out_unlock;
 
-   vfb = vmw_framebuffer_to_vfb(crtc->primary->fb);
+   vfb = vmw_framebuffer_to_vfb(plane->state->fb);
WARN_ON_ONCE(dev_priv->num_implicit != 1 &&
 dev_priv->implicit_fb != vfb);
 
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 04/13] drm/vmwgfx: Stop updating plane->fb

[Ville Syrjala]

From: Ville Syrjälä 

We want to get rid of plane->fb on atomic drivers. Stop setting it.

Cc: Deepak Rawat 
Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: VMware Graphics 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Deepak Rawat 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 --
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 3d667e903beb..9798640cbfcd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -527,8 +527,6 @@ vmw_sou_primary_plane_atomic_update(struct drm_plane *plane,
 */
if (ret != 0)
DRM_ERROR("Failed to update screen.\n");
-
-   crtc->primary->fb = plane->state->fb;
} else {
/*
 * When disabling a plane, CRTC and FB should always be NULL
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 67331f01ef32..90445bc590cb 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1285,8 +1285,6 @@ vmw_stdu_primary_plane_atomic_update(struct drm_plane 
*plane,
 1, 1, NULL, crtc);
if (ret)
DRM_ERROR("Failed to update STDU.\n");
-
-   crtc->primary->fb = plane->state->fb;
} else {
crtc = old_state->crtc;
stdu = vmw_crtc_to_stdu(crtc);
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 01/13] drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()

[Ville Syrjala]

From: Ville Syrjälä 

Instead of looking at plane->fb let's look at the proper new
plane state.

Not that the code makes a ton of sense. It's only going through the
crtcs in the atomic state, so assuming not all of them are included
we're not even calculating the total bandwidth here. Also we're
not considering whether each crtc is actually enabled or not.

Cc: Deepak Rawat 
Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: VMware Graphics 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 01f2dc9e6f52..2e4c38bb846d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1536,9 +1536,13 @@ vmw_kms_atomic_check_modeset(struct drm_device *dev,
unsigned long requested_bb_mem = 0;
 
if (dev_priv->active_display_unit == vmw_du_screen_target) {
-   if (crtc->primary->fb) {
-   int cpp = crtc->primary->fb->pitches[0] /
- crtc->primary->fb->width;
+   struct drm_plane *plane = crtc->primary;
+   struct drm_plane_state *plane_state;
+
+   plane_state = drm_atomic_get_new_plane_state(state, 
plane);
+
+   if (plane_state && plane_state->fb) {
+   int cpp = plane_state->fb->format->cpp[0];
 
requested_bb_mem += crtc->mode.hdisplay * cpp *
crtc->mode.vdisplay;
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 00/13] drm: Eliminate plane->fb/crtc usage for atomic drivers

[Ville Syrjala]

From: Ville Syrjälä 

Here are again the last (?) bits of eliminating the plane->fb/crtc
usage for atomic drivers. I've pushed everything else (thanks to
everyone who reviewed them). 

Deepak said he'd tested the vmwgfx stuff, so I think it should be
safe to land. Just missing a bit of review...

Cc: Alex Deucher 
Cc: amd-...@lists.freedesktop.org
Cc: "Christian König" 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: "David (ChunMing) Zhou" 
Cc: Deepak Rawat 
Cc: Eric Anholt 
Cc: freedr...@lists.freedesktop.org
Cc: Gerd Hoffmann 
Cc: Harry Wentland 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Kyungmin Park 
Cc: linux-arm-...@vger.kernel.org
Cc: Rob Clark 
Cc: Seung-Woo Kim 
Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Cc: virtualizat...@lists.linux-foundation.org
Cc: VMware Graphics 

Ville Syrjälä (13):
  drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()
  drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()
  drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb()
  drm/vmwgfx: Stop updating plane->fb
  drm/vmwgfx: Stop using plane->fb in atomic_enable()
  drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc
  drm/amdgpu/dc: Stop updating plane->fb
  drm/i915: Stop updating plane->fb/crtc
  drm/exynos: Stop updating plane->crtc
  drm/msm: Stop updating plane->fb/crtc
  drm/virtio: Stop updating plane->crtc
  drm/vc4: Stop updating plane->fb/crtc
  drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 -
 drivers/gpu/drm/drm_atomic.c  | 55 +++
 drivers/gpu/drm/drm_atomic_helper.c   | 15 +--
 drivers/gpu/drm/drm_crtc.c|  8 +++-
 drivers/gpu/drm/drm_fb_helper.c   |  7 ---
 drivers/gpu/drm/drm_framebuffer.c |  5 ---
 drivers/gpu/drm/drm_plane.c   | 14 +++---
 drivers/gpu/drm/drm_plane_helper.c|  4 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  2 -
 drivers/gpu/drm/i915/intel_atomic_plane.c | 12 -
 drivers/gpu/drm/i915/intel_display.c  |  7 ++-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c |  1 -
 drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c|  2 -
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  1 -
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c|  2 -
 drivers/gpu/drm/vc4/vc4_crtc.c|  3 --
 drivers/gpu/drm/virtio/virtgpu_display.c  |  2 -
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 24 --
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   | 24 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c  |  2 -
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c  |  5 +--
 include/drm/drm_atomic.h  |  3 --
 22 files changed, 46 insertions(+), 154 deletions(-)

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

[Intel-gfx] [PATCH v2 02/13] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

[Ville Syrjala]

From: Ville Syrjälä 

Instead of plane->fb (which we're going to deprecate for atomic drivers)
we need to look at plane->state->fb. The maze of code leading to
vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
concluded that the calls originating from vmw_*_primary_plane_atomic_update()
all pass in the crtc which means we'll never end up in this branch
of the function. All other callers use drm_modeset_lock_all() somewhere
higher up, which means accessing plane->state is safe. We'll toss in
a lockdep assert to catch wrongdoers.

v2: Drop the comment and make the code do what it did before (Thomas)

Cc: Deepak Rawat 
Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: VMware Graphics 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 2e4c38bb846d..5417eb1b486e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2326,9 +2326,12 @@ int vmw_kms_helper_dirty(struct vmw_private *dev_priv,
} else {
list_for_each_entry(crtc, _priv->dev->mode_config.crtc_list,
head) {
-   if (crtc->primary->fb != >base)
-   continue;
-   units[num_units++] = vmw_crtc_to_du(crtc);
+   struct drm_plane *plane = crtc->primary;
+
+   lockdep_assert_held(>mutex);
+
+   if (plane->state->fb == >base)
+   units[num_units++] = vmw_crtc_to_du(crtc);
}
}
 
-- 
2.16.1

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

[Intel-gfx] [PATCH v2 06/24] drm/i915/ICL: Add register definition for DFLEXDPMLE

[Manasi Navare]

DFLEXDPMLE register is required to tell the FIA hardware which
main links of DP are enabled on TCC Connectors. FIA uses this
information to program PHY to Controller signal mapping.
This register is applicable in both TC connector's Alternate mode
as well as DP connector mode.

v2:
* Remove _ICL prefix since the reg is first introduced
in ICL (Paulo)
* s/ICL/icl in commit message (Lucas)

Cc: Jani Nikula 
Cc: Animesh Manna 
Cc: Madhav Chauhan 
Cc: Anusha Srivatsa 
Cc: Paulo Zanoni 
Signed-off-by: Manasi Navare 
Reviewed-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6953419..01573e8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1990,6 +1990,11 @@ enum i915_power_well_id {
   _ICL_PORT_COMP_DW10_A, \
   _ICL_PORT_COMP_DW10_B)
 
+/* ICL PHY DFLEX registers */
+#define PORT_TX_DFLEXDPMLE1_MMIO(0x1638C0)
+#define   DFLEXDPMLE1_DPMLETC_MASK(n)  (0xf << (4 * (n)))
+#define   DFLEXDPMLE1_DPMLETC(n, x)((x) << (4 * (n)))
+
 /* BXT PHY Ref registers */
 #define _PORT_REF_DW3_A0x16218C
 #define _PORT_REF_DW3_BC   0x6C18C
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 27/24] drm/i915/dp: Add support for HBR3 and TPS4 during link training

[James Ausmus]

On Thu, May 24, 2018 at 04:42:38PM -0700, Paulo Zanoni wrote:
> From: Manasi Navare 
> 
> DP spec 1.4 supports training pattern set 4 (TPS4) for HBR3 link
> rate. This will be used in link training's channel equalization
> phase if supported by both source and sink.
> This patch adds the helpers to check if HBR3 is supported and uses
> TPS4 in training pattern selection during link training.
> 
> Cc: James Ausmus 
> Cc: Rodrigo Vivi 
> Cc: Jani Nikula 
> Signed-off-by: Manasi Navare 

Reviewed-by: James Ausmus 

> ---
>  drivers/gpu/drm/i915/i915_reg.h   |  1 +
>  drivers/gpu/drm/i915/intel_dp.c   | 17 +---
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 39 
> +++
>  drivers/gpu/drm/i915/intel_drv.h  |  1 +
>  4 files changed, 44 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e48b717769b2..ae7070c0806d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8791,6 +8791,7 @@ enum skl_power_gate {
>  #define  DP_TP_CTL_LINK_TRAIN_PAT1   (0<<8)
>  #define  DP_TP_CTL_LINK_TRAIN_PAT2   (1<<8)
>  #define  DP_TP_CTL_LINK_TRAIN_PAT3   (4<<8)
> +#define  DP_TP_CTL_LINK_TRAIN_PAT4   (5<<8)
>  #define  DP_TP_CTL_LINK_TRAIN_IDLE   (2<<8)
>  #define  DP_TP_CTL_LINK_TRAIN_NORMAL (3<<8)
>  #define  DP_TP_CTL_SCRAMBLE_DISABLE  (1<<7)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3ee8e74cf2b8..bcc3f330b301 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1721,6 +1721,13 @@ bool intel_dp_source_supports_hbr2(struct intel_dp 
> *intel_dp)
>   return max_rate >= 54;
>  }
>  
> +bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp)
> +{
> + int max_rate = intel_dp->source_rates[intel_dp->num_source_rates - 1];
> +
> + return max_rate >= 81;
> +}
> +
>  static void
>  intel_dp_set_clock(struct intel_encoder *encoder,
>  struct intel_crtc_state *pipe_config)
> @@ -3046,10 +3053,11 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
>   struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   enum port port = intel_dig_port->base.port;
> + uint8_t train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
>  
> - if (dp_train_pat & DP_TRAINING_PATTERN_MASK)
> + if (dp_train_pat & train_pat_mask)
>   DRM_DEBUG_KMS("Using DP training pattern TPS%d\n",
> -   dp_train_pat & DP_TRAINING_PATTERN_MASK);
> +   dp_train_pat & train_pat_mask);
>  
>   if (HAS_DDI(dev_priv)) {
>   uint32_t temp = I915_READ(DP_TP_CTL(port));
> @@ -3060,7 +3068,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
>   temp &= ~DP_TP_CTL_SCRAMBLE_DISABLE;
>  
>   temp &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> - switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
> + switch (dp_train_pat & train_pat_mask) {
>   case DP_TRAINING_PATTERN_DISABLE:
>   temp |= DP_TP_CTL_LINK_TRAIN_NORMAL;
>  
> @@ -3074,6 +3082,9 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
>   case DP_TRAINING_PATTERN_3:
>   temp |= DP_TP_CTL_LINK_TRAIN_PAT3;
>   break;
> + case DP_TRAINING_PATTERN_4:
> + temp |= DP_TP_CTL_LINK_TRAIN_PAT4;
> + break;
>   }
>   I915_WRITE(DP_TP_CTL(port), temp);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 3fcaa98b9055..4da6e33c7fa1 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -219,14 +219,30 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
> *intel_dp)
>  }
>  
>  /*
> - * Pick training pattern for channel equalization. Training Pattern 3 for 
> HBR2
> + * Pick training pattern for channel equalization. Training pattern 4 for 
> HBR3
> + * or for 1.4 devices that support it, training Pattern 3 for HBR2
>   * or 1.2 devices that support it, Training Pattern 2 otherwise.
>   */
>  static u32 intel_dp_training_pattern(struct intel_dp *intel_dp)
>  {
> - u32 training_pattern = DP_TRAINING_PATTERN_2;
> - bool source_tps3, sink_tps3;
> + bool source_tps3, sink_tps3, source_tps4, sink_tps4;
>  
> + /*
> +  * Intel platforms that support HBR3 also support TPS4. It is mandatory
> +  * for all downstream devices that support HBR3. There are no known eDP
> +  

Re: [Intel-gfx] [PATCH 26/24] drm/i915/icl: Add allowed DP rates for Icelake

[James Ausmus]

On Thu, May 24, 2018 at 04:42:37PM -0700, Paulo Zanoni wrote:
> From: Manasi Navare 
> 
> For ICL, on Combo PHY the allowed max rates are:
>  - HBR3 8.1 eDP (DDIA)
>  - HBR2 5.4 DisplayPort (DDIB)
> and for MG PHY/TC DDI Ports allowed DP rates are:
>  - HBR3 8.1 DisplayPort (DP alternate mode, DP over TBT,
>  - DP on legacy connector - DDIC/D/E/F)
> 
> Cc: Rodrigo Vivi 
> Cc: Jani Nikula 
> Cc: James Ausmus 
> Signed-off-by: Manasi Navare 
> Signed-off-by: James Ausmus 

Reviewed-by: James Ausmus 

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5109023abe28..3ee8e74cf2b8 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -419,6 +419,20 @@ static int cnl_max_source_rate(struct intel_dp *intel_dp)
>   return 81;
>  }
>  
> +static int icl_max_source_rate(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + enum port port = dig_port->base.port;
> +
> + /* On Combo PHY port A max speed is HBR3 for all Vccio voltages
> +  * and on Combo PHY Port B the maximum supported is HBR2.
> +  */
> + if (port == PORT_B)
> + return 54;
> +
> + return 81;
> +}
> +
>  static void
>  intel_dp_set_source_rates(struct intel_dp *intel_dp)
>  {
> @@ -448,10 +462,13 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
>   /* This should only be done once */
>   WARN_ON(intel_dp->source_rates || intel_dp->num_source_rates);
>  
> - if (IS_CANNONLAKE(dev_priv)) {
> + if (INTEL_GEN(dev_priv) >= 10) {
>   source_rates = cnl_rates;
>   size = ARRAY_SIZE(cnl_rates);
> - max_rate = cnl_max_source_rate(intel_dp);
> + if (IS_ICELAKE(dev_priv))
> + max_rate = icl_max_source_rate(intel_dp);
> + else
> + max_rate = cnl_max_source_rate(intel_dp);
>   } else if (IS_GEN9_LP(dev_priv)) {
>   source_rates = bxt_rates;
>   size = ARRAY_SIZE(bxt_rates);
> -- 
> 2.14.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Tomasz Lis]

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

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

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

v2: Added needs_preempt_context() change so that it is not created when
preempt-to-idle is supported. (Chris)
Updated setting HWACK flag so that it is cleared after
preempt-to-dle. (Chris, Daniele)
Updated to use I915_ENGINE_HAS_PREEMPTION flag. (Chris)

v3: Fixed needs_preempt_context() change. (Chris)
Merged preemption trigger functions to one. (Chris)
Fixed conyext state tonot assume COMPLETED_MASK after preemption,
since idle-to-idle case will not have it set.

v4: Simplified needs_preempt_context() change. (Daniele)
Removed clearing HWACK flag in idle-to-idle preempt. (Daniele)

Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Winiarski 
Cc: Mika Kuoppala 
Bspec: 18922
Signed-off-by: Tomasz Lis 
---
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_gem_context.c  |   3 +-
 drivers/gpu/drm/i915/i915_pci.c  |   3 +-
 drivers/gpu/drm/i915/intel_device_info.h |   1 +
 drivers/gpu/drm/i915/intel_lrc.c | 113 +--
 drivers/gpu/drm/i915/intel_lrc.h |   1 +
 6 files changed, 86 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 487922f..35eddf7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2534,6 +2534,8 @@ intel_info(const struct drm_i915_private *dev_priv)
((dev_priv)->info.has_logical_ring_elsq)
 #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
((dev_priv)->info.has_logical_ring_preemption)
+#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
+   ((dev_priv)->info.has_hw_preempt_to_idle)
 
 #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 45393f6..341a5ff 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -455,7 +455,8 @@ destroy_kernel_context(struct i915_gem_context **ctxp)
 
 static bool needs_preempt_context(struct drm_i915_private *i915)
 {
-   return HAS_LOGICAL_RING_PREEMPTION(i915);
+   return HAS_LOGICAL_RING_PREEMPTION(i915) &&
+  !HAS_HW_PREEMPT_TO_IDLE(i915);
 }
 
 int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 97a91e6a..ee09926 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -593,7 +593,8 @@ static const struct intel_device_info intel_cannonlake_info 
= {
GEN(11), \
.ddb_size = 2048, \
.has_csr = 0, \
-   .has_logical_ring_elsq = 1
+   .has_logical_ring_elsq = 1, \
+   .has_hw_preempt_to_idle = 1
 
 static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 933e316..4eb97b5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -98,6 +98,7 @@ enum intel_platform {
func(has_logical_ring_contexts); \
func(has_logical_ring_elsq); \
func(has_logical_ring_preemption); \
+   func(has_hw_preempt_to_idle); \
func(has_overlay); \
func(has_pooled_eu); \
func(has_psr); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8a6058b..f95cb37 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -154,6 +154,7 @@
 #define GEN8_CTX_STATUS_ACTIVE_IDLE(1 << 3)
 #define GEN8_CTX_STATUS_COMPLETE   (1 << 4)
 #define GEN8_CTX_STATUS_LITE_RESTORE   (1 << 15)
+#define GEN11_CTX_STATUS_PREEMPT_IDLE  (1 << 29)
 
 #define GEN8_CTX_STATUS_COMPLETED_MASK \
 (GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
@@ -522,31 +523,46 @@ static void port_assign(struct execlist_port *port, 
struct i915_request *rq)
 static void inject_preempt_context(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists *execlists = >execlists;
-   struct intel_context *ce =
-   to_intel_context(engine->i915->preempt_context, engine);
-   unsigned int n;
-
-   

Re: [Intel-gfx] [PATCH] drm/i915 : clip yuv primary planes to hw constraints

[Ville Syrjälä]

On Fri, May 25, 2018 at 11:00:23AM -0700, Fritz Koenig wrote:
> YUV planes need to be multiples of 2 to scan out. This was
> handled correctly for planes other than the primary in the
> intel_check_sprite_plane, where the code fixes up the plane
> and makes it compliant. Move this code into a location that
> allows the primary check to access it as well.
> 
> Signed-off-by: Fritz Koenig 
> ---
> 
> Hi,
> 
> I think this is a better implementation where instead of rejecting
> yuv planes that are not correctly aligned, they are fixed up.  This
> is done by reusing the sprite check code that was already doing that.
> 
>  drivers/gpu/drm/i915/intel_display.c | 170 +++
>  drivers/gpu/drm/i915/intel_drv.h |   2 +
>  drivers/gpu/drm/i915/intel_sprite.c  | 154 +---
>  3 files changed, 175 insertions(+), 151 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 56004ffbd8bb..1328fb90367f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12854,6 +12854,170 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct 
> intel_crtc_state *crtc_state
>   return max_scale;
>  }
>  
> +int
> +intel_clip_src_rect(struct intel_plane *plane,
> + struct intel_crtc_state *crtc_state,
> + struct intel_plane_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_framebuffer *fb = state->base.fb;
> + int crtc_x, crtc_y;
> + unsigned int crtc_w, crtc_h;
> + uint32_t src_x, src_y, src_w, src_h;
> + struct drm_rect *src = >base.src;
> + struct drm_rect *dst = >base.dst;
> + struct drm_rect clip = {};
> + int hscale, vscale;
> + int max_scale, min_scale;
> + bool can_scale;
> +
> + *src = drm_plane_state_src(>base);
> + *dst = drm_plane_state_dest(>base);
> +
> + /* setup can_scale, min_scale, max_scale */
> + if (INTEL_GEN(dev_priv) >= 9) {
> + /* use scaler when colorkey is not required */
> + if (!state->ckey.flags) {
> + can_scale = 1;
> + min_scale = 1;
> + max_scale = skl_max_scale(crtc, crtc_state);
> + } else {
> + can_scale = 0;
> + min_scale = DRM_PLANE_HELPER_NO_SCALING;
> + max_scale = DRM_PLANE_HELPER_NO_SCALING;
> + }
> + } else {
> + can_scale = plane->can_scale;
> + max_scale = plane->max_downscale << 16;
> + min_scale = plane->can_scale ? 1 : (1 << 16);
> + }
> +
> + /*
> +  * FIXME the following code does a bunch of fuzzy adjustments to the
> +  * coordinates and sizes. We probably need some way to decide whether
> +  * more strict checking should be done instead.
> +  */
> + drm_rect_rotate(src, fb->width << 16, fb->height << 16,
> + state->base.rotation);
> +
> + hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
> + BUG_ON(hscale < 0);
> +
> + vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
> + BUG_ON(vscale < 0);

Your baseline is already outdated.

-- 
Ville Syrjälä
Intel
___
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 : clip yuv primary planes to hw constraints

[Patchwork]

== Series Details ==

Series: drm/i915 : clip yuv primary planes to hw constraints
URL   : https://patchwork.freedesktop.org/series/43796/
State : failure

== Summary ==

Applying: drm/i915 : clip yuv primary planes to hw constraints
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_display.c
M   drivers/gpu/drm/i915/intel_drv.h
M   drivers/gpu/drm/i915/intel_sprite.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_sprite.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_sprite.c
Auto-merging drivers/gpu/drm/i915/intel_drv.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_drv.h
Auto-merging drivers/gpu/drm/i915/intel_display.c
Patch failed at 0001 drm/i915 : clip yuv primary planes to hw constraints
The copy of the patch that failed is found in: .git/rebase-apply/patch
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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Measure sampler intervals

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Measure sampler intervals
URL   : https://patchwork.freedesktop.org/series/43795/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4243 -> Patchwork_9124 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43795/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)


 Possible fixes 

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-skl-6770hq:  FAIL (fdo#103928, fdo#100368) -> PASS

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
  fi-skl-6770hq:  FAIL (fdo#103481) -> PASS


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


== Participating hosts (44 -> 39) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4243 -> Patchwork_9124

  CI_DRM_4243: 7af0b742eec473a202f327e5148757f988b65305 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9124: 1620ac1abdcf8e4c1102eb46b9719b4484db140a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1620ac1abdcf drm/i915/pmu: Measure sampler intervals

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915 : clip yuv primary planes to hw constraints

[Fritz Koenig]

YUV planes need to be multiples of 2 to scan out. This was
handled correctly for planes other than the primary in the
intel_check_sprite_plane, where the code fixes up the plane
and makes it compliant. Move this code into a location that
allows the primary check to access it as well.

Signed-off-by: Fritz Koenig 
---

Hi,

I think this is a better implementation where instead of rejecting
yuv planes that are not correctly aligned, they are fixed up.  This
is done by reusing the sprite check code that was already doing that.

 drivers/gpu/drm/i915/intel_display.c | 170 +++
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_sprite.c  | 154 +---
 3 files changed, 175 insertions(+), 151 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 56004ffbd8bb..1328fb90367f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12854,6 +12854,170 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct 
intel_crtc_state *crtc_state
return max_scale;
 }
 
+int
+intel_clip_src_rect(struct intel_plane *plane,
+   struct intel_crtc_state *crtc_state,
+   struct intel_plane_state *state)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+   struct drm_framebuffer *fb = state->base.fb;
+   int crtc_x, crtc_y;
+   unsigned int crtc_w, crtc_h;
+   uint32_t src_x, src_y, src_w, src_h;
+   struct drm_rect *src = >base.src;
+   struct drm_rect *dst = >base.dst;
+   struct drm_rect clip = {};
+   int hscale, vscale;
+   int max_scale, min_scale;
+   bool can_scale;
+
+   *src = drm_plane_state_src(>base);
+   *dst = drm_plane_state_dest(>base);
+
+   /* setup can_scale, min_scale, max_scale */
+   if (INTEL_GEN(dev_priv) >= 9) {
+   /* use scaler when colorkey is not required */
+   if (!state->ckey.flags) {
+   can_scale = 1;
+   min_scale = 1;
+   max_scale = skl_max_scale(crtc, crtc_state);
+   } else {
+   can_scale = 0;
+   min_scale = DRM_PLANE_HELPER_NO_SCALING;
+   max_scale = DRM_PLANE_HELPER_NO_SCALING;
+   }
+   } else {
+   can_scale = plane->can_scale;
+   max_scale = plane->max_downscale << 16;
+   min_scale = plane->can_scale ? 1 : (1 << 16);
+   }
+
+   /*
+* FIXME the following code does a bunch of fuzzy adjustments to the
+* coordinates and sizes. We probably need some way to decide whether
+* more strict checking should be done instead.
+*/
+   drm_rect_rotate(src, fb->width << 16, fb->height << 16,
+   state->base.rotation);
+
+   hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
+   BUG_ON(hscale < 0);
+
+   vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
+   BUG_ON(vscale < 0);
+
+   if (crtc_state->base.enable)
+   drm_mode_get_hv_timing(_state->base.mode,
+  , );
+
+   state->base.visible = drm_rect_clip_scaled(src, dst, , hscale, 
vscale);
+
+   crtc_x = dst->x1;
+   crtc_y = dst->y1;
+   crtc_w = drm_rect_width(dst);
+   crtc_h = drm_rect_height(dst);
+
+   if (state->base.visible) {
+   /* check again in case clipping clamped the results */
+   hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
+   if (hscale < 0) {
+   DRM_DEBUG_KMS("Horizontal scaling factor out of 
limits\n");
+   drm_rect_debug_print("src: ", src, true);
+   drm_rect_debug_print("dst: ", dst, false);
+
+   return hscale;
+   }
+
+   vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
+   if (vscale < 0) {
+   DRM_DEBUG_KMS("Vertical scaling factor out of 
limits\n");
+   drm_rect_debug_print("src: ", src, true);
+   drm_rect_debug_print("dst: ", dst, false);
+
+   return vscale;
+   }
+
+   /* Make the source viewport size an exact multiple of the 
scaling factors. */
+   drm_rect_adjust_size(src,
+drm_rect_width(dst) * hscale - 
drm_rect_width(src),
+drm_rect_height(dst) * vscale - 
drm_rect_height(src));
+
+   drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
+   state->base.rotation);
+
+   /* sanity check to make sure the src viewport 

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Measure sampler intervals

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-05-25 18:31:35)
> 
> On 25/05/2018 18:11, Chris Wilson wrote:
> > hrtimer is not reliable enough to assume fixed intervals, and so even
> > coarse accuracy (in the face of kasan and similar heavy debugging) we
> > need to measure the actual interval between sample.
> 
> It doesn't even average out to something acceptable under such Kconfigs? 
> Horror.. precise but inaccurate. /O\
> 
> > While using a single timestamp to compute the interval does not allow
> > very fine accuracy (consider the impact of a slow forcewake between
> > different samples after the timestamp is read) is much better than
> > assuming the interval.
> > 
> > Testcase: igt/perf_pmu #ivb
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/i915_pmu.c | 20 +---
> >   drivers/gpu/drm/i915/i915_pmu.h |  4 
> >   2 files changed, 17 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index dc87797db500..f5087515eb43 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -127,6 +127,7 @@ static void __i915_pmu_maybe_start_timer(struct 
> > drm_i915_private *i915)
> >   {
> >   if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
> >   i915->pmu.timer_enabled = true;
> > + i915->pmu.timestamp = ktime_get();
> >   hrtimer_start_range_ns(>pmu.timer,
> >  ns_to_ktime(PERIOD), 0,
> >  HRTIMER_MODE_REL_PINNED);
> > @@ -160,7 +161,7 @@ update_sample(struct i915_pmu_sample *sample, u32 unit, 
> > u32 val)
> >   sample->cur += mul_u32_u32(val, unit);
> >   }
> >   
> > -static void engines_sample(struct drm_i915_private *dev_priv)
> > +static void engines_sample(struct drm_i915_private *dev_priv, u64 period)
> >   {
> >   struct intel_engine_cs *engine;
> >   enum intel_engine_id id;
> > @@ -183,7 +184,7 @@ static void engines_sample(struct drm_i915_private 
> > *dev_priv)
> >   val = !i915_seqno_passed(current_seqno, last_seqno);
> >   
> >   update_sample(>pmu.sample[I915_SAMPLE_BUSY],
> > -   PERIOD, val);
> > +   period, val);
> >   
> >   if (val && (engine->pmu.enable &
> >   (BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
> > @@ -195,10 +196,10 @@ static void engines_sample(struct drm_i915_private 
> > *dev_priv)
> >   }
> >   
> >   update_sample(>pmu.sample[I915_SAMPLE_WAIT],
> > -   PERIOD, !!(val & RING_WAIT));
> > +   period, !!(val & RING_WAIT));
> >   
> >   update_sample(>pmu.sample[I915_SAMPLE_SEMA],
> > -   PERIOD, !!(val & RING_WAIT_SEMAPHORE));
> > +   period, !!(val & RING_WAIT_SEMAPHORE));
> >   }
> >   
> >   if (fw)
> > @@ -207,7 +208,7 @@ static void engines_sample(struct drm_i915_private 
> > *dev_priv)
> >   intel_runtime_pm_put(dev_priv);
> >   }
> >   
> > -static void frequency_sample(struct drm_i915_private *dev_priv)
> > +static void frequency_sample(struct drm_i915_private *dev_priv, u64 period)
> 
> Period is unused in this function.
> 
> But more importantly that leads to a problem. When reading the counter 
> the frequencies accumulator is divided by FREQUENCY define, which is 
> inverse of PERIOD. If the error is big enough to mess up the engines 
> sampling, is it big enough to affect the frequencies as well?

Yes, but fixing up frequencies I left for another patch, because it's
going to be more involved (having to choose the divider more carefully)
and would you believe it, but CI only complains about busy sampling ;)

I passed in the period as a reminder.
 
> Improving that would need average frequency between two counter reads. 
> Which looks tricky to shoehorn into the pmu api. Maybe primitive running 
> average would do.

My plan was to expose cycles (Frequency x time) to the user, and then
they calculate frequency by the comparing their own samples. (Since we
give them (time, samples) for each pmu read).

> >   {
> >   if (dev_priv->pmu.enable &
> >   config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY)) {
> > @@ -237,12 +238,17 @@ static enum hrtimer_restart i915_sample(struct 
> > hrtimer *hrtimer)
> >   {
> >   struct drm_i915_private *i915 =
> >   container_of(hrtimer, struct drm_i915_private, pmu.timer);
> > + ktime_t now, period;
> >   
> >   if (!READ_ONCE(i915->pmu.timer_enabled))
> >   return HRTIMER_NORESTART;
> >   
> > - engines_sample(i915);
> > - frequency_sample(i915);
> > + now = ktime_get();
> > + period = ktime_sub(now, i915->pmu.timestamp);
> > + i915->pmu.timestamp = now;
> > +
> > + 

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Measure sampler intervals

[Tvrtko Ursulin]

On 25/05/2018 18:11, Chris Wilson wrote:

hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual interval between sample.


It doesn't even average out to something acceptable under such Kconfigs? 
Horror.. precise but inaccurate. /O\



While using a single timestamp to compute the interval does not allow
very fine accuracy (consider the impact of a slow forcewake between
different samples after the timestamp is read) is much better than
assuming the interval.

Testcase: igt/perf_pmu #ivb
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_pmu.c | 20 +---
  drivers/gpu/drm/i915/i915_pmu.h |  4 
  2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index dc87797db500..f5087515eb43 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -127,6 +127,7 @@ static void __i915_pmu_maybe_start_timer(struct 
drm_i915_private *i915)
  {
if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
i915->pmu.timer_enabled = true;
+   i915->pmu.timestamp = ktime_get();
hrtimer_start_range_ns(>pmu.timer,
   ns_to_ktime(PERIOD), 0,
   HRTIMER_MODE_REL_PINNED);
@@ -160,7 +161,7 @@ update_sample(struct i915_pmu_sample *sample, u32 unit, u32 
val)
sample->cur += mul_u32_u32(val, unit);
  }
  
-static void engines_sample(struct drm_i915_private *dev_priv)

+static void engines_sample(struct drm_i915_private *dev_priv, u64 period)
  {
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -183,7 +184,7 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
val = !i915_seqno_passed(current_seqno, last_seqno);
  
  		update_sample(>pmu.sample[I915_SAMPLE_BUSY],

- PERIOD, val);
+ period, val);
  
  		if (val && (engine->pmu.enable &

(BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
@@ -195,10 +196,10 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
}
  
  		update_sample(>pmu.sample[I915_SAMPLE_WAIT],

- PERIOD, !!(val & RING_WAIT));
+ period, !!(val & RING_WAIT));
  
  		update_sample(>pmu.sample[I915_SAMPLE_SEMA],

- PERIOD, !!(val & RING_WAIT_SEMAPHORE));
+ period, !!(val & RING_WAIT_SEMAPHORE));
}
  
  	if (fw)

@@ -207,7 +208,7 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
intel_runtime_pm_put(dev_priv);
  }
  
-static void frequency_sample(struct drm_i915_private *dev_priv)

+static void frequency_sample(struct drm_i915_private *dev_priv, u64 period)


Period is unused in this function.

But more importantly that leads to a problem. When reading the counter 
the frequencies accumulator is divided by FREQUENCY define, which is 
inverse of PERIOD. If the error is big enough to mess up the engines 
sampling, is it big enough to affect the frequencies as well?


Improving that would need average frequency between two counter reads. 
Which looks tricky to shoehorn into the pmu api. Maybe primitive running 
average would do.



  {
if (dev_priv->pmu.enable &
config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY)) {
@@ -237,12 +238,17 @@ static enum hrtimer_restart i915_sample(struct hrtimer 
*hrtimer)
  {
struct drm_i915_private *i915 =
container_of(hrtimer, struct drm_i915_private, pmu.timer);
+   ktime_t now, period;
  
  	if (!READ_ONCE(i915->pmu.timer_enabled))

return HRTIMER_NORESTART;
  
-	engines_sample(i915);

-   frequency_sample(i915);
+   now = ktime_get();
+   period = ktime_sub(now, i915->pmu.timestamp);
+   i915->pmu.timestamp = now;
+
+   engines_sample(i915, period);
+   frequency_sample(i915, period);
  
  	hrtimer_forward_now(hrtimer, ns_to_ktime(PERIOD));

return HRTIMER_RESTART;
diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
index 2ba735299f7c..0f1e4642077e 100644
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@ -52,6 +52,10 @@ struct i915_pmu {
 * @timer: Timer for internal i915 PMU sampling.
 */
struct hrtimer timer;
+   /**
+* @timestamp: Timestamp of last internal i915 PMU sampling.
+*/
+   ktime_t timestamp;
/**
 * @enable: Bitmask of all currently enabled events.
 *



Patch looks okay, just loses the some of the optimisation potential so I 
am guessing we won't be thinking about replacing multiplies and divides 
with shift any 

Re: [Intel-gfx] DRM Inquiry

[Jani Nikula]

On Fri, 25 May 2018, "Taylor, Clinton A"  wrote:
> Looks like the seek=%d in the sprintf is not working.

Yeah. Try skip=%d instead.

BR,
Jani.


-- 
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] [PATCH] drm/i915/pmu: Measure sampler intervals

[Chris Wilson]

hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual interval between sample.

While using a single timestamp to compute the interval does not allow
very fine accuracy (consider the impact of a slow forcewake between
different samples after the timestamp is read) is much better than
assuming the interval.

Testcase: igt/perf_pmu #ivb
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 20 +---
 drivers/gpu/drm/i915/i915_pmu.h |  4 
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index dc87797db500..f5087515eb43 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -127,6 +127,7 @@ static void __i915_pmu_maybe_start_timer(struct 
drm_i915_private *i915)
 {
if (!i915->pmu.timer_enabled && pmu_needs_timer(i915, true)) {
i915->pmu.timer_enabled = true;
+   i915->pmu.timestamp = ktime_get();
hrtimer_start_range_ns(>pmu.timer,
   ns_to_ktime(PERIOD), 0,
   HRTIMER_MODE_REL_PINNED);
@@ -160,7 +161,7 @@ update_sample(struct i915_pmu_sample *sample, u32 unit, u32 
val)
sample->cur += mul_u32_u32(val, unit);
 }
 
-static void engines_sample(struct drm_i915_private *dev_priv)
+static void engines_sample(struct drm_i915_private *dev_priv, u64 period)
 {
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -183,7 +184,7 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
val = !i915_seqno_passed(current_seqno, last_seqno);
 
update_sample(>pmu.sample[I915_SAMPLE_BUSY],
- PERIOD, val);
+ period, val);
 
if (val && (engine->pmu.enable &
(BIT(I915_SAMPLE_WAIT) | BIT(I915_SAMPLE_SEMA {
@@ -195,10 +196,10 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
}
 
update_sample(>pmu.sample[I915_SAMPLE_WAIT],
- PERIOD, !!(val & RING_WAIT));
+ period, !!(val & RING_WAIT));
 
update_sample(>pmu.sample[I915_SAMPLE_SEMA],
- PERIOD, !!(val & RING_WAIT_SEMAPHORE));
+ period, !!(val & RING_WAIT_SEMAPHORE));
}
 
if (fw)
@@ -207,7 +208,7 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
intel_runtime_pm_put(dev_priv);
 }
 
-static void frequency_sample(struct drm_i915_private *dev_priv)
+static void frequency_sample(struct drm_i915_private *dev_priv, u64 period)
 {
if (dev_priv->pmu.enable &
config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY)) {
@@ -237,12 +238,17 @@ static enum hrtimer_restart i915_sample(struct hrtimer 
*hrtimer)
 {
struct drm_i915_private *i915 =
container_of(hrtimer, struct drm_i915_private, pmu.timer);
+   ktime_t now, period;
 
if (!READ_ONCE(i915->pmu.timer_enabled))
return HRTIMER_NORESTART;
 
-   engines_sample(i915);
-   frequency_sample(i915);
+   now = ktime_get();
+   period = ktime_sub(now, i915->pmu.timestamp);
+   i915->pmu.timestamp = now;
+
+   engines_sample(i915, period);
+   frequency_sample(i915, period);
 
hrtimer_forward_now(hrtimer, ns_to_ktime(PERIOD));
return HRTIMER_RESTART;
diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
index 2ba735299f7c..0f1e4642077e 100644
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@ -52,6 +52,10 @@ struct i915_pmu {
 * @timer: Timer for internal i915 PMU sampling.
 */
struct hrtimer timer;
+   /**
+* @timestamp: Timestamp of last internal i915 PMU sampling.
+*/
+   ktime_t timestamp;
/**
 * @enable: Bitmask of all currently enabled events.
 *
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH 06/24] drm/i915/ICL: Add register definition for DFLEXDPMLE

[Manasi Navare]

On Fri, May 25, 2018 at 09:14:57AM -0700, Lucas De Marchi wrote:
> On Thu, May 24, 2018 at 05:26:38PM -0700, Paulo Zanoni wrote:
> > Em Seg, 2018-05-21 às 17:25 -0700, Paulo Zanoni escreveu:
> > > From: Manasi Navare 
> > > 
> > > DFLEXDPMLE register is required to tell the FIA hardware which
> > > main links of DP are enabled on TCC Connectors. FIA uses this
> > > information to program PHY to Controller signal mapping.
> > > This register is applicable in both TC connector's Alternate mode
> > > as well as DP connector mode.
> > > 
> > > Cc: Jani Nikula 
> > > Cc: Animesh Manna 
> > > Cc: Madhav Chauhan 
> > > Cc: Anusha Srivatsa 
> > > Cc: Paulo Zanoni 
> > > Signed-off-by: Manasi Navare 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h | 5 +
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 28ce96ce0484..7f27fe2e38c7 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -1990,6 +1990,11 @@ enum i915_power_well_id {
> > >  _ICL_PORT_COMP_DW
> > > 10_A, \
> > >  _ICL_PORT_COMP_DW
> > > 10_B)
> > >  
> > > +/* ICL PHY DFLEX registers */
> > > +#define ICL_PORT_TX_DFLEXDPMLE1  _MMIO(0x1638C0)
> > 
> > We can probably remove the ICL_ prefix since the register did not exist
> > before.
>

Yes I agree this ICL prefix should be removed like I did for all the MG PHY 
regs too.
 
> And while at it s/ICL/icl/ in the commit message?
> 
> Lucas De Marchi
>

And yes will change this as well in the commit message.
Thanks for the review.

Manasi
 
> > 
> > With or without that:
> > Reviewed-by: Paulo Zanoni 
> > 
> > Note: the patch that uses the register was removed from the series due
> > to some problems identified. Will be upstreamed as soon as it's fixed.
> > 
> > > +#define   DFLEXDPMLE1_DPMLETC_MASK(n)(0xf << (4 * (n)))
> > > +#define   DFLEXDPMLE1_DPMLETC(n, x)  ((x) << (4 * (n)))
> > > +
> > >  /* BXT PHY Ref registers */
> > >  #define _PORT_REF_DW3_A  0x16218C
> > >  #define _PORT_REF_DW3_BC 0x6C18C
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: fix icl_unmap/map_plls_to_ports (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/icl: fix icl_unmap/map_plls_to_ports (rev2)
URL   : https://patchwork.freedesktop.org/series/43510/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4242 -> Patchwork_9123 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43510/revisions/2/mbox/


== Changes ==

  No changes found


== Participating hosts (43 -> 39) ==

  Additional (1): fi-cnl-y3 
  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4242 -> Patchwork_9123

  CI_DRM_4242: 0364c498cd9a9e584a7080ee8526e9d17a7d4c67 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9123: 5ea233f0d8ba58cee34c41e139aec7839a6f02e3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5ea233f0d8ba drm/i915/icl: fix icl_unmap/map_plls_to_ports

== Logs ==

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

Re: [Intel-gfx] [PATCH 07/24] drm/i915/icl: Add DDI HDMI level selection for ICL

[Lucas De Marchi]

On Mon, May 21, 2018 at 05:25:41PM -0700, Paulo Zanoni wrote:
> From: Manasi Navare 
> 
> This patch adds a proper HDMI DDI entry level for vswing
> programming sequences on ICL.
> 
> Spec doesn't specify any default for HDMI tables,
> so let's pick the last entry as the default for now
> to stay consistent with older platform like CNL.
> 
> Cc: Paulo Zanoni 
> Cc: Rakshmi Bhatia 
> Cc: Rodrigo Vivi 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 1665bc588241..d8ae82001f83 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -915,7 +915,14 @@ static int intel_ddi_hdmi_level(struct drm_i915_private 
> *dev_priv, enum port por
>  
>   level = dev_priv->vbt.ddi_port_info[port].hdmi_level_shift;
>  
> - if (IS_CANNONLAKE(dev_priv)) {
> + if (IS_ICELAKE(dev_priv)) {
> + if (port == PORT_A || port == PORT_B)

This should be using the helper you introduced in patch 3. Either a
'if (!intel_port_is_tc()' or add a 'if (intel_port_is_combo)'.

With that,

Reviewed-by: Lucas De Marchi 

Lucas De Marchi

> + icl_get_combo_buf_trans(dev_priv, port,
> + INTEL_OUTPUT_HDMI, _entries);
> + else
> + n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations);
> + default_entry = n_entries - 1;
> + } else if (IS_CANNONLAKE(dev_priv)) {
>   cnl_get_buf_trans_hdmi(dev_priv, _entries);
>   default_entry = n_entries - 1;
>   } else if (IS_GEN9_LP(dev_priv)) {
> -- 
> 2.14.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 25/24] drm/i915/icl: fix gmbus gpio pin mapping

[Lucas De Marchi]

On Fri, May 25, 2018 at 07:24:07PM +0300, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 05:36:37PM -0700, Lucas De Marchi wrote:
> > On Thu, May 24, 2018 at 04:42:36PM -0700, Paulo Zanoni wrote:
> > > From: Mahesh Kumar 
> > > 
> > > ICP has GPIO pin 1/2 mapped to combo-phy ports & GPIO pins 9/10/11/12
> > > mapped to tc ports[1-4].
> > > This patch defines GPIOCTL registers for GPIO pins 9-12 & uses them in 
> > > GPIO
> > > pin mapping table.
> > > 
> > > Cc: Anusha Srivatsa 
> > > Cc: Madhav Chauhan 
> > > Cc: Lucas De Marchi 
> > > Signed-off-by: Mahesh Kumar 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h   |  4 
> > >  drivers/gpu/drm/i915/intel_hdmi.c |  2 +-
> > >  drivers/gpu/drm/i915/intel_i2c.c  | 12 ++--
> > >  3 files changed, 11 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 452356a4af07..e48b717769b2 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -3015,6 +3015,10 @@ enum i915_power_well_id {
> > >  #define GPIOF_MMIO(0x5024)
> > >  #define GPIOG_MMIO(0x5028)
> > >  #define GPIOH_MMIO(0x502c)
> > > +#define GPIOJ_MMIO(0x5034)
> > > +#define GPIOK_MMIO(0x5038)
> > > +#define GPIOL_MMIO(0x503C)
> > > +#define GPIOM_MMIO(0x5040)
> > 
> > I was reviewing again this and I think again I was puzzled why the spec
> > has them as 0xc5034, ...
> > 
> > Probably same conclusion as I had when I first reviewed this. Maybe it
> > would be nice to add a comment to PCH_GPIO* saying PCH_GPIOA is used
> > only for calculation the gpio base and remove the rest. I can send this
> > is a separate patch, what do you think?
> > 
> > ---8<---
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 6953419881c4..40b9aa57078b 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7442,12 +7442,8 @@ enum {
> >  #define  PORTE_HOTPLUG_SHORT_DETECT(1 << 0)
> >  #define  PORTE_HOTPLUG_LONG_DETECT (2 << 0)
> >  
> > +/* Used just for calculating the gpio base for PCH */
> >  #define PCH_GPIOA   _MMIO(0xc5010)
> > -#define PCH_GPIOB   _MMIO(0xc5014)
> > -#define PCH_GPIOC   _MMIO(0xc5018)
> > -#define PCH_GPIOD   _MMIO(0xc501c)
> > -#define PCH_GPIOE   _MMIO(0xc5020)
> > -#define PCH_GPIOF   _MMIO(0xc5024)
> 
> Maybe just have
> 
> #define PCH_GPIO_BASE ...
> 
> and throw out the PCH_GPIO/GMBUS defines entirely?

Yeah just thought about this after sending the email. I will spin a
patch with that.

thanks
Lucas De Marchi

> 
> >  
> >  #define PCH_GMBUS0 _MMIO(0xc5100)
> >  #define PCH_GMBUS1 _MMIO(0xc5104)
> > ---8<---
> > 
> > 
> > Other than that,
> > 
> > Reviewed-by: Lucas De Marchi 
> > 
> > >  # define GPIO_CLOCK_DIR_MASK (1 << 0)
> > >  # define GPIO_CLOCK_DIR_IN   (0 << 1)
> > >  # define GPIO_CLOCK_DIR_OUT  (1 << 1)
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 75f02a0e7d39..3db2459c79b1 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -2276,7 +2276,7 @@ static u8 intel_hdmi_ddc_pin(struct 
> > > drm_i915_private *dev_priv,
> > >   ddc_pin = bxt_port_to_ddc_pin(dev_priv, port);
> > >   else if (HAS_PCH_CNP(dev_priv))
> > >   ddc_pin = cnp_port_to_ddc_pin(dev_priv, port);
> > > - else if (IS_ICELAKE(dev_priv))
> > > + else if (HAS_PCH_ICP(dev_priv))
> > >   ddc_pin = icl_port_to_ddc_pin(dev_priv, port);
> > >   else
> > >   ddc_pin = g4x_port_to_ddc_pin(dev_priv, port);
> > > diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> > > b/drivers/gpu/drm/i915/intel_i2c.c
> > > index e6875509bcd9..b91e418028cb 100644
> > > --- a/drivers/gpu/drm/i915/intel_i2c.c
> > > +++ b/drivers/gpu/drm/i915/intel_i2c.c
> > > @@ -77,12 +77,12 @@ static const struct gmbus_pin gmbus_pins_cnp[] = {
> > >  };
> > >  
> > >  static const struct gmbus_pin gmbus_pins_icp[] = {
> > > - [GMBUS_PIN_1_BXT] = { "dpa", GPIOA },
> > > - [GMBUS_PIN_2_BXT] = { "dpb", GPIOB },
> > > - [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOC },
> > > - [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOD },
> > > - [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOE },
> > > - [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOF },
> > > + [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
> > > + [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
> > > + [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
> > > + [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOK },
> > > + [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOL },
> > > + 

Re: [Intel-gfx] [PATCH 25/24] drm/i915/icl: fix gmbus gpio pin mapping

[Ville Syrjälä]

On Thu, May 24, 2018 at 05:36:37PM -0700, Lucas De Marchi wrote:
> On Thu, May 24, 2018 at 04:42:36PM -0700, Paulo Zanoni wrote:
> > From: Mahesh Kumar 
> > 
> > ICP has GPIO pin 1/2 mapped to combo-phy ports & GPIO pins 9/10/11/12
> > mapped to tc ports[1-4].
> > This patch defines GPIOCTL registers for GPIO pins 9-12 & uses them in GPIO
> > pin mapping table.
> > 
> > Cc: Anusha Srivatsa 
> > Cc: Madhav Chauhan 
> > Cc: Lucas De Marchi 
> > Signed-off-by: Mahesh Kumar 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h   |  4 
> >  drivers/gpu/drm/i915/intel_hdmi.c |  2 +-
> >  drivers/gpu/drm/i915/intel_i2c.c  | 12 ++--
> >  3 files changed, 11 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 452356a4af07..e48b717769b2 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3015,6 +3015,10 @@ enum i915_power_well_id {
> >  #define GPIOF  _MMIO(0x5024)
> >  #define GPIOG  _MMIO(0x5028)
> >  #define GPIOH  _MMIO(0x502c)
> > +#define GPIOJ  _MMIO(0x5034)
> > +#define GPIOK  _MMIO(0x5038)
> > +#define GPIOL  _MMIO(0x503C)
> > +#define GPIOM  _MMIO(0x5040)
> 
> I was reviewing again this and I think again I was puzzled why the spec
> has them as 0xc5034, ...
> 
> Probably same conclusion as I had when I first reviewed this. Maybe it
> would be nice to add a comment to PCH_GPIO* saying PCH_GPIOA is used
> only for calculation the gpio base and remove the rest. I can send this
> is a separate patch, what do you think?
> 
> ---8<---
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6953419881c4..40b9aa57078b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7442,12 +7442,8 @@ enum {
>  #define  PORTE_HOTPLUG_SHORT_DETECT  (1 << 0)
>  #define  PORTE_HOTPLUG_LONG_DETECT   (2 << 0)
>  
> +/* Used just for calculating the gpio base for PCH */
>  #define PCH_GPIOA   _MMIO(0xc5010)
> -#define PCH_GPIOB   _MMIO(0xc5014)
> -#define PCH_GPIOC   _MMIO(0xc5018)
> -#define PCH_GPIOD   _MMIO(0xc501c)
> -#define PCH_GPIOE   _MMIO(0xc5020)
> -#define PCH_GPIOF   _MMIO(0xc5024)

Maybe just have

#define PCH_GPIO_BASE ...

and throw out the PCH_GPIO/GMBUS defines entirely?

>  
>  #define PCH_GMBUS0   _MMIO(0xc5100)
>  #define PCH_GMBUS1   _MMIO(0xc5104)
> ---8<---
> 
> 
> Other than that,
> 
> Reviewed-by: Lucas De Marchi 
> 
> >  # define GPIO_CLOCK_DIR_MASK   (1 << 0)
> >  # define GPIO_CLOCK_DIR_IN (0 << 1)
> >  # define GPIO_CLOCK_DIR_OUT(1 << 1)
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 75f02a0e7d39..3db2459c79b1 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -2276,7 +2276,7 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private 
> > *dev_priv,
> > ddc_pin = bxt_port_to_ddc_pin(dev_priv, port);
> > else if (HAS_PCH_CNP(dev_priv))
> > ddc_pin = cnp_port_to_ddc_pin(dev_priv, port);
> > -   else if (IS_ICELAKE(dev_priv))
> > +   else if (HAS_PCH_ICP(dev_priv))
> > ddc_pin = icl_port_to_ddc_pin(dev_priv, port);
> > else
> > ddc_pin = g4x_port_to_ddc_pin(dev_priv, port);
> > diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> > b/drivers/gpu/drm/i915/intel_i2c.c
> > index e6875509bcd9..b91e418028cb 100644
> > --- a/drivers/gpu/drm/i915/intel_i2c.c
> > +++ b/drivers/gpu/drm/i915/intel_i2c.c
> > @@ -77,12 +77,12 @@ static const struct gmbus_pin gmbus_pins_cnp[] = {
> >  };
> >  
> >  static const struct gmbus_pin gmbus_pins_icp[] = {
> > -   [GMBUS_PIN_1_BXT] = { "dpa", GPIOA },
> > -   [GMBUS_PIN_2_BXT] = { "dpb", GPIOB },
> > -   [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOC },
> > -   [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOD },
> > -   [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOE },
> > -   [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOF },
> > +   [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
> > +   [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
> > +   [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
> > +   [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOK },
> > +   [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOL },
> > +   [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOM },
> >  };
> >  
> >  /* pin is expected to be valid */
> > -- 
> > 2.14.3
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx 

Re: [Intel-gfx] [PATCH 06/24] drm/i915/ICL: Add register definition for DFLEXDPMLE

[Lucas De Marchi]

On Thu, May 24, 2018 at 05:26:38PM -0700, Paulo Zanoni wrote:
> Em Seg, 2018-05-21 às 17:25 -0700, Paulo Zanoni escreveu:
> > From: Manasi Navare 
> > 
> > DFLEXDPMLE register is required to tell the FIA hardware which
> > main links of DP are enabled on TCC Connectors. FIA uses this
> > information to program PHY to Controller signal mapping.
> > This register is applicable in both TC connector's Alternate mode
> > as well as DP connector mode.
> > 
> > Cc: Jani Nikula 
> > Cc: Animesh Manna 
> > Cc: Madhav Chauhan 
> > Cc: Anusha Srivatsa 
> > Cc: Paulo Zanoni 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 28ce96ce0484..7f27fe2e38c7 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1990,6 +1990,11 @@ enum i915_power_well_id {
> >_ICL_PORT_COMP_DW
> > 10_A, \
> >_ICL_PORT_COMP_DW
> > 10_B)
> >  
> > +/* ICL PHY DFLEX registers */
> > +#define ICL_PORT_TX_DFLEXDPMLE1_MMIO(0x1638C0)
> 
> We can probably remove the ICL_ prefix since the register did not exist
> before.

And while at it s/ICL/icl/ in the commit message?

Lucas De Marchi

> 
> With or without that:
> Reviewed-by: Paulo Zanoni 
> 
> Note: the patch that uses the register was removed from the series due
> to some problems identified. Will be upstreamed as soon as it's fixed.
> 
> > +#define   DFLEXDPMLE1_DPMLETC_MASK(n)  (0xf << (4 * (n)))
> > +#define   DFLEXDPMLE1_DPMLETC(n, x)((x) << (4 * (n)))
> > +
> >  /* BXT PHY Ref registers */
> >  #define _PORT_REF_DW3_A0x16218C
> >  #define _PORT_REF_DW3_BC   0x6C18C
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] DRM Inquiry

[Taylor, Clinton A]

Looks like the seek=%d in the sprintf is not working. 0x11 0x0A are being 
returned by the monitor from DPCD’s 0x and 0x0001 repeatedly. The first is 
DPCD revision (1.1) and the second is maximum Link Rate (0x0a) which is 2.7 
Gbps. You might want to do a printf of call to make sure seek is being set 
correctly.

Which brings up another issue: eDP Backlight Brightness LSB is at hex 0x723 or 
1827 decimal. You might also want to confirm your panel supports DPCD backlight 
adjustment by reading DPCD 0x701 and confirm bit 0 is set.

Clint

From: Intel-gfx  On Behalf Of John 
Sledge
Sent: Friday, May 25, 2018 1:11 AM
To: dri-de...@lists.freedesktop.org; Jani Nikula 
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] DRM Inquiry

Hi Jani,

I seek 0-800 and here's what I get, all 11 0A in hex. Not sure if this is the 
brightness value of the display. I also did a test, when I disconnect the DP to 
the display and execute the dd commands, it would say error reading 
'dev/drm_dp_aux1': Connection timed out. So I think my display setup is okay 
and the 11 0A values are really coming out from the display.

Output in hex:
11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 
11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 
11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 
11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 11 0A 

int main(int argc, char **argv)
{
int ret = 0;
int offset = 0;
char call[100];
for(offset=0;offset<800;offset++)
{
sprintf(call,"dd if=/dev/drm_dp_aux1 bs=1 count=2 seek=%d >> out.txt",offset);
ret = system(call);
}
return 0;
}
Regards,
John




On Friday, May 25, 2018, 2:56:04 PM GMT+8, Jani Nikula 
> wrote:


On Fri, 25 May 2018, John Sledge 
> wrote:
>  Hi Jani,
> I can now see /dev/drm_dp_aux*.
> I'm not familiar with dd command.Correct me if I'm wrong.
> Possible commands i tried and nothing happen:dd if=/dev/drm_dp_aux1 seek=723 
> ibs=2dd of=/dev/drm_dp_aux1 seek=723 ibs=2
> dd if=/dev/drm_dp_aux2 seek=723 ibs=2dd of=/dev/drm_dp_aux2 seek=723 ibs=2
> I assumed I could read the brightness msb and lsb using the define in 
> drm_dp_helper.h.
> #define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722#define 
> DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723

You're mixing hex and decimal numbers, you should probably use bs=1
count=2, dd outputs binary so you probably need to pipe it to hexdump to
see anything, etc. Perhaps start experiments with reading at seek=0.

> From here, I was thinking if I could try to open \dev\drm_dp_aux* then read 
> the brightness offset 0x723, though not sure how to proceed with it.I was 
> able to successfully open \dev\drm_dp_aux1 and \dev\drm_dp_aux2 but I 
> thinking I'm wrong when I proceed to ioctl because they all failed.

It's a character device, open, seek, read/write. Don't try any ioctls on
it.

Good luck.


BR,

Jani.


>
> #define BRIGHTNESS 0x723
> int main(int argc, char ** argv){  int fd;  int retcode;  char out[128];
> if((fd = open("/dev/drm_dp_aux1",O_RDWR)) >=0)  {printf("open success");  
> }  else  {printf("open failed");
>   }
>if((retcode = ioctl(fd,BRIGHTNESS,)) < 0)  {printf("ioctl 
> failed");  }  else  {printf("ioctl success");
>   }
>   // trying aux2  if((fd = open("/dev/drm_dp_aux2",O_RDWR)) >=0)  {
> printf("open success");  }  else  {printf("open failed");
>   }
>   if((retcode = ioctl(fd,BRIGHTNESS,)) < 0)  {printf("ioctl failed"); 
>  }  else  {printf("ioctl success");
>   }
>   return 0;}
> Thanks,John
>
>On Thursday, May 24, 2018, 8:38:02 PM GMT+8, Jani Nikula 
> > wrote:
>
>  On Thu, 24 May 2018, John Sledge 
> > wrote:
>> I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV
>> in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also
>> add DRM_DP_AUX_CHARDEV=y in  kernel config. When invoke uname -r, I
>> could see that the kernel is now 4.6.
>
> If you're updating kernels, why not update to a recent kernel that's
> actually supported...?
>
>> How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure
>> it correctly?
>
> Boot the kernel, run 'ls /dev/drm_dp_aux*'. If you see stuff, you got it
> right.
>
>> It still unclear to me how to follow what you mean by using DRM DP AUX
>> interface and getting /dev/drm_dp_auxN node(s) that allows me to read
>> and write arbitrary DPCD offsets.
>
> The device is a char device you can open, seek to an offset (which would
> be the DPCD offset), and read. For testing, you can achieve the same
> using dd.
>
> BR,
> Jani.

--
Jani Nikula, Intel Open Source Graphics Center
___

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Simplify ilk-ivb underrun suppression

[Chris Wilson]

Quoting Ville Syrjälä (2018-05-25 16:43:42)
> On Fri, May 25, 2018 at 04:20:07PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjala (2018-05-24 20:04:06)
> > > From: Ville Syrjälä 
> > > 
> > > Let's suppress the underruns around every modeset sequence instead
> > > of trying to avoid it. Planes are disabled at this point anyway so
> > > we don't really gain anything from keeping the underrun reporting
> > > enabled. Also for PCH ports we already suppress all underruns here
> > > anyway so trying avoid it for the CPU eDP doesn't seem all that
> > > important.
> > > 
> > > Maybe this gets rid of some lingering spurious underruns?
> > 
> > I'll bite. Isn't the reason for enabling underrung report for the
> > modeset itself to detect errors in our sequence?
> 
> In theory CPU FIFO underruns shouldn't happen until we have some planes
> enabled. Otherwise we have no data going through the FIFOs and thus
> reporting an underrun isn't particularly sane. That doesn't stop gen2
> from doing it though, but gen3+ seem to follow the more reasonable
> interpretation of what a FIFO underrun means.

Makes sense.
 
> I suppose PCH FIFO underruns are a bit different as there is data flowing
> as soon as the CPU pipe starts running, whether or not any planes have
> been enabled. So those could certainly indicate some kind of programming
> sequence error. Or it could just be totally expected that we start the
> PCH side of the pipe first and there's a small bit of time when the CPU
> pipe isn't yet pushing out pixels, and that's when the PCH side reports
> the underrun.
> 
> > 
> > How certain are we that these are hw limitations vs sw bugs?
> 
> To the best of my knowledge we are reasonably close to the sequence
> listed in bspec. And while it's at least theoretically possible that
> there's some change we could make to eliminate the underruns I don't
> suppose anyone has the time or energy to try out all possible
> variations.
> 
> And as long as the underrun (even if it's real) has vanished by the
> time we enable the planes I think we are reasonably safe wrt. getting
> the correct looking output to the user's display.

Also makes sense. And if glitches during modesetting itself, we hope
nobody complains ;)

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

[Intel-gfx] [PATCH] drm/i915/icl: fix icl_unmap/map_plls_to_ports

[Lucas De Marchi]

From: Mahesh Kumar 

All connectors may not have best_encoder attached, so don't dereference
encoder pointer for each connector.

Fixes: c27e917e2bda (drm/i915/icl: add basic support for the ICL clocks)
Signed-off-by: Mahesh Kumar 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 3b8f12883ca7..c33b19705e39 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2444,12 +2444,13 @@ void icl_map_plls_to_ports(struct drm_crtc *crtc,
for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);
-   enum port port = encoder->port;
+   enum port port;
uint32_t val;
 
if (conn_state->crtc != crtc)
continue;
 
+   port = encoder->port;
mutex_lock(_priv->dpll_lock);
 
val = I915_READ(DPCLKA_CFGCR0_ICL);
@@ -2481,11 +2482,12 @@ void icl_unmap_plls_to_ports(struct drm_crtc *crtc,
for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(old_conn_state->best_encoder);
-   enum port port = encoder->port;
+   enum port port;
 
if (old_conn_state->crtc != crtc)
continue;
 
+   port = encoder->port;
mutex_lock(_priv->dpll_lock);
I915_WRITE(DPCLKA_CFGCR0_ICL,
   I915_READ(DPCLKA_CFGCR0_ICL) |
-- 
2.17.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove stale asserts from i915_gem_find_active_request()

[Patchwork]

== Series Details ==

Series: drm/i915: Remove stale asserts from i915_gem_find_active_request()
URL   : https://patchwork.freedesktop.org/series/43781/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4242 -> Patchwork_9122 =

== Summary - WARNING ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43781/revisions/1/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_gttfill@basic:
  fi-pnv-d510:PASS -> SKIP




== Participating hosts (43 -> 38) ==

  Additional (1): fi-cnl-y3 
  Missing(6): fi-ilk-m540 fi-byt-j1900 fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4242 -> Patchwork_9122

  CI_DRM_4242: 0364c498cd9a9e584a7080ee8526e9d17a7d4c67 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9122: ce83453c8437968122d49ba7529e8c4860659cee @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ce83453c8437 drm/i915: Remove stale asserts from i915_gem_find_active_request()

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Try to suppress more spurious PCH underruns on ILK-IVB

[Ville Syrjälä]

On Fri, May 25, 2018 at 06:19:17PM +0300, Jani Nikula wrote:
> On Fri, 25 May 2018, Ville Syrjälä  wrote:
> > On Thu, May 24, 2018 at 10:19:02PM +0100, Chris Wilson wrote:
> >> Quoting Ville Syrjala (2018-05-24 20:04:05)
> >> > From: Ville Syrjälä 
> >> > 
> >> > My ILK seems to generate a spurious PCH underrun with most interlaced
> >> > HDMI modes. Add a second vblank wait to avoid it.
> >> 
> >> Fwiw, a second vblank because of interlacing is very believable.
> 
> /me .oO( could we wait for the 2nd vblank based on interlace? )

We certainly could. However as explained below we have seen some
similar looking underruns in CI with progressive DP as well, and so
I chose to try the shotgun approach in the hopes of hitting a few
more barn doors.

> 
> >>  
> >> > We have seen some spurious PCH underruns still in CI as well, some
> >> > of which seem to be progressive DP. The logs also point towards some
> >> > spurious underrins with progressive HDMI on SNB. While I don't have
> >> > a solid explanation for those let's try to kill all the birds with one
> >> > stone and always do the double wait.
> >> > 
> >> > Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106387
> >> > Signed-off-by: Ville Syrjälä 
> >> Acked-by: Chris Wilson a
> >
> > Thanks. Pushed to dinq.
> >
> >> 
> >> No point waiting for a vblank worker? ;)
> >
> > That might take a while. Also I'm not sure we'd want to use it here
> > because we'd probably want underrun reporting to be active by the
> > time we enable the planes. So we'd either have to enable planes from
> > the worker as well, or we'd just sample the vblank counter at the
> > end of crtc_enable and wait for n+2 just before we start to enable the
> > planes. Not sure if that latter approach would gain us any practical
> > parallelism though.
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Simplify ilk-ivb underrun suppression

[Ville Syrjälä]

On Fri, May 25, 2018 at 04:20:07PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-05-24 20:04:06)
> > From: Ville Syrjälä 
> > 
> > Let's suppress the underruns around every modeset sequence instead
> > of trying to avoid it. Planes are disabled at this point anyway so
> > we don't really gain anything from keeping the underrun reporting
> > enabled. Also for PCH ports we already suppress all underruns here
> > anyway so trying avoid it for the CPU eDP doesn't seem all that
> > important.
> > 
> > Maybe this gets rid of some lingering spurious underruns?
> 
> I'll bite. Isn't the reason for enabling underrung report for the
> modeset itself to detect errors in our sequence?

In theory CPU FIFO underruns shouldn't happen until we have some planes
enabled. Otherwise we have no data going through the FIFOs and thus
reporting an underrun isn't particularly sane. That doesn't stop gen2
from doing it though, but gen3+ seem to follow the more reasonable
interpretation of what a FIFO underrun means.

I suppose PCH FIFO underruns are a bit different as there is data flowing
as soon as the CPU pipe starts running, whether or not any planes have
been enabled. So those could certainly indicate some kind of programming
sequence error. Or it could just be totally expected that we start the
PCH side of the pipe first and there's a small bit of time when the CPU
pipe isn't yet pushing out pixels, and that's when the PCH side reports
the underrun.

> 
> How certain are we that these are hw limitations vs sw bugs?

To the best of my knowledge we are reasonably close to the sequence
listed in bspec. And while it's at least theoretically possible that
there's some change we could make to eliminate the underruns I don't
suppose anyone has the time or energy to try out all possible
variations.

And as long as the underrun (even if it's real) has vanished by the
time we enable the planes I think we are reasonably safe wrt. getting
the correct looking output to the user's display.

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

Re: [Intel-gfx] [PATCH v6 7/7] drm/i915: add a sysfs entry to let users set sseu configs

[Lionel Landwerlin]

On 24/05/18 11:39, Tvrtko Ursulin wrote:

--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -981,7 +981,8 @@ int i915_gem_context_setparam_ioctl(struct 
drm_device *dev, void *data,

  break;
  }
  -    if (!capable(CAP_SYS_ADMIN)) {
+    if (!dev_priv->contexts.allow_sseu &&
+    !capable(CAP_SYS_ADMIN)) {


So the thing I mentioned in the previous patch. My thinking was not 
to fail it if sysfs toggle is disabled, but just don't do dynamic 
switching. That way the software stack works in all cases but user 
has the option of tuning his system.


I mean it can still be done but in userspace. Set param fails, 
userspace goes for a fall back.


Only difference is I guess whether it is useful to allow switching 
at runtime. I am imagining running some 3d and media, and then 
toggling the knob to see what happens to power and performance on 
the fly. But maybe that is not so interesting.


Along the same lines I was thinking CAP_SYS_ADMIN limitation could 
be dropped.


Both points are for a wider discussion I guess.


Okay, let's get Dmitry input on this.


To expand, my thinking is to let media stack configure its contexts 
for fewer slices, but let the user/sysadmin decide whether 3d/compute 
performance is more important, or media.


Downside is that with this approach you would have to re-configure all 
contexts when sysfs toggle is changed from zero to one.


Right, I've updated this series locally with Tvrkto's latest comments on v7.

The issue discussed above is the last remaining detail on which some 
kind of decision needs to be taken.


Ccing Joonas who might have an input.

Cheers,

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Simplify ilk-ivb underrun suppression

[Chris Wilson]

Quoting Ville Syrjala (2018-05-24 20:04:06)
> From: Ville Syrjälä 
> 
> Let's suppress the underruns around every modeset sequence instead
> of trying to avoid it. Planes are disabled at this point anyway so
> we don't really gain anything from keeping the underrun reporting
> enabled. Also for PCH ports we already suppress all underruns here
> anyway so trying avoid it for the CPU eDP doesn't seem all that
> important.
> 
> Maybe this gets rid of some lingering spurious underruns?

I'll bite. Isn't the reason for enabling underrung report for the
modeset itself to detect errors in our sequence?

How certain are we that these are hw limitations vs sw bugs?
-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: Try to suppress more spurious PCH underruns on ILK-IVB

[Jani Nikula]

On Fri, 25 May 2018, Ville Syrjälä  wrote:
> On Thu, May 24, 2018 at 10:19:02PM +0100, Chris Wilson wrote:
>> Quoting Ville Syrjala (2018-05-24 20:04:05)
>> > From: Ville Syrjälä 
>> > 
>> > My ILK seems to generate a spurious PCH underrun with most interlaced
>> > HDMI modes. Add a second vblank wait to avoid it.
>> 
>> Fwiw, a second vblank because of interlacing is very believable.

/me .oO( could we wait for the 2nd vblank based on interlace? )

>>  
>> > We have seen some spurious PCH underruns still in CI as well, some
>> > of which seem to be progressive DP. The logs also point towards some
>> > spurious underrins with progressive HDMI on SNB. While I don't have
>> > a solid explanation for those let's try to kill all the birds with one
>> > stone and always do the double wait.
>> > 
>> > Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106387
>> > Signed-off-by: Ville Syrjälä 
>> Acked-by: Chris Wilson a
>
> Thanks. Pushed to dinq.
>
>> 
>> No point waiting for a vblank worker? ;)
>
> That might take a while. Also I'm not sure we'd want to use it here
> because we'd probably want underrun reporting to be active by the
> time we enable the planes. So we'd either have to enable planes from
> the worker as well, or we'd just sample the vblank counter at the
> end of crtc_enable and wait for n+2 just before we start to enable the
> planes. Not sure if that latter approach would gain us any practical
> parallelism though.

-- 
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] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang

[Chris Wilson]

We may not idle immediately after a hang, and indeed may send a pulse
down the pipeline periodically to become idle. Rather than make a flimsy
assumption about how long we need to sleep before the system idles,
wait for the system to declare itself idle; flushing it to idle in the
process!

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 tests/perf_pmu.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 590e6526b..9af192dd8 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2 
*e, unsigned int flags)
 
/* Check for idle after hang. */
if (flags & FLAG_HANG) {
-   /* Sleep for a bit for reset unwind to settle. */
-   usleep(500e3);
-   /*
-* Ensure batch was executing before reset, meaning it must be
-* idle by now. Unless it did not even manage to start before we
-* triggered the reset, in which case the idleness check below
-* might fail. The latter is very unlikely since there are two
-* sleeps during which it had an opportunity to start.
-*/
+   gem_quiescent_gpu(gem_fd);
igt_assert(!gem_bo_busy(gem_fd, spin->handle));
+
val = pmu_read_single(fd);
slept = measured_usleep(batch_duration_ns / 1000);
val = pmu_read_single(fd) - val;
-- 
2.17.0

___
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: Try to suppress more spurious PCH underruns on ILK-IVB

[Ville Syrjälä]

On Thu, May 24, 2018 at 10:19:02PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-05-24 20:04:05)
> > From: Ville Syrjälä 
> > 
> > My ILK seems to generate a spurious PCH underrun with most interlaced
> > HDMI modes. Add a second vblank wait to avoid it.
> 
> Fwiw, a second vblank because of interlacing is very believable.
>  
> > We have seen some spurious PCH underruns still in CI as well, some
> > of which seem to be progressive DP. The logs also point towards some
> > spurious underrins with progressive HDMI on SNB. While I don't have
> > a solid explanation for those let's try to kill all the birds with one
> > stone and always do the double wait.
> > 
> > Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106387
> > Signed-off-by: Ville Syrjälä 
> Acked-by: Chris Wilson a

Thanks. Pushed to dinq.

> 
> No point waiting for a vblank worker? ;)

That might take a while. Also I'm not sure we'd want to use it here
because we'd probably want underrun reporting to be active by the
time we enable the planes. So we'd either have to enable planes from
the worker as well, or we'd just sample the vblank counter at the
end of crtc_enable and wait for n+2 just before we start to enable the
planes. Not sure if that latter approach would gain us any practical
parallelism though.

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

Re: [Intel-gfx] [PATCH v4 1/1] drm/i915: Consult VBT "LVDS config" bits to determine whether internal LVDS is present

[Ville Syrjälä]

On Fri, May 18, 2018 at 06:01:38PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> VBT seems to have some bits to tell us whether the internal LVDS port
> has something hooked up. In theory one might expect the VBT to not have
> a child device for the LVDS port if there's no panel hooked up, but
> in practice many VBTs still add the child device. The "LVDS config" bits
> seem more reliable though, so let's check those.
> 
> So far we've used the "LVDS config" bits to check for eDP support on
> ILK+, and disable the internal LVDS when the value is 3. That value
> is actually documented as "Both internal LVDS and SDVO LVDS", but in
> practice it looks to mean "eDP" on all the ilk+ VBTs I've seen. So let's
> keep that interpretation, but for pre-ILK we will consider the value
> 3 to also indicate the presence of the internal LVDS.
> 
> Currently we have 25 DMI matches for the "no internal LVDS" quirk. In an
> effort to reduce that let's toss in a WARN when the DMI match and VBT
> both tell us that the internal LVDS is not present. The hope is that
> people will report a bug, and then we can just nuke the corresponding
> entry from the DMI quirk list. Credits to Jani for this idea.
> 
> v2: Split the basic int_lvds_support thing to a separate patch (Jani)
> v3: Rebase
> v4: Limit this to VBT version >= 134
> 
> Cc: Jani Nikula 
> Cc: Ondrej Zary 
> Signed-off-by: Ville Syrjälä 

I picked up Jani's r-b from v3 and pushed to dinq. Let's see how badly
I'll end up regretting this one...

> ---
>  drivers/gpu/drm/i915/intel_bios.c | 28 +---
>  drivers/gpu/drm/i915/intel_lvds.c |  5 -
>  drivers/gpu/drm/i915/intel_vbt_defs.h |  2 +-
>  3 files changed, 30 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 5c863e2714ec..26b59118ef7b 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -518,9 +518,31 @@ parse_driver_features(struct drm_i915_private *dev_priv,
>   if (!driver)
>   return;
>  
> - if (INTEL_GEN(dev_priv) >= 5 &&
> - driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
> - dev_priv->vbt.int_lvds_support = 0;
> + if (INTEL_GEN(dev_priv) >= 5) {
> + /*
> +  * Note that we consider BDB_DRIVER_FEATURE_INT_SDVO_LVDS
> +  * to mean "eDP". The VBT spec doesn't agree with that
> +  * interpretation, but real world VBTs seem to.
> +  */
> + if (driver->lvds_config != BDB_DRIVER_FEATURE_INT_LVDS)
> + dev_priv->vbt.int_lvds_support = 0;
> + } else {
> + /*
> +  * FIXME it's not clear which BDB version has the LVDS config
> +  * bits defined. Revision history in the VBT spec says:
> +  * "0.92 | Add two definitions for VBT value of LVDS Active
> +  *  Config (00b and 11b values defined) | 06/13/2005"
> +  * but does not the specify the BDB version.
> +  *
> +  * So far version 134 (on i945gm) is the oldest VBT observed
> +  * in the wild with the bits correctly populated. Version
> +  * 108 (on i85x) does not have the bits correctly populated.
> +  */
> + if (bdb->version >= 134 &&
> + driver->lvds_config != BDB_DRIVER_FEATURE_INT_LVDS &&
> + driver->lvds_config != BDB_DRIVER_FEATURE_INT_SDVO_LVDS)
> + dev_priv->vbt.int_lvds_support = 0;
> + }
>  
>   DRM_DEBUG_KMS("DRRS State Enabled:%d\n", driver->drrs_enabled);
>   /*
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
> b/drivers/gpu/drm/i915/intel_lvds.c
> index cda46bfa7041..a78d2b181819 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -973,8 +973,11 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
>   return;
>  
>   /* Skip init on machines we know falsely report LVDS */
> - if (dmi_check_system(intel_no_lvds))
> + if (dmi_check_system(intel_no_lvds)) {
> + WARN(!dev_priv->vbt.int_lvds_support,
> +  "Useless DMI match. Internal LVDS support disabled by 
> VBT\n");
>   return;
> + }
>  
>   if (!dev_priv->vbt.int_lvds_support) {
>   DRM_DEBUG_KMS("Internal LVDS support disabled by VBT\n");
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index 458468237b5f..39c804624179 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -635,7 +635,7 @@ struct bdb_sdvo_lvds_options {
>  #define BDB_DRIVER_FEATURE_NO_LVDS   0
>  #define BDB_DRIVER_FEATURE_INT_LVDS  1
>  #define BDB_DRIVER_FEATURE_SDVO_LVDS 2

[Intel-gfx] [PATCH] drm/i915: Remove stale asserts from i915_gem_find_active_request()

[Chris Wilson]

Since we use i915_gem_find_active_request() from inside
intel_engine_dump() and may call that at any time, we do not guarantee
that the engine is paused nor that the signal kthreads and irq handler
are suspended, so we cannot assert that the breadcrumb doesn't advance
and that the irq hasn't happened on another CPU signaling the request we
believe to be idle.

Fixes: f636edb214a5 ("drm/i915: Make i915_engine_info pretty printer to 
standalone")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 05f44ca35a06..530d6d0109b4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2972,23 +2972,22 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine)
struct i915_request *request, *active = NULL;
unsigned long flags;
 
-   /* We are called by the error capture and reset at a random
-* point in time. In particular, note that neither is crucially
-* ordered with an interrupt. After a hang, the GPU is dead and we
-* assume that no more writes can happen (we waited long enough for
-* all writes that were in transaction to be flushed) - adding an
+   /*
+* We are called by the error capture, reset and to dump engine
+* state at random points in time. In particular, note that neither is
+* crucially ordered with an interrupt. After a hang, the GPU is dead
+* and we assume that no more writes can happen (we waited long enough
+* for all writes that were in transaction to be flushed) - adding an
 * extra delay for a recent interrupt is pointless. Hence, we do
 * not need an engine->irq_seqno_barrier() before the seqno reads.
+* At all other times, we must assume the GPU is still running, but
+* we only care about the snapshot of this moment.
 */
spin_lock_irqsave(>timeline.lock, flags);
list_for_each_entry(request, >timeline.requests, link) {
if (__i915_request_completed(request, request->global_seqno))
continue;
 
-   GEM_BUG_ON(request->engine != engine);
-   GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
-   >fence.flags));
-
active = request;
break;
}
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH] drm/edid: Fix up edid_cea_modes[] formatting

[Ville Syrjälä]

On Fri, May 25, 2018 at 10:21:20AM -0400, Alex Deucher wrote:
> On Thu, May 24, 2018 at 3:20 PM, Ville Syrjala
>  wrote:
> > From: Ville Syrjälä 
> >
> > Fix up a bunch of bad indentation and insconsistent comments
> 
> inconsistent

Dang. Pulled the trigger on dim mere seconds before seeing your
reply :( But thanks for the review anyway.

> 
> With that fixed:
> Reviewed-by: Alex Deucher 
> 
> > in edid_cea_modes[].
> >
> > v2: Instead of stripping the aspect ratio comments let's
> > add them to all modes
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 268 
> > ++---
> >  1 file changed, 134 insertions(+), 134 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 82f1ab09169d..634a68a03b07 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -687,562 +687,562 @@ static const struct minimode extra_modes[] = {
> >  static const struct drm_display_mode edid_cea_modes[] = {
> > /* 0 - dummy, VICs start at 1 */
> > { },
> > -   /* 1 - 640x480@60Hz */
> > +   /* 1 - 640x480@60Hz 4:3 */
> > { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
> >752, 800, 0, 480, 490, 492, 525, 0,
> >DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
> >   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, 
> > },
> > -   /* 2 - 720x480@60Hz */
> > +   /* 2 - 720x480@60Hz 4:3 */
> > { DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 27000, 720, 736,
> >798, 858, 0, 480, 489, 495, 525, 0,
> >DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
> >   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, 
> > },
> > -   /* 3 - 720x480@60Hz */
> > +   /* 3 - 720x480@60Hz 16:9 */
> > { DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 27000, 720, 736,
> >798, 858, 0, 480, 489, 495, 525, 0,
> >DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
> >   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, 
> > },
> > -   /* 4 - 1280x720@60Hz */
> > +   /* 4 - 1280x720@60Hz 16:9 */
> > { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> >1430, 1650, 0, 720, 725, 730, 750, 0,
> >DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, 
> > },
> > -   /* 5 - 1920x1080i@60Hz */
> > +   /* 5 - 1920x1080i@60Hz 16:9 */
> > { DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
> >2052, 2200, 0, 1080, 1084, 1094, 1125, 0,
> >DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
> > -   DRM_MODE_FLAG_INTERLACE),
> > +  DRM_MODE_FLAG_INTERLACE),
> >   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, 
> > },
> > -   /* 6 - 720(1440)x480i@60Hz */
> > +   /* 6 - 720(1440)x480i@60Hz 4:3 */
> > { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> >801, 858, 0, 480, 488, 494, 525, 0,
> >DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> > -   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> > +  DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> >   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, 
> > },
> > -   /* 7 - 720(1440)x480i@60Hz */
> > +   /* 7 - 720(1440)x480i@60Hz 16:9 */
> > { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> >801, 858, 0, 480, 488, 494, 525, 0,
> >DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> > -   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> > +  DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> >   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, 
> > },
> > -   /* 8 - 720(1440)x240@60Hz */
> > +   /* 8 - 720(1440)x240@60Hz 4:3 */
> > { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> >801, 858, 0, 240, 244, 247, 262, 0,
> >DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> > -   DRM_MODE_FLAG_DBLCLK),
> > +  DRM_MODE_FLAG_DBLCLK),
> >   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, 
> > },
> > -   /* 9 - 720(1440)x240@60Hz */
> > +   /* 9 - 720(1440)x240@60Hz 16:9 */
> > { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
> >801, 858, 0, 240, 244, 247, 262, 0,
> >DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> > -   

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/18] drm/i915: Prepare GEM for suspend earlier

[Patchwork]

== Series Details ==

Series: series starting with [01/18] drm/i915: Prepare GEM for suspend earlier
URL   : https://patchwork.freedesktop.org/series/43765/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4238_full -> Patchwork_9120_full =

== Summary - FAILURE ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43765/revisions/1/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@perf_pmu@busy-hang-rcs0:
  shard-kbl:  PASS -> FAIL
  shard-apl:  PASS -> FAIL
  shard-glk:  PASS -> FAIL


 Warnings 

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS

igt@kms_mmap_write_crc:
  shard-snb:  PASS -> SKIP +1


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  shard-glk:  PASS -> DMESG-FAIL (fdo#106560)

igt@gem_eio@suspend:
  shard-snb:  PASS -> INCOMPLETE (fdo#105411) +1

igt@gem_workarounds@suspend-resume:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665) +4

igt@kms_flip@2x-plain-flip-fb-recreate:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  PASS -> FAIL (fdo#105707)

igt@kms_flip_tiling@flip-to-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#103822, fdo#104724) +1

igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-msflip-blt:
  shard-glk:  PASS -> FAIL (fdo#103167, fdo#104724)


 Possible fixes 

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
  shard-glk:  FAIL (fdo#105703) -> PASS


 Warnings 

igt@gem_exec_schedule@pi-ringfull-bsd1:
  shard-kbl:  FAIL (fdo#103158) -> INCOMPLETE (fdo#103665)


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4238 -> Patchwork_9120

  CI_DRM_4238: 2771a5e6347eb63e43fdfc432a9f15ffb55ef209 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9120: 66703c7b803c782443434c0c3dc479870dce7df9 @ 
git://anongit.freedesktop.org/gfx-ci/linux

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/edid: Fix up edid_cea_modes[] formatting

[Alex Deucher]

On Thu, May 24, 2018 at 3:20 PM, Ville Syrjala
 wrote:
> From: Ville Syrjälä 
>
> Fix up a bunch of bad indentation and insconsistent comments

inconsistent

With that fixed:
Reviewed-by: Alex Deucher 

> in edid_cea_modes[].
>
> v2: Instead of stripping the aspect ratio comments let's
> add them to all modes
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_edid.c | 268 
> ++---
>  1 file changed, 134 insertions(+), 134 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 82f1ab09169d..634a68a03b07 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -687,562 +687,562 @@ static const struct minimode extra_modes[] = {
>  static const struct drm_display_mode edid_cea_modes[] = {
> /* 0 - dummy, VICs start at 1 */
> { },
> -   /* 1 - 640x480@60Hz */
> +   /* 1 - 640x480@60Hz 4:3 */
> { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
>752, 800, 0, 480, 490, 492, 525, 0,
>DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
>   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> -   /* 2 - 720x480@60Hz */
> +   /* 2 - 720x480@60Hz 4:3 */
> { DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 27000, 720, 736,
>798, 858, 0, 480, 489, 495, 525, 0,
>DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
>   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> -   /* 3 - 720x480@60Hz */
> +   /* 3 - 720x480@60Hz 16:9 */
> { DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 27000, 720, 736,
>798, 858, 0, 480, 489, 495, 525, 0,
>DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
>   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> -   /* 4 - 1280x720@60Hz */
> +   /* 4 - 1280x720@60Hz 16:9 */
> { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
>1430, 1650, 0, 720, 725, 730, 750, 0,
>DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> -   /* 5 - 1920x1080i@60Hz */
> +   /* 5 - 1920x1080i@60Hz 16:9 */
> { DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
>2052, 2200, 0, 1080, 1084, 1094, 1125, 0,
>DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
> -   DRM_MODE_FLAG_INTERLACE),
> +  DRM_MODE_FLAG_INTERLACE),
>   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> -   /* 6 - 720(1440)x480i@60Hz */
> +   /* 6 - 720(1440)x480i@60Hz 4:3 */
> { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
>801, 858, 0, 480, 488, 494, 525, 0,
>DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> -   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> +  DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
>   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> -   /* 7 - 720(1440)x480i@60Hz */
> +   /* 7 - 720(1440)x480i@60Hz 16:9 */
> { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
>801, 858, 0, 480, 488, 494, 525, 0,
>DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> -   DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> +  DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
>   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> -   /* 8 - 720(1440)x240@60Hz */
> +   /* 8 - 720(1440)x240@60Hz 4:3 */
> { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
>801, 858, 0, 240, 244, 247, 262, 0,
>DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> -   DRM_MODE_FLAG_DBLCLK),
> +  DRM_MODE_FLAG_DBLCLK),
>   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> -   /* 9 - 720(1440)x240@60Hz */
> +   /* 9 - 720(1440)x240@60Hz 16:9 */
> { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
>801, 858, 0, 240, 244, 247, 262, 0,
>DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> -   DRM_MODE_FLAG_DBLCLK),
> +  DRM_MODE_FLAG_DBLCLK),
>   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> -   /* 10 - 2880x480i@60Hz */
> +   /* 10 - 2880x480i@60Hz 4:3 */
> { DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
>3204, 3432, 0, 480, 488, 494, 525, 0,
>

Re: [Intel-gfx] [PATCH] drm/i915: Prepare GEM for suspend earlier

[Chris Wilson]

Quoting Ville Syrjälä (2018-05-25 11:51:13)
> On Fri, May 25, 2018 at 10:26:29AM +0100, Chris Wilson wrote:
> > In order to prepare the GPU for sleeping, we may want to submit commands
> > to it. This is a complicated process that may even require some swapping
> > in from shmemfs, if the GPU was in the wrong state. As such, we need to
> > do this preparation step synchronously before the rest of the system has
> > started to turn off (e.g. swapin fails if scsi is suspended).
> > Fortunately, we are provided with a such a hook, pm_ops.prepare().
> > 
> > v2: Compile cleanup
> > v3: Fewer asserts, fewer problems?
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106640
> > Testcase: igt/drv_suspend after igt/gem_tiled_swapping
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 41 +
> >  1 file changed, 31 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 9c449b8d8eab..9d6ac7f44812 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1553,12 +1553,24 @@ static bool suspend_to_idle(struct drm_i915_private 
> > *dev_priv)
> >   return false;
> >  }
> >  
> > +static int i915_drm_prepare(struct drm_device *dev)
> > +{
> > + struct drm_i915_private *i915 = to_i915(dev);
> > + int err;
> > +
> > + err = i915_gem_suspend(i915);
> > + if (err)
> > + dev_err(>drm.pdev->dev,
> > + "GEM idle failed, suspend/resume might fail\n");
> > +
> > + return err;
> > +}
> > +
> >  static int i915_drm_suspend(struct drm_device *dev)
> >  {
> >   struct drm_i915_private *dev_priv = to_i915(dev);
> >   struct pci_dev *pdev = dev_priv->drm.pdev;
> >   pci_power_t opregion_target_state;
> > - int error;
> >  
> >   /* ignore lid events during suspend */
> >   mutex_lock(_priv->modeset_restore_lock);
> > @@ -1575,13 +1587,6 @@ static int i915_drm_suspend(struct drm_device *dev)
> >  
> >   pci_save_state(pdev);
> >  
> > - error = i915_gem_suspend(dev_priv);
> > - if (error) {
> > - dev_err(>dev,
> > - "GEM idle failed, resume might fail\n");
> > - goto out;
> > - }
> > -
> >   intel_display_suspend(dev);
> >  
> >   intel_dp_mst_suspend(dev);
> > @@ -1609,10 +1614,9 @@ static int i915_drm_suspend(struct drm_device *dev)
> >  
> >   intel_csr_ucode_suspend(dev_priv);
> >  
> > -out:
> >   enable_rpm_wakeref_asserts(dev_priv);
> >  
> > - return error;
> > + return 0;
> >  }
> >  
> >  static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation)
> > @@ -2081,6 +2085,22 @@ int i915_reset_engine(struct intel_engine_cs 
> > *engine, const char *msg)
> >   return ret;
> >  }
> >  
> > +static int i915_pm_prepare(struct device *kdev)
> > +{
> > + struct pci_dev *pdev = to_pci_dev(kdev);
> > + struct drm_device *dev = pci_get_drvdata(pdev);
> > +
> > + if (!dev) {
> > + dev_err(kdev, "DRM not initialized, aborting suspend.\n");
> > + return -ENODEV;
> > + }
> 
> How can this happen?
> 
> IIRC I actually wrote a patch once to move the gem suspend to happen
> after display suspend. The idea being that shutting down the display(s)
> may require gem services (MI_OVERLAY_OFF being the prime example I
> had in mind at the time). Just wondering if we can split the gem suspend
> somehow to allow that, or would we need to just move display suspend
> earlier as well?

Ville accepted that this didn't really change the status quo (on irc)
and so was ok with postponing such fixes until later. I added
+   /*
+* NB intel_display_suspend() may issue new requests after we've
+* ostensibly marked the GPU as ready-to-sleep here. We need to
+* split out that work and pull it forward so that after point,
+* the GPU is not woken again.
+*/
to record the issue so that hopefully we might fix it before any one
notices.

I pulled in Mika's review from a later thread and pushed so I can close
the bug.

Thanks for the review,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/18] drm/i915: Switch to kernel context before idling at runtime

[Mika Kuoppala]

Chris Wilson  writes:

> We can reduce our exposure to random neutrinos by resting on the kernel
> context having flushed out the user contexts to system memory and
> beyond. The corollary is that we then we require two passes through the
> idle handler to go to sleep, which on a truly idle system involves an
> extra pass through the slow and irregular retire work handler.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  7 +--
>  drivers/gpu/drm/i915/i915_gem.c | 29 -
>  2 files changed, 29 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a8e7761cdc7d..0fb86a8ef192 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4226,8 +4226,11 @@ i915_drop_caches_set(void *data, u64 val)
>   i915_gem_shrink_all(dev_priv);
>   fs_reclaim_release(GFP_KERNEL);
>  
> - if (val & DROP_IDLE)
> - drain_delayed_work(_priv->gt.idle_work);
> + if (val & DROP_IDLE) {
> + do {
> + drain_delayed_work(_priv->gt.idle_work);
> + } while (READ_ONCE(dev_priv->gt.awake));
> + }

Should we do this on suspend path also? Perhaps better
just to warn there, like we do, and let it slide.

>  
>   if (val & DROP_FREED)
>   i915_gem_drain_freed_objects(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 05f44ca35a06..c93f5dcb1d82 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -139,6 +139,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
>  
>  static u32 __i915_gem_park(struct drm_i915_private *i915)
>  {
> + GEM_TRACE("\n");
> +
>   lockdep_assert_held(>drm.struct_mutex);
>   GEM_BUG_ON(i915->gt.active_requests);
>   GEM_BUG_ON(!list_empty(>gt.active_rings));
> @@ -193,6 +195,8 @@ void i915_gem_park(struct drm_i915_private *i915)
>  
>  void i915_gem_unpark(struct drm_i915_private *i915)
>  {
> + GEM_TRACE("\n");
> +
>   lockdep_assert_held(>drm.struct_mutex);
>   GEM_BUG_ON(!i915->gt.active_requests);
>  
> @@ -3504,6 +3508,21 @@ i915_gem_idle_work_handler(struct work_struct *work)
>   if (!READ_ONCE(dev_priv->gt.awake))
>   return;
>  
> + /*
> +  * Flush out the last user context, leaving only the pinned
> +  * kernel context resident. When we are idling on the kernel_context,
> +  * no more new requests (with a context switch) are emitted and we
> +  * can finally rest. A consequence is that the idle work handler is
> +  * always called at least twice before idling (and if the system is
> +  * idle that implies a round trip through the retire worker).
> +  */

We keep gt awake a little longer and inject somtimes 'useless'
switch to kernel ctx.

It is acceptable price to pay for a sound bed to sleep on.

Reviewed-by: Mika Kuoppala 

> + mutex_lock(_priv->drm.struct_mutex);
> + i915_gem_switch_to_kernel_context(dev_priv);
> + mutex_unlock(_priv->drm.struct_mutex);
> +
> + GEM_TRACE("active_requests=%d (after switch-to-kernel-context)\n",
> +   READ_ONCE(dev_priv->gt.active_requests));
> +
>   /*
>* Wait for last execlists context complete, but bail out in case a
>* new request is submitted. As we don't trust the hardware, we
> @@ -4914,11 +4933,9 @@ static void assert_kernel_context_is_current(struct 
> drm_i915_private *i915)
>  
>  void i915_gem_sanitize(struct drm_i915_private *i915)
>  {
> - if (i915_terminally_wedged(>gpu_error)) {
> - mutex_lock(>drm.struct_mutex);
> + mutex_lock(>drm.struct_mutex);
> + if (i915_terminally_wedged(>gpu_error))
>   i915_gem_unset_wedged(i915);
> - mutex_unlock(>drm.struct_mutex);
> - }
>  
>   /*
>* If we inherit context state from the BIOS or earlier occupants
> @@ -4930,6 +4947,9 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
>*/
>   if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
>   WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
> +
> + i915_gem_contexts_lost(i915);
> + mutex_unlock(>drm.struct_mutex);
>  }
>  
>  int i915_gem_suspend(struct drm_i915_private *dev_priv)
> @@ -4965,7 +4985,6 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
>  
>   assert_kernel_context_is_current(dev_priv);
>   }
> - i915_gem_contexts_lost(dev_priv);
>   mutex_unlock(>struct_mutex);
>  
>   intel_uc_suspend(dev_priv);
> -- 
> 2.17.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Prepare GEM for suspend earlier (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: Prepare GEM for suspend earlier (rev5)
URL   : https://patchwork.freedesktop.org/series/43575/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4238_full -> Patchwork_9119_full =

== Summary - WARNING ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43575/revisions/5/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-blt:
  shard-kbl:  PASS -> SKIP +1

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS +1


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
  shard-glk:  PASS -> FAIL (fdo#105703)

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  PASS -> FAIL (fdo#105707)

igt@kms_flip@wf_vblank-ts-check:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@perf@blocking:
  shard-hsw:  PASS -> FAIL (fdo#102252)


 Possible fixes 

igt@drv_selftest@live_gtt:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  INCOMPLETE (fdo#103665, fdo#106023) -> PASS

igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
  shard-glk:  FAIL (fdo#105703) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4238 -> Patchwork_9119

  CI_DRM_4238: 2771a5e6347eb63e43fdfc432a9f15ffb55ef209 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9119: 7dcc0ef687ea40de696bf00d3f8976e2a903ed6f @ 
git://anongit.freedesktop.org/gfx-ci/linux

== Logs ==

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

Re: [Intel-gfx] [PATCH 04/18] drm/i915: After reset on sanitization, reset the engine backends

[Mika Kuoppala]

Chris Wilson  writes:

> Quoting Mika Kuoppala (2018-05-25 14:13:19)
>> Chris Wilson  writes:
>> 
>> > As we reset the GPU on suspend/resume, we also do need to reset the
>> > engine state tracking so call into the engine backends. This is
>> > especially important so that we can also sanitize the state tracking
>> > across resume.
>> >
>> > Signed-off-by: Chris Wilson 
>> > ---
>> >  drivers/gpu/drm/i915/i915_gem.c | 24 
>> >  1 file changed, 24 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>> > b/drivers/gpu/drm/i915/i915_gem.c
>> > index 7b5544efa0ba..5a7e0b388ad0 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem.c
>> > @@ -4955,7 +4955,22 @@ static void assert_kernel_context_is_current(struct 
>> > drm_i915_private *i915)
>> >  
>> >  void i915_gem_sanitize(struct drm_i915_private *i915)
>> >  {
>> > + struct intel_engine_cs *engine;
>> > + enum intel_engine_id id;
>> > +
>> > + GEM_TRACE("\n");
>> > +
>> >   mutex_lock(>drm.struct_mutex);
>> > +
>> > + intel_runtime_pm_get(i915);
>> > + intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
>> > +
>> > + /*
>> > +  * As we have just resumed the machine and woken the device up from
>> > +  * deep PCI sleep (presumably D3_cold), assume the HW has been reset
>> > +  * back to defaults, recovering from whatever wedged state we left it
>> > +  * in and so worth trying to use the device once more.
>> > +  */
>> >   if (i915_terminally_wedged(>gpu_error))
>> >   i915_gem_unset_wedged(i915);
>> >  
>> > @@ -4970,6 +4985,15 @@ void i915_gem_sanitize(struct drm_i915_private 
>> > *i915)
>> >   if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
>> >   WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
>> >  
>> > + /* Reset the submission backend after resume as well as the GPU 
>> > reset */
>> > + for_each_engine(engine, i915, id) {
>> > + if (engine->reset.reset)
>> > + engine->reset.reset(engine, NULL);
>> > + }
>> 
>> The NULL guarantees that it wont try to do any funny things
>> with the incomplete state.
>
> The NULL is there because this gets called really, really early before
> we've finished setting up the engines.
>
>> But what guarantees the the timeline cleanup so that
>> we don't endup unwinding incomplete requests crap?
>
> To get here we must have gone through at least the start of a suspend.
> So we've already cleaned everything up; nicely or forcefully though a
> wedge. Whatever is here is garbage, including any internal knowledge in
> the backend about what state we left the machine in.

Fair enough,

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

Re: [Intel-gfx] [PATCH 04/18] drm/i915: After reset on sanitization, reset the engine backends

[Chris Wilson]

Quoting Mika Kuoppala (2018-05-25 14:13:19)
> Chris Wilson  writes:
> 
> > As we reset the GPU on suspend/resume, we also do need to reset the
> > engine state tracking so call into the engine backends. This is
> > especially important so that we can also sanitize the state tracking
> > across resume.
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 24 
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 7b5544efa0ba..5a7e0b388ad0 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4955,7 +4955,22 @@ static void assert_kernel_context_is_current(struct 
> > drm_i915_private *i915)
> >  
> >  void i915_gem_sanitize(struct drm_i915_private *i915)
> >  {
> > + struct intel_engine_cs *engine;
> > + enum intel_engine_id id;
> > +
> > + GEM_TRACE("\n");
> > +
> >   mutex_lock(>drm.struct_mutex);
> > +
> > + intel_runtime_pm_get(i915);
> > + intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
> > +
> > + /*
> > +  * As we have just resumed the machine and woken the device up from
> > +  * deep PCI sleep (presumably D3_cold), assume the HW has been reset
> > +  * back to defaults, recovering from whatever wedged state we left it
> > +  * in and so worth trying to use the device once more.
> > +  */
> >   if (i915_terminally_wedged(>gpu_error))
> >   i915_gem_unset_wedged(i915);
> >  
> > @@ -4970,6 +4985,15 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
> >   if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
> >   WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
> >  
> > + /* Reset the submission backend after resume as well as the GPU reset 
> > */
> > + for_each_engine(engine, i915, id) {
> > + if (engine->reset.reset)
> > + engine->reset.reset(engine, NULL);
> > + }
> 
> The NULL guarantees that it wont try to do any funny things
> with the incomplete state.

The NULL is there because this gets called really, really early before
we've finished setting up the engines.

> But what guarantees the the timeline cleanup so that
> we don't endup unwinding incomplete requests crap?

To get here we must have gone through at least the start of a suspend.
So we've already cleaned everything up; nicely or forcefully though a
wedge. Whatever is here is garbage, including any internal knowledge in
the backend about what state we left the machine in.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/18] drm/i915: After reset on sanitization, reset the engine backends

[Mika Kuoppala]

Chris Wilson  writes:

> As we reset the GPU on suspend/resume, we also do need to reset the
> engine state tracking so call into the engine backends. This is
> especially important so that we can also sanitize the state tracking
> across resume.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7b5544efa0ba..5a7e0b388ad0 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4955,7 +4955,22 @@ static void assert_kernel_context_is_current(struct 
> drm_i915_private *i915)
>  
>  void i915_gem_sanitize(struct drm_i915_private *i915)
>  {
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> +
> + GEM_TRACE("\n");
> +
>   mutex_lock(>drm.struct_mutex);
> +
> + intel_runtime_pm_get(i915);
> + intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
> +
> + /*
> +  * As we have just resumed the machine and woken the device up from
> +  * deep PCI sleep (presumably D3_cold), assume the HW has been reset
> +  * back to defaults, recovering from whatever wedged state we left it
> +  * in and so worth trying to use the device once more.
> +  */
>   if (i915_terminally_wedged(>gpu_error))
>   i915_gem_unset_wedged(i915);
>  
> @@ -4970,6 +4985,15 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
>   if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
>   WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
>  
> + /* Reset the submission backend after resume as well as the GPU reset */
> + for_each_engine(engine, i915, id) {
> + if (engine->reset.reset)
> + engine->reset.reset(engine, NULL);
> + }

The NULL guarantees that it wont try to do any funny things
with the incomplete state.

But what guarantees the the timeline cleanup so that
we don't endup unwinding incomplete requests crap?
-Mika

> +
> + intel_uncore_forcewake_put(i915, FORCEWAKE_ALL);
> + intel_runtime_pm_put(i915);
> +
>   i915_gem_contexts_lost(i915);
>   mutex_unlock(>drm.struct_mutex);
>  }
> -- 
> 2.17.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/18] drm/i915: Prepare GEM for suspend earlier

[Mika Kuoppala]

Chris Wilson  writes:

> In order to prepare the GPU for sleeping, we may want to submit commands
> to it. This is a complicated process that may even require some swapping
> in from shmemfs, if the GPU was in the wrong state. As such, we need to
> do this preparation step synchronously before the rest of the system has
> started to turn off (e.g. swapin fails if scsi is suspended).
> Fortunately, we are provided with a such a hook, pm_ops.prepare().
>
> v2: Compile cleanup
> v3: Fewer asserts, fewer problems?
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106640
> Testcase: igt/drv_suspend after igt/gem_tiled_swapping
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 41 +
>  1 file changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9c449b8d8eab..9d6ac7f44812 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1553,12 +1553,24 @@ static bool suspend_to_idle(struct drm_i915_private 
> *dev_priv)
>   return false;
>  }
>  
> +static int i915_drm_prepare(struct drm_device *dev)
> +{
> + struct drm_i915_private *i915 = to_i915(dev);
> + int err;
> +
> + err = i915_gem_suspend(i915);
> + if (err)
> + dev_err(>drm.pdev->dev,
> + "GEM idle failed, suspend/resume might fail\n");
> +
> + return err;
> +}
> +
>  static int i915_drm_suspend(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct pci_dev *pdev = dev_priv->drm.pdev;
>   pci_power_t opregion_target_state;
> - int error;
>  
>   /* ignore lid events during suspend */
>   mutex_lock(_priv->modeset_restore_lock);
> @@ -1575,13 +1587,6 @@ static int i915_drm_suspend(struct drm_device *dev)
>  
>   pci_save_state(pdev);
>  
> - error = i915_gem_suspend(dev_priv);
> - if (error) {
> - dev_err(>dev,
> - "GEM idle failed, resume might fail\n");
> - goto out;
> - }
> -
>   intel_display_suspend(dev);
>  
>   intel_dp_mst_suspend(dev);
> @@ -1609,10 +1614,9 @@ static int i915_drm_suspend(struct drm_device *dev)
>  
>   intel_csr_ucode_suspend(dev_priv);
>  
> -out:
>   enable_rpm_wakeref_asserts(dev_priv);
>  
> - return error;
> + return 0;
>  }
>  
>  static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation)
> @@ -2081,6 +2085,22 @@ int i915_reset_engine(struct intel_engine_cs *engine, 
> const char *msg)
>   return ret;
>  }
>  
> +static int i915_pm_prepare(struct device *kdev)
> +{
> + struct pci_dev *pdev = to_pci_dev(kdev);
> + struct drm_device *dev = pci_get_drvdata(pdev);
> +
> + if (!dev) {
> + dev_err(kdev, "DRM not initialized, aborting suspend.\n");
> + return -ENODEV;
> + }
> +
> + if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
> + return 0;
> +
> + return i915_drm_prepare(dev);
> +}
> +
>  static int i915_pm_suspend(struct device *kdev)
>  {
>   struct pci_dev *pdev = to_pci_dev(kdev);
> @@ -2731,6 +2751,7 @@ const struct dev_pm_ops i915_pm_ops = {
>* S0ix (via system suspend) and S3 event handlers [PMSG_SUSPEND,
>* PMSG_RESUME]
>*/
> + .prepare = i915_pm_prepare,
>   .suspend = i915_pm_suspend,
>   .suspend_late = i915_pm_suspend_late,
>   .resume_early = i915_pm_resume_early,
> -- 
> 2.17.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/trace: Describe engines as class:instance pairs

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915/trace: Describe engines as 
class:instance pairs
URL   : https://patchwork.freedesktop.org/series/43763/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4238_full -> Patchwork_9117_full =

== Summary - WARNING ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43763/revisions/1/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-dirty-render:
  shard-kbl:  SKIP -> PASS +1

igt@gem_mocs_settings@mocs-rc6-render:
  shard-kbl:  PASS -> SKIP


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_gtt:
  shard-glk:  PASS -> INCOMPLETE (fdo#103359, k.org#198133)

igt@drv_selftest@live_hangcheck:
  shard-kbl:  NOTRUN -> DMESG-FAIL (fdo#106560)

igt@gem_workarounds@suspend-resume:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@kms_flip_tiling@flip-to-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#103822, fdo#104724)

igt@kms_flip_tiling@flip-y-tiled:
  shard-glk:  PASS -> FAIL (fdo#104724)

igt@pm_rps@waitboost:
  shard-apl:  PASS -> FAIL (fdo#102250)


 Possible fixes 

igt@drv_selftest@live_hangcheck:
  shard-apl:  DMESG-FAIL (fdo#106560) -> PASS

igt@gem_ctx_isolation@bcs0-s3:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS +1

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  INCOMPLETE (fdo#103665, fdo#106023) -> PASS

igt@kms_flip_tiling@flip-x-tiled:
  shard-glk:  FAIL (fdo#103822, fdo#104724) -> PASS


  fdo#102250 https://bugs.freedesktop.org/show_bug.cgi?id=102250
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4238 -> Patchwork_9117

  CI_DRM_4238: 2771a5e6347eb63e43fdfc432a9f15ffb55ef209 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9117: c4abefa00271bb29045a20fee8839cef5bbd0fe2 @ 
git://anongit.freedesktop.org/gfx-ci/linux

== Logs ==

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-05-25 09:36:18)
> 
> On 24/05/2018 14:40, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-24 14:34:41)
> >>
> >> On 19/05/2018 10:04, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-05-18 15:42:00)
> 
>  On 18/05/2018 15:13, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-18 13:36:52)
> >>
> >> On 18/05/2018 13:28, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-05-18 12:50:41)
> 
>  On 18/05/2018 12:10, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-18 12:05:17)
> >>
> >> On 18/05/2018 11:09, Chris Wilson wrote:
> >>> Inside the live_hangcheck (reset) selftests, we occasionally see
> >>> failures like
> >>>
> >>> <7>[  239.094840] i915_gem_set_wedged rcs0
> >>> <7>[  239.094843] i915_gem_set_wedged current seqno 
> >>> 19a98, last 19a9a, hangcheck 0 [5158 ms]
> >>> <7>[  239.094846] i915_gem_set_wedged Reset count: 6239 
> >>> (global 1)
> >>> <7>[  239.094848] i915_gem_set_wedged Requests:
> >>> <7>[  239.095052] i915_gem_set_wedged first  
> >>> 19a99 [e8c:5f] prio=1024 @ 5159ms: (null)
> >>> <7>[  239.095056] i915_gem_set_wedged last   
> >>> 19a9a [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1
> >>> <7>[  239.095059] i915_gem_set_wedged active 
> >>> 19a99 [e8c:5f] prio=1024 @ 5159ms: (null)
> >>> <7>[  239.095062] i915_gem_set_wedged [head 0220, 
> >>> postfix 0280, tail 02a8, batch 0x_]
> >>> <7>[  239.100050] i915_gem_set_wedged 
> >>> ring->start:  0x00283000
> >>> <7>[  239.100053] i915_gem_set_wedged ring->head: 
> >>>   0x01f8
> >>> <7>[  239.100055] i915_gem_set_wedged ring->tail: 
> >>>   0x02a8
> >>> <7>[  239.100057] i915_gem_set_wedged ring->emit: 
> >>>   0x02a8
> >>> <7>[  239.100059] i915_gem_set_wedged 
> >>> ring->space:  0x0f10
> >>> <7>[  239.100085] i915_gem_set_wedged RING_START: 
> >>> 0x00283000
> >>> <7>[  239.100088] i915_gem_set_wedged RING_HEAD:  
> >>> 0x0260
> >>> <7>[  239.100091] i915_gem_set_wedged RING_TAIL:  
> >>> 0x02a8
> >>> <7>[  239.100094] i915_gem_set_wedged RING_CTL:   
> >>> 0x0001
> >>> <7>[  239.100097] i915_gem_set_wedged RING_MODE:  
> >>> 0x0300 [idle]
> >>> <7>[  239.100100] i915_gem_set_wedged RING_IMR: fefe
> >>> <7>[  239.100104] i915_gem_set_wedged ACTHD:  
> >>> 0x_609c
> >>> <7>[  239.100108] i915_gem_set_wedged BBADDR: 
> >>> 0x_609d
> >>> <7>[  239.100111] i915_gem_set_wedged DMA_FADDR: 
> >>> 0x_00283260
> >>> <7>[  239.100114] i915_gem_set_wedged IPEIR: 0x
> >>> <7>[  239.100117] i915_gem_set_wedged IPEHR: 0x0280
> >>> <7>[  239.100120] i915_gem_set_wedged Execlist status: 
> >>> 0x00044052 0002
> >>> <7>[  239.100124] i915_gem_set_wedged Execlist CSB read 5 
> >>> [5 cached], write 5 [5 from hws], interrupt posted? no, tasklet 
> >>> queued? no (enabled)
> >>> <7>[  239.100128] i915_gem_set_wedged ELSP[0] 
> >>> count=1, ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 
> >>> 5164ms: (null)
> >>> <7>[  239.100132] i915_gem_set_wedged ELSP[1] 
> >>> count=1, ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 
> >>> 5164ms: igt/rcs0[5977]/1
> >>> <7>[  239.100135] i915_gem_set_wedged HW active? 
> >>> 0x5
> >>> <7>[  239.100250] i915_gem_set_wedged E 19a99 
> >>> [e8c:5f] prio=1024 @ 5164ms: (null)
> >>> <7>[  239.100338] i915_gem_set_wedged E 19a9a 
> >>> [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1
> >>> <7>[  239.100340] i915_gem_set_wedged Queue 
> >>> priority: 139
> >>> <7>[  239.100343] i915_gem_set_wedged Q 0 
> >>> [e98:19] prio=132 @ 5164ms: igt/rcs0[5977]/8
> >>> <7>[  239.100346] i915_gem_set_wedged Q 0 
> >>> [e84:19] prio=121 @ 5165ms: igt/rcs0[5977]/2
> >>> <7>[  239.100349] i915_gem_set_wedged Q 0 
> >>> [e87:19] prio=82 @ 5165ms: igt/rcs0[5977]/3
> >>> <7>[  239.100352] i915_gem_set_wedged Q 0 
> >>> [e84:1a] prio=44 @ 5164ms: igt/rcs0[5977]/2
> >>> <7>[  239.100356] i915_gem_set_wedged   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c

[Patchwork]

== Series Details ==

Series: drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c
URL   : https://patchwork.freedesktop.org/series/43770/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4238 -> Patchwork_9121 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/43770/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)


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


== Participating hosts (44 -> 39) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4238 -> Patchwork_9121

  CI_DRM_4238: 2771a5e6347eb63e43fdfc432a9f15ffb55ef209 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9121: 89d952d130695412fc71593cdb614f0447e2f7ff @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

89d952d13069 drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Wait for ELSP submission on restart

[Chris Wilson]

Quoting Chris Wilson (2018-05-22 11:19:37)
> After a reset, we will ensure that there is at least one request
> submitted to HW to ensure that a context is loaded for powersaving.
> Let's wait for this submission via a tasklet to complete before we drop
> our forcewake, ensuring the system is ready for rc6 before we let it
> possible sleep.
> 
> Signed-off-by: Chris Wilson 

Pushed with corrections and review from Mika (on a later thread). Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function

[Noralf Trønnes]

Den 24.05.2018 11.16, skrev Daniel Vetter:

On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote:

This is the first step in getting generic fbdev emulation.
A drm_fb_helper_funcs.fb_probe function is added which uses the
DRM client API to get a framebuffer backed by a dumb buffer.

A transitional hack for tinydrm is needed in order to switch over all
CMA helper drivers in a later patch. This hack will be removed when
tinydrm moves to vmalloc buffers.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/drm_fb_helper.c | 164 
  include/drm/drm_fb_helper.h |  26 +++
  2 files changed, 190 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2ee1eaa66188..444c2b4040ea 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -30,11 +30,13 @@
  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
  
  #include 

+#include 
  #include 
  #include 
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -2928,6 +2930,168 @@ void drm_fb_helper_output_poll_changed(struct 
drm_device *dev)
  }
  EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
  
+/* @user: 1=userspace, 0=fbcon */

+static int drm_fbdev_fb_open(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   if (!try_module_get(fb_helper->dev->driver->fops->owner))
+   return -ENODEV;
+
+   return 0;
+}
+
+static int drm_fbdev_fb_release(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   module_put(fb_helper->dev->driver->fops->owner);
+
+   return 0;
+}

Hm, I thought earlier versions of your patch series had this separately,
for everyone. What's the reasons for merging this into the fb_probe
implementation.


This is only necessary when struct fb_ops is defined in a library where
the owner field is the library module and not the driver module.
I realised that with this generic version it's highly unlikely that we
get another library that defines struct fb_ops, so it's only needed here.

Noralf.


+
+/*
+ * fb_ops.fb_destroy is called by the last put_fb_info() call at the end of
+ * unregister_framebuffer() or fb_release().
+ */
+static void drm_fbdev_fb_destroy(struct fb_info *info)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   struct fb_ops *fbops = NULL;
+
+   DRM_DEBUG("\n");
+
+   if (fb_helper->fbdev->fbdefio) {
+   fb_deferred_io_cleanup(fb_helper->fbdev);
+   fbops = fb_helper->fbdev->fbops;
+   }
+
+   drm_fb_helper_fini(fb_helper);
+   drm_client_framebuffer_delete(fb_helper->buffer);
+   drm_client_free(fb_helper->client);
+   kfree(fb_helper);
+   kfree(fbops);
+}

Hm, if we go with the idea that drm_clients could auto-unregister through
a callback, then I expect this will lead to some control inversion. But we
can fix that later on.


+
+static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   if (fb_helper->dev->driver->gem_prime_mmap)
+   return 
fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma);
+   else
+   return -ENODEV;
+}
+
+static struct fb_ops drm_fbdev_fb_ops = {
+   /* No need to set owner, this module is already pinned by the driver. */

I'd still set it, means less thinking since more obviously correct.


+   DRM_FB_HELPER_DEFAULT_OPS,
+   .fb_open= drm_fbdev_fb_open,
+   .fb_release = drm_fbdev_fb_release,
+   .fb_destroy = drm_fbdev_fb_destroy,
+   .fb_mmap= drm_fbdev_fb_mmap,
+   .fb_read= drm_fb_helper_sys_read,
+   .fb_write   = drm_fb_helper_sys_write,
+   .fb_fillrect= drm_fb_helper_sys_fillrect,
+   .fb_copyarea= drm_fb_helper_sys_copyarea,
+   .fb_imageblit   = drm_fb_helper_sys_imageblit,

Hm, some drivers require the cfb versions of these. In practice I guess
there's not much of a difference really, at least on x86 and arm.

We might want to document that though.


+};
+
+static struct fb_deferred_io drm_fbdev_defio = {
+   .delay  = HZ / 20,
+   .deferred_io= drm_fb_helper_deferred_io,
+};
+
+/*
+ * TODO: Remove this when tinydrm is converted to vmalloc buffers.
+ */
+static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
+ struct vm_area_struct *vma)
+{
+   fb_deferred_io_mmap(info, vma);
+   vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+
+   return 0;
+}
+

Needs kerneldoc here.


+int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper,
+   struct drm_fb_helper_surface_size *sizes)
+{
+   struct drm_client_dev *client = fb_helper->client;
+   struct drm_client_buffer *buffer;
+   struct 

Re: [Intel-gfx] [PATCH 08/18] drm/i915/execlists: Wait for ELSP submission on restart

[Mika Kuoppala]

Chris Wilson  writes:

> After a reset, we will ensure that there is at least one request
> submitted to HW to ensure that a context is loaded for powersaving.
> Let's wait for this submission via a tasklet to complete before we drop
> our forcewake, ensuring the system is ready for rc6 before we let it
> possible sleep.

s/possible/possibly ?

>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.h  |  6 ++
>  drivers/gpu/drm/i915/intel_lrc.c | 15 ++-
>  2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
> index 62ee4e385365..261da577829a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.h
> +++ b/drivers/gpu/drm/i915/i915_gem.h
> @@ -82,4 +82,10 @@ static inline void __tasklet_disable_sync_once(struct 
> tasklet_struct *t)
>   tasklet_unlock_wait(t);
>  }
>  
> +static inline void __tasklet_enable_sync_once(struct tasklet_struct *t)
> +{
> + if (atomic_dec_return(>count) == 0)
> + tasklet_kill(t);
> +}
> +
>  #endif /* __I915_GEM_H__ */
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index b3a5cfb7689f..f2fb48b1a7b7 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1877,6 +1877,8 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
>  
>   GEM_TRACE("%s\n", engine->name);
>  
> + intel_uncore_forcewake_get(engine->i915, FORCEWAKE_ALL);
> +
>   /*
>* Prevent request submission to the hardware until we have
>* completed the reset in i915_gem_reset_finish(). If a request
> @@ -2007,7 +2009,18 @@ static void execlists_reset(struct intel_engine_cs 
> *engine,
>  
>  static void execlists_reset_finish(struct intel_engine_cs *engine)
>  {
> - tasklet_enable(>execlists.tasklet);
> + /*
> +  * Flush the tasklet while we still have the forcewake to be sure
> +  * that it is not allowed to sleep before we restart and reload a
> +  * context.
> +  *
> +  * As before (with execlists_reset_prepare) we rely on the caller
> +  * serialising mutiple attempts to reset so that we know that we

s/mutiple/multiple

> +  * are the only one manipulating tasklet state.
> +  */
> + __tasklet_enable_sync_once(>execlists.tasklet);
> +
> + intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);

as discussed in irc, we already hold forcewakes on behalf of
prepare_engine() above us.


With forcewake_put/get removed,

Reviewed-by: Mika Kuoppala 

>  
>   GEM_TRACE("%s\n", engine->name);
>  }
> -- 
> 2.17.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/18] drm/i915: "Race-to-idle" after switching to the kernel context

[Chris Wilson]

Quoting Mika Kuoppala (2018-05-25 13:22:55)
> Chris Wilson  writes:
> 
> > During suspend we want to flush out all active contexts and their
> > rendering. To do so we queue a request from the kernel's context, once
> > we know that request is done, we know the GPU is completely idle. To
> > speed up that switch bump the GPU clocks.
> >
> > Switching to the kernel context prior to idling is also used to enforce
> > a barrier before changing OA properties, and when evicting active
> > rendering from the global GTT. All cases where we do want to
> > race-to-idle.
> >
> > v2: Limit the boosting to only the switch before suspend.
> > v3: Limit it to the wait-for-idle on suspend.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: David Weinehall 
> > Cc: Mika Kuoppala 
> > Reviewed-by: Mika Kuoppala  #v1
> > Tested-by: David Weinehall  #v1
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 27 +--
> >  drivers/gpu/drm/i915/i915_request.h |  1 +
> >  2 files changed, 26 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index c93f5dcb1d82..7b5544efa0ba 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3704,7 +3704,29 @@ i915_gem_wait_ioctl(struct drm_device *dev, void 
> > *data, struct drm_file *file)
> >  
> >  static int wait_for_timeline(struct i915_timeline *tl, unsigned int flags)
> >  {
> > - return i915_gem_active_wait(>last_request, flags);
> > + struct i915_request *rq;
> > + long ret;
> > +
> > + rq = i915_gem_active_get_unlocked(>last_request);
> > + if (!rq)
> > + return 0;
> > +
> > + /*
> > +  * "Race-to-idle".
> > +  *
> > +  * Switching to the kernel context is often used a synchronous
> > +  * step prior to idling, e.g. in suspend for flushing all
> > +  * current operations to memory before sleeping. These we
> > +  * want to complete as quickly as possible to avoid prolonged
> > +  * stalls, so allow the gpu to boost to maximum clocks.
> > +  */
> > + if (flags & I915_WAIT_FOR_IDLE_BOOST)
> > + gen6_rps_boost(rq, NULL);
> > +
> > + ret = i915_request_wait(rq, flags, MAX_SCHEDULE_TIMEOUT);
> 
> I pondered about the boost flag falling through into wait.
> But they are flags on wait domain so no reason to split/limit.

Indeed,

> >  #define I915_WAIT_INTERRUPTIBLE  BIT(0)
> >  #define I915_WAIT_LOCKED BIT(1) /* struct_mutex held, handle GPU reset 
> > */
> >  #define I915_WAIT_ALLBIT(2) /* used by 
> > i915_gem_object_wait() */
> > +#define I915_WAIT_FOR_IDLE_BOOST BIT(3)

I thought was a reasonable way to share the same set of flags with
distinct regions.

Thanks for the review and discussion,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx