Re: [Intel-gfx] [PATCH] drm/i915/ttm: don't leak the ccs state

[C, Ramalingam]

> -Original Message-
> From: Auld, Matthew 
> Sent: Thursday, July 28, 2022 1:38 PM
> To: C, Ramalingam ; intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Thomas Hellström 
> 
> Subject: Re: [PATCH] drm/i915/ttm: don't leak the ccs state
> 
> On 28/07/2022 00:16, C, Ramalingam wrote:
> >> -Original Message-
> >> From: Auld, Matthew 
> >> Sent: Wednesday, July 27, 2022 10:14 PM
> >> To: intel-gfx@lists.freedesktop.org
> >> Cc: dri-de...@lists.freedesktop.org; Thomas Hellström
> >> ; C, Ramalingam
> >> 
> >> Subject: [PATCH] drm/i915/ttm: don't leak the ccs state
> >>
> >> The kernel only manages the ccs state with lmem-only objects, however
> >> the kernel should still take care not to leak the CCS state from the 
> >> previous user.
> >>
> >> Fixes: 48760ffe923a ("drm/i915/gt: Clear compress metadata for
> >> Flat-ccs objects")
> >> Signed-off-by: Matthew Auld 
> >> Cc: Thomas Hellström 
> >> Cc: Ramalingam C 
> >> ---
> >>   drivers/gpu/drm/i915/gt/intel_migrate.c | 23 ++-
> >>   1 file changed, 22 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
> >> b/drivers/gpu/drm/i915/gt/intel_migrate.c
> >> index a69b244f14d0..9a0814422ba4 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> >> @@ -708,7 +708,7 @@ intel_context_migrate_copy(struct intel_context *ce,
> >>u8 src_access, dst_access;
> >>struct i915_request *rq;
> >>int src_sz, dst_sz;
> >> -  bool ccs_is_src;
> >> +  bool ccs_is_src, overwrite_ccs;
> >>int err;
> >>
> >>GEM_BUG_ON(ce->vm != ce->engine->gt->migrate.context->vm);
> >> @@ -749,6 +749,8 @@ intel_context_migrate_copy(struct intel_context *ce,
> >>get_ccs_sg_sgt(_ccs, bytes_to_cpy);
> >>}
> >>
> >> +  overwrite_ccs = HAS_FLAT_CCS(i915) && !ccs_bytes_to_cpy &&
> >> +dst_is_lmem;
> >> +
> >>src_offset = 0;
> >>dst_offset = CHUNK_SZ;
> >>if (HAS_64K_PAGES(ce->engine->i915)) { @@ -852,6 +854,25 @@
> >> intel_context_migrate_copy(struct intel_context *ce,
> >>if (err)
> >>goto out_rq;
> >>ccs_bytes_to_cpy -= ccs_sz;
> >> +  } else if (overwrite_ccs) {
> >> +  err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
> >> +  if (err)
> >> +  goto out_rq;
> >> +
> >> +  /*
> >> +   * While we can't always restore/manage the CCS state,
> >> +   * we still need to ensure we don't leak the CCS state
> >> +   * from the previous user, so make sure we overwrite it
> >> +   * with something.
> >> +   */
> >> +  err = emit_copy_ccs(rq, dst_offset, INDIRECT_ACCESS,
> >> +  dst_offset, DIRECT_ACCESS, len);
> >> +  if (err)
> >> +  goto out_rq;
> >> +
> >> +  err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
> >> +  if (err)
> >> +  goto out_rq;
> > The change is looking good to the purpose. But shouldn't this be the part 
> > of lmem allocation itself?
> 
> Hmm, what do you mean by the lmem allocation itself? The scenarios I had in 
> mind here were:
> 
> - { lmem, smem } buffer, object is allocated in smem (like with initial
> mmap) and then moved to lmem (smem -> lmem).
> 
> - { lmem, smem } buffer, object is allocated in lmem, but then evicted to 
> smem. Object then moved
> back to lmem (smem -> lmem).
> 
> - { lmem, smem} buffer with CPU_ACCESS flag on small-bar system, object is 
> allocated in non-
> mappable lmem, and them moved to the mappable part of lmem on fault (lmem -> 
> lmem).
> 
> In all the above cases the CCS state is left uninitialised, AFAICT.

As we discussed offline, this will clear the ccs state(old) of the dst lmem in 
case of migration
from smem to lmem of smem+lmem obj. this seems to be right place to fix the 
info leak of
previous ccs state.

Reviewed-by: Ramalingam C 

> 
> >
> > Ram.
> >>}
> >>
> >>/* Arbitration is re-enabled between requests. */
> >> --
> >> 2.37.1
> >

Re: [Intel-gfx] [PATCH] drm/i915/ttm: don't leak the ccs state

[C, Ramalingam]

> -Original Message-
> From: Auld, Matthew 
> Sent: Wednesday, July 27, 2022 10:14 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Thomas Hellström 
> ; C,
> Ramalingam 
> Subject: [PATCH] drm/i915/ttm: don't leak the ccs state
> 
> The kernel only manages the ccs state with lmem-only objects, however the 
> kernel should still take
> care not to leak the CCS state from the previous user.
> 
> Fixes: 48760ffe923a ("drm/i915/gt: Clear compress metadata for Flat-ccs 
> objects")
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 
> Cc: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/gt/intel_migrate.c | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
> b/drivers/gpu/drm/i915/gt/intel_migrate.c
> index a69b244f14d0..9a0814422ba4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> @@ -708,7 +708,7 @@ intel_context_migrate_copy(struct intel_context *ce,
>   u8 src_access, dst_access;
>   struct i915_request *rq;
>   int src_sz, dst_sz;
> - bool ccs_is_src;
> + bool ccs_is_src, overwrite_ccs;
>   int err;
> 
>   GEM_BUG_ON(ce->vm != ce->engine->gt->migrate.context->vm);
> @@ -749,6 +749,8 @@ intel_context_migrate_copy(struct intel_context *ce,
>   get_ccs_sg_sgt(_ccs, bytes_to_cpy);
>   }
> 
> + overwrite_ccs = HAS_FLAT_CCS(i915) && !ccs_bytes_to_cpy &&
> +dst_is_lmem;
> +
>   src_offset = 0;
>   dst_offset = CHUNK_SZ;
>   if (HAS_64K_PAGES(ce->engine->i915)) { @@ -852,6 +854,25 @@
> intel_context_migrate_copy(struct intel_context *ce,
>   if (err)
>   goto out_rq;
>   ccs_bytes_to_cpy -= ccs_sz;
> + } else if (overwrite_ccs) {
> + err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
> + if (err)
> + goto out_rq;
> +
> + /*
> +  * While we can't always restore/manage the CCS state,
> +  * we still need to ensure we don't leak the CCS state
> +  * from the previous user, so make sure we overwrite it
> +  * with something.
> +  */
> + err = emit_copy_ccs(rq, dst_offset, INDIRECT_ACCESS,
> + dst_offset, DIRECT_ACCESS, len);
> + if (err)
> + goto out_rq;
> +
> + err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
> + if (err)
> + goto out_rq;
The change is looking good to the purpose. But shouldn't this be the part of 
lmem allocation itself?

Ram.
>   }
> 
>   /* Arbitration is re-enabled between requests. */
> --
> 2.37.1

Re: [Intel-gfx] [RFC 0/2] drm/i915/ttm: Evict and store of compressed object

[C, Ramalingam]

On 2022-02-07 at 15:37:09 +0100, Christian König wrote:
> Am 07.02.22 um 14:53 schrieb Ramalingam C:
> > On 2022-02-07 at 12:41:59 +0100, Christian König wrote:
> > > Am 07.02.22 um 10:37 schrieb Ramalingam C:
> > > > On flat-ccs capable platform we need to evict and resore the ccs data
> > > > along with the corresponding main memory.
> > > > 
> > > > This ccs data can only be access through BLT engine through a special
> > > > cmd ( )
> > > > 
> > > > To support above requirement of flat-ccs enabled i915 platforms this
> > > > series adds new param called ccs_pages_needed to the ttm_tt_init(),
> > > > to increase the ttm_tt->num_pages of system memory when the obj has the
> > > > lmem placement possibility.
> > > Well question is why isn't the buffer object allocated with the extra 
> > > space
> > > in the first place?
> > Hi Christian,
> > 
> > On Xe-HP and later devices, we use dedicated compression control state (CCS)
> > stored in local memory for each surface, to support the 3D and media
> > compression formats.
> > 
> > The memory required for the CCS of the entire local memory is 1/256 of the
> > local memory size. So before the kernel boot, the required memory is 
> > reserved
> > for the CCS data and a secure register will be programmed with the CCS base
> > address
> > 
> > So when we allocate a object in local memory we dont need to explicitly
> > allocate the space for ccs data. But when we evict the obj into the smem
> >   to hold the compression related data along with the obj we need smem
> >   space of obj_size + (obj_size/256).
> > 
> >   Hence when we create smem for an obj with lmem placement possibility we
> >   create with the extra space.
> 
> Exactly that's what I've been missing in the cover letter and/or commit
> messages, comments etc..
> 
> Over all sounds like a valid explanation to me, just one comment on the
> code/naming:
> 
> >   int ttm_tt_init(struct ttm_tt *ttm, struct ttm_buffer_object *bo,
> > -   uint32_t page_flags, enum ttm_caching caching)
> > +   uint32_t page_flags, enum ttm_caching caching,
> > +   unsigned long ccs_pages)
> 
> Please don't try to leak any i915 specific stuff into common TTM code.
> 
> For example use the wording extra_pages instead of ccs_pages here.
> 
> Apart from that looks good to me,

Thank you. I will address the comments on naming.

Ram
> Christian.
> 
> > 
> >   Ram.
> > > Regards,
> > > Christian.
> > > 
> > > > This will be on top of the flat-ccs enabling series
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F95686%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7Ce54bb7576a334a76cab008d9ea4138e5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637798388115252727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=V9wQZvb0JwtplIBSYYXGzrg%2BEMvn4hfkscziPFDvZDY%3Dreserved=0
> > > > 
> > > > For more about flat-ccs feature please have a look at
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F471777%2F%3Fseries%3D95686%26rev%3D5data=04%7C01%7Cchristian.koenig%40amd.com%7Ce54bb7576a334a76cab008d9ea4138e5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637798388115252727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=aYjoTKMbZvi%2Fnr7hkSH4SYGxZIv8Dj210dNrBnUNpQw%3Dreserved=0
> > > > 
> > > > Testing of the series is WIP and looking forward for the early review on
> > > > the amendment to ttm_tt_init and the approach.
> > > > 
> > > > Ramalingam C (2):
> > > > drm/i915/ttm: Add extra pages for handling ccs data
> > > > drm/i915/migrate: Evict and restore the ccs data
> > > > 
> > > >drivers/gpu/drm/drm_gem_vram_helper.c  |   2 +-
> > > >drivers/gpu/drm/i915/gem/i915_gem_ttm.c|  23 +-
> > > >drivers/gpu/drm/i915/gt/intel_migrate.c| 283 
> > > > +++--
> > > >drivers/gpu/drm/qxl/qxl_ttm.c  |   2 +-
> > > >drivers/gpu/drm/ttm/ttm_agp_backend.c  |   2 +-
> > > >drivers/gpu/drm/ttm/ttm_tt.c   |  12 +-
> > > >drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c |   2 +-
> > > >include/drm/ttm/ttm_tt.h   |   4 +-
> > > >8 files changed, 191 insertions(+), 139 deletions(-)
> > > > 
> 

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: enforce min GTT alignment for discrete cards

[C, Ramalingam]

On 2022-01-20 at 16:09:01 +, Robert Beckett wrote:
> 
> 
> On 20/01/2022 15:58, Matthew Auld wrote:
> > On 20/01/2022 15:44, Robert Beckett wrote:
> > > 
> > > 
> > > On 20/01/2022 14:59, Matthew Auld wrote:
> > > > On 20/01/2022 13:15, Robert Beckett wrote:
> > > > > 
> > > > > 
> > > > > On 20/01/2022 11:46, Ramalingam C wrote:
> > > > > > On 2022-01-18 at 17:50:34 +, Robert Beckett wrote:
> > > > > > > From: Matthew Auld 
> > > > > > > 
> > > > > > > For local-memory objects we need to align the GTT addresses
> > > > > > > to 64K, both for the ppgtt and ggtt.
> > > > > > > 
> > > > > > > We need to support vm->min_alignment > 4K, depending
> > > > > > > on the vm itself and the type of object we are inserting.
> > > > > > > With this in mind update the GTT selftests to take this
> > > > > > > into account.
> > > > > > > 
> > > > > > > For DG2 we further align and pad lmem object GTT addresses
> > > > > > > to 2MB to ensure PDEs contain consistent page sizes as
> > > > > > > required by the HW.
> > > > > > > 
> > > > > > > Signed-off-by: Matthew Auld 
> > > > > > > Signed-off-by: Ramalingam C 
> > > > > > > Signed-off-by: Robert Beckett 
> > > > > > > Cc: Joonas Lahtinen 
> > > > > > > Cc: Rodrigo Vivi 
> > > > > > > ---
> > > > > > >   .../i915/gem/selftests/i915_gem_client_blt.c  | 23 +++--
> > > > > > >   drivers/gpu/drm/i915/gt/intel_gtt.c   | 14 +++
> > > > > > >   drivers/gpu/drm/i915/gt/intel_gtt.h   |  9 ++
> > > > > > >   drivers/gpu/drm/i915/i915_vma.c   | 14 +++
> > > > > > >   drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96
> > > > > > > ---
> > > > > > >   5 files changed, 115 insertions(+), 41 deletions(-)
> > > > > > > 
> > > > > > > diff --git
> > > > > > > a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> > > > > > > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> > > > > > > index c08f766e6e15..7fee95a65414 100644
> > > > > > > --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> > > > > > > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> > > > > > > @@ -39,6 +39,7 @@ struct tiled_blits {
> > > > > > >   struct blit_buffer scratch;
> > > > > > >   struct i915_vma *batch;
> > > > > > >   u64 hole;
> > > > > > > +    u64 align;
> > > > > > >   u32 width;
> > > > > > >   u32 height;
> > > > > > >   };
> > > > > > > @@ -410,14 +411,21 @@ tiled_blits_create(struct
> > > > > > > intel_engine_cs *engine, struct rnd_state *prng)
> > > > > > >   goto err_free;
> > > > > > >   }
> > > > > > > -    hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
> > > > > > > +    t->align = I915_GTT_PAGE_SIZE_2M; /* XXX worst
> > > > > > > case, derive from vm! */
> > > > > > > +    t->align = max(t->align,
> > > > > > > +   i915_vm_min_alignment(t->ce->vm,
> > > > > > > INTEL_MEMORY_LOCAL));
> > > > > > > +    t->align = max(t->align,
> > > > > > > +   i915_vm_min_alignment(t->ce->vm,
> > > > > > > INTEL_MEMORY_SYSTEM));
> > > > > > > +
> > > > > > > +    hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
> > > > > > >   hole_size *= 2; /* room to maneuver */
> > > > > > > -    hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
> > > > > > > +    hole_size += 2 * t->align; /* padding on either side */
> > > > > > >   mutex_lock(>ce->vm->mutex);
> > > > > > >   memset(, 0, sizeof(hole));
> > > > > > >   err = drm_mm_insert_node_in_range(>ce->vm->mm, ,
> > > > > > > -  hole_size, 0, I915_COLOR_UNEVICTABLE,
> > > > > > > +  hole_size, t->align,
> > > > > > > +  I915_COLOR_UNEVICTABLE,
> > > > > > >     0, U64_MAX,
> > > > > > >     DRM_MM_INSERT_BEST);
> > > > > > >   if (!err)
> > > > > > > @@ -428,7 +436,7 @@ tiled_blits_create(struct
> > > > > > > intel_engine_cs *engine, struct rnd_state *prng)
> > > > > > >   goto err_put;
> > > > > > >   }
> > > > > > > -    t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
> > > > > > > +    t->hole = hole.start + t->align;
> > > > > > >   pr_info("Using hole at %llx\n", t->hole);
> > > > > > >   err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
> > > > > > > @@ -455,7 +463,7 @@ static void
> > > > > > > tiled_blits_destroy(struct tiled_blits *t)
> > > > > > >   static int tiled_blits_prepare(struct tiled_blits *t,
> > > > > > >  struct rnd_state *prng)
> > > > > > >   {
> > > > > > > -    u64 offset = PAGE_ALIGN(t->width * t->height * 4);
> > > > > > > +    u64 offset = round_up(t->width * t->height * 4, t->align);
> > > > > > >   u32 *map;
> > > > > > >   int err;
> > > > > > >   int i;
> > > > > > > @@ -486,8 +494,7 @@ static int
> > > > > > > tiled_blits_prepare(struct tiled_blits *t,
> > > > > > >   static int tiled_blits_bounce(struct tiled_blits
> > > > > > > *t, struct rnd_state *prng)
> > > > > > >   {
> > > > > > > -    u64 offset =
> 

Re: [Intel-gfx] [PATCH] drm/i915/gt: Fixing the error handling of shmem_pin_map

[C, Ramalingam]

In that case can we merge the series 
http://intel-gfx-pw.fi.intel.com/series/6611/ ?
If so please provide your R-b/Ack


> -Original Message-
> From: Chris Wilson 
> Sent: Monday, December 7, 2020 4:17 PM
> To: C, Ramalingam ; intel-gfx  g...@lists.freedesktop.org>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gt: Fixing the error handling of
> shmem_pin_map
> 
> Quoting Ramalingam C (2020-12-07 10:28:12)
> > Since i was size_t, at error handling if i is 0, then --i >= 0.
> > Making i as int.
> 
> The problem here is that size_t is 64b, but int 32b.
> There's a patch by Colin King that does the trick.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 14/17] drm/i915: Add connector to hdcp_shim->check_link()

[C, Ramalingam]

> -Original Message-
> From: Sean Paul 
> Sent: Tuesday, June 23, 2020 9:29 PM
> To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: Li, Juston ; C, Ramalingam
> ; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
> ; daniel.vet...@ffwll.ch; Sean Paul
> 
> Subject: [PATCH v7 14/17] drm/i915: Add connector to hdcp_shim->check_link()
> 
> From: Sean Paul 
> 
> Currently we derive the connector from digital port in check_link(). For MST, 
> this
> isn't sufficient since the digital port passed into the function can have 
> multiple
> connectors downstream. This patch adds connector to the check_link()
> arguments so we have it when we need it.
> 
> Signed-off-by: Sean Paul 
Reviewed-by: Ramalingam C 

> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-
> s...@poorly.run #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-
> s...@poorly.run #v5
> Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-
> 14-s...@poorly.run #v6
> 
> Changes in v4:
> -Added to the set
> Changes in v5:
> -None
> Changes in v6:
> -None
> Changes in v7:
> -None
> ---
>  drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c   | 3 ++-
>  drivers/gpu/drm/i915/display/intel_hdcp.c  | 2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c  | 5 ++---
>  4 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 811085ef3fba..94211b8fc159 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -318,7 +318,8 @@ struct intel_hdcp_shim {
>bool enable);
> 
>   /* Ensures the link is still protected */
> - bool (*check_link)(struct intel_digital_port *intel_dig_port);
> + bool (*check_link)(struct intel_digital_port *intel_dig_port,
> +struct intel_connector *connector);
> 
>   /* Detects panel's hdcp capability. This is optional for HDMI. */
>   int (*hdcp_capable)(struct intel_digital_port *intel_dig_port, diff 
> --git
> a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index e26a45f880cb..43446a6cae8d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -223,7 +223,8 @@ int intel_dp_hdcp_toggle_signalling(struct
> intel_digital_port *intel_dig_port,  }
> 
>  static
> -bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port)
> +bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port,
> +   struct intel_connector *connector)
>  {
>   struct drm_i915_private *i915 = to_i915(intel_dig_port-
> >base.base.dev);
>   ssize_t ret;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index d79d4142aea7..6bd0e4616ee1 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -953,7 +953,7 @@ static int intel_hdcp_check_link(struct intel_connector
> *connector)
>   goto out;
>   }
> 
> - if (hdcp->shim->check_link(intel_dig_port)) {
> + if (hdcp->shim->check_link(intel_dig_port, connector)) {
>   if (hdcp->value !=
> DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
>   intel_hdcp_update_value(connector,
> 
>   DRM_MODE_CONTENT_PROTECTION_ENABLED, true); diff --git
> a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index ca71ee3dd1c7..b12f1af0611d 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1546,11 +1546,10 @@ int intel_hdmi_hdcp_toggle_signalling(struct
> intel_digital_port *intel_dig_port,  }
> 
>  static
> -bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port)
> +bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port,
> + struct intel_connector *connector)
>  {
>   struct drm_i915_private *i915 = to_i915(intel_dig_port-
> >base.base.dev);
> - struct intel_connector *connector =
> - intel_dig_port->hdmi.attached_connector;
>   enum port port = intel_dig_port->base.port;
>   enum transcoder cpu_transcoder = connector->hdcp.cpu_transcoder;
>   int ret;
> --
> Sean Paul, Software Engineer, Google / Chromium OS

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 12/17] drm/i915: Factor out HDCP shim functions from dp for use by dp_mst

[C, Ramalingam]

> -Original Message-
> From: Sean Paul 
> Sent: Tuesday, June 23, 2020 9:29 PM
> To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: Li, Juston ; C, Ramalingam
> ; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
> ; daniel.vet...@ffwll.ch; Sean Paul
> 
> Subject: [PATCH v7 12/17] drm/i915: Factor out HDCP shim functions from dp
> for use by dp_mst
> 
> From: Sean Paul 
> 
> These functions are all the same for dp and dp_mst, so move them into a
> dedicated file for both sst and mst to use.
> 
> Signed-off-by: Sean Paul 
Reviewed-by: Ramalingam C 

> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-
> 11-s...@poorly.run #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-12-
> s...@poorly.run #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-12-
> s...@poorly.run #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-12-
> s...@poorly.run #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-12-
> s...@poorly.run #v5
> Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-
> 12-s...@poorly.run #v6
> 
> Changes in v2:
> -None
> Changes in v3:
> -Created intel_dp_hdcp.c for the shared functions to live (Ville) Changes in 
> v4:
> -Rebased on new drm logging change
> Changes in v5:
> -None
> Changes in v6:
> -None
> Changes in v7:
> -Rebased patch
> ---
>  drivers/gpu/drm/i915/Makefile|   1 +
>  drivers/gpu/drm/i915/display/intel_dp.c  | 606 +-
>  drivers/gpu/drm/i915/display/intel_dp.h  |   3 +
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 636 +++
>  4 files changed, 641 insertions(+), 605 deletions(-)  create mode 100644
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 41a27fd5dbc7..cba4ddb95ab1 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -233,6 +233,7 @@ i915-y += \
>   display/intel_ddi.o \
>   display/intel_dp.o \
>   display/intel_dp_aux_backlight.o \
> + display/intel_dp_hdcp.o \
>   display/intel_dp_link_training.o \
>   display/intel_dp_mst.o \
>   display/intel_dsi.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d98e45a09c28..78ce5e41d559 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -38,7 +38,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> 
>  #include "i915_debugfs.h"
> @@ -6396,609 +6395,6 @@ void intel_dp_encoder_suspend(struct
> intel_encoder *intel_encoder)
>   edp_panel_vdd_off_sync(intel_dp);
>  }
> 
> -static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp, int 
> timeout)
> -{
> - long ret;
> -
> -#define C (hdcp->cp_irq_count_cached != atomic_read(>cp_irq_count))
> - ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
> -msecs_to_jiffies(timeout));
> -
> - if (!ret)
> - DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
> -}
> -
> -static
> -int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> - u8 *an)
> -{
> - struct drm_i915_private *i915 = to_i915(intel_dig_port-
> >base.base.dev);
> - u8 aksv[DRM_HDCP_KSV_LEN] = {};
> - ssize_t dpcd_ret;
> -
> - dpcd_ret = drm_dp_dpcd_write(_dig_port->dp.aux,
> DP_AUX_HDCP_AN,
> -  an, DRM_HDCP_AN_LEN);
> - if (dpcd_ret != DRM_HDCP_AN_LEN) {
> - drm_dbg_kms(>drm,
> - "Failed to write An over DP/AUX (%zd)\n",
> - dpcd_ret);
> - return dpcd_ret >= 0 ? -EIO : dpcd_ret;
> - }
> -
> - /*
> -  * Since Aksv is Oh-So-Secret, we can't access it in software. So we
> -  * send an empty buffer of the correct length through the DP helpers. On
> -  * the other side, in the transfer hook, we'll generate a flag based on
> -  * the destination address which will tickle the hardware to output the
> -  * Aksv on our behalf after the header is sent.
> -  */
> - dpcd_ret = drm_dp_dpcd_write(_dig_port->dp.aux,
> DP_AUX_HDCP_AKSV,
> -  aksv, DRM_HDCP_KSV_LEN);
> - if (dpcd_ret != DRM_HDCP_KSV_

Re: [Intel-gfx] [PATCH v7 11/17] drm/i915: Use ddi_update_pipe in intel_dp_mst

[C, Ramalingam]

> -Original Message-
> From: Sean Paul 
> Sent: Tuesday, June 23, 2020 9:29 PM
> To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: Li, Juston ; C, Ramalingam
> ; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
> ; daniel.vet...@ffwll.ch; Sean Paul
> 
> Subject: [PATCH v7 11/17] drm/i915: Use ddi_update_pipe in intel_dp_mst
> 
> From: Sean Paul 
> 
> In order to act upon content_protection property changes, we'll need to
> implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe for
> this
> 
> Signed-off-by: Sean Paul 
Reviewed-by: Ramalingam C 

> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-
> 10-s...@poorly.run #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-11-
> s...@poorly.run #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-11-
> s...@poorly.run #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-11-
> s...@poorly.run #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-11-
> s...@poorly.run #v5
> Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-
> 11-s...@poorly.run #v6
> 
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -None
> Changes in v7:
> -None
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c| 11 ++-
>  drivers/gpu/drm/i915/display/intel_dp.h |  6 ++
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  1 +
>  3 files changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 536299f902b9..29f1f552e8d8 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3907,13 +3907,14 @@ static void intel_ddi_update_pipe_dp(struct
> intel_atomic_state *state,
>   intel_panel_update_backlight(state, encoder, crtc_state, conn_state);  }
> 
> -static void intel_ddi_update_pipe(struct intel_atomic_state *state,
> -   struct intel_encoder *encoder,
> -   const struct intel_crtc_state *crtc_state,
> -   const struct drm_connector_state
> *conn_state)
> +void intel_ddi_update_pipe(struct intel_atomic_state *state,
> +struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +const struct drm_connector_state *conn_state)
>  {
> 
> - if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
> + !intel_encoder_is_mst(encoder))
>   intel_ddi_update_pipe_dp(state, encoder, crtc_state,
>conn_state);
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 0a8950f744f6..6352c7e97e3b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -17,6 +17,7 @@ struct drm_encoder;
>  struct drm_i915_private;
>  struct drm_modeset_acquire_ctx;
>  struct drm_dp_vsc_sdp;
> +struct intel_atomic_state;
>  struct intel_connector;
>  struct intel_crtc_state;
>  struct intel_digital_port;
> @@ -128,4 +129,9 @@ static inline unsigned int intel_dp_unused_lane_mask(int
> lane_count)
> 
>  u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
> 
> +void intel_ddi_update_pipe(struct intel_atomic_state *state,
> +struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +const struct drm_connector_state *conn_state);
> +
>  #endif /* __INTEL_DP_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 9308b5920780..0675825dcc20 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -836,6 +836,7 @@ intel_dp_create_fake_mst_encoder(struct
> intel_digital_port *intel_dig_port, enum
>   intel_encoder->compute_config_late =
> intel_dp_mst_compute_config_late;
>   intel_encoder->disable = intel_mst_disable_dp;
>   intel_encoder->post_disable = intel_mst_post_disable_dp;
> + intel_encoder->update_pipe = intel_ddi_update_pipe;
>   intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
>   intel_encoder->pre_enable = intel_mst_pre_enable_dp;
>   intel_encoder->enable = intel_mst_enable_dp;
> --
> Sean Paul, Software Engineer, Google / Chromium OS

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/10] drm: Add CP content type property

[C, Ramalingam]

> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, March 5, 2019 8:09 PM
> To: C, Ramalingam ; intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Shankar, Uma
> 
> Subject: Re: [Intel-gfx] [PATCH 01/10] drm: Add CP content type property
> 
> Op 26-02-2019 om 08:36 schreef Ramalingam C:
> > This patch adds a DRM ENUM property to the selected connectors.
> > This property is used for pass the protected content's type from
> > userspace to kernel HDCP authentication.
> >
> > Type of the stream is decided by the protected content providers as
> > Type 0/1.
> >
> > Type 0 content can be rendered on any HDCP protected display wires.
> > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> >
> > So upon a content protection request with Type 1 as Content type from
> > userspace, Kernel will declare success only if the HDCP2.2
> > authentication is successful.
> >
> > Signed-off-by: Ramalingam C 
> > ---
> >  drivers/gpu/drm/drm_atomic_uapi.c | 10 ++
> >  drivers/gpu/drm/drm_connector.c   | 64
> +++
> >  include/drm/drm_connector.h   | 15 +
> >  include/uapi/drm/drm_mode.h   |  4 +++
> >  4 files changed, 93 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 4eb81f10bc54..5289486565ce 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -746,6 +746,14 @@ static int
> drm_atomic_connector_set_property(struct drm_connector *connector,
> > return -EINVAL;
> > }
> > state->content_protection = val;
> > +   } else if (property == connector->cp_content_type_property) {
> > +   if (state->content_protection !=
> > +   DRM_MODE_CONTENT_PROTECTION_UNDESIRED &&
> > +   state->cp_content_type != val) {
> > +   DRM_DEBUG_KMS("Disable CP, then change Type\n");
> > +   return -EINVAL;
> > +   }
> > +   state->cp_content_type = val;
> 
> You can't add checks in atomic_set_property.

Thanks Maarten for the review.
I am afraid we have the similar check for content_protection, just above this.

> 
> Until we have the full state, we can't do any checks. This has to be done in 
> the
> .atomic_check() callback.
> 
> Lets say atomic commit consists of the following:
> Set Content_Protection to desired.
> Set Content Type to Type 1.
> atomic setprop will fail
> 
> Plus the check itself is bogus. We should be able to change HDCP strictness
> without a modeset, the same way we enable and disable HDCP 1.4 with a
> fastset.

This is not modeset mandating, but the sequence of hdcp_disable->change 
Type->hdcp_enable from userspace.
Reason is we need to redo the hdcp authenticate with new Type value.

Alternate approach would be kernel performing disable and enable on Type change 
request from userspace.
For this we could disable hdcp at intel_hdcp_atomic_check and re-enable with 
new Type value at atomic_commit.

I thought it is better to leave the required preparation (disable and enable of 
hdcp) to userspace.
But if we prefer to push that into kernel also it is doable. Share your opinion 
please.

> 
> > } else if (property == connector->colorspace_property) {
> > state->colorspace = val;
> > } else if (property == config->writeback_fb_id_property) { @@ -822,6
> > +830,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> > *val = state->scaling_mode;
> > } else if (property == connector->content_protection_property) {
> > *val = state->content_protection;
> > +   } else if (property == connector->cp_content_type_property) {
> > +   *val = state->cp_content_type;
> > } else if (property == config->writeback_fb_id_property) {
> > /* Writeback framebuffer is one-shot, write and forget */
> > *val = 0;
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c index 07d65a16c623..5d7738e1e977
> > 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -853,6 +853,13 @@ static const struct drm_prop_enum_list
> hdmi_colorspaces[] = {
> > { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-
> P3_RGB_Theater" },
> > };
> >
> > +

Re: [Intel-gfx] [PATCH v15 00/16] drm/i915: Implement HDCP2.2

[C, Ramalingam]

Tomas,

Lkp issue is complaining about the header drm/i915_mei_hdcp_interface.h, Which 
is already merged in drm-tip through below commit. So don’t think this is a 
genuine issue. May be this build was tried in different tree, where this commit 
is not added yet?

commit 1626eab70ebc61d015e69a4bc3479d9228539343
Author: Ramalingam C 
Date:   Fri Feb 15 14:04:58 2019 +0530

drm/i915: header for i915 - MEI_HDCP interface

v15 is now part of github.

Best Regards,
Ramalingam C


> -Original Message-
> From: Winkler, Tomas
> Sent: Monday, February 25, 2019 1:45 AM
> To: C, Ramalingam ; intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Shankar, Uma
> 
> Subject: RE: [PATCH v15 00/16] drm/i915: Implement HDCP2.2
> 
> Have you fixed the lkp issue?
> I didn't see you pushed the code to github.
> Thanks
> 
> 
> > -Original Message-
> > From: C, Ramalingam
> > Sent: Sunday, February 24, 2019 18:33
> > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> > daniel.vet...@ffwll.ch; Winkler, Tomas ;
> > Shankar, Uma 
> > Subject: Re: [PATCH v15 00/16] drm/i915: Implement HDCP2.2
> >
> > Tomas,
> >
> > Could you please help to review and give final "Go" for the series?
> >
> > Thanks
> > --Ram.
> >
> > On 2/21/2019 11:41 PM, Ramalingam C wrote:
> > > This series enables the HDCP2.2 Type 0 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 streams.
> > >
> > > Test-with:
> > > <1549566452-30175-1-git-send-email-ramalinga...@intel.com>
> > > So that CP will be tested on BAT machine too.
> > >
> > > Major changes in v15
> > >- All I915 patches are merged. So dropping them.
> > >- Few minor suggestions are incorporated at mei changes.
> > >
> > > To ease the review process, series is hosted at
> > > https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v15
> > >
> > > Ramalingam C (15):
> > >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
> > >FOR_TEST_ONLY: i915/Kconfig: Select mei_hdcp by I915
> > >
> > > Tomas Winkler (1):
> > >mei: bus: whitelist hdcp client
> > >
> > >   drivers/misc/mei/Kconfig |  11 +
> > >   drivers/misc/mei/Makefile|   2 +
> > >   drivers/misc/mei/bus-fixup.c |  16 +
> > >   drivers/misc/mei/hdcp/Makefile   |   7 +
> > >   drivers/misc/mei/hdcp/mei_hdcp.c | 849
> > +++
> > >   drivers/misc/mei/hdcp/mei_hdcp.h | 377 +
> > >   6 files changed, 1262 insertions(+)
> > >   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
> > >

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v15 00/16] drm/i915: Implement HDCP2.2

[C, Ramalingam]

Tomas,

Could you please help to review and give final "Go" for the series?

Thanks
--Ram.

On 2/21/2019 11:41 PM, Ramalingam C wrote:

This series enables the HDCP2.2 Type 0 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 streams.

Test-with: <1549566452-30175-1-git-send-email-ramalinga...@intel.com>
So that CP will be tested on BAT machine too.

Major changes in v15
   - All I915 patches are merged. So dropping them.
   - Few minor suggestions are incorporated at mei changes.

To ease the review process, series is hosted at
https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v15

Ramalingam C (15):
   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
   FOR_TEST_ONLY: i915/Kconfig: Select mei_hdcp by I915

Tomas Winkler (1):
   mei: bus: whitelist hdcp client

  drivers/misc/mei/Kconfig |  11 +
  drivers/misc/mei/Makefile|   2 +
  drivers/misc/mei/bus-fixup.c |  16 +
  drivers/misc/mei/hdcp/Makefile   |   7 +
  drivers/misc/mei/hdcp/mei_hdcp.c | 849 +++
  drivers/misc/mei/hdcp/mei_hdcp.h | 377 +
  6 files changed, 1262 insertions(+)
  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



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v14 04/33] drm/i915: MEI interface implementation

[C, Ramalingam]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Thursday, February 21, 2019 1:10 AM
> To: C, Ramalingam 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
> Uma 
> Subject: Re: [PATCH v14 04/33] drm/i915: MEI interface implementation
> 
> On Sat, Feb 16, 2019 at 11:06:51PM +0530, Ramalingam C wrote:
> > 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]
> > v4:
> >   port initialization is done only at hdcp2_init only [Danvet]
> > v5:
> >   I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
> > v6:
> >   HDCP_disable for all connectors incase of comp_unbind.
> >   Tear down HDCP comp interface at i915_unload [Daniel]
> > v7:
> >   Component init and fini are moved out of connector ops [Daniel]
> >   hdcp_disable is not called from unbind. [Daniel]
> > v8:
> >   subcomponent name is dropped as it is already merged.
> >
> > Signed-off-by: Ramalingam C 
> > Reviewed-by: Daniel Vetter  [v11]
> 
> I think that r-b was for v7, not v8, and v11 of this patch doesn't even 
> exist. Series
> itself is as v14. Anyways, merged, thanks for all your work!

Thanks Daniel. Series version at which R-b was received for the original patch 
was captured here.
But yes. Should have captured the patch version instead.

-Ram
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c|   1 +
> >  drivers/gpu/drm/i915/i915_drv.h|   7 +
> >  drivers/gpu/drm/i915/intel_connector.c |   2 +
> >  drivers/gpu/drm/i915/intel_display.c   |   4 +
> >  drivers/gpu/drm/i915/intel_drv.h   |   8 +
> >  drivers/gpu/drm/i915/intel_hdcp.c  | 398
> -
> >  6 files changed, 419 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c index 6630212f2faf..c6354f6cdbdb
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -906,6 +906,7 @@ static int i915_driver_init_early(struct
> drm_i915_private *dev_priv)
> > mutex_init(_priv->av_mutex);
> > mutex_init(_priv->wm.wm_mutex);
> > mutex_init(_priv->pps_mutex);
> > +   mutex_init(_priv->hdcp_comp_mutex);
> >
> > i915_memcpy_init_early(dev_priv);
> > intel_runtime_pm_init_early(dev_priv);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 5c8d0489a1cd..d375d1cf86f5
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -55,6 +55,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "i915_fixed.h"
> >  #include "i915_params.h"
> > @@ -2052,6 +2053,12 @@ struct drm_i915_private {
> >
> > struct i915_pmu pmu;
> >
> > +   struct i915_hdcp_comp_master *hdcp_master;
> > +   bool hdcp_comp_added;
> > +
> > +   /* Mutex to protect the above hdcp component related values. */
> > +   struct mutex hdcp_comp_mutex;
> > +
> > /*
> >  * 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_connector.c
> > b/drivers/gpu/drm/i915/intel_connector.c
> > index ee16758747c5..66ed3ee5998a 100644
> > --- a/drivers/gpu/drm/i915/intel_connector.c
> > +++ b/drivers/gpu/drm/i915/intel_connector.c
> > @@ -88,6 +88,8 @@ void intel_connector_destroy(struct drm_connector
> > *connector)
> >
> > kfree(intel_connector->detect_edid);
> >
> > +   intel_hdcp_cleanup(intel_connector);
> > +
> > if (!IS_ERR_OR_NULL(intel_connector->edid))
> > kfree(intel_connector->edid);
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 73a107b6eb9a..acb993ce7eaa 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ 

Re: [Intel-gfx] [PATCH v12 24/38] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

[C, Ramalingam]

On 2/10/2019 1:55 PM, Winkler, Tomas wrote:

On 2/9/2019 9:39 PM, Winkler, Tomas wrote:

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.
v9:
s/mei_hdcp_ddi/mei_fw_ddi
s/i915_port/mei_i915_port [Tomas]
renamed func as mei_hdcp_* [Tomas]
Instead of macro, inline func for ddi index is used. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
   drivers/misc/mei/hdcp/mei_hdcp.c | 89

   drivers/misc/mei/hdcp/mei_hdcp.h | 23 +++
   2 files changed, 112 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index 8df069c1b0cc..56d3ac1e6831 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,6 +23,95 @@
   #include 
   #include 
   #include 
+#include 
+#include 
+#include 
+
+#include "mei_hdcp.h"
+
+static inline u8 mei_get_ddi_index(short int port) {
+   enum mei_i915_port i915_port = (enum mei_i915_port)port;
+
+   return (u8)(i915_port == PORT_A ? MEI_DDI_A : i915_port); }
+

Still the same code I haven't Acked that patch.

Sorry. I will remove the ack part.

I prefer this approach as it is not so complicated stuff here. still if you 
insist I
will use switch case.

Yes, I believe that the translation should be understood.
This function should returns
MEI_DDI_XXX only (it could be u8)
It's by accident  that MEI_DDI_B equals PORT_B etc.
Please also remove dual enum i915_port and eum port  as well.

this will do?
static inline u8 mei_get_ddi_index(short int port)
{
 switch (port) {
 case PORT_A:
 return (u8)MEI_DDI_A;
 case PORT_B:
 return (u8)MEI_DDI_B;
 case PORT_C:
 return (u8)MEI_DDI_C;
 case PORT_D:
 return (u8)MEI_DDI_D;
 case PORT_E:
 return (u8)MEI_DDI_E;
 case PORT_F:
 return (u8)MEI_DDI_F;
 default:
 return (u8)MEI_DDI_INVALID_PORT;
 }
 }


-Ram


Thanks
Tomas


Thanks
--Ram


Thanks
Tomas



+/**
+ * mei_hdcp_initiate_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_hdcp_initiate_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 = mei_get_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, 

Re: [Intel-gfx] [PATCH v12 24/38] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

[C, Ramalingam]

On 2/9/2019 9:39 PM, Winkler, Tomas wrote:

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.
v9:
   s/mei_hdcp_ddi/mei_fw_ddi
   s/i915_port/mei_i915_port [Tomas]
   renamed func as mei_hdcp_* [Tomas]
   Instead of macro, inline func for ddi index is used. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
  drivers/misc/mei/hdcp/mei_hdcp.c | 89

  drivers/misc/mei/hdcp/mei_hdcp.h | 23 +++
  2 files changed, 112 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index 8df069c1b0cc..56d3ac1e6831 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,6 +23,95 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+#include 
+
+#include "mei_hdcp.h"
+
+static inline u8 mei_get_ddi_index(short int port) {
+   enum mei_i915_port i915_port = (enum mei_i915_port)port;
+
+   return (u8)(i915_port == PORT_A ? MEI_DDI_A : i915_port); }
+

Still the same code I haven't Acked that patch.

Sorry. I will remove the ack part.

I prefer this approach as it is not so complicated stuff here. still if 
you insist I will use switch case.


Thanks
--Ram


Thanks
Tomas



+/**
+ * mei_hdcp_initiate_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_hdcp_initiate_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 = mei_get_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_hdcp_initiate_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 582a7e27ae29..28686f2ae88c 100644
--- 

Re: [Intel-gfx] [PATCH v11 08/42] drm/i915: MEI interface definition

[C, Ramalingam]

On 2/8/2019 1:18 AM, Daniel Vetter wrote:

On Thu, Feb 07, 2019 at 08:40:08PM +0100, Daniel Vetter wrote:

On Thu, Feb 07, 2019 at 02:33:57AM +0530, Ramalingam C wrote:

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]
v4:
   port initialization is done only at hdcp2_init only [Danvet]
v5:
   I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
v6:
   HDCP_disable for all connectors incase of comp_unbind.
   Tear down HDCP comp interface at i915_unload [Daniel]

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/i915_drv.c|   1 +
  drivers/gpu/drm/i915/i915_drv.h|   7 +
  drivers/gpu/drm/i915/intel_connector.c |   2 +
  drivers/gpu/drm/i915/intel_drv.h   |   6 +
  drivers/gpu/drm/i915/intel_hdcp.c  | 423 -
  include/drm/i915_component.h   |   3 +
  6 files changed, 441 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7de90701f6f1..9c4218b5d153 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -904,6 +904,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv)
mutex_init(_priv->av_mutex);
mutex_init(_priv->wm.wm_mutex);
mutex_init(_priv->pps_mutex);
+   mutex_init(_priv->hdcp_comp_mutex);
  
  	i915_memcpy_init_early(dev_priv);

intel_runtime_pm_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a2293152cb6a..e3d030b73b5b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "i915_fixed.h"

  #include "i915_params.h"
@@ -2043,6 +2044,12 @@ struct drm_i915_private {
  
  	struct i915_pmu pmu;
  
+	struct i915_hdcp_comp_master *hdcp_master;

+   bool hdcp_comp_added;
+
+   /* Mutex to protect the above hdcp component related values. */
+   struct mutex hdcp_comp_mutex;
+
/*
 * 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_connector.c 
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758747c5..66ed3ee5998a 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -88,6 +88,8 @@ void intel_connector_destroy(struct drm_connector *connector)
  
  	kfree(intel_connector->detect_edid);
  
+	intel_hdcp_cleanup(intel_connector);

+
if (!IS_ERR_OR_NULL(intel_connector->edid))
kfree(intel_connector->edid);
  
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h

index 030d962697dd..b5c54c688256 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -41,6 +41,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  struct drm_printer;

@@ -385,6 +386,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 {

@@ -405,6 +409,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 {

@@ -2070,6 +2075,7 @@ 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);
+void intel_hdcp_cleanup(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 7b1097d79fb8..79f8979b9150 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -7,8 +7,10 @@
   */
  
  #include 

+#include 
  #include 
  #include 
+#include 
  
  #include "intel_drv.h"

  #include "i915_reg.h"
@@ -832,6 +834,360 @@ 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 

Re: [Intel-gfx] [PATCH v11 39/42] misc/mei/hdcp: Component framework for I915 Interface

[C, Ramalingam]

> -Original Message-
> From: Winkler, Tomas
> Sent: Friday, February 8, 2019 3:42 AM
> To: C, Ramalingam ; intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Shankar, Uma
> 
> Subject: RE: [PATCH v11 39/42] 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.
> > v8:
> >   master comp is added to be matched with i915 subcomponent [daniel]
> > v9:
> >   only comp_master is set and retrieved as driver_data [Daniel]
> >   Reviewed-by Daniel.
> >
> > Signed-off-by: Ramalingam C 
> > Reviewed-by: Daniel Vetter 
> > ---
> >  drivers/misc/mei/hdcp/mei_hdcp.c | 83
> > +++-
> >  1 file changed, 81 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > b/drivers/misc/mei/hdcp/mei_hdcp.c
> > index 615eed149837..beba6fb4d2e2 100644
> > --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > @@ -23,6 +23,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include  @@ -706,8 +707,7 @@
> > mei_hdcp_close_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_hdcp_initiate_session,
> > .verify_receiver_cert_prepare_km =
> > @@ -724,20 +724,99 @@ struct i915_hdcp_component_ops mei_hdcp_ops =
> {
> > .close_hdcp_session = mei_hdcp_close_session,  };
> >
> > +static int mei_component_master_bind(struct device *dev) {
> > +   struct mei_cl_device *cldev = to_mei_cl_device(dev);
> > +   struct i915_hdcp_comp_master *comp_master =
> > +
> > mei_cldev_get_drvdata(cldev);
> > +   int ret;
> > +
> > +   dev_info(dev, "%s\n", __func__);
> > +   comp_master->ops = _hdcp_ops;
> > +   comp_master->mei_dev = dev;
> > +   ret = component_bind_all(dev, comp_master);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   return 0;
> > +}
> > +
> > +static void mei_component_master_unbind(struct device *dev) {
> > +   struct mei_cl_device *cldev = to_mei_cl_device(dev);
> > +   struct i915_hdcp_comp_master *comp_master =
> > +
> > mei_cldev_get_drvdata(cldev);
> > +
> > +   dev_info(dev, "%s\n", __func__);
> > +   component_unbind_all(dev, comp_master); }
> > +
> > +static const struct component_master_ops mei_component_master_ops = {
> > +   .bind = mei_component_master_bind,
> > +   .unbind = mei_component_master_unbind, };
> > +
> > +static int mei_hdcp_component_match(struct device *dev, int
> subcomponent,
> > +   void *data)
> > +{
> > +   return !strcmp(dev->driver->name, "i915") &&
> > +  subcomponent == I915_COMPONENT_HDCP; }
> > +
> >  static int mei_hdcp_probe(struct mei_cl_device *cldev,
> >   const struct mei_cl_device_id *id)  {
> > +   struct i915_hdcp_comp_master *comp_master;
> > +   struct component_match *master_match;
> > int ret;
> >
> > ret = mei_cldev_enable(cldev);
> > if (ret < 0)
> > dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
> >
> > +   comp_master = kzalloc(sizeof(*comp_master), GFP_KERNEL);
> > +   if (!comp_master) {
> > +   ret = -ENOMEM;
> > +   goto comp_master_exit;
> > +   }
> > +
> > +   master_match = NULL;
> > +   component_match_add_typed(>dev, _match,
> > + mei_hdcp_component_match,
> > comp_master);
> > +   if (IS_ERR_OR_NULL(master_matc

Re: [Intel-gfx] [PATCH v11 28/42] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

[C, Ramalingam]

> -Original Message-
> From: Winkler, Tomas
> Sent: Friday, February 8, 2019 3:05 AM
> To: C, Ramalingam ; intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Shankar, Uma
> 
> Subject: RE: [PATCH v11 28/42] 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.
> > v9:
> >   s/mei_hdcp_ddi/mei_fw_ddi
> >   s/i915_port/mei_i915_port [Tomas]
> >   renamed func as mei_hdcp_* [Tomas]
> >   Instead of macro, inline func for ddi index is used. [Tomas]
> >
> > Signed-off-by: Ramalingam C 
> > Reviewed-by: Uma Shankar 
> > ---
> >  drivers/misc/mei/hdcp/mei_hdcp.c | 89
> > 
> >  drivers/misc/mei/hdcp/mei_hdcp.h | 23 +++
> >  2 files changed, 112 insertions(+)
> >
> > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > b/drivers/misc/mei/hdcp/mei_hdcp.c
> > index b8580b91e255..77dda13fcc88 100644
> > --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > @@ -23,6 +23,95 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "mei_hdcp.h"
> > +
> > +static inline u8 mei_get_ddi_index(short int port) {
> > +   enum mei_i915_port i915_port = (enum mei_i915_port)port;
> > +
> > +   return (u8)(i915_port == PORT_A ? MEI_DDI_A : i915_port); }
> 
> This translations from enum port to short int, than to eum mei_i915_port  and
> then to u8 bothers me.
> Should be a cleaner
> Maybe it's a bit overhead but it will be much more readlbe if we do switch
> statement here:
> 
>  switch (port)
> {
>   case PORT_A:
>   return MEI_DDI_A:
>   case PORT_B:
>   return MEI_DDI_B
> etc.
>   case: I915_MAX_PORTS
> default:
>  MEI_DDI_INVALID_PORT
> }
> Otherwise looks good to me.

Only one value differs by value that is PORTA. All other input and output 
values are same.
In this situation switch will be overkill. Let me know if you still insist.

-Ram
> 
> > +
> > +/**
> > + * mei_hdcp_initiate_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_hdcp_initiate_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 = mei_get_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) {
> >

Re: [Intel-gfx] [PATCH v11 07/42] drm/i915: Initialize HDCP2.2

[C, Ramalingam]

On 2/7/2019 8:43 PM, Winkler, Tomas wrote:

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.
v10:
   bool is used in struct to make coding simpler. [Daniel]
   hdmi hdcp init is placed correctly after encoder attachment.
v11:
   hdcp2_capability check is moved into hdcp.c [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
Reviewed-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_drv.h  | 11 +++
drivers/gpu/drm/i915/intel_hdcp.c | 28 ++--
drivers/gpu/drm/i915/intel_hdmi.c |  6 +++---
  3 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 90ba5436370e..030d962697dd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -394,6 +394,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. */
+   bool hdcp2_supported;
+
+   /*
+* Content Stream Type defined by content owner. TYPE0(0x0) content
can
+* flow in the link protected by HDCP2.2 or HDCP1.4, where as
TYPE1(0x1)
+* content can flow only through a link protected by HDCP2.2.
+*/
+   u8 content_type;
  };

  struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 8cb85b07cfde..7b1097d79fb8 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -832,14 +832,34 @@ bool is_hdcp_supported(struct drm_i915_private
*dev_priv, enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;  }

+static bool is_hdcp2_supported(struct drm_i915_private *dev_priv) {
+   if (!IS_ENABLED(CONFIG_INTEL_MEI_HDCP))
+   return false;

Is this enough, you can have SKU where this is not enabled, and you can detect 
that only during runtime.
Best approach will be failing the HDCP2.2 support for such SKUs. But at 
present I am not aware of any. If there is any we can always add here.


In the absence of the details about SKU with no HDCP support, even 
though init will assume

the HDCP2.2 support based on the MEI_HDCP config variable,
    mei_dev with UUID wont be available hence driver-device bind wont 
occur hence I915-MEI interface will never be complete and/or

    HDCP2_CMDs passed from mei_hdcp to MEI_FW will fail.
Hence HDCP2.2 will not attempted/succeed from I915.

Basically nothing will blow up here.

+
+   return (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
+   IS_KABYLAKE(dev_priv));
+}
+
+static void intel_hdcp2_init(struct intel_connector *connector) {
+   struct intel_hdcp *hdcp = >hdcp;
+
+   /* TODO: MEI interface needs to be initialized here */
+   hdcp->hdcp2_supported = true;
+}
+
  int intel_hdcp_init(struct intel_connector *connector,
const struct intel_hdcp_shim *shim)  {
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
int ret;

-   ret = drm_connector_attach_content_protection_property(
-   >base);
+   if (!shim)
+   return -EINVAL;
+
+   ret =
+drm_connector_attach_content_protection_property(>base);
if (ret)
return ret;

@@ -847,6 +867,10 @@ int intel_hdcp_init(struct intel_connector *connector,
mutex_init(>mutex);
INIT_DELAYED_WORK(>check_work, intel_hdcp_check_work);
INIT_WORK(>prop_work, intel_hdcp_prop_work);
+
+   if (is_hdcp2_supported(dev_priv))
+   intel_hdcp2_init(connector);
+
return 0;
  }

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index f125a62eba8c..faeedf76db99 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2427,6 +2427,9 @@ void intel_hdmi_init_connector(struct
intel_digital_port *intel_dig_port,

intel_hdmi_add_properties(intel_hdmi, connector);

+   

Re: [Intel-gfx] [PATCH v11 24/42] mei: me: add ice lake point device ids

[C, Ramalingam]

Sure. Intention was enabling the HDCP2.2 testing on CI for ICL. I will drop 
this patch, instead I will cherry-pick the one you have published for other 
branch.


Best Regards,
Ramalingam C


> -Original Message-
> From: Winkler, Tomas
> Sent: Thursday, February 7, 2019 12:47 PM
> To: C, Ramalingam ; intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Shankar, Uma
> 
> Subject: RE: [PATCH v11 24/42] mei: me: add ice lake point device ids
> 
> 
> >
> > From: Tomas Winkler 
> >
> > Add icelake device ids: ICP LP, N and H
> >
> > Signed-off-by: Tomas Winkler 
> NACK, this goes via mei driver submission process.
> Please drop it from the series.
> 
> > ---
> >  drivers/misc/mei/hw-me-regs.h | 4 
> >  drivers/misc/mei/pci-me.c | 4 
> >  2 files changed, 8 insertions(+)
> >
> > diff --git a/drivers/misc/mei/hw-me-regs.h
> > b/drivers/misc/mei/hw-me-regs.h index 23739a60517f..086e557c2872
> > 100644
> > --- a/drivers/misc/mei/hw-me-regs.h
> > +++ b/drivers/misc/mei/hw-me-regs.h
> > @@ -139,6 +139,10 @@
> >  #define MEI_DEV_ID_CNP_H  0xA360  /* Cannon Point H */
> >  #define MEI_DEV_ID_CNP_H_40xA364  /* Cannon Point H 4 (iTouch) */
> >
> > +#define MEI_DEV_ID_ICP_LP 0x34E0  /* Ice Lake Point LP */
> > +#define MEI_DEV_ID_ICP_N  0x38E0  /* Ice Lake Point N */
> > +#define MEI_DEV_ID_ICP_H  0x3DE0  /* Ice Lake Point H */
> > +
> >  /*
> >   * MEI HW Section
> >   */
> > diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
> > index
> > e89497f858ae..5ed5d28e6fe2 100644
> > --- a/drivers/misc/mei/pci-me.c
> > +++ b/drivers/misc/mei/pci-me.c
> > @@ -105,6 +105,10 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
> > {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH12_CFG)},
> > {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H_4, MEI_ME_PCH8_CFG)},
> >
> > +   {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP, MEI_ME_PCH12_CFG)},
> > +   {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_N, MEI_ME_PCH12_CFG)},
> > +   {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_H, MEI_ME_PCH12_CFG)},
> > +
> > /* required last entry */
> > {0, }
> >  };
> > --
> > 2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v11 08/42] drm/i915: MEI interface definition

