[Intel-gfx] [PATCH v8 5/8] drm/i915/pxp: Add ARB session creation and cleanup

[Alan Previn]

Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.

While relooking at the ARB session creation flow in intel_pxp_start,
let's address missing UAPI documentation. Without actually changing
backward compatible behavior, update i915's drm-uapi comments
that describe the possible error values when creating a context
with I915_CONTEXT_PARAM_PROTECTED_CONTENT. Since the first merge
of PXP support on ADL, i915 returns -ENXIO if a dependency such as
firmware or component driver was yet to be loaded or returns -EIO
if the creation attempt failed when requested by the PXP firmware
(specific firmware error responses are reported in dmesg).

Add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.

For both cases, in the back-end gsccs functions for sending messages
to the firmware inspect the GSC-CS-Mem-Header's pending-bit which
means the GSC firmware is busy and we should retry.

Given the last hw requirement, lets also update functions in
front-end layer that wait for session creation or teardown
completion to use new worst case timeout periods.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c |  10 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h |   1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c  |  28 +++-
 .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |  21 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 130 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h|  12 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  11 +-
 include/uapi/drm/i915_drm.h   |  15 ++
 8 files changed, 221 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 1d9fdfb11268..85f720af2f75 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -13,6 +13,7 @@
 #define GSC_FW_STATUS_REG  _MMIO(0x116C40)
 #define GSC_FW_CURRENT_STATE   REG_GENMASK(3, 0)
 #define   GSC_FW_CURRENT_STATE_RESET   0
+#define   GSC_FW_PROXY_STATE_NORMAL5
 #define GSC_FW_INIT_COMPLETE_BIT   REG_BIT(9)
 
 static bool gsc_is_in_reset(struct intel_uncore *uncore)
@@ -31,6 +32,15 @@ bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
return fw_status & GSC_FW_INIT_COMPLETE_BIT;
 }
 
+bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc)
+{
+   struct intel_uncore *uncore = gsc_uc_to_gt(gsc)->uncore;
+   u32 fw_status = intel_uncore_read(uncore, GSC_FW_STATUS_REG);
+
+   return REG_FIELD_GET(GSC_FW_CURRENT_STATE, fw_status) ==
+  GSC_FW_PROXY_STATE_NORMAL;
+}
+
 static int emit_gsc_fw_load(struct i915_request *rq, struct intel_gsc_uc *gsc)
 {
u32 offset = i915_ggtt_offset(gsc->local);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
index f4c1106bb2a9..fff8928218df 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
@@ -13,5 +13,6 @@ struct intel_uncore;
 
 int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc);
 bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc);
+bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc);
 
 #endif
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 8949d4be7882..550457bbb034 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -291,6 +291,8 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
 
 static int __pxp_global_teardown_final(struct intel_pxp *pxp)
 {
+   int timeout;
+
if (!pxp->arb_is_valid)
return 0;
/*
@@ -300,7 +302,12 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
 
-   if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(250)))
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   else
+   timeout = 250;
+
+   if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
 
return 0;
@@ -308,6 +315,8 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
 
 static int __pxp_global_teardown_restart(struct intel_pxp *pxp)
 {
+   int timeout;
+
if (pxp->arb_is_valid)
return 0;
/*
@@ -316,7 +325,12 @@ static int __pxp_global_teardown_restart(struct intel_pxp 
*pxp)
 */
pxp_queue_termination(pxp);
 
-   if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(250)))
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   else
+   timeout = 

[Intel-gfx] [PATCH v8 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

[Alan Previn]

Because of the additional firmware, component-driver and
initialization depedencies required on MTL platform before a
PXP context can be created, UMD calling for PXP creation as a
way to get-caps can take a long time. An actual real world
customer stack has seen this happen in the 4-to-8 second range
after the kernel starts (which sees MESA's init appear in the
middle of this range as the compositor comes up). To avoid
unncessary delays experienced by the UMD for get-caps purposes,
add a GET_PARAM for I915_PARAM_PXP_SUPPORT.

However, some failures can still occur after all the depedencies
are met (such as firmware init flow failure, bios configurations
or SOC fusing not allowing PXP enablement). Those scenarios will
only be known to user space when it attempts creating a PXP context.

With this change, large delays are only met by user-space processes
that explicitly need to create a PXP context and boot very early.
There is no way to avoid this today.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
Acked-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_getparam.c |  5 +
 include/uapi/drm/i915_drm.h  | 14 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 2238e096c957..9729384f033f 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -5,6 +5,8 @@
 #include "gem/i915_gem_mman.h"
 #include "gt/intel_engine_user.h"
 
+#include "pxp/intel_pxp.h"
+
 #include "i915_cmd_parser.h"
 #include "i915_drv.h"
 #include "i915_getparam.h"
@@ -102,6 +104,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
if (value < 0)
return value;
break;
+   case I915_PARAM_PXP_STATUS:
+   value = intel_pxp_is_enabled(i915->pxp) ? 0 : -ENODEV;
+   break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
 * earlier versions as 0, in effect their value is undefined as
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index b15dd9cc2ffb..e21991cd6c3d 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -771,6 +771,20 @@ typedef struct drm_i915_irq_wait {
  */
 #define I915_PARAM_OA_TIMESTAMP_FREQUENCY 57
 
+/*
+ * Query the status of PXP support in i915.
+ *
+ * The query can fail in the following scenarios with the listed error codes:
+ *  -ENODEV = PXP support is not available on the GPU device or in the kernel
+ *due to missing component drivers or kernel configs.
+ * If the IOCTL is successful, the returned parameter will be set to one of the
+ * following values:
+ *   0 = PXP support maybe available but underlying SOC fusing, BIOS or 
firmware
+ *   configuration is unknown and a PXP-context-creation would be required
+ *   for final verification of feature availibility.
+ */
+#define I915_PARAM_PXP_STATUS   58
+
 /* Must be kept compact -- no holes and well documented */
 
 /**
-- 
2.39.0

[Intel-gfx] [PATCH v8 7/8] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component

[Alan Previn]

On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.

Thus, immediately enable (or disable) KCR HW on PXP's init,
fini and resume.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 15 ++-
 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c|  3 ++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 4bc276daca16..8dc41de3f6f7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -10,6 +10,7 @@
 #include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
 
 #include "i915_drv.h"
+#include "intel_pxp.h"
 #include "intel_pxp_cmd_interface_42.h"
 #include "intel_pxp_cmd_interface_43.h"
 #include "intel_pxp_gsccs.h"
@@ -422,10 +423,22 @@ gsccs_allocate_execution_resource(struct intel_pxp *pxp)
 
 void intel_pxp_gsccs_fini(struct intel_pxp *pxp)
 {
+   intel_wakeref_t wakeref;
+
gsccs_destroy_execution_resource(pxp);
+   with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref)
+   intel_pxp_fini_hw(pxp);
 }
 
 int intel_pxp_gsccs_init(struct intel_pxp *pxp)
 {
-   return gsccs_allocate_execution_resource(pxp);
+   int ret;
+   intel_wakeref_t wakeref;
+
+   ret = gsccs_allocate_execution_resource(pxp);
+   if (!ret) {
+   with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref)
+   intel_pxp_init_hw(pxp);
+   }
+   return ret;
 }
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 4f836b317424..1a04067f61fc 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -43,8 +43,9 @@ void intel_pxp_resume_complete(struct intel_pxp *pxp)
 * The PXP component gets automatically unbound when we go into S3 and
 * re-bound after we come out, so in that scenario we can defer the
 * hw init to the bind call.
+* NOTE: GSC-CS backend doesn't rely on components.
 */
-   if (!pxp->pxp_component)
+   if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
return;
 
intel_pxp_init_hw(pxp);
-- 
2.39.0

[Intel-gfx] [PATCH v8 8/8] drm/i915/pxp: Enable PXP with MTL-GSC-CS

[Alan Previn]

Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the debugfs teardown timeouts to align with
new GSC-CS + firmware specs.

Now that we have 3 places that are selecting pxp timeouts
based on tee vs gsccs back-end, let's add a helper.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_pci.c  |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 18 ++
 drivers/gpu/drm/i915/pxp/intel_pxp.h |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c |  6 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c |  2 +-
 5 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index d64e074d7457..78077b2cd3fa 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1149,6 +1149,7 @@ static const struct intel_device_info mtl_info = {
.has_guc_deprivilege = 1,
.has_mslice_steering = 0,
.has_snoop = 1,
+   .has_pxp = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
.require_force_probe = 1,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 550457bbb034..833ca2bdd6fa 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -289,6 +289,14 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
return bound;
 }
 
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp)
+{
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   return GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+   else
+   return 250;
+}
+
 static int __pxp_global_teardown_final(struct intel_pxp *pxp)
 {
int timeout;
@@ -302,10 +310,7 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
 
-   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
-   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
-   else
-   timeout = 250;
+   timeout = intel_pxp_get_backend_timeout_ms(pxp);
 
if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
@@ -325,10 +330,7 @@ static int __pxp_global_teardown_restart(struct intel_pxp 
*pxp)
 */
pxp_queue_termination(pxp);
 
-   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
-   timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
-   else
-   timeout = 250;
+   timeout = intel_pxp_get_backend_timeout_ms(pxp);
 
if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 3ded0890cd27..9b11211255f9 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -26,6 +26,7 @@ void intel_pxp_fini_hw(struct intel_pxp *pxp);
 void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
 void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32 
arb_session_id);
 
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp);
 int intel_pxp_start(struct intel_pxp *pxp);
 void intel_pxp_end(struct intel_pxp *pxp);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..e07c5b380789 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -14,6 +14,7 @@
 
 #include "intel_pxp.h"
 #include "intel_pxp_debugfs.h"
+#include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
 #include "intel_pxp_types.h"
 
@@ -45,6 +46,7 @@ static int pxp_terminate_set(void *data, u64 val)
 {
struct intel_pxp *pxp = data;
struct intel_gt *gt = pxp->ctrl_gt;
+   int timeout_ms;
 
if (!intel_pxp_is_active(pxp))
return -ENODEV;
@@ -54,8 +56,10 @@ static int pxp_terminate_set(void *data, u64 val)
intel_pxp_irq_handler(pxp, 
GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
spin_unlock_irq(gt->irq_lock);
 
+   timeout_ms = intel_pxp_get_backend_timeout_ms(pxp);
+
if (!wait_for_completion_timeout(>termination,
-msecs_to_jiffies(100)))
+msecs_to_jiffies(timeout_ms)))
return -ETIMEDOUT;
 
return 0;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index e4d8242302c5..0a3e66b0265e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -44,7 +44,7 @@ static int pxp_wait_for_session_state(struct intel_pxp *pxp, 
u32 id, bool in_pla
  KCR_SIP(pxp->kcr_base),

[Intel-gfx] [PATCH v8 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

[Alan Previn]

Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.

NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
 1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
 2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
 3- PXP: This series.

NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.

NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
   common helpers come in:
 - On MTL, when an i915 subsystem needs to send a command request
   to the security firmware, it will send that via the GSC-
   engine-command-streamer.
 - However those commands, (lets call them "gsc_specific_fw_api"
   calls), are not understood by the GSC command streamer hw.
 - The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and
   passes it along to the GSC firmware.
 - The GSC FW on the other hand needs additional metadata to know
   which usage service is being called (PXP, HDCP, proxy, etc) along
   with session specific info. Thus an extra header called GSC-CS
   HECI Memory Header, (C) in below diagram is prepended before
   the FW specific API, (D).
 - Thus, the structural layout of the request submitted would
   need to look like the diagram below (for non-priv PXP).
 - In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
   PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
   will populate blob (C) while additional helpers, different for
   PPGGTT (this patch) vs GGTT (HDCP series) will populate
   blobs (A) and (B) below.
  ___
 (A)  |  MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
  | |   |
  |_|   |
  | (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,|   |
  ||   pkt-addr-out, pkt-size-out)  |
  || MI_BATCH_BUFFER_END|   |   |
  |||   |   |
  | |   |
  |_|   |
|
-
|
   \|/
  __V___
  |   _|
  |(C)|   ||
  |   | struct intel_gsc_mtl_header { ||
  |   |   validity marker ||
  |   |   heci_clent_id   ||
  |   |   ... ||
  |   |  }||
  |   |___||
  |(D)|   ||
  |   | struct gsc_fw_specific_api_foobar {   ||
  |   | ...   ||
  |   | For an example, see   ||
  |   | 'struct pxp43_create_arb_in' at   ||
  |   | intel_pxp_cmd_interface_43.h  ||
  |   |   ||
  |   | } ||
  |   |  Struture depends on command type ||
  |   | struct gsc_fw_specific_api_foobar {   ||
  |   |___||
  ||

That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle (D) and everything
else such as input/output size verification or handling the
responses from security firmware (for example, requiring a retry).

Signed-off-by: Alan Previn 
---
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 102 ++
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |  23 
 2 files changed, 125 

[Intel-gfx] [PATCH v8 2/8] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation

[Alan Previn]

Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:

1. Updating 'pick-gt' to get the media tile for
   KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
   (init, status-checking, etc.).

While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_gt_irq.c   |  3 +-
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 32 
 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 27 +
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 12 +++-
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h   |  6 
 5 files changed, 58 insertions(+), 22 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index c0f3ff4746ad..7727eadb0672 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -101,7 +101,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8 
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
-   if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt, 
GSC0))
+   if ((instance == OTHER_GSC_INSTANCE || instance == 
OTHER_KCR_INSTANCE) &&
+   HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f93aa171aa1e..8949d4be7882 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
 #include "intel_pxp.h"
 #include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
 #include "intel_pxp_session.h"
 #include "intel_pxp_tee.h"
 #include "intel_pxp_types.h"
@@ -61,21 +62,22 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
 }
 
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
+{
+   u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES) 
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+   intel_uncore_write(pxp->ctrl_gt->uncore, KCR_INIT(pxp->kcr_base), val);
+}
 
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
 {
-   intel_uncore_write(gt->uncore, KCR_INIT,
-  
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+   kcr_pxp_set_status(pxp, true);
 }
 
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
 {
-   intel_uncore_write(gt->uncore, KCR_INIT,
-  
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+   kcr_pxp_set_status(pxp, false);
 }
 
 static int create_vcs_context(struct intel_pxp *pxp)
@@ -127,6 +129,11 @@ static void pxp_init_full(struct intel_pxp *pxp)
init_completion(>termination);
complete_all(>termination);
 
+   if (pxp->ctrl_gt->type == GT_MEDIA)
+   pxp->kcr_base = MTL_KCR_BASE;
+   else
+   pxp->kcr_base = GEN12_KCR_BASE;
+
intel_pxp_session_management_init(pxp);
 
ret = create_vcs_context(pxp);
@@ -369,14 +376,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
 
 void intel_pxp_init_hw(struct intel_pxp *pxp)
 {
-   kcr_pxp_enable(pxp->ctrl_gt);
+   kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
 }
 
 void intel_pxp_fini_hw(struct intel_pxp *pxp)
 {
-   kcr_pxp_disable(pxp->ctrl_gt);
-
+   kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
 }
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..a9e7e6efa4c7
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR subsystem register base address */
+#define GEN12_KCR_BASE 0x32000
+#define MTL_KCR_BASE 0x386000
+
+/* KCR enable/disable control */
+#define KCR_INIT(base) _MMIO((base) + 0xf0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define KCR_SIP(base) _MMIO((base) + 0x260)
+
+/* PXP global terminate register for session termination */
+#define KCR_GLOBAL_TERMINATE(base) 

[Intel-gfx] [PATCH v8 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages

[Alan Previn]

Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.

Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.

We use non-priveleged batches for submission to GSC engine
which require two buffers for the request:
 - a buffer for the HECI packet that contains PXP FW commands
 - a batch-buffer that contains the engine instruction for
   sending the HECI packet to the GSC firmware.

Thus, add the allocation and freeing of these buffers in gsccs
init and fini.

The GSC-fw may reply to commands with a SUCCESS but with an
additional pending-bit set in the reply packet. This bit
means the GSC-FW is currently busy and the caller needs to
try again with the gsc_message_handle the fw returned. Thus,
add a wrapper to continuously retry send_message while
replaying the gsc_message_handle. Retries need to follow the
arch-spec count and delay until GSC-FW replies with the real
SUCCESS or timeout after that spec'd delay.

The GSC-fw requires a non-zero host_session_handle provided
by the caller to enable gsc_message_handle tracking. Thus,
allocate the host_session_handle at init and destroy it
at fini (the latter requiring an FYI to the gsc-firmware).

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   3 +-
 .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |   3 +
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 240 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h|   4 +
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h|   6 +
 5 files changed, 254 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
index 3f60cbc011c1..0db216a031af 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -50,7 +50,8 @@ struct intel_gsc_mtl_header {
 * we distinguish the flags using OUTFLAG or INFLAG
 */
u32 flags;
-#define GSC_OUTFLAG_MSG_PENDING1
+#define GSC_OUTFLAG_MSG_PENDINGBIT(0)
+#define GSC_INFLAG_MSG_CLEANUP BIT(1)
 
u32 status;
 } __packed;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index ad67e3f49c20..c65ada99e54f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -12,6 +12,9 @@
 /* PXP-Cmd-Op definitions */
 #define PXP43_CMDID_START_HUC_AUTH 0x003A
 
+/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
+#define PXP43_MAX_HECI_INOUT_SIZE (SZ_32K)
+
 /* PXP-Input-Packet: HUC-Authentication */
 struct pxp43_start_huc_auth_in {
struct pxp_cmd_header header;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index bad55719a7ac..16e3b73d0653 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,23 +6,232 @@
 #include "gem/i915_gem_internal.h"
 
 #include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
 
 #include "i915_drv.h"
 #include "intel_pxp_cmd_interface_43.h"
 #include "intel_pxp_gsccs.h"
 #include "intel_pxp_types.h"
 
+static int
+gsccs_send_message(struct intel_pxp *pxp,
+  void *msg_in, size_t msg_in_size,
+  void *msg_out, size_t msg_out_size_max,
+  size_t *msg_out_len,
+  u64 *gsc_msg_handle_retry)
+{
+   struct intel_gt *gt = pxp->ctrl_gt;
+   struct drm_i915_private *i915 = gt->i915;
+   struct gsccs_session_resources *exec_res =  >gsccs_res;
+   struct intel_gsc_mtl_header *header = exec_res->pkt_vaddr;
+   struct intel_gsc_heci_non_priv_pkt pkt;
+   size_t max_msg_size;
+   u32 reply_size;
+   int ret;
+
+   if (!exec_res->ce)
+   return -ENODEV;
+
+   max_msg_size = PXP43_MAX_HECI_INOUT_SIZE - sizeof(*header);
+
+   if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+   return -ENOSPC;
+
+   if (!exec_res->pkt_vma || !exec_res->bb_vma)
+   return -ENOENT;
+
+   GEM_BUG_ON(exec_res->pkt_vma->size < (2 * PXP43_MAX_HECI_INOUT_SIZE));
+
+   mutex_lock(>tee_mutex);
+
+   memset(header, 0, sizeof(*header));
+   intel_gsc_uc_heci_cmd_emit_mtl_header(header, HECI_MEADDRESS_PXP,
+ msg_in_size + sizeof(*header),
+ exec_res->host_session_handle);
+
+   /* check if this is a host-session-handle cleanup call (empty packet) */
+   if (!msg_in && !msg_out)
+   header->flags |= GSC_INFLAG_MSG_CLEANUP;
+
+   /* copy caller provided gsc message 

[Intel-gfx] [PATCH v8 1/8] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup

[Alan Previn]

For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.

Thus for MTL, we need to allocate and free a set of execution
submission resources for the management of the arbitration session.
Lets start with the context creation first since that object and
its usage is very straight-forward. We'll add the buffer allocation
and freeing later when we introduce the gsccs' send-message function.

Do this one time allocation of gsccs specific resources in
a new gsccs source file with intel_pxp_gsccs_init / fini functions
and hook them up from the PXP front-end.

Signed-off-by: Alan Previn 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/Makefile  |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp.c   | 20 +--
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 63 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h | 29 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   |  2 -
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  8 +++
 6 files changed, 117 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9af76e376ca9..523fc9dda428 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -342,6 +342,7 @@ i915-y += \
 i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
+   pxp/intel_pxp_gsccs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 9d4c7724e98e..f93aa171aa1e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -12,6 +12,7 @@
 #include "i915_drv.h"
 
 #include "intel_pxp.h"
+#include "intel_pxp_gsccs.h"
 #include "intel_pxp_irq.h"
 #include "intel_pxp_session.h"
 #include "intel_pxp_tee.h"
@@ -132,7 +133,10 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
 
-   ret = intel_pxp_tee_component_init(pxp);
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   ret = intel_pxp_gsccs_init(pxp);
+   else
+   ret = intel_pxp_tee_component_init(pxp);
if (ret)
goto out_context;
 
@@ -165,9 +169,12 @@ static struct intel_gt 
*find_gt_for_required_protected_content(struct drm_i915_p
/*
 * For MTL onwards, PXP-controller-GT needs to have a valid GSC engine
 * on the media GT. NOTE: if we have a media-tile with a GSC-engine,
-* the VDBOX is already present so skip that check
+* the VDBOX is already present so skip that check. We also have to
+* ensure the GSC and HUC firmware are coming online
 */
-   if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0))
+   if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0) &&
+   intel_uc_fw_is_loadable(>media_gt->uc.gsc.fw) &&
+   intel_uc_fw_is_loadable(>media_gt->uc.huc.fw))
return i915->media_gt;
 
/*
@@ -207,7 +214,9 @@ int intel_pxp_init(struct drm_i915_private *i915)
if (!i915->pxp)
return -ENOMEM;
 
+   /* init common info used by all feature-mode usages*/
i915->pxp->ctrl_gt = gt;
+   mutex_init(>pxp->tee_mutex);
 
/*
 * If full PXP feature is not available but HuC is loaded by GSC on 
pre-MTL
@@ -229,7 +238,10 @@ void intel_pxp_fini(struct drm_i915_private *i915)
 
i915->pxp->arb_is_valid = false;
 
-   intel_pxp_tee_component_fini(i915->pxp);
+   if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+   intel_pxp_gsccs_fini(i915->pxp);
+   else
+   intel_pxp_tee_component_fini(i915->pxp);
 
destroy_vcs_context(i915->pxp);
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
new file mode 100644
index ..bad55719a7ac
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2023 Intel Corporation.
+ */
+
+#include "gem/i915_gem_internal.h"
+
+#include "gt/intel_context.h"
+
+#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_43.h"
+#include "intel_pxp_gsccs.h"
+#include "intel_pxp_types.h"
+
+static void
+gsccs_destroy_execution_resource(struct intel_pxp *pxp)
+{
+   struct gsccs_session_resources *exec_res = >gsccs_res;
+
+   if (exec_res->ce)
+   intel_context_put(exec_res->ce);
+
+   memset(exec_res, 0, sizeof(*exec_res));
+}
+
+static int
+gsccs_allocate_execution_resource(struct intel_pxp *pxp)
+{
+   struct intel_gt *gt = 

[Intel-gfx] [PATCH v8 0/8] drm/i915/pxp: Add MTL PXP Support

[Alan Previn]

This series enables PXP on MTL. On ADL/TGL platforms, we rely on
the mei driver via the i915-mei PXP component interface to establish
a connection to the security firmware via the HECI device interface.
That interface is used to create and teardown the PXP ARB session.
PXP ARB session is created when protected contexts are created.

In this series, the front end behaviors and interfaces (uapi) remain
the same. We add backend support for MTL but with MTL we directly use
the GSC-CS engine on the MTL GPU device to send messages to the PXP
(a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format
of the message is slightly different with a 2-layer packetization
that is explained in detail in Patch #3. Also, the second layer
which is the actual PXP firmware packet is now rev'd to version 4.3
for MTL that is defined in Patch #5.

Take note that Patch #4 adds the buffer allocation and gsccs-send-
message without actually being called by the arb-creation code
which gets added in Patch #5. Additionally, a seperate series being
reviewed is introducing a change for session teardown (in pxp front-
end layer that will need backend support by both legacy and gsccs).
If we squash all of these together (buffer-alloc, send-message,
arb-creation and, in future, session-termination), the single patch
will be rather large. That said, we are keeping Patch #4 and #5
separate for now, but at merge time, we can squash them together
if maintainer requires it.

Changes from prior revs:
   v1 : - fixed when building with CONFIG_PXP disabled.
- more alignment with gsc_mtl_header structure from the HDCP
   v2 : - (all following changes as per reviews from Daniele)
- squashed Patch #1 from v1 into the next one.
- replaced unnecessary "uses_gsccs" boolean in the pxp
  with "HAS_ENGINE(pxp->ctrl_gt, GSC0)".
- moved the stashing of gsccs resources from a dynamically
  allocated opaque handle to an explicit sub-struct in
  'struct intel_pxp'.
- moved the buffer object allocations from Patch #1 of this
  series to Patch #5 (but keep the context allocation in
  Patch #1).
- used the kernel default ppgtt for the gsccs context.
- optimized the buffer allocation and deallocation code
  and drop the need to stash the drm_i915_gem_object.
- use a macro with the right mmio reg base (depending
  on root-tile vs media-tile) along with common relative
  offset to access all KCR registers thus minimizing
  changes to the KCR register access codes.
- fixed bugs in the heci packet request submission code
  in Patch #3 (of this series)
- add comments in the mtl-gsc-heci-header regarding the
  host-session-handle.
- re-use tee-mutex instead of introducing a gsccs specific
  cmd mutex.
- minor cosmetic improvements in Patch #5.
- before creating arb session, ensure intel_pxp_start
  first ensures the GSC FW is up and running.
- use 2 second timeout for the pending-bit scenario when
  sending command to GSC-FW as per specs.
- simplify intel_pxp_get_irq_gt with addition comments
- redo Patch #7 to minimize the changes without introducing
  a common  abstraction helper for suspend/resume/init/fini
  codes that have to change the kcr power state.
   v3 : - rebase onto latest drm-tip with the updated firmware
  session invalidation flow
- on Patch#1: move 'mutex_init(>tee_mutex)' to a common
  init place in intel_pxp_init since its needed everywhere
  (Daniele)
- on Patch#1: remove unneccasary "ce->vm = i915_vm_get(vm);"
  (Daniele)
- on Patch#2: move the introduction of host_session_handle to
  Patch#4 where it starts getting used.
- on Patch#4: move host-session-handle initialization to the
  allocate-resources during gsccs-init (away from Patch#5)
  and add the required call to PXP-firmware to cleanup the
  host-session-handle in destroy-resources during gsccs-fini
- on Patch#5: add dispatching of arb session termination
  firmware cmd during session teardown (as per latest
  upstream flows)
   v4 : - Added proper initialization and cleanup of host-session-handle
  that the gsc firmware expects.
- Fix the stream-session-key invalidation instruction for MTL.
   v5 : - In Patch #4, move the tee_mutex locking to after we check for
  valid vma allocations.
- In Patch #5, wait for intel_huc_is_authenticated instead of
  intel_uc_fw_is_running(gsc-fw) before starting ARB session.
- In Patch #5, increase the necessary timeouts at the top-level
  (PXP arb session creation / termination) to accomodate SLA of
  GSC firmware when busy with pending-bit responses.
- In Patch #5, remove redundant host_session_handle init 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Initialize dkl_phy spin lock from display code path (rev4)

[Souza, Jose]

On Fri, 2023-04-21 at 02:02 +, Patchwork wrote:
Patch Details
Series: drm/i915: Initialize dkl_phy spin lock from display code path (rev4)
URL:https://patchwork.freedesktop.org/series/116325/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/index.html
CI Bug Log - changes from CI_DRM_13034_full -> Patchwork_116325v4_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_116325v4_full absolutely need to 
be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_116325v4_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

Participating hosts (7 -> 7)

No changes in participating hosts

Possible new issues

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

IGT changes
Possible regressions

  *   igt@gem_ppgtt@blt-vs-render-ctxn:
 *   shard-snb: 
PASS
 -> 
DMESG-FAIL

Not related.
SNB don't even have DKL phy.

Patch pushed, thanks for all the comments and reviews.

Suppressed

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

  *   igt@kms_flip@2x-flip-vs-fences-interruptible:
 *   {shard-dg1}: NOTRUN -> 
SKIP

Known issues

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

IGT changes
Issues hit

  *   igt@gem_exec_fair@basic-pace@rcs0:

 *   shard-glk: 
PASS
 -> 
FAIL
 (i915#2842)
  *   igt@kms_color@ctm-0-25@pipe-b-vga-1:

 *   shard-snb: NOTRUN -> 
SKIP
 (fdo#109271) +6 similar 
issues

Possible fixes

  *   igt@gem_barrier_race@remote-request@rcs0:

 *   {shard-rkl}: 
ABORT
 (i915#8211) -> 
PASS
  *   igt@gem_exec_endless@dispatch@rcs0:

 *   {shard-tglu}: 
TIMEOUT
 (i915#3778) -> 
PASS
  *   igt@gem_exec_fair@basic-deadline:

 *   shard-apl: 
FAIL
 (i915#2846) -> 
PASS
  *   igt@gem_exec_fair@basic-none@vcs0:

 *   {shard-rkl}: 
FAIL
 (i915#2842) -> 
PASS
 +2 similar issues
  *   igt@i915_pm_rpm@dpms-lpsp:

 *   {shard-rkl}: 
SKIP
 (i915#1397) -> 
PASS
 +1 similar issue
  *   igt@i915_pm_rpm@modeset-non-lpsp:

 *   {shard-dg1}: 
SKIP
 (i915#1397) -> 
PASS
  *   igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:

 *   shard-apl: 
FAIL
 (i915#2346) -> 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Improvements to uc firmare management (rev2)

[Patchwork]

== Series Details ==

Series: Improvements to uc firmare management (rev2)
URL   : https://patchwork.freedesktop.org/series/116517/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13036 -> Patchwork_116517v2


Summary
---

  **FAILURE**

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

Participating hosts (37 -> 37)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

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

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][4] ([i915#1886])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-FAIL][5] ([i915#6367] / [i915#7996])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271]) +16 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v2/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][7] ([i915#7828])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v2/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8:  [PASS][8] -> [FAIL][9] ([i915#7932])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13036/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][10] ([i915#1845])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v2/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-skl-guc: [DMESG-WARN][11] ([i915#8073]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13036/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v2/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@reset:
- bat-rpls-1: [ABORT][13] ([i915#4983] / [i915#7981]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13036/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v2/bat-rpls-1/igt@i915_selftest@l...@reset.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
  [i915#7981]: https://gitlab.freedesktop.org/drm/intel/issues/7981
  [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
  [i915#8073]: https://gitlab.freedesktop.org/drm/intel/issues/8073


Build changes
-

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Improvements to uc firmare management (rev2)

[Patchwork]

== Series Details ==

Series: Improvements to uc firmare management (rev2)
URL   : https://patchwork.freedesktop.org/series/116517/
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.CHECKPATCH: warning for Improvements to uc firmare management (rev2)

[Patchwork]

== Series Details ==

Series: Improvements to uc firmare management (rev2)
URL   : https://patchwork.freedesktop.org/series/116517/
State : warning

== Summary ==

Error: dim checkpatch failed
5f4add3122b0 drm/i915/guc: Decode another GuC load failure case
2b35e460865b drm/i915/guc: Print status register when waiting for GuC to load
5fcf4600dbe0 drm/i915/uc: Track patch level versions on reduced version 
firmware files
-:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'major_' - possible 
side-effects?
#61: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:200:
+#define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \
+   UC_FW_BLOB_NEW(major_, minor_, patch_, false, \
+  MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_))

-:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'minor_' - possible 
side-effects?
#61: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:200:
+#define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \
+   UC_FW_BLOB_NEW(major_, minor_, patch_, false, \
+  MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_))

-:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'patch_' - possible 
side-effects?
#61: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:200:
+#define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \
+   UC_FW_BLOB_NEW(major_, minor_, patch_, false, \
+  MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_))

total: 0 errors, 0 warnings, 3 checks, 73 lines checked
0ad23ab7f74c drm/i915/uc: Enhancements to firmware table validation
8d3a53230905 drm/i915/uc: Reject duplicate entries in firmware table
0eae0615810a drm/i915/uc: Make unexpected firmware versions an error in debug 
builds

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Initialize dkl_phy spin lock from display code path (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Initialize dkl_phy spin lock from display code path (rev4)
URL   : https://patchwork.freedesktop.org/series/116325/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13034_full -> Patchwork_116325v4_full


Summary
---

  **FAILURE**

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

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-snb:  [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-snb1/igt@gem_pp...@blt-vs-render-ctxn.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/shard-snb1/igt@gem_pp...@blt-vs-render-ctxn.html

  
 Suppressed 

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

  * igt@kms_flip@2x-flip-vs-fences-interruptible:
- {shard-dg1}:NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/shard-dg1-16/igt@kms_f...@2x-flip-vs-fences-interruptible.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk:  [PASS][4] -> [FAIL][5] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-glk5/igt@gem_exec_fair@basic-p...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/shard-glk3/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@kms_color@ctm-0-25@pipe-b-vga-1:
- shard-snb:  NOTRUN -> [SKIP][6] ([fdo#109271]) +6 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/shard-snb7/igt@kms_color@ctm-0...@pipe-b-vga-1.html

  
 Possible fixes 

  * igt@gem_barrier_race@remote-request@rcs0:
- {shard-rkl}:[ABORT][7] ([i915#8211]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-rkl-7/igt@gem_barrier_race@remote-requ...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/shard-rkl-2/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_exec_endless@dispatch@rcs0:
- {shard-tglu}:   [TIMEOUT][9] ([i915#3778]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-tglu-8/igt@gem_exec_endless@dispa...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/shard-tglu-10/igt@gem_exec_endless@dispa...@rcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  [FAIL][11] ([i915#2846]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-apl4/igt@gem_exec_f...@basic-deadline.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/shard-apl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][13] ([i915#2842]) -> [PASS][14] +2 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-rkl-7/igt@gem_exec_fair@basic-n...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/shard-rkl-2/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@i915_pm_rpm@dpms-lpsp:
- {shard-rkl}:[SKIP][15] ([i915#1397]) -> [PASS][16] +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-rkl-6/igt@i915_pm_...@dpms-lpsp.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/shard-rkl-7/igt@i915_pm_...@dpms-lpsp.html

  * igt@i915_pm_rpm@modeset-non-lpsp:
- {shard-dg1}:[SKIP][17] ([i915#1397]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-dg1-14/igt@i915_pm_...@modeset-non-lpsp.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/shard-dg1-18/igt@i915_pm_...@modeset-non-lpsp.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl:  [FAIL][19] ([i915#2346]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-apl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

  * igt@kms_cursor_legacy@forked-bo@pipe-b:
- {shard-rkl}:

Re: [Intel-gfx] [RFC 6/6] drm/i915: Implement fdinfo memory stats printing

[Rob Clark]

On Thu, Apr 20, 2023 at 6:11 AM Tvrtko Ursulin
 wrote:
>
>
> On 19/04/2023 15:38, Rob Clark wrote:
> > On Wed, Apr 19, 2023 at 7:06 AM Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 18/04/2023 17:08, Rob Clark wrote:
> >>> On Tue, Apr 18, 2023 at 7:58 AM Tvrtko Ursulin
> >>>  wrote:
>  On 18/04/2023 15:39, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> >  wrote:
> >>
> >> From: Tvrtko Ursulin 
> >>
> >> Show how more driver specific set of memory stats could be shown,
> >> more specifically where object can reside in multiple regions, showing 
> >> all
> >> the supported stats, and where there is more to show than just user 
> >> visible
> >> objects.
> >>
> >> WIP...
> >>
> >> Signed-off-by: Tvrtko Ursulin 
> >> ---
> >> drivers/gpu/drm/i915/i915_driver.c |   5 ++
> >> drivers/gpu/drm/i915/i915_drm_client.c | 102 
> >> +
> >> drivers/gpu/drm/i915/i915_drm_client.h |   8 ++
> >> drivers/gpu/drm/i915/i915_drv.h|   2 +
> >> 4 files changed, 117 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_driver.c 
> >> b/drivers/gpu/drm/i915/i915_driver.c
> >> index 6493548c69bf..4c70206cbc27 100644
> >> --- a/drivers/gpu/drm/i915/i915_driver.c
> >> +++ b/drivers/gpu/drm/i915/i915_driver.c
> >> @@ -1806,6 +1806,11 @@ static const struct drm_driver i915_drm_driver 
> >> = {
> >>.dumb_create = i915_gem_dumb_create,
> >>.dumb_map_offset = i915_gem_dumb_mmap_offset,
> >>
> >> +#ifdef CONFIG_PROC_FS
> >> +   .query_fdinfo_memory_regions = 
> >> i915_query_fdinfo_memory_regions,
> >> +   .query_fdinfo_memory_stats = i915_query_fdinfo_memory_stats,
> >> +#endif
> >> +
> >>.ioctls = i915_ioctls,
> >>.num_ioctls = ARRAY_SIZE(i915_ioctls),
> >>.fops = _driver_fops,
> >> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
> >> b/drivers/gpu/drm/i915/i915_drm_client.c
> >> index c654984189f7..65857c68bdb3 100644
> >> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> >> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> >> @@ -12,6 +12,7 @@
> >> #include 
> >>
> >> #include "gem/i915_gem_context.h"
> >> +#include "intel_memory_region.h"
> >> #include "i915_drm_client.h"
> >> #include "i915_file_private.h"
> >> #include "i915_gem.h"
> >> @@ -112,4 +113,105 @@ void i915_drm_client_fdinfo(struct drm_printer 
> >> *p, struct drm_file *file)
> >>for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
> >>show_client_class(p, i915, file_priv->client, i);
> >> }
> >> +
> >> +char **
> >> +i915_query_fdinfo_memory_regions(struct drm_device *dev, unsigned int 
> >> *num)
> >> +{
> >> +   struct drm_i915_private *i915 = to_i915(dev);
> >> +   struct intel_memory_region *mr;
> >> +   enum intel_region_id id;
> >> +
> >> +   /* FIXME move to init */
> >> +   for_each_memory_region(mr, i915, id) {
> >> +   if (!i915->mm.region_names[id])
> >> +   i915->mm.region_names[id] = mr->name;
> >> +   }
> >> +
> >> +   *num = id;
> >> +
> >> +   return i915->mm.region_names;
> >> +}
> >> +
> >> +static void
> >> +add_obj(struct drm_i915_gem_object *obj, struct 
> >> drm_fdinfo_memory_stat *stats)
> >> +{
> >> +struct intel_memory_region *mr;
> >> +   u64 sz = obj->base.size;
> >> +enum intel_region_id id;
> >> +   unsigned int i;
> >> +
> >> +   if (!obj)
> >> +   return;
> >> +
> >> +   /* Attribute size and shared to all possible memory regions. */
> >> +   for (i = 0; i < obj->mm.n_placements; i++) {
> >> +   mr = obj->mm.placements[i];
> >> +   id = mr->id;
> >> +
> >> +   stats[id].size += sz;
> >
> > This implies that summing up all of the categories is not the same as
> > the toplevel stats that I was proposing
> >>>
> >>> Sorry, I mis-spoke, I meant "summing up all of the regions is not..."
> >>
> >> Ah okay. It could be made like that yes.
> >>
> >> I wasn't sure what would be more useful for drivers which support memory
> >> regions. To see how much memory file could be using worst case, or
> >> strictly how much it is currently using. So for buffer objects where
> >> userspace allows kernel to choose the region from a supplied list, I
> >> thought it would be useful to show that in total size against all
> >> possible regions.
> >>
> >> In a way you see this driver /could/ be using 1G in vram and 1G in
> >> system, but currently it only has resident 1G in vram. Or you see
> >> another file which 

Re: [Intel-gfx] [RFC 4/6] drm: Add simple fdinfo memory helpers

[Rob Clark]

On Thu, Apr 20, 2023 at 6:14 AM Tvrtko Ursulin
 wrote:
>
>
> On 19/04/2023 15:32, Rob Clark wrote:
> > On Wed, Apr 19, 2023 at 6:16 AM Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 18/04/2023 18:18, Rob Clark wrote:
> >>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> >>>  wrote:
> 
>  From: Tvrtko Ursulin 
> 
>  For drivers who only wish to show one memory region called 'system,
>  and only account the GEM buffer object handles under it.
> 
>  Signed-off-by: Tvrtko Ursulin 
>  ---
> drivers/gpu/drm/drm_file.c | 45 ++
> include/drm/drm_file.h |  6 +
> 2 files changed, 51 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
>  index e202f79e816d..1e70669dddf7 100644
>  --- a/drivers/gpu/drm/drm_file.c
>  +++ b/drivers/gpu/drm/drm_file.c
>  @@ -872,6 +872,51 @@ void drm_send_event(struct drm_device *dev, struct 
>  drm_pending_event *e)
> }
> EXPORT_SYMBOL(drm_send_event);
> 
>  +static void
>  +add_obj(struct drm_gem_object *obj, struct drm_fdinfo_memory_stat 
>  *stats)
>  +{
>  +   u64 sz = obj->size;
>  +
>  +   stats[0].size += sz;
>  +
>  +   if (obj->handle_count > 1)
>  +   stats[0].shared += sz;
>  +
>  +   if (!dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true)))
>  +   stats[0].active += sz;
>  +
>  +   /* Not supported. */
>  +   stats[0].resident = ~0ull;
>  +   stats[0].purgeable = ~0ull;
> >>>
> >>> Hmm, this kinda makes the simple helper not very useful.  In my
> >>> version, you get something that is useful for all UMA drivers (which
> >>> all, IIRC, have some form of madv ioctl).  I was kinda imagining that
> >>> for ttm drivers, my print_memory_stats() would just become a helper
> >>> and that TTM (or "multi-region") drivers would have their own thing.
> >>
> >> Hm how? Your version also needed a driver specific vfunc:
> >
> > Sure, but there is a possibility for a driver specific vfunc ;-)
>
> Indeed, they are there in both proposals! :)
>
> > And arguably we could move madv to drm_gem_object, along with get/put
> > pages tracking.. since all the UMA drivers pretty much do the same
> > thing.  So maybe the vfunc is a temporary thing.
> >
> > Anyways, I could go back to my original version where it was a helper
> > called from the driver to print mem stats.  That way, TTM drivers
> > could do their own thing.
>
> I must have missed that. So it was the same idea as in my RFC?

similar, danvet asked for something "more core" ;-)

https://patchwork.freedesktop.org/patch/531403/?series=116216=1

BR,
-R

> Regards,
>
> Tvrtko
>
> > BR,
> > -R
> >
> >> +static enum drm_gem_object_status msm_gem_status(struct drm_gem_object 
> >> *obj)
> >> +{
> >> +   struct msm_gem_object *msm_obj = to_msm_bo(obj);
> >> +   enum drm_gem_object_status status = 0;
> >> +
> >> +   if (msm_obj->pages)
> >> +   status |= DRM_GEM_OBJECT_RESIDENT;
> >> +
> >> +   if (msm_obj->madv == MSM_MADV_DONTNEED)
> >> +   status |= DRM_GEM_OBJECT_PURGEABLE;
> >> +
> >> +   return status;
> >> +}
> >>
> >> Regards,
> >>
> >> Tvrtko
> >>
> >>>
> >>> BR,
> >>> -R
> >>>
>  +}
>  +
>  +char **
>  +drm_query_fdinfo_system_region(struct drm_device *dev, unsigned int 
>  *num)
>  +{
>  +   static char *region[] = {
>  +   "system",
>  +   };
>  +
>  +   *num = 1;
>  +
>  +   return region;
>  +}
>  +EXPORT_SYMBOL(drm_query_fdinfo_system_region);
>  +
>  +void
>  +drm_query_fdinfo_system_memory(struct drm_file *file,
>  +  struct drm_fdinfo_memory_stat *stats)
>  +{
>  +   struct drm_gem_object *obj;
>  +   int id;
>  +
>  +   spin_lock(>table_lock);
>  +   idr_for_each_entry(>object_idr, obj, id)
>  +   add_obj(obj, stats);
>  +   spin_unlock(>table_lock);
>  +}
>  +EXPORT_SYMBOL(drm_query_fdinfo_system_memory);
>  +
> static void
> print_stat(struct drm_printer *p, const char *stat, const char 
>  *region, u64 sz)
> {
>  diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
>  index 00d48beeac5c..dd7c6fb2c975 100644
>  --- a/include/drm/drm_file.h
>  +++ b/include/drm/drm_file.h
>  @@ -383,6 +383,12 @@ struct drm_fdinfo_memory_stat {
>    u64 active;
> };
> 
>  +char **drm_query_fdinfo_system_region(struct drm_device *dev,
>  + unsigned int *num);
>  +void drm_query_fdinfo_system_memory(struct drm_file *file,
>  +   struct drm_fdinfo_memory_stat 
>  *stats);
>  +
>  +
> /**
>  * 

[Intel-gfx] [PATCH 4/6] drm/i915/uc: Enhancements to firmware table validation

[John . C . Harrison]

From: John Harrison 

The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. So pull it out into a separate function that is only
called once per blob type at init time.

Also, drop the CONFIG_SELFTEST requirement and make errors terminal.
It was mentioned that potential issues with backports would not be
caught by regular pre-merge CI as that only occurs on tip not stable
branches. Making the validation unconditional and failing driver load
on detecting of a problem ensures that such backports will also be
validated correctly.

v2: Change to unconditionally fail module load on a validation error
(review feedback/discussion with Daniele).

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 157 +--
 1 file changed, 92 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index c9cd9bb47577f..eb52e8db9ae0b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -233,20 +233,22 @@ struct fw_blobs_by_type {
u32 count;
 };
 
+static const struct uc_fw_platform_requirement blobs_guc[] = {
+   INTEL_GUC_FIRMWARE_DEFS(MAKE_FW_LIST, GUC_FW_BLOB, GUC_FW_BLOB_MMP)
+};
+
+static const struct uc_fw_platform_requirement blobs_huc[] = {
+   INTEL_HUC_FIRMWARE_DEFS(MAKE_FW_LIST, HUC_FW_BLOB, HUC_FW_BLOB_MMP, 
HUC_FW_BLOB_GSC)
+};
+
+static const struct fw_blobs_by_type blobs_all[INTEL_UC_FW_NUM_TYPES] = {
+   [INTEL_UC_FW_TYPE_GUC] = { blobs_guc, ARRAY_SIZE(blobs_guc) },
+   [INTEL_UC_FW_TYPE_HUC] = { blobs_huc, ARRAY_SIZE(blobs_huc) },
+};
+
 static void
 __uc_fw_auto_select(struct drm_i915_private *i915, struct intel_uc_fw *uc_fw)
 {
-   static const struct uc_fw_platform_requirement blobs_guc[] = {
-   INTEL_GUC_FIRMWARE_DEFS(MAKE_FW_LIST, GUC_FW_BLOB, 
GUC_FW_BLOB_MMP)
-   };
-   static const struct uc_fw_platform_requirement blobs_huc[] = {
-   INTEL_HUC_FIRMWARE_DEFS(MAKE_FW_LIST, HUC_FW_BLOB, 
HUC_FW_BLOB_MMP, HUC_FW_BLOB_GSC)
-   };
-   static const struct fw_blobs_by_type blobs_all[INTEL_UC_FW_NUM_TYPES] = 
{
-   [INTEL_UC_FW_TYPE_GUC] = { blobs_guc, ARRAY_SIZE(blobs_guc) },
-   [INTEL_UC_FW_TYPE_HUC] = { blobs_huc, ARRAY_SIZE(blobs_huc) },
-   };
-   static bool verified[INTEL_UC_FW_NUM_TYPES];
const struct uc_fw_platform_requirement *fw_blobs;
enum intel_platform p = INTEL_INFO(i915)->platform;
u32 fw_count;
@@ -286,6 +288,11 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
continue;
 
if (uc_fw->file_selected.path) {
+   /*
+* Continuing an earlier search after a found blob 
failed to load.
+* Once the previously chosen path has been found, 
clear it out
+* and let the search continue from there.
+*/
if (uc_fw->file_selected.path == blob->path)
uc_fw->file_selected.path = NULL;
 
@@ -306,76 +313,91 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
/* Failed to find a match for the last attempt?! */
uc_fw->file_selected.path = NULL;
}
+}
 
-   /* make sure the list is ordered as expected */
-   if (IS_ENABLED(CONFIG_DRM_I915_SELFTEST) && !verified[uc_fw->type]) {
-   verified[uc_fw->type] = true;
+static bool validate_fw_table_type(struct drm_i915_private *i915, enum 
intel_uc_fw_type type)
+{
+   const struct uc_fw_platform_requirement *fw_blobs;
+   u32 fw_count;
+   int i;
 
-   for (i = 1; i < fw_count; i++) {
-   /* Next platform is good: */
-   if (fw_blobs[i].p < fw_blobs[i - 1].p)
-   continue;
+   if (type >= ARRAY_SIZE(blobs_all)) {
+   drm_err(>drm, "No blob array for %s\n", 
intel_uc_fw_type_repr(type));
+   return false;
+   }
 
-   /* Next platform revision is good: */
-   if (fw_blobs[i].p == fw_blobs[i - 1].p &&
-   fw_blobs[i].rev < fw_blobs[i - 1].rev)
-   continue;
+   fw_blobs = blobs_all[type].blobs;
+   fw_count = blobs_all[type].count;
 
-   /* Platform/revision must be in order: */
-   if (fw_blobs[i].p != fw_blobs[i - 1].p ||
-   fw_blobs[i].rev != fw_blobs[i - 1].rev)
-   goto bad;
+   if (!fw_count)
+   return true;
 
-   /* Next major version is good: */
-   if (fw_blobs[i].blob.major < fw_blobs[i - 

[Intel-gfx] [PATCH 6/6] drm/i915/uc: Make unexpected firmware versions an error in debug builds

[John . C . Harrison]

From: John Harrison 

If the DEBUG_GEM config option is set then escalate the 'unexpected
firmware version' message from a notice to an error. This will ensure
that the CI system treats such occurences as a failure and logs a bug
about it (or fails the pre-merge testing).

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 34 ++--
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index bc4011d55667c..c5b21d17ca437 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -17,6 +17,12 @@
 #include "i915_drv.h"
 #include "i915_reg.h"
 
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#define UNEXPECTED gt_err
+#else
+#define UNEXPECTED gt_notice
+#endif
+
 static inline struct intel_gt *
 uc_fw_to_gt(struct intel_uc_fw *uc_fw, enum intel_uc_fw_type type)
 {
@@ -828,10 +834,10 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
if (uc_fw->file_wanted.ver.major && uc_fw->file_selected.ver.major) {
/* Check the file's major version was as it claimed */
if (uc_fw->file_selected.ver.major != 
uc_fw->file_wanted.ver.major) {
-   gt_notice(gt, "%s firmware %s: unexpected version: 
%u.%u != %u.%u\n",
- intel_uc_fw_type_repr(uc_fw->type), 
uc_fw->file_selected.path,
- uc_fw->file_selected.ver.major, 
uc_fw->file_selected.ver.minor,
- uc_fw->file_wanted.ver.major, 
uc_fw->file_wanted.ver.minor);
+   UNEXPECTED(gt, "%s firmware %s: unexpected version: 
%u.%u != %u.%u\n",
+  intel_uc_fw_type_repr(uc_fw->type), 
uc_fw->file_selected.path,
+  uc_fw->file_selected.ver.major, 
uc_fw->file_selected.ver.minor,
+  uc_fw->file_wanted.ver.major, 
uc_fw->file_wanted.ver.minor);
if (!intel_uc_fw_is_overridden(uc_fw)) {
err = -ENOEXEC;
goto fail;
@@ -849,16 +855,16 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
/* Preserve the version that was really wanted */
memcpy(_fw->file_wanted, _ideal, 
sizeof(uc_fw->file_wanted));
 
-   gt_notice(gt, "%s firmware %s (%d.%d.%d) is recommended, but 
only %s (%d.%d.%d) was found\n",
- intel_uc_fw_type_repr(uc_fw->type),
- uc_fw->file_wanted.path,
- uc_fw->file_wanted.ver.major,
- uc_fw->file_wanted.ver.minor,
- uc_fw->file_wanted.ver.patch,
- uc_fw->file_selected.path,
- uc_fw->file_selected.ver.major,
- uc_fw->file_selected.ver.minor,
- uc_fw->file_selected.ver.patch);
+   UNEXPECTED(gt, "%s firmware %s (%d.%d.%d) is recommended, but 
only %s (%d.%d.%d) was found\n",
+  intel_uc_fw_type_repr(uc_fw->type),
+  uc_fw->file_wanted.path,
+  uc_fw->file_wanted.ver.major,
+  uc_fw->file_wanted.ver.minor,
+  uc_fw->file_wanted.ver.patch,
+  uc_fw->file_selected.path,
+  uc_fw->file_selected.ver.major,
+  uc_fw->file_selected.ver.minor,
+  uc_fw->file_selected.ver.patch);
gt_info(gt, "Consider updating your linux-firmware pkg or 
downloading from %s\n",
INTEL_UC_FIRMWARE_URL);
}
-- 
2.39.1

[Intel-gfx] [PATCH 5/6] drm/i915/uc: Reject duplicate entries in firmware table

[John . C . Harrison]

From: John Harrison 

It was noticed that duplicate entries in the firmware table could cause
an infinite loop in the firmware loading code if that entry failed to
load. Duplicate entries are a bug anyway and so should never happen.
Ensure they don't by tweaking the table validation code to reject
duplicates.

For full m/m/p files, that can be done by simply tweaking the patch
level check to reject matching values. For reduced version entries,
the filename itself must be compared.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 27 +---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index eb52e8db9ae0b..bc4011d55667c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -319,7 +319,7 @@ static bool validate_fw_table_type(struct drm_i915_private 
*i915, enum intel_uc_
 {
const struct uc_fw_platform_requirement *fw_blobs;
u32 fw_count;
-   int i;
+   int i, j;
 
if (type >= ARRAY_SIZE(blobs_all)) {
drm_err(>drm, "No blob array for %s\n", 
intel_uc_fw_type_repr(type));
@@ -334,6 +334,27 @@ static bool validate_fw_table_type(struct drm_i915_private 
*i915, enum intel_uc_
 
/* make sure the list is ordered as expected */
for (i = 1; i < fw_count; i++) {
+   /* Versionless file names must be unique per platform: */
+   for (j = i + 1; j < fw_count; j++) {
+   /* Same platform? */
+   if (fw_blobs[i].p != fw_blobs[j].p)
+   continue;
+
+   if (fw_blobs[i].blob.path != fw_blobs[j].blob.path)
+   continue;
+
+   drm_err(>drm, "Diplicaate %s blobs: %s r%u 
%s%d.%d.%d [%s] matches %s r%u %s%d.%d.%d [%s]\n",
+   intel_uc_fw_type_repr(type),
+   intel_platform_name(fw_blobs[j].p), 
fw_blobs[j].rev,
+   fw_blobs[j].blob.legacy ? "L" : "v",
+   fw_blobs[j].blob.major, fw_blobs[j].blob.minor,
+   fw_blobs[j].blob.patch, fw_blobs[j].blob.path,
+   intel_platform_name(fw_blobs[i].p), 
fw_blobs[i].rev,
+   fw_blobs[i].blob.legacy ? "L" : "v",
+   fw_blobs[i].blob.major, fw_blobs[i].blob.minor,
+   fw_blobs[i].blob.patch, fw_blobs[i].blob.path);
+   }
+
/* Next platform is good: */
if (fw_blobs[i].p < fw_blobs[i - 1].p)
continue;
@@ -377,8 +398,8 @@ static bool validate_fw_table_type(struct drm_i915_private 
*i915, enum intel_uc_
if (fw_blobs[i].blob.minor != fw_blobs[i - 1].blob.minor)
goto bad;
 
-   /* Patch versions must be in order: */
-   if (fw_blobs[i].blob.patch <= fw_blobs[i - 1].blob.patch)
+   /* Patch versions must be in order and unique: */
+   if (fw_blobs[i].blob.patch < fw_blobs[i - 1].blob.patch)
continue;
 
 bad:
-- 
2.39.1

[Intel-gfx] [PATCH 1/6] drm/i915/guc: Decode another GuC load failure case

[John . C . Harrison]

From: John Harrison 

Explain another potential firmware failure mode and early exit the
long wait if hit.

Signed-off-by: John Harrison 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 1 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c   | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
index bcb1129b36102..dabeaf4f245f3 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
@@ -44,6 +44,7 @@ enum intel_guc_load_status {
 enum intel_bootrom_load_status {
INTEL_BOOTROM_STATUS_NO_KEY_FOUND = 0x13,
INTEL_BOOTROM_STATUS_AES_PROD_KEY_FOUND   = 0x1A,
+   INTEL_BOOTROM_STATUS_PROD_KEY_CHECK_FAILURE   = 0x2B,
INTEL_BOOTROM_STATUS_RSA_FAILED   = 0x50,
INTEL_BOOTROM_STATUS_PAVPC_FAILED = 0x73,
INTEL_BOOTROM_STATUS_WOPCM_FAILED = 0x74,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 6fda3aec5c66a..0ff088a5e51a8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -129,6 +129,7 @@ static inline bool guc_load_done(struct intel_uncore 
*uncore, u32 *status, bool
case INTEL_BOOTROM_STATUS_RC6CTXCONFIG_FAILED:
case INTEL_BOOTROM_STATUS_MPUMAP_INCORRECT:
case INTEL_BOOTROM_STATUS_EXCEPTION:
+   case INTEL_BOOTROM_STATUS_PROD_KEY_CHECK_FAILURE:
*success = false;
return true;
}
@@ -219,6 +220,11 @@ static int guc_wait_ucode(struct intel_guc *guc)
guc_info(guc, "firmware signature verification 
failed\n");
ret = -ENOEXEC;
break;
+
+   case INTEL_BOOTROM_STATUS_PROD_KEY_CHECK_FAILURE:
+   guc_info(guc, "firmware production part check 
failure\n");
+   ret = -ENOEXEC;
+   break;
}
 
switch (ukernel) {
-- 
2.39.1

[Intel-gfx] [PATCH 3/6] drm/i915/uc: Track patch level versions on reduced version firmware files

[John . C . Harrison]

From: John Harrison 

When reduced version firmware files were added (matching major
component being the only strict requirement), the minor version was
still tracked and a notification reported if it was older. However,
the patch version should really be tracked as well for the same
reasons. The KMD can work without the change but if the effort has
been taken to release a new firmware with the change then there must
be a valid reason for doing so - important bug fix, security fix, etc.
And in that case it would be good to alert the user if they are
missing out on that new fix.

v2: Use correct patch version number and drop redunant debug print
(review by Daniele / CI results).

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 30 +++-
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index a82a53dbbc86d..c9cd9bb47577f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -80,14 +80,14 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
  */
 #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \
fw_def(METEORLAKE,   0, guc_mmp(mtl,  70, 6, 5)) \
-   fw_def(DG2,  0, guc_maj(dg2,  70, 5)) \
-   fw_def(ALDERLAKE_P,  0, guc_maj(adlp, 70, 5)) \
+   fw_def(DG2,  0, guc_maj(dg2,  70, 5, 1)) \
+   fw_def(ALDERLAKE_P,  0, guc_maj(adlp, 70, 5, 1)) \
fw_def(ALDERLAKE_P,  0, guc_mmp(adlp, 70, 1, 1)) \
fw_def(ALDERLAKE_P,  0, guc_mmp(adlp, 69, 0, 3)) \
-   fw_def(ALDERLAKE_S,  0, guc_maj(tgl,  70, 5)) \
+   fw_def(ALDERLAKE_S,  0, guc_maj(tgl,  70, 5, 1)) \
fw_def(ALDERLAKE_S,  0, guc_mmp(tgl,  70, 1, 1)) \
fw_def(ALDERLAKE_S,  0, guc_mmp(tgl,  69, 0, 3)) \
-   fw_def(DG1,  0, guc_maj(dg1,  70, 5)) \
+   fw_def(DG1,  0, guc_maj(dg1,  70, 5, 1)) \
fw_def(ROCKETLAKE,   0, guc_mmp(tgl,  70, 1, 1)) \
fw_def(TIGERLAKE,0, guc_mmp(tgl,  70, 1, 1)) \
fw_def(JASPERLAKE,   0, guc_mmp(ehl,  70, 1, 1)) \
@@ -141,7 +141,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
__stringify(patch_) ".bin"
 
 /* Minor for internal driver use, not part of file name */
-#define MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_) \
+#define MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_) \
__MAKE_UC_FW_PATH_MAJOR(prefix_, "guc", major_)
 
 #define MAKE_GUC_FW_PATH_MMP(prefix_, major_, minor_, patch_) \
@@ -197,9 +197,9 @@ struct __packed uc_fw_blob {
{ UC_FW_BLOB_BASE(major_, minor_, patch_, path_) \
  .legacy = true }
 
-#define GUC_FW_BLOB(prefix_, major_, minor_) \
-   UC_FW_BLOB_NEW(major_, minor_, 0, false, \
-  MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_))
+#define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \
+   UC_FW_BLOB_NEW(major_, minor_, patch_, false, \
+  MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_))
 
 #define GUC_FW_BLOB_MMP(prefix_, major_, minor_, patch_) \
UC_FW_BLOB_OLD(major_, minor_, patch_, \
@@ -296,6 +296,7 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
uc_fw->file_wanted.path = blob->path;
uc_fw->file_wanted.ver.major = blob->major;
uc_fw->file_wanted.ver.minor = blob->minor;
+   uc_fw->file_wanted.ver.patch = blob->patch;
uc_fw->loaded_via_gsc = blob->loaded_via_gsc;
found = true;
break;
@@ -790,6 +791,9 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
} else {
if (uc_fw->file_selected.ver.minor < 
uc_fw->file_wanted.ver.minor)
old_ver = true;
+   else if ((uc_fw->file_selected.ver.minor == 
uc_fw->file_wanted.ver.minor) &&
+(uc_fw->file_selected.ver.patch < 
uc_fw->file_wanted.ver.patch))
+   old_ver = true;
}
}
 
@@ -797,12 +801,16 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
/* Preserve the version that was really wanted */
memcpy(_fw->file_wanted, _ideal, 
sizeof(uc_fw->file_wanted));
 
-   gt_notice(gt, "%s firmware %s (%d.%d) is recommended, but only 
%s (%d.%d) was found\n",
+   gt_notice(gt, "%s firmware %s (%d.%d.%d) is recommended, but 
only %s (%d.%d.%d) was found\n",
  intel_uc_fw_type_repr(uc_fw->type),
  uc_fw->file_wanted.path,
- uc_fw->file_wanted.ver.major, 
uc_fw->file_wanted.ver.minor,
+ uc_fw->file_wanted.ver.major,
+ uc_fw->file_wanted.ver.minor,
+ uc_fw->file_wanted.ver.patch,
  

[Intel-gfx] [PATCH 0/6] Improvements to uc firmare management

[John . C . Harrison]

From: John Harrison 

Enhance the firmware table verification code to catch more potential
errors and to generally improve the code itself.

Track patch level version even on reduced version files to allow user
notification of missing bug fixes.

Detect another immediate failure case when loading GuC firmware.

Treat more problems as fatal errors, at least for DEBUG builds.

Signed-off-by: John Harrison 


John Harrison (6):
  drm/i915/guc: Decode another GuC load failure case
  drm/i915/guc: Print status register when waiting for GuC to load
  drm/i915/uc: Track patch level versions on reduced version firmware
files
  drm/i915/uc: Enhancements to firmware table validation
  drm/i915/uc: Reject duplicate entries in firmware table
  drm/i915/uc: Make unexpected firmware versions an error in debug
builds

 .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h   |   1 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c |  12 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 224 +++---
 3 files changed, 154 insertions(+), 83 deletions(-)

-- 
2.39.1

[Intel-gfx] [PATCH 2/6] drm/i915/guc: Print status register when waiting for GuC to load

[John . C . Harrison]

From: John Harrison 

If the GuC load is taking an excessively long time, the wait loop
currently prints the GT frequency. Extend that to include the GuC
status as well so we can see if the GuC is actually making progress or
not.

Signed-off-by: John Harrison 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 0ff088a5e51a8..364d0d546ec82 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -191,8 +191,10 @@ static int guc_wait_ucode(struct intel_guc *guc)
if (!ret || !success)
break;
 
-   guc_dbg(guc, "load still in progress, count = %d, freq = 
%dMHz\n",
-   count, 
intel_rps_read_actual_frequency(>gt->rps));
+   guc_dbg(guc, "load still in progress, count = %d, freq = %dMHz, 
status = 0x%08X [0x%02X/%02X]\n",
+   count, 
intel_rps_read_actual_frequency(>gt->rps), status,
+   REG_FIELD_GET(GS_BOOTROM_MASK, status),
+   REG_FIELD_GET(GS_UKERNEL_MASK, status));
}
after = ktime_get();
delta = ktime_sub(after, before);
-- 
2.39.1

Re: [Intel-gfx] [PATCH 4/4] drm/i915/gsc: add support for GSC proxy interrupt

[Teres Alexis, Alan Previn]

I think we are also bottom-ing on the opens fo this patch too:


On Thu, 2023-04-20 at 13:21 -0700, Ceraolo Spurio, Daniele wrote:
> On 4/20/2023 11:49 AM, Teres Alexis, Alan Previn wrote:
> > On Wed, 2023-03-29 at 09:56 -0700, Ceraolo Spurio, Daniele wrote:
> > > The GSC notifies us of a proxy request via the HECI2 interrupt. The
> > alan:snip
> > 
> > > @@ -256,6 +262,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
> > >   u32 irqs = GT_RENDER_USER_INTERRUPT;
> > >   u32 guc_mask = intel_uc_wants_guc(>uc) ? GUC_INTR_GUC2HOST 
> > > : 0;
> > >   u32 gsc_mask = 0;
> > > + u32 heci_mask = 0;
> > alan: nit: should we call this heci2_mask - uniquely identifiable from 
> > legacy.
> 
> The mask is theoretically not just for HECI2, the bit we set in it is. 
> If future platforms add back the HECI1 interrupt then it'd go in the 
> same mask.
alan: yeah - im good with that - no change needed then - was a nit anyways.


> > alan:snip
> > 
> > > - else if (HAS_HECI_GSC(gt->i915))
> > > + heci_mask = GSC_IRQ_INTF(1); /* HECI2 IRQ for SW Proxy*/
> > alan: does this GSC_IRQ_INTF macro still make sense for this newer 
> > platforms with GSC-CS / HECI2?
> > i dont think i see other bit definitions for this mask register, so might 
> > else well just define it as BIT14?
> 
> GSC_IRQ_INTF(1) is the HECI2 interrupt on DG2 and the bit has remained 
> the same exactly to allow SW to re-use the same code/defines, so IMO we 
> should do so.
alan: okay sure - sounds good.


> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> > > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > index 4aecb5a7b631..da11ce5ca99e 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > @@ -1577,6 +1577,7 @@
> > >   
> > >   #define GEN11_GT_INTR_DW(x) _MMIO(0x190018 + ((x) * 
> > > 4))
> > >   #define   GEN11_CSME(31)
> > > +#define   GEN12_HECI_2   (30)
> > alan: I dont see this being used anywhere - should remove this.
> 
> A few of the defines for this register here are not used. I've added 
> this one in as a way of documenting where the bit was, but I can remove 
> it if you think it's unneeded.
alan: Oh i actually didnt notice that earlier - in that case, please keep it
would be nice to add a comment for all of those such bits (consider this a nit).

> > 

> > > +void intel_gsc_proxy_irq_handler(struct intel_gsc_uc *gsc, u32 iir)
> > > +{
> > > + struct intel_gt *gt = gsc_uc_to_gt(gsc);
> > > +
> > > + if (unlikely(!iir))
> > > + return;
> > > +
> > > + lockdep_assert_held(gt->irq_lock);
> > > +
> > > + if (!gsc->proxy.component) {
> > > + gt_err(gt, "GSC proxy irq received without the component being 
> > > bound!\n");
> > alan: So although proxy init is only a one-time thing (even surviving 
> > suspend-resume), we
> > know that proxy runtime irqs could happen anytime (depending on other 
> > gpu-security-related
> > system interactions). However, would the component driver be bound/unbound 
> > through a
> > suspend-resume cycle? If yes, then would this check fail if an IRQ for a 
> > proxy request
> > came too early after a resume cycle. If yes, then should we not do 
> > somethign here to ensure that
> > when the component gets bound later, we know there is something waiting to 
> > be processed?
> > (in bind, if proxy-init was done before, but we have outstanding IRQs, then 
> > we can trigger
> > the worker from there, i.e. the bind func?)
> 
> A proxy request can only be triggered in response to a userspace ask, 
> which in turn can only happen once we've completed the resume flow and 
> the component is re-bound. Therefore, we should never have a situation 
> where we get a proxy interrupt without the component being bound.
alan: thanks -my bad.
> > 


> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> > > @@ -23,6 +23,9 @@ struct intel_gsc_uc {
> > >   /* for delayed load and proxy handling */
> > >   struct workqueue_struct *wq;
> > >   struct work_struct work;
> > > + u32 gsc_work_actions; /* protected by gt->irq_lock */
> > > +#define GSC_ACTION_FW_LOAD BIT(0)
> > > +#define GSC_ACTION_SW_PROXY BIT(1
> > > 
> > alan: perhaps its time to have a substruct for "proxy_worker" and include
> > 'wq' and 'work' in additional to actions?
> 
> The worker is not just for proxy, we use it for a GSC and HuC loading as 
> well. It's the main way we handle the gsc_uc, so IMO it's better off 
> staying in the main struct. However, if you still think a substructure 
> will make things cleaner I can add it in, but please suggest a name 
> because I have no idea what to call it (something like handler?).
alan: i was thinking "task_handler" - but since its not specific to proxy,
then let's not change it.

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Disable PL1 power limit when loading GuC firmware

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Disable PL1 power limit when loading GuC firmware
URL   : https://patchwork.freedesktop.org/series/116768/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13034_full -> Patchwork_116768v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-snb:  [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-snb6/igt@gem_pp...@blt-vs-render-ctx0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/shard-snb6/igt@gem_pp...@blt-vs-render-ctx0.html

  
 Suppressed 

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

  * igt@kms_flip@2x-flip-vs-fences-interruptible:
- {shard-dg1}:NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/shard-dg1-17/igt@kms_f...@2x-flip-vs-fences-interruptible.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_barrier_race@remote-request@rcs0:
- shard-glk:  [PASS][4] -> [ABORT][5] ([i915#8211])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-glk9/igt@gem_barrier_race@remote-requ...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/shard-glk9/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@kms_color@ctm-0-25@pipe-b-vga-1:
- shard-snb:  NOTRUN -> [SKIP][6] ([fdo#109271]) +8 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/shard-snb7/igt@kms_color@ctm-0...@pipe-b-vga-1.html

  * igt@kms_flip@flip-vs-blocking-wf-vblank@c-hdmi-a2:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2122])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-glk4/igt@kms_flip@flip-vs-blocking-wf-vbl...@c-hdmi-a2.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/shard-glk1/igt@kms_flip@flip-vs-blocking-wf-vbl...@c-hdmi-a2.html

  * igt@kms_flip@plain-flip-fb-recreate@b-dp1:
- shard-apl:  [PASS][9] -> [FAIL][10] ([i915#2122])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-apl3/igt@kms_flip@plain-flip-fb-recre...@b-dp1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/shard-apl2/igt@kms_flip@plain-flip-fb-recre...@b-dp1.html

  
 Possible fixes 

  * igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][11] ([i915#7742]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-rkl-3/igt@drm_fdinfo@most-busy-check-...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/shard-rkl-7/igt@drm_fdinfo@most-busy-check-...@rcs0.html

  * igt@gem_barrier_race@remote-request@rcs0:
- {shard-rkl}:[ABORT][13] ([i915#8211]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-rkl-7/igt@gem_barrier_race@remote-requ...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/shard-rkl-4/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_exec_endless@dispatch@rcs0:
- {shard-tglu}:   [TIMEOUT][15] ([i915#3778]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-tglu-8/igt@gem_exec_endless@dispa...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/shard-tglu-8/igt@gem_exec_endless@dispa...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- {shard-rkl}:[FAIL][17] ([i915#2842]) -> [PASS][18] +1 similar 
issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-rkl-7/igt@gem_exec_fair@basic-n...@vecs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/shard-rkl-6/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl:  [FAIL][19] ([i915#2842]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * 

Re: [Intel-gfx] [PATCH 2/4] mei: gsc_proxy: add gsc proxy driver

[Teres Alexis, Alan Previn]

i guess we are settled with this patch...

On Thu, 2023-04-20 at 15:04 -0700, Ceraolo Spurio, Daniele wrote:
> On 4/18/2023 11:57 PM, Teres Alexis, Alan Previn wrote:
> > On Wed, 2023-03-29 at 09:56 -0700, Ceraolo Spurio, Daniele wrote:
> > > From: Alexander Usyskin 
> > > 
> > > Add GSC proxy driver. It to allows messaging between GSC component
> > > on Intel on board graphics card and CSE device.
> > alan:nit: isn't "Intel integrated GPU" clearer than "Intel on-board 
> > graphics card"?
> > Same thing for the Kconfig description later (or am i missing something 
> > else here).
> 
> Will change
> 
alan: saw your reply on better alternative for both 'i' and 'd'

alan:snip
> > > +static int mei_gsc_proxy_recv(struct device *dev, void *buf, size_t size)
> > > +{
> > > + ssize_t ret;
> > > +
> > > + if (!dev || !buf)
> > alan: nit: same as in the 'send' above,.. not sure if we should be checking 
> > for !size here...
> > or perhaps 0 sized recv is supported.
> 
> AFAICS the lower level of the mei code do allow for size 0 for both send 
> and recv. Also, this is the same check as what we do for the PXP component.
alan: agreed - thus the nit as per my earlier email.

> > 
alan:snip

> > > + if (subcomponent != I915_COMPONENT_GSC_PROXY)
> > > + return 0;
> > > +
> > > + return component_compare_dev(dev->parent, ((struct device 
> > > *)data)->parent);
> > alan: do we care if both these parents are non-null? i notice in other mei 
> > component
> > drivers match functions we do check that.
> 
> Those should always both be non-NULL, since both the mei and the GFX 
> device have the PCI bus as parent (and the previous check on pdev 
> ensures those are the 2 devices we're handling at this point).
alan: sounds good.



> > > +#define MEI_UUID_GSC_PROXY UUID_LE(0xf73db04, 0x97ab, 0x4125, \
> > > +0xb8, 0x93, 0xe9, 0x4, 0xad, 0xd, 0x54, 0x64)
> > alan: apologies for the newbie question, but why are we using UUID for the 
> > gsc_proxy
> > as opposed to GUID like the other mei components? i am not sure if i read 
> > the right
> > archived patch review but it sounded like GUID is for internal to kernel 
> > only whereas
> > UUID is for external too? 
[snip]
> AFAICS all other mei components use UUID_LE as well. The code was 
> updated from GUID to UUID_LE in:
> https://lore.kernel.org/all/20221228160558.21311-1-andriy.shevche...@linux.intel.com/
alan: sounds good- thanks for the URL.

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add workaround 14018778641

[Matt Roper]

On Thu, Apr 20, 2023 at 04:51:23PM +0530, Tejas Upadhyay wrote:
> WA 18018781329 is applicable now across all MTL
> steppings.
> 
> Cc: Matt Roper 
> Signed-off-by: Tejas Upadhyay 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 312eb8b5f949..c73d2b5410d8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1695,17 +1695,22 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct 
> i915_wa_list *wal)
>  static void
>  xelpg_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
>  {
> - if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0) ||
> - IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0)) {
> - /* Wa_14014830051 */
> - wa_mcr_write_clr(wal, SARB_CHICKEN1, COMP_CKN_IN);
> + /* Wa_14018778641: MTL */
> + if (IS_METEORLAKE(gt->i915)) {

It's already MTL if we're inside this function.  No need for the
condition.  Same for the one in xelpmp_gt_workarounds_init farther down.

In the future it's possible that other platforms could re-use the Xe_LPG
and/or Xe_LPM+ chips in a different platform.  If that happens, we'd
also want these workarounds to apply on those other non-MTL platforms as
well since the workaround is tied to the IP rather than the platform.


Matt

>  
>   /* Wa_18018781329 */
>   wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
>   wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
>  
> - /* Wa_14015795083 */
> - wa_write_clr(wal, GEN7_MISCCPCTL, 
> GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
> + if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0) ||
> + IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0)) {
> + /* Wa_14014830051 */
> + wa_mcr_write_clr(wal, SARB_CHICKEN1, COMP_CKN_IN);
> +
> + /* Wa_14015795083 */
> + wa_write_clr(wal, GEN7_MISCCPCTL,
> +  GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
> + }
>   }
>  
>   /*
> @@ -1718,7 +1723,8 @@ xelpg_gt_workarounds_init(struct intel_gt *gt, struct 
> i915_wa_list *wal)
>  static void
>  xelpmp_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
>  {
> - if (IS_MTL_MEDIA_STEP(gt->i915, STEP_A0, STEP_B0)) {
> + /* Wa_14018778641: MTL */
> + if (IS_METEORLAKE(gt->i915)) {
>   /*
>* Wa_18018781329
>*
> -- 
> 2.25.1
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

Re: [Intel-gfx] [PATCH 2/4] mei: gsc_proxy: add gsc proxy driver

[Ceraolo Spurio, Daniele]

On 4/20/2023 3:04 PM, Ceraolo Spurio, Daniele wrote:



On 4/18/2023 11:57 PM, Teres Alexis, Alan Previn wrote:

On Wed, 2023-03-29 at 09:56 -0700, Ceraolo Spurio, Daniele wrote:

From: Alexander Usyskin 

Add GSC proxy driver. It to allows messaging between GSC component
on Intel on board graphics card and CSE device.
alan:nit: isn't "Intel integrated GPU" clearer than "Intel on-board 
graphics card"?
Same thing for the Kconfig description later (or am i missing 
something else here).


Will change


Thinking again, GSC proxy will be applicable to non-integrated GPUs as 
well, so I'm just going to change this to "Intel graphics card".


Daniele

Re: [Intel-gfx] [PATCH v7 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

[Ceraolo Spurio, Daniele]

On 4/17/2023 10:56 AM, Teres Alexis, Alan Previn wrote:

On Mon, 2023-04-10 at 09:10 -0700, Ceraolo Spurio, Daniele wrote:
alan:snip


+int
+intel_gsc_uc_heci_cmd_submit_nonpriv(struct intel_gsc_uc *gsc,
+struct intel_context *ce,
+struct intel_gsc_heci_non_priv_pkt *pkt,
+u32 *cmd, int timeout_ms)
+{
+   struct intel_engine_cs *eng;

We always use "engine" for engine_cs variables. IMO it's better to stick
to that here as well for consistency across the code.

alan: will do

+   struct i915_gem_ww_ctx ww;
+   struct i915_request *rq;
+   int err, trials = 0;
+

Is the assumption that the caller is holding a wakeref already?
Otherwise we're going to need and engine_pm_get() here (assuming it
doesn't interfere with any locking, otherwise it has to be in the caller)

alan: right now the only places this can get called from is via 
intel_pxp_gsccs_create_session or
intel_pxp_gsccs_end_arb_fw_session. These functions are either being called by 
intel_pxp_start
or intel_pxp_end. intel_pxp_start calls intel_runtime_pm_get_if_in_use 
indirectly from the
session-worker and while intel_pxp_end takes an explicit intel_runtime_pm_get 
(since it is
for suspend/shutdown cleanup and doesn't use the worker). I'm assuming 
runtime_pm works right?
we have a similar logic across the paths from ADL version where we dont take 
explicit
engine_pm_get for the termination via VDBOX because its part of the same code 
paths.


rpm_get works for the power management side, but not for "activeness" 
tracking, for which we need engine_pm_get. However, I've just realized 
that the context_pin contains an engine_pm_get, so we're covered.


Therefore, with the other minor comments addressed, this is:

Reviewed-by: Daniele Ceraolo Spurio 

Daniele



alan:snip


+   err = i915_vma_move_to_active(pkt->bb_vma, rq, EXEC_OBJECT_WRITE);

nit: I don't think we need EXEC_OBJECT_WRITE for the bb as we're not
going to write it.

alan: yes - will remove. (had accidentally kept above flag from offline
debugging version of the code that had additional store dwords into bb).


+   if (err)
+   goto out_rq;
+   err = i915_vma_move_to_active(pkt->heci_pkt_vma, rq, EXEC_OBJECT_WRITE);
+   if (err)
+   goto out_rq;
+
+   eng = rq->context->engine;
+   if (eng->emit_init_breadcrumb) {
+   err = eng->emit_init_breadcrumb(rq);
+   if (err)
+   goto out_rq;
+   }
+
+   err = eng->emit_bb_start(rq, i915_vma_offset(pkt->bb_vma), PAGE_SIZE, 
0);
+   if (err)
+   goto out_rq;
+
+   err = ce->engine->emit_flush(rq, 0);
+   if (err)
+   drm_err(_uc_to_gt(gsc)->i915->drm,
+   "Failed emit-flush for gsc-heci-non-priv-pkterr=%d\n", 
err);
+
+out_rq:
+   i915_request_get(rq);
+
+   if (unlikely(err))
+   i915_request_set_error_once(rq, err);
+
+   i915_request_add(rq);
+
+   if (!err) {
+   if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
+ msecs_to_jiffies(timeout_ms)) < 0)
+   err = -ETIME;
+   }
+
+   i915_request_put(rq);
+
+out_unpin_ce:
+   intel_context_unpin(ce);
+out_ww:
+   if (err == -EDEADLK) {
+   err = i915_gem_ww_ctx_backoff();
+   if (!err) {
+   if (++trials < 10)
+   goto retry;
+   else
+   err = EAGAIN;
+   }
+   }
+   i915_gem_ww_ctx_fini();
+
+   return err;
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
index 3d56ae501991..3addce861854 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -8,7 +8,10 @@
   
   #include 
   
+struct i915_vma;

+struct intel_context;
   struct intel_gsc_uc;
+
   struct intel_gsc_mtl_header {
u32 validity_marker;
   #define GSC_HECI_VALIDITY_MARKER 0xA578875A
@@ -47,7 +50,7 @@ struct intel_gsc_mtl_header {
 * we distinguish the flags using OUTFLAG or INFLAG
 */
u32 flags;
-#define GSC_OUTFLAG_MSG_PENDING1
+#define GSC_OUTFLAG_MSG_PENDING 1

Nit: this change on the define is not really needed

sure - will fix.

Daniele

Re: [Intel-gfx] [PATCH 4/5] drm/i915/mtl: Synchronize i915/BIOS on C6 enabling

[Radhakrishna Sripada]

On Thu, Apr 20, 2023 at 01:05:27PM -0700, Umesh Nerlige Ramappa wrote:
> On Thu, Mar 16, 2023 at 01:25:48PM -0700, Radhakrishna Sripada wrote:
> > From: Vinay Belgaumkar 
> > 
> > If BIOS enables/disables C6, i915 should do the same. Also, retain
> > this value across driver reloads. This is needed only for MTL as
> > of now due to an existing bug in OA which needs C6 disabled for
> > it to function. BIOS behavior is also different across platforms
> > in terms of how C6 is enabled.
> > 
> > v2: Review comments (Umesh)
> > v3: Cache the C6 enable value for all MTL. The OA WA is needed only
> > for A/B step, but we don't need to check for that here.
> > v4: Rename to mtl_check_bios_c6_setup()
> > 
> > Signed-off-by: Vinay Belgaumkar 
> > Signed-off-by: Radhakrishna Sripada 
> 
> This one's already pushed with the MTL OA series.
Thank you for the update. Skipped this patch in the latest rev at [1].

[1] https://patchwork.freedesktop.org/series/115292/#rev3

- Radhakrishna Sripada
> 
> Regards,
> Umesh

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/mtl: Add the missing CPU transcoder mask in intel_device_info

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/mtl: Add the missing CPU transcoder 
mask in intel_device_info
URL   : https://patchwork.freedesktop.org/series/116781/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13035 -> Patchwork_116781v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 36)
--

  Additional (1): bat-mtlp-8 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@migrate:
- bat-atsm-1: [PASS][1] -> [DMESG-FAIL][2] ([i915#7699])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13035/bat-atsm-1/igt@i915_selftest@l...@migrate.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116781v1/bat-atsm-1/igt@i915_selftest@l...@migrate.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@lmem0:
- bat-dg2-9:  [FAIL][3] ([fdo#103375]) -> [PASS][4] +3 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13035/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116781v1/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-3:
- bat-dg2-9:  [FAIL][5] ([fdo#103375] / [i915#7932]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13035/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116781v1/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html

  
 Warnings 

  * igt@i915_selftest@live@slpc:
- bat-rpls-1: [DMESG-FAIL][7] ([i915#6367] / [i915#7996]) -> 
[DMESG-FAIL][8] ([i915#6367])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13035/bat-rpls-1/igt@i915_selftest@l...@slpc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116781v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html

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

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [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.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
  [i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
  [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
  [i915#8346]: https://gitlab.freedesktop.org/drm/intel/issues/8346
  [i915#8368]: https://gitlab.freedesktop.org/drm/intel/issues/8368
  [i915#8369]: https://gitlab.freedesktop.org/drm/intel/issues/8369
  [i915#8370]: https://gitlab.freedesktop.org/drm/intel/issues/8370
  [i915#8379]: https://gitlab.freedesktop.org/drm/intel/issues/8379


Build changes
-

  * Linux: CI_DRM_13035 -> Patchwork_116781v1

  CI-20190529: 20190529
  CI_DRM_13035: 182419213bd7d88fead18eb0830855b675b093d7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7263: a6bd8f415c4ec41b5a014c7db47e46c81ffd0074 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116781v1: 182419213bd7d88fead18eb0830855b675b093d7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

4c6953895a73 drm/i915/mtl: Copy c10 phy pll sw state from master to slave for 
bigjoiner
02f523cf81d9 drm/i915/mtl: Add the missing CPU transcoder mask in 
intel_device_info

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116781v1/index.html

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/mtl: Add the missing CPU transcoder mask in intel_device_info

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/mtl: Add the missing CPU transcoder 
mask in intel_device_info
URL   : https://patchwork.freedesktop.org/series/116781/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced 
symbol 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/mtl: Add the missing CPU transcoder mask in intel_device_info

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/mtl: Add the missing CPU transcoder 
mask in intel_device_info
URL   : https://patchwork.freedesktop.org/series/116781/
State : warning

== Summary ==

Error: dim checkpatch failed
0e167372bec6 drm/i915/mtl: Add the missing CPU transcoder mask in 
intel_device_info
bf32815acd80 drm/i915/mtl: Copy c10 phy pll sw state from master to slave for 
bigjoiner
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#7: 
We try to verify pll registers in sw state for slave crtc with the hw state.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Define MOCS and PAT tables for MTL (rev9)

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Define MOCS and PAT tables for MTL (rev9)
URL   : https://patchwork.freedesktop.org/series/115980/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13035 -> Patchwork_115980v9


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 35)
--

  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#4983])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13035/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v9/bat-rpls-1/igt@i915_selftest@l...@reset.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@lmem0:
- bat-dg2-9:  [FAIL][3] ([fdo#103375]) -> [PASS][4] +3 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13035/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v9/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-3:
- bat-dg2-9:  [FAIL][5] ([fdo#103375] / [i915#7932]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13035/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v9/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html

  
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932


Build changes
-

  * Linux: CI_DRM_13035 -> Patchwork_115980v9

  CI-20190529: 20190529
  CI_DRM_13035: 182419213bd7d88fead18eb0830855b675b093d7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7263: a6bd8f415c4ec41b5a014c7db47e46c81ffd0074 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_115980v9: 182419213bd7d88fead18eb0830855b675b093d7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

2df2b96c526d drm/i915/mtl: Define MOCS and PAT tables for MTL

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v9/index.html

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Define MOCS and PAT tables for MTL (rev9)

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Define MOCS and PAT tables for MTL (rev9)
URL   : https://patchwork.freedesktop.org/series/115980/
State : warning

== Summary ==

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

[Intel-gfx] [PATCH 2/2] drm/i915/mtl: Copy c10 phy pll sw state from master to slave for bigjoiner

[Radhakrishna Sripada]

From: Stanislav Lisovskiy 

We try to verify pll registers in sw state for slave crtc with the hw state.
However in case of bigjoiner we don't calculate those at all, so this 
verification
will then always fail.
So we should either skip the verification for Bigjoiner slave crtc or copy sw 
state
from master crtc.

Signed-off-by: Stanislav Lisovskiy 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index bf391a6cd8d6..83c98791fea3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4556,6 +4556,7 @@ copy_bigjoiner_crtc_state_modeset(struct 
intel_atomic_state *state,
drm_mode_copy(_crtc_state->hw.adjusted_mode,
  _crtc_state->hw.adjusted_mode);
slave_crtc_state->hw.scaling_filter = 
master_crtc_state->hw.scaling_filter;
+   slave_crtc_state->cx0pll_state = master_crtc_state->cx0pll_state;
 
copy_bigjoiner_crtc_state_nomodeset(state, slave_crtc);
 
-- 
2.34.1

[Intel-gfx] [PATCH 1/2] drm/i915/mtl: Add the missing CPU transcoder mask in intel_device_info

[Radhakrishna Sripada]

CPU transcoder mask is used to iterate over the available
CPU transcoders in the macro for_each_cpu_transcoder().

The macro is broken on MTL and got highlighted when audio
state was being tracked for each transcoder added in [1].

Add the missing CPU transcoder mask which is similar to ADL-P
mask but without DSI transcoders.

[1]: https://patchwork.freedesktop.org/patch/523723/

Fixes: 7835303982d1 ("drm/i915/mtl: Add MeteorLake PCI IDs")
Cc: Ville Syrjälä 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/i915_pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index d64e074d7457..847057569796 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1135,6 +1135,8 @@ static const struct intel_gt_definition xelpmp_extra_gt[] 
= {
 static const struct intel_device_info mtl_info = {
XE_HP_FEATURES,
XE_LPDP_FEATURES,
+   .__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
+  BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
/*
 * Real graphics IP version will be obtained from hardware GMD_ID
 * register.  Value provided here is just for sanity checking.
-- 
2.34.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: workaround coherency issue for Media (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: workaround coherency issue for Media (rev2)
URL   : https://patchwork.freedesktop.org/series/116751/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13035 -> Patchwork_116751v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 36)
--

  Additional (1): bat-mtlp-8 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@requests:
- bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#7911])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13035/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v2/bat-rpls-1/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- bat-rplp-1: [PASS][3] -> [DMESG-FAIL][4] ([i915#6367] / 
[i915#7913])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13035/bat-rplp-1/igt@i915_selftest@l...@slpc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v2/bat-rplp-1/igt@i915_selftest@l...@slpc.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@lmem0:
- bat-dg2-9:  [FAIL][5] ([fdo#103375]) -> [PASS][6] +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13035/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v2/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-3:
- bat-dg2-9:  [FAIL][7] ([fdo#103375] / [i915#7932]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13035/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v2/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html

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

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [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.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
  [i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
  [i915#8346]: https://gitlab.freedesktop.org/drm/intel/issues/8346
  [i915#8368]: https://gitlab.freedesktop.org/drm/intel/issues/8368
  [i915#8369]: https://gitlab.freedesktop.org/drm/intel/issues/8369
  [i915#8370]: https://gitlab.freedesktop.org/drm/intel/issues/8370
  [i915#8379]: https://gitlab.freedesktop.org/drm/intel/issues/8379


Build changes
-

  * Linux: CI_DRM_13035 -> Patchwork_116751v2

  CI-20190529: 20190529
  CI_DRM_13035: 182419213bd7d88fead18eb0830855b675b093d7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7263: a6bd8f415c4ec41b5a014c7db47e46c81ffd0074 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116751v2: 182419213bd7d88fead18eb0830855b675b093d7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

a7403f6a505b drm/i915/mtl: workaround coherency issue for Media

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v2/index.html

Re: [Intel-gfx] [PATCH 2/4] mei: gsc_proxy: add gsc proxy driver

[Ceraolo Spurio, Daniele]

On 4/18/2023 11:57 PM, Teres Alexis, Alan Previn wrote:

On Wed, 2023-03-29 at 09:56 -0700, Ceraolo Spurio, Daniele wrote:

From: Alexander Usyskin 

Add GSC proxy driver. It to allows messaging between GSC component
on Intel on board graphics card and CSE device.

alan:nit: isn't "Intel integrated GPU" clearer than "Intel on-board graphics 
card"?
Same thing for the Kconfig description later (or am i missing something else 
here).


Will change



alan:snip




+ MEI GSC proxy enables messaging between GSC service on
+ Intel graphics on-board card and services on CSE (MEI)

alan:nit: same as above





diff --git a/drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c 
b/drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c
new file mode 100644
index ..953eda1a16fb
--- /dev/null
+++ b/drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022-2023 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 

alan: [nit?] i thought we need to have the headers alphabetically ordered? 
(below too)


Will fix


+#include 
+#include 
+#include 
+#include 
+
+/**
+ * mei_gsc_proxy_send - Sends a proxy message to ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @buf: a message buffer to send
+ * @size: size of the message
+ * Return: bytes sent on Success, <0 on Failure
+ */
+static int mei_gsc_proxy_send(struct device *dev, const void *buf, size_t size)
+{
+   ssize_t ret;
+
+   if (!dev || !buf)

alan: nit: not sure if we should be checking for !size here - i do see that 
next patch
is checking for this from i915 side of the interface... but just wasnt sure 
which is the prefered style
(in terms of where to check for this condition). Either way, its a nit for me 
since i traced down
all the way to mei_cl_alloc_cb and it looks like mei bus can tolerate zero 
sized messages.

+   return -EINVAL;

alan:snip


+static int mei_gsc_proxy_recv(struct device *dev, void *buf, size_t size)
+{
+   ssize_t ret;
+
+   if (!dev || !buf)

alan: nit: same as in the 'send' above,.. not sure if we should be checking for 
!size here...
or perhaps 0 sized recv is supported.


AFAICS the lower level of the mei code do allow for size 0 for both send 
and recv. Also, this is the same check as what we do for the PXP component.





+   return -EINVAL;

alan:snip


+static int mei_gsc_proxy_component_match(struct device *dev, int subcomponent,
+void *data)
+{
+   struct pci_dev *pdev;
+
+   if (!dev_is_pci(dev))
+   return 0;
+
+   pdev = to_pci_dev(dev);
+
+   if (pdev->class != (PCI_CLASS_DISPLAY_VGA << 8) ||
+   pdev->vendor != PCI_VENDOR_ID_INTEL)
+   return 0;
+
+   if (subcomponent != I915_COMPONENT_GSC_PROXY)
+   return 0;
+
+   return component_compare_dev(dev->parent, ((struct device 
*)data)->parent);

alan: do we care if both these parents are non-null? i notice in other mei 
component
drivers match functions we do check that.


Those should always both be non-NULL, since both the mei and the GFX 
device have the PCI bus as parent (and the previous check on pdev 
ensures those are the 2 devices we're handling at this point).





+}
+

alan:snip


+#define MEI_UUID_GSC_PROXY UUID_LE(0xf73db04, 0x97ab, 0x4125, \
+  0xb8, 0x93, 0xe9, 0x4, 0xad, 0xd, 0x54, 0x64)

alan: apologies for the newbie question, but why are we using UUID for the 
gsc_proxy
as opposed to GUID like the other mei components? i am not sure if i read the 
right
archived patch review but it sounded like GUID is for internal to kernel only 
whereas
UUID is for external too? (in which case why are we not using GUID for 
gsc-proxy?)
Consider this a non-blocking inquiry since i assume mei folks have reviewed this
prior and this is an explicit design decision that I'm just not versed on.


AFAICS all other mei components use UUID_LE as well. The code was 
updated from GUID to UUID_LE in:

https://lore.kernel.org/all/20221228160558.21311-1-andriy.shevche...@linux.intel.com/

Daniele



alan:snip

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Define MOCS and PAT tables for MTL

[Andi Shyti]

On Thu, Apr 20, 2023 at 02:23:22PM -0700, Matt Roper wrote:
> On Thu, Apr 20, 2023 at 11:13:52PM +0200, Andi Shyti wrote:
> > From: Madhumitha Tolakanahalli Pradeep 
> > 
> > 
> > On MTL, GT can no longer allocate on LLC - only the CPU can.
> > This, along with addition of support for L4 cache calls for
> > a MOCS/PAT table update.
> > Also the PAT index registers are multicasted for primary GT,
> > and there is an address jump from index 7 to 8. This patch
> > makes sure that these registers are programmed in the proper
> > way.
> > 
> > BSpec: 44509, 45101, 44235
> > 
> > Cc: Matt Roper 
> > Cc: Lucas De Marchi 
> > Signed-off-by: Madhumitha Tolakanahalli Pradeep 
> > 
> > Signed-off-by: Aravind Iddamsetty 
> > Signed-off-by: Nirmoy Das 
> > Signed-off-by: Fei Yang 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Nirmoy Das 
> > Reviewed-by: Andi Shyti 
> > Signed-off-by: Andi Shyti 
> > ---
> > Hi,
> > 
> > just extracting this patch from Fei's series.
> 
> I just posted some feedback on Fei's series about an hour ago:
> 
> https://lore.kernel.org/intel-gfx/20230420202904.gy4085...@mdroper-desk1.amr.corp.intel.com/

Yes, sorry! I read your comments but I was in a patch sending
frenzy :-P

> Basically there's extra stuff in this patch that doesn't relate to the
> primary topic of defining the MOCS and PAT tables for MTL.  E.g., the
> PTE bits aren't used in this patch and should be moved to the following
> patch that deals with page table encoding (and at least one of those
> bits likely isn't correct from what I see in the bspec).

Yes... I made the same comment patches ago... I don't really mind
though, but I agree it's better to remove the parts we don't
need.

Andi

> Also the GSI changes at the bottom seem to be trying to work around a
> shortcoming of the selftest; it would likely be better to handle that in
> the selftest itself (which can probably be a separate patch).
> 
> 
> Matt
> 
> > 
> > Andi
> > 
> >  drivers/gpu/drm/i915/gt/intel_gt_regs.h |  6 +-
> >  drivers/gpu/drm/i915/gt/intel_gtt.c | 47 ++-
> >  drivers/gpu/drm/i915/gt/intel_gtt.h | 20 ++-
> >  drivers/gpu/drm/i915/gt/intel_mocs.c| 76 +++--
> >  drivers/gpu/drm/i915/gt/selftest_mocs.c |  2 +-
> >  5 files changed, 143 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index fd1f9cd35e9d7..e8c3b762a92a3 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -356,7 +356,11 @@
> >  #define GEN7_TLB_RD_ADDR   _MMIO(0x4700)
> >  
> >  #define GEN12_PAT_INDEX(index) _MMIO(0x4800 + (index) 
> > * 4)
> > -#define XEHP_PAT_INDEX(index)  MCR_REG(0x4800 + 
> > (index) * 4)
> > +#define _PAT_INDEX(index)  _PICK_EVEN_2RANGES(index, 8, \
> > +  0x4800, 
> > 0x4804, \
> > +  0x4848, 
> > 0x484c)
> > +#define XEHP_PAT_INDEX(index)  
> > MCR_REG(_PAT_INDEX(index))
> > +#define XELPMP_PAT_INDEX(index)_MMIO(_PAT_INDEX(index))
> >  
> >  #define XEHP_TILE0_ADDR_RANGE  MCR_REG(0x4900)
> >  #define   XEHP_TILE_LMEM_RANGE_SHIFT   8
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
> > b/drivers/gpu/drm/i915/gt/intel_gtt.c
> > index 4f436ba7a3c83..2f6a9be0ffe61 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> > @@ -468,6 +468,44 @@ void gtt_write_workarounds(struct intel_gt *gt)
> > }
> >  }
> >  
> > +static void xelpmp_setup_private_ppat(struct intel_uncore *uncore)
> > +{
> > +   intel_uncore_write(uncore, XELPMP_PAT_INDEX(0),
> > +  MTL_PPAT_L4_0_WB);
> > +   intel_uncore_write(uncore, XELPMP_PAT_INDEX(1),
> > +  MTL_PPAT_L4_1_WT);
> > +   intel_uncore_write(uncore, XELPMP_PAT_INDEX(2),
> > +  MTL_PPAT_L4_3_UC);
> > +   intel_uncore_write(uncore, XELPMP_PAT_INDEX(3),
> > +  MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
> > +   intel_uncore_write(uncore, XELPMP_PAT_INDEX(4),
> > +  MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
> > +
> > +   /*
> > +* Remaining PAT entries are left at the hardware-default
> > +* fully-cached setting
> > +*/
> > +}
> > +
> > +static void xelpg_setup_private_ppat(struct intel_gt *gt)
> > +{
> > +   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0),
> > +MTL_PPAT_L4_0_WB);
> > +   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1),
> > +MTL_PPAT_L4_1_WT);
> > +   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2),
> > +MTL_PPAT_L4_3_UC);
> > +   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3),
> > +   

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Add support for C20 phy

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add support for C20 phy
URL   : https://patchwork.freedesktop.org/series/116755/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13034_full -> Patchwork_116755v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-snb:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-snb1/igt@gem_pp...@blt-vs-render-ctxn.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/shard-snb1/igt@gem_pp...@blt-vs-render-ctxn.html

  * igt@i915_pm_rc6_residency@rc6-idle@bcs0:
- shard-apl:  [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-apl2/igt@i915_pm_rc6_residency@rc6-i...@bcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/shard-apl1/igt@i915_pm_rc6_residency@rc6-i...@bcs0.html

  
 Suppressed 

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

  * igt@kms_flip@2x-flip-vs-fences-interruptible:
- {shard-dg1}:NOTRUN -> [SKIP][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/shard-dg1-16/igt@kms_f...@2x-flip-vs-fences-interruptible.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@smoketest:
- shard-apl:  [PASS][6] -> [FAIL][7] ([i915#5099])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-apl2/igt@gem_ctx_persiste...@smoketest.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/shard-apl1/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_exec_endless@dispatch@rcs0:
- shard-apl:  [PASS][8] -> [TIMEOUT][9] ([i915#3778])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-apl1/igt@gem_exec_endless@dispa...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/shard-apl2/igt@gem_exec_endless@dispa...@rcs0.html

  * igt@gen9_exec_parse@allowed-single:
- shard-glk:  [PASS][10] -> [ABORT][11] ([i915#5566])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/shard-glk9/igt@gen9_exec_pa...@allowed-single.html

  * igt@kms_color@ctm-0-25@pipe-b-vga-1:
- shard-snb:  NOTRUN -> [SKIP][12] ([fdo#109271]) +6 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/shard-snb4/igt@kms_color@ctm-0...@pipe-b-vga-1.html

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

  * igt@perf@oa-exponents@0-rcs0:
- shard-glk:  [PASS][15] -> [ABORT][16] ([i915#5213])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-glk6/igt@perf@oa-expone...@0-rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/shard-glk1/igt@perf@oa-expone...@0-rcs0.html

  
 Possible fixes 

  * igt@gem_barrier_race@remote-request@rcs0:
- {shard-rkl}:[ABORT][17] ([i915#8211]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-rkl-7/igt@gem_barrier_race@remote-requ...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/shard-rkl-3/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][19] ([i915#6268]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-rkl-6/igt@gem_ctx_e...@basic-nohangcheck.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/shard-rkl-1/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_exec_endless@dispatch@rcs0:
- {shard-tglu}:   [TIMEOUT][21] ([i915#3778]) -> [PASS][22]
   [21]: 

Re: [Intel-gfx] [PATCH] drm/i915/mtl: workaround coherency issue for Media

[Matt Roper]

On Thu, Apr 20, 2023 at 01:38:59PM +0200, Nirmoy Das wrote:
> From: Fei Yang 
> 
> This patch implements Wa_22016122933.
> 
> In MTL, memory writes initiated by Media tile update the whole
> cache line even for partial writes. This creates a coherency
> problem for cacheable memory if both CPU and GPU are writing data
> to different locations within a single cache line. CTB communication
> is impacted by this issue because the head and tail pointers are
> adjacent words within a cache line (see struct guc_ct_buffer_desc),
> where one is written by GuC and the other by the host.
> This patch circumvents the issue by making CPU/GPU shared memory
> uncacheable (WC on CPU side, and PAT index 2 for GPU). Also for
> CTB which is being updated by both CPU and GuC, mfence instruction
> is added to make sure the CPU writes are visible to GPU right away
> (flush the write combining buffer).

I posted a note about the commit message here on the original series
about an hour ago:

https://lore.kernel.org/intel-gfx/20230420205238.ga4085...@mdroper-desk1.amr.corp.intel.com/

Patch itself looks fine, I just think the last sentence above should be
simplified to avoid inaccuracy.


Matt

> 
> While fixing the CTB issue, we noticed some random GSC firmware
> loading failure because the share buffers are cacheable (WB) on CPU
> side but uncached on GPU side. To fix these issues we need to map
> such shared buffers as WC on CPU side. Since such allocations are
> not all done through GuC allocator, to avoid too many code changes,
> the i915_coherent_map_type() is now hard coded to return WC for MTL.
> 
> BSpec: 45101
> 
> Signed-off-by: Fei Yang 
> Reviewed-by: Andi Shyti 
> Acked-by: Nirmoy Das 
> Reviewed-by: Andrzej Hajda 
> Signed-off-by: Nirmoy Das 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c |  5 -
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 13 +
>  drivers/gpu/drm/i915/gt/uc/intel_guc.c|  7 +++
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  6 ++
>  4 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index ecd86130b74f..89fc8ea6bcfc 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -469,7 +469,10 @@ enum i915_map_type i915_coherent_map_type(struct 
> drm_i915_private *i915,
> struct drm_i915_gem_object *obj,
> bool always_coherent)
>  {
> - if (i915_gem_object_is_lmem(obj))
> + /*
> +  * Wa_22016122933: always return I915_MAP_WC for MTL
> +  */
> + if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
>   return I915_MAP_WC;
>   if (HAS_LLC(i915) || always_coherent)
>   return I915_MAP_WB;
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> index 1d9fdfb11268..236673c02f9a 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> @@ -110,6 +110,13 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
>   if (obj->base.size < gsc->fw.size)
>   return -ENOSPC;
>  
> + /*
> +  * Wa_22016122933: For MTL the shared memory needs to be mapped
> +  * as WC on CPU side and UC (PAT index 2) on GPU side
> +  */
> + if (IS_METEORLAKE(i915))
> + i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
> +
>   dst = i915_gem_object_pin_map_unlocked(obj,
>  i915_coherent_map_type(i915, 
> obj, true));
>   if (IS_ERR(dst))
> @@ -125,6 +132,12 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
>   memset(dst, 0, obj->base.size);
>   memcpy(dst, src, gsc->fw.size);
>  
> + /*
> +  * Wa_22016122933: Making sure the data in dst is
> +  * visible to GSC right away
> +  */
> + intel_guc_write_barrier(>uc.guc);
> +
>   i915_gem_object_unpin_map(gsc->fw.obj);
>   i915_gem_object_unpin_map(obj);
>  
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index e89f16ecf1ae..c9f20385f6a0 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -744,6 +744,13 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
> *guc, u32 size)
>   if (IS_ERR(obj))
>   return ERR_CAST(obj);
>  
> + /*
> +  * Wa_22016122933: For MTL the shared memory needs to be mapped
> +  * as WC on CPU side and UC (PAT index 2) on GPU side
> +  */
> + if (IS_METEORLAKE(gt->i915))
> + i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
> +
>   vma = i915_vma_instance(obj, >ggtt->vm, NULL);
>   if (IS_ERR(vma))
>   goto err;
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> 

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Define MOCS and PAT tables for MTL

[Matt Roper]

On Thu, Apr 20, 2023 at 11:13:52PM +0200, Andi Shyti wrote:
> From: Madhumitha Tolakanahalli Pradeep 
> 
> 
> On MTL, GT can no longer allocate on LLC - only the CPU can.
> This, along with addition of support for L4 cache calls for
> a MOCS/PAT table update.
> Also the PAT index registers are multicasted for primary GT,
> and there is an address jump from index 7 to 8. This patch
> makes sure that these registers are programmed in the proper
> way.
> 
> BSpec: 44509, 45101, 44235
> 
> Cc: Matt Roper 
> Cc: Lucas De Marchi 
> Signed-off-by: Madhumitha Tolakanahalli Pradeep 
> 
> Signed-off-by: Aravind Iddamsetty 
> Signed-off-by: Nirmoy Das 
> Signed-off-by: Fei Yang 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Nirmoy Das 
> Reviewed-by: Andi Shyti 
> Signed-off-by: Andi Shyti 
> ---
> Hi,
> 
> just extracting this patch from Fei's series.

I just posted some feedback on Fei's series about an hour ago:

https://lore.kernel.org/intel-gfx/20230420202904.gy4085...@mdroper-desk1.amr.corp.intel.com/

Basically there's extra stuff in this patch that doesn't relate to the
primary topic of defining the MOCS and PAT tables for MTL.  E.g., the
PTE bits aren't used in this patch and should be moved to the following
patch that deals with page table encoding (and at least one of those
bits likely isn't correct from what I see in the bspec).

Also the GSI changes at the bottom seem to be trying to work around a
shortcoming of the selftest; it would likely be better to handle that in
the selftest itself (which can probably be a separate patch).


Matt

> 
> Andi
> 
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h |  6 +-
>  drivers/gpu/drm/i915/gt/intel_gtt.c | 47 ++-
>  drivers/gpu/drm/i915/gt/intel_gtt.h | 20 ++-
>  drivers/gpu/drm/i915/gt/intel_mocs.c| 76 +++--
>  drivers/gpu/drm/i915/gt/selftest_mocs.c |  2 +-
>  5 files changed, 143 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index fd1f9cd35e9d7..e8c3b762a92a3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -356,7 +356,11 @@
>  #define GEN7_TLB_RD_ADDR _MMIO(0x4700)
>  
>  #define GEN12_PAT_INDEX(index)   _MMIO(0x4800 + (index) 
> * 4)
> -#define XEHP_PAT_INDEX(index)MCR_REG(0x4800 + 
> (index) * 4)
> +#define _PAT_INDEX(index)_PICK_EVEN_2RANGES(index, 8, \
> +0x4800, 
> 0x4804, \
> +0x4848, 
> 0x484c)
> +#define XEHP_PAT_INDEX(index)
> MCR_REG(_PAT_INDEX(index))
> +#define XELPMP_PAT_INDEX(index)  _MMIO(_PAT_INDEX(index))
>  
>  #define XEHP_TILE0_ADDR_RANGEMCR_REG(0x4900)
>  #define   XEHP_TILE_LMEM_RANGE_SHIFT 8
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
> b/drivers/gpu/drm/i915/gt/intel_gtt.c
> index 4f436ba7a3c83..2f6a9be0ffe61 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> @@ -468,6 +468,44 @@ void gtt_write_workarounds(struct intel_gt *gt)
>   }
>  }
>  
> +static void xelpmp_setup_private_ppat(struct intel_uncore *uncore)
> +{
> + intel_uncore_write(uncore, XELPMP_PAT_INDEX(0),
> +MTL_PPAT_L4_0_WB);
> + intel_uncore_write(uncore, XELPMP_PAT_INDEX(1),
> +MTL_PPAT_L4_1_WT);
> + intel_uncore_write(uncore, XELPMP_PAT_INDEX(2),
> +MTL_PPAT_L4_3_UC);
> + intel_uncore_write(uncore, XELPMP_PAT_INDEX(3),
> +MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
> + intel_uncore_write(uncore, XELPMP_PAT_INDEX(4),
> +MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
> +
> + /*
> +  * Remaining PAT entries are left at the hardware-default
> +  * fully-cached setting
> +  */
> +}
> +
> +static void xelpg_setup_private_ppat(struct intel_gt *gt)
> +{
> + intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0),
> +  MTL_PPAT_L4_0_WB);
> + intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1),
> +  MTL_PPAT_L4_1_WT);
> + intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2),
> +  MTL_PPAT_L4_3_UC);
> + intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3),
> +  MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
> + intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4),
> +  MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
> +
> + /*
> +  * Remaining PAT entries are left at the hardware-default
> +  * fully-cached setting
> +  */
> +}
> +
>  static void tgl_setup_private_ppat(struct intel_uncore *uncore)
>  {
>   /* TGL doesn't support LLC or AGE settings */
> @@ -603,7 

[Intel-gfx] [PATCH] drm/i915/mtl: Define MOCS and PAT tables for MTL

[Andi Shyti]

From: Madhumitha Tolakanahalli Pradeep 


On MTL, GT can no longer allocate on LLC - only the CPU can.
This, along with addition of support for L4 cache calls for
a MOCS/PAT table update.
Also the PAT index registers are multicasted for primary GT,
and there is an address jump from index 7 to 8. This patch
makes sure that these registers are programmed in the proper
way.

BSpec: 44509, 45101, 44235

Cc: Matt Roper 
Cc: Lucas De Marchi 
Signed-off-by: Madhumitha Tolakanahalli Pradeep 

Signed-off-by: Aravind Iddamsetty 
Signed-off-by: Nirmoy Das 
Signed-off-by: Fei Yang 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Nirmoy Das 
Reviewed-by: Andi Shyti 
Signed-off-by: Andi Shyti 
---
Hi,

just extracting this patch from Fei's series.

Andi

 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  6 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c | 47 ++-
 drivers/gpu/drm/i915/gt/intel_gtt.h | 20 ++-
 drivers/gpu/drm/i915/gt/intel_mocs.c| 76 +++--
 drivers/gpu/drm/i915/gt/selftest_mocs.c |  2 +-
 5 files changed, 143 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index fd1f9cd35e9d7..e8c3b762a92a3 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -356,7 +356,11 @@
 #define GEN7_TLB_RD_ADDR   _MMIO(0x4700)
 
 #define GEN12_PAT_INDEX(index) _MMIO(0x4800 + (index) * 4)
-#define XEHP_PAT_INDEX(index)  MCR_REG(0x4800 + (index) * 4)
+#define _PAT_INDEX(index)  _PICK_EVEN_2RANGES(index, 8, \
+  0x4800, 
0x4804, \
+  0x4848, 
0x484c)
+#define XEHP_PAT_INDEX(index)  MCR_REG(_PAT_INDEX(index))
+#define XELPMP_PAT_INDEX(index)_MMIO(_PAT_INDEX(index))
 
 #define XEHP_TILE0_ADDR_RANGE  MCR_REG(0x4900)
 #define   XEHP_TILE_LMEM_RANGE_SHIFT   8
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 4f436ba7a3c83..2f6a9be0ffe61 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -468,6 +468,44 @@ void gtt_write_workarounds(struct intel_gt *gt)
}
 }
 
+static void xelpmp_setup_private_ppat(struct intel_uncore *uncore)
+{
+   intel_uncore_write(uncore, XELPMP_PAT_INDEX(0),
+  MTL_PPAT_L4_0_WB);
+   intel_uncore_write(uncore, XELPMP_PAT_INDEX(1),
+  MTL_PPAT_L4_1_WT);
+   intel_uncore_write(uncore, XELPMP_PAT_INDEX(2),
+  MTL_PPAT_L4_3_UC);
+   intel_uncore_write(uncore, XELPMP_PAT_INDEX(3),
+  MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
+   intel_uncore_write(uncore, XELPMP_PAT_INDEX(4),
+  MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
+
+   /*
+* Remaining PAT entries are left at the hardware-default
+* fully-cached setting
+*/
+}
+
+static void xelpg_setup_private_ppat(struct intel_gt *gt)
+{
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0),
+MTL_PPAT_L4_0_WB);
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1),
+MTL_PPAT_L4_1_WT);
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2),
+MTL_PPAT_L4_3_UC);
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3),
+MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4),
+MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
+
+   /*
+* Remaining PAT entries are left at the hardware-default
+* fully-cached setting
+*/
+}
+
 static void tgl_setup_private_ppat(struct intel_uncore *uncore)
 {
/* TGL doesn't support LLC or AGE settings */
@@ -603,7 +641,14 @@ void setup_private_pat(struct intel_gt *gt)
 
GEM_BUG_ON(GRAPHICS_VER(i915) < 8);
 
-   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
+   if (gt->type == GT_MEDIA) {
+   xelpmp_setup_private_ppat(gt->uncore);
+   return;
+   }
+
+   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+   xelpg_setup_private_ppat(gt);
+   else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
xehp_setup_private_ppat(gt);
else if (GRAPHICS_VER(i915) >= 12)
tgl_setup_private_ppat(uncore);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 69ce55f517f56..854ec09fd5888 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -88,9 +88,18 @@ typedef u64 gen8_pte_t;
 #define BYT_PTE_SNOOPED_BY_CPU_CACHES  REG_BIT(2)
 #define BYT_PTE_WRITEABLE  REG_BIT(1)
 
+#define 

Re: [Intel-gfx] [PATCH 6/8] drm/i915: preparation for using PAT index

[Matt Roper]

On Wed, Apr 19, 2023 at 04:00:56PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang 
> 
> This patch is a preparation for replacing enum i915_cache_level with PAT
> index. Caching policy for buffer objects is set through the PAT index in
> PTE, the old i915_cache_level is not sufficient to represent all caching
> modes supported by the hardware.
> 
> Preparing the transition by adding some platform dependent data structures
> and helper functions to translate the cache_level to pat_index.
> 
> cachelevel_to_pat: a platform dependent array mapping cache_level to
>pat_index.
> 
> max_pat_index: the maximum PAT index supported by the hardware. Needed for
>validating the PAT index passed in from user space.

The description here doesn't quite match how it's being used.  For
platforms like MTL, the hardware supports PAT indices 0-15.  The bspec
only gives us values to program for the first 5 of those entries and we
leave the rest at their hardware default (fully cached).  In the code
below, you're setting max_pat_index to the size of the bspec-defined
table (i.e., max=4 on MTL).  That's fine, but it means the description
here ("maximum...supported by hardware") is inaccurate.


Matt

> 
> i915_gem_get_pat_index: function to convert cache_level to PAT index.
> 
> obj_to_i915(obj): macro moved to header file for wider usage.
> 
> I915_MAX_CACHE_LEVEL: upper bound of i915_cache_level for the
>   convenience of coding.
> 
> Cc: Chris Wilson 
> Cc: Matt Roper 
> Cc: Andi Shyti 
> Signed-off-by: Fei Yang 
> Reviewed-by: Andi Shyti 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.c|  9 +++
>  drivers/gpu/drm/i915/gem/i915_gem_object.h|  4 +
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  1 +
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  2 -
>  drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  6 ++
>  drivers/gpu/drm/i915/gt/intel_ggtt.c  |  6 ++
>  drivers/gpu/drm/i915/i915_pci.c   | 75 +--
>  drivers/gpu/drm/i915/intel_device_info.h  |  5 ++
>  .../gpu/drm/i915/selftests/mock_gem_device.c  |  9 +++
>  9 files changed, 107 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 4666bb82f312..8c70a0ec7d2f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -45,6 +45,15 @@ static struct kmem_cache *slab_objects;
>  
>  static const struct drm_gem_object_funcs i915_gem_object_funcs;
>  
> +unsigned int i915_gem_get_pat_index(struct drm_i915_private *i915,
> + enum i915_cache_level level)
> +{
> + if (drm_WARN_ON(>drm, level >= I915_MAX_CACHE_LEVEL))
> + return 0;
> +
> + return INTEL_INFO(i915)->cachelevel_to_pat[level];
> +}
> +
>  struct drm_i915_gem_object *i915_gem_object_alloc(void)
>  {
>   struct drm_i915_gem_object *obj;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 885ccde9dc3c..4c92e17b4337 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -20,6 +20,8 @@
>  
>  enum intel_region_id;
>  
> +#define obj_to_i915(obj__) to_i915((obj__)->base.dev)
> +
>  static inline bool i915_gem_object_size_2big(u64 size)
>  {
>   struct drm_i915_gem_object *obj;
> @@ -30,6 +32,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
>   return false;
>  }
>  
> +unsigned int i915_gem_get_pat_index(struct drm_i915_private *i915,
> + enum i915_cache_level level);
>  void i915_gem_init__objects(struct drm_i915_private *i915);
>  
>  void i915_objects_module_exit(void);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index 830c11431ee8..41b35abccf88 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -194,6 +194,7 @@ enum i915_cache_level {
>* engine.
>*/
>   I915_CACHE_WT,
> + I915_MAX_CACHE_LEVEL,
>  };
>  
>  enum i915_map_type {
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> index b1672e054b21..214763942aa2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> @@ -460,8 +460,6 @@ void i915_gem_shrinker_taints_mutex(struct 
> drm_i915_private *i915,
>   fs_reclaim_release(GFP_KERNEL);
>  }
>  
> -#define obj_to_i915(obj__) to_i915((obj__)->base.dev)
> -
>  /**
>   * i915_gem_object_make_unshrinkable - Hide the object from the shrinker. By
>   * default all object types that support shrinking(see IS_SHRINKABLE), will 
> also
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index 

Re: [Intel-gfx] [PATCH 5/8] drm/i915/mtl: end support for set caching ioctl

[Matt Roper]

On Wed, Apr 19, 2023 at 04:00:55PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang 
> 
> The design is to keep Buffer Object's caching policy immutable through
> out its life cycle. This patch ends the support for set caching ioctl
> from MTL onward. While doing that we also set BO's to be 1-way coherent
> at creation time because GPU is no longer automatically snooping CPU
> cache. For UMD's need to fine tune the caching policy for BO's, a follow
> up patch will extend the GEM_CREATE uAPI to allow UMD's specify caching
> mode at BO creation time.

Nitpick:  I don't think "UMD" is a term that anyone really uses outside
of Intel.  It's probably better to just say "userspace" instead of
"UMD" since that's more accurate anyway.


Matt

> 
> Signed-off-by: Fei Yang 
> Reviewed-by: Andi Shyti 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
>  drivers/gpu/drm/i915/gem/i915_gem_shmem.c  | 9 -
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index d2d5a24301b2..bb3575b1479f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -337,6 +337,9 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
> void *data,
>   if (IS_DGFX(i915))
>   return -ENODEV;
>  
> + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
> + return -EOPNOTSUPP;
> +
>   switch (args->caching) {
>   case I915_CACHING_NONE:
>   level = I915_CACHE_NONE;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index 37d1efcd3ca6..cad4a6017f4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -601,7 +601,14 @@ static int shmem_object_init(struct intel_memory_region 
> *mem,
>   obj->write_domain = I915_GEM_DOMAIN_CPU;
>   obj->read_domains = I915_GEM_DOMAIN_CPU;
>  
> - if (HAS_LLC(i915))
> + /*
> +  * MTL doesn't snoop CPU cache by default for GPU access (namely
> +  * 1-way coherency). However some UMD's are currently depending on
> +  * that. Make 1-way coherent the default setting for MTL. A follow
> +  * up patch will extend the GEM_CREATE uAPI to allow UMD's specify
> +  * caching mode at BO creation time
> +  */
> + if (HAS_LLC(i915) || (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)))
>   /* On some devices, we can have the GPU use the LLC (the CPU
>* cache) for about a 10% performance improvement
>* compared to uncached.  Graphics requests other than
> -- 
> 2.25.1
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

Re: [Intel-gfx] [PATCH 4/8] drm/i915/mtl: workaround coherency issue for Media

[Matt Roper]

On Wed, Apr 19, 2023 at 04:00:54PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang 
> 
> This patch implements Wa_22016122933.
> 
> In MTL, memory writes initiated by Media tile update the whole
> cache line even for partial writes. This creates a coherency
> problem for cacheable memory if both CPU and GPU are writing data
> to different locations within a single cache line. CTB communication
> is impacted by this issue because the head and tail pointers are
> adjacent words within a cache line (see struct guc_ct_buffer_desc),
> where one is written by GuC and the other by the host.
> This patch circumvents the issue by making CPU/GPU shared memory
> uncacheable (WC on CPU side, and PAT index 2 for GPU). Also for
> CTB which is being updated by both CPU and GuC, mfence instruction
> is added to make sure the CPU writes are visible to GPU right away
> (flush the write combining buffer).

Is this description accurate?  This patch doesn't insert an mfence
instruction itself, it just calls intel_guc_write_barrier().  On
platforms like MTL that aren't using local memory, that issues a wmb()
barrier, which I believe is implemented as an sfence, not mfence.  You'd
need to be doing a mb() call to get an mfence.

I think in general this level of explanation is unnecessary; you can
just give a high-level description indicating that we force the
write-combine buffer to be flushed and not give the low-level specifics
of what instruction that translates to at the x86 level.

Aside from simplifying the commit message,

Reviewed-by: Matt Roper 

> 
> While fixing the CTB issue, we noticed some random GSC firmware
> loading failure because the share buffers are cacheable (WB) on CPU
> side but uncached on GPU side. To fix these issues we need to map
> such shared buffers as WC on CPU side. Since such allocations are
> not all done through GuC allocator, to avoid too many code changes,
> the i915_coherent_map_type() is now hard coded to return WC for MTL.
> 
> BSpec: 45101
> 
> Signed-off-by: Fei Yang 
> Reviewed-by: Andi Shyti 
> Acked-by: Nirmoy Das 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c |  5 -
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 13 +
>  drivers/gpu/drm/i915/gt/uc/intel_guc.c|  7 +++
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  6 ++
>  4 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index ecd86130b74f..89fc8ea6bcfc 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -469,7 +469,10 @@ enum i915_map_type i915_coherent_map_type(struct 
> drm_i915_private *i915,
> struct drm_i915_gem_object *obj,
> bool always_coherent)
>  {
> - if (i915_gem_object_is_lmem(obj))
> + /*
> +  * Wa_22016122933: always return I915_MAP_WC for MTL
> +  */
> + if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
>   return I915_MAP_WC;
>   if (HAS_LLC(i915) || always_coherent)
>   return I915_MAP_WB;
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> index 1d9fdfb11268..236673c02f9a 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> @@ -110,6 +110,13 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
>   if (obj->base.size < gsc->fw.size)
>   return -ENOSPC;
>  
> + /*
> +  * Wa_22016122933: For MTL the shared memory needs to be mapped
> +  * as WC on CPU side and UC (PAT index 2) on GPU side
> +  */
> + if (IS_METEORLAKE(i915))
> + i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
> +
>   dst = i915_gem_object_pin_map_unlocked(obj,
>  i915_coherent_map_type(i915, 
> obj, true));
>   if (IS_ERR(dst))
> @@ -125,6 +132,12 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
>   memset(dst, 0, obj->base.size);
>   memcpy(dst, src, gsc->fw.size);
>  
> + /*
> +  * Wa_22016122933: Making sure the data in dst is
> +  * visible to GSC right away
> +  */
> + intel_guc_write_barrier(>uc.guc);
> +
>   i915_gem_object_unpin_map(gsc->fw.obj);
>   i915_gem_object_unpin_map(obj);
>  
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index e89f16ecf1ae..c9f20385f6a0 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -744,6 +744,13 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
> *guc, u32 size)
>   if (IS_ERR(obj))
>   return ERR_CAST(obj);
>  
> + /*
> +  * Wa_22016122933: For MTL the shared memory needs to be mapped
> +  * as WC on CPU side and UC (PAT index 2) on GPU side
> +  */
> + 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: workaround coherency issue for Media

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: workaround coherency issue for Media
URL   : https://patchwork.freedesktop.org/series/116751/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13034_full -> Patchwork_116751v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rps@engine-order:
- shard-glk:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-glk1/igt@i915_pm_...@engine-order.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/shard-glk4/igt@i915_pm_...@engine-order.html

  
 Suppressed 

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

  * igt@kms_flip@2x-flip-vs-fences-interruptible:
- {shard-dg1}:NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/shard-dg1-16/igt@kms_f...@2x-flip-vs-fences-interruptible.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][4] -> [FAIL][5] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gen9_exec_parse@allowed-single:
- shard-apl:  [PASS][6] -> [ABORT][7] ([i915#5566])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-apl7/igt@gen9_exec_pa...@allowed-single.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/shard-apl7/igt@gen9_exec_pa...@allowed-single.html

  * igt@kms_color@ctm-0-25@pipe-b-vga-1:
- shard-snb:  NOTRUN -> [SKIP][8] ([fdo#109271]) +8 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/shard-snb7/igt@kms_color@ctm-0...@pipe-b-vga-1.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2346])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-glk8/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/shard-glk5/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html

  
 Possible fixes 

  * igt@gem_barrier_race@remote-request@rcs0:
- {shard-rkl}:[ABORT][11] ([i915#8211]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-rkl-7/igt@gem_barrier_race@remote-requ...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/shard-rkl-4/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][13] ([i915#6268]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-rkl-6/igt@gem_ctx_e...@basic-nohangcheck.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/shard-rkl-2/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_exec_endless@dispatch@rcs0:
- {shard-tglu}:   [TIMEOUT][15] ([i915#3778]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-tglu-8/igt@gem_exec_endless@dispa...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/shard-tglu-4/igt@gem_exec_endless@dispa...@rcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  [FAIL][17] ([i915#2846]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-apl4/igt@gem_exec_f...@basic-deadline.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/shard-apl6/igt@gem_exec_f...@basic-deadline.html
- shard-glk:  [FAIL][19] ([i915#2846]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/shard-glk7/igt@gem_exec_f...@basic-deadline.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/shard-glk6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][21] ([i915#2842]) -> [PASS][22] +1 

Re: [Intel-gfx] [PATCH 3/8] drm/i915/mtl: Add PTE encode function

[Matt Roper]

On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang 
> 
> PTE encode functions are platform dependent. This patch implements
> PTE functions for MTL, and ensures the correct PTE encode function
> is used by calling pte_encode function pointer instead of the
> hardcoded gen8 version of PTE encode.
> 
> Signed-off-by: Fei Yang 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Andi Shyti 
> Acked-by: Nirmoy Das 

Bspec: 45015, 45040

> ---
>  drivers/gpu/drm/i915/display/intel_dpt.c |  2 +-
>  drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45 
>  drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 +--
>  3 files changed, 72 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
> b/drivers/gpu/drm/i915/display/intel_dpt.c
> index b8027392144d..c5eacfdba1a5 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> @@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>   vm->vma_ops.bind_vma= dpt_bind_vma;
>   vm->vma_ops.unbind_vma  = dpt_unbind_vma;
>  
> - vm->pte_encode = gen8_ggtt_pte_encode;
> + vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
>  
>   dpt->obj = dpt_obj;
>   dpt->obj->is_dpt = true;
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index 4daaa6f55668..11b91e0453c8 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> @@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
>   return pte;
>  }
>  
> +static u64 mtl_pte_encode(dma_addr_t addr,
> +   enum i915_cache_level level,
> +   u32 flags)
> +{
> + gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
> +
> + if (unlikely(flags & PTE_READ_ONLY))
> + pte &= ~GEN8_PAGE_RW;
> +
> + if (flags & PTE_LM)
> + pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;

GEN12_PPGTT_PTE_NC got defined in the previous patch as BIT(5).  But
according to bspec 45040, bit 5 is ignored in the PTE encoding.  What is
this trying to do?


Matt

> +
> + switch (level) {
> + case I915_CACHE_NONE:
> + pte |= GEN12_PPGTT_PTE_PAT1;
> + break;
> + case I915_CACHE_LLC:
> + case I915_CACHE_L3_LLC:
> + pte |= GEN12_PPGTT_PTE_PAT0 | GEN12_PPGTT_PTE_PAT1;
> + break;
> + case I915_CACHE_WT:
> + pte |= GEN12_PPGTT_PTE_PAT0;
> + break;
> + }
> +
> + return pte;
> +}
> +
>  static void gen8_ppgtt_notify_vgt(struct i915_ppgtt *ppgtt, bool create)
>  {
>   struct drm_i915_private *i915 = ppgtt->vm.i915;
> @@ -427,7 +455,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
> u32 flags)
>  {
>   struct i915_page_directory *pd;
> - const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
> + const gen8_pte_t pte_encode = ppgtt->vm.pte_encode(0, cache_level, 
> flags);
>   gen8_pte_t *vaddr;
>  
>   pd = i915_pd_entry(pdp, gen8_pd_index(idx, 2));
> @@ -580,7 +608,7 @@ static void gen8_ppgtt_insert_huge(struct 
> i915_address_space *vm,
>  enum i915_cache_level cache_level,
>  u32 flags)
>  {
> - const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
> + const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
>   unsigned int rem = sg_dma_len(iter->sg);
>   u64 start = vma_res->start;
>  
> @@ -743,7 +771,7 @@ static void gen8_ppgtt_insert_entry(struct 
> i915_address_space *vm,
>   GEM_BUG_ON(pt->is_compact);
>  
>   vaddr = px_vaddr(pt);
> - vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
> + vaddr[gen8_pd_index(idx, 0)] = vm->pte_encode(addr, level, flags);
>   drm_clflush_virt_range([gen8_pd_index(idx, 0)], sizeof(*vaddr));
>  }
>  
> @@ -773,7 +801,7 @@ static void __xehpsdv_ppgtt_insert_entry_lm(struct 
> i915_address_space *vm,
>   }
>  
>   vaddr = px_vaddr(pt);
> - vaddr[gen8_pd_index(idx, 0) / 16] = gen8_pte_encode(addr, level, flags);
> + vaddr[gen8_pd_index(idx, 0) / 16] = vm->pte_encode(addr, level, flags);
>  }
>  
>  static void xehpsdv_ppgtt_insert_entry(struct i915_address_space *vm,
> @@ -820,8 +848,8 @@ static int gen8_init_scratch(struct i915_address_space 
> *vm)
>   pte_flags |= PTE_LM;
>  
>   vm->scratch[0]->encode =
> - gen8_pte_encode(px_dma(vm->scratch[0]),
> - I915_CACHE_NONE, pte_flags);
> + vm->pte_encode(px_dma(vm->scratch[0]),
> +I915_CACHE_NONE, pte_flags);
>  
>   for (i = 1; i <= vm->top; i++) {
>   struct drm_i915_gem_object *obj;
> @@ -963,7 +991,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
>*/
>   ppgtt->vm.alloc_scratch_dma = 

Re: [Intel-gfx] [PATCH 2/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

[Matt Roper]

On Wed, Apr 19, 2023 at 04:00:52PM -0700, fei.y...@intel.com wrote:
> From: Madhumitha Tolakanahalli Pradeep 
> 
> 
> On MTL, GT can no longer allocate on LLC - only the CPU can.
> This, along with addition of support for L4 cache calls for
> a MOCS/PAT table update.
> Also the PAT index registers are multicasted for primary GT,
> and there is an address jump from index 7 to 8. This patch
> makes sure that these registers are programmed in the proper
> way.
> 
> BSpec: 44509, 45101, 44235
> 
> Cc: Matt Roper 
> Cc: Lucas De Marchi 
> Signed-off-by: Madhumitha Tolakanahalli Pradeep 
> 
> Signed-off-by: Aravind Iddamsetty 
> Signed-off-by: Nirmoy Das 
> Signed-off-by: Fei Yang 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Nirmoy Das 
> Reviewed-by: Andi Shyti 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h |  6 +-
>  drivers/gpu/drm/i915/gt/intel_gtt.c | 47 ++-
>  drivers/gpu/drm/i915/gt/intel_gtt.h | 20 ++-
>  drivers/gpu/drm/i915/gt/intel_mocs.c| 76 +++--
>  drivers/gpu/drm/i915/gt/selftest_mocs.c |  2 +-
>  5 files changed, 143 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index fd1f9cd35e9d..e8c3b762a92a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -356,7 +356,11 @@
>  #define GEN7_TLB_RD_ADDR _MMIO(0x4700)
>  
>  #define GEN12_PAT_INDEX(index)   _MMIO(0x4800 + (index) 
> * 4)
> -#define XEHP_PAT_INDEX(index)MCR_REG(0x4800 + 
> (index) * 4)
> +#define _PAT_INDEX(index)_PICK_EVEN_2RANGES(index, 8, \
> +0x4800, 
> 0x4804, \
> +0x4848, 
> 0x484c)
> +#define XEHP_PAT_INDEX(index)
> MCR_REG(_PAT_INDEX(index))
> +#define XELPMP_PAT_INDEX(index)  _MMIO(_PAT_INDEX(index))
>  
>  #define XEHP_TILE0_ADDR_RANGEMCR_REG(0x4900)
>  #define   XEHP_TILE_LMEM_RANGE_SHIFT 8
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
> b/drivers/gpu/drm/i915/gt/intel_gtt.c
> index 4f436ba7a3c8..2f6a9be0ffe6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> @@ -468,6 +468,44 @@ void gtt_write_workarounds(struct intel_gt *gt)
>   }
>  }
>  
> +static void xelpmp_setup_private_ppat(struct intel_uncore *uncore)
> +{
> + intel_uncore_write(uncore, XELPMP_PAT_INDEX(0),
> +MTL_PPAT_L4_0_WB);
> + intel_uncore_write(uncore, XELPMP_PAT_INDEX(1),
> +MTL_PPAT_L4_1_WT);
> + intel_uncore_write(uncore, XELPMP_PAT_INDEX(2),
> +MTL_PPAT_L4_3_UC);
> + intel_uncore_write(uncore, XELPMP_PAT_INDEX(3),
> +MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
> + intel_uncore_write(uncore, XELPMP_PAT_INDEX(4),
> +MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
> +
> + /*
> +  * Remaining PAT entries are left at the hardware-default
> +  * fully-cached setting
> +  */
> +}
> +
> +static void xelpg_setup_private_ppat(struct intel_gt *gt)
> +{
> + intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0),
> +  MTL_PPAT_L4_0_WB);
> + intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1),
> +  MTL_PPAT_L4_1_WT);
> + intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2),
> +  MTL_PPAT_L4_3_UC);
> + intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3),
> +  MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
> + intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4),
> +  MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
> +
> + /*
> +  * Remaining PAT entries are left at the hardware-default
> +  * fully-cached setting
> +  */
> +}
> +
>  static void tgl_setup_private_ppat(struct intel_uncore *uncore)
>  {
>   /* TGL doesn't support LLC or AGE settings */
> @@ -603,7 +641,14 @@ void setup_private_pat(struct intel_gt *gt)
>  
>   GEM_BUG_ON(GRAPHICS_VER(i915) < 8);
>  
> - if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
> + if (gt->type == GT_MEDIA) {
> + xelpmp_setup_private_ppat(gt->uncore);
> + return;
> + }
> +
> + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
> + xelpg_setup_private_ppat(gt);
> + else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
>   xehp_setup_private_ppat(gt);
>   else if (GRAPHICS_VER(i915) >= 12)
>   tgl_setup_private_ppat(uncore);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
> b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index 69ce55f517f5..854ec09fd588 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> 

Re: [Intel-gfx] [PATCH 4/4] drm/i915/gsc: add support for GSC proxy interrupt

[Ceraolo Spurio, Daniele]

On 4/20/2023 11:49 AM, Teres Alexis, Alan Previn wrote:

On Wed, 2023-03-29 at 09:56 -0700, Ceraolo Spurio, Daniele wrote:

The GSC notifies us of a proxy request via the HECI2 interrupt. The

alan:snip


@@ -256,6 +262,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
u32 irqs = GT_RENDER_USER_INTERRUPT;
u32 guc_mask = intel_uc_wants_guc(>uc) ? GUC_INTR_GUC2HOST : 0;
u32 gsc_mask = 0;
+   u32 heci_mask = 0;

alan: nit: should we call this heci2_mask - uniquely identifiable from legacy.


The mask is theoretically not just for HECI2, the bit we set in it is. 
If future platforms add back the HECI1 interrupt then it'd go in the 
same mask.





alan:snip


-   else if (HAS_HECI_GSC(gt->i915))
+   heci_mask = GSC_IRQ_INTF(1); /* HECI2 IRQ for SW Proxy*/

alan: does this GSC_IRQ_INTF macro still make sense for this newer platforms 
with GSC-CS / HECI2?
i dont think i see other bit definitions for this mask register, so might else 
well just define it as BIT14?


GSC_IRQ_INTF(1) is the HECI2 interrupt on DG2 and the bit has remained 
the same exactly to allow SW to re-use the same code/defines, so IMO we 
should do so.




alan:snip




diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 4aecb5a7b631..da11ce5ca99e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1577,6 +1577,7 @@
  
  #define GEN11_GT_INTR_DW(x)			_MMIO(0x190018 + ((x) * 4))

  #define   GEN11_CSME  (31)
+#define   GEN12_HECI_2 (30)

alan: I dont see this being used anywhere - should remove this.


A few of the defines for this register here are not used. I've added 
this one in as a way of documenting where the bit was, but I can remove 
it if you think it's unneeded.





+#define GEN11_HECI2_RSVD_INTR_MASK _MMIO(0x1900e4)

alan: GEN11? don't you mean GEN12?



Yup, this should be GEN12






+void intel_gsc_proxy_irq_handler(struct intel_gsc_uc *gsc, u32 iir)
+{
+   struct intel_gt *gt = gsc_uc_to_gt(gsc);
+
+   if (unlikely(!iir))
+   return;
+
+   lockdep_assert_held(gt->irq_lock);
+
+   if (!gsc->proxy.component) {
+   gt_err(gt, "GSC proxy irq received without the component being 
bound!\n");

alan: So although proxy init is only a one-time thing (even surviving 
suspend-resume), we
know that proxy runtime irqs could happen anytime (depending on other 
gpu-security-related
system interactions). However, would the component driver be bound/unbound 
through a
suspend-resume cycle? If yes, then would this check fail if an IRQ for a proxy 
request
came too early after a resume cycle. If yes, then should we not do somethign 
here to ensure that
when the component gets bound later, we know there is something waiting to be 
processed?
(in bind, if proxy-init was done before, but we have outstanding IRQs, then we 
can trigger
the worker from there, i.e. the bind func?)


A proxy request can only be triggered in response to a userspace ask, 
which in turn can only happen once we've completed the resume flow and 
the component is re-bound. Therefore, we should never have a situation 
where we get a proxy interrupt without the component being bound.




alan:snip


  static int i915_gsc_proxy_component_bind(struct device *i915_kdev,
 struct device *tee_kdev, void *data)
  {
struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
-   struct intel_gsc_uc *gsc = >media_gt->uc.gsc;
+   struct intel_gt *gt = i915->media_gt;
+   struct intel_gsc_uc *gsc = >uc.gsc;
+   intel_wakeref_t wakeref;
+
+   /* enable HECI2 IRQs */
+   with_intel_runtime_pm(>runtime_pm, wakeref)
+   intel_uncore_rmw(gt->uncore, HECI_H_CSR(MTL_GSC_HECI2_BASE),
+0, HECI_H_CSR_IE);

alan: i notice we don't seem to care about potentially re-writing a '1' into 
reset
if it was midst reset when we read. Shouldn't we also protect against that here?


Yeah, I'll add that in



alan:snip



diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
index 023bded10dde..a2a0813b8a76 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
@@ -23,6 +23,9 @@ struct intel_gsc_uc {
/* for delayed load and proxy handling */
struct workqueue_struct *wq;
struct work_struct work;
+   u32 gsc_work_actions; /* protected by gt->irq_lock */
+#define GSC_ACTION_FW_LOAD BIT(0)
+#define GSC_ACTION_SW_PROXY BIT(1


alan: perhaps its time to have a substruct for "proxy_worker" and include
'wq' and 'work' in additional to actions?


The worker is not just for proxy, we use it for a GSC and HuC loading as 
well. It's the main way we handle the gsc_uc, so IMO it's better off 
staying in the main struct. However, if you still 

Re: [Intel-gfx] [PATCH 9/9] drm/i915/pmu: Enable legacy PMU events for MTL

[Umesh Nerlige Ramappa]

On Fri, Mar 31, 2023 at 02:02:40PM +0100, Tvrtko Ursulin wrote:


On 30/03/2023 19:31, Umesh Nerlige Ramappa wrote:

+ Joonas for comments on this

On Thu, Mar 30, 2023 at 02:38:03PM +0100, Tvrtko Ursulin wrote:


On 30/03/2023 01:41, Umesh Nerlige Ramappa wrote:

MTL introduces separate GTs for render and media. This complicates the
definition of frequency and rc6 counters for the GPU as a whole since
each GT has an independent counter. The best way to support this change
is to deprecate the GPU-specific counters and create GT-specific
counters, however that just breaks ABI. Since perf tools and scripts may
be decentralized with probably many users, it's hard to deprecate the
legacy counters and have all the users on board with that.

Re-introduce the legacy counters and support them as min/max of
GT-specific counters as necessary to ensure backwards compatibility.

I915_PMU_ACTUAL_FREQUENCY - will show max of GT-specific counters
I915_PMU_REQUESTED_FREQUENCY - will show max of GT-specific counters
I915_PMU_INTERRUPTS - no changes since it is GPU specific on all 
platforms

I915_PMU_RC6_RESIDENCY - will show min of GT-specific counters
I915_PMU_SOFTWARE_GT_AWAKE_TIME - will show max of GT-specific counters


IMO max/min games are _very_ low value and probably just confusing.


By value, do you mean ROI or actually that the values would be incorrect?


Both really.

I am not convinced we need to burden the kernel with this. New 
platform, new counters.. userspace can just deal with it.


I agree and would prefer to drop this patch. There are some counter 
arguments, I have added Joonas here for comments.


1) an app/script hard-coded with the legacy events would be used on 
a new platform and fail and we should maintain backwards 
compatibility.


I thought we pretty much agreed multiple times in the past (on 
different topics) that a new platform can require new userspace.


PMU is probably even a more clear cut case since it is exposing 
hardware counters (or close) so sometimes it is not even theoretically 
possible to preserve "backward" compatibility.


(I double quote backward because I think real backward compatibility 
does not apply on a new platform. And MTL is under force probe still.)


So for me it all comes under the "would be nice" category. But since 
we need to add kernel code to do it, code which asy intel_gpu_top 
could run in userspace, I am not at all convinced it wouldn't be a bad 
idea.


The aggregated counters wouldn't even be giving the full picture.

So I'd simply add tiles/gt support to intel_gpu_top. Same as it 
currently can do "-p" on the command line, or '1' in the interactive 
mode, to aggregate the engine classes into one line item, I'd extend 
that concept into frequencies and RC6.


By default we start with normalized values and in physical mode we 
show separate counters per tile/gt.


Someone running old intel_gpu_top on MTL gets to see nothing since the 
counter names are different. Which is IMO fine - better than showing 
tile 0 data, or some minimums/maximums from one tile only.


2) the sysfs attributes for rc6/frequency have already adopted an 
aggregate vs gt0/gt1 approach to address that and pmu should have a 
similar solution (or rather, PMU and the sysfs approaches should 
match based on whatever is the approach)


Yeah I disagreed with min/max reads in sysfs too and am pretty sure I 
expressed that at the time. :shrug:


But I don't think there is a strong argument that PMU needs to follow.

Only impact is to people who access perf_event_open directly so yeah, 
if there are such users, they will need to add multi-tile support.


I discussed with Joonas offline and I guess I had a wrong idea regarding 
ABI. Looks like ABI is only broken if we remove something that existed 
for a platform, so this does not break ABI for MTL. The motivation was 
to have per-platform differences smaller for applications/UMD.


The other aspect he pointed out was that we should not push anything 
that does not have an IGT. For aggregate events, we do not have any 
plans to support IGTs (large effort as well as no clear way to support 
such aggregation).


In short, I will drop this patch and post what you originally had for 
multi-gt PMU support.


Thanks,
Umesh


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 4/5] drm/i915/mtl: Synchronize i915/BIOS on C6 enabling

[Umesh Nerlige Ramappa]

On Thu, Mar 16, 2023 at 01:25:48PM -0700, Radhakrishna Sripada wrote:

From: Vinay Belgaumkar 

If BIOS enables/disables C6, i915 should do the same. Also, retain
this value across driver reloads. This is needed only for MTL as
of now due to an existing bug in OA which needs C6 disabled for
it to function. BIOS behavior is also different across platforms
in terms of how C6 is enabled.

v2: Review comments (Umesh)
v3: Cache the C6 enable value for all MTL. The OA WA is needed only
for A/B step, but we don't need to check for that here.
v4: Rename to mtl_check_bios_c6_setup()

Signed-off-by: Vinay Belgaumkar 
Signed-off-by: Radhakrishna Sripada 


This one's already pushed with the MTL OA series.

Regards,
Umesh

Re: [Intel-gfx] [PATCH 4/4] drm/i915/gsc: add support for GSC proxy interrupt

[Teres Alexis, Alan Previn]

On Wed, 2023-03-29 at 09:56 -0700, Ceraolo Spurio, Daniele wrote:
> The GSC notifies us of a proxy request via the HECI2 interrupt. The

alan:snip

> @@ -256,6 +262,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
>   u32 irqs = GT_RENDER_USER_INTERRUPT;
>   u32 guc_mask = intel_uc_wants_guc(>uc) ? GUC_INTR_GUC2HOST : 0;
>   u32 gsc_mask = 0;
> + u32 heci_mask = 0;
alan: nit: should we call this heci2_mask - uniquely identifiable from legacy.


alan:snip

> - else if (HAS_HECI_GSC(gt->i915))
> + heci_mask = GSC_IRQ_INTF(1); /* HECI2 IRQ for SW Proxy*/
alan: does this GSC_IRQ_INTF macro still make sense for this newer platforms 
with GSC-CS / HECI2?
i dont think i see other bit definitions for this mask register, so might else 
well just define it as BIT14?

alan:snip



> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 4aecb5a7b631..da11ce5ca99e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1577,6 +1577,7 @@
>  
>  #define GEN11_GT_INTR_DW(x)  _MMIO(0x190018 + ((x) * 4))
>  #define   GEN11_CSME (31)
> +#define   GEN12_HECI_2   (30)
alan: I dont see this being used anywhere - should remove this.

> +#define GEN11_HECI2_RSVD_INTR_MASK   _MMIO(0x1900e4)
alan: GEN11? don't you mean GEN12?





> +void intel_gsc_proxy_irq_handler(struct intel_gsc_uc *gsc, u32 iir)
> +{
> + struct intel_gt *gt = gsc_uc_to_gt(gsc);
> +
> + if (unlikely(!iir))
> + return;
> +
> + lockdep_assert_held(gt->irq_lock);
> +
> + if (!gsc->proxy.component) {
> + gt_err(gt, "GSC proxy irq received without the component being 
> bound!\n");
alan: So although proxy init is only a one-time thing (even surviving 
suspend-resume), we
know that proxy runtime irqs could happen anytime (depending on other 
gpu-security-related
system interactions). However, would the component driver be bound/unbound 
through a
suspend-resume cycle? If yes, then would this check fail if an IRQ for a proxy 
request
came too early after a resume cycle. If yes, then should we not do somethign 
here to ensure that
when the component gets bound later, we know there is something waiting to be 
processed?
(in bind, if proxy-init was done before, but we have outstanding IRQs, then we 
can trigger
the worker from there, i.e. the bind func?)

alan:snip

>  static int i915_gsc_proxy_component_bind(struct device *i915_kdev,
>struct device *tee_kdev, void *data)
>  {
>   struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
> - struct intel_gsc_uc *gsc = >media_gt->uc.gsc;
> + struct intel_gt *gt = i915->media_gt;
> + struct intel_gsc_uc *gsc = >uc.gsc;
> + intel_wakeref_t wakeref;
> +
> + /* enable HECI2 IRQs */
> + with_intel_runtime_pm(>runtime_pm, wakeref)
> + intel_uncore_rmw(gt->uncore, HECI_H_CSR(MTL_GSC_HECI2_BASE),
> +  0, HECI_H_CSR_IE);
alan: i notice we don't seem to care about potentially re-writing a '1' into 
reset
if it was midst reset when we read. Shouldn't we also protect against that here?

alan:snip


> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> index 023bded10dde..a2a0813b8a76 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> @@ -23,6 +23,9 @@ struct intel_gsc_uc {
>   /* for delayed load and proxy handling */
>   struct workqueue_struct *wq;
>   struct work_struct work;
> + u32 gsc_work_actions; /* protected by gt->irq_lock */
> +#define GSC_ACTION_FW_LOAD BIT(0)
> +#define GSC_ACTION_SW_PROXY BIT(1
> 
alan: perhaps its time to have a substruct for "proxy_worker" and include
'wq' and 'work' in additional to actions?
> )
>  
>   struct {
>   struct i915_gsc_proxy_component *component;

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Initialize dkl_phy spin lock from display code path (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Initialize dkl_phy spin lock from display code path (rev4)
URL   : https://patchwork.freedesktop.org/series/116325/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13034 -> Patchwork_116325v4


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (37 -> 36)
--

  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@reset:
- bat-rpls-1: NOTRUN -> [ABORT][1] ([i915#4983])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-adlp-6: NOTRUN -> [SKIP][2] ([i915#7828])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/bat-adlp-6/igt@kms_chamelium_...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@i915_selftest@live@mman:
- bat-rpls-1: [TIMEOUT][3] ([i915#6794]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-rpls-1/igt@i915_selftest@l...@mman.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/bat-rpls-1/igt@i915_selftest@l...@mman.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-adlp-6: [INCOMPLETE][5] ([i915#7443]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-adlp-6/igt@i915_susp...@basic-s3-without-i915.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/bat-adlp-6/igt@i915_susp...@basic-s3-without-i915.html

  
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
  [i915#7443]: https://gitlab.freedesktop.org/drm/intel/issues/7443
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828


Build changes
-

  * Linux: CI_DRM_13034 -> Patchwork_116325v4

  CI-20190529: 20190529
  CI_DRM_13034: bf6a3fbb5a6d7afbbaeb93043fd0001d6b83591b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7263: a6bd8f415c4ec41b5a014c7db47e46c81ffd0074 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116325v4: bf6a3fbb5a6d7afbbaeb93043fd0001d6b83591b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

e70aaa9d3ace drm/i915: Initialize dkl_phy spin lock from display code path

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v4/index.html

Re: [Intel-gfx] [Intel-xe] [PATCH v4] drm/i915: Initialize dkl_phy spin lock from display code path

[Souza, Jose]

On Thu, 2023-04-20 at 09:35 -0700, Lucas De Marchi wrote:
> On Thu, Apr 20, 2023 at 08:36:37AM -0700, Jose Souza wrote:
> > On Thu, 2023-04-20 at 11:27 -0400, Rodrigo Vivi wrote:
> > > On Thu, Apr 20, 2023 at 09:19:09AM -0400, Souza, Jose wrote:
> > > > On Wed, 2023-04-19 at 00:29 -0700, Lucas De Marchi wrote:
> > > > > On Wed, Apr 19, 2023 at 10:16:22AM +0300, Jani Nikula wrote:
> > > > > > On Tue, 18 Apr 2023, Lucas De Marchi  
> > > > > > wrote:
> > > > > > > On Tue, Apr 18, 2023 at 11:30:18PM -0700, Lucas De Marchi wrote:
> > > > > > > > On Tue, Apr 18, 2023 at 09:43:37AM -0700, Jose Souza wrote:
> > > > > > > > > Start to move the initialization of display locks from
> > > > > > > > > i915_driver_early_probe(), this way it is also executed when 
> > > > > > > > > running
> > > > > > > > > Xe kmd.
> > > > > > > > > 
> > > > > > > > > This will fix a warning in Xe kmd:
> > > > > > > > > 
> > > > > > > > > [  201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY 
> > > > > > > > > A] failed to retrieve link info, disabling eDP
> > > > > > > > > [  202.136336] xe :00:02.0: [drm] *ERROR* Failed to write 
> > > > > > > > > source OUI
> > > > > > > > > [  202.175346] INFO: trying to register non-static key.
> > > > > > > > > [  202.175347] irq event stamp: 754060
> > > > > > > > > [  202.175359] hardirqs last  enabled at (754059): 
> > > > > > > > > [] tick_nohz_idle_enter+0x59/0x80
> > > > > > > > > [  202.180294] The code is fine but needs lockdep annotation, 
> > > > > > > > > or maybe
> > > > > > > > > [  202.183774] hardirqs last disabled at (754060): 
> > > > > > > > > [] do_idle+0x99/0x230
> > > > > > > > > [  202.192734] you didn't initialize this object before use?
> > > > > > > > > [  202.198951] softirqs last  enabled at (753948): 
> > > > > > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > > > > > [  202.206882] turning off the locking correctness validator.
> > > > > > > > > [  202.212236] softirqs last disabled at (753943): 
> > > > > > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > > > > > [  202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: G 
> > > > > > > > >W  6.3.0-rc4+zeh-xe+ #909
> > > > > > > > > [  202.243002] Hardware name: Intel Corporation Raptor Lake 
> > > > > > > > > Client Platform/RaptorLake-P LP5 RVP, BIOS 
> > > > > > > > > RPLPFWI1.R00.3361.A14.2211151548 11/15/2022
> > > > > > > > > [  202.255737] Call Trace:
> > > > > > > > > [  202.258179]  
> > > > > > > > > [  202.260275]  dump_stack_lvl+0x58/0xc0
> > > > > > > > > [  202.263922]  register_lock_class+0x756/0x7d0
> > > > > > > > > [  202.268165]  ? find_held_lock+0x2b/0x80
> > > > > > > > > [  202.271975]  __lock_acquire+0x72/0x28b0
> > > > > > > > > [  202.275786]  ? debug_object_free+0xb4/0x160
> > > > > > > > > [  202.279946]  lock_acquire+0xd1/0x2d0
> > > > > > > > > [  202.283503]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > > > [  202.288181]  _raw_spin_lock+0x2a/0x40
> > > > > > > > > [  202.291825]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > > > [  202.296475]  intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > > > [  202.300949]  icl_aux_power_well_enable+0x2bd/0x400 [xe]
> > > > > > > > > [  202.306202]  ? 
> > > > > > > > > intel_display_power_grab_async_put_ref+0x75/0x120 [xe]
> > > > > > > > > [  202.312649]  intel_power_well_enable+0x1c/0x70 [xe]
> > > > > > > > > [  202.317543]  
> > > > > > > > > __intel_display_power_get_domain.part.0+0x4d/0x70 [xe]
> > > > > > > > > [  202.323812]  intel_display_power_get+0x43/0x70 [xe]
> > > > > > > > > [  202.328708]  intel_tc_port_init+0x199/0x2a0 [xe]
> > > > > > > > > [  202.63]  intel_ddi_init+0x6ad/0xb00 [xe]
> > > > > > > > > [  202.337678]  intel_modeset_init_nogem+0x536/0x6d0 [xe]
> > > > > > > > > [  202.342838]  xe_display_init_noaccel+0x19/0x40 [xe]
> > > > > > > > > [  202.347743]  xe_device_probe+0x1f5/0x2a0 [xe]
> > > > > > > > > [  202.352127]  xe_pci_probe+0x28c/0x480 [xe]
> > > > > > > > > [  202.356260]  pci_device_probe+0x9d/0x150
> > > > > > > > > [  202.360164]  really_probe+0x19a/0x400
> > > > > > > > > [  202.363809]  ? __pfx___driver_attach+0x10/0x10
> > > > > > > > > [  202.368226]  __driver_probe_device+0x73/0x170
> > > > > > > > > [  202.372558]  driver_probe_device+0x1a/0x90
> > > > > > > > > [  202.376632]  __driver_attach+0xcd/0x1c0
> > > > > > > > > [  202.380442]  bus_for_each_dev+0x72/0xc0
> > > > > > > > > [  202.384253]  bus_add_driver+0x110/0x210
> > > > > > > > > [  202.388063]  driver_register+0x50/0x100
> > > > > > > > > [  202.391873]  ? __pfx_init_module+0x10/0x10 [xe]
> > > > > > > > > [  202.396431]  do_one_initcall+0x55/0x260
> > > > > > > > > [  202.400245]  ? rcu_is_watching+0xd/0x40
> > > > > > > > > [  202.404058]  ? kmalloc_trace+0xa0/0xb0
> > > > > > > > > [  202.407786]  do_init_module+0x45/0x1e0
> > > > > > > > > [  202.411512]  __do_sys_finit_module+0xac/0x120
> > > > > > > > > [  202.415838]  do_syscall_64+0x37/0x90
> > > > > > > > > [  202.419397]  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Disable PL1 power limit when loading GuC firmware

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Disable PL1 power limit when loading GuC firmware
URL   : https://patchwork.freedesktop.org/series/116768/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13034 -> Patchwork_116768v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (37 -> 35)
--

  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@requests:
- bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#4983] / [i915#7911])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/bat-rpls-1/igt@i915_selftest@l...@requests.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-adlp-6: NOTRUN -> [SKIP][3] ([i915#7828])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/bat-adlp-6/igt@kms_chamelium_...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@i915_suspend@basic-s3-without-i915:
- bat-adlp-6: [INCOMPLETE][4] ([i915#7443]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-adlp-6/igt@i915_susp...@basic-s3-without-i915.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/bat-adlp-6/igt@i915_susp...@basic-s3-without-i915.html

  
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#7443]: https://gitlab.freedesktop.org/drm/intel/issues/7443
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911


Build changes
-

  * Linux: CI_DRM_13034 -> Patchwork_116768v1

  CI-20190529: 20190529
  CI_DRM_13034: bf6a3fbb5a6d7afbbaeb93043fd0001d6b83591b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7263: a6bd8f415c4ec41b5a014c7db47e46c81ffd0074 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116768v1: bf6a3fbb5a6d7afbbaeb93043fd0001d6b83591b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

39178baf855c drm/i915/hwmon: Block waiting for GuC reset to complete
d6f8cf406cba drm/i915/guc: Disable PL1 power limit when loading GuC firmware
1341c465cd24 drm/i915/hwmon: Get mutex and rpm ref just once in 
hwm_power_max_write

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/index.html

[Intel-gfx] [PATCH v5] drm/i915: Initialize dkl_phy spin lock from display code path

[José Roberto de Souza]

drm/i915: Initialize dkl_phy spin lock from display code path

Start moving the initialization of display locks from
i915_driver_early_probe().
Display locks should be initialized from display-only code paths.

It was also agreed that if a variable is only used in one file, it
should be initialized only in that file, so intel_dkl_phy_init() was
added.

v2:
- added intel_display_locks_init()

v3:
- rebased

v4:
- dropped intel_display_locks_init()

v5:
- moved intel_dkl_phy_init() to the beginning of file

Cc: intel-gfx@lists.freedesktop.org
Cc: Rodrigo Vivi 
Cc: Ville Syrjälä 
Cc: Jani Nikula 
Cc: Maarten Lankhorst 
Reviewed-by: Lucas De Marchi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display_driver.c | 2 ++
 drivers/gpu/drm/i915/display/intel_dkl_phy.c| 9 +
 drivers/gpu/drm/i915/display/intel_dkl_phy.h| 1 +
 drivers/gpu/drm/i915/i915_driver.c  | 1 -
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c 
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index b3dbfe2a892e6..60ce10fc72058 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -30,6 +30,7 @@
 #include "intel_display_driver.h"
 #include "intel_display_power.h"
 #include "intel_display_types.h"
+#include "intel_dkl_phy.h"
 #include "intel_dmc.h"
 #include "intel_dp.h"
 #include "intel_dpll.h"
@@ -175,6 +176,7 @@ void intel_display_driver_early_probe(struct 
drm_i915_private *i915)
if (!HAS_DISPLAY(i915))
return;
 
+   intel_dkl_phy_init(i915);
intel_color_init_hooks(i915);
intel_init_cdclk_hooks(i915);
intel_audio_hooks_init(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_dkl_phy.c 
b/drivers/gpu/drm/i915/display/intel_dkl_phy.c
index 57cc3edba0163..a001232ad445e 100644
--- a/drivers/gpu/drm/i915/display/intel_dkl_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_dkl_phy.c
@@ -11,6 +11,15 @@
 #include "intel_dkl_phy.h"
 #include "intel_dkl_phy_regs.h"
 
+/**
+ * intel_dkl_phy_init - initialize Dekel PHY
+ * @i915: i915 device instance
+ */
+void intel_dkl_phy_init(struct drm_i915_private *i915)
+{
+   spin_lock_init(>display.dkl.phy_lock);
+}
+
 static void
 dkl_phy_set_hip_idx(struct drm_i915_private *i915, struct intel_dkl_phy_reg 
reg)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_dkl_phy.h 
b/drivers/gpu/drm/i915/display/intel_dkl_phy.h
index 570ee36f9386f..5956ec3e940b1 100644
--- a/drivers/gpu/drm/i915/display/intel_dkl_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_dkl_phy.h
@@ -12,6 +12,7 @@
 
 struct drm_i915_private;
 
+void intel_dkl_phy_init(struct drm_i915_private *i915);
 u32
 intel_dkl_phy_read(struct drm_i915_private *i915, struct intel_dkl_phy_reg 
reg);
 void
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index a52db8a809006..fd198700272b1 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -223,7 +223,6 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
mutex_init(_priv->display.wm.wm_mutex);
mutex_init(_priv->display.pps.mutex);
mutex_init(_priv->display.hdcp.comp_mutex);
-   spin_lock_init(_priv->display.dkl.phy_lock);
 
i915_memcpy_init_early(dev_priv);
intel_runtime_pm_init_early(_priv->runtime_pm);
-- 
2.40.0

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Disable PL1 power limit when loading GuC firmware

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Disable PL1 power limit when loading GuC firmware
URL   : https://patchwork.freedesktop.org/series/116768/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 

Re: [Intel-gfx] [Intel-xe] [PATCH v4] drm/i915: Initialize dkl_phy spin lock from display code path

[Lucas De Marchi]

On Thu, Apr 20, 2023 at 08:36:37AM -0700, Jose Souza wrote:

On Thu, 2023-04-20 at 11:27 -0400, Rodrigo Vivi wrote:

On Thu, Apr 20, 2023 at 09:19:09AM -0400, Souza, Jose wrote:
> On Wed, 2023-04-19 at 00:29 -0700, Lucas De Marchi wrote:
> > On Wed, Apr 19, 2023 at 10:16:22AM +0300, Jani Nikula wrote:
> > > On Tue, 18 Apr 2023, Lucas De Marchi  wrote:
> > > > On Tue, Apr 18, 2023 at 11:30:18PM -0700, Lucas De Marchi wrote:
> > > > > On Tue, Apr 18, 2023 at 09:43:37AM -0700, Jose Souza wrote:
> > > > > > Start to move the initialization of display locks from
> > > > > > i915_driver_early_probe(), this way it is also executed when running
> > > > > > Xe kmd.
> > > > > >
> > > > > > This will fix a warning in Xe kmd:
> > > > > >
> > > > > > [  201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] 
failed to retrieve link info, disabling eDP
> > > > > > [  202.136336] xe :00:02.0: [drm] *ERROR* Failed to write 
source OUI
> > > > > > [  202.175346] INFO: trying to register non-static key.
> > > > > > [  202.175347] irq event stamp: 754060
> > > > > > [  202.175359] hardirqs last  enabled at (754059): 
[] tick_nohz_idle_enter+0x59/0x80
> > > > > > [  202.180294] The code is fine but needs lockdep annotation, or 
maybe
> > > > > > [  202.183774] hardirqs last disabled at (754060): 
[] do_idle+0x99/0x230
> > > > > > [  202.192734] you didn't initialize this object before use?
> > > > > > [  202.198951] softirqs last  enabled at (753948): 
[] irq_exit_rcu+0xbe/0x130
> > > > > > [  202.206882] turning off the locking correctness validator.
> > > > > > [  202.212236] softirqs last disabled at (753943): 
[] irq_exit_rcu+0xbe/0x130
> > > > > > [  202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: GW  
6.3.0-rc4+zeh-xe+ #909
> > > > > > [  202.243002] Hardware name: Intel Corporation Raptor Lake Client 
Platform/RaptorLake-P LP5 RVP, BIOS RPLPFWI1.R00.3361.A14.2211151548 11/15/2022
> > > > > > [  202.255737] Call Trace:
> > > > > > [  202.258179]  
> > > > > > [  202.260275]  dump_stack_lvl+0x58/0xc0
> > > > > > [  202.263922]  register_lock_class+0x756/0x7d0
> > > > > > [  202.268165]  ? find_held_lock+0x2b/0x80
> > > > > > [  202.271975]  __lock_acquire+0x72/0x28b0
> > > > > > [  202.275786]  ? debug_object_free+0xb4/0x160
> > > > > > [  202.279946]  lock_acquire+0xd1/0x2d0
> > > > > > [  202.283503]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > [  202.288181]  _raw_spin_lock+0x2a/0x40
> > > > > > [  202.291825]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > [  202.296475]  intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > [  202.300949]  icl_aux_power_well_enable+0x2bd/0x400 [xe]
> > > > > > [  202.306202]  ? intel_display_power_grab_async_put_ref+0x75/0x120 
[xe]
> > > > > > [  202.312649]  intel_power_well_enable+0x1c/0x70 [xe]
> > > > > > [  202.317543]  __intel_display_power_get_domain.part.0+0x4d/0x70 
[xe]
> > > > > > [  202.323812]  intel_display_power_get+0x43/0x70 [xe]
> > > > > > [  202.328708]  intel_tc_port_init+0x199/0x2a0 [xe]
> > > > > > [  202.63]  intel_ddi_init+0x6ad/0xb00 [xe]
> > > > > > [  202.337678]  intel_modeset_init_nogem+0x536/0x6d0 [xe]
> > > > > > [  202.342838]  xe_display_init_noaccel+0x19/0x40 [xe]
> > > > > > [  202.347743]  xe_device_probe+0x1f5/0x2a0 [xe]
> > > > > > [  202.352127]  xe_pci_probe+0x28c/0x480 [xe]
> > > > > > [  202.356260]  pci_device_probe+0x9d/0x150
> > > > > > [  202.360164]  really_probe+0x19a/0x400
> > > > > > [  202.363809]  ? __pfx___driver_attach+0x10/0x10
> > > > > > [  202.368226]  __driver_probe_device+0x73/0x170
> > > > > > [  202.372558]  driver_probe_device+0x1a/0x90
> > > > > > [  202.376632]  __driver_attach+0xcd/0x1c0
> > > > > > [  202.380442]  bus_for_each_dev+0x72/0xc0
> > > > > > [  202.384253]  bus_add_driver+0x110/0x210
> > > > > > [  202.388063]  driver_register+0x50/0x100
> > > > > > [  202.391873]  ? __pfx_init_module+0x10/0x10 [xe]
> > > > > > [  202.396431]  do_one_initcall+0x55/0x260
> > > > > > [  202.400245]  ? rcu_is_watching+0xd/0x40
> > > > > > [  202.404058]  ? kmalloc_trace+0xa0/0xb0
> > > > > > [  202.407786]  do_init_module+0x45/0x1e0
> > > > > > [  202.411512]  __do_sys_finit_module+0xac/0x120
> > > > > > [  202.415838]  do_syscall_64+0x37/0x90
> > > > > > [  202.419397]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
> > > > > > [  202.424409] RIP: 0033:0x7fd11291ea3d
> > > > > > [  202.427967] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 
48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 
01 c3 48 8b 0d c3 a3 0f 00 f7 d8 64 89 01 48
> > > > > > [  202.446530] RSP: 002b:7de11368 EFLAGS: 0246 
ORIG_RAX: 0139
> > > > > > [  202.454031] RAX: ffda RBX: 5616a617f210 RCX: 
7fd11291ea3d
> > > > > > [  202.461106] RDX:  RSI: 5616a617fe60 RDI: 
000e
> > > > > > [  202.468182] RBP: 0004 R08:  R09: 
0002
> > > > > > [  202.475250] R10: 

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Allow user to set cache at BO creation

[Andi Shyti]

Hi Fei,

> >>> To comply with the design that buffer objects shall have immutable
> >>> cache setting through out their life cycle, {set, get}_caching ioctl's
> >>> are no longer supported from MTL onward. With that change caching
> >>> policy can only be set at object creation time. The current code
> >>> applies a default (platform dependent) cache setting for all objects.
> >>> However this is not optimal for performance tuning. The patch extends
> >>> the existing gem_create uAPI to let user set PAT index for the object
> >>> at creation time.
> >>> The new extension is platform independent, so UMD's can switch to using
> >>> this extension for older platforms as well, while {set, get}_caching are
> >>> still supported on these legacy paltforms for compatibility reason.
> >>>
> >>> Cc: Chris Wilson 
> >>> Cc: Matt Roper 
> >>> Cc: Andi Shyti 
> >>> Signed-off-by: Fei Yang 
> >>> Reviewed-by: Andi Shyti 
> >>
> >> because this is an API change, we need some more information
> >> here.
> >>
> >> First of all you need to CC the userspace guys that have been
> >> working on top of your series and get their ack's.
> >
> > Yes, and a link to a Mesa merge request which uses the uapi should be
> > included.
> 
> Working with Mesa team on this, stay tuned.
> 
> > IGTs should be ready to before we can merge. I glanced over igt-dev but
> > did not spot anything.
> 
> There is a IGT patch posted to gfx-internal-devel, titled "test/gem_create:
> exercise gem_create_ext_set_pat"

Any chance to have it ported upstream? It's OK even if it's not
merged (at least on my side) but some public interface testing is
needed.

If you do post it upstream you could add in the cover letter:

Test-with: 

where the mail-id is referred to the upstream patch of the test.

Andi

Re: [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete

[Dixit, Ashutosh]

On Thu, 20 Apr 2023 08:43:52 -0700, Rodrigo Vivi wrote:
>

Hi Rodrigo,

> On Thu, Apr 20, 2023 at 08:57:24AM +0100, Tvrtko Ursulin wrote:
> >
> > On 19/04/2023 23:10, Dixit, Ashutosh wrote:
> > > On Wed, 19 Apr 2023 06:21:27 -0700, Tvrtko Ursulin wrote:
> > > >
> > >
> > > Hi Tvrtko,
> > >
> > > > On 10/04/2023 23:35, Ashutosh Dixit wrote:
> > > > > Instead of erroring out when GuC reset is in progress, block waiting 
> > > > > for
> > > > > GuC reset to complete which is a more reasonable uapi behavior.
> > > > >
> > > > > v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo)
> > > > >
> > > > > Signed-off-by: Ashutosh Dixit 
> > > > > ---
> > > > >drivers/gpu/drm/i915/i915_hwmon.c | 38 
> > > > > +++
> > > > >1 file changed, 33 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> > > > > b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > > index 9ab8971679fe3..8471a667dfc71 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > > @@ -51,6 +51,7 @@ struct hwm_drvdata {
> > > > >   char name[12];
> > > > >   int gt_n;
> > > > >   bool reset_in_progress;
> > > > > + wait_queue_head_t waitq;
> > > > >};
> > > > >  struct i915_hwmon {
> > > > > @@ -395,16 +396,41 @@ hwm_power_max_read(struct hwm_drvdata *ddat, 
> > > > > long *val)
> > > > >static int
> > > > >hwm_power_max_write(struct hwm_drvdata *ddat, long val)
> > > > >{
> > > > > +#define GUC_RESET_TIMEOUT msecs_to_jiffies(2000)
> > > > > +
> > > > > + int ret = 0, timeout = GUC_RESET_TIMEOUT;
> > > >
> > > > Patch looks good to me
> > >
> > > Great, thanks :)
> > >
> > > > apart that I am not sure what is the purpose of the timeout? This is 
> > > > just
> > > > the sysfs write path or has more callers?
> > >
> > > It is just the sysfs path, but the sysfs is accessed also by the oneAPI
> > > stack (Level 0). In the initial version I also didn't have the timeout
> > > thinking that the app can send a signal to the blocked thread to unblock
> > > it. I introduced the timeout after Rodrigo brought it up and I am now
> > > thinking maybe it's better to have the timeout in the driver since the app
> > > has no knowledge of how long GuC resets can take. But I can remove it if
> > > you think it's not needed.
> >
> > Maybe I am missing something but I don't get why we would need to provide a
> > timeout facility in sysfs? If the library writes here to configure something
> > it already has to expect a blocking write by the nature of a a write(2) and
> > sysfs contract. It can take long for any reason so I hope we are not
> > guaranteeing some latency number to someone? Or the concern is just about
> > things getting stuck? In which case I think Ctrl-C is the answer because
> > ETIME is not even listed as an errno for write(2).

Hmm, good point.

> I suggested the timeout on the other version because of that race,
> which is fixed now with this approach. It is probably better to remove
> it now to avoid confusions. I'm sorry about that.

No problem, I've removed the timeout in the latest version.

Thanks for the R-b.

Ashutosh

[Intel-gfx] [PATCH 2/3] drm/i915/guc: Disable PL1 power limit when loading GuC firmware

[Ashutosh Dixit]

On dGfx, the PL1 power limit being enabled and set to a low value results
in a low GPU operating freq. It also negates the freq raise operation which
is done before GuC firmware load. As a result GuC firmware load can time
out. Such timeouts were seen in the GL #8062 bug below (where the PL1 power
limit was enabled and set to a low value). Therefore disable the PL1 power
limit when allowed by HW when loading GuC firmware.

v2:
 - Take mutex (to disallow writes to power1_max) across GuC reset/fw load
 - Add hwm_power_max_restore to error return code path

v3 (Jani N):
 - Add/remove explanatory comments
 - Function renames
 - Type corrections
 - Locking annotation

v4:
 - Don't hold the lock across GuC reset (Rodrigo)
 - New locking scheme (suggested by Rodrigo)
 - Eliminate rpm_get in power_max_disable/restore, not needed (Tvrtko)

v5:
 - Fix uninitialized pl1en variable compile warning reported by kernel
   build robot by creating new err_rps label

Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
Signed-off-by: Ashutosh Dixit 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 13 +++--
 drivers/gpu/drm/i915/i915_hwmon.c | 40 +++
 drivers/gpu/drm/i915/i915_hwmon.h |  7 +
 3 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 4ccb4be4c9cba..996168312340e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -18,6 +18,7 @@
 #include "intel_uc.h"
 
 #include "i915_drv.h"
+#include "i915_hwmon.h"
 
 static const struct intel_uc_ops uc_ops_off;
 static const struct intel_uc_ops uc_ops_on;
@@ -461,6 +462,7 @@ static int __uc_init_hw(struct intel_uc *uc)
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
int ret, attempts;
+   bool pl1en;
 
GEM_BUG_ON(!intel_uc_supports_guc(uc));
GEM_BUG_ON(!intel_uc_wants_guc(uc));
@@ -491,6 +493,9 @@ static int __uc_init_hw(struct intel_uc *uc)
else
attempts = 1;
 
+   /* Disable a potentially low PL1 power limit to allow freq to be raised 
*/
+   i915_hwmon_power_max_disable(gt->i915, );
+
intel_rps_raise_unslice(_to_gt(uc)->rps);
 
while (attempts--) {
@@ -500,7 +505,7 @@ static int __uc_init_hw(struct intel_uc *uc)
 */
ret = __uc_sanitize(uc);
if (ret)
-   goto err_out;
+   goto err_rps;
 
intel_huc_fw_upload(huc);
intel_guc_ads_reset(guc);
@@ -547,6 +552,8 @@ static int __uc_init_hw(struct intel_uc *uc)
intel_rps_lower_unslice(_to_gt(uc)->rps);
}
 
+   i915_hwmon_power_max_restore(gt->i915, pl1en);
+
guc_info(guc, "submission %s\n", 
str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
guc_info(guc, "SLPC %s\n", 
str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
 
@@ -559,10 +566,12 @@ static int __uc_init_hw(struct intel_uc *uc)
intel_guc_submission_disable(guc);
 err_log_capture:
__uc_capture_load_err_log(uc);
-err_out:
+err_rps:
/* Return GT back to RPn */
intel_rps_lower_unslice(_to_gt(uc)->rps);
 
+   i915_hwmon_power_max_restore(gt->i915, pl1en);
+err_out:
__uc_sanitize(uc);
 
if (!ret) {
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 7f44e809ca155..9ab8971679fe3 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -50,6 +50,7 @@ struct hwm_drvdata {
struct hwm_energy_info ei;  /*  Energy info for 
energy1_input */
char name[12];
int gt_n;
+   bool reset_in_progress;
 };
 
 struct i915_hwmon {
@@ -400,6 +401,10 @@ hwm_power_max_write(struct hwm_drvdata *ddat, long val)
u32 nval;
 
mutex_lock(>hwmon_lock);
+   if (hwmon->ddat.reset_in_progress) {
+   ret = -EAGAIN;
+   goto unlock;
+   }
wakeref = intel_runtime_pm_get(ddat->uncore->rpm);
 
/* Disable PL1 limit and verify, because the limit cannot be disabled 
on all platforms */
@@ -421,6 +426,7 @@ hwm_power_max_write(struct hwm_drvdata *ddat, long val)
 PKG_PWR_LIM_1_EN | PKG_PWR_LIM_1, nval);
 exit:
intel_runtime_pm_put(ddat->uncore->rpm, wakeref);
+unlock:
mutex_unlock(>hwmon_lock);
return ret;
 }
@@ -472,6 +478,40 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int 
chan, long val)
}
 }
 
+void i915_hwmon_power_max_disable(struct drm_i915_private *i915, bool *old)
+{
+   struct i915_hwmon *hwmon = i915->hwmon;
+   u32 r;
+
+   if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
+   return;
+
+   mutex_lock(>hwmon_lock);
+
+   hwmon->ddat.reset_in_progress = true;
+   r = 

[Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete

[Ashutosh Dixit]

Instead of erroring out when GuC reset is in progress, block waiting for
GuC reset to complete which is a more reasonable uapi behavior.

v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo)
v3: Remove timeout when blocked (Tvrtko)

Signed-off-by: Ashutosh Dixit 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_hwmon.c | 29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 9ab8971679fe3..a3bdd9f68a458 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -51,6 +51,7 @@ struct hwm_drvdata {
char name[12];
int gt_n;
bool reset_in_progress;
+   wait_queue_head_t waitq;
 };
 
 struct i915_hwmon {
@@ -397,14 +398,32 @@ hwm_power_max_write(struct hwm_drvdata *ddat, long val)
 {
struct i915_hwmon *hwmon = ddat->hwmon;
intel_wakeref_t wakeref;
+   DEFINE_WAIT(wait);
int ret = 0;
u32 nval;
 
-   mutex_lock(>hwmon_lock);
-   if (hwmon->ddat.reset_in_progress) {
-   ret = -EAGAIN;
-   goto unlock;
+   /* Block waiting for GuC reset to complete when needed */
+   for (;;) {
+   mutex_lock(>hwmon_lock);
+
+   prepare_to_wait(>waitq, , TASK_INTERRUPTIBLE);
+
+   if (!hwmon->ddat.reset_in_progress)
+   break;
+
+   if (signal_pending(current)) {
+   ret = -EINTR;
+   break;
+   }
+
+   mutex_unlock(>hwmon_lock);
+
+   schedule();
}
+   finish_wait(>waitq, );
+   if (ret)
+   goto unlock;
+
wakeref = intel_runtime_pm_get(ddat->uncore->rpm);
 
/* Disable PL1 limit and verify, because the limit cannot be disabled 
on all platforms */
@@ -508,6 +527,7 @@ void i915_hwmon_power_max_restore(struct drm_i915_private 
*i915, bool old)
intel_uncore_rmw(hwmon->ddat.uncore, hwmon->rg.pkg_rapl_limit,
 PKG_PWR_LIM_1_EN, old ? PKG_PWR_LIM_1_EN : 0);
hwmon->ddat.reset_in_progress = false;
+   wake_up_all(>ddat.waitq);
 
mutex_unlock(>hwmon_lock);
 }
@@ -784,6 +804,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
ddat->uncore = >uncore;
snprintf(ddat->name, sizeof(ddat->name), "i915");
ddat->gt_n = -1;
+   init_waitqueue_head(>waitq);
 
for_each_gt(gt, i915, i) {
ddat_gt = hwmon->ddat_gt + i;
-- 
2.38.0

[Intel-gfx] [PATCH v6 0/3] drm/i915/guc: Disable PL1 power limit when loading GuC firmware

[Ashutosh Dixit]

v6: Update Patch 3 to remove the timeout when blocked
v1-v5: Please see individual patches for revision history

Ashutosh Dixit (3):
  drm/i915/hwmon: Get mutex and rpm ref just once in hwm_power_max_write
  drm/i915/guc: Disable PL1 power limit when loading GuC firmware
  drm/i915/hwmon: Block waiting for GuC reset to complete

 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 13 +++-
 drivers/gpu/drm/i915/i915_hwmon.c | 87 +++
 drivers/gpu/drm/i915/i915_hwmon.h |  7 +++
 3 files changed, 93 insertions(+), 14 deletions(-)

-- 
2.38.0

[Intel-gfx] [PATCH 1/3] drm/i915/hwmon: Get mutex and rpm ref just once in hwm_power_max_write

[Ashutosh Dixit]

In preparation for follow-on patches, refactor hwm_power_max_write to take
hwmon_lock and runtime pm wakeref at start of the function and release them
at the end, therefore acquiring these just once each.

Signed-off-by: Ashutosh Dixit 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_hwmon.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 8e7dccc8d3a0e..7f44e809ca155 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -396,31 +396,33 @@ hwm_power_max_write(struct hwm_drvdata *ddat, long val)
 {
struct i915_hwmon *hwmon = ddat->hwmon;
intel_wakeref_t wakeref;
+   int ret = 0;
u32 nval;
 
+   mutex_lock(>hwmon_lock);
+   wakeref = intel_runtime_pm_get(ddat->uncore->rpm);
+
/* Disable PL1 limit and verify, because the limit cannot be disabled 
on all platforms */
if (val == PL1_DISABLE) {
-   mutex_lock(>hwmon_lock);
-   with_intel_runtime_pm(ddat->uncore->rpm, wakeref) {
-   intel_uncore_rmw(ddat->uncore, hwmon->rg.pkg_rapl_limit,
-PKG_PWR_LIM_1_EN, 0);
-   nval = intel_uncore_read(ddat->uncore, 
hwmon->rg.pkg_rapl_limit);
-   }
-   mutex_unlock(>hwmon_lock);
+   intel_uncore_rmw(ddat->uncore, hwmon->rg.pkg_rapl_limit,
+PKG_PWR_LIM_1_EN, 0);
+   nval = intel_uncore_read(ddat->uncore, 
hwmon->rg.pkg_rapl_limit);
 
if (nval & PKG_PWR_LIM_1_EN)
-   return -ENODEV;
-   return 0;
+   ret = -ENODEV;
+   goto exit;
}
 
/* Computation in 64-bits to avoid overflow. Round to nearest. */
nval = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_power, 
SF_POWER);
nval = PKG_PWR_LIM_1_EN | REG_FIELD_PREP(PKG_PWR_LIM_1, nval);
 
-   hwm_locked_with_pm_intel_uncore_rmw(ddat, hwmon->rg.pkg_rapl_limit,
-   PKG_PWR_LIM_1_EN | PKG_PWR_LIM_1,
-   nval);
-   return 0;
+   intel_uncore_rmw(ddat->uncore, hwmon->rg.pkg_rapl_limit,
+PKG_PWR_LIM_1_EN | PKG_PWR_LIM_1, nval);
+exit:
+   intel_runtime_pm_put(ddat->uncore->rpm, wakeref);
+   mutex_unlock(>hwmon_lock);
+   return ret;
 }
 
 static int
-- 
2.38.0

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Allow user to set cache at BO creation

[Yang, Fei]

> On 20/04/2023 12:39, Andi Shyti wrote:
>> Hi Fei,
>>
>>> To comply with the design that buffer objects shall have immutable
>>> cache setting through out their life cycle, {set, get}_caching ioctl's
>>> are no longer supported from MTL onward. With that change caching
>>> policy can only be set at object creation time. The current code
>>> applies a default (platform dependent) cache setting for all objects.
>>> However this is not optimal for performance tuning. The patch extends
>>> the existing gem_create uAPI to let user set PAT index for the object
>>> at creation time.
>>> The new extension is platform independent, so UMD's can switch to using
>>> this extension for older platforms as well, while {set, get}_caching are
>>> still supported on these legacy paltforms for compatibility reason.
>>>
>>> Cc: Chris Wilson 
>>> Cc: Matt Roper 
>>> Cc: Andi Shyti 
>>> Signed-off-by: Fei Yang 
>>> Reviewed-by: Andi Shyti 
>>
>> because this is an API change, we need some more information
>> here.
>>
>> First of all you need to CC the userspace guys that have been
>> working on top of your series and get their ack's.
>
> Yes, and a link to a Mesa merge request which uses the uapi should be
> included.

Working with Mesa team on this, stay tuned.

> IGTs should be ready to before we can merge. I glanced over igt-dev but
> did not spot anything.

There is a IGT patch posted to gfx-internal-devel, titled "test/gem_create: 
exercise gem_create_ext_set_pat"

> Regards,
>
> Tvrtko
>
>>
>> I also believe that this series has also been tested on a
>> separate repository, would you link it in the commit message?
>>
>> Thanks,
>> Andi

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add support for C20 phy

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add support for C20 phy
URL   : https://patchwork.freedesktop.org/series/116755/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13034 -> Patchwork_116755v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (37 -> 36)
--

  Additional (1): fi-kbl-soraka 
  Missing(2): bat-kbl-2 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@gt_mocs:
- {bat-mtlp-8}:   [ABORT][1] ([i915#8369]) -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@gt_pm:
- {bat-mtlp-8}:   [DMESG-FAIL][3] ([i915#8370]) -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-mtlp-8/igt@i915_selftest@live@gt_pm.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/bat-mtlp-8/igt@i915_selftest@live@gt_pm.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-apl-guc: [PASS][5] -> [ABORT][6] ([i915#8225])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: [PASS][7] -> [ABORT][8] ([i915#6687] / [i915#7978])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][11] ([i915#5334] / [i915#7872])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_mocs:
- bat-rpls-1: [PASS][12] -> [DMESG-FAIL][13] ([i915#7059])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][14] ([i915#1886])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@requests:
- fi-kbl-soraka:  NOTRUN -> [ABORT][15] ([i915#7913])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/fi-kbl-soraka/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-FAIL][16] ([i915#6367] / [i915#7996])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][17] ([fdo#109271]) +16 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-adlp-6: NOTRUN -> [SKIP][18] ([i915#7828])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/bat-adlp-6/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8:  [PASS][19] -> [FAIL][20] ([i915#7932])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116755v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html

 

Re: [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete

[Rodrigo Vivi]

On Wed, Apr 19, 2023 at 03:13:08PM -0700, Dixit, Ashutosh wrote:
> On Wed, 19 Apr 2023 12:40:44 -0700, Rodrigo Vivi wrote:
> >
> 
> Hi Rodrigo,
> 
> > On Tue, Apr 18, 2023 at 10:23:50AM -0700, Dixit, Ashutosh wrote:
> > > On Mon, 17 Apr 2023 22:35:58 -0700, Rodrigo Vivi wrote:
> > > >
> > >
> > > Hi Rodrigo,
> > >
> > > > On Mon, Apr 10, 2023 at 03:35:09PM -0700, Ashutosh Dixit wrote:
> > > > > Instead of erroring out when GuC reset is in progress, block waiting 
> > > > > for
> > > > > GuC reset to complete which is a more reasonable uapi behavior.
> > > > >
> > > > > v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo)
> > > > >
> > > > > Signed-off-by: Ashutosh Dixit 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_hwmon.c | 38 
> > > > > +++
> > > > >  1 file changed, 33 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> > > > > b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > > index 9ab8971679fe3..8471a667dfc71 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > > @@ -51,6 +51,7 @@ struct hwm_drvdata {
> > > > >   char name[12];
> > > > >   int gt_n;
> > > > >   bool reset_in_progress;
> > > > > + wait_queue_head_t waitq;
> > > > >  };
> > > > >
> > > > >  struct i915_hwmon {
> > > > > @@ -395,16 +396,41 @@ hwm_power_max_read(struct hwm_drvdata *ddat, 
> > > > > long *val)
> > > > >  static int
> > > > >  hwm_power_max_write(struct hwm_drvdata *ddat, long val)
> > > > >  {
> > > > > +#define GUC_RESET_TIMEOUT msecs_to_jiffies(2000)
> > > > > +
> > > > > + int ret = 0, timeout = GUC_RESET_TIMEOUT;
> > > > >   struct i915_hwmon *hwmon = ddat->hwmon;
> > > > >   intel_wakeref_t wakeref;
> > > > > - int ret = 0;
> > > > > + DEFINE_WAIT(wait);
> > > > >   u32 nval;
> > > > >
> > > > > - mutex_lock(>hwmon_lock);
> > > > > - if (hwmon->ddat.reset_in_progress) {
> > > > > - ret = -EAGAIN;
> > > > > - goto unlock;
> > > > > + /* Block waiting for GuC reset to complete when needed */
> > > > > + for (;;) {
> > > > > + mutex_lock(>hwmon_lock);
> > > >
> > > > I'm really afraid of how this mutex is handled with the wait queue.
> > > > some initial thought it looks like it is trying to reimplement ww_mutex?
> > >
> > > Sorry, but I am missing the relation with ww_mutex. No such relation is
> > > intended.
> > >
> > > > all other examples of the wait_queue usages like this or didn't use
> > > > locks or had it in a total different flow that I could not correlate.
> > >
> > > Actually there are several examples of prepare_to_wait/finish_wait
> > > sequences with both spinlock and mutex in the kernel. See
> > > e.g. rpm_suspend(), wait_for_rtrs_disconnection(), softsynthx_read().
> > >
> > > Also, as I mentioned, except for the lock, the sequence here is identical
> > > to intel_guc_wait_for_pending_msg().
> > >
> > > >
> > > > > +
> > > > > + prepare_to_wait(>waitq, , 
> > > > > TASK_INTERRUPTIBLE);
> > > > > +
> > > > > + if (!hwmon->ddat.reset_in_progress)
> > > > > + break;
> > > >
> > > > If this breaks we never unlock it?
> > >
> > > Correct, this is the original case in Patch 2 where the mutex is acquired
> > > in the beginning of the function and released just before the final exit
> > > from the function (so the mutex is held for the entire duration of the
> > > function).
> >
> > I got really confused here...
> 
> Sorry, the patch is a little confusing/tricky but I thought I'd better
> stick to the standard 'for (;;)' loop pattern otherwise it will also be
> hard to review.
> 
> > I looked at the patch 2 again and I don't see any place where the lock
> > remains outside of the function. What was what I asked to remove on the
> > initial versions.
> 
> So it was in Patch 1 where we changed the code to take the lock in the
> beginning of the function and release it at the end of the function (you
> can see it Patch 1).
> 
> In Patch 2 the 'unlock' label and 'goto unlock' is introduced and the lock
> is released at the 'unlock' label (it is visible in Patch 2).
> 
> > But now with this one I'm even more confused because I couldn't follow
> > to understand who will remove the lock and when.
> 
> In Patch 3 again the lock is released at the the 'unlock' label (i.e. the
> destination of 'goto unlock', not visible in Patch 3). But we execute 'goto
> unlock' only when 'ret != 0' in the 'for (;;)' loop. But when 'ret == 0'
> (when 'ddat.reset_in_progress' flag is clear) we hold the mutex, execute
> the entire function and finally release the lock at the end of the
> function.
> 
> Hopefully this helps.

more coffee also helped! I'm sorry for the noise.

with the timeout thing sorted out:

Reviewed-by: Rodrigo Vivi 


> 
> Thanks.
> --
> Ashutosh
> 
> >
> > >
> > > >
> > > > > +
> > > > > + if (signal_pending(current)) 

Re: [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete

[Rodrigo Vivi]

On Thu, Apr 20, 2023 at 08:57:24AM +0100, Tvrtko Ursulin wrote:
> 
> On 19/04/2023 23:10, Dixit, Ashutosh wrote:
> > On Wed, 19 Apr 2023 06:21:27 -0700, Tvrtko Ursulin wrote:
> > > 
> > 
> > Hi Tvrtko,
> > 
> > > On 10/04/2023 23:35, Ashutosh Dixit wrote:
> > > > Instead of erroring out when GuC reset is in progress, block waiting for
> > > > GuC reset to complete which is a more reasonable uapi behavior.
> > > > 
> > > > v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo)
> > > > 
> > > > Signed-off-by: Ashutosh Dixit 
> > > > ---
> > > >drivers/gpu/drm/i915/i915_hwmon.c | 38 
> > > > +++
> > > >1 file changed, 33 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> > > > b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > index 9ab8971679fe3..8471a667dfc71 100644
> > > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > @@ -51,6 +51,7 @@ struct hwm_drvdata {
> > > > char name[12];
> > > > int gt_n;
> > > > bool reset_in_progress;
> > > > +   wait_queue_head_t waitq;
> > > >};
> > > >  struct i915_hwmon {
> > > > @@ -395,16 +396,41 @@ hwm_power_max_read(struct hwm_drvdata *ddat, long 
> > > > *val)
> > > >static int
> > > >hwm_power_max_write(struct hwm_drvdata *ddat, long val)
> > > >{
> > > > +#define GUC_RESET_TIMEOUT msecs_to_jiffies(2000)
> > > > +
> > > > +   int ret = 0, timeout = GUC_RESET_TIMEOUT;
> > > 
> > > Patch looks good to me
> > 
> > Great, thanks :)
> > 
> > > apart that I am not sure what is the purpose of the timeout? This is just
> > > the sysfs write path or has more callers?
> > 
> > It is just the sysfs path, but the sysfs is accessed also by the oneAPI
> > stack (Level 0). In the initial version I also didn't have the timeout
> > thinking that the app can send a signal to the blocked thread to unblock
> > it. I introduced the timeout after Rodrigo brought it up and I am now
> > thinking maybe it's better to have the timeout in the driver since the app
> > has no knowledge of how long GuC resets can take. But I can remove it if
> > you think it's not needed.
> 
> Maybe I am missing something but I don't get why we would need to provide a
> timeout facility in sysfs? If the library writes here to configure something
> it already has to expect a blocking write by the nature of a a write(2) and
> sysfs contract. It can take long for any reason so I hope we are not
> guaranteeing some latency number to someone? Or the concern is just about
> things getting stuck? In which case I think Ctrl-C is the answer because
> ETIME is not even listed as an errno for write(2).

I suggested the timeout on the other version because of that race,
which is fixed now with this approach. It is probably better to remove
it now to avoid confusions. I'm sorry about that.

> 
> > > If the
> > > former perhaps it would be better to just use interruptible everything
> > > (mutex and sleep) and wait for as long as it takes or until user presses
> > > Ctrl-C?
> > 
> > Now we are not holding the mutexes for long, just long enough do register
> > rmw's. So not holding the mutex across GuC reset as we were
> > originally. Therefore I am thinking mutex_lock_interruptible is not needed?
> > The sleep is already interruptible (TASK_INTERRUPTIBLE).
> 
> Ah yes, you are right.
> 
> Regards,
> 
> Tvrtko
> 
> > Anyway please let me know if you think we need to change anything.
> > 
> > Thanks.
> > --
> > Ashutosh
> > 
> > > > struct i915_hwmon *hwmon = ddat->hwmon;
> > > > intel_wakeref_t wakeref;
> > > > -   int ret = 0;
> > > > +   DEFINE_WAIT(wait);
> > > > u32 nval;
> > > >-mutex_lock(>hwmon_lock);
> > > > -   if (hwmon->ddat.reset_in_progress) {
> > > > -   ret = -EAGAIN;
> > > > -   goto unlock;
> > > > +   /* Block waiting for GuC reset to complete when needed */
> > > > +   for (;;) {
> > > > +   mutex_lock(>hwmon_lock);
> > > > +
> > > > +   prepare_to_wait(>waitq, , 
> > > > TASK_INTERRUPTIBLE);
> > > > +
> > > > +   if (!hwmon->ddat.reset_in_progress)
> > > > +   break;
> > > > +
> > > > +   if (signal_pending(current)) {
> > > > +   ret = -EINTR;
> > > > +   break;
> > > > +   }
> > > > +
> > > > +   if (!timeout) {
> > > > +   ret = -ETIME;
> > > > +   break;
> > > > +   }
> > > > +
> > > > +   mutex_unlock(>hwmon_lock);
> > > > +
> > > > +   timeout = schedule_timeout(timeout);
> > > > }
> > > > +   finish_wait(>waitq, );
> > > > +   if (ret)
> > > > +   goto unlock;
> > > > +
> > > > wakeref = intel_runtime_pm_get(ddat->uncore->rpm);
> > > > /* Disable PL1 limit and verify, because the limit 

Re: [Intel-gfx] [Intel-xe] [PATCH v4] drm/i915: Initialize dkl_phy spin lock from display code path

[Souza, Jose]

On Thu, 2023-04-20 at 11:27 -0400, Rodrigo Vivi wrote:
> On Thu, Apr 20, 2023 at 09:19:09AM -0400, Souza, Jose wrote:
> > On Wed, 2023-04-19 at 00:29 -0700, Lucas De Marchi wrote:
> > > On Wed, Apr 19, 2023 at 10:16:22AM +0300, Jani Nikula wrote:
> > > > On Tue, 18 Apr 2023, Lucas De Marchi  wrote:
> > > > > On Tue, Apr 18, 2023 at 11:30:18PM -0700, Lucas De Marchi wrote:
> > > > > > On Tue, Apr 18, 2023 at 09:43:37AM -0700, Jose Souza wrote:
> > > > > > > Start to move the initialization of display locks from
> > > > > > > i915_driver_early_probe(), this way it is also executed when 
> > > > > > > running
> > > > > > > Xe kmd.
> > > > > > > 
> > > > > > > This will fix a warning in Xe kmd:
> > > > > > > 
> > > > > > > [  201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] 
> > > > > > > failed to retrieve link info, disabling eDP
> > > > > > > [  202.136336] xe :00:02.0: [drm] *ERROR* Failed to write 
> > > > > > > source OUI
> > > > > > > [  202.175346] INFO: trying to register non-static key.
> > > > > > > [  202.175347] irq event stamp: 754060
> > > > > > > [  202.175359] hardirqs last  enabled at (754059): 
> > > > > > > [] tick_nohz_idle_enter+0x59/0x80
> > > > > > > [  202.180294] The code is fine but needs lockdep annotation, or 
> > > > > > > maybe
> > > > > > > [  202.183774] hardirqs last disabled at (754060): 
> > > > > > > [] do_idle+0x99/0x230
> > > > > > > [  202.192734] you didn't initialize this object before use?
> > > > > > > [  202.198951] softirqs last  enabled at (753948): 
> > > > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > > > [  202.206882] turning off the locking correctness validator.
> > > > > > > [  202.212236] softirqs last disabled at (753943): 
> > > > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > > > [  202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: G
> > > > > > > W  6.3.0-rc4+zeh-xe+ #909
> > > > > > > [  202.243002] Hardware name: Intel Corporation Raptor Lake 
> > > > > > > Client Platform/RaptorLake-P LP5 RVP, BIOS 
> > > > > > > RPLPFWI1.R00.3361.A14.2211151548 11/15/2022
> > > > > > > [  202.255737] Call Trace:
> > > > > > > [  202.258179]  
> > > > > > > [  202.260275]  dump_stack_lvl+0x58/0xc0
> > > > > > > [  202.263922]  register_lock_class+0x756/0x7d0
> > > > > > > [  202.268165]  ? find_held_lock+0x2b/0x80
> > > > > > > [  202.271975]  __lock_acquire+0x72/0x28b0
> > > > > > > [  202.275786]  ? debug_object_free+0xb4/0x160
> > > > > > > [  202.279946]  lock_acquire+0xd1/0x2d0
> > > > > > > [  202.283503]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > [  202.288181]  _raw_spin_lock+0x2a/0x40
> > > > > > > [  202.291825]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > [  202.296475]  intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > > [  202.300949]  icl_aux_power_well_enable+0x2bd/0x400 [xe]
> > > > > > > [  202.306202]  ? 
> > > > > > > intel_display_power_grab_async_put_ref+0x75/0x120 [xe]
> > > > > > > [  202.312649]  intel_power_well_enable+0x1c/0x70 [xe]
> > > > > > > [  202.317543]  __intel_display_power_get_domain.part.0+0x4d/0x70 
> > > > > > > [xe]
> > > > > > > [  202.323812]  intel_display_power_get+0x43/0x70 [xe]
> > > > > > > [  202.328708]  intel_tc_port_init+0x199/0x2a0 [xe]
> > > > > > > [  202.63]  intel_ddi_init+0x6ad/0xb00 [xe]
> > > > > > > [  202.337678]  intel_modeset_init_nogem+0x536/0x6d0 [xe]
> > > > > > > [  202.342838]  xe_display_init_noaccel+0x19/0x40 [xe]
> > > > > > > [  202.347743]  xe_device_probe+0x1f5/0x2a0 [xe]
> > > > > > > [  202.352127]  xe_pci_probe+0x28c/0x480 [xe]
> > > > > > > [  202.356260]  pci_device_probe+0x9d/0x150
> > > > > > > [  202.360164]  really_probe+0x19a/0x400
> > > > > > > [  202.363809]  ? __pfx___driver_attach+0x10/0x10
> > > > > > > [  202.368226]  __driver_probe_device+0x73/0x170
> > > > > > > [  202.372558]  driver_probe_device+0x1a/0x90
> > > > > > > [  202.376632]  __driver_attach+0xcd/0x1c0
> > > > > > > [  202.380442]  bus_for_each_dev+0x72/0xc0
> > > > > > > [  202.384253]  bus_add_driver+0x110/0x210
> > > > > > > [  202.388063]  driver_register+0x50/0x100
> > > > > > > [  202.391873]  ? __pfx_init_module+0x10/0x10 [xe]
> > > > > > > [  202.396431]  do_one_initcall+0x55/0x260
> > > > > > > [  202.400245]  ? rcu_is_watching+0xd/0x40
> > > > > > > [  202.404058]  ? kmalloc_trace+0xa0/0xb0
> > > > > > > [  202.407786]  do_init_module+0x45/0x1e0
> > > > > > > [  202.411512]  __do_sys_finit_module+0xac/0x120
> > > > > > > [  202.415838]  do_syscall_64+0x37/0x90
> > > > > > > [  202.419397]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
> > > > > > > [  202.424409] RIP: 0033:0x7fd11291ea3d
> > > > > > > [  202.427967] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 
> > > > > > > 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 
> > > > > > > 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 a3 0f 00 
> > > > > > > f7 d8 64 89 01 48
> > > > > > > [  202.446530] RSP: 002b:7de11368 EFLAGS: 0246 
> > > > > > > ORIG_RAX: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Add support for C20 phy

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add support for C20 phy
URL   : https://patchwork.freedesktop.org/series/116755/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: Add support for C20 phy

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add support for C20 phy
URL   : https://patchwork.freedesktop.org/series/116755/
State : warning

== Summary ==

Error: dim checkpatch failed
46e88ddde94d drm/i915/mtl: C20 PLL programming
-:155: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#155: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1539:
+   cntx = intel_cx0_read(i915, encoder->port, INTEL_CX0_LANE0, 
PHY_C20_VDR_CUSTOM_SERDES_RATE) &

-:164: WARNING:LONG_LINE: line length of 129 exceeds 100 columns
#164: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1548:
+   intel_c20_sram_write(i915, encoder->port, 
INTEL_CX0_LANE0, RAWLANEAONX_DIG_TX_MPLLB_CAL_DONE_BANK(i), 0);

-:165: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.rst
#165: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1549:
+   msleep(4);

-:172: WARNING:LONG_LINE: line length of 127 exceeds 100 columns
#172: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1556:
+   intel_c20_sram_write(i915, encoder->port, 
INTEL_CX0_LANE0, PHY_C20_A_TX_CNTX_CFG(i), pll_state->tx[i]);

-:174: WARNING:LONG_LINE: line length of 127 exceeds 100 columns
#174: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1558:
+   intel_c20_sram_write(i915, encoder->port, 
INTEL_CX0_LANE0, PHY_C20_B_TX_CNTX_CFG(i), pll_state->tx[i]);

-:180: WARNING:LONG_LINE: line length of 129 exceeds 100 columns
#180: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1564:
+   intel_c20_sram_write(i915, encoder->port, 
INTEL_CX0_LANE0, PHY_C20_A_CMN_CNTX_CFG(i), pll_state->cmn[i]);

-:182: WARNING:LONG_LINE: line length of 129 exceeds 100 columns
#182: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1566:
+   intel_c20_sram_write(i915, encoder->port, 
INTEL_CX0_LANE0, PHY_C20_B_CMN_CNTX_CFG(i), pll_state->cmn[i]);

-:218: CHECK:BRACES: Unbalanced braces around else statement
#218: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1602:
+   } else

-:226: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#226: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1610:
+ BIT(6) | 
PHY_C20_CUSTOM_SERDES(intel_c20_get_dp_rate(pll_state->clock)),

-:229: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#229: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1613:
+   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C20_VDR_CUSTOM_SERDES_RATE,

total: 0 errors, 9 warnings, 1 checks, 460 lines checked
d82ad92a3433 drm/i915/mtl: C20 HW readout
-:617: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#617: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1962:
+int intel_cx0pll_calc_state(struct intel_crtc_state *crtc_state,
+struct intel_encoder *encoder)

-:643: WARNING:LONG_LINE: line length of 125 exceeds 100 columns
#643: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:1990:
+   cntx = intel_cx0_read(i915, encoder->port, INTEL_CX0_LANE0, 
PHY_C20_VDR_CUSTOM_SERDES_RATE) & PHY_C20_CONTEXT_TOGGLE;

-:658: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#658: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2005:
+   pll_state->cmn[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,

-:661: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#661: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2008:
+   pll_state->cmn[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,

-:665: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#665: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2012:
+   val = intel_c20_sram_read(i915, encoder->port, INTEL_CX0_LANE0, 
PHY_C20_A_MPLLA_CNTX_CFG(6));

-:672: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#672: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2019:
+   pll_state->mplla[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,

-:673: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#673: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2020:
+ 
PHY_C20_B_MPLLA_CNTX_CFG(i));

-:675: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#675: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2022:
+   pll_state->mplla[i] = intel_c20_sram_read(i915, 
encoder->port, INTEL_CX0_LANE0,

-:676: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#676: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2023:
+ 
PHY_C20_A_MPLLA_CNTX_CFG(i));

-:682: WARNING:LONG_LINE: line length of 111 exceeds 100 columns
#682: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy.c:2029:
+   

Re: [Intel-gfx] [Intel-xe] [PATCH v4] drm/i915: Initialize dkl_phy spin lock from display code path

[Rodrigo Vivi]

On Thu, Apr 20, 2023 at 09:19:09AM -0400, Souza, Jose wrote:
> On Wed, 2023-04-19 at 00:29 -0700, Lucas De Marchi wrote:
> > On Wed, Apr 19, 2023 at 10:16:22AM +0300, Jani Nikula wrote:
> > > On Tue, 18 Apr 2023, Lucas De Marchi  wrote:
> > > > On Tue, Apr 18, 2023 at 11:30:18PM -0700, Lucas De Marchi wrote:
> > > > > On Tue, Apr 18, 2023 at 09:43:37AM -0700, Jose Souza wrote:
> > > > > > Start to move the initialization of display locks from
> > > > > > i915_driver_early_probe(), this way it is also executed when running
> > > > > > Xe kmd.
> > > > > > 
> > > > > > This will fix a warning in Xe kmd:
> > > > > > 
> > > > > > [  201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] 
> > > > > > failed to retrieve link info, disabling eDP
> > > > > > [  202.136336] xe :00:02.0: [drm] *ERROR* Failed to write 
> > > > > > source OUI
> > > > > > [  202.175346] INFO: trying to register non-static key.
> > > > > > [  202.175347] irq event stamp: 754060
> > > > > > [  202.175359] hardirqs last  enabled at (754059): 
> > > > > > [] tick_nohz_idle_enter+0x59/0x80
> > > > > > [  202.180294] The code is fine but needs lockdep annotation, or 
> > > > > > maybe
> > > > > > [  202.183774] hardirqs last disabled at (754060): 
> > > > > > [] do_idle+0x99/0x230
> > > > > > [  202.192734] you didn't initialize this object before use?
> > > > > > [  202.198951] softirqs last  enabled at (753948): 
> > > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > > [  202.206882] turning off the locking correctness validator.
> > > > > > [  202.212236] softirqs last disabled at (753943): 
> > > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > > [  202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: GW  
> > > > > > 6.3.0-rc4+zeh-xe+ #909
> > > > > > [  202.243002] Hardware name: Intel Corporation Raptor Lake Client 
> > > > > > Platform/RaptorLake-P LP5 RVP, BIOS 
> > > > > > RPLPFWI1.R00.3361.A14.2211151548 11/15/2022
> > > > > > [  202.255737] Call Trace:
> > > > > > [  202.258179]  
> > > > > > [  202.260275]  dump_stack_lvl+0x58/0xc0
> > > > > > [  202.263922]  register_lock_class+0x756/0x7d0
> > > > > > [  202.268165]  ? find_held_lock+0x2b/0x80
> > > > > > [  202.271975]  __lock_acquire+0x72/0x28b0
> > > > > > [  202.275786]  ? debug_object_free+0xb4/0x160
> > > > > > [  202.279946]  lock_acquire+0xd1/0x2d0
> > > > > > [  202.283503]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > [  202.288181]  _raw_spin_lock+0x2a/0x40
> > > > > > [  202.291825]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > [  202.296475]  intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > > [  202.300949]  icl_aux_power_well_enable+0x2bd/0x400 [xe]
> > > > > > [  202.306202]  ? intel_display_power_grab_async_put_ref+0x75/0x120 
> > > > > > [xe]
> > > > > > [  202.312649]  intel_power_well_enable+0x1c/0x70 [xe]
> > > > > > [  202.317543]  __intel_display_power_get_domain.part.0+0x4d/0x70 
> > > > > > [xe]
> > > > > > [  202.323812]  intel_display_power_get+0x43/0x70 [xe]
> > > > > > [  202.328708]  intel_tc_port_init+0x199/0x2a0 [xe]
> > > > > > [  202.63]  intel_ddi_init+0x6ad/0xb00 [xe]
> > > > > > [  202.337678]  intel_modeset_init_nogem+0x536/0x6d0 [xe]
> > > > > > [  202.342838]  xe_display_init_noaccel+0x19/0x40 [xe]
> > > > > > [  202.347743]  xe_device_probe+0x1f5/0x2a0 [xe]
> > > > > > [  202.352127]  xe_pci_probe+0x28c/0x480 [xe]
> > > > > > [  202.356260]  pci_device_probe+0x9d/0x150
> > > > > > [  202.360164]  really_probe+0x19a/0x400
> > > > > > [  202.363809]  ? __pfx___driver_attach+0x10/0x10
> > > > > > [  202.368226]  __driver_probe_device+0x73/0x170
> > > > > > [  202.372558]  driver_probe_device+0x1a/0x90
> > > > > > [  202.376632]  __driver_attach+0xcd/0x1c0
> > > > > > [  202.380442]  bus_for_each_dev+0x72/0xc0
> > > > > > [  202.384253]  bus_add_driver+0x110/0x210
> > > > > > [  202.388063]  driver_register+0x50/0x100
> > > > > > [  202.391873]  ? __pfx_init_module+0x10/0x10 [xe]
> > > > > > [  202.396431]  do_one_initcall+0x55/0x260
> > > > > > [  202.400245]  ? rcu_is_watching+0xd/0x40
> > > > > > [  202.404058]  ? kmalloc_trace+0xa0/0xb0
> > > > > > [  202.407786]  do_init_module+0x45/0x1e0
> > > > > > [  202.411512]  __do_sys_finit_module+0xac/0x120
> > > > > > [  202.415838]  do_syscall_64+0x37/0x90
> > > > > > [  202.419397]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
> > > > > > [  202.424409] RIP: 0033:0x7fd11291ea3d
> > > > > > [  202.427967] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 
> > > > > > 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 
> > > > > > 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 a3 0f 00 f7 
> > > > > > d8 64 89 01 48
> > > > > > [  202.446530] RSP: 002b:7de11368 EFLAGS: 0246 
> > > > > > ORIG_RAX: 0139
> > > > > > [  202.454031] RAX: ffda RBX: 5616a617f210 RCX: 
> > > > > > 7fd11291ea3d
> > > > > > [  202.461106] RDX:  RSI: 5616a617fe60 RDI: 
> > > > > > 000e
> > > > > > [  

Re: [Intel-gfx] [PATCH 4/4] drm/i915/mtl: Skip pcode qgv restrictions for MTL

[Govindapillai, Vinod]

On Fri, 2023-03-17 at 17:58 -0700, Radhakrishna Sripada wrote:
> Communicating QGV points restriction to PUnit happens via PM Demand
> instead of the Pcode mailbox in the previous platforms. GV point
> restriction is handled by the PM demand code.
> 
> Signed-off-by: Radhakrishna Sripada 
> ---

Thanks! 

Reviewed-by: Vinod Govindapillai 


>  drivers/gpu/drm/i915/display/intel_bw.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 87c20bf52123..c292e63bdcbb 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -150,6 +150,9 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private 
> *dev_priv,
>  {
> int ret;
>  
> +   if (DISPLAY_VER(dev_priv) >= 14)
> +   return 0;
> +
> /* bspec says to keep retrying for at least 1 ms */
> ret = skl_pcode_request(_priv->uncore, 
> ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
> points_mask,

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Add workaround 14018778641

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add workaround 14018778641
URL   : https://patchwork.freedesktop.org/series/116750/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13033_full -> Patchwork_116750v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_color@ctm-max@pipe-a-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][1] ([fdo#109271]) +32 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v1/shard-snb1/igt@kms_color@ctm-...@pipe-a-hdmi-a-1.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk:  [PASS][2] -> [FAIL][3] ([i915#2346])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-glk2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v1/shard-glk4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

  * igt@kms_psr@psr2_primary_page_flip:
- shard-glk:  NOTRUN -> [SKIP][4] ([fdo#109271]) +12 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v1/shard-glk1/igt@kms_psr@psr2_primary_page_flip.html

  
 Possible fixes 

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][5] ([i915#7742]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v1/shard-rkl-2/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][7] ([i915#6268]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-rkl-6/igt@gem_ctx_e...@basic-nohangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v1/shard-rkl-7/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [FAIL][9] ([i915#2842]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v1/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][11] ([i915#2842]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-rkl-6/igt@gem_exec_fair@basic-p...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v1/shard-rkl-2/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gen9_exec_parse@allowed-single:
- shard-glk:  [ABORT][13] ([i915#5566]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-glk7/igt@gen9_exec_pa...@allowed-single.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v1/shard-glk1/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_pm_rpm@dpms-lpsp:
- {shard-rkl}:[SKIP][15] ([i915#1397]) -> [PASS][16] +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-rkl-1/igt@i915_pm_...@dpms-lpsp.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v1/shard-rkl-7/igt@i915_pm_...@dpms-lpsp.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl:  [FAIL][17] ([i915#2346]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v1/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html

  * igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2:
- shard-glk:  [FAIL][19] ([i915#79]) -> [PASS][20] +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-glk1/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v1/shard-glk5/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.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#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109307]: https://bugs.freedesktop.org/show_bug.cgi?id=109307
  [fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
  [fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: workaround coherency issue for Media

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: workaround coherency issue for Media
URL   : https://patchwork.freedesktop.org/series/116751/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13034 -> Patchwork_116751v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (37 -> 36)
--

  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@reset:
- bat-rpls-1: NOTRUN -> [ABORT][1] ([i915#4983] / [i915#7981])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
- bat-adlp-6: [PASS][2] -> [ABORT][3] ([i915#4983] / [i915#7913])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-adlp-6/igt@i915_selftest@l...@reset.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/bat-adlp-6/igt@i915_selftest@l...@reset.html

  * igt@i915_selftest@live@workarounds:
- bat-rpls-1: [PASS][4] -> [DMESG-FAIL][5] ([i915#6763])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-rpls-1/igt@i915_selftest@l...@workarounds.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/bat-rpls-1/igt@i915_selftest@l...@workarounds.html

  
 Possible fixes 

  * igt@i915_selftest@live@mman:
- bat-rpls-1: [TIMEOUT][6] ([i915#6794]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13034/bat-rpls-1/igt@i915_selftest@l...@mman.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/bat-rpls-1/igt@i915_selftest@l...@mman.html

  
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6763]: https://gitlab.freedesktop.org/drm/intel/issues/6763
  [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7981]: https://gitlab.freedesktop.org/drm/intel/issues/7981


Build changes
-

  * Linux: CI_DRM_13034 -> Patchwork_116751v1

  CI-20190529: 20190529
  CI_DRM_13034: bf6a3fbb5a6d7afbbaeb93043fd0001d6b83591b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7263: a6bd8f415c4ec41b5a014c7db47e46c81ffd0074 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_116751v1: bf6a3fbb5a6d7afbbaeb93043fd0001d6b83591b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

20e858c4a176 drm/i915/mtl: workaround coherency issue for Media

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v1/index.html

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Set has_llc=0

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Set has_llc=0
URL   : https://patchwork.freedesktop.org/series/116747/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13033_full -> Patchwork_116747v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
- {shard-rkl}:[PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-rkl-2/igt@kms_rotation_...@sprite-rotation-90-pos-100-0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116747v1/shard-rkl-6/igt@kms_rotation_...@sprite-rotation-90-pos-100-0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_suspend@debugfs-reader:
- shard-snb:  [PASS][3] -> [DMESG-WARN][4] ([i915#5090])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-snb1/igt@i915_susp...@debugfs-reader.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116747v1/shard-snb5/igt@i915_susp...@debugfs-reader.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#79])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-glk3/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@bc-hdmi-a1-hdmi-a2.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116747v1/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@bc-hdmi-a1-hdmi-a2.html

  * igt@kms_hdr@bpc-switch-dpms@pipe-a-dp-1:
- shard-apl:  [PASS][7] -> [FAIL][8] ([i915#1188])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-apl1/igt@kms_hdr@bpc-switch-d...@pipe-a-dp-1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116747v1/shard-apl4/igt@kms_hdr@bpc-switch-d...@pipe-a-dp-1.html

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-b-vga-1:
- shard-snb:  NOTRUN -> [SKIP][9] ([fdo#109271]) +34 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116747v1/shard-snb5/igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-...@pipe-b-vga-1.html

  * igt@kms_psr@psr2_primary_page_flip:
- shard-apl:  NOTRUN -> [SKIP][10] ([fdo#109271]) +18 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116747v1/shard-apl6/igt@kms_psr@psr2_primary_page_flip.html

  
 Possible fixes 

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][11] ([i915#7742]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116747v1/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl:  [FAIL][13] ([i915#2842]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116747v1/shard-apl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gen9_exec_parse@allowed-single:
- shard-apl:  [ABORT][15] ([i915#5566]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-apl7/igt@gen9_exec_pa...@allowed-single.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116747v1/shard-apl6/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_pm_dc@dc9-dpms:
- {shard-tglu}:   [SKIP][17] ([i915#4281]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-tglu-6/igt@i915_pm...@dc9-dpms.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116747v1/shard-tglu-4/igt@i915_pm...@dc9-dpms.html

  * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-hdmi-a:
- {shard-dg1}:[SKIP][19] ([i915#1937]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13033/shard-dg1-18/igt@i915_pm_lpsp@kms-l...@kms-lpsp-hdmi-a.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116747v1/shard-dg1-14/igt@i915_pm_lpsp@kms-l...@kms-lpsp-hdmi-a.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl:  [FAIL][21] ([i915#2346]) -> [PASS][22]
   [21]: 

Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO

[Alex Williamson]

On Thu, 20 Apr 2023 12:10:20 +
"Liu, Yi L"  wrote:

> > From: Alex Williamson 
> > Sent: Wednesday, April 19, 2023 2:39 AM
> > 
> > On Tue, 18 Apr 2023 09:57:32 -0300
> > Jason Gunthorpe  wrote:
> >   
> > > On Mon, Apr 17, 2023 at 02:06:42PM -0600, Alex Williamson wrote:  
> > > > On Mon, 17 Apr 2023 16:31:56 -0300
> > > > Jason Gunthorpe  wrote:
> > > >  
> > > > > On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:  
> > > > > > Yes, it's not trivial, but Jason is now proposing that we consider
> > > > > > mixing groups, cdevs, and multiple iommufd_ctxs as invalid.  I think
> > > > > > this means that regardless of which device calls INFO, there's only 
> > > > > > one
> > > > > > answer (assuming same set of devices opened, all cdev, all within 
> > > > > > same
> > > > > > iommufd_ctx).  Based on what I explained about my understanding of 
> > > > > > INFO2
> > > > > > and Jason agreed to, I think the output would be:
> > > > > >
> > > > > > flags: NOT_RESETABLE | DEV_ID
> > > > > > {
> > > > > >   { valid devA-id,  devA-BDF },
> > > > > >   { valid devC-id,  devC-BDF },
> > > > > >   { valid devD-id,  devD-BDF },
> > > > > >   { invalid dev-id, devE-BDF },
> > > > > > }
> > > > > >
> > > > > > Here devB gets dropped because the kernel understands that devB is
> > > > > > unopened, affected, and owned.  It's therefore not a blocker for
> > > > > > hot-reset.  
> > > > >
> > > > > I don't think we want to drop anything because it makes the API
> > > > > ill suited for the debugging purpose.
> > > > >
> > > > > devb should be returned with an invalid dev_id if I understand your
> > > > > example. Maybe it should return with -1 as the dev_id instead of 0, to
> > > > > make the debugging a bit better.
> > > > >
> > > > > Userspace should look at only NOT_RESETTABLE to determine if it
> > > > > proceeds or not, and it should use the valid dev_id list to iterate
> > > > > over the devices it has open to do the config stuff.  
> > > >
> > > > If an affected device is owned, not opened, and not interfering with
> > > > the reset, what is it adding to the API to report it for debugging
> > > > purposes?  
> > >
> > > It lets it print the entire group of devices, this is the only way
> > > something can learn the actual list of all BDFs affected.  
> > 
> > If we do so, userspace must be able to differentiate which devices are
> > blocking, which necessitates at least a bi-modal invalid dev-id.
> >   
> > > dev_id can just return 0, we don't need a complex bitmap. Userspace
> > > looks at the flag, if !NOT_RESETABLE then it ignores dev_id=0.  
> > 
> > I'm having trouble with a succinct definition of dev-id == 0, is it "A
> > device affected by the hot-reset reset, which does not directly
> > contribute to the availability of the hot-reset, ex. an unopened device
> > within the same IOMMU group as an opened device (ie. this is not the
> > device responsible if hot-reset is unavailable).   
> 
> Hide this device in the list looks fine to me. But the calling user should
> not do any new device open before finishing hot-reset. Otherwise, user may
> miss a device that needs to do pre/post reset. I think this requirement is
> acceptable. Is it? 

I think Kevin and Jason are leaning towards reporting the entire
dev-set.  The INFO ioctl has always been a point-in-time reading, no
guarantees are made if the host or user configuration is changed.
Nothing changes in that respect.

> > Whereas dev-id < 0
> > (== -1) is an affected device which prevents hot-reset, ex. an un-owned
> > device, device configured within a different iommufd_ctx, or device
> > opened outside of the vfio cdev API."  Is that about right?  Thanks,  
> 
> Do you mean to have separate err-code for the three possibilities? As
> the devid is generated by iommufd and it is u32. I'm not sure if we can
> have such err-code definition without reserving some ids in iommufd. 

Yes, if we're going to report the full dev-set, I think we need at
least two unique error codes or else the user has no way to determine
the subset of invalid dev-ids which block the reset.  I think Jason is
proposing the set of valid dev-ids are >0, a dev-id of zero indicates
some form of non-blocking, while <0 (or maybe specifically -1)
indicates a blocking device.  I was trying to get consensus on a formal
definition of each of those error codes in my previous reply.  Thanks,

Alex

Re: [Intel-gfx] [Intel-xe] [PATCH v4] drm/i915: Initialize dkl_phy spin lock from display code path

[Souza, Jose]

On Wed, 2023-04-19 at 00:29 -0700, Lucas De Marchi wrote:
> On Wed, Apr 19, 2023 at 10:16:22AM +0300, Jani Nikula wrote:
> > On Tue, 18 Apr 2023, Lucas De Marchi  wrote:
> > > On Tue, Apr 18, 2023 at 11:30:18PM -0700, Lucas De Marchi wrote:
> > > > On Tue, Apr 18, 2023 at 09:43:37AM -0700, Jose Souza wrote:
> > > > > Start to move the initialization of display locks from
> > > > > i915_driver_early_probe(), this way it is also executed when running
> > > > > Xe kmd.
> > > > > 
> > > > > This will fix a warning in Xe kmd:
> > > > > 
> > > > > [  201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] 
> > > > > failed to retrieve link info, disabling eDP
> > > > > [  202.136336] xe :00:02.0: [drm] *ERROR* Failed to write source 
> > > > > OUI
> > > > > [  202.175346] INFO: trying to register non-static key.
> > > > > [  202.175347] irq event stamp: 754060
> > > > > [  202.175359] hardirqs last  enabled at (754059): 
> > > > > [] tick_nohz_idle_enter+0x59/0x80
> > > > > [  202.180294] The code is fine but needs lockdep annotation, or maybe
> > > > > [  202.183774] hardirqs last disabled at (754060): 
> > > > > [] do_idle+0x99/0x230
> > > > > [  202.192734] you didn't initialize this object before use?
> > > > > [  202.198951] softirqs last  enabled at (753948): 
> > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > [  202.206882] turning off the locking correctness validator.
> > > > > [  202.212236] softirqs last disabled at (753943): 
> > > > > [] irq_exit_rcu+0xbe/0x130
> > > > > [  202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: GW
> > > > >   6.3.0-rc4+zeh-xe+ #909
> > > > > [  202.243002] Hardware name: Intel Corporation Raptor Lake Client 
> > > > > Platform/RaptorLake-P LP5 RVP, BIOS RPLPFWI1.R00.3361.A14.2211151548 
> > > > > 11/15/2022
> > > > > [  202.255737] Call Trace:
> > > > > [  202.258179]  
> > > > > [  202.260275]  dump_stack_lvl+0x58/0xc0
> > > > > [  202.263922]  register_lock_class+0x756/0x7d0
> > > > > [  202.268165]  ? find_held_lock+0x2b/0x80
> > > > > [  202.271975]  __lock_acquire+0x72/0x28b0
> > > > > [  202.275786]  ? debug_object_free+0xb4/0x160
> > > > > [  202.279946]  lock_acquire+0xd1/0x2d0
> > > > > [  202.283503]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > [  202.288181]  _raw_spin_lock+0x2a/0x40
> > > > > [  202.291825]  ? intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > [  202.296475]  intel_dkl_phy_read+0x18/0x60 [xe]
> > > > > [  202.300949]  icl_aux_power_well_enable+0x2bd/0x400 [xe]
> > > > > [  202.306202]  ? intel_display_power_grab_async_put_ref+0x75/0x120 
> > > > > [xe]
> > > > > [  202.312649]  intel_power_well_enable+0x1c/0x70 [xe]
> > > > > [  202.317543]  __intel_display_power_get_domain.part.0+0x4d/0x70 [xe]
> > > > > [  202.323812]  intel_display_power_get+0x43/0x70 [xe]
> > > > > [  202.328708]  intel_tc_port_init+0x199/0x2a0 [xe]
> > > > > [  202.63]  intel_ddi_init+0x6ad/0xb00 [xe]
> > > > > [  202.337678]  intel_modeset_init_nogem+0x536/0x6d0 [xe]
> > > > > [  202.342838]  xe_display_init_noaccel+0x19/0x40 [xe]
> > > > > [  202.347743]  xe_device_probe+0x1f5/0x2a0 [xe]
> > > > > [  202.352127]  xe_pci_probe+0x28c/0x480 [xe]
> > > > > [  202.356260]  pci_device_probe+0x9d/0x150
> > > > > [  202.360164]  really_probe+0x19a/0x400
> > > > > [  202.363809]  ? __pfx___driver_attach+0x10/0x10
> > > > > [  202.368226]  __driver_probe_device+0x73/0x170
> > > > > [  202.372558]  driver_probe_device+0x1a/0x90
> > > > > [  202.376632]  __driver_attach+0xcd/0x1c0
> > > > > [  202.380442]  bus_for_each_dev+0x72/0xc0
> > > > > [  202.384253]  bus_add_driver+0x110/0x210
> > > > > [  202.388063]  driver_register+0x50/0x100
> > > > > [  202.391873]  ? __pfx_init_module+0x10/0x10 [xe]
> > > > > [  202.396431]  do_one_initcall+0x55/0x260
> > > > > [  202.400245]  ? rcu_is_watching+0xd/0x40
> > > > > [  202.404058]  ? kmalloc_trace+0xa0/0xb0
> > > > > [  202.407786]  do_init_module+0x45/0x1e0
> > > > > [  202.411512]  __do_sys_finit_module+0xac/0x120
> > > > > [  202.415838]  do_syscall_64+0x37/0x90
> > > > > [  202.419397]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
> > > > > [  202.424409] RIP: 0033:0x7fd11291ea3d
> > > > > [  202.427967] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e 
> > > > > fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 
> > > > > 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 a3 0f 00 f7 d8 64 
> > > > > 89 01 48
> > > > > [  202.446530] RSP: 002b:7de11368 EFLAGS: 0246 ORIG_RAX: 
> > > > > 0139
> > > > > [  202.454031] RAX: ffda RBX: 5616a617f210 RCX: 
> > > > > 7fd11291ea3d
> > > > > [  202.461106] RDX:  RSI: 5616a617fe60 RDI: 
> > > > > 000e
> > > > > [  202.468182] RBP: 0004 R08:  R09: 
> > > > > 0002
> > > > > [  202.475250] R10: 000e R11: 0246 R12: 
> > > > > 5616a617fe60
> > > > > [  202.482319] R13: 5616a617f340 R14:  R15: 
> 

Re: [Intel-gfx] [RFC 4/6] drm: Add simple fdinfo memory helpers

[Tvrtko Ursulin]

On 19/04/2023 15:32, Rob Clark wrote:

On Wed, Apr 19, 2023 at 6:16 AM Tvrtko Ursulin
 wrote:



On 18/04/2023 18:18, Rob Clark wrote:

On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
 wrote:


From: Tvrtko Ursulin 

For drivers who only wish to show one memory region called 'system,
and only account the GEM buffer object handles under it.

Signed-off-by: Tvrtko Ursulin 
---
   drivers/gpu/drm/drm_file.c | 45 ++
   include/drm/drm_file.h |  6 +
   2 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index e202f79e816d..1e70669dddf7 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -872,6 +872,51 @@ void drm_send_event(struct drm_device *dev, struct 
drm_pending_event *e)
   }
   EXPORT_SYMBOL(drm_send_event);

+static void
+add_obj(struct drm_gem_object *obj, struct drm_fdinfo_memory_stat *stats)
+{
+   u64 sz = obj->size;
+
+   stats[0].size += sz;
+
+   if (obj->handle_count > 1)
+   stats[0].shared += sz;
+
+   if (!dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true)))
+   stats[0].active += sz;
+
+   /* Not supported. */
+   stats[0].resident = ~0ull;
+   stats[0].purgeable = ~0ull;


Hmm, this kinda makes the simple helper not very useful.  In my
version, you get something that is useful for all UMA drivers (which
all, IIRC, have some form of madv ioctl).  I was kinda imagining that
for ttm drivers, my print_memory_stats() would just become a helper
and that TTM (or "multi-region") drivers would have their own thing.


Hm how? Your version also needed a driver specific vfunc:


Sure, but there is a possibility for a driver specific vfunc ;-)


Indeed, they are there in both proposals! :)


And arguably we could move madv to drm_gem_object, along with get/put
pages tracking.. since all the UMA drivers pretty much do the same
thing.  So maybe the vfunc is a temporary thing.

Anyways, I could go back to my original version where it was a helper
called from the driver to print mem stats.  That way, TTM drivers
could do their own thing.


I must have missed that. So it was the same idea as in my RFC?

Regards,

Tvrtko
 

BR,
-R


+static enum drm_gem_object_status msm_gem_status(struct drm_gem_object *obj)
+{
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
+   enum drm_gem_object_status status = 0;
+
+   if (msm_obj->pages)
+   status |= DRM_GEM_OBJECT_RESIDENT;
+
+   if (msm_obj->madv == MSM_MADV_DONTNEED)
+   status |= DRM_GEM_OBJECT_PURGEABLE;
+
+   return status;
+}

Regards,

Tvrtko



BR,
-R


+}
+
+char **
+drm_query_fdinfo_system_region(struct drm_device *dev, unsigned int *num)
+{
+   static char *region[] = {
+   "system",
+   };
+
+   *num = 1;
+
+   return region;
+}
+EXPORT_SYMBOL(drm_query_fdinfo_system_region);
+
+void
+drm_query_fdinfo_system_memory(struct drm_file *file,
+  struct drm_fdinfo_memory_stat *stats)
+{
+   struct drm_gem_object *obj;
+   int id;
+
+   spin_lock(>table_lock);
+   idr_for_each_entry(>object_idr, obj, id)
+   add_obj(obj, stats);
+   spin_unlock(>table_lock);
+}
+EXPORT_SYMBOL(drm_query_fdinfo_system_memory);
+
   static void
   print_stat(struct drm_printer *p, const char *stat, const char *region, u64 
sz)
   {
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 00d48beeac5c..dd7c6fb2c975 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -383,6 +383,12 @@ struct drm_fdinfo_memory_stat {
  u64 active;
   };

+char **drm_query_fdinfo_system_region(struct drm_device *dev,
+ unsigned int *num);
+void drm_query_fdinfo_system_memory(struct drm_file *file,
+   struct drm_fdinfo_memory_stat *stats);
+
+
   /**
* drm_is_primary_client - is this an open file of the primary node
* @file_priv: DRM file
--
2.37.2

Re: [Intel-gfx] [RFC 6/6] drm/i915: Implement fdinfo memory stats printing

[Tvrtko Ursulin]

On 19/04/2023 15:38, Rob Clark wrote:

On Wed, Apr 19, 2023 at 7:06 AM Tvrtko Ursulin
 wrote:



On 18/04/2023 17:08, Rob Clark wrote:

On Tue, Apr 18, 2023 at 7:58 AM Tvrtko Ursulin
 wrote:

On 18/04/2023 15:39, Rob Clark wrote:

On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
 wrote:


From: Tvrtko Ursulin 

Show how more driver specific set of memory stats could be shown,
more specifically where object can reside in multiple regions, showing all
the supported stats, and where there is more to show than just user visible
objects.

WIP...

Signed-off-by: Tvrtko Ursulin 
---
drivers/gpu/drm/i915/i915_driver.c |   5 ++
drivers/gpu/drm/i915/i915_drm_client.c | 102 +
drivers/gpu/drm/i915/i915_drm_client.h |   8 ++
drivers/gpu/drm/i915/i915_drv.h|   2 +
4 files changed, 117 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 6493548c69bf..4c70206cbc27 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1806,6 +1806,11 @@ static const struct drm_driver i915_drm_driver = {
   .dumb_create = i915_gem_dumb_create,
   .dumb_map_offset = i915_gem_dumb_mmap_offset,

+#ifdef CONFIG_PROC_FS
+   .query_fdinfo_memory_regions = i915_query_fdinfo_memory_regions,
+   .query_fdinfo_memory_stats = i915_query_fdinfo_memory_stats,
+#endif
+
   .ioctls = i915_ioctls,
   .num_ioctls = ARRAY_SIZE(i915_ioctls),
   .fops = _driver_fops,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c 
b/drivers/gpu/drm/i915/i915_drm_client.c
index c654984189f7..65857c68bdb3 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -12,6 +12,7 @@
#include 

#include "gem/i915_gem_context.h"
+#include "intel_memory_region.h"
#include "i915_drm_client.h"
#include "i915_file_private.h"
#include "i915_gem.h"
@@ -112,4 +113,105 @@ void i915_drm_client_fdinfo(struct drm_printer *p, struct 
drm_file *file)
   for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
   show_client_class(p, i915, file_priv->client, i);
}
+
+char **
+i915_query_fdinfo_memory_regions(struct drm_device *dev, unsigned int *num)
+{
+   struct drm_i915_private *i915 = to_i915(dev);
+   struct intel_memory_region *mr;
+   enum intel_region_id id;
+
+   /* FIXME move to init */
+   for_each_memory_region(mr, i915, id) {
+   if (!i915->mm.region_names[id])
+   i915->mm.region_names[id] = mr->name;
+   }
+
+   *num = id;
+
+   return i915->mm.region_names;
+}
+
+static void
+add_obj(struct drm_i915_gem_object *obj, struct drm_fdinfo_memory_stat *stats)
+{
+struct intel_memory_region *mr;
+   u64 sz = obj->base.size;
+enum intel_region_id id;
+   unsigned int i;
+
+   if (!obj)
+   return;
+
+   /* Attribute size and shared to all possible memory regions. */
+   for (i = 0; i < obj->mm.n_placements; i++) {
+   mr = obj->mm.placements[i];
+   id = mr->id;
+
+   stats[id].size += sz;


This implies that summing up all of the categories is not the same as
the toplevel stats that I was proposing


Sorry, I mis-spoke, I meant "summing up all of the regions is not..."


Ah okay. It could be made like that yes.

I wasn't sure what would be more useful for drivers which support memory
regions. To see how much memory file could be using worst case, or
strictly how much it is currently using. So for buffer objects where
userspace allows kernel to choose the region from a supplied list, I
thought it would be useful to show that in total size against all
possible regions.

In a way you see this driver /could/ be using 1G in vram and 1G in
system, but currently it only has resident 1G in vram. Or you see
another file which has 1G vram size and 1G resident size and you can
infer some things.


AFAIU all the buffers could exist in system memory at some point in
time, and vram is more like an explicitly managed fast cache.  Like,
what happens on suspend to ram or hibernate, I assume you don't keep
vram powered?


Yeah they can be swapped out on suspend, but that's different that 
buffers which are explicitly marked as being allowed to exist in either 
region at runtime.



Perhaps that can be confusing and it would be better to let total size
migrate between regions at runtime as does resident and other
categories. But then the total size per region would change at runtime
influenced by other app activity (as driver is transparently migrating
buffers between regions). Which can also be very confusing, it would
appear as if the app is creating/freeing objects when it isn't.

Correct, my categories are a bit different. You had private and shared as two 
mutually exclusive buckets, and then resident as subset of either/both. I have 
size as analogue to VmSize and resident as 

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Allow user to set cache at BO creation

[Tvrtko Ursulin]

On 20/04/2023 12:39, Andi Shyti wrote:

Hi Fei,


To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a default (platform dependent) cache setting for all objects.
However this is not optimal for performance tuning. The patch extends
the existing gem_create uAPI to let user set PAT index for the object
at creation time.
The new extension is platform independent, so UMD's can switch to using
this extension for older platforms as well, while {set, get}_caching are
still supported on these legacy paltforms for compatibility reason.

Cc: Chris Wilson 
Cc: Matt Roper 
Cc: Andi Shyti 
Signed-off-by: Fei Yang 
Reviewed-by: Andi Shyti 


because this is an API change, we need some more information
here.

First of all you need to CC the userspace guys that have been
working on top of your series and get their ack's.


Yes, and a link to a Mesa merge request which uses the uapi should be 
included.


IGTs should be ready to before we can merge. I glanced over igt-dev but 
did not spot anything.


Regards,

Tvrtko



I also believe that this series has also been tested on a
separate repository, would you link it in the commit message?

Thanks,
Andi

Re: [Intel-gfx] [PATCH 2/2] drm/dsc: fix DP_DSC_MAX_BPP_DELTA_* macro values

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 4/6/2023 7:16 PM, Jani Nikula wrote:

The macro values just don't match the specs. Fix them.

Fixes: 1482ec00be4a ("drm: Add missing DP DSC extended capability definitions.")
Cc: Vinod Govindapillai 
Cc: Stanislav Lisovskiy 
Signed-off-by: Jani Nikula 
---
  include/drm/display/drm_dp.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 89d5a700b04d..f8813c1e059b 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -286,8 +286,8 @@
  
  #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */

  # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK  (0x3 << 0)
-# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK  0x06
-# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY  0x08
+# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK  (0x3 << 5)   /* eDP 1.5 & DP 2.0 */
+# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY  (1 << 7) /* eDP 1.5 & DP 2.0 */
  
  #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069

  # define DP_DSC_RGB (1 << 0)

[Intel-gfx] [PATCH 13/13] drm/i915/mtl: Enable TC ports

[Mika Kahola]

Finally, we can enable TC ports for Meteorlake.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_display.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e70bdf0e06f3..dc777c3b1b1a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7587,9 +7587,12 @@ void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
return;
 
if (IS_METEORLAKE(dev_priv)) {
-   /* TODO: initialize TC ports as well */
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
+   intel_ddi_init(dev_priv, PORT_TC1);
+   intel_ddi_init(dev_priv, PORT_TC2);
+   intel_ddi_init(dev_priv, PORT_TC3);
+   intel_ddi_init(dev_priv, PORT_TC4);
} else if (IS_DG2(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
-- 
2.34.1

[Intel-gfx] [PATCH 12/13] drm/i915/mtl: Pin assignment for TypeC

[Mika Kahola]

From: Anusha Srivatsa 

Unlike previous platforms that used PORT_TX_DFLEXDPSP
for max_lane calculation, MTL uses only PORT_TX_DFLEXPA1
from which the max_lanes has to be calculated.

Bspec: 50235, 65380

Signed-off-by: Anusha Srivatsa 
Signed-off-by: Jose Roberto de Souza 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_tc.c | 28 +
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index b192265a3d78..4fca711a58bc 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -16,6 +16,10 @@
 #include "intel_mg_phy_regs.h"
 #include "intel_tc.h"
 
+#define DP_PIN_ASSIGNMENT_C0x3
+#define DP_PIN_ASSIGNMENT_D0x4
+#define DP_PIN_ASSIGNMENT_E0x5
+
 enum tc_port_mode {
TC_PORT_DISCONNECTED,
TC_PORT_TBT_ALT,
@@ -281,6 +285,27 @@ u32 intel_tc_port_get_pin_assignment_mask(struct 
intel_digital_port *dig_port)
   DP_PIN_ASSIGNMENT_SHIFT(tc->phy_fia_idx);
 }
 
+static int mtl_tc_port_get_pin_assignment_mask(struct intel_digital_port 
*dig_port)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   intel_wakeref_t wakeref;
+   u32 pin_mask;
+
+   with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
+   pin_mask = intel_tc_port_get_pin_assignment_mask(dig_port);
+
+   switch (pin_mask) {
+   default:
+   MISSING_CASE(pin_mask);
+   fallthrough;
+   case DP_PIN_ASSIGNMENT_D:
+   return 2;
+   case DP_PIN_ASSIGNMENT_C:
+   case DP_PIN_ASSIGNMENT_E:
+   return 4;
+   }
+}
+
 int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
@@ -294,6 +319,9 @@ int intel_tc_port_fia_max_lane_count(struct 
intel_digital_port *dig_port)
 
assert_tc_cold_blocked(tc);
 
+   if (DISPLAY_VER(i915) >= 14)
+   return mtl_tc_port_get_pin_assignment_mask(dig_port);
+
lane_mask = 0;
with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
lane_mask = intel_tc_port_get_lane_mask(dig_port);
-- 
2.34.1

[Intel-gfx] [PATCH 10/13] drm/i915/mtl: Power up TCSS

[Mika Kahola]

Add register writes to enable powering up Type-C subsystem i.e. TCSS.
For MeteorLake we need to request TCSS to power up and check the TCSS
power state after 500 us.

In addition, for PICA we need to set/clear the Type-C PHY ownnership
bit when Type-C device is connected/disconnected.

Signed-off-by: Mika Kahola 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c |  19 ++
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |   4 +
 drivers/gpu/drm/i915/display/intel_ddi.c |   1 +
 drivers/gpu/drm/i915/display/intel_display.c |   2 +-
 drivers/gpu/drm/i915/display/intel_tc.c  | 199 ++-
 5 files changed, 216 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index dc005e61..97d80adb921f 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2884,6 +2884,25 @@ void intel_mtl_pll_disable(struct intel_encoder *encoder)
intel_cx0pll_disable(encoder);
 }
 
+enum icl_port_dpll_id
+intel_mtl_port_pll_type(struct intel_encoder *encoder,
+   const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   /*
+* TODO: Determine the PLL type from the SW state, once MTL PLL
+* handling is done via the standard shared DPLL framework.
+*/
+   u32 val = intel_de_read(i915, XELPDP_PORT_CLOCK_CTL(encoder->port));
+   u32 clock = REG_FIELD_GET(XELPDP_DDI_CLOCK_SELECT_MASK, val);
+
+   if (clock == XELPDP_DDI_CLOCK_SELECT_MAXPCLK ||
+   clock == XELPDP_DDI_CLOCK_SELECT_DIV18CLK)
+   return ICL_PORT_DPLL_MG_PHY;
+   else
+   return ICL_PORT_DPLL_DEFAULT;
+}
+
 void intel_c10pll_state_verify(struct intel_atomic_state *state,
   struct intel_crtc_state *new_crtc_state)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index c1b8f7980f69..f99809af257d 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -16,12 +16,16 @@
 struct drm_i915_private;
 struct intel_encoder;
 struct intel_crtc_state;
+enum icl_port_dpll_id;
 enum phy;
 
 bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy);
 void intel_mtl_pll_enable(struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state);
 void intel_mtl_pll_disable(struct intel_encoder *encoder);
+enum icl_port_dpll_id
+intel_mtl_port_pll_type(struct intel_encoder *encoder,
+   const struct intel_crtc_state *crtc_state);
 void intel_c10pll_readout_hw_state(struct intel_encoder *encoder, struct 
intel_c10pll_state *pll_state);
 int intel_cx0pll_calc_state(struct intel_crtc_state *crtc_state, struct 
intel_encoder *encoder);
 void intel_c10pll_dump_hw_state(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 8f0f858cde31..55f36d9d509c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4784,6 +4784,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
if (DISPLAY_VER(dev_priv) >= 14) {
encoder->enable_clock = intel_mtl_pll_enable;
encoder->disable_clock = intel_mtl_pll_disable;
+   encoder->port_pll_type = intel_mtl_port_pll_type;
encoder->get_config = mtl_ddi_get_config;
} else if (IS_DG2(dev_priv)) {
encoder->enable_clock = intel_mpllb_enable;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 1c264c17b6e4..e70bdf0e06f3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1757,7 +1757,7 @@ bool intel_phy_is_tc(struct drm_i915_private *dev_priv, 
enum phy phy)
if (IS_DG2(dev_priv))
/* DG2's "TC1" output uses a SNPS PHY */
return false;
-   else if (IS_ALDERLAKE_P(dev_priv))
+   else if (IS_ALDERLAKE_P(dev_priv) || IS_METEORLAKE(dev_priv))
return phy >= PHY_F && phy <= PHY_I;
else if (IS_TIGERLAKE(dev_priv))
return phy >= PHY_D && phy <= PHY_I;
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 3b60995e9dfb..951b12ac51dc 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -5,6 +5,7 @@
 
 #include "i915_drv.h"
 #include "i915_reg.h"
+#include "intel_cx0_phy_regs.h"
 #include "intel_ddi.h"
 #include "intel_de.h"
 #include "intel_display.h"
@@ -59,6 +60,7 @@ static enum intel_display_power_domain
 tc_phy_cold_off_domain(struct intel_tc_port *);
 static u32 

[Intel-gfx] [PATCH 05/13] drm/i915/mtl: Add voltage swing sequence for C20

[Mika Kahola]

DP1.4 and DP20 voltage swing sequence for C20 phy.

Bspec: 65449, 67636, 67610

Signed-off-by: Mika Kahola 
Signed-off-by: Clint Taylor 
Signed-off-by: Radhakrishna Sripada 
---
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |  4 ++
 .../drm/i915/display/intel_ddi_buf_trans.c| 53 ++-
 2 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
index a5e5bee24533..5305cc8aad8e 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
@@ -211,6 +211,10 @@
 #define   C20_MULTIPLIER_MASK  REG_GENMASK(11, 0)
 #define   C20_PHY_USE_MPLLBREG_BIT(7)
 
+/* C20 Phy VSwing Masks */
+#define C20_PHY_VSWING_PREEMPH_MASKREG_GENMASK8(5, 0)
+#define C20_PHY_VSWING_PREEMPH(val)
REG_FIELD_PREP8(C20_PHY_VSWING_PREEMPH_MASK, val)
+
 #define RAWLANEAONX_DIG_TX_MPLLB_CAL_DONE_BANK(idx) (0x303D + (idx))
 
 #endif /* __INTEL_CX0_REG_DEFS_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c 
b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
index cd4becbae098..b7d20485bde5 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
@@ -9,6 +9,7 @@
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_dp.h"
+#include "intel_cx0_phy.h"
 
 /* HDMI/DVI modes ignore everything but the last 2 items. So we share
  * them for both DP and FDI transports, allowing those ports to
@@ -1048,12 +1049,52 @@ static const union intel_ddi_buf_trans_entry 
_mtl_c10_trans_dp14[] = {
{ .snps = { 62, 0, 0  } },  /* preset 9 */
 };
 
-static const struct intel_ddi_buf_trans mtl_cx0c10_trans = {
+static const struct intel_ddi_buf_trans mtl_cx0_trans = {
.entries = _mtl_c10_trans_dp14,
.num_entries = ARRAY_SIZE(_mtl_c10_trans_dp14),
.hdmi_default_entry = ARRAY_SIZE(_mtl_c10_trans_dp14) - 1,
 };
 
+/* DP2.0 */
+static const union intel_ddi_buf_trans_entry _mtl_c20_trans_uhbr[] = {
+   { .snps = { 48, 0, 0 } },   /* preset 0 */
+   { .snps = { 43, 0, 5 } },   /* preset 1 */
+   { .snps = { 40, 0, 8 } },   /* preset 2 */
+   { .snps = { 37, 0, 11 } },  /* preset 3 */
+   { .snps = { 33, 0, 15 } },  /* preset 4 */
+   { .snps = { 46, 2, 0 } },   /* preset 5 */
+   { .snps = { 42, 2, 4 } },   /* preset 6 */
+   { .snps = { 38, 2, 8 } },   /* preset 7 */
+   { .snps = { 35, 2, 11 } },  /* preset 8 */
+   { .snps = { 33, 2, 13 } },  /* preset 9 */
+   { .snps = { 44, 4, 0 } },   /* preset 10 */
+   { .snps = { 40, 4, 4 } },   /* preset 11 */
+   { .snps = { 37, 4, 7 } },   /* preset 12 */
+   { .snps = { 33, 4, 11 } },  /* preset 13 */
+   { .snps = { 40, 8, 0 } },   /* preset 14 */
+   { .snps = { 28, 2, 2 } },   /* preset 15 */
+};
+
+/* HDMI2.0 */
+static const union intel_ddi_buf_trans_entry _mtl_c20_trans_hdmi[] = {
+   { .snps = { 48, 0, 0 } },   /* preset 0 */
+   { .snps = { 38, 4, 6 } },   /* preset 1 */
+   { .snps = { 36, 4, 8 } },   /* preset 2 */
+   { .snps = { 34, 4, 10 } },  /* preset 3 */
+   { .snps = { 32, 4, 12 } },  /* preset 4 */
+};
+
+static const struct intel_ddi_buf_trans mtl_c20_trans_hdmi = {
+   .entries = _mtl_c20_trans_hdmi,
+   .num_entries = ARRAY_SIZE(_mtl_c20_trans_hdmi),
+   .hdmi_default_entry = 0,
+};
+
+static const struct intel_ddi_buf_trans mtl_c20_trans_uhbr = {
+   .entries = _mtl_c20_trans_uhbr,
+   .num_entries = ARRAY_SIZE(_mtl_c20_trans_uhbr),
+};
+
 bool is_hobl_buf_trans(const struct intel_ddi_buf_trans *table)
 {
return table == _combo_phy_trans_edp_hbr2_hobl;
@@ -1630,7 +1671,15 @@ mtl_get_cx0_buf_trans(struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state,
  int *n_entries)
 {
-   return intel_get_buf_trans(_cx0c10_trans, n_entries);
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum phy phy = intel_port_to_phy(i915, encoder->port);
+
+   if (intel_crtc_has_dp_encoder(crtc_state) && crtc_state->port_clock >= 
100)
+   return intel_get_buf_trans(_c20_trans_uhbr, n_entries);
+   else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) && 
!(intel_is_c10phy(i915, phy)))
+   return intel_get_buf_trans(_c20_trans_hdmi, n_entries);
+   else
+   return intel_get_buf_trans(_cx0_trans, n_entries);
 }
 
 void intel_ddi_buf_trans_init(struct intel_encoder *encoder)
-- 
2.34.1

[Intel-gfx] [PATCH 06/13] drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA

[Mika Kahola]

Use MPLLA for DP2.0 rates 20G and 20G, when ssc is enabled.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index f7720acaf58c..4231ba98f075 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2340,8 +2340,11 @@ static void intel_program_port_clock_ctl(struct 
intel_encoder *encoder,
val |= XELPDP_DDI_CLOCK_SELECT(XELPDP_DDI_CLOCK_SELECT_MAXPCLK);
 
/* TODO: HDMI FRL */
-   /* TODO: DP2.0 10G and 20G rates enable MPLLA*/
-   val |= crtc_state->cx0pll_state.ssc_enabled ? XELPDP_SSC_ENABLE_PLLB : 
0;
+   /* DP2.0 10G and 20G rates enable MPLLA*/
+   if (crtc_state->port_clock == 100 || crtc_state->port_clock == 
200)
+   val |= crtc_state->cx0pll_state.ssc_enabled ? 
XELPDP_SSC_ENABLE_PLLA : 0;
+   else
+   val |= crtc_state->cx0pll_state.ssc_enabled ? 
XELPDP_SSC_ENABLE_PLLB : 0;
 
intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->port),
 XELPDP_LANE1_PHY_CLOCK_SELECT | 
XELPDP_FORWARD_CLOCK_UNGATE |
-- 
2.34.1

[Intel-gfx] [PATCH 07/13] drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll

[Mika Kahola]

Enabling and disabling sequence for Thunderbolt PLL.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 135 ++-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |   7 +-
 drivers/gpu/drm/i915/display/intel_ddi.c |   4 +-
 3 files changed, 138 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 4231ba98f075..9722d3f1b926 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2600,8 +2600,8 @@ static u32 intel_cx0_get_pclk_pll_ack(u8 lane_mask)
return val;
 }
 
-void intel_cx0pll_enable(struct intel_encoder *encoder,
-const struct intel_crtc_state *crtc_state)
+static void intel_cx0pll_enable(struct intel_encoder *encoder,
+   const struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(i915, encoder->port);
@@ -2676,7 +2676,86 @@ void intel_cx0pll_enable(struct intel_encoder *encoder,
intel_cx0_phy_transaction_end(encoder, wakeref);
 }
 
-void intel_cx0pll_disable(struct intel_encoder *encoder)
+static int intel_mtl_tbt_clock_select(struct drm_i915_private *i915, int clock)
+{
+   switch (clock) {
+   case 162000:
+   return XELPDP_DDI_CLOCK_SELECT_TBT_162;
+   case 27:
+   return XELPDP_DDI_CLOCK_SELECT_TBT_270;
+   case 54:
+   return XELPDP_DDI_CLOCK_SELECT_TBT_540;
+   case 81:
+   return XELPDP_DDI_CLOCK_SELECT_TBT_810;
+   default:
+   MISSING_CASE(clock);
+   return XELPDP_DDI_CLOCK_SELECT_TBT_162;
+   }
+}
+
+static void intel_mtl_tbt_pll_enable(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum phy phy = intel_port_to_phy(i915, encoder->port);
+   u32 val = 0;
+
+   /*
+* 1. Program PORT_CLOCK_CTL REGISTER to configure
+* clock muxes, gating and SSC
+*/
+   val |= XELPDP_DDI_CLOCK_SELECT(intel_mtl_tbt_clock_select(i915, 
crtc_state->port_clock));
+   val |= XELPDP_FORWARD_CLOCK_UNGATE;
+   intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->port),
+XELPDP_DDI_CLOCK_SELECT_MASK | 
XELPDP_FORWARD_CLOCK_UNGATE, val);
+
+   /* 2. Read back PORT_CLOCK_CTL REGISTER */
+   val = intel_de_read(i915, XELPDP_PORT_CLOCK_CTL(encoder->port));
+
+   /*
+* 3. Follow the Display Voltage Frequency Switching - Sequence
+* Before Frequency Change. We handle this step in bxt_set_cdclk().
+*/
+
+   /*
+* 4. Set PORT_CLOCK_CTL register TBT CLOCK Request to "1" to enable 
PLL.
+*/
+   val |= XELPDP_TBT_CLOCK_REQUEST;
+   intel_de_write(i915, XELPDP_PORT_CLOCK_CTL(encoder->port), val);
+
+   /* 5. Poll on PORT_CLOCK_CTL TBT CLOCK Ack == "1". */
+   if (__intel_wait_for_register(>uncore, 
XELPDP_PORT_CLOCK_CTL(encoder->port),
+ XELPDP_TBT_CLOCK_ACK,
+ XELPDP_TBT_CLOCK_ACK,
+ 100, 0, NULL))
+   drm_warn(>drm, "[ENCODER:%d:%s][%c] PHY PLL not locked 
after 100us.\n",
+encoder->base.base.id, encoder->base.name, 
phy_name(phy));
+
+   /*
+* 6. Follow the Display Voltage Frequency Switching Sequence After
+* Frequency Change. We handle this step in bxt_set_cdclk().
+*/
+
+   /*
+* 7. Program DDI_CLK_VALFREQ to match intended DDI
+* clock frequency.
+*/
+   intel_de_write(i915, DDI_CLK_VALFREQ(encoder->port),
+  crtc_state->port_clock);
+}
+
+void intel_mtl_pll_enable(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
+   if (intel_tc_port_in_tbt_alt_mode(dig_port))
+   intel_mtl_tbt_pll_enable(encoder, crtc_state);
+   else
+   intel_cx0pll_enable(encoder, crtc_state);
+}
+
+static void intel_cx0pll_disable(struct intel_encoder *encoder)
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(i915, encoder->port);
@@ -2728,6 +2807,56 @@ void intel_cx0pll_disable(struct intel_encoder *encoder)
intel_cx0_phy_transaction_end(encoder, wakeref);
 }
 
+static void intel_mtl_tbt_pll_disable(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum phy phy = intel_port_to_phy(i915, encoder->port);
+
+   /*
+* 1. Follow the Display Voltage Frequency Switching Sequence Before
+* Frequency 

[Intel-gfx] [PATCH 09/13] drm/i915/mtl: Define mask for DDI AUX interrupts

[Mika Kahola]

From: Gustavo Sousa 

Xe_LPD+ defines interrupt bits for only DDI ports in the DE Port
Interrupt registers. The bits for Type-C ports are defined in the PICA
interrupt registers.

BSpec: 50064
Signed-off-by: Gustavo Sousa 
---
 drivers/gpu/drm/i915/i915_irq.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2b94b8ca8ec9..e5f12aa141f6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1938,7 +1938,10 @@ static u32 gen8_de_port_aux_mask(struct drm_i915_private 
*dev_priv)
 {
u32 mask;
 
-   if (DISPLAY_VER(dev_priv) >= 13)
+   if (DISPLAY_VER(dev_priv) >= 14)
+   return TGL_DE_PORT_AUX_DDIA |
+   TGL_DE_PORT_AUX_DDIB;
+   else if (DISPLAY_VER(dev_priv) >= 13)
return TGL_DE_PORT_AUX_DDIA |
TGL_DE_PORT_AUX_DDIB |
TGL_DE_PORT_AUX_DDIC |
-- 
2.34.1

[Intel-gfx] [PATCH 11/13] drm/i915/mtl: TypeC HPD live status query

[Mika Kahola]

From: Imre Deak 

The HPD live status for MTL has to be read from different set of
registers. MTL deserves a new function for this purpose
and cannot reuse the existing  HPD live status detection

Signed-off-by: Anusha Srivatsa 
Signed-off-by: Imre Deak 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_tc.c | 30 -
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 951b12ac51dc..b192265a3d78 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -886,6 +886,34 @@ static const struct intel_tc_phy_ops adlp_tc_phy_ops = {
  * XELPDP TC PHY handlers
  * --
  */
+static u32 xelpdp_tc_phy_hpd_live_status(struct intel_tc_port *tc)
+{
+   struct drm_i915_private *i915 = tc_to_i915(tc);
+   struct intel_digital_port *dig_port = tc->dig_port;
+   enum hpd_pin hpd_pin = dig_port->base.hpd_pin;
+   u32 pica_isr_bits = i915->display.hotplug.hpd[hpd_pin];
+   u32 pch_isr_bit = i915->display.hotplug.pch_hpd[hpd_pin];
+   intel_wakeref_t wakeref;
+   u32 pica_isr;
+   u32 pch_isr;
+   u32 mask = 0;
+
+   with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref) {
+   pica_isr = intel_de_read(i915, PICAINTERRUPT_ISR);
+   pch_isr = intel_de_read(i915, SDEISR);
+   }
+
+   if (pica_isr & (pica_isr_bits & XELPDP_DP_ALT_HOTPLUG_MASK))
+   mask |= BIT(TC_PORT_DP_ALT);
+   if (pica_isr & (pica_isr_bits & XELPDP_TBT_HOTPLUG_MASK))
+   mask |= BIT(TC_PORT_TBT_ALT);
+
+   if (tc->legacy_port && (pch_isr & pch_isr_bit))
+   mask |= BIT(TC_PORT_LEGACY);
+
+   return mask;
+}
+
 static bool
 xelpdp_tc_phy_tcss_power_is_enabled(struct intel_tc_port *tc)
 {
@@ -1039,7 +1067,7 @@ static void xelpdp_tc_phy_disconnect(struct intel_tc_port 
*tc)
 
 static const struct intel_tc_phy_ops xelpdp_tc_phy_ops = {
.cold_off_domain = tgl_tc_phy_cold_off_domain,
-   .hpd_live_status = adlp_tc_phy_hpd_live_status,
+   .hpd_live_status = xelpdp_tc_phy_hpd_live_status,
.is_ready = adlp_tc_phy_is_ready,
.is_owned = xelpdp_tc_phy_is_owned,
.get_hw_state = xelpdp_tc_phy_get_hw_state,
-- 
2.34.1

[Intel-gfx] [PATCH 03/13] drm/i915/mtl: Dump C20 pll hw state

[Mika Kahola]

As we already do with C10 chip, let's dump the pll
hw state for C20 as well.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 20 
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |  2 ++
 drivers/gpu/drm/i915/display/intel_ddi.c |  1 +
 3 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 61428c5145e5..144474540ef4 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2035,6 +2035,26 @@ void intel_c20pll_readout_hw_state(struct intel_encoder 
*encoder,
}
 }
 
+void intel_c20pll_dump_hw_state(struct drm_i915_private *i915,
+   const struct intel_c20pll_state *hw_state)
+{
+   int i;
+
+   drm_dbg_kms(>drm, "c20pll_hw_state:\n");
+   drm_dbg_kms(>drm, "tx[0] = 0x%.4x, tx[1] = 0x%.4x, tx[2] = 
0x%.4x\n",
+   hw_state->tx[0], hw_state->tx[1], hw_state->tx[2]);
+   drm_dbg_kms(>drm, "cmn[0] = 0x%.4x, cmn[1] = 0x%.4x, cmn[2] = 
0x%.4x, cmn[3] = 0x%.4x\n",
+   hw_state->cmn[0], hw_state->cmn[1], hw_state->cmn[2], 
hw_state->cmn[3]);
+
+   if (intel_c20_use_mplla(hw_state->clock)) {
+   for (i = 0; i < ARRAY_SIZE(hw_state->mplla); i++)
+   drm_dbg_kms(>drm, "mplla[%d] = 0x%.4x\n", i, 
hw_state->mplla[i]);
+   } else {
+   for (i = 0; i < ARRAY_SIZE(hw_state->mpllb); i++)
+   drm_dbg_kms(>drm, "mpllb[%d] = 0x%.4x\n", i, 
hw_state->mpllb[i]);
+   }
+}
+
 static u8 intel_c20_get_dp_rate(u32 clock)
 {
switch (clock) {
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index 9760c6292c81..c643aae27bac 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -32,6 +32,8 @@ void intel_c10pll_state_verify(struct intel_atomic_state 
*state,
   struct intel_crtc_state *new_crtc_state);
 void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
   struct intel_c20pll_state *pll_state);
+void intel_c20pll_dump_hw_state(struct drm_i915_private *i915,
+   const struct intel_c20pll_state *hw_state);
 void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
 const struct intel_crtc_state *crtc_state);
 int intel_cx0_phy_check_hdmi_link_rate(struct intel_hdmi *hdmi, int clock);
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 44f07011245b..d414dd8c26bf 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3858,6 +3858,7 @@ static void mtl_ddi_get_config(struct intel_encoder 
*encoder,
intel_c10pll_dump_hw_state(i915, _state->cx0pll_state.c10);
} else {
intel_c20pll_readout_hw_state(encoder, 
_state->cx0pll_state.c20);
+   intel_c20pll_dump_hw_state(i915, _state->cx0pll_state.c20);
}
 
crtc_state->port_clock = intel_c10pll_calc_port_clock(encoder, 
_state->cx0pll_state.c10);
-- 
2.34.1

[Intel-gfx] [PATCH 08/13] drm/i915/mtl: Readout Thunderbolt HW state

[Mika Kahola]

Readout hw state for Thunderbolt.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 27 
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |  2 +-
 drivers/gpu/drm/i915/display/intel_ddi.c |  5 +++-
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 9722d3f1b926..dc005e61 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2676,6 +2676,33 @@ static void intel_cx0pll_enable(struct intel_encoder 
*encoder,
intel_cx0_phy_transaction_end(encoder, wakeref);
 }
 
+int intel_mtl_tbt_calc_port_clock(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   u32 clock;
+   u32 val = intel_de_read(i915, XELPDP_PORT_CLOCK_CTL(encoder->port));
+
+   clock = REG_FIELD_GET(XELPDP_DDI_CLOCK_SELECT_MASK, val);
+
+   drm_WARN_ON(>drm, !(val & XELPDP_FORWARD_CLOCK_UNGATE));
+   drm_WARN_ON(>drm, !(val & XELPDP_TBT_CLOCK_REQUEST));
+   drm_WARN_ON(>drm, !(val & XELPDP_TBT_CLOCK_ACK));
+
+   switch (clock) {
+   case XELPDP_DDI_CLOCK_SELECT_TBT_162:
+   return 162000;
+   case XELPDP_DDI_CLOCK_SELECT_TBT_270:
+   return 27;
+   case XELPDP_DDI_CLOCK_SELECT_TBT_540:
+   return 54;
+   case XELPDP_DDI_CLOCK_SELECT_TBT_810:
+   return 81;
+   default:
+   MISSING_CASE(clock);
+   return 162000;
+   }
+}
+
 static int intel_mtl_tbt_clock_select(struct drm_i915_private *i915, int clock)
 {
switch (clock) {
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index 9ea6310b6d79..c1b8f7980f69 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -42,5 +42,5 @@ int intel_cx0_phy_check_hdmi_link_rate(struct intel_hdmi 
*hdmi, int clock);
 void intel_cx0_phy_ddi_vswing_sequence(struct intel_encoder *encoder,
   const struct intel_crtc_state 
*crtc_state,
   u32 level);
-int intel_mtl_tbt_readout_hw_state(struct intel_encoder *encoder);
+int intel_mtl_tbt_calc_port_clock(struct intel_encoder *encoder);
 #endif /* __INTEL_CX0_PHY_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c18226edacac..8f0f858cde31 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3852,8 +3852,11 @@ static void mtl_ddi_get_config(struct intel_encoder 
*encoder,
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(i915, encoder->port);
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
 
-   if (intel_is_c10phy(i915, phy)) {
+   if (intel_tc_port_in_tbt_alt_mode(dig_port)) {
+   crtc_state->port_clock = intel_mtl_tbt_calc_port_clock(encoder);
+   } else if (intel_is_c10phy(i915, phy)) {
intel_c10pll_readout_hw_state(encoder, 
_state->cx0pll_state.c10);
intel_c10pll_dump_hw_state(i915, _state->cx0pll_state.c10);
crtc_state->port_clock = intel_c10pll_calc_port_clock(encoder, 
_state->cx0pll_state.c10);
-- 
2.34.1

[Intel-gfx] [PATCH 04/13] drm/i915/mtl: C20 port clock calculation

[Mika Kahola]

Calculate port clock with C20 phy.

BSpec: 64568
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 45 +++
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |  2 +
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |  4 ++
 drivers/gpu/drm/i915/display/intel_ddi.c  |  4 +-
 drivers/gpu/drm/i915/display/intel_dpll.c |  2 +
 5 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 144474540ef4..f7720acaf58c 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2274,6 +2274,51 @@ int intel_c10pll_calc_port_clock(struct intel_encoder 
*encoder,
return tmpclk;
 }
 
+int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
+const struct intel_c20pll_state *pll_state)
+{
+   unsigned int frac, frac_en, frac_quot, frac_rem, frac_den;
+   unsigned int multiplier, refclk = 38400;
+   unsigned int tx_clk_div;
+   unsigned int ref_clk_mpllb_div;
+   unsigned int fb_clk_div4_en;
+   unsigned int ref, vco;
+   unsigned int tx_rate_mult;
+   unsigned int tx_rate = REG_FIELD_GET(C20_PHY_TX_RATE, pll_state->tx[0]);
+
+   if (pll_state->tx[0] & C20_PHY_USE_MPLLB) {
+   tx_rate_mult = 1;
+   frac_en = REG_FIELD_GET(C20_MPLLB_FRACEN, pll_state->mpllb[6]);
+   frac_quot = pll_state->mpllb[8];
+   frac_rem =  pll_state->mpllb[9];
+   frac_den =  pll_state->mpllb[7];
+   multiplier = REG_FIELD_GET(C20_MULTIPLIER_MASK, 
pll_state->mpllb[0]);
+   tx_clk_div = REG_FIELD_GET(C20_MPLLB_TX_CLK_DIV_MASK, 
pll_state->mpllb[0]);
+   ref_clk_mpllb_div = REG_FIELD_GET(C20_REF_CLK_MPLLB_DIV_MASK, 
pll_state->mpllb[6]);
+   fb_clk_div4_en = 0;
+   } else {
+   tx_rate_mult = 2;
+   frac_en = REG_FIELD_GET(C20_MPLLA_FRACEN, pll_state->mplla[6]);
+   frac_quot = pll_state->mplla[8];
+   frac_rem =  pll_state->mplla[9];
+   frac_den =  pll_state->mplla[7];
+   multiplier = REG_FIELD_GET(C20_MULTIPLIER_MASK, 
pll_state->mplla[0]);
+   tx_clk_div = REG_FIELD_GET(C20_MPLLA_TX_CLK_DIV_MASK, 
pll_state->mplla[1]);
+   ref_clk_mpllb_div = REG_FIELD_GET(C20_REF_CLK_MPLLB_DIV_MASK, 
pll_state->mplla[6]);
+   fb_clk_div4_en = REG_FIELD_GET(C20_FB_CLK_DIV4_EN, 
pll_state->mplla[0]);
+   }
+
+   if (frac_en)
+   frac = frac_quot + DIV_ROUND_CLOSEST(frac_rem, frac_den);
+   else
+   frac = 0;
+
+   ref = DIV_ROUND_CLOSEST(refclk * (1 << (1 + fb_clk_div4_en)), 1 << 
ref_clk_mpllb_div);
+   vco = DIV_ROUND_CLOSEST_ULL(mul_u32_u32(ref, (multiplier << (17 - 2)) + 
frac) >> 17, 10);
+
+   return vco << tx_rate_mult >> tx_clk_div >> tx_rate;
+}
+
 static void intel_program_port_clock_ctl(struct intel_encoder *encoder,
 const struct intel_crtc_state 
*crtc_state,
 bool lane_reversal)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index c643aae27bac..83bd3500091b 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -34,6 +34,8 @@ void intel_c20pll_readout_hw_state(struct intel_encoder 
*encoder,
   struct intel_c20pll_state *pll_state);
 void intel_c20pll_dump_hw_state(struct drm_i915_private *i915,
const struct intel_c20pll_state *hw_state);
+int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
+const struct intel_c20pll_state *pll_state);
 void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
 const struct intel_crtc_state *crtc_state);
 int intel_cx0_phy_check_hdmi_link_rate(struct intel_hdmi *hdmi, int clock);
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
index 6fcb1680fb54..a5e5bee24533 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
@@ -195,17 +195,21 @@
 #define PHY_C20_VDR_CUSTOM_WIDTH   0xD02
 #define PHY_C20_A_TX_CNTX_CFG(idx) (0xCF2E - (idx))
 #define PHY_C20_B_TX_CNTX_CFG(idx) (0xCF2A - (idx))
+#define   C20_PHY_TX_RATE  REG_GENMASK(2, 0)
 #define PHY_C20_A_CMN_CNTX_CFG(idx)(0xCDAA - (idx))
 #define PHY_C20_B_CMN_CNTX_CFG(idx)(0xCDA5 - (idx))
 #define PHY_C20_A_MPLLA_CNTX_CFG(idx)  (0xCCF0 - (idx))
 #define PHY_C20_B_MPLLA_CNTX_CFG(idx)  (0xCCE5 - (idx))
 #define   C20_MPLLA_FRACEN REG_BIT(14)
+#define   C20_FB_CLK_DIV4_EN   REG_BIT(13)
 #define   

[Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout

[Mika Kahola]

Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
The PLL settings are based on table, not for algorithmic alternative.
For DP 1.4 only MPLLB is in use.

Once register settings are done, we read back C20 HW state.

BSpec: 64568

Signed-off-by: Mika Kahola 
Signed-off-by: Arun R Murthy 
Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 623 +-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   8 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  |   9 +-
 .../drm/i915/display/intel_display_types.h|   1 +
 drivers/gpu/drm/i915/display/intel_hdmi.c |   6 +-
 drivers/gpu/drm/i915/display/intel_hdmi.h |   1 +
 6 files changed, 628 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index dd96bf5e179e..61428c5145e5 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -11,6 +11,7 @@
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_dp.h"
+#include "intel_hdmi.h"
 #include "intel_panel.h"
 #include "intel_psr.h"
 #include "intel_tc.h"
@@ -285,6 +286,23 @@ static void intel_c20_sram_write(struct drm_i915_private 
*i915, enum port port,
intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
 }
 
+static u16 intel_c20_sram_read(struct drm_i915_private *i915, enum port port,
+  int lane, u16 addr)
+{
+   u16 val;
+
+   assert_dc_off(i915);
+
+   intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, addr >> 8, 0);
+   intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr & 0xff, 1);
+
+   val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
+   val <<= 8;
+   val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
+
+   return val;
+}
+
 static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
int lane, u16 addr, u8 clear, u8 set, bool 
committed)
 {
@@ -659,6 +677,199 @@ static const struct intel_c10pll_state * const 
mtl_c10_edp_tables[] = {
NULL,
 };
 
+/* C20 basic DP 1.4 tables */
+static const struct intel_c20pll_state mtl_c20_dp_rbr = {
+   .link_bit_rate = 162000,
+   .clock = 162000,
+   .tx = { 0xbe88, /* tx cfg0 */
+   0x5800, /* tx cfg1 */
+   0x, /* tx cfg2 */
+   },
+   .cmn = {0x0500, /* cmn cfg0*/
+   0x0005, /* cmn cfg1 */
+   0x, /* cmn cfg2 */
+   0x, /* cmn cfg3 */
+   },
+   .mpllb = { 0x50a8,  /* mpllb cfg0 */
+   0x2120, /* mpllb cfg1 */
+   0xcd9a, /* mpllb cfg2 */
+   0xbfc1, /* mpllb cfg3 */
+   0x5ab8, /* mpllb cfg4 */
+   0x4c34, /* mpllb cfg5 */
+   0x2000, /* mpllb cfg6 */
+   0x0001, /* mpllb cfg7 */
+   0x6000, /* mpllb cfg8 */
+   0x, /* mpllb cfg9 */
+   0x, /* mpllb cfg10 */
+   },
+};
+
+static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
+   .link_bit_rate = 27,
+   .clock = 27,
+   .tx = { 0xbe88, /* tx cfg0 */
+   0x4800, /* tx cfg1 */
+   0x, /* tx cfg2 */
+   },
+   .cmn = {0x0500, /* cmn cfg0*/
+   0x0005, /* cmn cfg1 */
+   0x, /* cmn cfg2 */
+   0x, /* cmn cfg3 */
+   },
+   .mpllb = { 0x308c,  /* mpllb cfg0 */
+   0x2110, /* mpllb cfg1 */
+   0xcc9c, /* mpllb cfg2 */
+   0xbfc1, /* mpllb cfg3 */
+   0x489a, /* mpllb cfg4 */
+   0x3f81, /* mpllb cfg5 */
+   0x2000, /* mpllb cfg6 */
+   0x0001, /* mpllb cfg7 */
+   0x5000, /* mpllb cfg8 */
+   0x, /* mpllb cfg9 */
+   0x, /* mpllb cfg10 */
+   },
+};
+
+static const struct intel_c20pll_state mtl_c20_dp_hbr2 = {
+   .link_bit_rate = 54,
+   .clock = 54,
+   .tx = { 0xbe88, /* tx cfg0 */
+   0x4800, /* tx cfg1 */
+   0x, /* tx cfg2 */
+   },
+   .cmn = {0x0500, /* cmn cfg0*/
+   0x0005, /* cmn cfg1 */
+   0x, /* cmn cfg2 */
+   0x, /* cmn cfg3 */
+   },
+   .mpllb = { 0x108c,  /* mpllb cfg0 */
+   0x2108, /* mpllb cfg1 */
+   0xcc9c, /* mpllb cfg2 */
+   0xbfc1, /* mpllb cfg3 */
+   0x489a, /* mpllb cfg4 */
+   0x3f81, /* mpllb cfg5 */
+   0x2000, /* mpllb cfg6 */
+   0x0001, /* mpllb cfg7 */
+

[Intel-gfx] [PATCH 01/13] drm/i915/mtl: C20 PLL programming

[Mika Kahola]

C20 phy PLL programming sequence for DP, DP2.0, HDMI2.x non-FRL and
HDMI2.x FRL. This enables C20 MPLLA and MPLLB programming sequence. add
4 lane support for c20.

Signed-off-by: José Roberto de Souza 
Signed-off-by: Mika Kahola 
Signed-off-by: Bhanuprakash Modem 
Signed-off-by: Imre Deak 
Signed-off-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 280 +++---
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |  32 ++
 drivers/gpu/drm/i915/display/intel_ddi.c  |   3 +-
 .../drm/i915/display/intel_display_types.h|  15 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  12 +-
 5 files changed, 300 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 83180074b512..dd96bf5e179e 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -273,6 +273,18 @@ static void intel_cx0_write(struct drm_i915_private *i915, 
enum port port,
__intel_cx0_write(i915, port, lane, addr, data, committed);
 }
 
+static void intel_c20_sram_write(struct drm_i915_private *i915, enum port port,
+int lane, u16 addr, u16 data)
+{
+   assert_dc_off(i915);
+
+   intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_H, addr >> 8, 0);
+   intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_L, addr & 0xff, 0);
+
+   intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_H, data >> 8, 0);
+   intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
+}
+
 static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
int lane, u16 addr, u8 clear, u8 set, bool 
committed)
 {
@@ -1415,6 +1427,207 @@ void intel_c10pll_dump_hw_state(struct drm_i915_private 
*i915,
i + 2, hw_state->pll[i + 2], i + 3, hw_state->pll[i 
+ 3]);
 }
 
+static bool intel_c20_use_mplla(u32 clock)
+{
+   /* 10G and 20G rates use MPLLA */
+   if (clock == 312500 || clock == 625000)
+   return true;
+
+   return false;
+}
+
+static u8 intel_c20_get_dp_rate(u32 clock)
+{
+   switch (clock) {
+   case 162000: /* 1.62 Gbps DP1.4 */
+   return 0;
+   case 27: /* 2.7 Gbps DP1.4 */
+   return 1;
+   case 54: /* 5.4 Gbps DP 1.4 */
+   return 2;
+   case 81: /* 8.1 Gbps DP1.4 */
+   return 3;
+   case 216000: /* 2.16 Gbps eDP */
+   return 4;
+   case 243000: /* 2.43 Gbps eDP */
+   return 5;
+   case 324000: /* 3.24 Gbps eDP */
+   return 6;
+   case 432000: /* 4.32 Gbps eDP */
+   return 7;
+   case 312500: /* 10 Gbps DP2.0 */
+   return 8;
+   case 421875: /* 13.5 Gbps DP2.0 */
+   return 9;
+   case 625000: /* 20 Gbps DP2.0*/
+   return 10;
+   default:
+   MISSING_CASE(clock);
+   return 0;
+   }
+}
+
+static u8 intel_c20_get_hdmi_rate(u32 clock)
+{
+   switch (clock) {
+   case 25175:
+   case 27000:
+   case 74250:
+   case 148500:
+   case 594000:
+   return 0;
+   case 166670: /* 3 Gbps */
+   case 30: /* 6 Gbps */
+   case 70: /* 12 Gbps */
+   return 1;
+   case 40: /* 8 Gbps */
+   return 2;
+   case 60: /* 10 Gbps */
+   return 3;
+   default:
+   MISSING_CASE(clock);
+   return 0;
+   }
+}
+
+static bool is_dp2(u32 clock)
+{
+   /* DP2.0 clock rates */
+   if (clock == 312500 || clock == 421875 || clock  == 625000)
+   return true;
+
+   return false;
+}
+
+static bool is_hdmi_frl(u32 clock)
+{
+   switch (clock) {
+   case 166670: /* 3 Gbps */
+   case 30: /* 6 Gbps */
+   case 40: /* 8 Gbps */
+   case 60: /* 10 Gbps */
+   case 70: /* 12 Gbps */
+   return true;
+   default:
+   return false;
+   }
+}
+
+static bool intel_c20_protocol_switch_valid(struct intel_encoder *encoder)
+{
+   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+
+   /* banks should not be cleared for DPALT/USB4/TBT modes */
+   /* TODO: optimize re-calibration in legacy mode */
+   return intel_tc_port_in_legacy_mode(intel_dig_port);
+}
+
+static void intel_c20_pll_program(struct drm_i915_private *i915,
+ const struct intel_crtc_state *crtc_state,
+ struct intel_encoder *encoder)
+{
+   const struct intel_c20pll_state *pll_state = 
_state->cx0pll_state.c20;
+   bool dp = false;
+   int lane = crtc_state->lane_count == 4 ? INTEL_CX0_BOTH_LANES : 
INTEL_CX0_LANE0;
+   bool cntx;
+   int i;
+
+   if (intel_crtc_has_dp_encoder(crtc_state))
+   dp = true;
+
+   

[Intel-gfx] [PATCH 00/13] drm/i915/mtl: Add support for C20 phy

[Mika Kahola]

Add support for C20 phy for Type-C connections. C20 phy differs from
C10 and hence we need to separately handle this case.

Signed-off-by: Mika Kahola 

Anusha Srivatsa (1):
  drm/i915/mtl: Pin assignment for TypeC

Gustavo Sousa (1):
  drm/i915/mtl: Define mask for DDI AUX interrupts

Imre Deak (1):
  drm/i915/mtl: TypeC HPD live status query

Mika Kahola (10):
  drm/i915/mtl: C20 PLL programming
  drm/i915/mtl: C20 HW readout
  drm/i915/mtl: Dump C20 pll hw state
  drm/i915/mtl: C20 port clock calculation
  drm/i915/mtl: Add voltage swing sequence for C20
  drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA
  drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll
  drm/i915/mtl: Readout Thunderbolt HW state
  drm/i915/mtl: Power up TCSS
  drm/i915/mtl: Enable TC ports

 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 1128 -
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   23 +-
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |   40 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |   25 +-
 .../drm/i915/display/intel_ddi_buf_trans.c|   53 +-
 drivers/gpu/drm/i915/display/intel_display.c  |7 +-
 .../drm/i915/display/intel_display_types.h|   16 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |   12 +-
 drivers/gpu/drm/i915/display/intel_dpll.c |2 +
 drivers/gpu/drm/i915/display/intel_hdmi.c |6 +-
 drivers/gpu/drm/i915/display/intel_hdmi.h |1 +
 drivers/gpu/drm/i915/display/intel_tc.c   |  255 +++-
 drivers/gpu/drm/i915/i915_irq.c   |5 +-
 13 files changed, 1500 insertions(+), 73 deletions(-)

-- 
2.34.1

Re: [Intel-gfx] [PATCH 7/8] drm/i915: use pat_index instead of cache_level

[Tvrtko Ursulin]

On 20/04/2023 11:13, Andrzej Hajda wrote:

On 20.04.2023 01:00, fei.y...@intel.com wrote:

From: Fei Yang 

Currently the KMD is using enum i915_cache_level to set caching policy 
for

buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in 
the
enum. In addition, the PAT index is platform dependent, having to 
translate
between i915_cache_level and PAT index is not reliable, and makes the 
code

more complicated.


How it is flaky and not reliable - yet the series proposed to leave it in place 
and even claims using cache levels simplifies the code (lower in the commit 
message). Maybe just the commit message needs work.

 From UMD's perspective there is also a necessity to set caching 
policy for

performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only 
cause

more ambiguity.

For these reasons this patch replaces i915_cache_level with PAT index. 
Also
note, the cache_level is not completely removed yet, because the KMD 
still
has the need of creating buffer objects with simple cache settings 
such as
cached, uncached, or writethrough. For such simple cases, using 
cache_level

would help simplify the code.


It seems quite fundamental change to me. Does this "not completely 
removed yet" means that in some future we will not have support for 
generic cache levels at all? Seems strange to me. Even looking at the 
number of users of i915_gem_get_pat_index below it seem very unlikely.


And if the support for generic level will stay, maybe it would be better 
to make usage of it more convienient. All conversion of

 f(..., cache_level, ...)
to
 f(..., i915_gem_get_pat_index(i915, cache_level), ...)
looks quite ugly to me.

Maybe extending cache level to support pat index somehow, for example:
enum i915_cache_level {
 I915_CACHE_NONE = 0,
 I915_CACHE_...,
 ...
 I915_CACHE_1ST_PAT_INDEX = 0x100,
}

so real_pat_index = cache_level - I915_CACHE_1ST_PAT_INDEX

and in case of generic level there will be platform dependend conversion 
to real_pat_index?


I do not know the whole picture so maybe this is all wrong for some 
reason, just asking :)


It looks a bit unsightly to me too so yes please, brain storm on whether it can 
be made more elegant and less intrusive would be appreciated.


Cc: Chris Wilson 
Cc: Matt Roper 
Signed-off-by: Fei Yang 
Reviewed-by: Andi Shyti 
---
  drivers/gpu/drm/i915/display/intel_dpt.c  | 12 +--
  drivers/gpu/drm/i915/gem/i915_gem_domain.c    | 27 ++
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c    | 10 ++-
  drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  3 +-
  drivers/gpu/drm/i915/gem/i915_gem_object.c    | 52 +++-
  drivers/gpu/drm/i915/gem/i915_gem_object.h    |  4 +
  .../gpu/drm/i915/gem/i915_gem_object_types.h  | 25 +-
  drivers/gpu/drm/i915/gem/i915_gem_stolen.c    |  4 +-
  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  | 16 ++--
  .../gpu/drm/i915/gem/selftests/huge_pages.c   |  2 +-
  .../drm/i915/gem/selftests/i915_gem_migrate.c |  2 +-
  .../drm/i915/gem/selftests/i915_gem_mman.c    |  2 +-
  drivers/gpu/drm/i915/gt/gen6_ppgtt.c  | 10 ++-
  drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 71 
  drivers/gpu/drm/i915/gt/gen8_ppgtt.h  |  3 +-
  drivers/gpu/drm/i915/gt/intel_ggtt.c  | 82 +--
  drivers/gpu/drm/i915/gt/intel_gtt.h   | 20 ++---
  drivers/gpu/drm/i915/gt/intel_migrate.c   | 47 ++-
  drivers/gpu/drm/i915/gt/intel_migrate.h   | 13 ++-
  drivers/gpu/drm/i915/gt/intel_ppgtt.c |  6 +-
  drivers/gpu/drm/i915/gt/selftest_migrate.c    | 47 ++-
  drivers/gpu/drm/i915/gt/selftest_reset.c  |  8 +-
  drivers/gpu/drm/i915/gt/selftest_timeline.c   |  2 +-
  drivers/gpu/drm/i915/gt/selftest_tlb.c    |  4 +-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 10 ++-
  drivers/gpu/drm/i915/i915_debugfs.c   | 55 ++---
  drivers/gpu/drm/i915/i915_gem.c   | 16 +++-
  drivers/gpu/drm/i915/i915_gpu_error.c |  8 +-
  drivers/gpu/drm/i915/i915_vma.c   | 16 ++--
  drivers/gpu/drm/i915/i915_vma.h   |  2 +-
  drivers/gpu/drm/i915/i915_vma_types.h |  2 -
  drivers/gpu/drm/i915/selftests/i915_gem.c |  5 +-
  .../gpu/drm/i915/selftests/i915_gem_evict.c   |  4 +-
  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++--
  .../drm/i915/selftests/intel_memory_region.c  |  4 +-
  drivers/gpu/drm/i915/selftests/mock_gtt.c |  8 +-
  36 files changed, 378 insertions(+), 239 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c

index c5eacfdba1a5..7c5fddb203ba 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -43,24 

Re: [Intel-gfx] [PATCH 1/2] drm/dsc: fix drm_edp_dsc_sink_output_bpp() DPCD high byte usage

[Nautiyal, Ankit K]

LGTM.

Reviewed-by: Ankit Nautiyal 

On 4/6/2023 7:16 PM, Jani Nikula wrote:

The operator precedence between << and & is wrong, leading to the high
byte being completely ignored. For example, with the 6.4 format, 32
becomes 0 and 24 becomes 8. Fix it, and remove the slightly confusing
and unnecessary DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT macro while at it.

Fixes: 0575650077ea ("drm/dp: DRM DP helper/macros to get DP sink DSC 
parameters")
Cc: Stanislav Lisovskiy 
Cc: Manasi Navare 
Cc: Anusha Srivatsa 
Cc:  # v5.0+
Signed-off-by: Jani Nikula 
---
  include/drm/display/drm_dp.h| 1 -
  include/drm/display/drm_dp_helper.h | 5 ++---
  2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 358db4a9f167..89d5a700b04d 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -286,7 +286,6 @@
  
  #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */

  # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK  (0x3 << 0)
-# define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8
  # define DP_DSC_MAX_BPP_DELTA_VERSION_MASK  0x06
  # define DP_DSC_MAX_BPP_DELTA_AVAILABILITY  0x08
  
diff --git a/include/drm/display/drm_dp_helper.h b/include/drm/display/drm_dp_helper.h

index 533d3ee7fe05..86f24a759268 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -181,9 +181,8 @@ static inline u16
  drm_edp_dsc_sink_output_bpp(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
  {
return dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW - DP_DSC_SUPPORT] |
-   (dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - DP_DSC_SUPPORT] &
-DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK <<
-DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
+   ((dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI - DP_DSC_SUPPORT] &
+ DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK) << 8);
  }
  
  static inline u32