[RFC v1 00/20] DRM Interfaces for HDCP support

[RFC v1 00/20] DRM Interfaces for HDCP support

[Ramalingam C]

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

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

[RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

DRM connector property is created as bitmask to receive
HDCP enable/disable request along with content type.

And also there are Read only status bits for
	1. HDCP spec capability of the connector + panel
	2. HDCP encryption status of the connector

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_connector.c | 30 +++++++++++++++++++++
 include/drm/drm_hdcp.h          | 58 +++++++++++++++++++++++++++++++++++++++++
 include/drm/drm_mode_config.h   |  5 ++++
 3 files changed, 93 insertions(+)
 create mode 100644 include/drm/drm_hdcp.h

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8072e6e..04f8cf8 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -24,6 +24,7 @@
 #include <drm/drm_connector.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_encoder.h>
+#include <drm/drm_hdcp.h>
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -617,6 +618,28 @@ 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_hdcp_enum_list[] = {
+	{ __builtin_ffs(DRM_HDCP_ENABLE) - 1,
+					"Enable HDCP Encryption" },
+	{ __builtin_ffs(DRM_HDCP_TYPE_BIT0) - 1,
+					"HDCP Content type bit0" },
+	{ __builtin_ffs(DRM_HDCP_TYPE_BIT1) - 1,
+					"HDCP Content type bit1" },
+	{ __builtin_ffs(DRM_HDCP1_SUPPORTED) - 1,
+					"HDCP1.x Supported" },
+	{ __builtin_ffs(DRM_HDCP2_SUPPORTED) - 1,
+					"HDCP2.x Supported" },
+	{ __builtin_ffs(DRM_HDCP_WIP) - 1,
+					"HDCP work in progress" },
+	{ __builtin_ffs(DRM_HDCP_AUTH_FAILED) - 1,
+					"HDCP Authentication Failed" },
+	{ __builtin_ffs(DRM_HDCP_LINK_INTEGRITY_FAILED) - 1,
+					"HDCP Link Integrity Failed" },
+	{ __builtin_ffs(DRM_HDCP_REAUTH_REQUESTED) - 1,
+					"HDCP Reauthentication Requested" },
+};
+DRM_ENUM_NAME_FN(drm_get_hdcp_name, drm_hdcp_enum_list)
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -789,6 +812,13 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
 		return -ENOMEM;
 	dev->mode_config.link_status_property = prop;
 
+	prop = drm_property_create_bitmask(dev, 0, "hdcp", drm_hdcp_enum_list,
+					   ARRAY_SIZE(drm_hdcp_enum_list),
+					   DRM_HDCP_PROP_SUPPORTED_BITS);
+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.hdcp_property = prop;
+
 	return 0;
 }
 
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
new file mode 100644
index 0000000..7cebf0f
--- /dev/null
+++ b/include/drm/drm_hdcp.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+/*
+ * Header for HDCP specific data
+ */
+
+#ifndef __DRM_HDCP_H__
+#define __DRM_HDCP_H__
+
+/**
+ * HDCP property related information
+ */
+/* RW: HDCP Encryption Requests and Status bits */
+#define DRM_HDCP_ENABLE				BIT(0)
+#define DRM_HDCP_TYPE_BIT0			BIT(4)
+#define DRM_HDCP_TYPE_BIT1			BIT(5)
+
+/* RO: HDCP Version supported on Platform + panel */
+#define DRM_HDCP1_SUPPORTED			BIT(12)
+#define DRM_HDCP2_SUPPORTED			BIT(13)
+
+/* RO: Status of the requested operations */
+#define DRM_HDCP_WIP				BIT(20)
+#define DRM_HDCP_AUTH_FAILED			BIT(21)
+
+/* RO: Error Status From HDCP sink */
+#define DRM_HDCP_LINK_INTEGRITY_FAILED		BIT(22)
+#define DRM_HDCP_REAUTH_REQUESTED		BIT(23)
+
+#define DRM_HDCP_PROP_SUPPORTED_BITS	(DRM_HDCP_ENABLE | DRM_HDCP_TYPE_BIT0 \
+					| DRM_HDCP_TYPE_BIT1 | \
+					DRM_HDCP1_SUPPORTED | \
+					DRM_HDCP2_SUPPORTED | DRM_HDCP_WIP | \
+					DRM_HDCP_AUTH_FAILED | \
+					DRM_HDCP_LINK_INTEGRITY_FAILED | \
+					DRM_HDCP_REAUTH_REQUESTED)
+
+#endif	/* __DRM_HDCP_H__ */
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 4298171..0c5bb90 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;
 	/**
+	 * @hdcp_property: Default connector property for HDCP
+	 * of a connector
+	 */
+	struct drm_property *hdcp_property;
+	/**
 	 * @plane_type_property: Default plane property to differentiate
 	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
 	 */
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 02/20] drm/hdcp: HDCP SRM blob property for connectors

[Ramalingam C]

Standard connector blob property is created for passing HDCP
SRM table from HDCP content player to kernel.

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

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 04f8cf8..41f83a9 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -819,6 +819,11 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
 		return -ENOMEM;
 	dev->mode_config.hdcp_property = prop;
 
+	prop = drm_property_create(dev, DRM_MODE_PROP_BLOB, "hdcp_srm", 0);
+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.hdcp_srm_property = prop;
+
 	return 0;
 }
 
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 0c5bb90..6b06729 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -543,6 +543,11 @@ struct drm_mode_config {
 	 */
 	struct drm_property *hdcp_property;
 	/**
+	 * @hdcp_srm_property: Default connector property to feed in the
+	 * SRM Table for HDCP revocation check.
+	 */
+	struct drm_property *hdcp_srm_property;
+	/**
 	 * @plane_type_property: Default plane property to differentiate
 	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
 	 */
-- 
2.7.4

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

[RFC v1 03/20] drm/sysfs: Generate drm uevent with custom string

[Ramalingam C]

Routine to generate DRM uevent with custom string is introduced.
This is required to notify the UMD about the HDCP link breakage
during the ongoing HDCP session. This could happen due to loss of
HDCP packet sync or reauthentication request from HDCP sink as per
the HDCP spec.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_sysfs.c | 17 +++++++++++++++++
 include/drm/drm_sysfs.h     |  1 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 1c5b5ce..07c374a 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -320,6 +320,23 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_sysfs_hotplug_event);
 
+/**
+ * drm_sysfs_generate_uevent - generate a DRM uevent
+ * @dev: DRM device
+ *
+ * Send a uevent for the DRM device specified by @dev.
+ */
+void drm_sysfs_generate_uevent(struct drm_device *dev, char *event_string)
+{
+	char *envp[] = { event_string, NULL };
+
+	DRM_DEBUG("generating DRM uevent with %s\n", event_string);
+
+	kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_generate_uevent);
+
+
 static void drm_sysfs_release(struct device *dev)
 {
 	kfree(dev);
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index 70c9a10..8bd358f 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -8,5 +8,6 @@ int drm_class_device_register(struct device *dev);
 void drm_class_device_unregister(struct device *dev);
 
 void drm_sysfs_hotplug_event(struct drm_device *dev);
+void drm_sysfs_generate_uevent(struct drm_device *dev, char *event_string);
 
 #endif
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 04/20] drm/hdcp: Struct drm_hdcp for connector's hdcp state

[Ramalingam C]

Structure drm_hdcp is defined to represent the HDCP state
of the connector. drm_connector will have a pointer to an instance
of this structure.

This will be used to hold all specification related information
along with state machine parameters.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 include/drm/drm_connector.h |  5 +++++
 include/drm/drm_hdcp.h      | 39 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 44 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ae5b7dc..45911db 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -27,6 +27,7 @@
 #include <linux/ctype.h>
 #include <linux/hdmi.h>
 #include <drm/drm_mode_object.h>
+#include <drm/drm_hdcp.h>
 
 #include <uapi/drm/drm_mode.h>
 
@@ -867,6 +868,10 @@ struct drm_connector {
 	 */
 	struct drm_connector_state *state;
 
+	/* HDCP representation on the connector */
+	struct drm_hdcp *hdcp;
+	uint64_t hdcp_state;
+
 	/* DisplayID bits */
 	bool has_tile;
 	struct drm_tile_group *tile_group;
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 7cebf0f..92fd933 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -27,6 +27,45 @@
 #ifndef __DRM_HDCP_H__
 #define __DRM_HDCP_H__
 
+struct drm_connector;
+
+/**
+ * HDCP Software stack specific
+ */
+/* Bit mask for HDCP spec ver support */
+#define HDCP_1_4_SUPPORT			(1<<0)
+#define HDCP_2_2_SUPPORT			(1<<1)
+
+/**
+ * wired_protocol: Supported integrated wired HDCP protocol.
+ * Based on this value, Minor differenceneeded between wired specifications
+ * are handled.
+ */
+enum wired_protocol {
+	WIRED_PROTOCOL_INVALID,
+	WIRED_PROTOCOL_HDMI,
+	WIRED_PROTOCOL_DP
+};
+
+/**
+ * Struct drm_hdcp - central drm hdcp control structure
+ */
+struct drm_hdcp {
+	struct drm_connector *connector;
+
+	/* HDCP Specifications support flag */
+	uint32_t ver_support_on_plat;
+	uint32_t ver_support_on_panel;
+
+	/* HDCP requested state and also the current state */
+	uint64_t req_state;
+
+	/* HDMI/DP Protocol */
+	enum wired_protocol protocol;
+
+	struct mutex mutex;
+};
+
 /**
  * HDCP property related information
  */
-- 
2.7.4

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

[RFC v1 05/20] drm/hdcp: HDCP status code for DRM HDCP stack

[Ramalingam C]

HDCP status code is defined. this will be used as a return value
of the service function of HDCP to indicate the hdcp status

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 include/drm/drm_hdcp.h | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 92fd933..bf77d37 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -37,6 +37,26 @@ struct drm_connector;
 #define HDCP_2_2_SUPPORT			(1<<1)
 
 /**
+ * @enum hdcp_status Enumeration of all HDCP Status Codes
+ */
+enum hdcp_status {
+	HDCP_STATUS_SUCCESS = 0,
+	HDCP_STATUS_UNKNOWN_ERROR,
+	HDCP_STATUS_INVALID_PARAMS,
+	HDCP_SRM_VERIFICATION_FAILED,
+	HDCP_SRM_VERSION_TOO_OLD,
+	HDCP_RX_CERT_VERIFICATION_FAILED,
+	HDCP_RX_REVOKED,
+	HDCP_H_VERIFICATION_FAILED,
+	HDCP_TOPOLOGY_MAX_EXCEEDED,
+	HDCP_V_VERIFICATION_FAILED,
+	HDCP_L_VERIFICATION_FAILED,
+	HDCP_STREAM_KEY_ALLOC_FAILED,
+	HDCP_STATUS_LC_MAX_ATTEMPTS,
+	HDCP_STATUS_MISMATCH_IN_M,
+};
+
+/**
  * wired_protocol: Supported integrated wired HDCP protocol.
  * Based on this value, Minor differenceneeded between wired specifications
  * are handled.
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 06/20] drm/hdcp: display driver callback funcs defined

[Ramalingam C]

Callback functions for Platform specific services are defined. These
pointers has to be initialized from display driver's hdcp_init and
passed onto drm_hdcp_init.

drm_hdcp_funcs will have pointers of functions common for all HDCP
versions supported on that platform.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 include/drm/drm_hdcp.h | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index bf77d37..2a48ef9 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -28,6 +28,7 @@
 #define __DRM_HDCP_H__
 
 struct drm_connector;
+struct drm_hdcp;
 
 /**
  * HDCP Software stack specific
@@ -67,6 +68,43 @@ enum wired_protocol {
 	WIRED_PROTOCOL_DP
 };
 
+struct drm_hdcp_funcs {
+
+	/**
+	 * @link_write:
+	 *
+	 * Service Function to implement the HDCP protocol write on
+	 * I2C/AUX bus based on HDCP protocol.
+	 *
+	 * returns No of Bytes written on success
+	 *		else negative error codes
+	 **/
+	ssize_t (*link_write)(struct drm_hdcp *hdcp, uint32_t offset,
+			void *buf, size_t size);
+
+	/**
+	 * @link_read:
+	 *
+	 * Service Function to implement the HDCP protocol read on
+	 * I2C/AUX bus based on HDCP protocol.
+	 *
+	 * returns No of Bytes read on success
+	 *		else negative error codes
+	 **/
+	ssize_t (*link_read)(struct drm_hdcp *hdcp, uint32_t offset,
+			void *buf, size_t size);
+
+	/**
+	 * @late_init:
+	 *
+	 * Service function to do any deferred init at platform level.
+	 *
+	 * returns 0 on success
+	 *		else negative error codes
+	 **/
+	int (*late_init)(struct drm_hdcp *hdcp);
+};
+
 /**
  * Struct drm_hdcp - central drm hdcp control structure
  */
@@ -83,6 +121,8 @@ struct drm_hdcp {
 	/* HDMI/DP Protocol */
 	enum wired_protocol protocol;
 
+	const struct drm_hdcp_funcs *hdcp_funcs;
+
 	struct mutex mutex;
 };
 
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 07/20] drm/hdcp: Initialization of DRM hdcp stack

[Ramalingam C]

Initialization of the drm hdcp stack drm_hdcp_init is implemented.
This function has to be called by the display driver to get the
DRM support for HDCP.

This function will take the pointers to the drm_hdcp and associated
drm_conenctor. These two entities will be linked. And HDCP version
supported by the Display driver is received as another parameter.
And corresponding callback fucntions can be validated.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_hdcp.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++
 include/drm/drm_hdcp.h     |  7 +++++
 2 files changed, 82 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_hdcp.c

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
new file mode 100644
index 0000000..481bc24
--- /dev/null
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+/**
+ * Implementation of HDCP stack for DRM
+ */
+#include <linux/errno.h>
+#include <linux/export.h>
+#include <linux/i2c.h>
+#include <drm/drmP.h>
+#include <drm/drm_connector.h>
+#include <drm/drm_hdcp.h>
+#include <drm/drm_dp_helper.h>
+
+/**
+ * @drm_hdcp_init:
+ *	Initialization of the HDCP stack of the DRM
+ *
+ * Return 0 on success else -ve.
+ */
+int drm_hdcp_init(struct drm_connector *connector,
+				struct drm_hdcp *hdcp,
+				uint8_t spec_supported)
+{
+	struct drm_mode_config *config = &connector->dev->mode_config;
+
+	if (!hdcp)
+		return -EINVAL;
+
+	if (!hdcp->hdcp_funcs) {
+		DRM_ERROR("Callback functions are missing\n");
+		return -EINVAL;
+	}
+
+	if (!spec_supported) {
+		DRM_ERROR("HDCP version support is not mentioned\n");
+		return -EINVAL;
+	}
+
+	/* Check for Essential Service Funcs */
+	if (!hdcp->hdcp_funcs->link_write || !hdcp->hdcp_funcs->link_read)
+		return -EINVAL;
+
+	hdcp->ver_support_on_plat = spec_supported;
+
+	connector->hdcp = hdcp;
+	hdcp->connector = connector;
+
+	drm_object_attach_property(&connector->base,
+				   config->hdcp_property,
+				   0);
+
+	mutex_init(&hdcp->mutex);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_hdcp_init);
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 2a48ef9..e8136ef 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -37,6 +37,9 @@ struct drm_hdcp;
 #define HDCP_1_4_SUPPORT			(1<<0)
 #define HDCP_2_2_SUPPORT			(1<<1)
 
+#define HDCP_STREAM_TYPE0_CODE			0x00
+#define HDCP_STREAM_TYPE1_CODE			0x01
+
 /**
  * @enum hdcp_status Enumeration of all HDCP Status Codes
  */
@@ -154,4 +157,8 @@ struct drm_hdcp {
 					DRM_HDCP_LINK_INTEGRITY_FAILED | \
 					DRM_HDCP_REAUTH_REQUESTED)
 
+/* Functions exported */
+extern int drm_hdcp_init(struct drm_connector *connector,
+					struct drm_hdcp *hdcp,
+					uint8_t spec_supported);
 #endif	/* __DRM_HDCP_H__ */
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 08/20] drm/hdcp: Add KBuild for DRM HDCP support

[Ramalingam C]

New config variable CONFIG_DRM_HDCP is added.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/Kconfig  | 12 ++++++++++++
 drivers/gpu/drm/Makefile |  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 83cb2a8..94501ec 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -26,6 +26,18 @@ config DRM_MIPI_DSI
 	bool
 	depends on DRM
 
+config DRM_HDCP
+	bool "Generic HDCP Support on DRM"
+	depends on DRM
+	help
+	  DRM support for HDCP Protection. This can be extended for
+	  multiple version of HDCP in parallel and also for many
+	  HDCP adaptations also.
+		HDCP Versions supported
+			HDCP2.2
+		HDCP Adaptations supported
+			HDMI
+
 config DRM_DP_AUX_CHARDEV
 	bool "DRM DP AUX Interface"
 	depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e..4e0af1f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -19,6 +19,7 @@ drm-y       :=	drm_auth.o drm_bufs.o drm_cache.o \
 		drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
 		drm_syncobj.o
 
+drm-$(CONFIG_DRM_HDCP) += drm_hdcp.o
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
-- 
2.7.4

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

[RFC v1 09/20] drm/hdcp: Generic enable, disable and late_init

[Ramalingam C]

Generic HDCP enable disable and late_init implemented.
When new HDCP version support is added to general stack corresponding
enable, disable and late_init will be invoked from these
implementation.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_hdcp.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 481bc24..ab80370 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -30,6 +30,57 @@
 #include <drm/drm_hdcp.h>
 #include <drm/drm_dp_helper.h>
 
+int drm_hdcp_enable(struct drm_connector *connector, uint8_t stream_type)
+{
+	struct drm_hdcp *hdcp = connector->hdcp;
+	int ret = -EINVAL;
+
+	if (!hdcp)
+		return ret;
+
+	if (connector->status != connector_status_connected) {
+		DRM_ERROR("Panel is not connected\n");
+		return ret;
+	}
+
+	/*
+	 * TODO: Invoke the Version specific hdcp_enable
+	 */
+
+	return 0;
+}
+
+int drm_hdcp_disable(struct drm_connector *connector)
+{
+	struct drm_hdcp *hdcp = connector->hdcp;
+
+	/* Skip if HDCP is not enabled or HDCP enable is not in progress */
+	if (!(connector->hdcp_state & DRM_HDCP_ENABLE ||
+			(hdcp->req_state & DRM_HDCP_ENABLE &&
+				connector->hdcp_state & DRM_HDCP_WIP))) {
+		DRM_ERROR("HDCP is not enabled\n");
+		return 0;
+	}
+
+	/*
+	 * TODO: Invoke the Version specific hdcp_disable
+	 */
+
+	return 0;
+}
+
+void drm_hdcp_late_init(struct drm_connector *connector)
+{
+	struct drm_hdcp *hdcp = connector->hdcp;
+
+	if (hdcp->hdcp_funcs->late_init)
+		hdcp->hdcp_funcs->late_init(hdcp);
+
+	/*
+	 * TODO: Invoke the Version specific late_init
+	 */
+}
+
 /**
  * @drm_hdcp_init:
  *	Initialization of the HDCP stack of the DRM
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 10/20] drm/hdcp: Handler for connector state change

[Ramalingam C]

On hotplug/detection of connector Panel's HDCP capability is probed.
On hot unplug of connector HDCP is diabled, if it has beed enabled.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_hdcp.c | 24 ++++++++++++++++++++++++
 include/drm/drm_hdcp.h     |  9 +++++++++
 2 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index ab80370..89c7c5e 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -82,6 +82,30 @@ void drm_hdcp_late_init(struct drm_connector *connector)
 }
 
 /**
+ * @drm_hdcp_connector_state_change_handler:
+ *
+ * Handler for the Connector state change.
+ */
+void drm_hdcp_connector_state_change_handler(struct drm_connector *connector)
+{
+	if (!connector->hdcp)
+		return;
+
+	if (connector->status == connector_status_connected) {
+
+		/* Probes the panel capability */
+		drm_hdcp_late_init(connector);
+	} else {
+		drm_hdcp_disable(connector);
+		connector->hdcp->ver_support_on_panel = 0;
+
+		/* Removing support for all versions */
+		connector->hdcp_state &= ~DRM_HDCP_VER_SUPPORT_MASK;
+	}
+}
+EXPORT_SYMBOL(drm_hdcp_connector_state_change_handler);
+
+/**
  * @drm_hdcp_init:
  *	Initialization of the HDCP stack of the DRM
  *
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index e8136ef..89879ff 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -157,8 +157,17 @@ struct drm_hdcp {
 					DRM_HDCP_LINK_INTEGRITY_FAILED | \
 					DRM_HDCP_REAUTH_REQUESTED)
 
+#define DRM_HDCP_VER_SUPPORT_SHIFT		12
+#define DRM_HDCP_VER_SUPPORT_MASK		(0xFFULL<< \
+						DRM_HDCP_VER_SUPPORT_SHIFT)
+#define DRM_HDCP_TYPE_SHIFT			4
+#define DRM_HDCP_TYPE_MASK			(0xFFULL<<DRM_HDCP_TYPE_SHIFT)
+
 /* Functions exported */
 extern int drm_hdcp_init(struct drm_connector *connector,
 					struct drm_hdcp *hdcp,
 					uint8_t spec_supported);
+extern void drm_hdcp_connector_state_change_handler(
+				struct drm_connector *connector);
+
 #endif	/* __DRM_HDCP_H__ */
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 11/20] drm/hdcp: Registering for connector state change

[Ramalingam C]

On connector state change detection, HDCP handler for connector
state change notified.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_probe_helper.c   | 3 +++
 drivers/gpu/drm/i915/intel_hotplug.c | 6 +++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index 00e6832..5545f51 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -467,6 +467,9 @@ int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
 		if (dev->mode_config.poll_enabled)
 			schedule_delayed_work(&dev->mode_config.output_poll_work,
 					      0);
