[Intel-gfx] ✓ Fi.CI.BAT: success for Fix modeset locking issue in HDCP MST
== Series Details ==
Series: Fix modeset locking issue in HDCP MST
URL : https://patchwork.freedesktop.org/series/117615/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13131 -> Patchwork_117615v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/index.html
Participating hosts (40 -> 39)
--
Additional (1): bat-mtlp-6
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117615v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-7567u: [PASS][1] -> [DMESG-FAIL][2] ([i915#5334])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html
- fi-apl-guc: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.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_13131/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-WARN][7] ([i915#6367] / [i915#7953])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-2: NOTRUN -> [ABORT][8] ([i915#6687])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-1: NOTRUN -> [ABORT][9] ([i915#6687] / [i915#7953] /
[i915#7978])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_pipe_crc_basic@read-crc:
- bat-adlp-9: NOTRUN -> [SKIP][10] ([i915#3546]) +1 similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html
Possible fixes
* igt@dmabuf@all-tests@dma_fence:
- fi-kbl-7567u: [DMESG-FAIL][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html
* igt@dmabuf@all-tests@sanitycheck:
- fi-kbl-7567u: [ABORT][13] -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-8}: [ABORT][15] ([i915#4983] / [i915#7920] / [i915#7953])
-> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-mtlp-8/igt@i915_selftest@l...@requests.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@reset:
- bat-rpls-2: [ABORT][17] ([i915#4983] / [i915#7461] / [i915#7913]
/ [i915#8347]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-rpls-2/igt@i915_selftest@l...@reset.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
- bat-rpls-1: [ABORT][19] ([i915#4983] / [i915#7461] / [i915#7953]
/ [i915#7981] / [i915#8347] / [i915#8384]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-rpls-1/igt@i915_selftest@l...@reset.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
Warnings
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: [SKIP][21] ([i915#3555] / [i915#4579]) -> [ABORT][22]
([i915#8260])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117615v1/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL
== Series Details ==
Series: series starting with [1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL
URL : https://patchwork.freedesktop.org/series/117607/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13131_full -> Patchwork_117607v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117607v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s3@smem:
- {shard-dg1}:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-dg1-16/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/shard-dg1-13/igt@gem_exec_suspend@basic...@smem.html
Known issues
Here are the changes found in Patchwork_117607v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-apl: [PASS][5] -> [DMESG-FAIL][6] ([i915#5334])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl4/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/shard-apl4/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_async_flips@alternate-sync-async-flip@pipe-c-dp-1:
- shard-apl: [PASS][7] -> [FAIL][8] ([i915#2521])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl7/igt@kms_async_flips@alternate-sync-async-f...@pipe-c-dp-1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/shard-apl3/igt@kms_async_flips@alternate-sync-async-f...@pipe-c-dp-1.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2346])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/shard-glk6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][11] -> [FAIL][12] ([i915#2346]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a2:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#79])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk8/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/shard-glk8/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a2.html
Possible fixes
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [FAIL][15] ([i915#2842]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][17] ([i915#2842]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-rkl-1/igt@gem_exec_fair@basic-p...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/shard-rkl-7/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_suspend@basic-s4-devices@smem:
- {shard-tglu}: [ABORT][19] ([i915#7953] / [i915#7975] / [i915#8213])
-> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devi...@smem.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/shard-tglu-7/igt@gem_exec_suspend@basic-s4-devi...@smem.html
* igt@i915_pm_rc6_residency@rc6-idle@vecs0:
- {shard-dg1}:[FAIL][21] ([i915#3591]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-dg1-12/igt@i915_pm_rc6_residency@rc6-i...@vecs0.html
[22]:
https://intel-gfx-ci.01.org/tr
[Intel-gfx] [PATCH 2/2] drm/i915/hdcp: Fix modeset locking issue in hdcp mst
Since topology state is being added to drm_atomic_state now all
drm_modeset_lock required are being taken from core this raises
an issue when we try to loop over connector and assign vcpi id to
our streams as we did not have atomic state to derive acquire_ctx
from hence we fill in stream info if dpmst encoder is found before
enabling hdcp.
Cc: Jani Nikula
Cc: Ankit Nautiyal
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_display_types.h| 2 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 26 ++-
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 35c260bd1461..aecd84b66735 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1813,6 +1813,8 @@ struct intel_digital_port {
struct hdcp_port_data hdcp_port_data;
/* Whether the MST topology supports HDCP Type 1 Content */
bool hdcp_mst_type1_capable;
+ /* If streams for HDCP MST are assigned with vcpi id and stream type */
+ int hdcp_mst_streams_ready;
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 1928c80cb6a2..d2874431c9d3 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -30,7 +30,8 @@
#define KEY_LOAD_TRIES 5
#define HDCP2_LC_RETRY_CNT 3
-static int intel_conn_to_vcpi(struct intel_connector *connector)
+static int intel_conn_to_vcpi(struct drm_atomic_state *state,
+ struct intel_connector *connector)
{
struct drm_dp_mst_topology_mgr *mgr;
struct drm_dp_mst_atomic_payload *payload;
@@ -42,7 +43,7 @@ static int intel_conn_to_vcpi(struct intel_connector
*connector)
return 0;
mgr = connector->port->mgr;
- drm_modeset_lock(&mgr->base.lock, NULL);
+ drm_modeset_lock(&mgr->base.lock, state->acquire_ctx);
mst_state = to_drm_dp_mst_topology_state(mgr->base.state);
payload = drm_atomic_get_mst_payload_state(mst_state, connector->port);
if (drm_WARN_ON(mgr->dev, !payload))
@@ -54,7 +55,6 @@ static int intel_conn_to_vcpi(struct intel_connector
*connector)
goto out;
}
out:
- drm_modeset_unlock(&mgr->base.lock);
return vcpi;
}
@@ -69,7 +69,8 @@ static int intel_conn_to_vcpi(struct intel_connector
*connector)
* policy to mark different content_types for different streams.
*/
static int
-intel_hdcp_required_content_stream(struct intel_digital_port *dig_port)
+intel_hdcp_required_content_stream(struct intel_digital_port *dig_port,
+ struct intel_atomic_state *state)
{
struct drm_connector_list_iter conn_iter;
struct intel_digital_port *conn_dig_port;
@@ -81,9 +82,6 @@ intel_hdcp_required_content_stream(struct intel_digital_port
*dig_port)
data->k = 0;
- if (dig_port->hdcp_auth_status)
- return 0;
-
drm_connector_list_iter_begin(&i915->drm, &conn_iter);
for_each_intel_connector_iter(connector, &conn_iter) {
if (connector->base.status == connector_status_disconnected)
@@ -99,7 +97,8 @@ intel_hdcp_required_content_stream(struct intel_digital_port
*dig_port)
if (!enforce_type0 && !dig_port->hdcp_mst_type1_capable)
enforce_type0 = true;
- data->streams[data->k].stream_id =
intel_conn_to_vcpi(connector);
+ data->streams[data->k].stream_id =
+ intel_conn_to_vcpi(&state->base, connector);
data->k++;
/* if there is only one active stream */
@@ -127,15 +126,12 @@ static int intel_hdcp_prepare_streams(struct
intel_connector *connector)
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct hdcp_port_data *data = &dig_port->hdcp_port_data;
struct intel_hdcp *hdcp = &connector->hdcp;
- int ret;
if (!intel_encoder_is_mst(intel_attached_encoder(connector))) {
data->k = 1;
data->streams[0].stream_type = hdcp->content_type;
} else {
- ret = intel_hdcp_required_content_stream(dig_port);
- if (ret)
- return ret;
+ return dig_port->hdcp_mst_streams_ready;
}
return 0;
@@ -2373,6 +2369,12 @@ int intel_hdcp_enable(struct intel_atomic_state *state,
* is capable of HDCP2.2, it is preferred to use HDCP2.2.
*/
if (intel_hdcp2_capable(connector)) {
+ if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
+ dig_port-
[Intel-gfx] [PATCH 1/2] drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function
Pass all the parameter in intel_encoder->enable()
to intel_hdcp_enable as we need intel_atomic_state
later down to get acquire_ctx.
Cc: Jani Nikula
Cc: Ankit Nautiyal
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_ddi.c| 5 +++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++--
drivers/gpu/drm/i915/display/intel_hdcp.c | 12 +++-
drivers/gpu/drm/i915/display/intel_hdcp.h | 6 --
4 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 29e4bfab4635..e838d56415cd 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3264,9 +3264,10 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
/* Enable hdcp if it's desired */
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector),
+ intel_hdcp_enable(state,
to_intel_connector(conn_state->connector),
crtc_state,
- (u8)conn_state->hdcp_content_type);
+ conn_state);
+
}
static void intel_disable_ddi_dp(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 2c49d9ab86a2..e1e040434a97 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -800,9 +800,9 @@ static void intel_mst_enable_dp(struct intel_atomic_state
*state,
/* Enable hdcp if it's desired */
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector),
+ intel_hdcp_enable(state,
to_intel_connector(conn_state->connector),
pipe_config,
- (u8)conn_state->hdcp_content_type);
+ conn_state);
}
static bool intel_dp_mst_enc_get_hw_state(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 650232c4892b..1928c80cb6a2 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2330,8 +2330,10 @@ int intel_hdcp_init(struct intel_connector *connector,
return 0;
}
-int intel_hdcp_enable(struct intel_connector *connector,
- const struct intel_crtc_state *pipe_config, u8
content_type)
+int intel_hdcp_enable(struct intel_atomic_state *state,
+ struct intel_connector *connector,
+ const struct intel_crtc_state *pipe_config,
+ const struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
@@ -2352,7 +2354,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
mutex_lock(&dig_port->hdcp_mutex);
drm_WARN_ON(&dev_priv->drm,
hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
- hdcp->content_type = content_type;
+ hdcp->content_type = (u8)conn_state->content_type;
if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
@@ -2483,9 +2485,9 @@ void intel_hdcp_update_pipe(struct intel_atomic_state
*state,
}
if (desired_and_not_enabled || content_protection_type_changed)
- intel_hdcp_enable(connector,
+ intel_hdcp_enable(state, connector,
crtc_state,
- (u8)conn_state->hdcp_content_type);
+ conn_state);
}
void intel_hdcp_component_fini(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 8f53b0c7fe5c..6aaec4df6f6c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -28,8 +28,10 @@ void intel_hdcp_atomic_check(struct drm_connector *connector,
int intel_hdcp_init(struct intel_connector *connector,
struct intel_digital_port *dig_port,
const struct intel_hdcp_shim *hdcp_shim);
-int intel_hdcp_enable(struct intel_connector *connector,
- const struct intel_crtc_state *pipe_config, u8
content_type);
+int intel_hdcp_enable(struct intel_atomic_state *state,
+ struct intel_connector *connector,
+ const struct intel_crtc_state *pipe_config,
+ const struct drm_connector_state *conn_state);
int intel_hdcp_disable(struct
[Intel-gfx] [PATCH 0/2] Fix modeset locking issue in HDCP MST
HDCP MST scenario sees modeset locking issue ever since topology_state was added to drm_atomic_state and all modeset locks were being taken for us causing a locking issue to occur when we iterate over connectors to assign vcpi id, the fix being to pass acquire_ctx to drm_modeset_lock Signed-off-by: Suraj Kandpal Suraj Kandpal (2): drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function drm/i915/hdcp: Fix modeset locking issue in hdcp mst drivers/gpu/drm/i915/display/intel_ddi.c | 5 ++- .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 38 ++- drivers/gpu/drm/i915/display/intel_hdcp.h | 6 ++- 5 files changed, 32 insertions(+), 23 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH] drm/i915: Use REG_BIT() & co. for AUX CH registers
On Tue, 2023-05-09 at 20:14 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Modernize the DP AUX CH register definitions with REG_BIT() & co. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jouni Högander > > --- > drivers/gpu/drm/i915/display/intel_dp_aux.c | 35 +-- > .../gpu/drm/i915/display/intel_dp_aux_regs.h | 62 ++--- > -- > drivers/gpu/drm/i915/gvt/edid.c | 10 +-- > 3 files changed, 52 insertions(+), 55 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c > b/drivers/gpu/drm/i915/display/intel_dp_aux.c > index abf77ba76972..25e36bdc4adb 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c > @@ -161,14 +161,14 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp > *intel_dp, > timeout = DP_AUX_CH_CTL_TIME_OUT_400us; > > return DP_AUX_CH_CTL_SEND_BUSY | > - DP_AUX_CH_CTL_DONE | > - DP_AUX_CH_CTL_INTERRUPT | > - DP_AUX_CH_CTL_TIME_OUT_ERROR | > - timeout | > - DP_AUX_CH_CTL_RECEIVE_ERROR | > - (send_bytes << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) | > - (g4x_dp_aux_precharge_len() << > DP_AUX_CH_CTL_PRECHARGE_2US_SHIFT) | > - (aux_clock_divider << > DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT); > + DP_AUX_CH_CTL_DONE | > + DP_AUX_CH_CTL_INTERRUPT | > + DP_AUX_CH_CTL_TIME_OUT_ERROR | > + timeout | > + DP_AUX_CH_CTL_RECEIVE_ERROR | > + DP_AUX_CH_CTL_MESSAGE_SIZE(send_bytes) | > + DP_AUX_CH_CTL_PRECHARGE_2US(g4x_dp_aux_precharge_len( > )) | > + DP_AUX_CH_CTL_BIT_CLOCK_2X(aux_clock_divider); > } > > static u32 skl_get_aux_send_ctl(struct intel_dp *intel_dp, > @@ -185,14 +185,14 @@ static u32 skl_get_aux_send_ctl(struct intel_dp > *intel_dp, > * ICL+: 4ms > */ > ret = DP_AUX_CH_CTL_SEND_BUSY | > - DP_AUX_CH_CTL_DONE | > - DP_AUX_CH_CTL_INTERRUPT | > - DP_AUX_CH_CTL_TIME_OUT_ERROR | > - DP_AUX_CH_CTL_TIME_OUT_MAX | > - DP_AUX_CH_CTL_RECEIVE_ERROR | > - (send_bytes << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) | > - > DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(intel_dp_aux_fw_sync_len()) | > - DP_AUX_CH_CTL_SYNC_PULSE_SKL(intel_dp_aux_sync_len()); > + DP_AUX_CH_CTL_DONE | > + DP_AUX_CH_CTL_INTERRUPT | > + DP_AUX_CH_CTL_TIME_OUT_ERROR | > + DP_AUX_CH_CTL_TIME_OUT_MAX | > + DP_AUX_CH_CTL_RECEIVE_ERROR | > + DP_AUX_CH_CTL_MESSAGE_SIZE(send_bytes) | > + DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(intel_dp_aux_fw_sync_ > len()) | > + DP_AUX_CH_CTL_SYNC_PULSE_SKL(intel_dp_aux_sync_len()) > ; > > if (intel_tc_port_in_tbt_alt_mode(dig_port)) > ret |= DP_AUX_CH_CTL_TBT_IO; > @@ -378,8 +378,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp, > } > > /* Unload any bytes sent back from the other side */ > - recv_bytes = ((status & DP_AUX_CH_CTL_MESSAGE_SIZE_MASK) >> > - DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT); > + recv_bytes = REG_FIELD_GET(DP_AUX_CH_CTL_MESSAGE_SIZE_MASK, > status); > > /* > * By BSpec: "Message sizes of 0 or >20 are not allowed." > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_regs.h > b/drivers/gpu/drm/i915/display/intel_dp_aux_regs.h > index 5702f318d537..5185345277c7 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_regs.h > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_regs.h > @@ -50,35 +50,37 @@ > > _XELPDP_USBC3_AUX_CH_DATA1, \ > > _XELPDP_USBC4_AUX_CH_DATA1) + (i) * 4) > > -#define DP_AUX_CH_CTL_SEND_BUSY (1 << 31) > -#define DP_AUX_CH_CTL_DONE (1 << 30) > -#define DP_AUX_CH_CTL_INTERRUPT (1 << 29) > -#define DP_AUX_CH_CTL_TIME_OUT_ERROR (1 << 28) > -#define DP_AUX_CH_CTL_TIME_OUT_400us (0 << 26) > -#define DP_AUX_CH_CTL_TIME_OUT_600us (1 << 26) > -#define DP_AUX_CH_CTL_TIME_OUT_800us (2 << 26) > -#define DP_AUX_CH_CTL_TIME_OUT_MAX (3 << 26) /* Varies per > platform */ > -#define DP_AUX_CH_CTL_TIME_OUT_MASK (3 << 26) > -#define DP_AUX_CH_CTL_RECEIVE_ERROR (1 << 25) > -#define DP_AUX_CH_CTL_MESSAGE_SIZE_MASK (0x1f << 20) > -#define DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT 20 > -#define XELPDP_DP_AUX_CH_CTL_POWER_REQUEST REG_BIT(19) > -#define XELPDP_DP_AUX_CH_CTL_POWER_STATUS REG_BIT(18) > -#define DP_AUX_CH_CTL_PRECHARGE_2US_MASK (0xf << 16) > -#define DP_AUX_CH_CTL_PRECHARGE_2US_SHIFT 16 > -#define DP_AUX_CH_CTL_AUX_AKSV_SELECT (1 << 15) > -#define DP_AUX_CH_CTL_MANCHESTER_TEST (1 << 14) > -#define DP_AUX_
Re: [Intel-gfx] [PATCH] drm/i915: Fix typo in intel_frontbuffer
On Wed, 2023-05-10 at 11:10 +0200, Andi Shyti wrote:
> Hi Jouni,
Hi Andi, thank you for checking my patch.
>
> On Wed, May 10, 2023 at 11:50:43AM +0300, Jouni Högander wrote:
> > Fix obvious typo in intel_frontbuffer forward declaration.
> >
> > Signed-off-by: Jouni Högander
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > index 830c11431ee8..cb362b09bf21 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > @@ -18,7 +18,7 @@
> > #include "i915_vma_resource.h"
> >
> > struct drm_i915_gem_object;
> > -struct intel_fronbuffer;
> > +struct intel_frontbuffer;
>
> Then I guess this is not necessary.
Removing it is also possible. I was thinking as i915_gem_object
contains intel_frontbuffer pointer keeping it would be more correct:
struct drm_i915_gem_object {
...
struct intel_frontbuffer __rcu *frontbuffer;
...
}
> Andi
>
> > struct intel_memory_region;
> >
> > /*
> > --
> > 2.34.1
BR,
Jouni Högander
Re: [Intel-gfx] [PATCH] drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function
> On Thu, 04 May 2023, Suraj Kandpal wrote:
> > Since topology state is being added to drm_atomic_state now all
> > drm_modeset_lock required are being taken from core this raises an
> > issue when we try to loop over connector and assign vcpi id to our
> > streams as we did not have atomic state to derive acquire_ctx from
> > hence we fill in stream info if dpmst encoder is found before enabling
> > hdcp.
> >
> > Cc: Ankit Nautiyal
> > Signed-off-by: Suraj Kandpal
>
> The subject implies you're just passing an extra parameter, but that's really
> not the case. You're doing something else, and to achieve that, you also pass
> an extra parameter.
>
> One approach might be to have a separate patch to change the parameters
> only, and it might be sensible to actually pass all the
> intel_encoder->enable() parameters i.e.
>
> (struct intel_atomic_state *state,
> struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config, const struct drm_connector_state
> *conn_state)
>
Sure Jani will break the patch into two and pass all the
intel_encoder->enable() params
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c| 3 +-
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 50 ++---
> > drivers/gpu/drm/i915/display/intel_hdcp.h | 3 +-
> > 4 files changed, 49 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 29e4bfab4635..182b8815b20d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3264,9 +3264,10 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,
> > /* Enable hdcp if it's desired */
> > if (conn_state->content_protection ==
> > DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > - intel_hdcp_enable(to_intel_connector(conn_state-
> >connector),
> > + intel_hdcp_enable(state, to_intel_connector(conn_state-
> >connector),
> > crtc_state,
> > (u8)conn_state->hdcp_content_type);
> > +
> > }
> >
> > static void intel_disable_ddi_dp(struct intel_atomic_state *state,
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 2c49d9ab86a2..c92b00ceaae0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -800,7 +800,7 @@ static void intel_mst_enable_dp(struct
> intel_atomic_state *state,
> > /* Enable hdcp if it's desired */
> > if (conn_state->content_protection ==
> > DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > - intel_hdcp_enable(to_intel_connector(conn_state-
> >connector),
> > + intel_hdcp_enable(state, to_intel_connector(conn_state-
> >connector),
> > pipe_config,
> > (u8)conn_state->hdcp_content_type);
> > }
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index e1dc3d96e708..c8cdf25914f7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -30,7 +30,8 @@
> > #define KEY_LOAD_TRIES 5
> > #define HDCP2_LC_RETRY_CNT 3
> >
> > -static int intel_conn_to_vcpi(struct intel_connector *connector)
> > +static int intel_conn_to_vcpi(struct intel_connector *connector,
> > + struct drm_atomic_state *state)
> > {
> > struct drm_dp_mst_topology_mgr *mgr;
> > struct drm_dp_mst_atomic_payload *payload; @@ -42,7 +43,7 @@
> static
> > int intel_conn_to_vcpi(struct intel_connector *connector)
> > return 0;
> > mgr = connector->port->mgr;
> >
> > - drm_modeset_lock(&mgr->base.lock, NULL);
> > + drm_modeset_lock(&mgr->base.lock, state->acquire_ctx);
>
> The return value must be checked and handled for ctx != NULL. Please git
> grep for examples.
>
> > mst_state = to_drm_dp_mst_topology_state(mgr->base.state);
> > payload = drm_atomic_get_mst_payload_state(mst_state,
> connector->port);
> > if (drm_WARN_ON(mgr->dev, !payload)) @@ -54,7 +55,6 @@ static
> int
> > intel_conn_to_vcpi(struct intel_connector *connector)
> > goto out;
> > }
> > out:
> > - drm_modeset_unlock(&mgr->base.lock);
> > return vcpi;
> > }
> >
> > @@ -99,7 +99,6 @@ intel_hdcp_required_content_stream(struct
> intel_digital_port *dig_port)
> > if (!enforce_type0 && !dig_port->hdcp_mst_type1_capable)
> > enforce_type0 = true;
> >
> > - data->streams[data->k].stream_id =
> intel_conn_to_vcpi(connector);
> > data->k++;
> >
> > /* if there is only one active stream */ @@ -122,6 +121,41
> @@
> > intel_hdcp_required_content_stream(struct intel_digital_port *dig_port)
> > return 0
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i1915/guc: Fix probe injection CI failures after recent change
== Series Details ==
Series: drm/i1915/guc: Fix probe injection CI failures after recent change
URL : https://patchwork.freedesktop.org/series/117600/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13131_full -> Patchwork_117600v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_117600v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_117600v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117600v1_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_isolation@preservation-s3@vecs0:
- shard-apl: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl1/igt@gem_ctx_isolation@preservation...@vecs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/shard-apl6/igt@gem_ctx_isolation@preservation...@vecs0.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- {shard-dg1}:[PASS][3] -> [DMESG-WARN][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-dg1-17/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/shard-dg1-16/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
Known issues
Here are the changes found in Patchwork_117600v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/shard-glk9/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2346])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/shard-glk1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2346])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#2122])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk1/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@ab-hdmi-a1-hdmi-a2.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/shard-glk7/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@ab-hdmi-a1-hdmi-a2.html
* igt@kms_hdr@bpc-switch-dpms@pipe-a-dp-1:
- shard-apl: [PASS][13] -> [FAIL][14] ([i915#1188])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl7/igt@kms_hdr@bpc-switch-d...@pipe-a-dp-1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/shard-apl1/igt@kms_hdr@bpc-switch-d...@pipe-a-dp-1.html
* igt@kms_plane@pixel-format-source-clamping@pipe-b-planes:
- shard-glk: [PASS][15] -> [DMESG-FAIL][16] ([i915#118])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk7/igt@kms_plane@pixel-format-source-clamp...@pipe-b-planes.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/shard-glk2/igt@kms_plane@pixel-format-source-clamp...@pipe-b-planes.html
Possible fixes
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][17] ([i915#6268]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-rkl-6/igt@gem_ctx_e...@basic-nohangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/shard-rkl-3/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- {shard-rkl}:[FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-rkl-2/igt@gem_exec_fair@basic-throt...@rcs0.html
[20]:
https://intel-g
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hwmon: Silence UBSAN uninitialized bool variable warning
== Series Details ==
Series: drm/i915/hwmon: Silence UBSAN uninitialized bool variable warning
URL : https://patchwork.freedesktop.org/series/117591/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13131_full -> Patchwork_117591v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_117591v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_117591v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117591v1_full:
### IGT changes ###
Possible regressions
* igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-apl: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl3/igt@kms_flip@flip-vs-susp...@c-dp1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/shard-apl6/igt@kms_flip@flip-vs-susp...@c-dp1.html
Known issues
Here are the changes found in Patchwork_117591v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-apl: [PASS][3] -> [ABORT][4] ([i915#7461] / [i915#8211] /
[i915#8234])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl1/igt@gem_barrier_race@remote-requ...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/shard-apl1/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][7] -> [ABORT][8] ([i915#5566])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2346])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/shard-glk6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][11] -> [FAIL][12] ([i915#2346])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_hdr@bpc-switch-dpms@pipe-a-dp-1:
- shard-apl: [PASS][13] -> [FAIL][14] ([i915#1188])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl7/igt@kms_hdr@bpc-switch-d...@pipe-a-dp-1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/shard-apl2/igt@kms_hdr@bpc-switch-d...@pipe-a-dp-1.html
* igt@perf@stress-open-close@0-rcs0:
- shard-apl: [PASS][15] -> [ABORT][16] ([i915#5213])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl1/igt@perf@stress-open-cl...@0-rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/shard-apl4/igt@perf@stress-open-cl...@0-rcs0.html
Possible fixes
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [FAIL][17] ([i915#2842]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-none@vecs0:
- {shard-rkl}:[FAIL][19] ([i915#2842]) -> [PASS][20] +2 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-rkl-3/igt@gem_exec_fair@basic-n...@vecs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/shard-rkl-7/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][21] ([i915#2842]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/sh
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pxp: Add MTL PXP Support (rev11)
== Series Details ==
Series: drm/i915/pxp: Add MTL PXP Support (rev11)
URL : https://patchwork.freedesktop.org/series/112647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13131_full -> Patchwork_112647v11_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_112647v11_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-glk: [PASS][1] -> [ABORT][2] ([i915#7461] / [i915#8211])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk2/igt@gem_barrier_race@remote-requ...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-glk1/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-glk2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_mmap_gtt@fault-concurrent-y:
- shard-snb: [PASS][5] -> [ABORT][6] ([i915#5161])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-snb2/igt@gem_mmap_...@fault-concurrent-y.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-snb2/igt@gem_mmap_...@fault-concurrent-y.html
* igt@gem_spin_batch@spin-each:
- shard-apl: [PASS][7] -> [FAIL][8] ([i915#2898])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl3/igt@gem_spin_ba...@spin-each.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-apl3/igt@gem_spin_ba...@spin-each.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [PASS][9] -> [ABORT][10] ([i915#5566])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl3/igt@gen9_exec_pa...@allowed-single.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-apl7/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_selftest@live@dmabuf:
- shard-apl: [PASS][11] -> [DMESG-FAIL][12] ([i915#7562])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl4/igt@i915_selftest@l...@dmabuf.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-apl7/igt@i915_selftest@l...@dmabuf.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [PASS][13] -> [FAIL][14] ([i915#2346])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_hdr@bpc-switch-dpms@pipe-a-dp-1:
- shard-apl: [PASS][15] -> [FAIL][16] ([i915#1188])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl7/igt@kms_hdr@bpc-switch-d...@pipe-a-dp-1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-apl1/igt@kms_hdr@bpc-switch-d...@pipe-a-dp-1.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][17] ([i915#7742]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [FAIL][19] ([i915#2842]) -> [PASS][20] +1 similar
issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-apl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- {shard-rkl}:[FAIL][21] ([i915#2842]) -> [PASS][22] +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-rkl-2/igt@gem_exec_fair@basic-throt...@rcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-rkl-2/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_exec_suspend@basic-s4-devices@smem:
- {shard-tglu}: [ABORT][23] ([i915#7953] / [i915#7975] / [i915#8213])
-> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devi...@smem.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/shard-tglu-3/igt@gem_exec_suspend@basic-s4-devi...@smem.html
* igt@i915_pm_r
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL
== Series Details ==
Series: series starting with [1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL
URL : https://patchwork.freedesktop.org/series/117607/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13131 -> Patchwork_117607v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/index.html
Participating hosts (40 -> 40)
--
Additional (1): bat-mtlp-6
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117607v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][1] -> [DMESG-WARN][2] ([i915#7699] /
[i915#7953])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][3] ([i915#6367])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-2: NOTRUN -> [ABORT][4] ([i915#6687])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-1: NOTRUN -> [ABORT][5] ([i915#6687] / [i915#7953] /
[i915#7978])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][6] ([i915#1845] / [i915#5354]) +2
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1:
- bat-dg2-8: [PASS][7] -> [FAIL][8] ([i915#7932])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
Possible fixes
* igt@dmabuf@all-tests@dma_fence:
- fi-kbl-7567u: [DMESG-FAIL][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html
* igt@dmabuf@all-tests@sanitycheck:
- fi-kbl-7567u: [ABORT][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html
* igt@i915_hangman@error-state-basic:
- fi-kbl-soraka: [INCOMPLETE][13] -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-soraka/igt@i915_hang...@error-state-basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/fi-kbl-soraka/igt@i915_hang...@error-state-basic.html
* igt@i915_selftest@live@reset:
- bat-rpls-1: [ABORT][15] ([i915#4983] / [i915#7461] / [i915#7953]
/ [i915#7981] / [i915#8347] / [i915#8384]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-rpls-1/igt@i915_selftest@l...@reset.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
- bat-rpls-2: [ABORT][17] ([i915#4983] / [i915#7461] / [i915#7913]
/ [i915#8347]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-rpls-2/igt@i915_selftest@l...@reset.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117607v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4078]: https://gi
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: RFC: Introduce Wa_14011282866
== Series Details == Series: drm/i915: RFC: Introduce Wa_14011282866 URL : https://patchwork.freedesktop.org/series/117604/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13131 -> Patchwork_117604v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_117604v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_117604v1, 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_117604v1/index.html Participating hosts (40 -> 39) -- Additional (1): bat-mtlp-6 Missing(2): fi-kbl-soraka fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_117604v1: ### IGT changes ### Possible regressions * igt@i915_module_load@load: - fi-rkl-11600: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-rkl-11600/igt@i915_module_l...@load.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/fi-rkl-11600/igt@i915_module_l...@load.html - bat-adls-5: [PASS][3] -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-adls-5/igt@i915_module_l...@load.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/bat-adls-5/igt@i915_module_l...@load.html - bat-dg1-5: [PASS][5] -> [ABORT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-dg1-5/igt@i915_module_l...@load.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/bat-dg1-5/igt@i915_module_l...@load.html - bat-dg1-7: [PASS][7] -> [ABORT][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-dg1-7/igt@i915_module_l...@load.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/bat-dg1-7/igt@i915_module_l...@load.html - bat-adln-1: [PASS][9] -> [ABORT][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-adln-1/igt@i915_module_l...@load.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/bat-adln-1/igt@i915_module_l...@load.html - bat-adlm-1: [PASS][11] -> [ABORT][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-adlm-1/igt@i915_module_l...@load.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/bat-adlm-1/igt@i915_module_l...@load.html - bat-rplp-1: [PASS][13] -> [ABORT][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-rplp-1/igt@i915_module_l...@load.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/bat-rplp-1/igt@i915_module_l...@load.html - bat-rpls-2: [PASS][15] -> [ABORT][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-rpls-2/igt@i915_module_l...@load.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/bat-rpls-2/igt@i915_module_l...@load.html Known issues Here are the changes found in Patchwork_117604v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@load: - bat-rpls-1: [PASS][17] -> [ABORT][18] ([i915#7953]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-rpls-1/igt@i915_module_l...@load.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/bat-rpls-1/igt@i915_module_l...@load.html - bat-adlp-6: [PASS][19] -> [ABORT][20] ([i915#8189]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-adlp-6/igt@i915_module_l...@load.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/bat-adlp-6/igt@i915_module_l...@load.html - bat-adlp-9: [PASS][21] -> [ABORT][22] ([i915#8189]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-adlp-9/igt@i915_module_l...@load.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/bat-adlp-9/igt@i915_module_l...@load.html - bat-dg2-11: [PASS][23] -> [ABORT][24] ([i915#7953] / [i915#8189]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-dg2-11/igt@i915_module_l...@load.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/bat-dg2-11/igt@i915_module_l...@load.html - fi-tgl-1115g4: [PASS][25] -> [ABORT][26] ([i915#7953] / [i915#8189]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-tgl-1115g4/igt@i915_module_l...@load.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117604v1/fi-tgl-1115g4/igt@i915_module_l...@load.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1: - bat-dg2-8: [PASS][27] -> [FAIL][28] ([i915#7932]) [27]: https:/
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i1915/guc: Fix probe injection CI failures after recent change
== Series Details ==
Series: drm/i1915/guc: Fix probe injection CI failures after recent change
URL : https://patchwork.freedesktop.org/series/117600/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13131 -> Patchwork_117600v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/index.html
Participating hosts (40 -> 40)
--
Additional (1): bat-mtlp-6
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117600v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][1] ([i915#6367])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-kbl-7567u: NOTRUN -> [ABORT][2] ([i915#8299])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/fi-kbl-7567u/igt@i915_susp...@basic-s2idle-without-i915.html
- bat-rpls-2: NOTRUN -> [ABORT][3] ([i915#6687])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1:
- bat-dg2-8: [PASS][4] -> [FAIL][5] ([i915#7932]) +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][6] ([i915#3546]) +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc-frame-sequence.html
Possible fixes
* igt@dmabuf@all-tests@dma_fence:
- fi-kbl-7567u: [DMESG-FAIL][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html
* igt@dmabuf@all-tests@sanitycheck:
- fi-kbl-7567u: [ABORT][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html
* igt@i915_hangman@error-state-basic:
- fi-kbl-soraka: [INCOMPLETE][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-soraka/igt@i915_hang...@error-state-basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/fi-kbl-soraka/igt@i915_hang...@error-state-basic.html
* igt@i915_selftest@live@reset:
- bat-rpls-2: [ABORT][13] ([i915#4983] / [i915#7461] / [i915#7913]
/ [i915#8347]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-rpls-2/igt@i915_selftest@l...@reset.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
Warnings
* igt@i915_selftest@live@reset:
- bat-rpls-1: [ABORT][15] ([i915#4983] / [i915#7461] / [i915#7953]
/ [i915#7981] / [i915#8347] / [i915#8384]) -> [ABORT][16] ([i915#4983] /
[i915#7461] / [i915#7953] / [i915#8347] / [i915#8384])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-rpls-1/igt@i915_selftest@l...@reset.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117600v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4342]: https://gitlab.freedesktop.org/drm/intel/is
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hwmon: Silence UBSAN uninitialized bool variable warning
== Series Details ==
Series: drm/i915/hwmon: Silence UBSAN uninitialized bool variable warning
URL : https://patchwork.freedesktop.org/series/117591/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13131 -> Patchwork_117591v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/index.html
Participating hosts (40 -> 40)
--
Additional (1): bat-mtlp-6
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117591v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [PASS][1] -> [FAIL][2] ([i915#7932])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
Possible fixes
* igt@dmabuf@all-tests@dma_fence:
- fi-kbl-7567u: [DMESG-FAIL][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html
* igt@dmabuf@all-tests@sanitycheck:
- fi-kbl-7567u: [ABORT][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html
* igt@i915_hangman@error-state-basic:
- fi-kbl-soraka: [INCOMPLETE][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-soraka/igt@i915_hang...@error-state-basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/fi-kbl-soraka/igt@i915_hang...@error-state-basic.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-8}: [ABORT][9] ([i915#4983] / [i915#7920] / [i915#7953])
-> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-mtlp-8/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html
Warnings
* igt@i915_selftest@live@reset:
- bat-rpls-1: [ABORT][11] ([i915#4983] / [i915#7461] / [i915#7953]
/ [i915#7981] / [i915#8347] / [i915#8384]) -> [ABORT][12] ([i915#4983] /
[i915#7461] / [i915#7953] / [i915#8347] / [i915#8384])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-rpls-1/igt@i915_selftest@l...@reset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117591v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4342]: https://gitlab.freedesktop.org/drm/intel/issues/4342
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
[i915#7461]: https://gitlab.freedesktop.org/drm/intel/issues/7461
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#7953]: https://gitlab.freedesktop
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Add MTL PXP Support (rev11)
== Series Details ==
Series: drm/i915/pxp: Add MTL PXP Support (rev11)
URL : https://patchwork.freedesktop.org/series/112647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13131 -> Patchwork_112647v11
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/index.html
Participating hosts (40 -> 40)
--
Additional (1): bat-mtlp-6
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112647v11 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0@smem:
- bat-jsl-3: [PASS][1] -> [ABORT][2] ([i915#5122])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_lrc:
- bat-dg2-11: [PASS][5] -> [INCOMPLETE][6] ([i915#7609] /
[i915#7913] / [i915#7953])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-jsl-3: [PASS][7] -> [FAIL][8] ([fdo#103375])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#1845] / [i915#5354]) +2
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8: [PASS][10] -> [FAIL][11] ([i915#7932])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
Possible fixes
* igt@dmabuf@all-tests@dma_fence:
- fi-kbl-7567u: [DMESG-FAIL][12] -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/fi-kbl-7567u/igt@dmabuf@all-tests@dma_fence.html
* igt@dmabuf@all-tests@sanitycheck:
- fi-kbl-7567u: [ABORT][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/fi-kbl-7567u/igt@dmabuf@all-te...@sanitycheck.html
* igt@i915_hangman@error-state-basic:
- fi-kbl-soraka: [INCOMPLETE][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-soraka/igt@i915_hang...@error-state-basic.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v11/fi-kbl-soraka/igt@i915_hang...@error-state-basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4342]: https://gitlab.freedesktop.org
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/pxp: Add MTL PXP Support (rev10)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev10) URL : https://patchwork.freedesktop.org/series/112647/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13131 -> Patchwork_112647v10 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_112647v10 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_112647v10, 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_112647v10/index.html Participating hosts (40 -> 40) -- Additional (1): bat-mtlp-6 Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_112647v10: ### IGT changes ### Possible regressions * igt@kms_flip@basic-flip-vs-modeset@b-dp1: - fi-apl-guc: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-apl-guc/igt@kms_flip@basic-flip-vs-mode...@b-dp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v10/fi-apl-guc/igt@kms_flip@basic-flip-vs-mode...@b-dp1.html * igt@kms_frontbuffer_tracking@basic: - fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-apl-guc/igt@kms_frontbuffer_track...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v10/fi-apl-guc/igt@kms_frontbuffer_track...@basic.html * igt@kms_psr@cursor_plane_move: - fi-kbl-soraka: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-soraka/igt@kms_psr@cursor_plane_move.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v10/fi-kbl-soraka/igt@kms_psr@cursor_plane_move.html Known issues Here are the changes found in Patchwork_112647v10 that come from known issues: ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - fi-apl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#7634]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v10/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_suspend@basic-s0@smem: - bat-jsl-3: [PASS][9] -> [ABORT][10] ([i915#5122]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v10/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html * igt@i915_module_load@reload: - fi-apl-guc: [PASS][11] -> [DMESG-WARN][12] ([i915#62] / [i915#7634] / [i915#8189]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-apl-guc/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v10/fi-apl-guc/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-apl-guc: [PASS][13] -> [DMESG-WARN][14] ([i915#1982] / [i915#62] / [i915#7634]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-apl-guc/igt@i915_pm_...@module-reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v10/fi-apl-guc/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][15] -> [DMESG-FAIL][16] ([i915#5334] / [i915#7872]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v10/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@reset: - fi-apl-guc: [PASS][17] -> [DMESG-WARN][18] ([i915#7634]) +33 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-apl-guc/igt@i915_selftest@l...@reset.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v10/fi-apl-guc/igt@i915_selftest@l...@reset.html * igt@i915_suspend@basic-s3-without-i915: - bat-jsl-3: [PASS][19] -> [FAIL][20] ([fdo#103375]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v10/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_flip@basic-flip-vs-modeset@c-dp1: - fi-apl-guc: [PASS][21] -> [DMESG-FAIL][22] ([i915#62]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13131/fi-apl-guc/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html [22]: https://intel-gfx-ci.01.org/tree/dr
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL
== Series Details == Series: series starting with [1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL URL : https://patchwork.freedesktop.org/series/117607/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bi
Re: [Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
> alan:snip > > Assuming that: > > 2 = PXP feature is supported but should be ready soon (pending > initialization of non-i915 system dependencies). > > really means, "it'll be ready soon or there is a bug somewhere", > > Acked-by: Jordan Justen > > If Mesa finds that it can't really rely on that, we may have to decide > on a different approach in how to use that return value. > > Is it possible to hold on for another ~12 hours to see if Lionel wants > to Ack as well? > > -Jordan alan: agreed and thanks. And sure, lets give ourselves till tomorrow afternoon PST.
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: RFC: Introduce Wa_14011282866
== Series Details == Series: drm/i915: RFC: Introduce Wa_14011282866 URL : https://patchwork.freedesktop.org/series/117604/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH 2/2] drm/i915/mtl: Add MTL performance tuning changes
MTL reuses the tuning parameters for DG2. Extend the dg2
performance tuning parameters to MTL.
Bspec: 68331
Cc: Matt Roper
Cc: Gustavo Sousa
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 786349e95487..b222a3d367c9 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -817,6 +817,8 @@ static void mtl_ctx_workarounds_init(struct intel_engine_cs
*engine,
{
struct drm_i915_private *i915 = engine->i915;
+ dg2_ctx_gt_tuning_init(engine, wal);
+
if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) {
/* Wa_14014947963 */
@@ -1754,7 +1756,7 @@ static void gt_tuning_settings(struct intel_gt *gt,
struct i915_wa_list *wal)
wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
}
- if (IS_DG2(gt->i915)) {
+ if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915)) {
wa_mcr_write_or(wal, XEHP_L3SCQREG7,
BLEND_FILL_CACHING_OPT_DIS);
wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
}
@@ -2944,7 +2946,7 @@ static void
add_render_compute_tuning_settings(struct drm_i915_private *i915,
struct i915_wa_list *wal)
{
- if (IS_DG2(i915))
+ if (IS_DG2(i915) || IS_METEORLAKE(i915))
wa_mcr_write_clr_set(wal, RT_CTRL, STACKID_CTRL,
STACKID_CTRL_512);
/*
--
2.34.1
[Intel-gfx] [PATCH 1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL
The dg2 workaround which is used for performance tuning is needed for Meteorlake. Bspec: 68331 Cc: Matt Roper Cc: Gustavo Sousa Signed-off-by: Radhakrishna Sripada --- drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 81a96c52a92b..78ec350188b6 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -1370,7 +1370,7 @@ gen12_emit_indirect_ctx_rcs(const struct intel_context *ce, u32 *cs) cs, GEN12_GFX_CCS_AUX_NV); /* Wa_16014892111 */ - if (IS_DG2(ce->engine->i915)) + if (IS_DG2(ce->engine->i915) || IS_METEORLAKE(ce->engine->i915)) cs = dg2_emit_draw_watermark_setting(cs); return cs; -- 2.34.1
Re: [Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
On 2023-05-10 15:00:03, Teres Alexis, Alan Previn wrote: > > alan:snip > > > This is why I asked if it was it was "basically certain that in a > > production environment, then it will eventually return 1 meaning it's > > ready". Alan's response was a little ambiguous on this point. > alan: if we get a '2' and never transition to '1' - thats a kernel bug or > firmware / system issue. > > > Arguably a transition from 2 to -ENODEV could be considered a kernel > > bug, but it doesn't sound like Alan would agree. :) Maybe Alan would > > agree to saying it's either a kernel, or system integration bug. > alan: agreed - that would be a kernel bug or a system integration bug. > > I also agreed on the init-flow vs app-usage thoughts Jordan had. > That said MESA has many ways it can use this UAPI and we can discuss > that on the MESA patch. > > > hmmm.. so... ack anyone? [insert big hopeful smiley here] > apologies if I am asking too often. Assuming that: 2 = PXP feature is supported but should be ready soon (pending initialization of non-i915 system dependencies). really means, "it'll be ready soon or there is a bug somewhere", Acked-by: Jordan Justen If Mesa finds that it can't really rely on that, we may have to decide on a different approach in how to use that return value. Is it possible to hold on for another ~12 hours to see if Lionel wants to Ack as well? -Jordan
Re: [Intel-gfx] [PATCH v7 4/4] drm/i915: Allow user to set cache at BO creation
Hi,
On Tue, May 09, 2023 at 09:59:42AM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> To comply with the design that buffer objects shall have immutable
> cache setting through out their life cycle, {set, get}_caching ioctl's
> are no longer supported from MTL onward. With that change caching
> policy can only be set at object creation time. The current code
> applies a default (platform dependent) cache setting for all objects.
> However this is not optimal for performance tuning. The patch extends
> the existing gem_create uAPI to let user set PAT index for the object
> at creation time.
> The new extension is platform independent, so UMD's can switch to using
> this extension for older platforms as well, while {set, get}_caching are
> still supported on these legacy paltforms for compatibility reason.
>
> Cc: Chris Wilson
> Cc: Matt Roper
> Cc: Andi Shyti
> Signed-off-by: Fei Yang
> Reviewed-by: Andi Shyti
just for a matter of completeness, this is new uapi is tested
through the "create-ext-set-pat" test case from the "gem_create"
igt test[1]. Can any of the igt maintainers give it a look,
comment and ack?
The mesa merge request is here [2]. As there is a merge request
in progress, would anyone from mesa be so kind to give an ack to
this patch, as well?
With the mesa ack in place this patch should be ready to go and
I'm looking forward to having it in.
Thanks,
Andi
[1] https://patchwork.freedesktop.org/patch/534955/?series=117185&rev=1
[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878
> ---
> drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 ++
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 6
> include/uapi/drm/i915_drm.h| 36 ++
> tools/include/uapi/drm/i915_drm.h | 36 ++
> 4 files changed, 114 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> index bfe1dbda4cb7..644a936248ad 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> @@ -245,6 +245,7 @@ struct create_ext {
> unsigned int n_placements;
> unsigned int placement_mask;
> unsigned long flags;
> + unsigned int pat_index;
> };
>
> static void repr_placements(char *buf, size_t size,
> @@ -394,11 +395,39 @@ static int ext_set_protected(struct i915_user_extension
> __user *base, void *data
> return 0;
> }
>
> +static int ext_set_pat(struct i915_user_extension __user *base, void *data)
> +{
> + struct create_ext *ext_data = data;
> + struct drm_i915_private *i915 = ext_data->i915;
> + struct drm_i915_gem_create_ext_set_pat ext;
> + unsigned int max_pat_index;
> +
> + BUILD_BUG_ON(sizeof(struct drm_i915_gem_create_ext_set_pat) !=
> + offsetofend(struct drm_i915_gem_create_ext_set_pat, rsvd));
> +
> + if (copy_from_user(&ext, base, sizeof(ext)))
> + return -EFAULT;
> +
> + max_pat_index = INTEL_INFO(i915)->max_pat_index;
> +
> + if (ext.pat_index > max_pat_index) {
> + drm_dbg(&i915->drm, "PAT index is invalid: %u\n",
> + ext.pat_index);
> + return -EINVAL;
> + }
> +
> + ext_data->pat_index = ext.pat_index;
> +
> + return 0;
> +}
> +
> static const i915_user_extension_fn create_extensions[] = {
> [I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
> [I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
> + [I915_GEM_CREATE_EXT_SET_PAT] = ext_set_pat,
> };
>
> +#define PAT_INDEX_NOT_SET0x
> /**
> * i915_gem_create_ext_ioctl - Creates a new mm object and returns a handle
> to it.
> * @dev: drm device pointer
> @@ -418,6 +447,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
> *data,
> if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
> return -EINVAL;
>
> + ext_data.pat_index = PAT_INDEX_NOT_SET;
> ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
> create_extensions,
> ARRAY_SIZE(create_extensions),
> @@ -454,5 +484,11 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
> *data,
> if (IS_ERR(obj))
> return PTR_ERR(obj);
>
> + if (ext_data.pat_index != PAT_INDEX_NOT_SET) {
> + i915_gem_object_set_pat_index(obj, ext_data.pat_index);
> + /* Mark pat_index is set by UMD */
> + obj->pat_set_by_user = true;
> + }
> +
> return i915_gem_publish(obj, file, &args->size, &args->handle);
> }
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 46a19b099ec8..97ac6fb37958 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -208,6 +208,12 @@ bool i915_gem_object_can_bypass_llc(struc
Re: [Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
alan:snip > This is why I asked if it was it was "basically certain that in a > production environment, then it will eventually return 1 meaning it's > ready". Alan's response was a little ambiguous on this point. alan: if we get a '2' and never transition to '1' - thats a kernel bug or firmware / system issue. > Arguably a transition from 2 to -ENODEV could be considered a kernel > bug, but it doesn't sound like Alan would agree. :) Maybe Alan would > agree to saying it's either a kernel, or system integration bug. alan: agreed - that would be a kernel bug or a system integration bug. I also agreed on the init-flow vs app-usage thoughts Jordan had. That said MESA has many ways it can use this UAPI and we can discuss that on the MESA patch. hmmm.. so... ack anyone? [insert big hopeful smiley here] apologies if I am asking too often.
[Intel-gfx] [PATCH] drm/i915: RFC: Introduce Wa_14011282866
From: Tilak Tangudu
Wa_14011282866 applies to RKL, ADL-S, ADL-P and TGL.
Allocate buffer pinned to GGTT and add WA to restore sampler power
context.
Bspec: 46247
Signed-off-by: Matt Atwood
Signed-off-by: Tilak Tangudu
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 ++
drivers/gpu/drm/i915/gt/intel_rc6.c | 88 +++
drivers/gpu/drm/i915/gt/intel_rc6_types.h | 3 +
3 files changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index b8a39c219b60..91cbdd24572f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -48,6 +48,11 @@
/* RCP unit config (Gen8+) */
#define RCP_CONFIG _MMIO(0xd08)
+#define CTX_WA_PTR _MMIO(0x2058)
+#define CTX_WA_PTR_ADDR_MASK REG_GENMASK(31, 12)
+#define CTX_WA_TYPE_MASK REG_GENMASK(4, 3)
+#define CTX_WA_VALID REG_BIT(0)
+
#define RC6_LOCATION _MMIO(0xd40)
#define RC6_CTX_IN_DRAM (1 << 0)
#define RC6_CTX_BASE _MMIO(0xd48)
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 908a3d0f2343..9589af2e8ca3 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -12,6 +12,7 @@
#include "i915_vgpu.h"
#include "intel_engine_regs.h"
#include "intel_gt.h"
+#include "intel_gpu_commands.h"
#include "intel_gt_pm.h"
#include "intel_gt_regs.h"
#include "intel_pcode.h"
@@ -38,6 +39,7 @@
* require higher latency to switch to and wake up.
*/
+#define RC6_CTX_WA_BB_SIZE (PAGE_SIZE)
static struct intel_gt *rc6_to_gt(struct intel_rc6 *rc6)
{
return container_of(rc6, struct intel_gt, rc6);
@@ -53,8 +55,86 @@ static struct drm_i915_private *rc6_to_i915(struct intel_rc6
*rc)
return rc6_to_gt(rc)->i915;
}
+static int rc6_wa_bb_ctx_init(struct intel_rc6 *rc6)
+{
+ struct drm_i915_private *i915 = rc6_to_i915(rc6);
+ struct intel_gt *gt = rc6_to_gt(rc6);
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ void *batch;
+ struct i915_gem_ww_ctx ww;
+ int err;
+
+ obj = i915_gem_object_create_shmem(i915, RC6_CTX_WA_BB_SIZE);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ vma = i915_vma_instance(obj, >->ggtt->vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err;
+ }
+ rc6->vma = vma;
+ i915_gem_ww_ctx_init(&ww, true);
+retry:
+ err = i915_gem_object_lock(rc6->vma->obj, &ww);
+ if (!err)
+ err = i915_ggtt_pin(rc6->vma, &ww, 0, PIN_HIGH);
+ if (err)
+ goto err_ww_fini;
+
+ batch = i915_gem_object_pin_map(rc6->vma->obj, I915_MAP_WB);
+ if (IS_ERR(batch)) {
+ err = PTR_ERR(batch);
+ goto err_unpin;
+ }
+ rc6->rc6_wa_bb = batch;
+ return 0;
+err_unpin:
+ if (err)
+ i915_vma_unpin(rc6->vma);
+err_ww_fini:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(&ww);
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini(&ww);
+
+ if (err)
+ i915_vma_put(rc6->vma);
+err:
+ i915_gem_object_put(obj);
+ return err;
+}
+
+static void rc6_wa_bb_restore_sampler_power_ctx(struct intel_rc6 *rc6)
+{
+ struct intel_uncore *uncore = rc6_to_uncore(rc6);
+ u32 *rc6_wa_bb;
+
+ if (!rc6->vma->obj)
+ return;
+
+ rc6_wa_bb = rc6->rc6_wa_bb;
+ *rc6_wa_bb++ = MI_NOOP;
+ *rc6_wa_bb++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_FORCE_POSTED;
+ *rc6_wa_bb++ = i915_mmio_reg_offset(GEN10_SAMPLER_MODE);
+ *rc6_wa_bb++ = _MASKED_BIT_ENABLE(ENABLE_SMALLPL);
+ *rc6_wa_bb++ = MI_NOOP;
+ *rc6_wa_bb++ = MI_BATCH_BUFFER_END;
+
+ i915_gem_object_flush_map(rc6->vma->obj);
+
+ intel_uncore_write(uncore, CTX_WA_PTR,
+ REG_FIELD_PREP(CTX_WA_PTR_ADDR_MASK,
+ i915_vma_offset(rc6->vma) &
GENMASK(19, 0)) |
+ CTX_WA_VALID);
+}
+
static void gen11_rc6_enable(struct intel_rc6 *rc6)
{
+ struct drm_i915_private *i915 = rc6_to_i915(rc6);
struct intel_gt *gt = rc6_to_gt(rc6);
struct intel_uncore *uncore = gt->uncore;
struct intel_engine_cs *engine;
@@ -103,6 +183,11 @@ static void gen11_rc6_enable(struct intel_rc6 *rc6)
intel_uncore_write_fw(uncore, GEN9_MEDIA_PG_IDLE_HYSTERESIS, 60);
intel_uncore_write_fw(uncore, GEN9_RENDER_PG_IDLE_HYSTERESIS, 60);
+ /* Wa_14011282866 Restore sampler power context */
+ if (IS_DG1(i915) || IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915) ||
+ IS_ALDERLAKE_S(i915) || IS_ALDERLAKE_P(i9
Re: [Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
...fixing some Cc email addresses I somehow mangled.
On 2023-05-10 12:40:07, Souza, Jose wrote:
> On Mon, 2023-05-08 at 17:49 +, Teres Alexis, Alan Previn wrote:
> > On Fri, 2023-05-05 at 00:39 -0700, Justen, Jordan L wrote:
> > > On 2023-05-04 22:30:07, Teres Alexis, Alan Previn wrote:
> > > > On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, Alan Previn wrote:
> > > > > Because of the additional firmware, component-driver and
> > > > > initialization depedencies required on MTL platform before a
> > > > > PXP context can be created, UMD calling for PXP creation as a
> > > > > way to get-caps can take a long time. An actual real world
> > > > > customer stack has seen this happen in the 4-to-8 second range
> > > > > after the kernel starts (which sees MESA's init appear in the
> > > > > middle of this range as the compositor comes up). To avoid
> > > > > unncessary delays experienced by the UMD for get-caps purposes,
> > > > > add a GET_PARAM for I915_PARAM_PXP_SUPPORT.
> > > > >
> > > > alan:snip.
> > > > Progress update on the UMD side - I'm working on patch for PR here:
> > > > https://gitlab.freedesktop.org/alan_previn_intel/mesa-alan-previn-features/-/commit/fb9d4fbfbef7dfd3f41df335cd31549fd39ddb57
> > > > but taking time to verify certain code paths
> > >
> > > Just to confirm, if I915_PARAM_PXP_STATUS returns 2 ("will be ready
> > > soon"), then it is basically certain that in a production environment,
> > > then it will eventually return 1 meaning it's ready, right?
> > alan: yes - but not 100%. non-platform-state-machine could still
> > cause unexpected failures for example, [1] if hw was fused in a way
> > that doesnt permit PXP or [2] enabling certain BIOS debug knobs
> > doesnt allow PXP. However at the moment, there is no way for us
> > to know for sure without actually creating a protected context.
> > Of course having hw-fusing + bios-config that supports PXP have
> > always 100% succeeded for me.
>
> In my opinion it is problematic mark that we support protected
> context but then it fails to create protected context.
This is why I asked if it was it was "basically certain that in a
production environment, then it will eventually return 1 meaning it's
ready". Alan's response was a little ambiguous on this point.
But, considering the number of applications that will need this
feature is low, combined with an extremely low chance that the kernel
will end up going from 2 (will be ready soon) to -ENODEV (will never
work), well, it seems worth considering advertising it with no delay
even if it later fails if used.
Arguably a transition from 2 to -ENODEV could be considered a kernel
bug, but it doesn't sound like Alan would agree. :) Maybe Alan would
agree to saying it's either a kernel, or system integration bug.
I think it'd also be ok if we didn't advertise support if an
application starts when the kernel is still in the 2 (will be ready
soon) state.
But, some environments might prefer to wait, so I think the kernel
uapi should stay as Alan has it now so we have the flexibility to
potentially accommodate this. (Perhaps with driconf, or a build flag,
or an env-var.)
-Jordan
Re: [Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
On 2023-05-10 12:40:07, Souza, Jose wrote:
> On Mon, 2023-05-08 at 17:49 +, Teres Alexis, Alan Previn wrote:
> > On Fri, 2023-05-05 at 00:39 -0700, Justen, Jordan L wrote:
> > > On 2023-05-04 22:30:07, Teres Alexis, Alan Previn wrote:
> > > > On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, Alan Previn wrote:
> > > > > Because of the additional firmware, component-driver and
> > > > > initialization depedencies required on MTL platform before a
> > > > > PXP context can be created, UMD calling for PXP creation as a
> > > > > way to get-caps can take a long time. An actual real world
> > > > > customer stack has seen this happen in the 4-to-8 second range
> > > > > after the kernel starts (which sees MESA's init appear in the
> > > > > middle of this range as the compositor comes up). To avoid
> > > > > unncessary delays experienced by the UMD for get-caps purposes,
> > > > > add a GET_PARAM for I915_PARAM_PXP_SUPPORT.
> > > > >
> > > > alan:snip.
> > > > Progress update on the UMD side - I'm working on patch for PR here:
> > > > https://gitlab.freedesktop.org/alan_previn_intel/mesa-alan-previn-features/-/commit/fb9d4fbfbef7dfd3f41df335cd31549fd39ddb57
> > > > but taking time to verify certain code paths
> > >
> > > Just to confirm, if I915_PARAM_PXP_STATUS returns 2 ("will be ready
> > > soon"), then it is basically certain that in a production environment,
> > > then it will eventually return 1 meaning it's ready, right?
> > alan: yes - but not 100%. non-platform-state-machine could still
> > cause unexpected failures for example, [1] if hw was fused in a way
> > that doesnt permit PXP or [2] enabling certain BIOS debug knobs
> > doesnt allow PXP. However at the moment, there is no way for us
> > to know for sure without actually creating a protected context.
> > Of course having hw-fusing + bios-config that supports PXP have
> > always 100% succeeded for me.
>
> In my opinion it is problematic mark that we support protected
> context but then it fails to create protected context.
This is why I asked if it was it was "basically certain that in a
production environment, then it will eventually return 1 meaning it's
ready". Alan's response was a little ambiguous on this point.
But, considering the number of applications that will need this
feature is low, combined with an extremely low chance that the kernel
will end up going from 2 (will be ready soon) to -ENODEV (will never
work), well, it seems worth considering advertising it with no delay
even if it later fails if used.
Arguably a transition from 2 to -ENODEV could be considered a kernel
bug, but it doesn't sound like Alan would agree. :) Maybe Alan would
agree to saying it's either a kernel, or system integration bug.
I think it'd also be ok if we didn't advertise support if an
application starts when the kernel is still in the 2 (will be ready
soon) state.
But, some environments might prefer to wait, so I think the kernel
uapi should stay as Alan has it now so we have the flexibility to
potentially accommodate this. (Perhaps with driconf, or a build flag,
or an env-var.)
-Jordan
[Intel-gfx] [PATCH] drm/i1915/guc: Fix probe injection CI failures after recent change
From: John Harrison
A recent change bumped a 'notice' message up to 'error' level for
debug builds to help trap incorrect configurations in CI systems.
Unfortunaetly, tha error condition in question is triggered by the
error injection probe test. So change the message again to be 'probe
error' level instead.
Signed-off-by: John Harrison
Fixes: 760133d42f0a ("drm/i915/uc: Make unexpected firmware versions an error
in debug builds")
Cc: John Harrison
Cc: Daniele Ceraolo Spurio
Cc: Rodrigo Vivi
Cc: Alan Previn
Cc: Lucas De Marchi
Cc: Jani Nikula
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 4ec7df9ed5ff3..e467d9af61876 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -18,7 +18,7 @@
#include "i915_reg.h"
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
-#define UNEXPECTED gt_err
+#define UNEXPECTED gt_probe_error
#else
#define UNEXPECTED gt_notice
#endif
--
2.39.1
Re: [Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
> > > > > Because of the additional firmware, component-driver and
> > > > > initialization depedencies required on MTL platform before a
> > > > > PXP context can be created, UMD calling for PXP creation as a
> > > > > way to get-caps can take a long time. An actual real world
> > > > > customer stack has seen this happen in the 4-to-8 second range
> > > > > after the kernel starts (which sees MESA's init appear in the
> > > > > middle of this range as the compositor comes up). To avoid
> > > > > unncessary delays experienced by the UMD for get-caps purposes,
> > > > > add a GET_PARAM for I915_PARAM_PXP_SUPPORT.
> > > > >
> > > > alan:snip.
> > > > Progress update on the UMD side - I'm working on patch for PR here:
> > > > https://gitlab.freedesktop.org/alan_previn_intel/mesa-alan-previn-features/-/commit/fb9d4fbfbef7dfd3f41df335cd31549fd39ddb57
> > > > but taking time to verify certain code paths
> > >
> > > Just to confirm, if I915_PARAM_PXP_STATUS returns 2 ("will be ready
> > > soon"), then it is basically certain that in a production environment,
> > > then it will eventually return 1 meaning it's ready, right?
> > alan: yes - but not 100%. non-platform-state-machine could still
> > cause unexpected failures for example, [1] if hw was fused in a way
> > that doesnt permit PXP or [2] enabling certain BIOS debug knobs
> > doesnt allow PXP. However at the moment, there is no way for us
> > to know for sure without actually creating a protected context.
> > Of course having hw-fusing + bios-config that supports PXP have
> > always 100% succeeded for me.
>
> In my opinion it is problematic mark that we support protected context but
> then it fails to create protected context.
>
> It should check the I915_PARAM_PXP_STATUS in
> i915_gem_supports_protected_context() return earlier if know that protected
> context is not supported.
> Then create a protected context so we know that all other calls will succeed.
Hi Jose, I think your comment WRT how MESA change coule be implemented. Right
now this UAPI
will provide all possible information: '-ENODEV'==no-support...
'1'==supported-and-read...
'2'==supported-but-not-ready.
Unfortunately the '2'->'1' transition is not something the kernel driver has
control over.
As per the earlier review comments in prior revs and weeks with others (Lionel,
Jordan, Trvtko,
Daniele, etc), depending on certain scenarios (kernel configs with many
components + interdependencies,
.. OR... a fresh platform-IFWI-update ... OR... a distro that is designed to
boot under 1 sec),
the "2"->"1" can take up to 8-seconds-from-kernel-start. In almost all our
internal CI testing
we are only seeing it take 2-seconds-from-kernel-start.
That said, perhaps we can discuss the MESA behavior on the MESA patch:
do we want to block on init time get-caps (i915_gem_supports_protected_context)
or during
runtime context-creation (if the user explicitly requests it).. or never block
from MESA
and report if the PXP context failed because it wasnt ready (so user knows it
could retry).
<-- this last one was what Jordan wanted and what i posted here on MESA patch:
https://gitlab.freedesktop.org/alan_previn_intel/mesa-alan-previn-features/-/commit/8728ab5a40c1a83f65afe0072f45a906ff26f706
However, as it stands today, this UAPI kernel patch has incorporated all
the requests from prior review comments and provides as much information as
required.
Do you see other shortcoming this kernel side UAPI behavior?
if not, an ack would be greatly appreciated :) since earlier ack from Lionel
was on the prior behavior before Jordan's request for this more
comprehensive response-set (-ENODEV vs '1' vs '2').
Re: [Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
On Mon, 2023-05-08 at 17:49 +, Teres Alexis, Alan Previn wrote:
> On Fri, 2023-05-05 at 00:39 -0700, Justen, Jordan L wrote:
> > On 2023-05-04 22:30:07, Teres Alexis, Alan Previn wrote:
> > > On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, Alan Previn wrote:
> > > > Because of the additional firmware, component-driver and
> > > > initialization depedencies required on MTL platform before a
> > > > PXP context can be created, UMD calling for PXP creation as a
> > > > way to get-caps can take a long time. An actual real world
> > > > customer stack has seen this happen in the 4-to-8 second range
> > > > after the kernel starts (which sees MESA's init appear in the
> > > > middle of this range as the compositor comes up). To avoid
> > > > unncessary delays experienced by the UMD for get-caps purposes,
> > > > add a GET_PARAM for I915_PARAM_PXP_SUPPORT.
> > > >
> > > alan:snip.
> > > Progress update on the UMD side - I'm working on patch for PR here:
> > > https://gitlab.freedesktop.org/alan_previn_intel/mesa-alan-previn-features/-/commit/fb9d4fbfbef7dfd3f41df335cd31549fd39ddb57
> > > but taking time to verify certain code paths
> >
> > Just to confirm, if I915_PARAM_PXP_STATUS returns 2 ("will be ready
> > soon"), then it is basically certain that in a production environment,
> > then it will eventually return 1 meaning it's ready, right?
> alan: yes - but not 100%. non-platform-state-machine could still
> cause unexpected failures for example, [1] if hw was fused in a way
> that doesnt permit PXP or [2] enabling certain BIOS debug knobs
> doesnt allow PXP. However at the moment, there is no way for us
> to know for sure without actually creating a protected context.
> Of course having hw-fusing + bios-config that supports PXP have
> always 100% succeeded for me.
In my opinion it is problematic mark that we support protected context but then
it fails to create protected context.
It should check the I915_PARAM_PXP_STATUS in
i915_gem_supports_protected_context() return earlier if know that protected
context is not supported.
Then create a protected context so we know that all other calls will succeed.
>
> >
> > If this is correct, then I think that the change in
> > i915_gem_supports_protected_context() is good, and probably we can
> > skip the change in iris_create_hw_context().
> >
> > Basically, we're timing out for multiple seconds either way. And, I'm
> > hoping that the kernel will eventually get the PXP init done and
> > create the context.
> >
> > I think there's 2 cases of interest here.
> >
> > First, and most likely, the application running doesn't care about
> > protected content. In this case we can quickly advertise the support,
> > but there will be no consequence because the application won't use the
> > feature.
> alan: yes - that was one of the goals of this UAPI.
> >
> > Second, the application does care about protected content. In this
> > case we can quickly advertise the support, but if the feature is used
> > too quickly, then the context create might take a long time.
> alan: no, that isnt the case now, we started at 8-secs, then 2-secs,
> and finally settled on the same timeout as ADL since this new UAPI
> will be something that can be polled on to be sure we have readiness
> to make the create-context-call. That's why i wanted to add the
> polling wait in the actual create call - but not the get caps call
> which can be quick (as you said above).
>
> >
> > If I915_PARAM_PXP_STATUS returning 2 has a reasonable chance in a
> > production environment of eventually finding out that pxp can't work,
> > then perhaps more disussion is needed. I guess the worst case scenario
> > is no worse than today though. (Except it is still somewhat better,
> > because the common case would not involve protected content being
> > used by the application.)
> alan: hmmm... i guess it depends on the meaning of resonable: if 50%
> of the CI platforms being run have incorrect bios config / hw fusing
> does it mean this UAPI is only 50% useful? My opinion is the alternative:
> in the case of platform that has correctly configured BIOS + fusing,
> is the chance of 2 eventually leading to a failure high? The answer is no.
> Hypothetically i have actually never seen this happen (note: this UAPI
> is new but i know from past debug of customer issues). There are some very
> corner-cases but those get into the weeds of pxp runtime state machine..
> I am sure we don't wanna discuss that rabbit hole right now.
> >
> > Another option besides from the timeout loop in
> > iris_create_hw_context() might be to check I915_PARAM_PXP_STATUS after
> > the context create fails to tweak the debug message.
> alan: Yeah, that is an option - I'm thinking we can add a DBG that reads
> either"PXP context failure expected due not ready" vs
> "Unexpected PXP context failure"
>
> >
> > -Jordan
>
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pxp: Add MTL PXP Support (rev11)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev11) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pxp: Add MTL PXP Support (rev11)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev11) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim checkpatch failed b96ff8f3b576 drm/i915/pxp: Add GSC-CS back-end resource init and cleanup Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:99: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #99: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 173 lines checked 997b8ed14d28 drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:109: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #109: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 153 lines checked d261f1ae7782 drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC 73c94ae011c9 drm/i915/pxp: Add GSC-CS backend to send GSC fw messages -:109: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #109: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c:43: + GEM_BUG_ON(exec_res->pkt_vma->size < (2 * PXP43_MAX_HECI_INOUT_SIZE)); total: 0 errors, 1 warnings, 0 checks, 326 lines checked c90f5b0aa492 drm/i915/pxp: Add ARB session creation and cleanup fa2c398aa4e2 drm/i915/uapi/pxp: Add a GET_PARAM for PXP -:24: WARNING:TYPO_SPELLING: 'similiar' may be misspelled - perhaps 'similar'? #24: similiar checks. total: 0 errors, 1 warnings, 0 checks, 96 lines checked f6ad47c4e352 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component 52fb85b4e4a9 drm/i915/pxp: Enable PXP with MTL-GSC-CS
Re: [Intel-gfx] [RFC PATCH 0/4] Add support for DRM cgroup memory accounting.
Hello, On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote: > The misc controller is not granular enough. A single computer may have any > number of > graphics cards, some of them with multiple regions of vram inside a single > card. Extending the misc controller to support dynamic keys shouldn't be that difficult. ... > In the next version, I will move all the code for handling the resource limit > to > TTM's eviction layer, because otherwise it cannot handle the resource limit > correctly. > > The effect of moving the code to TTM, is that it will make the code even more > generic > for drivers that have vram and use TTM. When using TTM, you only have to > describe your > VRAM, update some fields in the TTM manager and (un)register your device with > the > cgroup handler on (un)load. It's quite trivial to add vram accounting to > amdgpu and > nouveau. [2] > > If you want to add a knob for scheduling weight for a process, it makes sense > to > also add resource usage as a knob, otherwise the effect of that knob is very > limited. So even for Tvrtko's original proposed usecase, it would make sense. It does make sense but unlike Tvrtko's scheduling weights what's being proposed doesn't seem to encapsulate GPU memory resource in a generic enough manner at least to my untrained eyes. ie. w/ drm.weight, I don't need any specific knoweldge of how a specific GPU operates to say "this guy should get 2x processing power over that guy". This more or less holds for other major resources including CPU, memory and IO. What you're proposing seems a lot more tied to hardware details and users would have to know a lot more about how memory is configured on that particular GPU. Now, if this is inherent to how all, or at least most, GPUs operate, sure, but otherwise let's start small in terms of interface and not take up space which should be for something universal. If this turns out to be the way, expanding to take up the generic interface space isn't difficult. I don't know GPU space so please educate me where I'm wrong. Thanks. -- tejun
[Intel-gfx] [PATCH] drm/i915/hwmon: Silence UBSAN uninitialized bool variable warning
Loading i915 on UBSAN enabled kernels (CONFIG_UBSAN/CONFIG_UBSAN_BOOL)
causes the following warning:
UBSAN: invalid-load in drivers/gpu/drm/i915/gt/uc/intel_uc.c:558:2
load of value 255 is not a valid value for type '_Bool'
Call Trace:
dump_stack_lvl+0x57/0x7d
ubsan_epilogue+0x5/0x40
__ubsan_handle_load_invalid_value.cold+0x43/0x48
__uc_init_hw+0x76a/0x903 [i915]
...
i915_driver_probe+0xfb1/0x1eb0 [i915]
i915_pci_probe+0xbe/0x2d0 [i915]
The warning happens because during probe i915_hwmon is still not available
which results in the output boolean variable *old remaining
uninitialized. Silence the warning by initializing the variable to an
arbitrary value.
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_hwmon.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index a3bdd9f68a458..685663861bc0b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -502,8 +502,11 @@ void i915_hwmon_power_max_disable(struct drm_i915_private
*i915, bool *old)
struct i915_hwmon *hwmon = i915->hwmon;
u32 r;
- if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
+ if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit)) {
+ /* Fix uninitialized bool variable warning */
+ *old = false;
return;
+ }
mutex_lock(&hwmon->hwmon_lock);
--
2.38.0
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pxp: Add MTL PXP Support (rev10)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev10) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pxp: Add MTL PXP Support (rev10)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev10) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim checkpatch failed 91f20ccd4603 drm/i915/pxp: Add GSC-CS back-end resource init and cleanup Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:99: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #99: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 173 lines checked 987d18796a95 drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:109: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #109: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 153 lines checked 6ac0639807cf drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC d687c9b5e77c drm/i915/pxp: Add GSC-CS backend to send GSC fw messages -:109: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #109: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c:43: + GEM_BUG_ON(exec_res->pkt_vma->size < (2 * PXP43_MAX_HECI_INOUT_SIZE)); total: 0 errors, 1 warnings, 0 checks, 326 lines checked d932e92ce6c6 drm/i915/pxp: Add ARB session creation and cleanup 744f1d53a88e drm/i915/uapi/pxp: Add a GET_PARAM for PXP -:24: WARNING:TYPO_SPELLING: 'similiar' may be misspelled - perhaps 'similar'? #24: similiar checks. total: 0 errors, 1 warnings, 0 checks, 96 lines checked 33f203b82ae5 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component 583d018a131a drm/i915/pxp: Enable PXP with MTL-GSC-CS
[Intel-gfx] [PATCH v10 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
3- PXP: This series.
NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.
NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
common helpers come in:
- On MTL, when an i915 subsystem needs to send a command request
to the security firmware, it will send that via the GSC-
engine-command-streamer.
- However those commands, (lets call them "gsc_specific_fw_api"
calls), are not understood by the GSC command streamer hw.
- The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and
passes it along to the GSC firmware.
- The GSC FW on the other hand needs additional metadata to know
which usage service is being called (PXP, HDCP, proxy, etc) along
with session specific info. Thus an extra header called GSC-CS
HECI Memory Header, (C) in below diagram is prepended before
the FW specific API, (D).
- Thus, the structural layout of the request submitted would
need to look like the diagram below (for non-priv PXP).
- In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
will populate blob (C) while additional helpers, different for
PPGGTT (this patch) vs GGTT (HDCP series) will populate
blobs (A) and (B) below.
___
(A) | MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
| | |
|_| |
| (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,| |
|| pkt-addr-out, pkt-size-out) |
|| MI_BATCH_BUFFER_END| | |
||| | |
| | |
|_| |
|
-
|
\|/
__V___
| _|
|(C)| ||
| | struct intel_gsc_mtl_header { ||
| | validity marker ||
| | heci_clent_id ||
| | ... ||
| | }||
| |___||
|(D)| ||
| | struct gsc_fw_specific_api_foobar { ||
| | ... ||
| | For an example, see ||
| | 'struct pxp43_create_arb_in' at ||
| | intel_pxp_cmd_interface_43.h ||
| | ||
| | } ||
| | Struture depends on command type ||
| | struct gsc_fw_specific_api_foobar { ||
| |___||
||
That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle (D) and everything
else such as input/output size verification or handling the
responses from security firmware (for example, requiring a retry).
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 102 ++
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 23 ++
[Intel-gfx] [PATCH v10 8/8] drm/i915/pxp: Enable PXP with MTL-GSC-CS
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the debugfs teardown timeouts to align with
new GSC-CS + firmware specs.
Now that we have 3 places that are selecting pxp timeouts
based on tee vs gsccs back-end, let's add a helper.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 18 ++
drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 6 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 +-
5 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index c509ea4aa70f..116b5b5bdb91 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1152,6 +1152,7 @@ static const struct intel_device_info mtl_info = {
.has_llc = 0,
.has_mslice_steering = 0,
.has_snoop = 1,
+ .has_pxp = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
.require_force_probe = 1,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f143eadbc253..bb2e15329f34 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -289,6 +289,14 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
return bound;
}
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp)
+{
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ return GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+ else
+ return 250;
+}
+
static int __pxp_global_teardown_final(struct intel_pxp *pxp)
{
int timeout;
@@ -302,10 +310,7 @@ static int __pxp_global_teardown_final(struct intel_pxp
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
- if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
- timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
- else
- timeout = 250;
+ timeout = intel_pxp_get_backend_timeout_ms(pxp);
if (!wait_for_completion_timeout(&pxp->termination,
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
@@ -325,10 +330,7 @@ static int __pxp_global_teardown_restart(struct intel_pxp
*pxp)
*/
pxp_queue_termination(pxp);
- if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
- timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
- else
- timeout = 250;
+ timeout = intel_pxp_get_backend_timeout_ms(pxp);
if (!wait_for_completion_timeout(&pxp->termination,
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 17e6dbc86b38..17254c3f1267 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -27,6 +27,7 @@ void intel_pxp_mark_termination_in_progress(struct intel_pxp
*pxp);
void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
arb_session_id);
int intel_pxp_get_readiness_status(struct intel_pxp *pxp);
+int intel_pxp_get_backend_timeout_ms(struct intel_pxp *pxp);
int intel_pxp_start(struct intel_pxp *pxp);
void intel_pxp_end(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..e07c5b380789 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -14,6 +14,7 @@
#include "intel_pxp.h"
#include "intel_pxp_debugfs.h"
+#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
#include "intel_pxp_types.h"
@@ -45,6 +46,7 @@ static int pxp_terminate_set(void *data, u64 val)
{
struct intel_pxp *pxp = data;
struct intel_gt *gt = pxp->ctrl_gt;
+ int timeout_ms;
if (!intel_pxp_is_active(pxp))
return -ENODEV;
@@ -54,8 +56,10 @@ static int pxp_terminate_set(void *data, u64 val)
intel_pxp_irq_handler(pxp,
GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
spin_unlock_irq(gt->irq_lock);
+ timeout_ms = intel_pxp_get_backend_timeout_ms(pxp);
+
if (!wait_for_completion_timeout(&pxp->termination,
-msecs_to_jiffies(100)))
+msecs_to_jiffies(timeout_ms)))
return -ETIMEDOUT;
return 0;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index e4d8242302c5..0a3e66b0265e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -44,7 +44,7 @@ static int pxp_wait_for_session_state(struct intel_pxp *pxp,
u32 id, bool in_pla
KCR_SIP(pxp->kcr_base),
[Intel-gfx] [PATCH v10 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP
Because of the additional firmware, component-driver and
initialization depedencies required on MTL platform before a
PXP context can be created, UMD calling for PXP creation as a
way to get-caps can take a long time. An actual real world
customer stack has seen this happen in the 4-to-8 second range
after the kernel starts (which sees MESA's init appear in the
middle of this range as the compositor comes up). To avoid
unncessary delays experienced by the UMD for get-caps purposes,
add a GET_PARAM for I915_PARAM_PXP_SUPPORT.
However, some failures can still occur after all the depedencies
are met (such as firmware init flow failure, bios configurations
or SOC fusing not allowing PXP enablement). Those scenarios will
only be known to user space when it attempts creating a PXP context
and is documented in the GEM UAPI headers.
While making this change, create a helper that is common to both
GET_PARAM caller and intel_pxp_start since the latter does
similiar checks.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_getparam.c | 7 +++
drivers/gpu/drm/i915/pxp/intel_pxp.c | 29 +---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
include/uapi/drm/i915_drm.h | 19 ++
4 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 2238e096c957..6f11d7eaa91a 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -5,6 +5,8 @@
#include "gem/i915_gem_mman.h"
#include "gt/intel_engine_user.h"
+#include "pxp/intel_pxp.h"
+
#include "i915_cmd_parser.h"
#include "i915_drv.h"
#include "i915_getparam.h"
@@ -102,6 +104,11 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
if (value < 0)
return value;
break;
+ case I915_PARAM_PXP_STATUS:
+ value = intel_pxp_get_readiness_status(i915->pxp);
+ if (value < 0)
+ return value;
+ break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
* earlier versions as 0, in effect their value is undefined as
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index b600d68de2a4..f143eadbc253 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -358,23 +358,38 @@ void intel_pxp_end(struct intel_pxp *pxp)
}
/*
- * the arb session is restarted from the irq work when we receive the
- * termination completion interrupt
+ * this helper is used by both intel_pxp_start and by
+ * the GET_PARAM IOCTL that user space calls. Thus, the
+ * return values here should match the UAPI spec.
*/
-int intel_pxp_start(struct intel_pxp *pxp)
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
{
- int ret = 0;
-
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 250))
- return -ENXIO;
+ return 2;
} else {
if (wait_for(pxp_component_bound(pxp), 250))
- return -ENXIO;
+ return 2;
}
+ return 1;
+}
+
+/*
+ * the arb session is restarted from the irq work when we receive the
+ * termination completion interrupt
+ */
+int intel_pxp_start(struct intel_pxp *pxp)
+{
+ int ret = 0;
+
+ ret = intel_pxp_get_readiness_status(pxp);
+ if (ret < 0)
+ return ret;
+ else if (ret > 1)
+ return -EIO; /* per UAPI spec, user may retry later */
mutex_lock(&pxp->arb_mutex);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 3ded0890cd27..17e6dbc86b38 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -26,6 +26,7 @@ void intel_pxp_fini_hw(struct intel_pxp *pxp);
void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
arb_session_id);
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp);
int intel_pxp_start(struct intel_pxp *pxp);
void intel_pxp_end(struct intel_pxp *pxp);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 0aa3190e7654..ba40855dbc93 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -771,6 +771,25 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_OA_TIMESTAMP_FREQUENCY 57
+/*
+ * Query the status of PXP support in i915.
+ *
+ * The query can fail in the following scenarios with the listed error codes:
+ * -ENODEV = PXP support is not available on the GPU device or in the
+ * kernel due
[Intel-gfx] [PATCH v10 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
3- PXP: This series.
NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.
NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
common helpers come in:
- On MTL, when an i915 subsystem needs to send a command request
to the security firmware, it will send that via the GSC-
engine-command-streamer.
- However those commands, (lets call them "gsc_specific_fw_api"
calls), are not understood by the GSC command streamer hw.
- The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and
passes it along to the GSC firmware.
- The GSC FW on the other hand needs additional metadata to know
which usage service is being called (PXP, HDCP, proxy, etc) along
with session specific info. Thus an extra header called GSC-CS
HECI Memory Header, (C) in below diagram is prepended before
the FW specific API, (D).
- Thus, the structural layout of the request submitted would
need to look like the diagram below (for non-priv PXP).
- In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
will populate blob (C) while additional helpers, different for
PPGGTT (this patch) vs GGTT (HDCP series) will populate
blobs (A) and (B) below.
___
(A) | MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
| | |
|_| |
| (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,| |
|| pkt-addr-out, pkt-size-out) |
|| MI_BATCH_BUFFER_END| | |
||| | |
| | |
|_| |
|
-
|
\|/
__V___
| _|
|(C)| ||
| | struct intel_gsc_mtl_header { ||
| | validity marker ||
| | heci_clent_id ||
| | ... ||
| | }||
| |___||
|(D)| ||
| | struct gsc_fw_specific_api_foobar { ||
| | ... ||
| | For an example, see ||
| | 'struct pxp43_create_arb_in' at ||
| | intel_pxp_cmd_interface_43.h ||
| | ||
| | } ||
| | Struture depends on command type ||
| | struct gsc_fw_specific_api_foobar { ||
| |___||
||
That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle (D) and everything
else such as input/output size verification or handling the
responses from security firmware (for example, requiring a retry).
Signed-off-by: Alan Previn
---
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 102 ++
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 23
2 files changed, 125 insertions(+
[Intel-gfx] [PATCH v10 7/8] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.
Thus, immediately enable (or disable) KCR HW on PXP's init,
fini and resume.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 15 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c| 3 ++-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 4bc276daca16..8dc41de3f6f7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -10,6 +10,7 @@
#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
+#include "intel_pxp.h"
#include "intel_pxp_cmd_interface_42.h"
#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
@@ -422,10 +423,22 @@ gsccs_allocate_execution_resource(struct intel_pxp *pxp)
void intel_pxp_gsccs_fini(struct intel_pxp *pxp)
{
+ intel_wakeref_t wakeref;
+
gsccs_destroy_execution_resource(pxp);
+ with_intel_runtime_pm(&pxp->ctrl_gt->i915->runtime_pm, wakeref)
+ intel_pxp_fini_hw(pxp);
}
int intel_pxp_gsccs_init(struct intel_pxp *pxp)
{
- return gsccs_allocate_execution_resource(pxp);
+ int ret;
+ intel_wakeref_t wakeref;
+
+ ret = gsccs_allocate_execution_resource(pxp);
+ if (!ret) {
+ with_intel_runtime_pm(&pxp->ctrl_gt->i915->runtime_pm, wakeref)
+ intel_pxp_init_hw(pxp);
+ }
+ return ret;
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 4f836b317424..1a04067f61fc 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -43,8 +43,9 @@ void intel_pxp_resume_complete(struct intel_pxp *pxp)
* The PXP component gets automatically unbound when we go into S3 and
* re-bound after we come out, so in that scenario we can defer the
* hw init to the bind call.
+* NOTE: GSC-CS backend doesn't rely on components.
*/
- if (!pxp->pxp_component)
+ if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
return;
intel_pxp_init_hw(pxp);
--
2.39.0
[Intel-gfx] [PATCH v10 5/8] drm/i915/pxp: Add ARB session creation and cleanup
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
While relooking at the ARB session creation flow in intel_pxp_start,
let's address missing UAPI documentation. Without actually changing
backward compatible behavior, update i915's drm-uapi comments
that describe the possible error values when creating a context
with I915_CONTEXT_PARAM_PROTECTED_CONTENT:
Since the first merge of PXP support on ADL, i915 returns -ENXIO
if a dependency such as firmware or component driver was yet to
be loaded or returns -EIO if the creation attempt failed when
requested by the PXP firmware (specific firmware error responses
are reported in dmesg).
Add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.
For both cases, in the back-end gsccs functions for sending messages
to the firmware inspect the GSC-CS-Mem-Header's pending-bit which
means the GSC firmware is busy and we should retry.
Given the last hw requirement, lets also update functions in
front-end layer that wait for session creation or teardown
completion to use new worst case timeout periods.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 27 +++-
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 21 +++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 130 ++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h| 12 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 11 +-
include/uapi/drm/i915_drm.h | 15 ++
6 files changed, 209 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 8949d4be7882..b600d68de2a4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -291,6 +291,8 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
static int __pxp_global_teardown_final(struct intel_pxp *pxp)
{
+ int timeout;
+
if (!pxp->arb_is_valid)
return 0;
/*
@@ -300,7 +302,12 @@ static int __pxp_global_teardown_final(struct intel_pxp
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
- if (!wait_for_completion_timeout(&pxp->termination,
msecs_to_jiffies(250)))
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+ else
+ timeout = 250;
+
+ if (!wait_for_completion_timeout(&pxp->termination,
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
return 0;
@@ -308,6 +315,8 @@ static int __pxp_global_teardown_final(struct intel_pxp
*pxp)
static int __pxp_global_teardown_restart(struct intel_pxp *pxp)
{
+ int timeout;
+
if (pxp->arb_is_valid)
return 0;
/*
@@ -316,7 +325,12 @@ static int __pxp_global_teardown_restart(struct intel_pxp
*pxp)
*/
pxp_queue_termination(pxp);
- if (!wait_for_completion_timeout(&pxp->termination,
msecs_to_jiffies(250)))
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ timeout = GSCFW_MAX_ROUND_TRIP_LATENCY_MS;
+ else
+ timeout = 250;
+
+ if (!wait_for_completion_timeout(&pxp->termination,
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
return 0;
@@ -354,8 +368,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
- if (wait_for(pxp_component_bound(pxp), 250))
- return -ENXIO;
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
+ if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 250))
+ return -ENXIO;
+ } else {
+ if (wait_for(pxp_component_bound(pxp), 250))
+ return -ENXIO;
+ }
mutex_lock(&pxp->arb_mutex);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index c65ada99e54f..0919cd84 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -11,6 +11,7 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+#define PXP43_CMDID_INIT_SESSION 0x0036
/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
#define PXP43_MAX_HECI_INOUT_SIZE (SZ_32K)
@@ -26,4 +27,24 @@ struct pxp43_start_huc_auth_out {
struct pxp_cmd_header header;
} __packed;
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_in {
+ struct pxp_cmd_header header;
+ /* header.stream_id fields for vesion 4.3 of Init PXP session:
*/
+ #define PXP43_INIT_SESSION_VALID BIT(0)
+ #define PXP43_INIT_SESSION_APPTYPE BIT(1)
+ #define PXP43_INIT_SESSION_APPID GENMASK(17, 2)
+ u32 protection_m
[Intel-gfx] [PATCH v10 2/8] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 3 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 32
drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 27 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 12 +++-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6
5 files changed, 58 insertions(+), 22 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 95e59ed6651d..8f888d36f16d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -107,7 +107,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8
class, u8 instance)
case OTHER_CLASS:
if (instance == OTHER_GSC_HECI_2_INSTANCE)
return media_gt;
- if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt,
GSC0))
+ if ((instance == OTHER_GSC_INSTANCE || instance ==
OTHER_KCR_INSTANCE) &&
+ HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index f93aa171aa1e..8949d4be7882 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
#include "intel_pxp.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
#include "intel_pxp_types.h"
@@ -61,21 +62,22 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
}
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
+{
+ u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES)
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+ intel_uncore_write(pxp->ctrl_gt->uncore, KCR_INIT(pxp->kcr_base), val);
+}
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, true);
}
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, false);
}
static int create_vcs_context(struct intel_pxp *pxp)
@@ -127,6 +129,11 @@ static void pxp_init_full(struct intel_pxp *pxp)
init_completion(&pxp->termination);
complete_all(&pxp->termination);
+ if (pxp->ctrl_gt->type == GT_MEDIA)
+ pxp->kcr_base = MTL_KCR_BASE;
+ else
+ pxp->kcr_base = GEN12_KCR_BASE;
+
intel_pxp_session_management_init(pxp);
ret = create_vcs_context(pxp);
@@ -369,14 +376,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
void intel_pxp_init_hw(struct intel_pxp *pxp)
{
- kcr_pxp_enable(pxp->ctrl_gt);
+ kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
}
void intel_pxp_fini_hw(struct intel_pxp *pxp)
{
- kcr_pxp_disable(pxp->ctrl_gt);
-
+ kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..a9e7e6efa4c7
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR subsystem register base address */
+#define GEN12_KCR_BASE 0x32000
+#define MTL_KCR_BASE 0x386000
+
+/* KCR enable/disable control */
+#define KCR_INIT(base) _MMIO((base) + 0xf0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define KCR_SIP(base) _MMIO((base) + 0x260)
+
+/* PXP global terminate register for session termination */
+#de
[Intel-gfx] [PATCH v10 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.
Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.
We use non-priveleged batches for submission to GSC engine
which require two buffers for the request:
- a buffer for the HECI packet that contains PXP FW commands
- a batch-buffer that contains the engine instruction for
sending the HECI packet to the GSC firmware.
Thus, add the allocation and freeing of these buffers in gsccs
init and fini.
The GSC-fw may reply to commands with a SUCCESS but with an
additional pending-bit set in the reply packet. This bit
means the GSC-FW is currently busy and the caller needs to
try again with the gsc_message_handle the fw returned. Thus,
add a wrapper to continuously retry send_message while
replaying the gsc_message_handle. Retries need to follow the
arch-spec count and delay until GSC-FW replies with the real
SUCCESS or timeout after that spec'd delay.
The GSC-fw requires a non-zero host_session_handle provided
by the caller to enable gsc_message_handle tracking. Thus,
allocate the host_session_handle at init and destroy it
at fini (the latter requiring an FYI to the gsc-firmware).
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 3 +-
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 3 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 240 +-
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h| 4 +
drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 6 +
5 files changed, 254 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
index e790608745d4..ef70e304904a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -51,7 +51,8 @@ struct intel_gsc_mtl_header {
* we distinguish the flags using OUTFLAG or INFLAG
*/
u32 flags;
-#define GSC_OUTFLAG_MSG_PENDING1
+#define GSC_OUTFLAG_MSG_PENDINGBIT(0)
+#define GSC_INFLAG_MSG_CLEANUP BIT(1)
u32 status;
} __packed;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index ad67e3f49c20..c65ada99e54f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -12,6 +12,9 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
+#define PXP43_MAX_HECI_INOUT_SIZE (SZ_32K)
+
/* PXP-Input-Packet: HUC-Authentication */
struct pxp43_start_huc_auth_in {
struct pxp_cmd_header header;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index bad55719a7ac..16e3b73d0653 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,23 +6,232 @@
#include "gem/i915_gem_internal.h"
#include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_types.h"
+static int
+gsccs_send_message(struct intel_pxp *pxp,
+ void *msg_in, size_t msg_in_size,
+ void *msg_out, size_t msg_out_size_max,
+ size_t *msg_out_len,
+ u64 *gsc_msg_handle_retry)
+{
+ struct intel_gt *gt = pxp->ctrl_gt;
+ struct drm_i915_private *i915 = gt->i915;
+ struct gsccs_session_resources *exec_res = &pxp->gsccs_res;
+ struct intel_gsc_mtl_header *header = exec_res->pkt_vaddr;
+ struct intel_gsc_heci_non_priv_pkt pkt;
+ size_t max_msg_size;
+ u32 reply_size;
+ int ret;
+
+ if (!exec_res->ce)
+ return -ENODEV;
+
+ max_msg_size = PXP43_MAX_HECI_INOUT_SIZE - sizeof(*header);
+
+ if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+ return -ENOSPC;
+
+ if (!exec_res->pkt_vma || !exec_res->bb_vma)
+ return -ENOENT;
+
+ GEM_BUG_ON(exec_res->pkt_vma->size < (2 * PXP43_MAX_HECI_INOUT_SIZE));
+
+ mutex_lock(&pxp->tee_mutex);
+
+ memset(header, 0, sizeof(*header));
+ intel_gsc_uc_heci_cmd_emit_mtl_header(header, HECI_MEADDRESS_PXP,
+ msg_in_size + sizeof(*header),
+ exec_res->host_session_handle);
+
+ /* check if this is a host-session-handle cleanup call (empty packet) */
+ if (!msg_in && !msg_out)
+ header->flags |= GSC_INFLAG_MSG_CLEANUP;
+
+ /* copy caller provided gsc
[Intel-gfx] [PATCH v10 1/8] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.
Thus for MTL, we need to allocate and free a set of execution
submission resources for the management of the arbitration session.
Lets start with the context creation first since that object and
its usage is very straight-forward. We'll add the buffer allocation
and freeing later when we introduce the gsccs' send-message function.
Do this one time allocation of gsccs specific resources in
a new gsccs source file with intel_pxp_gsccs_init / fini functions
and hook them up from the PXP front-end.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 20 +--
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 63 ++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h | 29 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 2 -
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 8 +++
6 files changed, 117 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d97d45ae1a0d..7587fe856e67 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -343,6 +343,7 @@ i915-y += \
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
+ pxp/intel_pxp_gsccs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 9d4c7724e98e..f93aa171aa1e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -12,6 +12,7 @@
#include "i915_drv.h"
#include "intel_pxp.h"
+#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
@@ -132,7 +133,10 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- ret = intel_pxp_tee_component_init(pxp);
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ ret = intel_pxp_gsccs_init(pxp);
+ else
+ ret = intel_pxp_tee_component_init(pxp);
if (ret)
goto out_context;
@@ -165,9 +169,12 @@ static struct intel_gt
*find_gt_for_required_protected_content(struct drm_i915_p
/*
* For MTL onwards, PXP-controller-GT needs to have a valid GSC engine
* on the media GT. NOTE: if we have a media-tile with a GSC-engine,
-* the VDBOX is already present so skip that check
+* the VDBOX is already present so skip that check. We also have to
+* ensure the GSC and HUC firmware are coming online
*/
- if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0))
+ if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0) &&
+ intel_uc_fw_is_loadable(&i915->media_gt->uc.gsc.fw) &&
+ intel_uc_fw_is_loadable(&i915->media_gt->uc.huc.fw))
return i915->media_gt;
/*
@@ -207,7 +214,9 @@ int intel_pxp_init(struct drm_i915_private *i915)
if (!i915->pxp)
return -ENOMEM;
+ /* init common info used by all feature-mode usages*/
i915->pxp->ctrl_gt = gt;
+ mutex_init(&i915->pxp->tee_mutex);
/*
* If full PXP feature is not available but HuC is loaded by GSC on
pre-MTL
@@ -229,7 +238,10 @@ void intel_pxp_fini(struct drm_i915_private *i915)
i915->pxp->arb_is_valid = false;
- intel_pxp_tee_component_fini(i915->pxp);
+ if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+ intel_pxp_gsccs_fini(i915->pxp);
+ else
+ intel_pxp_tee_component_fini(i915->pxp);
destroy_vcs_context(i915->pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
new file mode 100644
index ..bad55719a7ac
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2023 Intel Corporation.
+ */
+
+#include "gem/i915_gem_internal.h"
+
+#include "gt/intel_context.h"
+
+#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_43.h"
+#include "intel_pxp_gsccs.h"
+#include "intel_pxp_types.h"
+
+static void
+gsccs_destroy_execution_resource(struct intel_pxp *pxp)
+{
+ struct gsccs_session_resources *exec_res = &pxp->gsccs_res;
+
+ if (exec_res->ce)
+ intel_context_put(exec_res->ce);
+
+ memset(exec_res, 0, sizeof(*exec_res));
+}
+
+static int
+gsccs_allocate_execution_resource(struct intel_pxp *pxp)
+{
+ st
[Intel-gfx] [PATCH v10 0/8] drm/i915/pxp: Add MTL PXP Support
This series enables PXP on MTL. On ADL/TGL platforms, we rely on the mei driver via the i915-mei PXP component interface to establish a connection to the security firmware via the HECI device interface. That interface is used to create and teardown the PXP ARB session. PXP ARB session is created when protected contexts are created. In this series, the front end behaviors and interfaces (uapi) remain the same. We add backend support for MTL but with MTL we directly use the GSC-CS engine on the MTL GPU device to send messages to the PXP (a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format of the message is slightly different with a 2-layer packetization that is explained in detail in Patch #3. Also, the second layer which is the actual PXP firmware packet is now rev'd to version 4.3 for MTL that is defined in Patch #5. Take note that Patch #4 adds the buffer allocation and gsccs-send- message without actually being called by the arb-creation code which gets added in Patch #5. Additionally, a seperate series being reviewed is introducing a change for session teardown (in pxp front- end layer that will need backend support by both legacy and gsccs). If we squash all of these together (buffer-alloc, send-message, arb-creation and, in future, session-termination), the single patch will be rather large. That said, we are keeping Patch #4 and #5 separate for now, but at merge time, we can squash them together if maintainer requires it. Changes from prior revs: v1 : - fixed when building with CONFIG_PXP disabled. - more alignment with gsc_mtl_header structure from the HDCP v2 : - (all following changes as per reviews from Daniele) - squashed Patch #1 from v1 into the next one. - replaced unnecessary "uses_gsccs" boolean in the pxp with "HAS_ENGINE(pxp->ctrl_gt, GSC0)". - moved the stashing of gsccs resources from a dynamically allocated opaque handle to an explicit sub-struct in 'struct intel_pxp'. - moved the buffer object allocations from Patch #1 of this series to Patch #5 (but keep the context allocation in Patch #1). - used the kernel default ppgtt for the gsccs context. - optimized the buffer allocation and deallocation code and drop the need to stash the drm_i915_gem_object. - use a macro with the right mmio reg base (depending on root-tile vs media-tile) along with common relative offset to access all KCR registers thus minimizing changes to the KCR register access codes. - fixed bugs in the heci packet request submission code in Patch #3 (of this series) - add comments in the mtl-gsc-heci-header regarding the host-session-handle. - re-use tee-mutex instead of introducing a gsccs specific cmd mutex. - minor cosmetic improvements in Patch #5. - before creating arb session, ensure intel_pxp_start first ensures the GSC FW is up and running. - use 2 second timeout for the pending-bit scenario when sending command to GSC-FW as per specs. - simplify intel_pxp_get_irq_gt with addition comments - redo Patch #7 to minimize the changes without introducing a common abstraction helper for suspend/resume/init/fini codes that have to change the kcr power state. v3 : - rebase onto latest drm-tip with the updated firmware session invalidation flow - on Patch#1: move 'mutex_init(&pxp->tee_mutex)' to a common init place in intel_pxp_init since its needed everywhere (Daniele) - on Patch#1: remove unneccasary "ce->vm = i915_vm_get(vm);" (Daniele) - on Patch#2: move the introduction of host_session_handle to Patch#4 where it starts getting used. - on Patch#4: move host-session-handle initialization to the allocate-resources during gsccs-init (away from Patch#5) and add the required call to PXP-firmware to cleanup the host-session-handle in destroy-resources during gsccs-fini - on Patch#5: add dispatching of arb session termination firmware cmd during session teardown (as per latest upstream flows) v4 : - Added proper initialization and cleanup of host-session-handle that the gsc firmware expects. - Fix the stream-session-key invalidation instruction for MTL. v5 : - In Patch #4, move the tee_mutex locking to after we check for valid vma allocations. - In Patch #5, wait for intel_huc_is_authenticated instead of intel_uc_fw_is_running(gsc-fw) before starting ARB session. - In Patch #5, increase the necessary timeouts at the top-level (PXP arb session creation / termination) to accomodate SLA of GSC firmware when busy with pending-bit responses. - In Patch #5, remove redundant host_session_handle i
[Intel-gfx] [linux-next:master] BUILD SUCCESS WITH WARNING 578215f3e21c472c08d70b8796edf1ac58f88578
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 578215f3e21c472c08d70b8796edf1ac58f88578 Add linux-next specific files for 20230510 Warning reports: https://lore.kernel.org/oe-kbuild-all/202304140707.coh337ux-...@intel.com Warning: (recently discovered and may have been fixed) drivers/base/regmap/regcache-maple.c:113:23: warning: 'lower_index' is used uninitialized [-Wuninitialized] drivers/base/regmap/regcache-maple.c:113:36: warning: 'lower_last' is used uninitialized [-Wuninitialized] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6395:21: warning: variable 'count' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:499:13: warning: variable 'j' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:48:38: warning: unused variable 'golden_settings_gc_9_4_3' [-Wunused-const-variable] Unverified Warning (likely false positive, please contact us if interested): drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:648:3-9: preceding lock on line 640 drivers/gpu/drm/i915/display/intel_psr.c:2999:0-23: WARNING: i915_edp_psr_debug_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE fs/ext4/super.c:4724 ext4_check_feature_compatibility() warn: bitwise AND condition is false here fs/ext4/verity.c:316 ext4_get_verity_descriptor_location() error: uninitialized symbol 'desc_size_disk'. fs/xfs/scrub/fscounters.c:459 xchk_fscounters() warn: ignoring unreachable code. Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arc-allyesconfig | |-- drivers-base-regmap-regcache-maple.c:warning:lower_index-is-used-uninitialized | |-- drivers-base-regmap-regcache-maple.c:warning:lower_last-is-used-uninitialized | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arc-randconfig-r025-20230509 | |-- drivers-base-regmap-regcache-maple.c:warning:lower_index-is-used-uninitialized | `-- drivers-base-regmap-regcache-maple.c:warning:lower_last-is-used-uninitialized |-- arm-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arm-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arm64-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- csky-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- i386-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- ia64-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- ia64-randconfig-s052-20230509 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- loongarch-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- loongarch-defconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- loongarch-randconfig-c023-20230509 | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- loongarch-randconfig-s051-20230509 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- microblaze-randconfig-m031-20230509 | `-- fs-ext4-super.c-ext4_check_feature_compatibility()-warn:bitwise-AND-condition-is-false-here |-- microblaze-randconfig-r035-20230509 | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warnin
Re: [Intel-gfx] [PATCH] drm/i915: WARN if not all pipes are in bigjoiner mask, when copying plane state
On Wed, May 10, 2023 at 04:47:57PM +0300, Ville Syrjälä wrote:
> On Tue, May 09, 2023 at 02:14:41PM +0300, Stanislav Lisovskiy wrote:
> > There is a suspicion that we might not have all bigjoiner pipes
> > set in correspodent mask, which leads to that not all crtc are added to the
> > state,
> > however because we are copying for instance crtc reference from master crtc
> > to slave crtc, we might be trying to get it via
> > intel_atomic_get_new_crtc_state,
> > which might the return NULL.
> > This is surely not a fix, but at least the WARN should give us some clue and
> > "red light" when this happens.
> > In future we might need to evaluate the logic of adding crtc to the state,
> > to make sure that we always have all affected crtcs in the state,
> > even though such functions already exist, there seem to be still some
> > glitches in this logic.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/intel_atomic_plane.c | 13 +
> > drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_display.h | 1 +
> > 3 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index 4125ee07a271..03cbd755261b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -695,6 +695,19 @@ int intel_plane_atomic_check(struct intel_atomic_state
> > *state,
> >
> > new_master_plane_state =
> > intel_atomic_get_new_plane_state(state, master_plane);
> > +
> > + /*
> > +* We would be copying plane state from master crtc
> > +* however if crtc_state->bigjoiner_pipes doesn't contain both
> > +* master and slave, that means that quite likely we didn't call
> > +* intel_atomic_get_crtc_state for both, which can cause issues,
> > +* like intel_atomic_get_new_crtc_state returning NULL
> > suddently,
> > +* when we for example try to use hw.crtc from that plane state.
> > +* This WARN might sched some light on out existing issues, also
> > +* prevent others from happening in future.
> > +*/
> > + drm_WARN_ON(state->base.dev,
> > intel_bigjoiner_num_pipes(new_crtc_state) < 2);
>
> What you are doing here is basically just
> if (bigjoiner_pipes)
> assert(bigjoiner_pipes != 1);
> which is not going to catch anything.
>
> We can trivially see that it will never happen given
> how bigjoiner_pipes is initialized.
intel_bigjoiner_num_pipes counts how many pipe are used,
as I understand in case of bigjoiner we should always have it
returning 2, right?
For example intel_bigjoiner_adjust_timings uses it currently
same way in our code, also I think there other places:
static void intel_bigjoiner_adjust_timings(const struct intel_crtc_state
*crtc_state,
struct drm_display_mode *mode)
{
int num_pipes = intel_bigjoiner_num_pipes(crtc_state);
if (num_pipes < 2)
return;
...
I was just willing to check if, we might have this mask
messed up somehow, because we add crtcs to the state based
on this mask.
However I already checked, problem seems to be
somewhere else.
Stan
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [RFC PATCH 0/4] Add support for DRM cgroup memory accounting.
Hey, On 2023-05-05 21:50, Tejun Heo wrote: Hello, On Wed, May 03, 2023 at 10:34:56AM +0200, Maarten Lankhorst wrote: RFC as I'm looking for comments. For long running compute, it can be beneficial to partition the GPU memory between cgroups, so each cgroup can use its maximum amount of memory without interfering with other scheduled jobs. Done properly, this can alleviate the need for eviction, which might result in a job being terminated if the GPU doesn't support mid-thread preemption or recoverable page faults. This is done by adding a bunch of knobs to cgroup: drm.capacity: Shows maximum capacity of each resource region. drm.max: Display or limit max amount of memory. drm.current: Current amount of memory in use. TTM has not been made cgroup aware yet, so instead of evicting from the current cgroup to stay within the cgroup limits, it simply returns the error -ENOSPC to userspace. I've used Tvrtko's cgroup controller series as a base, but it implemented scheduling weight, not memory accounting, so I only ended up keeping the base patch. Xe is not upstream yet, so the driver specific patch will only apply on https://gitlab.freedesktop.org/drm/xe/kernel Some high-level feedbacks. * There have been multiple attempts at this but the track record is kinda poor. People don't seem to agree what should constitute DRM memory and how they should be accounted / controlled. Thanks for the feedback. I think for a lot of drivers, what is VRAM might have different meaning, but the intention is it being accounted in the same way. Most drivers use TTM, which has a standard way of allocating memory, and a standard way of evicting VRAM. This makes it very useful for the usecase which I'm looking at, long running compute. When you have long running jobs, you don't want them to be interrupted because a completely unrelated process needs some VRAM, and one of the compute jobs buffers are being evicted. Some hardware does not support mid-thread preemption or page fault recovery, this means that when memory is evicted, the compute job is terminated. The full problem statement is in drm-compute.rst in the memory accounting patch. * I like Tvrtko's scheduling patchset because it exposes a generic interface which makes sense regardless of hardware details and then each driver can implement the configured control in whatever way they can. However, even for that, there doesn't seem much buy-in from other drivers. Yeah, that is correct. But it tries to solve a different part of the problem. * This proposal seems narrowly scoped trying to solve a specific problem which may not translate to different hardware configurations. Please let me know if I got that wrong, but if that's the case, I think a better and easier approach might be just being a part of the misc controller. That doesn't require much extra code and should be able to provide everything necessary for statically limiting specific resources. The misc controller is not granular enough. A single computer may have any number of graphics cards, some of them with multiple regions of vram inside a single card. For compute and shared hosting you might want to limit the usage of a single memory region on a single card, and then limit the same limits for the rest too, to prevent triggering eviction. The current version doesn't handle eviction correctly, because I was still working on it and I wanted to post a RFC. As a result, the case where resource limit is hit will evict the device's entire memory or get stuck in a loop. With some changes, the next version will not have this bug. This results in a few changes to the core code. [1] In the next version, I will move all the code for handling the resource limit to TTM's eviction layer, because otherwise it cannot handle the resource limit correctly. The effect of moving the code to TTM, is that it will make the code even more generic for drivers that have vram and use TTM. When using TTM, you only have to describe your VRAM, update some fields in the TTM manager and (un)register your device with the cgroup handler on (un)load. It's quite trivial to add vram accounting to amdgpu and nouveau. [2] If you want to add a knob for scheduling weight for a process, it makes sense to also add resource usage as a knob, otherwise the effect of that knob is very limited. So even for Tvrtko's original proposed usecase, it would make sense. Cheers, ~Maarten [1] Compared to this version: static inline int drmcg_try_charge(struct drmcgroup_state **drmcs, + struct drmcgroup_state **limitcs, struct drmcgroup_device *cgdev, u32 index, u64 size) This now returns which cgroup's limit is hit on -EAGAIN. +bool drmcs_grouped(struct drmcgroup_state *limitcs, + struct drmcgroup_state *testcs); Tells if testcs is the same as limitcs, or a subgroup of
Re: [Intel-gfx] [PATCH] drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function
On Thu, 04 May 2023, Suraj Kandpal wrote:
> Since topology state is being added to drm_atomic_state now all
> drm_modeset_lock required are being taken from core this raises
> an issue when we try to loop over connector and assign vcpi id to
> our streams as we did not have atomic state to derive acquire_ctx
> from hence we fill in stream info if dpmst encoder is found before
> enabling hdcp.
>
> Cc: Ankit Nautiyal
> Signed-off-by: Suraj Kandpal
The subject implies you're just passing an extra parameter, but that's
really not the case. You're doing something else, and to achieve that,
you also pass an extra parameter.
One approach might be to have a separate patch to change the parameters
only, and it might be sensible to actually pass all the
intel_encoder->enable() parameters i.e.
(struct intel_atomic_state *state,
struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config,
const struct drm_connector_state *conn_state)
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c| 3 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 50 ++---
> drivers/gpu/drm/i915/display/intel_hdcp.h | 3 +-
> 4 files changed, 49 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 29e4bfab4635..182b8815b20d 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3264,9 +3264,10 @@ static void intel_enable_ddi(struct intel_atomic_state
> *state,
> /* Enable hdcp if it's desired */
> if (conn_state->content_protection ==
> DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(to_intel_connector(conn_state->connector),
> + intel_hdcp_enable(state,
> to_intel_connector(conn_state->connector),
> crtc_state,
> (u8)conn_state->hdcp_content_type);
> +
> }
>
> static void intel_disable_ddi_dp(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 2c49d9ab86a2..c92b00ceaae0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -800,7 +800,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state
> *state,
> /* Enable hdcp if it's desired */
> if (conn_state->content_protection ==
> DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(to_intel_connector(conn_state->connector),
> + intel_hdcp_enable(state,
> to_intel_connector(conn_state->connector),
> pipe_config,
> (u8)conn_state->hdcp_content_type);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index e1dc3d96e708..c8cdf25914f7 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -30,7 +30,8 @@
> #define KEY_LOAD_TRIES 5
> #define HDCP2_LC_RETRY_CNT 3
>
> -static int intel_conn_to_vcpi(struct intel_connector *connector)
> +static int intel_conn_to_vcpi(struct intel_connector *connector,
> + struct drm_atomic_state *state)
> {
> struct drm_dp_mst_topology_mgr *mgr;
> struct drm_dp_mst_atomic_payload *payload;
> @@ -42,7 +43,7 @@ static int intel_conn_to_vcpi(struct intel_connector
> *connector)
> return 0;
> mgr = connector->port->mgr;
>
> - drm_modeset_lock(&mgr->base.lock, NULL);
> + drm_modeset_lock(&mgr->base.lock, state->acquire_ctx);
The return value must be checked and handled for ctx != NULL. Please git
grep for examples.
> mst_state = to_drm_dp_mst_topology_state(mgr->base.state);
> payload = drm_atomic_get_mst_payload_state(mst_state, connector->port);
> if (drm_WARN_ON(mgr->dev, !payload))
> @@ -54,7 +55,6 @@ static int intel_conn_to_vcpi(struct intel_connector
> *connector)
> goto out;
> }
> out:
> - drm_modeset_unlock(&mgr->base.lock);
> return vcpi;
> }
>
> @@ -99,7 +99,6 @@ intel_hdcp_required_content_stream(struct
> intel_digital_port *dig_port)
> if (!enforce_type0 && !dig_port->hdcp_mst_type1_capable)
> enforce_type0 = true;
>
> - data->streams[data->k].stream_id =
> intel_conn_to_vcpi(connector);
> data->k++;
>
> /* if there is only one active stream */
> @@ -122,6 +121,41 @@ intel_hdcp_required_content_stream(struct
> intel_digital_port *dig_port)
> return 0;
> }
>
> +static int
> +intel_hdcp_get_content_stream_id(struct intel_digital_port *dig_port,
> + struct intel_atomic_state *state)
To me it seems like this *sets* the stream id, not get.
Re: [Intel-gfx] [PATCH v4 13/14] drm/i915/tc: Call TypeC port flush_work/cleanup without modeset locks held
On Wed, May 10, 2023 at 05:03:17PM +0300, Ville Syrjälä wrote:
> On Wed, May 10, 2023 at 01:31:30PM +0300, Imre Deak wrote:
> > Call the TypeC port flush_work and cleanup handlers without the modeset
> > locks held. These don't require the locks, as the work takes - as it
> > should be able to at any point in time - any locks it needs and by the
> > time cleanup is called and after cleanup returns the encoder is not in
> > use.
> >
> > This is required by the next patch canceling a TypeC port work
> > synchronously during encoder suspend and shutdown, where the work can
> > take modeset locks as well, hence the canceling must be done without
> > holding the locks.
> >
> > I also considered moving the modeset locking down to each encoder
> > suspend()/shutdown() hook instead, however locking the full modeset
> > state for each encoder separately would be odd, and the bigger change -
> > affecting all encoders - is beyond the scope of this patchset.
>
> Hmm. What is it in the encoder shutdown/suspend hooks that
> actually needs the modeset locks?
In the case of intel_dp_encoder_suspend() for instance, I assume
nothing, since the VDD work and intel_pps_vdd_off_sync() should take
whatever locks they require.
So presumably most (all) of those could be made lockless. However, I
would like to leave that kind of change for a follow-up if possible, not
to affect in this patchset any other encoder types (again because of
possible need for CC stable).
>
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 27 +--
> > .../drm/i915/display/intel_display_types.h| 12 +
> > drivers/gpu/drm/i915/i915_driver.c| 8 ++
> > 3 files changed, 33 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 813be957ed11b..7d09bd2412352 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -4617,31 +4617,27 @@ static bool intel_ddi_is_tc(struct drm_i915_private
> > *i915, enum port port)
> >
> > static void intel_ddi_encoder_suspend(struct intel_encoder *encoder)
> > {
> > - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > - enum phy phy = intel_port_to_phy(i915, encoder->port);
> > -
> > intel_dp_encoder_suspend(encoder);
> > +}
> >
> > - if (!intel_phy_is_tc(i915, phy))
> > - return;
> > +static void intel_ddi_tc_encoder_suspend_complete(struct intel_encoder
> > *encoder)
> > +{
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> >
> > intel_tc_port_flush_work(dig_port);
> > }
> >
> > static void intel_ddi_encoder_shutdown(struct intel_encoder *encoder)
> > {
> > - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > - enum phy phy = intel_port_to_phy(i915, encoder->port);
> > -
> > intel_dp_encoder_shutdown(encoder);
> > intel_hdmi_encoder_shutdown(encoder);
> > +}
> >
> > - if (!intel_phy_is_tc(i915, phy))
> > - return;
> > +static void intel_ddi_tc_encoder_shutdown_complete(struct intel_encoder
> > *encoder)
> > +{
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> >
> > intel_tc_port_cleanup(dig_port);
> > }
> > @@ -4908,6 +4904,9 @@ void intel_ddi_init(struct drm_i915_private
> > *dev_priv, enum port port)
> > is_legacy ? "legacy" : "non-legacy");
> > }
> >
> > + encoder->suspend_complete =
> > intel_ddi_tc_encoder_suspend_complete;
> > + encoder->shutdown_complete =
> > intel_ddi_tc_encoder_shutdown_complete;
> > +
> > if (intel_tc_port_init(dig_port, is_legacy) < 0)
> > goto err;
> > }
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 270c4c84a2920..88b2a55d19f21 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -233,13 +233,25 @@ struct intel_encoder {
> > * Called during system suspend after all pending requests for the
> > * encoder are flushed (for example for DP AUX transactions) and
> > * device interrupts are disabled.
> > +* All modeset locks are held while the hook is called.
> > */
> > void (*suspend)(struct intel_encoder *);
> > + /*
> > +* Called without the modeset locks held after the suspend() hook for
> > +* all encod
Re: [Intel-gfx] [PATCH v4 13/14] drm/i915/tc: Call TypeC port flush_work/cleanup without modeset locks held
On Wed, May 10, 2023 at 01:31:30PM +0300, Imre Deak wrote:
> Call the TypeC port flush_work and cleanup handlers without the modeset
> locks held. These don't require the locks, as the work takes - as it
> should be able to at any point in time - any locks it needs and by the
> time cleanup is called and after cleanup returns the encoder is not in
> use.
>
> This is required by the next patch canceling a TypeC port work
> synchronously during encoder suspend and shutdown, where the work can
> take modeset locks as well, hence the canceling must be done without
> holding the locks.
>
> I also considered moving the modeset locking down to each encoder
> suspend()/shutdown() hook instead, however locking the full modeset
> state for each encoder separately would be odd, and the bigger change -
> affecting all encoders - is beyond the scope of this patchset.
Hmm. What is it in the encoder shutdown/suspend hooks that
actually needs the modeset locks?
>
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 27 +--
> .../drm/i915/display/intel_display_types.h| 12 +
> drivers/gpu/drm/i915/i915_driver.c| 8 ++
> 3 files changed, 33 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 813be957ed11b..7d09bd2412352 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4617,31 +4617,27 @@ static bool intel_ddi_is_tc(struct drm_i915_private
> *i915, enum port port)
>
> static void intel_ddi_encoder_suspend(struct intel_encoder *encoder)
> {
> - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> - enum phy phy = intel_port_to_phy(i915, encoder->port);
> -
> intel_dp_encoder_suspend(encoder);
> +}
>
> - if (!intel_phy_is_tc(i915, phy))
> - return;
> +static void intel_ddi_tc_encoder_suspend_complete(struct intel_encoder
> *encoder)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>
> intel_tc_port_flush_work(dig_port);
> }
>
> static void intel_ddi_encoder_shutdown(struct intel_encoder *encoder)
> {
> - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> - enum phy phy = intel_port_to_phy(i915, encoder->port);
> -
> intel_dp_encoder_shutdown(encoder);
> intel_hdmi_encoder_shutdown(encoder);
> +}
>
> - if (!intel_phy_is_tc(i915, phy))
> - return;
> +static void intel_ddi_tc_encoder_shutdown_complete(struct intel_encoder
> *encoder)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>
> intel_tc_port_cleanup(dig_port);
> }
> @@ -4908,6 +4904,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> is_legacy ? "legacy" : "non-legacy");
> }
>
> + encoder->suspend_complete =
> intel_ddi_tc_encoder_suspend_complete;
> + encoder->shutdown_complete =
> intel_ddi_tc_encoder_shutdown_complete;
> +
> if (intel_tc_port_init(dig_port, is_legacy) < 0)
> goto err;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 270c4c84a2920..88b2a55d19f21 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -233,13 +233,25 @@ struct intel_encoder {
>* Called during system suspend after all pending requests for the
>* encoder are flushed (for example for DP AUX transactions) and
>* device interrupts are disabled.
> + * All modeset locks are held while the hook is called.
>*/
> void (*suspend)(struct intel_encoder *);
> + /*
> + * Called without the modeset locks held after the suspend() hook for
> + * all encoders have been called.
> + */
> + void (*suspend_complete)(struct intel_encoder *encoder);
> /*
>* Called during system reboot/shutdown after all the
>* encoders have been disabled and suspended.
> + * All modeset locks are held while the hook is called.
>*/
> void (*shutdown)(struct intel_encoder *encoder);
> + /*
> + * Called without the modeset locks held after the shutdown() hook for
> + * all encoders have been called.
> + */
> + void (*shutdown_complete)(struct intel_encoder *encoder);
> /*
>* Enable/disable the
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tc: Add a workaround for an IOM/TCSS firmware hang issue (rev11)
== Series Details ==
Series: drm/i915/tc: Add a workaround for an IOM/TCSS firmware hang issue
(rev11)
URL : https://patchwork.freedesktop.org/series/117004/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13129_full -> Patchwork_117004v11_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_117004v11_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_117004v11_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117004v11_full:
### IGT changes ###
Possible regressions
* igt@gem_busy@close-race:
- shard-snb: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-snb6/igt@gem_b...@close-race.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-snb5/igt@gem_b...@close-race.html
Known issues
Here are the changes found in Patchwork_117004v11_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2846])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-glk9/igt@gem_exec_f...@basic-deadline.html
* igt@gem_huc_copy@huc-copy:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-glk8/igt@gem_huc_c...@huc-copy.html
* igt@gem_pread@exhaustion:
- shard-glk: NOTRUN -> [WARN][6] ([i915#2658])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-glk8/igt@gem_pr...@exhaustion.html
* igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-glk8/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [PASS][8] -> [FAIL][9] ([i915#2346])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_psr2_su@page_flip-p010:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#658])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-glk8/igt@kms_psr2_su@page_flip-p010.html
* igt@kms_scaling_modes@scaling-mode-full-aspect:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271]) +23 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-glk8/igt@kms_scaling_mo...@scaling-mode-full-aspect.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- shard-glk: [ABORT][12] ([i915#7461] / [i915#8211]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-glk6/igt@gem_barrier_race@remote-requ...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-glk8/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_eio@hibernate:
- {shard-tglu}: [ABORT][14] ([i915#7953] / [i915#7975] / [i915#8213]
/ [i915#8398]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-tglu-10/igt@gem_...@hibernate.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-tglu-2/igt@gem_...@hibernate.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [FAIL][16] ([i915#2842]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][18] ([i915#2842]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-rkl-2/igt@gem_exec_fair@basic-p...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/shard-rkl-7/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- {shard-rkl}:[SKIP][20] ([i915#1397]) -> [PASS][21] +1 similar
issue
[20]:
https://intel-gfx-ci.01.org/tree/d
Re: [Intel-gfx] [PATCH] drm/i915: WARN if not all pipes are in bigjoiner mask, when copying plane state
On Tue, May 09, 2023 at 02:14:41PM +0300, Stanislav Lisovskiy wrote: > There is a suspicion that we might not have all bigjoiner pipes > set in correspodent mask, which leads to that not all crtc are added to the > state, > however because we are copying for instance crtc reference from master crtc > to slave crtc, we might be trying to get it via > intel_atomic_get_new_crtc_state, > which might the return NULL. > This is surely not a fix, but at least the WARN should give us some clue and > "red light" when this happens. > In future we might need to evaluate the logic of adding crtc to the state, > to make sure that we always have all affected crtcs in the state, > even though such functions already exist, there seem to be still some > glitches in this logic. > > Signed-off-by: Stanislav Lisovskiy > --- > drivers/gpu/drm/i915/display/intel_atomic_plane.c | 13 + > drivers/gpu/drm/i915/display/intel_display.c | 2 +- > drivers/gpu/drm/i915/display/intel_display.h | 1 + > 3 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c > index 4125ee07a271..03cbd755261b 100644 > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c > @@ -695,6 +695,19 @@ int intel_plane_atomic_check(struct intel_atomic_state > *state, > > new_master_plane_state = > intel_atomic_get_new_plane_state(state, master_plane); > + > + /* > + * We would be copying plane state from master crtc > + * however if crtc_state->bigjoiner_pipes doesn't contain both > + * master and slave, that means that quite likely we didn't call > + * intel_atomic_get_crtc_state for both, which can cause issues, > + * like intel_atomic_get_new_crtc_state returning NULL > suddently, > + * when we for example try to use hw.crtc from that plane state. > + * This WARN might sched some light on out existing issues, also > + * prevent others from happening in future. > + */ > + drm_WARN_ON(state->base.dev, > intel_bigjoiner_num_pipes(new_crtc_state) < 2); What you are doing here is basically just if (bigjoiner_pipes) assert(bigjoiner_pipes != 1); which is not going to catch anything. We can trivially see that it will never happen given how bigjoiner_pipes is initialized. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 1/2] drm/fourcc: define Intel Meteorlake related ccs modifiers
On Tue, 09 May 2023, Juha-Pekka Heikkila wrote:
> Add Tile4 type ccs modifiers with aux buffer needed for MTL
Please send this Cc: dri-devel too.
BR,
Jani.
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> include/uapi/drm/drm_fourcc.h | 43 +++
> 1 file changed, 43 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index de703c6be969..cbe214adf1e4 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -657,6 +657,49 @@ extern "C" {
> */
> #define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC fourcc_mod_code(INTEL, 12)
>
> +/*
> + * Intel color control surfaces (CCS) for display ver 14 render compression.
> + *
> + * The main surface is tile4 and at plane index 0, the CCS is linear and
> + * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
> + * main surface. In other words, 4 bits in CCS map to a main surface cache
> + * line pair. The main surface pitch is required to be a multiple of four
> + * tile4 widths.
> + */
> +#define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS fourcc_mod_code(INTEL, 13)
> +
> +/*
> + * Intel color control surfaces (CCS) for display ver 14 media compression
> + *
> + * The main surface is tile4 and at plane index 0, the CCS is linear and
> + * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
> + * main surface. In other words, 4 bits in CCS map to a main surface cache
> + * line pair. The main surface pitch is required to be a multiple of four
> + * tile4 widths. For semi-planar formats like NV12, CCS planes follow the
> + * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
> + * planes 2 and 3 for the respective CCS.
> + */
> +#define I915_FORMAT_MOD_4_TILED_MTL_MC_CCS fourcc_mod_code(INTEL, 14)
> +
> +/*
> + * Intel Color Control Surface with Clear Color (CCS) for display ver 14
> render
> + * compression.
> + *
> + * The main surface is tile4 and is at plane index 0 whereas CCS is linear
> + * and at index 1. The clear color is stored at index 2, and the pitch should
> + * be ignored. The clear color structure is 256 bits. The first 128 bits
> + * represents Raw Clear Color Red, Green, Blue and Alpha color each
> represented
> + * by 32 bits. The raw clear color is consumed by the 3d engine and generates
> + * the converted clear color of size 64 bits. The first 32 bits store the
> Lower
> + * Converted Clear Color value and the next 32 bits store the Higher
> Converted
> + * Clear Color value when applicable. The Converted Clear Color values are
> + * consumed by the DE. The last 64 bits are used to store Color Discard
> Enable
> + * and Depth Clear Value Valid which are ignored by the DE. A CCS cache line
> + * corresponds to an area of 4x1 tiles in the main surface. The main surface
> + * pitch is required to be a multiple of 4 tile widths.
> + */
> +#define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC fourcc_mod_code(INTEL, 15)
> +
> /*
> * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> *
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
Hi Lucas,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.4-rc1 next-20230510]
[cannot apply to drm-misc/drm-misc-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Lucas-De-Marchi/drm-amd-Remove-wrapper-macros-over-get_u-32-16-8/20230509-131544
base: git://anongit.freedesktop.org/drm-intel for-linux-next
patch link:
https://lore.kernel.org/r/20230509051403.2748545-3-lucas.demarchi%40intel.com
patch subject: [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
config: arm64-randconfig-r021-20230509
(https://download.01.org/0day-ci/archive/20230510/202305102048.2o5u4wia-...@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project
b0fb98227c90adf2536c9ad644a74d5e9296)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/intel-lab-lkp/linux/commit/dc308f14f76fa2d6c1698a701dfbe0f1b247e6bd
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Lucas-De-Marchi/drm-amd-Remove-wrapper-macros-over-get_u-32-16-8/20230509-131544
git checkout dc308f14f76fa2d6c1698a701dfbe0f1b247e6bd
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=arm64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=arm64 SHELL=/bin/bash lib/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202305102048.2o5u4wia-...@intel.com/
All errors (new ones prefixed by >>):
>> lib/zstd/compress/zstd_opt.c:785:9: error: type specifier missing, defaults
>> to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
typedef U32 (*ZSTD_getAllMatchesFn)(
~~~ ^
int
include/vdso/const.h:7:18: note: expanded from macro 'U32'
#define U32(x) (_U32(x))
^
include/uapi/linux/const.h:25:19: note: expanded from macro '_U32'
#define _U32(x) (_AC(x, U))
^
include/uapi/linux/const.h:21:18: note: expanded from macro '_AC'
#define _AC(X,Y)__AC(X,Y)
^
include/uapi/linux/const.h:20:20: note: expanded from macro '__AC'
#define __AC(X,Y) (X##Y)
^
:178:1: note: expanded from here
ZSTD_getAllMatchesFnU
^
>> lib/zstd/compress/zstd_opt.c:851:8: error: unknown type name
>> 'ZSTD_getAllMatchesFn'; did you mean 'ZSTD_getAllMatchesFnU'?
static ZSTD_getAllMatchesFn
^~~~
ZSTD_getAllMatchesFnU
lib/zstd/compress/zstd_opt.c:785:9: note: 'ZSTD_getAllMatchesFnU' declared
here
typedef U32 (*ZSTD_getAllMatchesFn)(
^
include/vdso/const.h:7:18: note: expanded from macro 'U32'
#define U32(x) (_U32(x))
^
include/uapi/linux/const.h:25:19: note: expanded from macro '_U32'
#define _U32(x) (_AC(x, U))
^
include/uapi/linux/const.h:21:18: note: expanded from macro '_AC'
#define _AC(X,Y)__AC(X,Y)
^
include/uapi/linux/const.h:20:20: note: expanded from macro '__AC'
#define __AC(X,Y) (X##Y)
^
:178:1: note: expanded from here
ZSTD_getAllMatchesFnU
^
>> lib/zstd/compress/zstd_opt.c:854:5: error: use of undeclared identifier
>> 'ZSTD_getAllMatchesFn'
ZSTD_getAllMatchesFn const getAllMatchesFns[3][4] = {
^
>> lib/zstd/compress/zstd_opt.c:862:12: error: use of undeclared identifier
>> 'getAllMatchesFns'
return getAllMatchesFns[(int)dictMode][mls - 3];
^
lib/zstd/compress/zstd_opt.c:1054:5: error: unknown type name
'ZSTD_getAllMatchesFn'; did you mean 'ZSTD_getAllMatchesFnU'?
ZSTD_getAllMatchesFn getAllMatches = ZSTD_selectBtGetAllMatches(ms,
dictMode);
^~~~
ZSTD_getAllMatchesFnU
lib/zstd/compress/zstd_opt.c:785:9: note: 'ZSTD_getAllMatchesFnU' declar
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix typo in intel_frontbuffer
== Series Details ==
Series: drm/i915: Fix typo in intel_frontbuffer
URL : https://patchwork.freedesktop.org/series/117567/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13129_full -> Patchwork_117567v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_117567v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-apl: [PASS][1] -> [ABORT][2] ([i915#180])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-apl3/igt@gem_ctx_isolation@preservation...@bcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-apl6/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2846])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-glk3/igt@gem_exec_f...@basic-deadline.html
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][5] -> [DMESG-FAIL][6] ([i915#8319])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-snb4/igt@i915_pm_...@reset.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-snb2/igt@i915_pm_...@reset.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-apl: [PASS][7] -> [DMESG-FAIL][8] ([i915#5334])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-apl2/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-apl6/igt@i915_selftest@live@gt_heartbeat.html
Possible fixes
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][9] ([i915#6268]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-tglu-4/igt@gem_ctx_e...@basic-nohangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-tglu-9/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_eio@hibernate:
- {shard-tglu}: [ABORT][11] ([i915#7953] / [i915#7975] / [i915#8213]
/ [i915#8398]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-tglu-10/igt@gem_...@hibernate.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-tglu-9/igt@gem_...@hibernate.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [FAIL][13] ([i915#2842]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#2842]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-rkl-7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-rkl-2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- {shard-rkl}:[SKIP][17] ([i915#1397]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-rkl-7/igt@i915_pm_...@dpms-mode-unset-non-lpsp.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-rkl-4/igt@i915_pm_...@dpms-mode-unset-non-lpsp.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [FAIL][19] ([i915#2346]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2:
- shard-glk: [FAIL][21] ([i915#79]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-glk2/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-glk5/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.html
* {igt@kms_plane_scaling@intel-max-src-size@pipe-a-hdmi-a-2}:
- {shard-rkl}:[FAIL][23] ([i915#8292]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/shard-rkl-6/igt@kms_plane_scaling@intel-max-src-s...@pipe-a-hdmi-a-2.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/shard-rkl-4/igt@kms_plane_scaling@intel-max-src-s...@pipe-a-hdmi-a-2.html
{name}: This element i
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tc: Add a workaround for an IOM/TCSS firmware hang issue (rev11)
== Series Details ==
Series: drm/i915/tc: Add a workaround for an IOM/TCSS firmware hang issue
(rev11)
URL : https://patchwork.freedesktop.org/series/117004/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13129 -> Patchwork_117004v11
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/index.html
Participating hosts (41 -> 39)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_117004v11 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_backlight@basic-brightness@edp-1:
- bat-rplp-1: NOTRUN -> [ABORT][1] ([i915#7077])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/bat-rplp-1/igt@i915_pm_backlight@basic-brightn...@edp-1.html
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [PASS][2] -> [ABORT][3] ([i915#7911] / [i915#7913])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@slpc:
- bat-rpls-2: [PASS][4] -> [DMESG-WARN][5] ([i915#6367])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/bat-rpls-2/igt@i915_selftest@l...@slpc.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/bat-rpls-2/igt@i915_selftest@l...@slpc.html
Possible fixes
* igt@i915_selftest@live@requests:
- {bat-mtlp-8}: [ABORT][6] ([i915#4983] / [i915#7920] / [i915#7953])
-> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/bat-mtlp-8/igt@i915_selftest@l...@requests.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/bat-mtlp-8/igt@i915_selftest@l...@requests.html
- {bat-mtlp-6}: [ABORT][8] ([i915#4983] / [i915#7920] / [i915#7953])
-> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/bat-mtlp-6/igt@i915_selftest@l...@requests.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/bat-mtlp-6/igt@i915_selftest@l...@requests.html
Warnings
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: [ABORT][10] ([i915#8260]) -> [SKIP][11] ([i915#3555]
/ [i915#4579])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117004v11/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7920]: https://gitlab.freedesktop.org/drm/intel/issues/7920
[i915#7953]: https://gitlab.freedesktop.org/drm/intel/issues/7953
[i915#8260]: https://gitlab.freedesktop.org/drm/intel/issues/8260
Build changes
-
* Linux: CI_DRM_13129 -> Patchwork_117004v11
CI-20190529: 20190529
CI_DRM_13129: 451e49cfbaa90720149e63f4fa9c7824013c783d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7285: d1cbf2bad9c2664ab8bd3bd0946510a52800912f @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_117004v11: 451e49cfbaa90720149e63f4fa9c7824013c783d @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
10ff32832e41 drm/i915/tc: Reset TypeC PHYs left enabled in DP-alt mode after
the sink disconnects
ee8c5f01994b drm/i915/tc: Call TypeC port flush_work/cleanup without modeset
locks held
dd42b48eac05 drm/i915: Factor out a helper for handling atomic modeset
locks/state
788a9d13ada7 drm/i915/dp: Factor out intel_dp_get_active_pipes()
64c33fbb767f drm/i915/dp: Prevent link training fallback on disconnected port
3fb5a6327794 drm/i915/dp: Convert link training error to debug message on
disconnected sink
511b92f206f5 drm/i915/dp: Add link training debug and error printing helpers
f6253f25571f drm/i915: Add support for disabling any CRTCs during HW
readout/sanitization
9d0c2d68cd9c
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/tc: Add a workaround for an IOM/TCSS firmware hang issue (rev11)
== Series Details == Series: drm/i915/tc: Add a workaround for an IOM/TCSS firmware hang issue (rev11) URL : https://patchwork.freedesktop.org/series/117004/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tc: Add a workaround for an IOM/TCSS firmware hang issue (rev11)
== Series Details ==
Series: drm/i915/tc: Add a workaround for an IOM/TCSS firmware hang issue
(rev11)
URL : https://patchwork.freedesktop.org/series/117004/
State : warning
== Summary ==
Error: dim checkpatch failed
1c6ca42f5da6 drm/i915: Fix PIPEDMC disabling for a bigjoiner configuration
c523f3133717 drm/i915: Add helpers to reference/unreference a DPLL for a CRTC
4b78e7cb56ef drm/i915: Make the CRTC state consistent during sanitize-disabling
1deb0c819cfe drm/i915: Update connector atomic state before crtc
sanitize-disabling
5a03f330c916 drm/i915: Separate intel_crtc_disable_noatomic_begin/complete()
cdd2f850fcfc drm/i915: Factor out set_encoder_for_connector()
0e1ed421d648 drm/i915: Add support for disabling any CRTCs during HW
readout/sanitization
486d78e143dc drm/i915/dp: Add link training debug and error printing helpers
-:34: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#34: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:30:
+#define LT_MSG_ARGS(_intel_dp, _dp_phy)
(_intel_dp)->attached_connector->base.base.id, \
+
(_intel_dp)->attached_connector->base.name, \
+
dp_to_dig_port(_intel_dp)->base.base.base.id, \
+
dp_to_dig_port(_intel_dp)->base.base.name, \
+ drm_dp_phy_name(_dp_phy)
-:34: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_intel_dp' - possible
side-effects?
#34: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:30:
+#define LT_MSG_ARGS(_intel_dp, _dp_phy)
(_intel_dp)->attached_connector->base.base.id, \
+
(_intel_dp)->attached_connector->base.name, \
+
dp_to_dig_port(_intel_dp)->base.base.base.id, \
+
dp_to_dig_port(_intel_dp)->base.base.name, \
+ drm_dp_phy_name(_dp_phy)
-:40: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_intel_dp' - possible
side-effects?
#40: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:36:
+#define lt_dbg(_intel_dp, _dp_phy, _format, ...) \
+ drm_dbg_kms(&dp_to_i915(_intel_dp)->drm, \
+ LT_MSG_PREFIX _format, \
+ LT_MSG_ARGS(_intel_dp, _dp_phy), ## __VA_ARGS__)
-:45: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_intel_dp' - possible
side-effects?
#45: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:41:
+#define lt_err(_intel_dp, _dp_phy, _format, ...) \
+ drm_err(&dp_to_i915(_intel_dp)->drm, \
+ LT_MSG_PREFIX _format, \
+ LT_MSG_ARGS(_intel_dp, _dp_phy), ## __VA_ARGS__)
total: 1 errors, 0 warnings, 3 checks, 758 lines checked
3e4284c57120 drm/i915/dp: Convert link training error to debug message on
disconnected sink
-:39: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_intel_dp' - possible
side-effects?
#39: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:41:
+#define lt_err(_intel_dp, _dp_phy, _format, ...) do { \
+ if (intel_digital_port_connected(&dp_to_dig_port(_intel_dp)->base)) \
+ drm_err(&dp_to_i915(_intel_dp)->drm, \
+ LT_MSG_PREFIX _format, \
+ LT_MSG_ARGS(_intel_dp, _dp_phy), ## __VA_ARGS__); \
+ else \
+ lt_dbg(_intel_dp, _dp_phy, "Sink disconnected: " _format, ##
__VA_ARGS__); \
+} while (0)
-:39: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_dp_phy' - possible
side-effects?
#39: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:41:
+#define lt_err(_intel_dp, _dp_phy, _format, ...) do { \
+ if (intel_digital_port_connected(&dp_to_dig_port(_intel_dp)->base)) \
+ drm_err(&dp_to_i915(_intel_dp)->drm, \
+ LT_MSG_PREFIX _format, \
+ LT_MSG_ARGS(_intel_dp, _dp_phy), ## __VA_ARGS__); \
+ else \
+ lt_dbg(_intel_dp, _dp_phy, "Sink disconnected: " _format, ##
__VA_ARGS__); \
+} while (0)
-:39: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_format' - possible
side-effects?
#39: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:41:
+#define lt_err(_intel_dp, _dp_phy, _format, ...) do { \
+ if (intel_digital_port_connected(&dp_to_dig_port(_intel_dp)->base)) \
+ drm_err(&dp_to_i915(_intel_dp)->drm, \
+ LT_MSG_PREFIX _format, \
+ LT_MSG_ARGS(_intel_dp, _dp_phy), ## __VA_ARGS__); \
+ else \
+ lt_dbg(_intel_dp, _dp_phy, "Sink disconnected: " _format, ##
__VA_ARGS__); \
+} while (0)
total: 0 errors, 0 warnings, 3 checks, 18 lines checked
a44bfd3ab166 drm/i915/dp: Prevent link training fallback on disconnected port
aadf7a0770a4 drm/i915/dp: Factor out intel_dp_get_active_pipes()
1ca7b464d077 drm/i915: Factor out a helper for handling atomic modeset
locks/state
Traceback (most recent call last
[Intel-gfx] [PATCH v4 14/14] drm/i915/tc: Reset TypeC PHYs left enabled in DP-alt mode after the sink disconnects
If the output on a DP-alt link with its sink disconnected is kept
enabled for too long (about 20 sec), then some IOM/TCSS firmware timeout
will cause havoc on the PCI bus, at least for other GFX devices on it
which will stop powering up. Since user space is not guaranteed to do a
disabling modeset in time, switch such disconnected but active links to
TBT mode - which is without such shortcomings - with a 2 second delay.
If the above condition is detected already during the driver load/system
resume sanitization step disable the output instead, as at that point no
user space or kernel client depends on a consistent output state yet and
because subsequent atomic modeset on such connectors - without the
actual sink capabilities available - can fail.
An active/disconnected port as above will also block the HPD status of
other active/disconnected ports to get updated (stuck in the connected
state), until the former port is disabled, its PHY is disconnected and
a ~10 ms delay has elapsed. This means the link state for all TypeC
ports/CRTCs must be rechecked after a CRTC is disabled due to the above
reason. For this disconnect the PHY synchronously after the CRTC/port is
disabled and recheck all CRTCs for the above condition whenever such a
port is disabled.
To account for a race condition during driver loading where the sink is
disconnected after the above sanitization step and before the HPD
interrupts get enabled, do an explicit check/link reset if needed from
the encoder's late_register hook, which is called after the HPD
interrupts are enabled already.
v2:
- Handle an active/disconnected port blocking the HPD state update of
another active/disconnected port.
- Cancel the delayed work resetting the link also from the encoder
enable/suspend/shutdown hooks.
- Rebase on the earlier intel_modeset_lock_ctx_retry() addition,
fixing here the missed atomic state reset in case of a retry.
- Fix handling of an error return from intel_atomic_get_crtc_state().
- Recheck if the port needs to be reset after all the atomic state
is locked and async commits are waited on.
v3:
- Add intel_crtc_needs_link_reset(), instead of open-coding it,
keep intel_crtc_has_encoders(). (Ville)
- Fix state dumping and use a bitmask to track disabled CRTCs in
intel_sanitize_all_crtcs(). (Ville)
- Set internal in intel_atomic_state right after allocating it.
(Ville)
- Recheck all CRTCs (not yet force-disabled) after a CRTC is
force-disabled for any reason (not only due to a link state)
in intel_sanitize_all_crtcs().
- Reduce delay after CRTC disabling to 20ms, and use the simpler
msleep().
- Clarify code comment about HPD behaviour in
intel_sanitize_all_crtcs().
- Move all the TC link reset logic to intel_tc.c .
- Cancel the link reset work synchronously during system suspend,
driver unload and shutdown.
v4:
- Rebased on previous patch, which allows calling the TC port
suspend/cleanup handlers without modeset locks held; remove the
display driver suspended assert from the link reset work
accordingly.
Cc: Kai-Heng Feng
Cc: Ville Syrjälä
Tested-by: Kai-Heng Feng
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5860
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 32 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
.../drm/i915/display/intel_modeset_setup.c| 85 --
drivers/gpu/drm/i915/display/intel_tc.c | 156 +-
drivers/gpu/drm/i915/display/intel_tc.h | 5 +-
6 files changed, 262 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 7d09bd2412352..b443a79bc9803 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3313,6 +3313,8 @@ static void intel_disable_ddi(struct intel_atomic_state
*state,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
+ intel_tc_port_link_cancel_reset_work(enc_to_dig_port(encoder));
+
intel_hdcp_disable(to_intel_connector(old_conn_state->connector));
if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
@@ -3381,6 +3383,8 @@ intel_ddi_pre_pll_enable(struct intel_atomic_state *state,
enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
bool is_tc_port = intel_phy_is_tc(dev_priv, phy);
+ intel_tc_port_link_cancel_reset_work(dig_port);
+
if (is_tc_port) {
struct intel_crtc *master_crtc =
to_intel_crtc(crtc_state->uapi.crtc);
@@ -4232,9 +4236,19 @@ static void intel_ddi_encoder_reset(struct drm_encoder
*encoder)
intel_tc_port_init_mode(dig_port);
}
+static int intel_ddi_encoder_late_register(struct drm_encoder *_encoder)
+{
+ struct intel_encoder *encoder = to_inte
[Intel-gfx] [PATCH v4 13/14] drm/i915/tc: Call TypeC port flush_work/cleanup without modeset locks held
Call the TypeC port flush_work and cleanup handlers without the modeset
locks held. These don't require the locks, as the work takes - as it
should be able to at any point in time - any locks it needs and by the
time cleanup is called and after cleanup returns the encoder is not in
use.
This is required by the next patch canceling a TypeC port work
synchronously during encoder suspend and shutdown, where the work can
take modeset locks as well, hence the canceling must be done without
holding the locks.
I also considered moving the modeset locking down to each encoder
suspend()/shutdown() hook instead, however locking the full modeset
state for each encoder separately would be odd, and the bigger change -
affecting all encoders - is beyond the scope of this patchset.
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 27 +--
.../drm/i915/display/intel_display_types.h| 12 +
drivers/gpu/drm/i915/i915_driver.c| 8 ++
3 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 813be957ed11b..7d09bd2412352 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4617,31 +4617,27 @@ static bool intel_ddi_is_tc(struct drm_i915_private
*i915, enum port port)
static void intel_ddi_encoder_suspend(struct intel_encoder *encoder)
{
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
- struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
- enum phy phy = intel_port_to_phy(i915, encoder->port);
-
intel_dp_encoder_suspend(encoder);
+}
- if (!intel_phy_is_tc(i915, phy))
- return;
+static void intel_ddi_tc_encoder_suspend_complete(struct intel_encoder
*encoder)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
intel_tc_port_flush_work(dig_port);
}
static void intel_ddi_encoder_shutdown(struct intel_encoder *encoder)
{
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
- struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
- enum phy phy = intel_port_to_phy(i915, encoder->port);
-
intel_dp_encoder_shutdown(encoder);
intel_hdmi_encoder_shutdown(encoder);
+}
- if (!intel_phy_is_tc(i915, phy))
- return;
+static void intel_ddi_tc_encoder_shutdown_complete(struct intel_encoder
*encoder)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
intel_tc_port_cleanup(dig_port);
}
@@ -4908,6 +4904,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
is_legacy ? "legacy" : "non-legacy");
}
+ encoder->suspend_complete =
intel_ddi_tc_encoder_suspend_complete;
+ encoder->shutdown_complete =
intel_ddi_tc_encoder_shutdown_complete;
+
if (intel_tc_port_init(dig_port, is_legacy) < 0)
goto err;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 270c4c84a2920..88b2a55d19f21 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -233,13 +233,25 @@ struct intel_encoder {
* Called during system suspend after all pending requests for the
* encoder are flushed (for example for DP AUX transactions) and
* device interrupts are disabled.
+* All modeset locks are held while the hook is called.
*/
void (*suspend)(struct intel_encoder *);
+ /*
+* Called without the modeset locks held after the suspend() hook for
+* all encoders have been called.
+*/
+ void (*suspend_complete)(struct intel_encoder *encoder);
/*
* Called during system reboot/shutdown after all the
* encoders have been disabled and suspended.
+* All modeset locks are held while the hook is called.
*/
void (*shutdown)(struct intel_encoder *encoder);
+ /*
+* Called without the modeset locks held after the shutdown() hook for
+* all encoders have been called.
+*/
+ void (*shutdown_complete)(struct intel_encoder *encoder);
/*
* Enable/disable the clock to the port.
*/
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index fd198700272b1..705ba65f2ff9a 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -964,6 +964,10 @@ static void intel_susp
[Intel-gfx] [PATCH v4 12/14] drm/i915: Factor out a helper for handling atomic modeset locks/state
This patch simplifying the handling of modeset locks and atomic state
for an atomic commit is based on
https://lore.kernel.org/all/20210715184954.7794-2-ville.syrj...@linux.intel.com/
adding the helper to i915. I find this approach preferrable than
open-coding the corresponding steps (fixed for me an atomic
state reset during a DEADLK retry, which I missed in the open-coded
version) and also better than the existing
DRM_MODESET_LOCK_ALL_BEGIN/END macros for the reasons described in the
above original patchset.
This change takes the helper into use only for atomic commits during DDI
hotplug handling, as a preparation for a follow-up patch adding a
similar commit started from the same spot. Other places doing a
driver-internal atomic commit is to be converted by a follow-up
patchset.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_ddi.c | 17 ++-
.../gpu/drm/i915/display/intel_modeset_lock.c | 50 +++
.../gpu/drm/i915/display/intel_modeset_lock.h | 33
4 files changed, 87 insertions(+), 14 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_modeset_lock.c
create mode 100644 drivers/gpu/drm/i915/display/intel_modeset_lock.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d97d45ae1a0d7..2a388bc1f07cb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -264,6 +264,7 @@ i915-y += \
display/intel_hti.o \
display/intel_load_detect.o \
display/intel_lpe_audio.o \
+ display/intel_modeset_lock.o \
display/intel_modeset_verify.o \
display/intel_modeset_setup.o \
display/intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 0ba5492c06047..813be957ed11b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -63,6 +63,7 @@
#include "intel_hti.h"
#include "intel_lspcon.h"
#include "intel_mg_phy_regs.h"
+#include "intel_modeset_lock.h"
#include "intel_pps.h"
#include "intel_psr.h"
#include "intel_quirks.h"
@@ -4403,26 +4404,14 @@ intel_ddi_hotplug(struct intel_encoder *encoder,
state = intel_encoder_hotplug(encoder, connector);
- drm_modeset_acquire_init(&ctx, 0);
-
- for (;;) {
+ intel_modeset_lock_ctx_retry(&ctx, NULL, 0, ret) {
if (connector->base.connector_type == DRM_MODE_CONNECTOR_HDMIA)
ret = intel_hdmi_reset_link(encoder, &ctx);
else
ret = intel_dp_retrain_link(encoder, &ctx);
-
- if (ret == -EDEADLK) {
- drm_modeset_backoff(&ctx);
- continue;
- }
-
- break;
}
- drm_modeset_drop_locks(&ctx);
- drm_modeset_acquire_fini(&ctx);
- drm_WARN(encoder->base.dev, ret,
-"Acquiring modeset locks failed with %i\n", ret);
+ drm_WARN_ON(encoder->base.dev, ret);
/*
* Unpowered type-c dongles can take some time to boot and be
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_lock.c
b/drivers/gpu/drm/i915/display/intel_modeset_lock.c
new file mode 100644
index 0..8fb6fd849a75d
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_modeset_lock.c
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include
+
+#include "intel_display_types.h"
+#include "intel_modeset_lock.h"
+
+void _intel_modeset_lock_begin(struct drm_modeset_acquire_ctx *ctx,
+ struct intel_atomic_state *state,
+ unsigned int flags, int *ret)
+{
+ drm_modeset_acquire_init(ctx, flags);
+
+ if (state)
+ state->base.acquire_ctx = ctx;
+
+ *ret = -EDEADLK;
+}
+
+bool _intel_modeset_lock_loop(int *ret)
+{
+ if (*ret == -EDEADLK) {
+ *ret = 0;
+ return true;
+ }
+
+ return false;
+}
+
+void _intel_modeset_lock_end(struct drm_modeset_acquire_ctx *ctx,
+struct intel_atomic_state *state,
+int *ret)
+{
+ if (*ret == -EDEADLK) {
+ if (state)
+ drm_atomic_state_clear(&state->base);
+
+ *ret = drm_modeset_backoff(ctx);
+ if (*ret == 0) {
+ *ret = -EDEADLK;
+ return;
+ }
+ }
+
+ drm_modeset_drop_locks(ctx);
+ drm_modeset_acquire_fini(ctx);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_lock.h
b/drivers/gpu/drm/i915/display/intel_modeset_lock.h
new file mode 100644
index 0..edb5099bcd99c
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_modeset_lock.h
@@ -0,0 +1,33 @@
+/* SPDX-Lic
[Intel-gfx] [PATCH v4 11/14] drm/i915/dp: Factor out intel_dp_get_active_pipes()
Factor out a helper used by a follow up patch to reset an active DP
link.
No functional changes.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0cc57681dc4d4..99ceaa7d90b62 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4231,9 +4231,9 @@ static bool intel_dp_has_connector(struct intel_dp
*intel_dp,
return false;
}
-static int intel_dp_prep_link_retrain(struct intel_dp *intel_dp,
- struct drm_modeset_acquire_ctx *ctx,
- u8 *pipe_mask)
+static int intel_dp_get_active_pipes(struct intel_dp *intel_dp,
+struct drm_modeset_acquire_ctx *ctx,
+u8 *pipe_mask)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct drm_connector_list_iter conn_iter;
@@ -4242,9 +4242,6 @@ static int intel_dp_prep_link_retrain(struct intel_dp
*intel_dp,
*pipe_mask = 0;
- if (!intel_dp_needs_link_retrain(intel_dp))
- return 0;
-
drm_connector_list_iter_begin(&i915->drm, &conn_iter);
for_each_intel_connector_iter(connector, &conn_iter) {
struct drm_connector_state *conn_state =
@@ -4278,9 +4275,6 @@ static int intel_dp_prep_link_retrain(struct intel_dp
*intel_dp,
}
drm_connector_list_iter_end(&conn_iter);
- if (!intel_dp_needs_link_retrain(intel_dp))
- *pipe_mask = 0;
-
return ret;
}
@@ -4309,13 +4303,19 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
if (ret)
return ret;
- ret = intel_dp_prep_link_retrain(intel_dp, ctx, &pipe_mask);
+ if (!intel_dp_needs_link_retrain(intel_dp))
+ return 0;
+
+ ret = intel_dp_get_active_pipes(intel_dp, ctx, &pipe_mask);
if (ret)
return ret;
if (pipe_mask == 0)
return 0;
+ if (!intel_dp_needs_link_retrain(intel_dp))
+ return 0;
+
drm_dbg_kms(&dev_priv->drm, "[ENCODER:%d:%s] retraining link\n",
encoder->base.base.id, encoder->base.name);
--
2.37.2
[Intel-gfx] [PATCH v4 08/14] drm/i915/dp: Add link training debug and error printing helpers
Add functions for printing link training debug and error messages, both
to prepare for the next patch, which downgrades an error to a debug
message if the sink is disconnected and to remove some code duplication.
v2: (Ville)
- Always print the connector prefix.
- Preserve the drm_dbg_kms() debug category.
v3:
- Keep printing the name of functions calling the helpers. (Jani)
Cc: Ville Syrjälä
Cc: Jani Nikula
Reviewed-by: Ville Syrjälä (v2)
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_dp_link_training.c | 367 ++
1 file changed, 120 insertions(+), 247 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 e92c62bcc9b85..4f33b79b23db0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -26,6 +26,23 @@
#include "intel_dp.h"
#include "intel_dp_link_training.h"
+#define LT_MSG_PREFIX "[CONNECTOR:%d:%s][ENCODER:%d:%s][%s] "
+#define LT_MSG_ARGS(_intel_dp, _dp_phy)
(_intel_dp)->attached_connector->base.base.id, \
+
(_intel_dp)->attached_connector->base.name, \
+
dp_to_dig_port(_intel_dp)->base.base.base.id, \
+
dp_to_dig_port(_intel_dp)->base.base.name, \
+ drm_dp_phy_name(_dp_phy)
+
+#define lt_dbg(_intel_dp, _dp_phy, _format, ...) \
+ drm_dbg_kms(&dp_to_i915(_intel_dp)->drm, \
+ LT_MSG_PREFIX _format, \
+ LT_MSG_ARGS(_intel_dp, _dp_phy), ## __VA_ARGS__)
+
+#define lt_err(_intel_dp, _dp_phy, _format, ...) \
+ drm_err(&dp_to_i915(_intel_dp)->drm, \
+ LT_MSG_PREFIX _format, \
+ LT_MSG_ARGS(_intel_dp, _dp_phy), ## __VA_ARGS__)
+
static void intel_dp_reset_lttpr_common_caps(struct intel_dp *intel_dp)
{
memset(intel_dp->lttpr_common_caps, 0,
sizeof(intel_dp->lttpr_common_caps));
@@ -47,29 +64,21 @@ static void intel_dp_read_lttpr_phy_caps(struct intel_dp
*intel_dp,
const u8 dpcd[DP_RECEIVER_CAP_SIZE],
enum drm_dp_phy dp_phy)
{
- struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
if (drm_dp_read_lttpr_phy_caps(&intel_dp->aux, dpcd, dp_phy, phy_caps)
< 0) {
- drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
- "[ENCODER:%d:%s][%s] failed to read the PHY caps\n",
- encoder->base.base.id, encoder->base.name,
- drm_dp_phy_name(dp_phy));
+ lt_dbg(intel_dp, dp_phy, "failed to read the PHY caps\n");
return;
}
- drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
- "[ENCODER:%d:%s][%s] PHY capabilities: %*ph\n",
- encoder->base.base.id, encoder->base.name,
- drm_dp_phy_name(dp_phy),
- (int)sizeof(intel_dp->lttpr_phy_caps[0]),
- phy_caps);
+ lt_dbg(intel_dp, dp_phy, "PHY capabilities: %*ph\n",
+ (int)sizeof(intel_dp->lttpr_phy_caps[0]),
+ phy_caps);
}
static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp,
const u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
- struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
int ret;
ret = drm_dp_read_lttpr_common_caps(&intel_dp->aux, dpcd,
@@ -77,11 +86,9 @@ static bool intel_dp_read_lttpr_common_caps(struct intel_dp
*intel_dp,
if (ret < 0)
goto reset_caps;
- drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
- "[ENCODER:%d:%s] LTTPR common capabilities: %*ph\n",
- encoder->base.base.id, encoder->base.name,
- (int)sizeof(intel_dp->lttpr_common_caps),
- intel_dp->lttpr_common_caps);
+ lt_dbg(intel_dp, DP_PHY_DPRX, "LTTPR common capabilities: %*ph\n",
+ (int)sizeof(intel_dp->lttpr_common_caps),
+ intel_dp->lttpr_common_caps);
/* The minimum value of
LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV is 1.4 */
if (intel_dp->lttpr_common_caps[0] < 0x14)
@@ -105,8 +112,6 @@ intel_dp_set_lttpr_transparent_mode(struct intel_dp
*intel_dp, bool enable)
static int intel_dp_init_lttpr(struct intel_dp *intel_dp, const u8
dpcd[DP_RECEIVER_CAP_SIZE])
{
- struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
- struct drm_i915_private *i915 = to_i915(encoder->base.dev);
int lttpr_count;
int i;
@@ -138,9 +143,8 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp,
const u8 dpcd[DP_RECEI
return 0;
if (!intel_dp_set_lttpr_transpar
[Intel-gfx] [PATCH v4 10/14] drm/i915/dp: Prevent link training fallback on disconnected port
Prevent downgrading the link training maximum lane count/rate if the
sink is disconnected - and so the link training failure is expected. In
such cases modeset failures due to the reduced max link params would be
just confusing for user space (instead of which the correct thing it
should act on is the sink disconnect signaled by a hotplug event,
requiring a disabling modeset).
v2:
- Check the actual HPD state to handle the forced connector state case.
(Vinod)
Cc: Ville Syrjälä
Cc: Vinod Govindapillai
Reviewed-by: Ville Syrjälä (v1)
Reviewed-by: Vinod Govindapillai
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 5 +
1 file changed, 5 insertions(+)
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 51d1e4b4b2f19..0952a707358c1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -1065,6 +1065,11 @@ static void
intel_dp_schedule_fallback_link_training(struct intel_dp *intel_dp,
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ if (!intel_digital_port_connected(&dp_to_dig_port(intel_dp)->base)) {
+ lt_dbg(intel_dp, DP_PHY_DPRX, "Link Training failed on
disconnected sink.\n");
+ return;
+ }
+
if (intel_dp->hobl_active) {
lt_dbg(intel_dp, DP_PHY_DPRX,
"Link Training failed with HOBL active, not enabling it
from now on\n");
--
2.37.2
[Intel-gfx] [PATCH v4 09/14] drm/i915/dp: Convert link training error to debug message on disconnected sink
If a sink is disconnected it's expected that link training actions will
fail on it, so downgrade the error messages about such actions to be a
debug message. Such - expected - link training failures are more
frequent after a follow up patch, after which an active TypeC link is
reset after the sink is disconnected which also involves a link
training.
v2:
- Check the actual HPD state to handle the forced connector state case.
(Vinod)
Cc: Ville Syrjälä
Cc: Vinod Govindapillai
Reviewed-by: Ville Syrjälä (v1)
Reviewed-by: Vinod Govindapillai
Signed-off-by: Imre Deak
---
.../gpu/drm/i915/display/intel_dp_link_training.c| 12
1 file changed, 8 insertions(+), 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 4f33b79b23db0..51d1e4b4b2f19 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -38,10 +38,14 @@
LT_MSG_PREFIX _format, \
LT_MSG_ARGS(_intel_dp, _dp_phy), ## __VA_ARGS__)
-#define lt_err(_intel_dp, _dp_phy, _format, ...) \
- drm_err(&dp_to_i915(_intel_dp)->drm, \
- LT_MSG_PREFIX _format, \
- LT_MSG_ARGS(_intel_dp, _dp_phy), ## __VA_ARGS__)
+#define lt_err(_intel_dp, _dp_phy, _format, ...) do { \
+ if (intel_digital_port_connected(&dp_to_dig_port(_intel_dp)->base)) \
+ drm_err(&dp_to_i915(_intel_dp)->drm, \
+ LT_MSG_PREFIX _format, \
+ LT_MSG_ARGS(_intel_dp, _dp_phy), ## __VA_ARGS__); \
+ else \
+ lt_dbg(_intel_dp, _dp_phy, "Sink disconnected: " _format, ##
__VA_ARGS__); \
+} while (0)
static void intel_dp_reset_lttpr_common_caps(struct intel_dp *intel_dp)
{
--
2.37.2
[Intel-gfx] [PATCH v4 06/14] drm/i915: Factor out set_encoder_for_connector()
Factor out a function setting the encoder and CRTC in the connector
atomic state, required by a follow up patch.
No functional changes.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_modeset_setup.c| 28 +--
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
index 2c93f4c5dc8cf..6f59654ea0261 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
@@ -86,6 +86,24 @@ static void intel_crtc_disable_noatomic_begin(struct
intel_crtc *crtc,
&crtc_state->shared_dpll->state);
}
+static void set_encoder_for_connector(struct intel_connector *connector,
+ struct intel_encoder *encoder)
+{
+ struct drm_connector_state *conn_state = connector->base.state;
+
+ if (conn_state->crtc)
+ drm_connector_put(&connector->base);
+
+ if (encoder) {
+ conn_state->best_encoder = &encoder->base;
+ conn_state->crtc = encoder->base.crtc;
+ drm_connector_get(&connector->base);
+ } else {
+ conn_state->best_encoder = NULL;
+ conn_state->crtc = NULL;
+ }
+}
+
static void intel_crtc_disable_noatomic_complete(struct intel_crtc *crtc)
{
struct intel_encoder *encoder;
@@ -140,8 +158,7 @@ static void
intel_modeset_update_connector_atomic_state(struct drm_i915_private
struct intel_encoder *encoder =
to_intel_encoder(connector->base.encoder);
- if (conn_state->crtc)
- drm_connector_put(&connector->base);
+ set_encoder_for_connector(connector, encoder);
if (encoder) {
struct intel_crtc *crtc =
@@ -149,14 +166,7 @@ static void
intel_modeset_update_connector_atomic_state(struct drm_i915_private
const struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
- conn_state->best_encoder = &encoder->base;
- conn_state->crtc = &crtc->base;
conn_state->max_bpc = (crtc_state->pipe_bpp ?: 24) / 3;
-
- drm_connector_get(&connector->base);
- } else {
- conn_state->best_encoder = NULL;
- conn_state->crtc = NULL;
}
}
drm_connector_list_iter_end(&conn_iter);
--
2.37.2
[Intel-gfx] [PATCH v4 07/14] drm/i915: Add support for disabling any CRTCs during HW readout/sanitization
During HW readout/sanitization CRTCs can be disabled only if they don't
have an attached encoder (and so the encoder disable hooks don't need to
be called). An upcoming patch will need to disable CRTCs also with an
attached encoder, so add support for this.
For bigjoiner configs the encoder disabling hooks require the slave CRTC
states, so add these too to the atomic state. Since the connector atomic
state is already up-to-date when the CRTC is disabled the connector
state needs to be updated (reset) after the CRTC is disabled, make this
so. Follow the proper order of disabling first all bigjoiner slaves,
then any port synced CRTC slaves followed by the CRTC originally
requested to be disabled.
v2:
- Fix calculating the bigjoiner_masters mask in a port sync config,
(Ville)
- Keep _noatomic suffix in intel_crtc_disable_noatomic(). (Ville)
- Rebase on full CRTC state reset in this patchset, not requiring
resetting the bigjoiner state separately and (instead) resetting
the full atomic CRTC and related global state after all linked
pipes got disabled.
- Disable portsync slaves before a portsync master.
- Disable a portsync master if a linked portsync slave is disabled.
v3: (Ville)
- Use s/u32/u8 for transcoder and pipe masks.
- Use is_power_of_2() instead of hweight()==1.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.h | 1 +
.../drm/i915/display/intel_modeset_setup.c| 160 --
3 files changed, 152 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 116fa52290b84..3bf67dfa66f2b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -225,7 +225,7 @@ is_trans_port_sync_slave(const struct intel_crtc_state
*crtc_state)
return crtc_state->master_transcoder != INVALID_TRANSCODER;
}
-static bool
+bool
is_trans_port_sync_master(const struct intel_crtc_state *crtc_state)
{
return crtc_state->sync_mode_slaves_mask != 0;
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index ac95961f68ba7..3ecc5649a73ab 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -407,6 +407,7 @@ intel_mode_valid_max_plane_size(struct drm_i915_private
*dev_priv,
bool bigjoiner);
enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port);
bool is_trans_port_sync_mode(const struct intel_crtc_state *state);
+bool is_trans_port_sync_master(const struct intel_crtc_state *state);
bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state *crtc_state);
bool intel_crtc_is_bigjoiner_master(const struct intel_crtc_state *crtc_state);
u8 intel_crtc_bigjoiner_slave_pipes(const struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
index 6f59654ea0261..75b4dea1e442b 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
@@ -38,8 +38,8 @@ static void intel_crtc_disable_noatomic_begin(struct
intel_crtc *crtc,
to_intel_crtc_state(crtc->base.state);
struct intel_plane *plane;
struct drm_atomic_state *state;
- struct intel_crtc_state *temp_crtc_state;
- int ret;
+ struct intel_crtc *temp_crtc;
+ enum pipe pipe = crtc->pipe;
if (!crtc_state->hw.active)
return;
@@ -64,10 +64,17 @@ static void intel_crtc_disable_noatomic_begin(struct
intel_crtc *crtc,
to_intel_atomic_state(state)->internal = true;
/* Everything's already locked, -EDEADLK can't happen. */
- temp_crtc_state = intel_atomic_get_crtc_state(state, crtc);
- ret = drm_atomic_add_affected_connectors(state, &crtc->base);
+ for_each_intel_crtc_in_pipe_mask(&i915->drm, temp_crtc,
+BIT(pipe) |
+
intel_crtc_bigjoiner_slave_pipes(crtc_state)) {
+ struct intel_crtc_state *temp_crtc_state =
+ intel_atomic_get_crtc_state(state, temp_crtc);
+ int ret;
+
+ ret = drm_atomic_add_affected_connectors(state,
&temp_crtc->base);
- drm_WARN_ON(&i915->drm, IS_ERR(temp_crtc_state) || ret);
+ drm_WARN_ON(&i915->drm, IS_ERR(temp_crtc_state) || ret);
+ }
i915->display.funcs.display->crtc_disable(to_intel_atomic_state(state),
crtc);
@@ -104,9 +111,38 @@ static void set_encoder_for_connector(struct
intel_connector *connector,
}
}
-static void intel_crtc_disable_noatomic_complete(struct intel_crtc *crtc)
+static void reset_encoder_connector_state(struct inte
[Intel-gfx] [PATCH v4 05/14] drm/i915: Separate intel_crtc_disable_noatomic_begin/complete()
Split calling the CRTC/encoder disabling hooks and updating the CRTC and
DPLL object states from updating the CRTC and atomic state and other
global state (BW, CDCLK, DBUF) into separate functions. When disabling a
bigjoiner configuration the latter step can be done only after all the
linked pipes are disabled, so this change prepares for that.
No functional changes.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_modeset_setup.c| 34 +--
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
index 66796e8eef90a..2c93f4c5dc8cf 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
@@ -30,23 +30,15 @@
#include "intel_wm.h"
#include "skl_watermark.h"
-static void intel_crtc_disable_noatomic(struct intel_crtc *crtc,
- struct drm_modeset_acquire_ctx *ctx)
+static void intel_crtc_disable_noatomic_begin(struct intel_crtc *crtc,
+ struct drm_modeset_acquire_ctx
*ctx)
{
- struct intel_encoder *encoder;
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
- struct intel_bw_state *bw_state =
- to_intel_bw_state(i915->display.bw.obj.state);
- struct intel_cdclk_state *cdclk_state =
- to_intel_cdclk_state(i915->display.cdclk.obj.state);
- struct intel_dbuf_state *dbuf_state =
- to_intel_dbuf_state(i915->display.dbuf.obj.state);
struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
struct intel_plane *plane;
struct drm_atomic_state *state;
struct intel_crtc_state *temp_crtc_state;
- enum pipe pipe = crtc->pipe;
int ret;
if (!crtc_state->hw.active)
@@ -92,6 +84,21 @@ static void intel_crtc_disable_noatomic(struct intel_crtc
*crtc,
intel_unreference_shared_dpll_crtc(crtc,
crtc_state->shared_dpll,
&crtc_state->shared_dpll->state);
+}
+
+static void intel_crtc_disable_noatomic_complete(struct intel_crtc *crtc)
+{
+ struct intel_encoder *encoder;
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+ struct intel_bw_state *bw_state =
+ to_intel_bw_state(i915->display.bw.obj.state);
+ struct intel_cdclk_state *cdclk_state =
+ to_intel_cdclk_state(i915->display.cdclk.obj.state);
+ struct intel_dbuf_state *dbuf_state =
+ to_intel_dbuf_state(i915->display.dbuf.obj.state);
+ struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(crtc->base.state);
+ enum pipe pipe = crtc->pipe;
__drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi);
intel_crtc_free_hw_state(crtc_state);
@@ -115,6 +122,13 @@ static void intel_crtc_disable_noatomic(struct intel_crtc
*crtc,
bw_state->num_active_planes[pipe] = 0;
}
+static void intel_crtc_disable_noatomic(struct intel_crtc *crtc,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ intel_crtc_disable_noatomic_begin(crtc, ctx);
+ intel_crtc_disable_noatomic_complete(crtc);
+}
+
static void intel_modeset_update_connector_atomic_state(struct
drm_i915_private *i915)
{
struct intel_connector *connector;
--
2.37.2
[Intel-gfx] [PATCH v4 03/14] drm/i915: Make the CRTC state consistent during sanitize-disabling
Make sure that the CRTC state is reset correctly, as expected after disabling the CRTC. In particular this change will: - Zero all the CSC blob pointers after intel_crtc_free_hw_state() has freed them. - Zero the shared DPLL and port PLL pointers and clear the corresponding CRTC reference flag in the PLL state. - Reset all the transcoder and pipe fields. v2: - Reset fully the CRTC state. (Ville) - Clear pipe active flags in the DPLL state. v3: - Clear only the CRTC reference flag and add a helper for this. (Ville) v4: - Rebased on previous patch, adding intel_unreference_shared_dpll_crtc() separately. (Ville) Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 3 +++ drivers/gpu/drm/i915/display/intel_modeset_setup.c | 13 +++-- 3 files changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c index 84ebe66012b1d..f603ab1e9a0e2 100644 --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c @@ -399,7 +399,7 @@ intel_reference_shared_dpll(struct intel_atomic_state *state, * * Drop a reference for @pll tracking the end of use of it by @crtc. */ -static void +void intel_unreference_shared_dpll_crtc(const struct intel_crtc *crtc, const struct intel_shared_dpll *pll, struct intel_shared_dpll_state *shared_dpll_state) diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h index 3854f1b4299ac..ba62eb5d7c517 100644 --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h @@ -341,6 +341,9 @@ int intel_reserve_shared_dplls(struct intel_atomic_state *state, struct intel_encoder *encoder); void intel_release_shared_dplls(struct intel_atomic_state *state, struct intel_crtc *crtc); +void intel_unreference_shared_dpll_crtc(const struct intel_crtc *crtc, + const struct intel_shared_dpll *pll, + struct intel_shared_dpll_state *shared_dpll_state); void icl_set_active_port_dpll(struct intel_crtc_state *crtc_state, enum icl_port_dpll_id port_dpll_id); void intel_update_active_dpll(struct intel_atomic_state *state, diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c b/drivers/gpu/drm/i915/display/intel_modeset_setup.c index eefa4018dc0c2..6e55806bbe066 100644 --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c @@ -88,13 +88,14 @@ static void intel_crtc_disable_noatomic(struct intel_crtc *crtc, crtc->active = false; crtc->base.enabled = false; - drm_WARN_ON(&i915->drm, - drm_atomic_set_mode_for_crtc(&crtc_state->uapi, NULL) < 0); - crtc_state->uapi.active = false; - crtc_state->uapi.connector_mask = 0; - crtc_state->uapi.encoder_mask = 0; + if (crtc_state->shared_dpll) + intel_unreference_shared_dpll_crtc(crtc, + crtc_state->shared_dpll, + &crtc_state->shared_dpll->state); + + __drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi); intel_crtc_free_hw_state(crtc_state); - memset(&crtc_state->hw, 0, sizeof(crtc_state->hw)); + intel_crtc_state_reset(crtc_state, crtc); for_each_encoder_on_crtc(&i915->drm, &crtc->base, encoder) encoder->base.crtc = NULL; -- 2.37.2
[Intel-gfx] [PATCH v4 02/14] drm/i915: Add helpers to reference/unreference a DPLL for a CRTC
Add helpers to reference/unreference a shared DPLL tracking the use of
it by a given CRTC.
This prepares for the next patch, which unreferences a DPLL during CRTC
HW-readout/sanitization.
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 58 +++
1 file changed, 46 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index ed372d227aa73..84ebe66012b1d 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -351,13 +351,35 @@ intel_find_shared_dpll(struct intel_atomic_state *state,
return NULL;
}
+/**
+ * intel_reference_shared_dpll_crtc - Get a DPLL reference for a CRTC
+ * @crtc: CRTC on which behalf the reference is taken
+ * @pll: DPLL for which the reference is taken
+ * @shared_dpll_state: the DPLL atomic state in which the reference is tracked
+ *
+ * Take a reference for @pll tracking the use of it by @crtc.
+ */
+static void
+intel_reference_shared_dpll_crtc(const struct intel_crtc *crtc,
+const struct intel_shared_dpll *pll,
+struct intel_shared_dpll_state
*shared_dpll_state)
+{
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+
+ drm_WARN_ON(&i915->drm, (shared_dpll_state->pipe_mask &
BIT(crtc->pipe)) != 0);
+
+ shared_dpll_state->pipe_mask |= BIT(crtc->pipe);
+
+ drm_dbg_kms(&i915->drm, "[CRTC:%d:%s] reserving %s\n",
+ crtc->base.base.id, crtc->base.name, pll->info->name);
+}
+
static void
intel_reference_shared_dpll(struct intel_atomic_state *state,
const struct intel_crtc *crtc,
const struct intel_shared_dpll *pll,
const struct intel_dpll_hw_state *pll_state)
{
- struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_shared_dpll_state *shared_dpll;
const enum intel_dpll_id id = pll->info->id;
@@ -366,11 +388,29 @@ intel_reference_shared_dpll(struct intel_atomic_state
*state,
if (shared_dpll[id].pipe_mask == 0)
shared_dpll[id].hw_state = *pll_state;
- drm_WARN_ON(&i915->drm, (shared_dpll[id].pipe_mask & BIT(crtc->pipe))
!= 0);
+ intel_reference_shared_dpll_crtc(crtc, pll, &shared_dpll[id]);
+}
+
+/**
+ * intel_unreference_shared_dpll_crtc - Drop a DPLL reference for a CRTC
+ * @crtc: CRTC on which behalf the reference is dropped
+ * @pll: DPLL for which the reference is dropped
+ * @shared_dpll_state: the DPLL atomic state in which the reference is tracked
+ *
+ * Drop a reference for @pll tracking the end of use of it by @crtc.
+ */
+static void
+intel_unreference_shared_dpll_crtc(const struct intel_crtc *crtc,
+ const struct intel_shared_dpll *pll,
+ struct intel_shared_dpll_state
*shared_dpll_state)
+{
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
- shared_dpll[id].pipe_mask |= BIT(crtc->pipe);
+ drm_WARN_ON(&i915->drm, (shared_dpll_state->pipe_mask &
BIT(crtc->pipe)) == 0);
- drm_dbg_kms(&i915->drm, "[CRTC:%d:%s] reserving %s\n",
+ shared_dpll_state->pipe_mask &= ~BIT(crtc->pipe);
+
+ drm_dbg_kms(&i915->drm, "[CRTC:%d:%s] releasing %s\n",
crtc->base.base.id, crtc->base.name, pll->info->name);
}
@@ -378,18 +418,12 @@ static void intel_unreference_shared_dpll(struct
intel_atomic_state *state,
const struct intel_crtc *crtc,
const struct intel_shared_dpll *pll)
{
- struct drm_i915_private *i915 = to_i915(state->base.dev);
struct intel_shared_dpll_state *shared_dpll;
const enum intel_dpll_id id = pll->info->id;
shared_dpll = intel_atomic_get_shared_dpll_state(&state->base);
- drm_WARN_ON(&i915->drm, (shared_dpll[id].pipe_mask & BIT(crtc->pipe))
== 0);
-
- shared_dpll[id].pipe_mask &= ~BIT(crtc->pipe);
-
- drm_dbg_kms(&i915->drm, "[CRTC:%d:%s] releasing %s\n",
- crtc->base.base.id, crtc->base.name, pll->info->name);
+ intel_unreference_shared_dpll_crtc(crtc, pll, &shared_dpll[id]);
}
static void intel_put_dpll(struct intel_atomic_state *state,
@@ -4314,7 +4348,7 @@ static void readout_dpll_hw_state(struct drm_i915_private
*i915,
to_intel_crtc_state(crtc->base.state);
if (crtc_state->hw.active && crtc_state->shared_dpll == pll)
- pll->state.pipe_mask |= BIT(crtc->pipe);
+ intel_reference_shared_dpll_crtc(crtc, pll,
&pll->state);
}
pll->active_mask = pll->state.pipe_mask;
--
2.37.2
[Intel-gfx] [PATCH v4 04/14] drm/i915: Update connector atomic state before crtc sanitize-disabling
During HW state readout/sanitization an up-to-date connector atomic
state will be required by a follow-up patch, which can disable CRTCs
with an encoder (and calling the correct encoder hooks happens via the
connector atomic state encoder pointer). So update the connector state
already before the CRTC sanitize/disable step. For now this doesn't make
a difference, since intel_modeset_update_connector_atomic_state() will
update/enable the atomic state only for connectors that have an enabled
encoder/CRTC. Such CRTCs/encoders will not be affected by
intel_sanitize_crtc().
v2: Add comment about why the connector state needs to be up-to-date.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_modeset_setup.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
index 6e55806bbe066..66796e8eef90a 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
@@ -701,6 +701,12 @@ void intel_modeset_setup_hw_state(struct drm_i915_private
*i915,
for_each_intel_encoder(&i915->drm, encoder)
intel_sanitize_encoder(encoder);
+ /*
+* Sanitizing CRTCs needs their connector atomic state to be
+* up-to-date, so ensure that already here.
+*/
+ intel_modeset_update_connector_atomic_state(i915);
+
for_each_intel_crtc(&i915->drm, crtc) {
struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
@@ -709,8 +715,6 @@ void intel_modeset_setup_hw_state(struct drm_i915_private
*i915,
intel_crtc_state_dump(crtc_state, NULL, "setup_hw_state");
}
- intel_modeset_update_connector_atomic_state(i915);
-
intel_dpll_sanitize_state(i915);
intel_wm_get_hw_state(i915);
--
2.37.2
[Intel-gfx] [PATCH v4 01/14] drm/i915: Fix PIPEDMC disabling for a bigjoiner configuration
For a bigjoiner configuration display->crtc_disable() will be called
first for the slave CRTCs and then for the master CRTC. However slave
CRTCs will be actually disabled only after the master CRTC is disabled
(from the encoder disable hooks called with the master CRTC state).
Hence the slave PIPEDMCs can be disabled only after the master CRTC is
disabled, make this so.
intel_encoders_post_pll_disable() must be called only for the master
CRTC, as for the other two encoder disable hooks. While at it fix this
up as well. This didn't cause a problem, since
intel_encoders_post_pll_disable() will call the corresponding hook only
for an encoder/connector connected to the given CRTC, however slave
CRTCs will have no associated encoder/connector.
Fixes: 3af2ff0840be ("drm/i915: Enable a PIPEDMC whenever its corresponding
pipe is enabled")
Cc: Rodrigo Vivi
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1d5d42a408035..116fa52290b84 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1702,9 +1702,17 @@ static void hsw_crtc_disable(struct intel_atomic_state
*state,
intel_disable_shared_dpll(old_crtc_state);
- intel_encoders_post_pll_disable(state, crtc);
+ if (!intel_crtc_is_bigjoiner_slave(old_crtc_state)) {
+ struct intel_crtc *slave_crtc;
+
+ intel_encoders_post_pll_disable(state, crtc);
- intel_dmc_disable_pipe(i915, crtc->pipe);
+ intel_dmc_disable_pipe(i915, crtc->pipe);
+
+ for_each_intel_crtc_in_pipe_mask(&i915->drm, slave_crtc,
+
intel_crtc_bigjoiner_slave_pipes(old_crtc_state))
+ intel_dmc_disable_pipe(i915, slave_crtc->pipe);
+ }
}
static void i9xx_pfit_enable(const struct intel_crtc_state *crtc_state)
--
2.37.2
[Intel-gfx] [PATCH v4 00/14] drm/i915/tc: Add a workaround for an IOM/TCSS firmware hang issue
This is v4 of [1], addressing the review comments from Ville, Vinod and Jani. Patch 13/14 also fixes an issue canceling the link reset work synchronously during system suspend and driver cleanup. Cc: Ville Syrjälä Cc: Vinod Govindapillai Cc: Jani Nikula [1] https://lore.kernel.org/all/20230503231048.432368-1-imre.d...@intel.com/ Imre Deak (14): drm/i915: Fix PIPEDMC disabling for a bigjoiner configuration drm/i915: Add helpers to reference/unreference a DPLL for a CRTC drm/i915: Make the CRTC state consistent during sanitize-disabling drm/i915: Update connector atomic state before crtc sanitize-disabling drm/i915: Separate intel_crtc_disable_noatomic_begin/complete() drm/i915: Factor out set_encoder_for_connector() drm/i915: Add support for disabling any CRTCs during HW readout/sanitization drm/i915/dp: Add link training debug and error printing helpers drm/i915/dp: Convert link training error to debug message on disconnected sink drm/i915/dp: Prevent link training fallback on disconnected port drm/i915/dp: Factor out intel_dp_get_active_pipes() drm/i915: Factor out a helper for handling atomic modeset locks/state drm/i915/tc: Call TypeC port flush_work/cleanup without modeset locks held drm/i915/tc: Reset TypeC PHYs left enabled in DP-alt mode after the sink disconnects drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 68 ++-- drivers/gpu/drm/i915/display/intel_display.c | 14 +- drivers/gpu/drm/i915/display/intel_display.h | 1 + .../drm/i915/display/intel_display_types.h| 12 + drivers/gpu/drm/i915/display/intel_dp.c | 20 +- drivers/gpu/drm/i915/display/intel_dp.h | 3 + .../drm/i915/display/intel_dp_link_training.c | 376 ++ drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 58 ++- drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 3 + .../gpu/drm/i915/display/intel_modeset_lock.c | 50 +++ .../gpu/drm/i915/display/intel_modeset_lock.h | 33 ++ .../drm/i915/display/intel_modeset_setup.c| 318 +-- drivers/gpu/drm/i915/display/intel_tc.c | 156 +++- drivers/gpu/drm/i915/display/intel_tc.h | 5 +- drivers/gpu/drm/i915/i915_driver.c| 8 + 16 files changed, 776 insertions(+), 350 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_modeset_lock.c create mode 100644 drivers/gpu/drm/i915/display/intel_modeset_lock.h -- 2.37.2
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix typo in intel_frontbuffer
== Series Details ==
Series: drm/i915: Fix typo in intel_frontbuffer
URL : https://patchwork.freedesktop.org/series/117567/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13129 -> Patchwork_117567v1
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_117567v1 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_117567v1, 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_117567v1/index.html
Participating hosts (41 -> 39)
--
Missing(2): bat-rpls-2 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_117567v1:
### IGT changes ###
Warnings
* igt@kms_chamelium_hpd@vga-hpd-fast:
- fi-kbl-soraka: [SKIP][1] ([fdo#109271]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/fi-kbl-soraka/igt@kms_chamelium_...@vga-hpd-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/fi-kbl-soraka/igt@kms_chamelium_...@vga-hpd-fast.html
* igt@kms_psr@sprite_plane_onoff:
- bat-rplp-1: [SKIP][3] ([i915#1072]) -> [ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/bat-rplp-1/igt@kms_psr@sprite_plane_onoff.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/bat-rplp-1/igt@kms_psr@sprite_plane_onoff.html
Known issues
Here are the changes found in Patchwork_117567v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-kbl-soraka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/fi-kbl-soraka/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][7] -> [DMESG-FAIL][8] ([i915#5334])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@migrate:
- bat-adlp-9: [PASS][9] -> [DMESG-FAIL][10] ([i915#7699] /
[i915#7913])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/bat-adlp-9/igt@i915_selftest@l...@migrate.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/bat-adlp-9/igt@i915_selftest@l...@migrate.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-kbl-7567u: [PASS][11] -> [INCOMPLETE][12] ([i915#4817])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/fi-kbl-7567u/igt@i915_susp...@basic-s3-without-i915.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/fi-kbl-7567u/igt@i915_susp...@basic-s3-without-i915.html
- fi-skl-guc: [PASS][13] -> [ABORT][14] ([i915#7980] / [i915#8189])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/fi-skl-guc/igt@i915_susp...@basic-s3-without-i915.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/fi-skl-guc/igt@i915_susp...@basic-s3-without-i915.html
Possible fixes
* 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_13129/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@requests:
- {bat-mtlp-8}: [ABORT][17] ([i915#4983] / [i915#7920] / [i915#7953])
-> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/bat-mtlp-8/igt@i915_selftest@l...@requests.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html
- {bat-mtlp-6}: [ABORT][19] ([i915#4983] / [i915#7920] / [i915#7953])
-> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13129/bat-mtlp-6/igt@i915_selftest@l...@requests.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117567v1/bat-mtlp-6/igt@i915_selftest@l...@requests.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1982]: http
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix typo in intel_frontbuffer
== Series Details == Series: drm/i915: Fix typo in intel_frontbuffer URL : https://patchwork.freedesktop.org/series/117567/ 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] drm/i915: Fix typo in intel_frontbuffer
Hi Jouni, On Wed, May 10, 2023 at 11:50:43AM +0300, Jouni Högander wrote: > Fix obvious typo in intel_frontbuffer forward declaration. > > Signed-off-by: Jouni Högander > --- > drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > index 830c11431ee8..cb362b09bf21 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > @@ -18,7 +18,7 @@ > #include "i915_vma_resource.h" > > struct drm_i915_gem_object; > -struct intel_fronbuffer; > +struct intel_frontbuffer; Then I guess this is not necessary. Andi > struct intel_memory_region; > > /* > -- > 2.34.1
[Intel-gfx] [PATCH] drm/i915: Fix typo in intel_frontbuffer
Fix obvious typo in intel_frontbuffer forward declaration. Signed-off-by: Jouni Högander --- drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h index 830c11431ee8..cb362b09bf21 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h @@ -18,7 +18,7 @@ #include "i915_vma_resource.h" struct drm_i915_gem_object; -struct intel_fronbuffer; +struct intel_frontbuffer; struct intel_memory_region; /* -- 2.34.1
