[Intel-gfx] [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
We've opted to use the maximum link rate and lane count for eDP panels,
because typically the maximum supported configuration reported by the
panel has matched the native resolution requirements of the panel, and
optimizing the link has lead to problems.
With eDP 1.4 rate select method and DSC features, this is decreasingly
the case. There's a need to optimize the link parameters. Moreover,
already eDP 1.3 states fast link with fewer lanes is preferred over the
wide and slow. (Wide and slow should still be more reliable for longer
cable lengths.)
Additionally, there have been reports of panels failing on arbitrary
link configurations, although arguably all configurations they claim to
support should work.
Optimize eDP 1.4+ link config fast and narrow.
Side note: The implementation has a near duplicate of the link config
function, with just the two inner for loops turned inside out. Perhaps
there'd be a way to make this, say, more table driven to reduce the
duplication, but seems like that would lead to duplication in the table
generation. We'll also have to see how the link config optimization for
DSC turns out.
Cc: Ville Syrjälä
Cc: Manasi Navare
Cc: Rodrigo Vivi
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267
Signed-off-by: Jani Nikula
---
Untested. It's possible this helps the referenced bug. The downside is
that this patch has a bunch of dependencies that are too much to
backport to stable kernels. If the patch works, we may need to consider
hacking together an uglier backport.
---
drivers/gpu/drm/i915/intel_dp.c | 73 ++---
1 file changed, 62 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dde92e4af5d3..1ec62965ece3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1768,6 +1768,42 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
return false;
}
+/* Optimize link config in order: max bpp, min lanes, min clock */
+static bool
+intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
+ struct intel_crtc_state *pipe_config,
+ const struct link_config_limits *limits)
+{
+ struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
+ int bpp, clock, lane_count;
+ int mode_rate, link_clock, link_avail;
+
+ for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+ mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+ bpp);
+
+ for (lane_count = limits->min_lane_count;
+lane_count <= limits->max_lane_count;
+lane_count <<= 1) {
+ for (clock = limits->min_clock; clock <=
limits->max_clock; clock++) {
+ link_clock = intel_dp->common_rates[clock];
+ link_avail = intel_dp_max_data_rate(link_clock,
+ lane_count);
+
+ if (mode_rate <= link_avail) {
+ pipe_config->lane_count = lane_count;
+ pipe_config->pipe_bpp = bpp;
+ pipe_config->port_clock = link_clock;
+
+ return true;
+ }
+ }
+ }
+ }
+
+ return false;
+}
+
static bool
intel_dp_compute_link_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
@@ -1792,13 +1828,15 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
limits.min_bpp = 6 * 3;
limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
- if (intel_dp_is_edp(intel_dp)) {
+ if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
/*
* Use the maximum clock and number of lanes the eDP panel
-* advertizes being capable of. The panels are generally
-* designed to support only a single clock and lane
-* configuration, and typically these values correspond to the
-* native resolution of the panel.
+* advertizes being capable of. The eDP 1.3 and earlier panels
+* are generally designed to support only a single clock and
+* lane configuration, and typically these values correspond to
+* the native resolution of the panel. With eDP 1.4 rate select
+* and DSC, this is decreasingly the case, and we need to be
+* able to select less than maximum link config.
*/
limits.min_lane_count = limits.max_lane_count;
limits.min_clock = limits
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Create mock_engine() under struct_mutex
Quoting Patchwork (2018-05-09 03:41:59) > == Series Details == > > Series: drm/i915/selftests: Create mock_engine() under struct_mutex > URL : https://patchwork.freedesktop.org/series/42898/ > State : success > > == Summary == > > = CI Bug Log - changes from CI_DRM_4160_full -> Patchwork_8951_full = > > == Summary - WARNING == > > Minor unknown changes coming with Patchwork_8951_full need to be verified > manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_8951_full, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/42898/revisions/1/mbox/ > > == Possible new issues == > > Here are the unknown changes that may have been introduced in > Patchwork_8951_full: > > === IGT changes === > > Warnings > > igt@drv_selftest@live_execlists: > shard-apl: PASS -> SKIP +1 > > igt@drv_selftest@live_hangcheck: > shard-apl: DMESG-WARN -> DMESG-FAIL Applied, but more fallout to fix. Thanks, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/execlists: Use rmb() to order CSB reads
Quoting Chris Wilson (2018-05-08 17:30:41)
> We assume that the CSB is written using the normal ringbuffer
> coherency protocols, as outlined in kernel/events/ring_buffer.c:
>
> * (HW) (DRIVER)
> *
> * if (LOAD ->data_tail) {LOAD ->data_head
> * (A) smp_rmb() (C)
> * STORE $data LOAD $data
> * smp_wmb() (B) smp_mb()(D)
> * STORE ->data_head STORE ->data_tail
> * }
>
> So we assume that the HW fulfils its ordering requirements (B), and so
> we should use a complimentary rmb (C) to ensure that our read of its
> WRITE pointer is completed before we start accessing the data.
>
> The final mb (D) is implied by the uncached mmio we perform to inform
> the HW of our READ pointer.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=105064
-References: https://bugs.freedesktop.org/show_bug.cgi?id=105064
Resolved as ba74cb10c775 ("drm/i915/execlists: Delay writing to ELSP
until HW has processed the previous write")
So the other possibility is that this fixes up the issue with VT-d
latency.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries
On Wed, 09 May 2018, Feng Tang wrote: > On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: >> On Wed, 09 May 2018, Feng Tang wrote: >> >> Well if it's edp probing, then atm we do need to block since we have >> >> no support for panel hotplugging. And userspace generally no >> >> expectations that built-in panels come&go. async_synchronize_full >> >> making our fbdev code less async than desired is kinda a different >> >> story I think here. First step would be trying to figure out why we >> >> even bother with edp probing on this platform, when the thing isn't >> >> there. Sounds like broken VBT. >> > >> > Hi Daniel, >> > >> > Here are some of the VBT and DPCD related logs on my A3900 (bxt + GEN9 LP) >> > based NUC. but I don't have the knowledge to tell if the VBT is broken :) >> >> Please run current upstream drm-tip when you're suggesting changes to >> upstream code. Looks like you're running at most v4.14. This can't be >> emphasized enough. We can't and won't merge the changes unless they make >> sense with current code. > > Yes, I understand, the patch posted was created right after git-pulling > Linus' tree, and back-ported to test with 4.14 kernel. > >> >> As to vbt, please send me /sys/kernel/debug/dri/0/i915_vbt. > > Sure. as attached Your VBT claims the device has an eDP panel. Does it have one or not? BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries
On Wed, May 09, 2018 at 10:53:53AM +0300, Jani Nikula wrote: > On Wed, 09 May 2018, Feng Tang wrote: > > On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: > >> On Wed, 09 May 2018, Feng Tang wrote: > >> >> Well if it's edp probing, then atm we do need to block since we have > >> >> no support for panel hotplugging. And userspace generally no > >> >> expectations that built-in panels come&go. async_synchronize_full > >> >> making our fbdev code less async than desired is kinda a different > >> >> story I think here. First step would be trying to figure out why we > >> >> even bother with edp probing on this platform, when the thing isn't > >> >> there. Sounds like broken VBT. > >> > > >> > Hi Daniel, > >> > > >> > Here are some of the VBT and DPCD related logs on my A3900 (bxt + GEN9 > >> > LP) > >> > based NUC. but I don't have the knowledge to tell if the VBT is broken :) > >> > >> Please run current upstream drm-tip when you're suggesting changes to > >> upstream code. Looks like you're running at most v4.14. This can't be > >> emphasized enough. We can't and won't merge the changes unless they make > >> sense with current code. > > > > Yes, I understand, the patch posted was created right after git-pulling > > Linus' tree, and back-ported to test with 4.14 kernel. > > > >> > >> As to vbt, please send me /sys/kernel/debug/dri/0/i915_vbt. > > > > Sure. as attached > > Your VBT claims the device has an eDP panel. Does it have one or not? After asking around, our platform (BXT NUC) does have a eDP interface (someone has tested with a eDP screen), but most of our platforms are connected with 2 HDMI LCD monitors. Thanks, Feng ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Only switch to kernel context when locked
== Series Details == Series: drm/i915/selftests: Only switch to kernel context when locked URL : https://patchwork.freedesktop.org/series/42922/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4161 -> Patchwork_8956 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8956 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8956, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42922/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8956: === IGT changes === Possible regressions igt@gvt_basic@invalid-placeholder-test: fi-bwr-2160:SKIP -> INCOMPLETE Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8956 that come from known issues: === IGT changes === Issues hit igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#106103, fdo#102614) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (40 -> 37) == Additional (1): fi-glk-j4005 Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq == Build changes == * Linux: CI_DRM_4161 -> Patchwork_8956 CI_DRM_4161: f20dbaa0dfba8b33c677c084d39fc730309c5af2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8956: 4a647a80781ebba5387f68d93c22120c05aa776b @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Linux commits == 4a647a80781e drm/i915/selftests: Only switch to kernel context when locked == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8956/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Only switch to kernel context when locked
Chris Wilson writes:
> In igt_flush_test() we try to switch back to the kernel context, but we
> are only able to do so when we care called with struct_mutex held.
s/care/are
>
> More CI fallout from lockdep being temporarily suppressed :(
Kind words.../o\
Reviewed-by: Mika Kuoppala
>
> Fixes: 4cdf65ce8cc2 ("drm/i915/selftests: Return to kernel context after each
> test")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/selftests/igt_flush_test.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/igt_flush_test.c
> b/drivers/gpu/drm/i915/selftests/igt_flush_test.c
> index 7f35bddc2e95..0d06f559243f 100644
> --- a/drivers/gpu/drm/i915/selftests/igt_flush_test.c
> +++ b/drivers/gpu/drm/i915/selftests/igt_flush_test.c
> @@ -57,7 +57,8 @@ int igt_flush_test(struct drm_i915_private *i915, unsigned
> int flags)
>
> cond_resched();
>
> - if (i915_gem_switch_to_kernel_context(i915)) {
> + if (flags & I915_WAIT_LOCKED &&
> + i915_gem_switch_to_kernel_context(i915)) {
> pr_err("Failed to switch back to kernel context; declaring
> wedged\n");
> i915_gem_set_wedged(i915);
> }
> --
> 2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
== Series Details == Series: drm/i915/dp: optimize eDP 1.4+ link config fast and narrow URL : https://patchwork.freedesktop.org/series/42923/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4161 -> Patchwork_8957 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8957 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8957, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42923/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8957: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8957 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_frontbuffer_tracking@basic: fi-cnl-y3: PASS -> FAIL (fdo#104724, fdo#103167) igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-skl-guc: PASS -> FAIL (fdo#103191, fdo#104724) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cnl-y3: PASS -> DMESG-WARN (fdo#104951) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 == Participating hosts (40 -> 37) == Additional (1): fi-glk-j4005 Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq == Build changes == * Linux: CI_DRM_4161 -> Patchwork_8957 CI_DRM_4161: f20dbaa0dfba8b33c677c084d39fc730309c5af2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8957: 14195da35f10255240ce36a4f0c2628ba2340110 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Linux commits == 14195da35f10 drm/i915/dp: optimize eDP 1.4+ link config fast and narrow == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8957/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Only switch to kernel context when locked
== Series Details == Series: drm/i915/selftests: Only switch to kernel context when locked URL : https://patchwork.freedesktop.org/series/42922/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4161 -> Patchwork_8958 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8958 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8958, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42922/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8958: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8958 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 == Participating hosts (40 -> 37) == Additional (1): fi-glk-j4005 Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq == Build changes == * Linux: CI_DRM_4161 -> Patchwork_8958 CI_DRM_4161: f20dbaa0dfba8b33c677c084d39fc730309c5af2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8958: 19d6def0ed772cfbbfe18c9acf717b08eae827ac @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Linux commits == 19d6def0ed77 drm/i915/selftests: Only switch to kernel context when locked == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8958/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, Not quite the explosion you were afraid of, but three fixes to avoid a some WARNs and *ERROR*s. I'm still trying to get an Ack for merging the ICL stolen early quirks through our tree and then including them in the next -fixes (I know we're bit late :( ) I'm travelling for the rest of the week related to a public holiday, so for emergencies ping Jani and Rodrigo. Regards, Joonas drm-intel-fixes-2018-05-09: - Increase LVDS panel timeout to 5s to avoid spurious *ERROR* - Fix 2 WARNS: BIOS framebuffer related (FDO #105992) and eDP cdclk mismatch The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb: Linux 4.17-rc4 (2018-05-06 16:57:38 -1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-05-09 for you to fetch changes up to e8f48f96db7e482995743f461b3e8a5c1a102533: drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log (2018-05-08 15:56:13 +0300) - Increase LVDS panel timeout to 5s to avoid spurious *ERROR* - Fix 2 WARNS: BIOS framebuffer related (FDO #105992) and eDP cdclk mismatch Florent Flament (1): drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log Rodrigo Vivi (1): drm/i915: Adjust eDP's logical vco in a reliable place. Ville Syrjälä (1): drm/i915: Correctly populate user mode h/vdisplay with pipe src size during readout drivers/gpu/drm/i915/intel_cdclk.c | 41 drivers/gpu/drm/i915/intel_display.c | 2 ++ drivers/gpu/drm/i915/intel_dp.c | 20 -- drivers/gpu/drm/i915/intel_lvds.c| 3 ++- 4 files changed, 41 insertions(+), 25 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915: reprogram NOA muxes on context switch when using perf
Quoting Lionel Landwerlin (2018-05-08 19:03:45)
> If some of the contexts submitting workloads to the GPU have been
> configured to shutdown slices/subslices, we might loose the NOA
> configurations written in the NOA muxes. We need to reprogram them
> when we detect a powergating configuration change.
>
> In this change i915/perf is responsible for setting up a reprogramming
> batchbuffer which we execute just before the userspace submitted
> batchbuffer. We do this while preemption is still disable, only if
> needed. The decision to execute this reprogramming batchbuffer is made
> when we assign a request to an execlist port.
>
> v2: Only reprogram when detecting configuration changes (Chris/Lionel)
>
> Signed-off-by: Lionel Landwerlin
> ---
> drivers/gpu/drm/i915/i915_drv.h | 6 ++
> drivers/gpu/drm/i915/i915_perf.c | 108 ++
> drivers/gpu/drm/i915/i915_request.h | 6 ++
> drivers/gpu/drm/i915/intel_gpu_commands.h | 1 +
> drivers/gpu/drm/i915/intel_lrc.c | 59 +++-
> drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +
> drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +
> 7 files changed, 183 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 04e27806e581..07cdbfb4ad7a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1461,6 +1461,12 @@ struct i915_perf_stream {
> * @oa_config: The OA configuration used by the stream.
> */
> struct i915_oa_config *oa_config;
> +
> + /**
> +* @noa_reprogram_vma: A batchbuffer reprogramming the NOA muxes, used
> +* after switching powergating configurations.
> +*/
> + struct i915_vma *noa_reprogram_vma;
> };
>
> /**
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 5b279a82445a..1b9e3d6a53a2 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -1691,6 +1691,96 @@ static int gen8_emit_oa_config(struct i915_request *rq,
> return 0;
> }
>
> +#define MAX_LRI_SIZE (125U)
> +
> +static u32 noa_reprogram_bb_size(struct i915_oa_config *oa_config)
> +{
> + u32 n_lri;
> +
> + /* Very unlikely but possible that we have no muxes to configure. */
> + if (!oa_config->mux_regs_len)
> + return 0;
> +
> + n_lri = (oa_config->mux_regs_len / MAX_LRI_SIZE) +
> + (oa_config->mux_regs_len % MAX_LRI_SIZE) != 0;
> +
> + return n_lri * 4 + oa_config->mux_regs_len * 8 + /*
> MI_LOAD_REGISTER_IMMs */
> + 6 * 4 + /* PIPE_CONTROL */
> + 4; /* MI_BATCH_BUFFER_END */
> +}
> +
> +static int
> +alloc_noa_reprogram_bo(struct i915_perf_stream *stream)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> + struct i915_oa_config *oa_config = stream->oa_config;
> + struct drm_i915_gem_object *bo;
> + struct i915_vma *vma;
> + u32 buffer_size;
> + u32 *cs;
> + int i, ret, n_loaded_regs;
> +
> + buffer_size = ALIGN(noa_reprogram_bb_size(oa_config), PAGE_SIZE);
> + if (buffer_size == 0)
> + return 0;
> +
> + bo = i915_gem_object_create(dev_priv, buffer_size);
> + if (IS_ERR(bo)) {
> + DRM_ERROR("Failed to allocate NOA reprogramming buffer\n");
> + return PTR_ERR(bo);
> + }
> +
> + cs = i915_gem_object_pin_map(bo, I915_MAP_WB);
> + if (IS_ERR(cs)) {
> + ret = PTR_ERR(cs);
> + goto err_unref_bo;
> + }
> +
> + n_loaded_regs = 0;
> + for (i = 0; i < oa_config->mux_regs_len; i++) {
> + if ((n_loaded_regs % MAX_LRI_SIZE) == 0) {
> + u32 n_lri = min(oa_config->mux_regs_len -
> n_loaded_regs,
> + MAX_LRI_SIZE);
> + *cs++ = MI_LOAD_REGISTER_IMM(n_lri);
> + }
> +
> + *cs++ = i915_mmio_reg_offset(oa_config->mux_regs[i].addr);
> + *cs++ = oa_config->mux_regs[i].value;
> + n_loaded_regs++;
> + }
> +
> + cs = gen8_emit_pipe_control(cs, PIPE_CONTROL_MMIO_WRITE, 0);
What's the pc for? Isn't it a bit dangerous to request a mmio write to
to reg 0?
> +
> + *cs++ = MI_BATCH_BUFFER_END;
> +
> + i915_gem_object_unpin_map(bo);
> +
> + ret = i915_gem_object_set_to_gtt_domain(bo, false);
> + if (ret)
> + goto err_unref_bo;
> +
> + vma = i915_vma_instance(bo, &dev_priv->ggtt.base, NULL);
> + if (IS_ERR(vma)) {
> + ret = PTR_ERR(vma);
> + goto err_unref_bo;
> + }
> +
> + ret = i915_vma_pin(vma, 0, 0, PIN_USER | PIN_GLOBAL);
> + if (ret)
> + goto err_unref_vma;
No GGTT access, so just PIN_USER for GPU access.
> + stream->noa_reprogram_vma = vma;
> +
>
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915: reprogram NOA muxes on context switch when using perf
Quoting Chris Wilson (2018-05-09 09:59:09)
> Quoting Lionel Landwerlin (2018-05-08 19:03:45)
> > If some of the contexts submitting workloads to the GPU have been
> > configured to shutdown slices/subslices, we might loose the NOA
> > configurations written in the NOA muxes. We need to reprogram them
> > when we detect a powergating configuration change.
> >
> > In this change i915/perf is responsible for setting up a reprogramming
> > batchbuffer which we execute just before the userspace submitted
> > batchbuffer. We do this while preemption is still disable, only if
> > needed. The decision to execute this reprogramming batchbuffer is made
> > when we assign a request to an execlist port.
> >
> > v2: Only reprogram when detecting configuration changes (Chris/Lionel)
> >
> > Signed-off-by: Lionel Landwerlin
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 6 ++
> > drivers/gpu/drm/i915/i915_perf.c | 108 ++
> > drivers/gpu/drm/i915/i915_request.h | 6 ++
> > drivers/gpu/drm/i915/intel_gpu_commands.h | 1 +
> > drivers/gpu/drm/i915/intel_lrc.c | 59 +++-
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +
> > 7 files changed, 183 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 04e27806e581..07cdbfb4ad7a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1461,6 +1461,12 @@ struct i915_perf_stream {
> > * @oa_config: The OA configuration used by the stream.
> > */
> > struct i915_oa_config *oa_config;
> > +
> > + /**
> > +* @noa_reprogram_vma: A batchbuffer reprogramming the NOA muxes,
> > used
> > +* after switching powergating configurations.
> > +*/
> > + struct i915_vma *noa_reprogram_vma;
> > };
> >
> > /**
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> > b/drivers/gpu/drm/i915/i915_perf.c
> > index 5b279a82445a..1b9e3d6a53a2 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -1691,6 +1691,96 @@ static int gen8_emit_oa_config(struct i915_request
> > *rq,
> > return 0;
> > }
> >
> > +#define MAX_LRI_SIZE (125U)
> > +
> > +static u32 noa_reprogram_bb_size(struct i915_oa_config *oa_config)
> > +{
> > + u32 n_lri;
> > +
> > + /* Very unlikely but possible that we have no muxes to configure. */
> > + if (!oa_config->mux_regs_len)
> > + return 0;
> > +
> > + n_lri = (oa_config->mux_regs_len / MAX_LRI_SIZE) +
> > + (oa_config->mux_regs_len % MAX_LRI_SIZE) != 0;
> > +
> > + return n_lri * 4 + oa_config->mux_regs_len * 8 + /*
> > MI_LOAD_REGISTER_IMMs */
> > + 6 * 4 + /* PIPE_CONTROL */
> > + 4; /* MI_BATCH_BUFFER_END */
> > +}
> > +
> > +static int
> > +alloc_noa_reprogram_bo(struct i915_perf_stream *stream)
> > +{
> > + struct drm_i915_private *dev_priv = stream->dev_priv;
> > + struct i915_oa_config *oa_config = stream->oa_config;
> > + struct drm_i915_gem_object *bo;
> > + struct i915_vma *vma;
> > + u32 buffer_size;
> > + u32 *cs;
> > + int i, ret, n_loaded_regs;
> > +
> > + buffer_size = ALIGN(noa_reprogram_bb_size(oa_config), PAGE_SIZE);
> > + if (buffer_size == 0)
> > + return 0;
> > +
> > + bo = i915_gem_object_create(dev_priv, buffer_size);
> > + if (IS_ERR(bo)) {
> > + DRM_ERROR("Failed to allocate NOA reprogramming buffer\n");
> > + return PTR_ERR(bo);
> > + }
> > +
> > + cs = i915_gem_object_pin_map(bo, I915_MAP_WB);
> > + if (IS_ERR(cs)) {
> > + ret = PTR_ERR(cs);
> > + goto err_unref_bo;
> > + }
> > +
> > + n_loaded_regs = 0;
> > + for (i = 0; i < oa_config->mux_regs_len; i++) {
> > + if ((n_loaded_regs % MAX_LRI_SIZE) == 0) {
> > + u32 n_lri = min(oa_config->mux_regs_len -
> > n_loaded_regs,
> > + MAX_LRI_SIZE);
> > + *cs++ = MI_LOAD_REGISTER_IMM(n_lri);
> > + }
> > +
> > + *cs++ = i915_mmio_reg_offset(oa_config->mux_regs[i].addr);
> > + *cs++ = oa_config->mux_regs[i].value;
> > + n_loaded_regs++;
> > + }
> > +
> > + cs = gen8_emit_pipe_control(cs, PIPE_CONTROL_MMIO_WRITE, 0);
>
> What's the pc for? Isn't it a bit dangerous to request a mmio write to
> to reg 0?
>
> > +
> > + *cs++ = MI_BATCH_BUFFER_END;
> > +
> > + i915_gem_object_unpin_map(bo);
> > +
> > + ret = i915_gem_object_set_to_gtt_domain(bo, false);
> > + if (ret)
> > + goto err_unref_bo;
> > +
> > + vma = i915_vma_instance(bo, &dev_priv->ggtt.base, NULL);
> > + if (IS_ERR(vma)) {
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915: reprogram NOA muxes on context switch when using perf
On 09/05/18 09:59, Chris Wilson wrote: + + *cs++ = MI_BATCH_BUFFER_START_GEN8 | MI_BATCH_SECOND_LEVEL; You are not a second level batch. You are calling from the ring to a global address of _0_. + *cs++ = 0; low 32bits = 0 + *cs++ = i915_ggtt_offset(stream->noa_reprogram_vma); high 32bits = address you wanted. (order reversed) How is this not hanging my machine is beyond me... :( ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dp: fix spelling mistake: "seqeuncer" -> "sequencer"
From: Colin Ian King Trivial fix to spelling mistake in WARN warning message text Signed-off-by: Colin Ian King --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index dde92e4af5d3..914389f67458 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -513,7 +513,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp) uint32_t DP; if (WARN(I915_READ(intel_dp->output_reg) & DP_PORT_EN, -"skipping pipe %c power seqeuncer kick due to port %c being active\n", +"skipping pipe %c power sequencer kick due to port %c being active\n", pipe_name(pipe), port_name(intel_dig_port->base.port))) return; -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Only switch to kernel context when locked
Quoting Patchwork (2018-05-09 09:57:55) > == Series Details == > > Series: drm/i915/selftests: Only switch to kernel context when locked > URL : https://patchwork.freedesktop.org/series/42922/ > State : success > > == Summary == > > = CI Bug Log - changes from CI_DRM_4161 -> Patchwork_8958 = > > == Summary - WARNING == > > Minor unknown changes coming with Patchwork_8958 need to be verified > manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_8958, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/42922/revisions/1/mbox/ Pushed it before we have too many CI runs with the error. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915: reprogram NOA muxes on context switch when using perf
On 09/05/18 10:05, Chris Wilson wrote: Could there be any more pointer chasing? Thinking about more about how to make this part cleaner, could we not store the engine->noa_batch and then this all becomes vma = engine->noa_batch; if (vma) return; Locking! Missed it in the first pass, but we are unlocked here... That also ties into lifetimes. I'm thinking more like ctx->noa_batch with that being pinned along with the context. We need something along those lines to track the locking/lifetime. -Chris In another series tracking pid of submitted requests, I used "empty" requests to change the state of the engine. I could use that approach to message-pass what needs to be used in the engine submission. - Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/7] drm/i915/execlists: Make submission tasklet hardirq safe
Quoting Chris Wilson (2018-05-08 21:59:20)
> Quoting Tvrtko Ursulin (2018-05-08 18:45:44)
> >
> > On 07/05/2018 14:57, Chris Wilson wrote:
> > > Prepare to allow the execlists submission to be run from underneath a
> > > hardirq timer context (and not just the current softirq context) as is
> > > required for fast preemption resets and context switches.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/intel_lrc.c | 42 ++--
> > > 1 file changed, 29 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > > b/drivers/gpu/drm/i915/intel_lrc.c
> > > index f9f4064dec0e..15c373ea5b7e 100644
> > > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > > @@ -357,10 +357,13 @@ execlists_unwind_incomplete_requests(struct
> > > intel_engine_execlists *execlists)
> > > {
> > > struct intel_engine_cs *engine =
> > > container_of(execlists, typeof(*engine), execlists);
> > > + unsigned long flags;
> > > +
> > > + spin_lock_irqsave(&engine->timeline.lock, flags);
> > >
> > > - spin_lock_irq(&engine->timeline.lock);
> > > __unwind_incomplete_requests(engine);
> > > - spin_unlock_irq(&engine->timeline.lock);
> > > +
> > > + spin_unlock_irqrestore(&engine->timeline.lock, flags);
> > > }
> > >
> > > static inline void
> > > @@ -554,7 +557,7 @@ static void inject_preempt_context(struct
> > > intel_engine_cs *engine)
> > > execlists_set_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT);
> > > }
> > >
> > > -static void execlists_dequeue(struct intel_engine_cs *engine)
> > > +static bool __execlists_dequeue(struct intel_engine_cs *engine)
> > > {
> > > struct intel_engine_execlists * const execlists =
> > > &engine->execlists;
> > > struct execlist_port *port = execlists->port;
> > > @@ -564,6 +567,8 @@ static void execlists_dequeue(struct intel_engine_cs
> > > *engine)
> > > struct rb_node *rb;
> > > bool submit = false;
> > >
> > > + lockdep_assert_held(&engine->timeline.lock);
> > > +
> > > /* Hardware submission is through 2 ports. Conceptually each port
> > >* has a (RING_START, RING_HEAD, RING_TAIL) tuple. RING_START is
> > >* static for a context, and unique to each, so we only execute
> > > @@ -585,7 +590,6 @@ static void execlists_dequeue(struct intel_engine_cs
> > > *engine)
> > >* and context switches) submission.
> > >*/
> > >
> > > - spin_lock_irq(&engine->timeline.lock);
> > > rb = execlists->first;
> > > GEM_BUG_ON(rb_first(&execlists->queue) != rb);
> > >
> > > @@ -600,7 +604,7 @@ static void execlists_dequeue(struct intel_engine_cs
> > > *engine)
> > > EXECLISTS_ACTIVE_USER));
> > > GEM_BUG_ON(!port_count(&port[0]));
> > > if (port_count(&port[0]) > 1)
> > > - goto unlock;
> > > + return false;
> > >
> > > /*
> > >* If we write to ELSP a second time before the HW has had
> > > @@ -610,11 +614,11 @@ static void execlists_dequeue(struct
> > > intel_engine_cs *engine)
> > >* the HW to indicate that it has had a chance to respond.
> > >*/
> > > if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_HWACK))
> > > - goto unlock;
> > > + return false;
> > >
> > > if (need_preempt(engine, last, execlists->queue_priority)) {
> > > inject_preempt_context(engine);
> > > - goto unlock;
> > > + return false;
> > > }
> > >
> > > /*
> > > @@ -639,7 +643,7 @@ static void execlists_dequeue(struct intel_engine_cs
> > > *engine)
> > >* priorities of the ports haven't been switch.
> > >*/
> > > if (port_count(&port[1]))
> > > - goto unlock;
> > > + return false;
> > >
> > > /*
> > >* WaIdleLiteRestore:bdw,skl
> > > @@ -744,13 +748,25 @@ static void execlists_dequeue(struct
> > > intel_engine_cs *engine)
> > > /* We must always keep the beast fed if we have work piled up */
> > > GEM_BUG_ON(execlists->first && !port_isset(execlists->port));
> > >
> > > -unlock:
> > > - spin_unlock_irq(&engine->timeline.lock);
> > > -
> > > - if (submit) {
> > > + /* Re-evaluate the executing context setup after each preemptive
> > > kick */
> > > + if (last)
> > > execlists_user_begin(execlists, execlists->port);
> > > +
> > > + return submit;
> > > +}
> > > +
> > > +static void execlists_dequeue(struct intel_engine_cs *engine)
> > > +{
> > > + struct intel_engine_execlists * const execlists =
> > > &engine->execlists;
> > > + unsigned l
Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries
On Wed, 09 May 2018, Feng Tang wrote: > On Wed, May 09, 2018 at 10:53:53AM +0300, Jani Nikula wrote: >> On Wed, 09 May 2018, Feng Tang wrote: >> > On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: >> >> On Wed, 09 May 2018, Feng Tang wrote: >> >> >> Well if it's edp probing, then atm we do need to block since we have >> >> >> no support for panel hotplugging. And userspace generally no >> >> >> expectations that built-in panels come&go. async_synchronize_full >> >> >> making our fbdev code less async than desired is kinda a different >> >> >> story I think here. First step would be trying to figure out why we >> >> >> even bother with edp probing on this platform, when the thing isn't >> >> >> there. Sounds like broken VBT. >> >> > >> >> > Hi Daniel, >> >> > >> >> > Here are some of the VBT and DPCD related logs on my A3900 (bxt + GEN9 >> >> > LP) >> >> > based NUC. but I don't have the knowledge to tell if the VBT is broken >> >> > :) >> >> >> >> Please run current upstream drm-tip when you're suggesting changes to >> >> upstream code. Looks like you're running at most v4.14. This can't be >> >> emphasized enough. We can't and won't merge the changes unless they make >> >> sense with current code. >> > >> > Yes, I understand, the patch posted was created right after git-pulling >> > Linus' tree, and back-ported to test with 4.14 kernel. >> > >> >> >> >> As to vbt, please send me /sys/kernel/debug/dri/0/i915_vbt. >> > >> > Sure. as attached >> >> Your VBT claims the device has an eDP panel. Does it have one or not? > > After asking around, our platform (BXT NUC) does have a eDP interface (someone > has tested with a eDP screen), but most of our platforms are connected > with 2 HDMI LCD monitors. Sounds like you should have a different VBT for the cases where you ship with/without eDP connected. As you've noticed, we generally try pretty hard to talk to the panel if VBT says it's there, to avoid black screens which are a much worse scenario than delays in detection. BR, Jani. > > Thanks, > Feng -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: fix spelling mistake: "seqeuncer" -> "sequencer"
On Wed, 09 May 2018, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in WARN warning message text While at it, would you mind fixing the plethora of "seqeuencer" typos in the comments in the same file please? BR, Jani. > > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/i915/intel_dp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index dde92e4af5d3..914389f67458 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -513,7 +513,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp) > uint32_t DP; > > if (WARN(I915_READ(intel_dp->output_reg) & DP_PORT_EN, > - "skipping pipe %c power seqeuncer kick due to port %c being > active\n", > + "skipping pipe %c power sequencer kick due to port %c being > active\n", >pipe_name(pipe), port_name(intel_dig_port->base.port))) > return; -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 01/40] drm: hdcp2.2 authentication msg definitions
>-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Ramalingam C >Sent: Tuesday, April 3, 2018 7:27 PM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk; >jani.nik...@linux.intel.com; Winkler, Tomas ; >Usyskin, Alexander >Cc: Vivi, Rodrigo >Subject: [Intel-gfx] [PATCH v3 01/40] drm: hdcp2.2 authentication msg >definitions > >This patch defines the hdcp2.2 protocol messages for the Drop redundant "the" and one of the hdcp2.2. Not required. >HDCP2.2 authentication. > >v2: > bit_fields are removed. Instead bitmasking used. [Tomas and Jani] > prefix HDCP_2_2_ is added to the macros. [Tomas] >v3: > No Changes. > >Signed-off-by: Ramalingam C >--- > include/drm/drm_hdcp.h | 183 >+ > 1 file changed, 183 insertions(+) > >diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index >562fa7df2637..5e0a5ed1a08e 100644 >--- a/include/drm/drm_hdcp.h >+++ b/include/drm/drm_hdcp.h >@@ -38,4 +38,187 @@ > #define DRM_HDCP_DDC_BSTATUS 0x41 > #define DRM_HDCP_DDC_KSV_FIFO 0x43 > >+#define DRM_HDCP_1_4_SRM_ID 0x8 >+#define DRM_HDCP_1_4_VRL_LENGTH_SIZE 3 >+#define DRM_HDCP_1_4_DCP_SIG_SIZE 40 >+ >+/** >+ * Protocol message definition for HDCP2.2 specification */ Multi Line comment style not needed here. >+ >+#define HDCP_STREAM_TYPE0 0x00 >+#define HDCP_STREAM_TYPE1 0x01 >+ >+/* HDCP2.2 Msg IDs */ >+#define HDCP_2_2_NULL_MSG 1 >+#define HDCP_2_2_AKE_INIT 2 >+#define HDCP_2_2_AKE_SEND_CERT3 >+#define HDCP_2_2_AKE_NO_STORED_KM 4 >+#define HDCP_2_2_AKE_STORED_KM5 >+#define HDCP_2_2_AKE_SEND_HPRIME 7 >+#define HDCP_2_2_AKE_SEND_PARING_INFO 8 Typo in Pairing >+#define HDCP_2_2_LC_INIT 9 >+#define HDCP_2_2_LC_SEND_LPRIME 10 >+#define HDCP_2_2_SKE_SEND_EKS 11 >+#define HDCP_2_2_REP_SEND_RECVID_LIST 12 >+#define HDCP_2_2_REP_SEND_ACK 15 >+#define HDCP_2_2_REP_STREAM_MANAGE16 >+#define HDCP_2_2_REP_STREAM_READY 17 >+#define HDCP_2_2_ERRATA_DP_STREAM_TYPE50 >+ >+#define HDCP_2_2_RTX_LEN 8 >+#define HDCP_2_2_RRX_LEN 8 >+ >+#define HDCP_2_2_K_PUB_RX_MOD_N_LEN 128 >+#define HDCP_2_2_K_PUB_RX_EXP_E_LEN 3 >+#define HDCP_2_2_K_PUB_RX_LEN > (HDCP_2_2_K_PUB_RX_MOD_N_LEN + \ >+ >HDCP_2_2_K_PUB_RX_EXP_E_LEN) >+ >+#define HDCP_2_2_DCP_LLC_SIG_LEN 384 >+ >+#define HDCP_2_2_E_KPUB_KM_LEN128 >+#define HDCP_2_2_E_KH_KM_M_LEN(16 + 16) >+#define HDCP_2_2_H_PRIME_LEN 32 >+#define HDCP_2_2_E_KH_KM_LEN 16 >+#define HDCP_2_2_RN_LEN 8 >+#define HDCP_2_2_L_PRIME_LEN 32 >+#define HDCP_2_2_E_DKEY_KS_LEN16 >+#define HDCP_2_2_RIV_LEN 8 >+#define HDCP_2_2_SEQ_NUM_LEN 3 >+#define HDCP_2_2_LPRIME_HALF_LEN (HDCP_2_2_L_PRIME_LEN / 2) >+#define HDCP_2_2_RECEIVER_ID_LEN DRM_HDCP_KSV_LEN >+#define HDCP_2_2_MAX_DEVICE_COUNT 31 >+#define HDCP_2_2_RECEIVER_IDS_MAX_LEN > (HDCP_2_2_RECEIVER_ID_LEN * \ >+ >HDCP_2_2_MAX_DEVICE_COUNT) >+#define HDCP_2_2_MPRIME_LEN 32 >+ >+/** Remove an extra "*". >+ * TODO: This has to be changed for DP MST, as multiple stream on >+ * same port is possible. >+ * For HDCP2.2 on HDMI and DP SST this value is always 1. >+ */ >+#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT 1 >+#define HDCP_2_2_TXCAP_MASK_LEN 2 >+#define HDCP_2_2_RXCAPS_LEN 3 >+#define HDCP_2_2_RX_REPEATER(x) (x & BIT(0)) >+#define HDCP_2_2_DP_HDCP_CAPABLE(x) (x & BIT(1)) >+#define HDCP_2_2_RXINFO_LEN 2 >+ >+/* HDCP1.x compliant device in downstream */ >+#define HDCP_2_2_HDCP1_DEVICE_CONNECTED(x)(x & BIT(0)) >+ >+/* HDCP2.0 Compliant repeater in downstream */ >+#define HDCP_2_2_HDCP_2_0_REP_CONNECTED(x)(x & BIT(1)) >+#define HDCP_2_2_MAX_CASCADE_EXCEEDED(x) (x & BIT(2)) >+#define HDCP_2_2_MAX_DEVS_EXCEEDED(x) (x & BIT(3)) >+#define HDCP_2_2_DEV_COUNT_LO(x) ((x & (0xF << 4)) >> 4) >+#define HDCP_2_2_DEV_COUNT_HI(x) (x & BIT(0)) As per 2.2 spec this is a 5 bit field and no mention of HI and LO is there for dev count. A comment explaining why this masking style is chosen will be helpful since it doesn't match exactly with spec. >+#define HDCP_2_2_DEPTH(x) ((x & (0x7 << 1)) >> 1) Same here, may be add a generic comment explaining the logi
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: fix spelling mistake: "seqeuncer" -> "sequencer"
== Series Details == Series: drm/i915/dp: fix spelling mistake: "seqeuncer" -> "sequencer" URL : https://patchwork.freedesktop.org/series/42935/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4162 -> Patchwork_8959 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8959 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8959, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42935/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8959: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8959 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-skl-6700k2: PASS -> INCOMPLETE (k.org#199541, fdo#105524, fdo#104108) fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#105524 https://bugs.freedesktop.org/show_bug.cgi?id=105524 k.org#199541 https://bugzilla.kernel.org/show_bug.cgi?id=199541 == Participating hosts (41 -> 36) == Missing(5): fi-ctg-p8600 fi-byt-squawks fi-ilk-m540 fi-cnl-y3 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4162 -> Patchwork_8959 CI_DRM_4162: ea17aab5ec734a262a252758d7412c09dfa833cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8959: 9cecedefb9e2280719feafeb9f9e4c4b3f8302d1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Linux commits == 9cecedefb9e2 drm/i915/dp: fix spelling mistake: "seqeuncer" -> "sequencer" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8959/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 02/40] drm: HDMI and DP specific HDCP2.2 defines
>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Ramalingam C >Sent: Tuesday, April 3, 2018 7:27 PM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk; >jani.nik...@linux.intel.com; Winkler, Tomas ; >Usyskin, Alexander >Cc: Vivi, Rodrigo >Subject: [PATCH v3 02/40] drm: HDMI and DP specific HDCP2.2 defines > >In preparation for implementing HDCP2.2 in I915, this patch adds HDCP register >definitions for HDMI and DP HDCP adaptations. I believe we can just keep this message generic at drm layer, instead of calling out i915 specifically. Currently it may be enabled for i915, but it will used for other drivers as well in future. > >HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h, where are Make it "where as". >HDCP2.2 register offsets in DPCD offsets are defined at drm_dp_helper.h. > >v2: > bit_field definitions are replaced by macros. [Tomas and Jany] Typo in "Jani's" name. >v3: > No Changes. > >Signed-off-by: Ramalingam C >--- > include/drm/drm_dp_helper.h | 54 >+ > include/drm/drm_hdcp.h | 29 > 2 files changed, 83 insertions(+) > >diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index >4de97e94ef9d..2185b3a88911 100644 >--- a/include/drm/drm_dp_helper.h >+++ b/include/drm/drm_dp_helper.h >@@ -887,6 +887,60 @@ > #define DP_AUX_HDCP_KSV_FIFO 0x6802C > #define DP_AUX_HDCP_AINFO 0x6803B > >+/** >+ * DP HDCP2.2 parameter offsets in DPCD address space */ Rectify the comment style >+#define DP_HDCP_2_2_REG_RTX_OFFSET0x69000 >+#define DP_HDCP_2_2_REG_TXCAPS_OFFSET 0x69008 >+#define DP_HDCP_2_2_REG_CERT_RX_OFFSET0x6900B >+#define DP_HDCP_2_2_REG_RRX_OFFSET0x69215 >+#define DP_HDCP_2_2_REG_RX_CAPS_OFFSET0x6921D >+#define DP_HDCP_2_2_REG_EKPUB_KM_OFFSET 0x69220 >+#define DP_HDCP_2_2_REG_EKH_KM_OFFSET 0x692A0 >+#define DP_HDCP_2_2_REG_M_OFFSET 0x692B0 >+#define DP_HDCP_2_2_REG_HPRIME_OFFSET 0x692C0 >+#define DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET 0x692E0 >+#define DP_HDCP_2_2_REG_RN_OFFSET 0x692F0 >+#define DP_HDCP_2_2_REG_LPRIME_OFFSET 0x692F8 >+#define DP_HDCP_2_2_REG_EDKEY_KS_OFFSET 0x69318 >+#define DP_HDCP_2_2_REG_RIV_OFFSET 0x69328 >+#define DP_HDCP_2_2_REG_RXINFO_OFFSET 0x69330 >+#define DP_HDCP_2_2_REG_SEQ_NUM_V_OFFSET 0x69332 >+#define DP_HDCP_2_2_REG_VPRIME_OFFSET 0x69335 >+#define DP_HDCP_2_2_REG_RECV_ID_LIST_OFFSET 0x69345 >+#define DP_HDCP_2_2_REG_V_OFFSET 0x693E0 >+#define DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET 0x693F0 >+#define DP_HDCP_2_2_REG_K_OFFSET 0x693F3 >+#define DP_HDCP_2_2_REG_STREAM_ID_TYPE_OFFSET 0x693F5 >+#define DP_HDCP_2_2_REG_MPRIME_OFFSET 0x69473 >+#define DP_HDCP_2_2_REG_RXSTATUS_OFFSET 0x69493 >+#define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET0x69494 This is not matching to the spec. Seems reserved in spec. >+#define DP_HDCP_2_2_REG_DBG_OFFSET0x69518 >+ >+/** >+ * DP HDCP message start offsets in DPCD address space */ Rectify comment style >+#define DP_HDCP_2_2_AKE_INIT_OFFSET > DP_HDCP_2_2_REG_RTX_OFFSET >+#define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET > DP_HDCP_2_2_REG_CERT_RX_OFFSET >+#define DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET > DP_HDCP_2_2_REG_EKPUB_KM_OFFSET >+#define DP_HDCP_2_2_AKE_STORED_KM_OFFSET > DP_HDCP_2_2_REG_EKH_KM_OFFSET >+#define DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET > DP_HDCP_2_2_REG_HPRIME_OFFSET >+#define DP_HDCP_2_2_AKE_SEND_PARING_INFO_OFFSET Typo in pairing > DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET >+#define DP_HDCP_2_2_LC_INIT_OFFSET > DP_HDCP_2_2_REG_RN_OFFSET >+#define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET > DP_HDCP_2_2_REG_LPRIME_OFFSET >+#define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET > DP_HDCP_2_2_REG_EDKEY_KS_OFFSET >+#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET > DP_HDCP_2_2_REG_RXINFO_OFFSET >+#define DP_HDCP_2_2_REP_SEND_ACK_OFFSET > DP_HDCP_2_2_REG_V_OFFSET >+#define DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET > DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET >+#define DP_HDCP_2_2_REP_STREAM_READY_OFFSET > DP_HDCP_2_2_REG_MPRIME_OFFSET >+ >+#define HDCP_2_2_DP_RXSTATUS_LEN 1 >+#define HDCP_2_2_DP_RXSTATUS_READY(x) (x & BIT(0)) >+#define HDCP_2_2_DP_RXSTATUS_H_PRIME(x) (x & BIT(1)) >+#define HDCP_2_2_DP_RXSTATUS_PAIRING(x) (x & BIT(2)) >+#define HDCP_2_2_DP_RXSTATUS_REAUTH_REQ(x)(x & BIT(3)) >+#define HDCP_2_2_DP_RXSTATUS_LINK_FAILED(x) (x & BIT(4)) >+ > /* DP 1.2 Sideband message defines */ > /* peer device type - DP 1.2a Table 2-92 */ Make it multi line comment. > #define DP_PEER_DEVICE_NONE 0x0 >diff --git a/include/dr
Re: [Intel-gfx] [PATCH v3 04/40] misc/mei/hdcp: Client driver for HDCP application
>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Ramalingam C >Sent: Tuesday, April 3, 2018 7:27 PM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk; >jani.nik...@linux.intel.com; Winkler, Tomas ; >Usyskin, Alexander >Cc: Vivi, Rodrigo >Subject: [PATCH v3 04/40] misc/mei/hdcp: Client driver for HDCP application > >ME FW is contributes a vital role in HDCP2.2 authentication. Remove "is". >HDCP2.2 driver needs to communicate to ME FW for each step of the >HDCP2.2 authentication. > >ME FW prepare and HDCP2.2 authentication parameters and encrypt them as per Drop "and HDCP2.2" here. >spec. With such parameter Driver prepares HDCP2.2 auth messages and >communicate with HDCP2.2 sink. > >Similarly HDCP2. sink's response is shared with ME FW for decrypt and Drop "HDCP2.". Its implicit, no need to call multiple times. >verification. > >Once All the steps of HDCP2.2 authentications are complete on driver's request Change "All to all". Drop "s" from authentication. Add a "," after complete. >ME FW will configure the port as authenticated and supply the HDCP keys to the >Gen HW for encryption. > >Only after this stage HDCP2.2 driver can start the HDCP2.2 encryption for a >port. > >ME FW is interfaced to kernel through MEI Bus Driver. To obtain the >HDCP2.2 services from the ME FW through MEI Bus driver MEI Client Driver is >developed. > >v2: > hdcp files are moved to drivers/misc/mei/hdcp/ [Tomas] >v3: > Squashed the Kbuild support [Tomas] > UUID renamed and Module License is modified [Tomas] > drv_data is set to null at remove [Tomas] > >Signed-off-by: Ramalingam C >Signed-off-by: Tomas Winkler >--- > drivers/misc/mei/Kconfig | 6 > drivers/misc/mei/Makefile| 2 ++ > drivers/misc/mei/hdcp/Makefile | 6 > drivers/misc/mei/hdcp/mei_hdcp.c | 74 > > 4 files changed, 88 insertions(+) > create mode 100644 drivers/misc/mei/hdcp/Makefile create mode 100644 >drivers/misc/mei/hdcp/mei_hdcp.c > >diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig index >c49e1d2269af..90977132d1e2 100644 >--- a/drivers/misc/mei/Kconfig >+++ b/drivers/misc/mei/Kconfig >@@ -43,3 +43,9 @@ config INTEL_MEI_TXE > > Supported SoCs: > Intel Bay Trail >+ >+config INTEL_MEI_HDCP >+ tristate "Intel HDCP2.2 services of ME Interface" >+ depends on INTEL_MEI && DRM_I915 >+ help >+MEI Support for HDCP2.2 Services on Intel SoCs. >diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile index >cd6825afa8e1..e64d1212fb85 100644 >--- a/drivers/misc/mei/Makefile >+++ b/drivers/misc/mei/Makefile >@@ -23,3 +23,5 @@ mei-txe-objs += hw-txe.o > > mei-$(CONFIG_EVENT_TRACING) += mei-trace.o CFLAGS_mei-trace.o = -I$(src) >+ >+obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/ >diff --git a/drivers/misc/mei/hdcp/Makefile b/drivers/misc/mei/hdcp/Makefile >new file mode 100644 index ..75ac50203223 >--- /dev/null >+++ b/drivers/misc/mei/hdcp/Makefile >@@ -0,0 +1,6 @@ >+# SPDX-License-Identifier: GPL-2.0 >+# >+# Makefile - HDCP client driver for Intel MEI Bus Driver. >+# Copyright (c) 2010-2014, Intel Corporation. >+# >+obj-$(CONFIG_INTEL_MEI_HDCP) += mei_hdcp.o >diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c >b/drivers/misc/mei/hdcp/mei_hdcp.c >new file mode 100644 >index ..b334615728a7 >--- /dev/null >+++ b/drivers/misc/mei/hdcp/mei_hdcp.c >@@ -0,0 +1,74 @@ >+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */ >+/* >+ * Copyright © 2017-2018 Intel Corporation >+ * >+ * Mei_hdcp.c: HDCP client driver for mei bus >+ * >+ * Permission is hereby granted, free of charge, to any person >+obtaining a >+ * copy of this software and associated documentation files (the >+"Software"), >+ * to deal in the Software without restriction, including without >+limitation >+ * the rights to use, copy, modify, merge, publish, distribute, >+sublicense, >+ * and/or sell copies of the Software, and to permit persons to whom >+the >+ * Software is furnished to do so, subject to the following conditions: >+ * >+ * The above copyright notice and this permission notice (including the >+next >+ * paragraph) shall be included in all copies or substantial portions >+of the >+ * Software. >+ * >+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, >+EXPRESS OR >+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF >+MERCHANTABILITY, >+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO >EVENT >+SHALL >+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, >DAMAGES OR >+OTHER >+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, >+ARISING >+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR >OTHER >+ * DEALINGS IN THE SOFTWARE. >+ * >+ * Authors: >+ *Ramalingam C >+ */ >+ >+#include >+#include >+#include >+#include >+ >+s
Re: [Intel-gfx] [PATCH v3 07/40] linux/mei: Header for mei_hdcp driver interface
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:27 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [PATCH v3 07/40] linux/mei: Header for mei_hdcp driver interface
>
>Data structures and Enum for the I915-MEI_HDCP interface are defined at
>
>
>v2:
> Rebased.
>v3:
> mei_cl_device is removed from mei_hdcp_data [Tomas]
>
>Signed-off-by: Ramalingam C
>---
> include/linux/mei_hdcp.h | 70
>
> 1 file changed, 70 insertions(+)
>
>diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
>3b46bebde718..634c1a5bdf1e 100644
>--- a/include/linux/mei_hdcp.h
>+++ b/include/linux/mei_hdcp.h
>@@ -27,11 +27,81 @@
> #ifndef _LINUX_MEI_HDCP_H
> #define _LINUX_MEI_HDCP_H
>
>+#include
>+
> enum mei_cldev_state {
> MEI_CLDEV_DISABLED,
> MEI_CLDEV_ENABLED
> };
>
>+/*
>+ * Enumeration of the physical DDI available on the platform */ enum
>+hdcp_physical_port {
>+ INVALID_PORT = 0x00,/* Not a valid port */
>+
>+ DDI_RANGE_BEGIN = 0x01, /* Beginning of the valid DDI port range
>*/
>+ DDI_B = 0x01, /* Port DDI B */
>+ DDI_C = 0x02, /* Port DDI C */
>+ DDI_D = 0x03, /* Port DDI D */
>+ DDI_E = 0x04, /* Port DDI E */
>+ DDI_F = 0x05, /* Port DDI F */
>+ DDI_A = 0x07, /* Port DDI A */
Why A is made as 0x7. In I915, enum port defines A as 0. Any special reason to
deviate from that ?
>+ DDI_RANGE_END = DDI_A,/* End of the valid DDI port range */
>+};
>+
>+/* The types of HDCP 2.2 ports supported */ enum
>+hdcp_integrated_port_type {
>+ HDCP_INVALID_TYPE = 0x00,
>+
>+ /* HDCP 2.x ports that are integrated into Intel HW */
>+ INTEGRATED = 0x01,
>+
>+ /* HDCP2.2 discrete wired Tx port with LSPCON (HDMI 2.0) solution */
>+ LSPCON = 0x02,
>+
>+ /* HDCP2.2 discrete wired Tx port using the CPDP (DP 1.3) solution */
>+ CPDP= 0x03,
>+};
>+
>+/**
Drop an extra *
>+ * wired_protocol: Supported integrated wired HDCP protocol.
>+ * Based on this value, Minor differenceneeded between wired
"Add space after differences"
>+specifications
>+ * are handled.
>+ */
>+enum hdcp_protocol {
>+ HDCP_PROTOCOL_INVALID,
>+ HDCP_PROTOCOL_HDMI,
>+ HDCP_PROTOCOL_DP
>+};
>+
>+/**
>+ * mei_hdcp_data: Input data to the mei_hdcp APIs.
>+ */
>+struct mei_hdcp_data {
>+ enum hdcp_physical_port port;
>+ enum hdcp_integrated_port_type port_type;
>+ enum hdcp_protocol protocol;
>+
>+ /*
>+ * No of streams transmitted on a port.
>+ * In case of HDMI & DP SST, single stream will be
>+ * transmitted on a port.
>+ */
>+ uint16_t k;
>+
>+ /*
>+ * Count of RepeaterAuth_Stream_Manage msg propagated.
>+ * Initialized to 0 on AKE_INIT. Incremented after every successful
>+ * transmission of RepeaterAuth_Stream_Manage message. When it rolls
>+ * over re-Auth has to be triggered.
>+ */
>+ uint32_t seq_num_m;
>+
>+ /* k(No of Streams per port) x structure of wired_streamid_type */
>+ struct hdcp2_streamid_type *streams;
>+};
>+
> #ifdef CONFIG_INTEL_MEI_HDCP
> int mei_cldev_register_notify(struct notifier_block *nb); int
>mei_cldev_unregister_notify(struct notifier_block *nb);
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
== Series Details == Series: drm/i915/dp: optimize eDP 1.4+ link config fast and narrow URL : https://patchwork.freedesktop.org/series/42923/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4161_full -> Patchwork_8957_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8957_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8957_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42923/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8957_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: SKIP -> PASS +1 == Known issues == Here are the changes found in Patchwork_8957_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@2x-flip-vs-absolute-wf_vblank: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#102887) igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) +2 Possible fixes igt@kms_flip@dpms-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@flip-vs-wf_vblank-interruptible: shard-glk: FAIL (fdo#100368) -> PASS +1 igt@kms_flip@modeset-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_vblank@pipe-b-accuracy-idle: shard-hsw: FAIL (fdo#102583) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4161 -> Patchwork_8957 CI_DRM_4161: f20dbaa0dfba8b33c677c084d39fc730309c5af2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8957: 14195da35f10255240ce36a4f0c2628ba2340110 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8957/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:27 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 08/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx
>Session
>
>Request ME FW to start the HDCP2.2 session for a intel port.
Change "a" to "an".
>Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sent to
"sent" to "sends"
>ME FW.
>
>On Success, ME FW will start a HDCP2.2 session for the port and provides the
>content for HDCP2.2 AKE_Init message.
>
>v2:
> Rebased.
>v3:
> cldev is add as a separate parameter [Tomas]
> Redundant comment and typecast are removed [Tomas]
>
>Signed-off-by: Ramalingam C
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 68
>
> include/linux/mei_hdcp.h | 11 +++
> 2 files changed, 79 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 2811a25f8c57..7caee0947761 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -33,9 +33,77 @@
> #include
> #include
> #include
>+#include
>+
>+#include "mei_hdcp.h"
>
> static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);
>
>+/**
>+ * mei_initiate_hdcp2_session:
>+ *Function to start a Wired HDCP2.2 Tx Session with ME FW
>+ *
>+ * @cldev : Pointer for mei client device
>+ * @data : Intel HW specific Data
>+ * @ake_data : ptr to store AKE_Init
>+ *
>+ * Returns 0 on Success, <0 on Failure.
>+ */
>+int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data,
>+ struct hdcp2_ake_init *ake_data) {
>+ struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
>+ struct wired_cmd_initiate_hdcp2_session_out
>+ session_init_out = { { 0 } };
>+ struct device *dev;
>+ ssize_t byte;
>+
>+ if (!data || !ake_data)
>+ return -EINVAL;
>+
>+ dev = &cldev->dev;
>+
>+ session_init_in.header.api_version = HDCP_API_VERSION;
>+ session_init_in.header.command_id =
>WIRED_INITIATE_HDCP2_SESSION;
>+ session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+ session_init_in.header.buffer_len =
>+
> WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
>+
>+ session_init_in.port.integrated_port_type = data->port_type;
>+ session_init_in.port.physical_port = data->port;
>+ session_init_in.protocol = (uint8_t)data->protocol;
>+
>+ byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
>+sizeof(session_init_in));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ byte = mei_cldev_recv(cldev, (u8 *)&session_init_out,
>+sizeof(session_init_out));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+ dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
>+ WIRED_INITIATE_HDCP2_SESSION,
>+ session_init_out.header.status);
>+ return -1;
>+ }
>+
>+ ake_data->msg_id = HDCP_2_2_AKE_INIT;
>+ ake_data->tx_caps = session_init_out.tx_caps;
>+ memcpy(ake_data->r_tx, session_init_out.r_tx,
We should check for ake_data->r_tx for NULL as well before attempting this copy.
>+ sizeof(session_init_out.r_tx));
>+
>+ return 0;
>+}
>+EXPORT_SYMBOL(mei_initiate_hdcp2_session);
>+
> void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled) {
> if (enabled)
>diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
>634c1a5bdf1e..bb4f27d3abcb 100644
>--- a/include/linux/mei_hdcp.h
>+++ b/include/linux/mei_hdcp.h
>@@ -28,6 +28,7 @@
> #define _LINUX_MEI_HDCP_H
>
> #include
>+#include
>
> enum mei_cldev_state {
> MEI_CLDEV_DISABLED,
>@@ -105,6 +106,9 @@ struct mei_hdcp_data { #ifdef
>CONFIG_INTEL_MEI_HDCP int mei_cldev_register_notify(struct notifier_block
>*nb); int mei_cldev_unregister_notify(struct notifier_block *nb);
>+int mei_initiate_hdcp2_session(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data,
>+ struct hdcp2_ake_init *ake_data);
> #else
> static int mei_cldev_register_notify(struct notifier_block *nb) { @@ -114,5
>+118,12 @@ static int mei_cldev_unregister_notify(struct notifier_block *nb) {
> return -ENODEV;
> }
>+static inline
>+int mei
[Intel-gfx] [PATCH][V2] drm/i915/dp: fix spelling mistakes: "seqeuncer" and "seqeuencer"
From: Colin Ian King
Trivial fix to spelling mistakes in WARN warning message text and
in comments:
"seqeuncer", "seqeuencer" -> "sequencer"
Signed-off-by: Colin Ian King
---
V2: Also fix seqeuencer in comments
---
drivers/gpu/drm/i915/intel_dp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dde92e4af5d3..2cc58596ff5a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -513,7 +513,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
uint32_t DP;
if (WARN(I915_READ(intel_dp->output_reg) & DP_PORT_EN,
-"skipping pipe %c power seqeuncer kick due to port %c being
active\n",
+"skipping pipe %c power sequencer kick due to port %c being
active\n",
pipe_name(pipe), port_name(intel_dig_port->base.port)))
return;
@@ -554,7 +554,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
/*
* Similar magic as in intel_dp_enable_port().
* We _must_ do this port enable + disable trick
-* to make this power seqeuencer lock onto the port.
+* to make this power sequencer lock onto the port.
* Otherwise even VDD force bit won't work.
*/
I915_WRITE(intel_dp->output_reg, DP);
@@ -3066,11 +3066,11 @@ static void vlv_detach_power_sequencer(struct intel_dp
*intel_dp)
edp_panel_vdd_off_sync(intel_dp);
/*
-* VLV seems to get confused when multiple power seqeuencers
+* VLV seems to get confused when multiple power sequencers
* have the same port selected (even if only one has power/vdd
* enabled). The failure manifests as vlv_wait_port_ready() failing
* CHV on the other hand doesn't seem to mind having the same port
-* selected in multiple power seqeuencers, but let's clear the
+* selected in multiple power sequencers, but let's clear the
* port select always when logically disconnecting a power sequencer
* from a port.
*/
@@ -5698,7 +5698,7 @@ intel_dp_init_panel_power_sequencer_registers(struct
intel_dp *intel_dp,
/*
* On some VLV machines the BIOS can leave the VDD
-* enabled even on power seqeuencers which aren't
+* enabled even on power sequencers which aren't
* hooked up to any port. This would mess up the
* power domain tracking the first time we pick
* one of these power sequencers for use since
@@ -5706,7 +5706,7 @@ intel_dp_init_panel_power_sequencer_registers(struct
intel_dp *intel_dp,
* already on and therefore wouldn't grab the power
* domain reference. Disable VDD first to avoid this.
* This also avoids spuriously turning the VDD on as
-* soon as the new power seqeuencer gets initialized.
+* soon as the new power sequencer gets initialized.
*/
if (force_disable_vdd) {
u32 pp = ironlake_get_pp_control(intel_dp);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 10/40] misc/mei/hdcp: Verify H_prime
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:27 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 10/40] misc/mei/hdcp: Verify H_prime
>
>Requests for the verifcation of AKE_Send_H_prime.
Typo in verification.
>
>ME will calculation the H and comparing it with received H_Prime.
Change to "calculate". Also change "comparing" to "compares".
>Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.
>
>v2:
> Rebased.
>v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
>
>Signed-off-by: Ramalingam C
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 58
>
> include/linux/mei_hdcp.h | 8 ++
> 2 files changed, 66 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 181994529058..fa548310de7a 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -186,6 +186,64 @@ mei_verify_receiver_cert_prepare_km(struct
>mei_cl_device *cldev, }
>EXPORT_SYMBOL(mei_verify_receiver_cert_prepare_km);
>
>+/**
>+ * mei_verify_hprime:
>+ *Function to verify AKE_Send_H_prime received
>+ *
>+ * @cldev : Pointer for mei client device
>+ * @data : Intel HW specific Data
>+ * @rx_hprime : Pointer for AKE_Send_H_prime
>+ * @hprime_sz : Input buffer size
>+ *
>+ * Returns 0 on Success, <0 on Failure
>+ */
>+int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
>+struct hdcp2_ake_send_hprime *rx_hprime) {
>+ struct wired_cmd_ake_send_hprime_in send_hprime_in = { { 0 } };
>+ struct wired_cmd_ake_send_hprime_out send_hprime_out = { { 0 } };
>+ struct device *dev;
>+ ssize_t byte;
>+
>+ if (!data || !rx_hprime)
>+ return -EINVAL;
>+
>+ dev = &cldev->dev;
>+
>+ send_hprime_in.header.api_version = HDCP_API_VERSION;
>+ send_hprime_in.header.command_id = WIRED_AKE_SEND_HPRIME;
>+ send_hprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+ send_hprime_in.header.buffer_len =
>+WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
>+
>+ send_hprime_in.port.integrated_port_type = data->port_type;
>+ send_hprime_in.port.physical_port = data->port;
>+
>+ memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
Need to validate rx_hprime->h_prime for NULL.
>+ sizeof(rx_hprime->h_prime));
>+
>+ byte = mei_cldev_send(cldev, (u8 *)&send_hprime_in,
>+sizeof(send_hprime_in));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ byte = mei_cldev_recv(cldev, (u8 *)&send_hprime_out,
>+sizeof(send_hprime_out));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ if (send_hprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+ dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
>+ WIRED_AKE_SEND_HPRIME,
>send_hprime_out.header.status);
>+ return -1;
>+ }
Leave a blank line here.
>+ return 0;
One clarification required - the h prime value sent and received are not
compared here. So, whether
hw matches them and returns success only if they match or it just returns the H
prime value
and driver should compare ?
>+}
>+EXPORT_SYMBOL(mei_verify_hprime);
>+
> void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled) {
> if (enabled)
>diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
>314b15f6afc0..00bfde251ba4 100644
>--- a/include/linux/mei_hdcp.h
>+++ b/include/linux/mei_hdcp.h
>@@ -116,6 +116,8 @@ mei_verify_receiver_cert_prepare_km(struct
>mei_cl_device *cldev,
> bool *km_stored,
> struct hdcp2_ake_no_stored_km
>*ek_pub_km,
> size_t *msg_sz);
>+int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
>+struct hdcp2_ake_send_hprime *rx_hprime);
> #else
> static int mei_cldev_register_notify(struct notifier_block *nb) { @@ -142,5
>+144,11 @@ mei_verify_receiver_cert_prepare_km(struct mei_cl_device *cldev,
>{
> return -ENODEV;
> }
>+static inline
>+int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
>+struct hdcp2_ake_send_hprime *rx_hprime) {
>+ return -ENODEV;
>+}
> #endif /* defined (CONFIG_INTEL_MEI_HDCP) */ #endif /* defined
>(_LINUX_MEI_HDCP_H) */
>--
>2.7
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Only switch to kernel context when locked
== Series Details == Series: drm/i915/selftests: Only switch to kernel context when locked URL : https://patchwork.freedesktop.org/series/42922/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4161_full -> Patchwork_8958_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8958_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8958_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42922/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8958_full: === IGT changes === Warnings igt@drv_selftest@live_execlists: shard-glk: SKIP -> PASS +1 shard-apl: SKIP -> PASS +1 igt@gem_exec_schedule@deep-blt: shard-kbl: SKIP -> PASS +4 igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8958_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible: shard-apl: PASS -> FAIL (fdo#100368) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@plain-flip-ts-check-interruptible: shard-glk: PASS -> FAIL (fdo#100368) +1 igt@kms_sysfs_edid_timing: shard-apl: PASS -> WARN (fdo#100047) Possible fixes igt@drv_selftest@live_hangcheck: shard-kbl: DMESG-FAIL (fdo#106453) -> PASS shard-apl: DMESG-FAIL (fdo#106453) -> PASS shard-glk: DMESG-FAIL (fdo#106453) -> PASS igt@kms_flip@dpms-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@flip-vs-wf_vblank-interruptible: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@modeset-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS igt@kms_vblank@pipe-b-accuracy-idle: shard-hsw: FAIL (fdo#102583) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106453 https://bugs.freedesktop.org/show_bug.cgi?id=106453 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4161 -> Patchwork_8958 CI_DRM_4161: f20dbaa0dfba8b33c677c084d39fc730309c5af2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8958: 19d6def0ed772cfbbfe18c9acf717b08eae827ac @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8958/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP Pairing info
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:27 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP Pairing
>info
>
>Provides Pairing info to ME to store.
>
>Pairing is a process to fast track the subsequent authentication with the same
>HDCP sink.
>
>On Success, received HDCP pairing info is stored in non-volatile memory of ME.
>
>v2:
> Rebased.
>v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
>
>Signed-off-by: Ramalingam C
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 61
>
> include/linux/mei_hdcp.h | 10 +++
> 2 files changed, 71 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index fa548310de7a..60afdd0cee79 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -244,6 +244,67 @@ int mei_verify_hprime(struct mei_cl_device *cldev,
>struct mei_hdcp_data *data, } EXPORT_SYMBOL(mei_verify_hprime);
>
>+/**
Drop the extra *, unless you really love it :)
>+ * mei_store_pairing_info:
>+ *Function to store pairing info received from panel
>+ *
>+ * @cldev : Pointer for mei client device
>+ * @data : Intel HW specific Data
>+ * @pairing_info : Pointer for AKE_Send_Pairing_Info
>+ *
>+ * Returns 0 on Success, <0 on Failure
>+ */
>+
>+int mei_store_pairing_info(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data,
>+ struct hdcp2_ake_send_pairing_info *pairing_info) {
>+ struct wired_cmd_ake_send_pairing_info_in pairing_info_in = { { 0 } };
>+ struct wired_cmd_ake_send_pairing_info_out pairing_info_out = { { 0 } };
>+ struct device *dev;
>+ ssize_t byte;
>+
>+ if (!data || !pairing_info)
>+ return -EINVAL;
>+
>+ dev = &cldev->dev;
>+
>+ pairing_info_in.header.api_version = HDCP_API_VERSION;
>+ pairing_info_in.header.command_id =
>WIRED_AKE_SEND_PAIRING_INFO;
>+ pairing_info_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+ pairing_info_in.header.buffer_len =
>+
> WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
>+
>+ pairing_info_in.port.integrated_port_type = data->port_type;
>+ pairing_info_in.port.physical_port = data->port;
>+
>+ memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
Validate pairing_info->e_kh_km for NULL.
>+ sizeof(pairing_info_in.e_kh_km));
>+
>+ byte = mei_cldev_send(cldev, (u8 *)&pairing_info_in,
>+sizeof(pairing_info_in));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ byte = mei_cldev_recv(cldev, (u8 *)&pairing_info_out,
>+sizeof(pairing_info_out));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ if (pairing_info_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+ dev_dbg(dev, "ME cmd 0x%08X failed. Status: 0x%X\n",
>+ WIRED_AKE_SEND_PAIRING_INFO,
>+ pairing_info_out.header.status);
>+ return -1;
>+ }
Leave a blank line here.
>+ return 0;
>+}
>+EXPORT_SYMBOL(mei_store_pairing_info);
>+
> void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled) {
> if (enabled)
>diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
>00bfde251ba4..be16e49d8018 100644
>--- a/include/linux/mei_hdcp.h
>+++ b/include/linux/mei_hdcp.h
>@@ -118,6 +118,9 @@ mei_verify_receiver_cert_prepare_km(struct
>mei_cl_device *cldev,
> size_t *msg_sz);
> int mei_verify_hprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
> struct hdcp2_ake_send_hprime *rx_hprime);
>+int mei_store_pairing_info(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data,
>+ struct hdcp2_ake_send_pairing_info *pairing_info);
> #else
> static int mei_cldev_register_notify(struct notifier_block *nb) { @@ -150,5
>+153,12 @@ int mei_verify_hprime(struct mei_cl_device *cldev, struct
>mei_hdcp_data *data, {
> return -ENODEV;
> }
>+static inline
>+int mei_store_pairing_info(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data,
>+ struct hdcp2_ake_send_pairing_info *pairing_info) {
>+ return -ENODEV;
>+}
> #endif /* defined (CONFIG_INTEL_MEI_HDCP) */ #endif /* defined
>(_LINUX_MEI_HDCP_H
Re: [Intel-gfx] [PATCH v3 12/40] misc/mei/hdcp: Initiate Locality check
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:27 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [PATCH v3 12/40] misc/mei/hdcp: Initiate Locality check
>
>Requests ME to start the second stage of HDCP2.2 authentication, called
>Locality
>Check.
>
>On Success, ME FW will provide LC_Init message to send to hdcp sink.
>
>v2:
> Rebased.
>v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
>
>Signed-off-by: Ramalingam C
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 56
>
> include/linux/mei_hdcp.h | 10 +++
> 2 files changed, 66 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 60afdd0cee79..9bd7e66a91e4 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -305,6 +305,62 @@ int mei_store_pairing_info(struct mei_cl_device *cldev,
>} EXPORT_SYMBOL(mei_store_pairing_info);
>
>+/**
>+ * mei_initiate_locality_check:
>+ *Function to prepare LC_Init.
>+ *
>+ * @cldev : Pointer for mei client device
>+ * @data : Intel HW specific Data
>+ * @hdcp2_lc_init : Pointer for storing LC_Init
>+ *
>+ * Returns 0 on Success, <0 on Failure
>+ */
>+int mei_initiate_locality_check(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data,
>+ struct hdcp2_lc_init *lc_init_data) {
>+ struct wired_cmd_init_locality_check_in lc_init_in = { { 0 } };
>+ struct wired_cmd_init_locality_check_out lc_init_out = { { 0 } };
>+ struct device *dev;
>+ ssize_t byte;
>+
>+ if (!data || !lc_init_data)
>+ return -EINVAL;
>+
>+ dev = &cldev->dev;
>+
>+ lc_init_in.header.api_version = HDCP_API_VERSION;
>+ lc_init_in.header.command_id = WIRED_INIT_LOCALITY_CHECK;
>+ lc_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+ lc_init_in.header.buffer_len =
>+WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
>+
>+ lc_init_in.port.integrated_port_type = data->port_type;
>+ lc_init_in.port.physical_port = data->port;
>+
>+ byte = mei_cldev_send(cldev, (u8 *)&lc_init_in, sizeof(lc_init_in));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ byte = mei_cldev_recv(cldev, (u8 *)&lc_init_out, sizeof(lc_init_out));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ if (lc_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+ dev_dbg(dev, "ME cmd 0x%08X Failed. status: 0x%X\n",
>+ WIRED_INIT_LOCALITY_CHECK,
>lc_init_out.header.status);
>+ return -1;
>+ }
>+
>+ lc_init_data->msg_id = HDCP_2_2_LC_INIT;
>+ memcpy(lc_init_data->r_n, lc_init_out.r_n, HDCP_2_2_RN_LEN);
Check for validity of lc_init_data->r_n.
Also, leave a blank line.
>+ return 0;
>+}
>+EXPORT_SYMBOL(mei_initiate_locality_check);
>+
> void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled) {
> if (enabled)
>diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
>be16e49d8018..d9c4cac0b276 100644
>--- a/include/linux/mei_hdcp.h
>+++ b/include/linux/mei_hdcp.h
>@@ -121,6 +121,9 @@ int mei_verify_hprime(struct mei_cl_device *cldev, struct
>mei_hdcp_data *data, int mei_store_pairing_info(struct mei_cl_device *cldev,
> struct mei_hdcp_data *data,
> struct hdcp2_ake_send_pairing_info *pairing_info);
>+int mei_initiate_locality_check(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data,
>+ struct hdcp2_lc_init *lc_init_data);
> #else
> static int mei_cldev_register_notify(struct notifier_block *nb) { @@ -160,5
>+163,12 @@ int mei_store_pairing_info(struct mei_cl_device *cldev, {
> return -ENODEV;
> }
>+static inline
>+int mei_initiate_locality_check(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data,
>+ struct hdcp2_lc_init *lc_init_data) {
>+ return -ENODEV;
>+}
> #endif /* defined (CONFIG_INTEL_MEI_HDCP) */ #endif /* defined
>(_LINUX_MEI_HDCP_H) */
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel
Re: [Intel-gfx] [PATCH v3 13/40] misc/mei/hdcp: Verify L_prime
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:27 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 13/40] misc/mei/hdcp: Verify L_prime
>
>Request to ME to verify the LPrime received from HDCP sink.
>
>On Success, ME FW will verify the received Lprime by calculating and comparing
>with L.
>
>This represents the completion of Locality Check.
>
>v2:
> Rebased.
>v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
>
>Signed-off-by: Ramalingam C
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 59
>
> include/linux/mei_hdcp.h | 8 ++
> 2 files changed, 67 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 9bd7e66a91e4..ea84177311b7 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -361,6 +361,65 @@ int mei_initiate_locality_check(struct mei_cl_device
>*cldev, } EXPORT_SYMBOL(mei_initiate_locality_check);
>
>+/**
>+ * mei_verify_lprime:
>+ *Function to verify lprime.
>+ *
>+ * @cldev : Pointer for mei client device
>+ * @data : Intel HW specific Data
>+ * @rx_lprime : Pointer for LC_Send_L_prime
>+ *
>+ * Returns 0 on Success, <0 on Failure
>+ */
>+int mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
>+struct hdcp2_lc_send_lprime *rx_lprime) {
>+ struct wired_cmd_validate_locality_in verify_lprime_in = { { 0 } };
>+ struct wired_cmd_validate_locality_out verify_lprime_out = { { 0 } };
>+ struct device *dev;
>+ ssize_t byte;
>+
>+ if (!data || !rx_lprime)
>+ return -EINVAL;
>+
>+ dev = &cldev->dev;
>+
>+ verify_lprime_in.header.api_version = HDCP_API_VERSION;
>+ verify_lprime_in.header.command_id = WIRED_VALIDATE_LOCALITY;
>+ verify_lprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+ verify_lprime_in.header.buffer_len =
>+
> WIRED_CMD_BUF_LEN_VALIDATE_LOCALITY_IN;
>+
>+ verify_lprime_in.port.integrated_port_type = data->port_type;
>+ verify_lprime_in.port.physical_port = data->port;
>+
>+ memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
Validate rx_lprime->l_prime for NULL
>+ sizeof(rx_lprime->l_prime));
>+
>+ byte = mei_cldev_send(cldev, (u8 *)&verify_lprime_in,
>+sizeof(verify_lprime_in));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ byte = mei_cldev_recv(cldev, (u8 *)&verify_lprime_out,
>+sizeof(verify_lprime_out));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ if (verify_lprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+ dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
>+ WIRED_VALIDATE_LOCALITY,
>+ verify_lprime_out.header.status);
>+ return -1;
>+ }
Leave a blank line.
>+ return 0;
>+}
>+EXPORT_SYMBOL(mei_verify_lprime);
>+
> void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled) {
> if (enabled)
>diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
>d9c4cac0b276..792143563c46 100644
>--- a/include/linux/mei_hdcp.h
>+++ b/include/linux/mei_hdcp.h
>@@ -124,6 +124,8 @@ int mei_store_pairing_info(struct mei_cl_device *cldev,
>int mei_initiate_locality_check(struct mei_cl_device *cldev,
> struct mei_hdcp_data *data,
> struct hdcp2_lc_init *lc_init_data);
>+int mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
>+struct hdcp2_lc_send_lprime *rx_lprime);
> #else
> static int mei_cldev_register_notify(struct notifier_block *nb) { @@ -170,5
>+172,11 @@ int mei_initiate_locality_check(struct mei_cl_device *cldev, {
> return -ENODEV;
> }
>+static inline
>+int mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
>+struct hdcp2_lc_send_lprime *rx_lprime) {
>+ return -ENODEV;
>+}
> #endif /* defined (CONFIG_INTEL_MEI_HDCP) */ #endif /* defined
>(_LINUX_MEI_HDCP_H) */
>--
>2.7.4
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/li
Re: [Intel-gfx] [PATCH][V2] drm/i915/dp: fix spelling mistakes: "seqeuncer" and "seqeuencer"
On Wed, 09 May 2018, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistakes in WARN warning message text and
> in comments:
>
> "seqeuncer", "seqeuencer" -> "sequencer"
>
> Signed-off-by: Colin Ian King
Reviewed-by: Jani Nikula
(Waiting for the CI runs before merging.)
> ---
>
> V2: Also fix seqeuencer in comments
>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..2cc58596ff5a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -513,7 +513,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
> uint32_t DP;
>
> if (WARN(I915_READ(intel_dp->output_reg) & DP_PORT_EN,
> - "skipping pipe %c power seqeuncer kick due to port %c being
> active\n",
> + "skipping pipe %c power sequencer kick due to port %c being
> active\n",
>pipe_name(pipe), port_name(intel_dig_port->base.port)))
> return;
>
> @@ -554,7 +554,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
> /*
>* Similar magic as in intel_dp_enable_port().
>* We _must_ do this port enable + disable trick
> - * to make this power seqeuencer lock onto the port.
> + * to make this power sequencer lock onto the port.
>* Otherwise even VDD force bit won't work.
>*/
> I915_WRITE(intel_dp->output_reg, DP);
> @@ -3066,11 +3066,11 @@ static void vlv_detach_power_sequencer(struct
> intel_dp *intel_dp)
> edp_panel_vdd_off_sync(intel_dp);
>
> /*
> - * VLV seems to get confused when multiple power seqeuencers
> + * VLV seems to get confused when multiple power sequencers
>* have the same port selected (even if only one has power/vdd
>* enabled). The failure manifests as vlv_wait_port_ready() failing
>* CHV on the other hand doesn't seem to mind having the same port
> - * selected in multiple power seqeuencers, but let's clear the
> + * selected in multiple power sequencers, but let's clear the
>* port select always when logically disconnecting a power sequencer
>* from a port.
>*/
> @@ -5698,7 +5698,7 @@ intel_dp_init_panel_power_sequencer_registers(struct
> intel_dp *intel_dp,
>
> /*
>* On some VLV machines the BIOS can leave the VDD
> - * enabled even on power seqeuencers which aren't
> + * enabled even on power sequencers which aren't
>* hooked up to any port. This would mess up the
>* power domain tracking the first time we pick
>* one of these power sequencers for use since
> @@ -5706,7 +5706,7 @@ intel_dp_init_panel_power_sequencer_registers(struct
> intel_dp *intel_dp,
>* already on and therefore wouldn't grab the power
>* domain reference. Disable VDD first to avoid this.
>* This also avoids spuriously turning the VDD on as
> - * soon as the new power seqeuencer gets initialized.
> + * soon as the new power sequencer gets initialized.
>*/
> if (force_disable_vdd) {
> u32 pp = ironlake_get_pp_control(intel_dp);
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: fix spelling mistakes: "seqeuncer" and "seqeuencer"
== Series Details == Series: drm/i915/dp: fix spelling mistakes: "seqeuncer" and "seqeuencer" URL : https://patchwork.freedesktop.org/series/42937/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4162 -> Patchwork_8960 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8960 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8960, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42937/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8960: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8960 that come from known issues: === IGT changes === Issues hit igt@kms_flip@basic-flip-vs-wf_vblank: fi-hsw-4770r: PASS -> FAIL (fdo#100368) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 == Participating hosts (41 -> 37) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq == Build changes == * Linux: CI_DRM_4162 -> Patchwork_8960 CI_DRM_4162: ea17aab5ec734a262a252758d7412c09dfa833cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8960: f76a6f37217db32642e478c43004bae5e030436d @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Linux commits == f76a6f37217d drm/i915/dp: fix spelling mistakes: "seqeuncer" and "seqeuencer" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8960/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 14/40] misc/mei/hdcp: Prepare Session Key
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:27 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 14/40] misc/mei/hdcp: Prepare Session Key
>
>Request to ME to prepare the encrypted session key.
>
>On Success, ME provides Encrypted session key. Functions populates the HDCP2.2
Drop "s" from function.
>authentication msg SKE_Send_Eks.
>
>v2:
> Rebased.
>v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
>
>Signed-off-by: Ramalingam C
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 58
>
> include/linux/mei_hdcp.h | 8 ++
> 2 files changed, 66 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index ea84177311b7..abfcc57863b8 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -420,6 +420,64 @@ int mei_verify_lprime(struct mei_cl_device *cldev,
>struct mei_hdcp_data *data, } EXPORT_SYMBOL(mei_verify_lprime);
>
>+/**
>+ * mei_get_session_key:
>+ *Function to prepare SKE_Send_Eks.
>+ *
>+ * @cldev : Pointer for mei client device
>+ * @data : Intel HW specific Data
>+ * @ske_data : Pointer for SKE_Send_Eks.
>+ *
>+ * Returns 0 on Success, <0 on Failure
>+ */
>+int mei_get_session_key(struct mei_cl_device *cldev, struct mei_hdcp_data
>*data,
>+ struct hdcp2_ske_send_eks *ske_data) {
>+ struct wired_cmd_get_session_key_in get_skey_in = { { 0 } };
>+ struct wired_cmd_get_session_key_out get_skey_out = { { 0 } };
>+ struct device *dev;
>+ ssize_t byte;
>+
>+ if (!data || !ske_data)
>+ return -EINVAL;
>+
>+ dev = &cldev->dev;
>+
>+ get_skey_in.header.api_version = HDCP_API_VERSION;
>+ get_skey_in.header.command_id = WIRED_GET_SESSION_KEY;
>+ get_skey_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+ get_skey_in.header.buffer_len =
>WIRED_CMD_BUF_LEN_GET_SESSION_KEY_IN;
>+
>+ get_skey_in.port.integrated_port_type = data->port_type;
>+ get_skey_in.port.physical_port = data->port;
>+
>+ byte = mei_cldev_send(cldev, (u8 *)&get_skey_in, sizeof(get_skey_in));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ byte = mei_cldev_recv(cldev, (u8 *)&get_skey_out,
>+sizeof(get_skey_out));
>+
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ if (get_skey_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+ dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
>+ WIRED_GET_SESSION_KEY,
>get_skey_out.header.status);
>+ return -1;
>+ }
>+
>+ ske_data->msg_id = HDCP_2_2_SKE_SEND_EKS;
>+ memcpy(ske_data->e_dkey_ks, get_skey_out.e_dkey_ks,
Check for validity of ske_data->e_dkey_ks.
>+ HDCP_2_2_E_DKEY_KS_LEN);
>+ memcpy(ske_data->riv, get_skey_out.r_iv, HDCP_2_2_RIV_LEN);
Again check for ske_data->riv. Also leave a blank line here.
>+ return 0;
>+}
>+EXPORT_SYMBOL(mei_get_session_key);
>+
> void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled) {
> if (enabled)
>diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
>792143563c46..534170d746af 100644
>--- a/include/linux/mei_hdcp.h
>+++ b/include/linux/mei_hdcp.h
>@@ -126,6 +126,8 @@ int mei_initiate_locality_check(struct mei_cl_device
>*cldev,
> struct hdcp2_lc_init *lc_init_data); int
>mei_verify_lprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
> struct hdcp2_lc_send_lprime *rx_lprime);
>+int mei_get_session_key(struct mei_cl_device *cldev, struct mei_hdcp_data
>*data,
>+ struct hdcp2_ske_send_eks *ske_data);
> #else
> static int mei_cldev_register_notify(struct notifier_block *nb) { @@ -178,5
>+180,11 @@ int mei_verify_lprime(struct mei_cl_device *cldev, struct
>mei_hdcp_data *data, {
> return -ENODEV;
> }
>+static inline
>+int mei_get_session_key(struct mei_cl_device *cldev, struct mei_hdcp_data
>*data,
>+ struct hdcp2_ske_send_eks *ske_data) {
>+ return -ENODEV;
>+}
> #endif /* defined (CONFIG_INTEL_MEI_HDCP) */ #endif /* defined
>(_LINUX_MEI_HDCP_H) */
>--
>2.7.4
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists
Re: [Intel-gfx] [PATCH v3 15/40] misc/mei/hdcp: Repeater topology verifcation and ack
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:27 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [PATCH v3 15/40] misc/mei/hdcp: Repeater topology verifcation and ack
Typo in verification.
>
>Request ot ME to verify the downatream topology information received.
"To" misspelled. Also typo in downstream.
>
>ME FW will validate the Repeaters receiver id list and downstream topology.
>
>On Success ME FW will provide the Least Significant 128bits of VPrime, which
>forms the repeater ack.
>
>v2:
> Rebased.
>v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
>
>Signed-off-by: Ramalingam C
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 75
>
> include/linux/mei_hdcp.h | 15
> 2 files changed, 90 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index abfcc57863b8..64fcecfa5b10 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -478,6 +478,81 @@ int mei_get_session_key(struct mei_cl_device *cldev,
>struct mei_hdcp_data *data, } EXPORT_SYMBOL(mei_get_session_key);
>
>+/**
>+ * mei_repeater_check_flow_prepare_ack:
>+ *Function to validate the Downstream topology and prepare rep_ack.
>+ *
>+ * @cldev : Pointer for mei client device
>+ * @data : Intel HW specific Data
>+ * @rep_topology : Pointer for Receiver Id List to be validated.
>+ * @rep_send_ack : Pointer for repeater ack
>+ *
>+ * Returns 0 on Success, <0 on Failure
>+ */
>+
>+int
>+mei_repeater_check_flow_prepare_ack(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data,
>+ struct hdcp2_rep_send_receiverid_list
>+ *rep_topology,
>+ struct hdcp2_rep_send_ack *rep_send_ack) {
>+ struct wired_cmd_verify_repeater_in verify_repeater_in = { { 0 } };
>+ struct wired_cmd_verify_repeater_out verify_repeater_out = { { 0 } };
>+ struct device *dev;
>+ ssize_t byte;
>+
>+ if (!rep_topology || !rep_send_ack || !data)
>+ return -EINVAL;
>+
>+ dev = &cldev->dev;
>+
>+ verify_repeater_in.header.api_version = HDCP_API_VERSION;
>+ verify_repeater_in.header.command_id = WIRED_VERIFY_REPEATER;
>+ verify_repeater_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+ verify_repeater_in.header.buffer_len =
>+
> WIRED_CMD_BUF_LEN_VERIFY_REPEATER_IN;
>+
>+ verify_repeater_in.port.integrated_port_type = data->port_type;
>+ verify_repeater_in.port.physical_port = data->port;
>+
>+ memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
>+ HDCP_2_2_RXINFO_LEN);
>+ memcpy(verify_repeater_in.seq_num_v, rep_topology->seq_num_v,
>+ HDCP_2_2_SEQ_NUM_LEN);
>+ memcpy(verify_repeater_in.v_prime, rep_topology->v_prime,
>+ HDCP_2_2_LPRIME_HALF_LEN);
>+ memcpy(verify_repeater_in.receiver_ids, rep_topology->receiver_ids,
>+ HDCP_2_2_RECEIVER_IDS_MAX_LEN);
Check for validity of rep_topology->... pointers.
>+
>+ byte = mei_cldev_send(cldev, (u8 *)&verify_repeater_in,
>+sizeof(verify_repeater_in));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ byte = mei_cldev_recv(cldev, (u8 *)&verify_repeater_out,
>+sizeof(verify_repeater_out));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ if (verify_repeater_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+ dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
>+ WIRED_VERIFY_REPEATER,
>+ verify_repeater_out.header.status);
>+ return -1;
>+ }
>+
>+ memcpy(rep_send_ack->v, verify_repeater_out.v,
Same as above.
>+ HDCP_2_2_LPRIME_HALF_LEN);
>+ rep_send_ack->msg_id = HDCP_2_2_REP_SEND_ACK;
Leave a blank line here.
>+ return 0;
>+}
>+EXPORT_SYMBOL(mei_repeater_check_flow_prepare_ack);
>+
> void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled) {
> if (enabled)
>diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
>534170d746af..46e2dc295d03 100644
>--- a/include/linux/mei_hdcp.h
>+++ b/include/linux/mei_hdcp.h
>@@ -128,6 +128,12 @@ int mei_verify_lprime(struct mei_cl_device *cldev,
>struct mei_hdcp_data *data,
> struct h
Re: [Intel-gfx] [PATCH 13/22] drm/i915/icl: WaForwardProgressSoftReset
Oscar Mateo writes:
> Avoids a hang during soft reset.
>
> v2: Rebased on top of the WA refactoring
> v3: Added References (Mika)
> v4:
> - Rebased
> - C, not lisp (Chris)
> - Which steppings affected by this are not clear.
> For the moment, apply unconditionally as per the
> BSpec (Mika)
> - Add reference to another HSD also related
>
> References: HSDES#1405476379
> References: HSDES#2006612137
> Cc: Mika Kuoppala
> Signed-off-by: Oscar Mateo
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5 +
> drivers/gpu/drm/i915/intel_workarounds.c | 7 +++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ce48427..1449178 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9897,6 +9897,11 @@ enum skl_power_gate {
> /* Media decoder 2 MOCS registers */
> #define GEN11_MFX2_MOCS(i) _MMIO(0x1 + (i) * 4)
>
> +#define GEN10_SCRATCH_LNCF2 _MMIO(0xb0a0)
> +#define PMFLUSHDONE_LNICRSDROP (1 << 20)
> +#define PMFLUSH_GAPL3UNBLOCK (1 << 21)
> +#define PMFLUSHDONE_LNEBLK (1 << 22)
> +
> /* gamt regs */
> #define GEN8_L3_LRA_1_GPGPU _MMIO(0x4dd4)
> #define GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_BDW 0x67F1427F /* max/min for
> LRA1/2 */
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 942d322..5eec4ce 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -761,6 +761,13 @@ static void icl_gt_workarounds_apply(struct
> drm_i915_private *dev_priv)
> I915_WRITE(INF_UNIT_LEVEL_CLKGATE,
> I915_READ(INF_UNIT_LEVEL_CLKGATE) |
> CGPSF_CLKGATE_DIS);
> +
> + /* WaForwardProgressSoftReset:icl */
> + I915_WRITE(GEN10_SCRATCH_LNCF2,
> +I915_READ(GEN10_SCRATCH_LNCF2) |
> +PMFLUSHDONE_LNICRSDROP |
> +PMFLUSH_GAPL3UNBLOCK |
> +PMFLUSHDONE_LNEBLK);
> }
>
> void intel_gt_workarounds_apply(struct drm_i915_private *dev_priv)
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: fix spelling mistake: "seqeuncer" -> "sequencer"
== Series Details == Series: drm/i915/dp: fix spelling mistake: "seqeuncer" -> "sequencer" URL : https://patchwork.freedesktop.org/series/42935/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4162_full -> Patchwork_8959_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8959_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8959_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42935/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8959_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: PASS -> SKIP igt@gem_exec_schedule@deep-bsd2: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_8959_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) +1 igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic: shard-hsw: FAIL (fdo#104873) -> PASS igt@kms_flip@flip-vs-wf_vblank-interruptible: shard-glk: FAIL (fdo#100368) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS +1 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4162 -> Patchwork_8959 CI_DRM_4162: ea17aab5ec734a262a252758d7412c09dfa833cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8959: 9cecedefb9e2280719feafeb9f9e4c4b3f8302d1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8959/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/5] drm/i915: Combine tasklet_kill and tasklet_disable
Ideally, we want to atomically flush and disable the tasklet before
resetting the GPU. At present, we rely on being the only part to touch
our tasklet and serialisation of the reset process to ensure that we can
suspend the tasklet from the mix of reset/wedge pathways. In this patch,
we move the tasklet abuse into its own function and tweak it such that
we only do a synchronous operation the first time it is disabled around
the reset. This allows us to avoid the sync inside a softirq context in
subsequent patches.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
---
drivers/gpu/drm/i915/i915_gem.c| 2 --
drivers/gpu/drm/i915/i915_tasklet.h| 14 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 98481e150e61..8d27e78b052c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3043,8 +3043,6 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
* common case of recursively being called from set-wedged from inside
* i915_reset.
*/
- if (i915_tasklet_is_enabled(&engine->execlists.tasklet))
- i915_tasklet_flush(&engine->execlists.tasklet);
i915_tasklet_disable(&engine->execlists.tasklet);
/*
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
index c9f41a5ebb91..d8263892f385 100644
--- a/drivers/gpu/drm/i915/i915_tasklet.h
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -59,10 +59,24 @@ static inline void i915_tasklet_enable(struct i915_tasklet
*t)
}
static inline void i915_tasklet_disable(struct i915_tasklet *t)
+{
+ if (i915_tasklet_is_enabled(t))
+ i915_tasklet_flush(t);
+
+ if (atomic_inc_return(&t->base.count) == 1)
+ tasklet_unlock_wait(&t->base);
+}
+
+static inline void i915_tasklet_lock(struct i915_tasklet *t)
{
tasklet_disable(&t->base);
}
+static inline void i915_tasklet_unlock(struct i915_tasklet *t)
+{
+ tasklet_enable(&t->base);
+}
+
static inline void i915_tasklet_set_func(struct i915_tasklet *t,
void (*func)(unsigned long data),
unsigned long data)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 5f1118ea96d8..3c8a0c3245f3 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1478,7 +1478,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
if (!intel_engine_supports_stats(engine))
return -ENODEV;
- i915_tasklet_disable(&execlists->tasklet);
+ i915_tasklet_lock(&execlists->tasklet);
write_seqlock_irqsave(&engine->stats.lock, flags);
if (unlikely(engine->stats.enabled == ~0)) {
@@ -1504,7 +1504,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
unlock:
write_sequnlock_irqrestore(&engine->stats.lock, flags);
- i915_tasklet_enable(&execlists->tasklet);
+ i915_tasklet_unlock(&execlists->tasklet);
return err;
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 5/5] drm/i915: Speed up idle detection by kicking the tasklets
We rely on ksoftirqd to run in a timely fashion in order to drain the execlists queue. Quite frequently, it does not. In some cases we may see latencies of over 200ms triggering our idle timeouts and forcing us to declare the driver wedged! Thus we can speed up idle detection by bypassing ksoftirqd in these cases and flush our tasklet to confirm if we are indeed still waiting for the ELSP to drain. v2: Put the execlists.first check back; it is required for handling reset! v3: Follow Mika's suggestion to try and limit kicking the tasklet to only when we expect it to make a difference, i.e. in catch up after a CS interrupt, and not just execute it everytime as that is likely just to cover over our own bugs. References: https://bugs.freedesktop.org/show_bug.cgi?id=106373 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index 3c8a0c3245f3..f975091c5498 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -944,11 +944,20 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine) if (I915_SELFTEST_ONLY(engine->breadcrumbs.mock)) return true; + /* +* ksoftirqd has notorious latency that may cause us to +* timeout while waiting for the engine to idle as we wait for +* ksoftirqd to run the execlists tasklet to drain the ELSP. +* If we are expecting a context switch from the GPU, check now. +*/ + if (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted)) + i915_tasklet_try(&engine->execlists.tasklet); + /* Waiting to drain ELSP? */ if (READ_ONCE(engine->execlists.active)) return false; - /* ELSP is empty, but there are ready requests? */ + /* ELSP is empty, but there are ready requests? E.g. after reset */ if (READ_ONCE(engine->execlists.first)) return false; -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 3/5] drm/i915/execlists: Direct submit onto idle engines
Bypass using the tasklet to submit the first request to HW, as the
tasklet may be deferred unto ksoftirqd and at a minimum will add in
excess of 10us (and maybe tens of milliseconds) to our execution
latency. This latency reduction is most notable when execution flows
between engines.
v2: Beware handling preemption completion from the direct submit path as
well.
v3: Make the abuse clear and track our extra state inside i915_tasklet.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_tasklet.h | 24 +++
drivers/gpu/drm/i915/intel_guc_submission.c | 10 ++-
drivers/gpu/drm/i915/intel_lrc.c| 71 +
3 files changed, 89 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
index d8263892f385..bb8f03a03b29 100644
--- a/drivers/gpu/drm/i915/i915_tasklet.h
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -8,8 +8,11 @@
#define _I915_TASKLET_H_
#include
+#include
#include
+#include "i915_gem.h"
+
/**
* struct i915_tasklet - wrapper around tasklet_struct
*
@@ -19,6 +22,8 @@
*/
struct i915_tasklet {
struct tasklet_struct base;
+ unsigned long flags;
+#define I915_TASKLET_DIRECT_SUBMIT BIT(0)
};
static inline void i915_tasklet_init(struct i915_tasklet *t,
@@ -43,6 +48,14 @@ static inline bool i915_tasklet_is_enabled(const struct
i915_tasklet *t)
return likely(!atomic_read(&t->base.count));
}
+static inline bool i915_tasklet_is_direct_submit(const struct i915_tasklet *t)
+{
+ /* Only legal to be checked from inside the tasklet. */
+ GEM_BUG_ON(!i915_tasklet_is_locked(t));
+
+ return t->flags & I915_TASKLET_DIRECT_SUBMIT;
+}
+
static inline void i915_tasklet_schedule(struct i915_tasklet *t)
{
tasklet_hi_schedule(&t->base);
@@ -89,4 +102,15 @@ static inline void i915_tasklet_set_func(struct
i915_tasklet *t,
tasklet_enable(&t->base);
}
+static inline void __i915_tasklet_run(const struct i915_tasklet *t)
+{
+ t->base.func(t->base.data);
+}
+
+static inline void i915_tasklet_run(const struct i915_tasklet *t)
+{
+ GEM_BUG_ON(!i915_tasklet_is_locked(t));
+ __i915_tasklet_run(t);
+}
+
#endif /* _I915_TASKLET_H_ */
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index a7afc976c3b9..f2ded1796523 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -754,14 +754,18 @@ static bool __guc_dequeue(struct intel_engine_cs *engine)
static void guc_dequeue(struct intel_engine_cs *engine)
{
- unsigned long flags;
+ unsigned long uninitialized_var(flags);
bool submit;
local_irq_save(flags);
- spin_lock(&engine->timeline.lock);
+ if (!i915_tasklet_is_direct_submit(&engine->execlists.tasklet))
+ spin_lock(&engine->timeline.lock);
+
submit = __guc_dequeue(engine);
- spin_unlock(&engine->timeline.lock);
+
+ if (!i915_tasklet_is_direct_submit(&engine->execlists.tasklet))
+ spin_unlock(&engine->timeline.lock);
if (submit)
guc_submit(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 539fa03d7600..09fded9d409f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -356,13 +356,15 @@ execlists_unwind_incomplete_requests(struct
intel_engine_execlists *execlists)
{
struct intel_engine_cs *engine =
container_of(execlists, typeof(*engine), execlists);
- unsigned long flags;
+ unsigned long uninitialized_var(flags);
- spin_lock_irqsave(&engine->timeline.lock, flags);
+ if (!i915_tasklet_is_direct_submit(&execlists->tasklet))
+ spin_lock_irqsave(&engine->timeline.lock, flags);
__unwind_incomplete_requests(engine);
- spin_unlock_irqrestore(&engine->timeline.lock, flags);
+ if (!i915_tasklet_is_direct_submit(&execlists->tasklet))
+ spin_unlock_irqrestore(&engine->timeline.lock, flags);
}
static inline void
@@ -601,6 +603,8 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
*/
GEM_BUG_ON(!execlists_is_active(execlists,
EXECLISTS_ACTIVE_USER));
+ GEM_BUG_ON(execlists_is_active(execlists,
+ EXECLISTS_ACTIVE_PREEMPT));
GEM_BUG_ON(!port_count(&port[0]));
if (port_count(&port[0]) > 1)
return false;
@@ -757,12 +761,16 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
static void execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
- unsigned long flags;
+ unsigned lon
[Intel-gfx] [PATCH v3 4/5] drm/i915/execlists: Direct submission from irq handler
Continuing the theme of bypassing ksoftirqd latency, also first try to
directly submit from the CS interrupt handler to clear the ELSP and
queue the next.
In the past, we have been hesitant to do this as the context switch
processing has been quite heavy, requiring forcewaked mmio. However, as
we now can read the GPU state from the cacheable HWSP, it is relatively
cheap!
v2: Explain why we test_bit(IRQ_EXECLIST) after doing notify_ring (it's
because the notify_ring() may itself trigger direct submission clearing
the bit)
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_irq.c | 21 ++---
drivers/gpu/drm/i915/i915_tasklet.h | 19 +++
drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f8aff5a5aa83..e1b3a7575fe7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1465,19 +1465,26 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
struct intel_engine_execlists * const execlists = &engine->execlists;
bool tasklet = false;
- if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
- if (READ_ONCE(engine->execlists.active))
- tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
- &engine->irq_posted);
- }
+ if (iir & GT_CONTEXT_SWITCH_INTERRUPT && READ_ONCE(execlists->active))
+ tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
+ &engine->irq_posted);
if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
- tasklet |= USES_GUC_SUBMISSION(engine->i915);
+ /*
+* notify_ring() may trigger direct submission onto this
+* engine, clearing the ENGINE_IRQ_EXECLIST bit. In that
+* case, we don't want to resubmit and so clear the tasklet
+* boolean. GuC never sets the ENGINE_IRQ_EXECLIST bit and
+* so when using the GuC this equates to an unconditional
+* setting of tasklet to true.
+*/
+ if (!test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted))
+ tasklet = USES_GUC_SUBMISSION(engine->i915);
}
if (tasklet)
- i915_tasklet_schedule(&execlists->tasklet);
+ i915_tasklet(&execlists->tasklet);
}
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
index bb8f03a03b29..6fcab4ec7f35 100644
--- a/drivers/gpu/drm/i915/i915_tasklet.h
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -113,4 +113,23 @@ static inline void i915_tasklet_run(const struct
i915_tasklet *t)
__i915_tasklet_run(t);
}
+static inline bool i915_tasklet_try(struct i915_tasklet *t)
+{
+ if (unlikely(!tasklet_trylock(&t->base)))
+ return false;
+
+ i915_tasklet_run(t);
+ tasklet_unlock(&t->base);
+ return true;
+}
+
+static inline void i915_tasklet(struct i915_tasklet *t)
+{
+ if (!i915_tasklet_is_enabled(t)) /* GPU reset active */
+ return;
+
+ if (!i915_tasklet_try(t))
+ i915_tasklet_schedule(t);
+}
+
#endif /* _I915_TASKLET_H_ */
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index f2ded1796523..4e09abf7e206 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -780,6 +780,8 @@ static void guc_submission_tasklet(unsigned long data)
struct execlist_port *port = execlists->port;
struct i915_request *rq;
+ clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+
rq = port_request(port);
while (rq && i915_request_completed(rq)) {
trace_i915_request_out(rq);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/5] drm/i915: Wrap tasklet_struct for abuse
In the next few patches, we want to abuse tasklet to avoid ksoftirqd
latency along critical paths. To make that abuse easily to swallow,
first coat the tasklet in a little syntactic sugar.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 8 +--
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_tasklet.h | 78 +
drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++-
drivers/gpu/drm/i915/intel_guc_submission.c | 8 +--
drivers/gpu/drm/i915/intel_lrc.c| 18 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +-
7 files changed, 104 insertions(+), 24 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_tasklet.h
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 89bf5d67cb74..98481e150e61 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3043,9 +3043,9 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
* common case of recursively being called from set-wedged from inside
* i915_reset.
*/
- if (!atomic_read(&engine->execlists.tasklet.count))
- tasklet_kill(&engine->execlists.tasklet);
- tasklet_disable(&engine->execlists.tasklet);
+ if (i915_tasklet_is_enabled(&engine->execlists.tasklet))
+ i915_tasklet_flush(&engine->execlists.tasklet);
+ i915_tasklet_disable(&engine->execlists.tasklet);
/*
* We're using worker to queue preemption requests from the tasklet in
@@ -3265,7 +3265,7 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
{
- tasklet_enable(&engine->execlists.tasklet);
+ i915_tasklet_enable(&engine->execlists.tasklet);
kthread_unpark(engine->breadcrumbs.signaler);
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f9bc3aaa90d0..f8aff5a5aa83 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1477,7 +1477,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
}
if (tasklet)
- tasklet_hi_schedule(&execlists->tasklet);
+ i915_tasklet_schedule(&execlists->tasklet);
}
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
new file mode 100644
index ..c9f41a5ebb91
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -0,0 +1,78 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef _I915_TASKLET_H_
+#define _I915_TASKLET_H_
+
+#include
+#include
+
+/**
+ * struct i915_tasklet - wrapper around tasklet_struct
+ *
+ * We want to abuse tasklets slightly, such as calling them directly. In some
+ * cases, this requires some auxiliary tracking so subclass the tasklet_struct
+ * so that we have a central place and helpers.
+ */
+struct i915_tasklet {
+ struct tasklet_struct base;
+};
+
+static inline void i915_tasklet_init(struct i915_tasklet *t,
+void (*func)(unsigned long),
+unsigned long data)
+{
+ tasklet_init(&t->base, func, data);
+}
+
+static inline bool i915_tasklet_is_scheduled(const struct i915_tasklet *t)
+{
+ return test_bit(TASKLET_STATE_SCHED, &t->base.state);
+}
+
+static inline bool i915_tasklet_is_locked(const struct i915_tasklet *t)
+{
+ return test_bit(TASKLET_STATE_RUN, &t->base.state);
+}
+
+static inline bool i915_tasklet_is_enabled(const struct i915_tasklet *t)
+{
+ return likely(!atomic_read(&t->base.count));
+}
+
+static inline void i915_tasklet_schedule(struct i915_tasklet *t)
+{
+ tasklet_hi_schedule(&t->base);
+}
+
+static inline void i915_tasklet_flush(struct i915_tasklet *t)
+{
+ tasklet_kill(&t->base);
+}
+
+static inline void i915_tasklet_enable(struct i915_tasklet *t)
+{
+ tasklet_enable(&t->base);
+}
+
+static inline void i915_tasklet_disable(struct i915_tasklet *t)
+{
+ tasklet_disable(&t->base);
+}
+
+static inline void i915_tasklet_set_func(struct i915_tasklet *t,
+void (*func)(unsigned long data),
+unsigned long data)
+{
+ tasklet_disable(&t->base);
+
+ t->base.func = func;
+ t->base.data = data;
+
+ tasklet_enable(&t->base);
+}
+
+#endif /* _I915_TASKLET_H_ */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 70325e0824e3..5f1118ea96d8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1032,7 +1032,7 @@ void intel_engines_park(struct drm_i915_private *i915)
for_each_engine(engine, i915, id) {
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: fix spelling mistakes: "seqeuncer" and "seqeuencer"
== Series Details == Series: drm/i915/dp: fix spelling mistakes: "seqeuncer" and "seqeuencer" URL : https://patchwork.freedesktop.org/series/42937/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4162_full -> Patchwork_8960_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8960_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8960_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42937/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8960_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: PASS -> SKIP +1 igt@gem_exec_schedule@deep-bsd2: shard-kbl: SKIP -> PASS igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-hsw: PASS -> SKIP +1 igt@kms_vblank@pipe-b-query-idle: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8960_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@modeset-vs-vblank-race: shard-glk: PASS -> FAIL (fdo#103060) igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-hsw: PASS -> FAIL (fdo#103928) igt@kms_flip@wf_vblank-ts-check-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic: shard-hsw: FAIL (fdo#104873) -> PASS igt@kms_flip@flip-vs-wf_vblank-interruptible: shard-glk: FAIL (fdo#100368) -> PASS +1 igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS +1 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4162 -> Patchwork_8960 CI_DRM_4162: ea17aab5ec734a262a252758d7412c09dfa833cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8960: f76a6f37217db32642e478c43004bae5e030436d @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8960/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/5] drm/i915: Wrap tasklet_struct for abuse
== Series Details == Series: series starting with [v3,1/5] drm/i915: Wrap tasklet_struct for abuse URL : https://patchwork.freedesktop.org/series/42942/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Wrap tasklet_struct for abuse Okay! Commit: drm/i915: Combine tasklet_kill and tasklet_disable Okay! Commit: drm/i915/execlists: Direct submit onto idle engines +drivers/gpu/drm/i915/intel_guc_submission.c:768:28: warning: context imbalance in 'guc_dequeue' - unexpected unlock +drivers/gpu/drm/i915/intel_lrc.c:367:39: warning: context imbalance in 'execlists_unwind_incomplete_requests' - unexpected unlock +drivers/gpu/drm/i915/intel_lrc.c:773:39: warning: context imbalance in 'execlists_dequeue' - unexpected unlock Commit: drm/i915/execlists: Direct submission from irq handler Okay! Commit: drm/i915: Speed up idle detection by kicking the tasklets Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/5] drm/i915: Wrap tasklet_struct for abuse
== Series Details == Series: series starting with [v3,1/5] drm/i915: Wrap tasklet_struct for abuse URL : https://patchwork.freedesktop.org/series/42942/ State : warning == Summary == $ dim checkpatch origin/drm-tip 949ea8da2485 drm/i915: Wrap tasklet_struct for abuse -:53: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #53: new file mode 100644 -:58: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #58: FILE: drivers/gpu/drm/i915/i915_tasklet.h:1: +/* total: 0 errors, 2 warnings, 0 checks, 225 lines checked 48eff927a0b7 drm/i915: Combine tasklet_kill and tasklet_disable 7a3aa88dc258 drm/i915/execlists: Direct submit onto idle engines -:85: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should also have an identifier name #85: FILE: drivers/gpu/drm/i915/intel_guc_submission.c:757: + unsigned long uninitialized_var(flags); -:111: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should also have an identifier name #111: FILE: drivers/gpu/drm/i915/intel_lrc.c:359: + unsigned long uninitialized_var(flags); -:139: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should also have an identifier name #139: FILE: drivers/gpu/drm/i915/intel_lrc.c:764: + unsigned long uninitialized_var(flags); total: 0 errors, 3 warnings, 0 checks, 192 lines checked acdabab95b40 drm/i915/execlists: Direct submission from irq handler 5126eaff44f8 drm/i915: Speed up idle detection by kicking the tasklets ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
On Wed, May 09, 2018 at 10:13:21AM +0300, Jani Nikula wrote:
> We've opted to use the maximum link rate and lane count for eDP panels,
> because typically the maximum supported configuration reported by the
> panel has matched the native resolution requirements of the panel, and
> optimizing the link has lead to problems.
>
> With eDP 1.4 rate select method and DSC features, this is decreasingly
> the case. There's a need to optimize the link parameters. Moreover,
> already eDP 1.3 states fast link with fewer lanes is preferred over the
> wide and slow. (Wide and slow should still be more reliable for longer
> cable lengths.)
>
> Additionally, there have been reports of panels failing on arbitrary
> link configurations, although arguably all configurations they claim to
> support should work.
>
> Optimize eDP 1.4+ link config fast and narrow.
>
> Side note: The implementation has a near duplicate of the link config
> function, with just the two inner for loops turned inside out. Perhaps
> there'd be a way to make this, say, more table driven to reduce the
> duplication, but seems like that would lead to duplication in the table
> generation. We'll also have to see how the link config optimization for
> DSC turns out.
>
> Cc: Ville Syrjälä
> Cc: Manasi Navare
> Cc: Rodrigo Vivi
Cc: Matt Atwood
I believe Matt is interested on this and know who could test this for us.
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> Signed-off-by: Jani Nikula
This matches my understand of the eDP 1.4 spec I believe this is the
way to go, so
Acked-by: Rodrigo Vivi
but probably better to get a proper review and wait for someone
to test...
>
> ---
>
> Untested. It's possible this helps the referenced bug. The downside is
> that this patch has a bunch of dependencies that are too much to
> backport to stable kernels. If the patch works, we may need to consider
> hacking together an uglier backport.
> ---
> drivers/gpu/drm/i915/intel_dp.c | 73
> ++---
> 1 file changed, 62 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..1ec62965ece3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1768,6 +1768,42 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> return false;
> }
>
> +/* Optimize link config in order: max bpp, min lanes, min clock */
> +static bool
> +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> + struct intel_crtc_state *pipe_config,
> + const struct link_config_limits *limits)
> +{
> + struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
> + int bpp, clock, lane_count;
> + int mode_rate, link_clock, link_avail;
> +
> + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> + mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> +bpp);
> +
> + for (lane_count = limits->min_lane_count;
> + lane_count <= limits->max_lane_count;
> + lane_count <<= 1) {
> + for (clock = limits->min_clock; clock <=
> limits->max_clock; clock++) {
> + link_clock = intel_dp->common_rates[clock];
> + link_avail = intel_dp_max_data_rate(link_clock,
> + lane_count);
> +
> + if (mode_rate <= link_avail) {
> + pipe_config->lane_count = lane_count;
> + pipe_config->pipe_bpp = bpp;
> + pipe_config->port_clock = link_clock;
> +
> + return true;
> + }
> + }
> + }
> + }
> +
> + return false;
> +}
> +
> static bool
> intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config)
> @@ -1792,13 +1828,15 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> limits.min_bpp = 6 * 3;
> limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>
> - if (intel_dp_is_edp(intel_dp)) {
> + if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
> /*
>* Use the maximum clock and number of lanes the eDP panel
> - * advertizes being capable of. The panels are generally
> - * designed to support only a single clock and lane
> - * configuration, and typically these values correspond to the
> - * native resolution of the panel.
> + * advertizes being capable of. The eDP 1.3 and earlier panels
> + * are gene
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/5] drm/i915: Wrap tasklet_struct for abuse
== Series Details == Series: series starting with [v3,1/5] drm/i915: Wrap tasklet_struct for abuse URL : https://patchwork.freedesktop.org/series/42942/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4162 -> Patchwork_8961 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/42942/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8961 that come from known issues: === IGT changes === Issues hit igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 == Participating hosts (41 -> 37) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq == Build changes == * Linux: CI_DRM_4162 -> Patchwork_8961 CI_DRM_4162: ea17aab5ec734a262a252758d7412c09dfa833cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8961: 5126eaff44f881f5deff006f2338ef87f4940bf9 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Linux commits == 5126eaff44f8 drm/i915: Speed up idle detection by kicking the tasklets acdabab95b40 drm/i915/execlists: Direct submission from irq handler 7a3aa88dc258 drm/i915/execlists: Direct submit onto idle engines 48eff927a0b7 drm/i915: Combine tasklet_kill and tasklet_disable 949ea8da2485 drm/i915: Wrap tasklet_struct for abuse == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8961/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Check if VBT says PSR can be enabled.
On Tue, May 08, 2018 at 05:35:24PM -0700, Dhinakaran Pandiyan wrote:
> Driver features data block has a boolean flag for PSR, use this to decide
> whether PSR should be enabled on a platform. The module parameter can
> still be used to override this.
>
> Note: The feature currently remains disabled by default for all platforms
> irrespective of what VBT says.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 7 +--
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 04e27806e581..24c5e4765afd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1073,6 +1073,7 @@ struct intel_vbt_data {
> } edp;
>
> struct {
> + bool enable;
> bool full_link;
> bool require_aux_wakeup;
> int idle_frames;
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 702d3fab97fc..54270bdde100 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -530,6 +530,7 @@ parse_driver_features(struct drm_i915_private *dev_priv,
>*/
> if (!driver->drrs_enabled)
> dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
> + dev_priv->vbt.psr.enable = driver->psr_enabled;
> }
>
> static void
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 6233a322aac5..db27f2faa1de 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -1173,9 +1173,12 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
> if (!dev_priv->psr.sink_support)
> return;
>
> - /* Per platform default: all disabled. */
> - if (i915_modparams.enable_psr == -1)
> + if (i915_modparams.enable_psr == -1) {
> + i915_modparams.enable_psr = dev_priv->vbt.psr.enable;
> +
> + /* Per platform default: all disabled. */
> i915_modparams.enable_psr = 0;
> + }
>
> /* Set link_standby x link_off defaults */
> if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> --
> 2.14.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Wrap tasklet_struct for abuse
Chris Wilson writes:
> In the next few patches, we want to abuse tasklet to avoid ksoftirqd
> latency along critical paths. To make that abuse easily to swallow,
> first coat the tasklet in a little syntactic sugar.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_gem.c | 8 +--
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> drivers/gpu/drm/i915/i915_tasklet.h | 78 +
> drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++-
> drivers/gpu/drm/i915/intel_guc_submission.c | 8 +--
> drivers/gpu/drm/i915/intel_lrc.c| 18 ++---
> drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +-
> 7 files changed, 104 insertions(+), 24 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_tasklet.h
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 89bf5d67cb74..98481e150e61 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3043,9 +3043,9 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
> *engine)
>* common case of recursively being called from set-wedged from inside
>* i915_reset.
>*/
> - if (!atomic_read(&engine->execlists.tasklet.count))
> - tasklet_kill(&engine->execlists.tasklet);
> - tasklet_disable(&engine->execlists.tasklet);
> + if (i915_tasklet_is_enabled(&engine->execlists.tasklet))
> + i915_tasklet_flush(&engine->execlists.tasklet);
> + i915_tasklet_disable(&engine->execlists.tasklet);
>
> /*
>* We're using worker to queue preemption requests from the tasklet in
> @@ -3265,7 +3265,7 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
>
> void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
> {
> - tasklet_enable(&engine->execlists.tasklet);
> + i915_tasklet_enable(&engine->execlists.tasklet);
> kthread_unpark(engine->breadcrumbs.signaler);
>
> intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f9bc3aaa90d0..f8aff5a5aa83 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1477,7 +1477,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
> iir)
> }
>
> if (tasklet)
> - tasklet_hi_schedule(&execlists->tasklet);
> + i915_tasklet_schedule(&execlists->tasklet);
> }
>
> static void gen8_gt_irq_ack(struct drm_i915_private *i915,
> diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
> b/drivers/gpu/drm/i915/i915_tasklet.h
> new file mode 100644
> index ..c9f41a5ebb91
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_tasklet.h
> @@ -0,0 +1,78 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + *
> + * Copyright © 2018 Intel Corporation
> + */
> +
> +#ifndef _I915_TASKLET_H_
> +#define _I915_TASKLET_H_
> +
> +#include
> +#include
> +
> +/**
> + * struct i915_tasklet - wrapper around tasklet_struct
> + *
> + * We want to abuse tasklets slightly, such as calling them directly. In some
> + * cases, this requires some auxiliary tracking so subclass the
> tasklet_struct
> + * so that we have a central place and helpers.
> + */
> +struct i915_tasklet {
> + struct tasklet_struct base;
> +};
> +
> +static inline void i915_tasklet_init(struct i915_tasklet *t,
> + void (*func)(unsigned long),
> + unsigned long data)
> +{
> + tasklet_init(&t->base, func, data);
> +}
> +
> +static inline bool i915_tasklet_is_scheduled(const struct i915_tasklet *t)
> +{
> + return test_bit(TASKLET_STATE_SCHED, &t->base.state);
> +}
> +
> +static inline bool i915_tasklet_is_locked(const struct i915_tasklet *t)
why not is_running() ?
> +{
> + return test_bit(TASKLET_STATE_RUN, &t->base.state);
> +}
> +
> +static inline bool i915_tasklet_is_enabled(const struct i915_tasklet *t)
> +{
> + return likely(!atomic_read(&t->base.count));
I am concerned that we bury the sign of racy nature out of sight and
then it comes and bites us.
-Mika
> +}
> +
> +static inline void i915_tasklet_schedule(struct i915_tasklet *t)
> +{
> + tasklet_hi_schedule(&t->base);
> +}
> +
> +static inline void i915_tasklet_flush(struct i915_tasklet *t)
> +{
> + tasklet_kill(&t->base);
> +}
> +
> +static inline void i915_tasklet_enable(struct i915_tasklet *t)
> +{
> + tasklet_enable(&t->base);
> +}
> +
> +static inline void i915_tasklet_disable(struct i915_tasklet *t)
> +{
> + tasklet_disable(&t->base);
> +}
> +
> +static inline void i915_tasklet_set_func(struct i915_tasklet *t,
> + void (*func)(unsigned long data),
> + unsigned long data)
> +{
> + tasklet_disable(&t->base);
What does the disable/enable pair buy us here?
It looks that you want trylock and unlock
so that you can safely cha
Re: [Intel-gfx] [PATCH v3 16/40] misc/mei/hdcp: Verify M_prime
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:27 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [PATCH v3 16/40] misc/mei/hdcp: Verify M_prime
>
>Request to ME to verify the M_Prime received from the HDCP sink.
>
>ME FW will calculate the M and compare with M_prime received as part of
>RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.
>
>On successful completion of this stage, downstream propagation of the stream
>management info is completed.
>
>v2:
> Rebased.
>v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
>
>Signed-off-by: Ramalingam C
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 79
>
> include/linux/mei_hdcp.h | 8
> 2 files changed, 87 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 64fcecfa5b10..68eb5267a8e7 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -553,6 +553,85 @@ mei_repeater_check_flow_prepare_ack(struct
>mei_cl_device *cldev, }
>EXPORT_SYMBOL(mei_repeater_check_flow_prepare_ack);
>
>+static inline void reverse_endianness(u8 *dest, size_t dst_sz, u8 *src)
Function with loop ideally should not be inline.
>+{
>+ u32 index;
>+
>+ if (dest != NULL && dst_sz != 0) {
Good to check for src as well. Also this function will not do anything if these
check fails with caller not even been aware of the failure. Atleast return an
error or make sure no parameter validation happens here and its done by calling
function.
>+ for (index = 0; index < dst_sz && index < sizeof(u32);
>+ index++) {
>+ dest[dst_sz - index - 1] = src[index];
>+ }
>+ }
>+}
>+
>+/**
>+ * mei_verify_mprime:
>+ *Function to verify mprime.
>+ *
>+ * @cldev : Pointer for mei client device
>+ * @data : Intel HW specific Data
>+ * @stream_ready : pointer for RepeaterAuth_Stream_Ready message.
>+ *
>+ * Returns 0 on Success, <0 on Failure
>+ */
>+int mei_verify_mprime(struct mei_cl_device *cldev, struct mei_hdcp_data
>*data,
>+struct hdcp2_rep_stream_ready *stream_ready) {
>+ struct wired_cmd_repeater_auth_stream_req_in
>+ verify_mprime_in = { { 0 } };
>+ struct wired_cmd_repeater_auth_stream_req_out
>+ verify_mprime_out = { { 0 } };
>+ struct device *dev;
>+ ssize_t byte;
>+
>+ if (!stream_ready || !data)
>+ return -EINVAL;
>+
>+ dev = &cldev->dev;
>+
>+ verify_mprime_in.header.api_version = HDCP_API_VERSION;
>+ verify_mprime_in.header.command_id =
>WIRED_REPEATER_AUTH_STREAM_REQ;
>+ verify_mprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+ verify_mprime_in.header.buffer_len =
>+
> WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
>+
>+ verify_mprime_in.port.integrated_port_type = data->port_type;
>+ verify_mprime_in.port.physical_port = data->port;
>+
>+ memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
Validate stream_ready->m_prime.
>+ HDCP_2_2_MPRIME_LEN);
>+ reverse_endianness((u8 *)&verify_mprime_in.seq_num_m,
>+ HDCP_2_2_SEQ_NUM_LEN, (u8 *)&data-
>>seq_num_m);
>+ memcpy(verify_mprime_in.streams, data->streams,
Validate data->streams.
>+ (data->k * sizeof(struct hdcp2_streamid_type)));
>+
>+ verify_mprime_in.k = __swab16(data->k);
>+
>+ byte = mei_cldev_send(cldev, (u8 *)&verify_mprime_in,
>+sizeof(verify_mprime_in));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ byte = mei_cldev_recv(cldev, (u8 *)&verify_mprime_out,
>+sizeof(verify_mprime_out));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ if (verify_mprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+ dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
>+ WIRED_REPEATER_AUTH_STREAM_REQ,
>+ verify_mprime_out.header.status);
>+ return -1;
>+ }
Leave a blank line here.
>+ return 0;
>+}
>+EXPORT_SYMBOL(mei_verify_mprime);
>+
> void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled) {
> if (enabled)
>diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
>46e2dc295d03..dbc216e13f97 100644
>--- a/include/linux/mei_hdcp.h
>+++
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Wrap tasklet_struct for abuse
Quoting Mika Kuoppala (2018-05-09 14:44:30)
> Chris Wilson writes:
>
> > In the next few patches, we want to abuse tasklet to avoid ksoftirqd
> > latency along critical paths. To make that abuse easily to swallow,
> > first coat the tasklet in a little syntactic sugar.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 8 +--
> > drivers/gpu/drm/i915/i915_irq.c | 2 +-
> > drivers/gpu/drm/i915/i915_tasklet.h | 78 +
> > drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++-
> > drivers/gpu/drm/i915/intel_guc_submission.c | 8 +--
> > drivers/gpu/drm/i915/intel_lrc.c| 18 ++---
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +-
> > 7 files changed, 104 insertions(+), 24 deletions(-)
> > create mode 100644 drivers/gpu/drm/i915/i915_tasklet.h
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 89bf5d67cb74..98481e150e61 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3043,9 +3043,9 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
> > *engine)
> >* common case of recursively being called from set-wedged from inside
> >* i915_reset.
> >*/
> > - if (!atomic_read(&engine->execlists.tasklet.count))
> > - tasklet_kill(&engine->execlists.tasklet);
> > - tasklet_disable(&engine->execlists.tasklet);
> > + if (i915_tasklet_is_enabled(&engine->execlists.tasklet))
> > + i915_tasklet_flush(&engine->execlists.tasklet);
> > + i915_tasklet_disable(&engine->execlists.tasklet);
> >
> > /*
> >* We're using worker to queue preemption requests from the tasklet in
> > @@ -3265,7 +3265,7 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
> >
> > void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
> > {
> > - tasklet_enable(&engine->execlists.tasklet);
> > + i915_tasklet_enable(&engine->execlists.tasklet);
> > kthread_unpark(engine->breadcrumbs.signaler);
> >
> > intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index f9bc3aaa90d0..f8aff5a5aa83 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1477,7 +1477,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine,
> > u32 iir)
> > }
> >
> > if (tasklet)
> > - tasklet_hi_schedule(&execlists->tasklet);
> > + i915_tasklet_schedule(&execlists->tasklet);
> > }
> >
> > static void gen8_gt_irq_ack(struct drm_i915_private *i915,
> > diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
> > b/drivers/gpu/drm/i915/i915_tasklet.h
> > new file mode 100644
> > index ..c9f41a5ebb91
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/i915_tasklet.h
> > @@ -0,0 +1,78 @@
> > +/*
> > + * SPDX-License-Identifier: GPL-2.0
> > + *
> > + * Copyright © 2018 Intel Corporation
> > + */
> > +
> > +#ifndef _I915_TASKLET_H_
> > +#define _I915_TASKLET_H_
> > +
> > +#include
> > +#include
> > +
> > +/**
> > + * struct i915_tasklet - wrapper around tasklet_struct
> > + *
> > + * We want to abuse tasklets slightly, such as calling them directly. In
> > some
> > + * cases, this requires some auxiliary tracking so subclass the
> > tasklet_struct
> > + * so that we have a central place and helpers.
> > + */
> > +struct i915_tasklet {
> > + struct tasklet_struct base;
> > +};
> > +
> > +static inline void i915_tasklet_init(struct i915_tasklet *t,
> > + void (*func)(unsigned long),
> > + unsigned long data)
> > +{
> > + tasklet_init(&t->base, func, data);
> > +}
> > +
> > +static inline bool i915_tasklet_is_scheduled(const struct i915_tasklet *t)
> > +{
> > + return test_bit(TASKLET_STATE_SCHED, &t->base.state);
> > +}
> > +
> > +static inline bool i915_tasklet_is_locked(const struct i915_tasklet *t)
>
> why not is_running() ?
Because I didn't want to resend the series immediately. It's confusing
because it's set by tasklet_trylock and cleared by tasklet_unlock.
> > + return test_bit(TASKLET_STATE_RUN, &t->base.state);
> > +}
> > +
> > +static inline bool i915_tasklet_is_enabled(const struct i915_tasklet *t)
> > +{
> > + return likely(!atomic_read(&t->base.count));
>
> I am concerned that we bury the sign of racy nature out of sight and
> then it comes and bites us.
Oh, I wouldn't worry about that, just wait until you see what comes
later :-p
> > +static inline void i915_tasklet_set_func(struct i915_tasklet *t,
> > + void (*func)(unsigned long data),
> > + unsigned long data)
> > +{
> > + tasklet_disable(&t->base);
>
> What does the disable/enable pair buy us here?
>
I was thinking about being
[Intel-gfx] [PATCH v4 0/2] GMBUS changes
I am not aware if there is a reason for restricting the Bytes per GMBUS WR/RD to 256 at present. But HW has 9Bits for Total Byte count for a single read or Write cycle. Means we can extend a cycle of RD/WR to 511Bytes. At present nothing much as ROI, as most of the usecases are for less than 256Bytes. On GLK tested for 300Bytes on single normal read, found to be working fine. First patch does it. But I have restricted the extension to Gen9 onwards, as I am not sure about the legacy platforms. And second patch is enabling the burst read for all GMBUS read of more than 511Bytes, on supported platforms. Basically this Burst read is enabled in HW for HDCP2.2 compliance requirement. Instead of enabling the burst read only for HDCP on special API this patch enables it for all GMBUS read of >511Bytes, on capable platforms. Changes in V4: --Extra variable and brackets are removed. [ville] --Implemented the handling of the 512Bytes Burst read. [ville] --GMBUS0 values are passed as parameters. [ville] Ramalingam C (2): drm/i915/gmbus: Increase the Bytes per Rd/Wr Op drm/i915/gmbus: Enable burst read drivers/gpu/drm/i915/i915_drv.h | 3 ++ drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_i2c.c | 61 3 files changed, 55 insertions(+), 11 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/2] drm/i915/gmbus: Enable burst read
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
v2:
Extra line is removed.
v3:
Macro is added for detecting the BURST_READ Support [Jani]
Runtime detection of the need for burst_read [Jani]
Calculation enhancement.
v4:
GMBUS0 reg val is passed from caller [ville]
Removed a extra var [ville]
Extra brackets are removed [ville]
Implemented the handling of 512Bytes Burst Read.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_i2c.c | 52
3 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 028691108125..14293fc1a142 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2552,6 +2552,9 @@ intel_info(const struct drm_i915_private *dev_priv)
*/
#define HAS_AUX_IRQ(dev_priv) true
#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
+#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
+ IS_GEMINILAKE(dev_priv) || \
+ IS_KABYLAKE(dev_priv))
/* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
* rows, which changed the alignment requirements and fence programming.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index df998c10c48e..1166a24aff48 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2996,6 +2996,7 @@ enum i915_power_well_id {
#define GMBUS_RATE_400KHZ(2<<8) /* reserved on Pineview */
#define GMBUS_RATE_1MHZ (3<<8) /* reserved on Pineview */
#define GMBUS_HOLD_EXT (1<<7) /* 300ns hold time, rsvd on Pineview */
+#define GMBUS_BYTE_CNT_OVERRIDE (1<<6)
#define GMBUS_PIN_DISABLED 0
#define GMBUS_PIN_SSC1
#define GMBUS_PIN_VGADDC 2
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 1c0f6b56b209..2b59f8db42f2 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -371,12 +371,30 @@ unsigned int gmbus_max_xfer_size(struct drm_i915_private
*dev_priv)
static int
gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
unsigned short addr, u8 *buf, unsigned int len,
- u32 gmbus1_index)
+ u32 gmbus0_reg, u32 gmbus1_index)
{
+ unsigned int size = len;
+ bool burst_read = len > gmbus_max_xfer_size(dev_priv);
+ bool extra_byte_added = false;
+
+ if (burst_read) {
+
+ /*
+* As per HW Spec, for 512Bytes need to read extra Byte and
+* Ignore the extra byte read.
+*/
+ if (len == 512) {
+ extra_byte_added = true;
+ len++;
+ }
+ size = len % 256 + 256;
+ I915_WRITE_FW(GMBUS0, gmbus0_reg | GMBUS_BYTE_CNT_OVERRIDE);
+ }
+
I915_WRITE_FW(GMBUS1,
gmbus1_index |
GMBUS_CYCLE_WAIT |
- (len << GMBUS_BYTE_COUNT_SHIFT) |
+ (size << GMBUS_BYTE_COUNT_SHIFT) |
(addr << GMBUS_SLAVE_ADDR_SHIFT) |
GMBUS_SLAVE_READ | GMBUS_SW_RDY);
while (len) {
@@ -389,9 +407,16 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
val = I915_READ_FW(GMBUS3);
do {
+ if (extra_byte_added && len == 1)
+ break;
+
*buf++ = val & 0xff;
val >>= 8;
} while (--len && ++loop < 4);
+
+ if (burst_read && len == size - 4)
+ /* Reset the override bit */
+ I915_WRITE_FW(GMBUS0, gmbus0_reg);
}
return 0;
@@ -399,7 +424,7 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
static int
gmbus_xfer_read(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
- u32 gmbus1_index)
+ u32 gmbus0_reg, u32 gmbus1_index)
{
u8 *buf = msg->buf;
unsigned int rx_size = msg->len;
@@ -407,10 +432,13 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct
i2c_msg *msg,
int ret;
do {
- len = min(rx_size, gmbus_max_xfer_size(dev_priv));
+ if (HAS_GMBUS_BURST_READ(dev_priv))
+ len = rx_size;
+ else
+ len = min(rx_size, gmbus_max_xfer_size(dev_priv));
- ret = gmbus_xfer_read_chunk(dev_priv, msg->addr,
- buf, len, gmbus1_index);
+
[Intel-gfx] [PATCH v4 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
GMBUS HW supports 511Bytes as Max Bytes per single RD/WR op. Instead of
enabling the 511Bytes per RD/WR cycle on legacy platforms for no
absolute ROIs, this change allows the max bytes per op upto 511Bytes
from Gen9 onwards.
v2:
No Change.
v3:
Inline function for max_xfer_size and renaming of the macro.[Jani]
v4:
Extra brackets removed [ville]
Commit msg is modified.
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_i2c.c | 11 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c08fd4ded688..df998c10c48e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3025,6 +3025,7 @@ enum i915_power_well_id {
#define GMBUS_CYCLE_STOP (4<<25)
#define GMBUS_BYTE_COUNT_SHIFT 16
#define GMBUS_BYTE_COUNT_MAX 256U
+#define GEN9_GMBUS_BYTE_COUNT_MAX 511U
#define GMBUS_SLAVE_INDEX_SHIFT 8
#define GMBUS_SLAVE_ADDR_SHIFT 1
#define GMBUS_SLAVE_READ (1<<0)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index e6875509bcd9..1c0f6b56b209 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -361,6 +361,13 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv)
return ret;
}
+static inline
+unsigned int gmbus_max_xfer_size(struct drm_i915_private *dev_priv)
+{
+ return INTEL_GEN(dev_priv) >= 9 ? GEN9_GMBUS_BYTE_COUNT_MAX :
+ GMBUS_BYTE_COUNT_MAX;
+}
+
static int
gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
unsigned short addr, u8 *buf, unsigned int len,
@@ -400,7 +407,7 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct
i2c_msg *msg,
int ret;
do {
- len = min(rx_size, GMBUS_BYTE_COUNT_MAX);
+ len = min(rx_size, gmbus_max_xfer_size(dev_priv));
ret = gmbus_xfer_read_chunk(dev_priv, msg->addr,
buf, len, gmbus1_index);
@@ -462,7 +469,7 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct
i2c_msg *msg,
int ret;
do {
- len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
+ len = min(tx_size, gmbus_max_xfer_size(dev_priv));
ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
gmbus1_index);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/5] drm/i915: Combine tasklet_kill and tasklet_disable
Chris Wilson writes:
> Ideally, we want to atomically flush and disable the tasklet before
> resetting the GPU. At present, we rely on being the only part to touch
> our tasklet and serialisation of the reset process to ensure that we can
> suspend the tasklet from the mix of reset/wedge pathways. In this patch,
> we move the tasklet abuse into its own function and tweak it such that
> we only do a synchronous operation the first time it is disabled around
> the reset. This allows us to avoid the sync inside a softirq context in
> subsequent patches.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
> Cc: Michał Winiarski
> CC: Michel Thierry
> Cc: Jeff McGee
> ---
> drivers/gpu/drm/i915/i915_gem.c| 2 --
> drivers/gpu/drm/i915/i915_tasklet.h| 14 ++
> drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 98481e150e61..8d27e78b052c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3043,8 +3043,6 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
> *engine)
>* common case of recursively being called from set-wedged from inside
>* i915_reset.
>*/
> - if (i915_tasklet_is_enabled(&engine->execlists.tasklet))
> - i915_tasklet_flush(&engine->execlists.tasklet);
> i915_tasklet_disable(&engine->execlists.tasklet);
>
> /*
> diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
> b/drivers/gpu/drm/i915/i915_tasklet.h
> index c9f41a5ebb91..d8263892f385 100644
> --- a/drivers/gpu/drm/i915/i915_tasklet.h
> +++ b/drivers/gpu/drm/i915/i915_tasklet.h
> @@ -59,10 +59,24 @@ static inline void i915_tasklet_enable(struct
> i915_tasklet *t)
> }
>
> static inline void i915_tasklet_disable(struct i915_tasklet *t)
> +{
> + if (i915_tasklet_is_enabled(t))
> + i915_tasklet_flush(t);
This needs a comment to explain how we can get away with
the race.
> +
> + if (atomic_inc_return(&t->base.count) == 1)
> + tasklet_unlock_wait(&t->base);
I would add comment in here too.
/* No need to sync on further disables */
-Mika
> +}
> +
> +static inline void i915_tasklet_lock(struct i915_tasklet *t)
> {
> tasklet_disable(&t->base);
> }
>
> +static inline void i915_tasklet_unlock(struct i915_tasklet *t)
> +{
> + tasklet_enable(&t->base);
> +}
> +
> static inline void i915_tasklet_set_func(struct i915_tasklet *t,
>void (*func)(unsigned long data),
>unsigned long data)
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 5f1118ea96d8..3c8a0c3245f3 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1478,7 +1478,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
> *engine)
> if (!intel_engine_supports_stats(engine))
> return -ENODEV;
>
> - i915_tasklet_disable(&execlists->tasklet);
> + i915_tasklet_lock(&execlists->tasklet);
After the initial shock, the *lock starts to fit.
-Mika
> write_seqlock_irqsave(&engine->stats.lock, flags);
>
> if (unlikely(engine->stats.enabled == ~0)) {
> @@ -1504,7 +1504,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
> *engine)
>
> unlock:
> write_sequnlock_irqrestore(&engine->stats.lock, flags);
> - i915_tasklet_enable(&execlists->tasklet);
> + i915_tasklet_unlock(&execlists->tasklet);
>
> return err;
> }
> --
> 2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 17/40] misc/mei/hdcp: Enabling the HDCP authentication
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [PATCH v3 17/40] misc/mei/hdcp: Enabling the HDCP authentication
>
>Request to ME to configure a port as authenticated.
>
>On Success, ME FW will mark th eport as authenticated and provides HDCP chipper
Rectify "the". Also it should be HDCP cipher.
>of the port with the encryption keys.
>
>Enabling the Authentication can be requested once the all stages of HDCP2.2
>authentication is completed by interating with ME FW.
Typo in interacting.
>
>Only after this stage, driver can enable the HDCP encryption for the port,
>through
>HW registers.
>
>v2:
> Rebased.
>v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
>
>Signed-off-by: Ramalingam C
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 54
>
> include/linux/mei_hdcp.h | 7 ++
> 2 files changed, 61 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 68eb5267a8e7..b5d1da41f1d9 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -632,6 +632,60 @@ int mei_verify_mprime(struct mei_cl_device *cldev,
>struct mei_hdcp_data *data, } EXPORT_SYMBOL(mei_verify_mprime);
>
>+/**
>+ * mei_enable_hdcp_authentication:
>+ *Function to request ME FW to mark a port as authenticated.
>+ *
>+ * @cldev : Pointer for mei client device
>+ * @data : Intel HW specific Data
>+ *
>+ * Returns 0 on Success, <0 on Failure
>+ */
>+int mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data)
>+{
>+ struct wired_cmd_enable_auth_in enable_auth_in = { { 0 } };
>+ struct wired_cmd_enable_auth_out enable_auth_out = { { 0 } };
>+ struct device *dev;
>+ ssize_t byte;
>+
>+ if (!data)
>+ return -EINVAL;
>+
>+ dev = &cldev->dev;
>+
>+ enable_auth_in.header.api_version = HDCP_API_VERSION;
>+ enable_auth_in.header.command_id = WIRED_ENABLE_AUTH;
>+ enable_auth_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+ enable_auth_in.header.buffer_len =
>WIRED_CMD_BUF_LEN_ENABLE_AUTH_IN;
>+
>+ enable_auth_in.port.integrated_port_type = data->port_type;
>+ enable_auth_in.port.physical_port = data->port;
>+ enable_auth_in.stream_type = data->streams[0].stream_type;
Check for data->streams.
>+
>+ byte = mei_cldev_send(cldev, (u8 *)&enable_auth_in,
>+sizeof(enable_auth_in));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ byte = mei_cldev_recv(cldev, (u8 *)&enable_auth_out,
>+sizeof(enable_auth_out));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ if (enable_auth_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+ dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
>+ WIRED_ENABLE_AUTH,
>enable_auth_out.header.status);
>+ return -1;
>+ }
Leave a blank line here.
>+ return 0;
>+}
>+EXPORT_SYMBOL(mei_enable_hdcp_authentication);
>+
> void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled) {
> if (enabled)
>diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
>dbc216e13f97..2366d0741abe 100644
>--- a/include/linux/mei_hdcp.h
>+++ b/include/linux/mei_hdcp.h
>@@ -136,6 +136,8 @@ mei_repeater_check_flow_prepare_ack(struct
>mei_cl_device *cldev,
> struct hdcp2_rep_send_ack *rep_send_ack);
>int mei_verify_mprime(struct mei_cl_device *cldev, struct mei_hdcp_data *data,
> struct hdcp2_rep_stream_ready *stream_ready);
>+int mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data);
> #else
> static int mei_cldev_register_notify(struct notifier_block *nb) { @@ -209,5
>+211,10 @@ int mei_verify_mprime(struct mei_cl_device *cldev, struct
>mei_hdcp_data *data, {
> return -ENODEV;
> }
>+static inline int mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data)
>+{
>+ return -ENODEV;
>+}
> #endif /* defined (CONFIG_INTEL_MEI_HDCP) */ #endif /* defined
>(_LINUX_MEI_HDCP_H) */
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freed
Re: [Intel-gfx] [PATCH] drm/i915/psr: Check if VBT says PSR can be enabled.
On Wed, May 09, 2018 at 05:29:14AM -0700, Rodrigo Vivi wrote:
> On Tue, May 08, 2018 at 05:35:24PM -0700, Dhinakaran Pandiyan wrote:
> > Driver features data block has a boolean flag for PSR, use this to decide
> > whether PSR should be enabled on a platform. The module parameter can
> > still be used to override this.
> >
> > Note: The feature currently remains disabled by default for all platforms
> > irrespective of what VBT says.
> >
> > Cc: Rodrigo Vivi
> > Signed-off-by: Dhinakaran Pandiyan
>
> Reviewed-by: Rodrigo Vivi
pushed to dinq. Thanks for the patch.
>
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_bios.c | 1 +
> > drivers/gpu/drm/i915/intel_psr.c | 7 +--
> > 3 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 04e27806e581..24c5e4765afd 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1073,6 +1073,7 @@ struct intel_vbt_data {
> > } edp;
> >
> > struct {
> > + bool enable;
> > bool full_link;
> > bool require_aux_wakeup;
> > int idle_frames;
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 702d3fab97fc..54270bdde100 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -530,6 +530,7 @@ parse_driver_features(struct drm_i915_private *dev_priv,
> > */
> > if (!driver->drrs_enabled)
> > dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
> > + dev_priv->vbt.psr.enable = driver->psr_enabled;
> > }
> >
> > static void
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 6233a322aac5..db27f2faa1de 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -1173,9 +1173,12 @@ void intel_psr_init(struct drm_i915_private
> > *dev_priv)
> > if (!dev_priv->psr.sink_support)
> > return;
> >
> > - /* Per platform default: all disabled. */
> > - if (i915_modparams.enable_psr == -1)
> > + if (i915_modparams.enable_psr == -1) {
> > + i915_modparams.enable_psr = dev_priv->vbt.psr.enable;
> > +
> > + /* Per platform default: all disabled. */
> > i915_modparams.enable_psr = 0;
> > + }
> >
> > /* Set link_standby x link_off defaults */
> > if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> > --
> > 2.14.1
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 18/40] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 18/40] misc/mei/hdcp: Closing wired HDCP2.2 Tx
>Session
>
>Request the ME to terminate the HDCP2.2 session for a port.
>
>On Success, ME FW will mark the intel port as Deauthenticated and terminate the
>wired HDCP2.2 Tx session started due to the cmd
>WIRED_INITIATE_HDCP2_SESSION.
>
>v2:
> Rebased.
>v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
>
>Signed-off-by: Ramalingam C
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 55
>
> include/linux/mei_hdcp.h | 7 +
> 2 files changed, 62 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index b5d1da41f1d9..ed402f1f2f64 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -686,6 +686,61 @@ int mei_enable_hdcp_authentication(struct
>mei_cl_device *cldev, } EXPORT_SYMBOL(mei_enable_hdcp_authentication);
>
>+/**
>+ * me_close_hdcp_session:
Typo in me. Should be mei.
>+ *Function to close the Wired HDCP Tx session of ME FW.
>+ *This also disables the authenticated state of the port.
>+ *
>+ * @data : Intel HW specific Data
>+ *
>+ * Returns 0 on Success, <0 on Failure
>+ */
>+int mei_close_hdcp_session(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data)
>+{
>+ struct wired_cmd_close_session_in session_close_in = { { 0 } };
>+ struct wired_cmd_close_session_out session_close_out = { { 0 } };
>+ struct device *dev;
>+ ssize_t byte;
>+
>+ if (!data)
>+ return -EINVAL;
>+
>+ dev = &cldev->dev;
>+
>+ session_close_in.header.api_version = HDCP_API_VERSION;
>+ session_close_in.header.command_id = WIRED_CLOSE_SESSION;
>+ session_close_in.header.status = ME_HDCP_STATUS_SUCCESS;
>+ session_close_in.header.buffer_len =
>+ WIRED_CMD_BUF_LEN_CLOSE_SESSION_IN;
>+
>+ session_close_in.port.integrated_port_type = data->port_type;
>+ session_close_in.port.physical_port = data->port;
>+
>+
>+ byte = mei_cldev_send(cldev, (u8 *)&session_close_in,
>+sizeof(session_close_in));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_send failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ byte = mei_cldev_recv(cldev, (u8 *)&session_close_out,
>+sizeof(session_close_out));
>+ if (byte < 0) {
>+ dev_dbg(dev, "mei_cldev_recv failed. %d\n", (int)byte);
>+ return byte;
>+ }
>+
>+ if (session_close_out.header.status != ME_HDCP_STATUS_SUCCESS) {
>+ dev_dbg(dev, "Session Close Failed. status: 0x%X\n",
>+ session_close_out.header.status);
>+ return -1;
>+ }
>+ return 0;
>+}
>+EXPORT_SYMBOL(mei_close_hdcp_session);
>+
> void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool
> enabled) {
> if (enabled)
>diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h index
>2366d0741abe..55cbde890571 100644
>--- a/include/linux/mei_hdcp.h
>+++ b/include/linux/mei_hdcp.h
>@@ -138,6 +138,8 @@ int mei_verify_mprime(struct mei_cl_device *cldev,
>struct mei_hdcp_data *data,
> struct hdcp2_rep_stream_ready *stream_ready); int
>mei_enable_hdcp_authentication(struct mei_cl_device *cldev,
> struct mei_hdcp_data *data);
>+int mei_close_hdcp_session(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data);
> #else
> static int mei_cldev_register_notify(struct notifier_block *nb) { @@ -216,5
>+218,10 @@ static inline int mei_enable_hdcp_authentication(struct
>mei_cl_device *cldev, {
> return -ENODEV;
> }
>+static inline int mei_close_hdcp_session(struct mei_cl_device *cldev,
>+ struct mei_hdcp_data *data)
>+{
>+ return -ENODEV;
>+}
> #endif /* defined (CONFIG_INTEL_MEI_HDCP) */ #endif /* defined
>(_LINUX_MEI_HDCP_H) */
>--
>2.7.4
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/5] drm/i915: Combine tasklet_kill and tasklet_disable
Quoting Mika Kuoppala (2018-05-09 14:54:04)
> Chris Wilson writes:
>
> > Ideally, we want to atomically flush and disable the tasklet before
> > resetting the GPU. At present, we rely on being the only part to touch
> > our tasklet and serialisation of the reset process to ensure that we can
> > suspend the tasklet from the mix of reset/wedge pathways. In this patch,
> > we move the tasklet abuse into its own function and tweak it such that
> > we only do a synchronous operation the first time it is disabled around
> > the reset. This allows us to avoid the sync inside a softirq context in
> > subsequent patches.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: Mika Kuoppala
> > Cc: Michał Winiarski
> > CC: Michel Thierry
> > Cc: Jeff McGee
> > ---
> > drivers/gpu/drm/i915/i915_gem.c| 2 --
> > drivers/gpu/drm/i915/i915_tasklet.h| 14 ++
> > drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
> > 3 files changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 98481e150e61..8d27e78b052c 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3043,8 +3043,6 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
> > *engine)
> >* common case of recursively being called from set-wedged from inside
> >* i915_reset.
> >*/
> > - if (i915_tasklet_is_enabled(&engine->execlists.tasklet))
> > - i915_tasklet_flush(&engine->execlists.tasklet);
> > i915_tasklet_disable(&engine->execlists.tasklet);
> >
> > /*
> > diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
> > b/drivers/gpu/drm/i915/i915_tasklet.h
> > index c9f41a5ebb91..d8263892f385 100644
> > --- a/drivers/gpu/drm/i915/i915_tasklet.h
> > +++ b/drivers/gpu/drm/i915/i915_tasklet.h
> > @@ -59,10 +59,24 @@ static inline void i915_tasklet_enable(struct
> > i915_tasklet *t)
> > }
> >
> > static inline void i915_tasklet_disable(struct i915_tasklet *t)
> > +{
> > + if (i915_tasklet_is_enabled(t))
> > + i915_tasklet_flush(t);
>
> This needs a comment to explain how we can get away with
> the race.
It doesn't, we rely on exclusivity that is provided by it is only us
that controls the tasklet. The rationale comes from the caller. That we
call flush here at all, is just that it helps avoid spinning, it is not
required. If the race is too much, we just need the next line.
> > + if (atomic_inc_return(&t->base.count) == 1)
> > + tasklet_unlock_wait(&t->base);
>
> I would add comment in here too.
> /* No need to sync on further disables */
Doesn't help much, that literally is what the code is doing but not why.
Why we want that is the caller again.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/5] drm/i915: Combine tasklet_kill and tasklet_disable
Quoting Chris Wilson (2018-05-09 15:02:12)
> Quoting Mika Kuoppala (2018-05-09 14:54:04)
> > Chris Wilson writes:
> >
> > > Ideally, we want to atomically flush and disable the tasklet before
> > > resetting the GPU. At present, we rely on being the only part to touch
> > > our tasklet and serialisation of the reset process to ensure that we can
> > > suspend the tasklet from the mix of reset/wedge pathways. In this patch,
> > > we move the tasklet abuse into its own function and tweak it such that
> > > we only do a synchronous operation the first time it is disabled around
> > > the reset. This allows us to avoid the sync inside a softirq context in
> > > subsequent patches.
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Tvrtko Ursulin
> > > Cc: Mika Kuoppala
> > > Cc: Michał Winiarski
> > > CC: Michel Thierry
> > > Cc: Jeff McGee
> > > ---
> > > drivers/gpu/drm/i915/i915_gem.c| 2 --
> > > drivers/gpu/drm/i915/i915_tasklet.h| 14 ++
> > > drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
> > > 3 files changed, 16 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 98481e150e61..8d27e78b052c 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -3043,8 +3043,6 @@ i915_gem_reset_prepare_engine(struct
> > > intel_engine_cs *engine)
> > >* common case of recursively being called from set-wedged from
> > > inside
> > >* i915_reset.
> > >*/
> > > - if (i915_tasklet_is_enabled(&engine->execlists.tasklet))
> > > - i915_tasklet_flush(&engine->execlists.tasklet);
> > > i915_tasklet_disable(&engine->execlists.tasklet);
> > >
> > > /*
> > > diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
> > > b/drivers/gpu/drm/i915/i915_tasklet.h
> > > index c9f41a5ebb91..d8263892f385 100644
> > > --- a/drivers/gpu/drm/i915/i915_tasklet.h
> > > +++ b/drivers/gpu/drm/i915/i915_tasklet.h
> > > @@ -59,10 +59,24 @@ static inline void i915_tasklet_enable(struct
> > > i915_tasklet *t)
> > > }
> > >
> > > static inline void i915_tasklet_disable(struct i915_tasklet *t)
> > > +{
> > > + if (i915_tasklet_is_enabled(t))
> > > + i915_tasklet_flush(t);
> >
> > This needs a comment to explain how we can get away with
> > the race.
>
> It doesn't, we rely on exclusivity that is provided by it is only us
> that controls the tasklet. The rationale comes from the caller. That we
> call flush here at all, is just that it helps avoid spinning, it is not
> required. If the race is too much, we just need the next line.
Rather than ever worry, let's just kill it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 19/40] drm/i915: wrapping all hdcp var into intel_hdcp
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [PATCH v3 19/40] drm/i915: wrapping all hdcp var into intel_hdcp
>
>Considering the upcoming significant no HDCP2.2 variables, it will be clean to
Rephrase this sentence.
>have separate struct fo HDCP.
Typo here.
>
>New structure called intel_hdcp is introduced.
>
>v2:
> struct hdcp statically allocated. [Sean Paul]
> enable and disable function parameters are retained.[Sean Paul]
>v3:
> No Changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_display.c | 7 +--
> drivers/gpu/drm/i915/intel_drv.h | 14 --
> drivers/gpu/drm/i915/intel_hdcp.c| 94
> 3 files changed, 66 insertions(+), 49 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_display.c
>b/drivers/gpu/drm/i915/intel_display.c
>index 331084082545..2d7c47135e1a 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -15395,9 +15395,10 @@ static void intel_hpd_poll_fini(struct drm_device
>*dev)
> for_each_intel_connector_iter(connector, &conn_iter) {
> if (connector->modeset_retry_work.func)
> cancel_work_sync(&connector->modeset_retry_work);
>- if (connector->hdcp_shim) {
>- cancel_delayed_work_sync(&connector-
>>hdcp_check_work);
>- cancel_work_sync(&connector->hdcp_prop_work);
>+ if (connector->hdcp.hdcp_shim) {
>+ cancel_delayed_work_sync(
>+ &connector->hdcp.hdcp_check_work);
>+ cancel_work_sync(&connector->hdcp.hdcp_prop_work);
> }
> }
> drm_connector_list_iter_end(&conn_iter);
>diff --git a/drivers/gpu/drm/i915/intel_drv.h
>b/drivers/gpu/drm/i915/intel_drv.h
>index d4368589b355..fdffcb833cd2 100644
>--- a/drivers/gpu/drm/i915/intel_drv.h
>+++ b/drivers/gpu/drm/i915/intel_drv.h
>@@ -377,6 +377,14 @@ struct intel_hdcp_shim {
> bool *hdcp_capable);
> };
>
>+struct intel_hdcp {
>+ const struct intel_hdcp_shim *hdcp_shim;
>+ struct mutex hdcp_mutex;
>+ uint64_t hdcp_value; /* protected by hdcp_mutex */
>+ struct delayed_work hdcp_check_work;
>+ struct work_struct hdcp_prop_work;
>+};
>+
> struct intel_connector {
> struct drm_connector base;
> /*
>@@ -409,11 +417,7 @@ struct intel_connector {
> /* Work struct to schedule a uevent on link train failure */
> struct work_struct modeset_retry_work;
>
>- const struct intel_hdcp_shim *hdcp_shim;
>- struct mutex hdcp_mutex;
>- uint64_t hdcp_value; /* protected by hdcp_mutex */
>- struct delayed_work hdcp_check_work;
>- struct work_struct hdcp_prop_work;
>+ struct intel_hdcp hdcp;
> };
>
> struct intel_digital_connector_state {
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 14ca5d3057a7..1cca4f349064 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -547,6 +547,7 @@ struct intel_digital_port *conn_to_dig_port(struct
>intel_connector *connector)
>
> static int _intel_hdcp_disable(struct intel_connector *connector) {
>+ struct intel_hdcp *hdcp = &connector->hdcp;
> struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
> struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> enum port port = intel_dig_port->base.port; @@ -562,7 +563,7 @@
>static int _intel_hdcp_disable(struct intel_connector *connector)
> return -ETIMEDOUT;
> }
>
>- ret = connector->hdcp_shim->toggle_signalling(intel_dig_port, false);
>+ ret = hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
> if (ret) {
> DRM_ERROR("Failed to disable HDCP signalling\n");
> return ret;
>@@ -574,6 +575,7 @@ static int _intel_hdcp_disable(struct intel_connector
>*connector)
>
> static int _intel_hdcp_enable(struct intel_connector *connector) {
>+ struct intel_hdcp *hdcp = &connector->hdcp;
> struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
> int i, ret, tries = 3;
>
>@@ -599,7 +601,7 @@ static int _intel_hdcp_enable(struct intel_connector
>*connector)
> /* Incase of authentication failures, HDCP spec expects reauth. */
> for (i = 0; i < tries; i++) {
> ret = intel_hdcp_auth(conn_to_dig_port(connector),
>-connector->hdcp_shim);
>+hdcp->hdcp_shim);
> if (!ret)
>
Re: [Intel-gfx] [PATCH v3 20/40] drm/i915: Define HDCP2.2 related variables
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [PATCH v3 20/40] drm/i915: Define HDCP2.2 related variables
>
>For upcoming implementation of HDCP2.2 in I915, important variable required for
>HDCP2.2 are defined.
>
>HDCP_shim is extended to support encoder specific HDCP2.2 flows.
>
>v2:
> 1.4 shim is extended to support hdcp2.2. [Sean Paul]
> platform's/panel's hdcp ver capability is removed. [Sean Paul]
> mei references in i915_private are moved to later patches. [Chris Wilson]
>v3:
> mei_cl_device ref is moved into intel_hdcp
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_drv.h | 61
>
> 1 file changed, 61 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_drv.h
>b/drivers/gpu/drm/i915/intel_drv.h
>index fdffcb833cd2..ca06d9a158f6 100644
>--- a/drivers/gpu/drm/i915/intel_drv.h
>+++ b/drivers/gpu/drm/i915/intel_drv.h
>@@ -29,6 +29,7 @@
> #include
> #include
> #include
>+#include
> #include
> #include "i915_drv.h"
> #include
>@@ -375,6 +376,32 @@ struct intel_hdcp_shim {
> /* Detects panel's hdcp capability. This is optional for HDMI. */
> int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
> bool *hdcp_capable);
>+
>+ /* Write HDCP2.2 messages */
>+ int (*write_2_2_msg)(struct intel_digital_port *intel_dig_port,
>+ void *buf, size_t size);
>+
>+ /* Read HDCP2.2 messages */
>+ int (*read_2_2_msg)(struct intel_digital_port *intel_dig_port,
>+ uint8_t msg_id, void *buf, size_t size);
>+
>+ /*
>+ * Implementation of DP HDCP2.2 Errata for the communication of
>stream
>+ * type to Receivers. In DP HDCP2.2 Stream type is one of the input to
>+ * the HDCP2.2 Chiper for En/De-Cryption. Not applicable for HDMI.
>+ */
>+ int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
>+void *buf, size_t size);
>+
>+ /* HDCP2.2 Link Integrity Check */
>+ int (*check_2_2_link)(struct intel_digital_port *intel_dig_port);
>+
>+ /* Detects whether Panel is HDCP2.2 capable */
>+ int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
>+ bool *capable);
>+
>+ /* Detects the HDCP protocol(DP/HDMI) required on the port */
>+ enum hdcp_protocol (*hdcp_protocol)(void);
> };
>
> struct intel_hdcp {
>@@ -383,6 +410,40 @@ struct intel_hdcp {
> uint64_t hdcp_value; /* protected by hdcp_mutex */
> struct delayed_work hdcp_check_work;
> struct work_struct hdcp_prop_work;
>+
>+ /** HDCP2.2 related definitions **/
Drop extra *.
>+ bool hdcp2_supported;
>+
>+ /*
>+ * Content Stream Type defined by content owner. TYPE0(0x0) content
>can
>+ * flow in the link protected by HDCP2.2 or HDCP1.4, where as
>TYPE1(0x1)
>+ * content can flow only through a link protected by HDCP2.2.
>+ */
>+ u8 content_type;
>+
>+ bool is_paired;
>+ bool is_repeater;
>+
>+ /*
>+ * Count of ReceiverID_List received. Initialized to 0 at AKE_INIT.
>+ * Incremented after processing the RepeaterAuth_Send_ReceiverID_List.
>+ * When it rolls over re-auth has to be triggered.
>+ */
>+ uint32_t seq_num_v;
>+
>+ /*
>+ * Count of RepeaterAuth_Stream_Manage msg propagated.
>+ * Initialized to 0 on AKE_INIT. Incremented after every successful
>+ * transmission of RepeaterAuth_Stream_Manage message. When it rolls
>+ * over re-Auth has to be triggered.
>+ */
>+ uint32_t seq_num_m;
>+
>+ /* mei interface related information */
>+ struct mei_cl_device *cldev;
>+ struct mei_hdcp_data mei_data;
>+
>+ struct delayed_work hdcp2_check_work;
> };
>
> struct intel_connector {
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v3,1/5] drm/i915: Wrap tasklet_struct for abuse
== Series Details == Series: series starting with [v3,1/5] drm/i915: Wrap tasklet_struct for abuse URL : https://patchwork.freedesktop.org/series/42942/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4162_full -> Patchwork_8961_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8961_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8961_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42942/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8961_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd1: shard-kbl: PASS -> SKIP +2 igt@gem_exec_schedule@deep-bsd2: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_8961_full that come from known issues: === IGT changes === Issues hit igt@kms_chv_cursor_fail@pipe-c-256x256-bottom-edge: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#105602) +33 igt@kms_flip@wf_vblank-ts-check-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) igt@perf_pmu@enable-race-vcs0: shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) +2 igt@perf_pmu@enable-race-vcs1: shard-kbl: PASS -> INCOMPLETE (fdo#103665) +1 igt@perf_pmu@enable-race-vecs0: shard-apl: PASS -> INCOMPLETE (fdo#103927) +2 Possible fixes igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic: shard-hsw: FAIL (fdo#104873) -> PASS igt@kms_flip@flip-vs-wf_vblank-interruptible: shard-glk: FAIL (fdo#100368) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS +1 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4162 -> Patchwork_8961 CI_DRM_4162: ea17aab5ec734a262a252758d7412c09dfa833cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8961: 5126eaff44f881f5deff006f2338ef87f4940bf9 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8961/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Wrap tasklet_struct for abuse
In the next few patches, we want to abuse tasklet to avoid ksoftirqd
latency along critical paths. To make that abuse easily to swallow,
first coat the tasklet in a little syntactic sugar.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_tasklet.h | 78 +
drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++-
drivers/gpu/drm/i915/intel_guc_submission.c | 8 +--
drivers/gpu/drm/i915/intel_lrc.c| 18 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +-
7 files changed, 102 insertions(+), 22 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_tasklet.h
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 63c96c2b8fcf..59e04387a27c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3036,7 +3036,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
* Turning off the execlists->tasklet until the reset is over
* prevents the race.
*/
- tasklet_disable(&engine->execlists.tasklet);
+ i915_tasklet_lock(&engine->execlists.tasklet);
/*
* We're using worker to queue preemption requests from the tasklet in
@@ -3256,7 +3256,7 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
{
- tasklet_enable(&engine->execlists.tasklet);
+ i915_tasklet_unlock(&engine->execlists.tasklet);
kthread_unpark(engine->breadcrumbs.signaler);
intel_uncore_forcewake_put(engine->i915, FORCEWAKE_ALL);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f9bc3aaa90d0..f8aff5a5aa83 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1477,7 +1477,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
}
if (tasklet)
- tasklet_hi_schedule(&execlists->tasklet);
+ i915_tasklet_schedule(&execlists->tasklet);
}
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
new file mode 100644
index ..42b002b88edb
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -0,0 +1,78 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef _I915_TASKLET_H_
+#define _I915_TASKLET_H_
+
+#include
+#include
+
+/**
+ * struct i915_tasklet - wrapper around tasklet_struct
+ *
+ * We want to abuse tasklets slightly, such as calling them directly. In some
+ * cases, this requires some auxiliary tracking so subclass the tasklet_struct
+ * so that we have a central place and helpers.
+ */
+struct i915_tasklet {
+ struct tasklet_struct base;
+};
+
+static inline void i915_tasklet_init(struct i915_tasklet *t,
+void (*func)(unsigned long),
+unsigned long data)
+{
+ tasklet_init(&t->base, func, data);
+}
+
+static inline bool i915_tasklet_is_scheduled(const struct i915_tasklet *t)
+{
+ return test_bit(TASKLET_STATE_SCHED, &t->base.state);
+}
+
+static inline bool i915_tasklet_is_running(const struct i915_tasklet *t)
+{
+ return test_bit(TASKLET_STATE_RUN, &t->base.state);
+}
+
+static inline bool i915_tasklet_is_enabled(const struct i915_tasklet *t)
+{
+ return likely(!atomic_read(&t->base.count));
+}
+
+static inline void i915_tasklet_schedule(struct i915_tasklet *t)
+{
+ tasklet_hi_schedule(&t->base);
+}
+
+static inline void i915_tasklet_flush(struct i915_tasklet *t)
+{
+ tasklet_kill(&t->base);
+}
+
+static inline void i915_tasklet_lock(struct i915_tasklet *t)
+{
+ tasklet_disable(&t->base);
+}
+
+static inline void i915_tasklet_unlock(struct i915_tasklet *t)
+{
+ tasklet_enable(&t->base);
+}
+
+static inline void i915_tasklet_set_func(struct i915_tasklet *t,
+void (*func)(unsigned long data),
+unsigned long data)
+{
+ i915_tasklet_lock(t);
+
+ t->base.func = func;
+ t->base.data = data;
+
+ i915_tasklet_unlock(t);
+}
+
+#endif /* _I915_TASKLET_H_ */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 70325e0824e3..3c8a0c3245f3 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1032,7 +1032,7 @@ void intel_engines_park(struct drm_i915_private *i915)
for_each_engine(engine, i915, id) {
/* Flush the residual irq tasklets first. */
intel_engine_disarm_breadcrumbs(engine);
- tasklet_kill(&engine->execlists.tasklet);
+ i915_tasklet_flush(&engine->execlists.tasklet);
/*
[Intel-gfx] [PATCH 4/5] drm/i915/execlists: Direct submission from irq handler
Continuing the theme of bypassing ksoftirqd latency, also first try to
directly submit from the CS interrupt handler to clear the ELSP and
queue the next.
In the past, we have been hesitant to do this as the context switch
processing has been quite heavy, requiring forcewaked mmio. However, as
we now can read the GPU state from the cacheable HWSP, it is relatively
cheap!
v2: Explain why we test_bit(IRQ_EXECLIST) after doing notify_ring (it's
because the notify_ring() may itself trigger direct submission clearing
the bit)
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_irq.c | 21 ++---
drivers/gpu/drm/i915/i915_tasklet.h | 21 +
drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
3 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f8aff5a5aa83..e1b3a7575fe7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1465,19 +1465,26 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir)
struct intel_engine_execlists * const execlists = &engine->execlists;
bool tasklet = false;
- if (iir & GT_CONTEXT_SWITCH_INTERRUPT) {
- if (READ_ONCE(engine->execlists.active))
- tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
- &engine->irq_posted);
- }
+ if (iir & GT_CONTEXT_SWITCH_INTERRUPT && READ_ONCE(execlists->active))
+ tasklet = !test_and_set_bit(ENGINE_IRQ_EXECLIST,
+ &engine->irq_posted);
if (iir & GT_RENDER_USER_INTERRUPT) {
notify_ring(engine);
- tasklet |= USES_GUC_SUBMISSION(engine->i915);
+ /*
+* notify_ring() may trigger direct submission onto this
+* engine, clearing the ENGINE_IRQ_EXECLIST bit. In that
+* case, we don't want to resubmit and so clear the tasklet
+* boolean. GuC never sets the ENGINE_IRQ_EXECLIST bit and
+* so when using the GuC this equates to an unconditional
+* setting of tasklet to true.
+*/
+ if (!test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted))
+ tasklet = USES_GUC_SUBMISSION(engine->i915);
}
if (tasklet)
- i915_tasklet_schedule(&execlists->tasklet);
+ i915_tasklet(&execlists->tasklet);
}
static void gen8_gt_irq_ack(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
index 99e2fa2241ba..c532282551b7 100644
--- a/drivers/gpu/drm/i915/i915_tasklet.h
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -99,4 +99,25 @@ static inline void i915_tasklet_run(const struct
i915_tasklet *t)
__i915_tasklet_run(t);
}
+static inline bool i915_tasklet_try(struct i915_tasklet *t)
+{
+ if (unlikely(!tasklet_trylock(&t->base)))
+ return false;
+
+ if (i915_tasklet_is_enabled(t))
+ i915_tasklet_run(t);
+
+ tasklet_unlock(&t->base);
+ return true;
+}
+
+static inline void i915_tasklet(struct i915_tasklet *t)
+{
+ if (!i915_tasklet_is_enabled(t)) /* GPU reset active */
+ return;
+
+ if (!i915_tasklet_try(t))
+ i915_tasklet_schedule(t);
+}
+
#endif /* _I915_TASKLET_H_ */
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index f2ded1796523..4e09abf7e206 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -780,6 +780,8 @@ static void guc_submission_tasklet(unsigned long data)
struct execlist_port *port = execlists->port;
struct i915_request *rq;
+ clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+
rq = port_request(port);
while (rq && i915_request_completed(rq)) {
trace_i915_request_out(rq);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915/execlists: Direct submit onto idle engines
Bypass using the tasklet to submit the first request to HW, as the
tasklet may be deferred unto ksoftirqd and at a minimum will add in
excess of 10us (and maybe tens of milliseconds) to our execution
latency. This latency reduction is most notable when execution flows
between engines.
v2: Beware handling preemption completion from the direct submit path as
well.
v3: Make the abuse clear and track our extra state inside i915_tasklet.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_tasklet.h | 24 +++
drivers/gpu/drm/i915/intel_guc_submission.c | 10 ++-
drivers/gpu/drm/i915/intel_lrc.c| 71 +
3 files changed, 89 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_tasklet.h
b/drivers/gpu/drm/i915/i915_tasklet.h
index 42b002b88edb..99e2fa2241ba 100644
--- a/drivers/gpu/drm/i915/i915_tasklet.h
+++ b/drivers/gpu/drm/i915/i915_tasklet.h
@@ -8,8 +8,11 @@
#define _I915_TASKLET_H_
#include
+#include
#include
+#include "i915_gem.h"
+
/**
* struct i915_tasklet - wrapper around tasklet_struct
*
@@ -19,6 +22,8 @@
*/
struct i915_tasklet {
struct tasklet_struct base;
+ unsigned long flags;
+#define I915_TASKLET_DIRECT_SUBMIT BIT(0)
};
static inline void i915_tasklet_init(struct i915_tasklet *t,
@@ -43,6 +48,14 @@ static inline bool i915_tasklet_is_enabled(const struct
i915_tasklet *t)
return likely(!atomic_read(&t->base.count));
}
+static inline bool i915_tasklet_is_direct_submit(const struct i915_tasklet *t)
+{
+ /* Only legal to be checked from inside the tasklet. */
+ GEM_BUG_ON(!i915_tasklet_is_running(t));
+
+ return t->flags & I915_TASKLET_DIRECT_SUBMIT;
+}
+
static inline void i915_tasklet_schedule(struct i915_tasklet *t)
{
tasklet_hi_schedule(&t->base);
@@ -75,4 +88,15 @@ static inline void i915_tasklet_set_func(struct i915_tasklet
*t,
i915_tasklet_unlock(t);
}
+static inline void __i915_tasklet_run(const struct i915_tasklet *t)
+{
+ t->base.func(t->base.data);
+}
+
+static inline void i915_tasklet_run(const struct i915_tasklet *t)
+{
+ GEM_BUG_ON(!i915_tasklet_is_running(t));
+ __i915_tasklet_run(t);
+}
+
#endif /* _I915_TASKLET_H_ */
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index a7afc976c3b9..f2ded1796523 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -754,14 +754,18 @@ static bool __guc_dequeue(struct intel_engine_cs *engine)
static void guc_dequeue(struct intel_engine_cs *engine)
{
- unsigned long flags;
+ unsigned long uninitialized_var(flags);
bool submit;
local_irq_save(flags);
- spin_lock(&engine->timeline.lock);
+ if (!i915_tasklet_is_direct_submit(&engine->execlists.tasklet))
+ spin_lock(&engine->timeline.lock);
+
submit = __guc_dequeue(engine);
- spin_unlock(&engine->timeline.lock);
+
+ if (!i915_tasklet_is_direct_submit(&engine->execlists.tasklet))
+ spin_unlock(&engine->timeline.lock);
if (submit)
guc_submit(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 539fa03d7600..09fded9d409f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -356,13 +356,15 @@ execlists_unwind_incomplete_requests(struct
intel_engine_execlists *execlists)
{
struct intel_engine_cs *engine =
container_of(execlists, typeof(*engine), execlists);
- unsigned long flags;
+ unsigned long uninitialized_var(flags);
- spin_lock_irqsave(&engine->timeline.lock, flags);
+ if (!i915_tasklet_is_direct_submit(&execlists->tasklet))
+ spin_lock_irqsave(&engine->timeline.lock, flags);
__unwind_incomplete_requests(engine);
- spin_unlock_irqrestore(&engine->timeline.lock, flags);
+ if (!i915_tasklet_is_direct_submit(&execlists->tasklet))
+ spin_unlock_irqrestore(&engine->timeline.lock, flags);
}
static inline void
@@ -601,6 +603,8 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
*/
GEM_BUG_ON(!execlists_is_active(execlists,
EXECLISTS_ACTIVE_USER));
+ GEM_BUG_ON(execlists_is_active(execlists,
+ EXECLISTS_ACTIVE_PREEMPT));
GEM_BUG_ON(!port_count(&port[0]));
if (port_count(&port[0]) > 1)
return false;
@@ -757,12 +761,16 @@ static bool __execlists_dequeue(struct intel_engine_cs
*engine)
static void execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
- unsigned long flags;
+ unsigned long
[Intel-gfx] [PATCH 1/5] drm/i915: Remove tasklet flush before disable
The idea was to try and let the existing tasklet run to completion before we began the reset, but it involves a racy check against anything else that tries to run the tasklet. Rather than acknowledge and ignore the race, let it be and don't try and be too clever. The tasklet will resume execution after reset (after spinning a bit during reset), but before we allow it to resume we will have cleared all the pending state. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 89bf5d67cb74..63c96c2b8fcf 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3035,16 +3035,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs *engine) * calling engine->init_hw() and also writing the ELSP. * Turning off the execlists->tasklet until the reset is over * prevents the race. -* -* Note that this needs to be a single atomic operation on the -* tasklet (flush existing tasks, prevent new tasks) to prevent -* a race between reset and set-wedged. It is not, so we do the best -* we can atm and make sure we don't lock the machine up in the more -* common case of recursively being called from set-wedged from inside -* i915_reset. */ - if (!atomic_read(&engine->execlists.tasklet.count)) - tasklet_kill(&engine->execlists.tasklet); tasklet_disable(&engine->execlists.tasklet); /* -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Speed up idle detection by kicking the tasklets
We rely on ksoftirqd to run in a timely fashion in order to drain the execlists queue. Quite frequently, it does not. In some cases we may see latencies of over 200ms triggering our idle timeouts and forcing us to declare the driver wedged! Thus we can speed up idle detection by bypassing ksoftirqd in these cases and flush our tasklet to confirm if we are indeed still waiting for the ELSP to drain. v2: Put the execlists.first check back; it is required for handling reset! v3: Follow Mika's suggestion to try and limit kicking the tasklet to only when we expect it to make a difference, i.e. in catch up after a CS interrupt, and not just execute it everytime as that is likely just to cover over our own bugs. References: https://bugs.freedesktop.org/show_bug.cgi?id=106373 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index 3c8a0c3245f3..f975091c5498 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -944,11 +944,20 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine) if (I915_SELFTEST_ONLY(engine->breadcrumbs.mock)) return true; + /* +* ksoftirqd has notorious latency that may cause us to +* timeout while waiting for the engine to idle as we wait for +* ksoftirqd to run the execlists tasklet to drain the ELSP. +* If we are expecting a context switch from the GPU, check now. +*/ + if (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted)) + i915_tasklet_try(&engine->execlists.tasklet); + /* Waiting to drain ELSP? */ if (READ_ONCE(engine->execlists.active)) return false; - /* ELSP is empty, but there are ready requests? */ + /* ELSP is empty, but there are ready requests? E.g. after reset */ if (READ_ONCE(engine->execlists.first)) return false; -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GMBUS changes (rev4)
== Series Details ==
Series: GMBUS changes (rev4)
URL : https://patchwork.freedesktop.org/series/41632/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7ef555142951 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
3e623cbfe855 drm/i915/gmbus: Enable burst read
-:34: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible
side-effects?
#34: FILE: drivers/gpu/drm/i915/i915_drv.h:2563:
+#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
+ IS_GEMINILAKE(dev_priv) || \
+ IS_KABYLAKE(dev_priv))
-:48: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#48: FILE: drivers/gpu/drm/i915/i915_reg.h:2999:
+#define GMBUS_BYTE_CNT_OVERRIDE (1<<6)
^
-:68: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#68: FILE: drivers/gpu/drm/i915/intel_i2c.c:381:
+ if (burst_read) {
+
total: 0 errors, 0 warnings, 3 checks, 120 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for GMBUS changes (rev4)
== Series Details == Series: GMBUS changes (rev4) URL : https://patchwork.freedesktop.org/series/41632/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/gmbus: Increase the Bytes per Rd/Wr Op -O:drivers/gpu/drm/i915/intel_i2c.c:403:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_i2c.c:465:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:472:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:472:23: warning: expression using sizeof(void) Commit: drm/i915/gmbus: Enable burst read -O:drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:438:31: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:438:31: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3654:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3657:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for GMBUS changes (rev4)
== Series Details == Series: GMBUS changes (rev4) URL : https://patchwork.freedesktop.org/series/41632/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4163 -> Patchwork_8962 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8962 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8962, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41632/revisions/4/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8962: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8962 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-glk-j4005: DMESG-WARN (fdo#106248) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-hsw-4770r: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 == Participating hosts (41 -> 37) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq == Build changes == * Linux: CI_DRM_4163 -> Patchwork_8962 CI_DRM_4163: 8e1dab6e913be7d014eb9bc355ec65b6b56dcd56 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8962: 3e623cbfe855623913aefc4cdef9c719141d @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Linux commits == 3e623cbfe855 drm/i915/gmbus: Enable burst read 7ef555142951 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8962/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915: Remove tasklet flush before disable
== Series Details == Series: series starting with [1/5] drm/i915: Remove tasklet flush before disable URL : https://patchwork.freedesktop.org/series/42950/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8083271a8a5b drm/i915: Remove tasklet flush before disable 23f6b88c5a19 drm/i915: Wrap tasklet_struct for abuse -:49: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #49: new file mode 100644 -:54: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #54: FILE: drivers/gpu/drm/i915/i915_tasklet.h:1: +/* total: 0 errors, 2 warnings, 0 checks, 221 lines checked 236c6eeffbad drm/i915/execlists: Direct submit onto idle engines -:85: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should also have an identifier name #85: FILE: drivers/gpu/drm/i915/intel_guc_submission.c:757: + unsigned long uninitialized_var(flags); -:111: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should also have an identifier name #111: FILE: drivers/gpu/drm/i915/intel_lrc.c:359: + unsigned long uninitialized_var(flags); -:139: WARNING:FUNCTION_ARGUMENTS: function definition argument 'flags' should also have an identifier name #139: FILE: drivers/gpu/drm/i915/intel_lrc.c:764: + unsigned long uninitialized_var(flags); total: 0 errors, 3 warnings, 0 checks, 192 lines checked d351b279d678 drm/i915/execlists: Direct submission from irq handler 5eb66ebc88e5 drm/i915: Speed up idle detection by kicking the tasklets ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Wrap tasklet_struct for abuse
Quoting Chris Wilson (2018-05-09 15:27:58) > In the next few patches, we want to abuse tasklet to avoid ksoftirqd > latency along critical paths. To make that abuse easily to swallow, > first coat the tasklet in a little syntactic sugar. > > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/i915_gem.c | 4 +- > drivers/gpu/drm/i915/i915_irq.c | 2 +- > drivers/gpu/drm/i915/i915_tasklet.h | 78 + > drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++- > drivers/gpu/drm/i915/intel_guc_submission.c | 8 +-- > drivers/gpu/drm/i915/intel_lrc.c| 18 ++--- > drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +- > 7 files changed, 102 insertions(+), 22 deletions(-) > create mode 100644 drivers/gpu/drm/i915/i915_tasklet.h > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 63c96c2b8fcf..59e04387a27c 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3036,7 +3036,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs > *engine) > * Turning off the execlists->tasklet until the reset is over > * prevents the race. > */ > - tasklet_disable(&engine->execlists.tasklet); > + i915_tasklet_lock(&engine->execlists.tasklet); Hmm, probably sensible to stick to disable/enable: - better match to tasklet_interface (no arbitrary impedance mismatch) - they are counting locks rather than mutex which we commonly think of for lock/unlock (more like a semaphore). After dropping the custom flush+disable wrapper, there's no good reason to have a custom name. Thoughts? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915: Remove tasklet flush before disable
== Series Details == Series: series starting with [1/5] drm/i915: Remove tasklet flush before disable URL : https://patchwork.freedesktop.org/series/42950/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Remove tasklet flush before disable Okay! Commit: drm/i915: Wrap tasklet_struct for abuse Okay! Commit: drm/i915/execlists: Direct submit onto idle engines +drivers/gpu/drm/i915/intel_guc_submission.c:768:28: warning: context imbalance in 'guc_dequeue' - unexpected unlock +drivers/gpu/drm/i915/intel_lrc.c:367:39: warning: context imbalance in 'execlists_unwind_incomplete_requests' - unexpected unlock +drivers/gpu/drm/i915/intel_lrc.c:773:39: warning: context imbalance in 'execlists_dequeue' - unexpected unlock Commit: drm/i915/execlists: Direct submission from irq handler Okay! Commit: drm/i915: Speed up idle detection by kicking the tasklets Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 21/40] drm/i915: Define Intel HDCP2.2 registers
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 21/40] drm/i915: Define Intel HDCP2.2 registers
>
>Intel HDCP2.2 registers are defined with addr offsets and bit details.
>
>v2:
> Replaced the arith calc with _PICK [Sean Paul]
>v3:
> No changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/i915_reg.h | 32
> 1 file changed, 32 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>index e6a8c0ee7df1..f04ad3c15abd 100644
>--- a/drivers/gpu/drm/i915/i915_reg.h
>+++ b/drivers/gpu/drm/i915/i915_reg.h
>@@ -8649,6 +8649,38 @@ enum skl_power_gate {
> #define HDCP_STATUS_CIPHER BIT(16)
> #define HDCP_STATUS_FRAME_CNT(x) ((x >> 8) & 0xff)
>
>+/* HDCP2.2 Registers */
>+#define _PORTA_HDCP2_BASE 0x66800
>+#define _PORTB_HDCP2_BASE 0x66500
>+#define _PORTC_HDCP2_BASE 0x66600
>+#define _PORTD_HDCP2_BASE 0x66700
>+#define _PORTE_HDCP2_BASE 0x66A00
>+#define _PORTF_HDCP2_BASE 0x66900
>+#define _PORT_HDCP2_BASE(port, x) _MMIO(_PICK(port, \
>+_PORTA_HDCP2_BASE, \
>+_PORTB_HDCP2_BASE, \
>+_PORTC_HDCP2_BASE, \
>+_PORTD_HDCP2_BASE, \
>+_PORTE_HDCP2_BASE, \
>+_PORTF_HDCP2_BASE) + x)
>+
>+#define HDCP2_AUTH_DDI(port) _PORT_HDCP2_BASE(port,
>0x98)
>+#define AUTH_LINK_AUTHENTICATED BIT(31)
>+#define AUTH_LINK_TYPE BIT(30)
>+#define AUTH_FORCE_CLR_INPUTCTR BIT(19)
>+#define AUTH_CLR_KEYS BIT(18)
>+
>+#define HDCP2_CTR_DDI(port) _PORT_HDCP2_BASE(port, 0xB0)
Rename it to HDCP2_CTL_DDI to match with spec and avoid any ambiguity.
>+#define CTL_LINK_ENCRYPTION_REQ BIT(31)
>+
>+#define HDCP2_STATUS_DDI(port)_PORT_HDCP2_BASE(port,
>0xB4)
>+#define STREAM_ENCRYPTION_STATUS_A BIT(31)
>+#define STREAM_ENCRYPTION_STATUS_B BIT(30)
>+#define STREAM_ENCRYPTION_STATUS_C BIT(29)
>+#define LINK_TYPE_STATUSBIT(22)
>+#define LINK_AUTH_STATUSBIT(21)
>+#define LINK_ENCRYPTION_STATUS BIT(20)
>+
> /* Per-pipe DDI Function Control */
> #define _TRANS_DDI_FUNC_CTL_A 0x60400
> #define _TRANS_DDI_FUNC_CTL_B 0x61400
>--
>2.7.4
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
On Wed, 2018-05-09 at 05:21 -0700, Rodrigo Vivi wrote:
> On Wed, May 09, 2018 at 10:13:21AM +0300, Jani Nikula wrote:
> > We've opted to use the maximum link rate and lane count for eDP
> > panels,
> > because typically the maximum supported configuration reported by
> > the
> > panel has matched the native resolution requirements of the panel,
> > and
> > optimizing the link has lead to problems.
> >
> > With eDP 1.4 rate select method and DSC features, this is
> > decreasingly
> > the case. There's a need to optimize the link parameters. Moreover,
> > already eDP 1.3 states fast link with fewer lanes is preferred over
> > the
> > wide and slow. (Wide and slow should still be more reliable for
> > longer
> > cable lengths.)
> >
> > Additionally, there have been reports of panels failing on
> > arbitrary
> > link configurations, although arguably all configurations they
> > claim to
> > support should work.
> >
> > Optimize eDP 1.4+ link config fast and narrow.
> >
> > Side note: The implementation has a near duplicate of the link
> > config
> > function, with just the two inner for loops turned inside out.
> > Perhaps
> > there'd be a way to make this, say, more table driven to reduce the
> > duplication, but seems like that would lead to duplication in the
> > table
> > generation. We'll also have to see how the link config optimization
> > for
> > DSC turns out.
> >
> > Cc: Ville Syrjälä
> > Cc: Manasi Navare
> > Cc: Rodrigo Vivi
>
> Cc: Matt Atwood
>
> I believe Matt is interested on this and know who could test this for
> us.
I'm actually in the process of working with my counterpart at Google to
actually quantify what power is saved. With both chromeos-
4.14/chromeos-4.4 patches to do so across multiple boards and multiple
systems.
>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> > Signed-off-by: Jani Nikula
>
> This matches my understand of the eDP 1.4 spec I believe this is the
> way to go, so
>
> Acked-by: Rodrigo Vivi
>
> but probably better to get a proper review and wait for someone
> to test...
>
> >
> > ---
> >
> > Untested. It's possible this helps the referenced bug. The downside
> > is
> > that this patch has a bunch of dependencies that are too much to
> > backport to stable kernels. If the patch works, we may need to
> > consider
> > hacking together an uglier backport.
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 73
> > ++---
> > 1 file changed, 62 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index dde92e4af5d3..1ec62965ece3 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1768,6 +1768,42 @@ intel_dp_compute_link_config_wide(struct
> > intel_dp *intel_dp,
> > return false;
> > }
> >
> > +/* Optimize link config in order: max bpp, min lanes, min clock */
> > +static bool
> > +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> > + struct intel_crtc_state
> > *pipe_config,
> > + const struct link_config_limits
> > *limits)
I personally called this intel_dp_compute_link_config_narrow as a
counterpart to the "wide" implementation.
> > +{
> > + struct drm_display_mode *adjusted_mode = &pipe_config-
> > >base.adjusted_mode;
> > + int bpp, clock, lane_count;
> > + int mode_rate, link_clock, link_avail;
> > +
> > + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -=
> > 2 * 3) {
> > + mode_rate = intel_dp_link_required(adjusted_mode-
> > >crtc_clock,
> > + bpp);
> > +
> > + for (lane_count = limits->min_lane_count;
> > +lane_count <= limits->max_lane_count;
> > +lane_count <<= 1) {
> > + for (clock = limits->min_clock; clock <=
> > limits->max_clock; clock++) {
> > + link_clock = intel_dp-
> > >common_rates[clock];
> > + link_avail =
> > intel_dp_max_data_rate(link_clock,
> > +
> > lane_count);
> > +
> > + if (mode_rate <= link_avail) {
> > + pipe_config->lane_count =
> > lane_count;
> > + pipe_config->pipe_bpp =
> > bpp;
> > + pipe_config->port_clock =
> > link_clock;
> > +
> > + return true;
> > + }
> > + }
> > + }
> > + }
> > +
> > + return false;
> > +}
> > +
> > static bool
> > intel_dp_compute_link_config(struct intel_encoder *encoder,
> > struct intel_crtc_state *pipe_config)
> > @@ -1792,13 +1828,15 @@ intel_dp_compute_link_config(struct
> > intel_encoder *encoder,
> > limits.min_bpp = 6 * 3;
> > limits.max_bpp = in
Re: [Intel-gfx] [PATCH v3 22/40] drm/i915: Wrappers for mei HDCP2.2 services
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 22/40] drm/i915: Wrappers for mei HDCP2.2
>services
>
>Adds the wrapper for all mei hdcp2.2 service functions.
>
>v2:
> Rebased.
>v3:
> cldev is moved from mei_hdcp_data to hdcp.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 194
>++
> 1 file changed, 194 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 1cca4f349064..b4d56b21cf9b 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -10,10 +10,13 @@
> #include
> #include
> #include
>+#include
>
> #include "intel_drv.h"
> #include "i915_reg.h"
>
>+#define GET_MEI_DDI_INDEX(port) (((port) == PORT_A) ? DDI_A : \
>+ (enum hdcp_physical_port) (port))
> #define KEY_LOAD_TRIES5
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port, @@ -
>817,3 +820,194 @@ int intel_hdcp_check_link(struct intel_connector
>*connector)
> mutex_unlock(&hdcp->hdcp_mutex);
> return ret;
> }
>+
>+static int
>+hdcp2_prepare_ake_init(struct intel_hdcp *hdcp, struct hdcp2_ake_init
>+*ake_data) {
>+ struct mei_hdcp_data *data = &hdcp->mei_data;
>+ struct intel_connector *connector = container_of(hdcp,
>+ struct intel_connector,
>+ hdcp);
>+
>+ if (!hdcp->cldev)
>+ return -EINVAL;
>+
>+ if (data->port == INVALID_PORT && connector->encoder)
>+ data->port = GET_MEI_DDI_INDEX(connector->encoder->port);
I believe caller should provide valid port and this should fail if port
received is invalid instead of
retrieving it here.
>+
>+ /* Clear ME FW instance for the port, just incase */
>+ mei_close_hdcp_session(hdcp->cldev, data);
>+
>+ return mei_initiate_hdcp2_session(hdcp->cldev, data, ake_data); }
>+
>+static int hdcp2_close_mei_session(struct intel_hdcp *hdcp) {
>+ struct mei_hdcp_data *data = &hdcp->mei_data;
>+
>+ if (!hdcp->cldev || data->port == INVALID_PORT)
This is what I was saying for above.
>+ return -EINVAL;
>+
>+ return mei_close_hdcp_session(hdcp->cldev, data); }
>+
>+static int
>+hdcp2_verify_rx_cert_prepare_km(struct intel_hdcp *hdcp,
>+ struct hdcp2_ake_send_cert *rx_cert,
>+ bool *paired,
>+ struct hdcp2_ake_no_stored_km *ek_pub_km,
>+ size_t *msg_sz)
>+{
>+ struct mei_hdcp_data *data = &hdcp->mei_data;
>+ int ret;
>+
>+ if (!hdcp->cldev)
>+ return -EINVAL;
>+
>+ ret = mei_verify_receiver_cert_prepare_km(hdcp->cldev, data, rx_cert,
>+paired, ek_pub_km, msg_sz);
>+ if (ret < 0)
>+ mei_close_hdcp_session(hdcp->cldev, data);
>+
>+ return ret;
>+}
>+
>+static int hdcp2_verify_hprime(struct intel_hdcp *hdcp,
>+ struct hdcp2_ake_send_hprime *rx_hprime) {
>+ struct mei_hdcp_data *data = &hdcp->mei_data;
>+ int ret;
>+
>+ if (!hdcp->cldev)
>+ return -EINVAL;
>+
>+ ret = mei_verify_hprime(hdcp->cldev, data, rx_hprime);
>+ if (ret < 0)
>+ mei_close_hdcp_session(hdcp->cldev, data);
>+
>+ return ret;
>+}
>+
>+static int
>+hdcp2_store_paring_info(struct intel_hdcp *hdcp,
>+ struct hdcp2_ake_send_pairing_info *pairing_info) {
>+ struct mei_hdcp_data *data = &hdcp->mei_data;
>+ int ret;
>+
>+ if (!hdcp->cldev)
>+ return -EINVAL;
>+
>+ ret = mei_store_pairing_info(hdcp->cldev, data, pairing_info);
>+ if (ret < 0)
>+ mei_close_hdcp_session(hdcp->cldev, data);
>+
>+ return ret;
>+}
>+
>+static int
>+hdcp2_prepare_lc_init(struct intel_hdcp *hdcp, struct hdcp2_lc_init
>+*lc_init) {
>+ struct mei_hdcp_data *data = &hdcp->mei_data;
>+ int ret;
>+
>+ if (!hdcp->cldev)
>+ return -EINVAL;
>+
>+ ret = mei_initiate_locality_check(hdcp->cldev, data, lc_init);
>+ if (ret < 0)
>+ mei_close_hdcp_session(hdcp->cldev, data);
>+
>+ return ret;
>+}
>+
>+static int
>+hdcp2_verify_lprime(struct intel_hdcp *hdcp,
>+ struct hdcp2_lc_send_lprime *rx_lprime) {
>+ struct mei_hdcp_data *data = &hdcp->mei_data;
>+ int ret;
>+
>+ if (!hdcp->cldev)
>+ return -EINVAL;
>+
>+
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Remove tasklet flush before disable
== Series Details == Series: series starting with [1/5] drm/i915: Remove tasklet flush before disable URL : https://patchwork.freedesktop.org/series/42950/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4163 -> Patchwork_8963 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8963 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8963, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42950/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8963: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8963 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cnl-y3: PASS -> DMESG-WARN (fdo#104951) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-glk-j4005: DMESG-WARN (fdo#106248) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-hsw-4770r: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 == Participating hosts (41 -> 37) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq == Build changes == * Linux: CI_DRM_4163 -> Patchwork_8963 CI_DRM_4163: 8e1dab6e913be7d014eb9bc355ec65b6b56dcd56 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8963: 5eb66ebc88e5235c97725e9d0dc08d1f6820aed0 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Linux commits == 5eb66ebc88e5 drm/i915: Speed up idle detection by kicking the tasklets d351b279d678 drm/i915/execlists: Direct submission from irq handler 236c6eeffbad drm/i915/execlists: Direct submit onto idle engines 23f6b88c5a19 drm/i915: Wrap tasklet_struct for abuse 8083271a8a5b drm/i915: Remove tasklet flush before disable == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8963/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 23/40] drm/i915: Implement HDCP2.2 receiver authentication
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 23/40] drm/i915: Implement HDCP2.2 receiver
>authentication
>
>Implements HDCP2.2 authentication for hdcp2.2 receivers, with following steps:
> Authentication and Key enchange (AKE).
Typo in exchange.
> Locality Check (LC).
> Session Key Exchange(SKE).
> DP Errata for stream type confuguration for receivers.
Typo in configuration.
>
>At AKE, the HDCP Receiver’s public key certificate is verified by the HDCP
>Transmitter. A Master Key k m is exchanged.
>
>At LC, the HDCP Transmitter enforces locality on the content by requiring that
>the
>Round Trip Time (RTT) between a pair of messages is not more than 20 ms.
>
>At SKE, The HDCP Transmitter exchanges Session Key ks with the HDCP Receiver.
>
>In DP HDCP2.2 encryption and decryption logics use the stream type as one of
>the
>parameter. So Before enabling the Encryption DP HDCP2.2 receiver needs to be
>communicated with stream type. This is added to spec as ERRATA.
>
>This generic implementation is complete only with the hdcp2_shim defined.
>
>v2:
> Rebased.
>v3:
> No Changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 184
>++
> 1 file changed, 184 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index b4d56b21cf9b..ee9b7519fe73 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -18,6 +18,7 @@
> #define GET_MEI_DDI_INDEX(port) (((port) == PORT_A) ? DDI_A : \
>(enum hdcp_physical_port) (port))
> #define KEY_LOAD_TRIES5
>+#define HDCP2_LC_RETRY_CNT3
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
> const struct intel_hdcp_shim *shim) @@ -
>1011,3 +1012,186 @@ static inline int hdcp2_deauthenticate_port(struct
>intel_hdcp *hdcp) {
> return hdcp2_close_mei_session(hdcp);
> }
>+
>+static int hdcp2_authentication_key_exchange(struct intel_connector
>+*connector) {
>+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+ struct intel_hdcp *hdcp = &connector->hdcp;
>+ union {
>+ struct hdcp2_ake_init ake_init;
>+ struct hdcp2_ake_send_cert send_cert;
>+ struct hdcp2_ake_no_stored_km no_stored_km;
>+ struct hdcp2_ake_send_hprime send_hprime;
>+ struct hdcp2_ake_send_pairing_info pairing_info;
>+ } msgs;
>+ const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
>+ size_t size;
>+ int ret;
>+
>+ /* Init for seq_num */
>+ hdcp->seq_num_v = 0;
>+ hdcp->seq_num_m = 0;
>+
>+ ret = hdcp2_prepare_ake_init(hdcp, &msgs.ake_init);
>+ if (ret < 0)
>+ return ret;
>+
>+ ret = shim->write_2_2_msg(intel_dig_port, &msgs.ake_init,
>+sizeof(msgs.ake_init));
>+ if (ret < 0)
>+ return ret;
>+
>+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_AKE_SEND_CERT,
>+ &msgs.send_cert, sizeof(msgs.send_cert));
>+ if (ret < 0)
>+ return ret;
>+
>+ if (msgs.send_cert.rx_caps[0] != HDCP_2_2_RX_CAPS_VERSION_VAL)
>+ return -EINVAL;
>+
>+ hdcp->is_repeater =
>HDCP_2_2_RX_REPEATER(msgs.send_cert.rx_caps[2]);
>+
>+ /*
>+ * Here msgs.no_stored_km will hold msgs corresponding to the km
>+ * stored also.
>+ */
>+ ret = hdcp2_verify_rx_cert_prepare_km(hdcp, &msgs.send_cert,
>+&hdcp->is_paired,
>+&msgs.no_stored_km, &size);
>+ if (ret < 0)
>+ return ret;
>+
>+ ret = shim->write_2_2_msg(intel_dig_port, &msgs.no_stored_km, size);
>+ if (ret < 0)
>+ return ret;
>+
>+ ret = shim->read_2_2_msg(intel_dig_port,
>HDCP_2_2_AKE_SEND_HPRIME,
>+ &msgs.send_hprime,
>sizeof(msgs.send_hprime));
>+ if (ret < 0)
>+ return ret;
>+
>+ ret = hdcp2_verify_hprime(hdcp, &msgs.send_hprime);
>+ if (ret < 0)
>+ return ret;
>+
>+ if (!hdcp->is_paired) {
>+ /* Pairing is required */
>+ ret = shim->read_2_2_msg(intel_dig_port,
>+ HDCP_2_2_AKE_SEND_PARING_INFO,
>+ &msgs.pairing_info,
>+ sizeof(msgs.pairing_info));
>+ if
Re: [Intel-gfx] [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
On Wed, 2018-05-09 at 08:09 -0700, Matt Atwood wrote:
> On Wed, 2018-05-09 at 05:21 -0700, Rodrigo Vivi wrote:
> > On Wed, May 09, 2018 at 10:13:21AM +0300, Jani Nikula wrote:
> > > We've opted to use the maximum link rate and lane count for eDP
> > > panels,
> > > because typically the maximum supported configuration reported by
> > > the
> > > panel has matched the native resolution requirements of the
> > > panel,
> > > and
> > > optimizing the link has lead to problems.
> > >
> > > With eDP 1.4 rate select method and DSC features, this is
> > > decreasingly
> > > the case. There's a need to optimize the link parameters.
> > > Moreover,
> > > already eDP 1.3 states fast link with fewer lanes is preferred
> > > over
> > > the
> > > wide and slow. (Wide and slow should still be more reliable for
> > > longer
> > > cable lengths.)
> > >
> > > Additionally, there have been reports of panels failing on
> > > arbitrary
> > > link configurations, although arguably all configurations they
> > > claim to
> > > support should work.
> > >
> > > Optimize eDP 1.4+ link config fast and narrow.
> > >
> > > Side note: The implementation has a near duplicate of the link
> > > config
> > > function, with just the two inner for loops turned inside out.
> > > Perhaps
> > > there'd be a way to make this, say, more table driven to reduce
> > > the
> > > duplication, but seems like that would lead to duplication in the
> > > table
> > > generation. We'll also have to see how the link config
> > > optimization
> > > for
> > > DSC turns out.
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Manasi Navare
> > > Cc: Rodrigo Vivi
> >
> > Cc: Matt Atwood
> >
> > I believe Matt is interested on this and know who could test this
> > for
> > us.
>
> I'm actually in the process of working with my counterpart at Google
> to
> actually quantify what power is saved. With both chromeos-
> 4.14/chromeos-4.4 patches to do so across multiple boards and
> multiple
> systems.
> >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> > > Signed-off-by: Jani Nikula
> >
> > This matches my understand of the eDP 1.4 spec I believe this is
> > the
> > way to go, so
> >
> > Acked-by: Rodrigo Vivi
> >
> > but probably better to get a proper review and wait for someone
> > to test...
> >
> > >
> > > ---
> > >
> > > Untested. It's possible this helps the referenced bug. The
> > > downside
> > > is
> > > that this patch has a bunch of dependencies that are too much to
> > > backport to stable kernels. If the patch works, we may need to
> > > consider
> > > hacking together an uglier backport.
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 73
> > > ++---
> > > 1 file changed, 62 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index dde92e4af5d3..1ec62965ece3 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -1768,6 +1768,42 @@ intel_dp_compute_link_config_wide(struct
> > > intel_dp *intel_dp,
> > > return false;
> > > }
> > >
> > > +/* Optimize link config in order: max bpp, min lanes, min clock
> > > */
> > > +static bool
> > > +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> > > + struct intel_crtc_state
> > > *pipe_config,
> > > + const struct
> > > link_config_limits
> > > *limits)
>
> I personally called this intel_dp_compute_link_config_narrow as a
> counterpart to the "wide" implementation.
> > > +{
> > > + struct drm_display_mode *adjusted_mode = &pipe_config-
> > > > base.adjusted_mode;
> > >
> > > + int bpp, clock, lane_count;
> > > + int mode_rate, link_clock, link_avail;
> > > +
> > > + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp
> > > -=
> > > 2 * 3) {
> > > + mode_rate =
> > > intel_dp_link_required(adjusted_mode-
> > > > crtc_clock,
> > >
> > > +bpp);
> > > +
> > > + for (lane_count = limits->min_lane_count;
> > > + lane_count <= limits->max_lane_count;
> > > + lane_count <<= 1) {
> > > + for (clock = limits->min_clock; clock <=
> > > limits->max_clock; clock++) {
> > > + link_clock = intel_dp-
> > > > common_rates[clock];
> > >
> > > + link_avail =
> > > intel_dp_max_data_rate(link_clock,
> > > +
> > >
> > > lane_count);
> > > +
> > > + if (mode_rate <= link_avail) {
> > > + pipe_config->lane_count
> > > =
> > > lane_count;
> > > + pipe_config->pipe_bpp =
> > > bpp;
> > > + pipe_config->port_clock
> > > =
> > > link_clock;
> > > +
> > > + return true;
> > > + }
> > >
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915: reprogram NOA muxes on context switch when using perf
On 09/05/18 09:59, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-05-08 19:03:45)
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes. We need to reprogram them
when we detect a powergating configuration change.
In this change i915/perf is responsible for setting up a reprogramming
batchbuffer which we execute just before the userspace submitted
batchbuffer. We do this while preemption is still disable, only if
needed. The decision to execute this reprogramming batchbuffer is made
when we assign a request to an execlist port.
v2: Only reprogram when detecting configuration changes (Chris/Lionel)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_perf.c | 108 ++
drivers/gpu/drm/i915/i915_request.h | 6 ++
drivers/gpu/drm/i915/intel_gpu_commands.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 59 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +
7 files changed, 183 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 04e27806e581..07cdbfb4ad7a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1461,6 +1461,12 @@ struct i915_perf_stream {
* @oa_config: The OA configuration used by the stream.
*/
struct i915_oa_config *oa_config;
+
+ /**
+* @noa_reprogram_vma: A batchbuffer reprogramming the NOA muxes, used
+* after switching powergating configurations.
+*/
+ struct i915_vma *noa_reprogram_vma;
};
/**
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 5b279a82445a..1b9e3d6a53a2 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1691,6 +1691,96 @@ static int gen8_emit_oa_config(struct i915_request *rq,
return 0;
}
+#define MAX_LRI_SIZE (125U)
+
+static u32 noa_reprogram_bb_size(struct i915_oa_config *oa_config)
+{
+ u32 n_lri;
+
+ /* Very unlikely but possible that we have no muxes to configure. */
+ if (!oa_config->mux_regs_len)
+ return 0;
+
+ n_lri = (oa_config->mux_regs_len / MAX_LRI_SIZE) +
+ (oa_config->mux_regs_len % MAX_LRI_SIZE) != 0;
+
+ return n_lri * 4 + oa_config->mux_regs_len * 8 + /*
MI_LOAD_REGISTER_IMMs */
+ 6 * 4 + /* PIPE_CONTROL */
+ 4; /* MI_BATCH_BUFFER_END */
+}
+
+static int
+alloc_noa_reprogram_bo(struct i915_perf_stream *stream)
+{
+ struct drm_i915_private *dev_priv = stream->dev_priv;
+ struct i915_oa_config *oa_config = stream->oa_config;
+ struct drm_i915_gem_object *bo;
+ struct i915_vma *vma;
+ u32 buffer_size;
+ u32 *cs;
+ int i, ret, n_loaded_regs;
+
+ buffer_size = ALIGN(noa_reprogram_bb_size(oa_config), PAGE_SIZE);
+ if (buffer_size == 0)
+ return 0;
+
+ bo = i915_gem_object_create(dev_priv, buffer_size);
+ if (IS_ERR(bo)) {
+ DRM_ERROR("Failed to allocate NOA reprogramming buffer\n");
+ return PTR_ERR(bo);
+ }
+
+ cs = i915_gem_object_pin_map(bo, I915_MAP_WB);
+ if (IS_ERR(cs)) {
+ ret = PTR_ERR(cs);
+ goto err_unref_bo;
+ }
+
+ n_loaded_regs = 0;
+ for (i = 0; i < oa_config->mux_regs_len; i++) {
+ if ((n_loaded_regs % MAX_LRI_SIZE) == 0) {
+ u32 n_lri = min(oa_config->mux_regs_len - n_loaded_regs,
+ MAX_LRI_SIZE);
+ *cs++ = MI_LOAD_REGISTER_IMM(n_lri);
+ }
+
+ *cs++ = i915_mmio_reg_offset(oa_config->mux_regs[i].addr);
+ *cs++ = oa_config->mux_regs[i].value;
+ n_loaded_regs++;
+ }
+
+ cs = gen8_emit_pipe_control(cs, PIPE_CONTROL_MMIO_WRITE, 0);
What's the pc for? Isn't it a bit dangerous to request a mmio write to
to reg 0?
Oops, I've been using this wrong :(
I thought it would flush pending MMIO writes.
+
+ *cs++ = MI_BATCH_BUFFER_END;
+
+ i915_gem_object_unpin_map(bo);
+
+ ret = i915_gem_object_set_to_gtt_domain(bo, false);
+ if (ret)
+ goto err_unref_bo;
+
+ vma = i915_vma_instance(bo, &dev_priv->ggtt.base, NULL);
+ if (IS_ERR(vma)) {
+ ret = PTR_ERR(vma);
+ goto err_unref_bo;
+ }
+
+ ret = i915_vma_pin(vma, 0, 0, PIN_USER | PIN_GLOBAL);
+ if (ret)
+ goto err_unref_vma;
No GGTT access, so just PIN_USER for GPU access.
Okay. I just don't seem to understand any of the vma stuff...
+ stream->noa_reprogram_vma = vma;
+
+ return 0;
+
+err_unref_vma:
+ i915_vm
[Intel-gfx] [PATCH i-g-t v4 7/7] trace.pl: Fix request split mode
From: Tvrtko Ursulin
Request split mode had several bugs, both in the original version and also
after the recent refactorings.
One big one was that it wasn't considering different submit ports as a
reason to split execution, and also that it was too time based instead of
looking at relevant timelines.
In this refactoring we address the former by using the engine timelines
introduced in the previous patch. Secondary port submissions are moved
to follow the preceding submission as a first step in the correction
process.
In the second step, we add context timelines and use then in a similar
fashion to separate start and end time of coalesced requests. For each
coalesced request we know its boundaries by looking at the engine
timeline (via global seqnos), and we know the previous request it should
only start after, by looking at the context timeline.
v2:
* Remove some dead code.
* Fix !port0 shifting logic.
v3:
* Refactor for less list walking as with incomplete handling.
v4:
* Database of context timelines should not contain duplicates!
(Converted from array into a hash.)
Signed-off-by: Tvrtko Ursulin
Cc: John Harrison
---
scripts/trace.pl | 126 ++-
1 file changed, 98 insertions(+), 28 deletions(-)
diff --git a/scripts/trace.pl b/scripts/trace.pl
index 935f57117a37..936e4fe6b885 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -27,7 +27,7 @@ use warnings;
use 5.010;
my $gid = 0;
-my (%db, %queue, %submit, %notify, %rings, %ctxdb, %ringmap, %reqwait);
+my (%db, %queue, %submit, %notify, %rings, %ctxdb, %ringmap, %reqwait,
%ctxtimelines);
my @freqs;
my $max_items = 3000;
@@ -435,6 +435,7 @@ while (<>) {
$req{'ring'} = $ring;
$req{'seqno'} = $seqno;
$req{'ctx'} = $ctx;
+ $ctxtimelines{$ctx . '/' . $ring} = 1;
$req{'name'} = $ctx . '/' . $seqno;
$req{'global'} = $tp{'global'};
$req{'port'} = $tp{'port'};
@@ -589,41 +590,110 @@ sub sortStart {
return $val;
}
-my @sorted_keys = sort sortStart keys %db;
-my $re_sort = 0;
+my $re_sort = 1;
+my @sorted_keys;
-die "Database changed size?!" unless scalar(@sorted_keys) == $key_count;
+sub maybe_sort_keys
+{
+ if ($re_sort) {
+ @sorted_keys = sort sortStart keys %db;
+ $re_sort = 0;
+ die "Database changed size?!" unless scalar(@sorted_keys) ==
+$key_count;
+ }
+}
-foreach my $key (@sorted_keys) {
- my $ring = $db{$key}->{'ring'};
- my $end = $db{$key}->{'end'};
+maybe_sort_keys();
+
+my %ctx_timelines;
+
+sub sortContext {
+ my $as = $db{$a}->{'seqno'};
+ my $bs = $db{$b}->{'seqno'};
+ my $val;
+
+ $val = $as <=> $bs;
+
+ die if $val == 0;
+
+ return $val;
+}
+
+sub get_ctx_timeline {
+ my ($ctx, $ring, $key) = @_;
+ my @timeline;
+
+ return $ctx_timelines{$key} if exists $ctx_timelines{$key};
+
+ @timeline = grep { $db{$_}->{'ring'} == $ring and
+ $db{$_}->{'ctx'} == $ctx } @sorted_keys;
+ # FIXME seqno restart
+ @timeline = sort sortContext @timeline;
+
+ $ctx_timelines{$key} = \@timeline;
+
+ return \@timeline;
+}
+
+# Split out merged batches if requested.
+if ($correct_durations) {
+ # Shift !port0 requests start time to after the previous context on the
+ # same timeline has finished.
+ foreach my $gid (sort keys %rings) {
+ my $ring = $ringmap{$rings{$gid}};
+ my $timeline = get_engine_timeline($ring);
+ my $complete;
+
+ foreach my $pos (0..$#{$timeline}) {
+ my $key = @{$timeline}[$pos];
+ my $prev = $complete;
+ my $pkey;
+
+ $complete = $key unless exists $db{$key}->{'no-end'};
+ $pkey = $complete;
+
+ next if $db{$key}->{'port'} == 0;
+
+ $pkey = $prev if $complete eq $key;
+
+ die unless defined $pkey;
+
+ $db{$key}->{'start'} = $db{$pkey}->{'end'};
+ $db{$key}->{'start'} = $db{$pkey}->{'notify'} if
$db{$key}->{'start'} > $db{$key}->{'end'};
+
+ die if $db{$key}->{'start'} > $db{$key}->{'end'};
+
+ $re_sort = 1;
+ }
+ }
+
+ maybe_sort_keys();
+
+ # Batch with no-end (no request_out) means it was submitted as part of
+ # colaesced context. This means it's start time should be set to end
+ # time of a following request on this timeline.
+ foreach my $tkey (sort keys %ctxtimelines) {
+ my ($ctx, $ring) = split '/', $tkey;
+ my $timeline = get_ctx_timeline($ctx, $ring, $tkey);
+ my $last_complete = -1;
+
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
On 08/05/18 21:56, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-03 18:18:43)
On 25/04/2018 12:45, Lionel Landwerlin wrote:
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.
The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.
We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,
struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .flags =
I915_EXEC_RENDER };
memset(&arg, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t) &sseu;
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, &arg) == 0) {
sseu.packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &arg);
}
could be used to disable all subslices where supported.
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
c: Dmitry Rogozhkin
CC: Tvrtko Ursulin
CC: Zhipeng Gong
CC: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 82 -
drivers/gpu/drm/i915/intel_lrc.c| 55 +
drivers/gpu/drm/i915/intel_lrc.h| 4 ++
include/uapi/drm/i915_drm.h | 28 +
4 files changed, 168 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index bdf050beeb94..b97ddcf47514 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -740,6 +740,26 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
return 0;
}
+static struct i915_gem_context_sseu
+i915_gem_context_sseu_from_user_sseu(const struct sseu_dev_info *sseu,
+ const struct drm_i915_gem_context_param_sseu
*user_sseu)
+{
+ struct i915_gem_context_sseu value = {
+ .slice_mask = user_sseu->packed.slice_mask == 0 ?
+ sseu->slice_mask :
+ (user_sseu->packed.slice_mask & sseu->slice_mask),
+ .subslice_mask = user_sseu->packed.subslice_mask == 0 ?
+ sseu->subslice_mask[0] :
+ (user_sseu->packed.subslice_mask &
sseu->subslice_mask[0]),
+ .min_eus_per_subslice =
min(user_sseu->packed.min_eus_per_subslice,
+ sseu->max_eus_per_subslice),
+ .max_eus_per_subslice =
min(user_sseu->packed.max_eus_per_subslice,
+ sseu->max_eus_per_subslice),
+ };
+
+ return value;
+}
+
int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
@@ -777,6 +797,37 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
case I915_CONTEXT_PARAM_PRIORITY:
args->value = ctx->sched.priority;
break;
+ case I915_CONTEXT_PARAM_SSEU: {
+ struct drm_i915_gem_context_param_sseu param_sseu;
+ struct intel_engine_cs *engine;
+
+ if (copy_from_user(¶m_sseu, u64_to_user_ptr(args->value),
+sizeof(param_sseu))) {
+ ret = -EFAULT;
+ break;
+ }
+
+ engine = i915_gem_engine_from_flags(to_i915(dev), file,
+ param_sseu.flags);
+ if (!engine) {
+ ret = -EINVAL;
+ break;
+ }
+
+ param_sseu.packed.slice_mask =
+ ctx->engine[engine->id].sseu.slice_mask;
+ param_sseu.packed.subslice_mask =
+ ctx->engine[engine->id].sseu.subslice_mask;
+ param_sseu.packed.min_eus_per_subslice =
+ ctx->engine[engine->id].sseu.min_eus_per_subslice;
[Intel-gfx] ✓ Fi.CI.IGT: success for GMBUS changes (rev4)
== Series Details == Series: GMBUS changes (rev4) URL : https://patchwork.freedesktop.org/series/41632/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4163_full -> Patchwork_8962_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8962_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8962_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41632/revisions/4/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8962_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: SKIP -> PASS +2 igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: PASS -> SKIP +1 igt@kms_force_connector_basic@force-connector-state: shard-snb: PASS -> SKIP igt@kms_properties@plane-properties-legacy: shard-snb: SKIP -> PASS +4 == Known issues == Here are the changes found in Patchwork_8962_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@plain-flip-ts-check-interruptible: shard-glk: PASS -> FAIL (fdo#100368) +1 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: shard-apl: PASS -> FAIL (fdo#103167, fdo#104724) Possible fixes igt@kms_flip@absolute-wf_vblank-interruptible: shard-glk: FAIL (fdo#106087) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-apl: FAIL (fdo#105363, fdo#102887) -> PASS igt@kms_flip@wf_vblank-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS shard-apl: FAIL (fdo#100368) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4163 -> Patchwork_8962 CI_DRM_4163: 8e1dab6e913be7d014eb9bc355ec65b6b56dcd56 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8962: 3e623cbfe855623913aefc4cdef9c719141d @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8962/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/8] drm/i915: add new pipe control helper for mmio writes
We'll use those helpers in the following commits. It's a good thing to
have them around as they need to apply a particular workaround on
Skylake.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c| 34 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 5
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e754e9d112a5..6fe0d668c023 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2151,6 +2151,40 @@ static void gen8_emit_breadcrumb_rcs(struct i915_request
*request, u32 *cs)
}
static const int gen8_emit_breadcrumb_rcs_sz = 8 + WA_TAIL_DWORDS;
+u32 gen8_lri_pipe_control_len(struct drm_i915_private *dev_priv)
+{
+ return IS_SKYLAKE(dev_priv) ? (7) : 5;
+}
+
+u32 *gen8_emit_lri_pipe_control(struct drm_i915_private *dev_priv,
+ u32 *cs, u32 flags, u32 offset,
+ u32 value)
+{
+ /*
+* Project: SKL
+*
+* "PIPECONTROL command with "Command Streamer Stall Enable" must be
+* programmed prior to programming a PIPECONTROL command with LRI
+* Post Sync Operation in GPGPU mode of operation (i.e when
+* PIPELINE_SELECT command is set to GPGPU mode of operation)."
+*
+* Since the mode of operation is selected from userspace, we apply
+* this workaround all the time one SKL.
+*/
+ if (IS_SKYLAKE(dev_priv)) {
+ *cs++ = GFX_OP_PIPE_CONTROL(2);
+ *cs++ = PIPE_CONTROL_CS_STALL;
+ }
+
+ *cs++ = GFX_OP_PIPE_CONTROL(5);
+ *cs++ = PIPE_CONTROL_MMIO_WRITE | flags;
+ *cs++ = offset;
+ *cs++ = 0;
+ *cs++ = value;
+
+ return cs;
+}
+
static int gen8_init_rcs_context(struct i915_request *rq)
{
int ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 010750e8ee44..aa643a1d69db 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -1042,6 +1042,11 @@ gen8_emit_ggtt_write(u32 *cs, u32 value, u32 gtt_offset)
return cs;
}
+u32 gen8_lri_pipe_control_len(struct drm_i915_private *dev_priv);
+u32 *gen8_emit_lri_pipe_control(struct drm_i915_private *dev_priv,
+ u32 *cs, u32 flags, u32 offset,
+ u32 value);
+
bool intel_engine_is_idle(struct intel_engine_cs *engine);
bool intel_engines_are_idle(struct drm_i915_private *dev_priv);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 6/8] drm/i915: reprogram NOA muxes on context switch when using perf
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes. We need to reprogram them
when we detect a powergating configuration change.
In this change i915/perf is responsible for setting up a reprogramming
batchbuffer which we execute just before the userspace submitted
batchbuffer. We do this while preemption is still disable, only if
needed. The decision to execute this reprogramming batchbuffer is made
when we assign a request to an execlist port.
v2: Only reprogram when detecting configuration changes (Chris/Lionel)
v3: Clear engine sseu tracking on execlists cancel port (Chris)
Store NOA reprogramming vma on the engine (Chris/Lionel)
Use PIPECONTROL MMIO write correctly, on the last register write
(Chris/Lionel)
Pin NOA reprogramming vma with PIN_USER only (Chris)
Program MI_BATCH_BUFFER_START into NOA reprogramming correctly (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c| 135
drivers/gpu/drm/i915/i915_request.c | 2 +
drivers/gpu/drm/i915/i915_request.h | 11 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +
drivers/gpu/drm/i915/intel_lrc.c| 57 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 14 +++
6 files changed, 220 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 5b279a82445a..66a8f296290a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1691,6 +1691,122 @@ static int gen8_emit_oa_config(struct i915_request *rq,
return 0;
}
+#define MAX_LRI_SIZE (125U)
+
+static u32 noa_reprogram_bb_size(struct drm_i915_private *dev_priv,
+const struct i915_oa_config *oa_config)
+{
+ u32 n_lri_mux_regs;
+ u32 n_lri;
+
+ /* Very unlikely but possible that we have no muxes to configure. */
+ if (!oa_config->mux_regs_len)
+ return 0;
+
+ n_lri_mux_regs = oa_config->mux_regs_len - 1;
+
+ n_lri = (n_lri_mux_regs / MAX_LRI_SIZE) +
+ (n_lri_mux_regs % MAX_LRI_SIZE) != 0;
+
+ return n_lri * 4 + n_lri_mux_regs * 8 + /* MI_LOAD_REGISTER_IMMs */
+ gen8_lri_pipe_control_len(dev_priv) + /* PIPE_CONTROL */
+ 4; /* MI_BATCH_BUFFER_END */
+}
+
+static struct i915_vma *
+alloc_noa_reprogram_bo(struct drm_i915_private *dev_priv,
+ const struct i915_oa_config *oa_config)
+{
+ struct drm_i915_gem_object *bo;
+ struct i915_vma *vma;
+ u32 buffer_size, pc_flags;
+ u32 *cs;
+ int i, ret, last_reg, n_loaded_regs;
+
+ buffer_size =
+ ALIGN(noa_reprogram_bb_size(dev_priv, oa_config), PAGE_SIZE);
+ if (buffer_size == 0)
+ return NULL;
+
+ bo = i915_gem_object_create(dev_priv, buffer_size);
+ if (IS_ERR(bo)) {
+ DRM_ERROR("Failed to allocate NOA reprogramming buffer\n");
+ ret = PTR_ERR(bo);
+ }
+
+ cs = i915_gem_object_pin_map(bo, I915_MAP_WB);
+ if (IS_ERR(cs)) {
+ ret = PTR_ERR(cs);
+ goto err_unref_bo;
+ }
+
+ n_loaded_regs = 0;
+ last_reg = oa_config->mux_regs_len - 1;
+ for (i = 0; i < last_reg; i++) {
+ if ((n_loaded_regs % MAX_LRI_SIZE) == 0) {
+ u32 n_lri = min(oa_config->mux_regs_len - n_loaded_regs,
+ MAX_LRI_SIZE);
+ *cs++ = MI_LOAD_REGISTER_IMM(n_lri);
+ }
+
+ *cs++ = i915_mmio_reg_offset(oa_config->mux_regs[i].addr);
+ *cs++ = oa_config->mux_regs[i].value;
+ n_loaded_regs++;
+ }
+
+ pc_flags = PIPE_CONTROL_CS_STALL;
+ /*
+* Project: PRE-SKL
+*
+* Command Streamer Stall Enable:
+*
+* "One of the following must also be set:
+* - Render Target Cache Flush Enable
+* - Dpeth Cache Flush Enable
+* - Stall at Pixel Scoreboard
+* - Depth Stall
+* - Post-Sync Operation
+* - DC FlushEnable"
+*
+* Since we only do NOA reprogramming on Gen8+, this is the only Gen
+* where we need to apply this.
+*/
+ if (IS_GEN8(dev_priv, 8))
+ pc_flags |= PIPE_CONTROL_STALL_AT_SCOREBOARD;
+
+ /* Serialize on the last MMIO write. */
+ cs = gen8_emit_lri_pipe_control(dev_priv, cs, pc_flags,
+
i915_mmio_reg_offset(oa_config->mux_regs[last_reg].addr),
+ oa_config->mux_regs[last_reg].value);
+
+ *cs++ = MI_BATCH_BUFFER_END;
+
+ i915_gem_object_unpin_map(bo);
+
+ ret = i915_gem_object_set_to_gtt_domain(bo, false);
+ if (ret)
+ goto err_
[Intel-gfx] [PATCH v4 2/8] drm/i915: Record the sseu configuration per-context & engine
From: Chris Wilson
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)
v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_gem_context.c | 22 ++
drivers/gpu/drm/i915/i915_gem_context.h | 3 +++
drivers/gpu/drm/i915/i915_request.h | 13 +
drivers/gpu/drm/i915/intel_lrc.c| 24
4 files changed, 50 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 33f8a4b3c981..a04f0329e85a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -261,11 +261,26 @@ static u32 default_desc_template(const struct
drm_i915_private *i915,
return desc;
}
+static union intel_sseu
+intel_sseu_from_device_sseu(const struct sseu_dev_info *sseu)
+{
+ union intel_sseu value = {
+ .slice_mask = sseu->slice_mask,
+ .subslice_mask = sseu->subslice_mask[0],
+ .min_eus_per_subslice = sseu->max_eus_per_subslice,
+ .max_eus_per_subslice = sseu->max_eus_per_subslice,
+ };
+
+ return value;
+}
+
static struct i915_gem_context *
__create_hw_context(struct drm_i915_private *dev_priv,
struct drm_i915_file_private *file_priv)
{
struct i915_gem_context *ctx;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
int ret;
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
@@ -314,6 +329,13 @@ __create_hw_context(struct drm_i915_private *dev_priv,
* is no remap info, it will be a NOP. */
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
+ /* On all engines, use the whole device by default */
+ for_each_engine(engine, dev_priv, id) {
+ struct intel_context *ce = to_intel_context(ctx, engine);
+
+ ce->sseu =
intel_sseu_from_device_sseu(&INTEL_INFO(dev_priv)->sseu);
+ }
+
i915_gem_context_set_bannable(ctx);
ctx->ring_size = 4 * PAGE_SIZE;
ctx->desc_template =
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index ace3b129c189..cb9d93d29c64 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -30,6 +30,7 @@
#include
#include "i915_gem.h"
+#include "intel_device_info.h"
struct pid;
@@ -149,6 +150,8 @@ struct i915_gem_context {
u32 *lrc_reg_state;
u64 lrc_desc;
int pin_count;
+ /** sseu: Control eu/slice partitioning */
+ union intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index eddbd4245cb3..beb312ac9aa0 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -39,6 +39,19 @@ struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+union intel_sseu {
+ struct {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eus_per_subslice;
+ u8 max_eus_per_subslice;
+ };
+ u64 value;
+};
+
struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 1bc35de215ae..e754e9d112a5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2389,8 +2389,8 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
return logical_ring_init(engine);
}
-static u32
-make_rpcs(struct drm_i915_private *dev_priv)
+static u32 make_rpcs(const struct sseu_dev_info *sseu,
+union intel_sseu ctx_sseu)
{
u32 rpcs = 0;
@@ -2400,24 +2400,23 @@ make_rpcs(struct drm_i915_private *dev_priv)
* must make an explicit request through RPCS for full
* enablement.
*/
- if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
+ if (sseu->has_slice_pg) {
rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
+ rpcs |= hweight8(ctx_sseu.slice_mask) << GEN8_RPCS_S_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
[Intel-gfx] [PATCH v4 5/8] drm/i915: give engine to execlists cancel helper
We would like to set a value on the associated engine in this helper
in a following commit.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 10 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 2feb65096966..ef914fc926bb 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -794,7 +794,7 @@ static void guc_submission_tasklet(unsigned long data)
if (execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT) &&
intel_read_status_page(engine, I915_GEM_HWS_PREEMPT_INDEX) ==
GUC_PREEMPT_FINISHED) {
- execlists_cancel_port_requests(&engine->execlists);
+ execlists_cancel_port_requests(engine);
execlists_unwind_incomplete_requests(execlists);
wait_for_guc_preempt_report(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6fe0d668c023..a608ff0f9e7a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -772,8 +772,9 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
}
void
-execlists_cancel_port_requests(struct intel_engine_execlists * const execlists)
+execlists_cancel_port_requests(struct intel_engine_cs *engine)
{
+ struct intel_engine_execlists * const execlists = &engine->execlists;
struct execlist_port *port = execlists->port;
unsigned int num_ports = execlists_num_ports(execlists);
@@ -904,7 +905,7 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
local_irq_save(flags);
/* Cancel the requests on the HW and clear the ELSP tracker. */
- execlists_cancel_port_requests(execlists);
+ execlists_cancel_port_requests(engine);
reset_irq(engine);
spin_lock(&engine->timeline.lock);
@@ -1063,7 +1064,7 @@ static void execlists_submission_tasklet(unsigned long
data)
buf[2*head + 1] ==
execlists->preempt_complete_status) {
GEM_TRACE("%s preempt-idle\n", engine->name);
- execlists_cancel_port_requests(execlists);
+ execlists_cancel_port_requests(engine);
execlists_unwind_incomplete_requests(execlists);
GEM_BUG_ON(!execlists_is_active(execlists,
@@ -1823,7 +1824,6 @@ static int gen9_init_render_ring(struct intel_engine_cs
*engine)
static void reset_common_ring(struct intel_engine_cs *engine,
struct i915_request *request)
{
- struct intel_engine_execlists * const execlists = &engine->execlists;
unsigned long flags;
u32 *regs;
@@ -1843,7 +1843,7 @@ static void reset_common_ring(struct intel_engine_cs
*engine,
* guessing the missed context-switch events by looking at what
* requests were completed.
*/
- execlists_cancel_port_requests(execlists);
+ execlists_cancel_port_requests(engine);
reset_irq(engine);
/* Push back any incomplete requests for replay after the reset. */
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index aa643a1d69db..1d00cc3cc1a4 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -684,7 +684,7 @@ void execlists_user_begin(struct intel_engine_execlists
*execlists,
void execlists_user_end(struct intel_engine_execlists *execlists);
void
-execlists_cancel_port_requests(struct intel_engine_execlists * const
execlists);
+execlists_cancel_port_requests(struct intel_engine_cs *engine);
void
execlists_unwind_incomplete_requests(struct intel_engine_execlists *execlists);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 7/8] drm/i915: count powergating transitions per engine
This can be used to monitor the number of powergating transition
changes for a particular workload.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
drivers/gpu/drm/i915/intel_lrc.c| 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++
3 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1bab0447c9dc..c795a674abf0 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -505,6 +505,7 @@ void intel_engine_setup_common(struct intel_engine_cs
*engine)
i915_timeline_init(engine->i915, &engine->timeline, engine->name);
memset(&engine->last_sseu, 0, sizeof(engine->last_sseu));
+ atomic_set(&engine->sseu_transitions, 0);
intel_engine_init_execlist(engine);
intel_engine_init_hangcheck(engine);
@@ -1439,6 +1440,8 @@ void intel_engine_dump(struct intel_engine_cs *engine,
hexdump(m, engine->status_page.page_addr, PAGE_SIZE);
drm_printf(m, "Idle? %s\n", yesno(intel_engine_is_idle(engine)));
+
+ drm_printf(m, "Powergating transitions: %u\n",
atomic_read(&engine->sseu_transitions));
}
static u8 user_class_map[] = {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c9a51185b7fe..d0c429c4bd35 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -542,6 +542,7 @@ static void maybe_enable_noa_reprogram(struct i915_request
*rq)
*cs++ = upper_32_bits(engine->noa_reprogram_vma->node.start);
engine->last_sseu = rq->sseu;
+ atomic_inc(&engine->sseu_transitions);
}
static void port_assign(struct execlist_port *port, struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 955518a5396f..80819172619e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -357,6 +357,12 @@ struct intel_engine_cs {
*/
union intel_sseu last_sseu;
+ /**
+* @sseu_transitions: A counter of the number of powergating
+* transition this engine has gone through.
+*/
+ atomic_t sseu_transitions;
+
atomic_t irq_count;
unsigned long irq_posted;
#define ENGINE_IRQ_BREADCRUMB 0
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/8] drm/i915/perf: simplify configure all context function
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d9341415df40..5b279a82445a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1765,7 +1765,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
/* Switch away from any user context. */
ret = gen8_switch_to_updated_kernel_context(dev_priv, oa_config);
if (ret)
- goto out;
+ return ret;
/*
* The OA register config is setup through the context image. This image
@@ -1782,7 +1782,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
*/
ret = i915_gem_wait_for_idle(dev_priv, wait_flags);
if (ret)
- goto out;
+ return ret;
/* Update all contexts now that we've stalled the submission. */
list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
@@ -1794,10 +1794,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
continue;
regs = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
- if (IS_ERR(regs)) {
- ret = PTR_ERR(regs);
- goto out;
- }
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
ce->state->obj->mm.dirty = true;
regs += LRC_STATE_PN * PAGE_SIZE / sizeof(*regs);
@@ -1807,7 +1805,6 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
i915_gem_object_unpin_map(ce->state->obj);
}
- out:
return ret;
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/8] drm/i915: Program RPCS for Broadwell
From: Chris Wilson
Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may want to
opt out of the "always-enabled" setting.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_lrc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7f98dda3c929..1bc35de215ae 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2394,13 +2394,6 @@ make_rpcs(struct drm_i915_private *dev_priv)
{
u32 rpcs = 0;
- /*
-* No explicit RPCS request is needed to ensure full
-* slice/subslice/EU enablement prior to Gen9.
- */
- if (INTEL_GEN(dev_priv) < 9)
- return 0;
-
/*
* Starting in Gen9, render power gating can leave
* slice/subslice/EU in a partially enabled state. We
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/8] drm/i915: per context slice/subslice powergating
Hi all, Another update following Chris' review (Thanks!). A few more IGT tests to come to verify that interaction with perf. Cheers, Chris Wilson (3): drm/i915: Program RPCS for Broadwell drm/i915: Record the sseu configuration per-context & engine drm/i915: Expose RPCS (SSEU) configuration to userspace Lionel Landwerlin (5): drm/i915/perf: simplify configure all context function drm/i915: add new pipe control helper for mmio writes drm/i915: give engine to execlists cancel helper drm/i915: reprogram NOA muxes on context switch when using perf drm/i915: count powergating transitions per engine drivers/gpu/drm/i915/i915_gem_context.c | 173 drivers/gpu/drm/i915/i915_gem_context.h | 3 + drivers/gpu/drm/i915/i915_perf.c| 146 - drivers/gpu/drm/i915/i915_request.c | 2 + drivers/gpu/drm/i915/i915_request.h | 24 +++ drivers/gpu/drm/i915/intel_engine_cs.c | 5 + drivers/gpu/drm/i915/intel_guc_submission.c | 2 +- drivers/gpu/drm/i915/intel_lrc.c| 216 +++- drivers/gpu/drm/i915/intel_ringbuffer.c | 2 + drivers/gpu/drm/i915/intel_ringbuffer.h | 31 ++- include/uapi/drm/i915_drm.h | 38 11 files changed, 583 insertions(+), 59 deletions(-) -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.
The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.
We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,
struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .class = 0, instance =
0, };
memset(&arg, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t) &sseu;
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, &arg) == 0) {
sseu.packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &arg);
}
could be used to disable all subslices where supported.
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context (Chris)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
c: Dmitry Rogozhkin
CC: Tvrtko Ursulin
CC: Zhipeng Gong
CC: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 151
drivers/gpu/drm/i915/intel_lrc.c| 103 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
include/uapi/drm/i915_drm.h | 38 ++
5 files changed, 263 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index a04f0329e85a..6c67ef87b706 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -747,6 +747,92 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
return 0;
}
+static int
+intel_sseu_from_user_sseu(const struct sseu_dev_info *sseu,
+ const struct drm_i915_gem_context_param_sseu
*user_sseu,
+ union intel_sseu *ctx_sseu)
+{
+ if ((user_sseu->slice_mask & ~sseu->slice_mask) != 0 ||
+ user_sseu->slice_mask == 0)
+ return -EINVAL;
+
+ if ((user_sseu->subslice_mask & ~sseu->subslice_mask[0]) != 0 ||
+ user_sseu->subslice_mask == 0)
+ return -EINVAL;
+
+ if (user_sseu->min_eus_per_subslice > sseu->max_eus_per_subslice)
+ return -EINVAL;
+
+ if (user_sseu->max_eus_per_subslice > sseu->max_eus_per_subslice ||
+ user_sseu->max_eus_per_subslice < user_sseu->min_eus_per_subslice ||
+ user_sseu->max_eus_per_subslice == 0)
+ return -EINVAL;
+
+ ctx_sseu->slice_mask = user_sseu->slice_mask;
+ ctx_sseu->subslice_mask = user_sseu->subslice_mask;
+ ctx_sseu->min_eus_per_subslice = user_sseu->min_eus_per_subslice;
+ ctx_sseu->max_eus_per_subslice = user_sseu->max_eus_per_subslice;
+
+ return 0;
+}
+
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ union intel_sseu sseu)
+{
+ struct drm_i915_private *dev_priv = ctx->i915;
+ struct i915_timeline *timeline;
+ struct i915_request *rq;
+ enum intel_engine_id id;
+ int ret;
+
+ if (!engine->emit_rpcs_config)
+ return -ENODEV;
+
+ if (ctx->__engine[engine->id].sseu.value == sseu.value)
+ return 0;
+
+ lockdep_assert_held(&dev_priv->drm.struct_mutex);
+
+ i915_retire_requests(dev_priv);
+
+ /* Now use the RCS to actually reconfigure. */
+ engine = dev_priv->engine[RCS];
+
+ rq = i915_request_alloc(engine, dev_priv->kernel_context);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ ret = engine->emit_rpcs_config(rq, ctx, sseu);
+ if (ret) {
+ __i915_request_add(rq, true);
+ return ret;
+ }
+
+ /* Queue this switch after all other activity */
+ list
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915: Remove tasklet flush before disable
== Series Details == Series: series starting with [1/5] drm/i915: Remove tasklet flush before disable URL : https://patchwork.freedesktop.org/series/42950/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4163_full -> Patchwork_8963_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8963_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8963_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42950/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8963_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: SKIP -> PASS +3 igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: PASS -> SKIP +1 igt@kms_force_connector_basic@force-connector-state: shard-snb: PASS -> SKIP igt@kms_properties@plane-properties-legacy: shard-snb: SKIP -> PASS +4 == Known issues == Here are the changes found in Patchwork_8963_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@perf_pmu@enable-race-vcs0: shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) +1 igt@perf_pmu@enable-race-vecs0: shard-apl: PASS -> INCOMPLETE (fdo#103927) +1 shard-kbl: PASS -> INCOMPLETE (fdo#103665) +1 Possible fixes igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-apl: FAIL (fdo#105363, fdo#102887) -> PASS igt@kms_flip@wf_vblank-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS shard-apl: FAIL (fdo#100368) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4163 -> Patchwork_8963 CI_DRM_4163: 8e1dab6e913be7d014eb9bc355ec65b6b56dcd56 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8963: 5eb66ebc88e5235c97725e9d0dc08d1f6820aed0 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8963/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
On Wed, May 09, 2018 at 10:13:21AM +0300, Jani Nikula wrote:
> We've opted to use the maximum link rate and lane count for eDP panels,
> because typically the maximum supported configuration reported by the
> panel has matched the native resolution requirements of the panel, and
> optimizing the link has lead to problems.
>
> With eDP 1.4 rate select method and DSC features, this is decreasingly
> the case. There's a need to optimize the link parameters. Moreover,
> already eDP 1.3 states fast link with fewer lanes is preferred over the
> wide and slow. (Wide and slow should still be more reliable for longer
> cable lengths.)
>
> Additionally, there have been reports of panels failing on arbitrary
> link configurations, although arguably all configurations they claim to
> support should work.
>
> Optimize eDP 1.4+ link config fast and narrow.
>
> Side note: The implementation has a near duplicate of the link config
> function, with just the two inner for loops turned inside out. Perhaps
> there'd be a way to make this, say, more table driven to reduce the
> duplication, but seems like that would lead to duplication in the table
> generation. We'll also have to see how the link config optimization for
> DSC turns out.
Yes for DSC for eDP we currently try fast and wide and if that doesnt
fit the requested mode then we enable DSC.
Now with the fast and narrow approach, again for power savings we can try
the fastest link rate with narrowest lane count and see if DSC can be enabled
there before increasing the lane count. But anyways that calls for a separate
optimization discussion.
Otherwise yes this method looks correct as per eDP 1.4 spec.
>
> Cc: Ville Syrjälä
> Cc: Manasi Navare
> Cc: Rodrigo Vivi
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> Signed-off-by: Jani Nikula
>
> ---
>
> Untested. It's possible this helps the referenced bug. The downside is
> that this patch has a bunch of dependencies that are too much to
> backport to stable kernels. If the patch works, we may need to consider
> hacking together an uglier backport.
> ---
> drivers/gpu/drm/i915/intel_dp.c | 73
> ++---
> 1 file changed, 62 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..1ec62965ece3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1768,6 +1768,42 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> return false;
> }
>
> +/* Optimize link config in order: max bpp, min lanes, min clock */
> +static bool
> +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> + struct intel_crtc_state *pipe_config,
> + const struct link_config_limits *limits)
Should we make the name of this function
intel_dp_compute_link_config_fast_narrow() to make it
more intuitive to the optimization approach
And while at it change the other one also to _wide_slow()?
Just a suggestion but otherwise everything else LGTM.
Regards
Manasi
> +{
> + struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
> + int bpp, clock, lane_count;
> + int mode_rate, link_clock, link_avail;
> +
> + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> + mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> +bpp);
> +
> + for (lane_count = limits->min_lane_count;
> + lane_count <= limits->max_lane_count;
> + lane_count <<= 1) {
> + for (clock = limits->min_clock; clock <=
> limits->max_clock; clock++) {
> + link_clock = intel_dp->common_rates[clock];
> + link_avail = intel_dp_max_data_rate(link_clock,
> + lane_count);
> +
> + if (mode_rate <= link_avail) {
> + pipe_config->lane_count = lane_count;
> + pipe_config->pipe_bpp = bpp;
> + pipe_config->port_clock = link_clock;
> +
> + return true;
> + }
> + }
> + }
> + }
> +
> + return false;
> +}
> +
> static bool
> intel_dp_compute_link_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config)
> @@ -1792,13 +1828,15 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> limits.min_bpp = 6 * 3;
> limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>
> - if (intel_dp_is_edp(intel_dp)) {
> + if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
> /*
>* Use the m
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: per context slice/subslice powergating (rev3)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev3) URL : https://patchwork.freedesktop.org/series/42285/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh DESCEND objtool CHK scripts/mod/devicetable-offsets.h CHK include/generated/compile.h CHK kernel/config_data.h CC [M] drivers/gpu/drm/i915/i915_perf.o drivers/gpu/drm/i915/i915_perf.c: In function ‘alloc_noa_reprogram_bo’: drivers/gpu/drm/i915/i915_perf.c:1774:25: error: macro "IS_GEN8" passed 2 arguments, but takes just 1 if (IS_GEN8(dev_priv, 8)) ^ drivers/gpu/drm/i915/i915_perf.c:1774:6: error: ‘IS_GEN8’ undeclared (first use in this function); did you mean ‘IS_ERR’? if (IS_GEN8(dev_priv, 8)) ^~~ IS_ERR drivers/gpu/drm/i915/i915_perf.c:1774:6: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:312: recipe for target 'drivers/gpu/drm/i915/i915_perf.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_perf.o] Error 1 scripts/Makefile.build:559: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:559: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:559: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1060: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v14 10/10] drm: Add and handle new aspect ratios in DRM layer
On Tue, May 08, 2018 at 04:39:45PM +0530, Nautiyal, Ankit K wrote:
> From: "Sharma, Shashank"
>
> HDMI 2.0/CEA-861-F introduces two new aspect ratios:
> - 64:27
> - 256:135
>
> This patch:
> - Adds new DRM flags for to represent these new aspect ratios.
> - Adds new cases to handle these aspect ratios while converting
> from user->kernel mode or vise versa.
>
> This patch was once reviewed and merged, and later reverted due
> to lack of DRM client protection, while adding aspect ratio bits
> in user modes. This is a re-spin of the series, with DRM client
> cap protection.
>
> The previous series can be found here:
> https://pw-emeril.freedesktop.org/series/10850/
>
> Signed-off-by: Shashank Sharma
> Reviewed-by: Sean Paul (V2)
> Reviewed-by: Jose Abreu (V2)
>
> Cc: Ville Syrjala
> Cc: Sean Paul
> Cc: Jose Abreu
> Cc: Ankit Nautiyal
Since I bikeshedded the drm core bits and they all look good now imo, on
patches 6-10:
Acked-by: Daniel Vetter
>
> V3: rebase
> V4: rebase
> V5: corrected the macro name for an aspect ratio, in a switch case.
> V6: rebase
> V7: rebase
> V8: rebase
> V9: rebase
> V10: rebase
> V11: rebase
> V12: rebase
> V13: rebase
> V14: rebase
> ---
> drivers/gpu/drm/drm_modes.c | 12
> include/uapi/drm/drm_mode.h | 6 ++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 7dfabdd..c78ca0e 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1656,6 +1656,12 @@ void drm_mode_convert_to_umode(struct
> drm_mode_modeinfo *out,
> case HDMI_PICTURE_ASPECT_16_9:
> out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> break;
> + case HDMI_PICTURE_ASPECT_64_27:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
> + break;
> + case HDMI_PICTURE_ASPECT_256_135:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
> + break;
> case HDMI_PICTURE_ASPECT_RESERVED:
> default:
> out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> @@ -1721,6 +1727,12 @@ int drm_mode_convert_umode(struct drm_device *dev,
> case DRM_MODE_FLAG_PIC_AR_16_9:
> out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> break;
> + case DRM_MODE_FLAG_PIC_AR_64_27:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
> + break;
> + case DRM_MODE_FLAG_PIC_AR_256_135:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
> + break;
> default:
> out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> break;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 50bcf42..4b3a1bb 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -93,6 +93,8 @@ extern "C" {
> #define DRM_MODE_PICTURE_ASPECT_NONE 0
> #define DRM_MODE_PICTURE_ASPECT_4_3 1
> #define DRM_MODE_PICTURE_ASPECT_16_9 2
> +#define DRM_MODE_PICTURE_ASPECT_64_273
> +#define DRM_MODE_PICTURE_ASPECT_256_135 4
>
> /* Aspect ratio flag bitmask (4 bits 22:19) */
> #define DRM_MODE_FLAG_PIC_AR_MASK(0x0F<<19)
> @@ -102,6 +104,10 @@ extern "C" {
> (DRM_MODE_PICTURE_ASPECT_4_3<<19)
> #define DRM_MODE_FLAG_PIC_AR_16_9 \
> (DRM_MODE_PICTURE_ASPECT_16_9<<19)
> +#define DRM_MODE_FLAG_PIC_AR_64_27 \
> + (DRM_MODE_PICTURE_ASPECT_64_27<<19)
> +#define DRM_MODE_FLAG_PIC_AR_256_135 \
> + (DRM_MODE_PICTURE_ASPECT_256_135<<19)
>
> #define DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
>DRM_MODE_FLAG_NHSYNC | \
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, This weeks fixes is a little busier than normal, due to the omap changes. However since these aren't regressions, it shouldn't be something to be concerned about. drm-misc-fixes-2018-05-09: atomic: Clear state pointers on clear (Ville) vc4: Fix oops in dpi disable (Eric) omap: Various error-checking + uninitialized var fixes (Tomi) Cc: Ville Syrjälä Cc: Eric Anholt Cc: Tomi Valkeinen Cheers, Sean The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb: Linux 4.17-rc4 (2018-05-06 16:57:38 -1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-05-09 for you to fetch changes up to 9a0e9802217291e54c4dd1fc5462f189a4be14ec: drm/vc4: Fix scaling of uni-planar formats (2018-05-09 09:48:23 +0200) atomic: Clear state pointers on clear (Ville) vc4: Fix oops in dpi disable (Eric) omap: Various error-checking + uninitialized var fixes (Tomi) Cc: Ville Syrjälä Cc: Eric Anholt Cc: Tomi Valkeinen Andrzej Hajda (1): drm/bridge/sii8620: add Kconfig dependency on extcon Boris Brezillon (1): drm/vc4: Fix scaling of uni-planar formats Dan Carpenter (1): drm/omap: silence unititialized variable warning Eric Anholt (1): drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge. Tomi Valkeinen (6): drm/omap: fix uninitialized ret variable drm/omap: fix possible NULL ref issue in tiler_reserve_2d drm/omap: check return value from soc_device_match drm/omap: handle error if scale coefs are not found drm/omap: add missing linefeeds to prints drm/omap: handle alloc failures in omap_connector Ville Syrjälä (2): drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear() drm/atomic: Clean private obj old_state/new_state in drm_atomic_state_default_clear() drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/drm_atomic.c | 8 drivers/gpu/drm/omapdrm/dss/dispc.c | 20 +--- drivers/gpu/drm/omapdrm/dss/hdmi4.c | 2 +- drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 7 ++- drivers/gpu/drm/omapdrm/dss/hdmi5.c | 2 +- drivers/gpu/drm/omapdrm/omap_connector.c | 10 ++ drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 6 +- drivers/gpu/drm/omapdrm/tcm-sita.c | 2 +- drivers/gpu/drm/vc4/vc4_dpi.c| 25 ++--- drivers/gpu/drm/vc4/vc4_plane.c | 2 +- 11 files changed, 69 insertions(+), 16 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dim: replace pipe commands with single sed
A single sed can do the job of taking the second line after a match and
it looks simpler.
Signed-off-by: Lucas De Marchi
---
I noticed this while reviewing "[PATCH 2/4] dim: shut up sed broken pipe
noise in apply-pull".
dim | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dim b/dim
index 6b684ba5308c..f7cf255db3e1 100755
--- a/dim
+++ b/dim
@@ -924,7 +924,7 @@ function dim_apply_pull
cat > $file
- pull_branch=$(sed -e '0,/[gG]it repository at:$/d' $file | head -n 2 |
tail -n 1)
+ pull_branch=$(sed -ne '/[gG]it repository at:$/{n;n;p}' $file)
if [[ -z "$pull_branch" ]] ; then
echoerr "no pull request found"
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
