diff mbox

[RFC,v4] drm/hdcp: drm enum property for CP State

Message ID 1501689185-24949-1-git-send-email-ramalingam.c@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Ramalingam C Aug. 2, 2017, 3:53 p.m. UTC 
Default connector property called "Content Protection" is added to
represent the content protection state of a connector and to
configure the same.

Userspace can request for enable or disable of content protection
on a connector. Set "DESIRED" for Enable and "UNDESIRED" for disable.

Content protection states defined:
	DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED 	- Unsupported
	DRM_MODE_CONTENT_PROTECTION_UNDESIRED		- Undesired
	DRM_MODE_CONTENT_PROTECTION_DESIRED		- Desired
	DRM_MODE_CONTENT_PROTECTION_ENABLED		- Enabled

v2: Redesigned the property to match with CP needs of CrOS [Sean].
v3: Renamed the state names. Header is removed [Sean].
v4: Aligned with existing userspace(CrOS's usage) [Sean].

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_connector.c | 24 ++++++++++++++++++++++++
 include/drm/drm_mode_config.h   |  5 +++++
 include/uapi/drm/drm_mode.h     |  7 +++++++
 3 files changed, 36 insertions(+)

Comments

Ramalingam C Aug. 5, 2017, 3:51 p.m. UTC | #1 
Hi all,

As we discussed in this review thread before, "UNSUPPORTED" state is 
added to the HDCP property to indicate a situation when HDCP is not 
possible, though hdcp property is attached to connector obj. In such 
case I would prefer to detach the hdcp property from connector, which 
would have been clear indication of no support. Since that is not 
possible at present in our kernel, I have added this state in the property.

In v4 of the uAPI RFC, "UNSUPPORTED" state of Enum is assigned with 
"-1", so that it doesn't alter the existing CrOS user space HDCP uAPI 
states {UNDESIRED=0, DESIRED=1, ENABLED=2}. Current CrOS User space need 
not change anything to use proposed uAPI. v4 of this uAPI RFC posted 
should be compatible for downstream uAPI of CrOS. So in current state of 
CrOS user space, as usual it can set the property for DESIRED for 
enabling the HDCP. But it will be rejected as no HDCP is possible in the 
platform. Please share if there is any concern. This can be removed as 
it is not a compulsory state for functionality.

Multiple questions are asked in off line discussions, on why can't we 
make uAPI as HDCP version agnostic. Sharing the reasoning with 
community, so that we all can be on same page.

For first phase of HDCP2.2 development, uAPI proposed is version 
agnostic. Thats the reason we are able to use the CrOS's HDCP1.4 support 
as user space consumer for Phase 1. But in Phase 2 when we enable 
complete HDCP2.2 spec in kernel along with required user space consumer, 
uAPI will be extended to support required interface. Such uAPI extension 
will expose the platforms HDCP v2.2 capability to the user, and in some 
cases, allows the users to mandate the HDCP v2.2 encryption only for 
their content. I am bringing this up as we need community agreement for 
this second phase of uAPI also. Reasoning for such extension is as follow:

HDCPv2.2 Spec provides an option to the content provider, to tag a 
stream, such that it will be given to HDCP2.2(or latest) compliant 
devices only through out the distribution chain. This tagging is nothing 
but calling the stream as Type 1. In Other words, Type 1 streams are 
always encrypted with HDCPv2.2. This stream type info will be passed to 
the All HDCP2.2 sinks as part of authentication. So that sinks such as 
repeaters/converters wont be transmitting the received encrypted stream 
to the HDCP device which is non-compliant with HDCP V2.2.

If a stream can be distributed to HDCP1.4 compliant devices also, that 
is tagged as Type 0. Refer the below diagram for pictorial 
representation for flow of encrypted stream tagged as Type 0 and 1.


+-----------+ HDCP v2.2 protected
         | HDCP v2.2 |                       Type 0 
Content                  Type 1 Content
         |Transmitter|                          flow 
path                       flow path
         +-----+-----+
               | |                               |
               | v2.2 link |                               |
               v v                               v
          +----+----+ |                               |
          |HDCP v2.2| |                               |
          | Repeater| |                               |
          +--+---+--+ |                               |
             |   | +-+-+                           +-+
  v2.2 link  |   |    v1.4 link                   | 
|                           |
      +------+   +-------+                 +------+ +-------+            
+------+
      |                  |                 | |            |
      v                  v                 v v            v
+----+----+        +----+----+
|HDCP v2.2|        |HDCP v1.4|
|  Panel  |        |  Panel  |
+---------+        +---------+


Note: none of the protected content streams Type0/1 will be shared to 
panels which are non HDCP compliant.

We need uAPI to pass the type of stream from user space to kernel because:

 1. When Digital Right Management(DRM) wants HDCP2.2 encryption, it will
    tag the stream as Type 0/1.
 2. One of the parameter for encryption formula of HDCP v2.2 is this
    Type info. So Type classification of stream defined by DRM should be
    passed to kernel.
 3. Many content providers(DRM) want their content to be encrypted only
    in V2.2, as v1.4 is already compromised. To fulfill such
    requirement, we need to expose the capability of HDCP v2.2 to user
    space and also interface to set such requirement to kernel. Adding
    option to set type info of stream clears both requirements.

Option 1: All of the above requirements can be fulfilled just by adding 
a property state to a existing hdcp property to represent the type info 
of the stream. such as {UNDESIRED, DESIRED, ENABLED, TYPE1_DESIRED, 
TYPE1_ENABLED}.
Option 2: Assume still we prefer HDCP version agnostic uAPI, as Enum 
property with {UNDESIRED, DESIRED, ENABLED}. For HDCP enable request, 
latest HDCP version supported will be invoked for encryption. When the 
latest version capable is v2.2, still we have to pass the type info 
along with version agnostic enable request, through separate HDCP 
ver2.2+ specific Enum property as {TYPE0, TYPE1}.

Bottom line is For HDCP v2.2 either way we need to pass the Type info 
from user space to kernel.

If there is a concern or doubt about this interface requirement please 
express it here.

Example of protected content provider, who mandates the HDCP v2.2 
encryption only is Netflix. It imposes that 4k content can be played 
only on HDCP2.2 HDMI monitors.


On Wednesday 02 August 2017 09:23 PM, Ramalingam C wrote:
> Default connector property called "Content Protection" is added to
> represent the content protection state of a connector and to
> configure the same.
>
> Userspace can request for enable or disable of content protection
> on a connector. Set "DESIRED" for Enable and "UNDESIRED" for disable.
>
> Content protection states defined:
> 	DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED 	- Unsupported
> 	DRM_MODE_CONTENT_PROTECTION_UNDESIRED		- Undesired
> 	DRM_MODE_CONTENT_PROTECTION_DESIRED		- Desired
> 	DRM_MODE_CONTENT_PROTECTION_ENABLED		- Enabled
>
> v2: Redesigned the property to match with CP needs of CrOS [Sean].
> v3: Renamed the state names. Header is removed [Sean].
> v4: Aligned with existing userspace(CrOS's usage) [Sean].
>
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> ---
>   drivers/gpu/drm/drm_connector.c | 24 ++++++++++++++++++++++++
>   include/drm/drm_mode_config.h   |  5 +++++
>   include/uapi/drm/drm_mode.h     |  7 +++++++
>   3 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8072e6e4c62c..f4ce0af63ad3 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -617,6 +617,14 @@ 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" },
> +	{ DRM_MODE_CONTENT_PROTECTION_UNDESIRED,	"Undesired" },
> +	{ DRM_MODE_CONTENT_PROTECTION_DESIRED,		"Desired" },
> +	{ DRM_MODE_CONTENT_PROTECTION_ENABLED,		"Enabled" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
> +
>   /**
>    * drm_display_info_set_bus_formats - set the supported bus formats
>    * @info: display info to store bus formats in
> @@ -741,6 +749,15 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>    *      value of link-status is "GOOD". If something fails during or after modeset,
>    *      the kernel driver may set this to "BAD" and issue a hotplug uevent. Drivers
>    *      should update this value using drm_mode_connector_set_link_status_property().
> + * Content Protection:
> + *      Connector Content Protection property to indicate the content protection
> + *      status of a connector. Default value is "UNDESIRED". Kernel will set
> + *      to "UNSUPPORTED" if there is no common HDCP ver supported between Src
> + *      and Sink. User space could set this to "DESIRED" to enabled the content
> + *      protection on the connector. If content protection setup process is
> + *      success, kernel will set this property to "ENABLED". To Disable the
> + *      content protection on the connector userspace could set this property to
> + *      "UNDESIRED".
>    *
>    * Connectors also have one standardized atomic property:
>    *
> @@ -789,6 +806,13 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
>   		return -ENOMEM;
>   	dev->mode_config.link_status_property = prop;
>   
> +	prop = drm_property_create_enum(dev, 0, "Content Protection",
> +					drm_cp_enum_list,
> +					ARRAY_SIZE(drm_cp_enum_list));
> +	if (!prop)
> +		return -ENOMEM;
> +	dev->mode_config.cp_property = prop;
> +
>   	return 0;
>   }
>   
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 42981711189b..72e2b4e6d51d 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -538,6 +538,11 @@ struct drm_mode_config {
>   	 */
>   	struct drm_property *link_status_property;
>   	/**
> +	 * @cp_property: Default connector property for content protection
> +	 * status of a connector
> +	 */
> +	struct drm_property *cp_property;
> +	/**
>   	 * @plane_type_property: Default plane property to differentiate
>   	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
>   	 */
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 403339f98a92..61685a64cd6a 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -173,6 +173,13 @@ extern "C" {
>   		DRM_MODE_REFLECT_X | \
>   		DRM_MODE_REFLECT_Y)
>   
> +/* Content Protection options */
> +enum cp_state {
> +	DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED = -1,
> +	DRM_MODE_CONTENT_PROTECTION_UNDESIRED,
> +	DRM_MODE_CONTENT_PROTECTION_DESIRED,
> +	DRM_MODE_CONTENT_PROTECTION_ENABLED,
> +};
>   
>   struct drm_mode_modeinfo {
>   	__u32 clock;
Ramalingam C Aug. 7, 2017, 5:32 a.m. UTC | #2 
Wrapping the image, to make it compatible for viewers with 80Char limit.


On Saturday 05 August 2017 09:21 PM, Ramalingam C wrote:
> If a stream can be distributed to HDCP1.4 compliant devices also, that 
> is tagged as Type 0. Refer the below diagram for pictorial 
> representation for flow of encrypted stream tagged as Type 0 and 1. 
                  +-----------+
                  | HDCP v2.2 |
                  |Transmitter|
                  +-----+-----+
                        |
                        | v2.2 link
                        v
                   +----+----+
                   |HDCP v2.2|
                   | Repeater|
                   +--+---+--+
                      |   |
                      |   |
     v2.2 link +------+   +-------+ v1.4 link
               |                  |
               v                  v
          +----+----+        +----+----+
          |HDCP v2.2|        |HDCP v1.4|
          |  Panel  |        |  Panel  |
          +---------+        +---------+



                               HDCP v2.2 protected
   Type 0 Content                  Type 1 Content
      flow path                       flow path

          +                               +
          |                               |
          |                               |
          |                               |
          |                               |
          |                               |
          |                               |
        +-+-+                           +-+
        |   |                           |
+------+   +-------+            +------+
|                  |            |
v                  v            v

--Ram
diff mbox

Patch

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8072e6e4c62c..f4ce0af63ad3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -617,6 +617,14 @@  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" },
+	{ DRM_MODE_CONTENT_PROTECTION_UNDESIRED,	"Undesired" },
+	{ DRM_MODE_CONTENT_PROTECTION_DESIRED,		"Desired" },
+	{ DRM_MODE_CONTENT_PROTECTION_ENABLED,		"Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -741,6 +749,15 @@  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  *      value of link-status is "GOOD". If something fails during or after modeset,
  *      the kernel driver may set this to "BAD" and issue a hotplug uevent. Drivers
  *      should update this value using drm_mode_connector_set_link_status_property().
+ * Content Protection:
+ *      Connector Content Protection property to indicate the content protection
+ *      status of a connector. Default value is "UNDESIRED". Kernel will set
+ *      to "UNSUPPORTED" if there is no common HDCP ver supported between Src
+ *      and Sink. User space could set this to "DESIRED" to enabled the content
+ *      protection on the connector. If content protection setup process is
+ *      success, kernel will set this property to "ENABLED". To Disable the
+ *      content protection on the connector userspace could set this property to
+ *      "UNDESIRED".
  *
  * Connectors also have one standardized atomic property:
  *
@@ -789,6 +806,13 @@  int drm_connector_create_standard_properties(struct drm_device *dev)
 		return -ENOMEM;
 	dev->mode_config.link_status_property = prop;
 
+	prop = drm_property_create_enum(dev, 0, "Content Protection",
+					drm_cp_enum_list,
+					ARRAY_SIZE(drm_cp_enum_list));
+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.cp_property = prop;
+
 	return 0;
 }
 
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 42981711189b..72e2b4e6d51d 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -538,6 +538,11 @@  struct drm_mode_config {
 	 */
 	struct drm_property *link_status_property;
 	/**
+	 * @cp_property: Default connector property for content protection
+	 * status of a connector
+	 */
+	struct drm_property *cp_property;
+	/**
 	 * @plane_type_property: Default plane property to differentiate
 	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
 	 */
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 403339f98a92..61685a64cd6a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -173,6 +173,13 @@  extern "C" {
 		DRM_MODE_REFLECT_X | \
 		DRM_MODE_REFLECT_Y)
 
+/* Content Protection options */
+enum cp_state {
+	DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED = -1,
+	DRM_MODE_CONTENT_PROTECTION_UNDESIRED,
+	DRM_MODE_CONTENT_PROTECTION_DESIRED,
+	DRM_MODE_CONTENT_PROTECTION_ENABLED,
+};
 
 struct drm_mode_modeinfo {
 	__u32 clock;