[C, Ramalingam]

Daniel,

Due to significant changes @unbind and cleanup, i have dropped your r-b. 
Please review it again.


--Ram

On 2/7/2019 2:33 AM, Ramalingam C wrote:

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]
v4:
   port initialization is done only at hdcp2_init only [Danvet]
v5:
   I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
v6:
   HDCP_disable for all connectors incase of comp_unbind.
   Tear down HDCP comp interface at i915_unload [Daniel]

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/i915_drv.c|   1 +
  drivers/gpu/drm/i915/i915_drv.h|   7 +
  drivers/gpu/drm/i915/intel_connector.c |   2 +
  drivers/gpu/drm/i915/intel_drv.h   |   6 +
  drivers/gpu/drm/i915/intel_hdcp.c  | 423 -
  include/drm/i915_component.h   |   3 +
  6 files changed, 441 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7de90701f6f1..9c4218b5d153 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -904,6 +904,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv)
mutex_init(_priv->av_mutex);
mutex_init(_priv->wm.wm_mutex);
mutex_init(_priv->pps_mutex);
+   mutex_init(_priv->hdcp_comp_mutex);
  
  	i915_memcpy_init_early(dev_priv);

intel_runtime_pm_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a2293152cb6a..e3d030b73b5b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "i915_fixed.h"

  #include "i915_params.h"
