dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Ramalingam C <ramalingam.c@intel.com>
To: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	daniel@ffwll.ch, gwan-gyeong.mun@intel.com
Subject: [PATCH v5 00/12] HDCP2.2 Phase II
Date: Thu, 18 Apr 2019 14:27:53 +0530	[thread overview]
Message-ID: <20190418085805.5648-1-ramalingam.c@intel.com> (raw)

HDCP2.2 phase-II introduces below features:
	Addition of two connector properties
		HDCP Content Type
		HDCP Topology
	Addition of binary sysfs "hdcp_srm" at drm subsystem
	Parsing for HDCP1.4 and 2.2 SRM table
	Once HDCP1.4/2.2 authentication is completed gathering the all
		downstream topology for userspace 
	Extending debugfs entry to provide the HDCP2.2 capability too.
	Uevent for HDCP state change.
	Dedicated file for hdcp in drm.

HDCP Content Type:
	This property is used to indicate the content type
classification of a stream. Which indicate the HDCP version required
for the rendering of that streams. This conten type is one of the
parameter in the HDCP2.2 authentication flow, as even downstream
repeaters will mandate the HDCP version requirement.

Two values possible for content type of a stream:
	Type 0: Stream can be rendered only on HDCP encrypted link no
		restriction on HDCP versions.
	Type 1: Stream can be rendered only on HDCP2.2 encrypted link.

There is a parallel effort in #wayland community to add the support for
HDCP2.2 along with content type support. Patches are under review in
#wayland community.

HDCP Topology:
This blob property is used by the kernel to pass the downstream topology
of the HDCP encrypted port to the userspace.

This is used by the userspace to implement the HDCP repeater, which KMD
implementing the HDCP transmitters(downstream ports) and userspace
implementing the upstream port(HDCP receiver).

Discussion is on going to add the downstream_info support in the
weston HDCP stack.

hdcp_srm: write only binary sysfs used by the userspace to pass the SRM
table of HDCP1.4 and 2.2. These are nothing but revocated list of
receiver IDs of the HDCP sinks. KMD will use this list to identify the
revocated devices in the HDCP authentication and deny the hdcp encryption to it.

Daniel has suggested about moving the SRM node implementation into DRM core.
Still dome more clarification is required. Once that is done another
respin on SRM patches are expected.

v5:
  srm is read from the /lib/firmware/display_hdcp_srm.bin [danvet]
  small fix at hdcp state update to userspace.
 
Series can be cloned from github
https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_p2_v5

Test-with: <20190418084842.5422-2-ramalingam.c@intel.com>

Ramalingam C (12):
  drm: move content protection property to mode_config
  drm/i915: debugfs: HDCP2.2 capability read
  drm: Add Content protection type property
  drm/i915: Attach content type property
  drm: revocation check at drm subsystem
  drm/i915: SRM revocation check for HDCP1.4 and 2.2
  drm/hdcp: gathering hdcp related code into drm_hdcp.c
  drm: uevent for connector status change
  drm/hdcp: update content protection property with uevent
  drm/i915: update the hdcp state with uevent
  drm: Add CP downstream_info property
  drm/i915: Populate downstream info for HDCP

 drivers/gpu/drm/Makefile            |   2 +-
 drivers/gpu/drm/drm_atomic_uapi.c   |  11 +-
 drivers/gpu/drm/drm_connector.c     |  80 +++--
 drivers/gpu/drm/drm_hdcp.c          | 498 ++++++++++++++++++++++++++++
 drivers/gpu/drm/drm_internal.h      |   4 +
 drivers/gpu/drm/drm_sysfs.c         |  33 ++
 drivers/gpu/drm/i915/i915_debugfs.c |  13 +-
 drivers/gpu/drm/i915/intel_ddi.c    |  38 ++-
 drivers/gpu/drm/i915/intel_drv.h    |   2 +
 drivers/gpu/drm/i915/intel_hdcp.c   | 177 +++++++---
 drivers/gpu/drm/i915/intel_hdcp.h   |   3 +-
 include/drm/drm_connector.h         |  21 +-
 include/drm/drm_hdcp.h              |  48 +++
 include/drm/drm_mode_config.h       |  18 +
 include/drm/drm_sysfs.h             |   5 +-
 include/uapi/drm/drm_mode.h         |  41 +++
 16 files changed, 894 insertions(+), 100 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_hdcp.c

-- 
2.19.1

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

             reply	other threads:[~2019-04-18  8:57 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18  8:57 Ramalingam C [this message]
2019-04-18  8:57 ` [PATCH v5 01/12] drm: move content protection property to mode_config Ramalingam C
2019-04-23  7:38   ` Daniel Vetter
2019-04-18  8:57 ` [PATCH v5 02/12] drm/i915: debugfs: HDCP2.2 capability read Ramalingam C
2019-04-18  8:57 ` [PATCH v5 03/12] drm: Add Content protection type property Ramalingam C
2019-04-23  7:44   ` Daniel Vetter
2019-04-18  8:57 ` [PATCH v5 04/12] drm/i915: Attach content " Ramalingam C
2019-04-23  8:11   ` Daniel Vetter
2019-04-23 11:17     ` Ramalingam C
2019-04-23 12:10       ` Daniel Vetter
2019-04-18  8:57 ` [PATCH v5 05/12] drm: revocation check at drm subsystem Ramalingam C
2019-04-29  7:26   ` Daniel Vetter
2019-04-29  7:30     ` Daniel Vetter
2019-04-18  8:57 ` [PATCH v5 06/12] drm/i915: SRM revocation check for HDCP1.4 and 2.2 Ramalingam C
2019-04-29  7:28   ` Daniel Vetter
2019-04-18  8:58 ` [PATCH v5 07/12] drm/hdcp: gathering hdcp related code into drm_hdcp.c Ramalingam C
2019-04-29  7:31   ` Daniel Vetter
2019-04-18  8:58 ` [PATCH v5 08/12] drm: uevent for connector status change Ramalingam C
2019-04-29  7:33   ` Daniel Vetter
2019-04-18  8:58 ` [PATCH v5 09/12] drm/hdcp: update content protection property with uevent Ramalingam C
2019-04-29  7:35   ` Daniel Vetter
2019-04-18  8:58 ` [PATCH v5 10/12] drm/i915: update the hdcp state " Ramalingam C
2019-04-29  7:35   ` Daniel Vetter
2019-04-18  8:58 ` [PATCH v5 11/12] drm: Add CP downstream_info property Ramalingam C
2019-04-29  7:38   ` Daniel Vetter
2019-04-29 14:46     ` Ramalingam C
2019-04-18  8:58 ` [PATCH v5 12/12] drm/i915: Populate downstream info for HDCP Ramalingam C

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190418085805.5648-1-ramalingam.c@intel.com \
    --to=ramalingam.c@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gwan-gyeong.mun@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox