[Intel-gfx] [PATCH v12 6/6] drm/i915/mtl: Add HDCP GSC interface

[Suraj Kandpal]

MTL uses GSC command streamer i.e gsc cs to send HDCP/PXP commands
to GSC f/w. It requires to keep hdcp display driver
agnostic to content protection f/w (ME/GSC fw) in the form of
i915_hdcp_fw_ops generic ops.

Adding HDCP GSC CS interface by leveraging the i915_hdcp_fw_ops generic
ops instead of I915_HDCP_COMPONENT as integral part of i915.

Adding checks to see if GSC is loaded and proxy is setup

--v6
-dont change the license date in same patch series [Jani]
-fix the license year {Jani]

--v8
-remove stale comment [Ankit]
-get headers in alphabetical order [Ankit]
-fix hdcp2_supported check [Ankit]

--v9
-remove return statement from hdcp_gsc_fini [Ankit]

Cc: Tomas Winkler 
Cc: Rodrigo Vivi 
Cc: Uma Shankar 
Cc: Ankit Nautiyal 
Signed-off-by: Anshuman Gupta 
Signed-off-by: Suraj Kandpal 
Reviewed-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c |  28 +-
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 637 +-
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |   3 +
 3 files changed, 660 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 3b9bdc4a764d..650232c4892b 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -23,6 +23,7 @@
 #include "intel_display_power_well.h"
 #include "intel_display_types.h"
 #include "intel_hdcp.h"
+#include "intel_hdcp_gsc.h"
 #include "intel_hdcp_regs.h"
 #include "intel_pcode.h"
 
@@ -203,13 +204,20 @@ bool intel_hdcp2_capable(struct intel_connector 
*connector)
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
+   struct intel_gt *gt = dev_priv->media_gt;
+   struct intel_gsc_uc *gsc = >uc.gsc;
bool capable = false;
 
/* I915 support for HDCP2.2 */
if (!hdcp->hdcp2_supported)
return false;
 