+
+		/* Signaling connector state change to the HDCP module */
+		drm_hdcp_connector_state_change_handler(connector);
 	}
 
 	/* Re-enable polling in case the global poll config changed. */
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c
index f120027..891898e 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -25,6 +25,7 @@
 
 #include <drm/drmP.h>
 #include <drm/i915_drm.h>
+#include <drm/drm_hdcp.h>
 
 #include "i915_drv.h"
 #include "intel_drv.h"
@@ -344,8 +345,11 @@ static void i915_hotplug_work_func(struct work_struct *work)
 				      connector->name, intel_encoder->hpd_pin);
 			if (intel_encoder->hot_plug)
 				intel_encoder->hot_plug(intel_encoder);
-			if (intel_hpd_irq_event(dev, connector))
+			if (intel_hpd_irq_event(dev, connector)) {
 				changed = true;
+				drm_hdcp_connector_state_change_handler(
+								connector);
+			}
 		}
 	}
 	drm_connector_list_iter_end(&conn_iter);
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 12/20] drm/hdcp: Atomic set and get property for hdcp

[Ramalingam C]

Atomic ioctl request is pruned based on the platform
and panel's HDCP capabilities along with current state of HDCP
protection on the connector.

Valid enable and disable requests are passed on to the
HDCP stack.

get_property also updated with current state of the HDCP on
connector.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_atomic.c |  5 +++++
 drivers/gpu/drm/drm_hdcp.c   | 53 ++++++++++++++++++++++++++++++++++++++++++++
 include/drm/drm_hdcp.h       |  1 +
 3 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 09ca662..9d4af3b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -30,6 +30,7 @@
 #include <drm/drm_atomic.h>
 #include <drm/drm_mode.h>
 #include <drm/drm_print.h>
+#include <drm/drm_hdcp.h>
 #include <linux/sync_file.h>
 
 #include "drm_crtc_internal.h"
@@ -1188,6 +1189,8 @@ int drm_atomic_connector_set_property(struct drm_connector *connector,
 		 */
 		if (state->link_status != DRM_LINK_STATUS_GOOD)
 			state->link_status = val;
+	} else if (property == config->hdcp_property) {
+		return drm_hdcp_set_property(connector, val);
 	} else if (property == config->aspect_ratio_property) {
 		state->picture_aspect_ratio = val;
 	} else if (property == connector->scaling_mode_property) {
@@ -1268,6 +1271,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
 		*val = state->tv.hue;
 	} else if (property == config->link_status_property) {
 		*val = state->link_status;
+	} else if (property == config->hdcp_property) {
+		*val = connector->hdcp_state;
 	} else if (property == config->aspect_ratio_property) {
 		*val = state->picture_aspect_ratio;
 	} else if (property == connector->scaling_mode_property) {
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 89c7c5e..9b3bf92 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -69,6 +69,59 @@ int drm_hdcp_disable(struct drm_connector *connector)
 	return 0;
 }
 
+
+/**
+ * @drm_hdcp_set_property:
+ *
+ * Entry function for hdcp_enable and hdcp_disable.
+ */
+int drm_hdcp_set_property(struct drm_connector *connector,
+						uint64_t req_state)
+{
+	struct drm_hdcp *hdcp = connector->hdcp;
+	uint64_t cur_state = connector->hdcp_state;
+	uint8_t stream_type;
+
+	if (connector->status != connector_status_connected)
+		return -EINVAL;
+
+	if (!hdcp)
+		return -EINVAL;
+
+	DRM_DEBUG("Prop_val: Current : 0x%llx, Request: 0x%llx\n",
+						cur_state, req_state);
+
+	if (!(cur_state & DRM_HDCP_VER_SUPPORT_MASK)) {
+		DRM_ERROR("None of the HDCP Ver is supported\n");
+		return -EINVAL;
+	}
+
+	if ((cur_state & DRM_HDCP_ENABLE) ==
+				(req_state & DRM_HDCP_ENABLE)) {
+		DRM_DEBUG("Req for current state is redundant\n");
+		return -EINVAL;
+	}
+
+	if (!(cur_state & DRM_HDCP2_SUPPORTED) &&
+				req_state & DRM_HDCP_TYPE_BIT0) {
+		DRM_ERROR("Type 1 HDCP is not available\n");
+		return -EINVAL;
+	}
+
+	if (cur_state & DRM_HDCP_WIP)
+		return -EBUSY;
+
+	if (req_state & DRM_HDCP_ENABLE) {
+		stream_type = (req_state & DRM_HDCP_TYPE_MASK) >>
+					DRM_HDCP_TYPE_SHIFT;
+		return drm_hdcp_enable(connector, stream_type);
+	} else {
+		drm_hdcp_disable(connector);
+	}
+
+	return 0;
+}
+
 void drm_hdcp_late_init(struct drm_connector *connector)
 {
 	struct drm_hdcp *hdcp = connector->hdcp;
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 89879ff..eb7149b 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -169,5 +169,6 @@ extern int drm_hdcp_init(struct drm_connector *connector,
 					uint8_t spec_supported);
 extern void drm_hdcp_connector_state_change_handler(
 				struct drm_connector *connector);
+int drm_hdcp_set_property(struct drm_connector *connector, uint64_t val);
 
 #endif	/* __DRM_HDCP_H__ */
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 13/20] drm/hdcp: Updating DRM Property val with HDCP state

[Ramalingam C]

Implemented drm_hdcp_update_change() for updating the current
status to the hdcp_property value.

This will update the error status flag incase of encryption failure.
Whenever there is a HDCP state change KOBJ_UEVENT will be broadcasted
to notify the awaiting userspace consumers.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_hdcp.c | 40 ++++++++++++++++++++++++++++++++++++++++
 include/drm/drm_hdcp.h     |  3 +++
 2 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 9b3bf92..9785ab6 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -30,6 +30,46 @@
 #include <drm/drm_hdcp.h>
 #include <drm/drm_dp_helper.h>
 
+/*
+ * drm_hdcp_update_change:
+ *		Updating the HDCP property val along with uevent
+ *
+ * @hdcp:	ptr to hdcp instance
+ * @enabled:	status of HDCP encryption
+ * @status:	Error status bits, if auth failed.
+ * @mute:	uevent is mute or not
+ */
+static void drm_hdcp_update_change(struct drm_hdcp *hdcp, bool enabled,
+						uint64_t status, bool mute)
+{
+	struct drm_connector *connector = hdcp->connector;
+	char event_str[30];
+	uint64_t temp_state;
+
+	/* Mutex has to be acquired before entering this function */
+	WARN_ON(!mutex_is_locked(&hdcp->mutex));
+	temp_state = connector->hdcp_state;
+
+	if (enabled) {
+		temp_state &= ~(DRM_HDCP_ENABLE | DRM_HDCP_TYPE_MASK
+						| DRM_HDCP_STATUS_MASK);
+		temp_state |= hdcp->req_state;
+	} else {
+		temp_state &= DRM_HDCP_VER_SUPPORT_MASK;
+		temp_state |= (status & DRM_HDCP_STATUS_MASK);
+	}
+
+	connector->hdcp_state = temp_state;
+
+	if (!mute) {
+		sprintf(event_str, "HDCP=0x%llx", connector->hdcp_state);
+
+		/* Generating the uevent with custom string */
+		drm_sysfs_generate_uevent(hdcp->connector->dev, event_str);
+	}
+}
+
+
 int drm_hdcp_enable(struct drm_connector *connector, uint8_t stream_type)
 {
 	struct drm_hdcp *hdcp = connector->hdcp;
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index eb7149b..d5adbf5 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -163,6 +163,9 @@ struct drm_hdcp {
 #define DRM_HDCP_TYPE_SHIFT			4
 #define DRM_HDCP_TYPE_MASK			(0xFFULL<<DRM_HDCP_TYPE_SHIFT)
 
+#define DRM_HDCP_STATUS_SHIFT			20
+#define DRM_HDCP_STATUS_MASK			(0xFULL<<DRM_HDCP_STATUS_SHIFT)
+
 /* Functions exported */
 extern int drm_hdcp_init(struct drm_connector *connector,
 					struct drm_hdcp *hdcp,
-- 
2.7.4

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

[RFC v1 14/20] drm/hdcp2.2: HDCP2.2 protocol msg definitions

[Ramalingam C]

Protocol message structures and constants of the
HDCP2.2 specification are defined at <drm/drm_hdcp.h>

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 include/drm/drm_hdcp.h | 204 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 204 insertions(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index d5adbf5..1f9a04d 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -166,6 +166,210 @@ struct drm_hdcp {
 #define DRM_HDCP_STATUS_SHIFT			20
 #define DRM_HDCP_STATUS_MASK			(0xFULL<<DRM_HDCP_STATUS_SHIFT)
 
+
+/**
+ * Protocol message definition for HDCP2.2 specification
+ */
+
+/* HDCP2.2 Msg IDs */
+#define NULL_MSG				1
+#define AKE_INIT				2
+#define AKE_SEND_CERT				3
+#define AKE_NO_STORED_KM			4
+#define AKE_STORED_KM				5
+#define AKE_SEND_HPRIME				7
+#define AKE_SEND_PARING_INFO			8
+#define LC_INIT					9
+#define LC_SEND_LPRIME				10
+#define SKE_SEND_EKS				11
+#define REP_SEND_RECVID_LIST			12
+#define REP_SEND_ACK				15
+#define REP_STREAM_MANAGE			16
+#define REP_STREAM_READY			17
+
+#define HDCP_RTX_LEN				8
+#define HDCP_RRX_LEN				8
+#define RECEIVER_ID_SIZE			5
+
+#define K_PUB_RX_MOD_N_SIZE			128
+#define K_PUB_RX_EXP_E_SIZE			3
+#define K_PUB_RX_SIZE				(K_PUB_RX_MOD_N_SIZE + \
+						 K_PUB_RX_EXP_E_SIZE)
+
+#define DCP_LLC_SIGNATURE_SIZE			384
+
+#define HDCP_E_KPUB_KM_LEN			128
+#define HDCP_E_KH_KM_M_LEN			(16 + 16)
+#define HDCP_H_PRIME_LEN			32
+#define HDCP_E_KH_KM_LEN			16
+#define HDCP_RN_LEN				8
+#define HDCP_L_PRIME_LEN			32
+#define HDCP_E_DKEY_KS_LEN			16
+#define HDCP_RIV_LEN				8
+#define HDCP_SEQ_NUM_LEN			3
+#define HDCP_LPRIME_HALF_SIZE			(HDCP_L_PRIME_LEN / 2)
+#define HDCP_RECEIVER_ID_LEN			5
+#define HDCP_MAX_DEVICE_COUNT			31
+#define HDCP_RECEIVER_IDS_MAX_LEN		(HDCP_RECEIVER_ID_LEN * \
+						 HDCP_MAX_DEVICE_COUNT)
+
+/**
+ * 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 MAX_CONTENT_STREAMS_CNT			1
+
+#define HDCP_MPRIME_LEN				32
+
+struct hdcp_cert_rx {
+	uint8_t	receiver_id[RECEIVER_ID_SIZE];
+	uint8_t	kpub_rx[K_PUB_RX_SIZE];
+	uint8_t	reserved1			:4;
+
+	/* As per HDMI & DP HDCP Spec, must be 0x0 or 0x1 */
+	uint8_t	protocol_descriptor		:4;
+
+	/* As per HDMI & DP HDCP Spec, must be 0x0000 */
+	uint8_t	reserved2;
+	uint8_t	dcp_signature[DCP_LLC_SIGNATURE_SIZE];
+} __packed;
+
+/**
+ * The RxCaps field specified in the HDCP HDMI, DP specs
+ * This field is big endian as specified in the errata.
+ */
+union rx_caps {
+	struct	{
+		uint8_t version;
+		uint8_t receiver_capability_mask_hi;
+		uint8_t repeater:1;
+
+		/* Rsvd in HDMI. Applicable in DP alone */
+		uint8_t hdcp_capable:1;
+		uint8_t receiver_capability_mask_low:6;
+	} fields;
+	uint8_t rx_caps_value[3];
+} __packed;
+
+/**
+ * RxInfo fields Contains various topology information for the
+ * repeater authentication flows
+ */
+union rx_info {
+	struct {
+		uint8_t device_count_hi:1;
+		uint8_t depth:3;
+		uint8_t rsvd:4;
+
+		/* Bit-0: downstream HDCP 1.x device exist */
+		uint8_t hdcp1_device_downstream:1;
+
+		/* Bit-1: downstream HDCP 2.0, 2.1 device exist */
+		uint8_t hdcp2_legacy_device_downstream:1;
+
+		/* Bit-2: downstream Topology limit errors */
+		uint8_t max_cascade_exceeded:1;
+		uint8_t max_devs_exceeded:1;
+		uint8_t device_count_lo:4;
+
+	} fields;
+	uint16_t rx_info_value;
+} __packed;
+
+struct wired_streamid_type {
+	uint8_t stream_id;
+	uint8_t stream_type;
+} __packed;
+
+/**
+ * The TxCaps field specified in the HDCP HDMI, DP specs
+ * This field is big endian as specified in the errata.
+ */
+struct tx_caps {
+	uint8_t			version;
+
+	/* Reserved for HDCP and DP Spec. Read as Zero */
+	uint16_t		transmitter_capability_mask;
+} __packed;
+
+/*
+ * Main structures for HDCP2.2 protocol communication
+ */
+struct wired_ake_init {
+	uint8_t			msg_id;
+	uint8_t			r_tx[HDCP_RTX_LEN];
+	struct tx_caps		tx_caps;
+} __packed;
+
+struct wired_ake_send_cert {
+	uint8_t			msg_id;
+	struct hdcp_cert_rx	cert_rx;
+	uint8_t			r_rx[HDCP_RRX_LEN];
+	union rx_caps		rx_caps;
+} __packed;
+
+struct wired_ake_no_stored_km {
+	uint8_t			msg_id;
+	uint8_t			e_kpub_km[HDCP_E_KPUB_KM_LEN];
+} __packed;
+
+struct wired_ake_stored_km {
+	uint8_t			msg_id;
+	uint8_t			e_kh_km_m[HDCP_E_KH_KM_M_LEN];
+} __packed;
+
+struct wired_ake_send_hprime {
+	uint8_t			msg_id;
+	uint8_t			h_prime[HDCP_H_PRIME_LEN];
+} __packed;
+
+struct wired_ake_send_pairing_info {
+	uint8_t			msg_id;
+	uint8_t			e_kh_km[HDCP_E_KH_KM_LEN];
+} __packed;
+
+struct wired_lc_init {
+	uint8_t			msg_id;
+	uint8_t			r_n[HDCP_RN_LEN];
+} __packed;
+
+struct wired_lc_send_lprime {
+	uint8_t			msg_id;
+	uint8_t			l_prime[HDCP_L_PRIME_LEN];
+} __packed;
+
+struct wired_ske_send_eks {
+	uint8_t			msg_id;
+	uint8_t			e_dkey_ks[HDCP_E_DKEY_KS_LEN];
+	uint8_t			riv[HDCP_RIV_LEN];
+} __packed;
+
+struct wired_rep_send_receiverid_list {
+	uint8_t			msg_id;
+	union rx_info		rx_info;
+	uint8_t			seq_num_v[HDCP_SEQ_NUM_LEN];
+	uint8_t			v_prime[HDCP_LPRIME_HALF_SIZE];
+	uint8_t			receiver_ids[HDCP_RECEIVER_IDS_MAX_LEN];
+} __packed;
+
+struct wired_rep_send_ack {
+	uint8_t			msg_id;
+	uint8_t			v[HDCP_LPRIME_HALF_SIZE];
+} __packed;
+
+struct wired_rep_stream_manage {
+	uint8_t			msg_id;
+	uint8_t			seq_num_m[HDCP_SEQ_NUM_LEN];
+	uint16_t		k;
+	struct wired_streamid_type streams[MAX_CONTENT_STREAMS_CNT];
+} __packed;
+
+struct wired_rep_stream_ready {
+	uint8_t			msg_id;
+	uint8_t			m_prime[HDCP_MPRIME_LEN];
+} __packed;
+
 /* Functions exported */
 extern int drm_hdcp_init(struct drm_connector *connector,
 					struct drm_hdcp *hdcp,
-- 
2.7.4

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

[RFC v1 15/20] drm/hdcp2.2: Display driver service functions

[Ramalingam C]

DRM HDCP2.2 service function interface is defiend.
This will be initialized from display driver.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 include/drm/drm_hdcp.h | 207 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 207 insertions(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 1f9a04d..94acd8d 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -30,6 +30,18 @@
 struct drm_connector;
 struct drm_hdcp;
 
+struct wired_ake_init;
+struct wired_ake_send_cert;
+struct wired_ake_no_stored_km;
+struct wired_ake_send_hprime;
+struct wired_ake_send_pairing_info;
+struct wired_lc_init;
+struct wired_lc_send_lprime;
+struct wired_ske_send_eks;
+struct wired_rep_send_receiverid_list;
+struct wired_rep_send_ack;
+struct wired_rep_stream_ready;
+
 /**
  * HDCP Software stack specific
  */
@@ -71,6 +83,200 @@ enum wired_protocol {
 	WIRED_PROTOCOL_DP
 };
 
+struct drm_hdcp2_funcs {
+
+	/* Authencation and Key Exchange related */
+	/**
+	 * @prepare_ake_init:
+	 *
+	 * Function to prepare the complete ake_init message and
+	 * pass it onto DRM.
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*prepare_ake_init)(struct drm_hdcp *hdcp,
+			struct wired_ake_init *ake_data, size_t buf_sz,
+			size_t *msg_sz);
+
+	/**
+	 * @verify_rx_cert:
+	 *
+	 * Service Function for verifying the DCP signature of rx
+	 * certificate received from HDCP sink and prepare the msg with km as
+	 * AKE_No_Stored_km or AKE_Stored_km.
+	 *
+	 *	Involves:
+	 *	  DCP signature verification.
+	 *	  Receiver ID check against the SRM table's revocation list.
+	 *	  For Non-Paired receiver
+	 *	    Generate a pseudo-random 128-bit Master Key Km
+	 *	    Encrypt km with kpub_rx
+	 *	    Form AKE_No_Stored_km msg
+	 *	  For Paired Device
+	 *	    Forms AKE_Stored_km with stored Ekh(km) and m
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*verify_rx_cert_prepare_km)(struct drm_hdcp *hdcp,
+			struct wired_ake_send_cert *rx_cert,
+			size_t rx_cert_sz, bool *paired,
+			struct wired_ake_no_stored_km *ek_pub_km,
+			size_t buf_sz, size_t *msg_sz);
+
+	/**
+	 * @verify_hprime:
+	 *
+	 * Service Function for verifying the hprime received from receiver.
+	 *	Involves:
+	 *	  Prepare hprime and compare with received hprime
+	 *		hprime = HMAC_SHA256(r_tx || RxCaps || TxCaps, kd)
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*verify_hprime)(struct drm_hdcp *hdcp,
+			struct wired_ake_send_hprime *rx_hprime,
+			size_t hprime_sz);
+
+	/**
+	 * @store_paring_info:
+	 *
+	 * Service Function to store the Ekh(km) along with m in
+	 * non-volatile memory. This is just to fast track the authentication
+	 * of same receiver from next time onwards.
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*store_paring_info)(struct drm_hdcp *hdcp,
+			struct wired_ake_send_pairing_info *pairing_info,
+			size_t pairing_info_sz);
+
+	/* Locality check related services */
+	/**
+	 * @prepare_lc_init:
+	 *
+	 * Service Function to prepare LC_INIT
+	 *	Involves:
+	 *	  Generation of 64bit pseudo aandom nonce rn
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*prepare_lc_init)(struct drm_hdcp *hdcp,
+			struct wired_lc_init *lc_init_data, size_t buf_sz,
+			size_t *msg_sz);
+
+	/**
+	 * @verify_lprime:
+	 *
+	 * Service Function to verify the lprime received from receiver
+	 *	Involves
+	 *	  Calculate L = HMAC-SHA256(rn, kd XOR rrx)
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*verify_lprime)(struct drm_hdcp *hdcp,
+			struct wired_lc_send_lprime *rx_lprime,
+			size_t lprime_sz);
+
+	/* SKE related services */
+	/**
+	 * @prepare_skey:
+	 *
+	 * Service Function to prepare SKE_Send_Eks msg
+	 *	Involves
+	 *	  Generation of Edkey(ks) and riv
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*prepare_skey)(struct drm_hdcp *hdcp,
+			struct wired_ske_send_eks *ske_data,
+			size_t buf_sz, size_t *msg_sz);
+
+	/* Repeater Support services */
+	/**
+	 * @verify_rep_topology:
+	 *
+	 * Service Function to validate the downstream topology and to prepare
+	 * repeater_auth_ack message.
+	 *	Involves
+	 *	  Validate the devcie count and Depth
+	 *	  Look out for HDCP1.x devices or HDCP2.0 devices
+	 *	  Check receiver ID list against revocation list
+	 *	  Check for roll over of seq_num_V
+	 *	  validate the vprime with Most Significant 128bits of V
+	 *	  V’ = HMAC-SHA256(ReceiverID list || RxInfo || seq_num_V, kd)
+	 *	  Least Significant 128bits of V is formed as ack msg.
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*verify_rep_topology_prepare_ack)(
+			struct drm_hdcp *hdcp,
+			struct wired_rep_send_receiverid_list *rep_topology,
+			size_t receiverid_list_sz,
+			struct wired_rep_send_ack *rep_send_ack, size_t buf_sz,
+			size_t *msg_sz);
+
+	/**
+	 * @verify_mprime:
+	 *
+	 * Service Function to verify the MPrime received
+	 *	M’(or M) = HMAC-SHA256(StreamID_Type || seq_num_M, SHA256(kd))
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*verify_mprime)(struct drm_hdcp *hdcp,
+			struct wired_rep_stream_ready *stream_ready,
+			size_t stream_ready_sz);
+
+	/**
+	 * @authenticate:
+	 *
+	 * Service Function to configure HW as Authenticated
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*authenticate)(struct drm_hdcp *hdcp);
+
+	/**
+	 * @deauthenticate:
+	 *
+	 * Service Function to configure HW as deauthenticated
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*deauthenticate)(struct drm_hdcp *hdcp);
+
+	/**
+	 * @enable_encryption:
+	 *
+	 * Service Function to enable encryption at platform level.
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*enable_encryption)(struct drm_hdcp *hdcp);
+
+	/**
+	 * @disable_encryption:
+	 *
+	 * Service function to disable encryption at platform level.
+	 *
+	 * returns HDCP_STATUS_SUCCESS on success
+	 *		else non-zero HDCP error states
+	 **/
+	enum hdcp_status (*disable_encryption)(struct drm_hdcp *hdcp);
+};
+
 struct drm_hdcp_funcs {
 
 	/**
@@ -125,6 +331,7 @@ struct drm_hdcp {
 	enum wired_protocol protocol;
 
 	const struct drm_hdcp_funcs *hdcp_funcs;
+	const struct drm_hdcp2_funcs *hdcp2_funcs;
 
 	struct mutex mutex;
 };
-- 
2.7.4

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

[RFC v1 16/20] drm/hdcp2.2: HDCP2.2 Initialization

[Ramalingam C]

drm_hdcp_init is extended to support HDCP spec Ver2.2.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_hdcp.c | 37 +++++++++++++++++++++++++++++++++++++
 include/drm/drm_hdcp.h     |  6 ++++++
 2 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 9785ab6..5441b55 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -198,6 +198,36 @@ void drm_hdcp_connector_state_change_handler(struct drm_connector *connector)
 }
 EXPORT_SYMBOL(drm_hdcp_connector_state_change_handler);
 
+static inline int drm_hdcp2_init(struct drm_connector *connector,
+				struct drm_hdcp *hdcp,
+				uint8_t spec_supported)
+{
+	if (!hdcp->hdcp2_funcs) {
+		DRM_ERROR("Callback functions are missing\n");
+		return -EINVAL;
+	}
+
+	/* No of streams transmitted on the port */
+	/*
+	 * TODO: For DP, in case of MST we need to figure out a way to
+	 * configure this value on the run. on HDMI it is always 1.
+	 */
+	hdcp->k = 1;
+
+	hdcp->streams = kmalloc_array(hdcp->k,
+				sizeof(struct wired_streamid_type), GFP_KERNEL);
+	if (!hdcp->streams)
+		return -ENOMEM;
+
+	/* For HDMI this is forced to be 0x0 */
+	hdcp->streams[0].stream_id = 0;
+
+	/* Setting it to Type 0 by default */
+	hdcp->streams[0].stream_type = HDCP_STREAM_TYPE0_CODE;
+
+	return 0;
+}
+
 /**
  * @drm_hdcp_init:
  *	Initialization of the HDCP stack of the DRM
@@ -209,6 +239,7 @@ int drm_hdcp_init(struct drm_connector *connector,
 				uint8_t spec_supported)
 {
 	struct drm_mode_config *config = &connector->dev->mode_config;
+	int ret;
 
 	if (!hdcp)
 		return -EINVAL;
@@ -227,6 +258,12 @@ int drm_hdcp_init(struct drm_connector *connector,
 	if (!hdcp->hdcp_funcs->link_write || !hdcp->hdcp_funcs->link_read)
 		return -EINVAL;
 
+	if (spec_supported & HDCP_2_2_SUPPORT) {
+		ret = drm_hdcp2_init(connector, hdcp, spec_supported);
+		if (ret < 0)
+			return ret;
+	}
+
 	hdcp->ver_support_on_plat = spec_supported;
 
 	connector->hdcp = hdcp;
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 94acd8d..47862a7 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -320,6 +320,12 @@ struct drm_hdcp_funcs {
 struct drm_hdcp {
 	struct drm_connector *connector;
 
+	/* No of streams transmitted on the port. 1 incase of HDMI & DP SST */
+	uint16_t k;
+
+	/* k no of structures of wired_streamid_type */
+	struct wired_streamid_type *streams;
+
 	/* HDCP Specifications support flag */
 	uint32_t ver_support_on_plat;
 	uint32_t ver_support_on_panel;
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 17/20] drm/hdcp2.2: Definitions of HDMI HDCP2.2 registers

[Ramalingam C]

HDCP2.2 registers offsets on HDMI are defined along with it constants.
And also timeout macros for HDCP2.2 adaptation for HDMI is defined.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 include/drm/drm_hdcp.h | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 47862a7..dac9831 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -43,6 +43,42 @@ struct wired_rep_send_ack;
 struct wired_rep_stream_ready;
 
 /**
+ * Definitions for HDCP2.2 adaptation for HDMI
+ */
+
+#define DRM_HDCP_2_2_DDC_ADDR			(0x74>>1)
+
+/* HDCP2.2 TIMEOUTs in mSec */
+#define HDCP_2_2_CERT_TIMEOUT			100
+#define HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT	1000
+#define HDCP_2_2_HPRIME_PAIRED_TIMEOUT		200
+#define HDCP_2_2_PAIRING_TIMEOUT		200
+#define	HDCP_2_2_HDMI_LPRIME_TIMEOUT		20
+#define HDCP_2_2_RECVID_LIST_TIMEOUT		3000
+#define HDCP_2_2_STREAM_READY_TIMEOUT		100
+
+/* HDCP2.2 Register Offsets */
+#define HDMI_HDCP2_REG_VER_OFFSET		0x50
+#define HDMI_HDCP2_REG_WR_MSG_OFFSET		0x60
+#define HDMI_HDCP2_REG_RXSTATUS_OFFSET		0x70
+#define HDMI_HDCP2_REG_RD_MSG_OFFSET		0x80
+#define HDMI_HDCP2_REG_DBG_OFFSET		0xC0
+
+#define HDMI_HDCP_2_2_SUPPORT_MASK		(1<<2)
+
+union rx_status_hdmi {
+	struct {
+		uint8_t msg_sz_hi:2;
+		uint8_t ready:1;
+		uint8_t reauth_req:1;
+		uint8_t reserved:4;
+		uint8_t msg_sz_lo;
+	} fields;
+	uint16_t val;
+} __packed;
+
+
+/**
  * HDCP Software stack specific
  */
 /* Bit mask for HDCP spec ver support */
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 18/20] drm/hdcp2.2: Late_init: Capability probing on panel

[Ramalingam C]

When the platform support HDCP2.2, HDCP2.2 capability is probed
on panel from late_init. If platform and panel support HDCP2.2,
DRM_HDCP2_SUPPORTED bit of HDCP property will be set.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_hdcp.c | 41 ++++++++++++++++++++++++++++++++++++++---
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 5441b55..cb20cc9 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -162,6 +162,42 @@ int drm_hdcp_set_property(struct drm_connector *connector,
 	return 0;
 }
 
+static void drm_hdcp_2_2_late_init(struct drm_hdcp *hdcp)
+{
+	uint8_t hdcp2version;
+	void *buf;
+	ssize_t receiv, size;
+	unsigned int offset;
+
+	if (hdcp->protocol == WIRED_PROTOCOL_HDMI) {
+		offset = HDMI_HDCP2_REG_VER_OFFSET;
+		buf = (void *)&hdcp2version;
+		size = sizeof(hdcp2version);
+	} else {
+		DRM_ERROR("Unsupported Protocol\n");
+		return;
+	}
+
+	receiv = hdcp->hdcp_funcs->link_read(hdcp, offset, buf, size);
+	if (receiv == size) {
+		mutex_lock(&hdcp->mutex);
+		if (hdcp2version & HDMI_HDCP_2_2_SUPPORT_MASK) {
+			hdcp->ver_support_on_panel |= HDCP_2_2_SUPPORT;
+			hdcp->connector->hdcp_state |= DRM_HDCP2_SUPPORTED;
+
+			DRM_DEBUG("HDMI with HDCP 2.2\n");
+		} else {
+			hdcp->ver_support_on_panel &= ~HDCP_2_2_SUPPORT;
+			hdcp->connector->hdcp_state &= ~DRM_HDCP2_SUPPORTED;
+
+			DRM_DEBUG("HDMI without HDCP 2.2\n");
+		}
+		mutex_unlock(&hdcp->mutex);
+	} else {
+		DRM_ERROR("HDCP Link read failed. Error: %d\n", (int)receiv);
+	}
+}
+
 void drm_hdcp_late_init(struct drm_connector *connector)
 {
 	struct drm_hdcp *hdcp = connector->hdcp;
@@ -169,9 +205,8 @@ void drm_hdcp_late_init(struct drm_connector *connector)
 	if (hdcp->hdcp_funcs->late_init)
 		hdcp->hdcp_funcs->late_init(hdcp);
 
-	/*
-	 * TODO: Invoke the Version specific late_init
-	 */
+	if (hdcp->ver_support_on_plat & HDCP_2_2_SUPPORT)
+		drm_hdcp_2_2_late_init(hdcp);
 }
 
 /**
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v1 19/20] drm/hdcp2.2: HDCP2.2 enable as a asynchronous work

[Ramalingam C]

HDCP2 Authentication might take more then 5Secs based on the
downstream topology. So when atomic property set ioctl requests
for HDCP enable, We schedule the HDCP2 enbale as a asynchronous
work by not blocking the ioctl call.

The Result of the work will be updated to the DRM Property.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_hdcp.c | 40 +++++++++++++++++++++++++++++++++++++---
 include/drm/drm_hdcp.h     |  8 ++++++++
 2 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index cb20cc9..9e1b7ae 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -69,6 +69,39 @@ static void drm_hdcp_update_change(struct drm_hdcp *hdcp, bool enabled,
 	}
 }
 
+static void hdcp_2_2_enable_work(struct work_struct *work)
+{
+	struct drm_hdcp *hdcp = container_of(work, struct drm_hdcp,
+							hdcp2_enable_work);
+
+	mutex_lock(&hdcp->mutex);
+
+	/* Marking it as WIP */
+	drm_hdcp_update_change(hdcp, false, DRM_HDCP_WIP, true);
+	hdcp->spec_ver_used = HDCP_2_2_SUPPORT;
+
+	/*
+	 * TODO: Implement the HDCP2.2 authentication and Encryption Enable
+	 */
+	mutex_unlock(&hdcp->mutex);
+}
+
+static int drm_hdcp_2_2_enable(struct drm_hdcp *hdcp, uint8_t stream_type)
+{
+	mutex_lock(&hdcp->mutex);
+
+	/* Set the stream type */
+	hdcp->streams[0].stream_type = stream_type;
+
+	hdcp->req_state &= ~(DRM_HDCP_ENABLE | DRM_HDCP_TYPE_MASK);
+	hdcp->req_state = DRM_HDCP_ENABLE |
+				(stream_type << DRM_HDCP_TYPE_SHIFT);
+
+	schedule_work(&hdcp->hdcp2_enable_work);
+
+	mutex_unlock(&hdcp->mutex);
+	return 0;
+}
 
 int drm_hdcp_enable(struct drm_connector *connector, uint8_t stream_type)
 {
@@ -83,9 +116,8 @@ int drm_hdcp_enable(struct drm_connector *connector, uint8_t stream_type)
 		return ret;
 	}
 
-	/*
-	 * TODO: Invoke the Version specific hdcp_enable
-	 */
+	if (connector->hdcp_state & DRM_HDCP2_SUPPORTED)
+		return drm_hdcp_2_2_enable(hdcp, stream_type);
 
 	return 0;
 }