@@ -2043,6 +2044,12 @@ struct drm_i915_private {
  
  	struct i915_pmu pmu;
  
+	struct i915_hdcp_comp_master *hdcp_master;

+   bool hdcp_comp_added;
+
+   /* Mutex to protect the above hdcp component related values. */
+   struct mutex hdcp_comp_mutex;
+
/*
 * 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_connector.c 
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758747c5..66ed3ee5998a 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -88,6 +88,8 @@ void intel_connector_destroy(struct drm_connector *connector)
  
  	kfree(intel_connector->detect_edid);
  
+	intel_hdcp_cleanup(intel_connector);

+
if (!IS_ERR_OR_NULL(intel_connector->edid))
kfree(intel_connector->edid);
  
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h

index 030d962697dd..b5c54c688256 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -41,6 +41,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  struct drm_printer;

@@ -385,6 +386,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 {

@@ -405,6 +409,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 {

@@ -2070,6 +2075,7 @@ 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);
+void intel_hdcp_cleanup(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 7b1097d79fb8..79f8979b9150 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -7,8 +7,10 @@
   */
  
  #include 

+#include 
  #include 
  #include 
+#include 
  
  #include "intel_drv.h"

  #include "i915_reg.h"
@@ -832,6 +834,360 @@ 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,
+

Re: [Intel-gfx] [PATCH] drm/i915: HDCP state handling in ddi_update_pipe

[C, Ramalingam]

Daniel,

Could we process this for merger? Or anything is pending from myside?

--Ram

On 2/4/2019 9:14 PM, Ramalingam C wrote:

The downgrade of the fullmodeset into fastset
intel_encoder->update_pipe, in possible scenario, skips the En/Dis-able
DDI. Hence breaks the HDCP state change handling.

We also don't have any hdcp tests in CI, because the shard runs don't
have hdcp capable outputs :-/

So this change fixs it by handling the HDCP state change request at
intel_encoder->update_pipe too along with enable and disable of the DDI.

Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")

v2:
   Added commit id that broke the HDCP [Daniel]

Signed-off-by: Ramalingam C 
cc: Maarten Lankhorst 
cc: Hans de Goede 
cc: Daniel Vetter 
---
  drivers/gpu/drm/i915/intel_ddi.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ca705546a0ab..2323b7cb1d38 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3568,6 +3568,13 @@ static void intel_ddi_update_pipe(struct intel_encoder 
*encoder,
  {
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+
+   if (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_DESIRED)
+   intel_hdcp_enable(to_intel_connector(conn_state->connector));
+   else if (conn_state->content_protection ==
+DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   intel_hdcp_disable(to_intel_connector(conn_state->connector));
  }
  
  static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 25/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

[C, Ramalingam]

On 2/6/2019 3:57 PM, Winkler, Tomas wrote:

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 

Latest set look ok. You can keep the RB.


---
drivers/misc/mei/hdcp/mei_hdcp.c | 82

drivers/misc/mei/hdcp/mei_hdcp.h | 28 ++
2 files changed, 110 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index ca5010ad7dd7..534d29c8ee86 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,6 +23,88 @@
#include 
#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) {


Breaking naming conventions : all functions should be prefixed with mei_hdcp_

e.g. mei_hdcp_ initiate_session()


+   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 582a7e27ae29..f831db3cbd54 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 {

We've already reviewed. Move to i915 

Re: [Intel-gfx] [PATCH v10 25/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

[C, Ramalingam]

Thanks Tomas.

On 2/5/2019 6:39 PM, Winkler, Tomas wrote:

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 

Latest set look ok. You can keep the RB.


---
drivers/misc/mei/hdcp/mei_hdcp.c | 82

drivers/misc/mei/hdcp/mei_hdcp.h | 28 ++
2 files changed, 110 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index ca5010ad7dd7..534d29c8ee86 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,6 +23,88 @@
#include 
#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) {


Breaking naming conventions : all functions should be prefixed with mei_hdcp_

e.g. mei_hdcp_ initiate_session()

I will rename all the function name similarly.

--Ram



+   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 582a7e27ae29..f831db3cbd54 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 = 

Re: [Intel-gfx] [PATCH] drm/i915: HDCP state handling in ddi_update_pipe

[C, Ramalingam]

On 2/4/2019 10:34 PM, Maarten Lankhorst wrote:

Op 04-02-2019 om 17:51 schreef C, Ramalingam:


On 2/4/2019 10:13 PM, Maarten Lankhorst wrote:

Op 04-02-2019 om 16:44 schreef Ramalingam C:

The downgrade of the fullmodeset into fastset
intel_encoder->update_pipe, in possible scenario, skips the En/Dis-able
DDI. Hence breaks the HDCP state change handling.

We also don't have any hdcp tests in CI, because the shard runs don't
have hdcp capable outputs :-/

So this change fixs it by handling the HDCP state change request at
intel_encoder->update_pipe too along with enable and disable of the DDI.

Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")

v2:
    Added commit id that broke the HDCP [Daniel]

Signed-off-by: Ramalingam C 
cc: Maarten Lankhorst 
cc: Hans de Goede 
cc: Daniel Vetter 
---
   drivers/gpu/drm/i915/intel_ddi.c | 7 +++
   1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ca705546a0ab..2323b7cb1d38 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3568,6 +3568,13 @@ static void intel_ddi_update_pipe(struct intel_encoder 
*encoder,
   {
   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
   intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+
+    if (conn_state->content_protection ==
+    DRM_MODE_CONTENT_PROTECTION_DESIRED)
+    intel_hdcp_enable(to_intel_connector(conn_state->connector));
+    else if (conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+    intel_hdcp_disable(to_intel_connector(conn_state->connector));
   }
     static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,

Does anything bad happen if we enable HDCP when it's already enabled? Might 
want to have a test for that. :)

nothing will happen. intel_hdcp_atomic_check will prune the request. 
mode_changed is not set in such case.

There are other reasons than HDCP that could cause fastsets, so what happens if 
update_pipe is called and content protection stays the same?

If the HDCP is enabled we dont trigger the HDCP_enable from the fastset.
But if the HDCP is failed every fastset will be triggering the HDCP 
enable. But that is the expectation. If user dont want further attempt 
on hdcp auth, user will set it to undesired.


--Ram


~Maarten



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: HDCP state handling in ddi_update_pipe

[C, Ramalingam]

On 2/4/2019 10:13 PM, Maarten Lankhorst wrote:

Op 04-02-2019 om 16:44 schreef Ramalingam C:

The downgrade of the fullmodeset into fastset
intel_encoder->update_pipe, in possible scenario, skips the En/Dis-able
DDI. Hence breaks the HDCP state change handling.

We also don't have any hdcp tests in CI, because the shard runs don't
have hdcp capable outputs :-/

So this change fixs it by handling the HDCP state change request at
intel_encoder->update_pipe too along with enable and disable of the DDI.

Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")

v2:
   Added commit id that broke the HDCP [Daniel]

Signed-off-by: Ramalingam C 
cc: Maarten Lankhorst 
cc: Hans de Goede 
cc: Daniel Vetter 
---
  drivers/gpu/drm/i915/intel_ddi.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ca705546a0ab..2323b7cb1d38 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3568,6 +3568,13 @@ static void intel_ddi_update_pipe(struct intel_encoder 
*encoder,
  {
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+
+   if (conn_state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_DESIRED)
+   intel_hdcp_enable(to_intel_connector(conn_state->connector));
+   else if (conn_state->content_protection ==
+DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   intel_hdcp_disable(to_intel_connector(conn_state->connector));
  }
  
  static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,

Does anything bad happen if we enable HDCP when it's already enabled? Might 
want to have a test for that. :)
nothing will happen. intel_hdcp_atomic_check will prune the request. 
mode_changed is not set in such case.


--Ram


~Maarten



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 20/40] drm/i915: Add HDCP2.2 support for HDMI connectors

[C, Ramalingam]

On 2/4/2019 9:34 PM, Winkler, Tomas wrote:

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 3b4fe7048af9..2c4bf6d0c39f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2621,7 +2621,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));

intel_hdcp_init is always called with is_hdcp2_supported() both for DP and 
HDMI, so you can just remove the argument it's redundant.

Thanks for the review Tomas.
Sure. That will reduce a parameter in hdcp_init.

--Ram



if (is_hdcp2_supported())
  intel_hdcp2_init(connector);

They are both defied in intel_hdcp.c.

Thanks
Tomas



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 38/40] drm/i915: Fix KBL HDCP2.2 encrypt status signalling

[C, Ramalingam]

daniel,

Could you please review this patch too.? Already Updated this as per 
your previous review comment.


--Ram

On 1/31/2019 12:29 PM, Ramalingam C wrote:

Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.

v2:
   WA is moved into the toggle_signalling [Daniel]

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_hdmi.c | 42 +++
  1 file changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2c4bf6d0c39f..ae20288f7bbf 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1083,10 +1083,44 @@ int intel_hdmi_hdcp_read_v_prime_part(struct 
intel_digital_port *intel_dig_port,
return ret;
  }
  
+static int 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 drm_crtc *crtc = connector->base.state->crtc;
+   struct intel_crtc *intel_crtc = container_of(crtc,
+struct intel_crtc, base);
+   u32 scanline;
+   int ret;
+
+   for (;;) {
+   scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
+   if (scanline > 100 && scanline < 200)
+   break;
+   usleep_range(25, 50);
+   }
+
+   ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, false);
+   if (ret) {
+   DRM_ERROR("Disable HDCP signalling failed (%d)\n", ret);
+   return ret;
+   }
+   ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, true);
+   if (ret) {
+   DRM_ERROR("Enable HDCP signalling failed (%d)\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
  static
  int intel_hdmi_hdcp_toggle_signalling(struct intel_digital_port 
*intel_dig_port,
  bool enable)
  {
+   struct intel_hdmi *hdmi = _dig_port->hdmi;
+   struct intel_connector *connector = hdmi->attached_connector;
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
int ret;
  
  	if (!enable)

@@ -1098,6 +1132,14 @@ int intel_hdmi_hdcp_toggle_signalling(struct 
intel_digital_port *intel_dig_port,
  enable ? "Enable" : "Disable", ret);
return ret;
}
+
+   /*
+* WA: To fix incorrect positioning of the window of
+* opportunity and enc_en signalling in KABYLAKE.
+*/
+   if (IS_KABYLAKE(dev_priv) && enable)
+   return kbl_repositioning_enc_en_signal(connector);
+
return 0;
  }
  


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 12/40] drm: HDCP2.2 link check period

[C, Ramalingam]

On 2/4/2019 7:54 PM, Shankar, Uma wrote:



-Original Message-
From: C, Ramalingam
Sent: Thursday, January 31, 2019 12:29 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
Uma 
Cc: C, Ramalingam 
Subject: [PATCH v10 12/40] drm: HDCP2.2 link check period

Time period for HDCP2.2 link check.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 

Not sure if we need a separate patch for this. Could be merged where check_link 
is
introduced for hdcp2.2.

If there is a valid reasoning, no hard objection and it looks ok in general. So
drm level change is convenient to have in separate patch to get approval 
from dri-devel.


--Ram


Reviewed-by: Uma Shankar 


---
include/drm/drm_hdcp.h | 1 +
1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
7260b31af276..d4e98b11b4aa 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -13,6 +13,7 @@

/* 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

/* Shared lengths/masks between HDMI/DVI/DisplayPort */
#define DRM_HDCP_AN_LEN 8
--
2.7.4


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 07/40] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking

[C, Ramalingam]

On 2/4/2019 7:39 PM, Shankar, Uma wrote:



-Original Message-
From: C, Ramalingam
Sent: Thursday, January 31, 2019 12:29 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
Uma 
Cc: C, Ramalingam 
Subject: [PATCH v10 07/40] 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.

v2:
  bool is used in struct for the cleaner coding. [Daniel]
  check_link work_fn is scheduled for cp_irq handling [Daniel]

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 |
73 ---
3 files changed, 58 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 815ee68efa2f..9ce05819fc11 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4776,7 +4776,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 63e009286d5f..13a41e8cf4ff 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -399,6 +399,9 @@ struct intel_hdcp {
struct delayed_work check_work;
struct work_struct prop_work;

+   /* HDCP1.4 Encryption status */
+   bool hdcp_encrypted;
+
/* HDCP2.2 related definitions */
/* Flag indicates whether this connector supports HDCP2.2 or not. */
bool hdcp2_supported;
@@ -2073,10 +2076,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 e0bb5f32ba90..c1b057f1501b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -74,6 +74,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)  { @@ -
668,6 +678,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 = false;
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)) {
@@ -713,8 +724,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 = true;
return 0;
+   }

DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);

@@ -741,16 +754,17 @@ int intel_hdcp_check_link(struct intel_connector
*connector)
enum port port = intel_dig_port->base.port;
in

Re: [Intel-gfx] [PATCH v10 37/40] drm/i915: Commit CP without modeset

[C, Ramalingam]

Tomas,

On 1/31/2019 2:02 PM, Daniel Vetter wrote:

Also we need CI results without this patch so I can start merging. Rough
merge plan:
- needs ack to merge component.c through drm-intel
- merge all the i915 patches
- topic branch for mei, shared with mei subsystem

Is this convenient to you? Or you have any other suggestion?

--Ram

- make sure that CI has mei enabled and that tests aren't on fire
- merge this one here

Cheers, Daniel


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 07/40] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking

[C, Ramalingam]

On 1/31/2019 1:26 PM, Daniel Vetter wrote:

On Thu, Jan 31, 2019 at 12:29:23PM +0530, Ramalingam C wrote:

"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.

v2:
   bool is used in struct for the cleaner coding. [Daniel]
   check_link work_fn is scheduled for cp_irq handling [Daniel]

Just doing a delta-review, v2 addresses my comment about synchronization
with the worker, so

Reviewed-by: Daniel Vetter 

Thank you.

--Ram



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 | 73 ---
  3 files changed, 58 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 815ee68efa2f..9ce05819fc11 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4776,7 +4776,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 63e009286d5f..13a41e8cf4ff 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -399,6 +399,9 @@ struct intel_hdcp {
struct delayed_work check_work;
struct work_struct prop_work;
  
+	/* HDCP1.4 Encryption status */

+   bool hdcp_encrypted;
+
/* HDCP2.2 related definitions */
/* Flag indicates whether this connector supports HDCP2.2 or not. */
bool hdcp2_supported;
@@ -2073,10 +2076,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 e0bb5f32ba90..c1b057f1501b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -74,6 +74,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)
  {
@@ -668,6 +678,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 = false;

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)) {
@@ -713,8 +724,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 = true;
return 0;
+   }
  
  		DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
  
@@ -741,16 +754,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 

Re: [Intel-gfx] [PATCH v10 06/40] drm/i915: MEI interface definition

[C, Ramalingam]

On 1/31/2019 1:47 PM, Daniel Vetter wrote:

On Thu, Jan 31, 2019 at 12:29:22PM +0530, Ramalingam C wrote:

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]
v4:
   port initialization is done only at hdcp2_init only [Danvet]
v5:
   I915 registers a subcomponent to be matched with mei_hdcp [Daniel]

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 

When you make substantial changes to a patch (like here) and decide to
keep the r-b, then please indicate that it was for an earlier version. I
most definitely didn't review this one that re-adds all the locking :-)

sure :)


What's missing here is the component_del. Not exactly sure why this
doesn't blow up.
That is weird. But yes note the absence of _del. I will introduce the 
the call to hdcp_exit at unload and handle the component_del.

Luckily we don't need a component_del_typed because
component_del already takes the (dev, ops) pair, and that's unique.

yes true.

-Ram

-Daniel



---
  drivers/gpu/drm/i915/i915_drv.c   |   1 +
  drivers/gpu/drm/i915/i915_drv.h   |   7 +
  drivers/gpu/drm/i915/intel_drv.h  |   5 +
  drivers/gpu/drm/i915/intel_hdcp.c | 378 +-
  include/drm/i915_component.h  |   3 +
  5 files changed, 393 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7aaa1ac4c99..75aff907ba69 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -904,6 +904,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv)
mutex_init(_priv->av_mutex);
mutex_init(_priv->wm.wm_mutex);
mutex_init(_priv->pps_mutex);
+   mutex_init(_priv->hdcp_comp_mutex);
  
  	i915_memcpy_init_early(dev_priv);

intel_runtime_pm_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 22da9df1f0a7..d9a0771af4d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "i915_fixed.h"

  #include "i915_params.h"