-   /* MEI interface is solid */
+   /* If MTL+ make sure gsc is loaded and proxy is setup */
+   if (intel_hdcp_gsc_cs_required(dev_priv))
+   if (!intel_uc_fw_is_running(>fw))
+   return false;
+
+   /* MEI/GSC interface is solid depending on which is used */
mutex_lock(_priv->display.hdcp.comp_mutex);
if (!dev_priv->display.hdcp.comp_added ||  
!dev_priv->display.hdcp.master) {
mutex_unlock(_priv->display.hdcp.comp_mutex);
@@ -2233,6 +2241,9 @@ static int initialize_hdcp_port_data(struct 
intel_connector *connector,
 
 static bool is_hdcp2_supported(struct drm_i915_private *dev_priv)
 {
+   if (intel_hdcp_gsc_cs_required(dev_priv))
+   return true;
+
if (!IS_ENABLED(CONFIG_INTEL_MEI_HDCP))
return false;
 
@@ -2254,10 +2265,14 @@ void intel_hdcp_component_init(struct drm_i915_private 
*dev_priv)
 
dev_priv->display.hdcp.comp_added = true;
mutex_unlock(_priv->display.hdcp.comp_mutex);
-   ret = component_add_typed(dev_priv->drm.dev, _hdcp_ops,
- I915_COMPONENT_HDCP);
+   if (intel_hdcp_gsc_cs_required(dev_priv))
+   ret = intel_hdcp_gsc_init(dev_priv);
+   else
+   ret = component_add_typed(dev_priv->drm.dev, _hdcp_ops,
+ I915_COMPONENT_HDCP);
+
if (ret < 0) {
-   drm_dbg_kms(_priv->drm, "Failed at component add(%d)\n",
+   drm_dbg_kms(_priv->drm, "Failed at fw component add(%d)\n",
ret);
mutex_lock(_priv->display.hdcp.comp_mutex);
dev_priv->display.hdcp.comp_added = false;
@@ -2484,7 +2499,10 @@ void intel_hdcp_component_fini(struct drm_i915_private 
*dev_priv)
dev_priv->display.hdcp.comp_added = false;
mutex_unlock(_priv->display.hdcp.comp_mutex);
 
-   component_del(dev_priv->drm.dev, _hdcp_ops);
+   if (intel_hdcp_gsc_cs_required(dev_priv))
+   intel_hdcp_gsc_fini(dev_priv);
+   else
+   component_del(dev_priv->drm.dev, _hdcp_ops);
 }
 
 void intel_hdcp_cleanup(struct intel_connector *connector)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
index 4234fabd62ad..7e52aea6aa17 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -3,12 +3,617 @@
  * Copyright 2023, Intel Corporation.
  */
 
+#include 
+
 #include "display/intel_hdcp_gsc.h"
 #include "gem/i915_gem_region.h"
 #include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
 #include "i915_drv.h"
 #include "i915_utils.h"
 
+bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915)
+{
+   return DISPLAY_VER(i915) >= 14;
+}
+
+static int
+gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
+ 

[Intel-gfx] [PATCH v12 5/6] drm/i915/mtl: Add function to send command to GSC CS

[Suraj Kandpal]

Add function that takes care of sending command to gsc cs. We start
of with allocation of memory for our command intel_hdcp_gsc_message that
contains gsc cs memory header as directed in specs followed by the
actual payload hdcp message that we want to send.
Spec states that we need to poll pending bit of response header around
20 times each try being 50ms apart hence adding that to current
gsc_msg_send function
Also we use the same function to take care of both sending and receiving
hence no separate function to get the response.

--v4
-Create common function to fill in gsc_mtl_header [Alan]
-define host session bitmask [Alan]

--v5
-use i915 directly instead of gt->i915 [Alan]
-No need to make fields NULL as we are already
using kzalloc [Alan]

--v8
-change mechanism to reuse the same memory for one hdcp session[Alan]
-fix header ordering
-add comments to explain flags and host session mask [Alan]

--v9
-remove gem obj from hdcp message as we can use
i915_vma_unpin_and_release [Alan]
-move hdcp message allocation and deallocation from hdcp2_enable and
hdcp2_disable to init and teardown of HDCP [Alan]

--v10
-remove unnecessary i915_vma_unpin [Alan]

--v11
-fix comment style [Uma]

Cc: Ankit Nautiyal 
Cc: Daniele Ceraolo Spurio 
Cc: Alan Pervin Teres 
Cc: Uma Shankar 
Cc: Anshuman Gupta 
Signed-off-by: Suraj Kandpal 
Reviewed-by: Alan Previn 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/display/intel_display_core.h |   6 +
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 200 ++
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |  23 ++
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c |  15 ++
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |  16 ++
 6 files changed, 261 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8c6b3808c49f..53318809f4a1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -256,6 +256,7 @@ i915-y += \
display/intel_frontbuffer.o \
display/intel_global_state.o \
display/intel_hdcp.o \
+   display/intel_hdcp_gsc.o \
display/intel_hotplug.o \
display/intel_hti.o \
display/intel_lpe_audio.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index d7cb649be915..cc5c9382c24e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -387,6 +387,12 @@ struct intel_display {
struct i915_hdcp_master *master;
bool comp_added;
 
+   /*
+* HDCP message struct for allocation of memory which can be
+* reused when sending message to gsc cs.
+* this is only populated post Meteorlake
+*/
+   struct intel_hdcp_gsc_message *hdcp_message;
/* Mutex to protect the above hdcp component related values. */
struct mutex comp_mutex;
} hdcp;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
new file mode 100644
index ..4234fabd62ad
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright 2023, Intel Corporation.
+ */
+
+#include "display/intel_hdcp_gsc.h"
+#include "gem/i915_gem_region.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
+#include "i915_drv.h"
+#include "i915_utils.h"
+
+/*This function helps allocate memory for the command that we will send to gsc 
cs */
+static int intel_hdcp_gsc_initialize_message(struct drm_i915_private *i915,
+struct intel_hdcp_gsc_message 
*hdcp_message)
+{
+   struct intel_gt *gt = i915->media_gt;
+   struct drm_i915_gem_object *obj = NULL;
+   struct i915_vma *vma = NULL;
+   void *cmd;
+   int err;
+
+   /* allocate object of one page for HDCP command memory and store it */
+   obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
+
+   if (IS_ERR(obj)) {
+   drm_err(>drm, "Failed to allocate HDCP streaming 
command!\n");
+   return PTR_ERR(obj);
+   }
+
+   cmd = i915_gem_object_pin_map_unlocked(obj, 
i915_coherent_map_type(i915, obj, true));
+   if (IS_ERR(cmd)) {
+   drm_err(>drm, "Failed to map gsc message page!\n");
+   err = PTR_ERR(cmd);
+   goto out_unpin;
+   }
+
+   vma = i915_vma_instance(obj, >ggtt->vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto out_unmap;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL);
+   if (err)
+   goto out_unmap;
+
+   memset(cmd, 0, obj->base.size);
+
+   

[Intel-gfx] [PATCH v12 4/6] drm/i915/hdcp: Refactor HDCP API structures

[Suraj Kandpal]

It requires to move intel specific HDCP API structures to
i915_hdcp_interface.h from driver/misc/mei/hdcp/mei_hdcp.h
so that any content protection fw interfaces can use these
structures.

Cc: Tomas Winkler 
Cc: Rodrigo Vivi 
Cc: Uma Shankar 
Cc: Ankit Nautiyal 
Signed-off-by: Anshuman Gupta 
Signed-off-by: Suraj Kandpal 
Reviewed-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c  |  44 ++--
 drivers/misc/mei/hdcp/mei_hdcp.h  | 354 -
 include/drm/i915_hdcp_interface.h | 355 ++
 3 files changed, 377 insertions(+), 376 deletions(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 9e85bf916091..7728fe685476 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -52,7 +52,7 @@ mei_hdcp_initiate_session(struct device *dev, struct 
hdcp_port_data *data,
 
session_init_in.header.api_version = HDCP_API_VERSION;
session_init_in.header.command_id = WIRED_INITIATE_HDCP2_SESSION;
-   session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   session_init_in.header.status = FW_HDCP_STATUS_SUCCESS;
session_init_in.header.buffer_len =
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
 
@@ -75,7 +75,7 @@ mei_hdcp_initiate_session(struct device *dev, struct 
hdcp_port_data *data,
return byte;
}
 
-   if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   if (session_init_out.header.status != FW_HDCP_STATUS_SUCCESS) {
dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
WIRED_INITIATE_HDCP2_SESSION,
session_init_out.header.status);
@@ -122,7 +122,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
 
verify_rxcert_in.header.api_version = HDCP_API_VERSION;
verify_rxcert_in.header.command_id = WIRED_VERIFY_RECEIVER_CERT;
-   verify_rxcert_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_rxcert_in.header.status = FW_HDCP_STATUS_SUCCESS;
verify_rxcert_in.header.buffer_len =
WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
 
@@ -148,7 +148,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
return byte;
}
 
-   if (verify_rxcert_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   if (verify_rxcert_out.header.status != FW_HDCP_STATUS_SUCCESS) {
dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
WIRED_VERIFY_RECEIVER_CERT,
verify_rxcert_out.header.status);
@@ -194,7 +194,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct 
hdcp_port_data *data,
 
send_hprime_in.header.api_version = HDCP_API_VERSION;
send_hprime_in.header.command_id = WIRED_AKE_SEND_HPRIME;
-   send_hprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   send_hprime_in.header.status = FW_HDCP_STATUS_SUCCESS;
send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
 
send_hprime_in.port.integrated_port_type = data->port_type;
@@ -218,7 +218,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct 
hdcp_port_data *data,
return byte;
}
 
-   if (send_hprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   if (send_hprime_out.header.status != FW_HDCP_STATUS_SUCCESS) {
dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
WIRED_AKE_SEND_HPRIME, send_hprime_out.header.status);
return -EIO;
@@ -251,7 +251,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct 
hdcp_port_data *data,
 
pairing_info_in.header.api_version = HDCP_API_VERSION;
pairing_info_in.header.command_id = WIRED_AKE_SEND_PAIRING_INFO;
-   pairing_info_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   pairing_info_in.header.status = FW_HDCP_STATUS_SUCCESS;
pairing_info_in.header.buffer_len =
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
 
@@ -276,7 +276,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct 
hdcp_port_data *data,
return byte;
}
 
-   if (pairing_info_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   if (pairing_info_out.header.status != FW_HDCP_STATUS_SUCCESS) {
dev_dbg(dev, "ME cmd 0x%08X failed. Status: 0x%X\n",
WIRED_AKE_SEND_PAIRING_INFO,
pairing_info_out.header.status);
@@ -311,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
 
lc_init_in.header.api_version = HDCP_API_VERSION;
lc_init_in.header.command_id = WIRED_INIT_LOCALITY_CHECK;
-   lc_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   lc_init_in.header.status = FW_HDCP_STATUS_SUCCESS;
lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
 
  

[Intel-gfx] [PATCH v12 3/6] drm/i915/hdcp: HDCP2.x Refactoring to agnostic hdcp

[Suraj Kandpal]

As now we have more then one type of content protection
secrity firmware.
%s/_mei_/_

--v3
-Changing names to drop cp_fw to make naming more agnostic[Jani]

--v4
-remove header reference in intel_display_core.h [Uma]
-fix commit message and prefix drm [Uma]

Cc: Tomas Winkler 
Cc: Rodrigo Vivi 
Cc: Uma Shankar 
Cc: Ankit Nautiyal 
Signed-off-by: Anshuman Gupta 
Signed-off-by: Suraj Kandpal 
Reviewed-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 1ae0882dc1d4..3b9bdc4a764d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1409,7 +1409,7 @@ static int hdcp2_authenticate_port(struct intel_connector 
*connector)
return ret;
 }
 
-static int hdcp2_close_mei_session(struct intel_connector *connector)
+static int hdcp2_close_session(struct intel_connector *connector)
 {
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1433,7 +1433,7 @@ static int hdcp2_close_mei_session(struct intel_connector 
*connector)
 
 static int hdcp2_deauthenticate_port(struct intel_connector *connector)
 {
-   return hdcp2_close_mei_session(connector);
+   return hdcp2_close_session(connector);
 }
 
 /* Authentication flow starts from here */
-- 
2.25.1

[Intel-gfx] [PATCH v12 2/6] drm/i915/hdcp: Use generic names for HDCP helpers and structs

[Suraj Kandpal]

From: Anshuman Gupta 

pre MTL we interact with mei interface to talk to
firmware and enable CP but going forward we will talk to gsc cs
because of which we are making all names for HDCP helpers and
structures generic as either mei or gsc cs maybe used.

Change the include/drm/i915_mei_hdcp_interface.h to
include/drm/i915_hdcp_interface.h

Change the i915_hdcp_interface.h header naming convention to
suit generic f/w type.
%s/MEI_/HDCP_
%s/mei_dev/hdcp_dev

Change structure name Accordingly.
%s/i915_hdcp_comp_master/i915_hdcp_master
%s/i915_hdcp_component_ops/i915_hdcp_ops

--v6
-make each patch build individually [Jani]

--v8
-change ME FW to ME/GSC FW [Ankit]
-fix formatting issue [Ankit]

--v9
-fix commit message and header [Uma]

--v10
-rename comp variable [Uma]

Cc: Tomas Winkler 
Cc: Rodrigo Vivi 
Cc: Uma Shankar 
Cc: Ankit Nautiyal 
Signed-off-by: Anshuman Gupta 
Signed-off-by: Suraj Kandpal 
Reviewed-by: Ankit Nautiyal 
Acked-by: Tomas Winkler 
---
 .../gpu/drm/i915/display/intel_display_core.h |   2 +-
 .../drm/i915/display/intel_display_types.h|   2 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c | 130 +-
 drivers/misc/mei/hdcp/mei_hdcp.c  |  61 
 ...hdcp_interface.h => i915_hdcp_interface.h} |  94 ++---
 5 files changed, 144 insertions(+), 145 deletions(-)
 rename include/drm/{i915_mei_hdcp_interface.h => i915_hdcp_interface.h} (71%)

diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index fdab7bb93a7d..d7cb649be915 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -384,7 +384,7 @@ struct intel_display {
} gmbus;
 
struct {
-   struct i915_hdcp_comp_master *master;
+   struct i915_hdcp_master *master;
bool comp_added;
 
/* Mutex to protect the above hdcp component related values. */
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c32bfba06ca1..cc98a7ad548e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -43,7 +43,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include "i915_vma.h"
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2984d2810e42..1ae0882dc1d4 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1142,18 +1142,18 @@ hdcp2_prepare_ake_init(struct intel_connector 
*connector,
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
struct hdcp_port_data *data = _port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   struct i915_hdcp_comp_master *comp;
+   struct i915_hdcp_master *arbiter;
int ret;
 
mutex_lock(_priv->display.hdcp.comp_mutex);
-   comp = dev_priv->display.hdcp.master;
+   arbiter = dev_priv->display.hdcp.master;
 
-   if (!comp || !comp->ops) {
+   if (!arbiter || !arbiter->ops) {
mutex_unlock(_priv->display.hdcp.comp_mutex);
return -EINVAL;
}
 
-   ret = comp->ops->initiate_hdcp2_session(comp->mei_dev, data, ake_data);
+   ret = arbiter->ops->initiate_hdcp2_session(arbiter->hdcp_dev, data, 
ake_data);
if (ret)
drm_dbg_kms(_priv->drm, "Prepare_ake_init failed. %d\n",
ret);
@@ -1172,18 +1172,18 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_connector 
*connector,
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
struct hdcp_port_data *data = _port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   struct i915_hdcp_comp_master *comp;
+   struct i915_hdcp_master *arbiter;
int ret;
 
mutex_lock(_priv->display.hdcp.comp_mutex);
-   comp = dev_priv->display.hdcp.master;
+   arbiter = dev_priv->display.hdcp.master;
 
-   if (!comp || !comp->ops) {
+   if (!arbiter || !arbiter->ops) {
mutex_unlock(_priv->display.hdcp.comp_mutex);
return -EINVAL;
}
 
-   ret = comp->ops->verify_receiver_cert_prepare_km(comp->mei_dev, data,
+   ret = arbiter->ops->verify_receiver_cert_prepare_km(arbiter->hdcp_dev, 
data,
 rx_cert, paired,
 ek_pub_km, msg_sz);
if (ret < 0)
@@ -1200,18 +1200,18 @@ static int hdcp2_verify_hprime(struct intel_connector 
*connector,
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
struct hdcp_port_data *data = _port->hdcp_port_data;
struct drm_i915_private *dev_priv = 

[Intel-gfx] [PATCH v12 1/6] drm/i915/gsc: Create GSC request submission mechanism

[Suraj Kandpal]

HDCP and PXP will require a common function to allow it to
submit commands to the gsc cs. Also adding the gsc mtl header
that needs to be added on to the existing payloads of HDCP
and PXP.

--v4
-Seprate gsc load and heci cmd submission into different
functions in different files for better scalability [Alan]
-Rename gsc address field [Alan]

--v5
-remove extra line is intel_gsc_fw.h [Uma]

Cc: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Signed-off-by: Suraj Kandpal
Reviewed-by: Alan Previn 
---
 drivers/gpu/drm/i915/Makefile |  1 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  2 +
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 94 +++
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 45 +
 4 files changed, 142 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8e46f57e4569..8c6b3808c49f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -195,6 +195,7 @@ i915-y += \
 i915-y += \
  gt/uc/intel_gsc_fw.o \
  gt/uc/intel_gsc_uc.o \
+ gt/uc/intel_gsc_uc_heci_cmd_submit.o\
  gt/uc/intel_guc.o \
  gt/uc/intel_guc_ads.o \
  gt/uc/intel_guc_capture.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index e10507fa71ce..5d143e2a8db0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -440,6 +440,8 @@
 #define GSC_FW_LOAD GSC_INSTR(1, 0, 2)
 #define   HECI1_FW_LIMIT_VALID (1 << 31)
 
+#define GSC_HECI_CMD_PKT GSC_INSTR(0, 0, 6)
+
 /*
  * Used to convert any address to canonical form.
  * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
new file mode 100644
index ..be2424af521d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
@@ -0,0 +1,94 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include "gt/intel_engine_pm.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_ring.h"
+#include "intel_gsc_uc_heci_cmd_submit.h"
+
+struct gsc_heci_pkt {
+   u64 addr_in;
+   u32 size_in;
+   u64 addr_out;
+   u32 size_out;
+};
+
+static int emit_gsc_heci_pkt(struct i915_request *rq, struct gsc_heci_pkt *pkt)
+{
+   u32 *cs;
+
+   cs = intel_ring_begin(rq, 8);
+   if (IS_ERR(cs))
+   return PTR_ERR(cs);
+
+   *cs++ = GSC_HECI_CMD_PKT;
+   *cs++ = lower_32_bits(pkt->addr_in);
+   *cs++ = upper_32_bits(pkt->addr_in);
+   *cs++ = pkt->size_in;
+   *cs++ = lower_32_bits(pkt->addr_out);
+   *cs++ = upper_32_bits(pkt->addr_out);
+   *cs++ = pkt->size_out;
+   *cs++ = 0;
+
+   intel_ring_advance(rq, cs);
+
+   return 0;
+}
+
+int intel_gsc_uc_heci_cmd_submit_packet(struct intel_gsc_uc *gsc, u64 addr_in,
+   u32 size_in, u64 addr_out,
+   u32 size_out)
+{
+   struct intel_context *ce = gsc->ce;
+   struct i915_request *rq;
+   struct gsc_heci_pkt pkt = {
+   .addr_in = addr_in,
+   .size_in = size_in,
+   .addr_out = addr_out,
+   .size_out = size_out
+   };
+   int err;
+
+   if (!ce)
+   return -ENODEV;
+
+   rq = i915_request_create(ce);
+   if (IS_ERR(rq))
+   return PTR_ERR(rq);
+
+   if (ce->engine->emit_init_breadcrumb) {
+   err = ce->engine->emit_init_breadcrumb(rq);
+   if (err)
+   goto out_rq;
+   }
+
+   err = emit_gsc_heci_pkt(rq, );
+
+   if (err)
+   goto out_rq;
+
+   err = ce->engine->emit_flush(rq, 0);
+
+out_rq:
+   i915_request_get(rq);
+
+   if (unlikely(err))
+   i915_request_set_error_once(rq, err);
+
+   i915_request_add(rq);
+
+   if (!err && i915_request_wait(rq, 0, msecs_to_jiffies(500)) < 0)
+   err = -ETIME;
+
+   i915_request_put(rq);
+
+   if (err)
+   drm_err(_uc_to_gt(gsc)->i915->drm,
+   "Request submission for GSC heci cmd failed (%d)\n",
+   err);
+
+   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
new file mode 100644
index ..cf610dfca7a5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef _INTEL_GSC_UC_HECI_CMD_SUBMIT_H_
+#define _INTEL_GSC_UC_HECI_CMD_SUBMIT_H_
+
+#include 
+

[Intel-gfx] [PATCH v12 0/6] Enable HDCP2.x via GSC CS

[Suraj Kandpal]

These patches enable HDCP2.x on machines MTL and above.
>From MTL onwards CSME is spilt into GSC and CSC and now
we use GSC CS instead of MEI to talk to firmware to start
HDCP authentication

--v2
-Fixing some checkpatch changes which I forgot before sending
out the series

--v3
-Drop cp and fw to make naming more agnostic[Jani]
-Sort header[Jani]
-remove static inline function from i915_hdcp_interface[Jani]
-abstract DISPLAY_VER check[Jani]

--v4
-Remove stale comment P2 [Jani]
-Fix part where file rename looks like its removed in P2 and
added in P3 [Jani]
-Add bitmask definition for host session id[Alan]
-Seprating gsc load and heci cmd submission into different funcs[Alan]
-Create comman function to fill gsc_mtl_header[Alan]

--v5
-No need to make hdcp_message field null as we use kzalloc [Alan]
-use i915->drm instead of gt->i915->drm [Alan]

--v6
-Make each patch build individually [Jani]
-drop cp_fw stale commit subject [Jani]
-fix the date on license [Jani]
-revert back to orginal design where mei and gsc fill their own header

--v7
-remove RB by Ankit

--v8
-change design to allocate and deallocate hdcp_message only at
enablement and disabling of hdcp [Alan]
-fix few formatting issue [Ankit]
-fix stale comments [Ankit]

--v9
-move allocation dealloc of hdcp messgae to init and teardown [Alan]
-remove obj from hdcp message , use i915_vma_unpin_and_release [Alan]
-remove return statement from intel_hdcp_gsc_fini [Ankit]

--v10
-remove unnecessary i915_vma_unpin [Alan]

--v11
-commit message and header fix [Uma]
-comment style fix [Uma]
-add line gap [Uma]

--v12
-rename comp to arbiter [Uma]

Anshuman Gupta (1):
  drm/i915/hdcp: Use generic names for HDCP helpers and structs

Suraj Kandpal (5):
  drm/i915/gsc: Create GSC request submission mechanism
  drm/i915/hdcp: HDCP2.x Refactoring to agnostic hdcp
  drm/i915/hdcp: Refactor HDCP API structures
  drm/i915/mtl: Add function to send command to GSC CS
  drm/i915/mtl: Add HDCP GSC interface

 drivers/gpu/drm/i915/Makefile |   2 +
 .../gpu/drm/i915/display/intel_display_core.h |   8 +-
 .../drm/i915/display/intel_display_types.h|   2 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c | 158 ++--
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 831 ++
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |  26 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |   2 +
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 109 +++
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |  61 ++
 drivers/misc/mei/hdcp/mei_hdcp.c  | 105 ++-
 drivers/misc/mei/hdcp/mei_hdcp.h  | 354 
 include/drm/i915_hdcp_interface.h | 539 
 include/drm/i915_mei_hdcp_interface.h | 184 
 13 files changed, 1718 insertions(+), 663 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
 create mode 100644 include/drm/i915_hdcp_interface.h
 delete mode 100644 include/drm/i915_mei_hdcp_interface.h

-- 
2.25.1

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: prevent forcewake releases during BAR resize

[Andrzej Hajda]

On 08.03.2023 18:29, Das, Nirmoy wrote:


On 3/8/2023 2:36 PM, Andrzej Hajda wrote:

Tests on DG2 machines show that releasing forcewakes during BAR resize
results later in forcewake ack timeouts.
Do we have a fdo/issues url for that? Having that as References would be 
nice.


The patch is result of issue reported internally, but...grepping 
bugtracker I've found potential candidates:


Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6530
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7853

Maybe it would be good to add them on merge.
Anyway thx for a-b.

Regards
Andrzej


  Since forcewakes can be realeased
asynchronously the simplest way to prevent it is to get all forcewakes
for duration of BAR resizing.

v2: hold rpm as well during resizing (Rodrigo)

Signed-off-by: Andrzej Hajda 



Acked-by: Nirmoy Das 



---
Please ignore resend of v1, my mistake.

Regards
Andrzej
---
  drivers/gpu/drm/i915/gt/intel_region_lmem.c | 25 +++--
  1 file changed, 18 insertions(+), 7 deletions(-)

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

index 89fdfc67f8d1e0..2a3217e2890fc7 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -54,6 +54,7 @@ static void i915_resize_lmem_bar(struct 
drm_i915_private *i915, resource_size_t

  struct resource *root_res;
  resource_size_t rebar_size;
  resource_size_t current_size;
+    intel_wakeref_t wakeref;
  u32 pci_cmd;
  int i;
@@ -102,15 +103,25 @@ static void i915_resize_lmem_bar(struct 
drm_i915_private *i915, resource_size_t

  return;
  }
-    /* First disable PCI memory decoding references */
-    pci_read_config_dword(pdev, PCI_COMMAND, _cmd);
-    pci_write_config_dword(pdev, PCI_COMMAND,
-   pci_cmd & ~PCI_COMMAND_MEMORY);
+    /*
+ * Releasing forcewake during BAR resizing results in later 
forcewake

+ * ack timeouts and former can happen any time - it is asynchronous.
+ * Grabbing all forcewakes prevents it.
+ */
+    with_intel_runtime_pm(i915->uncore.rpm, wakeref) {
+    intel_uncore_forcewake_get(>uncore, FORCEWAKE_ALL);
-    _resize_bar(i915, GEN12_LMEM_BAR, rebar_size);
+    /* First disable PCI memory decoding references */
+    pci_read_config_dword(pdev, PCI_COMMAND, _cmd);
+    pci_write_config_dword(pdev, PCI_COMMAND,
+   pci_cmd & ~PCI_COMMAND_MEMORY);
-    pci_assign_unassigned_bus_resources(pdev->bus);
-    pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
+    _resize_bar(i915, GEN12_LMEM_BAR, rebar_size);
+
+    pci_assign_unassigned_bus_resources(pdev->bus);
+    pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
+    intel_uncore_forcewake_put(>uncore, FORCEWAKE_ALL);
+    }
  }
  #else
  static void i915_resize_lmem_bar(struct drm_i915_private *i915, 
resource_size_t lmem_size) {}

Re: [Intel-gfx] [PATCH v10 6/6] drm/i915/mtl: Add HDCP GSC interface

[Kandpal, Suraj]

> -Original Message-
> From: Shankar, Uma 
> Sent: Tuesday, March 7, 2023 12:15 PM
> To: Kandpal, Suraj ; intel-
> g...@lists.freedesktop.org
> Cc: Nautiyal, Ankit K ; Winkler, Tomas
> ; Vivi, Rodrigo ; Gupta,
> Anshuman 
> Subject: RE: [PATCH v10 6/6] drm/i915/mtl: Add HDCP GSC interface
> 
> 
> 
> > -Original Message-
> > From: Shankar, Uma
> > Sent: Monday, March 6, 2023 6:05 PM
> > To: Kandpal, Suraj ;
> > intel-gfx@lists.freedesktop.org
> > Cc: Nautiyal, Ankit K ; Winkler, Tomas
> > ; Vivi, Rodrigo ;
> > Gupta, Anshuman 
> > Subject: RE: [PATCH v10 6/6] drm/i915/mtl: Add HDCP GSC interface
> >
> >
> >
> > > -Original Message-
> > > From: Kandpal, Suraj 
> > > Sent: Wednesday, February 1, 2023 2:38 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Nautiyal, Ankit K ; Kandpal, Suraj
> > > ; Winkler, Tomas
> ;
> > > Vivi, Rodrigo ; Shankar, Uma
> > > ; Gupta, Anshuman
> 
> > > Subject: [PATCH v10 6/6] drm/i915/mtl: Add HDCP GSC interface
> > >
> > > MTL uses GSC command streamer i.e gsc cs to send HDCP/PXP
> commands
> > > to GSC f/w. It requires to keep hdcp display driver agnostic to
> > > content protection f/w (ME/GSC fw) in the form of i915_hdcp_fw_ops
> generic ops.
> > >
> > > Adding HDCP GSC CS interface by leveraging the i915_hdcp_fw_ops
> > > generic ops instead of I915_HDCP_COMPONENT as integral part of i915.
> > >
> > > Adding checks to see if GSC is loaded and proxy is setup
> > >
> > > --v6
> > > -dont change the license date in same patch series [Jani] -fix the
> > > license year {Jani]
> > >
> > > --v8
> > > -remove stale comment [Ankit]
> > > -get headers in alphabetical order [Ankit] -fix hdcp2_supported
> > > check [Ankit]
> > >
> > > --v9
> > > -remove return statement from hdcp_gsc_fini [Ankit]
> >
> > Looks Good to me.
> > Reviewed-by: Uma Shankar 
> >
> > > Cc: Tomas Winkler 
> > > Cc: Rodrigo Vivi 
> > > Cc: Uma Shankar 
> > > Cc: Ankit Nautiyal 
> > > Signed-off-by: Anshuman Gupta 
> > > Signed-off-by: Suraj Kandpal 
> > > Reviewed-by: Ankit Nautiyal 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_hdcp.c |  28 +-
> > >  drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 637
> +-
> > >  drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |   3 +
> > >  3 files changed, 660 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > index 0d6aed1eb171..61bb2bbd0349 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > @@ -23,6 +23,7 @@
> > >  #include "intel_display_power_well.h"
> > >  #include "intel_display_types.h"
> > >  #include "intel_hdcp.h"
> > > +#include "intel_hdcp_gsc.h"
> > >  #include "intel_hdcp_regs.h"
> > >  #include "intel_pcode.h"
> > >
> > > @@ -203,13 +204,20 @@ bool intel_hdcp2_capable(struct
> > > intel_connector
> > > *connector)
> > >   struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> > >   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > >   struct intel_hdcp *hdcp = >hdcp;
> > > + struct intel_gt *gt = dev_priv->media_gt;
> > > + struct intel_gsc_uc *gsc = >uc.gsc;
> > >   bool capable = false;
> > >
> > >   /* I915 support for HDCP2.2 */
> > >   if (!hdcp->hdcp2_supported)
> > >   return false;
> > >
> > > - /* MEI interface is solid */
> > > + /* If MTL+ make sure gsc is loaded and proxy is setup */
> > > + if (intel_hdcp_gsc_cs_required(dev_priv))
> > > + if (!intel_uc_fw_is_running(>fw))
> > > + return false;
> > > +
> > > + /* MEI/GSC interface is solid depending on which is used */
> > >   mutex_lock(_priv->display.hdcp.comp_mutex);
> > >   if (!dev_priv->display.hdcp.comp_added ||
> > > !dev_priv->display.hdcp.master) {
> > >   mutex_unlock(_priv->display.hdcp.comp_mutex);
> > > @@ -2235,6 +2243,9 @@ static int initialize_hdcp_port_data(struct
> > > intel_connector *connector,
> > >
> > >  static bool is_hdcp2_supported(struct drm_i915_private *dev_priv)
> > > {
> > > + if (intel_hdcp_gsc_cs_required(dev_priv))
> > > + return true;
> > > +
> > >   if (!IS_ENABLED(CONFIG_INTEL_MEI_HDCP))
> > >   return false;
> > >
> > > @@ -2256,10 +2267,14 @@ void intel_hdcp_component_init(struct
> > > drm_i915_private *dev_priv)
> > >
> > >   dev_priv->display.hdcp.comp_added = true;
> > >   mutex_unlock(_priv->display.hdcp.comp_mutex);
> > > - ret = component_add_typed(dev_priv->drm.dev, _hdcp_ops,
> > > -   I915_COMPONENT_HDCP);
> > > + if (intel_hdcp_gsc_cs_required(dev_priv))
> > > + ret = intel_hdcp_gsc_init(dev_priv);
> > > + else
> > > + ret = component_add_typed(dev_priv->drm.dev,
> _hdcp_ops,
> > > +   I915_COMPONENT_HDCP);
> > > +
> > >   if (ret < 0) {
> > > - drm_dbg_kms(_priv->drm, "Failed at component
> add(%d)\n",
> > > + drm_dbg_kms(_priv->drm, 

Re: [Intel-gfx] [PATCH v2 3/7] drm/ttm: Use the BIT macro for the TTM_TT_FLAGs

[Thomas Hellström]

Hi, Christian,

Thanks for reviewing these.

Ack to merge reviewed patches through drm-misc-next?

Thanks,

Thomas


On 3/8/23 09:49, Christian König wrote:

Am 07.03.23 um 15:46 schrieb Thomas Hellström:

New code is recommended to use the BIT macro instead of the explicit
shifts. Change the older defines so that we can keep the style 
consistent

with upcoming changes.

v2:
- Also change the value of the _PRIV_POPULATED bit (Christian König)

Signed-off-by: Thomas Hellström 


Reviewed-by: Christian König 


---
  include/drm/ttm/ttm_tt.h | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index b7d3f3843f1e..977ca195a536 100644
--- a/include/drm/ttm/ttm_tt.h
+++ b/include/drm/ttm/ttm_tt.h
@@ -83,12 +83,12 @@ struct ttm_tt {
   * set by TTM after ttm_tt_populate() has successfully 
returned, and is

   * then unset when TTM calls ttm_tt_unpopulate().
   */
-#define TTM_TT_FLAG_SWAPPED    (1 << 0)
-#define TTM_TT_FLAG_ZERO_ALLOC    (1 << 1)
-#define TTM_TT_FLAG_EXTERNAL    (1 << 2)
-#define TTM_TT_FLAG_EXTERNAL_MAPPABLE    (1 << 3)
+#define TTM_TT_FLAG_SWAPPED    BIT(0)
+#define TTM_TT_FLAG_ZERO_ALLOC    BIT(1)
+#define TTM_TT_FLAG_EXTERNAL    BIT(2)
+#define TTM_TT_FLAG_EXTERNAL_MAPPABLE    BIT(3)
  -#define TTM_TT_FLAG_PRIV_POPULATED  (1U << 31)
+#define TTM_TT_FLAG_PRIV_POPULATED    BIT(4)
  uint32_t page_flags;
  /** @num_pages: Number of pages in the page array. */
  uint32_t num_pages;

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable YCbCr420 format for VDSC (rev3)

[Patchwork]

== Series Details ==

Series: Enable YCbCr420 format for VDSC (rev3)
URL   : https://patchwork.freedesktop.org/series/114246/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114246v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 35)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@eof:
- bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/bat-atsm-1/igt@fb...@eof.html

  * igt@gem_mmap@basic:
- bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/bat-atsm-1/igt@gem_m...@basic.html

  * igt@gem_sync@basic-each:
- bat-atsm-1: NOTRUN -> [FAIL][3] ([i915#8062]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/bat-atsm-1/igt@gem_s...@basic-each.html

  * igt@gem_tiled_fence_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/bat-atsm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_hangman@error-state-basic:
- bat-atsm-1: NOTRUN -> [ABORT][6] ([i915#8060])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/bat-atsm-1/igt@i915_hang...@error-state-basic.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][7] -> [ABORT][8] ([i915#7911])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

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

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

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][13] ([i915#5354]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114246v3/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [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#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#7694]: https://gitlab.freedesktop.org/drm/intel/issues/7694
  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#8060]: https://gitlab.freedesktop.org/drm/intel/issues/8060
  [i915#8062]: https://gitlab.freedesktop.org/drm/intel/issues/8062


Build changes
-

  * Linux: CI_DRM_12829 -> Patchwork_114246v3

  CI-20190529: 20190529
  CI_DRM_12829: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7185: 6707461ddb214bb8a75c5fcf2747941c9d9b11ae @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_114246v3: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

6265f67b795c drm/i915/dsc: Add debugfs entry to validate DSC output formats
391c8124760b drm/i915/vdsc: Check slice design requirement
c9e9eb1c4e5d drm/i915/dsc: Fill in native_420 field
58794bd10bb3 drm/i915/dsc: Enable YCbCr420 for VDSC
3c5b3752a47b drm/i915/dsc: Adding the new registers for DSC
252f741175f4 drm/i915/dp: Check if DSC supports the given output_format
6774e60344fc drm/dp_helper: Add helper to check DSC support with given o/p 
format

== Logs ==

For more details see: 

[Intel-gfx] [PATCH v3 7/7] drm/i915/dsc: Add debugfs entry to validate DSC output formats

[Suraj Kandpal]

From: Swati Sharma 

DSC_Output_Format_Sink_Support entry is added to i915_dsc_fec_support_show
to depict if sink supports DSC output formats (RGB/YCbCr420/YCbCr444).
Also, new debugfs entry is created to enforce output format. This is
required because of our driver policy. For ex. if a mode is supported
in both RGB and YCbCr420 output formats by the sink, our policy is to
try RGB first and fall back to YCbCr420, if mode cannot be shown
using RGB. So, to test other output formats like YCbCr420 or YCbCr444,
we need a debugfs entry (force_dsc_output_format) to force this
output format.

v2: -Func name changed to intel_output_format_name() (Jani N)
-Return forced o/p format from intel_dp_output_format() (Jani N)
v3: -output_format_str[] to remain static (Jani N)

Signed-off-by: Swati Sharma 
Reviewed-by: Uma Shankar 
---
 .../drm/i915/display/intel_crtc_state_dump.c  |  4 +-
 .../drm/i915/display/intel_crtc_state_dump.h  |  2 +
 .../drm/i915/display/intel_display_debugfs.c  | 78 +++
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   |  4 +
 5 files changed, 87 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c 
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
index 766633566fd6..54c8adc0702e 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
@@ -123,7 +123,7 @@ static const char * const output_format_str[] = {
[INTEL_OUTPUT_FORMAT_YCBCR444] = "YCBCR4:4:4",
 };
 
-static const char *output_formats(enum intel_output_format format)
+const char *intel_output_format_name(enum intel_output_format format)
 {
if (format >= ARRAY_SIZE(output_format_str))
return "invalid";
@@ -181,7 +181,7 @@ void intel_crtc_state_dump(const struct intel_crtc_state 
*pipe_config,
"active: %s, output_types: %s (0x%x), output format: %s\n",
str_yes_no(pipe_config->hw.active),
buf, pipe_config->output_types,
-   output_formats(pipe_config->output_format));
+   intel_output_format_name(pipe_config->output_format));
 
drm_dbg_kms(>drm,
"cpu_transcoder: %s, pipe bpp: %i, dithering: %i\n",
diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h 
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
index 9399c35b7e5e..780f3f1190d7 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
@@ -8,9 +8,11 @@
 
 struct intel_crtc_state;
 struct intel_atomic_state;
+enum intel_output_format;
 
 void intel_crtc_state_dump(const struct intel_crtc_state *crtc_state,
   struct intel_atomic_state *state,
   const char *context);
+const char *intel_output_format_name(enum intel_output_format format);
 
 #endif /* __INTEL_CRTC_STATE_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 1e654ddd0815..fc2905574e5b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -12,6 +12,7 @@
 #include "i915_irq.h"
 #include "i915_reg.h"
 #include "intel_de.h"
+#include "intel_crtc_state_dump.h"
 #include "intel_display_debugfs.h"
 #include "intel_display_power.h"
 #include "intel_display_power_well.h"
@@ -1535,6 +1536,13 @@ static int i915_dsc_fec_support_show(struct seq_file *m, 
void *data)
   str_yes_no(crtc_state->dsc.compression_enable));
seq_printf(m, "DSC_Sink_Support: %s\n",
   
str_yes_no(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
+   seq_printf(m, "DSC_Output_Format_Sink_Support: RGB: %s 
YCBCR420: %s YCBCR444: %s\n",
+  
str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
+ 
DP_DSC_RGB)),
+  
str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
+ 
DP_DSC_YCbCr420_Native)),
+  
str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
+ 
DP_DSC_YCbCr444)));
seq_printf(m, "Force_DSC_Enable: %s\n",
   str_yes_no(intel_dp->force_dsc_en));
if (!intel_dp_is_edp(intel_dp))
@@ -1660,6 +1668,73 @@ static const struct file_operations i915_dsc_bpc_fops = {
.write = i915_dsc_bpc_write
 };
 
+static int i915_dsc_output_format_show(struct seq_file *m, void *data)
+{
+   struct drm_connector *connector = m->private;
+   struct drm_device *dev = connector->dev;
+   struct drm_crtc *crtc;
+   struct 

[Intel-gfx] [PATCH v3 5/7] drm/i915/dsc: Fill in native_420 field

[Suraj Kandpal]

Now that we have laid the groundwork for YUV420 Enablement
we fill up native_420 field in vdsc_cfg and add appropriate
checks wherever required.

---v2
-adding native_422 field as 0 [Vandita]
-filling in second_line_bpg_offset, second_line_offset_adj
and nsl_bpg_offset in vds_cfg when native_420 is true

---v3
-adding display version check to solve igt issue

--v7
-remove is_pipe_dsc check as its always true for D14 [Jani]

--v10
-keep sink capability check [Jani]
-move from !(x == y  || w == z) to x !=y && w != z [Jani]

--v11
-avoid native_420 computation if not gen14 [Uma]

--v12
-fix state mismatch issue of compressed_bpp

Cc: Uma Shankar 
Cc: Jani Nikula 
Signed-off-by: Suraj Kandpal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/icl_dsi.c|  2 -
 drivers/gpu/drm/i915/display/intel_dp.c   | 16 +++-
 drivers/gpu/drm/i915/display/intel_vdsc.c | 98 ---
 3 files changed, 100 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 50dcaa895854..dde0269a2778 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1552,8 +1552,6 @@ static int gen11_dsi_dsc_compute_config(struct 
intel_encoder *encoder,
if (crtc_state->dsc.slice_count > 1)
crtc_state->dsc.dsc_split = true;
 
-   vdsc_cfg->convert_rgb = true;
-
/* FIXME: initialize from VBT */
vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index c725b40e2718..b40bb5fd9abb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1467,9 +1467,10 @@ static int intel_dp_dsc_compute_params(struct 
intel_encoder *encoder,
vdsc_cfg->dsc_version_minor =
min(intel_dp_source_dsc_version_minor(intel_dp),
intel_dp_sink_dsc_version_minor(intel_dp));
-
-   vdsc_cfg->convert_rgb = intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP 
- DP_DSC_SUPPORT] &
-   DP_DSC_RGB;
+   if (vdsc_cfg->convert_rgb)
+   vdsc_cfg->convert_rgb =
+   intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - 
DP_DSC_SUPPORT] &
+   DP_DSC_RGB;
 
line_buf_depth = drm_dp_dsc_sink_line_buf_depth(intel_dp->dsc_dpcd);
if (!line_buf_depth) {
@@ -1587,6 +1588,15 @@ int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,

pipe_config->bigjoiner_pipes,
pipe_bpp,
timeslots);
+   /*
+* According to DSC 1.2a Section 4.1.1 Table 4.1 the 
maximum
+* supported PPS value can be 63.9375 and with the 
further
+* mention that bpp should be programmed double the 
target bpp
+* restricting our target bpp to be 31.9375 at max
+*/
+   if (pipe_config->output_format == 
INTEL_OUTPUT_FORMAT_YCBCR420)
+   dsc_max_output_bpp = min_t(u16, 
dsc_max_output_bpp, 31 << 4);
+
if (!dsc_max_output_bpp) {
drm_dbg_kms(_priv->drm,
"Compressed BPP not supported\n");
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 6fa70f3c074b..0388efb49b92 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -461,14 +461,50 @@ int intel_dsc_compute_params(struct intel_crtc_state 
*pipe_config)
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
 pipe_config->dsc.slice_count);
-
-   /* Gen 11 does not support YCbCr */
+   /*
+* According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb 
is 0
+* else 1
+*/
+   vdsc_cfg->convert_rgb = pipe_config->output_format != 
INTEL_OUTPUT_FORMAT_YCBCR420 &&
+   pipe_config->output_format != 
INTEL_OUTPUT_FORMAT_YCBCR444;
+
+   if (DISPLAY_VER(dev_priv) >= 14 &&
+   pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   vdsc_cfg->native_420 = true;
+   /* We do not support YcBCr422 as of now */
+   vdsc_cfg->native_422 = false;
vdsc_cfg->simple_422 = false;
/* Gen 11 does not support VBR */
vdsc_cfg->vbr_enable = false;
 
/* Gen 11 only supports integral values of bpp */
vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
+
+   /*
+* According to DSC 1.2 specs in Section 4.1 if native_420 is set:

[Intel-gfx] [PATCH v3 6/7] drm/i915/vdsc: Check slice design requirement

[Suraj Kandpal]

Add function to check if slice design requirements are being
met as defined in Bspec: 49259 in the section
Slice Design Requirement

--v7
-remove full bspec link [Jani]
-rename intel_dsc_check_slice_design_req to
intel_dsc_slice_dimensions_valid [Jani]

--v8
-fix condition to check if slice width and height are
of two
-fix minimum pixel in slice condition

--v10
-condition should be < rather then >= [Uma]

Cc: Uma Shankar 
Signed-off-by: Suraj Kandpal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 32 +++
 1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 0388efb49b92..8e787c13d26d 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -448,6 +448,29 @@ calculate_rc_params(struct rc_parameters *rc,
}
 }
 
+static int intel_dsc_slice_dimensions_valid(struct intel_crtc_state 
*pipe_config,
+   struct drm_dsc_config *vdsc_cfg)
+{
+   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_RGB ||
+   pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
+   if (vdsc_cfg->slice_height > 4095)
+   return -EINVAL;
+   if (vdsc_cfg->slice_height * vdsc_cfg->slice_width < 15000)
+   return -EINVAL;
+   } else if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
+   if (vdsc_cfg->slice_width % 2)
+   return -EINVAL;
+   if (vdsc_cfg->slice_height % 2)
+   return -EINVAL;
+   if (vdsc_cfg->slice_height > 4094)
+   return -EINVAL;
+   if (vdsc_cfg->slice_height * vdsc_cfg->slice_width < 3)
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 int intel_dsc_compute_params(struct intel_crtc_state *pipe_config)
 {
struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
@@ -456,11 +479,20 @@ int intel_dsc_compute_params(struct intel_crtc_state 
*pipe_config)
u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
const struct rc_parameters *rc_params;
struct rc_parameters *rc = NULL;
+   int err;
u8 i = 0;
 
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
 pipe_config->dsc.slice_count);
+
+   err = intel_dsc_slice_dimensions_valid(pipe_config, vdsc_cfg);
+
+   if (err) {
+   drm_dbg_kms(_priv->drm, "Slice dimension requirements not 
met\n");
+   return err;
+   }
+
/*
 * According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb 
is 0
 * else 1
-- 
2.25.1

[Intel-gfx] [PATCH v3 4/7] drm/i915/dsc: Enable YCbCr420 for VDSC

[Suraj Kandpal]

Implementation of VDSC for YCbCr420.
Add QP tables for 8,10,12 BPC from rc_tables.h in intel_qp_tables.c
(Derived from C-Model, which is given along with DSC1.2a Spec from Vesa)
intel_lookup_range_min/max_qp functons need to take into account the
output format. Based on that appropriate qp table need to be chosen.
Other rc_parameters need to be set where currently values for 444 format
is hardcoded in calculate_rc_parameters( ).
vdsc_cfg struct needs to be filled with output format information, where
these are hardcoded for 444 format.
Bspec: 49259

Signed-off-by: Suraj Kandpal 
Reviewed-by: Vandita Kulkarni 
Reviewed-by: Uma Shankar 
---
 .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
 .../gpu/drm/i915/display/intel_qp_tables.h|   4 +-
 drivers/gpu/drm/i915/display/intel_vdsc.c |   4 +-
 3 files changed, 180 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_qp_tables.c 
b/drivers/gpu/drm/i915/display/intel_qp_tables.c
index 6f8e4ec5c0fb..6e86c0971d24 100644
--- a/drivers/gpu/drm/i915/display/intel_qp_tables.c
+++ b/drivers/gpu/drm/i915/display/intel_qp_tables.c
@@ -17,6 +17,15 @@
 /* from BPP 6 to 36 in steps of 0.5 */
 #define RC_RANGE_QP444_12BPC_MAX_NUM_BPP   61
 
+/* from BPP 6 to 24 in steps of 0.5 */
+#define RC_RANGE_QP420_8BPC_MAX_NUM_BPP17
+
+/* from BPP 6 to 30 in steps of 0.5 */
+#define RC_RANGE_QP420_10BPC_MAX_NUM_BPP   23
+
+/* from BPP 6 to 36 in steps of 0.5 */
+#define RC_RANGE_QP420_12BPC_MAX_NUM_BPP   29
+
 /*
  * These qp tables are as per the C model
  * and it has the rows pointing to bpps which increment
@@ -283,26 +292,182 @@ static const u8 
rc_range_maxqp444_12bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP444_12BPC
  11, 11, 10, 10, 10, 10, 10, 9, 9, 8, 8, 8, 8, 8, 7, 7, 6, 6, 6, 6, 5, 
5, 4 }
 };
 
-#define PARAM_TABLE(_minmax, _bpc, _row, _col)  do { \
-   if (bpc == (_bpc)) \
-   return rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+static const u8 
rc_range_minqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MAX_NUM_BPP] = {
+   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 3, 3, 3, 3, 3, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0 },
+   { 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+   { 3, 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+   { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
+   { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 0 },
+   { 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 1, 1 },
+   { 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 3, 3, 3, 3, 2, 1, 1 },
+   { 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 2, 2, 1 },
+   { 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 3, 3, 2, 1 },
+   { 9, 8, 8, 7, 7, 7, 7, 7, 7, 6, 5, 5, 4, 3, 3, 3, 2 },
+   { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3 }
+};
+
+static const u8 
rc_range_maxqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MAX_NUM_BPP] = {
+   { 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 4, 4, 4, 4, 4, 3, 2, 2, 1, 1, 1, 1, 0, 0, 0, 0, 0 },
+   { 5, 5, 5, 5, 5, 4, 3, 2, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+   { 6, 6, 6, 6, 6, 5, 4, 3, 2, 2, 2, 1, 1, 1, 1, 0, 0 },
+   { 7, 7, 7, 7, 7, 5, 4, 3, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 2, 2, 2, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1 },
+   { 8, 8, 8, 8, 8, 7, 6, 5, 4, 4, 4, 3, 3, 2, 2, 2, 1 },
+   { 9, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1 },
+   { 10, 10, 9, 9, 9, 8, 7, 6, 5, 5, 5, 4, 4, 3, 3, 2, 2 },
+   { 10, 10, 10, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 2, 2 },
+   { 11, 11, 10, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4, 3, 3, 2 },
+   { 11, 11, 11, 10, 9, 9, 9, 8, 7, 7, 6, 5, 5, 4, 4, 3, 2 },
+   { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 4, 4, 4, 3 },
+   { 14, 13, 13, 12, 11, 11, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4 }
+};
+
+static const u8 
rc_range_minqp420_10bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_10BPC_MAX_NUM_BPP] = 
{
+   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 4, 4, 4, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 4, 4, 4, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 3, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0 },
+   { 7, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0 },
+   { 7, 7, 7, 7, 7, 6, 5, 5, 5, 5, 5, 4, 3, 3, 2, 2, 1, 1, 1, 1, 1, 0, 0 },
+   { 7, 7, 7, 7, 7, 6, 6, 5, 5, 5, 5, 4, 4, 4, 3, 2, 2, 2, 2, 1, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 6, 5, 4, 4, 4, 3, 2, 2, 2, 1, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 2, 1, 1 },
+   { 7, 7, 7, 7, 7, 7, 7, 7, 7, 

[Intel-gfx] [PATCH v3 3/7] drm/i915/dsc: Adding the new registers for DSC

[Suraj Kandpal]

Adding new DSC register which are introducted MTL onwards

Signed-off-by: Suraj Kandpal 
Reviewed-by: Vandita Kulkarni 
Reviewed-by: Uma Shankar 
---
 .../gpu/drm/i915/display/intel_vdsc_regs.h| 28 +++
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc_regs.h 
b/drivers/gpu/drm/i915/display/intel_vdsc_regs.h
index 4fd883463752..b71f00b5c761 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_vdsc_regs.h
@@ -46,6 +46,32 @@
   
_ICL_PIPE_DSS_CTL2_PB, \
   
_ICL_PIPE_DSS_CTL2_PC)
 
+/* MTL Display Stream Compression registers */
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PB  0x782B4
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PB  0x783B4
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PC  0x784B4
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PC  0x785B4
+#define MTL_DSC0_PICTURE_PARAMETER_SET_17(pipe)_MMIO_PIPE((pipe) - 
PIPE_B, \
+  
_MTL_DSC0_PICTURE_PARAMETER_SET_17_PB, \
+  
_MTL_DSC0_PICTURE_PARAMETER_SET_17_PC)
+#define MTL_DSC1_PICTURE_PARAMETER_SET_17(pipe)_MMIO_PIPE((pipe) - 
PIPE_B, \
+  
_MTL_DSC1_PICTURE_PARAMETER_SET_17_PB, \
+  
_MTL_DSC1_PICTURE_PARAMETER_SET_17_PC)
+#define DSC_SL_BPG_OFFSET(offset)  ((offset) << 27)
+
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PB  0x782B8
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PB  0x783B8
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PC  0x784B8
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PC  0x785B8
+#define MTL_DSC0_PICTURE_PARAMETER_SET_18(pipe)_MMIO_PIPE((pipe) - 
PIPE_B, \
+  
_MTL_DSC0_PICTURE_PARAMETER_SET_18_PB, \
+  
_MTL_DSC0_PICTURE_PARAMETER_SET_18_PC)
+#define MTL_DSC1_PICTURE_PARAMETER_SET_18(pipe)_MMIO_PIPE((pipe) - 
PIPE_B, \
+  
_MTL_DSC1_PICTURE_PARAMETER_SET_18_PB, \
+  
_MTL_DSC1_PICTURE_PARAMETER_SET_18_PC)
+#define DSC_NSL_BPG_OFFSET(offset) ((offset) << 16)
+#define DSC_SL_OFFSET_ADJ(offset)  ((offset) << 0)
+
 /* Icelake Display Stream Compression Registers */
 #define DSCA_PICTURE_PARAMETER_SET_0   _MMIO(0x6B200)
 #define DSCC_PICTURE_PARAMETER_SET_0   _MMIO(0x6BA00)
@@ -59,6 +85,8 @@
 #define ICL_DSC1_PICTURE_PARAMETER_SET_0(pipe) _MMIO_PIPE((pipe) - PIPE_B, \
   
_ICL_DSC1_PICTURE_PARAMETER_SET_0_PB, \
   
_ICL_DSC1_PICTURE_PARAMETER_SET_0_PC)
+#define  DSC_NATIVE_422_ENABLE BIT(23)
+#define  DSC_NATIVE_420_ENABLE BIT(22)
 #define  DSC_ALT_ICH_SEL   (1 << 20)
 #define  DSC_VBR_ENABLE(1 << 19)
 #define  DSC_422_ENABLE(1 << 18)
-- 
2.25.1

[Intel-gfx] [PATCH v3 2/7] drm/i915/dp: Check if DSC supports the given output_format

[Suraj Kandpal]

From: Ankit Nautiyal 

Go with DSC only if the given output_format is supported.

v2: Use drm helper to get DSC format support for sink.

v3: remove drm_dp_dsc_compute_bpp.

Cc: Uma Shankar 
Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 28 +
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index aee93b0d810e..c725b40e2718 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1492,6 +1492,31 @@ static int intel_dp_dsc_compute_params(struct 
intel_encoder *encoder,
return drm_dsc_compute_rc_parameters(vdsc_cfg);
 }
 
+static bool intel_dp_dsc_supports_format(struct intel_dp *intel_dp,
+enum intel_output_format output_format)
+{
+   u8 sink_dsc_format;
+
+   switch (output_format) {
+   case INTEL_OUTPUT_FORMAT_RGB:
+   sink_dsc_format = DP_DSC_RGB;
+   break;
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   sink_dsc_format = DP_DSC_YCbCr444;
+   break;
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   if (min(intel_dp_source_dsc_version_minor(intel_dp),
+   intel_dp_sink_dsc_version_minor(intel_dp)) < 2)
+   return false;
+   sink_dsc_format = DP_DSC_YCbCr420_Native;
+   break;
+   default:
+   return false;
+   }
+
+   return drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd, 
sink_dsc_format);
+}
+
 int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state,
@@ -1512,6 +1537,9 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return -EINVAL;
 
+   if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
+   return -EINVAL;
+
if (compute_pipe_bpp)
pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, 
conn_state->max_requested_bpc);
else
-- 
2.25.1

[Intel-gfx] [PATCH v3 1/7] drm/dp_helper: Add helper to check DSC support with given o/p format

[Suraj Kandpal]

From: Ankit Nautiyal 

Add helper to check if the DP sink supports DSC with the given
o/p format.

v2: Add documentation for the helper. (Uma Shankar)

v3: /** instead of  /* (Uma Shankar)

Signed-off-by: Ankit Nautiyal 
Reviewed-by: Uma Shankar 
---
 include/drm/display/drm_dp_helper.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/drm/display/drm_dp_helper.h 
b/include/drm/display/drm_dp_helper.h
index ab55453f2d2c..533d3ee7fe05 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -194,6 +194,19 @@ drm_dp_dsc_sink_max_slice_width(const u8 
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
DP_DSC_SLICE_WIDTH_MULTIPLIER;
 }
 
+/**
+ * drm_dp_dsc_sink_supports_format() - check if sink supports DSC with given 
output format
+ * @dsc_dpcd : DSC-capability DPCDs of the sink
+ * @output_format: output_format which is to be checked
+ *
+ * Returns true if the sink supports DSC with the given output_format, false 
otherwise.
+ */
+static inline bool
+drm_dp_dsc_sink_supports_format(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE], 
u8 output_format)
+{
+   return dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - DP_DSC_SUPPORT] & 
output_format;
+}
+
 /* Forward Error Correction Support on DP 1.4 */
 static inline bool
 drm_dp_sink_supports_fec(const u8 fec_capable)
-- 
2.25.1

[Intel-gfx] [PATCH v3 0/7] Enable YCbCr420 format for VDSC

[Suraj Kandpal]

This patch series aims to enable the YCbCr420 format
for DSC. Changes are mostly compute params related for
hdmi,dp and dsi along with the addition of new rc_tables
for native_420 and corresponding changes to macros used to
fetch them.
There have been discussions prior to this series in which some patches
have gotten rb and can be found in the below link
https://patchwork.freedesktop.org/series/113729

Ankit Nautiyal (2):
  drm/dp_helper: Add helper to check DSC support with given o/p format
  drm/i915/dp: Check if DSC supports the given output_format

Suraj Kandpal (4):
  drm/i915/dsc: Adding the new registers for DSC
  drm/i915/dsc: Enable YCbCr420 for VDSC
  drm/i915/dsc: Fill in native_420 field
  drm/i915/vdsc: Check slice design requirement

Swati Sharma (1):
  drm/i915/dsc: Add debugfs entry to validate DSC output formats

 drivers/gpu/drm/i915/display/icl_dsi.c|   2 -
 .../drm/i915/display/intel_crtc_state_dump.c  |   4 +-
 .../drm/i915/display/intel_crtc_state_dump.h  |   2 +
 .../drm/i915/display/intel_display_debugfs.c  |  78 
 .../drm/i915/display/intel_display_types.h|   1 +
 drivers/gpu/drm/i915/display/intel_dp.c   |  48 -
 .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
 .../gpu/drm/i915/display/intel_qp_tables.h|   4 +-
 drivers/gpu/drm/i915/display/intel_vdsc.c | 132 +++--
 .../gpu/drm/i915/display/intel_vdsc_regs.h|  28 +++
 include/drm/display/drm_dp_helper.h   |  13 ++
 11 files changed, 467 insertions(+), 32 deletions(-)

-- 
2.25.1

Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: Make use of idr_find and idr_for_each_entry in dmabuf

[Zhenyu Wang]

On 2023.03.03 22:07:18 +0800, Cai Huoqing wrote:
> This patch uses the already existing IDR mechanism to simplify
> and improve the dmabuf code.
> 
> Using 'vgpu.object_idr' directly instead of 'dmabuf_obj_list_head'
> or 'dmabuf.list', because the dmabuf_obj can be found by 'idr_find'
> or 'idr_for_each_entry'.
> 
> Signed-off-by: Cai Huoqing 
> ---
> v1->v2:
>   1.Use idr_find to get the target one and free it instead of free all 
> dma objs.
>   2.Revert the original code 'ret' related
>   3.Add '&& !idr_is_empty()' like the original code '&& !list_empty()'

Looks good to me. I'll send it for some regression test before upstream.

Reviewed-by: Zhenyu Wang 

Thanks!

> 
> v1 link:
>   
> https://lore.kernel.org/lkml/20230302115318.79487-1-cai.huoq...@linux.dev/
> 
>  drivers/gpu/drm/i915/gvt/dmabuf.c | 58 +++
>  drivers/gpu/drm/i915/gvt/dmabuf.h |  1 -
>  drivers/gpu/drm/i915/gvt/gvt.h|  1 -
>  drivers/gpu/drm/i915/gvt/vgpu.c   |  1 -
>  4 files changed, 12 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c 
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 6834f9fe40cf..cf619b1ed3ad 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.c
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -133,21 +133,15 @@ static void dmabuf_gem_object_free(struct kref *kref)
>   struct intel_vgpu_dmabuf_obj *obj =
>   container_of(kref, struct intel_vgpu_dmabuf_obj, kref);
>   struct intel_vgpu *vgpu = obj->vgpu;
> - struct list_head *pos;
>   struct intel_vgpu_dmabuf_obj *dmabuf_obj;
>  
>   if (vgpu && test_bit(INTEL_VGPU_STATUS_ACTIVE, vgpu->status) &&
> - !list_empty(>dmabuf_obj_list_head)) {
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct 
> intel_vgpu_dmabuf_obj, list);
> - if (dmabuf_obj == obj) {
> - list_del(pos);
> - idr_remove(>object_idr,
> -dmabuf_obj->dmabuf_id);
> - kfree(dmabuf_obj->info);
> - kfree(dmabuf_obj);
> - break;
> - }
> + !idr_is_empty(>object_idr)) {
> + dmabuf_obj = idr_find(>object_idr, obj->dmabuf_id);
> + if (dmabuf_obj) {
> + idr_remove(>object_idr, obj->dmabuf_id);
> + kfree(dmabuf_obj->info);
> + kfree(dmabuf_obj);
>   }
>   } else {
>   /* Free the orphan dmabuf_objs here */
> @@ -340,13 +334,12 @@ static struct intel_vgpu_dmabuf_obj *
>  pick_dmabuf_by_info(struct intel_vgpu *vgpu,
>   struct intel_vgpu_fb_info *latest_info)
>  {
> - struct list_head *pos;
>   struct intel_vgpu_fb_info *fb_info;
>   struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
>   struct intel_vgpu_dmabuf_obj *ret = NULL;
> + int id;
>  
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj, 
> list);
> + idr_for_each_entry(>object_idr, dmabuf_obj, id) {
>   if (!dmabuf_obj->info)
>   continue;
>  
> @@ -366,24 +359,6 @@ pick_dmabuf_by_info(struct intel_vgpu *vgpu,
>   return ret;
>  }
>  
> -static struct intel_vgpu_dmabuf_obj *
> -pick_dmabuf_by_num(struct intel_vgpu *vgpu, u32 id)
> -{
> - struct list_head *pos;
> - struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
> - struct intel_vgpu_dmabuf_obj *ret = NULL;
> -
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj, 
> list);
> - if (dmabuf_obj->dmabuf_id == id) {
> - ret = dmabuf_obj;
> - break;
> - }
> - }
> -
> - return ret;
> -}
> -
>  static void update_fb_info(struct vfio_device_gfx_plane_info *gvt_dmabuf,
> struct intel_vgpu_fb_info *fb_info)
>  {
> @@ -477,11 +452,6 @@ int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void 
> *args)
>  
>   update_fb_info(gfx_plane_info, _info);
>  
> - INIT_LIST_HEAD(_obj->list);
> - mutex_lock(>dmabuf_lock);
> - list_add_tail(_obj->list, >dmabuf_obj_list_head);
> - mutex_unlock(>dmabuf_lock);
> -
>   gvt_dbg_dpy("vgpu%d: %s new dmabuf_obj ref %d, id %d\n", vgpu->id,
>   __func__, kref_read(_obj->kref), ret);
>  
> @@ -508,7 +478,7 @@ int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu, 
> unsigned int dmabuf_id)
>  
>   mutex_lock(>dmabuf_lock);
>  
> - dmabuf_obj = pick_dmabuf_by_num(vgpu, dmabuf_id);
> + dmabuf_obj = idr_find(>object_idr, dmabuf_id);
>   if (dmabuf_obj == NULL) {
>   gvt_vgpu_err("invalid dmabuf id:%d\n", dmabuf_id);
>   ret = -EINVAL;
> @@ -570,23 +540,19 @@ int intel_vgpu_get_dmabuf(struct 

Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915/mtl: Add Wa_14017073508 for SAMedia"

[Nilawar, Badal]

On 08-03-2023 20:55, Nilawar, Badal wrote:

Hi Jani,

On 08-03-2023 16:48, Jani Nikula wrote:

On Wed, 08 Mar 2023, Badal Nilawar  wrote:

This reverts commit 8f70f1ec587da0b0d52d768fd8c3defbc5e5b55c.


Reverts need a commit message too. The why. The cover letter is not
recorded in git history.


I will add commit message.


Is it ok if I squash both the commits?


Regards,
Badal


BR,
Jani.


Signed-off-by: Badal Nilawar 
---
  drivers/gpu/drm/i915/gt/intel_gt_pm.c | 27 ---
  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 13 +--
  drivers/gpu/drm/i915/i915_reg.h   |  9 
  3 files changed, 1 insertion(+), 48 deletions(-)

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

index 85ae7dc079f2..e02cb90723ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -20,31 +20,10 @@
  #include "intel_rc6.h"
  #include "intel_rps.h"
  #include "intel_wakeref.h"
-#include "intel_pcode.h"
  #include "pxp/intel_pxp_pm.h"
  #define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)
-static void mtl_media_busy(struct intel_gt *gt)
-{
-    /* Wa_14017073508: mtl */
-    if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
-    gt->type == GT_MEDIA)
-    snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
-  PCODE_MBOX_GT_STATE_MEDIA_BUSY,
-  PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
-}
-
-static void mtl_media_idle(struct intel_gt *gt)
-{
-    /* Wa_14017073508: mtl */
-    if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
-    gt->type == GT_MEDIA)
-    snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
-  PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY,
-  PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
-}
-
  static void user_forcewake(struct intel_gt *gt, bool suspend)
  {
  int count = atomic_read(>user_wakeref);
@@ -92,9 +71,6 @@ static int __gt_unpark(struct intel_wakeref *wf)
  GT_TRACE(gt, "\n");
-    /* Wa_14017073508: mtl */
-    mtl_media_busy(gt);
-
  /*
   * It seems that the DMC likes to transition between the DC 
states a lot
   * when there are no connected displays (no active power 
domains) during

@@ -144,9 +120,6 @@ static int __gt_park(struct intel_wakeref *wf)
  GEM_BUG_ON(!wakeref);
  intel_display_power_put_async(i915, POWER_DOMAIN_GT_IRQ, wakeref);
-    /* Wa_14017073508: mtl */
-    mtl_media_idle(gt);
-
  return 0;
  }
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c

index fcf51614f9a4..1adec6de223c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
@@ -12,20 +12,9 @@
  static bool __guc_rc_supported(struct intel_guc *guc)
  {
-    struct intel_gt *gt = guc_to_gt(guc);
-
-    /*
- * Wa_14017073508: mtl
- * Do not enable gucrc to avoid additional interrupts which
- * may disrupt pcode wa.
- */
-    if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
-    gt->type == GT_MEDIA)
-    return false;
-
  /* GuC RC is unavailable for pre-Gen12 */
  return guc->submission_supported &&
-    GRAPHICS_VER(gt->i915) >= 12;
+    GRAPHICS_VER(guc_to_gt(guc)->i915) >= 12;
  }
  static bool __guc_rc_selected(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/i915_reg.h 
b/drivers/gpu/drm/i915/i915_reg.h

index f2ce4bde6a68..b177cdeee1ec 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6469,15 +6469,6 @@
  /*   XEHP_PCODE_FREQUENCY_CONFIG param2 */
  #define PCODE_MBOX_DOMAIN_NONE    0x0
  #define PCODE_MBOX_DOMAIN_MEDIAFF    0x3
-
-/* Wa_14017210380: mtl */
-#define   PCODE_MBOX_GT_STATE    0x50
-/* sub-commands (param1) */
-#define PCODE_MBOX_GT_STATE_MEDIA_BUSY    0x1
-#define PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY    0x2
-/* param2 */
-#define PCODE_MBOX_GT_STATE_DOMAIN_MEDIA    0x1
-
  #define GEN6_PCODE_DATA    _MMIO(0x138128)
  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT    8
  #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT    16

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Use common freq functions with sysfs (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Use common freq functions with sysfs (rev2)
URL   : https://patchwork.freedesktop.org/series/114814/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114814v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 36)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@eof:
- bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/bat-atsm-1/igt@fb...@eof.html

  * igt@gem_mmap@basic:
- bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/bat-atsm-1/igt@gem_m...@basic.html

  * igt@gem_sync@basic-each:
- bat-atsm-1: NOTRUN -> [FAIL][3] ([i915#8062]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/bat-atsm-1/igt@gem_s...@basic-each.html

  * igt@gem_tiled_fence_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/bat-atsm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_hangman@error-state-basic:
- bat-atsm-1: NOTRUN -> [ABORT][6] ([i915#8060])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/bat-atsm-1/igt@i915_hang...@error-state-basic.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][7] -> [ABORT][8] ([i915#7911] / [i915#7913])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@migrate:
- bat-adlp-9: [PASS][9] -> [DMESG-FAIL][10] ([i915#7699])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/bat-adlp-9/igt@i915_selftest@l...@migrate.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/bat-adlp-9/igt@i915_selftest@l...@migrate.html

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

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][13] ([i915#5354]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v2/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  
 Possible fixes 

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

  
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [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#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#8060]: https://gitlab.freedesktop.org/drm/intel/issues/8060
  [i915#8062]: https://gitlab.freedesktop.org/drm/intel/issues/8062


Build changes
-

  * Linux: CI_DRM_12829 -> Patchwork_114814v2

  CI-20190529: 20190529
  CI_DRM_12829: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7185: 6707461ddb214bb8a75c5fcf2747941c9d9b11ae @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_114814v2: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux


### 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pmu: Use common freq functions with sysfs (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Use common freq functions with sysfs (rev2)
URL   : https://patchwork.freedesktop.org/series/114814/
State : warning

== Summary ==

Error: dim checkpatch failed
b9a3eb1e49e1 drm/i915/pmu: Use functions common with sysfs to read actual freq
-:15: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'Closes:', use 
'Link:' instead
#15: 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8280

total: 0 errors, 1 warnings, 0 checks, 117 lines checked
356bf09249d3 drm/i915/pmu: Remove fallback to requested freq for SLPC

Re: [Intel-gfx] [PATCH 3/3] drm/i915/pmu: Use common freq functions with sysfs

[Dixit, Ashutosh]

On Tue, 07 Mar 2023 22:12:49 -0800, Belgaumkar, Vinay wrote:
>

Hi Vinay,

> On 3/7/2023 9:33 PM, Ashutosh Dixit wrote:
> > Using common freq functions with sysfs in PMU (but without taking
> > forcewake) solves the following issues (a) missing support for MTL (b)
>
> For the requested_freq, we read it only if actual_freq is zero below
> (meaning, GT is in C6). So then what is the point of reading it without a
> force wake? It will also be zero, correct?

Yes agreed. I had tested this and you do see values for requested freq
which look correct even when actual freq is 0 even without taking
forcewake. That is why I ended up writing Patch 2/3.

However what I missed is what you pointed out that 0xa008 is a shadowed
register which cannot be read without taking forcewake. It is probably
returning the last value which was written to the shadowed write register.

As a result I have dropped the "drm/i915/rps: Expose
get_requested_frequency_fw for PMU" patch in v2 of this series.

Thanks.
--
Ashutosh

[Intel-gfx] [PATCH 2/2] drm/i915/pmu: Remove fallback to requested freq for SLPC

[Ashutosh Dixit]

The fallback to requested freq does not work for SLPC because SLPC does not
use 'struct intel_rps'. Also for SLPC requested freq can only be obtained
from a hw register after acquiring forcewake which we don't want to do for
PMU. Therefore remove fallback to requested freq for SLPC. The actual freq
will be 0 when gt is in RC6 which is correct. Also this is rare since PMU
freq sampling happens only when gt is unparked.

Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_pmu.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 7ece883a7d95..f697fabed64a 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -393,7 +393,14 @@ frequency_sample(struct intel_gt *gt, unsigned int 
period_ns)
 * frequency. Fortunately, the read should rarely fail!
 */
val = intel_rps_read_actual_frequency_fw(rps);
-   if (!val)
+
+   /*
+* SLPC does not use 'struct intel_rps'. Also for SLPC
+* requested freq can only be obtained after acquiring
+* forcewake and reading a hw register. For SLPC just
+* let val be 0
+*/
+   if (!val && !intel_uc_uses_guc_slpc(>uc))
val = intel_gpu_freq(rps, rps->cur_freq);
 
add_sample_mult(>sample[__I915_SAMPLE_FREQ_ACT],
-- 
2.38.0

[Intel-gfx] [PATCH 0/2] drm/i915/pmu: Use common freq functions with sysfs

[Ashutosh Dixit]

Expose intel_rps_read_actual_frequency_fw to read the actual freq without
taking forcewake for use by PMU. The code is refactored to use a common set
of functions across sysfs and PMU. Using common functions with sysfs in PMU
solves the issues of missing support for MTL and missing support for older
generations (prior to Gen6). It also future proofs the PMU where sometimes
code has been updated for sysfs and PMU has been missed.

Ashutosh Dixit (2):
  drm/i915/pmu: Use functions common with sysfs to read actual freq
  drm/i915/pmu: Remove fallback to requested freq for SLPC

 drivers/gpu/drm/i915/gt/intel_rps.c | 46 +++--
 drivers/gpu/drm/i915/gt/intel_rps.h |  2 +-
 drivers/gpu/drm/i915/i915_pmu.c | 17 +++
 3 files changed, 43 insertions(+), 22 deletions(-)

-- 
2.38.0

[Intel-gfx] [PATCH 1/2] drm/i915/pmu: Use functions common with sysfs to read actual freq

[Ashutosh Dixit]

Expose intel_rps_read_actual_frequency_fw to read the actual freq without
taking forcewake for use by PMU. The code is refactored to use a common set
of functions across sysfs and PMU. Using common functions with sysfs in PMU
solves the issues of missing support for MTL and missing support for older
generations (prior to Gen6). It also future proofs the PMU where sometimes
code has been updated for sysfs and PMU has been missed.

Fixes: 22009b6dad66 ("drm/i915/mtl: Modify CAGF functions for MTL")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8280
Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 46 +++--
 drivers/gpu/drm/i915/gt/intel_rps.h |  2 +-
 drivers/gpu/drm/i915/i915_pmu.c | 10 +++
 3 files changed, 36 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 4d0dc9de23f9..3957c5ee5cba 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2046,16 +2046,6 @@ void intel_rps_sanitize(struct intel_rps *rps)
rps_disable_interrupts(rps);
 }
 
-u32 intel_rps_read_rpstat_fw(struct intel_rps *rps)
-{
-   struct drm_i915_private *i915 = rps_to_i915(rps);
-   i915_reg_t rpstat;
-
-   rpstat = (GRAPHICS_VER(i915) >= 12) ? GEN12_RPSTAT1 : GEN6_RPSTAT1;
-
-   return intel_uncore_read_fw(rps_to_gt(rps)->uncore, rpstat);
-}
-
 u32 intel_rps_read_rpstat(struct intel_rps *rps)
 {
struct drm_i915_private *i915 = rps_to_i915(rps);
@@ -2089,10 +2079,11 @@ u32 intel_rps_get_cagf(struct intel_rps *rps, u32 
rpstat)
return cagf;
 }
 
-static u32 read_cagf(struct intel_rps *rps)
+static u32 __read_cagf(struct intel_rps *rps, bool take_fw)
 {
struct drm_i915_private *i915 = rps_to_i915(rps);
struct intel_uncore *uncore = rps_to_uncore(rps);
+   i915_reg_t r = INVALID_MMIO_REG;
u32 freq;
 
/*
@@ -2100,22 +2091,30 @@ static u32 read_cagf(struct intel_rps *rps)
 * registers will return 0 freq when GT is in RC6
 */
if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
-   freq = intel_uncore_read(uncore, MTL_MIRROR_TARGET_WP1);
+   r = MTL_MIRROR_TARGET_WP1;
} else if (GRAPHICS_VER(i915) >= 12) {
-   freq = intel_uncore_read(uncore, GEN12_RPSTAT1);
+   r = GEN12_RPSTAT1;
} else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
vlv_punit_get(i915);
freq = vlv_punit_read(i915, PUNIT_REG_GPU_FREQ_STS);
vlv_punit_put(i915);
+   goto exit;
} else if (GRAPHICS_VER(i915) >= 6) {
-   freq = intel_uncore_read(uncore, GEN6_RPSTAT1);
+   r = GEN6_RPSTAT1;
} else {
-   freq = intel_uncore_read(uncore, MEMSTAT_ILK);
+   r = MEMSTAT_ILK;
}
 
+   freq = take_fw ? intel_uncore_read(uncore, r) : 
intel_uncore_read_fw(uncore, r);
+exit:
return intel_rps_get_cagf(rps, freq);
 }
 
+static u32 read_cagf(struct intel_rps *rps)
+{
+   return __read_cagf(rps, true);
+}
+
 u32 intel_rps_read_actual_frequency(struct intel_rps *rps)
 {
struct intel_runtime_pm *rpm = rps_to_uncore(rps)->rpm;
@@ -2128,6 +2127,23 @@ u32 intel_rps_read_actual_frequency(struct intel_rps 
*rps)
return freq;
 }
 
+static u32 read_cagf_fw(struct intel_rps *rps)
+{
+   return __read_cagf(rps, false);
+}
+
+u32 intel_rps_read_actual_frequency_fw(struct intel_rps *rps)
+{
+   struct intel_runtime_pm *rpm = rps_to_uncore(rps)->rpm;
+   intel_wakeref_t wakeref;
+   u32 freq = 0;
+
+   with_intel_runtime_pm_if_in_use(rpm, wakeref)
+   freq = intel_gpu_freq(rps, read_cagf_fw(rps));
+
+   return freq;
+}
+
 u32 intel_rps_read_punit_req(struct intel_rps *rps)
 {
struct intel_uncore *uncore = rps_to_uncore(rps);
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h 
b/drivers/gpu/drm/i915/gt/intel_rps.h
index c622962c6bef..2d5b3ef58606 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -39,6 +39,7 @@ int intel_gpu_freq(struct intel_rps *rps, int val);
 int intel_freq_opcode(struct intel_rps *rps, int val);
 u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat1);
 u32 intel_rps_read_actual_frequency(struct intel_rps *rps);
+u32 intel_rps_read_actual_frequency_fw(struct intel_rps *rps);
 u32 intel_rps_get_requested_frequency(struct intel_rps *rps);
 u32 intel_rps_get_min_frequency(struct intel_rps *rps);
 u32 intel_rps_get_min_raw_freq(struct intel_rps *rps);
@@ -52,7 +53,6 @@ u32 intel_rps_get_rpn_frequency(struct intel_rps *rps);
 u32 intel_rps_read_punit_req(struct intel_rps *rps);
 u32 intel_rps_read_punit_req_frequency(struct intel_rps *rps);
 u32 intel_rps_read_rpstat(struct intel_rps *rps);
-u32 intel_rps_read_rpstat_fw(struct intel_rps *rps);
 void gen6_rps_get_freq_caps(struct intel_rps *rps, 

[Intel-gfx] ✓ Fi.CI.BAT: success for cpumask: fix incorrect cpumask scanning result checks

[Patchwork]

== Series Details ==

Series: cpumask: fix incorrect cpumask scanning result checks
URL   : https://patchwork.freedesktop.org/series/114882/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114882v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 38)
--

  Additional (3): fi-elk-e7500 fi-ilk-650 fi-pnv-d510 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-elk-e7500:   NOTRUN -> [SKIP][1] ([fdo#109271]) +30 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/fi-elk-e7500/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][2] -> [ABORT][3] ([i915#7911])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@kms_chamelium_edid@dp-edid-read:
- fi-ilk-650: NOTRUN -> [SKIP][4] ([fdo#109271]) +29 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/fi-ilk-650/igt@kms_chamelium_e...@dp-edid-read.html

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

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

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][7] ([fdo#109271]) +38 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

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

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

  * igt@i915_selftest@live@slpc:
- bat-rpls-1: [DMESG-FAIL][12] ([i915#6367]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/bat-rpls-1/igt@i915_selftest@l...@slpc.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  
 Warnings 

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: [DMESG-FAIL][14] ([i915#6367] / [i915#7913]) -> 
[DMESG-FAIL][15] ([i915#6367] / [i915#7913] / [i915#7996])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/bat-rpls-2/igt@i915_selftest@l...@slpc.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114882v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
  [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996


Build changes
-

  * Linux: CI_DRM_12829 -> Patchwork_114882v1

  CI-20190529: 20190529
  CI_DRM_12829: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7185: 6707461ddb214bb8a75c5fcf2747941c9d9b11ae @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_114882v1: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

dde2883cc9f9 cpumask: fix incorrect 

[Intel-gfx] [PATCH CI] cpumask: fix incorrect cpumask scanning result checks

[Ville Syrjala]

From: Linus Torvalds 

It turns out that commit 596ff4a09b89 ("cpumask: re-introduce
constant-sized cpumask optimizations") exposed a number of cases of
drivers not checking the result of "cpumask_next()" and friends
correctly.

The documented correct check for "no more cpus in the cpumask" is to
check for the result being equal or larger than the number of possible
CPU ids, exactly _because_ we've always done those constant-sized
cpumask scans using a widened type before.  So the return value of a
cpumask scan should be checked with

if (cpu >= nr_cpu_ids)
...

because the cpumask scan did not necessarily stop exactly *at* that
maximum CPU id.

But a few cases ended up instead using checks like

if (cpu == nr_cpumask_bits)
...

which used that internal "widened" number of bits.  And that used to
work pretty much by accident (ok, in this case "by accident" is simply
because it matched the historical internal implementation of the cpumask
scanning, so it was more of a "intentionally using implementation
details rather than an accident").

But the extended constant-sized optimizations then did that internal
implementation differently, and now that code that did things wrong but
matched the old implementation no longer worked at all.

Which then causes subsequent odd problems due to using what ends up
being an invalid CPU ID.

Most of these cases require either unusual hardware or special uses to
hit, but the random.c one triggers quite easily.

All you really need is to have a sufficiently small CONFIG_NR_CPUS value
for the bit scanning optimization to be triggered, but not enough CPUs
to then actually fill that widened cpumask.  At that point, the cpumask
scanning will return the NR_CPUS constant, which is _not_ the same as
nr_cpumask_bits.

This just does the mindless fix with

   sed -i 's/== nr_cpumask_bits/>= nr_cpu_ids/'

to fix the incorrect uses.

The ones in the SCSI lpfc driver in particular could probably be fixed
more cleanly by just removing that repeated pattern entirely, but I am
not emptionally invested enough in that driver to care.

Reported-and-tested-by: Guenter Roeck 
Link: 
https://lore.kernel.org/lkml/481b19b5-83a0-4793-b4fd-194ad7b97...@roeck-us.net/
Reported-and-tested-by: Geert Uytterhoeven 
Link: 
https://lore.kernel.org/lkml/CAMuHMdUKo_Sf7TjKzcNDa8Ve+6QrK+P8nSQrSQ=6ltrmcbk...@mail.gmail.com/
Reported-by: Vernon Yang 
Link: https://lore.kernel.org/lkml/20230306160651.2016767-1-vernon...@gmail.com/
Cc: Yury Norov 
Cc: Jason A. Donenfeld 
Signed-off-by: Linus Torvalds 
---
 arch/powerpc/xmon/xmon.c |  2 +-
 drivers/char/random.c|  2 +-
 drivers/net/wireguard/queueing.h |  2 +-
 drivers/scsi/lpfc/lpfc_init.c| 14 +++---
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 73c620c2a3a1..e753a6bd4888 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1275,7 +1275,7 @@ static int xmon_batch_next_cpu(void)
while (!cpumask_empty(_batch_cpus)) {
cpu = cpumask_next_wrap(smp_processor_id(), _batch_cpus,
xmon_batch_start_cpu, true);
-   if (cpu == nr_cpumask_bits)
+   if (cpu >= nr_cpu_ids)
break;
if (xmon_batch_start_cpu == -1)
xmon_batch_start_cpu = cpu;
diff --git a/drivers/char/random.c b/drivers/char/random.c
index ce3ccd172cc8..253f2ddb8913 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1311,7 +1311,7 @@ static void __cold try_to_generate_entropy(void)
/* Basic CPU round-robin, which avoids the current CPU. 
*/
do {
cpu = cpumask_next(cpu, _cpus);
-   if (cpu == nr_cpumask_bits)
+   if (cpu >= nr_cpu_ids)
cpu = cpumask_first(_cpus);
} while (cpu == smp_processor_id() && num_cpus > 1);
 
diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
index 583adb37ee1e..125284b346a7 100644
--- a/drivers/net/wireguard/queueing.h
+++ b/drivers/net/wireguard/queueing.h
@@ -106,7 +106,7 @@ static inline int wg_cpumask_choose_online(int *stored_cpu, 
unsigned int id)
 {
unsigned int cpu = *stored_cpu, cpu_index, i;
 
-   if (unlikely(cpu == nr_cpumask_bits ||
+   if (unlikely(cpu >= nr_cpu_ids ||
 !cpumask_test_cpu(cpu, cpu_online_mask))) {
cpu_index = id % cpumask_weight(cpu_online_mask);
cpu = cpumask_first(cpu_online_mask);
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 61958a24a43d..73b544bfbb2e 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -12563,7 +12563,7 @@ lpfc_cpu_affinity_check(struct lpfc_hba 

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: prevent forcewake releases during BAR resize

[Andi Shyti]

Hi Andrzej,

On Wed, Mar 08, 2023 at 02:36:24PM +0100, Andrzej Hajda wrote:
> Tests on DG2 machines show that releasing forcewakes during BAR resize
> results later in forcewake ack timeouts. Since forcewakes can be realeased
> asynchronously the simplest way to prevent it is to get all forcewakes
> for duration of BAR resizing.
> 
> v2: hold rpm as well during resizing (Rodrigo)
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Andi Shyti 

Thanks,
Andi

Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/selftests: use nop_clear_range instead of local function

[Andi Shyti]

Hi Andrzej,

On Wed, Mar 08, 2023 at 04:39:05PM +0100, Andrzej Hajda wrote:
> Since nop_clear_range is visible it can be used here.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Andi Shyti 

Thanks,
Andi

Re: [Intel-gfx] [PATCH v5 2/4] drm/i915/display: use nop_clear_range instead of local function

[Andi Shyti]

Hi Andrzej,

On Wed, Mar 08, 2023 at 04:39:04PM +0100, Andrzej Hajda wrote:
> Since nop_clear_range is visible it can be used here.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Andi Shyti 

Thanks,
Andi

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915/gt: make nop_clear_range public

[Andi Shyti]

Hi Andrzej,

On Wed, Mar 08, 2023 at 04:39:03PM +0100, Andrzej Hajda wrote:
> Function nop_clear_range can be used instead of local implementations.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Andi Shyti 

Andi

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: vblank stuff (rev6)

[Patchwork]

== Series Details ==

Series: drm/i915: vblank stuff (rev6)
URL   : https://patchwork.freedesktop.org/series/112170/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12829 -> Patchwork_112170v6


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 33)
--

  Missing(3): fi-kbl-soraka bat-dg2-9 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  
 Possible fixes 

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

  
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978


Build changes
-

  * Linux: CI_DRM_12829 -> Patchwork_112170v6

  CI-20190529: 20190529
  CI_DRM_12829: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7185: 6707461ddb214bb8a75c5fcf2747941c9d9b11ae @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_112170v6: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

801e5f358f97 drm/i915: Reject wm levels that exceed vblank time
9a6990c9f06c drm/i915: Extract skl_wm_latency()

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/selftests: keep same cache settings as timeline

[fei . yang]

From: Fei Yang 

On MTL, objects allocated through i915_gem_object_create_internal() are
mapped as uncached in GPU by default because HAS_LLC is false. However
in the live_hwsp_read selftest these watcher objects are mapped as WB
on CPU side. The conseqence is that the updates done by the GPU are not
immediately visible to CPU, thus the selftest is randomly failing due to
the stale data in CPU cache. Solution can be either setting WC for CPU +
UC for GPU, or WB for CPU + 1-way coherent WB for GPU.
To keep the consistency, let's simply inherit the same cache settings
from the timeline, which is WB for CPU + 1-way coherent WB for GPU,
because this test is supposed to emulate the behavior of the timeline
anyway.

v2: copy cache settings from timeline instead of setting it to WC
(Suggested by Chris)

Signed-off-by: Fei Yang 
Reviewed-by: Chris Wilson 
Acked-by: Jonathan Cavitt 
Acked-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/selftest_timeline.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c 
b/drivers/gpu/drm/i915/gt/selftest_timeline.c
index 522d0190509c..631aaed9bc3d 100644
--- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
+++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
@@ -825,7 +825,8 @@ static bool cmp_gte(u32 a, u32 b)
return a >= b;
 }
 
-static int setup_watcher(struct hwsp_watcher *w, struct intel_gt *gt)
+static int setup_watcher(struct hwsp_watcher *w, struct intel_gt *gt,
+struct intel_timeline *tl)
 {
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
@@ -834,7 +835,10 @@ static int setup_watcher(struct hwsp_watcher *w, struct 
intel_gt *gt)
if (IS_ERR(obj))
return PTR_ERR(obj);
 
-   w->map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
+   /* keep the same cache settings as timeline */
+   i915_gem_object_set_cache_coherency(obj, 
tl->hwsp_ggtt->obj->cache_level);
+   w->map = i915_gem_object_pin_map_unlocked(obj,
+   page_unmask_bits(tl->hwsp_ggtt->obj->mm.mapping));
if (IS_ERR(w->map)) {
i915_gem_object_put(obj);
return PTR_ERR(w->map);
@@ -1004,8 +1008,10 @@ static int live_hwsp_read(void *arg)
if (!tl->has_initial_breadcrumb)
goto out_free;
 
+   selftest_tl_pin(tl);
+
for (i = 0; i < ARRAY_SIZE(watcher); i++) {
-   err = setup_watcher([i], gt);
+   err = setup_watcher([i], gt, tl);
if (err)
goto out;
}
@@ -1160,6 +1166,8 @@ static int live_hwsp_read(void *arg)
for (i = 0; i < ARRAY_SIZE(watcher); i++)
cleanup_watcher([i]);
 
+   intel_timeline_unpin(tl);
+
if (igt_flush_test(gt->i915))
err = -EIO;
 
-- 
2.25.1

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix idle pattern enabling

[Ville Syrjälä]

On Thu, Mar 09, 2023 at 12:19:09AM +0200, Imre Deak wrote:
> On Wed, Mar 08, 2023 at 11:28:07PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 02, 2023 at 09:03:42PM +0200, Imre Deak wrote:
> > > On Tue, Feb 14, 2023 at 03:43:48PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > Currently we are always switching to the idle pattern after the
> > > > link training, but we don't always wait for the minimum number
> > > > of idle patterns sent. That doesn't look to be what Bspec
> > > > asks of us.
> > > > 
> > > > According to bspec what we should do is switch to idle pattern
> > > > and wait for it only in DP1.4 MST cases. In all other cases we
> > > > should apparently do neither.
> > > > 
> > > > What confuses matters further is that the port sync SST sequence
> > > > asks us to "stay in idle pattern". But if we never switched to it
> > > > how can we stay in it? This still needs further clarificaiton.
> > > 
> > > HSW seems to require it also for SST, but yes for all other platforms
> > > bspec only requires it for MST.
> > 
> > commit 3ab9c63705cb ("drm/i915: hsw: fix link training for eDP on
> > port-A") (written by you it seems :) says there was some problem on
> > HSW that needed it for DDI A SST as well. But it's not really obvious
> > why you skipped the IDLE_DONE thing there. Maybe just an optimization?
> 
> Ok, forgot about that. Looking back at the discussion the problem on HSW
> was that switching from sending idle patterns to normal mode didn't
> happen automatically due to some HW problem. The workaround was to to
> switch to idle patterns and enable normal mode manually after the pipe
> is enabled. The WA didn't require waiting for IDLE_DONE, but before
> TGL there is no DP_TP_STATUS register on port A either.

Ah, that would explain it. Also might explain some hardcoded wait 
values I saw in some GOP stuff.

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix idle pattern enabling

[Imre Deak]

On Wed, Mar 08, 2023 at 11:28:07PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 02, 2023 at 09:03:42PM +0200, Imre Deak wrote:
> > On Tue, Feb 14, 2023 at 03:43:48PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Currently we are always switching to the idle pattern after the
> > > link training, but we don't always wait for the minimum number
> > > of idle patterns sent. That doesn't look to be what Bspec
> > > asks of us.
> > > 
> > > According to bspec what we should do is switch to idle pattern
> > > and wait for it only in DP1.4 MST cases. In all other cases we
> > > should apparently do neither.
> > > 
> > > What confuses matters further is that the port sync SST sequence
> > > asks us to "stay in idle pattern". But if we never switched to it
> > > how can we stay in it? This still needs further clarificaiton.
> > 
> > HSW seems to require it also for SST, but yes for all other platforms
> > bspec only requires it for MST.
> 
> commit 3ab9c63705cb ("drm/i915: hsw: fix link training for eDP on
> port-A") (written by you it seems :) says there was some problem on
> HSW that needed it for DDI A SST as well. But it's not really obvious
> why you skipped the IDLE_DONE thing there. Maybe just an optimization?

Ok, forgot about that. Looking back at the discussion the problem on HSW
was that switching from sending idle patterns to normal mode didn't
happen automatically due to some HW problem. The workaround was to to
switch to idle patterns and enable normal mode manually after the pipe
is enabled. The WA didn't require waiting for IDLE_DONE, but before
TGL there is no DP_TP_STATUS register on port A either.

> Anyways, that does suggest that perhaps the current code is more
> correct than what I'm proposing here.
> 
> > The DP2.1 standard has some addition
> > (3.5.1.2.6) referring to idle pattern to be sent after TPS even for SST.
> > Not sure if this would be done automatically by HW w/o manually
> > switching to it.
> 
> I did at some point spot some DP state machine status bits in some
> debug register. If I get bored I might see if I can spot the idle
> pattern transmission on those when we don't explicitly enable it.

Ok, the above suggests that it should work automatically, except when
the WA is needed.

> 
> -- 
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Include timeline seqno in error capture

[Teres Alexis, Alan Previn]

On Wed, 2023-03-08 at 14:02 -0800, Teres Alexis, Alan Previn wrote:
> On Thu, 2023-02-16 at 18:24 -0800, john.c.harri...@intel.com wrote:
> > From: John Harrison 
> > 
> > The seqno value actually written out to memory is no longer in the
> > regular HWSP. Instead, it is now in its own private timeline buffer.
> > Thus, it is no longer visible in an error capture. So, explicitly read
> > the value and include that in the capture.
> > 
> > Signed-off-by: John Harrison 
> alan: snip.
> 
> simple one ... LGTM
> Reviewed-by: Alan Previn 

alan: i just realized i missed something. On the following hunk,
seqno printout should be using a %u format specifier since we could use the 
upper most bit of that 32 bit value:
Consider above a conditional RB (based on this fix) - sorry about that.

@@ -505,6 +505,7 @@  static void error_print_context(struct 
drm_i915_error_state_buf *m,
   header, ctx->comm, ctx->pid, ctx->sched_attr.priority,
   ctx->guilty, ctx->active,
   ctx->total_runtime, ctx->avg_runtime);
+   err_printf(m, "  context timeline seqno %d\n", ctx->hwsp_seqno);

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup 
during system resume on platforms without display
URL   : https://patchwork.freedesktop.org/series/114866/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114866v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 35)
--

  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][3] -> [ABORT][4] ([i915#7911] / [i915#7913])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

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

  * igt@i915_selftest@live@migrate:
- bat-adlp-9: [PASS][7] -> [DMESG-FAIL][8] ([i915#7699])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/bat-adlp-9/igt@i915_selftest@l...@migrate.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/bat-adlp-9/igt@i915_selftest@l...@migrate.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][9] ([i915#7828])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.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_114866v1/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-hdmi-a-3:
- bat-dg2-11: [PASS][11] -> [INCOMPLETE][12] ([i915#7908])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-3.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-3.html

  
 Possible fixes 

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

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

  
 Warnings 

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: [DMESG-FAIL][17] ([i915#6367] / [i915#7913]) -> 
[DMESG-FAIL][18] ([i915#6367] / [i915#7913] / [i915#7996])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/bat-rpls-2/igt@i915_selftest@l...@slpc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
- bat-rpls-1: [DMESG-FAIL][19] ([i915#6367]) -> [DMESG-FAIL][20] 
([i915#6367] / [i915#7996])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/bat-rpls-1/igt@i915_selftest@l...@slpc.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114866v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7872]: 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.

[Ville Syrjälä]

On Wed, Mar 08, 2023 at 11:58:58AM -0500, Rodrigo Vivi wrote:
> uncore->lock only protects the forcewake domain itself,
> not the register accesses.
> 
> uncore's _fw alternatives are for cases where the domains
> are not needed because we are sure that they are already
> awake.
> 
> So the move towards the uncore's _fw alternatives seems
> right, however using the uncore-lock to protect the dsparb
> registers seems an abuse of the uncore-lock.
> 
> Let's restore the previous individual lock and try to get
> rid of the direct uncore accesses from the display code.
> 
> Cc: Ville Syrjälä 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
>  drivers/gpu/drm/i915/display/intel_display_core.h |  3 +++
>  drivers/gpu/drm/i915/i915_driver.c|  1 +
>  3 files changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c 
> b/drivers/gpu/drm/i915/display/i9xx_wm.c
> index caef72d38798..8fe0b5c63d3a 100644
> --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> @@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct 
> intel_atomic_state *state,
>  
>   trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
>  
> - /*
> -  * uncore.lock serves a double purpose here. It allows us to
> -  * use the less expensive I915_{READ,WRITE}_FW() functions, and
> -  * it protects the DSPARB registers from getting clobbered by
> -  * parallel updates from multiple pipes.
> -  *
> -  * intel_pipe_update_start() has already disabled interrupts
> -  * for us, so a plain spin_lock() is sufficient here.
> -  */

I was wondering if we need to preserve the comment about irqs,
but since this is the only place using this lock, and it's never
called from an irq handler a non-irq disabling spinlock will suffice
anyway.

Reviewed-by: Ville Syrjälä 

> - spin_lock(>lock);
> + spin_lock(_priv->display.wm.dsparb_lock);
>  
>   switch (crtc->pipe) {
>   case PIPE_A:
> @@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct 
> intel_atomic_state *state,
>  
>   intel_uncore_posting_read_fw(uncore, DSPARB);
>  
> - spin_unlock(>lock);
> + spin_unlock(_priv->display.wm.dsparb_lock);
>  }
>  
>  #undef VLV_FIFO
> diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
> b/drivers/gpu/drm/i915/display/intel_display_core.h
> index fdab7bb93a7d..68c6bfb91dbe 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> @@ -253,6 +253,9 @@ struct intel_wm {
>*/
>   struct mutex wm_mutex;
>  
> + /* protects DSPARB registers on pre-g4x/vlv/chv */
> + spinlock_t dsparb_lock;
> +
>   bool ipc_enabled;
>  };
>  
> diff --git a/drivers/gpu/drm/i915/i915_driver.c 
> b/drivers/gpu/drm/i915/i915_driver.c
> index a53fd339e2cc..c78e36444a12 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct 
> drm_i915_private *dev_priv)
>   mutex_init(_priv->display.pps.mutex);
>   mutex_init(_priv->display.hdcp.comp_mutex);
>   spin_lock_init(_priv->display.dkl.phy_lock);
> + spin_lock_init(_priv->display.wm.dsparb_lock);
>  
>   i915_memcpy_init_early(dev_priv);
>   intel_runtime_pm_init_early(_priv->runtime_pm);
> -- 
> 2.39.2

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Include timeline seqno in error capture

[Teres Alexis, Alan Previn]

On Thu, 2023-02-16 at 18:24 -0800, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> The seqno value actually written out to memory is no longer in the
> regular HWSP. Instead, it is now in its own private timeline buffer.
> Thus, it is no longer visible in an error capture. So, explicitly read
> the value and include that in the capture.
> 
> Signed-off-by: John Harrison 
alan: snip.

simple one ... LGTM
Reviewed-by: Alan Previn 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore.

[Ville Syrjälä]

On Wed, Mar 08, 2023 at 08:18:52PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 08, 2023 at 12:56:28PM -0500, Rodrigo Vivi wrote:
> > On Wed, Mar 08, 2023 at 07:50:27PM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 08, 2023 at 11:58:59AM -0500, Rodrigo Vivi wrote:
> > > > } else if (IS_I915GM(dev_priv)) {
> > > > /*
> > > >  * FIXME can't find a bit like this for 915G, and
> > > >  * yet it does have the related watermark in
> > > >  * FW_BLC_SELF. What's going on?
> > > >  */
> > > > -   was_enabled = intel_uncore_read(_priv->uncore, 
> > > > INSTPM) & INSTPM_SELF_EN;
> > > > +   was_enabled = intel_de_read(dev_priv, INSTPM) & 
> > > > INSTPM_SELF_EN;
> > > > val = enable ? _MASKED_BIT_ENABLE(INSTPM_SELF_EN) :
> > > >_MASKED_BIT_DISABLE(INSTPM_SELF_EN);
> > > > -   intel_uncore_write(_priv->uncore, INSTPM, val);
> > > > -   intel_uncore_posting_read(_priv->uncore, INSTPM);
> > > > +   intel_de_write(dev_priv, INSTPM, val);
> > > > +   intel_de_posting_read(dev_priv, INSTPM);
> > > 
> > > I'm still not really convinced that we want to
> > > use intel_de_*() for non-display registers.
> > 
> > hmmm... I see...
> > so should we create a new component out of i915/display and move
> > these calls there?
> > 
> > but in the end of the day it is the same uncore functions that
> > are getting calling underneath anyway, right?!
> 
> Currently yes. Though I have occasionally thought about
> splitting it up lower down, since no display registers need
> forcewake, and IIRC the RM unclaimed stuff only really works
> for display registers. So we could perhaps lighten each
> side a bit by knowing ahead of time what kind of register
> we're dealing with.
> 
> > 
> > I believe i915/display should only call intel_de for mmio, so it
> > gets easier on the code reuse on Xe.
> 
> Yeah, I get idea. However I think it might also be nice 
> to check that we are not touching registers that we're
> not supposed to touch from the display code. So having
> intel_de*() validate the register offset might be nice.
> Would be especially important if we did do the lower
> level register accessor split.
> 
> Though admittedly on these old platforms that valiation
> is perhaps a bit moot since the display vs. not split
> is far from clear, and even the truly dedicated display
> registers can live at rather weird offsets.

I guess we can always backpedal a bit if we do decide
to do those things. There shouldn't be that many non-display
registers in the mix anyway.

Reviewed-by: Ville Syrjälä 

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup 
during system resume on platforms without display
URL   : https://patchwork.freedesktop.org/series/114866/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix idle pattern enabling

[Ville Syrjälä]

On Thu, Mar 02, 2023 at 09:03:42PM +0200, Imre Deak wrote:
> On Tue, Feb 14, 2023 at 03:43:48PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Currently we are always switching to the idle pattern after the
> > link training, but we don't always wait for the minimum number
> > of idle patterns sent. That doesn't look to be what Bspec
> > asks of us.
> > 
> > According to bspec what we should do is switch to idle pattern
> > and wait for it only in DP1.4 MST cases. In all other cases we
> > should apparently do neither.
> > 
> > What confuses matters further is that the port sync SST sequence
> > asks us to "stay in idle pattern". But if we never switched to it
> > how can we stay in it? This still needs further clarificaiton.
> 
> HSW seems to require it also for SST, but yes for all other platforms
> bspec only requires it for MST.

commit 3ab9c63705cb ("drm/i915: hsw: fix link training for eDP on
port-A") (written by you it seems :) says there was some problem on
HSW that needed it for DDI A SST as well. But it's not really obvious
why you skipped the IDLE_DONE thing there. Maybe just an optimization?

Anyways, that does suggest that perhaps the current code is more
correct than what I'm proposing here.

> The DP2.1 standard has some addition
> (3.5.1.2.6) referring to idle pattern to be sent after TPS even for SST.
> Not sure if this would be done automatically by HW w/o manually
> switching to it.

I did at some point spot some DP state machine status bits in some
debug register. If I get bored I might see if I can spot the idle
pattern transmission on those when we don't explicitly enable it.

-- 
Ville Syrjälä
Intel

[Intel-gfx] [PATCH v2 1/2] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL

[Ville Syrjala]

From: Ville Syrjälä 

AFAICS Bspec has never asked us to switch to TPS1 when *disabling*
DP_TP_CTL. Let's stop doing that in case it confuses something.
We do have to switch before we *enable* DP_TP_CTL, but that
is already being handled correctly.

v2: Do the same for FDI
v3: Rebase

Reviewed-by: Imre Deak  #v1
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++
 drivers/gpu/drm/i915/display/intel_fdi.c | 4 +---
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 0950bcfea4c0..c531fee888a4 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2618,8 +2618,7 @@ static void intel_disable_ddi_buf(struct intel_encoder 
*encoder,
 
if (intel_crtc_has_dp_encoder(crtc_state))
intel_de_rmw(dev_priv, dp_tp_ctl_reg(encoder, crtc_state),
-DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK,
-DP_TP_CTL_LINK_TRAIN_PAT1);
+DP_TP_CTL_ENABLE, 0);
 
/* Disable FEC in DP Sink */
intel_ddi_disable_fec_state(encoder, crtc_state);
@@ -3140,8 +3139,7 @@ static void intel_ddi_prepare_link_retrain(struct 
intel_dp *intel_dp,
wait = true;
}
 
-   dp_tp_ctl &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
-   dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT1;
+   dp_tp_ctl &= ~DP_TP_CTL_ENABLE;
intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), 
dp_tp_ctl);
intel_de_posting_read(dev_priv, dp_tp_ctl_reg(encoder, 
crtc_state));
 
diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c 
b/drivers/gpu/drm/i915/display/intel_fdi.c
index f55b4893c00f..c08c26a321b3 100644
--- a/drivers/gpu/drm/i915/display/intel_fdi.c
+++ b/drivers/gpu/drm/i915/display/intel_fdi.c
@@ -845,9 +845,7 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
intel_de_posting_read(dev_priv, DDI_BUF_CTL(PORT_E));
 
/* Disable DP_TP_CTL and FDI_RX_CTL and retry */
-   intel_de_rmw(dev_priv, DP_TP_CTL(PORT_E),
-DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK,
-DP_TP_CTL_LINK_TRAIN_PAT1);
+   intel_de_rmw(dev_priv, DP_TP_CTL(PORT_E), DP_TP_CTL_ENABLE, 0);
intel_de_posting_read(dev_priv, DP_TP_CTL(PORT_E));
 
intel_wait_ddi_buf_idle(dev_priv, PORT_E);
-- 
2.39.2

[Intel-gfx] [PATCH v2 2/2] drm/i915: Don't send idle pattern after DP2.0 link training

[Ville Syrjala]

From: Ville Syrjälä 

Bspec calls us to select pattern 2 after link training for
DP 2.0. Let's do that... by doing nothing because we will
be transmitting pattern 2 at the end of the link training
already.

Reviewed-by: Imre Deak 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp_link_training.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 3d3efcf02011..b35af21a2761 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -1379,10 +1379,6 @@ intel_dp_128b132b_lane_cds(struct intel_dp *intel_dp,
}
}
 
-   /* FIXME: Should DP_TRAINING_PATTERN_DISABLE be written first? */
-   if (intel_dp->set_idle_link_train)
-   intel_dp->set_idle_link_train(intel_dp, crtc_state);
-
return true;
 }
 
-- 
2.39.2

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/debugfs: move IPS debugfs to hsw_ips.c (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/debugfs: move IPS debugfs to hsw_ips.c (rev4)
URL   : https://patchwork.freedesktop.org/series/114578/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114578v4


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 36)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@eof:
- bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/bat-atsm-1/igt@fb...@eof.html

  * igt@gem_mmap@basic:
- bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/bat-atsm-1/igt@gem_m...@basic.html

  * igt@gem_sync@basic-each:
- bat-atsm-1: NOTRUN -> [FAIL][3] ([i915#8062]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/bat-atsm-1/igt@gem_s...@basic-each.html

  * igt@gem_tiled_fence_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/bat-atsm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_hangman@error-state-basic:
- bat-atsm-1: NOTRUN -> [ABORT][6] ([i915#8060])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/bat-atsm-1/igt@i915_hang...@error-state-basic.html

  * igt@i915_selftest@live@migrate:
- bat-adlp-9: [PASS][7] -> [DMESG-FAIL][8] ([i915#7699])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/bat-adlp-9/igt@i915_selftest@l...@migrate.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/bat-adlp-9/igt@i915_selftest@l...@migrate.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#5354]) +2 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114578v4/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  
 Possible fixes 

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

  
 Warnings 

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

  
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [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#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
  [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
  [i915#8060]: https://gitlab.freedesktop.org/drm/intel/issues/8060
  [i915#8062]: https://gitlab.freedesktop.org/drm/intel/issues/8062


Build changes
-

  * Linux: CI_DRM_12829 -> Patchwork_114578v4

  CI-20190529: 20190529
  CI_DRM_12829: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7185: 6707461ddb214bb8a75c5fcf2747941c9d9b11ae @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_114578v4: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

4296f99e81eb drm/i915/debugfs: move IPS debugfs to hsw_ips.c

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add guard page to ggtt->error_capture (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915: add guard page to ggtt->error_capture (rev7)
URL   : https://patchwork.freedesktop.org/series/113560/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12829 -> Patchwork_113560v7


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 36)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@eof:
- bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/bat-atsm-1/igt@fb...@eof.html

  * igt@gem_mmap@basic:
- bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/bat-atsm-1/igt@gem_m...@basic.html

  * igt@gem_sync@basic-each:
- bat-atsm-1: NOTRUN -> [FAIL][3] ([i915#8062]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/bat-atsm-1/igt@gem_s...@basic-each.html

  * igt@gem_tiled_fence_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/bat-atsm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_hangman@error-state-basic:
- bat-atsm-1: NOTRUN -> [ABORT][6] ([i915#8060])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/bat-atsm-1/igt@i915_hang...@error-state-basic.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-7567u:   [PASS][7] -> [DMESG-FAIL][8] ([i915#5334] / 
[i915#7872])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][9] -> [DMESG-WARN][10] ([i915#7699])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/bat-dg2-11/igt@i915_selftest@l...@migrate.html

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

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][13] ([i915#5354]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v7/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  
 Possible fixes 

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

  
 Warnings 

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

  
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [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#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
  [i915#8060]: https://gitlab.freedesktop.org/drm/intel/issues/8060
  

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [RFC,1/2] drm/i915: Add a function to mmap framebuffer obj

[Patchwork]

== Series Details ==

Series: series starting with [RFC,1/2] drm/i915: Add a function to mmap 
framebuffer obj
URL   : https://patchwork.freedesktop.org/series/114775/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12821_full -> Patchwork_114775v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@fbdev@pan:
- {shard-dg1}:[PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12821/shard-dg1-12/igt@fb...@pan.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-dg1-16/igt@fb...@pan.html

  
New tests
-

  New tests have been introduced between CI_DRM_12821_full and 
Patchwork_114775v1_full:

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

  * igt@fbdev:
- Statuses :
- Exec time: [None] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@device_reset@unbind-cold-reset-rebind:
- shard-tglu-10:  NOTRUN -> [SKIP][3] ([i915#7701])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@device_re...@unbind-cold-reset-rebind.html

  * igt@gem_ccs@block-copy-compressed:
- shard-tglu-10:  NOTRUN -> [SKIP][4] ([i915#3555] / [i915#5325])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@gem_...@block-copy-compressed.html

  * igt@gem_ccs@block-multicopy-compressed:
- shard-tglu-10:  NOTRUN -> [SKIP][5] ([i915#5325])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@gem_...@block-multicopy-compressed.html

  * igt@gem_close_race@multigpu-basic-threads:
- shard-tglu-10:  NOTRUN -> [SKIP][6] ([i915#7697])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@gem_close_r...@multigpu-basic-threads.html

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-tglu-10:  NOTRUN -> [SKIP][7] ([fdo#109314])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_exec_capture@capture-invisible@smem0:
- shard-tglu-10:  NOTRUN -> [SKIP][8] ([i915#6334])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@gem_exec_capture@capture-invisi...@smem0.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12821/shard-apl2/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-tglu-10:  NOTRUN -> [FAIL][11] ([i915#2842]) +5 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@gem_exec_fair@basic-n...@rcs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-tglu-10:  NOTRUN -> [SKIP][12] ([fdo#109313])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_exec_params@secure-non-root:
- shard-tglu-10:  NOTRUN -> [SKIP][13] ([fdo#112283])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@gem_exec_par...@secure-non-root.html

  * igt@gem_lmem_evict@dontneed-evict-race:
- shard-tglu-10:  NOTRUN -> [SKIP][14] ([i915#7582])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@gem_lmem_ev...@dontneed-evict-race.html

  * igt@gem_lmem_swapping@heavy-verify-multi:
- shard-apl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-apl4/igt@gem_lmem_swapp...@heavy-verify-multi.html

  * igt@gem_lmem_swapping@random:
- shard-tglu-10:  NOTRUN -> [SKIP][16] ([i915#4613]) +7 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@gem_lmem_swapp...@random.html

  * igt@gem_media_vme:
- shard-tglu-10:  NOTRUN -> [SKIP][17] ([i915#284])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/shard-tglu-10/igt@gem_media_vme.html

  * igt@gem_mmap_gtt@coherency:
- shard-tglu-10:  NOTRUN -> [SKIP][18] ([fdo#111656])
   [18]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for MAINTAINERS: update the 01.org website entries

[Patchwork]

== Series Details ==

Series: MAINTAINERS: update the 01.org website entries
URL   : https://patchwork.freedesktop.org/series/114854/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114854v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 35)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@eof:
- bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114854v1/bat-atsm-1/igt@fb...@eof.html

  * igt@gem_mmap@basic:
- bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114854v1/bat-atsm-1/igt@gem_m...@basic.html

  * igt@gem_sync@basic-each:
- bat-atsm-1: NOTRUN -> [FAIL][3] ([i915#8062]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114854v1/bat-atsm-1/igt@gem_s...@basic-each.html

  * igt@gem_tiled_fence_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114854v1/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114854v1/bat-atsm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_hangman@error-state-basic:
- bat-atsm-1: NOTRUN -> [ABORT][6] ([i915#8060])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114854v1/bat-atsm-1/igt@i915_hang...@error-state-basic.html

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

  
 Warnings 

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: [DMESG-FAIL][9] ([i915#6367] / [i915#7913]) -> 
[DMESG-FAIL][10] ([i915#6997] / [i915#7913])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12829/bat-rpls-2/igt@i915_selftest@l...@slpc.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114854v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [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#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7694]: https://gitlab.freedesktop.org/drm/intel/issues/7694
  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#8060]: https://gitlab.freedesktop.org/drm/intel/issues/8060
  [i915#8062]: https://gitlab.freedesktop.org/drm/intel/issues/8062


Build changes
-

  * Linux: CI_DRM_12829 -> Patchwork_114854v1

  CI-20190529: 20190529
  CI_DRM_12829: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7185: 6707461ddb214bb8a75c5fcf2747941c9d9b11ae @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_114854v1: d947159409deea43f404f35cc758740c714c @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

ec8d1b64ee3c MAINTAINERS: update the 01.org website entries

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore.

[Ville Syrjälä]

On Wed, Mar 08, 2023 at 12:56:28PM -0500, Rodrigo Vivi wrote:
> On Wed, Mar 08, 2023 at 07:50:27PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 08, 2023 at 11:58:59AM -0500, Rodrigo Vivi wrote:
> > >   } else if (IS_I915GM(dev_priv)) {
> > >   /*
> > >* FIXME can't find a bit like this for 915G, and
> > >* yet it does have the related watermark in
> > >* FW_BLC_SELF. What's going on?
> > >*/
> > > - was_enabled = intel_uncore_read(_priv->uncore, INSTPM) & 
> > > INSTPM_SELF_EN;
> > > + was_enabled = intel_de_read(dev_priv, INSTPM) & INSTPM_SELF_EN;
> > >   val = enable ? _MASKED_BIT_ENABLE(INSTPM_SELF_EN) :
> > >  _MASKED_BIT_DISABLE(INSTPM_SELF_EN);
> > > - intel_uncore_write(_priv->uncore, INSTPM, val);
> > > - intel_uncore_posting_read(_priv->uncore, INSTPM);
> > > + intel_de_write(dev_priv, INSTPM, val);
> > > + intel_de_posting_read(dev_priv, INSTPM);
> > 
> > I'm still not really convinced that we want to
> > use intel_de_*() for non-display registers.
> 
> hmmm... I see...
> so should we create a new component out of i915/display and move
> these calls there?
> 
> but in the end of the day it is the same uncore functions that
> are getting calling underneath anyway, right?!

Currently yes. Though I have occasionally thought about
splitting it up lower down, since no display registers need
forcewake, and IIRC the RM unclaimed stuff only really works
for display registers. So we could perhaps lighten each
side a bit by knowing ahead of time what kind of register
we're dealing with.

> 
> I believe i915/display should only call intel_de for mmio, so it
> gets easier on the code reuse on Xe.

Yeah, I get idea. However I think it might also be nice 
to check that we are not touching registers that we're
not supposed to touch from the display code. So having
intel_de*() validate the register offset might be nice.
Would be especially important if we did do the lower
level register accessor split.

Though admittedly on these old platforms that valiation
is perhaps a bit moot since the display vs. not split
is far from clear, and even the truly dedicated display
registers can live at rather weird offsets.

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v4 8/9] drm/i915/perf: Add engine class instance parameters to perf

[Dixit, Ashutosh]

On Tue, 07 Mar 2023 12:16:10 -0800, Umesh Nerlige Ramappa wrote:
>

Hi Umesh,

> One or more engines map to a specific OA unit. All reports from these
> engines are captured in the OA buffer managed by this OA unit.
>
> Current i915 OA implementation supports only the OAG unit. OAG primarily
> caters to render engine, so i915 OA uses render as the default engine
> in the OA implementation. Since there are more OA units on newer
> hardware that map to other engines, allow user to pass engine class and
> instance to select and program specific OA units.

I believe there is another uapi issue to be resolved here: how the engines
are associated with OA units, since from the point of view of the uapi
there are multiple engines and multiple OA units (even if in the actual
implementation at present there is only one OA unit per gt). In the
internal tree we had added oa_unit_id to engine_info for this. So if
multiple engines had the same oa_unit_id, user could pass class:instance of
any of those engines to get oa data from that OA unit (and generally know
how engines are hooked up to OA units (the OA unit topology)).

So the question is even if we don't implement it as part of this series (or
do we have to?) do we at least need to agree to that uapi which will be
used to associate OA units with engines?

Thanks.
--
Ashutosh

Re: [Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore.

[Rodrigo Vivi]

On Wed, Mar 08, 2023 at 07:50:27PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 08, 2023 at 11:58:59AM -0500, Rodrigo Vivi wrote:
> > } else if (IS_I915GM(dev_priv)) {
> > /*
> >  * FIXME can't find a bit like this for 915G, and
> >  * yet it does have the related watermark in
> >  * FW_BLC_SELF. What's going on?
> >  */
> > -   was_enabled = intel_uncore_read(_priv->uncore, INSTPM) & 
> > INSTPM_SELF_EN;
> > +   was_enabled = intel_de_read(dev_priv, INSTPM) & INSTPM_SELF_EN;
> > val = enable ? _MASKED_BIT_ENABLE(INSTPM_SELF_EN) :
> >_MASKED_BIT_DISABLE(INSTPM_SELF_EN);
> > -   intel_uncore_write(_priv->uncore, INSTPM, val);
> > -   intel_uncore_posting_read(_priv->uncore, INSTPM);
> > +   intel_de_write(dev_priv, INSTPM, val);
> > +   intel_de_posting_read(dev_priv, INSTPM);
> 
> I'm still not really convinced that we want to
> use intel_de_*() for non-display registers.

hmmm... I see...
so should we create a new component out of i915/display and move
these calls there?

but in the end of the day it is the same uncore functions that
are getting calling underneath anyway, right?!

I believe i915/display should only call intel_de for mmio, so it
gets easier on the code reuse on Xe.

> 
> -- 
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore.

[Ville Syrjälä]

On Wed, Mar 08, 2023 at 11:58:59AM -0500, Rodrigo Vivi wrote:
>   } else if (IS_I915GM(dev_priv)) {
>   /*
>* FIXME can't find a bit like this for 915G, and
>* yet it does have the related watermark in
>* FW_BLC_SELF. What's going on?
>*/
> - was_enabled = intel_uncore_read(_priv->uncore, INSTPM) & 
> INSTPM_SELF_EN;
> + was_enabled = intel_de_read(dev_priv, INSTPM) & INSTPM_SELF_EN;
>   val = enable ? _MASKED_BIT_ENABLE(INSTPM_SELF_EN) :
>  _MASKED_BIT_DISABLE(INSTPM_SELF_EN);
> - intel_uncore_write(_priv->uncore, INSTPM, val);
> - intel_uncore_posting_read(_priv->uncore, INSTPM);
> + intel_de_write(dev_priv, INSTPM, val);
> + intel_de_posting_read(dev_priv, INSTPM);

I'm still not really convinced that we want to
use intel_de_*() for non-display registers.

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: prevent forcewake releases during BAR resize

[Rodrigo Vivi]

On Wed, Mar 08, 2023 at 02:36:24PM +0100, Andrzej Hajda wrote:
> Tests on DG2 machines show that releasing forcewakes during BAR resize
> results later in forcewake ack timeouts. Since forcewakes can be realeased
> asynchronously the simplest way to prevent it is to get all forcewakes
> for duration of BAR resizing.
> 
> v2: hold rpm as well during resizing (Rodrigo)

oh, I really dislike this with_rpm... a get and put directly would
end up with a much clear patch... :/

but anyway:

Reviewed-by: Rodrigo Vivi 


> 
> Signed-off-by: Andrzej Hajda 
> ---
> Please ignore resend of v1, my mistake.
> 
> Regards
> Andrzej
> ---
>  drivers/gpu/drm/i915/gt/intel_region_lmem.c | 25 +++--
>  1 file changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
> b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> index 89fdfc67f8d1e0..2a3217e2890fc7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> +++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> @@ -54,6 +54,7 @@ static void i915_resize_lmem_bar(struct drm_i915_private 
> *i915, resource_size_t
>   struct resource *root_res;
>   resource_size_t rebar_size;
>   resource_size_t current_size;
> + intel_wakeref_t wakeref;
>   u32 pci_cmd;
>   int i;
>  
> @@ -102,15 +103,25 @@ static void i915_resize_lmem_bar(struct 
> drm_i915_private *i915, resource_size_t
>   return;
>   }
>  
> - /* First disable PCI memory decoding references */
> - pci_read_config_dword(pdev, PCI_COMMAND, _cmd);
> - pci_write_config_dword(pdev, PCI_COMMAND,
> -pci_cmd & ~PCI_COMMAND_MEMORY);
> + /*
> +  * Releasing forcewake during BAR resizing results in later forcewake
> +  * ack timeouts and former can happen any time - it is asynchronous.
> +  * Grabbing all forcewakes prevents it.
> +  */
> + with_intel_runtime_pm(i915->uncore.rpm, wakeref) {
> + intel_uncore_forcewake_get(>uncore, FORCEWAKE_ALL);
>  
> - _resize_bar(i915, GEN12_LMEM_BAR, rebar_size);
> + /* First disable PCI memory decoding references */
> + pci_read_config_dword(pdev, PCI_COMMAND, _cmd);
> + pci_write_config_dword(pdev, PCI_COMMAND,
> +pci_cmd & ~PCI_COMMAND_MEMORY);
>  
> - pci_assign_unassigned_bus_resources(pdev->bus);
> - pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
> + _resize_bar(i915, GEN12_LMEM_BAR, rebar_size);
> +
> + pci_assign_unassigned_bus_resources(pdev->bus);
> + pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
> + intel_uncore_forcewake_put(>uncore, FORCEWAKE_ALL);
> + }
>  }
>  #else
>  static void i915_resize_lmem_bar(struct drm_i915_private *i915, 
> resource_size_t lmem_size) {}
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: prevent forcewake releases during BAR resize

[Das, Nirmoy]

On 3/8/2023 2:36 PM, Andrzej Hajda wrote:

Tests on DG2 machines show that releasing forcewakes during BAR resize
results later in forcewake ack timeouts.
Do we have a fdo/issues url for that? Having that as References would be 
nice.

  Since forcewakes can be realeased
asynchronously the simplest way to prevent it is to get all forcewakes
for duration of BAR resizing.

v2: hold rpm as well during resizing (Rodrigo)

Signed-off-by: Andrzej Hajda 



Acked-by: Nirmoy Das 



---
Please ignore resend of v1, my mistake.

Regards
Andrzej
---
  drivers/gpu/drm/i915/gt/intel_region_lmem.c | 25 +++--
  1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 89fdfc67f8d1e0..2a3217e2890fc7 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -54,6 +54,7 @@ static void i915_resize_lmem_bar(struct drm_i915_private 
*i915, resource_size_t
struct resource *root_res;
resource_size_t rebar_size;
resource_size_t current_size;
+   intel_wakeref_t wakeref;
u32 pci_cmd;
int i;
  
@@ -102,15 +103,25 @@ static void i915_resize_lmem_bar(struct drm_i915_private *i915, resource_size_t

return;
}
  
-	/* First disable PCI memory decoding references */

-   pci_read_config_dword(pdev, PCI_COMMAND, _cmd);
-   pci_write_config_dword(pdev, PCI_COMMAND,
-  pci_cmd & ~PCI_COMMAND_MEMORY);
+   /*
+* Releasing forcewake during BAR resizing results in later forcewake
+* ack timeouts and former can happen any time - it is asynchronous.
+* Grabbing all forcewakes prevents it.
+*/
+   with_intel_runtime_pm(i915->uncore.rpm, wakeref) {
+   intel_uncore_forcewake_get(>uncore, FORCEWAKE_ALL);
  
-	_resize_bar(i915, GEN12_LMEM_BAR, rebar_size);

+   /* First disable PCI memory decoding references */
+   pci_read_config_dword(pdev, PCI_COMMAND, _cmd);
+   pci_write_config_dword(pdev, PCI_COMMAND,
+  pci_cmd & ~PCI_COMMAND_MEMORY);
  
-	pci_assign_unassigned_bus_resources(pdev->bus);

-   pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
+   _resize_bar(i915, GEN12_LMEM_BAR, rebar_size);
+
+   pci_assign_unassigned_bus_resources(pdev->bus);
+   pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
+   intel_uncore_forcewake_put(>uncore, FORCEWAKE_ALL);
+   }
  }
  #else
  static void i915_resize_lmem_bar(struct drm_i915_private *i915, 
resource_size_t lmem_size) {}

[Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.

[Rodrigo Vivi]

uncore->lock only protects the forcewake domain itself,
not the register accesses.

uncore's _fw alternatives are for cases where the domains
are not needed because we are sure that they are already
awake.

So the move towards the uncore's _fw alternatives seems
right, however using the uncore-lock to protect the dsparb
registers seems an abuse of the uncore-lock.

Let's restore the previous individual lock and try to get
rid of the direct uncore accesses from the display code.

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
 drivers/gpu/drm/i915/display/intel_display_core.h |  3 +++
 drivers/gpu/drm/i915/i915_driver.c|  1 +
 3 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c 
b/drivers/gpu/drm/i915/display/i9xx_wm.c
index caef72d38798..8fe0b5c63d3a 100644
--- a/drivers/gpu/drm/i915/display/i9xx_wm.c
+++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
@@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct 
intel_atomic_state *state,
 
trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
 
-   /*
-* uncore.lock serves a double purpose here. It allows us to
-* use the less expensive I915_{READ,WRITE}_FW() functions, and
-* it protects the DSPARB registers from getting clobbered by
-* parallel updates from multiple pipes.
-*
-* intel_pipe_update_start() has already disabled interrupts
-* for us, so a plain spin_lock() is sufficient here.
-*/
-   spin_lock(>lock);
+   spin_lock(_priv->display.wm.dsparb_lock);
 
switch (crtc->pipe) {
case PIPE_A:
@@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct 
intel_atomic_state *state,
 
intel_uncore_posting_read_fw(uncore, DSPARB);
 
-   spin_unlock(>lock);
+   spin_unlock(_priv->display.wm.dsparb_lock);
 }
 
 #undef VLV_FIFO
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index fdab7bb93a7d..68c6bfb91dbe 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -253,6 +253,9 @@ struct intel_wm {
 */
struct mutex wm_mutex;
 
+   /* protects DSPARB registers on pre-g4x/vlv/chv */
+   spinlock_t dsparb_lock;
+
bool ipc_enabled;
 };
 
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index a53fd339e2cc..c78e36444a12 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct drm_i915_private 
*dev_priv)
mutex_init(_priv->display.pps.mutex);
mutex_init(_priv->display.hdcp.comp_mutex);
spin_lock_init(_priv->display.dkl.phy_lock);
+   spin_lock_init(_priv->display.wm.dsparb_lock);
 
i915_memcpy_init_early(dev_priv);
intel_runtime_pm_init_early(_priv->runtime_pm);
-- 
2.39.2

[Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore.

[Rodrigo Vivi]

Let's get rid of the intel_uncore calls on display side.

Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/display/i9xx_wm.c  | 238 
 drivers/gpu/drm/i915/display/intel_de.h |  12 ++
 2 files changed, 131 insertions(+), 119 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c 
b/drivers/gpu/drm/i915/display/i9xx_wm.c
index 8fe0b5c63d3a..28a9a920a2bc 100644
--- a/drivers/gpu/drm/i915/display/i9xx_wm.c
+++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
@@ -6,6 +6,7 @@
 #include "i915_drv.h"
 #include "i9xx_wm.h"
 #include "intel_atomic.h"
+#include "intel_de.h"
 #include "intel_display.h"
 #include "intel_display_trace.h"
 #include "intel_mchbar_regs.h"
@@ -141,39 +142,39 @@ static bool _intel_set_memory_cxsr(struct 
drm_i915_private *dev_priv, bool enabl
u32 val;
 
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
-   was_enabled = intel_uncore_read(_priv->uncore, 
FW_BLC_SELF_VLV) & FW_CSPWRDWNEN;
-   intel_uncore_write(_priv->uncore, FW_BLC_SELF_VLV, enable ? 
FW_CSPWRDWNEN : 0);
-   intel_uncore_posting_read(_priv->uncore, FW_BLC_SELF_VLV);
+   was_enabled = intel_de_read(dev_priv, FW_BLC_SELF_VLV) & 
FW_CSPWRDWNEN;
+   intel_de_write(dev_priv, FW_BLC_SELF_VLV, enable ? 
FW_CSPWRDWNEN : 0);
+   intel_de_posting_read(dev_priv, FW_BLC_SELF_VLV);
} else if (IS_G4X(dev_priv) || IS_I965GM(dev_priv)) {
-   was_enabled = intel_uncore_read(_priv->uncore, FW_BLC_SELF) 
& FW_BLC_SELF_EN;
-   intel_uncore_write(_priv->uncore, FW_BLC_SELF, enable ? 
FW_BLC_SELF_EN : 0);
-   intel_uncore_posting_read(_priv->uncore, FW_BLC_SELF);
+   was_enabled = intel_de_read(dev_priv, FW_BLC_SELF) & 
FW_BLC_SELF_EN;
+   intel_de_write(dev_priv, FW_BLC_SELF, enable ? FW_BLC_SELF_EN : 
0);
+   intel_de_posting_read(dev_priv, FW_BLC_SELF);
} else if (IS_PINEVIEW(dev_priv)) {
-   val = intel_uncore_read(_priv->uncore, DSPFW3);
+   val = intel_de_read(dev_priv, DSPFW3);
was_enabled = val & PINEVIEW_SELF_REFRESH_EN;
if (enable)
val |= PINEVIEW_SELF_REFRESH_EN;
else
val &= ~PINEVIEW_SELF_REFRESH_EN;
-   intel_uncore_write(_priv->uncore, DSPFW3, val);
-   intel_uncore_posting_read(_priv->uncore, DSPFW3);
+   intel_de_write(dev_priv, DSPFW3, val);
+   intel_de_posting_read(dev_priv, DSPFW3);
} else if (IS_I945G(dev_priv) || IS_I945GM(dev_priv)) {
-   was_enabled = intel_uncore_read(_priv->uncore, FW_BLC_SELF) 
& FW_BLC_SELF_EN;
+   was_enabled = intel_de_read(dev_priv, FW_BLC_SELF) & 
FW_BLC_SELF_EN;
val = enable ? _MASKED_BIT_ENABLE(FW_BLC_SELF_EN) :
   _MASKED_BIT_DISABLE(FW_BLC_SELF_EN);
-   intel_uncore_write(_priv->uncore, FW_BLC_SELF, val);
-   intel_uncore_posting_read(_priv->uncore, FW_BLC_SELF);
+   intel_de_write(dev_priv, FW_BLC_SELF, val);
+   intel_de_posting_read(dev_priv, FW_BLC_SELF);
} else if (IS_I915GM(dev_priv)) {
/*
 * FIXME can't find a bit like this for 915G, and
 * yet it does have the related watermark in
 * FW_BLC_SELF. What's going on?
 */
-   was_enabled = intel_uncore_read(_priv->uncore, INSTPM) & 
INSTPM_SELF_EN;
+   was_enabled = intel_de_read(dev_priv, INSTPM) & INSTPM_SELF_EN;
val = enable ? _MASKED_BIT_ENABLE(INSTPM_SELF_EN) :
   _MASKED_BIT_DISABLE(INSTPM_SELF_EN);
-   intel_uncore_write(_priv->uncore, INSTPM, val);
-   intel_uncore_posting_read(_priv->uncore, INSTPM);
+   intel_de_write(dev_priv, INSTPM, val);
+   intel_de_posting_read(dev_priv, INSTPM);
} else {
return false;
}
@@ -269,20 +270,20 @@ static void vlv_get_fifo_size(struct intel_crtc_state 
*crtc_state)
 
switch (pipe) {
case PIPE_A:
-   dsparb = intel_uncore_read(_priv->uncore, DSPARB);
-   dsparb2 = intel_uncore_read(_priv->uncore, DSPARB2);
+   dsparb = intel_de_read(dev_priv, DSPARB);
+   dsparb2 = intel_de_read(dev_priv, DSPARB2);
sprite0_start = VLV_FIFO_START(dsparb, dsparb2, 0, 0);
sprite1_start = VLV_FIFO_START(dsparb, dsparb2, 8, 4);
break;
case PIPE_B:
-   dsparb = intel_uncore_read(_priv->uncore, DSPARB);
-   dsparb2 = intel_uncore_read(_priv->uncore, DSPARB2);
+   dsparb = intel_de_read(dev_priv, DSPARB);
+   dsparb2 = intel_de_read(dev_priv, DSPARB2);
sprite0_start = VLV_FIFO_START(dsparb, 

Re: [Intel-gfx] [PATCH v2 06/10] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters

[Dmitry Baryshkov]

On Wed, 8 Mar 2023 at 15:19, Jani Nikula  wrote:
>
> On Wed, 08 Mar 2023, Dmitry Baryshkov  wrote:
> > On Wed, 8 Mar 2023 at 12:14, Jani Nikula  
> > wrote:
> >>
> >> On Tue, 07 Mar 2023, Dmitry Baryshkov  wrote:
> >> > The array of rc_parameters contains a mixture of parameters from DSC 1.1
> >> > and DSC 1.2 standards. Split these tow configuration arrays in
> >> > preparation to adding more configuration data.
> >> >
> >> > Signed-off-by: Dmitry Baryshkov 
> >> > ---
> >> >  drivers/gpu/drm/display/drm_dsc_helper.c  | 127 ++
> >> >  drivers/gpu/drm/i915/display/intel_vdsc.c |  10 +-
> >> >  include/drm/display/drm_dsc_helper.h  |   7 +-
> >> >  3 files changed, 119 insertions(+), 25 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
> >> > b/drivers/gpu/drm/display/drm_dsc_helper.c
> >> > index acb93d4116e0..35b39f3109c4 100644
> >> > --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> >> > +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> >> > @@ -324,11 +324,81 @@ struct rc_parameters_data {
> >> >
> >> >  #define DSC_BPP(bpp) ((bpp) << 4)
> >> >
> >> > +static const struct rc_parameters_data rc_parameters_pre_scr[] = {
> >> > + {
> >> > + .bpp = DSC_BPP(8), .bpc = 8,
> >> > + { 512, 12, 6144, 3, 12, 11, 11, {
> >> > + { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 
> >> > },
> >> > + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, 
> >> > -8 },
> >> > + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 
> >> > 12, -12 },
> >> > + { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
> >> > + }
> >> > + }
> >> > + },
> >> > + {
> >> > + .bpp = DSC_BPP(8), .bpc = 10,
> >> > + { 512, 12, 6144, 7, 16, 15, 15, {
> >> > + /*
> >> > +  * DSC model/pre-SCR-cfg has 8 for 
> >> > range_max_qp[0], however
> >> > +  * VESA DSC 1.1 Table E-5 sets it to 4.
> >> > +  */
> >> > + { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 
> >> > },
> >> > + { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 
> >> > 12, -8 },
> >> > + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 
> >> > 9, 16, -12 },
> >> > + { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> >> > + }
> >> > + }
> >> > + },
> >> > + {
> >> > + .bpp = DSC_BPP(8), .bpc = 12,
> >> > + { 512, 12, 6144, 11, 20, 19, 19, {
> >> > + { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, 
> >> > -2 },
> >> > + { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 
> >> > 11, 16, -8 },
> >> > + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
> >> > + { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
> >> > + { 21, 23, -12 }
> >> > + }
> >> > + }
> >> > + },
> >> > + {
> >> > + .bpp = DSC_BPP(12), .bpc = 8,
> >> > + { 341, 15, 2048, 3, 12, 11, 11, {
> >> > + { 0, 2, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 
> >> > },
> >> > + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, 
> >> > -8 },
> >> > + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 },
> >> > + { 5, 12, -12 }, { 5, 13, -12 }, { 7, 13, -12 }, { 
> >> > 13, 15, -12 }
> >> > + }
> >> > + }
> >> > + },
> >> > + {
> >> > + .bpp = DSC_BPP(12), .bpc = 10,
> >> > + { 341, 15, 2048, 7, 16, 15, 15, {
> >> > + { 0, 2, 2 }, { 2, 5, 0 }, { 3, 7, 0 }, { 4, 8, -2 
> >> > },
> >> > + { 6, 9, -4 }, { 7, 10, -6 }, { 7, 11, -8 }, { 7, 
> >> > 12, -8 },
> >> > + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 
> >> > 9, 16, -12 },
> >> > + { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> >> > + }
> >> > + }
> >> > + },
> >> > + {
> >> > + .bpp = DSC_BPP(12), .bpc = 12,
> >> > + { 341, 15, 2048, 11, 20, 19, 19, {
> >> > + { 0, 6, 2 }, { 4, 9, 0 }, { 7, 11, 0 }, { 8, 12, 
> >> > -2 },
> >> > + { 10, 13, -4 }, { 11, 14, -6 }, { 11, 15, -8 }, { 
> >> > 11, 16, -8 },
> >> > + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
> >> > + { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
> >> > + { 21, 23, -12 }
> >> > + }
> >> > + }
> >> > + },
> >> > + { /* sentinel */ }
> >> > +};
> >> > +
> >> >  /*
> >> >   * Selected Rate Control Related Parameter Recommended Values
> >> >   * from DSC_v1.11 spec & C Model 

[Intel-gfx] [CI 3/3] drm/i915/opregion: Register display debugfs later, after initialization steps

[Imre Deak]

Move the display debugfs registration later, after initializing steps
for opregion/acpi/audio. These latter ones don't depend on the debugfs
entries, OTOH some debugfs entries may depend on the initialized state.

Reviewed-by: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index edbcb1273ca28..e7e7a29e117dc 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8886,14 +8886,14 @@ void intel_display_driver_register(struct 
drm_i915_private *i915)
if (!HAS_DISPLAY(i915))
return;
 
-   intel_display_debugfs_register(i915);
-
/* Must be done after probing outputs */
intel_opregion_register(i915);
intel_acpi_video_register(i915);
 
intel_audio_init(i915);
 
+   intel_display_debugfs_register(i915);
+
/*
 * Some ports require correctly set-up hpd registers for
 * detection to work properly (leading to ghost connected
-- 
2.37.1

[Intel-gfx] [CI 2/3] drm/i915/opregion: Cleanup opregion after errors during driver loading

[Imre Deak]

Clean up the opregion state if something fails after
intel_opregion_setup() is called.

Reviewed-by: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_opregion.c | 8 
 drivers/gpu/drm/i915/display/intel_opregion.h | 1 +
 drivers/gpu/drm/i915/i915_driver.c| 6 +-
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
b/drivers/gpu/drm/i915/display/intel_opregion.c
index bbcc2142d7df5..b7973a05d022d 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -1237,6 +1237,14 @@ void intel_opregion_unregister(struct drm_i915_private 
*i915)
unregister_acpi_notifier(>acpi_notifier);
opregion->acpi_notifier.notifier_call = NULL;
}
+}
+
+void intel_opregion_cleanup(struct drm_i915_private *i915)
+{
+   struct intel_opregion *opregion = >display.opregion;
+
+   if (!opregion->header)
+   return;
 
/* just clear all opregion memory pointers now */
memunmap(opregion->header);
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.h 
b/drivers/gpu/drm/i915/display/intel_opregion.h
index d02e6696a050e..181eb3e9abbf3 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.h
+++ b/drivers/gpu/drm/i915/display/intel_opregion.h
@@ -60,6 +60,7 @@ struct intel_opregion {
 #ifdef CONFIG_ACPI
 
 int intel_opregion_setup(struct drm_i915_private *dev_priv);
+void intel_opregion_cleanup(struct drm_i915_private *i915);
 
 void intel_opregion_register(struct drm_i915_private *dev_priv);
 void intel_opregion_unregister(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index a53fd339e2cc9..da249337c23bd 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -535,7 +535,7 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
 
ret = i915_pcode_init(dev_priv);
if (ret)
-   goto err_msi;
+   goto err_opregion;
 
/*
 * Fill the dram structure to get the system dram info. This will be
@@ -556,6 +556,8 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
 
return 0;
 
+err_opregion:
+   intel_opregion_cleanup(dev_priv);
 err_msi:
if (pdev->msi_enabled)
pci_disable_msi(pdev);
@@ -581,6 +583,8 @@ static void i915_driver_hw_remove(struct drm_i915_private 
*dev_priv)
 
i915_perf_fini(dev_priv);
 
+   intel_opregion_cleanup(dev_priv);
+
if (pdev->msi_enabled)
pci_disable_msi(pdev);
 
-- 
2.37.1

[Intel-gfx] [CI 1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display

[Imre Deak]

Atm, during system resume, the driver updates the display connector
information required by the opregion video extensions during system
resume, on platforms both with and without display being present. On
!HAS_DISPLAY platforms this will result in the crash with the stack
trace below, since the driver's connector state is not initialized on
those.

Bspec doesn't specify when each of the opregion functionality is
supported (depending on the presence of display), however we can presume
that none of the video extensions, nor the ACPI _DSM functions are
supported on !HAS_DISPLAY platforms; accordingly skip the corresponding
opregion/ACPI setup on those (also matching the Windows driver in this).

Keep sending the opregion notification about suspending/resuming the
whole adapter (vs. the display only which is a separate power state
notification) on all platforms, similarly to runtime suspend/resume.

This fixes the following:
Oops:  [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 1443 Comm: kworker/u40:55 Tainted: G U 6.2.0-rc8+ #58
Hardware name: LENOVO 82VB/LNVNB161216, BIOS KMCN09WW 04/26/2022
Workqueue: events_unbound async_run_entry_fn
RIP: 0010:drm_connector_list_iter_next+0x4f/0xb0

Call Trace:
 
 intel_acpi_device_id_update+0x80/0x160 [i915]
 intel_opregion_resume+0x2f/0x1e0 [i915]
 ? dg2_init_clock_gating+0x49/0xf0 [i915]
 i915_drm_resume+0x137/0x190 [i915]
 ? __pfx_pci_pm_resume+0x10/0x10
 dpm_run_callback+0x47/0x150

Cc: iczero 
Reported-and-tested-by: iczero 
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8015
Reviewed-by: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_opregion.c | 36 +--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
b/drivers/gpu/drm/i915/display/intel_opregion.c
index b8dce0576512a..bbcc2142d7df5 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -1159,13 +1159,10 @@ void intel_opregion_register(struct drm_i915_private 
*i915)
intel_opregion_resume(i915);
 }
 
-void intel_opregion_resume(struct drm_i915_private *i915)
+static void intel_opregion_resume_display(struct drm_i915_private *i915)
 {
struct intel_opregion *opregion = >display.opregion;
 
-   if (!opregion->header)
-   return;
-
if (opregion->acpi) {
intel_didl_outputs(i915);
intel_setup_cadls(i915);
@@ -1186,19 +1183,25 @@ void intel_opregion_resume(struct drm_i915_private 
*i915)
 
/* Some platforms abuse the _DSM to enable MUX */
intel_dsm_get_bios_data_funcs_supported(i915);
+}
+
+void intel_opregion_resume(struct drm_i915_private *i915)
+{
+   struct intel_opregion *opregion = >display.opregion;
+
+   if (!opregion->header)
+   return;
+
+   if (HAS_DISPLAY(i915))
+   intel_opregion_resume_display(i915);
 
intel_opregion_notify_adapter(i915, PCI_D0);
 }
 
-void intel_opregion_suspend(struct drm_i915_private *i915, pci_power_t state)
+static void intel_opregion_suspend_display(struct drm_i915_private *i915)
 {
struct intel_opregion *opregion = >display.opregion;
 
-   if (!opregion->header)
-   return;
-
-   intel_opregion_notify_adapter(i915, state);
-
if (opregion->asle)
opregion->asle->ardy = ASLE_ARDY_NOT_READY;
 
@@ -1208,6 +1211,19 @@ void intel_opregion_suspend(struct drm_i915_private 
*i915, pci_power_t state)
opregion->acpi->drdy = 0;
 }
 
+void intel_opregion_suspend(struct drm_i915_private *i915, pci_power_t state)
+{
+   struct intel_opregion *opregion = >display.opregion;
+
+   if (!opregion->header)
+   return;
+
+   intel_opregion_notify_adapter(i915, state);
+
+   if (HAS_DISPLAY(i915))
+   intel_opregion_suspend_display(i915);
+}
+
 void intel_opregion_unregister(struct drm_i915_private *i915)
 {
struct intel_opregion *opregion = >display.opregion;
-- 
2.37.1

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: prevent forcewake releases during BAR resize (rev3)

[Andrzej Hajda]

On 08.03.2023 16:44, Patchwork wrote:

*Patch Details*
*Series:*   drm/i915/gt: prevent forcewake releases during BAR resize (rev3)
*URL:*	https://patchwork.freedesktop.org/series/114836/ 


*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/index.html 




  CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114836v3


Summary

*FAILURE*

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

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_114836v3, 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_114836v3/index.html



Participating hosts (35 -> 34)

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


Possible new issues

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



  IGT changes


Possible regressions

  * igt@i915_selftest@live@execlists:
  o fi-glk-j4005: PASS


 -> ABORT 




Unrelated, and already observed [1].

[1]: 
http://gfx-ci.igk.intel.com/tree/drm-tip/IGT_7184/fi-bsw-nick/igt@i915_selftest@l...@execlists.html


Regards
Andrzej



Known issues

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



  IGT changes


Issues hit

  *

igt@gem_mmap@basic:

  o bat-dg1-6: NOTRUN -> SKIP


 (i915#4083 )
  *

igt@gem_render_tiled_blits@basic:

  o bat-dg1-6: NOTRUN -> SKIP


 (i915#4079 ) +1 similar issue
  *

igt@gem_tiled_fence_blits@basic:

  o bat-dg1-6: NOTRUN -> SKIP


 (i915#4077 ) +2 similar issues
  *

igt@i915_pm_backlight@basic-brightness:

  o bat-dg1-6: NOTRUN -> SKIP


 (i915#7561 )
  *

igt@i915_pm_rps@basic-api:

  o bat-dg1-6: NOTRUN -> SKIP


 (i915#6621 )
  *

igt@i915_selftest@live@slpc:

  o bat-rpls-1: NOTRUN -> DMESG-FAIL


 (i915#6367 )
  *

igt@kms_addfb_basic@basic-y-tiled-legacy:

  o bat-dg1-6: NOTRUN -> SKIP


 (i915#4215 )
  *

igt@kms_addfb_basic@tile-pitch-mismatch:

  o bat-dg1-6: NOTRUN -> SKIP


 (i915#4212 ) +7 similar issues
  *

igt@kms_chamelium_hpd@common-hpd-after-suspend:

  o

bat-dg1-6: NOTRUN -> SKIP


 (i915#7828 ) +8 similar issues

  o

bat-rpls-1: NOTRUN -> SKIP


 (i915#7828 )

  *

igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:

  o bat-dg1-6: NOTRUN -> SKIP


 (i915#4103  / i915#4213 
) +1 similar issue
  *

igt@kms_force_connector_basic@force-load-detect:

Re: [Intel-gfx] [PATCH v5 00/19] Add vfio_device cdev for iommufd support

[Shameerali Kolothum Thodi]

> -Original Message-
> From: Nicolin Chen [mailto:nicol...@nvidia.com]
> Sent: 04 March 2023 07:01
> To: Shameerali Kolothum Thodi 
> Cc: Xu, Terrence ; Liu, Yi L ;
> Jason Gunthorpe ; alex.william...@redhat.com; Tian,
> Kevin ; j...@8bytes.org; robin.mur...@arm.com;
> coh...@redhat.com; eric.au...@redhat.com; k...@vger.kernel.org;
> mjros...@linux.ibm.com; chao.p.p...@linux.intel.com;
> yi.y@linux.intel.com; pet...@redhat.com; jasow...@redhat.com;
> l...@redhat.com; suravee.suthikulpa...@amd.com;
> intel-gvt-...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org;
> linux-s...@vger.kernel.org; Hao, Xudong ; Zhao,
> Yan Y 
> Subject: Re: [PATCH v5 00/19] Add vfio_device cdev for iommufd support
> 
> On Fri, Mar 03, 2023 at 03:01:03PM +, Shameerali Kolothum Thodi
> wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > > -Original Message-
> > > From: Nicolin Chen [mailto:nicol...@nvidia.com]
> > > Sent: 02 March 2023 23:51
> > > To: Shameerali Kolothum Thodi
> 
> > > Cc: Xu, Terrence ; Liu, Yi L
> > > ; Jason Gunthorpe ;
> > > alex.william...@redhat.com; Tian, Kevin ;
> > > j...@8bytes.org; robin.mur...@arm.com; coh...@redhat.com;
> > > eric.au...@redhat.com; k...@vger.kernel.org; mjros...@linux.ibm.com;
> > > chao.p.p...@linux.intel.com; yi.y@linux.intel.com;
> > > pet...@redhat.com; jasow...@redhat.com; l...@redhat.com;
> > > suravee.suthikulpa...@amd.com; intel-gvt-...@lists.freedesktop.org;
> > > intel-gfx@lists.freedesktop.org; linux-s...@vger.kernel.org; Hao,
> > > Xudong ; Zhao, Yan Y 
> > > Subject: Re: [PATCH v5 00/19] Add vfio_device cdev for iommufd
> > > support
> > >
> > > On Thu, Mar 02, 2023 at 09:43:00AM +, Shameerali Kolothum Thodi
> > > wrote:
> > >
> > > > Hi Nicolin,
> > > >
> > > > Thanks for the latest ARM64 branch. Do you have a working Qemu
> > > > branch
> > > corresponding to the
> > > > above one?
> > > >
> > > > I tried the
> > >
> https://github.com/nicolinc/qemu/tree/wip/iommufd_rfcv3%2Bnesting%2B
> > > smmuv3
> > > > but for some reason not able to launch the Guest.
> > > >
> > > > Please let me know.
> > >
> > > I do use that branch. It might not be that robust though as it went
> > > through a big rebase.
> >
> > Ok. The issue seems to be quite random in nature and only happens when
> > there are multiple vCPUs. Also doesn't look like related to VFIO
> > device assignment as I can reproduce Guest hang without it by only
> > having nested-smmuv3 and iommufd object.
> >
> > ./qemu-system-aarch64-iommuf -machine
> > virt,gic-version=3,iommu=nested-smmuv3,iommufd=iommufd0 \
> -enable-kvm
> > -cpu host -m 1G -smp cpus=8,maxcpus=8 \ -object iommufd,id=iommufd0
> \
> > -bios QEMU_EFI.fd \ -kernel Image-6.2-iommufd \ -initrd
> > rootfs-iperf.cpio \ -net none \ -nographic \ -append "rdinit=init
> > console=ttyAMA0 root=/dev/vda rw earlycon=pl011,0x900" \ -trace
> > events=events \ -D trace_iommufd
> >
> > When the issue happens, no output on terminal as if Qemu is in a locked
> state.
> >
> >  Can you try with the followings?
> > >
> > > --trace "iommufd*" --trace "smmu*" --trace "vfio_*" --trace "pci_*"
> > > --trace "msi_*" --trace "nvme_*"
> >
> > The only trace events with above are this,
> >
> > iommufd_backend_connect fd=22 owned=1 users=1 (0) smmu_add_mr
> > smmuv3-iommu-memory-region-0-0
> >
> > I haven't debugged this further. Please let me know if issue is
> > reproducible with multiple vCPUs at your end. For now will focus on VFIO
> dev specific tests.
> 
> Oh. My test environment has been a single-core vCPU. So that doesn't
> happen to me. Can you try a vanilla QEMU branch that our nesting branch is
> rebased on? I took a branch from Yi as the baseline, while he might take
> from Eric for the rfcv3.
> 
> I am guessing that it might be an issue in the common tree.

Yes, that looks like the case.
I tried with:
 commit 13356edb8750("Merge tag 'block-pull-request' of 
https://gitlab.com/stefanha/qemu into staging")

And issue is still there. So hopefully once we rebase everything it will go 
away.

Thanks,
Shameer

[Intel-gfx] [PATCH v10 15/15] drm/i915: Add deadline based boost support

[Rob Clark]

From: Rob Clark 

I expect this patch to be replaced by someone who knows i915 better.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/i915/i915_request.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 7503dcb9043b..44491e7e214c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -97,6 +97,25 @@ static bool i915_fence_enable_signaling(struct dma_fence 
*fence)
return i915_request_enable_breadcrumb(to_request(fence));
 }
 
+static void i915_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
+{
+   struct i915_request *rq = to_request(fence);
+
+   if (i915_request_completed(rq))
+   return;
+
+   if (i915_request_started(rq))
+   return;
+
+   /*
+* TODO something more clever for deadlines that are in the
+* future.  I think probably track the nearest deadline in
+* rq->timeline and set timer to trigger boost accordingly?
+*/
+
+   intel_rps_boost(rq);
+}
+
 static signed long i915_fence_wait(struct dma_fence *fence,
   bool interruptible,
   signed long timeout)
@@ -182,6 +201,7 @@ const struct dma_fence_ops i915_fence_ops = {
.signaled = i915_fence_signaled,
.wait = i915_fence_wait,
.release = i915_fence_release,
+   .set_deadline = i915_fence_set_deadline,
 };
 
 static void irq_execute_cb(struct irq_work *wrk)
-- 
2.39.2

[Intel-gfx] [PATCH v10 13/15] drm/msm: Add wait-boost support

[Rob Clark]

From: Rob Clark 

Add a way for various userspace waits to signal urgency.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_drv.c | 12 
 drivers/gpu/drm/msm/msm_gem.c |  5 +
 include/uapi/drm/msm_drm.h| 14 --
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index aca48c868c14..f6764a86b2da 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -46,6 +46,7 @@
  * - 1.8.0 - Add MSM_BO_CACHED_COHERENT for supported GPUs (a6xx)
  * - 1.9.0 - Add MSM_SUBMIT_FENCE_SN_IN
  * - 1.10.0 - Add MSM_SUBMIT_BO_NO_IMPLICIT
+ * - 1.11.0 - Add wait boost (MSM_WAIT_FENCE_BOOST, MSM_PREP_BOOST)
  */
 #define MSM_VERSION_MAJOR  1
 #define MSM_VERSION_MINOR  10
@@ -899,7 +900,7 @@ static int msm_ioctl_gem_info(struct drm_device *dev, void 
*data,
 }
 
 static int wait_fence(struct msm_gpu_submitqueue *queue, uint32_t fence_id,
- ktime_t timeout)
+ ktime_t timeout, uint32_t flags)
 {
struct dma_fence *fence;
int ret;
@@ -929,6 +930,9 @@ static int wait_fence(struct msm_gpu_submitqueue *queue, 
uint32_t fence_id,
if (!fence)
return 0;
 
+   if (flags & MSM_WAIT_FENCE_BOOST)
+   dma_fence_set_deadline(fence, ktime_get());
+
ret = dma_fence_wait_timeout(fence, true, timeout_to_jiffies());
if (ret == 0) {
ret = -ETIMEDOUT;
@@ -949,8 +953,8 @@ static int msm_ioctl_wait_fence(struct drm_device *dev, 
void *data,
struct msm_gpu_submitqueue *queue;
int ret;
 
-   if (args->pad) {
-   DRM_ERROR("invalid pad: %08x\n", args->pad);
+   if (args->flags & ~MSM_WAIT_FENCE_FLAGS) {
+   DRM_ERROR("invalid flags: %08x\n", args->flags);
return -EINVAL;
}
 
@@ -961,7 +965,7 @@ static int msm_ioctl_wait_fence(struct drm_device *dev, 
void *data,
if (!queue)
return -ENOENT;
 
-   ret = wait_fence(queue, args->fence, to_ktime(args->timeout));
+   ret = wait_fence(queue, args->fence, to_ktime(args->timeout), 
args->flags);
 
msm_submitqueue_put(queue);
 
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 1dee0d18abbb..dd4a0d773f6e 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -846,6 +846,11 @@ int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t 
op, ktime_t *timeout)
op & MSM_PREP_NOSYNC ? 0 : timeout_to_jiffies(timeout);
long ret;
 
+   if (op & MSM_PREP_BOOST) {
+   dma_resv_set_deadline(obj->resv, dma_resv_usage_rw(write),
+ ktime_get());
+   }
+
ret = dma_resv_wait_timeout(obj->resv, dma_resv_usage_rw(write),
true,  remain);
if (ret == 0)
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index 329100016e7c..dbf0d6f43fa9 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -151,8 +151,13 @@ struct drm_msm_gem_info {
 #define MSM_PREP_READ0x01
 #define MSM_PREP_WRITE   0x02
 #define MSM_PREP_NOSYNC  0x04
+#define MSM_PREP_BOOST   0x08
 
-#define MSM_PREP_FLAGS   (MSM_PREP_READ | MSM_PREP_WRITE | MSM_PREP_NOSYNC)
+#define MSM_PREP_FLAGS   (MSM_PREP_READ | \
+ MSM_PREP_WRITE | \
+ MSM_PREP_NOSYNC | \
+ MSM_PREP_BOOST | \
+ 0)
 
 struct drm_msm_gem_cpu_prep {
__u32 handle; /* in */
@@ -286,6 +291,11 @@ struct drm_msm_gem_submit {
 
 };
 
+#define MSM_WAIT_FENCE_BOOST   0x0001
+#define MSM_WAIT_FENCE_FLAGS   ( \
+   MSM_WAIT_FENCE_BOOST | \
+   0)
+
 /* The normal way to synchronize with the GPU is just to CPU_PREP on
  * a buffer if you need to access it from the CPU (other cmdstream
  * submission from same or other contexts, PAGE_FLIP ioctl, etc, all
@@ -295,7 +305,7 @@ struct drm_msm_gem_submit {
  */
 struct drm_msm_wait_fence {
__u32 fence;  /* in */
-   __u32 pad;
+   __u32 flags;  /* in, bitmask of MSM_WAIT_FENCE_x */
struct drm_msm_timespec timeout;   /* in */
__u32 queueid; /* in, submitqueue id */
 };
-- 
2.39.2

[Intel-gfx] [PATCH v10 14/15] drm/msm/atomic: Switch to vblank_start helper

[Rob Clark]

From: Rob Clark 

Drop our custom thing and switch to drm_crtc_next_vblank_start() for
calculating the time of the start of the next vblank period.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 ---
 drivers/gpu/drm/msm/msm_atomic.c|  8 +---
 drivers/gpu/drm/msm/msm_kms.h   |  8 
 3 files changed, 5 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index a683bd9b5a04..43996aecaf8c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -411,20 +411,6 @@ static void dpu_kms_disable_commit(struct msm_kms *kms)
pm_runtime_put_sync(_kms->pdev->dev);
 }
 
-static ktime_t dpu_kms_vsync_time(struct msm_kms *kms, struct drm_crtc *crtc)
-{
-   struct drm_encoder *encoder;
-
-   drm_for_each_encoder_mask(encoder, crtc->dev, 
crtc->state->encoder_mask) {
-   ktime_t vsync_time;
-
-   if (dpu_encoder_vsync_time(encoder, _time) == 0)
-   return vsync_time;
-   }
-
-   return ktime_get();
-}
-
 static void dpu_kms_prepare_commit(struct msm_kms *kms,
struct drm_atomic_state *state)
 {
@@ -953,7 +939,6 @@ static const struct msm_kms_funcs kms_funcs = {
.irq = dpu_core_irq,
.enable_commit   = dpu_kms_enable_commit,
.disable_commit  = dpu_kms_disable_commit,
-   .vsync_time  = dpu_kms_vsync_time,
.prepare_commit  = dpu_kms_prepare_commit,
.flush_commit= dpu_kms_flush_commit,
.wait_flush  = dpu_kms_wait_flush,
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 1686fbb611fd..c5e71c05f038 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -186,8 +186,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
struct msm_kms *kms = priv->kms;
struct drm_crtc *async_crtc = NULL;
unsigned crtc_mask = get_crtc_mask(state);
-   bool async = kms->funcs->vsync_time &&
-   can_do_async(state, _crtc);
+   bool async = can_do_async(state, _crtc);
 
trace_msm_atomic_commit_tail_start(async, crtc_mask);
 
@@ -231,7 +230,9 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
 
kms->pending_crtc_mask |= crtc_mask;
 
-   vsync_time = kms->funcs->vsync_time(kms, async_crtc);
+   if (drm_crtc_next_vblank_start(async_crtc, _time))
+   goto fallback;
+
wakeup_time = ktime_sub(vsync_time, ms_to_ktime(1));
 
msm_hrtimer_queue_work(>work, wakeup_time,
@@ -253,6 +254,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
return;
}
 
+fallback:
/*
 * If there is any async flush pending on updated crtcs, fold
 * them into the current flush.
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index f8ed7588928c..086a3f1ff956 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -59,14 +59,6 @@ struct msm_kms_funcs {
void (*enable_commit)(struct msm_kms *kms);
void (*disable_commit)(struct msm_kms *kms);
 
-   /**
-* If the kms backend supports async commit, it should implement
-* this method to return the time of the next vsync.  This is
-* used to determine a time slightly before vsync, for the async
-* commit timer to run and complete an async commit.
-*/
-   ktime_t (*vsync_time)(struct msm_kms *kms, struct drm_crtc *crtc);
-
/**
 * Prepare for atomic commit.  This is called after any previous
 * (async or otherwise) commit has completed.
-- 
2.39.2

[Intel-gfx] [PATCH v10 12/15] drm/msm: Add deadline based boost support

[Rob Clark]

From: Rob Clark 

Track the nearest deadline on a fence timeline and set a timer to expire
shortly before to trigger boost if the fence has not yet been signaled.

v2: rebase

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_fence.c | 74 +
 drivers/gpu/drm/msm/msm_fence.h | 20 +
 2 files changed, 94 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c
index 56641408ea74..51b461f32103 100644
--- a/drivers/gpu/drm/msm/msm_fence.c
+++ b/drivers/gpu/drm/msm/msm_fence.c
@@ -8,6 +8,35 @@
 
 #include "msm_drv.h"
 #include "msm_fence.h"
+#include "msm_gpu.h"
+
+static struct msm_gpu *fctx2gpu(struct msm_fence_context *fctx)
+{
+   struct msm_drm_private *priv = fctx->dev->dev_private;
+   return priv->gpu;
+}
+
+static enum hrtimer_restart deadline_timer(struct hrtimer *t)
+{
+   struct msm_fence_context *fctx = container_of(t,
+   struct msm_fence_context, deadline_timer);
+
+   kthread_queue_work(fctx2gpu(fctx)->worker, >deadline_work);
+
+   return HRTIMER_NORESTART;
+}
+
+static void deadline_work(struct kthread_work *work)
+{
+   struct msm_fence_context *fctx = container_of(work,
+   struct msm_fence_context, deadline_work);
+
+   /* If deadline fence has already passed, nothing to do: */
+   if (msm_fence_completed(fctx, fctx->next_deadline_fence))
+   return;
+
+   msm_devfreq_boost(fctx2gpu(fctx), 2);
+}
 
 
 struct msm_fence_context *
@@ -36,6 +65,13 @@ msm_fence_context_alloc(struct drm_device *dev, volatile 
uint32_t *fenceptr,
fctx->completed_fence = fctx->last_fence;
*fctx->fenceptr = fctx->last_fence;
 
+   hrtimer_init(>deadline_timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+   fctx->deadline_timer.function = deadline_timer;
+
+   kthread_init_work(>deadline_work, deadline_work);
+
+   fctx->next_deadline = ktime_get();
+
return fctx;
 }
 
@@ -62,6 +98,8 @@ void msm_update_fence(struct msm_fence_context *fctx, 
uint32_t fence)
spin_lock_irqsave(>spinlock, flags);
if (fence_after(fence, fctx->completed_fence))
fctx->completed_fence = fence;
+   if (msm_fence_completed(fctx, fctx->next_deadline_fence))
+   hrtimer_cancel(>deadline_timer);
spin_unlock_irqrestore(>spinlock, flags);
 }
 
@@ -92,10 +130,46 @@ static bool msm_fence_signaled(struct dma_fence *fence)
return msm_fence_completed(f->fctx, f->base.seqno);
 }
 
+static void msm_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
+{
+   struct msm_fence *f = to_msm_fence(fence);
+   struct msm_fence_context *fctx = f->fctx;
+   unsigned long flags;
+   ktime_t now;
+
+   spin_lock_irqsave(>spinlock, flags);
+   now = ktime_get();
+
+   if (ktime_after(now, fctx->next_deadline) ||
+   ktime_before(deadline, fctx->next_deadline)) {
+   fctx->next_deadline = deadline;
+   fctx->next_deadline_fence =
+   max(fctx->next_deadline_fence, (uint32_t)fence->seqno);
+
+   /*
+* Set timer to trigger boost 3ms before deadline, or
+* if we are already less than 3ms before the deadline
+* schedule boost work immediately.
+*/
+   deadline = ktime_sub(deadline, ms_to_ktime(3));
+
+   if (ktime_after(now, deadline)) {
+   kthread_queue_work(fctx2gpu(fctx)->worker,
+   >deadline_work);
+   } else {
+   hrtimer_start(>deadline_timer, deadline,
+   HRTIMER_MODE_ABS);
+   }
+   }
+
+   spin_unlock_irqrestore(>spinlock, flags);
+}
+
 static const struct dma_fence_ops msm_fence_ops = {
.get_driver_name = msm_fence_get_driver_name,
.get_timeline_name = msm_fence_get_timeline_name,
.signaled = msm_fence_signaled,
+   .set_deadline = msm_fence_set_deadline,
 };
 
 struct dma_fence *
diff --git a/drivers/gpu/drm/msm/msm_fence.h b/drivers/gpu/drm/msm/msm_fence.h
index 7f1798c54cd1..cdaebfb94f5c 100644
--- a/drivers/gpu/drm/msm/msm_fence.h
+++ b/drivers/gpu/drm/msm/msm_fence.h
@@ -52,6 +52,26 @@ struct msm_fence_context {
volatile uint32_t *fenceptr;
 
spinlock_t spinlock;
+
+   /*
+* TODO this doesn't really deal with multiple deadlines, like
+* if userspace got multiple frames ahead.. OTOH atomic updates
+* don't queue, so maybe that is ok
+*/
+
+   /** next_deadline: Time of next deadline */
+   ktime_t next_deadline;
+
+   /**
+* next_deadline_fence:
+*
+* Fence value for next pending deadline.  The deadline timer is
+* canceled when this fence is signaled.
+*/
+   uint32_t next_deadline_fence;
+
+   struct hrtimer 

[Intel-gfx] [PATCH v10 09/15] drm/syncobj: Add deadline support for syncobj waits

[Rob Clark]

From: Rob Clark 

Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits.  This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can addjust GPU frequency accordingly.  An immediate deadline can be
given to provide something equivalent to i915 "wait boost".

v2: Use absolute u64 ns value for deadline hint, drop cap and driver
feature flag in favor of allowing count_handles==0 as a way for
userspace to probe kernel for support of new flag
v3: More verbose comments about UAPI

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_syncobj.c | 64 ---
 include/uapi/drm/drm.h| 17 ++
 2 files changed, 68 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0c2be8360525..a85e9464f07b 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -126,6 +126,11 @@
  * synchronize between the two.
  * This requirement is inherited from the Vulkan fence API.
  *
+ * If _SYNCOBJ_WAIT_FLAGS_WAIT_DEADLINE is set, the ioctl will also set
+ * a fence deadline hint on the backing fences before waiting, to provide the
+ * fence signaler with an appropriate sense of urgency.  The deadline is
+ * specified as an absolute _MONOTONIC value in units of ns.
+ *
  * Similarly, _IOCTL_SYNCOBJ_TIMELINE_WAIT takes an array of syncobj
  * handles as well as an array of u64 points and does a host-side wait on all
  * of syncobj fences at the given points simultaneously.
@@ -973,7 +978,8 @@ static signed long drm_syncobj_array_wait_timeout(struct 
drm_syncobj **syncobjs,
  uint32_t count,
  uint32_t flags,
  signed long timeout,
- uint32_t *idx)
+ uint32_t *idx,
+ ktime_t *deadline)
 {
struct syncobj_wait_entry *entries;
struct dma_fence *fence;
@@ -1053,6 +1059,15 @@ static signed long drm_syncobj_array_wait_timeout(struct 
drm_syncobj **syncobjs,
drm_syncobj_fence_add_wait(syncobjs[i], [i]);
}
 
+   if (deadline) {
+   for (i = 0; i < count; ++i) {
+   fence = entries[i].fence;
+   if (!fence)
+   continue;
+   dma_fence_set_deadline(fence, *deadline);
+   }
+   }
+
do {
set_current_state(TASK_INTERRUPTIBLE);
 
@@ -1151,7 +1166,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
  struct drm_file *file_private,
  struct drm_syncobj_wait *wait,
  struct drm_syncobj_timeline_wait 
*timeline_wait,
- struct drm_syncobj **syncobjs, bool timeline)
+ struct drm_syncobj **syncobjs, bool timeline,
+ ktime_t *deadline)
 {
signed long timeout = 0;
uint32_t first = ~0;
@@ -1162,7 +1178,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
 NULL,
 wait->count_handles,
 wait->flags,
-timeout, );
+timeout, ,
+deadline);
if (timeout < 0)
return timeout;
wait->first_signaled = first;
@@ -1172,7 +1189,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
 
u64_to_user_ptr(timeline_wait->points),
 
timeline_wait->count_handles,
 timeline_wait->flags,
-timeout, );
+timeout, ,
+deadline);
if (timeout < 0)
return timeout;
timeline_wait->first_signaled = first;
@@ -1243,17 +1261,22 @@ drm_syncobj_wait_ioctl(struct drm_device *dev, void 
*data,
 {
struct drm_syncobj_wait *args = data;
struct drm_syncobj **syncobjs;
+   unsigned possible_flags;
+   ktime_t t, *tp = NULL;
int ret = 0;
 
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -EOPNOTSUPP;
 
-   if (args->flags & 

[Intel-gfx] [PATCH v10 10/15] drm/vblank: Add helper to get next vblank time

[Rob Clark]

From: Rob Clark 

Will be used in the next commit to set a deadline on fences that an
atomic update is waiting on.

v2: Calculate time at *start* of vblank period, not end
v3: Fix kbuild complaints

Signed-off-by: Rob Clark 
Reviewed-by: Mario Kleiner 
---
 drivers/gpu/drm/drm_vblank.c | 53 ++--
 include/drm/drm_vblank.h |  1 +
 2 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 2ff31717a3de..299fa2a19a90 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -844,10 +844,9 @@ bool drm_crtc_vblank_helper_get_vblank_timestamp(struct 
drm_crtc *crtc,
 EXPORT_SYMBOL(drm_crtc_vblank_helper_get_vblank_timestamp);
 
 /**
- * drm_get_last_vbltimestamp - retrieve raw timestamp for the most recent
- * vblank interval
- * @dev: DRM device
- * @pipe: index of CRTC whose vblank timestamp to retrieve
+ * drm_crtc_get_last_vbltimestamp - retrieve raw timestamp for the most
+ *  recent vblank interval
+ * @crtc: CRTC whose vblank timestamp to retrieve
  * @tvblank: Pointer to target time which should receive the timestamp
  * @in_vblank_irq:
  * True when called from drm_crtc_handle_vblank().  Some drivers
@@ -865,10 +864,9 @@ EXPORT_SYMBOL(drm_crtc_vblank_helper_get_vblank_timestamp);
  * True if timestamp is considered to be very precise, false otherwise.
  */
 static bool
-drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
- ktime_t *tvblank, bool in_vblank_irq)
+drm_crtc_get_last_vbltimestamp(struct drm_crtc *crtc, ktime_t *tvblank,
+  bool in_vblank_irq)
 {
-   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
bool ret = false;
 
/* Define requested maximum error on timestamps (nanoseconds). */
@@ -876,8 +874,6 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned 
int pipe,
 
/* Query driver if possible and precision timestamping enabled. */
if (crtc && crtc->funcs->get_vblank_timestamp && max_error > 0) {
-   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
-
ret = crtc->funcs->get_vblank_timestamp(crtc, _error,
tvblank, in_vblank_irq);
}
@@ -891,6 +887,15 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned 
int pipe,
return ret;
 }
 
+static bool
+drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
+ ktime_t *tvblank, bool in_vblank_irq)
+{
+   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
+
+   return drm_crtc_get_last_vbltimestamp(crtc, tvblank, in_vblank_irq);
+}
+
 /**
  * drm_crtc_vblank_count - retrieve "cooked" vblank counter value
  * @crtc: which counter to retrieve
@@ -980,6 +985,36 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
 }
 EXPORT_SYMBOL(drm_crtc_vblank_count_and_time);
 
+/**
+ * drm_crtc_next_vblank_start - calculate the time of the next vblank
+ * @crtc: the crtc for which to calculate next vblank time
+ * @vblanktime: pointer to time to receive the next vblank timestamp.
+ *
+ * Calculate the expected time of the start of the next vblank period,
+ * based on time of previous vblank and frame duration
+ */
+int drm_crtc_next_vblank_start(struct drm_crtc *crtc, ktime_t *vblanktime)
+{
+   unsigned int pipe = drm_crtc_index(crtc);
+   struct drm_vblank_crtc *vblank = >dev->vblank[pipe];
+   struct drm_display_mode *mode = >hwmode;
+   u64 vblank_start;
+
+   if (!vblank->framedur_ns || !vblank->linedur_ns)
+   return -EINVAL;
+
+   if (!drm_crtc_get_last_vbltimestamp(crtc, vblanktime, false))
+   return -EINVAL;
+
+   vblank_start = DIV_ROUND_DOWN_ULL(
+   (u64)vblank->framedur_ns * mode->crtc_vblank_start,
+   mode->crtc_vtotal);
+   *vblanktime  = ktime_add(*vblanktime, ns_to_ktime(vblank_start));
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_crtc_next_vblank_start);
+
 static void send_vblank_event(struct drm_device *dev,
struct drm_pending_vblank_event *e,
u64 seq, ktime_t now)
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 733a3e2d1d10..7f3957943dd1 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -230,6 +230,7 @@ bool drm_dev_has_vblank(const struct drm_device *dev);
 u64 drm_crtc_vblank_count(struct drm_crtc *crtc);
 u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
   ktime_t *vblanktime);
+int drm_crtc_next_vblank_start(struct drm_crtc *crtc, ktime_t *vblanktime);
 void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
   struct drm_pending_vblank_event *e);
 void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
-- 
2.39.2

[Intel-gfx] [PATCH v10 11/15] drm/atomic-helper: Set fence deadline for vblank

[Rob Clark]

From: Rob Clark 

For an atomic commit updating a single CRTC (ie. a pageflip) calculate
the next vblank time, and inform the fence(s) of that deadline.

v2: Comment typo fix (danvet)
v3: If there are multiple CRTCs, consider the time of the soonest vblank

Signed-off-by: Rob Clark 
Reviewed-by: Daniel Vetter 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_atomic_helper.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index d579fd8f7cb8..28e3f2c8917e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1511,6 +1511,41 @@ void drm_atomic_helper_commit_modeset_enables(struct 
drm_device *dev,
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit_modeset_enables);
 
+/*
+ * For atomic updates which touch just a single CRTC, calculate the time of the
+ * next vblank, and inform all the fences of the deadline.
+ */
+static void set_fence_deadline(struct drm_device *dev,
+  struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *new_crtc_state;
+   struct drm_plane *plane;
+   struct drm_plane_state *new_plane_state;
+   ktime_t vbltime = 0;
+   int i;
+
+   for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
+   ktime_t v;
+
+   if (drm_crtc_next_vblank_start(crtc, ))
+   continue;
+
+   if (!vbltime || ktime_before(v, vbltime))
+   vbltime = v;
+   }
+
+   /* If no CRTCs updated, then nothing to do: */
+   if (!vbltime)
+   return;
+
+   for_each_new_plane_in_state (state, plane, new_plane_state, i) {
+   if (!new_plane_state->fence)
+   continue;
+   dma_fence_set_deadline(new_plane_state->fence, vbltime);
+   }
+}
+
 /**
  * drm_atomic_helper_wait_for_fences - wait for fences stashed in plane state
  * @dev: DRM device
@@ -1540,6 +1575,8 @@ int drm_atomic_helper_wait_for_fences(struct drm_device 
*dev,
struct drm_plane_state *new_plane_state;
int i, ret;
 
+   set_fence_deadline(dev, state);
+
for_each_new_plane_in_state(state, plane, new_plane_state, i) {
if (!new_plane_state->fence)
continue;
-- 
2.39.2

[Intel-gfx] [PATCH v10 06/15] dma-buf/sync_file: Add SET_DEADLINE ioctl

[Rob Clark]

From: Rob Clark 

The initial purpose is for igt tests, but this would also be useful for
compositors that wait until close to vblank deadline to make decisions
about which frame to show.

The igt tests can be found at:

https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline

v2: Clarify the timebase, add link to igt tests
v3: Use u64 value in ns to express deadline.
v4: More doc

Signed-off-by: Rob Clark 
Acked-by: Pekka Paalanen 
---
 drivers/dma-buf/dma-fence.c|  3 ++-
 drivers/dma-buf/sync_file.c| 19 +++
 include/uapi/linux/sync_file.h | 22 ++
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index f177c56269bb..74e36f6d05b0 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -933,7 +933,8 @@ EXPORT_SYMBOL(dma_fence_wait_any_timeout);
  *   the GPU's devfreq to reduce frequency, when in fact the opposite is what 
is
  *   needed.
  *
- * To this end, deadline hint(s) can be set on a _fence via 
_fence_set_deadline.
+ * To this end, deadline hint(s) can be set on a _fence via 
_fence_set_deadline
+ * (or indirectly via userspace facing ioctls like _set_deadline).
  * The deadline hint provides a way for the waiting driver, or userspace, to
  * convey an appropriate sense of urgency to the signaling driver.
  *
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index af57799c86ce..418021cfb87c 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -350,6 +350,22 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
return ret;
 }
 
+static int sync_file_ioctl_set_deadline(struct sync_file *sync_file,
+   unsigned long arg)
+{
+   struct sync_set_deadline ts;
+
+   if (copy_from_user(, (void __user *)arg, sizeof(ts)))
+   return -EFAULT;
+
+   if (ts.pad)
+   return -EINVAL;
+
+   dma_fence_set_deadline(sync_file->fence, ns_to_ktime(ts.deadline_ns));
+
+   return 0;
+}
+
 static long sync_file_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
 {
@@ -362,6 +378,9 @@ static long sync_file_ioctl(struct file *file, unsigned int 
cmd,
case SYNC_IOC_FILE_INFO:
return sync_file_ioctl_fence_info(sync_file, arg);
 
+   case SYNC_IOC_SET_DEADLINE:
+   return sync_file_ioctl_set_deadline(sync_file, arg);
+
default:
return -ENOTTY;
}
diff --git a/include/uapi/linux/sync_file.h b/include/uapi/linux/sync_file.h
index 7e42a5b7558b..d61752dca4c6 100644
--- a/include/uapi/linux/sync_file.h
+++ b/include/uapi/linux/sync_file.h
@@ -76,6 +76,27 @@ struct sync_file_info {
__u64   sync_fence_info;
 };
 
+/**
+ * struct sync_set_deadline - SYNC_IOC_SET_DEADLINE - set a deadline hint on a 
fence
+ * @deadline_ns: absolute time of the deadline
+ * @pad:   must be zero
+ *
+ * Allows userspace to set a deadline on a fence, see _fence_set_deadline
+ *
+ * The timebase for the deadline is CLOCK_MONOTONIC (same as vblank).  For
+ * example
+ *
+ * clock_gettime(CLOCK_MONOTONIC, );
+ * deadline_ns = (t.tv_sec * 10L) + t.tv_nsec + ns_until_deadline
+ */
+struct sync_set_deadline {
+   __u64   deadline_ns;
+   /* Not strictly needed for alignment but gives some possibility
+* for future extension:
+*/
+   __u64   pad;
+};
+
 #define SYNC_IOC_MAGIC '>'
 
 /*
@@ -87,5 +108,6 @@ struct sync_file_info {
 
 #define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 3, struct sync_merge_data)
 #define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info)
+#define SYNC_IOC_SET_DEADLINE  _IOW(SYNC_IOC_MAGIC, 5, struct 
sync_set_deadline)
 
 #endif /* _UAPI_LINUX_SYNC_H */
-- 
2.39.2

[Intel-gfx] [PATCH v10 07/15] dma-buf/sw_sync: Add fence deadline support

[Rob Clark]

From: Rob Clark 

This consists of simply storing the most recent deadline, and adding an
ioctl to retrieve the deadline.  This can be used in conjunction with
the SET_DEADLINE ioctl on a fence fd for testing.  Ie. create various
sw_sync fences, merge them into a fence-array, set deadline on the
fence-array and confirm that it is propagated properly to each fence.

v2: Switch UABI to express deadline as u64
v3: More verbose UAPI docs, show how to convert from timespec
v4: Better comments, track the soonest deadline, as a normal fence
implementation would, return an error if no deadline set.

Signed-off-by: Rob Clark 
Reviewed-by: Christian König 
Acked-by: Pekka Paalanen 
---
 drivers/dma-buf/sw_sync.c| 81 
 drivers/dma-buf/sync_debug.h |  2 +
 2 files changed, 83 insertions(+)

diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 348b3a9170fa..f53071bca3af 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -52,12 +52,33 @@ struct sw_sync_create_fence_data {
__s32   fence; /* fd of new fence */
 };
 
+/**
+ * struct sw_sync_get_deadline - get the deadline hint of a sw_sync fence
+ * @deadline_ns: absolute time of the deadline
+ * @pad:   must be zero
+ * @fence_fd:  the sw_sync fence fd (in)
+ *
+ * Return the earliest deadline set on the fence.  The timebase for the
+ * deadline is CLOCK_MONOTONIC (same as vblank).  If there is no deadline
+ * set on the fence, this ioctl will return -ENOENT.
+ */
+struct sw_sync_get_deadline {
+   __u64   deadline_ns;
+   __u32   pad;
+   __s32   fence_fd;
+};
+
 #define SW_SYNC_IOC_MAGIC  'W'
 
 #define SW_SYNC_IOC_CREATE_FENCE   _IOWR(SW_SYNC_IOC_MAGIC, 0,\
struct sw_sync_create_fence_data)
 
 #define SW_SYNC_IOC_INC_IOW(SW_SYNC_IOC_MAGIC, 1, 
__u32)
+#define SW_SYNC_GET_DEADLINE   _IOWR(SW_SYNC_IOC_MAGIC, 2, \
+   struct sw_sync_get_deadline)
+
+
+#define SW_SYNC_HAS_DEADLINE_BIT   DMA_FENCE_FLAG_USER_BITS
 
 static const struct dma_fence_ops timeline_fence_ops;
 
@@ -171,6 +192,22 @@ static void timeline_fence_timeline_value_str(struct 
dma_fence *fence,
snprintf(str, size, "%d", parent->value);
 }
 
+static void timeline_fence_set_deadline(struct dma_fence *fence, ktime_t 
deadline)
+{
+   struct sync_pt *pt = dma_fence_to_sync_pt(fence);
+   unsigned long flags;
+
+   spin_lock_irqsave(fence->lock, flags);
+   if (test_bit(SW_SYNC_HAS_DEADLINE_BIT, >flags)) {
+   if (ktime_before(deadline, pt->deadline))
+   pt->deadline = deadline;
+   } else {
+   pt->deadline = deadline;
+   set_bit(SW_SYNC_HAS_DEADLINE_BIT, >flags);
+   }
+   spin_unlock_irqrestore(fence->lock, flags);
+}
+
 static const struct dma_fence_ops timeline_fence_ops = {
.get_driver_name = timeline_fence_get_driver_name,
.get_timeline_name = timeline_fence_get_timeline_name,
@@ -179,6 +216,7 @@ static const struct dma_fence_ops timeline_fence_ops = {
.release = timeline_fence_release,
.fence_value_str = timeline_fence_value_str,
.timeline_value_str = timeline_fence_timeline_value_str,
+   .set_deadline = timeline_fence_set_deadline,
 };
 
 /**
@@ -387,6 +425,46 @@ static long sw_sync_ioctl_inc(struct sync_timeline *obj, 
unsigned long arg)
return 0;
 }
 
+static int sw_sync_ioctl_get_deadline(struct sync_timeline *obj, unsigned long 
arg)
+{
+   struct sw_sync_get_deadline data;
+   struct dma_fence *fence;
+   struct sync_pt *pt;
+   int ret = 0;
+
+   if (copy_from_user(, (void __user *)arg, sizeof(data)))
+   return -EFAULT;
+
+   if (data.deadline_ns || data.pad)
+   return -EINVAL;
+
+   fence = sync_file_get_fence(data.fence_fd);
+   if (!fence)
+   return -EINVAL;
+
+   pt = dma_fence_to_sync_pt(fence);
+   if (!pt)
+   return -EINVAL;
+
+   spin_lock(fence->lock);
+   if (test_bit(SW_SYNC_HAS_DEADLINE_BIT, >flags)) {
+   data.deadline_ns = ktime_to_ns(pt->deadline);
+   } else {
+   ret = -ENOENT;
+   }
+   spin_unlock(fence->lock);
+
+   dma_fence_put(fence);
+
+   if (ret)
+   return ret;
+
+   if (copy_to_user((void __user *)arg, , sizeof(data)))
+   return -EFAULT;
+
+   return 0;
+}
+
 static long sw_sync_ioctl(struct file *file, unsigned int cmd,
  unsigned long arg)
 {
@@ -399,6 +477,9 @@ static long sw_sync_ioctl(struct file *file, unsigned int 
cmd,
case SW_SYNC_IOC_INC:
return sw_sync_ioctl_inc(obj, arg);
 
+   case SW_SYNC_GET_DEADLINE:
+   return sw_sync_ioctl_get_deadline(obj, arg);
+
default:
return -ENOTTY;
}
diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
index 

[Intel-gfx] [PATCH v10 08/15] drm/scheduler: Add fence deadline support

[Rob Clark]

As the finished fence is the one that is exposed to userspace, and
therefore the one that other operations, like atomic update, would
block on, we need to propagate the deadline from from the finished
fence to the actual hw fence.

v2: Split into drm_sched_fence_set_parent() (ckoenig)
v3: Ensure a thread calling drm_sched_fence_set_deadline_finished() sees
fence->parent set before drm_sched_fence_set_parent() does this
test_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT).

Signed-off-by: Rob Clark 
Acked-by: Luben Tuikov 
---
 drivers/gpu/drm/scheduler/sched_fence.c | 46 +
 drivers/gpu/drm/scheduler/sched_main.c  |  2 +-
 include/drm/gpu_scheduler.h | 17 +
 3 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/scheduler/sched_fence.c 
b/drivers/gpu/drm/scheduler/sched_fence.c
index 7fd869520ef2..fe9c6468e440 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -123,6 +123,37 @@ static void drm_sched_fence_release_finished(struct 
dma_fence *f)
dma_fence_put(>scheduled);
 }
 
+static void drm_sched_fence_set_deadline_finished(struct dma_fence *f,
+ ktime_t deadline)
+{
+   struct drm_sched_fence *fence = to_drm_sched_fence(f);
+   struct dma_fence *parent;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+
+   /* If we already have an earlier deadline, keep it: */
+   if (test_bit(DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT, >flags) &&
+   ktime_before(fence->deadline, deadline)) {
+   spin_unlock_irqrestore(>lock, flags);
+   return;
+   }
+
+   fence->deadline = deadline;
+   set_bit(DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT, >flags);
+
+   spin_unlock_irqrestore(>lock, flags);
+
+   /*
+* smp_load_aquire() to ensure that if we are racing another
+* thread calling drm_sched_fence_set_parent(), that we see
+* the parent set before it calls test_bit(HAS_DEADLINE_BIT)
+*/
+   parent = smp_load_acquire(>parent);
+   if (parent)
+   dma_fence_set_deadline(parent, deadline);
+}
+
 static const struct dma_fence_ops drm_sched_fence_ops_scheduled = {
.get_driver_name = drm_sched_fence_get_driver_name,
.get_timeline_name = drm_sched_fence_get_timeline_name,
@@ -133,6 +164,7 @@ static const struct dma_fence_ops 
drm_sched_fence_ops_finished = {
.get_driver_name = drm_sched_fence_get_driver_name,
.get_timeline_name = drm_sched_fence_get_timeline_name,
.release = drm_sched_fence_release_finished,
+   .set_deadline = drm_sched_fence_set_deadline_finished,
 };
 
 struct drm_sched_fence *to_drm_sched_fence(struct dma_fence *f)
@@ -147,6 +179,20 @@ struct drm_sched_fence *to_drm_sched_fence(struct 
dma_fence *f)
 }
 EXPORT_SYMBOL(to_drm_sched_fence);
 
+void drm_sched_fence_set_parent(struct drm_sched_fence *s_fence,
+   struct dma_fence *fence)
+{
+   /*
+* smp_store_release() to ensure another thread racing us
+* in drm_sched_fence_set_deadline_finished() sees the
+* fence's parent set before test_bit()
+*/
+   smp_store_release(_fence->parent, dma_fence_get(fence));
+   if (test_bit(DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT,
+_fence->finished.flags))
+   dma_fence_set_deadline(fence, s_fence->deadline);
+}
+
 struct drm_sched_fence *drm_sched_fence_alloc(struct drm_sched_entity *entity,
  void *owner)
 {
diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index 4e6ad6e122bc..007f98c48f8d 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1019,7 +1019,7 @@ static int drm_sched_main(void *param)
drm_sched_fence_scheduled(s_fence);
 
if (!IS_ERR_OR_NULL(fence)) {
-   s_fence->parent = dma_fence_get(fence);
+   drm_sched_fence_set_parent(s_fence, fence);
/* Drop for original kref_init of the fence */
dma_fence_put(fence);
 
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 9db9e5e504ee..99584e457153 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -41,6 +41,15 @@
  */
 #define DRM_SCHED_FENCE_DONT_PIPELINE  DMA_FENCE_FLAG_USER_BITS
 
+/**
+ * DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT - A fence deadline hint has been set
+ *
+ * Because we could have a deadline hint can be set before the backing hw
+ * fence is created, we need to keep track of whether a deadline has already
+ * been set.
+ */
+#define DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT  (DMA_FENCE_FLAG_USER_BITS + 1)
+
 enum dma_resv_usage;
 struct dma_resv;
 struct drm_gem_object;
@@ -280,6 +289,12 @@ struct drm_sched_fence {
 

[Intel-gfx] [PATCH v10 03/15] dma-buf/fence-chain: Add fence deadline support

[Rob Clark]

From: Rob Clark 

Propagate the deadline to all the fences in the chain.

v2: Use dma_fence_chain_contained [Tvrtko]

Signed-off-by: Rob Clark 
Reviewed-by: Christian König  for this one.
---
 drivers/dma-buf/dma-fence-chain.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
index a0d920576ba6..9663ba1bb6ac 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -206,6 +206,17 @@ static void dma_fence_chain_release(struct dma_fence 
*fence)
dma_fence_free(fence);
 }
 
+
+static void dma_fence_chain_set_deadline(struct dma_fence *fence,
+ktime_t deadline)
+{
+   dma_fence_chain_for_each(fence, fence) {
+   struct dma_fence *f = dma_fence_chain_contained(fence);
+
+   dma_fence_set_deadline(f, deadline);
+   }
+}
+
 const struct dma_fence_ops dma_fence_chain_ops = {
.use_64bit_seqno = true,
.get_driver_name = dma_fence_chain_get_driver_name,
@@ -213,6 +224,7 @@ const struct dma_fence_ops dma_fence_chain_ops = {
.enable_signaling = dma_fence_chain_enable_signaling,
.signaled = dma_fence_chain_signaled,
.release = dma_fence_chain_release,
+   .set_deadline = dma_fence_chain_set_deadline,
 };
 EXPORT_SYMBOL(dma_fence_chain_ops);
 
-- 
2.39.2

[Intel-gfx] [PATCH v10 05/15] dma-buf/sync_file: Surface sync-file uABI

[Rob Clark]

From: Rob Clark 

We had all of the internal driver APIs, but not the all important
userspace uABI, in the dma-buf doc.  Fix that.  And re-arrange the
comments slightly as otherwise the comments for the ioctl nr defines
would not show up.

v2: Fix docs build warning coming from newly including the uabi header
in the docs build

Signed-off-by: Rob Clark 
Acked-by: Pekka Paalanen 
---
 Documentation/driver-api/dma-buf.rst | 10 ++--
 include/uapi/linux/sync_file.h   | 37 +++-
 2 files changed, 23 insertions(+), 24 deletions(-)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index 183e480d8cea..ff3f8da296af 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -203,8 +203,8 @@ DMA Fence unwrap
 .. kernel-doc:: include/linux/dma-fence-unwrap.h
:internal:
 
-DMA Fence uABI/Sync File
-
+DMA Fence Sync File
+~~~
 
 .. kernel-doc:: drivers/dma-buf/sync_file.c
:export:
@@ -212,6 +212,12 @@ DMA Fence uABI/Sync File
 .. kernel-doc:: include/linux/sync_file.h
:internal:
 
+DMA Fence Sync File uABI
+
+
+.. kernel-doc:: include/uapi/linux/sync_file.h
+   :internal:
+
 Indefinite DMA Fences
 ~
 
diff --git a/include/uapi/linux/sync_file.h b/include/uapi/linux/sync_file.h
index ee2dcfb3d660..7e42a5b7558b 100644
--- a/include/uapi/linux/sync_file.h
+++ b/include/uapi/linux/sync_file.h
@@ -16,12 +16,16 @@
 #include 
 
 /**
- * struct sync_merge_data - data passed to merge ioctl
+ * struct sync_merge_data - SYNC_IOC_MERGE: merge two fences
  * @name:  name of new fence
  * @fd2:   file descriptor of second fence
  * @fence: returns the fd of the new fence to userspace
  * @flags: merge_data flags
  * @pad:   padding for 64-bit alignment, should always be zero
+ *
+ * Creates a new fence containing copies of the sync_pts in both
+ * the calling fd and sync_merge_data.fd2.  Returns the new fence's
+ * fd in sync_merge_data.fence
  */
 struct sync_merge_data {
charname[32];
@@ -34,8 +38,8 @@ struct sync_merge_data {
 /**
  * struct sync_fence_info - detailed fence information
  * @obj_name:  name of parent sync_timeline
-* @driver_name:name of driver implementing the parent
-* @status: status of the fence 0:active 1:signaled <0:error
+ * @driver_name:   name of driver implementing the parent
+ * @status:status of the fence 0:active 1:signaled <0:error
  * @flags: fence_info flags
  * @timestamp_ns:  timestamp of status change in nanoseconds
  */
@@ -48,14 +52,19 @@ struct sync_fence_info {
 };
 
 /**
- * struct sync_file_info - data returned from fence info ioctl
+ * struct sync_file_info - SYNC_IOC_FILE_INFO: get detailed information on a 
sync_file
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
  * @flags: sync_file_info flags
  * @num_fences number of fences in the sync_file
  * @pad:   padding for 64-bit alignment, should always be zero
- * @sync_fence_info: pointer to array of structs sync_fence_info with all
+ * @sync_fence_info: pointer to array of struct _fence_info with all
  *  fences in the sync_file
+ *
+ * Takes a struct sync_file_info. If num_fences is 0, the field is updated
+ * with the actual number of fences. If num_fences is > 0, the system will
+ * use the pointer provided on sync_fence_info to return up to num_fences of
+ * struct sync_fence_info, with detailed fence information.
  */
 struct sync_file_info {
charname[32];
@@ -69,30 +78,14 @@ struct sync_file_info {
 
 #define SYNC_IOC_MAGIC '>'
 
-/**
+/*
  * Opcodes  0, 1 and 2 were burned during a API change to avoid users of the
  * old API to get weird errors when trying to handling sync_files. The API
  * change happened during the de-stage of the Sync Framework when there was
  * no upstream users available.
  */
 
-/**
- * DOC: SYNC_IOC_MERGE - merge two fences
- *
- * Takes a struct sync_merge_data.  Creates a new fence containing copies of
- * the sync_pts in both the calling fd and sync_merge_data.fd2.  Returns the
- * new fence's fd in sync_merge_data.fence
- */
 #define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 3, struct sync_merge_data)
-
-/**
- * DOC: SYNC_IOC_FILE_INFO - get detailed information on a sync_file
- *
- * Takes a struct sync_file_info. If num_fences is 0, the field is updated
- * with the actual number of fences. If num_fences is > 0, the system will
- * use the pointer provided on sync_fence_info to return up to num_fences of
- * struct sync_fence_info, with detailed fence information.
- */
 #define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info)
 
 #endif /* _UAPI_LINUX_SYNC_H */
-- 
2.39.2

[Intel-gfx] [PATCH v10 04/15] dma-buf/dma-resv: Add a way to set fence deadline

[Rob Clark]

From: Rob Clark 

Add a way to set a deadline on remaining resv fences according to the
requested usage.

Signed-off-by: Rob Clark 
Reviewed-by: Christian König 
---
 drivers/dma-buf/dma-resv.c | 22 ++
 include/linux/dma-resv.h   |  2 ++
 2 files changed, 24 insertions(+)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 1c76aed8e262..2a594b754af1 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -684,6 +684,28 @@ long dma_resv_wait_timeout(struct dma_resv *obj, enum 
dma_resv_usage usage,
 }
 EXPORT_SYMBOL_GPL(dma_resv_wait_timeout);
 
+/**
+ * dma_resv_set_deadline - Set a deadline on reservation's objects fences
+ * @obj: the reservation object
+ * @usage: controls which fences to include, see enum dma_resv_usage.
+ * @deadline: the requested deadline (MONOTONIC)
+ *
+ * May be called without holding the dma_resv lock.  Sets @deadline on
+ * all fences filtered by @usage.
+ */
+void dma_resv_set_deadline(struct dma_resv *obj, enum dma_resv_usage usage,
+  ktime_t deadline)
+{
+   struct dma_resv_iter cursor;
+   struct dma_fence *fence;
+
+   dma_resv_iter_begin(, obj, usage);
+   dma_resv_for_each_fence_unlocked(, fence) {
+   dma_fence_set_deadline(fence, deadline);
+   }
+   dma_resv_iter_end();
+}
+EXPORT_SYMBOL_GPL(dma_resv_set_deadline);
 
 /**
  * dma_resv_test_signaled - Test if a reservation object's fences have been
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index 0637659a702c..8d0e34dad446 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -479,6 +479,8 @@ int dma_resv_get_singleton(struct dma_resv *obj, enum 
dma_resv_usage usage,
 int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src);
 long dma_resv_wait_timeout(struct dma_resv *obj, enum dma_resv_usage usage,
   bool intr, unsigned long timeout);
+void dma_resv_set_deadline(struct dma_resv *obj, enum dma_resv_usage usage,
+  ktime_t deadline);
 bool dma_resv_test_signaled(struct dma_resv *obj, enum dma_resv_usage usage);
 void dma_resv_describe(struct dma_resv *obj, struct seq_file *seq);
 
-- 
2.39.2

[Intel-gfx] [PATCH v10 02/15] dma-buf/fence-array: Add fence deadline support

[Rob Clark]

From: Rob Clark 

Propagate the deadline to all the fences in the array.

Signed-off-by: Rob Clark 
Reviewed-by: Christian König 
---
 drivers/dma-buf/dma-fence-array.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 5c8a7084577b..9b3ce8948351 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -123,12 +123,23 @@ static void dma_fence_array_release(struct dma_fence 
*fence)
dma_fence_free(fence);
 }
 
+static void dma_fence_array_set_deadline(struct dma_fence *fence,
+ktime_t deadline)
+{
+   struct dma_fence_array *array = to_dma_fence_array(fence);
+   unsigned i;
+
+   for (i = 0; i < array->num_fences; ++i)
+   dma_fence_set_deadline(array->fences[i], deadline);
+}
+
 const struct dma_fence_ops dma_fence_array_ops = {
.get_driver_name = dma_fence_array_get_driver_name,
.get_timeline_name = dma_fence_array_get_timeline_name,
.enable_signaling = dma_fence_array_enable_signaling,
.signaled = dma_fence_array_signaled,
.release = dma_fence_array_release,
+   .set_deadline = dma_fence_array_set_deadline,
 };
 EXPORT_SYMBOL(dma_fence_array_ops);
 
-- 
2.39.2

[Intel-gfx] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

[Rob Clark]

From: Rob Clark 

Add a way to hint to the fence signaler of an upcoming deadline, such as
vblank, which the fence waiter would prefer not to miss.  This is to aid
the fence signaler in making power management decisions, like boosting
frequency as the deadline approaches and awareness of missing deadlines
so that can be factored in to the frequency scaling.

v2: Drop dma_fence::deadline and related logic to filter duplicate
deadlines, to avoid increasing dma_fence size.  The fence-context
implementation will need similar logic to track deadlines of all
the fences on the same timeline.  [ckoenig]
v3: Clarify locking wrt. set_deadline callback
v4: Clarify in docs comment that this is a hint
v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT.
v6: More docs
v7: Fix typo, clarify past deadlines

Signed-off-by: Rob Clark 
Reviewed-by: Christian König 
Acked-by: Pekka Paalanen 
Reviewed-by: Bagas Sanjaya 
---
 Documentation/driver-api/dma-buf.rst |  6 +++
 drivers/dma-buf/dma-fence.c  | 59 
 include/linux/dma-fence.h| 22 +++
 3 files changed, 87 insertions(+)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index 622b8156d212..183e480d8cea 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -164,6 +164,12 @@ DMA Fence Signalling Annotations
 .. kernel-doc:: drivers/dma-buf/dma-fence.c
:doc: fence signalling annotation
 
+DMA Fence Deadline Hints
+
+
+.. kernel-doc:: drivers/dma-buf/dma-fence.c
+   :doc: deadline hints
+
 DMA Fences Functions Reference
 ~~
 
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 0de0482cd36e..f177c56269bb 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct dma_fence **fences, 
uint32_t count,
 }
 EXPORT_SYMBOL(dma_fence_wait_any_timeout);
 
+/**
+ * DOC: deadline hints
+ *
+ * In an ideal world, it would be possible to pipeline a workload sufficiently
+ * that a utilization based device frequency governor could arrive at a minimum
+ * frequency that meets the requirements of the use-case, in order to minimize
+ * power consumption.  But in the real world there are many workloads which
+ * defy this ideal.  For example, but not limited to:
+ *
+ * * Workloads that ping-pong between device and CPU, with alternating periods
+ *   of CPU waiting for device, and device waiting on CPU.  This can result in
+ *   devfreq and cpufreq seeing idle time in their respective domains and in
+ *   result reduce frequency.
+ *
+ * * Workloads that interact with a periodic time based deadline, such as 
double
+ *   buffered GPU rendering vs vblank sync'd page flipping.  In this scenario,
+ *   missing a vblank deadline results in an *increase* in idle time on the GPU
+ *   (since it has to wait an additional vblank period), sending a signal to
+ *   the GPU's devfreq to reduce frequency, when in fact the opposite is what 
is
+ *   needed.
+ *
+ * To this end, deadline hint(s) can be set on a _fence via 
_fence_set_deadline.
+ * The deadline hint provides a way for the waiting driver, or userspace, to
+ * convey an appropriate sense of urgency to the signaling driver.
+ *
+ * A deadline hint is given in absolute ktime (CLOCK_MONOTONIC for userspace
+ * facing APIs).  The time could either be some point in the future (such as
+ * the vblank based deadline for page-flipping, or the start of a compositor's
+ * composition cycle), or the current time to indicate an immediate deadline
+ * hint (Ie. forward progress cannot be made until this fence is signaled).
+ *
+ * Multiple deadlines may be set on a given fence, even in parallel.  See the
+ * documentation for _fence_ops.set_deadline.
+ *
+ * The deadline hint is just that, a hint.  The driver that created the fence
+ * may react by increasing frequency, making different scheduling choices, etc.
+ * Or doing nothing at all.
+ */
+
+/**
+ * dma_fence_set_deadline - set desired fence-wait deadline hint
+ * @fence:the fence that is to be waited on
+ * @deadline: the time by which the waiter hopes for the fence to be
+ *signaled
+ *
+ * Give the fence signaler a hint about an upcoming deadline, such as
+ * vblank, by which point the waiter would prefer the fence to be
+ * signaled by.  This is intended to give feedback to the fence signaler
+ * to aid in power management decisions, such as boosting GPU frequency
+ * if a periodic vblank deadline is approaching but the fence is not
+ * yet signaled..
+ */
+void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
+{
+   if (fence->ops->set_deadline && !dma_fence_is_signaled(fence))
+   fence->ops->set_deadline(fence, deadline);
+}
+EXPORT_SYMBOL(dma_fence_set_deadline);
+
 /**
  * dma_fence_describe - Dump fence describtion into seq_file
  * @fence: the 6fence to 

[Intel-gfx] [PATCH v10 00/15] dma-fence: Deadline awareness

[Rob Clark]

From: Rob Clark 

This series adds a deadline hint to fences, so realtime deadlines
such as vblank can be communicated to the fence signaller for power/
frequency management decisions.

This is partially inspired by a trick i915 does, but implemented
via dma-fence for a couple of reasons:

1) To continue to be able to use the atomic helpers
2) To support cases where display and gpu are different drivers

This iteration adds a dma-fence ioctl to set a deadline (both to
support igt-tests, and compositors which delay decisions about which
client buffer to display), and a sw_sync ioctl to read back the
deadline.  IGT tests utilizing these can be found at:

  https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline


v1: https://patchwork.freedesktop.org/series/93035/
v2: Move filtering out of later deadlines to fence implementation
to avoid increasing the size of dma_fence
v3: Add support in fence-array and fence-chain; Add some uabi to
support igt tests and userspace compositors.
v4: Rebase, address various comments, and add syncobj deadline
support, and sync_file EPOLLPRI based on experience with perf/
freq issues with clvk compute workloads on i915 (anv)
v5: Clarify that this is a hint as opposed to a more hard deadline
guarantee, switch to using u64 ns values in UABI (still absolute
CLOCK_MONOTONIC values), drop syncobj related cap and driver
feature flag in favor of allowing count_handles==0 for probing
kernel support.
v6: Re-work vblank helper to calculate time of _start_ of vblank,
and work correctly if the last vblank event was more than a
frame ago.  Add (mostly unrelated) drm/msm patch which also
uses the vblank helper.  Use dma_fence_chain_contained().  More
verbose syncobj UABI comments.  Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT.
v7: Fix kbuild complaints about vblank helper.  Add more docs.
v8: Add patch to surface sync_file UAPI, and more docs updates.
v9: Drop (E)POLLPRI support.. I still like it, but not essential and
it can always be revived later.  Fix doc build warning.
v10: Update 11/15 to handle multiple CRTCs

Rob Clark (15):
  dma-buf/dma-fence: Add deadline awareness
  dma-buf/fence-array: Add fence deadline support
  dma-buf/fence-chain: Add fence deadline support
  dma-buf/dma-resv: Add a way to set fence deadline
  dma-buf/sync_file: Surface sync-file uABI
  dma-buf/sync_file: Add SET_DEADLINE ioctl
  dma-buf/sw_sync: Add fence deadline support
  drm/scheduler: Add fence deadline support
  drm/syncobj: Add deadline support for syncobj waits
  drm/vblank: Add helper to get next vblank time
  drm/atomic-helper: Set fence deadline for vblank
  drm/msm: Add deadline based boost support
  drm/msm: Add wait-boost support
  drm/msm/atomic: Switch to vblank_start helper
  drm/i915: Add deadline based boost support

Rob Clark (15):
  dma-buf/dma-fence: Add deadline awareness
  dma-buf/fence-array: Add fence deadline support
  dma-buf/fence-chain: Add fence deadline support
  dma-buf/dma-resv: Add a way to set fence deadline
  dma-buf/sync_file: Surface sync-file uABI
  dma-buf/sync_file: Add SET_DEADLINE ioctl
  dma-buf/sw_sync: Add fence deadline support
  drm/scheduler: Add fence deadline support
  drm/syncobj: Add deadline support for syncobj waits
  drm/vblank: Add helper to get next vblank time
  drm/atomic-helper: Set fence deadline for vblank
  drm/msm: Add deadline based boost support
  drm/msm: Add wait-boost support
  drm/msm/atomic: Switch to vblank_start helper
  drm/i915: Add deadline based boost support

 Documentation/driver-api/dma-buf.rst| 16 -
 drivers/dma-buf/dma-fence-array.c   | 11 
 drivers/dma-buf/dma-fence-chain.c   | 12 
 drivers/dma-buf/dma-fence.c | 60 ++
 drivers/dma-buf/dma-resv.c  | 22 +++
 drivers/dma-buf/sw_sync.c   | 81 +
 drivers/dma-buf/sync_debug.h|  2 +
 drivers/dma-buf/sync_file.c | 19 ++
 drivers/gpu/drm/drm_atomic_helper.c | 37 +++
 drivers/gpu/drm/drm_syncobj.c   | 64 +++
 drivers/gpu/drm/drm_vblank.c| 53 +---
 drivers/gpu/drm/i915/i915_request.c | 20 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 -
 drivers/gpu/drm/msm/msm_atomic.c|  8 ++-
 drivers/gpu/drm/msm/msm_drv.c   | 12 ++--
 drivers/gpu/drm/msm/msm_fence.c | 74 ++
 drivers/gpu/drm/msm/msm_fence.h | 20 ++
 drivers/gpu/drm/msm/msm_gem.c   |  5 ++
 drivers/gpu/drm/msm/msm_kms.h   |  8 ---
 drivers/gpu/drm/scheduler/sched_fence.c | 46 ++
 drivers/gpu/drm/scheduler/sched_main.c  |  2 +-
 include/drm/drm_vblank.h|  1 +
 include/drm/gpu_scheduler.h | 17 ++
 include/linux/dma-fence.h   | 22 +++
 include/linux/dma-resv.h|  2 +
 include/uapi/drm/drm.h  | 17 ++
 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: prevent forcewake releases during BAR resize (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: prevent forcewake releases during BAR resize (rev3)
URL   : https://patchwork.freedesktop.org/series/114836/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114836v3


Summary
---

  **FAILURE**

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

Participating hosts (35 -> 34)
--

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@execlists:
- fi-glk-j4005:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/fi-glk-j4005/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/fi-glk-j4005/igt@i915_selftest@l...@execlists.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_mmap@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][3] ([i915#4083])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-dg1-6/igt@gem_m...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][4] ([i915#4079]) +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][5] ([i915#4077]) +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg1-6:  NOTRUN -> [SKIP][6] ([i915#7561])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-6:  NOTRUN -> [SKIP][7] ([i915#6621])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-dg1-6/igt@i915_pm_...@basic-api.html

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

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-6:  NOTRUN -> [SKIP][9] ([i915#4215])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg1-6:  NOTRUN -> [SKIP][10] ([i915#4212]) +7 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-dg1-6/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-6:  NOTRUN -> [SKIP][11] ([i915#7828]) +8 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-dg1-6/igt@kms_chamelium_...@common-hpd-after-suspend.html
- bat-rpls-1: NOTRUN -> [SKIP][12] ([i915#7828])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- bat-dg1-6:  NOTRUN -> [SKIP][13] ([i915#4103] / [i915#4213]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-dg1-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-6:  NOTRUN -> [SKIP][14] ([fdo#109285])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-dg1-6/igt@kms_force_connector_ba...@force-load-detect.html

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

  * igt@kms_psr@sprite_plane_onoff:
- bat-dg1-6:  NOTRUN -> [SKIP][16] ([i915#1072] / [i915#4078]) +3 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114836v3/bat-dg1-6/igt@kms_psr@sprite_plane_onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-dg1-6:  NOTRUN -> [SKIP][17] ([i915#3555])
   [17]: 

[Intel-gfx] [PATCH v5 4/4] drm/i915: add guard page to ggtt->error_capture

[Andrzej Hajda]

Write-combining memory allows speculative reads by CPU.
ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try
to prefetch memory beyond the error_capture, ie it tries
to read memory pointed by next PTE in GGTT.
If this PTE points to invalid address DMAR errors will occur.
This behaviour was observed on ADL and RPL platforms.
To avoid it, guard scratch page should be added after error_capture.
The patch fixes the most annoying issue with error capture but
since WC reads are used also in other places there is a risk similar
problem can affect them as well.

v2:
  - modified commit message (I hope the diagnosis is correct),
  - added bug checks to ensure scratch is initialized on gen3 platforms.
CI produces strange stacktrace for it suggesting scratch[0] is NULL,
to be removed after resolving the issue with gen3 platforms.
v3:
  - removed bug checks, replaced with gen check.
v4:
  - change code for scratch page insertion to support all platforms,
  - add info in commit message there could be more similar issues
v5:
  - check for nop_clear_range instead of gen8 (Tvrtko),
  - re-insert scratch pages on resume (Tvrtko)

Signed-off-by: Andrzej Hajda 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 35 +++
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index b925da42c7cfc4..8fb700fde85c8f 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -502,6 +502,21 @@ static void cleanup_init_ggtt(struct i915_ggtt *ggtt)
mutex_destroy(>error_mutex);
 }
 
+static void
+ggtt_insert_scratch_pages(struct i915_ggtt *ggtt, u64 offset, u64 length)
+{
+   struct i915_address_space *vm = >vm;
+
+   if (vm->clear_range != nop_clear_range)
+   return vm->clear_range(vm, offset, length);
+
+   while (length > 0) {
+   vm->insert_page(vm, px_dma(vm->scratch[0]), offset, 
I915_CACHE_NONE, 0);
+   offset += I915_GTT_PAGE_SIZE;
+   length -= I915_GTT_PAGE_SIZE;
+   }
+}
+
 static int init_ggtt(struct i915_ggtt *ggtt)
 {
/*
@@ -550,8 +565,12 @@ static int init_ggtt(struct i915_ggtt *ggtt)
 * paths, and we trust that 0 will remain reserved. However,
 * the only likely reason for failure to insert is a driver
 * bug, which we expect to cause other failures...
+*
+* Since CPU can perform speculative reads on error capture
+* (write-combining allows it) add scratch page after error
+* capture to avoid DMAR errors.
 */
-   ggtt->error_capture.size = I915_GTT_PAGE_SIZE;
+   ggtt->error_capture.size = 2 * I915_GTT_PAGE_SIZE;
ggtt->error_capture.color = I915_COLOR_UNEVICTABLE;
if (drm_mm_reserve_node(>vm.mm, >error_capture))
drm_mm_insert_node_in_range(>vm.mm,
@@ -561,11 +580,15 @@ static int init_ggtt(struct i915_ggtt *ggtt)
0, ggtt->mappable_end,
DRM_MM_INSERT_LOW);
}
-   if (drm_mm_node_allocated(>error_capture))
+   if (drm_mm_node_allocated(>error_capture)) {
+   u64 start = ggtt->error_capture.start;
+   u64 size = ggtt->error_capture.size;
+
+   ggtt_insert_scratch_pages(ggtt, start, size);
drm_dbg(>vm.i915->drm,
"Reserved GGTT:[%llx, %llx] for use by error capture\n",
-   ggtt->error_capture.start,
-   ggtt->error_capture.start + ggtt->error_capture.size);
+   start, start + size);
+   }
 
/*
 * The upper portion of the GuC address space has a sizeable hole
@@ -1256,6 +1279,10 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
 
flush = i915_ggtt_resume_vm(>vm);
 
+   if (drm_mm_node_allocated(>error_capture))
+   ggtt_insert_scratch_pages(ggtt, ggtt->error_capture.start,
+ ggtt->error_capture.size);
+
ggtt->invalidate(ggtt);
 
if (flush)

-- 
2.34.1

[Intel-gfx] [PATCH v5 2/4] drm/i915/display: use nop_clear_range instead of local function

[Andrzej Hajda]

Since nop_clear_range is visible it can be used here.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_dpt.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index ad1a37b515fb1c..eb9d1a6cbfb9dd 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -73,11 +73,6 @@ static void dpt_insert_entries(struct i915_address_space *vm,
gen8_set_pte([i++], pte_encode | addr);
 }
 
-static void dpt_clear_range(struct i915_address_space *vm,
-   u64 start, u64 length)
-{
-}
-
 static void dpt_bind_vma(struct i915_address_space *vm,
 struct i915_vm_pt_stash *stash,
 struct i915_vma_resource *vma_res,
@@ -291,7 +286,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
i915_address_space_init(vm, VM_CLASS_DPT);
 
vm->insert_page = dpt_insert_page;
-   vm->clear_range = dpt_clear_range;
+   vm->clear_range = nop_clear_range;
vm->insert_entries = dpt_insert_entries;
vm->cleanup = dpt_cleanup;
 

-- 
2.34.1

[Intel-gfx] [PATCH v5 3/4] drm/i915/selftests: use nop_clear_range instead of local function

[Andrzej Hajda]

Since nop_clear_range is visible it can be used here.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/selftests/mock_gtt.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/mock_gtt.c 
b/drivers/gpu/drm/i915/selftests/mock_gtt.c
index ece97e4faacb97..89119e3970279f 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gtt.c
@@ -57,11 +57,6 @@ static void mock_cleanup(struct i915_address_space *vm)
 {
 }
 
-static void mock_clear_range(struct i915_address_space *vm,
-u64 start, u64 length)
-{
-}
-
 struct i915_ppgtt *mock_ppgtt(struct drm_i915_private *i915, const char *name)
 {
struct i915_ppgtt *ppgtt;
@@ -80,7 +75,7 @@ struct i915_ppgtt *mock_ppgtt(struct drm_i915_private *i915, 
const char *name)
ppgtt->vm.alloc_pt_dma = alloc_pt_dma;
ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
 
-   ppgtt->vm.clear_range = mock_clear_range;
+   ppgtt->vm.clear_range = nop_clear_range;
ppgtt->vm.insert_page = mock_insert_page;
ppgtt->vm.insert_entries = mock_insert_entries;
ppgtt->vm.cleanup = mock_cleanup;
@@ -119,7 +114,7 @@ void mock_init_ggtt(struct intel_gt *gt)
ggtt->vm.alloc_pt_dma = alloc_pt_dma;
ggtt->vm.alloc_scratch_dma = alloc_pt_dma;
 
-   ggtt->vm.clear_range = mock_clear_range;
+   ggtt->vm.clear_range = nop_clear_range;
ggtt->vm.insert_page = mock_insert_page;
ggtt->vm.insert_entries = mock_insert_entries;
ggtt->vm.cleanup = mock_cleanup;

-- 
2.34.1

[Intel-gfx] [PATCH v5 1/4] drm/i915/gt: make nop_clear_range public

[Andrzej Hajda]

Function nop_clear_range can be used instead of local implementations.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 +--
 drivers/gpu/drm/i915/gt/intel_gtt.h  | 2 ++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 842e69c7b21e49..b925da42c7cfc4 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -345,8 +345,7 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
ggtt->invalidate(ggtt);
 }
 
-static void nop_clear_range(struct i915_address_space *vm,
-   u64 start, u64 length)
+void nop_clear_range(struct i915_address_space *vm, u64 start, u64 length)
 {
 }
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 5a775310d3fcb5..c15a4892e9f45d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -672,4 +672,6 @@ static inline struct sgt_dma {
return (struct sgt_dma){ sg, addr, addr + sg_dma_len(sg) };
 }
 
+void nop_clear_range(struct i915_address_space *vm, u64 start, u64 length);
+
 #endif

-- 
2.34.1

[Intel-gfx] [PATCH v5 0/4] drm/i915: add guard page to ggtt->error_capture

[Andrzej Hajda]

This patch tries to diminish plague of DMAR read errors present
in CI for ADL*, RPL*, DG2 platforms, see for example [1] (grep DMAR).
CI is usually tolerant for these errors, so the scale of the problem
is not really visible.
To show it I have counted lines containing DMAR read errors in dmesgs
produced by CI for all three versions of the patch, but in contrast to v2
I have grepped only for lines containing "PTE Read access".
Below stats for kernel w/o patchset vs patched one.
v1: 210 vs 0
v2: 201 vs 0
v3: 214 vs 0
Apparently the patchset fixes all common PTE read errors.

Changelog:
v2:
- modified commit message (I hope the diagnosis is correct),
- added bug checks to ensure scratch is initialized on gen3 platforms.
  CI produces strange stacktrace for it suggesting scratch[0] is NULL,
  to be removed after resolving the issue with gen3 platforms.
v3:
- removed bug checks, replaced with gen check.
v4:
- change code for scratch page insertion to support all platforms,
- add info in commit message there could be more similar issues
v5:
- changed to patchset adding nop_clear_range related code,
- re-insert scratch PTEs on resume

To: Jani Nikula 
To: Joonas Lahtinen 
To: Rodrigo Vivi 
To: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: Andi Shyti 
Cc: Chris Wilson 
Cc: Nirmoy Das 

Signed-off-by: Andrzej Hajda 

---
Andrzej Hajda (4):
  drm/i915/gt: make nop_clear_range public
  drm/i915/display: use nop_clear_range instead of local function
  drm/i915/selftests: use nop_clear_range instead of local function
  drm/i915: add guard page to ggtt->error_capture

 drivers/gpu/drm/i915/display/intel_dpt.c  |  7 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 38 ++-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  2 ++
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  9 ++--
 4 files changed, 37 insertions(+), 19 deletions(-)
---
base-commit: 3cd6c251f39c14df9ab711e3eb56e703b359ff54
change-id: 20230308-guard_error_capture-f3f334eec85f

Best regards,
-- 
Andrzej Hajda 

Re: [Intel-gfx] [PATCH v10 03/13] drm/i915/dp: Add Scaler constraint for YCbCr420 output

[Ville Syrjälä]

On Wed, Mar 08, 2023 at 05:10:57PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 27, 2023 at 09:33:14AM +0530, Ankit Nautiyal wrote:
> > For YCbCr420 output, scaler is required for downsampling.
> > Scaler can be used only when source size smaller than max_src_w and
> > max_src_h as defined by for the platform.
> > So go for native YCbCr420 only if there are no scaler constraints.
> > 
> > v2: Corrected max-width based on Display Version.
> > 
> > v3: Updated max-width as per latest Bspec change.
> > 
> > Signed-off-by: Ankit Nautiyal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 41 ++---
> >  1 file changed, 37 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 1a30cc021b25..e95fc0f0d13a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -804,11 +804,36 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp 
> > *intel_dp,
> > return 0;
> >  }
> >  
> > +static bool
> > +ycbcr420_scaler_constraints(struct drm_i915_private *i915,
> > +   const struct drm_display_mode *mode)
> > +{
> > +   int max_src_w, max_src_h;
> > +
> > +   if (DISPLAY_VER(i915) < 11) {
> > +   max_src_w = 4096;
> > +   max_src_h = 4096;
> > +   } else if (DISPLAY_VER(i915) < 12) {
> > +   max_src_w = 5120;
> > +   max_src_h = 4096;
> > +   } else if (DISPLAY_VER(i915) < 14) {
> > +   max_src_w = 5120;
> > +   max_src_h = 8192;
> > +   } else {
> > +   max_src_w = 4096;
> > +   max_src_h = 8192;
> > +   }
> > +
> > +   return mode->hdisplay > max_src_w || mode->vdisplay > max_src_h;
> > +}
> > +
> 
> I don't really like this. If we do something like this
> then it should be the scaler code that checks this stuff.
> 
> However, after pondering about this more I'm actually
> leaning towards using 4:4:4 output whenever possible,
> only going for 4:2:0 if absolutely necessary. That
> avoids having to deal with all the annoying scaler/etc
> limitations.

In fact perhaps best to try RGB first (also avoids the whole
pipe CSC mess on glk), then YCbCr 4:4:4 (still avoids the
scaler mess), and finally accepting that we need to do 
native YCbCr 4:2:0 output.

> 
> >  static enum intel_output_format
> >  intel_dp_output_format(struct intel_connector *connector,
> > +  const struct drm_display_mode *mode,
> >enum intel_output_format sink_format)
> >  {
> > struct intel_dp *intel_dp = intel_attached_dp(connector);
> > +   struct drm_i915_private *i915 = to_i915(connector->base.dev);
> >  
> > if (!connector->base.ycbcr_420_allowed ||
> > sink_format != INTEL_OUTPUT_FORMAT_YCBCR420)
> > @@ -820,8 +845,15 @@ intel_dp_output_format(struct intel_connector 
> > *connector,
> >  
> > if (intel_dp->dfp.ycbcr_444_to_420)
> > return INTEL_OUTPUT_FORMAT_YCBCR444;
> > -   else
> > +
> > +   /*
> > +* For YCbCr420 output, scaler is required for downsampling
> > +* So go for native YCbCr420 only if there are no scaler constraints.
> > +*/
> > +   if (!ycbcr420_scaler_constraints(i915, mode))
> > return INTEL_OUTPUT_FORMAT_YCBCR420;
> > +
> > +   return INTEL_OUTPUT_FORMAT_RGB;
> >  }
> >  
> >  int intel_dp_min_bpp(enum intel_output_format output_format)
> > @@ -857,7 +889,7 @@ intel_dp_mode_min_output_bpp(struct intel_connector 
> > *connector,
> > else
> > sink_format = INTEL_OUTPUT_FORMAT_RGB;
> >  
> > -   output_format = intel_dp_output_format(connector, sink_format);
> > +   output_format = intel_dp_output_format(connector, mode, sink_format);
> >  
> > return intel_dp_output_bpp(output_format, 
> > intel_dp_min_bpp(output_format));
> >  }
> > @@ -2052,7 +2084,8 @@ intel_dp_compute_output_format(struct intel_encoder 
> > *encoder,
> > crtc_state->sink_format = INTEL_OUTPUT_FORMAT_RGB;
> > }
> >  
> > -   crtc_state->output_format = intel_dp_output_format(connector, 
> > crtc_state->sink_format);
> > +   crtc_state->output_format = intel_dp_output_format(connector, 
> > adjusted_mode,
> > +  
> > crtc_state->sink_format);
> >  
> > ret = intel_dp_compute_link_config(encoder, crtc_state, conn_state,
> >respect_downstream_limits);
> > @@ -2063,7 +2096,7 @@ intel_dp_compute_output_format(struct intel_encoder 
> > *encoder,
> > return ret;
> >  
> > crtc_state->sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> > -   crtc_state->output_format = intel_dp_output_format(connector,
> > +   crtc_state->output_format = intel_dp_output_format(connector, 
> > adjusted_mode,
> >
> > crtc_state->sink_format);
> > ret = intel_dp_compute_link_config(encoder, crtc_state, 

Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915/mtl: Add Wa_14017073508 for SAMedia"

[Nilawar, Badal]

Hi Jani,

On 08-03-2023 16:48, Jani Nikula wrote:

On Wed, 08 Mar 2023, Badal Nilawar  wrote:

This reverts commit 8f70f1ec587da0b0d52d768fd8c3defbc5e5b55c.


Reverts need a commit message too. The why. The cover letter is not
recorded in git history.


I will add commit message.
Regards,
Badal


BR,
Jani.


Signed-off-by: Badal Nilawar 
---
  drivers/gpu/drm/i915/gt/intel_gt_pm.c | 27 ---
  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 13 +--
  drivers/gpu/drm/i915/i915_reg.h   |  9 
  3 files changed, 1 insertion(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 85ae7dc079f2..e02cb90723ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -20,31 +20,10 @@
  #include "intel_rc6.h"
  #include "intel_rps.h"
  #include "intel_wakeref.h"
-#include "intel_pcode.h"
  #include "pxp/intel_pxp_pm.h"
  
  #define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)
  
-static void mtl_media_busy(struct intel_gt *gt)

-{
-   /* Wa_14017073508: mtl */
-   if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
-   gt->type == GT_MEDIA)
-   snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
- PCODE_MBOX_GT_STATE_MEDIA_BUSY,
- PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
-}
-
-static void mtl_media_idle(struct intel_gt *gt)
-{
-   /* Wa_14017073508: mtl */
-   if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
-   gt->type == GT_MEDIA)
-   snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
- PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY,
- PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
-}
-
  static void user_forcewake(struct intel_gt *gt, bool suspend)
  {
int count = atomic_read(>user_wakeref);
@@ -92,9 +71,6 @@ static int __gt_unpark(struct intel_wakeref *wf)
  
  	GT_TRACE(gt, "\n");
  
-	/* Wa_14017073508: mtl */

-   mtl_media_busy(gt);
-
/*
 * It seems that the DMC likes to transition between the DC states a lot
 * when there are no connected displays (no active power domains) during
@@ -144,9 +120,6 @@ static int __gt_park(struct intel_wakeref *wf)
GEM_BUG_ON(!wakeref);
intel_display_power_put_async(i915, POWER_DOMAIN_GT_IRQ, wakeref);
  
-	/* Wa_14017073508: mtl */

-   mtl_media_idle(gt);
-
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c

index fcf51614f9a4..1adec6de223c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
@@ -12,20 +12,9 @@
  
  static bool __guc_rc_supported(struct intel_guc *guc)

  {
-   struct intel_gt *gt = guc_to_gt(guc);
-
-   /*
-* Wa_14017073508: mtl
-* Do not enable gucrc to avoid additional interrupts which
-* may disrupt pcode wa.
-*/
-   if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
-   gt->type == GT_MEDIA)
-   return false;
-
/* GuC RC is unavailable for pre-Gen12 */
return guc->submission_supported &&
-   GRAPHICS_VER(gt->i915) >= 12;
+   GRAPHICS_VER(guc_to_gt(guc)->i915) >= 12;
  }
  
  static bool __guc_rc_selected(struct intel_guc *guc)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f2ce4bde6a68..b177cdeee1ec 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6469,15 +6469,6 @@
  /*   XEHP_PCODE_FREQUENCY_CONFIG param2 */
  #define PCODE_MBOX_DOMAIN_NONE0x0
  #define PCODE_MBOX_DOMAIN_MEDIAFF 0x3
-
-/* Wa_14017210380: mtl */
-#define   PCODE_MBOX_GT_STATE  0x50
-/* sub-commands (param1) */
-#define PCODE_MBOX_GT_STATE_MEDIA_BUSY 0x1
-#define PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY 0x2
-/* param2 */
-#define PCODE_MBOX_GT_STATE_DOMAIN_MEDIA   0x1
-
  #define GEN6_PCODE_DATA   _MMIO(0x138128)
  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT  8
  #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT16

Re: [Intel-gfx] [PATCH 2/2] drm/i915/mtl: Disable MC6 for MTL A step

[Nilawar, Badal]

Hi Rodrigo,

On 08-03-2023 18:59, Rodrigo Vivi wrote:

On Wed, Mar 08, 2023 at 03:51:09PM +0530, Badal Nilawar wrote:

The Wa_14017073508 require to send Media Busy/Idle mailbox while
accessing Media tile. As of now it is getting handled while __gt_unpark,
__gt_park. But there are various corner cases where forcewakes are taken
without __gt_unpark i.e. without sending Busy Mailbox especially during
register reads. Forcewakes are taken without busy mailbox leads to
GPU HANG. So bringing mailbox calls under forcewake calls are no feasible
option as forcewake calls are atomic and mailbox calls are blocking.
The issue already fixed in B step so disabling MC6 on A step and
reverting previous commits which handles Wa_14017073508

Fixes: 8f70f1ec587d ("drm/i915/mtl: Add Wa_14017073508 for SAMedia")
Cc: Rodrigo Vivi 
Signed-off-by: Badal Nilawar 


This patch should probably come before the revert itself.

Reviewed-by: Rodrigo Vivi 


Thanks for RB. I will put this patch before revert.

Regards,
Badal Nilawar



---
  drivers/gpu/drm/i915/gt/intel_rc6.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c 
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 5c91622dfca4..f4150f61f39c 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -486,6 +486,7 @@ static bool bxt_check_bios_rc6_setup(struct intel_rc6 *rc6)
  static bool rc6_supported(struct intel_rc6 *rc6)
  {
struct drm_i915_private *i915 = rc6_to_i915(rc6);
+   struct intel_gt *gt = rc6_to_gt(rc6);
  
  	if (!HAS_RC6(i915))

return false;
@@ -502,6 +503,13 @@ static bool rc6_supported(struct intel_rc6 *rc6)
return false;
}
  
+	if (IS_MTL_MEDIA_STEP(gt->i915, STEP_A0, STEP_B0) &&

+   gt->type == GT_MEDIA) {
+   drm_notice(>drm,
+  "Media RC6 disabled on A step\n");
+   return false;
+   }
+
return true;
  }
  
--

2.25.1

Re: [Intel-gfx] [PATCH v10 03/13] drm/i915/dp: Add Scaler constraint for YCbCr420 output

[Ville Syrjälä]

On Mon, Feb 27, 2023 at 09:33:14AM +0530, Ankit Nautiyal wrote:
> For YCbCr420 output, scaler is required for downsampling.
> Scaler can be used only when source size smaller than max_src_w and
> max_src_h as defined by for the platform.
> So go for native YCbCr420 only if there are no scaler constraints.
> 
> v2: Corrected max-width based on Display Version.
> 
> v3: Updated max-width as per latest Bspec change.
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 41 ++---
>  1 file changed, 37 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1a30cc021b25..e95fc0f0d13a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -804,11 +804,36 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp 
> *intel_dp,
>   return 0;
>  }
>  
> +static bool
> +ycbcr420_scaler_constraints(struct drm_i915_private *i915,
> + const struct drm_display_mode *mode)
> +{
> + int max_src_w, max_src_h;
> +
> + if (DISPLAY_VER(i915) < 11) {
> + max_src_w = 4096;
> + max_src_h = 4096;
> + } else if (DISPLAY_VER(i915) < 12) {
> + max_src_w = 5120;
> + max_src_h = 4096;
> + } else if (DISPLAY_VER(i915) < 14) {
> + max_src_w = 5120;
> + max_src_h = 8192;
> + } else {
> + max_src_w = 4096;
> + max_src_h = 8192;
> + }
> +
> + return mode->hdisplay > max_src_w || mode->vdisplay > max_src_h;
> +}
> +

I don't really like this. If we do something like this
then it should be the scaler code that checks this stuff.

However, after pondering about this more I'm actually
leaning towards using 4:4:4 output whenever possible,
only going for 4:2:0 if absolutely necessary. That
avoids having to deal with all the annoying scaler/etc
limitations.

>  static enum intel_output_format
>  intel_dp_output_format(struct intel_connector *connector,
> +const struct drm_display_mode *mode,
>  enum intel_output_format sink_format)
>  {
>   struct intel_dp *intel_dp = intel_attached_dp(connector);
> + struct drm_i915_private *i915 = to_i915(connector->base.dev);
>  
>   if (!connector->base.ycbcr_420_allowed ||
>   sink_format != INTEL_OUTPUT_FORMAT_YCBCR420)
> @@ -820,8 +845,15 @@ intel_dp_output_format(struct intel_connector *connector,
>  
>   if (intel_dp->dfp.ycbcr_444_to_420)
>   return INTEL_OUTPUT_FORMAT_YCBCR444;
> - else
> +
> + /*
> +  * For YCbCr420 output, scaler is required for downsampling
> +  * So go for native YCbCr420 only if there are no scaler constraints.
> +  */
> + if (!ycbcr420_scaler_constraints(i915, mode))
>   return INTEL_OUTPUT_FORMAT_YCBCR420;
> +
> + return INTEL_OUTPUT_FORMAT_RGB;
>  }
>  
>  int intel_dp_min_bpp(enum intel_output_format output_format)
> @@ -857,7 +889,7 @@ intel_dp_mode_min_output_bpp(struct intel_connector 
> *connector,
>   else
>   sink_format = INTEL_OUTPUT_FORMAT_RGB;
>  
> - output_format = intel_dp_output_format(connector, sink_format);
> + output_format = intel_dp_output_format(connector, mode, sink_format);
>  
>   return intel_dp_output_bpp(output_format, 
> intel_dp_min_bpp(output_format));
>  }
> @@ -2052,7 +2084,8 @@ intel_dp_compute_output_format(struct intel_encoder 
> *encoder,
>   crtc_state->sink_format = INTEL_OUTPUT_FORMAT_RGB;
>   }
>  
> - crtc_state->output_format = intel_dp_output_format(connector, 
> crtc_state->sink_format);
> + crtc_state->output_format = intel_dp_output_format(connector, 
> adjusted_mode,
> +
> crtc_state->sink_format);
>  
>   ret = intel_dp_compute_link_config(encoder, crtc_state, conn_state,
>  respect_downstream_limits);
> @@ -2063,7 +2096,7 @@ intel_dp_compute_output_format(struct intel_encoder 
> *encoder,
>   return ret;
>  
>   crtc_state->sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> - crtc_state->output_format = intel_dp_output_format(connector,
> + crtc_state->output_format = intel_dp_output_format(connector, 
> adjusted_mode,
>  
> crtc_state->sink_format);
>   ret = intel_dp_compute_link_config(encoder, crtc_state, 
> conn_state,
>  respect_downstream_limits);
> -- 
> 2.25.1

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

[Jason Gunthorpe]

On Wed, Mar 08, 2023 at 07:26:08AM +, Tian, Kevin wrote:
>  * Userspace requests hot reset for the devices it uses.  Due to the
>  * underlying topology, multiple devices can be affected in the reset
>  * while some might be opened by another user. To avoid interference
>  * the calling user must ensure all affected devices, if opened, are
>  * owned by itself.
>  *
>  * The ownership can be proved in three ways:
>  *   - An array of group fds
>  *   - An array of device fds
>  *   - A zero-length array
>  *
>  * In the last case all affected devices which are opened by this user must
>  * have been bound to a same iommufd_ctx.
> 
> and with this change let's rename 'group_fds'  to 'fds'

Looks right

Jason

[Intel-gfx] ✗ Fi.CI.BAT: failure for vfio: Make emulated devices prepared for vfio device cdev

[Patchwork]

== Series Details ==

Series: vfio: Make emulated devices prepared for vfio device cdev
URL   : https://patchwork.freedesktop.org/series/114846/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114846v1


Summary
---

  **FAILURE**

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

Participating hosts (35 -> 36)
--

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@dmabuf@all-tests@dma_fence:
- fi-kbl-7567u:   [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v1/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html

  * igt@dmabuf@all-tests@sanitycheck:
- fi-kbl-7567u:   [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v1/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_auth@basic-auth:
- fi-kbl-soraka:  NOTRUN -> [DMESG-WARN][5] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v1/fi-kbl-soraka/igt@core_a...@basic-auth.html

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

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

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

  * igt@gem_mmap@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][9] ([i915#4083])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v1/bat-dg1-6/igt@gem_m...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][10] ([i915#4079]) +1 similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v1/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][11] ([i915#4077]) +2 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v1/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg1-6:  NOTRUN -> [SKIP][12] ([i915#7561])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v1/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-6:  NOTRUN -> [SKIP][13] ([i915#6621])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v1/bat-dg1-6/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@client:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][14] ([i915#7609])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v1/fi-kbl-soraka/igt@i915_selftest@l...@client.html

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

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

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-6:  NOTRUN -> [SKIP][17] ([i915#4215])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v1/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg1-6:  NOTRUN -> [SKIP][18] ([i915#4212]) +7 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v1/bat-dg1-6/igt@kms_addfb_ba...@tile-pitch-mismatch.html

Re: [Intel-gfx] [Intel-xe] [PATCH] drm/xe/display: Do not use i915 frontbuffer tracking implementation

[Ville Syrjälä]

On Wed, Mar 08, 2023 at 03:29:45PM +0100, Maarten Lankhorst wrote:
> Hey,
> 
> 
> On 2023-03-08 14:36, Ville Syrjälä wrote:
> > On Wed, Mar 08, 2023 at 01:47:12PM +0100, Maarten Lankhorst wrote:
> >> On 2023-03-06 21:58, Ville Syrjälä wrote:
> >>> On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten Lankhorst wrote:
>  Hey,
> 
>  On 2023-03-06 16:23, Souza, Jose wrote:
> > On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote:
> >> As a fallback if we decide not to merge the frontbuffer tracking, allow
> >> i915 to keep its own implementation, and do the right thing in Xe.
> >>
> >> The frontbuffer tracking for Xe is still done per-fb, while i915 can
> >> keep doing the weird intel_frontbuffer + i915_active thing without
> >> blocking Xe.
> > Please also disable PSR and FBC with this or at least add a way for 
> > users to disable those features.
> > Without frontbuffer tracker those two features will break in some cases.
>  FBC and PSR work completely as expected. I don't remove frontbuffer
>  tracking; I only remove the GEM parts.
> 
>  Explicit invalidation using pageflip or CPU rendering + DirtyFB continue
>  to work, as I validated on my laptop with FBC.
> >>> Neither of which are relevant to the removal of the gem hooks.
> >>>
> >>> Like I already said ~10 times in the last meeting, we need a proper
> >>> testcase. Here's a rough idea what it should do:
> >>>
> >>> prepare a batch with
> >>> 1. spinner
> >>> 2. something that clobbers the fb
> >>>
> >>> Then
> >>> 1. grab reference crc
> >>> 2. execbuffer
> >>> 3. dirtyfb
> >>> 4. wait long enough for fbc to recompress
> >>> 5. terminate spinner
> >>> 6. gem_sync
> >>> 7. grab crc and compare with reference
> >>>
> >>> No idea what the current status of PSR+CRC is, so not sure
> >>> whether we can actually test PSR or not.
> >> This test doesn't make sense. DirtyFB should simply not return before
> >> execbuffer finishes.
> > Of course it should. It's not a blocking ioctl, and can't
> > be because that will make X unusable.
> 
> Except it actually is.
> 
> DirtyFB blocks in its default implementation, and waits for the next vblank.
> 
> drm_atomic_helper_dirtyfb() blocks by default as it's a synchronous 
> plane update.
> 
> Considering every driver except i915 uses it, it works just fine. :)

No it doesn't. We tries to use it, but that was an utter failure.

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [Intel-xe] [PATCH] drm/xe/display: Do not use i915 frontbuffer tracking implementation

[Maarten Lankhorst]

Hey,


On 2023-03-08 14:36, Ville Syrjälä wrote:

On Wed, Mar 08, 2023 at 01:47:12PM +0100, Maarten Lankhorst wrote:

On 2023-03-06 21:58, Ville Syrjälä wrote:

On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten Lankhorst wrote:

Hey,

On 2023-03-06 16:23, Souza, Jose wrote:

On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote:

As a fallback if we decide not to merge the frontbuffer tracking, allow
i915 to keep its own implementation, and do the right thing in Xe.

The frontbuffer tracking for Xe is still done per-fb, while i915 can
keep doing the weird intel_frontbuffer + i915_active thing without
blocking Xe.

Please also disable PSR and FBC with this or at least add a way for users to 
disable those features.
Without frontbuffer tracker those two features will break in some cases.

FBC and PSR work completely as expected. I don't remove frontbuffer
tracking; I only remove the GEM parts.

Explicit invalidation using pageflip or CPU rendering + DirtyFB continue
to work, as I validated on my laptop with FBC.

Neither of which are relevant to the removal of the gem hooks.

Like I already said ~10 times in the last meeting, we need a proper
testcase. Here's a rough idea what it should do:

prepare a batch with
1. spinner
2. something that clobbers the fb

Then
1. grab reference crc
2. execbuffer
3. dirtyfb
4. wait long enough for fbc to recompress
5. terminate spinner
6. gem_sync
7. grab crc and compare with reference

No idea what the current status of PSR+CRC is, so not sure
whether we can actually test PSR or not.

This test doesn't make sense. DirtyFB should simply not return before
execbuffer finishes.

Of course it should. It's not a blocking ioctl, and can't
be because that will make X unusable.


Except it actually is.

DirtyFB blocks in its default implementation, and waits for the next vblank.

drm_atomic_helper_dirtyfb() blocks by default as it's a synchronous 
plane update.


Considering every driver except i915 uses it, it works just fine. :)

~Maarten

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for vfio: Make emulated devices prepared for vfio device cdev

[Patchwork]

== Series Details ==

Series: vfio: Make emulated devices prepared for vfio device cdev
URL   : https://patchwork.freedesktop.org/series/114846/
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:148: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:148: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:148: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:148: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:148: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:148: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:148: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: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:150:9: warning: unreplaced symbol 'oldbit'
+./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:150:9: warning: unreplaced symbol 'oldbit'
+./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:150:9: warning: unreplaced symbol 'oldbit'
+./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:150:9: warning: unreplaced symbol 'oldbit'
+./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:150:9: warning: unreplaced symbol 'oldbit'
+./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:150:9: warning: unreplaced symbol 'oldbit'

[Intel-gfx] [PATCH] MAINTAINERS: update the 01.org website entries

[Lukas Bulwahn]

The 01.org links in MAINTAINERS now forward to different other pages or do
not resolve.

The link https://01.org/linuxgraphics/ resolves to the Intel Graphics for
Linux - Programmer's Reference Manuals. Update this webpage entry.

The link
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
does not resolve. Remove this webpage entry.

The link https://01.org/igvt-g resolves to
https://github.com/intel/gvt-linux. Remove the webpage entry, as the
github repository is already referred to by the T: entry in that section.

The link resolves the pm-graph project page in Intel's Open Ecosystem area
at intel.com. Update this webpage entry.

M:  "Todd E Brandt" 
L:  linux...@vger.kernel.org

Signed-off-by: Lukas Bulwahn 
---
 MAINTAINERS | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1333928a7be4..99adcd74b06a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6747,7 +6747,6 @@ M:Maarten Lankhorst 

 M: Maxime Ripard 
 M: Thomas Zimmermann 
 S: Maintained
-W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
 T: git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/gpu/
 F: drivers/gpu/drm/*
@@ -10250,7 +10249,7 @@ M:  Rodrigo Vivi 
 M: Tvrtko Ursulin 
 L: intel-gfx@lists.freedesktop.org
 S: Supported
-W: https://01.org/linuxgraphics/
+W: 
https://www.intel.com/content/www/us/en/develop/documentation/intel-graphics-for-linux-programmers-reference-guide/top.html
 Q: http://patchwork.freedesktop.org/project/intel-gfx/
 B: https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
 C: irc://irc.oftc.net/intel-gfx
@@ -10312,7 +10311,6 @@ M:  Zhi Wang 
 L: intel-gvt-...@lists.freedesktop.org
 L: intel-gfx@lists.freedesktop.org
 S: Supported
-W: https://01.org/igvt-g
 T: git https://github.com/intel/gvt-linux.git
 F: drivers/gpu/drm/i915/gvt/
 
@@ -16668,7 +1,7 @@ PM-GRAPH UTILITY
 M: "Todd E Brandt" 
 L: linux...@vger.kernel.org
 S: Supported
-W: https://01.org/pm-graph
+W: 
https://www.intel.com/content/www/us/en/developer/topic-technology/open/pm-graph/overview.html
 B: https://bugzilla.kernel.org/buglist.cgi?component=pm-graph=Tools
 T: git git://github.com/intel/pm-graph
 F: tools/power/pm-graph
-- 
2.17.1

[Intel-gfx] [PATCH v2] drm/i915/gt: prevent forcewake releases during BAR resize

[Andrzej Hajda]

Tests on DG2 machines show that releasing forcewakes during BAR resize
results later in forcewake ack timeouts. Since forcewakes can be realeased
asynchronously the simplest way to prevent it is to get all forcewakes
for duration of BAR resizing.

v2: hold rpm as well during resizing (Rodrigo)

Signed-off-by: Andrzej Hajda 
---
Please ignore resend of v1, my mistake.

Regards
Andrzej
---
 drivers/gpu/drm/i915/gt/intel_region_lmem.c | 25 +++--
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 89fdfc67f8d1e0..2a3217e2890fc7 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -54,6 +54,7 @@ static void i915_resize_lmem_bar(struct drm_i915_private 
*i915, resource_size_t
struct resource *root_res;
resource_size_t rebar_size;
resource_size_t current_size;
+   intel_wakeref_t wakeref;
u32 pci_cmd;
int i;
 
@@ -102,15 +103,25 @@ static void i915_resize_lmem_bar(struct drm_i915_private 
*i915, resource_size_t
return;
}
 
-   /* First disable PCI memory decoding references */
-   pci_read_config_dword(pdev, PCI_COMMAND, _cmd);
-   pci_write_config_dword(pdev, PCI_COMMAND,
-  pci_cmd & ~PCI_COMMAND_MEMORY);
+   /*
+* Releasing forcewake during BAR resizing results in later forcewake
+* ack timeouts and former can happen any time - it is asynchronous.
+* Grabbing all forcewakes prevents it.
+*/
+   with_intel_runtime_pm(i915->uncore.rpm, wakeref) {
+   intel_uncore_forcewake_get(>uncore, FORCEWAKE_ALL);
 
-   _resize_bar(i915, GEN12_LMEM_BAR, rebar_size);
+   /* First disable PCI memory decoding references */
+   pci_read_config_dword(pdev, PCI_COMMAND, _cmd);
+   pci_write_config_dword(pdev, PCI_COMMAND,
+  pci_cmd & ~PCI_COMMAND_MEMORY);
 
-   pci_assign_unassigned_bus_resources(pdev->bus);
-   pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
+   _resize_bar(i915, GEN12_LMEM_BAR, rebar_size);
+
+   pci_assign_unassigned_bus_resources(pdev->bus);
+   pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
+   intel_uncore_forcewake_put(>uncore, FORCEWAKE_ALL);
+   }
 }
 #else
 static void i915_resize_lmem_bar(struct drm_i915_private *i915, 
resource_size_t lmem_size) {}
-- 
2.34.1

Re: [Intel-gfx] [Intel-xe] [PATCH] drm/xe/display: Do not use i915 frontbuffer tracking implementation

[Ville Syrjälä]

On Wed, Mar 08, 2023 at 01:47:12PM +0100, Maarten Lankhorst wrote:
> 
> On 2023-03-06 21:58, Ville Syrjälä wrote:
> > On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten Lankhorst wrote:
> >> Hey,
> >>
> >> On 2023-03-06 16:23, Souza, Jose wrote:
> >>> On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote:
>  As a fallback if we decide not to merge the frontbuffer tracking, allow
>  i915 to keep its own implementation, and do the right thing in Xe.
> 
>  The frontbuffer tracking for Xe is still done per-fb, while i915 can
>  keep doing the weird intel_frontbuffer + i915_active thing without
>  blocking Xe.
> >>> Please also disable PSR and FBC with this or at least add a way for users 
> >>> to disable those features.
> >>> Without frontbuffer tracker those two features will break in some cases.
> >> FBC and PSR work completely as expected. I don't remove frontbuffer
> >> tracking; I only remove the GEM parts.
> >>
> >> Explicit invalidation using pageflip or CPU rendering + DirtyFB continue
> >> to work, as I validated on my laptop with FBC.
> > Neither of which are relevant to the removal of the gem hooks.
> >
> > Like I already said ~10 times in the last meeting, we need a proper
> > testcase. Here's a rough idea what it should do:
> >
> > prepare a batch with
> > 1. spinner
> > 2. something that clobbers the fb
> >
> > Then
> > 1. grab reference crc
> > 2. execbuffer
> > 3. dirtyfb
> > 4. wait long enough for fbc to recompress
> > 5. terminate spinner
> > 6. gem_sync
> > 7. grab crc and compare with reference
> >
> > No idea what the current status of PSR+CRC is, so not sure
> > whether we can actually test PSR or not.
> 
> This test doesn't make sense. DirtyFB should simply not return before 
> execbuffer finishes.

Of course it should. It's not a blocking ioctl, and can't
be because that will make X unusable.

-- 
Ville Syrjälä
Intel

[Intel-gfx] [PATCH] drm/i915/gt: prevent forcewake releases during BAR resize

[Andrzej Hajda]

Tests on DG2 machines show that releasing forcewakes during BAR resize
results later in forcewake ack timeouts. Since forcewakes can be realeased
asynchronously the simplest way to prevent it is to get all forcewakes
for duration of BAR resizing.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/intel_region_lmem.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 89fdfc67f8d1e0..5a01dc6ca08324 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -54,6 +54,7 @@ static void i915_resize_lmem_bar(struct drm_i915_private 
*i915, resource_size_t
struct resource *root_res;
resource_size_t rebar_size;
resource_size_t current_size;
+   intel_wakeref_t wakeref;
u32 pci_cmd;
int i;
 
@@ -102,6 +103,14 @@ static void i915_resize_lmem_bar(struct drm_i915_private 
*i915, resource_size_t
return;
}
 
+   /*
+* Releasing forcewake during BAR resizing results in later forcewake
+* ack timeouts and former can happen any time - it is asynchronous.
+* Grabbing all forcewakes prevents it.
+*/
+   with_intel_runtime_pm(i915->uncore.rpm, wakeref)
+   intel_uncore_forcewake_get(>uncore, FORCEWAKE_ALL);
+
/* First disable PCI memory decoding references */
pci_read_config_dword(pdev, PCI_COMMAND, _cmd);
pci_write_config_dword(pdev, PCI_COMMAND,
@@ -111,6 +120,9 @@ static void i915_resize_lmem_bar(struct drm_i915_private 
*i915, resource_size_t
 
pci_assign_unassigned_bus_resources(pdev->bus);
pci_write_config_dword(pdev, PCI_COMMAND, pci_cmd);
+
+   with_intel_runtime_pm(i915->uncore.rpm, wakeref)
+   intel_uncore_forcewake_put(>uncore, FORCEWAKE_ALL);
 }
 #else
 static void i915_resize_lmem_bar(struct drm_i915_private *i915, 
resource_size_t lmem_size) {}
-- 
2.34.1

[Intel-gfx] [PATCH v6 24/24] docs: vfio: Add vfio device cdev description

[Yi Liu]

This gives notes for userspace applications on device cdev usage.

Signed-off-by: Yi Liu 
---
 Documentation/driver-api/vfio.rst | 125 ++
 1 file changed, 125 insertions(+)

diff --git a/Documentation/driver-api/vfio.rst 
b/Documentation/driver-api/vfio.rst
index 44527420f20d..227940e5224f 100644
--- a/Documentation/driver-api/vfio.rst
+++ b/Documentation/driver-api/vfio.rst
@@ -239,6 +239,123 @@ group and can access them as follows::
/* Gratuitous device reset and go... */
ioctl(device, VFIO_DEVICE_RESET);
 
+IOMMUFD and vfio_iommu_type1
+
+
+IOMMUFD is the new user API to manage I/O page tables from userspace.
+It intends to be the portal of delivering advanced userspace DMA
+features (nested translation [5], PASID [6], etc.) and backward
+compatible with the vfio_iommu_type1 driver. Eventually vfio_iommu_type1
+will be deprecated.
+
+With the backward compatibility, no change is required for legacy VFIO
+drivers or applications to connect a VFIO device to IOMMUFD.
+
+   When CONFIG_IOMMUFD_VFIO_CONTAINER=n, VFIO container still provides
+   /dev/vfio/vfio which connects to vfio_iommu_type1. To disable VFIO
+   container and vfio_iommu_type1, the administrator could symbol link
+   /dev/vfio/vfio to /dev/iommu to enable VFIO container emulation
+   in IOMMUFD.
+
+   When CONFIG_IOMMUFD_VFIO_CONTAINER=y, IOMMUFD directly provides
+   /dev/vfio/vfio while the VFIO container and vfio_iommu_type1 are
+   explicitly disabled.
+
+VFIO Device cdev
+
+
+Traditionally user acquires a device fd via VFIO_GROUP_GET_DEVICE_FD
+in a VFIO group.
+
+With CONFIG_VFIO_DEVICE_CDEV=y the user can now acquire a device fd
+by directly opening a character device /dev/vfio/devices/vfioX where
+"X" is the number allocated uniquely by VFIO for registered devices.
+
+The cdev only works with IOMMUFD. Both VFIO drivers and applications
+must adapt to the new cdev security model which requires using
+VFIO_DEVICE_BIND_IOMMUFD to claim DMA ownership before starting to
+actually use the device. Once bind succeeds then a VFIO device can
+be fully accessed by the user.
+
+VFIO device cdev doesn't rely on VFIO group/container/iommu drivers.
+Hence those modules can be fully compiled out in an environment
+where no legacy VFIO application exists.
+
+So far SPAPR does not support IOMMUFD yet. So it cannot support device
+cdev either.
+
+Device cdev Example
+---
+
+Assume user wants to access PCI device :6a:01.0::
+
+   $ ls /sys/bus/pci/devices/:6a:01.0/vfio-dev/
+   vfio0
+
+This device is therefore represented as vfio0. The user can verify
+its existence::
+
+   $ ls -l /dev/vfio/devices/vfio0
+   crw--- 1 root root 511, 0 Feb 16 01:22 /dev/vfio/devices/vfio0
+   $ cat /sys/bus/pci/devices/:6a:01.0/vfio-dev/vfio0/dev
+   511:0
+   $ ls -l /dev/char/511\:0
+   lrwxrwxrwx 1 root root 21 Feb 16 01:22 /dev/char/511:0 -> 
../vfio/devices/vfio0
+
+Then provide the user with access to the device if unprivileged
+operation is desired::
+
+   $ chown user:user /dev/vfio/devices/vfio0
+
+Finally the user could get cdev fd by::
+
+   cdev_fd = open("/dev/vfio/devices/vfio0", O_RDWR);
+
+An opened cdev_fd doesn't give the user any permission of accessing
+the device except binding the cdev_fd to an iommufd. After that point
+then the device is fully accessible including attaching it to an
+IOMMUFD IOAS/HWPT to enable userspace DMA::
+
+   struct vfio_device_bind_iommufd bind = {
+   .argsz = sizeof(bind),
+   .flags = 0,
+   };
+   struct iommu_ioas_alloc alloc_data  = {
+   .size = sizeof(alloc_data),
+   .flags = 0,
+   };
+   struct vfio_device_attach_iommufd_pt attach_data = {
+   .argsz = sizeof(attach_data),
+   .flags = 0,
+   };
+   struct iommu_ioas_map map = {
+   .size = sizeof(map),
+   .flags = IOMMU_IOAS_MAP_READABLE |
+IOMMU_IOAS_MAP_WRITEABLE |
+IOMMU_IOAS_MAP_FIXED_IOVA,
+   .__reserved = 0,
+   };
+
+   iommufd = open("/dev/iommu", O_RDWR);
+
+   bind.iommufd = iommufd; // negative iommufd means vfio-noiommu mode
+   ioctl(cdev_fd, VFIO_DEVICE_BIND_IOMMUFD, );
+
+   ioctl(iommufd, IOMMU_IOAS_ALLOC, _data);
+   attach_data.pt_id = alloc_data.out_ioas_id;
+   ioctl(cdev_fd, VFIO_DEVICE_ATTACH_IOMMUFD_PT, _data);
+
+   /* Allocate some space and setup a DMA mapping */
+   map.user_va = (int64_t)mmap(0, 1024 * 1024, PROT_READ | PROT_WRITE,
+   MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+   map.iova = 0; /* 1MB starting at 0x0 from device view */
+   map.length = 1024 * 1024;
+   map.ioas_id = alloc_data.out_ioas_id;;
+
+   ioctl(iommufd, IOMMU_IOAS_MAP, );
+
+   /* Other device