@@ -260,6 +292,8 @@ static inline int drm_hdcp2_init(struct drm_connector *connector,
 	/* Setting it to Type 0 by default */
 	hdcp->streams[0].stream_type = HDCP_STREAM_TYPE0_CODE;
 
+	INIT_WORK(&hdcp->hdcp2_enable_work, hdcp_2_2_enable_work);
+
 	return 0;
 }
 
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index dac9831..ea18bac 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -366,6 +366,12 @@ struct drm_hdcp {
 	uint32_t ver_support_on_plat;
 	uint32_t ver_support_on_panel;
 
+	/*
+	 * HDCP ver last used for Enable. Will help to choose the
+	 * corresponding Version's disable.
+	 */
+	uint32_t spec_ver_used;
+
 	/* HDCP requested state and also the current state */
 	uint64_t req_state;
 
@@ -375,6 +381,8 @@ struct drm_hdcp {
 	const struct drm_hdcp_funcs *hdcp_funcs;
 	const struct drm_hdcp2_funcs *hdcp2_funcs;
 
+	struct work_struct hdcp2_enable_work;
+
 	struct mutex mutex;
 };
 
-- 
2.7.4

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

[RFC v1 20/20] drm/hdcp2.2: HDCP2.2 disable as a asynchronous work

[Ramalingam C]

HDCP2.2 Disable might take some time to destroy the ongoing
link integrity check thread, to disable the encryption and
deauthenticate the port. So Just to unblock the caller like
hotplug handler or IOCTL we are scheduling the HDCP2.2 disable
as an asynchronous work.

Once HDCP is disabled, DRM Property will be updated.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_hdcp.c | 30 +++++++++++++++++++++++++++---
 include/drm/drm_hdcp.h     |  1 +
 2 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 9e1b7ae..a1130d8 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -103,6 +103,30 @@ static int drm_hdcp_2_2_enable(struct drm_hdcp *hdcp, uint8_t stream_type)
 	return 0;
 }
 
+void hdcp_2_2_disable_work(struct work_struct *work)
+{
+	struct drm_hdcp *hdcp = container_of(work, struct drm_hdcp,
+							hdcp2_disable_work);
+
+	mutex_lock(&hdcp->mutex);
+
+	hdcp->req_state &= ~DRM_HDCP_ENABLE;
+
+	/*
+	 * TODO: Implement the HDCP2.2 Disable Sequence
+	 */
+
+	drm_hdcp_update_change(hdcp, false, 0, false);
+
+	mutex_unlock(&hdcp->mutex);
+}
+
+void drm_hdcp_2_2_disable(struct drm_hdcp *hdcp)
+{
+	if (!schedule_work(&hdcp->hdcp2_disable_work))
+		DRM_ERROR("Disable work is already in queue\n");
+}
+
 int drm_hdcp_enable(struct drm_connector *connector, uint8_t stream_type)
 {
 	struct drm_hdcp *hdcp = connector->hdcp;
@@ -134,9 +158,8 @@ int drm_hdcp_disable(struct drm_connector *connector)
 		return 0;
 	}
 
-	/*
-	 * TODO: Invoke the Version specific hdcp_disable
-	 */
+	if (hdcp->spec_ver_used & HDCP_2_2_SUPPORT)
+		drm_hdcp_2_2_disable(hdcp);
 
 	return 0;
 }
@@ -293,6 +316,7 @@ static inline int drm_hdcp2_init(struct drm_connector *connector,
 	hdcp->streams[0].stream_type = HDCP_STREAM_TYPE0_CODE;
 
 	INIT_WORK(&hdcp->hdcp2_enable_work, hdcp_2_2_enable_work);
+	INIT_WORK(&hdcp->hdcp2_disable_work, hdcp_2_2_disable_work);
 
 	return 0;
 }
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index ea18bac..bff229f 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -382,6 +382,7 @@ struct drm_hdcp {
 	const struct drm_hdcp2_funcs *hdcp2_funcs;
 
 	struct work_struct hdcp2_enable_work;
+	struct work_struct hdcp2_disable_work;
 
 	struct mutex mutex;
 };
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

✗ Fi.CI.BAT: failure for DRM Interfaces for HDCP support

[Patchwork]

== Series Details ==

Series: DRM Interfaces for HDCP support
URL   : https://patchwork.freedesktop.org/series/27170/
State : failure

== Summary ==

  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CHK     include/generated/bounds.h
  CHK     include/generated/timeconst.h
  CHK     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CHK     scripts/mod/devicetable-offsets.h
  CHK     include/generated/compile.h
  CHK     kernel/config_data.h
  CHK     include/generated/uapi/linux/version.h
  GEN     .version
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      vmlinux.o
  MODPOST vmlinux.o
drivers/built-in.o: In function `drm_helper_probe_single_connector_modes':
/home/cidrm/kernel/drivers/gpu/drm/drm_probe_helper.c:472: undefined reference to `drm_hdcp_connector_state_change_handler'
drivers/built-in.o: In function `drm_atomic_connector_set_property':
/home/cidrm/kernel/drivers/gpu/drm/drm_atomic.c:1193: undefined reference to `drm_hdcp_set_property'
Makefile:997: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

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

