Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Sean Paul]

On Fri, Dec 1, 2017 at 2:36 AM, Daniel Vetter  wrote:
> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
>> Sean,
>>
>> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
>> drm helpers and all interested display drivers to use them.
>>
>> This Design will make the extending of hdcp easy for other display drivers
>> based on DRM.
>>
>> We can have the required drm_hdcp_shim type of implementation at drm
>> structure which will be called for platform specific operations (like
>> prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?
>
> I discussed this exact question with Sean Paul, and apparently the
> hardware designs are too diverse to make shared code much useful. Some hw
> has the entire hdcp flow in hw, some almost nothing (like i915 here), and
> then there's everything in between.
>
> Given that Sean has seen a lot more hdcp implementations than we have,
> that we right now have no other implementation than i915 in upstream and
> than wrong abstraction is much harder to fix than no abstraction I'm going
> with Sean's approach of "no generic abstraction" here. Personally I'm not
> even fully sold on the shim abstraction, but I think by that one is
> fine.
>

[html fail on the first response, resending in plain text]

I think there's some sharing potential between exynos and i915, but
the rockchip stuff is completely different. Even exynos differs in
that each step of the authentication process is interrupt driven
(iirc). I just don't see a pattern worth abstracting atm. We might be
able to share the enable/disable/check song & dance, but let's not
worry about abstraction until we have 2 implementations.


>> On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:
>> > This patch adds the framework required to add HDCP support to intel
>> > connectors. It implements Aksv loading from fuse, and parts 1/2/3
>> > of the HDCP authentication scheme.
>> >
>> > Note that without shim implementations, this does not actually implement
>> > HDCP. That will come in subsequent patches.
>> >
>> > Signed-off-by: Sean Paul 
>> > ---
>> >   drivers/gpu/drm/i915/Makefile   |   1 +
>> >   drivers/gpu/drm/i915/i915_reg.h |  83 +
>> >   drivers/gpu/drm/i915/intel_atomic.c |  26 +-
>> >   drivers/gpu/drm/i915/intel_ddi.c|  14 +
>> >   drivers/gpu/drm/i915/intel_drv.h|  53 +++
>> >   drivers/gpu/drm/i915/intel_hdcp.c   | 636 
>> > 
>> >   6 files changed, 811 insertions(+), 2 deletions(-)
>> >   create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
>> >
>> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>> > index 6c3b0481ef82..1e745508e437 100644
>> > --- a/drivers/gpu/drm/i915/Makefile
>> > +++ b/drivers/gpu/drm/i915/Makefile
>> > @@ -87,6 +87,7 @@ i915-y += intel_audio.o \
>> >   intel_fbc.o \
>> >   intel_fifo_underrun.o \
>> >   intel_frontbuffer.o \
>> > + intel_hdcp.o \
>> >   intel_hotplug.o \
>> >   intel_modes.o \
>> >   intel_overlay.o \
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> > b/drivers/gpu/drm/i915/i915_reg.h
>> > index 68a58cce6ab1..43128030171d 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -7991,6 +7991,7 @@ enum {
>> >   #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
>> >   #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
>> >   #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
>> > +#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
>> >   #define   SKL_PCODE_CDCLK_CONTROL 0x7
>> >   #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
>> >   #define SKL_CDCLK_READY_FOR_CHANGE0x1
>> > @@ -8285,6 +8286,88 @@ enum skl_power_gate {
>> >   #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + 
>> > SKL_PG1)
>> >   #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
>> > +
>> > +/* HDCP Key Registers */
>> > +#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
>> > +#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
>> > +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
>> > +#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
>> > +#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
>> > +#define  SKL_HDCP_FUSE_ERROR   BIT(6)
>> > +#define  SKL_HDCP_FUSE_DONEBIT(5)
>> > +#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
>> > +#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
>> > +#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
>> > +#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
>> > +
>> > +/* HDCP Repeater Registers */
>> > +#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
>> > +#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
>> > +#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
>> > +#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
>> > +#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
>> > +#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
>> > +#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Sean Paul]

On Fri, Dec 1, 2017 at 3:36 AM, Ramalingam C  wrote:
>
>
>
> On Friday 01 December 2017 01:06 PM, Daniel Vetter wrote:
>>
>> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
>>>
>>> Sean,
>>>
>>> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
>>> drm helpers and all interested display drivers to use them.
>>>
>>> This Design will make the extending of hdcp easy for other display drivers
>>> based on DRM.
>>>
>>> We can have the required drm_hdcp_shim type of implementation at drm
>>> structure which will be called for platform specific operations (like
>>> prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?
>>
>> I discussed this exact question with Sean Paul, and apparently the
>> hardware designs are too diverse to make shared code much useful. Some hw
>> has the entire hdcp flow in hw, some almost nothing (like i915 here), and
>> then there's everything in between.
>
> Just trying to understand the other extreme of HW (full)support for HDCP here.
>
> When you say everything about HDCP is implemented in HW, do you mean that 
> whole protocol comm on HDCP link also driven by HW?
>

Yep. Check out the rockchip implementation in our 4.4 tree.

Sean


>
> --Ram
>
>>
>> Given that Sean has seen a lot more hdcp implementations than we have,
>> that we right now have no other implementation than i915 in upstream and
>> than wrong abstraction is much harder to fix than no abstraction I'm going
>> with Sean's approach of "no generic abstraction" here. Personally I'm not
>> even fully sold on the shim abstraction, but I think by that one is
>> fine.
>>
>>> On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:

 This patch adds the framework required to add HDCP support to intel
 connectors. It implements Aksv loading from fuse, and parts 1/2/3
 of the HDCP authentication scheme.

 Note that without shim implementations, this does not actually implement
 HDCP. That will come in subsequent patches.

 Signed-off-by: Sean Paul 
 ---
drivers/gpu/drm/i915/Makefile   |   1 +
drivers/gpu/drm/i915/i915_reg.h |  83 +
drivers/gpu/drm/i915/intel_atomic.c |  26 +-
drivers/gpu/drm/i915/intel_ddi.c|  14 +
drivers/gpu/drm/i915/intel_drv.h|  53 +++
drivers/gpu/drm/i915/intel_hdcp.c   | 636 
 
6 files changed, 811 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

 diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
 index 6c3b0481ef82..1e745508e437 100644
 --- a/drivers/gpu/drm/i915/Makefile
 +++ b/drivers/gpu/drm/i915/Makefile
 @@ -87,6 +87,7 @@ i915-y += intel_audio.o \
   intel_fbc.o \
   intel_fifo_underrun.o \
   intel_frontbuffer.o \
 + intel_hdcp.o \
   intel_hotplug.o \
   intel_modes.o \
   intel_overlay.o \
 diff --git a/drivers/gpu/drm/i915/i915_reg.h 
 b/drivers/gpu/drm/i915/i915_reg.h
 index 68a58cce6ab1..43128030171d 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -7991,6 +7991,7 @@ enum {
#define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT 8
#define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT 16
#define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
 +#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
#define   SKL_PCODE_CDCLK_CONTROL0x7
#define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
#define SKL_CDCLK_READY_FOR_CHANGE   0x1
 @@ -8285,6 +8286,88 @@ enum skl_power_gate {
#define  SKL_PW_TO_PG(pw)((pw) - SKL_DISP_PW_1 + 
 SKL_PG1)
#define  SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg)))
 +
 +/* HDCP Key Registers */
 +#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
 +#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
 +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
 +#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
 +#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
 +#define  SKL_HDCP_FUSE_ERROR   BIT(6)
 +#define  SKL_HDCP_FUSE_DONEBIT(5)
 +#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
 +#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
 +#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
 +#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
 +
 +/* HDCP Repeater Registers */
 +#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
 +#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
 +#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
 +#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
 +#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
 +#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
 +#define  

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Sean Paul]

On Fri, Dec 1, 2017 at 2:36 AM, Daniel Vetter  wrote:

> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
> > Sean,
> >
> > IMHO, it will good if we can have all generic hdcp1.4 authentication
> flow in
> > drm helpers and all interested display drivers to use them.
> >
> > This Design will make the extending of hdcp easy for other display
> drivers
> > based on DRM.
> >
> > We can have the required drm_hdcp_shim type of implementation at drm
> > structure which will be called for platform specific operations (like
> > prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?
>
> I discussed this exact question with Sean Paul, and apparently the
> hardware designs are too diverse to make shared code much useful. Some hw
> has the entire hdcp flow in hw, some almost nothing (like i915 here), and
> then there's everything in between.
>
> Given that Sean has seen a lot more hdcp implementations than we have,
> that we right now have no other implementation than i915 in upstream and
> than wrong abstraction is much harder to fix than no abstraction I'm going
> with Sean's approach of "no generic abstraction" here. Personally I'm not
> even fully sold on the shim abstraction, but I think by that one is
> fine.
>

I think there's some sharing potential between exynos and i915, but the
rockchip stuff is completely different. Even exynos differs in that each
step of the authentication process is interrupt driven (iirc). I just don't
see a pattern worth abstracting atm. We might be able to share the
enable/disable/check song & dance, but let's not worry about abstraction
until we have 2 implementations.



> > On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:
> > > This patch adds the framework required to add HDCP support to intel
> > > connectors. It implements Aksv loading from fuse, and parts 1/2/3
> > > of the HDCP authentication scheme.
> > >
> > > Note that without shim implementations, this does not actually
> implement
> > > HDCP. That will come in subsequent patches.
> > >
> > > Signed-off-by: Sean Paul 
> > > ---
> > >   drivers/gpu/drm/i915/Makefile   |   1 +
> > >   drivers/gpu/drm/i915/i915_reg.h |  83 +
> > >   drivers/gpu/drm/i915/intel_atomic.c |  26 +-
> > >   drivers/gpu/drm/i915/intel_ddi.c|  14 +
> > >   drivers/gpu/drm/i915/intel_drv.h|  53 +++
> > >   drivers/gpu/drm/i915/intel_hdcp.c   | 636
> 
> > >   6 files changed, 811 insertions(+), 2 deletions(-)
> > >   create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
> > >
> > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/
> Makefile
> > > index 6c3b0481ef82..1e745508e437 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -87,6 +87,7 @@ i915-y += intel_audio.o \
> > >   intel_fbc.o \
> > >   intel_fifo_underrun.o \
> > >   intel_frontbuffer.o \
> > > + intel_hdcp.o \
> > >   intel_hotplug.o \
> > >   intel_modes.o \
> > >   intel_overlay.o \
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> > > index 68a58cce6ab1..43128030171d 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7991,6 +7991,7 @@ enum {
> > >   #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
> > >   #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
> > >   #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
> > > +#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
> > >   #define   SKL_PCODE_CDCLK_CONTROL 0x7
> > >   #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
> > >   #define SKL_CDCLK_READY_FOR_CHANGE0x1
> > > @@ -8285,6 +8286,88 @@ enum skl_power_gate {
> > >   #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 +
> SKL_PG1)
> > >   #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
> > > +
> > > +/* HDCP Key Registers */
> > > +#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
> > > +#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
> > > +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
> > > +#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
> > > +#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
> > > +#define  SKL_HDCP_FUSE_ERROR   BIT(6)
> > > +#define  SKL_HDCP_FUSE_DONEBIT(5)
> > > +#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
> > > +#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
> > > +#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
> > > +#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
> > > +
> > > +/* HDCP Repeater Registers */
> > > +#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
> > > +#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
> > > +#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
> > > +#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
> > > +#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
> > > +#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
> > > +#define  

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Ramalingam C]

On Friday 01 December 2017 01:06 PM, Daniel Vetter wrote:

On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:

Sean,

IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
drm helpers and all interested display drivers to use them.

This Design will make the extending of hdcp easy for other display drivers
based on DRM.

We can have the required drm_hdcp_shim type of implementation at drm
structure which will be called for platform specific operations (like
prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?

I discussed this exact question with Sean Paul, and apparently the
hardware designs are too diverse to make shared code much useful. Some hw
has the entire hdcp flow in hw, some almost nothing (like i915 here), and
then there's everything in between.
Just trying to understand the other extreme of HW (full)support for HDCP 
here.


When you say everything about HDCP is implemented in HW, do you mean 
that whole protocol comm on HDCP link also driven by HW?


--Ram


Given that Sean has seen a lot more hdcp implementations than we have,
that we right now have no other implementation than i915 in upstream and
than wrong abstraction is much harder to fix than no abstraction I'm going
with Sean's approach of "no generic abstraction" here. Personally I'm not
even fully sold on the shim abstraction, but I think by that one is
fine.


On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:

This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.

Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.

Signed-off-by: Sean Paul 
---
   drivers/gpu/drm/i915/Makefile   |   1 +
   drivers/gpu/drm/i915/i915_reg.h |  83 +
   drivers/gpu/drm/i915/intel_atomic.c |  26 +-
   drivers/gpu/drm/i915/intel_ddi.c|  14 +
   drivers/gpu/drm/i915/intel_drv.h|  53 +++
   drivers/gpu/drm/i915/intel_hdcp.c   | 636 

   6 files changed, 811 insertions(+), 2 deletions(-)
   create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6c3b0481ef82..1e745508e437 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -87,6 +87,7 @@ i915-y += intel_audio.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
  intel_frontbuffer.o \
+ intel_hdcp.o \
  intel_hotplug.o \
  intel_modes.o \
  intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 68a58cce6ab1..43128030171d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7991,6 +7991,7 @@ enum {
   #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT 8
   #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT 16
   #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
+#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
   #define   SKL_PCODE_CDCLK_CONTROL0x7
   #define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
   #define SKL_CDCLK_READY_FOR_CHANGE   0x1
@@ -8285,6 +8286,88 @@ enum skl_power_gate {
   #define  SKL_PW_TO_PG(pw)((pw) - SKL_DISP_PW_1 + SKL_PG1)
   #define  SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg)))
+
+/* HDCP Key Registers */
+#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
+#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
+#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
+#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
+#define  SKL_HDCP_FUSE_ERROR   BIT(6)
+#define  SKL_HDCP_FUSE_DONEBIT(5)
+#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
+#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
+#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
+#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
+#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
+#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
+#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
+#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
+#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
+#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
+#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
+#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
+#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
+#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
+#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) // Bspec says 5?
+#define  SKL_HDCP_SHA1_BUSYBIT(16)
+#define  SKL_HDCP_SHA1_READY   BIT(17)
+#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
+#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
+#define  SKL_HDCP_SHA1_TEXT_32 (1 << 1)

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Daniel Vetter]

On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
> Sean,
> 
> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
> drm helpers and all interested display drivers to use them.
> 
> This Design will make the extending of hdcp easy for other display drivers
> based on DRM.
> 
> We can have the required drm_hdcp_shim type of implementation at drm
> structure which will be called for platform specific operations (like
> prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?

I discussed this exact question with Sean Paul, and apparently the
hardware designs are too diverse to make shared code much useful. Some hw
has the entire hdcp flow in hw, some almost nothing (like i915 here), and
then there's everything in between.

Given that Sean has seen a lot more hdcp implementations than we have,
that we right now have no other implementation than i915 in upstream and
than wrong abstraction is much harder to fix than no abstraction I'm going
with Sean's approach of "no generic abstraction" here. Personally I'm not
even fully sold on the shim abstraction, but I think by that one is
fine.

> On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:
> > This patch adds the framework required to add HDCP support to intel
> > connectors. It implements Aksv loading from fuse, and parts 1/2/3
> > of the HDCP authentication scheme.
> > 
> > Note that without shim implementations, this does not actually implement
> > HDCP. That will come in subsequent patches.
> > 
> > Signed-off-by: Sean Paul 
> > ---
> >   drivers/gpu/drm/i915/Makefile   |   1 +
> >   drivers/gpu/drm/i915/i915_reg.h |  83 +
> >   drivers/gpu/drm/i915/intel_atomic.c |  26 +-
> >   drivers/gpu/drm/i915/intel_ddi.c|  14 +
> >   drivers/gpu/drm/i915/intel_drv.h|  53 +++
> >   drivers/gpu/drm/i915/intel_hdcp.c   | 636 
> > 
> >   6 files changed, 811 insertions(+), 2 deletions(-)
> >   create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
> > 
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 6c3b0481ef82..1e745508e437 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -87,6 +87,7 @@ i915-y += intel_audio.o \
> >   intel_fbc.o \
> >   intel_fifo_underrun.o \
> >   intel_frontbuffer.o \
> > + intel_hdcp.o \
> >   intel_hotplug.o \
> >   intel_modes.o \
> >   intel_overlay.o \
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 68a58cce6ab1..43128030171d 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7991,6 +7991,7 @@ enum {
> >   #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
> >   #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
> >   #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
> > +#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
> >   #define   SKL_PCODE_CDCLK_CONTROL 0x7
> >   #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
> >   #define SKL_CDCLK_READY_FOR_CHANGE0x1
> > @@ -8285,6 +8286,88 @@ enum skl_power_gate {
> >   #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
> >   #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
> > +
> > +/* HDCP Key Registers */
> > +#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
> > +#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
> > +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
> > +#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
> > +#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
> > +#define  SKL_HDCP_FUSE_ERROR   BIT(6)
> > +#define  SKL_HDCP_FUSE_DONEBIT(5)
> > +#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
> > +#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
> > +#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
> > +#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
> > +
> > +/* HDCP Repeater Registers */
> > +#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
> > +#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
> > +#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
> > +#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
> > +#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
> > +#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
> > +#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
> > +#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
> > +#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
> > +#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
> > +#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
> > +#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
> > +#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) // Bspec says 5?
> > +#define  SKL_HDCP_SHA1_BUSYBIT(16)
> > +#define  SKL_HDCP_SHA1_READY   BIT(17)
> > +#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
> > +#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
> > +#define  SKL_HDCP_SHA1_TEXT_32  

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Chris Wilson]

Quoting Sean Paul (2017-11-30 03:08:58)
> This patch adds the framework required to add HDCP support to intel
> connectors. It implements Aksv loading from fuse, and parts 1/2/3
> of the HDCP authentication scheme.
> 
> Note that without shim implementations, this does not actually implement
> HDCP. That will come in subsequent patches.
> 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/Makefile   |   1 +
>  drivers/gpu/drm/i915/i915_reg.h |  83 +
>  drivers/gpu/drm/i915/intel_atomic.c |  26 +-
>  drivers/gpu/drm/i915/intel_ddi.c|  14 +
>  drivers/gpu/drm/i915/intel_drv.h|  53 +++
>  drivers/gpu/drm/i915/intel_hdcp.c   | 636 
> 
>  6 files changed, 811 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 6c3b0481ef82..1e745508e437 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -87,6 +87,7 @@ i915-y += intel_audio.o \
>   intel_fbc.o \
>   intel_fifo_underrun.o \
>   intel_frontbuffer.o \
> + intel_hdcp.o \
>   intel_hotplug.o \
>   intel_modes.o \
>   intel_overlay.o \
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 68a58cce6ab1..43128030171d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7991,6 +7991,7 @@ enum {
>  #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT   8
>  #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT   16
>  #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT   24
> +#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
>  #define   SKL_PCODE_CDCLK_CONTROL  0x7
>  #define SKL_CDCLK_PREPARE_FOR_CHANGE   0x3
>  #define SKL_CDCLK_READY_FOR_CHANGE 0x1
> @@ -8285,6 +8286,88 @@ enum skl_power_gate {
>  #define  SKL_PW_TO_PG(pw)  ((pw) - SKL_DISP_PW_1 + 
> SKL_PG1)
>  #define  SKL_FUSE_PG_DIST_STATUS(pg)   (1 << (27 - (pg)))
>  
> +
> +/* HDCP Key Registers */
> +#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
> +#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
> +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
> +#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
> +#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
> +#define  SKL_HDCP_FUSE_ERROR   BIT(6)
> +#define  SKL_HDCP_FUSE_DONEBIT(5)
> +#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
> +#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
> +#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
> +#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
> +
> +/* HDCP Repeater Registers */
> +#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
> +#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
> +#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
> +#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
> +#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
> +#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
> +#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
> +#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
> +#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
> +#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
> +#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
> +#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
> +#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) // Bspec says 5?
> +#define  SKL_HDCP_SHA1_BUSYBIT(16)
> +#define  SKL_HDCP_SHA1_READY   BIT(17)
> +#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
> +#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
> +#define  SKL_HDCP_SHA1_TEXT_32 (1 << 1)
> +#define  SKL_HDCP_SHA1_COMPLETE_HASH   (2 << 1)
> +#define  SKL_HDCP_SHA1_TEXT_24 (4 << 1)
> +#define  SKL_HDCP_SHA1_TEXT_16 (5 << 1)
> +#define  SKL_HDCP_SHA1_TEXT_8  (6 << 1)
> +#define  SKL_HDCP_SHA1_TEXT_0  (7 << 1)
> +#define SKL_HDCP_SHA_V_PRIME_H0_MMIO(0x66d04)
> +#define SKL_HDCP_SHA_V_PRIME_H1_MMIO(0x66d08)
> +#define SKL_HDCP_SHA_V_PRIME_H2_MMIO(0x66d0C)
> +#define SKL_HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
> +#define SKL_HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
> +#define SKL_HDCP_SHA_V_PRIME(h)_MMIO((0x66d04 + h * 4))
> +#define SKL_HDCP_SHA_TEXT  _MMIO(0x66d18)
> +
> +/* HDCP Auth Registers */
> +#define _SKL_PORTA_HDCP_AUTHENC0x66800
> +#define _SKL_PORTB_HDCP_AUTHENC0x66500
> +#define _SKL_PORTC_HDCP_AUTHENC0x66600
> +#define _SKL_PORTD_HDCP_AUTHENC0x66700
> +#define _SKL_PORTE_HDCP_AUTHENC0x66A00
> +#define _SKL_PORTF_HDCP_AUTHENC0x66900
> +#define _SKL_PORT_HDCP_AUTHENC(port, x)_MMIO(_PICK(port, \
> + _SKL_PORTA_HDCP_AUTHENC, \
> +