[Intel-gfx] [PULL] gvt-fixes

2021-01-07 Thread Zhenyu Wang

Hi,

Here's one gvt fixes for VFIO edid on APL/BXT with virtual display
hotplug fixed that feature is enabled again.

Thanks.
--
The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:

  Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux tags/gvt-fixes-2020-01-08

for you to fetch changes up to 4ceb06e7c336f4a8d3f3b6ac9a4fea2e9c97dc07:

  drm/i915/gvt: Fix vfio_edid issue for BXT/APL (2021-01-06 11:19:15 +0800)


gvt-fixes-2020-01-08

- Fix VFIO EDID on APL/BXT (Colin)


Colin Xu (1):
  drm/i915/gvt: Fix vfio_edid issue for BXT/APL

 drivers/gpu/drm/i915/gvt/display.c | 81 +++---
 drivers/gpu/drm/i915/gvt/vgpu.c|  5 +--
 2 files changed, 59 insertions(+), 27 deletions(-)


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


[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915/selftests: Skip unstable timing measurements (rev2)

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/selftests: Skip unstable timing 
measurements (rev2)
URL   : https://patchwork.freedesktop.org/series/85596/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9563_full -> Patchwork_19287_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-cleanup:
- shard-hsw:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-hsw8/igt@gem_ctx_persiste...@engines-cleanup.html

  * igt@gem_exec_reloc@basic-many-active@rcs0:
- shard-apl:  [PASS][2] -> [FAIL][3] ([i915#2389])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/shard-apl4/igt@gem_exec_reloc@basic-many-act...@rcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-apl8/igt@gem_exec_reloc@basic-many-act...@rcs0.html

  * igt@gem_exec_reloc@basic-many-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][4] ([i915#2389])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-iclb4/igt@gem_exec_reloc@basic-many-act...@vcs1.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][5] -> [SKIP][6] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/shard-tglb1/igt@gem_huc_c...@huc-copy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_media_vme:
- shard-skl:  NOTRUN -> [SKIP][7] ([fdo#109271]) +105 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-skl5/igt@gem_media_vme.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-skl:  [PASS][8] -> [FAIL][9] ([i915#644])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/shard-skl7/igt@gem_pp...@flink-and-close-vma-leak.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-skl7/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [WARN][10] ([i915#2658])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-skl4/igt@gem_pr...@exhaustion.html

  * igt@i915_selftest@mock@requests:
- shard-skl:  [PASS][11] -> [INCOMPLETE][12] ([i915#198])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/shard-skl1/igt@i915_selftest@m...@requests.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-skl1/igt@i915_selftest@m...@requests.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl:  [PASS][13] -> [FAIL][14] ([i915#2521])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/shard-skl9/igt@kms_async_fl...@alternate-sync-async-flip.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-skl5/igt@kms_async_fl...@alternate-sync-async-flip.html

  * igt@kms_ccs@pipe-c-bad-pixel-format:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111304]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-skl6/igt@kms_...@pipe-c-bad-pixel-format.html

  * igt@kms_color_chamelium@pipe-a-ctm-0-75:
- shard-hsw:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-hsw8/igt@kms_color_chamel...@pipe-a-ctm-0-75.html

  * igt@kms_color_chamelium@pipe-d-ctm-0-25:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) 
+13 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-skl8/igt@kms_color_chamel...@pipe-d-ctm-0-25.html

  * igt@kms_cursor_crc@pipe-a-cursor-128x128-random:
- shard-skl:  [PASS][18] -> [FAIL][19] ([i915#54]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-128x128-random.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-128x128-random.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x128-random:
- shard-skl:  NOTRUN -> [FAIL][20] ([i915#54]) +1 similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-128x128-random.html

  * igt@kms_cursor_crc@pipe-d-cursor-64x21-onscreen:
- shard-kbl:  NOTRUN -> [SKIP][21] ([fdo#109271])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/shard-kbl4/igt@kms_cursor_...@pipe-d-cursor-64x21-onscreen.html
- shard-apl:  NOTRUN -> [SKIP][22] ([fdo#109271])
   [22]: 

Re: [Intel-gfx] [kbuild-all] Re: [PATCH v3 8/8] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev

2021-01-07 Thread Rong Chen

Hi Thomas,

Thanks for the feedback, do you mean the patch was applied to a wrong base?

Best Regards,
Rong Chen

On 1/7/21 6:45 PM, Thomas Zimmermann wrote:

AFAICT these are false positives. The instances have been fixed already.

Am 07.01.21 um 10:45 schrieb kernel test robot:

Hi Thomas,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next linus/master v5.11-rc2 
next-20210104]

[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url: 
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007

base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-s021-20210107 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
 # apt-get install sparse
 # sparse version: v0.6.3-208-g46a52ca4-dirty
 # 
https://github.com/0day-ci/linux/commit/380912f7b62c23322562c40e19efd7ad84d57e9c

 git remote add linux-review https://github.com/0day-ci/linux
 git fetch --no-tags linux-review 
Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007

 git checkout 380912f7b62c23322562c40e19efd7ad84d57e9c
 # save the attached .config to linux build tree
 make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' 
ARCH=x86_64


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

All errors (new ones prefixed by >>):

    drivers/gpu/drm/gma500/oaktrail_device.c: In function 
'oaktrail_chip_setup':
drivers/gpu/drm/gma500/oaktrail_device.c:509:26: error: 'struct 
drm_device' has no member named 'pdev'; did you mean 'dev'?

  509 |  if (pci_enable_msi(dev->pdev))
  |  ^~~~
  |  dev
--
    drivers/gpu/drm/gma500/oaktrail_lvds.c: In function 
'oaktrail_lvds_set_power':
drivers/gpu/drm/gma500/oaktrail_lvds.c:63:25: error: 'struct 
drm_device' has no member named 'pdev'; did you mean 'dev'?

   63 |   pm_request_idle(>pdev->dev);
  | ^~~~
  | dev
--
    drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_clock':
    drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:69:11: warning: 
variable 'tmp' set but not used [-Wunused-but-set-variable]

   69 |  u32 val, tmp;
  |   ^~~
    drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_data':
    drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:83:11: warning: 
variable 'tmp' set but not used [-Wunused-but-set-variable]

   83 |  u32 val, tmp;
  |   ^~~
    drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 
'oaktrail_lvds_i2c_init':
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:148:35: error: 'struct 
drm_device' has no member named 'pdev'; did you mean 'dev'?

  148 |  chan->adapter.dev.parent = >pdev->dev;
  |   ^~~~
  |   dev
--
    drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function 'vmw_driver_load':
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:661:22: error: 'struct 
drm_device' has no member named 'pdev'; did you mean 'dev'?

  661 |  pci_set_master(dev->pdev);
  |  ^~~~
  |  dev
    In file included from drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:31:
    drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:690:47: error: 'struct 
drm_device' has no member named 'pdev'; did you mean 'dev'?

  690 |  dev_priv->io_start = pci_resource_start(dev->pdev, 0);
  |   ^~~~
    include/linux/pci.h:1854:40: note: in definition of macro 
'pci_resource_start'
 1854 | #define pci_resource_start(dev, bar) 
((dev)->resource[(bar)].start)

  |    ^~~
    drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:691:49: error: 'struct 
drm_device' has no member named 'pdev'; did you mean 'dev'?

  691 |  dev_priv->vram_start = pci_resource_start(dev->pdev, 1);
  | ^~~~
    include/linux/pci.h:1854:40: note: in definition of macro 
'pci_resource_start'
 1854 | #define pci_resource_start(dev, bar) 
((dev)->resource[(bar)].start)

  |    ^~~
    drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:692:49: error: 'struct 
drm_device' has no member named 'pdev'; did you mean 'dev'?

  692 |  dev_priv->mmio_start = pci_resource_start(dev->pdev, 2);
  | ^~~~
    include/linux/pci.h:1854:40: note: in definition of macro 
'pci_resource_start'
 1854 | #define pci_reso

Re: [Intel-gfx] linux-next: build failure after merge of the drm tree

2021-01-07 Thread Stephen Rothwell
Hi all,

On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> error: the following would cause module name conflict:
>   drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
>   drivers/gpu/drm/panel/panel-dsi-cm.ko
> 
> Maybe caused by commit
> 
>   cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> 
> I have used the drm tree from next-20210107 for today.

This has affected the drm-misc tree as well (since it merged in the drm
tree).

I have used the drm-misc tree from next-20210107 for today.
-- 
Cheers,
Stephen Rothwell


pgpi1MUV_h9GN.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Try to use fast+narrow link on eDP 
again and fall back to the old max strategy on failure
URL   : https://patchwork.freedesktop.org/series/85588/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9562_full -> Patchwork_19284_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-hostile:
- shard-hsw:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-hsw5/igt@gem_ctx_persiste...@engines-hostile.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_eio@kms:
- shard-glk:  [PASS][3] -> [INCOMPLETE][4] ([i915#2244] / 
[i915#2502])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-glk4/igt@gem_...@kms.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-glk5/igt@gem_...@kms.html

  * igt@gem_exec_whisper@basic-forked-all:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-glk9/igt@gem_exec_whis...@basic-forked-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-glk6/igt@gem_exec_whis...@basic-forked-all.html

  * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb:
- shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271]) +48 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-snb6/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html

  * igt@gem_userptr_blits@process-exit-mmap@wc:
- shard-hsw:  NOTRUN -> [SKIP][8] ([fdo#109271]) +161 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-hsw7/igt@gem_userptr_blits@process-exit-m...@wc.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl:  [PASS][9] -> [FAIL][10] ([i915#2521])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl6/igt@kms_async_fl...@alternate-sync-async-flip.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-skl6/igt@kms_async_fl...@alternate-sync-async-flip.html

  * igt@kms_color@pipe-c-ctm-0-25:
- shard-skl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl9/igt@kms_co...@pipe-c-ctm-0-25.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-skl7/igt@kms_co...@pipe-c-ctm-0-25.html

  * igt@kms_color_chamelium@pipe-c-ctm-red-to-blue:
- shard-snb:  NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +3 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-snb6/igt@kms_color_chamel...@pipe-c-ctm-red-to-blue.html

  * igt@kms_color_chamelium@pipe-d-ctm-0-25:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +9 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-skl2/igt@kms_color_chamel...@pipe-d-ctm-0-25.html

  * igt@kms_color_chamelium@pipe-invalid-gamma-lut-sizes:
- shard-hsw:  NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +9 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-hsw5/igt@kms_color_chamel...@pipe-invalid-gamma-lut-sizes.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-skl:  NOTRUN -> [FAIL][16] ([i915#54]) +1 similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-skl10/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x42-sliding:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#54]) +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-128x42-sliding.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-128x42-sliding.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk:  [PASS][19] -> [FAIL][20] ([i915#72])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html

  * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic:
- shard-skl:  NOTRUN -> [FAIL][21] ([i915#2346])
   [21]: 

Re: [Intel-gfx] [PATCH] drm/i915/uc: Add function to define defaults for GuC/HuC enable

2021-01-07 Thread Daniele Ceraolo Spurio




On 1/5/2021 1:13 PM, john.c.harri...@intel.com wrote:

From: John Harrison 

There is a module parameter for controlling what GuC/HuC features are
enabled. Setting to -1 means 'use the default'. However, the default
is not well defined, out of date and needs to be different across
platforms.


I believe this needs a bit more detail about the change in behavior. -1 
used to map to HuC loading on all gen11+ platforms, while after this 
change it will map to disabled on all current platforms and HuC loading 
on dg1 and all future platforms.



Signed-off-by: John Harrison 
CC: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/gt/uc/intel_uc.c| 28 ++--
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  7 +-
  drivers/gpu/drm/i915/i915_params.h   |  1 +
  3 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 6a0452815c41..2c08db58cf12 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -15,6 +15,29 @@
  static const struct intel_uc_ops uc_ops_off;
  static const struct intel_uc_ops uc_ops_on;
  
+static void uc_expand_default_options(struct intel_uc *uc)

+{
+   struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
+
+   if (i915->params.enable_guc != -1)
+   return;
+
+   /* Don't enable GuC/HuC on pre-Gen12 */
+   if (INTEL_GEN(i915) < 12) {
+   i915->params.enable_guc = 0;
+   return;
+   }
+
+   /* Don't enable GuC/HuC on older Gen12 platforms */
+   if (IS_TIGERLAKE(i915) || IS_ROCKETLAKE(i915)) {
+   i915->params.enable_guc = 0;
+   return;
+   }
+
+   /* Default: enable HuC authentication only */
+   i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+}
+
  /* Reset GuC providing us with fresh state for both GuC and HuC.
   */
  static int __intel_uc_reset_hw(struct intel_uc *uc)
@@ -79,8 +102,7 @@ static void __confirm_options(struct intel_uc *uc)
 "Incompatible option enable_guc=%d - %s\n",
 i915->params.enable_guc, "GuC submission is N/A");
  
-	if (i915->params.enable_guc & ~(ENABLE_GUC_SUBMISSION |

- ENABLE_GUC_LOAD_HUC))
+   if (i915->params.enable_guc & ~ENABLE_GUC_MASK)
drm_info(>drm,
 "Incompatible option enable_guc=%d - %s\n",
 i915->params.enable_guc, "undocumented flag");
@@ -88,6 +110,8 @@ static void __confirm_options(struct intel_uc *uc)
  
  void intel_uc_init_early(struct intel_uc *uc)

  {
+   uc_expand_default_options(uc);
+
intel_guc_init_early(>guc);
intel_huc_init_early(>huc);


here there is a call to __confirm_options() that has a check for 
enable_guc == -1, which can be dropped since we can't reach here with 
that value anymore.


with these addressed:
Reviewed-by: Daniele Ceraolo Spurio 

Daniele

  
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c

index 602f1a0bc587..67b06fde1225 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -152,16 +152,11 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
uc_fw->path = NULL;
}
}
-
-   /* We don't want to enable GuC/HuC on pre-Gen11 by default */
-   if (i915->params.enable_guc == -1 && p < INTEL_ICELAKE)
-   uc_fw->path = NULL;
  }
  
  static const char *__override_guc_firmware_path(struct drm_i915_private *i915)

  {
-   if (i915->params.enable_guc & (ENABLE_GUC_SUBMISSION |
-  ENABLE_GUC_LOAD_HUC))
+   if (i915->params.enable_guc & ENABLE_GUC_MASK)
return i915->params.guc_firmware_path;
return "";
  }
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 330c03e2b4f7..f031966af5b7 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -32,6 +32,7 @@ struct drm_printer;
  
  #define ENABLE_GUC_SUBMISSION		BIT(0)

  #define ENABLE_GUC_LOAD_HUC   BIT(1)
+#define ENABLE_GUC_MASKGENMASK(1, 0)
  
  /*

   * Invoke param, a function-like macro, for each i915 param, with arguments:


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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915/selftests: Skip unstable timing measurements (rev2)

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/selftests: Skip unstable timing 
measurements (rev2)
URL   : https://patchwork.freedesktop.org/series/85596/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9563 -> Patchwork_19287


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-y:   NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [PASS][3] -> [INCOMPLETE][4] ([i915#142] / 
[i915#2405])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/fi-byt-j1900/igt@i915_pm_...@module-reload.html

  * igt@prime_vgem@basic-fence-flip:
- fi-tgl-y:   [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/fi-tgl-y/igt@prime_v...@basic-fence-flip.html

  * igt@runner@aborted:
- fi-byt-j1900:   NOTRUN -> [FAIL][7] ([i915#1814] / [i915#2505])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/fi-byt-j1900/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_getparams_basic@basic-subslice-total:
- fi-tgl-y:   [DMESG-WARN][8] ([i915#402]) -> [PASS][9] +2 similar 
issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [DMESG-WARN][10] ([i915#1982]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@evict:
- fi-kbl-soraka:  [INCOMPLETE][12] ([i915#2782]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-kbl-soraka/igt@i915_selftest@l...@evict.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/fi-kbl-soraka/igt@i915_selftest@l...@evict.html

  * igt@i915_selftest@live@gem:
- fi-kbl-soraka:  [DMESG-WARN][14] ([i915#2826]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-kbl-soraka/igt@i915_selftest@l...@gem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19287/fi-kbl-soraka/igt@i915_selftest@l...@gem.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2826]: https://gitlab.freedesktop.org/drm/intel/issues/2826
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (43 -> 38)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9563 -> Patchwork_19287

  CI-20190529: 20190529
  CI_DRM_9563: 2b85e51a060e954506ab2dce0778411482fb4625 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5946: 641e5545213dd9a82d80a4e065013a138afb58ff @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19287: 228258384661876419f27a6f775b064d13bd367d @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

228258384661 drm/i915/gt: Disable arbitration on no-preempt requests
7f031882a9d0 drm/i915/gt: Only disable preemption on gen8 render engines
18357f02333b drm/i915/gt: Only retire on the last breadcrumb if the last request
edab172299d7 drm/i915/gt: Restore ce->signal flush before releasing virtual 
engine

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915: Wrap our timer_list.expires checking (rev2)

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Wrap our timer_list.expires 
checking (rev2)
URL   : https://patchwork.freedesktop.org/series/85584/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9562_full -> Patchwork_19283_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@in-flight-suspend:
- shard-apl:  [PASS][1] -> [CRASH][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-apl6/igt@gem_...@in-flight-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-apl7/igt@gem_...@in-flight-suspend.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-hostile:
- shard-hsw:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-hsw6/igt@gem_ctx_persiste...@engines-hostile.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-snb4/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_exec_whisper@basic-forked-all:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-glk9/igt@gem_exec_whis...@basic-forked-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-glk1/igt@gem_exec_whis...@basic-forked-all.html

  * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb:
- shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271]) +48 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-snb4/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html

  * igt@gem_userptr_blits@process-exit-mmap@wc:
- shard-hsw:  NOTRUN -> [SKIP][8] ([fdo#109271]) +161 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-hsw2/igt@gem_userptr_blits@process-exit-m...@wc.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl:  [PASS][9] -> [FAIL][10] ([i915#2521])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl6/igt@kms_async_fl...@alternate-sync-async-flip.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-skl7/igt@kms_async_fl...@alternate-sync-async-flip.html

  * igt@kms_color_chamelium@pipe-c-ctm-red-to-blue:
- shard-snb:  NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +3 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-snb4/igt@kms_color_chamel...@pipe-c-ctm-red-to-blue.html

  * igt@kms_color_chamelium@pipe-d-ctm-0-25:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +9 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-skl1/igt@kms_color_chamel...@pipe-d-ctm-0-25.html

  * igt@kms_color_chamelium@pipe-invalid-gamma-lut-sizes:
- shard-hsw:  NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +9 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-hsw6/igt@kms_color_chamel...@pipe-invalid-gamma-lut-sizes.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-skl:  NOTRUN -> [FAIL][14] ([i915#54])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-skl5/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x42-random:
- shard-skl:  [PASS][15] -> [FAIL][16] ([i915#54]) +8 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl8/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html

  * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic:
- shard-skl:  NOTRUN -> [FAIL][17] ([i915#2346])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/shard-skl1/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-atomic.html

  * igt@kms_cursor_legacy@pipe-d-torture-move:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271]) +83 similar issues
   [18]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915/selftests: Skip unstable timing measurements (rev2)

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/selftests: Skip unstable timing 
measurements (rev2)
URL   : https://patchwork.freedesktop.org/series/85596/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1329:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1450:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1504:15: warning: memset with byte count of 
16777216
+./include/linux/seqlock.h:843:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:843:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:869:16: warning: trying to copy expression type 31
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


___
Intel-gfx mailing list

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915/selftests: Skip unstable timing measurements (rev2)

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/selftests: Skip unstable timing 
measurements (rev2)
URL   : https://patchwork.freedesktop.org/series/85596/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
00bfab2df5c6 drm/i915/selftests: Skip unstable timing measurements
edab172299d7 drm/i915/gt: Restore ce->signal flush before releasing virtual 
engine
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit bab0557c8dca ("drm/i915/gt: 
Remove virtual breadcrumb before transfer")'
#14: 
bab0557c8dca ("drm/i915/gt: Remove virtual breadcrumb before transfer"),

total: 1 errors, 0 warnings, 0 checks, 90 lines checked
18357f02333b drm/i915/gt: Only retire on the last breadcrumb if the last request
7f031882a9d0 drm/i915/gt: Only disable preemption on gen8 render engines
228258384661 drm/i915/gt: Disable arbitration on no-preempt requests


___
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: Add support for Intel's eDP backlight controls (rev8)

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Add support for Intel's eDP backlight controls (rev8)
URL   : https://patchwork.freedesktop.org/series/81702/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9563 -> Patchwork_19286


Summary
---

  **FAILURE**

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

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- fi-bsw-kefka:   NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19286/fi-bsw-kefka/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19286/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@gem_linear_blits@basic:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#402])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-tgl-y/igt@gem_linear_bl...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19286/fi-tgl-y/igt@gem_linear_bl...@basic.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-7500u:   [PASS][5] -> [DMESG-WARN][6] ([i915#2868])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19286/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@i915_getparams_basic@basic-subslice-total:
- fi-tgl-y:   [DMESG-WARN][7] ([i915#402]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19286/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19286/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@evict:
- fi-kbl-soraka:  [INCOMPLETE][11] ([i915#2782]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-kbl-soraka/igt@i915_selftest@l...@evict.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19286/fi-kbl-soraka/igt@i915_selftest@l...@evict.html

  * igt@i915_selftest@live@gem:
- fi-kbl-soraka:  [DMESG-WARN][13] ([i915#2826]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-kbl-soraka/igt@i915_selftest@l...@gem.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19286/fi-kbl-soraka/igt@i915_selftest@l...@gem.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2268]: https://gitlab.freedesktop.org/drm/intel/issues/2268
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2826]: https://gitlab.freedesktop.org/drm/intel/issues/2826
  [i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (43 -> 38)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9563 -> Patchwork_19286

  CI-20190529: 20190529
  CI_DRM_9563: 2b85e51a060e954506ab2dce0778411482fb4625 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5946: 641e5545213dd9a82d80a4e065013a138afb58ff @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19286: 827c0eb2c2a4e03612eca0754b3010db29da4820 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

827c0eb2c2a4 drm/dp: Revert "drm/dp: Introduce EDID-based quirks"
b844d631c301 drm/i915/dp: Allow forcing specific interfaces through 
enable_dpcd_backlight
cf64269a8e16 drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for 
now)
bb95b7b53def drm/i915: Keep track of pwm-related 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Show the per-engine runtime in sysfs

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Show the per-engine runtime in sysfs
URL   : https://patchwork.freedesktop.org/series/85583/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9562_full -> Patchwork_19282_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@api_intel_bb@render-ccs:
- shard-kbl:  [PASS][1] -> [INCOMPLETE][2] ([i915#2405] / 
[i915#2499])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-kbl1/igt@api_intel...@render-ccs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-kbl6/igt@api_intel...@render-ccs.html

  * igt@gem_ctx_persistence@engines-hostile:
- shard-hsw:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-hsw2/igt@gem_ctx_persiste...@engines-hostile.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-snb4/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][5] ([i915#2389]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_exec_whisper@basic-forked-all:
- shard-glk:  [PASS][6] -> [DMESG-WARN][7] ([i915#118] / [i915#95]) 
+1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-glk9/igt@gem_exec_whis...@basic-forked-all.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-glk2/igt@gem_exec_whis...@basic-forked-all.html

  * igt@gem_render_copy@y-tiled-to-vebox-linear:
- shard-hsw:  NOTRUN -> [SKIP][8] ([fdo#109271]) +97 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-hsw7/igt@gem_render_c...@y-tiled-to-vebox-linear.html

  * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb:
- shard-snb:  NOTRUN -> [SKIP][9] ([fdo#109271]) +48 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-snb4/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-glk:  [PASS][10] -> [INCOMPLETE][11] ([i915#2199] / 
[i915#2405])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-glk6/igt@gem_workarou...@suspend-resume-fd.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-glk8/igt@gem_workarou...@suspend-resume-fd.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl:  [PASS][12] -> [FAIL][13] ([i915#2521])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl6/igt@kms_async_fl...@alternate-sync-async-flip.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-skl2/igt@kms_async_fl...@alternate-sync-async-flip.html

  * igt@kms_color_chamelium@pipe-c-ctm-red-to-blue:
- shard-snb:  NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +3 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-snb4/igt@kms_color_chamel...@pipe-c-ctm-red-to-blue.html

  * igt@kms_color_chamelium@pipe-d-ctm-0-25:
- shard-skl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-skl8/igt@kms_color_chamel...@pipe-d-ctm-0-25.html

  * igt@kms_color_chamelium@pipe-invalid-gamma-lut-sizes:
- shard-hsw:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-hsw2/igt@kms_color_chamel...@pipe-invalid-gamma-lut-sizes.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-skl:  NOTRUN -> [FAIL][17] ([i915#54]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-skl3/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html

  * igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding:
- shard-skl:  [PASS][18] -> [FAIL][19] ([i915#54]) +7 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/shard-skl6/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html

  * igt@kms_cursor_legacy@cursor-vs-flip-varying-size:
- shard-hsw:  [PASS][20] -> [FAIL][21] ([i915#2370])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html
   

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/selftests: Skip unstable timing measurements

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/selftests: Skip unstable timing 
measurements
URL   : https://patchwork.freedesktop.org/series/85596/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9563 -> Patchwork_19285


Summary
---

  **FAILURE**

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

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@execlists:
- fi-bsw-kefka:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19285/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19285/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_basic@memory-alloc:
- fi-tgl-y:   NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +1 
similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19285/fi-tgl-y/igt@amdgpu/amd_ba...@memory-alloc.html

  * igt@gem_sync@basic-all:
- fi-tgl-y:   [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +2 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-tgl-y/igt@gem_s...@basic-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19285/fi-tgl-y/igt@gem_s...@basic-all.html

  * igt@runner@aborted:
- fi-bsw-kefka:   NOTRUN -> [FAIL][7] ([i915#1436])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19285/fi-bsw-kefka/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_getparams_basic@basic-subslice-total:
- fi-tgl-y:   [DMESG-WARN][8] ([i915#402]) -> [PASS][9] +2 similar 
issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19285/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [DMESG-WARN][10] ([i915#1982]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19285/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@evict:
- fi-kbl-soraka:  [INCOMPLETE][12] ([i915#2782]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-kbl-soraka/igt@i915_selftest@l...@evict.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19285/fi-kbl-soraka/igt@i915_selftest@l...@evict.html

  * igt@i915_selftest@live@gem:
- fi-kbl-soraka:  [DMESG-WARN][14] ([i915#2826]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-kbl-soraka/igt@i915_selftest@l...@gem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19285/fi-kbl-soraka/igt@i915_selftest@l...@gem.html

  
 Warnings 

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [SKIP][16] ([fdo#109271]) -> [FAIL][17] ([i915#579])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9563/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19285/fi-kbl-guc/igt@i915_pm_...@basic-rte.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2826]: https://gitlab.freedesktop.org/drm/intel/issues/2826
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579


Participating hosts (43 -> 38)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9563 -> Patchwork_19285

  CI-20190529: 20190529
  

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915/selftests: Skip unstable timing measurements

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/selftests: Skip unstable timing 
measurements
URL   : https://patchwork.freedesktop.org/series/85596/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1329:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1450:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1504:15: warning: memset with byte count of 
16777216
+./include/linux/seqlock.h:843:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:843:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:869:16: warning: trying to copy expression type 31
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pps: Reuse POWER_DOMAIN_DISPLAY_CORE in pps_{lock, unlock}

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915/pps: Reuse POWER_DOMAIN_DISPLAY_CORE in pps_{lock, unlock}
URL   : https://patchwork.freedesktop.org/series/85582/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9562_full -> Patchwork_19281_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * {igt@perf_pmu@rc6-suspend}:
- shard-snb:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-snb6/igt@perf_...@rc6-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-snb4/igt@perf_...@rc6-suspend.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-hostile:
- shard-hsw:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-hsw4/igt@gem_ctx_persiste...@engines-hostile.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_exec_whisper@basic-forked-all:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) 
+2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-glk9/igt@gem_exec_whis...@basic-forked-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-glk8/igt@gem_exec_whis...@basic-forked-all.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][7] -> [SKIP][8] ([i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-tglb1/igt@gem_huc_c...@huc-copy.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb:
- shard-snb:  NOTRUN -> [SKIP][9] ([fdo#109271]) +48 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-snb6/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html

  * igt@gem_userptr_blits@process-exit-mmap@wc:
- shard-hsw:  NOTRUN -> [SKIP][10] ([fdo#109271]) +161 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-hsw7/igt@gem_userptr_blits@process-exit-m...@wc.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-apl:  [PASS][11] -> [INCOMPLETE][12] ([i915#1630] / 
[i915#2405])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-apl8/igt@gem_workarou...@suspend-resume-fd.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-apl8/igt@gem_workarou...@suspend-resume-fd.html

  * igt@i915_module_load@reload:
- shard-skl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl7/igt@i915_module_l...@reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-skl1/igt@i915_module_l...@reload.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl:  [PASS][15] -> [FAIL][16] ([i915#2521])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl6/igt@kms_async_fl...@alternate-sync-async-flip.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-skl8/igt@kms_async_fl...@alternate-sync-async-flip.html

  * igt@kms_color_chamelium@pipe-c-ctm-red-to-blue:
- shard-snb:  NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +3 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-snb6/igt@kms_color_chamel...@pipe-c-ctm-red-to-blue.html

  * igt@kms_color_chamelium@pipe-d-ctm-0-25:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +9 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-skl5/igt@kms_color_chamel...@pipe-d-ctm-0-25.html

  * igt@kms_color_chamelium@pipe-invalid-gamma-lut-sizes:
- shard-hsw:  NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +9 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-hsw4/igt@kms_color_chamel...@pipe-invalid-gamma-lut-sizes.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-skl:  NOTRUN -> [FAIL][20] ([i915#54])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html

  * 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915/selftests: Skip unstable timing measurements

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915/selftests: Skip unstable timing 
measurements
URL   : https://patchwork.freedesktop.org/series/85596/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
d55262c7a0fc drm/i915/selftests: Skip unstable timing measurements
f0c8af36f5ef drm/i915/gt: Restore ce->signal flush before releasing virtual 
engine
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit bab0557c8dca ("drm/i915/gt: 
Remove virtual breadcrumb before transfer")'
#14: 
bab0557c8dca ("drm/i915/gt: Remove virtual breadcrumb before transfer"),

total: 1 errors, 0 warnings, 0 checks, 90 lines checked
50a15a7f74c7 drm/i915/gt: Only retire on the last breadcrumb if the last request
bd8857f907c3 drm/i915/gt: Only disable preemption on gen8 render engines
aef164de84be drm/i915/gt: Disable arbitration on no-preempt requests


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


[Intel-gfx] [PATCH v5 4/4] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

2021-01-07 Thread Lyude Paul
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
  intel_edp_init_connector()

Signed-off-by: Lyude Paul 
Acked-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/drm_dp_helper.c   | 83 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  9 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 +
 7 files changed, 9 insertions(+), 113 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3ecde451f523..19dbdeb581cb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1236,7 +1236,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector 
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
-   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+   !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
 }
 EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
 
@@ -1957,87 +1957,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
-struct edid_quirk {
-   u8 mfg_id[2];
-   u8 prod_id[2];
-   u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * Some devices have unreliable OUIDs where they don't set the device ID
- * correctly, and as a result we need to use the EDID for finding additional
- * DP quirks in such cases.
- */
-static const struct edid_quirk edid_quirk_list[] = {
-   /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
-* only supports DPCD backlight controls
-*/
-   { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   /*
-* Some Dell CML 2020 systems have panels support both AUX and PWM
-* backlight control, and some only support AUX backlight control. All
-* said panels start up in AUX mode by default, and we don't have any
-* support for disabling HDR mode on these panels which would be
-* required to switch to PWM backlight control mode (plus, I'm not
-* even sure we want PWM backlight controls over DPCD backlight
-* controls anyway...). Until we have a better way of detecting these,
-* force DPCD backlight mode on all of them.
-*/
-   { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x09, 0xe5), PROD_ID(0xde, 0x08), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirks in some cases. This function can 

[Intel-gfx] [PATCH v5 2/4] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)

2021-01-07 Thread Lyude Paul
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.

Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.

On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.

For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:

* If the panel's VBT reports VESA backlight support, assume it really
  does support it
* If the panel's VBT reports DDI backlight controls:
  * First probe for Intel's HDR backlight interface
  * If that fails, probe for VESA's backlight interface
  * If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
  doesn't have DPCD backlight controls

Changes since v4:
* Fix checkpatch issues
Changes since v3:
* Stop using drm_device and use drm_i915_private instead
* Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
  to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()

Signed-off-by: Lyude Paul 
Acked-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 248 --
 drivers/gpu/drm/i915/display/intel_panel.c|  42 ++-
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 4 files changed, 271 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ee5c2d50b81a..b24d80ffd18b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -261,7 +261,14 @@ struct intel_panel {
struct pwm_state pwm_state;
 
/* DPCD backlight */
-   u8 pwmgen_bit_count;
+   union {
+   struct {
+   u8 pwmgen_bit_count;
+   } vesa;
+   struct {
+   bool sdr_uses_aux;
+   } intel;
+   } edp;
 
struct backlight_device *device;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 9775f33d1aac..5e761fb49a14 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,8 +22,26 @@
  *
  */
 
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us 
back into SDR mode so we
+ * can make people's backlights work in the mean time
+ */
 
 /*
  * DP AUX registers for Intel's proprietary HDR backlight interface. We define
@@ -77,6 +95,179 @@
 
 #define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
 
+/* Intel EDP backlight callbacks */
+static bool
+intel_dp_aux_supports_hdr_backlight(struct intel_connector 

[Intel-gfx] [PATCH v5 3/4] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight

2021-01-07 Thread Lyude Paul
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.

So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).

v3:
* Rebase

Signed-off-by: Lyude Paul 
Reviewed-by: Jani Nikula 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
 drivers/gpu/drm/i915/i915_params.c|  2 +-
 2 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 5e761fb49a14..4b2cb20b1f94 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -613,15 +613,54 @@ static const struct intel_panel_bl_funcs 
intel_dp_vesa_bl_funcs = {
.get = intel_dp_aux_vesa_get_backlight,
 };
 
+enum intel_dp_aux_backlight_modparam {
+   INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+   INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+   INTEL_DP_AUX_BACKLIGHT_ON = 1,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+   INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = >panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   bool try_intel_interface = false, try_vesa_interface = false;
 
-   if (i915->params.enable_dpcd_backlight == 0)
+   /* Check the VBT and user's module parameters to figure out which
+* interfaces to probe
+*/
+   switch (i915->params.enable_dpcd_backlight) {
+   case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
+   case INTEL_DP_AUX_BACKLIGHT_AUTO:
+   switch (i915->vbt.backlight.type) {
+   case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
+   try_vesa_interface = true;
+   break;
+   case INTEL_BACKLIGHT_DISPLAY_DDI:
+   try_intel_interface = true;
+   try_vesa_interface = true;
+   break;
+   default:
+   return -ENODEV;
+   }
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_ON:
+   if (i915->vbt.backlight.type != 
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+   try_intel_interface = true;
+
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
+   try_vesa_interface = true;
+   break;
+   case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
+   try_intel_interface = true;
+   break;
+   }
 
/*
 * A lot of eDP panels in the wild will report supporting both the
@@ -630,13 +669,13 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
 * and will only work with the Intel interface. So, always probe for
 * that first.
 */
-   if (intel_dp_aux_supports_hdr_backlight(connector)) {
+   if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight 
controls\n");
panel->backlight.funcs = _dp_hdr_bl_funcs;
return 0;
}
 
-   if (intel_dp_aux_supports_vesa_backlight(connector)) {
+   if (try_vesa_interface && 
intel_dp_aux_supports_vesa_backlight(connector)) {
drm_dbg_kms(dev, "Using VESA eDP backlight controls\n");
panel->backlight.funcs = _dp_vesa_bl_funcs;
return 0;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b..6939634e56ed 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
 
 i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"
-   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enabled)");
+   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enable, 2=force VESA interface, 3=force Intel interface)");
 
 #if IS_ENABLED(CONFIG_DRM_I915_GVT)
 

[Intel-gfx] [PATCH v5 1/4] drm/i915: Keep track of pwm-related backlight hooks separately

2021-01-07 Thread Lyude Paul
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs->setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.

Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.

v5:
* Fix indenting warnings from checkpatch
v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
  indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
  intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   4 +
 drivers/gpu/drm/i915/display/intel_panel.c| 333 ++
 2 files changed, 187 insertions(+), 150 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1067bd073c95..ee5c2d50b81a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -252,6 +252,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_level_min;
+   u32 pwm_level_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -263,6 +266,7 @@ struct intel_panel {
struct backlight_device *device;
 
const struct intel_panel_bl_funcs *funcs;
+   const struct intel_panel_bl_funcs *pwm_funcs;
void (*power)(struct intel_connector *, bool enable);
} backlight;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 67f81ae995c4..8c99bf404a32 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector 
*connector,
 0, user_max);
 }
 
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *connector, 
u32 

[Intel-gfx] [PATCH v5 0/4] drm/i915: Add support for Intel's eDP backlight controls

2021-01-07 Thread Lyude Paul
A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Series-wide changes in v3:
* Pass down brightness values to enable/disable backlight callbacks in a
  separate patch
* Rebase

Lyude Paul (4):
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
  drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  83 +---
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  14 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 287 --
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 371 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 11 files changed, 505 insertions(+), 294 deletions(-)

-- 
2.29.2

___
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/pps: Add PPS power domain (rev3)

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915/pps: Add PPS power domain (rev3)
URL   : https://patchwork.freedesktop.org/series/85470/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9562_full -> Patchwork_19280_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-hostile:
- shard-hsw:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-hsw8/igt@gem_ctx_persiste...@engines-hostile.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_ctx_persistence@smoketest:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2896])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-glk2/igt@gem_ctx_persiste...@smoketest.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-glk4/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][5] ([i915#2389]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][6] -> [SKIP][7] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-tglb1/igt@gem_huc_c...@huc-copy.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-tglb6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_render_copy@y-tiled-to-vebox-linear:
- shard-hsw:  NOTRUN -> [SKIP][8] ([fdo#109271]) +97 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-hsw6/igt@gem_render_c...@y-tiled-to-vebox-linear.html

  * igt@gem_userptr_blits@huge-split:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([i915#2502])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-tglb6/igt@gem_userptr_bl...@huge-split.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-tglb6/igt@gem_userptr_bl...@huge-split.html

  * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb:
- shard-snb:  NOTRUN -> [SKIP][11] ([fdo#109271]) +48 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-snb5/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html

  * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- shard-iclb: [PASS][12] -> [SKIP][13] ([i915#579])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-iclb5/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-iclb2/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl:  [PASS][14] -> [FAIL][15] ([i915#2521])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl6/igt@kms_async_fl...@alternate-sync-async-flip.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-skl7/igt@kms_async_fl...@alternate-sync-async-flip.html

  * igt@kms_color_chamelium@pipe-c-ctm-red-to-blue:
- shard-snb:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +3 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-snb5/igt@kms_color_chamel...@pipe-c-ctm-red-to-blue.html

  * igt@kms_color_chamelium@pipe-d-ctm-0-25:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +9 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-skl10/igt@kms_color_chamel...@pipe-d-ctm-0-25.html

  * igt@kms_color_chamelium@pipe-invalid-gamma-lut-sizes:
- shard-hsw:  NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-hsw8/igt@kms_color_chamel...@pipe-invalid-gamma-lut-sizes.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-skl:  NOTRUN -> [FAIL][19] ([i915#54]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html

  * igt@kms_cursor_crc@pipe-b-cursor-64x64-offscreen:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#54]) +6 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-64x64-offscreen.html
   [21]: 

[Intel-gfx] [PATCH 5/5] drm/i915/gt: Disable arbitration on no-preempt requests

2021-01-07 Thread Chris Wilson
If a request is submitted and known to require no preemption, disable
arbitration around the batch which prevents the HW from handling a
preemption request during the payload.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Matthew Brost 
Cc: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 +++---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c   | 3 +++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cf9a6b4eb913..b91b32195dcf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2534,6 +2534,9 @@ static int eb_submit(struct i915_execbuffer *eb, struct 
i915_vma *batch)
 {
int err;
 
+   if (intel_context_nopreempt(eb->context))
+   __set_bit(I915_FENCE_FLAG_NOPREEMPT, >request->fence.flags);
+
err = eb_move_to_gpu(eb);
if (err)
return err;
@@ -2574,9 +2577,6 @@ static int eb_submit(struct i915_execbuffer *eb, struct 
i915_vma *batch)
return err;
}
 
-   if (intel_context_nopreempt(eb->context))
-   __set_bit(I915_FENCE_FLAG_NOPREEMPT, >request->fence.flags);
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 1972dd5dca00..2e36e0a9d8a6 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -427,6 +427,9 @@ int gen8_emit_bb_start(struct i915_request *rq,
 {
u32 *cs;
 
+   if (unlikely(i915_request_has_nopreempt(rq)))
+   return gen8_emit_bb_start_noarb(rq, offset, len, flags);
+
cs = intel_ring_begin(rq, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
-- 
2.20.1

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


[Intel-gfx] [PATCH 4/5] drm/i915/gt: Only disable preemption on gen8 render engines

2021-01-07 Thread Chris Wilson
The reason why we did not enable preemption on Broadwater was due to
missing GPGPU workarounds. Since this only applies to rcs0, only
restrict rcs0 (and our global capabilities).

While this does not affect exposing a preemption capability to
userspace, it does affect our internal decisions on whether to use
timeslicing and semaphores between individual engines.

Signed-off-by: Chris Wilson 
---
 .../drm/i915/gt/intel_execlists_submission.c  | 11 -
 drivers/gpu/drm/i915/gt/selftest_execlists.c  | 40 +++
 drivers/gpu/drm/i915/i915_drv.h   |  2 -
 drivers/gpu/drm/i915/i915_pci.c   |  2 -
 drivers/gpu/drm/i915/intel_device_info.h  |  1 -
 5 files changed, 15 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index eb69eef9d7db..259e0daee490 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3093,6 +3093,15 @@ static void execlists_park(struct intel_engine_cs 
*engine)
cancel_timer(>execlists.preempt);
 }
 
+static bool can_preempt(struct intel_engine_cs *engine)
+{
+   if (INTEL_GEN(engine->i915) > 8)
+   return true;
+
+   /* GPGPU on bdw requires extra w/a; not implemented */
+   return engine->class != RENDER_CLASS;
+}
+
 void intel_execlists_set_default_submission(struct intel_engine_cs *engine)
 {
engine->submit_request = execlists_submit_request;
@@ -3110,7 +3119,7 @@ void intel_execlists_set_default_submission(struct 
intel_engine_cs *engine)
engine->flags |= I915_ENGINE_SUPPORTS_STATS;
if (!intel_vgpu_active(engine->i915)) {
engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
-   if (HAS_LOGICAL_RING_PREEMPTION(engine->i915)) {
+   if (can_preempt(engine)) {
engine->flags |= I915_ENGINE_HAS_PREEMPTION;
if (IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
engine->flags |= I915_ENGINE_HAS_TIMESLICES;
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c 
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index bfa7fd5c2c91..e9070f51ff15 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -924,6 +924,9 @@ slice_semaphore_queue(struct intel_engine_cs *outer,
return PTR_ERR(head);
 
for_each_engine(engine, outer->gt, id) {
+   if (!intel_engine_has_preemption(engine))
+   continue;
+
for (i = 0; i < count; i++) {
struct i915_request *rq;
 
@@ -943,8 +946,8 @@ slice_semaphore_queue(struct intel_engine_cs *outer,
 
if (i915_request_wait(head, 0,
  2 * outer->gt->info.num_engines * (count + 2) * 
(count + 3)) < 0) {
-   pr_err("Failed to slice along semaphore chain of length (%d, 
%d)!\n",
-  count, n);
+   pr_err("%s: Failed to slice along semaphore chain of length 
(%d, %d)!\n",
+  outer->name, count, n);
GEM_TRACE_DUMP();
intel_gt_set_wedged(outer->gt);
err = -EIO;
@@ -1721,12 +1724,6 @@ static int live_preempt(void *arg)
enum intel_engine_id id;
int err = -ENOMEM;
 
-   if (!HAS_LOGICAL_RING_PREEMPTION(gt->i915))
-   return 0;
-
-   if (!(gt->i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
-   pr_err("Logical preemption supported, but not exposed\n");
-
if (igt_spinner_init(_hi, gt))
return -ENOMEM;
 
@@ -1821,9 +1818,6 @@ static int live_late_preempt(void *arg)
enum intel_engine_id id;
int err = -ENOMEM;
 
-   if (!HAS_LOGICAL_RING_PREEMPTION(gt->i915))
-   return 0;
-
if (igt_spinner_init(_hi, gt))
return -ENOMEM;
 
@@ -1957,9 +1951,6 @@ static int live_nopreempt(void *arg)
 * that may be being observed and not want to be interrupted.
 */
 
-   if (!HAS_LOGICAL_RING_PREEMPTION(gt->i915))
-   return 0;
-
if (preempt_client_init(gt, ))
return -ENOMEM;
if (preempt_client_init(gt, ))
@@ -2382,9 +2373,6 @@ static int live_preempt_cancel(void *arg)
 * GPU. That sounds like preemption! Plus a little bit of bookkeeping.
 */
 
-   if (!HAS_LOGICAL_RING_PREEMPTION(gt->i915))
-   return 0;
-
if (preempt_client_init(gt, ))
return -ENOMEM;
if (preempt_client_init(gt, ))
@@ -2448,9 +2436,6 @@ static int live_suppress_self_preempt(void *arg)
 * completion event.
 */
 
-   if (!HAS_LOGICAL_RING_PREEMPTION(gt->i915))
-   return 0;
-
if (intel_uc_uses_guc_submission(>uc))
return 0; /* presume black blox */
 
@@ -2563,9 

[Intel-gfx] [PATCH 1/5] drm/i915/selftests: Skip unstable timing measurements

2021-01-07 Thread Chris Wilson
If any of the perf tests run into 0 time, not only are we liable to
divide by zero, but the result would be highly questionable.
Nevertheless, let's not have a div-by-zero error.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/intel_memory_region.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c 
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index 75839db63bea..59c58a276677 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -852,6 +852,9 @@ static int _perf_memcpy(struct intel_memory_region *src_mr,
}
 
sort(t, ARRAY_SIZE(t), sizeof(*t), wrap_ktime_compare, NULL);
+   if (!t[0])
+   continue;
+
pr_info("%s src(%s, %s) -> dst(%s, %s) %14s %4llu KiB copy: 
%5lld MiB/s\n",
__func__,
src_mr->name,
-- 
2.20.1

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


[Intel-gfx] [PATCH 2/5] drm/i915/gt: Restore ce->signal flush before releasing virtual engine

2021-01-07 Thread Chris Wilson
Before we mark the virtual engine as no longer inflight, flush any
ongoing signaling that may be using the ce->signal_link along the
previous breadcrumbs. On switch to a new physical engine, that link will
be inserted into the new set of breadcrumbs, causing confusion to an
ongoing iterator.

This patch undoes a last minute mistake introduced into commit
bab0557c8dca ("drm/i915/gt: Remove virtual breadcrumb before transfer"),
whereby instead of unconditionally applying the flush, it was only
applied if the request itself was going to be reused.

v2: Generalise and cancel all remaining ce->signals

Fixes: bab0557c8dca ("drm/i915/gt: Remove virtual breadcrumb before transfer")
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c   | 33 +++
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.h   |  4 +++
 .../drm/i915/gt/intel_execlists_submission.c  | 25 ++
 3 files changed, 47 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 2eabb9ab5d47..7137b6f24f55 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -472,6 +472,39 @@ void i915_request_cancel_breadcrumb(struct i915_request 
*rq)
i915_request_put(rq);
 }
 
+void intel_context_remove_breadcrumbs(struct intel_context *ce,
+ struct intel_breadcrumbs *b)
+{
+   struct i915_request *rq, *rn;
+   bool release = false;
+   unsigned long flags;
+
+   spin_lock_irqsave(>signal_lock, flags);
+
+   if (list_empty(>signals))
+   goto unlock;
+
+   list_for_each_entry_safe(rq, rn, >signals, signal_link) {
+   GEM_BUG_ON(!__i915_request_is_complete(rq));
+   if (!test_and_clear_bit(I915_FENCE_FLAG_SIGNAL,
+   >fence.flags))
+   continue;
+
+   list_del_rcu(>signal_link);
+   irq_signal_request(rq, b);
+   i915_request_put(rq);
+   }
+   release = remove_signaling_context(b, ce);
+
+unlock:
+   spin_unlock_irqrestore(>signal_lock, flags);
+   if (release)
+   intel_context_put(ce);
+
+   while (atomic_read(>signaler_active))
+   cpu_relax();
+}
+
 static void print_signals(struct intel_breadcrumbs *b, struct drm_printer *p)
 {
struct intel_context *ce;
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
index 75cc9cff3ae3..3ce5ce270b04 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
@@ -6,6 +6,7 @@
 #ifndef __INTEL_BREADCRUMBS__
 #define __INTEL_BREADCRUMBS__
 
+#include 
 #include 
 
 #include "intel_engine_types.h"
@@ -44,4 +45,7 @@ void intel_engine_print_breadcrumbs(struct intel_engine_cs 
*engine,
 bool i915_request_enable_breadcrumb(struct i915_request *request);
 void i915_request_cancel_breadcrumb(struct i915_request *request);
 
+void intel_context_remove_breadcrumbs(struct intel_context *ce,
+ struct intel_breadcrumbs *b);
+
 #endif /* __INTEL_BREADCRUMBS__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 2f8e10450f7e..eb69eef9d7db 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -581,21 +581,6 @@ resubmit_virtual_request(struct i915_request *rq, struct 
virtual_engine *ve)
 {
struct intel_engine_cs *engine = rq->engine;
 
-   /* Flush concurrent rcu iterators in signal_irq_work */
-   if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags)) {
-   /*
-* After this point, the rq may be transferred to a new
-* sibling, so before we clear ce->inflight make sure that
-* the context has been removed from the b->signalers and
-* furthermore we need to make sure that the concurrent
-* iterator in signal_irq_work is no longer following
-* ce->signal_link.
-*/
-   i915_request_cancel_breadcrumb(rq);
-   while (atomic_read(>breadcrumbs->signaler_active))
-   cpu_relax();
-   }
-
spin_lock_irq(>active.lock);
 
clear_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
@@ -610,6 +595,16 @@ static void kick_siblings(struct i915_request *rq, struct 
intel_context *ce)
struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
struct intel_engine_cs *engine = rq->engine;
 
+   /*
+* After this point, the rq may be transferred to a new sibling, so
+* before we clear ce->inflight make sure that the context has been
+* removed from the b->signalers and furthermore we need to make sure
+

[Intel-gfx] [PATCH 3/5] drm/i915/gt: Only retire on the last breadcrumb if the last request

2021-01-07 Thread Chris Wilson
We use the completion of the last active breadcrumb to retire the
requests along a timeline. This is purely opportunistic as nothing
guarantees that any particular timeline is terminated by a breadcrumb;
except for the parking the engine. We explicitly add a breadcrumb to
parking the engine so that we park quickly and do an explicit retire
upon signaling to reduce the latency dramatically.

With scheduling, we anticipate retiring completed timelines as a matter
of course. Performing the same action from inside the breadcrumbs is
intended to provide similar functionality for legacy ringbuffer
submission.

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

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 7137b6f24f55..6996e22ba65b 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -257,17 +257,19 @@ static void signal_irq_work(struct irq_work *work)
list_del_rcu(>signal_link);
release = remove_signaling_context(b, ce);
spin_unlock(>signal_lock);
+   if (release) {
+   if (list_is_last_rcu(>link,
+>timeline->requests))
+   add_retire(b, ce->timeline);
+
+   intel_context_put(ce);
+   }
 
if (__dma_fence_signal(>fence))
/* We own signal_node now, xfer to local list */
signal = slist_add(>signal_node, signal);
else
i915_request_put(rq);
-
-   if (release) {
-   add_retire(b, ce->timeline);
-   intel_context_put(ce);
-   }
}
}
atomic_dec(>signaler_active);
-- 
2.20.1

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


Re: [Intel-gfx] [PATCH] drm/i915/gt: Limit VFE threads based on GT

2021-01-07 Thread Chris Wilson
Quoting Rodrigo Vivi (2021-01-07 19:50:37)
> On Fri, Oct 16, 2020 at 06:54:11PM +0100, Chris Wilson wrote:
> > MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
> > range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
> > based on plaform and the number of EU based on the number of slices and
> > subslices. This is a fixed number per platform/gt, so appropriately
> > limit the number of threads we spawn to match the device.
> > 
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024
> 
> we need to get this closed...

Unfortunately this failed the validation test. And as that test is still
not in CI, I cannot say why. My vote would be to remove the
clear_residuals until it works on all target platforms. Plus we clearly
need a hsw-gt1 in CI.
 
> >   bv->scratch_size = bv->surface_height * bv->surface_width;
> > @@ -244,7 +258,6 @@ gen7_emit_vfe_state(struct batch_chunk *batch,
> >   u32 urb_size, u32 curbe_size,
> >   u32 mode)
> >  {
> > - u32 urb_entries = bv->max_urb_entries;
> >   u32 threads = bv->max_primitives - 1;
> >   u32 *cs = batch_alloc_items(batch, 32, 8);
> >  
> > @@ -254,7 +267,7 @@ gen7_emit_vfe_state(struct batch_chunk *batch,
> >   *cs++ = 0;
> >  
> >   /* number of threads & urb entries for GPGPU vs Media Mode */
> > - *cs++ = threads << 16 | urb_entries << 8 | mode << 2;
> > + *cs++ = threads << 16 | 1 << 8 | mode << 2;
> 
> why urb_entries = 1 ?

We only used a single entry. There was no measurable benefit from
assigning more entries, and the importance of any side effects from doing
so unknown.

> the range is 0,64 and 0,128 depending on the sku.
> 
> in general there's a min of 32 URBs

Don't forget num_entries * entry_size must fit within the URB
allocation/allotment.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915: Wrap our timer_list.expires checking (rev3)

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/i915: Wrap our timer_list.expires 
checking (rev3)
URL   : https://patchwork.freedesktop.org/series/85551/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9562_full -> Patchwork_19279_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2] ([i915#198]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl3/igt@gem_ctx_isolation@preservation...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-skl1/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_ctx_persistence@idempotent:
- shard-hsw:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-hsw6/igt@gem_ctx_persiste...@idempotent.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_exec_whisper@basic-forked-all:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-glk9/igt@gem_exec_whis...@basic-forked-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-glk8/igt@gem_exec_whis...@basic-forked-all.html

  * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb:
- shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271]) +48 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-snb6/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html

  * igt@gem_userptr_blits@process-exit-mmap@wc:
- shard-hsw:  NOTRUN -> [SKIP][8] ([fdo#109271]) +111 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-hsw4/igt@gem_userptr_blits@process-exit-m...@wc.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl:  [PASS][9] -> [FAIL][10] ([i915#2521])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl6/igt@kms_async_fl...@alternate-sync-async-flip.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-skl5/igt@kms_async_fl...@alternate-sync-async-flip.html

  * igt@kms_color_chamelium@pipe-a-ctm-0-5:
- shard-hsw:  NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +4 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-hsw6/igt@kms_color_chamel...@pipe-a-ctm-0-5.html

  * igt@kms_color_chamelium@pipe-a-gamma:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +2 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-skl10/igt@kms_color_chamel...@pipe-a-gamma.html

  * igt@kms_color_chamelium@pipe-c-ctm-red-to-blue:
- shard-snb:  NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +3 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-snb6/igt@kms_color_chamel...@pipe-c-ctm-red-to-blue.html

  * igt@kms_cursor_crc@pipe-a-cursor-128x128-random:
- shard-skl:  [PASS][14] -> [FAIL][15] ([i915#54]) +5 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-128x128-random.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-128x128-random.html

  * igt@kms_cursor_crc@pipe-b-cursor-64x64-onscreen:
- shard-skl:  NOTRUN -> [FAIL][16] ([i915#54])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-64x64-onscreen.html

  * igt@kms_cursor_legacy@pipe-d-torture-move:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271]) +38 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-skl10/igt@kms_cursor_leg...@pipe-d-torture-move.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1:
- shard-skl:  [PASS][18] -> [FAIL][19] ([i915#2122]) +1 similar 
issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +2 similar 
issues
   [20]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Try to use fast+narrow link on eDP 
again and fall back to the old max strategy on failure
URL   : https://patchwork.freedesktop.org/series/85588/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9562 -> Patchwork_19284


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-tgl-y:   NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y:   [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +2 similar 
issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [PASS][4] -> [INCOMPLETE][5] ([i915#142] / 
[i915#2405])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/fi-byt-j1900/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka:  [PASS][6] -> [INCOMPLETE][7] ([i915#2369] / 
[i915#794])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@hugepages:
- fi-kbl-soraka:  [PASS][8] -> [DMESG-WARN][9] ([i915#2826])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-kbl-soraka/igt@i915_selftest@l...@hugepages.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/fi-kbl-soraka/igt@i915_selftest@l...@hugepages.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u:   [PASS][10] -> [DMESG-FAIL][11] ([i915#165])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@runner@aborted:
- fi-kbl-soraka:  NOTRUN -> [FAIL][12] ([i915#1436] / [i915#2295])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/fi-kbl-soraka/igt@run...@aborted.html
- fi-byt-j1900:   NOTRUN -> [FAIL][13] ([i915#1814] / [i915#2505])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/fi-byt-j1900/igt@run...@aborted.html

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries:
- fi-tgl-y:   [DMESG-WARN][14] ([i915#402]) -> [PASS][15] +2 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [DMESG-WARN][16] ([i915#2411] / [i915#402]) -> 
[PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@sanitycheck:
- fi-kbl-7500u:   [DMESG-WARN][18] ([i915#2605]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19284/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html

  
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295
  [i915#2369]: https://gitlab.freedesktop.org/drm/intel/issues/2369
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605
  [i915#2826]: 

Re: [Intel-gfx] [PATCH] drm/i915/gt: Limit VFE threads based on GT

2021-01-07 Thread Rodrigo Vivi
On Fri, Oct 16, 2020 at 06:54:11PM +0100, Chris Wilson wrote:
> MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
> range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
> based on plaform and the number of EU based on the number of slices and
> subslices. This is a fixed number per platform/gt, so appropriately
> limit the number of threads we spawn to match the device.
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024

we need to get this closed...

> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Prathap Kumar Valsan 
> Cc: Akeem G Abodunrin 
> Cc: Balestrieri Francesco 
> Cc: Bloomfield Jon 
> Cc:  # v5.7+
> ---
>  drivers/gpu/drm/i915/gt/gen7_renderclear.c | 35 +++---
>  1 file changed, 24 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c 
> b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> index d93d85cd3027..f3b8fea6226e 100644
> --- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> +++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> @@ -7,8 +7,6 @@
>  #include "i915_drv.h"
>  #include "intel_gpu_commands.h"
>  
> -#define MAX_URB_ENTRIES 64
> -#define STATE_SIZE (4 * 1024)
>  #define GT3_INLINE_DATA_DELAYS 0x1E00
>  #define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
>  
> @@ -34,8 +32,7 @@ struct batch_chunk {
>  };
>  
>  struct batch_vals {
> - u32 max_primitives;
> - u32 max_urb_entries;
> + u32 max_primitives; /* == number of VFE threads */
>   u32 cmd_size;
>   u32 state_size;
>   u32 state_start;
> @@ -50,18 +47,35 @@ static void
>  batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv)
>  {
>   if (IS_HASWELL(i915)) {
> - bv->max_primitives = 280;
> - bv->max_urb_entries = MAX_URB_ENTRIES;
> + switch (INTEL_INFO(i915)->gt) {
> + default:
> + case 1:
> + bv->max_primitives = 70;
> + break;
> + case 2:
> + bv->max_primitives = 140;
> + break;
> + case 3:
> + bv->max_primitives = 280;
> + break;
> + }
>   bv->surface_height = 16 * 16;
>   bv->surface_width = 32 * 2 * 16;
>   } else {
> - bv->max_primitives = 128;
> - bv->max_urb_entries = MAX_URB_ENTRIES / 2;
> + switch (INTEL_INFO(i915)->gt) {
> + default:
> + case 1: /* including vlv */
> + bv->max_primitives = 36;
> + break;
> + case 2:
> + bv->max_primitives = 128;
> + break;
> + }
>   bv->surface_height = 16 * 8;
>   bv->surface_width = 32 * 16;
>   }
>   bv->cmd_size = bv->max_primitives * 4096;
> - bv->state_size = STATE_SIZE;
> + bv->state_size = SZ_4K;
>   bv->state_start = bv->cmd_size;
>   bv->batch_size = bv->cmd_size + bv->state_size;
>   bv->scratch_size = bv->surface_height * bv->surface_width;
> @@ -244,7 +258,6 @@ gen7_emit_vfe_state(struct batch_chunk *batch,
>   u32 urb_size, u32 curbe_size,
>   u32 mode)
>  {
> - u32 urb_entries = bv->max_urb_entries;
>   u32 threads = bv->max_primitives - 1;
>   u32 *cs = batch_alloc_items(batch, 32, 8);
>  
> @@ -254,7 +267,7 @@ gen7_emit_vfe_state(struct batch_chunk *batch,
>   *cs++ = 0;
>  
>   /* number of threads & urb entries for GPGPU vs Media Mode */
> - *cs++ = threads << 16 | urb_entries << 8 | mode << 2;
> + *cs++ = threads << 16 | 1 << 8 | mode << 2;

why urb_entries = 1 ?

the range is 0,64 and 0,128 depending on the sku.

in general there's a min of 32 URBs

>  
>   *cs++ = 0;
>  
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Try to use fast+narrow link on eDP 
again and fall back to the old max strategy on failure
URL   : https://patchwork.freedesktop.org/series/85588/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1329:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


___
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: Wrap our timer_list.expires checking (rev2)

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Wrap our timer_list.expires 
checking (rev2)
URL   : https://patchwork.freedesktop.org/series/85584/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9562 -> Patchwork_19283


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-kbl-7500u:   [PASS][1] -> [DMESG-WARN][2] ([i915#2605])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-kbl-7500u/igt@i915_module_l...@reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/fi-kbl-7500u/igt@i915_module_l...@reload.html

  
 Possible fixes 

  * igt@i915_selftest@live@sanitycheck:
- fi-kbl-7500u:   [DMESG-WARN][3] ([i915#2605]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19283/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html

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

  [i915#2268]: https://gitlab.freedesktop.org/drm/intel/issues/2268
  [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605


Participating hosts (43 -> 37)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-tgl-y 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9562 -> Patchwork_19283

  CI-20190529: 20190529
  CI_DRM_9562: fc8d32007355b4babc37b621b3c9a4e0fe998d27 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5946: 641e5545213dd9a82d80a4e065013a138afb58ff @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19283: befcaa03c20aae2b9d2f6d79d8629dcd348aba17 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

befcaa03c20a drm/i915/gt: Remove timeslice suppression
838bdb07d26e drm/i915: Wrap our timer_list.expires checking

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Show the per-engine runtime in sysfs

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Show the per-engine runtime in sysfs
URL   : https://patchwork.freedesktop.org/series/85583/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9562 -> Patchwork_19282


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_getparams_basic@basic-subslice-total:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][3] -> [FAIL][4] ([i915#579])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@runner@aborted:
- fi-kbl-r:   NOTRUN -> [FAIL][5] ([i915#1569] / [i915#192] / 
[i915#193] / [i915#194] / [i915#2295])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/fi-kbl-r/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [DMESG-WARN][6] ([i915#2411] / [i915#402]) -> 
[PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@sanitycheck:
- fi-kbl-7500u:   [DMESG-WARN][8] ([i915#2605]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html

  * igt@prime_vgem@basic-fence-flip:
- fi-tgl-y:   [DMESG-WARN][10] ([i915#402]) -> [PASS][11] +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19282/fi-tgl-y/igt@prime_v...@basic-fence-flip.html

  
  [i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
  [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
  [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
  [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
  [i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579


Participating hosts (43 -> 38)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9562 -> Patchwork_19282

  CI-20190529: 20190529
  CI_DRM_9562: fc8d32007355b4babc37b621b3c9a4e0fe998d27 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5946: 641e5545213dd9a82d80a4e065013a138afb58ff @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19282: c471788f580bff25ee08eb7f609dc95e33b0ee9f @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c471788f580b drm/i915/gt: Show the per-engine runtime in sysfs

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pps: Reuse POWER_DOMAIN_DISPLAY_CORE in pps_{lock, unlock}

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915/pps: Reuse POWER_DOMAIN_DISPLAY_CORE in pps_{lock, unlock}
URL   : https://patchwork.freedesktop.org/series/85582/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9562 -> Patchwork_19281


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-y:   NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html

  * igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y:   [PASS][2] -> [DMESG-WARN][3] ([i915#402])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [DMESG-WARN][4] ([i915#2411] / [i915#402]) -> 
[PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@sanitycheck:
- fi-kbl-7500u:   [DMESG-WARN][6] ([i915#2605]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html

  * igt@prime_vgem@basic-fence-flip:
- fi-tgl-y:   [DMESG-WARN][8] ([i915#402]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19281/fi-tgl-y/igt@prime_v...@basic-fence-flip.html

  
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (43 -> 38)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9562 -> Patchwork_19281

  CI-20190529: 20190529
  CI_DRM_9562: fc8d32007355b4babc37b621b3c9a4e0fe998d27 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5946: 641e5545213dd9a82d80a4e065013a138afb58ff @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19281: 60b4502979d34a8e9b8b1b57dae40cd213ca7dca @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

60b4502979d3 drm/i915/pps: Reuse POWER_DOMAIN_DISPLAY_CORE in pps_{lock, unlock}

== Logs ==

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


[Intel-gfx] [PATCH 1/2] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure

2021-01-07 Thread Ville Syrjala
From: Ville Syrjälä 

Some new eDP panels don't like to operate at the max parameters, and
instead we need to go for an optimal confiugration. That unfortunately
doesn't work with older eDP panels which are generally only guaranteed
to work at the max parameters.

To solve these two conflicting requirements let's start with the optimal
setup, and if that fails we start again with the max parameters. The
downside is probably an extra modeset when we switch strategies but
I don't see a good way to avoid that.

For a bit of history we first tried to go for the fast+narrow in
commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
fast and narrow"). but that had to be reverted due to regression
on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
to max link rate and lane count on eDP"). So now we try to get
the best of both worlds by using both strategies.

v2: Deal with output_bpp and uapi vs. hw state split
Reword some comments
v3: Rebase

Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Albert Astals Cid  # v5.0 backport
Cc: Emanuele Panigati  # v5.0 backport
Cc: Matteo Iervasi  # v5.0 backport
Cc: Timo Aaltonen 
Cc: Kai-Heng Feng 
Reviewed-by: Manasi Navare 
References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
References: https://gitlab.freedesktop.org/drm/intel/issues/272
Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 75 ---
 2 files changed, 67 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1067bd073c95..9dfad41eb3dc 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1354,6 +1354,7 @@ struct intel_dp {
bool has_hdmi_sink;
bool has_audio;
bool reset_link_params;
+   bool use_max_params;
u8 dpcd[DP_RECEIVER_CAP_SIZE];
u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8a00e609085f..57c2140c1316 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -480,6 +480,13 @@ int intel_dp_get_link_train_fallback_values(struct 
intel_dp *intel_dp,
return -1;
}
 
+   if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
+   drm_dbg_kms(>drm,
+   "Retrying Link training for eDP with max 
parameters\n");
+   intel_dp->use_max_params = true;
+   return 0;
+   }
+
index = intel_dp_rate_index(intel_dp->common_rates,
intel_dp->num_common_rates,
link_rate);
@@ -2290,6 +2297,44 @@ intel_dp_compute_link_config_wide(struct intel_dp 
*intel_dp,
return -EINVAL;
 }
 
+/* Optimize link config in order: max bpp, min lanes, min clock */
+static int
+intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
+ struct intel_crtc_state *pipe_config,
+ const struct link_config_limits *limits)
+{
+   const struct drm_display_mode *adjusted_mode = 
_config->hw.adjusted_mode;
+   int bpp, clock, lane_count;
+   int mode_rate, link_clock, link_avail;
+
+   for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+   int output_bpp = 
intel_dp_output_bpp(pipe_config->output_format, bpp);
+
+   mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+  output_bpp);
+
+   for (lane_count = limits->min_lane_count;
+lane_count <= limits->max_lane_count;
+lane_count <<= 1) {
+   for (clock = limits->min_clock; clock <= 
limits->max_clock; clock++) {
+   link_clock = intel_dp->common_rates[clock];
+   link_avail = intel_dp_max_data_rate(link_clock,
+   lane_count);
+
+   if (mode_rate <= link_avail) {
+   pipe_config->lane_count = lane_count;
+   pipe_config->pipe_bpp = bpp;
+   pipe_config->port_clock = link_clock;
+
+   return 0;
+   }
+   }
+   }
+   }
+
+   return -EINVAL;
+}
+
 static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc)
 {
int i, num_bpc;
@@ -2513,13 +2558,14 @@ intel_dp_compute_link_config(struct intel_encoder 

[Intel-gfx] [PATCH 2/2] drm: Refactor intel_dp_compute_link_config_*()

2021-01-07 Thread Ville Syrjala
From: Ville Syrjälä 

Pull the common parts of intel_dp_compute_link_config_wide()
and intel_dp_compute_link_config_fast() into a shared helper
to avoid duplicated code.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 74 ++---
 1 file changed, 43 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 57c2140c1316..d682cf57e455 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2259,34 +2259,47 @@ intel_dp_adjust_compliance_config(struct intel_dp 
*intel_dp,
}
 }
 
+static bool
+intel_dp_link_config_valid(const struct intel_crtc_state *crtc_state,
+  int bpp, int link_clock, int lane_count)
+{
+   const struct drm_display_mode *adjusted_mode =
+   _state->hw.adjusted_mode;
+   int output_bpp = intel_dp_output_bpp(crtc_state->output_format, bpp);
+   int mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+  output_bpp);
+   int link_avail = intel_dp_max_data_rate(link_clock, lane_count);
+
+   return mode_rate <= link_avail;
+}
+
 /* Optimize link config in order: max bpp, min clock, min lanes */
 static int
 intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
- struct intel_crtc_state *pipe_config,
+ struct intel_crtc_state *crtc_state,
  const struct link_config_limits *limits)
 {
-   struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
-   int bpp, clock, lane_count;
-   int mode_rate, link_clock, link_avail;
+   int bpp;
 
for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
-   int output_bpp = 
intel_dp_output_bpp(pipe_config->output_format, bpp);
+   int clock;
 
-   mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
-  output_bpp);
+   for (clock = limits->min_clock;
+clock <= limits->max_clock;
+clock++) {
+   int lane_count;
 
-   for (clock = limits->min_clock; clock <= limits->max_clock; 
clock++) {
for (lane_count = limits->min_lane_count;
 lane_count <= limits->max_lane_count;
 lane_count <<= 1) {
-   link_clock = intel_dp->common_rates[clock];
-   link_avail = intel_dp_max_data_rate(link_clock,
-   lane_count);
+   int link_clock = intel_dp->common_rates[clock];
 
-   if (mode_rate <= link_avail) {
-   pipe_config->lane_count = lane_count;
-   pipe_config->pipe_bpp = bpp;
-   pipe_config->port_clock = link_clock;
+   if (intel_dp_link_config_valid(crtc_state, bpp,
+  link_clock,
+  lane_count)) {
+   crtc_state->pipe_bpp = bpp;
+   crtc_state->port_clock = link_clock;
+   crtc_state->lane_count = lane_count;
 
return 0;
}
@@ -2300,31 +2313,30 @@ intel_dp_compute_link_config_wide(struct intel_dp 
*intel_dp,
 /* Optimize link config in order: max bpp, min lanes, min clock */
 static int
 intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
- struct intel_crtc_state *pipe_config,
+ struct intel_crtc_state *crtc_state,
  const struct link_config_limits *limits)
 {
-   const struct drm_display_mode *adjusted_mode = 
_config->hw.adjusted_mode;
-   int bpp, clock, lane_count;
-   int mode_rate, link_clock, link_avail;
+   int bpp;
 
for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
-   int output_bpp = 
intel_dp_output_bpp(pipe_config->output_format, bpp);
-
-   mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
-  output_bpp);
+   int lane_count;
 
for (lane_count = limits->min_lane_count;
 lane_count <= limits->max_lane_count;
 lane_count <<= 1) {
-   for (clock = limits->min_clock; clock <= 
limits->max_clock; clock++) {
-   link_clock = 

Re: [Intel-gfx] [PATCH V3] drm/i915/gen9_bc : Add TGP PCH support

2021-01-07 Thread Jani Nikula
On Tue, 05 Jan 2021, Tejas Upadhyay 
 wrote:
> We have TGP PCH support for Tigerlake and Rocketlake. Similarly
> now TGP PCH can be used with Cometlake CPU.
>
> Changes since V2 :
> - IS_COMETLAKE replaced with IS_GEN9_BC
> - VBT ddc pin remapping added
> - Added dedicated HPD pin and DDC pin handling API
> Changes since V1 :
> - Matched HPD Pin mapping for PORT C and PORT D of CML CPU.
>
> Cc: Matt Roper 
> Signed-off-by: Tejas Upadhyay 
> ---
>  drivers/gpu/drm/i915/display/intel_bios.c|  9 +
>  drivers/gpu/drm/i915/display/intel_ddi.c |  7 +--
>  drivers/gpu/drm/i915/display/intel_display.c |  7 ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c| 20 
>  drivers/gpu/drm/i915/intel_pch.c |  3 ++-
>  5 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 06c3310446a2..67f9c0d8d1f3 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1623,6 +1623,12 @@ static const u8 icp_ddc_pin_map[] = {
>   [TGL_DDC_BUS_PORT_6] = GMBUS_PIN_14_TC6_TGP,
>  };
>  
> +static const u8 gen9bc_tgp_ddc_pin_map[] = {
> + [DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
> + [DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
> + [DDC_BUS_DDI_D] = GMBUS_PIN_10_TC2_ICP,
> +};
> +
>  static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
>  {
>   const u8 *ddc_pin_map;
> @@ -1630,6 +1636,9 @@ static u8 map_ddc_pin(struct drm_i915_private 
> *dev_priv, u8 vbt_pin)
>  
>   if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1) {
>   return vbt_pin;
> + } else if (HAS_PCH_TGP(dev_priv) && IS_GEN9_BC(dev_priv)) {
> + ddc_pin_map = gen9bc_tgp_ddc_pin_map;
> + n_entries = ARRAY_SIZE(gen9bc_tgp_ddc_pin_map);
>   } else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP) {
>   ddc_pin_map = icp_ddc_pin_map;
>   n_entries = ARRAY_SIZE(icp_ddc_pin_map);
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 17eaa56c5a99..55d6329dc9c9 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -5301,7 +5301,9 @@ static enum hpd_pin dg1_hpd_pin(struct drm_i915_private 
> *dev_priv,
>  static enum hpd_pin tgl_hpd_pin(struct drm_i915_private *dev_priv,
>   enum port port)
>  {
> - if (port >= PORT_TC1)
> + if (IS_GEN9_BC(dev_priv) && port >= PORT_C)
> + return HPD_PORT_TC1 + port - PORT_C;
> + else if (port >= PORT_TC1)
>   return HPD_PORT_TC1 + port - PORT_TC1;
>   else
>   return HPD_PORT_A + port - PORT_A;
> @@ -5457,7 +5459,8 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   encoder->hpd_pin = dg1_hpd_pin(dev_priv, port);
>   else if (IS_ROCKETLAKE(dev_priv))
>   encoder->hpd_pin = rkl_hpd_pin(dev_priv, port);
> - else if (INTEL_GEN(dev_priv) >= 12)
> + else if (INTEL_GEN(dev_priv) >= 12 || (IS_GEN9_BC(dev_priv) &&
> +HAS_PCH_TGP(dev_priv)))
>   encoder->hpd_pin = tgl_hpd_pin(dev_priv, port);
>   else if (IS_JSL_EHL(dev_priv))
>   encoder->hpd_pin = ehl_hpd_pin(dev_priv, port);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f2c48e5cdb43..5a75ce1f78ac 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16194,11 +16194,12 @@ static void intel_setup_outputs(struct 
> drm_i915_private *dev_priv)
>* register */
>   found = intel_de_read(dev_priv, SFUSE_STRAP);

Is it okay to read SFUSE_STRAP if it's not there? Maybe something like
this instead, with the comment above fixed?

if (HAS_PCH_TGP(dev_priv)) {
found = (SFUSE_STRAP_DDIB_DETECTED |
 SFUSE_STRAP_DDIC_DETECTED |
 SFUSE_STRAP_DDID_DETECTED);
} else {
found = intel_de_read(dev_priv, SFUSE_STRAP);
}

>  
> - if (found & SFUSE_STRAP_DDIB_DETECTED)
> + /* W/A due to lack of STRAP config on TGP PCH*/
> + if (found & SFUSE_STRAP_DDIB_DETECTED || HAS_PCH_TGP(dev_priv))
>   intel_ddi_init(dev_priv, PORT_B);
> - if (found & SFUSE_STRAP_DDIC_DETECTED)
> + if (found & SFUSE_STRAP_DDIC_DETECTED || HAS_PCH_TGP(dev_priv))
>   intel_ddi_init(dev_priv, PORT_C);
> - if (found & SFUSE_STRAP_DDID_DETECTED)
> + if (found & SFUSE_STRAP_DDID_DETECTED || HAS_PCH_TGP(dev_priv))
>   intel_ddi_init(dev_priv, PORT_D);
>   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pps: Add PPS power domain (rev3)

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915/pps: Add PPS power domain (rev3)
URL   : https://patchwork.freedesktop.org/series/85470/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9562 -> Patchwork_19280


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +2 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries:
- fi-tgl-y:   [DMESG-WARN][3] ([i915#402]) -> [PASS][4] +2 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [DMESG-WARN][5] ([i915#2411] / [i915#402]) -> 
[PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@sanitycheck:
- fi-kbl-7500u:   [DMESG-WARN][7] ([i915#2605]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19280/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html

  
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (43 -> 38)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9562 -> Patchwork_19280

  CI-20190529: 20190529
  CI_DRM_9562: fc8d32007355b4babc37b621b3c9a4e0fe998d27 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5946: 641e5545213dd9a82d80a4e065013a138afb58ff @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19280: f6373225edb871afc10b20f1bc1747ef55db288c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f6373225edb8 drm/i915/pps: Reuse POWER_DOMAIN_DISPLAY_CORE in pps_{lock, unlock}

== Logs ==

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


Re: [Intel-gfx] [PATCH v2] drm/i915/debugfs : PM_REQ and PM_RES registers

2021-01-07 Thread Jani Nikula
On Mon, 04 Jan 2021, Saichandana S  wrote:
> From: Saichandana 
>
> PM_REQ register provides the value of the last PM request from PCU to
> Display Engine.PM_RES register provides the value of the last PM
> response from Display Engine to PCU.This debugfs will be used by
> DC9 IGT test to know about "DC9 Ready" status.
>
> B.Spec : 49501, 49502
>
> Signed-off-by: Saichandana 
> ---
>  .../drm/i915/display/intel_display_debugfs.c  | 30 +++
>  drivers/gpu/drm/i915/i915_reg.h   |  8 +
>  2 files changed, 38 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index cd7e5519ee7d..551fb1a90bb3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -559,6 +559,36 @@ static int i915_dmc_info(struct seq_file *m, void 
> *unused)
>   return 0;
>  }
>  
> +static int i915_pm_req_res_info(struct seq_file *m, void *unused)
> +{
> + struct drm_i915_private *dev_priv = node_to_i915(m->private);

All new code should call the local variable "i915".

> + struct intel_csr *csr = _priv->csr;
> + const char *status;
> +
> + if (!HAS_CSR(dev_priv))
> + return -ENODEV;
> + if (!csr->dmc_payload)
> + return 0;
> + seq_printf(m, "PM debug request 0 (0x45284): 0x%08x\n",
> +intel_de_read(dev_priv, PM_REQ_DBG_0));
> + seq_printf(m, "PM debug request 1 (0x45288): 0x%08x\n",
> +intel_de_read(dev_priv, PM_REQ_DBG_1));
> + seq_printf(m, "PM debug response 0 (0x4528C): 0x%08x\n",
> +intel_de_read(dev_priv, PM_RSP_DBG_0));
> + seq_printf(m, "PM debug response 1 (0x45290): 0x%08x\n",
> +intel_de_read(dev_priv, PM_RSP_DBG_1));

Like I said before [1], do *not* dump the registers. We have userspace
tools for dumping register contents as-is when you need that for debug
purposes. And even the userspace tool can do some register content
parsing. See tools/intel_reg in igt.

The only reason to have a debugfs file is to provide some other, added
value that a register dump can't provide.

[1] http://lore.kernel.org/r/87mtyl8vpu@intel.com

> + status = (intel_de_read(dev_priv, PM_RSP_DBG_1) & MASK_DC9_BIT) ? "yes" 
> : "no";

See yesno() in i915_utils.h. You probably don't want the local variable
for the string.

> +
> + seq_printf(m, "Time to Next Fill = 0x%0x\n",
> +(intel_de_read(dev_priv, PM_RSP_DBG_0) & ~MASK_RSP_0));
> + seq_printf(m, "Time to Next VBI = 0x%0x\n",
> +((intel_de_read(dev_priv, PM_RSP_DBG_0) & MASK_RSP_0)) >> 
> 16);
> + seq_printf(m, "Selective Exit Latency = 0x%0x\n",
> +(intel_de_read(dev_priv, PM_RSP_DBG_1) & MASK_RSP_1));

There's a bunch of unnecessary parenthesis around the 3rd parameter to
seq_printf.

> + seq_printf(m, "DC9 Ready = %s\n", status);
> + return 0;
> +}
> +
>  static void intel_seq_print_mode(struct seq_file *m, int tabs,
>const struct drm_display_mode *mode)
>  {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0023c023f472..3e9ed555f928 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -371,6 +371,14 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define VLV_G3DCTL   _MMIO(0x9024)
>  #define VLV_GSCKGCTL _MMIO(0x9028)
>  
> +#define PM_REQ_DBG_0 _MMIO(0x45284)
> +#define PM_REQ_DBG_1 _MMIO(0x45288)
> +#define PM_RSP_DBG_0 _MMIO(0x4528C)
> +#define PM_RSP_DBG_1 _MMIO(0x45290)
> +#define MASK_RSP_0   (0x << 16)
> +#define MASK_RSP_1   (7 << 0)
> +#define MASK_DC9_BIT (1 << 17)

This is a random location in i915_reg.h, out of place.

Please also read the big comment near the top of this file.

BR,
Jani.


> +
>  #define GEN6_MBCTL   _MMIO(0x0907c)
>  #define   GEN6_MBCTL_ENABLE_BOOT_FETCH   (1 << 4)
>  #define   GEN6_MBCTL_CTX_FETCH_NEEDED(1 << 3)

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


Re: [Intel-gfx] [PATCH 36/56] drm/i915: Fair low-latency scheduling

2021-01-07 Thread Matthew Brost
On Thu, Jan 07, 2021 at 04:45:31PM +, Chris Wilson wrote:
> Quoting Matthew Brost (2021-01-07 16:05:07)
> > On Tue, Dec 29, 2020 at 12:01:25PM +, Chris Wilson wrote:
> > > The first "scheduler" was a topographical sorting of requests into
> > > priority order. The execution order was deterministic, the earliest
> > > submitted, highest priority request would be executed first. Priority
> > > inheritance ensured that inversions were kept at bay, and allowed us to
> > > dynamically boost priorities (e.g. for interactive pageflips).
> > > 
> > > The minimalistic timeslicing scheme was an attempt to introduce fairness
> > > between long running requests, by evicting the active request at the end
> > > of a timeslice and moving it to the back of its priority queue (while
> > > ensuring that dependencies were kept in order). For short running
> > > requests from many clients of equal priority, the scheme is still very
> > > much FIFO submission ordering, and as unfair as before.
> > > 
> > > To impose fairness, we need an external metric that ensures that clients
> > > are interpersed, so we don't execute one long chain from client A before
> > > executing any of client B. This could be imposed by the clients
> > > themselves by using fences based on an external clock, that is they only
> > > submit work for a "frame" at frame-intervals, instead of submitting as
> > > much work as they are able to. The standard SwapBuffers approach is akin
> > > to double bufferring, where as one frame is being executed, the next is
> > > being submitted, such that there is always a maximum of two frames per
> > > client in the pipeline and so ideally maintains consistent input-output
> > > latency. Even this scheme exhibits unfairness under load as a single
> > > client will execute two frames back to back before the next, and with
> > > enough clients, deadlines will be missed.
> > > 
> > > The idea introduced by BFS/MuQSS is that fairness is introduced by
> > > metering with an external clock. Every request, when it becomes ready to
> > > execute is assigned a virtual deadline, and execution order is then
> > > determined by earliest deadline. Priority is used as a hint, rather than
> > > strict ordering, where high priority requests have earlier deadlines,
> > > but not necessarily earlier than outstanding work. Thus work is executed
> > > in order of 'readiness', with timeslicing to demote long running work.
> > > 
> > > The Achille's heel of this scheduler is its strong preference for
> > > low-latency and favouring of new queues. Whereas it was easy to dominate
> > > the old scheduler by flooding it with many requests over a short period
> > > of time, the new scheduler can be dominated by a 'synchronous' client
> > > that waits for each of its requests to complete before submitting the
> > > next. As such a client has no history, it is always considered
> > > ready-to-run and receives an earlier deadline than the long running
> > > requests. This is compensated for by refreshing the current execution's
> > > deadline and by disallowing preemption for timeslice shuffling.
> > > 
> > > To check the impact on throughput (often the downfall of latency
> > > sensitive schedulers), we used gem_wsim to simulate various transcode
> > > workloads with different load balancers, and varying the number of
> > > competing [heterogenous] clients.
> > > 
> > > +delta%--+
> > > |a   |
> > > |a   |
> > > |aa  |
> > > |aa  |
> > > |aa  |
> > > |aa  |
> > > |   aaa  |
> > > |    |
> > > |   a  a |
> > > |   a aa |
> > > |a  aa   a  aa aa   a   a|
> > > |A_| |
> > > ++
> > >N  Min   MaxMedian   AvgStddev
> > >  108   -23.982194 28.421527  -0.077474828  -0.0726504180.16179718
> > > 
> > > The impact was on average 0.1% under contention due to the change in
> > > context execution order and number of context switches. The biggest
> > > swings are due to the execution ordering favouring one client or another,
> > > and maybe room for improvement.
> > > 
> > 
> > I haven't dug into 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Wrap our timer_list.expires checking (rev3)

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/i915: Wrap our timer_list.expires 
checking (rev3)
URL   : https://patchwork.freedesktop.org/series/85551/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9562 -> Patchwork_19279


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2:  [PASS][1] -> [FAIL][2] ([i915#1888])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_mmap_gtt@basic:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@gem_mmap_...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/fi-tgl-y/igt@gem_mmap_...@basic.html

  * igt@i915_selftest@live@gem:
- fi-bsw-n3050:   [PASS][5] -> [DMESG-WARN][6] ([i915#2826])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-bsw-n3050/igt@i915_selftest@l...@gem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/fi-bsw-n3050/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@gem_contexts:
- fi-bsw-n3050:   [PASS][7] -> [INCOMPLETE][8] ([i915#2369])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-bsw-n3050/igt@i915_selftest@live@gem_contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/fi-bsw-n3050/igt@i915_selftest@live@gem_contexts.html

  * igt@runner@aborted:
- fi-bsw-n3050:   NOTRUN -> [FAIL][9] ([i915#1436] / [i915#483])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/fi-bsw-n3050/igt@run...@aborted.html

  
 Possible fixes 

  * igt@debugfs_test@read_all_entries:
- fi-tgl-y:   [DMESG-WARN][10] ([i915#402]) -> [PASS][11] +2 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [DMESG-WARN][12] ([i915#2411] / [i915#402]) -> 
[PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2369]: https://gitlab.freedesktop.org/drm/intel/issues/2369
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#2826]: https://gitlab.freedesktop.org/drm/intel/issues/2826
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#483]: https://gitlab.freedesktop.org/drm/intel/issues/483


Participating hosts (43 -> 38)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9562 -> Patchwork_19279

  CI-20190529: 20190529
  CI_DRM_9562: fc8d32007355b4babc37b621b3c9a4e0fe998d27 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5946: 641e5545213dd9a82d80a4e065013a138afb58ff @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19279: 00408bfe5158970f1350607258989d54d4845eaa @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

00408bfe5158 drm/i915/gt: Remove timeslice suppression
48f5aaacb2c8 drm/i915: Wrap our timer_list.expires checking

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19279/index.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 series starting with [v2,1/2] drm/i915: Wrap our timer_list.expires checking (rev3)

2021-01-07 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/i915: Wrap our timer_list.expires 
checking (rev3)
URL   : https://patchwork.freedesktop.org/series/85551/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 
'wakeref_auto_timeout' - unexpected unlock
+drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y


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


Re: [Intel-gfx] [PATCH 36/56] drm/i915: Fair low-latency scheduling

2021-01-07 Thread Chris Wilson
Quoting Matthew Brost (2021-01-07 16:05:07)
> On Tue, Dec 29, 2020 at 12:01:25PM +, Chris Wilson wrote:
> > The first "scheduler" was a topographical sorting of requests into
> > priority order. The execution order was deterministic, the earliest
> > submitted, highest priority request would be executed first. Priority
> > inheritance ensured that inversions were kept at bay, and allowed us to
> > dynamically boost priorities (e.g. for interactive pageflips).
> > 
> > The minimalistic timeslicing scheme was an attempt to introduce fairness
> > between long running requests, by evicting the active request at the end
> > of a timeslice and moving it to the back of its priority queue (while
> > ensuring that dependencies were kept in order). For short running
> > requests from many clients of equal priority, the scheme is still very
> > much FIFO submission ordering, and as unfair as before.
> > 
> > To impose fairness, we need an external metric that ensures that clients
> > are interpersed, so we don't execute one long chain from client A before
> > executing any of client B. This could be imposed by the clients
> > themselves by using fences based on an external clock, that is they only
> > submit work for a "frame" at frame-intervals, instead of submitting as
> > much work as they are able to. The standard SwapBuffers approach is akin
> > to double bufferring, where as one frame is being executed, the next is
> > being submitted, such that there is always a maximum of two frames per
> > client in the pipeline and so ideally maintains consistent input-output
> > latency. Even this scheme exhibits unfairness under load as a single
> > client will execute two frames back to back before the next, and with
> > enough clients, deadlines will be missed.
> > 
> > The idea introduced by BFS/MuQSS is that fairness is introduced by
> > metering with an external clock. Every request, when it becomes ready to
> > execute is assigned a virtual deadline, and execution order is then
> > determined by earliest deadline. Priority is used as a hint, rather than
> > strict ordering, where high priority requests have earlier deadlines,
> > but not necessarily earlier than outstanding work. Thus work is executed
> > in order of 'readiness', with timeslicing to demote long running work.
> > 
> > The Achille's heel of this scheduler is its strong preference for
> > low-latency and favouring of new queues. Whereas it was easy to dominate
> > the old scheduler by flooding it with many requests over a short period
> > of time, the new scheduler can be dominated by a 'synchronous' client
> > that waits for each of its requests to complete before submitting the
> > next. As such a client has no history, it is always considered
> > ready-to-run and receives an earlier deadline than the long running
> > requests. This is compensated for by refreshing the current execution's
> > deadline and by disallowing preemption for timeslice shuffling.
> > 
> > To check the impact on throughput (often the downfall of latency
> > sensitive schedulers), we used gem_wsim to simulate various transcode
> > workloads with different load balancers, and varying the number of
> > competing [heterogenous] clients.
> > 
> > +delta%--+
> > |a   |
> > |a   |
> > |aa  |
> > |aa  |
> > |aa  |
> > |aa  |
> > |   aaa  |
> > |    |
> > |   a  a |
> > |   a aa |
> > |a  aa   a  aa aa   a   a|
> > |A_| |
> > ++
> >N  Min   MaxMedian   AvgStddev
> >  108   -23.982194 28.421527  -0.077474828  -0.0726504180.16179718
> > 
> > The impact was on average 0.1% under contention due to the change in
> > context execution order and number of context switches. The biggest
> > swings are due to the execution ordering favouring one client or another,
> > and maybe room for improvement.
> > 
> 
> I haven't dug into this series deeply but it does seem plausible for
> execlist submission. However this new scheduler seems completely broken
> for Guc submission.

Underneath it's the same topological sort, just with a different 

Re: [Intel-gfx] [PATCH v3] drm/i915/gt: Remove timeslice suppression

2021-01-07 Thread Andi Shyti
Hi Chris,

On Thu, Jan 07, 2021 at 11:05:55AM +, Chris Wilson wrote:
> In the next^W future patch, we remove the strict priority system and
> continuously re-evaluate the relative priority of tasks. As such we need
> to enable the timeslice whenever there is more than one context in the
> pipeline. This simplifies the decision and removes some of the tweaks to
> suppress timeslicing, allowing us to lift the timeslice enabling to a
> common spot at the end of running the submission tasklet.
> 
> One consequence of the suppression is that it was reducing fairness
> between virtual engines on an over saturated system; undermining the
> principle for timeslicing.
> 
> v2: Commentary
> v3: Commentary for the right cancel_timer()
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2802
> Testcase: igt/gem_exec_balancer/fairslice
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 

I don't know if you have answered all Tvrtko's question, but I
to me this looks good.

Reviewed-by: Andi Shyti 

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove obj->mm.lock! (rev13)

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove obj->mm.lock! (rev13)
URL   : https://patchwork.freedesktop.org/series/82337/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9562 -> Patchwork_19278


Summary
---

  **FAILURE**

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

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@prime_vgem@basic-userptr:
- fi-tgl-y:   [PASS][1] -> [SKIP][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@prime_v...@basic-userptr.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-tgl-y/igt@prime_v...@basic-userptr.html
- fi-icl-u2:  [PASS][3] -> [SKIP][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-icl-u2/igt@prime_v...@basic-userptr.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-icl-u2/igt@prime_v...@basic-userptr.html
- fi-tgl-u2:  [PASS][5] -> [SKIP][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-u2/igt@prime_v...@basic-userptr.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-tgl-u2/igt@prime_v...@basic-userptr.html
- fi-cml-s:   [PASS][7] -> [SKIP][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-cml-s/igt@prime_v...@basic-userptr.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-cml-s/igt@prime_v...@basic-userptr.html
- fi-icl-y:   [PASS][9] -> [SKIP][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-icl-y/igt@prime_v...@basic-userptr.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-icl-y/igt@prime_v...@basic-userptr.html
- fi-cml-u2:  [PASS][11] -> [SKIP][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-cml-u2/igt@prime_v...@basic-userptr.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-cml-u2/igt@prime_v...@basic-userptr.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@prime_vgem@basic-userptr:
- {fi-ehl-1}: [PASS][13] -> [SKIP][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-ehl-1/igt@prime_v...@basic-userptr.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-ehl-1/igt@prime_v...@basic-userptr.html
- {fi-tgl-dsi}:   [PASS][15] -> [SKIP][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-dsi/igt@prime_v...@basic-userptr.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-tgl-dsi/igt@prime_v...@basic-userptr.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_sync@basic-each:
- fi-tgl-y:   [PASS][17] -> [DMESG-WARN][18] ([i915#402])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-tgl-y/igt@gem_s...@basic-each.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-tgl-y/igt@gem_s...@basic-each.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:[PASS][19] -> [SKIP][20] ([fdo#109271])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-pnv-d510/igt@prime_v...@basic-userptr.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-pnv-d510/igt@prime_v...@basic-userptr.html
- fi-cfl-8700k:   [PASS][21] -> [SKIP][22] ([fdo#109271])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-cfl-8700k/igt@prime_v...@basic-userptr.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-cfl-8700k/igt@prime_v...@basic-userptr.html
- fi-skl-6600u:   [PASS][23] -> [SKIP][24] ([fdo#109271])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-skl-6600u/igt@prime_v...@basic-userptr.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-skl-6600u/igt@prime_v...@basic-userptr.html
- fi-bsw-n3050:   [PASS][25] -> [SKIP][26] ([fdo#109271])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9562/fi-bsw-n3050/igt@prime_v...@basic-userptr.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19278/fi-bsw-n3050/igt@prime_v...@basic-userptr.html
- fi-bsw-kefka:   [PASS][27] -> [SKIP][28] ([fdo#109271])
   [27]: 

Re: [Intel-gfx] [PATCH 36/56] drm/i915: Fair low-latency scheduling

2021-01-07 Thread Matthew Brost
On Tue, Dec 29, 2020 at 12:01:25PM +, Chris Wilson wrote:
> The first "scheduler" was a topographical sorting of requests into
> priority order. The execution order was deterministic, the earliest
> submitted, highest priority request would be executed first. Priority
> inheritance ensured that inversions were kept at bay, and allowed us to
> dynamically boost priorities (e.g. for interactive pageflips).
> 
> The minimalistic timeslicing scheme was an attempt to introduce fairness
> between long running requests, by evicting the active request at the end
> of a timeslice and moving it to the back of its priority queue (while
> ensuring that dependencies were kept in order). For short running
> requests from many clients of equal priority, the scheme is still very
> much FIFO submission ordering, and as unfair as before.
> 
> To impose fairness, we need an external metric that ensures that clients
> are interpersed, so we don't execute one long chain from client A before
> executing any of client B. This could be imposed by the clients
> themselves by using fences based on an external clock, that is they only
> submit work for a "frame" at frame-intervals, instead of submitting as
> much work as they are able to. The standard SwapBuffers approach is akin
> to double bufferring, where as one frame is being executed, the next is
> being submitted, such that there is always a maximum of two frames per
> client in the pipeline and so ideally maintains consistent input-output
> latency. Even this scheme exhibits unfairness under load as a single
> client will execute two frames back to back before the next, and with
> enough clients, deadlines will be missed.
> 
> The idea introduced by BFS/MuQSS is that fairness is introduced by
> metering with an external clock. Every request, when it becomes ready to
> execute is assigned a virtual deadline, and execution order is then
> determined by earliest deadline. Priority is used as a hint, rather than
> strict ordering, where high priority requests have earlier deadlines,
> but not necessarily earlier than outstanding work. Thus work is executed
> in order of 'readiness', with timeslicing to demote long running work.
> 
> The Achille's heel of this scheduler is its strong preference for
> low-latency and favouring of new queues. Whereas it was easy to dominate
> the old scheduler by flooding it with many requests over a short period
> of time, the new scheduler can be dominated by a 'synchronous' client
> that waits for each of its requests to complete before submitting the
> next. As such a client has no history, it is always considered
> ready-to-run and receives an earlier deadline than the long running
> requests. This is compensated for by refreshing the current execution's
> deadline and by disallowing preemption for timeslice shuffling.
> 
> To check the impact on throughput (often the downfall of latency
> sensitive schedulers), we used gem_wsim to simulate various transcode
> workloads with different load balancers, and varying the number of
> competing [heterogenous] clients.
> 
> +delta%--+
> |a   |
> |a   |
> |aa  |
> |aa  |
> |aa  |
> |aa  |
> |   aaa  |
> |    |
> |   a  a |
> |   a aa |
> |a  aa   a  aa aa   a   a|
> |A_| |
> ++
>N  Min   MaxMedian   AvgStddev
>  108   -23.982194 28.421527  -0.077474828  -0.0726504180.16179718
> 
> The impact was on average 0.1% under contention due to the change in
> context execution order and number of context switches. The biggest
> swings are due to the execution ordering favouring one client or another,
> and maybe room for improvement.
> 

I haven't dug into this series deeply but it does seem plausible for
execlist submission. However this new scheduler seems completely broken
for Guc submission. The scheduler really isn't used that much with GuC
submission but when it is the old one works perfectly. The vfunc for
the scheduler is deleted in patch #25. I don't think that is good idea
as it appears we are trending to 2 separate schedulers.

Lastly this 

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce Intel PXP component - Mesa single session (rev19)

2021-01-07 Thread Vivi, Rodrigo
On Wed, 2021-01-06 at 23:47 +, Patchwork wrote:
> == Series Details ==
> 
> Series: Introduce Intel PXP component - Mesa single session (rev19)
> URL   : https://patchwork.freedesktop.org/series/84620/
> State : warning
> 
> == Summary ==
> 
> $ dim checkpatch origin/drm-tip
> fbdd4e2e287d drm/i915/pxp: Introduce Intel PXP component
> -:119: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #119: 
> new file mode 100644
> 
> total: 0 errors, 1 warnings, 0 checks, 194 lines checked
> fdb764188c85 drm/i915/pxp: set KCR reg init during the boot time
> 20c2f538fd26 drm/i915/pxp: Implement funcs to create the TEE channel
> -:8: WARNING:TYPO_SPELLING: 'defualt' may be misspelled - perhaps
> 'default'?
> #8: 
> (defualt) session.
>  ^^^
> 
> -:85: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #85: 
> new file mode 100644
> 
> total: 0 errors, 2 warnings, 0 checks, 253 lines checked
> e77ddc43854a drm/i915/pxp: Create the arbitrary session after boot
> -:68: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #68: 
> new file mode 100644
> 
> total: 0 errors, 1 warnings, 0 checks, 330 lines checked
> 60d904942ebb drm/i915/pxp: Func to send hardware session termination
> -:53: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #53: 
> new file mode 100644
> 
> total: 0 errors, 1 warnings, 0 checks, 222 lines checked
> e06c62d5fd8d drm/i915/pxp: Enable PXP irq worker and callback stub
> -:51: WARNING:LONG_LINE_COMMENT: line length of 113 exceeds 100
> columns
> #51: FILE: drivers/gpu/drm/i915/i915_reg.h:7970:
> +#define GEN11_CRYPTO_INTR_MASK _MMIO(0x1900f0) /* crypto
> mask is in bit31-16 (Engine1 Interrupt Mask) */
> 
> total: 0 errors, 1 warnings, 0 checks, 230 lines checked
> 2b451866410d drm/i915/pxp: Destroy arb session upon teardown
> f74cff978a9a drm/i915/pxp: Enable PXP power management
> -:78: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #78: 
> new file mode 100644
> 
> total: 0 errors, 1 warnings, 0 checks, 148 lines checked
> f45f6bf27787 drm/i915/pxp: Expose session state for display
> protection flip
> ed1733ee9985 mei: pxp: export pavp client to me client bus
> -:32: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s),
> does MAINTAINERS need updating?
> #32: 
> new file mode 100644
> 
> total: 0 errors, 1 warnings, 0 checks, 277 lines checked
> 5ed5ea72d630 drm/i915/uapi: introduce drm_i915_gem_create_ext
> -:12: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Joonas
> Lahtinen joonas.lahti...@linux.intel.com'
> #12: 
> Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com

Please make sure you address some of the checkpatch complains like this

> 
> -:13: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Matthew Auld 
> matthew.a...@intel.com'
> #13: 
> Cc: Matthew Auld matthew.a...@intel.com

this

> 
> -:46: ERROR:CODE_INDENT: code indent should use tabs where possible
> #46: FILE: drivers/gpu/drm/i915/i915_gem.c:265:
> +    struct drm_i915_private *i915;$

this

> 
> -:46: WARNING:LEADING_SPACE: please, no spaces at the start of a line
> #46: FILE: drivers/gpu/drm/i915/i915_gem.c:265:
> +    struct drm_i915_private *i915;$
> 

this


> -:50: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open
> parenthesis
> #50: FILE: drivers/gpu/drm/i915/i915_gem.c:269:
> +static int __create_setparam(struct drm_i915_gem_object_param *args,
> +   struct
> create_ext *ext_data)
> 

this

> -:95: CHECK:LINE_SPACING: Please don't use multiple blank lines
> #95: FILE: drivers/gpu/drm/i915/i915_gem.c:317:
> +
> +

this

> -:107: WARNING:LONG_LINE: line length of 120 exceeds 100 columns
> #107: FILE: include/uapi/drm/i915_drm.h:395:
> +#define DRM_IOCTL_I915_GEM_CREATE_EXT   DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_CREATE, struct drm_i915_gem_create_ext)
> 
> -:155: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> #155: FILE: include/uapi/drm/i915_drm.h:1736:
> +#define I915_OBJECT_PARAM  (1ull<<32)

this

>  ^
> 
> total: 3 errors, 2 warnings, 3 checks, 136 lines checked
> ae1f0edf901f drm/i915/pxp: User interface for Protected buffer
> 7ce48b165a12 drm/i915/pxp: Add plane decryption support
> 
> 
> ___
> 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] [RFC-v19 12/13] drm/i915/pxp: User interface for Protected buffer

2021-01-07 Thread Vivi, Rodrigo
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> From: Bommu Krishnaiah 
> 
> This api allow user mode to create Protected buffer and context
> creation.
> 
> Signed-off-by: Bommu Krishnaiah 
> Cc: Telukuntla Sreedhar 
> Cc: Kondapally Kalyan 
> Cc: Gupta Anshuman 
> Cc: Huang Sean Z 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 19 +--
>  drivers/gpu/drm/i915/gem/i915_gem_context.h   |  5 
>  .../gpu/drm/i915/gem/i915_gem_context_types.h |  2 +-
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  5 
>  drivers/gpu/drm/i915/i915_gem.c   | 23 +++--
> --
>  include/uapi/drm/i915_drm.h   | 19 +++
>  6 files changed, 66 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 68f58762d5e3..00d7ca3071e7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -81,6 +81,8 @@
>  #include "i915_trace.h"
>  #include "i915_user_extensions.h"
>  
> +#include "pxp/intel_pxp.h"
> +
>  #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
>  
>  static struct i915_global_gem_context {
> @@ -2022,12 +2024,25 @@ static int ctx_setparam(struct
> drm_i915_file_private *fpriv,
> case I915_CONTEXT_PARAM_RECOVERABLE:
> if (args->size)
> ret = -EINVAL;
> -   else if (args->value)
> -   i915_gem_context_set_recoverable(ctx);
> +   else if (args->value) {
> +   if (!i915_gem_context_is_protected(ctx))
> +   i915_gem_context_set_recoverable(ctx)
> ;
> +   else
> +   ret = -EPERM;
> +   }
> else
> i915_gem_context_clear_recoverable(ctx);
> break;
>  
> +   case I915_CONTEXT_PARAM_PROTECTED_CONTENT:

remember that we also need to require recoverable flag to false. It
cannot be implicit.

> +   if (args->size)
> +   ret = -EINVAL;
> +   else if (args->value)
> +   ret =
> intel_pxp_gem_context_set_protected(ctx->i915,
> +
> >user_flags,
> +
> UCONTEXT_PROTECTED);
> +   break;
> +
> case I915_CONTEXT_PARAM_PRIORITY:
> ret = set_priority(ctx, args);
> break;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> index b5c908f3f4f2..173154fdc311 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> @@ -70,6 +70,11 @@ static inline void
> i915_gem_context_set_recoverable(struct i915_gem_context *ctx
> set_bit(UCONTEXT_RECOVERABLE, >user_flags);
>  }
>  
> +static inline bool i915_gem_context_is_protected(struct
> i915_gem_context *ctx)
> +{
> +   return test_bit(UCONTEXT_PROTECTED, >user_flags);
> +}
> +
>  static inline void i915_gem_context_clear_recoverable(struct
> i915_gem_context *ctx)
>  {
> clear_bit(UCONTEXT_RECOVERABLE, >user_flags);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index 1449f54924e0..0917c9431c65 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> @@ -134,7 +134,7 @@ struct i915_gem_context {
>  #define UCONTEXT_BANNABLE  2
>  #define UCONTEXT_RECOVERABLE   3
>  #define UCONTEXT_PERSISTENCE   4
> -
> +#define UCONTEXT_PROTECTED 5
> /**
>  * @flags: small set of booleans
>  */
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index e2d9b7e1e152..90ac955463f4 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -161,6 +161,11 @@ struct drm_i915_gem_object {
> } mmo;
>  
> I915_SELFTEST_DECLARE(struct list_head st_link);
> +   /**
> +    * @user_flags: small set of booleans set by the user
> +    */
> +   unsigned long user_flags;
> +#define I915_BO_PROTECTED BIT(0)
>  
> unsigned long flags;
>  #define I915_BO_ALLOC_CONTIGUOUS BIT(0)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index c53b13c02e59..611a0b5ab51f 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -184,7 +184,8 @@ static int
>  i915_gem_create(struct drm_file *file,
> struct intel_memory_region *mr,
> u64 *size_p,
> -   u32 *handle_p)
> +   u32 

Re: [Intel-gfx] [RFC-v19 09/13] drm/i915/pxp: Expose session state for display protection flip

2021-01-07 Thread Vivi, Rodrigo
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Implement the intel_pxp_gem_object_status() to allow i915 display
> querying the current PXP session state. In the design, display
> should not perform protection flip on the protected buffers if
> there is no PXP session alive. And Implement the funciton to set
> the protected flag for gem context.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/pxp/intel_pxp.c | 21 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.h | 18 ++
>  2 files changed, 39 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 23d4cfc1fb1f..a28a459532c2 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -158,3 +158,24 @@ void intel_pxp_irq_handler(struct intel_pxp
> *pxp, u16 iir)
> pxp->current_events |= events;
> schedule_work(>irq_work);
>  }
> +
> +bool intel_pxp_gem_object_status(struct drm_i915_private *i915)
> +{
> +   if (i915->gt.pxp.ctx.inited &&
> +   i915->gt.pxp.ctx.flag_display_hm_surface_keys)
> +   return true;
> +   else
> +   return false;
> +}
> +
> +int intel_pxp_gem_context_set_protected(struct drm_i915_private
> *i915,
> +   unsigned long *user_flags,
> +   u32 protected_bit)
> +{
> +   if (!user_flags || !protected_bit ||
> +   !intel_pxp_arb_session_is_in_play(>gt.pxp))
> +   return -EINVAL;
> +
> +   set_bit(protected_bit, user_flags);

This protected_bit should only be set during context creation and never
modified with set_context.

> +   return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index cdaa6ce6fdca..ff1c1c0e720c 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -29,6 +29,8 @@ enum pxp_protection_modes {
> PROTECTION_MODE_ALL
>  };
>  
> +struct drm_i915_private;
> +
>  #ifdef CONFIG_DRM_I915_PXP
>  void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir);
>  int i915_pxp_teardown_required_callback(struct intel_pxp *pxp);
> @@ -36,6 +38,10 @@ int
> i915_pxp_global_terminate_complete_callback(struct intel_pxp *pxp);
>  
>  void intel_pxp_init(struct intel_pxp *pxp);
>  void intel_pxp_fini(struct intel_pxp *pxp);
> +bool intel_pxp_gem_object_status(struct drm_i915_private *i915);
> +int intel_pxp_gem_context_set_protected(struct drm_i915_private
> *i915,
> +   unsigned long *user_flag,
> +   u32 protected_bit);
>  #else
>  static inline void intel_pxp_irq_handler(struct intel_pxp *pxp, u16
> iir)
>  {
> @@ -58,6 +64,18 @@ static inline void intel_pxp_init(struct intel_pxp
> *pxp)
>  static inline void intel_pxp_fini(struct intel_pxp *pxp)
>  {
>  }
> +
> +static inline bool intel_pxp_gem_object_status(struct
> drm_i915_private *i915)
> +{
> +   return false;
> +}
> +
> +static inline int intel_pxp_gem_context_set_protected(struct
> drm_i915_private *i915,
> + unsigned long
> *user_flag,
> + u32
> protected_bit)
> +{
> +   return 0;
> +}
>  #endif
>  
>  #endif /* __INTEL_PXP_H__ */

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


Re: [Intel-gfx] [RFC-v19 08/13] drm/i915/pxp: Enable PXP power management

2021-01-07 Thread Vivi, Rodrigo
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> During the power event S3+ sleep/resume, hardware will lose all the
> encryption keys for every hardware session, even though the
> software session state was marked as alive after resume. So to
> handle such case, PXP should terminate all the hardware sessions
> and cleanup all the software states after the power cycle.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Makefile  |  1 +
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c  |  4 ++
>  drivers/gpu/drm/i915/i915_drv.c    |  4 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_pm.c    | 65
> ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_pm.h    | 31 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  1 +
>  6 files changed, 106 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index 5599b92bea9b..7592fc8cbd89 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -265,6 +265,7 @@ i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp_arb.o \
> pxp/intel_pxp_cmd.o \
> pxp/intel_pxp_context.o \
> +   pxp/intel_pxp_pm.o \
> pxp/intel_pxp_tee.o
>  
>  # Post-mortem debug and GPU hang state capture
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index c94e8ac884eb..ae0387e419a2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -20,6 +20,7 @@
>  #include "intel_rc6.h"
>  #include "intel_rps.h"
>  #include "intel_wakeref.h"
> +#include "pxp/intel_pxp_pm.h"
>  
>  static void user_forcewake(struct intel_gt *gt, bool suspend)
>  {
> @@ -266,6 +267,8 @@ int intel_gt_resume(struct intel_gt *gt)
>  
> intel_uc_resume(>uc);
>  
> +   intel_pxp_pm_resume(>pxp);
> +
> user_forcewake(gt, false);
>  
>  out_fw:
> @@ -300,6 +303,7 @@ void intel_gt_suspend_prepare(struct intel_gt
> *gt)
> user_forcewake(gt, true);
> wait_for_suspend(gt);
>  
> +   intel_pxp_pm_prepare_suspend(>pxp);
> intel_uc_suspend(>uc);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 207d50226e64..5923db004d9b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -68,6 +68,8 @@
>  #include "gt/intel_gt_pm.h"
>  #include "gt/intel_rc6.h"
>  
> +#include "pxp/intel_pxp_pm.h"
> +
>  #include "i915_debugfs.h"
>  #include "i915_drv.h"
>  #include "i915_ioc32.h"
> @@ -1338,6 +1340,8 @@ static int i915_drm_resume_early(struct
> drm_device *dev)
>  
> intel_power_domains_resume(dev_priv);
>  
> +   intel_pxp_pm_resume_early(_priv->gt.pxp);
> +
> enable_rpm_wakeref_asserts(_priv->runtime_pm);
>  
> return ret;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> new file mode 100644
> index ..ebe89262485c
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include "intel_pxp_context.h"
> +#include "intel_pxp_arb.h"
> +#include "intel_pxp_pm.h"
> +
> +void intel_pxp_pm_prepare_suspend(struct intel_pxp *pxp)
> +{
> +   if (!pxp->ctx.inited)
> +   return;
> +
> +   mutex_lock(>ctx.mutex);
> +
> +   /* Disable PXP-IOCTLs */
> +   pxp->ctx.global_state_in_suspend = true;
> +
> +   mutex_unlock(>ctx.mutex);
> +}
> +
> +void intel_pxp_pm_resume_early(struct intel_pxp *pxp)
> +{
> +   if (!pxp->ctx.inited)
> +   return;
> +
> +   mutex_lock(>ctx.mutex);
> +
> +   if (pxp->ctx.global_state_in_suspend) {
> +   /* reset the attacked flag even there was a pending
> */
> +   pxp->ctx.global_state_attacked = false;
> +
> +   pxp->ctx.flag_display_hm_surface_keys = false;
> +   }
> +
> +   mutex_unlock(>ctx.mutex);
> +}
> +
> +int intel_pxp_pm_resume(struct intel_pxp *pxp)
> +{
> +   int ret = 0;
> +   struct intel_gt *gt = container_of(pxp, typeof(*gt), pxp);
> +
> +   if (!pxp->ctx.inited)
> +   return 0;
> +
> +   mutex_lock(>ctx.mutex);
> +
> +   /* Re-enable PXP-IOCTLs */
> +   if (pxp->ctx.global_state_in_suspend) {
> +   ret = intel_pxp_arb_terminate_session(pxp);

I'm confused. I was expecting we terminate the session at suspend and
re-stablish at resume. But I'm missing or forgetting something

> +   if (ret) {
> +   drm_err(>i915->drm, "Failed to terminate
> the arb session\n");
> +   goto end;
> +   }
> +
> +   pxp->ctx.global_state_in_suspend = false;
> +   }
> +
> +end:
> +   

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Remove obj->mm.lock! (rev13)

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove obj->mm.lock! (rev13)
URL   : https://patchwork.freedesktop.org/series/82337/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter 
or member 'ww' not described in 'i915_gem_shrink'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1413: warning: Excess function 
parameter 'trampoline' description in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1413: warning: Function parameter or 
member 'jump_whitelist' not described in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1413: warning: Function parameter or 
member 'shadow_map' not described in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1413: warning: Function parameter or 
member 'batch_map' not described in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1413: warning: Excess function 
parameter 'trampoline' description in 'intel_engine_cmd_parser'


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


Re: [Intel-gfx] [RFC-v19 05/13] drm/i915/pxp: Func to send hardware session termination

2021-01-07 Thread Vivi, Rodrigo
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Implement the functions to allow PXP to send a GPU command, in
> order to terminate the hardware session, so hardware can recycle
> this session slot for the next usage.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Makefile  |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.c   |  13 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c   | 158
> +
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h   |  18 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h |   4 +
>  5 files changed, 194 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index af9e87e4c63a..5599b92bea9b 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -263,6 +263,7 @@ i915-y += i915_perf.o
>  i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> pxp/intel_pxp_arb.o \
> +   pxp/intel_pxp_cmd.o \
> pxp/intel_pxp_context.o \
> pxp/intel_pxp_tee.o
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 3868e8c697f9..2f63801748f8 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -17,10 +17,23 @@
>  void intel_pxp_init(struct intel_pxp *pxp)
>  {
> struct intel_gt *gt = container_of(pxp, struct intel_gt,
> pxp);
> +   int i;
>  
> if (INTEL_GEN(gt->i915) < 12)
> return;
>  
> +   /* Find the first VCS engine present */
> +   for (i = 0; i < I915_MAX_VCS; i++) {
> +   if (HAS_ENGINE(gt, _VCS(i))) {
> +   pxp->vcs_engine = gt->engine[_VCS(i)];
> +   break;
> +   }
> +   }
> +   if (!pxp->vcs_engine) {
> +   drm_err(>i915->drm, "Could not find a VCS
> engine\n");
> +   return;
> +   }
> +
> intel_pxp_ctx_init(>ctx);
>  
> intel_uncore_write(gt->uncore, KCR_INIT,
> KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> new file mode 100644
> index ..d9298cf5e1a7
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#include "intel_pxp_cmd.h"
> +#include "i915_drv.h"
> +#include "gt/intel_context.h"
> +#include "gt/intel_engine_pm.h"
> +
> +struct i915_vma *intel_pxp_cmd_get_batch(struct intel_pxp *pxp,
> +    struct intel_context *ce,
> +    struct
> intel_gt_buffer_pool_node *pool,
> +    u32 *cmd_buf, int
> cmd_size_in_dw)
> +{
> +   struct i915_vma *batch = ERR_PTR(-EINVAL);
> +   struct intel_gt *gt = container_of(pxp, struct intel_gt,
> pxp);
> +   u32 *cmd;
> +
> +   if (!ce || !ce->engine || !cmd_buf)
> +   return ERR_PTR(-EINVAL);
> +
> +   if (cmd_size_in_dw * 4 > PAGE_SIZE) {
> +   drm_err(>i915->drm, "Failed to %s, invalid
> cmd_size_id_dw=[%d]\n",
> +   __func__, cmd_size_in_dw);
> +   return ERR_PTR(-EINVAL);
> +   }
> +
> +   cmd = i915_gem_object_pin_map(pool->obj, I915_MAP_FORCE_WC);
> +   if (IS_ERR(cmd)) {
> +   drm_err(>i915->drm, "Failed to
> i915_gem_object_pin_map()\n");
> +   return ERR_PTR(-EINVAL);
> +   }
> +
> +   memcpy(cmd, cmd_buf, cmd_size_in_dw * 4);
> +
> +   if (drm_debug_enabled(DRM_UT_DRIVER)) {
> +   print_hex_dump(KERN_DEBUG, "cmd binaries:",
> +  DUMP_PREFIX_OFFSET, 4, 4, cmd,
> cmd_size_in_dw * 4, true);
> +   }
> +
> +   i915_gem_object_unpin_map(pool->obj);
> +
> +   batch = i915_vma_instance(pool->obj, ce->vm, NULL);
> +   if (IS_ERR(batch)) {
> +   drm_err(>i915->drm, "Failed to
> i915_vma_instance()\n");
> +   return batch;
> +   }
> +
> +   return batch;
> +}
> +
> +int intel_pxp_cmd_submit(struct intel_pxp *pxp, u32 *cmd, int
> cmd_size_in_dw)
> +{
> +   int err = -EINVAL;
> +   struct i915_vma *batch;
> +   struct i915_request *rq;
> +   struct intel_context *ce = NULL;
> +   bool is_engine_pm_get = false;
> +   bool is_batch_vma_pin = false;
> +   bool is_skip_req_on_err = false;
> +   bool is_engine_get_pool = false;

I remember that I asked myself in some internal version to this to be
converted to gotos and I remember seeing the change. I'm not sure why
this also came back to the very original code.

Then Chris and Joonas also requested changes on older versions of this
patch. Not only limited to this. Please address 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Remove obj->mm.lock! (rev13)

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove obj->mm.lock! (rev13)
URL   : https://patchwork.freedesktop.org/series/82337/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1265:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 
'wakeref_auto_timeout' - unexpected unlock
+drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y


___
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: Remove obj->mm.lock! (rev13)

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove obj->mm.lock! (rev13)
URL   : https://patchwork.freedesktop.org/series/82337/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
cbc0237dc775 drm/i915: Do not share hwsp across contexts any more, v6
-:558: WARNING:CONSTANT_COMPARISON: Comparisons should place the constant on 
the right side of the test
#558: FILE: drivers/gpu/drm/i915/gt/intel_timeline.c:287:
+   if (TIMELINE_SEQNO_BYTES <= BIT(5) && (next_ofs & BIT(5)))

total: 0 errors, 1 warnings, 0 checks, 939 lines checked
9785c066d43f drm/i915: Pin timeline map after first timeline pin, v3.
-:13: WARNING:TYPO_SPELLING: 'arithmatic' may be misspelled - perhaps 
'arithmetic'?
#13: 
- Fix NULL + XX arithmatic, use casts. (kbuild)
^^

total: 0 errors, 1 warnings, 0 checks, 296 lines checked
de7db6cc5368 drm/i915: Move cmd parser pinning to execbuffer
f4a0ebe47349 drm/i915: Add missing -EDEADLK handling to execbuf pinning, v2.
-:59: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#59: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:452:
+   err = i915_vma_pin_ww(vma, >ww,
 entry->pad_to_size,

total: 0 errors, 0 warnings, 1 checks, 75 lines checked
f4245cae4741 drm/i915: Ensure we hold the object mutex in pin correctly.
a6940e0503e5 drm/i915: Add gem object locking to madvise.
b881f7651122 drm/i915: Move HAS_STRUCT_PAGE to obj->flags
-:110: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#110: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.c:63:
+ struct lock_class_key *key, unsigned flags)

-:133: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#133: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:27:
+ unsigned alloc_flags);

total: 0 errors, 2 warnings, 0 checks, 348 lines checked
f90f08586008 drm/i915: Rework struct phys attachment handling
138d22527745 drm/i915: Convert i915_gem_object_attach_phys() to ww locking, v2.
d319bbed11e6 drm/i915: make lockdep slightly happier about execbuf.
2164b6818543 drm/i915: Disable userptr pread/pwrite support.
f5dbb93bbfa1 drm/i915: No longer allow exporting userptr through dma-buf
7f3e5695a30c drm/i915: Reject more ioctls for userptr
6221e6630d88 drm/i915: Reject UNSYNCHRONIZED for userptr, v2.
08f97e18f8e9 drm/i915: Make compilation of userptr code depend on MMU_NOTIFIER.
3953cfa616ca drm/i915: Fix userptr so we do not have to worry about 
obj->mm.lock, v5.
-:291: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#291: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:561:
+static inline int i915_gem_object_userptr_submit_init(struct 
drm_i915_gem_object *obj) { GEM_BUG_ON(1); return -ENODEV; }

-:292: WARNING:LONG_LINE: line length of 121 exceeds 100 columns
#292: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:562:
+static inline int i915_gem_object_userptr_submit_done(struct 
drm_i915_gem_object *obj) { GEM_BUG_ON(1); return -ENODEV; }

-:293: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#293: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:563:
+static inline void i915_gem_object_userptr_submit_fini(struct 
drm_i915_gem_object *obj) { GEM_BUG_ON(1); }

-:351: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use 
line 1 instead
#351: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:2:
  * SPDX-License-Identifier: MIT

-:355: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each 
line
#355: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:6:
+ *
+  * Based on amdgpu_mn, which bears the following notice:

-:356: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each 
line
#356: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:7:
+  * Based on amdgpu_mn, which bears the following notice:
+ *

-:469: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#469: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:63:
+   struct drm_i915_gem_object *obj = container_of(mni, struct 
drm_i915_gem_object, userptr.notifier);

-:1123: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#1123: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:293:
+   pinned = ret = 0;

-:1138: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#1138: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:308:
+   if (mmu_interval_read_retry(>userptr.notifier,
+   !obj->userptr.page_ref ? notifier_seq :

-:1259: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#1259: FILE: drivers/gpu/drm/i915/i915_drv.h:598:
+   spinlock_t notifier_lock;

total: 0 errors, 7 warnings, 3 checks, 1202 lines checked
f112822eb256 drm/i915: Flatten obj->mm.lock
a29d90e385ae drm/i915: Populate logical context during first pin.
31e23527c490 drm/i915: Make ring submission compatible with obj->mm.lock 
removal, v2.
868eac184a45 drm/i915: Handle ww 

Re: [Intel-gfx] [RFC-v19 00/13] Introduce Intel PXP component - Mesa single session

2021-01-07 Thread Vivi, Rodrigo
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> PXP (Protected Xe Path) is an i915 component, available on
> GEN12+ that helps to establish the hardware protected session
> and manage the status of the alive software session, as well
> as its life cycle.
> 
> This patch series is to allow the kernel space to create and
> manage a single hardware session (a.k.a. default session or
> arbitrary session). So user can allocate the protected buffer,
> which is encrypted with the leverage of the arbitrary hardware
> session.
> 
> v2:
>     - modification based on code review feedbacks received
>     - passing pxp instead of i915 as function argument
>     - remove dead code only for multi-session
>     - move the pxp init call from i915_drv.c to intel_gt.c
>     - remove the tautology naming
> 
> v3:
>     - rebase to latest drm-tip
> 
> v4:
>     - Append the split non-mesa patch sereis (commit #14 - #21) into
>   this patch series
> 
> v5:
>     - include "intel_pxp.h" in intel_pxp_sm.h at commit #14 to fix
>   the build problem.
> 
> v6:
>     - Fix the null pointer arb_session access bug in intel_pxp_arb.c
> in
>   "04 [RFC-v5] drm/i915/pxp: Create the arbitrary session after
>   boot"
> 
> v7:
>     - Use list_for_each_entry_safe instead of list_for_each_entry
> 
> v8:
>     - Add MEI vtag support for PXP multi-session usage
> 
> v9:
>     - Fix error handling bug in commit #5 "Func to send hardware
> session
>   termination". In intel_pxp_cmd.c, we should properly assign
>   "err = PTR_ERR(x)" if hitting the error case "IS_ERR(x)", this
> is
>   the only change in v9.
> 
> v10
>     - Remove the multi session commits #14-#21, for now we would like
> to
>   keep the multi session patches as downstream.
>     - Adopt the code review suggestion from Wilson in commit #1
> 
> v11
>     - In commit #05 "drm/i915/pxp: Func to send hardware session
>   termination", we should not assume VCS0 is always on.
>   Instead we use available VCS#, could be VCS0, VCS2, etc.
> 
> v12
>     - Add "#include  in #1 intel_pxp_types.h
> 
> v13
>     - Add "#include  in #1 intel_pxp_types.h (#v12
> didn't
>   actually update the _types.h file...)
> 
> v14
>     - Add "if (INTEL_GEN(gt->i915) < 12) return;" in #1
>   intel_pxp_fini(), just skip for non gen12+ sku
> 
> v15
>     In #04:
>     - Make intel_pxp_arb_reserve_session() as static function to fix
> the
>   sparse warning
>     - Update value of PXP_TEE_ARB_CMD_BIN 
> 
> v16
>     In #04:
>     - Remove the binary from source code via defining the TEE command
>   header
> 
> v17
>     - In #04, directly return intel_pxp_tee_component_fini() if
>   pxp_tee_comp_added is off
> 
> v18
>     - In #09, Add intel_pxp_gem_context_set_protected() to check the
> arb
>   session before setting protected flag for gem context
> 
>     - In #12, Replace i915_gem_context_set_protected() with
>   intel_pxp_gem_context_set_protected() to check whether the
> arbitrary
>   session is alive
> 
> v19
>     - In #01, put intel_pxp_fini() in intel_gt_driver_remove()
> instead of
>   intel_gt_driver_release() since intel_gt_driver_release() is
> the last
>   stage of i915 unbind and we shouldn't call the component_del
> here.
> 
>     - In #04, check if arbitrary session is alive before
>   intel_pxp_arb_create_session()

Please reduce the amount of series revision and start using --in-reply-
to so we can easily see what was addressed from the previous comments
versus what is open.

> 
> 
> Anshuman Gupta (1):
>   drm/i915/pxp: Add plane decryption support
> 
> Bommu Krishnaiah (2):
>   drm/i915/uapi: introduce drm_i915_gem_create_ext
>   drm/i915/pxp: User interface for Protected buffer
> 
> Huang, Sean Z (9):
>   drm/i915/pxp: Introduce Intel PXP component
>   drm/i915/pxp: set KCR reg init during the boot time
>   drm/i915/pxp: Implement funcs to create the TEE channel
>   drm/i915/pxp: Create the arbitrary session after boot
>   drm/i915/pxp: Func to send hardware session termination
>   drm/i915/pxp: Enable PXP irq worker and callback stub
>   drm/i915/pxp: Destroy arb session upon teardown
>   drm/i915/pxp: Enable PXP power management
>   drm/i915/pxp: Expose session state for display protection flip
> 
> Vitaly Lubart (1):
>   mei: pxp: export pavp client to me client bus
> 
>  drivers/gpu/drm/i915/Kconfig  |  22 ++
>  drivers/gpu/drm/i915/Makefile |   9 +
>  drivers/gpu/drm/i915/display/intel_sprite.c   |  21 +-
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   |  19 +-
>  drivers/gpu/drm/i915/gem/i915_gem_context.h   |   5 +
>  .../gpu/drm/i915/gem/i915_gem_context_types.h |   2 +-
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |   5 +
>  drivers/gpu/drm/i915/gt/intel_gt.c    |   5 +
>  drivers/gpu/drm/i915/gt/intel_gt_irq.c    |   4 +
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c |   4 +
>  drivers/gpu/drm/i915/gt/intel_gt_types.h  |   3 +
>  

Re: [Intel-gfx] [RFC-v19 04/13] drm/i915/pxp: Create the arbitrary session after boot

2021-01-07 Thread Vivi, Rodrigo
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Create the arbitrary session, with the fixed session id 0xf, after
> system boot, for the case that application allocates the protected
> buffer without establishing any protection session. Because the
> hardware requires at least one alive session for protected buffer
> creation.  This arbitrary session needs to be re-created after
> teardown or power event because hardware encryption key won't be
> valid after such cases.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Makefile    |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.c |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.h |  16 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_arb.c | 131
> +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_arb.h |  16 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_context.h |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c |  73 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.h |   3 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h   |  26 
>  9 files changed, 268 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_arb.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index 5494c30cb54f..af9e87e4c63a 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -262,6 +262,7 @@ i915-y += i915_perf.o
>  # Protected execution platform (PXP) support
>  i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> +   pxp/intel_pxp_arb.o \
> pxp/intel_pxp_context.o \
> pxp/intel_pxp_tee.o
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index c819f3791ee4..3868e8c697f9 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -6,6 +6,7 @@
>  #include "intel_pxp.h"
>  #include "intel_pxp_context.h"
>  #include "intel_pxp_tee.h"
> +#include "intel_pxp_arb.h"
>  
>  /* KCR register definitions */
>  #define KCR_INIT    _MMIO(0x320f0)
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index f47bc6bea34f..8fc91e900b16 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -8,6 +8,22 @@
>  
>  #include "intel_pxp_types.h"
>  
> +enum pxp_session_types {
> +   SESSION_TYPE_TYPE0 = 0,
> +   SESSION_TYPE_TYPE1 = 1,
> +
> +   SESSION_TYPE_MAX
> +};
> +
> +enum pxp_protection_modes {
> +   PROTECTION_MODE_NONE = 0,
> +   PROTECTION_MODE_LM   = 2,
> +   PROTECTION_MODE_HM   = 3,
> +   PROTECTION_MODE_SM   = 6,
> +
> +   PROTECTION_MODE_ALL
> +};
> +
>  #ifdef CONFIG_DRM_I915_PXP
>  void intel_pxp_init(struct intel_pxp *pxp);
>  void intel_pxp_fini(struct intel_pxp *pxp);
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> new file mode 100644
> index ..640d7103c04d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#include "gt/intel_context.h"
> +#include "gt/intel_engine_pm.h"
> +
> +#include "intel_pxp_types.h"
> +#include "intel_pxp_arb.h"
> +#include "intel_pxp.h"
> +#include "intel_pxp_tee.h"
> +
> +#define GEN12_KCR_SIP _MMIO(0x32260) /* KCR type0 session in play 0-
> 31 */
> +
> +/* Arbitrary session */
> +#define ARB_SESSION_INDEX 0xf
> +#define ARB_SESSION_TYPE SESSION_TYPE_TYPE0

All reg defines should be in i915_reg.h

> +
> +bool intel_pxp_arb_session_is_in_play(struct intel_pxp *pxp)
> +{
> +   u32 regval_sip = 0;
> +   intel_wakeref_t wakeref;
> +   struct intel_gt *gt = container_of(pxp, struct intel_gt,
> pxp);
> +
> +   with_intel_runtime_pm(>i915->runtime_pm, wakeref) {
> +   regval_sip = intel_uncore_read(gt->uncore,
> GEN12_KCR_SIP);
> +   }
> +
> +   return regval_sip & BIT(ARB_SESSION_INDEX);
> +}
> +
> +/* wait hw session_in_play reg to match the current sw state */
> +static int wait_arb_hw_sw_state(struct intel_pxp *pxp)
> +{
> +   const int max_retry = 10;
> +   const int ms_delay = 10;
> +   int retry = 0;
> +   int ret;
> +   struct pxp_protected_session *arb = >ctx.arb_session;
> +
> +   ret = -EINVAL;
> +   for (retry = 0; retry < max_retry; retry++) {
> +   if (intel_pxp_arb_session_is_in_play(pxp) ==
> +   arb->is_in_play) {
> +   ret = 0;
> +   break;
> +   }
> +
> +   msleep(ms_delay);
> +   }
> +
> +   return ret;
> +}
> +
> +static void arb_session_entry_init(struct intel_pxp *pxp)
> +{
> +   struct pxp_protected_session *arb = >ctx.arb_session;
> +
> +   arb->type = ARB_SESSION_TYPE;
> +   

Re: [Intel-gfx] [RFC-v19 03/13] drm/i915/pxp: Implement funcs to create the TEE channel

2021-01-07 Thread Vivi, Rodrigo
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Implement the funcs to create the TEE channel, so kernel can
> send the TEE commands directly to TEE for creating the arbitrary
> (defualt) session.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Makefile    |   3 +-
>  drivers/gpu/drm/i915/i915_drv.c  |   1 +
>  drivers/gpu/drm/i915/i915_drv.h  |   6 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.c |   5 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 137
> +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.h |  14 +++
>  include/drm/i915_component.h |   1 +
>  include/drm/i915_pxp_tee_interface.h |  45 
>  8 files changed, 211 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
>  create mode 100644 include/drm/i915_pxp_tee_interface.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index cbf2f0594b4d..5494c30cb54f 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -262,7 +262,8 @@ i915-y += i915_perf.o
>  # Protected execution platform (PXP) support
>  i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> -   pxp/intel_pxp_context.o
> +   pxp/intel_pxp_context.o \
> +   pxp/intel_pxp_tee.o
>  
>  # Post-mortem debug and GPU hang state capture
>  i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 3e504247f2da..207d50226e64 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -322,6 +322,7 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
> mutex_init(_priv->wm.wm_mutex);
> mutex_init(_priv->pps_mutex);
> mutex_init(_priv->hdcp_comp_mutex);
> +   mutex_init(_priv->pxp_tee_comp_mutex);
>  
> i915_memcpy_init_early(dev_priv);
> intel_runtime_pm_init_early(_priv->runtime_pm);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 5e5bcef20e33..c2f47daef5a5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1209,6 +1209,12 @@ struct drm_i915_private {
> /* Mutex to protect the above hdcp component related values.
> */
> struct mutex hdcp_comp_mutex;
>  
> +   struct i915_pxp_comp_master *pxp_tee_master;
> +   bool pxp_tee_comp_added;
> +
> +   /* Mutex to protect the above pxp_tee component related
> values. */
> +   struct mutex pxp_tee_comp_mutex;
> +
> I915_SELFTEST_DECLARE(struct i915_selftest_stash selftest;)
>  
> /*
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index f566a4fda044..c819f3791ee4 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -5,6 +5,7 @@
>  #include "i915_drv.h"
>  #include "intel_pxp.h"
>  #include "intel_pxp_context.h"
> +#include "intel_pxp_tee.h"
>  
>  /* KCR register definitions */
>  #define KCR_INIT    _MMIO(0x320f0)
> @@ -23,6 +24,8 @@ void intel_pxp_init(struct intel_pxp *pxp)
>  
> intel_uncore_write(gt->uncore, KCR_INIT,
> KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
>  
> +   intel_pxp_tee_component_init(pxp);
> +
> drm_info(>i915->drm, "Protected Xe Path (PXP) protected
> content support initialized\n");
>  }
>  
> @@ -33,5 +36,7 @@ void intel_pxp_fini(struct intel_pxp *pxp)
> if (INTEL_GEN(gt->i915) < 12)
> return;
>  
> +   intel_pxp_tee_component_fini(pxp);
> +
> intel_pxp_ctx_fini(>ctx);
>  }
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> new file mode 100644
> index ..5a1ffcc703e2
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -0,0 +1,137 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include 
> +#include "drm/i915_pxp_tee_interface.h"
> +#include "drm/i915_component.h"
> +#include  "i915_drv.h"
> +#include "intel_pxp.h"
> +#include "intel_pxp_context.h"
> +#include "intel_pxp_tee.h"
> +
> +static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
> +   void *msg_in, u32 msg_in_size,
> +   void *msg_out, u32
> *msg_out_size_ptr,
> +   u32 msg_out_buf_size)
> +{
> +   int ret;
> +   struct intel_gt *gt = container_of(pxp, typeof(*gt), pxp);
> +   struct drm_i915_private *i915 = gt->i915;
> +   struct i915_pxp_comp_master *pxp_tee_master = i915-
> >pxp_tee_master;
> +
> +   if (!pxp_tee_master || !msg_in || !msg_out ||
> !msg_out_size_ptr)
> +   return -EINVAL;
> +
> +   lockdep_assert_held(>pxp_tee_comp_mutex);
> +
> +   if 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Move struct drm_device.pdev to legacy (rev3)

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm: Move struct drm_device.pdev to legacy (rev3)
URL   : https://patchwork.freedesktop.org/series/84205/
State : failure

== Summary ==

Applying: drm/amdgpu: Fix trailing whitespaces
Applying: drm/amdgpu: Remove references to struct drm_device.pdev
Applying: drm/hibmc: Remove references to struct drm_device.pdev
Applying: drm/i915: Remove references to struct drm_device.pdev
Applying: drm/i915/gt: Remove references to struct drm_device.pdev
Applying: drm/i915/gvt: Remove references to struct drm_device.pdev
Applying: drm/nouveau: Remove references to struct drm_device.pdev
Applying: drm: Upcast struct drm_device.dev to struct pci_device; replace pdev
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/drm_pci.c
M   include/drm/drm_device.h
Falling back to patching base and 3-way merge...
Auto-merging include/drm/drm_device.h
CONFLICT (content): Merge conflict in include/drm/drm_device.h
Auto-merging drivers/gpu/drm/drm_pci.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0008 drm: Upcast struct drm_device.dev to struct pci_device; 
replace pdev
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] [RFC-v19 02/13] drm/i915/pxp: set KCR reg init during the boot time

2021-01-07 Thread Vivi, Rodrigo
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> Set the KCR init during the boot time, which is
> required by hardware, to allow us doing further
> protection operation such as sending commands to
> GPU or TEE.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 9bc3c7e30654..f566a4fda044 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -6,6 +6,12 @@
>  #include "intel_pxp.h"
>  #include "intel_pxp_context.h"
>  
> +/* KCR register definitions */

please define this in i915_reg.h

> +#define KCR_INIT    _MMIO(0x320f0)
> +#define KCR_INIT_MASK_SHIFT (16) 

mask or shift?

> +/* Setting KCR Init bit is required after system boot */
> +#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) <<
> KCR_INIT_MASK_SHIFT))

Also, use only bit definitions here and leave the mask and/or shift
only when calling the write function.

> 
> +
>  void intel_pxp_init(struct intel_pxp *pxp)
>  {
> struct intel_gt *gt = container_of(pxp, struct intel_gt,
> pxp);
> @@ -15,6 +21,8 @@ void intel_pxp_init(struct intel_pxp *pxp)
>  
> intel_pxp_ctx_init(>ctx);
>  
> +   intel_uncore_write(gt->uncore, KCR_INIT,
> KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
> +
> drm_info(>i915->drm, "Protected Xe Path (PXP) protected
> content support initialized\n");
>  }
>  

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


Re: [Intel-gfx] [RFC-v19 01/13] drm/i915/pxp: Introduce Intel PXP component

2021-01-07 Thread Vivi, Rodrigo
On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> PXP (Protected Xe Path) is an i915 componment, available on GEN12+,
> that helps to establish the hardware protected session and manage
> the status of the alive software session, as well as its life cycle.
> 
> This patch series is to allow the kernel space to create and
> manage a single hardware session (a.k.a default session or
> arbitrary session). So Mesa can allocate the protected buffer,
> which is encrypted with the leverage of the arbitrary hardware
> session.
> 
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Kconfig | 22 +++
>  drivers/gpu/drm/i915/Makefile    |  5 
>  drivers/gpu/drm/i915/gt/intel_gt.c   |  5 
>  drivers/gpu/drm/i915/gt/intel_gt_types.h |  3 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp.c | 29
> 
>  drivers/gpu/drm/i915/pxp/intel_pxp.h | 25 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_context.c | 25 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_context.h | 15 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h   | 23 
>  9 files changed, 152 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_context.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_context.h
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig
> b/drivers/gpu/drm/i915/Kconfig
> index 1e1cb245fca7..594775c11e19 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -130,6 +130,28 @@ config DRM_I915_GVT_KVMGT
>   Choose this option if you want to enable KVMGT support for
>   Intel GVT-g.
>  
> +config DRM_I915_PXP
> +   bool "Enable Intel PXP support for Intel Gen12+ platform"
> +   depends on DRM_I915
> +   select INTEL_MEI
> +   select INTEL_MEI_ME
> +   select INTEL_MEI_TXE
> +   select INTEL_MEI_PXP

I'm afraid you haven't addressed any of the Chris' comments from V4.
I saw you marked as "done", but I'm seeing everything back here.
So I'm not sure what's going on here.


> +   default y
> +   help
> + This option selects INTEL_MEI_ME if it isn't already
> selected to
> + enabled full PXP Services on Intel platforms.
> +
> + PXP (Protected Xe Path) is an i915 componment, available on
> GEN12+,
> + that helps to establish the hardware protected session and
> manage
> + the status of the alive software session, as well as its
> life cycle.
> +
> + This patch series is to allow the kernel space to create
> and
> + manage a single hardware session (a.k.a default session or
> + arbitrary session). So Mesa can allocate the protected
> buffer,
> + which is encrypted with the leverage of the arbitrary
> hardware
> + session.
> +
>  menu "drm/i915 Debugging"
>  depends on DRM_I915
>  depends on EXPERT
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index 4074d8cb0d6e..cbf2f0594b4d 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -259,6 +259,11 @@ i915-y += \
>  
>  i915-y += i915_perf.o
>  
> +# Protected execution platform (PXP) support
> +i915-$(CONFIG_DRM_I915_PXP) += \
> +   pxp/intel_pxp.o \
> +   pxp/intel_pxp_context.o
> +
>  # Post-mortem debug and GPU hang state capture
>  i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
>  i915-$(CONFIG_DRM_I915_SELFTEST) += \
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index d8e1ab412634..336ad7deae06 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -18,6 +18,7 @@
>  #include "intel_uncore.h"
>  #include "intel_pm.h"
>  #include "shmem_utils.h"
> +#include "pxp/intel_pxp.h"
>  
>  void intel_gt_init_early(struct intel_gt *gt, struct
> drm_i915_private *i915)
>  {
> @@ -584,6 +585,8 @@ int intel_gt_init(struct intel_gt *gt)
> if (err)
> goto err_gt;
>  
> +   intel_pxp_init(>pxp);
> +
> goto out_fw;
>  err_gt:
> __intel_gt_disable(gt);
> @@ -607,6 +610,8 @@ void intel_gt_driver_remove(struct intel_gt *gt)
>  {
> __intel_gt_disable(gt);
>  
> +   intel_pxp_fini(>pxp);
> +
> intel_uc_driver_remove(>uc);
>  
> intel_engines_release(gt);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index a83d3e18254d..c4760e2722fd 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -23,6 +23,7 @@
>  #include "intel_rc6_types.h"
>  #include "intel_rps_types.h"
>  #include "intel_wakeref.h"
> +#include "pxp/intel_pxp_types.h"
>  
>  struct drm_i915_private;
>  struct 

Re: [Intel-gfx] [RFC][PATCH 3/3] drm/i915: Implement readout for AVI infoframe SDP

2021-01-07 Thread Mun, Gwan-gyeong
On Fri, 2020-12-18 at 16:03 +0530, Swati Sharma wrote:
> In this patch readout for AVI infoframes enclosed in GMP
> DIP is implemented.
> 
> Signed-off-by: Swati Sharma 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 74
> -
>  1 file changed, 72 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d96e69dd2197..4821c96991f2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5738,6 +5738,44 @@
> intel_dp_hdr_metadata_infoframe_sdp_unpack(struct hdmi_drm_infoframe
> *drm_infofr
>   return ret;
>  }
>  
> +static int
> +intel_dp_avi_infoframe_sdp_unpack(union hdmi_infoframe *frame,
> +   const void *buffer, size_t size)
> +{
> + int ret;
> +
> + const struct dp_sdp *sdp = buffer;
> +
> + if (size < sizeof(struct dp_sdp))
> + return -EINVAL;
> +
> + if (sdp->sdp_header.HB0 != 0)
> + return -EINVAL;
> +
> + if (sdp->sdp_header.HB1 != HDMI_INFOFRAME_TYPE_AVI)
> + return -EINVAL;
> +
> + if (sdp->sdp_header.HB2 != 0x1D)
> + return -EINVAL;
> +
> + if ((sdp->sdp_header.HB3 & 0x3) != 0)
> + return -EINVAL;
> +
> + if (((sdp->sdp_header.HB3 >> 2) & 0x3f) != 0x13)
> + return -EINVAL;
> +
> + if (sdp->db[0] != 2)
> + return -EINVAL;
> +
> + if (sdp->db[1] != HDMI_AVI_INFOFRAME_SIZE)
> + return -EINVAL;
> +
> + ret = hdmi_infoframe_unpack(frame, >db[2],
> + HDMI_DRM_INFOFRAME_SIZE);
> +
> + return ret;
> +}
> +
>  static void intel_read_dp_vsc_sdp(struct intel_encoder *encoder,
> struct intel_crtc_state *crtc_state,
> struct drm_dp_vsc_sdp *vsc)
> @@ -5790,10 +5828,37 @@ static void
> intel_read_dp_hdr_metadata_infoframe_sdp(struct intel_encoder *encod
>   "Failed to unpack DP HDR Metadata Infoframe
> SDP\n");
>  }
>  
> +static void intel_read_dp_avi_infoframe_sdp(struct intel_encoder
> *encoder,
> + struct intel_crtc_state
> *crtc_state,
> + union hdmi_infoframe
> *frame)
> +{
> + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + unsigned int type = HDMI_PACKET_TYPE_GAMUT_METADATA;
> + struct dp_sdp sdp = {};
> + int ret;
> +
> + if ((crtc_state->infoframes.enable &
> + intel_hdmi_infoframe_enable(type)) == 0)
> + return;
> +
> + dig_port->read_infoframe(encoder, crtc_state, type, ,
> +  sizeof(sdp));
> +
> + ret = intel_dp_avi_infoframe_sdp_unpack(frame, ,
> + sizeof(sdp));
> +
> + if (ret)
> + drm_dbg_kms(_priv->drm,
> + "Failed to unpack DP AVI Infoframe SDP\n");
> +}
> +
>  void intel_read_dp_sdp(struct intel_encoder *encoder,
>  struct intel_crtc_state *crtc_state,
>  unsigned int type)
>  {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
>   if (encoder->type != INTEL_OUTPUT_DDI)
>   return;
>  
> @@ -5803,8 +5868,13 @@ void intel_read_dp_sdp(struct intel_encoder
> *encoder,
> _state->infoframes.vsc);
>   break;
>   case HDMI_PACKET_TYPE_GAMUT_METADATA:
> - intel_read_dp_hdr_metadata_infoframe_sdp(encoder,
> crtc_state,
> -  _state-
> >infoframes.drm.drm);
> + if (intel_dp_is_hdmi_2_1_sink(intel_dp)) {
> + intel_read_dp_avi_infoframe_sdp(encoder,
> crtc_state,
> + _state-
> >infoframes.avi);
> + } else {
> + intel_read_dp_hdr_metadata_infoframe_sdp(encoder,
> crtc_state,
> +  _stat
> e->infoframes.drm.drm);
> + }
I recommend you split the types like this.
case HDMI_PACKET_TYPE_GAMUT_METADATA:
if (!intel_dp_is_hdmi_2_1_sink(intel_dp))
intel_read_dp_avi_infoframe_sdp(encoder,
crtc_state,  _state->infoframes.avi);


case HDMI_INFOFRAME_TYPE_AVI:
if (intel_dp_is_hdmi_2_1_sink(intel_dp))
intel_read_dp_avi_infoframe_sdp(encoder, crtc_state,
_state->infoframes.avi);

Add you should call this function call " intel_read_dp_sdp(encoder,
pipe_config, HDMI_INFOFRAME_TYPE_AVI); "
below this line,
intel_read_dp_sdp(encoder, pipe_config, DP_SDP_VSC); 
in this function.
[drivers/gpu/drm/i915/display/intel_ddi.c]
void intel_ddi_get_config()

>   break;
>   default:
>   

Re: [Intel-gfx] [RFC][PATCH 2/3] drm/i915: Sending AVI infoframe through GMP DIP

2021-01-07 Thread Mun, Gwan-gyeong
On Fri, 2020-12-18 at 16:03 +0530, Swati Sharma wrote:
> DP does not support sending AVI info frame to panel. So we need to
> send AVI info frame to HDMI through some other DIP.
> 
> When DP-to-HDMI protocol converter is present GMP DIP will be used
> to send AVI infoframe instead of static HDR infoframes.
> 
> While VESA spec indicates support within PCON to built AVI IF, it
> gives better control with source sending the infoframe by itself as
> per HDMI/CTA spec. Minimum of version 3 need to be used for VIC >=
> 128
> (i.e. for 8k mode as an example).
> 
> Signed-off-by: Swati Sharma 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 135 ++--
> 
>  1 file changed, 100 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a776e7f809b4..d96e69dd2197 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2779,6 +2779,22 @@
> intel_dp_compute_hdr_metadata_infoframe_sdp(struct intel_dp
> *intel_dp,
>   intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_META
> DATA);
>  }
>  
> +static void
> +intel_dp_compute_avi_infoframe_sdp(struct intel_encoder *encoder,
> +struct intel_crtc_state *crtc_state,
> +struct drm_connector_state
> *conn_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + if (!intel_hdmi_compute_avi_infoframe(encoder, crtc_state,
> conn_state)) {
> + drm_dbg_kms(_priv->drm, "bad AVI infoframe\n");
> + return;
> + }
> +
Because intel_hdmi_compute_avi_infoframe() enables
HDMI_INFOFRAME_TYPE_AVI,
we should not call
intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA) here.
> + crtc_state->infoframes.enable |=
> + intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_META
> DATA);
> +}
> +
>  static void
>  intel_dp_drrs_compute_config(struct intel_dp *intel_dp,
>struct intel_crtc_state *pipe_config,
> @@ -2807,6 +2823,38 @@ intel_dp_drrs_compute_config(struct intel_dp
> *intel_dp,
>  constant_n, pipe_config->fec_enable);
>  }
>  
> +static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
> +{
> + struct intel_connector *intel_connector = intel_dp-
> >attached_connector;
> + struct drm_connector *connector = _connector->base;
> + int max_frl_rate;
> + int max_lanes, rate_per_lane;
> + int max_dsc_lanes, dsc_rate_per_lane;
> +
> + max_lanes = connector->display_info.hdmi.max_lanes;
> + rate_per_lane = connector-
> >display_info.hdmi.max_frl_rate_per_lane;
> + max_frl_rate = max_lanes * rate_per_lane;
> +
> + if (connector->display_info.hdmi.dsc_cap.v_1p2) {
> + max_dsc_lanes = connector-
> >display_info.hdmi.dsc_cap.max_lanes;
> + dsc_rate_per_lane = connector-
> >display_info.hdmi.dsc_cap.max_frl_rate_per_lane;
> + if (max_dsc_lanes && dsc_rate_per_lane)
> + max_frl_rate = min(max_frl_rate, max_dsc_lanes
> * dsc_rate_per_lane);
> + }
> +
> + return max_frl_rate;
> +}
> +
> +static bool intel_dp_is_hdmi_2_1_sink(struct intel_dp *intel_dp)
> +{
> + if (drm_dp_is_branch(intel_dp->dpcd) &&
> + intel_dp->has_hdmi_sink &&
> + intel_dp_hdmi_sink_max_frl(intel_dp) > 0)
> + return true;
> +
> + return false;
> +}
> +
>  int
>  intel_dp_compute_config(struct intel_encoder *encoder,
>   struct intel_crtc_state *pipe_config,
> @@ -2894,7 +2942,13 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>   intel_dp_drrs_compute_config(intel_dp, pipe_config, output_bpp,
>constant_n);
>   intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
> - intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp,
> pipe_config, conn_state);
> +
> + if (intel_dp_is_hdmi_2_1_sink(intel_dp)) {
> + pipe_config->has_infoframe = true;
> + intel_dp_compute_avi_infoframe_sdp(encoder,
> pipe_config, conn_state);
> + } else {
> + intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp,
> pipe_config, conn_state);
> + }
>  
>   return 0;
>  }
> @@ -4043,28 +4097,6 @@ static int intel_dp_pcon_set_frl_mask(int
> max_frl)
>   return 0;
>  }
>  
> -static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
> -{
> - struct intel_connector *intel_connector = intel_dp-
> >attached_connector;
> - struct drm_connector *connector = _connector->base;
> - int max_frl_rate;
> - int max_lanes, rate_per_lane;
> - int max_dsc_lanes, dsc_rate_per_lane;
> -
> - max_lanes = connector->display_info.hdmi.max_lanes;
> - rate_per_lane = connector-
> >display_info.hdmi.max_frl_rate_per_lane;
> - max_frl_rate = max_lanes * rate_per_lane;
> -
> 

[Intel-gfx] [PATCH] drm/i915/gt: Remove timeslice suppression

2021-01-07 Thread Chris Wilson
In the next^W future patch, we remove the strict priority system and
continuously re-evaluate the relative priority of tasks. As such we need
to enable the timeslice whenever there is more than one context in the
pipeline. This simplifies the decision and removes some of the tweaks to
suppress timeslicing, allowing us to lift the timeslice enabling to a
common spot at the end of running the submission tasklet.

One consequence of the suppression is that it was reducing fairness
between virtual engines on an over saturated system; undermining the
principle for timeslicing.

v2: Commentary
v3: Commentary for the right cancel_timer()
v4: Add tracing for why we need a timeslice

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2802
Testcase: igt/gem_exec_balancer/fairslice
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Andi Shyti 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |  10 -
 .../drm/i915/gt/intel_execlists_submission.c  | 223 +-
 2 files changed, 118 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 430066e5884c..df62e793e747 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -238,16 +238,6 @@ struct intel_engine_execlists {
 */
unsigned int port_mask;
 
-   /**
-* @switch_priority_hint: Second context priority.
-*
-* We submit multiple contexts to the HW simultaneously and would
-* like to occasionally switch between them to emulate timeslicing.
-* To know when timeslicing is suitable, we track the priority of
-* the context submitted second.
-*/
-   int switch_priority_hint;
-
/**
 * @queue_priority_hint: Highest pending priority.
 *
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index a5b442683c18..2f8e10450f7e 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1148,25 +1148,6 @@ static void defer_active(struct intel_engine_cs *engine)
defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
 }
 
-static bool
-need_timeslice(const struct intel_engine_cs *engine,
-  const struct i915_request *rq)
-{
-   int hint;
-
-   if (!intel_engine_has_timeslices(engine))
-   return false;
-
-   hint = max(engine->execlists.queue_priority_hint,
-  virtual_prio(>execlists));
-
-   if (!list_is_last(>sched.link, >active.requests))
-   hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
-
-   GEM_BUG_ON(hint >= I915_PRIORITY_UNPREEMPTABLE);
-   return hint >= effective_prio(rq);
-}
-
 static bool
 timeslice_yield(const struct intel_engine_execlists *el,
const struct i915_request *rq)
@@ -1186,76 +1167,83 @@ timeslice_yield(const struct intel_engine_execlists *el,
return rq->context->lrc.ccid == READ_ONCE(el->yield);
 }
 
-static bool
-timeslice_expired(const struct intel_engine_execlists *el,
- const struct i915_request *rq)
+static bool needs_timeslice(const struct intel_engine_cs *engine,
+   const struct i915_request *rq)
 {
+   if (!intel_engine_has_timeslices(engine))
+   return false;
+
+   /* If not currently active, or about to switch, wait for next event */
+   if (!rq || __i915_request_is_complete(rq))
+   return false;
+
+   /* We do not need to start the timeslice until after the ACK */
+   if (READ_ONCE(engine->execlists.pending[0]))
+   return false;
+
+   /* If ELSP[1] is occupied, always check to see if worth slicing */
+   if (!list_is_last_rcu(>sched.link, >active.requests)) {
+   ENGINE_TRACE(engine, "timeslice required for second inflight 
context\n");
+   return true;
+   }
+
+   /* Otherwise, ELSP[0] is by itself, but may be waiting in the queue */
+   if (!RB_EMPTY_ROOT(>execlists.queue.rb_root)) {
+   ENGINE_TRACE(engine, "timeslice required for queue\n");
+   return true;
+   }
+
+   if (!RB_EMPTY_ROOT(>execlists.virtual.rb_root)) {
+   ENGINE_TRACE(engine, "timeslice required for virtual\n");
+   return true;
+   }
+
+   return false;
+}
+
+static bool
+timeslice_expired(struct intel_engine_cs *engine, const struct i915_request 
*rq)
+{
+   const struct intel_engine_execlists *el = >execlists;
+
+   if (i915_request_has_nopreempt(rq) && __i915_request_has_started(rq))
+   return false;
+
+   if (!needs_timeslice(engine, rq))
+   return false;
+
return timer_expired(>timer) || timeslice_yield(el, rq);
 }
 
-static int
-switch_prio(struct 

Re: [Intel-gfx] v5.10 stable backport request

2021-01-07 Thread Greg KH
On Wed, Jan 06, 2021 at 09:09:45PM +0200, Imre Deak wrote:
> On Wed, Jan 06, 2021 at 07:04:42PM +0100, Greg KH wrote:
> > On Wed, Jan 06, 2021 at 07:53:01PM +0200, Imre Deak wrote:
> > > Stable team, please backport the upstream commit
> > > 
> > > 8f329967d596 ("drm/i915/tgl: Fix Combo PHY DPLL fractional divider for 
> > > 38.4MHz ref clock")
> > > 
> > > to the v5.10 stable kernel.
> > 
> > I see no such commit id in Linus's kernel :(
> 
> Sorry, the commit id correctly is
> 
> 0e2497e334de42dbaaee8e325241b5b5b34ede7e

Much better :)

Now queued up, thanks.

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


Re: [Intel-gfx] [PATCH] drm/i915/icl: Fix initing the DSI DSC power refcount during HW readout

2021-01-07 Thread Imre Deak
On Thu, Jan 07, 2021 at 09:01:40AM +0200, Jani Nikula wrote:
> On Wed, 09 Dec 2020, Imre Deak  wrote:
> > For an enabled DSC during HW readout the corresponding power reference
> > is taken along the CRTC power domain references in
> > get_crtc_power_domains(). Remove the incorrect get ref from the DSI
> > encoder hook.
> 
> Does this fix [1] which is v5.11-rc2 on TGL DSI?

Yes, looks like it:
<4> [199.269612] i915 :00:02.0: i915 raw-wakerefs=1 wakelocks=1 on cleanup
...
<7> [199.277233] i915 Wakeref x1 taken at:
intel_display_power_get+0x1f/0x60 [i915]
intel_modeset_setup_hw_state+0xbcf/0x19b0 [i915]

> Should we pick this up for fixes?

Yes.

Thanks,
Imre

> BR,
> Jani.
> 
> 
> [1] 
> https://intel-gfx-ci.01.org/tree/drm-intel-fixes/CI_DIF_538/fi-tgl-dsi/igt@gem_exec_susp...@basic-s0.html
> 
> 
> 
> >
> > Cc: Vandita Kulkarni 
> > Cc: Jani Nikula 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c | 4 
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index a9439b415603..b3533a32f8ba 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -1616,10 +1616,6 @@ static void gen11_dsi_get_power_domains(struct 
> > intel_encoder *encoder,
> >  
> > get_dsi_io_power_domains(i915,
> >  enc_to_intel_dsi(encoder));
> > -
> > -   if (crtc_state->dsc.compression_enable)
> > -   intel_display_power_get(i915,
> > -   intel_dsc_power_domain(crtc_state));
> >  }
> >  
> >  static bool gen11_dsi_get_hw_state(struct intel_encoder *encoder,
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v3] drm/i915/gt: Remove timeslice suppression

2021-01-07 Thread Tvrtko Ursulin



On 07/01/2021 11:05, Chris Wilson wrote:

In the next^W future patch, we remove the strict priority system and
continuously re-evaluate the relative priority of tasks. As such we need
to enable the timeslice whenever there is more than one context in the
pipeline. This simplifies the decision and removes some of the tweaks to
suppress timeslicing, allowing us to lift the timeslice enabling to a
common spot at the end of running the submission tasklet.

One consequence of the suppression is that it was reducing fairness
between virtual engines on an over saturated system; undermining the
principle for timeslicing.

v2: Commentary
v3: Commentary for the right cancel_timer()

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2802
Testcase: igt/gem_exec_balancer/fairslice
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/gt/intel_engine_types.h  |  10 -
  .../drm/i915/gt/intel_execlists_submission.c  | 204 +-
  2 files changed, 99 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 430066e5884c..df62e793e747 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -238,16 +238,6 @@ struct intel_engine_execlists {
 */
unsigned int port_mask;
  
-	/**

-* @switch_priority_hint: Second context priority.
-*
-* We submit multiple contexts to the HW simultaneously and would
-* like to occasionally switch between them to emulate timeslicing.
-* To know when timeslicing is suitable, we track the priority of
-* the context submitted second.
-*/
-   int switch_priority_hint;
-
/**
 * @queue_priority_hint: Highest pending priority.
 *
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index a5b442683c18..13be71a81a38 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1148,25 +1148,6 @@ static void defer_active(struct intel_engine_cs *engine)
defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
  }
  
-static bool

-need_timeslice(const struct intel_engine_cs *engine,
-  const struct i915_request *rq)
-{
-   int hint;
-
-   if (!intel_engine_has_timeslices(engine))
-   return false;
-
-   hint = max(engine->execlists.queue_priority_hint,
-  virtual_prio(>execlists));
-
-   if (!list_is_last(>sched.link, >active.requests))
-   hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
-
-   GEM_BUG_ON(hint >= I915_PRIORITY_UNPREEMPTABLE);
-   return hint >= effective_prio(rq);
-}
-
  static bool
  timeslice_yield(const struct intel_engine_execlists *el,
const struct i915_request *rq)
@@ -1186,76 +1167,74 @@ timeslice_yield(const struct intel_engine_execlists *el,
return rq->context->lrc.ccid == READ_ONCE(el->yield);
  }
  
-static bool

-timeslice_expired(const struct intel_engine_execlists *el,
- const struct i915_request *rq)
+static bool needs_timeslice(const struct intel_engine_cs *engine,
+   const struct i915_request *rq)
  {
+   if (!intel_engine_has_timeslices(engine))
+   return false;
+
+   /* If not currently active, or about to switch, wait for next event */
+   if (!rq || __i915_request_is_complete(rq))
+   return false;
+
+   /* We do not need to start the timeslice until after the ACK */
+   if (READ_ONCE(engine->execlists.pending[0]))
+   return false;
+
+   /* If ELSP[1] is occupied, always check to see if worth slicing */
+   if (!list_is_last_rcu(>sched.link, >active.requests))
+   return true;
+
+   /* Otherwise, ELSP[0] is by itself, but may be waiting in the queue */
+   if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
+   return true;
+
+   return !RB_EMPTY_ROOT(>execlists.virtual.rb_root);
+}
+
+static bool
+timeslice_expired(struct intel_engine_cs *engine, const struct i915_request 
*rq)
+{
+   const struct intel_engine_execlists *el = >execlists;
+
+   if (i915_request_has_nopreempt(rq) && __i915_request_has_started(rq))
+   return false;
+
+   if (!needs_timeslice(engine, rq))
+   return false;
+
return timer_expired(>timer) || timeslice_yield(el, rq);
  }
  
-static int

-switch_prio(struct intel_engine_cs *engine, const struct i915_request *rq)
-{
-   if (list_is_last(>sched.link, >active.requests))
-   return engine->execlists.queue_priority_hint;
-
-   return rq_prio(list_next_entry(rq, sched.link));
-}
-
-static inline unsigned long
-timeslice(const struct intel_engine_cs *engine)
+static unsigned long timeslice(const struct 

Re: [Intel-gfx] [PATCH 4/4] drm/i915/gt: Remove timeslice suppression

2021-01-07 Thread Tvrtko Ursulin



On 07/01/2021 10:27, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2021-01-07 10:16:57)


On 06/01/2021 16:08, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2021-01-06 15:57:49)


[snip]


@@ -1363,16 +1336,16 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
__unwind_incomplete_requests(engine);

last = NULL;

- } else if (need_timeslice(engine, last) &&
-timeslice_expired(execlists, last)) {
+ } else if (timeslice_expired(engine, last)) {
ENGINE_TRACE(engine,
-  "expired last=%llx:%lld, prio=%d, hint=%d, 
yield?=%s\n",
-  last->fence.context,
-  last->fence.seqno,
-  last->sched.attr.priority,
+  "expired:%s last=%llx:%lld, prio=%d, hint=%d, 
yield?=%s\n",
+  yesno(timer_expired(>timer)),
+  last->fence.context, last->fence.seqno,
+  rq_prio(last),
 execlists->queue_priority_hint,
 yesno(timeslice_yield(execlists, last)));

+ cancel_timer(>timer);


What is this cancel for?


This branch is taken upon yielding the timeslice, but we may not submit
a new pair of contexts, leaving the timer active (and marked as
expired). Since the timer remains expired, we will continuously looped
until a context switch, or some other preemption event.


Sorry I was looking at the cancel_timer in process_csb and ended up
replying at the wrong spot. The situation there seems to be removing the
single timeslice related call (set_timeslice) and adding a cancel_timer
which is also not obvious to me what it is about.


Yes, there the cancel_timer() is equivalent to the old set_timeslice().

After processing an event, we assume it is a change in context meriting
a new timeslice. To start a new timeslice rather than continue the old
one, we remove an existing timer and readd it for the end of the
timeslice.


I was looking what is the resulting symmetry of start/cancel call sites. 
We end up with a single start_timeslice call from the tasklet, but 
guarded with !pending. That looked confusing at first until I remembered 
you mentioned (or a comment somewhere already says) that the idea is to 
only start the timeslice after the csb ack.


That explains the transition from timer disabled to timer enabled.

Then as long as there are contexts queued code relies on timeslice 
expiry, or re-submission with change, to temporarily suspend the timer.


It looks okay as far as I can see. Will tag the latest.

Regards,

Tvrtko

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


Re: [Intel-gfx] [PULL] drm-misc-next

2021-01-07 Thread Daniel Vetter
On Wed, Jan 06, 2021 at 12:13:12PM +0100, Maarten Lankhorst wrote:
> drm-misc-next-2021-01-06:
> drm-misc-next for v5.12:
> 
> Core Changes:
> - Lots of drm documentation updates by Simor Ser.

Extra kudos for documentation work!

> - Require that each crtc has a unique primary plane.
> - Add fixme that fbdev_generic_setup is confusing.
> 
> Driver Changes:
> - Update addresses for TI display drivers maintainers.
> - Make DRM_VIRTIO_GPU select VIRTIO.
> - Small fixes to qxl, virtio, hisilicon, tve200, panel/s6e63m0.
> The following changes since commit 5fbd41d3bf123af6a135bdea564087ec0f563eb0:
> 
>   Merge tag 'drm-misc-next-2020-11-27-1' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2020-12-15 10:21:48 
> +0100)

Pulled, thanks.
-Daniel

> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-01-06
> 
> for you to fetch changes up to cf9a4be47fd14473b4d0dd6f494ed7279c2bc8a0:
> 
>   drm/doc: render drm.h uapi docs (2021-01-05 14:22:26 +0100)
> 
> 
> drm-misc-next for v5.12:
> 
> Core Changes:
> - Lots of drm documentation updates by Simor Ser.
> - Require that each crtc has a unique primary plane.
> - Add fixme that fbdev_generic_setup is confusing.
> 
> Driver Changes:
> - Update addresses for TI display drivers maintainers.
> - Make DRM_VIRTIO_GPU select VIRTIO.
> - Small fixes to qxl, virtio, hisilicon, tve200, panel/s6e63m0.
> 
> 
> Arnd Bergmann (1):
>   drm/kmb: fix array bounds warning
> 
> Bernard Zhao (1):
>   via/via_irq: use __func__ to replace string function name
> 
> Chia-I Wu (1):
>   drm/virtio: align blob resources to page sizes
> 
> Christian König (13):
>   drm/radeon: fix check order in radeon_bo_move
>   drm/radeon: stop using pages with drm_prime_sg_to_page_addr_arrays v2
>   drm/amdgpu: stop using pages with drm_prime_sg_to_page_addr_arrays
>   drm/nouveau: stop using pages with drm_prime_sg_to_page_addr_arrays v2
>   drm/vmwgfx: switch to ttm_sg_tt_init
>   drm/qxl: switch to ttm_sg_tt_init
>   drm/ttm: nuke ttm_dma_tt_init
>   drm/prime: split array import functions v4
>   drm/ttm/drivers: remove unecessary ttm_module.h include v2
>   drm/ttm: stop destroying pinned ghost object
>   drm/ttm: cleanup BO size handling v3
>   drm/ttm: use pin_count more extensively
>   drm/ttm: cleanup LRU handling further
> 
> Chuhong Yuan (1):
>   drm/fb-helper: Add missed unlocks in setcmap_legacy()
> 
> Dafna Hirschfeld (2):
>   drm/rockchip: for error print, use the correct device pointer
>   drm/rockchip: fix typo in Kconfig 's/HDMI/dsi/'
> 
> Dan Carpenter (3):
>   drm/kmb: Remove an unnecessary NULL check
>   gma500: clean up error handling in init
>   drm/panel: khadas: Fix error code in khadas_ts050_panel_add()
> 
> Daniel Vetter (10):
>   drm/ttm: Warn on pinning without holding a reference
>   drm/nouveau: Drop mutex_lock_nested for atomic
>   dma-buf: Fix kerneldoc formatting
>   drm/vkms: Unset preferred_depth
>   drm/amdkfd: fix ttm size refactor fallout
>   dma-buf: Remove kmap kerneldoc vestiges
>   dma-buf: some kerneldoc formatting fixes
>   dma-buf: begin/end_cpu might lock the dma_resv lock
>   dma-buf: doc polish for pin/unpin
>   drm/fb-helper: Add a FIXME that generic_setup is very confusing
> 
> Dave Stevenson (4):
>   drm/vc4: dsi: Correct DSI register definition
>   drm/vc4: dsi: Add support for DSI0
>   dt-bindings: Add compatible for BCM2711 DSI1
>   drm/vc4: dsi: Add configuration for BCM2711 DSI1
> 
> Douglas Anderson (7):
>   drm: panel: simple: Fixup the struct panel_desc kernel doc
>   drm: panel: simple: Defer unprepare delay till next prepare to shorten 
> it
>   drm: panel: simple: Allow specifying the delay from prepare to enable
>   dt-bindings: dt-bindings: display: simple: Add BOE NV110WTM-N61
>   drm: panel: simple: Add BOE NV110WTM-N61
>   drm: panel: Fully transition panel_desc kerneldoc to inline style
>   drm: panel: add flags to BOE NV110WTM-N61
> 
> Enrico Weigelt, metux IT consult (1):
>   drivers: gpu: drm: virtio: fix dependency of DRM_VIRTIO_GPU on VIRTIO
> 
> Guido Günther (6):
>   drm/panel: st7703: Use dev_err_probe
>   drm/panel: mantix: Tweak init sequence
>   drm/panel: mantix: Allow to specify default mode for different panels
>   drm/panel: mantix: Support panel from Shenzhen Yashi Changhua 
> Intelligent Technology Co
>   dt-bindings: vendor-prefixes: Add ys vendor prefix
>   dt-bindings: display: mantix: Add compatible for panel from YS
> 
> Gurchetan Singh (3):
>   drm/virtio: virtio_{blah} --> virtio_gpu_{blah}
>   drm/virtio: rework virtio_fence_signaled
>   drm/virtio: consider dma-fence context when signaling
> 
> Jialin 

[Intel-gfx] [CI 2/2] drm/i915/gt: Remove timeslice suppression

2021-01-07 Thread Chris Wilson
In the next^W future patch, we remove the strict priority system and
continuously re-evaluate the relative priority of tasks. As such we need
to enable the timeslice whenever there is more than one context in the
pipeline. This simplifies the decision and removes some of the tweaks to
suppress timeslicing, allowing us to lift the timeslice enabling to a
common spot at the end of running the submission tasklet.

One consequence of the suppression is that it was reducing fairness
between virtual engines on an over saturated system; undermining the
principle for timeslicing.

v2: Commentary
v3: Commentary for the right cancel_timer()

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2802
Testcase: igt/gem_exec_balancer/fairslice
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |  10 -
 .../drm/i915/gt/intel_execlists_submission.c  | 214 +-
 2 files changed, 109 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 430066e5884c..df62e793e747 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -238,16 +238,6 @@ struct intel_engine_execlists {
 */
unsigned int port_mask;
 
-   /**
-* @switch_priority_hint: Second context priority.
-*
-* We submit multiple contexts to the HW simultaneously and would
-* like to occasionally switch between them to emulate timeslicing.
-* To know when timeslicing is suitable, we track the priority of
-* the context submitted second.
-*/
-   int switch_priority_hint;
-
/**
 * @queue_priority_hint: Highest pending priority.
 *
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index a5b442683c18..c13b362bf1ed 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1148,25 +1148,6 @@ static void defer_active(struct intel_engine_cs *engine)
defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
 }
 
-static bool
-need_timeslice(const struct intel_engine_cs *engine,
-  const struct i915_request *rq)
-{
-   int hint;
-
-   if (!intel_engine_has_timeslices(engine))
-   return false;
-
-   hint = max(engine->execlists.queue_priority_hint,
-  virtual_prio(>execlists));
-
-   if (!list_is_last(>sched.link, >active.requests))
-   hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
-
-   GEM_BUG_ON(hint >= I915_PRIORITY_UNPREEMPTABLE);
-   return hint >= effective_prio(rq);
-}
-
 static bool
 timeslice_yield(const struct intel_engine_execlists *el,
const struct i915_request *rq)
@@ -1186,76 +1167,74 @@ timeslice_yield(const struct intel_engine_execlists *el,
return rq->context->lrc.ccid == READ_ONCE(el->yield);
 }
 
-static bool
-timeslice_expired(const struct intel_engine_execlists *el,
- const struct i915_request *rq)
+static bool needs_timeslice(const struct intel_engine_cs *engine,
+   const struct i915_request *rq)
 {
+   if (!intel_engine_has_timeslices(engine))
+   return false;
+
+   /* If not currently active, or about to switch, wait for next event */
+   if (!rq || __i915_request_is_complete(rq))
+   return false;
+
+   /* We do not need to start the timeslice until after the ACK */
+   if (READ_ONCE(engine->execlists.pending[0]))
+   return false;
+
+   /* If ELSP[1] is occupied, always check to see if worth slicing */
+   if (!list_is_last_rcu(>sched.link, >active.requests))
+   return true;
+
+   /* Otherwise, ELSP[0] is by itself, but may be waiting in the queue */
+   if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
+   return true;
+
+   return !RB_EMPTY_ROOT(>execlists.virtual.rb_root);
+}
+
+static bool
+timeslice_expired(struct intel_engine_cs *engine, const struct i915_request 
*rq)
+{
+   const struct intel_engine_execlists *el = >execlists;
+
+   if (i915_request_has_nopreempt(rq) && __i915_request_has_started(rq))
+   return false;
+
+   if (!needs_timeslice(engine, rq))
+   return false;
+
return timer_expired(>timer) || timeslice_yield(el, rq);
 }
 
-static int
-switch_prio(struct intel_engine_cs *engine, const struct i915_request *rq)
-{
-   if (list_is_last(>sched.link, >active.requests))
-   return engine->execlists.queue_priority_hint;
-
-   return rq_prio(list_next_entry(rq, sched.link));
-}
-
-static inline unsigned long
-timeslice(const struct intel_engine_cs *engine)
+static unsigned long timeslice(const struct intel_engine_cs *engine)
 {

[Intel-gfx] [CI 1/2] drm/i915: Wrap our timer_list.expires checking

2021-01-07 Thread Chris Wilson
Refactor our timer_list.expires checking into its own timer_active()
helper.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_utils.c | 2 +-
 drivers/gpu/drm/i915/i915_utils.h | 7 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.c 
b/drivers/gpu/drm/i915/i915_utils.c
index 4c305d838016..f9e780dee9de 100644
--- a/drivers/gpu/drm/i915/i915_utils.c
+++ b/drivers/gpu/drm/i915/i915_utils.c
@@ -87,7 +87,7 @@ bool i915_error_injected(void)
 
 void cancel_timer(struct timer_list *t)
 {
-   if (!READ_ONCE(t->expires))
+   if (!timer_active(t))
return;
 
del_timer(t);
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 54773371e6bd..abd4dcd9f79c 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -438,9 +438,14 @@ static inline void __add_taint_for_CI(unsigned int taint)
 void cancel_timer(struct timer_list *t);
 void set_timer_ms(struct timer_list *t, unsigned long timeout);
 
+static inline bool timer_active(const struct timer_list *t)
+{
+   return READ_ONCE(t->expires);
+}
+
 static inline bool timer_expired(const struct timer_list *t)
 {
-   return READ_ONCE(t->expires) && !timer_pending(t);
+   return timer_active(t) && !timer_pending(t);
 }
 
 /*
-- 
2.20.1

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


[Intel-gfx] [PATCH] drm/i915/gt: Show the per-engine runtime in sysfs

2021-01-07 Thread Chris Wilson
Since we already report the per-engine runtime via PMU (using sampling
if a direct measure is not available), and in debugfs, also trivially
include the information for each engine under sysfs as a read-only
property. We only present the total milliseconds to hide any misleading
accuracy and to purposely reduce the precision of the global
unprivileged information.

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

diff --git a/drivers/gpu/drm/i915/gt/sysfs_engines.c 
b/drivers/gpu/drm/i915/gt/sysfs_engines.c
index ec49ffa8d9b9..9759f268828a 100644
--- a/drivers/gpu/drm/i915/gt/sysfs_engines.c
+++ b/drivers/gpu/drm/i915/gt/sysfs_engines.c
@@ -452,6 +452,19 @@ heartbeat_default(struct kobject *kobj, struct 
kobj_attribute *attr, char *buf)
 static struct kobj_attribute heartbeat_interval_def =
 __ATTR(heartbeat_interval_ms, 0444, heartbeat_default, NULL);
 
+static ssize_t
+runtime_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
+{
+   struct intel_engine_cs *engine = kobj_to_engine(kobj);
+   ktime_t dummy;
+
+   return sprintf(buf, "%llu\n",
+  ktime_to_ms(intel_engine_get_busy_time(engine, )));
+}
+
+static struct kobj_attribute runtime_attr =
+__ATTR(runtime_ms, 0444, runtime_show, NULL);
+
 static void kobj_engine_release(struct kobject *kobj)
 {
kfree(kobj);
@@ -564,6 +577,10 @@ void intel_engines_add_sysfs(struct drm_i915_private *i915)
sysfs_create_file(kobj, _timeout_attr.attr))
goto err_engine;
 
+   if (intel_engine_supports_stats(engine) &&
+   sysfs_create_file(kobj, _attr.attr))
+   goto err_engine;
+
add_defaults(container_of(kobj, struct kobj_engine, base));
 
if (0) {
-- 
2.20.1

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


Re: [Intel-gfx] [PULL] drm-intel-next

2021-01-07 Thread Daniel Vetter
On Mon, Jan 04, 2021 at 01:10:18PM -0800, Rodrigo Vivi wrote:
> Hi Dave and Daniel,
> 
> Happy New Year.
> 
> Here goes the first pull request targeting 5.12.
> 
> drm-intel-next-2021-01-04:
> - Display hotplug fix for gen2/gen3 (Chris)
> - Remove trailing semicolon (Tom)
> - Suppress display warnings for old ifwi presend on our CI (Chris)
> - OA/Perf related workaround (Lionel)
> - Replace I915_READ/WRITE per new uncore and display read/write functions 
> (Jani)\
> .
> - PSR improvements (Jose)
> - HDR and other color changes on LSPCON (Uma, Ville)
> - FBC fixes for TGL (Uma)
> - Record plane update times for debugging (Chris)
> - Refactor panel backlight control functions (Dave)
> - Display power improvements (Imre)
> - Add VRR register definition (Manasi)
> - Atomic modeset improvements for bigjoiner pipes (Ville)
> - Switch off the scanout during driver unregister (Chris)
> - Clean-up DP's FEW enable (Manasi)
> - Fix VDSCP slice count (Manasi)
> - Fix and clean up around rc_model_size for DSC (Jani)
> - Remove Type-C noisy debug warn message (Sean)
> - Display HPD code clean-up (Ville)
> - Refactor Intel Display (Dave)
> - Start adding support for Intel's eDP backlight controls (Lyude)

Pulled, thanks.
-Daniel

> 
> Thanks,
> Rodrigo.
> 
> The following changes since commit b3bf99daaee96a141536ce5c60a0d6dba6ec1d23:
> 
>   drm/i915/display: Defer initial modeset until after GGTT is initialised 
> (2020-11-26 11:01:52 +)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-01-04
> 
> for you to fetch changes up to b3304591f14b437b6bccd8dbff06006c11837031:
> 
>   drm/i915/dp: Track pm_qos per connector (2020-12-30 21:22:55 +)
> 
> 
> - Display hotplug fix for gen2/gen3 (Chris)
> - Remove trailing semicolon (Tom)
> - Suppress display warnings for old ifwi presend on our CI (Chris)
> - OA/Perf related workaround (Lionel)
> - Replace I915_READ/WRITE per new uncore and display read/write functions 
> (Jani)\
> .
> - PSR improvements (Jose)
> - HDR and other color changes on LSPCON (Uma, Ville)
> - FBC fixes for TGL (Uma)
> - Record plane update times for debugging (Chris)
> - Refactor panel backlight control functions (Dave)
> - Display power improvements (Imre)
> - Add VRR register definition (Manasi)
> - Atomic modeset improvements for bigjoiner pipes (Ville)
> - Switch off the scanout during driver unregister (Chris)
> - Clean-up DP's FEW enable (Manasi)
> - Fix VDSCP slice count (Manasi)
> - Fix and clean up around rc_model_size for DSC (Jani)
> - Remove Type-C noisy debug warn message (Sean)
> - Display HPD code clean-up (Ville)
> - Refactor Intel Display (Dave)
> - Start adding support for Intel's eDP backlight controls (Lyude)
> 
> 
> Chris Wilson (6):
>   Revert "drm/i915: re-order if/else ladder for hpd_irq_setup"
>   drm/i915/display: Suppress "Combo PHY A HW state changed unexpectedly"
>   drm/i915/display: Record the plane update times for debugging
>   drm/i915/gem: Spring clean debugfs
>   drm/i915: Disable outputs during unregister
>   drm/i915/dp: Track pm_qos per connector
> 
> Dave Airlie (6):
>   drm/i915: refactor panel backlight control functions. (v2)
>   drm/i915/display: move needs_modeset to an inline in header
>   drm/i915/display: move to_intel_frontbuffer to header
>   drm/i915/display: fix misused comma
>   drm/i915: refactor cursor code out of i915_display.c
>   drm/i915: refactor i915 plane code into separate file.
> 
> Imre Deak (10):
>   drm/i915: Use CRTC index consistently during getting/putting CRTC power 
> domains
>   drm/i915: Factor out helpers to get/put a set of tracked power domains
>   drm/i915: Track power references taken for enabled CRTCs
>   drm/i915/ddi: Track power reference taken for encoder DDI IO use
>   drm/i915/ddi: Track power reference taken for encoder main lane AUX use
>   drm/i915: Track power reference taken for eDP VDD
>   drm/i915: Rename power_domains.wakeref to init_wakeref
>   drm/i915: Track power reference taken to disable power well 
> functionality
>   drm/i915: Make intel_display_power_put_unchecked() an internal-only 
> function
>   drm/i915/icl: Fix initing the DSI DSC power refcount during HW readout
> 
> Jani Nikula (15):
>   drm/i915/debugfs: remove RPS autotuning details from i915_rps_boost_info
>   drm/i915: remove last traces of I915_READ_FW() and I915_WRITE_FW()
>   drm/i915/cdclk: prefer intel_de_write() over I915_WRITE()
>   drm/i915/debugfs: remove the i915_cache_sharing debugfs file
>   drm/i915/debugfs: replace I915_READ() with intel_uncore_read()
>   drm/i915/suspend: replace I915_READ()/WRITE() with 
> intel_de_read()/write()
>   drm/i915/pm: replace I915_READ()/WRITE() with 
> intel_uncore_read()/write()
>   

[Intel-gfx] [PATCH] drm/i915/pps: Reuse POWER_DOMAIN_DISPLAY_CORE in pps_{lock, unlock}

2021-01-07 Thread Anshuman Gupta
We need a power_domain wakeref in pps_{lock,unlock} to prevent
a race while resetting pps state in intel_power_sequencer_reset().

intel_power_sequencer_reset() need a pps_mutex to access pps_pipe
but it can't grab pps_mutex due to deadlock with power_well
functions are called while holding pps_mutex.
intel_power_sequencer_reset() is called by power_well function
associated with legacy platforms like vlv and chv therefore re-use
the POWER_DOMAIN_DISPLAY_CORE power domain, which only used
by vlv and chv display power domain.

This will avoids the unnecessary noise of unrelated power wells
in pps_{lock,unlock}.

Cc: Jani Nikula 
Cc: Imre Deak 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8a00e609085f..4f190a82d4ad 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -895,9 +895,7 @@ pps_lock(struct intel_dp *intel_dp)
 * See intel_power_sequencer_reset() why we need
 * a power domain reference here.
 */
-   wakeref = intel_display_power_get(dev_priv,
- 
intel_aux_power_domain(dp_to_dig_port(intel_dp)));
-
+   wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_DISPLAY_CORE);
mutex_lock(_priv->pps_mutex);
 
return wakeref;
@@ -909,9 +907,7 @@ pps_unlock(struct intel_dp *intel_dp, intel_wakeref_t 
wakeref)
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
 
mutex_unlock(_priv->pps_mutex);
-   intel_display_power_put(dev_priv,
-   
intel_aux_power_domain(dp_to_dig_port(intel_dp)),
-   wakeref);
+   intel_display_power_put(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref);
return 0;
 }
 
-- 
2.26.2

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


[Intel-gfx] [PATCH] drm/i915/pps: Reuse POWER_DOMAIN_DISPLAY_CORE in pps_{lock, unlock}

2021-01-07 Thread Anshuman Gupta
We need a power_domain wakeref in pps_{lock,unlock} to prevent
a race while resetting pps state in intel_power_sequencer_reset().

intel_power_sequencer_reset() need a pps_mutex to access pps_pipe
but it can't grab pps_mutex due to deadlock with power_well
functions are called while holding pps_mutex.
intel_power_sequencer_reset() is called by power_well function
associated with legacy platforms like vlv and chv therefore re-use
the POWER_DOMAIN_DISPLAY_CORE power domain, which only used
by vlv and chv display power domain.

This will avoids the unnecessary noise of unrelated power wells
in pps_{lock,unlock}.

Cc: Jani Nikula 
Cc: Imre Deak 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8a00e609085f..4f190a82d4ad 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -895,9 +895,7 @@ pps_lock(struct intel_dp *intel_dp)
 * See intel_power_sequencer_reset() why we need
 * a power domain reference here.
 */
-   wakeref = intel_display_power_get(dev_priv,
- 
intel_aux_power_domain(dp_to_dig_port(intel_dp)));
-
+   wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_DISPLAY_CORE);
mutex_lock(_priv->pps_mutex);
 
return wakeref;
@@ -909,9 +907,7 @@ pps_unlock(struct intel_dp *intel_dp, intel_wakeref_t 
wakeref)
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
 
mutex_unlock(_priv->pps_mutex);
-   intel_display_power_put(dev_priv,
-   
intel_aux_power_domain(dp_to_dig_port(intel_dp)),
-   wakeref);
+   intel_display_power_put(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref);
return 0;
 }
 
-- 
2.26.2

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


[Intel-gfx] [PATCH v3] drm/i915/gt: Remove timeslice suppression

2021-01-07 Thread Chris Wilson
In the next^W future patch, we remove the strict priority system and
continuously re-evaluate the relative priority of tasks. As such we need
to enable the timeslice whenever there is more than one context in the
pipeline. This simplifies the decision and removes some of the tweaks to
suppress timeslicing, allowing us to lift the timeslice enabling to a
common spot at the end of running the submission tasklet.

One consequence of the suppression is that it was reducing fairness
between virtual engines on an over saturated system; undermining the
principle for timeslicing.

v2: Commentary
v3: Commentary for the right cancel_timer()

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2802
Testcase: igt/gem_exec_balancer/fairslice
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |  10 -
 .../drm/i915/gt/intel_execlists_submission.c  | 204 +-
 2 files changed, 99 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 430066e5884c..df62e793e747 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -238,16 +238,6 @@ struct intel_engine_execlists {
 */
unsigned int port_mask;
 
-   /**
-* @switch_priority_hint: Second context priority.
-*
-* We submit multiple contexts to the HW simultaneously and would
-* like to occasionally switch between them to emulate timeslicing.
-* To know when timeslicing is suitable, we track the priority of
-* the context submitted second.
-*/
-   int switch_priority_hint;
-
/**
 * @queue_priority_hint: Highest pending priority.
 *
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index a5b442683c18..13be71a81a38 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1148,25 +1148,6 @@ static void defer_active(struct intel_engine_cs *engine)
defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
 }
 
-static bool
-need_timeslice(const struct intel_engine_cs *engine,
-  const struct i915_request *rq)
-{
-   int hint;
-
-   if (!intel_engine_has_timeslices(engine))
-   return false;
-
-   hint = max(engine->execlists.queue_priority_hint,
-  virtual_prio(>execlists));
-
-   if (!list_is_last(>sched.link, >active.requests))
-   hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
-
-   GEM_BUG_ON(hint >= I915_PRIORITY_UNPREEMPTABLE);
-   return hint >= effective_prio(rq);
-}
-
 static bool
 timeslice_yield(const struct intel_engine_execlists *el,
const struct i915_request *rq)
@@ -1186,76 +1167,74 @@ timeslice_yield(const struct intel_engine_execlists *el,
return rq->context->lrc.ccid == READ_ONCE(el->yield);
 }
 
-static bool
-timeslice_expired(const struct intel_engine_execlists *el,
- const struct i915_request *rq)
+static bool needs_timeslice(const struct intel_engine_cs *engine,
+   const struct i915_request *rq)
 {
+   if (!intel_engine_has_timeslices(engine))
+   return false;
+
+   /* If not currently active, or about to switch, wait for next event */
+   if (!rq || __i915_request_is_complete(rq))
+   return false;
+
+   /* We do not need to start the timeslice until after the ACK */
+   if (READ_ONCE(engine->execlists.pending[0]))
+   return false;
+
+   /* If ELSP[1] is occupied, always check to see if worth slicing */
+   if (!list_is_last_rcu(>sched.link, >active.requests))
+   return true;
+
+   /* Otherwise, ELSP[0] is by itself, but may be waiting in the queue */
+   if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
+   return true;
+
+   return !RB_EMPTY_ROOT(>execlists.virtual.rb_root);
+}
+
+static bool
+timeslice_expired(struct intel_engine_cs *engine, const struct i915_request 
*rq)
+{
+   const struct intel_engine_execlists *el = >execlists;
+
+   if (i915_request_has_nopreempt(rq) && __i915_request_has_started(rq))
+   return false;
+
+   if (!needs_timeslice(engine, rq))
+   return false;
+
return timer_expired(>timer) || timeslice_yield(el, rq);
 }
 
-static int
-switch_prio(struct intel_engine_cs *engine, const struct i915_request *rq)
-{
-   if (list_is_last(>sched.link, >active.requests))
-   return engine->execlists.queue_priority_hint;
-
-   return rq_prio(list_next_entry(rq, sched.link));
-}
-
-static inline unsigned long
-timeslice(const struct intel_engine_cs *engine)
+static unsigned long timeslice(const struct intel_engine_cs *engine)
 {
return 

Re: [Intel-gfx] [PATCH] drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence

2021-01-07 Thread Hans de Goede
Hi,

On 11/24/20 4:49 PM, Ville Syrjälä wrote:
> On Wed, Nov 18, 2020 at 01:40:58PM +0100, Hans de Goede wrote:
>> Commit 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
>> added an intel_dsi_msleep() helper which skips sleeping if the
>> MIPI-sequences have a version of 3 or newer and the panel is in vid-mode;
>> and it moved a bunch of msleep-s over to this new helper.
>>
>> This was based on my reading of the big comment around line 730 which
>> starts with "Panel enable/disable sequences from the VBT spec.",
>> where the "v3 video mode seq" column does not have any wait t# entries.
>>
>> Given that this code has been used on a lot of different devices without
>> issues until now, it seems that my interpretation of the spec here is
>> mostly correct.
>>
>> But now I have encountered one device, an Acer Aspire Switch 10 E
>> SW3-016, where the panel will not light up unless we do actually honor the
>> panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence.
>>
>> What seems to set this model apart is that it is lacking a
>> MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on
>> delay usually happens.
>>
>> Fix the panel not lighting up on this model by using an unconditional
>> msleep(panel_on_delay) instead of intel_dsi_msleep() when there is
>> no MIPI_SEQ_DEASSERT_RESET sequence.
>>
>> Fixes: 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/i915/display/vlv_dsi.c | 10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
>> b/drivers/gpu/drm/i915/display/vlv_dsi.c
>> index 194c239ab6b1..ef673277b36d 100644
>> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
>> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
>> @@ -816,10 +816,14 @@ static void intel_dsi_pre_enable(struct 
>> intel_atomic_state *state,
>>  intel_dsi_prepare(encoder, pipe_config);
>>  
>>  intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
>> -intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
>>  
>> -/* Deassert reset */
>> -intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>> +if (dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
>> +intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
>> +/* Deassert reset */
>> +intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>> +} else {
>> +msleep(intel_dsi->panel_on_delay);
>> +}
> 
> Could perhaps use a comment ot explain to the reader what's going on.
> 
> Looks sane enough to me, and if we get this wrong we just get a bigger
> delay than necessary I guess. So mostly harmless.
> 
> Reviewed-by: Ville Syrjälä 

Thank you, and sorry for being slow with getting around to
pushing this to drm-intel-next.

I've just pushed it to drm-intel-next with a comment added above the if
(and dropped the single line comment inside the if), so this now
looks like this:

/*
 * Give the panel time to power-on and then deassert its reset.
 * Depending on the VBT MIPI sequences version the deassert-seq
 * may contain the necessary delay, intel_dsi_msleep() will skip
 * the delay in that case. If there is no deassert-seq, then an
 * unconditional msleep is used to give the panel time to power-on.
 */
if (dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
} else {
msleep(intel_dsi->panel_on_delay);
}

(the code is unchanged from when you reviewed it).

Regards,

Hans

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


[Intel-gfx] [PATCH v3] drm/i915/gt: Remove timeslice suppression

2021-01-07 Thread Chris Wilson
In the next^W future patch, we remove the strict priority system and
continuously re-evaluate the relative priority of tasks. As such we need
to enable the timeslice whenever there is more than one context in the
pipeline. This simplifies the decision and removes some of the tweaks to
suppress timeslicing, allowing us to lift the timeslice enabling to a
common spot at the end of running the submission tasklet.

One consequence of the suppression is that it was reducing fairness
between virtual engines on an over saturated system; undermining the
principle for timeslicing.

v2: Commentary
v3: Commentary for the right cancel_timer()

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2802
Testcase: igt/gem_exec_balancer/fairslice
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |  10 -
 .../drm/i915/gt/intel_execlists_submission.c  | 202 +-
 2 files changed, 97 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 430066e5884c..df62e793e747 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -238,16 +238,6 @@ struct intel_engine_execlists {
 */
unsigned int port_mask;
 
-   /**
-* @switch_priority_hint: Second context priority.
-*
-* We submit multiple contexts to the HW simultaneously and would
-* like to occasionally switch between them to emulate timeslicing.
-* To know when timeslicing is suitable, we track the priority of
-* the context submitted second.
-*/
-   int switch_priority_hint;
-
/**
 * @queue_priority_hint: Highest pending priority.
 *
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index a5b442683c18..19bd1843e4b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1148,25 +1148,6 @@ static void defer_active(struct intel_engine_cs *engine)
defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
 }
 
-static bool
-need_timeslice(const struct intel_engine_cs *engine,
-  const struct i915_request *rq)
-{
-   int hint;
-
-   if (!intel_engine_has_timeslices(engine))
-   return false;
-
-   hint = max(engine->execlists.queue_priority_hint,
-  virtual_prio(>execlists));
-
-   if (!list_is_last(>sched.link, >active.requests))
-   hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
-
-   GEM_BUG_ON(hint >= I915_PRIORITY_UNPREEMPTABLE);
-   return hint >= effective_prio(rq);
-}
-
 static bool
 timeslice_yield(const struct intel_engine_execlists *el,
const struct i915_request *rq)
@@ -1186,76 +1167,74 @@ timeslice_yield(const struct intel_engine_execlists *el,
return rq->context->lrc.ccid == READ_ONCE(el->yield);
 }
 
-static bool
-timeslice_expired(const struct intel_engine_execlists *el,
- const struct i915_request *rq)
+static bool needs_timeslice(const struct intel_engine_cs *engine,
+   const struct i915_request *rq)
 {
+   if (!intel_engine_has_timeslices(engine))
+   return false;
+
+   /* If not currently active, or about to switch, wait for next event */
+   if (!rq || __i915_request_is_complete(rq))
+   return false;
+
+   /* We do not need to start the timeslice until after the ACK */
+   if (READ_ONCE(engine->execlists.pending[0]))
+   return false;
+
+   /* If ELSP[1] is occupied, always check to see if worth slicing */
+   if (!list_is_last_rcu(>sched.link, >active.requests))
+   return true;
+
+   /* Otherwise, ELSP[0] is by itself, but may be waiting in the queue */
+   if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
+   return true;
+
+   return !RB_EMPTY_ROOT(>execlists.virtual.rb_root);
+}
+
+static bool
+timeslice_expired(struct intel_engine_cs *engine, const struct i915_request 
*rq)
+{
+   const struct intel_engine_execlists *el = >execlists;
+
+   if (i915_request_has_nopreempt(rq) && __i915_request_has_started(rq))
+   return false;
+
+   if (!needs_timeslice(engine, rq))
+   return false;
+
return timer_expired(>timer) || timeslice_yield(el, rq);
 }
 
-static int
-switch_prio(struct intel_engine_cs *engine, const struct i915_request *rq)
-{
-   if (list_is_last(>sched.link, >active.requests))
-   return engine->execlists.queue_priority_hint;
-
-   return rq_prio(list_next_entry(rq, sched.link));
-}
-
-static inline unsigned long
-timeslice(const struct intel_engine_cs *engine)
+static unsigned long timeslice(const struct intel_engine_cs *engine)
 {
return 

Re: [Intel-gfx] [PATCH v3 8/8] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev

2021-01-07 Thread Thomas Zimmermann

AFAICT these are false positives. The instances have been fixed already.

Am 07.01.21 um 10:45 schrieb kernel test robot:

Hi Thomas,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next linus/master v5.11-rc2 next-20210104]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-s021-20210107 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
 # apt-get install sparse
 # sparse version: v0.6.3-208-g46a52ca4-dirty
 # 
https://github.com/0day-ci/linux/commit/380912f7b62c23322562c40e19efd7ad84d57e9c
 git remote add linux-review https://github.com/0day-ci/linux
 git fetch --no-tags linux-review 
Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007
 git checkout 380912f7b62c23322562c40e19efd7ad84d57e9c
 # save the attached .config to linux build tree
 make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64

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

All errors (new ones prefixed by >>):

drivers/gpu/drm/gma500/oaktrail_device.c: In function 'oaktrail_chip_setup':

drivers/gpu/drm/gma500/oaktrail_device.c:509:26: error: 'struct drm_device' has 
no member named 'pdev'; did you mean 'dev'?

  509 |  if (pci_enable_msi(dev->pdev))
  |  ^~~~
  |  dev
--
drivers/gpu/drm/gma500/oaktrail_lvds.c: In function 
'oaktrail_lvds_set_power':

drivers/gpu/drm/gma500/oaktrail_lvds.c:63:25: error: 'struct drm_device' has no 
member named 'pdev'; did you mean 'dev'?

   63 |   pm_request_idle(>pdev->dev);
  | ^~~~
  | dev
--
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_clock':
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:69:11: warning: variable 'tmp' 
set but not used [-Wunused-but-set-variable]
   69 |  u32 val, tmp;
  |   ^~~
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_data':
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:83:11: warning: variable 'tmp' 
set but not used [-Wunused-but-set-variable]
   83 |  u32 val, tmp;
  |   ^~~
drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 
'oaktrail_lvds_i2c_init':

drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:148:35: error: 'struct drm_device' 
has no member named 'pdev'; did you mean 'dev'?

  148 |  chan->adapter.dev.parent = >pdev->dev;
  |   ^~~~
  |   dev
--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function 'vmw_driver_load':

drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:661:22: error: 'struct drm_device' has no 
member named 'pdev'; did you mean 'dev'?

  661 |  pci_set_master(dev->pdev);
  |  ^~~~
  |  dev
In file included from drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:31:
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:690:47: error: 'struct drm_device' has 
no member named 'pdev'; did you mean 'dev'?
  690 |  dev_priv->io_start = pci_resource_start(dev->pdev, 0);
  |   ^~~~
include/linux/pci.h:1854:40: note: in definition of macro 
'pci_resource_start'
 1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start)
  |^~~
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:691:49: error: 'struct drm_device' has 
no member named 'pdev'; did you mean 'dev'?
  691 |  dev_priv->vram_start = pci_resource_start(dev->pdev, 1);
  | ^~~~
include/linux/pci.h:1854:40: note: in definition of macro 
'pci_resource_start'
 1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start)
  |^~~
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:692:49: error: 'struct drm_device' has 
no member named 'pdev'; did you mean 'dev'?
  692 |  dev_priv->mmio_start = pci_resource_start(dev->pdev, 2);
  | ^~~~
include/linux/pci.h:1854:40: note: in definition of macro 
'pci_resource_start'
 1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start)
  |^~~
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:842:33: error: 'struct drm_device' has 
no mem

Re: [Intel-gfx] [PATCH 4/4] drm/i915/gt: Remove timeslice suppression

2021-01-07 Thread Chris Wilson
Quoting Tvrtko Ursulin (2021-01-07 10:16:57)
> 
> On 06/01/2021 16:08, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2021-01-06 15:57:49)
> 
> [snip]
> 
> >>> @@ -1363,16 +1336,16 @@ static void execlists_dequeue(struct 
> >>> intel_engine_cs *engine)
> >>>__unwind_incomplete_requests(engine);
> >>>
> >>>last = NULL;
> >>> - } else if (need_timeslice(engine, last) &&
> >>> -timeslice_expired(execlists, last)) {
> >>> + } else if (timeslice_expired(engine, last)) {
> >>>ENGINE_TRACE(engine,
> >>> -  "expired last=%llx:%lld, prio=%d, 
> >>> hint=%d, yield?=%s\n",
> >>> -  last->fence.context,
> >>> -  last->fence.seqno,
> >>> -  last->sched.attr.priority,
> >>> +  "expired:%s last=%llx:%lld, prio=%d, 
> >>> hint=%d, yield?=%s\n",
> >>> +  
> >>> yesno(timer_expired(>timer)),
> >>> +  last->fence.context, last->fence.seqno,
> >>> +  rq_prio(last),
> >>> execlists->queue_priority_hint,
> >>> yesno(timeslice_yield(execlists, 
> >>> last)));
> >>>
> >>> + cancel_timer(>timer);
> >>
> >> What is this cancel for?
> > 
> > This branch is taken upon yielding the timeslice, but we may not submit
> > a new pair of contexts, leaving the timer active (and marked as
> > expired). Since the timer remains expired, we will continuously looped
> > until a context switch, or some other preemption event.
> 
> Sorry I was looking at the cancel_timer in process_csb and ended up 
> replying at the wrong spot. The situation there seems to be removing the 
> single timeslice related call (set_timeslice) and adding a cancel_timer 
> which is also not obvious to me what it is about.

Yes, there the cancel_timer() is equivalent to the old set_timeslice().

After processing an event, we assume it is a change in context meriting
a new timeslice. To start a new timeslice rather than continue the old
one, we remove an existing timer and readd it for the end of the
timeslice.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce Intel PXP component - Mesa single session (rev19)

2021-01-07 Thread Patchwork
== Series Details ==

Series: Introduce Intel PXP component - Mesa single session (rev19)
URL   : https://patchwork.freedesktop.org/series/84620/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9554_full -> Patchwork_19276_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@suspend:
- shard-tglb: [PASS][1] -> [DMESG-WARN][2] +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-tglb3/igt@gem_...@suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-tglb5/igt@gem_...@suspend.html

  * igt@i915_selftest@mock@timelines:
- shard-kbl:  [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-kbl6/igt@i915_selftest@m...@timelines.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-kbl7/igt@i915_selftest@m...@timelines.html
- shard-iclb: [PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-iclb3/igt@i915_selftest@m...@timelines.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-iclb8/igt@i915_selftest@m...@timelines.html
- shard-apl:  [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-apl7/igt@i915_selftest@m...@timelines.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-apl1/igt@i915_selftest@m...@timelines.html
- shard-glk:  [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-glk8/igt@i915_selftest@m...@timelines.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-glk1/igt@i915_selftest@m...@timelines.html
- shard-skl:  [PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl9/igt@i915_selftest@m...@timelines.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-skl2/igt@i915_selftest@m...@timelines.html
- shard-snb:  [PASS][13] -> [DMESG-WARN][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-snb7/igt@i915_selftest@m...@timelines.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-snb2/igt@i915_selftest@m...@timelines.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@system-suspend-devices:
- shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#2411])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-tglb3/igt@i915_pm_...@system-suspend-devices.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-tglb7/igt@i915_pm_...@system-suspend-devices.html

  * igt@i915_selftest@live@gt_heartbeat:
- shard-skl:  [PASS][17] -> [DMESG-FAIL][18] ([i915#2291] / 
[i915#541])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl3/igt@i915_selftest@live@gt_heartbeat.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-skl4/igt@i915_selftest@live@gt_heartbeat.html
- shard-glk:  [PASS][19] -> [DMESG-FAIL][20] ([i915#2291])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-glk9/igt@i915_selftest@live@gt_heartbeat.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-glk2/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@mock@vma:
- shard-skl:  [PASS][21] -> [INCOMPLETE][22] ([i915#2295])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl9/igt@i915_selftest@m...@vma.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-skl2/igt@i915_selftest@m...@vma.html

  * igt@kms_async_flips@test-time-stamp:
- shard-skl:  [PASS][23] -> [DMESG-FAIL][24] ([i915#142])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl8/igt@kms_async_fl...@test-time-stamp.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-skl7/igt@kms_async_fl...@test-time-stamp.html

  * igt@kms_chamelium@dp-frame-dump:
- shard-glk:  NOTRUN -> [SKIP][25] ([fdo#109271] / [fdo#111827]) +1 
similar issue
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19276/shard-glk8/igt@kms_chamel...@dp-frame-dump.html
- 

Re: [Intel-gfx] [PATCH 4/4] drm/i915/gt: Remove timeslice suppression

2021-01-07 Thread Tvrtko Ursulin



On 06/01/2021 16:08, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2021-01-06 15:57:49)


[snip]


@@ -1363,16 +1336,16 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
   __unwind_incomplete_requests(engine);
   
   last = NULL;

- } else if (need_timeslice(engine, last) &&
-timeslice_expired(execlists, last)) {
+ } else if (timeslice_expired(engine, last)) {
   ENGINE_TRACE(engine,
-  "expired last=%llx:%lld, prio=%d, hint=%d, 
yield?=%s\n",
-  last->fence.context,
-  last->fence.seqno,
-  last->sched.attr.priority,
+  "expired:%s last=%llx:%lld, prio=%d, hint=%d, 
yield?=%s\n",
+  yesno(timer_expired(>timer)),
+  last->fence.context, last->fence.seqno,
+  rq_prio(last),
execlists->queue_priority_hint,
yesno(timeslice_yield(execlists, last)));
   
+ cancel_timer(>timer);


What is this cancel for?


This branch is taken upon yielding the timeslice, but we may not submit
a new pair of contexts, leaving the timer active (and marked as
expired). Since the timer remains expired, we will continuously looped
until a context switch, or some other preemption event.


Sorry I was looking at the cancel_timer in process_csb and ended up 
replying at the wrong spot. The situation there seems to be removing the 
single timeslice related call (set_timeslice) and adding a cancel_timer 
which is also not obvious to me what it is about.


Regards,

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hdcp: Disable the QSES check for HDCP 1.4 over MST

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915/hdcp: Disable the QSES check for HDCP 1.4 over MST
URL   : https://patchwork.freedesktop.org/series/8/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9554_full -> Patchwork_19275_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip_tiling@flip-to-y-tiled@edp-1-pipe-c:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl6/igt@kms_flip_tiling@flip-to-y-ti...@edp-1-pipe-c.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19275/shard-skl10/igt@kms_flip_tiling@flip-to-y-ti...@edp-1-pipe-c.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@cursor-dpms:
- shard-iclb: [PASS][3] -> [DMESG-WARN][4] ([i915#1226])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-iclb6/igt@i915_pm_...@cursor-dpms.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19275/shard-iclb5/igt@i915_pm_...@cursor-dpms.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([i915#146] / [i915#151])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl7/igt@i915_pm_...@system-suspend-execbuf.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19275/shard-skl3/igt@i915_pm_...@system-suspend-execbuf.html

  * igt@kms_async_flips@test-time-stamp:
- shard-skl:  [PASS][7] -> [DMESG-FAIL][8] ([i915#142])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl8/igt@kms_async_fl...@test-time-stamp.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19275/shard-skl1/igt@kms_async_fl...@test-time-stamp.html

  * igt@kms_chamelium@dp-frame-dump:
- shard-skl:  NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19275/shard-skl8/igt@kms_chamel...@dp-frame-dump.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-skl:  [PASS][10] -> [FAIL][11] ([i915#54]) +5 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl5/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19275/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html

  * igt@kms_cursor_crc@pipe-c-cursor-128x42-offscreen:
- shard-skl:  NOTRUN -> [FAIL][12] ([i915#54])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19275/shard-skl8/igt@kms_cursor_...@pipe-c-cursor-128x42-offscreen.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl:  NOTRUN -> [FAIL][13] ([i915#2346])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19275/shard-skl5/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

  * igt@kms_flip@flip-vs-expired-vblank@c-edp1:
- shard-skl:  [PASS][14] -> [FAIL][15] ([i915#79])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19275/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html

  * igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a2:
- shard-glk:  [PASS][16] -> [FAIL][17] ([i915#79])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-glk9/igt@kms_flip@flip-vs-expired-vbl...@c-hdmi-a2.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19275/shard-glk9/igt@kms_flip@flip-vs-expired-vbl...@c-hdmi-a2.html

  * igt@kms_flip@flip-vs-suspend-interruptible@c-edp1:
- shard-skl:  [PASS][18] -> [INCOMPLETE][19] ([i915#2295])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl6/igt@kms_flip@flip-vs-suspend-interrupti...@c-edp1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19275/shard-skl10/igt@kms_flip@flip-vs-suspend-interrupti...@c-edp1.html

  * igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#2122])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl9/igt@kms_flip@plain-flip-ts-check-interrupti...@b-edp1.html
   [21]: 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2] runner: Don't kill a test on taint if watching timeouts

2021-01-07 Thread Petri Latvala
On Thu, Jan 07, 2021 at 09:49:23AM +, Chris Wilson wrote:
> Quoting Petri Latvala (2021-01-07 09:40:02)
> > On Wed, Jan 06, 2021 at 09:41:37AM +, Chris Wilson wrote:
> > > Quoting Janusz Krzysztofik (2020-12-04 19:50:07)
> > > > We may still be interested in results of a test even if it has tainted
> > > > the kernel.  On the other hand, we need to kill the test on taint if no
> > > > other means of killing it on a jam is active.
> > > > 
> > > > If abort on both kernel taint or a timeout is requested, decrease all
> > > > potential timeouts significantly while the taint is detected instead of
> > > > aborting immediately.  However, report the taint as the reason of the
> > > > abort if a timeout decreased by the taint expires.
> > > 
> > > This has the nasty side effect of not stopping the test run after a
> > > kernel taint. Instead the next test inherits the tainted condition from
> > > the previous test and usually ends up being declared incomplete.
> > > 
> > > False positives are frustrating.
> > > -Chris
> > 
> > 
> > Do you have a link to a test run where this happened? This patch
> > didn't change the between-tests abort checks.
> 
> The taint is from the warnings in the penultimate test:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9550/shard-skl7/igt_runner20.txt

Ah, I see.

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9550/shard-skl7/dmesg20.txt

This is the tainting WARN I presume:

<4>[  917.575173] Memory manager not clean during takedown.
<4>[  917.575272] WARNING: CPU: 2 PID: 7 at drivers/gpu/drm/drm_mm.c:999 
drm_mm_takedown+0x51/0x100

That happens after @gem, before @evict.

In other words, this is all in the same exec() of i915_selftest
--run-subtest live. Incorrect _dynamic_ subtest gets blamed.

Getting the killing right here is a bit tricky, possibly doable. Or
rather, getting the blame right is doable, killing will be inherently
racy...


-- 
Petri Latvala
___
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/selftests: Skip unstable timing measurements

2021-01-07 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Skip unstable timing measurements
URL   : https://patchwork.freedesktop.org/series/85554/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9554_full -> Patchwork_19274_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@smoketest:
- shard-kbl:  [PASS][1] -> [FAIL][2] ([i915#2896])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-kbl2/igt@gem_ctx_persiste...@smoketest.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-kbl4/igt@gem_ctx_persiste...@smoketest.html

  * igt@i915_query@query-garbage:
- shard-skl:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl4/igt@i915_qu...@query-garbage.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-skl2/igt@i915_qu...@query-garbage.html

  * igt@kms_async_flips@test-time-stamp:
- shard-skl:  [PASS][5] -> [DMESG-FAIL][6] ([i915#142])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl8/igt@kms_async_fl...@test-time-stamp.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-skl3/igt@kms_async_fl...@test-time-stamp.html

  * igt@kms_chamelium@dp-frame-dump:
- shard-glk:  NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-glk1/igt@kms_chamel...@dp-frame-dump.html
- shard-skl:  NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +2 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-skl4/igt@kms_chamel...@dp-frame-dump.html

  * igt@kms_color@pipe-b-ctm-negative:
- shard-skl:  NOTRUN -> [DMESG-WARN][9] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-skl4/igt@kms_co...@pipe-b-ctm-negative.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x128-random:
- shard-skl:  NOTRUN -> [FAIL][10] ([i915#54]) +1 similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-128x128-random.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x42-random:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#54]) +4 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html

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

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl:  NOTRUN -> [FAIL][15] ([i915#2346])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-skl8/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

  * igt@kms_cursor_legacy@flip-vs-cursor-legacy:
- shard-skl:  [PASS][16] -> [FAIL][17] ([i915#2346])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-skl9/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-hdmi-a1:
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#79])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-glk7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-glk2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a1.html

  * igt@kms_flip@plain-flip-ts-check-interruptible@a-edp1:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#2122])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9554/shard-skl9/igt@kms_flip@plain-flip-ts-check-interrupti...@a-edp1.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-skl2/igt@kms_flip@plain-flip-ts-check-interrupti...@a-edp1.html

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt:
- shard-skl:  NOTRUN -> [SKIP][22] ([fdo#109271]) +40 similar issues
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19274/shard-skl4/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-indfb-draw-blt.html

  * 

Re: [Intel-gfx] [PULL] topic/dp-hdmi-2.1-pcon for drm-misc-next

2021-01-07 Thread Daniel Vetter
On Wed, Dec 23, 2020 at 10:14:58AM +0200, Jani Nikula wrote:
> 
> Hi Maarten, Maxime, and Thomas -
> 
> Here's the DP-HDMI2.1 PCON support topic pull consisting of the series
> [1]. The series is split roughly 50-50 between drm helpers and i915, so
> a topic branch seemed to be the right way to go.
> 
> I'll also pull this to drm-intel-next once you've merged to
> drm-misc-next.

I didn't see this merged into drm-misc-next, so pulled into drm-next. I'm
processing an entire batch of pulls, I'll ping you on irc when it's all
ready for backmerging.

Cheers, Daniel

> 
> BR,
> Jani.
> 
> 
> [1] https://patchwork.freedesktop.org/series/82098/
> 
> 
> topic/dp-hdmi-2.1-pcon-2020-12-23:
> Add support for DP-HDMI2.1 PCON
> 
> From the series cover letter:
> 
> This patch series attempts to add support for a DP-HDMI2.1 Protocol
> Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
> E5 to DisplayPort_v2.0:
> https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299
> The details are mentioned in:
> VESA DP-to-HDMI PCON Specification Standalone Document
> https://groups.vesa.org/wg/DP/document/15651
> 
> This series starts with adding support for FRL (Fixed Rate Link)
> Training between the PCON and HDMI2.1 sink.
> As per HDMI2.1 specification, a new data-channel or lane is added in
> FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher
> bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4
> lanes).
> 
> With these patches, the HDMI2.1 PCON can be configured to achieve FRL
> training based on the maximum FRL rate supported by the panel, source
> and the PCON.
> The approach is to add the support for FRL training between PCON and
> HDMI2.1 sink and gradually add other blocks for supporting higher
> resolutions and other HDMI2.1 features, that can be supported by pcon
> for the sources that do not natively support HDMI2.1.
> 
> This is done before the DP Link training between the source and PCON
> is started. In case of FRL training is not achieved, the PCON will
> work in the regular TMDS mode, without HDMI2.1 feature support.
> Any interruption in FRL training between the PCON and HDMI2.1 sink is
> notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD
> registers are read and FRL training is re-attempted.
> 
> Currently, we have tested the FRL training and are able to enable 4K
> display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting
> panel.
> 
> The following changes since commit b3bf99daaee96a141536ce5c60a0d6dba6ec1d23:
> 
>   drm/i915/display: Defer initial modeset until after GGTT is initialised 
> (2020-11-26 11:01:52 +)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel 
> tags/topic/dp-hdmi-2.1-pcon-2020-12-23
> 
> for you to fetch changes up to 522508b665df3bbfdf40381d4e61777844b1703f:
> 
>   drm/i915/display: Let PCON convert from RGB to YCbCr if it can (2020-12-22 
> 17:59:07 +0200)
> 
> 
> Add support for DP-HDMI2.1 PCON
> 
> From the series cover letter:
> 
> This patch series attempts to add support for a DP-HDMI2.1 Protocol
> Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
> E5 to DisplayPort_v2.0:
> https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299
> The details are mentioned in:
> VESA DP-to-HDMI PCON Specification Standalone Document
> https://groups.vesa.org/wg/DP/document/15651
> 
> This series starts with adding support for FRL (Fixed Rate Link)
> Training between the PCON and HDMI2.1 sink.
> As per HDMI2.1 specification, a new data-channel or lane is added in
> FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher
> bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4
> lanes).
> 
> With these patches, the HDMI2.1 PCON can be configured to achieve FRL
> training based on the maximum FRL rate supported by the panel, source
> and the PCON.
> The approach is to add the support for FRL training between PCON and
> HDMI2.1 sink and gradually add other blocks for supporting higher
> resolutions and other HDMI2.1 features, that can be supported by pcon
> for the sources that do not natively support HDMI2.1.
> 
> This is done before the DP Link training between the source and PCON
> is started. In case of FRL training is not achieved, the PCON will
> work in the regular TMDS mode, without HDMI2.1 feature support.
> Any interruption in FRL training between the PCON and HDMI2.1 sink is
> notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD
> registers are read and FRL training is re-attempted.
> 
> Currently, we have tested the FRL training and are able to enable 4K
> display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting
> panel.
> 
> 
> Ankit Nautiyal (11):
>   drm/edid: Parse DSC1.2 cap fields from HFVSDB block
>   

Re: [Intel-gfx] [PULL] drm-misc-next

2021-01-07 Thread Daniel Vetter
On Thu, Dec 17, 2020 at 11:12 AM Maarten Lankhorst
 wrote:
>
> drm-misc-next-2020-12-17:
> drm-misc-next for v5.12:
>
> UAPI Changes:
> - Not necessarily one, but we document that userspace needs to force probe 
> connectors.
>
> Cross-subsystem Changes:
> - Require FB_ATY_CT for aty on sparc64.
> - video: Fix documentation, and a few compiler warnings.
> - Add devicetree bindings for DP connectors.
> - dma-buf: Update kernel-doc, and add might_lock for resv objects in 
> begin/end_cpu_access.
>
> Core Changes:
> - ttm: Warn when releasing a pinned bo.
> - ttm: Cleanup bo size handling.
> - cma-helper: Remove prime infix, and implement mmap as GEM CMA functions.
> - Split drm_prime_sg_to_page_addr_arrays into 2 functions.
> - Add a new api to install irq using devm.
> - Update panel kerneldoc to inline style.
> - Add DP support to drm/bridge.
> - Assorted small fixes to ttm, fb-helper, scheduler.
> - Add atomic_commit_setup function callback.
> - Automatically use the atomic gamma_set, instead of forcing drivers to 
> declare the default atomic version.
> - Allow using degamma for legacy gamma if gamma is not available.
> - Clarify that primary/cursor planes are not tied to 1 crtc (depending on 
> possible_crtcs).
> - ttm: Cleanup the lru handler.
>
> Driver Changes:
> - Add pm support to ingenic.
> - Assorted small fixes in radeon, via, rockchip, omap2fb, kmb, gma500, 
> nouveau, virtio, hisilicon, ingenic, s6e63m0 panel, ast, udlfb.
> - Add BOE NV110WTM-N61, ys57pss36bh5gq, Khadas TS050 panels.
> - Stop using pages with drm_prime_sg_to_page_addr_arrays, and switch all 
> callers to use ttm_sg_tt_init.
> - Cleanup compiler and docbook warnings in a lot of fbdev devices.
> - Use the drmm_vram_helper in hisilicon.
> - Add support for BCM2711 DSI1 in vc4.
> - Add support for 8-bit delta RGB panels to ingenic.
> - Add documentation on how to test vkms.
> - Convert vc4 to atomic helpers.
> - Use degamma instead of gamma table in omap, to add support for CTM and 
> color encoding/range properties.
> - Rework omap DSI code, and merge all omapdrm modules now that the last omap 
> panel is now a drm panel.
> - More refactoring of omap dsi code.
> - Enable 10/12 bpc outputs in vc4.
> The following changes since commit 5fbd41d3bf123af6a135bdea564087ec0f563eb0:
>
>   Merge tag 'drm-misc-next-2020-11-27-1' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2020-12-15 10:21:48 
> +0100)

Pulled, thanks.
-Daniel

>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-12-17
>
> for you to fetch changes up to c545781e1c55ab680dcc49c37212d5327b9d6812:
>
>   dma-buf: doc polish for pin/unpin (2020-12-16 11:28:34 +0100)
>
> 
> drm-misc-next for v5.12:
>
> UAPI Changes:
> - Not necessarily one, but we document that userspace needs to force probe 
> connectors.
>
> Cross-subsystem Changes:
> - Require FB_ATY_CT for aty on sparc64.
> - video: Fix documentation, and a few compiler warnings.
> - Add devicetree bindings for DP connectors.
> - dma-buf: Update kernel-doc, and add might_lock for resv objects in 
> begin/end_cpu_access.
>
> Core Changes:
> - ttm: Warn when releasing a pinned bo.
> - ttm: Cleanup bo size handling.
> - cma-helper: Remove prime infix, and implement mmap as GEM CMA functions.
> - Split drm_prime_sg_to_page_addr_arrays into 2 functions.
> - Add a new api to install irq using devm.
> - Update panel kerneldoc to inline style.
> - Add DP support to drm/bridge.
> - Assorted small fixes to ttm, fb-helper, scheduler.
> - Add atomic_commit_setup function callback.
> - Automatically use the atomic gamma_set, instead of forcing drivers to 
> declare the default atomic version.
> - Allow using degamma for legacy gamma if gamma is not available.
> - Clarify that primary/cursor planes are not tied to 1 crtc (depending on 
> possible_crtcs).
> - ttm: Cleanup the lru handler.
>
> Driver Changes:
> - Add pm support to ingenic.
> - Assorted small fixes in radeon, via, rockchip, omap2fb, kmb, gma500, 
> nouveau, virtio, hisilicon, ingenic, s6e63m0 panel, ast, udlfb.
> - Add BOE NV110WTM-N61, ys57pss36bh5gq, Khadas TS050 panels.
> - Stop using pages with drm_prime_sg_to_page_addr_arrays, and switch all 
> callers to use ttm_sg_tt_init.
> - Cleanup compiler and docbook warnings in a lot of fbdev devices.
> - Use the drmm_vram_helper in hisilicon.
> - Add support for BCM2711 DSI1 in vc4.
> - Add support for 8-bit delta RGB panels to ingenic.
> - Add documentation on how to test vkms.
> - Convert vc4 to atomic helpers.
> - Use degamma instead of gamma table in omap, to add support for CTM and 
> color encoding/range properties.
> - Rework omap DSI code, and merge all omapdrm modules now that the last omap 
> panel is now a drm panel.
> - More refactoring of omap dsi code.
> - Enable 10/12 bpc outputs in vc4.
>
> 
> Arnd 

Re: [Intel-gfx] [PATCH i-g-t v2] runner: Don't kill a test on taint if watching timeouts

2021-01-07 Thread Chris Wilson
Quoting Petri Latvala (2021-01-07 09:40:02)
> On Wed, Jan 06, 2021 at 09:41:37AM +, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2020-12-04 19:50:07)
> > > We may still be interested in results of a test even if it has tainted
> > > the kernel.  On the other hand, we need to kill the test on taint if no
> > > other means of killing it on a jam is active.
> > > 
> > > If abort on both kernel taint or a timeout is requested, decrease all
> > > potential timeouts significantly while the taint is detected instead of
> > > aborting immediately.  However, report the taint as the reason of the
> > > abort if a timeout decreased by the taint expires.
> > 
> > This has the nasty side effect of not stopping the test run after a
> > kernel taint. Instead the next test inherits the tainted condition from
> > the previous test and usually ends up being declared incomplete.
> > 
> > False positives are frustrating.
> > -Chris
> 
> 
> Do you have a link to a test run where this happened? This patch
> didn't change the between-tests abort checks.

The taint is from the warnings in the penultimate test:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9550/shard-skl7/igt_runner20.txt
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v3 8/8] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev

2021-01-07 Thread kernel test robot
Hi Thomas,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next linus/master v5.11-rc2 next-20210104]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: microblaze-randconfig-r013-20210107 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/380912f7b62c23322562c40e19efd7ad84d57e9c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007
git checkout 380912f7b62c23322562c40e19efd7ad84d57e9c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=microblaze 

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

All errors (new ones prefixed by >>):

   drivers/gpu/drm/virtio/virtgpu_drv.c: In function 'virtio_gpu_pci_quirk':
>> drivers/gpu/drm/virtio/virtgpu_drv.c:57:7: error: 'struct drm_device' has no 
>> member named 'pdev'; did you mean 'dev'?
  57 |  dev->pdev = pdev;
 |   ^~~~
 |   dev


vim +57 drivers/gpu/drm/virtio/virtgpu_drv.c

dc5698e80cf724 Dave Airlie 2013-09-09  46  
d516e75c71c985 Ezequiel Garcia 2019-01-08  47  static int 
virtio_gpu_pci_quirk(struct drm_device *dev, struct virtio_device *vdev)
d516e75c71c985 Ezequiel Garcia 2019-01-08  48  {
d516e75c71c985 Ezequiel Garcia 2019-01-08  49   struct pci_dev *pdev = 
to_pci_dev(vdev->dev.parent);
d516e75c71c985 Ezequiel Garcia 2019-01-08  50   const char *pname = 
dev_name(>dev);
d516e75c71c985 Ezequiel Garcia 2019-01-08  51   bool vga = (pdev->class >> 8) 
== PCI_CLASS_DISPLAY_VGA;
d516e75c71c985 Ezequiel Garcia 2019-01-08  52   char unique[20];
d516e75c71c985 Ezequiel Garcia 2019-01-08  53  
d516e75c71c985 Ezequiel Garcia 2019-01-08  54   DRM_INFO("pci: %s detected at 
%s\n",
d516e75c71c985 Ezequiel Garcia 2019-01-08  55vga ? "virtio-vga" : 
"virtio-gpu-pci",
d516e75c71c985 Ezequiel Garcia 2019-01-08  56pname);
d516e75c71c985 Ezequiel Garcia 2019-01-08 @57   dev->pdev = pdev;
d516e75c71c985 Ezequiel Garcia 2019-01-08  58   if (vga)
d516e75c71c985 Ezequiel Garcia 2019-01-08  59   
drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
d516e75c71c985 Ezequiel Garcia 2019-01-08  60   
  "virtiodrmfb");
d516e75c71c985 Ezequiel Garcia 2019-01-08  61  
d516e75c71c985 Ezequiel Garcia 2019-01-08  62   /*
d516e75c71c985 Ezequiel Garcia 2019-01-08  63* Normally the 
drm_dev_set_unique() call is done by core DRM.
d516e75c71c985 Ezequiel Garcia 2019-01-08  64* The following comment 
covers, why virtio cannot rely on it.
d516e75c71c985 Ezequiel Garcia 2019-01-08  65*
d516e75c71c985 Ezequiel Garcia 2019-01-08  66* Unlike the other virtual GPU 
drivers, virtio abstracts the
d516e75c71c985 Ezequiel Garcia 2019-01-08  67* underlying bus type by using 
struct virtio_device.
d516e75c71c985 Ezequiel Garcia 2019-01-08  68*
d516e75c71c985 Ezequiel Garcia 2019-01-08  69* Hence the dev_is_pci() 
check, used in core DRM, will fail
d516e75c71c985 Ezequiel Garcia 2019-01-08  70* and the unique returned will 
be the virtio_device "virtio0",
d516e75c71c985 Ezequiel Garcia 2019-01-08  71* while a "pci:..." one is 
required.
d516e75c71c985 Ezequiel Garcia 2019-01-08  72*
d516e75c71c985 Ezequiel Garcia 2019-01-08  73* A few other ideas were 
considered:
d516e75c71c985 Ezequiel Garcia 2019-01-08  74* - Extend the dev_is_pci() 
check [in drm_set_busid] to
d516e75c71c985 Ezequiel Garcia 2019-01-08  75*   consider virtio.
d516e75c71c985 Ezequiel Garcia 2019-01-08  76*   Seems like a bigger hack 
than what we have already.
d516e75c71c985 Ezequiel Garcia 2019-01-08  77*
d516e75c71c985 Ezequiel Garcia 2019-01-08  78* - Point drm_device::dev to 
the parent of the virtio_device
d516e75c71c985 Ezequiel Garcia 2019-01-08  79*   Semantic changes:
d516e75c71c985 Ezequiel Garcia 2019-01-08  80*   * Using the wrong device 
for i2c, framebuffer_alloc and
d516e75c71c985 Ezequiel Garcia 2019-01-08  81* prime import.
d516e75c71c985 Ezequiel Garcia 2019-01-08  82*   Visual changes:
d516e75c71c985 Ezequiel G

Re: [Intel-gfx] [PATCH v3 8/8] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev

2021-01-07 Thread kernel test robot
Hi Thomas,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next linus/master v5.11-rc2 next-20210104]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-s021-20210107 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-208-g46a52ca4-dirty
# 
https://github.com/0day-ci/linux/commit/380912f7b62c23322562c40e19efd7ad84d57e9c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007
git checkout 380912f7b62c23322562c40e19efd7ad84d57e9c
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 

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

All errors (new ones prefixed by >>):

   drivers/gpu/drm/gma500/oaktrail_device.c: In function 'oaktrail_chip_setup':
>> drivers/gpu/drm/gma500/oaktrail_device.c:509:26: error: 'struct drm_device' 
>> has no member named 'pdev'; did you mean 'dev'?
 509 |  if (pci_enable_msi(dev->pdev))
 |  ^~~~
 |  dev
--
   drivers/gpu/drm/gma500/oaktrail_lvds.c: In function 
'oaktrail_lvds_set_power':
>> drivers/gpu/drm/gma500/oaktrail_lvds.c:63:25: error: 'struct drm_device' has 
>> no member named 'pdev'; did you mean 'dev'?
  63 |   pm_request_idle(>pdev->dev);
 | ^~~~
 | dev
--
   drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_clock':
   drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:69:11: warning: variable 'tmp' 
set but not used [-Wunused-but-set-variable]
  69 |  u32 val, tmp;
 |   ^~~
   drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_data':
   drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:83:11: warning: variable 'tmp' 
set but not used [-Wunused-but-set-variable]
  83 |  u32 val, tmp;
 |   ^~~
   drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 
'oaktrail_lvds_i2c_init':
>> drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:148:35: error: 'struct 
>> drm_device' has no member named 'pdev'; did you mean 'dev'?
 148 |  chan->adapter.dev.parent = >pdev->dev;
 |   ^~~~
 |   dev
--
   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function 'vmw_driver_load':
>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:661:22: error: 'struct drm_device' has 
>> no member named 'pdev'; did you mean 'dev'?
 661 |  pci_set_master(dev->pdev);
 |  ^~~~
 |  dev
   In file included from drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:31:
   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:690:47: error: 'struct drm_device' has 
no member named 'pdev'; did you mean 'dev'?
 690 |  dev_priv->io_start = pci_resource_start(dev->pdev, 0);
 |   ^~~~
   include/linux/pci.h:1854:40: note: in definition of macro 
'pci_resource_start'
1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start)
 |^~~
   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:691:49: error: 'struct drm_device' has 
no member named 'pdev'; did you mean 'dev'?
 691 |  dev_priv->vram_start = pci_resource_start(dev->pdev, 1);
 | ^~~~
   include/linux/pci.h:1854:40: note: in definition of macro 
'pci_resource_start'
1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start)
 |^~~
   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:692:49: error: 'struct drm_device' has 
no member named 'pdev'; did you mean 'dev'?
 692 |  dev_priv->mmio_start = pci_resource_start(dev->pdev, 2);
 | ^~~~
   include/linux/pci.h:1854:40: note: in definition of macro 
'pci_resource_start'
1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start)
 |^~~
   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:842:33: error: 'struct drm_device' has 
no member named 'pdev'; did you mean 'dev'?
 842 |  ret = pci_request_regions(dev->pdev, "vmwgfx probe");
 

Re: [Intel-gfx] [PATCH i-g-t v2] runner: Don't kill a test on taint if watching timeouts

2021-01-07 Thread Petri Latvala
On Wed, Jan 06, 2021 at 09:41:37AM +, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-12-04 19:50:07)
> > We may still be interested in results of a test even if it has tainted
> > the kernel.  On the other hand, we need to kill the test on taint if no
> > other means of killing it on a jam is active.
> > 
> > If abort on both kernel taint or a timeout is requested, decrease all
> > potential timeouts significantly while the taint is detected instead of
> > aborting immediately.  However, report the taint as the reason of the
> > abort if a timeout decreased by the taint expires.
> 
> This has the nasty side effect of not stopping the test run after a
> kernel taint. Instead the next test inherits the tainted condition from
> the previous test and usually ends up being declared incomplete.
> 
> False positives are frustrating.
> -Chris


Do you have a link to a test run where this happened? This patch
didn't change the between-tests abort checks.


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


Re: [Intel-gfx] [PULL] drm-intel-fixes

2021-01-07 Thread Daniel Vetter
On Thu, Jan 07, 2021 at 09:50:28AM +0200, Jani Nikula wrote:
> 
> Hi Dave & Daniel -
> 
> Pretty quiet still, but here's some cc: stable fixes.

Pulled, thanks.
-Daniel

> 
> (Well, one doesn't have the explicit stable tag, but the Fixes tag
> points at a commit in v3.9...)
> 
> drm-intel-fixes-2021-01-07:
> drm/i915 fixes for v5.11-rc3:
> - Use per-connector PM QoS tracking for DP aux communication
> - GuC firmware fix for older Cometlakes
> - Clear the gpu reloc and shadow batches
> 
> BR,
> Jani.
> 
> The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:
> 
>   Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-01-07
> 
> for you to fetch changes up to 9397d66212cdf7a21c66523f1583e5d63a609e84:
> 
>   drm/i915/dp: Track pm_qos per connector (2021-01-05 10:25:03 +0200)
> 
> 
> drm/i915 fixes for v5.11-rc3:
> - Use per-connector PM QoS tracking for DP aux communication
> - GuC firmware fix for older Cometlakes
> - Clear the gpu reloc and shadow batches
> 
> 
> Chris Wilson (2):
>   drm/i915/gt: Define guc firmware blob for older Cometlakes
>   drm/i915/dp: Track pm_qos per connector
> 
> Matthew Auld (2):
>   drm/i915: clear the shadow batch
>   drm/i915: clear the gpu reloc batch
> 
>  drivers/gpu/drm/i915/display/intel_display_types.h |  3 +++
>  drivers/gpu/drm/i915/display/intel_dp.c|  8 +--
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  4 +++-
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c   |  1 +
>  drivers/gpu/drm/i915/i915_cmd_parser.c | 27 
> --
>  drivers/gpu/drm/i915/i915_drv.c|  5 
>  drivers/gpu/drm/i915/i915_drv.h|  3 ---
>  7 files changed, 22 insertions(+), 29 deletions(-)
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

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


Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Wrap our timer_list.expires checking

2021-01-07 Thread Tvrtko Ursulin



On 06/01/2021 16:36, Chris Wilson wrote:

Refactor our timer_list.expires checking into its own timer_active()
helper.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_utils.c | 2 +-
  drivers/gpu/drm/i915/i915_utils.h | 7 ++-
  2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.c 
b/drivers/gpu/drm/i915/i915_utils.c
index 4c305d838016..f9e780dee9de 100644
--- a/drivers/gpu/drm/i915/i915_utils.c
+++ b/drivers/gpu/drm/i915/i915_utils.c
@@ -87,7 +87,7 @@ bool i915_error_injected(void)
  
  void cancel_timer(struct timer_list *t)

  {
-   if (!READ_ONCE(t->expires))
+   if (!timer_active(t))
return;
  
  	del_timer(t);

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 54773371e6bd..abd4dcd9f79c 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -438,9 +438,14 @@ static inline void __add_taint_for_CI(unsigned int taint)
  void cancel_timer(struct timer_list *t);
  void set_timer_ms(struct timer_list *t, unsigned long timeout);
  
+static inline bool timer_active(const struct timer_list *t)

+{
+   return READ_ONCE(t->expires);
+}
+
  static inline bool timer_expired(const struct timer_list *t)
  {
-   return READ_ONCE(t->expires) && !timer_pending(t);
+   return timer_active(t) && !timer_pending(t);
  }
  
  /*




Don't know really, it's a bit dodgy to prefix with generic timer_ when 
semantics are i915 specific and apply only to timers managed with our 
set_timer_ms().


Have it for now and perhaps we can revisit to tidy later.

Reviewed-by: Tvrtko Ursulin 

Regards,

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


[Intel-gfx] [PATCH v3 6/8] drm/i915/gvt: Remove references to struct drm_device.pdev

2021-01-07 Thread Thomas Zimmermann
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/gvt/cfg_space.c |  5 +++--
 drivers/gpu/drm/i915/gvt/firmware.c  | 10 +-
 drivers/gpu/drm/i915/gvt/gtt.c   | 12 ++--
 drivers/gpu/drm/i915/gvt/gvt.c   |  6 +++---
 drivers/gpu/drm/i915/gvt/kvmgt.c |  4 ++--
 5 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c 
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index ad86c5eb5bba..b490e3db2e38 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -374,6 +374,7 @@ void intel_vgpu_init_cfg_space(struct intel_vgpu *vgpu,
   bool primary)
 {
struct intel_gvt *gvt = vgpu->gvt;
+   struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
const struct intel_gvt_device_info *info = >device_info;
u16 *gmch_ctl;
u8 next;
@@ -407,9 +408,9 @@ void intel_vgpu_init_cfg_space(struct intel_vgpu *vgpu,
memset(vgpu_cfg_space(vgpu) + INTEL_GVT_PCI_OPREGION, 0, 4);
 
vgpu->cfg_space.bar[INTEL_GVT_PCI_BAR_GTTMMIO].size =
-   pci_resource_len(gvt->gt->i915->drm.pdev, 0);
+   pci_resource_len(pdev, 0);
vgpu->cfg_space.bar[INTEL_GVT_PCI_BAR_APERTURE].size =
-   pci_resource_len(gvt->gt->i915->drm.pdev, 2);
+   pci_resource_len(pdev, 2);
 
memset(vgpu_cfg_space(vgpu) + PCI_ROM_ADDRESS, 0, 4);
 
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index 990a181094e3..1a8274a3f4b1 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -76,7 +76,7 @@ static int mmio_snapshot_handler(struct intel_gvt *gvt, u32 
offset, void *data)
 static int expose_firmware_sysfs(struct intel_gvt *gvt)
 {
struct intel_gvt_device_info *info = >device_info;
-   struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
struct gvt_firmware_header *h;
void *firmware;
void *p;
@@ -127,7 +127,7 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt)
 
 static void clean_firmware_sysfs(struct intel_gvt *gvt)
 {
-   struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
 
device_remove_bin_file(>dev, _attr);
vfree(firmware_attr.private);
@@ -151,7 +151,7 @@ static int verify_firmware(struct intel_gvt *gvt,
   const struct firmware *fw)
 {
struct intel_gvt_device_info *info = >device_info;
-   struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
struct gvt_firmware_header *h;
unsigned long id, crc32_start;
const void *mem;
@@ -205,7 +205,7 @@ static int verify_firmware(struct intel_gvt *gvt,
 int intel_gvt_load_firmware(struct intel_gvt *gvt)
 {
struct intel_gvt_device_info *info = >device_info;
-   struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
struct intel_gvt_firmware *firmware = >firmware;
struct gvt_firmware_header *h;
const struct firmware *fw;
@@ -240,7 +240,7 @@ int intel_gvt_load_firmware(struct intel_gvt *gvt)
 
gvt_dbg_core("request hw state firmware %s...\n", path);
 
-   ret = request_firmware(, path, >gt->i915->drm.pdev->dev);
+   ret = request_firmware(, path, gvt->gt->i915->drm.dev);
kfree(path);
 
if (ret)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 897c007ea96a..6d12a5a401f6 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -746,7 +746,7 @@ static int detach_oos_page(struct intel_vgpu *vgpu,
 
 static void ppgtt_free_spt(struct intel_vgpu_ppgtt_spt *spt)
 {
-   struct device *kdev = >vgpu->gvt->gt->i915->drm.pdev->dev;
+   struct device *kdev = spt->vgpu->gvt->gt->i915->drm.dev;
 
trace_spt_free(spt->vgpu->id, spt, spt->guest_page.type);
 
@@ -831,7 +831,7 @@ static int reclaim_one_ppgtt_mm(struct intel_gvt *gvt);
 static struct intel_vgpu_ppgtt_spt *ppgtt_alloc_spt(
struct intel_vgpu *vgpu, enum intel_gvt_gtt_type type)
 {
-   struct device *kdev = >gvt->gt->i915->drm.pdev->dev;
+   struct device *kdev = vgpu->gvt->gt->i915->drm.dev;
struct intel_vgpu_ppgtt_spt *spt = NULL;
dma_addr_t daddr;
int ret;
@@ -2402,7 +2402,7 @@ static int alloc_scratch_pages(struct intel_vgpu *vgpu,
vgpu->gvt->device_info.gtt_entry_size_shift;
void *scratch_pt;
int i;
-   struct device *dev = >gvt->gt->i915->drm.pdev->dev;
+   struct device *dev = 

[Intel-gfx] [PATCH v3 8/8] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev

2021-01-07 Thread Thomas Zimmermann
We have DRM drivers based on USB, SPI and platform devices. All of them
are fine with storing their device reference in struct drm_device.dev.
PCI devices should be no exception. Therefore struct drm_device.pdev is
deprecated.

Instead upcast from struct drm_device.dev with to_pci_dev(). PCI-specific
code can use dev_is_pci() to test for a PCI device. This patch changes
the DRM core code and documentation accordingly. Struct drm_device.pdev
is being moved to legacy status.

Signed-off-by: Thomas Zimmermann 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/drm_agpsupport.c |  9 ++---
 drivers/gpu/drm/drm_bufs.c   |  4 ++--
 drivers/gpu/drm/drm_edid.c   |  7 ++-
 drivers/gpu/drm/drm_irq.c| 12 +++-
 drivers/gpu/drm/drm_pci.c| 26 +++---
 drivers/gpu/drm/drm_vm.c |  2 +-
 include/drm/drm_device.h | 12 +---
 7 files changed, 46 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 4c7ad46fdd21..a4040fe4f4ba 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -103,11 +103,13 @@ int drm_agp_info_ioctl(struct drm_device *dev, void *data,
  */
 int drm_agp_acquire(struct drm_device *dev)
 {
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
+
if (!dev->agp)
return -ENODEV;
if (dev->agp->acquired)
return -EBUSY;
-   dev->agp->bridge = agp_backend_acquire(dev->pdev);
+   dev->agp->bridge = agp_backend_acquire(pdev);
if (!dev->agp->bridge)
return -ENODEV;
dev->agp->acquired = 1;
@@ -402,14 +404,15 @@ int drm_agp_free_ioctl(struct drm_device *dev, void *data,
  */
 struct drm_agp_head *drm_agp_init(struct drm_device *dev)
 {
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
struct drm_agp_head *head = NULL;
 
head = kzalloc(sizeof(*head), GFP_KERNEL);
if (!head)
return NULL;
-   head->bridge = agp_find_bridge(dev->pdev);
+   head->bridge = agp_find_bridge(pdev);
if (!head->bridge) {
-   head->bridge = agp_backend_acquire(dev->pdev);
+   head->bridge = agp_backend_acquire(pdev);
if (!head->bridge) {
kfree(head);
return NULL;
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index aeb1327e3077..e3d77dfefb0a 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -326,7 +326,7 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
 * As we're limiting the address to 2^32-1 (or less),
 * casting it down to 32 bits is no problem, but we
 * need to point to a 64bit variable first. */
-   map->handle = dma_alloc_coherent(>pdev->dev,
+   map->handle = dma_alloc_coherent(dev->dev,
 map->size,
 >offset,
 GFP_KERNEL);
@@ -556,7 +556,7 @@ int drm_legacy_rmmap_locked(struct drm_device *dev, struct 
drm_local_map *map)
case _DRM_SCATTER_GATHER:
break;
case _DRM_CONSISTENT:
-   dma_free_coherent(>pdev->dev,
+   dma_free_coherent(dev->dev,
  map->size,
  map->handle,
  map->offset);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 394cc55b3214..c2bbe7bee7b6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -2075,9 +2076,13 @@ EXPORT_SYMBOL(drm_get_edid);
 struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
 struct i2c_adapter *adapter)
 {
-   struct pci_dev *pdev = connector->dev->pdev;
+   struct drm_device *dev = connector->dev;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
struct edid *edid;
 
+   if (drm_WARN_ON_ONCE(dev, !dev_is_pci(dev->dev)))
+   return NULL;
+
vga_switcheroo_lock_ddc(pdev);
edid = drm_get_edid(connector, adapter);
vga_switcheroo_unlock_ddc(pdev);
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 803af4bbd214..c3bd664ea733 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -122,7 +122,7 @@ int drm_irq_install(struct drm_device *dev, int irq)
dev->driver->irq_preinstall(dev);
 
/* PCI devices require shared interrupts. */
-   if (dev->pdev)
+   if (dev_is_pci(dev->dev))
sh_flags = IRQF_SHARED;
 
ret = request_irq(irq, dev->driver->irq_handler,
@@ -140,7 +140,7 @@ int drm_irq_install(struct drm_device *dev, int irq)
if 

[Intel-gfx] [PATCH v3 7/8] drm/nouveau: Remove references to struct drm_device.pdev

2021-01-07 Thread Thomas Zimmermann
Using struct drm_device.pdev is deprecated. Convert nouveau to struct
drm_device.dev. No functional changes.

v3:
* fix nv04_dfp_update_backlight() as well (Jeremy)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jeremy Cline 
Cc: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/dispnv04/arb.c  | 12 +++-
 drivers/gpu/drm/nouveau/dispnv04/dfp.c  |  5 +++--
 drivers/gpu/drm/nouveau/dispnv04/disp.h | 14 --
 drivers/gpu/drm/nouveau/dispnv04/hw.c   | 10 ++
 drivers/gpu/drm/nouveau/nouveau_abi16.c |  7 ---
 drivers/gpu/drm/nouveau/nouveau_acpi.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_bios.c  | 11 ---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 10 ++
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  5 ++---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |  6 --
 drivers/gpu/drm/nouveau/nouveau_vga.c   | 20 
 11 files changed, 61 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c 
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 9d4a2d97507e..1d3542d6006b 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -200,16 +200,17 @@ nv04_update_arb(struct drm_device *dev, int VClk, int bpp,
int MClk = nouveau_hw_get_clock(dev, PLL_MEMORY);
int NVClk = nouveau_hw_get_clock(dev, PLL_CORE);
uint32_t cfg1 = nvif_rd32(device, NV04_PFB_CFG1);
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
 
sim_data.pclk_khz = VClk;
sim_data.mclk_khz = MClk;
sim_data.nvclk_khz = NVClk;
sim_data.bpp = bpp;
sim_data.two_heads = nv_two_heads(dev);
-   if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
-   (dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
+   if ((pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
+   (pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
-   int domain = pci_domain_nr(dev->pdev->bus);
+   int domain = pci_domain_nr(pdev->bus);
 
pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
  0x7c, );
@@ -251,11 +252,12 @@ void
 nouveau_calc_arb(struct drm_device *dev, int vclk, int bpp, int *burst, int 
*lwm)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
 
if (drm->client.device.info.family < NV_DEVICE_INFO_V0_KELVIN)
nv04_update_arb(dev, vclk, bpp, burst, lwm);
-   else if ((dev->pdev->device & 0xfff0) == 0x0240 /*CHIPSET_C51*/ ||
-(dev->pdev->device & 0xfff0) == 0x03d0 /*CHIPSET_C512*/) {
+   else if ((pdev->device & 0xfff0) == 0x0240 /*CHIPSET_C51*/ ||
+(pdev->device & 0xfff0) == 0x03d0 /*CHIPSET_C512*/) {
*burst = 128;
*lwm = 0x0480;
} else
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c 
b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index 42687ea2a4ca..ce3d8c6ef000 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -488,12 +488,13 @@ static void nv04_dfp_update_backlight(struct drm_encoder 
*encoder, int mode)
 #ifdef __powerpc__
struct drm_device *dev = encoder->dev;
struct nvif_object *device = _drm(dev)->client.device.object;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
 
/* BIOS scripts usually take care of the backlight, thanks
 * Apple for your consistency.
 */
-   if (dev->pdev->device == 0x0174 || dev->pdev->device == 0x0179 ||
-   dev->pdev->device == 0x0189 || dev->pdev->device == 0x0329) {
+   if (pdev->device == 0x0174 || pdev->device == 0x0179 ||
+   pdev->device == 0x0189 || pdev->device == 0x0329) {
if (mode == DRM_MODE_DPMS_ON) {
nvif_mask(device, NV_PBUS_DEBUG_DUALHEAD_CTL, 1 << 31, 
1 << 31);
nvif_mask(device, NV_PCRTC_GPIO_EXT, 3, 1);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.h 
b/drivers/gpu/drm/nouveau/dispnv04/disp.h
index 5ace5e906949..f0a24126641a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.h
@@ -130,7 +130,7 @@ static inline bool
 nv_two_heads(struct drm_device *dev)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
-   const int impl = dev->pdev->device & 0x0ff0;
+   const int impl = to_pci_dev(dev->dev)->device & 0x0ff0;
 
if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_CELSIUS && impl 
!= 0x0100 &&
impl != 0x0150 && impl != 0x01a0 && impl != 0x0200)
@@ -142,14 +142,14 @@ nv_two_heads(struct drm_device *dev)
 static inline bool
 nv_gf4_disp_arch(struct drm_device *dev)
 {
-   return nv_two_heads(dev) && (dev->pdev->device & 0x0ff0) != 0x0110;
+   return nv_two_heads(dev) && (to_pci_dev(dev->dev)->device & 0x0ff0) != 

[Intel-gfx] [PATCH v3 5/8] drm/i915/gt: Remove references to struct drm_device.pdev

2021-01-07 Thread Thomas Zimmermann
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 10 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_rc6.c   |  4 ++--
 drivers/gpu/drm/i915/gt/intel_reset.c |  6 +++---
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1847d3c2ea99..a1e872ecc3f1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1252,7 +1252,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
 
/* Waiting to drain ELSP? */
if (execlists_active(>execlists)) {
-   synchronize_hardirq(engine->i915->drm.pdev->irq);
+   synchronize_hardirq(to_pci_dev(engine->i915->drm.dev)->irq);
 
intel_engine_flush_submission(engine);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index eece0844fbe9..fd6c8fa54812 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -769,7 +769,7 @@ static unsigned int chv_get_total_gtt_size(u16 gmch_ctrl)
 static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
 {
struct drm_i915_private *i915 = ggtt->vm.i915;
-   struct pci_dev *pdev = i915->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
phys_addr_t phys_addr;
int ret;
 
@@ -839,7 +839,7 @@ static struct resource pci_resource(struct pci_dev *pdev, 
int bar)
 static int gen8_gmch_probe(struct i915_ggtt *ggtt)
 {
struct drm_i915_private *i915 = ggtt->vm.i915;
-   struct pci_dev *pdev = i915->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
unsigned int size;
u16 snb_gmch_ctl;
 
@@ -983,7 +983,7 @@ static u64 iris_pte_encode(dma_addr_t addr,
 static int gen6_gmch_probe(struct i915_ggtt *ggtt)
 {
struct drm_i915_private *i915 = ggtt->vm.i915;
-   struct pci_dev *pdev = i915->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
unsigned int size;
u16 snb_gmch_ctl;
 
@@ -1046,7 +1046,7 @@ static int i915_gmch_probe(struct i915_ggtt *ggtt)
phys_addr_t gmadr_base;
int ret;
 
-   ret = intel_gmch_probe(i915->bridge_dev, i915->drm.pdev, NULL);
+   ret = intel_gmch_probe(i915->bridge_dev, to_pci_dev(i915->drm.dev), 
NULL);
if (!ret) {
drm_err(>drm, "failed to set up gmch\n");
return -EIO;
@@ -1091,7 +1091,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct 
intel_gt *gt)
 
ggtt->vm.gt = gt;
ggtt->vm.i915 = i915;
-   ggtt->vm.dma = >drm.pdev->dev;
+   ggtt->vm.dma = i915->drm.dev;
 
if (INTEL_GEN(i915) <= 5)
ret = i915_gmch_probe(ggtt);
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c 
b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 46d9aceda64c..01b7d08532f2 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -301,7 +301,7 @@ void ppgtt_init(struct i915_ppgtt *ppgtt, struct intel_gt 
*gt)
 
ppgtt->vm.gt = gt;
ppgtt->vm.i915 = i915;
-   ppgtt->vm.dma = >drm.pdev->dev;
+   ppgtt->vm.dma = i915->drm.dev;
ppgtt->vm.total = BIT_ULL(INTEL_INFO(i915)->ppgtt_size);
 
i915_address_space_init(>vm, VM_CLASS_PPGTT);
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c 
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index d7b8e4457fc2..cce53fb9589c 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -485,14 +485,14 @@ static bool rc6_supported(struct intel_rc6 *rc6)
 static void rpm_get(struct intel_rc6 *rc6)
 {
GEM_BUG_ON(rc6->wakeref);
-   pm_runtime_get_sync(_to_i915(rc6)->drm.pdev->dev);
+   pm_runtime_get_sync(rc6_to_i915(rc6)->drm.dev);
rc6->wakeref = true;
 }
 
 static void rpm_put(struct intel_rc6 *rc6)
 {
GEM_BUG_ON(!rc6->wakeref);
-   pm_runtime_put(_to_i915(rc6)->drm.pdev->dev);
+   pm_runtime_put(rc6_to_i915(rc6)->drm.dev);
rc6->wakeref = false;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 761b50eca33b..fa8f1e98dd0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -179,7 +179,7 @@ static int i915_do_reset(struct intel_gt *gt,
 intel_engine_mask_t engine_mask,
 unsigned int retry)
 {
-   struct pci_dev *pdev = gt->i915->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(gt->i915->drm.dev);
int err;
 
/* Assert reset for at least 20 usec, and wait for acknowledgement. */
@@ -208,7 

[Intel-gfx] [PATCH v3 4/8] drm/i915: Remove references to struct drm_device.pdev

2021-01-07 Thread Thomas Zimmermann
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.

v3:
* rebased
v2:
* move gt/ and gvt/ changes into separate patches

Signed-off-by: Thomas Zimmermann 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/display/intel_bios.c |  2 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c| 14 ++---
 drivers/gpu/drm/i915/display/intel_csr.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c|  2 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c|  2 +-
 .../gpu/drm/i915/display/intel_lpe_audio.c|  5 +++--
 drivers/gpu/drm/i915/display/intel_opregion.c |  6 +++---
 drivers/gpu/drm/i915/display/intel_overlay.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_panel.c|  4 ++--
 drivers/gpu/drm/i915/display/intel_quirks.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
 drivers/gpu/drm/i915/display/intel_vga.c  |  8 
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  |  6 +++---
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.c   | 20 +--
 drivers/gpu/drm/i915/i915_drv.h   |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  5 ++---
 drivers/gpu/drm/i915/i915_getparam.c  |  5 +++--
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 drivers/gpu/drm/i915/i915_irq.c   |  6 +++---
 drivers/gpu/drm/i915/i915_pmu.c   |  2 +-
 drivers/gpu/drm/i915/i915_suspend.c   |  4 ++--
 drivers/gpu/drm/i915/i915_switcheroo.c|  4 ++--
 drivers/gpu/drm/i915/i915_vgpu.c  |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c  |  2 +-
 drivers/gpu/drm/i915/intel_region_lmem.c  |  8 
 drivers/gpu/drm/i915/intel_runtime_pm.c   |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c   |  4 ++--
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  1 -
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  2 +-
 32 files changed, 66 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 06c3310446a2..6144872cf3aa 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2088,7 +2088,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t size)
 
 static struct vbt_header *oprom_get_vbt(struct drm_i915_private *dev_priv)
 {
-   struct pci_dev *pdev = dev_priv->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
void __iomem *p = NULL, *oprom;
struct vbt_header *vbt;
u16 vbt_size;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 2e878cc274b7..bf83e9e75227 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -96,7 +96,7 @@ static void fixed_450mhz_get_cdclk(struct drm_i915_private 
*dev_priv,
 static void i85x_get_cdclk(struct drm_i915_private *dev_priv,
   struct intel_cdclk_config *cdclk_config)
 {
-   struct pci_dev *pdev = dev_priv->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 hpllcc = 0;
 
/*
@@ -138,7 +138,7 @@ static void i85x_get_cdclk(struct drm_i915_private 
*dev_priv,
 static void i915gm_get_cdclk(struct drm_i915_private *dev_priv,
 struct intel_cdclk_config *cdclk_config)
 {
-   struct pci_dev *pdev = dev_priv->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 gcfgc = 0;
 
pci_read_config_word(pdev, GCFGC, );
@@ -162,7 +162,7 @@ static void i915gm_get_cdclk(struct drm_i915_private 
*dev_priv,
 static void i945gm_get_cdclk(struct drm_i915_private *dev_priv,
 struct intel_cdclk_config *cdclk_config)
 {
-   struct pci_dev *pdev = dev_priv->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 gcfgc = 0;
 
pci_read_config_word(pdev, GCFGC, );
@@ -256,7 +256,7 @@ static unsigned int intel_hpll_vco(struct drm_i915_private 
*dev_priv)
 static void g33_get_cdclk(struct drm_i915_private *dev_priv,
  struct intel_cdclk_config *cdclk_config)
 {
-   struct pci_dev *pdev = dev_priv->drm.pdev;
+   struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
static const u8 div_3200[] = { 12, 10,  8,  7, 5, 16 };
static const u8 div_4000[] = { 14, 12, 10,  8, 6, 20 };
static const u8 div_4800[] = { 20, 14, 12, 10, 8, 24 };
@@ -305,7 +305,7 @@ static void g33_get_cdclk(struct drm_i915_private *dev_priv,
 static void pnv_get_cdclk(struct drm_i915_private *dev_priv,
  struct intel_cdclk_config *cdclk_config)
 {
-   struct pci_dev *pdev = dev_priv->drm.pdev;
+   

[Intel-gfx] [PATCH v3 3/8] drm/hibmc: Remove references to struct drm_device.pdev

2021-01-07 Thread Thomas Zimmermann
Using struct drm_device.pdev is deprecated. Convert hibmc to struct
drm_device.dev. No functional changes.

v3:
* rebased

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Tian Tao 
Acked-by: Sam Ravnborg 
Cc: Xinliang Liu 
Cc: Tian Tao  
Cc: John Stultz 
Cc: Xinwei Kong 
Cc: Chen Feng 
---
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 13 ++--
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c   |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c   | 61 +++
 3 files changed, 68 insertions(+), 8 deletions(-)
 create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 0d4e9023f54d..0a2edc7b754a 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -210,8 +210,8 @@ static void hibmc_hw_config(struct hibmc_drm_private *priv)
 
 static int hibmc_hw_map(struct hibmc_drm_private *priv)
 {
-   struct drm_device *dev = >dev;
struct pci_dev *pdev = dev->pdev;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
resource_size_t addr, size, ioaddr, iosize;
 
ioaddr = pci_resource_start(pdev, 1);
@@ -255,13 +255,14 @@ static int hibmc_unload(struct drm_device *dev)
if (dev->irq_enabled)
drm_irq_uninstall(dev);
 
-   pci_disable_msi(dev->pdev);
+   pci_disable_msi(to_pci_dev(dev->dev));
 
return 0;
 }
 
 static int hibmc_load(struct drm_device *dev)
 {
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
int ret;
 
@@ -269,8 +270,7 @@ static int hibmc_load(struct drm_device *dev)
if (ret)
goto err;
 
-   ret = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
-   priv->fb_size);
+   ret = drmm_vram_helper_init(dev, pci_resource_start(pdev, 0), 
priv->fb_size);
if (ret) {
drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
goto err;
@@ -286,11 +286,11 @@ static int hibmc_load(struct drm_device *dev)
goto err;
}
 
-   ret = pci_enable_msi(dev->pdev);
+   ret = pci_enable_msi(pdev);
if (ret) {
drm_warn(dev, "enabling MSI failed: %d\n", ret);
} else {
-   ret = drm_irq_install(dev, dev->pdev->irq);
+   ret = drm_irq_install(dev, pdev->irq);
if (ret)
drm_warn(dev, "install irq failed: %d\n", ret);
}
@@ -326,7 +326,6 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
}
 
dev = >dev;
-   dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
 
ret = pcim_enable_device(pdev);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
index 86d712090d87..410bd019bb35 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
@@ -83,7 +83,7 @@ int hibmc_ddc_create(struct drm_device *drm_dev,
connector->adapter.owner = THIS_MODULE;
connector->adapter.class = I2C_CLASS_DDC;
snprintf(connector->adapter.name, I2C_NAME_SIZE, "HIS i2c bit bus");
-   connector->adapter.dev.parent = _dev->pdev->dev;
+   connector->adapter.dev.parent = drm_dev->dev;
i2c_set_adapdata(>adapter, connector);
connector->adapter.algo_data = >bit_data;
 
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
new file mode 100644
index ..77f075075db2
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Hisilicon Hibmc SoC drm driver
+ *
+ * Based on the bochs drm driver.
+ *
+ * Copyright (c) 2016 Huawei Limited.
+ *
+ * Author:
+ * Rongrong Zou 
+ * Rongrong Zou 
+ * Jianhua Li 
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hibmc_drm_drv.h"
+
+int hibmc_mm_init(struct hibmc_drm_private *hibmc)
+{
+   struct drm_vram_mm *vmm;
+   int ret;
+   struct drm_device *dev = hibmc->dev;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
+
+   vmm = drm_vram_helper_alloc_mm(dev, pci_resource_start(pdev, 0),
+  hibmc->fb_size);
+   if (IS_ERR(vmm)) {
+   ret = PTR_ERR(vmm);
+   drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+void hibmc_mm_fini(struct hibmc_drm_private *hibmc)
+{
+   if (!hibmc->dev->vram_mm)
+   return;
+
+   drm_vram_helper_release_mm(hibmc->dev);
+}
+
+int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
+{
+   return 

[Intel-gfx] [PATCH v3 0/8] drm: Move struct drm_device.pdev to legacy

2021-01-07 Thread Thomas Zimmermann
I merged many of the patches that were ready in v2 into drm-misc-next. In
v3 remain only patches that need an r-b/a-b (i915/gt/gvt) or required
a change from v2.

The pdev field in struct drm_device points to a PCI device structure and
goes back to UMS-only days when all DRM drivers were for PCI devices.
Meanwhile we also support USB, SPI and platform devices. Each of those
uses the generic device stored in struct drm_device.dev.

To reduce duplication and remove the special case of PCI, this patchset
converts all modesetting drivers from pdev to dev and makes pdev a field
for legacy UMS drivers.

For PCI devices, the pointer in struct drm_device.dev can be upcasted to
struct pci_device; or tested for PCI with dev_is_pci(). In several places
the code can use the dev field directly.

After converting all drivers and the DRM core, the pdev fields becomes
only relevant for legacy drivers. In a later patchset, we may want to
convert these as well and remove pdev entirely.

v3:
* fix one pdev reference in nouveau (Jeremy)
* rebases
v2:
* move whitespace fixes into separate patches (Alex, Sam)
* move i915 gt/ and gvt/ changes into separate patches (Joonas)


Thomas Zimmermann (8):
  drm/amdgpu: Fix trailing whitespaces
  drm/amdgpu: Remove references to struct drm_device.pdev
  drm/hibmc: Remove references to struct drm_device.pdev
  drm/i915: Remove references to struct drm_device.pdev
  drm/i915/gt: Remove references to struct drm_device.pdev
  drm/i915/gvt: Remove references to struct drm_device.pdev
  drm/nouveau: Remove references to struct drm_device.pdev
  drm: Upcast struct drm_device.dev to struct pci_device; replace pdev

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 23 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   | 10 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 10 +--
 drivers/gpu/drm/drm_agpsupport.c  |  9 ++-
 drivers/gpu/drm/drm_bufs.c|  4 +-
 drivers/gpu/drm/drm_edid.c|  7 ++-
 drivers/gpu/drm/drm_irq.c | 12 ++--
 drivers/gpu/drm/drm_pci.c | 26 
 drivers/gpu/drm/drm_vm.c  |  2 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 13 ++--
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c   |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c   | 61 +++
 drivers/gpu/drm/i915/display/intel_bios.c |  2 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c| 14 ++---
 drivers/gpu/drm/i915/display/intel_csr.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c|  2 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c|  2 +-
 .../gpu/drm/i915/display/intel_lpe_audio.c|  5 +-
 drivers/gpu/drm/i915/display/intel_opregion.c |  6 +-
 drivers/gpu/drm/i915/display/intel_overlay.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_panel.c|  4 +-
 drivers/gpu/drm/i915/display/intel_quirks.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
 drivers/gpu/drm/i915/display/intel_vga.c  |  8 +--
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  |  6 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 10 +--
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_rc6.c   |  4 +-
 drivers/gpu/drm/i915/gt/intel_reset.c |  6 +-
 drivers/gpu/drm/i915/gvt/cfg_space.c  |  5 +-
 drivers/gpu/drm/i915/gvt/firmware.c   | 10 +--
 drivers/gpu/drm/i915/gvt/gtt.c| 12 ++--
 drivers/gpu/drm/i915/gvt/gvt.c|  6 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c  |  4 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.c   | 20 +++---
 drivers/gpu/drm/i915/i915_drv.h   |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  5 +-
 drivers/gpu/drm/i915/i915_getparam.c  |  5 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 drivers/gpu/drm/i915/i915_irq.c   |  6 +-
 drivers/gpu/drm/i915/i915_pmu.c   |  2 +-
 drivers/gpu/drm/i915/i915_suspend.c   |  4 +-
 drivers/gpu/drm/i915/i915_switcheroo.c|  4 +-
 drivers/gpu/drm/i915/i915_vgpu.c  |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c  |  2 +-
 drivers/gpu/drm/i915/intel_region_lmem.c  |  8 +--
 drivers/gpu/drm/i915/intel_runtime_pm.c   |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c   |  4 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  1 -
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/arb.c| 12 ++--
 

  1   2   >