[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Attach and Set vrr_enabled property (rev2)

2022-04-25 Thread Patchwork
== Series Details ==

Series: Attach and Set vrr_enabled property (rev2)
URL   : https://patchwork.freedesktop.org/series/102978/
State : warning

== Summary ==

Error: dim checkpatch failed
74f8ea70155d drm/vrr: Attach vrr_enabled property to the drm crtc
-:90: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#90: FILE: drivers/gpu/drm/drm_mode_config.c:327:
+   prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
"VRR_ENABLED");

total: 0 errors, 0 warnings, 1 checks, 63 lines checked
ecc537c1ea75 drm/i915/vrr: Attach and set drm crtc vrr_enabled property




[Intel-gfx] ✗ Fi.CI.BAT: failure for Attach and Set vrr_enabled property (rev2)

2022-04-25 Thread Patchwork
== Series Details ==

Series: Attach and Set vrr_enabled property (rev2)
URL   : https://patchwork.freedesktop.org/series/102978/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11548 -> Patchwork_102978v2


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102978v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102978v2, 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_102978v2/index.html

Participating hosts (42 -> 44)
--

  Additional (5): fi-kbl-soraka fi-bdw-5557u bat-adls-5 bat-dg1-6 bat-dg2-8 
  Missing(3): bat-adlm-1 fi-bsw-cyan bat-dg1-5 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@kms_vrr@parse-vrr-range@pipe-a-dsi-1} (NEW):
- {fi-tgl-dsi}:   NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/fi-tgl-dsi/igt@kms_vrr@parse-vrr-ra...@pipe-a-dsi-1.html

  * igt@runner@aborted:
