Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation
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&large 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) >> > +#define SKL_HDCP_DDIB_SHA1_
Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation
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&large 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) +#de
Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation
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&large 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 SKL_HDCP_DDIE_REP_PRESENT BIT(25) > > > +#define
Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation
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&large 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) +#define SKL_HDCP_SHA1
Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation
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&large 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 (1 << 1) > > +
Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation
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)? 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 (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_AUTHENC
Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation
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, \ > + _SKL_PORTB_HDCP_AUTHENC, \ > +
[Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation
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, \ + _SKL_PORTB_HDCP_AUTHENC, \ + _SKL_PORTC_HDCP_AUTHENC, \ + _SKL_PORTD_HDCP_AUTHENC, \ + _SKL_PORTE_HDCP_AUTHENC, \ + _SKL_PORTF