[RFC v1 00/20] DRM Interfaces for HDCP support
Ramalingam C
ramalingam.c at intel.com
Wed Jul 12 08:28:44 UTC 2017
Purpose of this RFC series is proposing the DRM interfaces for HDCP
support and based on DRM community inputs improvising it or altering it.
This series talks about the
1. DRM's UMD interface, i.e DRM Properties
2. DRM's Display driver Interface
Before looking into the interface details, it will be helpful if we can
have a look at whole picture of HDCP implementation at KMD.
Eagle view of HDCP Support in KMD:
**********************************
Gist of it is KMD is implementing service for HDCP protection based on
1. HDCP spec ver supported on HDCP source HW.
2. HDCP spec ver supported on HDCP sink.
3. UMD's request for the HDCP type(0/1) protection.
HDCP specification support is implemented at DRM. And Display drivers will
register for the DRM's HDCP services.
DRM could have multiple HDCP spec versions (HDCP v1.4 and v2.2) implemented
in parallel and also could support multiple Display adapatations
(HDMI, DP etc) for each HDCP version supported.
Initial implementation will add DRM support for HDCP2.2 for HDMI.
DP adaption support for HDCP2.2 will added soon.
During registration for DRM HDCP services Display drivers will
register for as many HDCP Spec versions supported by HDCP Source HW.
As per the HDCP capability of the connected HDCP sink's HDCP version
capability and the UMD's type request, DRM will choose the HDCP spec ver
it has to execute on a port.
Functional blocks of KMD HDCP support:
**********************************
DRM implements the below HW independent blocks:
1. Defining the HDCP protocol messages.
2. HDCP link communication through I2C/AUX as per HDCP spec.
3. HDCP Sink capability probing
4. Authentication sequence of HDCP with time keeping.
5. DRM property for UMD interface.
6. Kobj-uevent broadcasting at HDCP state change.
7. Deciding the HDCP ver based on the HDCP src and sink's capability.
8. Interface for platform dependent services from display drivers.
Display drivers implement below blocks:
1. Key generation as per HDCP version.
2. Encryption and decryption of the data with cryptography.
3. Calculations required for HDCP spec implementation
4. Filling the DRM's HDCP protocol message with data.
5. HW programming for HDCP source.
6. Initializing the HDCP for a display port and registering it
for DRM HDCP services.
7. Initializing the interface of DRM for platform dependent
HDCP services.
Block Diagram:
**************
+---------------------------+
| |
| Protected Content Player |
|(Chrome stack/LibOEMCrypto)|
| |
+-----------+--+------------+
| ^
| |
| |
UMD v |
+------------------------------------+
| +----------------+ |
| | | Compositors |
| | LIBHDCP | (Wayland/HwC)|
| | | |
| +----------------+ |
+------------------------------------+
| ^
-----------------------------+ | | +-----------------------
| |
v |
+-------------------------------+
| Drm HDCP Properties |
+-------------------------------+
+-------------------------------+
| |
| DRM Generic HDCP Stack |
| |
KMD | +-----------+ +----------+ |
| | | | | |
| | HDCP V2.2 | | HDCP Vx.x| |
| | | | | |
| +-----------+ +----------+ |
| |
+---+ + ^ +-------+ + ^ +-+
| | | |
| | | |
| | | |
| | | |
+---+ v + +-------+ v + +-+
+ |
+-------+ +-----------+ +----------+ |
| | <----+ | | | | |
| ME FW | | HDCP V2.2 | | HDCP Vx.x| |
| | +----> | | | | |
+-------+ +-----------+ +----------+ |
+ |
| I915 Generic HDCP Stack |
| |
+-------------------------------+
UMD: HDCP library:
******************
A HDCP library, which can be consumed by open source compositor like
Wayland is getting designed. This will provide the below services to the
HDCP clients like Chrome stack or libOEMCrypto of Android.
1. List of Display ports with HDCP version supported.
2. HDCP Enable/Disable per port basis.
3. Get HDCP status of a port.
4. Invoking registered Callback for HDCP link failure.
5. Send SRM to KMD.
DRM HDCP Properties:
********************
Purpose of these properties are:
1. Receiving the UMD's request for HDCP Enable (With Type info)
and HDCP Disable
2. Sharing the status of the previous request. Error type in case
of failure.
3. Receiving the SRM Table from the UMD.
DRM bitmask property:
This property serves requirement 1 and 2 with below bit defined
Configurable bits:
1. HDCP_ENABLE "1" - Enable; "0" - Disable;
2. Type Bit 0 and 1 "00-Type 0; "01"- Type 1;
Capability flags(RO) :
1. HDCP1_SUPPORTED "1" - HDCP1.4 Supported
2. HDCP2_SUPPORTED "1" - HDCP2.2 Supported
Status Flags(RO) :
1. HDCP_WIP "1" - Previous request WIP
2. HDCP_AUTH_FAILED "1" - HDCP Auth Failed
Runtime Error on Protected port(RO):
3. HDCP_LINK_INTEGRITY_FAILED
"1" - Encrypted HDCP Link sync failed
4. HDCP_REAUTH_REQUESTED
"1" - HDCP sink requested for reauth
Above ver(1.4/2.2) capability flag will be set when HDCP src and sink
support that HDCP version.
And on any update of these above bits change, kobj-uevent will be
broadcasted, so that UMD library can avoid the unnecessary polling of
the status with huge timeout.
DRM blob property:
To receive the SRM table the revocation check of HDCP sink ID, DRM blob
property is defined. this blob will be parsed and stored as SRM table.
Design Discussion phases:
*************************
Considering the size of patch series, for the convenience of the review
process, Design discussion through RFC is logically split into four
phases as below.
Phase 1:
DRM Interfaces for HDCP support
Phase 2:
DRM support for HDCP2.2 specification
Phase 3:
I915 implementation for HDCP2.2
Phase 4:
mei_client driver for Intel platforms
Once DRM community concludes on Phase 1, subsequent phases will be floated
for discussion. Incase if the whole picture through code is preferred,
initial code for all phases are maintained at below github
https://github.com/ramalingampc2008/drm-tip/tree/hdcp_rfc
Ramalingam C (20):
drm/hdcp: HDCP bitmask property for connectors
drm/hdcp: HDCP SRM blob property for connectors
drm/sysfs: Generate drm uevent with custom string
drm/hdcp: Struct drm_hdcp for connector's hdcp state
drm/hdcp: HDCP status code for DRM HDCP stack
drm/hdcp: display driver callback funcs defined
drm/hdcp: Initialization of DRM hdcp stack
drm/hdcp: Add KBuild for DRM HDCP support
drm/hdcp: Generic enable, disable and late_init
drm/hdcp: Handler for connector state change
drm/hdcp: Registering for connector state change
drm/hdcp: Atomic set and get property for hdcp
drm/hdcp: Updating DRM Property val with HDCP state
drm/hdcp2.2: HDCP2.2 protocol msg definitions
drm/hdcp2.2: Display driver service functions
drm/hdcp2.2: HDCP2.2 Initialization
drm/hdcp2.2: Definitions of HDMI HDCP2.2 registers
drm/hdcp2.2: Late_init: Capability probing on panel
drm/hdcp2.2: HDCP2.2 enable as a asynchronous work
drm/hdcp2.2: HDCP2.2 disable as a asynchronous work
drivers/gpu/drm/Kconfig | 12 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_atomic.c | 5 +
drivers/gpu/drm/drm_connector.c | 35 ++
drivers/gpu/drm/drm_hdcp.c | 373 ++++++++++++++++++++
drivers/gpu/drm/drm_probe_helper.c | 3 +
drivers/gpu/drm/drm_sysfs.c | 17 +
drivers/gpu/drm/i915/intel_hotplug.c | 6 +-
include/drm/drm_connector.h | 5 +
include/drm/drm_hdcp.h | 639 +++++++++++++++++++++++++++++++++++
include/drm/drm_mode_config.h | 10 +
include/drm/drm_sysfs.h | 1 +
12 files changed, 1106 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_hdcp.c
create mode 100644 include/drm/drm_hdcp.h
--
2.7.4
More information about the dri-devel
mailing list