[Intel-gfx] [PATCH 1/2] drm/i915/gt: obey "reset" module parameter
From: Marcin Ślusarz For some reason intel_gt_reset attempts to reset the GPU twice. On one code path (do_reset) "reset" parameter is obeyed, but is not on the other one (__intel_gt_set_wedged). Fix this. I noticed this because I stumbled on a bug which completely locks up a machine on reset (preventing me from saving the error state) and i915.reset=0 wasn't working as expected. Signed-off-by: Marcin Ślusarz --- drivers/gpu/drm/i915/gt/intel_reset.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c index 39070b514e65..f4823ca2d71f 100644 --- a/drivers/gpu/drm/i915/gt/intel_reset.c +++ b/drivers/gpu/drm/i915/gt/intel_reset.c @@ -816,7 +816,8 @@ static void __intel_gt_set_wedged(struct intel_gt *gt) awake = reset_prepare(gt); /* Even if the GPU reset fails, it should still stop the engines */ -if (!INTEL_INFO(gt->i915)->gpu_reset_clobbers_display) +if (!INTEL_INFO(gt->i915)->gpu_reset_clobbers_display && +i915_modparams.reset) __intel_gt_reset(gt, ALL_ENGINES); for_each_engine(engine, gt, id) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gt: raise logging level of "gpu reset disabled" message
From: Marcin Ślusarz Few lines above there's drm_notice saying that the gpu will be reset. Printing "gpu reset disabled" using lower logging level makes it harder to figure out what happened. Signed-off-by: Marcin Ślusarz --- drivers/gpu/drm/i915/gt/intel_reset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c index f4823ca2d71f..0384315c190d 100644 --- a/drivers/gpu/drm/i915/gt/intel_reset.c +++ b/drivers/gpu/drm/i915/gt/intel_reset.c @@ -1042,7 +1042,7 @@ void intel_gt_reset(struct intel_gt *gt, if (i915_modparams.reset) drm_err(>->i915->drm, "GPU reset not supported\n"); else -drm_dbg(>->i915->drm, "GPU reset disabled\n"); +drm_notice(>->i915->drm, "GPU reset disabled\n"); goto error; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: raise logging level of "gpu reset disabled" message
Quoting Marcin Ślusarz (2020-08-18 12:37:20) > From: Marcin Ślusarz > > Few lines above there's drm_notice saying that the gpu will be reset. > Printing "gpu reset disabled" using lower logging level makes it > harder to figure out what happened. It's disabled by user request, and we may do this very very frequently. If you are wise enough to touch an unsafe module parameter, you get to keep all the pieces. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915/gt: obey "reset" module parameter
== Series Details == Series: series starting with [1/2] drm/i915/gt: obey "reset" module parameter URL : https://patchwork.freedesktop.org/series/80734/ State : failure == Summary == Applying: drm/i915/gt: obey "reset" module parameter error: git diff header lacks filename information when removing 1 leading pathname component (line 6) error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915/gt: obey "reset" module parameter When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: obey "reset" module parameter
Quoting Marcin Ślusarz (2020-08-18 12:36:07) > From: Marcin Ślusarz > > For some reason intel_gt_reset attempts to reset the GPU twice. > On one code path (do_reset) "reset" parameter is obeyed, but is > not on the other one (__intel_gt_set_wedged). It's not that simple, we do want to force __intel_gt_set_wedged() to cancel whatever is running on the GPU as it is used for more than just failing resets (e.g. around control boundaries) regardless of what the user may want. I'm loathe to add a parameter just to enable unsafe behaviour, but that may be the compromise. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl+: Fix Combo PHY DPLL fractional divider for 38.4MHz ref clock (rev2)
On Mon, Aug 17, 2020 at 09:17:55PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/tgl+: Fix Combo PHY DPLL fractional divider for 38.4MHz ref > clock (rev2) > URL : https://patchwork.freedesktop.org/series/79486/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_8891_full -> Patchwork_18365_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_18365_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_18365_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_18365_full: > > ### IGT changes ### > > Possible regressions > > * igt@runner@aborted: > - shard-tglb: NOTRUN -> ([FAIL][1], [FAIL][2], [FAIL][3], > [FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], > [FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], > [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22], > [FAIL][23], [FAIL][24], [FAIL][25]) This is due to a mismatching fractional divider value used by BIOS vs. the fractional divider value used by the driver after the workaround. The latest BIOS versions use already the divider required by the WA as well, so upgrading BIOS would solve this. Is there any plan for that? >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb8/igt@run...@aborted.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb5/igt@run...@aborted.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb1/igt@run...@aborted.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb1/igt@run...@aborted.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb5/igt@run...@aborted.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb2/igt@run...@aborted.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb1/igt@run...@aborted.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb5/igt@run...@aborted.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb5/igt@run...@aborted.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb8/igt@run...@aborted.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb2/igt@run...@aborted.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb5/igt@run...@aborted.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb1/igt@run...@aborted.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb3/igt@run...@aborted.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb5/igt@run...@aborted.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb1/igt@run...@aborted.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb7/igt@run...@aborted.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb3/igt@run...@aborted.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb2/igt@run...@aborted.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb8/igt@run...@aborted.html >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb7/igt@run...@aborted.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb1/igt@run...@aborted.html >[23]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb7/igt@run...@aborted.html >[24]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb2/igt@run...@aborted.html >[25]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-tglb2/igt@run...@aborted.html > > > Known issues > > > Here are the changes found in Patchwork_18365_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_whisper@basic-contexts-forked: > - shard-glk: [PASS][26] -> [DMESG-WARN][27] ([i915#118] / > [i915#95]) +2 similar issues >[26]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8891/shard-glk6/igt@gem_exec_whis...@basic-contexts-forked.html >[27]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18365/shard-glk3/igt@gem_exec_whis...@basic-contexts-forked.html > > * igt@gen9_exec_parse@allowed-single: > - shard-skl:
[Intel-gfx] [PATCH v8 02/17] drm/i915: Clear the repeater bit on HDCP disable
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-3-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-3-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-3-s...@poorly.run
#v7
Changes in v2:
-Added to the set
Changes in v3:
-None
I had previously agreed that clearing the rep_ctl bits on enable would
also be a good idea. However when I committed that idea to code, it
didn't look right. So let's rely on enables and disables being paired
and everything outside of that will be considered a bug
Changes in v4:
-s/I915_(READ|WRITE)/intel_de_(read|write)/
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6189b7583277..1a0d49af2a08 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -795,6 +795,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
struct intel_hdcp *hdcp = &connector->hdcp;
enum port port = dig_port->base.port;
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+ u32 repeater_ctl;
int ret;
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
@@ -810,6 +811,11 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
return -ETIMEDOUT;
}
+ repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
+ port);
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ intel_de_read(dev_priv, HDCP_REP_CTL) & ~repeater_ctl);
+
ret = hdcp->shim->toggle_signalling(dig_port, false);
if (ret) {
drm_err(&dev_priv->drm, "Failed to disable HDCP signalling\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 03/17] drm/i915: WARN if HDCP signalling is enabled upon disable
From: Sean Paul HDCP signalling should not be left on, WARN if it is Cc: Ville Syrjälä Cc: Daniel Vetter Reviewed-by: Ramalingam C Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-4-s...@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-4-s...@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-4-s...@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-4-s...@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-4-s...@poorly.run #v7 Changes in v2: -Added to the set in lieu of just clearing the bit Changes in v3: -None Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -Rebased, variable name changed from 'ctl' to 'val' Changes in v8: -None --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index de5b216561d8..b02cd36647d6 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -1791,6 +1791,8 @@ void intel_ddi_disable_transcoder_func(const struct intel_crtc_state *crtc_state ctl = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder)); + drm_WARN_ON(crtc->base.dev, ctl & TRANS_DDI_HDCP_SIGNALLING); + ctl &= ~TRANS_DDI_FUNC_ENABLE; if (IS_GEN_RANGE(dev_priv, 8, 10)) -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 01/17] drm/i915: Fix sha_text population code
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being placed on the wrong half of sha_text, overlapping the leftover
ksv value
3- In the sha_leftovers == 2 case, we need to manually terminate the
byte stream with 0x80 since the hardware doesn't have enough room to
add it after writing M0
The upside is that all of the HDCP supported HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-2-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-2-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-2-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-2-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on intel_de_write changes
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 26 +--
include/drm/drm_hdcp.h| 3 +++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 89a4d294822d..6189b7583277 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -336,8 +336,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Fill up the empty slots in sha_text and write it out */
sha_empty = sizeof(sha_text) - sha_leftovers;
- for (j = 0; j < sha_empty; j++)
- sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
+ for (j = 0; j < sha_empty; j++) {
+ u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) *
8);
+ sha_text |= ksv[j] << off;
+ }
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
@@ -435,7 +437,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Write 32 bits of text */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24 | bstatus[1] << 16;
+ sha_text |= bstatus[0] << 8 | bstatus[1];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
@@ -450,17 +452,29 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
return ret;
sha_idx += sizeof(sha_text);
}
+
+ /*
+* Terminate the SHA-1 stream by hand. For the other leftover
+* cases this is appended by the hardware.
+*/
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ rep_ctl | HDCP_SHA1_TEXT_32);
+ sha_text = DRM_HDCP_SHA1_TERMINATOR << 24;
+ ret = intel_write_sha_text(dev_priv, sha_text);
+ if (ret < 0)
+ return ret;
+ sha_idx += sizeof(sha_text);
} else if (sha_leftovers == 3) {
- /* Write 32 bits of text */
+ /* Write 32 bits of text (filled from LSB) */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24;
+ sha_text |= bstatus[0];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
sha_idx += sizeof(sha_text);
- /* Write 8 bits of text, 24 bits of M0 */
+ /* Write 8 bits of text (filled from LSB), 24 bits of M0 */
intel_de_write(dev_priv, HDCP_REP_CTL,
[Intel-gfx] [PATCH v8 04/17] drm/i915: Intercept Aksv writes in the aux hooks
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an LG monitor on my desk, I noticed it was passing
back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
auth was failing as a result. Instead of copy/pasting all of the retry
logic and delays from drm dp helpers, let's just use the helpers and hide
the aksv select as best as we can.
Reviewed-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-3-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-5-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-5-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-5-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-5-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-5-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-5-s...@poorly.run
#v7
Changes in v2:
-Remove 'generate' in intel_dp_aux_generate_xfer_flags, make arg const (Ville)
-Bundle Aksv if statement together (Ville)
-Rename 'txbuf' to 'aksv' (Ville)
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_dp.c | 62 -
1 file changed, 29 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 79c27f91f42c..7d1774bfbe41 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1563,6 +1563,20 @@ intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
txbuf[3] = msg->size - 1;
}
+static u32 intel_dp_aux_xfer_flags(const struct drm_dp_aux_msg *msg)
+{
+ /*
+* If we're trying to send the HDCP Aksv, we need to set a the Aksv
+* select bit to inform the hardware to send the Aksv after our header
+* since we can't access that data from software.
+*/
+ if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_WRITE &&
+ msg->address == DP_AUX_HDCP_AKSV)
+ return DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+
+ return 0;
+}
+
static ssize_t
intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
{
@@ -1570,6 +1584,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 txbuf[20], rxbuf[20];
size_t txsize, rxsize;
+ u32 flags = intel_dp_aux_xfer_flags(msg);
int ret;
intel_dp_aux_header(txbuf, msg);
@@ -1590,7 +1605,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
@@ -1613,7 +1628,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
return -E2BIG;
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -6403,15 +6418,8 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *dig_port,
u8 *an)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- struct intel_dp *intel_dp =
enc_to_intel_dp(to_intel_encoder(&dig_port->base.base));
- static const struct drm_dp_aux_msg msg = {
- .request = DP_AUX_NATIVE_WRITE,
- .address = DP_AUX_HDCP_AKSV,
- .size = DRM_HDCP_KSV_LEN,
- };
- u8 txbuf[HEADER_SIZE + DRM_HDCP_KSV_LEN] = {}, rxbuf[2], reply = 0;
+ u8 aksv[DRM_HDCP_KSV_LEN] = {};
ssize_t dpcd_ret;
- int ret;
/* Output An first, that's easy */
dpcd_ret = drm_dp_dpcd_write(&dig_port->dp.aux, DP_AUX_HDCP_AN,
@@ -6424,31 +6432,19 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *dig_port,
}
/*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So in
-* order to get it on the wire, we need to create the AUX header as if
-*
[Intel-gfx] [PATCH v8 00/17] drm/i915: Add support for HDCP 1.4 over MST
From: Sean Paul Only one functional change, reversed the hdcp_1x/2x_present bits in the QUERY_STREAM_ENCRYPTION_STATUS parsing with a comment explaining my confusion. Other than that, lots of rebasing, the most notable being the s/intel_dig_port/dig_port/ rename. Every patch now has a Reviewed-by tag now, I've done build tests on each patch and tested the set as a whole. Hopefully we can get this landed. Sean Sean Paul (17): drm/i915: Fix sha_text population code drm/i915: Clear the repeater bit on HDCP disable drm/i915: WARN if HDCP signalling is enabled upon disable drm/i915: Intercept Aksv writes in the aux hooks drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling drm/i915: Factor out hdcp->value assignments drm/i915: Protect workers against disappearing connectors drm/i915: Clean up intel_hdcp_disable drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it drm/i915: Support DP MST in enc_to_dig_port() function drm/i915: Use ddi_update_pipe in intel_dp_mst drm/i915: Factor out HDCP shim functions from dp for use by dp_mst drm/i915: Plumb port through hdcp init drm/i915: Add connector to hdcp_shim->check_link() drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message drm/i915: Print HDCP version info for all connectors drm/i915: Add HDCP 1.4 support for MST connectors drivers/gpu/drm/drm_dp_mst_topology.c | 150 drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- drivers/gpu/drm/i915/display/intel_ddi.h | 2 + .../drm/i915/display/intel_display_debugfs.c | 21 +- .../drm/i915/display/intel_display_types.h| 30 +- drivers/gpu/drm/i915/display/intel_dp.c | 646 +--- drivers/gpu/drm/i915/display/intel_dp.h | 9 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 703 ++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 + drivers/gpu/drm/i915/display/intel_hdcp.c | 217 -- drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 30 +- .../drm/selftests/test-drm_dp_mst_helper.c| 17 + include/drm/drm_dp_helper.h | 3 + include/drm/drm_dp_mst_helper.h | 44 ++ include/drm/drm_hdcp.h| 3 + 17 files changed, 1202 insertions(+), 724 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 08/17] drm/i915: Clean up intel_hdcp_disable
From: Sean Paul
Add an out label and un-indent hdcp disable in preparation for
hdcp_mutex. No functional changes
Reviewed-by: Anshuman Gupta
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-9-s...@poorly.run
#v7
Changes in v7:
-Split into separate patch (Ramalingam)
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index fe9377a6e4d5..4de87012659b 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2112,16 +2112,17 @@ int intel_hdcp_disable(struct intel_connector
*connector)
mutex_lock(&hdcp->mutex);
- if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- intel_hdcp_update_value(connector,
- DRM_MODE_CONTENT_PROTECTION_UNDESIRED,
- false);
- if (hdcp->hdcp2_encrypted)
- ret = _intel_hdcp2_disable(connector);
- else if (hdcp->hdcp_encrypted)
- ret = _intel_hdcp_disable(connector);
- }
+ if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ goto out;
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED, false);
+ if (hdcp->hdcp2_encrypted)
+ ret = _intel_hdcp2_disable(connector);
+ else if (hdcp->hdcp_encrypted)
+ ret = _intel_hdcp_disable(connector);
+
+out:
mutex_unlock(&hdcp->mutex);
cancel_delayed_work_sync(&hdcp->check_work);
return ret;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 13/17] drm/i915: Plumb port through hdcp init
From: Sean Paul
This patch plumbs port through hdcp init instead of relying on
intel_attached_encoder() to return a non-NULL encoder which won't work
for MST connectors.
Cc: Ville Syrjälä
Reviewed-by: Anshuman Gupta
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-13-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-13-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-14-s...@poorly.run
#v7
Changes in v5:
-Added to the set
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c| 11 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h| 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +-
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 0b8200bed061..c164ad11e617 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -631,7 +631,8 @@ int intel_dp_init_hdcp(struct intel_digital_port *dig_port,
return 0;
if (!intel_dp_is_edp(intel_dp))
- return intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
+ return intel_hdcp_init(intel_connector, port,
+ &intel_dp_hdcp_shim);
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index dc77db0a8df3..f25cfb7a9565 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1954,6 +1954,7 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder
cpu_transcoder)
}
static int initialize_hdcp_port_data(struct intel_connector *connector,
+enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1961,8 +1962,7 @@ static int initialize_hdcp_port_data(struct
intel_connector *connector,
struct hdcp_port_data *data = &hdcp->port_data;
if (INTEL_GEN(dev_priv) < 12)
- data->fw_ddi =
-
intel_get_mei_fw_ddi_index(intel_attached_encoder(connector)->port);
+ data->fw_ddi = intel_get_mei_fw_ddi_index(port);
else
/*
* As per ME FW API expectation, for GEN 12+, fw_ddi is filled
@@ -2032,14 +2032,14 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
}
}
-static void intel_hdcp2_init(struct intel_connector *connector,
+static void intel_hdcp2_init(struct intel_connector *connector, enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
- ret = initialize_hdcp_port_data(connector, shim);
+ ret = initialize_hdcp_port_data(connector, port, shim);
if (ret) {
drm_dbg_kms(&i915->drm, "Mei hdcp data init failed\n");
return;
@@ -2049,6 +2049,7 @@ static void intel_hdcp2_init(struct intel_connector
*connector,
}
int intel_hdcp_init(struct intel_connector *connector,
+ enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -2059,7 +2060,7 @@ int intel_hdcp_init(struct intel_connector *connector,
return -EINVAL;
if (is_hdcp2_supported(dev_priv))
- intel_hdcp2_init(connector, shim);
+ intel_hdcp2_init(connector, port, shim);
ret =
drm_connector_attach_content_protection_property(&connector->base,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 86bbaec120cc..1bbf5b67ed0a 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -22,7 +22,7 @@ enum transcoder;
void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
-int intel_hdcp_init(struct intel_connector *connector,
+int intel_hdcp_init(struct intel_connector *connector, enum port port,
const struct intel_hdcp_shim *hdcp_shim);
int intel_hdcp_enable(struct intel_connector *connector,
enum transcoder cpu_transcoder, u8 content_type);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 9c3b1ae2cd2b..c0ea16dae3b3 100644
--- a/drivers/gpu/drm/i915/
[Intel-gfx] [PATCH v8 09/17] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.
In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.
Cc: Ramalingam C
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-9-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-10-s...@poorly.run
#v7
Changes in v2:
-Move the toggle_signalling call into _intel_hdcp_disable so it's called from
check_work
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-Split minor intel_hdcp_disable refactor into separate patch (Ramalingam)
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 ++
.../drm/i915/display/intel_display_types.h| 5 +++
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 33 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 ++
5 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 2feec47a48e0..a1643588b5f9 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4996,6 +4996,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
drm_encoder_init(&dev_priv->drm, &encoder->base, &intel_ddi_funcs,
DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
+ mutex_init(&dig_port->hdcp_mutex);
+ dig_port->num_hdcp_streams = 0;
+
encoder->hotplug = intel_ddi_hotplug;
encoder->compute_output_type = intel_ddi_compute_output_type;
encoder->compute_config = intel_ddi_compute_config;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d30ec7728a99..b6d0ad171432 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1416,6 +1416,11 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
+ /* protects num_hdcp_streams reference count */
+ struct mutex hdcp_mutex;
+ /* the number of pipes using HDCP signalling out of this port */
+ unsigned int num_hdcp_streams;
+
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index adef7b508ff5..b54577a04ccf 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -8285,6 +8285,8 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder = &dig_port->base;
encoder = &intel_encoder->base;
+ mutex_init(&dig_port->hdcp_mutex);
+
if (drm_encoder_init(&dev_priv->drm, &intel_encoder->base,
&intel_dp_enc_funcs, DRM_MODE_ENCODER_TMDS,
"DP %c", port_name(port)))
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 4de87012659b..dc77db0a8df3 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -801,6 +801,19 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ /*
+* If there are other connectors on this port using HDCP, don't disable
+* it. Instead, toggle the HDCP signalling off on that particular
+* connector/pipe and exit.
+*/
+ if (dig_port->num_hdcp_streams > 0) {
+ ret = hdcp->shim->toggle_signalling(dig_port,
+ cpu_transcoder, false);
+ if (ret)
+ DRM_ERROR("Failed to disable HDCP signalling\n");
+ retur
[Intel-gfx] [PATCH v8 07/17] drm/i915: Protect workers against disappearing connectors
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't do a synchronous wait since it needs
to take connection_mutex which could cause deadlock. Instead, we'll take
a reference on the connector when scheduling prop_work and give it up
once we're done.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-8-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-8-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-8-s...@poorly.run
#v7
Changes in v2:
-Added to the set
Changes in v3:
-Change the WARN_ON condition in intel_hdcp_cleanup to allow for
initializing connectors as well
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 44 ---
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index ab2e2f9d0020..fe9377a6e4d5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -887,8 +887,10 @@ static void intel_hdcp_update_value(struct intel_connector
*connector,
return;
hdcp->value = value;
- if (update_property)
+ if (update_property) {
+ drm_connector_get(&connector->base);
schedule_work(&hdcp->prop_work);
+ }
}
/* Implements Part 3 of the HDCP authorization procedure */
@@ -980,6 +982,8 @@ static void intel_hdcp_prop_work(struct work_struct *work)
mutex_unlock(&hdcp->mutex);
drm_modeset_unlock(&dev_priv->drm.mode_config.connection_mutex);
+
+ drm_connector_put(&connector->base);
}
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
@@ -1859,6 +1863,9 @@ static void intel_hdcp_check_work(struct work_struct
*work)
check_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
+ if (drm_connector_is_unregistered(&connector->base))
+ return;
+
if (!intel_hdcp2_check_link(connector))
schedule_delayed_work(&hdcp->check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
@@ -2185,12 +2192,39 @@ void intel_hdcp_component_fini(struct drm_i915_private
*dev_priv)
void intel_hdcp_cleanup(struct intel_connector *connector)
{
- if (!connector->hdcp.shim)
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ if (!hdcp->shim)
return;
- mutex_lock(&connector->hdcp.mutex);
- kfree(connector->hdcp.port_data.streams);
- mutex_unlock(&connector->hdcp.mutex);
+ /*
+* If the connector is registered, it's possible userspace could kick
+* off another HDCP enable, which would re-spawn the workers.
+*/
+ drm_WARN_ON(connector->base.dev,
+ connector->base.registration_state == DRM_CONNECTOR_REGISTERED);
+
+ /*
+* Now that the connector is not registered, check_work won't be run,
+* but cancel any outstanding instances of it
+*/
+ cancel_delayed_work_sync(&hdcp->check_work);
+
+ /*
+* We don't cancel prop_work in the same way as check_work since it
+* requires connection_mutex which could be held while calling this
+* function. Instead, we rely on the connector references grabbed before
+* scheduling prop_work to ensure the connector is alive when prop_work
+* is run. So if we're in the destroy path (which is where this
+* function should be called), we're "guaranteed" that prop_work is not
+* active (tl;dr This Should Never Happen).
+*/
+ drm_WARN_ON(connector->base.dev, work_pending(&hdcp->prop_work));
+
+ mutex_lock(&hdcp->mutex);
+ kfree(hdcp->port_data.streams);
+ hdcp->shim = NULL;
+ mutex_unlock(&hdcp->mutex);
}
void intel_hdcp_atomic_check(struct drm_connector *connector,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 10/17] drm/i915: Support DP MST in enc_to_dig_port() function
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-10-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-10-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-10-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-10-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-10-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-11-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
.../drm/i915/display/intel_display_types.h| 21 ---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b6d0ad171432..5e01f2f840c9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1531,6 +1531,18 @@ static inline bool intel_encoder_is_dig_port(struct
intel_encoder *encoder)
}
}
+static inline bool intel_encoder_is_mst(struct intel_encoder *encoder)
+{
+ return encoder->type == INTEL_OUTPUT_DP_MST;
+}
+
+static inline struct intel_dp_mst_encoder *
+enc_to_mst(struct intel_encoder *encoder)
+{
+ return container_of(&encoder->base, struct intel_dp_mst_encoder,
+ base.base);
+}
+
static inline struct intel_digital_port *
enc_to_dig_port(struct intel_encoder *encoder)
{
@@ -1539,6 +1551,8 @@ enc_to_dig_port(struct intel_encoder *encoder)
if (intel_encoder_is_dig_port(intel_encoder))
return container_of(&encoder->base, struct intel_digital_port,
base.base);
+ else if (intel_encoder_is_mst(intel_encoder))
+ return enc_to_mst(encoder)->primary;
else
return NULL;
}
@@ -1549,13 +1563,6 @@ intel_attached_dig_port(struct intel_connector
*connector)
return enc_to_dig_port(intel_attached_encoder(connector));
}
-static inline struct intel_dp_mst_encoder *
-enc_to_mst(struct intel_encoder *encoder)
-{
- return container_of(&encoder->base, struct intel_dp_mst_encoder,
- base.base);
-}
-
static inline struct intel_dp *enc_to_intel_dp(struct intel_encoder *encoder)
{
return &enc_to_dig_port(encoder)->dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 11/17] drm/i915: Use ddi_update_pipe in intel_dp_mst
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-11-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-11-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-11-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-11-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-11-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-12-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c| 11 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 6 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a1643588b5f9..36022281d7e0 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4012,13 +4012,14 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
intel_panel_update_backlight(state, encoder, crtc_state, conn_state);
}
-static void intel_ddi_update_pipe(struct intel_atomic_state *state,
- struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
+void intel_ddi_update_pipe(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
- if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+ !intel_encoder_is_mst(encoder))
intel_ddi_update_pipe_dp(state, encoder, crtc_state,
conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index b901ab850cbd..d13b45151a3f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -17,6 +17,7 @@ struct drm_encoder;
struct drm_i915_private;
struct drm_modeset_acquire_ctx;
struct drm_dp_vsc_sdp;
+struct intel_atomic_state;
struct intel_connector;
struct intel_crtc_state;
struct intel_digital_port;
@@ -128,4 +129,9 @@ static inline unsigned int intel_dp_unused_lane_mask(int
lane_count)
u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
+void intel_ddi_update_pipe(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state);
+
#endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index a2d91a499700..b97b2918d802 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -865,6 +865,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
*dig_port, enum pipe
intel_encoder->compute_config_late = intel_dp_mst_compute_config_late;
intel_encoder->disable = intel_mst_disable_dp;
intel_encoder->post_disable = intel_mst_post_disable_dp;
+ intel_encoder->update_pipe = intel_ddi_update_pipe;
intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
intel_encoder->pre_enable = intel_mst_pre_enable_dp;
intel_encoder->enable = intel_mst_enable_dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 05/17] drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-6-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-6-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-6-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-6-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-6-s...@poorly.run
#v7
Changes in v2:
-Added to the set
Changes in v3:
-s/hdcp/hdmi/ in commit msg (Ram)
Changes in v4:
-Rebased on intel_de_(read|write) change
Changes in v5:
-Update hdcp->cpu_transcoder in intel_hdcp_enable so it works with pipe != 0
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c | 13 +++--
drivers/gpu/drm/i915/display/intel_ddi.h | 2 ++
.../gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.c| 15 ---
drivers/gpu/drm/i915/display/intel_hdmi.c| 16 +++-
6 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index b02cd36647d6..2feec47a48e0 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1820,12 +1820,12 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable)
{
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
intel_wakeref_t wakeref;
- enum pipe pipe = 0;
int ret = 0;
u32 tmp;
@@ -1834,19 +1834,12 @@ int intel_ddi_toggle_hdcp_signalling(struct
intel_encoder *intel_encoder,
if (drm_WARN_ON(dev, !wakeref))
return -ENXIO;
- if (drm_WARN_ON(dev,
- !intel_encoder->get_hw_state(intel_encoder, &pipe))) {
- ret = -EIO;
- goto out;
- }
-
- tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(pipe));
+ tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
tmp |= TRANS_DDI_HDCP_SIGNALLING;
else
tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
- intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe), tmp);
-out:
+ intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
}
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index 077e9dbbe367..f5fb62fc9400 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -16,6 +16,7 @@ struct intel_crtc_state;
struct intel_dp;
struct intel_dpll_hw_state;
struct intel_encoder;
+enum transcoder;
void intel_ddi_fdi_post_disable(struct intel_atomic_state *state,
struct intel_encoder *intel_encoder,
@@ -43,6 +44,7 @@ void intel_ddi_compute_min_voltage_level(struct
drm_i915_private *dev_priv,
u32 bxt_signal_levels(struct intel_dp *intel_dp);
u32 ddi_signal_levels(struct intel_dp *intel_dp);
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9349b15afff6..d30ec7728a99 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -314,6 +314,7 @@ struct intel_hdcp_shim {
/* Enables HDCP signalling on the port */
int (*toggle_signalling)(struct intel_digital_port *dig_port,
+enum transcoder cpu_transcoder,
bool enable);
/* Ensures the link is still protected */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7d1774bfbe41..adef7b508ff5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp
[Intel-gfx] [PATCH v8 06/17] drm/i915: Factor out hdcp->value assignments
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-7-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-7-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-7-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-7-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-7-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-7-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-7-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on top of drm_* logging changes
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 67 ---
1 file changed, 46 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index b28a351f3a98..ab2e2f9d0020 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -876,6 +876,21 @@ static struct intel_connector
*intel_hdcp_to_connector(struct intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
}
+static void intel_hdcp_update_value(struct intel_connector *connector,
+ u64 value, bool update_property)
+{
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ drm_WARN_ON(connector->base.dev, !mutex_is_locked(&hdcp->mutex));
+
+ if (hdcp->value == value)
+ return;
+
+ hdcp->value = value;
+ if (update_property)
+ schedule_work(&hdcp->prop_work);
+}
+
/* Implements Part 3 of the HDCP authorization procedure */
static int intel_hdcp_check_link(struct intel_connector *connector)
{
@@ -903,15 +918,16 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
connector->base.name, connector->base.base.id,
intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
if (hdcp->shim->check_link(dig_port)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
}
goto out;
}
@@ -923,16 +939,18 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
ret = _intel_hdcp_disable(connector);
if (ret) {
drm_err(&dev_priv->drm, "Failed to disable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = _intel_hdcp_enable(connector);
if (ret) {
drm_err(&dev_priv->drm, "Failed to enable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
@@ -1768,16 +1786,18 @@ static int intel_hdcp2_check_link(struct
intel_connector *connector)
"HDCP2.2 link stopped the encryption, %x\n",
intel_de_read(dev_priv, HDCP2_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = hdcp->shim->check_2
[Intel-gfx] [PATCH v8 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Cc: Lyude Paul
Reviewed-by: Anshuman Gupta
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-16-s...@poorly.run
#v7
Changes in v4:
-Added to the set
Changes in v5:
-None
Changes in v6:
-Use FIELD_PREP to generate request buffer bitfields (Lyude)
-Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
Changes in v7:
-None
Changes in v8:
-Reverse the parsing on the hdcp_*x_device_present bits and leave
breadcrumb in case this is incorrect (Anshuman)
---
drivers/gpu/drm/drm_dp_mst_topology.c | 150 ++
.../drm/selftests/test-drm_dp_mst_helper.c| 17 ++
include/drm/drm_dp_helper.h | 3 +
include/drm/drm_dp_mst_helper.h | 44 +
4 files changed, 214 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 67dd72ea200e..f2b77ef40281 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -20,11 +20,13 @@
* OF THIS SOFTWARE.
*/
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -423,6 +425,22 @@ drm_dp_encode_sideband_req(const struct
drm_dp_sideband_msg_req_body *req,
memcpy(&buf[idx], req->u.i2c_write.bytes,
req->u.i2c_write.num_bytes);
idx += req->u.i2c_write.num_bytes;
break;
+ case DP_QUERY_STREAM_ENC_STATUS: {
+ const struct drm_dp_query_stream_enc_status *msg;
+
+ msg = &req->u.enc_status;
+ buf[idx] = msg->stream_id;
+ idx++;
+ memcpy(&buf[idx], msg->client_id, sizeof(msg->client_id));
+ idx += sizeof(msg->client_id);
+ buf[idx] = 0;
+ buf[idx] |= FIELD_PREP(GENMASK(1, 0), msg->stream_event);
+ buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
+ buf[idx] |= FIELD_PREP(GENMASK(4, 3), msg->stream_behavior);
+ buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
+ idx++;
+ }
+ break;
}
raw->cur_len = idx;
}
@@ -551,6 +569,20 @@ drm_dp_decode_sideband_req(const struct
drm_dp_sideband_msg_tx *raw,
return -ENOMEM;
}
break;
+ case DP_QUERY_STREAM_ENC_STATUS:
+ req->u.enc_status.stream_id = buf[idx++];
+ for (i = 0; i < sizeof(req->u.enc_status.client_id); i++)
+ req->u.enc_status.client_id[i] = buf[idx++];
+
+ req->u.enc_status.stream_event = FIELD_GET(GENMASK(1, 0),
+ buf[idx]);
+ req->u.enc_status.valid_stream_event = FIELD_GET(BIT(2),
+buf[idx]);
+ req->u.enc_status.stream_behavior = FIELD_GET(GENMASK(4, 3),
+ buf[idx]);
+ req->u.enc_status.valid_stream_behavior = FIELD_GET(BIT(5),
+ buf[idx]);
+ break;
}
return 0;
@@ -629,6 +661,16 @@ drm_dp_dump_sideband_msg_req_body(const struct
drm_dp_sideband_msg_req_body *req
req->u.i2c_write.num_bytes, req->u.i2c_write.num_bytes,
req->u.i2c_write.bytes);
break;
+ case DP_QUERY_STREAM_ENC_STATUS:
+ P("stream_id=%u client_id=%*ph stream_event=%x "
+ "valid_event=%d stream_behavior=%x valid_behavior=%d",
+ req->u.enc_status.stream_id,
+ (int)ARRAY_SIZE(req->u.enc_status.client_id),
+ req->u.enc_status.client_id, req->u.enc_status.stream_event,
+ req->u.enc_status.valid_stream_event,
+ req->u.enc_status.stream_behavior,
+ req->u.enc_status.valid_stream_behavior);
+ break;
default:
P("???\n");
break;
@@ -936,6 +978,42 @@ static bool
drm_dp_sideband_parse_power_updown_phy_ack(struct drm_dp_sideband_ms
return true;
}
+static bool
+drm_dp_sideband_parse_query_stream_enc_status(
+ struct drm_dp_sideband_msg_rx *raw,
+ struct drm_dp_sideband_msg_reply_body *repmsg)
+{
+ struct drm_dp_query_stream_enc_status_ack_reply *reply;
+
+ reply = &repmsg->u.enc_status;
+
+ reply->stream_id = raw->ms
[Intel-gfx] [PATCH v8 12/17] drm/i915: Factor out HDCP shim functions from dp for use by dp_mst
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-12-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-12-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-12-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-12-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-12-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-13-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-Created intel_dp_hdcp.c for the shared functions to live (Ville)
Changes in v4:
-Rebased on new drm logging change
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-Rebased patch
Changes in v8:
-None
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 607 +-
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 637 +++
4 files changed, 642 insertions(+), 606 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index bda4c0e408f8..e5574e506a5c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -234,6 +234,7 @@ i915-y += \
display/intel_ddi.o \
display/intel_dp.o \
display/intel_dp_aux_backlight.o \
+ display/intel_dp_hdcp.o \
display/intel_dp_link_training.o \
display/intel_dp_mst.o \
display/intel_dsi.o \
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b54577a04ccf..41d76df7423e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include "i915_debugfs.h"
@@ -6401,610 +6400,6 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
edp_panel_vdd_off_sync(intel_dp);
}
-static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp, int timeout)
-{
- long ret;
-
-#define C (hdcp->cp_irq_count_cached != atomic_read(&hdcp->cp_irq_count))
- ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
- msecs_to_jiffies(timeout));
-
- if (!ret)
- DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
-}
-
-static
-int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *dig_port,
- u8 *an)
-{
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- u8 aksv[DRM_HDCP_KSV_LEN] = {};
- ssize_t dpcd_ret;
-
- /* Output An first, that's easy */
- dpcd_ret = drm_dp_dpcd_write(&dig_port->dp.aux, DP_AUX_HDCP_AN,
-an, DRM_HDCP_AN_LEN);
- if (dpcd_ret != DRM_HDCP_AN_LEN) {
- drm_dbg_kms(&i915->drm,
- "Failed to write An over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
-
- /*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So we
-* send an empty buffer of the correct length through the DP helpers. On
-* the other side, in the transfer hook, we'll generate a flag based on
-* the destination address which will tickle the hardware to output the
-* Aksv on our behalf after the header is sent.
-*/
- dpcd_ret = drm_dp_dpcd_write(&dig_port->dp.aux, DP_AUX_HDCP_AKSV,
-aksv, DRM_HDCP_KSV_LEN);
- if (dpcd_ret != DRM_HDCP_KSV_LEN) {
- drm_dbg_kms(&i915->drm,
- "Failed to write Aksv over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bksv(struct intel_digital_port *dig_port,
- u8 *bksv)
-{
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- ssize_t ret;
-
- ret = drm_dp_dpcd_read(&dig_port->dp.aux, DP_AUX_HDCP_BKSV, bksv,
- DRM_HDCP_KSV_LEN);
- if (ret != DRM_HDCP_KSV_LEN) {
- drm_dbg_kms(&i915->drm,
- "Read Bksv from DP/AUX failed (%zd)\n", ret);
- return ret >= 0 ? -EIO : ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bstatus(struct intel_digita
[Intel-gfx] [PATCH v8 14/17] drm/i915: Add connector to hdcp_shim->check_link()
From: Sean Paul
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
Reviewed-by: Anshuman Gupta
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-14-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-15-s...@poorly.run
#v7
Changes in v4:
-Added to the set
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +-
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e01f2f840c9..413b60337a0b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -318,7 +318,8 @@ struct intel_hdcp_shim {
bool enable);
/* Ensures the link is still protected */
- bool (*check_link)(struct intel_digital_port *dig_port);
+ bool (*check_link)(struct intel_digital_port *dig_port,
+ struct intel_connector *connector);
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *dig_port,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index c164ad11e617..b744253a5924 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -224,7 +224,8 @@ int intel_dp_hdcp_toggle_signalling(struct
intel_digital_port *dig_port,
}
static
-bool intel_dp_hdcp_check_link(struct intel_digital_port *dig_port)
+bool intel_dp_hdcp_check_link(struct intel_digital_port *dig_port,
+ struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
ssize_t ret;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index f25cfb7a9565..028cf3ac548f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -952,7 +952,7 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
goto out;
}
- if (hdcp->shim->check_link(dig_port)) {
+ if (hdcp->shim->check_link(dig_port, connector)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
intel_hdcp_update_value(connector,
DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index c0ea16dae3b3..0978b0d8f4c6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1546,11 +1546,10 @@ int intel_hdmi_hdcp_toggle_signalling(struct
intel_digital_port *dig_port,
}
static
-bool intel_hdmi_hdcp_check_link_once(struct intel_digital_port *dig_port)
+bool intel_hdmi_hdcp_check_link_once(struct intel_digital_port *dig_port,
+struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- struct intel_connector *connector =
- dig_port->hdmi.attached_connector;
enum port port = dig_port->base.port;
enum transcoder cpu_transcoder = connector->hdcp.cpu_transcoder;
int ret;
@@ -1578,13 +1577,14 @@ bool intel_hdmi_hdcp_check_link_once(struct
intel_digital_port *dig_port)
}
static
-bool intel_hdmi_hdcp_check_link(struct intel_digital_port *dig_port)
+bool intel_hdmi_hdcp_check_link(struct intel_digital_port *dig_port,
+ struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
int retry;
for (retry = 0; retry < 3; retry++)
- if (intel_hdmi_hdcp_check_link_once(dig_port))
+ if (intel_hdmi_hdcp_check_link_once(dig_port, connector))
return true;
drm_err(&i915->drm, "Link check failed\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskt
[Intel-gfx] [PATCH v8 16/17] drm/i915: Print HDCP version info for all connectors
From: Sean Paul
De-duplicate the HDCP version code for each connector and print it for
all connectors.
Cc: Juston Li
Cc: Ramalingam C
Reviewed-by: Juston Li
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200227185714.171466-1-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-16-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-16-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-17-s...@poorly.run
#v7
Changes in v4:
- Added to the set
Changes in v5:
-Print "No connector support" for hdcp sink capability as well (Ram)
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
.../drm/i915/display/intel_display_debugfs.c | 21 ---
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index f549381048b3..58c26a5afc49 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -601,6 +601,11 @@ static void intel_hdcp_info(struct seq_file *m,
{
bool hdcp_cap, hdcp2_cap;
+ if (!intel_connector->hdcp.shim) {
+ seq_puts(m, "No Connector Support");
+ goto out;
+ }
+
hdcp_cap = intel_hdcp_capable(intel_connector);
hdcp2_cap = intel_hdcp2_capable(intel_connector);
@@ -612,6 +617,7 @@ static void intel_hdcp_info(struct seq_file *m,
if (!hdcp_cap && !hdcp2_cap)
seq_puts(m, "None");
+out:
seq_puts(m, "\n");
}
@@ -628,10 +634,6 @@ static void intel_dp_info(struct seq_file *m,
drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp->downstream_ports,
&intel_dp->aux);
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_dp_mst_info(struct seq_file *m,
@@ -649,10 +651,6 @@ static void intel_hdmi_info(struct seq_file *m,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(intel_encoder);
seq_printf(m, "\taudio support: %s\n", yesno(intel_hdmi->has_audio));
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_lvds_info(struct seq_file *m,
@@ -708,6 +706,9 @@ static void intel_connector_info(struct seq_file *m,
break;
}
+ seq_puts(m, "\tHDCP version: ");
+ intel_hdcp_info(m, intel_connector);
+
seq_printf(m, "\tmodes:\n");
list_for_each_entry(mode, &connector->modes, head)
intel_seq_print_mode(m, 2, mode);
@@ -2029,10 +2030,6 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
if (connector->status != connector_status_connected)
return -ENODEV;
- /* HDCP is supported by connector */
- if (!intel_connector->hdcp.shim)
- return -EINVAL;
-
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
intel_hdcp_info(m, intel_connector);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 17/17] drm/i915: Add HDCP 1.4 support for MST connectors
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Cc: Juston Li
Reviewed-by: Anshuman Gupta
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-18-s...@poorly.run
#v7
Changes in v2:
-Toggle HDCP from encoder disable/enable
-Don't disable HDCP on MST connector destroy, leave that for encoder
disable, just ensure the check_work routine isn't running any longer
Changes in v3:
-Place the shim in the new intel_dp_hdcp.c file (Ville)
Changes in v4:
-Actually use the mst shim for mst connections (Juston)
-Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
Changes in v5:
-Add sleep on disable signalling to match hdmi delay
Changes in v6:
-Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
don't have hardware to test it
Changes in v7:
-Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam)
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 66 +++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 ++
drivers/gpu/drm/i915/display/intel_hdcp.c| 2 +-
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index b744253a5924..03424d20e9f7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -7,10 +7,12 @@
*/
#include
+#include
#include
#include
#include "intel_display_types.h"
+#include "intel_ddi.h"
#include "intel_dp.h"
#include "intel_hdcp.h"
@@ -619,6 +621,65 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.protocol = HDCP_PROTOCOL_DP,
};
+static int
+intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port *dig_port,
+ enum transcoder cpu_transcoder,
+ bool enable)
+{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ int ret;
+
+ if (!enable)
+ usleep_range(6, 60); /* Bspec says >= 6us */
+
+ ret = intel_ddi_toggle_hdcp_signalling(&dig_port->base,
+ cpu_transcoder, enable);
+ if (ret)
+ drm_dbg_kms(&i915->drm, "%s HDCP signalling failed (%d)\n",
+ enable ? "Enable" : "Disable", ret);
+ return ret;
+}
+
+static
+bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
+ struct intel_connector *connector)
+{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ struct intel_dp *intel_dp = &dig_port->dp;
+ struct drm_dp_query_stream_enc_status_ack_reply reply;
+ int ret;
+
+ if (!intel_dp_hdcp_check_link(dig_port, connector))
+ return false;
+
+ ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
+ connector->port, &reply);
+ if (ret) {
+ drm_dbg_kms(&i915->drm,
+ "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
+ connector->base.base.id, connector->base.name, ret);
+ return false;
+ }
+
+ return reply.auth_completed && reply.encryption_enabled;
+}
+
+static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
+ .write_an_aksv = intel_dp_hdcp_write_an_aksv,
+ .read_bksv = intel_dp_hdcp_read_bksv,
+ .read_bstatus = intel_dp_hdcp_read_bstatus,
+ .repeater_present = intel_dp_hdcp_repeater_present,
+ .read_ri_prime = intel_dp_hdcp_read_ri_prime,
+ .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
+ .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
+ .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
+ .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
+ .check_link = intel_dp_mst_hdcp_check_link,
+ .hdcp_capable = intel_dp_hdcp_capable,
+
+ .protocol = HDCP_PROTOCOL_DP,
+};
+
int intel_dp_init_hdcp(struct intel_digital_port *dig_port,
struct intel_connector *intel_connector)
{
@@ -631,7 +692,10 @@ int intel_dp_init_hdcp(str
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add support for HDCP 1.4 over MST (rev2)
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST (rev2)
URL : https://patchwork.freedesktop.org/series/78749/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ad446f228d24 drm/i915: Fix sha_text population code
-:72: WARNING:LINE_SPACING: Missing a blank line after declarations
#72: FILE: drivers/gpu/drm/i915/display/intel_hdcp.c:341:
+ u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) *
8);
+ sha_text |= ksv[j] << off;
total: 0 errors, 1 warnings, 0 checks, 61 lines checked
be78fd1d52cb drm/i915: Clear the repeater bit on HDCP disable
96f56301c229 drm/i915: WARN if HDCP signalling is enabled upon disable
2a9f21eb9c09 drm/i915: Intercept Aksv writes in the aux hooks
1a56bdc02def drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP
signalling
8d6b5fe7b16e drm/i915: Factor out hdcp->value assignments
-:78: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#78: FILE: drivers/gpu/drm/i915/display/intel_hdcp.c:930:
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
-:123: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#123: FILE: drivers/gpu/drm/i915/display/intel_hdcp.c:1799:
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED,
-:135: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#135: FILE: drivers/gpu/drm/i915/display/intel_hdcp.c:1814:
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED,
-:147: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#147: FILE: drivers/gpu/drm/i915/display/intel_hdcp.c:1834:
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED, true);
total: 0 errors, 0 warnings, 4 checks, 138 lines checked
d8b168bd5d5a drm/i915: Protect workers against disappearing connectors
-:95: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#95: FILE: drivers/gpu/drm/i915/display/intel_hdcp.c:2205:
+ drm_WARN_ON(connector->base.dev,
+ connector->base.registration_state == DRM_CONNECTOR_REGISTERED);
total: 0 errors, 0 warnings, 1 checks, 71 lines checked
5390eda47a58 drm/i915: Clean up intel_hdcp_disable
a82bad65d0b2 drm/i915: Don't fully disable HDCP on a port if multiple pipes are
using it
f155946735e0 drm/i915: Support DP MST in enc_to_dig_port() function
260f90f909b5 drm/i915: Use ddi_update_pipe in intel_dp_mst
8b7aea4234cf drm/i915: Factor out HDCP shim functions from dp for use by dp_mst
-:692: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#692:
new file mode 100644
-:697: WARNING:SPDX_LICENSE_TAG: Improper SPDX comment style for
'drivers/gpu/drm/i915/display/intel_dp_hdcp.c', please use '//' instead
#697: FILE: drivers/gpu/drm/i915/display/intel_dp_hdcp.c:1:
+/* SPDX-License-Identifier: MIT */
-:697: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#697: FILE: drivers/gpu/drm/i915/display/intel_dp_hdcp.c:1:
+/* SPDX-License-Identifier: MIT */
-:878: WARNING:LINE_SPACING: Missing a blank line after declarations
#878: FILE: drivers/gpu/drm/i915/display/intel_dp_hdcp.c:182:
+ size_t len = min(num_downstream - i, 3) * DRM_HDCP_KSV_LEN;
+ ret = drm_dp_dpcd_read(&dig_port->dp.aux,
-:1254: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#1254: FILE: drivers/gpu/drm/i915/display/intel_dp_hdcp.c:558:
+
+}
total: 0 errors, 4 warnings, 1 checks, 1276 lines checked
8379b02b9940 drm/i915: Plumb port through hdcp init
bbb5610468ab drm/i915: Add connector to hdcp_shim->check_link()
f4915cd92791 drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST
sideband message
-:115: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#115: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:982:
+drm_dp_sideband_parse_query_stream_enc_status(
-:193: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#193: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:3256:
+int drm_dp_send_query_stream_enc_status(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port,
-:373: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#373: FILE: include/drm/drm_dp_mst_helper.h:853:
+int drm_dp_send_query_stream_enc_status(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port,
total: 0 errors, 0 warnings, 3 checks, 315 lines checked
f589de4d6946 drm/i915: Print HDCP version info for all connectors
3a5e18d9ce36 drm/i915: Add HDCP 1.4 support for MST connectors
-:76: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#76: FILE: drivers/gpu/drm/i915/display/intel_dp_hdcp.c:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Add support for HDCP 1.4 over MST (rev2)
== Series Details == Series: drm/i915: Add support for HDCP 1.4 over MST (rev2) URL : https://patchwork.freedesktop.org/series/78749/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:expected unsigned int [addressable] [usertype] ulClockParams +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:got restricted __le32 [usertype] +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many warnings +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:598:21: warning: cast to restr
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add support for HDCP 1.4 over MST (rev2)
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST (rev2)
URL : https://patchwork.freedesktop.org/series/78749/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8898 -> Patchwork_18368
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18368:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@debugfs_test@read_all_entries:
- {fi-kbl-7560u}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/fi-kbl-7560u/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/fi-kbl-7560u/igt@debugfs_test@read_all_entries.html
Known issues
Here are the changes found in Patchwork_18368 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_parallel@engines@contexts:
- fi-tgl-u2: [PASS][3] -> [INCOMPLETE][4] ([CI#80])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/fi-tgl-u2/igt@gem_exec_parallel@engi...@contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/fi-tgl-u2/igt@gem_exec_parallel@engi...@contexts.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- fi-icl-y: [PASS][7] -> [INCOMPLETE][8] ([i915#2276])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/fi-icl-y/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/fi-icl-y/igt@i915_selftest@l...@execlists.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-bxt-dsi: [DMESG-WARN][9] ([i915#1635] / [i915#1982]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/fi-bxt-dsi/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/fi-bxt-dsi/igt@i915_pm_...@module-reload.html
Warnings
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) ->
[DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92]) +2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2276]: https://gitlab.freedesktop.org/drm/intel/issues/2276
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (39 -> 34)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper
Build changes
-
* Linux: CI_DRM_8898 -> Patchwork_18368
CI-20190529: 20190529
CI_DRM_8898: 7a3c826e246d18af05f662cf6425e750eb00aec5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5769: 4e5f76be680b65780204668e302026cf638decc9 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18368: 3a5e18d9ce3659322d1b3623d8641463ce454851 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3a5e18d9ce36 drm/i915: Add HDCP 1.4 support for MST connectors
f589de4d6946 drm/i915: Print HDCP version info for all connectors
f4915cd92791 drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST
sideband message
bbb5610468ab drm/i915: Add connector to hdcp_shim->check_link()
8379b02b9940 dr
Re: [Intel-gfx] [PATCH] char: ipmi: convert tasklets to use new tasklet_setup() API
> >
> > Signed-off-by: Romain Perier
> > Signed-off-by: Allen Pais
>
> This looks good to me.
>
> Reviewed-by: Corey Minyard
>
> Are you planning to push this, or do you want me to take it? If you
> want me to take it, what is the urgency?
Thanks. Well, not hurry, as long as it goes into 5.9 with all other
changes.
>
> -corey
>
> > ---
> > drivers/char/ipmi/ipmi_msghandler.c | 13 ++---
> > 1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/char/ipmi/ipmi_msghandler.c
> > b/drivers/char/ipmi/ipmi_msghandler.c
> > index 737c0b6b24ea..e1814b6a1225 100644
> > --- a/drivers/char/ipmi/ipmi_msghandler.c
> > +++ b/drivers/char/ipmi/ipmi_msghandler.c
> > @@ -39,7 +39,7 @@
> >
> > static struct ipmi_recv_msg *ipmi_alloc_recv_msg(void);
> > static int ipmi_init_msghandler(void);
> > -static void smi_recv_tasklet(unsigned long);
> > +static void smi_recv_tasklet(struct tasklet_struct *t);
> > static void handle_new_recv_msgs(struct ipmi_smi *intf);
> > static void need_waiter(struct ipmi_smi *intf);
> > static int handle_one_recv_msg(struct ipmi_smi *intf,
> > @@ -3430,9 +3430,8 @@ int ipmi_add_smi(struct module *owner,
> > intf->curr_seq = 0;
> > spin_lock_init(&intf->waiting_rcv_msgs_lock);
> > INIT_LIST_HEAD(&intf->waiting_rcv_msgs);
> > - tasklet_init(&intf->recv_tasklet,
> > - smi_recv_tasklet,
> > - (unsigned long) intf);
> > + tasklet_setup(&intf->recv_tasklet,
> > + smi_recv_tasklet);
> > atomic_set(&intf->watchdog_pretimeouts_to_deliver, 0);
> > spin_lock_init(&intf->xmit_msgs_lock);
> > INIT_LIST_HEAD(&intf->xmit_msgs);
> > @@ -4467,10 +4466,10 @@ static void handle_new_recv_msgs(struct ipmi_smi
> > *intf)
> > }
> > }
> >
> > -static void smi_recv_tasklet(unsigned long val)
> > +static void smi_recv_tasklet(struct tasklet_struct *t)
> > {
> > unsigned long flags = 0; /* keep us warning-free. */
> > - struct ipmi_smi *intf = (struct ipmi_smi *) val;
> > + struct ipmi_smi *intf = from_tasklet(intf, t, recv_tasklet);
> > int run_to_completion = intf->run_to_completion;
> > struct ipmi_smi_msg *newmsg = NULL;
> >
> > @@ -4542,7 +4541,7 @@ void ipmi_smi_msg_received(struct ipmi_smi *intf,
> > spin_unlock_irqrestore(&intf->xmit_msgs_lock, flags);
> >
> > if (run_to_completion)
> > - smi_recv_tasklet((unsigned long) intf);
> > + smi_recv_tasklet(&intf->recv_tasklet);
> > else
> > tasklet_schedule(&intf->recv_tasklet);
> > }
> > --
> > 2.17.1
> >
--
- Allen
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] char: ipmi: convert tasklets to use new tasklet_setup() API
On Tue, Aug 18, 2020 at 02:46:23PM +0530, Allen wrote:
> > >
> > > Signed-off-by: Romain Perier
> > > Signed-off-by: Allen Pais
> >
> > This looks good to me.
> >
> > Reviewed-by: Corey Minyard
> >
> > Are you planning to push this, or do you want me to take it? If you
> > want me to take it, what is the urgency?
>
> Thanks. Well, not hurry, as long as it goes into 5.9 with all other
> changes.
Ok, this is queued in my for-next branch.
-corey
>
>
> >
> > -corey
> >
> > > ---
> > > drivers/char/ipmi/ipmi_msghandler.c | 13 ++---
> > > 1 file changed, 6 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/char/ipmi/ipmi_msghandler.c
> > > b/drivers/char/ipmi/ipmi_msghandler.c
> > > index 737c0b6b24ea..e1814b6a1225 100644
> > > --- a/drivers/char/ipmi/ipmi_msghandler.c
> > > +++ b/drivers/char/ipmi/ipmi_msghandler.c
> > > @@ -39,7 +39,7 @@
> > >
> > > static struct ipmi_recv_msg *ipmi_alloc_recv_msg(void);
> > > static int ipmi_init_msghandler(void);
> > > -static void smi_recv_tasklet(unsigned long);
> > > +static void smi_recv_tasklet(struct tasklet_struct *t);
> > > static void handle_new_recv_msgs(struct ipmi_smi *intf);
> > > static void need_waiter(struct ipmi_smi *intf);
> > > static int handle_one_recv_msg(struct ipmi_smi *intf,
> > > @@ -3430,9 +3430,8 @@ int ipmi_add_smi(struct module *owner,
> > > intf->curr_seq = 0;
> > > spin_lock_init(&intf->waiting_rcv_msgs_lock);
> > > INIT_LIST_HEAD(&intf->waiting_rcv_msgs);
> > > - tasklet_init(&intf->recv_tasklet,
> > > - smi_recv_tasklet,
> > > - (unsigned long) intf);
> > > + tasklet_setup(&intf->recv_tasklet,
> > > + smi_recv_tasklet);
> > > atomic_set(&intf->watchdog_pretimeouts_to_deliver, 0);
> > > spin_lock_init(&intf->xmit_msgs_lock);
> > > INIT_LIST_HEAD(&intf->xmit_msgs);
> > > @@ -4467,10 +4466,10 @@ static void handle_new_recv_msgs(struct ipmi_smi
> > > *intf)
> > > }
> > > }
> > >
> > > -static void smi_recv_tasklet(unsigned long val)
> > > +static void smi_recv_tasklet(struct tasklet_struct *t)
> > > {
> > > unsigned long flags = 0; /* keep us warning-free. */
> > > - struct ipmi_smi *intf = (struct ipmi_smi *) val;
> > > + struct ipmi_smi *intf = from_tasklet(intf, t, recv_tasklet);
> > > int run_to_completion = intf->run_to_completion;
> > > struct ipmi_smi_msg *newmsg = NULL;
> > >
> > > @@ -4542,7 +4541,7 @@ void ipmi_smi_msg_received(struct ipmi_smi *intf,
> > > spin_unlock_irqrestore(&intf->xmit_msgs_lock, flags);
> > >
> > > if (run_to_completion)
> > > - smi_recv_tasklet((unsigned long) intf);
> > > + smi_recv_tasklet(&intf->recv_tasklet);
> > > else
> > > tasklet_schedule(&intf->recv_tasklet);
> > > }
> > > --
> > > 2.17.1
> > >
>
>
>
> --
>- Allen
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add support for HDCP 1.4 over MST (rev2)
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST (rev2)
URL : https://patchwork.freedesktop.org/series/78749/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8898_full -> Patchwork_18368_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18368_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18368_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_18368_full:
### IGT changes ###
Possible regressions
* igt@kms_flip@2x-flip-vs-absolute-wf_vblank@ab-vga1-hdmi-a1:
- shard-hsw: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/shard-hsw4/igt@kms_flip@2x-flip-vs-absolute-wf_vbl...@ab-vga1-hdmi-a1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/shard-hsw1/igt@kms_flip@2x-flip-vs-absolute-wf_vbl...@ab-vga1-hdmi-a1.html
### Piglit changes ###
Possible regressions
* spec@glsl-1.30@execution@built-in-functions@fs-op-bitor-uint-uvec2 (NEW):
- {pig-icl-1065g7}: NOTRUN -> [CRASH][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/pig-icl-1065g7/spec@glsl-1.30@execution@built-in-functi...@fs-op-bitor-uint-uvec2.html
* spec@glsl-1.30@execution@built-in-functions@vs-op-add-uint-uvec4 (NEW):
- {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][4] +6 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/pig-icl-1065g7/spec@glsl-1.30@execution@built-in-functi...@vs-op-add-uint-uvec4.html
New tests
-
New tests have been introduced between CI_DRM_8898_full and
Patchwork_18368_full:
### New Piglit tests (8) ###
* spec@glsl-1.30@execution@built-in-functions@fs-clamp-ivec4-int-int:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
* spec@glsl-1.30@execution@built-in-functions@fs-op-assign-bitor-uvec3-uvec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
* spec@glsl-1.30@execution@built-in-functions@fs-op-bitor-uint-uvec2:
- Statuses : 1 crash(s)
- Exec time: [0.63] s
* spec@glsl-1.30@execution@built-in-functions@fs-op-bitor-uint-uvec4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
* spec@glsl-1.30@execution@built-in-functions@fs-op-bitxor-neg-abs-int-int:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
* spec@glsl-1.30@execution@built-in-functions@vs-op-add-uint-uvec4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
* spec@glsl-1.30@execution@built-in-functions@vs-op-assign-lshift-ivec2-int:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
* spec@glsl-1.30@execution@built-in-functions@vs-op-bitor-neg-int-ivec2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_18368_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_balancer@bonded-early:
- shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2079])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/shard-kbl4/igt@gem_exec_balan...@bonded-early.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/shard-kbl6/igt@gem_exec_balan...@bonded-early.html
* igt@gem_exec_gttfill@all:
- shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/shard-glk1/igt@gem_exec_gttf...@all.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/shard-glk7/igt@gem_exec_gttf...@all.html
* igt@i915_pm_rpm@drm-resources-equal:
- shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1635] /
[i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/shard-apl8/igt@i915_pm_...@drm-resources-equal.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/shard-apl1/igt@i915_pm_...@drm-resources-equal.html
* igt@i915_selftest@mock@contexts:
- shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#198] /
[i915#2278])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/shard-skl1/igt@i915_selftest@m...@contexts.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/shard-skl2/igt@i915_selftest@m...@contexts.html
* igt@kms_big_fb@x-tiled-64bpp-rotate-180:
- shard-iclb: [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8898/shard-iclb1/igt@kms_big...@x-tiled-64bpp-rotate-180.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18368/shard-iclb3/igt@kms_big...@x-tiled-64bpp-rotate-180.html
* igt@kms_big_fb@y-tiled-64bp
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: obey "reset" module parameter
On Tue, Aug 18, 2020 at 12:58:00PM +0100, Chris Wilson wrote: > Quoting Marcin Ślusarz (2020-08-18 12:36:07) > > From: Marcin Ślusarz > > > > For some reason intel_gt_reset attempts to reset the GPU twice. > > On one code path (do_reset) "reset" parameter is obeyed, but is > > not on the other one (__intel_gt_set_wedged). > > It's not that simple, we do want to force __intel_gt_set_wedged() to > cancel whatever is running on the GPU as it is used for more than just > failing resets (e.g. around control boundaries) regardless of what the > user may want. > > I'm loathe to add a parameter just to enable unsafe behaviour, but that > may be the compromise. we probably need this compromise for these cases Marcin faced... what about moving this to intel_get_gpu_reset()? @bool intel_has_gpu_reset(const struct intel_gt *gt) - if (!gt->i915->params.reset) - return NULL; @ static reset_func intel_get_gpu_reset(const struct intel_gt *gt) + if (!gt->i915->params.reset) + return NULL; > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: obey "reset" module parameter
Quoting Rodrigo Vivi (2020-08-18 18:49:19) > On Tue, Aug 18, 2020 at 12:58:00PM +0100, Chris Wilson wrote: > > Quoting Marcin Ślusarz (2020-08-18 12:36:07) > > > From: Marcin Ślusarz > > > > > > For some reason intel_gt_reset attempts to reset the GPU twice. > > > On one code path (do_reset) "reset" parameter is obeyed, but is > > > not on the other one (__intel_gt_set_wedged). > > > > It's not that simple, we do want to force __intel_gt_set_wedged() to > > cancel whatever is running on the GPU as it is used for more than just > > failing resets (e.g. around control boundaries) regardless of what the > > user may want. > > > > I'm loathe to add a parameter just to enable unsafe behaviour, but that > > may be the compromise. > > we probably need this compromise for these cases Marcin faced... You can always say those who risk unsafe parameters are always capable of patching the kernel to break it. > what about moving this to intel_get_gpu_reset()? When it was there, we didn't have the reason why, so we ended up duplicating the tests anyway to suppress the error messages for CI. And it breaks the control boundary cases where we have to reset the GPU, or when we need the wedge to undeadlock modesetting which will also lockup the machine. In short, we should remove the parameter; we'll still end up having to bisect through the GPU features [atomic ops, it's always atomic ops] to find which one is killing the machine. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Push the fake iommu device from the stack to data
Since we store a pointer to the fake iommu device that is allocated on
the stack, as soon as we leave the function it goes out of scope and any
future dereference is undefined behaviour. Just in case we may need to
look at the fake iommu device after initialiation, move the allocation
from the stack into the data.
Fixes: 01b9d4e21148 ("iommu/vt-d: Use dev_iommu_priv_get/set()")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index f127e633f7ca..397c313a8b69 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -118,11 +118,11 @@ static struct dev_pm_domain pm_domain = {
struct drm_i915_private *mock_gem_device(void)
{
- struct drm_i915_private *i915;
- struct pci_dev *pdev;
#if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
- struct dev_iommu iommu;
+ static struct dev_iommu fake_iommu = { .priv = (void *)-1 };
#endif
+ struct drm_i915_private *i915;
+ struct pci_dev *pdev;
int err;
pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
@@ -141,10 +141,8 @@ struct drm_i915_private *mock_gem_device(void)
dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
#if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
- /* HACK HACK HACK to disable iommu for the fake device; force identity
mapping */
- memset(&iommu, 0, sizeof(iommu));
- iommu.priv = (void *)-1;
- pdev->dev.iommu = &iommu;
+ /* HACK to disable iommu for the fake device; force identity mapping */
+ pdev->dev.iommu = &fake_iommu;
#endif
pci_set_drvdata(pdev, i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Push the fake iommu device from the stack to data
On Tue, 18 Aug 2020 at 19:43, Chris Wilson wrote:
>
> Since we store a pointer to the fake iommu device that is allocated on
> the stack, as soon as we leave the function it goes out of scope and any
> future dereference is undefined behaviour. Just in case we may need to
> look at the fake iommu device after initialiation, move the allocation
> from the stack into the data.
>
> Fixes: 01b9d4e21148 ("iommu/vt-d: Use dev_iommu_priv_get/set()")
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Push the fake iommu device from the stack to data
== Series Details == Series: drm/i915/selftests: Push the fake iommu device from the stack to data URL : https://patchwork.freedesktop.org/series/80756/ State : success == Summary == CI Bug Log - changes from CI_DRM_8900 -> Patchwork_18369 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/index.html Known issues Here are the changes found in Patchwork_18369 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-tgl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/fi-tgl-u2/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-n3050: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [FAIL][5] ([i915#1888]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@i915_selftest@live@execlists: - fi-apl-guc: [INCOMPLETE][7] ([i915#1635]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/fi-apl-guc/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/fi-apl-guc/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7500u: [DMESG-WARN][9] ([i915#2203]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2: - fi-skl-guc: [DMESG-WARN][11] ([i915#2203]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [DMESG-FAIL][13] ([i915#62] / [i915#95]) -> [DMESG-FAIL][14] ([i915#62]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/fi-kbl-x1275/igt@i915_pm_...@module-reload.html - fi-kbl-guc: [DMESG-WARN][15] ([i915#2203]) -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/fi-kbl-guc/igt@i915_pm_...@module-reload.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) -> [DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][20] ([i915#62] / [i915#92]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (39 -> 34) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper Build changes - * Linux: CI_D
Re: [Intel-gfx] [PATCH] block: convert tasklets to use new tasklet_setup() API
On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote: > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > > On 8/17/20 12:48 PM, Kees Cook wrote: > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > > > > On 8/17/20 12:29 PM, Kees Cook wrote: > > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > > > > > > On 8/17/20 2:15 AM, Allen Pais wrote: > > > > > > > From: Allen Pais > > > > > > > > > > > > > > In preparation for unconditionally passing the > > > > > > > struct tasklet_struct pointer to all tasklet > > > > > > > callbacks, switch to using the new tasklet_setup() > > > > > > > and from_tasklet() to pass the tasklet pointer explicitly. > > > > > > > > > > > > Who came up with the idea to add a macro 'from_tasklet' that > > > > > > is just container_of? container_of in the code would be > > > > > > _much_ more readable, and not leave anyone guessing wtf > > > > > > from_tasklet is doing. > > > > > > > > > > > > I'd fix that up now before everything else goes in... > > > > > > > > > > As I mentioned in the other thread, I think this makes things > > > > > much more readable. It's the same thing that the timer_struct > > > > > conversion did (added a container_of wrapper) to avoid the > > > > > ever-repeating use of typeof(), long lines, etc. > > > > > > > > But then it should use a generic name, instead of each sub-system > > > > using some random name that makes people look up exactly what it > > > > does. I'm not huge fan of the container_of() redundancy, but > > > > adding private variants of this doesn't seem like the best way > > > > forward. Let's have a generic helper that does this, and use it > > > > everywhere. > > > > > > I'm open to suggestions, but as things stand, these kinds of > > > treewide > > > > On naming? Implementation is just as it stands, from_tasklet() is > > totally generic which is why I objected to it. from_member()? Not > > great with naming... But I can see this going further and then we'll > > suddenly have tons of these. It's not good for readability. > > Since both threads seem to have petered out, let me suggest in > kernel.h: > > #define cast_out(ptr, container, member) \ > container_of(ptr, typeof(*container), member) > > It does what you want, the argument order is the same as container_of > with the only difference being you name the containing structure > instead of having to specify its type. I like this! Shall I send this to Linus to see if this can land in -rc2 for use going forward? -- Kees Cook ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] block: convert tasklets to use new tasklet_setup() API
On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > On 8/17/20 12:48 PM, Kees Cook wrote: > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > > > On 8/17/20 12:29 PM, Kees Cook wrote: > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > > > > > On 8/17/20 2:15 AM, Allen Pais wrote: > > > > > > From: Allen Pais > > > > > > > > > > > > In preparation for unconditionally passing the > > > > > > struct tasklet_struct pointer to all tasklet > > > > > > callbacks, switch to using the new tasklet_setup() > > > > > > and from_tasklet() to pass the tasklet pointer explicitly. > > > > > > > > > > Who came up with the idea to add a macro 'from_tasklet' that > > > > > is just container_of? container_of in the code would be > > > > > _much_ more readable, and not leave anyone guessing wtf > > > > > from_tasklet is doing. > > > > > > > > > > I'd fix that up now before everything else goes in... > > > > > > > > As I mentioned in the other thread, I think this makes things > > > > much more readable. It's the same thing that the timer_struct > > > > conversion did (added a container_of wrapper) to avoid the > > > > ever-repeating use of typeof(), long lines, etc. > > > > > > But then it should use a generic name, instead of each sub-system > > > using some random name that makes people look up exactly what it > > > does. I'm not huge fan of the container_of() redundancy, but > > > adding private variants of this doesn't seem like the best way > > > forward. Let's have a generic helper that does this, and use it > > > everywhere. > > > > I'm open to suggestions, but as things stand, these kinds of > > treewide > > On naming? Implementation is just as it stands, from_tasklet() is > totally generic which is why I objected to it. from_member()? Not > great with naming... But I can see this going further and then we'll > suddenly have tons of these. It's not good for readability. Since both threads seem to have petered out, let me suggest in kernel.h: #define cast_out(ptr, container, member) \ container_of(ptr, typeof(*container), member) It does what you want, the argument order is the same as container_of with the only difference being you name the containing structure instead of having to specify its type. James ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] block: convert tasklets to use new tasklet_setup() API
On Tue, 2020-08-18 at 13:10 -0700, Kees Cook wrote: > On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote: > > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > > > On 8/17/20 12:48 PM, Kees Cook wrote: > > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > > > > > On 8/17/20 12:29 PM, Kees Cook wrote: > > > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > > > > > > > On 8/17/20 2:15 AM, Allen Pais wrote: > > > > > > > > From: Allen Pais > > > > > > > > > > > > > > > > In preparation for unconditionally passing the > > > > > > > > struct tasklet_struct pointer to all tasklet > > > > > > > > callbacks, switch to using the new tasklet_setup() > > > > > > > > and from_tasklet() to pass the tasklet pointer > > > > > > > > explicitly. > > > > > > > > > > > > > > Who came up with the idea to add a macro 'from_tasklet' > > > > > > > that > > > > > > > is just container_of? container_of in the code would be > > > > > > > _much_ more readable, and not leave anyone guessing wtf > > > > > > > from_tasklet is doing. > > > > > > > > > > > > > > I'd fix that up now before everything else goes in... > > > > > > > > > > > > As I mentioned in the other thread, I think this makes > > > > > > things > > > > > > much more readable. It's the same thing that the > > > > > > timer_struct > > > > > > conversion did (added a container_of wrapper) to avoid the > > > > > > ever-repeating use of typeof(), long lines, etc. > > > > > > > > > > But then it should use a generic name, instead of each sub- > > > > > system > > > > > using some random name that makes people look up exactly what > > > > > it > > > > > does. I'm not huge fan of the container_of() redundancy, but > > > > > adding private variants of this doesn't seem like the best > > > > > way > > > > > forward. Let's have a generic helper that does this, and use > > > > > it > > > > > everywhere. > > > > > > > > I'm open to suggestions, but as things stand, these kinds of > > > > treewide > > > > > > On naming? Implementation is just as it stands, from_tasklet() is > > > totally generic which is why I objected to it. from_member()? Not > > > great with naming... But I can see this going further and then > > > we'll > > > suddenly have tons of these. It's not good for readability. > > > > Since both threads seem to have petered out, let me suggest in > > kernel.h: > > > > #define cast_out(ptr, container, member) \ > > container_of(ptr, typeof(*container), member) > > > > It does what you want, the argument order is the same as > > container_of with the only difference being you name the containing > > structure instead of having to specify its type. > > I like this! Shall I send this to Linus to see if this can land in > -rc2 for use going forward? Sure ... he's probably been lurking on this thread anyway ... it's about time he got off his arse^Wthe fence and made an executive decision ... James ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/dp: TPS4 PHY test pattern compliance support
On Wed, Jul 22, 2020 at 05:36:27PM -0700, Khaled Almahallawy wrote:
> Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
>
> v2: uniform bit names TP4a/b/c (Manasi)
>
> Signed-off-by: Khaled Almahallawy
Looks good to me,
Reviewed-by: Manasi Navare
Khaled, could you also give a tested by here?
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 14 --
> drivers/gpu/drm/i915/i915_reg.h | 4
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d6295eb20b63..4b74b2ec5665 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5371,7 +5371,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp
> *intel_dp)
> &intel_dp->compliance.test_data.phytest;
> struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
> enum pipe pipe = crtc->pipe;
> - u32 pattern_val;
> + u32 pattern_val, dp_tp_ctl;
>
> switch (data->phy_pattern) {
> case DP_PHY_TEST_PATTERN_NONE:
> @@ -5411,7 +5411,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp
> *intel_dp)
> DDI_DP_COMP_CTL_ENABLE |
> DDI_DP_COMP_CTL_CUSTOM80);
> break;
> - case DP_PHY_TEST_PATTERN_CP2520:
> + case DP_PHY_TEST_PATTERN_CP2520_PAT1:
> /*
>* FIXME: Ideally pattern should come from DPCD 0x24A. As
>* current firmware of DPR-100 could not set it, so hardcoding
> @@ -5423,6 +5423,16 @@ static void intel_dp_phy_pattern_update(struct
> intel_dp *intel_dp)
> DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
> pattern_val);
> break;
> + case DP_PHY_TEST_PATTERN_CP2520_PAT3:
> + DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
> + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
> + dp_tp_ctl = intel_de_read(dev_priv,
> TGL_DP_TP_CTL(pipe));
> + dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
> + dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
> + dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> + dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
> + intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe),
> dp_tp_ctl);
> + break;
> default:
> WARN(1, "Invalid Phy Test Pattern\n");
> }
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a0d31f3bf634..c586595b9e76 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9982,6 +9982,10 @@ enum skl_power_gate {
> #define DP_TP_CTL_MODE_SST (0 << 27)
> #define DP_TP_CTL_MODE_MST (1 << 27)
> #define DP_TP_CTL_FORCE_ACT (1 << 25)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
> #define DP_TP_CTL_ENHANCED_FRAME_ENABLE (1 << 18)
> #define DP_TP_CTL_FDI_AUTOTRAIN (1 << 15)
> #define DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
> --
> 2.17.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Push the fake iommu device from the stack to data
== Series Details == Series: drm/i915/selftests: Push the fake iommu device from the stack to data URL : https://patchwork.freedesktop.org/series/80756/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8900_full -> Patchwork_18369_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18369_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18369_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18369_full: ### IGT changes ### Possible regressions * igt@i915_pm_backlight@fade_with_suspend: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/shard-skl5/igt@i915_pm_backlight@fade_with_suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/shard-skl4/igt@i915_pm_backlight@fade_with_suspend.html * igt@kms_cursor_legacy@cursor-vs-flip-toggle: - shard-hsw: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/shard-hsw4/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html Known issues Here are the changes found in Patchwork_18369_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/shard-kbl2/igt@gem_ctx_isolation@preservation...@vcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#1528]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/shard-skl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/shard-skl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html * igt@gem_exec_whisper@basic-contexts-forked: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/shard-glk8/igt@gem_exec_whis...@basic-contexts-forked.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/shard-glk7/igt@gem_exec_whis...@basic-contexts-forked.html * igt@i915_suspend@fence-restore-untiled: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#198]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/shard-skl3/igt@i915_susp...@fence-restore-untiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/shard-skl1/igt@i915_susp...@fence-restore-untiled.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][13] -> [DMESG-FAIL][14] ([i915#118] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/shard-glk1/igt@kms_big...@linear-64bpp-rotate-180.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-untiled: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#52] / [i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/shard-skl4/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-untiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/shard-skl8/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-untiled.html * igt@kms_flip@2x-modeset-vs-vblank-race-interruptible@ab-vga1-hdmi-a1: - shard-hsw: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/shard-hsw8/igt@kms_flip@2x-modeset-vs-vblank-race-interrupti...@ab-vga1-hdmi-a1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/shard-hsw6/igt@kms_flip@2x-modeset-vs-vblank-race-interrupti...@ab-vga1-hdmi-a1.html * igt@kms_flip_tiling@flip-to-y-tiled: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#167]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8900/shard-skl6/igt@kms_flip_til...@flip-to-y-tiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18369/shard-skl9/igt@kms_flip_til...@flip-to-y-tiled.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +1 similar issue [21]: https://intel-gfx-ci.01.or
Re: [Intel-gfx] [PATCH v8 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
Just one small comment
On Tue, 2020-08-18 at 11:39 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Used to query whether an MST stream is encrypted or not.
>
> Cc: Lyude Paul
> Reviewed-by: Anshuman Gupta
> Signed-off-by: Sean Paul
>
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
> #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
> #v5
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-s...@poorly.run
> #v6
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-16-s...@poorly.run
> #v7
>
> Changes in v4:
> -Added to the set
> Changes in v5:
> -None
> Changes in v6:
> -Use FIELD_PREP to generate request buffer bitfields (Lyude)
> -Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
> Changes in v7:
> -None
> Changes in v8:
> -Reverse the parsing on the hdcp_*x_device_present bits and leave
> breadcrumb in case this is incorrect (Anshuman)
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 150 ++
> .../drm/selftests/test-drm_dp_mst_helper.c| 17 ++
> include/drm/drm_dp_helper.h | 3 +
> include/drm/drm_dp_mst_helper.h | 44 +
> 4 files changed, 214 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 67dd72ea200e..f2b77ef40281 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -20,11 +20,13 @@
> * OF THIS SOFTWARE.
> */
>
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -423,6 +425,22 @@ drm_dp_encode_sideband_req(const struct
> drm_dp_sideband_msg_req_body *req,
> memcpy(&buf[idx], req->u.i2c_write.bytes, req-
> >u.i2c_write.num_bytes);
> idx += req->u.i2c_write.num_bytes;
> break;
> + case DP_QUERY_STREAM_ENC_STATUS: {
> + const struct drm_dp_query_stream_enc_status *msg;
> +
> + msg = &req->u.enc_status;
> + buf[idx] = msg->stream_id;
> + idx++;
> + memcpy(&buf[idx], msg->client_id, sizeof(msg->client_id));
> + idx += sizeof(msg->client_id);
> + buf[idx] = 0;
> + buf[idx] |= FIELD_PREP(GENMASK(1, 0), msg->stream_event);
> + buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
> + buf[idx] |= FIELD_PREP(GENMASK(4, 3), msg->stream_behavior);
> + buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
> + idx++;
> + }
> + break;
> }
> raw->cur_len = idx;
> }
> @@ -551,6 +569,20 @@ drm_dp_decode_sideband_req(const struct
> drm_dp_sideband_msg_tx *raw,
> return -ENOMEM;
> }
> break;
> + case DP_QUERY_STREAM_ENC_STATUS:
> + req->u.enc_status.stream_id = buf[idx++];
> + for (i = 0; i < sizeof(req->u.enc_status.client_id); i++)
> + req->u.enc_status.client_id[i] = buf[idx++];
> +
> + req->u.enc_status.stream_event = FIELD_GET(GENMASK(1, 0),
> +buf[idx]);
> + req->u.enc_status.valid_stream_event = FIELD_GET(BIT(2),
> + buf[idx]);
> + req->u.enc_status.stream_behavior = FIELD_GET(GENMASK(4, 3),
> + buf[idx]);
> + req->u.enc_status.valid_stream_behavior = FIELD_GET(BIT(5),
> + buf[idx]);
> + break;
> }
>
> return 0;
> @@ -629,6 +661,16 @@ drm_dp_dump_sideband_msg_req_body(const struct
> drm_dp_sideband_msg_req_body *req
> req->u.i2c_write.num_bytes, req->u.i2c_write.num_bytes,
> req->u.i2c_write.bytes);
> break;
> + case DP_QUERY_STREAM_ENC_STATUS:
> + P("stream_id=%u client_id=%*ph stream_event=%x "
> + "valid_event=%d stream_behavior=%x valid_behavior=%d",
> + req->u.enc_status.stream_id,
> + (int)ARRAY_SIZE(req->u.enc_status.client_id),
> + req->u.enc_status.client_id, req->u.enc_status.stream_event,
> + req->u.enc_status.valid_stream_event,
> + req->u.enc_status.stream_behavior,
> + req->u.enc_status.valid_stream_behavior);
> + break;
> default:
> P("???\n");
> break;
> @@ -936,6 +978,42 @@ static bool
> drm_dp_sideband_parse_power_updown_phy_ack(struct drm_dp_sideband_ms
> return true;
> }
>
> +static bool
> +drm_dp_sideband_parse_query_stream_enc_status(
> + struct drm_dp_sideband_msg_rx *raw,
> +
Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline
Ping on this?
The code disassembles to
24: 8b 85 d0 fd ff ffmov-0x230(%ebp),%eax
2a:* c7 03 01 00 40 10movl $0x1041,(%ebx) <-- trapping instruction
30: 89 43 04 mov%eax,0x4(%ebx)
33: 8b 85 b4 fd ff ffmov-0x24c(%ebp),%eax
39: 89 43 08 mov%eax,0x8(%ebx)
3c: e9jmp ...
which looks like is one of the cases in __reloc_entry_gpu(). I *think*
it's this one:
} else if (gen >= 3 &&
!(IS_I915G(eb->i915) || IS_I915GM(eb->i915))) {
*batch++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
*batch++ = addr;
*batch++ = target_addr;
where that "batch" pointer is 0xf8601000, so it looks like it just
overflowed into the next page that isn't there.
The cleaned-up call trace is
drm_ioctl+0x1f4/0x38b ->
drm_ioctl_kernel+0x87/0xd0 ->
i915_gem_execbuffer2_ioctl+0xdd/0x360 ->
i915_gem_do_execbuffer+0xaab/0x2780 ->
eb_relocate_vma
but there's a lot of inling going on, so..
The obvious suspect is commit 9e0f9464e2ab ("drm/i915/gem: Async GPU
relocations only") but that's going purely by "that seems to be the
main relocation change this mmrge window".
Linus
On Mon, Aug 17, 2020 at 9:11 AM Pavel Machek wrote:
>
> Hi!
>
> After about half an hour of uptime, screen starts blinking on thinkpad
> x60 and machine becomes unusable.
>
> I already reported this in -next, and now it is in mainline. It is
> 32-bit x86 system.
>
>
> Pavel
>
>
> Aug 17 17:36:04 amd ovpn-castor[2828]: UDPv4 link local (bound):
> [undef]
> Aug 17 17:36:04 amd ovpn-castor[2828]: UDPv4 link remote:
> [AF_INET]87.138.219.28:1194
> Aug 17 17:36:23 amd kernel: BUG: unable to handle page fault for
> address: f8601000
> Aug 17 17:36:23 amd kernel: #PF: supervisor write access in kernel
> mode
> Aug 17 17:36:23 amd kernel: #PF: error_code(0x0002) - not-present page
> Aug 17 17:36:23 amd kernel: *pdpt = 318f2001 *pde =
>
> Aug 17 17:36:23 amd kernel: Oops: 0002 [#1] PREEMPT SMP PTI
> Aug 17 17:36:23 amd kernel: CPU: 1 PID: 3004 Comm: Xorg Not tainted
> 5.9.0-rc1+ #86
> Aug 17 17:36:23 amd kernel: Hardware name: LENOVO 17097HU/17097HU,
> BIOS 7BETD8WW (2.19 ) 03/31
> /2011
> Aug 17 17:36:23 amd kernel: EIP: eb_relocate_vma+0xcf6/0xf20
> Aug 17 17:36:23 amd kernel: Code: e9 ff f7 ff ff c7 85 c0 fd ff ff ed
> ff ff ff c7 85 c4 fd ff
> ff ff ff ff ff 8b 85 c0 fd ff ff e9 a5 f8 ff ff 8b 85 d0 fd ff ff
> 03 01 00 40 10 89 43 04
> 8b 85 b4 fd ff ff 89 43 08 e9 9f f7 ff
> Aug 17 17:36:23 amd kernel: EAX: 003c306c EBX: f8601000 ECX: 00847000
> EDX:
> Aug 17 17:36:23 amd kernel: ESI: 00847000 EDI: EBP: f1947c68
> ESP: f19479fc
> Aug 17 17:36:23 amd kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS:
> 0068 EFLAGS: 00210246
> Aug 17 17:36:23 amd kernel: CR0: 80050033 CR2: f8601000 CR3: 31a1e000
> CR4: 06b0
> Aug 17 17:36:23 amd kernel: Call Trace:
> Aug 17 17:36:23 amd kernel: ? i915_vma_pin+0xc5/0x8c0
> Aug 17 17:36:23 amd kernel: ? __mutex_unlock_slowpath+0x2b/0x280
> Aug 17 17:36:23 amd kernel: ? __active_retire+0x7e/0xd0
> Aug 17 17:36:23 amd kernel: ? mutex_unlock+0xb/0x10
> Aug 17 17:36:23 amd kernel: ? i915_vma_pin+0xc5/0x8c0
> Aug 17 17:36:23 amd kernel: ? __lock_acquire.isra.31+0x261/0x530
> Aug 17 17:36:23 amd kernel: ? eb_lookup_vmas+0x1f5/0x9e0
> Aug 17 17:36:23 amd kernel: i915_gem_do_execbuffer+0xaab/0x2780
> Aug 17 17:36:23 amd kernel: ? _raw_spin_unlock_irqrestore+0x27/0x40
> Aug 17 17:36:23 amd kernel: ? __lock_acquire.isra.31+0x261/0x530
> Aug 17 17:36:23 amd kernel: ? __lock_acquire.isra.31+0x261/0x530
> Aug 17 17:36:23 amd kernel: ? kvmalloc_node+0x69/0x70
> Aug 17 17:36:23 amd kernel: i915_gem_execbuffer2_ioctl+0xdd/0x360
> Aug 17 17:36:23 amd kernel: ? i915_gem_execbuffer_ioctl+0x2b0/0x2b0
> Aug 17 17:36:23 amd kernel: drm_ioctl_kernel+0x87/0xd0
> Aug 17 17:36:23 amd kernel: drm_ioctl+0x1f4/0x38b
> Aug 17 17:36:23 amd kernel: ? i915_gem_execbuffer_ioctl+0x2b0/0x2b0
> Aug 17 17:36:23 amd kernel: ? posix_get_monotonic_timespec+0x1c/0x90
> Aug 17 17:36:23 amd kernel: ? ktime_get_ts64+0x7a/0x1e0
> Aug 17 17:36:23 amd kernel: ? drm_ioctl_kernel+0xd0/0xd0
> Aug 17 17:36:23 amd kernel: __ia32_sys_ioctl+0x1ad/0x799
> Aug 17 17:36:23 amd kernel: ? debug_smp_processor_id+0x12/0x20
> Aug 17 17:36:23 amd kernel: ? exit_to_user_mode_prepare+0x4f/0x100
> Aug 17 17:36:23 amd kernel: do_int80_syscall_32+0x2c/0x40
> Aug 17 17:36:23 amd kernel: entry_INT80_32+0x111/0x111
> Aug 17 17:36:23 amd kernel: EIP: 0xb7fbc092
> Aug 17 17:36:23 amd kernel: Code: 00 00 00 e9 90 ff ff ff ff a3 24 00
> 00 00 68 30 00 00 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00
> 00 00 00 00 00 cd 80 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b
> 1c 24 c3 8d b4 26 00
> Aug 17 17:36:23 amd kernel: EAX: ffda EBX: 000a ECX: c0406469
> E
Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline
On Wed, 19 Aug 2020 at 10:38, Linus Torvalds
wrote:
>
> Ping on this?
>
> The code disassembles to
>
> 24: 8b 85 d0 fd ff ffmov-0x230(%ebp),%eax
> 2a:* c7 03 01 00 40 10movl $0x1041,(%ebx) <-- trapping instruction
> 30: 89 43 04 mov%eax,0x4(%ebx)
> 33: 8b 85 b4 fd ff ffmov-0x24c(%ebp),%eax
> 39: 89 43 08 mov%eax,0x8(%ebx)
> 3c: e9jmp ...
>
> which looks like is one of the cases in __reloc_entry_gpu(). I *think*
> it's this one:
>
> } else if (gen >= 3 &&
>!(IS_I915G(eb->i915) || IS_I915GM(eb->i915))) {
> *batch++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
> *batch++ = addr;
> *batch++ = target_addr;
>
> where that "batch" pointer is 0xf8601000, so it looks like it just
> overflowed into the next page that isn't there.
>
> The cleaned-up call trace is
>
> drm_ioctl+0x1f4/0x38b ->
> drm_ioctl_kernel+0x87/0xd0 ->
> i915_gem_execbuffer2_ioctl+0xdd/0x360 ->
> i915_gem_do_execbuffer+0xaab/0x2780 ->
> eb_relocate_vma
>
> but there's a lot of inling going on, so..
>
> The obvious suspect is commit 9e0f9464e2ab ("drm/i915/gem: Async GPU
> relocations only") but that's going purely by "that seems to be the
> main relocation change this mmrge window".
I think there's been some discussion about reverting that change for
other reasons, but it's quite likely the culprit.
Maybe we can push for a revert sooner, (cc'ing more of i915 team).
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/dp: TPS4 PHY test pattern compliance support
On Tue, 2020-08-18 at 14:29 -0700, Navare, Manasi wrote:
> On Wed, Jul 22, 2020 at 05:36:27PM -0700, Khaled Almahallawy wrote:
> > Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source
> > tests.
> >
> > v2: uniform bit names TP4a/b/c (Manasi)
> >
> > Signed-off-by: Khaled Almahallawy
>
> Looks good to me,
>
> Reviewed-by: Manasi Navare
>
> Khaled, could you also give a tested by here?
>
> Manasi
Passed all TPS4 tests on DP Compliance scope with DPoC1.4a test
specification
Tested-by: Khaled Almahallawy
>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 14 --
> > drivers/gpu/drm/i915/i915_reg.h | 4
> > 2 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d6295eb20b63..4b74b2ec5665 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5371,7 +5371,7 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> > &intel_dp->compliance.test_data.phytest;
> > struct intel_crtc *crtc = to_intel_crtc(dig_port-
> > >base.base.crtc);
> > enum pipe pipe = crtc->pipe;
> > - u32 pattern_val;
> > + u32 pattern_val, dp_tp_ctl;
> >
> > switch (data->phy_pattern) {
> > case DP_PHY_TEST_PATTERN_NONE:
> > @@ -5411,7 +5411,7 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> >DDI_DP_COMP_CTL_ENABLE |
> >DDI_DP_COMP_CTL_CUSTOM80);
> > break;
> > - case DP_PHY_TEST_PATTERN_CP2520:
> > + case DP_PHY_TEST_PATTERN_CP2520_PAT1:
> > /*
> > * FIXME: Ideally pattern should come from DPCD 0x24A.
> > As
> > * current firmware of DPR-100 could not set it, so
> > hardcoding
> > @@ -5423,6 +5423,16 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> >DDI_DP_COMP_CTL_ENABLE |
> > DDI_DP_COMP_CTL_HBR2 |
> >pattern_val);
> > break;
> > + case DP_PHY_TEST_PATTERN_CP2520_PAT3:
> > + DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
> > + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
> > 0x0);
> > + dp_tp_ctl = intel_de_read(dev_priv,
> > TGL_DP_TP_CTL(pipe));
> > + dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
> > + dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
> > + dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> > + dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
> > + intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe),
> > dp_tp_ctl);
> > + break;
> > default:
> > WARN(1, "Invalid Phy Test Pattern\n");
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index a0d31f3bf634..c586595b9e76 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -9982,6 +9982,10 @@ enum skl_power_gate {
> > #define DP_TP_CTL_MODE_SST(0 << 27)
> > #define DP_TP_CTL_MODE_MST(1 << 27)
> > #define DP_TP_CTL_FORCE_ACT (1 << 25)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
> > #define DP_TP_CTL_ENHANCED_FRAME_ENABLE (1 << 18)
> > #define DP_TP_CTL_FDI_AUTOTRAIN (1 << 15)
> > #define DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
> > --
> > 2.17.1
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline
On Tue, Aug 18, 2020 at 6:13 PM Dave Airlie wrote:
>
> I think there's been some discussion about reverting that change for
> other reasons, but it's quite likely the culprit.
Hmm. It reverts cleanly, but the end result doesn't work, because of
other changes.
Reverting all of
763fedd6a216 ("drm/i915: Remove i915_gem_object_get_dirty_page()")
7ac2d2536dfa ("drm/i915/gem: Delete unused code")
9e0f9464e2ab ("drm/i915/gem: Async GPU relocations only")
seems to at least build.
Pavel, does doing those three reverts make things work for you?
Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
