* [PATCH v4 01/13] drm: move content protection property to mode_config
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
@ 2019-04-05 8:42 ` Ramalingam C
2019-04-05 8:42 ` [PATCH v4 02/13] drm/i915: debugfs: HDCP2.2 capability read Ramalingam C
` (11 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:42 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel
Content protection property is created once and stored in
drm_mode_config. And attached to all HDCP capable connectors.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 13 +++++++------
include/drm/drm_connector.h | 6 ------
include/drm/drm_mode_config.h | 6 ++++++
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 4eb81f10bc54..e52acad9005f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -740,7 +740,7 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
state->content_type = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
- } else if (property == connector->content_protection_property) {
+ } else if (property == config->content_protection_property) {
if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
return -EINVAL;
@@ -820,7 +820,7 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
*val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
- } else if (property == connector->content_protection_property) {
+ } else if (property == config->content_protection_property) {
*val = state->content_protection;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2355124849db..7c0eda9cca60 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1534,18 +1534,19 @@ int drm_connector_attach_content_protection_property(
struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
- struct drm_property *prop;
+ struct drm_property *prop =
+ dev->mode_config.content_protection_property;
- prop = drm_property_create_enum(dev, 0, "Content Protection",
- drm_cp_enum_list,
- ARRAY_SIZE(drm_cp_enum_list));
+ if (!prop)
+ prop = drm_property_create_enum(dev, 0, "Content Protection",
+ drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
if (!prop)
return -ENOMEM;
drm_object_attach_property(&connector->base, prop,
DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
-
- connector->content_protection_property = prop;
+ dev->mode_config.content_protection_property = prop;
return 0;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index c8061992d6cb..bcaffd68202e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1023,12 +1023,6 @@ struct drm_connector {
*/
struct drm_property *vrr_capable_property;
- /**
- * @content_protection_property: DRM ENUM property for content
- * protection. See drm_connector_attach_content_protection_property().
- */
- struct drm_property *content_protection_property;
-
/**
* @colorspace_property: Connector property to set the suitable
* colorspace supported by the sink.
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7f60e8eb269a..5764ee3c7453 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -836,6 +836,12 @@ struct drm_mode_config {
*/
struct drm_property *writeback_out_fence_ptr_property;
+ /**
+ * @content_protection_property: DRM ENUM property for content
+ * protection. See drm_connector_attach_content_protection_property().
+ */
+ struct drm_property *content_protection_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
--
2.19.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH v4 02/13] drm/i915: debugfs: HDCP2.2 capability read
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
2019-04-05 8:42 ` [PATCH v4 01/13] drm: move content protection property to mode_config Ramalingam C
@ 2019-04-05 8:42 ` Ramalingam C
2019-04-05 8:42 ` [PATCH v4 03/13] drm: Add Content protection type property Ramalingam C
` (10 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:42 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"
This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +++++++++++--
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdcp.c | 2 +-
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 08683dca7775..912f30e8e01a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4751,6 +4751,7 @@ static int i915_hdcp_sink_capability_show(struct seq_file *m, void *data)
{
struct drm_connector *connector = m->private;
struct intel_connector *intel_connector = to_intel_connector(connector);
+ bool hdcp_cap, hdcp2_cap;
if (connector->status != connector_status_connected)
return -ENODEV;
@@ -4761,8 +4762,16 @@ static int i915_hdcp_sink_capability_show(struct seq_file *m, void *data)
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
- seq_printf(m, "%s ", !intel_hdcp_capable(intel_connector) ?
- "None" : "HDCP1.4");
+ hdcp_cap = intel_hdcp_capable(intel_connector);
+ hdcp2_cap = intel_hdcp2_capable(intel_connector);
+
+ if (hdcp_cap)
+ seq_puts(m, "HDCP1.4 ");
+ if (hdcp2_cap)
+ seq_puts(m, "HDCP2.2 ");
+
+ if (!hdcp_cap && !hdcp2_cap)
+ seq_puts(m, "None");
seq_puts(m, "\n");
return 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4d7ae579fc92..a37a4477994c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2182,6 +2182,7 @@ int intel_hdcp_enable(struct intel_connector *connector);
int intel_hdcp_disable(struct intel_connector *connector);
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
bool intel_hdcp_capable(struct intel_connector *connector);
+bool intel_hdcp2_capable(struct intel_connector *connector);
void intel_hdcp_component_init(struct drm_i915_private *dev_priv);
void intel_hdcp_component_fini(struct drm_i915_private *dev_priv);
void intel_hdcp_cleanup(struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
index 9ce09f67776d..ff9497e5c591 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -76,7 +76,7 @@ bool intel_hdcp_capable(struct intel_connector *connector)
}
/* Is HDCP2.2 capable on Platform and Sink */
-static bool intel_hdcp2_capable(struct intel_connector *connector)
+bool intel_hdcp2_capable(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
--
2.19.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH v4 03/13] drm: Add Content protection type property
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
2019-04-05 8:42 ` [PATCH v4 01/13] drm: move content protection property to mode_config Ramalingam C
2019-04-05 8:42 ` [PATCH v4 02/13] drm/i915: debugfs: HDCP2.2 capability read Ramalingam C
@ 2019-04-05 8:42 ` Ramalingam C
2019-04-05 8:42 ` [PATCH v4 04/13] drm/i915: Attach content " Ramalingam C
` (9 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:42 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_connector.c | 53 ++++++++++++++++++++++++++++++-
drivers/gpu/drm/i915/intel_hdcp.c | 4 ++-
include/drm/drm_connector.h | 9 +++++-
include/drm/drm_mode_config.h | 6 ++++
include/uapi/drm/drm_mode.h | 4 +++
6 files changed, 77 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index e52acad9005f..fa50fac2e952 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == config->hdcp_content_type_property) {
+ state->hdcp_content_type = val;
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
@@ -822,6 +824,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
*val = state->scaling_mode;
} else if (property == config->content_protection_property) {
*val = state->content_protection;
+ } else if (property == config->hdcp_content_type_property) {
+ *val = state->hdcp_content_type;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7c0eda9cca60..03907d13ef66 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -857,6 +857,13 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] = {
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
+static struct drm_prop_enum_list drm_hdcp_content_type_enum_list[] = {
+ { DRM_MODE_HDCP_CONTENT_TYPE0, "HDCP Type0" },
+ { DRM_MODE_HDCP_CONTENT_TYPE1, "HDCP Type1" },
+};
+DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
+ drm_hdcp_content_type_enum_list)
+
/**
* DOC: standard connector properties
*
@@ -962,6 +969,23 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] = {
* the value transitions from ENABLED to DESIRED. This signifies the link
* is no longer protected and userspace should take appropriate action
* (whatever that might be).
+ * HDCP Content Type:
+ * This property is used by the userspace to configure the kernel with
+ * upcoming stream's content type. Content Type of a stream is decided by
+ * the owner of the stream, as HDCP Type0 or HDCP Type1.
+ *
+ * The value of the property can be one the below:
+ * - DRM_MODE_HDCP_CONTENT_TYPE0 = 0
+ * HDCP Type0 streams can be transmitted on a link which is
+ * encrypted with HDCP 1.4 or HDCP 2.2.
+ * - DRM_MODE_HDCP_CONTENT_TYPE1 = 1
+ * HDCP Type1 streams can be transmitted on a link which is
+ * encrypted only with HDCP 2.2.
+ *
+ * Please note this content type is introduced at HDCP 2.2 and used in its
+ * authentication process. If content type is changed when
+ * content_protection is not UNDESIRED, then kernel will disable the HDCP
+ * and re-enable with new type in the same atomic commit
*
* max bpc:
* This range property is used by userspace to limit the bit depth. When
@@ -1520,18 +1544,29 @@ EXPORT_SYMBOL(drm_connector_attach_scaling_mode_property);
* property
*
* @connector: connector to attach CP property on.
+ * @hdcp_content_type: is HDCP Content Type property needed for connector
*
* This is used to add support for content protection on select connectors.
* Content Protection is intentionally vague to allow for different underlying
* technologies, however it is most implemented by HDCP.
*
+ * When hdcp_content_type is true enum property called HDCP Content Type is
+ * created (if it is not already) and attached to the connector.
+ *
+ * This property is used for sending the protected content's stream type
+ * from userspace to kernel on selected connectors. Protected content provider
+ * will decide their type of their content and declare the same to kernel.
+ *
+ * Content type will be used during the HDCP 2.2 authentication.
+ * Content type will be set to &drm_connector_state.hdcp_content_type.
+ *
* The content protection will be set to &drm_connector_state.content_protection
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_attach_content_protection_property(
- struct drm_connector *connector)
+ struct drm_connector *connector, bool hdcp_content_type)
{
struct drm_device *dev = connector->dev;
struct drm_property *prop =
@@ -1548,6 +1583,22 @@ int drm_connector_attach_content_protection_property(
DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
dev->mode_config.content_protection_property = prop;
+ if (!hdcp_content_type)
+ return 0;
+
+ prop = dev->mode_config.hdcp_content_type_property;
+ if (!prop)
+ prop = drm_property_create_enum(dev, 0, "HDCP Content Type",
+ drm_hdcp_content_type_enum_list,
+ ARRAY_SIZE(
+ drm_hdcp_content_type_enum_list));
+ if (!prop)
+ return -ENOMEM;
+
+ drm_object_attach_property(&connector->base, prop,
+ DRM_MODE_HDCP_CONTENT_TYPE0);
+ dev->mode_config.hdcp_content_type_property = prop;
+
return 0;
}
EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
index ff9497e5c591..12b863e4ce09 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1795,7 +1795,9 @@ int intel_hdcp_init(struct intel_connector *connector,
if (!shim)
return -EINVAL;
- ret = drm_connector_attach_content_protection_property(&connector->base);
+ ret =
+ drm_connector_attach_content_protection_property(&connector->base,
+ false);
if (ret)
return ret;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index bcaffd68202e..bfa7e886fc93 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -518,6 +518,12 @@ struct drm_connector_state {
*/
unsigned int content_type;
+ /**
+ * @hdcp_content_type: Connector property to pass the type of
+ * protected content. This is most commonly used for HDCP.
+ */
+ unsigned int hdcp_content_type;
+
/**
* @scaling_mode: Connector property to control the
* upscaling, mostly used for built-in panels.
@@ -1288,6 +1294,7 @@ const char *drm_get_dvi_i_select_name(int val);
const char *drm_get_tv_subconnector_name(int val);
const char *drm_get_tv_select_name(int val);
const char *drm_get_content_protection_name(int val);
+const char *drm_get_hdcp_content_type_name(int val);
int drm_mode_create_dvi_i_properties(struct drm_device *dev);
int drm_mode_create_tv_margin_properties(struct drm_device *dev);
@@ -1302,7 +1309,7 @@ int drm_connector_attach_scaling_mode_property(struct drm_connector *connector,
int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector);
int drm_connector_attach_content_protection_property(
- struct drm_connector *connector);
+ struct drm_connector *connector, bool hdcp_content_type);
int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
int drm_mode_create_colorspace_property(struct drm_connector *connector);
int drm_mode_create_content_type_property(struct drm_device *dev);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 5764ee3c7453..b359b5b71eb9 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -842,6 +842,12 @@ struct drm_mode_config {
*/
struct drm_property *content_protection_property;
+ /**
+ * @hdcp_content_type_property: DRM ENUM property for type of
+ * Protected Content.
+ */
+ struct drm_property *hdcp_content_type_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index a439c2e67896..44412e8b77cd 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -210,6 +210,10 @@ extern "C" {
#define DRM_MODE_CONTENT_PROTECTION_DESIRED 1
#define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
+/* Content Type classification for HDCP2.2 vs others */
+#define DRM_MODE_HDCP_CONTENT_TYPE0 0
+#define DRM_MODE_HDCP_CONTENT_TYPE1 1
+
struct drm_mode_modeinfo {
__u32 clock;
__u16 hdisplay;
--
2.19.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH v4 04/13] drm/i915: Attach content type property
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
` (2 preceding siblings ...)
2019-04-05 8:42 ` [PATCH v4 03/13] drm: Add Content protection type property Ramalingam C
@ 2019-04-05 8:42 ` Ramalingam C
2019-04-05 8:42 ` [PATCH v4 05/13] drivers: create binary sysfs for class Ramalingam C
` (8 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:42 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
[Maarten]
v3:
s/content_protection_type/hdcp_content_type [Pekka]
v4:
hdcp disable incase of type change is moved into commit [daniel].
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
drivers/gpu/drm/i915/intel_ddi.c | 38 ++++++++++++++++++++++++---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_hdcp.c | 43 ++++++++++++++++++++-----------
3 files changed, 63 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 933df3a57a8a..b152cd2af0b4 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3495,7 +3495,8 @@ static void intel_enable_ddi(struct intel_encoder *encoder,
/* Enable hdcp if it's desired */
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
+ intel_hdcp_enable(to_intel_connector(conn_state->connector),
+ (u8)conn_state->hdcp_content_type);
}
static void intel_disable_ddi_dp(struct intel_encoder *encoder,
@@ -3562,15 +3563,44 @@ static void intel_ddi_update_pipe(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ bool re_enable_hdcp = false;
+ int ret = -EINVAL;
+
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+ /*
+ * During the HDCP encryption session if Type change is requested,
+ * disable the HDCP and reenable it with new TYPE value.
+ */
if (conn_state->content_protection ==
- DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
+ DRM_MODE_CONTENT_PROTECTION_ENABLED &&
+ conn_state->hdcp_content_type != hdcp->content_type) {
+ intel_hdcp_disable(to_intel_connector(conn_state->connector));
+ re_enable_hdcp = true;
+ }
+
+ if (conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_DESIRED || re_enable_hdcp)
+ ret = intel_hdcp_enable(connector,
+ (u8)conn_state->hdcp_content_type);
else if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
- intel_hdcp_disable(to_intel_connector(conn_state->connector));
+ intel_hdcp_disable(connector);
+
+ /*
+ * During Type change handling re-enabling of the HDCP failed. Hence
+ * changes state as ENABLED->DESIRED.
+ */
+ if (ret && re_enable_hdcp) {
+ mutex_lock(&hdcp->mutex);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(&hdcp->prop_work);
+ mutex_unlock(&hdcp->mutex);
+ }
}
static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a37a4477994c..e387e842f414 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2178,7 +2178,7 @@ void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *new_state);
int intel_hdcp_init(struct intel_connector *connector,
const struct intel_hdcp_shim *hdcp_shim);
-int intel_hdcp_enable(struct intel_connector *connector);
+int intel_hdcp_enable(struct intel_connector *connector, u8 content_type);
int intel_hdcp_disable(struct intel_connector *connector);
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
bool intel_hdcp_capable(struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
index 12b863e4ce09..19130f9b970d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1714,14 +1714,15 @@ static const struct component_ops i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
};
-static inline int initialize_hdcp_port_data(struct intel_connector *connector)
+static inline int initialize_hdcp_port_data(struct intel_connector *connector,
+ const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = &connector->hdcp;
struct hdcp_port_data *data = &hdcp->port_data;
data->port = connector->encoder->port;
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
- data->protocol = (u8)hdcp->shim->protocol;
+ data->protocol = (u8)shim->protocol;
data->k = 1;
if (!data->streams)
@@ -1771,12 +1772,13 @@ void intel_hdcp_component_init(struct drm_i915_private *dev_priv)
}
}
-static void intel_hdcp2_init(struct intel_connector *connector)
+static void intel_hdcp2_init(struct intel_connector *connector,
+ const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
- ret = initialize_hdcp_port_data(connector);
+ ret = initialize_hdcp_port_data(connector, shim);
if (ret) {
DRM_DEBUG_KMS("Mei hdcp data init failed\n");
return;
@@ -1795,25 +1797,28 @@ int intel_hdcp_init(struct intel_connector *connector,
if (!shim)
return -EINVAL;
+ if (is_hdcp2_supported(dev_priv))
+ intel_hdcp2_init(connector, shim);
+
ret =
drm_connector_attach_content_protection_property(&connector->base,
- false);
- if (ret)
+ hdcp->hdcp2_supported);
+ if (ret) {
+ hdcp->hdcp2_supported = false;
+ kfree(hdcp->port_data.streams);
return ret;
+ }
hdcp->shim = shim;
mutex_init(&hdcp->mutex);
INIT_DELAYED_WORK(&hdcp->check_work, intel_hdcp_check_work);
INIT_WORK(&hdcp->prop_work, intel_hdcp_prop_work);
-
- if (is_hdcp2_supported(dev_priv))
- intel_hdcp2_init(connector);
init_waitqueue_head(&hdcp->cp_irq_queue);
return 0;
}
-int intel_hdcp_enable(struct intel_connector *connector)
+int intel_hdcp_enable(struct intel_connector *connector, u8 content_type)
{
struct intel_hdcp *hdcp = &connector->hdcp;
unsigned long check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
@@ -1824,6 +1829,7 @@ int intel_hdcp_enable(struct intel_connector *connector)
mutex_lock(&hdcp->mutex);
WARN_ON(hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
+ hdcp->content_type = content_type;
/*
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
@@ -1835,8 +1841,12 @@ int intel_hdcp_enable(struct intel_connector *connector)
check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
}
- /* When HDCP2.2 fails, HDCP1.4 will be attempted */
- if (ret && intel_hdcp_capable(connector)) {
+ /*
+ * When HDCP2.2 fails and Content Type is not Type1, HDCP1.4 will
+ * be attempted.
+ */
+ if (ret && intel_hdcp_capable(connector) &&
+ hdcp->content_type != DRM_MODE_HDCP_CONTENT_TYPE1) {
ret = _intel_hdcp_enable(connector);
}
@@ -1918,12 +1928,15 @@ void intel_hdcp_atomic_check(struct drm_connector *connector,
/*
* Nothing to do if the state didn't change, or HDCP was activated since
- * the last commit
+ * the last commit. And also no change in hdcp content type.
*/
if (old_cp == new_cp ||
(old_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
- new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED))
- return;
+ new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED)) {
+ if (old_state->hdcp_content_type ==
+ new_state->hdcp_content_type)
+ return;
+ }
crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
new_state->crtc);
--
2.19.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH v4 05/13] drivers: create binary sysfs for class
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
` (3 preceding siblings ...)
2019-04-05 8:42 ` [PATCH v4 04/13] drm/i915: Attach content " Ramalingam C
@ 2019-04-05 8:42 ` Ramalingam C
2019-04-05 9:23 ` Greg Kroah-Hartman
2019-04-05 8:42 ` [PATCH v4 06/13] drm: HDCP SRM binary sysfs for subsystem Ramalingam C
` (7 subsequent siblings)
12 siblings, 1 reply; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:42 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel; +Cc: Greg Kroah-Hartman
Functions to create and remove the binary sysfs for class are added.
These are getting introduced as DRM wants to create the common binary
sysfs across the drm subsystem to handle hdcp srm.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Daniel Vetter <daniel@ffwll.ch>
---
drivers/base/class.c | 19 +++++++++++++++++++
include/linux/device.h | 4 ++++
2 files changed, 23 insertions(+)
diff --git a/drivers/base/class.c b/drivers/base/class.c
index d8a6a5864c2e..b0f37de16a14 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -83,6 +83,23 @@ static struct kobj_type class_ktype = {
/* Hotplug events for classes go to the class subsys */
static struct kset *class_kset;
+int class_create_bin_file(struct class *cls, const struct bin_attribute *attr)
+{
+ int error;
+
+ if (cls)
+ error = sysfs_create_bin_file(&cls->p->subsys.kobj, attr);
+ else
+ error = -EINVAL;
+ return error;
+}
+
+void class_remove_bin_file(struct class *cls, const struct bin_attribute *attr)
+{
+ if (cls)
+ sysfs_remove_bin_file(&cls->p->subsys.kobj, attr);
+}
+
int class_create_file_ns(struct class *cls, const struct class_attribute *attr,
const void *ns)
@@ -577,6 +594,8 @@ int __init classes_init(void)
return 0;
}
+EXPORT_SYMBOL_GPL(class_create_bin_file);
+EXPORT_SYMBOL_GPL(class_remove_bin_file);
EXPORT_SYMBOL_GPL(class_create_file_ns);
EXPORT_SYMBOL_GPL(class_remove_file_ns);
EXPORT_SYMBOL_GPL(class_unregister);
diff --git a/include/linux/device.h b/include/linux/device.h
index b6c6a4634801..004c8064a78a 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -485,6 +485,10 @@ struct class_attribute {
#define CLASS_ATTR_WO(_name) \
struct class_attribute class_attr_##_name = __ATTR_WO(_name)
+extern int __must_check class_create_bin_file(struct class *class,
+ const struct bin_attribute *attr);
+extern void class_remove_bin_file(struct class *class,
+ const struct bin_attribute *attr);
extern int __must_check class_create_file_ns(struct class *class,
const struct class_attribute *attr,
const void *ns);
--
2.19.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v4 05/13] drivers: create binary sysfs for class
2019-04-05 8:42 ` [PATCH v4 05/13] drivers: create binary sysfs for class Ramalingam C
@ 2019-04-05 9:23 ` Greg Kroah-Hartman
2019-04-05 10:36 ` Ramalingam C
0 siblings, 1 reply; 25+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-05 9:23 UTC (permalink / raw)
To: Ramalingam C; +Cc: intel-gfx, dri-devel
On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> Functions to create and remove the binary sysfs for class are added.
>
> These are getting introduced as DRM wants to create the common binary
> sysfs across the drm subsystem to handle hdcp srm.
Why do you need individual files? That's almost always a sign that you
are going to race with userspace in a bad way. Why not just use an
attribute group which provides automatic support for this?
thanks,
greg k-h
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v4 05/13] drivers: create binary sysfs for class
2019-04-05 9:23 ` Greg Kroah-Hartman
@ 2019-04-05 10:36 ` Ramalingam C
2019-04-05 12:32 ` Greg Kroah-Hartman
0 siblings, 1 reply; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 10:36 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: intel-gfx, dri-devel, gwan-gyeong.mun
On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> > Functions to create and remove the binary sysfs for class are added.
> >
> > These are getting introduced as DRM wants to create the common binary
> > sysfs across the drm subsystem to handle hdcp srm.
>
> Why do you need individual files? That's almost always a sign that you
> are going to race with userspace in a bad way. Why not just use an
> attribute group which provides automatic support for this?
Greg,
Reason behind this move is to have a common srm entry path across all drm
drivers. And the data fed into this is binary blob. So I am creating a
binary sysfs "hdcp_srm" at /sys/class/drm/
Thanks,
Ram.
>
> thanks,
>
> greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v4 05/13] drivers: create binary sysfs for class
2019-04-05 10:36 ` Ramalingam C
@ 2019-04-05 12:32 ` Greg Kroah-Hartman
2019-04-15 12:41 ` Ramalingam C
0 siblings, 1 reply; 25+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-05 12:32 UTC (permalink / raw)
To: Ramalingam C; +Cc: intel-gfx, dri-devel, gwan-gyeong.mun
On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote:
> On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> > > Functions to create and remove the binary sysfs for class are added.
> > >
> > > These are getting introduced as DRM wants to create the common binary
> > > sysfs across the drm subsystem to handle hdcp srm.
> >
> > Why do you need individual files? That's almost always a sign that you
> > are going to race with userspace in a bad way. Why not just use an
> > attribute group which provides automatic support for this?
> Greg,
>
> Reason behind this move is to have a common srm entry path across all drm
> drivers. And the data fed into this is binary blob. So I am creating a
> binary sysfs "hdcp_srm" at /sys/class/drm/
Ah, you want to have a file in your class directory, not your class
device directory.
No, please do not do that. There's a reason I got rid of those same
types of apis in the past.
And "binary blobs" are horrid anyway, they are only to be used as a
pass-through to the device itself, from the kernel, no touching the data
at all. If you really need/want this, then put it in the device's
directory as that is where the data is going to, not the kernel "class"
code as it sure as heck better not be doing anything with it.
thanks,
greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v4 05/13] drivers: create binary sysfs for class
2019-04-05 12:32 ` Greg Kroah-Hartman
@ 2019-04-15 12:41 ` Ramalingam C
2019-04-15 14:47 ` Greg Kroah-Hartman
0 siblings, 1 reply; 25+ messages in thread
From: Ramalingam C @ 2019-04-15 12:41 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: intel-gfx, dri-devel, gwan-gyeong.mun
On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote:
> On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote:
> > On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> > > > Functions to create and remove the binary sysfs for class are added.
> > > >
> > > > These are getting introduced as DRM wants to create the common binary
> > > > sysfs across the drm subsystem to handle hdcp srm.
> > >
> > > Why do you need individual files? That's almost always a sign that you
> > > are going to race with userspace in a bad way. Why not just use an
> > > attribute group which provides automatic support for this?
> > Greg,
> >
> > Reason behind this move is to have a common srm entry path across all drm
> > drivers. And the data fed into this is binary blob. So I am creating a
> > binary sysfs "hdcp_srm" at /sys/class/drm/
>
> Ah, you want to have a file in your class directory, not your class
> device directory.
>
> No, please do not do that. There's a reason I got rid of those same
> types of apis in the past.
>
> And "binary blobs" are horrid anyway, they are only to be used as a
> pass-through to the device itself, from the kernel, no touching the data
> at all. If you really need/want this, then put it in the device's
> directory as that is where the data is going to, not the kernel "class"
> code as it sure as heck better not be doing anything with it.
Greg,
But here the parsing of the received binary blob is done outside the drm
device/cards. This will be generic code for all drm cardx(drivers). And
this will provide the service helper functions to the drm drivers for HDCP SRM checking.
So we prefer to have the binary sysfs at /sys/class/drm/ than inside the
cardx folders, so that it will be generic. Could you please suggest a way to achieve that?
-Ram
>
> thanks,
>
> greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v4 05/13] drivers: create binary sysfs for class
2019-04-15 12:41 ` Ramalingam C
@ 2019-04-15 14:47 ` Greg Kroah-Hartman
2019-04-15 17:14 ` Ramalingam C
0 siblings, 1 reply; 25+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-15 14:47 UTC (permalink / raw)
To: Ramalingam C; +Cc: intel-gfx, dri-devel
On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote:
> On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote:
> > On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote:
> > > On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> > > > > Functions to create and remove the binary sysfs for class are added.
> > > > >
> > > > > These are getting introduced as DRM wants to create the common binary
> > > > > sysfs across the drm subsystem to handle hdcp srm.
> > > >
> > > > Why do you need individual files? That's almost always a sign that you
> > > > are going to race with userspace in a bad way. Why not just use an
> > > > attribute group which provides automatic support for this?
> > > Greg,
> > >
> > > Reason behind this move is to have a common srm entry path across all drm
> > > drivers. And the data fed into this is binary blob. So I am creating a
> > > binary sysfs "hdcp_srm" at /sys/class/drm/
> >
> > Ah, you want to have a file in your class directory, not your class
> > device directory.
> >
> > No, please do not do that. There's a reason I got rid of those same
> > types of apis in the past.
> >
> > And "binary blobs" are horrid anyway, they are only to be used as a
> > pass-through to the device itself, from the kernel, no touching the data
> > at all. If you really need/want this, then put it in the device's
> > directory as that is where the data is going to, not the kernel "class"
> > code as it sure as heck better not be doing anything with it.
> Greg,
>
> But here the parsing of the received binary blob is done outside the drm
> device/cards. This will be generic code for all drm cardx(drivers). And
> this will provide the service helper functions to the drm drivers for HDCP SRM checking.
Again, the kernel is NOT to be parsing any binary data that comes
through a sysfs file. If you need such a crazy thing, do it through
your normal drm ioctl.
> So we prefer to have the binary sysfs at /sys/class/drm/ than inside the
> cardx folders, so that it will be generic. Could you please suggest a way to achieve that?
What is a "cardx" driver? Why can you not do it in a device-specific
location? Are suddenly _ALL_ DRM drivers going to need this
information? What is the use case? Who is going to be providing this
blob and where is it going? What in the kernel uses it? What on the
hardware uses it? What is it actually?
I need a lot more information before being able to determine what you
can do here.
thanks,
greg k-h
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v4 05/13] drivers: create binary sysfs for class
2019-04-15 14:47 ` Greg Kroah-Hartman
@ 2019-04-15 17:14 ` Ramalingam C
2019-04-15 18:01 ` Greg Kroah-Hartman
0 siblings, 1 reply; 25+ messages in thread
From: Ramalingam C @ 2019-04-15 17:14 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: intel-gfx, dri-devel
On 2019-04-15 at 16:47:16 +0200, Greg Kroah-Hartman wrote:
> On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote:
> > On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote:
> > > > On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> > > > > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> > > > > > Functions to create and remove the binary sysfs for class are added.
> > > > > >
> > > > > > These are getting introduced as DRM wants to create the common binary
> > > > > > sysfs across the drm subsystem to handle hdcp srm.
> > > > >
> > > > > Why do you need individual files? That's almost always a sign that you
> > > > > are going to race with userspace in a bad way. Why not just use an
> > > > > attribute group which provides automatic support for this?
> > > > Greg,
> > > >
> > > > Reason behind this move is to have a common srm entry path across all drm
> > > > drivers. And the data fed into this is binary blob. So I am creating a
> > > > binary sysfs "hdcp_srm" at /sys/class/drm/
> > >
> > > Ah, you want to have a file in your class directory, not your class
> > > device directory.
> > >
> > > No, please do not do that. There's a reason I got rid of those same
> > > types of apis in the past.
> > >
> > > And "binary blobs" are horrid anyway, they are only to be used as a
> > > pass-through to the device itself, from the kernel, no touching the data
> > > at all. If you really need/want this, then put it in the device's
> > > directory as that is where the data is going to, not the kernel "class"
> > > code as it sure as heck better not be doing anything with it.
> > Greg,
> >
> > But here the parsing of the received binary blob is done outside the drm
> > device/cards. This will be generic code for all drm cardx(drivers). And
> > this will provide the service helper functions to the drm drivers for HDCP SRM checking.
>
> Again, the kernel is NOT to be parsing any binary data that comes
> through a sysfs file. If you need such a crazy thing, do it through
> your normal drm ioctl.
>
> > So we prefer to have the binary sysfs at /sys/class/drm/ than inside the
> > cardx folders, so that it will be generic. Could you please suggest a way to achieve that?
>
> What is a "cardx" driver?
Meant card0 card1 etc.. Drm drivers.
> Why can you not do it in a device-specific
> location? Are suddenly _ALL_ DRM drivers going to need this
> information? What is the use case? Who is going to be providing this
> blob and where is it going? What in the kernel uses it? What on the
> hardware uses it? What is it actually?
This is for HDCP usecase. List of compromised receivers' ID called system
renewability Message (SRM) will be available at userspace which needs to
be passed to be kernel. And this data can be parsed at kernel used
across all DRM drivers to implement the HDCP authentication. Hence we
want generic code to parse the SRM data and provide a helper function to
all DRM drivers to validate their HDCP sink's ID.
To achieve this we want to keep the sysfs and parsing logic outside the
drm drivers at the class level.
At present I915 will be using these implementation. in future other DRM
drivers can use the same.
Thanks,
-Ram
>
> I need a lot more information before being able to determine what you
> can do here.
>
> thanks,
>
> greg k-h
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v4 05/13] drivers: create binary sysfs for class
2019-04-15 17:14 ` Ramalingam C
@ 2019-04-15 18:01 ` Greg Kroah-Hartman
2019-04-15 19:14 ` Daniel Vetter
0 siblings, 1 reply; 25+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-15 18:01 UTC (permalink / raw)
To: Ramalingam C; +Cc: intel-gfx, dri-devel, gwan-gyeong.mun
On Mon, Apr 15, 2019 at 10:44:12PM +0530, Ramalingam C wrote:
> On 2019-04-15 at 16:47:16 +0200, Greg Kroah-Hartman wrote:
> > On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote:
> > > On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote:
> > > > > On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> > > > > > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> > > > > > > Functions to create and remove the binary sysfs for class are added.
> > > > > > >
> > > > > > > These are getting introduced as DRM wants to create the common binary
> > > > > > > sysfs across the drm subsystem to handle hdcp srm.
> > > > > >
> > > > > > Why do you need individual files? That's almost always a sign that you
> > > > > > are going to race with userspace in a bad way. Why not just use an
> > > > > > attribute group which provides automatic support for this?
> > > > > Greg,
> > > > >
> > > > > Reason behind this move is to have a common srm entry path across all drm
> > > > > drivers. And the data fed into this is binary blob. So I am creating a
> > > > > binary sysfs "hdcp_srm" at /sys/class/drm/
> > > >
> > > > Ah, you want to have a file in your class directory, not your class
> > > > device directory.
> > > >
> > > > No, please do not do that. There's a reason I got rid of those same
> > > > types of apis in the past.
> > > >
> > > > And "binary blobs" are horrid anyway, they are only to be used as a
> > > > pass-through to the device itself, from the kernel, no touching the data
> > > > at all. If you really need/want this, then put it in the device's
> > > > directory as that is where the data is going to, not the kernel "class"
> > > > code as it sure as heck better not be doing anything with it.
> > > Greg,
> > >
> > > But here the parsing of the received binary blob is done outside the drm
> > > device/cards. This will be generic code for all drm cardx(drivers). And
> > > this will provide the service helper functions to the drm drivers for HDCP SRM checking.
> >
> > Again, the kernel is NOT to be parsing any binary data that comes
> > through a sysfs file. If you need such a crazy thing, do it through
> > your normal drm ioctl.
> >
> > > So we prefer to have the binary sysfs at /sys/class/drm/ than inside the
> > > cardx folders, so that it will be generic. Could you please suggest a way to achieve that?
> >
> > What is a "cardx" driver?
> Meant card0 card1 etc.. Drm drivers.
> > Why can you not do it in a device-specific
> > location? Are suddenly _ALL_ DRM drivers going to need this
> > information? What is the use case? Who is going to be providing this
> > blob and where is it going? What in the kernel uses it? What on the
> > hardware uses it? What is it actually?
>
> This is for HDCP usecase. List of compromised receivers' ID called system
> renewability Message (SRM) will be available at userspace which needs to
> be passed to be kernel. And this data can be parsed at kernel used
> across all DRM drivers to implement the HDCP authentication. Hence we
> want generic code to parse the SRM data and provide a helper function to
> all DRM drivers to validate their HDCP sink's ID.
>
> To achieve this we want to keep the sysfs and parsing logic outside the
> drm drivers at the class level.
>
> At present I915 will be using these implementation. in future other DRM
> drivers can use the same.
Again, binary sysfs files are not for any data that the kernel has to
parse at all. So do not use sysfs for this.
thanks,
greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v4 05/13] drivers: create binary sysfs for class
2019-04-15 18:01 ` Greg Kroah-Hartman
@ 2019-04-15 19:14 ` Daniel Vetter
2019-04-16 9:04 ` Greg Kroah-Hartman
0 siblings, 1 reply; 25+ messages in thread
From: Daniel Vetter @ 2019-04-15 19:14 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: intel-gfx, dri-devel
On Mon, Apr 15, 2019 at 8:01 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 15, 2019 at 10:44:12PM +0530, Ramalingam C wrote:
> > On 2019-04-15 at 16:47:16 +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote:
> > > > On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote:
> > > > > On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote:
> > > > > > On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> > > > > > > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> > > > > > > > Functions to create and remove the binary sysfs for class are added.
> > > > > > > >
> > > > > > > > These are getting introduced as DRM wants to create the common binary
> > > > > > > > sysfs across the drm subsystem to handle hdcp srm.
> > > > > > >
> > > > > > > Why do you need individual files? That's almost always a sign that you
> > > > > > > are going to race with userspace in a bad way. Why not just use an
> > > > > > > attribute group which provides automatic support for this?
> > > > > > Greg,
> > > > > >
> > > > > > Reason behind this move is to have a common srm entry path across all drm
> > > > > > drivers. And the data fed into this is binary blob. So I am creating a
> > > > > > binary sysfs "hdcp_srm" at /sys/class/drm/
> > > > >
> > > > > Ah, you want to have a file in your class directory, not your class
> > > > > device directory.
> > > > >
> > > > > No, please do not do that. There's a reason I got rid of those same
> > > > > types of apis in the past.
> > > > >
> > > > > And "binary blobs" are horrid anyway, they are only to be used as a
> > > > > pass-through to the device itself, from the kernel, no touching the data
> > > > > at all. If you really need/want this, then put it in the device's
> > > > > directory as that is where the data is going to, not the kernel "class"
> > > > > code as it sure as heck better not be doing anything with it.
> > > > Greg,
> > > >
> > > > But here the parsing of the received binary blob is done outside the drm
> > > > device/cards. This will be generic code for all drm cardx(drivers). And
> > > > this will provide the service helper functions to the drm drivers for HDCP SRM checking.
> > >
> > > Again, the kernel is NOT to be parsing any binary data that comes
> > > through a sysfs file. If you need such a crazy thing, do it through
> > > your normal drm ioctl.
> > >
> > > > So we prefer to have the binary sysfs at /sys/class/drm/ than inside the
> > > > cardx folders, so that it will be generic. Could you please suggest a way to achieve that?
> > >
> > > What is a "cardx" driver?
> > Meant card0 card1 etc.. Drm drivers.
> > > Why can you not do it in a device-specific
> > > location? Are suddenly _ALL_ DRM drivers going to need this
> > > information? What is the use case? Who is going to be providing this
> > > blob and where is it going? What in the kernel uses it? What on the
> > > hardware uses it? What is it actually?
> >
> > This is for HDCP usecase. List of compromised receivers' ID called system
> > renewability Message (SRM) will be available at userspace which needs to
> > be passed to be kernel. And this data can be parsed at kernel used
> > across all DRM drivers to implement the HDCP authentication. Hence we
> > want generic code to parse the SRM data and provide a helper function to
> > all DRM drivers to validate their HDCP sink's ID.
> >
> > To achieve this we want to keep the sysfs and parsing logic outside the
> > drm drivers at the class level.
> >
> > At present I915 will be using these implementation. in future other DRM
> > drivers can use the same.
>
> Again, binary sysfs files are not for any data that the kernel has to
> parse at all. So do not use sysfs for this.
So what's the recommend thing then?
- requrest_firmware blob could work, aside that the blob might change
(the point of this to allow updates). For some hw you can even stuff
the SRM into some eprom iirc, so not entirely misfit. Plus kernel
parses it, so not sure request_firmware is really the right thing.
- configfs? I never used that one, but the transactional config stuff
this provides feels like silly amounts of overkill
- procfs :-)
- ioctl it definitely isn't, there's no need to open a drm device node
first and require a special binary to upload the srm if cat >
$kernfs/srm is all that's needed
- drmfs ... that's some serious amounts of overkill, so nope.
- per-device sysfs binary blob, silly because it's not per-device, but
wouldn't need your ack since we could sneak this one in :-) For
reasonable semantics we could just alias them all to the same storage,
so that userspace can do a cat > /sys/class/drm/card0/srm instead of
/sys/class/drm/srm for same effects (for multi gpu systems).
That's roughly why we ended up with the class sysfs file, but that
seems uncool too.
-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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v4 05/13] drivers: create binary sysfs for class
2019-04-15 19:14 ` Daniel Vetter
@ 2019-04-16 9:04 ` Greg Kroah-Hartman
2019-04-16 9:25 ` Daniel Vetter
0 siblings, 1 reply; 25+ messages in thread
From: Greg Kroah-Hartman @ 2019-04-16 9:04 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx, dri-devel
On Mon, Apr 15, 2019 at 09:14:12PM +0200, Daniel Vetter wrote:
> On Mon, Apr 15, 2019 at 8:01 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Mon, Apr 15, 2019 at 10:44:12PM +0530, Ramalingam C wrote:
> > > On 2019-04-15 at 16:47:16 +0200, Greg Kroah-Hartman wrote:
> > > > On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote:
> > > > > On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote:
> > > > > > On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote:
> > > > > > > On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> > > > > > > > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> > > > > > > > > Functions to create and remove the binary sysfs for class are added.
> > > > > > > > >
> > > > > > > > > These are getting introduced as DRM wants to create the common binary
> > > > > > > > > sysfs across the drm subsystem to handle hdcp srm.
> > > > > > > >
> > > > > > > > Why do you need individual files? That's almost always a sign that you
> > > > > > > > are going to race with userspace in a bad way. Why not just use an
> > > > > > > > attribute group which provides automatic support for this?
> > > > > > > Greg,
> > > > > > >
> > > > > > > Reason behind this move is to have a common srm entry path across all drm
> > > > > > > drivers. And the data fed into this is binary blob. So I am creating a
> > > > > > > binary sysfs "hdcp_srm" at /sys/class/drm/
> > > > > >
> > > > > > Ah, you want to have a file in your class directory, not your class
> > > > > > device directory.
> > > > > >
> > > > > > No, please do not do that. There's a reason I got rid of those same
> > > > > > types of apis in the past.
> > > > > >
> > > > > > And "binary blobs" are horrid anyway, they are only to be used as a
> > > > > > pass-through to the device itself, from the kernel, no touching the data
> > > > > > at all. If you really need/want this, then put it in the device's
> > > > > > directory as that is where the data is going to, not the kernel "class"
> > > > > > code as it sure as heck better not be doing anything with it.
> > > > > Greg,
> > > > >
> > > > > But here the parsing of the received binary blob is done outside the drm
> > > > > device/cards. This will be generic code for all drm cardx(drivers). And
> > > > > this will provide the service helper functions to the drm drivers for HDCP SRM checking.
> > > >
> > > > Again, the kernel is NOT to be parsing any binary data that comes
> > > > through a sysfs file. If you need such a crazy thing, do it through
> > > > your normal drm ioctl.
> > > >
> > > > > So we prefer to have the binary sysfs at /sys/class/drm/ than inside the
> > > > > cardx folders, so that it will be generic. Could you please suggest a way to achieve that?
> > > >
> > > > What is a "cardx" driver?
> > > Meant card0 card1 etc.. Drm drivers.
> > > > Why can you not do it in a device-specific
> > > > location? Are suddenly _ALL_ DRM drivers going to need this
> > > > information? What is the use case? Who is going to be providing this
> > > > blob and where is it going? What in the kernel uses it? What on the
> > > > hardware uses it? What is it actually?
> > >
> > > This is for HDCP usecase. List of compromised receivers' ID called system
> > > renewability Message (SRM) will be available at userspace which needs to
> > > be passed to be kernel. And this data can be parsed at kernel used
> > > across all DRM drivers to implement the HDCP authentication. Hence we
> > > want generic code to parse the SRM data and provide a helper function to
> > > all DRM drivers to validate their HDCP sink's ID.
> > >
> > > To achieve this we want to keep the sysfs and parsing logic outside the
> > > drm drivers at the class level.
> > >
> > > At present I915 will be using these implementation. in future other DRM
> > > drivers can use the same.
> >
> > Again, binary sysfs files are not for any data that the kernel has to
> > parse at all. So do not use sysfs for this.
>
> So what's the recommend thing then?
> - requrest_firmware blob could work, aside that the blob might change
> (the point of this to allow updates). For some hw you can even stuff
> the SRM into some eprom iirc, so not entirely misfit. Plus kernel
> parses it, so not sure request_firmware is really the right thing.
I think it is, as this really looks like "firmware" to me as you are
wanting to do something with the buffer and pass it on.
> - configfs? I never used that one, but the transactional config stuff
> this provides feels like silly amounts of overkill
Maybe, but why do you want to stuf binary data in your kernel in the
first place? It is configuration, right, why not have it in a format
that you can easily handle it in? Or is that the binary format you
have?
> - procfs :-)
Hah, no.
> - ioctl it definitely isn't, there's no need to open a drm device node
> first and require a special binary to upload the srm if cat >
> $kernfs/srm is all that's needed
But you want this associtated with a specific drm device, right? So
what's wrong with this?
> - drmfs ... that's some serious amounts of overkill, so nope.
300 lines of kernel code for a fs isn't that much :)
> - per-device sysfs binary blob, silly because it's not per-device, but
> wouldn't need your ack since we could sneak this one in :-) For
> reasonable semantics we could just alias them all to the same storage,
> so that userspace can do a cat > /sys/class/drm/card0/srm instead of
> /sys/class/drm/srm for same effects (for multi gpu systems).
Again, no, you do not use binary sysfs files for data you want to touch.
Yes, you can try to get away with it, but please do not.
thanks,
greg k-h
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH v4 05/13] drivers: create binary sysfs for class
2019-04-16 9:04 ` Greg Kroah-Hartman
@ 2019-04-16 9:25 ` Daniel Vetter
0 siblings, 0 replies; 25+ messages in thread
From: Daniel Vetter @ 2019-04-16 9:25 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: intel-gfx, dri-devel, Gwan-gyeong Mun
On Tue, Apr 16, 2019 at 11:04 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 15, 2019 at 09:14:12PM +0200, Daniel Vetter wrote:
> > On Mon, Apr 15, 2019 at 8:01 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > On Mon, Apr 15, 2019 at 10:44:12PM +0530, Ramalingam C wrote:
> > > > On 2019-04-15 at 16:47:16 +0200, Greg Kroah-Hartman wrote:
> > > > > On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote:
> > > > > > On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote:
> > > > > > > On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote:
> > > > > > > > On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> > > > > > > > > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote:
> > > > > > > > > > Functions to create and remove the binary sysfs for class are added.
> > > > > > > > > >
> > > > > > > > > > These are getting introduced as DRM wants to create the common binary
> > > > > > > > > > sysfs across the drm subsystem to handle hdcp srm.
> > > > > > > > >
> > > > > > > > > Why do you need individual files? That's almost always a sign that you
> > > > > > > > > are going to race with userspace in a bad way. Why not just use an
> > > > > > > > > attribute group which provides automatic support for this?
> > > > > > > > Greg,
> > > > > > > >
> > > > > > > > Reason behind this move is to have a common srm entry path across all drm
> > > > > > > > drivers. And the data fed into this is binary blob. So I am creating a
> > > > > > > > binary sysfs "hdcp_srm" at /sys/class/drm/
> > > > > > >
> > > > > > > Ah, you want to have a file in your class directory, not your class
> > > > > > > device directory.
> > > > > > >
> > > > > > > No, please do not do that. There's a reason I got rid of those same
> > > > > > > types of apis in the past.
> > > > > > >
> > > > > > > And "binary blobs" are horrid anyway, they are only to be used as a
> > > > > > > pass-through to the device itself, from the kernel, no touching the data
> > > > > > > at all. If you really need/want this, then put it in the device's
> > > > > > > directory as that is where the data is going to, not the kernel "class"
> > > > > > > code as it sure as heck better not be doing anything with it.
> > > > > > Greg,
> > > > > >
> > > > > > But here the parsing of the received binary blob is done outside the drm
> > > > > > device/cards. This will be generic code for all drm cardx(drivers). And
> > > > > > this will provide the service helper functions to the drm drivers for HDCP SRM checking.
> > > > >
> > > > > Again, the kernel is NOT to be parsing any binary data that comes
> > > > > through a sysfs file. If you need such a crazy thing, do it through
> > > > > your normal drm ioctl.
> > > > >
> > > > > > So we prefer to have the binary sysfs at /sys/class/drm/ than inside the
> > > > > > cardx folders, so that it will be generic. Could you please suggest a way to achieve that?
> > > > >
> > > > > What is a "cardx" driver?
> > > > Meant card0 card1 etc.. Drm drivers.
> > > > > Why can you not do it in a device-specific
> > > > > location? Are suddenly _ALL_ DRM drivers going to need this
> > > > > information? What is the use case? Who is going to be providing this
> > > > > blob and where is it going? What in the kernel uses it? What on the
> > > > > hardware uses it? What is it actually?
> > > >
> > > > This is for HDCP usecase. List of compromised receivers' ID called system
> > > > renewability Message (SRM) will be available at userspace which needs to
> > > > be passed to be kernel. And this data can be parsed at kernel used
> > > > across all DRM drivers to implement the HDCP authentication. Hence we
> > > > want generic code to parse the SRM data and provide a helper function to
> > > > all DRM drivers to validate their HDCP sink's ID.
> > > >
> > > > To achieve this we want to keep the sysfs and parsing logic outside the
> > > > drm drivers at the class level.
> > > >
> > > > At present I915 will be using these implementation. in future other DRM
> > > > drivers can use the same.
> > >
> > > Again, binary sysfs files are not for any data that the kernel has to
> > > parse at all. So do not use sysfs for this.
> >
> > So what's the recommend thing then?
> > - requrest_firmware blob could work, aside that the blob might change
> > (the point of this to allow updates). For some hw you can even stuff
> > the SRM into some eprom iirc, so not entirely misfit. Plus kernel
> > parses it, so not sure request_firmware is really the right thing.
>
> I think it is, as this really looks like "firmware" to me as you are
> wanting to do something with the buffer and pass it on.
>
> > - configfs? I never used that one, but the transactional config stuff
> > this provides feels like silly amounts of overkill
>
> Maybe, but why do you want to stuf binary data in your kernel in the
> first place? It is configuration, right, why not have it in a format
> that you can easily handle it in? Or is that the binary format you
> have?
Hm, maybe that's the disconnect. It's a blob because that's what the
relevant standards body defined it as such.
> > - procfs :-)
>
> Hah, no.
>
> > - ioctl it definitely isn't, there's no need to open a drm device node
> > first and require a special binary to upload the srm if cat >
> > $kernfs/srm is all that's needed
>
> But you want this associtated with a specific drm device, right? So
> what's wrong with this?
ioctl are generally for the unpriviledged stuff in drm, where multiple
client share (mediated by the driver) the single device. So per-client
configuration data and stuff like that. Anything that's device-wide
(clocks, hw config settings, other stuff like that) we generally stuff
into sysfs. Plus some dedicated low-level dev nodes (i2c, dp aux).
Also, the "ioctl to configure the device globally" is how dri1 worked,
and that stuff is serious nightmare fuel, so we try really hard to
avoid that design pattern because history :-)
> > - drmfs ... that's some serious amounts of overkill, so nope.
>
> 300 lines of kernel code for a fs isn't that much :)
That's not the problem, it's the "you need to mount this and then cat
the file into it and then maybe unmount it again" which doesn't make
for the most awesome uapi.
> > - per-device sysfs binary blob, silly because it's not per-device, but
> > wouldn't need your ack since we could sneak this one in :-) For
> > reasonable semantics we could just alias them all to the same storage,
> > so that userspace can do a cat > /sys/class/drm/card0/srm instead of
> > /sys/class/drm/srm for same effects (for multi gpu systems).
>
> Again, no, you do not use binary sysfs files for data you want to touch.
> Yes, you can try to get away with it, but please do not.
See above, that's the canonical format of this things. Of course we
could split it up, and let the kernel reassemble it all again (for the
case where we need to push it unchanged into hw), but that's somewhat
silly. Plus iirc it's also signed, which is somewhat ... hard to fake
:-)
Anyway I guess request_firmware it is then. We might end up doing a
new request_firmware for each modeset, but without the legacy compat
cruft (aka usermode helper) request_firmware should be plenty fast
enough to not matter I think. And also feels like reasonable uapi.
-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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v4 06/13] drm: HDCP SRM binary sysfs for subsystem
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
` (4 preceding siblings ...)
2019-04-05 8:42 ` [PATCH v4 05/13] drivers: create binary sysfs for class Ramalingam C
@ 2019-04-05 8:42 ` Ramalingam C
2019-04-05 8:42 ` [PATCH v4 07/13] drm/i915: SRM revocation check for HDCP1.4 and 2.2 Ramalingam C
` (6 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:42 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel; +Cc: gwan-gyeong.mun
A common binary sysfs called "hdcp_srm" is created at /sys/class/drm
with only write permission.
SRM table is parsed and stored at drm_hdcp.c, with functions exported
for the services for revocation check from drivers (which
implements the HDCP authentication)
This patch handles the HDCP1.4 and 2.2 versions of SRM table.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_hdcp.c | 351 +++++++++++++++++++++++++++++++++
drivers/gpu/drm/drm_internal.h | 4 +
drivers/gpu/drm/drm_sysfs.c | 2 +
include/drm/drm_hdcp.h | 35 ++++
5 files changed, 393 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_hdcp.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e630eccb951c..ef6e484c964b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -19,7 +19,7 @@ drm-y := drm_auth.o drm_bufs.o drm_cache.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
- drm_atomic_uapi.o
+ drm_atomic_uapi.o drm_hdcp.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
new file mode 100644
index 000000000000..2f0367d6be64
--- /dev/null
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -0,0 +1,351 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ *
+ * Authors:
+ * Ramalingam C <ramalingam.c@intel.com>
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gfp.h>
+#include <linux/export.h>
+#include <linux/slab.h>
+
+#include <drm/drm_hdcp.h>
+#include <drm/drm_sysfs.h>
+#include <drm/drm_print.h>
+
+struct hdcp_srm {
+ u8 *srm_buf;
+ size_t received_srm_sz;
+ u32 revocated_ksv_cnt;
+ u8 *revocated_ksv_list;
+
+ /* Mutex to protect above struct member */
+ struct mutex mutex;
+} *srm_data;
+
+static inline void drm_hdcp_print_ksv(const char *ksv)
+{
+ DRM_DEBUG("\t%#04x, %#04x, %#04x, %#04x, %#04x\n", *ksv & 0xff,
+ *(ksv + 1) & 0xff, *(ksv + 2) & 0xff, *(ksv + 3) & 0xff,
+ *(ksv + 4) & 0xff);
+}
+
+static u32 drm_hdcp_get_revocated_ksv_count(const char *buf, u32 vrls_length)
+{
+ u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
+
+ do {
+ vrl_ksv_cnt = *buf;
+ ksv_count += vrl_ksv_cnt;
+
+ vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
+ buf += vrl_sz;
+ parsed_bytes += vrl_sz;
+ } while (parsed_bytes < vrls_length);
+
+ return ksv_count;
+}
+
+static u32 drm_hdcp_get_revocated_ksvs(const char *buf, u8 *revocated_ksv_list,
+ u32 vrls_length)
+{
+ u32 parsed_bytes = 0, ksv_count = 0;
+ u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0;
+
+ do {
+ vrl_ksv_cnt = *buf;
+ vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN;
+
+ buf++;
+
+ DRM_DEBUG("vrl: %d, Revoked KSVs: %d\n", vrl_idx++,
+ vrl_ksv_cnt);
+ memcpy(revocated_ksv_list, buf, vrl_ksv_sz);
+
+ ksv_count += vrl_ksv_cnt;
+ revocated_ksv_list += vrl_ksv_sz;
+ buf += vrl_ksv_sz;
+
+ parsed_bytes += (vrl_ksv_sz + 1);
+ } while (parsed_bytes < vrls_length);
+
+ return ksv_count;
+}
+
+static int drm_hdcp_parse_hdcp1_srm(const char *buf, size_t count)
+{
+ struct hdcp_srm_header *header;
+ u32 vrl_length, ksv_count;
+
+ if (count < (sizeof(struct hdcp_srm_header) +
+ DRM_HDCP_1_4_VRL_LENGTH_SIZE + DRM_HDCP_1_4_DCP_SIG_SIZE)) {
+ DRM_ERROR("Invalid blob length\n");
+ return -EINVAL;
+ }
+
+ header = (struct hdcp_srm_header *)buf;
+ mutex_lock(&srm_data->mutex);
+ DRM_DEBUG("SRM ID: 0x%x, SRM Ver: 0x%x, SRM Gen No: 0x%x\n",
+ header->spec_indicator.srm_id,
+ __swab16(header->srm_version), header->srm_gen_no);
+
+ WARN_ON(header->spec_indicator.reserved_hi ||
+ header->spec_indicator.reserved_lo);
+
+ if (header->spec_indicator.srm_id != DRM_HDCP_1_4_SRM_ID) {
+ DRM_ERROR("Invalid srm_id\n");
+ mutex_unlock(&srm_data->mutex);
+ return -EINVAL;
+ }
+
+ buf = buf + sizeof(*header);
+ vrl_length = (*buf << 16 | *(buf + 1) << 8 | *(buf + 2));
+ if (count < (sizeof(struct hdcp_srm_header) + vrl_length) ||
+ vrl_length < (DRM_HDCP_1_4_VRL_LENGTH_SIZE +
+ DRM_HDCP_1_4_DCP_SIG_SIZE)) {
+ DRM_ERROR("Invalid blob length or vrl length\n");
+ mutex_unlock(&srm_data->mutex);
+ return -EINVAL;
+ }
+
+ /* Length of the all vrls combined */
+ vrl_length -= (DRM_HDCP_1_4_VRL_LENGTH_SIZE +
+ DRM_HDCP_1_4_DCP_SIG_SIZE);
+
+ if (!vrl_length) {
+ DRM_ERROR("No vrl found\n");
+ mutex_unlock(&srm_data->mutex);
+ return -EINVAL;
+ }
+
+ buf += DRM_HDCP_1_4_VRL_LENGTH_SIZE;
+ ksv_count = drm_hdcp_get_revocated_ksv_count(buf, vrl_length);
+ if (!ksv_count) {
+ DRM_DEBUG("Revocated KSV count is 0\n");
+ mutex_unlock(&srm_data->mutex);
+ return count;
+ }
+
+ kfree(srm_data->revocated_ksv_list);
+ srm_data->revocated_ksv_list = kzalloc(ksv_count * DRM_HDCP_KSV_LEN,
+ GFP_KERNEL);
+ if (!srm_data->revocated_ksv_list) {
+ DRM_ERROR("Out of Memory\n");
+ mutex_unlock(&srm_data->mutex);
+ return -ENOMEM;
+ }
+
+ if (drm_hdcp_get_revocated_ksvs(buf, srm_data->revocated_ksv_list,
+ vrl_length) != ksv_count) {
+ srm_data->revocated_ksv_cnt = 0;
+ kfree(srm_data->revocated_ksv_list);
+ mutex_unlock(&srm_data->mutex);
+ return -EINVAL;
+ }
+
+ srm_data->revocated_ksv_cnt = ksv_count;
+ mutex_unlock(&srm_data->mutex);
+ return count;
+}
+
+static int drm_hdcp_parse_hdcp2_srm(const char *buf, size_t count)
+{
+ struct hdcp2_srm_header *header;
+ u32 vrl_length, ksv_count, ksv_sz;
+
+ mutex_lock(&srm_data->mutex);
+ if (count < (sizeof(struct hdcp2_srm_header) +
+ DRM_HDCP_2_VRL_LENGTH_SIZE + DRM_HDCP_2_DCP_SIG_SIZE)) {
+ DRM_ERROR("Invalid blob length\n");
+ mutex_unlock(&srm_data->mutex);
+ return -EINVAL;
+ }
+
+ header = (struct hdcp2_srm_header *)buf;
+ DRM_DEBUG("SRM ID: 0x%x, SRM Ver: 0x%x, SRM Gen No: 0x%x\n",
+ header->spec_indicator.srm_id,
+ __swab16(header->srm_version), header->srm_gen_no);
+
+ if (header->spec_indicator.reserved)
+ return -EINVAL;
+
+ buf = buf + sizeof(*header);
+ vrl_length = (*buf << 16 | *(buf + 1) << 8 | *(buf + 2));
+
+ if (count < (sizeof(struct hdcp2_srm_header) + vrl_length) ||
+ vrl_length < (DRM_HDCP_2_VRL_LENGTH_SIZE +
+ DRM_HDCP_2_DCP_SIG_SIZE)) {
+ DRM_ERROR("Invalid blob length or vrl length\n");
+ mutex_unlock(&srm_data->mutex);
+ return -EINVAL;
+ }
+
+ /* Length of the all vrls combined */
+ vrl_length -= (DRM_HDCP_2_VRL_LENGTH_SIZE +
+ DRM_HDCP_2_DCP_SIG_SIZE);
+
+ if (!vrl_length) {
+ DRM_ERROR("No vrl found\n");
+ mutex_unlock(&srm_data->mutex);
+ return -EINVAL;
+ }
+
+ buf += DRM_HDCP_2_VRL_LENGTH_SIZE;
+ ksv_count = (*buf << 2) | DRM_HDCP_2_KSV_COUNT_2_LSBITS(*(buf + 1));
+ if (!ksv_count) {
+ DRM_DEBUG("Revocated KSV count is 0\n");
+ mutex_unlock(&srm_data->mutex);
+ return count;
+ }
+
+ kfree(srm_data->revocated_ksv_list);
+ srm_data->revocated_ksv_list = kzalloc(ksv_count * DRM_HDCP_KSV_LEN,
+ GFP_KERNEL);
+ if (!srm_data->revocated_ksv_list) {
+ DRM_ERROR("Out of Memory\n");
+ mutex_unlock(&srm_data->mutex);
+ return -ENOMEM;
+ }
+
+ ksv_sz = ksv_count * DRM_HDCP_KSV_LEN;
+ buf += DRM_HDCP_2_NO_OF_DEV_PLUS_RESERVED_SZ;
+
+ DRM_DEBUG("Revoked KSVs: %d\n", ksv_count);
+ memcpy(srm_data->revocated_ksv_list, buf, ksv_sz);
+
+ srm_data->revocated_ksv_cnt = ksv_count;
+ mutex_unlock(&srm_data->mutex);
+ return count;
+}
+
+static inline bool is_srm_version_hdcp1(const char *buf)
+{
+ return ((u8)*buf) == DRM_HDCP_1_4_SRM_ID << 4;
+}
+
+static inline bool is_srm_version_hdcp2(const char *buf)
+{
+ return ((u8)*buf) == (DRM_HDCP_2_SRM_ID << 4 |
+ DRM_HDCP_2_INDICATOR);
+}
+
+static ssize_t drm_hdcp_srm_update(const char *buf, size_t count)
+{
+ if (is_srm_version_hdcp1(buf))
+ return (ssize_t)drm_hdcp_parse_hdcp1_srm(buf, count);
+ else if (is_srm_version_hdcp2(buf))
+ return (ssize_t)drm_hdcp_parse_hdcp2_srm(buf, count);
+
+ return (ssize_t)-EINVAL;
+}
+
+/* Check if any of the KSV is revocated by DCP LLC through SRM table */
+bool drm_hdcp_ksvs_revocated(u8 *ksvs, u32 ksv_count)
+{
+ u32 rev_ksv_cnt, cnt, i, j;
+ u8 *rev_ksv_list;
+
+ if (!srm_data)
+ return false;
+
+ mutex_lock(&srm_data->mutex);
+ rev_ksv_cnt = srm_data->revocated_ksv_cnt;
+ rev_ksv_list = srm_data->revocated_ksv_list;
+
+ /* If the Revocated ksv list is empty */
+ if (!rev_ksv_cnt || !rev_ksv_list) {
+ mutex_unlock(&srm_data->mutex);
+ return false;
+ }
+
+ for (cnt = 0; cnt < ksv_count; cnt++) {
+ rev_ksv_list = srm_data->revocated_ksv_list;
+ for (i = 0; i < rev_ksv_cnt; i++) {
+ for (j = 0; j < DRM_HDCP_KSV_LEN; j++)
+ if (*(ksvs + j) != *(rev_ksv_list + j)) {
+ break;
+ } else if (j == (DRM_HDCP_KSV_LEN - 1)) {
+ DRM_DEBUG("Revocated KSV is ");
+ drm_hdcp_print_ksv(ksvs);
+ mutex_unlock(&srm_data->mutex);
+ return true;
+ }
+ /* Move the offset to next KSV in the revocated list */
+ rev_ksv_list += DRM_HDCP_KSV_LEN;
+ }
+
+ /* Iterate to next ksv_offset */
+ ksvs += DRM_HDCP_KSV_LEN;
+ }
+ mutex_unlock(&srm_data->mutex);
+ return false;
+}
+EXPORT_SYMBOL_GPL(drm_hdcp_ksvs_revocated);
+
+static ssize_t
+drm_hdcp_srm_write(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr, char *buf,
+ loff_t offset, size_t count)
+{
+ int ret;
+
+ if (count > DRM_HDCP_SRM_GEN1_MAX_BYTES) {
+ DRM_ERROR("Invalid length of SRM\n");
+ return -EINVAL;
+ }
+
+ ret = drm_hdcp_srm_update((const char *)buf, count);
+ if (ret < 0)
+ return ret;
+
+ memcpy((void *)srm_data->srm_buf, (const void *)buf, count);
+
+ return count;
+}
+
+static const struct bin_attribute srm_attrs = {
+ .attr = {.name = "hdcp_srm", .mode = S_IWUSR},
+ .read = NULL,
+ .write = drm_hdcp_srm_write,
+ .mmap = NULL,
+ .private = (void *)0
+};
+
+int drm_setup_hdcp_srm(struct class *drm_class)
+{
+ int ret;
+
+ srm_data = kzalloc(sizeof(*srm_data), GFP_KERNEL);
+ if (!srm_data)
+ return -ENOMEM;
+
+ srm_data->srm_buf = kcalloc(DRM_HDCP_SRM_GEN1_MAX_BYTES,
+ sizeof(u8), GFP_KERNEL);
+ if (!srm_data->srm_buf) {
+ kfree(srm_data);
+ return -ENOMEM;
+ }
+ mutex_init(&srm_data->mutex);
+
+ ret = class_create_bin_file(drm_class, &srm_attrs);
+ if (ret) {
+ DRM_ERROR("SRM bin sysfs creation failed. %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+void drm_teardown_hdcp_srm(struct class *drm_class)
+{
+ if (srm_data) {
+ kfree(srm_data->srm_buf);
+ kfree(srm_data->revocated_ksv_list);
+ kfree(srm_data);
+ }
+
+ class_remove_bin_file(drm_class, &srm_attrs);
+}
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 251d67e04c2d..15d6bfc764da 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -191,3 +191,7 @@ int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
void drm_framebuffer_print_info(struct drm_printer *p, unsigned int indent,
const struct drm_framebuffer *fb);
int drm_framebuffer_debugfs_init(struct drm_minor *minor);
+
+/* drm_hdcp.c */
+int drm_setup_hdcp_srm(struct class *drm_class);
+void drm_teardown_hdcp_srm(struct class *drm_class);
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index ecb7b33002bb..18b1ac442997 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -78,6 +78,7 @@ int drm_sysfs_init(void)
}
drm_class->devnode = drm_devnode;
+ drm_setup_hdcp_srm(drm_class);
return 0;
}
@@ -90,6 +91,7 @@ void drm_sysfs_destroy(void)
{
if (IS_ERR_OR_NULL(drm_class))
return;
+ drm_teardown_hdcp_srm(drm_class);
class_remove_file(drm_class, &class_attr_version.attr);
class_destroy(drm_class);
drm_class = NULL;
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index f243408ecf26..5cb21dd6797b 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -265,4 +265,39 @@ void drm_hdcp2_u32_to_seq_num(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN], u32 val)
seq_num[2] = val;
}
+#define DRM_HDCP_SRM_GEN1_MAX_BYTES (5 * 1024)
+#define DRM_HDCP_1_4_SRM_ID 0x8
+#define DRM_HDCP_1_4_VRL_LENGTH_SIZE 3
+#define DRM_HDCP_1_4_DCP_SIG_SIZE 40
+
+struct hdcp_srm_header {
+ struct {
+ u8 reserved_hi:4;
+ u8 srm_id:4;
+ u8 reserved_lo;
+ } spec_indicator;
+ u16 srm_version;
+ u8 srm_gen_no;
+} __packed;
+
+#define DRM_HDCP_2_SRM_ID 0x9
+#define DRM_HDCP_2_INDICATOR 0x1
+#define DRM_HDCP_2_VRL_LENGTH_SIZE 3
+#define DRM_HDCP_2_DCP_SIG_SIZE 384
+#define DRM_HDCP_2_NO_OF_DEV_PLUS_RESERVED_SZ 4
+
+#define DRM_HDCP_2_KSV_COUNT_2_LSBITS(byte) (((byte) & 0xC) >> 6)
+
+struct hdcp2_srm_header {
+ struct {
+ u8 hdcp2_indicator:4;
+ u8 srm_id:4;
+ u8 reserved;
+ } spec_indicator;
+ u16 srm_version;
+ u8 srm_gen_no;
+} __packed;
+
+bool drm_hdcp_ksvs_revocated(u8 *ksvs, u32 ksv_count);
+
#endif
--
2.19.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH v4 07/13] drm/i915: SRM revocation check for HDCP1.4 and 2.2
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
` (5 preceding siblings ...)
2019-04-05 8:42 ` [PATCH v4 06/13] drm: HDCP SRM binary sysfs for subsystem Ramalingam C
@ 2019-04-05 8:42 ` Ramalingam C
2019-04-05 8:42 ` [PATCH v4 08/13] drm/hdcp: gathering hdcp related code into drm_hdcp.c Ramalingam C
` (5 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:42 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel; +Cc: gwan-gyeong.mun
DRM HDCP SRM revocation check services are used from I915 for HDCP1.4
and 2.2 revocation check during the respective authentication flow.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
drivers/gpu/drm/i915/intel_hdcp.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
index 19130f9b970d..6982a2e6cf9a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -531,6 +531,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
if (ret)
goto err;
+ if (drm_hdcp_ksvs_revocated(ksv_fifo, num_downstream)) {
+ DRM_ERROR("Revocated Ksv(s) in ksv_fifo\n");
+ return -EPERM;
+ }
+
/*
* When V prime mismatches, DP Spec mandates re-read of
* V prime atleast twice.
@@ -625,6 +630,11 @@ static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
if (ret < 0)
return ret;
+ if (drm_hdcp_ksvs_revocated(bksv.shim, 1)) {
+ DRM_ERROR("BKSV is revocated\n");
+ return -EPERM;
+ }
+
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
@@ -1193,6 +1203,11 @@ static int hdcp2_authentication_key_exchange(struct intel_connector *connector)
hdcp->is_repeater = HDCP_2_2_RX_REPEATER(msgs.send_cert.rx_caps[2]);
+ if (drm_hdcp_ksvs_revocated(msgs.send_cert.cert_rx.receiver_id, 1)) {
+ DRM_ERROR("Receiver ID is revocated\n");
+ return -EPERM;
+ }
+
/*
* Here msgs.no_stored_km will hold msgs corresponding to the km
* stored also.
@@ -1350,8 +1365,8 @@ int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
struct hdcp2_rep_send_ack rep_ack;
} msgs;
const struct intel_hdcp_shim *shim = hdcp->shim;
+ u32 seq_num_v, device_cnt;
u8 *rx_info;
- u32 seq_num_v;
int ret;
ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_SEND_RECVID_LIST,
@@ -1376,6 +1391,14 @@ int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
return -EINVAL;
}
+ device_cnt = HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 ||
+ HDCP_2_2_DEV_COUNT_LO(rx_info[1]);
+ if (drm_hdcp_ksvs_revocated(msgs.recvid_list.receiver_ids,
+ device_cnt)) {
+ DRM_ERROR("Revoked receiver ID(s) is in list\n");
+ return -EPERM;
+ }
+
ret = hdcp2_verify_rep_topology_prepare_ack(connector,
&msgs.recvid_list,
&msgs.rep_ack);
--
2.19.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH v4 08/13] drm/hdcp: gathering hdcp related code into drm_hdcp.c
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
` (6 preceding siblings ...)
2019-04-05 8:42 ` [PATCH v4 07/13] drm/i915: SRM revocation check for HDCP1.4 and 2.2 Ramalingam C
@ 2019-04-05 8:42 ` Ramalingam C
2019-04-05 8:42 ` [PATCH v4 09/13] drm: uevent for connector status change Ramalingam C
` (4 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:42 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel; +Cc: gwan-gyeong.mun
Considering the significant size of hdcp related code in drm, all
hdcp related codes are moved into separate file called drm_hdcp.c.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
---
drivers/gpu/drm/drm_connector.c | 78 -------------------------------
drivers/gpu/drm/drm_hdcp.c | 82 +++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 2 -
include/drm/drm_hdcp.h | 4 ++
4 files changed, 86 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 03907d13ef66..436cf8e764cc 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -823,13 +823,6 @@ static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
-static struct drm_prop_enum_list drm_cp_enum_list[] = {
- { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
- { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
- { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
-};
-DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
-
static const struct drm_prop_enum_list hdmi_colorspaces[] = {
/* For Default case, driver will set the colorspace */
{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
@@ -857,13 +850,6 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] = {
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
-static struct drm_prop_enum_list drm_hdcp_content_type_enum_list[] = {
- { DRM_MODE_HDCP_CONTENT_TYPE0, "HDCP Type0" },
- { DRM_MODE_HDCP_CONTENT_TYPE1, "HDCP Type1" },
-};
-DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
- drm_hdcp_content_type_enum_list)
-
/**
* DOC: standard connector properties
*
@@ -1539,70 +1525,6 @@ int drm_connector_attach_scaling_mode_property(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_connector_attach_scaling_mode_property);
-/**
- * drm_connector_attach_content_protection_property - attach content protection
- * property
- *
- * @connector: connector to attach CP property on.
- * @hdcp_content_type: is HDCP Content Type property needed for connector
- *
- * This is used to add support for content protection on select connectors.
- * Content Protection is intentionally vague to allow for different underlying
- * technologies, however it is most implemented by HDCP.
- *
- * When hdcp_content_type is true enum property called HDCP Content Type is
- * created (if it is not already) and attached to the connector.
- *
- * This property is used for sending the protected content's stream type
- * from userspace to kernel on selected connectors. Protected content provider
- * will decide their type of their content and declare the same to kernel.
- *
- * Content type will be used during the HDCP 2.2 authentication.
- * Content type will be set to &drm_connector_state.hdcp_content_type.
- *
- * The content protection will be set to &drm_connector_state.content_protection
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_connector_attach_content_protection_property(
- struct drm_connector *connector, bool hdcp_content_type)
-{
- struct drm_device *dev = connector->dev;
- struct drm_property *prop =
- dev->mode_config.content_protection_property;
-
- if (!prop)
- prop = drm_property_create_enum(dev, 0, "Content Protection",
- drm_cp_enum_list,
- ARRAY_SIZE(drm_cp_enum_list));
- if (!prop)
- return -ENOMEM;
-
- drm_object_attach_property(&connector->base, prop,
- DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
- dev->mode_config.content_protection_property = prop;
-
- if (!hdcp_content_type)
- return 0;
-
- prop = dev->mode_config.hdcp_content_type_property;
- if (!prop)
- prop = drm_property_create_enum(dev, 0, "HDCP Content Type",
- drm_hdcp_content_type_enum_list,
- ARRAY_SIZE(
- drm_hdcp_content_type_enum_list));
- if (!prop)
- return -ENOMEM;
-
- drm_object_attach_property(&connector->base, prop,
- DRM_MODE_HDCP_CONTENT_TYPE0);
- dev->mode_config.hdcp_content_type_property = prop;
-
- return 0;
-}
-EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
-
/**
* drm_mode_create_aspect_ratio_property - create aspect ratio property
* @dev: DRM device
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 2f0367d6be64..c1483862c87c 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -15,6 +15,10 @@
#include <drm/drm_hdcp.h>
#include <drm/drm_sysfs.h>
#include <drm/drm_print.h>
+#include <drm/drm_property.h>
+#include <drm/drm_mode_object.h>
+#include <drm/drm_device.h>
+#include <drm/drm_connector.h>
struct hdcp_srm {
u8 *srm_buf;
@@ -349,3 +353,81 @@ void drm_teardown_hdcp_srm(struct class *drm_class)
class_remove_bin_file(drm_class, &srm_attrs);
}
+
+static struct drm_prop_enum_list drm_cp_enum_list[] = {
+ { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
+ { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+ { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+
+static struct drm_prop_enum_list drm_hdcp_content_type_enum_list[] = {
+ { DRM_MODE_HDCP_CONTENT_TYPE0, "HDCP Type0" },
+ { DRM_MODE_HDCP_CONTENT_TYPE1, "HDCP Type1" },
+};
+DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
+ drm_hdcp_content_type_enum_list)
+
+/**
+ * drm_connector_attach_content_protection_property - attach content protection
+ * property
+ *
+ * @connector: connector to attach CP property on.
+ * @hdcp_content_type: is HDCP Content Type property needed for connector
+ *
+ * This is used to add support for content protection on select connectors.
+ * Content Protection is intentionally vague to allow for different underlying
+ * technologies, however it is most implemented by HDCP.
+ *
+ * When hdcp_content_type is true enum property called HDCP Content Type is
+ * created (if it is not already) and attached to the connector.
+ *
+ * This property is used for sending the protected content's stream type
+ * from userspace to kernel on selected connectors. Protected content provider
+ * will decide their type of their content and declare the same to kernel.
+ *
+ * Content type will be used during the HDCP 2.2 authentication.
+ * Content type will be set to &drm_connector_state.hdcp_content_type.
+ *
+ * The content protection will be set to &drm_connector_state.content_protection
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_content_protection_property(
+ struct drm_connector *connector, bool hdcp_content_type)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop =
+ dev->mode_config.content_protection_property;
+
+ if (!prop)
+ prop = drm_property_create_enum(dev, 0, "Content Protection",
+ drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
+ if (!prop)
+ return -ENOMEM;
+
+ drm_object_attach_property(&connector->base, prop,
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
+ dev->mode_config.content_protection_property = prop;
+
+ if (!hdcp_content_type)
+ return 0;
+
+ prop = dev->mode_config.hdcp_content_type_property;
+ if (!prop)
+ prop = drm_property_create_enum(dev, 0, "HDCP Content Type",
+ drm_hdcp_content_type_enum_list,
+ ARRAY_SIZE(
+ drm_hdcp_content_type_enum_list));
+ if (!prop)
+ return -ENOMEM;
+
+ drm_object_attach_property(&connector->base, prop,
+ DRM_MODE_HDCP_CONTENT_TYPE0);
+ dev->mode_config.hdcp_content_type_property = prop;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index bfa7e886fc93..ed68af1a3f8f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1308,8 +1308,6 @@ int drm_connector_attach_scaling_mode_property(struct drm_connector *connector,
u32 scaling_mode_mask);
int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector);
-int drm_connector_attach_content_protection_property(
- struct drm_connector *connector, bool hdcp_content_type);
int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
int drm_mode_create_colorspace_property(struct drm_connector *connector);
int drm_mode_create_content_type_property(struct drm_device *dev);
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 5cb21dd6797b..ba0dbb45deaa 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -298,6 +298,10 @@ struct hdcp2_srm_header {
u8 srm_gen_no;
} __packed;
+struct drm_connector;
+
bool drm_hdcp_ksvs_revocated(u8 *ksvs, u32 ksv_count);
+int drm_connector_attach_content_protection_property(
+ struct drm_connector *connector, bool hdcp_content_type);
#endif
--
2.19.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH v4 09/13] drm: uevent for connector status change
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
` (7 preceding siblings ...)
2019-04-05 8:42 ` [PATCH v4 08/13] drm/hdcp: gathering hdcp related code into drm_hdcp.c Ramalingam C
@ 2019-04-05 8:42 ` Ramalingam C
2019-04-05 8:42 ` [PATCH v4 10/13] drm/hdcp: update content protection property with uevent Ramalingam C
` (3 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:42 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
v2:
Minor fixes at KDoc comments [Daniel]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
drivers/gpu/drm/drm_sysfs.c | 31 +++++++++++++++++++++++++++++++
include/drm/drm_sysfs.h | 5 ++++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 18b1ac442997..e8f1fd73677f 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -320,6 +320,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
* Send a uevent for the DRM device specified by @dev. Currently we only
* set HOTPLUG=1 in the uevent environment, but this could be expanded to
* deal with other types of events.
+ *
+ * Any new uapi should be using the drm_sysfs_connector_status_event()
+ * for uevents on connector status change.
*/
void drm_sysfs_hotplug_event(struct drm_device *dev)
{
@@ -332,6 +335,34 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_sysfs_hotplug_event);
+/**
+ * drm_sysfs_connector_status_event - generate a DRM uevent for connector
+ * property status change
+ * @connector: connector on which property status changed
+ * @property: connector property whoes status changed.
+ *
+ * Send a uevent for the DRM device specified by @dev. Currently we
+ * set HOTPLUG=1 and connector id along with the attached property id
+ * related to the status change.
+ */
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property)
+{
+ struct drm_device *dev = connector->dev;
+ char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
+ char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
+
+ snprintf(conn_id, ARRAY_SIZE(conn_id),
+ "CONNECTOR=%u", connector->base.id);
+ snprintf(prop_id, ARRAY_SIZE(prop_id),
+ "PROPERTY=%u", property->base.id);
+
+ DRM_DEBUG("generating connector status event\n");
+
+ kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_connector_status_event);
+
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 4f311e836cdc..d454ef617b2c 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -4,10 +4,13 @@
struct drm_device;
struct device;
+struct drm_connector;
+struct drm_property;
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_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property);
#endif
--
2.19.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH v4 10/13] drm/hdcp: update content protection property with uevent
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
` (8 preceding siblings ...)
2019-04-05 8:42 ` [PATCH v4 09/13] drm: uevent for connector status change Ramalingam C
@ 2019-04-05 8:42 ` Ramalingam C
2019-04-05 8:43 ` [PATCH v4 11/13] drm/i915: update the hdcp state " Ramalingam C
` (2 subsequent siblings)
12 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:42 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel; +Cc: gwan-gyeong.mun
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
drivers/gpu/drm/drm_hdcp.c | 13 +++++++++++++
include/drm/drm_hdcp.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index c1483862c87c..38c90c053cdd 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -431,3 +431,16 @@ int drm_connector_attach_content_protection_property(
return 0;
}
EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
+
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+ u64 val)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_connector_state *state = connector->state;
+
+ WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
+ state->content_protection = val;
+ drm_sysfs_connector_status_event(connector,
+ dev->mode_config.content_protection_property);
+}
+EXPORT_SYMBOL(drm_hdcp_update_content_protection);
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index ba0dbb45deaa..f0ef42247f2c 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -303,5 +303,7 @@ struct drm_connector;
bool drm_hdcp_ksvs_revocated(u8 *ksvs, u32 ksv_count);
int drm_connector_attach_content_protection_property(
struct drm_connector *connector, bool hdcp_content_type);
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+ u64 val);
#endif
--
2.19.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH v4 11/13] drm/i915: update the hdcp state with uevent
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
` (9 preceding siblings ...)
2019-04-05 8:42 ` [PATCH v4 10/13] drm/hdcp: update content protection property with uevent Ramalingam C
@ 2019-04-05 8:43 ` Ramalingam C
2019-04-05 8:43 ` [PATCH v4 12/13] drm: Add CP downstream_info property Ramalingam C
2019-04-05 8:43 ` [PATCH v4 13/13] drm/i915: Populate downstream info for HDCP Ramalingam C
12 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:43 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel; +Cc: gwan-gyeong.mun
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
v2:
state update is moved into drm function [daniel]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
drivers/gpu/drm/i915/intel_hdcp.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
index 6982a2e6cf9a..f70f1e98e4ae 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -858,7 +858,6 @@ static void intel_hdcp_prop_work(struct work_struct *work)
prop_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
struct drm_device *dev = connector->base.dev;
- struct drm_connector_state *state;
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
mutex_lock(&hdcp->mutex);
@@ -868,10 +867,9 @@ static void intel_hdcp_prop_work(struct work_struct *work)
* those to UNDESIRED is handled by core. If value == UNDESIRED,
* we're running just after hdcp has been disabled, so just exit
*/
- if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- state = connector->base.state;
- state->content_protection = hdcp->value;
- }
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ drm_hdcp_update_content_protection(&connector->base,
+ hdcp->value);
mutex_unlock(&hdcp->mutex);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
--
2.19.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH v4 12/13] drm: Add CP downstream_info property
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
` (10 preceding siblings ...)
2019-04-05 8:43 ` [PATCH v4 11/13] drm/i915: update the hdcp state " Ramalingam C
@ 2019-04-05 8:43 ` Ramalingam C
2019-04-05 8:43 ` [PATCH v4 13/13] drm/i915: Populate downstream info for HDCP Ramalingam C
12 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:43 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel; +Cc: gwan-gyeong.mun
This patch adds a optional CP downstream info blob property to the
connectors. This enables the Userspace to read the information of HDCP
authenticated downstream topology.
Driver will update this blob with all downstream information at the
end of the authentication.
In case userspace configures this platform as repeater, then this
information is needed for the authentication with upstream HDCP
transmitter.
v2:
s/cp_downstream/content_protection_downstream [daniel]
v3:
s/content_protection_downstream/hdcp_topology [daniel]
v4:
hdcp_topology_info struct is added with explicit padding [Daniel]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 ++
drivers/gpu/drm/drm_connector.c | 20 ++++++++++
drivers/gpu/drm/drm_hdcp.c | 65 +++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 6 +++
include/drm/drm_hdcp.h | 6 +++
include/drm/drm_mode_config.h | 6 +++
include/uapi/drm/drm_mode.h | 37 ++++++++++++++++++
7 files changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index fa50fac2e952..3a1858d5730c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -826,6 +826,9 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
*val = state->content_protection;
} else if (property == config->hdcp_content_type_property) {
*val = state->hdcp_content_type;
+ } else if (property == config->hdcp_topology_property) {
+ *val = connector->hdcp_topology_blob_ptr ?
+ connector->hdcp_topology_blob_ptr->base.id : 0;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 436cf8e764cc..033ced774d37 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -246,6 +246,7 @@ int drm_connector_init(struct drm_device *dev,
mutex_init(&connector->mutex);
connector->edid_blob_ptr = NULL;
connector->tile_blob_ptr = NULL;
+ connector->hdcp_topology_blob_ptr = NULL;
connector->status = connector_status_unknown;
connector->display_info.panel_orientation =
DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
@@ -972,6 +973,25 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] = {
* authentication process. If content type is changed when
* content_protection is not UNDESIRED, then kernel will disable the HDCP
* and re-enable with new type in the same atomic commit
+ * HDCP Topology:
+ * This blob property is used to pass the HDCP downstream topology details
+ * of a HDCP encrypted connector, from kernel to userspace.
+ * This provides all required information to userspace, so that userspace
+ * can implement the HDCP repeater using the kernel as downstream ports of
+ * the repeater. as illustrated below:
+ *
+ * HDCP Repeaters
+ * +--------------------------------------------------------------+
+ * | |
+ * | | |
+ * | Userspace HDCP Receiver +-----> KMD HDCP transmitters |
+ * | (Upstream Port) <------+ (Downstream Ports) |
+ * | | |
+ * | |
+ * +--------------------------------------------------------------+
+ *
+ * Kernel will populate this blob only when the HDCP authentication is
+ * successful.
*
* max bpc:
* This range property is used by userspace to limit the bit depth. When
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 38c90c053cdd..3f57ca424a1b 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -444,3 +444,68 @@ void drm_hdcp_update_content_protection(struct drm_connector *connector,
dev->mode_config.content_protection_property);
}
EXPORT_SYMBOL(drm_hdcp_update_content_protection);
+
+/**
+ * drm_connector_attach_hdcp_topology_property - attach hdcp topology property
+ *
+ * @connector: connector to attach hdcp topology property with.
+ *
+ * This is used to add support for hdcp topology support on select connectors.
+ * When Intel platform is configured as repeater, this downstream info is used
+ * by userspace, to complete the repeater authentication of HDCP specification
+ * with upstream HDCP transmitter.
+ *
+ * The blob_id of the hdcp topology info will be set to
+ * &drm_connector_state.hdcp_topology
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_hdcp_topology_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop = dev->mode_config.hdcp_topology_property;
+
+ if (!prop)
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB |
+ DRM_MODE_PROP_IMMUTABLE,
+ "HDCP Topology", 0);
+ if (!prop)
+ return -ENOMEM;
+
+ drm_object_attach_property(&connector->base, prop, 0);
+ dev->mode_config.hdcp_topology_property = prop;
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_hdcp_topology_property);
+
+/**
+ * drm_connector_update_hdcp_topology_property - update the hdcp topology
+ * property of a connector
+ * @connector: drm connector, the topology is associated to
+ * @hdcp_topology_info: new content for the blob of hdcp_topology_property
+ *
+ * This function creates a new blob modeset object and assigns its id to the
+ * connector's hdcp_topology_property.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int
+drm_connector_update_hdcp_topology_property(struct drm_connector *connector,
+ const struct hdcp_topology_info *info)
+{
+ struct drm_device *dev = connector->dev;
+ int ret;
+
+ if (!info)
+ return -EINVAL;
+
+ ret = drm_property_replace_global_blob(dev,
+ &connector->hdcp_topology_blob_ptr,
+ sizeof(struct hdcp_topology_info),
+ info, &connector->base,
+ dev->mode_config.hdcp_topology_property);
+ return ret;
+}
+EXPORT_SYMBOL(drm_connector_update_hdcp_topology_property);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ed68af1a3f8f..66229a4bee35 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1012,6 +1012,12 @@ struct drm_connector {
/** @properties: property tracking for this connector */
struct drm_object_properties properties;
+ /**
+ * @hdcp_topology_blob_ptr: DRM BLOB pointer for hdcp downstream
+ * topology information.
+ */
+ struct drm_property_blob *hdcp_topology_blob_ptr;
+
/**
* @scaling_mode_property: Optional atomic property to control the
* upscaling. See drm_connector_attach_content_protection_property().
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index f0ef42247f2c..fdd65a14f4db 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -299,11 +299,17 @@ struct hdcp2_srm_header {
} __packed;
struct drm_connector;
+struct hdcp_topology_info;
bool drm_hdcp_ksvs_revocated(u8 *ksvs, u32 ksv_count);
int drm_connector_attach_content_protection_property(
struct drm_connector *connector, bool hdcp_content_type);
void drm_hdcp_update_content_protection(struct drm_connector *connector,
u64 val);
+int drm_connector_attach_hdcp_topology_property(
+ struct drm_connector *connector);
+int drm_connector_update_hdcp_topology_property(
+ struct drm_connector *connector,
+ const struct hdcp_topology_info *info);
#endif
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index b359b5b71eb9..4349b614fa15 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -848,6 +848,12 @@ struct drm_mode_config {
*/
struct drm_property *hdcp_content_type_property;
+ /**
+ * @hdcp_topology_property: DRM BLOB property for hdcp downstream
+ * topology information.
+ */
+ struct drm_property *hdcp_topology_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 44412e8b77cd..251865679dfc 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -214,6 +214,43 @@ extern "C" {
#define DRM_MODE_HDCP_CONTENT_TYPE0 0
#define DRM_MODE_HDCP_CONTENT_TYPE1 1
+#define DRM_MODE_HDCP_KSV_LEN 5
+#define DRM_MODE_HDCP_MAX_DEVICE_CNT 127
+#define DRM_MODE_HDCP14_IN_FORCE (1 << 0)
+#define DRM_MODE_HDCP22_IN_FORCE (1 << 1)
+
+struct hdcp_topology_info {
+ /* Version of HDCP authenticated (1.4/2.2) */
+ __u32 ver_in_force;
+
+ /* Applicable only for HDCP2.2 */
+ __u32 content_type;
+
+ /* KSV of immediate HDCP Sink. In Little-Endian Format. */
+ __u8 bksv[DRM_MODE_HDCP_KSV_LEN];
+
+ /* Whether Immediate HDCP sink is a repeater? */
+ __u8 is_repeater;
+
+ /* Depth received from immediate downstream repeater */
+ __u8 depth;
+ __u8 pad1;
+
+ /* Device count received from immediate downstream repeater */
+ __u32 device_count;
+
+ /*
+ * Max buffer required to hold ksv list received from immediate
+ * repeater. In this array first device_count * DRM_MODE_HDCP_KSV_LEN
+ * will hold the valid ksv bytes.
+ * If authentication specification is
+ * HDCP1.4 - each KSV's Bytes will be in Little-Endian format.
+ * HDCP2.2 - each KSV's Bytes will be in Big-Endian format.
+ */
+ __u8 ksv_list[DRM_MODE_HDCP_KSV_LEN * DRM_MODE_HDCP_MAX_DEVICE_CNT];
+ __u8 pad2[5];
+} __packed;
+
struct drm_mode_modeinfo {
__u32 clock;
__u16 hdisplay;
--
2.19.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH v4 13/13] drm/i915: Populate downstream info for HDCP
2019-04-05 8:42 [PATCH v4 00/13] HDCP2.2 Phase II Ramalingam C
` (11 preceding siblings ...)
2019-04-05 8:43 ` [PATCH v4 12/13] drm: Add CP downstream_info property Ramalingam C
@ 2019-04-05 8:43 ` Ramalingam C
2019-04-05 12:03 ` Ramalingam C
12 siblings, 1 reply; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 8:43 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel
Implements drm blob property content_protection_downstream_info
property on HDCP capable connectors.
Downstream topology info is gathered across authentication stages
and stored in intel_hdcp. When HDCP authentication is complete,
new blob with latest downstream topology information is updated to
content_protection_downstream_info property.
v2:
%s/cp_downstream/content_protection_downstream [daniel]
v3:
%s/content_protection_downstream/hdcp_topology [daniel]
v4:
Rebased.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
---
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_hdcp.c | 87 ++++++++++++++++++++++++++-----
include/drm/drm_hdcp.h | 1 +
3 files changed, 76 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e387e842f414..6a321a56ce42 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -482,6 +482,8 @@ struct intel_hdcp {
wait_queue_head_t cp_irq_queue;
atomic_t cp_irq_count;
int cp_irq_count_cached;
+
+ struct hdcp_topology_info *topology_info;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
index f70f1e98e4ae..6993bb9ecd0b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -490,9 +490,10 @@ int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
/* Implements Part 2 of the HDCP authorization procedure */
static
-int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
- const struct intel_hdcp_shim *shim)
+int intel_hdcp_auth_downstream(struct intel_hdcp *hdcp,
+ struct intel_digital_port *intel_dig_port)
{
+ const struct intel_hdcp_shim *shim = hdcp->shim;
u8 bstatus[2], num_downstream, *ksv_fifo;
int ret, i, tries = 3;
@@ -523,6 +524,9 @@ int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
if (num_downstream == 0)
return -EINVAL;
+ hdcp->topology_info->device_count = num_downstream;
+ hdcp->topology_info->depth = DRM_HDCP_DEPTH(bstatus[1]);
+
ksv_fifo = kcalloc(DRM_HDCP_KSV_LEN, num_downstream, GFP_KERNEL);
if (!ksv_fifo)
return -ENOMEM;
@@ -536,6 +540,8 @@ int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
return -EPERM;
}
+ memcpy(hdcp->topology_info->ksv_list, ksv_fifo,
+ num_downstream * DRM_HDCP_KSV_LEN);
/*
* When V prime mismatches, DP Spec mandates re-read of
* V prime atleast twice.
@@ -562,9 +568,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
}
/* Implements Part 1 of the HDCP authorization procedure */
-static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
- const struct intel_hdcp_shim *shim)
+static int intel_hdcp_auth(struct intel_connector *connector)
{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
@@ -635,15 +643,20 @@ static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
return -EPERM;
}
+ hdcp->topology_info->ver_in_force = DRM_MODE_HDCP14_IN_FORCE;
+ memcpy(hdcp->topology_info->bksv, bksv.shim, DRM_MODE_HDCP_KSV_LEN);
+
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
ret = shim->repeater_present(intel_dig_port, &repeater_present);
if (ret)
return ret;
- if (repeater_present)
+ if (repeater_present) {
I915_WRITE(HDCP_REP_CTL,
intel_hdcp_get_repeater_ctl(intel_dig_port));
+ hdcp->topology_info->is_repeater = true;
+ }
ret = shim->toggle_signalling(intel_dig_port, true);
if (ret)
@@ -708,7 +721,7 @@ static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
*/
if (repeater_present)
- return intel_hdcp_auth_downstream(intel_dig_port, shim);
+ return intel_hdcp_auth_downstream(hdcp, intel_dig_port);
DRM_DEBUG_KMS("HDCP is enabled (no repeater present)\n");
return 0;
@@ -739,13 +752,18 @@ static int _intel_hdcp_disable(struct intel_connector *connector)
return ret;
}
+ memset(hdcp->topology_info, 0, sizeof(struct hdcp_topology_info));
+
+ if (drm_connector_update_hdcp_topology_property(&connector->base,
+ connector->hdcp.topology_info))
+ DRM_ERROR("Downstream_info update failed.\n");
+
DRM_DEBUG_KMS("HDCP is disabled\n");
return 0;
}
static int _intel_hdcp_enable(struct intel_connector *connector)
{
- struct intel_hdcp *hdcp = &connector->hdcp;
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
int i, ret, tries = 3;
@@ -770,9 +788,13 @@ static int _intel_hdcp_enable(struct intel_connector *connector)
/* Incase of authentication failures, HDCP spec expects reauth. */
for (i = 0; i < tries; i++) {
- ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
+ ret = intel_hdcp_auth(connector);
if (!ret) {
- hdcp->hdcp_encrypted = true;
+ connector->hdcp.hdcp_encrypted = true;
+ if (drm_connector_update_hdcp_topology_property(
+ &connector->base,
+ connector->hdcp.topology_info))
+ DRM_ERROR("Downstream_info update failed.\n");
return 0;
}
@@ -1206,6 +1228,12 @@ static int hdcp2_authentication_key_exchange(struct intel_connector *connector)
return -EPERM;
}
+ hdcp->topology_info->ver_in_force = DRM_MODE_HDCP22_IN_FORCE;
+ hdcp->topology_info->content_type = hdcp->content_type;
+ memcpy(hdcp->topology_info->bksv, msgs.send_cert.cert_rx.receiver_id,
+ HDCP_2_2_RECEIVER_ID_LEN);
+ hdcp->topology_info->is_repeater = hdcp->is_repeater;
+
/*
* Here msgs.no_stored_km will hold msgs corresponding to the km
* stored also.
@@ -1397,6 +1425,11 @@ int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
return -EPERM;
}
+ hdcp->topology_info->device_count = device_cnt;
+ hdcp->topology_info->depth = HDCP_2_2_DEPTH(rx_info[0]);
+ memcpy(hdcp->topology_info->ksv_list, msgs.recvid_list.receiver_ids,
+ device_cnt * HDCP_2_2_RECEIVER_ID_LEN);
+
ret = hdcp2_verify_rep_topology_prepare_ack(connector,
&msgs.recvid_list,
&msgs.rep_ack);
@@ -1583,6 +1616,12 @@ static int _intel_hdcp2_enable(struct intel_connector *connector)
if (ret) {
DRM_DEBUG_KMS("HDCP2 Type%d Enabling Failed. (%d)\n",
hdcp->content_type, ret);
+
+ memset(hdcp->topology_info, 0,
+ sizeof(struct hdcp_topology_info));
+ drm_connector_update_hdcp_topology_property(&connector->base,
+ hdcp->topology_info);
+
return ret;
}
@@ -1590,12 +1629,16 @@ static int _intel_hdcp2_enable(struct intel_connector *connector)
connector->base.name, connector->base.base.id,
hdcp->content_type);
+ drm_connector_update_hdcp_topology_property(&connector->base,
+ hdcp->topology_info);
hdcp->hdcp2_encrypted = true;
+
return 0;
}
static int _intel_hdcp2_disable(struct intel_connector *connector)
{
+ struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being Disabled\n",
@@ -1606,8 +1649,11 @@ static int _intel_hdcp2_disable(struct intel_connector *connector)
if (hdcp2_deauthenticate_port(connector) < 0)
DRM_DEBUG_KMS("Port deauth failed.\n");
- connector->hdcp.hdcp2_encrypted = false;
+ hdcp->hdcp2_encrypted = false;
+ memset(hdcp->topology_info, 0, sizeof(struct hdcp_topology_info));
+ drm_connector_update_hdcp_topology_property(&connector->base,
+ hdcp->topology_info);
return ret;
}
@@ -1824,10 +1870,17 @@ int intel_hdcp_init(struct intel_connector *connector,
ret =
drm_connector_attach_content_protection_property(&connector->base,
hdcp->hdcp2_supported);
- if (ret) {
- hdcp->hdcp2_supported = false;
- kfree(hdcp->port_data.streams);
- return ret;
+ if (ret)
+ goto err_exit;
+
+ ret = drm_connector_attach_hdcp_topology_property(&connector->base);
+ if (ret)
+ goto err_exit;
+
+ hdcp->topology_info = kzalloc(sizeof(*hdcp->topology_info), GFP_KERNEL);
+ if (!hdcp->topology_info) {
+ ret = -ENOMEM;
+ goto err_exit;
}
hdcp->shim = shim;
@@ -1837,6 +1890,12 @@ int intel_hdcp_init(struct intel_connector *connector,
init_waitqueue_head(&hdcp->cp_irq_queue);
return 0;
+
+err_exit:
+ hdcp->hdcp2_supported = false;
+ kfree(hdcp->port_data.streams);
+
+ return ret;
}
int intel_hdcp_enable(struct intel_connector *connector, u8 content_type)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index fdd65a14f4db..330e34715aa4 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -23,6 +23,7 @@
#define DRM_HDCP_V_PRIME_PART_LEN 4
#define DRM_HDCP_V_PRIME_NUM_PARTS 5
#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x7f)
+#define DRM_HDCP_DEPTH(x) ((x) & 0x7)
#define DRM_HDCP_MAX_CASCADE_EXCEEDED(x) (x & BIT(3))
#define DRM_HDCP_MAX_DEVICE_EXCEEDED(x) (x & BIT(7))
--
2.19.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v4 13/13] drm/i915: Populate downstream info for HDCP
2019-04-05 8:43 ` [PATCH v4 13/13] drm/i915: Populate downstream info for HDCP Ramalingam C
@ 2019-04-05 12:03 ` Ramalingam C
0 siblings, 0 replies; 25+ messages in thread
From: Ramalingam C @ 2019-04-05 12:03 UTC (permalink / raw)
To: intel-gfx, dri-devel, daniel; +Cc: gwan-gyeong.mun
On 2019-04-05 at 14:13:02 +0530, Ramalingam C wrote:
> Implements drm blob property content_protection_downstream_info
> property on HDCP capable connectors.
>
> Downstream topology info is gathered across authentication stages
> and stored in intel_hdcp. When HDCP authentication is complete,
> new blob with latest downstream topology information is updated to
> content_protection_downstream_info property.
>
> v2:
> %s/cp_downstream/content_protection_downstream [daniel]
> v3:
> %s/content_protection_downstream/hdcp_topology [daniel]
> v4:
> Rebased.
Daniel,
Hope I have done enough explicit padding struct hdcp_topology_info.
Please correct me if i am still missing something.
For populating the structure for the blob, as you sugegsted this patch
is not using the separate functions. IMHO I feel usage is very minimal,
separate functions might not be justified here. Hope you are fine with
that.
-Ram
>
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> ---
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> drivers/gpu/drm/i915/intel_hdcp.c | 87 ++++++++++++++++++++++++++-----
> include/drm/drm_hdcp.h | 1 +
> 3 files changed, 76 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index e387e842f414..6a321a56ce42 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -482,6 +482,8 @@ struct intel_hdcp {
> wait_queue_head_t cp_irq_queue;
> atomic_t cp_irq_count;
> int cp_irq_count_cached;
> +
> + struct hdcp_topology_info *topology_info;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
> index f70f1e98e4ae..6993bb9ecd0b 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -490,9 +490,10 @@ int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
>
> /* Implements Part 2 of the HDCP authorization procedure */
> static
> -int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
> - const struct intel_hdcp_shim *shim)
> +int intel_hdcp_auth_downstream(struct intel_hdcp *hdcp,
> + struct intel_digital_port *intel_dig_port)
> {
> + const struct intel_hdcp_shim *shim = hdcp->shim;
> u8 bstatus[2], num_downstream, *ksv_fifo;
> int ret, i, tries = 3;
>
> @@ -523,6 +524,9 @@ int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
> if (num_downstream == 0)
> return -EINVAL;
>
> + hdcp->topology_info->device_count = num_downstream;
> + hdcp->topology_info->depth = DRM_HDCP_DEPTH(bstatus[1]);
> +
> ksv_fifo = kcalloc(DRM_HDCP_KSV_LEN, num_downstream, GFP_KERNEL);
> if (!ksv_fifo)
> return -ENOMEM;
> @@ -536,6 +540,8 @@ int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
> return -EPERM;
> }
>
> + memcpy(hdcp->topology_info->ksv_list, ksv_fifo,
> + num_downstream * DRM_HDCP_KSV_LEN);
> /*
> * When V prime mismatches, DP Spec mandates re-read of
> * V prime atleast twice.
> @@ -562,9 +568,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
> }
>
> /* Implements Part 1 of the HDCP authorization procedure */
> -static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
> - const struct intel_hdcp_shim *shim)
> +static int intel_hdcp_auth(struct intel_connector *connector)
> {
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + const struct intel_hdcp_shim *shim = hdcp->shim;
> struct drm_i915_private *dev_priv;
> enum port port;
> unsigned long r0_prime_gen_start;
> @@ -635,15 +643,20 @@ static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
> return -EPERM;
> }
>
> + hdcp->topology_info->ver_in_force = DRM_MODE_HDCP14_IN_FORCE;
> + memcpy(hdcp->topology_info->bksv, bksv.shim, DRM_MODE_HDCP_KSV_LEN);
> +
> I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
> I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
>
> ret = shim->repeater_present(intel_dig_port, &repeater_present);
> if (ret)
> return ret;
> - if (repeater_present)
> + if (repeater_present) {
> I915_WRITE(HDCP_REP_CTL,
> intel_hdcp_get_repeater_ctl(intel_dig_port));
> + hdcp->topology_info->is_repeater = true;
> + }
>
> ret = shim->toggle_signalling(intel_dig_port, true);
> if (ret)
> @@ -708,7 +721,7 @@ static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
> */
>
> if (repeater_present)
> - return intel_hdcp_auth_downstream(intel_dig_port, shim);
> + return intel_hdcp_auth_downstream(hdcp, intel_dig_port);
>
> DRM_DEBUG_KMS("HDCP is enabled (no repeater present)\n");
> return 0;
> @@ -739,13 +752,18 @@ static int _intel_hdcp_disable(struct intel_connector *connector)
> return ret;
> }
>
> + memset(hdcp->topology_info, 0, sizeof(struct hdcp_topology_info));
> +
> + if (drm_connector_update_hdcp_topology_property(&connector->base,
> + connector->hdcp.topology_info))
> + DRM_ERROR("Downstream_info update failed.\n");
> +
> DRM_DEBUG_KMS("HDCP is disabled\n");
> return 0;
> }
>
> static int _intel_hdcp_enable(struct intel_connector *connector)
> {
> - struct intel_hdcp *hdcp = &connector->hdcp;
> struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
> int i, ret, tries = 3;
>
> @@ -770,9 +788,13 @@ static int _intel_hdcp_enable(struct intel_connector *connector)
>
> /* Incase of authentication failures, HDCP spec expects reauth. */
> for (i = 0; i < tries; i++) {
> - ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
> + ret = intel_hdcp_auth(connector);
> if (!ret) {
> - hdcp->hdcp_encrypted = true;
> + connector->hdcp.hdcp_encrypted = true;
> + if (drm_connector_update_hdcp_topology_property(
> + &connector->base,
> + connector->hdcp.topology_info))
> + DRM_ERROR("Downstream_info update failed.\n");
> return 0;
> }
>
> @@ -1206,6 +1228,12 @@ static int hdcp2_authentication_key_exchange(struct intel_connector *connector)
> return -EPERM;
> }
>
> + hdcp->topology_info->ver_in_force = DRM_MODE_HDCP22_IN_FORCE;
> + hdcp->topology_info->content_type = hdcp->content_type;
> + memcpy(hdcp->topology_info->bksv, msgs.send_cert.cert_rx.receiver_id,
> + HDCP_2_2_RECEIVER_ID_LEN);
> + hdcp->topology_info->is_repeater = hdcp->is_repeater;
> +
> /*
> * Here msgs.no_stored_km will hold msgs corresponding to the km
> * stored also.
> @@ -1397,6 +1425,11 @@ int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
> return -EPERM;
> }
>
> + hdcp->topology_info->device_count = device_cnt;
> + hdcp->topology_info->depth = HDCP_2_2_DEPTH(rx_info[0]);
> + memcpy(hdcp->topology_info->ksv_list, msgs.recvid_list.receiver_ids,
> + device_cnt * HDCP_2_2_RECEIVER_ID_LEN);
> +
> ret = hdcp2_verify_rep_topology_prepare_ack(connector,
> &msgs.recvid_list,
> &msgs.rep_ack);
> @@ -1583,6 +1616,12 @@ static int _intel_hdcp2_enable(struct intel_connector *connector)
> if (ret) {
> DRM_DEBUG_KMS("HDCP2 Type%d Enabling Failed. (%d)\n",
> hdcp->content_type, ret);
> +
> + memset(hdcp->topology_info, 0,
> + sizeof(struct hdcp_topology_info));
> + drm_connector_update_hdcp_topology_property(&connector->base,
> + hdcp->topology_info);
> +
> return ret;
> }
>
> @@ -1590,12 +1629,16 @@ static int _intel_hdcp2_enable(struct intel_connector *connector)
> connector->base.name, connector->base.base.id,
> hdcp->content_type);
>
> + drm_connector_update_hdcp_topology_property(&connector->base,
> + hdcp->topology_info);
> hdcp->hdcp2_encrypted = true;
> +
> return 0;
> }
>
> static int _intel_hdcp2_disable(struct intel_connector *connector)
> {
> + struct intel_hdcp *hdcp = &connector->hdcp;
> int ret;
>
> DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being Disabled\n",
> @@ -1606,8 +1649,11 @@ static int _intel_hdcp2_disable(struct intel_connector *connector)
> if (hdcp2_deauthenticate_port(connector) < 0)
> DRM_DEBUG_KMS("Port deauth failed.\n");
>
> - connector->hdcp.hdcp2_encrypted = false;
> + hdcp->hdcp2_encrypted = false;
>
> + memset(hdcp->topology_info, 0, sizeof(struct hdcp_topology_info));
> + drm_connector_update_hdcp_topology_property(&connector->base,
> + hdcp->topology_info);
> return ret;
> }
>
> @@ -1824,10 +1870,17 @@ int intel_hdcp_init(struct intel_connector *connector,
> ret =
> drm_connector_attach_content_protection_property(&connector->base,
> hdcp->hdcp2_supported);
> - if (ret) {
> - hdcp->hdcp2_supported = false;
> - kfree(hdcp->port_data.streams);
> - return ret;
> + if (ret)
> + goto err_exit;
> +
> + ret = drm_connector_attach_hdcp_topology_property(&connector->base);
> + if (ret)
> + goto err_exit;
> +
> + hdcp->topology_info = kzalloc(sizeof(*hdcp->topology_info), GFP_KERNEL);
> + if (!hdcp->topology_info) {
> + ret = -ENOMEM;
> + goto err_exit;
> }
>
> hdcp->shim = shim;
> @@ -1837,6 +1890,12 @@ int intel_hdcp_init(struct intel_connector *connector,
> init_waitqueue_head(&hdcp->cp_irq_queue);
>
> return 0;
> +
> +err_exit:
> + hdcp->hdcp2_supported = false;
> + kfree(hdcp->port_data.streams);
> +
> + return ret;
> }
>
> int intel_hdcp_enable(struct intel_connector *connector, u8 content_type)
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index fdd65a14f4db..330e34715aa4 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -23,6 +23,7 @@
> #define DRM_HDCP_V_PRIME_PART_LEN 4
> #define DRM_HDCP_V_PRIME_NUM_PARTS 5
> #define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x7f)
> +#define DRM_HDCP_DEPTH(x) ((x) & 0x7)
> #define DRM_HDCP_MAX_CASCADE_EXCEEDED(x) (x & BIT(3))
> #define DRM_HDCP_MAX_DEVICE_EXCEEDED(x) (x & BIT(7))
>
> --
> 2.19.1
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 25+ messages in thread