Re: [Intel-gfx] [PATCH v5] drm/i915/pxp: limit drm-errors or warning on firmware API failures
Thanks Daniele, Thanks Jani. ...alan
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Disable C6 on MTL A0 for media (rev3)
== Series Details ==
Series: drm/i915/mtl: Disable C6 on MTL A0 for media (rev3)
URL : https://patchwork.freedesktop.org/series/115610/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12913_full -> Patchwork_115610v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_115610v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#3886])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-apl2/igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2346])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/shard-glk8/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-glk8/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][4] -> [FAIL][5] ([i915#2346])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-apl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@v3d/v3d_get_param@get-bad-param:
- shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271]) +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-apl2/igt@v3d/v3d_get_pa...@get-bad-param.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][7] ([i915#7742]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-rkl-5/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@drm_read@short-buffer-block:
- {shard-rkl}:[SKIP][9] ([i915#4098]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/shard-rkl-1/igt@drm_r...@short-buffer-block.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-rkl-6/igt@drm_r...@short-buffer-block.html
* igt@fbdev@pan:
- {shard-rkl}:[SKIP][11] ([i915#2582]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/shard-rkl-1/igt@fb...@pan.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-rkl-6/igt@fb...@pan.html
* igt@fbdev@unaligned-read:
- {shard-tglu}: [SKIP][13] ([i915#2582]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/shard-tglu-9/igt@fb...@unaligned-read.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-tglu-5/igt@fb...@unaligned-read.html
* igt@gem_exec_balancer@fairslice:
- {shard-rkl}:[SKIP][15] ([i915#6259]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/shard-rkl-5/igt@gem_exec_balan...@fairslice.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-rkl-3/igt@gem_exec_balan...@fairslice.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][17] ([i915#6247]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-rkl-3/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +13 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/shard-rkl-4/igt@gem_exec_re...@basic-wc-read-noreloc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html
* igt@gem_exec_schedule@semaphore-power:
- {shard-rkl}:[SKIP][21] ([i915#7276]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/shard-rkl-4/igt@gem_exec_sched...@semaphore-power.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/shard-rkl-5/igt@gem_exec_sched...@semaphore-power.html
* igt@gem_exec_whisper@basic-fds-priority-all:
- {shard-tglu}: [INCOMPLETE][23] ([i915#6755]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/shard-tglu-2/igt@gem_exec_whis...@basic-fds-priority-all.html
[24]:
Re: [Intel-gfx] [RFC v4 00/10] DRM scheduling cgroup controller
Hello, Tvrtko. On Tue, Mar 14, 2023 at 02:18:54PM +, Tvrtko Ursulin wrote: > DRM scheduling soft limits > ~~ > > Because of the heterogenous hardware and driver DRM capabilities, soft limits > are implemented as a loose co-operative (bi-directional) interface between the > controller and DRM core. > > The controller configures the GPU time allowed per group and periodically > scans > the belonging tasks to detect the over budget condition, at which point it > invokes a callback notifying the DRM core of the condition. > > DRM core provides an API to query per process GPU utilization and 2nd API to > receive notification from the cgroup controller when the group enters or exits > the over budget condition. > > Individual DRM drivers which implement the interface are expected to act on > this > in the best-effort manner only. There are no guarantees that the soft limits > will be respected. > > DRM scheduling soft limits interface files > ~~ In general, I'm in favor of your approach but can you please stop using the term "soft limit". That's a term with a specific historical meaning in cgroup, so it gets really confusing when you use the term for hierarchical weighted control. If you need a term to refer to how the weighted control is implemented by throttling cgroups at target rates, please just come up with a different term "usage threshold based control", "usage throttling based control" or whichever you may like. > drm.weight > Standard cgroup weight based control [1, 1] used to configure the > relative distributing of GPU time between the sibling groups. > > This builds upon the per client GPU utilisation work which landed recently > for a > few drivers. My thinking is that in principle, an intersect of drivers which > support both that and some sort of scheduling control, like priorities, could > also in theory support this controller. > > Another really interesting angle for this controller is that it mimics the > same > control menthod used by the CPU scheduler. That is the proportional/weight > based > GPU time budgeting. Which makes it easy to configure and does not need a new > mental model. FWIW, the hierarchical weighted distribution is also implemented by IO control. > However, as the introduction mentions, GPUs are much more heterogenous and > therefore the controller uses very "soft" wording as to what it promises. The > general statement is that it can define budgets, notify clients when they are > over them, and let individual drivers implement best effort handling of those > conditions. Maybe "best effort" is more suited than "soft"? ... > Roughly simultaneously we run the following two benchmarks in each session > respectively: > > 1) > ./GpuTest /test=pixmark_julia_fp32 /width=1920 /height=1080 /fullscreen > /no_scorebox /benchmark /benchmark_duration_ms=6 > > 2) > vblank_mode=0 bin/testfw_app --gl_api=desktop_core --width=1920 --height=1080 > --fullscreen 1 --gfx=glfw -t gl_manhattan > > (The only reason for vsync off here is because I struggled to find an easily > runnable and demanding enough benchmark, or to run on a screen large enough to > make even a simpler ones demanding.) > > With this test we get 252fps from GpuTest and 96fps from GfxBenchmark. > > Premise here is that one of these GPU intensive benchmarks is intended to be > ran > by the user with lower priority. Imagine kicking off some background compute > processing and continuing to use the UI for other tasks. Hence the user will > now > re-run the test by first lowering the weight control of the first session (DRM > cgroup): > > 1) > echo 50 | sudo tee /sys/fs/cgroup/`cut -d':' -f3 /proc/self/cgroup`/drm.weight > ./GpuTest /test=pixmark_julia_fp32 /width=1920 /height=1080 /fullscreen > /no_scorebox /benchmark /benchmark_duration_ms=6 > > 2) > vblank_mode=0 bin/testfw_app --gl_api=desktop_core --width=1920 --height=1080 > --fullscreen 1 --gfx=glfw -t gl_manhattan > > In this case we will see that GpuTest has recorded 208fps (~18% down) and > GfxBenchmark 114fps (18% up), demonstrating that even a very simple approach > of > wiring up i915 to the DRM cgroup controller can enable external GPU scheduling > control. It's really nice to see it working pretty intuitively. > * For now (RFC) I haven't implemented the 2nd suggestion from Tejun of having >a shadow tree which would only contain groups with DRM clients. (Purpose >being less nodes to traverse in the scanning loop.) > > * Is the global state passing from can_attach to attach really okay? (I need >source and destination css.) Right now, it is and there are other places that depend on it. Obviously, it's not great and we probably want to add explicit context passed around instead in the future, but for now, it should be okay. While not fully polished, from cgroup POV, the series looks pretty good and I'd be happy to see it
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev4)
== Series Details ==
Series: series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev4)
URL : https://patchwork.freedesktop.org/series/114868/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12911_full -> Patchwork_114868v4_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_114868v4_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_114868v4_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114868v4_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/shard-snb7/igt@i915_pm_...@reset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/shard-snb4/igt@i915_pm_...@reset.html
Known issues
Here are the changes found in Patchwork_114868v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-glk: NOTRUN -> [FAIL][5] ([i915#4767])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/shard-glk3/igt@kms_fbcon_...@fbc-suspend.html
* igt@kms_vblank@pipe-d-wait-busy-hang:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271]) +33 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/shard-glk3/igt@kms_vbl...@pipe-d-wait-busy-hang.html
Possible fixes
* igt@gem_eio@hibernate:
- {shard-tglu}: [ABORT][7] ([i915#7975]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/shard-tglu-10/igt@gem_...@hibernate.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/shard-tglu-1/igt@gem_...@hibernate.html
* igt@gem_eio@reset-stress:
- {shard-dg1}:[FAIL][9] ([i915#5784]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/shard-dg1-14/igt@gem_...@reset-stress.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/shard-dg1-15/igt@gem_...@reset-stress.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][11] ([i915#2842]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_reloc@basic-cpu-gtt:
- {shard-rkl}:[SKIP][13] ([i915#3281]) -> [PASS][14] +5 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/shard-rkl-3/igt@gem_exec_re...@basic-cpu-gtt.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/shard-rkl-5/igt@gem_exec_re...@basic-cpu-gtt.html
* igt@gem_tiled_partial_pwrite_pread@writes:
- {shard-rkl}:[SKIP][15] ([i915#3282]) -> [PASS][16] +3 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/shard-rkl-3/igt@gem_tiled_partial_pwrite_pr...@writes.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/shard-rkl-5/igt@gem_tiled_partial_pwrite_pr...@writes.html
* igt@gen9_exec_parse@batch-zero-length:
- {shard-rkl}:[SKIP][17] ([i915#2527]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/shard-rkl-3/igt@gen9_exec_pa...@batch-zero-length.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/shard-rkl-5/igt@gen9_exec_pa...@batch-zero-length.html
* igt@i915_pm_rpm@modeset-lpsp:
- {shard-dg1}:[SKIP][19] ([i915#1397]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/shard-dg1-16/igt@i915_pm_...@modeset-lpsp.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/shard-dg1-14/igt@i915_pm_...@modeset-lpsp.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-apl: [DMESG-FAIL][21] ([i915#5334]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/shard-apl7/igt@i915_selftest@live@gt_heartbeat.html
[22]:
[Intel-gfx] [PATCH i-g-t] tests/xe_guc_pc: Restore max freq first
When min/max are both at RPn, restoring min back to 300
will not work. Max needs to be increased first. Also, add
igt_assert() here, which would have caught the issue.
Cc: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
tests/xe/xe_guc_pc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/xe/xe_guc_pc.c b/tests/xe/xe_guc_pc.c
index 60c93288..43bf6f48 100644
--- a/tests/xe/xe_guc_pc.c
+++ b/tests/xe/xe_guc_pc.c
@@ -489,8 +489,8 @@ igt_main
igt_fixture {
xe_for_each_gt(fd, gt) {
- set_freq(sysfs, gt, "min", stash_min);
- set_freq(sysfs, gt, "max", stash_max);
+ igt_assert(set_freq(sysfs, gt, "max", stash_max) > 0);
+ igt_assert(set_freq(sysfs, gt, "min", stash_min) > 0);
}
close(sysfs);
xe_device_put(fd);
--
2.38.1
Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable PL1 power limit when loading GuC firmware
On 3/24/2023 4:31 PM, Dixit, Ashutosh wrote:
On Fri, 24 Mar 2023 11:15:02 -0700, Belgaumkar, Vinay wrote:
Hi Vinay,
Thanks for the review. Comments inline below.
Sorry about asking the same questions all over again :) Didn't look at
previous versions.
On 3/15/2023 8:59 PM, Ashutosh Dixit wrote:
On dGfx, the PL1 power limit being enabled and set to a low value results
in a low GPU operating freq. It also negates the freq raise operation which
is done before GuC firmware load. As a result GuC firmware load can time
out. Such timeouts were seen in the GL #8062 bug below (where the PL1 power
limit was enabled and set to a low value). Therefore disable the PL1 power
limit when allowed by HW when loading GuC firmware.
v3 label missing in subject.
v2:
- Take mutex (to disallow writes to power1_max) across GuC reset/fw load
- Add hwm_power_max_restore to error return code path
v3 (Jani N):
- Add/remove explanatory comments
- Function renames
- Type corrections
- Locking annotation
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9 +++
drivers/gpu/drm/i915/i915_hwmon.c | 39 +++
drivers/gpu/drm/i915/i915_hwmon.h | 7 +
3 files changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 4ccb4be4c9cba..aa8e35a5636a0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -18,6 +18,7 @@
#include "intel_uc.h"
#include "i915_drv.h"
+#include "i915_hwmon.h"
static const struct intel_uc_ops uc_ops_off;
static const struct intel_uc_ops uc_ops_on;
@@ -461,6 +462,7 @@ static int __uc_init_hw(struct intel_uc *uc)
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
int ret, attempts;
+ bool pl1en;
Init to 'false' here
See next comment.
GEM_BUG_ON(!intel_uc_supports_guc(uc));
GEM_BUG_ON(!intel_uc_wants_guc(uc));
@@ -491,6 +493,9 @@ static int __uc_init_hw(struct intel_uc *uc)
else
attempts = 1;
+/* Disable a potentially low PL1 power limit to allow freq to be
raised */
+ i915_hwmon_power_max_disable(gt->i915, );
+
intel_rps_raise_unslice(_to_gt(uc)->rps);
while (attempts--) {
@@ -547,6 +552,8 @@ static int __uc_init_hw(struct intel_uc *uc)
intel_rps_lower_unslice(_to_gt(uc)->rps);
}
+i915_hwmon_power_max_restore(gt->i915, pl1en);
+
guc_info(guc, "submission %s\n",
str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
guc_info(guc, "SLPC %s\n",
str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
@@ -563,6 +570,8 @@ static int __uc_init_hw(struct intel_uc *uc)
/* Return GT back to RPn */
intel_rps_lower_unslice(_to_gt(uc)->rps);
+i915_hwmon_power_max_restore(gt->i915, pl1en);
if (pl1en)
i915_hwmon_power_max_enable().
IMO it's better not to have checks in the main __uc_init_hw() function (if
we do this we'll need to add 2 checks in __uc_init_hw()). If you really
want we could do something like this inside
i915_hwmon_power_max_disable/i915_hwmon_power_max_restore. But for now I
am not making any changes.
ok.
(I can send a patch with the changes if you want to take a look but IMO it
will add more logic/code but without real benefits (it will save a rmw if
the limit was already disabled, but IMO this code is called so infrequently
(only during GuC resets) as to not have any significant impact)).
+
__uc_sanitize(uc);
if (!ret) {
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index ee63a8fd88fc1..769b5bda4d53f 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -444,6 +444,45 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int
chan, long val)
}
}
+void i915_hwmon_power_max_disable(struct drm_i915_private *i915, bool
*old)
Shouldn't we call this i915_hwmon_package_pl1_disable()?
I did think of using "pl1" in the function name but then decided to retain
"power_max" because other hwmon functions for PL1 limit also use
"power_max" (hwm_power_max_read/hwm_power_max_write) and currently
"hwmon_power_max" is mapped to the PL1 limit. So "power_max" is used to
show that all these functions deal with the PL1 power limit.
There is a comment in __uc_init_hw() explaining "power_max" means the PL1
power limit.
ok.
+ __acquires(i915->hwmon->hwmon_lock)
+{
+ struct i915_hwmon *hwmon = i915->hwmon;
+ intel_wakeref_t wakeref;
+ u32 r;
+
+ if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
+ return;
+
+ /* Take mutex to prevent concurrent hwm_power_max_write */
+ mutex_lock(>hwmon_lock);
+
+ with_intel_runtime_pm(hwmon->ddat.uncore->rpm, wakeref)
+
Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable PL1 power limit when loading GuC firmware
On Fri, 24 Mar 2023 11:15:02 -0700, Belgaumkar, Vinay wrote:
>
Hi Vinay,
Thanks for the review. Comments inline below.
> On 3/15/2023 8:59 PM, Ashutosh Dixit wrote:
> > On dGfx, the PL1 power limit being enabled and set to a low value results
> > in a low GPU operating freq. It also negates the freq raise operation which
> > is done before GuC firmware load. As a result GuC firmware load can time
> > out. Such timeouts were seen in the GL #8062 bug below (where the PL1 power
> > limit was enabled and set to a low value). Therefore disable the PL1 power
> > limit when allowed by HW when loading GuC firmware.
> v3 label missing in subject.
> >
> > v2:
> > - Take mutex (to disallow writes to power1_max) across GuC reset/fw load
> > - Add hwm_power_max_restore to error return code path
> >
> > v3 (Jani N):
> > - Add/remove explanatory comments
> > - Function renames
> > - Type corrections
> > - Locking annotation
> >
> > Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
> > Signed-off-by: Ashutosh Dixit
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9 +++
> > drivers/gpu/drm/i915/i915_hwmon.c | 39 +++
> > drivers/gpu/drm/i915/i915_hwmon.h | 7 +
> > 3 files changed, 55 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > index 4ccb4be4c9cba..aa8e35a5636a0 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > @@ -18,6 +18,7 @@
> > #include "intel_uc.h"
> > #include "i915_drv.h"
> > +#include "i915_hwmon.h"
> > static const struct intel_uc_ops uc_ops_off;
> > static const struct intel_uc_ops uc_ops_on;
> > @@ -461,6 +462,7 @@ static int __uc_init_hw(struct intel_uc *uc)
> > struct intel_guc *guc = >guc;
> > struct intel_huc *huc = >huc;
> > int ret, attempts;
> > + bool pl1en;
>
> Init to 'false' here
See next comment.
>
>
> > GEM_BUG_ON(!intel_uc_supports_guc(uc));
> > GEM_BUG_ON(!intel_uc_wants_guc(uc));
> > @@ -491,6 +493,9 @@ static int __uc_init_hw(struct intel_uc *uc)
> > else
> > attempts = 1;
> > + /* Disable a potentially low PL1 power limit to allow freq to be
> > raised */
> > + i915_hwmon_power_max_disable(gt->i915, );
> > +
> > intel_rps_raise_unslice(_to_gt(uc)->rps);
> > while (attempts--) {
> > @@ -547,6 +552,8 @@ static int __uc_init_hw(struct intel_uc *uc)
> > intel_rps_lower_unslice(_to_gt(uc)->rps);
> > }
> > + i915_hwmon_power_max_restore(gt->i915, pl1en);
> > +
> > guc_info(guc, "submission %s\n",
> > str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
> > guc_info(guc, "SLPC %s\n",
> > str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
> > @@ -563,6 +570,8 @@ static int __uc_init_hw(struct intel_uc *uc)
> > /* Return GT back to RPn */
> > intel_rps_lower_unslice(_to_gt(uc)->rps);
> > + i915_hwmon_power_max_restore(gt->i915, pl1en);
>
> if (pl1en)
>
> i915_hwmon_power_max_enable().
IMO it's better not to have checks in the main __uc_init_hw() function (if
we do this we'll need to add 2 checks in __uc_init_hw()). If you really
want we could do something like this inside
i915_hwmon_power_max_disable/i915_hwmon_power_max_restore. But for now I
am not making any changes.
(I can send a patch with the changes if you want to take a look but IMO it
will add more logic/code but without real benefits (it will save a rmw if
the limit was already disabled, but IMO this code is called so infrequently
(only during GuC resets) as to not have any significant impact)).
>
> > +
> > __uc_sanitize(uc);
> > if (!ret) {
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > b/drivers/gpu/drm/i915/i915_hwmon.c
> > index ee63a8fd88fc1..769b5bda4d53f 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -444,6 +444,45 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr,
> > int chan, long val)
> > }
> > }
> > +void i915_hwmon_power_max_disable(struct drm_i915_private *i915, bool
> > *old)
> Shouldn't we call this i915_hwmon_package_pl1_disable()?
I did think of using "pl1" in the function name but then decided to retain
"power_max" because other hwmon functions for PL1 limit also use
"power_max" (hwm_power_max_read/hwm_power_max_write) and currently
"hwmon_power_max" is mapped to the PL1 limit. So "power_max" is used to
show that all these functions deal with the PL1 power limit.
There is a comment in __uc_init_hw() explaining "power_max" means the PL1
power limit.
> > + __acquires(i915->hwmon->hwmon_lock)
> > +{
> > + struct i915_hwmon *hwmon = i915->hwmon;
> > + intel_wakeref_t wakeref;
> > + u32 r;
> > +
> > + if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
> > + return;
> > +
> > + /* Take mutex to prevent concurrent hwm_power_max_write */
> > +
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/overlay: Remove redundant drm_rect_visible() use
== Series Details ==
Series: drm/i915/overlay: Remove redundant drm_rect_visible() use
URL : https://patchwork.freedesktop.org/series/115605/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12910_full -> Patchwork_115605v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 7)
--
Missing(1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115605v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@perf@gen12-invalid-class-instance}:
- {shard-rkl}:NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-rkl-3/igt@p...@gen12-invalid-class-instance.html
* {igt@perf@oa-exponents@0-rcs0}:
- shard-glk: [PASS][2] -> [ABORT][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-glk9/igt@perf@oa-expone...@0-rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-glk6/igt@perf@oa-expone...@0-rcs0.html
Known issues
Here are the changes found in Patchwork_115605v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [PASS][4] -> [FAIL][5] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_lmem_swapping@heavy-multi:
- shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-apl1/igt@gem_lmem_swapp...@heavy-multi.html
* igt@gem_render_copy@x-tiled-to-vebox-yf-tiled:
- shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271]) +90 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-apl6/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [PASS][8] -> [ABORT][9] ([i915#5566])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-apl2/igt@gen9_exec_pa...@allowed-all.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-apl4/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3886])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-apl1/igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs.html
* igt@kms_content_protection@atomic-dpms@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][11] ([i915#7173])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-apl6/igt@kms_content_protection@atomic-d...@pipe-a-dp-1.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#658])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-apl1/igt@kms_psr2...@primary-plane-update-sf-dmg-area.html
Possible fixes
* igt@fbdev@nullptr:
- {shard-rkl}:[SKIP][13] ([i915#2582]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-rkl-2/igt@fb...@nullptr.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-rkl-6/igt@fb...@nullptr.html
* igt@fbdev@pan:
- {shard-tglu}: [SKIP][15] ([i915#2582]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-tglu-10/igt@fb...@pan.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-tglu-7/igt@fb...@pan.html
* igt@gem_busy@close-race:
- shard-apl: [ABORT][17] ([i915#6016]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-apl6/igt@gem_b...@close-race.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-apl1/igt@gem_b...@close-race.html
* igt@gem_eio@in-flight-immediate:
- {shard-rkl}:[ABORT][19] ([i915#7811]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-rkl-4/igt@gem_...@in-flight-immediate.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-rkl-2/igt@gem_...@in-flight-immediate.html
* igt@gem_eio@reset-stress:
- {shard-dg1}:[FAIL][21] ([i915#5784]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-dg1-18/igt@gem_...@reset-stress.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/shard-dg1-14/igt@gem_...@reset-stress.html
*
[Intel-gfx] [PATCH i-g-t 1/2] lib/debugfs: Add per GT debugfs helpers
These can be used to open per-gt debugfs files.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Vinay Belgaumkar
---
lib/igt_debugfs.c | 60 +++
lib/igt_debugfs.h | 4
2 files changed, 64 insertions(+)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 05889bbe..afde2da6 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -217,6 +217,37 @@ int igt_debugfs_dir(int device)
return open(path, O_RDONLY);
}
+/**
+ * igt_debugfs_gt_dir:
+ * @device: fd of the device
+ * @gt: GT instance number
+ *
+ * This opens the debugfs directory corresponding to device for use
+ * with igt_sysfs_get() and related functions.
+ *
+ * Returns:
+ * The directory fd, or -1 on failure.
+ */
+int igt_debugfs_gt_dir(int device, unsigned int gt)
+{
+ int debugfs_gt_dir_fd;
+ char path[PATH_MAX];
+ char gtpath[16];
+ int ret;
+
+ if (!igt_debugfs_path(device, path, sizeof(path)))
+ return -1;
+
+ ret = snprintf(gtpath, sizeof(gtpath), "/gt%u", gt);
+ igt_assert(ret < sizeof(gtpath));
+ strncat(path, gtpath, sizeof(path) - 1);
+
+ debugfs_gt_dir_fd = open(path, O_RDONLY);
+ igt_debug_on_f(debugfs_gt_dir_fd < 0, "path: %s\n", path);
+
+ return debugfs_gt_dir_fd;
+}
+
/**
* igt_debugfs_connector_dir:
* @device: fd of the device
@@ -313,6 +344,35 @@ bool igt_debugfs_exists(int device, const char *filename,
int mode)
return false;
}
+/**
+ * igt_debugfs_gt_open:
+ * @device: open i915 drm fd
+ * @gt: gt instance number
+ * @filename: name of the debugfs node to open
+ * @mode: mode bits as used by open()
+ *
+ * This opens a debugfs file as a Unix file descriptor. The filename should be
+ * relative to the drm device's root, i.e. without "drm/$minor".
+ *
+ * Returns:
+ * The Unix file descriptor for the debugfs file or -1 if that didn't work out.
+ */
+int
+igt_debugfs_gt_open(int device, unsigned int gt, const char *filename, int
mode)
+{
+ int dir, ret;
+
+ dir = igt_debugfs_gt_dir(device, gt);
+ if (dir < 0)
+ return dir;
+
+ ret = openat(dir, filename, mode);
+
+ close(dir);
+
+ return ret;
+}
+
/**
* igt_debugfs_simple_read:
* @dir: fd of the debugfs directory
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
index 4824344a..3e6194ad 100644
--- a/lib/igt_debugfs.h
+++ b/lib/igt_debugfs.h
@@ -45,6 +45,10 @@ void __igt_debugfs_write(int fd, const char *filename, const
char *buf, int size
int igt_debugfs_simple_read(int dir, const char *filename, char *buf, int
size);
bool igt_debugfs_search(int fd, const char *filename, const char *substring);
+int igt_debugfs_gt_dir(int device, unsigned int gt);
+int igt_debugfs_gt_open(int device, unsigned int gt, const char *filename,
+ int mode);
+
/**
* igt_debugfs_read:
* @filename: name of the debugfs file
--
2.38.1
[Intel-gfx] [PATCH i-g-t 2/2] i915_guc_pc: Add some basic SLPC igt tests
Use the xe_guc_pc test for i915 as well. Validate basic
api for GT freq control. Also test interaction with GT
reset. We skip rps tests with SLPC enabled, this will
re-introduce some coverage. SLPC selftests are already
covering some other workload related scenarios.
Signed-off-by: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
tests/i915/i915_guc_pc.c | 151 +++
tests/meson.build| 1 +
2 files changed, 152 insertions(+)
create mode 100644 tests/i915/i915_guc_pc.c
diff --git a/tests/i915/i915_guc_pc.c b/tests/i915/i915_guc_pc.c
new file mode 100644
index ..f9a0ed83
--- /dev/null
+++ b/tests/i915/i915_guc_pc.c
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drmtest.h"
+#include "i915/gem.h"
+#include "igt_sysfs.h"
+#include "igt.h"
+
+IGT_TEST_DESCRIPTION("Test GuC PM features like SLPC and its interactions");
+/*
+ * Too many intermediate components and steps before freq is adjusted
+ * Specially if workload is under execution, so let's wait 100 ms.
+ */
+#define ACT_FREQ_LATENCY_US 10
+
+static uint32_t get_freq(int dirfd, uint8_t id)
+{
+ uint32_t val;
+
+ igt_require(igt_sysfs_rps_scanf(dirfd, id, "%u", ) == 1);
+
+ return val;
+}
+
+static int set_freq(int dirfd, uint8_t id, uint32_t val)
+{
+ return igt_sysfs_rps_printf(dirfd, id, "%u", val);
+}
+
+static void test_freq_basic_api(int dirfd, int gt)
+{
+ uint32_t rpn, rp0, rpe;
+
+ /* Save frequencies */
+ rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
+ rp0 = get_freq(dirfd, RPS_RP0_FREQ_MHZ);
+ rpe = get_freq(dirfd, RPS_RP1_FREQ_MHZ);
+ igt_info("System min freq: %dMHz; max freq: %dMHz\n", rpn, rp0);
+
+ /*
+* Negative bound tests
+* RPn is the floor
+* RP0 is the ceiling
+*/
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn - 1) < 0);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rp0 + 1) < 0);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn - 1) < 0);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rp0 + 1) < 0);
+
+ /* Assert min requests are respected from rp0 to rpn */
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rp0) > 0);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rp0);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpe) > 0);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpe);
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpn);
+
+ /* Assert max requests are respected from rpn to rp0 */
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rpn);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpe) > 0);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rpe);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rp0) > 0);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rp0);
+
+}
+
+static void test_reset(int i915, int dirfd, int gt)
+{
+ uint32_t rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
+ int fd;
+
+ igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
+ igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0);
+ usleep(ACT_FREQ_LATENCY_US);
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpn);
+
+ /* Manually trigger a GT reset */
+ fd = igt_debugfs_gt_open(i915, gt, "reset", O_WRONLY);
+ igt_require(fd >= 0);
+ igt_ignore_warn(write(fd, "1\n", 2));
+ close(fd);
+
+ igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) == rpn);
+ igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) == rpn);
+}
+
+igt_main
+{
+ int i915 = -1;
+ uint32_t *stash_min, *stash_max;
+
+ igt_fixture {
+ int num_gts, dirfd, gt;
+
+ i915 = drm_open_driver(DRIVER_INTEL);
+ igt_require_gem(i915);
+ /* i915_pm_rps already covers execlist path */
+ igt_require(gem_using_guc_submission(i915));
+
+ num_gts = igt_sysfs_get_num_gt(i915);
+ stash_min = (uint32_t*)malloc(sizeof(uint32_t) * num_gts);
+ stash_max = (uint32_t*)malloc(sizeof(uint32_t) * num_gts);
+
+ /* Save curr min and max across GTs */
+ for_each_sysfs_gt_dirfd(i915, dirfd, gt) {
+ stash_min[gt] = get_freq(dirfd, RPS_MIN_FREQ_MHZ);
+ stash_max[gt] = get_freq(dirfd, RPS_MAX_FREQ_MHZ);
+ }
+ }
+
+ igt_describe("Test basic API for controlling min/max GT frequency");
+ igt_subtest_with_dynamic_f("freq-basic-api") {
+ int dirfd, gt;
+
+ for_each_sysfs_gt_dirfd(i915, dirfd, gt)
+ igt_dynamic_f("gt%u", gt)
+
[Intel-gfx] [PATCH i-g-t 0/2] tests/i915/slpc: Add basic IGT test
Borrow some subtests from xe_guc_pc. Also add per GT debugfs helpers. Signed-off-by: Vinay Belgaumkar Vinay Belgaumkar (2): lib/debugfs: Add per GT debugfs helpers i915_guc_pc: Add some basic SLPC igt tests lib/igt_debugfs.c| 60 lib/igt_debugfs.h| 4 ++ tests/i915/i915_guc_pc.c | 151 +++ tests/meson.build| 1 + 4 files changed, 216 insertions(+) create mode 100644 tests/i915/i915_guc_pc.c -- 2.38.1
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Implement UHBR bandwidth check (rev3)
== Series Details ==
Series: drm/i915: Implement UHBR bandwidth check (rev3)
URL : https://patchwork.freedesktop.org/series/112806/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12910_full -> Patchwork_112806v3_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_112806v3_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_112806v3_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (8 -> 7)
--
Missing(1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112806v3_full:
### IGT changes ###
Warnings
* igt@kms_hdr@static-toggle:
- shard-snb: [SKIP][1] ([fdo#109271]) -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-snb2/igt@kms_...@static-toggle.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-snb2/igt@kms_...@static-toggle.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@perf@gen12-invalid-class-instance}:
- {shard-rkl}:NOTRUN -> [SKIP][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-rkl-1/igt@p...@gen12-invalid-class-instance.html
Known issues
Here are the changes found in Patchwork_112806v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_render_copy@x-tiled-to-vebox-yf-tiled:
- shard-apl: NOTRUN -> [SKIP][4] ([fdo#109271]) +49 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-apl1/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: NOTRUN -> [ABORT][5] ([i915#5566])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-apl1/igt@gen9_exec_pa...@allowed-single.html
- shard-glk: [PASS][6] -> [ABORT][7] ([i915#5566])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-glk3/igt@gen9_exec_pa...@allowed-single.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-glk2/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-glk: [PASS][8] -> [DMESG-FAIL][9] ([i915#5334])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-glk7/igt@i915_selftest@live@gt_heartbeat.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-glk9/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_content_protection@atomic-dpms@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][10] ([i915#7173])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-apl1/igt@kms_content_protection@atomic-d...@pipe-a-dp-1.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-glk: [PASS][11] -> [DMESG-FAIL][12] ([i915#118])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-glk2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-move.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-glk5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-move.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][13] ([i915#7742]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-rkl-3/igt@drm_fdi...@virtual-idle.html
* igt@fbdev@eof:
- {shard-rkl}:[SKIP][15] ([i915#2582]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-rkl-4/igt@fb...@eof.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-rkl-6/igt@fb...@eof.html
* igt@fbdev@pan:
- {shard-tglu}: [SKIP][17] ([i915#2582]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-tglu-10/igt@fb...@pan.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-tglu-3/igt@fb...@pan.html
* igt@feature_discovery@psr1:
- {shard-rkl}:[SKIP][19] ([i915#658]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-rkl-3/igt@feature_discov...@psr1.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/shard-rkl-6/igt@feature_discov...@psr1.html
* igt@gem_busy@close-race:
- shard-apl: [ABORT][21] ([i915#6016]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/shard-apl6/igt@gem_b...@close-race.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Disable C6 on MTL A0 for media (rev3)
== Series Details == Series: drm/i915/mtl: Disable C6 on MTL A0 for media (rev3) URL : https://patchwork.freedesktop.org/series/115610/ State : success == Summary == CI Bug Log - changes from CI_DRM_12913 -> Patchwork_115610v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/index.html Participating hosts (37 -> 36) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_115610v3 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0@smem: - bat-rpls-2: [PASS][1] -> [ABORT][2] ([i915#6687]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][3] -> [ABORT][4] ([i915#7911] / [i915#7913]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@kms_pipe_crc_basic@read-crc: - bat-dg2-11: NOTRUN -> [SKIP][5] ([i915#5354]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/bat-dg2-11/igt@kms_pipe_crc_ba...@read-crc.html Possible fixes * igt@i915_pm_rps@basic-api: - bat-dg2-11: [FAIL][6] ([i915#8308]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/bat-dg2-11/igt@i915_pm_...@basic-api.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/bat-dg2-11/igt@i915_pm_...@basic-api.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-FAIL][8] ([i915#6997] / [i915#7913]) -> [DMESG-FAIL][9] ([i915#6367] / [i915#7913] / [i915#7996]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12913/bat-rpls-2/igt@i915_selftest@l...@slpc.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308 Build changes - * Linux: CI_DRM_12913 -> Patchwork_115610v3 CI-20190529: 20190529 CI_DRM_12913: df699b6b571efc8cc0342135aedc31935c3ab253 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7218: 8036123f781059c54a31240756794b17bd3d15dc @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115610v3: df699b6b571efc8cc0342135aedc31935c3ab253 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 542710b986f8 drm/i915/mtl: Disable C6 on MTL A0 for media == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v3/index.html
Re: [Intel-gfx] [PATCH] drm/i915/overlay: Remove redundant drm_rect_visible() use
On Fri, Mar 24, 2023 at 11:25:33AM -0300, Arthur Grillo wrote: > The drm_rect_intersect() already returns if the intersection is visible > or not, so the use of drm_rect_visible() is duplicate. > > Signed-off-by: Arthur Grillo > --- > drivers/gpu/drm/i915/display/intel_overlay.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c > b/drivers/gpu/drm/i915/display/intel_overlay.c > index c12bdca8da9b..444d88f418c5 100644 > --- a/drivers/gpu/drm/i915/display/intel_overlay.c > +++ b/drivers/gpu/drm/i915/display/intel_overlay.c > @@ -966,9 +966,8 @@ static int check_overlay_dst(struct intel_overlay > *overlay, > rec->dst_width, rec->dst_height); > > clipped = req; > - drm_rect_intersect(, _state->pipe_src); > > - if (!drm_rect_visible() || > + if (!drm_rect_intersect(, _state->pipe_src) || > !drm_rect_equals(, )) Hmm. I think I like the original a bit better because there is no hard to spot dependency between the two sides of the ||. I suppose another option would to to replace the || with two separate if statements. > return -EINVAL; > > -- > 2.39.2 -- Ville Syrjälä Intel
[Intel-gfx] [PATCH] drm/i915/mtl: Disable C6 on MTL A0 for media
Earlier merge dropped an if block when applying the patch -
"drm/i915/mtl: Synchronize i915/BIOS on C6 enabling". Bring back the
if block as the check is required by - "drm/i915/mtl: Disable MC6 for MTL
A step" to disable C6 on media for A0 stepping.
Fixes: 3735040978a4 ("drm/i915/mtl: Synchronize i915/BIOS on C6 enabling")
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index f760586f9f46..8f3cd68d14f8 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -525,6 +525,13 @@ static bool rc6_supported(struct intel_rc6 *rc6)
return false;
}
+ if (IS_MTL_MEDIA_STEP(gt->i915, STEP_A0, STEP_B0) &&
+ gt->type == GT_MEDIA) {
+ drm_notice(>drm,
+ "Media RC6 disabled on A step\n");
+ return false;
+ }
+
return true;
}
--
2.36.1
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/hdcp: Pull HDCP auth/exchange/check into helpers (rev7)
== Series Details == Series: drm/hdcp: Pull HDCP auth/exchange/check into helpers (rev7) URL : https://patchwork.freedesktop.org/series/94712/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/94712/revisions/7/mbox/ not applied Applying: drm/hdcp: Add drm_hdcp_atomic_check() Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/display/intel_atomic.c M drivers/gpu/drm/i915/display/intel_hdcp.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/display/intel_hdcp.c Auto-merging drivers/gpu/drm/i915/display/intel_atomic.c Applying: drm/hdcp: Avoid changing crtc state in hdcp atomic check Applying: drm/hdcp: Update property value on content type and user changes Applying: drm/hdcp: Expand HDCP helper library for enable/disable/check Applying: drm/i915/hdcp: Consolidate HDCP setup/state cache Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/display/intel_hdcp.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/display/intel_hdcp.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_hdcp.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0005 drm/i915/hdcp: Consolidate HDCP setup/state cache 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". Build failed, no error log produced
Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
On Thu, Feb 23, 2023 at 06:47:27AM -0300, Kahola, Mika wrote:
> > -Original Message-
> > From: Sousa, Gustavo
> > Sent: Tuesday, February 7, 2023 6:54 PM
> > To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> > Cc: Nikula, Jani
> > Subject: Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
> >
> > On Thu, Jan 05, 2023 at 02:54:34PM +0200, Mika Kahola wrote:
> > > Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> > > The PLL settings are based on table, not for algorithmic alternative.
> > > For DP 1.4 only MPLLB is in use.
> > >
> > > Once register settings are done, we read back C20 HW state.
> > >
> > > BSpec: 64568
> > >
> > > v2: Update rbr, hbr1, hbr2, and hbr3 pll configurations 4 and 5
> > > based on changes in BSpec consolidated table
> > >
> > > Signed-off-by: Mika Kahola
> > > Link:
> > > https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-10
> > > -mika.kah...@intel.com
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 495
> > > ++- drivers/gpu/drm/i915/display/intel_cx0_phy.h | 10 +-
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 9 +-
> > > drivers/gpu/drm/i915/display/intel_hdmi.c| 6 +-
> > > drivers/gpu/drm/i915/display/intel_hdmi.h| 1 +
> > > 5 files changed, 513 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > index 022888050a68..285e4cdd23eb 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > @@ -11,6 +11,7 @@
> > > #include "intel_de.h"
> > > #include "intel_display_types.h"
> > > #include "intel_dp.h"
> > > +#include "intel_hdmi.h"
> > > #include "intel_panel.h"
> > > #include "intel_psr.h"
> > > #include "intel_uncore.h"
> > > @@ -247,6 +248,23 @@ static void intel_c20_write(struct drm_i915_private
> > *i915, enum port port,
> > > intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff,
> > > 1); }
> > >
> > > +static u16 intel_c20_read(struct drm_i915_private *i915, enum port port,
> > > + int lane, u16 addr)
> >
> > Similar to my comment for intel_c20_write(), I think it would be better to
> > name
> > this function intel_c20_sram_read().
>
> We can rename these read/writes differently.
> >
> > Also, this function is indented with spaces instead of tabs.
> This comes from copy-paste error. Thanks for spotting!
>
> >
> > > +{
> > > + u16 val;
> > > +
> > > + assert_dc_off(i915);
> > > +
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr &
> > > 0xff,
> > 0);
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, (addr
> > > + >> 8) & 0xff, 1);
> >
> > Looks like the 0xff maks is unnecessary here.
> Ok.
>
> >
> > Also, does the byte order matter here? The diagram for the read operation in
> > the BSpec suggests writing the higher part of the address first and then the
> > lower part.
> I don't think it matters here but to be aligned with the spec we could swap
> these writes.
>
> >
> > > +
> > > + val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
> > > + val <<= 8;
> > > + val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
> > > +
> > > +return val;
> > > +}
> > > +
> > > static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port
> > > port,
> > > int lane, u16 addr, u8 clear, u8 set, bool
> > > committed) {
> > @@
> > > -588,6 +606,192 @@ static const struct intel_c10mpllb_state * const
> > mtl_c10_edp_tables[] = {
> > > NULL,
> > > };
> > >
> > > +/* C20 basic DP 1.4 tables */
> > > +static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> > > + .clock = 162000,
> > > + .tx = { 0xbe88, /* tx cfg0 */
> > > + 0x5800, /* tx cfg1 */
> > > + 0x, /* tx cfg2 */
> > > + },
> > > + .cmn = {0x0500, /* cmn cfg0*/
> > > + 0x0005, /* cmn cfg1 */
> > > + 0x, /* cmn cfg2 */
> > > + 0x, /* cmn cfg3 */
> > > + },
> > > + .mpllb = { 0x50a8, /* mpllb cfg0 */
> > > + 0x2120, /* mpllb cfg1 */
> > > + 0xcd9a, /* mpllb cfg2 */
> > > + 0xbfc1, /* mpllb cfg3 */
> > > + 0x5ab8, /* mpllb cfg4 */
> > > + 0x4c34, /* mpllb cfg5 */
> > > + 0x2000, /* mpllb cfg6 */
> > > + 0x0001, /* mpllb cfg7 */
> > > + 0x6000, /* mpllb cfg8 */
> > > + 0x, /* mpllb cfg9 */
> > > + 0x, /* mpllb cfg10 */
> > > + },
> > > +};
> > > +
> > > +static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
> > > + .clock = 27,
> > > + .tx = { 0xbe88, /* tx cfg0 */
> > > + 0x4800, /* tx cfg1 */
> > > + 0x, /* tx cfg2 */
> > > + },
> > > + .cmn = {0x0500, /* cmn cfg0*/
> > > +
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Disable C6 on MTL A0 for media (rev2)
== Series Details == Series: drm/i915/mtl: Disable C6 on MTL A0 for media (rev2) URL : https://patchwork.freedesktop.org/series/115610/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12912 -> Patchwork_115610v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_115610v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_115610v2, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/index.html Participating hosts (38 -> 36) -- Missing(2): fi-kbl-soraka fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_115610v2: ### IGT changes ### Possible regressions * igt@i915_selftest@live@objects: - bat-atsm-1: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12912/bat-atsm-1/igt@i915_selftest@l...@objects.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/bat-atsm-1/igt@i915_selftest@l...@objects.html Known issues Here are the changes found in Patchwork_115610v2 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-2: NOTRUN -> [ABORT][3] ([i915#6687] / [i915#7978]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [PASS][4] -> [DMESG-FAIL][5] ([i915#5334]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12912/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@hangcheck: - bat-dg2-11: [PASS][6] -> [ABORT][7] ([i915#7913]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12912/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - bat-rpls-1: [PASS][8] -> [ABORT][9] ([i915#4983] / [i915#7911]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12912/bat-rpls-1/igt@i915_selftest@l...@requests.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][10] ([i915#6367] / [i915#7913] / [i915#7996]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/bat-rpls-2/igt@i915_selftest@l...@slpc.html - bat-adln-1: NOTRUN -> [DMESG-FAIL][11] ([i915#6997]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/bat-adln-1/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-adln-1: NOTRUN -> [SKIP][12] ([i915#7828]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/bat-adln-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][13] ([i915#5354]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html Possible fixes * igt@i915_selftest@live@gt_lrc: - bat-adln-1: [INCOMPLETE][14] ([i915#4983] / [i915#7609]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12912/bat-adln-1/igt@i915_selftest@live@gt_lrc.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/bat-adln-1/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@reset: - bat-rpls-2: [ABORT][16] ([i915#4983] / [i915#7913]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12912/bat-rpls-2/igt@i915_selftest@l...@reset.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-hdmi-a-2: - bat-dg1-5: [FAIL][18] ([fdo#103375]) -> [PASS][19] +4 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12912/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v2/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
Re: [Intel-gfx] [PATCH v5 09/22] drm/i915/mtl: C20 HW readout
On Thu, Mar 16, 2023 at 01:13:22PM +0200, Mika Kahola wrote:
> Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> The PLL settings are based on table, not for algorithmic alternative.
> For DP 1.4 only MPLLB is in use.
>
> Once register settings are done, we read back C20 HW state.
>
> BSpec: 64568
>
> v2: Update rbr, hbr1, hbr2, and hbr3 pll configurations 4 and 5
> based on changes in BSpec consolidated table
> v3: Rename intel_c20_read() to intel_c20_sram_read() (Gustavo)
> Use context and correct MPLLA reg bit to select if MPLLA is in
> use or not (Gustavo)
>
> Signed-off-by: Mika Kahola
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 553 ++-
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 8 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 9 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c| 6 +-
> drivers/gpu/drm/i915/display/intel_hdmi.h| 1 +
> 5 files changed, 569 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 730c70f82822..bfb264ea154a 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -11,6 +11,7 @@
> #include "intel_de.h"
> #include "intel_display_types.h"
> #include "intel_dp.h"
> +#include "intel_hdmi.h"
> #include "intel_panel.h"
> #include "intel_tc.h"
> #include "intel_psr.h"
> @@ -248,6 +249,23 @@ static void intel_c20_sram_write(struct drm_i915_private
> *i915, enum port port,
> intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
> }
>
> +static u16 intel_c20_sram_read(struct drm_i915_private *i915, enum port port,
> + int lane, u16 addr)
> +{
> + u16 val;
> +
> + assert_dc_off(i915);
> +
> + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, (addr >> 8), 1);
> + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr & 0xff, 0);
Now that we have swapped the order of these writes, we should also swap the 1
and 0 passed as arguments to the "committed" parameter.
--
Gustavo Sousa
> +
> + val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
> + val <<= 8;
> + val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
> +
> + return val;
> +}
> +
> static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
> int lane, u16 addr, u8 clear, u8 set, bool
> committed)
> {
> @@ -598,6 +616,192 @@ static const struct intel_c10mpllb_state * const
> mtl_c10_edp_tables[] = {
> NULL,
> };
>
> +/* C20 basic DP 1.4 tables */
> +static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> + .clock = 162000,
> + .tx = { 0xbe88, /* tx cfg0 */
> + 0x5800, /* tx cfg1 */
> + 0x, /* tx cfg2 */
> + },
> + .cmn = {0x0500, /* cmn cfg0*/
> + 0x0005, /* cmn cfg1 */
> + 0x, /* cmn cfg2 */
> + 0x, /* cmn cfg3 */
> + },
> + .mpllb = { 0x50a8, /* mpllb cfg0 */
> + 0x2120, /* mpllb cfg1 */
> + 0xcd9a, /* mpllb cfg2 */
> + 0xbfc1, /* mpllb cfg3 */
> + 0x5ab8, /* mpllb cfg4 */
> + 0x4c34, /* mpllb cfg5 */
> + 0x2000, /* mpllb cfg6 */
> + 0x0001, /* mpllb cfg7 */
> + 0x6000, /* mpllb cfg8 */
> + 0x, /* mpllb cfg9 */
> + 0x, /* mpllb cfg10 */
> + },
> +};
> +
> +static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
> + .clock = 27,
> + .tx = { 0xbe88, /* tx cfg0 */
> + 0x4800, /* tx cfg1 */
> + 0x, /* tx cfg2 */
> + },
> + .cmn = {0x0500, /* cmn cfg0*/
> + 0x0005, /* cmn cfg1 */
> + 0x, /* cmn cfg2 */
> + 0x, /* cmn cfg3 */
> + },
> + .mpllb = { 0x308c, /* mpllb cfg0 */
> + 0x2110, /* mpllb cfg1 */
> + 0xcc9c, /* mpllb cfg2 */
> + 0xbfc1, /* mpllb cfg3 */
> + 0x489a, /* mpllb cfg4 */
> + 0x3f81, /* mpllb cfg5 */
> + 0x2000, /* mpllb cfg6 */
> + 0x0001, /* mpllb cfg7 */
> + 0x5000, /* mpllb cfg8 */
> + 0x, /* mpllb cfg9 */
> + 0x, /* mpllb cfg10 */
> + },
> +};
> +
> +static const struct intel_c20pll_state mtl_c20_dp_hbr2 = {
> + .clock = 54,
> + .tx = { 0xbe88, /* tx cfg0 */
> + 0x4800, /* tx cfg1 */
> + 0x, /* tx cfg2 */
> + },
> + .cmn = {0x0500, /* cmn cfg0*/
> + 0x0005, /* cmn cfg1 */
> + 0x, /* cmn cfg2 */
> + 0x, /* cmn
Re: [Intel-gfx] [PULL] drm-intel-next
On Thu, Mar 23, 2023 at 04:43:22PM -0400, Rodrigo Vivi wrote: > Hi Daniel, > > Here goes drm-intel-next-2023-03-23: > > Core Changes: > - drm: Add SDP Error Detection Configuration Register (Arun) > > Driver Changes: > - Meteor Lake enabling and fixes (RK, Jose, Madhumitha) > - Lock the fbdev obj before vma pin (Tejas) > - DSC fixes (Stanislav) > - Fixes and clean-up on opregion code (Imre) > - More wm/vblank stuff (Ville) > - More general display code organization (Jani) > - DP Fixes (Stanislav, Ville) > - Introduce flags to ignore long HPD and link training issues \ > for handling spurious issues on CI (Vinod) > - Plane cleanups and extra registers (Ville) > - Update audio keepalive clock values (Clint) > - Rename find_section to bdb_find_section (Maarten) > - DP SDP CRC16 for 128b132b link layer (Arun) > - Fix various issues with noarm register writes (Ville) > - Fix a few TypeC / MST issues (Imre) > - Create GSC submission targeting HDCP and PXP usages on MTL+ (Suraj) > - Enable HDCP2.x via GSC CS (Suraj) > > Thanks, > Rodrigo. > > The following changes since commit 4b736ed40583631e0cf32c55dbc1e5ec0434a74b: > > drm/i915: Get rid of the gm45 HPD live state nonsense (2023-03-07 19:09:20 > +0200) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-03-23 Pulled, thanks. > > for you to fetch changes up to 883631771038d1b0c10c0929e31bbd5ffb5e682c: > > drm/i915/mtl: Add HDCP GSC interface (2023-03-23 12:17:22 +0530) > > > Core Changes: > - drm: Add SDP Error Detection Configuration Register (Arun) > > Driver Changes: > - Meteor Lake enabling and fixes (RK, Jose, Madhumitha) > - Lock the fbdev obj before vma pin (Tejas) > - DSC fixes (Stanislav) > - Fixes and clean-up on opregion code (Imre) > - More wm/vblank stuff (Ville) > - More general display code organization (Jani) > - DP Fixes (Stanislav, Ville) > - Introduce flags to ignore long HPD and link training issues \ > for handling spurious issues on CI (Vinod) > - Plane cleanups and extra registers (Ville) > - Update audio keepalive clock values (Clint) > - Rename find_section to bdb_find_section (Maarten) > - DP SDP CRC16 for 128b132b link layer (Arun) > - Fix various issues with noarm register writes (Ville) > - Fix a few TypeC / MST issues (Imre) > - Create GSC submission targeting HDCP and PXP usages on MTL+ (Suraj) > - Enable HDCP2.x via GSC CS (Suraj) > > > Ankit Nautiyal (1): > drm/i915/dp: Don't roundup max bpp, while computing compressed bpp > > Anshuman Gupta (1): > drm/i915/hdcp: Use generic names for HDCP helpers and structs > > Arun R Murthy (2): > drm: Add SDP Error Detection Configuration Register > i915/display/dp: SDP CRC16 for 128b132b link layer > > Clint Taylor (1): > drm/i915/audio: update audio keepalive clock values > > Imre Deak (18): > drm/i915/opregion: Fix opregion setup during system resume on platforms > without display > drm/i915/opregion: Cleanup opregion after errors during driver loading > drm/i915/opregion: Register display debugfs later, after initialization > steps > drm/i915/opregion: Fix CONFIG_ACPI=n builds adding missing > intel_opregion_cleanup() prototype > drm/i915/tc: Abort DP AUX transfer on a disconnected TC port > drm/i915/tc: Fix TC port link ref init for DP MST during HW readout > drm/i915/tc: Fix the ICL PHY ownership check in TC-cold state > drm/i915/tc: Fix system resume MST mode restore for DP-alt sinks > drm/i915/tc: Wait for IOM/FW PHY initialization of legacy TC ports > drm/i915/tc: Factor out helpers converting HPD mask to TC mode > drm/i915/tc: Fix target TC mode for a disconnected legacy port > drm/i915/tc: Fix TC mode for a legacy port if the PHY is not ready > drm/i915/tc: Fix initial TC mode on disabled legacy ports > drm/i915/tc: Make the TC mode readout consistent in all PHY states > drm/i915/tc: Assume a TC port is legacy if VBT says the port has HDMI > drm/i915: Add encoder hook to get the PLL type used by TC ports > drm/i915/tc: Factor out a function querying active links on a TC port > drm/i915/tc: Check the PLL type used by an enabled TC port > > Jani Nikula (6): > drm/i915/debugfs: move IPS debugfs to hsw_ips.c > drm/i915/psr: move PSR debugfs to intel_psr.c > drm/i915/psr: switch PSR debugfs to struct intel_connector > drm/i915/psr: clean up PSR debugfs sink status error handling > drm/i915/debugfs: switch crtc debugfs to struct intel_crtc > drm/i915/debugfs: add crtc i915_pipe debugfs file > > José Roberto de Souza (1): > drm/i915/display/mtl: Program latch to phy reset > > Maarten Lankhorst (1): > drm/i915/bios: Rename find_section to find_bdb_section > > Madhumitha
Re: [Intel-gfx] [PATCH v5 08/22] drm/i915/mtl: C20 PLL programming
On Thu, Mar 16, 2023 at 01:13:21PM +0200, Mika Kahola wrote:
> C20 phy PLL programming sequence for DP, DP2.0, HDMI2.x non-FRL and
> HDMI2.x FRL. This enables C20 MPLLA and MPLLB programming sequence. add
> 4 lane support for c20.
>
> v2: Rename intel_c20_write() to intel_c20_sram_write() (Gustavo)
> Remove unnecessary bit masks (Gustavo)
> Fix comments on C20 pll programming (Gustavo)
> Clear calibration banks for both lanes (Gustavo)
>
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Mika Kahola
> Signed-off-by: Bhanuprakash Modem
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 266 +++---
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 30 ++
> drivers/gpu/drm/i915/display/intel_ddi.c | 11 +-
> .../drm/i915/display/intel_display_types.h| 19 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 12 +-
> 5 files changed, 298 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 3d61afbe7bdb..730c70f82822 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -15,6 +15,7 @@
> #include "intel_tc.h"
> #include "intel_psr.h"
> #include "intel_uncore.h"
> +#include "intel_tc.h"
>
> bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
> {
> @@ -235,6 +236,18 @@ static void intel_cx0_write(struct drm_i915_private
> *i915, enum port port,
> }
> }
>
> +static void intel_c20_sram_write(struct drm_i915_private *i915, enum port
> port,
> + int lane, u16 addr, u16 data)
> +{
> + assert_dc_off(i915);
> +
> + intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_H, (addr >> 8), 0);
> + intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_L, addr & 0xff, 0);
> +
> + intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_H, (data >> 8), 0);
> + intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
> +}
> +
> static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
> int lane, u16 addr, u8 clear, u8 set, bool
> committed)
> {
> @@ -1157,7 +1170,7 @@ static int intel_c10mpllb_calc_state(struct
> intel_crtc_state *crtc_state,
>
> for (i = 0; tables[i]; i++) {
> if (crtc_state->port_clock <= tables[i]->clock) {
> - crtc_state->c10mpllb_state = *tables[i];
> + crtc_state->cx0pll_state.c10mpllb_state = *tables[i];
> return 0;
> }
> }
> @@ -1217,7 +1230,7 @@ static void intel_c10_pll_program(struct
> drm_i915_private *i915,
> const struct intel_crtc_state *crtc_state,
> struct intel_encoder *encoder)
> {
> - const struct intel_c10mpllb_state *pll_state =
> _state->c10mpllb_state;
> + const struct intel_c10mpllb_state *pll_state =
> _state->cx0pll_state.c10mpllb_state;
> struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
> u8 master_lane = lane_reversal ? INTEL_CX0_LANE1 :
> @@ -1301,6 +1314,205 @@ void intel_c10mpllb_dump_hw_state(struct
> drm_i915_private *dev_priv,
> i + 2, hw_state->pll[i + 2], i + 3, hw_state->pll[i
> + 3]);
> }
>
> +static bool intel_c20_use_mplla(u32 clock)
> +{
> + /* 10G and 20G rates use MPLLA */
> + if (clock == 312500 || clock == 625000)
> + return true;
> +
> + return false;
> +}
> +
> +static u8 intel_c20_get_dp_rate(u32 clock)
> +{
> + switch (clock) {
> + case 162000: /* 1.62 Gbps DP1.4 */
> + return 0;
> + case 27: /* 2.7 Gbps DP1.4 */
> + return 1;
> + case 54: /* 5.4 Gbps DP 1.4 */
> + return 2;
> + case 81: /* 8.1 Gbps DP1.4 */
> + return 3;
> + case 216000: /* 2.16 Gbps eDP */
> + return 4;
> + case 243000: /* 2.43 Gbps eDP */
> + return 5;
> + case 324000: /* 3.24 Gbps eDP */
> + return 6;
> + case 432000: /* 4.32 Gbps eDP */
> + return 7;
> + case 312500: /* 10 Gbps DP2.0 */
> + return 8;
> + case 421875: /* 13.5 Gbps DP2.0 */
> + return 9;
> + case 625000: /* 20 Gbps DP2.0*/
> + return 10;
> + default:
> + MISSING_CASE(clock);
> + return 0;
> + }
> +}
> +
> +static u8 intel_c20_get_hdmi_rate(u32 clock)
> +{
> + switch (clock) {
> + case 25175:
> + case 27000:
> + case 74250:
> + case 148500:
> + case 594000:
> + return 0;
> + case 166670: /* 3 Gbps */
> + case 30: /* 6 Gbps */
> + case 70: /* 12 Gbps */
> + return 1;
> + case 40: /* 8 Gbps */
> + return 2;
> +
[Intel-gfx] [PATCH v7 07/10] drm/i915/hdcp: Use HDCP helpers for i915
From: Sean Paul
Now that all of the HDCP 1.x logic has been migrated to the central HDCP
helpers, use it in the i915 driver.
The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
however there are a few helper hooks which are connector-specific and
need to be partially or fully implemented in the intel_dp_hdcp.c or
intel_hdmi.c.
We'll leave most of the HDCP 2.x code alone since we don't have another
implementation of HDCP 2.x to use as reference for what should and
should not live in the drm helpers. The helper will call the overly
general enable/disable/is_capable HDCP 2.x callbacks and leave the
interesting stuff for the driver. Once we have another HDCP 2.x
implementation, we should do a similar migration.
Acked-by: Jani Nikula
Acked-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Fix mst helper function pointer reported by 0-day
Changes in v3:
-Add forward declaration for drm_atomic_state in intel_hdcp.h identified
by 0-day
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased.
Changes in v7:
-Added to drm_hdcp_helper_funcs new functions that are unique between DP
and HDMI
-Adjusted the function signatures to take "driver data"
drivers/gpu/drm/i915/display/intel_ddi.c | 32 +-
.../drm/i915/display/intel_display_debugfs.c | 6 +-
.../drm/i915/display/intel_display_types.h| 51 +-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 368 +++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 960 --
drivers/gpu/drm/i915/display/intel_hdcp.h | 37 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 276 ++---
8 files changed, 484 insertions(+), 1262 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 0f1ec2a98cc87..550a99d1811b4 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include "i915_drv.h"
@@ -2941,6 +2942,10 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
if (!intel_crtc_is_bigjoiner_slave(crtc_state))
@@ -2957,12 +2962,10 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
else
intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
- /* Enable hdcp if it's desired */
- if (conn_state->content_protection ==
- DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector),
- crtc_state,
- (u8)conn_state->hdcp_content_type);
+ if (connector->hdcp_helper_data)
+ drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
+ >base,
+ _port->hdcp_mutex);
}
static void intel_disable_ddi_dp(struct intel_atomic_state *state,
@@ -3008,7 +3011,14 @@ static void intel_disable_ddi(struct intel_atomic_state
*state,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
- intel_hdcp_disable(to_intel_connector(old_conn_state->connector));
+ struct intel_connector *connector =
+ to_intel_connector(old_conn_state->connector);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
+ if (connector->hdcp_helper_data)
+ drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
+ >base,
+ _port->hdcp_mutex);
if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
intel_disable_ddi_hdmi(state, encoder, old_crtc_state,
@@ -3036,13 +3046,19 @@ void intel_ddi_update_pipe(struct intel_atomic_state
*state,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
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);
-
[Intel-gfx] [PATCH v7 10/10] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
From: Sean Paul
Add HDCP 1.x support to msm DP bridges using the new HDCP
helpers.
Cc: Stephen Boyd
Reviewed-by: Stephen Boyd
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Squash [1] into this patch with the following changes (Stephen)
-Update the sc7180 dtsi file
-Remove resource names and just use index (Stephen)
Changes in v3:
-Split out the dtsi change from v2 (Stephen)
-Fix set-but-unused warning identified by 0-day
-Fix up a couple of style nits (Stephen)
-Store HDCP key directly in dp_hdcp struct (Stephen)
-Remove wmb in HDCP key initialization, move an_seed (Stephen)
-Use FIELD_PREP for bstatus/bcaps (Stephen)
-#define read_poll_timeout values (Stephen)
-Remove unnecessary parentheses in dp_hdcp_store_ksv_fifo (Stephen)
-Add compatible string for hdcp (Stephen)
-Rename dp_hdcp_write_* functions (Abhinav)
-Add 1us delay between An reads (Abhinav)
-Delete unused dp_hdcp_read_* functions
Changes in v4:
-Rebase on Bjorn's multi-dp patchset
Changes in v5:
-Change return check of drm_hdcp_helper_initialize_dp() (Stephen)
Changes in v6:
-Change the tracking of the state from connector state to bridge as
state as drm_connector_state is no longer tracked and the functionality
has moved to msm_dp_bridge
Changes in v7:
-Use dp bridge to maintain the state with no use for connector
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/Makefile| 1 +
drivers/gpu/drm/msm/dp/dp_debug.c | 48 ++-
drivers/gpu/drm/msm/dp/dp_debug.h | 17 +-
drivers/gpu/drm/msm/dp/dp_display.c | 42 ++-
drivers/gpu/drm/msm/dp/dp_display.h | 5 +
drivers/gpu/drm/msm/dp/dp_drm.c | 39 ++-
drivers/gpu/drm/msm/dp/dp_drm.h | 12 +-
drivers/gpu/drm/msm/dp/dp_hdcp.c| 483
drivers/gpu/drm/msm/dp/dp_hdcp.h| 31 ++
drivers/gpu/drm/msm/dp/dp_parser.c | 19 ++
drivers/gpu/drm/msm/dp/dp_parser.h | 4 +
drivers/gpu/drm/msm/dp/dp_reg.h | 30 +-
drivers/gpu/drm/msm/msm_atomic.c| 19 ++
14 files changed, 732 insertions(+), 19 deletions(-)
create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 86f0e64cbda30..c3e4d6102a5fa 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -15,6 +15,7 @@ config DRM_MSM
select REGULATOR
select DRM_DP_AUX_BUS
select DRM_DISPLAY_DP_HELPER
+ select DRM_DISPLAY_HDCP_HELPER
select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select DRM_PANEL
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7274c41228ed9..a73e7b858af27 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -122,6 +122,7 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
dp/dp_ctrl.o \
dp/dp_display.o \
dp/dp_drm.o \
+ dp/dp_hdcp.o \
dp/dp_hpd.o \
dp/dp_link.o \
dp/dp_panel.o \
diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
b/drivers/gpu/drm/msm/dp/dp_debug.c
index 5e35033ba3e43..e97d27edbb13b 100644
--- a/drivers/gpu/drm/msm/dp/dp_debug.c
+++ b/drivers/gpu/drm/msm/dp/dp_debug.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include "dp_parser.h"
#include "dp_catalog.h"
@@ -15,6 +16,7 @@
#include "dp_ctrl.h"
#include "dp_debug.h"
#include "dp_display.h"
+#include "dp_hdcp.h"
#define DEBUG_NAME "msm_dp"
@@ -25,6 +27,7 @@ struct dp_debug_private {
struct dp_link *link;
struct dp_panel *panel;
struct drm_connector *connector;
+ struct dp_hdcp *hdcp;
struct device *dev;
struct drm_device *drm_dev;
@@ -196,6 +199,35 @@ static int dp_test_active_open(struct inode *inode,
inode->i_private);
}
+static ssize_t dp_hdcp_key_write(struct file *file, const char __user *ubuf,
+size_t len, loff_t *offp)
+{
+ char *input_buffer;
+ int ret;
+ struct dp_debug_private *debug = file->private_data;
+
+ if (len != (DRM_HDCP_KSV_LEN + DP_HDCP_NUM_KEYS * DP_HDCP_KEY_LEN))
+ return -EINVAL;
+
+ if (!debug->hdcp)
+ return -ENOENT;
+
+ input_buffer = memdup_user_nul(ubuf, len);
+ if (IS_ERR(input_buffer))
+ return PTR_ERR(input_buffer);
+
+ ret = dp_hdcp_ingest_key(debug->hdcp, input_buffer, len);
+
+ kfree(input_buffer);
+ if (ret < 0) {
+ DRM_ERROR("Could not ingest HDCP key, ret=%d\n", ret);
+ return ret;
+ }
+
+ *offp += len;
+ return len;
+}
+
static const struct file_operations test_active_fops = {
.owner = THIS_MODULE,
.open = dp_test_active_open,
@@ -205,6 +237,12 @@ static const struct file_operations test_active_fops = {
.write = dp_test_active_write
};
+static const struct file_operations dp_hdcp_key_fops = {
+ .owner = THIS_MODULE,
[Intel-gfx] [PATCH v7 09/10] arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller
From: Sean Paul
Add the register ranges required for HDCP key injection and
HDCP TrustZone interaction as described in the dt-bindings for the
sc7180 dp controller.
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v3:
-Split off into a new patch containing just the dts change (Stephen)
-Add hdcp compatible string (Stephen)
Changes in v4:
-Rebase on Bjorn's multi-dp patchset
Changes in v5:
-Put the tz register offsets in trogdor dtsi (Rob C)
Changes in v6:
-Rebased: Removed modifications in sc7180.dtsi as it's already upstream
Changes in v7:
-Change registers offset
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 47f39c547c41a..63183ac9c3c48 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -816,6 +816,14 @@ _dp {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
+
+ reg = <0 0x0ae9 0 0x200>,
+ <0 0x0ae90200 0 0x200>,
+ <0 0x0ae90400 0 0xc00>,
+ <0 0x0ae91000 0 0x400>,
+ <0 0x0ae91400 0 0x400>,
+ <0 0x0aed1000 0 0x174>,
+ <0 0x0aee1000 0 0x2c>;
};
_dp_out {
--
2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH v7 08/10] dt-bindings: msm/dp: Add bindings for HDCP registers
From: Sean Paul Add the bindings for the MSM DisplayPort HDCP registers which are required to write the HDCP key into the display controller as well as the registers to enable HDCP authentication/key exchange/encryption. Cc: Rob Herring Cc: Stephen Boyd Reviewed-by: Rob Herring Signed-off-by: Sean Paul Signed-off-by: Mark Yacoub --- Changes in v2: -Drop register range names (Stephen) -Fix yaml errors (Rob) Changes in v3: -Add new compatible string for dp-hdcp -Add descriptions to reg -Add minItems/maxItems to reg -Make reg depend on the new hdcp compatible string Changes in v4: -Rebase on Bjorn's multi-dp patchset Changes in v4.5: -Remove maxItems from reg (Rob) -Remove leading zeros in example (Rob) Changes in v5: -None Changes in v6: -Rebased: modify minItems instead of adding it as new line. Changes in v7: -Revert the change to minItems -Added the maxItems to Reg .../devicetree/bindings/display/msm/dp-controller.yaml | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 774ccb5184b88..c47ade3a4ae17 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -31,6 +31,8 @@ properties: - description: link register block - description: p0 register block - description: p1 register block + - description: (Optional) Registers for HDCP device key injection + - description: (Optional) Registers for HDCP TrustZone interaction interrupts: maxItems: 1 @@ -158,6 +160,7 @@ allOf: aux-bus: false reg: minItems: 5 + maxItems: 7 required: - "#sound-dai-cells" @@ -175,7 +178,9 @@ examples: <0xae90200 0x200>, <0xae90400 0xc00>, <0xae91000 0x400>, - <0xae91400 0x400>; + <0xae91400 0x400>, + <0xaed1000 0x174>, + <0xaee1000 0x2c>; interrupt-parent = <>; interrupts = <12>; clocks = < DISP_CC_MDSS_AHB_CLK>, -- 2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH v7 05/10] drm/i915/hdcp: Consolidate HDCP setup/state cache
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
- None
drivers/gpu/drm/i915/display/intel_hdcp.c | 52 +++
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 396d2cef000aa..0a20bc41be55d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2190,6 +2190,37 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum
transcoder cpu_transcoder)
}
}
+static int
+_intel_hdcp_setup(struct intel_connector *connector,
+ const struct intel_crtc_state *pipe_config, u8 content_type)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ int ret = 0;
+
+ if (!connector->encoder) {
+ drm_err(_priv->drm, "[%s:%d] encoder is not initialized\n",
+ connector->base.name, connector->base.base.id);
+ return -ENODEV;
+ }
+
+ hdcp->content_type = content_type;
+
+ if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
+ hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
+ hdcp->stream_transcoder = pipe_config->cpu_transcoder;
+ } else {
+ hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
+ hdcp->stream_transcoder = INVALID_TRANSCODER;
+ }
+
+ if (DISPLAY_VER(dev_priv) >= 12)
+ dig_port->hdcp_port_data.fw_tc =
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+
+ return ret;
+}
+
static int initialize_hdcp_port_data(struct intel_connector *connector,
struct intel_digital_port *dig_port,
const struct intel_hdcp_shim *shim)
@@ -2329,28 +2360,14 @@ int intel_hdcp_enable(struct intel_connector *connector,
if (!hdcp->shim)
return -ENOENT;
- if (!connector->encoder) {
- drm_err(_priv->drm, "[%s:%d] encoder is not initialized\n",
- connector->base.name, connector->base.base.id);
- return -ENODEV;
- }
-
mutex_lock(>mutex);
mutex_lock(_port->hdcp_mutex);
drm_WARN_ON(_priv->drm,
hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
- hdcp->content_type = content_type;
-
- if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
- hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
- hdcp->stream_transcoder = pipe_config->cpu_transcoder;
- } else {
- hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
- hdcp->stream_transcoder = INVALID_TRANSCODER;
- }
- if (DISPLAY_VER(dev_priv) >= 12)
- dig_port->hdcp_port_data.fw_tc =
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+ ret = _intel_hdcp_setup(connector, pipe_config, content_type);
+ if (ret)
+ goto out;
/*
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
@@ -2378,6 +2395,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
true);
}
+out:
mutex_unlock(_port->hdcp_mutex);
mutex_unlock(>mutex);
return ret;
--
2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH v7 04/10] drm/hdcp: Expand HDCP helper library for enable/disable/check
From: Sean Paul
Expand upon the HDCP helper library to manage HDCP enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new platform supported HDCP we could make good decisions
about what should be centralized. With the addition of HDCP support
for Qualcomm, it's time to migrate the protocol-specific bits of HDCP
authentication, key exchange, and link checks to the HDCP helper.
In terms of functionality, this migration is 1:1 with the Intel driver,
however things are laid out a bit differently than with intel_hdcp.c,
which is why this is a separate patch from the i915 transition to the
helper. On i915, the shim vtable is used to account for HDMI vs. DP
vs. DP-MST differences whereas the helper library uses a LUT to
account for the register offsets and a remote read function to route
the messages. On i915, storing the sink information in the source is
done inline whereas now we use the new drm_hdcp_helper_funcs vtable
to store and fetch information to/from source hw. Finally, instead of
calling enable/disable directly from the driver, we'll leave that
decision to the helper and by calling drm_hdcp_helper_atomic_commit()
from the driver. All told, this will centralize the protocol and state
handling in the helper, ensuring we collect all of our bugs^Wlogic
in one place.
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Fixed set-but-unused variable identified by 0-day
Changes in v3:
-Fixed uninitialized variable warning identified by 0-day
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Fixed typo in function descriptions
-Rebased: Moved the new code between drm_hdcp.h and drm_hdcp_helper.c/h
-Add missing headers. Reported-by: kernel test robot
Changes in v7:
- Add a |driver_data| field to some functions in drm_hdcp_helper_funcs
that are called by the driver so drivers can pass anything they such
as bridges
- Isolate all non-common code between HDMI and DP into separate
functions instead of manually checking for datra->aux
drivers/gpu/drm/display/drm_hdcp_helper.c | 1211 +
include/drm/display/drm_hdcp.h| 287 +
include/drm/display/drm_hdcp_helper.h | 51 +-
3 files changed, 1548 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index 3ee1a6ae26c53..40ea10869736c 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -6,13 +6,18 @@
* Ramalingam C
*/
+#include
#include
#include
#include
+#include
+#include
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -507,3 +512,1209 @@ bool drm_hdcp_has_changed(struct drm_connector
*connector,
return old_hdcp != new_hdcp;
}
EXPORT_SYMBOL(drm_hdcp_has_changed);
+
+struct drm_hdcp_hdcp1_receiver_reg_lut {
+ unsigned int bksv;
+ unsigned int ri;
+ unsigned int aksv;
+ unsigned int an;
+ unsigned int ainfo;
+ unsigned int v[5];
+ unsigned int bcaps;
+ unsigned int bcaps_mask_repeater_present;
+ unsigned int bstatus;
+};
+
+static const struct drm_hdcp_hdcp1_receiver_reg_lut drm_hdcp_hdcp1_ddc_lut = {
+ .bksv = DRM_HDCP_DDC_BKSV,
+ .ri = DRM_HDCP_DDC_RI_PRIME,
+ .aksv = DRM_HDCP_DDC_AKSV,
+ .an = DRM_HDCP_DDC_AN,
+ .ainfo = DRM_HDCP_DDC_AINFO,
+ .v = { DRM_HDCP_DDC_V_PRIME(0), DRM_HDCP_DDC_V_PRIME(1),
+ DRM_HDCP_DDC_V_PRIME(2), DRM_HDCP_DDC_V_PRIME(3),
+ DRM_HDCP_DDC_V_PRIME(4) },
+ .bcaps = DRM_HDCP_DDC_BCAPS,
+ .bcaps_mask_repeater_present = DRM_HDCP_DDC_BCAPS_REPEATER_PRESENT,
+ .bstatus = DRM_HDCP_DDC_BSTATUS,
+};
+
+static const struct drm_hdcp_hdcp1_receiver_reg_lut drm_hdcp_hdcp1_dpcd_lut = {
+ .bksv = DP_AUX_HDCP_BKSV,
+ .ri = DP_AUX_HDCP_RI_PRIME,
+ .aksv = DP_AUX_HDCP_AKSV,
+ .an = DP_AUX_HDCP_AN,
+ .ainfo = DP_AUX_HDCP_AINFO,
+ .v = { DP_AUX_HDCP_V_PRIME(0), DP_AUX_HDCP_V_PRIME(1),
+ DP_AUX_HDCP_V_PRIME(2), DP_AUX_HDCP_V_PRIME(3),
+ DP_AUX_HDCP_V_PRIME(4) },
+ .bcaps = DP_AUX_HDCP_BCAPS,
+ .bcaps_mask_repeater_present = DP_BCAPS_REPEATER_PRESENT,
+
+ /*
+* For some reason the HDMI and DP HDCP specs call this register
+* definition by different names. In the HDMI spec, it's called BSTATUS,
+* but in DP it's called BINFO.
+*/
+ .bstatus = DP_AUX_HDCP_BINFO,
+};
+
+/*
+ * Read a DPCD register.
+ *
+ * @data: drm_hdcp_helper_data containing the DisplayPort AUX channel (SST or
MST)
+ * @offset: address of the (first) register to read
+ * @value: buffer to store the register values
+ * @len: number of bytes in @value
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
[Intel-gfx] [PATCH v7 06/10] drm/i915/hdcp: Retain hdcp_capable return codes
From: Sean Paul
The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased
Changes in v7:
-None
.../drm/i915/display/intel_display_debugfs.c | 9 +++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 51 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
3 files changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 7bcd90384a46d..a14b86a07e545 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -494,6 +494,7 @@ static void intel_panel_info(struct seq_file *m,
static void intel_hdcp_info(struct seq_file *m,
struct intel_connector *intel_connector)
{
+ int ret;
bool hdcp_cap, hdcp2_cap;
if (!intel_connector->hdcp.shim) {
@@ -501,8 +502,12 @@ static void intel_hdcp_info(struct seq_file *m,
goto out;
}
- hdcp_cap = intel_hdcp_capable(intel_connector);
- hdcp2_cap = intel_hdcp2_capable(intel_connector);
+ ret = intel_hdcp_capable(intel_connector, _cap);
+ if (ret)
+ hdcp_cap = false;
+ ret = intel_hdcp2_capable(intel_connector, _cap);
+ if (ret)
+ hdcp2_cap = false;
if (hdcp_cap)
seq_puts(m, "HDCP1.4 ");
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 0a20bc41be55d..61a862ae1f286 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -177,50 +177,49 @@ int intel_hdcp_read_valid_bksv(struct intel_digital_port
*dig_port,
}
/* Is HDCP1.4 capable on Platform and Sink */
-bool intel_hdcp_capable(struct intel_connector *connector)
+int intel_hdcp_capable(struct intel_connector *connector, bool *capable)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
const struct intel_hdcp_shim *shim = connector->hdcp.shim;
- bool capable = false;
u8 bksv[5];
+ *capable = false;
+
if (!shim)
- return capable;
+ return 0;
- if (shim->hdcp_capable) {
- shim->hdcp_capable(dig_port, );
- } else {
- if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
- capable = true;
- }
+ if (shim->hdcp_capable)
+ return shim->hdcp_capable(dig_port, capable);
+
+ if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
+ *capable = true;
- return capable;
+ return 0;
}
/* Is HDCP2.2 capable on Platform and Sink */
-bool intel_hdcp2_capable(struct intel_connector *connector)
+int intel_hdcp2_capable(struct intel_connector *connector, bool *capable)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
- bool capable = false;
+
+ *capable = false;
/* I915 support for HDCP2.2 */
if (!hdcp->hdcp2_supported)
- return false;
+ return 0;
/* MEI interface is solid */
mutex_lock(_priv->display.hdcp.comp_mutex);
if (!dev_priv->display.hdcp.comp_added ||
!dev_priv->display.hdcp.master) {
mutex_unlock(_priv->display.hdcp.comp_mutex);
- return false;
+ return 0;
}
mutex_unlock(_priv->display.hdcp.comp_mutex);
/* Sink's capability for HDCP2.2 */
- hdcp->shim->hdcp_2_2_capable(dig_port, );
-
- return capable;
+ return hdcp->shim->hdcp_2_2_capable(dig_port, capable);
}
static bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
@@ -2355,6 +2354,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
unsigned long check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
+ bool capable;
int ret = -EINVAL;
if (!hdcp->shim)
@@ -2373,21 +2373,27 @@ int intel_hdcp_enable(struct intel_connector *connector,
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
* is capable of HDCP2.2, it is preferred to use HDCP2.2.
*/
- if (intel_hdcp2_capable(connector)) {
+ ret = intel_hdcp2_capable(connector, );
+ if (capable) {
ret = _intel_hdcp2_enable(connector);
- if (!ret)
+
[Intel-gfx] [PATCH v7 02/10] drm/hdcp: Avoid changing crtc state in hdcp atomic check
From: Sean Paul
Instead of forcing a modeset in the hdcp atomic check, rename to
drm_hdcp_has_changed and return true if the content protection value
is changing and let the driver decide whether a modeset is required or not.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebase: modifications in drm_hdcp_helper.c instead of drm_hdcp.c
Changes in v7:
-Renamed the function from drm_hdcp_atomic_check to drm_hdcp_has_changed
(Dmitry Baryshkov)
drivers/gpu/drm/display/drm_hdcp_helper.c | 39 ++---
drivers/gpu/drm/i915/display/intel_atomic.c | 6 ++--
include/drm/display/drm_hdcp_helper.h | 2 +-
3 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index 7ca390b3ea106..34baf2b97cd87 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -422,18 +422,21 @@ void drm_hdcp_update_content_protection(struct
drm_connector *connector,
EXPORT_SYMBOL(drm_hdcp_update_content_protection);
/**
- * drm_hdcp_atomic_check - Helper for drivers to call during
connector->atomic_check
+ * drm_hdcp_has_changed - Helper for drivers to call during
connector->atomic_check
*
* @state: pointer to the atomic state being checked
* @connector: drm_connector on which content protection state needs an update
*
* This function can be used by display drivers to perform an atomic check on
the
- * hdcp state elements. If hdcp state has changed, this function will set
- * mode_changed on the crtc driving the connector so it can update its hardware
- * to match the hdcp state.
+ * hdcp state elements. If hdcp state has changed in a manner which requires
the
+ * driver to enable or disable content protection, this function will return
+ * true.
+ *
+ * Returns:
+ * true if the driver must enable/disable hdcp, false otherwise
*/
-void drm_hdcp_atomic_check(struct drm_connector *connector,
- struct drm_atomic_state *state)
+bool drm_hdcp_has_changed(struct drm_connector *connector,
+ struct drm_atomic_state *state)
{
struct drm_connector_state *new_conn_state, *old_conn_state;
struct drm_crtc_state *new_crtc_state;
@@ -450,19 +453,31 @@ void drm_hdcp_atomic_check(struct drm_connector
*connector,
* If the connector is being disabled with CP enabled, mark it
* desired so it's re-enabled when the connector is brought back
*/
- if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
+ if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
new_conn_state->content_protection =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
- return;
+ return true;
+ }
+ return false;
}
new_crtc_state =
drm_atomic_get_new_crtc_state(state, new_conn_state->crtc);
if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
(old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
-new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
+new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)) {
new_conn_state->content_protection =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ return true;
+ }
+
+ /*
+* Coming back from UNDESIRED state, CRTC change or re-enablement
requires
+* the driver to try CP enable.
+*/
+ if (new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+ new_conn_state->crtc != old_conn_state->crtc)
+ return true;
/*
* Nothing to do if content type is unchanged and one of:
@@ -477,9 +492,9 @@ void drm_hdcp_atomic_check(struct drm_connector *connector,
new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
if (old_conn_state->hdcp_content_type ==
new_conn_state->hdcp_content_type)
- return;
+ return false;
}
- new_crtc_state->mode_changed = true;
+ return true;
}
-EXPORT_SYMBOL(drm_hdcp_atomic_check);
+EXPORT_SYMBOL(drm_hdcp_has_changed);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 934ca9dcecc54..bce4aba752974 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -123,8 +123,6 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
to_intel_digital_connector_state(old_state);
struct drm_crtc_state *crtc_state;
- drm_hdcp_atomic_check(conn, state);
-
if (!new_state->crtc)
[Intel-gfx] [PATCH v7 03/10] drm/hdcp: Update property value on content type and user changes
From: Sean Paul
Update the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new content type.
2- Userspace sets value to DESIRED while ENABLED. In this case, the
value should be reset immediately to ENABLED since the link is
actively being encrypted.
To accommodate these changes, I've split up the conditionals to make
things a bit more clear (as much as one can with this mess of state).
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-Fixed indentation issue identified by 0-day
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased: modifications in drm_hdcp_helper.c instead of drm_hdcp.c
Changes in v7:
-Rebased as function name has changed.
drivers/gpu/drm/display/drm_hdcp_helper.c | 29 +++
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index 34baf2b97cd87..3ee1a6ae26c53 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -480,21 +480,30 @@ bool drm_hdcp_has_changed(struct drm_connector *connector,
return true;
/*
-* Nothing to do if content type is unchanged and one of:
-* - state didn't change
-* - HDCP was activated since the last commit
-* - attempting to set to desired while already enabled
+* Content type changes require an HDCP disable/enable cycle.
*/
- if (old_hdcp == new_hdcp ||
- (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+ if (new_conn_state->hdcp_content_type !=
+ old_conn_state->hdcp_content_type) {
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ return true;
+ }
+
+ /*
+* Ignore meaningless state changes:
+* - HDCP was activated since the last commit
+* - Attempting to set to desired while already enabled
+*/
+ if ((old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
(old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
- if (old_conn_state->hdcp_content_type ==
- new_conn_state->hdcp_content_type)
- return false;
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ return false;
}
- return true;
+ /* Finally, if state changes, we need action */
+ return old_hdcp != new_hdcp;
}
EXPORT_SYMBOL(drm_hdcp_has_changed);
--
2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH v7 01/10] drm/hdcp: Add drm_hdcp_atomic_check()
From: Sean Paul
Move the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebase: move helper from drm_hdcp.c to drm_hdcp_helper.c
Changes in v7:
-Removed links to patch from commit msg (Dmitry Baryshkov)
drivers/gpu/drm/display/drm_hdcp_helper.c | 64 +
drivers/gpu/drm/i915/display/intel_atomic.c | 4 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 47 ---
drivers/gpu/drm/i915/display/intel_hdcp.h | 3 -
include/drm/display/drm_hdcp_helper.h | 3 +
5 files changed, 69 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index e78999c72bd77..7ca390b3ea106 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
static inline void drm_hdcp_print_ksv(const u8 *ksv)
{
@@ -419,3 +420,66 @@ void drm_hdcp_update_content_protection(struct
drm_connector *connector,
dev->mode_config.content_protection_property);
}
EXPORT_SYMBOL(drm_hdcp_update_content_protection);
+
+/**
+ * drm_hdcp_atomic_check - Helper for drivers to call during
connector->atomic_check
+ *
+ * @state: pointer to the atomic state being checked
+ * @connector: drm_connector on which content protection state needs an update
+ *
+ * This function can be used by display drivers to perform an atomic check on
the
+ * hdcp state elements. If hdcp state has changed, this function will set
+ * mode_changed on the crtc driving the connector so it can update its hardware
+ * to match the hdcp state.
+ */
+void drm_hdcp_atomic_check(struct drm_connector *connector,
+ struct drm_atomic_state *state)
+{
+ struct drm_connector_state *new_conn_state, *old_conn_state;
+ struct drm_crtc_state *new_crtc_state;
+ u64 old_hdcp, new_hdcp;
+
+ old_conn_state = drm_atomic_get_old_connector_state(state, connector);
+ old_hdcp = old_conn_state->content_protection;
+
+ new_conn_state = drm_atomic_get_new_connector_state(state, connector);
+ new_hdcp = new_conn_state->content_protection;
+
+ if (!new_conn_state->crtc) {
+ /*
+* If the connector is being disabled with CP enabled, mark it
+* desired so it's re-enabled when the connector is brought back
+*/
+ if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ return;
+ }
+
+ new_crtc_state =
+ drm_atomic_get_new_crtc_state(state, new_conn_state->crtc);
+ if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
+ (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
+new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_DESIRED;
+
+ /*
+* Nothing to do if content type is unchanged and one of:
+* - state didn't change
+* - HDCP was activated since the last commit
+* - attempting to set to desired while already enabled
+*/
+ if (old_hdcp == new_hdcp ||
+ (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
+ (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
+new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
+ if (old_conn_state->hdcp_content_type ==
+ new_conn_state->hdcp_content_type)
+ return;
+ }
+
+ new_crtc_state->mode_changed = true;
+}
+EXPORT_SYMBOL(drm_hdcp_atomic_check);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 6621aa245caf4..934ca9dcecc54 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "i915_drv.h"
#include "i915_reg.h"
@@ -39,7 +40,6 @@
#include "intel_cdclk.h"
#include "intel_display_types.h"
#include "intel_global_state.h"
-#include "intel_hdcp.h"
#include "intel_psr.h"
#include "skl_universal_plane.h"
@@ -123,7 +123,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
to_intel_digital_connector_state(old_state);
struct drm_crtc_state *crtc_state;
- intel_hdcp_atomic_check(conn, old_state,
[Intel-gfx] [PATCH v7 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers
From: Mark Yacoub Hi all, This is v7 of the HDCP patches. The patches are authored by Sean Paul. I rebased and addressed the review comments in v6-v7. Patches 1-4 focus on moving the common HDCP helpers to common DRM. This introduces a slight change in the original intel flow as it splits the unique driver protocol from the generic implementation. Patches 5-7 split the HDCP flow on i915 driver to make use the common DRM helpers. Patches 8-10 implement HDCP on MSM driver. (Note: I resent the patch to add missing cc's) Thanks, -Mark Yacoub Sean Paul (10): drm/hdcp: Add drm_hdcp_atomic_check() drm/hdcp: Avoid changing crtc state in hdcp atomic check drm/hdcp: Update property value on content type and user changes drm/hdcp: Expand HDCP helper library for enable/disable/check drm/i915/hdcp: Consolidate HDCP setup/state cache drm/i915/hdcp: Retain hdcp_capable return codes drm/i915/hdcp: Use HDCP helpers for i915 dt-bindings: msm/dp: Add bindings for HDCP registers arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller drm/msm: Implement HDCP 1.x using the new drm HDCP helpers .../bindings/display/msm/dp-controller.yaml |7 +- arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi |8 + drivers/gpu/drm/display/drm_hdcp_helper.c | 1299 + drivers/gpu/drm/i915/display/intel_atomic.c |8 +- drivers/gpu/drm/i915/display/intel_ddi.c | 32 +- .../drm/i915/display/intel_display_debugfs.c | 11 +- .../drm/i915/display/intel_display_types.h| 51 +- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 368 ++--- drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 1036 +++-- drivers/gpu/drm/i915/display/intel_hdcp.h | 42 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 276 ++-- drivers/gpu/drm/msm/Kconfig |1 + drivers/gpu/drm/msm/Makefile |1 + drivers/gpu/drm/msm/dp/dp_debug.c | 48 +- drivers/gpu/drm/msm/dp/dp_debug.h | 17 +- drivers/gpu/drm/msm/dp/dp_display.c | 42 +- drivers/gpu/drm/msm/dp/dp_display.h |5 + drivers/gpu/drm/msm/dp/dp_drm.c | 39 +- drivers/gpu/drm/msm/dp/dp_drm.h | 12 +- drivers/gpu/drm/msm/dp/dp_hdcp.c | 483 ++ drivers/gpu/drm/msm/dp/dp_hdcp.h | 31 + drivers/gpu/drm/msm/dp/dp_parser.c| 19 + drivers/gpu/drm/msm/dp/dp_parser.h|4 + drivers/gpu/drm/msm/dp/dp_reg.h | 30 +- drivers/gpu/drm/msm/msm_atomic.c | 19 + include/drm/display/drm_hdcp.h| 287 include/drm/display/drm_hdcp_helper.h | 52 + 28 files changed, 2903 insertions(+), 1341 deletions(-) create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h -- 2.40.0.348.gf938b09366-goog
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Disable C6 on MTL A0 for media
On Fri, Mar 24, 2023 at 06:43:19PM +, Patchwork wrote: Patch Details Series: drm/i915/mtl: Disable C6 on MTL A0 for media URL: [1]https://patchwork.freedesktop.org/series/115610/ State: failure Details: [2]https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v1/index.html CI Bug Log - changes from CI_DRM_12911 -> Patchwork_115610v1 Summary FAILURE Serious unknown changes coming with Patchwork_115610v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_115610v1, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v1/index.html Participating hosts (37 -> 35) Missing (2): fi-tgl-1115g4 fi-snb-2520m Possible new issues Here are the unknown changes that may have been introduced in Patchwork_115610v1: IGT changes Possible regressions * igt@i915_selftest@live@workarounds: * bat-rpls-1: [3]PASS -> [4]INCOMPLETE Patch is specific to MTL A0, so the above failure is not related to this change. Regards, Umesh Known issues
Re: [Intel-gfx] [PATCH v7 01/10] drm/hdcp: Add drm_hdcp_atomic_check()
On Fri, 24 Mar 2023 at 21:21, Mark Yacoub wrote: > > From: Sean Paul > > Move the hdcp atomic check from i915 to drm_hdcp so other > drivers can use it. No functional changes, just cleaned up some of the > code when moving it over. > > Acked-by: Jani Nikula > Reviewed-by: Rodrigo Vivi > Reviewed-by: Dmitry Baryshkov > Signed-off-by: Sean Paul > Signed-off-by: Mark Yacoub Please: 1) Cc the cover letter to all parties, so that we know what is going on 2) Please also Cc the whole series including the cover letter to freedreno@ so that it hits patchwork as a whole. -- With best wishes Dmitry
Re: [Intel-gfx] [PATCH v6 07/10] drm/i915/hdcp: Use HDCP helpers for i915
On Tue, Mar 14, 2023 at 1:54 AM Kandpal, Suraj wrote:
>
> >
> > From: Sean Paul
> >
> > Now that all of the HDCP 1.x logic has been migrated to the central HDCP
> > helpers, use it in the i915 driver.
> >
> > The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
> > however there are a few helper hooks which are connector-specific and
> > need to be partially or fully implemented in the intel_dp_hdcp.c or
> > intel_hdmi.c.
> >
> > We'll leave most of the HDCP 2.x code alone since we don't have another
> > implementation of HDCP 2.x to use as reference for what should and
> > should not live in the drm helpers. The helper will call the overly
> > general enable/disable/is_capable HDCP 2.x callbacks and leave the
> > interesting stuff for the driver. Once we have another HDCP 2.x
> > implementation, we should do a similar migration.
> >
> > Acked-by: Jani Nikula
> > Signed-off-by: Sean Paul
> > Signed-off-by: Mark Yacoub
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-8-
> > s...@poorly.run #v1
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-8-
> > s...@poorly.run #v2
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-8-
> > s...@poorly.run #v3
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-
> > 8-s...@poorly.run #v4
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20220411204741.1074308-
> > 8-s...@poorly.run #v5
> >
> > Changes in v2:
> > -Fix mst helper function pointer reported by 0-day
> > Changes in v3:
> > -Add forward declaration for drm_atomic_state in intel_hdcp.h identified
> > by 0-day
> > Changes in v4:
> > -None
> > Changes in v5:
> > -None
> > Changes in v6:
> > -Rebased.
> >
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 32 +-
> > .../drm/i915/display/intel_display_debugfs.c | 6 +-
> > .../drm/i915/display/intel_display_types.h| 60 +-
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 348 +++
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +-
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 952 +++---
> > drivers/gpu/drm/i915/display/intel_hdcp.h | 31 +-
> > drivers/gpu/drm/i915/display/intel_hdmi.c | 270 ++---
> > 8 files changed, 445 insertions(+), 1270 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 69ecf2a3d6c6..a4397f066a3e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -28,6 +28,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> >
> > #include "i915_drv.h"
> > @@ -2909,6 +2910,10 @@ static void intel_enable_ddi(struct
> > intel_atomic_state *state,
> >const struct intel_crtc_state *crtc_state,
> >const struct drm_connector_state *conn_state)
> > {
> > + struct intel_connector *connector =
> > + to_intel_connector(conn_state->connector);
> > + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > +
> > drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
> >
> > if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> > @@ -2925,12 +2930,10 @@ static void intel_enable_ddi(struct
> > intel_atomic_state *state,
> > else
> > intel_enable_ddi_dp(state, encoder, crtc_state,
> > conn_state);
> >
> > - /* Enable hdcp if it's desired */
> > - if (conn_state->content_protection ==
> > - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > - intel_hdcp_enable(to_intel_connector(conn_state-
> > >connector),
> > - crtc_state,
> > - (u8)conn_state->hdcp_content_type);
> > + if (connector->hdcp_helper_data)
> > + drm_hdcp_helper_atomic_commit(connector-
> > >hdcp_helper_data,
> > + >base,
> > + _port->hdcp_mutex);
> > }
> >
> > static void intel_disable_ddi_dp(struct intel_atomic_state *state,
> > @@ -2976,7 +2979,14 @@ static void intel_disable_ddi(struct
> > intel_atomic_state *state,
> > const struct intel_crtc_state *old_crtc_state,
> > const struct drm_connector_state
> > *old_conn_state)
> > {
> > - intel_hdcp_disable(to_intel_connector(old_conn_state-
> > >connector));
> > + struct intel_connector *connector =
> > + to_intel_connector(old_conn_state->connector);
> > + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > +
> > + if (connector->hdcp_helper_data)
> > + drm_hdcp_helper_atomic_commit(connector-
> > >hdcp_helper_data,
> > + >base,
> > + _port->hdcp_mutex);
> >
> > if
Re: [Intel-gfx] [PATCH v6 06/10] drm/i915/hdcp: Retain hdcp_capable return codes
On Thu, Mar 23, 2023 at 3:18 AM Kandpal, Suraj wrote:
>
>
>
> > -Original Message-
> > From: Kandpal, Suraj
> > Sent: Friday, March 10, 2023 1:55 PM
> > To: Mark Yacoub ; quic_khs...@quicinc.com;
> > linux-arm-...@vger.kernel.org; dri-de...@lists.freedesktop.org;
> > freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; intel-gfx@lists.freedesktop.org
> > Cc: quic_sbill...@quicinc.com; konrad.dyb...@somainline.org; Souza, Jose
> > ; bjorn.anders...@linaro.org;
> > krzysztof.kozlowski...@linaro.org; hbh...@gmail.com; Vasut, Marek
> > ; Dixit, Ashutosh ;
> > s...@poorly.run; abhin...@codeaurora.org; javi...@redhat.com; Murthy,
> > Arun R ; Lisovskiy, Stanislav
> > ; agr...@kernel.org;
> > quic_jessz...@quicinc.com; Nautiyal, Ankit K ;
> > Nikula, Jani ; De Marchi, Lucas
> > ; quic_abhin...@quicinc.com;
> > swb...@chromium.org; robh...@kernel.org;
> > christophe.jail...@wanadoo.fr; max...@cerno.tech; Vivi, Rodrigo
> > ; johan+lin...@kernel.org;
> > tvrtko.ursu...@linux.intel.com; anders...@kernel.org;
> > diand...@chromium.org; Sharma, Swati2 ;
> > Navare, Manasi D ; tzimmerm...@suse.de;
> > Modem, Bhanuprakash ;
> > dmitry.barysh...@linaro.org; seanp...@chromium.org
> > Subject: RE: [PATCH v6 06/10] drm/i915/hdcp: Retain hdcp_capable return
> > codes
> >
> > > Subject: [PATCH v6 06/10] drm/i915/hdcp: Retain hdcp_capable return
> > > codes
> > >
> > > From: Sean Paul
> > >
> > > The shim functions return error codes, but they are discarded in
> > > intel_hdcp.c. This patch plumbs the return codes through so they are
> > > properly handled.
> > >
> > > Acked-by: Jani Nikula
> > > Reviewed-by: Rodrigo Vivi
> > > Signed-off-by: Sean Paul
> > > Signed-off-by: Mark Yacoub
> > > Link:
> > > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-7-
> > > s...@poorly.run #v1
> > > Link:
> > > https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-7-
> > > s...@poorly.run #v2
> > > Link:
> > > https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-7-
> > > s...@poorly.run #v3
> > > Link:
> > >
> > https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-
> > > 7-s...@poorly.run #v4
> > > Link:
> > >
> > https://patchwork.freedesktop.org/patch/msgid/20220411204741.1074308-
> > > 7-s...@poorly.run #v5
> > >
> > > Changes in v2:
> > > -None
> > > Changes in v3:
> > > -None
> > > Changes in v4:
> > > -None
> > > Changes in v5:
> > > -None
> > > Changes in v6:
> > > -Rebased
> > >
> > > ---
> > > .../drm/i915/display/intel_display_debugfs.c | 9 +++-
> > > drivers/gpu/drm/i915/display/intel_hdcp.c | 51 ++-
> > > drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
> > > 3 files changed, 37 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > index 7c7253a2541c..13a4153bb76e 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > @@ -492,6 +492,7 @@ static void intel_panel_info(struct seq_file *m,
> > > static void intel_hdcp_info(struct seq_file *m,
> > > struct intel_connector *intel_connector) {
> > > + int ret;
> > > bool hdcp_cap, hdcp2_cap;
> > >
> > > if (!intel_connector->hdcp.shim) {
> > > @@ -499,8 +500,12 @@ static void intel_hdcp_info(struct seq_file *m,
> > > goto out;
> > > }
> > >
> > > - hdcp_cap = intel_hdcp_capable(intel_connector);
> > > - hdcp2_cap = intel_hdcp2_capable(intel_connector);
> > > + ret = intel_hdcp_capable(intel_connector, _cap);
> > > + if (ret)
> > > + hdcp_cap = false;
> > > + ret = intel_hdcp2_capable(intel_connector, _cap);
> > > + if (ret)
> > > + hdcp2_cap = false;
> > >
> >
> > This does not seem to be adding value here as this error which you referred
> > to as being ignored is used both in case of hdmi and dp is being to
> > determine
> > if hdcp_cap or hdcp2 cap is true or false which you basically reiterate
> > here too
> > check the intel_dp_hdcp2_capable and intel_hdmi_hdcp2_capable .
> > this change in itself can be removed.
> >
> > Regards,
> > Suraj Kandpal
> >
Hey Suraj, what we're trying to do here is to have a distinction
between 2 things:
1. were we able to check of the capability or not. like did the
connection work well
2. if the check went well, what capability were were able to read
We may or may not need both info. But since we moved to common DRM, it
might be best keep the distinction and each driver can handle it as it
sees fit.
> > > if (hdcp_cap)
> > > seq_puts(m, "HDCP1.4 ");
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > index 0a20bc41be55..61a862ae1f28 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > +++
Re: [Intel-gfx] [PULL] drm-misc-next
On Thu, Mar 23, 2023 at 12:08:57PM +0100, Maarten Lankhorst wrote: > Hi Dave, Daniel, > > Lots of small commits with cleanup and fixes this time around, nothing major > otherwise. > > Cheers, > ~Maarten > > drm-misc-next-2023-03-23: > drm-misc-next for v6.4-rc1: > > Core Changes: > - Add unit test for xrgb to mono. > - Assorted small fixes to format helper selftests. > - Assorted documentation updates. > - Drop drm_dev_set_unique. > - Always use shadow buffer in generic fbdev emulation helpers, and > improve error handling. > > Driver Changes: > - Assorted small fixes to malidp, hdlcd, gma500, lima, bridge, rockchip. > - Move fbdev in gma500 to use drm_client. > - Convert bridge platform callbacks to void return. > - Drop leftover from vgem to shmem helper conversion. > > The following changes since commit b24343eaceedb902c1625854f85a193b0549d85f: > > drm/nouveau/nvfw/acr: set wpr_generic_header_dump storage-class-specifier > to static (2023-03-16 14:53:15 +0100) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-03-23 Pulled, thanks > > for you to fetch changes up to 4ab9157c7e02019fa8d8ab98d4f9e67e6a7cfad1: > > drm/rockchip: vop2: Add error check to devm_regmap_init_mmio (2023-03-23 > 00:18:58 +0100) > > > drm-misc-next for v6.4-rc1: > > Core Changes: > - Add unit test for xrgb to mono. > - Assorted small fixes to format helper selftests. > - Assorted documentation updates. > - Drop drm_dev_set_unique. > - Always use shadow buffer in generic fbdev emulation helpers, and > improve error handling. > > Driver Changes: > - Assorted small fixes to malidp, hdlcd, gma500, lima, bridge, rockchip. > - Move fbdev in gma500 to use drm_client. > - Convert bridge platform callbacks to void return. > - Drop leftover from vgem to shmem helper conversion. > > > Adam Ford (1): > drm/bridge: adv7533: Fix adv7533_mode_valid for adv7533 and adv7535 > > Alfredo Cruz (1): > drm/rockchip: vop2: Add error check to devm_regmap_init_mmio > > Arthur Grillo (2): > drm/format-helper: Add Kunit tests for drm_fb_xrgb_to_mono() > drm/format-helper: Make "destination_pitch" test usable for mono > > Christian König (1): > drm: remove drm_dev_set_unique > > Javier Martinez Canillas (1): > drm/format-helper: Use drm_format_info_min_pitch() in tests helper > > Lee Jones (1): > drm/ttm/ttm_bo: Provide a missing 'bulk' description and correct > misnaming of 'placement' > > Maíra Canal (2): > drm/vgem: Drop struct drm_vgem_gem_object > drm/lima: Use drm_sched_job_add_syncobj_dependency() > > Petr Tesarik (1): > drm/prime: Fix documentation of drm_gem_prime_fd_to_handle() > > Simon Ser (1): > drm: fix typo in margin connector properties docs > > Thomas Zimmermann (15): > drm/gma500: Remove unnecessary include statements > drm/gma500: Move fbdev code into separate source file > drm/gma500: Remove fbdev vma open and close callbacks > drm/gma500: Fix naming in fb_ops > drm/gma500: Inline psbfb_create() into psbfb_probe() > drm/gma500: Implement client-based fbdev emulation > drm/gma500: Pass fb_info to psb_fbdev_vm_fault() > drm/fbdev-generic: Always use shadow buffering > drm/fbdev-generic: Remove unused prefer_shadow_fbdev flag > drm/fb-helper: Export drm_fb_helper_release_info() > drm/fb-helper: Support smem_len in deferred I/O > drm/fbdev-generic: Set screen size to size of GEM buffer > drm/fbdev-generic: Clean up after failed probing > drm/fb-helper: Consolidate CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM > drm/fbdev-generic: Rename symbols > > Toby Chen (1): > drm/rockchip: dw_hdmi: cleanup drm encoder during unbind > > Tom Rix (3): > gpu: drm: bridge: sii9234: remove unused bridge_to_sii9234 function > drm/gma500: remove unused gma_pipe_event function > drm/rockchip: vop2: fix uninitialized variable possible_crtcs > > Uwe Kleine-König (17): > drm/bridge: cdns-dsi: Convert to platform remove callback returning void > drm/bridge: display-connector: Convert to platform remove callback > returning void > drm/bridge: fsl-ldb: Convert to platform remove callback returning void > drm/bridge: imx8qm-ldb: Convert to platform remove callback returning > void > drm/bridge: imx8qxp-ldb: Convert to platform remove callback returning > void > drm/bridge: imx8qxp-pixel-combiner: Convert to platform remove callback > returning void > drm/bridge: imx8qxp-pixel-link: Convert to platform remove callback > returning void > drm/bridge: imx8qxp-pxl2dpi: Convert to platform remove callback > returning void > drm/bridge: lvds-codec: Convert to platform remove callback returning > void >
[Intel-gfx] [PATCH v7 07/10] drm/i915/hdcp: Use HDCP helpers for i915
From: Sean Paul
Now that all of the HDCP 1.x logic has been migrated to the central HDCP
helpers, use it in the i915 driver.
The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
however there are a few helper hooks which are connector-specific and
need to be partially or fully implemented in the intel_dp_hdcp.c or
intel_hdmi.c.
We'll leave most of the HDCP 2.x code alone since we don't have another
implementation of HDCP 2.x to use as reference for what should and
should not live in the drm helpers. The helper will call the overly
general enable/disable/is_capable HDCP 2.x callbacks and leave the
interesting stuff for the driver. Once we have another HDCP 2.x
implementation, we should do a similar migration.
Acked-by: Jani Nikula
Acked-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Fix mst helper function pointer reported by 0-day
Changes in v3:
-Add forward declaration for drm_atomic_state in intel_hdcp.h identified
by 0-day
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased.
Changes in v7:
-Added to drm_hdcp_helper_funcs new functions that are unique between DP
and HDMI
-Adjusted the function signatures to take "driver data"
drivers/gpu/drm/i915/display/intel_ddi.c | 32 +-
.../drm/i915/display/intel_display_debugfs.c | 6 +-
.../drm/i915/display/intel_display_types.h| 51 +-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 368 +++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 960 --
drivers/gpu/drm/i915/display/intel_hdcp.h | 37 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 276 ++---
8 files changed, 484 insertions(+), 1262 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 0f1ec2a98cc87..550a99d1811b4 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include "i915_drv.h"
@@ -2941,6 +2942,10 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
if (!intel_crtc_is_bigjoiner_slave(crtc_state))
@@ -2957,12 +2962,10 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
else
intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
- /* Enable hdcp if it's desired */
- if (conn_state->content_protection ==
- DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector),
- crtc_state,
- (u8)conn_state->hdcp_content_type);
+ if (connector->hdcp_helper_data)
+ drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
+ >base,
+ _port->hdcp_mutex);
}
static void intel_disable_ddi_dp(struct intel_atomic_state *state,
@@ -3008,7 +3011,14 @@ static void intel_disable_ddi(struct intel_atomic_state
*state,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
- intel_hdcp_disable(to_intel_connector(old_conn_state->connector));
+ struct intel_connector *connector =
+ to_intel_connector(old_conn_state->connector);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
+ if (connector->hdcp_helper_data)
+ drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
+ >base,
+ _port->hdcp_mutex);
if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
intel_disable_ddi_hdmi(state, encoder, old_crtc_state,
@@ -3036,13 +3046,19 @@ void intel_ddi_update_pipe(struct intel_atomic_state
*state,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
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);
-
[Intel-gfx] [PATCH v7 05/10] drm/i915/hdcp: Consolidate HDCP setup/state cache
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
- None
drivers/gpu/drm/i915/display/intel_hdcp.c | 52 +++
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 396d2cef000aa..0a20bc41be55d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2190,6 +2190,37 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum
transcoder cpu_transcoder)
}
}
+static int
+_intel_hdcp_setup(struct intel_connector *connector,
+ const struct intel_crtc_state *pipe_config, u8 content_type)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ int ret = 0;
+
+ if (!connector->encoder) {
+ drm_err(_priv->drm, "[%s:%d] encoder is not initialized\n",
+ connector->base.name, connector->base.base.id);
+ return -ENODEV;
+ }
+
+ hdcp->content_type = content_type;
+
+ if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
+ hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
+ hdcp->stream_transcoder = pipe_config->cpu_transcoder;
+ } else {
+ hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
+ hdcp->stream_transcoder = INVALID_TRANSCODER;
+ }
+
+ if (DISPLAY_VER(dev_priv) >= 12)
+ dig_port->hdcp_port_data.fw_tc =
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+
+ return ret;
+}
+
static int initialize_hdcp_port_data(struct intel_connector *connector,
struct intel_digital_port *dig_port,
const struct intel_hdcp_shim *shim)
@@ -2329,28 +2360,14 @@ int intel_hdcp_enable(struct intel_connector *connector,
if (!hdcp->shim)
return -ENOENT;
- if (!connector->encoder) {
- drm_err(_priv->drm, "[%s:%d] encoder is not initialized\n",
- connector->base.name, connector->base.base.id);
- return -ENODEV;
- }
-
mutex_lock(>mutex);
mutex_lock(_port->hdcp_mutex);
drm_WARN_ON(_priv->drm,
hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
- hdcp->content_type = content_type;
-
- if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
- hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
- hdcp->stream_transcoder = pipe_config->cpu_transcoder;
- } else {
- hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
- hdcp->stream_transcoder = INVALID_TRANSCODER;
- }
- if (DISPLAY_VER(dev_priv) >= 12)
- dig_port->hdcp_port_data.fw_tc =
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+ ret = _intel_hdcp_setup(connector, pipe_config, content_type);
+ if (ret)
+ goto out;
/*
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
@@ -2378,6 +2395,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
true);
}
+out:
mutex_unlock(_port->hdcp_mutex);
mutex_unlock(>mutex);
return ret;
--
2.40.0.348.gf938b09366-goog
[Intel-gfx] [PATCH v7 06/10] drm/i915/hdcp: Retain hdcp_capable return codes
From: Sean Paul
The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased
Changes in v7:
-None
.../drm/i915/display/intel_display_debugfs.c | 9 +++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 51 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
3 files changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 7bcd90384a46d..a14b86a07e545 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -494,6 +494,7 @@ static void intel_panel_info(struct seq_file *m,
static void intel_hdcp_info(struct seq_file *m,
struct intel_connector *intel_connector)
{
+ int ret;
bool hdcp_cap, hdcp2_cap;
if (!intel_connector->hdcp.shim) {
@@ -501,8 +502,12 @@ static void intel_hdcp_info(struct seq_file *m,
goto out;
}
- hdcp_cap = intel_hdcp_capable(intel_connector);
- hdcp2_cap = intel_hdcp2_capable(intel_connector);
+ ret = intel_hdcp_capable(intel_connector, _cap);
+ if (ret)
+ hdcp_cap = false;
+ ret = intel_hdcp2_capable(intel_connector, _cap);
+ if (ret)
+ hdcp2_cap = false;
if (hdcp_cap)
seq_puts(m, "HDCP1.4 ");
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 0a20bc41be55d..61a862ae1f286 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -177,50 +177,49 @@ int intel_hdcp_read_valid_bksv(struct intel_digital_port
*dig_port,
}
/* Is HDCP1.4 capable on Platform and Sink */
-bool intel_hdcp_capable(struct intel_connector *connector)
+int intel_hdcp_capable(struct intel_connector *connector, bool *capable)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
const struct intel_hdcp_shim *shim = connector->hdcp.shim;
- bool capable = false;
u8 bksv[5];
+ *capable = false;
+
if (!shim)
- return capable;
+ return 0;
- if (shim->hdcp_capable) {
- shim->hdcp_capable(dig_port, );
- } else {
- if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
- capable = true;
- }
+ if (shim->hdcp_capable)
+ return shim->hdcp_capable(dig_port, capable);
+
+ if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
+ *capable = true;
- return capable;
+ return 0;
}
/* Is HDCP2.2 capable on Platform and Sink */
-bool intel_hdcp2_capable(struct intel_connector *connector)
+int intel_hdcp2_capable(struct intel_connector *connector, bool *capable)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
- bool capable = false;
+
+ *capable = false;
/* I915 support for HDCP2.2 */
if (!hdcp->hdcp2_supported)
- return false;
+ return 0;
/* MEI interface is solid */
mutex_lock(_priv->display.hdcp.comp_mutex);
if (!dev_priv->display.hdcp.comp_added ||
!dev_priv->display.hdcp.master) {
mutex_unlock(_priv->display.hdcp.comp_mutex);
- return false;
+ return 0;
}
mutex_unlock(_priv->display.hdcp.comp_mutex);
/* Sink's capability for HDCP2.2 */
- hdcp->shim->hdcp_2_2_capable(dig_port, );
-
- return capable;
+ return hdcp->shim->hdcp_2_2_capable(dig_port, capable);
}
static bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
@@ -2355,6 +2354,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
unsigned long check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
+ bool capable;
int ret = -EINVAL;
if (!hdcp->shim)
@@ -2373,21 +2373,27 @@ int intel_hdcp_enable(struct intel_connector *connector,
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
* is capable of HDCP2.2, it is preferred to use HDCP2.2.
*/
- if (intel_hdcp2_capable(connector)) {
+ ret = intel_hdcp2_capable(connector, );
+ if (capable) {
ret = _intel_hdcp2_enable(connector);
- if (!ret)
+
[Intel-gfx] [PATCH v7 02/10] drm/hdcp: Avoid changing crtc state in hdcp atomic check
From: Sean Paul
Instead of forcing a modeset in the hdcp atomic check, rename to
drm_hdcp_has_changed and return true if the content protection value
is changing and let the driver decide whether a modeset is required or not.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebase: modifications in drm_hdcp_helper.c instead of drm_hdcp.c
Changes in v7:
-Renamed the function from drm_hdcp_atomic_check to drm_hdcp_has_changed
(Dmitry Baryshkov)
drivers/gpu/drm/display/drm_hdcp_helper.c | 39 ++---
drivers/gpu/drm/i915/display/intel_atomic.c | 6 ++--
include/drm/display/drm_hdcp_helper.h | 2 +-
3 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index 7ca390b3ea106..34baf2b97cd87 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -422,18 +422,21 @@ void drm_hdcp_update_content_protection(struct
drm_connector *connector,
EXPORT_SYMBOL(drm_hdcp_update_content_protection);
/**
- * drm_hdcp_atomic_check - Helper for drivers to call during
connector->atomic_check
+ * drm_hdcp_has_changed - Helper for drivers to call during
connector->atomic_check
*
* @state: pointer to the atomic state being checked
* @connector: drm_connector on which content protection state needs an update
*
* This function can be used by display drivers to perform an atomic check on
the
- * hdcp state elements. If hdcp state has changed, this function will set
- * mode_changed on the crtc driving the connector so it can update its hardware
- * to match the hdcp state.
+ * hdcp state elements. If hdcp state has changed in a manner which requires
the
+ * driver to enable or disable content protection, this function will return
+ * true.
+ *
+ * Returns:
+ * true if the driver must enable/disable hdcp, false otherwise
*/
-void drm_hdcp_atomic_check(struct drm_connector *connector,
- struct drm_atomic_state *state)
+bool drm_hdcp_has_changed(struct drm_connector *connector,
+ struct drm_atomic_state *state)
{
struct drm_connector_state *new_conn_state, *old_conn_state;
struct drm_crtc_state *new_crtc_state;
@@ -450,19 +453,31 @@ void drm_hdcp_atomic_check(struct drm_connector
*connector,
* If the connector is being disabled with CP enabled, mark it
* desired so it's re-enabled when the connector is brought back
*/
- if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
+ if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
new_conn_state->content_protection =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
- return;
+ return true;
+ }
+ return false;
}
new_crtc_state =
drm_atomic_get_new_crtc_state(state, new_conn_state->crtc);
if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
(old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
-new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
+new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)) {
new_conn_state->content_protection =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ return true;
+ }
+
+ /*
+* Coming back from UNDESIRED state, CRTC change or re-enablement
requires
+* the driver to try CP enable.
+*/
+ if (new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+ new_conn_state->crtc != old_conn_state->crtc)
+ return true;
/*
* Nothing to do if content type is unchanged and one of:
@@ -477,9 +492,9 @@ void drm_hdcp_atomic_check(struct drm_connector *connector,
new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
if (old_conn_state->hdcp_content_type ==
new_conn_state->hdcp_content_type)
- return;
+ return false;
}
- new_crtc_state->mode_changed = true;
+ return true;
}
-EXPORT_SYMBOL(drm_hdcp_atomic_check);
+EXPORT_SYMBOL(drm_hdcp_has_changed);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 934ca9dcecc54..bce4aba752974 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -123,8 +123,6 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
to_intel_digital_connector_state(old_state);
struct drm_crtc_state *crtc_state;
- drm_hdcp_atomic_check(conn, state);
-
if (!new_state->crtc)
[Intel-gfx] [PATCH v7 01/10] drm/hdcp: Add drm_hdcp_atomic_check()
From: Sean Paul
Move the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebase: move helper from drm_hdcp.c to drm_hdcp_helper.c
Changes in v7:
-Removed links to patch from commit msg (Dmitry Baryshkov)
drivers/gpu/drm/display/drm_hdcp_helper.c | 64 +
drivers/gpu/drm/i915/display/intel_atomic.c | 4 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 47 ---
drivers/gpu/drm/i915/display/intel_hdcp.h | 3 -
include/drm/display/drm_hdcp_helper.h | 3 +
5 files changed, 69 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index e78999c72bd77..7ca390b3ea106 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
static inline void drm_hdcp_print_ksv(const u8 *ksv)
{
@@ -419,3 +420,66 @@ void drm_hdcp_update_content_protection(struct
drm_connector *connector,
dev->mode_config.content_protection_property);
}
EXPORT_SYMBOL(drm_hdcp_update_content_protection);
+
+/**
+ * drm_hdcp_atomic_check - Helper for drivers to call during
connector->atomic_check
+ *
+ * @state: pointer to the atomic state being checked
+ * @connector: drm_connector on which content protection state needs an update
+ *
+ * This function can be used by display drivers to perform an atomic check on
the
+ * hdcp state elements. If hdcp state has changed, this function will set
+ * mode_changed on the crtc driving the connector so it can update its hardware
+ * to match the hdcp state.
+ */
+void drm_hdcp_atomic_check(struct drm_connector *connector,
+ struct drm_atomic_state *state)
+{
+ struct drm_connector_state *new_conn_state, *old_conn_state;
+ struct drm_crtc_state *new_crtc_state;
+ u64 old_hdcp, new_hdcp;
+
+ old_conn_state = drm_atomic_get_old_connector_state(state, connector);
+ old_hdcp = old_conn_state->content_protection;
+
+ new_conn_state = drm_atomic_get_new_connector_state(state, connector);
+ new_hdcp = new_conn_state->content_protection;
+
+ if (!new_conn_state->crtc) {
+ /*
+* If the connector is being disabled with CP enabled, mark it
+* desired so it's re-enabled when the connector is brought back
+*/
+ if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ return;
+ }
+
+ new_crtc_state =
+ drm_atomic_get_new_crtc_state(state, new_conn_state->crtc);
+ if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
+ (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
+new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_DESIRED;
+
+ /*
+* Nothing to do if content type is unchanged and one of:
+* - state didn't change
+* - HDCP was activated since the last commit
+* - attempting to set to desired while already enabled
+*/
+ if (old_hdcp == new_hdcp ||
+ (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
+ (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
+new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
+ if (old_conn_state->hdcp_content_type ==
+ new_conn_state->hdcp_content_type)
+ return;
+ }
+
+ new_crtc_state->mode_changed = true;
+}
+EXPORT_SYMBOL(drm_hdcp_atomic_check);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 6621aa245caf4..934ca9dcecc54 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "i915_drv.h"
#include "i915_reg.h"
@@ -39,7 +40,6 @@
#include "intel_cdclk.h"
#include "intel_display_types.h"
#include "intel_global_state.h"
-#include "intel_hdcp.h"
#include "intel_psr.h"
#include "skl_universal_plane.h"
@@ -123,7 +123,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
to_intel_digital_connector_state(old_state);
struct drm_crtc_state *crtc_state;
- intel_hdcp_atomic_check(conn, old_state,
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev4)
== Series Details == Series: series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev4) URL : https://patchwork.freedesktop.org/series/114868/ State : success == Summary == CI Bug Log - changes from CI_DRM_12911 -> Patchwork_114868v4 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/index.html Participating hosts (37 -> 35) -- Missing(2): fi-tgl-1115g4 fi-snb-2520m Known issues Here are the changes found in Patchwork_114868v4 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@guc: - bat-rpls-1: [PASS][1] -> [DMESG-WARN][2] ([i915#7852]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/bat-rpls-1/igt@i915_selftest@l...@guc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/bat-rpls-1/igt@i915_selftest@l...@guc.html * igt@i915_selftest@live@migrate: - bat-adlp-9: [PASS][3] -> [DMESG-FAIL][4] ([i915#7699]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/bat-adlp-9/igt@i915_selftest@l...@migrate.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/bat-adlp-9/igt@i915_selftest@l...@migrate.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@read-crc: - bat-adlp-9: NOTRUN -> [SKIP][6] ([i915#3546]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-2: NOTRUN -> [SKIP][7] ([i915#1845]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@i915_pm_rps@basic-api: - bat-dg1-5: [FAIL][8] ([i915#8308]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/bat-dg1-5/igt@i915_pm_...@basic-api.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [DMESG-WARN][10] ([i915#8073]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html * igt@i915_suspend@basic-s3-without-i915: - bat-rpls-2: [ABORT][12] ([i915#6687] / [i915#7978]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-FAIL][14] ([i915#6997] / [i915#7913]) -> [DMESG-FAIL][15] ([i915#6367] / [i915#7913]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/bat-rpls-2/igt@i915_selftest@l...@slpc.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v4/bat-rpls-2/igt@i915_selftest@l...@slpc.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#8073]: https://gitlab.freedesktop.org/drm/intel/issues/8073 [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308 Build changes - * Linux: CI_DRM_12911 -> Patchwork_114868v4 CI-20190529: 20190529 CI_DRM_12911: 57d579dfa8400021292fdca447983cfb59246061 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7218: 8036123f781059c54a31240756794b17bd3d15dc @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114868v4: 57d579dfa8400021292fdca447983cfb59246061 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits d7d06741d3b6 drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore. 8355000cbe5d drm/i915/display: Restore dsparb_lock. == Logs == For more details see:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev4)
== Series Details == Series: series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev4) URL : https://patchwork.freedesktop.org/series/114868/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev4)
== Series Details == Series: series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev4) URL : https://patchwork.freedesktop.org/series/114868/ State : warning == Summary == Error: dim checkpatch failed 4a0ced9e598f drm/i915/display: Restore dsparb_lock. 6ac1060f9408 drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore. -:155: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #155: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:670: + intel_de_rmw(dev_priv, DSPFW3, DSPFW_CURSOR_SR_MASK, FW_WM(wm, CURSOR_SR)); -:183: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #183: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:720: + intel_de_write(dev_priv, DSPFW1, FW_WM(wm->sr.plane, SR) | -:189: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #189: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:725: + intel_de_write(dev_priv, DSPFW2, (wm->fbc_en ? DSPFW_FBC_SR_EN : 0) | -:197: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #197: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:732: + intel_de_write(dev_priv, DSPFW3, (wm->hpll_en ? DSPFW_HPLL_SR_EN : 0) | -:213: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #213: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:752: + intel_de_write(dev_priv, VLV_DDL(pipe), (wm->ddl[pipe].plane[PLANE_CURSOR] << DDL_CURSOR_SHIFT) | -:233: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #233: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:770: + intel_de_write(dev_priv, DSPFW1, FW_WM(wm->sr.plane, SR) | -:239: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #239: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:775: + intel_de_write(dev_priv, DSPFW2, FW_WM_VLV(wm->pipe[PIPE_A].plane[PLANE_SPRITE1], SPRITEB) | -:244: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #244: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:779: + intel_de_write(dev_priv, DSPFW3, FW_WM(wm->sr.cursor, CURSOR_SR)); -:249: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #249: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:783: + intel_de_write(dev_priv, DSPFW7_CHV, FW_WM_VLV(wm->pipe[PIPE_B].plane[PLANE_SPRITE1], SPRITED) | -:253: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #253: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:786: + intel_de_write(dev_priv, DSPFW8_CHV, FW_WM_VLV(wm->pipe[PIPE_C].plane[PLANE_SPRITE1], SPRITEF) | -:257: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #257: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:789: + intel_de_write(dev_priv, DSPFW9_CHV, FW_WM_VLV(wm->pipe[PIPE_C].plane[PLANE_PRIMARY], PLANEC) | -:261: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #261: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:792: + intel_de_write(dev_priv, DSPHOWM, FW_WM(wm->sr.plane >> 9, SR_HI) | -:270: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #270: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:804: + intel_de_write(dev_priv, DSPFW7, FW_WM_VLV(wm->pipe[PIPE_B].plane[PLANE_SPRITE1], SPRITED) | -:274: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #274: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:807: + intel_de_write(dev_priv, DSPHOWM, FW_WM(wm->sr.plane >> 9, SR_HI) | -:381: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #381: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:2205: + intel_de_write(dev_priv, FW_BLC_SELF, FW_BLC_SELF_FIFO_MASK | (srwm & 0xff)); -:480: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #480: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:3214: + intel_de_rmw(dev_priv, WM_MISC, WM_MISC_DATA_PARTITION_5_6, results->partitioning == INTEL_DDB_PART_1_2 ? 0 : -:485: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #485: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:3218: + intel_de_rmw(dev_priv, DISP_ARB_CTL2, DISP_DATA_PARTITION_5_6, results->partitioning == INTEL_DDB_PART_1_2 ? 0 : -:492: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #492: FILE: drivers/gpu/drm/i915/display/i9xx_wm.c:3224: +
Re: [Intel-gfx] [PATCH] [i915] avoid infinite retries in GuC/HuC loading
On 3/12/2023 12:56, Alexandre Oliva wrote: If two or more suitable entries with the same filename are found in __uc_fw_auto_select's fw_blobs, and that filename fails to load in the first attempt and in the retry, when __uc_fw_auto_select is called for the third time, the coincidence of strings will cause it to clear file_selected.path at the first hit, so it will return the second hit over and over again, indefinitely. Of course this doesn't occur with the pristine blob lists, but a modified version could run into this, e.g., patching in a duplicate entry, or (as in our case) disarming blob loading by remapping their names to "/*(DEBLOBBED)*/", given a toolchain that unifies identical string literals. Not sure what you mean by disarming? I think what you are saying is that you made a change similar to this? #define __MAKE_UC_FW_PATH_MMP(prefix_, name_, major_, minor_, patch_) "i915/invalid_file_name.bin" So all entries in the table have the exact same filename. And with the toolchain unification comment, that means not just a matching string but the same string pointer. Thus, the search code is getting confused. I'm not sure that is really a valid use case that the driver code should be expected to support. I'm not even sure what the purpose of your testing is? Even without the infinite loop, the driver is not going to load because you have removed the firmware files? However, I think you are saying that the problem would also exist if there was some kind of genuine duplication in the table? Can you give an example of a genuine use case problem? If the same string is used for different platforms, I believe that should be fine. E.g. there are already a bunch of different platforms that all use the same TGL firmware file. Even with the string unification, that should not be an issue because the search is within a platform only. So there can only be a problem if a single platform specifies the same filename multiple times? Which would be a bug in the table because why? It would be redundant entries that have no purpose. Note that I'm not saying we don't want to take your change. But I would like to understand if there is a genuine issue that maybe needs a better fix. E.g. should the table verification code be enhanced to just reject the table entirely if there are such errors present. Also, is this string unification thing a part of the current gcc toolchain? Or are you saying that is a new feature that is not generally available yet? Or maybe only exists in some non-gcc toolchain? Thanks, John. Of course I'm ready to carry a patchlet to avoid this problem triggered by our (GNU Linux-libre's) intentional changes, but I figured you might be interested in fail-safing it even in accidental backporting circumstances. I realize it's not entirely foolproof: if the same string appears in two entries separated by a different one, the infinite loop might still occur. Catching that even more unlikely situation seemed too expensive. Link: https://www.fsfla.org/pipermail/linux-libre/2023-March/003506.html Cc: intel-gfx@lists.freedesktop.org Cc: sta...@vger.kernel.org # 6.[12].x Signed-off-by: Alexandre Oliva --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index 9d6f571097e6..2b7564a3ed82 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -259,7 +259,10 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct intel_uc_fw *uc_fw) uc_fw->file_selected.path = NULL; continue; - } + } else if (uc_fw->file_wanted.path == blob->path) + /* Avoid retrying forever when neighbor + entries point to the same path. */ + continue; uc_fw->file_selected.path = blob->path; uc_fw->file_wanted.path = blob->path;
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Disable C6 on MTL A0 for media
== Series Details == Series: drm/i915/mtl: Disable C6 on MTL A0 for media URL : https://patchwork.freedesktop.org/series/115610/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12911 -> Patchwork_115610v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_115610v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_115610v1, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v1/index.html Participating hosts (37 -> 35) -- Missing(2): fi-tgl-1115g4 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_115610v1: ### IGT changes ### Possible regressions * igt@i915_selftest@live@workarounds: - bat-rpls-1: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/bat-rpls-1/igt@i915_selftest@l...@workarounds.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v1/bat-rpls-1/igt@i915_selftest@l...@workarounds.html Known issues Here are the changes found in Patchwork_115610v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@reset: - bat-rpls-2: [PASS][3] -> [ABORT][4] ([i915#4983] / [i915#7913]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/bat-rpls-2/igt@i915_selftest@l...@reset.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v1/bat-rpls-2/igt@i915_selftest@l...@reset.html Possible fixes * igt@i915_pm_rps@basic-api: - bat-dg1-5: [FAIL][5] ([i915#8308]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/bat-dg1-5/igt@i915_pm_...@basic-api.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v1/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [DMESG-WARN][7] ([i915#8073]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12911/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v1/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#8073]: https://gitlab.freedesktop.org/drm/intel/issues/8073 [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308 Build changes - * Linux: CI_DRM_12911 -> Patchwork_115610v1 CI-20190529: 20190529 CI_DRM_12911: 57d579dfa8400021292fdca447983cfb59246061 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7218: 8036123f781059c54a31240756794b17bd3d15dc @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115610v1: 57d579dfa8400021292fdca447983cfb59246061 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits a8d8db98c7b7 drm/i915/mtl: Disable C6 on MTL A0 for media == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115610v1/index.html
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Disable C6 on MTL A0 for media
On 3/24/2023 11:02 AM, Umesh Nerlige Ramappa wrote:
Earlier merge dropped an if block when applying the patch -
"drm/i915/mtl: Synchronize i915/BIOS on C6 enabling". Bring back the
if block as the check is required by - "drm/i915/mtl: Disable MC6 for MTL
A step" to disable C6 on media for A0 stepping.
LGTM,
Reviewed-by: Vinay Belgaumkar
Fixes: 3735040978a4 ("drm/i915/mtl: Synchronize i915/BIOS on C6 enabling")
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index f760586f9f46..8f3cd68d14f8 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -525,6 +525,13 @@ static bool rc6_supported(struct intel_rc6 *rc6)
return false;
}
+ if (IS_MTL_MEDIA_STEP(gt->i915, STEP_A0, STEP_B0) &&
+ gt->type == GT_MEDIA) {
+ drm_notice(>drm,
+ "Media RC6 disabled on A step\n");
+ return false;
+ }
+
return true;
}
Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable PL1 power limit when loading GuC firmware
On 3/15/2023 8:59 PM, Ashutosh Dixit wrote:
On dGfx, the PL1 power limit being enabled and set to a low value results
in a low GPU operating freq. It also negates the freq raise operation which
is done before GuC firmware load. As a result GuC firmware load can time
out. Such timeouts were seen in the GL #8062 bug below (where the PL1 power
limit was enabled and set to a low value). Therefore disable the PL1 power
limit when allowed by HW when loading GuC firmware.
v3 label missing in subject.
v2:
- Take mutex (to disallow writes to power1_max) across GuC reset/fw load
- Add hwm_power_max_restore to error return code path
v3 (Jani N):
- Add/remove explanatory comments
- Function renames
- Type corrections
- Locking annotation
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9 +++
drivers/gpu/drm/i915/i915_hwmon.c | 39 +++
drivers/gpu/drm/i915/i915_hwmon.h | 7 +
3 files changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 4ccb4be4c9cba..aa8e35a5636a0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -18,6 +18,7 @@
#include "intel_uc.h"
#include "i915_drv.h"
+#include "i915_hwmon.h"
static const struct intel_uc_ops uc_ops_off;
static const struct intel_uc_ops uc_ops_on;
@@ -461,6 +462,7 @@ static int __uc_init_hw(struct intel_uc *uc)
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
int ret, attempts;
+ bool pl1en;
Init to 'false' here
GEM_BUG_ON(!intel_uc_supports_guc(uc));
GEM_BUG_ON(!intel_uc_wants_guc(uc));
@@ -491,6 +493,9 @@ static int __uc_init_hw(struct intel_uc *uc)
else
attempts = 1;
+ /* Disable a potentially low PL1 power limit to allow freq to be raised */
+ i915_hwmon_power_max_disable(gt->i915, );
+
intel_rps_raise_unslice(_to_gt(uc)->rps);
while (attempts--) {
@@ -547,6 +552,8 @@ static int __uc_init_hw(struct intel_uc *uc)
intel_rps_lower_unslice(_to_gt(uc)->rps);
}
+ i915_hwmon_power_max_restore(gt->i915, pl1en);
+
guc_info(guc, "submission %s\n",
str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
guc_info(guc, "SLPC %s\n",
str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
@@ -563,6 +570,8 @@ static int __uc_init_hw(struct intel_uc *uc)
/* Return GT back to RPn */
intel_rps_lower_unslice(_to_gt(uc)->rps);
+ i915_hwmon_power_max_restore(gt->i915, pl1en);
if (pl1en)
i915_hwmon_power_max_enable().
+
__uc_sanitize(uc);
if (!ret) {
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index ee63a8fd88fc1..769b5bda4d53f 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -444,6 +444,45 @@ hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int
chan, long val)
}
}
+void i915_hwmon_power_max_disable(struct drm_i915_private *i915, bool *old)
Shouldn't we call this i915_hwmon_package_pl1_disable()?
+ __acquires(i915->hwmon->hwmon_lock)
+{
+ struct i915_hwmon *hwmon = i915->hwmon;
+ intel_wakeref_t wakeref;
+ u32 r;
+
+ if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
+ return;
+
+ /* Take mutex to prevent concurrent hwm_power_max_write */
+ mutex_lock(>hwmon_lock);
+
+ with_intel_runtime_pm(hwmon->ddat.uncore->rpm, wakeref)
+ r = intel_uncore_rmw(hwmon->ddat.uncore,
+hwmon->rg.pkg_rapl_limit,
+PKG_PWR_LIM_1_EN, 0);
Most of this code (lock and rmw parts) is already inside static void
hwm_locked_with_pm_intel_uncore_rmw() , can we reuse that here?
+
+ *old = !!(r & PKG_PWR_LIM_1_EN);
+}
+
+void i915_hwmon_power_max_restore(struct drm_i915_private *i915, bool old)
+ __releases(i915->hwmon->hwmon_lock)
We can just call this i915_hwmon_power_max_enable() and call whenever
the old value was actually enabled. That way, we have proper mirror
functions.
+{
+ struct i915_hwmon *hwmon = i915->hwmon;
+ intel_wakeref_t wakeref;
+
+ if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
+ return;
+
+ with_intel_runtime_pm(hwmon->ddat.uncore->rpm, wakeref)
+ intel_uncore_rmw(hwmon->ddat.uncore,
+hwmon->rg.pkg_rapl_limit,
+PKG_PWR_LIM_1_EN,
+old ? PKG_PWR_LIM_1_EN : 0);
3rd param should be 0 here, else we will end up clearing other bits.
Thanks,
Vinay.
+
+ mutex_unlock(>hwmon_lock);
+}
+
static umode_t
hwm_energy_is_visible(const struct hwm_drvdata *ddat, u32 attr)
{
diff --git
[Intel-gfx] [PATCH] drm/i915/mtl: Disable C6 on MTL A0 for media
Earlier merge dropped an if block when applying the patch -
"drm/i915/mtl: Synchronize i915/BIOS on C6 enabling". Bring back the
if block as the check is required by - "drm/i915/mtl: Disable MC6 for MTL
A step" to disable C6 on media for A0 stepping.
Fixes: 3735040978a4 ("drm/i915/mtl: Synchronize i915/BIOS on C6 enabling")
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index f760586f9f46..8f3cd68d14f8 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -525,6 +525,13 @@ static bool rc6_supported(struct intel_rc6 *rc6)
return false;
}
+ if (IS_MTL_MEDIA_STEP(gt->i915, STEP_A0, STEP_B0) &&
+ gt->type == GT_MEDIA) {
+ drm_notice(>drm,
+ "Media RC6 disabled on A step\n");
+ return false;
+ }
+
return true;
}
--
2.36.1
Re: [Intel-gfx] [PATCH v5 04/22] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
On Thu, Mar 16, 2023 at 01:13:17PM +0200, Mika Kahola wrote:
> From: Radhakrishna Sripada
>
> XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy
> has a dedicated PIPE 5.2 Message bus for configuration. This message
> bus is used to configure the phy internal registers.
>
> XELPDP has C10 phys to drive output to the EDP and the native output
> from the display engine. Add structures, programming hardware state
> readout logic. Port clock calculations are similar to DG2. Use the DG2
> formulae to calculate the port clock but use the relevant pll signals.
> Note: PHY lane 0 is always used for PLL programming.
>
> Add sequences for C10 phy enable/disable phy lane reset,
> powerdown change sequence and phy lane programming.
>
> Bspec: 64539, 64568, 64599, 65100, 65101, 65450, 65451, 67610, 67636
>
> v2: Squash patches related to C10 phy message bus and pll
> programming support (Jani)
> Move register definitions to a new file i.e. intel_cx0_reg_defs.h (Jani)
> Move macro definitions (Jani)
> DP rates as separate patch (Jani)
> Spin out xelpdp register definitions into a separate file (Jani)
> Replace macro to select registers based on phy lane with
> function calls (Jani)
> Fix styling issues (Jani)
> Call XELPDP_PORT_P2M_MSGBUS_STATUS() with port instead of phy (Lucas)
> v3: Move clear request flag into try-loop
> v4: On PHY idle change drm_err_once() as drm_dbg_kms() (Jani)
> use __intel_de_wait_for_register() instead of __intel_wait_for_register
> and uncomment intel_uncore.h (Jani)
> Add DP-alt support for PHY lane programming (Khaled)
Hi Mika!
The only comment from my feedback in [1] that I see addressed in this
version here is the renaming of intel_c10_program_phy_lane() to
intel_cx0_program_phy_lane.
Not sure if you did receive that in you inbox (meaning that the rename
aforementioned could be a coincidence).
[1]
https://patchwork.freedesktop.org/patch/517048/?series=109714=4#comment_943150
>
> Cc: Imre Deak
> Cc: Uma Shankar
> Signed-off-by: Radhakrishna Sripada
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/Makefile |1 +
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 1120 +
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 43 +
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 34 +
> drivers/gpu/drm/i915/display/intel_ddi.c | 22 +-
> .../drm/i915/display/intel_display_power.c|3 +-
> .../i915/display/intel_display_power_well.c |2 +-
> .../drm/i915/display/intel_display_types.h|6 +
> drivers/gpu/drm/i915/display/intel_dpll.c | 22 +-
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
> .../drm/i915/display/intel_modeset_verify.c |2 +
> drivers/gpu/drm/i915/i915_reg.h |5 +
> drivers/gpu/drm/i915/i915_reg_defs.h | 57 +
> 13 files changed, 1314 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 8e46f57e4569..27d81ba37187 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -295,6 +295,7 @@ i915-y += \
> display/icl_dsi.o \
> display/intel_backlight.o \
> display/intel_crt.o \
> + display/intel_cx0_phy.o \
> display/intel_ddi.o \
> display/intel_ddi_buf_trans.o \
> display/intel_display_trace.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> new file mode 100644
> index ..dce55f0ed5e1
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -0,0 +1,1120 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include "i915_reg.h"
> +#include "intel_cx0_phy.h"
> +#include "intel_cx0_phy_regs.h"
> +#include "intel_de.h"
> +#include "intel_display_types.h"
> +#include "intel_dp.h"
> +#include "intel_panel.h"
> +#include "intel_tc.h"
> +
> +bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
> +{
> + if (IS_METEORLAKE(dev_priv) && (phy < PHY_C))
> + return true;
> +
> + return false;
> +}
> +
> +static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port
> port, int lane)
> +{
> + enum phy phy = intel_port_to_phy(i915, port);
> +
> + /* Bring the phy to idle. */
> + intel_de_write(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, lane-1),
> +XELPDP_PORT_M2P_TRANSACTION_RESET);
> +
> + /* Wait for Idle Clear. */
> + if (intel_de_wait_for_clear(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port,
> lane-1),
> + XELPDP_PORT_M2P_TRANSACTION_RESET,
> + XELPDP_MSGBUS_TIMEOUT_SLOW)) {
> + drm_dbg_kms(>drm, "Failed to bring PHY %c to idle.\n",
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/overlay: Remove redundant drm_rect_visible() use
== Series Details == Series: drm/i915/overlay: Remove redundant drm_rect_visible() use URL : https://patchwork.freedesktop.org/series/115605/ State : success == Summary == CI Bug Log - changes from CI_DRM_12910 -> Patchwork_115605v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/index.html Participating hosts (37 -> 35) -- Missing(2): bat-rpls-2 fi-snb-2520m Known issues Here are the changes found in Patchwork_115605v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rps@basic-api: - bat-dg2-11: [PASS][1] -> [FAIL][2] ([i915#8308]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/bat-dg2-11/igt@i915_pm_...@basic-api.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/bat-dg2-11/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_lrc: - bat-adlp-9: [PASS][3] -> [INCOMPLETE][4] ([i915#4983]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-FAIL][5] ([i915#6367]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s3-without-i915: - bat-rpls-1: NOTRUN -> [ABORT][6] ([i915#6687] / [i915#7978]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html Possible fixes * igt@i915_selftest@live@migrate: - bat-dg2-11: [DMESG-WARN][7] ([i915#7699]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/bat-dg2-11/igt@i915_selftest@l...@migrate.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@requests: - bat-rpls-1: [ABORT][9] ([i915#7911]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/bat-rpls-1/igt@i915_selftest@l...@requests.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/bat-rpls-1/igt@i915_selftest@l...@requests.html [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308 Build changes - * Linux: CI_DRM_12910 -> Patchwork_115605v1 CI-20190529: 20190529 CI_DRM_12910: 34e37caa656a3f5907fd3afcacb4ef69b1d3062c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7217: 605a0a5896b8f49a41e04c358d00a85e4fb6df4e @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115605v1: 34e37caa656a3f5907fd3afcacb4ef69b1d3062c @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 9e4c527aa4b4 drm/i915/overlay: Remove redundant drm_rect_visible() use == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115605v1/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement UHBR bandwidth check (rev3)
== Series Details == Series: drm/i915: Implement UHBR bandwidth check (rev3) URL : https://patchwork.freedesktop.org/series/112806/ State : success == Summary == CI Bug Log - changes from CI_DRM_12910 -> Patchwork_112806v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/index.html Participating hosts (37 -> 36) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_112806v3 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-2: NOTRUN -> [ABORT][1] ([i915#7978]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html - bat-rpls-1: NOTRUN -> [ABORT][2] ([i915#6687] / [i915#7978]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@mman: - bat-rpls-2: NOTRUN -> [TIMEOUT][3] ([i915#6794]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/bat-rpls-2/igt@i915_selftest@l...@mman.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-FAIL][4] ([i915#6367]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][5] ([i915#5354]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html Possible fixes * igt@i915_selftest@live@migrate: - bat-dg2-11: [DMESG-WARN][6] ([i915#7699]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/bat-dg2-11/igt@i915_selftest@l...@migrate.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@requests: - bat-rpls-2: [ABORT][8] ([i915#7913] / [i915#7982]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/bat-rpls-2/igt@i915_selftest@l...@requests.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/bat-rpls-2/igt@i915_selftest@l...@requests.html - bat-rpls-1: [ABORT][10] ([i915#7911]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/bat-rpls-1/igt@i915_selftest@l...@requests.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@workarounds: - bat-rpls-2: [DMESG-FAIL][12] ([i915#6763] / [i915#7913]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12910/bat-rpls-2/igt@i915_selftest@l...@workarounds.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/bat-rpls-2/igt@i915_selftest@l...@workarounds.html [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#6763]: https://gitlab.freedesktop.org/drm/intel/issues/6763 [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982 Build changes - * Linux: CI_DRM_12910 -> Patchwork_112806v3 CI-20190529: 20190529 CI_DRM_12910: 34e37caa656a3f5907fd3afcacb4ef69b1d3062c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7217: 605a0a5896b8f49a41e04c358d00a85e4fb6df4e @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_112806v3: 34e37caa656a3f5907fd3afcacb4ef69b1d3062c @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits f1276e555e85 drm/i915: Implement UHBR bandwidth check == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112806v3/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Implement UHBR bandwidth check (rev3)
== Series Details == Series: drm/i915: Implement UHBR bandwidth check (rev3) URL : https://patchwork.freedesktop.org/series/112806/ State : warning == Summary == Error: dim checkpatch failed 5b3a41314c80 drm/i915: Implement UHBR bandwidth check -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: - Merged previous patch into that one, to remove empty function(Jani Nikula) total: 0 errors, 1 warnings, 0 checks, 47 lines checked
Re: [Intel-gfx] [PATCH v3 1/7] drm/dp_helper: Add helper to check DSC support with given o/p format
ack
On 2023-03-20 09:59, Jani Nikula wrote:
Thomas, Maxime, Maarten, ack for merging this one via drm-intel?
BR,
Jani.
On Thu, 09 Mar 2023, Suraj Kandpal wrote:
From: Ankit Nautiyal
Add helper to check if the DP sink supports DSC with the given
o/p format.
v2: Add documentation for the helper. (Uma Shankar)
v3: /** instead of /* (Uma Shankar)
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
include/drm/display/drm_dp_helper.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index ab55453f2d2c..533d3ee7fe05 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -194,6 +194,19 @@ drm_dp_dsc_sink_max_slice_width(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
DP_DSC_SLICE_WIDTH_MULTIPLIER;
}
+/**
+ * drm_dp_dsc_sink_supports_format() - check if sink supports DSC with given
output format
+ * @dsc_dpcd : DSC-capability DPCDs of the sink
+ * @output_format: output_format which is to be checked
+ *
+ * Returns true if the sink supports DSC with the given output_format, false
otherwise.
+ */
+static inline bool
+drm_dp_dsc_sink_supports_format(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
u8 output_format)
+{
+ return dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - DP_DSC_SUPPORT] &
output_format;
+}
+
/* Forward Error Correction Support on DP 1.4 */
static inline bool
drm_dp_sink_supports_fec(const u8 fec_capable)
[Intel-gfx] [PATCH] drm/i915/overlay: Remove redundant drm_rect_visible() use
The drm_rect_intersect() already returns if the intersection is visible or not, so the use of drm_rect_visible() is duplicate. Signed-off-by: Arthur Grillo --- drivers/gpu/drm/i915/display/intel_overlay.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c b/drivers/gpu/drm/i915/display/intel_overlay.c index c12bdca8da9b..444d88f418c5 100644 --- a/drivers/gpu/drm/i915/display/intel_overlay.c +++ b/drivers/gpu/drm/i915/display/intel_overlay.c @@ -966,9 +966,8 @@ static int check_overlay_dst(struct intel_overlay *overlay, rec->dst_width, rec->dst_height); clipped = req; - drm_rect_intersect(, _state->pipe_src); - if (!drm_rect_visible() || + if (!drm_rect_intersect(, _state->pipe_src) || !drm_rect_equals(, )) return -EINVAL; -- 2.39.2
Re: [Intel-gfx] [PATCH 12/29] drm/i915/tc: Factor out tc_phy_verify_legacy_or_dp_alt_mode()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 12/29] drm/i915/tc: Factor out
> tc_phy_verify_legacy_or_dp_alt_mode()
>
> Factor out a function verifying the PHY connected state in legacy or DP-alt
> mode. This is common to all platforms, which can be reused in platform
> specific
> connect hooks added in follow-up patches.
>
> No functional changes.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 47 +++--
> 1 file changed, 29 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 9179f86287ab0..ee4db9d0eb978 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -434,27 +434,13 @@ static void icl_tc_phy_get_hw_state(struct
> intel_tc_port *tc)
> * connect and disconnect to cleanly transfer ownership with the controller
> and
> * set the type-C power state.
> */
> -static bool icl_tc_phy_connect(struct intel_tc_port *tc,
> -int required_lanes)
> +static bool tc_phy_verify_legacy_or_dp_alt_mode(struct intel_tc_port *tc,
> + int required_lanes)
> {
> struct drm_i915_private *i915 = tc_to_i915(tc);
> struct intel_digital_port *dig_port = tc->dig_port;
> int max_lanes;
>
> - if (tc->mode == TC_PORT_TBT_ALT)
> - return true;
> -
> - if (!tc_phy_is_ready(tc) &&
> - !drm_WARN_ON(>drm, tc->legacy_port)) {
> - drm_dbg_kms(>drm, "Port %s: PHY not ready\n",
> - tc->port_name);
> - return false;
> - }
> -
> - if (!tc_phy_take_ownership(tc, true) &&
> - !drm_WARN_ON(>drm, tc->legacy_port))
> - return false;
> -
> max_lanes = intel_tc_port_fia_max_lane_count(dig_port);
> if (tc->legacy_port) {
> drm_WARN_ON(>drm, max_lanes != 4); @@ -470,7
> +456,7 @@ static bool icl_tc_phy_connect(struct intel_tc_port *tc,
> if (!(tc_phy_hpd_live_status(tc) & BIT(TC_PORT_DP_ALT))) {
> drm_dbg_kms(>drm, "Port %s: PHY sudden
> disconnect\n",
> tc->port_name);
> - goto out_release_phy;
> + return false;
> }
>
> if (max_lanes < required_lanes) {
> @@ -478,9 +464,34 @@ static bool icl_tc_phy_connect(struct intel_tc_port *tc,
> "Port %s: PHY max lanes %d < required lanes %d\n",
> tc->port_name,
> max_lanes, required_lanes);
> - goto out_release_phy;
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static bool icl_tc_phy_connect(struct intel_tc_port *tc,
> +int required_lanes)
> +{
> + struct drm_i915_private *i915 = tc_to_i915(tc);
> +
> + if (tc->mode == TC_PORT_TBT_ALT)
> + return true;
> +
> + if (!tc_phy_is_ready(tc) &&
> + !drm_WARN_ON(>drm, tc->legacy_port)) {
> + drm_dbg_kms(>drm, "Port %s: PHY not ready\n",
> + tc->port_name);
> + return false;
> }
>
> + if (!tc_phy_take_ownership(tc, true) &&
> + !drm_WARN_ON(>drm, tc->legacy_port))
> + return false;
> +
> + if (!tc_phy_verify_legacy_or_dp_alt_mode(tc, required_lanes))
> + goto out_release_phy;
> +
> return true;
>
> out_release_phy:
> --
> 2.37.1
Re: [Intel-gfx] [PATCH 11/29] drm/i915/tc: Add generic TC PHY connect/disconnect handlers
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 11/29] drm/i915/tc: Add generic TC PHY
> connect/disconnect handlers
>
> Add generic handlers to connect/disconnect a PHY.
>
> Setting the TC mode to the target mode deducted from the HPD state and - if
> connecting to this mode fails - falling back to connecting to the default
> (TBT)
> mode are common to all platforms; move the logic for this from the ICL
> specific
> connect / disconnect handlers to the generic ones.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 65 +++--
> 1 file changed, 39 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index aa39810962592..9179f86287ab0 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -434,41 +434,35 @@ static void icl_tc_phy_get_hw_state(struct
> intel_tc_port *tc)
> * connect and disconnect to cleanly transfer ownership with the controller
> and
> * set the type-C power state.
> */
> -static void icl_tc_phy_connect(struct intel_tc_port *tc,
> +static bool icl_tc_phy_connect(struct intel_tc_port *tc,
> int required_lanes)
> {
> struct drm_i915_private *i915 = tc_to_i915(tc);
> struct intel_digital_port *dig_port = tc->dig_port;
> - u32 live_status_mask;
> int max_lanes;
>
> + if (tc->mode == TC_PORT_TBT_ALT)
> + return true;
> +
> if (!tc_phy_is_ready(tc) &&
> !drm_WARN_ON(>drm, tc->legacy_port)) {
> drm_dbg_kms(>drm, "Port %s: PHY not ready\n",
> tc->port_name);
> - goto out_set_tbt_alt_mode;
> - }
> -
> - live_status_mask = tc_phy_hpd_live_status(tc);
> - if (!(live_status_mask & (BIT(TC_PORT_DP_ALT) |
> BIT(TC_PORT_LEGACY))) &&
> - !tc->legacy_port) {
> - drm_dbg_kms(>drm, "Port %s: PHY ownership not
> required (live status %02x)\n",
> - tc->port_name, live_status_mask);
> - goto out_set_tbt_alt_mode;
> + return false;
> }
>
> if (!tc_phy_take_ownership(tc, true) &&
> !drm_WARN_ON(>drm, tc->legacy_port))
> - goto out_set_tbt_alt_mode;
> + return false;
>
> max_lanes = intel_tc_port_fia_max_lane_count(dig_port);
> if (tc->legacy_port) {
> drm_WARN_ON(>drm, max_lanes != 4);
> - tc->mode = TC_PORT_LEGACY;
> -
> - return;
> + return true;
> }
>
> + drm_WARN_ON(>drm, tc->mode != TC_PORT_DP_ALT);
> +
> /*
>* Now we have to re-check the live state, in case the port recently
>* became disconnected. Not necessary for legacy mode.
> @@ -487,14 +481,12 @@ static void icl_tc_phy_connect(struct intel_tc_port
> *tc,
> goto out_release_phy;
> }
>
> - tc->mode = TC_PORT_DP_ALT;
> -
> - return;
> + return true;
>
> out_release_phy:
> tc_phy_take_ownership(tc, false);
> -out_set_tbt_alt_mode:
> - tc->mode = TC_PORT_TBT_ALT;
> +
> + return false;
> }
>
> /*
> @@ -509,9 +501,6 @@ static void icl_tc_phy_disconnect(struct intel_tc_port
> *tc)
> tc_phy_take_ownership(tc, false);
> fallthrough;
> case TC_PORT_TBT_ALT:
> - tc->mode = TC_PORT_DISCONNECTED;
> - fallthrough;
> - case TC_PORT_DISCONNECTED:
> break;
> default:
> MISSING_CASE(tc->mode);
> @@ -817,6 +806,30 @@ tc_phy_get_target_mode(struct intel_tc_port *tc)
> return hpd_mask_to_target_mode(tc, live_status_mask); }
>
> +static void tc_phy_connect(struct intel_tc_port *tc, int
> +required_lanes) {
> + struct drm_i915_private *i915 = tc_to_i915(tc);
> + bool connected;
> +
> + tc->mode = tc_phy_get_target_mode(tc);
> +
> + connected = icl_tc_phy_connect(tc, required_lanes);
> + if (!connected && tc->mode != default_tc_mode(tc)) {
> + tc->mode = default_tc_mode(tc);
> + connected = icl_tc_phy_connect(tc, required_lanes);
> + }
> +
> + drm_WARN_ON(>drm, !connected);
> +}
> +
> +static void tc_phy_disconnect(struct intel_tc_port *tc) {
> + if (tc->mode != TC_PORT_DISCONNECTED) {
> + icl_tc_phy_disconnect(tc);
> + tc->mode = TC_PORT_DISCONNECTED;
> + }
> +}
> +
> static void intel_tc_port_reset_mode(struct intel_tc_port *tc,
>int required_lanes, bool force_disconnect)
> {
> @@ -834,9 +847,9 @@ static void intel_tc_port_reset_mode(struct
> intel_tc_port *tc,
> drm_WARN_ON(>drm, aux_powered);
> }
>
> - icl_tc_phy_disconnect(tc);
> + tc_phy_disconnect(tc);
>
[Intel-gfx] [PATCH] drm/i915: Implement UHBR bandwidth check
According to spec, we should check if output_bpp * pixel_rate is less
than DDI clock * 72, if UHBR is used.
v2: - s/pipe_config/crtc_state/ (Jani Nikula)
- Merged previous patch into that one, to remove empty function(Jani Nikula)
v3: - Make that constraint check to be DSC-related only
- Limit this to only DISPLAY_VER <= 13
HSDES: 1406899791
BSPEC: 49259
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index a860cbc5dbea..4c0edb760b8e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -45,6 +45,27 @@
#include "intel_hotplug.h"
#include "skl_scaler.h"
+static int intel_dp_mst_check_constraints(struct drm_i915_private *i915, int
bpp,
+ const struct drm_display_mode
*adjusted_mode,
+ struct intel_crtc_state *crtc_state,
+ bool dsc)
+{
+ if (intel_dp_is_uhbr(crtc_state) && DISPLAY_VER(i915) <= 13 && dsc) {
+ int output_bpp = bpp;
+ /* DisplayPort 2 128b/132b, bits per lane is always 32 */
+ int symbol_clock = crtc_state->port_clock / 32;
+
+ if (output_bpp * adjusted_mode->crtc_clock >=
+ symbol_clock * 72) {
+ drm_dbg_kms(>drm, "UHBR check failed(required bw
%d available %d)\n",
+ output_bpp * adjusted_mode->crtc_clock,
symbol_clock * 72);
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
static int intel_dp_mst_find_vcpi_slots_for_bpp(struct intel_encoder *encoder,
struct intel_crtc_state
*crtc_state,
int max_bpp,
@@ -87,6 +108,10 @@ static int intel_dp_mst_find_vcpi_slots_for_bpp(struct
intel_encoder *encoder,
drm_dbg_kms(>drm, "Trying bpp %d\n", bpp);
+ ret = intel_dp_mst_check_constraints(i915, bpp, adjusted_mode,
crtc_state, dsc);
+ if (ret)
+ continue;
+
slots = drm_dp_atomic_find_time_slots(state, _dp->mst_mgr,
connector->port,
crtc_state->pbn);
@@ -104,8 +129,8 @@ static int intel_dp_mst_find_vcpi_slots_for_bpp(struct
intel_encoder *encoder,
}
}
- /* Despite slots are non-zero, we still failed the atomic check */
- if (ret && slots >= 0)
+ /* We failed to find a proper bpp/timeslots, return error */
+ if (ret)
slots = ret;
if (slots < 0) {
--
2.37.3
Re: [Intel-gfx] [PATCH 10/29] drm/i915/tc: Add TC PHY hook to read out the PHY HW state
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 10/29] drm/i915/tc: Add TC PHY hook to read out
> the
> PHY HW state
>
> Add a TC PHY hook to read out the PHY HW state on each platform, move the
> common parts to the generic helper.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 34 +
> 1 file changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 7d64cb310ca3e..aa39810962592 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -28,6 +28,7 @@ struct intel_tc_phy_ops {
> u32 (*hpd_live_status)(struct intel_tc_port *tc);
> bool (*is_ready)(struct intel_tc_port *tc);
> bool (*is_owned)(struct intel_tc_port *tc);
> + void (*get_hw_state)(struct intel_tc_port *tc);
> };
>
> struct intel_tc_port {
> @@ -51,6 +52,7 @@ struct intel_tc_port { static u32
> tc_phy_hpd_live_status(struct intel_tc_port *tc); static bool
> tc_phy_is_ready(struct intel_tc_port *tc); static bool
> tc_phy_take_ownership(struct intel_tc_port *tc, bool take);
> +static enum tc_port_mode tc_phy_get_current_mode(struct intel_tc_port
> +*tc);
>
> static const char *tc_port_mode_name(enum tc_port_mode mode) { @@ -
> 407,6 +409,20 @@ static bool icl_tc_phy_is_owned(struct intel_tc_port *tc)
> return val & DP_PHY_MODE_STATUS_NOT_SAFE(tc->phy_fia_idx);
> }
>
> +static void icl_tc_phy_get_hw_state(struct intel_tc_port *tc) {
> + enum intel_display_power_domain domain;
> + intel_wakeref_t tc_cold_wref;
> +
> + tc_cold_wref = tc_cold_block(tc, );
> +
> + tc->mode = tc_phy_get_current_mode(tc);
> + if (tc->mode != TC_PORT_DISCONNECTED)
> + tc->lock_wakeref = tc_cold_block(tc,
> >lock_power_domain);
> +
> + tc_cold_unblock(tc, domain, tc_cold_wref); }
> +
> /*
> * This function implements the first part of the Connect Flow described by
> our
> * specification, Gen11 TypeC Programming chapter. The rest of the flow
> (reading @@ -506,6 +522,7 @@ static const struct intel_tc_phy_ops
> icl_tc_phy_ops = {
> .hpd_live_status = icl_tc_phy_hpd_live_status,
> .is_ready = icl_tc_phy_is_ready,
> .is_owned = icl_tc_phy_is_owned,
> + .get_hw_state = icl_tc_phy_get_hw_state,
> };
>
> /**
> @@ -587,6 +604,7 @@ static const struct intel_tc_phy_ops adlp_tc_phy_ops = {
> .hpd_live_status = adlp_tc_phy_hpd_live_status,
> .is_ready = adlp_tc_phy_is_ready,
> .is_owned = adlp_tc_phy_is_owned,
> + .get_hw_state = icl_tc_phy_get_hw_state,
> };
>
> /**
> @@ -617,6 +635,11 @@ static bool tc_phy_is_owned(struct intel_tc_port *tc)
> return tc->phy_ops->is_owned(tc);
> }
>
> +static void tc_phy_get_hw_state(struct intel_tc_port *tc) {
> + tc->phy_ops->get_hw_state(tc);
> +}
> +
> static bool tc_phy_take_ownership(struct intel_tc_port *tc, bool take) {
> struct drm_i915_private *i915 = tc_to_i915(tc); @@ -889,8 +912,6 @@
> void intel_tc_port_init_mode(struct intel_digital_port *dig_port) {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> struct intel_tc_port *tc = to_tc_port(dig_port);
> - intel_wakeref_t tc_cold_wref;
> - enum intel_display_power_domain domain;
> bool update_mode = false;
>
> mutex_lock(>lock);
> @@ -899,17 +920,12 @@ void intel_tc_port_init_mode(struct intel_digital_port
> *dig_port)
> drm_WARN_ON(>drm, tc->lock_wakeref);
> drm_WARN_ON(>drm, tc->link_refcount);
>
> - tc_cold_wref = tc_cold_block(tc, );
> -
> - tc->mode = tc_phy_get_current_mode(tc);
> + tc_phy_get_hw_state(tc);
> /*
>* Save the initial mode for the state check in
>* intel_tc_port_sanitize_mode().
>*/
> tc->init_mode = tc->mode;
> - if (tc->mode != TC_PORT_DISCONNECTED)
> - tc->lock_wakeref =
> - tc_cold_block(tc, >lock_power_domain);
>
> /*
>* The PHY needs to be connected for AUX to work during HW readout
> and @@ -938,8 +954,6 @@ void intel_tc_port_init_mode(struct
> intel_digital_port *dig_port)
> /* Prevent changing tc->mode until intel_tc_port_sanitize_mode() is
> called. */
> __intel_tc_port_get_link(tc);
>
> - tc_cold_unblock(tc, domain, tc_cold_wref);
> -
> mutex_unlock(>lock);
> }
>
> --
> 2.37.1
Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
On Fri, Mar 24, 2023 at 09:09:59AM +, Tian, Kevin wrote: > > From: Alex Williamson > > Sent: Wednesday, March 22, 2023 5:01 AM > > > > On Tue, 21 Mar 2023 17:50:08 -0300 > > Jason Gunthorpe wrote: > > > > > > > > Though it would be nice if qemu didn't need two implementations so Yi > > > I'd rather see a new info in this series as well and qemu can just > > > consistently use dev_id and never bdf in iommufd mode. > > > > We also need to consider how libvirt determines if QEMU has the kernel > > support it needs to pass file descriptors. It'd be a lot cleaner if > > this aligned with the introduction of vfio cdevs. > > > > Libvirt can check whether the kernel creates cdev for a given device > via sysfs. > > but I'm not sure how Libvirt determines whether QEMU supports a > feature that it wants to use. But sounds this is a general handshake > problem as Libvirt needs to support many versions of QEMU then > there must be a way for such negotiation? Ideally libvirt would be able to learn what ioctls are supported on the cdev fd after it opens it, but before binding. I don't think we have something here yet, but I could imagine having something. Clearly it is easier if cdev alone is enough proof to know that it should go ahead in cdev mode. Jason
Re: [Intel-gfx] [PATCH 09/29] drm/i915/tc: Add TC PHY hooks to get the PHY ready/owned state
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 09/29] drm/i915/tc: Add TC PHY hooks to get the
> PHY ready/owned state
>
> Add TC PHY hooks to get the PHY ready/owned state on each platform,
> replacing the corresponding if ladder.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 20
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index a0508e2173007..7d64cb310ca3e 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -26,6 +26,8 @@ struct intel_tc_port;
>
> struct intel_tc_phy_ops {
> u32 (*hpd_live_status)(struct intel_tc_port *tc);
> + bool (*is_ready)(struct intel_tc_port *tc);
> + bool (*is_owned)(struct intel_tc_port *tc);
> };
>
> struct intel_tc_port {
> @@ -502,6 +504,8 @@ static void icl_tc_phy_disconnect(struct intel_tc_port
> *tc)
>
> static const struct intel_tc_phy_ops icl_tc_phy_ops = {
> .hpd_live_status = icl_tc_phy_hpd_live_status,
> + .is_ready = icl_tc_phy_is_ready,
> + .is_owned = icl_tc_phy_is_owned,
> };
>
> /**
> @@ -581,6 +585,8 @@ static bool adlp_tc_phy_is_owned(struct intel_tc_port
> *tc)
>
> static const struct intel_tc_phy_ops adlp_tc_phy_ops = {
> .hpd_live_status = adlp_tc_phy_hpd_live_status,
> + .is_ready = adlp_tc_phy_is_ready,
> + .is_owned = adlp_tc_phy_is_owned,
> };
>
> /**
> @@ -603,22 +609,12 @@ static u32 tc_phy_hpd_live_status(struct intel_tc_port
> *tc)
>
> static bool tc_phy_is_ready(struct intel_tc_port *tc) {
> - struct drm_i915_private *i915 = tc_to_i915(tc);
> -
> - if (IS_ALDERLAKE_P(i915))
> - return adlp_tc_phy_is_ready(tc);
> -
> - return icl_tc_phy_is_ready(tc);
> + return tc->phy_ops->is_ready(tc);
> }
>
> static bool tc_phy_is_owned(struct intel_tc_port *tc) {
> - struct drm_i915_private *i915 = tc_to_i915(tc);
> -
> - if (IS_ALDERLAKE_P(i915))
> - return adlp_tc_phy_is_owned(tc);
> -
> - return icl_tc_phy_is_owned(tc);
> + return tc->phy_ops->is_owned(tc);
> }
>
> static bool tc_phy_take_ownership(struct intel_tc_port *tc, bool take)
> --
> 2.37.1
Re: [Intel-gfx] [PATCH 08/29] drm/i915/tc: Add TC PHY hook to get the PHY HPD live status
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 08/29] drm/i915/tc: Add TC PHY hook to get the PHY
> HPD live status
>
> Add a table of TC PHY hooks which can be used to call platform specific TC PHY
> handlers, replacing the corresponding if ladders.
>
> Add the hook to retrieve the PHY's HPD live status. Move the common part
> fixing
> up the VBT legacy port flag to the generic helper.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 40 ++---
> 1 file changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 2a04c5ea44ade..a0508e2173007 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -22,8 +22,17 @@ enum tc_port_mode {
> TC_PORT_LEGACY,
> };
>
> +struct intel_tc_port;
> +
> +struct intel_tc_phy_ops {
> + u32 (*hpd_live_status)(struct intel_tc_port *tc); };
> +
> struct intel_tc_port {
> struct intel_digital_port *dig_port;
> +
> + const struct intel_tc_phy_ops *phy_ops;
> +
> struct mutex lock; /* protects the TypeC port mode */
> intel_wakeref_t lock_wakeref;
> enum intel_display_power_domain lock_power_domain; @@ -329,10
> +338,6 @@ static u32 icl_tc_phy_hpd_live_status(struct intel_tc_port *tc)
> if (intel_de_read(i915, SDEISR) & isr_bit)
> mask |= BIT(TC_PORT_LEGACY);
>
> - /* The sink can be connected only in a single mode. */
> - if (!drm_WARN_ON_ONCE(>drm, hweight32(mask) > 1))
> - tc_port_fixup_legacy_flag(tc, mask);
> -
> return mask;
> }
>
> @@ -495,6 +500,10 @@ static void icl_tc_phy_disconnect(struct intel_tc_port
> *tc)
> }
> }
>
> +static const struct intel_tc_phy_ops icl_tc_phy_ops = {
> + .hpd_live_status = icl_tc_phy_hpd_live_status, };
> +
> /**
> * ADLP TC PHY handlers
> *
> @@ -521,10 +530,6 @@ static u32 adlp_tc_phy_hpd_live_status(struct
> intel_tc_port *tc)
> if (intel_de_read(i915, SDEISR) & isr_bit)
> mask |= BIT(TC_PORT_LEGACY);
>
> - /* The sink can be connected only in a single mode. */
> - if (!drm_WARN_ON(>drm, hweight32(mask) > 1))
> - tc_port_fixup_legacy_flag(tc, mask);
> -
> return mask;
> }
>
> @@ -574,6 +579,10 @@ static bool adlp_tc_phy_is_owned(struct intel_tc_port
> *tc)
> return val & DDI_BUF_CTL_TC_PHY_OWNERSHIP; }
>
> +static const struct intel_tc_phy_ops adlp_tc_phy_ops = {
> + .hpd_live_status = adlp_tc_phy_hpd_live_status, };
> +
> /**
> * Generic TC PHY handlers
> * ---
> @@ -581,11 +590,15 @@ static bool adlp_tc_phy_is_owned(struct
> intel_tc_port *tc) static u32 tc_phy_hpd_live_status(struct intel_tc_port
> *tc) {
> struct drm_i915_private *i915 = tc_to_i915(tc);
> + u32 mask;
>
> - if (IS_ALDERLAKE_P(i915))
> - return adlp_tc_phy_hpd_live_status(tc);
> + mask = tc->phy_ops->hpd_live_status(tc);
> +
> + /* The sink can be connected only in a single mode. */
> + if (!drm_WARN_ON_ONCE(>drm, hweight32(mask) > 1))
> + tc_port_fixup_legacy_flag(tc, mask);
>
> - return icl_tc_phy_hpd_live_status(tc);
> + return mask;
> }
>
> static bool tc_phy_is_ready(struct intel_tc_port *tc) @@ -1197,6 +1210,11 @@
> int intel_tc_port_init(struct intel_digital_port *dig_port, bool is_legacy)
> dig_port->tc = tc;
> tc->dig_port = dig_port;
>
> + if (DISPLAY_VER(i915) >= 13)
> + tc->phy_ops = _tc_phy_ops;
> + else
> + tc->phy_ops = _tc_phy_ops;
> +
> snprintf(tc->port_name, sizeof(tc->port_name),
>"%c/TC#%d", port_name(port), tc_port + 1);
>
> --
> 2.37.1
Re: [Intel-gfx] [PATCH 07/29] drm/i915/tc: Move the intel_tc_port struct declaration to intel_tc.c
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 07/29] drm/i915/tc: Move the intel_tc_port struct
> declaration to intel_tc.c
>
> Move the intel_tc_port struct to intel_tc.c for better isolation. This
> requires
> allocating the struct dynamically.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 7 +--
> .../drm/i915/display/intel_display_types.h| 4 +-
> drivers/gpu/drm/i915/display/intel_tc.c | 45 +--
> drivers/gpu/drm/i915/display/intel_tc.h | 30 +
> 4 files changed, 49 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 73240cf78c8bf..dac3ec8fbbc11 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3843,7 +3843,7 @@ static void intel_ddi_encoder_destroy(struct
> drm_encoder *encoder)
>
> intel_dp_encoder_flush_work(encoder);
> if (intel_phy_is_tc(i915, phy))
> - intel_tc_port_flush_work(dig_port);
> + intel_tc_port_cleanup(dig_port);
> intel_display_power_flush_work(i915);
>
> drm_encoder_cleanup(encoder);
> @@ -4284,7 +4284,7 @@ static void intel_ddi_encoder_shutdown(struct
> intel_encoder *encoder)
> if (!intel_phy_is_tc(i915, phy))
> return;
>
> - intel_tc_port_flush_work(dig_port);
> + intel_tc_port_cleanup(dig_port);
> }
>
> #define port_tc_name(port) ((port) - PORT_TC1 + '1') @@ -4541,7 +4541,8 @@
> void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
> is_legacy ? "legacy" : "non-legacy");
> }
>
> - intel_tc_port_init(dig_port, is_legacy);
> + if (intel_tc_port_init(dig_port, is_legacy) < 0)
> + goto err;
>
> encoder->update_prepare = intel_ddi_update_prepare;
> encoder->update_complete = intel_ddi_update_complete; diff -
> -git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 0130c7b7f0232..ce24e58b2a825 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -54,13 +54,13 @@
> #include "intel_display_power.h"
> #include "intel_dpll_mgr.h"
> #include "intel_wm_types.h"
> -#include "intel_tc.h"
>
> struct drm_printer;
> struct __intel_global_objs_state;
> struct intel_ddi_buf_trans;
> struct intel_fbc;
> struct intel_connector;
> +struct intel_tc_port;
>
> /*
> * Display related stuff
> @@ -1781,7 +1781,7 @@ struct intel_digital_port {
> intel_wakeref_t ddi_io_wakeref;
> intel_wakeref_t aux_wakeref;
>
> - struct intel_tc_port tc;
> + struct intel_tc_port *tc;
>
> /* protects num_hdcp_streams reference count, hdcp_port_data and
> hdcp_auth_status */
> struct mutex hdcp_mutex;
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 48a59a675cd57..2a04c5ea44ade 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -15,6 +15,28 @@
> #include "intel_mg_phy_regs.h"
> #include "intel_tc.h"
>
> +enum tc_port_mode {
> + TC_PORT_DISCONNECTED,
> + TC_PORT_TBT_ALT,
> + TC_PORT_DP_ALT,
> + TC_PORT_LEGACY,
> +};
> +
> +struct intel_tc_port {
> + struct intel_digital_port *dig_port;
> + struct mutex lock; /* protects the TypeC port mode */
> + intel_wakeref_t lock_wakeref;
> + enum intel_display_power_domain lock_power_domain;
> + struct delayed_work disconnect_phy_work;
> + int link_refcount;
> + bool legacy_port:1;
> + char port_name[8];
> + enum tc_port_mode mode;
> + enum tc_port_mode init_mode;
> + enum phy_fia phy_fia;
> + u8 phy_fia_idx;
> +};
> +
> static u32 tc_phy_hpd_live_status(struct intel_tc_port *tc); static bool
> tc_phy_is_ready(struct intel_tc_port *tc); static bool
> tc_phy_take_ownership(struct intel_tc_port *tc, bool take); @@ -36,7 +58,7
> @@ static const char *tc_port_mode_name(enum tc_port_mode mode)
>
> static struct intel_tc_port *to_tc_port(struct intel_digital_port *dig_port)
> {
> - return _port->tc;
> + return dig_port->tc;
> }
>
> static struct drm_i915_private *tc_to_i915(struct intel_tc_port *tc) @@ -
> 1158,16 +1180,21 @@ tc_port_load_fia_params(struct drm_i915_private *i915,
> struct intel_tc_port *tc)
> }
> }
>
> -void intel_tc_port_init(struct intel_digital_port *dig_port, bool is_legacy)
> +int intel_tc_port_init(struct intel_digital_port *dig_port, bool
> +is_legacy)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> - struct intel_tc_port
Re: [Intel-gfx] [PATCH 06/29] drm/i915/tc: Check for TC PHY explicitly in intel_tc_port_fia_max_lane_count()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 06/29] drm/i915/tc: Check for TC PHY explicitly in
> intel_tc_port_fia_max_lane_count()
>
> Check explicitly if the port passed to
> intel_tc_port_fia_max_lane_count() has a TC PHY, instead of relying on the
> default TC mode value set for non-TC PHY ports.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 70771044a2fe8..48a59a675cd57 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -188,10 +188,11 @@ int intel_tc_port_fia_max_lane_count(struct
> intel_digital_port *dig_port) {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> struct intel_tc_port *tc = to_tc_port(dig_port);
> + enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> intel_wakeref_t wakeref;
> u32 lane_mask;
>
> - if (tc->mode != TC_PORT_DP_ALT)
> + if (!intel_phy_is_tc(i915, phy) || tc->mode != TC_PORT_DP_ALT)
> return 4;
>
> assert_tc_cold_blocked(tc);
> --
> 2.37.1
Re: [Intel-gfx] [PATCH 05/29] drm/i915/tc: Move TC port fields to a new intel_tc_port struct
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 05/29] drm/i915/tc: Move TC port fields to a new
> intel_tc_port struct
>
> Move the TC port specific fields from intel_digital_port to a new
> intel_tc_port
> struct. Pass an intel_tc_port pointer to all static functions in intel_tc.c
> keeping
> dig_port accessible for these via a pointer stored in the new struct.
>
> The next patch will allocate the intel_tc_port dynamically, allowing moving
> the
> struct definition to intel_tc.c.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 7 -
> .../drm/i915/display/intel_display_types.h| 13 +-
> drivers/gpu/drm/i915/display/intel_tc.c | 578 ++
> drivers/gpu/drm/i915/display/intel_tc.h | 26 +
> 4 files changed, 335 insertions(+), 289 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 596fd3ec19838..287159bdeb0d1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -164,13 +164,6 @@ enum tc_port {
> I915_MAX_TC_PORTS
> };
>
> -enum tc_port_mode {
> - TC_PORT_DISCONNECTED,
> - TC_PORT_TBT_ALT,
> - TC_PORT_DP_ALT,
> - TC_PORT_LEGACY,
> -};
> -
> enum aux_ch {
> AUX_CH_NONE = -1,
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index ab146b5b68bd5..0130c7b7f0232 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -54,6 +54,7 @@
> #include "intel_display_power.h"
> #include "intel_dpll_mgr.h"
> #include "intel_wm_types.h"
> +#include "intel_tc.h"
>
> struct drm_printer;
> struct __intel_global_objs_state;
> @@ -1780,17 +1781,7 @@ struct intel_digital_port {
> intel_wakeref_t ddi_io_wakeref;
> intel_wakeref_t aux_wakeref;
>
> - struct mutex tc_lock; /* protects the TypeC port mode */
> - intel_wakeref_t tc_lock_wakeref;
> - enum intel_display_power_domain tc_lock_power_domain;
> - struct delayed_work tc_disconnect_phy_work;
> - int tc_link_refcount;
> - bool tc_legacy_port:1;
> - char tc_port_name[8];
> - enum tc_port_mode tc_mode;
> - enum tc_port_mode tc_init_mode;
> - enum phy_fia tc_phy_fia;
> - u8 tc_phy_fia_idx;
> + struct intel_tc_port tc;
>
> /* protects num_hdcp_streams reference count, hdcp_port_data and
> hdcp_auth_status */
> struct mutex hdcp_mutex;
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index d2afe8b65beee..70771044a2fe8 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -15,9 +15,9 @@
> #include "intel_mg_phy_regs.h"
> #include "intel_tc.h"
>
> -static u32 tc_phy_hpd_live_status(struct intel_digital_port *dig_port);
> -static
> bool tc_phy_is_ready(struct intel_digital_port *dig_port); -static bool
> tc_phy_take_ownership(struct intel_digital_port *dig_port, bool take);
> +static u32 tc_phy_hpd_live_status(struct intel_tc_port *tc); static
> +bool tc_phy_is_ready(struct intel_tc_port *tc); static bool
> +tc_phy_take_ownership(struct intel_tc_port *tc, bool take);
>
> static const char *tc_port_mode_name(enum tc_port_mode mode) { @@ -
> 34,13 +34,24 @@ static const char *tc_port_mode_name(enum tc_port_mode
> mode)
> return names[mode];
> }
>
> +static struct intel_tc_port *to_tc_port(struct intel_digital_port
> +*dig_port) {
> + return _port->tc;
> +}
> +
> +static struct drm_i915_private *tc_to_i915(struct intel_tc_port *tc) {
> + return to_i915(tc->dig_port->base.base.dev);
> +}
> +
> static bool intel_tc_port_in_mode(struct intel_digital_port *dig_port,
> enum tc_port_mode mode)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> + struct intel_tc_port *tc = to_tc_port(dig_port);
>
> - return intel_phy_is_tc(i915, phy) && dig_port->tc_mode == mode;
> + return intel_phy_is_tc(i915, phy) && tc->mode == mode;
> }
>
> bool intel_tc_port_in_tbt_alt_mode(struct intel_digital_port *dig_port) @@ -
> 61,15 +72,17 @@ bool intel_tc_port_in_legacy_mode(struct intel_digital_port
> *dig_port) bool intel_tc_cold_requires_aux_pw(struct intel_digital_port
> *dig_port) {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + struct intel_tc_port *tc = to_tc_port(dig_port);
>
> - return (DISPLAY_VER(i915) == 11 && dig_port->tc_legacy_port) ||
> + return (DISPLAY_VER(i915) == 11 && tc->legacy_port) ||
> IS_ALDERLAKE_P(i915);
> }
>
>
[Intel-gfx] ✗ Fi.CI.BUILD: failure for cover-letter: Add vfio_device cdev for iommufd support (rev2)
== Series Details == Series: cover-letter: Add vfio_device cdev for iommufd support (rev2) URL : https://patchwork.freedesktop.org/series/114850/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/114850/revisions/2/mbox/ not applied Applying: vfio: Allocate per device file structure Applying: vfio: Refine vfio file kAPIs for KVM Applying: vfio: Accept vfio device file in the KVM facing kAPI Applying: kvm/vfio: Rename kvm_vfio_group to prepare for accepting vfio device fd Applying: kvm/vfio: Accept vfio device file from userspace error: sha1 information is lacking or useless (Documentation/virt/kvm/devices/vfio.rst). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0005 kvm/vfio: Accept vfio device file from userspace 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". Build failed, no error log produced
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: limit double GT reset to pre-MTL
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: limit double GT reset to pre-MTL
URL : https://patchwork.freedesktop.org/series/115572/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12907_full -> Patchwork_115572v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 7)
--
Missing(1): shard-rkl0
Known issues
Here are the changes found in Patchwork_115572v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2846])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-glk4/igt@gem_exec_f...@basic-deadline.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-glk6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@kms_ccs@pipe-a-bad-pixel-format-4_tiled_dg2_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271]) +49 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-apl6/igt@kms_ccs@pipe-a-bad-pixel-format-4_tiled_dg2_rc_ccs_cc.html
* igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) +1
similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-apl6/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-glk6/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area:
- shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#658])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-apl6/igt@kms_psr2...@primary-plane-update-sf-dmg-area.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][11] ([i915#7742]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-rkl-3/igt@drm_fdi...@virtual-idle.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-rkl-6/igt@drm_fdi...@virtual-idle.html
* igt@fbdev@eof:
- {shard-rkl}:[SKIP][13] ([i915#2582]) -> [PASS][14] +2 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-rkl-4/igt@fb...@eof.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-rkl-6/igt@fb...@eof.html
* igt@gem_eio@hibernate:
- {shard-tglu}: [ABORT][15] ([i915#7975]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-tglu-10/igt@gem_...@hibernate.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-tglu-9/igt@gem_...@hibernate.html
* igt@gem_eio@in-flight-contexts-10ms:
- {shard-tglu}: [TIMEOUT][17] ([i915#3063]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-tglu-7/igt@gem_...@in-flight-contexts-10ms.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-tglu-7/igt@gem_...@in-flight-contexts-10ms.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- {shard-rkl}:[FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-rkl-4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-rkl-5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [FAIL][21] ([i915#2842]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115572v1/shard-glk3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_reloc@basic-gtt:
- {shard-rkl}:[SKIP][23] ([i915#3281]) -> [PASS][24] +6 similar
issues
[23]:
Re: [Intel-gfx] [PATCH 04/29] drm/i915/tc: Use the tc_phy prefix for all TC PHY functions
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 04/29] drm/i915/tc: Use the tc_phy prefix for all
> TC
> PHY functions
>
> For consistency use the tc_phy prefix for all TC PHY functions.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 30 -
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 9fecf24b69c16..d2afe8b65beee 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -15,7 +15,7 @@
> #include "intel_mg_phy_regs.h"
> #include "intel_tc.h"
>
> -static u32 tc_port_live_status_mask(struct intel_digital_port *dig_port);
> +static u32 tc_phy_hpd_live_status(struct intel_digital_port *dig_port);
> static bool tc_phy_is_ready(struct intel_digital_port *dig_port); static
> bool
> tc_phy_take_ownership(struct intel_digital_port *dig_port, bool take);
>
> @@ -264,7 +264,7 @@ static void tc_port_fixup_legacy_flag(struct
> intel_digital_port *dig_port,
> * ICL TC PHY handlers
> * ---
> */
> -static u32 icl_tc_port_live_status_mask(struct intel_digital_port *dig_port)
> +static u32 icl_tc_phy_hpd_live_status(struct intel_digital_port
> +*dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> u32 isr_bit = i915->display.hotplug.pch_hpd[dig_port->base.hpd_pin];
> @@ -384,7 +384,7 @@ static void icl_tc_phy_connect(struct intel_digital_port
> *dig_port,
> goto out_set_tbt_alt_mode;
> }
>
> - live_status_mask = tc_port_live_status_mask(dig_port);
> + live_status_mask = tc_phy_hpd_live_status(dig_port);
> if (!(live_status_mask & (BIT(TC_PORT_DP_ALT) |
> BIT(TC_PORT_LEGACY))) &&
> !dig_port->tc_legacy_port) {
> drm_dbg_kms(>drm, "Port %s: PHY ownership not
> required (live status %02x)\n", @@ -408,7 +408,7 @@ static void
> icl_tc_phy_connect(struct intel_digital_port *dig_port,
>* Now we have to re-check the live state, in case the port recently
>* became disconnected. Not necessary for legacy mode.
>*/
> - if (!(tc_port_live_status_mask(dig_port) & BIT(TC_PORT_DP_ALT))) {
> + if (!(tc_phy_hpd_live_status(dig_port) & BIT(TC_PORT_DP_ALT))) {
> drm_dbg_kms(>drm, "Port %s: PHY sudden
> disconnect\n",
> dig_port->tc_port_name);
> goto out_release_phy;
> @@ -457,7 +457,7 @@ static void icl_tc_phy_disconnect(struct
> intel_digital_port *dig_port)
> * ADLP TC PHY handlers
> *
> */
> -static u32 adlp_tc_port_live_status_mask(struct intel_digital_port *dig_port)
> +static u32 adlp_tc_phy_hpd_live_status(struct intel_digital_port
> +*dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> @@ -535,14 +535,14 @@ static bool adlp_tc_phy_is_owned(struct
> intel_digital_port *dig_port)
> * Generic TC PHY handlers
> * ---
> */
> -static u32 tc_port_live_status_mask(struct intel_digital_port *dig_port)
> +static u32 tc_phy_hpd_live_status(struct intel_digital_port *dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>
> if (IS_ALDERLAKE_P(i915))
> - return adlp_tc_port_live_status_mask(dig_port);
> + return adlp_tc_phy_hpd_live_status(dig_port);
>
> - return icl_tc_port_live_status_mask(dig_port);
> + return icl_tc_phy_hpd_live_status(dig_port);
> }
>
> static bool tc_phy_is_ready(struct intel_digital_port *dig_port) @@ -631,7
> +631,7 @@ hpd_mask_to_tc_mode(u32 live_status_mask) static enum
> tc_port_mode tc_phy_hpd_live_mode(struct intel_digital_port *dig_port) {
> - u32 live_status_mask = tc_port_live_status_mask(dig_port);
> + u32 live_status_mask = tc_phy_hpd_live_status(dig_port);
>
> return hpd_mask_to_tc_mode(live_status_mask);
> }
> @@ -678,7 +678,7 @@ get_tc_mode_in_phy_not_owned_state(struct
> intel_digital_port *dig_port, }
>
> static enum tc_port_mode
> -intel_tc_port_get_current_mode(struct intel_digital_port *dig_port)
> +tc_phy_get_current_mode(struct intel_digital_port *dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> enum tc_port_mode live_mode = tc_phy_hpd_live_mode(dig_port);
> @@ -735,9 +735,9 @@ hpd_mask_to_target_mode(struct intel_digital_port
> *dig_port, u32 live_status_mas }
>
> static enum tc_port_mode
> -intel_tc_port_get_target_mode(struct intel_digital_port *dig_port)
> +tc_phy_get_target_mode(struct intel_digital_port *dig_port)
> {
> - u32 live_status_mask = tc_port_live_status_mask(dig_port);
> +
Re: [Intel-gfx] [PATCH 03/29] drm/i915/tc: Rename tc_phy_status_complete() to tc_phy_is_ready()
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 03/29] drm/i915/tc: Rename
> tc_phy_status_complete() to tc_phy_is_ready()
>
> For consistency rename tc_phy_status_complete() to tc_phy_is_ready()
> following the terminology of new platforms.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 099b1ec842ba2..9fecf24b69c16 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -16,7 +16,7 @@
> #include "intel_tc.h"
>
> static u32 tc_port_live_status_mask(struct intel_digital_port *dig_port);
> -static
> bool tc_phy_status_complete(struct intel_digital_port *dig_port);
> +static bool tc_phy_is_ready(struct intel_digital_port *dig_port);
> static bool tc_phy_take_ownership(struct intel_digital_port *dig_port, bool
> take);
>
> static const char *tc_port_mode_name(enum tc_port_mode mode) @@ -303,7
> +303,7 @@ static u32 icl_tc_port_live_status_mask(struct intel_digital_port
> *dig_port)
> * owned by the TBT subsystem and so switching the ownership to display is
> not
> * required.
> */
> -static bool icl_tc_phy_status_complete(struct intel_digital_port *dig_port)
> +static bool icl_tc_phy_is_ready(struct intel_digital_port *dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> u32 val;
> @@ -311,7 +311,7 @@ static bool icl_tc_phy_status_complete(struct
> intel_digital_port *dig_port)
> val = intel_de_read(i915, PORT_TX_DFLEXDPPMS(dig_port-
> >tc_phy_fia));
> if (val == 0x) {
> drm_dbg_kms(>drm,
> - "Port %s: PHY in TCCOLD, assuming not complete\n",
> + "Port %s: PHY in TCCOLD, assuming not ready\n",
> dig_port->tc_port_name);
> return false;
> }
> @@ -377,7 +377,7 @@ static void icl_tc_phy_connect(struct intel_digital_port
> *dig_port,
> u32 live_status_mask;
> int max_lanes;
>
> - if (!tc_phy_status_complete(dig_port) &&
> + if (!tc_phy_is_ready(dig_port) &&
> !drm_WARN_ON(>drm, dig_port->tc_legacy_port)) {
> drm_dbg_kms(>drm, "Port %s: PHY not ready\n",
> dig_port->tc_port_name);
> @@ -492,7 +492,7 @@ static u32 adlp_tc_port_live_status_mask(struct
> intel_digital_port *dig_port)
> * DP-alt, legacy or nothing). For TBT-alt sinks the PHY is owned by the TBT
> * subsystem and so switching the ownership to display is not required.
> */
> -static bool adlp_tc_phy_status_complete(struct intel_digital_port *dig_port)
> +static bool adlp_tc_phy_is_ready(struct intel_digital_port *dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> @@ -501,7 +501,7 @@ static bool adlp_tc_phy_status_complete(struct
> intel_digital_port *dig_port)
> val = intel_de_read(i915, TCSS_DDI_STATUS(tc_port));
> if (val == 0x) {
> drm_dbg_kms(>drm,
> - "Port %s: PHY in TCCOLD, assuming not complete\n",
> + "Port %s: PHY in TCCOLD, assuming not ready\n",
> dig_port->tc_port_name);
> return false;
> }
> @@ -545,14 +545,14 @@ static u32 tc_port_live_status_mask(struct
> intel_digital_port *dig_port)
> return icl_tc_port_live_status_mask(dig_port);
> }
>
> -static bool tc_phy_status_complete(struct intel_digital_port *dig_port)
> +static bool tc_phy_is_ready(struct intel_digital_port *dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>
> if (IS_ALDERLAKE_P(i915))
> - return adlp_tc_phy_status_complete(dig_port);
> + return adlp_tc_phy_is_ready(dig_port);
>
> - return icl_tc_phy_status_complete(dig_port);
> + return icl_tc_phy_is_ready(dig_port);
> }
>
> static bool tc_phy_is_owned(struct intel_digital_port *dig_port) @@ -590,7
> +590,7 @@ static bool tc_phy_is_connected(struct intel_digital_port *dig_port,
> {
> struct intel_encoder *encoder = _port->base;
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> - bool phy_is_ready = tc_phy_status_complete(dig_port);
> + bool phy_is_ready = tc_phy_is_ready(dig_port);
> bool phy_is_owned = tc_phy_is_owned(dig_port);
> bool is_connected;
>
> @@ -614,7 +614,7 @@ static void tc_phy_wait_for_ready(struct
> intel_digital_port *dig_port) {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>
> - if
Re: [Intel-gfx] [PATCH 02/29] drm/i915/tc: Use the adlp prefix for ADLP TC PHY functions
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 23, 2023 4:20 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 02/29] drm/i915/tc: Use the adlp prefix for ADLP
> TC
> PHY functions
>
> Use the usual adlp prefix for all ADLP specific TC PHY functions. Other ADL
> platforms don't support TC.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index b6e425c44fcb9..099b1ec842ba2 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -457,7 +457,7 @@ static void icl_tc_phy_disconnect(struct
> intel_digital_port *dig_port)
> * ADLP TC PHY handlers
> *
> */
> -static u32 adl_tc_port_live_status_mask(struct intel_digital_port *dig_port)
> +static u32 adlp_tc_port_live_status_mask(struct intel_digital_port
> +*dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> @@ -492,7 +492,7 @@ static u32 adl_tc_port_live_status_mask(struct
> intel_digital_port *dig_port)
> * DP-alt, legacy or nothing). For TBT-alt sinks the PHY is owned by the TBT
> * subsystem and so switching the ownership to display is not required.
> */
> -static bool adl_tc_phy_status_complete(struct intel_digital_port *dig_port)
> +static bool adlp_tc_phy_status_complete(struct intel_digital_port
> +*dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> @@ -509,8 +509,8 @@ static bool adl_tc_phy_status_complete(struct
> intel_digital_port *dig_port)
> return val & TCSS_DDI_STATUS_READY;
> }
>
> -static bool adl_tc_phy_take_ownership(struct intel_digital_port *dig_port,
> - bool take)
> +static bool adlp_tc_phy_take_ownership(struct intel_digital_port *dig_port,
> +bool take)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> enum port port = dig_port->base.port;
> @@ -521,7 +521,7 @@ static bool adl_tc_phy_take_ownership(struct
> intel_digital_port *dig_port,
> return true;
> }
>
> -static bool adl_tc_phy_is_owned(struct intel_digital_port *dig_port)
> +static bool adlp_tc_phy_is_owned(struct intel_digital_port *dig_port)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> enum port port = dig_port->base.port;
> @@ -540,7 +540,7 @@ static u32 tc_port_live_status_mask(struct
> intel_digital_port *dig_port)
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>
> if (IS_ALDERLAKE_P(i915))
> - return adl_tc_port_live_status_mask(dig_port);
> + return adlp_tc_port_live_status_mask(dig_port);
>
> return icl_tc_port_live_status_mask(dig_port);
> }
> @@ -550,7 +550,7 @@ static bool tc_phy_status_complete(struct
> intel_digital_port *dig_port)
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>
> if (IS_ALDERLAKE_P(i915))
> - return adl_tc_phy_status_complete(dig_port);
> + return adlp_tc_phy_status_complete(dig_port);
>
> return icl_tc_phy_status_complete(dig_port);
> }
> @@ -560,7 +560,7 @@ static bool tc_phy_is_owned(struct intel_digital_port
> *dig_port)
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>
> if (IS_ALDERLAKE_P(i915))
> - return adl_tc_phy_is_owned(dig_port);
> + return adlp_tc_phy_is_owned(dig_port);
>
> return icl_tc_phy_is_owned(dig_port);
> }
> @@ -570,7 +570,7 @@ static bool tc_phy_take_ownership(struct
> intel_digital_port *dig_port, bool take
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>
> if (IS_ALDERLAKE_P(i915))
> - return adl_tc_phy_take_ownership(dig_port, take);
> + return adlp_tc_phy_take_ownership(dig_port, take);
>
> return icl_tc_phy_take_ownership(dig_port, take); }
> --
> 2.37.1
Re: [Intel-gfx] [PATCH 01/29] drm/i915/tc: Group the TC PHY setup/query functions per platform
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Thursday, March 23, 2023 4:33 PM
> To: Deak, Imre ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 01/29] drm/i915/tc: Group the TC PHY
> setup/query functions per platform
>
> On Thu, 23 Mar 2023, Imre Deak wrote:
> > Arrange the TC PHY HW state setup/query functions into platform
> > specific and generic groups. This prepares for upcoming patches adding
> > generic TC PHY handlers and platform specific hooks for these,
> > replacing the corresponding if ladders.
> >
> > No functional changes.
> >
With the kernel doc comments fixed, this is
Reviewed-by: Mika Kahola
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_tc.c | 244
> > +---
> > 1 file changed, 130 insertions(+), 114 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > b/drivers/gpu/drm/i915/display/intel_tc.c
> > index bd8c9df5f98fe..b6e425c44fcb9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > @@ -15,6 +15,10 @@
> > #include "intel_mg_phy_regs.h"
> > #include "intel_tc.h"
> >
> > +static u32 tc_port_live_status_mask(struct intel_digital_port
> > +*dig_port); static bool tc_phy_status_complete(struct
> > +intel_digital_port *dig_port); static bool
> > +tc_phy_take_ownership(struct intel_digital_port *dig_port, bool
> > +take);
> > +
> > static const char *tc_port_mode_name(enum tc_port_mode mode) {
> > static const char * const names[] = { @@ -256,6 +260,10 @@ static
> > void tc_port_fixup_legacy_flag(struct intel_digital_port *dig_port,
> > dig_port->tc_legacy_port = !dig_port->tc_legacy_port; }
> >
> > +/**
> > + * ICL TC PHY handlers
> > + * ---
> > + */
>
> These should not be kernel-doc comments, please replace /** with /*.
>
> BR,
> Jani.
>
>
>
> > static u32 icl_tc_port_live_status_mask(struct intel_digital_port
> > *dig_port) {
> > struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev); @@
> > -287,44 +295,6 @@ static u32 icl_tc_port_live_status_mask(struct
> intel_digital_port *dig_port)
> > return mask;
> > }
> >
> > -static u32 adl_tc_port_live_status_mask(struct intel_digital_port
> > *dig_port) -{
> > - struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > - enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> > - u32 isr_bit = i915->display.hotplug.pch_hpd[dig_port->base.hpd_pin];
> > - u32 val, mask = 0;
> > -
> > - /*
> > -* On ADL-P HW/FW will wake from TCCOLD to complete the read
> access of
> > -* registers in IOM. Note that this doesn't apply to PHY and FIA
> > -* registers.
> > -*/
> > - val = intel_de_read(i915, TCSS_DDI_STATUS(tc_port));
> > - if (val & TCSS_DDI_STATUS_HPD_LIVE_STATUS_ALT)
> > - mask |= BIT(TC_PORT_DP_ALT);
> > - if (val & TCSS_DDI_STATUS_HPD_LIVE_STATUS_TBT)
> > - mask |= BIT(TC_PORT_TBT_ALT);
> > -
> > - if (intel_de_read(i915, SDEISR) & isr_bit)
> > - mask |= BIT(TC_PORT_LEGACY);
> > -
> > - /* The sink can be connected only in a single mode. */
> > - if (!drm_WARN_ON(>drm, hweight32(mask) > 1))
> > - tc_port_fixup_legacy_flag(dig_port, mask);
> > -
> > - return mask;
> > -}
> > -
> > -static u32 tc_port_live_status_mask(struct intel_digital_port
> > *dig_port) -{
> > - struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > -
> > - if (IS_ALDERLAKE_P(i915))
> > - return adl_tc_port_live_status_mask(dig_port);
> > -
> > - return icl_tc_port_live_status_mask(dig_port);
> > -}
> > -
> > /*
> > * Return the PHY status complete flag indicating that display can acquire
> > the
> > * PHY ownership. The IOM firmware sets this flag when a DP-alt or
> > legacy sink @@ -349,40 +319,6 @@ static bool
> icl_tc_phy_status_complete(struct intel_digital_port *dig_port)
> > return val & DP_PHY_MODE_STATUS_COMPLETED(dig_port-
> >tc_phy_fia_idx);
> > }
> >
> > -/*
> > - * Return the PHY status complete flag indicating that display can
> > acquire the
> > - * PHY ownership. The IOM firmware sets this flag when it's ready to
> > switch
> > - * the ownership to display, regardless of what sink is connected
> > (TBT-alt,
> > - * DP-alt, legacy or nothing). For TBT-alt sinks the PHY is owned by
> > the TBT
> > - * subsystem and so switching the ownership to display is not required.
> > - */
> > -static bool adl_tc_phy_status_complete(struct intel_digital_port
> > *dig_port) -{
> > - struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > - enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> > - u32 val;
> > -
> > - val = intel_de_read(i915, TCSS_DDI_STATUS(tc_port));
> > - if (val == 0x) {
> > - drm_dbg_kms(>drm,
> > - "Port %s: PHY in TCCOLD, assuming not complete\n",
> > -
Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
> From: Jason Gunthorpe
> Sent: Thursday, March 23, 2023 8:02 PM
>
> On Thu, Mar 23, 2023 at 03:15:20AM +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, March 22, 2023 9:43 PM
> > >
> > > On Wed, Mar 22, 2023 at 01:33:09PM +, Liu, Yi L wrote:
> > >
> > > > Thanks. So this new _INFO only reports a limited scope instead of
> > > > the full list of affected devices. Also, it is not static scope since
> > > > device
> > > > may be opened just after the _INFO returns.
> > >
> > > Yes, it would be simplest for qemu to do the query after it gains a
> > > new dev_id and then it can add the new dev_id with the correct reset
> > > group.
> >
> > I see. QEMU can decide. For now, it seems like QEMU doesn't store
> > such the info return by the existing _INFO ioctl. It is used in the hot
> > reset helper and freed before it returns. Though, I'm not sure whether
> > QEMU will store the dev_id info returned by the new _INFO. Perhaps
> > Alex can give some guidance.
>
> That seems a bit confusing, qemu should take the reset group
> information and encode it so that the guest can know it as well.
>
> If all it does is blindly invoke the hot_reset with the right
> parameters then what was the point of all this discussion?
>
> > btw. Another question about this new _INFO ioctl. If there are affected
> > devices that have not been bound to vfio driver yet, should this new _INFO
> > ioctl fail all the same with EPERM?
>
> Yeah, it should EPERM the same as the normal hot reset if it can't
> marshal the device list.
Hi Jason, Alex,
I got a draft patch to add the new _INFO? It checks if all the affected devices
are in the dev_set, and then gets the dev_id of all the opened devices within
the dev_set. There is still one thing not quite clear. It is the noiommu mode.
In this mode, there is no iommufd bind, so no dev_id. For now, I just fail this
new _INFO ioctl if there is no iommufd_device. Hence, this new _INFO is not
available for users that operating in noiommu mode. Is this acceptable?
>From e763474e255ff9805b1fb76d6b6b9ccedb61058f Mon Sep 17 00:00:00 2001
From: Yi Liu
Date: Fri, 24 Mar 2023 00:54:08 -0700
Subject: [PATCH 06/10] vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO
to report the affected devices for a given device's hot reset. It is a
list of iommufd dev_id that is opened by the user. If there is device
that is not bound to vfio driver or opened by another user, this shall
fail with -EPERM. For the noiommu mode in the vfio device cdev path,
this shall fail as no dev_id would be generated.
Signed-off-by: Yi Liu
---
drivers/vfio/pci/vfio_pci_core.c | 98
include/uapi/linux/vfio.h| 28 +
2 files changed, 126 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index b68fcba67a4b..5789933a64ae 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -1181,6 +1181,102 @@ static int vfio_pci_ioctl_reset(struct
vfio_pci_core_device *vdev,
return ret;
}
+static struct pci_dev *
+vfio_pci_dev_set_resettable(struct vfio_device_set *dev_set);
+
+static int vfio_pci_ioctl_get_pci_hot_reset_group_info(
+ struct vfio_pci_core_device *vdev,
+ struct vfio_pci_hot_reset_group_info __user *arg)
+{
+ unsigned long minsz =
+ offsetofend(struct vfio_pci_hot_reset_group_info, count);
+ struct vfio_pci_hot_reset_group_info hdr;
+ struct iommufd_ctx *iommufd, *cur_iommufd;
+ u32 count = 0, index = 0, *devices = NULL;
+ struct vfio_pci_core_device *cur;
+ bool slot = false;
+ int ret = 0;
+
+ if (copy_from_user(, arg, minsz))
+ return -EFAULT;
+
+ if (hdr.argsz < minsz)
+ return -EINVAL;
+
+ hdr.flags = 0;
+
+ /* Can we do a slot or bus reset or neither? */
+ if (!pci_probe_reset_slot(vdev->pdev->slot))
+ slot = true;
+ else if (pci_probe_reset_bus(vdev->pdev->bus))
+ return -ENODEV;
+
+ mutex_lock(>vdev.dev_set->lock);
+ if (!vfio_pci_dev_set_resettable(vdev->vdev.dev_set)) {
+ ret = -EPERM;
+ goto out_unlock;
+ }
+
+ iommufd = vfio_iommufd_physical_ictx(>vdev);
+ if (!iommufd) {
+ ret = -EPERM;
+ goto out_unlock;
+ }
+
+ /* How many devices are affected? */
+ ret = vfio_pci_for_each_slot_or_bus(vdev->pdev, vfio_pci_count_devs,
+ , slot);
+ if (ret)
+ goto out_unlock;
+
+ WARN_ON(!count); /* Should always be at least one */
+
+ /*
+* If there's enough space, fill it now, otherwise return -ENOSPC and
+* the number of devices affected.
+*/
+ if (hdr.argsz < sizeof(hdr) + (count * sizeof(*devices))) {
+ ret = -ENOSPC;
+ hdr.count = count;
+ goto
Re: [Intel-gfx] [PULL] drm-intel-fixes
On Thu, Mar 23, 2023 at 12:46:27PM +0200, Jani Nikula wrote: > > Hi Dave & Daniel - > > Otherwise a fairly regular fixes pull, except for two things: > > First, I have not gotten CI results on this. I don't know what gives. > > Second, I missed adding the hwmon revert to the tag. I accidentally > picked up the commit for the previous pull, and it shouldn't have been > there. > > > BR, > Jani. > > > > drm-intel-fixes-2023-03-23: > drm/i915 fixes for v6.3-rc4: > - Fix an MTL workaround > - Fix fbdev obj locking before vma pin > - Fix state inheritance tracking in initial commit > - Fix missing GuC error capture codes > - Fix missing debug object activation > - Fix uc init late order relative to probe error injection > - Fix perf limit reasons formatting > - Fix vblank timestamp update on seamless M/N changes > > BR, > Jani. > > The following changes since commit e8d018dd0257f744ca50a729e3d042cf2ec9da65: > > Linux 6.3-rc3 (2023-03-19 13:27:55 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-03-23 Pulled, thanks. -Daniel > > for you to fetch changes up to 22aa20e4c5dcbe6fdc480eb4fb27039b1f43217f: > > Revert "drm/i915/hwmon: Enable PL1 power limit" (2023-03-20 12:31:01 +0200) > > > drm/i915 fixes for v6.3-rc4: > - Fix an MTL workaround > - Fix fbdev obj locking before vma pin > - Fix state inheritance tracking in initial commit > - Fix missing GuC error capture codes > - Fix missing debug object activation > - Fix uc init late order relative to probe error injection > - Fix perf limit reasons formatting > - Fix vblank timestamp update on seamless M/N changes > > > Andrzej Hajda (1): > drm/i915/gt: perform uc late init after probe error injection > > Ashutosh Dixit (1): > Revert "drm/i915/hwmon: Enable PL1 power limit" > > Badal Nilawar (1): > drm/i915/mtl: Disable MC6 for MTL A step > > John Harrison (1): > drm/i915/guc: Fix missing ecodes > > Nirmoy Das (1): > drm/i915/active: Fix missing debug object activation > > Radhakrishna Sripada (1): > drm/i915/mtl: Fix Wa_16015201720 implementation > > Tejas Upadhyay (1): > drm/i915/fbdev: lock the fbdev obj before vma pin > > Ville Syrjälä (2): > drm/i915: Preserve crtc_state->inherited during state clearing > drm/i915: Update vblank timestamping stuff on seamless M/N change > > Vinay Belgaumkar (1): > drm/i915: Fix format for perf_limit_reasons > > drivers/gpu/drm/i915/display/intel_crtc.c | 8 > drivers/gpu/drm/i915/display/intel_display.c | 1 + > drivers/gpu/drm/i915/display/intel_dmc.c | 26 - > drivers/gpu/drm/i915/display/intel_fbdev.c | 24 +-- > drivers/gpu/drm/i915/gt/intel_gt.c | 4 ++-- > drivers/gpu/drm/i915/gt/intel_gt_pm.c | 27 > -- > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 2 +- > drivers/gpu/drm/i915/gt/intel_rc6.c| 8 > drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 22 + > drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 13 + > drivers/gpu/drm/i915/i915_active.c | 3 +-- > drivers/gpu/drm/i915/i915_hwmon.c | 5 - > drivers/gpu/drm/i915/i915_reg.h| 17 +--- > 13 files changed, 88 insertions(+), 72 deletions(-) > > -- > Jani Nikula, Intel Open Source Graphics Center -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v5] drm/i915/pxp: limit drm-errors or warning on firmware API failures
On Thu, 23 Mar 2023, "Ceraolo Spurio, Daniele"
wrote:
> On 3/23/2023 11:41 AM, Alan Previn wrote:
>> MESA driver is creating protected context on every driver handle
>> creation to query caps bits for app. So when running CI tests,
>> they are observing hundreds of drm_errors when enabling PXP
>> in .config but using SOC fusing or BIOS configuration that cannot
>> support PXP sessions.
>>
>> The fixes tag referenced below was to resolve a related issue
>> where we wanted to silence error messages, but that case was due
>> to outdated IFWI (firmware) that definitely needed an upgrade and
>> was, at that point, considered a one-off case as opposed to today's
>> realization that default CI was enabling PXP in kernel config for
>> all testing.
>>
>> So with this patch, let's strike a balance between issues that is
>> critical but are root-caused from HW/platform gaps (louder drm-warn
>> but just ONCE) vs other cases where it could also come from session
>> state machine (which cannot be a WARN_ONCE since it can be triggered
>> due to runtime operation events).
>>
>> Let's use helpers for these so as more functions are added in future
>> features / HW (or as FW designers continue to bless upstreaming of
>> the error codes and meanings), we only need to update the helpers.
>>
>> NOTE: Don't completely remove FW errors (via drm_debug) or else cusomer
>> apps that really needs to know that content protection failed won't
>> be aware of it.
>>
>> v2: - Add fixes tag (Trvtko)
>> v3: - Break multi-line drm_dbg strings into separate drm_dbg (Daniele)
>> - Fix couple of typecasting nits (Daniele)
>> v4: - Unsuccessful PXP FW cmd due to platform configuration shouldn't
>>use drm_WARN_once (Tvrtko), Switched to use drm_info_once.
>> v5: - Added "reported-and-tested" by Eero.
>>
>> Reported-and-tested-by: Eero Tamminen
>
> checkpatch seems to not like this tag. Maybe have 2 lines?
>
> Reported-by: ...
> Tested-by: ...
It's not that. It's that checkpatch wants a link to the report
immediately following the Reported-by: or Reported-and-tested-by:.
If you have a link to the report, by all means add it, but it's no big
deal.
BR,
Jani.
>
> Can be fixed while merging.
>
>> Fixes: b762787bf767 ("drm/i915/pxp: Use drm_dbg if arb session failed due to
>> fw version")
>> Signed-off-by: Alan Previn
>
> Reviewed-by: Daniele Ceraolo Spurio
>
> Daniele
>
>> ---
>> .../i915/pxp/intel_pxp_cmd_interface_cmn.h| 3 +
>> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 +-
>> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 77 +++
>> 3 files changed, 67 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
>> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
>> index ae9b151b7cb7..6f6541d5e49a 100644
>> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
>> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
>> @@ -18,6 +18,9 @@
>> enum pxp_status {
>> PXP_STATUS_SUCCESS = 0x0,
>> PXP_STATUS_ERROR_API_VERSION = 0x1002,
>> +PXP_STATUS_NOT_READY = 0x100e,
>> +PXP_STATUS_PLATFCONFIG_KF1_NOVERIF = 0x101a,
>> +PXP_STATUS_PLATFCONFIG_KF1_BAD = 0x101f,
>> PXP_STATUS_OP_NOT_PERMITTED = 0x4013
>> };
>>
>> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
>> b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
>> index 448cacb0465d..7de849cb6c47 100644
>> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
>> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
>> @@ -74,7 +74,7 @@ static int pxp_create_arb_session(struct intel_pxp *pxp)
>>
>> ret = pxp_wait_for_session_state(pxp, ARB_SESSION, true);
>> if (ret) {
>> -drm_err(>i915->drm, "arb session failed to go in play\n");
>> +drm_dbg(>i915->drm, "arb session failed to go in play\n");
>> return ret;
>> }
>> drm_dbg(>i915->drm, "PXP ARB session is alive\n");
>> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> index d9d248b48093..a2846b1dbbee 100644
>> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> @@ -19,6 +19,37 @@
>> #include "intel_pxp_tee.h"
>> #include "intel_pxp_types.h"
>>
>> +static bool
>> +is_fw_err_platform_config(u32 type)
>> +{
>> +switch (type) {
>> +case PXP_STATUS_ERROR_API_VERSION:
>> +case PXP_STATUS_PLATFCONFIG_KF1_NOVERIF:
>> +case PXP_STATUS_PLATFCONFIG_KF1_BAD:
>> +return true;
>> +default:
>> +break;
>> +}
>> +return false;
>> +}
>> +
>> +static const char *
>> +fw_err_to_string(u32 type)
>> +{
>> +switch (type) {
>> +case PXP_STATUS_ERROR_API_VERSION:
>> +return "ERR_API_VERSION";
>> +case PXP_STATUS_NOT_READY:
>> +return "ERR_NOT_READY";
>> +case PXP_STATUS_PLATFCONFIG_KF1_NOVERIF:
>> +case PXP_STATUS_PLATFCONFIG_KF1_BAD:
>> +return
Re: [Intel-gfx] [PULL] drm-misc-fixes
On Thu, Mar 23, 2023 at 09:24:01AM +0100, Thomas Zimmermann wrote: > Hi Dave and Daniel, > > here's the weekly PR for drm-misc-fixes. > > Best regards > Thomas > > drm-misc-fixes-2023-03-23: > Short summary of fixes pull: > > * fixes for bind and probing error handling > * panel-orientation fixes for Lenovo Book X90F > The following changes since commit 4028cbf867f70a3c599c9b0c9509334c56ed97d7: > > drm/meson: dw-hdmi: Fix devm_regulator_*get_enable*() conversion again > (2023-03-15 10:06:46 +0100) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-03-23 Pulled, thanks. -Daniel > > for you to fetch changes up to 1a70ca89d59c7c8af006d29b965a95ede0abb0da: > > drm/bridge: lt8912b: return EPROBE_DEFER if bridge is not found (2023-03-22 > 18:01:57 +0100) > > > Short summary of fixes pull: > > * fixes for bind and probing error handling > * panel-orientation fixes for Lenovo Book X90F > > > Hans de Goede (1): > drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Book X90F > > Johan Hovold (1): > drm/meson: fix missing component unbind on bind errors > > Matheus Castello (1): > drm/bridge: lt8912b: return EPROBE_DEFER if bridge is not found > > drivers/gpu/drm/bridge/lontium-lt8912b.c | 4 ++-- > drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 ++--- > drivers/gpu/drm/meson/meson_drv.c | 13 - > 3 files changed, 20 insertions(+), 10 deletions(-) > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [bug report] drm/i915/guc: Use GuC submission API version number
Hello John Harrison,
The patch 9bbba0667f37: "drm/i915/guc: Use GuC submission API version
number" from Nov 29, 2022, leads to the following Smatch static
checker warning:
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:821 intel_uc_fw_fetch()
warn: passing zero to 'ERR_PTR'
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
709 int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
710 {
711 struct intel_gt *gt = __uc_fw_to_gt(uc_fw);
712 struct drm_i915_private *i915 = gt->i915;
713 struct intel_uc_fw_file file_ideal;
714 struct drm_i915_gem_object *obj;
715 const struct firmware *fw = NULL;
716 bool old_ver = false;
717 int err;
718
719 GEM_BUG_ON(!gt->wopcm.size);
720 GEM_BUG_ON(!intel_uc_fw_is_enabled(uc_fw));
721
722 err = i915_inject_probe_error(i915, -ENXIO);
723 if (err)
724 goto fail;
725
726 __force_fw_fetch_failures(uc_fw, -EINVAL);
727 __force_fw_fetch_failures(uc_fw, -ESTALE);
728
729 err = try_firmware_load(uc_fw, );
730 memcpy(_ideal, _fw->file_wanted, sizeof(file_ideal));
731
732 /* Any error is terminal if overriding. Don't bother searching
for older versions */
733 if (err && intel_uc_fw_is_overridden(uc_fw))
734 goto fail;
735
736 while (err == -ENOENT) {
737 old_ver = true;
738
739 __uc_fw_auto_select(i915, uc_fw);
740 if (!uc_fw->file_selected.path) {
741 /*
742 * No more options! But set the path back to
something
743 * valid just in case it gets dereferenced.
744 */
745 uc_fw->file_selected.path = file_ideal.path;
746
747 /* Also, preserve the version that was really
wanted */
748 memcpy(_fw->file_wanted, _ideal,
sizeof(uc_fw->file_wanted));
749 break;
750 }
751
752 err = try_firmware_load(uc_fw, );
753 }
754
755 if (err)
756 goto fail;
757
758 err = check_fw_header(gt, fw, uc_fw);
759 if (err)
760 goto fail;
761
762 if (uc_fw->type == INTEL_UC_FW_TYPE_GUC &&
!guc_check_version_range(uc_fw))
763 goto fail;
^
Should "err" be set on this path?
764
765 if (uc_fw->file_wanted.ver.major &&
uc_fw->file_selected.ver.major) {
766 /* Check the file's major version was as it claimed */
767 if (uc_fw->file_selected.ver.major !=
uc_fw->file_wanted.ver.major) {
768 gt_notice(gt, "%s firmware %s: unexpected
version: %u.%u != %u.%u\n",
769 intel_uc_fw_type_repr(uc_fw->type),
uc_fw->file_selected.path,
770 uc_fw->file_selected.ver.major,
uc_fw->file_selected.ver.minor,
771 uc_fw->file_wanted.ver.major,
uc_fw->file_wanted.ver.minor);
772 if (!intel_uc_fw_is_overridden(uc_fw)) {
773 err = -ENOEXEC;
774 goto fail;
775 }
776 } else {
777 if (uc_fw->file_selected.ver.minor <
uc_fw->file_wanted.ver.minor)
778 old_ver = true;
779 }
780 }
781
782 if (old_ver && uc_fw->file_selected.ver.major) {
783 /* Preserve the version that was really wanted */
784 memcpy(_fw->file_wanted, _ideal,
sizeof(uc_fw->file_wanted));
785
786 gt_notice(gt, "%s firmware %s (%d.%d) is recommended,
but only %s (%d.%d) was found\n",
787 intel_uc_fw_type_repr(uc_fw->type),
788 uc_fw->file_wanted.path,
789 uc_fw->file_wanted.ver.major,
uc_fw->file_wanted.ver.minor,
790 uc_fw->file_selected.path,
791 uc_fw->file_selected.ver.major,
uc_fw->file_selected.ver.minor);
792 gt_info(gt, "Consider updating your linux-firmware pkg
or downloading from %s\n",
793 INTEL_UC_FIRMWARE_URL);
794 }
795
796 if (HAS_LMEM(i915)) {
797 obj = i915_gem_object_create_lmem_from_data(i915,
fw->data, fw->size);
798 if (!IS_ERR(obj))
799 obj->flags |=
Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
> From: Alex Williamson > Sent: Wednesday, March 22, 2023 5:01 AM > > On Tue, 21 Mar 2023 17:50:08 -0300 > Jason Gunthorpe wrote: > > > > > Though it would be nice if qemu didn't need two implementations so Yi > > I'd rather see a new info in this series as well and qemu can just > > consistently use dev_id and never bdf in iommufd mode. > > We also need to consider how libvirt determines if QEMU has the kernel > support it needs to pass file descriptors. It'd be a lot cleaner if > this aligned with the introduction of vfio cdevs. > Libvirt can check whether the kernel creates cdev for a given device via sysfs. but I'm not sure how Libvirt determines whether QEMU supports a feature that it wants to use. But sounds this is a general handshake problem as Libvirt needs to support many versions of QEMU then there must be a way for such negotiation?
Re: [Intel-gfx] [PATCH 06/14] drm/i915/tc: Factor out helpers converting HPD mask to TC mode
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 16, 2023 3:17 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 06/14] drm/i915/tc: Factor out helpers converting
> HPD mask to TC mode
>
> Factor out helpers used later in the patchset to convert an HPD status mask to
> TC mode or target TC mode.
>
> No functional changes.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 44 ++---
> 1 file changed, 33 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 2116c82831a53..002e142cc746f 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -591,11 +591,28 @@ static void tc_phy_wait_for_ready(struct
> intel_digital_port *dig_port)
> dig_port->tc_port_name);
> }
>
> +static enum tc_port_mode
> +hpd_mask_to_tc_mode(u32 live_status_mask) {
> + if (live_status_mask)
> + return fls(live_status_mask) - 1;
> +
> + return TC_PORT_DISCONNECTED;
> +}
> +
> +static enum tc_port_mode
> +tc_phy_hpd_live_mode(struct intel_digital_port *dig_port) {
> + u32 live_status_mask = tc_port_live_status_mask(dig_port);
> +
> + return hpd_mask_to_tc_mode(live_status_mask);
> +}
> +
> static enum tc_port_mode
> intel_tc_port_get_current_mode(struct intel_digital_port *dig_port) {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> - u32 live_status_mask = tc_port_live_status_mask(dig_port);
> + enum tc_port_mode live_mode = tc_phy_hpd_live_mode(dig_port);
> enum tc_port_mode mode;
>
> /*
> @@ -611,27 +628,32 @@ intel_tc_port_get_current_mode(struct
> intel_digital_port *dig_port)
> return TC_PORT_TBT_ALT;
>
> mode = dig_port->tc_legacy_port ? TC_PORT_LEGACY :
> TC_PORT_DP_ALT;
> - if (live_status_mask) {
> - enum tc_port_mode live_mode = fls(live_status_mask) - 1;
> -
> - if (!drm_WARN_ON(>drm, live_mode ==
> TC_PORT_TBT_ALT))
> - mode = live_mode;
> - }
> + if (live_mode != TC_PORT_DISCONNECTED &&
> + !drm_WARN_ON(>drm, live_mode == TC_PORT_TBT_ALT))
> + mode = live_mode;
>
> return mode;
> }
>
> static enum tc_port_mode
> -intel_tc_port_get_target_mode(struct intel_digital_port *dig_port)
> +hpd_mask_to_target_mode(u32 live_status_mask)
> {
> - u32 live_status_mask = tc_port_live_status_mask(dig_port);
> + enum tc_port_mode mode = hpd_mask_to_tc_mode(live_status_mask);
>
> - if (live_status_mask)
> - return fls(live_status_mask) - 1;
> + if (mode != TC_PORT_DISCONNECTED)
> + return mode;
>
> return TC_PORT_TBT_ALT;
> }
>
> +static enum tc_port_mode
> +intel_tc_port_get_target_mode(struct intel_digital_port *dig_port) {
> + u32 live_status_mask = tc_port_live_status_mask(dig_port);
> +
> + return hpd_mask_to_target_mode(live_status_mask);
> +}
> +
> static void intel_tc_port_reset_mode(struct intel_digital_port *dig_port,
>int required_lanes, bool force_disconnect)
> {
> --
> 2.37.1
[Intel-gfx] ✓ Fi.CI.IGT: success for Add OAM support for MTL
== Series Details == Series: Add OAM support for MTL URL : https://patchwork.freedesktop.org/series/115570/ State : success == Summary == CI Bug Log - changes from CI_DRM_12907_full -> Patchwork_115570v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (8 -> 8) -- No changes in participating hosts New tests - New tests have been introduced between CI_DRM_12907_full and Patchwork_115570v1_full: ### New IGT tests (17) ### * igt@perf@blocking@0-rcs0: - Statuses : 3 pass(s) - Exec time: [0.0] s * igt@perf@buffer-fill@0-rcs0: - Statuses : 3 pass(s) - Exec time: [0.0] s * igt@perf@enable-disable@0-rcs0: - Statuses : 4 pass(s) - Exec time: [0.0] s * igt@perf@gen12-group-concurrent-oa-buffer-read: - Statuses : 4 pass(s) 1 skip(s) - Exec time: [0.0] s * igt@perf@gen12-group-exclusive-stream-ctx-handle: - Statuses : 3 pass(s) 2 skip(s) - Exec time: [0.0] s * igt@perf@gen12-group-exclusive-stream-sample-oa: - Statuses : 3 pass(s) 3 skip(s) - Exec time: [0.0] s * igt@perf@gen12-invalid-class-instance: - Statuses : 4 pass(s) 1 skip(s) - Exec time: [0.0] s * igt@perf@gen12-mi-rpc@rcs0: - Statuses : 2 pass(s) - Exec time: [0.0] s * igt@perf@gen12-oa-tlb-invalidate@0-rcs0: - Statuses : 2 pass(s) - Exec time: [0.0] s * igt@perf@gen12-unprivileged-single-ctx-counters@rcs0: - Statuses : 2 pass(s) - Exec time: [0.0] s * igt@perf@global-sseu-config-invalid@0-rcs0: - Statuses : 5 pass(s) - Exec time: [0.0] s * igt@perf@global-sseu-config@0-rcs0: - Statuses : 5 pass(s) - Exec time: [0.0] s * igt@perf@non-zero-reason@0-rcs0: - Statuses : 5 pass(s) - Exec time: [0.0] s * igt@perf@oa-exponents@0-rcs0: - Statuses : 5 pass(s) - Exec time: [0.0] s * igt@perf@oa-formats@0-rcs0: - Statuses : 5 pass(s) - Exec time: [0.0] s * igt@perf@polling@0-rcs0: - Statuses : 4 pass(s) - Exec time: [0.0] s * igt@perf@stress-open-close@0-rcs0: - Statuses : 5 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_115570v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][1] -> [FAIL][2] ([i915#2846]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-glk4/igt@gem_exec_f...@basic-deadline.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115570v1/shard-glk7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115570v1/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115570v1/shard-apl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@i915_selftest@live@gt_heartbeat: - shard-apl: [PASS][7] -> [DMESG-FAIL][8] ([i915#5334]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-apl1/igt@i915_selftest@live@gt_heartbeat.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115570v1/shard-apl6/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_ccs@pipe-a-bad-pixel-format-4_tiled_dg2_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271]) +50 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115570v1/shard-apl2/igt@kms_ccs@pipe-a-bad-pixel-format-4_tiled_dg2_rc_ccs_cc.html * igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3886]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115570v1/shard-apl1/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html * igt@kms_cursor_crc@cursor-rapid-movement-256x85: - shard-snb: NOTRUN -> [SKIP][11] ([fdo#109271]) +59 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115570v1/shard-snb2/igt@kms_cursor_...@cursor-rapid-movement-256x85.html * igt@kms_cursor_crc@cursor-suspend@pipe-a-dp-1: - shard-apl: [PASS][12] -> [ABORT][13] ([i915#180]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12907/shard-apl6/igt@kms_cursor_crc@cursor-susp...@pipe-a-dp-1.html [13]:
Re: [Intel-gfx] [PATCH 05/14] drm/i915/tc: Wait for IOM/FW PHY initialization of legacy TC ports
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Thursday, March 16, 2023 3:17 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 05/14] drm/i915/tc: Wait for IOM/FW PHY
> initialization of legacy TC ports
>
> During boot-up/system resume, the TC PHY on legacy ports will be initialized
> by
> the IOM/TCSS firmware regardless of a sink being connected or not (as opposed
> to DP-alt/TBT ports, which the FW only inits once a sink is connected).
>
> Wait for the above initialization to complete during HW readout, so that
> connecting the PHY later will already see the expected PHY ready state.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_tc.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index e8cf3b506fb7f..2116c82831a53 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -582,6 +582,15 @@ static bool icl_tc_phy_is_connected(struct
> intel_digital_port *dig_port)
> dig_port->tc_mode == TC_PORT_LEGACY; }
>
> +static void tc_phy_wait_for_ready(struct intel_digital_port *dig_port)
> +{
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> +
> + if (wait_for(tc_phy_status_complete(dig_port), 100))
> + drm_err(>drm, "Port %s: timeout waiting for PHY
> ready\n",
This timeout value is probably based on experimentation as I couldn't find any
specs for this.
Reviewed-by: Mika Kahola
> + dig_port->tc_port_name);
> +}
> +
> static enum tc_port_mode
> intel_tc_port_get_current_mode(struct intel_digital_port *dig_port) { @@ -
> 589,6 +598,14 @@ intel_tc_port_get_current_mode(struct intel_digital_port
> *dig_port)
> u32 live_status_mask = tc_port_live_status_mask(dig_port);
> enum tc_port_mode mode;
>
> + /*
> + * For legacy ports the IOM firmware initializes the PHY during boot-up
> + * and system resume whether or not a sink is connected. Wait here for
> + * the initialization to get ready.
> + */
> + if (dig_port->tc_legacy_port)
> + tc_phy_wait_for_ready(dig_port);
> +
> if (!tc_phy_is_owned(dig_port) ||
> drm_WARN_ON(>drm, !tc_phy_status_complete(dig_port)))
> return TC_PORT_TBT_ALT;
> --
> 2.37.1
Re: [Intel-gfx] [PATCH 02/14] drm/i915/tc: Fix TC port link ref init for DP MST during HW readout
> -Original Message-
> From: Deak, Imre
> Sent: Tuesday, March 21, 2023 4:00 PM
> To: Kahola, Mika
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 02/14] drm/i915/tc: Fix TC port link ref init
> for DP
> MST during HW readout
>
> On Tue, Mar 21, 2023 at 02:06:38PM +0200, Kahola, Mika wrote:
> > > -Original Message-
> > > From: Intel-gfx On Behalf
> > > Of Imre Deak
> > > Sent: Thursday, March 16, 2023 3:17 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Subject: [Intel-gfx] [PATCH 02/14] drm/i915/tc: Fix TC port link ref
> > > init for DP MST during HW readout
> > >
> > > An enabled TC MST port holds one TC port link reference, regardless
> > > of the number of enabled streams on it, but the TC port HW readout
> > > takes one reference for each active MST stream.
> > >
> > > Fix the HW readout, taking only one reference for MST ports.
> > >
> > > This didn't cause an actual problem, since the encoder HW readout
> > > doesn't yet support reading out the MST HW state.
> > >
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/display/intel_tc.c | 20 +++-
> > > 1 file changed, 11 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > > b/drivers/gpu/drm/i915/display/intel_tc.c
> > > index 050f998284592..0b6fe96ab4759 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > > @@ -660,11 +660,14 @@ static void intel_tc_port_update_mode(struct
> > > intel_digital_port *dig_port,
> > > tc_cold_unblock(dig_port, domain, wref); }
> > >
> > > -static void
> > > -intel_tc_port_link_init_refcount(struct intel_digital_port *dig_port,
> > > - int refcount)
> > > +static void __intel_tc_port_get_link(struct intel_digital_port
> > > +*dig_port)
> > > {
> > > - dig_port->tc_link_refcount = refcount;
> > > + dig_port->tc_link_refcount++;
> > > +}
> > > +
> > > +static void __intel_tc_port_put_link(struct intel_digital_port
> > > +*dig_port) {
> > > + dig_port->tc_link_refcount--;
> > > }
> >
> > When I read this first time, I had an impression that *_put_link() and
> > *_get_link() would do something for the mst streams. However, these
> > get/put just increases or decreases the link refcount. Should we
> > rename these functions to restore the "refcount" to the function name
> > as the replaced function had?
>
> A link ref is taken whenever the port's TC mode should stay unchanged.
> This may be because the port is enabled in any mode (DP-SST, -MST or HDMI) or
> as here not necessarilty enabled, but not fully initialized yet (which is
> done only
> once intel_tc_port_sanitize_mode() is called).
Ok, this does make sense.
Reviewed-by: Mika Kahola
>
> Based on the above get/put_link here means the same thing as later when
> enabling/disabling outputs; hence I added the above functions used in both
> cases.
>
> > Otherwise, the patch does what is supposed to do here and looks ok.
> >
> > -Mika-
> >
> > >
> > > /**
> > > @@ -690,7 +693,7 @@ void intel_tc_port_init_mode(struct
> > > intel_digital_port
> > > *dig_port)
> > >
> > > dig_port->tc_mode = intel_tc_port_get_current_mode(dig_port);
> > > /* Prevent changing dig_port->tc_mode until
> > > intel_tc_port_sanitize_mode() is called. */
> > > - intel_tc_port_link_init_refcount(dig_port, 1);
> > > + __intel_tc_port_get_link(dig_port);
> > > dig_port->tc_lock_wakeref = tc_cold_block(dig_port, _port-
> > > >tc_lock_power_domain);
> > >
> > > tc_cold_unblock(dig_port, domain, tc_cold_wref); @@ -726,8
> > > +729,6 @@ void intel_tc_port_sanitize_mode(struct intel_digital_port
> *dig_port)
> > > active_links =
> > > to_intel_crtc(encoder->base.crtc)->active;
> > >
> > > drm_WARN_ON(>drm, dig_port->tc_link_refcount != 1);
> > > - intel_tc_port_link_init_refcount(dig_port, active_links);
> > > -
> > > if (active_links) {
> > > if (!icl_tc_phy_is_connected(dig_port))
> > > drm_dbg_kms(>drm, @@ -746,6 +747,7 @@
> > > void intel_tc_port_sanitize_mode(struct
> > > intel_digital_port *dig_port)
> > > dig_port->tc_port_name,
> > > tc_port_mode_name(dig_port->tc_mode));
> > > icl_tc_phy_disconnect(dig_port);
> > > + __intel_tc_port_put_link(dig_port);
> > >
> > > tc_cold_unblock(dig_port, dig_port->tc_lock_power_domain,
> > >
> > > fetch_and_zero(_port->tc_lock_wakeref));
> > > @@ -864,14 +866,14 @@ void intel_tc_port_get_link(struct
> > > intel_digital_port *dig_port,
> > > int required_lanes) {
> > > __intel_tc_port_lock(dig_port, required_lanes);
> > > - dig_port->tc_link_refcount++;
> > > + __intel_tc_port_get_link(dig_port);
> > > intel_tc_port_unlock(dig_port); }
> > >
> > > void