Re: [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote:
> DRM connector property is created as bitmask to receive
> HDCP enable/disable request along with content type.
> 
> And also there are Read only status bits for
> 	1. HDCP spec capability of the connector + panel
> 	2. HDCP encryption status of the connector
> 
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> ---
>  drivers/gpu/drm/drm_connector.c | 30 +++++++++++++++++++++
>  include/drm/drm_hdcp.h          | 58 +++++++++++++++++++++++++++++++++++++++++
>  include/drm/drm_mode_config.h   |  5 ++++
>  3 files changed, 93 insertions(+)
>  create mode 100644 include/drm/drm_hdcp.h
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8072e6e..04f8cf8 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -24,6 +24,7 @@
>  #include <drm/drm_connector.h>
>  #include <drm/drm_edid.h>
>  #include <drm/drm_encoder.h>
> +#include <drm/drm_hdcp.h>
>  
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> @@ -617,6 +618,28 @@ 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_hdcp_enum_list[] = {
> +	{ __builtin_ffs(DRM_HDCP_ENABLE) - 1,
> +					"Enable HDCP Encryption" },
> +	{ __builtin_ffs(DRM_HDCP_TYPE_BIT0) - 1,
> +					"HDCP Content type bit0" },
> +	{ __builtin_ffs(DRM_HDCP_TYPE_BIT1) - 1,
> +					"HDCP Content type bit1" },
> +	{ __builtin_ffs(DRM_HDCP1_SUPPORTED) - 1,
> +					"HDCP1.x Supported" },
> +	{ __builtin_ffs(DRM_HDCP2_SUPPORTED) - 1,
> +					"HDCP2.x Supported" },
> +	{ __builtin_ffs(DRM_HDCP_WIP) - 1,
> +					"HDCP work in progress" },
> +	{ __builtin_ffs(DRM_HDCP_AUTH_FAILED) - 1,
> +					"HDCP Authentication Failed" },
> +	{ __builtin_ffs(DRM_HDCP_LINK_INTEGRITY_FAILED) - 1,
> +					"HDCP Link Integrity Failed" },
> +	{ __builtin_ffs(DRM_HDCP_REAUTH_REQUESTED) - 1,
> +					"HDCP Reauthentication Requested" },

Why all these intermediate steps and different failure modes? Either hdcp
works, or it doesnt (and we can split up with the type 0 or type 1 if
needed), but I don't know what userspace would do with all the other
stuff?

This also doesn't seem to do the lockdown mode to force hdcp mode. And
afair it also doesn't match what CrOS currently uses, which means we don't
have userspace for this.

I think the best approach would be if we simply try to upstream _exactly_
the property CrOS currently uses (not even bothering with type 0 vs type 1
if that's not required), since that is the currently only open source
userspace that asks for this. Going with a much more complicated or
different interface just because only risks a massive discussion and
subsequent long delays.
-Daniel

> +};
> +DRM_ENUM_NAME_FN(drm_get_hdcp_name, drm_hdcp_enum_list)
> +
>  /**
>   * drm_display_info_set_bus_formats - set the supported bus formats
>   * @info: display info to store bus formats in
> @@ -789,6 +812,13 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
>  		return -ENOMEM;
>  	dev->mode_config.link_status_property = prop;
>  
> +	prop = drm_property_create_bitmask(dev, 0, "hdcp", drm_hdcp_enum_list,
> +					   ARRAY_SIZE(drm_hdcp_enum_list),
> +					   DRM_HDCP_PROP_SUPPORTED_BITS);
> +	if (!prop)
> +		return -ENOMEM;
> +	dev->mode_config.hdcp_property = prop;
> +
>  	return 0;
>  }
>  
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> new file mode 100644
> index 0000000..7cebf0f
> --- /dev/null
> +++ b/include/drm/drm_hdcp.h
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission.  The copyright holders make no representations
> + * about the suitability of this software for any purpose.  It is provided "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
> + * OF THIS SOFTWARE.
> + */
> +
> +/*
> + * Header for HDCP specific data
> + */
> +
> +#ifndef __DRM_HDCP_H__
> +#define __DRM_HDCP_H__
> +
> +/**
> + * HDCP property related information
> + */
> +/* RW: HDCP Encryption Requests and Status bits */
> +#define DRM_HDCP_ENABLE				BIT(0)
> +#define DRM_HDCP_TYPE_BIT0			BIT(4)
> +#define DRM_HDCP_TYPE_BIT1			BIT(5)
> +
> +/* RO: HDCP Version supported on Platform + panel */
> +#define DRM_HDCP1_SUPPORTED			BIT(12)
> +#define DRM_HDCP2_SUPPORTED			BIT(13)
> +
> +/* RO: Status of the requested operations */
> +#define DRM_HDCP_WIP				BIT(20)
> +#define DRM_HDCP_AUTH_FAILED			BIT(21)
> +
> +/* RO: Error Status From HDCP sink */
> +#define DRM_HDCP_LINK_INTEGRITY_FAILED		BIT(22)
> +#define DRM_HDCP_REAUTH_REQUESTED		BIT(23)
> +
> +#define DRM_HDCP_PROP_SUPPORTED_BITS	(DRM_HDCP_ENABLE | DRM_HDCP_TYPE_BIT0 \
> +					| DRM_HDCP_TYPE_BIT1 | \
> +					DRM_HDCP1_SUPPORTED | \
> +					DRM_HDCP2_SUPPORTED | DRM_HDCP_WIP | \
> +					DRM_HDCP_AUTH_FAILED | \
> +					DRM_HDCP_LINK_INTEGRITY_FAILED | \
> +					DRM_HDCP_REAUTH_REQUESTED)
> +
> +#endif	/* __DRM_HDCP_H__ */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 4298171..0c5bb90 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;
>  	/**
> +	 * @hdcp_property: Default connector property for HDCP
> +	 * of a connector
> +	 */
> +	struct drm_property *hdcp_property;
> +	/**
>  	 * @plane_type_property: Default plane property to differentiate
>  	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
>  	 */
> -- 
> 2.7.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

[-- Attachment #1.1: Type: text/plain, Size: 9264 bytes --]

Daniel,

Thank you for reviewing the patch in short time. My views are below.


On Wednesday 12 July 2017 03:24 PM, Daniel Vetter wrote:
> On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote:
>> DRM connector property is created as bitmask to receive
>> HDCP enable/disable request along with content type.
>>
>> And also there are Read only status bits for
>> 	1. HDCP spec capability of the connector + panel
>> 	2. HDCP encryption status of the connector
>>
>> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
>> ---
>>   drivers/gpu/drm/drm_connector.c | 30 +++++++++++++++++++++
>>   include/drm/drm_hdcp.h          | 58 +++++++++++++++++++++++++++++++++++++++++
>>   include/drm/drm_mode_config.h   |  5 ++++
>>   3 files changed, 93 insertions(+)
>>   create mode 100644 include/drm/drm_hdcp.h
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> index 8072e6e..04f8cf8 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -24,6 +24,7 @@
>>   #include <drm/drm_connector.h>
>>   #include <drm/drm_edid.h>
>>   #include <drm/drm_encoder.h>
>> +#include <drm/drm_hdcp.h>
>>   
>>   #include "drm_crtc_internal.h"
>>   #include "drm_internal.h"
>> @@ -617,6 +618,28 @@ 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_hdcp_enum_list[] = {
>> +	{ __builtin_ffs(DRM_HDCP_ENABLE) - 1,
>> +					"Enable HDCP Encryption" },
>> +	{ __builtin_ffs(DRM_HDCP_TYPE_BIT0) - 1,
>> +					"HDCP Content type bit0" },
>> +	{ __builtin_ffs(DRM_HDCP_TYPE_BIT1) - 1,
>> +					"HDCP Content type bit1" },
>> +	{ __builtin_ffs(DRM_HDCP1_SUPPORTED) - 1,
>> +					"HDCP1.x Supported" },
>> +	{ __builtin_ffs(DRM_HDCP2_SUPPORTED) - 1,
>> +					"HDCP2.x Supported" },
>> +	{ __builtin_ffs(DRM_HDCP_WIP) - 1,
>> +					"HDCP work in progress" },
>> +	{ __builtin_ffs(DRM_HDCP_AUTH_FAILED) - 1,
>> +					"HDCP Authentication Failed" },
>> +	{ __builtin_ffs(DRM_HDCP_LINK_INTEGRITY_FAILED) - 1,
>> +					"HDCP Link Integrity Failed" },
>> +	{ __builtin_ffs(DRM_HDCP_REAUTH_REQUESTED) - 1,
>> +					"HDCP Reauthentication Requested" },
> Why all these intermediate steps and different failure modes? Either hdcp
> works, or it doesnt (and we can split up with the type 0 or type 1 if
> needed), but I don't know what userspace would do with all the other
> stuff?
enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with 
kobj-uevent
for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2 
configuration.

And without Type info it is not possible for HDCP2.2.

But to inform whether both HDCP source and Sink support HDCP1.4/2.2/None 
I wanted to add
the capability bits. These capability flags could be avoided if the 
presence of the drm_hdcp_property
on connector, assures the corresponding HDCP version support on both 
HDCP src and sink.
But for that we need a way to detach/alter the DRM_property of connector 
based on HDCP
sink's hdcp version capability. Need to explore on that direction if 
that is allowed.

Once HDCP protection is enabled link protection might break for many 
reasons including hot unplug. So Other Error
flags are just to give more information to UMD on that scenario. But we 
can avoid them by setting the state
as HDCP_DISABLE and notifying the UMD through Kobj-uevent for HDCP state 
change.

But one concern remains un-addressed that is compliance requirement will 
force us to reauthenticate
in case of failures in authentication or on HDCP enabled link. In that 
scenario UMD has to be in formed that
reauth is in progress. If UMD wants the port to be reenabled it has to 
wait for the completion of reauth else
it has to place request for disabling the HDCP on port. We might want to 
add a enum value as HDCP_DISABLE_REAUTH.
What is your opinion on this?
>
> This also doesn't seem to do the lockdown mode to force hdcp mode. And
> afair it also doesn't match what CrOS currently uses, which means we don't
> have userspace for this.
AFAIK, Either way we don't have userspace for HDCP2.2 at present, as 
CrOS interface is designed for
HDCP1.4(Need to cross check this with sean). But I will check with 
seanpaul if there is any plan for extending it for HDCP2.2 too.
If so we could enable CrOS as consumer for HDCP2.2 against planned open 
source consumer from my side.

As discussed in cover letter I am starting on a UMD library
which will be open sourced as a HDCP1.4 and 2.2 service provider for 
chromebox stack and Android.

>
> I think the best approach would be if we simply try to upstream _exactly_
> the property CrOS currently uses (not even bothering with type 0 vs type 1
> if that's not required), since that is the currently only open source
> userspace that asks for this.
At first stage, as we are developing the HDCP2.2 support at DRM at first 
than HDCP1.4,
we need to extend CrOS property for HDCP2.2 and then upstream. That will 
be the fruitful solution for us.

--Ram
>   Going with a much more complicated or
> different interface just because only risks a massive discussion and
> subsequent long delays.
> -Daniel
>
>> +};
>> +DRM_ENUM_NAME_FN(drm_get_hdcp_name, drm_hdcp_enum_list)
>> +
>>   /**
>>    * drm_display_info_set_bus_formats - set the supported bus formats
>>    * @info: display info to store bus formats in
>> @@ -789,6 +812,13 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
>>   		return -ENOMEM;
>>   	dev->mode_config.link_status_property = prop;
>>   
>> +	prop = drm_property_create_bitmask(dev, 0, "hdcp", drm_hdcp_enum_list,
>> +					   ARRAY_SIZE(drm_hdcp_enum_list),
>> +					   DRM_HDCP_PROP_SUPPORTED_BITS);
>> +	if (!prop)
>> +		return -ENOMEM;
>> +	dev->mode_config.hdcp_property = prop;
>> +
>>   	return 0;
>>   }
>>   
>> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
>> new file mode 100644
>> index 0000000..7cebf0f
>> --- /dev/null
>> +++ b/include/drm/drm_hdcp.h
>> @@ -0,0 +1,58 @@
>> +/*
>> + * Copyright (c) 2017 Intel Corporation
>> + *
>> + * Permission to use, copy, modify, distribute, and sell this software and its
>> + * documentation for any purpose is hereby granted without fee, provided that
>> + * the above copyright notice appear in all copies and that both that copyright
>> + * notice and this permission notice appear in supporting documentation, and
>> + * that the name of the copyright holders not be used in advertising or
>> + * publicity pertaining to distribution of the software without specific,
>> + * written prior permission.  The copyright holders make no representations
>> + * about the suitability of this software for any purpose.  It is provided "as
>> + * is" without express or implied warranty.
>> + *
>> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
>> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
>> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
>> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
>> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
>> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
>> + * OF THIS SOFTWARE.
>> + */
>> +
>> +/*
>> + * Header for HDCP specific data
>> + */
>> +
>> +#ifndef __DRM_HDCP_H__
>> +#define __DRM_HDCP_H__
>> +
>> +/**
>> + * HDCP property related information
>> + */
>> +/* RW: HDCP Encryption Requests and Status bits */
>> +#define DRM_HDCP_ENABLE				BIT(0)
>> +#define DRM_HDCP_TYPE_BIT0			BIT(4)
>> +#define DRM_HDCP_TYPE_BIT1			BIT(5)
>> +
>> +/* RO: HDCP Version supported on Platform + panel */
>> +#define DRM_HDCP1_SUPPORTED			BIT(12)
>> +#define DRM_HDCP2_SUPPORTED			BIT(13)
>> +
>> +/* RO: Status of the requested operations */
>> +#define DRM_HDCP_WIP				BIT(20)
>> +#define DRM_HDCP_AUTH_FAILED			BIT(21)
>> +
>> +/* RO: Error Status From HDCP sink */
>> +#define DRM_HDCP_LINK_INTEGRITY_FAILED		BIT(22)
>> +#define DRM_HDCP_REAUTH_REQUESTED		BIT(23)
>> +
>> +#define DRM_HDCP_PROP_SUPPORTED_BITS	(DRM_HDCP_ENABLE | DRM_HDCP_TYPE_BIT0 \
>> +					| DRM_HDCP_TYPE_BIT1 | \
>> +					DRM_HDCP1_SUPPORTED | \
>> +					DRM_HDCP2_SUPPORTED | DRM_HDCP_WIP | \
>> +					DRM_HDCP_AUTH_FAILED | \
>> +					DRM_HDCP_LINK_INTEGRITY_FAILED | \
>> +					DRM_HDCP_REAUTH_REQUESTED)
>> +
>> +#endif	/* __DRM_HDCP_H__ */
>> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>> index 4298171..0c5bb90 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;
>>   	/**
>> +	 * @hdcp_property: Default connector property for HDCP
>> +	 * of a connector
>> +	 */
>> +	struct drm_property *hdcp_property;
>> +	/**
>>   	 * @plane_type_property: Default plane property to differentiate
>>   	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
>>   	 */
>> -- 
>> 2.7.4
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>

[-- Attachment #1.2: Type: text/html, Size: 10523 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Sean Paul]

On Wed, Jul 12, 2017 at 08:26:02PM +0530, Ramalingam C wrote:
> Daniel,
> 
> Thank you for reviewing the patch in short time. My views are below.
> 
> 
> On Wednesday 12 July 2017 03:24 PM, Daniel Vetter wrote:
> > On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote:
> > > DRM connector property is created as bitmask to receive
> > > HDCP enable/disable request along with content type.
> > > 
> > > And also there are Read only status bits for
> > > 	1. HDCP spec capability of the connector + panel
> > > 	2. HDCP encryption status of the connector

Hi Ram,
Thank you for posting this set! I'll do some code review in a separate
pass.


> > > 
> > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > ---
> > >   drivers/gpu/drm/drm_connector.c | 30 +++++++++++++++++++++
> > >   include/drm/drm_hdcp.h          | 58 +++++++++++++++++++++++++++++++++++++++++
> > >   include/drm/drm_mode_config.h   |  5 ++++
> > >   3 files changed, 93 insertions(+)
> > >   create mode 100644 include/drm/drm_hdcp.h
> > > 
> > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > > index 8072e6e..04f8cf8 100644
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -24,6 +24,7 @@
> > >   #include <drm/drm_connector.h>
> > >   #include <drm/drm_edid.h>
> > >   #include <drm/drm_encoder.h>
> > > +#include <drm/drm_hdcp.h>
> > >   #include "drm_crtc_internal.h"
> > >   #include "drm_internal.h"
> > > @@ -617,6 +618,28 @@ 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_hdcp_enum_list[] = {
> > > +	{ __builtin_ffs(DRM_HDCP_ENABLE) - 1,
> > > +					"Enable HDCP Encryption" },
> > > +	{ __builtin_ffs(DRM_HDCP_TYPE_BIT0) - 1,
> > > +					"HDCP Content type bit0" },
> > > +	{ __builtin_ffs(DRM_HDCP_TYPE_BIT1) - 1,
> > > +					"HDCP Content type bit1" },
> > > +	{ __builtin_ffs(DRM_HDCP1_SUPPORTED) - 1,
> > > +					"HDCP1.x Supported" },
> > > +	{ __builtin_ffs(DRM_HDCP2_SUPPORTED) - 1,
> > > +					"HDCP2.x Supported" },
> > > +	{ __builtin_ffs(DRM_HDCP_WIP) - 1,
> > > +					"HDCP work in progress" },
> > > +	{ __builtin_ffs(DRM_HDCP_AUTH_FAILED) - 1,
> > > +					"HDCP Authentication Failed" },
> > > +	{ __builtin_ffs(DRM_HDCP_LINK_INTEGRITY_FAILED) - 1,
> > > +					"HDCP Link Integrity Failed" },
> > > +	{ __builtin_ffs(DRM_HDCP_REAUTH_REQUESTED) - 1,
> > > +					"HDCP Reauthentication Requested" },
> > Why all these intermediate steps and different failure modes? Either hdcp
> > works, or it doesnt (and we can split up with the type 0 or type 1 if
> > needed), but I don't know what userspace would do with all the other
> > stuff?
> enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
> kobj-uevent
> for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
> configuration.
> 
> And without Type info it is not possible for HDCP2.2.

I've had requests from chrome team to expose HDCP version, so I don't think this
is too contentious.

Note that I've tried to use "content protection" instead of HDCP. My original
thinking was that since HDCP 1.x was broken, there was probably going to be
something else coming along. It's probably best to continue to keep the means of
protection vague, since you never know what will happen with HDCP 2.2 and what
will come after it.


> 
> But to inform whether both HDCP source and Sink support HDCP1.4/2.2/None I
> wanted to add
> the capability bits. These capability flags could be avoided if the presence
> of the drm_hdcp_property
> on connector, assures the corresponding HDCP version support on both HDCP
> src and sink.
> But for that we need a way to detach/alter the DRM_property of connector
> based on HDCP
> sink's hdcp version capability. Need to explore on that direction if that is
> allowed.

Meh, just change the content protection type to UNSUPPORTED or whatever.

> 
> Once HDCP protection is enabled link protection might break for many reasons
> including hot unplug. So Other Error
> flags are just to give more information to UMD on that scenario. But we can
> avoid them by setting the state
> as HDCP_DISABLE and notifying the UMD through Kobj-uevent for HDCP state
> change.

I can't think of a scenario where this info is worth exposing to userspace. We
can just log failures for debugging purposes and we'll be fine.

> 
> But one concern remains un-addressed that is compliance requirement will
> force us to reauthenticate
> in case of failures in authentication or on HDCP enabled link. In that
> scenario UMD has to be in formed that
> reauth is in progress. If UMD wants the port to be reenabled it has to wait
> for the completion of reauth else
> it has to place request for disabling the HDCP on port. We might want to add
> a enum value as HDCP_DISABLE_REAUTH.
> What is your opinion on this?

Let's worry about that if it actually becomes a problem. I don't anticipate
needing such fine grained controls.

> > 
> > This also doesn't seem to do the lockdown mode to force hdcp mode. And
> > afair it also doesn't match what CrOS currently uses, which means we don't
> > have userspace for this.
> AFAIK, Either way we don't have userspace for HDCP2.2 at present, as CrOS
> interface is designed for
> HDCP1.4(Need to cross check this with sean). But I will check with seanpaul
> if there is any plan for extending it for HDCP2.2 too.
> If so we could enable CrOS as consumer for HDCP2.2 against planned open
> source consumer from my side.
> 
> As discussed in cover letter I am starting on a UMD library
> which will be open sourced as a HDCP1.4 and 2.2 service provider for
> chromebox stack and Android.

I'm not sure this really justifies its own library. Or at least, I hope it
doesn't. All userspace should have to do is 3 things:

1- Tell kernel it wants content protection
2- Determine what method is being used for content protection
3- Determine if the display is protected at any given time

Chrome, Android (well, drm_hwc) already understand drm properties, so I'm not
sure how they would benefit from an additional layer of misdirection.

Sean


> 
> > 
> > I think the best approach would be if we simply try to upstream _exactly_
> > the property CrOS currently uses (not even bothering with type 0 vs type 1
> > if that's not required), since that is the currently only open source
> > userspace that asks for this.
> At first stage, as we are developing the HDCP2.2 support at DRM at first
> than HDCP1.4,
> we need to extend CrOS property for HDCP2.2 and then upstream. That will be
> the fruitful solution for us.
> 
> --Ram
> >   Going with a much more complicated or
> > different interface just because only risks a massive discussion and
> > subsequent long delays.
> > -Daniel
> > 
> > > +};
> > > +DRM_ENUM_NAME_FN(drm_get_hdcp_name, drm_hdcp_enum_list)
> > > +
> > >   /**
> > >    * drm_display_info_set_bus_formats - set the supported bus formats
> > >    * @info: display info to store bus formats in
> > > @@ -789,6 +812,13 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
> > >   		return -ENOMEM;
> > >   	dev->mode_config.link_status_property = prop;
> > > +	prop = drm_property_create_bitmask(dev, 0, "hdcp", drm_hdcp_enum_list,
> > > +					   ARRAY_SIZE(drm_hdcp_enum_list),
> > > +					   DRM_HDCP_PROP_SUPPORTED_BITS);
> > > +	if (!prop)
> > > +		return -ENOMEM;
> > > +	dev->mode_config.hdcp_property = prop;
> > > +
> > >   	return 0;
> > >   }
> > > diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> > > new file mode 100644
> > > index 0000000..7cebf0f
> > > --- /dev/null
> > > +++ b/include/drm/drm_hdcp.h
> > > @@ -0,0 +1,58 @@
> > > +/*
> > > + * Copyright (c) 2017 Intel Corporation
> > > + *
> > > + * Permission to use, copy, modify, distribute, and sell this software and its
> > > + * documentation for any purpose is hereby granted without fee, provided that
> > > + * the above copyright notice appear in all copies and that both that copyright
> > > + * notice and this permission notice appear in supporting documentation, and
> > > + * that the name of the copyright holders not be used in advertising or
> > > + * publicity pertaining to distribution of the software without specific,
> > > + * written prior permission.  The copyright holders make no representations
> > > + * about the suitability of this software for any purpose.  It is provided "as
> > > + * is" without express or implied warranty.
> > > + *
> > > + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
> > > + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> > > + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> > > + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
> > > + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> > > + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
> > > + * OF THIS SOFTWARE.
> > > + */
> > > +
> > > +/*
> > > + * Header for HDCP specific data
> > > + */
> > > +
> > > +#ifndef __DRM_HDCP_H__
> > > +#define __DRM_HDCP_H__
> > > +
> > > +/**
> > > + * HDCP property related information
> > > + */
> > > +/* RW: HDCP Encryption Requests and Status bits */
> > > +#define DRM_HDCP_ENABLE				BIT(0)
> > > +#define DRM_HDCP_TYPE_BIT0			BIT(4)
> > > +#define DRM_HDCP_TYPE_BIT1			BIT(5)
> > > +
> > > +/* RO: HDCP Version supported on Platform + panel */
> > > +#define DRM_HDCP1_SUPPORTED			BIT(12)
> > > +#define DRM_HDCP2_SUPPORTED			BIT(13)
> > > +
> > > +/* RO: Status of the requested operations */
> > > +#define DRM_HDCP_WIP				BIT(20)
> > > +#define DRM_HDCP_AUTH_FAILED			BIT(21)
> > > +
> > > +/* RO: Error Status From HDCP sink */
> > > +#define DRM_HDCP_LINK_INTEGRITY_FAILED		BIT(22)
> > > +#define DRM_HDCP_REAUTH_REQUESTED		BIT(23)
> > > +
> > > +#define DRM_HDCP_PROP_SUPPORTED_BITS	(DRM_HDCP_ENABLE | DRM_HDCP_TYPE_BIT0 \
> > > +					| DRM_HDCP_TYPE_BIT1 | \
> > > +					DRM_HDCP1_SUPPORTED | \
> > > +					DRM_HDCP2_SUPPORTED | DRM_HDCP_WIP | \
> > > +					DRM_HDCP_AUTH_FAILED | \
> > > +					DRM_HDCP_LINK_INTEGRITY_FAILED | \
> > > +					DRM_HDCP_REAUTH_REQUESTED)
> > > +
> > > +#endif	/* __DRM_HDCP_H__ */
> > > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > > index 4298171..0c5bb90 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;
> > >   	/**
> > > +	 * @hdcp_property: Default connector property for HDCP
> > > +	 * of a connector
> > > +	 */
> > > +	struct drm_property *hdcp_property;
> > > +	/**
> > >   	 * @plane_type_property: Default plane property to differentiate
> > >   	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
> > >   	 */
> > > -- 
> > > 2.7.4
> > > 
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 

> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <seanpaul@chromium.org> wrote:
>> > Why all these intermediate steps and different failure modes? Either hdcp
>> > works, or it doesnt (and we can split up with the type 0 or type 1 if
>> > needed), but I don't know what userspace would do with all the other
>> > stuff?
>> enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
>> kobj-uevent
>> for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
>> configuration.
>>
>> And without Type info it is not possible for HDCP2.2.
>
> I've had requests from chrome team to expose HDCP version, so I don't think this
> is too contentious.

I think it'd still be easier if we start out with the current content
protection props that CrOS is using, and then figure out how to layer
the exact version/standard on top? One thing at a time and all that.
-Daniel
-- 
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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

[-- Attachment #1.1: Type: text/plain, Size: 13428 bytes --]



On Thursday 13 July 2017 12:40 AM, Sean Paul wrote:
> On Wed, Jul 12, 2017 at 08:26:02PM +0530, Ramalingam C wrote:
>> Daniel,
>>
>> Thank you for reviewing the patch in short time. My views are below.
>>
>>
>> On Wednesday 12 July 2017 03:24 PM, Daniel Vetter wrote:
>>> On Wed, Jul 12, 2017 at 01:58:45PM +0530, Ramalingam C wrote:
>>>> DRM connector property is created as bitmask to receive
>>>> HDCP enable/disable request along with content type.
>>>>
>>>> And also there are Read only status bits for
>>>> 	1. HDCP spec capability of the connector + panel
>>>> 	2. HDCP encryption status of the connector
> Hi Ram,
> Thank you for posting this set! I'll do some code review in a separate
> pass.
Sean, Thank you for reviewing the code.
>
>
>>>> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
>>>> ---
>>>>    drivers/gpu/drm/drm_connector.c | 30 +++++++++++++++++++++
>>>>    include/drm/drm_hdcp.h          | 58 +++++++++++++++++++++++++++++++++++++++++
>>>>    include/drm/drm_mode_config.h   |  5 ++++
>>>>    3 files changed, 93 insertions(+)
>>>>    create mode 100644 include/drm/drm_hdcp.h
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>>>> index 8072e6e..04f8cf8 100644
>>>> --- a/drivers/gpu/drm/drm_connector.c
>>>> +++ b/drivers/gpu/drm/drm_connector.c
>>>> @@ -24,6 +24,7 @@
>>>>    #include <drm/drm_connector.h>
>>>>    #include <drm/drm_edid.h>
>>>>    #include <drm/drm_encoder.h>
>>>> +#include <drm/drm_hdcp.h>
>>>>    #include "drm_crtc_internal.h"
>>>>    #include "drm_internal.h"
>>>> @@ -617,6 +618,28 @@ 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_hdcp_enum_list[] = {
>>>> +	{ __builtin_ffs(DRM_HDCP_ENABLE) - 1,
>>>> +					"Enable HDCP Encryption" },
>>>> +	{ __builtin_ffs(DRM_HDCP_TYPE_BIT0) - 1,
>>>> +					"HDCP Content type bit0" },
>>>> +	{ __builtin_ffs(DRM_HDCP_TYPE_BIT1) - 1,
>>>> +					"HDCP Content type bit1" },
>>>> +	{ __builtin_ffs(DRM_HDCP1_SUPPORTED) - 1,
>>>> +					"HDCP1.x Supported" },
>>>> +	{ __builtin_ffs(DRM_HDCP2_SUPPORTED) - 1,
>>>> +					"HDCP2.x Supported" },
>>>> +	{ __builtin_ffs(DRM_HDCP_WIP) - 1,
>>>> +					"HDCP work in progress" },
>>>> +	{ __builtin_ffs(DRM_HDCP_AUTH_FAILED) - 1,
>>>> +					"HDCP Authentication Failed" },
>>>> +	{ __builtin_ffs(DRM_HDCP_LINK_INTEGRITY_FAILED) - 1,
>>>> +					"HDCP Link Integrity Failed" },
>>>> +	{ __builtin_ffs(DRM_HDCP_REAUTH_REQUESTED) - 1,
>>>> +					"HDCP Reauthentication Requested" },
>>> Why all these intermediate steps and different failure modes? Either hdcp
>>> works, or it doesnt (and we can split up with the type 0 or type 1 if
>>> needed), but I don't know what userspace would do with all the other
>>> stuff?
>> enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
>> kobj-uevent
>> for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
>> configuration.
>>
>> And without Type info it is not possible for HDCP2.2.
> I've had requests from chrome team to expose HDCP version, so I don't think this
> is too contentious.
Nice. So we could consider that we both need interface for HDCP1.4 and 
also HDCP2.2
>
> Note that I've tried to use "content protection" instead of HDCP. My original
> thinking was that since HDCP 1.x was broken, there was probably going to be
> something else coming along. It's probably best to continue to keep the means of
> protection vague, since you never know what will happen with HDCP 2.2 and what
> will come after it.
Sure that will help in long run. Even I will name it as CP instead of HDCP
>
>
>> But to inform whether both HDCP source and Sink support HDCP1.4/2.2/None I
>> wanted to add
>> the capability bits. These capability flags could be avoided if the presence
>> of the drm_hdcp_property
>> on connector, assures the corresponding HDCP version support on both HDCP
>> src and sink.
>> But for that we need a way to detach/alter the DRM_property of connector
>> based on HDCP
>> sink's hdcp version capability. Need to explore on that direction if that is
>> allowed.
> Meh, just change the content protection type to UNSUPPORTED or whatever.
Just thinking: In that case UNSUPPORTED will stand for not supporting 
any common HDCP ver
on the combination of HDCP src and sink?

In that case if HDCP src and sink combo doesn't support one of V1.4 and 
V2.2, then we wont
set the property state to UNSUPPORTED and
We will return error code -EINVAL for the request (atomic ioctl) of not 
supported version.
Does it sound good enough?
>
>> Once HDCP protection is enabled link protection might break for many reasons
>> including hot unplug. So Other Error
>> flags are just to give more information to UMD on that scenario. But we can
>> avoid them by setting the state
>> as HDCP_DISABLE and notifying the UMD through Kobj-uevent for HDCP state
>> change.
> I can't think of a scenario where this info is worth exposing to userspace. We
> can just log failures for debugging purposes and we'll be fine.
Agreed. I will remove those error bits.
>
>> But one concern remains un-addressed that is compliance requirement will
>> force us to reauthenticate
>> in case of failures in authentication or on HDCP enabled link. In that
>> scenario UMD has to be in formed that
>> reauth is in progress. If UMD wants the port to be reenabled it has to wait
>> for the completion of reauth else
>> it has to place request for disabling the HDCP on port. We might want to add
>> a enum value as HDCP_DISABLE_REAUTH.
>> What is your opinion on this?
> Let's worry about that if it actually becomes a problem. I don't anticipate
> needing such fine grained controls.
As a policy, i want to retain the port in unauthenticated state, unless 
UMD wants it otherwise.
This policy will save the frequent sanity check (poll of RxStatus reg) 
of authenticated HDCP
sink from KMD part.

So when the CP protection breaks on encrypted port, I want to keep UMD 
informed that port is
under reauth process. So that UMD can take a call on the desired CP 
state of the port.

If we agree on above policy, it will be good to address the above need 
of interface at this point in time.
>
>>> This also doesn't seem to do the lockdown mode to force hdcp mode. And
>>> afair it also doesn't match what CrOS currently uses, which means we don't
>>> have userspace for this.
>> AFAIK, Either way we don't have userspace for HDCP2.2 at present, as CrOS
>> interface is designed for
>> HDCP1.4(Need to cross check this with sean). But I will check with seanpaul
>> if there is any plan for extending it for HDCP2.2 too.
>> If so we could enable CrOS as consumer for HDCP2.2 against planned open
>> source consumer from my side.
>>
>> As discussed in cover letter I am starting on a UMD library
>> which will be open sourced as a HDCP1.4 and 2.2 service provider for
>> chromebox stack and Android.
> I'm not sure this really justifies its own library. Or at least, I hope it
> doesn't. All userspace should have to do is 3 things:
>
> 1- Tell kernel it wants content protection
> 2- Determine what method is being used for content protection
Yes it is indirect selection of HDCP version. Userspace decides the cp 
for which content type
and drm decides which version can do that and implements that.
> 3- Determine if the display is protected at any given time
Yes it has to continue monitoring the encrypted port too. As this is 
needed to prevent
the leakage of protected content on runtime encryption failed port.

This can be done in two ways
     1. through freq polling (min once in a Sec) on hdcp property.
     2. Broadcasting uevent from KMD on HDCP state change and monitor 
for it at UMD.
         This avoids the polling for sanity check and also for detecting 
request(EN/DIS able) completion.

I have opted for option 2, as that sounds better design. Please share 
your view on that too.
> Chrome, Android (well, drm_hwc) already understand drm properties, so I'm not
> sure how they would benefit from an additional layer of misdirection.
Benefit we are thinking of having a separate layer is maintainability. 
We can enhance the library for
future addition of HDCP versions by retaining the same interface hence 
not disturbing
any consumers (compositors).
>
> Sean
>
>
>>> I think the best approach would be if we simply try to upstream _exactly_
>>> the property CrOS currently uses (not even bothering with type 0 vs type 1
>>> if that's not required), since that is the currently only open source
>>> userspace that asks for this.
>> At first stage, as we are developing the HDCP2.2 support at DRM at first
>> than HDCP1.4,
>> we need to extend CrOS property for HDCP2.2 and then upstream. That will be
>> the fruitful solution for us.
>>
>> --Ram
>>>    Going with a much more complicated or
>>> different interface just because only risks a massive discussion and
>>> subsequent long delays.
>>> -Daniel
>>>
>>>> +};
>>>> +DRM_ENUM_NAME_FN(drm_get_hdcp_name, drm_hdcp_enum_list)
>>>> +
>>>>    /**
>>>>     * drm_display_info_set_bus_formats - set the supported bus formats
>>>>     * @info: display info to store bus formats in
>>>> @@ -789,6 +812,13 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
>>>>    		return -ENOMEM;
>>>>    	dev->mode_config.link_status_property = prop;
>>>> +	prop = drm_property_create_bitmask(dev, 0, "hdcp", drm_hdcp_enum_list,
>>>> +					   ARRAY_SIZE(drm_hdcp_enum_list),
>>>> +					   DRM_HDCP_PROP_SUPPORTED_BITS);
>>>> +	if (!prop)
>>>> +		return -ENOMEM;
>>>> +	dev->mode_config.hdcp_property = prop;
>>>> +
>>>>    	return 0;
>>>>    }
>>>> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
>>>> new file mode 100644
>>>> index 0000000..7cebf0f
>>>> --- /dev/null
>>>> +++ b/include/drm/drm_hdcp.h
>>>> @@ -0,0 +1,58 @@
>>>> +/*
>>>> + * Copyright (c) 2017 Intel Corporation
>>>> + *
>>>> + * Permission to use, copy, modify, distribute, and sell this software and its
>>>> + * documentation for any purpose is hereby granted without fee, provided that
>>>> + * the above copyright notice appear in all copies and that both that copyright
>>>> + * notice and this permission notice appear in supporting documentation, and
>>>> + * that the name of the copyright holders not be used in advertising or
>>>> + * publicity pertaining to distribution of the software without specific,
>>>> + * written prior permission.  The copyright holders make no representations
>>>> + * about the suitability of this software for any purpose.  It is provided "as
>>>> + * is" without express or implied warranty.
>>>> + *
>>>> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
>>>> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
>>>> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
>>>> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
>>>> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
>>>> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
>>>> + * OF THIS SOFTWARE.
>>>> + */
>>>> +
>>>> +/*
>>>> + * Header for HDCP specific data
>>>> + */
>>>> +
>>>> +#ifndef __DRM_HDCP_H__
>>>> +#define __DRM_HDCP_H__
>>>> +
>>>> +/**
>>>> + * HDCP property related information
>>>> + */
>>>> +/* RW: HDCP Encryption Requests and Status bits */
>>>> +#define DRM_HDCP_ENABLE				BIT(0)
>>>> +#define DRM_HDCP_TYPE_BIT0			BIT(4)
>>>> +#define DRM_HDCP_TYPE_BIT1			BIT(5)
>>>> +
>>>> +/* RO: HDCP Version supported on Platform + panel */
>>>> +#define DRM_HDCP1_SUPPORTED			BIT(12)
>>>> +#define DRM_HDCP2_SUPPORTED			BIT(13)
>>>> +
>>>> +/* RO: Status of the requested operations */
>>>> +#define DRM_HDCP_WIP				BIT(20)
>>>> +#define DRM_HDCP_AUTH_FAILED			BIT(21)
>>>> +
>>>> +/* RO: Error Status From HDCP sink */
>>>> +#define DRM_HDCP_LINK_INTEGRITY_FAILED		BIT(22)
>>>> +#define DRM_HDCP_REAUTH_REQUESTED		BIT(23)
>>>> +
>>>> +#define DRM_HDCP_PROP_SUPPORTED_BITS	(DRM_HDCP_ENABLE | DRM_HDCP_TYPE_BIT0 \
>>>> +					| DRM_HDCP_TYPE_BIT1 | \
>>>> +					DRM_HDCP1_SUPPORTED | \
>>>> +					DRM_HDCP2_SUPPORTED | DRM_HDCP_WIP | \
>>>> +					DRM_HDCP_AUTH_FAILED | \
>>>> +					DRM_HDCP_LINK_INTEGRITY_FAILED | \
>>>> +					DRM_HDCP_REAUTH_REQUESTED)
>>>> +
>>>> +#endif	/* __DRM_HDCP_H__ */
>>>> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>>>> index 4298171..0c5bb90 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;
>>>>    	/**
>>>> +	 * @hdcp_property: Default connector property for HDCP
>>>> +	 * of a connector
>>>> +	 */
>>>> +	struct drm_property *hdcp_property;
>>>> +	/**
>>>>    	 * @plane_type_property: Default plane property to differentiate
>>>>    	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
>>>>    	 */
>>>> -- 
>>>> 2.7.4
>>>>
>>>> _______________________________________________
>>>> Intel-gfx mailing list
>>>> Intel-gfx@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>


[-- Attachment #1.2: Type: text/html, Size: 17072 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

[-- Attachment #1.1: Type: text/plain, Size: 1254 bytes --]



On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:
> On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <seanpaul@chromium.org> wrote:
>>>> Why all these intermediate steps and different failure modes? Either hdcp
>>>> works, or it doesnt (and we can split up with the type 0 or type 1 if
>>>> needed), but I don't know what userspace would do with all the other
>>>> stuff?
>>> enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
>>> kobj-uevent
>>> for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
>>> configuration.
>>>
>>> And without Type info it is not possible for HDCP2.2.
>> I've had requests from chrome team to expose HDCP version, so I don't think this
>> is too contentious.
> I think it'd still be easier if we start out with the current content
> protection props that CrOS is using, and then figure out how to layer
> the exact version/standard on top? One thing at a time and all that.
> -Daniel
I understand the approach.

But Only problem is current upstreaming effort is for HDCP2.2 support at 
DRM with a design which can
easily accommodate other versions too. So we  need to stretch current 
CrOS property a bit with
ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all.

--Ram


[-- Attachment #1.2: Type: text/html, Size: 2220 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C <ramalingam.c@intel.com> wrote:
> On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:
>
> On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <seanpaul@chromium.org> wrote:
>
> Why all these intermediate steps and different failure modes? Either hdcp
> works, or it doesnt (and we can split up with the type 0 or type 1 if
> needed), but I don't know what userspace would do with all the other
> stuff?
>
> enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
> kobj-uevent
> for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
> configuration.
>
> And without Type info it is not possible for HDCP2.2.
>
> I've had requests from chrome team to expose HDCP version, so I don't think
> this
> is too contentious.
>
> I think it'd still be easier if we start out with the current content
> protection props that CrOS is using, and then figure out how to layer
> the exact version/standard on top? One thing at a time and all that.
> -Daniel
>
> I understand the approach.
>
> But Only problem is current upstreaming effort is for HDCP2.2 support at DRM
> with a design which can
> easily accommodate other versions too. So we  need to stretch current CrOS
> property a bit with
> ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all.

Yeah, but if we just go with enable (without specifying the type) we
could still enable the highest hdcp level (so 2.2 for our case). At
least I don't see a reason why we need to already have the
enable_type1 thing. Can you pls explain why you think this is
necessary?

There seems to be a need to force type1, but I think it's easier to do
that as an extension. Of course we need to keep it in mind meanwhile.
-Daniel
-- 
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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

[-- Attachment #1.1: Type: text/plain, Size: 3292 bytes --]



On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote:
> On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C <ramalingam.c@intel.com> wrote:
>> On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:
>>
>> On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <seanpaul@chromium.org> wrote:
>>
>> Why all these intermediate steps and different failure modes? Either hdcp
>> works, or it doesnt (and we can split up with the type 0 or type 1 if
>> needed), but I don't know what userspace would do with all the other
>> stuff?
>>
>> enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
>> kobj-uevent
>> for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
>> configuration.
>>
>> And without Type info it is not possible for HDCP2.2.
>>
>> I've had requests from chrome team to expose HDCP version, so I don't think
>> this
>> is too contentious.
>>
>> I think it'd still be easier if we start out with the current content
>> protection props that CrOS is using, and then figure out how to layer
>> the exact version/standard on top? One thing at a time and all that.
>> -Daniel
>>
>> I understand the approach.
>>
>> But Only problem is current upstreaming effort is for HDCP2.2 support at DRM
>> with a design which can
>> easily accommodate other versions too. So we  need to stretch current CrOS
>> property a bit with
>> ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all.
> Yeah, but if we just go with enable (without specifying the type) we
> could still enable the highest hdcp level (so 2.2 for our case). At
> least I don't see a reason why we need to already have the
> enable_type1 thing. Can you pls explain why you think this is
> necessary?
>
> There seems to be a need to force type1, but I think it's easier to do
> that as an extension. Of course we need to keep it in mind meanwhile.
Background for this need of Type info in HDCP2.2 implementation is as 
follows:

HDCP2.2 Spec classify the protected content as Type 0 and Type 1. For 
Example lets say
- A HDCP2.2 Src is connected to HDCP repeater
- that repeater is connected to a HDCP2.2 panel
- that same repeater is also connected to a HDCP1.4 panel.

In this topology, as part of Repeater authentication:
- HDCP2.2 Source will mention the Content Type to HDCP2.2 Repeater
- Repeater can transmit this Type 1 content to HDCP2.2 compliant sink 
only (which is HDCP 2.2 panel here).
- Repeater can transmit any type0 content to any other devices (like 
HDCP1.4 panel here).
- Device with no HDCP support will get Neither of Type 0 or Type 1.

So if we implement HDCP2.2 with HDCP_ENABLE state alone there is no way 
for Userspace
to request for HDCP2.2 protection only. In this case we wont know the 
content type classification.

Even if we force Content type to Type1, in above topology Type 0 content 
that could be rendered to
HDCP1.4 compliant panel wont be rendered as that has been forcibly 
classified as Type 1 by KMD.

Forcing type 1 content to Type 0 will break the association of type1 
content to HDCP2.2 devices only.

More than that Devices with our indented DRM HDCP2.2 support wont pass 
the HDCP2.2 compliance.
Considering we could extend the CrOS Userspace for HDCP2.2, I would 
prefer to go ahead with
HDCP_ENABLE_TYPE1 along with HDCP_ENABLE.

--Ram
> -Daniel


[-- Attachment #1.2: Type: text/html, Size: 4390 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C <ramalingam.c@intel.com> wrote:
>
>
> On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote:
>
> On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C <ramalingam.c@intel.com>
> wrote:
>
> On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:
>
> On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <seanpaul@chromium.org> wrote:
>
> Why all these intermediate steps and different failure modes? Either hdcp
> works, or it doesnt (and we can split up with the type 0 or type 1 if
> needed), but I don't know what userspace would do with all the other
> stuff?
>
> enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
> kobj-uevent
> for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
> configuration.
>
> And without Type info it is not possible for HDCP2.2.
>
> I've had requests from chrome team to expose HDCP version, so I don't think
> this
> is too contentious.
>
> I think it'd still be easier if we start out with the current content
> protection props that CrOS is using, and then figure out how to layer
> the exact version/standard on top? One thing at a time and all that.
> -Daniel
>
> I understand the approach.
>
> But Only problem is current upstreaming effort is for HDCP2.2 support at DRM
> with a design which can
> easily accommodate other versions too. So we  need to stretch current CrOS
> property a bit with
> ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all.
>
> Yeah, but if we just go with enable (without specifying the type) we
> could still enable the highest hdcp level (so 2.2 for our case). At
> least I don't see a reason why we need to already have the
> enable_type1 thing. Can you pls explain why you think this is
> necessary?
>
> There seems to be a need to force type1, but I think it's easier to do
> that as an extension. Of course we need to keep it in mind meanwhile.
>
> Background for this need of Type info in HDCP2.2 implementation is as
> follows:

Aside: You're quoting is broken for inline quoting. Either fix the
quoting or top-quote (there's no difference between your text and
mine, mine should be indented with > or | or similar).

> HDCP2.2 Spec classify the protected content as Type 0 and Type 1. For
> Example lets say
> - A HDCP2.2 Src is connected to HDCP repeater
> - that repeater is connected to a HDCP2.2 panel
> - that same repeater is also connected to a HDCP1.4 panel.
>
> In this topology, as part of Repeater authentication:
> - HDCP2.2 Source will mention the Content Type to HDCP2.2 Repeater
> - Repeater can transmit this Type 1 content to HDCP2.2 compliant sink only
> (which is HDCP 2.2 panel here).
> - Repeater can transmit any type0 content to any other devices (like HDCP1.4
> panel here).
> - Device with no HDCP support will get Neither of Type 0 or Type 1.
>
> So if we implement HDCP2.2 with HDCP_ENABLE state alone there is no way for
> Userspace
> to request for HDCP2.2 protection only. In this case we wont know the
> content type classification.

Yes, that is the case, but also the point of gradual enabling. Atm
(with the current CrOS usersapce) userspace can ask for "pls give me
content protection, I don't care what level/type". That itself is
already useful, and a good step forward. Allowing to ask for a
specific type is something on top.

> Even if we force Content type to Type1, in above topology Type 0 content
> that could be rendered to
> HDCP1.4 compliant panel wont be rendered as that has been forcibly
> classified as Type 1 by KMD.

Why? HDCP_ENABLE would just give you the "best" HDCP, so we'd fall
back to type 0 (if that's available).

> Forcing type 1 content to Type 0 will break the association of type1 content
> to HDCP2.2 devices only.

I didn't propose to force type1 everywhere. Why do you think this is needed.

> More than that Devices with our indented DRM HDCP2.2 support wont pass the
> HDCP2.2 compliance.
> Considering we could extend the CrOS Userspace for HDCP2.2, I would prefer
> to go ahead with
> HDCP_ENABLE_TYPE1 along with HDCP_ENABLE.

Yes, it's only hdcp1.4, and getting to full hdcp2.2 will take more
work. You can do all of that in one go, but my experience with
upstreaming new uabi is that usually that's not the most effective way
to go about things. But in the end, that's your choice.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

[-- Attachment #1.1: Type: text/plain, Size: 5173 bytes --]



On Thursday 13 July 2017 04:06 PM, Daniel Vetter wrote:
> On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C <ramalingam.c@intel.com> wrote:
>>
>> On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote:
>>
>> On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C <ramalingam.c@intel.com>
>> wrote:
>>
>> On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:
>>
>> On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <seanpaul@chromium.org> wrote:
>>
>> Why all these intermediate steps and different failure modes? Either hdcp
>> works, or it doesnt (and we can split up with the type 0 or type 1 if
>> needed), but I don't know what userspace would do with all the other
>> stuff?
>>
>> enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
>> kobj-uevent
>> for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
>> configuration.
>>
>> And without Type info it is not possible for HDCP2.2.
>>
>> I've had requests from chrome team to expose HDCP version, so I don't think
>> this
>> is too contentious.
>>
>> I think it'd still be easier if we start out with the current content
>> protection props that CrOS is using, and then figure out how to layer
>> the exact version/standard on top? One thing at a time and all that.
>> -Daniel
>>
>> I understand the approach.
>>
>> But Only problem is current upstreaming effort is for HDCP2.2 support at DRM
>> with a design which can
>> easily accommodate other versions too. So we  need to stretch current CrOS
>> property a bit with
>> ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all.
>>
>> Yeah, but if we just go with enable (without specifying the type) we
>> could still enable the highest hdcp level (so 2.2 for our case). At
>> least I don't see a reason why we need to already have the
>> enable_type1 thing. Can you pls explain why you think this is
>> necessary?
>>
>> There seems to be a need to force type1, but I think it's easier to do
>> that as an extension. Of course we need to keep it in mind meanwhile.
>>
>> Background for this need of Type info in HDCP2.2 implementation is as
>> follows:
> Aside: You're quoting is broken for inline quoting. Either fix the
> quoting or top-quote (there's no difference between your text and
> mine, mine should be indented with > or | or similar).
Sorry for the inconvenience. Hope now it is fine. Just reset the 
settings on thunderbird
>
>> HDCP2.2 Spec classify the protected content as Type 0 and Type 1. For
>> Example lets say
>> - A HDCP2.2 Src is connected to HDCP repeater
>> - that repeater is connected to a HDCP2.2 panel
>> - that same repeater is also connected to a HDCP1.4 panel.
>>
>> In this topology, as part of Repeater authentication:
>> - HDCP2.2 Source will mention the Content Type to HDCP2.2 Repeater
>> - Repeater can transmit this Type 1 content to HDCP2.2 compliant sink only
>> (which is HDCP 2.2 panel here).
>> - Repeater can transmit any type0 content to any other devices (like HDCP1.4
>> panel here).
>> - Device with no HDCP support will get Neither of Type 0 or Type 1.
>>
>> So if we implement HDCP2.2 with HDCP_ENABLE state alone there is no way for
>> Userspace
>> to request for HDCP2.2 protection only. In this case we wont know the
>> content type classification.
> Yes, that is the case, but also the point of gradual enabling. Atm
> (with the current CrOS usersapce) userspace can ask for "pls give me
> content protection, I don't care what level/type". That itself is
> already useful, and a good step forward. Allowing to ask for a
> specific type is something on top.
Ok. When i think over it, that sounds as a  good idea to go gradually 
for enabling HDCP2.2.
>
>> Even if we force Content type to Type1, in above topology Type 0 content
>> that could be rendered to
>> HDCP1.4 compliant panel wont be rendered as that has been forcibly
>> classified as Type 1 by KMD.
> Why? HDCP_ENABLE would just give you the "best" HDCP, so we'd fall
> back to type 0 (if that's available).
I think i misinterpreted. We could enable the HDCP2.2(if supported on 
panel) for the Type 0 content. No issue on that
>> Forcing type 1 content to Type 0 will break the association of type1 content
>> to HDCP2.2 devices only.
> I didn't propose to force type1 everywhere. Why do you think this is needed.

>> More than that Devices with our indented DRM HDCP2.2 support wont pass the
>> HDCP2.2 compliance.
>> Considering we could extend the CrOS Userspace for HDCP2.2, I would prefer
>> to go ahead with
>> HDCP_ENABLE_TYPE1 along with HDCP_ENABLE.
> Yes, it's only hdcp1.4, and getting to full hdcp2.2 will take more
> work. You can do all of that in one go, but my experience with
> upstreaming new uabi is that usually that's not the most effective way
> to go about things. But in the end, that's your choice.
Agreed. We will go gradually about enabling HDCP2.2.
     1. Enable HDCP2.2 for HDCP_ENABLE with Content type as 0.
     2. Enable HDCP2.2 for Type 1 content with Enum value HDCP_ENABLE_TYPE1
     3. Making HDCP2.2 support as HDCP2.2 spec compliant.

But I think i will just add another enum value HDCP_UNSUPPORTED to mark 
the no HDCP supported on the setup.
I hope that is fine.
> -Daniel


[-- Attachment #1.2: Type: text/html, Size: 7064 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Daniel Vetter]

On Thu, Jul 13, 2017 at 06:29:33PM +0530, Ramalingam C wrote:
> 
> 
> On Thursday 13 July 2017 04:06 PM, Daniel Vetter wrote:
> > On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C <ramalingam.c@intel.com> wrote:
> > > 
> > > On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote:
> > > 
> > > On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C <ramalingam.c@intel.com>
> > > wrote:
> > > 
> > > On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:
> > > 
> > > On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <seanpaul@chromium.org> wrote:
> > > 
> > > Why all these intermediate steps and different failure modes? Either hdcp
> > > works, or it doesnt (and we can split up with the type 0 or type 1 if
> > > needed), but I don't know what userspace would do with all the other
> > > stuff?
> > > 
> > > enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
> > > kobj-uevent
> > > for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
> > > configuration.
> > > 
> > > And without Type info it is not possible for HDCP2.2.
> > > 
> > > I've had requests from chrome team to expose HDCP version, so I don't think
> > > this
> > > is too contentious.
> > > 
> > > I think it'd still be easier if we start out with the current content
> > > protection props that CrOS is using, and then figure out how to layer
> > > the exact version/standard on top? One thing at a time and all that.
> > > -Daniel
> > > 
> > > I understand the approach.
> > > 
> > > But Only problem is current upstreaming effort is for HDCP2.2 support at DRM
> > > with a design which can
> > > easily accommodate other versions too. So we  need to stretch current CrOS
> > > property a bit with
> > > ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all.
> > > 
> > > Yeah, but if we just go with enable (without specifying the type) we
> > > could still enable the highest hdcp level (so 2.2 for our case). At
> > > least I don't see a reason why we need to already have the
> > > enable_type1 thing. Can you pls explain why you think this is
> > > necessary?
> > > 
> > > There seems to be a need to force type1, but I think it's easier to do
> > > that as an extension. Of course we need to keep it in mind meanwhile.
> > > 
> > > Background for this need of Type info in HDCP2.2 implementation is as
> > > follows:
> > Aside: You're quoting is broken for inline quoting. Either fix the
> > quoting or top-quote (there's no difference between your text and
> > mine, mine should be indented with > or | or similar).
> Sorry for the inconvenience. Hope now it is fine. Just reset the settings on
> thunderbird

Yes, looks good now.

> > 
> > > HDCP2.2 Spec classify the protected content as Type 0 and Type 1. For
> > > Example lets say
> > > - A HDCP2.2 Src is connected to HDCP repeater
> > > - that repeater is connected to a HDCP2.2 panel
> > > - that same repeater is also connected to a HDCP1.4 panel.
> > > 
> > > In this topology, as part of Repeater authentication:
> > > - HDCP2.2 Source will mention the Content Type to HDCP2.2 Repeater
> > > - Repeater can transmit this Type 1 content to HDCP2.2 compliant sink only
> > > (which is HDCP 2.2 panel here).
> > > - Repeater can transmit any type0 content to any other devices (like HDCP1.4
> > > panel here).
> > > - Device with no HDCP support will get Neither of Type 0 or Type 1.
> > > 
> > > So if we implement HDCP2.2 with HDCP_ENABLE state alone there is no way for
> > > Userspace
> > > to request for HDCP2.2 protection only. In this case we wont know the
> > > content type classification.
> > Yes, that is the case, but also the point of gradual enabling. Atm
> > (with the current CrOS usersapce) userspace can ask for "pls give me
> > content protection, I don't care what level/type". That itself is
> > already useful, and a good step forward. Allowing to ask for a
> > specific type is something on top.
> Ok. When i think over it, that sounds as a  good idea to go gradually for
> enabling HDCP2.2.
> > 
> > > Even if we force Content type to Type1, in above topology Type 0 content
> > > that could be rendered to
> > > HDCP1.4 compliant panel wont be rendered as that has been forcibly
> > > classified as Type 1 by KMD.
> > Why? HDCP_ENABLE would just give you the "best" HDCP, so we'd fall
> > back to type 0 (if that's available).
> I think i misinterpreted. We could enable the HDCP2.2(if supported on panel)
> for the Type 0 content. No issue on that
> > > Forcing type 1 content to Type 0 will break the association of type1 content
> > > to HDCP2.2 devices only.
> > I didn't propose to force type1 everywhere. Why do you think this is needed.
> 
> > > More than that Devices with our indented DRM HDCP2.2 support wont pass the
> > > HDCP2.2 compliance.
> > > Considering we could extend the CrOS Userspace for HDCP2.2, I would prefer
> > > to go ahead with
> > > HDCP_ENABLE_TYPE1 along with HDCP_ENABLE.
> > Yes, it's only hdcp1.4, and getting to full hdcp2.2 will take more
> > work. You can do all of that in one go, but my experience with
> > upstreaming new uabi is that usually that's not the most effective way
> > to go about things. But in the end, that's your choice.
> Agreed. We will go gradually about enabling HDCP2.2.
>     1. Enable HDCP2.2 for HDCP_ENABLE with Content type as 0.
>     2. Enable HDCP2.2 for Type 1 content with Enum value HDCP_ENABLE_TYPE1
>     3. Making HDCP2.2 support as HDCP2.2 spec compliant.
> 
> But I think i will just add another enum value HDCP_UNSUPPORTED to mark the
> no HDCP supported on the setup.
> I hope that is fine.

Makes sense.

btw I chatted with Shashi today, I think it'd be good if we could have a
chat next week about some of the design patterns for the implementation. I
can give you some pointers for kernel best practices (so you understand
why things are done a bit different).

But I think first priority is to get agreement on the new uapi and make
sure it works for CrOS, we can polish the implementation in following
rounds.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

[Ramalingam C]

On Friday 14 July 2017 12:32 AM, Daniel Vetter wrote:
> On Thu, Jul 13, 2017 at 06:29:33PM +0530, Ramalingam C wrote:
>>
>> On Thursday 13 July 2017 04:06 PM, Daniel Vetter wrote:
>>> On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C <ramalingam.c@intel.com> wrote:
>>>> On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote:
>>>>
>>>> On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C <ramalingam.c@intel.com>
>>>> wrote:
>>>>
>>>> On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:
>>>>
>>>> On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <seanpaul@chromium.org> wrote:
>>>>
>>>> Why all these intermediate steps and different failure modes? Either hdcp
>>>> works, or it doesnt (and we can split up with the type 0 or type 1 if
>>>> needed), but I don't know what userspace would do with all the other
>>>> stuff?
>>>>
>>>> enum values  HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with
>>>> kobj-uevent
>>>> for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2
>>>> configuration.
>>>>
>>>> And without Type info it is not possible for HDCP2.2.
>>>>
>>>> I've had requests from chrome team to expose HDCP version, so I don't think
>>>> this
>>>> is too contentious.
>>>>
>>>> I think it'd still be easier if we start out with the current content
>>>> protection props that CrOS is using, and then figure out how to layer
>>>> the exact version/standard on top? One thing at a time and all that.
>>>> -Daniel
>>>>
>>>> I understand the approach.
>>>>
>>>> But Only problem is current upstreaming effort is for HDCP2.2 support at DRM
>>>> with a design which can
>>>> easily accommodate other versions too. So we  need to stretch current CrOS
>>>> property a bit with
>>>> ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all.
>>>>
>>>> Yeah, but if we just go with enable (without specifying the type) we
>>>> could still enable the highest hdcp level (so 2.2 for our case). At
>>>> least I don't see a reason why we need to already have the
>>>> enable_type1 thing. Can you pls explain why you think this is
>>>> necessary?
>>>>
>>>> There seems to be a need to force type1, but I think it's easier to do
>>>> that as an extension. Of course we need to keep it in mind meanwhile.
>>>>
>>>> Background for this need of Type info in HDCP2.2 implementation is as
>>>> follows:
>>> Aside: You're quoting is broken for inline quoting. Either fix the
>>> quoting or top-quote (there's no difference between your text and
>>> mine, mine should be indented with > or | or similar).
>> Sorry for the inconvenience. Hope now it is fine. Just reset the settings on
>> thunderbird
> Yes, looks good now.
>
>>>> HDCP2.2 Spec classify the protected content as Type 0 and Type 1. For
>>>> Example lets say
>>>> - A HDCP2.2 Src is connected to HDCP repeater
>>>> - that repeater is connected to a HDCP2.2 panel
>>>> - that same repeater is also connected to a HDCP1.4 panel.
>>>>
>>>> In this topology, as part of Repeater authentication:
>>>> - HDCP2.2 Source will mention the Content Type to HDCP2.2 Repeater
>>>> - Repeater can transmit this Type 1 content to HDCP2.2 compliant sink only
>>>> (which is HDCP 2.2 panel here).
>>>> - Repeater can transmit any type0 content to any other devices (like HDCP1.4
>>>> panel here).
>>>> - Device with no HDCP support will get Neither of Type 0 or Type 1.
>>>>
>>>> So if we implement HDCP2.2 with HDCP_ENABLE state alone there is no way for
>>>> Userspace
>>>> to request for HDCP2.2 protection only. In this case we wont know the
>>>> content type classification.
>>> Yes, that is the case, but also the point of gradual enabling. Atm
>>> (with the current CrOS usersapce) userspace can ask for "pls give me
>>> content protection, I don't care what level/type". That itself is
>>> already useful, and a good step forward. Allowing to ask for a
>>> specific type is something on top.
>> Ok. When i think over it, that sounds as a  good idea to go gradually for
>> enabling HDCP2.2.
>>>> Even if we force Content type to Type1, in above topology Type 0 content
>>>> that could be rendered to
>>>> HDCP1.4 compliant panel wont be rendered as that has been forcibly
>>>> classified as Type 1 by KMD.
>>> Why? HDCP_ENABLE would just give you the "best" HDCP, so we'd fall
>>> back to type 0 (if that's available).
>> I think i misinterpreted. We could enable the HDCP2.2(if supported on panel)
>> for the Type 0 content. No issue on that
>>>> Forcing type 1 content to Type 0 will break the association of type1 content
>>>> to HDCP2.2 devices only.
>>> I didn't propose to force type1 everywhere. Why do you think this is needed.
>>>> More than that Devices with our indented DRM HDCP2.2 support wont pass the
>>>> HDCP2.2 compliance.
>>>> Considering we could extend the CrOS Userspace for HDCP2.2, I would prefer
>>>> to go ahead with
>>>> HDCP_ENABLE_TYPE1 along with HDCP_ENABLE.
>>> Yes, it's only hdcp1.4, and getting to full hdcp2.2 will take more
>>> work. You can do all of that in one go, but my experience with
>>> upstreaming new uabi is that usually that's not the most effective way
>>> to go about things. But in the end, that's your choice.
>> Agreed. We will go gradually about enabling HDCP2.2.
>>      1. Enable HDCP2.2 for HDCP_ENABLE with Content type as 0.
>>      2. Enable HDCP2.2 for Type 1 content with Enum value HDCP_ENABLE_TYPE1
>>      3. Making HDCP2.2 support as HDCP2.2 spec compliant.
>>
>> But I think i will just add another enum value HDCP_UNSUPPORTED to mark the
>> no HDCP supported on the setup.
>> I hope that is fine.
> Makes sense.
>
> btw I chatted with Shashi today, I think it'd be good if we could have a
> chat next week about some of the design patterns for the implementation. I
> can give you some pointers for kernel best practices (so you understand
> why things are done a bit different).
>
> But I think first priority is to get agreement on the new uapi and make
> sure it works for CrOS, we can polish the implementation in following
> rounds.
>
> Thanks, Daniel
Sure daniel. Now I have prepared v2 of this patch alone. Please have 
review that too.
Based on feedbacks I will spin other patches of this series.

--Ram

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

[RFC v2] drm/hdcp: drm enum property for HDCP State

[Ramalingam C]

DRM connector property is created to represent the content protection
state of the connector and to configure the same.

CP States defined:
	DRM_CP_UNSUPPORTED 	- CP is not supported
	DRM_CP_DISABLE		- CP is disabled
	DRM_CP_ENABLE		- CP is enabled

V2: Redesigned the property to match with CP needs of CrOS.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
 drivers/gpu/drm/drm_connector.c | 14 +++++++++++++
 include/drm/drm_hdcp.h          | 44 +++++++++++++++++++++++++++++++++++++++++
 include/drm/drm_mode_config.h   |  5 +++++
 3 files changed, 63 insertions(+)
 create mode 100644 include/drm/drm_hdcp.h

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5cd61af..64895fb 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -24,6 +24,7 @@
 #include <drm/drm_connector.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_encoder.h>
+#include <drm/drm_hdcp.h>
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -617,6 +618,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_CP_UNSUPPORTED,	"CP Not Supported" },
+	{ DRM_CP_DISABLE,	"Disable CP" },
+	{ DRM_CP_ENABLE,	"Enable CP for Type0 content" },
+};
+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
@@ -789,6 +797,12 @@ 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, "cp", 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_hdcp.h b/include/drm/drm_hdcp.h
new file mode 100644
index 0000000..f6d0160
--- /dev/null
+++ b/include/drm/drm_hdcp.h
@@ -0,0 +1,44 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+/*
+ * Header for HDCP specific data
+ */
+
+#ifndef __DRM_HDCP_H__
+#define __DRM_HDCP_H__
+
+/**
+ * CP property related information
+ */
+enum drm_cp_state {
+
+	/* HDCP sink and Src dont have any common HDCP ver supported */
+	DRM_CP_UNSUPPORTED,
+
+	/* Disable Content Protection */
+	DRM_CP_DISABLE,
+
+	/* Enable Content Protection */
+	DRM_CP_ENABLE,
+};
+#endif	/* __DRM_HDCP_H__ */
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 4298171..7acb8b2 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 CP
+	 * of a connector
+	 */
+	struct drm_property *cp_property;
+	/**
 	 * @plane_type_property: Default plane property to differentiate
 	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
 	 */
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

✗ Fi.CI.BAT: failure for DRM Interfaces for HDCP support (rev2)

[Patchwork]

== Series Details ==

Series: DRM Interfaces for HDCP support (rev2)
URL   : https://patchwork.freedesktop.org/series/27170/
State : failure

== Summary ==

  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CHK     include/generated/bounds.h
  CHK     include/generated/timeconst.h
  CHK     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CHK     scripts/mod/devicetable-offsets.h
  CHK     include/generated/compile.h
  CHK     kernel/config_data.h
  CC      drivers/gpu/drm/drm_crtc_helper.o
In file included from ./include/drm/drm_connector.h:30:0,
                 from ./include/drm/drm_modes.h:33,
                 from ./include/drm/drm_crtc.h:40,
                 from ./include/drm/drmP.h:69,
                 from drivers/gpu/drm/drm_crtc_helper.c:36:
./include/drm/drm_hdcp.h:137:1: error: expected identifier before ‘<<’ token
 <<<<<<< 13cfd1763bd86210733b05319007d9f80b2280fe
 ^
./include/drm/drm_hdcp.h:137:9: error: invalid suffix "cfd1763bd86210733b05319007d9f80b2280fe" on integer constant
 <<<<<<< 13cfd1763bd86210733b05319007d9f80b2280fe
         ^
./include/drm/drm_hdcp.h:147:1: error: expected identifier or ‘(’ before ‘==’ token
 =======
 ^
./include/drm/drm_hdcp.h:152:1: error: expected identifier or ‘(’ before ‘>>’ token
 >>>>>>> drm/hdcp: Initialization of DRM hdcp stack
 ^
scripts/Makefile.build:302: recipe for target 'drivers/gpu/drm/drm_crtc_helper.o' failed
make[3]: *** [drivers/gpu/drm/drm_crtc_helper.o] Error 1
scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1016: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

Re: [RFC v2] drm/hdcp: drm enum property for HDCP State

[Sean Paul]

On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
> DRM connector property is created to represent the content protection
> state of the connector and to configure the same.
> 
> CP States defined:
> 	DRM_CP_UNSUPPORTED 	- CP is not supported
> 	DRM_CP_DISABLE		- CP is disabled
> 	DRM_CP_ENABLE		- CP is enabled

Why are we changing the names from the original version (that's used in CrOS)? It's not
obvious what "CP" stands for when looking at the name.

> 
> V2: Redesigned the property to match with CP needs of CrOS.
> 
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> ---
>  drivers/gpu/drm/drm_connector.c | 14 +++++++++++++
>  include/drm/drm_hdcp.h          | 44 +++++++++++++++++++++++++++++++++++++++++
>  include/drm/drm_mode_config.h   |  5 +++++
>  3 files changed, 63 insertions(+)
>  create mode 100644 include/drm/drm_hdcp.h
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 5cd61af..64895fb 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -24,6 +24,7 @@
>  #include <drm/drm_connector.h>
>  #include <drm/drm_edid.h>
>  #include <drm/drm_encoder.h>
> +#include <drm/drm_hdcp.h>
>  
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> @@ -617,6 +618,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_CP_UNSUPPORTED,	"CP Not Supported" },
> +	{ DRM_CP_DISABLE,	"Disable CP" },
> +	{ DRM_CP_ENABLE,	"Enable CP for Type0 content" },

Type0 has no meaning in this case. The whole point of using "Content Protection"
is to abstract the means of protection from userspace. The names are also much
more verbose than they need be. "Unsupported", "Disabled", "Enabled" are fine.


> +};
> +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
> @@ -789,6 +797,12 @@ 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, "cp", drm_cp_enum_list,
> +					   ARRAY_SIZE(drm_cp_enum_list));

Your property name here, on the other hand, is not descriptive enough. Please
expand to something meaningful.

> +	if (!prop)
> +		return -ENOMEM;
> +	dev->mode_config.cp_property = prop;
> +
>  	return 0;
>  }
>  
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h

Why create a new header for this? That seems a little excessive.

Sean

> new file mode 100644
> index 0000000..f6d0160
> --- /dev/null
> +++ b/include/drm/drm_hdcp.h
> @@ -0,0 +1,44 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission.  The copyright holders make no representations
> + * about the suitability of this software for any purpose.  It is provided "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
> + * OF THIS SOFTWARE.
> + */
> +
> +/*
> + * Header for HDCP specific data
> + */
> +
> +#ifndef __DRM_HDCP_H__
> +#define __DRM_HDCP_H__
> +
> +/**
> + * CP property related information
> + */
> +enum drm_cp_state {
> +
> +	/* HDCP sink and Src dont have any common HDCP ver supported */
> +	DRM_CP_UNSUPPORTED,
> +
> +	/* Disable Content Protection */
> +	DRM_CP_DISABLE,
> +
> +	/* Enable Content Protection */
> +	DRM_CP_ENABLE,
> +};
> +#endif	/* __DRM_HDCP_H__ */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 4298171..7acb8b2 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 CP
> +	 * of a connector
> +	 */
> +	struct drm_property *cp_property;
> +	/**
>  	 * @plane_type_property: Default plane property to differentiate
>  	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
>  	 */
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2] drm/hdcp: drm enum property for HDCP State

[Ramalingam C]

[-- Attachment #1.1: Type: text/plain, Size: 6799 bytes --]

Sorry for late response.


On Friday 14 July 2017 07:25 PM, Sean Paul wrote:
> On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
>> DRM connector property is created to represent the content protection
>> state of the connector and to configure the same.
>>
>> CP States defined:
>> 	DRM_CP_UNSUPPORTED 	- CP is not supported
>> 	DRM_CP_DISABLE		- CP is disabled
>> 	DRM_CP_ENABLE		- CP is enabled
> Why are we changing the names from the original version (that's used in CrOS)? It's not
> obvious what "CP" stands for when looking at the name.
Sean,

Considering that we want to test this interface for CrOS stack as a 
consumer, I will try to align the property names.
Meanwhile got few questions with respect to designing this CP interface 
aligned with existing CrOS stack.

I want to understand what all are the bare minimal content protection 
interface required for existing CrOS Userspace stack.
Whether this drm enum property will be sufficient for CrOS Content 
protection needs of HDCP1.4.?
Could you please help me on that direction?

When i refer your RFC at 
https://lists.freedesktop.org/archives/dri-devel/2014-December/073418.html
there is a drm range property called  "Content Protection KSV", claimed 
to stand for content protection state.
Is this used by current CrOS userspace stack?

As per the design I am proposing, SRM is passed to KMD and revocation 
check is done in kernel space.
How is this done in CrOS? CrOS uses the above mentioned ksv property for 
that purpose, to pass the ksv to UMD for revocation check?

>
>> V2: Redesigned the property to match with CP needs of CrOS.
>>
>> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
>> ---
>>   drivers/gpu/drm/drm_connector.c | 14 +++++++++++++
>>   include/drm/drm_hdcp.h          | 44 +++++++++++++++++++++++++++++++++++++++++
>>   include/drm/drm_mode_config.h   |  5 +++++
>>   3 files changed, 63 insertions(+)
>>   create mode 100644 include/drm/drm_hdcp.h
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> index 5cd61af..64895fb 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -24,6 +24,7 @@
>>   #include <drm/drm_connector.h>
>>   #include <drm/drm_edid.h>
>>   #include <drm/drm_encoder.h>
>> +#include <drm/drm_hdcp.h>
>>   
>>   #include "drm_crtc_internal.h"
>>   #include "drm_internal.h"
>> @@ -617,6 +618,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_CP_UNSUPPORTED,	"CP Not Supported" },
>> +	{ DRM_CP_DISABLE,	"Disable CP" },
>> +	{ DRM_CP_ENABLE,	"Enable CP for Type0 content" },
> Type0 has no meaning in this case. The whole point of using "Content Protection"
> is to abstract the means of protection from userspace. The names are also much
> more verbose than they need be. "Unsupported", "Disabled", "Enabled" are fine.
Looks like i was still trying to reflect that "Type1 is coming" ;). I 
will rename these in next revision. Thanks
>
>
>> +};
>> +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
>> @@ -789,6 +797,12 @@ 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, "cp", drm_cp_enum_list,
>> +					   ARRAY_SIZE(drm_cp_enum_list));
> Your property name here, on the other hand, is not descriptive enough. Please
> expand to something meaningful.
Will change it to "content protection"
>
>> +	if (!prop)
>> +		return -ENOMEM;
>> +	dev->mode_config.cp_property = prop;
>> +
>>   	return 0;
>>   }
>>   
>> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> Why create a new header for this? That seems a little excessive.
But I am planning to use this header for all hdcp protocol specific
definitions like HDCP2.2 messages and Panel's HDCP2.2 register 
definitions etc.
With that I felt it justifies a header on it own.
And this will grow further when multiple spec versions are supported in 
future.

-Ram
>
> Sean
>
>> new file mode 100644
>> index 0000000..f6d0160
>> --- /dev/null
>> +++ b/include/drm/drm_hdcp.h
>> @@ -0,0 +1,44 @@
>> +/*
>> + * Copyright (c) 2017 Intel Corporation
>> + *
>> + * Permission to use, copy, modify, distribute, and sell this software and its
>> + * documentation for any purpose is hereby granted without fee, provided that
>> + * the above copyright notice appear in all copies and that both that copyright
>> + * notice and this permission notice appear in supporting documentation, and
>> + * that the name of the copyright holders not be used in advertising or
>> + * publicity pertaining to distribution of the software without specific,
>> + * written prior permission.  The copyright holders make no representations
>> + * about the suitability of this software for any purpose.  It is provided "as
>> + * is" without express or implied warranty.
>> + *
>> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
>> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
>> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
>> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
>> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
>> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
>> + * OF THIS SOFTWARE.
>> + */
>> +
>> +/*
>> + * Header for HDCP specific data
>> + */
>> +
>> +#ifndef __DRM_HDCP_H__
>> +#define __DRM_HDCP_H__
>> +
>> +/**
>> + * CP property related information
>> + */
>> +enum drm_cp_state {
>> +
>> +	/* HDCP sink and Src dont have any common HDCP ver supported */
>> +	DRM_CP_UNSUPPORTED,
>> +
>> +	/* Disable Content Protection */
>> +	DRM_CP_DISABLE,
>> +
>> +	/* Enable Content Protection */
>> +	DRM_CP_ENABLE,
>> +};
>> +#endif	/* __DRM_HDCP_H__ */
>> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>> index 4298171..7acb8b2 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 CP
>> +	 * of a connector
>> +	 */
>> +	struct drm_property *cp_property;
>> +	/**
>>   	 * @plane_type_property: Default plane property to differentiate
>>   	 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
>>   	 */
>> -- 
>> 2.7.4
>>


[-- Attachment #1.2: Type: text/html, Size: 8523 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [RFC v2] drm/hdcp: drm enum property for HDCP State

[Sean Paul]

On Fri, Jul 21, 2017 at 9:02 AM, Ramalingam C <ramalingam.c@intel.com> wrote:
> Sorry for late response.
>
>
> On Friday 14 July 2017 07:25 PM, Sean Paul wrote:
>
> On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
>
> DRM connector property is created to represent the content protection
> state of the connector and to configure the same.
>
> CP States defined:
> DRM_CP_UNSUPPORTED - CP is not supported
> DRM_CP_DISABLE - CP is disabled
> DRM_CP_ENABLE - CP is enabled
>
> Why are we changing the names from the original version (that's used in
> CrOS)? It's not
> obvious what "CP" stands for when looking at the name.
>
> Sean,
>
> Considering that we want to test this interface for CrOS stack as a
> consumer, I will try to align the property names.
> Meanwhile got few questions with respect to designing this CP interface
> aligned with existing CrOS stack.
>
> I want to understand what all are the bare minimal content protection
> interface required for existing CrOS Userspace stack.
> Whether this drm enum property will be sufficient for CrOS Content
> protection needs of HDCP1.4.?

Yep, just the property. Userspace sets it to desired and polls it
until it's enabled. Here are the code pointers, I sent this to Marc
Herbert, so perhaps it's already gotten to you.

Threads to set/query hdcp state:
https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/apply_content_protection_task.cc
https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/query_content_protection_task.cc
Code which actually tweaks the drm props:
https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.cc


> Could you please help me on that direction?
>
> When i refer your RFC at
> https://lists.freedesktop.org/archives/dri-devel/2014-December/073418.html
> there is a drm range property called  "Content Protection KSV", claimed to
> stand for content protection state.
> Is this used by current CrOS userspace stack?
>

No, it's not.

> As per the design I am proposing, SRM is passed to KMD and revocation check
> is done in kernel space.

I'm not completely against this, however I'm more partial to having
userspace handle SRM/revocation since it's not really a hardware
feature.

> How is this done in CrOS? CrOS uses the above mentioned ksv property for
> that purpose, to pass the ksv to UMD for revocation check?

We don't have SRM or revocation lists, but that was the idea should we
have needed it.

Sean

>
>
>
> V2: Redesigned the property to match with CP needs of CrOS.
>
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> ---
>  drivers/gpu/drm/drm_connector.c | 14 +++++++++++++
>  include/drm/drm_hdcp.h          | 44
> +++++++++++++++++++++++++++++++++++++++++
>  include/drm/drm_mode_config.h   |  5 +++++
>  3 files changed, 63 insertions(+)
>  create mode 100644 include/drm/drm_hdcp.h
>
> diff --git a/drivers/gpu/drm/drm_connector.c
> b/drivers/gpu/drm/drm_connector.c
> index 5cd61af..64895fb 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -24,6 +24,7 @@
>  #include <drm/drm_connector.h>
>  #include <drm/drm_edid.h>
>  #include <drm/drm_encoder.h>
> +#include <drm/drm_hdcp.h>
>
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> @@ -617,6 +618,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_CP_UNSUPPORTED, "CP Not Supported" },
> + { DRM_CP_DISABLE, "Disable CP" },
> + { DRM_CP_ENABLE, "Enable CP for Type0 content" },
>
> Type0 has no meaning in this case. The whole point of using "Content
> Protection"
> is to abstract the means of protection from userspace. The names are also
> much
> more verbose than they need be. "Unsupported", "Disabled", "Enabled" are
> fine.
>
> Looks like i was still trying to reflect that "Type1 is coming" ;). I will
> rename these in next revision. Thanks
>
>
> +};
> +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
> @@ -789,6 +797,12 @@ 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, "cp", drm_cp_enum_list,
> +   ARRAY_SIZE(drm_cp_enum_list));
>
> Your property name here, on the other hand, is not descriptive enough.
> Please
> expand to something meaningful.
>
> Will change it to "content protection"
>
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.cp_property = prop;
> +
>   return 0;
>  }
>
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
>
> Why create a new header for this? That seems a little excessive.
>
> But I am planning to use this header for all hdcp protocol specific
> definitions like HDCP2.2 messages and Panel's HDCP2.2 register definitions
> etc.
> With that I felt it justifies a header on it own.
> And this will grow further when multiple spec versions are supported in
> future.
>
> -Ram
>
>
> Sean
>
> new file mode 100644
> index 0000000..f6d0160
> --- /dev/null
> +++ b/include/drm/drm_hdcp.h
> @@ -0,0 +1,44 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> its
> + * documentation for any purpose is hereby granted without fee, provided
> that
> + * the above copyright notice appear in all copies and that both that
> copyright
> + * notice and this permission notice appear in supporting documentation,
> and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission.  The copyright holders make no representations
> + * about the suitability of this software for any purpose.  It is provided
> "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
> USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> PERFORMANCE
> + * OF THIS SOFTWARE.
> + */
> +
> +/*
> + * Header for HDCP specific data
> + */
> +
> +#ifndef __DRM_HDCP_H__
> +#define __DRM_HDCP_H__
> +
> +/**
> + * CP property related information
> + */
> +enum drm_cp_state {
> +
> + /* HDCP sink and Src dont have any common HDCP ver supported */
> + DRM_CP_UNSUPPORTED,
> +
> + /* Disable Content Protection */
> + DRM_CP_DISABLE,
> +
> + /* Enable Content Protection */
> + DRM_CP_ENABLE,
> +};
> +#endif /* __DRM_HDCP_H__ */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 4298171..7acb8b2 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 CP
> + * of a connector
> + */
> + struct drm_property *cp_property;
> + /**
>   * @plane_type_property: Default plane property to differentiate
>   * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
>   */
> --
> 2.7.4
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC v2] drm/hdcp: drm enum property for HDCP State

[Ramalingam C]

On Monday 24 July 2017 06:53 PM, Sean Paul wrote:
> On Fri, Jul 21, 2017 at 9:02 AM, Ramalingam C <ramalingam.c@intel.com> wrote:
>> Sorry for late response.
>>
>>
>> On Friday 14 July 2017 07:25 PM, Sean Paul wrote:
>>
>> On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
>>
>> DRM connector property is created to represent the content protection
>> state of the connector and to configure the same.
>>
>> CP States defined:
>> DRM_CP_UNSUPPORTED - CP is not supported
>> DRM_CP_DISABLE - CP is disabled
>> DRM_CP_ENABLE - CP is enabled
>>
>> Why are we changing the names from the original version (that's used in
>> CrOS)? It's not
>> obvious what "CP" stands for when looking at the name.
>>
>> Sean,
>>
>> Considering that we want to test this interface for CrOS stack as a
>> consumer, I will try to align the property names.
>> Meanwhile got few questions with respect to designing this CP interface
>> aligned with existing CrOS stack.
>>
>> I want to understand what all are the bare minimal content protection
>> interface required for existing CrOS Userspace stack.
>> Whether this drm enum property will be sufficient for CrOS Content
>> protection needs of HDCP1.4.?
> Yep, just the property. Userspace sets it to desired and polls it
> until it's enabled. Here are the code pointers, I sent this to Marc
> Herbert, so perhaps it's already gotten to you.
>
> Threads to set/query hdcp state:
> https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/apply_content_protection_task.cc
> https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/query_content_protection_task.cc
> Code which actually tweaks the drm props:
> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.cc
>
>
>> Could you please help me on that direction?
>>
>> When i refer your RFC at
>> https://lists.freedesktop.org/archives/dri-devel/2014-December/073418.html
>> there is a drm range property called  "Content Protection KSV", claimed to
>> stand for content protection state.
>> Is this used by current CrOS userspace stack?
>>
> No, it's not.
>
>> As per the design I am proposing, SRM is passed to KMD and revocation check
>> is done in kernel space.
> I'm not completely against this, however I'm more partial to having
> userspace handle SRM/revocation since it's not really a hardware
> feature.
>
>> How is this done in CrOS? CrOS uses the above mentioned ksv property for
>> that purpose, to pass the ksv to UMD for revocation check?
> We don't have SRM or revocation lists, but that was the idea should we
> have needed it.
>
> Sean
Thank you sean. This clears my doubts. I will share the reworked patch soon.

--Ram
>
>>
>>
>> V2: Redesigned the property to match with CP needs of CrOS.
>>
>> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
>> ---
>>   drivers/gpu/drm/drm_connector.c | 14 +++++++++++++
>>   include/drm/drm_hdcp.h          | 44
>> +++++++++++++++++++++++++++++++++++++++++
>>   include/drm/drm_mode_config.h   |  5 +++++
>>   3 files changed, 63 insertions(+)
>>   create mode 100644 include/drm/drm_hdcp.h
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c
>> index 5cd61af..64895fb 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -24,6 +24,7 @@
>>   #include <drm/drm_connector.h>
>>   #include <drm/drm_edid.h>
>>   #include <drm/drm_encoder.h>
>> +#include <drm/drm_hdcp.h>
>>
>>   #include "drm_crtc_internal.h"
>>   #include "drm_internal.h"
>> @@ -617,6 +618,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_CP_UNSUPPORTED, "CP Not Supported" },
>> + { DRM_CP_DISABLE, "Disable CP" },
>> + { DRM_CP_ENABLE, "Enable CP for Type0 content" },
>>
>> Type0 has no meaning in this case. The whole point of using "Content
>> Protection"
>> is to abstract the means of protection from userspace. The names are also
>> much
>> more verbose than they need be. "Unsupported", "Disabled", "Enabled" are
>> fine.
>>
>> Looks like i was still trying to reflect that "Type1 is coming" ;). I will
>> rename these in next revision. Thanks
>>
>>
>> +};
>> +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
>> @@ -789,6 +797,12 @@ 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, "cp", drm_cp_enum_list,
>> +   ARRAY_SIZE(drm_cp_enum_list));
>>
>> Your property name here, on the other hand, is not descriptive enough.
>> Please
>> expand to something meaningful.
>>
>> Will change it to "content protection"
>>
>> + if (!prop)
>> + return -ENOMEM;
>> + dev->mode_config.cp_property = prop;
>> +
>>    return 0;
>>   }
>>
>> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
>>
>> Why create a new header for this? That seems a little excessive.
>>
>> But I am planning to use this header for all hdcp protocol specific
>> definitions like HDCP2.2 messages and Panel's HDCP2.2 register definitions
>> etc.
>> With that I felt it justifies a header on it own.
>> And this will grow further when multiple spec versions are supported in
>> future.
>>
>> -Ram
>>
>>
>> Sean
>>
>> new file mode 100644
>> index 0000000..f6d0160
>> --- /dev/null
>> +++ b/include/drm/drm_hdcp.h
>> @@ -0,0 +1,44 @@
>> +/*
>> + * Copyright (c) 2017 Intel Corporation
>> + *
>> + * Permission to use, copy, modify, distribute, and sell this software and
>> its
>> + * documentation for any purpose is hereby granted without fee, provided
>> that
>> + * the above copyright notice appear in all copies and that both that
>> copyright
>> + * notice and this permission notice appear in supporting documentation,
>> and
>> + * that the name of the copyright holders not be used in advertising or
>> + * publicity pertaining to distribution of the software without specific,
>> + * written prior permission.  The copyright holders make no representations
>> + * about the suitability of this software for any purpose.  It is provided
>> "as
>> + * is" without express or implied warranty.
>> + *
>> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
>> SOFTWARE,
>> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
>> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
>> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
>> USE,
>> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
>> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
>> PERFORMANCE
>> + * OF THIS SOFTWARE.
>> + */
>> +
>> +/*
>> + * Header for HDCP specific data
>> + */
>> +
>> +#ifndef __DRM_HDCP_H__
>> +#define __DRM_HDCP_H__
>> +
>> +/**
>> + * CP property related information
>> + */
>> +enum drm_cp_state {
>> +
>> + /* HDCP sink and Src dont have any common HDCP ver supported */
>> + DRM_CP_UNSUPPORTED,
>> +
>> + /* Disable Content Protection */
>> + DRM_CP_DISABLE,
>> +
>> + /* Enable Content Protection */
>> + DRM_CP_ENABLE,
>> +};
>> +#endif /* __DRM_HDCP_H__ */
>> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>> index 4298171..7acb8b2 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 CP
>> + * of a connector
>> + */
>> + struct drm_property *cp_property;
>> + /**
>>    * @plane_type_property: Default plane property to differentiate
>>    * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
>>    */
>> --
>> 2.7.4
>>
>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ramalingam C]

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 <ramalingam.c@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" },
+	{ DRM_MODE_CONTENT_PROTECTION_DISABLE,		"Disabled" },
+	{ DRM_MODE_CONTENT_PROTECTION_ENABLE,		"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
@@ -789,6 +796,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 4298171..7acb8b2 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 CP
+	 * 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 403339f..554a770 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -127,6 +127,11 @@ extern "C" {
 #define DRM_MODE_LINK_STATUS_GOOD	0
 #define DRM_MODE_LINK_STATUS_BAD	1
 
+/* Content Protection options */
+#define DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED		0
+#define DRM_MODE_CONTENT_PROTECTION_DISABLE		1
+#define DRM_MODE_CONTENT_PROTECTION_ENABLE		2
+
 /*
  * DRM_MODE_ROTATE_<degrees>
  *
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Sean Paul]

On Mon, Jul 24, 2017 at 2:12 PM, Ramalingam C <ramalingam.c@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 <ramalingam.c@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/073336.html

https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.cc?l=27



> +       { DRM_MODE_CONTENT_PROTECTION_DISABLE,          "Disabled" },
> +       { DRM_MODE_CONTENT_PROTECTION_ENABLE,           "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
> @@ -789,6 +796,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 4298171..7acb8b2 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 CP
> +        * of a connector

Can you please elaborate on this, so readers can understand how this
property works? Perhaps just copy the docs from the original patch?

> +        */
> +       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 403339f..554a770 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -127,6 +127,11 @@ extern "C" {
>  #define DRM_MODE_LINK_STATUS_GOOD      0
>  #define DRM_MODE_LINK_STATUS_BAD       1
>
> +/* Content Protection options */
> +#define DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED                0
> +#define DRM_MODE_CONTENT_PROTECTION_DISABLE            1
> +#define DRM_MODE_CONTENT_PROTECTION_ENABLE             2
> +
>  /*
>   * DRM_MODE_ROTATE_<degrees>
>   *
> --
> 2.7.4
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ramalingam C]

[-- Attachment #1.1: Type: text/plain, Size: 7498 bytes --]



On Tuesday 25 July 2017 06:04 PM, Sean Paul wrote:
> On Mon, Jul 24, 2017 at 2:12 PM, Ramalingam C <ramalingam.c@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 <ramalingam.c@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/073336.html
>
> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.cc?l=27

Sean,

I think we have bit of confusion here.

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 :(

Lets say we need to modify CrOS user space, will there be any help for that?
I am not aware what it takes though.

I am trying to discuss both uapi versions of V1 and V2. I prefer V2 though.

If V1 is preferred we need a single property as below
"content protection" property  with {"Unsupported", "Undesired", 
"Desired", "Enabled"}
                         "Type1_desired" and "Type1_Enabled" are needed 
for HDCP2.2


If V2 is preferred we need two properties as below

"content protection" property with {"Unsupported", "Undesired", "Desired"}
             ("Type1_desired" - needed For HDCP2.2)
"content protection status" property with {"Disabled", "Enabled"}
             ("Type1_enabled" - needed for HDCP2.2)

         -   Not providing the ksv, as reflecting one ksv is not serving 
any purpose.
             Even for revocation check you need provision to list all 
device IDs (Max 32devices x 5Bytes ID) attached to repeater.
             So it is good to reflect the current protection level of 
link through enum.

And Usage will be as below:
     By default property "content protection" will be set to
         - "Unsupported"    (If CP is not possible on the Link)
         - "Undesired"        (If Link is not protected. CP is possible)
     By default property "content protection status" will be set to
         - "Disabled"

     the sequence of enabling protection on a link:
         - User space will set "content protection"  "Undesired" -> 
"Desired"
         - kernel will start the Authentication.
         - Once Auth is successful, kernel will change "content 
protection status" as "Disabled" -> "Enabled"

     The sequence of disabling protection on a link:
         - User space will set "content protection"  "Desired" -> 
"Undesired"
         - kernel will start the disable encryption.
         - Once it is successful, kernel will change "content protection 
status" as "Enabled" -> "Disabled"

     The sequence in case of encryption Failure on protected link:
         - When Failure of encryption occurs, kernel will change 
"content protection status" as "Enabled" -> "Disabled"
         - Kernel will try for retry for authentication and encryption.
                 - If the link is encrypted once again, kernel will 
change "content protection status" as "Disabled" -> "Enabled"
                 - But if retry failed, kernel will change "content 
protection" as "Desired" -> "Undesired"
         - So the "Desired" state of "content protection" property 
indicates that kernel is authenticating/re authenticating the link for 
encryption.

--Ram
>
>
>
>> +       { DRM_MODE_CONTENT_PROTECTION_DISABLE,          "Disabled" },
>> +       { DRM_MODE_CONTENT_PROTECTION_ENABLE,           "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
>> @@ -789,6 +796,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 4298171..7acb8b2 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 CP
>> +        * of a connector
> Can you please elaborate on this, so readers can understand how this
> property works? Perhaps just copy the docs from the original patch?
>
>> +        */
>> +       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 403339f..554a770 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -127,6 +127,11 @@ extern "C" {
>>   #define DRM_MODE_LINK_STATUS_GOOD      0
>>   #define DRM_MODE_LINK_STATUS_BAD       1
>>
>> +/* Content Protection options */
>> +#define DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED                0
>> +#define DRM_MODE_CONTENT_PROTECTION_DISABLE            1
>> +#define DRM_MODE_CONTENT_PROTECTION_ENABLE             2
>> +
>>   /*
>>    * DRM_MODE_ROTATE_<degrees>
>>    *
>> --
>> 2.7.4
>>


[-- Attachment #1.2: Type: text/html, Size: 9493 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

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

[Sean Paul]

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 <ramalingam.c@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 <ramalingam.c@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/073336.html
> > 
> > https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.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.

As has been mentioned before in this thread, it's a lot easier to upstream code
that is proven to work, than it is to merge speculative API. Further, if this
patch were merged, it would be CrOS which is currently the only consumer... not
a good look :)


> 
> Lets say we need to modify CrOS user space, will there be any help for that?
> I am not aware what it takes though.

You could probably reach out to chromium-dev@chromium.org or the author of the
Chrome hdcp implementation for help.

Sean

> 
> I am trying to discuss both uapi versions of V1 and V2. I prefer V2 though.
> 
> If V1 is preferred we need a single property as below
> "content protection" property  with {"Unsupported", "Undesired", "Desired",
> "Enabled"}
>                         "Type1_desired" and "Type1_Enabled" are needed for
> HDCP2.2
> 
> 
> If V2 is preferred we need two properties as below
> 
> "content protection" property with {"Unsupported", "Undesired", "Desired"}
>             ("Type1_desired" - needed For HDCP2.2)
> "content protection status" property with {"Disabled", "Enabled"}
>             ("Type1_enabled" - needed for HDCP2.2)
> 
>         -   Not providing the ksv, as reflecting one ksv is not serving any
> purpose.
>             Even for revocation check you need provision to list all device
> IDs (Max 32devices x 5Bytes ID) attached to repeater.
>             So it is good to reflect the current protection level of link
> through enum.
> 
> And Usage will be as below:
>     By default property "content protection" will be set to
>         - "Unsupported"    (If CP is not possible on the Link)
>         - "Undesired"        (If Link is not protected. CP is possible)
>     By default property "content protection status" will be set to
>         - "Disabled"
> 
>     the sequence of enabling protection on a link:
>         - User space will set "content protection"  "Undesired" -> "Desired"
>         - kernel will start the Authentication.
>         - Once Auth is successful, kernel will change "content protection
> status" as "Disabled" -> "Enabled"
> 
>     The sequence of disabling protection on a link:
>         - User space will set "content protection"  "Desired" -> "Undesired"
>         - kernel will start the disable encryption.
>         - Once it is successful, kernel will change "content protection
> status" as "Enabled" -> "Disabled"
> 
>     The sequence in case of encryption Failure on protected link:
>         - When Failure of encryption occurs, kernel will change "content
> protection status" as "Enabled" -> "Disabled"
>         - Kernel will try for retry for authentication and encryption.
>                 - If the link is encrypted once again, kernel will change
> "content protection status" as "Disabled" -> "Enabled"
>                 - But if retry failed, kernel will change "content
> protection" as "Desired" -> "Undesired"
>         - So the "Desired" state of "content protection" property indicates
> that kernel is authenticating/re authenticating the link for encryption.
> 
> --Ram
> > 
> > 
> > 
> > > +       { DRM_MODE_CONTENT_PROTECTION_DISABLE,          "Disabled" },
> > > +       { DRM_MODE_CONTENT_PROTECTION_ENABLE,           "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
> > > @@ -789,6 +796,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 4298171..7acb8b2 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 CP
> > > +        * of a connector
> > Can you please elaborate on this, so readers can understand how this
> > property works? Perhaps just copy the docs from the original patch?
> > 
> > > +        */
> > > +       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 403339f..554a770 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -127,6 +127,11 @@ extern "C" {
> > >   #define DRM_MODE_LINK_STATUS_GOOD      0
> > >   #define DRM_MODE_LINK_STATUS_BAD       1
> > > 
> > > +/* Content Protection options */
> > > +#define DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED                0
> > > +#define DRM_MODE_CONTENT_PROTECTION_DISABLE            1
> > > +#define DRM_MODE_CONTENT_PROTECTION_ENABLE             2
> > > +
> > >   /*
> > >    * DRM_MODE_ROTATE_<degrees>
> > >    *
> > > --
> > > 2.7.4
> > > 
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RFC v3] drm/hdcp: drm enum property for CP State

[C, Ramalingam]

> -----Original Message-----
> From: Sean Paul [mailto:seanpaul@chromium.org]
> Sent: Wednesday, July 26, 2017 8:23 PM
> To: C, Ramalingam <ramalingam.c@intel.com>
> Cc: Sean Paul <seanpaul@chromium.org>; Vetter, Daniel
> <daniel.vetter@intel.com>; Intel Graphics Development <intel-
> gfx@lists.freedesktop.org>; dri-devel <dri-devel@lists.freedesktop.org>; Daniel
> Vetter <daniel@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 <ramalingam.c@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 <ramalingam.c@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 uAPI for HDCP2.2 and 1.4 in place.

Sean, I think you will be better person to comment on this from both sides, CrOS and DRM.


> 
> As has been mentioned before in this thread, it's a lot easier to upstream code
> that is proven to work, than it is to merge speculative API. Further, if this patch
> were merged, it would be CrOS which is currently the only consumer... not a
> good look :)

Not exactly. CrOS will be the first consumer, Android will follow soon after this.
We need to enable this feature on HwC for that purpose. Yup might take required time :)

> 
> 
> >
> > Lets say we need to modify CrOS user space, will there be any help for that?
> > I am not aware what it takes though.
> 
> You could probably reach out to chromium-dev@chromium.org or the author of
> the Chrome hdcp implementation for help.

Thank you for the contact.
And before reaching out, it is better to conclude the HDCP1.4/2.2 uAPI interfaces that is agreeable for this community.

In that perspective, can we consider and review the uAPI interface with two properties discussed for V2 of your earlier patches?
Complete use case is discussed in my previous mail.

Based on userspace commitment for HDCP2.2, we can add blob property for SRM too.

> 
> Sean
> 
> >
> > I am trying to discuss both uapi versions of V1 and V2. I prefer V2 though.
> >
> > If V1 is preferred we need a single property as below "content
> > protection" property  with {"Unsupported", "Undesired", "Desired",
> > "Enabled"}
> >                         "Type1_desired" and "Type1_Enabled" are needed
> > for
> > HDCP2.2
> >
> >
> > If V2 is preferred we need two properties as below
> >
> > "content protection" property with {"Unsupported", "Undesired", "Desired"}
> >             ("Type1_desired" - needed For HDCP2.2) "content protection
> > status" property with {"Disabled", "Enabled"}
> >             ("Type1_enabled" - needed for HDCP2.2)

This uAPI interface looks fit to serve the all needs of HDCP1.4 and 2.2 as explained below.

Sean and Daniel,
	I request you to share your views. Thanks.

--Ram
> >
> >         -   Not providing the ksv, as reflecting one ksv is not serving any
> > purpose.
> >             Even for revocation check you need provision to list all
> > device IDs (Max 32devices x 5Bytes ID) attached to repeater.
> >             So it is good to reflect the current protection level of
> > link through enum.
> >
> > And Usage will be as below:
> >     By default property "content protection" will be set to
> >         - "Unsupported"    (If CP is not possible on the Link)
> >         - "Undesired"        (If Link is not protected. CP is possible)
> >     By default property "content protection status" will be set to
> >         - "Disabled"
> >
> >     the sequence of enabling protection on a link:
> >         - User space will set "content protection"  "Undesired" -> "Desired"
> >         - kernel will start the Authentication.
> >         - Once Auth is successful, kernel will change "content
> > protection status" as "Disabled" -> "Enabled"
> >
> >     The sequence of disabling protection on a link:
> >         - User space will set "content protection"  "Desired" -> "Undesired"
> >         - kernel will start the disable encryption.
> >         - Once it is successful, kernel will change "content
> > protection status" as "Enabled" -> "Disabled"
> >
> >     The sequence in case of encryption Failure on protected link:
> >         - When Failure of encryption occurs, kernel will change
> > "content protection status" as "Enabled" -> "Disabled"
> >         - Kernel will try for retry for authentication and encryption.
> >                 - If the link is encrypted once again, kernel will
> > change "content protection status" as "Disabled" -> "Enabled"
> >                 - But if retry failed, kernel will change "content
> > protection" as "Desired" -> "Undesired"
> >         - So the "Desired" state of "content protection" property
> > indicates that kernel is authenticating/re authenticating the link for encryption.
> >
> > --Ram
> > >
> > >
> > >
> > > > +       { DRM_MODE_CONTENT_PROTECTION_DISABLE,          "Disabled" },
> > > > +       { DRM_MODE_CONTENT_PROTECTION_ENABLE,           "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 @@ -789,6 +796,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 4298171..7acb8b2 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 CP
> > > > +        * of a connector
> > > Can you please elaborate on this, so readers can understand how this
> > > property works? Perhaps just copy the docs from the original patch?
> > >
> > > > +        */
> > > > +       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 403339f..554a770 100644
> > > > --- a/include/uapi/drm/drm_mode.h
> > > > +++ b/include/uapi/drm/drm_mode.h
> > > > @@ -127,6 +127,11 @@ extern "C" {
> > > >   #define DRM_MODE_LINK_STATUS_GOOD      0
> > > >   #define DRM_MODE_LINK_STATUS_BAD       1
> > > >
> > > > +/* Content Protection options */
> > > > +#define DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED                0
> > > > +#define DRM_MODE_CONTENT_PROTECTION_DISABLE            1
> > > > +#define DRM_MODE_CONTENT_PROTECTION_ENABLE             2
> > > > +
> > > >   /*
> > > >    * DRM_MODE_ROTATE_<degrees>
> > > >    *
> > > > --
> > > > 2.7.4
> > > >
> >
> 
> --
> Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Sean Paul]

On Wed, Jul 26, 2017 at 12:51 PM, C, Ramalingam <ramalingam.c@intel.com> wrote:
>
>> -----Original Message-----
>> From: Sean Paul [mailto:seanpaul@chromium.org]
>> Sent: Wednesday, July 26, 2017 8:23 PM
>> To: C, Ramalingam <ramalingam.c@intel.com>
>> Cc: Sean Paul <seanpaul@chromium.org>; Vetter, Daniel
>> <daniel.vetter@intel.com>; Intel Graphics Development <intel-
>> gfx@lists.freedesktop.org>; dri-devel <dri-devel@lists.freedesktop.org>; Daniel
>> Vetter <daniel@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 <ramalingam.c@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 <ramalingam.c@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 uAPI for HDCP2.2 and 1.4 in place.
>
> Sean, I think you will be better person to comment on this from both sides, CrOS and DRM.
>
>
>>
>> As has been mentioned before in this thread, it's a lot easier to upstream code
>> that is proven to work, than it is to merge speculative API. Further, if this patch
>> were merged, it would be CrOS which is currently the only consumer... not a
>> good look :)
>
> Not exactly. CrOS will be the first consumer, Android will follow soon after this.
> We need to enable this feature on HwC for that purpose. Yup might take required time :)
>
>>
>>
>> >
>> > Lets say we need to modify CrOS user space, will there be any help for that?
>> > I am not aware what it takes though.
>>
>> You could probably reach out to chromium-dev@chromium.org or the author of
>> the Chrome hdcp implementation for help.
>
> Thank you for the contact.
> And before reaching out, it is better to conclude the HDCP1.4/2.2 uAPI interfaces that is agreeable for this community.
>
> In that perspective, can we consider and review the uAPI interface with two properties discussed for V2 of your earlier patches?
> Complete use case is discussed in my previous mail.
>
> Based on userspace commitment for HDCP2.2, we can add blob property for SRM too.
>
>>
>> Sean
>>
>> >
>> > I am trying to discuss both uapi versions of V1 and V2. I prefer V2 though.
>> >
>> > If V1 is preferred we need a single property as below "content
>> > protection" property  with {"Unsupported", "Undesired", "Desired",
>> > "Enabled"}
>> >                         "Type1_desired" and "Type1_Enabled" are needed
>> > for
>> > HDCP2.2
>> >
>> >
>> > If V2 is preferred we need two properties as below
>> >
>> > "content protection" property with {"Unsupported", "Undesired", "Desired"}
>> >             ("Type1_desired" - needed For HDCP2.2) "content protection
>> > status" property with {"Disabled", "Enabled"}
>> >             ("Type1_enabled" - needed for HDCP2.2)
>
> This uAPI interface looks fit to serve the all needs of HDCP1.4 and 2.2 as explained below.
>
> Sean and Daniel,
>         I request you to share your views. Thanks.

Just going to summarize what I mentioned on IRC for the benefit of the list.

Any change to the original proposal will require a userspace
implementation to go along with it. We currently only have one
userspace implementation, which is Chrome. Chrome implements the
original RFC (linked above). If you change anything from the original
RFC, you no longer have a userspace implementation.

In order to have a userspace implementation, you can choose to alter
Chrome or another compositor.

In order to change Chrome, I suspect you'll need to do one of the
following to avoid breaking devices running old kernels with the RFC
uapi:
1- Make the proposed uapi changes compatible with the original RFC
2- Change all CrOS kernels to the new proposal at the same time as
userspace changes (this is actually possible with CrOS since it's all
packaged/updated up together)

In my opinion, option 1 is going to be the easiest path forward.
Others have also suggested same. So before we get too far ahead of
ourselves with HDCP 2.2, let's figure out how to upstream *something*
with a userspace implementation. If you want to go for option 2,
you'll need to do some legwork in Chrome beforehand.

Sean


>
> --Ram


<snip>

>> > > > --
>> > > > 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: [RFC v3] drm/hdcp: drm enum property for CP State

[Ramalingam C]

On Wednesday 26 July 2017 11:24 PM, Sean Paul wrote:
> On Wed, Jul 26, 2017 at 12:51 PM, C, Ramalingam <ramalingam.c@intel.com> wrote:
>>> -----Original Message-----
>>> From: Sean Paul [mailto:seanpaul@chromium.org]
>>> Sent: Wednesday, July 26, 2017 8:23 PM
>>> To: C, Ramalingam <ramalingam.c@intel.com>
>>> Cc: Sean Paul <seanpaul@chromium.org>; Vetter, Daniel
>>> <daniel.vetter@intel.com>; Intel Graphics Development <intel-
>>> gfx@lists.freedesktop.org>; dri-devel <dri-devel@lists.freedesktop.org>; Daniel
>>> Vetter <daniel@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 <ramalingam.c@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 <ramalingam.c@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 uAPI for HDCP2.2 and 1.4 in place.
>>
>> Sean, I think you will be better person to comment on this from both sides, CrOS and DRM.
>>
>>
>>> As has been mentioned before in this thread, it's a lot easier to upstream code
>>> that is proven to work, than it is to merge speculative API. Further, if this patch
>>> were merged, it would be CrOS which is currently the only consumer... not a
>>> good look :)
>> Not exactly. CrOS will be the first consumer, Android will follow soon after this.
>> We need to enable this feature on HwC for that purpose. Yup might take required time :)
>>
>>>
>>>> Lets say we need to modify CrOS user space, will there be any help for that?
>>>> I am not aware what it takes though.
>>> You could probably reach out to chromium-dev@chromium.org or the author of
>>> the Chrome hdcp implementation for help.
>> Thank you for the contact.
>> And before reaching out, it is better to conclude the HDCP1.4/2.2 uAPI interfaces that is agreeable for this community.
>>
>> In that perspective, can we consider and review the uAPI interface with two properties discussed for V2 of your earlier patches?
>> Complete use case is discussed in my previous mail.
>>
>> Based on userspace commitment for HDCP2.2, we can add blob property for SRM too.
>>
>>> Sean
>>>
>>>> I am trying to discuss both uapi versions of V1 and V2. I prefer V2 though.
>>>>
>>>> If V1 is preferred we need a single property as below "content
>>>> protection" property  with {"Unsupported", "Undesired", "Desired",
>>>> "Enabled"}
>>>>                          "Type1_desired" and "Type1_Enabled" are needed
>>>> for
>>>> HDCP2.2
>>>>
>>>>
>>>> If V2 is preferred we need two properties as below
>>>>
>>>> "content protection" property with {"Unsupported", "Undesired", "Desired"}
>>>>              ("Type1_desired" - needed For HDCP2.2) "content protection
>>>> status" property with {"Disabled", "Enabled"}
>>>>              ("Type1_enabled" - needed for HDCP2.2)
>> This uAPI interface looks fit to serve the all needs of HDCP1.4 and 2.2 as explained below.
>>
>> Sean and Daniel,
>>          I request you to share your views. Thanks.
> Just going to summarize what I mentioned on IRC for the benefit of the list.
>
> Any change to the original proposal will require a userspace
> implementation to go along with it. We currently only have one
> userspace implementation, which is Chrome. Chrome implements the
> original RFC (linked above). If you change anything from the original
> RFC, you no longer have a userspace implementation.
>
> In order to have a userspace implementation, you can choose to alter
> Chrome or another compositor.
>
> In order to change Chrome, I suspect you'll need to do one of the
> following to avoid breaking devices running old kernels with the RFC
> uapi:
> 1- Make the proposed uapi changes compatible with the original RFC
> 2- Change all CrOS kernels to the new proposal at the same time as
> userspace changes (this is actually possible with CrOS since it's all
> packaged/updated up together)
>
> In my opinion, option 1 is going to be the easiest path forward.
> Others have also suggested same. So before we get too far ahead of
> ourselves with HDCP 2.2, let's figure out how to upstream *something*
> with a userspace implementation. If you want to go for option 2,
> you'll need to do some legwork in Chrome beforehand.
>
> Sean
Based on given options, I will make proposed uapi changes compatible 
with with original RFC
to go with option 1.  I will send the updated patch in some time. Thanks 
Sean.

As per my off line discussion with Daniel, I working on using the DRM 
HDCP helper functions than
abstraction layer in DRM. Once that work is complete, I will re-spine 
the complete series for
review than phase by phase.

--Ram
>
>
>> --Ram
>
> <snip>
>
>>>>>> --
>>>>>> 2.7.4
>>>>>>
>>> --
>>> Sean Paul, Software Engineer, Google / Chromium OS

-- 
Regards,
--Ram.

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ramalingam C]

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

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

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

[Ramalingam C]

[-- Attachment #1.1: Type: text/plain, Size: 10104 bytes --]

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;

-- 
Regards,
--Ram.


[-- Attachment #1.2: Type: text/html, Size: 13060 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ramalingam C]

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx