[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim
== Series Details == Series: series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/53953/ State : success == Summary == CI Bug Log - changes from CI_DRM_5296_full -> Patchwork_11077_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11077_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11077_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11077_full: ### IGT changes ### Warnings * igt@kms_draw_crc@draw-method-xrgb-pwrite-xtiled: - shard-snb: PASS -> SKIP +2 * igt@tools_test@tools_test: - shard-skl: SKIP -> PASS Known issues Here are the changes found in Patchwork_11077_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@normal: - shard-skl: PASS -> TIMEOUT [fdo#108592] * igt@i915_selftest@live_contexts: - shard-iclb: NOTRUN -> DMESG-FAIL [fdo#108569] * igt@kms_atomic_transition@plane-toggle-modeset-transition: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +12 * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-iclb: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-glk: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_chv_cursor_fail@pipe-b-256x256-right-edge: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +5 * igt@kms_color@pipe-a-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] / [fdo#108145] * igt@kms_cursor_crc@cursor-128x42-sliding: - shard-glk: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x85-random: - shard-apl: PASS -> FAIL [fdo#103232] +5 * igt@kms_fbcon_fbt@fbc-suspend: - shard-glk: PASS -> FAIL [fdo#103833] / [fdo#105681] * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite: - shard-glk: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-cpu: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +4 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render: - shard-iclb: PASS -> FAIL [fdo#103167] +3 * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-apl: PASS -> FAIL [fdo#108948] * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-apl: PASS -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-c-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_psr@no_drrs: - shard-iclb: PASS -> FAIL [fdo#108341] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-glk: PASS -> DMESG-FAIL [fdo#105763] / [fdo#106538] * igt@kms_sysfs_edid_timing: - shard-skl: NOTRUN -> FAIL [fdo#100047] * igt@pm_rpm@gem-execbuf: - shard-skl: PASS -> INCOMPLETE [fdo#107803] / [fdo#107807] * igt@pm_rpm@gem-execbuf-stress-extra-wait: - shard-iclb: PASS -> INCOMPLETE [fdo#108840] Possible fixes * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-glk: DMESG-WARN [fdo#107956] -> PASS * igt@kms_color@pipe-b-ctm-negative: - shard-skl: FAIL [fdo#107361] -> PASS * igt@kms_cursor_crc@cursor-256x256-dpms: - shard-apl: FAIL [fdo#103232] -> PASS * igt@kms_cursor_crc@cursor-256x85-onscreen: - shard-glk: FAIL [fdo#103232] -> PASS * igt@kms_draw_crc@draw-method-rgb565-render-ytiled: - shard-iclb: WARN [fdo#108336] -> PASS +1 * igt@kms_flip@dpms-off-confusion: - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +23 * igt@kms_flip_tiling@flip-changes-tiling: - shard-iclb: DMESG-WARN [fdo#107724] / [fdo#108336] -> PASS +10 * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite: -
Re: [Intel-gfx] [PATCH 07/19] drm/i915/icl: Mind the SFC units when resetting VD or VEBox engines
On 12/12/2018 13:41, Chris Wilson wrote:
From: Oscar Mateo
SFC (Scaler & Format Converter) units are shared between VD and VEBoxes.
They also happen to have separate reset bits. So, whenever we want to reset
one or more of the media engines, we have to make sure the SFCs do not
change owner in the process and, if this owner happens to be one of the
engines being reset, we need to reset the SFC as well.
This happens in 4 steps:
1) Tell the engine that a software reset is going to happen. The engine
will then try to force lock the SFC (if currently locked, it will
remain so; if currently unlocked, it will ignore this and all new lock
requests).
2) Poll the ack bit to make sure the hardware has received the forced
lock from the driver. Once this bit is set, it indicates SFC status
(lock or unlock) will not change anymore (until we tell the engine it
is safe to unlock again).
3) Check the usage bit to see if the SFC has ended up being locked to
the engine we want to reset. If this is the case, we have to reset
the SFC as well.
4) Unlock all the SFCs once the reset sequence is completed.
Obviously, if we are resetting the whole GPU, we don't have to worry
about all of this.
BSpec: 10989
BSpec: 10990
BSpec: 10954
BSpec: 10955
BSpec: 10956
BSpec: 19212
Signed-off-by: Tomasz Lis
Signed-off-by: Oscar Mateo
Signed-off-by: Michel Thierry
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reg.h | 18 +
drivers/gpu/drm/i915/intel_uncore.c | 115 ++--
2 files changed, 128 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0a7d60509ca7..0796526dc10f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -347,6 +347,24 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GEN11_GRDOM_MEDIA4 (1 << 8)
#define GEN11_GRDOM_VECS (1 << 13)
#define GEN11_GRDOM_VECS2(1 << 14)
+#define GEN11_GRDOM_SFC0 (1 << 17)
+#define GEN11_GRDOM_SFC1 (1 << 18)
+
+#define GEN11_VCS_SFC_RESET_BIT(instance) (GEN11_GRDOM_SFC0 << ((instance)
>> 1))
+#define GEN11_VECS_SFC_RESET_BIT(instance)(GEN11_GRDOM_SFC0 << (instance))
+
+#define GEN11_VCS_SFC_FORCED_LOCK(engine) _MMIO((engine)->mmio_base +
0x88C)
+#define GEN11_VCS_SFC_FORCED_LOCK_BIT(1 << 0)
+#define GEN11_VCS_SFC_LOCK_STATUS(engine) _MMIO((engine)->mmio_base +
0x890)
+#define GEN11_VCS_SFC_USAGE_BIT (1 << 0)
+#define GEN11_VCS_SFC_LOCK_ACK_BIT (1 << 1)
+
+#define GEN11_VECS_SFC_FORCED_LOCK(engine) _MMIO((engine)->mmio_base +
0x201C)
+#define GEN11_VECS_SFC_FORCED_LOCK_BIT (1 << 0)
+#define GEN11_VECS_SFC_LOCK_ACK(engine)
_MMIO((engine)->mmio_base + 0x2018)
+#define GEN11_VECS_SFC_LOCK_ACK_BIT (1 << 0)
+#define GEN11_VECS_SFC_USAGE(engine) _MMIO((engine)->mmio_base +
0x2014)
+#define GEN11_VECS_SFC_USAGE_BIT (1 << 0)
#define RING_PP_DIR_BASE(engine) _MMIO((engine)->mmio_base + 0x228)
#define RING_PP_DIR_BASE_READ(engine) _MMIO((engine)->mmio_base + 0x518)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 9289515108c3..408692b88c98 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1931,6 +1931,103 @@ static int gen6_reset_engines(struct drm_i915_private
*dev_priv,
return gen6_hw_domain_reset(dev_priv, hw_mask);
}
+static u32 gen11_lock_sfc(struct drm_i915_private *dev_priv,
+ struct intel_engine_cs *engine)
+{
+ u8 vdbox_sfc_access = INTEL_INFO(dev_priv)->vdbox_sfc_access;
Only a single use site so could get away with a local copy.
+ i915_reg_t sfc_forced_lock, sfc_forced_lock_ack;
+ u32 sfc_forced_lock_bit, sfc_forced_lock_ack_bit;
+ i915_reg_t sfc_usage;
+ u32 sfc_usage_bit;
+ u32 sfc_reset_bit;
+
+ switch (engine->class) {
+ case VIDEO_DECODE_CLASS:
+ if ((BIT(engine->instance) & vdbox_sfc_access) == 0)
+ return 0;
+
+ sfc_forced_lock = GEN11_VCS_SFC_FORCED_LOCK(engine);
+ sfc_forced_lock_bit = GEN11_VCS_SFC_FORCED_LOCK_BIT;
+
+ sfc_forced_lock_ack = GEN11_VCS_SFC_LOCK_STATUS(engine);
+ sfc_forced_lock_ack_bit = GEN11_VCS_SFC_LOCK_ACK_BIT;
+
+ sfc_usage = GEN11_VCS_SFC_LOCK_STATUS(engine);
+ sfc_usage_bit = GEN11_VCS_SFC_USAGE_BIT;
+ sfc_reset_bit = GEN11_VCS_SFC_RESET_BIT(engine->instance);
+ break;
+
+ case VIDEO_ENHANCEMENT_CLASS:
+ sfc_forced_lock = GEN11_VECS_SFC_FORCED_LOCK(engine);
+ sfc_forced_lock_bit = GEN11_VECS_SFC_FORCED_LOCK_BIT;
+
+
[Intel-gfx] [PATCH 4/6] drm/i915: Remove gen6_check_mch_setup()
From: Ville Syrjälä
snb_wm_latency_quirk() already boosts up the latency values
so the extra warning about the SSKPD value being insufficient
is now redundant. Drop it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 --
drivers/gpu/drm/i915/intel_pm.c | 14 --
2 files changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0a7d60509ca7..9dce09ed47f7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3538,8 +3538,6 @@ enum i915_power_well_id {
/* snb MCH registers for priority tuning */
#define MCH_SSKPD _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5d10)
-#define MCH_SSKPD_WM0_MASK 0x3f
-#define MCH_SSKPD_WM0_VAL0xc
#define MCH_SECP_NRG_STTS _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x592c)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d5ad84be769d..1a9ad431efbd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8612,16 +8612,6 @@ static void cpt_init_clock_gating(struct
drm_i915_private *dev_priv)
}
}
-static void gen6_check_mch_setup(struct drm_i915_private *dev_priv)
-{
- uint32_t tmp;
-
- tmp = I915_READ(MCH_SSKPD);
- if ((tmp & MCH_SSKPD_WM0_MASK) != MCH_SSKPD_WM0_VAL)
- DRM_DEBUG_KMS("Wrong MCH_SSKPD value: 0x%08x This can cause
underruns.\n",
- tmp);
-}
-
static void gen6_init_clock_gating(struct drm_i915_private *dev_priv)
{
uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE;
@@ -8712,8 +8702,6 @@ static void gen6_init_clock_gating(struct
drm_i915_private *dev_priv)
g4x_disable_trickle_feed(dev_priv);
cpt_init_clock_gating(dev_priv);
-
- gen6_check_mch_setup(dev_priv);
}
static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv)
@@ -9081,8 +9069,6 @@ static void ivb_init_clock_gating(struct drm_i915_private
*dev_priv)
if (!HAS_PCH_NOP(dev_priv))
cpt_init_clock_gating(dev_priv);
-
- gen6_check_mch_setup(dev_priv);
}
static void vlv_init_clock_gating(struct drm_i915_private *dev_priv)
--
2.18.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915: Use _MMIO_PIPE3() for ilk+ WM0_PIPE registers
From: Ville Syrjälä
Remove the hand rolled array of WM0_PIPE register offsets
and use the standard _MMIO_PIPE3() instead.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 9 +
drivers/gpu/drm/i915/intel_pm.c | 13 -
2 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ea9a664980a6..246e5e77e7c5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5992,15 +5992,16 @@ enum {
_MMIO(_PLANE(plane, _PLANE_WM_TRANS_1(pipe), _PLANE_WM_TRANS_2(pipe)))
/* define the Watermark register on Ironlake */
-#define WM0_PIPEA_ILK _MMIO(0x45100)
+#define _WM0_PIPEA_ILK 0x45100
+#define _WM0_PIPEB_ILK 0x45104
+#define _WM0_PIPEC_IVB 0x45200
+#define WM0_PIPE_ILK(pipe) _MMIO_PIPE3((pipe), _WM0_PIPEA_ILK, \
+ _WM0_PIPEB_ILK, _WM0_PIPEC_IVB)
#define WM0_PIPE_PLANE_MASK (0x << 16)
#define WM0_PIPE_PLANE_SHIFT 16
#define WM0_PIPE_SPRITE_MASK (0xff << 8)
#define WM0_PIPE_SPRITE_SHIFT 8
#define WM0_PIPE_CURSOR_MASK (0xff)
-
-#define WM0_PIPEB_ILK _MMIO(0x45104)
-#define WM0_PIPEC_IVB _MMIO(0x45200)
#define WM1_LP_ILK _MMIO(0x45108)
#define WM1_LP_SR_EN (1 << 31)
#define WM1_LP_LATENCY_SHIFT 24
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6ebde7bbac4e..46f8c8728847 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3555,11 +3555,11 @@ static void ilk_write_wm_values(struct drm_i915_private
*dev_priv,
_ilk_disable_lp_wm(dev_priv, dirty);
if (dirty & WM_DIRTY_PIPE(PIPE_A))
- I915_WRITE(WM0_PIPEA_ILK, results->wm_pipe[0]);
+ I915_WRITE(WM0_PIPE_ILK(PIPE_A), results->wm_pipe[0]);
if (dirty & WM_DIRTY_PIPE(PIPE_B))
- I915_WRITE(WM0_PIPEB_ILK, results->wm_pipe[1]);
+ I915_WRITE(WM0_PIPE_ILK(PIPE_B), results->wm_pipe[1]);
if (dirty & WM_DIRTY_PIPE(PIPE_C))
- I915_WRITE(WM0_PIPEC_IVB, results->wm_pipe[2]);
+ I915_WRITE(WM0_PIPE_ILK(PIPE_C), results->wm_pipe[2]);
if (dirty & WM_DIRTY_LINETIME(PIPE_A))
I915_WRITE(PIPE_WM_LINETIME(PIPE_A), results->wm_linetime[0]);
@@ -5647,13 +5647,8 @@ static void ilk_pipe_wm_get_hw_state(struct intel_crtc
*crtc)
struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->base.state);
struct ilk_pipe_wm *active = >wm.ilk.optimal;
enum pipe pipe = crtc->pipe;
- static const i915_reg_t wm0_pipe_reg[] = {
- [PIPE_A] = WM0_PIPEA_ILK,
- [PIPE_B] = WM0_PIPEB_ILK,
- [PIPE_C] = WM0_PIPEC_IVB,
- };
- hw->wm_pipe[pipe] = I915_READ(wm0_pipe_reg[pipe]);
+ hw->wm_pipe[pipe] = I915_READ(WM0_PIPE_ILK(pipe));
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
hw->wm_linetime[pipe] = I915_READ(PIPE_WM_LINETIME(pipe));
--
2.18.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't forget to reset blocks when testing lower wm levels
On Wed, Dec 12, 2018 at 09:23:38PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 12, 2018 at 11:17:20AM -0800, Matt Roper wrote:
> > During DDB allocation, we try to distribute enough blocks for each plane
> > to hit the highest watermark level; if that fails, we retry each lower
> > level (which should require fewer blocks) until we find one that's
> > possible (or until the whole commit is rejected as impossible). We need
> > to reset our running block count when trying each lower level, otherwise
> > all lower levels will fail as well.
> >
> > Cc: Ville Syrjälä
> > Fixes: d8e8749802 ("drm/i915: Switch to level-based DDB allocation
> > algorithm (v5)")
> > Signed-off-by: Matt Roper
>
> Whoops.
>
> Reviewed-by: Ville Syrjälä
Pushed to dinq. Thanks for the quick review!
Matt
>
> > ---
> > After waiting for CI results to come out, I accidentally pushed v5 of
> > the new DDB algorithm rather than the expected v6. This fixup patch is
> > the only difference between those two versions.
> >
> > drivers/gpu/drm/i915/intel_pm.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 6d074f2e69d3..a6c7c11d2c0e 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4365,6 +4365,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
> > * requirement of active planes.
> > */
> > for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
> > + blocks = 0;
> > for_each_plane_id_on_crtc(intel_crtc, plane_id) {
> > if (plane_id == PLANE_CURSOR)
> > continue;
> > --
> > 2.14.4
>
> --
> Ville Syrjälä
> Intel
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Rename ilk watermark structs/enums
From: Ville Syrjälä
Rename all the watermark related structs/enums specific to ilk-bdw
to have an ilk_ prefix rather than an intel_ prefix. Should make it
less confusing for everyone when it's clear where these things
get used.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 12 ++--
drivers/gpu/drm/i915/intel_drv.h | 10 ++--
drivers/gpu/drm/i915/intel_pm.c | 96
3 files changed, 58 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9264fd1b8662..95231f5f813d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1024,12 +1024,12 @@ struct intel_vbt_data {
struct sdvo_device_mapping sdvo_mappings[2];
};
-enum intel_ddb_partitioning {
- INTEL_DDB_PART_1_2,
- INTEL_DDB_PART_5_6, /* IVB+ */
+enum ilk_ddb_partitioning {
+ ILK_DDB_PART_1_2,
+ ILK_DDB_PART_5_6, /* IVB+ */
};
-struct intel_wm_level {
+struct ilk_wm_level {
bool enable;
u16 pri_val;
u16 spr_val;
@@ -1043,7 +1043,7 @@ struct ilk_wm_values {
u32 wm_lp_spr[3];
u32 wm_linetime[3];
bool enable_fbc_wm;
- enum intel_ddb_partitioning partitioning;
+ enum ilk_ddb_partitioning partitioning;
};
struct g4x_pipe_wm {
@@ -1195,7 +1195,7 @@ struct i915_virtual_gpu {
};
/* used in computing the new watermarks state */
-struct intel_wm_config {
+struct ilk_wm_config {
unsigned int num_pipes_active;
bool sprites_enabled;
bool sprites_scaled;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 09abc1035335..cc4d8d8382b6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -628,8 +628,8 @@ struct intel_crtc_scaler_state {
/* Flag to get scanline using frame time stamps */
#define I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP (1<<1)
-struct intel_pipe_wm {
- struct intel_wm_level wm[5];
+struct ilk_pipe_wm {
+ struct ilk_wm_level wm[5];
u32 linetime;
bool fbc_wm_enabled;
bool pipe_enabled;
@@ -693,13 +693,13 @@ struct intel_crtc_wm_state {
* switching away from and the new
* configuration we're switching to.
*/
- struct intel_pipe_wm intermediate;
+ struct ilk_pipe_wm intermediate;
/*
* Optimal watermarks, programmed post-vblank
* when this state is committed.
*/
- struct intel_pipe_wm optimal;
+ struct ilk_pipe_wm optimal;
} ilk;
struct {
@@ -982,7 +982,7 @@ struct intel_crtc {
struct {
/* watermarks currently being used */
union {
- struct intel_pipe_wm ilk;
+ struct ilk_pipe_wm ilk;
struct vlv_wm_state vlv;
struct g4x_wm_state g4x;
} active;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f23ea4631f9b..6328f0f8aa88 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2485,8 +2485,7 @@ struct ilk_wm_maximums {
*/
static u16 ilk_compute_pri_wm(const struct intel_crtc_state *cstate,
const struct intel_plane_state *pstate,
- unsigned int mem_value,
- bool is_lp)
+ unsigned int mem_value, bool is_lp)
{
u16 method1, method2;
int cpp;
@@ -2623,8 +2622,8 @@ static u16 ilk_fbc_wm_reg_max(const struct
drm_i915_private *dev_priv)
/* Calculate the maximum primary/sprite plane watermark */
static u16 ilk_plane_wm_max(const struct drm_i915_private *dev_priv,
int level,
- const struct intel_wm_config *config,
- enum intel_ddb_partitioning ddb_partitioning,
+ const struct ilk_wm_config *config,
+ enum ilk_ddb_partitioning ddb_partitioning,
bool is_sprite)
{
u16 fifo_size = ilk_display_fifo_size(dev_priv);
@@ -2648,7 +2647,7 @@ static u16 ilk_plane_wm_max(const struct drm_i915_private
*dev_priv,
if (config->sprites_enabled) {
/* level 0 is always calculated with 1:1 split */
- if (level > 0 && ddb_partitioning == INTEL_DDB_PART_5_6) {
+ if (level > 0 && ddb_partitioning == ILK_DDB_PART_5_6) {
if (is_sprite)
fifo_size *= 5;
fifo_size /= 6;
@@ -2664,7 +2663,7 @@ static u16 ilk_plane_wm_max(const struct drm_i915_private
*dev_priv,
/* Calculate the
[Intel-gfx] [PATCH 1/6] drm/i915: Shrink ilk-bdw wm storage by using u16
From: Ville Syrjälä
The maximum watermark value we can ever have on ilk-bdw is
11 bits. Thus we can safely store all of these values in
u16.
Also toss in a few s/uint16_t/u16/ etc. while at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 16 ++---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 101 +++
3 files changed, 58 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e70707e79386..9264fd1b8662 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1031,17 +1031,17 @@ enum intel_ddb_partitioning {
struct intel_wm_level {
bool enable;
- uint32_t pri_val;
- uint32_t spr_val;
- uint32_t cur_val;
- uint32_t fbc_val;
+ u16 pri_val;
+ u16 spr_val;
+ u16 cur_val;
+ u16 fbc_val;
};
struct ilk_wm_values {
- uint32_t wm_pipe[3];
- uint32_t wm_lp[3];
- uint32_t wm_lp_spr[3];
- uint32_t wm_linetime[3];
+ u32 wm_pipe[3];
+ u32 wm_lp[3];
+ u32 wm_lp_spr[3];
+ u32 wm_linetime[3];
bool enable_fbc_wm;
enum intel_ddb_partitioning partitioning;
};
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d08f08f607dd..09abc1035335 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -630,7 +630,7 @@ struct intel_crtc_scaler_state {
struct intel_pipe_wm {
struct intel_wm_level wm[5];
- uint32_t linetime;
+ u32 linetime;
bool fbc_wm_enabled;
bool pipe_enabled;
bool sprites_enabled;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6d074f2e69d3..f23ea4631f9b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1188,9 +1188,9 @@ static bool g4x_raw_fbc_wm_set(struct intel_crtc_state
*crtc_state,
return dirty;
}
-static uint32_t ilk_compute_fbc_wm(const struct intel_crtc_state *cstate,
- const struct intel_plane_state *pstate,
- uint32_t pri_val);
+static u16 ilk_compute_fbc_wm(const struct intel_crtc_state *cstate,
+ const struct intel_plane_state *pstate,
+ u16 pri_val);
static bool g4x_raw_plane_wm_compute(struct intel_crtc_state *crtc_state,
const struct intel_plane_state
*plane_state)
@@ -2436,7 +2436,7 @@ static unsigned int ilk_wm_method1(unsigned int
pixel_rate,
ret = intel_wm_method1(pixel_rate, cpp, latency);
ret = DIV_ROUND_UP(ret, 64) + 2;
- return ret;
+ return min_t(unsigned int, ret, USHRT_MAX);
}
/* latency must be in 0.1us units. */
@@ -2452,11 +2452,11 @@ static unsigned int ilk_wm_method2(unsigned int
pixel_rate,
width, cpp, latency);
ret = DIV_ROUND_UP(ret, 64) + 2;
- return ret;
+ return min_t(unsigned int, ret, USHRT_MAX);
}
-static uint32_t ilk_wm_fbc(uint32_t pri_val, uint32_t horiz_pixels,
- uint8_t cpp)
+static u16 ilk_wm_fbc(u16 pri_val, unsigned int horiz_pixels,
+ unsigned int cpp)
{
/*
* Neither of these should be possible since this function shouldn't be
@@ -2473,26 +2473,26 @@ static uint32_t ilk_wm_fbc(uint32_t pri_val, uint32_t
horiz_pixels,
}
struct ilk_wm_maximums {
- uint16_t pri;
- uint16_t spr;
- uint16_t cur;
- uint16_t fbc;
+ u16 pri;
+ u16 spr;
+ u16 cur;
+ u16 fbc;
};
/*
* For both WM_PIPE and WM_LP.
* mem_value must be in 0.1us units.
*/
-static uint32_t ilk_compute_pri_wm(const struct intel_crtc_state *cstate,
- const struct intel_plane_state *pstate,
- uint32_t mem_value,
- bool is_lp)
+static u16 ilk_compute_pri_wm(const struct intel_crtc_state *cstate,
+ const struct intel_plane_state *pstate,
+ unsigned int mem_value,
+ bool is_lp)
{
- uint32_t method1, method2;
+ u16 method1, method2;
int cpp;
if (mem_value == 0)
- return U32_MAX;
+ return U16_MAX;
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
@@ -2516,15 +2516,15 @@ static uint32_t ilk_compute_pri_wm(const struct
intel_crtc_state *cstate,
* For both WM_PIPE and WM_LP.
* mem_value must be in 0.1us units.
*/
-static uint32_t ilk_compute_spr_wm(const struct intel_crtc_state *cstate,
- const struct intel_plane_state *pstate,
- uint32_t mem_value)
+static u16 ilk_compute_spr_wm(const struct intel_crtc_state
[Intel-gfx] [PATCH 3/6] drm/i915: Stash away the original SSKPD latency values
From: Ville Syrjälä
On ILK-IVB we must write the latency value read from SSKPD into
the latency field in the WM_LP registers. While bspec was never
clear on how the punit (or whatever) interprets these values
empirical evidence has shown that these are treated as a cookie
rather than as a literal latency value. That is, if we write a
value that we didn't get from SSKPD (just off by one is sufficient)
the system no longer appears to enter the corresponding power
saving state.
This was made much more obvious on HSW/BDW since there we longer
write the latency value into the WM_LP registers, and rather we
write the desired watermark level number (well, 2x the level
number).
Since we allow the user to adjust the latency values via debugfs,
and since we have some quirks where we adjust the values automagically,
we must stash away the originals read from SSKPD for later use
in the WM_LP registers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 37 +++--
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 95231f5f813d..c0204802d9cd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1778,6 +1778,12 @@ struct drm_i915_private {
* (which we don't fully trust).
*/
bool distrust_bios_wm;
+
+ /*
+* The values we must write to the LP watermark
+* registers' latency field on ILK-BDW.
+*/
+ u16 ilk_wm_lp_latency[5];
} wm;
struct dram_info {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6328f0f8aa88..d5ad84be769d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3038,10 +3038,35 @@ static void snb_wm_lp3_irq_quirk(struct
drm_i915_private *dev_priv)
intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
}
+/* The value we need to program into the WM_LPx latency field */
+static u16 ilk_wm_lp_latency(struct drm_i915_private *dev_priv, int level)
+{
+ if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+ return 2 * level;
+ else
+ return dev_priv->wm.pri_latency[level];
+}
+
+static void ilk_setup_wm_lp_latency(struct drm_i915_private *dev_priv)
+{
+ int level, max_level = ilk_wm_max_level(dev_priv);
+
+ for (level = 1; level <= max_level; level++)
+ dev_priv->wm.ilk_wm_lp_latency[level] =
+ ilk_wm_lp_latency(dev_priv, level);
+}
+
static void ilk_setup_wm_latency(struct drm_i915_private *dev_priv)
{
intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency);
+ /*
+* On ILK-IVB the values written to the LP watermark register
+* latency field must match SSKPD 100%. So do this before any
+* adjustments are made to the latency values we got from SSKPD.
+*/
+ ilk_setup_wm_lp_latency(dev_priv);
+
memcpy(dev_priv->wm.spr_latency, dev_priv->wm.pri_latency,
sizeof(dev_priv->wm.pri_latency));
memcpy(dev_priv->wm.cur_latency, dev_priv->wm.pri_latency,
@@ -3326,16 +3351,6 @@ static int ilk_wm_lp_to_level(int wm_lp, const struct
ilk_pipe_wm *pipe_wm)
return wm_lp + (wm_lp >= 2 && pipe_wm->wm[4].enable);
}
-/* The value we need to program into the WM_LPx latency field */
-static unsigned int ilk_wm_lp_latency(struct drm_i915_private *dev_priv,
- int level)
-{
- if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
- return 2 * level;
- else
- return dev_priv->wm.pri_latency[level];
-}
-
static void ilk_compute_wm_results(struct drm_i915_private *dev_priv,
const struct ilk_pipe_wm *merged,
enum ilk_ddb_partitioning partitioning,
@@ -3360,7 +3375,7 @@ static void ilk_compute_wm_results(struct
drm_i915_private *dev_priv,
* disabled. Doing otherwise could cause underruns.
*/
results->wm_lp[wm_lp - 1] =
- (ilk_wm_lp_latency(dev_priv, level) <<
WM1_LP_LATENCY_SHIFT) |
+ (dev_priv->wm.ilk_wm_lp_latency[level] <<
WM1_LP_LATENCY_SHIFT) |
(r->pri_val << WM1_LP_SR_SHIFT) |
r->cur_val;
--
2.18.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915: Clean up SSKPD defines
From: Ville Syrjälä
Give names to the HSW/BDW SSKPD mask/shift values, give
and _SNB suffix to the SNB/IVB mask/shift values, and
drop the bogus non-mirrored SSKPD register define.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 26 +-
drivers/gpu/drm/i915/intel_pm.c | 20 ++--
2 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9dce09ed47f7..ea9a664980a6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3536,8 +3536,24 @@ enum i915_power_well_id {
#define MAD_DIMM_A_SIZE_SHIFT0
#define MAD_DIMM_A_SIZE_MASK (0xff << MAD_DIMM_A_SIZE_SHIFT)
-/* snb MCH registers for priority tuning */
#define MCH_SSKPD _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5d10)
+#define SSKPD_WM0_SHIFT_SNB0
+#define SSKPD_WM1_SHIFT_SNB8
+#define SSKPD_WM2_SHIFT_SNB16
+#define SSKPD_WM3_SHIFT_SNB24
+#define SSKPD_WM_MASK_SNB 0x3f
+#define SSKPD_NEW_WM0_SHIFT_HSW56
+#define SSKPD_NEW_WM0_MASK_HSW 0xff
+#define SSKPD_OLD_WM0_SHIFT_HSW0
+#define SSKPD_OLD_WM0_MASK_HSW 0xf
+#define SSKPD_WM1_SHIFT_HSW4
+#define SSKPD_WM1_MASK_HSW 0xff
+#define SSKPD_WM2_SHIFT_HSW12
+#define SSKPD_WM2_MASK_HSW 0xff
+#define SSKPD_WM3_SHIFT_HSW20
+#define SSKPD_WM3_MASK_HSW 0x1ff
+#define SSKPD_WM4_SHIFT_HSW32
+#define SSKPD_WM4_MASK_HSW 0x1ff
#define MCH_SECP_NRG_STTS _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x592c)
@@ -6016,14 +6032,6 @@ enum {
#define ILK_SRLT_MASK 0x3f
-/* the address where we get all kinds of latency value */
-#define SSKPD _MMIO(0x5d10)
-#define SSKPD_WM_MASK 0x3f
-#define SSKPD_WM0_SHIFT0
-#define SSKPD_WM1_SHIFT8
-#define SSKPD_WM2_SHIFT16
-#define SSKPD_WM3_SHIFT24
-
/*
* The two pipe frame counter registers are not synchronized, so
* reading a stable value is somewhat tricky. The following code
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1a9ad431efbd..6ebde7bbac4e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2889,20 +2889,20 @@ static void intel_read_wm_latency(struct
drm_i915_private *dev_priv,
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
uint64_t sskpd = I915_READ64(MCH_SSKPD);
- wm[0] = (sskpd >> 56) & 0xFF;
+ wm[0] = (sskpd >> SSKPD_NEW_WM0_SHIFT_HSW) &
SSKPD_NEW_WM0_MASK_HSW;
if (wm[0] == 0)
- wm[0] = sskpd & 0xF;
- wm[1] = (sskpd >> 4) & 0xFF;
- wm[2] = (sskpd >> 12) & 0xFF;
- wm[3] = (sskpd >> 20) & 0x1FF;
- wm[4] = (sskpd >> 32) & 0x1FF;
+ wm[0] = (sskpd >> SSKPD_OLD_WM0_SHIFT_HSW) &
SSKPD_OLD_WM0_MASK_HSW;
+ wm[1] = (sskpd >> SSKPD_WM1_SHIFT_HSW) & SSKPD_WM1_MASK_HSW;
+ wm[2] = (sskpd >> SSKPD_WM2_SHIFT_HSW) & SSKPD_WM2_MASK_HSW;
+ wm[3] = (sskpd >> SSKPD_WM3_SHIFT_HSW) & SSKPD_WM3_MASK_HSW;
+ wm[4] = (sskpd >> SSKPD_WM4_SHIFT_HSW) & SSKPD_WM4_MASK_HSW;
} else if (INTEL_GEN(dev_priv) >= 6) {
uint32_t sskpd = I915_READ(MCH_SSKPD);
- wm[0] = (sskpd >> SSKPD_WM0_SHIFT) & SSKPD_WM_MASK;
- wm[1] = (sskpd >> SSKPD_WM1_SHIFT) & SSKPD_WM_MASK;
- wm[2] = (sskpd >> SSKPD_WM2_SHIFT) & SSKPD_WM_MASK;
- wm[3] = (sskpd >> SSKPD_WM3_SHIFT) & SSKPD_WM_MASK;
+ wm[0] = (sskpd >> SSKPD_WM0_SHIFT_SNB) & SSKPD_WM_MASK_SNB;
+ wm[1] = (sskpd >> SSKPD_WM1_SHIFT_SNB) & SSKPD_WM_MASK_SNB;
+ wm[2] = (sskpd >> SSKPD_WM2_SHIFT_SNB) & SSKPD_WM_MASK_SNB;
+ wm[3] = (sskpd >> SSKPD_WM3_SHIFT_SNB) & SSKPD_WM_MASK_SNB;
} else if (INTEL_GEN(dev_priv) >= 5) {
uint32_t mltr = I915_READ(MLTR_ILK);
--
2.18.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't forget to reset blocks when testing lower wm levels
On Wed, Dec 12, 2018 at 11:17:20AM -0800, Matt Roper wrote:
> During DDB allocation, we try to distribute enough blocks for each plane
> to hit the highest watermark level; if that fails, we retry each lower
> level (which should require fewer blocks) until we find one that's
> possible (or until the whole commit is rejected as impossible). We need
> to reset our running block count when trying each lower level, otherwise
> all lower levels will fail as well.
>
> Cc: Ville Syrjälä
> Fixes: d8e8749802 ("drm/i915: Switch to level-based DDB allocation algorithm
> (v5)")
> Signed-off-by: Matt Roper
Whoops.
Reviewed-by: Ville Syrjälä
> ---
> After waiting for CI results to come out, I accidentally pushed v5 of
> the new DDB algorithm rather than the expected v6. This fixup patch is
> the only difference between those two versions.
>
> drivers/gpu/drm/i915/intel_pm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6d074f2e69d3..a6c7c11d2c0e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4365,6 +4365,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>* requirement of active planes.
>*/
> for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
> + blocks = 0;
> for_each_plane_id_on_crtc(intel_crtc, plane_id) {
> if (plane_id == PLANE_CURSOR)
> continue;
> --
> 2.14.4
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: correct the pitch check for NV12 framebuffer
On Wed, Dec 12, 2018 at 09:33:49PM +0100, Daniel Vetter wrote:
> On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> > > framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> > > of the width. This patch corrects it.
> > >
> > > For instance, a 480p video, whose width and pitch are 854 and 896
> > > respectively, is excluded for NV12 plane so far.
> > >
> > > Signed-off-by: Dongseong Hwang
> > > Cc: Chandra Konduru
> > > Cc: Vidya Srinivas
> > > Cc: Ville Syrjälä
> > > Cc: Juha-Pekka Heikkila
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 13e5650..8a3de12 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -14600,7 +14600,7 @@ static int intel_framebuffer_init(struct
> > > intel_framebuffer *intel_fb,
> > > if (fb->format->format == DRM_FORMAT_NV12 &&
> > > (fb->width < SKL_MIN_YUV_420_SRC_W ||
> > >fb->height < SKL_MIN_YUV_420_SRC_H ||
> > > - (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
> > > + (fb->pitches[0] % 4) != 0 || (fb->height % 4) != 0)) {
> >
> > The stride can never be misaligned like that. It'll be at least tile
> > aligned, or 64 byte aligned with linear buffers.
> >
> > Anyways this entire piece of code doesn't make too much sense. The fb
> > size doesn't really matter for us, only the src viewport size matters.
> > That one we limit to a minimum of 2x2 pixels w/o scaling, and 16x16
> > pixems w/ scaling. So looks like this code can be just ripped out.
>
> Do we have igt testcases for these cornercases in igt? Obviously would
> need to be intel specific subtests ...
Can't spot anything quite that specific. Someone would need to write
one I suppose. Also Imre has a test somewhere on the list for testing
the plane clipping underrun fails which tests small src viewport sizes,
and JP has been working on a rotation vs. clipping test that is also
somewhat related. Not sure if we could combine any of these somehow
to avoid having too many similar tests.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't forget to reset blocks when testing lower wm levels
During DDB allocation, we try to distribute enough blocks for each plane
to hit the highest watermark level; if that fails, we retry each lower
level (which should require fewer blocks) until we find one that's
possible (or until the whole commit is rejected as impossible). We need
to reset our running block count when trying each lower level, otherwise
all lower levels will fail as well.
Cc: Ville Syrjälä
Fixes: d8e8749802 ("drm/i915: Switch to level-based DDB allocation algorithm
(v5)")
Signed-off-by: Matt Roper
---
After waiting for CI results to come out, I accidentally pushed v5 of
the new DDB algorithm rather than the expected v6. This fixup patch is
the only difference between those two versions.
drivers/gpu/drm/i915/intel_pm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6d074f2e69d3..a6c7c11d2c0e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4365,6 +4365,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
* requirement of active planes.
*/
for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
+ blocks = 0;
for_each_plane_id_on_crtc(intel_crtc, plane_id) {
if (plane_id == PLANE_CURSOR)
continue;
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using u16
== Series Details == Series: series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using u16 URL : https://patchwork.freedesktop.org/series/53962/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gvt/handlers.o drivers/gpu/drm/i915/gvt/handlers.c: In function ‘init_generic_mmio_info’: drivers/gpu/drm/i915/gvt/handlers.c:2123:9: error: ‘WM0_PIPEA_ILK’ undeclared (first use in this function); did you mean ‘_WM0_PIPEA_ILK’? MMIO_D(WM0_PIPEA_ILK, D_ALL); ^ drivers/gpu/drm/i915/gvt/handlers.c:1767:48: note: in definition of macro ‘MMIO_F’ ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \ ^~~ drivers/gpu/drm/i915/gvt/handlers.c:2123:2: note: in expansion of macro ‘MMIO_D’ MMIO_D(WM0_PIPEA_ILK, D_ALL); ^~ drivers/gpu/drm/i915/gvt/handlers.c:2123:9: note: each undeclared identifier is reported only once for each function it appears in MMIO_D(WM0_PIPEA_ILK, D_ALL); ^ drivers/gpu/drm/i915/gvt/handlers.c:1767:48: note: in definition of macro ‘MMIO_F’ ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \ ^~~ drivers/gpu/drm/i915/gvt/handlers.c:2123:2: note: in expansion of macro ‘MMIO_D’ MMIO_D(WM0_PIPEA_ILK, D_ALL); ^~ drivers/gpu/drm/i915/gvt/handlers.c:2124:9: error: ‘WM0_PIPEB_ILK’ undeclared (first use in this function); did you mean ‘WM0_PIPEA_ILK’? MMIO_D(WM0_PIPEB_ILK, D_ALL); ^ drivers/gpu/drm/i915/gvt/handlers.c:1767:48: note: in definition of macro ‘MMIO_F’ ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \ ^~~ drivers/gpu/drm/i915/gvt/handlers.c:2124:2: note: in expansion of macro ‘MMIO_D’ MMIO_D(WM0_PIPEB_ILK, D_ALL); ^~ drivers/gpu/drm/i915/gvt/handlers.c:2125:9: error: ‘WM0_PIPEC_IVB’ undeclared (first use in this function); did you mean ‘_WM0_PIPEC_IVB’? MMIO_D(WM0_PIPEC_IVB, D_ALL); ^ drivers/gpu/drm/i915/gvt/handlers.c:1767:48: note: in definition of macro ‘MMIO_F’ ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \ ^~~ drivers/gpu/drm/i915/gvt/handlers.c:2125:2: note: in expansion of macro ‘MMIO_D’ MMIO_D(WM0_PIPEC_IVB, D_ALL); ^~ scripts/Makefile.build:291: recipe for target 'drivers/gpu/drm/i915/gvt/handlers.o' failed make[4]: *** [drivers/gpu/drm/i915/gvt/handlers.o] Error 1 scripts/Makefile.build:516: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:516: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:516: 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 v2] drm/i915: correct the pitch check for NV12 framebuffer
On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä
wrote:
>
> On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> > framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> > of the width. This patch corrects it.
> >
> > For instance, a 480p video, whose width and pitch are 854 and 896
> > respectively, is excluded for NV12 plane so far.
> >
> > Signed-off-by: Dongseong Hwang
> > Cc: Chandra Konduru
> > Cc: Vidya Srinivas
> > Cc: Ville Syrjälä
> > Cc: Juha-Pekka Heikkila
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 13e5650..8a3de12 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14600,7 +14600,7 @@ static int intel_framebuffer_init(struct
> > intel_framebuffer *intel_fb,
> > if (fb->format->format == DRM_FORMAT_NV12 &&
> > (fb->width < SKL_MIN_YUV_420_SRC_W ||
> >fb->height < SKL_MIN_YUV_420_SRC_H ||
> > - (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
> > + (fb->pitches[0] % 4) != 0 || (fb->height % 4) != 0)) {
>
> The stride can never be misaligned like that. It'll be at least tile
> aligned, or 64 byte aligned with linear buffers.
>
> Anyways this entire piece of code doesn't make too much sense. The fb
> size doesn't really matter for us, only the src viewport size matters.
> That one we limit to a minimum of 2x2 pixels w/o scaling, and 16x16
> pixems w/ scaling. So looks like this code can be just ripped out.
Do we have igt testcases for these cornercases in igt? Obviously would
need to be intel specific subtests ...
-Daniel
>
> > DRM_DEBUG_KMS("src dimensions not correct for NV12\n");
> > goto err;
> > }
> > --
> > 2.7.4
>
> --
> Ville Syrjälä
> Intel
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
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: Don't forget to reset blocks when testing lower wm levels
== Series Details == Series: drm/i915: Don't forget to reset blocks when testing lower wm levels URL : https://patchwork.freedesktop.org/series/53961/ State : success == Summary == CI Bug Log - changes from CI_DRM_5307 -> Patchwork_11078 Summary --- **WARNING** Minor unknown changes coming with Patchwork_11078 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11078, 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/53961/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11078: ### IGT changes ### Warnings * igt@kms_flip@basic-flip-vs-dpms: - fi-skl-6770hq: PASS -> SKIP +36 Known issues Here are the changes found in Patchwork_11078 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-compute: - fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094] * igt@amdgpu/amd_prime@amd-to-i915: - fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341] * igt@kms_pipe_crc_basic@read-crc-pipe-a: - fi-byt-clapper: PASS -> FAIL [fdo#107362] * igt@vgem_basic@dmabuf-export: - fi-cfl-8109u: PASS -> DMESG-WARN [fdo#106107] +1 Possible fixes * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS * igt@i915_selftest@live_gem: - fi-bdw-gvtdvm: DMESG-WARN [fdo#108797] -> PASS * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107 [fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094 [fdo#108797]: https://bugs.freedesktop.org/show_bug.cgi?id=108797 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 Participating hosts (50 -> 44) -- Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-ctg-p8600 fi-icl-y Build changes - * Linux: CI_DRM_5307 -> Patchwork_11078 CI_DRM_5307: 68a6c7d52a9ff2671979b31596cba7393b8d9973 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4746: 2c793666d8c8328733f5769b16ae5858fee97f3f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11078: 79e4187e5f0456dc8fe3190e02e55db3373a21ec @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 79e4187e5f04 drm/i915: Don't forget to reset blocks when testing lower wm levels == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11078/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/6] drm/i915: Use _MMIO_PIPE3() for ilk+ WM0_PIPE registers
From: Ville Syrjälä
Remove the hand rolled array of WM0_PIPE register offsets
and use the standard _MMIO_PIPE3() instead.
v2: Take care of gvt too
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gvt/handlers.c | 6 +++---
drivers/gpu/drm/i915/i915_reg.h | 9 +
drivers/gpu/drm/i915/intel_pm.c | 13 -
3 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index b5475c91e2ef..2edab387221d 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -2120,9 +2120,9 @@ static int init_generic_mmio_info(struct intel_gvt *gvt)
MMIO_D(PF_VSCALE(PIPE_C), D_ALL);
MMIO_D(PF_HSCALE(PIPE_C), D_ALL);
- MMIO_D(WM0_PIPEA_ILK, D_ALL);
- MMIO_D(WM0_PIPEB_ILK, D_ALL);
- MMIO_D(WM0_PIPEC_IVB, D_ALL);
+ MMIO_D(WM0_PIPE_ILK(PIPE_A), D_ALL);
+ MMIO_D(WM0_PIPE_ILK(PIPE_B), D_ALL);
+ MMIO_D(WM0_PIPE_ILK(PIPE_C), D_ALL);
MMIO_D(WM1_LP_ILK, D_ALL);
MMIO_D(WM2_LP_ILK, D_ALL);
MMIO_D(WM3_LP_ILK, D_ALL);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ea9a664980a6..246e5e77e7c5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5992,15 +5992,16 @@ enum {
_MMIO(_PLANE(plane, _PLANE_WM_TRANS_1(pipe), _PLANE_WM_TRANS_2(pipe)))
/* define the Watermark register on Ironlake */
-#define WM0_PIPEA_ILK _MMIO(0x45100)
+#define _WM0_PIPEA_ILK 0x45100
+#define _WM0_PIPEB_ILK 0x45104
+#define _WM0_PIPEC_IVB 0x45200
+#define WM0_PIPE_ILK(pipe) _MMIO_PIPE3((pipe), _WM0_PIPEA_ILK, \
+ _WM0_PIPEB_ILK, _WM0_PIPEC_IVB)
#define WM0_PIPE_PLANE_MASK (0x << 16)
#define WM0_PIPE_PLANE_SHIFT 16
#define WM0_PIPE_SPRITE_MASK (0xff << 8)
#define WM0_PIPE_SPRITE_SHIFT 8
#define WM0_PIPE_CURSOR_MASK (0xff)
-
-#define WM0_PIPEB_ILK _MMIO(0x45104)
-#define WM0_PIPEC_IVB _MMIO(0x45200)
#define WM1_LP_ILK _MMIO(0x45108)
#define WM1_LP_SR_EN (1 << 31)
#define WM1_LP_LATENCY_SHIFT 24
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6ebde7bbac4e..46f8c8728847 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3555,11 +3555,11 @@ static void ilk_write_wm_values(struct drm_i915_private
*dev_priv,
_ilk_disable_lp_wm(dev_priv, dirty);
if (dirty & WM_DIRTY_PIPE(PIPE_A))
- I915_WRITE(WM0_PIPEA_ILK, results->wm_pipe[0]);
+ I915_WRITE(WM0_PIPE_ILK(PIPE_A), results->wm_pipe[0]);
if (dirty & WM_DIRTY_PIPE(PIPE_B))
- I915_WRITE(WM0_PIPEB_ILK, results->wm_pipe[1]);
+ I915_WRITE(WM0_PIPE_ILK(PIPE_B), results->wm_pipe[1]);
if (dirty & WM_DIRTY_PIPE(PIPE_C))
- I915_WRITE(WM0_PIPEC_IVB, results->wm_pipe[2]);
+ I915_WRITE(WM0_PIPE_ILK(PIPE_C), results->wm_pipe[2]);
if (dirty & WM_DIRTY_LINETIME(PIPE_A))
I915_WRITE(PIPE_WM_LINETIME(PIPE_A), results->wm_linetime[0]);
@@ -5647,13 +5647,8 @@ static void ilk_pipe_wm_get_hw_state(struct intel_crtc
*crtc)
struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->base.state);
struct ilk_pipe_wm *active = >wm.ilk.optimal;
enum pipe pipe = crtc->pipe;
- static const i915_reg_t wm0_pipe_reg[] = {
- [PIPE_A] = WM0_PIPEA_ILK,
- [PIPE_B] = WM0_PIPEB_ILK,
- [PIPE_C] = WM0_PIPEC_IVB,
- };
- hw->wm_pipe[pipe] = I915_READ(wm0_pipe_reg[pipe]);
+ hw->wm_pipe[pipe] = I915_READ(WM0_PIPE_ILK(pipe));
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
hw->wm_linetime[pipe] = I915_READ(PIPE_WM_LINETIME(pipe));
--
2.18.1
___
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, One lonely patch to fix a new WARN on rockchip rk3399 chromebooks. drm-misc-fixes-2018-12-12: - rockchip: Revert change causing WARN on shutdown (Brian) Cc: Brian Norris Cheers, Sean The following changes since commit b31a3ca745a4a47ba63208d37cd50abffe58280f: drm/fb-helper: Fix typo in parameter description (2018-12-04 14:22:20 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-12-12 for you to fetch changes up to 63238173b2faf3d6b85a416f1c69af6c7be2413f: Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec" (2018-12-11 15:15:57 +0100) - rockchip: Revert change causing WARN on shutdown (Brian) Cc: Brian Norris Brian Norris (1): Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec" drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 -- 1 file changed, 6 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] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using u16 (rev2)
== Series Details == Series: series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using u16 (rev2) URL : https://patchwork.freedesktop.org/series/53962/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Shrink ilk-bdw wm storage by using u16 +drivers/gpu/drm/i915/intel_pm.c:2439:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:2455:16: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_pm.c:2734:35: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_pm.c:2734:35: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_pm.c:2735:35: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_pm.c:2735:35: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_pm.c:2736:35: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_pm.c:2736:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:2731:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:2731:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:2732:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:2732:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:2733:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:2733:35: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_pm.c:4852:30: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_pm.c:4852:30: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_pm.c:6615:24: warning: too many warnings +drivers/gpu/drm/i915/intel_pm.c:4852:30: warning: too many warnings Commit: drm/i915: Rename ilk watermark structs/enums -O:drivers/gpu/drm/i915/intel_pm.c:3208:33: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_pm.c:3208:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:3207:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:3207:33: warning: expression using sizeof(void) Commit: drm/i915: Stash away the original SSKPD latency values -drivers/gpu/drm/i915/selftests/../i915_drv.h:3561:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3567:16: warning: expression using sizeof(void) Commit: drm/i915: Remove gen6_check_mch_setup() Okay! Commit: drm/i915: Clean up SSKPD defines Okay! Commit: drm/i915: Use _MMIO_PIPE3() for ilk+ WM0_PIPE registers Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?
Hi! > > > > > > > There's one similar for nouveau in Bugzilla, but it seems like a > > > > > > > genuine > > > > > > > memory corruption (1 bit flipped): > > > > > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > > > > > > > > > > > > > Any extra information would be of use :) > > > > > > > > > > > > > > Regards, Joonas > > > > > > > > > > > > > > PS. Could you open a bug to Bugzilla, it'll help to collect the > > > > > > > information in one consolidated place: > > > > > > > > > > > > > > https://01.org/linuxgraphics/documentation/how-report-bugs > > > > > > > > > > > > I prefer email... certainly for bugs that can't be reproduced. > > > > > > > > > > By adding it to the Bugzilla it may be recognized by somebody else > > > > > who is experiencing a similar issue. Internet points are not deducted > > > > > for submitting bugs in good faith, even if they get closed as > > > > > NOTABUG. > > > > > > Well, your documentation suggests you'll deduce my internet points: > > > > > > Before filing the bug, please try to reproduce your issue with the > > > latest kernel. Use the latest drm-tip branch from > > > http://cgit.freedesktop.org/drm-tip and build as instructed on our > > > Build Guide. > > > > > > :-) > > > > I'd prefer not to run drm-tip. I'll update to 2.6.20-rc5+ and see if > > it re-appears (but it takes long time to reproduce :-(). > > If we can or can not reproduce the issue with drm-tip, is a very useful > datapoint for us. If we can not reproduce, it'll be possible to bisect > which commit fixed it, and backport that. On the other hand, if it's > still reproducible, we know we're not spending time on something we > already fixed, and the priority gets a bump. bisect ... is not practical on something that takes 2 days to reproduce. > > If you think it is useful, I can try to update my machine to > > linux-next. > > linux-next is closer to drm-tip, so it's better. Do you have some > specific reason for not wanting to run drm-tip (but linux-next is still > ok)? I already have build/update scripts for -next, and I trust -next not to store screenshots of my desktop in my master boot record :-). Anyway, it does happen with -next. This time, chromiums were running, and crash happened minute? after I exited flightgear. It can be seen in the logs. Oh and I might want to mention -- machine was rather deep in swap this time, as in "mouse jumping when starting fgfs" and "could feel the chromium being swapped back in". I might have had this situation before, and just powercycled the machine "because it is so deep in swap that it will not recover". top says: top - 19:18:24 up 2 days, 8:03, 2 users, load average: 3.02, 3.45, 3.21 Tasks: 141 total, 1 running, 86 sleeping, 0 stopped, 2 zombie %Cpu(s): 18.8 us, 7.6 sy, 3.0 ni, 68.4 id, 1.3 wa, 0.0 hi, 0.9 si, 0.0 st KiB Mem: 5967968 total, 663244 used, 5304724 free,48876 buffers KiB Swap: 1681428 total, 170904 used, 1510524 free. 446280 cached Mem but of course that memory is free once everything died. Any ideas? Should I go back to v4.19 to see if it happens there, too? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html delme.gz Description: application/gzip signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: correct the pitch check for NV12 framebuffer
On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> of the width. This patch corrects it.
>
> For instance, a 480p video, whose width and pitch are 854 and 896
> respectively, is excluded for NV12 plane so far.
>
> Signed-off-by: Dongseong Hwang
> Cc: Chandra Konduru
> Cc: Vidya Srinivas
> Cc: Ville Syrjälä
> Cc: Juha-Pekka Heikkila
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 13e5650..8a3de12 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14600,7 +14600,7 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> if (fb->format->format == DRM_FORMAT_NV12 &&
> (fb->width < SKL_MIN_YUV_420_SRC_W ||
>fb->height < SKL_MIN_YUV_420_SRC_H ||
> - (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
> + (fb->pitches[0] % 4) != 0 || (fb->height % 4) != 0)) {
The stride can never be misaligned like that. It'll be at least tile
aligned, or 64 byte aligned with linear buffers.
Anyways this entire piece of code doesn't make too much sense. The fb
size doesn't really matter for us, only the src viewport size matters.
That one we limit to a minimum of 2x2 pixels w/o scaling, and 16x16
pixems w/ scaling. So looks like this code can be just ripped out.
> DRM_DEBUG_KMS("src dimensions not correct for NV12\n");
> goto err;
> }
> --
> 2.7.4
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Don't forget to reset blocks when testing lower wm levels
== Series Details ==
Series: drm/i915: Don't forget to reset blocks when testing lower wm levels
URL : https://patchwork.freedesktop.org/series/53961/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5307_full -> Patchwork_11078_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11078_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11078_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11078_full:
### IGT changes ###
Possible regressions
* igt@gem_userptr_blits@readonly-unsync:
- shard-iclb: PASS -> TIMEOUT
Warnings
* igt@kms_plane_lowres@pipe-a-tiling-y:
- shard-iclb: SKIP -> PASS
* igt@pm_rc6_residency@rc6-accuracy:
- shard-kbl: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_11078_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@pi-ringfull-bsd:
- shard-skl: NOTRUN -> FAIL [fdo#103158]
* igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-skl: NOTRUN -> TIMEOUT [fdo#108039]
* igt@gem_workarounds@suspend-resume:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713]
* igt@i915_suspend@shrink:
- shard-skl: NOTRUN -> INCOMPLETE [fdo#106886]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-pageflip-hang-newfb-render-a:
- shard-glk: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled:
- shard-skl: NOTRUN -> FAIL [fdo#103184]
* igt@kms_draw_crc@draw-method-rgb565-render-untiled:
- shard-iclb: PASS -> WARN [fdo#108336] +2
* igt@kms_flip@dpms-off-confusion:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +21
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +8
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +6
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt:
- shard-skl: NOTRUN -> FAIL [fdo#105682] +1
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-gtt:
- shard-skl: NOTRUN -> FAIL [fdo#103167] +3
* igt@kms_plane@pixel-format-pipe-a-planes:
- shard-iclb: NOTRUN -> FAIL [fdo#103166]
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane@plane-panning-top-left-pipe-c-planes:
- shard-skl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815]
* igt@kms_plane_lowres@pipe-c-tiling-y:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +13
* igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-glk: PASS -> FAIL [fdo#103166] +2
* {igt@runner@aborted}:
- shard-iclb: NOTRUN -> FAIL [fdo#108866]
Possible fixes
* igt@kms_color@pipe-b-degamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: FAIL [fdo#102887] / [fdo#105363] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-pri-indfb-multidraw:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-iclb: FAIL [fdo#105683] / [fdo#108040] -> PASS
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-pgflip-blt:
- shard-snb: INCOMPLETE [fdo#105411] / [fdo#107469] -> SKIP
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen:
- shard-iclb: FAIL -> PASS +7
* igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-iclb: FAIL [fdo#103166] -> PASS
* igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- shard-glk: FAIL [fdo#103166] -> PASS +1
*
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using u16 (rev2)
== Series Details ==
Series: series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using
u16 (rev2)
URL : https://patchwork.freedesktop.org/series/53962/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5308 -> Patchwork_11080
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11080 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11080, 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/53962/revisions/2/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11080:
### IGT changes ###
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: PASS -> SKIP +33
Known issues
Here are the changes found in Patchwork_11080 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-7500u: PASS -> DMESG-WARN [fdo#105128] / [fdo#107139]
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-skl-guc: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]
* {igt@runner@aborted}:
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128
[fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
Participating hosts (48 -> 44)
--
Additional (1): fi-icl-y
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5308 -> Patchwork_11080
CI_DRM_5308: e7cbffbd8fd1b6d713128ceb891d7d6205390ee4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4746: 2c793666d8c8328733f5769b16ae5858fee97f3f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11080: f542917d1f7c20c1fee9535302982f1ff7038b13 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f542917d1f7c drm/i915: Use _MMIO_PIPE3() for ilk+ WM0_PIPE registers
a65c8a2538bb drm/i915: Clean up SSKPD defines
15479c03167b drm/i915: Remove gen6_check_mch_setup()
436a44ebac02 drm/i915: Stash away the original SSKPD latency values
633566de8c23 drm/i915: Rename ilk watermark structs/enums
4552b667487e drm/i915: Shrink ilk-bdw wm storage by using u16
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11080/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/psr: Disable DRRS if enabled when enabling PSR from debugfs
On Wed, 2018-12-12 at 05:02 -0800, Souza, Jose wrote:
> On Tue, 2018-12-11 at 14:02 -0800, Dhinakaran Pandiyan wrote:
> > On Mon, 2018-11-12 at 11:17 +0100, Maarten Lankhorst wrote:
> > > Op 09-11-18 om 21:20 schreef José Roberto de Souza:
> > > > If panel supports DRRS and PSR and if driver is loaded without
> > > > PSR
> > > > enabled, driver will enable DRRS as expected but if PSR is
> > > > enabled
> > > > by
> > > > debugfs latter it will keep PSR and DRRS enabled causing
> > > > possible
> > > > problems as DRRS will lower the refresh rate while PSR enabled.
> > > >
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108341
> > > > Cc: Maarten Lankhorst
> > > > Cc: Dhinakaran Pandiyan
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/intel_psr.c | 5 -
> > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 853e3f1370a0..bfc6a08b5cf4 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -904,8 +904,11 @@ int intel_psr_set_debugfs_mode(struct
> > > > drm_i915_private *dev_priv,
> > > >
> > > > intel_psr_irq_control(dev_priv, dev_priv->psr.debug);
> > > >
> > > > - if (dev_priv->psr.prepared && enable)
> > > > + if (dev_priv->psr.prepared && enable) {
> > > > + if (crtc_state)
> > > > + intel_edp_drrs_disable(dp, crtc_state);
> > > > intel_psr_enable_locked(dev_priv, crtc_state);
> > > > + }
> > > >
> > > > mutex_unlock(_priv->psr.lock);
> > > > return ret;
> > >
> > > I've considered this, but I thought it was a feature, not a bug.
> > > It's
> > > a pain to track
> > > how we handle this as intended.
> > >
> > > kms_frontbuffer_tracking is also controlling DRRS during the
> > > test,
> > > so
> > > perhaps simply
> > > fix the test?
> > >
> > > It seems the no_drrs test simply checks that if PSR is enabled,
> > > we
> > > don't have drrs
> > > enabled. We probably care about the default configuration, so I
> > > would
> > > simply disable
> > > the pipe, update the PSR flag, and then start running the tests.
> > > Else
> > > the only thing
> > > we test is that debugfs disables DRRS. Not that the default
> > > modeset
> > > path prevents
> > > PSR and DRRS simultaneously.
> > >
> > > ~Maarten
> > >
> > > Maybe something like below?
> > >
> > > Perhaps move the drrs manipulation functions from
> > > kms_frontbuffer_tracking to lib/kms_psr.c
> > >
> > > 8<---
> > > diff --git a/tests/kms_psr.c b/tests/kms_psr.c
> > > index 9767f475bf23..ffc356df06ce 100644
> > > --- a/tests/kms_psr.c
> > > +++ b/tests/kms_psr.c
> > > @@ -414,9 +414,6 @@ int main(int argc, char *argv[])
> > > kmstest_set_vt_graphics_mode();
> > > data.devid = intel_get_drm_devid(data.drm_fd);
> > >
> > > - if (!data.with_psr_disabled)
> > > - psr_enable(data.debugfs_fd);
> > > -
> > > igt_require_f(sink_support(),
> > > "Sink does not support PSR\n");
> > >
> > > @@ -428,18 +425,25 @@ int main(int argc, char *argv[])
> > > }
> > >
> > > igt_subtest("basic") {
> > > - setup_test_plane(, DRM_PLANE_TYPE_PRIMARY);
> > > - igt_assert(psr_wait_entry_if_enabled());
> > > - test_cleanup();
> > > - }
> > > + /* Disable display to get a default setup. */
> > > + igt_display_commit2(,
> > > data.display.is_atomic ? COMMIT_ATOMIC : COMMIT_LEGACY);
> > > +
> > > + if (!data.with_psr_disabled)
> > > + psr_enable(data.debugfs_fd);
> > >
> > > - igt_subtest("no_drrs") {
> > > setup_test_plane(, DRM_PLANE_TYPE_PRIMARY);
> > > igt_assert(psr_wait_entry_if_enabled());
> > > igt_assert(drrs_disabled());
> > > test_cleanup();
> >
> > This makes a lot more sense to me, ensuring that DRRS does not get
> > enabled in the default code path was the goal of the no-drrs test.
>
> The problem with this approach is if user wants to run just one test
> the basic test will not run and DRRS will be kept on, it will not
> fail
> the no_drrs test but DRRS could interfere with other PSR tests.
Disable DRRS for the other sub-tests, doesn't this work?
echo 0 > /sys/kernel/debug/dri/0/i915_drrs_ctl
>
> If the call to disable display is moved to igt_fixture() it would
> work
> fine but in terms of modesets this approach have just one more
> modeset
> than forcing a modeset every time we write to PSR i915_edp_psr_debug,
> for just the cost of one modeset in my opnion is better drop the
> aditional PSR code path and just test the main one.
>
> >
> > -DK
> >
> > > }
> > >
> > > + igt_fixture {
> > > + drrs_disable();
> > > +
> > > + if (!data.with_psr_disabled)
> > > +
Re: [Intel-gfx] [PATCH v8 05/35] drm/i915: MEI interface definition
On 12/12/2018 4:34 PM, C, Ramalingam wrote:
On 12/12/2018 4:08 PM, Daniel Vetter wrote:
On Wed, Dec 12, 2018 at 02:28:29PM +0530, C, Ramalingam wrote:
On 12/7/2018 7:59 PM, Daniel Vetter wrote:
On Fri, Dec 07, 2018 at 11:22:44AM +0530, C, Ramalingam wrote:
On 12/6/2018 3:53 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:
+static void i915_hdcp_component_master_unbind(struct device *dev)
+{
+ struct drm_i915_private *dev_priv = kdev_to_i915(dev);
+
+ intel_connectors_hdcp_disable(dev_priv);
Why this code? Once we've unregistered the driver, we should have shut
down the hardware completely. Which should have shut down all the hdcp
users too.
This unbind might be triggered either due to master_del or component_del.
if its triggered from mei through component_del, then before teardown of
the i/f in component_unbind(), disable the ongoing HDCP session through
hdcp_disable() for each connectors.
I looked at your v7 component code again. I think if we put the
drm_atomic_helper_shutdown() call into master_unbind, then we'll have taken care
of that. Essentially what you're doing here is open-coding part of that
function. Better to just move the existing call to the right place.
And shutting down the entire hw is kinda what master_unbind should be
doing I think. We might also need to move the general hw quiescent into
master_unbind, that should work too.
Need some more information on this. As per v7 on master_unbind will invoke
i915_unload_head that is i915_driver_unregister(dev_priv);
Similarly master_bind will call the load_tail that is
i915_driver_register(dev_priv);
We are not initializing/shutting the HW in master_bind/unbind .
But this comment is contradicting with current approach. Could you please
elaborate.?
So my understanding is that we need to shut down all hdcp usage before
master_unbind completes, because otherwise we'll blow up: The mei_hdcp
component is gone already.
Now the other case for master_unbind is that the i915 pci device is
unloaded, and in that case again I think it makes sense to shut down the
hardware in master_unbind.
Now when I looked at v7, right after the component_unbind code in the i915
unload sequences comes the function calls to shut down the hardware. I
think it would make sense to them (or at least the
drm_atomic_helper_shutdown() call) into master_unbind.
This is somewhat asymetric, but that's ok: Load path doesn't enable
anything, we just keep the hardware as-is (to be able to support
flicker-free boôt-up). First modest is done by usersapce. Exception is if
you have fbcon enabled (and not use the fastboot patches that Hans just
merged), in that case the kernel will do the first modeset when we
regiseter the fbdev device.
Anyway, moving the drm_atomic_helper_shutdown() into the master_unbind
function in v7 should take care of disabling all outputs, and hence also
disabling all usage of hdcp component.
But in that case master_bind should do the reverse of the
drm_atomic_helper_shutdown()right?
else lets say mei_hdcp is removed, master_unbind triggered and hence all hw is
shutdown.
And then mei_hdcp is loaded so master_bind should initialize the hw right?
Which is not the scenario right now.
Summarizing the #intel-gfx IRC discussion:
As i915 load and unload are already asymetric, there is no harm in moving
the drm_atomic_helper_shutdown() into the master_unbind(). So going
ahead with daniel's suggestion.
-Ram
-Ram
-Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Implement HDCP2.2 (rev11)
== Series Details == Series: drm/i915: Implement HDCP2.2 (rev11) URL : https://patchwork.freedesktop.org/series/38254/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Gathering the HDCP1.4 routines together Okay! Commit: drm: header for i915 - MEI_HDCP interface Okay! Commit: drivers/base: use a worker for sysfs unbind Okay! Commit: component: alloc component_match without any comp to match Okay! Commit: drm/i915: component master at i915 driver load -drivers/gpu/drm/i915/selftests/../i915_drv.h:3548:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3551:16: warning: expression using sizeof(void) +./include/linux/slab.h:332:43: warning: dubious: x & !y Commit: drm/i915: Initialize HDCP2.2 Okay! Commit: drm/i915: MEI interface definition +./include/linux/slab.h:665:13: error: not a function Commit: drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking +drivers/gpu/drm/i915/intel_hdcp.c:750:5: warning: symbol 'intel_hdcp_check_link' was not declared. Should it be static? Commit: drm/i915: Enable and Disable of HDCP2.2 Okay! Commit: drm/i915: Implement HDCP2.2 receiver authentication Okay! Commit: drm: helper functions for hdcp2 seq_num to from u32 Okay! Commit: drm/i915: Implement HDCP2.2 repeater authentication +drivers/gpu/drm/i915/intel_hdcp.c:1202:30: warning: incorrect type in assignment (different base types) Commit: drm: HDCP2.2 link check related constants Okay! Commit: drm/i915: Implement HDCP2.2 link integrity check Okay! Commit: drm/i915: Handle HDCP2.2 downstream topology change Okay! Commit: drm/i915: Implement the HDCP2.2 support for DP Okay! Commit: drm/i915: Implement the HDCP2.2 support for HDMI Okay! Commit: drm/i915: Add HDCP2.2 support for DP connectors Okay! Commit: drm/i915: Add HDCP2.2 support for HDMI connectors Okay! Commit: mei: bus: whitelist hdcp client Okay! Commit: mei: bus: export to_mei_cl_device for mei client device drivers Okay! Commit: misc/mei/hdcp: Client driver for HDCP application +Error in reading or end of file. Commit: misc/mei/hdcp: Define ME FW interface for HDCP2.2 Okay! Commit: misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session Okay! Commit: misc/mei/hdcp: Verify Receiver Cert and prepare km Okay! Commit: misc/mei/hdcp: Verify H_prime Okay! Commit: misc/mei/hdcp: Store the HDCP Pairing info Okay! Commit: misc/mei/hdcp: Initiate Locality check Okay! Commit: misc/mei/hdcp: Verify L_prime Okay! Commit: misc/mei/hdcp: Prepare Session Key Okay! Commit: misc/mei/hdcp: Repeater topology verification and ack Okay! Commit: misc/mei/hdcp: Verify M_prime Okay! Commit: misc/mei/hdcp: Enabling the HDCP authentication Okay! Commit: misc/mei/hdcp: Closing wired HDCP2.2 Tx Session Okay! Commit: misc/mei/hdcp: Component framework for I915 Interface Okay! Commit: drm/i915: Commit CP without modeset Okay! Commit: drm/i915: Fix KBL HDCP2.2 encrypt status signalling Okay! Commit: FOR_TEST: i915/Kconfig: Select mei_hdcp by I915 Okay! Commit: FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4 Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well
On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fill out the AVI infoframe quantization range bits using
> drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_sdvo.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 1277d31adb54..9c16e273fb8d 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -984,6 +984,8 @@ static bool intel_sdvo_set_avi_infoframe(struct
> intel_sdvo *intel_sdvo,
>const struct intel_crtc_state
> *pipe_config,
>const struct
> drm_connector_state *conn_state)
> {
> + const struct drm_display_mode *adjusted_mode =
> + _config->base.adjusted_mode;
> uint8_t sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
> union hdmi_infoframe frame;
> int ret;
> @@ -991,20 +993,19 @@ static bool intel_sdvo_set_avi_infoframe(struct
> intel_sdvo *intel_sdvo,
>
> ret = drm_hdmi_avi_infoframe_from_display_mode(,
> conn_state-
> >connector,
> -_config-
> >base.adjusted_mode);
> +adjusted_mode);
> if (ret < 0) {
> DRM_ERROR("couldn't fill AVI infoframe\n");
> return false;
> }
>
> - if (intel_sdvo->rgb_quant_range_selectable) {
> - if (pipe_config->limited_color_range)
> - frame.avi.quantization_range =
> - HDMI_QUANTIZATION_RANGE_LIMITED;
> - else
> - frame.avi.quantization_range =
> - HDMI_QUANTIZATION_RANGE_FULL;
> - }
> + drm_hdmi_avi_infoframe_quant_range(,
> +conn_state->connector,
> +adjusted_mode,
> +pipe_config-
> >limited_color_range ?
> +rgb_quant_range_selectableTE
> D :
> +HDMI_QUANTIZATION_RANGE_FULL
> ,
> +intel_sdvo-
> >rgb_quant_range_selectable);
Seems like avi.quantization_range can now get set to _LIMITED or _FULL
even when ->rgb_quant_range_selectable == false, i.e., it is not
_DEFAULT anymore. Is that change in behavior intended?
>
> len = hdmi_infoframe_pack(, sdvo_data,
> sizeof(sdvo_data));
> if (len < 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 drm/i915: Implement HDCP2.2 (rev11)
== Series Details == Series: drm/i915: Implement HDCP2.2 (rev11) URL : https://patchwork.freedesktop.org/series/38254/ State : warning == Summary == $ dim checkpatch origin/drm-tip bcb5b8686be3 drm/i915: Gathering the HDCP1.4 routines together 83df45d26858 drm: header for i915 - MEI_HDCP interface -:11: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #11: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 132 lines checked 1272436b06c3 drivers/base: use a worker for sysfs unbind c05bd8653488 component: alloc component_match without any comp to match -:55: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #55: FILE: drivers/base/component.c:321: +void component_match_alloc(struct device *master, + struct component_match **matchptr) -:90: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #90: FILE: include/linux/component.h:41: +void component_match_alloc(struct device *master, + struct component_match **matchptr); total: 0 errors, 0 warnings, 2 checks, 44 lines checked 6fbcfc114e39 drm/i915: component master at i915 driver load eecc07b8b347 drm/i915: Initialize HDCP2.2 8d8dd5f6d217 drm/i915: MEI interface definition 00cbaafe144c drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking 7833fd7eaa30 drm/i915: Enable and Disable of HDCP2.2 9a394f2f3023 drm/i915: Implement HDCP2.2 receiver authentication 7d465cbe49b6 drm: helper functions for hdcp2 seq_num to from u32 7dc263a0b470 drm/i915: Implement HDCP2.2 repeater authentication 8fc1d866777d drm: HDCP2.2 link check related constants c6f7ed8e14fc drm/i915: Implement HDCP2.2 link integrity check aa7080cb29b8 drm/i915: Handle HDCP2.2 downstream topology change d2c86d09a537 drm/i915: Implement the HDCP2.2 support for DP 329c1c9d0839 drm/i915: Implement the HDCP2.2 support for HDMI e8441d06100d drm/i915: Add HDCP2.2 support for DP connectors b9400ddf1f7d drm/i915: Add HDCP2.2 support for HDMI connectors ec823f25607a mei: bus: whitelist hdcp client 224dc5b5cfae mei: bus: export to_mei_cl_device for mei client device drivers 4d17a22f645e misc/mei/hdcp: Client driver for HDCP application -:73: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #73: new file mode 100644 -:91: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #91: FILE: drivers/misc/mei/hdcp/mei_hdcp.c:1: +/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */ total: 0 errors, 2 warnings, 0 checks, 87 lines checked 49daba8864d1 misc/mei/hdcp: Define ME FW interface for HDCP2.2 -:29: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #29: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 366 lines checked c5d2659b3177 misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session e635874a9ca8 misc/mei/hdcp: Verify Receiver Cert and prepare km 59ba26d4c7ca misc/mei/hdcp: Verify H_prime 121a0dbfc2ea misc/mei/hdcp: Store the HDCP Pairing info b682919888ee misc/mei/hdcp: Initiate Locality check 43c1b2aeb67b misc/mei/hdcp: Verify L_prime f1766ded1c0a misc/mei/hdcp: Prepare Session Key e127a9d212cd misc/mei/hdcp: Repeater topology verification and ack 40ecac1cfc2d misc/mei/hdcp: Verify M_prime 5f7c7797c62f misc/mei/hdcp: Enabling the HDCP authentication e470b2c2b13f misc/mei/hdcp: Closing wired HDCP2.2 Tx Session 7b32fd10999d misc/mei/hdcp: Component framework for I915 Interface aee57816a8a6 drm/i915: Commit CP without modeset 446a760cbe18 drm/i915: Fix KBL HDCP2.2 encrypt status signalling ef3c22a3dcc1 FOR_TEST: i915/Kconfig: Select mei_hdcp by I915 0fe879c951f8 FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 12/39] drm/i915: Implement HDCP2.2 repeater authentication
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.
v2: Rebased.
v3:
-EINVAL is returned for topology error and rollover scenario.
Endianness conversion func from drm_hdcp.h is used [Uma]
v4:
Rebased as part of patches reordering.
Defined the mei service functions [Daniel]
v5:
Redefined the mei service functions as per comp redesign.
v6:
%s/uintxx_t/uxx
Check for comp_master is removed.
v7:
Adjust to the new mei interface.
style issue fixed.
v8:
drm_hdcp.h change is moved into separate patch [Daniel]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 123 +-
1 file changed, 121 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index f1f0ef294e20..b52da5c3159d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -978,7 +978,7 @@ static int hdcp2_prepare_skey(struct intel_connector
*connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_rep_topology_prepare_ack(struct intel_connector *connector,
struct hdcp2_rep_send_receiverid_list
*rep_topology,
@@ -999,7 +999,7 @@ hdcp2_verify_rep_topology_prepare_ack(struct
intel_connector *connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_mprime(struct intel_connector *connector,
struct hdcp2_rep_stream_ready *stream_ready)
{
@@ -1182,6 +1182,119 @@ static int hdcp2_session_key_exchange(struct
intel_connector *connector)
return 0;
}
+static
+int hdcp2_propagate_stream_management_info(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ union {
+ struct hdcp2_rep_stream_manage stream_manage;
+ struct hdcp2_rep_stream_ready stream_ready;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
+ int ret;
+
+ /* Prepare RepeaterAuth_Stream_Manage msg */
+ msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
+ drm_hdcp2_u32_to_seq_num(msgs.stream_manage.seq_num_m, hdcp->seq_num_m);
+
+ /* K no of streams is fixed as 1. Stored as big-endian. */
+ msgs.stream_manage.k = __swab16(1);
+
+ /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
+ msgs.stream_manage.streams[0].stream_id = 0;
+ msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
+
+ /* Send it to Repeater */
+ ret = shim->write_2_2_msg(intel_dig_port, _manage,
+ sizeof(msgs.stream_manage));
+ if (ret < 0)
+ return ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_STREAM_READY,
+_ready, sizeof(msgs.stream_ready));
+ if (ret < 0)
+ return ret;
+
+ hdcp->port_data.seq_num_m = hdcp->seq_num_m;
+ hdcp->port_data.streams[0].stream_type = hdcp->content_type;
+
+ ret = hdcp2_verify_mprime(connector, _ready);
+ if (ret < 0)
+ return ret;
+
+ hdcp->seq_num_m++;
+
+ if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
+ DRM_DEBUG_KMS("seq_num_m roll over.\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+static
+int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ union {
+ struct hdcp2_rep_send_receiverid_list recvid_list;
+ struct hdcp2_rep_send_ack rep_ack;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
+ u8 *rx_info;
+ u32 seq_num_v;
+ int ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_SEND_RECVID_LIST,
+_list, sizeof(msgs.recvid_list));
+ if (ret < 0)
+ return ret;
+
+ rx_info = msgs.recvid_list.rx_info;
+
+ if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
+ HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
+ DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
+ return -EINVAL;
+ }
+
+ /* Converting and Storing the seq_num_v to local variable as DWORD */
+ drm_hdcp2_seq_num_to_u32(_num_v, msgs.recvid_list.seq_num_v);
+
+ if (seq_num_v < hdcp->seq_num_v) {
+ /* Roll over of the seq_num_v from repeater. Reauthenticate. */
+ DRM_DEBUG_KMS("Seq_num_v roll over.\n");
+ return -EINVAL;
+ }
+
+ ret = hdcp2_verify_rep_topology_prepare_ack(connector,
+
[Intel-gfx] [PATCH v9 11/39] drm: helper functions for hdcp2 seq_num to from u32
Library functions for endianness are aligned for 16/32/64 bits.
But hdcp sequence numbers are 24bits(big endian).
So for their conversion to and from u32 helper functions are developed.
Signed-off-by: Ramalingam C
---
include/drm/drm_hdcp.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index a6de09c5e47f..d8093ecf3ddc 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -250,4 +250,22 @@ struct hdcp2_dp_errata_stream_type {
#define HDCP_2_2_HDMI_RXSTATUS_READY(x)((x) & BIT(2))
#define HDCP_2_2_HDMI_RXSTATUS_REAUTH_REQ(x) ((x) & BIT(3))
+/*
+ * Library functions for endianness are aligned for 16/32/64 bits.
+ * But hdcp sequence numbers are 24bits(big endian). So for their conversion
+ * from and to u32 below functions are developed.
+ */
+static inline void
+drm_hdcp2_seq_num_to_u32(u32 *val, u8 seq_num[HDCP_2_2_SEQ_NUM_LEN])
+{
+ *val = seq_num[2] | seq_num[1] << 8 | seq_num[0] << 16;
+}
+
+static inline void drm_hdcp2_u32_to_seq_num(u8 *seq_num, u32 val)
+{
+ seq_num[0] = (val & (0xff << 16)) >> 16;
+ seq_num[1] = (val & (0xff << 8)) >> 8;
+ seq_num[2] = val & 0xff;
+}
+
#endif
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 04/39] component: alloc component_match without any comp to match
If all the components associated to a component master is not added
to the component framework due to the HW capability or Kconfig
selection, component_match will be NULL at
component_master_add_with_match().
To avoid this, component_match_alloc() is added to the framework,
to allcoate the struct component_match with zero associated components.
Hence component master can be added with a component_match with zero
associated components.
This helps the component master bind call to get triggered,
even if no component is registered for that particular master.
This is meant for big PCI device drivers where small/optional
features are external components, and based on usecases different
combination of components are build as entire driver.
In such PCI device driver Load, if we use the component master for
waiting for few components(features) availability, only if they are
supported by the underlying HW, then we need to allocate memory for
component_match using the API introduced in this change before
the call to component_master_add_with_match.
v2:
No Change.
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Kate Stewart
Cc: Thomas Gleixner
Cc: Philippe Ombredanne
Cc: linux-ker...@vger.kernel.org
---
drivers/base/component.c | 30 ++
include/linux/component.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index e8d676fad0c9..0ab36b2255ea 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -312,6 +312,36 @@ static int component_match_realloc(struct device *dev,
}
/*
+ * Allocate the match without any component_match_array elements.
+ *
+ * This function is useful when the component master might end up
+ * registering itself without any matching components.
+ */
+void component_match_alloc(struct device *master,
+ struct component_match **matchptr)
+{
+ struct component_match *match = *matchptr;
+
+ if (IS_ERR(match))
+ return;
+
+ if (match)
+ return;
+
+ match = devres_alloc(devm_component_match_release,
+sizeof(*match), GFP_KERNEL);
+ if (!match) {
+ *matchptr = ERR_PTR(-ENOMEM);
+ return;
+ }
+
+ devres_add(master, match);
+
+ *matchptr = match;
+}
+EXPORT_SYMBOL(component_match_alloc);
+
+/*
* Add a component to be matched, with a release function.
*
* The match array is first created or extended if necessary.
diff --git a/include/linux/component.h b/include/linux/component.h
index e71fbbbc74e2..3f6b420a58f8 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -37,6 +37,8 @@ void component_match_add_release(struct device *master,
struct component_match **matchptr,
void (*release)(struct device *, void *),
int (*compare)(struct device *, void *), void *compare_data);
+void component_match_alloc(struct device *master,
+ struct component_match **matchptr);
static inline void component_match_add(struct device *master,
struct component_match **matchptr,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 00/39] drm/i915: Implement HDCP2.2
This series enables the HDCP2.2 for I915. The sequence for HDCP2.2 authentication and encryption is implemented as a generic flow between HDMI and DP. Encoder specific implementations are moved into hdcp_shim. Intel HWs supports HDCP2.2 through ME FW. Hence this series introduces a client driver for mei bus, so that for HDCP2.2 authentication, HDCP2.2 stack in I915 can avail the services from ME FW. To enable this client driver set the config variable CONFIG_INTEL_MEI_HDCP. Userspace interface remains unchanged as version agnostic. When userspace request for HDCP enable, Kernel will detect the HDCP source and sink's HDCP version(1.4/2.2)capability and enable the best capable version for that combination. This series enables the HDCP2.2 for Type0 content strams. Major changes in v9: - Mei_hdcp component binding status will impact I915_load [Daniel]. - worker for sysfs unbind from daniel. - i915-mei_hdcp interface defined at i915_mei_hdcp_interface.h - Same check_work is used for HDCP1.4 and 2.2 link check. [Daniel] - seq_num to and from u32 is done through a helper. [Daniel] - hdcp_wired_protocol() is replaced with a const [Daniel] - Kdocs are added to mei_hdcp.c [Tomas] - i915 port -> mei_ddi_index conversion moved to mei_hdcp [Tomas] - SW tracking of the HDCP spec enabled is used [Daniel] Hopefully covered all suggestions from Tomas and Daniel. To ease the review process, series is hosted at https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v9 Daniel Vetter (1): drivers/base: use a worker for sysfs unbind Ramalingam C (36): drm/i915: Gathering the HDCP1.4 routines together drm: header for i915 - MEI_HDCP interface component: alloc component_match without any comp to match drm/i915: component master at i915 driver load drm/i915: Initialize HDCP2.2 drm/i915: MEI interface definition drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking drm/i915: Enable and Disable of HDCP2.2 drm/i915: Implement HDCP2.2 receiver authentication drm: helper functions for hdcp2 seq_num to from u32 drm/i915: Implement HDCP2.2 repeater authentication drm: HDCP2.2 link check related constants drm/i915: Implement HDCP2.2 link integrity check drm/i915: Handle HDCP2.2 downstream topology change drm/i915: Implement the HDCP2.2 support for DP drm/i915: Implement the HDCP2.2 support for HDMI drm/i915: Add HDCP2.2 support for DP connectors drm/i915: Add HDCP2.2 support for HDMI connectors misc/mei/hdcp: Client driver for HDCP application misc/mei/hdcp: Define ME FW interface for HDCP2.2 misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session misc/mei/hdcp: Verify Receiver Cert and prepare km misc/mei/hdcp: Verify H_prime misc/mei/hdcp: Store the HDCP Pairing info misc/mei/hdcp: Initiate Locality check misc/mei/hdcp: Verify L_prime misc/mei/hdcp: Prepare Session Key misc/mei/hdcp: Repeater topology verification and ack misc/mei/hdcp: Verify M_prime misc/mei/hdcp: Enabling the HDCP authentication misc/mei/hdcp: Closing wired HDCP2.2 Tx Session misc/mei/hdcp: Component framework for I915 Interface drm/i915: Commit CP without modeset drm/i915: Fix KBL HDCP2.2 encrypt status signalling FOR_TEST: i915/Kconfig: Select mei_hdcp by I915 FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4 Tomas Winkler (2): mei: bus: whitelist hdcp client mei: bus: export to_mei_cl_device for mei client device drivers drivers/base/bus.c| 35 +- drivers/base/component.c | 30 + drivers/gpu/drm/i915/i915_debugfs.c | 10 +- drivers/gpu/drm/i915/i915_drv.c | 86 ++- drivers/gpu/drm/i915/i915_drv.h |3 + drivers/gpu/drm/i915/intel_ddi.c |7 - drivers/gpu/drm/i915/intel_display.c | 10 + drivers/gpu/drm/i915/intel_dp.c | 315 - drivers/gpu/drm/i915/intel_drv.h | 74 ++- drivers/gpu/drm/i915/intel_hdcp.c | 1178 + drivers/gpu/drm/i915/intel_hdmi.c | 192 +- drivers/misc/mei/Kconfig |8 + drivers/misc/mei/Makefile |2 + drivers/misc/mei/bus-fixup.c | 16 + drivers/misc/mei/bus.c|1 - drivers/misc/mei/hdcp/Makefile|7 + drivers/misc/mei/hdcp/mei_hdcp.c | 807 ++ drivers/misc/mei/hdcp/mei_hdcp.h | 394 +++ include/drm/drm_hdcp.h| 26 + include/drm/i915_component.h | 18 + include/drm/i915_mei_hdcp_interface.h | 132 include/linux/component.h |2 + include/linux/mei_cl_bus.h|2 + 23 files changed, 3207 insertions(+), 148 deletions(-) create mode 100644 drivers/misc/mei/hdcp/Makefile create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h create mode 100644 include/drm/i915_mei_hdcp_interface.h -- 2.7.4 ___ Intel-gfx mailing list
[Intel-gfx] [PATCH v9 05/39] drm/i915: component master at i915 driver load
A generic component master is added to hold the i915 registration
until all required kernel modules are up and active.
This is achieved through following steps:
- moving the i915 driver registration to the component master's
bind call
- all required kernel modules will add one component each to
component_match of I915 component master.
If no component is added to the I915 component master, due to CONFIG
selection or HW limitation, component master's bind call (i915
registration) will be triggered with no wait.
Similarly when a associated component is removed for some reasons,
I915 will be unregistered through component master unbind.
v2:
i915_driver_unregister is added to the unbind of master.
v3:
In master_unbind i915_unregister->drm_atomic_helper_shutdown->
component_unbind_all [Daniel]
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 86 +
drivers/gpu/drm/i915/i915_drv.h | 3 ++
include/drm/i915_component.h| 11 ++
3 files changed, 92 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b310a897a4ad..b8a204072e60 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -39,12 +39,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include "i915_drv.h"
#include "i915_trace.h"
@@ -1577,8 +1579,6 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
if (IS_GEN5(dev_priv))
intel_gpu_ips_init(dev_priv);
- intel_audio_init(dev_priv);
-
/*
* Some ports require correctly set-up hpd registers for detection to
* work properly (leading to ghost connected connector status), e.g. VGA
@@ -1609,7 +1609,6 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
intel_power_domains_disable(dev_priv);
intel_fbdev_unregister(dev_priv);
- intel_audio_deinit(dev_priv);
/*
* After flushing the fbdev (incl. a late async config which will
@@ -1694,6 +1693,48 @@ static void i915_driver_destroy(struct drm_i915_private
*i915)
pci_set_drvdata(pdev, NULL);
}
+static void i915_driver_load_tail(struct drm_i915_private *dev_priv)
+{
+ i915_driver_register(dev_priv);
+
+ DRM_INFO("load_tail: I915 driver registered\n");
+}
+
+static void i915_driver_unload_head(struct drm_i915_private *dev_priv)
+{
+ i915_driver_unregister(dev_priv);
+
+ DRM_INFO("unload_head: I915 driver unregistered\n");
+}
+
+static int i915_component_master_bind(struct device *dev)
+{
+ struct drm_i915_private *dev_priv = kdev_to_i915(dev);
+ int ret;
+
+ ret = component_bind_all(dev, dev_priv->comp_master);
+ if (ret < 0)
+ return ret;
+
+ i915_driver_load_tail(dev_priv);
+
+ return 0;
+}
+
+static void i915_component_master_unbind(struct device *dev)
+{
+ struct drm_i915_private *dev_priv = kdev_to_i915(dev);
+
+ i915_driver_unload_head(dev_priv);
+ drm_atomic_helper_shutdown(_priv->drm);
+ component_unbind_all(dev, dev_priv->comp_master);
+}
+
+static const struct component_master_ops i915_component_master_ops = {
+ .bind = i915_component_master_bind,
+ .unbind = i915_component_master_unbind,
+};
+
/**
* i915_driver_load - setup chip and create an initial config
* @pdev: PCI device
@@ -1720,9 +1761,22 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (!i915_modparams.nuclear_pageflip && match_info->gen < 5)
dev_priv->drm.driver_features &= ~DRIVER_ATOMIC;
+ dev_priv->comp_master = kzalloc(sizeof(*dev_priv->comp_master),
+ GFP_KERNEL);
+ if (!dev_priv->comp_master) {
+ ret = -ENOMEM;
+ goto out_fini;
+ }
+
+ component_match_alloc(dev_priv->drm.dev, _priv->master_match);
+ if (!dev_priv->master_match) {
+ ret = -ENOMEM;
+ goto out_comp_master_clean;
+ }
+
ret = pci_enable_device(pdev);
if (ret)
- goto out_fini;
+ goto out_comp_master_clean;
ret = i915_driver_init_early(dev_priv);
if (ret < 0)
@@ -1742,14 +1796,27 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret < 0)
goto out_cleanup_hw;
- i915_driver_register(dev_priv);
+ ret = component_master_add_with_match(dev_priv->drm.dev,
+ _component_master_ops,
+ dev_priv->master_match);
+ if (ret < 0) {
+ DRM_DEV_ERROR(>dev, "Master comp add failed %d\n",
+ ret);
+ goto out_cleanup_modeset;
+ }
+
+
[Intel-gfx] [PATCH v9 01/39] drm/i915: Gathering the HDCP1.4 routines together
All HDCP1.4 routines are gathered together, followed by the generic
functions those can be extended for HDCP2.2 too.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 118 +++---
1 file changed, 59 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index e000e54ad569..506b4cc6f46b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -731,6 +731,65 @@ struct intel_connector *intel_hdcp_to_connector(struct
intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
}
+/* Implements Part 3 of the HDCP authorization procedure */
+int intel_hdcp_check_link(struct intel_connector *connector)
+{
+ struct intel_hdcp *hdcp = >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;
+ int ret = 0;
+
+ if (!hdcp->shim)
+ return -ENOENT;
+
+ mutex_lock(>mutex);
+
+ if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ goto out;
+
+ if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
+ DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
+ connector->base.name, connector->base.base.id,
+ I915_READ(PORT_HDCP_STATUS(port)));
+ ret = -ENXIO;
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ goto out;
+ }
+
+ if (hdcp->shim->check_link(intel_dig_port)) {
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(>prop_work);
+ }
+ goto out;
+ }
+
+ DRM_DEBUG_KMS("[%s:%d] HDCP link failed, retrying authentication\n",
+ connector->base.name, connector->base.base.id);
+
+ ret = _intel_hdcp_disable(connector);
+ if (ret) {
+ DRM_ERROR("Failed to disable hdcp (%d)\n", ret);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ goto out;
+ }
+
+ ret = _intel_hdcp_enable(connector);
+ if (ret) {
+ DRM_ERROR("Failed to enable hdcp (%d)\n", ret);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ goto out;
+ }
+
+out:
+ mutex_unlock(>mutex);
+ return ret;
+}
+
static void intel_hdcp_check_work(struct work_struct *work)
{
struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
@@ -867,62 +926,3 @@ void intel_hdcp_atomic_check(struct drm_connector
*connector,
new_state->crtc);
crtc_state->mode_changed = true;
}
-
-/* Implements Part 3 of the HDCP authorization procedure */
-int intel_hdcp_check_link(struct intel_connector *connector)
-{
- struct intel_hdcp *hdcp = >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;
- int ret = 0;
-
- if (!hdcp->shim)
- return -ENOENT;
-
- mutex_lock(>mutex);
-
- if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
- goto out;
-
- if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
- DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
- connector->base.name, connector->base.base.id,
- I915_READ(PORT_HDCP_STATUS(port)));
- ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(>prop_work);
- goto out;
- }
-
- if (hdcp->shim->check_link(intel_dig_port)) {
- if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(>prop_work);
- }
- goto out;
- }
-
- DRM_DEBUG_KMS("[%s:%d] HDCP link failed, retrying authentication\n",
- connector->base.name, connector->base.base.id);
-
- ret = _intel_hdcp_disable(connector);
- if (ret) {
- DRM_ERROR("Failed to disable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(>prop_work);
- goto out;
- }
-
- ret = _intel_hdcp_enable(connector);
- if (ret) {
- DRM_DEBUG_KMS("Failed
[Intel-gfx] [PATCH v9 06/39] drm/i915: Initialize HDCP2.2
Add the HDCP2.2 initialization to the existing HDCP1.4 stack.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out of mem [Uma]
Inline req for init function removed [Uma]
v5:
Rebase as Part of reordering.
Component is used for the I915 and MEI_HDCP interface [Daniel]
v6:
HDCP2.2 uses the I915 component master to communicate with mei_hdcp
- [Daniel]
Required HDCP2.2 variables defined [Sean Paul]
v7:
intel_hdcp2.2_init returns void [Uma]
Realigning the codes.
v8:
Avoid using bool structure members.
MEI interface related changes are moved into separate patch.
Commit msg is updated accordingly.
intel_hdcp_exit is defined and used from i915_unload
v9:
Movement of the hdcp_check_link is moved to new patch [Daniel]
intel_hdcp2_exit is removed as mei_comp will be unbind in i915_unload.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 3 ++-
drivers/gpu/drm/i915/intel_drv.h | 15 ++-
drivers/gpu/drm/i915/intel_hdcp.c | 30 +++---
drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
4 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e94faa0a42eb..aba884c64879 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6902,7 +6902,8 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dp_add_properties(intel_dp, connector);
if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
- int ret = intel_hdcp_init(intel_connector, _dp_hdcp_shim);
+ int ret = intel_hdcp_init(intel_connector, _dp_hdcp_shim,
+ false);
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d08f08f607dd..dd9371647a8c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -388,6 +388,17 @@ struct intel_hdcp {
u64 value;
struct delayed_work check_work;
struct work_struct prop_work;
+
+ /* HDCP2.2 related definitions */
+ /* Flag indicates whether this connector supports HDCP2.2 or not. */
+ u8 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;
};
struct intel_connector {
@@ -2038,12 +2049,14 @@ void intel_hdcp_atomic_check(struct drm_connector
*connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
int intel_hdcp_init(struct intel_connector *connector,
- const struct intel_hdcp_shim *hdcp_shim);
+ const struct intel_hdcp_shim *hdcp_shim,
+ bool hdcp2_supported);
int intel_hdcp_enable(struct intel_connector *connector);
int intel_hdcp_disable(struct intel_connector *connector);
int intel_hdcp_check_link(struct intel_connector *connector);
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
bool intel_hdcp_capable(struct intel_connector *connector);
+bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
/* intel_psr.c */
#define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 506b4cc6f46b..584d27f3c699 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -833,14 +833,34 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
}
+bool is_hdcp2_supported(struct drm_i915_private *dev_priv)
+{
+ return ((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
+IS_KABYLAKE(dev_priv)) && IS_ENABLED(CONFIG_INTEL_MEI_HDCP));
+}
+
+static void intel_hdcp2_init(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
+
+ WARN_ON(!is_hdcp2_supported(dev_priv));
+
+ /* TODO: MEI interface needs to be initialized here */
+ hdcp->hdcp2_supported = 1;
+}
+
int intel_hdcp_init(struct intel_connector *connector,
- const struct intel_hdcp_shim *shim)
+ const struct intel_hdcp_shim *shim,
+ bool hdcp2_supported)
{
struct intel_hdcp *hdcp = >hdcp;
int ret;
- ret = drm_connector_attach_content_protection_property(
- >base);
+
[Intel-gfx] [PATCH v9 07/39] drm/i915: MEI interface definition
Defining the mei-i915 interface functions and initialization of
the interface.
v2:
Adjust to the new interface changes. [Tomas]
Added further debug logs for the failures at MEI i/f.
port in hdcp_port data is equipped to handle -ve values.
v3:
mei comp is matched for global i915 comp master. [Daniel]
In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
mei wrappers are adjusted as per the i/f change [Daniel]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drv.h | 5 +
drivers/gpu/drm/i915/intel_hdcp.c | 248 +-
include/drm/i915_component.h | 7 ++
3 files changed, 259 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dd9371647a8c..191b6e0f086c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
/**
@@ -379,6 +380,9 @@ 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);
+
+ /* HDCP adaptation(DP/HDMI) required on the port */
+ enum hdcp_wired_protocol protocol;
};
struct intel_hdcp {
@@ -399,6 +403,7 @@ struct intel_hdcp {
* content can flow only through a link protected by HDCP2.2.
*/
u8 content_type;
+ struct hdcp_port_data port_data;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 584d27f3c699..9405fce07b93 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -8,8 +8,10 @@
#include
#include
+#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
@@ -833,6 +835,232 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
}
+static __attribute__((unused)) int
+hdcp2_prepare_ake_init(struct intel_connector *connector,
+ struct hdcp2_ake_init *ake_data)
+{
+ struct hdcp_port_data *data = >hdcp.port_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_component_master *comp = dev_priv->comp_master;
+ int ret;
+
+ /* During the connector init encoder might not be initialized */
+ if (data->port == PORT_NONE)
+ data->port = connector->encoder->port;
+
+ ret = comp->hdcp_ops->initiate_hdcp2_session(comp->mei_dev,
+data, ake_data);
+ if (ret)
+ DRM_DEBUG_KMS("Prepare_ake_init failed. %d\n", ret);
+
+ return ret;
+}
+
+static __attribute__((unused)) int
+hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
+ struct hdcp2_ake_send_cert *rx_cert,
+ bool *paired,
+ struct hdcp2_ake_no_stored_km *ek_pub_km,
+ size_t *msg_sz)
+{
+ struct hdcp_port_data *data = >hdcp.port_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_component_master *comp = dev_priv->comp_master;
+ int ret;
+
+ ret = comp->hdcp_ops->verify_receiver_cert_prepare_km(comp->mei_dev,
+ data, rx_cert,
+ paired, ek_pub_km,
+ msg_sz);
+ if (ret < 0)
+ DRM_DEBUG_KMS("Verify rx_cert failed. %d\n", ret);
+
+ return ret;
+}
+
+static __attribute__((unused)) int
+hdcp2_verify_hprime(struct intel_connector *connector,
+ struct hdcp2_ake_send_hprime *rx_hprime)
+{
+ struct hdcp_port_data *data = >hdcp.port_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_component_master *comp = dev_priv->comp_master;
+ int ret;
+
+ ret = comp->hdcp_ops->verify_hprime(comp->mei_dev, data, rx_hprime);
+ if (ret < 0)
+ DRM_DEBUG_KMS("Verify hprime failed. %d\n", ret);
+
+ return ret;
+}
+
+static __attribute__((unused)) int
+hdcp2_store_pairing_info(struct intel_connector *connector,
+struct hdcp2_ake_send_pairing_info *pairing_info)
+{
+ struct hdcp_port_data *data = >hdcp.port_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_component_master *comp = dev_priv->comp_master;
+ int ret;
+
+ ret = comp->hdcp_ops->store_pairing_info(comp->mei_dev, data,
+pairing_info);
+ if (ret < 0)
+ DRM_DEBUG_KMS("Store pairing info failed.
[Intel-gfx] [PATCH v9 02/39] drm: header for i915 - MEI_HDCP interface
Header defines the interface for the I915 and MEI_HDCP drivers.
Signed-off-by: Ramalingam C
---
include/drm/i915_mei_hdcp_interface.h | 132 ++
1 file changed, 132 insertions(+)
create mode 100644 include/drm/i915_mei_hdcp_interface.h
diff --git a/include/drm/i915_mei_hdcp_interface.h
b/include/drm/i915_mei_hdcp_interface.h
new file mode 100644
index ..e3b7fb32612a
--- /dev/null
+++ b/include/drm/i915_mei_hdcp_interface.h
@@ -0,0 +1,132 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Authors:
+ * Ramalingam C
+ */
+
+#ifndef _I915_MEI_HDCP_INTERFACE_H_
+#define _I915_MEI_HDCP_INTERFACE_H_
+
+#include
+#include
+
+/**
+ * enum hdcp_port_type - HDCP port implementation type defined by ME FW
+ * @HDCP_PORT_TYPE_INVALID: Invalid hdcp port type
+ * @HDCP_PORT_TYPE_INTEGRATED: In-Host HDCP2.x port
+ * @HDCP_PORT_TYPE_LSPCON: HDCP2.2 discrete wired Tx port with LSPCON
+ *(HDMI 2.0) solution
+ * @HDCP_PORT_TYPE_CPDP: HDCP2.2 discrete wired Tx port using the CPDP (DP 1.3)
+ * solution
+ */
+enum hdcp_port_type {
+ HDCP_PORT_TYPE_INVALID,
+ HDCP_PORT_TYPE_INTEGRATED,
+ HDCP_PORT_TYPE_LSPCON,
+ HDCP_PORT_TYPE_CPDP
+};
+
+/**
+ * enum hdcp_wired_protocol - HDCP adaptation used on the port
+ * @HDCP_PROTOCOL_INVALID: Invalid HDCP adaptation protocol
+ * @HDCP_PROTOCOL_HDMI: HDMI adaptation of HDCP used on the port
+ * @HDCP_PROTOCOL_DP: DP adaptation of HDCP used on the port
+ */
+enum hdcp_wired_protocol {
+ HDCP_PROTOCOL_INVALID,
+ HDCP_PROTOCOL_HDMI,
+ HDCP_PROTOCOL_DP
+};
+
+/**
+ * struct hdcp_port_data - intel specific HDCP port data
+ * @port: port index as per I915
+ * @port_type: HDCP port type as per ME FW classification
+ * @protocol: HDCP adaptation as per ME FW
+ * @k: No of streams transmitted on a port. Only on DP MST this is != 1
+ * @seq_num_m: 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.
+ * @streams: struct hdcp2_streamid_type[k]. Defines the type and id for the
+ * streams
+ */
+struct hdcp_port_data {
+ short int port;
+ u8 port_type;
+ u8 protocol;
+ u16 k;
+ u32 seq_num_m;
+ struct hdcp2_streamid_type *streams;
+};
+
+/**
+ * struct i915_hdcp_component_ops- ops for HDCP2.2 services.
+ * @owner: Module providing the ops
+ * @initiate_hdcp2_session: Initiate a Wired HDCP2.2 Tx Session.
+ * And Prepare AKE_Init.
+ * @verify_receiver_cert_prepare_km: Verify the Receiver Certificate
+ * AKE_Send_Cert and prepare
+AKE_Stored_Km/AKE_No_Stored_Km
+ * @verify_hprime: Verify AKE_Send_H_prime
+ * @store_pairing_info: Store pairing info received
+ * @initiate_locality_check: Prepare LC_Init
+ * @verify_lprime: Verify lprime
+ * @get_session_key: Prepare SKE_Send_Eks
+ * @repeater_check_flow_prepare_ack: Validate the Downstream topology
+ * and prepare rep_ack
+ * @verify_mprime: Verify mprime
+ * @enable_hdcp_authentication: Mark a port as authenticated.
+ * @close_hdcp_session: Close the Wired HDCP Tx session per port.
+ * This also disables the authenticated state of the port.
+ */
+struct i915_hdcp_component_ops {
+ /**
+* @owner: mei_hdcp module
+*/
+ struct module *owner;
+
+ int (*initiate_hdcp2_session)(struct device *dev,
+ struct hdcp_port_data *data,
+ struct hdcp2_ake_init *ake_data);
+ int (*verify_receiver_cert_prepare_km)(struct device *dev,
+ struct hdcp_port_data *data,
+ struct hdcp2_ake_send_cert
+ *rx_cert,
+ bool *km_stored,
+ struct hdcp2_ake_no_stored_km
+ *ek_pub_km,
+ size_t *msg_sz);
+ int (*verify_hprime)(struct device *dev,
+struct hdcp_port_data *data,
+struct hdcp2_ake_send_hprime *rx_hprime);
+ int (*store_pairing_info)(struct device *dev,
+ struct hdcp_port_data *data,
+ struct hdcp2_ake_send_pairing_info
+ *pairing_info);
+ int (*initiate_locality_check)(struct device *dev,
+ struct
[Intel-gfx] [PATCH v9 03/39] drivers/base: use a worker for sysfs unbind
From: Daniel Vetter
Drivers might want to remove some sysfs files, which needs the same
locks and ends up angering lockdep. Relevant snippet of the stack
trace:
kernfs_remove_by_name_ns+0x3b/0x80
bus_remove_driver+0x92/0xa0
acpi_video_unregister+0x24/0x40
i915_driver_unload+0x42/0x130 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x36/0xb0
device_release_driver_internal+0x185/0x250
unbind_store+0xaf/0x180
kernfs_fop_write+0x104/0x190
I've stumbled over this because some new patches by Ram connect the
snd-hda-intel unload (where we do use sysfs unbind) with the locking
chains in the i915 unload code (but without creating a new loop),
which upset our CI. But the bug is already there and can be easily
reproduced by unbind i915 directly.
No idea whether this is the correct place to fix this, should at least
get CI happy again.
Note that the bus locking is already done by device_release_driver ->
device_release_driver_internal, so I dropped that part. Also note that
we don't recheck that the device is still bound by the same driver,
but neither does the current code do that without races. And I figured
that's a obscure enough corner case to not bother.
v2: Use a task work. An entirely async work leads to impressive
fireworks in our CI, notably in the vtcon bind/unbind code. Task work
will be as synchronous as the current code, and so keep all these
preexisting races neatly tugged under the rug.
Cc: Ramalingam C
Signed-off-by: Daniel Vetter
---
drivers/base/bus.c | 35 +--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 8bfd27ec73d6..095c4a140d76 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include "base.h"
#include "power/power.h"
@@ -174,22 +175,44 @@ static const struct kset_uevent_ops bus_uevent_ops = {
static struct kset *bus_kset;
+struct unbind_work {
+ struct callback_head twork;
+ struct device *dev;
+};
+
+void unbind_work_fn(struct callback_head *work)
+{
+ struct unbind_work *unbind_work =
+ container_of(work, struct unbind_work, twork);
+
+ device_release_driver_internal(unbind_work->dev, NULL,
+ unbind_work->dev->parent);
+ put_device(unbind_work->dev);
+ kfree(unbind_work);
+}
+
/* Manually detach a device from its associated driver. */
static ssize_t unbind_store(struct device_driver *drv, const char *buf,
size_t count)
{
struct bus_type *bus = bus_get(drv->bus);
+ struct unbind_work *unbind_work;
struct device *dev;
int err = -ENODEV;
dev = bus_find_device_by_name(bus, NULL, buf);
if (dev && dev->driver == drv) {
- if (dev->parent && dev->bus->need_parent_lock)
- device_lock(dev->parent);
- device_release_driver(dev);
- if (dev->parent && dev->bus->need_parent_lock)
- device_unlock(dev->parent);
- err = count;
+ unbind_work = kmalloc(sizeof(*unbind_work), GFP_KERNEL);
+ if (unbind_work) {
+ unbind_work->dev = dev;
+ get_device(dev);
+ init_task_work(_work->twork, unbind_work_fn);
+ task_work_add(current, _work->twork, true);
+
+ err = count;
+ } else {
+ err = -ENOMEM;
+ }
}
put_device(dev);
bus_put(bus);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 08/39] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking
"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable
and hdcp_check_link upon CP_IRQ.
On CP_IRQ we filter the CP_IRQ related to the states like Link failure
and reauthentication req etc and handle them in hdcp_check_link.
CP_IRQ corresponding to the authentication msg availability are ignored.
WARN_ON is added for the abrupt stop of HDCP encryption of a port.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 5 ++-
drivers/gpu/drm/i915/intel_hdcp.c | 89 ++-
3 files changed, 74 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index aba884c64879..89315e15fb34 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4758,7 +4758,7 @@ static void intel_dp_check_service_irq(struct intel_dp
*intel_dp)
intel_dp_handle_test_request(intel_dp);
if (val & DP_CP_IRQ)
- intel_hdcp_check_link(intel_dp->attached_connector);
+ intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
if (val & DP_SINK_SPECIFIC_IRQ)
DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 191b6e0f086c..decd0346c6a7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -393,6 +393,9 @@ struct intel_hdcp {
struct delayed_work check_work;
struct work_struct prop_work;
+ /* HDCP1.4 Encryption status */
+ u8 hdcp_encrypted;
+
/* HDCP2.2 related definitions */
/* Flag indicates whether this connector supports HDCP2.2 or not. */
u8 hdcp2_supported;
@@ -2058,10 +2061,10 @@ int intel_hdcp_init(struct intel_connector *connector,
bool hdcp2_supported);
int intel_hdcp_enable(struct intel_connector *connector);
int intel_hdcp_disable(struct intel_connector *connector);
-int intel_hdcp_check_link(struct intel_connector *connector);
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
bool intel_hdcp_capable(struct intel_connector *connector);
bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
+void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
/* intel_psr.c */
#define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 9405fce07b93..2b7814a6f12b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -75,6 +75,16 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
}
+static inline bool intel_hdcp_in_use(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ enum port port = connector->encoder->port;
+ u32 reg;
+
+ reg = I915_READ(PORT_HDCP_STATUS(port));
+ return reg & HDCP_STATUS_ENC;
+}
+
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
{
@@ -669,6 +679,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ hdcp->hdcp_encrypted = 0;
I915_WRITE(PORT_HDCP_CONF(port), 0);
if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
@@ -714,8 +725,10 @@ 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), hdcp->shim);
- if (!ret)
+ if (!ret) {
+ hdcp->hdcp_encrypted = 1;
return 0;
+ }
DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
@@ -742,16 +755,17 @@ int intel_hdcp_check_link(struct intel_connector
*connector)
enum port port = intel_dig_port->base.port;
int ret = 0;
- if (!hdcp->shim)
- return -ENOENT;
-
mutex_lock(>mutex);
- if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ /* Check_link valid only when HDCP1.4 is enabled */
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED ||
+ !hdcp->hdcp_encrypted) {
+ ret = -EINVAL;
goto out;
+ }
- if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
- DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
+ if
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well
On Wed, Dec 12, 2018 at 04:32:02PM -0800, Dhinakaran Pandiyan wrote:
> On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Fill out the AVI infoframe quantization range bits using
> > drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_sdvo.c | 19 ++-
> > 1 file changed, 10 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > b/drivers/gpu/drm/i915/intel_sdvo.c
> > index 1277d31adb54..9c16e273fb8d 100644
> > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > @@ -984,6 +984,8 @@ static bool intel_sdvo_set_avi_infoframe(struct
> > intel_sdvo *intel_sdvo,
> > const struct intel_crtc_state
> > *pipe_config,
> > const struct
> > drm_connector_state *conn_state)
> > {
> > + const struct drm_display_mode *adjusted_mode =
> > + _config->base.adjusted_mode;
> > uint8_t sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
> > union hdmi_infoframe frame;
> > int ret;
> > @@ -991,20 +993,19 @@ static bool intel_sdvo_set_avi_infoframe(struct
> > intel_sdvo *intel_sdvo,
> >
> > ret = drm_hdmi_avi_infoframe_from_display_mode(,
> >conn_state-
> > >connector,
> > - _config-
> > >base.adjusted_mode);
> > + adjusted_mode);
> > if (ret < 0) {
> > DRM_ERROR("couldn't fill AVI infoframe\n");
> > return false;
> > }
> >
> > - if (intel_sdvo->rgb_quant_range_selectable) {
> > - if (pipe_config->limited_color_range)
> > - frame.avi.quantization_range =
> > - HDMI_QUANTIZATION_RANGE_LIMITED;
> > - else
> > - frame.avi.quantization_range =
> > - HDMI_QUANTIZATION_RANGE_FULL;
> > - }
> > + drm_hdmi_avi_infoframe_quant_range(,
> > + conn_state->connector,
> > + adjusted_mode,
> > + pipe_config-
> > >limited_color_range ?
> > + rgb_quant_range_selectableTE
> > D :
> > + HDMI_QUANTIZATION_RANGE_FULL
> > ,
> > + intel_sdvo-
> > >rgb_quant_range_selectable);
>
> Seems like avi.quantization_range can now get set to _LIMITED or _FULL
> even when ->rgb_quant_range_selectable == false, i.e., it is not
> _DEFAULT anymore. Is that change in behavior intended?
->quant_range_selectable will be passed to
drm_hdmi_avi_infoframe_quant_range() which will do the right thing with
it.
That said, there is a slight behavioural change in that it will set
the Q bit even with QS==1 iff the quantization range matches the
default quantization range for the mode. I noted this in the radeon
patch but forgot to mention it here.
>
>
> >
> > len = hdmi_infoframe_pack(, sdvo_data,
> > sizeof(sdvo_data));
> > if (len < 0)
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: merge gen checks to use range
On Tue, Dec 11, 2018 at 04:35:57PM +0200, Jani Nikula wrote:
> On Wed, 05 Dec 2018, Lucas De Marchi wrote:
> > Instead of using IS_GEN() for consecutive gen checks, let's pass the
> > range to IS_GEN_RANGE(). By code inspection these were the ranges deemed
> > necessary for spatch:
> >
> > @@
> > expression e;
> > @@
> > (
> > - IS_GEN(e, 3) || IS_GEN(e, 2)
> > + IS_GEN_RANGE(e, 2, 3)
> > |
> > - IS_GEN(e, 3) || IS_GEN(e, 4)
> > + IS_GEN_RANGE(e, 3, 4)
> > |
> > - IS_GEN(e, 5) || IS_GEN(e, 6)
> > + IS_GEN_RANGE(e, 5, 6)
> > |
> > - IS_GEN(e, 6) || IS_GEN(e, 7)
> > + IS_GEN_RANGE(e, 6, 7)
> > |
> > - IS_GEN(e, 7) || IS_GEN(e, 8)
> > + IS_GEN_RANGE(e, 7, 8)
> > |
> > - IS_GEN(e, 8) || IS_GEN(e, 9)
> > + IS_GEN_RANGE(e, 8, 9)
> > |
> > - IS_GEN(e, 10) || IS_GEN(e, 9)
> > + IS_GEN_RANGE(e, 9, 10)
> > |
> > - IS_GEN(e, 9) || IS_GEN(e, 10)
> > + IS_GEN_RANGE(e, 9, 10)
> > )
> >
> > After conversion, checking we don't have any missing IS_GEN_RANGE() ||
> > IS_GEN() was also done.
> >
> > Signed-off-by: Lucas De Marchi
>
> Should've just looked at the whole series before commenting on the
> others. It's all
>
> Reviewed-by: Jani Nikula
Thanks.
Pushed.
>
>
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c| 6 +++---
> > drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
> > drivers/gpu/drm/i915/i915_perf.c | 2 +-
> > drivers/gpu/drm/i915/intel_crt.c | 2 +-
> > drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> > drivers/gpu/drm/i915/intel_display.c | 2 +-
> > drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
> > drivers/gpu/drm/i915/intel_fifo_underrun.c | 2 +-
> > drivers/gpu/drm/i915/intel_pipe_crc.c | 4 ++--
> > drivers/gpu/drm/i915/intel_uncore.c| 6 +++---
> > 10 files changed, 15 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 53e3f57a13f3..33ff75c6a4a3 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2034,7 +2034,7 @@ static int i915_swizzle_info(struct seq_file *m, void
> > *data)
> > seq_printf(m, "bit6 swizzle for Y-tiling = %s\n",
> >swizzle_string(dev_priv->mm.bit_6_swizzle_y));
> >
> > - if (IS_GEN(dev_priv, 3) || IS_GEN(dev_priv, 4)) {
> > + if (IS_GEN_RANGE(dev_priv, 3, 4)) {
> > seq_printf(m, "DDC = 0x%08x\n",
> >I915_READ(DCC));
> > seq_printf(m, "DDC2 = 0x%08x\n",
> > @@ -4268,7 +4268,7 @@ i915_cache_sharing_get(void *data, u64 *val)
> > struct drm_i915_private *dev_priv = data;
> > u32 snpcr;
> >
> > - if (!(IS_GEN(dev_priv, 6) || IS_GEN(dev_priv, 7)))
> > + if (!(IS_GEN_RANGE(dev_priv, 6, 7)))
> > return -ENODEV;
> >
> > intel_runtime_pm_get(dev_priv);
> > @@ -4288,7 +4288,7 @@ i915_cache_sharing_set(void *data, u64 val)
> > struct drm_i915_private *dev_priv = data;
> > u32 snpcr;
> >
> > - if (!(IS_GEN(dev_priv, 6) || IS_GEN(dev_priv, 7)))
> > + if (!(IS_GEN_RANGE(dev_priv, 6, 7)))
> > return -ENODEV;
> >
> > if (val > 3)
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index ccfd91c72477..581a40ac3591 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > @@ -1753,7 +1753,7 @@ static void capture_reg_state(struct i915_gpu_state
> > *error)
> > error->ccid = I915_READ(CCID);
> >
> > /* 3: Feature specific registers */
> > - if (IS_GEN(dev_priv, 6) || IS_GEN(dev_priv, 7)) {
> > + if (IS_GEN_RANGE(dev_priv, 6, 7)) {
> > error->gam_ecochk = I915_READ(GAM_ECOCHK);
> > error->gac_eco = I915_READ(GAC_ECO_BITS);
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> > b/drivers/gpu/drm/i915/i915_perf.c
> > index 6c7992320443..4288c0e02f0c 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -3415,7 +3415,7 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
> > dev_priv->perf.oa.ops.read = gen8_oa_read;
> > dev_priv->perf.oa.ops.oa_hw_tail_read = gen8_oa_hw_tail_read;
> >
> > - if (IS_GEN(dev_priv, 8) || IS_GEN(dev_priv, 9)) {
> > + if (IS_GEN_RANGE(dev_priv, 8, 9)) {
> > dev_priv->perf.oa.ops.is_valid_b_counter_reg =
> > gen7_is_valid_b_counter_addr;
> > dev_priv->perf.oa.ops.is_valid_mux_reg =
> > diff --git a/drivers/gpu/drm/i915/intel_crt.c
> > b/drivers/gpu/drm/i915/intel_crt.c
> > index bf4fd739b68c..0a41e58d61de 100644
> > --- a/drivers/gpu/drm/i915/intel_crt.c
> > +++ b/drivers/gpu/drm/i915/intel_crt.c
> > @@ -322,7 +322,7 @@ intel_crt_mode_valid(struct drm_connector *connector,
> > * DAC limit supposedly 355 MHz.
> > */
> > max_clock = 27;
> > - else if (IS_GEN(dev_priv, 3) ||
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Use _MMIO_PIPE3() for ilk+ WM0_PIPE registers
On Wed, Dec 12, 2018 at 11:17:38PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the hand rolled array of WM0_PIPE register offsets
> and use the standard _MMIO_PIPE3() instead.
>
> v2: Take care of gvt too
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 6 +++---
> drivers/gpu/drm/i915/i915_reg.h | 9 +
> drivers/gpu/drm/i915/intel_pm.c | 13 -
> 3 files changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index b5475c91e2ef..2edab387221d 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -2120,9 +2120,9 @@ static int init_generic_mmio_info(struct intel_gvt *gvt)
> MMIO_D(PF_VSCALE(PIPE_C), D_ALL);
> MMIO_D(PF_HSCALE(PIPE_C), D_ALL);
>
> - MMIO_D(WM0_PIPEA_ILK, D_ALL);
> - MMIO_D(WM0_PIPEB_ILK, D_ALL);
> - MMIO_D(WM0_PIPEC_IVB, D_ALL);
> + MMIO_D(WM0_PIPE_ILK(PIPE_A), D_ALL);
> + MMIO_D(WM0_PIPE_ILK(PIPE_B), D_ALL);
> + MMIO_D(WM0_PIPE_ILK(PIPE_C), D_ALL);
> MMIO_D(WM1_LP_ILK, D_ALL);
> MMIO_D(WM2_LP_ILK, D_ALL);
> MMIO_D(WM3_LP_ILK, D_ALL);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ea9a664980a6..246e5e77e7c5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5992,15 +5992,16 @@ enum {
> _MMIO(_PLANE(plane, _PLANE_WM_TRANS_1(pipe), _PLANE_WM_TRANS_2(pipe)))
>
> /* define the Watermark register on Ironlake */
> -#define WM0_PIPEA_ILK_MMIO(0x45100)
> +#define _WM0_PIPEA_ILK 0x45100
> +#define _WM0_PIPEB_ILK 0x45104
> +#define _WM0_PIPEC_IVB 0x45200
> +#define WM0_PIPE_ILK(pipe) _MMIO_PIPE3((pipe), _WM0_PIPEA_ILK, \
> + _WM0_PIPEB_ILK, _WM0_PIPEC_IVB)
> #define WM0_PIPE_PLANE_MASK (0x << 16)
> #define WM0_PIPE_PLANE_SHIFT16
> #define WM0_PIPE_SPRITE_MASK(0xff << 8)
> #define WM0_PIPE_SPRITE_SHIFT 8
> #define WM0_PIPE_CURSOR_MASK(0xff)
> -
> -#define WM0_PIPEB_ILK_MMIO(0x45104)
> -#define WM0_PIPEC_IVB_MMIO(0x45200)
> #define WM1_LP_ILK _MMIO(0x45108)
> #define WM1_LP_SR_EN(1 << 31)
> #define WM1_LP_LATENCY_SHIFT24
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6ebde7bbac4e..46f8c8728847 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3555,11 +3555,11 @@ static void ilk_write_wm_values(struct
> drm_i915_private *dev_priv,
> _ilk_disable_lp_wm(dev_priv, dirty);
>
> if (dirty & WM_DIRTY_PIPE(PIPE_A))
> - I915_WRITE(WM0_PIPEA_ILK, results->wm_pipe[0]);
> + I915_WRITE(WM0_PIPE_ILK(PIPE_A), results->wm_pipe[0]);
> if (dirty & WM_DIRTY_PIPE(PIPE_B))
> - I915_WRITE(WM0_PIPEB_ILK, results->wm_pipe[1]);
> + I915_WRITE(WM0_PIPE_ILK(PIPE_B), results->wm_pipe[1]);
> if (dirty & WM_DIRTY_PIPE(PIPE_C))
> - I915_WRITE(WM0_PIPEC_IVB, results->wm_pipe[2]);
> + I915_WRITE(WM0_PIPE_ILK(PIPE_C), results->wm_pipe[2]);
>
> if (dirty & WM_DIRTY_LINETIME(PIPE_A))
> I915_WRITE(PIPE_WM_LINETIME(PIPE_A), results->wm_linetime[0]);
> @@ -5647,13 +5647,8 @@ static void ilk_pipe_wm_get_hw_state(struct intel_crtc
> *crtc)
> struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->base.state);
> struct ilk_pipe_wm *active = >wm.ilk.optimal;
> enum pipe pipe = crtc->pipe;
> - static const i915_reg_t wm0_pipe_reg[] = {
> - [PIPE_A] = WM0_PIPEA_ILK,
> - [PIPE_B] = WM0_PIPEB_ILK,
> - [PIPE_C] = WM0_PIPEC_IVB,
> - };
>
> - hw->wm_pipe[pipe] = I915_READ(wm0_pipe_reg[pipe]);
> + hw->wm_pipe[pipe] = I915_READ(WM0_PIPE_ILK(pipe));
> if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> hw->wm_linetime[pipe] = I915_READ(PIPE_WM_LINETIME(pipe));
>
> --
> 2.18.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
[Intel-gfx] [PATCH v9 25/39] misc/mei/hdcp: Verify Receiver Cert and prepare km
Requests for verification for receiver certification and also the
preparation for next AKE auth message with km.
On Success ME FW validate the HDCP2.2 receivers certificate and do the
revocation check on the receiver ID. AKE_Stored_Km will be prepared if
the receiver is already paired, else AKE_No_Stored_Km will be prepared.
Here AKE_Stored_Km and AKE_No_Stored_Km are HDCP2.2 protocol msgs.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd is used for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc Addition. [Tomas]
memcpy for const length.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 81 +++-
1 file changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 124f02e2b7c4..270baf24f21b 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -89,11 +89,90 @@ mei_initiate_hdcp2_session(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_verify_receiver_cert_prepare_km() - Verify the Receiver Certificate
+ * AKE_Send_Cert and prepare AKE_Stored_Km/AKE_No_Stored_Km
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rx_cert: AKE_Send_Cert for verification
+ * @km_stored: Pairing status flag output
+ * @ek_pub_km: AKE_Stored_Km/AKE_No_Stored_Km output msg
+ * @msg_sz : size of AKE_X_Km output msg
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_verify_receiver_cert_prepare_km(struct device *dev,
+ struct hdcp_port_data *data,
+ struct hdcp2_ake_send_cert *rx_cert,
+ bool *km_stored,
+ struct hdcp2_ake_no_stored_km *ek_pub_km,
+ size_t *msg_sz)
+{
+ struct wired_cmd_verify_receiver_cert_in verify_rxcert_in = { { 0 } };
+ struct wired_cmd_verify_receiver_cert_out verify_rxcert_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !rx_cert || !km_stored || !ek_pub_km || !msg_sz)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ verify_rxcert_in.header.api_version = HDCP_API_VERSION;
+ verify_rxcert_in.header.command_id = WIRED_VERIFY_RECEIVER_CERT;
+ verify_rxcert_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ verify_rxcert_in.header.buffer_len =
+ WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
+
+ verify_rxcert_in.port.integrated_port_type = data->port_type;
+ verify_rxcert_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ verify_rxcert_in.cert_rx = rx_cert->cert_rx;
+ memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
+ memcpy(verify_rxcert_in.rx_caps, rx_cert->rx_caps, HDCP_2_2_RXCAPS_LEN);
+
+ byte = mei_cldev_send(cldev, (u8 *)_rxcert_in,
+ sizeof(verify_rxcert_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed: %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_rxcert_out,
+ sizeof(verify_rxcert_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed: %zd\n", byte);
+ return byte;
+ }
+
+ if (verify_rxcert_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+ WIRED_VERIFY_RECEIVER_CERT,
+ verify_rxcert_out.header.status);
+ return -EIO;
+ }
+
+ *km_stored = verify_rxcert_out.km_stored;
+ if (verify_rxcert_out.km_stored) {
+ ek_pub_km->msg_id = HDCP_2_2_AKE_STORED_KM;
+ *msg_sz = sizeof(struct hdcp2_ake_stored_km);
+ } else {
+ ek_pub_km->msg_id = HDCP_2_2_AKE_NO_STORED_KM;
+ *msg_sz = sizeof(struct hdcp2_ake_no_stored_km);
+ }
+
+ memcpy(ek_pub_km->e_kpub_km, _rxcert_out.ekm_buff,
+ sizeof(verify_rxcert_out.ekm_buff));
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
- .verify_receiver_cert_prepare_km = NULL,
+ .verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
.verify_hprime = NULL,
.store_pairing_info = NULL,
.initiate_locality_check = NULL,
--
2.7.4
___
Intel-gfx mailing list
[Intel-gfx] [PATCH v9 19/39] drm/i915: Add HDCP2.2 support for HDMI connectors
On HDMI connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
v3:
Collected the reviewed-by received.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 5f179f1dd4ad..0c3b287bff24 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2623,7 +2623,8 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
if (is_hdcp_supported(dev_priv, port)) {
int ret = intel_hdcp_init(intel_connector,
- _hdmi_hdcp_shim, false);
+_hdmi_hdcp_shim,
+is_hdcp2_supported(dev_priv));
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
Implements HDCP2.2 authentication for hdcp2.2 receivers, with
following steps:
Authentication and Key exchange (AKE).
Locality Check (LC).
Session Key Exchange(SKE).
DP Errata for stream type configuration for receivers.
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 specific
functions defined at hdcp_shim.
v2: Rebased.
v3:
%s/PARING/PAIRING
Coding style fixing [Uma]
v4:
Rebased as part of patch reordering.
Defined the functions for mei services. [Daniel]
v5:
Redefined the mei service functions as per comp redesign.
Required intel_hdcp members are defined [Sean Paul]
v6:
Typo of cipher is Fixed [Uma]
%s/uintxx_t/uxx
Check for comp_master is removed.
v7:
Adjust to the new interface.
Avoid using bool structure members. [Tomas]
v8: Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drv.h | 34 ++
drivers/gpu/drm/i915/intel_hdcp.c | 211 +++---
2 files changed, 230 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6d5361616ca3..a6b632d71490 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -387,6 +387,22 @@ struct intel_hdcp_shim {
/* Detects whether Panel is HDCP2.2 capable */
int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
bool *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,
+ u8 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 Cipher for En/De-Cryption. Not applicable for HDMI.
+*/
+ int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
+ void *buf, size_t size);
};
struct intel_hdcp {
@@ -414,6 +430,24 @@ struct intel_hdcp {
*/
u8 content_type;
struct hdcp_port_data port_data;
+
+ u8 is_paired;
+ u8 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.
+*/
+ u32 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.
+*/
+ u32 seq_num_m;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index f0ee448e6546..f1f0ef294e20 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -18,6 +18,7 @@
#define KEY_LOAD_TRIES 5
#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
+#define HDCP2_LC_RETRY_CNT 3
static
bool intel_hdcp_is_ksv_valid(u8 *ksv)
@@ -854,7 +855,7 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
}
-static __attribute__((unused)) int
+static int
hdcp2_prepare_ake_init(struct intel_connector *connector,
struct hdcp2_ake_init *ake_data)
{
@@ -875,7 +876,7 @@ hdcp2_prepare_ake_init(struct intel_connector *connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
struct hdcp2_ake_send_cert *rx_cert,
bool *paired,
@@ -897,9 +898,8 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_connector
*connector,
return ret;
}
-static __attribute__((unused)) int
-hdcp2_verify_hprime(struct intel_connector *connector,
- struct hdcp2_ake_send_hprime *rx_hprime)
+static int hdcp2_verify_hprime(struct intel_connector *connector,
+ struct
[Intel-gfx] [PATCH v9 16/39] drm/i915: Implement the HDCP2.2 support for DP
Implements the DP adaptation specific HDCP2.2 functions.
These functions perform the DPCD read and write for communicating the
HDCP2.2 auth message back and forth.
v2:
wait for cp_irq is merged with this patch. Rebased.
v3:
wait_queue is used for wait for cp_irq [Chris Wilson]
v4:
Style fixed.
%s/PARING/PAIRING
Few style fixes [Uma]
v5:
Lookup table for DP HDCP2.2 msg details [Daniel].
Extra lines are removed.
v6: Rebased.
v7:
Fixed some regression introduced at v5. [Ankit]
Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma]
Converted a function to inline [Uma]
%s/uintxx_t/uxx
v8:
Error due to the sinks are reported as DEBUG logs.
Adjust to the new mei interface.
v9:
ARRAY_SIZE for no of array members [Jon & Daniel]
return of the wait_for_cp_irq is made as void [Daniel]
Wait for HDCP2.2 msg is done based on polling the reg bit than
CP_IRQ based. [Daniel]
hdcp adaptation is added as a const in the hdcp_shim [Daniel]
Signed-off-by: Ramalingam C
Signed-off-by: Ankit K Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_dp.c | 310
1 file changed, 310 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 89315e15fb34..a8ace7d85918 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5797,6 +5797,310 @@ int intel_dp_hdcp_capable(struct intel_digital_port
*intel_dig_port,
return 0;
}
+static struct hdcp2_dp_msg_data {
+ u8 msg_id;
+ u32 offset;
+ bool msg_detectable;
+ u32 timeout;
+ u32 timeout2; /* Added for non_paired situation */
+ } hdcp2_msg_data[] = {
+ {HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0},
+ {HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
+ false, HDCP_2_2_CERT_TIMEOUT_MS, 0},
+ {HDCP_2_2_AKE_NO_STORED_KM, DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
+ false, 0, 0},
+ {HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
+ false, 0, 0},
+ {HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
+ true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
+ HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
+ {HDCP_2_2_AKE_SEND_PAIRING_INFO,
+ DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, true,
+ HDCP_2_2_PAIRING_TIMEOUT_MS, 0},
+ {HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0},
+ {HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
+ false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0},
+ {HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, false,
+ 0, 0},
+ {HDCP_2_2_REP_SEND_RECVID_LIST,
+ DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
+ HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
+ {HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, false,
+ 0, 0},
+ {HDCP_2_2_REP_STREAM_MANAGE,
+ DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
+ 0, 0},
+ {HDCP_2_2_REP_STREAM_READY, DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
+ false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0},
+ {HDCP_2_2_ERRATA_DP_STREAM_TYPE,
+ DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET, false,
+ 0, 0},
+ };
+
+static inline
+int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+ u8 *rx_status)
+{
+ ssize_t ret;
+
+ ret = drm_dp_dpcd_read(_dig_port->dp.aux,
+ DP_HDCP_2_2_REG_RXSTATUS_OFFSET, rx_status,
+ HDCP_2_2_DP_RXSTATUS_LEN);
+ if (ret != HDCP_2_2_DP_RXSTATUS_LEN) {
+ DRM_DEBUG_KMS("Read bstatus from DP/AUX failed (%zd)\n", ret);
+ return ret >= 0 ? -EIO : ret;
+ }
+
+ return 0;
+}
+
+static
+int hdcp2_detect_msg_availability(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, bool *msg_ready)
+{
+ u8 rx_status;
+ int ret;
+
+ *msg_ready = false;
+ ret = intel_dp_hdcp2_read_rx_status(intel_dig_port, _status);
+ if (ret < 0)
+ return ret;
+
+ switch (msg_id) {
+ case HDCP_2_2_AKE_SEND_HPRIME:
+ if (HDCP_2_2_DP_RXSTATUS_H_PRIME(rx_status))
+ *msg_ready = true;
+ break;
+ case HDCP_2_2_AKE_SEND_PAIRING_INFO:
+ if (HDCP_2_2_DP_RXSTATUS_PAIRING(rx_status))
+ *msg_ready = true;
+
[Intel-gfx] [PATCH v9 13/39] drm: HDCP2.2 link check related constants
Enums and macros are defined for HDCP2.2 link check.
Signed-off-by: Ramalingam C
---
include/drm/drm_hdcp.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index d8093ecf3ddc..21a128e7020a 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -11,6 +11,14 @@
/* Period of hdcp checks (to ensure we're still authenticated) */
#define DRM_HDCP_CHECK_PERIOD_MS (128 * 16)
+#define DRM_HDCP2_CHECK_PERIOD_MS 500
+
+enum check_link_response {
+ DRM_HDCP_LINK_PROTECTED = 0,
+ DRM_HDCP_TOPOLOGY_CHANGE,
+ DRM_HDCP_LINK_INTEGRITY_FAILURE,
+ DRM_HDCP_REAUTH_REQUEST
+};
/* Shared lengths/masks between HDMI/DVI/DisplayPort */
#define DRM_HDCP_AN_LEN8
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 22/39] misc/mei/hdcp: Client driver for HDCP application
ME FW is contributes a vital role in HDCP2.2 authentication.
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 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
verification.
Once All the steps of HDCP2.2 authentications are complete on driver's
request 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]
v4:
Module name is changed to "MEI HDCP"
I915 Selects the MEI_HDCP
v5:
Remove redundant text from the License header
Fix malformed licence
Removed the drv_data resetting.
v6:
K-Doc addition. [Tomas]
Signed-off-by: Ramalingam C
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/Kconfig | 7 +
drivers/misc/mei/Makefile| 2 ++
drivers/misc/mei/hdcp/Makefile | 7 +
drivers/misc/mei/hdcp/mei_hdcp.c | 65
4 files changed, 81 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..9c518b7f0011 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -43,3 +43,10 @@ config INTEL_MEI_TXE
Supported SoCs:
Intel Bay Trail
+
+config INTEL_MEI_HDCP
+ tristate "Intel HDCP2.2 services of ME Interface"
+ select INTEL_MEI_ME
+ depends on 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 ..c1a86dd9782b
--- /dev/null
+++ b/drivers/misc/mei/hdcp/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+#
+# Copyright (c) 2017-2018, Intel Corporation.
+#
+# Makefile - HDCP client driver for Intel MEI Bus Driver.
+
+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 ..6e7101512842
--- /dev/null
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Mei_hdcp.c: HDCP client driver for mei bus
+ *
+ * Authors:
+ * Ramalingam C
+ */
+
+/**
+ * DOC: MEI_HDCP Client Driver
+ *
+ * This is a client driver to the mei_bus to make the HDCP2.2 services of
+ * ME FW available for the interested consumers like I915.
+ *
+ * This module will act as a translation layer between HDCP protocol
+ * implementor(I915) and ME FW by translating HDCP2.2 authentication
+ * messages to ME FW command payloads and vice versa.
+ */
+
+#include
+#include
+#include
+#include
+
+static int mei_hdcp_probe(struct mei_cl_device *cldev,
+ const struct mei_cl_device_id *id)
+{
+ int ret;
+
+ ret = mei_cldev_enable(cldev);
+ if (ret < 0)
+ dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
+
+ return ret;
+}
+
+static int mei_hdcp_remove(struct mei_cl_device *cldev)
+{
+ return mei_cldev_disable(cldev);
+}
+
+#define MEI_UUID_HDCP UUID_LE(0xB638AB7E, 0x94E2, 0x4EA2, 0xA5, \
+ 0x52, 0xD1, 0xC5, 0x4B, \
+ 0x62, 0x7F, 0x04)
+
+static struct mei_cl_device_id mei_hdcp_tbl[] = {
+ { .uuid = MEI_UUID_HDCP, .version = MEI_CL_VERSION_ANY },
+ { }
+};
+MODULE_DEVICE_TABLE(mei, mei_hdcp_tbl);
+
+static struct mei_cl_driver mei_hdcp_driver = {
+ .id_table = mei_hdcp_tbl,
+ .name = KBUILD_MODNAME,
+ .probe = mei_hdcp_probe,
+ .remove = mei_hdcp_remove,
+};
+
+module_mei_cl_driver(mei_hdcp_driver);
+
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_DESCRIPTION("MEI HDCP");
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH v9 15/39] drm/i915: Handle HDCP2.2 downstream topology change
When repeater notifies a downstream topology change, this patch
reauthenticate the repeater alone without disabling the hdcp
encryption. If that fails then complete reauthentication is executed.
v2:
Rebased.
v3:
Typo in commit msg is fixed [Uma]
v4:
Rebased as part of patch reordering.
Minor style fixes.
v5:
Rebased.
v6:
Rebased.
v7:
Errors due to sinks are reported as DEBUG logs.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdcp.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 6fac570fcbac..cafda8903b50 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1537,8 +1537,24 @@ static int intel_hdcp2_check_link(struct intel_connector
*connector)
goto out;
}
- DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
- connector->base.name, connector->base.base.id);
+ if (ret == DRM_HDCP_TOPOLOGY_CHANGE) {
+ if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ goto out;
+
+ DRM_DEBUG_KMS("HDCP2.2 Downstream topology change\n");
+ ret = hdcp2_authenticate_repeater_topology(connector);
+ if (!ret) {
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(>prop_work);
+ goto out;
+ }
+ DRM_DEBUG_KMS("[%s:%d] Repeater topology auth failed.(%d)\n",
+ connector->base.name, connector->base.base.id,
+ ret);
+ } else {
+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
+ connector->base.name, connector->base.base.id);
+ }
ret = _intel_hdcp2_disable(connector);
if (ret) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 09/39] drm/i915: Enable and Disable of HDCP2.2
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.
This change implements a sequence of enabling and disabling of
HDCP2.2 authentication and HDCP2.2 port encryption.
v2:
Included few optimization suggestions [Chris Wilson]
Commit message is updated as per the rebased version.
intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
Extra comment added and Style issue fixed [Uma]
v4:
Rebased as part of patch reordering.
HDCP2 encryption status is tracked.
HW state check is moved into WARN_ON [Daniel]
v5:
Redefined the mei service functions as per comp redesign.
Merged patches related to hdcp2.2 enabling and disabling [Sean Paul].
Required shim functionality is defined [Sean Paul]
v6:
Return values are handles [Uma]
Realigned the code.
Check for comp_master is removed.
v7:
HDCP2.2 is attempted only if mei interface is up.
Adjust to the new interface
Avoid bool usage in struct [Tomas]
v8:
mei_binded status check is removed.
%s/hdcp2_in_use/hdcp2_encrypted
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drv.h | 7 ++
drivers/gpu/drm/i915/intel_hdcp.c | 202 +++---
2 files changed, 195 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index decd0346c6a7..6d5361616ca3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -383,6 +383,10 @@ struct intel_hdcp_shim {
/* HDCP adaptation(DP/HDMI) required on the port */
enum hdcp_wired_protocol protocol;
+
+ /* Detects whether Panel is HDCP2.2 capable */
+ int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
+ bool *capable);
};
struct intel_hdcp {
@@ -400,6 +404,9 @@ struct intel_hdcp {
/* Flag indicates whether this connector supports HDCP2.2 or not. */
u8 hdcp2_supported;
+ /* HDCP2.2 Encryption status */
+ u8 hdcp2_encrypted;
+
/*
* 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)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 2b7814a6f12b..f0ee448e6546 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -75,6 +75,23 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
}
+/* Is HDCP2.2 capable on Platform and Sink */
+static bool intel_hdcp2_capable(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ bool capable = false;
+
+ /* I915 support for HDCP2.2 */
+ if (!hdcp->hdcp2_supported)
+ return false;
+
+ /* Sink's capability for HDCP2.2 */
+ hdcp->shim->hdcp_2_2_capable(intel_dig_port, );
+
+ return capable;
+}
+
static inline bool intel_hdcp_in_use(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1014,8 +1031,7 @@ int hdcp2_authenticate_port(struct intel_connector
*connector)
return ret;
}
-static __attribute__((unused))
-int hdcp2_close_mei_session(struct intel_connector *connector)
+static int hdcp2_close_mei_session(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_component_master *comp = dev_priv->comp_master;
@@ -1024,12 +1040,157 @@ int hdcp2_close_mei_session(struct intel_connector
*connector)
>hdcp.port_data);
}
-static __attribute__((unused))
-int hdcp2_deauthenticate_port(struct intel_connector *connector)
+static int hdcp2_deauthenticate_port(struct intel_connector *connector)
{
return hdcp2_close_mei_session(connector);
}
+static int hdcp2_authenticate_sink(struct intel_connector *connector)
+{
+ DRM_ERROR("Sink authentication is done in subsequent patches\n");
+
+ return -EINVAL;
+}
+
+static int hdcp2_enable_encryption(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
+ enum port port = connector->encoder->port;
+ int ret;
+
+ WARN_ON(I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS);
+
+ if (hdcp->shim->toggle_signalling) {
+ ret = hdcp->shim->toggle_signalling(intel_dig_port, true);
+ if (ret) {
+ DRM_ERROR("Failed to enable HDCP signalling. %d\n",
+ ret);
+
[Intel-gfx] [PATCH v9 21/39] mei: bus: export to_mei_cl_device for mei client device drivers
From: Tomas Winkler
Export to_mei_cl_device macro, it is needed also in mei client drivers.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus.c | 1 -
include/linux/mei_cl_bus.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index fc3872fe7b25..e5456faf00e6 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -28,7 +28,6 @@
#include "client.h"
#define to_mei_cl_driver(d) container_of(d, struct mei_cl_driver, driver)
-#define to_mei_cl_device(d) container_of(d, struct mei_cl_device, dev)
/**
* __mei_cl_send - internal client send (write)
diff --git a/include/linux/mei_cl_bus.h b/include/linux/mei_cl_bus.h
index 7fde40e17c8b..03b6ba2a63f8 100644
--- a/include/linux/mei_cl_bus.h
+++ b/include/linux/mei_cl_bus.h
@@ -55,6 +55,8 @@ struct mei_cl_device {
void *priv_data;
};
+#define to_mei_cl_device(d) container_of(d, struct mei_cl_device, dev)
+
struct mei_cl_driver {
struct device_driver driver;
const char *name;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 17/39] drm/i915: Implement the HDCP2.2 support for HDMI
Implements the HDMI adaptation specific HDCP2.2 operations.
Basically these are DDC read and write for authenticating through
HDCP2.2 messages.
v2: Rebased.
v3:
No more special handling of Gmbus burst read for AKE_SEND_CERT.
Style fixed with few naming. [Uma]
%s/PARING/PAIRING
v4:
msg_sz is initialized at definition.
Lookup table is defined for HDMI HDCP2.2 msgs [Daniel].
v5: Rebased.
v6:
Make a function as inline [Uma]
%s/uintxx_t/uxx
v7:
Errors due to sinks are reported as DEBUG logs.
Adjust to the new mei interface.
v8:
ARRAY_SIZE for the # of array members [Jon & Daniel].
hdcp adaptation is added as a const in the hdcp_shim [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 189 ++
1 file changed, 189 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 38fe0fdbf8d8..5f179f1dd4ad 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1134,6 +1134,190 @@ bool intel_hdmi_hdcp_check_link(struct
intel_digital_port *intel_dig_port)
return true;
}
+static struct hdcp2_hdmi_msg_data {
+ u8 msg_id;
+ u32 timeout;
+ u32 timeout2;
+ } hdcp2_msg_data[] = {
+ {HDCP_2_2_AKE_INIT, 0, 0},
+ {HDCP_2_2_AKE_SEND_CERT, HDCP_2_2_CERT_TIMEOUT_MS, 0},
+ {HDCP_2_2_AKE_NO_STORED_KM, 0, 0},
+ {HDCP_2_2_AKE_STORED_KM, 0, 0},
+ {HDCP_2_2_AKE_SEND_HPRIME, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
+ HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
+ {HDCP_2_2_AKE_SEND_PAIRING_INFO, HDCP_2_2_PAIRING_TIMEOUT_MS,
+ 0},
+ {HDCP_2_2_LC_INIT, 0, 0},
+ {HDCP_2_2_LC_SEND_LPRIME, HDCP_2_2_HDMI_LPRIME_TIMEOUT_MS, 0},
+ {HDCP_2_2_SKE_SEND_EKS, 0, 0},
+ {HDCP_2_2_REP_SEND_RECVID_LIST,
+ HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
+ {HDCP_2_2_REP_SEND_ACK, 0, 0},
+ {HDCP_2_2_REP_STREAM_MANAGE, 0, 0},
+ {HDCP_2_2_REP_STREAM_READY, HDCP_2_2_STREAM_READY_TIMEOUT_MS,
+ 0},
+ };
+
+static
+int intel_hdmi_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+ uint8_t *rx_status)
+{
+ return intel_hdmi_hdcp_read(intel_dig_port,
+ HDCP_2_2_HDMI_REG_RXSTATUS_OFFSET,
+ rx_status,
+ HDCP_2_2_HDMI_RXSTATUS_LEN);
+}
+
+static int get_hdcp2_msg_timeout(u8 msg_id, bool is_paired)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(hdcp2_msg_data); i++)
+ if (hdcp2_msg_data[i].msg_id == msg_id &&
+ (msg_id != HDCP_2_2_AKE_SEND_HPRIME || is_paired))
+ return hdcp2_msg_data[i].timeout;
+ else if (hdcp2_msg_data[i].msg_id == msg_id)
+ return hdcp2_msg_data[i].timeout2;
+
+ return -EINVAL;
+}
+
+static inline
+int hdcp2_detect_msg_availability(struct intel_digital_port
*intel_digital_port,
+ u8 msg_id, bool *msg_ready,
+ ssize_t *msg_sz)
+{
+ u8 rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
+ int ret;
+
+ ret = intel_hdmi_hdcp2_read_rx_status(intel_digital_port, rx_status);
+ if (ret < 0) {
+ DRM_DEBUG_KMS("rx_status read failed. Err %d\n", ret);
+ return ret;
+ }
+
+ *msg_sz = ((HDCP_2_2_HDMI_RXSTATUS_MSG_SZ_HI(rx_status[1]) << 8) |
+ rx_status[0]);
+
+ if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST)
+ *msg_ready = (HDCP_2_2_HDMI_RXSTATUS_READY(rx_status[1]) &&
+*msg_sz);
+ else
+ *msg_ready = *msg_sz;
+
+ return 0;
+}
+
+static ssize_t
+intel_hdmi_hdcp2_wait_for_msg(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, bool paired)
+{
+ bool msg_ready = false;
+ int timeout, ret;
+ ssize_t msg_sz = 0;
+
+ timeout = get_hdcp2_msg_timeout(msg_id, paired);
+ if (timeout < 0)
+ return timeout;
+
+ ret = __wait_for(ret = hdcp2_detect_msg_availability(intel_dig_port,
+msg_id, _ready,
+_sz),
+!ret && msg_ready && msg_sz, timeout * 1000,
+1000, 5 * 1000);
+ if (ret)
+ DRM_DEBUG_KMS("msg_id: %d, ret: %d, timeout: %d\n",
+ msg_id, ret, timeout);
+
+ return ret ? ret : msg_sz;
+}
+
+static
+int intel_hdmi_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
+ void *buf,
[Intel-gfx] [PATCH v9 14/39] drm/i915: Implement HDCP2.2 link integrity check
Implements the link integrity check once in 500mSec.
Once encryption is enabled, an ongoing Link Integrity Check is
performed by the HDCP Receiver to check that cipher synchronization
is maintained between the HDCP Transmitter and the HDCP Receiver.
On the detection of synchronization lost, the HDCP Receiver must assert
the corresponding bits of the RxStatus register. The Transmitter polls
the RxStatus register and it may initiate re-authentication.
v2:
Rebased.
v3:
enum check_link_response is used check the link status [Uma]
v4:
Rebased as part of patch reordering.
v5:
Required members of intel_hdcp is defined [Sean Paul]
v6:
hdcp2_check_link is cancelled at required places.
v7:
Rebased for the component i/f changes.
Errors due to the sinks are reported as DEBUG logs.
v8:
hdcp_check_work is used for both hdcp1 and hdcp2 check_link [Daniel]
hdcp2.2 encryption status check is put under WARN_ON [Daniel]
drm_hdcp.h changes are moved into separate patch [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_drv.h | 3 ++
drivers/gpu/drm/i915/intel_hdcp.c | 90 ---
2 files changed, 87 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a6b632d71490..60d1359e55f4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -403,6 +403,9 @@ struct intel_hdcp_shim {
*/
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);
};
struct intel_hdcp {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index b52da5c3159d..6fac570fcbac 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -103,6 +103,16 @@ static inline bool intel_hdcp_in_use(struct
intel_connector *connector)
return reg & HDCP_STATUS_ENC;
}
+static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ enum port port = connector->encoder->port;
+ u32 reg;
+
+ reg = I915_READ(HDCP2_STATUS_DDI(port));
+ return reg & LINK_ENCRYPTION_STATUS;
+}
+
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
{
@@ -1491,11 +1501,77 @@ static int _intel_hdcp2_disable(struct intel_connector
*connector)
return ret;
}
+/* Implements the Link Integrity Check for HDCP2.2 */
+static int intel_hdcp2_check_link(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
+ enum port port = connector->encoder->port;
+ int ret = 0;
+
+ mutex_lock(>mutex);
+
+ /* hdcp2_check_link is expected only when HDCP2.2 is Enabled */
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED ||
+ !hdcp->hdcp2_encrypted) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (WARN_ON(!intel_hdcp2_in_use(connector))) {
+ DRM_ERROR("HDCP2.2 link stopped the encryption, %x\n",
+ I915_READ(HDCP2_STATUS_DDI(port)));
+ ret = -ENXIO;
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ goto out;
+ }
+
+ ret = hdcp->shim->check_2_2_link(intel_dig_port);
+ if (ret == DRM_HDCP_LINK_PROTECTED) {
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ schedule_work(>prop_work);
+ }
+ goto out;
+ }
+
+ DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
+ connector->base.name, connector->base.base.id);
+
+ ret = _intel_hdcp2_disable(connector);
+ if (ret) {
+ DRM_ERROR("[%s:%d] Failed to disable hdcp2.2 (%d)\n",
+ connector->base.name, connector->base.base.id, ret);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ goto out;
+ }
+
+ ret = _intel_hdcp2_enable(connector);
+ if (ret) {
+ DRM_DEBUG_KMS("[%s:%d] Failed to enable hdcp2.2 (%d)\n",
+ connector->base.name, connector->base.base.id,
+ ret);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ goto out;
+
[Intel-gfx] [PATCH v9 23/39] misc/mei/hdcp: Define ME FW interface for HDCP2.2
Defines the HDCP specific ME FW interfaces such as Request CMDs,
payload structure for CMDs and their response status codes.
This patch defines payload size(Excluding the Header)for each WIRED
HDCP2.2 CMDs.
v2: Rebased.
v3:
Extra comments are removed.
v4:
%s/\/\*\*/\/\*
v5:
Extra lines are removed.
v6:
Remove redundant text from the License header
%s/LPRIME_HALF/V_PRIME_HALF
%s/uintxx_t/uxx
v7:
Extra taps removed.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.h | 366 +++
1 file changed, 366 insertions(+)
create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
new file mode 100644
index ..d1456e3dbf22
--- /dev/null
+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
@@ -0,0 +1,366 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Authors:
+ * Ramalingam C
+ */
+
+#ifndef __MEI_HDCP_H__
+#define __MEI_HDCP_H__
+
+#include
+
+/* me_hdcp_status: Enumeration of all HDCP Status Codes */
+enum me_hdcp_status {
+ ME_HDCP_STATUS_SUCCESS = 0x,
+
+ /* WiDi Generic Status Codes */
+ ME_HDCP_STATUS_INTERNAL_ERROR = 0x1000,
+ ME_HDCP_STATUS_UNKNOWN_ERROR= 0x1001,
+ ME_HDCP_STATUS_INCORRECT_API_VERSION= 0x1002,
+ ME_HDCP_STATUS_INVALID_FUNCTION = 0x1003,
+ ME_HDCP_STATUS_INVALID_BUFFER_LENGTH= 0x1004,
+ ME_HDCP_STATUS_INVALID_PARAMS = 0x1005,
+ ME_HDCP_STATUS_AUTHENTICATION_FAILED= 0x1006,
+
+ /* WiDi Status Codes */
+ ME_HDCP_INVALID_SESSION_STATE = 0x6000,
+ ME_HDCP_SRM_FRAGMENT_UNEXPECTED = 0x6001,
+ ME_HDCP_SRM_INVALID_LENGTH = 0x6002,
+ ME_HDCP_SRM_FRAGMENT_OFFSET_INVALID = 0x6003,
+ ME_HDCP_SRM_VERIFICATION_FAILED = 0x6004,
+ ME_HDCP_SRM_VERSION_TOO_OLD = 0x6005,
+ ME_HDCP_RX_CERT_VERIFICATION_FAILED = 0x6006,
+ ME_HDCP_RX_REVOKED = 0x6007,
+ ME_HDCP_H_VERIFICATION_FAILED = 0x6008,
+ ME_HDCP_REPEATER_CHECK_UNEXPECTED = 0x6009,
+ ME_HDCP_TOPOLOGY_MAX_EXCEEDED = 0x600A,
+ ME_HDCP_V_VERIFICATION_FAILED = 0x600B,
+ ME_HDCP_L_VERIFICATION_FAILED = 0x600C,
+ ME_HDCP_STREAM_KEY_ALLOC_FAILED = 0x600D,
+ ME_HDCP_BASE_KEY_RESET_FAILED = 0x600E,
+ ME_HDCP_NONCE_GENERATION_FAILED = 0x600F,
+ ME_HDCP_STATUS_INVALID_E_KEY_STATE = 0x6010,
+ ME_HDCP_STATUS_INVALID_CS_ICV = 0x6011,
+ ME_HDCP_STATUS_INVALID_KB_KEY_STATE = 0x6012,
+ ME_HDCP_STATUS_INVALID_PAVP_MODE_ICV= 0x6013,
+ ME_HDCP_STATUS_INVALID_PAVP_MODE= 0x6014,
+ ME_HDCP_STATUS_LC_MAX_ATTEMPTS = 0x6015,
+
+ /* New status for HDCP 2.1 */
+ ME_HDCP_STATUS_MISMATCH_IN_M= 0x6016,
+
+ /* New status code for HDCP 2.2 Rx */
+ ME_HDCP_STATUS_RX_PROV_NOT_ALLOWED = 0x6017,
+ ME_HDCP_STATUS_RX_PROV_WRONG_SUBJECT= 0x6018,
+ ME_HDCP_RX_NEEDS_PROVISIONING = 0x6019,
+ ME_HDCP_BKSV_ICV_AUTH_FAILED= 0x6020,
+ ME_HDCP_STATUS_INVALID_STREAM_ID= 0x6021,
+ ME_HDCP_STATUS_CHAIN_NOT_INITIALIZED= 0x6022,
+ ME_HDCP_FAIL_NOT_EXPECTED = 0x6023,
+ ME_HDCP_FAIL_HDCP_OFF = 0x6024,
+ ME_HDCP_FAIL_INVALID_PAVP_MEMORY_MODE = 0x6025,
+ ME_HDCP_FAIL_AES_ECB_FAILURE= 0x6026,
+ ME_HDCP_FEATURE_NOT_SUPPORTED = 0x6027,
+ ME_HDCP_DMA_READ_ERROR = 0x6028,
+ ME_HDCP_DMA_WRITE_ERROR = 0x6029,
+ ME_HDCP_FAIL_INVALID_PACKET_SIZE= 0x6030,
+ ME_HDCP_H264_PARSING_ERROR = 0x6031,
+ ME_HDCP_HDCP2_ERRATA_VIDEO_VIOLATION= 0x6032,
+ ME_HDCP_HDCP2_ERRATA_AUDIO_VIOLATION= 0x6033,
+ ME_HDCP_TX_ACTIVE_ERROR = 0x6034,
+ ME_HDCP_MODE_CHANGE_ERROR = 0x6035,
+ ME_HDCP_STREAM_TYPE_ERROR = 0x6036,
+ ME_HDCP_STREAM_MANAGE_NOT_POSSIBLE = 0x6037,
+
+ ME_HDCP_STATUS_PORT_INVALID_COMMAND = 0x6038,
+ ME_HDCP_STATUS_UNSUPPORTED_PROTOCOL = 0x6039,
+ ME_HDCP_STATUS_INVALID_PORT_INDEX = 0x603a,
+ ME_HDCP_STATUS_TX_AUTH_NEEDED = 0x603b,
+ ME_HDCP_STATUS_NOT_INTEGRATED_PORT = 0x603c,
+ ME_HDCP_STATUS_SESSION_MAX_REACHED = 0x603d,
+
+ /* hdcp capable bit is not set in rx_caps(error is unique to DP) */
+ ME_HDCP_STATUS_NOT_HDCP_CAPABLE = 0x6041,
+
+ ME_HDCP_STATUS_INVALID_STREAM_COUNT = 0x6042,
+};
+
+#define HDCP_API_VERSION 0x0001
+
+#define HDCP_M_LEN 16
[Intel-gfx] [PATCH v9 20/39] mei: bus: whitelist hdcp client
From: Tomas Winkler
Whitelist HDCP client for in kernel drm use
v2:
Rebased.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus-fixup.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 80215c312f0e..5fcac02233af 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -40,6 +40,9 @@ static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
#define MEI_UUID_MKHIF_FIX UUID_LE(0x55213584, 0x9a29, 0x4916, \
0xba, 0xdf, 0xf, 0xb7, 0xed, 0x68, 0x2a, 0xeb)
+#define MEI_UUID_HDCP UUID_LE(0xB638AB7E, 0x94E2, 0x4EA2, \
+ 0xA5, 0x52, 0xD1, 0xC5, 0x4B, 0x62, 0x7F, 0x04)
+
#define MEI_UUID_ANY NULL_UUID_LE
/**
@@ -71,6 +74,18 @@ static void blacklist(struct mei_cl_device *cldev)
cldev->do_match = 0;
}
+/**
+ * whitelist - forcefully whitelist client
+ *
+ * @cldev: me clients device
+ */
+static void whitelist(struct mei_cl_device *cldev)
+{
+ dev_dbg(>dev, "running hook %s\n", __func__);
+
+ cldev->do_match = 1;
+}
+
#define OSTYPE_LINUX2
struct mei_os_ver {
__le16 build;
@@ -472,6 +487,7 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_NFC_HCI, mei_nfc),
MEI_FIXUP(MEI_UUID_WD, mei_wd),
MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
+ MEI_FIXUP(MEI_UUID_HDCP, whitelist),
};
/**
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 30/39] misc/mei/hdcp: Prepare Session Key
Request to ME to prepare the encrypted session key.
On Success, ME provides Encrypted session key. Function populates
the HDCP2.2 authentication msg SKE_Send_Eks.
v2: Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 58 +++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b6cc55c13d4a..554e07ba69c3 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -392,6 +392,62 @@ static int mei_verify_lprime(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_get_session_key() - Prepare SKE_Send_Eks.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @ske_data: SKE_Send_Eks msg output from ME FW.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_get_session_key(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !ske_data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(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 = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_skey_out, sizeof(get_skey_out));
+
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", 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 -EIO;
+ }
+
+ ske_data->msg_id = HDCP_2_2_SKE_SEND_EKS;
+ memcpy(ske_data->e_dkey_ks, get_skey_out.e_dkey_ks,
+ HDCP_2_2_E_DKEY_KS_LEN);
+ memcpy(ske_data->riv, get_skey_out.r_iv, HDCP_2_2_RIV_LEN);
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -401,7 +457,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.store_pairing_info = mei_store_pairing_info,
.initiate_locality_check = mei_initiate_locality_check,
.verify_lprime = mei_verify_lprime,
- .get_session_key = NULL,
+ .get_session_key = mei_get_session_key,
.repeater_check_flow_prepare_ack = NULL,
.verify_mprime = NULL,
.enable_hdcp_authentication = NULL,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 34/39] 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]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style and typos fixed [Uma]
v5:
Extra line is removed.
v6:
Collected the Rb-ed by.
Rebased.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition.[Tomas]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 55 +++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 9569a5b85fd0..b22a71e8c5d7 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -638,6 +638,59 @@ mei_enable_hdcp_authentication(struct device *dev, struct
hdcp_port_data *data)
return 0;
}
+/**
+ * mei_close_hdcp_session() - Close the Wired HDCP Tx session of ME FW per
port.
+ * This also disables the authenticated state of the port.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_close_hdcp_session(struct device *dev, struct hdcp_port_data *data)
+{
+ struct wired_cmd_close_session_in session_close_in = { { 0 } };
+ struct wired_cmd_close_session_out session_close_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(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 = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ byte = mei_cldev_send(cldev, (u8 *)_close_in,
+ sizeof(session_close_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_close_out,
+ sizeof(session_close_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", 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 -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -651,7 +704,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
.verify_mprime = mei_verify_mprime,
.enable_hdcp_authentication = mei_enable_hdcp_authentication,
- .close_hdcp_session = NULL,
+ .close_hdcp_session = mei_close_hdcp_session,
};
static int mei_hdcp_probe(struct mei_cl_device *cldev,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 26/39] misc/mei/hdcp: Verify H_prime
Requests for the verification of AKE_Send_H_prime.
ME will calculate the H and comparing it with received H_Prime.
The result will be returned as status.
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]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Styles and typos fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc Addition [Tomas]
memcpy for const length.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 57 +++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 270baf24f21b..3e4f91e8b8f4 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -168,12 +168,67 @@ mei_verify_receiver_cert_prepare_km(struct device *dev,
return 0;
}
+/**
+ * mei_verify_hprime() - Verify AKE_Send_H_prime at ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rx_hprime: AKE_Send_H_prime msg for ME FW verification
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_verify_hprime(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !rx_hprime)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(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 = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
+ HDCP_2_2_H_PRIME_LEN);
+
+ byte = mei_cldev_send(cldev, (u8 *)_hprime_in,
+ sizeof(send_hprime_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_hprime_out,
+ sizeof(send_hprime_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", 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 -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
- .verify_hprime = NULL,
+ .verify_hprime = mei_verify_hprime,
.store_pairing_info = NULL,
.initiate_locality_check = NULL,
.verify_lprime = NULL,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 33/39] misc/mei/hdcp: Enabling the HDCP authentication
Request to ME to configure a port as authenticated.
On Success, ME FW will mark the port as authenticated and provides
HDCP cipher with the encryption keys.
Enabling the Authentication can be requested once all stages of
HDCP2.2 authentication is completed by interacting with ME FW.
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]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style and typos fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebased.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 54 +++-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 9f24a66e3260..9569a5b85fd0 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -586,6 +586,58 @@ static int mei_verify_mprime(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_enable_hdcp_authentication() - Mark a port as authenticated through ME
FW
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_enable_hdcp_authentication(struct device *dev, struct hdcp_port_data *data)
+{
+ struct wired_cmd_enable_auth_in enable_auth_in = { { 0 } };
+ struct wired_cmd_enable_auth_out enable_auth_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(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 = (u8)GET_MEI_DDI_INDEX(data->port);
+ enable_auth_in.stream_type = data->streams[0].stream_type;
+
+ byte = mei_cldev_send(cldev, (u8 *)_auth_in,
+ sizeof(enable_auth_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_auth_out,
+ sizeof(enable_auth_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", 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 -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -598,7 +650,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.get_session_key = mei_get_session_key,
.repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
.verify_mprime = mei_verify_mprime,
- .enable_hdcp_authentication = NULL,
+ .enable_hdcp_authentication = mei_enable_hdcp_authentication,
.close_hdcp_session = NULL,
};
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 28/39] 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]
v4:
%zd used for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 56 +++-
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 809d6270b6c1..db1492f64d6b 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -281,6 +281,60 @@ mei_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_initiate_locality_check() - Prepare LC_Init
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @lc_init_data: LC_Init msg output
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_initiate_locality_check(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !lc_init_data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ lc_init_in.header.api_version = HDCP_API_VERSION;
+ lc_init_in.header.command_id = WIRED_INIT_LOCALITY_CHECK;
+ lc_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ lc_init_in.header.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 = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_init_out, sizeof(lc_init_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", 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 -EIO;
+ }
+
+ 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);
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -288,7 +342,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
.verify_hprime = mei_verify_hprime,
.store_pairing_info = mei_store_pairing_info,
- .initiate_locality_check = NULL,
+ .initiate_locality_check = mei_initiate_locality_check,
.verify_lprime = NULL,
.get_session_key = NULL,
.repeater_check_flow_prepare_ack = NULL,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 38/39] FOR_TEST: i915/Kconfig: Select mei_hdcp by I915
FOR TESTING PURPOSE ONLY. By default INTEL_MEI_HDCP is set to y. This patch is created to test the interface between I915 and MEI_HDCP. Signed-off-by: Ramalingam C --- drivers/misc/mei/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig index 9c518b7f0011..90ed55210447 100644 --- a/drivers/misc/mei/Kconfig +++ b/drivers/misc/mei/Kconfig @@ -48,5 +48,6 @@ config INTEL_MEI_HDCP tristate "Intel HDCP2.2 services of ME Interface" select INTEL_MEI_ME depends on DRM_I915 + default y help MEI Support for HDCP2.2 Services on Intel SoCs. -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 32/39] 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]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
endianness conversion func is moved to drm_hdcp.h [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
drm_hdcp2_u32_to_seq_num() is used for u32 to seq_num.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 66 +++-
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b8c039107d0f..9f24a66e3260 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -522,6 +522,70 @@ mei_repeater_check_flow_prepare_ack(struct device *dev,
return 0;
}
+/**
+ * mei_verify_mprime() - Verify mprime.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @stream_ready: RepeaterAuth_Stream_Ready msg for ME FW verification.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_verify_mprime(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !stream_ready || !data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(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 = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
+ HDCP_2_2_MPRIME_LEN);
+ drm_hdcp2_u32_to_seq_num(verify_mprime_in.seq_num_m, data->seq_num_m);
+ memcpy(verify_mprime_in.streams, data->streams,
+ (data->k * sizeof(struct hdcp2_streamid_type)));
+
+ verify_mprime_in.k = __swab16(data->k);
+
+ byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
+ sizeof(verify_mprime_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_mprime_out,
+ sizeof(verify_mprime_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", 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 -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -533,7 +597,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.verify_lprime = mei_verify_lprime,
.get_session_key = mei_get_session_key,
.repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
- .verify_mprime = NULL,
+ .verify_mprime = mei_verify_mprime,
.enable_hdcp_authentication = NULL,
.close_hdcp_session = NULL,
};
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface
Mei hdcp driver is designed as component slave for the I915 component
master.
v2: Rebased.
v3:
Notifier chain is adopted for cldev state update [Tomas]
v4:
Made static dummy functions as inline in mei_hdcp.h
API for polling client device status
IS_ENABLED used in header, for config status for mei_hdcp.
v5:
Replacing the notifier with component framework. [Daniel]
v6:
Rebased on the I915 comp master redesign.
v7:
mei_hdcp_component_registered is made static [Uma]
Need for global static variable mei_cldev is removed.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 67 +---
1 file changed, 63 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b22a71e8c5d7..3de1700dcc9f 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,11 +23,14 @@
#include
#include
#include
+#include
#include
#include
#include "mei_hdcp.h"
+static bool mei_hdcp_component_registered;
+
/**
* mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
* @dev: device corresponding to the mei_cl_device
@@ -691,8 +694,7 @@ mei_close_hdcp_session(struct device *dev, struct
hdcp_port_data *data)
return 0;
}
-static __attribute__((unused))
-struct i915_hdcp_component_ops mei_hdcp_ops = {
+static struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
@@ -707,20 +709,77 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.close_hdcp_session = mei_close_hdcp_session,
};
+static int mei_hdcp_component_bind(struct device *mei_kdev,
+ struct device *i915_kdev, void *data)
+{
+ struct i915_component_master *master_comp = data;
+
+ dev_info(mei_kdev, "MEI HDCP comp bind\n");
+ WARN_ON(master_comp->hdcp_ops);
+ master_comp->hdcp_ops = _hdcp_ops;
+ master_comp->mei_dev = mei_kdev;
+
+ return 0;
+}
+
+static void mei_hdcp_component_unbind(struct device *mei_kdev,
+ struct device *i915_kdev, void *data)
+{
+ struct i915_component_master *master_comp = data;
+
+ dev_info(mei_kdev, "MEI HDCP comp unbind\n");
+ master_comp->hdcp_ops = NULL;
+ master_comp->mei_dev = NULL;
+}
+
+static const struct component_ops mei_hdcp_component_bind_ops = {
+ .bind = mei_hdcp_component_bind,
+ .unbind = mei_hdcp_component_unbind,
+};
+
+static void mei_hdcp_component_init(struct device *dev)
+{
+ int ret;
+
+ dev_info(dev, "MEI HDCP comp init\n");
+ ret = component_add(dev, _hdcp_component_bind_ops);
+ if (ret < 0) {
+ dev_err(dev, "Failed to add MEI HDCP comp (%d)\n", ret);
+ return;
+ }
+
+ mei_hdcp_component_registered = true;
+}
+
+static void mei_hdcp_component_cleanup(struct device *dev)
+{
+ if (!mei_hdcp_component_registered)
+ return;
+
+ dev_info(dev, "MEI HDCP comp cleanup\n");
+ component_del(dev, _hdcp_component_bind_ops);
+ mei_hdcp_component_registered = false;
+}
+
static int mei_hdcp_probe(struct mei_cl_device *cldev,
const struct mei_cl_device_id *id)
{
int ret;
ret = mei_cldev_enable(cldev);
- if (ret < 0)
+ if (ret < 0) {
dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
+ return ret;
+ }
+ mei_hdcp_component_init(>dev);
- return ret;
+ return 0;
}
static int mei_hdcp_remove(struct mei_cl_device *cldev)
{
+ mei_hdcp_component_cleanup(>dev);
+
return mei_cldev_disable(cldev);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 27/39] 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]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
memcpy for const length.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 60 +++-
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 3e4f91e8b8f4..809d6270b6c1 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -223,13 +223,71 @@ static int mei_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_store_pairing_info() - Store pairing info received at ME FW
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @pairing_info: AKE_Send_Pairing_Info msg input to ME FW
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_store_pairing_info(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !pairing_info)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(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 = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
+ HDCP_2_2_E_KH_KM_LEN);
+
+ byte = mei_cldev_send(cldev, (u8 *)_info_in,
+ sizeof(pairing_info_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_info_out,
+ sizeof(pairing_info_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", 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 -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
.verify_hprime = mei_verify_hprime,
- .store_pairing_info = NULL,
+ .store_pairing_info = mei_store_pairing_info,
.initiate_locality_check = NULL,
.verify_lprime = NULL,
.get_session_key = NULL,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 24/39] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
Request ME FW to start the HDCP2.2 session for an intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
to 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]
v4:
%zd is used for size [Alexander]
%s/return -1/return -EIO [Alexander]
Spellings in commit msg is fixed [Uma]
v5: Rebased.
v6:
Collected the rb-ed by.
Realigning the patches in the series.
v7:
Adjust to the new mei interface.
Fix for kdoc.
v8:
K-Doc Addition.
memcpy for const length.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 81
drivers/misc/mei/hdcp/mei_hdcp.h | 28 ++
2 files changed, 109 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 6e7101512842..124f02e2b7c4 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,6 +23,87 @@
#include
#include
#include
+#include
+#include
+
+#include "mei_hdcp.h"
+
+/**
+ * mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @ake_data: AKE_Init msg output.
+ *
+ * Return: 0 on Success, <0 on Failure.
+ */
+static int
+mei_initiate_hdcp2_session(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !ake_data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(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 = (u8)GET_MEI_DDI_INDEX(data->port);
+ session_init_in.protocol = data->protocol;
+
+ byte = mei_cldev_send(cldev, (u8 *)_init_in,
+ sizeof(session_init_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_init_out,
+ sizeof(session_init_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", 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 -EIO;
+ }
+
+ 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, HDCP_2_2_RTX_LEN);
+
+ return 0;
+}
+
+static __attribute__((unused))
+struct i915_hdcp_component_ops mei_hdcp_ops = {
+ .owner = THIS_MODULE,
+ .initiate_hdcp2_session = mei_initiate_hdcp2_session,
+ .verify_receiver_cert_prepare_km = NULL,
+ .verify_hprime = NULL,
+ .store_pairing_info = NULL,
+ .initiate_locality_check = NULL,
+ .verify_lprime = NULL,
+ .get_session_key = NULL,
+ .repeater_check_flow_prepare_ack = NULL,
+ .verify_mprime = NULL,
+ .enable_hdcp_authentication = NULL,
+ .close_hdcp_session = NULL,
+};
static int mei_hdcp_probe(struct mei_cl_device *cldev,
const struct mei_cl_device_id *id)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
index d1456e3dbf22..cac1a525476d 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.h
+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
@@ -363,4 +363,32 @@ struct wired_cmd_repeater_auth_stream_req_out {
struct hdcp_port_id port;
} __packed;
+enum mei_hdcp_ddi {
+ MEI_DDI_INVALID_PORT = 0x0,
+
+ MEI_DDI_B = 1,
+ MEI_DDI_C,
+ MEI_DDI_D,
+ MEI_DDI_E,
+ MEI_DDI_F,
+ MEI_DDI_A = 7,
+ MEI_DDI_RANGE_END = MEI_DDI_A,
+};
+
+enum i915_port {
+ PORT_NONE = -1,
+
+ PORT_A = 0,
+ PORT_B,
+ PORT_C,
+ PORT_D,
+ PORT_E,
+ PORT_F,
+ I915_MAX_PORTS,
+};
+
+#define GET_MEI_DDI_INDEX(p) ({
[Intel-gfx] [PATCH v9 37/39] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 42327ed30903..2b9e1b6d0b1e 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
@@ -20,6 +21,27 @@
#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
#define HDCP2_LC_RETRY_CNT 3
+static void kbl_repositioning_enc_en_signal(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ struct drm_crtc *crtc = connector->base.state->crtc;
+ struct intel_crtc *intel_crtc = container_of(crtc,
+struct intel_crtc, base);
+ u32 scanline;
+
+ for (;;) {
+ scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
+ if (scanline > 100 && scanline < 200)
+ break;
+ usleep_range(25, 50);
+ }
+
+ hdcp->shim->toggle_signalling(intel_dig_port, false);
+ hdcp->shim->toggle_signalling(intel_dig_port, true);
+}
+
static
bool intel_hdcp_is_ksv_valid(u8 *ksv)
{
@@ -1382,6 +1404,13 @@ static int hdcp2_enable_encryption(struct
intel_connector *connector)
}
if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
+ /*
+* WA: To fix incorrect positioning of the window of
+* opportunity and enc_en signalling in KABYLAKE.
+*/
+ if (IS_KABYLAKE(dev_priv) && hdcp->shim->toggle_signalling)
+ kbl_repositioning_enc_en_signal(connector);
+
/* Link is Authenticated. Now set for Encryption */
I915_WRITE(HDCP2_CTL_DDI(port),
I915_READ(HDCP2_CTL_DDI(port)) |
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 29/39] 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]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style fixed [Uma]
v5: Rebased.
v6:
Collected the Rb-ed by.
Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
memcpy for const length.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 59 +++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index db1492f64d6b..b6cc55c13d4a 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -335,6 +335,63 @@ mei_initiate_locality_check(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_verify_lprime() - Verify lprime.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rx_lprime: LC_Send_L_prime msg for ME FW verification
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_verify_lprime(struct device *dev, struct hdcp_port_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 mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !rx_lprime)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(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 = (u8)GET_MEI_DDI_INDEX(data->port);
+
+ memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
+ HDCP_2_2_L_PRIME_LEN);
+
+ byte = mei_cldev_send(cldev, (u8 *)_lprime_in,
+ sizeof(verify_lprime_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_lprime_out,
+ sizeof(verify_lprime_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", 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 -EIO;
+ }
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -343,7 +400,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.verify_hprime = mei_verify_hprime,
.store_pairing_info = mei_store_pairing_info,
.initiate_locality_check = mei_initiate_locality_check,
- .verify_lprime = NULL,
+ .verify_lprime = mei_verify_lprime,
.get_session_key = NULL,
.repeater_check_flow_prepare_ack = NULL,
.verify_mprime = NULL,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 31/39] misc/mei/hdcp: Repeater topology verification and ack
Request ME to verify the downstream topology information received.
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]
v4:
%zd for ssize_t [Alexander]
%s/return -1/return -EIO [Alexander]
Style and typos fixed [Uma]
v5: Rebased.
v6: Rebasing.
v7:
Adjust to the new mei interface.
Fix for Kdoc.
v8:
K-Doc addition. [Tomas]
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 76 +++-
1 file changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 554e07ba69c3..b8c039107d0f 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -448,6 +448,80 @@ static int mei_get_session_key(struct device *dev, struct
hdcp_port_data *data,
return 0;
}
+/**
+ * mei_repeater_check_flow_prepare_ack() - Validate the Downstream topology
+ * and prepare rep_ack.
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @rep_topology: Receiver ID List to be validated
+ * @rep_send_ack : repeater ack from ME FW.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_repeater_check_flow_prepare_ack(struct device *dev,
+ struct hdcp_port_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 mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !rep_topology || !rep_send_ack || !data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(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 =
+ (u8)GET_MEI_DDI_INDEX(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_V_PRIME_HALF_LEN);
+ memcpy(verify_repeater_in.receiver_ids, rep_topology->receiver_ids,
+ HDCP_2_2_RECEIVER_IDS_MAX_LEN);
+
+ byte = mei_cldev_send(cldev, (u8 *)_repeater_in,
+ sizeof(verify_repeater_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)_repeater_out,
+ sizeof(verify_repeater_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", 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 -EIO;
+ }
+
+ memcpy(rep_send_ack->v, verify_repeater_out.v,
+ HDCP_2_2_V_PRIME_HALF_LEN);
+ rep_send_ack->msg_id = HDCP_2_2_REP_SEND_ACK;
+
+ return 0;
+}
+
static __attribute__((unused))
struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -458,7 +532,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.initiate_locality_check = mei_initiate_locality_check,
.verify_lprime = mei_verify_lprime,
.get_session_key = mei_get_session_key,
- .repeater_check_flow_prepare_ack = NULL,
+ .repeater_check_flow_prepare_ack = mei_repeater_check_flow_prepare_ack,
.verify_mprime = NULL,
.enable_hdcp_authentication = NULL,
.close_hdcp_session = NULL,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 36/39] drm/i915: Commit CP without modeset
Commits the content protection change of a connector,
without crtc modeset. This improves the user experience.
Originally proposed by Sean Paul at v3 of HDCP1.4 framework
https://patchwork.freedesktop.org/patch/191759/. For some
reason this was dropped, but needed for the proper functionality
of HDCP encryption.
Signed-off-by: Ramalingam C
Suggested-by: Sean Paul
---
drivers/gpu/drm/i915/intel_ddi.c | 7 ---
drivers/gpu/drm/i915/intel_display.c | 10 ++
drivers/gpu/drm/i915/intel_drv.h | 5 +
drivers/gpu/drm/i915/intel_hdcp.c| 32
4 files changed, 43 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 92c0bf70fe09..feb78780976d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3548,11 +3548,6 @@ static void intel_enable_ddi(struct intel_encoder
*encoder,
intel_enable_ddi_hdmi(encoder, crtc_state, conn_state);
else
intel_enable_ddi_dp(encoder, crtc_state, conn_state);
-
- /* Enable hdcp if it's desired */
- if (conn_state->content_protection ==
- DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
}
static void intel_disable_ddi_dp(struct intel_encoder *encoder,
@@ -3595,8 +3590,6 @@ static void intel_disable_ddi(struct intel_encoder
*encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
- intel_hdcp_disable(to_intel_connector(old_conn_state->connector));
-
if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
intel_disable_ddi_hdmi(encoder, old_crtc_state, old_conn_state);
else
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 13e5650b6f31..05bae91512cd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12922,6 +12922,8 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct intel_crtc_state *new_intel_crtc_state, *old_intel_crtc_state;
+ struct drm_connector_state *old_conn_state, *new_conn_state;
+ struct drm_connector *connector;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
u64 put_domains[I915_MAX_PIPES] = {};
@@ -13015,9 +13017,17 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
}
}
+ for_each_oldnew_connector_in_state(state, connector, old_conn_state,
+ new_conn_state, i)
+ intel_hdcp_atomic_pre_commit(connector, old_conn_state,
+new_conn_state);
+
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
dev_priv->display.update_crtcs(state);
+ for_each_new_connector_in_state(state, connector, new_conn_state, i)
+ intel_hdcp_atomic_commit(connector, new_conn_state);
+
/* FIXME: We should call drm_atomic_helper_commit_hw_done() here
* already, but still need the state for the delayed optimization. To
* fix this:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 60d1359e55f4..40357e17324e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2100,6 +2100,11 @@ static inline void
intel_backlight_device_unregister(struct intel_connector *con
void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
+void intel_hdcp_atomic_pre_commit(struct drm_connector *connector,
+ struct drm_connector_state *old_state,
+ struct drm_connector_state *new_state);
+void intel_hdcp_atomic_commit(struct drm_connector *connector,
+ struct drm_connector_state *new_state);
int intel_hdcp_init(struct intel_connector *connector,
const struct intel_hdcp_shim *hdcp_shim,
bool hdcp2_supported);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index cafda8903b50..42327ed30903 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1760,7 +1760,6 @@ void intel_hdcp_atomic_check(struct drm_connector
*connector,
{
uint64_t old_cp = old_state->content_protection;
uint64_t new_cp = new_state->content_protection;
- struct drm_crtc_state *crtc_state;
if (!new_state->crtc) {
/*
@@ -1781,10 +1780,35 @@ void
[Intel-gfx] [PATCH v9 18/39] drm/i915: Add HDCP2.2 support for DP connectors
On DP connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
v3:
Collected the reviewed-by received.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
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 a8ace7d85918..87078dcc372c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -7213,7 +7213,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
int ret = intel_hdcp_init(intel_connector, _dp_hdcp_shim,
- false);
+ is_hdcp2_supported(dev_priv));
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: correct the pitch check for NV12 framebuffer
On Wed, Dec 12, 2018 at 1:15 PM Ville Syrjälä
wrote:
>
> On Wed, Dec 12, 2018 at 09:33:49PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote:
> > > > framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> > > > of the width. This patch corrects it.
> > > >
> > > > For instance, a 480p video, whose width and pitch are 854 and 896
> > > > respectively, is excluded for NV12 plane so far.
> > > >
> > > > Signed-off-by: Dongseong Hwang
> > > > Cc: Chandra Konduru
> > > > Cc: Vidya Srinivas
> > > > Cc: Ville Syrjälä
> > > > Cc: Juha-Pekka Heikkila
> > > > ---
> > > > drivers/gpu/drm/i915/intel_display.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 13e5650..8a3de12 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -14600,7 +14600,7 @@ static int intel_framebuffer_init(struct
> > > > intel_framebuffer *intel_fb,
> > > > if (fb->format->format == DRM_FORMAT_NV12 &&
> > > > (fb->width < SKL_MIN_YUV_420_SRC_W ||
> > > >fb->height < SKL_MIN_YUV_420_SRC_H ||
> > > > - (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
> > > > + (fb->pitches[0] % 4) != 0 || (fb->height % 4) != 0)) {
> > >
> > > The stride can never be misaligned like that. It'll be at least tile
> > > aligned, or 64 byte aligned with linear buffers.
> > >
> > > Anyways this entire piece of code doesn't make too much sense. The fb
> > > size doesn't really matter for us, only the src viewport size matters.
> > > That one we limit to a minimum of 2x2 pixels w/o scaling, and 16x16
> > > pixems w/ scaling. So looks like this code can be just ripped out.
> >
> > Do we have igt testcases for these cornercases in igt? Obviously would
> > need to be intel specific subtests ...
>
> Can't spot anything quite that specific. Someone would need to write
> one I suppose. Also Imre has a test somewhere on the list for testing
> the plane clipping underrun fails which tests small src viewport sizes,
> and JP has been working on a rotation vs. clipping test that is also
> somewhat related. Not sure if we could combine any of these somehow
> to avoid having too many similar tests.
Ap pointed out there is i915 workaround
1106 Display NV12, Rotation, Horizontal flip
Display corruption/color shift observed when using NV12 with 270
rotation or 90 rotation + horizontal flip.
WA: NV12 with 270 rotation or 90 rotation + horizontal flip requires
the programmed plane height to be a multiple of 4.
GEN9:ALL
GLK:ALL
GLV:ALL
CNL:*:A
CNL:*:B
I think this condition was introduced to deal with the workaround, and
I think the stride restriction is enough for the above workaround.
Ville, if I add the igt covering this change, is it good to land?
Best regards,
Dongseong
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 39/39] FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4
Just excluding the LSPCon HDMI ports from the HDCP1.4 testing.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 40a61ef9aac1..c4badca83523 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5076,6 +5076,9 @@ static int i915_hdcp_sink_capability_show(struct seq_file
*m, void *data)
{
struct drm_connector *connector = m->private;
struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_digital_port *intel_dig_port =
+ conn_to_dig_port(intel_connector);
+ bool is_hdcp14;
if (connector->status != connector_status_connected)
return -ENODEV;
@@ -5086,8 +5089,11 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
- seq_printf(m, "%s ", !intel_hdcp_capable(intel_connector) ?
- "None" : "HDCP1.4");
+
+ /* Excluding the Lspcon for Testing Purpose */
+ is_hdcp14 = intel_hdcp_capable(intel_connector) &&
+ !intel_dig_port->lspcon.active;
+ seq_printf(m, "%s ", !is_hdcp14 ? "None" : "HDCP1.4");
seq_puts(m, "\n");
return 0;
--
2.7.4
___
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: Implement HDCP2.2 (rev11)
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev11)
URL : https://patchwork.freedesktop.org/series/38254/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5310 -> Patchwork_11081
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11081 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11081, 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/38254/revisions/11/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11081:
### IGT changes ###
Possible regressions
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-r: PASS -> DMESG-WARN
- fi-kbl-7567u: PASS -> DMESG-WARN
- fi-glk-j4005: PASS -> DMESG-WARN
- fi-glk-dsi: PASS -> DMESG-WARN
- fi-kbl-7500u: PASS -> DMESG-FAIL
- fi-kbl-guc: PASS -> DMESG-WARN
- fi-kbl-7560u: PASS -> DMESG-WARN
* igt@gem_mmap_gtt@basic-write:
- fi-kbl-7500u: PASS -> DMESG-WARN
* igt@i915_hangman@error-state-basic:
- fi-kbl-guc: PASS -> INCOMPLETE
* igt@i915_module_load@reload:
- fi-kbl-x1275: PASS -> DMESG-FAIL
* {igt@runner@aborted}:
- fi-glk-dsi: NOTRUN -> FAIL
- fi-kbl-7500u: NOTRUN -> FAIL
- fi-kbl-7560u: NOTRUN -> FAIL
- fi-glk-j4005: NOTRUN -> FAIL
- fi-kbl-7567u: NOTRUN -> FAIL
- fi-kbl-x1275: NOTRUN -> FAIL
- fi-kbl-r: NOTRUN -> FAIL
- fi-kbl-guc: NOTRUN -> FAIL
Warnings
* igt@gem_mmap_gtt@basic-small-bo:
- fi-kbl-7500u: PASS -> SKIP +21
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: PASS -> SKIP +171
* igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-x1275: PASS -> SKIP +225
Known issues
Here are the changes found in Patchwork_11081 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_module_load@reload:
- fi-icl-u2: NOTRUN -> DMESG-FAIL [fdo#107732]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
* igt@kms_busy@basic-flip-b:
- fi-bdw-gvtdvm: FAIL [fdo#103182] -> PASS
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2: DMESG-FAIL [fdo#103375] / [fdo#107732] / [fdo#108070]
/ [fdo#108924] -> SKIP
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107732]: https://bugs.freedesktop.org/show_bug.cgi?id=107732
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108924]: https://bugs.freedesktop.org/show_bug.cgi?id=108924
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
Participating hosts (47 -> 43)
--
Missing(4): fi-kbl-soraka fi-ctg-p8600 fi-ilk-m540 fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_5310 -> Patchwork_11081
CI_DRM_5310: 1f86f1fb70f082ed93450c328e518d8013d23953 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4746: 2c793666d8c8328733f5769b16ae5858fee97f3f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11081: 0fe879c951f81adcc08648928535f1f8af2fad1b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0fe879c951f8 FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4
ef3c22a3dcc1 FOR_TEST: i915/Kconfig: Select mei_hdcp by I915
446a760cbe18 drm/i915: Fix KBL HDCP2.2 encrypt status signalling
aee57816a8a6 drm/i915: Commit CP without modeset
7b32fd10999d misc/mei/hdcp: Component framework for I915 Interface
e470b2c2b13f
Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new drm_syncobj_add_point interface v2
在 2018/12/12 20:24, Daniel Vetter 写道: > On Wed, Dec 12, 2018 at 12:40 PM Zhou, David(ChunMing) > wrote: >> + Daniel Rakos and Jason Ekstrand. >> >> Below is the background, which is from Daniel R should be able to explain >> that's why: >> " ISVs, especially those coming from D3D12, are unsatisfied with the >> behavior of the Vulkan semaphores as they are unhappy with the fact that for >> every single dependency they need to use separate semaphores due to their >> binary nature. >> Compared to that a synchronization primitive like D3D12 monitored fences >> enable one of those to be used to track a sequence of operations by simply >> associating timeline values to the completion of individual operations. This >> allows them to track the lifetime and usage of resources and the ordered >> completion of sequences. >> Besides that, they also want to use a single synchronization primitive to be >> able to handle GPU-to-GPU and GPU-to-CPU dependencies, compared to using >> semaphores for the former and fences for the latter. >> In addition, compared to legacy semaphores, timeline semaphores are proposed >> to support wait-before-signal, i.e. allow enqueueing a semaphore wait >> operation with a wait value that is larger than any of the already enqueued >> signal values. This seems to be a hard requirement for ISVs. Without >> UMD-side queue batching, and even UMD-side queue batching doesn’t help the >> situation when such a semaphore is externally shared with another API. Thus >> in order to properly support wait-before-signal the KMD implementation has >> to also be able to support such dependencies. >> " > I was tangetially involved in that wg too, I understand the overall > use-case of vk timelines. I don't understand the exact corner case > here, because I wasn't deeply involved in the details. all details are here: https://gitlab.khronos.org/vulkan/vulkan/merge_requests/2696 -David > -Daniel > >> Btw, we already add test case to igt, and tested by many existing test, like >> libdrm unit test, igt related test, vulkan cts, and steam games. >> >> -David >>> -Original Message- >>> From: Daniel Vetter >>> Sent: Wednesday, December 12, 2018 7:15 PM >>> To: Koenig, Christian >>> Cc: Zhou, David(ChunMing) ; dri-devel >> de...@lists.freedesktop.org>; amd-gfx list ; >>> intel-gfx ; Christian König >>> >>> Subject: Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new >>> drm_syncobj_add_point interface v2 >>> >>> On Wed, Dec 12, 2018 at 12:08 PM Koenig, Christian >>> wrote: Am 12.12.18 um 11:49 schrieb Daniel Vetter: > On Fri, Dec 07, 2018 at 11:54:15PM +0800, Chunming Zhou wrote: >> From: Christian König >> >> Use the dma_fence_chain object to create a timeline of fence >> objects instead of just replacing the existing fence. >> >> v2: rebase and cleanup >> >> Signed-off-by: Christian König > Somewhat jumping back into this. Not sure we discussed this already > or not. I'm a bit unclear on why we have to chain the fences in the >>> timeline: > - The timeline stuff is modelled after the WDDM2 monitored fences. >>> Which > really are just u64 counters in memory somewhere (I think could be > system ram or vram). Because WDDM2 has the memory management >>> entirely > separated from rendering synchronization it totally allows userspace > to > create loops and deadlocks and everything else nasty using this - the > memory manager won't deadlock because these monitored fences >>> never leak > into the buffer manager. And if CS deadlock, gpu reset takes care of > the > mess. > > - This has a few consequences, as in they seem to indeed work like a > memory location: Userspace incrementing out-of-order (because they >>> run > batches updating the same fence on different engines) is totally fine, > as is doing anything else "stupid". > > - Now on linux we can't allow anything, because we need to make sure >>> that > deadlocks don't leak into the memory manager. But as long as we block > until the underlying dma_fence has materialized, nothing userspace can > do will lead to such a deadlock. Even if userspace ends up submitting > jobs without enough built-in synchronization, leading to out-of-order > signalling of fences on that "timeline". And I don't think that would > pose a problem for us. > > Essentially I think we can look at timeline syncobj as a dma_fence > container indexed through an integer, and there's no need to enforce > that the timline works like a real dma_fence timeline, with all it's > guarantees. It's just a pile of (possibly, if userspace is stupid) > unrelated dma_fences. You could implement the entire thing in > userspace after all, except for the "we want to share these timeline > objects between processes" problem. > >
Re: [Intel-gfx] [PATCH 1/2] drm: Add color management LUT validation helpers
Hi Matt,
On Tue, Dec 11, 2018 at 05:05:50PM -0800, Matt Roper wrote:
> Some hardware may place additional restrictions on the gamma/degamma
> curves described by our LUT properties. E.g., that a gamma curve never
> decreases or that the red/green/blue channels of a LUT's entries must be
> equal. Let's add a couple helpers that drivers can use to test that a
> userspace-provided LUT doesn't violate hardware requirements.
>
> Cc: Uma Shankar
> Cc: Swati Sharma
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 53
>
> include/drm/drm_color_mgmt.h | 3 +++
> 2 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 07dcf47daafe..41e617e34c10 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -462,3 +462,56 @@ int drm_plane_create_color_properties(struct drm_plane
> *plane,
> return 0;
> }
> EXPORT_SYMBOL(drm_plane_create_color_properties);
> +
> +/**
> + * drm_color_lut_has_equal_channels - check LUT for equal r/g/b values
> + * @lut: property blob containing LUT to check
> + *
> + * Helper to check whether the entries of a LUT all have equal values for the
> + * red, green, and blue channels. Some hardware can only be programmed
> + * with a single value per LUT entry, which is assumed to apply to all
> + * three color components.
> + */
> +bool drm_color_lut_has_equal_channels(struct drm_property_blob *lut)
> +{
> + struct drm_color_lut *entry;
> + int i;
> +
> + if (!lut)
> + return true;
> +
> + entry = lut->data;
> + for (i = 0; i < drm_color_lut_size(lut); i++)
> + if (entry[i].red != entry[i].blue ||
> + entry[i].red != entry[i].green)
> + return false;
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_color_lut_has_equal_channels);
We've got this open-coded for some of our HW, so thanks for the helper
:-)
> +
> +/**
> + * drm_color_lut_is_increasing - check that LUT is always flat/increasing
> + * @lut: LUT to check
> + *
> + * Helper to check whether the entries of a LUT are always flat or increasing
> + * (never decreasing).
> + */
> +bool drm_color_lut_is_increasing(struct drm_property_blob *lut)
> +{
> + struct drm_color_lut *entry;
> + int i;
> +
> + if (!lut)
> + return true;
> +
> + entry = lut->data;
> + for (i = 1; i < drm_color_lut_size(lut); i++)
> + if (entry[i].red < entry[i-1].red ||
> + entry[i].green < entry[i-1].green ||
> + entry[i].blue < entry[i-1].blue)
> + return false;
nit: I think checkpatch likes spaces around operators: [i - 1]
Another thought: in the worst case with a valid LUT with HW that needs
both checks, you can end up iterating the whole LUT twice - once for
increasing, and once for equal channels.
Maybe this could be a single function with a mask of constraints to
check:
drm_color_lut_check(lut, DRM_COLOR_LUT_EQUAL_CHANNELS |
DRM_COLOR_LUT_INCREASING);
Not sure if it would turn out messy with the different loop bounds.
Either way, for mali-dp it makes no difference, and probably
LUTs aren't changing all the time so:
Reviewed-by: Brian Starkey
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_color_lut_is_increasing);
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 90ef9996d9a4..6c38f5477e29 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -69,4 +69,7 @@ int drm_plane_create_color_properties(struct drm_plane
> *plane,
> u32 supported_ranges,
> enum drm_color_encoding default_encoding,
> enum drm_color_range default_range);
> +
> +bool drm_color_lut_has_equal_channels(struct drm_property_blob *lut);
> +bool drm_color_lut_is_increasing(struct drm_property_blob *lut);
> #endif
> --
> 2.14.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 3/5] drm/dp: Implement I2C_M_STOP for i2c-over-aux
On Mon, Dec 10, 2018 at 06:47:00PM -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2018-09-28 at 21:04 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Consult the I2C_M_STOP flag to determine whether to set the MOT bit
> > or
> > not. Makes it possible to send multiple messages in one go with
> > stop+start generated between the messages (as opposed nothing or
> > repstart depending on whether thr address/rw changed).
> >
> > Not sure anyone has actual use for this but figured I'd handle it
> > since I started to look at that flag for MST remote i2c xfers.
> >
> Don't see the I2C_M_STOP flag anywhere in drm_edid.c, but the change
> introduced here does make sense.
Iirc it's the i2c core library which takes an entire transaction, splits
it up, and sets the stop flag only on the very last one. Or something like
that.
-Daniel
>
> Reviewed-by: Dhinakaran Pandiyan
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 37c01b6076ec..e85cea299d2a 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -884,7 +884,8 @@ static void drm_dp_i2c_msg_set_request(struct
> > drm_dp_aux_msg *msg,
> > {
> > msg->request = (i2c_msg->flags & I2C_M_RD) ?
> > DP_AUX_I2C_READ : DP_AUX_I2C_WRITE;
> > - msg->request |= DP_AUX_I2C_MOT;
> > + if (!(i2c_msg->flags & I2C_M_STOP))
> > + msg->request |= DP_AUX_I2C_MOT;
> > }
> >
> > /*
>
> ___
> 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
Re: [Intel-gfx] [PATCH v8 05/35] drm/i915: MEI interface definition
On Wed, Dec 12, 2018 at 02:28:29PM +0530, C, Ramalingam wrote:
> On 12/7/2018 7:59 PM, Daniel Vetter wrote:
> > On Fri, Dec 07, 2018 at 11:22:44AM +0530, C, Ramalingam wrote:
> > > On 12/6/2018 3:53 PM, Daniel Vetter wrote:
> > > > On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:
> > > > > +static void i915_hdcp_component_master_unbind(struct device *dev)
> > > > > +{
> > > > > + struct drm_i915_private *dev_priv = kdev_to_i915(dev);
> > > > > +
> > > > > + intel_connectors_hdcp_disable(dev_priv);
> > > > Why this code? Once we've unregistered the driver, we should have shut
> > > > down the hardware completely. Which should have shut down all the hdcp
> > > > users too.
> > > This unbind might be triggered either due to master_del or component_del.
> > > if its triggered from mei through component_del, then before teardown of
> > > the i/f in component_unbind(), disable the ongoing HDCP session through
> > > hdcp_disable() for each connectors.
> > I looked at your v7 component code again. I think if we put the
> > drm_atomic_helper_shutdown() call into master_unbind, then we'll have taken
> > care
> > of that. Essentially what you're doing here is open-coding part of that
> > function. Better to just move the existing call to the right place.
> >
> > And shutting down the entire hw is kinda what master_unbind should be
> > doing I think. We might also need to move the general hw quiescent into
> > master_unbind, that should work too.
>
> Need some more information on this. As per v7 on master_unbind will invoke
> i915_unload_head that is i915_driver_unregister(dev_priv);
> Similarly master_bind will call the load_tail that is
> i915_driver_register(dev_priv);
>
> We are not initializing/shutting the HW in master_bind/unbind .
> But this comment is contradicting with current approach. Could you please
> elaborate.?
So my understanding is that we need to shut down all hdcp usage before
master_unbind completes, because otherwise we'll blow up: The mei_hdcp
component is gone already.
Now the other case for master_unbind is that the i915 pci device is
unloaded, and in that case again I think it makes sense to shut down the
hardware in master_unbind.
Now when I looked at v7, right after the component_unbind code in the i915
unload sequences comes the function calls to shut down the hardware. I
think it would make sense to them (or at least the
drm_atomic_helper_shutdown() call) into master_unbind.
This is somewhat asymetric, but that's ok: Load path doesn't enable
anything, we just keep the hardware as-is (to be able to support
flicker-free boôt-up). First modest is done by usersapce. Exception is if
you have fbcon enabled (and not use the fastboot patches that Hans just
merged), in that case the kernel will do the first modeset when we
regiseter the fbdev device.
Anyway, moving the drm_atomic_helper_shutdown() into the master_unbind
function in v7 should take care of disabling all outputs, and hence also
disabling all usage of hdcp component.
-Daniel
--
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
Re: [Intel-gfx] [PATCH 6/7] drm/xen: Don't set the dpms hook
On Mon, Dec 10, 2018 at 12:12:05PM +0200, Oleksandr Andrushchenko wrote:
> On 12/10/18 12:03 PM, Daniel Vetter wrote:
> > Doesn't do anything for atomic.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Oleksandr Andrushchenko
> > Cc: xen-de...@lists.xen.org
> > ---
> > drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c
> > b/drivers/gpu/drm/xen/xen_drm_front_conn.c
> > index c91ae532fa55..54af2669b1b3 100644
> > --- a/drivers/gpu/drm/xen/xen_drm_front_conn.c
> > +++ b/drivers/gpu/drm/xen/xen_drm_front_conn.c
> > @@ -89,7 +89,6 @@ static const struct drm_connector_helper_funcs
> > connector_helper_funcs = {
> > };
> > static const struct drm_connector_funcs connector_funcs = {
> > - .dpms = drm_helper_connector_dpms,
> > .fill_modes = drm_helper_probe_single_connector_modes,
> > .destroy = drm_connector_cleanup,
> > .reset = drm_atomic_helper_connector_reset,
>
> Reviewed-by: Oleksandr Andrushchenko
This and the previous patch merged, thanks for reviewing.
-Daniel
--
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
Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new drm_syncobj_add_point interface v2
On Fri, Dec 07, 2018 at 11:54:15PM +0800, Chunming Zhou wrote:
> From: Christian König
>
> Use the dma_fence_chain object to create a timeline of fence objects
> instead of just replacing the existing fence.
>
> v2: rebase and cleanup
>
> Signed-off-by: Christian König
Somewhat jumping back into this. Not sure we discussed this already or
not. I'm a bit unclear on why we have to chain the fences in the timeline:
- The timeline stuff is modelled after the WDDM2 monitored fences. Which
really are just u64 counters in memory somewhere (I think could be
system ram or vram). Because WDDM2 has the memory management entirely
separated from rendering synchronization it totally allows userspace to
create loops and deadlocks and everything else nasty using this - the
memory manager won't deadlock because these monitored fences never leak
into the buffer manager. And if CS deadlock, gpu reset takes care of the
mess.
- This has a few consequences, as in they seem to indeed work like a
memory location: Userspace incrementing out-of-order (because they run
batches updating the same fence on different engines) is totally fine,
as is doing anything else "stupid".
- Now on linux we can't allow anything, because we need to make sure that
deadlocks don't leak into the memory manager. But as long as we block
until the underlying dma_fence has materialized, nothing userspace can
do will lead to such a deadlock. Even if userspace ends up submitting
jobs without enough built-in synchronization, leading to out-of-order
signalling of fences on that "timeline". And I don't think that would
pose a problem for us.
Essentially I think we can look at timeline syncobj as a dma_fence
container indexed through an integer, and there's no need to enforce that
the timline works like a real dma_fence timeline, with all it's
guarantees. It's just a pile of (possibly, if userspace is stupid)
unrelated dma_fences. You could implement the entire thing in userspace
after all, except for the "we want to share these timeline objects between
processes" problem.
tldr; I think we can drop the dma_fence_chain complexity completely. Or at
least I'm not really understanding why it's needed.
Of course that means drivers cannot treat a drm_syncobj timeline as a
dma_fence timeline. But given the future fences stuff and all that, that's
already out of the window anyway.
What am I missing?
-Daniel
> ---
> drivers/gpu/drm/drm_syncobj.c | 37 +++
> include/drm/drm_syncobj.h | 5 +
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index e19525af0cce..51f798e2194f 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -122,6 +122,43 @@ static void drm_syncobj_remove_wait(struct drm_syncobj
> *syncobj,
> spin_unlock(>lock);
> }
>
> +/**
> + * drm_syncobj_add_point - add new timeline point to the syncobj
> + * @syncobj: sync object to add timeline point do
> + * @chain: chain node to use to add the point
> + * @fence: fence to encapsulate in the chain node
> + * @point: sequence number to use for the point
> + *
> + * Add the chain node as new timeline point to the syncobj.
> + */
> +void drm_syncobj_add_point(struct drm_syncobj *syncobj,
> +struct dma_fence_chain *chain,
> +struct dma_fence *fence,
> +uint64_t point)
> +{
> + struct syncobj_wait_entry *cur, *tmp;
> + struct dma_fence *prev;
> +
> + dma_fence_get(fence);
> +
> + spin_lock(>lock);
> +
> + prev = rcu_dereference_protected(syncobj->fence,
> + lockdep_is_held(>lock));
> + dma_fence_chain_init(chain, prev, fence, point);
> + rcu_assign_pointer(syncobj->fence, >base);
> +
> + list_for_each_entry_safe(cur, tmp, >cb_list, node) {
> + list_del_init(>node);
> + syncobj_wait_syncobj_func(syncobj, cur);
> + }
> + spin_unlock(>lock);
> +
> + /* Walk the chain once to trigger garbage collection */
> + dma_fence_chain_for_each(prev, fence);
> +}
> +EXPORT_SYMBOL(drm_syncobj_add_point);
> +
> /**
> * drm_syncobj_replace_fence - replace fence in a sync object.
> * @syncobj: Sync object to replace fence in
> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> index 7c6ed845c70d..8acb4ae4f311 100644
> --- a/include/drm/drm_syncobj.h
> +++ b/include/drm/drm_syncobj.h
> @@ -27,6 +27,7 @@
> #define __DRM_SYNCOBJ_H__
>
> #include "linux/dma-fence.h"
> +#include "linux/dma-fence-chain.h"
>
> /**
> * struct drm_syncobj - sync object.
> @@ -110,6 +111,10 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
>
> struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
>u32 handle);
> +void drm_syncobj_add_point(struct drm_syncobj *syncobj,
> +struct
Re: [Intel-gfx] [PATCH 1/7] drm/ch7006: Stop using drm_crtc_force_disable
On Mon, Dec 10, 2018 at 06:20:41PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 10, 2018 at 11:03:53AM +0100, Daniel Vetter wrote:
> > The correct way for legacy drivers to update properties that need to
> > do a full modeset, is to do a full modeset.
> >
> > Note that we don't need to call the drm_mode_config_internal helper
> > because we're not changing any of the refcounted paramters.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/i2c/ch7006_drv.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c
> > b/drivers/gpu/drm/i2c/ch7006_drv.c
> > index 544a8a2d3562..719c79d3fac9 100644
> > --- a/drivers/gpu/drm/i2c/ch7006_drv.c
> > +++ b/drivers/gpu/drm/i2c/ch7006_drv.c
> > @@ -359,10 +359,10 @@ static int ch7006_encoder_set_property(struct
> > drm_encoder *encoder,
> > if (modes_changed) {
> > drm_helper_probe_single_connector_modes(connector, 0, 0);
> >
> > - /* Disable the crtc to ensure a full modeset is
> > -* performed whenever it's turned on again. */
> > if (crtc)
> > - drm_crtc_force_disable(crtc);
> > + return drm_crtc_helper_set_mode(crtc, >mode,
> > + crtc->x, crtc->y,
> > + crtc->primary->fb);
>
> That guy seems to return a bool.
Indeed, thanks for spotting this. Will respin.
-Daniel
>
> > }
> >
> > return 0;
> > --
> > 2.20.0.rc1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
--
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
Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new drm_syncobj_add_point interface v2
Am 12.12.18 um 11:49 schrieb Daniel Vetter:
> On Fri, Dec 07, 2018 at 11:54:15PM +0800, Chunming Zhou wrote:
>> From: Christian König
>>
>> Use the dma_fence_chain object to create a timeline of fence objects
>> instead of just replacing the existing fence.
>>
>> v2: rebase and cleanup
>>
>> Signed-off-by: Christian König
> Somewhat jumping back into this. Not sure we discussed this already or
> not. I'm a bit unclear on why we have to chain the fences in the timeline:
>
> - The timeline stuff is modelled after the WDDM2 monitored fences. Which
>really are just u64 counters in memory somewhere (I think could be
>system ram or vram). Because WDDM2 has the memory management entirely
>separated from rendering synchronization it totally allows userspace to
>create loops and deadlocks and everything else nasty using this - the
>memory manager won't deadlock because these monitored fences never leak
>into the buffer manager. And if CS deadlock, gpu reset takes care of the
>mess.
>
> - This has a few consequences, as in they seem to indeed work like a
>memory location: Userspace incrementing out-of-order (because they run
>batches updating the same fence on different engines) is totally fine,
>as is doing anything else "stupid".
>
> - Now on linux we can't allow anything, because we need to make sure that
>deadlocks don't leak into the memory manager. But as long as we block
>until the underlying dma_fence has materialized, nothing userspace can
>do will lead to such a deadlock. Even if userspace ends up submitting
>jobs without enough built-in synchronization, leading to out-of-order
>signalling of fences on that "timeline". And I don't think that would
>pose a problem for us.
>
> Essentially I think we can look at timeline syncobj as a dma_fence
> container indexed through an integer, and there's no need to enforce that
> the timline works like a real dma_fence timeline, with all it's
> guarantees. It's just a pile of (possibly, if userspace is stupid)
> unrelated dma_fences. You could implement the entire thing in userspace
> after all, except for the "we want to share these timeline objects between
> processes" problem.
>
> tldr; I think we can drop the dma_fence_chain complexity completely. Or at
> least I'm not really understanding why it's needed.
>
> Of course that means drivers cannot treat a drm_syncobj timeline as a
> dma_fence timeline. But given the future fences stuff and all that, that's
> already out of the window anyway.
>
> What am I missing?
Good question, since that was exactly my initial idea as well.
Key point is that our Vulcan guys came back and said that this wouldn't
be sufficient, but I honestly don't fully understand why.
Anyway that's why David came up with using the fence array to wait for
all previously added fences, which I then later on extended into this
chain container.
I have to admit that it is way more defensive implemented this way. E.g.
there is much fewer things userspace can do wrong.
The principal idea is that when they mess things up they are always
going to wait more than necessary, but never less.
Christian.
> -Daniel
>
>> ---
>> drivers/gpu/drm/drm_syncobj.c | 37 +++
>> include/drm/drm_syncobj.h | 5 +
>> 2 files changed, 42 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>> index e19525af0cce..51f798e2194f 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -122,6 +122,43 @@ static void drm_syncobj_remove_wait(struct drm_syncobj
>> *syncobj,
>> spin_unlock(>lock);
>> }
>>
>> +/**
>> + * drm_syncobj_add_point - add new timeline point to the syncobj
>> + * @syncobj: sync object to add timeline point do
>> + * @chain: chain node to use to add the point
>> + * @fence: fence to encapsulate in the chain node
>> + * @point: sequence number to use for the point
>> + *
>> + * Add the chain node as new timeline point to the syncobj.
>> + */
>> +void drm_syncobj_add_point(struct drm_syncobj *syncobj,
>> + struct dma_fence_chain *chain,
>> + struct dma_fence *fence,
>> + uint64_t point)
>> +{
>> +struct syncobj_wait_entry *cur, *tmp;
>> +struct dma_fence *prev;
>> +
>> +dma_fence_get(fence);
>> +
>> +spin_lock(>lock);
>> +
>> +prev = rcu_dereference_protected(syncobj->fence,
>> + lockdep_is_held(>lock));
>> +dma_fence_chain_init(chain, prev, fence, point);
>> +rcu_assign_pointer(syncobj->fence, >base);
>> +
>> +list_for_each_entry_safe(cur, tmp, >cb_list, node) {
>> +list_del_init(>node);
>> +syncobj_wait_syncobj_func(syncobj, cur);
>> +}
>> +spin_unlock(>lock);
>> +
>> +/* Walk the chain once to trigger garbage collection */
>> +dma_fence_chain_for_each(prev, fence);
>> +}
>>
Re: [Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()
On Mon, Dec 10, 2018 at 05:30:09PM +0100, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 05:20:10PM +0100, Michal Hocko wrote:
> > > OK, no real objections to the thing. Just so long we're all on the same
> > > page as to what it does and doesn't do ;-)
> >
> > I am not really sure whether there are other potential users besides
> > this one and whether the check as such is justified.
>
> It's a debug option...
>
> > > I suppose you could extend the check to include schedule_debug() as
> > > well, maybe something like:
> >
> > Do you mean to make the check cheaper?
>
> Nah, so the patch only touched might_sleep(), the below touches
> schedule().
>
> If there were a patch that hits schedule() without going through a
> might_sleep() (rare in practise I think, but entirely possible) then you
> won't get a splat without something like the below on top.
We have a bunch of schedule() calls in i915, for e.g. waiting for multiple
events at the same time (when we want to unblock if any of them fire). And
there's no might_sleep in these cases afaict. Adding the check in
schedule() sounds useful, I'll include your snippet in v2. Plus try a bit
better to explain in the commit message why Michal suggested these.
Thanks, Daniel
>
> > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > > index f66920173370..b1aaa278f1af 100644
> > > --- a/kernel/sched/core.c
> > > +++ b/kernel/sched/core.c
> > > @@ -3278,13 +3278,18 @@ static noinline void __schedule_bug(struct
> > > task_struct *prev)
> > > /*
> > > * Various schedule()-time debugging checks and statistics:
> > > */
> > > -static inline void schedule_debug(struct task_struct *prev)
> > > +static inline void schedule_debug(struct task_struct *prev, bool preempt)
> > > {
> > > #ifdef CONFIG_SCHED_STACK_END_CHECK
> > > if (task_stack_end_corrupted(prev))
> > > panic("corrupted stack end detected inside scheduler\n");
> > > #endif
> > >
> > > +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
> > > + if (!preempt && prev->state && prev->non_block_count)
> > > + // splat
> > > +#endif
> > > +
> > > if (unlikely(in_atomic_preempt_off())) {
> > > __schedule_bug(prev);
> > > preempt_count_set(PREEMPT_DISABLED);
> > > @@ -3391,7 +3396,7 @@ static void __sched notrace __schedule(bool preempt)
> > > rq = cpu_rq(cpu);
> > > prev = rq->curr;
> > >
> > > - schedule_debug(prev);
> > > + schedule_debug(prev, preempt);
> > >
> > > if (sched_feat(HRTICK))
> > > hrtick_clear(rq);
> >
> > --
> > Michal Hocko
> > SUSE Labs
--
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
Re: [Intel-gfx] [PATCH 7/7] drm: Split out drm_probe_helper.h
On Mon, Dec 10, 2018 at 02:40:25PM +0100, Benjamin Gaignard wrote: > Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard > a écrit : > > > > Le lun. 10 déc. 2018 à 11:24, Thierry Reding > > a écrit : > > > > > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > > > > Having the probe helper stuff (which pretty much everyone needs) in > > > > the drm_crtc_helper.h file (which atomic drivers should never need) is > > > > confusing. Split them out. > > > > > > > > To make sure I actually achieved the goal here I went through all > > > > drivers. And indeed, all atomic drivers are now free of > > > > drm_crtc_helper.h includes. > > > > > > > > I have difficulties to apply this with git on top of drm-misc-next. > > It is because of that I got errors (encoder and connector types not > > found) while compiling adv7511_audio.c and exynos_dp.c ? > > > > Nack on this patch because it break compiling at least on sti driver. > drm_probe_helper.h doesn't bring the same includes than drm_crtc_helper.h: > #include > #include > #include > so some types, structures and functions proptotypes are missing while > compiling. Hm, I thought I've compile-tested all the arm stuff, I guess I've failed. Will respin, sorry for the confusion. -Daniel > > > > Benjamin > > > > Signed-off-by: Daniel Vetter > > > > Cc: linux-arm-ker...@lists.infradead.org > > > > Cc: virtualizat...@lists.linux-foundation.org > > > > Cc: etna...@lists.freedesktop.org > > > > Cc: linux-samsung-...@vger.kernel.org > > > > Cc: intel-gfx@lists.freedesktop.org > > > > Cc: linux-media...@lists.infradead.org > > > > Cc: linux-amlo...@lists.infradead.org > > > > Cc: linux-arm-...@vger.kernel.org > > > > Cc: freedr...@lists.freedesktop.org > > > > Cc: nouv...@lists.freedesktop.org > > > > Cc: spice-de...@lists.freedesktop.org > > > > Cc: amd-...@lists.freedesktop.org > > > > Cc: linux-renesas-...@vger.kernel.org > > > > Cc: linux-rockc...@lists.infradead.org > > > > Cc: linux-st...@st-md-mailman.stormreply.com > > > > Cc: linux-te...@vger.kernel.org > > > > Cc: xen-de...@lists.xen.org > > > > --- > > > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > > > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > > > > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > > > > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > > > > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > > > > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > > > > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > > > > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > > > > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > > > > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > > > > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > > > > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > > > > drivers/gpu/drm/armada/armada_510.c | 2 +- > > > > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > > > > drivers/gpu/drm/armada/armada_drv.c | 2 +- > > > > drivers/gpu/drm/armada/armada_fb.c| 2 +- > > > > drivers/gpu/drm/ast/ast_drv.c | 1 + > > > > drivers/gpu/drm/ast/ast_mode.c| 1 + > > > > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > > > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > > > > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > > > > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > > > > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- > > > > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- > > > > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > > > > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > > > > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > > > > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > > > > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > > > > drivers/gpu/drm/bridge/panel.c| 2 +- > > > > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > > > > drivers/gpu/drm/bridge/sii902x.c | 2 +- > > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > > > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > > > > drivers/gpu/drm/bridge/tc358764.c | 2 +- > > > > drivers/gpu/drm/bridge/tc358767.c | 2 +- > > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > > > > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > > > > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > > > > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > > > > drivers/gpu/drm/drm_atomic_helper.c | 1 - > > > > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > > > > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > > > >
Re: [Intel-gfx] [PATCH v8 05/35] drm/i915: MEI interface definition
On 12/12/2018 4:08 PM, Daniel Vetter wrote:
On Wed, Dec 12, 2018 at 02:28:29PM +0530, C, Ramalingam wrote:
On 12/7/2018 7:59 PM, Daniel Vetter wrote:
On Fri, Dec 07, 2018 at 11:22:44AM +0530, C, Ramalingam wrote:
On 12/6/2018 3:53 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:
+static void i915_hdcp_component_master_unbind(struct device *dev)
+{
+ struct drm_i915_private *dev_priv = kdev_to_i915(dev);
+
+ intel_connectors_hdcp_disable(dev_priv);
Why this code? Once we've unregistered the driver, we should have shut
down the hardware completely. Which should have shut down all the hdcp
users too.
This unbind might be triggered either due to master_del or component_del.
if its triggered from mei through component_del, then before teardown of
the i/f in component_unbind(), disable the ongoing HDCP session through
hdcp_disable() for each connectors.
I looked at your v7 component code again. I think if we put the
drm_atomic_helper_shutdown() call into master_unbind, then we'll have taken care
of that. Essentially what you're doing here is open-coding part of that
function. Better to just move the existing call to the right place.
And shutting down the entire hw is kinda what master_unbind should be
doing I think. We might also need to move the general hw quiescent into
master_unbind, that should work too.
Need some more information on this. As per v7 on master_unbind will invoke
i915_unload_head that is i915_driver_unregister(dev_priv);
Similarly master_bind will call the load_tail that is
i915_driver_register(dev_priv);
We are not initializing/shutting the HW in master_bind/unbind .
But this comment is contradicting with current approach. Could you please
elaborate.?
So my understanding is that we need to shut down all hdcp usage before
master_unbind completes, because otherwise we'll blow up: The mei_hdcp
component is gone already.
Now the other case for master_unbind is that the i915 pci device is
unloaded, and in that case again I think it makes sense to shut down the
hardware in master_unbind.
Now when I looked at v7, right after the component_unbind code in the i915
unload sequences comes the function calls to shut down the hardware. I
think it would make sense to them (or at least the
drm_atomic_helper_shutdown() call) into master_unbind.
This is somewhat asymetric, but that's ok: Load path doesn't enable
anything, we just keep the hardware as-is (to be able to support
flicker-free boôt-up). First modest is done by usersapce. Exception is if
you have fbcon enabled (and not use the fastboot patches that Hans just
merged), in that case the kernel will do the first modeset when we
regiseter the fbdev device.
Anyway, moving the drm_atomic_helper_shutdown() into the master_unbind
function in v7 should take care of disabling all outputs, and hence also
disabling all usage of hdcp component.
But in that case master_bind should do the reverse of the
drm_atomic_helper_shutdown()right?
else lets say mei_hdcp is removed, master_unbind triggered and hence all hw is
shutdown.
And then mei_hdcp is loaded so master_bind should initialize the hw right?
Which is not the scenario right now.
-Ram
-Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new drm_syncobj_add_point interface v2
On Wed, Dec 12, 2018 at 12:08 PM Koenig, Christian wrote: > > Am 12.12.18 um 11:49 schrieb Daniel Vetter: > > On Fri, Dec 07, 2018 at 11:54:15PM +0800, Chunming Zhou wrote: > >> From: Christian König > >> > >> Use the dma_fence_chain object to create a timeline of fence objects > >> instead of just replacing the existing fence. > >> > >> v2: rebase and cleanup > >> > >> Signed-off-by: Christian König > > Somewhat jumping back into this. Not sure we discussed this already or > > not. I'm a bit unclear on why we have to chain the fences in the timeline: > > > > - The timeline stuff is modelled after the WDDM2 monitored fences. Which > >really are just u64 counters in memory somewhere (I think could be > >system ram or vram). Because WDDM2 has the memory management entirely > >separated from rendering synchronization it totally allows userspace to > >create loops and deadlocks and everything else nasty using this - the > >memory manager won't deadlock because these monitored fences never leak > >into the buffer manager. And if CS deadlock, gpu reset takes care of the > >mess. > > > > - This has a few consequences, as in they seem to indeed work like a > >memory location: Userspace incrementing out-of-order (because they run > >batches updating the same fence on different engines) is totally fine, > >as is doing anything else "stupid". > > > > - Now on linux we can't allow anything, because we need to make sure that > >deadlocks don't leak into the memory manager. But as long as we block > >until the underlying dma_fence has materialized, nothing userspace can > >do will lead to such a deadlock. Even if userspace ends up submitting > >jobs without enough built-in synchronization, leading to out-of-order > >signalling of fences on that "timeline". And I don't think that would > >pose a problem for us. > > > > Essentially I think we can look at timeline syncobj as a dma_fence > > container indexed through an integer, and there's no need to enforce that > > the timline works like a real dma_fence timeline, with all it's > > guarantees. It's just a pile of (possibly, if userspace is stupid) > > unrelated dma_fences. You could implement the entire thing in userspace > > after all, except for the "we want to share these timeline objects between > > processes" problem. > > > > tldr; I think we can drop the dma_fence_chain complexity completely. Or at > > least I'm not really understanding why it's needed. > > > > Of course that means drivers cannot treat a drm_syncobj timeline as a > > dma_fence timeline. But given the future fences stuff and all that, that's > > already out of the window anyway. > > > > What am I missing? > > Good question, since that was exactly my initial idea as well. > > Key point is that our Vulcan guys came back and said that this wouldn't > be sufficient, but I honestly don't fully understand why. Hm, sounds like we really need those testscases (vk cts on top of mesa, igt) so we can talk about the exact corner cases we care about and why. I guess one thing that might happen is that userspace leaves out a number and never sets that fence, relying on the >= semantics of the monitored fence to unblock that thread. E.g. when skipping a frame in one of the auxiliary workloads. For that case we'd need to make sure we don't just wait for the given fence to materialize, but also any fences later in the timeline. But we can't decide that without understanding the actual use-case that needs to be supported at the other end of the stack, and how all the bits in between should look like. I guess we're back to "uapi design without userspace doesn't make sense" ... > Anyway that's why David came up with using the fence array to wait for > all previously added fences, which I then later on extended into this > chain container. > > I have to admit that it is way more defensive implemented this way. E.g. > there is much fewer things userspace can do wrong. > > The principal idea is that when they mess things up they are always > going to wait more than necessary, but never less. That seems against the spirit of vulkan, which is very much about "you get all the pieces". It also might dig us a hole in the future, if we ever get around to moving towards a WDDM2 style memory management model. For future proving I think it would make sense if we implement the minimal uapi we need for vk timelines, not the strictest guarantees we can get away with (without performance impact) with current drivers. -Daniel > Christian. > > > -Daniel > > > >> --- > >> drivers/gpu/drm/drm_syncobj.c | 37 +++ > >> include/drm/drm_syncobj.h | 5 + > >> 2 files changed, 42 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c > >> index e19525af0cce..51f798e2194f 100644 > >> --- a/drivers/gpu/drm/drm_syncobj.c > >> +++ b/drivers/gpu/drm/drm_syncobj.c > >> @@ -122,6 +122,43
[Intel-gfx] [drm-intel:for-linux-next-fixes 5/5] drivers/gpu//drm/i915/intel_ringbuffer.c:89:11: error: implicit declaration of function 'i915_scratch_offset'; did you mean 'i915_ggtt_offset'?
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
head: eeb139ca4b24d515265ad75f668333431896b1aa
commit: eeb139ca4b24d515265ad75f668333431896b1aa [5/5] drm/i915: Flush GPU
relocs harder for gen3
config: i386-randconfig-x073-201849 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout eeb139ca4b24d515265ad75f668333431896b1aa
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpu//drm/i915/intel_ringbuffer.c: In function
'gen2_render_ring_flush':
>> drivers/gpu//drm/i915/intel_ringbuffer.c:89:11: error: implicit declaration
>> of function 'i915_scratch_offset'; did you mean 'i915_ggtt_offset'?
>> [-Werror=implicit-function-declaration]
*cs++ = i915_scratch_offset(rq->i915);
^~~
i915_ggtt_offset
cc1: some warnings being treated as errors
vim +89 drivers/gpu//drm/i915/intel_ringbuffer.c
68
69 static int
70 gen2_render_ring_flush(struct i915_request *rq, u32 mode)
71 {
72 unsigned int num_store_dw;
73 u32 cmd, *cs;
74
75 cmd = MI_FLUSH;
76 num_store_dw = 0;
77 if (mode & EMIT_INVALIDATE)
78 cmd |= MI_READ_FLUSH;
79 if (mode & EMIT_FLUSH)
80 num_store_dw = 4;
81
82 cs = intel_ring_begin(rq, 2 + 3 * num_store_dw);
83 if (IS_ERR(cs))
84 return PTR_ERR(cs);
85
86 *cs++ = cmd;
87 while (num_store_dw--) {
88 *cs++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
> 89 *cs++ = i915_scratch_offset(rq->i915);
90 *cs++ = 0;
91 }
92 *cs++ = MI_FLUSH | MI_NO_WRITE_FLUSH;
93
94 intel_ring_advance(rq, cs);
95
96 return 0;
97 }
98
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Validate userspace-provided color management LUT's
Hi Matt,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.20-rc6 next-20181211]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/drm-Add-color-management-LUT-validation-helpers/20181212-130519
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x011-201849 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/intel_color.c: In function 'intel_color_check':
>> drivers/gpu/drm/i915/intel_color.c:632:51: error: 'struct drm_crtc_state'
>> has no member named 'base'
if (!drm_color_lut_has_equal_channels(crtc_state->base.degamma_lut)) {
^~
drivers/gpu/drm/i915/intel_color.c:639:45: error: 'struct drm_crtc_state'
has no member named 'base'
if (!drm_color_lut_is_increasing(crtc_state->base.degamma_lut)) {
^~
vim +632 drivers/gpu/drm/i915/intel_color.c
616
617 int intel_color_check(struct drm_crtc *crtc,
618struct drm_crtc_state *crtc_state)
619 {
620 struct drm_i915_private *dev_priv = to_i915(crtc->dev);
621 size_t gamma_length, degamma_length;
622
623 degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
624 gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
625
626 /*
627 * GLK and gen11 only accept a single value for red, green, and
628 * blue in the degamma table. Make sure userspace didn't try to
629 * pass us something we can't handle.
630 */
631 if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11) {
> 632 if
> (!drm_color_lut_has_equal_channels(crtc_state->base.degamma_lut)) {
633 DRM_DEBUG_KMS("All degamma entries must have
equal r/g/b\n");
634 return -EINVAL;
635 }
636 }
637
638 /* All platforms require that the degamma curve be
non-decreasing */
639 if (!drm_color_lut_is_increasing(crtc_state->base.degamma_lut))
{
640 DRM_DEBUG_KMS("Degamma curve must never decrease.\n");
641 return -EINVAL;
642 }
643
644 /*
645 * We allow both degamma & gamma luts at the right size or
646 * NULL.
647 */
648 if ((!crtc_state->degamma_lut ||
649 drm_color_lut_size(crtc_state->degamma_lut) ==
degamma_length) &&
650 (!crtc_state->gamma_lut ||
651 drm_color_lut_size(crtc_state->gamma_lut) == gamma_length))
652 return 0;
653
654 /*
655 * We also allow no degamma lut/ctm and a gamma lut at the
legacy
656 * size (256 entries).
657 */
658 if (crtc_state_is_legacy_gamma(crtc_state))
659 return 0;
660
661 return -EINVAL;
662 }
663
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 05/35] drm/i915: MEI interface definition
On 12/7/2018 7:59 PM, Daniel Vetter wrote:
On Fri, Dec 07, 2018 at 11:22:44AM +0530, C, Ramalingam wrote:
On 12/6/2018 3:53 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:03PM +0530, Ramalingam C wrote:
Defining the mei-i915 interface functions and initialization of
the interface.
Signed-off-by: Ramalingam C
Signed-off-by: Tomas Winkler
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_drv.h | 7 +
drivers/gpu/drm/i915/intel_hdcp.c | 442
+-
include/drm/i915_component.h | 71 ++
4 files changed, 521 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f763b30f98d9..b68bc980b7cd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2015,6 +2015,8 @@ struct drm_i915_private {
struct i915_pmu pmu;
+ struct i915_hdcp_component_master *hdcp_comp;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 85a526598096..bde82f3ada85 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
@@ -379,6 +380,9 @@ 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);
+
+ /* Detects the HDCP protocol(DP/HDMI) required on the port */
+ enum mei_hdcp_wired_protocol (*hdcp_protocol)(void);
Looking ahead, this seems hardwired to constant return value? Or why do we
need a function here?
This is hardwired based on the connector type(DP/HDMI).
Since we have the shim for hdcp's connector based work, I have added this
function.
Could have done this just with connector_type check, but in that way whole
hdcp_shim
can be done in that way. So going with the larger design here.
If it's hardwired then just make it a hardwired struct member. As long as
it's all const, we can mix data an function pointers. If you have runtime
variable data, then it's better to split it out from the ops structure, so
that we can keep ops read-only and protected against possible exploits
(any function pointers are a high-value target in the kernel).
Sure. Done.
};
struct intel_hdcp {
@@ -399,6 +403,9 @@ struct intel_hdcp {
* content can flow only through a link protected by HDCP2.2.
*/
u8 content_type;
+
+ /* mei interface related information */
+ struct mei_hdcp_data mei_data;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 99dddb540958..760780f1105c 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -8,14 +8,20 @@
#include
#include
+#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
#define KEY_LOAD_TRIES 5
#define TIME_FOR_ENCRYPT_STATUS_CHANGE 50
+#define GET_MEI_DDI_INDEX(p) ({\
+ typeof(p) __p = (p); \
+ __p == PORT_A ? MEI_DDI_A : (enum mei_hdcp_ddi)__p;\
+})
static
bool intel_hdcp_is_ksv_valid(u8 *ksv)
@@ -833,6 +839,417 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
!IS_CHERRYVIEW(dev_priv) && port < PORT_E);
}
+static __attribute__((unused)) int
+hdcp2_prepare_ake_init(struct intel_connector *connector,
+ struct hdcp2_ake_init *ake_data)
+{
+ struct mei_hdcp_data *data = >hdcp.mei_data;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct i915_hdcp_component_master *comp = dev_priv->hdcp_comp;
+ int ret;
+
+ if (!comp)
+ return -EINVAL;
+
+ mutex_lock(>mutex);
+ if (!comp->ops || !comp->dev) {
+ mutex_unlock(>mutex);
+ return -EINVAL;
+ }
+
+ if (data->port == MEI_DDI_INVALID_PORT && connector->encoder)
+ data->port = GET_MEI_DDI_INDEX(connector->encoder->port);
+
+ /* Clear ME FW instance for the port, just incase */
+ comp->ops->close_hdcp_session(comp->dev, data);
Sounds like a bug somewhere if we need this? I'd put this code into the
->initiate_hdcp2_session, with a big WARN_ON if it's actually needed.
Not really. Lets say you have progressed beyond the first step of HDCP2.2 auth
along with ME FW.
Now if authentication failed due to some reason, then the HDCP2.2 season
created with
ME FW for that port is not closed yet.
So we need to call close_hdcp_session() explicitly on authentication failures.
Session has
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Validate userspace-provided color management LUT's
Hi Matt,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.20-rc6 next-20181211]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/drm-Add-color-management-LUT-validation-helpers/20181212-130519
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x006-201849 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/async.h:16,
from drivers/gpu//drm/i915/intel_drv.h:28,
from drivers/gpu//drm/i915/intel_color.c:25:
drivers/gpu//drm/i915/intel_color.c: In function 'intel_color_check':
drivers/gpu//drm/i915/intel_color.c:632:51: error: 'struct drm_crtc_state'
has no member named 'base'
if (!drm_color_lut_has_equal_channels(crtc_state->base.degamma_lut)) {
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu//drm/i915/intel_color.c:632:3: note: in expansion of macro 'if'
if (!drm_color_lut_has_equal_channels(crtc_state->base.degamma_lut)) {
^~
drivers/gpu//drm/i915/intel_color.c:632:51: error: 'struct drm_crtc_state'
has no member named 'base'
if (!drm_color_lut_has_equal_channels(crtc_state->base.degamma_lut)) {
^
include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu//drm/i915/intel_color.c:632:3: note: in expansion of macro 'if'
if (!drm_color_lut_has_equal_channels(crtc_state->base.degamma_lut)) {
^~
drivers/gpu//drm/i915/intel_color.c:632:51: error: 'struct drm_crtc_state'
has no member named 'base'
if (!drm_color_lut_has_equal_channels(crtc_state->base.degamma_lut)) {
^
include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
__r = !!(cond); \
^~~~
>> drivers/gpu//drm/i915/intel_color.c:632:3: note: in expansion of macro 'if'
if (!drm_color_lut_has_equal_channels(crtc_state->base.degamma_lut)) {
^~
drivers/gpu//drm/i915/intel_color.c:639:45: error: 'struct drm_crtc_state'
has no member named 'base'
if (!drm_color_lut_is_increasing(crtc_state->base.degamma_lut)) {
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
drivers/gpu//drm/i915/intel_color.c:639:2: note: in expansion of macro 'if'
if (!drm_color_lut_is_increasing(crtc_state->base.degamma_lut)) {
^~
drivers/gpu//drm/i915/intel_color.c:639:45: error: 'struct drm_crtc_state'
has no member named 'base'
if (!drm_color_lut_is_increasing(crtc_state->base.degamma_lut)) {
^
include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
drivers/gpu//drm/i915/intel_color.c:639:2: note: in expansion of macro 'if'
if (!drm_color_lut_is_increasing(crtc_state->base.degamma_lut)) {
^~
drivers/gpu//drm/i915/intel_color.c:639:45: error: 'struct drm_crtc_state'
has no member named 'base'
if (!drm_color_lut_is_increasing(crtc_state->base.degamma_lut)) {
^
include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
__r = !!(cond); \
^~~~
drivers/gpu//drm/i915/intel_color.c:639:2: note: in expansion of macro 'if'
if (!drm_color_lut_is_increasing(crtc_state->base.degamma_lut)) {
^~
vim +/if +632 drivers/gpu//drm/i915/intel_color.c
616
617 int intel_color_check(struct drm_crtc *crtc,
618struct drm_crtc_state *crtc_state)
619 {
620 struct drm_i915_private *dev_priv = to_i915(crtc->dev);
621 size_t gamma_length, degamma_length;
622
623 degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
624 gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
625
626 /*
627
Re: [Intel-gfx] [PATCH v8 08/35] drm/i915: Implement HDCP2.2 repeater authentication
On 12/6/2018 4:15 PM, Daniel Vetter wrote:
On Tue, Nov 27, 2018 at 04:13:06PM +0530, Ramalingam C wrote:
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.
v2:
Rebased.
v3:
No Changes.
v4:
-EINVAL is returned for topology error and rollover scenario.
Endianness conversion func from drm_hdcp.h is used [Uma]
v5:
Rebased as part of patches reordering.
Defined the mei service functions [Daniel]
v6:
Redefined the mei service functions as per comp redesign.
v7:
%s/uintxx_t/uxx
Check for comp_master is removed.
v8:
Adjust to the new mei interface.
style issue fixed.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 125 +-
include/drm/drm_hdcp.h| 15 +
2 files changed, 138 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 0d7fea9c9bb1..679f3c164582 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1069,7 +1069,7 @@ static int hdcp2_prepare_skey(struct intel_connector
*connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_rep_topology_prepare_ack(struct intel_connector *connector,
struct hdcp2_rep_send_receiverid_list
*rep_topology,
@@ -1099,7 +1099,7 @@ hdcp2_verify_rep_topology_prepare_ack(struct
intel_connector *connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_mprime(struct intel_connector *connector,
struct hdcp2_rep_stream_ready *stream_ready)
{
@@ -1315,6 +1315,121 @@ static int hdcp2_session_key_exchange(struct
intel_connector *connector)
return 0;
}
+static
+int hdcp2_propagate_stream_management_info(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ union {
+ struct hdcp2_rep_stream_manage stream_manage;
+ struct hdcp2_rep_stream_ready stream_ready;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
+ int ret;
+
+ /* Prepare RepeaterAuth_Stream_Manage msg */
+ msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
+ reverse_endianness(msgs.stream_manage.seq_num_m, HDCP_2_2_SEQ_NUM_LEN,
+ (u8 *)>seq_num_m);
+
+ /* K no of streams is fixed as 1. Stored as big-endian. */
+ msgs.stream_manage.k = __swab16(1);
+
+ /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
+ msgs.stream_manage.streams[0].stream_id = 0;
+ msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
+
+ /* Send it to Repeater */
+ ret = shim->write_2_2_msg(intel_dig_port, _manage,
+ sizeof(msgs.stream_manage));
+ if (ret < 0)
+ return ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_STREAM_READY,
+_ready, sizeof(msgs.stream_ready));
+ if (ret < 0)
+ return ret;
+
+ hdcp->mei_data.seq_num_m = hdcp->seq_num_m;
+ hdcp->mei_data.streams[0].stream_type = hdcp->content_type;
+
+ ret = hdcp2_verify_mprime(connector, _ready);
+ if (ret < 0)
+ return ret;
+
+ hdcp->seq_num_m++;
+
+ if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
+ DRM_DEBUG_KMS("seq_num_m roll over.\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+static
+int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ union {
+ struct hdcp2_rep_send_receiverid_list recvid_list;
+ struct hdcp2_rep_send_ack rep_ack;
+ } msgs;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
+ u8 *rx_info;
+ u32 seq_num_v;
+ int ret;
+
+ ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_SEND_RECVID_LIST,
+_list, sizeof(msgs.recvid_list));
+ if (ret < 0)
+ return ret;
+
+ rx_info = msgs.recvid_list.rx_info;
+
+ if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
+ HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
+ DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
+ return -EINVAL;
+ }
+
+ /* Converting and Storing the seq_num_v to local variable as DWORD */
+ reverse_endianness((u8 *)_num_v, HDCP_2_2_SEQ_NUM_LEN,
+ msgs.recvid_list.seq_num_v);
+
+ if (seq_num_v < hdcp->seq_num_v) {
+ /* Roll over of the seq_num_v from
Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new drm_syncobj_add_point interface v2
+ Daniel Rakos and Jason Ekstrand. Below is the background, which is from Daniel R should be able to explain that's why: " ISVs, especially those coming from D3D12, are unsatisfied with the behavior of the Vulkan semaphores as they are unhappy with the fact that for every single dependency they need to use separate semaphores due to their binary nature. Compared to that a synchronization primitive like D3D12 monitored fences enable one of those to be used to track a sequence of operations by simply associating timeline values to the completion of individual operations. This allows them to track the lifetime and usage of resources and the ordered completion of sequences. Besides that, they also want to use a single synchronization primitive to be able to handle GPU-to-GPU and GPU-to-CPU dependencies, compared to using semaphores for the former and fences for the latter. In addition, compared to legacy semaphores, timeline semaphores are proposed to support wait-before-signal, i.e. allow enqueueing a semaphore wait operation with a wait value that is larger than any of the already enqueued signal values. This seems to be a hard requirement for ISVs. Without UMD-side queue batching, and even UMD-side queue batching doesn’t help the situation when such a semaphore is externally shared with another API. Thus in order to properly support wait-before-signal the KMD implementation has to also be able to support such dependencies. " Btw, we already add test case to igt, and tested by many existing test, like libdrm unit test, igt related test, vulkan cts, and steam games. -David > -Original Message- > From: Daniel Vetter > Sent: Wednesday, December 12, 2018 7:15 PM > To: Koenig, Christian > Cc: Zhou, David(ChunMing) ; dri-devel de...@lists.freedesktop.org>; amd-gfx list ; > intel-gfx ; Christian König > > Subject: Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new > drm_syncobj_add_point interface v2 > > On Wed, Dec 12, 2018 at 12:08 PM Koenig, Christian > wrote: > > > > Am 12.12.18 um 11:49 schrieb Daniel Vetter: > > > On Fri, Dec 07, 2018 at 11:54:15PM +0800, Chunming Zhou wrote: > > >> From: Christian König > > >> > > >> Use the dma_fence_chain object to create a timeline of fence > > >> objects instead of just replacing the existing fence. > > >> > > >> v2: rebase and cleanup > > >> > > >> Signed-off-by: Christian König > > > Somewhat jumping back into this. Not sure we discussed this already > > > or not. I'm a bit unclear on why we have to chain the fences in the > timeline: > > > > > > - The timeline stuff is modelled after the WDDM2 monitored fences. > Which > > >really are just u64 counters in memory somewhere (I think could be > > >system ram or vram). Because WDDM2 has the memory management > entirely > > >separated from rendering synchronization it totally allows userspace to > > >create loops and deadlocks and everything else nasty using this - the > > >memory manager won't deadlock because these monitored fences > never leak > > >into the buffer manager. And if CS deadlock, gpu reset takes care of > > > the > > >mess. > > > > > > - This has a few consequences, as in they seem to indeed work like a > > >memory location: Userspace incrementing out-of-order (because they > run > > >batches updating the same fence on different engines) is totally fine, > > >as is doing anything else "stupid". > > > > > > - Now on linux we can't allow anything, because we need to make sure > that > > >deadlocks don't leak into the memory manager. But as long as we block > > >until the underlying dma_fence has materialized, nothing userspace can > > >do will lead to such a deadlock. Even if userspace ends up submitting > > >jobs without enough built-in synchronization, leading to out-of-order > > >signalling of fences on that "timeline". And I don't think that would > > >pose a problem for us. > > > > > > Essentially I think we can look at timeline syncobj as a dma_fence > > > container indexed through an integer, and there's no need to enforce > > > that the timline works like a real dma_fence timeline, with all it's > > > guarantees. It's just a pile of (possibly, if userspace is stupid) > > > unrelated dma_fences. You could implement the entire thing in > > > userspace after all, except for the "we want to share these timeline > > > objects between processes" problem. > > > > > > tldr; I think we can drop the dma_fence_chain complexity completely. > > > Or at least I'm not really understanding why it's needed. > > > > > > Of course that means drivers cannot treat a drm_syncobj timeline as > > > a dma_fence timeline. But given the future fences stuff and all > > > that, that's already out of the window anyway. > > > > > > What am I missing? > > > > Good question, since that was exactly my initial idea as well. > > > > Key point is that our Vulcan guys came back and said that this > > wouldn't be sufficient, but I
Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new drm_syncobj_add_point interface v2
On Wed, Dec 12, 2018 at 1:00 PM Koenig, Christian wrote: > > > Key point is that our Vulcan guys came back and said that this > > wouldn't be sufficient, but I honestly don't fully understand why. > > Hm, sounds like we really need those testscases (vk cts on top of mesa, igt) > > so we can talk about the exact corner cases we care about and why. > Yes, that's why I made it mandatory that David provides an igt test case > along the ones in libdrm. > > > I guess one thing that might happen is that userspace leaves out a number > > and never sets that fence, relying on the >= semantics of the monitored > > fence to unblock that thread. E.g. when skipping a frame in one of the > > auxiliary workloads. For that case we'd need to make sure we don't just wait > > for the given fence to materialize, but also any fences later in the > > timeline. > Correct and that's also how we have implemented it. > > > But we can't decide that without understanding the actual use-case that > > needs to be supported at the other end of the stack, and how all the bits in > > between should look like. > > > > I guess we're back to "uapi design without userspace doesn't make sense" ... > Yeah, well chicken and egg problem. Amdvlk probably won't make the code > to support this public until the kernel has accepted it and the kernel > doesn't accept it until the amdvlk patches are public. That's not how we do uapi development. > David can you take care of this and release the userspace patches as well? Please also drag the people typing the code on the mailing list, not just the code. Code alone doesn't make for a useful discussion :-) Also, someone needs to drag the radv/anv side into this, because I don't also want to mix up the technical issues here with the entire "is amdvlk good enough for uapi development" question ... (as is it seems to fall short on technicalities of simply not doing development openly, but I hope that's fixable). > Additional to that except for a bit polishing the UAPI stayed the same > from the very beginning while being reviewed multiple times now. So that > seems to be rather sane. > > > That seems against the spirit of vulkan, which is very much about "you get > > all > > the pieces". It also might dig us a hole in the future, if we ever get > > around to > > moving towards a WDDM2 style memory management model. For future > > proving I think it would make sense if we implement the minimal uapi we > > need for vk timelines, not the strictest guarantees we can get away with > > (without performance impact) with current drivers. > Well I'm repeating myself, but while this seems to be a good idea for an > userspace API it is not necessary for a kernel API. > > In other words userspace can do all the mess it wants in as long as it > stays inside the same process, but when it starts to mess with > inter-process communication (e.g. X or Wayland) the stuff should be > water prove and not allow for mess to leak between processes. > > And what we can always do is to make the restriction more lose, but > tightening it when userspace already depends on a behavior is not > possible any more. The point of vk timelines seems to be that userspace wants the mess, even across processes. E.g. for VR compositors, which run in some other address space. If you don't want to leak the mess, don't use vk timelines, use normal fences. Which is what all the X/wayland protocols seem to be doing. So the mess is strictly opt-in for userspace, but seems entirely desired. -Daniel > > Regards, > Christian. > > Am 12.12.18 um 12:39 schrieb Zhou, David(ChunMing): > > + Daniel Rakos and Jason Ekstrand. > > > > Below is the background, which is from Daniel R should be able to > > explain that's why: > > " ISVs, especially those coming from D3D12, are unsatisfied with the > > behavior of the Vulkan semaphores as they are unhappy with the fact that > > for every single dependency they need to use separate semaphores due to > > their binary nature. > > Compared to that a synchronization primitive like D3D12 monitored fences > > enable one of those to be used to track a sequence of operations by simply > > associating timeline values to the completion of individual operations. > > This allows them to track the lifetime and usage of resources and the > > ordered completion of sequences. > > Besides that, they also want to use a single synchronization primitive to > > be able to handle GPU-to-GPU and GPU-to-CPU dependencies, compared to using > > semaphores for the former and fences for the latter. > > In addition, compared to legacy semaphores, timeline semaphores are > > proposed to support wait-before-signal, i.e. allow enqueueing a semaphore > > wait operation with a wait value that is larger than any of the already > > enqueued signal values. This seems to be a hard requirement for ISVs. > > Without UMD-side queue batching, and even UMD-side queue batching doesn’t > > help the situation when such a semaphore is
Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new drm_syncobj_add_point interface v2
On Wed, Dec 12, 2018 at 12:40 PM Zhou, David(ChunMing) wrote: > > + Daniel Rakos and Jason Ekstrand. > > Below is the background, which is from Daniel R should be able to explain > that's why: > " ISVs, especially those coming from D3D12, are unsatisfied with the behavior > of the Vulkan semaphores as they are unhappy with the fact that for every > single dependency they need to use separate semaphores due to their binary > nature. > Compared to that a synchronization primitive like D3D12 monitored fences > enable one of those to be used to track a sequence of operations by simply > associating timeline values to the completion of individual operations. This > allows them to track the lifetime and usage of resources and the ordered > completion of sequences. > Besides that, they also want to use a single synchronization primitive to be > able to handle GPU-to-GPU and GPU-to-CPU dependencies, compared to using > semaphores for the former and fences for the latter. > In addition, compared to legacy semaphores, timeline semaphores are proposed > to support wait-before-signal, i.e. allow enqueueing a semaphore wait > operation with a wait value that is larger than any of the already enqueued > signal values. This seems to be a hard requirement for ISVs. Without UMD-side > queue batching, and even UMD-side queue batching doesn’t help the situation > when such a semaphore is externally shared with another API. Thus in order to > properly support wait-before-signal the KMD implementation has to also be > able to support such dependencies. > " I was tangetially involved in that wg too, I understand the overall use-case of vk timelines. I don't understand the exact corner case here, because I wasn't deeply involved in the details. -Daniel > Btw, we already add test case to igt, and tested by many existing test, like > libdrm unit test, igt related test, vulkan cts, and steam games. > > -David > > -Original Message- > > From: Daniel Vetter > > Sent: Wednesday, December 12, 2018 7:15 PM > > To: Koenig, Christian > > Cc: Zhou, David(ChunMing) ; dri-devel > de...@lists.freedesktop.org>; amd-gfx list ; > > intel-gfx ; Christian König > > > > Subject: Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new > > drm_syncobj_add_point interface v2 > > > > On Wed, Dec 12, 2018 at 12:08 PM Koenig, Christian > > wrote: > > > > > > Am 12.12.18 um 11:49 schrieb Daniel Vetter: > > > > On Fri, Dec 07, 2018 at 11:54:15PM +0800, Chunming Zhou wrote: > > > >> From: Christian König > > > >> > > > >> Use the dma_fence_chain object to create a timeline of fence > > > >> objects instead of just replacing the existing fence. > > > >> > > > >> v2: rebase and cleanup > > > >> > > > >> Signed-off-by: Christian König > > > > Somewhat jumping back into this. Not sure we discussed this already > > > > or not. I'm a bit unclear on why we have to chain the fences in the > > timeline: > > > > > > > > - The timeline stuff is modelled after the WDDM2 monitored fences. > > Which > > > >really are just u64 counters in memory somewhere (I think could be > > > >system ram or vram). Because WDDM2 has the memory management > > entirely > > > >separated from rendering synchronization it totally allows userspace > > > > to > > > >create loops and deadlocks and everything else nasty using this - the > > > >memory manager won't deadlock because these monitored fences > > never leak > > > >into the buffer manager. And if CS deadlock, gpu reset takes care of > > > > the > > > >mess. > > > > > > > > - This has a few consequences, as in they seem to indeed work like a > > > >memory location: Userspace incrementing out-of-order (because they > > run > > > >batches updating the same fence on different engines) is totally > > > > fine, > > > >as is doing anything else "stupid". > > > > > > > > - Now on linux we can't allow anything, because we need to make sure > > that > > > >deadlocks don't leak into the memory manager. But as long as we block > > > >until the underlying dma_fence has materialized, nothing userspace > > > > can > > > >do will lead to such a deadlock. Even if userspace ends up submitting > > > >jobs without enough built-in synchronization, leading to out-of-order > > > >signalling of fences on that "timeline". And I don't think that would > > > >pose a problem for us. > > > > > > > > Essentially I think we can look at timeline syncobj as a dma_fence > > > > container indexed through an integer, and there's no need to enforce > > > > that the timline works like a real dma_fence timeline, with all it's > > > > guarantees. It's just a pile of (possibly, if userspace is stupid) > > > > unrelated dma_fences. You could implement the entire thing in > > > > userspace after all, except for the "we want to share these timeline > > > > objects between processes" problem. > > > > > > > > tldr; I think we can drop the dma_fence_chain complexity completely. > >
[Intel-gfx] [PATCH] drm/amd: Compile fix for amdgpu_dm.c
Fix compilation issue with CONFIG_DRM_AMDGPU on:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
‘amdgpu_dm_mode_config_init’:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1666:30: error:
passing argument 1 of ‘drm_atomic_private_obj_init’ from incompatible pointer
type
Fixes: b962a12050a3 ("drm/atomic: integrate modeset lock with private objects")
Cc: Rob Clark
Cc: Boris Brezillon
Cc: Daniel Vetter
Cc: Tomi Sarvela
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1691864bf59b..fd3ed2ce9cb1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1663,7 +1663,8 @@ static int amdgpu_dm_mode_config_init(struct
amdgpu_device *adev)
dc_resource_state_copy_construct_current(adev->dm.dc, state->context);
- drm_atomic_private_obj_init(>dm.atomic_obj,
+ drm_atomic_private_obj_init(adev->ddev,
+ >dm.atomic_obj,
>base,
_atomic_state_funcs);
--
2.17.1
___
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/amd: Compile fix for amdgpu_dm.c
== Series Details == Series: drm/amd: Compile fix for amdgpu_dm.c URL : https://patchwork.freedesktop.org/series/53948/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.o drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function ‘amdgpu_dm_mode_config_init’: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1666:30: error: passing argument 1 of ‘drm_atomic_private_obj_init’ from incompatible pointer type [-Werror=incompatible-pointer-types] drm_atomic_private_obj_init(adev->ddev, ^~~~ In file included from ./include/drm/drm_dp_mst_helper.h:27:0, from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:46, from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:57, from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31: ./include/drm/drm_atomic.h:403:6: note: expected ‘struct drm_private_obj *’ but argument is of type ‘struct drm_device *’ void drm_atomic_private_obj_init(struct drm_private_obj *obj, ^~~ drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1667:9: error: passing argument 2 of ‘drm_atomic_private_obj_init’ from incompatible pointer type [-Werror=incompatible-pointer-types] >dm.atomic_obj, ^ In file included from ./include/drm/drm_dp_mst_helper.h:27:0, from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:46, from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:57, from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31: ./include/drm/drm_atomic.h:403:6: note: expected ‘struct drm_private_state *’ but argument is of type ‘struct drm_private_obj *’ void drm_atomic_private_obj_init(struct drm_private_obj *obj, ^~~ drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1668:9: error: passing argument 3 of ‘drm_atomic_private_obj_init’ from incompatible pointer type [-Werror=incompatible-pointer-types] >base, ^ In file included from ./include/drm/drm_dp_mst_helper.h:27:0, from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:46, from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:57, from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31: ./include/drm/drm_atomic.h:403:6: note: expected ‘const struct drm_private_state_funcs *’ but argument is of type ‘struct drm_private_state *’ void drm_atomic_private_obj_init(struct drm_private_obj *obj, ^~~ drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1666:2: error: too many arguments to function ‘drm_atomic_private_obj_init’ drm_atomic_private_obj_init(adev->ddev, ^~~ In file included from ./include/drm/drm_dp_mst_helper.h:27:0, from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:46, from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:57, from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31: ./include/drm/drm_atomic.h:403:6: note: declared here void drm_atomic_private_obj_init(struct drm_private_obj *obj, ^~~ cc1: some warnings being treated as errors scripts/Makefile.build:291: recipe for target 'drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.o' failed make[4]: *** [drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.o] Error 1 scripts/Makefile.build:516: recipe for target 'drivers/gpu/drm/amd/amdgpu' failed make[3]: *** [drivers/gpu/drm/amd/amdgpu] Error 2 scripts/Makefile.build:516: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:516: 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 03/10] drm/syncobj: add new drm_syncobj_add_point interface v2
> Key point is that our Vulcan guys came back and said that this > wouldn't be sufficient, but I honestly don't fully understand why. > Hm, sounds like we really need those testscases (vk cts on top of mesa, igt) > so we can talk about the exact corner cases we care about and why. Yes, that's why I made it mandatory that David provides an igt test case along the ones in libdrm. > I guess one thing that might happen is that userspace leaves out a number > and never sets that fence, relying on the >= semantics of the monitored > fence to unblock that thread. E.g. when skipping a frame in one of the > auxiliary workloads. For that case we'd need to make sure we don't just wait > for the given fence to materialize, but also any fences later in the timeline. Correct and that's also how we have implemented it. > But we can't decide that without understanding the actual use-case that > needs to be supported at the other end of the stack, and how all the bits in > between should look like. > > I guess we're back to "uapi design without userspace doesn't make sense" ... Yeah, well chicken and egg problem. Amdvlk probably won't make the code to support this public until the kernel has accepted it and the kernel doesn't accept it until the amdvlk patches are public. David can you take care of this and release the userspace patches as well? Additional to that except for a bit polishing the UAPI stayed the same from the very beginning while being reviewed multiple times now. So that seems to be rather sane. > That seems against the spirit of vulkan, which is very much about "you get all > the pieces". It also might dig us a hole in the future, if we ever get around > to > moving towards a WDDM2 style memory management model. For future > proving I think it would make sense if we implement the minimal uapi we > need for vk timelines, not the strictest guarantees we can get away with > (without performance impact) with current drivers. Well I'm repeating myself, but while this seems to be a good idea for an userspace API it is not necessary for a kernel API. In other words userspace can do all the mess it wants in as long as it stays inside the same process, but when it starts to mess with inter-process communication (e.g. X or Wayland) the stuff should be water prove and not allow for mess to leak between processes. And what we can always do is to make the restriction more lose, but tightening it when userspace already depends on a behavior is not possible any more. Regards, Christian. Am 12.12.18 um 12:39 schrieb Zhou, David(ChunMing): > + Daniel Rakos and Jason Ekstrand. > > Below is the background, which is from Daniel R should be able to explain > that's why: > " ISVs, especially those coming from D3D12, are unsatisfied with the behavior > of the Vulkan semaphores as they are unhappy with the fact that for every > single dependency they need to use separate semaphores due to their binary > nature. > Compared to that a synchronization primitive like D3D12 monitored fences > enable one of those to be used to track a sequence of operations by simply > associating timeline values to the completion of individual operations. This > allows them to track the lifetime and usage of resources and the ordered > completion of sequences. > Besides that, they also want to use a single synchronization primitive to be > able to handle GPU-to-GPU and GPU-to-CPU dependencies, compared to using > semaphores for the former and fences for the latter. > In addition, compared to legacy semaphores, timeline semaphores are proposed > to support wait-before-signal, i.e. allow enqueueing a semaphore wait > operation with a wait value that is larger than any of the already enqueued > signal values. This seems to be a hard requirement for ISVs. Without UMD-side > queue batching, and even UMD-side queue batching doesn’t help the situation > when such a semaphore is externally shared with another API. Thus in order to > properly support wait-before-signal the KMD implementation has to also be > able to support such dependencies. > " > > Btw, we already add test case to igt, and tested by many existing test, like > libdrm unit test, igt related test, vulkan cts, and steam games. > > -David >> -Original Message- >> From: Daniel Vetter >> Sent: Wednesday, December 12, 2018 7:15 PM >> To: Koenig, Christian >> Cc: Zhou, David(ChunMing) ; dri-devel > de...@lists.freedesktop.org>; amd-gfx list ; >> intel-gfx ; Christian König >> >> Subject: Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new >> drm_syncobj_add_point interface v2 >> >> On Wed, Dec 12, 2018 at 12:08 PM Koenig, Christian >> wrote: >>> Am 12.12.18 um 11:49 schrieb Daniel Vetter: On Fri, Dec 07, 2018 at 11:54:15PM +0800, Chunming Zhou wrote: > From: Christian König > > Use the dma_fence_chain object to create a timeline of fence > objects instead of just replacing the existing fence. > > v2: rebase and cleanup
Re: [Intel-gfx] [PATCH 3/5] drm/dp: Implement I2C_M_STOP for i2c-over-aux
On Wed, Dec 12, 2018 at 11:30:30AM +0100, Daniel Vetter wrote:
> On Mon, Dec 10, 2018 at 06:47:00PM -0800, Dhinakaran Pandiyan wrote:
> > On Fri, 2018-09-28 at 21:04 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Consult the I2C_M_STOP flag to determine whether to set the MOT bit
> > > or
> > > not. Makes it possible to send multiple messages in one go with
> > > stop+start generated between the messages (as opposed nothing or
> > > repstart depending on whether thr address/rw changed).
> > >
> > > Not sure anyone has actual use for this but figured I'd handle it
> > > since I started to look at that flag for MST remote i2c xfers.
> > >
> > Don't see the I2C_M_STOP flag anywhere in drm_edid.c, but the change
> > introduced here does make sense.
>
> Iirc it's the i2c core library which takes an entire transaction, splits
> it up, and sets the stop flag only on the very last one. Or something like
> that.
The last msg of the transfer has an implicit stop even without
the flag. The core won't add the flag for you. So the flag
is purely meant to force a stop+start between two messages
of the same transfer.
Well, it's not really specific anywhere IIRC but that's how
i2c-algo-bit behaves, and I tend to think of that one as the
defacto specification.
> -Daniel
>
> >
> > Reviewed-by: Dhinakaran Pandiyan
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/drm_dp_helper.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 37c01b6076ec..e85cea299d2a 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -884,7 +884,8 @@ static void drm_dp_i2c_msg_set_request(struct
> > > drm_dp_aux_msg *msg,
> > > {
> > > msg->request = (i2c_msg->flags & I2C_M_RD) ?
> > > DP_AUX_I2C_READ : DP_AUX_I2C_WRITE;
> > > - msg->request |= DP_AUX_I2C_MOT;
> > > + if (!(i2c_msg->flags & I2C_M_STOP))
> > > + msg->request |= DP_AUX_I2C_MOT;
> > > }
> > >
> > > /*
> >
> > ___
> > 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
--
Ville Syrjälä
Intel
___
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 [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim
== Series Details ==
Series: series starting with [01/19] drm/i915: Return immediately if trylock
fails for direct-reclaim
URL : https://patchwork.freedesktop.org/series/53953/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
916a3be212e3 drm/i915: Return immediately if trylock fails for direct-reclaim
26917cf8d163 drm/i915/userptr: Avoid struct_mutex recursion for
mmu_invalidate_range_start
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#23:
References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers")
-:23: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 93065ac753e4 ("mm, oom:
distinguish blockable mode for mmu notifiers")'
#23:
References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers")
-:240: ERROR:LOCKING: recursive locking is bad, do not use this ever.
#240: FILE: drivers/gpu/drm/i915/i915_gem_userptr.c:108:
+ switch (mutex_trylock_recursive(m)) {
total: 2 errors, 1 warnings, 0 checks, 444 lines checked
c19a3aa46c49 drm/i915/userptr: Probe vma range before gup
bde35602ca66 drm/i915/selftests: Check we can recover a wedged device
10e12b27ed33 drm/i915/selftests: Verify we can perform resets from atomic
context
ce3fa3096959 drm/i915/icl: Record the valid VDBoxes with SFC capability
b5cc02d7c587 drm/i915/icl: Mind the SFC units when resetting VD or VEBox engines
6db7a50be19a drm/i915: Always try to reset the GPU on takeover
654c916de1ce drm/i915: Report the number of closed vma held by each context in
debugfs
-:61: WARNING:LONG_LINE: line over 100 characters
#61: FILE: drivers/gpu/drm/i915/i915_debugfs.c:348:
+ seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
inactive, %llu global, %llu shared, %llu unbound, %llu closed)\n", \
total: 0 errors, 1 warnings, 0 checks, 201 lines checked
0e7e9b9d070d drm/i915: Remove debugfs/i915_ppgtt_info
12f7cb4ec2ad drm/i915: Track all held rpm wakerefs
-:105: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#105: FILE: drivers/gpu/drm/i915/i915_drv.h:1160:
+ spinlock_t debug_lock;
total: 0 errors, 0 warnings, 1 checks, 571 lines checked
c4143336103e drm/i915: Markup paired operations on wakerefs
-:783: WARNING:NEW_TYPEDEFS: do not add new typedefs
#783: FILE: drivers/gpu/drm/i915/i915_drv.h:134:
+typedef depot_stack_handle_t intel_wakeref_t;
total: 0 errors, 1 warnings, 0 checks, 2533 lines checked
b72c3febcaf2 drm/i915: Syntatic sugar for using intel_runtime_pm
-:509: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible
side-effects?
#509: FILE: drivers/gpu/drm/i915/intel_drv.h:2181:
+#define with_intel_runtime_pm(i915, wf) \
+ for (wf = intel_runtime_pm_get(i915); wf; \
+intel_runtime_pm_put(i915, wf), wf = 0)
-:509: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects?
#509: FILE: drivers/gpu/drm/i915/intel_drv.h:2181:
+#define with_intel_runtime_pm(i915, wf) \
+ for (wf = intel_runtime_pm_get(i915); wf; \
+intel_runtime_pm_put(i915, wf), wf = 0)
-:513: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible
side-effects?
#513: FILE: drivers/gpu/drm/i915/intel_drv.h:2185:
+#define with_intel_runtime_pm_if_in_use(i915, wf) \
+ for (wf = intel_runtime_pm_get_if_in_use(i915); wf; \
+intel_runtime_pm_put(i915, wf), wf = 0)
-:513: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects?
#513: FILE: drivers/gpu/drm/i915/intel_drv.h:2185:
+#define with_intel_runtime_pm_if_in_use(i915, wf) \
+ for (wf = intel_runtime_pm_get_if_in_use(i915); wf; \
+intel_runtime_pm_put(i915, wf), wf = 0)
total: 0 errors, 0 warnings, 4 checks, 732 lines checked
507dba016bbc drm/i915: Markup paired operations on display power domains
e1be67c9baf0 drm/i915: Track the wakeref used to initialise display power
domains
-:213: WARNING:LINE_SPACING: Missing a blank line after declarations
#213: FILE: drivers/gpu/drm/i915/intel_runtime_pm.c:4107:
+ struct i915_power_domains *power_domains = >power_domains;
+ intel_wakeref_t wakeref __maybe_unused =
total: 0 errors, 1 warnings, 0 checks, 324 lines checked
5b0a7f1a093b drm/i915: Combined gt.awake/gt.power wakerefs
7d9692b87640 drm/i915/dp: Markup pps lock power well
-:57: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dp' - possible side-effects?
#57: FILE: drivers/gpu/drm/i915/intel_dp.c:633:
+#define with_pps_lock(dp, wf) \
+ for (wf = pps_lock(dp); wf; wf = pps_unlock(dp, wf))
-:57: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects?
#57: FILE: drivers/gpu/drm/i915/intel_dp.c:633:
+#define with_pps_lock(dp, wf) \
+ for (wf = pps_lock(dp); wf; wf = pps_unlock(dp, wf))
total: 0 errors, 0 warnings, 2 checks, 430 lines checked
6649c0427ac7 drm/i915: Complain if hsw_get_pipe_config acquires the same power
well twice
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim
== Series Details == Series: series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/53953/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Return immediately if trylock fails for direct-reclaim Okay! Commit: drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start Okay! Commit: drm/i915/userptr: Probe vma range before gup Okay! Commit: drm/i915/selftests: Check we can recover a wedged device Okay! Commit: drm/i915/selftests: Verify we can perform resets from atomic context Okay! Commit: drm/i915/icl: Record the valid VDBoxes with SFC capability Okay! Commit: drm/i915/icl: Mind the SFC units when resetting VD or VEBox engines Okay! Commit: drm/i915: Always try to reset the GPU on takeover Okay! Commit: drm/i915: Report the number of closed vma held by each context in debugfs Okay! Commit: drm/i915: Remove debugfs/i915_ppgtt_info -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1501:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1501:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1511:17: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1511:17: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1557:17: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1557:17: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem_gtt.c:348:14: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem_gtt.c:348:14: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:348:14: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:348:14: warning: expression using sizeof(void) Commit: drm/i915: Track all held rpm wakerefs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3561:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3568:16: warning: expression using sizeof(void) +./include/linux/slab.h:332:43: warning: dubious: x & !y Commit: drm/i915: Markup paired operations on wakerefs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3568:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3572:16: warning: expression using sizeof(void) +./include/linux/slab.h:332:43: warning: dubious: x & !y Commit: drm/i915: Syntatic sugar for using intel_runtime_pm Okay! Commit: drm/i915: Markup paired operations on display power domains -drivers/gpu/drm/i915/selftests/../i915_drv.h:3572:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3574:16: warning: expression using sizeof(void) Commit: drm/i915: Track the wakeref used to initialise display power domains -drivers/gpu/drm/i915/selftests/../i915_drv.h:3574:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3576:16: warning: expression using sizeof(void) Commit: drm/i915: Combined gt.awake/gt.power wakerefs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3576:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3575:16: warning: expression using sizeof(void) Commit: drm/i915/dp: Markup pps lock power well Okay! Commit: drm/i915: Complain if hsw_get_pipe_config acquires the same power well twice Okay! Commit: drm/i915: Mark up Ironlake ips with rpm wakerefs Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
Hi,
On 07-12-18 12:39, Mika Westerberg wrote:
On Thu, Dec 06, 2018 at 02:47:03PM +0100, Hans de Goede wrote:
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.
Although this is not really an ACPI opregion, the ACPI opregion code is the
closest thing we have. We need to have support for these PMIC specific MIPI
sequence elements somwhere. Since we already instantiate a special platform
device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to,
with PMIC specific implementations of the OpRegion, the handling of MIPI
sequence PMIC elements fits very well in the ACPI PMIC OpRegion code.
This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element()
function, which is to be backed by a PMIC specific
exec_mipi_pmic_seq_element callback. This function will be called by the
i915 code to execture MIPI sequence PMIC elements.
Signed-off-by: Hans de Goede
---
drivers/acpi/pmic/intel_pmic.c | 25 +
drivers/acpi/pmic/intel_pmic.h | 1 +
include/linux/mfd/intel_soc_pmic.h | 2 ++
3 files changed, 28 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
index ca18e0d23df9..0d96ca08bb79 100644
--- a/drivers/acpi/pmic/intel_pmic.c
+++ b/drivers/acpi/pmic/intel_pmic.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
#include "intel_pmic.h"
@@ -36,6 +37,8 @@ struct intel_pmic_opregion {
struct intel_pmic_regs_handler_ctx ctx;
};
+static struct intel_pmic_opregion *intel_pmic_opregion;
+
static int pmic_get_reg_bit(int address, struct pmic_table *table,
int count, int *reg, int *bit)
{
@@ -304,6 +307,7 @@ int intel_pmic_install_opregion_handler(struct device *dev,
acpi_handle handle,
}
opregion->data = d;
+ intel_pmic_opregion = opregion;
return 0;
out_remove_thermal_handler:
@@ -319,3 +323,24 @@ int intel_pmic_install_opregion_handler(struct device
*dev, acpi_handle handle,
return ret;
}
EXPORT_SYMBOL_GPL(intel_pmic_install_opregion_handler);
+
Since this is exported, please add kernel-doc here.
Done for v3.
+void intel_soc_pmic_exec_mipi_pmic_seq_element(const u8 *data)
+{
+ struct intel_pmic_opregion_data *d;
+
+ if (!intel_pmic_opregion) {
+ pr_warn("%s: No PMIC registered\n", __func__);
+ return;
Why not return error codes instead?
Other ops in struct intel_pmic_opregion_data seem to do so.
Ok, I've changed the return-type to int and I'm returning error
codes for v3 of this patch-set.
Regards,
Hans
+ }
+
+ d = intel_pmic_opregion->data;
+ if (!d->exec_mipi_pmic_seq_element) {
+ pr_warn("%s: Not implemented\n", __func__);
+ return;
Ditto.
+ }
+
+ mutex_lock(_pmic_opregion->lock);
+ d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap, data);
+ mutex_unlock(_pmic_opregion->lock);
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_exec_mipi_pmic_seq_element);
diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
index 095afc96952e..5a7bb33d046a 100644
--- a/drivers/acpi/pmic/intel_pmic.h
+++ b/drivers/acpi/pmic/intel_pmic.h
@@ -15,6 +15,7 @@ struct intel_pmic_opregion_data {
int (*update_aux)(struct regmap *r, int reg, int raw_temp);
int (*get_policy)(struct regmap *r, int reg, int bit, u64 *value);
int (*update_policy)(struct regmap *r, int reg, int bit, int enable);
+ void (*exec_mipi_pmic_seq_element)(struct regmap *r, const u8 *data);
struct pmic_table *power_table;
int power_table_count;
struct pmic_table *thermal_table;
diff --git a/include/linux/mfd/intel_soc_pmic.h
b/include/linux/mfd/intel_soc_pmic.h
index ed1dfba5e5f9..ce04ad7d4b6c 100644
--- a/include/linux/mfd/intel_soc_pmic.h
+++ b/include/linux/mfd/intel_soc_pmic.h
@@ -26,4 +26,6 @@ struct intel_soc_pmic {
struct device *dev;
};
+void intel_soc_pmic_exec_mipi_pmic_seq_element(const u8 *data);
+
#endif/* __INTEL_SOC_PMIC_H__ */
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/intel_dsi_vbt: Add support for PMIC mipi sequences
Hi,
On 07-12-18 18:17, Ville Syrjälä wrote:
On Thu, Dec 06, 2018 at 02:47:05PM +0100, Hans de Goede wrote:
Add support for PMIC mipi sequences using the new
intel_soc_pmic_exec_mipi_pmic_seq_element function.
Please document somewhere which machines you've found to need
this (commit msg should be sufficient I suppose). Can make it
much easier to respond to bug reports like "my machine X with
DSI doesn't work".
Ok, I've added this info to the commit message for v3 of the
patch-set.
Regards,
Hans
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index f27af47c6e49..6a2ed1ca72e0 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -371,7 +372,11 @@ static const u8 *mipi_exec_spi(struct intel_dsi
*intel_dsi, const u8 *data)
static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
{
+#ifdef CONFIG_PMIC_OPREGION
+ intel_soc_pmic_exec_mipi_pmic_seq_element(data);
+#else
DRM_DEBUG_KMS("Skipping PMIC element execution\n");
+#endif
return data + 15;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