- fi-rkl-11600:   NOTRUN -> [FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/fi-rkl-11600/igt@run...@aborted.html
- fi-rkl-guc: NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/fi-rkl-guc/igt@run...@aborted.html
- fi-adl-ddr5:NOTRUN -> [FAIL][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/fi-adl-ddr5/igt@run...@aborted.html

  
 Suppressed 

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

  * igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11548/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
- {fi-jsl-1}: [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11548/fi-jsl-1/igt@gem_exec_suspend@basic...@smem.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/fi-jsl-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@kms_force_connector_basic@force-connector-state:
- {bat-dg2-8}:NOTRUN -> [DMESG-WARN][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/bat-dg2-8/igt@kms_force_connector_ba...@force-connector-state.html

  * igt@kms_vrr@negative-basic:
- {fi-tgl-dsi}:   NOTRUN -> [SKIP][10]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/fi-tgl-dsi/igt@kms_...@negative-basic.html

  * igt@runner@aborted:
- {bat-adls-5}:   NOTRUN -> [FAIL][11]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/bat-adls-5/igt@run...@aborted.html
- {bat-adlp-6}:   NOTRUN -> [FAIL][12]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/bat-adlp-6/igt@run...@aborted.html
- {bat-jsl-2}:NOTRUN -> [FAIL][13]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/bat-jsl-2/igt@run...@aborted.html
- {bat-jsl-1}:NOTRUN -> [FAIL][14]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v2/bat-jsl-1/igt@run...@aborted.html

  
New tests
-

  New tests have been introduced between CI_DRM_11548 and Patchwork_102978v2:

### New IGT tests (9) ###

  * igt@kms_vrr@parse-vrr-range@pipe-a-dp-1:
- Statuses : 3 pass(s)
- Exec time: [0.04, 0.17] s

  * igt@kms_vrr@parse-vrr-range@pipe-a-dp-2:
- Statuses : 2 pass(s) 2 skip(s)
- Exec time: [0.0, 0.43] s

  * igt@kms_vrr@parse-vrr-range@pipe-a-dsi-1:
- Statuses : 2 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@kms_vrr@parse-vrr-range@pipe-a-edp-1:
- Statuses : 2 pass(s)
- Exec time: [0.42, 0.49] s

  * igt@kms_vrr@parse-vrr-range@pipe-a-hdmi-a-1:
- Statuses : 5 pass(s)
- Exec time: [0.03, 0.20] s

  * igt@kms_vrr@parse-vrr-range@pipe-a-hdmi-a-2:
- Statuses : 3 pass(s)
- Exec time: [0.05, 0.27] s

  * igt@kms_vrr@parse-vrr-range@pipe-a-lvds-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_vrr@parse-vrr-range@pipe-a-vga-1:
- Statuses : 5 skip(s)
- Exec time: [0.0] s

  * igt@kms_vrr@parse-vrr-range@pipe-c-hdmi-a-2:
- Statuses : 1 pass(s)
- Exec time: [0.10] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka:  NOTRUN -> [SKIP][15] ([fdo#109271]) +10 similar issues
   [15]: 
htt

[Intel-gfx] [PATCH v2 00/14] GSC support for XeHP SDV and DG2 platforms

2022-04-25 Thread Alexander Usyskin
Add GSC support for XeHP SDV and DG2 platforms.

The series includes changes for the mei driver:
- add ability to use polling instead of interrupts
- add ability to use extended timeouts
- setup extended operational memory for GSC

The series includes changes for the i915 driver:
- allocate extended operational memory for GSC
- GSC on XeHP SDV offsets and definitions

Greg KH, please review and ACK the MEI patches.
We are pushing these patches through gfx tree as
the auxiliary device belongs there.

V2: rebase over merged DG1 series and DG2 enablement patch,
fix commit messages

Alexander Usyskin (5):
  drm/i915/gsc: add slow_fw flag to the mei auxiliary device
  drm/i915/gsc: add slow_fw flag to the gsc device definition
  drm/i915/gsc: add GSC XeHP SDV platform definition
  mei: gsc: wait for reset thread on stop
  mei: extend timeouts on slow devices.

Daniele Ceraolo Spurio (1):
  HAX: drm/i915: force INTEL_MEI_GSC on for CI

Tomas Winkler (5):
  mei: gsc: use polling instead of interrupts
  mei: mkhi: add memory ready command
  mei: gsc: setup gsc extended operational memory
  mei: debugfs: add pxp mode to devstate in debugfs
  drm/i915/gsc: allocate extended operational memory in LMEM

Vitaly Lubart (3):
  drm/i915/gsc: skip irq initialization if using polling
  mei: bus: export common mkhi definitions into a separate header
  mei: gsc: add transition to PXP mode in resume flow

 drivers/gpu/drm/i915/Kconfig.debug  |   1 +
 drivers/gpu/drm/i915/gt/intel_gsc.c | 119 +---
 drivers/gpu/drm/i915/gt/intel_gsc.h |   3 +
 drivers/misc/mei/bus-fixup.c| 105 
 drivers/misc/mei/client.c   |  14 ++--
 drivers/misc/mei/debugfs.c  |  17 
 drivers/misc/mei/gsc-me.c   |  77 +++---
 drivers/misc/mei/hbm.c  |  12 +--
 drivers/misc/mei/hw-me-regs.h   |   7 ++
 drivers/misc/mei/hw-me.c| 116 ++-
 drivers/misc/mei/hw-me.h|  14 +++-
 drivers/misc/mei/hw-txe.c   |   2 +-
 drivers/misc/mei/hw.h   |   5 ++
 drivers/misc/mei/init.c |  21 -
 drivers/misc/mei/main.c |   2 +-
 drivers/misc/mei/mei_dev.h  |  26 ++
 drivers/misc/mei/mkhi.h |  57 +
 drivers/misc/mei/pci-me.c   |   2 +-
 include/linux/mei_aux.h |   2 +
 19 files changed, 511 insertions(+), 91 deletions(-)
 create mode 100644 drivers/misc/mei/mkhi.h

-- 
2.32.0



[Intel-gfx] [PATCH v2 01/14] HAX: drm/i915: force INTEL_MEI_GSC on for CI

2022-04-25 Thread Alexander Usyskin
From: Daniele Ceraolo Spurio 

After the new config option is merged we'll enable it by default in the
CI config, but for now just force it on via the i915 Kconfig so we can
get pre-merge CI results for it.

Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/Kconfig.debug | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index e7fd3e76f8a2..be4ef485d6c1 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -48,6 +48,7 @@ config DRM_I915_DEBUG
select DRM_I915_DEBUG_RUNTIME_PM
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
select DRM_I915_SELFTEST
+   select INTEL_MEI_GSC
select BROKEN # for prototype uAPI
default n
help
-- 
2.32.0



[Intel-gfx] [PATCH v2 02/14] drm/i915/gsc: skip irq initialization if using polling

2022-04-25 Thread Alexander Usyskin
From: Vitaly Lubart 

Some platforms require the host to poll on the
GSC registers instead of relaying on the interrupts.
For those platforms, irq initialization should be skipped

Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
Signed-off-by: Alexander Usyskin 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_gsc.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index 0e494028b81d..e0236ff1d072 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -40,6 +40,7 @@ struct gsc_def {
const char *name;
unsigned long bar;
size_t bar_size;
+   bool use_polling;
 };
 
 /* gsc resources and definitions (HECI1 and HECI2) */
@@ -117,6 +118,10 @@ static void gsc_init_one(struct drm_i915_private *i915,
return;
}
 
+   /* skip irq initialization */
+   if (def->use_polling)
+   goto add_device;
+
intf->irq = irq_alloc_desc(0);
if (intf->irq < 0) {
drm_err(&i915->drm, "gsc irq error %d\n", intf->irq);
@@ -129,6 +134,7 @@ static void gsc_init_one(struct drm_i915_private *i915,
goto fail;
}
 
+add_device:
adev = kzalloc(sizeof(*adev), GFP_KERNEL);
if (!adev)
goto fail;
@@ -182,10 +188,8 @@ static void gsc_irq_handler(struct intel_gt *gt, unsigned 
int intf_id)
return;
}
 
-   if (gt->gsc.intf[intf_id].irq < 0) {
-   drm_err_ratelimited(>->i915->drm, "GSC irq: irq not set");
+   if (gt->gsc.intf[intf_id].irq < 0)
return;
-   }
 
ret = generic_handle_irq(gt->gsc.intf[intf_id].irq);
if (ret)
-- 
2.32.0



[Intel-gfx] [PATCH v2 03/14] drm/i915/gsc: add slow_fw flag to the mei auxiliary device

2022-04-25 Thread Alexander Usyskin
Add slow_fw flag to the mei auxiliary device info
to inform the mei driver about slow underlying firmware.
Such firmware will require to use larger operation timeouts.

Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Reviewed-by: Daniele Ceraolo Spurio 
---
 include/linux/mei_aux.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/mei_aux.h b/include/linux/mei_aux.h
index 587f25128848..a29f4064b9c0 100644
--- a/include/linux/mei_aux.h
+++ b/include/linux/mei_aux.h
@@ -11,6 +11,7 @@ struct mei_aux_device {
struct auxiliary_device aux_dev;
int irq;
struct resource bar;
+   bool slow_fw;
 };
 
 #define auxiliary_dev_to_mei_aux_dev(auxiliary_dev) \
-- 
2.32.0



[Intel-gfx] [PATCH v2 04/14] drm/i915/gsc: add slow_fw flag to the gsc device definition

2022-04-25 Thread Alexander Usyskin
Add slow_fw flag to the gsc device definition
and pass it to mei auxiliary device.

Signed-off-by: Alexander Usyskin 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_gsc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index e0236ff1d072..f963c220bbff 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -41,6 +41,7 @@ struct gsc_def {
unsigned long bar;
size_t bar_size;
bool use_polling;
+   bool slow_fw;
 };
 
 /* gsc resources and definitions (HECI1 and HECI2) */
@@ -145,6 +146,7 @@ static void gsc_init_one(struct drm_i915_private *i915,
adev->bar.end = adev->bar.start + def->bar_size - 1;
adev->bar.flags = IORESOURCE_MEM;
adev->bar.desc = IORES_DESC_NONE;
+   adev->slow_fw = def->slow_fw;
 
aux_dev = &adev->aux_dev;
aux_dev->name = def->name;
-- 
2.32.0



[Intel-gfx] [PATCH v2 05/14] drm/i915/gsc: add GSC XeHP SDV platform definition

2022-04-25 Thread Alexander Usyskin
Define GSC on XeHP SDV (Intel(R) dGPU without display)

XeHP SDV uses the same hardware settings as DG1, but uses polling
instead of interrupts and runs the firmware in slow pace due to
hardware limitations.

Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
Signed-off-by: Alexander Usyskin 
---
 drivers/gpu/drm/i915/gt/intel_gsc.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index f963c220bbff..bfc307e49bf9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -56,6 +56,19 @@ static const struct gsc_def gsc_def_dg1[] = {
}
 };
 
+static const struct gsc_def gsc_def_xehpsdv[] = {
+   {
+   /* HECI1 not enabled on the device. */
+   },
+   {
+   .name = "mei-gscfi",
+   .bar = DG1_GSC_HECI2_BASE,
+   .bar_size = GSC_BAR_LENGTH,
+   .use_polling = true,
+   .slow_fw = true,
+   }
+};
+
 static const struct gsc_def gsc_def_dg2[] = {
{
.name = "mei-gsc",
@@ -107,6 +120,8 @@ static void gsc_init_one(struct drm_i915_private *i915,
 
if (IS_DG1(i915)) {
def = &gsc_def_dg1[intf_id];
+   } else if (IS_XEHPSDV(i915)) {
+   def = &gsc_def_xehpsdv[intf_id];
} else if (IS_DG2(i915)) {
def = &gsc_def_dg2[intf_id];
} else {
-- 
2.32.0



[Intel-gfx] [PATCH v2 07/14] mei: gsc: wait for reset thread on stop

2022-04-25 Thread Alexander Usyskin
Wait for reset work to complete before initiating
stop reset flow sequence.

Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index eb052005ca86..5bb6ba662cc0 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -320,6 +320,8 @@ void mei_stop(struct mei_device *dev)
 
mei_clear_interrupts(dev);
mei_synchronize_irq(dev);
+   /* to catch HW-initiated reset */
+   mei_cancel_work(dev);
 
mutex_lock(&dev->device_lock);
 
-- 
2.32.0



[Intel-gfx] [PATCH v2 06/14] mei: gsc: use polling instead of interrupts

2022-04-25 Thread Alexander Usyskin
From: Tomas Winkler 

A work-around for a HW issue in XEHPSDV that manifests itself when SW reads
a gsc register when gsc is sending an interrupt. The work-around is
to disable interrupts and to use polling instead.

Cc: James Ausmus 
Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/gsc-me.c | 48 ++--
 drivers/misc/mei/hw-me.c  | 58 ---
 drivers/misc/mei/hw-me.h  | 12 
 3 files changed, 105 insertions(+), 13 deletions(-)

diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
index c8145e9b62b6..2caba3a9ac35 100644
--- a/drivers/misc/mei/gsc-me.c
+++ b/drivers/misc/mei/gsc-me.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mei_dev.h"
 #include "hw-me.h"
@@ -66,13 +67,28 @@ static int mei_gsc_probe(struct auxiliary_device *aux_dev,
 
dev_set_drvdata(device, dev);
 
-   ret = devm_request_threaded_irq(device, hw->irq,
-   mei_me_irq_quick_handler,
-   mei_me_irq_thread_handler,
-   IRQF_ONESHOT, KBUILD_MODNAME, dev);
-   if (ret) {
-   dev_err(device, "irq register failed %d\n", ret);
-   goto err;
+   /* use polling */
+   if (mei_me_hw_use_polling(hw)) {
+   mei_disable_interrupts(dev);
+   mei_clear_interrupts(dev);
+   init_waitqueue_head(&hw->wait_active);
+   hw->is_active = true; /* start in active mode for 
initialization */
+   hw->polling_thread = kthread_run(mei_me_polling_thread, dev,
+"kmegscirqd/%s", 
dev_name(device));
+   if (IS_ERR(hw->polling_thread)) {
+   ret = PTR_ERR(hw->polling_thread);
+   dev_err(device, "unable to create kernel thread: %d\n", 
ret);
+   goto err;
+   }
+   } else {
+   ret = devm_request_threaded_irq(device, hw->irq,
+   mei_me_irq_quick_handler,
+   mei_me_irq_thread_handler,
+   IRQF_ONESHOT, KBUILD_MODNAME, 
dev);
+   if (ret) {
+   dev_err(device, "irq register failed %d\n", ret);
+   goto err;
+   }
}
 
pm_runtime_get_noresume(device);
@@ -98,7 +114,8 @@ static int mei_gsc_probe(struct auxiliary_device *aux_dev,
 
 register_err:
mei_stop(dev);
-   devm_free_irq(device, hw->irq, dev);
+   if (!mei_me_hw_use_polling(hw))
+   devm_free_irq(device, hw->irq, dev);
 
 err:
dev_err(device, "probe failed: %d\n", ret);
@@ -119,12 +136,17 @@ static void mei_gsc_remove(struct auxiliary_device 
*aux_dev)
 
mei_stop(dev);
 
+   hw = to_me_hw(dev);
+   if (mei_me_hw_use_polling(hw))
+   kthread_stop(hw->polling_thread);
+
mei_deregister(dev);
 
pm_runtime_disable(&aux_dev->dev);
 
mei_disable_interrupts(dev);
-   devm_free_irq(&aux_dev->dev, hw->irq, dev);
+   if (!mei_me_hw_use_polling(hw))
+   devm_free_irq(&aux_dev->dev, hw->irq, dev);
 }
 
 static int __maybe_unused mei_gsc_pm_suspend(struct device *device)
@@ -185,6 +207,9 @@ static int  __maybe_unused 
mei_gsc_pm_runtime_suspend(struct device *device)
if (mei_write_is_idle(dev)) {
hw = to_me_hw(dev);
hw->pg_state = MEI_PG_ON;
+
+   if (mei_me_hw_use_polling(hw))
+   hw->is_active = false;
ret = 0;
} else {
ret = -EAGAIN;
@@ -209,6 +234,11 @@ static int __maybe_unused mei_gsc_pm_runtime_resume(struct 
device *device)
hw = to_me_hw(dev);
hw->pg_state = MEI_PG_OFF;
 
+   if (mei_me_hw_use_polling(hw)) {
+   hw->is_active = true;
+   wake_up(&hw->wait_active);
+   }
+
mutex_unlock(&dev->device_lock);
 
irq_ret = mei_me_irq_thread_handler(1, dev);
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 9870bf717979..959b3329af60 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mei_dev.h"
 #include "hbm.h"
@@ -327,9 +328,12 @@ static void mei_me_intr_clear(struct mei_device *dev)
  */
 static void mei_me_intr_enable(struct mei_device *dev)
 {
-   u32 hcsr = mei_hcsr_read(dev);
+   u32 hcsr;
+
+   if (mei_me_hw_use_polling(to_me_hw(dev)))
+   return;
 
-   hcsr |= H_CSR_IE_MASK;
+   hcsr = mei_hcsr_read(dev) | H_CSR_IE_MASK;
mei_hcsr_set(dev, hcsr);
 }
 
@@ -354,6 +358,9 @@ static void mei_me_synchronize_irq(struct mei_device *dev)
 {
struct mei_me_hw *hw = to_me_hw(dev);
 
+   if

[Intel-gfx] [PATCH v2 08/14] mei: extend timeouts on slow devices.

2022-04-25 Thread Alexander Usyskin
Parametrize operational timeouts in order
to support slow firmware on some graphic devices.

Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus-fixup.c |  3 +--
 drivers/misc/mei/client.c| 14 +++---
 drivers/misc/mei/gsc-me.c|  2 +-
 drivers/misc/mei/hbm.c   | 12 ++--
 drivers/misc/mei/hw-me.c | 30 --
 drivers/misc/mei/hw-me.h |  2 +-
 drivers/misc/mei/hw-txe.c|  2 +-
 drivers/misc/mei/hw.h|  5 +
 drivers/misc/mei/init.c  | 19 ++-
 drivers/misc/mei/main.c  |  2 +-
 drivers/misc/mei/mei_dev.h   | 16 
 drivers/misc/mei/pci-me.c|  2 +-
 12 files changed, 74 insertions(+), 35 deletions(-)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 59506ba6fc48..24e91a9ea558 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -164,7 +164,6 @@ static int mei_osver(struct mei_cl_device *cldev)
sizeof(struct mkhi_fw_ver))
 #define MKHI_FWVER_LEN(__num) (sizeof(struct mkhi_msg_hdr) + \
   sizeof(struct mkhi_fw_ver_block) * (__num))
-#define MKHI_RCV_TIMEOUT 500 /* receive timeout in msec */
 static int mei_fwver(struct mei_cl_device *cldev)
 {
char buf[MKHI_FWVER_BUF_LEN];
@@ -187,7 +186,7 @@ static int mei_fwver(struct mei_cl_device *cldev)
 
ret = 0;
bytes_recv = __mei_cl_recv(cldev->cl, buf, sizeof(buf), NULL, 0,
-  MKHI_RCV_TIMEOUT);
+  cldev->bus->timeouts.mkhi_recv);
if (bytes_recv < 0 || (size_t)bytes_recv < MKHI_FWVER_LEN(1)) {
/*
 * Should be at least one version block,
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 31264ab2eb13..e7a16d9b2241 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -870,7 +870,7 @@ static int mei_cl_send_disconnect(struct mei_cl *cl, struct 
mei_cl_cb *cb)
}
 
list_move_tail(&cb->list, &dev->ctrl_rd_list);
-   cl->timer_count = MEI_CONNECT_TIMEOUT;
+   cl->timer_count = dev->timeouts.connect;
mei_schedule_stall_timer(dev);
 
return 0;
@@ -945,7 +945,7 @@ static int __mei_cl_disconnect(struct mei_cl *cl)
wait_event_timeout(cl->wait,
   cl->state == MEI_FILE_DISCONNECT_REPLY ||
   cl->state == MEI_FILE_DISCONNECTED,
-  mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
+  dev->timeouts.cl_connect);
mutex_lock(&dev->device_lock);
 
rets = cl->status;
@@ -1065,7 +1065,7 @@ static int mei_cl_send_connect(struct mei_cl *cl, struct 
mei_cl_cb *cb)
}
 
list_move_tail(&cb->list, &dev->ctrl_rd_list);
-   cl->timer_count = MEI_CONNECT_TIMEOUT;
+   cl->timer_count = dev->timeouts.connect;
mei_schedule_stall_timer(dev);
return 0;
 }
@@ -1164,7 +1164,7 @@ int mei_cl_connect(struct mei_cl *cl, struct 
mei_me_client *me_cl,
 cl->state == MEI_FILE_DISCONNECTED ||
 cl->state == MEI_FILE_DISCONNECT_REQUIRED ||
 cl->state == MEI_FILE_DISCONNECT_REPLY),
-   mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
+   dev->timeouts.cl_connect);
mutex_lock(&dev->device_lock);
 
if (!mei_cl_is_connected(cl)) {
@@ -1562,7 +1562,7 @@ int mei_cl_notify_request(struct mei_cl *cl,
   cl->notify_en == request ||
   cl->status ||
   !mei_cl_is_connected(cl),
-  mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
+  dev->timeouts.cl_connect);
mutex_lock(&dev->device_lock);
 
if (cl->notify_en != request && !cl->status)
@@ -2336,7 +2336,7 @@ int mei_cl_dma_alloc_and_map(struct mei_cl *cl, const 
struct file *fp,
mutex_unlock(&dev->device_lock);
wait_event_timeout(cl->wait,
   cl->dma_mapped || cl->status,
-  mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
+  dev->timeouts.cl_connect);
mutex_lock(&dev->device_lock);
 
if (!cl->dma_mapped && !cl->status)
@@ -2415,7 +2415,7 @@ int mei_cl_dma_unmap(struct mei_cl *cl, const struct file 
*fp)
mutex_unlock(&dev->device_lock);
wait_event_timeout(cl->wait,
   !cl->dma_mapped || cl->status,
-  mei_secs_to_jiffies(MEI_CL_CONNECT_TIMEOUT));
+  dev->timeouts.cl_connect);
mutex_lock(&dev->device_lock);
 
if (cl->dma_mapped && !cl->status)
diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
index 2caba3a9ac35..4f6c916282b7 100644
--- a/drivers/misc/mei/gsc-me.c
+++ b/drivers/misc/mei/gsc-me

[Intel-gfx] [PATCH v2 09/14] mei: bus: export common mkhi definitions into a separate header

2022-04-25 Thread Alexander Usyskin
From: Vitaly Lubart 

Exported common mkhi definitions from bus-fixup.c into a separate
header file mkhi.h for other driver usage.

Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus-fixup.c | 32 ++---
 drivers/misc/mei/mkhi.h  | 45 
 2 files changed, 47 insertions(+), 30 deletions(-)
 create mode 100644 drivers/misc/mei/mkhi.h

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 24e91a9ea558..190691abddc9 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -15,6 +15,7 @@
 
 #include "mei_dev.h"
 #include "client.h"
+#include "mkhi.h"
 
 #define MEI_UUID_NFC_INFO UUID_LE(0xd2de1625, 0x382d, 0x417d, \
0x48, 0xa4, 0xef, 0xab, 0xba, 0x8a, 0x12, 0x06)
@@ -80,6 +81,7 @@ static void whitelist(struct mei_cl_device *cldev)
 }
 
 #define OSTYPE_LINUX2
+
 struct mei_os_ver {
__le16 build;
__le16 reserved1;
@@ -89,20 +91,6 @@ struct mei_os_ver {
u8  reserved2;
 } __packed;
 
-#define MKHI_FEATURE_PTT 0x10
-
-struct mkhi_rule_id {
-   __le16 rule_type;
-   u8 feature_id;
-   u8 reserved;
-} __packed;
-
-struct mkhi_fwcaps {
-   struct mkhi_rule_id id;
-   u8 len;
-   u8 data[];
-} __packed;
-
 struct mkhi_fw_ver_block {
u16 minor;
u8 major;
@@ -115,22 +103,6 @@ struct mkhi_fw_ver {
struct mkhi_fw_ver_block ver[MEI_MAX_FW_VER_BLOCKS];
 } __packed;
 
-#define MKHI_FWCAPS_GROUP_ID 0x3
-#define MKHI_FWCAPS_SET_OS_VER_APP_RULE_CMD 6
-#define MKHI_GEN_GROUP_ID 0xFF
-#define MKHI_GEN_GET_FW_VERSION_CMD 0x2
-struct mkhi_msg_hdr {
-   u8  group_id;
-   u8  command;
-   u8  reserved;
-   u8  result;
-} __packed;
-
-struct mkhi_msg {
-   struct mkhi_msg_hdr hdr;
-   u8 data[];
-} __packed;
-
 #define MKHI_OSVER_BUF_LEN (sizeof(struct mkhi_msg_hdr) + \
sizeof(struct mkhi_fwcaps) + \
sizeof(struct mei_os_ver))
diff --git a/drivers/misc/mei/mkhi.h b/drivers/misc/mei/mkhi.h
new file mode 100644
index ..27a9b476904e
--- /dev/null
+++ b/drivers/misc/mei/mkhi.h
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2003-2020, Intel Corporation. All rights reserved.
+ * Intel Management Engine Interface (Intel MEI) Linux driver
+ */
+
+#ifndef _MEI_MKHI_H_
+#define _MEI_MKHI_H_
+
+#include "mei_dev.h"
+
+#define MKHI_FEATURE_PTT 0x10
+
+#define MKHI_FWCAPS_GROUP_ID 0x3
+#define MKHI_FWCAPS_SET_OS_VER_APP_RULE_CMD 6
+#define MKHI_GEN_GROUP_ID 0xFF
+#define MKHI_GEN_GET_FW_VERSION_CMD 0x2
+
+#define MCHI_GROUP_ID  0xA
+
+struct mkhi_rule_id {
+   __le16 rule_type;
+   u8 feature_id;
+   u8 reserved;
+} __packed;
+
+struct mkhi_fwcaps {
+   struct mkhi_rule_id id;
+   u8 len;
+   u8 data[];
+} __packed;
+
+struct mkhi_msg_hdr {
+   u8  group_id;
+   u8  command;
+   u8  reserved;
+   u8  result;
+} __packed;
+
+struct mkhi_msg {
+   struct mkhi_msg_hdr hdr;
+   u8 data[];
+} __packed;
+
+#endif /* _MEI_MKHI_H_ */
-- 
2.32.0



[Intel-gfx] [PATCH v2 11/14] mei: gsc: setup gsc extended operational memory

2022-04-25 Thread Alexander Usyskin
From: Tomas Winkler 

1. Retrieve extended operational memory physical pointers from the
   auxiliary device info.
2. Setup memory registers.
3. Notify firmware that the memory is ready by sending the memory
   ready command.
4. Disable PXP device if GSC is not in PXP mode.

CC: Daniele Ceraolo Spurio 
Signed-off-by: Tomas Winkler 
Signed-off-by: Alexander Usyskin 
---
 drivers/misc/mei/bus-fixup.c  | 70 ++-
 drivers/misc/mei/gsc-me.c | 16 
 drivers/misc/mei/hw-me-regs.h |  7 
 drivers/misc/mei/hw-me.c  | 28 +-
 drivers/misc/mei/mei_dev.h| 10 +
 include/linux/mei_aux.h   |  1 +
 6 files changed, 129 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 190691abddc9..d2929f68604d 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -189,6 +189,19 @@ static int mei_fwver(struct mei_cl_device *cldev)
return ret;
 }
 
+static int mei_gfx_memory_ready(struct mei_cl_device *cldev)
+{
+   struct mkhi_gfx_mem_ready req = {0};
+   unsigned int mode = MEI_CL_IO_TX_INTERNAL;
+
+   req.hdr.group_id = MKHI_GROUP_ID_GFX;
+   req.hdr.command = MKHI_GFX_MEMORY_READY_CMD_REQ;
+   req.flags = MKHI_GFX_MEM_READY_PXP_ALLOWED;
+
+   dev_dbg(&cldev->dev, "Sending memory ready command\n");
+   return __mei_cl_send(cldev->cl, (u8 *)&req, sizeof(req), 0, mode);
+}
+
 static void mei_mkhi_fix(struct mei_cl_device *cldev)
 {
int ret;
@@ -235,6 +248,39 @@ static void mei_gsc_mkhi_ver(struct mei_cl_device *cldev)
dev_err(&cldev->dev, "FW version command failed %d\n", ret);
mei_cldev_disable(cldev);
 }
+
+static void mei_gsc_mkhi_fix_ver(struct mei_cl_device *cldev)
+{
+   int ret;
+
+   /* No need to enable the client if nothing is needed from it */
+   if (!cldev->bus->fw_f_fw_ver_supported &&
+   (cldev->bus->pxp_mode != MEI_DEV_PXP_INIT))
+   return;
+
+   ret = mei_cldev_enable(cldev);
+   if (ret)
+   return;
+
+   if (cldev->bus->pxp_mode == MEI_DEV_PXP_INIT) {
+   ret = mei_gfx_memory_ready(cldev);
+   if (ret < 0)
+   dev_err(&cldev->dev, "memory ready command failed 
%d\n", ret);
+   else
+   dev_dbg(&cldev->dev, "memory ready command sent\n");
+   /* we go to reset after that */
+   cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
+   goto out;
+   }
+
+   ret = mei_fwver(cldev);
+   if (ret < 0)
+   dev_err(&cldev->dev, "FW version command failed %d\n",
+   ret);
+out:
+   mei_cldev_disable(cldev);
+}
+
 /**
  * mei_wd - wd client on the bus, change protocol version
  *   as the API has changed.
@@ -474,6 +520,26 @@ static void vt_support(struct mei_cl_device *cldev)
cldev->do_match = 1;
 }
 
+/**
+ * pxp_isready - enable bus client if pxp is ready
+ *
+ * @cldev: me clients device
+ */
+static void pxp_isready(struct mei_cl_device *cldev)
+{
+   struct mei_device *bus = cldev->bus;
+
+   switch (bus->pxp_mode) {
+   case MEI_DEV_PXP_READY:
+   case MEI_DEV_PXP_DEFAULT:
+   cldev->do_match = 1;
+   break;
+   default:
+   cldev->do_match = 0;
+   break;
+   }
+}
+
 #define MEI_FIXUP(_uuid, _hook) { _uuid, _hook }
 
 static struct mei_fixup {
@@ -487,10 +553,10 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_WD, mei_wd),
MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
MEI_FIXUP(MEI_UUID_IGSC_MKHI, mei_gsc_mkhi_ver),
-   MEI_FIXUP(MEI_UUID_IGSC_MKHI_FIX, mei_gsc_mkhi_ver),
+   MEI_FIXUP(MEI_UUID_IGSC_MKHI_FIX, mei_gsc_mkhi_fix_ver),
MEI_FIXUP(MEI_UUID_HDCP, whitelist),
MEI_FIXUP(MEI_UUID_ANY, vt_support),
-   MEI_FIXUP(MEI_UUID_PAVP, whitelist),
+   MEI_FIXUP(MEI_UUID_PAVP, pxp_isready),
 };
 
 /**
diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
index 4f6c916282b7..c8a167b57cc9 100644
--- a/drivers/misc/mei/gsc-me.c
+++ b/drivers/misc/mei/gsc-me.c
@@ -32,6 +32,17 @@ static int mei_gsc_read_hfs(const struct mei_device *dev, 
int where, u32 *val)
return 0;
 }
 
+static void mei_gsc_set_ext_op_mem(const struct mei_me_hw *hw, struct resource 
*mem)
+{
+   u32 low = lower_32_bits(mem->start);
+   u32 hi  = upper_32_bits(mem->start);
+   u32 limit = (resource_size(mem) / SZ_4K) | GSC_EXT_OP_MEM_VALID;
+
+   iowrite32(low, hw->mem_addr + H_GSC_EXT_OP_MEM_BASE_ADDR_LO_REG);
+   iowrite32(hi, hw->mem_addr + H_GSC_EXT_OP_MEM_BASE_ADDR_HI_REG);
+   iowrite32(limit, hw->mem_addr + H_GSC_EXT_OP_MEM_LIMIT_REG);
+}
+
 static int mei_gsc_probe(struct auxiliary_device *aux_dev,
 const struct auxiliary_device_id *aux_dev_id)
 {
@@ -67,6 +78,11 @@ static int mei_gsc_probe(struct auxiliary_device *aux_dev,
 
dev_s

[Intel-gfx] [PATCH v2 10/14] mei: mkhi: add memory ready command

2022-04-25 Thread Alexander Usyskin
From: Tomas Winkler 

Add GSC memory ready command.
The command indicates to the firmware that
extend operation memory was setup and
the firmware may enter PXP mode.

CC: Daniele Ceraolo Spurio 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/mkhi.h | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/mkhi.h b/drivers/misc/mei/mkhi.h
index 27a9b476904e..ea9fe487cb0f 100644
--- a/drivers/misc/mei/mkhi.h
+++ b/drivers/misc/mei/mkhi.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * Copyright (c) 2003-2020, Intel Corporation. All rights reserved.
+ * Copyright (c) 2003-2021, Intel Corporation. All rights reserved.
  * Intel Management Engine Interface (Intel MEI) Linux driver
  */
 
@@ -18,6 +18,13 @@
 
 #define MCHI_GROUP_ID  0xA
 
+#define MKHI_GROUP_ID_GFX  0x30
+#define MKHI_GFX_RESET_WARN_CMD_REQ0x0
+#define MKHI_GFX_MEMORY_READY_CMD_REQ  0x1
+
+/* Allow transition to PXP mode without approval */
+#define MKHI_GFX_MEM_READY_PXP_ALLOWED  0x1
+
 struct mkhi_rule_id {
__le16 rule_type;
u8 feature_id;
@@ -42,4 +49,9 @@ struct mkhi_msg {
u8 data[];
 } __packed;
 
+struct mkhi_gfx_mem_ready {
+   struct mkhi_msg_hdr hdr;
+   uint32_t flags;
+} __packed;
+
 #endif /* _MEI_MKHI_H_ */
-- 
2.32.0



[Intel-gfx] [PATCH v2 12/14] mei: gsc: add transition to PXP mode in resume flow

2022-04-25 Thread Alexander Usyskin
From: Vitaly Lubart 

Added transition to PXP mode in resume flow.

CC: Daniele Ceraolo Spurio 
Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/gsc-me.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
index c8a167b57cc9..71f247f5e7ca 100644
--- a/drivers/misc/mei/gsc-me.c
+++ b/drivers/misc/mei/gsc-me.c
@@ -182,11 +182,22 @@ static int __maybe_unused mei_gsc_pm_suspend(struct 
device *device)
 static int __maybe_unused mei_gsc_pm_resume(struct device *device)
 {
struct mei_device *dev = dev_get_drvdata(device);
+   struct auxiliary_device *aux_dev;
+   struct mei_aux_device *adev;
int err;
+   struct mei_me_hw *hw;
 
if (!dev)
return -ENODEV;
 
+   hw = to_me_hw(dev);
+   aux_dev = to_auxiliary_dev(device);
+   adev = auxiliary_dev_to_mei_aux_dev(aux_dev);
+   if (adev->ext_op_mem.start) {
+   mei_gsc_set_ext_op_mem(hw, &adev->ext_op_mem);
+   dev->pxp_mode = MEI_DEV_PXP_INIT;
+   }
+
err = mei_restart(dev);
if (err)
return err;
-- 
2.32.0



[Intel-gfx] [PATCH v2 13/14] mei: debugfs: add pxp mode to devstate in debugfs

2022-04-25 Thread Alexander Usyskin
From: Tomas Winkler 

CC: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/debugfs.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c
index 1ce61e9e24fc..4074fec866a6 100644
--- a/drivers/misc/mei/debugfs.c
+++ b/drivers/misc/mei/debugfs.c
@@ -86,6 +86,20 @@ static int mei_dbgfs_active_show(struct seq_file *m, void 
*unused)
 }
 DEFINE_SHOW_ATTRIBUTE(mei_dbgfs_active);
 
+static const char *mei_dev_pxp_mode_str(enum mei_dev_pxp_mode state)
+{
+#define MEI_PXP_MODE(state) case MEI_DEV_PXP_##state: return #state
+   switch (state) {
+   MEI_PXP_MODE(DEFAULT);
+   MEI_PXP_MODE(INIT);
+   MEI_PXP_MODE(SETUP);
+   MEI_PXP_MODE(READY);
+   default:
+   return "unknown";
+   }
+#undef MEI_PXP_MODE
+}
+
 static int mei_dbgfs_devstate_show(struct seq_file *m, void *unused)
 {
struct mei_device *dev = m->private;
@@ -112,6 +126,9 @@ static int mei_dbgfs_devstate_show(struct seq_file *m, void 
*unused)
seq_printf(m, "pg:  %s, %s\n",
   mei_pg_is_enabled(dev) ? "ENABLED" : "DISABLED",
   mei_pg_state_str(mei_pg_state(dev)));
+
+   seq_printf(m, "pxp: %s\n", mei_dev_pxp_mode_str(dev->pxp_mode));
+
return 0;
 }
 DEFINE_SHOW_ATTRIBUTE(mei_dbgfs_devstate);
-- 
2.32.0



[Intel-gfx] [PATCH v2 14/14] drm/i915/gsc: allocate extended operational memory in LMEM

2022-04-25 Thread Alexander Usyskin
From: Tomas Winkler 

GSC requires more operational memory than available on chip.
Reserve 4M of LMEM for GSC operation. The memory is provided to the
GSC as struct resource to the auxiliary data of the child device.

Signed-off-by: Tomas Winkler 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
 drivers/gpu/drm/i915/gt/intel_gsc.c | 92 ++---
 drivers/gpu/drm/i915/gt/intel_gsc.h |  3 +
 2 files changed, 88 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index bfc307e49bf9..4d87519d5773 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -7,6 +7,7 @@
 #include 
 #include "i915_drv.h"
 #include "i915_reg.h"
+#include "gem/i915_gem_region.h"
 #include "gt/intel_gsc.h"
 #include "gt/intel_gt.h"
 
@@ -36,12 +37,68 @@ static int gsc_irq_init(int irq)
return irq_set_chip_data(irq, NULL);
 }
 
+static int
+gsc_ext_om_alloc(struct intel_gsc *gsc, struct intel_gsc_intf *intf, size_t 
size)
+{
+   struct intel_gt *gt = gsc_to_gt(gsc);
+   struct drm_i915_gem_object *obj;
+   void *vaddr;
+   int err;
+
+   obj = i915_gem_object_create_lmem(gt->i915, size, 
I915_BO_ALLOC_CONTIGUOUS);
+   if (IS_ERR(obj)) {
+   drm_err(>->i915->drm, "Failed to allocate gsc memory\n");
+   return PTR_ERR(obj);
+   }
+
+   err = i915_gem_object_pin_pages_unlocked(obj);
+   if (err) {
+   drm_err(>->i915->drm, "Failed to pin pages for gsc memory\n");
+   goto out_put;
+   }
+
+   vaddr = i915_gem_object_pin_map_unlocked(obj, 
i915_coherent_map_type(gt->i915, obj, true));
+   if (IS_ERR(vaddr)) {
+   err = PTR_ERR(vaddr);
+   drm_err(>->i915->drm, "Failed to map gsc memory\n");
+   goto out_unpin;
+   }
+
+   memset(vaddr, 0, obj->base.size);
+
+   i915_gem_object_unpin_map(obj);
+
+   intf->gem_obj = obj;
+
+   return 0;
+
+out_unpin:
+   i915_gem_object_unpin_pages(obj);
+out_put:
+   i915_gem_object_put(obj);
+   return err;
+}
+
+static void gsc_ext_om_destroy(struct intel_gsc_intf *intf)
+{
+   struct drm_i915_gem_object *obj = fetch_and_zero(&intf->gem_obj);
+
+   if (!obj)
+   return;
+
+   if (i915_gem_object_has_pinned_pages(obj))
+   i915_gem_object_unpin_pages(obj);
+
+   i915_gem_object_put(obj);
+}
+
 struct gsc_def {
const char *name;
unsigned long bar;
size_t bar_size;
bool use_polling;
bool slow_fw;
+   size_t lmem_size;
 };
 
 /* gsc resources and definitions (HECI1 and HECI2) */
@@ -74,6 +131,7 @@ static const struct gsc_def gsc_def_dg2[] = {
.name = "mei-gsc",
.bar = DG2_GSC_HECI1_BASE,
.bar_size = GSC_BAR_LENGTH,
+   .lmem_size = SZ_4M,
},
{
.name = "mei-gscfi",
@@ -90,26 +148,33 @@ static void gsc_release_dev(struct device *dev)
kfree(adev);
 }
 
-static void gsc_destroy_one(struct intel_gsc_intf *intf)
+static void gsc_destroy_one(struct drm_i915_private *i915,
+ struct intel_gsc *gsc, unsigned int intf_id)
 {
+   struct intel_gsc_intf *intf = &gsc->intf[intf_id];
+
if (intf->adev) {
auxiliary_device_delete(&intf->adev->aux_dev);
auxiliary_device_uninit(&intf->adev->aux_dev);
intf->adev = NULL;
}
+
if (intf->irq >= 0)
irq_free_desc(intf->irq);
intf->irq = -1;
+
+   gsc_ext_om_destroy(intf);
 }
 
 static void gsc_init_one(struct drm_i915_private *i915,
-struct intel_gsc_intf *intf,
-unsigned int intf_id)
+  struct intel_gsc *gsc,
+  unsigned int intf_id)
 {
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct mei_aux_device *adev;
struct auxiliary_device *aux_dev;
const struct gsc_def *def;
+   struct intel_gsc_intf *intf = &gsc->intf[intf_id];
int ret;
 
intf->irq = -1;
@@ -141,7 +206,7 @@ static void gsc_init_one(struct drm_i915_private *i915,
intf->irq = irq_alloc_desc(0);
if (intf->irq < 0) {
drm_err(&i915->drm, "gsc irq error %d\n", intf->irq);
-   return;
+   goto fail;
}
 
ret = gsc_irq_init(intf->irq);
@@ -155,6 +220,19 @@ static void gsc_init_one(struct drm_i915_private *i915,
if (!adev)
goto fail;
 
+   if (def->lmem_size) {
+   dev_dbg(&pdev->dev, "setting up GSC lmem\n");
+
+   if (gsc_ext_om_alloc(gsc, intf, def->lmem_size)) {
+   dev_err(&pdev->dev, "setting up gsc extended 
operational memory failed\n");
+   kfree(adev);
+   goto fail;
+  

Re: [Intel-gfx] [PATCH 5/8] drm/i915/gt: Add media RP0/RPn to per-gt sysfs

2022-04-25 Thread Kamil Konieczny
Hi Ashutosh,

On 2022-04-13 at 11:11:06 -0700, Ashutosh Dixit wrote:
> Retrieve RP0 and RPn freq for media IP from PCODE and display in per-gt
> sysfs. This patch adds the following files to gt/gtN sysfs:
> * media_RP0_freq_mhz
> * media_RPn_freq_mhz
- ^
Can we keep it in lowercase ? So it will be like:
media_rp0_freq_mhz
media_rpn_freq_mhz

Or is it merged with capital letters at other sysfs path ?

Regards,
Kamil

> 
> Cc: Rodrigo Vivi 
> Cc: Joonas Lahtinen 
> Original-author: Dale B Stimson 
> Signed-off-by: Dale B Stimson 
> Signed-off-by: Ashutosh Dixit 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 47 +
>  drivers/gpu/drm/i915/i915_reg.h | 15 +++
>  2 files changed, 62 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
> b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> index 2b1cd6a01724..2a3398003933 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> @@ -12,6 +12,7 @@
>  #include "i915_sysfs.h"
>  #include "intel_gt.h"
>  #include "intel_gt_regs.h"
> +#include "intel_pcode.h"
>  #include "intel_gt_sysfs.h"
>  #include "intel_gt_sysfs_pm.h"
>  #include "intel_rc6.h"
> @@ -669,13 +670,59 @@ static ssize_t media_freq_factor_store(struct device 
> *dev,
>   return err ?: count;
>  }
>  
> +static ssize_t media_RP0_freq_mhz_show(struct device *dev,
> +struct device_attribute *attr,
> +char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + u32 val;
> + int err;
> +
> + err = __intel_gt_pcode_read(gt, XEHPSDV_PCODE_FREQUENCY_CONFIG,
> + PCODE_MBOX_FC_SC_READ_FUSED_P0,
> + PCODE_MBOX_DOMAIN_MEDIAFF, &val);
> +
> + if (err)
> + return err;
> +
> + /* data_out - Fused P0 for domain ID in units of 50 MHz */
> + val *= GT_FREQUENCY_MULTIPLIER;
> +
> + return sysfs_emit(buff, "%u\n", val);
> +}
> +
> +static ssize_t media_RPn_freq_mhz_show(struct device *dev,
> +struct device_attribute *attr,
> +char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + u32 val;
> + int err;
> +
> + err = __intel_gt_pcode_read(gt, XEHPSDV_PCODE_FREQUENCY_CONFIG,
> + PCODE_MBOX_FC_SC_READ_FUSED_PN,
> + PCODE_MBOX_DOMAIN_MEDIAFF, &val);
> +
> + if (err)
> + return err;
> +
> + /* data_out - Fused P0 for domain ID in units of 50 MHz */
> + val *= GT_FREQUENCY_MULTIPLIER;
> +
> + return sysfs_emit(buff, "%u\n", val);
> +}
> +
>  static DEVICE_ATTR_RW(media_freq_factor);
>  static struct device_attribute dev_attr_media_freq_factor_scale =
>   __ATTR(media_freq_factor.scale, 0444, freq_factor_scale_show, NULL);
> +static DEVICE_ATTR_RO(media_RP0_freq_mhz);
> +static DEVICE_ATTR_RO(media_RPn_freq_mhz);
>  
>  static const struct attribute *media_perf_power_attrs[] = {
>   &dev_attr_media_freq_factor.attr,
>   &dev_attr_media_freq_factor_scale.attr,
> + &dev_attr_media_RP0_freq_mhz.attr,
> + &dev_attr_media_RPn_freq_mhz.attr,
>   NULL
>  };
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0d5a4ecd374a..a45a776b2dae 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6753,6 +6753,21 @@
>  #define DG1_UNCORE_GET_INIT_STATUS   0x0
>  #define DG1_UNCORE_INIT_STATUS_COMPLETE  0x1
>  #define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US  0x23
> +#define   XEHPSDV_PCODE_FREQUENCY_CONFIG 0x6e/* xehpsdv, pvc 
> */
> +/* XEHPSDV_PCODE_FREQUENCY_CONFIG sub-commands (param1) */
> +#define PCODE_MBOX_FC_SC_READ_FUSED_P0   0x0
> +#define PCODE_MBOX_FC_SC_READ_FUSED_PN   0x1
> +/* PCODE_MBOX_DOMAIN_* - mailbox domain IDs */
> +/*   XEHPSDV_PCODE_FREQUENCY_CONFIG param2 */
> +#define PCODE_MBOX_DOMAIN_NONE   0x0
> +#define PCODE_MBOX_DOMAIN_GT 0x1
> +#define PCODE_MBOX_DOMAIN_HBM0x2
> +#define PCODE_MBOX_DOMAIN_MEDIAFF0x3
> +#define PCODE_MBOX_DOMAIN_MEDIA_SAMPLER  0x4
> +#define PCODE_MBOX_DOMAIN_SYSTOLIC_ARRAY 0x5
> +#define PCODE_MBOX_DOMAIN_CHIPLET0x6
> +#define PCODE_MBOX_DOMAIN_BASE_CHIPLET_LINK  0x7
> +#define PCODE_MBOX_DOMAIN_BASE   0x8
>  #define GEN6_PCODE_DATA  _MMIO(0x138128)
>  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
>  #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT   16
> -- 
> 2.34.1
> 


Re: [Intel-gfx] [PATCH 1/2] drm/i915/xehp: Add compute engine ABI

2022-04-25 Thread Tvrtko Ursulin



On 22/04/2022 20:50, Matt Roper wrote:

We're now ready to start exposing compute engines to userspace.

While we're at it, let's extend the kerneldoc description for the other
engine types as well.

Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Vinay Belgaumkar 
Cc: Jordan Justen 
Cc: Szymon Morek 
UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14395
UMD (compute): https://github.com/intel/compute-runtime/pull/451


The compute one points to a commit named "Add compute engine class for 
xehp" but content of which seems more about engine query, including the 
yet non-existent distance query (and more)?! I certainly does not appear 
to be adding a definition of I915_ENGINE_CLASS_COMPUTE. This needs 
clarifying.



Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_engine_user.c |  2 +-
  drivers/gpu/drm/i915/gt/intel_gt.c  |  1 +
  drivers/gpu/drm/i915/i915_drm_client.c  |  1 +
  drivers/gpu/drm/i915/i915_drm_client.h  |  2 +-
  include/uapi/drm/i915_drm.h | 62 +++--
  5 files changed, 60 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 0f6cd96b459f..46a174f8aa00 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -47,7 +47,7 @@ static const u8 uabi_classes[] = {
[COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY,
[VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
[VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
-   /* TODO: Add COMPUTE_CLASS mapping once ABI is available */
+   [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
  };
  
  static int engine_cmp(void *priv, const struct list_head *A,

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 92394f13b42f..c96e123496a5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1175,6 +1175,7 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
[VIDEO_DECODE_CLASS]= GEN12_VD_TLB_INV_CR,
[VIDEO_ENHANCEMENT_CLASS]   = GEN12_VE_TLB_INV_CR,
[COPY_ENGINE_CLASS] = GEN12_BLT_TLB_INV_CR,
+   [COMPUTE_CLASS] = GEN12_GFX_TLB_INV_CR,


Do you know what 0xcf04 is?

Or if GEN12_GFX_TLB_INV_CR is correct then I think get_reg_and_bit() 
might need adjusting to always select bit 0 for any compute engine 
instance. Not sure how hardware would behave if value other than '1' 
would be written into 0xced8.


Regards,

Tvrtko


};
struct drm_i915_private *i915 = gt->i915;
struct intel_uncore *uncore = gt->uncore;
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index 475a6f824cad..18d38cb59923 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -81,6 +81,7 @@ static const char * const uabi_class_names[] = {
[I915_ENGINE_CLASS_COPY] = "copy",
[I915_ENGINE_CLASS_VIDEO] = "video",
[I915_ENGINE_CLASS_VIDEO_ENHANCE] = "video-enhance",
+   [I915_ENGINE_CLASS_COMPUTE] = "compute",
  };
  
  static u64 busy_add(struct i915_gem_context *ctx, unsigned int class)

diff --git a/drivers/gpu/drm/i915/i915_drm_client.h 
b/drivers/gpu/drm/i915/i915_drm_client.h
index 5f5b02b01ba0..f796c5e8e060 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -13,7 +13,7 @@
  
  #include "gt/intel_engine_types.h"
  
-#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_VIDEO_ENHANCE

+#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_COMPUTE
  
  struct drm_i915_private;
  
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h

index 35ca528803fd..a2def7b27009 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -154,21 +154,71 @@ enum i915_mocs_table_index {
I915_MOCS_CACHED,
  };
  
-/*

+/**
+ * enum drm_i915_gem_engine_class - uapi engine type enumeration
+ *
   * Different engines serve different roles, and there may be more than one
- * engine serving each role. enum drm_i915_gem_engine_class provides a
- * classification of the role of the engine, which may be used when requesting
- * operations to be performed on a certain subset of engines, or for providing
- * information about that group.
+ * engine serving each role.  This enum provides a classification of the role
+ * of the engine, which may be used when requesting operations to be performed
+ * on a certain subset of engines, or for providing information about that
+ * group.
   */
  enum drm_i915_gem_engine_class {
+   /**
+* @I915_ENGINE_CLASS_RENDER:
+*
+* Render engines support instructions used for 3D, Compute (GPGPU),
+* and programmable media workloads.  These instructions fetch data and
+* dispatch in

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GSC support for XeHP SDV and DG2 platforms (rev2)

2022-04-25 Thread Patchwork
== Series Details ==

Series: GSC support for XeHP SDV and DG2 platforms (rev2)
URL   : https://patchwork.freedesktop.org/series/102339/
State : warning

== Summary ==

Error: dim checkpatch failed
9eb52a6face3 HAX: drm/i915: force INTEL_MEI_GSC on for CI
bcb3f3e0f0e6 drm/i915/gsc: skip irq initialization if using polling
3c33122a6f2f drm/i915/gsc: add slow_fw flag to the mei auxiliary device
93f26e6be8e2 drm/i915/gsc: add slow_fw flag to the gsc device definition
8d51996ee984 drm/i915/gsc: add GSC XeHP SDV platform definition
e3c0939e6332 mei: gsc: use polling instead of interrupts
885811f13ec8 mei: gsc: wait for reset thread on stop
9946bcc89d8e mei: extend timeouts on slow devices.
ef1379eb6fe3 mei: bus: export common mkhi definitions into a separate header
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 10, in 
import git
ModuleNotFoundError: No module named 'git'
-: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, 101 lines checked
5b11304a908c mei: mkhi: add memory ready command
-:46: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#46: FILE: drivers/misc/mei/mkhi.h:54:
+   uint32_t flags;

total: 0 errors, 0 warnings, 1 checks, 29 lines checked
dadcfa341a66 mei: gsc: setup gsc extended operational memory
-:51: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'cldev->bus->pxp_mode != MEI_DEV_PXP_INIT'
#51: FILE: drivers/misc/mei/bus-fixup.c:257:
+   if (!cldev->bus->fw_f_fw_ver_supported &&
+   (cldev->bus->pxp_mode != MEI_DEV_PXP_INIT))

total: 0 errors, 0 warnings, 1 checks, 224 lines checked
8f005a4b080a mei: gsc: add transition to PXP mode in resume flow
d22619ef42f8 mei: debugfs: add pxp mode to devstate in debugfs
-:19: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#19: FILE: drivers/misc/mei/debugfs.c:91:
+#define MEI_PXP_MODE(state) case MEI_DEV_PXP_##state: return #state

total: 1 errors, 0 warnings, 0 checks, 29 lines checked
b7490e00c025 drm/i915/gsc: allocate extended operational memory in LMEM
-:109: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#109: FILE: drivers/gpu/drm/i915/gt/intel_gsc.c:152:
+static void gsc_destroy_one(struct drm_i915_private *i915,
+ struct intel_gsc *gsc, unsigned int intf_id)

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




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for GSC support for XeHP SDV and DG2 platforms (rev2)

2022-04-25 Thread Patchwork
== Series Details ==

Series: GSC support for XeHP SDV and DG2 platforms (rev2)
URL   : https://patchwork.freedesktop.org/series/102339/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.BAT: failure for GSC support for XeHP SDV and DG2 platforms (rev2)

2022-04-25 Thread Patchwork
== Series Details ==

Series: GSC support for XeHP SDV and DG2 platforms (rev2)
URL   : https://patchwork.freedesktop.org/series/102339/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_102339v2


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102339v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102339v2, 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_102339v2/index.html

Participating hosts (43 -> 44)
--

  Additional (3): bat-dg2-8 bat-adlm-1 bat-dg1-6 
  Missing(2): fi-kbl-soraka fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v2/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  
 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {bat-rpls-1}:   NOTRUN -> [INCOMPLETE][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v2/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-1}:   [DMESG-FAIL][3] ([i915#4983]) -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v2/bat-rpls-1/igt@i915_selftest@l...@reset.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][5] -> [INCOMPLETE][6] ([i915#4983])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v2/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][7] -> [DMESG-FAIL][8] ([i915#4528])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v2/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [PASS][9] -> [DMESG-WARN][10] ([i915#62]) +11 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v2/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-cfl-8109u:   [PASS][11] -> [DMESG-WARN][12] ([i915#5341] / 
[i915#62])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v2/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@runner@aborted:
- fi-blb-e6850:   NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#2403] / 
[i915#4312])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v2/fi-blb-e6850/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][14] ([i915#5334]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v2/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][16] ([i915#4785]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-1}:   [DMESG-WARN][18] ([i915#5278]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@hugepages.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102339v2/bat-rpls-1/igt@i915_selftest@l...@hugepages.html

  
  {name}: This element is suppressed. This means it is ignored when 

Re: [Intel-gfx] [PULL v3] gvt-next

2022-04-25 Thread Jani Nikula
On Thu, 21 Apr 2022, "Wang, Zhi A"  wrote:
> Hi folks:
>
> Here is the PR of gvt-next. Thanks so much for the patience.

Thanks, pulled to drm-intel-next, applied the below fix for the silent
conflict on top, and pushed out. Should show up in linux-next shortly.

BR,
Jani.

>
> Mostly it includes the patch bundle of GVT-g re-factor patches for adapting 
> the GVT-g with the
> new MDEV interfaces:
>
> - Separating the MMIO table from GVT-g. (Zhi)
> - GVT-g re-factor. (Christoph)
> - GVT-g mdev API cleanup. (Jason)
> - GVT-g trace/makefile cleanup. (Jani)
>
> Thanks so much for making this happen.
>
> This PR has been tested as following and no problem shows up:
>
> $dim update-branches
> $dim apply-pull drm-intel-next < this_email.eml
>
> When merging this pull to drm-intel-next, please include the following code 
> in the merge commit:
>
> diff --git a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c 
> b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
> index 03a7fcd0f904..72dac1718f3e 100644
> --- a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
> +++ b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
> @@ -3,6 +3,7 @@
>   * Copyright © 2020 Intel Corporation
>   */
>  
> +#include "display/intel_dmc_regs.h"
>  #include "display/vlv_dsi_pll_regs.h"
>  #include "gt/intel_gt_regs.h"
>  #include "gvt/gvt.h"
>
>
> The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:
>
>   Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
>
> are available in the Git repository at:
>
>   https://github.com/intel/gvt-linux tags/gvt-next-2022-04-21-for-christoph
>
> for you to fetch changes up to 2917f53113be3b7a0f374e02cebe6d6b749366b5:
>
>   vfio/mdev: Remove mdev drvdata (2022-04-21 07:36:56 -0400)
>
> 
> gvt-next-2022-04-21-for-christoph
>
> - Separating the MMIO table from GVT-g. (Zhi)
> - GVT-g re-factor. (Christoph)
> - GVT-g mdev API cleanup. (Jason)
> - GVT-g trace/makefile cleanup. (Jani)
>
> 
> Christoph Hellwig (27):
>   drm/i915/gvt: remove module refcounting in 
> intel_gvt_{,un}register_hypervisor
>   drm/i915/gvt: remove enum hypervisor_type
>   drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops
>   drm/i915/gvt: move the gvt code into kvmgt.ko
>   drm/i915/gvt: remove intel_gvt_ops
>   drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops
>   drm/i915/gvt: remove the unused from_virt_to_mfn op
>   drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu
>   drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu
>   drm/i915/gvt: remove vgpu->handle
>   drm/i915/gvt: devirtualize ->{read,write}_gpa
>   drm/i915/gvt: devirtualize ->{get,put}_vfio_device
>   drm/i915/gvt: devirtualize ->set_edid and ->set_opregion
>   drm/i915/gvt: devirtualize ->detach_vgpu
>   drm/i915/gvt: devirtualize ->inject_msi
>   drm/i915/gvt: devirtualize ->is_valid_gfn
>   drm/i915/gvt: devirtualize ->gfn_to_mfn
>   drm/i915/gvt: devirtualize ->{enable,disable}_page_track
>   drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page
>   drm/i915/gvt: devirtualize dma_pin_guest_page
>   drm/i915/gvt: remove struct intel_gvt_mpt
>   drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs
>   drm/i915/gvt: streamline intel_vgpu_create
>   drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers
>   drm/i915/gvt: remove kvmgt_guest_{init,exit}
>   drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev
>   drm/i915/gvt: merge gvt.c into kvmgvt.c
>
> Jani Nikula (2):
>   drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
>   drm/i915/gvt: better align the Makefile with i915 Makefile
>
> Jason Gunthorpe (5):
>   vfio/mdev: Remove vfio_mdev.c
>   vfio/mdev: Remove mdev_parent_ops dev_attr_groups
>   vfio/mdev: Remove mdev_parent_ops
>   vfio/mdev: Use the driver core to create the 'remove' file
>   vfio/mdev: Remove mdev drvdata
>
> Zhi Wang (3):
>   i915/gvt: Separate the MMIO tracking table from GVT-g
>   i915/gvt: Save the initial HW state snapshot in i915
>   i915/gvt: Use the initial HW state snapshot saved in i915
>
>  Documentation/driver-api/vfio-mediated-device.rst |   27 +-
>  drivers/gpu/drm/i915/Kconfig  |   36 +-
>  drivers/gpu/drm/i915/Makefile |8 +-
>  drivers/gpu/drm/i915/gvt/Makefile |   30 +-
>  drivers/gpu/drm/i915/gvt/cfg_space.c  |   89 +-
>  drivers/gpu/drm/i915/gvt/cmd_parser.c |4 +-
>  drivers/gpu/drm/i915/gvt/dmabuf.c |   36 +-
>  drivers/gpu/drm/i915/gvt/execlist.c   |   12 +-
>  drivers/gpu/drm/i915/gvt/firmware.c   |   25 +-
>  drivers/gpu/drm/i915/gvt/gtt.c|   55 +-
>  drivers/gpu/drm/i915/gvt/gvt.c|  340 --
>  drivers/gpu/drm/i

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Inherit submitter nice when scheduling requests

2022-04-25 Thread Tvrtko Ursulin



On 08/04/2022 16:10, Daniel Vetter wrote:

On Fri, 8 Apr 2022 at 12:29, Tvrtko Ursulin
 wrote:



On 08/04/2022 10:50, Dave Airlie wrote:

On Fri, 8 Apr 2022 at 18:25, Tvrtko Ursulin
 wrote:



On 08/04/2022 08:58, Daniel Vetter wrote:

On Thu, Apr 07, 2022 at 04:16:27PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Inherit submitter nice at point of request submission to account for long
running processes getting either externally or self re-niced.

This accounts for the current processing landscape where computational
pipelines are composed of CPU and GPU parts working in tandem.

Nice value will only apply to requests which originate from user contexts
and have default context priority. This is to avoid disturbing any
application made choices of low and high (batch processing and latency
sensitive compositing). In this case nice value adjusts the effective
priority in the narrow band of -19 to +20 around
I915_CONTEXT_DEFAULT_PRIORITY.

This means that userspace using the context priority uapi directly has a
wider range of possible adjustments (in practice that only applies to
execlists platforms - with GuC there are only three priority buckets), but
in all cases nice adjustment has the expected effect: positive nice
lowering the scheduling priority and negative nice raising it.

Signed-off-by: Tvrtko Ursulin 


I don't think adding any more fancy features to i915-scheduler makes
sense, at least not before we've cut over to drm/sched.


Why do you think so?

Drm/sched has at least low/normal/high priority and surely we will keep
the i915 context priority ABI.

Then this patch is not touching the i915 scheduler at all, neither it is
fancy.

The cover letter explains how it implements the same approach as the IO
scheduler. And it explains the reasoning and benefits. Provides an user
experience benefit today, which can easily be preserved.


won't this cause uAPI divergence between execlists and GuC, like if
something nices to -15 or -18 with execlists and the same with GuC it
won't get the same sort of result will it?


Not sure what you consider new ABI divergence but the general problem
space of execlists vs GuC priority handling is not related to this patch.


It 100% is.

Mesa only uses 3 priority levels, which means the 1k execlist levels
(or whatever it was) nonsense has not left the barn and we can get it
back in.

This here bakes it in forever as implicit uapi.


Could you please explain what exactly you see baking into uapi? The fact 
user gets the ability to control GPU time distribution? The granularity 
of it by observing say difference between nice 5 and nice 6? Something else?


I maintain the uapi did not in any case provide any statements on the 
latter, so I still don't see a problem there.


Regards,

Tvrtko




Existing GEM context ABI has -1023 - +1023 for user priorities while GuC
maps that to low/normal/high only. I915_CONTEXT_DEFAULT_PRIORITY is zero
which maps to GuC normal. Negatives map to GuC low and positives to
high. Drm/sched is I understand similar or the same.

So any userspace using the existing uapi can already observe differences
between GuC and execlists. With your example of -15 vs -18 I mean.

I don't think anyone considered that a problem because execution order
based on priority is not a hard guarantee. Neither is proportionality of
timeslicing. Otherwise GuC would already be breaking the ABI.

With this patch it simply allows external control - whereas before only
applications could change their priorities, now users can influence the
priority of the ones which did not bother to set a non-default priority.

In the case of GuC if user says "nice 10 churn-my-dataset-on-gpu &&
run-my-game", former part get low prio, latter gets normal. I don't see
any issues there. Same as if the "churn-my-dataset-on-gpu" command
implemented a command line switch which passed context priority to i915
via the existing GEM context param ioctl.

I've described the exact experiments in both modes in the cover letter
which shows it works. (Ignoring the GuC scheduling quirk where
apparently low-vs-normal timeslices worse than normal-vs-high).


Guc is not breaking anything because the _real_ uapi only has 3 levels
(plus one for kernel stuff on top).
-Daniel


Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Replace crtc_state's has_drrs by drrs_downclock_mode

2022-04-25 Thread Jani Nikula
On Thu, 21 Apr 2022, José Roberto de Souza  wrote:
> Will be adding some additional control options to DRRS that will
> require to have the DRRS downclock mode stored in the crtc_state.
>
> So to optimize memory usage a bit here using it to replace has_drrs
> as we can check if the drrs_downclock_mode pointer is different than
> null to have the same behavior has has_drrs.
>
> Cc: Vidya Srinivas 
> Cc: Sean Paul 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 4 ++--
>  drivers/gpu/drm/i915/display/intel_display_types.h   | 4 +++-
>  drivers/gpu/drm/i915/display/intel_dp.c  | 2 +-
>  drivers/gpu/drm/i915/display/intel_drrs.c| 4 ++--
>  5 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0ddfce21a828d..a5f5caeced9a0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5360,7 +5360,7 @@ static void intel_dump_pipe_config(const struct 
> intel_crtc_state *pipe_config,
>  
>   drm_dbg_kms(&dev_priv->drm, "ips: %i, double wide: %i, drrs: %i\n",
>   pipe_config->ips_enabled, pipe_config->double_wide,
> - pipe_config->has_drrs);
> + CRTC_STATE_HAS_DRRS(pipe_config));

I'll mostly let Ville comment on the series, but that macro is an
eyesore and also just out of place in intel_display_types.h. Please make
it a proper function intel_drrs_something_something() in
intel_drrs.[ch].

BR,
Jani.

>  
>   intel_dpll_dump_hw_state(dev_priv, &pipe_config->dpll_hw_state);
>  
> @@ -7088,7 +7088,7 @@ static void intel_crtc_copy_fastset(const struct 
> intel_crtc_state *old_crtc_stat
>   new_crtc_state->fdi_m_n = old_crtc_state->fdi_m_n;
>   new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
>   new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
> - new_crtc_state->has_drrs = old_crtc_state->has_drrs;
> + new_crtc_state->drrs_downclock_mode = 
> old_crtc_state->drrs_downclock_mode;
>  }
>  
>  static int intel_crtc_add_planes_to_state(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 452d773fd4e34..f9720562336da 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1096,7 +1096,7 @@ static int i915_drrs_status(struct seq_file *m, void 
> *unused)
>  
>   /* DRRS Supported */
>   seq_printf(m, "\tDRRS Enabled: %s\n",
> -str_yes_no(crtc_state->has_drrs));
> +str_yes_no(CRTC_STATE_HAS_DRRS(crtc_state)));
>  
>   seq_printf(m, "\tDRRS Active: %s\n",
>  str_yes_no(intel_drrs_is_active(crtc)));
> @@ -1786,7 +1786,7 @@ static int i915_drrs_ctl_set(void *data, u64 val)
>   crtc_state = to_intel_crtc_state(crtc->base.state);
>  
>   if (!crtc_state->hw.active ||
> - !crtc_state->has_drrs)
> + !CRTC_STATE_HAS_DRRS(crtc_state))
>   goto out;
>  
>   commit = crtc_state->uapi.commit;
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index cfd042117b109..f0b3cfd3138ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1056,7 +1056,7 @@ struct intel_crtc_state {
>  
>   /* m2_n2 for eDP downclock */
>   struct intel_link_m_n dp_m2_n2;
> - bool has_drrs;
> + const struct drm_display_mode *drrs_downclock_mode;
>  
>   /* PSR is supported but might not be enabled due the lack of enabled 
> planes */
>   bool has_psr;
> @@ -1264,6 +1264,8 @@ enum drrs_refresh_rate {
>   DRRS_REFRESH_RATE_LOW,
>  };
>  
> +#define CRTC_STATE_HAS_DRRS(crtc_state) 
> (!!((crtc_state)->drrs_downclock_mode))
> +
>  #define INTEL_PIPE_CRC_ENTRIES_NR128
>  struct intel_pipe_crc {
>   spinlock_t lock;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d55acc4a028a8..feea172dd2753 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1881,7 +1881,7 @@ intel_dp_drrs_compute_config(struct intel_connector 
> *connector,
>   if (IS_IRONLAKE(i915) || IS_SANDYBRIDGE(i915) || IS_IVYBRIDGE(i915))
>   pipe_config->msa_timing_delay = 
> i915->vbt.edp.drrs_msa_timing_delay;
>  
> - pipe_config->has_drrs = true;
> + pipe_config->drrs_downclock_mode = downclock_mode;
>  
>   pixel_clock = downclock_mode->clock;
>   if (pipe_config->splitter.enable)
>

[Intel-gfx] [PATCH v2 0/4] lrc selftest fixes

2022-04-25 Thread Ramalingam C
Few bug fixes for lrc selftest.

Resending the reviewed patches for CI feedback.

Chris Wilson (4):
  drm/i915/gt: Explicitly clear BB_OFFSET for new contexts
  drm/i915/selftests: Check for incomplete LRI from the context image
  drm/i915/selftest: Always cancel semaphore on error
  drm/i915/selftest: Clear the output buffers before GPU writes

 drivers/gpu/drm/i915/gt/intel_engine_regs.h |   1 +
 drivers/gpu/drm/i915/gt/intel_lrc.c |  17 +++
 drivers/gpu/drm/i915/gt/selftest_lrc.c  | 115 
 3 files changed, 113 insertions(+), 20 deletions(-)

-- 
2.20.1



[Intel-gfx] [PATCH v2 2/4] drm/i915/selftests: Check for incomplete LRI from the context image

2022-04-25 Thread Ramalingam C
From: Chris Wilson 

In order to keep the context image parser simple, we assume that all
commands follow a similar format. A few, especially not MI commands on
the render engines, have fixed lengths not encoded in a length field.
This caused us to incorrectly skip over 3D state commands, and start
interpreting context data as instructions. Eventually, as Daniele
discovered, this would lead us to find addition LRI as part of the data
and mistakenly add invalid LRI commands to the context probes.

Stop parsing after we see the first !MI command, as we know we will have
seen all the context registers by that point. (Mostly true for all gen so far,
though the render context does have LRI after the first page that we
have been ignoring so far. It would be useful to extract those as well
so that we have the full list of user accessible registers.)

Similarly, emit a warning if we do try to emit an invalid zero-length
LRI.

Reported-by: Daniele Ceraolo Spurio 
Signed-off-by: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Ramalingam C 
Acked-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/selftest_lrc.c | 61 +++---
 1 file changed, 54 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 33f22f17e358..684a63de156a 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -27,6 +27,9 @@
 #define NUM_GPR 16
 #define NUM_GPR_DW (NUM_GPR * 2) /* each GPR is 2 dwords */
 
+#define LRI_HEADER MI_INSTR(0x22, 0)
+#define LRI_LENGTH_MASK GENMASK(7, 0)
+
 static struct i915_vma *create_scratch(struct intel_gt *gt)
 {
return __vm_create_scratch_for_read_pinned(>->ggtt->vm, PAGE_SIZE);
@@ -180,7 +183,7 @@ static int live_lrc_layout(void *arg)
continue;
}
 
-   if ((lri & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+   if ((lri & GENMASK(31, 23)) != LRI_HEADER) {
pr_err("%s: Expected LRI command at dword %d, 
found %08x\n",
   engine->name, dw, lri);
err = -EINVAL;
@@ -945,18 +948,40 @@ store_context(struct intel_context *ce, struct i915_vma 
*scratch)
hw = defaults;
hw += LRC_STATE_OFFSET / sizeof(*hw);
do {
-   u32 len = hw[dw] & 0x7f;
+   u32 len = hw[dw] & LRI_LENGTH_MASK;
+
+   /*
+* Keep it simple, skip parsing complex commands
+*
+* At present, there are no more MI_LOAD_REGISTER_IMM
+* commands after the first 3D state command. Rather
+* than include a table (see i915_cmd_parser.c) of all
+* the possible commands and their instruction lengths
+* (or mask for variable length instructions), assume
+* we have gathered the complete list of registers and
+* bail out.
+*/
+   if ((hw[dw] >> INSTR_CLIENT_SHIFT) != INSTR_MI_CLIENT)
+   break;
 
if (hw[dw] == 0) {
dw++;
continue;
}
 
-   if ((hw[dw] & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+   if ((hw[dw] & GENMASK(31, 23)) != LRI_HEADER) {
+   /* Assume all other MI commands match LRI length mask */
dw += len + 2;
continue;
}
 
+   if (!len) {
+   pr_err("%s: invalid LRI found in context image\n",
+  ce->engine->name);
+   igt_hexdump(defaults, PAGE_SIZE);
+   break;
+   }
+
dw++;
len = (len + 1) / 2;
while (len--) {
@@ -1108,18 +1133,29 @@ static struct i915_vma *load_context(struct 
intel_context *ce, u32 poison)
hw = defaults;
hw += LRC_STATE_OFFSET / sizeof(*hw);
do {
-   u32 len = hw[dw] & 0x7f;
+   u32 len = hw[dw] & LRI_LENGTH_MASK;
+
+   /* For simplicity, break parsing at the first complex command */
+   if ((hw[dw] >> INSTR_CLIENT_SHIFT) != INSTR_MI_CLIENT)
+   break;
 
if (hw[dw] == 0) {
dw++;
continue;
}
 
-   if ((hw[dw] & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+   if ((hw[dw] & GENMASK(31, 23)) != LRI_HEADER) {
dw += len + 2;
continue;
}
 
+   if (!len) {
+   pr_err("%s: invalid LRI found in context image\n",
+  ce->engine->name);
+   igt_hexdump(defaults, PAGE_SIZE);
+  

[Intel-gfx] [PATCH v2 3/4] drm/i915/selftest: Always cancel semaphore on error

2022-04-25 Thread Ramalingam C
From: Chris Wilson 

Ensure that we always signal the semaphore when timing out, so that if it
happens to be stuck waiting for the semaphore we will quickly recover
without having to wait for a reset.

Reported-by: CQ Tang 
Signed-off-by: Chris Wilson 
Cc: CQ Tang 
cc: Joonas Lahtinen 
Signed-off-by: Ramalingam C 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/selftest_lrc.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 684a63de156a..51e4b7092d4f 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1411,18 +1411,17 @@ static int __lrc_isolation(struct intel_engine_cs 
*engine, u32 poison)
}
 
err = poison_registers(B, poison, sema);
-   if (err) {
-   WRITE_ONCE(*sema, -1);
-   i915_request_put(rq);
-   goto err_result1;
-   }
-
-   if (i915_request_wait(rq, 0, HZ / 2) < 0) {
-   i915_request_put(rq);
+   if (err == 0 && i915_request_wait(rq, 0, HZ / 2) < 0) {
+   pr_err("%s(%s): wait for results timed out\n",
+  __func__, engine->name);
err = -ETIME;
-   goto err_result1;
}
+
+   /* Always cancel the semaphore wait, just in case the GPU gets stuck */
+   WRITE_ONCE(*sema, -1);
i915_request_put(rq);
+   if (err)
+   goto err_result1;
 
err = compare_isolation(engine, ref, result, A, poison);
 
-- 
2.20.1



[Intel-gfx] [PATCH v2 1/4] drm/i915/gt: Explicitly clear BB_OFFSET for new contexts

2022-04-25 Thread Ramalingam C
From: Chris Wilson 

Even though the initial protocontext we load onto HW has the register
cleared, by the time we save it into the default image, BB_OFFSET has
had the enable bit set. Reclear BB_OFFSET for each new context.

Testcase: igt/i915_selftests/gt_lrc

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Ramalingam C 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/intel_engine_regs.h |  1 +
 drivers/gpu/drm/i915/gt/intel_lrc.c | 17 +
 drivers/gpu/drm/i915/gt/selftest_lrc.c  |  5 +
 3 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 594a629cb28f..d4b02d36d2a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -109,6 +109,7 @@
 #define RING_SBBSTATE(base)_MMIO((base) + 0x118) /* hsw+ */
 #define RING_SBBADDR_UDW(base) _MMIO((base) + 0x11c) /* gen8+ 
*/
 #define RING_BBADDR(base)  _MMIO((base) + 0x140)
+#define RING_BB_OFFSET(base)   _MMIO((base) + 0x158)
 #define RING_BBADDR_UDW(base)  _MMIO((base) + 0x168) /* gen8+ 
*/
 #define CCID(base) _MMIO((base) + 0x180)
 #define   CCID_EN  BIT(0)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3f83a9038e13..63f0b44084cf 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -662,6 +662,18 @@ static int lrc_ring_mi_mode(const struct intel_engine_cs 
*engine)
return -1;
 }
 
+static int lrc_ring_bb_offset(const struct intel_engine_cs *engine)
+{
+   if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
+   return 0x80;
+   else if (GRAPHICS_VER(engine->i915) >= 12)
+   return 0x70;
+   else if (GRAPHICS_VER(engine->i915) >= 9)
+   return 0x64;
+   else
+   return -1;
+}
+
 static int lrc_ring_gpr0(const struct intel_engine_cs *engine)
 {
if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
@@ -768,6 +780,7 @@ static void init_common_regs(u32 * const regs,
 bool inhibit)
 {
u32 ctl;
+   int loc;
 
ctl = _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH);
ctl |= _MASKED_BIT_DISABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
@@ -779,6 +792,10 @@ static void init_common_regs(u32 * const regs,
regs[CTX_CONTEXT_CONTROL] = ctl;
 
regs[CTX_TIMESTAMP] = ce->stats.runtime.last;
+
+   loc = lrc_ring_bb_offset(engine);
+   if (loc != -1)
+   regs[loc + 1] = 0;
 }
 
 static void init_wa_bb_regs(u32 * const regs,
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 6ba52ef1acb8..33f22f17e358 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -323,6 +323,11 @@ static int live_lrc_fixed(void *arg)
lrc_ring_cmd_buf_cctl(engine),
"RING_CMD_BUF_CCTL"
},
+   {
+   
i915_mmio_reg_offset(RING_BB_OFFSET(engine->mmio_base)),
+   lrc_ring_bb_offset(engine),
+   "RING_BB_OFFSET"
+   },
{ },
}, *t;
u32 *hw;
-- 
2.20.1



[Intel-gfx] [PATCH v2 4/4] drm/i915/selftest: Clear the output buffers before GPU writes

2022-04-25 Thread Ramalingam C
From: Chris Wilson 

When testing whether we can get the GPU to leak information about
non-privileged state, we first need to ensure that the output buffer is
set to a known value as the HW may opt to skip the write into memory for
a non-privileged read of a sensitive register. We chose POISON_INUSE (0x5a)
so that is both non-zero and distinct from the poison values used during
the test.

v2:
  Use i915_gem_object_pin_map_unlocked

Reported-by: CQ Tang 
Signed-off-by: Chris Wilson 
Cc: CQ Tang 
cc: Joonas Lahtinen 
Signed-off-by: Ramalingam C 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/selftest_lrc.c | 32 ++
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 51e4b7092d4f..9c8e8321c633 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1346,6 +1346,30 @@ static int compare_isolation(struct intel_engine_cs 
*engine,
return err;
 }
 
+static struct i915_vma *
+create_result_vma(struct i915_address_space *vm, unsigned long sz)
+{
+   struct i915_vma *vma;
+   void *ptr;
+
+   vma = create_user_vma(vm, sz);
+   if (IS_ERR(vma))
+   return vma;
+
+   /* Set the results to a known value distinct from the poison */
+   ptr = i915_gem_object_pin_map_unlocked(vma->obj, I915_MAP_WC);
+   if (IS_ERR(ptr)) {
+   i915_vma_put(vma);
+   return ERR_CAST(ptr);
+   }
+
+   memset(ptr, POISON_INUSE, vma->size);
+   i915_gem_object_flush_map(vma->obj);
+   i915_gem_object_unpin_map(vma->obj);
+
+   return vma;
+}
+
 static int __lrc_isolation(struct intel_engine_cs *engine, u32 poison)
 {
u32 *sema = memset32(engine->status_page.addr + 1000, 0, 1);
@@ -1364,13 +1388,13 @@ static int __lrc_isolation(struct intel_engine_cs 
*engine, u32 poison)
goto err_A;
}
 
-   ref[0] = create_user_vma(A->vm, SZ_64K);
+   ref[0] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(ref[0])) {
err = PTR_ERR(ref[0]);
goto err_B;
}
 
-   ref[1] = create_user_vma(A->vm, SZ_64K);
+   ref[1] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(ref[1])) {
err = PTR_ERR(ref[1]);
goto err_ref0;
@@ -1392,13 +1416,13 @@ static int __lrc_isolation(struct intel_engine_cs 
*engine, u32 poison)
}
i915_request_put(rq);
 
-   result[0] = create_user_vma(A->vm, SZ_64K);
+   result[0] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(result[0])) {
err = PTR_ERR(result[0]);
goto err_ref1;
}
 
-   result[1] = create_user_vma(A->vm, SZ_64K);
+   result[1] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(result[1])) {
err = PTR_ERR(result[1]);
goto err_result0;
-- 
2.20.1



Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses

2022-04-25 Thread Imre Deak
On Fri, Apr 22, 2022 at 06:48:50PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses
> URL   : https://patchwork.freedesktop.org/series/102941/
> State : failure

Patch is pushed, thanks for the review. The failures are unrelated, see
below.

> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11537_full -> Patchwork_102941v1_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_102941v1_full absolutely need 
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_102941v1_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   
> 
> Participating hosts (13 -> 13)
> --
> 
>   No changes in participating hosts
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_102941v1_full:
> 
> ### CI changes ###
> 
>  Possible regressions 
> 
>   * boot:
> - shard-iclb: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
> [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], 
> [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], 
> [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], 
> [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], 
> [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], 
> [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], 
> [PASS][41], [PASS][42], [FAIL][43], [PASS][44], [PASS][45], [PASS][46], 
> [PASS][47], [PASS][48], [PASS][49], [PASS][50])
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb8/boot.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb8/boot.html
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb7/boot.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb7/boot.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb7/boot.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb6/boot.html
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb6/boot.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb6/boot.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb5/boot.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb5/boot.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb5/boot.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb4/boot.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb4/boot.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb4/boot.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb3/boot.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb3/boot.html
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb3/boot.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb3/boot.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb2/boot.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb2/boot.html
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb2/boot.html
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb2/boot.html
>[23]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb1/boot.html
>[24]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb1/boot.html
>[25]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb1/boot.html
>[26]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb6/boot.html
>[27]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb6/boot.html
>[28]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb5/boot.html
>[29]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb5/boot.html
>[30]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb5/boot.html
>[31]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb4/boot.html
>[32]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb4/boot.html
>[33]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb4/boot.html
>[34]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb4/boot.html
>[35]: 
> https://intel-gfx-ci.01.org/

Re: [Intel-gfx] [PULL v3] gvt-next

2022-04-25 Thread Jani Nikula
On Mon, 25 Apr 2022, Jani Nikula  wrote:
> On Thu, 21 Apr 2022, "Wang, Zhi A"  wrote:
>> Hi folks:
>>
>> Here is the PR of gvt-next. Thanks so much for the patience.
>
> Thanks, pulled to drm-intel-next, applied the below fix for the silent
> conflict on top, and pushed out. Should show up in linux-next shortly.

Aww crap, this breaks debug builds.

ERROR: modpost: "intel_runtime_pm_put" [drivers/gpu/drm/i915/kvmgt.ko] 
undefined!
ERROR: modpost: "i915_fence_ops" [drivers/gpu/drm/i915/kvmgt.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:134: modules-only.symvers] Error 1
make[1]: *** Deleting file 'modules-only.symvers'
make: *** [Makefile:1749: modules] Error 2

The first is triggered with CONFIG_DRM_I915_DEBUG_RUNTIME_PM=y, the
latter with CONFIG_DRM_I915_DEBUG_GEM=y.

Please add the proper fix on top of the topic branch, and send an
additional pull request. Looks like exports will do it.

On that note, I'm wondering about the use of
EXPORT_SYMBOL_NS_GPL(). It's between two MIT licensed modules after
all. Maybe just EXPORT_SYMBOL_NS()?

BR,
Jani.


>
> BR,
> Jani.
>
>>
>> Mostly it includes the patch bundle of GVT-g re-factor patches for adapting 
>> the GVT-g with the
>> new MDEV interfaces:
>>
>> - Separating the MMIO table from GVT-g. (Zhi)
>> - GVT-g re-factor. (Christoph)
>> - GVT-g mdev API cleanup. (Jason)
>> - GVT-g trace/makefile cleanup. (Jani)
>>
>> Thanks so much for making this happen.
>>
>> This PR has been tested as following and no problem shows up:
>>
>> $dim update-branches
>> $dim apply-pull drm-intel-next < this_email.eml
>>
>> When merging this pull to drm-intel-next, please include the following code 
>> in the merge commit:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c 
>> b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
>> index 03a7fcd0f904..72dac1718f3e 100644
>> --- a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
>> +++ b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
>> @@ -3,6 +3,7 @@
>>   * Copyright © 2020 Intel Corporation
>>   */
>>  
>> +#include "display/intel_dmc_regs.h"
>>  #include "display/vlv_dsi_pll_regs.h"
>>  #include "gt/intel_gt_regs.h"
>>  #include "gvt/gvt.h"
>>
>>
>> The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:
>>
>>   Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
>>
>> are available in the Git repository at:
>>
>>   https://github.com/intel/gvt-linux tags/gvt-next-2022-04-21-for-christoph
>>
>> for you to fetch changes up to 2917f53113be3b7a0f374e02cebe6d6b749366b5:
>>
>>   vfio/mdev: Remove mdev drvdata (2022-04-21 07:36:56 -0400)
>>
>> 
>> gvt-next-2022-04-21-for-christoph
>>
>> - Separating the MMIO table from GVT-g. (Zhi)
>> - GVT-g re-factor. (Christoph)
>> - GVT-g mdev API cleanup. (Jason)
>> - GVT-g trace/makefile cleanup. (Jani)
>>
>> 
>> Christoph Hellwig (27):
>>   drm/i915/gvt: remove module refcounting in 
>> intel_gvt_{,un}register_hypervisor
>>   drm/i915/gvt: remove enum hypervisor_type
>>   drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops
>>   drm/i915/gvt: move the gvt code into kvmgt.ko
>>   drm/i915/gvt: remove intel_gvt_ops
>>   drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops
>>   drm/i915/gvt: remove the unused from_virt_to_mfn op
>>   drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu
>>   drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu
>>   drm/i915/gvt: remove vgpu->handle
>>   drm/i915/gvt: devirtualize ->{read,write}_gpa
>>   drm/i915/gvt: devirtualize ->{get,put}_vfio_device
>>   drm/i915/gvt: devirtualize ->set_edid and ->set_opregion
>>   drm/i915/gvt: devirtualize ->detach_vgpu
>>   drm/i915/gvt: devirtualize ->inject_msi
>>   drm/i915/gvt: devirtualize ->is_valid_gfn
>>   drm/i915/gvt: devirtualize ->gfn_to_mfn
>>   drm/i915/gvt: devirtualize ->{enable,disable}_page_track
>>   drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page
>>   drm/i915/gvt: devirtualize dma_pin_guest_page
>>   drm/i915/gvt: remove struct intel_gvt_mpt
>>   drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs
>>   drm/i915/gvt: streamline intel_vgpu_create
>>   drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers
>>   drm/i915/gvt: remove kvmgt_guest_{init,exit}
>>   drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev
>>   drm/i915/gvt: merge gvt.c into kvmgvt.c
>>
>> Jani Nikula (2):
>>   drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
>>   drm/i915/gvt: better align the Makefile with i915 Makefile
>>
>> Jason Gunthorpe (5):
>>   vfio/mdev: Remove vfio_mdev.c
>>   vfio/mdev: Remove mdev_parent_ops dev_attr_groups
>>   vfio/mdev: Remove mdev_parent_ops
>>   vfio/mdev: Use the driver core to create the 'remove' file
>>   vfio/mdev: Remove mdev drvdata
>>
>> Zhi Wan

Re: [Intel-gfx] [PULL v3] gvt-next

2022-04-25 Thread Wang, Zhi A
On 4/25/22 12:33 PM, Jani Nikula wrote:
> On Mon, 25 Apr 2022, Jani Nikula  wrote:
>> On Thu, 21 Apr 2022, "Wang, Zhi A"  wrote:
>>> Hi folks:
>>>
>>> Here is the PR of gvt-next. Thanks so much for the patience.
>>
>> Thanks, pulled to drm-intel-next, applied the below fix for the silent
>> conflict on top, and pushed out. Should show up in linux-next shortly.
> 
> Aww crap, this breaks debug builds.
> 
> ERROR: modpost: "intel_runtime_pm_put" [drivers/gpu/drm/i915/kvmgt.ko] 
> undefined!
> ERROR: modpost: "i915_fence_ops" [drivers/gpu/drm/i915/kvmgt.ko] undefined!
> make[1]: *** [scripts/Makefile.modpost:134: modules-only.symvers] Error 1
> make[1]: *** Deleting file 'modules-only.symvers'
> make: *** [Makefile:1749: modules] Error 2
> 
> The first is triggered with CONFIG_DRM_I915_DEBUG_RUNTIME_PM=y, the
> latter with CONFIG_DRM_I915_DEBUG_GEM=y.
> 
> Please add the proper fix on top of the topic branch, and send an
> additional pull request. Looks like exports will do it.
> 
> On that note, I'm wondering about the use of
> EXPORT_SYMBOL_NS_GPL(). It's between two MIT licensed modules after
> all. Maybe just EXPORT_SYMBOL_NS()?
> 
Will do. Thanks so much for catching this. 
> BR,
> Jani.
> 
> 
>>
>> BR,
>> Jani.
>>
>>>
>>> Mostly it includes the patch bundle of GVT-g re-factor patches for adapting 
>>> the GVT-g with the
>>> new MDEV interfaces:
>>>
>>> - Separating the MMIO table from GVT-g. (Zhi)
>>> - GVT-g re-factor. (Christoph)
>>> - GVT-g mdev API cleanup. (Jason)
>>> - GVT-g trace/makefile cleanup. (Jani)
>>>
>>> Thanks so much for making this happen.
>>>
>>> This PR has been tested as following and no problem shows up:
>>>
>>> $dim update-branches
>>> $dim apply-pull drm-intel-next < this_email.eml
>>>
>>> When merging this pull to drm-intel-next, please include the following code 
>>> in the merge commit:
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c 
>>> b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
>>> index 03a7fcd0f904..72dac1718f3e 100644
>>> --- a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
>>> +++ b/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
>>> @@ -3,6 +3,7 @@
>>>   * Copyright © 2020 Intel Corporation
>>>   */
>>>  
>>> +#include "display/intel_dmc_regs.h"
>>>  #include "display/vlv_dsi_pll_regs.h"
>>>  #include "gt/intel_gt_regs.h"
>>>  #include "gvt/gvt.h"
>>>
>>>
>>> The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:
>>>
>>>   Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
>>>
>>> are available in the Git repository at:
>>>
>>>   https://github.com/intel/gvt-linux tags/gvt-next-2022-04-21-for-christoph
>>>
>>> for you to fetch changes up to 2917f53113be3b7a0f374e02cebe6d6b749366b5:
>>>
>>>   vfio/mdev: Remove mdev drvdata (2022-04-21 07:36:56 -0400)
>>>
>>> 
>>> gvt-next-2022-04-21-for-christoph
>>>
>>> - Separating the MMIO table from GVT-g. (Zhi)
>>> - GVT-g re-factor. (Christoph)
>>> - GVT-g mdev API cleanup. (Jason)
>>> - GVT-g trace/makefile cleanup. (Jani)
>>>
>>> 
>>> Christoph Hellwig (27):
>>>   drm/i915/gvt: remove module refcounting in 
>>> intel_gvt_{,un}register_hypervisor
>>>   drm/i915/gvt: remove enum hypervisor_type
>>>   drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops
>>>   drm/i915/gvt: move the gvt code into kvmgt.ko
>>>   drm/i915/gvt: remove intel_gvt_ops
>>>   drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops
>>>   drm/i915/gvt: remove the unused from_virt_to_mfn op
>>>   drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu
>>>   drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu
>>>   drm/i915/gvt: remove vgpu->handle
>>>   drm/i915/gvt: devirtualize ->{read,write}_gpa
>>>   drm/i915/gvt: devirtualize ->{get,put}_vfio_device
>>>   drm/i915/gvt: devirtualize ->set_edid and ->set_opregion
>>>   drm/i915/gvt: devirtualize ->detach_vgpu
>>>   drm/i915/gvt: devirtualize ->inject_msi
>>>   drm/i915/gvt: devirtualize ->is_valid_gfn
>>>   drm/i915/gvt: devirtualize ->gfn_to_mfn
>>>   drm/i915/gvt: devirtualize ->{enable,disable}_page_track
>>>   drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page
>>>   drm/i915/gvt: devirtualize dma_pin_guest_page
>>>   drm/i915/gvt: remove struct intel_gvt_mpt
>>>   drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs
>>>   drm/i915/gvt: streamline intel_vgpu_create
>>>   drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers
>>>   drm/i915/gvt: remove kvmgt_guest_{init,exit}
>>>   drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev
>>>   drm/i915/gvt: merge gvt.c into kvmgvt.c
>>>
>>> Jani Nikula (2):
>>>   drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
>>>   drm/i915/gvt: better align the Makefile with i915 Makefile
>>>
>>> Jason Gunthorpe (5):
>>>   vfio/mdev: Remov

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for lrc selftest fixes (rev4)

2022-04-25 Thread Patchwork
== Series Details ==

Series: lrc selftest fixes (rev4)
URL   : https://patchwork.freedesktop.org/series/101353/
State : warning

== Summary ==

Error: dim checkpatch failed
9ad1d0f63dda drm/i915/gt: Explicitly clear BB_OFFSET for new contexts
14f50dc6662f drm/i915/selftests: Check for incomplete LRI from the context image
-:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#16: 
seen all the context registers by that point. (Mostly true for all gen so far,

total: 0 errors, 1 warnings, 0 checks, 121 lines checked
76d7986fb072 drm/i915/selftest: Always cancel semaphore on error
e77357d9ef83 drm/i915/selftest: Clear the output buffers before GPU writes




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for lrc selftest fixes (rev4)

2022-04-25 Thread Patchwork
== Series Details ==

Series: lrc selftest fixes (rev4)
URL   : https://patchwork.freedesktop.org/series/101353/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1391:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+./include/linux/find.h:40:31: warning: shift count is negative (-24)
+./include/linux/find.h:40:31: warning: shift count is negative (-24)
+./include/linux/find.h:40:31: warning: shift count is negative (-24)
+./include/linux/find.h:40:31: warning: shift count is negative (-24)
+./include/linux/find.h:40:31: warning: shift count is negative (-448)
+./include/linux/find.h:40:31: warning: shift count is negative (-448)
+./include/linux/spinlock.h:404:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:404:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:404:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:404:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:404:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:404:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:404:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block




Re: [Intel-gfx] [PATCH 03/15] dma-buf & drm/amdgpu: remove dma_resv workaround

2022-04-25 Thread Christian König

Am 20.04.22 um 21:28 schrieb Zack Rusin:

[SNIP]

To figure out what it is could you try the following code fragment:

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
index f46891012be3..a36f89d3f36d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
@@ -288,7 +288,7 @@ int vmw_validation_add_bo(struct
vmw_validation_context *ctx,
  val_buf->bo = ttm_bo_get_unless_zero(&vbo->base);
  if (!val_buf->bo)
  return -ESRCH;
-   val_buf->num_shared = 0;
+   val_buf->num_shared = 16;
  list_add_tail(&val_buf->head, &ctx->bo_list);
  bo_node->as_mob = as_mob;
  bo_node->cpu_blit = cpu_blit;

Fails the same BUG_ON with num_fences and max_fences == 0.


Thanks for testing this.

So the buffer object is not reserved through 
vmw_validation_bo_reserve(), but comes from somewhere else. 
Unfortunately I absolutely can't find where that's coming from.


Do you have some documentation howto setup vmwgfx? E.g. sample VM which 
I can download somewhere etc..


Thanks,
Christian.



z




Re: [Intel-gfx] [PATCH 3/9] vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages()

2022-04-25 Thread Tony Krowiak




On 4/12/22 11:53 AM, Jason Gunthorpe wrote:

Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle model.

Signed-off-by: Jason Gunthorpe 
---
  .../driver-api/vfio-mediated-device.rst   |  4 +-
  drivers/s390/cio/vfio_ccw_cp.c|  6 +--
  drivers/s390/crypto/vfio_ap_ops.c |  8 ++--
  drivers/vfio/vfio.c   | 40 ++-
  include/linux/vfio.h  |  4 +-
  5 files changed, 24 insertions(+), 38 deletions(-)

diff --git a/Documentation/driver-api/vfio-mediated-device.rst 
b/Documentation/driver-api/vfio-mediated-device.rst
index 9f26079cacae35..6aeca741dc9be1 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -279,10 +279,10 @@ Translation APIs for Mediated Devices
  The following APIs are provided for translating user pfn to host pfn in a VFIO
  driver::
  
-	extern int vfio_pin_pages(struct device *dev, unsigned long *user_pfn,

+   extern int vfio_pin_pages(struct vfio_device *vdev, unsigned long 
*user_pfn,
  int npage, int prot, unsigned long *phys_pfn);
  
-	extern int vfio_unpin_pages(struct device *dev, unsigned long *user_pfn,

+   extern int vfio_unpin_pages(struct vfio_device *vdev, unsigned long 
*user_pfn,
int npage);
  
  These functions call back into the back-end IOMMU module by using the pin_pages


diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
b/drivers/s390/crypto/vfio_ap_ops.c
index 69768061cd7bd9..a10b3369d76c41 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -124,7 +124,7 @@ static void vfio_ap_free_aqic_resources(struct 
vfio_ap_queue *q)
q->saved_isc = VFIO_AP_ISC_INVALID;
}
if (q->saved_pfn && !WARN_ON(!q->matrix_mdev)) {
-   vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
+   vfio_unpin_pages(&q->matrix_mdev->vdev,
 &q->saved_pfn, 1);
q->saved_pfn = 0;
}
@@ -258,7 +258,7 @@ static struct ap_queue_status vfio_ap_irq_enable(struct 
vfio_ap_queue *q,
return status;
}
  
-	ret = vfio_pin_pages(mdev_dev(q->matrix_mdev->mdev), &g_pfn, 1,

+   ret = vfio_pin_pages(&q->matrix_mdev->vdev, &g_pfn, 1,
 IOMMU_READ | IOMMU_WRITE, &h_pfn);
switch (ret) {
case 1:
@@ -301,7 +301,7 @@ static struct ap_queue_status vfio_ap_irq_enable(struct 
vfio_ap_queue *q,
break;
case AP_RESPONSE_OTHERWISE_CHANGED:
/* We could not modify IRQ setings: clear new configuration */
-   vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev), &g_pfn, 1);
+   vfio_unpin_pages(&q->matrix_mdev->vdev, &g_pfn, 1);
kvm_s390_gisc_unregister(kvm, isc);
break;
default:
@@ -1250,7 +1250,7 @@ static int vfio_ap_mdev_iommu_notifier(struct 
notifier_block *nb,
struct vfio_iommu_type1_dma_unmap *unmap = data;
unsigned long g_pfn = unmap->iova >> PAGE_SHIFT;
  
-		vfio_unpin_pages(mdev_dev(matrix_mdev->mdev), &g_pfn, 1);

+   vfio_unpin_pages(&matrix_mdev->vdev, &g_pfn, 1);
return NOTIFY_OK;
}


The vfio_ap snippet:
Reviewed-by: Tony Krowiak 

  





Re: [Intel-gfx] [PATCH 1/9] vfio: Make vfio_(un)register_notifier accept a vfio_device

2022-04-25 Thread Tony Krowiak




On 4/12/22 11:53 AM, Jason Gunthorpe wrote:

All callers have a struct vfio_device trivially available, pass it in
directly and avoid calling the expensive vfio_group_get_from_dev().

To support the unconverted kvmgt mdev driver add
mdev_legacy_get_vfio_device() which will return the vfio_device pointer
vfio_mdev.c puts in the drv_data.

Signed-off-by: Jason Gunthorpe 
---
  drivers/gpu/drm/i915/gvt/kvmgt.c  | 15 +--
  drivers/s390/cio/vfio_ccw_ops.c   |  7 +++
  drivers/s390/crypto/vfio_ap_ops.c | 14 +++---
  drivers/vfio/mdev/vfio_mdev.c | 12 
  drivers/vfio/vfio.c   | 25 +++--
  include/linux/mdev.h  |  1 +
  include/linux/vfio.h  |  4 ++--
  7 files changed, 41 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 057ec449010458..bb59d21cf898ab 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -904,6 +904,7 @@ static int intel_vgpu_group_notifier(struct notifier_block 
*nb,
  
  static int intel_vgpu_open_device(struct mdev_device *mdev)

  {
+   struct vfio_device *vfio_dev = mdev_legacy_get_vfio_device(mdev);
struct intel_vgpu *vgpu = mdev_get_drvdata(mdev);
struct kvmgt_vdev *vdev = kvmgt_vdev(vgpu);
unsigned long events;
@@ -914,7 +915,7 @@ static int intel_vgpu_open_device(struct mdev_device *mdev)
vdev->group_notifier.notifier_call = intel_vgpu_group_notifier;
  
  	events = VFIO_IOMMU_NOTIFY_DMA_UNMAP;

-   ret = vfio_register_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY, &events,
+   ret = vfio_register_notifier(vfio_dev, VFIO_IOMMU_NOTIFY, &events,
&vdev->iommu_notifier);
if (ret != 0) {
gvt_vgpu_err("vfio_register_notifier for iommu failed: %d\n",
@@ -923,7 +924,7 @@ static int intel_vgpu_open_device(struct mdev_device *mdev)
}
  
  	events = VFIO_GROUP_NOTIFY_SET_KVM;

-   ret = vfio_register_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY, &events,
+   ret = vfio_register_notifier(vfio_dev, VFIO_GROUP_NOTIFY, &events,
&vdev->group_notifier);
if (ret != 0) {
gvt_vgpu_err("vfio_register_notifier for group failed: %d\n",
@@ -961,11 +962,11 @@ static int intel_vgpu_open_device(struct mdev_device 
*mdev)
vdev->vfio_group = NULL;
  
  undo_register:

-   vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
+   vfio_unregister_notifier(vfio_dev, VFIO_GROUP_NOTIFY,
&vdev->group_notifier);
  
  undo_iommu:

-   vfio_unregister_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY,
+   vfio_unregister_notifier(vfio_dev, VFIO_IOMMU_NOTIFY,
&vdev->iommu_notifier);
  out:
return ret;
@@ -988,6 +989,7 @@ static void __intel_vgpu_release(struct intel_vgpu *vgpu)
struct kvmgt_vdev *vdev = kvmgt_vdev(vgpu);
struct drm_i915_private *i915 = vgpu->gvt->gt->i915;
struct kvmgt_guest_info *info;
+   struct vfio_device *vfio_dev;
int ret;
  
  	if (!handle_valid(vgpu->handle))

@@ -998,12 +1000,13 @@ static void __intel_vgpu_release(struct intel_vgpu *vgpu)
  
  	intel_gvt_ops->vgpu_release(vgpu);
  
-	ret = vfio_unregister_notifier(mdev_dev(vdev->mdev), VFIO_IOMMU_NOTIFY,

+   vfio_dev = mdev_legacy_get_vfio_device(vdev->mdev);
+   ret = vfio_unregister_notifier(vfio_dev, VFIO_IOMMU_NOTIFY,
&vdev->iommu_notifier);
drm_WARN(&i915->drm, ret,
 "vfio_unregister_notifier for iommu failed: %d\n", ret);
  
-	ret = vfio_unregister_notifier(mdev_dev(vdev->mdev), VFIO_GROUP_NOTIFY,

+   ret = vfio_unregister_notifier(vfio_dev, VFIO_GROUP_NOTIFY,
&vdev->group_notifier);
drm_WARN(&i915->drm, ret,
 "vfio_unregister_notifier for group failed: %d\n", ret);
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index d8589afac272f1..e1ce24d8fb2555 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -183,7 +183,7 @@ static int vfio_ccw_mdev_open_device(struct vfio_device 
*vdev)
  
  	private->nb.notifier_call = vfio_ccw_mdev_notifier;
  
-	ret = vfio_register_notifier(vdev->dev, VFIO_IOMMU_NOTIFY,

+   ret = vfio_register_notifier(vdev, VFIO_IOMMU_NOTIFY,
 &events, &private->nb);
if (ret)
return ret;
@@ -204,8 +204,7 @@ static int vfio_ccw_mdev_open_device(struct vfio_device 
*vdev)
  
  out_unregister:

vfio_ccw_unregister_dev_regions(private);
-   vfio_unregister_notifier(vdev->dev, VFIO_IOMMU_NOTIFY,
-&private->nb);
+   vfio_unregister_notifier(vdev, VFIO_IOMMU_NOTIFY, &private->nb);
return ret;
  }
  
@@ -223,7

[Intel-gfx] [PATCH v3 2/2] drm/msm/dp: Implement oob_hotplug_event()

2022-04-25 Thread Bjorn Andersson
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
oob_hotplug_event() callback, by amending the dp_hpd module with the
missing logic.

Overall the solution is similar to what's done downstream, but upstream
all the code to disect the HPD notification lives on the calling side of
drm_connector_oob_hotplug_event().

drm_connector_oob_hotplug_event() performs the lookup of the
drm_connector based on fwnode, hence the need to assign the fwnode in
dp_drm_connector_init().

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Rebased patch

 drivers/gpu/drm/msm/dp/dp_display.c |  9 +
 drivers/gpu/drm/msm/dp/dp_display.h |  3 +++
 drivers/gpu/drm/msm/dp/dp_drm.c | 11 +++
 drivers/gpu/drm/msm/dp/dp_hpd.c | 21 +
 drivers/gpu/drm/msm/dp/dp_hpd.h |  5 +
 5 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index a42732b67349..1019f6d8fd03 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -449,6 +449,14 @@ static int dp_display_usbpd_configure_cb(struct device 
*dev)
return dp_display_process_hpd_high(dp);
 }
 
+void dp_display_oob_hotplug_event(struct msm_dp *dp_display,
+ enum drm_connector_hpd_state hpd_state)
+{
+   struct dp_display_private *dp = container_of(dp_display, struct 
dp_display_private, dp_display);
+
+   dp->usbpd->oob_event(dp->usbpd, hpd_state);
+}
+
 static int dp_display_usbpd_disconnect_cb(struct device *dev)
 {
struct dp_display_private *dp = dev_get_dp_display_private(dev);
@@ -1302,6 +1310,7 @@ static int dp_display_probe(struct platform_device *pdev)
dp->pdev = pdev;
dp->name = "drm_dp";
dp->dp_display.connector_type = desc->connector_type;
+   dp->dp_display.dev = &pdev->dev;
 
rc = dp_init_sub_modules(dp);
if (rc) {
diff --git a/drivers/gpu/drm/msm/dp/dp_display.h 
b/drivers/gpu/drm/msm/dp/dp_display.h
index 7af2b186d2d9..16658270df2c 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.h
+++ b/drivers/gpu/drm/msm/dp/dp_display.h
@@ -11,6 +11,7 @@
 #include "disp/msm_disp_snapshot.h"
 
 struct msm_dp {
+   struct device *dev;
struct drm_device *drm_dev;
struct device *codec_dev;
struct drm_bridge *bridge;
@@ -40,5 +41,7 @@ bool dp_display_check_video_test(struct msm_dp *dp_display);
 int dp_display_get_test_bpp(struct msm_dp *dp_display);
 void dp_display_signal_audio_start(struct msm_dp *dp_display);
 void dp_display_signal_audio_complete(struct msm_dp *dp_display);
+void dp_display_oob_hotplug_event(struct msm_dp *dp_display,
+ enum drm_connector_hpd_state hpd_state);
 
 #endif /* _DP_DISPLAY_H_ */
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 80f59cf99089..76904b1601b1 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -123,6 +123,14 @@ static enum drm_mode_status dp_connector_mode_valid(
return dp_display_validate_mode(dp_disp, mode->clock);
 }
 
+static void dp_oob_hotplug_event(struct drm_connector *connector,
+enum drm_connector_hpd_state hpd_state)
+{
+   struct msm_dp *dp_disp = to_dp_connector(connector)->dp_display;
+
+   dp_display_oob_hotplug_event(dp_disp, hpd_state);
+}
+
 static const struct drm_connector_funcs dp_connector_funcs = {
.detect = dp_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -130,6 +138,7 @@ static const struct drm_connector_funcs dp_connector_funcs 
= {
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+   .oob_hotplug_event = dp_oob_hotplug_event,
 };
 
 static const struct drm_connector_helper_funcs dp_connector_helper_funcs = {
@@ -160,6 +169,8 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp 
*dp_display)
if (ret)
return ERR_PTR(ret);
 
+   connector->fwnode = fwnode_handle_get(dev_fwnode(dp_display->dev));
+
drm_connector_helper_add(connector, &dp_connector_helper_funcs);
 
/*
diff --git a/drivers/gpu/drm/msm/dp/dp_hpd.c b/drivers/gpu/drm/msm/dp/dp_hpd.c
index db98a1d431eb..cdb1feea5ebf 100644
--- a/drivers/gpu/drm/msm/dp/dp_hpd.c
+++ b/drivers/gpu/drm/msm/dp/dp_hpd.c
@@ -7,6 +7,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include "dp_hpd.h"
 
@@ -45,6 +47,24 @@ int dp_hpd_connect(struct dp_usbpd *dp_usbpd, bool hpd)
return rc;
 }
 
+static void dp_hpd_oob_event(struct dp_usbpd *dp_usbpd,
+enum drm_connector_hpd_state hpd_state)
+{
+   struct dp_hpd_private *hpd_priv

Re: [Intel-gfx] [PATCH 03/15] dma-buf & drm/amdgpu: remove dma_resv workaround

2022-04-25 Thread Christian König

Am 20.04.22 um 20:49 schrieb Christian König:

Am 20.04.22 um 20:41 schrieb Zack Rusin:

On Wed, 2022-04-20 at 19:40 +0200, Christian König wrote:

Am 20.04.22 um 19:38 schrieb Zack Rusin:

On Wed, 2022-04-20 at 09:37 +0200, Christian König wrote:

⚠ External Email

Hi Zack,

Am 20.04.22 um 05:56 schrieb Zack Rusin:

On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:

Rework the internals of the dma_resv object to allow adding
more
than
one
write fence and remember for each fence what purpose it had.

This allows removing the workaround from amdgpu which used a
container
for
this instead.

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org

afaict this change broke vmwgfx which now kernel oops right
after
boot.
I haven't had the time to look into it yet, so I'm not sure
what's
the
problem. I'll look at this tomorrow, but just in case you have
some
clues, the backtrace follows:

that's a known issue and should already be fixed with:

commit d72dcbe9fce505228dae43bef9da8f2b707d1b3d
Author: Christian König 
Date:   Mon Apr 11 15:21:59 2022 +0200

Unfortunately that doesn't seem to be it. The backtrace is from the
current (as of the time of sending of this email) drm-misc-next,
which
has this change, so it's something else.

Ok, that's strange. In this case I need to investigate further.

Maybe VMWGFX is adding more than one fence and we actually need to
reserve multiple slots.
This might be helper code issue with CONFIG_DEBUG_MUTEXES set. On 
that config

dma_resv_reset_max_fences does:
    fences->max_fences = fences->num_fences;
For some objects num_fences is 0 and so after max_fences and 
num_fences are both 0.

And then BUG_ON(num_fences >= max_fences) is triggered.


Yeah, but that's expected behavior.

What's not expected is that max_fences is still 0 (or equal to old 
num_fences) when VMWGFX tries to add a new fence. The function 
ttm_eu_reserve_buffers() should have reserved at least one fence slot.


So the underlying problem is that either ttm_eu_reserve_buffers() was 
never called or VMWGFX tried to add more than one fence.



To figure out what it is could you try the following code fragment:

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c

index f46891012be3..a36f89d3f36d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
@@ -288,7 +288,7 @@ int vmw_validation_add_bo(struct 
vmw_validation_context *ctx,

    val_buf->bo = ttm_bo_get_unless_zero(&vbo->base);
    if (!val_buf->bo)
    return -ESRCH;
-   val_buf->num_shared = 0;
+   val_buf->num_shared = 16;
    list_add_tail(&val_buf->head, &ctx->bo_list);
    bo_node->as_mob = as_mob;
    bo_node->cpu_blit = cpu_blit;

Thanks,
Christian.



Regards,
Christian.



z







Re: [Intel-gfx] [PATCH 1/9] vfio: Make vfio_(un)register_notifier accept a vfio_device

2022-04-25 Thread Eric Farman
On Tue, 2022-04-12 at 12:53 -0300, Jason Gunthorpe wrote:
> All callers have a struct vfio_device trivially available, pass it in
> directly and avoid calling the expensive vfio_group_get_from_dev().
> 
> To support the unconverted kvmgt mdev driver add
> mdev_legacy_get_vfio_device() which will return the vfio_device
> pointer
> vfio_mdev.c puts in the drv_data.
> 
> Signed-off-by: Jason Gunthorpe 
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c  | 15 +--
>  drivers/s390/cio/vfio_ccw_ops.c   |  7 +++
>  drivers/s390/crypto/vfio_ap_ops.c | 14 +++---
>  drivers/vfio/mdev/vfio_mdev.c | 12 
>  drivers/vfio/vfio.c   | 25 +++--
>  include/linux/mdev.h  |  1 +
>  include/linux/vfio.h  |  4 ++--
>  7 files changed, 41 insertions(+), 37 deletions(-)

For the -ccw bits:

Acked-by: Eric Farman 

> 
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 057ec449010458..bb59d21cf898ab 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -904,6 +904,7 @@ static int intel_vgpu_group_notifier(struct
> notifier_block *nb,
>  
>  static int intel_vgpu_open_device(struct mdev_device *mdev)
>  {
> + struct vfio_device *vfio_dev =
> mdev_legacy_get_vfio_device(mdev);
>   struct intel_vgpu *vgpu = mdev_get_drvdata(mdev);
>   struct kvmgt_vdev *vdev = kvmgt_vdev(vgpu);
>   unsigned long events;
> @@ -914,7 +915,7 @@ static int intel_vgpu_open_device(struct
> mdev_device *mdev)
>   vdev->group_notifier.notifier_call = intel_vgpu_group_notifier;
>  
>   events = VFIO_IOMMU_NOTIFY_DMA_UNMAP;
> - ret = vfio_register_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY,
> &events,
> + ret = vfio_register_notifier(vfio_dev, VFIO_IOMMU_NOTIFY,
> &events,
>   &vdev->iommu_notifier);
>   if (ret != 0) {
>   gvt_vgpu_err("vfio_register_notifier for iommu failed:
> %d\n",
> @@ -923,7 +924,7 @@ static int intel_vgpu_open_device(struct
> mdev_device *mdev)
>   }
>  
>   events = VFIO_GROUP_NOTIFY_SET_KVM;
> - ret = vfio_register_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
> &events,
> + ret = vfio_register_notifier(vfio_dev, VFIO_GROUP_NOTIFY,
> &events,
>   &vdev->group_notifier);
>   if (ret != 0) {
>   gvt_vgpu_err("vfio_register_notifier for group failed:
> %d\n",
> @@ -961,11 +962,11 @@ static int intel_vgpu_open_device(struct
> mdev_device *mdev)
>   vdev->vfio_group = NULL;
>  
>  undo_register:
> - vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
> + vfio_unregister_notifier(vfio_dev, VFIO_GROUP_NOTIFY,
>   &vdev->group_notifier);
>  
>  undo_iommu:
> - vfio_unregister_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY,
> + vfio_unregister_notifier(vfio_dev, VFIO_IOMMU_NOTIFY,
>   &vdev->iommu_notifier);
>  out:
>   return ret;
> @@ -988,6 +989,7 @@ static void __intel_vgpu_release(struct
> intel_vgpu *vgpu)
>   struct kvmgt_vdev *vdev = kvmgt_vdev(vgpu);
>   struct drm_i915_private *i915 = vgpu->gvt->gt->i915;
>   struct kvmgt_guest_info *info;
> + struct vfio_device *vfio_dev;
>   int ret;
>  
>   if (!handle_valid(vgpu->handle))
> @@ -998,12 +1000,13 @@ static void __intel_vgpu_release(struct
> intel_vgpu *vgpu)
>  
>   intel_gvt_ops->vgpu_release(vgpu);
>  
> - ret = vfio_unregister_notifier(mdev_dev(vdev->mdev),
> VFIO_IOMMU_NOTIFY,
> + vfio_dev = mdev_legacy_get_vfio_device(vdev->mdev);
> + ret = vfio_unregister_notifier(vfio_dev, VFIO_IOMMU_NOTIFY,
>   &vdev->iommu_notifier);
>   drm_WARN(&i915->drm, ret,
>"vfio_unregister_notifier for iommu failed: %d\n",
> ret);
>  
> - ret = vfio_unregister_notifier(mdev_dev(vdev->mdev),
> VFIO_GROUP_NOTIFY,
> + ret = vfio_unregister_notifier(vfio_dev, VFIO_GROUP_NOTIFY,
>   &vdev->group_notifier);
>   drm_WARN(&i915->drm, ret,
>"vfio_unregister_notifier for group failed: %d\n",
> ret);
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c
> b/drivers/s390/cio/vfio_ccw_ops.c
> index d8589afac272f1..e1ce24d8fb2555 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -183,7 +183,7 @@ static int vfio_ccw_mdev_open_device(struct
> vfio_device *vdev)
>  
>   private->nb.notifier_call = vfio_ccw_mdev_notifier;
>  
> - ret = vfio_register_notifier(vdev->dev, VFIO_IOMMU_NOTIFY,
> + ret = vfio_register_notifier(vdev, VFIO_IOMMU_NOTIFY,
>&events, &private->nb);
>   if (ret)
>   return ret;
> @@ -204,8 +204,7 @@ static int vfio_ccw_mdev_open_device(struct
> vfio_device *vdev)
>  
>  out_unregister:
>   vfio_ccw_unregister_dev_regions(private);
> - vfio_un

[Intel-gfx] [PATCH v3 1/2] drm: Add HPD state to drm_connector_oob_hotplug_event()

2022-04-25 Thread Bjorn Andersson
In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.

Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
state.

Also push the test for unchanged state in the displayport altmode driver
into the i915 driver, to allow other drivers to act upon each update.

Signed-off-by: Bjorn Andersson 
---

Changs since v2:
- The i915 cached hpd_state is tracked per encoder.

 drivers/gpu/drm/drm_connector.c  |  6 --
 drivers/gpu/drm/i915/display/intel_dp.c  | 17 ++---
 drivers/gpu/drm/i915/i915_drv.h  |  3 +++
 drivers/usb/typec/altmodes/displayport.c | 10 +++---
 include/drm/drm_connector.h  | 11 +--
 5 files changed, 33 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 76a8c707c34b..fff8c74d1ae6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2828,6 +2828,7 @@ struct drm_connector *drm_connector_find_by_fwnode(struct 
fwnode_handle *fwnode)
 /**
  * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to 
connector
  * @connector_fwnode: fwnode_handle to report the event on
+ * @hpd_state: hot plug detect logical state
  *
  * On some hardware a hotplug event notification may come from outside the 
display
  * driver / device. An example of this is some USB Type-C setups where the 
hardware
@@ -2837,7 +2838,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct 
fwnode_handle *fwnode)
  * This function can be used to report these out-of-band events after obtaining
  * a drm_connector reference through calling drm_connector_find_by_fwnode().
  */
-void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode)
+void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
+enum drm_connector_hpd_state hpd_state)
 {
struct drm_connector *connector;
 
@@ -2846,7 +2848,7 @@ void drm_connector_oob_hotplug_event(struct fwnode_handle 
*connector_fwnode)
return;
 
if (connector->funcs->oob_hotplug_event)
-   connector->funcs->oob_hotplug_event(connector);
+   connector->funcs->oob_hotplug_event(connector, hpd_state);
 
drm_connector_put(connector);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index d55acc4a028a..2907d8e1f80e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4950,15 +4950,26 @@ static int intel_dp_connector_atomic_check(struct 
drm_connector *conn,
return intel_modeset_synced_crtcs(state, conn);
 }
 
-static void intel_dp_oob_hotplug_event(struct drm_connector *connector)
+static void intel_dp_oob_hotplug_event(struct drm_connector *connector,
+  enum drm_connector_hpd_state hpd_state)
 {
struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
struct drm_i915_private *i915 = to_i915(connector->dev);
+   bool hpd_high = hpd_state == DRM_CONNECTOR_HPD_HIGH;
+   unsigned int hpd_pin = encoder->hpd_pin;
+   bool need_work = false;
 
spin_lock_irq(&i915->irq_lock);
-   i915->hotplug.event_bits |= BIT(encoder->hpd_pin);
+   if (hpd_high != test_bit(hpd_pin, 
&i915->hotplug.oob_hotplug_last_state)) {
+   i915->hotplug.event_bits |= BIT(hpd_pin);
+
+   __assign_bit(hpd_pin, &i915->hotplug.oob_hotplug_last_state, 
hpd_high);
+   need_work = true;
+   }
spin_unlock_irq(&i915->irq_lock);
-   queue_delayed_work(system_wq, &i915->hotplug.hotplug_work, 0);
+
+   if (need_work)
+   queue_delayed_work(system_wq, &i915->hotplug.hotplug_work, 0);
 }
 
 static const struct drm_connector_funcs intel_dp_connector_funcs = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3711d618a372..71d0c7130ddd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -134,6 +134,9 @@ struct i915_hotplug {
/* Whether or not to count short HPD IRQs in HPD storms */
u8 hpd_short_storm_enabled;
 
+   /* Last state reported by oob_hotplug_event for each encoder */
+   unsigned long oob_hotplug_last_state;
+
/*
 * if we get a HPD irq from DP and a HPD irq from non-DP
 * the non-DP HPD could block the workqueue on a mode config
diff --git a/drivers/usb/typec/altmodes/displayport.c 
b/drivers/usb/typec/altmodes/displayport.c
index c1d8c23baa39..ea9cb1d71fd2 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -59,7 +59,6 @@ struct dp_altmode {
struct typec_displayport_data data;
 
enum dp_state state;
-   bool hp

Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters

2022-04-25 Thread Kalle Valo
+ linux-wireless, netdev

Jani Nikula  writes:

> On Thu, 14 Apr 2022, Greg Kroah-Hartman  wrote:
>> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>>> Hey, I've sent this before, ages ago, but haven't really followed
>>> through with it. I still think it would be useful for many scenarios
>>> where a plain number is a clumsy interface for a module param.
>>> 
>>> Thoughts?
>>
>> We should not be adding new module parameters anyway (they operate on
>> code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
>
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.

Wireless drivers would also desperately need to pass device specific
parameters at (or before) probe time. And not only debug parameters but
also configuration parameters, for example firmware memory allocations
schemes (optimise for features vs number of clients etc) and whatnot.

Any ideas how to implement that? Is there any prior work for anything
like this? This is pretty hard limiting usability of upstream wireless
drivers and I really want to find a proper solution.


-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters

2022-04-25 Thread Ben Greear

On 4/19/22 10:13 PM, Kalle Valo wrote:

+ linux-wireless, netdev

Jani Nikula  writes:


On Thu, 14 Apr 2022, Greg Kroah-Hartman  wrote:

On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:

Hey, I've sent this before, ages ago, but haven't really followed
through with it. I still think it would be useful for many scenarios
where a plain number is a clumsy interface for a module param.

Thoughts?


We should not be adding new module parameters anyway (they operate on
code, not data/devices), so what would this be used for?


I think it's just easier to use names than random values, and this also
gives you range check on the input.

I also keep telling people not to add new module parameters, but it's
not like they're going away anytime soon.

If there's a solution to being able to pass device specific debug
parameters at probe time, I'm all ears. At least i915 has a bunch of
things which can't really be changed after probe, when debugfs for the
device is around. Module parameters aren't ideal, but debugfs doesn't
work for this.


Wireless drivers would also desperately need to pass device specific
parameters at (or before) probe time. And not only debug parameters but
also configuration parameters, for example firmware memory allocations
schemes (optimise for features vs number of clients etc) and whatnot.

Any ideas how to implement that? Is there any prior work for anything
like this? This is pretty hard limiting usability of upstream wireless
drivers and I really want to find a proper solution.


I used a 'fwcfg' file that is loaded during ath10k initialization, from
same general location as the firmware.  Name is with pci-id or other unique
identifier like board files sometimes are named, and you get per radio
configuration at device load time.  I'm sure I posted a patch on this
some years ago, but I can point you to my current tree if you prefer.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com



Re: [Intel-gfx] [PATCH 9/9] vfio: Remove calls to vfio_group_add_container_user()

2022-04-25 Thread Matthew Rosato

On 4/12/22 11:53 AM, Jason Gunthorpe wrote:

When the open_device() op is called the container_users is incremented and
held incremented until close_device(). Thus, so long as drivers call
functions within their open_device()/close_device() region they do not
need to worry about the container_users.

These functions can all only be called between
open_device()/close_device():

   vfio_pin_pages()
   vfio_unpin_pages()
   vfio_dma_rw()
   vfio_register_notifier()
   vfio_unregister_notifier()

So eliminate the calls to vfio_group_add_container_user() and add a simple
WARN_ON to detect mis-use by drivers.



vfio_device_fops_release decrements dev->open_count immediately before 
calling dev->ops->close_device, which means we could enter close_device 
with a dev_count of 0.


Maybe vfio_device_fops_release should handle the same way as 
vfio_group_get_device_fd?


if (device->open_count == 1 && device->ops->close_device)
device->ops->close_device(device);
device->open_count--;



Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters

2022-04-25 Thread Jakub Kicinski
On Wed, 20 Apr 2022 08:13:47 +0300 Kalle Valo wrote:
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
> 
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.

In netdev we have devlink which is used for all sort of device
configuration. devlink-resource sounds like what you need,
but it'd have to be extended to support configuration which requires
reload/re-probe. Currently only devlink-params support that but params
were a mistake so don't use that.


Re: [Intel-gfx] [PATCH 1/9] vfio: Make vfio_(un)register_notifier accept a vfio_device

2022-04-25 Thread Tony Krowiak




On 4/18/22 11:44 AM, Jason Gunthorpe wrote:

On Mon, Apr 18, 2022 at 11:28:30AM -0400, Tony Krowiak wrote:

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index a4555014bd1e72..8a5c46aa2bef61 100644
+++ b/drivers/vfio/vfio.c
@@ -2484,19 +2484,15 @@ static int vfio_unregister_group_notifier(struct 
vfio_group *group,
return ret;
   }
-int vfio_register_notifier(struct device *dev, enum vfio_notify_type type,
+int vfio_register_notifier(struct vfio_device *dev, enum vfio_notify_type type,
   unsigned long *events, struct notifier_block *nb)
   {
-   struct vfio_group *group;
+   struct vfio_group *group = dev->group;

Is there a guarantee that dev != NULL? The original code below checks
the value of dev, so why is that check eliminated here?

Yes, no kernel driver calls this with null dev. The original code
should have been a WARN_ON as it is just protecting against a buggy
driver. In this case if the driver is buggy we simply generate a
backtrace through a null deref panic.

Jason


Regarding the vfio_ap parts:
Reviewed-by: Tony Krowiak 




Re: [Intel-gfx] [PATCH 2/9] vfio/ccw: Remove mdev from struct channel_program

2022-04-25 Thread Eric Farman
On Tue, 2022-04-12 at 12:53 -0300, Jason Gunthorpe wrote:
> The next patch wants the vfio_device instead. There is no reason to
> store
> a pointer here since we can container_of back to the vfio_device.
> 
> Signed-off-by: Jason Gunthorpe 
> ---
>  drivers/s390/cio/vfio_ccw_cp.c  | 44 +++--
> 
>  drivers/s390/cio/vfio_ccw_cp.h  |  4 +--
>  drivers/s390/cio/vfio_ccw_fsm.c |  3 +--
>  3 files changed, 28 insertions(+), 23 deletions(-)

There's opportunity for simplification here, but I'll handle that when
I get to some other work in this space. For this series, this is fine.

Reviewed-by: Eric Farman 

> 
> diff --git a/drivers/s390/cio/vfio_ccw_cp.c
> b/drivers/s390/cio/vfio_ccw_cp.c
> index 8d1b2771c1aa02..af5048a1ba8894 100644
> --- a/drivers/s390/cio/vfio_ccw_cp.c
> +++ b/drivers/s390/cio/vfio_ccw_cp.c
> @@ -16,6 +16,7 @@
>  #include 
>  
>  #include "vfio_ccw_cp.h"
> +#include "vfio_ccw_private.h"
>  
>  struct pfn_array {
>   /* Starting guest physical I/O address. */
> @@ -98,17 +99,17 @@ static int pfn_array_alloc(struct pfn_array *pa,
> u64 iova, unsigned int len)
>   * If the pin request partially succeeds, or fails completely,
>   * all pages are left unpinned and a negative error value is
> returned.
>   */
> -static int pfn_array_pin(struct pfn_array *pa, struct device *mdev)
> +static int pfn_array_pin(struct pfn_array *pa, struct vfio_device
> *vdev)
>  {
>   int ret = 0;
>  
> - ret = vfio_pin_pages(mdev, pa->pa_iova_pfn, pa->pa_nr,
> + ret = vfio_pin_pages(vdev->dev, pa->pa_iova_pfn, pa->pa_nr,
>IOMMU_READ | IOMMU_WRITE, pa->pa_pfn);
>  
>   if (ret < 0) {
>   goto err_out;
>   } else if (ret > 0 && ret != pa->pa_nr) {
> - vfio_unpin_pages(mdev, pa->pa_iova_pfn, ret);
> + vfio_unpin_pages(vdev->dev, pa->pa_iova_pfn, ret);
>   ret = -EINVAL;
>   goto err_out;
>   }
> @@ -122,11 +123,11 @@ static int pfn_array_pin(struct pfn_array *pa,
> struct device *mdev)
>  }
>  
>  /* Unpin the pages before releasing the memory. */
> -static void pfn_array_unpin_free(struct pfn_array *pa, struct device
> *mdev)
> +static void pfn_array_unpin_free(struct pfn_array *pa, struct
> vfio_device *vdev)
>  {
>   /* Only unpin if any pages were pinned to begin with */
>   if (pa->pa_nr)
> - vfio_unpin_pages(mdev, pa->pa_iova_pfn, pa->pa_nr);
> + vfio_unpin_pages(vdev->dev, pa->pa_iova_pfn, pa-
> >pa_nr);
>   pa->pa_nr = 0;
>   kfree(pa->pa_iova_pfn);
>  }
> @@ -190,7 +191,7 @@ static void convert_ccw0_to_ccw1(struct ccw1
> *source, unsigned long len)
>   * Within the domain (@mdev), copy @n bytes from a guest physical
>   * address (@iova) to a host physical address (@to).
>   */
> -static long copy_from_iova(struct device *mdev,
> +static long copy_from_iova(struct vfio_device *vdev,
>  void *to, u64 iova,
>  unsigned long n)
>  {
> @@ -203,9 +204,9 @@ static long copy_from_iova(struct device *mdev,
>   if (ret < 0)
>   return ret;
>  
> - ret = pfn_array_pin(&pa, mdev);
> + ret = pfn_array_pin(&pa, vdev);
>   if (ret < 0) {
> - pfn_array_unpin_free(&pa, mdev);
> + pfn_array_unpin_free(&pa, vdev);
>   return ret;
>   }
>  
> @@ -226,7 +227,7 @@ static long copy_from_iova(struct device *mdev,
>   break;
>   }
>  
> - pfn_array_unpin_free(&pa, mdev);
> + pfn_array_unpin_free(&pa, vdev);
>  
>   return l;
>  }
> @@ -423,11 +424,13 @@ static int ccwchain_loop_tic(struct ccwchain
> *chain,
>  
>  static int ccwchain_handle_ccw(u32 cda, struct channel_program *cp)
>  {
> + struct vfio_device *vdev =
> + &container_of(cp, struct vfio_ccw_private, cp)->vdev;
>   struct ccwchain *chain;
>   int len, ret;
>  
>   /* Copy 2K (the most we support today) of possible CCWs */
> - len = copy_from_iova(cp->mdev, cp->guest_cp, cda,
> + len = copy_from_iova(vdev, cp->guest_cp, cda,
>CCWCHAIN_LEN_MAX * sizeof(struct ccw1));
>   if (len)
>   return len;
> @@ -508,6 +511,8 @@ static int ccwchain_fetch_direct(struct ccwchain
> *chain,
>int idx,
>struct channel_program *cp)
>  {
> + struct vfio_device *vdev =
> + &container_of(cp, struct vfio_ccw_private, cp)->vdev;
>   struct ccw1 *ccw;
>   struct pfn_array *pa;
>   u64 iova;
> @@ -526,7 +531,7 @@ static int ccwchain_fetch_direct(struct ccwchain
> *chain,
>   if (ccw_is_idal(ccw)) {
>   /* Read first IDAW to see if it's 4K-aligned or not. */
>   /* All subsequent IDAws will be 4K-aligned. */
> - ret = copy_from_iova(cp->mdev, &iova, ccw->cda,
> sizeof(iova));
> + ret = copy_from_iova(vdev, &iova, ccw->cda,
> sizeof(iova));
>   

Re: [Intel-gfx] [PATCH v3 2/2] drm/msm/dp: Implement oob_hotplug_event()

2022-04-25 Thread Bjorn Andersson
On Fri 22 Apr 16:07 PDT 2022, Dmitry Baryshkov wrote:
> On 23/04/2022 01:32, Bjorn Andersson wrote:
[..]
> > diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c 
> > b/drivers/gpu/drm/msm/dp/dp_drm.c
> > index 80f59cf99089..76904b1601b1 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_drm.c
> > @@ -123,6 +123,14 @@ static enum drm_mode_status dp_connector_mode_valid(
> > return dp_display_validate_mode(dp_disp, mode->clock);
> >   }
> > +static void dp_oob_hotplug_event(struct drm_connector *connector,
> > +enum drm_connector_hpd_state hpd_state)
> > +{
> > +   struct msm_dp *dp_disp = to_dp_connector(connector)->dp_display;
> > +
> > +   dp_display_oob_hotplug_event(dp_disp, hpd_state);
> > +}
> > +
> >   static const struct drm_connector_funcs dp_connector_funcs = {
> > .detect = dp_connector_detect,
> > .fill_modes = drm_helper_probe_single_connector_modes,
> > @@ -130,6 +138,7 @@ static const struct drm_connector_funcs 
> > dp_connector_funcs = {
> > .reset = drm_atomic_helper_connector_reset,
> > .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> > .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> > +   .oob_hotplug_event = dp_oob_hotplug_event,
> 
> We were (are) going to switch dp driver to use drm_bridge_connector (to fix
> support for bridge chains, eDP panels, etc.
> 
> So these changes must be ported to drm_bridge_connector (or we must
> abandon/defer the idea of using the bridge_connector).
> 
> For the oob_hotplug_event() callback proper support might be as simple as
> calling drm_bridge_connector_hpd_cb().
> 

Are you saying that you have code ready and being merged into linux-next
that I should redesign this on top of, or that you're planning to write
some code in the future and DisplayPort support have to wait until then?

> >   };
> >   static const struct drm_connector_helper_funcs dp_connector_helper_funcs 
> > = {
> > @@ -160,6 +169,8 @@ struct drm_connector *dp_drm_connector_init(struct 
> > msm_dp *dp_display)
> > if (ret)
> > return ERR_PTR(ret);
> > +   connector->fwnode = fwnode_handle_get(dev_fwnode(dp_display->dev));
> > +
> 
> This would be much more interesting. Supporting this in a generic way might
> be tricky. But we can still set the fwnode manually from the dp code.
> 

There's a slight mishmash here, because the device used to initialize
the connector is the drm_dev, but we need the actual fwnode of the DP
device associated with the connector.

So I think this is how it needs to be done.

Regards,
Bjorn


Re: [Intel-gfx] [PATCH 03/15] dma-buf & drm/amdgpu: remove dma_resv workaround

2022-04-25 Thread Christian König

Am 20.04.22 um 19:38 schrieb Zack Rusin:

On Wed, 2022-04-20 at 09:37 +0200, Christian König wrote:

⚠ External Email

Hi Zack,

Am 20.04.22 um 05:56 schrieb Zack Rusin:

On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:

Rework the internals of the dma_resv object to allow adding more
than
one
write fence and remember for each fence what purpose it had.

This allows removing the workaround from amdgpu which used a
container
for
this instead.

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org

afaict this change broke vmwgfx which now kernel oops right after
boot.
I haven't had the time to look into it yet, so I'm not sure what's
the
problem. I'll look at this tomorrow, but just in case you have some
clues, the backtrace follows:

that's a known issue and should already be fixed with:

commit d72dcbe9fce505228dae43bef9da8f2b707d1b3d
Author: Christian König 
Date:   Mon Apr 11 15:21:59 2022 +0200

Unfortunately that doesn't seem to be it. The backtrace is from the
current (as of the time of sending of this email) drm-misc-next, which
has this change, so it's something else.


Ok, that's strange. In this case I need to investigate further.

Maybe VMWGFX is adding more than one fence and we actually need to 
reserve multiple slots.


Regards,
Christian.



z




Re: [Intel-gfx] [PATCH 3/9] vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages()

2022-04-25 Thread Jason J. Herne

On 4/12/22 11:53, Jason Gunthorpe wrote:

Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle model.
...
diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
b/drivers/s390/crypto/vfio_ap_ops.c
index 69768061cd7bd9..a10b3369d76c41 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -124,7 +124,7 @@ static void vfio_ap_free_aqic_resources(struct 
vfio_ap_queue *q)
q->saved_isc = VFIO_AP_ISC_INVALID;
}
if (q->saved_pfn && !WARN_ON(!q->matrix_mdev)) {
-   vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
+   vfio_unpin_pages(&q->matrix_mdev->vdev,
 &q->saved_pfn, 1);


Could be contracted to a single line. If you feel like it :)


q->saved_pfn = 0;
}
@@ -258,7 +258,7 @@ static struct ap_queue_status vfio_ap_irq_enable(struct 
vfio_ap_queue *q,
return status;
}
  
-	ret = vfio_pin_pages(mdev_dev(q->matrix_mdev->mdev), &g_pfn, 1,

+   ret = vfio_pin_pages(&q->matrix_mdev->vdev, &g_pfn, 1,
 IOMMU_READ | IOMMU_WRITE, &h_pfn);
switch (ret) {
case 1:
@@ -301,7 +301,7 @@ static struct ap_queue_status vfio_ap_irq_enable(struct 
vfio_ap_queue *q,
break;
case AP_RESPONSE_OTHERWISE_CHANGED:
/* We could not modify IRQ setings: clear new configuration */
-   vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev), &g_pfn, 1);
+   vfio_unpin_pages(&q->matrix_mdev->vdev, &g_pfn, 1);
kvm_s390_gisc_unregister(kvm, isc);
break;
default:
@@ -1250,7 +1250,7 @@ static int vfio_ap_mdev_iommu_notifier(struct 
notifier_block *nb,
struct vfio_iommu_type1_dma_unmap *unmap = data;
unsigned long g_pfn = unmap->iova >> PAGE_SHIFT;
  
-		vfio_unpin_pages(mdev_dev(matrix_mdev->mdev), &g_pfn, 1);

+   vfio_unpin_pages(&matrix_mdev->vdev, &g_pfn, 1);
return NOTIFY_OK;
}
  


Looks good to me.
Reviewed-by: Jason J. Herne 

--
-- Jason J. Herne (jjhe...@linux.ibm.com)


Re: [Intel-gfx] [PATCH v5 09/10] arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller

2022-04-25 Thread Bjorn Andersson
On Mon 11 Apr 13:47 PDT 2022, Sean Paul wrote:

> From: Sean Paul 
> 
> This patch adds the register ranges required for HDCP key injection and
> HDCP TrustZone interaction as described in the dt-bindings for the
> sc7180 dp controller.

Can you please mention why this is only done for trogdor and not sc7180
as a whole?

> Now that these are supported, change the compatible string to
> "dp-hdcp".
> 

I don't see this change in the patch.

> Signed-off-by: Sean Paul 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s...@poorly.run
>  #v1
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-14-s...@poorly.run
>  #v2
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-14-s...@poorly.run
>  #v3
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-14-s...@poorly.run
>  #v4
> 
> Changes in v3:
> -Split off into a new patch containing just the dts change (Stephen)
> -Add hdcp compatible string (Stephen)
> Changes in v4:
> -Rebase on Bjorn's multi-dp patchset
> Changes in v5:
> -Put the tz register offsets in trogdor dtsi (Rob C)
> ---
>  arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 8 
>  arch/arm64/boot/dts/qcom/sc7180.dtsi | 6 +-
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi 
> b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> index 732e1181af48..c3559253aefc 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> @@ -815,6 +815,14 @@ &mdss_dp {
>   data-lanes = <0 1>;
>   vdda-1p2-supply = <&vdda_usb_ss_dp_1p2>;
>   vdda-0p9-supply = <&vdda_usb_ss_dp_core>;
> +
> + reg = <0 0x0ae9 0 0x200>,
> +   <0 0x0ae90200 0 0x200>,
> +   <0 0x0ae90400 0 0xc00>,
> +   <0 0x0ae91000 0 0x400>,
> +   <0 0x0ae91400 0 0x400>,
> +   <0 0x0aed1000 0 0x175>,
> +   <0 0x0aee1000 0 0x2c>;
>  };
>  
>  &pm6150_adc {
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index e1c46b80f14a..3c3eef7a7d52 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -3089,7 +3089,11 @@ mdss_dp: displayport-controller@ae9 {
>   compatible = "qcom,sc7180-dp";
>   status = "disabled";
>  
> - reg = <0 0x0ae9 0 0x1400>;
> + reg = <0 0x0ae9 0 0x200>,
> +   <0 0x0ae90200 0 0x200>,
> +   <0 0x0ae90400 0 0xc00>,
> +   <0 0x0ae91000 0 0x400>,
> +   <0 0x0ae91400 0 0x400>;

This hunk stands on its own, following the DT binding changes I did
earlier. Would you mind spinning it off so I can merge it separately?

Thanks,
Bjorn

>  
>   interrupt-parent = <&mdss>;
>   interrupts = <12>;
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS
> 


Re: [Intel-gfx] [PATCH 1/9] vfio: Make vfio_(un)register_notifier accept a vfio_device

2022-04-25 Thread Jason J. Herne

On 4/12/22 11:53, Jason Gunthorpe wrote:

All callers have a struct vfio_device trivially available, pass it in
directly and avoid calling the expensive vfio_group_get_from_dev().

To support the unconverted kvmgt mdev driver add
mdev_legacy_get_vfio_device() which will return the vfio_device pointer
vfio_mdev.c puts in the drv_data.

Signed-off-by: Jason Gunthorpe 
...
diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
b/drivers/s390/crypto/vfio_ap_ops.c
index 6e08d04b605d6e..69768061cd7bd9 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -1406,21 +1406,21 @@ static int vfio_ap_mdev_open_device(struct vfio_device 
*vdev)
matrix_mdev->group_notifier.notifier_call = vfio_ap_mdev_group_notifier;
events = VFIO_GROUP_NOTIFY_SET_KVM;
  
-	ret = vfio_register_notifier(vdev->dev, VFIO_GROUP_NOTIFY,

-&events, &matrix_mdev->group_notifier);
+   ret = vfio_register_notifier(vdev, VFIO_GROUP_NOTIFY, &events,
+&matrix_mdev->group_notifier);
if (ret)
return ret;
  
  	matrix_mdev->iommu_notifier.notifier_call = vfio_ap_mdev_iommu_notifier;

events = VFIO_IOMMU_NOTIFY_DMA_UNMAP;
-   ret = vfio_register_notifier(vdev->dev, VFIO_IOMMU_NOTIFY,
-&events, &matrix_mdev->iommu_notifier);
+   ret = vfio_register_notifier(vdev, VFIO_IOMMU_NOTIFY, &events,
+&matrix_mdev->iommu_notifier);
if (ret)
goto out_unregister_group;
return 0;
  
  out_unregister_group:

-   vfio_unregister_notifier(vdev->dev, VFIO_GROUP_NOTIFY,
+   vfio_unregister_notifier(vdev, VFIO_GROUP_NOTIFY,
 &matrix_mdev->group_notifier);
return ret;
  }
@@ -1430,9 +1430,9 @@ static void vfio_ap_mdev_close_device(struct vfio_device 
*vdev)
struct ap_matrix_mdev *matrix_mdev =
container_of(vdev, struct ap_matrix_mdev, vdev);
  
-	vfio_unregister_notifier(vdev->dev, VFIO_IOMMU_NOTIFY,

+   vfio_unregister_notifier(vdev, VFIO_IOMMU_NOTIFY,
 &matrix_mdev->iommu_notifier);
-   vfio_unregister_notifier(vdev->dev, VFIO_GROUP_NOTIFY,
+   vfio_unregister_notifier(vdev, VFIO_GROUP_NOTIFY,
 &matrix_mdev->group_notifier);
vfio_ap_mdev_unset_kvm(matrix_mdev);
  }

looks good for vfio_ap.
Reviewed-by: Jason J. Herne 


--
-- Jason J. Herne (jjhe...@linux.ibm.com)


Re: [Intel-gfx] [PATCH 3/9] vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages()

2022-04-25 Thread Eric Farman
On Tue, 2022-04-12 at 12:53 -0300, Jason Gunthorpe wrote:
> Every caller has a readily available vfio_device pointer, use that
> instead
> of passing in a generic struct device. The struct vfio_device already
> contains the group we need so this avoids complexity, extra
> refcountings,
> and a confusing lifecycle model.
> 
> Signed-off-by: Jason Gunthorpe 
> ---
>  .../driver-api/vfio-mediated-device.rst   |  4 +-
>  drivers/s390/cio/vfio_ccw_cp.c|  6 +--
>  drivers/s390/crypto/vfio_ap_ops.c |  8 ++--
>  drivers/vfio/vfio.c   | 40 ++---
> --
>  include/linux/vfio.h  |  4 +-
>  5 files changed, 24 insertions(+), 38 deletions(-)

For the -ccw bits:

Acked-by: Eric Farman 

> 
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> b/Documentation/driver-api/vfio-mediated-device.rst
> index 9f26079cacae35..6aeca741dc9be1 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -279,10 +279,10 @@ Translation APIs for Mediated Devices
>  The following APIs are provided for translating user pfn to host pfn
> in a VFIO
>  driver::
>  
> - extern int vfio_pin_pages(struct device *dev, unsigned long
> *user_pfn,
> + extern int vfio_pin_pages(struct vfio_device *vdev, unsigned
> long *user_pfn,
> int npage, int prot, unsigned long
> *phys_pfn);
>  
> - extern int vfio_unpin_pages(struct device *dev, unsigned long
> *user_pfn,
> + extern int vfio_unpin_pages(struct vfio_device *vdev, unsigned
> long *user_pfn,
>   int npage);
>  
>  These functions call back into the back-end IOMMU module by using
> the pin_pages
> diff --git a/drivers/s390/cio/vfio_ccw_cp.c
> b/drivers/s390/cio/vfio_ccw_cp.c
> index af5048a1ba8894..e362cb962a7234 100644
> --- a/drivers/s390/cio/vfio_ccw_cp.c
> +++ b/drivers/s390/cio/vfio_ccw_cp.c
> @@ -103,13 +103,13 @@ static int pfn_array_pin(struct pfn_array *pa,
> struct vfio_device *vdev)
>  {
>   int ret = 0;
>  
> - ret = vfio_pin_pages(vdev->dev, pa->pa_iova_pfn, pa->pa_nr,
> + ret = vfio_pin_pages(vdev, pa->pa_iova_pfn, pa->pa_nr,
>IOMMU_READ | IOMMU_WRITE, pa->pa_pfn);
>  
>   if (ret < 0) {
>   goto err_out;
>   } else if (ret > 0 && ret != pa->pa_nr) {
> - vfio_unpin_pages(vdev->dev, pa->pa_iova_pfn, ret);
> + vfio_unpin_pages(vdev, pa->pa_iova_pfn, ret);
>   ret = -EINVAL;
>   goto err_out;
>   }
> @@ -127,7 +127,7 @@ static void pfn_array_unpin_free(struct pfn_array
> *pa, struct vfio_device *vdev)
>  {
>   /* Only unpin if any pages were pinned to begin with */
>   if (pa->pa_nr)
> - vfio_unpin_pages(vdev->dev, pa->pa_iova_pfn, pa-
> >pa_nr);
> + vfio_unpin_pages(vdev, pa->pa_iova_pfn, pa->pa_nr);
>   pa->pa_nr = 0;
>   kfree(pa->pa_iova_pfn);
>  }
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index 69768061cd7bd9..a10b3369d76c41 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -124,7 +124,7 @@ static void vfio_ap_free_aqic_resources(struct
> vfio_ap_queue *q)
>   q->saved_isc = VFIO_AP_ISC_INVALID;
>   }
>   if (q->saved_pfn && !WARN_ON(!q->matrix_mdev)) {
> - vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
> + vfio_unpin_pages(&q->matrix_mdev->vdev,
>&q->saved_pfn, 1);
>   q->saved_pfn = 0;
>   }
> @@ -258,7 +258,7 @@ static struct ap_queue_status
> vfio_ap_irq_enable(struct vfio_ap_queue *q,
>   return status;
>   }
>  
> - ret = vfio_pin_pages(mdev_dev(q->matrix_mdev->mdev), &g_pfn, 1,
> + ret = vfio_pin_pages(&q->matrix_mdev->vdev, &g_pfn, 1,
>IOMMU_READ | IOMMU_WRITE, &h_pfn);
>   switch (ret) {
>   case 1:
> @@ -301,7 +301,7 @@ static struct ap_queue_status
> vfio_ap_irq_enable(struct vfio_ap_queue *q,
>   break;
>   case AP_RESPONSE_OTHERWISE_CHANGED:
>   /* We could not modify IRQ setings: clear new
> configuration */
> - vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
> &g_pfn, 1);
> + vfio_unpin_pages(&q->matrix_mdev->vdev, &g_pfn, 1);
>   kvm_s390_gisc_unregister(kvm, isc);
>   break;
>   default:
> @@ -1250,7 +1250,7 @@ static int vfio_ap_mdev_iommu_notifier(struct
> notifier_block *nb,
>   struct vfio_iommu_type1_dma_unmap *unmap = data;
>   unsigned long g_pfn = unmap->iova >> PAGE_SHIFT;
>  
> - vfio_unpin_pages(mdev_dev(matrix_mdev->mdev), &g_pfn,
> 1);
> + vfio_unpin_pages(&matrix_mdev->vdev, &g_pfn, 1);
>   return NOTIFY_OK;
>   }
>  
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfi

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [01/15] dma-buf: add enum dma_resv_usage v4 (rev2)

2022-04-25 Thread Patchwork
== Series Details ==

Series: series starting with [01/15] dma-buf: add enum dma_resv_usage v4 (rev2)
URL   : https://patchwork.freedesktop.org/series/102340/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/102340/revisions/2/mbox/ not 
applied
Applying: dma-buf: add enum dma_resv_usage v4
Using index info to reconstruct a base tree...
M   drivers/dma-buf/dma-buf.c
M   drivers/dma-buf/dma-resv.c
M   drivers/dma-buf/st-dma-resv.c
M   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
M   drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
M   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
M   drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
M   drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
M   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
M   drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
M   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
M   drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
M   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
M   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
M   drivers/gpu/drm/drm_gem.c
M   drivers/gpu/drm/drm_gem_atomic_helper.c
M   drivers/gpu/drm/etnaviv/etnaviv_gem.c
M   drivers/gpu/drm/i915/display/intel_atomic_plane.c
M   drivers/gpu/drm/i915/gem/i915_gem_busy.c
M   drivers/gpu/drm/i915/gem/i915_gem_lmem.c
M   drivers/gpu/drm/i915/gem/i915_gem_userptr.c
M   drivers/gpu/drm/i915/gem/i915_gem_wait.c
M   drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
M   drivers/gpu/drm/i915/i915_request.c
M   drivers/gpu/drm/i915/i915_sw_fence.c
M   drivers/gpu/drm/msm/msm_gem.c
M   drivers/gpu/drm/nouveau/dispnv50/wndw.c
M   drivers/gpu/drm/nouveau/nouveau_bo.c
M   drivers/gpu/drm/nouveau/nouveau_fence.c
M   drivers/gpu/drm/nouveau/nouveau_gem.c
M   drivers/gpu/drm/panfrost/panfrost_drv.c
M   drivers/gpu/drm/qxl/qxl_debugfs.c
M   drivers/gpu/drm/radeon/radeon_display.c
M   drivers/gpu/drm/radeon/radeon_gem.c
M   drivers/gpu/drm/radeon/radeon_mn.c
M   drivers/gpu/drm/radeon/radeon_sync.c
M   drivers/gpu/drm/radeon/radeon_uvd.c
M   drivers/gpu/drm/scheduler/sched_main.c
M   drivers/gpu/drm/ttm/ttm_bo.c
M   drivers/gpu/drm/vgem/vgem_fence.c
M   drivers/gpu/drm/virtio/virtgpu_ioctl.c
M   drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
M   drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
M   drivers/infiniband/core/umem_dmabuf.c
M   include/linux/dma-buf.h
M   include/linux/dma-resv.h
Falling back to patching base and 3-way merge...
Auto-merging include/linux/dma-resv.h
CONFLICT (content): Merge conflict in include/linux/dma-resv.h
Auto-merging include/linux/dma-buf.h
Auto-merging drivers/infiniband/core/umem_dmabuf.c
CONFLICT (content): Merge conflict in drivers/infiniband/core/umem_dmabuf.c
Auto-merging drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
Auto-merging drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
Auto-merging drivers/gpu/drm/vgem/vgem_fence.c
Auto-merging drivers/gpu/drm/ttm/ttm_bo.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/ttm/ttm_bo.c
Auto-merging drivers/gpu/drm/radeon/radeon_uvd.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/radeon/radeon_uvd.c
Auto-merging drivers/gpu/drm/radeon/radeon_sync.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/radeon/radeon_sync.c
Auto-merging drivers/gpu/drm/radeon/radeon_mn.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/radeon/radeon_mn.c
Auto-merging drivers/gpu/drm/radeon/radeon_gem.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/radeon/radeon_gem.c
Auto-merging drivers/gpu/drm/qxl/qxl_debugfs.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/qxl/qxl_debugfs.c
Auto-merging drivers/gpu/drm/nouveau/nouveau_fence.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/nouveau/nouveau_fence.c
Auto-merging drivers/gpu/drm/nouveau/nouveau_bo.c
Auto-merging drivers/gpu/drm/msm/msm_gem.c
Auto-merging drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
Auto-merging drivers/gpu/drm/i915/gem/i915_gem_userptr.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/gem/i915_gem_userptr.c
Auto-merging drivers/gpu/drm/i915/gem/i915_gem_lmem.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_lmem.c
Auto-merging drivers/gpu/drm/i915/gem/i915_gem_busy.c
Auto-merging drivers/gpu/drm/i915/display/intel_atomic_plane.c
Auto-merging drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/amdgpu

[Intel-gfx] ✗ Fi.CI.BAT: failure for lrc selftest fixes (rev4)

2022-04-25 Thread Patchwork
== Series Details ==

Series: lrc selftest fixes (rev4)
URL   : https://patchwork.freedesktop.org/series/101353/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_101353v4


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_101353v4 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_101353v4, 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_101353v4/index.html

Participating hosts (43 -> 45)
--

  Additional (3): bat-dg2-8 bat-adlm-1 bat-dg1-6 
  Missing(1): fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_lrc:
- fi-bsw-n3050:   [PASS][2] -> [DMESG-FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
- fi-bsw-kefka:   [PASS][4] -> [DMESG-FAIL][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-kefka/igt@i915_selftest@live@gt_lrc.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/fi-bsw-kefka/igt@i915_selftest@live@gt_lrc.html
- fi-bsw-nick:[PASS][6] -> [DMESG-FAIL][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-nick/igt@i915_selftest@live@gt_lrc.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/fi-bsw-nick/igt@i915_selftest@live@gt_lrc.html
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][8]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/fi-bdw-5557u/igt@i915_selftest@live@gt_lrc.html

  
 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {bat-rpls-1}:   NOTRUN -> [INCOMPLETE][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- {bat-adlm-1}:   NOTRUN -> [DMESG-WARN][10]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/bat-adlm-1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][11] ([i915#3921])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-blb-e6850:   [PASS][12] -> [DMESG-FAIL][13] ([i915#4528])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-blb-e6850/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/fi-blb-e6850/igt@i915_selftest@l...@requests.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u:   NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-bdw-5557u:   NOTRUN -> [SKIP][15] ([fdo#109271]) +14 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/fi-bdw-5557u/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@runner@aborted:
- fi-blb-e6850:   NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#2403] / 
[i915#4312])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/fi-blb-e6850/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][17] ([i915#5334]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v4/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_lrc:
- {fi-tgl-dsi}:   [DMESG-FAIL][19] ([i915#2373]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/2] drm: Add HPD state to drm_connector_oob_hotplug_event()

2022-04-25 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/2] drm: Add HPD state to 
drm_connector_oob_hotplug_event()
URL   : https://patchwork.freedesktop.org/series/103078/
State : warning

== Summary ==

Error: dim checkpatch failed
f2ad7f841168 drm: Add HPD state to drm_connector_oob_hotplug_event()
-:118: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#118: FILE: drivers/usb/typec/altmodes/displayport.c:146:
+   hpd ? DRM_CONNECTOR_HPD_HIGH : 
DRM_CONNECTOR_HPD_LOW);

total: 0 errors, 1 warnings, 0 checks, 119 lines checked
26f3d1dccc50 drm/msm/dp: Implement oob_hotplug_event()
-:33: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#33: FILE: drivers/gpu/drm/msm/dp/dp_display.c:455:
+   struct dp_display_private *dp = container_of(dp_display, struct 
dp_display_private, dp_display);

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




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/2] drm: Add HPD state to drm_connector_oob_hotplug_event()

2022-04-25 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/2] drm: Add HPD state to 
drm_connector_oob_hotplug_event()
URL   : https://patchwork.freedesktop.org/series/103078/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/2] drm: Add HPD state to drm_connector_oob_hotplug_event()

2022-04-25 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/2] drm: Add HPD state to 
drm_connector_oob_hotplug_event()
URL   : https://patchwork.freedesktop.org/series/103078/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103078v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_103078v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_103078v1, 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_103078v1/index.html

Participating hosts (43 -> 44)
--

  Additional (2): bat-dg2-8 bat-dg1-6 
  Missing(1): fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103078v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  
 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {bat-rpls-1}:   NOTRUN -> [INCOMPLETE][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103078v1/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [PASS][3] -> [INCOMPLETE][4] ([i915#4785])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103078v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

  * igt@runner@aborted:
- fi-hsw-g3258:   NOTRUN -> [FAIL][5] ([fdo#109271] / [i915#4312])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103078v1/fi-hsw-g3258/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][6] ([i915#5334]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103078v1/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][8] ([i915#4785]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103078v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-1}:   [DMESG-WARN][10] ([i915#5278]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@hugepages.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103078v1/bat-rpls-1/igt@i915_selftest@l...@hugepages.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-1}:   [DMESG-FAIL][12] ([i915#4983]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103078v1/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@kms_busy@basic@flip:
- {bat-adlp-6}:   [DMESG-WARN][14] ([i915#3576]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-adlp-6/igt@kms_busy@ba...@flip.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103078v1/bat-adlp-6/igt@kms_busy@ba...@flip.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
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.o

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm: Add infrastructure to allow seamless mode switches (rev2)

2022-04-25 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm: Add infrastructure to allow seamless 
mode switches (rev2)
URL   : https://patchwork.freedesktop.org/series/102958/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must b

Re: [Intel-gfx] [PATCH 1/2] drm/i915/xehp: Add compute engine ABI

2022-04-25 Thread Andi Shyti
Hi Matt,

On Fri, Apr 22, 2022 at 12:50:06PM -0700, Matt Roper wrote:
> We're now ready to start exposing compute engines to userspace.
> 
> While we're at it, let's extend the kerneldoc description for the other
> engine types as well.

I would make two different patches. The kerneldoc description is
the biggest part of the lines added here.

Andi

> 
> Cc: Daniele Ceraolo Spurio 
> Cc: Tvrtko Ursulin 
> Cc: Vinay Belgaumkar 
> Cc: Jordan Justen 
> Cc: Szymon Morek 
> UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14395
> UMD (compute): https://github.com/intel/compute-runtime/pull/451
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/gt/intel_engine_user.c |  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt.c  |  1 +
>  drivers/gpu/drm/i915/i915_drm_client.c  |  1 +
>  drivers/gpu/drm/i915/i915_drm_client.h  |  2 +-
>  include/uapi/drm/i915_drm.h | 62 +++--
>  5 files changed, 60 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 0f6cd96b459f..46a174f8aa00 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -47,7 +47,7 @@ static const u8 uabi_classes[] = {
>   [COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY,
>   [VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
>   [VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
> - /* TODO: Add COMPUTE_CLASS mapping once ABI is available */
> + [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
>  };
>  
>  static int engine_cmp(void *priv, const struct list_head *A,
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 92394f13b42f..c96e123496a5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -1175,6 +1175,7 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
>   [VIDEO_DECODE_CLASS]= GEN12_VD_TLB_INV_CR,
>   [VIDEO_ENHANCEMENT_CLASS]   = GEN12_VE_TLB_INV_CR,
>   [COPY_ENGINE_CLASS] = GEN12_BLT_TLB_INV_CR,
> + [COMPUTE_CLASS] = GEN12_GFX_TLB_INV_CR,
>   };
>   struct drm_i915_private *i915 = gt->i915;
>   struct intel_uncore *uncore = gt->uncore;
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
> b/drivers/gpu/drm/i915/i915_drm_client.c
> index 475a6f824cad..18d38cb59923 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -81,6 +81,7 @@ static const char * const uabi_class_names[] = {
>   [I915_ENGINE_CLASS_COPY] = "copy",
>   [I915_ENGINE_CLASS_VIDEO] = "video",
>   [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "video-enhance",
> + [I915_ENGINE_CLASS_COMPUTE] = "compute",
>  };
>  
>  static u64 busy_add(struct i915_gem_context *ctx, unsigned int class)
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.h 
> b/drivers/gpu/drm/i915/i915_drm_client.h
> index 5f5b02b01ba0..f796c5e8e060 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.h
> +++ b/drivers/gpu/drm/i915/i915_drm_client.h
> @@ -13,7 +13,7 @@
>  
>  #include "gt/intel_engine_types.h"
>  
> -#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_VIDEO_ENHANCE
> +#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_COMPUTE
>  
>  struct drm_i915_private;
>  
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 35ca528803fd..a2def7b27009 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -154,21 +154,71 @@ enum i915_mocs_table_index {
>   I915_MOCS_CACHED,
>  };
>  
> -/*
> +/**
> + * enum drm_i915_gem_engine_class - uapi engine type enumeration
> + *
>   * Different engines serve different roles, and there may be more than one
> - * engine serving each role. enum drm_i915_gem_engine_class provides a
> - * classification of the role of the engine, which may be used when 
> requesting
> - * operations to be performed on a certain subset of engines, or for 
> providing
> - * information about that group.
> + * engine serving each role.  This enum provides a classification of the role
> + * of the engine, which may be used when requesting operations to be 
> performed
> + * on a certain subset of engines, or for providing information about that
> + * group.
>   */
>  enum drm_i915_gem_engine_class {
> + /**
> +  * @I915_ENGINE_CLASS_RENDER:
> +  *
> +  * Render engines support instructions used for 3D, Compute (GPGPU),
> +  * and programmable media workloads.  These instructions fetch data and
> +  * dispatch individual work items to threads that operate in parallel.
> +  * The threads run small programs (called "kernels" or "shaders") on
> +  * the GPU's execution units (EUs).
> +  */
>   I915_ENGINE_CLASS_RENDER= 0,
> +
> + /**
> +  * @I915_ENGINE_CLASS_COPY:
> +  *
> +  * 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Xe_HP SDV and DG2 have up to 4 CCS engines

2022-04-25 Thread Andi Shyti
On Fri, Apr 22, 2022 at 12:50:07PM -0700, Matt Roper wrote:
> From: Daniele Ceraolo Spurio 
> 
> Cc: Vinay Belgaumkar 
> Signed-off-by: Daniele Ceraolo Spurio 
> Signed-off-by: Matt Roper 
> Reviewed-by: Matt Roper 

Reviewed-by: Andi Shyti 

Andi


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm: Add infrastructure to allow seamless mode switches (rev2)

2022-04-25 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm: Add infrastructure to allow seamless 
mode switches (rev2)
URL   : https://patchwork.freedesktop.org/series/102958/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_102958v2


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102958v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102958v2, 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_102958v2/index.html

Participating hosts (43 -> 44)
--

  Additional (2): bat-dg2-8 bat-dg1-6 
  Missing(1): fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#3282])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#3012])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([fdo#111827]) +8 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#4070] / [i915#4103]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([fdo#109285] / [i915#4098])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#4070] / [i915#533])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#1072]) +3 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#3555] / [i915#4098])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#3301] / [i915#3708])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  * igt@prime_vgem@basic-write:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([i915#3291] / [i915#3708]) +2 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@prime_v...@basic-write.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   [INCOMPLETE][14] ([i915#5127]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102958v2/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][16] ([i915#5334]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [17]: 
https://intel-gfx-ci.01.org/tree

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses

2022-04-25 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses
URL   : https://patchwork.freedesktop.org/series/102941/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11537_full -> Patchwork_102941v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### CI changes ###

 Possible regressions 

  * boot:
- shard-iclb: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], 
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], 
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[PASS][48], [FAIL][49], [PASS][50])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb8/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb8/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb7/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb7/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb7/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb6/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb6/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb6/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb5/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb5/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb5/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb4/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb3/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/shard-iclb1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb7/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb6/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb6/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb6/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb5/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb5/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb5/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb4/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/shard-iclb4/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Pat

[Intel-gfx] [PATCH 1/3] drm/i915/xehpsdv/dg1/tgl: Fix issue with LRI relative addressing

2022-04-25 Thread Ramalingam C
From: Akeem G Abodunrin 

When bit 19 of MI_LOAD_REGISTER_IMM instruction opcode is set on tgl+
devices, HW does not care about certain register address offsets, but
instead check the following for valid address ranges on specific engines:
RCS && CCS: BITS(0 - 10)
BCS: BITS(0 - 11)
VECS && VCS: BITS(0 - 13)
Also, tgl+ now support relative addressing for BCS engine - So, this
patch fixes issue with live_gt_lrc selftest that is failing where there is
mismatch between LRC register layout generated during init and HW
default register offsets.

Signed-off-by: Akeem G Abodunrin 
cc: Prathap Kumar Valsan 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/selftest_lrc.c | 36 +-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 6ba52ef1acb8..8dc7b88cdca0 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -128,6 +128,27 @@ static int context_flush(struct intel_context *ce, long 
timeout)
return err;
 }
 
+static int get_lri_mask(struct intel_engine_cs *engine, u32 lri)
+{
+   if ((lri & MI_LRI_LRM_CS_MMIO) == 0)
+   return ~0u;
+
+   if (GRAPHICS_VER(engine->i915) < 12)
+   return 0xfff;
+
+   switch (engine->class) {
+   default:
+   case RENDER_CLASS:
+   case COMPUTE_CLASS:
+   return 0x07ff;
+   case COPY_ENGINE_CLASS:
+   return 0x0fff;
+   case VIDEO_DECODE_CLASS:
+   case VIDEO_ENHANCEMENT_CLASS:
+   return 0x3fff;
+   }
+}
+
 static int live_lrc_layout(void *arg)
 {
struct intel_gt *gt = arg;
@@ -167,6 +188,7 @@ static int live_lrc_layout(void *arg)
dw = 0;
do {
u32 lri = READ_ONCE(hw[dw]);
+   u32 lri_mask;
 
if (lri == 0) {
dw++;
@@ -194,6 +216,18 @@ static int live_lrc_layout(void *arg)
break;
}
 
+   /*
+* When bit 19 of MI_LOAD_REGISTER_IMM instruction
+* opcode is set on Gen12+ devices, HW does not
+* care about certain register address offsets, and
+* instead check the following for valid address
+* ranges on specific engines:
+* RCS && CCS: BITS(0 - 10)
+* BCS: BITS(0 - 11)
+* VECS && VCS: BITS(0 - 13)
+*/
+   lri_mask = get_lri_mask(engine, lri);
+
lri &= 0x7f;
lri++;
dw++;
@@ -201,7 +235,7 @@ static int live_lrc_layout(void *arg)
while (lri) {
u32 offset = READ_ONCE(hw[dw]);
 
-   if (offset != lrc[dw]) {
+   if ((offset ^ lrc[dw]) & lri_mask) {
pr_err("%s: Different registers found 
at dword %d, expected %x, found %x\n",
   engine->name, dw, offset, 
lrc[dw]);
err = -EINVAL;
-- 
2.20.1



[Intel-gfx] [PATCH 0/3] Handle predicate programming

2022-04-25 Thread Ramalingam C
Userspace can leave SET_PREDICATE_RESULT active at the end of their
batch, causing all the kernel operations from the ring to be noop'ed.
This includes workarounds for memory corruption on dg2, as well as the
usual synchronisation, arbitration, coherency and signaling. The latter
can be used to cause system-wide hangs, prevent TLB invalidates, as
well as runtime-pm leakage due to a never signaled fence which escapes
hangcheck as the context does run.

To avoid the issues caused by allowing userspace to disable kernel
execution, we explicitly clear SET_PREDICATE_RESULT but not before
recording whether predication was active. By tracking if predication was
active at the end of the batch, we can restore it immediately prior to
executing the users next batch, preserving the status of the user's
predication.

And also LRI relative addressing is fixed as part of this series.

Akeem G Abodunrin (1):
  drm/i915/xehpsdv/dg1/tgl: Fix issue with LRI relative addressing

Chris Wilson (2):
  drm/i915/selftests: Skip poisoning SET_PREDICATE_RESULT on dg2
  drm/i915/gt: Clear SET_PREDICATE_RESULT prior to executing the ring

 drivers/gpu/drm/i915/gt/gen8_engine_cs.c  | 54 +
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h  |  7 ++
 drivers/gpu/drm/i915/gt/intel_engine_regs.h   |  2 +
 .../drm/i915/gt/intel_execlists_submission.c  | 15 +++-
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  2 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 75 ++-
 drivers/gpu/drm/i915/gt/intel_lrc.h   |  5 ++
 drivers/gpu/drm/i915/gt/selftest_lrc.c| 53 -
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  2 +
 9 files changed, 189 insertions(+), 26 deletions(-)

-- 
2.20.1



[Intel-gfx] [PATCH 2/3] drm/i915/selftests: Skip poisoning SET_PREDICATE_RESULT on dg2

2022-04-25 Thread Ramalingam C
From: Chris Wilson 

When predication is enabled all commands baring a few (such as MI_BB_END)
are nop'ed. If we accidentally enable predication while poisoning the
context, not only is the rest of the poisoning skipped (thus disabling
the test), but the closing instructions of the poison request are
nop'ed. Not only do we then not signal the waiting context, but we even
prevent re-enabling arbitration and the GPU will not perform a context
switch at the end of the request.

Cc: Joonas Lahtinen 
Suggested-by: CQ Tang 
Signed-off-by: Chris Wilson 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_engine_regs.h |  1 +
 drivers/gpu/drm/i915/gt/selftest_lrc.c  | 17 -
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 594a629cb28f..1dab554bf640 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -193,6 +193,7 @@
 #define RING_TIMESTAMP_UDW(base)   _MMIO((base) + 0x358 + 4)
 #define RING_CONTEXT_STATUS_PTR(base)  _MMIO((base) + 0x3a0)
 #define RING_CTX_TIMESTAMP(base)   _MMIO((base) + 0x3a8) /* gen8+ 
*/
+#define RING_PREDICATE_RESULT(base)_MMIO((base) + 0x3b8)
 #define RING_FORCE_TO_NONPRIV(base, i) _MMIO(((base) + 0x4D0) + (i) * 
4)
 #define   RING_FORCE_TO_NONPRIV_ADDRESS_MASK   REG_GENMASK(25, 2)
 #define   RING_FORCE_TO_NONPRIV_ACCESS_RW  (0 << 28)/* CFL+ & Gen11+ */
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 8dc7b88cdca0..8b2c11dbe354 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -945,6 +945,19 @@ create_user_vma(struct i915_address_space *vm, unsigned 
long size)
return vma;
 }
 
+static u32 safe_poison(u32 offset, u32 poison)
+{
+   /*
+* Do not enable predication as it will nop all subsequent commands,
+* not only disabling the tests (by preventing all the other SRM) but
+* also preventing the arbitration events at the end of the request.
+*/
+   if (offset == i915_mmio_reg_offset(RING_PREDICATE_RESULT(0)))
+   poison &= ~REG_BIT(0);
+
+   return poison;
+}
+
 static struct i915_vma *
 store_context(struct intel_context *ce, struct i915_vma *scratch)
 {
@@ -1154,7 +1167,9 @@ static struct i915_vma *load_context(struct intel_context 
*ce, u32 poison)
*cs++ = MI_LOAD_REGISTER_IMM(len);
while (len--) {
*cs++ = hw[dw];
-   *cs++ = poison;
+   *cs++ = safe_poison(hw[dw] & get_lri_mask(ce->engine,
+ 
MI_LRI_LRM_CS_MMIO),
+   poison);
dw += 2;
}
} while (dw < PAGE_SIZE / sizeof(u32) &&
-- 
2.20.1



[Intel-gfx] [PATCH 3/3] drm/i915/gt: Clear SET_PREDICATE_RESULT prior to executing the ring

2022-04-25 Thread Ramalingam C
From: Chris Wilson 

Userspace may leave predication enabled upon return from the batch
buffer, which has the consequent of preventing all operation from the
ring from being executed, including all the synchronisation, coherency
control, arbitration and user signaling. This is more than just a local
gpu hang in one client, as the user has the ability to prevent the
kernel from applying critical workarounds and can cause a full GT reset.

We could simply execute MI_SET_PREDICATE upon return from the user
batch, but this has the repercussion of modifying the user's context
state. Instead, we opt to execute a fixup batch which by mixing
predicated operations can determine the state of the
SET_PREDICATE_RESULT register and restore it prior to the next userspace
batch. This allows us to protect the kernel's ring without changing the
uABI.

Suggested-by: Zbigniew Kempczynski 
Signed-off-by: Chris Wilson 
Cc: Zbigniew Kempczynski 
Cc: Thomas Hellstrom 
Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c  | 54 +
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h  |  7 ++
 drivers/gpu/drm/i915/gt/intel_engine_regs.h   |  1 +
 .../drm/i915/gt/intel_execlists_submission.c  | 15 +++-
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  2 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 75 ++-
 drivers/gpu/drm/i915/gt/intel_lrc.h   |  5 ++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  2 +
 8 files changed, 137 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 9529c5455bc3..3e13960615bd 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -5,6 +5,7 @@
 
 #include "gen8_engine_cs.h"
 #include "i915_drv.h"
+#include "intel_engine_regs.h"
 #include "intel_gpu_commands.h"
 #include "intel_lrc.h"
 #include "intel_ring.h"
@@ -385,6 +386,59 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq)
return 0;
 }
 
+static int __gen125_emit_bb_start(struct i915_request *rq,
+ u64 offset, u32 len,
+ const unsigned int flags,
+ u32 arb)
+{
+   struct intel_context *ce = rq->context;
+   u32 wa_offset = lrc_indirect_bb(ce);
+   u32 *cs;
+
+   cs = intel_ring_begin(rq, 12);
+   if (IS_ERR(cs))
+   return PTR_ERR(cs);
+
+   *cs++ = MI_ARB_ON_OFF | arb;
+
+   *cs++ = MI_LOAD_REGISTER_MEM_GEN8 |
+   MI_SRM_LRM_GLOBAL_GTT |
+   MI_LRI_LRM_CS_MMIO;
+   *cs++ = i915_mmio_reg_offset(RING_PREDICATE_RESULT(0));
+   *cs++ = wa_offset + DG2_PREDICATE_RESULT_WA;
+   *cs++ = 0;
+
+   *cs++ = MI_BATCH_BUFFER_START_GEN8 |
+   (flags & I915_DISPATCH_SECURE ? 0 : BIT(8));
+   *cs++ = lower_32_bits(offset);
+   *cs++ = upper_32_bits(offset);
+
+   /* Fixup stray MI_SET_PREDICATE as it prevents us executing the ring */
+   *cs++ = MI_BATCH_BUFFER_START_GEN8;
+   *cs++ = wa_offset + DG2_PREDICATE_RESULT_BB;
+   *cs++ = 0;
+
+   *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
+
+   intel_ring_advance(rq, cs);
+
+   return 0;
+}
+
+int gen125_emit_bb_start_noarb(struct i915_request *rq,
+  u64 offset, u32 len,
+  const unsigned int flags)
+{
+   return __gen125_emit_bb_start(rq, offset, len, flags, MI_ARB_DISABLE);
+}
+
+int gen125_emit_bb_start(struct i915_request *rq,
+u64 offset, u32 len,
+const unsigned int flags)
+{
+   return __gen125_emit_bb_start(rq, offset, len, flags, MI_ARB_ENABLE);
+}
+
 int gen8_emit_bb_start_noarb(struct i915_request *rq,
 u64 offset, u32 len,
 const unsigned int flags)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index 107ab42539ab..32e3d2b831bb 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -31,6 +31,13 @@ int gen8_emit_bb_start(struct i915_request *rq,
   u64 offset, u32 len,
   const unsigned int flags);
 
+int gen125_emit_bb_start_noarb(struct i915_request *rq,
+  u64 offset, u32 len,
+  const unsigned int flags);
+int gen125_emit_bb_start(struct i915_request *rq,
+u64 offset, u32 len,
+const unsigned int flags);
+
 u32 *gen8_emit_fini_breadcrumb_xcs(struct i915_request *rq, u32 *cs);
 u32 *gen12_emit_fini_breadcrumb_xcs(struct i915_request *rq, u32 *cs);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 1dab554bf640..75a0c55c5aa5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_re

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses

2022-04-25 Thread Vudum, Lakshminarayana
I see bat results went through successfully.
But on shards, there is a boot failure from ICL, where I am unable to load the 
result page(html).

Lakshmi.

-Original Message-
From: Deak, Imre  
Sent: Friday, April 22, 2022 2:39 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana 

Subject: Re: ✗ Fi.CI.BAT: failure for drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) 
register addresses

Hi Lakshmi,

On Thu, Apr 21, 2022 at 09:08:29PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses
> URL   : https://patchwork.freedesktop.org/series/102941/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11537 -> Patchwork_102941v1 
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_102941v1 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_102941v1, 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_102941v1/index.html
> 
> Participating hosts (45 -> 45)
> --
> 
>   Additional (2): fi-bdw-gvtdvm fi-bdw-5557u 
>   Missing(2): fi-bsw-cyan fi-icl-u2 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_102941v1:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@i915_selftest@live@gem:
> - fi-tgl-1115g4:  [PASS][1] -> [DMESG-WARN][2] +15 similar issues
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/fi-tgl-1115g4/igt@i915_selftest@l...@gem.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-tgl-111
> 5g4/igt@i915_selftest@l...@gem.html

This is
"i915 :00:02.0: [drm] *ERROR* power well AUX_TBT4 state mismatch (refcount 
1/enabled 0)"

tracked at
https://gitlab.freedesktop.org/drm/intel/-/issues/2867

The issue is unrelated to the change, since fi-tgl-111g4 doesn't have an eDP 
panel.

For 2867 I will follow up with a patch to change the error to a debug message, 
since TBT power wells are expected to stay disabled on a disconnected port.

> Known issues
> 
> 
>   Here are the changes found in Patchwork_102941v1 that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@fbdev@write:
> - fi-bdw-gvtdvm:  NOTRUN -> [SKIP][3] ([fdo#109271]) +5 similar issues
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-bdw-gvt
> dvm/igt@fb...@write.html
> 
>   * igt@gem_exec_suspend@basic-s0@smem:
> - fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][4] ([i915#4831])
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-bdw-gvt
> dvm/igt@gem_exec_suspend@basic...@smem.html
> 
>   * igt@i915_selftest@live@execlists:
> - fi-bsw-n3050:   [PASS][5] -> [INCOMPLETE][6] ([i915#2940])
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-bsw-n30
> 50/igt@i915_selftest@l...@execlists.html
> 
>   * igt@i915_selftest@live@gt_engines:
> - bat-dg1-6:  [PASS][7] -> [INCOMPLETE][8] ([i915#4418])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/bat-dg1-6/
> igt@i915_selftest@live@gt_engines.html
> 
>   * igt@i915_selftest@live@hangcheck:
> - fi-hsw-g3258:   [PASS][9] -> [INCOMPLETE][10] ([i915#4785])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/fi-hsw-g32
> 58/igt@i915_selftest@l...@hangcheck.html
> 
>   * igt@i915_selftest@live@slpc:
> - bat-dg1-5:  [PASS][11] -> [INCOMPLETE][12] ([i915#5198])
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-dg1-5/igt@i915_selftest@l...@slpc.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/bat-dg1-5/
> igt@i915_selftest@l...@slpc.html
> 
>   * igt@kms_flip@basic-flip-vs-modeset@b-edp1:
> - bat-adlp-4: [PASS][13] -> [DMESG-WARN][14] ([i915#3576]) +1 
> similar issue
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11537/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102941v1/bat-adlp-4
> /igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
> 
>   * igt@runner@aborted:
> - fi-bdw-5557u:   NOTRUN -> [FAIL][15] ([i915#4312])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patc

[Intel-gfx] [PATCH] drm/i915: remove superfluous string helper include

2022-04-25 Thread Jani Nikula
Remove the duplicate and incorrect (uses "" instead of <>)
linux/string_helpers.h include.

Fixes: cc1338f259a2 ("drm/i915/xehp: Update topology dumps for Xe_HP")
Cc: Matt Roper 
Cc: Lucas De Marchi 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/gt/intel_sseu.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c 
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 9881a6790574..fdd25691beda 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -10,8 +10,6 @@
 #include "intel_gt_regs.h"
 #include "intel_sseu.h"
 
-#include "linux/string_helpers.h"
-
 void intel_sseu_set_info(struct sseu_dev_info *sseu, u8 max_slices,
 u8 max_subslices, u8 max_eus_per_subslice)
 {
-- 
2.30.2



[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/4] drm/i915: consider min_page_size when migrating

2022-04-25 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915: consider min_page_size when 
migrating
URL   : https://patchwork.freedesktop.org/series/102879/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11528_full -> Patchwork_102879v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 11)
--

  Additional (1): shard-tglu 

Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([FAIL][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24], [PASS][25]) ([i915#4386]) -> ([PASS][26], [PASS][27], [PASS][28], 
[PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], 
[PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], 
[PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], 
[PASS][47], [PASS][48], [PASS][49], [PASS][50])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl1/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl1/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl2/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl2/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl2/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl3/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl3/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl3/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl3/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl4/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl4/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl6/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl6/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl6/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl7/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl7/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl8/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl8/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl7/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl7/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl6/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl6/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl6/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl4/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl4/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl4/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl4/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl3/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl3/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl3/boot.html
   [43]: 
https://intel-gfx-ci.01.org/tree/d

[Intel-gfx] [PATCH v2 0/4] Flat-CCS eviction enhancements

2022-04-25 Thread Ramalingam C
Flat-CCS eviction enhancements

v2: Correcting the memory residency requirement for flat-ccs capability
[Thomas]

Ramalingam C (4):
  drm/i915/gt: GEM_BUG_ON unexpected NULL at scatterlist walking
  drm/i915/gt: optimize the ccs_sz calculation per chunk
  drm/i915/gt: Document the eviction of the Flat-CCS objects
  uapi/drm/i915: Document memory residency and Flat-CCS capability of
obj

 drivers/gpu/drm/i915/gt/intel_migrate.c | 65 -
 include/uapi/drm/i915_drm.h | 18 +++
 2 files changed, 50 insertions(+), 33 deletions(-)

-- 
2.20.1



[Intel-gfx] [PATCH v2 2/4] drm/i915/gt: optimize the ccs_sz calculation per chunk

2022-04-25 Thread Ramalingam C
Calculate the ccs_sz that needs to be emitted based on the src
and dst pages emitted per chunk. And handle the return value of emit_pte
for the ccs pages.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 36 +
 1 file changed, 12 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 29d761da02c4..463a6a14b5f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -647,17 +647,9 @@ static int scatter_list_length(struct scatterlist *sg)
 
 static void
 calculate_chunk_sz(struct drm_i915_private *i915, bool src_is_lmem,
-  int *src_sz, int *ccs_sz, u32 bytes_to_cpy,
-  u32 ccs_bytes_to_cpy)
+  int *src_sz, u32 bytes_to_cpy, u32 ccs_bytes_to_cpy)
 {
if (ccs_bytes_to_cpy) {
-   /*
-* We can only copy the ccs data corresponding to
-* the CHUNK_SZ of lmem which is
-* GET_CCS_BYTES(i915, CHUNK_SZ))
-*/
-   *ccs_sz = min_t(int, ccs_bytes_to_cpy, GET_CCS_BYTES(i915, 
CHUNK_SZ));
-
if (!src_is_lmem)
/*
 * When CHUNK_SZ is passed all the pages upto CHUNK_SZ
@@ -713,10 +705,10 @@ intel_context_migrate_copy(struct intel_context *ce,
struct drm_i915_private *i915 = ce->engine->i915;
u32 ccs_bytes_to_cpy = 0, bytes_to_cpy;
enum i915_cache_level ccs_cache_level;
-   int src_sz, dst_sz, ccs_sz;
u32 src_offset, dst_offset;
u8 src_access, dst_access;
struct i915_request *rq;
+   int src_sz, dst_sz;
bool ccs_is_src;
int err;
 
@@ -770,7 +762,7 @@ intel_context_migrate_copy(struct intel_context *ce,
}
 
do {
-   int len;
+   int len, ccs_sz;
 
rq = i915_request_create(ce);
if (IS_ERR(rq)) {
@@ -797,7 +789,7 @@ intel_context_migrate_copy(struct intel_context *ce,
if (err)
goto out_rq;
 
-   calculate_chunk_sz(i915, src_is_lmem, &src_sz, &ccs_sz,
+   calculate_chunk_sz(i915, src_is_lmem, &src_sz,
   bytes_to_cpy, ccs_bytes_to_cpy);
 
len = emit_pte(rq, &it_src, src_cache_level, src_is_lmem,
@@ -835,33 +827,29 @@ intel_context_migrate_copy(struct intel_context *ce,
if (err)
goto out_rq;
 
+   ccs_sz = GET_CCS_BYTES(i915, len);
err = emit_pte(rq, &it_ccs, ccs_cache_level, false,
   ccs_is_src ? src_offset : dst_offset,
   ccs_sz);
+   if (err < 0)
+   goto out_rq;
+   if (err < ccs_sz) {
+   err = -EINVAL;
+   goto out_rq;
+   }
 
err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
if (err)
goto out_rq;
 
-   /*
-* Using max of src_sz and dst_sz, as we need to
-* pass the lmem size corresponding to the ccs
-* blocks we need to handle.
-*/
-   ccs_sz = max_t(int, ccs_is_src ? ccs_sz : src_sz,
-  ccs_is_src ? dst_sz : ccs_sz);
-
err = emit_copy_ccs(rq, dst_offset, dst_access,
-   src_offset, src_access, ccs_sz);
+   src_offset, src_access, len);
if (err)
goto out_rq;
 
err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
if (err)
goto out_rq;
-
-   /* Converting back to ccs bytes */
-   ccs_sz = GET_CCS_BYTES(rq->engine->i915, ccs_sz);
ccs_bytes_to_cpy -= ccs_sz;
}
 
-- 
2.20.1



[Intel-gfx] [PATCH v2 3/4] drm/i915/gt: Document the eviction of the Flat-CCS objects

2022-04-25 Thread Ramalingam C
Capture the eviction details for Flat-CCS capable, lmem objects.

v2:
  Fix the Flat-ccs capbility of lmem obj with smem residency
  possibility [Thomas]

Signed-off-by: Ramalingam C 
cc: Thomas Hellstrom 
cc: Matthew Auld 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 463a6a14b5f9..930e0fd9795f 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -485,16 +485,21 @@ static bool wa_1209644611_applies(int ver, u32 size)
  * And CCS data can be copied in and out of CCS region through
  * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
  *
- * When we exhaust the lmem, if the object's placements support smem, then we 
can
- * directly decompress the compressed lmem object into smem and start using it
- * from smem itself.
+ * I915 supports Flat-CCS on lmem only objects. When an objects has the smem in
+ * its preference list, on memory pressure, i915 needs to migarte the lmem
+ * content into smem. If the lmem object is Flat-CCS compressed by userspace,
+ * then i915 needs to decompress it. But I915 lack the required information
+ * for such decompression. Hence I915 supports Flat-CCS only on lmem only 
objects.
  *
- * But when we need to swapout the compressed lmem object into a smem region
- * though objects' placement doesn't support smem, then we copy the lmem 
content
- * as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).
- * When the object is referred, lmem content will be swaped in along with
- * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
- * location.
+ * when we exhaust the lmem, Flat-CCS capable objects' lmem backing memory can
+ * be temporarily evicted to smem, along with the auxiliary CCS state, where
+ * it can be potentially swapped-out at a later point, if required.
+ * If userspace later touches the evicted pages, then we always move
+ * the backing memory back to lmem, which includes restoring the saved CCS 
state,
+ * and potentially performing any required swap-in.
+ *
+ * For the migration of the lmem objects with smem in placement list, such as
+ * {lmem, smem}, objects are treated as non Flat-CCS capable objects.
  */
 
 static inline u32 *i915_flush_dw(u32 *cmd, u32 flags)
-- 
2.20.1



[Intel-gfx] [PATCH v2 1/4] drm/i915/gt: GEM_BUG_ON unexpected NULL at scatterlist walking

2022-04-25 Thread Ramalingam C
While locating the start of ccs scatterlist in smem scatterlist, that has
to be the size of lmem obj size + corresponding ccs data size. Report bug
if scatterlist terminate before that length.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 9d552f30b627..29d761da02c4 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -687,6 +687,12 @@ static void get_ccs_sg_sgt(struct sgt_dma *it, u32 
bytes_to_cpy)
bytes_to_cpy -= len;
 
it->sg = __sg_next(it->sg);
+
+   /*
+* scatterlist supposed to be the size of
+* bytes_to_cpy + GET_CCS_BYTES(bytes_to_copy).
+*/
+   GEM_BUG_ON(!it->sg);
it->dma = sg_dma_address(it->sg);
it->max = it->dma + sg_dma_len(it->sg);
} while (bytes_to_cpy);
-- 
2.20.1



[Intel-gfx] [PATCH v2 4/4] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj

2022-04-25 Thread Ramalingam C
Capture the impact of memory region preference list of an object, on
their memory residency and Flat-CCS capability of the objects.

v2:
  Fix the Flat-CCS capability of an obj with {lmem, smem} preference
  list [Thomas]

Signed-off-by: Ramalingam C 
cc: Matthew Auld 
cc: Thomas Hellstrom 
---
 include/uapi/drm/i915_drm.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 35ca528803fd..ad191ed6547c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3393,6 +3393,24 @@ struct drm_i915_gem_create_ext {
  * At which point we get the object handle in &drm_i915_gem_create_ext.handle,
  * along with the final object size in &drm_i915_gem_create_ext.size, which
  * should account for any rounding up, if required.
+ *
+ * Objects with multiple memory regions in the preference list will be backed
+ * by one of the memory regions mentioned in the preference list. Though I915
+ * tries to honour the order of the memory regions in the preference list,
+ * based on the memory pressure of the regions, objects' backing region
+ * will be selected.
+ *
+ * Userspace has no means of knowing the backing region for such objects.
+ *
+ * On Flat-CCS capable HW, compression is supported for the objects residing
+ * in I915_MEMORY_CLASS_DEVICE. When such objects (compressed) has other
+ * memory class in preference list and migrated (by I915, due to memory
+ * constrain) to the non I915_MEMORY_CLASS_DEVICE region, then I915 needs to
+ * decompress the content. But I915 dont have the required information to
+ * decompress the userspace compressed objects.
+ *
+ * So I915 supports Flat-CCS, only on the objects which can reside only on
+ * I915_MEMORY_CLASS_DEVICE regions.
  */
 struct drm_i915_gem_create_ext_memory_regions {
/** @base: Extension link. See struct i915_user_extension. */
-- 
2.20.1



[Intel-gfx] ✗ Fi.CI.BAT: failure for Handle predicate programming

2022-04-25 Thread Patchwork
== Series Details ==

Series: Handle predicate programming
URL   : https://patchwork.freedesktop.org/series/103084/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103084v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_103084v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_103084v1, 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_103084v1/index.html

Participating hosts (43 -> 42)
--

  Additional (2): bat-dg2-8 bat-dg1-6 
  Missing(3): fi-kbl-soraka fi-hsw-4770 fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  
 Suppressed 

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

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   [DMESG-WARN][2] ([i915#4391]) -> [WARN][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-2/igt@i915_pm_...@module-reload.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-rpls-2/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@client:
- {bat-dg2-8}:NOTRUN -> [DMESG-FAIL][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-dg2-8/igt@i915_selftest@l...@client.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- {bat-dg2-8}:NOTRUN -> [SKIP][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-dg2-8/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][6] -> [INCOMPLETE][7] ([i915#146])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][8] ([i915#5334]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_lrc:
- {bat-dg2-9}:[INCOMPLETE][10] ([i915#5270]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-dg2-9/igt@i915_selftest@live@gt_lrc.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-dg2-9/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@sanitycheck:
- {bat-rpls-2}:   [INCOMPLETE][12] ([i915#5401]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-2/igt@i915_selftest@l...@sanitycheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-rpls-2/igt@i915_selftest@l...@sanitycheck.html

  * igt@kms_busy@basic@flip:
- {bat-adlp-6}:   [DMESG-WARN][14] ([i915#3576]) -> [PASS][15] +1 
similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-adlp-6/igt@kms_busy@ba...@flip.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/bat-adlp-6/igt@kms_busy@ba...@flip.html

  
 Warnings 

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-7567u:   [SKIP][16] ([fdo#109271] / [i915#5341]) -> [SKIP][17] 
([fdo#109271])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-pnv-d510:[SKIP][18] ([fdo#109271] / [i915#5341]) -> [SKIP][19] 
([fdo#109271])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103084v1/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-snb-2520m:   [SKIP][20] ([fdo#109271] / [i915#5341]) -> [SKIP][21] 
([fdo#109271])
  

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Flat-CCS eviction enhancements (rev3)

2022-04-25 Thread Patchwork
== Series Details ==

Series: Flat-CCS eviction enhancements (rev3)
URL   : https://patchwork.freedesktop.org/series/102916/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: remove superfluous string helper include

2022-04-25 Thread Patchwork
== Series Details ==

Series: drm/i915: remove superfluous string helper include
URL   : https://patchwork.freedesktop.org/series/103086/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103086v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_103086v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_103086v1, 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_103086v1/index.html

Participating hosts (43 -> 43)
--

  Additional (3): bat-dg2-8 bat-adlm-1 bat-dg1-6 
  Missing(3): fi-kbl-soraka fi-bsw-cyan bat-jsl-2 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  
 Suppressed 

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- {bat-dg2-8}:NOTRUN -> [SKIP][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v1/bat-dg2-8/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][3] -> [INCOMPLETE][4] ([i915#146])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v1/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][5] ([i915#5334]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v1/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][7] ([i915#4785]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-1}:   [DMESG-WARN][9] ([i915#5278]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@hugepages.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v1/bat-rpls-1/igt@i915_selftest@l...@hugepages.html

  * igt@kms_busy@basic@modeset:
- {bat-adlp-6}:   [DMESG-WARN][11] ([i915#3576]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-adlp-6/igt@kms_busy@ba...@modeset.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v1/bat-adlp-6/igt@kms_busy@ba...@modeset.html

  
 Warnings 

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-7567u:   [SKIP][13] ([fdo#109271] / [i915#5341]) -> [SKIP][14] 
([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v1/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-pnv-d510:[SKIP][15] ([fdo#109271] / [i915#5341]) -> [SKIP][16] 
([fdo#109271])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v1/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-snb-2520m:   [SKIP][17] ([fdo#109271] / [i915#5341]) -> [SKIP][18] 
([fdo#109271])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-snb-2520m/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v1/fi-snb-2520m/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-bsw-kefka:   [SKIP][19] ([fdo#109271] / [i915#5341]) -> [SKIP][20] 
([fdo#109271])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-kefka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

Re: [Intel-gfx] [PATCH 1/2] drm/i915/xehp: Add compute engine ABI

2022-04-25 Thread Matt Roper
On Mon, Apr 25, 2022 at 11:41:36AM +0100, Tvrtko Ursulin wrote:
> 
> On 22/04/2022 20:50, Matt Roper wrote:
> > We're now ready to start exposing compute engines to userspace.
> > 
> > While we're at it, let's extend the kerneldoc description for the other
> > engine types as well.
> > 
> > Cc: Daniele Ceraolo Spurio 
> > Cc: Tvrtko Ursulin 
> > Cc: Vinay Belgaumkar 
> > Cc: Jordan Justen 
> > Cc: Szymon Morek 
> > UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14395
> > UMD (compute): https://github.com/intel/compute-runtime/pull/451
> 
> The compute one points to a commit named "Add compute engine class for xehp"
> but content of which seems more about engine query, including the yet
> non-existent distance query (and more)?! I certainly does not appear to be
> adding a definition of I915_ENGINE_CLASS_COMPUTE. This needs clarifying.
> 
> > Signed-off-by: Matt Roper 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_engine_user.c |  2 +-
> >   drivers/gpu/drm/i915/gt/intel_gt.c  |  1 +
> >   drivers/gpu/drm/i915/i915_drm_client.c  |  1 +
> >   drivers/gpu/drm/i915/i915_drm_client.h  |  2 +-
> >   include/uapi/drm/i915_drm.h | 62 +++--
> >   5 files changed, 60 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
> > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > index 0f6cd96b459f..46a174f8aa00 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > @@ -47,7 +47,7 @@ static const u8 uabi_classes[] = {
> > [COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY,
> > [VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
> > [VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
> > -   /* TODO: Add COMPUTE_CLASS mapping once ABI is available */
> > +   [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
> >   };
> >   static int engine_cmp(void *priv, const struct list_head *A,
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > index 92394f13b42f..c96e123496a5 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -1175,6 +1175,7 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
> > [VIDEO_DECODE_CLASS]= GEN12_VD_TLB_INV_CR,
> > [VIDEO_ENHANCEMENT_CLASS]   = GEN12_VE_TLB_INV_CR,
> > [COPY_ENGINE_CLASS] = GEN12_BLT_TLB_INV_CR,
> > +   [COMPUTE_CLASS] = GEN12_GFX_TLB_INV_CR,
> 
> Do you know what 0xcf04 is?
> 
> Or if GEN12_GFX_TLB_INV_CR is correct then I think get_reg_and_bit() might
> need adjusting to always select bit 0 for any compute engine instance. Not
> sure how hardware would behave if value other than '1' would be written into
> 0xced8.

I think Prathap and Fei have more familiarity with the MMIO TLB
invalidation; adding them for their thoughts.


Matt

> 
> Regards,
> 
> Tvrtko
> 
> > };
> > struct drm_i915_private *i915 = gt->i915;
> > struct intel_uncore *uncore = gt->uncore;
> > diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
> > b/drivers/gpu/drm/i915/i915_drm_client.c
> > index 475a6f824cad..18d38cb59923 100644
> > --- a/drivers/gpu/drm/i915/i915_drm_client.c
> > +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> > @@ -81,6 +81,7 @@ static const char * const uabi_class_names[] = {
> > [I915_ENGINE_CLASS_COPY] = "copy",
> > [I915_ENGINE_CLASS_VIDEO] = "video",
> > [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "video-enhance",
> > +   [I915_ENGINE_CLASS_COMPUTE] = "compute",
> >   };
> >   static u64 busy_add(struct i915_gem_context *ctx, unsigned int class)
> > diff --git a/drivers/gpu/drm/i915/i915_drm_client.h 
> > b/drivers/gpu/drm/i915/i915_drm_client.h
> > index 5f5b02b01ba0..f796c5e8e060 100644
> > --- a/drivers/gpu/drm/i915/i915_drm_client.h
> > +++ b/drivers/gpu/drm/i915/i915_drm_client.h
> > @@ -13,7 +13,7 @@
> >   #include "gt/intel_engine_types.h"
> > -#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_VIDEO_ENHANCE
> > +#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_COMPUTE
> >   struct drm_i915_private;
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index 35ca528803fd..a2def7b27009 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -154,21 +154,71 @@ enum i915_mocs_table_index {
> > I915_MOCS_CACHED,
> >   };
> > -/*
> > +/**
> > + * enum drm_i915_gem_engine_class - uapi engine type enumeration
> > + *
> >* Different engines serve different roles, and there may be more than one
> > - * engine serving each role. enum drm_i915_gem_engine_class provides a
> > - * classification of the role of the engine, which may be used when 
> > requesting
> > - * operations to be performed on a certain subset of engines, or for 
> > providing
> > - * information about that group.
> > + * engine serving each role.  This enum provides a classifi

[Intel-gfx] ✗ Fi.CI.BAT: failure for Flat-CCS eviction enhancements (rev3)

2022-04-25 Thread Patchwork
== Series Details ==

Series: Flat-CCS eviction enhancements (rev3)
URL   : https://patchwork.freedesktop.org/series/102916/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_102916v3


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102916v3 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102916v3, 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_102916v3/index.html

Participating hosts (43 -> 42)
--

  Additional (2): bat-dg2-8 bat-dg1-6 
  Missing(3): fi-kbl-soraka fi-bsw-cyan bat-jsl-2 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  
 Suppressed 

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- {bat-dg2-8}:NOTRUN -> [SKIP][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/bat-dg2-8/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#3282])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#3012])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([fdo#111827]) +8 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#4070] / [i915#4103]) +1 
similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([fdo#109285] / [i915#4098])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [PASS][10] -> [DMESG-WARN][11] ([i915#62]) +12 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#4070] / [i915#533])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-skl-6700k2:  [PASS][13] -> [INCOMPLETE][14] ([i915#])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-skl-6700k2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-skl-6700k2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-rkl-11600/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#3555] / [i915#4098])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v3/fi-r

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions

2022-04-25 Thread Lucas De Marchi

On Wed, Apr 06, 2022 at 08:53:56PM +, Anusha Srivatsa wrote:




-Original Message-
From: De Marchi, Lucas 
Sent: Wednesday, April 6, 2022 10:46 AM
To: Srivatsa, Anusha 
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions

On Wed, Apr 06, 2022 at 10:16:55AM -0700, Anusha Srivatsa wrote:
>
>
>> -Original Message-
>> From: De Marchi, Lucas 
>> Sent: Tuesday, April 5, 2022 11:03 AM
>> To: Srivatsa, Anusha 
>> Cc: intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range
>> restrictions
>>
>> On Tue, Apr 05, 2022 at 10:14:29AM -0700, Anusha Srivatsa wrote:
>> >Bspec has added some steps that check for DMC MMIO range before
>> >programming them.
>> >
>> >v2: Fix for CI failure for v1
>> >
>> >Cc: Lucas De Marchi 
>> >Signed-off-by: Anusha Srivatsa 
>> >---
>> > drivers/gpu/drm/i915/display/intel_dmc.c | 42
>> 
>> > 1 file changed, 42 insertions(+)
>> >
>> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
>> >b/drivers/gpu/drm/i915/display/intel_dmc.c
>> >index 257cf662f9f4..05d8e90854ec 100644
>> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
>> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
>> >@@ -103,6 +103,18 @@ MODULE_FIRMWARE(BXT_DMC_PATH);
>> > #define DMC_V1_MAX_MMIO_COUNT 8
>> > #define DMC_V3_MAX_MMIO_COUNT 20
>> > #define DMC_V1_MMIO_START_RANGE   0x8
>> >+#define TGL_MAIN_MMIO_START   0x8F000
>> >+#define TGL_MAIN_MMIO_END 0x8
>> >+#define TGL_PIPEA_MMIO_START  0x92000
>> >+#define TGL_PIPEA_MMIO_END0x93FFF
>> >+#define TGL_PIPEB_MMIO_START  0x96000
>> >+#define TGL_PIPEB_MMIO_END0x97FFF
>> >+#define TGL_PIPEC_MMIO_START  0x9A000
>> >+#define TGL_PIPEC_MMIO_END0x9BFFF
>> >+#define TGL_PIPED_MMIO_START  0x9E000
>> >+#define TGL_PIPED_MMIO_END0x9
>> >+#define ADLP_PIPE_MMIO_START  0x5F000
>> >+#define ADLP_PIPE_MMIO_END0x5
>> >
>> > struct intel_css_header {
>> >   /* 0x09 for DMC */
>> >@@ -374,6 +386,30 @@ static void dmc_set_fw_offset(struct intel_dmc
>> *dmc,
>> >   }
>> > }
>> >
>> >+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const
>> >+u32 *mmioaddr,
>> >+u32 mmio_count)
>> >+{
>> >+  struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
>> dmc);
>> >+  int i;
>> >+
>> >+  if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
>> >+  for (i = 0; i < mmio_count; i++) {
>> >+  if (!((mmioaddr[i] >= TGL_MAIN_MMIO_START &&
>> mmioaddr[i] <= TGL_MAIN_MMIO_END) ||
>> >+(mmioaddr[i] >= ADLP_PIPE_MMIO_START &&
>> mmioaddr[i] <= ADLP_PIPE_MMIO_END)))
>> >+  return false;
>> >+  }
>> >+  } else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
>> IS_ALDERLAKE_S(i915))
>> >+  for (i = 0; i < mmio_count; i++) {
>> >+  if (!((mmioaddr[i] >= TGL_MAIN_MMIO_START &&
>> mmioaddr[i] <= TGL_MAIN_MMIO_END) ||
>> >+(mmioaddr[i] >= TGL_PIPEA_MMIO_START &&
>> mmioaddr[i] <= TGL_PIPEA_MMIO_END) ||
>> >+(mmioaddr[i] >= TGL_PIPEB_MMIO_START &&
>> mmioaddr[i] <= TGL_PIPEB_MMIO_END) ||
>> >+(mmioaddr[i] >= TGL_PIPEC_MMIO_START &&
>> mmioaddr[i] <= TGL_PIPEC_MMIO_END) ||
>> >+(mmioaddr[i] >= TGL_PIPED_MMIO_START &&
>> mmioaddr[i] <= TGL_PIPEC_MMIO_END)))
>> >+  return false;
>>
>> wonder if we should check for each pipe DMC range independently
>> rather than just checking all the ranges.
> Can convert this to a switch case in that scenario. "If it is PIPE A then it 
must
be within this range". But it will be 2 switches one for DG2 and ADLP and one
for TGL and the rest which have individual ranges for every pipe.

I was thinking more about like this:

#define _TGL_PIPEA_MMIO 0x92000
#define _TGL_PIPEB_MMIO 0x96000
#define TGL_PIPE_MMIO(pipe) _MMIO_PIPE(pipe, _TGL_PIPEA_MMIO,
_TGL_PIPEB_MMIO)
#define TGL_PIPE_MMIO_SIZE  0x1000


Hmm, does it make sense to add something like:

#define DMC_MMIO(dmc_id)_MMIO(_PICK(DMC_ID, DMC_FW_MAIN, DMC_FW_PIPEA, 
DMC_FW_PIPEB, DMC_FW_PIPEC, DMC_FW_PIPED)


typo here --^^

_PICK(dmc_id, DMC_FW_MAIN, DMC_FW_PIPEA, ...) would return 0, 1, 
Why are you converting it to _MMIO? Did you mean to use the address?

If the main blob is not handled differently than it could make sense,
yes.


Lucas De Marchi


Re: [Intel-gfx] [PATCH 1/2] drm/i915/xehp: Add compute engine ABI

2022-04-25 Thread Yang, Fei
>> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
>> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
>> > @@ -1175,6 +1175,7 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
>> >[VIDEO_DECODE_CLASS]= GEN12_VD_TLB_INV_CR,
>> >[VIDEO_ENHANCEMENT_CLASS]   = GEN12_VE_TLB_INV_CR,
>> >[COPY_ENGINE_CLASS] = GEN12_BLT_TLB_INV_CR,
>> > +  [COMPUTE_CLASS] = GEN12_GFX_TLB_INV_CR,
>> 
>> Do you know what 0xcf04 is?

Looks like that is the TLB invalidation register for each compute context.

>> 
>> Or if GEN12_GFX_TLB_INV_CR is correct then I think get_reg_and_bit() 
>> might need adjusting to always select bit 0 for any compute engine 
>> instance. Not sure how hardware would behave if value other than '1' 
>> would be written into 0xced8.
> 
> I think Prathap and Fei have more familiarity with the MMIO TLB invalidation; 
> adding them for their thoughts.

I believe GEN12_GFX_TLB_INV_CR is the right one to use because we are 
invalidating the TLB for each engine.
I'm not sure if we could narrow down to exact which compute context the TLB 
needs to be invalidated though. If that's possible it might be a bit more 
efficient.

> Matt

>> 
>> Regards,
>> 
>> Tvrtko


Re: [Intel-gfx] [PATCH] drm/i915: remove superfluous string helper include

2022-04-25 Thread Matt Roper
On Mon, Apr 25, 2022 at 06:47:54PM +0300, Jani Nikula wrote:
> Remove the duplicate and incorrect (uses "" instead of <>)
> linux/string_helpers.h include.
> 
> Fixes: cc1338f259a2 ("drm/i915/xehp: Update topology dumps for Xe_HP")
> Cc: Matt Roper 
> Cc: Lucas De Marchi 
> Signed-off-by: Jani Nikula 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/gt/intel_sseu.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c 
> b/drivers/gpu/drm/i915/gt/intel_sseu.c
> index 9881a6790574..fdd25691beda 100644
> --- a/drivers/gpu/drm/i915/gt/intel_sseu.c
> +++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
> @@ -10,8 +10,6 @@
>  #include "intel_gt_regs.h"
>  #include "intel_sseu.h"
>  
> -#include "linux/string_helpers.h"
> -
>  void intel_sseu_set_info(struct sseu_dev_info *sseu, u8 max_slices,
>u8 max_subslices, u8 max_eus_per_subslice)
>  {
> -- 
> 2.30.2
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795


[Intel-gfx] [PATCH v2 2/3] drm/i915: Add first set of DG2 PCI IDs

2022-04-25 Thread Matt Roper
The IDs added here are the subset reserved for 'motherboard down'
designs of DG2.  We have all the necessary support upstream to enable
these now (although they'll continue to require force_probe until the
usual requirements are met).

The remaining DG2 IDs for add-in cards will come in a future patch once
some additional required functionality has fully landed.

Bspec: 44477
Cc: Lucas De Marchi 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Tvrtko Ursulin 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_pci.c  |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c | 21 +
 include/drm/i915_pciids.h| 22 ++
 3 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a3a1b4cb2942..1d44f57c2eb0 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1058,7 +1058,6 @@ static const struct intel_device_info xehpsdv_info = {
BIT(VECS0) | BIT(VECS1) | \
BIT(VCS0) | BIT(VCS2)
 
-__maybe_unused
 static const struct intel_device_info dg2_info = {
DG2_FEATURES,
XE_LPD_FEATURES,
@@ -1154,6 +1153,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_DG1_IDS(&dg1_info),
INTEL_RPLS_IDS(&adl_s_info),
INTEL_RPLP_IDS(&adl_p_info),
+   INTEL_DG2_IDS(&dg2_info),
{0, 0, 0}
 };
 MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 74c3ffb66b8d..cefa9ed784ff 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -186,6 +186,18 @@ static const u16 subplatform_rpl_ids[] = {
INTEL_RPLP_IDS(0),
 };
 
+static const u16 subplatform_g10_ids[] = {
+   INTEL_DG2_G10_IDS(0),
+};
+
+static const u16 subplatform_g11_ids[] = {
+   INTEL_DG2_G11_IDS(0),
+};
+
+static const u16 subplatform_g12_ids[] = {
+   INTEL_DG2_G12_IDS(0),
+};
+
 static bool find_devid(u16 id, const u16 *p, unsigned int num)
 {
for (; num; num--, p++) {
@@ -231,6 +243,15 @@ void intel_device_info_subplatform_init(struct 
drm_i915_private *i915)
} else if (find_devid(devid, subplatform_rpl_ids,
  ARRAY_SIZE(subplatform_rpl_ids))) {
mask = BIT(INTEL_SUBPLATFORM_RPL);
+   } else if (find_devid(devid, subplatform_g10_ids,
+ ARRAY_SIZE(subplatform_g10_ids))) {
+   mask = BIT(INTEL_SUBPLATFORM_G10);
+   } else if (find_devid(devid, subplatform_g11_ids,
+ ARRAY_SIZE(subplatform_g11_ids))) {
+   mask = BIT(INTEL_SUBPLATFORM_G11);
+   } else if (find_devid(devid, subplatform_g12_ids,
+ ARRAY_SIZE(subplatform_g12_ids))) {
+   mask = BIT(INTEL_SUBPLATFORM_G12);
}
 
GEM_BUG_ON(mask & ~INTEL_SUBPLATFORM_MASK);
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index a7b5eea7ffaa..283dadfbb4db 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -692,4 +692,26 @@
INTEL_VGA_DEVICE(0xA7A8, info), \
INTEL_VGA_DEVICE(0xA7A9, info)
 
+/* DG2 */
+#define INTEL_DG2_G10_IDS(info) \
+   INTEL_VGA_DEVICE(0x5690, info), \
+   INTEL_VGA_DEVICE(0x5691, info), \
+   INTEL_VGA_DEVICE(0x5692, info)
+
+#define INTEL_DG2_G11_IDS(info) \
+   INTEL_VGA_DEVICE(0x5693, info), \
+   INTEL_VGA_DEVICE(0x5694, info), \
+   INTEL_VGA_DEVICE(0x5695, info), \
+   INTEL_VGA_DEVICE(0x56B0, info)
+
+#define INTEL_DG2_G12_IDS(info) \
+   INTEL_VGA_DEVICE(0x5696, info), \
+   INTEL_VGA_DEVICE(0x5697, info), \
+   INTEL_VGA_DEVICE(0x56B2, info)
+
+#define INTEL_DG2_IDS(info) \
+   INTEL_DG2_G10_IDS(info), \
+   INTEL_DG2_G11_IDS(info), \
+   INTEL_DG2_G12_IDS(info)
+
 #endif /* _I915_PCIIDS_H */
-- 
2.35.1



[Intel-gfx] [PATCH v2 0/3] i915: Upstream initial DG2 PCI IDs

2022-04-25 Thread Matt Roper
We've had all of our DG2 and ATS-M PCI IDs in the topic/core-for-CI
branch for a while, but we've now got the critical uapi changes in place
to unblock upstreaming the initial subset (which correspond to
"motherboard down" designs) through the drm-intel tree.  The remaining
IDs (which correspond to add-in card designs) will remain in the
topic/core-for-CI branch until some additional prerequisite
functionality lands.

Since the topic/core-for-CI branch is a rebasing branch, we'll just
rebase the relevant IDs out of it when the time comes, but I'm sending
them as a formal revert here so that the CI system doesn't get confused
when testing the series.

Note that a handful of new DG2-G12 IDs have also shown up recently, so
those additional IDs are also included here.

Cc: Lucas De Marchi 

Matt Roper (3):
  topic/core-for-CI:  Revert DG2 and ATS-M device IDs
  drm/i915: Add first set of DG2 PCI IDs
  topic/core-for-CI: Add remaining DG2 and ATS-M device IDs

 include/drm/i915_pciids.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
2.35.1



[Intel-gfx] [PATCH v2 3/3] topic/core-for-CI: Add remaining DG2 and ATS-M device IDs

2022-04-25 Thread Matt Roper
The device IDs here are associated with DG2 add-in cards.  We need to
wait for some additional functionality (e.g., small BAR recovery) to
land before we're ready to truly upstream these via drm-intel; for now
we'll just add them to the core-for-CI branch for CI coverage.

Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_pci.c  |  2 +-
 drivers/gpu/drm/i915/intel_device_info.c |  2 ++
 include/drm/i915_pciids.h| 25 +---
 3 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 1d44f57c2eb0..b60492826478 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1066,7 +1066,6 @@ static const struct intel_device_info dg2_info = {
.require_force_probe = 1,
 };
 
-__maybe_unused
 static const struct intel_device_info ats_m_info = {
DG2_FEATURES,
.display = { 0 },
@@ -1154,6 +1153,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_RPLS_IDS(&adl_s_info),
INTEL_RPLP_IDS(&adl_p_info),
INTEL_DG2_IDS(&dg2_info),
+   INTEL_ATS_M_IDS(&ats_m_info),
{0, 0, 0}
 };
 MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index cefa9ed784ff..63e05cd15a90 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -188,10 +188,12 @@ static const u16 subplatform_rpl_ids[] = {
 
 static const u16 subplatform_g10_ids[] = {
INTEL_DG2_G10_IDS(0),
+   INTEL_ATS_M150_IDS(0),
 };
 
 static const u16 subplatform_g11_ids[] = {
INTEL_DG2_G11_IDS(0),
+   INTEL_ATS_M75_IDS(0),
 };
 
 static const u16 subplatform_g12_ids[] = {
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 283dadfbb4db..4585fed4e41e 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -696,22 +696,41 @@
 #define INTEL_DG2_G10_IDS(info) \
INTEL_VGA_DEVICE(0x5690, info), \
INTEL_VGA_DEVICE(0x5691, info), \
-   INTEL_VGA_DEVICE(0x5692, info)
+   INTEL_VGA_DEVICE(0x5692, info), \
+   INTEL_VGA_DEVICE(0x56A0, info), \
+   INTEL_VGA_DEVICE(0x56A1, info), \
+   INTEL_VGA_DEVICE(0x56A2, info)
 
 #define INTEL_DG2_G11_IDS(info) \
INTEL_VGA_DEVICE(0x5693, info), \
INTEL_VGA_DEVICE(0x5694, info), \
INTEL_VGA_DEVICE(0x5695, info), \
-   INTEL_VGA_DEVICE(0x56B0, info)
+   INTEL_VGA_DEVICE(0x56A5, info), \
+   INTEL_VGA_DEVICE(0x56A6, info), \
+   INTEL_VGA_DEVICE(0x56B0, info), \
+   INTEL_VGA_DEVICE(0x56B1, info)
 
 #define INTEL_DG2_G12_IDS(info) \
INTEL_VGA_DEVICE(0x5696, info), \
INTEL_VGA_DEVICE(0x5697, info), \
-   INTEL_VGA_DEVICE(0x56B2, info)
+   INTEL_VGA_DEVICE(0x56A3, info), \
+   INTEL_VGA_DEVICE(0x56A4, info), \
+   INTEL_VGA_DEVICE(0x56B2, info), \
+   INTEL_VGA_DEVICE(0x56B3, info)
 
 #define INTEL_DG2_IDS(info) \
INTEL_DG2_G10_IDS(info), \
INTEL_DG2_G11_IDS(info), \
INTEL_DG2_G12_IDS(info)
 
+#define INTEL_ATS_M150_IDS(info) \
+   INTEL_VGA_DEVICE(0x56C0, info)
+
+#define INTEL_ATS_M75_IDS(info) \
+   INTEL_VGA_DEVICE(0x56C1, info)
+
+#define INTEL_ATS_M_IDS(info) \
+   INTEL_ATS_M150_IDS(info), \
+   INTEL_ATS_M75_IDS(info)
+
 #endif /* _I915_PCIIDS_H */
-- 
2.35.1



[Intel-gfx] [PATCH v2 1/3] topic/core-for-CI: Revert DG2 and ATS-M device IDs

2022-04-25 Thread Matt Roper
Some of the IDs here are ready to formally upstream via drm-intel.
We'll rebase these out of the topic/core-for-CI branch (but they're sent
here as a revert to avoid confusing CI).
 - 92b805135ed2 ("drm/i915: Add DG2 PCI IDs")
 - bca8f652e1a0 ("topic/core-for-CI: Add ATS-M PCI IDs")

Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_pci.c  |  4 +--
 drivers/gpu/drm/i915/intel_device_info.c | 23 ---
 include/drm/i915_pciids.h| 37 
 3 files changed, 2 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index b60492826478..a3a1b4cb2942 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1058,6 +1058,7 @@ static const struct intel_device_info xehpsdv_info = {
BIT(VECS0) | BIT(VECS1) | \
BIT(VCS0) | BIT(VCS2)
 
+__maybe_unused
 static const struct intel_device_info dg2_info = {
DG2_FEATURES,
XE_LPD_FEATURES,
@@ -1066,6 +1067,7 @@ static const struct intel_device_info dg2_info = {
.require_force_probe = 1,
 };
 
+__maybe_unused
 static const struct intel_device_info ats_m_info = {
DG2_FEATURES,
.display = { 0 },
@@ -1152,8 +1154,6 @@ static const struct pci_device_id pciidlist[] = {
INTEL_DG1_IDS(&dg1_info),
INTEL_RPLS_IDS(&adl_s_info),
INTEL_RPLP_IDS(&adl_p_info),
-   INTEL_DG2_IDS(&dg2_info),
-   INTEL_ATS_M_IDS(&ats_m_info),
{0, 0, 0}
 };
 MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 63e05cd15a90..74c3ffb66b8d 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -186,20 +186,6 @@ static const u16 subplatform_rpl_ids[] = {
INTEL_RPLP_IDS(0),
 };
 
-static const u16 subplatform_g10_ids[] = {
-   INTEL_DG2_G10_IDS(0),
-   INTEL_ATS_M150_IDS(0),
-};
-
-static const u16 subplatform_g11_ids[] = {
-   INTEL_DG2_G11_IDS(0),
-   INTEL_ATS_M75_IDS(0),
-};
-
-static const u16 subplatform_g12_ids[] = {
-   INTEL_DG2_G12_IDS(0),
-};
-
 static bool find_devid(u16 id, const u16 *p, unsigned int num)
 {
for (; num; num--, p++) {
@@ -245,15 +231,6 @@ void intel_device_info_subplatform_init(struct 
drm_i915_private *i915)
} else if (find_devid(devid, subplatform_rpl_ids,
  ARRAY_SIZE(subplatform_rpl_ids))) {
mask = BIT(INTEL_SUBPLATFORM_RPL);
-   } else if (find_devid(devid, subplatform_g10_ids,
- ARRAY_SIZE(subplatform_g10_ids))) {
-   mask = BIT(INTEL_SUBPLATFORM_G10);
-   } else if (find_devid(devid, subplatform_g11_ids,
- ARRAY_SIZE(subplatform_g11_ids))) {
-   mask = BIT(INTEL_SUBPLATFORM_G11);
-   } else if (find_devid(devid, subplatform_g12_ids,
- ARRAY_SIZE(subplatform_g12_ids))) {
-   mask = BIT(INTEL_SUBPLATFORM_G12);
}
 
GEM_BUG_ON(mask & ~INTEL_SUBPLATFORM_MASK);
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 97d1270553bd..a7b5eea7ffaa 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -692,41 +692,4 @@
INTEL_VGA_DEVICE(0xA7A8, info), \
INTEL_VGA_DEVICE(0xA7A9, info)
 
-/* DG2 */
-#define INTEL_DG2_G10_IDS(info) \
-   INTEL_VGA_DEVICE(0x5690, info), \
-   INTEL_VGA_DEVICE(0x5691, info), \
-   INTEL_VGA_DEVICE(0x5692, info), \
-   INTEL_VGA_DEVICE(0x56A0, info), \
-   INTEL_VGA_DEVICE(0x56A1, info), \
-   INTEL_VGA_DEVICE(0x56A2, info)
-
-#define INTEL_DG2_G11_IDS(info) \
-   INTEL_VGA_DEVICE(0x5693, info), \
-   INTEL_VGA_DEVICE(0x5694, info), \
-   INTEL_VGA_DEVICE(0x5695, info), \
-   INTEL_VGA_DEVICE(0x56A5, info), \
-   INTEL_VGA_DEVICE(0x56A6, info), \
-   INTEL_VGA_DEVICE(0x56B0, info), \
-   INTEL_VGA_DEVICE(0x56B1, info)
-
-#define INTEL_DG2_G12_IDS(info) \
-   INTEL_VGA_DEVICE(0x56A3, info), \
-   INTEL_VGA_DEVICE(0x56A4, info)
-
-#define INTEL_DG2_IDS(info) \
-   INTEL_DG2_G10_IDS(info), \
-   INTEL_DG2_G11_IDS(info), \
-   INTEL_DG2_G12_IDS(info)
-
-#define INTEL_ATS_M150_IDS(info) \
-   INTEL_VGA_DEVICE(0x56C0, info)
-
-#define INTEL_ATS_M75_IDS(info) \
-   INTEL_VGA_DEVICE(0x56C1, info)
-
-#define INTEL_ATS_M_IDS(info) \
-   INTEL_ATS_M150_IDS(info), \
-   INTEL_ATS_M75_IDS(info)
-
 #endif /* _I915_PCIIDS_H */
-- 
2.35.1



Re: [Intel-gfx] False-positive of CI issue w/ AMDGPU patch set

2022-04-25 Thread Vudum, Lakshminarayana
I am not sure if I can take any action here. @Latvala, 
Petri Any inputs?

Lakshmi.

From: Zhang, Dingchen (David) 
Sent: Monday, April 25, 2022 1:16 PM
To: Vudum, Lakshminarayana 
Cc: Siqueira, Rodrigo ; Pillai, Aurabindo 

Subject: False-positive of CI issue w/ AMDGPU patch set


[AMD Official Use Only]

Hi Lakshminarayana,

Could you help clear the CI pipeline issue of below patch w/ the ARMHF failure, 
which is a false-positive that is uncorrelated to the amdgpu patch set?
https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/pipelines/569071
[Image removed by 
sender.]

Pipeline * gfx-ci / 
igt-ci-tags
CI tags for IGT GPU tools. WARNING: This repo's master branch will not be 
updated. Use https://gitlab.freedesktop.org/drm/igt-gpu-tools for this purpose.
gitlab.freedesktop.org


https://patchwork.freedesktop.org/series/102886/

Thanks
David


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Upstream initial DG2 PCI IDs

2022-04-25 Thread Patchwork
== Series Details ==

Series: i915: Upstream initial DG2 PCI IDs
URL   : https://patchwork.freedesktop.org/series/103098/
State : warning

== Summary ==

Error: dim checkpatch failed
54fcf40b14d7 topic/core-for-CI: Revert DG2 and ATS-M device IDs
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 92b805135ed2 ("drm/i915: Add DG2 
PCI IDs")'
#9: 
 - 92b805135ed2 ("drm/i915: Add DG2 PCI IDs")

-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit bca8f652e1a0 
("topic/core-for-CI: Add ATS-M PCI IDs")'
#10: 
 - bca8f652e1a0 ("topic/core-for-CI: Add ATS-M PCI IDs")

total: 2 errors, 0 warnings, 0 checks, 98 lines checked
dd0e2dc75482 drm/i915: Add first set of DG2 PCI IDs
-:92: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#92: FILE: include/drm/i915_pciids.h:696:
+#define INTEL_DG2_G10_IDS(info) \
+   INTEL_VGA_DEVICE(0x5690, info), \
+   INTEL_VGA_DEVICE(0x5691, info), \
+   INTEL_VGA_DEVICE(0x5692, info)

-:92: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'info' - possible 
side-effects?
#92: FILE: include/drm/i915_pciids.h:696:
+#define INTEL_DG2_G10_IDS(info) \
+   INTEL_VGA_DEVICE(0x5690, info), \
+   INTEL_VGA_DEVICE(0x5691, info), \
+   INTEL_VGA_DEVICE(0x5692, info)

-:97: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#97: FILE: include/drm/i915_pciids.h:701:
+#define INTEL_DG2_G11_IDS(info) \
+   INTEL_VGA_DEVICE(0x5693, info), \
+   INTEL_VGA_DEVICE(0x5694, info), \
+   INTEL_VGA_DEVICE(0x5695, info), \
+   INTEL_VGA_DEVICE(0x56B0, info)

-:97: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'info' - possible 
side-effects?
#97: FILE: include/drm/i915_pciids.h:701:
+#define INTEL_DG2_G11_IDS(info) \
+   INTEL_VGA_DEVICE(0x5693, info), \
+   INTEL_VGA_DEVICE(0x5694, info), \
+   INTEL_VGA_DEVICE(0x5695, info), \
+   INTEL_VGA_DEVICE(0x56B0, info)

-:103: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#103: FILE: include/drm/i915_pciids.h:707:
+#define INTEL_DG2_G12_IDS(info) \
+   INTEL_VGA_DEVICE(0x5696, info), \
+   INTEL_VGA_DEVICE(0x5697, info), \
+   INTEL_VGA_DEVICE(0x56B2, info)

-:103: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'info' - possible 
side-effects?
#103: FILE: include/drm/i915_pciids.h:707:
+#define INTEL_DG2_G12_IDS(info) \
+   INTEL_VGA_DEVICE(0x5696, info), \
+   INTEL_VGA_DEVICE(0x5697, info), \
+   INTEL_VGA_DEVICE(0x56B2, info)

-:108: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#108: FILE: include/drm/i915_pciids.h:712:
+#define INTEL_DG2_IDS(info) \
+   INTEL_DG2_G10_IDS(info), \
+   INTEL_DG2_G11_IDS(info), \
+   INTEL_DG2_G12_IDS(info)

-:108: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'info' - possible 
side-effects?
#108: FILE: include/drm/i915_pciids.h:712:
+#define INTEL_DG2_IDS(info) \
+   INTEL_DG2_G10_IDS(info), \
+   INTEL_DG2_G11_IDS(info), \
+   INTEL_DG2_G12_IDS(info)

total: 4 errors, 0 warnings, 4 checks, 73 lines checked
33a4fa208957 topic/core-for-CI: Add remaining DG2 and ATS-M device IDs
-:95: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#95: FILE: include/drm/i915_pciids.h:732:
+#define INTEL_ATS_M_IDS(info) \
+   INTEL_ATS_M150_IDS(info), \
+   INTEL_ATS_M75_IDS(info)

-:95: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'info' - possible 
side-effects?
#95: FILE: include/drm/i915_pciids.h:732:
+#define INTEL_ATS_M_IDS(info) \
+   INTEL_ATS_M150_IDS(info), \
+   INTEL_ATS_M75_IDS(info)

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




[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: Upstream initial DG2 PCI IDs

2022-04-25 Thread Patchwork
== Series Details ==

Series: i915: Upstream initial DG2 PCI IDs
URL   : https://patchwork.freedesktop.org/series/103098/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103098v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_103098v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_103098v1, 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_103098v1/index.html

Participating hosts (43 -> 44)
--

  Additional (2): bat-dg2-8 bat-dg1-6 
  Missing(1): fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

  
 Suppressed 

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- {bat-dg2-8}:NOTRUN -> [SKIP][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/bat-dg2-8/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][5] ([i915#5334]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-1}:   [DMESG-WARN][7] ([i915#5278]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@hugepages.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/bat-rpls-1/igt@i915_selftest@l...@hugepages.html

  * igt@kms_busy@basic@modeset:
- {bat-adlp-6}:   [DMESG-WARN][9] ([i915#3576]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-adlp-6/igt@kms_busy@ba...@modeset.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/bat-adlp-6/igt@kms_busy@ba...@modeset.html

  
 Warnings 

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-7567u:   [SKIP][11] ([fdo#109271] / [i915#5341]) -> [SKIP][12] 
([fdo#109271])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-pnv-d510:[SKIP][13] ([fdo#109271] / [i915#5341]) -> [SKIP][14] 
([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-snb-2520m:   [SKIP][15] ([fdo#109271] / [i915#5341]) -> [SKIP][16] 
([fdo#109271])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-snb-2520m/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/fi-snb-2520m/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-bsw-kefka:   [SKIP][17] ([fdo#109271] / [i915#5341]) -> [SKIP][18] 
([fdo#109271])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-kefka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/fi-bsw-kefka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-kbl-8809g:   [SKIP][19] ([fdo#109271] / [i915#5341]) -> [SKIP][20] 
([fdo#109271])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [20]: 
https://intel-gfx-ci.01.org/t

[Intel-gfx] [PATCH] drm/i915/gvt: Add missing symbol export.

2022-04-25 Thread Zhi Wang
When CONFIG_DRM_I915_DEBUG_RUNTIME and CONFIG_DRM_I915_DEBUG_PM
are enabled, two more extra symols in i915 are required to be
exported.

Cc: Jani Nikula 
Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/intel_gvt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index 7c03d975069e..24bc693439e8 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -309,6 +309,7 @@ EXPORT_SYMBOL_NS_GPL(__intel_context_do_pin, I915_GVT);
 EXPORT_SYMBOL_NS_GPL(__intel_context_do_unpin, I915_GVT);
 EXPORT_SYMBOL_NS_GPL(intel_ring_begin, I915_GVT);
 EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_get, I915_GVT);
+EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put, I915_GVT);
 EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put_unchecked, I915_GVT);
 EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_for_reg, I915_GVT);
 EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_get, I915_GVT);
@@ -316,3 +317,4 @@ EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_put, I915_GVT);
 EXPORT_SYMBOL_NS_GPL(shmem_pin_map, I915_GVT);
 EXPORT_SYMBOL_NS_GPL(shmem_unpin_map, I915_GVT);
 EXPORT_SYMBOL_NS_GPL(__px_dma, I915_GVT);
+EXPORT_SYMBOL_NS_GPL(i915_fence_ops, I915_GVT);
-- 
2.17.1



Re: [Intel-gfx] [PATCH] drm/i915/gvt: Add missing symbol export.

2022-04-25 Thread Wang, Zhi A
On 4/25/22 10:03 PM, Zhi Wang wrote:
> When CONFIG_DRM_I915_DEBUG_RUNTIME and CONFIG_DRM_I915_DEBUG_PM
> are enabled, two more extra symols in i915 are required to be
> exported.
> 
> Cc: Jani Nikula 
> Signed-off-by: Zhi Wang 
> ---
>  drivers/gpu/drm/i915/intel_gvt.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_gvt.c 
> b/drivers/gpu/drm/i915/intel_gvt.c
> index 7c03d975069e..24bc693439e8 100644
> --- a/drivers/gpu/drm/i915/intel_gvt.c
> +++ b/drivers/gpu/drm/i915/intel_gvt.c
> @@ -309,6 +309,7 @@ EXPORT_SYMBOL_NS_GPL(__intel_context_do_pin, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(__intel_context_do_unpin, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(intel_ring_begin, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_get, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put_unchecked, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_for_reg, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_get, I915_GVT);
> @@ -316,3 +317,4 @@ EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_put, 
> I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(shmem_pin_map, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(shmem_unpin_map, I915_GVT);
>  EXPORT_SYMBOL_NS_GPL(__px_dma, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_fence_ops, I915_GVT);
> 
Jani:

Can you give this an rb? As I can't give myself a rb.


[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gvt: Add missing symbol export.

2022-04-25 Thread Patchwork
== Series Details ==

Series: drm/i915/gvt: Add missing symbol export.
URL   : https://patchwork.freedesktop.org/series/103101/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/103101/revisions/1/mbox/ not 
applied
Applying: drm/i915/gvt: Add missing symbol export.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_gvt.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_gvt.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_gvt.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/gvt: Add missing symbol export.
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".




Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for i915: Upstream initial DG2 PCI IDs

2022-04-25 Thread Matt Roper
On Mon, Apr 25, 2022 at 09:58:43PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: i915: Upstream initial DG2 PCI IDs
> URL   : https://patchwork.freedesktop.org/series/103098/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103098v1
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_103098v1 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_103098v1, 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_103098v1/index.html
> 
> Participating hosts (43 -> 44)
> --
> 
>   Additional (2): bat-dg2-8 bat-dg1-6 
>   Missing(1): fi-bsw-cyan 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_103098v1:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_exec_suspend@basic-s0@smem:
> - bat-dg1-6:  NOTRUN -> [INCOMPLETE][1]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

Panic from the ethernet driver
(drivers/net/ethernet/aquantia/atlantic/).  Not related to i915 or this
series:

<1>[  232.010956] BUG: kernel NULL pointer dereference, address: 
0008
<1>[  232.010958] #PF: supervisor read access in kernel mode
<1>[  232.010959] #PF: error_code(0x) - not-present page
<6>[  232.010960] PGD 0 P4D 0 
<4>[  232.010961] Oops:  [#1] PREEMPT SMP NOPTI
<4>[  232.010963] CPU: 2 PID: 5261 Comm: kworker/u12:27 Not tainted 
5.18.0-rc4-Patchwork_103098v1-g56b089ae03ef+ #1
<4>[  232.010964] Hardware name: Gigabyte Technology Co., Ltd. GB-Z390 
Garuda/GB-Z390 Garuda-CF, BIOS IG1c 11/19/2019
<4>[  232.010965] Workqueue: events_unbound async_run_entry_fn
<4>[  232.010968] RIP: 0010:aq_ring_rx_fill+0xca/0x1f0 [atlantic]
<4>[  232.010975] Code: 45 24 ba 00 00 00 00 83 c0 01 39 45 28 48 0f 46 c2 89 
45 24 41 83 ee 01 0f 84 ee 00 00 00 48 8d 1c 40 48 c1 e3 04 48 03 5d 00 <48> 8b 
43 08 48 c7 43 28 00 08 00 00 48 85 c0 75 85 48 8b 45 10 31
<4>[  232.010976] RSP: 0018:c900016bbcb8 EFLAGS: 00010246
<4>[  232.010977] RAX:  RBX:  RCX: 

<4>[  232.010978] RDX:  RSI: 0047 RDI: 
888108e213a0
<4>[  232.010979] RBP: 888108e213a0 R08:  R09: 
2000
<4>[  232.010980] R10:  R11: ea0004bbc7c0 R12: 
1000
<4>[  232.010980] R13:  R14:  R15: 
8881000d8205
<4>[  232.010981] FS:  () GS:8884ad70() 
knlGS:
<4>[  232.010982] CS:  0010 DS:  ES:  CR0: 80050033
<4>[  232.010983] CR2: 0008 CR3: 06612004 CR4: 
003706e0
<4>[  232.010983] DR0:  DR1:  DR2: 

<4>[  232.010984] DR3:  DR6: fffe0ff0 DR7: 
0400
<4>[  232.010985] Call Trace:
<4>[  232.010985]  
<4>[  232.010986]  aq_vec_init+0x7c/0xe0 [atlantic]
<4>[  232.010991]  aq_nic_init+0xf4/0x1d0 [atlantic]
<4>[  232.010995]  atl_resume_common+0x49/0xf0 [atlantic]
<4>[  232.010999]  ? pci_pm_thaw+0x80/0x80
<4>[  232.011002]  dpm_run_callback+0x5c/0x240
<4>[  232.011004]  device_resume+0xb2/0x1e0
<4>[  232.011006]  ? __suspend_report_result.cold.21+0x18/0x18
<4>[  232.011008]  async_resume+0x14/0x30
<4>[  232.011010]  async_run_entry_fn+0x2b/0x130
<4>[  232.011012]  process_one_work+0x275/0x5c0
<4>[  232.011014]  worker_thread+0x37/0x370
<4>[  232.011015]  ? process_one_work+0x5c0/0x5c0
<4>[  232.011016]  kthread+0xef/0x120
<4>[  232.011017]  ? kthread_complete_and_exit+0x20/0x20
<4>[  232.011019]  ret_from_fork+0x22/0x30
<4>[  232.011022]  
<4>[  232.011022] Modules linked in: vgem drm_shmem_helper mei_hdcp 
x86_pkg_temp_thermal coretemp i915 kvm_intel snd_hda_codec_realtek 
snd_hda_codec_generic ledtrig_audio kvm irqbypass crct10dif_pclmul btusb ttm 
btrtl crc32_pclmul btbcm drm_buddy snd_hda_intel snd_intel_dspcfg 
ghash_clmulni_intel drm_display_helper btintel snd_hda_codec drm_kms_helper 
bluetooth syscopyarea snd_hwdep atlantic e1000e sysfillrect ecdh_generic 
snd_hda_core sysimgblt ecc ptp fb_sys_fops snd_pcm mei_me prime_numbers 
pps_core mei
<4>[  232.011040] CR2: 0008
<4>[  232.011041] ---[ end trace  ]---


> 
>   
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
> - {bat-dg2-8}:NOTRUN -> [SKIP][2]
>[2]: 
> https://intel-

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: Upstream initial DG2 PCI IDs

2022-04-25 Thread Patchwork
== Series Details ==

Series: i915: Upstream initial DG2 PCI IDs
URL   : https://patchwork.freedesktop.org/series/103098/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103098v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 44)
--

  Additional (2): bat-dg2-8 bat-dg1-6 
  Missing(1): fi-bsw-cyan 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- {bat-dg2-8}:NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/bat-dg2-8/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][2] ([i915#5827])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html

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

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][5] ([i915#5334]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-1}:   [DMESG-WARN][7] ([i915#5278]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-rpls-1/igt@i915_selftest@l...@hugepages.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/bat-rpls-1/igt@i915_selftest@l...@hugepages.html

  * igt@kms_busy@basic@modeset:
- {bat-adlp-6}:   [DMESG-WARN][9] ([i915#3576]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-adlp-6/igt@kms_busy@ba...@modeset.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/bat-adlp-6/igt@kms_busy@ba...@modeset.html

  
 Warnings 

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-7567u:   [SKIP][11] ([fdo#109271] / [i915#5341]) -> [SKIP][12] 
([fdo#109271])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/fi-kbl-7567u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-pnv-d510:[SKIP][13] ([fdo#109271] / [i915#5341]) -> [SKIP][14] 
([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-snb-2520m:   [SKIP][15] ([fdo#109271] / [i915#5341]) -> [SKIP][16] 
([fdo#109271])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-snb-2520m/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/fi-snb-2520m/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-bsw-kefka:   [SKIP][17] ([fdo#109271] / [i915#5341]) -> [SKIP][18] 
([fdo#109271])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-kefka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/fi-bsw-kefka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-kbl-8809g:   [SKIP][19] ([fdo#109271] / [i915#5341]) -> [SKIP][20] 
([fdo#109271])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/fi-kbl-8809g/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
- fi-bsw-nick:[SKIP][21] ([fdo#109271] / [i915#5341]) -> [SKIP][22] 
([fdo#109271])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-nick/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for i915: Upstream initial DG2 PCI IDs

2022-04-25 Thread Vudum, Lakshminarayana
Filed https://gitlab.freedesktop.org/drm/intel/-/issues/5827
igt@gem_exec_suspend@basic-s0@smem - incomplete - pstore logs - BUG: kernel 
NULL pointer dereference, address: 0008, RIP: 0010:aq_ring_rx_fill

Lakshmi.
-Original Message-
From: Roper, Matthew D  
Sent: Monday, April 25, 2022 3:20 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana 
Subject: Re: ✗ Fi.CI.BAT: failure for i915: Upstream initial DG2 PCI IDs

On Mon, Apr 25, 2022 at 09:58:43PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: i915: Upstream initial DG2 PCI IDs
> URL   : https://patchwork.freedesktop.org/series/103098/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103098v1 
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_103098v1 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_103098v1, 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_103098v1/index.html
> 
> Participating hosts (43 -> 44)
> --
> 
>   Additional (2): bat-dg2-8 bat-dg1-6 
>   Missing(1): fi-bsw-cyan 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_103098v1:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_exec_suspend@basic-s0@smem:
> - bat-dg1-6:  NOTRUN -> [INCOMPLETE][1]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/bat-dg1-6/
> igt@gem_exec_suspend@basic...@smem.html

Panic from the ethernet driver
(drivers/net/ethernet/aquantia/atlantic/).  Not related to i915 or this
series:

<1>[  232.010956] BUG: kernel NULL pointer dereference, address: 
0008 <1>[  232.010958] #PF: supervisor read access in kernel mode 
<1>[  232.010959] #PF: error_code(0x) - not-present page <6>[  232.010960] 
PGD 0 P4D 0 <4>[  232.010961] Oops:  [#1] PREEMPT SMP NOPTI <4>[  
232.010963] CPU: 2 PID: 5261 Comm: kworker/u12:27 Not tainted 
5.18.0-rc4-Patchwork_103098v1-g56b089ae03ef+ #1 <4>[  232.010964] Hardware 
name: Gigabyte Technology Co., Ltd. GB-Z390 Garuda/GB-Z390 Garuda-CF, BIOS IG1c 
11/19/2019 <4>[  232.010965] Workqueue: events_unbound async_run_entry_fn <4>[  
232.010968] RIP: 0010:aq_ring_rx_fill+0xca/0x1f0 [atlantic] <4>[  232.010975] 
Code: 45 24 ba 00 00 00 00 83 c0 01 39 45 28 48 0f 46 c2 89 45 24 41 83 ee 01 
0f 84 ee 00 00 00 48 8d 1c 40 48 c1 e3 04 48 03 5d 00 <48> 8b 43 08 48 c7 43 28 
00 08 00 00 48 85 c0 75 85 48 8b 45 10 31 <4>[  232.010976] RSP: 
0018:c900016bbcb8 EFLAGS: 00010246 <4>[  232.010977] RAX:  
RBX:  RCX:  <4>[  232.010978] RDX: 
 RSI: 0047 RDI: 888108e213a0 <4>[  232.010979] 
RBP: 888108e213a0 R08:  R09: 2000 <4>[  
232.010980] R10:  R11: ea0004bbc7c0 R12: 1000 
<4>[  232.010980] R13:  R14:  R15: 
8881000d8205 <4>[  232.010981] FS:  () 
GS:8884ad70() knlGS: <4>[  232.010982] CS:  0010 
DS:  ES:  CR0: 80050033 <4>[  232.010983] CR2: 0008 
CR3: 06612004 CR4: 003706e0 <4>[  232.010983] DR0: 
 DR1:  DR2:  <4>[  232.010984] 
DR3:  DR6: fffe0ff0 DR7: 0400 <4>[  
232.010985] Call Trace:
<4>[  232.010985]  
<4>[  232.010986]  aq_vec_init+0x7c/0xe0 [atlantic] <4>[  232.010991]  
aq_nic_init+0xf4/0x1d0 [atlantic] <4>[  232.010995]  
atl_resume_common+0x49/0xf0 [atlantic] <4>[  232.010999]  ? 
pci_pm_thaw+0x80/0x80 <4>[  232.011002]  dpm_run_callback+0x5c/0x240 <4>[  
232.011004]  device_resume+0xb2/0x1e0 <4>[  232.011006]  ? 
__suspend_report_result.cold.21+0x18/0x18
<4>[  232.011008]  async_resume+0x14/0x30 <4>[  232.011010]  
async_run_entry_fn+0x2b/0x130 <4>[  232.011012]  process_one_work+0x275/0x5c0 
<4>[  232.011014]  worker_thread+0x37/0x370 <4>[  232.011015]  ? 
process_one_work+0x5c0/0x5c0 <4>[  232.011016]  kthread+0xef/0x120 <4>[  
232.011017]  ? kthread_complete_and_exit+0x20/0x20
<4>[  232.011019]  ret_from_fork+0x22/0x30 <4>[  232.011022]   <4>[  
232.011022] Modules linked in: vgem drm_shmem_helper mei_hdcp 
x86_pkg_temp_thermal coretemp i915 kvm_intel snd_hda_codec_realtek 
snd_hda_codec_generic ledtrig_audio kvm irqbypass crct10dif_pclmul btusb ttm 
btrtl crc32_pclmul btbcm drm_buddy snd_hda_intel snd_intel_dspcfg 
ghash_clmulni_intel drm_display_helper btintel snd_hda_codec drm_kms_helper 
bluetooth syscopyarea snd_hwdep atlantic e1000e sysfillrect ecdh_generic

[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Upstream initial DG2 PCI IDs

2022-04-25 Thread Patchwork
== Series Details ==

Series: i915: Upstream initial DG2 PCI IDs
URL   : https://patchwork.freedesktop.org/series/103098/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103098v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 13)
--

  Additional (3): shard-rkl shard-dg1 shard-tglu 

Possible new issues
---

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

### CI changes ###

 Suppressed 

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

  * boot:
- {shard-rkl}:NOTRUN -> ([PASS][1], [PASS][2], [PASS][3], 
[PASS][4], [PASS][5], [PASS][6], [PASS][7], [FAIL][8], [PASS][9], [PASS][10], 
[PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], 
[PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-3/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-3/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-4/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-5/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-1/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-rkl-2/boot.html

  

### IGT changes ###

 Possible regressions 

  * igt@kms_vblank@pipe-d-wait-idle-hang:
- shard-tglb: [PASS][22] -> [INCOMPLETE][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-tglb6/igt@kms_vbl...@pipe-d-wait-idle-hang.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-tglb3/igt@kms_vbl...@pipe-d-wait-idle-hang.html

  
 Suppressed 

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

  * {igt@kms_concurrent@pipe-d@hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [CRASH][24]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-dg1-16/igt@kms_concurrent@pip...@hdmi-a-1.html

  
New tests
-

  New tests have been introduced between CI_DRM_11550_full and 
Patchwork_103098v1_full:

### New IGT tests (1) ###

  * igt@kms_sequence@get-forked-busy@hdmi-a-1-pipe-d:
- Statuses : 1 pass(s)
- Exec time: [1.24] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-1us:
- shard-skl:  [PASS][25] -> [TIMEOUT][26] ([i915#3063])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/igt@gem_...@in-flight-1us.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-skl4/igt@gem_...@in-flight-1us.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][27] ([fdo#109271]) +155 similar 
issues
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103098v1/shard-skl10/igt@gem_exec_fair@basic-f...@rcs0

[Intel-gfx] [PATCH 1/2] drm/i915: Introduce has_media_ratio_mode

2022-04-25 Thread Ashutosh Dixit
Media ratio mode (the ability for media IP to work at a different frequency
from the GT) is available for a subset of dGfx platforms supporting
GuC/SLPC. Introduce 'has_media_ratio_mode' flag in intel_device_info to
identify these platforms and set it for XEHPSDV and DG2/ATS-M.

Cc: Rodrigo Vivi 
Signed-off-by: Ashutosh Dixit 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Andi Shyti 
---
 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 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 24111bf42ce0..96625eabb244 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1227,6 +1227,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define CCS_MASK(gt) \
ENGINE_INSTANCES_MASK(gt, CCS0, I915_MAX_CCS)
 
+#define HAS_MEDIA_RATIO_MODE(dev_priv) 
(INTEL_INFO(dev_priv)->has_media_ratio_mode)
+
 /*
  * The Gen7 cmdparser copies the scanned buffer to the ggtt for execution
  * All later gens can run the final buffer from the ppgtt
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index b60492826478..3ea1e11cc2a7 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1033,6 +1033,7 @@ static const struct intel_device_info xehpsdv_info = {
.display = { },
.has_64k_pages = 1,
.needs_compact_pt = 1,
+   .has_media_ratio_mode = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1053,6 +1054,7 @@ static const struct intel_device_info xehpsdv_info = {
.has_guc_deprivilege = 1, \
.has_heci_pxp = 1, \
.needs_compact_pt = 1, \
+   .has_media_ratio_mode = 1, \
.platform_engine_mask = \
BIT(RCS0) | BIT(BCS0) | \
BIT(VECS0) | BIT(VECS1) | \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 20c351c8d5bd..2bd67b3457f1 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -153,6 +153,7 @@ enum intel_ppgtt_type {
func(has_llc); \
func(has_logical_ring_contexts); \
func(has_logical_ring_elsq); \
+   func(has_media_ratio_mode); \
func(has_mslices); \
func(has_pooled_eu); \
func(has_pxp); \
-- 
2.34.1



[Intel-gfx] [PATCH 2/2] drm/i915/gt: Add media freq factor to per-gt sysfs

2022-04-25 Thread Ashutosh Dixit
Expose new sysfs to program and retrieve media freq factor. Factor values
of 0 (dynamic), 0.5 and 1.0 are supported via a u8.8 fixed point
representation (corresponding to integer values of 0, 128 and 256
respectively).

Media freq factor is converted to media_ratio_mode for GuC. It is
programmed into GuC using H2G SLPC interface. It is retrieved from GuC
through a register read. A cached media_ratio_mode is maintained to
preserve set values across GuC resets.

This patch adds the following sysfs files to gt/gtN sysfs:
* media_freq_factor
* media_freq_factor.scale

Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Reviewed-by: Andi Shyti 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   1 +
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 130 ++
 .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h |   6 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   |  20 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h   |   1 +
 .../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h |   3 +
 6 files changed, 161 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index a39718a40cc3..8ba84c336925 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -732,6 +732,7 @@
 #define   GEN6_AGGRESSIVE_TURBO(0 << 15)
 #define   GEN9_SW_REQ_UNSLICE_RATIO_SHIFT  23
 #define   GEN9_IGNORE_SLICE_RATIO  (0 << 0)
+#define   GEN12_MEDIA_FREQ_RATIO   REG_BIT(13)
 
 #define GEN6_RC_VIDEO_FREQ _MMIO(0xa00c)
 #define   GEN6_RC_CTL_RC6pp_ENABLE (1 << 16)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 26cbfa6477d1..2b1cd6a01724 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -557,6 +557,128 @@ static const struct attribute *freq_attrs[] = {
NULL
 };
 
+/*
+ * Scaling for multipliers (aka frequency factors).
+ * The format of the value in the register is u8.8.
+ *
+ * The presentation to userspace is inspired by the perf event framework.
+ * See:
+ *   Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+ * for description of:
+ *   /sys/bus/event_source/devices//events/.scale
+ *
+ * Summary: Expose two sysfs files for each multiplier.
+ *
+ * 1. File  contains a raw hardware value.
+ * 2. File .scale contains the multiplicative scale factor to be
+ *used by userspace to compute the actual value.
+ *
+ * So userspace knows that to get the frequency_factor it multiplies the
+ * provided value by the specified scale factor and vice-versa.
+ *
+ * That way there is no precision loss in the kernel interface and API
+ * is future proof should one day the hardware register change to u16.u16,
+ * on some platform. (Or any other fixed point representation.)
+ *
+ * Example:
+ * File  contains the value 2.5, represented as u8.8 0x0280, which
+ * is comprised of:
+ * - an integer part of 2
+ * - a fractional part of 0x80 (representing 0x80 / 2^8 == 0x80 / 256).
+ * File .scale contains a string representation of floating point
+ * value 0.00390625 (which is (1 / 256)).
+ * Userspace computes the actual value:
+ *   0x0280 * 0.00390625 -> 2.5
+ * or converts an actual value to the value to be written into :
+ *   2.5 / 0.00390625 -> 0x0280
+ */
+
+#define U8_8_VAL_MASK   0x
+#define U8_8_SCALE_TO_VALUE "0.00390625"
+
+static ssize_t freq_factor_scale_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+   return sysfs_emit(buff, "%s\n", U8_8_SCALE_TO_VALUE);
+}
+
+static u32 media_ratio_mode_to_factor(u32 mode)
+{
+   /* 0 -> 0, 1 -> 256, 2 -> 128 */
+   return !mode ? mode : 256 / mode;
+}
+
+static ssize_t media_freq_factor_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+   struct intel_guc_slpc *slpc = >->uc.guc.slpc;
+   intel_wakeref_t wakeref;
+   u32 mode;
+
+   /*
+* Retrieve media_ratio_mode from GEN6_RPNSWREQ bit 13 set by
+* GuC. GEN6_RPNSWREQ:13 value 0 represents 1:2 and 1 represents 1:1
+*/
+   if (IS_XEHPSDV(gt->i915) &&
+   slpc->media_ratio_mode == SLPC_MEDIA_RATIO_MODE_DYNAMIC_CONTROL) {
+   /*
+* For XEHPSDV dynamic mode GEN6_RPNSWREQ:13 does not contain
+* the media_ratio_mode, just return the cached media ratio
+*/
+   mode = slpc->media_ratio_mode;
+   } else {
+   with_intel_runtime_pm(gt->uncore->rpm, wakeref)
+   mode = intel_uncore_read(gt->uncore, GEN6_RPN

  1   2   >