@@ -2043,6 +2044,12 @@ struct drm_i915_private {
  
  	struct i915_pmu pmu;
  
+	struct i915_hdcp_comp_master *hdcp_master;

+   bool hdcp_comp_added;
+
+   /* Mutex to protect the above hdcp component related values. */
+   struct mutex hdcp_comp_mutex;
+
/*
 * 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 0ac870feb5e9..63e009286d5f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -41,6 +41,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  struct drm_printer;

@@ -385,6 +386,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 {

@@ -405,6 +409,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 1a85dc46692d..e0bb5f32ba90 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -7,8 +7,10 @@
   */
  
  #include 

+#include 
  #include 
  #include 
+#include 
  
  #include "intel_drv.h"

  #include "i915_reg.h"
@@ -832,6 +834,348 @@ 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_hdcp_comp_master *comp;
+   int ret;
+
+   mutex_lock(_priv->hdcp_comp_mutex);
+   comp = dev_priv->hdcp_master;
+
+   if (!comp || !comp->ops) {
+   mutex_unlock(_priv->hdcp_comp_mutex);
+   return -EINVAL;
+   }
+
+   ret = comp->ops->initiate_hdcp2_session(comp->mei_dev, data, ake_data);
+   if 

Re: [Intel-gfx] [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface

[C, Ramalingam]

On 12/20/2018 9:36 PM, Winkler, Tomas wrote:

+static void __exit mei_hdcp_exit(void)
+{
+   mei_hdcp_component_cleanup(>dev);
Don’t think you can do that,  no guarantees this will be valid pointer


As we discussed offline, we have the below line at cleanup.
So valid pointer is made sure. I will protect init and cleanup with mutex too.

+static void mei_hdcp_component_cleanup(struct device *dev)
+{
+   if (!mei_hdcp_component_registered)
+   return;

-Ram


+   mei_cldev_driver_unregister(mei_hdcp_driver);
+}
+
+module_init(mei_hdcp_init);
+module_exit(mei_hdcp_exit);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface

[C, Ramalingam]

On 12/19/2018 12:15 PM, C, Ramalingam wrote:

Tomas and Daniel,

 From the discussion on this thread, I infer following understanding:

  * At present(v9) I915 wants to be hard binded to mei_hdcp
device-driver binding status through components
  o This means I915 driver load will get complete only when the
mei_hdcp's device and driver are bound.
  o if mei_hdcp device reset I915 will unregister itself from
userspace, and wait for the mei_hdcp device-deriver rebinding.
  + Could be due to FW error or any unexpected failures those
are rare occurances.
  o when mei_hdcp module is removed i915 will unregister itself.
  o Becasue of this, Ideally I915 dont expect the device reset
from mei for suspend and resume.
  * At present Mei bus is designed as below:
  o Device will disappear on FW failures, FW upgrade, suspend of
the system etc.
  o And when the errors are handled or on system resume mei device
will reappear, hence binding with corresponding driver.
  * Mei doesn't plan to avoid the device reset(disappearance and
reappearance) for suspend and resume in near future.

Based on above understanding, I propose the below approach. Please correct or 
approve it.

  * At present(v9) component_add from mei_hdcp indicates the
mei_hdcp's device-driver binded state.
  * Instead lets use component to indicate the mei_hdcp's module
availability,
  o by adding the component at module_init and removing it from
module_exit.
  * This way I915 will not be impacted due to the mei device reset at
suspend.
  * In such scenario I915 will have no idea about the device-driver
bind status of mei_hdcp.
  o So incase of device is not available, mei_hdcp is responsible
to prune such calls with -EIO error.
  * This approach avoid any future impact to I915, incase mei intended
to support suspend and resume.

I am aware this is not the ideal solution we want. But I feel this is the best 
at present we could do for this I915-mei interface.
Best regards,
Ram


something like (un compiled code)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b22a71e8c5d7..b5b57a883e3b 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,11 +23,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

 #include "mei_hdcp.h"

+struct i915_component_master *i915_master_comp;
+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 +695,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 +710,84 @@ 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;
+
+   i915_master_comp = master_comp;
+
+   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;
+   i915_master_comp = 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;
+
+   if (mei_hdcp_component_registered && i915_master_comp) {
+   i915_master_comp->mei_dev = dev;
+   return;
+   }
+
+   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");
+ 

Re: [Intel-gfx] [PATCH v9 07/39] drm/i915: MEI interface definition

[C, Ramalingam]

On 12/19/2018 8:51 PM, Daniel Vetter wrote:

Indeed, I overlooked that. Maybe highlight it a bit more with a separate

if (!CONFIG_ENABLED(MEI_HDCP))
return false;

so it stick out more in the previous patch. Currently it's a bit burried.

With that + the init ordering fixed:

Reviewed-by: Daniel Vetter


Sure. Thank you.



There's no need to split the patch out anymore, since without the mei
patches you can't enable that Kconfig option and hence no bisect issues.


Still Kconfig and makefile is added at 22nd patch but component support in 
mei_hdcp is added at 35th patch.
So even now this chunk needs to be kept after the component support addition.

-Ram



Cheers, Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 08/39] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking

[C, Ramalingam]

On 12/19/2018 9:18 PM, Daniel Vetter wrote:

On Thu, Dec 13, 2018 at 09:31:10AM +0530, Ramalingam C wrote:

"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;

Another bool I guess? Or unsigned : 1;

as per #intel-gfx discussion I will fallback to bool.



+
/* 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;
+ 

Re: [Intel-gfx] [PATCH v9 13/39] drm: HDCP2.2 link check related constants

[C, Ramalingam]

On 12/19/2018 10:05 PM, Daniel Vetter wrote:

On Wed, Dec 19, 2018 at 5:22 PM C, Ramalingam  wrote:


On 12/19/2018 9:28 PM, Daniel Vetter wrote:

On Wed, Dec 19, 2018 at 09:09:00PM +0530, C, Ramalingam wrote:

On 12/19/2018 8:46 PM, Daniel Vetter wrote:

On Thu, Dec 13, 2018 at 09:31:15AM +0530, Ramalingam C wrote:

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

This one here is good imo, and has my Reviewed-by: Daniel Vetter 



+
+enum check_link_response {
+  DRM_HDCP_LINK_PROTECTED = 0,
+  DRM_HDCP_TOPOLOGY_CHANGE,
+  DRM_HDCP_LINK_INTEGRITY_FAILURE,
+  DRM_HDCP_REAUTH_REQUEST
+};

But this one here is just a part of the intel_hdcp_shim interface. I think
we should put into the intel_drv.h header, and change the return value of
the check_2_2_link hook to this enum. I think that would clarify the code
a lot. Plus then ofc merge this part into the first patch that uses it.

daniel,

this is generic link check results as per the HDCP spec. This could be used
by any other driver in DRM. Still should i move as local to intel?

Yeah I think makes more sense. intel_hdcp_shim could also be used as
fairly generic hdcp implementation, but right now it isn't. Better to keep
things together that are used together.

thanks. With this i will use your R-b ?

Just to clarify: R-b with the enum moved to intel_drv.h, together with
the intel_hdcp_shim using it. Just realized that my reply is a bit
confusing.


True. I thought you didn't suggest any change :) I will do that the 
changes mentioned.


-Ram


-Daniel


-Ram


-Daniel


-Ram


With that remaining patches have my ack, too.

Cheers, Daniel


/* Shared lengths/masks between HDMI/DVI/DisplayPort */
#define DRM_HDCP_AN_LEN 8
--
2.7.4





___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 13/39] drm: HDCP2.2 link check related constants

[C, Ramalingam]

On 12/19/2018 9:28 PM, Daniel Vetter wrote:

On Wed, Dec 19, 2018 at 09:09:00PM +0530, C, Ramalingam wrote:

On 12/19/2018 8:46 PM, Daniel Vetter wrote:

On Thu, Dec 13, 2018 at 09:31:15AM +0530, Ramalingam C wrote:

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

This one here is good imo, and has my Reviewed-by: Daniel Vetter 



+
+enum check_link_response {
+   DRM_HDCP_LINK_PROTECTED = 0,
+   DRM_HDCP_TOPOLOGY_CHANGE,
+   DRM_HDCP_LINK_INTEGRITY_FAILURE,
+   DRM_HDCP_REAUTH_REQUEST
+};

But this one here is just a part of the intel_hdcp_shim interface. I think
we should put into the intel_drv.h header, and change the return value of
the check_2_2_link hook to this enum. I think that would clarify the code
a lot. Plus then ofc merge this part into the first patch that uses it.

daniel,

this is generic link check results as per the HDCP spec. This could be used
by any other driver in DRM. Still should i move as local to intel?

Yeah I think makes more sense. intel_hdcp_shim could also be used as
fairly generic hdcp implementation, but right now it isn't. Better to keep
things together that are used together.


thanks. With this i will use your R-b ?

-Ram


-Daniel


-Ram


With that remaining patches have my ack, too.

Cheers, Daniel


   /* Shared lengths/masks between HDMI/DVI/DisplayPort */
   #define DRM_HDCP_AN_LEN  8
--
2.7.4


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 37/39] drm/i915: Fix KBL HDCP2.2 encrypt status signalling

[C, Ramalingam]

On 12/19/2018 9:10 PM, Daniel Vetter wrote:

On Thu, Dec 13, 2018 at 09:31:39AM +0530, Ramalingam C wrote:

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_CNT3
  
+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);

This is a bit a layering violation of the shim. I think it'd be better to
push this into the toggle_signalling implementation, which you call right
above. That can easily check this register too, and retry. That way the
kbl flow is all in one place.


Yes, any way this is a fix for hdcp_signalling for kbl. I will do that.

-Ram



Bspec is down for me, so can't check the w/a itself :-(
-Daniel


+
/* 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

Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication

[C, Ramalingam]

On 12/19/2018 9:05 PM, Daniel Vetter wrote:

On Wed, Dec 19, 2018 at 08:35:48PM +0530, C, Ramalingam wrote:

On 12/19/2018 8:05 PM, Daniel Vetter wrote:

On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:

+   if (!hdcp->is_repeater && shim->config_stream_type) {
+   /*
+* Errata for DP: As Stream type is used for encryption,
+* Receiver should be communicated with stream type for the
+* decryption of the content.
+* Repeater will be communicated with stream type as a
+* part of it's auth later in time.
+*/

I'm not following what you want to say with this comment, and haven't
found anything in the hdcp2 dp spec about this either.

this is there in the errata of DP HDCP2.2 spec.
hdcp2.2 encryption algo involves the stream type as a parameter.
And as part of hdcp auth mentioned in base spec DP repeaters receive that 
details to decrypt the content.
But DP receivers dont get it. So errata adds the missing piece for decryption.

Ok I found it, but the fake HDCP_2_2_ERRATA_DP_STREAM_TYPE define is kinda
annoying. It doesn't exist in the spec, but we put it into the drm_hdcp.h
header. Since you have a special ->config_stream_type hook for this
anyway, and it's only needed for DP, please move that into the shim
implementation.

And then a follow-up patch to remove the fake #define from drm_hdcp.h.


This is defined to make the hdcp_shim interface to look common between DP and 
HDMI.
We can move this errata msg definition and its msg_id into intel_drv.h just for 
the intel's consumption.

-Ram


-Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 13/39] drm: HDCP2.2 link check related constants

[C, Ramalingam]

On 12/19/2018 8:46 PM, Daniel Vetter wrote:

On Thu, Dec 13, 2018 at 09:31:15AM +0530, Ramalingam C wrote:

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

This one here is good imo, and has my Reviewed-by: Daniel Vetter 



+
+enum check_link_response {
+   DRM_HDCP_LINK_PROTECTED = 0,
+   DRM_HDCP_TOPOLOGY_CHANGE,
+   DRM_HDCP_LINK_INTEGRITY_FAILURE,
+   DRM_HDCP_REAUTH_REQUEST
+};

But this one here is just a part of the intel_hdcp_shim interface. I think
we should put into the intel_drv.h header, and change the return value of
the check_2_2_link hook to this enum. I think that would clarify the code
a lot. Plus then ofc merge this part into the first patch that uses it.


daniel,

this is generic link check results as per the HDCP spec. This could be 
used by any other driver in DRM. Still should i move as local to intel?


-Ram



With that remaining patches have my ack, too.

Cheers, Daniel

  
  /* Shared lengths/masks between HDMI/DVI/DisplayPort */

  #define DRM_HDCP_AN_LEN   8
--
2.7.4


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 12/39] drm/i915: Implement HDCP2.2 repeater authentication

[C, Ramalingam]

On 12/19/2018 8:18 PM, Daniel Vetter wrote:

On Thu, Dec 13, 2018 at 09:31:14AM +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:
   -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;

There's a 2s timeout here that we're not checking, but again probably
follow-up patch.

Timeout is taken care at shim.



+
+   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 

Re: [Intel-gfx] [PATCH v9 07/39] drm/i915: MEI interface definition

[C, Ramalingam]

On 12/19/2018 7:30 PM, Daniel Vetter wrote:

On Thu, Dec 13, 2018 at 09:31:09AM +0530, Ramalingam C wrote:

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]

Yeah looks all good. Spotted some small stuff below still.


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;
+
+   

Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication

[C, Ramalingam]

On 12/19/2018 8:05 PM, Daniel Vetter wrote:

On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:

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;

Make these two bool, will simplify the code a bunch.


Seems there is a movement for not to use the bool in structures.
Thats why I have changed these from bool to u8 from v8 onwards. Checkpatch also 
complains on this




+
+   /*
+* 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,
@@ 

Re: [Intel-gfx] [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface

[C, Ramalingam]

Tomas and Daniel,

From the discussion on this thread, I infer following understanding:

 * At present(v9) I915 wants to be hard binded to mei_hdcp
   device-driver binding status through components
 o This means I915 driver load will get complete only when the
   mei_hdcp's device and driver are bound.
 o if mei_hdcp device reset I915 will unregister itself from
   userspace, and wait for the mei_hdcp device-deriver rebinding.
 + Could be due to FW error or any unexpected failures those
   are rare occurances.
 o when mei_hdcp module is removed i915 will unregister itself.
 o Becasue of this, Ideally I915 dont expect the device reset from
   mei for suspend and resume.
 * At present Mei bus is designed as below:
 o Device will disappear on FW failures, FW upgrade, suspend of the
   system etc.
 o And when the errors are handled or on system resume mei device
   will reappear, hence binding with corresponding driver.
 * Mei doesn't plan to avoid the device reset(disappearance and
   reappearance) for suspend and resume in near future.

Based on above understanding, I propose the below approach. Please correct or 
approve it.

 * At present(v9) component_add from mei_hdcp indicates the mei_hdcp's
   device-driver binded state.
 * Instead lets use component to indicate the mei_hdcp's module
   availability,
 o by adding the component at module_init and removing it from
   module_exit.
 * This way I915 will not be impacted due to the mei device reset at
   suspend.
 * In such scenario I915 will have no idea about the device-driver bind
   status of mei_hdcp.
 o So incase of device is not available, mei_hdcp is responsible to
   prune such calls with -EIO error.
 * This approach avoid any future impact to I915, incase mei intended
   to support suspend and resume.

I am aware this is not the ideal solution we want. But I feel this is the best 
at present we could do for this I915-mei interface.

Best regards,
Ram

On 12/17/2018 7:16 PM, Daniel Vetter wrote:

On Mon, Dec 17, 2018 at 11:57 AM Winkler, Tomas  wrote:



On Sat, Dec 15, 2018 at 09:20:38PM +, Winkler, Tomas wrote:

On Thu, Dec 13, 2018 at 5:27 PM Winkler, Tomas

wrote:

On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam

wrote:

Tomas and Daniel,

We got an issue here.

The relationship that we try to build between I915 and
mei_hdcp is as

follows:

We are using the components to establish the relationship.
I915 is component master where as mei_hdcp is component.
I915 adds the component master during the module load.
mei_hdcp adds the

component when the driver->probe is called (on device driver binding).

I915 forces itself such that until mei_hdcp component is added
I915_load

wont be complete.

Similarly on complete system, if mei_hdcp component is
removed,

immediately I915 unregister itself and HW will be shutdown.

This is completely fine when the modules are loaded and unloaded.

But during suspend, mei device disappears and mei bus handles
it by

unbinding device and driver by calling driver->remove.

This in-turn removes the component and triggers the master
unbind of I915

where, I915 unregister itself.

This cause the HW state mismatch during the suspend and resume.

Please check the powerwell mismatch errors at CI report for v9
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_3412/fi-glk-j4
005/
igt@
gem_exec_susp...@basic-s3.html

More over unregistering I915 during the suspend is not expected.
So how do

we handle this?

Bit more context from our irc discussion with Ram:

I found this very surprising, since I don't know of any other
subsystems where the devices get outright removed when going
through a

suspend/resume cycle.

The device model was built to handle this stuff
correctly: First clients/devices/interfaces get suspend, then
the parent/bridge/bus. Same dance in reverse when resuming. This
even holds for lots of hotpluggable buses, where child devices
could indeed disappear on resume, but as long as they don't,
everything stays the same. It's really surprising for something
that's soldered onto the

board like ME.

HDCP is an application in the ME it's not ME itself..  On the
linux side HDCP2 is a virtual device  on mei client virtual bus,
the bus  is teared

down on ME reset, which mostly happen  on power transitions.

Theoretically,  we could keep it up during power transitions, but
so fare it was not necessary and second it's not guarantie that
the all ME

applications will reappear after reset.

When does this happen that an ME application doesn't come back after e.g.
suspend/resume?

No, this can happen in special flows such as  fw updates and error conditions,

but is has to be supported as well.

Also, what's all the place where this reset can happen? Just
suspend/resume/hibernate and all these, or also at other times?

Also on errors and fw update,  the basic assumption is here that it can happen

any time.

If this can happen any time

Re: [Intel-gfx] [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface

[C, Ramalingam]

Tomas and Daniel,

We got an issue here.

The relationship that we try to build between I915 and mei_hdcp is as follows:

 * We are using the components to establish the relationship.
 * I915 is component master where as mei_hdcp is component.
 * I915 adds the component master during the module load. mei_hdcp adds
   the component when the driver->probe is called (on device driver
   binding).
 * I915 forces itself such that until mei_hdcp component is added
   I915_load wont be complete.
 * Similarly on complete system, if mei_hdcp component is removed,
   immediately I915 unregister itself and HW will be shutdown.

This is completely fine when the modules are loaded and unloaded.

But during suspend, mei device disappears and mei bus handles it by unbinding 
device and driver by calling driver->remove.
This in-turn removes the component and triggers the master unbind of I915 
where, I915 unregister itself.
This cause the HW state mismatch during the suspend and resume.

Please check the powerwell mismatch errors at CI report for v9
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_3412/fi-glk-j4005/igt@gem_exec_susp...@basic-s3.html

More over unregistering I915 during the suspend is not expected. So how do we 
handle this?

-Ram

On 12/13/2018 9:31 AM, Ramalingam C wrote:

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;
+   }
+   

Re: [Intel-gfx] [PATCH v9 01/39] drm/i915: Gathering the HDCP1.4 routines together

[C, Ramalingam]

On 12/13/2018 1:47 PM, Winkler, Tomas wrote:



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) {


Should be static


At this point in time, invoked from intel_dp.c. But at later part of
this series this function can be defined as static. Will do it then.

-Ram




+   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 

Re: [Intel-gfx] [PATCH v9 12/39] drm/i915: Implement HDCP2.2 repeater authentication

[C, Ramalingam]

On 12/13/2018 1:52 PM, Winkler, Tomas wrote:

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);

cpu_to_be16(1);


Sure. Tomas. That will suit better.
BTW, whether current mei- i915 interface suits to your preference?

Thanks
Ram


+
+   /* 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.
*/
+

Re: [Intel-gfx] [PATCH v8 05/35] drm/i915: MEI interface definition

[C, Ramalingam]

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

Re: [Intel-gfx] [PATCH v8 05/35] drm/i915: MEI interface definition

[C, Ramalingam]

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 v8 08/35] drm/i915: Implement HDCP2.2 repeater authentication

[C, Ramalingam]

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 v8 05/35] drm/i915: MEI interface definition

[C, Ramalingam]

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

Re: [Intel-gfx] [PATCH v8 03/35] linux/mei: Header for mei_hdcp driver interface

[C, Ramalingam]

Hi,

In one of the offline discussion Tomas has shared his review comments on v8.
So I am sharing the abstract of his suggestions here for the discussion and for 
the agreement of interface in the community.
Tomas please correct/add if I am missing any points.

1. Remove the include/linux/mei_hdcp.h to make the i915-mei interface
   more generic.
1. Move the definition of the struct mei_hdcp_data to i915 and
   mei_hdcp.c and pass the void* in the ops' functions.
2. Move the conversion of enum port value to mei_ddi_port value
   into mei_hdcp.c. Let I915 pass the enum port value as such.
3. Modified local definition of the struct mei_hdcp_data will looks
   like
4.

   +/* hdcp data per port */
   +struct hdcp_port_data {
   + short int port;
   + u8 port_type;
   + u8 protocol;
   + u16 k;
   + u32 seq_num_m;
   + struct hdcp2_streamid_type *streams;
 };

2. Add K-Doc compliant commenting in the mei_hdcp.c

I have implemented these changes and posted for intel-gfx-trybot. Just incase 
anyone wants to
refer the code please look at https://patchwork.freedesktop.org/series/53655/ .
Not shared on #intel-gfx as further review discussions are on-going on 
intel-gfx.

--Ram

On 11/27/2018 4:13 PM, Ramalingam C wrote:

Data structures and Enum for the I915-MEI_HDCP interface are defined
at 

v2:
   Rebased.
v3:
   mei_cl_device is removed from mei_hdcp_data [Tomas]
v4:
   Comment style and typo fixed [Uma]
v5:
   Rebased.
v6:
   No changes.
v7:
   Remove redundant text from the License header
   Change uintXX_t type to uXX_t types
   Remove unneeded include to mei_cl_bus.h
   Coding style fixed [Uma]
V8:
   Tab cleanup
   Fix kdoc and namespaces
   Update MAINTAINERS

Signed-off-by: Ramalingam C 
Signed-off-by: Tomas Winkler 
Reviewed-by: Uma Shankar 
---
  MAINTAINERS  |  1 +
  include/linux/mei_hdcp.h | 91 
  2 files changed, 92 insertions(+)
  create mode 100644 include/linux/mei_hdcp.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1026150ae90f..2fd6555bf040 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7540,6 +7540,7 @@ L:linux-ker...@vger.kernel.org
  S:Supported
  F:include/uapi/linux/mei.h
  F:include/linux/mei_cl_bus.h
+F: include/linux/mei_hdcp.h
  F:drivers/misc/mei/*
  F:drivers/watchdog/mei_wdt.c
  F:Documentation/misc-devices/mei/*
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
new file mode 100644
index ..716123003dd1
--- /dev/null
+++ b/include/linux/mei_hdcp.h
@@ -0,0 +1,91 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Authors:
+ * Ramalingam C 
+ */
+
+#ifndef _LINUX_MEI_HDCP_H
+#define _LINUX_MEI_HDCP_H
+
+/**
+ * enum mei_hdcp_ddi - The physical digital display interface (DDI)
+ * available on the platform
+ * @MEI_DDI_INVALID_PORT: Not a valid port
+ * @MEI_DDI_RANGE_BEGIN: Beginning of the valid DDI port range
+ * @MEI_DDI_B: Port DDI B
+ * @MEI_DDI_C: Port DDI C
+ * @MEI_DDI_D: Port DDI D
+ * @MEI_DDI_E: Port DDI E
+ * @MEI_DDI_F: Port DDI F
+ * @MEI_DDI_A: Port DDI A
+ * @MEI_DDI_RANGE_END: End of the valid DDI port range
+ */
+enum mei_hdcp_ddi {
+   MEI_DDI_INVALID_PORT = 0x00,
+
+   MEI_DDI_RANGE_BEGIN = 0x01,
+   MEI_DDI_B   = 0x01,
+   MEI_DDI_C   = 0x02,
+   MEI_DDI_D   = 0x03,
+   MEI_DDI_E   = 0x04,
+   MEI_DDI_F   = 0x05,
+   MEI_DDI_A   = 0x07,
+   MEI_DDI_RANGE_END   = MEI_DDI_A,
+};
+
+/**
+ * enum mei_hdcp_port_type - The types of HDCP 2.2 ports supported
+ *
+ * @MEI_HDCP_PORT_TYPE_INVALID: Invalid port
+ * @MEI_HDCP_PORT_TYPE_INTEGRATED: ports that are integrated into Intel HW
+ * @MEI_HDCP_PORT_TYPE_LSPCON: discrete wired Tx port with LSPCON (HDMI 2.0)
+ * @MEI_HDCP_PORT_TYPE_CPDP: discrete wired Tx port using the CPDP (DP 1.3)
+ */
+enum mei_hdcp_port_type {
+   MEI_HDCP_PORT_TYPE_INVALID= 0x00,
+   MEI_HDCP_PORT_TYPE_INTEGRATED = 0x01,
+   MEI_HDCP_PORT_TYPE_LSPCON = 0x02,
+   MEI_HDCP_PORT_TYPE_CPDP   = 0x03,
+};
+
+/*
+ * enum mei_hdcp_wired_protocol - Supported integrated wired HDCP protocol.
+ * @HDCP_PROTOCOL_INVALID: invalid type
+ * @HDCP_PROTOCOL_HDMI: HDMI
+ * @HDCP_PROTOCOL_DP: DP
+ *
+ * Based on this value, Minor difference needed between wired specifications
+ * are handled.
+ */
+enum mei_hdcp_wired_protocol {
+   MEI_HDCP_PROTOCOL_INVALID,
+   MEI_HDCP_PROTOCOL_HDMI,
+   MEI_HDCP_PROTOCOL_DP
+};
+
+/**
+ * struct mei_hdcp_data - Input data to the mei_hdcp APIs
+ * @port: The physical port (ddi).
+ * @port_type: The port type.
+ * @protocol: The Protocol on the port.
+ * @k: Number of streams transmitted on the port.
+ * In case of HDMI & DP SST, a single stream will be
+ * transmitted on the port.
+ * @seq_num_m: A sequence number of RepeaterAuth_Stream_Manage 

Re: [Intel-gfx] [PATCH v8 05/35] drm/i915: MEI interface definition

[C, Ramalingam]

On 12/7/2018 11:22 AM, 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.

  };
  
  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_CHANGE50
+#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 to be closed before restarting the auth on that port with 
initialite_hdcp_session.
If we are closing the hdcp session of the port on all auth errors, we dont need 
this just before
start of the hdcp session.

"Just in case" papering over programming bugs of our own just makes
debugging harder.


+
+   ret = comp->ops->

Re: [Intel-gfx] [PATCH v8 05/35] drm/i915: MEI interface definition

[C, Ramalingam]

On 12/7/2018 11:22 AM, 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.

  };
  
  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_CHANGE50
+#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 to be closed before restarting the auth on that port with 
initialite_hdcp_session.
If we are closing the hdcp session of the port on all auth errors, we dont need 
this just before
start of the hdcp session.

"Just in case" papering over programming bugs of our own just makes
debugging harder.


+
+   ret = comp->ops->

Re: [Intel-gfx] [PATCH v8 33/35] drm/i915: Fix KBL HDCP2.2 encrypt status signalling

[C, Ramalingam]

On 12/6/2018 7:50 PM, Daniel Vetter wrote:

On Tue, Nov 27, 2018 at 04:13:31PM +0530, Ramalingam C wrote:

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 9f4056e156ec..654a076c58e4 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"
@@ -24,6 +25,27 @@
__p == PORT_A ? MEI_DDI_A : (enum mei_hdcp_ddi)__p;\
  })
  
+static void kbl_repositioning_enc_en_signal(struct intel_connector *connector)

Is there a Bspec WA number/label so I can more easily find this?


Referenced in WAs #0889 and #0890

--Ram


-Daniel


+{
+   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)
  {
@@ -1527,6 +1549,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

Re: [Intel-gfx] [PATCH v8 09/35] drm/i915: Implement HDCP2.2 link integrity check

[C, Ramalingam]

On 12/6/2018 6:57 PM, Daniel Vetter wrote:

On Tue, Nov 27, 2018 at 04:13:07PM +0530, Ramalingam C wrote:

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:
   No Changes.
v4:
   enum check_link_response is used check the link status [Uma]
v5:
   Rebased as part of patch reordering.
v6:
   Required members of intel_hdcp is defined [Sean Paul]
v7:
   hdcp2_check_link is cancelled at required places.
v8:
   Rebased for the component i/f changes.
   Errors due to the sinks are reported as DEBUG logs.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_display.c | 11 +++--
  drivers/gpu/drm/i915/intel_drv.h |  5 +++
  drivers/gpu/drm/i915/intel_hdcp.c| 83 +++-
  include/drm/drm_hdcp.h   |  8 
  4 files changed, 103 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e9f4e22b2a4e..fc63babce165 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15833,15 +15833,20 @@ static void intel_hpd_poll_fini(struct drm_device 
*dev)
  {
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
+   struct intel_hdcp *hdcp;
  
  	/* Kill all the work that may have been queued by hpd. */

drm_connector_list_iter_begin(dev, _iter);
for_each_intel_connector_iter(connector, _iter) {
+   hdcp = >hdcp;
+
if (connector->modeset_retry_work.func)
cancel_work_sync(>modeset_retry_work);
-   if (connector->hdcp.shim) {
-   cancel_delayed_work_sync(>hdcp.check_work);
-   cancel_work_sync(>hdcp.prop_work);
+   if (hdcp->shim) {
+   cancel_delayed_work_sync(>check_work);
+   cancel_work_sync(>prop_work);
+   if (hdcp->hdcp2_supported)
+   
cancel_delayed_work_sync(>hdcp2_check_work);

Locking of these workers is always tricky ... why can't we use the same
worker for both checking hdcp2 and hdcp1 link status?


Doable similar to how we are doing hdcp_enable. Needs the tracking of the spec 
in
use to pick proper timeout and functions.

I will look into it.



Of course need to use the right timeout and call the right functions, but
I think gives us less duplication in the complicated code.



}
}
drm_connector_list_iter_end(_iter);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 24d258488efe..e6e32bf52568 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 {

@@ -445,6 +448,8 @@ struct intel_hdcp {
 * over re-Auth has to be triggered.
 */
u32 seq_num_m;
+
+   struct delayed_work hdcp2_check_work;
  };
  
  struct intel_connector {

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 679f3c164582..98b112395a5a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1626,6 +1626,81 @@ 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;
+
+   if (!hdcp->shim)
+   return -ENOENT;

Why is this possible? Should we wrap it into at least a WARN_ON?


we could land here from CP_IRQ, with hdcp_exit called for shim removal.
But could avoid if we assert on the HDCP auth/encrypt status of the port
before check_link.




+
+   mutex_lock(>mutex);
+
+   if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   goto out;
+
+   if (!(I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)) {
+   DRM_ERROR("HDCP2.2 check failed: link is not 

Re: [Intel-gfx] [PATCH v8 06/35] drm/i915: Enable and Disable of HDCP2.2

[C, Ramalingam]

On 12/6/2018 4:00 PM, Daniel Vetter wrote:

On Tue, Nov 27, 2018 at 04:13:04PM +0530, Ramalingam C wrote:

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.

Patch series suggestion for next time around: First build out the helper
functions, then time them into the big picture like here. Personally I
think that makes it easier to understand, but it's kinda personal choice.


Tried that already. But bisecting will give warnings as "defined but 
unused functions"


Hence moved to this approach.


I guess this here works too.


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:
   No changes.
v4:
   Extra comment added and Style issue fixed [Uma]
v5:
   Rebased as part of patch reordering.
   HDCP2 encryption status is tracked.
   HW state check is moved into WARN_ON [Daniel]
v6:
   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]
v7:
   Return values are handles [Uma]
   Realigned the code.
   Check for comp_master is removed.
v8:
   HDCP2.2 is attempted only if mei interface is up.
   Adjust to the new interface
   Avoid bool usage in struct [Tomas]

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_drv.h  |   5 +
  drivers/gpu/drm/i915/intel_hdcp.c | 223 +++---
  2 files changed, 214 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index bde82f3ada85..3e9f21d23442 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 {
  
  	/* Detects the HDCP protocol(DP/HDMI) required on the port */

enum mei_hdcp_wired_protocol (*hdcp_protocol)(void);
+
+   /* Detects whether Panel is HDCP2.2 capable */
+   int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
+   bool *capable);
  };
  
  struct intel_hdcp {

@@ -396,6 +400,7 @@ struct intel_hdcp {
/* HDCP2.2 related definitions */
/* Flag indicates whether this connector supports HDCP2.2 or not. */
u8 hdcp2_supported;
+   u8 hdcp2_in_use;
  
  	/*

 * Content Stream Type defined by content owner. TYPE0(0x0) content can
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 760780f1105c..c1bd1ccd47cd 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -79,6 +79,43 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
  }
  
+/* At present whether mei_hdcp component is binded with i915 master component */

+static bool intel_hdcp2_mei_binded(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct i915_hdcp_component_master *comp = dev_priv->hdcp_comp;
+
+   mutex_lock(>mutex);
+   if (!comp->ops || !comp->dev) {
+   mutex_unlock(>mutex);
+   return false;
+   }
+   mutex_unlock(>mutex);
+
+   return true;
+}
+
+/* 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;
+
+   /* MEI services for HDCP2.2 */
+   if (!intel_hdcp2_mei_binded(connector))
+   return false;

Why do we still need this with component? Driver load should be stalled
out until it's all there, that was kinda the entire point of component,
so we don't have to recheck all the time whether hdcp2 is still there or
not.


We discussed this in previous patches. Lets decide whether this approach 
is good enough or not.


--Ram




+
+   /* Sink's capability for HDCP2.2 */
+   hdcp->shim->hdcp_2_2_capable(intel_dig_port, );
+
+   return capable;
+}
+
  static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
  {
@@ -1114,8 +1151,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 mei_hdcp_data *data = >hdcp.mei_data;

Re: [Intel-gfx] [PATCH v8 05/35] drm/i915: MEI interface definition

[C, Ramalingam]

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.




  };
  
  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_CHANGE50
+#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 to be closed before restarting the auth on that port with 
initialite_hdcp_session.
If we are closing the hdcp session of the port on all auth errors, we dont need 
this just before
start of the hdcp session.



"Just in case" papering over programming bugs of our own just makes
debugging harder.


+
+   ret = comp->ops->initiate_hdcp2_session(comp->dev,
+   data, ake_data);

We should set the port only after successfully 

Re: [Intel-gfx] [PATCH v8 04/35] drm/i915: Initialize HDCP2.2

[C, Ramalingam]

On 12/6/2018 3:33 PM, Daniel Vetter wrote:

On Tue, Nov 27, 2018 at 04:13:02PM +0530, Ramalingam C wrote:

Add the HDCP2.2 initialization to the existing HDCP1.4 stack.

With the comments below addressed the commit message is a bit untrue,
since this just wires up a basic hdcp2_supported flag in a few places.
Please make that clear.


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

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/i915_drv.c   |   2 +
  drivers/gpu/drm/i915/intel_dp.c   |   3 +-
  drivers/gpu/drm/i915/intel_drv.h  |  16 +++-
  drivers/gpu/drm/i915/intel_hdcp.c | 172 --
  drivers/gpu/drm/i915/intel_hdmi.c |   2 +-
  5 files changed, 130 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b1d23c73c147..fbedd5024afe 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1755,6 +1755,8 @@ void i915_driver_unload(struct drm_device *dev)
  
  	disable_rpm_wakeref_asserts(dev_priv);
  
+	intel_hdcp_exit(dev_priv);

This smells like a separate patch. Needs to be split out. Looking at the
implementation of intel_hdcp_exit I think it's papering over some unload
trouble. We should be shutting down all the outputs on driver unload,
which mei should be triggering (with the component stuff), which means
this code should be unecessary. But I'm not sure.

Either way needs to be split out, but I think proper solution is to drop
it.


As we discussed, during v7-->v8 i changed the component usage such that it wont 
affect i915 load/unload.
During the first connector init, component master will be added. And during the 
mei_client dev and driver binding,
component will be added hence the binding will happen with interface 
initialization from mei.

Upon HDCP2.2 request, component binding will be checked before attempting for 
HDCP2.2 auth.
So component master unbind triggered due to mei component_del, will teardown 
the HDCP2.2 capability of the I915.

So in case of I915 unload trigger, from whatsoever reason, we need to clear the 
HDCP activities and bring down
the i915_hdcp_component_master and the interface with mei. For this purpose 
only intel_hdcp_exit is written here.




+
i915_driver_unregister(dev_priv);
  
  	if (i915_gem_suspend(dev_priv))

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 18e3a5a3d873..ac62af073688 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6675,7 +6675,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 a62d77b76291..85a526598096 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 {

@@ -2016,12 +2027,15 @@ 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,
+ 

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Fix platform coverage for HDCP1.4

[C, Ramalingam]

On 12/5/2018 12:45 AM, Ville Syrjälä wrote:

On Tue, Dec 04, 2018 at 11:37:05PM +0530, Ramalingam C wrote:

HDCP1.4 is enabled and validated only on GEN9+ platforms.

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
  drivers/gpu/drm/i915/intel_hdcp.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index c16bffcce3b0..bccfb001340a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -769,8 +769,7 @@ static void intel_hdcp_prop_work(struct work_struct *work)
  bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
  {
/* PORT E doesn't have HDCP, and PORT F is disabled */
-   return ((INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) &&
-   !IS_CHERRYVIEW(dev_priv) && port < PORT_E);
+   return ((INTEL_GEN(dev_priv) >= 9) && port < PORT_E);

Drive-by: Lots of pointless parens floating around here.


kept it for readability. Perhaps overkill here. Removed them.

Thanks,
--Ram




  }
  
  int intel_hdcp_init(struct intel_connector *connector,

--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/4] HDCP1.4 fixes

[C, Ramalingam]

Sean and Daniel,

Could you please help me with the review these changes?

--Ram

On 11/27/2018 7:32 PM, Ramalingam C wrote:

Couple of more HDCP1.4 fixes on
   - Key load process for CFL
   - Encryption status change time
   - debug log addition
   - active platform coverage

Ramalingam C (4):
   drm/i915: Fix GEN9 HDCP1.4 key load process
   drm/i915: Fix platform coverage for HDCP1.4
   drm/i915: debug log for REPLY_ACK missing
   drm/i915: Increase timeout for Encrypt status change

  drivers/gpu/drm/i915/intel_dp.c   |  6 +-
  drivers/gpu/drm/i915/intel_hdcp.c | 17 ++---
  2 files changed, 15 insertions(+), 8 deletions(-)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v8 12/35] drm/i915: Implement the HDCP2.2 support for DP

[C, Ramalingam]

On 11/28/2018 10:56 AM, Stéphane Marchesin wrote:

Hi,

Just a drive-by comment, but did you check that this fails gracefully
on platforms which don't enable the ME? For example Chrome OS :)


That is taken care :) HDCP2.2 is attempted only if platform enables the 
ME and its required kernel drivers.


--Ram



Stéphane

On Tue, Nov 27, 2018 at 2:48 AM Ramalingam C  wrote:

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.

Signed-off-by: Ramalingam C 
Signed-off-by: Ankit K Nautiyal 
Reviewed-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_dp.c   | 338 ++
  drivers/gpu/drm/i915/intel_drv.h  |   7 +
  drivers/gpu/drm/i915/intel_hdcp.c |   6 +
  3 files changed, 351 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ecc4706db7dc..1cc82e490999 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -5347,6 +5348,27 @@ void intel_dp_encoder_suspend(struct intel_encoder 
*intel_encoder)
 pps_unlock(intel_dp);
  }

+static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
+int timeout)
+{
+   long ret;
+
+   /* Reinit */
+   atomic_set(>cp_irq_recved, 0);
+
+#define C (atomic_read(>cp_irq_recved) > 0)
+   ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
+  msecs_to_jiffies(timeout));
+
+   if (ret > 0) {
+   atomic_set(>cp_irq_recved, 0);
+   return 0;
+   } else if (!ret) {
+   return -ETIMEDOUT;
+   }
+   return (int)ret;
+}
+
  static
  int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
 u8 *an)
@@ -5570,6 +5592,316 @@ 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 

Re: [Intel-gfx] [PATCH v8 12/35] drm/i915: Implement the HDCP2.2 support for DP

[C, Ramalingam]

On 11/27/2018 11:07 PM, Daniel Vetter wrote:

On Tue, Nov 27, 2018 at 04:54:15PM +, Bloomfield, Jon wrote:

I'm not formally reviewing this series, but while glancing at it, I noticed


-Original Message-
From: Intel-gfx  On Behalf Of
Ramalingam C
Sent: Tuesday, November 27, 2018 2:43 AM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
daniel.vet...@ffwll.ch; Winkler, Tomas 
Subject: [Intel-gfx] [PATCH v8 12/35] 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.

Signed-off-by: Ramalingam C 
Signed-off-by: Ankit K Nautiyal 
Reviewed-by: Uma Shankar 
---
  drivers/gpu/drm/i915/intel_dp.c   | 338
++
  drivers/gpu/drm/i915/intel_drv.h  |   7 +
  drivers/gpu/drm/i915/intel_hdcp.c |   6 +
  3 files changed, 351 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index ecc4706db7dc..1cc82e490999 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -5347,6 +5348,27 @@ void intel_dp_encoder_suspend(struct
intel_encoder *intel_encoder)
pps_unlock(intel_dp);
  }




+
+static struct hdcp2_dp_msg_data *get_hdcp2_dp_msg_data(u8 msg_id)
+{
+   int i;
+
+   for (i = 0; i < sizeof(hdcp2_msg_data); i++)

Should be
sizeof(hdcp2_msg_data) / sizeof(*hdcp2_msg_data)
or equivalent.

ARRAY_SIZE is probably what you want here.


yes. missed it as authentication flow always provides the valid msg_id. 
Will fix it.


--Ram


-Daniel


Has the failure return been tested?


+   if (hdcp2_msg_data[i].msg_id == msg_id)
+   return _msg_data[i];
+
+   return NULL;
+}
+



--
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Fix GEN9 HDCP1.4 key load process

[C, Ramalingam]

On 11/27/2018 8:45 PM, Ville Syrjälä wrote:

On Tue, Nov 27, 2018 at 07:32:56PM +0530, Ramalingam C wrote:

HDCP1.4 key load process varies between Intel platform to platform.

For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using
the GT Driver Mailbox interface. Instead of listing all the platforms
for this method, adopted this method for all Gen9 platforms with
exceptions. In this way we need not extent check for new GEN9 platforms
like CFL.

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_hdcp.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 1bf487f94254..beacfbb6e5e1 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -157,10 +157,12 @@ static int intel_hdcp_load_keys(struct drm_i915_private 
*dev_priv)
/*
 * Initiate loading the HDCP key from fuses.
 *
-* BXT+ platforms, HDCP key needs to be loaded by SW. Only SKL and KBL
-* differ in the key load trigger process from other platforms.
+* BXT+ platforms, HDCP key needs to be loaded by SW. Only Gen 9
+* platforms except BXT and GLK, differ in the key load trigger process
+* from other platforms.
 */
-   if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
+   if (IS_GEN9(dev_priv) &&
+   (!IS_BROXTON(dev_priv) && !IS_GEMINILAKE(dev_priv))) {

IS_GEN9_BC()


Bspec doesn't state anything about BC/LP. They have mentioned GEN9+ with BXT, 
CNL, ICL excluded.
So I am inferring that this method is only for Gen9 excluding BXT and GLK 
(verified).

Remaining platforms are SKL, KBL, and CFL.
IS_GEN9_BC() will filter them easily. unless we find otherwise, we can use 
this. Thanks Ville.

--Ram




mutex_lock(_priv->pcu_lock);
ret = sandybridge_pcode_write(dev_priv,
  SKL_PCODE_LOAD_HDCP_KEYS, 1);
--
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Implement HDCP2.2: PART-I (rev2)

[C, Ramalingam]

On 10/29/2018 8:16 PM, Martin Peres wrote:


On 29/10/2018 13:55, Patchwork wrote:

== Series Details ==

Series: Implement HDCP2.2: PART-I (rev2)
URL   : https://patchwork.freedesktop.org/series/51495/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_5044_full -> Patchwork_10620_full =

== Summary - FAILURE ==

   Serious unknown changes coming with Patchwork_10620_full absolutely need to 
be
   verified manually.
   
   If you think the reported changes have nothing to do with the changes

   introduced in Patchwork_10620_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_10620_full:

   === IGT changes ===

  Possible regressions 

 igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
   shard-apl:  PASS -> FAIL

https://bugs.freedesktop.org/show_bug.cgi?id=104894

 
  Warnings 


 igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
   shard-apl:  DMESG-FAIL (fdo#108549) -> FAIL +2

This part is not noise. The test was not failing before and it still
does now. Please fix!


So igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing failed 
atCI_DRM_5044    
andPatchwork_10620.  
This series improves the result removes the DRM WARNINGS( by making them as 
debug logs.)

But the HDCP attempts(because of known bug at IGT) will be avoided as soon as 
https://patchwork.freedesktop.org/patch/258692/ is merged.
So I dont see anything to be fixed here.

--Ram
 

 
== Known issues ==


   Here are the changes found in Patchwork_10620_full that come from known 
issues:

   === IGT changes ===

  Issues hit 

 igt@drv_suspend@shrink:
   shard-skl:  NOTRUN -> INCOMPLETE (fdo#106886)
   shard-glk:  PASS -> INCOMPLETE (fdo#103359, fdo#106886, 
k.org#198133)

 igt@gem_cpu_reloc@full:
   shard-skl:  NOTRUN -> INCOMPLETE (fdo#108073)

 igt@gem_exec_schedule@pi-ringfull-bsd:
   shard-skl:  NOTRUN -> FAIL (fdo#103158) +2

 igt@gem_ppgtt@blt-vs-render-ctxn:
   shard-skl:  NOTRUN -> TIMEOUT (fdo#108039)

 igt@kms_busy@extended-modeset-hang-newfb-render-a:
   shard-skl:  NOTRUN -> DMESG-WARN (fdo#107956) +4

 igt@kms_cursor_crc@cursor-128x42-onscreen:
   shard-apl:  PASS -> FAIL (fdo#103232) +2

 igt@kms_cursor_crc@cursor-64x21-offscreen:
   shard-skl:  NOTRUN -> FAIL (fdo#103232)

 igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
   shard-glk:  PASS -> FAIL (fdo#104873)

 igt@kms_fbcon_fbt@psr-suspend:
   shard-skl:  NOTRUN -> FAIL (fdo#107882) +1

 igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
   shard-glk:  PASS -> FAIL (fdo#105363)

 igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite:
   shard-snb:  SKIP -> INCOMPLETE (fdo#105411)

 igt@kms_plane@pixel-format-pipe-c-planes:
   shard-skl:  NOTRUN -> DMESG-FAIL (fdo#103166, fdo#106885)

 igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
   shard-skl:  NOTRUN -> INCOMPLETE (fdo#104108)

 igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
   shard-skl:  NOTRUN -> FAIL (fdo#108145, fdo#107815) +2

 igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
   shard-skl:  NOTRUN -> FAIL (fdo#108145) +8

 igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
   shard-skl:  NOTRUN -> FAIL (fdo#103166, fdo#107815)

 igt@kms_universal_plane@universal-plane-pipe-a-functional:
   shard-apl:  PASS -> FAIL (fdo#103166) +1

 
  Possible fixes 


 igt@drv_suspend@debugfs-reader:
   shard-skl:  INCOMPLETE (fdo#104108) -> PASS

 igt@kms_busy@extended-modeset-hang-newfb-render-a:
   shard-kbl:  DMESG-WARN (fdo#107956) -> PASS

 igt@kms_chv_cursor_fail@pipe-b-128x128-bottom-edge:
   shard-skl:  FAIL (fdo#104671) -> PASS +1

 igt@kms_color@pipe-b-ctm-max:
   shard-apl:  DMESG-WARN (fdo#108549) -> PASS +22

 igt@kms_cursor_crc@cursor-64x21-sliding:
   shard-apl:  FAIL (fdo#103232) -> PASS +2

 igt@kms_cursor_crc@cursor-64x64-sliding:
   shard-apl:  DMESG-FAIL (fdo#108549, fdo#103232) -> PASS

 igt@kms_cursor_crc@cursor-64x64-suspend:
   shard-apl:  FAIL (fdo#103232, fdo#103191) -> PASS

 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu:
   shard-glk:  DMESG-WARN (fdo#105763, fdo#106538) -> PASS +1

 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite:

Re: [Intel-gfx] [PATCH] drm/i915: convert HDCP DRM_ERROR into DRM_DEBUG

[C, Ramalingam]

So basically we want all logs related to HW failure and I915 programing should 
be errors whereas all sink specific errors in debug level.
I will prepare the change.

danvet, seanpaul has discussed few points about convenience of debugging on 
customer platforms. What is the take on it?

--Ram

On 10/26/2018 5:09 PM, Daniel Vetter wrote:

On Thu, Oct 25, 2018 at 11:47:52PM +0530, Ramalingam C wrote:

Conceptually user should be knowing the feature status through uAPI.
So HDCP authentication failure information need not DRM_ERRORS.
They are needed only for ENG debugging.

And also in HDCP we tolerate the retries for HDCP authentication.
Hence if we print the failure info initial attempts as ERRORs CI will
fail the IGT.

So we present the information of the failures in form of DRM_DEBUG
msgs for debugging purpose.

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_hdcp.c | 46 +++
  1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 5b423a78518d..d92b04c3ed4e 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -166,8 +166,8 @@ static int intel_hdcp_load_keys(struct drm_i915_private 
*dev_priv)
  SKL_PCODE_LOAD_HDCP_KEYS, 1);
mutex_unlock(_priv->pcu_lock);
if (ret) {
-   DRM_ERROR("Failed to initiate HDCP key load (%d)\n",
- ret);
+   DRM_DEBUG_KMS("Failed to initiate HDCP key load (%d)\n",
+ ret);

This one indicates an i915 hw failure, not anything wrong with the sink.
So should stay at DRM_ERROR.

Btw I noticed that 2 DRM_DEBUG_KMS in intel_hdcp_validate_v_prime also
indicate programming/i915-side hw errors. So should be upgraded to
DRM_ERROR I think (but in a separate patch).


return ret;
}
} else {
@@ -195,7 +195,7 @@ static int intel_write_sha_text(struct drm_i915_private 
*dev_priv, u32 sha_text)
I915_WRITE(HDCP_SHA_TEXT, sha_text);
if (intel_wait_for_register(dev_priv, HDCP_REP_CTL,
HDCP_SHA1_READY, HDCP_SHA1_READY, 1)) {
-   DRM_ERROR("Timed out waiting for SHA1 ready\n");
+   DRM_DEBUG_KMS("Timed out waiting for SHA1 ready\n");

Same here.


return -ETIMEDOUT;
}
return 0;
@@ -219,7 +219,7 @@ u32 intel_hdcp_get_repeater_ctl(struct intel_digital_port 
*intel_dig_port)
default:
break;
}
-   DRM_ERROR("Unknown port %d\n", port);
+   DRM_DEBUG_KMS("Unknown port %d\n", port);

Also a programming error.


return -EINVAL;
  }
  
@@ -448,7 +448,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
  
  	ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);

if (ret) {
-   DRM_ERROR("KSV list failed to become ready (%d)\n", ret);
+   DRM_DEBUG_KMS("KSV list failed to become ready (%d)\n", ret);

This one is a sink issue, so correct to change to DRM_DEBUG_KMS. If I
don't comment, assume that I agree with your change.


return ret;
}
  
@@ -458,7 +458,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
  
  	if (DRM_HDCP_MAX_DEVICE_EXCEEDED(bstatus[0]) ||

DRM_HDCP_MAX_CASCADE_EXCEEDED(bstatus[1])) {
-   DRM_ERROR("Max Topology Limit Exceeded\n");
+   DRM_DEBUG_KMS("Max Topology Limit Exceeded\n");
return -EPERM;
}
  
@@ -494,7 +494,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,

}
  
  	if (i == tries) {

-   DRM_ERROR("V Prime validation failed.(%d)\n", ret);
+   DRM_DEBUG_KMS("V Prime validation failed.(%d)\n", ret);
goto err;
}
  
@@ -543,7 +543,7 @@ static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,

if (ret)
return ret;
if (!hdcp_capable) {
-   DRM_ERROR("Panel is not HDCP capable\n");
+   DRM_DEBUG_KMS("Panel is not HDCP capable\n");
return -EINVAL;
}
}
@@ -557,7 +557,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port),
HDCP_STATUS_AN_READY,
HDCP_STATUS_AN_READY, 1)) {
-   DRM_ERROR("Timed out waiting for An\n");
+   DRM_DEBUG_KMS("Timed out waiting for An\n");

Again this would indicate an i915 hw issue, so better to keep it at
DRM_ERROR.


return -ETIMEDOUT;
}
  
@@ -594,7 +594,7 @@ static int intel_hdcp_auth(struct 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Enabling the IGT for HDCP1.4 (rev4)

[C, Ramalingam]

On 10/23/2018 1:15 PM, Martin Peres wrote:

On 23/10/2018 08:42, C, Ramalingam wrote:

On 10/22/2018 10:47 PM, Patchwork wrote:

== Series Details ==

Series: Enabling the IGT for HDCP1.4 (rev4)
URL   : https://patchwork.freedesktop.org/series/51113/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_5017 -> Patchwork_10527 =

== Summary - FAILURE ==

   Serious unknown changes coming with Patchwork_10527 absolutely need to be
   verified manually.
   
   If you think the reported changes have nothing to do with the changes

   introduced in Patchwork_10527, 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/51113/revisions/4/mbox/

== Possible new issues ==

   Here are the unknown changes that may have been introduced in 
Patchwork_10527:

   === IGT changes ===

  Possible regressions 

 igt@debugfs_test@read_all_entries:
   fi-skl-iommu:   PASS -> DMESG-WARN
   fi-bdw-gvtdvm:  PASS -> DMESG-WARN
   fi-bdw-5557u:   PASS -> DMESG-WARN
   fi-skl-guc: PASS -> DMESG-WARN
   fi-glk-j4005:   PASS -> DMESG-WARN
   fi-cfl-8700k:   PASS -> DMESG-WARN
   fi-cfl-guc: PASS -> DMESG-WARN

All these dmesg warnings are there because of the sink in CI which doesn't 
support hdcp registers. Which is expected in case of dummy HDMI sinks.
So we could go ahead and merge these patches.

DMESG-WARN is not allowed for any test, so the patch is currently
unacceptable. Please simply report that the sync does not support HDCP
in i915_hdcp_sink_capability, but no warnings are allowed in dmesg.

In Linux, we put the cost of integration on the person writing the
patch. Thus, if you need to rework the internals of i915 to achieve a
warning-free dmesg log, you will be expected to do so, so as not to
regress anything.


Thanks Martin, for pointing it out. These errors were part of authentication we 
have.
New patches are using a routine from auth flow hence when DDC request fail 
caused these errors.
As I had a closure with danvet, I will move these errors to debug level.



Looking forward to seeing an updated patch :)

PS: The retry button should not be pressed lightly as it steals machine
time from other tasks. If you believe some noise might just have
happened and blocked the testing of your patch series, please contact me
to file a bug in our suppression system (CI Bug Log) *before* being
allowed to press the button.


Agreed. At first attempt to request retest I saw that without result update,
re-queued for test state was gone. So clicked couple of times.
I remember this mistake next time. :)

Thanks,
--Ram




--Ram

 
== Known issues ==


   Here are the changes found in Patchwork_10527 that come from known issues:

   === IGT changes ===

  Issues hit 

 igt@gem_exec_store@basic-all:
   fi-icl-u:   NOTRUN -> DMESG-WARN (fdo#107732) +5

 igt@gem_exec_suspend@basic:
   fi-icl-u:   NOTRUN -> DMESG-WARN (fdo#107724) +24

 igt@gem_exec_suspend@basic-s3:
   fi-icl-u:   NOTRUN -> DMESG-WARN (fdo#108512)

 igt@gem_mmap@basic-small-bo:
   fi-icl-u2:  NOTRUN -> DMESG-WARN (fdo#107732) +1

 
  Possible fixes 


 igt@gem_exec_suspend@basic-s4-devices:
   fi-kbl-7500u:   DMESG-WARN (fdo#105128, fdo#107139) -> PASS

 igt@kms_frontbuffer_tracking@basic:
   fi-byt-clapper: FAIL (fdo#103167) -> PASS

 igt@prime_vgem@basic-fence-flip:
   fi-cfl-8700k:   FAIL (fdo#104008) -> PASS

 
   fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

   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#107724 https://bugs.freedesktop.org/show_bug.cgi?id=107724
   fdo#107732 https://bugs.freedesktop.org/show_bug.cgi?id=107732
   fdo#108512 https://bugs.freedesktop.org/show_bug.cgi?id=108512


== Participating hosts (51 -> 46) ==

   Additional (1): fi-icl-u
   Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-snb-2520m fi-ctg-p8600


== Build changes ==

 * Linux: CI_DRM_5017 -> Patchwork_10527

   CI_DRM_5017: 9510f8e44127260f92b5b6c3127aafa22b15f741 @ 
git://anongit.freedesktop.org/gfx-ci/linux
   IGT_4685: 78619fde4008424c472906041edb1d204e014f7c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
   Patchwork_10527: 757bbb8cb440de47c5c48ba5ca87c76681075424 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

757bbb8cb440 drm/i915/debugfs: hdcp capability of a sink
e82aaa2cb827 drm/i915: hdcp_check_link only on CP_IRQ
1698e218c4ae drm/i915: Pullout the bksv read and validation

== Logs ==

For more details see: 
https://intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Enabling the IGT for HDCP1.4 (rev4)

[C, Ramalingam]

On 10/22/2018 10:47 PM, Patchwork wrote:

== Series Details ==

Series: Enabling the IGT for HDCP1.4 (rev4)
URL   : https://patchwork.freedesktop.org/series/51113/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_5017 -> Patchwork_10527 =

== Summary - FAILURE ==

   Serious unknown changes coming with Patchwork_10527 absolutely need to be
   verified manually.
   
   If you think the reported changes have nothing to do with the changes

   introduced in Patchwork_10527, 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/51113/revisions/4/mbox/

== Possible new issues ==

   Here are the unknown changes that may have been introduced in 
Patchwork_10527:

   === IGT changes ===

  Possible regressions 

 igt@debugfs_test@read_all_entries:
   fi-skl-iommu:   PASS -> DMESG-WARN
   fi-bdw-gvtdvm:  PASS -> DMESG-WARN
   fi-bdw-5557u:   PASS -> DMESG-WARN
   fi-skl-guc: PASS -> DMESG-WARN
   fi-glk-j4005:   PASS -> DMESG-WARN
   fi-cfl-8700k:   PASS -> DMESG-WARN
   fi-cfl-guc: PASS -> DMESG-WARN


All these dmesg warnings are there because of the sink in CI which doesn't 
support hdcp registers. Which is expected in case of dummy HDMI sinks.
So we could go ahead and merge these patches.

--Ram

 
== Known issues ==


   Here are the changes found in Patchwork_10527 that come from known issues:

   === IGT changes ===

  Issues hit 

 igt@gem_exec_store@basic-all:
   fi-icl-u:   NOTRUN -> DMESG-WARN (fdo#107732) +5

 igt@gem_exec_suspend@basic:
   fi-icl-u:   NOTRUN -> DMESG-WARN (fdo#107724) +24

 igt@gem_exec_suspend@basic-s3:
   fi-icl-u:   NOTRUN -> DMESG-WARN (fdo#108512)

 igt@gem_mmap@basic-small-bo:
   fi-icl-u2:  NOTRUN -> DMESG-WARN (fdo#107732) +1

 
  Possible fixes 


 igt@gem_exec_suspend@basic-s4-devices:
   fi-kbl-7500u:   DMESG-WARN (fdo#105128, fdo#107139) -> PASS

 igt@kms_frontbuffer_tracking@basic:
   fi-byt-clapper: FAIL (fdo#103167) -> PASS

 igt@prime_vgem@basic-fence-flip:
   fi-cfl-8700k:   FAIL (fdo#104008) -> PASS

 
   fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

   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#107724 https://bugs.freedesktop.org/show_bug.cgi?id=107724
   fdo#107732 https://bugs.freedesktop.org/show_bug.cgi?id=107732
   fdo#108512 https://bugs.freedesktop.org/show_bug.cgi?id=108512


== Participating hosts (51 -> 46) ==

   Additional (1): fi-icl-u
   Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-snb-2520m fi-ctg-p8600


== Build changes ==

 * Linux: CI_DRM_5017 -> Patchwork_10527

   CI_DRM_5017: 9510f8e44127260f92b5b6c3127aafa22b15f741 @ 
git://anongit.freedesktop.org/gfx-ci/linux
   IGT_4685: 78619fde4008424c472906041edb1d204e014f7c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
   Patchwork_10527: 757bbb8cb440de47c5c48ba5ca87c76681075424 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

757bbb8cb440 drm/i915/debugfs: hdcp capability of a sink
e82aaa2cb827 drm/i915: hdcp_check_link only on CP_IRQ
1698e218c4ae drm/i915: Pullout the bksv read and validation

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10527/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 20/40] drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ

[C, Ramalingam]

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Tuesday, July 10, 2018 2:21 AM
> To: C, Ramalingam 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> dan...@ffwll.ch; Winkler, Tomas ; Usyskin,
> Alexander ; Shankar, Uma
> ; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Sharma, Shashank ;
> Sean Paul 
> Subject: Re: [PATCH v5 20/40] drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ
> 
> On Wed, Jun 27, 2018 at 02:10:09PM +0530, Ramalingam C wrote:
> > On DP HDCP1.4 and 2.2, when CP_IRQ is received, start the link
> > integrity check for the HDCP version that is enabled.
> >
> > v2:
> >   Rebased. Function name is changed.
> > v3:
> >   No Changes.
> > v4:
> >   No Changes.
> > v5:
> >   No Changes.
> >
> > Signed-off-by: Ramalingam C 
> > cc: Sean Paul 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c   |  2 +-
> >  drivers/gpu/drm/i915/intel_drv.h  |  2 +-
> > drivers/gpu/drm/i915/intel_hdcp.c | 31 ++-
> >  3 files changed, 32 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c index 7467e7b3f2df..a6ba27ef20ae
> > 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4484,7 +4484,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> > if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
> > intel_dp_handle_test_request(intel_dp);
> > if (sink_irq_vector & DP_CP_IRQ)
> > -   intel_hdcp_check_link(intel_dp->attached_connector);
> > +   intel_hdcp_handle_cp_irq(intel_dp-
> >attached_connector);
> > if (sink_irq_vector & 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 7624388eecd5..875657fd7d3c 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1965,8 +1965,8 @@ 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);
> > +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 790f4a9f4793..b035274785c8 100644
> > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > @@ -32,6 +32,7 @@ int intel_hdcp_read_valid_bksv(struct intel_digital_port
> *intel_dig_port,
> >const struct intel_hdcp_shim *shim, u8 *bksv);
> static
> > struct intel_digital_port *conn_to_dig_port(struct intel_connector
> > *connector);
> > +static int intel_hdcp_check_link(struct intel_connector *connector);
> >
> >  static bool panel_supports_hdcp(struct intel_connector *connector)  {
> > @@ -80,6 +81,26 @@ static inline bool intel_hdcp2_capable(struct
> intel_connector *connector)
> > panel_supports_hdcp2(connector));
> >  }
> >
> > +static inline bool intel_hdcp_in_force(struct intel_connector
> > +*connector)
> 
> nit: I'd use _in_use instead of in_force

Sure I will rename it.
> 
> With that fixed,
> 
> Reviewed-by: Sean Paul 

Thanks,
Ram.
> 
> 
> > +{
> > +   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_AUTH | HDCP_STATUS_ENC); }
> > +
> > +static inline bool intel_hdcp2_in_force(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 | LINK_AUTH_STATUS); }
> > +
> >  static int int

Re: [Intel-gfx] [PATCH v5 01/40] drm: hdcp2.2 authentication msg definitions

[C, Ramalingam]

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Thursday, July 12, 2018 12:38 AM
> To: C, Ramalingam 
> Cc: Sean Paul ; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; dan...@ffwll.ch; Winkler, Tomas
> ; Usyskin, Alexander
> ; Shankar, Uma 
> Subject: Re: [Intel-gfx] [PATCH v5 01/40] drm: hdcp2.2 authentication msg
> definitions
> 
> On Wed, Jul 11, 2018 at 05:57:08PM +, C, Ramalingam wrote:
> > Thanks seanpaul for the reviews.
> >
> > > -Original Message-
> > > From: Sean Paul [mailto:seanp...@chromium.org]
> > > Sent: Tuesday, July 10, 2018 1:51 AM
> > > To: C, Ramalingam 
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > dri-de...@lists.freedesktop.org; dan...@ffwll.ch; Winkler, Tomas
> > > ; Usyskin, Alexander
> > > ; Shankar, Uma 
> > > Subject: Re: [Intel-gfx] [PATCH v5 01/40] drm: hdcp2.2
> > > authentication msg definitions
> > >
> > > On Wed, Jun 27, 2018 at 02:09:50PM +0530, Ramalingam C wrote:
> > > > This patch defines the hdcp2.2 protocol messages for authentication.
> > > >
> > > > v2:
> > > >   bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
> > > >   prefix HDCP_2_2_ is added to the macros. [Tomas]
> > > > v3:
> > > >   No Changes.
> > > > v4:
> > > >   Style and spellings are fixed [Uma]
> > > > v5:
> > > >   Fix for macros.
> > > >
> > > > Signed-off-by: Ramalingam C 
> > > > ---
> > > >  include/drm/drm_hdcp.h | 179
> > > > +
> > > >  1 file changed, 179 insertions(+)
> > > >
> > > > diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
> > > > 98e63d870139..3e963c5d04b2 100644
> > > > --- a/include/drm/drm_hdcp.h
> > > > +++ b/include/drm/drm_hdcp.h
> > > > @@ -38,4 +38,183 @@
> > > >  #define DRM_HDCP_DDC_BSTATUS   0x41
> > > >  #define DRM_HDCP_DDC_KSV_FIFO  0x43
> > > >
> > > > +#define DRM_HDCP_1_4_SRM_ID0x8
> > > > +#define DRM_HDCP_1_4_VRL_LENGTH_SIZE   3
> > > > +#define DRM_HDCP_1_4_DCP_SIG_SIZE  40
> > >
> > > These don't seem to be related to the patch?
> > >
> > > > +
> > > > +/* Protocol message definition for HDCP2.2 specification */
> > > > +#define HDCP_STREAM_TYPE0  0x00
> > > > +#define HDCP_STREAM_TYPE1  0x01
> > >
> > > Why not HDCP_2_2 prefix?
> > Though they are introduced at HDCP2.2, this is classification of the 
> > streams.
> > And Type 0 can be transmitted on HDCP1.4.
> > So keeping it as generic name with no version mentioned.
> 
> Ok, I guess it's the comment that was throwing me off. Perhaps you could
> improve it to:
> 
> /*
>  * Protected video streams are classified into 2 types:
>  * - Type0: Can be transmitted with HDCP 1.4+
>  * - Type1: Can be transmitted with HDCP 2.2+  */
> 
> /snip
Sure I will fix this.

Thanks,
Ram.

> 
> > > > +} __packed;
> > >
> > > Perhaps this has already been asked and answered, but do all of
> > > these need to be __packed? This is kind of the problem with adding a
> > > bunch of unused structures to a patch, it's hard to see what their
> > > usage is. In future, these should probably be introduced when they're 
> > > being
> used.
> >
> > These are the HDCP2.2 message defined at HDCP2.2 spec. And they needs
> > to be __packed just to have exact size mentioned by spec.
> >
> > Like how we have HDCP1.4 and 2.2 macros defined as per the HDCP spec
> > definitions, defined the HDCP2.2 messages together here.
> 
> Thanks for the explanation.
> 
> Sean
> 
> >
> > Thanks,
> > Ram.
> > >
> > > Sean
> > >
> > > > +
> > > >  #endif
> > > > --
> > > > 2.7.4
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > --
> > > Sean Paul, Software Engineer, Google / Chromium OS
> 
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 09/40] drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable

[C, Ramalingam]

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Thursday, July 12, 2018 2:36 AM
> To: C, Ramalingam 
> Cc: Sean Paul ; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; dan...@ffwll.ch; Winkler, Tomas
> ; Usyskin, Alexander
> ; Shankar, Uma 
> Subject: Re: [PATCH v5 09/40] drm/i915: Schedule hdcp_check_link in
> _intel_hdcp_enable
> 
> On Wed, Jul 11, 2018 at 07:07:10PM +, C, Ramalingam wrote:
> >
> > > -Original Message-
> > > From: Sean Paul [mailto:seanp...@chromium.org]
> > > Sent: Tuesday, July 10, 2018 2:04 AM
> > > To: C, Ramalingam 
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > dri-de...@lists.freedesktop.org; dan...@ffwll.ch; Winkler, Tomas
> > > ; Usyskin, Alexander
> > > ; Shankar, Uma 
> > > Subject: Re: [PATCH v5 09/40] drm/i915: Schedule hdcp_check_link in
> > > _intel_hdcp_enable
> > >
> > > On Wed, Jun 27, 2018 at 02:09:58PM +0530, Ramalingam C wrote:
> > > > As a preparation for making the intel_hdcp_enable as common
> > > > function for both HDCP1.4 and HDCP2.2, HDCP1.4 check_link
> > > > scheduling is moved into _intel_hdcp_enable() function.
> > > >
> > > > v3:
> > > >   No Changes.
> > > > v4:
> > > >   Style fix.
> > > > v5:
> > > >   No Change.
> > > >
> > > > Signed-off-by: Ramalingam C 
> > > > Reviewed-by: Uma Shankar 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_hdcp.c | 12 
> > > >  1 file changed, 8 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> > > > b/drivers/gpu/drm/i915/intel_hdcp.c
> > > > index 769560591aa8..4bff74b3bed0 100644
> > > > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > > > @@ -688,7 +688,7 @@ static int _intel_hdcp_enable(struct
> > > > intel_connector
> > > *connector)
> > > > ret = intel_hdcp_auth(conn_to_dig_port(connector),
> > > >   hdcp->hdcp_shim);
> > > > if (!ret)
> > > > -   return 0;
> > > > +   break;
> > > >
> > > > DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
> > > >
> > > > @@ -696,7 +696,13 @@ static int _intel_hdcp_enable(struct
> > > > intel_connector
> > > *connector)
> > > > _intel_hdcp_disable(connector);
> > > > }
> > > >
> > > > -   DRM_ERROR("HDCP authentication failed (%d tries/%d)\n", tries, 
> > > > ret);
> > > > +   if (i != tries)
> > > > +   schedule_delayed_work(>hdcp_check_work,
> > > > + DRM_HDCP_CHECK_PERIOD_MS);
> > >
> > > At best, this results in a duplicate scheduling when called from
> > > intel_hdcp_check_link(). At worst, it schedules a check when it's
> > > not supposed to (see the condition in intel_hdcp_check_work).
> >
> > In original HDCP1.4 implementation hdcp_check_work is scheduled at
> intel_hdcp_enable.
> > To make the intel_hdcp_enable as a common function for 1.4 and 2.2,
> > the same hdcp_check_work is scheduled at _intel_hdcp_enable which is
> enable function for HDCP1.4.
> >
> > So no real functional change with this patch. If you are mentioning
> > the check_work is getting scheduled before prop_work and/or hdcp_value
> update, check_link handles that.
> > Means if the hdcp value is not UNDESIRED then shim's link_check will be
> invoked.
> >
> > Hope I understood your concern right.
> 
> I'm not sure. intel_hdcp_check_link() calls _intel_hdcp_enable(), which is now
> scheduling a check. So, in essence, intel_hdcp_check_work() is rescheduling
> itself through this call chain. Once intel_hdcp_check_link() returns in
> intel_hdcp_check_work(), the worker reschedules itself if the link is good, 
> so you
> get a duplicate schedule.


Oops! Thanks for catching me there. I missed to notice that _intel_hdcp_enable 
is called from check_link also.
I will fix that within intel_hdcp_enable itself. In that case this patch is no 
more needed.

Thanks,
Ram

> 
> Sean
> 
> >
> > Thanks,
> > Ram
> > >
> > > Sean
> > >
> > > > +   else
> > >

Re: [Intel-gfx] [PATCH v5 09/40] drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable

[C, Ramalingam]

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Tuesday, July 10, 2018 2:04 AM
> To: C, Ramalingam 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> dan...@ffwll.ch; Winkler, Tomas ; Usyskin,
> Alexander ; Shankar, Uma
> 
> Subject: Re: [PATCH v5 09/40] drm/i915: Schedule hdcp_check_link in
> _intel_hdcp_enable
> 
> On Wed, Jun 27, 2018 at 02:09:58PM +0530, Ramalingam C wrote:
> > As a preparation for making the intel_hdcp_enable as common function
> > for both HDCP1.4 and HDCP2.2, HDCP1.4 check_link scheduling is moved
> > into _intel_hdcp_enable() function.
> >
> > v3:
> >   No Changes.
> > v4:
> >   Style fix.
> > v5:
> >   No Change.
> >
> > Signed-off-by: Ramalingam C 
> > Reviewed-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/i915/intel_hdcp.c | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> > b/drivers/gpu/drm/i915/intel_hdcp.c
> > index 769560591aa8..4bff74b3bed0 100644
> > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > @@ -688,7 +688,7 @@ static int _intel_hdcp_enable(struct intel_connector
> *connector)
> > ret = intel_hdcp_auth(conn_to_dig_port(connector),
> >   hdcp->hdcp_shim);
> > if (!ret)
> > -   return 0;
> > +   break;
> >
> > DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
> >
> > @@ -696,7 +696,13 @@ static int _intel_hdcp_enable(struct intel_connector
> *connector)
> > _intel_hdcp_disable(connector);
> > }
> >
> > -   DRM_ERROR("HDCP authentication failed (%d tries/%d)\n", tries, ret);
> > +   if (i != tries)
> > +   schedule_delayed_work(>hdcp_check_work,
> > + DRM_HDCP_CHECK_PERIOD_MS);
> 
> At best, this results in a duplicate scheduling when called from
> intel_hdcp_check_link(). At worst, it schedules a check when it's not 
> supposed to
> (see the condition in intel_hdcp_check_work).

In original HDCP1.4 implementation hdcp_check_work is scheduled at 
intel_hdcp_enable.
To make the intel_hdcp_enable as a common function for 1.4 and 2.2, the same
hdcp_check_work is scheduled at _intel_hdcp_enable which is enable function for 
HDCP1.4.

So no real functional change with this patch. If you are mentioning the 
check_work is
getting scheduled before prop_work and/or hdcp_value update, check_link handles 
that.
Means if the hdcp value is not UNDESIRED then shim's link_check will be invoked.

Hope I understood your concern right.

Thanks,
Ram 
> 
> Sean
> 
> > +   else
> > +   DRM_ERROR("HDCP authentication failed (%d tries/%d)\n",
> > + tries, ret);
> > +
> > return ret;
> >  }
> >
> > @@ -790,8 +796,6 @@ int intel_hdcp_enable(struct intel_connector
> > *connector)
> >
> > hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
> > schedule_work(>hdcp_prop_work);
> > -   schedule_delayed_work(>hdcp_check_work,
> > - DRM_HDCP_CHECK_PERIOD_MS);
> >  out:
> > mutex_unlock(>hdcp_mutex);
> > return ret;
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 05/40] drm/i915: wrapping all hdcp var into intel_hdcp

[C, Ramalingam]

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Tuesday, July 10, 2018 2:00 AM
> To: C, Ramalingam 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> dan...@ffwll.ch; Winkler, Tomas ; Usyskin,
> Alexander ; Shankar, Uma
> 
> Subject: Re: [PATCH v5 05/40] drm/i915: wrapping all hdcp var into intel_hdcp
> 
> On Wed, Jun 27, 2018 at 02:09:54PM +0530, Ramalingam C wrote:
> > Considering significant number of HDCP specific variables, it will be
> > clean to have separate struct for HDCP.
> >
> > New structure called intel_hdcp is added within intel_connector.
> >
> > v2:
> >   struct hdcp statically allocated. [Sean Paul]
> >   enable and disable function parameters are retained.[Sean Paul]
> > v3:
> >   No Changes.
> > v4:
> >   Commit msg is rephrased [Uma]
> > v5:
> >   Comment for mutex definition.
> >
> > Signed-off-by: Ramalingam C 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c |  7 +--
> >  drivers/gpu/drm/i915/intel_drv.h | 15 --
> >  drivers/gpu/drm/i915/intel_hdcp.c| 94 
> > --
> --
> >  3 files changed, 67 insertions(+), 49 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 3d849ec17f5c..ef09bb89d2ca 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15856,9 +15856,10 @@ static void intel_hpd_poll_fini(struct drm_device
> *dev)
> > for_each_intel_connector_iter(connector, _iter) {
> > if (connector->modeset_retry_work.func)
> > cancel_work_sync(>modeset_retry_work);
> > -   if (connector->hdcp_shim) {
> > -   cancel_delayed_work_sync(
> >hdcp_check_work);
> > -   cancel_work_sync(>hdcp_prop_work);
> > +   if (connector->hdcp.hdcp_shim) {
> > +   cancel_delayed_work_sync(
> > +   >hdcp.hdcp_check_work);
> > +   cancel_work_sync(
> >hdcp.hdcp_prop_work);
> > }
> > }
> > drm_connector_list_iter_end(_iter);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 578346b8d7e2..eb480574a92e 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -377,6 +377,15 @@ struct intel_hdcp_shim {
> > bool *hdcp_capable);
> >  };
> >
> > +struct intel_hdcp {
> > +   const struct intel_hdcp_shim *hdcp_shim;
> > +   /* Mutex for hdcp state of the connector */
> > +   struct mutex hdcp_mutex;
> > +   uint64_t hdcp_value;
> > +   struct delayed_work hdcp_check_work;
> > +   struct work_struct hdcp_prop_work;
> 
> Now that they're in their own struct, you can probably drop the hdcp_* prefix
> from the struct members.

Sure I will do that.
> 
> > +};
> > +
> >  struct intel_connector {
> > struct drm_connector base;
> > /*
> > @@ -409,11 +418,7 @@ struct intel_connector {
> > /* Work struct to schedule a uevent on link train failure */
> > struct work_struct modeset_retry_work;
> >
> > -   const struct intel_hdcp_shim *hdcp_shim;
> > -   struct mutex hdcp_mutex;
> > -   uint64_t hdcp_value; /* protected by hdcp_mutex */
> > -   struct delayed_work hdcp_check_work;
> > -   struct work_struct hdcp_prop_work;
> > +   struct intel_hdcp hdcp;
> >  };
> >
> >  struct intel_digital_connector_state { diff --git
> > a/drivers/gpu/drm/i915/intel_hdcp.c
> > b/drivers/gpu/drm/i915/intel_hdcp.c
> > index 0cc6a861bcf8..65bbe5874eee 100644
> > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > @@ -626,6 +626,7 @@ struct intel_digital_port *conn_to_dig_port(struct
> > intel_connector *connector)
> >
> >  static int _intel_hdcp_disable(struct intel_connector *connector)  {
> > +   struct intel_hdcp *hdcp = >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; @@ -641,7 +642,7 @@
> > static int _intel_hdcp_disable(struct intel_connector *connector)
> > return -ETIMEDOUT;
> > }
> >
> > -   ret = connector->hdcp_shim->toggle_signalling(intel_dig_por

Re: [Intel-gfx] [PATCH v5 02/40] drm: HDMI and DP specific HDCP2.2 defines

[C, Ramalingam]

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Tuesday, July 10, 2018 1:53 AM
> To: C, Ramalingam 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> dan...@ffwll.ch; Winkler, Tomas ; Usyskin,
> Alexander ; Shankar, Uma
> 
> Subject: Re: [Intel-gfx] [PATCH v5 02/40] drm: HDMI and DP specific HDCP2.2
> defines
> 
> On Wed, Jun 27, 2018 at 02:09:51PM +0530, Ramalingam C wrote:
> > This patch adds HDCP register definitions for HDMI and DP HDCP
> > adaptations.
> >
> > HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h,
> > where as HDCP2.2 register offsets in DPCD offsets are defined at
> > drm_dp_helper.h.
> >
> > v2:
> >   bit_field definitions are replaced by macros. [Tomas and Jani]
> > v3:
> >   No Changes.
> > v4:
> >   Comments style and typos are fixed [Uma]
> > v5:
> >   Fix for macros.
> >
> > Signed-off-by: Ramalingam C 
> > ---
> >  include/drm/drm_dp_helper.h | 51
> +
> >  include/drm/drm_hdcp.h  | 30 ++
> >  2 files changed, 81 insertions(+)
> >
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index c01564991a9f..17e0889d6aaa 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -904,6 +904,57 @@
> >  #define DP_AUX_HDCP_KSV_FIFO   0x6802C
> >  #define DP_AUX_HDCP_AINFO  0x6803B
> >
> > +/* DP HDCP2.2 parameter offsets in DPCD address space */
> > +#define DP_HDCP_2_2_REG_RTX_OFFSET 0x69000
> > +#define DP_HDCP_2_2_REG_TXCAPS_OFFSET  0x69008
> > +#define DP_HDCP_2_2_REG_CERT_RX_OFFSET 0x6900B
> > +#define DP_HDCP_2_2_REG_RRX_OFFSET 0x69215
> > +#define DP_HDCP_2_2_REG_RX_CAPS_OFFSET 0x6921D
> > +#define DP_HDCP_2_2_REG_EKPUB_KM_OFFSET0x69220
> > +#define DP_HDCP_2_2_REG_EKH_KM_OFFSET  0x692A0
> > +#define DP_HDCP_2_2_REG_M_OFFSET   0x692B0
> > +#define DP_HDCP_2_2_REG_HPRIME_OFFSET  0x692C0
> > +#define DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET   0x692E0
> > +#define DP_HDCP_2_2_REG_RN_OFFSET  0x692F0
> > +#define DP_HDCP_2_2_REG_LPRIME_OFFSET  0x692F8
> > +#define DP_HDCP_2_2_REG_EDKEY_KS_OFFSET0x69318
> > +#defineDP_HDCP_2_2_REG_RIV_OFFSET  0x69328
> > +#define DP_HDCP_2_2_REG_RXINFO_OFFSET  0x69330
> > +#define DP_HDCP_2_2_REG_SEQ_NUM_V_OFFSET   0x69332
> > +#define DP_HDCP_2_2_REG_VPRIME_OFFSET  0x69335
> > +#define DP_HDCP_2_2_REG_RECV_ID_LIST_OFFSET0x69345
> > +#define DP_HDCP_2_2_REG_V_OFFSET   0x693E0
> > +#define DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET   0x693F0
> > +#define DP_HDCP_2_2_REG_K_OFFSET   0x693F3
> > +#define DP_HDCP_2_2_REG_STREAM_ID_TYPE_OFFSET  0x693F5
> > +#define DP_HDCP_2_2_REG_MPRIME_OFFSET  0x69473
> > +#define DP_HDCP_2_2_REG_RXSTATUS_OFFSET0x69493
> > +#define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET 0x69494
> > +#define DP_HDCP_2_2_REG_DBG_OFFSET 0x69518
> > +
> > +/* DP HDCP message start offsets in DPCD address space */
> > +#define DP_HDCP_2_2_AKE_INIT_OFFSET
>   DP_HDCP_2_2_REG_RTX_OFFSET
> > +#define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET
>   DP_HDCP_2_2_REG_CERT_RX_OFFSET
> > +#define DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET
>   DP_HDCP_2_2_REG_EKPUB_KM_OFFSET
> > +#define DP_HDCP_2_2_AKE_STORED_KM_OFFSET
>   DP_HDCP_2_2_REG_EKH_KM_OFFSET
> > +#define DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET
>   DP_HDCP_2_2_REG_HPRIME_OFFSET
> > +#define DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET \
> > +
>   DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET
> > +#define DP_HDCP_2_2_LC_INIT_OFFSET
>   DP_HDCP_2_2_REG_RN_OFFSET
> > +#define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET
>   DP_HDCP_2_2_REG_LPRIME_OFFSET
> > +#define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET
>   DP_HDCP_2_2_REG_EDKEY_KS_OFFSET
> > +#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
>   DP_HDCP_2_2_REG_RXINFO_OFFSET
> > +#define DP_HDCP_2_2_REP_SEND_ACK_OFFSET
>   DP_HDCP_2_2_REG_V_OFFSET
> > +#define DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET
>   DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET
> > +#define DP_HDCP_2_2_REP_STREAM_READY_OFFSET
>   DP_HDCP_2_2_REG_MPRIME_OFFSET
> > +
> > +#define HDCP_2_2_DP_RXSTATUS_LEN   1
> > +#define HDCP_2_2_DP_RXSTATUS_READY(x)  ((x) & BIT(0))
> > +#define HDCP_2_2_DP_RXSTATUS_H_PRIME(x) 

Re: [Intel-gfx] [PATCH v5 01/40] drm: hdcp2.2 authentication msg definitions

[C, Ramalingam]

Thanks seanpaul for the reviews.

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Tuesday, July 10, 2018 1:51 AM
> To: C, Ramalingam 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> dan...@ffwll.ch; Winkler, Tomas ; Usyskin,
> Alexander ; Shankar, Uma
> 
> Subject: Re: [Intel-gfx] [PATCH v5 01/40] drm: hdcp2.2 authentication msg
> definitions
> 
> On Wed, Jun 27, 2018 at 02:09:50PM +0530, Ramalingam C wrote:
> > This patch defines the hdcp2.2 protocol messages for authentication.
> >
> > v2:
> >   bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
> >   prefix HDCP_2_2_ is added to the macros. [Tomas]
> > v3:
> >   No Changes.
> > v4:
> >   Style and spellings are fixed [Uma]
> > v5:
> >   Fix for macros.
> >
> > Signed-off-by: Ramalingam C 
> > ---
> >  include/drm/drm_hdcp.h | 179
> > +
> >  1 file changed, 179 insertions(+)
> >
> > diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
> > 98e63d870139..3e963c5d04b2 100644
> > --- a/include/drm/drm_hdcp.h
> > +++ b/include/drm/drm_hdcp.h
> > @@ -38,4 +38,183 @@
> >  #define DRM_HDCP_DDC_BSTATUS   0x41
> >  #define DRM_HDCP_DDC_KSV_FIFO  0x43
> >
> > +#define DRM_HDCP_1_4_SRM_ID0x8
> > +#define DRM_HDCP_1_4_VRL_LENGTH_SIZE   3
> > +#define DRM_HDCP_1_4_DCP_SIG_SIZE  40
> 
> These don't seem to be related to the patch?
> 
> > +
> > +/* Protocol message definition for HDCP2.2 specification */
> > +#define HDCP_STREAM_TYPE0  0x00
> > +#define HDCP_STREAM_TYPE1  0x01
> 
> Why not HDCP_2_2 prefix?
Though they are introduced at HDCP2.2, this is classification of the streams.
And Type 0 can be transmitted on HDCP1.4.
So keeping it as generic name with no version mentioned.
> 
> > +
> > +/* HDCP2.2 Msg IDs */
> > +#define HDCP_2_2_NULL_MSG  1
> > +#define HDCP_2_2_AKE_INIT  2
> > +#define HDCP_2_2_AKE_SEND_CERT 3
> > +#define HDCP_2_2_AKE_NO_STORED_KM  4
> > +#define HDCP_2_2_AKE_STORED_KM 5
> > +#define HDCP_2_2_AKE_SEND_HPRIME   7
> > +#define HDCP_2_2_AKE_SEND_PAIRING_INFO 8
> > +#define HDCP_2_2_LC_INIT   9
> > +#define HDCP_2_2_LC_SEND_LPRIME10
> > +#define HDCP_2_2_SKE_SEND_EKS  11
> > +#define HDCP_2_2_REP_SEND_RECVID_LIST  12
> > +#define HDCP_2_2_REP_SEND_ACK  15
> > +#define HDCP_2_2_REP_STREAM_MANAGE 16
> > +#define HDCP_2_2_REP_STREAM_READY  17
> > +#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
> > +
> > +#define HDCP_2_2_RTX_LEN   8
> > +#define HDCP_2_2_RRX_LEN   8
> > +
> > +#define HDCP_2_2_K_PUB_RX_MOD_N_LEN128
> > +#define HDCP_2_2_K_PUB_RX_EXP_E_LEN3
> > +#define HDCP_2_2_K_PUB_RX_LEN
>   (HDCP_2_2_K_PUB_RX_MOD_N_LEN + \
> > +
> HDCP_2_2_K_PUB_RX_EXP_E_LEN)
> > +
> > +#define HDCP_2_2_DCP_LLC_SIG_LEN   384
> > +
> > +#define HDCP_2_2_E_KPUB_KM_LEN 128
> > +#define HDCP_2_2_E_KH_KM_M_LEN (16 + 16)
> > +#define HDCP_2_2_H_PRIME_LEN   32
> > +#define HDCP_2_2_E_KH_KM_LEN   16
> > +#define HDCP_2_2_RN_LEN8
> > +#define HDCP_2_2_L_PRIME_LEN   32
> > +#define HDCP_2_2_E_DKEY_KS_LEN 16
> > +#define HDCP_2_2_RIV_LEN   8
> > +#define HDCP_2_2_SEQ_NUM_LEN   3
> > +#define HDCP_2_2_LPRIME_HALF_LEN
>   (HDCP_2_2_L_PRIME_LEN / 2)
> > +#define HDCP_2_2_RECEIVER_ID_LEN   DRM_HDCP_KSV_LEN
> > +#define HDCP_2_2_MAX_DEVICE_COUNT  31
> > +#define HDCP_2_2_RECEIVER_IDS_MAX_LEN
>   (HDCP_2_2_RECEIVER_ID_LEN * \
> > +
> HDCP_2_2_MAX_DEVICE_COUNT)
> > +#define HDCP_2_2_MPRIME_LEN32
> > +
> > +/* Following Macros take a byte at a time for bit(s) masking */
> > +/*
> > + * TODO: This has to be changed for DP MST, as multiple stream on
> > + * same port is possible.
> > + * For HDCP2.2 on HDMI and DP SST this value is always 1.
> > + */
> > +#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT   1
> > +#define HDCP_2_2_TXCAP_MASK_LEN

Re: [Intel-gfx] [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP

[C, Ramalingam]

Best Regards,
Ramalingam C

> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, June 20, 2018 5:14 PM
> To: C, Ramalingam 
> Cc: intel-gfx ; dri-devel  de...@lists.freedesktop.org>; Sean Paul ; Chris
> Wilson ; Nikula, Jani ;
> Winkler, Tomas ; Usyskin, Alexander
> ; Shankar, Uma ;
> Sharma, Shashank 
> Subject: Re: [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP
> 
> On Wed, Jun 20, 2018 at 12:19 PM, Ramalingam C 
> wrote:
> >
> >
> > On Thursday 31 May 2018 12:52 PM, Daniel Vetter wrote:
> >>
> >> On Mon, May 21, 2018 at 06:23:57PM +0530, Ramalingam C wrote:
> >>>
> >>> 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.
> >>>
> >>> Note: Chris Wilson suggested alternate method for waiting for
> >>> CP_IRQ, than completions concept. WIP to understand and implement
> >>> that, if needed. Just to unblock the review of other changes, v2
> >>> still continues with completions.
> >>>
> >>> 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]
> >>>
> >>> Signed-off-by: Ramalingam C 
> >>> ---
> >>>   drivers/gpu/drm/i915/intel_dp.c   | 358
> >>> ++
> >>>   drivers/gpu/drm/i915/intel_drv.h  |   7 +
> >>>   drivers/gpu/drm/i915/intel_hdcp.c |   5 +
> >>>   3 files changed, 370 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >>> b/drivers/gpu/drm/i915/intel_dp.c index 528407d608c8..ee71a26ec23f
> >>> 100644
> >>> --- a/drivers/gpu/drm/i915/intel_dp.c
> >>> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >>> @@ -31,6 +31,7 @@
> >>>   #include 
> >>>   #include 
> >>>   #include 
> >>> +#include 
> >>>   #include 
> >>>   #include 
> >>>   #include  @@ -5057,6 +5058,28 @@ void
> >>> intel_dp_encoder_suspend(struct intel_encoder
> >>> *intel_encoder)
> >>> pps_unlock(intel_dp);
> >>>   }
> >>>   +static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
> >>> +int timeout) {
> >>> +   long ret;
> >>> +
> >>> +   /* Reinit */
> >>> +   atomic_set(>cp_irq_recved, 0);
> >>> +
> >>> +#define C (atomic_read(>cp_irq_recved) > 0)
> >>> +   ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue,
> >>> +C,
> >>> +
> >>> msecs_to_jiffies(timeout));
> >>> +
> >>> +   if (ret > 0) {
> >>> +   atomic_set(>cp_irq_recved, 0);
> >>> +   return 0;
> >>> +   } else if (!ret) {
> >>> +   return -ETIMEDOUT;
> >>> +   }
> >>> +   return (int)ret;
> >>> +}
> >>> +
> >>> +
> >>>   static
> >>>   int intel_dp_hdcp_write_an_aksv(struct intel_digital_port
> >>> *intel_dig_port,
> >>> u8 *an) @@ -5275,6 +5298,335 @@ int
> >>> intel_dp_hdcp_capable(struct intel_digital_port *intel_dig_port,
> >>> return 0;
> >>>   }
> >>>   +static
> >>> +int intel_dpcd_offset_for_hdcp2_msgid(uint8_t byte, unsigned int
> >>> *offset)
> >>
> >> Ugh, this is annoying that we have to map things around like that.
> >> But looking at the numbers the standards really don't seem to match at all.
> >
> > Sorry i am not getting about not matching part.
> > You mean some offsets and timeouts are not matching with spec?
> 
> match as in you can't just compute them using a base_offset + hdcp_msgid 
> trick,
> you do have to use the lookup table. The numbers itself match the spec, it's 
> just
> that the specs are all inconsistent with each another for no real good reason.
> 
> >>
> >>
> >> Instead of open-coding this I su

Re: [Intel-gfx] [PATCH v4 00/41] drm/i915: Implement HDCP2.2

[C, Ramalingam]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Tuesday, May 29, 2018 2:01 PM
> To: C, Ramalingam 
> Cc: Daniel Vetter ; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; seanp...@chromium.org; chris@chris-
> wilson.co.uk; jani.nik...@linux.intel.com; Winkler, Tomas
> ; Usyskin, Alexander
> ; Shankar, Uma ;
> Sharma, Shashank 
> Subject: Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2
> 
> On Tue, May 29, 2018 at 07:51:56AM +, C, Ramalingam wrote:
> > > -Original Message-
> > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> > > Daniel Vetter
> > > Sent: Tuesday, May 29, 2018 12:27 PM
> > > To: C, Ramalingam 
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > dri-de...@lists.freedesktop.org; seanp...@chromium.org;
> > > dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> > > jani.nik...@linux.intel.com; Winkler, Tomas
> > > ; Usyskin, Alexander
> > > ; Shankar, Uma ;
> > > Sharma, Shashank 
> > > Subject: Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2
> > >
> > > On Mon, May 21, 2018 at 06:23:19PM +0530, Ramalingam C wrote:
> > > > The sequence for HDCP2.2 authentication and encryption is
> > > > implemented in I915. 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.
> > > >
> > > > DRM_I915 selects INTEL_MEI_HDCP, which selects INTEL_MEI_ME and
> > > > INTEL_MEI. If we are interested in disabling the MEI_HDCP and MEI
> > > > Bus then we need an option to disable the HDCP2.2 in I915 (like
> > > > DRM_I915_HDCP2.2!?). Till then they are binded.
> > > >
> > > > 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 streams.
> > > >
> > > > Thanks a lot for Usyskin, Alexander and Uma shankar for the review of 
> > > > v3.
> > > > Thanks Daniel vetter for guiding me to test and confirm that there
> > > > is no locking issue with respect to notifier usage between I915 and
> MEI_HDCP.
> > > >
> > > > Major Changes in v4:
> > > >   - GMBus Changes to implement the burst read as generic
> > > > [Jani, Ville and Daniel]
> > > >   - Polling is added for extra Notifier notification when I915 and
> > > > MEI_HDCP are modules.
> > > >   - Comment and style issues and typos are fixed [Uma and Alexander]
> > > >   - INTEL_MEI_HDCP, INTEL_MEI_ME and INTEL_MEI are selected by I915.
> > > >   - Fixed the #if in include/linux/mei_hdcp.h for build issues.
> > > >
> > > > GMBus changes are added here for completeness of the series. They
> > > > are in review at https://patchwork.freedesktop.org/series/41632/ also.
> > >
> > > Please reply with a link to your github here (and include it in your
> > > next cover letter too). I can't ever find it when I need it :-/
> >
> > You can find a github repo for HDCP2.2 v4 series at
> > https://github.com/ramalingampc2008/drm-tip
> 
> Even nicer if you directly supply what I need to feed to git fetch (like a 
> git pull
> request over email):
> 
> https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v4
> 
> Then I can do a git fetch && git checkout FETCH_HEAD.

Ok. Sure.

Thanks,
Ram.

> 
> Thanks, Daniel
> 
> >
> > Thanks,
> > Ram
> >
> > >
> > > Thanks, Daniel
> > >
> > > >
> > > > Ramalingam C (40):
> > > >   drm: hdcp2.2 authentication msg definitions
> > > >   drm: HDMI and DP specific HDCP2.2 defines
> > > >   misc/mei/hdcp: Client driver for HDCP application
> > > >   misc/mei/hdcp: Notifier chain for mei cldev state change
> > > >   misc/mei/hdcp: Define ME FW interface for HDCP2.2
> > > >   linux/mei: Header for mei_hdcp driver interface
> > > >   misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
>

Re: [Intel-gfx] [PATCH v4 00/41] drm/i915: Implement HDCP2.2

[C, Ramalingam]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Tuesday, May 29, 2018 12:27 PM
> To: C, Ramalingam 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Winkler, Tomas ;
> Usyskin, Alexander ; Shankar, Uma
> ; Sharma, Shashank 
> Subject: Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2
> 
> On Mon, May 21, 2018 at 06:23:19PM +0530, Ramalingam C wrote:
> > The sequence for HDCP2.2 authentication and encryption is implemented
> > in I915. 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.
> >
> > DRM_I915 selects INTEL_MEI_HDCP, which selects INTEL_MEI_ME and
> > INTEL_MEI. If we are interested in disabling the MEI_HDCP and MEI Bus
> > then we need an option to disable the HDCP2.2 in I915 (like
> > DRM_I915_HDCP2.2!?). Till then they are binded.
> >
> > 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 streams.
> >
> > Thanks a lot for Usyskin, Alexander and Uma shankar for the review of v3.
> > Thanks Daniel vetter for guiding me to test and confirm that there is
> > no locking issue with respect to notifier usage between I915 and MEI_HDCP.
> >
> > Major Changes in v4:
> >   - GMBus Changes to implement the burst read as generic
> > [Jani, Ville and Daniel]
> >   - Polling is added for extra Notifier notification when I915 and
> > MEI_HDCP are modules.
> >   - Comment and style issues and typos are fixed [Uma and Alexander]
> >   - INTEL_MEI_HDCP, INTEL_MEI_ME and INTEL_MEI are selected by I915.
> >   - Fixed the #if in include/linux/mei_hdcp.h for build issues.
> >
> > GMBus changes are added here for completeness of the series. They are
> > in review at https://patchwork.freedesktop.org/series/41632/ also.
> 
> Please reply with a link to your github here (and include it in your next 
> cover
> letter too). I can't ever find it when I need it :-/

You can find a github repo for HDCP2.2 v4 series at 
https://github.com/ramalingampc2008/drm-tip 

Thanks,
Ram 

> 
> Thanks, Daniel
> 
> >
> > Ramalingam C (40):
> >   drm: hdcp2.2 authentication msg definitions
> >   drm: HDMI and DP specific HDCP2.2 defines
> >   misc/mei/hdcp: Client driver for HDCP application
> >   misc/mei/hdcp: Notifier chain for mei cldev state change
> >   misc/mei/hdcp: Define ME FW interface for HDCP2.2
> >   linux/mei: Header for mei_hdcp driver interface
> >   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
> >   drm/i915: wrapping all hdcp var into intel_hdcp
> >   drm/i915: Define HDCP2.2 related variables
> >   drm/i915: Define Intel HDCP2.2 registers
> >   drm/i915: Wrappers for mei HDCP2.2 services
> >   drm/i915: Implement HDCP2.2 receiver authentication
> >   drm/i915: Implement HDCP2.2 repeater authentication
> >   drm/i915: Enable and Disable HDCP2.2 port encryption
> >   drm/i915: Implement HDCP2.2 En/Dis-able
> >   drm/i915: Implement HDCP2.2 link integrity check
> >   drm/i915: Handle HDCP2.2 downstream topology change
> >   drm/i915: Pullout the bksv read and validation
> >   drm/i915: Initialize HDCP2.2 and its MEI interface
> >   drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable
> >   drm/i915: Enable superior HDCP ver that is capable
> >   drm/i915: Enable HDCP1.4 incase of HDCP2.2 failure
> >   drm/i915: hdcp_check_link only on CP_IRQ
> >   drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ
> >   drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
> >   drm/i915/gmbus: Enable burst read
> >   drm/i915: Impleme

Re: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP Pairing info

[C, Ramalingam]

> -Original Message-
> From: Usyskin, Alexander
> Sent: Thursday, May 17, 2018 11:29 AM
> To: C, Ramalingam <ramalinga...@intel.com>; Shankar, Uma
> <uma.shan...@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; seanp...@chromium.org; dan...@ffwll.ch;
> ch...@chris-wilson.co.uk; jani.nik...@linux.intel.com; Winkler, Tomas
> <tomas.wink...@intel.com>
> Cc: Vivi, Rodrigo <rodrigo.v...@intel.com>
> Subject: RE: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP 
> Pairing
> info
> 
> 
> 
> > -Original Message-
> > From: C, Ramalingam
> > Sent: Wednesday, May 16, 2018 18:53
> > To: Shankar, Uma <uma.shan...@intel.com>; intel-
> > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> > seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> > jani.nik...@linux.intel.com; Winkler, Tomas <tomas.wink...@intel.com>;
> > Usyskin, Alexander <alexander.usys...@intel.com>
> > Cc: Vivi, Rodrigo <rodrigo.v...@intel.com>
> > Subject: Re: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the
> > HDCP Pairing info
> >
> >
> >
> > On Wednesday 09 May 2018 03:58 PM, Shankar, Uma wrote:
> > >
> > >> -Original Message-
> > >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> > >> Behalf Of Ramalingam C
> > >> Sent: Tuesday, April 3, 2018 7:27 PM
> > >> To: intel-gfx@lists.freedesktop.org;
> > >> dri-de...@lists.freedesktop.org; seanp...@chromium.org;
> > >> dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> > >> jani.nik...@linux.intel.com; Winkler, Tomas
> > >> <tomas.wink...@intel.com>; Usyskin, Alexander
> > >> <alexander.usys...@intel.com>
> > >> Cc: Vivi, Rodrigo <rodrigo.v...@intel.com>
> > >> Subject: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP
> > >> Pairing info
> > >>
> > >> Provides Pairing info to ME to store.
> > >>
> > >> Pairing is a process to fast track the subsequent authentication
> > >> with the same HDCP sink.
> > >>
> > >> On Success, received HDCP pairing info is stored in non-volatile
> > >> memory
> > of ME.
> > >>
> > >> v2:
> > >>   Rebased.
> > >> v3:
> > >>   cldev is passed as first parameter [Tomas]
> > >>   Redundant comments and cast are removed [Tomas]
> > >>
> > >> Signed-off-by: Ramalingam C <ramalinga...@intel.com>
> > >> ---
> > >> drivers/misc/mei/hdcp/mei_hdcp.c | 61
> > >> 
> > >> include/linux/mei_hdcp.h | 10 +++
> > >> 2 files changed, 71 insertions(+)
> > >>
> > >> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > >> b/drivers/misc/mei/hdcp/mei_hdcp.c
> > >> index fa548310de7a..60afdd0cee79 100644
> > >> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > >> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > >> @@ -244,6 +244,67 @@ int mei_verify_hprime(struct mei_cl_device
> > >> *cldev, struct mei_hdcp_data *data,  }
> > >> EXPORT_SYMBOL(mei_verify_hprime);
> > >>
> > >> +/**
> > > Drop the extra *, unless you really love it :)
> > ha ha. Actually I have added intentionally. But removing them across
> > all patches as per your suggestions. :)
> 
> /** is a syntax for KDoc, so if you want to receive automatic code
> documentation you should use it and adhere to KDoc syntax

Thanks Alexander for the information. At present I am not adding the KDoc  
support, if it is not compulsory.
So I will remove the /**.

--Ram
> > >
> > >> + * mei_store_pairing_info:
> > >> + *  Function to store pairing info received from panel
> > >> + *
> > >> + * @cldev   : Pointer for mei client device
> > >> + * @data: Intel HW specific Data
> > >> + * @pairing_info: Pointer for AKE_Send_Pairing_Info
> > >> + *
> > >> + * Returns 0 on Success, <0 on Failure */
> > >> +
> > >> +int mei_store_pairing_info(struct mei_cl_device *cldev,
> > >> +   struct mei_hdcp_data *data,
> > >> +   struct hdcp2_ake_send_pairing_info 
> > >> *pairing_info)
> > {
> > >> +struct wired_cmd_ake_send_pairing_info_in pairing_info_

Re: [Intel-gfx] [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec

[C, Ramalingam]

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Monday, February 5, 2018 10:21 PM
> To: C, Ramalingam <ramalinga...@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; seanp...@chromium.org; Vivi, Rodrigo
> <rodrigo.v...@intel.com>; Sharma, Shashank <shashank.sha...@intel.com>;
> daniel.vet...@ffwll.ch
> Subject: Re: [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec
> 
> On Sat, Feb 03, 2018 at 03:39:02AM +0530, Ramalingam C wrote:
> > This series is developed to address the expectations from HDCP
> > compliance test specification.
> >
> > 6/8 patches are for fixing failures in one or more compliance test
> > cases
> > 2 patches are Good to have kind. Not related to compliance.
> >
> > Thanks to Seanpaul for immediate review comments on v1 and v2.
> 
> Hi Ram,
> Everything looks good except for my comments in patch 4. Could you please
> resping that one last patch (no need to send the whole series again)?

Sure

--Ram
> 
> Thanks,
> 
> Sean
> 
> >
> > Ramalingam C (8):
> >   drm/i915: Handle failure from 2nd stage HDCP auth
> >   drm/i915: Stop encryption for repeater with no sink
> >   drm/i915: Connector info in HDCP debug msgs
> >   drm/i915: Retry HDCP bksv read
> >   drm/i915: Optimize HDCP key load
> >   drm/i915: Detect panel's hdcp capability
> >   drm/i915: Reauthenticate HDCP on failure
> >   drm/i915: fix misalignment in HDCP register def
> >
> >  drivers/gpu/drm/i915/i915_reg.h   | 58 +-
> >  drivers/gpu/drm/i915/intel_dp.c   | 39 +++--
> >  drivers/gpu/drm/i915/intel_drv.h  |  4 ++
> > drivers/gpu/drm/i915/intel_hdcp.c | 88
> > ++-
> >  4 files changed, 137 insertions(+), 52 deletions(-)
> >
> > --
> > 2.7.4
> >
> 
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
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: II stage HDCP auth for repeater only

[C, Ramalingam]

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Friday, January 19, 2018 3:54 AM
> To: C, Ramalingam <ramalinga...@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; seanp...@chromium.org;
> daniel.vet...@ffwll.ch; Vivi, Rodrigo <rodrigo.v...@intel.com>; Sharma,
> Shashank <shashank.sha...@intel.com>
> Subject: Re: [PATCH 2/4] drm/i915: II stage HDCP auth for repeater only
> 
> On Thu, Jan 18, 2018 at 11:18:06AM +0530, Ramalingam C wrote:
> > Second stage of HDCP authentication required only if the HDCP sink is
> > a repeater.
> >
> > This patch imposes above condition on second stage HDCP authentication.
> 
> Hi Ram,
> This is already enforced in intel_hdcp_auth_downstream()

I am not able to locate any check for repeater capability at start of 
downstream auth.

I am not sure whether you are referring to number of downstream device count 
check.
That is valid after poll for ksv_fifo ready. We don't want to wait for 5Sec 
timeout in poll to detect the repeater cap.

And since the caller is handy with the flag for repeater cap, it is best to 
decide on the call for downstream auth itself.

Thanks
--Ram
> 
> Thanks,
> Sean
> 
> >
> > Signed-off-by: Ramalingam C <ramalinga...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_hdcp.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> > b/drivers/gpu/drm/i915/intel_hdcp.c
> > index 6ce6559897a6..b48c72cd0906 100644
> > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > @@ -493,7 +493,10 @@ static int intel_hdcp_auth(struct intel_digital_port
> *intel_dig_port,
> >  * on those as well.
> >  */
> >
> > -   return intel_hdcp_auth_downstream(intel_dig_port, shim);
> > +   if (repeater_present)
> > +   return intel_hdcp_auth_downstream(intel_dig_port, shim);
> > +
> > +   return 0;
> >  }
> >
> >  static
> > --
> > 2.7.4
> >
> 
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/2] i915/drrs/debugfs: crtc id and psr status

[C, Ramalingam]

> -Original Message-
> From: Vivi, Rodrigo
> Sent: Saturday, November 18, 2017 12:26 AM
> To: C, Ramalingam <ramalinga...@intel.com>
> Cc: Zanoni, Paulo R <paulo.r.zan...@intel.com>; ch...@chris-wilson.co.uk;
> intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 2/2] i915/drrs/debugfs: crtc id and psr 
> status
> 
> On Tue, Nov 07, 2017 at 06:40:08PM +, Ramalingam C wrote:
> > From: "C, Ramalingam" <ramalinga...@intel.com>
> >
> > Existing debugfs entry i915_drrs_status is updated with crtc id and if
> > PSR is cause for DRRS disabled state.
> >
> > [v2]: Dropped the module parameter details as ctl moved from module
> >   parameter to debugfs. [Rodrigo]
> >
> > Signed-off-by: C, Ramalingam <ramalinga...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 0c1501fe4c9f..6c2e8346b9a7 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -3567,7 +3567,10 @@ static void drrs_status_per_crtc(struct
> > seq_file *m,
> >
> > /* disable_drrs() will make drrs->dp NULL */
> > if (!drrs->dp) {
> > -   seq_puts(m, "Idleness DRRS: Disabled");
> > +   seq_puts(m, "Idleness DRRS: Disabled\n");
> > +   if (dev_priv->psr.enabled)
> > +   seq_puts(m,
> > +   "\tAs PSR is enabled, DRRS is not enabled\n");
> 
> this seems good...
> 
> > mutex_unlock(>mutex);
> > return;
> > }
> > @@ -3611,7 +3614,7 @@ static int i915_drrs_status(struct seq_file *m, void
> *unused)
> > for_each_intel_crtc(dev, intel_crtc) {
> > if (intel_crtc->base.state->active) {
> > active_crtc_cnt++;
> > -   seq_printf(m, "\nCRTC %d:  ", active_crtc_cnt);
> > +   seq_printf(m, "\nCRTC %d: ", intel_crtc->base.base.id);
> 
> this seems for a separated patch...
> or at least missing an explanation why...
This changes not needed for debugfs control of drrs. As of now debugfs provides 
the crtc index in the active crtc list. Instead providing the crtc id might 
help to identify the crtc, that the debuginfo is associated to.

Anyway as there is no usecase that need this change, I will remove it from this 
patch.

Thanks
-Ram
> 
> >
> > drrs_status_per_crtc(m, dev, intel_crtc);
> > }
> > --
> > 2.7.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Runtime disable for eDP DRRS

[C, Ramalingam]

Thanks for reviewing these changes Rodrigo.

> -Original Message-
> From: Vivi, Rodrigo
> Sent: Saturday, November 18, 2017 12:24 AM
> To: C, Ramalingam <ramalinga...@intel.com>
> Cc: Zanoni, Paulo R <paulo.r.zan...@intel.com>; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Runtime disable for eDP DRRS
> 
> On Tue, Nov 07, 2017 at 06:38:23PM +0000, Ramalingam C wrote:
> > From: "C, Ramalingam" <ramalinga...@intel.com>
> >
> > Debugfs called i915_drrs_ctl is added to enable and disable the eDP
> > DRRS. Writing 0 will disable the feature, whereas non-zero will enable
> > the feature.
> >
> > Possibility of disabling the DRRS, enables the testing of the
> > frontbuffer tracking based features (FBC, DRRS and PSR) as standalone
> > or any combination of the set.
> >
> > [v2]: ctl interface is moved from module parameter to debugfs
> > [Rodrigo]
> 
> Thanks
> 
> >
> > Signed-off-by: C, Ramalingam <ramalinga...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 43
> > -
> >  1 file changed, 42 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 0bb6e01121fc..0c1501fe4c9f 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -4747,6 +4747,46 @@ static const struct file_operations
> i915_hpd_storm_ctl_fops = {
> > .write = i915_hpd_storm_ctl_write
> >  };
> >
> > +static int i915_drrs_ctl_set(void *data, u64 val) {
> > +   struct drm_i915_private *dev_priv = data;
> > +   struct drm_device *dev = _priv->drm;
> > +   struct intel_crtc *intel_crtc;
> > +   struct intel_encoder *encoder;
> > +   struct intel_dp *intel_dp;
> > +
> > +   if (INTEL_GEN(dev_priv) < 7)
> 
> I believe we need to define a HAS_DRRS(dev_priv) which based on what is on
> intel_cpu_transcoder_set_m_n would be
> (IS_CHERRYVIEW(dev_priv) || INTEL_GEN(dev_priv) < 8)

Actually programming of pll divider m and n changes between platforms. Hence 
this check was there.
But all the platforms from Gen 7 has the DRRS support. Do we still need a macro 
for this check?

-Ram
> 
> > +   return -ENODEV;
> > +
> > +   drm_modeset_lock_all(dev);
> 
> my first reaction to this was: "why do you need to lock all modeset?!"
> But this simplify a lot the logic here...
> This assure that drrs is really not getting changed from other places.
> 
> > +   for_each_intel_crtc(dev, intel_crtc) {
> > +   if (!intel_crtc->base.state->active ||
> > +   !intel_crtc->config->has_drrs)
> 
> I was going to say that this check already happens inside enable and disable
> functions... But I see the reason why to check before the unecessary noise.
> 
> > +   continue;
> > +
> > +   for_each_encoder_on_crtc(dev, _crtc->base, encoder) {
> > +   if (encoder->type != INTEL_OUTPUT_EDP)
> > +   continue;
> > +
> > +   DRM_DEBUG_DRIVER("Manually %sabling DRRS.
> %llu\n",
> > +   val ? "en" : "dis", val);
> > +
> > +   intel_dp = enc_to_intel_dp(>base);
> > +   if (val)
> > +   intel_edp_drrs_enable(intel_dp,
> > +   intel_crtc->config);
> > +   else
> > +   intel_edp_drrs_disable(intel_dp,
> > +   intel_crtc->config);
> > +   }
> > +   }
> > +   drm_modeset_unlock_all(dev);
> > +
> > +   return 0;
> > +}
> 
> It seems simple and effective. Simpler than I imagined...
> My only question is about that HAS_DRRS and when to skip here...
> 
> > +
> > +DEFINE_SIMPLE_ATTRIBUTE(i915_drrs_ctl_fops, NULL, i915_drrs_ctl_set,
> > +"%llu\n");
> > +
> >  static const struct drm_info_list i915_debugfs_list[] = {
> > {"i915_capabilities", i915_capabilities, 0},
> > {"i915_gem_objects", i915_gem_object_info, 0}, @@ -4828,7 +4868,8
> @@
> > static const struct i915_debugfs_files {
> > {"i915_dp_test_active", _displayport_test_active_fops},
> > {"i915_guc_log_control", _guc_log_control_fops},
> > {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
> > -   {"i915_ipc_status", _ipc_status_fops}
> > +   {"i915_ipc_status", _ipc_status_fops},
> > +   {"i915_drrs_ctl", _drrs_ctl_fops}
> >  };
> >
> >  int i915_debugfs_register(struct drm_i915_private *dev_priv)
> > --
> > 2.7.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Runtime disable for eDP DRRS

[C, Ramalingam]

> -Original Message-
> From: Vivi, Rodrigo
> Sent: Wednesday, November 1, 2017 12:27 AM
> To: C, Ramalingam <ramalinga...@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R
> <paulo.r.zan...@intel.com>; ch...@chris-wilson.co.uk
> Subject: Re: [PATCH 1/2] drm/i915: Runtime disable for eDP DRRS
> 
> On Tue, Oct 31, 2017 at 09:20:42AM +0000, Ramalingam C wrote:
> > From: "C, Ramalingam" <ramalinga...@intel.com>
> >
> > Module parameter enable_drrs(Boolean flag) is added to control the
> > eDP Idleness drrs enable flow.
> 
> This goes on the opposite direction of the current trends.
> 
> Well, I'm a big fan of the parameters, but there's a big effort
> going on to remove all kernel parameters. I believe it will
> be just a matter of time that we have to remove fbc and psr as well.
> So probably not a good idea to add something now that we will
> have to rework soon.
> 
> Maybe we could add a on/off toggle on DRRS now and then
> when we remove the parameter for fbc and psr we also add toggles
> on debugfs...

Based on our offline discussion, I will use the debugfs to toggle the DRRS 
instead of modparams.
Once the code is ready I will share it for the review.

Thanks
--Ram
> 
> Thanks,
> Rodrigo.
> 
> >
> > Modification to this module parameter will be considered on next
> > eDP_DRRS enable flow. So after module parameter update, a modeset
> > will help to modify the feature state as per the module parameter's
> > current state.
> >
> > Possibility of disabling the DRRS, enables the testing of the
> > frontbuffer tracking based features (FBC, DRRS and PSR) as standalone
> > or any combination of the set.
> >
> > Signed-off-by: C, Ramalingam <ramalinga...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_params.c | 3 +++
> >  drivers/gpu/drm/i915/i915_params.h | 3 ++-
> >  drivers/gpu/drm/i915/intel_dp.c| 6 ++
> >  3 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> > index b4faeb6aa2bd..32f06bb74f9d 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -190,3 +190,6 @@ i915_param_named(enable_dpcd_backlight, bool,
> 0600,
> >
> >  i915_param_named(enable_gvt, bool, 0400,
> > "Enable support for Intel GVT-g graphics virtualization host
> support(default:false)");
> > +
> > +i915_param_named_unsafe(enable_drrs, bool, 0600,
> > +   "Enable DRRS. (True=Enabled, False=Disabled [Default])");
> > diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> > index c7292268ed43..3c6fdce1c122 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -67,7 +67,8 @@
> > param(bool, nuclear_pageflip, false) \
> > param(bool, enable_dp_mst, true) \
> > param(bool, enable_dpcd_backlight, false) \
> > -   param(bool, enable_gvt, false)
> > +   param(bool, enable_gvt, false) \
> > +   param(bool, enable_drrs, false)
> >
> >  #define MEMBER(T, member, ...) T member;
> >  struct i915_params {
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index ca48bce23a6f..ff9964cf15cd 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5568,6 +5568,11 @@ void intel_edp_drrs_enable(struct intel_dp
> *intel_dp,
> > return;
> > }
> >
> > +   if (!i915_modparams.enable_drrs) {
> > +   DRM_DEBUG_KMS("DRRS is disabled from modparams\n");
> > +   return;
> > +   }
> > +
> > mutex_lock(_priv->drrs.mutex);
> > if (WARN_ON(dev_priv->drrs.dp)) {
> > DRM_ERROR("DRRS already enabled\n");
> > @@ -5817,6 +5822,7 @@ intel_dp_drrs_init(struct intel_connector
> *intel_connector,
> > }
> >
> > dev_priv->drrs.type = dev_priv->vbt.drrs_type;
> > +   i915_modparams.enable_drrs = true;
> >
> > dev_priv->drrs.refresh_rate_type = DRRS_HIGH_RR;
> > DRM_DEBUG_KMS("seamless DRRS supported for eDP panel.\n");
> > --
> > 2.7.4
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v3] drm/hdcp: drm enum property for CP State

[C, Ramalingam]

> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Wednesday, July 26, 2017 8:23 PM
> To: C, Ramalingam <ramalinga...@intel.com>
> Cc: Sean Paul <seanp...@chromium.org>; Vetter, Daniel
> <daniel.vet...@intel.com>; Intel Graphics Development  g...@lists.freedesktop.org>; dri-devel <dri-de...@lists.freedesktop.org>; 
> Daniel
> Vetter <dan...@ffwll.ch>
> Subject: Re: [RFC v3] drm/hdcp: drm enum property for CP State
> 
> On Wed, Jul 26, 2017 at 03:24:10PM +0530, Ramalingam C wrote:
> >
> >
> > On Tuesday 25 July 2017 06:04 PM, Sean Paul wrote:
> > > On Mon, Jul 24, 2017 at 2:12 PM, Ramalingam C <ramalinga...@intel.com>
> wrote:
> > > > DRM connector property is created to represent the content
> > > > protection state of the connector and to configure the same.
> > > >
> > > > Content protection states defined:
> > > >  DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED -
> Unsupported
> > > >  DRM_MODE_CONTENT_PROTECTION_DISABLE - Disabled
> > > >  DRM_MODE_CONTENT_PROTECTION_ENABLE  - Enabled
> > > >
> > > > v2: Redesigned the property to match with CP needs of CrOS [Sean].
> > > >
> > > > v3: Renamed the state names. Header is removed [sean].
> > > >
> > > > Signed-off-by: Ramalingam C <ramalinga...@intel.com>
> > > > ---
> > > >   drivers/gpu/drm/drm_connector.c | 14 ++
> > > >   include/drm/drm_mode_config.h   |  5 +
> > > >   include/uapi/drm/drm_mode.h |  5 +
> > > >   3 files changed, 24 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_connector.c
> > > > b/drivers/gpu/drm/drm_connector.c index 5cd61af..d6aaa08 100644
> > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > @@ -617,6 +617,13 @@ static const struct drm_prop_enum_list
> drm_link_status_enum_list[] = {
> > > >   };
> > > >   DRM_ENUM_NAME_FN(drm_get_link_status_name,
> > > > drm_link_status_enum_list)
> > > >
> > > > +static const struct drm_prop_enum_list drm_cp_enum_list[] = {
> > > > +   { DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED,
> "Unsupported" },
> > > You're still changing the enum names from the original patch/CrOS
> > > implementation.
> > >
> > > https://lists.freedesktop.org/archives/dri-devel/2014-December/07333
> > > 6.html
> > >
> > > https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_d
> > > isplay.cc?l=27
> >
> > Sean,
> >
> > I think we have bit of confusion here.
> 
> Agreed :)
> 
> >
> > And in previous discussion you were fine with new state of property
> > that is "unsupported" - indicates no common HDCP version is supported
> > on HDCP src and Sink combo.
> >
> > when CP is not possible, if property exist, userspace will interpret
> > it as CP is supported and attempt for enabling.
> > I prefer indicating Unsupported state than failing such requests blindly.
> >
> > In that case to interpret the new state, we need to change CrOS User
> > space code.
> >
> > In the RFC you mentioned above, two version of uapi interfaces are
> > discussed.
> > V1 uses single property to configure the CP and also for
> > status indication.
> > V2 uses two properties one for configuring and another one for
> > status of Content protection.
> >
> > But CrOS user space is currently using the V1 interface.
> >
> > which will be preferred approach right now (V1/V2)?
> > In either way we need to change the CrOS :(
> 
> We can't upstream code without a userspace implementation, so V1. Without
> any modifications.

Based on uAPI rules mentioned by Daniel, what I infer is that once a uAPI is in 
place,
usecase of uAPI cant be changed. It can be only be extended for future needs.

So IMHO it is better to shape the userspace as per the uAPI
interfaces that community want to have for longer run. And mainly we should 
adapt to a
interface which can be conveniently extended for HDCP2.2 and future specs 
versions.

So IMO it is worth seeing what it takes for CrOS Userspace changes for HDCP2.2 
interfaces.
And In the interest of having HDCP2.2 in their stack sooner,  if the CrOS 
community or Google
 is interested in providing that userspace support, it will be smoother to put 
the
complete and preferred uA

Re: [Intel-gfx] [PATCH] drm/i915: Redoing the PSR setup on resume

[C, Ramalingam]

Hi Daniel,

Thanks for your valuable review. I found that Rodrigo has submitted a solution 
for the same issue just before mine. I am seeing that solution is aligning to 
the expectations.
http://lists.freedesktop.org/archives/intel-gfx/2014-January/038749.html

So may be we can ignore this submission.

Thanks and Regards,
Ramalingam C.

 -Original Message-
 From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
 Sent: Sunday, January 26, 2014 1:41 AM
 To: C, Ramalingam
 Cc: Intel-gfx@lists.freedesktop.org
 Subject: Re: [Intel-gfx] [PATCH] drm/i915: Redoing the PSR setup on resume
 
 On Fri, Jan 24, 2014 at 12:50:17AM +0530, Ramalingam C wrote:
  Due to switch between console and graphics modes multiple psr_enable
  call will be made. On such occasions, to avoid repeated psr_setup, a
  flag called psr_setup_done is used.
 
  On suspend-resume, panel goes for a power cycle. Hence PSR setup
  should be redone to enable the PSR after suspend-resume.
  So this patch resets the corresponding flag, if it is set during the
  panel powerup process.
 
  Signed-off-by: Ramalingam C ramalinga...@intel.com
  ---
   drivers/gpu/drm/i915/intel_ddi.c |5 +
   1 file changed, 5 insertions(+)
 
  diff --git a/drivers/gpu/drm/i915/intel_ddi.c
  b/drivers/gpu/drm/i915/intel_ddi.c
  index 74749c6..686f8f6 100644
  --- a/drivers/gpu/drm/i915/intel_ddi.c
  +++ b/drivers/gpu/drm/i915/intel_ddi.c
  @@ -1201,6 +1201,11 @@ static void intel_ddi_pre_enable(struct
 intel_encoder *intel_encoder)
  if (type == INTEL_OUTPUT_EDP) {
  struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
  ironlake_edp_panel_on(intel_dp);
  +
  +   /* Resetting the flag, to redo the PSR setup after
  +* panel powercycle */
  +   if (intel_dp-psr_setup_done)
  +   intel_dp-psr_setup_done = false;
 
 Imo it's better to add this as an encoder-reset callback. That one is only 
 called
 on resume (at least in -nightly), so fits exactly. Resetting this flag in 
 every
 pre_enable is a bit much imo.
 
 Also it sounds like we need to extend Rodrigo's psr testcase with a
 suspend/resume subtest.
 -Daniel
 
  }
 
  WARN_ON(intel_crtc-ddi_pll_sel == PORT_CLK_SEL_NONE);
  --
  1.7.9.5
 
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx