| Message ID | 1551166569-19683-1-git-send-email-ramalingam.c@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | HDCP2.2 Phase II | expand |
On Tue, Feb 26, 2019 at 8:42 AM Ramalingam C <ramalingam.c@intel.com> wrote: > > HDCP2.2 phase-II mojorly adds below features: > Addition of three connector properties > CP_Content_Type > CP_SRM Not really clear why this is a connector property. Do we need different SRM for different connectors? My understanding of the spec is that we want one SRM globally (so not even per driver). I think a binary sysfs file in the drm class (in /sys/class/drm, not one of the subdirectories) would fit that. Plus make userspace simpler, since a cat srm_file > /sys/class/drm/cp_srm at boot-up is all we need. Drivers can then just check with drm core for the latest srm file at the start of each hdcp transaction, and update it if there is one. Plus maybe a few functions to do sink filtering on the cpu - I think we need that for hdcp1.x on i915 too. Other properties make sense on the connector I think. Also please spell out CP as content_protection in all the properties/interfaces, I think that would be good, in common lingo (see urban dictionary) cp has a different meaning. -Daniel > CP_Downstream_Info > parsing for HDCP1.4 and 2.2 SRM Blobs > 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. > > CP_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. > > CP_SRM: > This blob property is 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. > > Work in progress to add the SRM support in the weston HDCP stack. > Yet to publish the patches in the #wayland community. > > CP_Downstream_Info: > 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. > > Test-with: 1551165805-19130-2-git-send-email-ramalingam.c@intel.com > > Ramalingam C (10): > drm: Add CP content type property > drm/i915: Attach content type property > drm: Add CP System Renewability Msg Property > drm/i915: Add HDCP SRM Blob parsing > drm/i915: Add revocation check on HDCP1.4 Ksvs > drm/i915: SRM parsing and revocation check for HDCP2 > drm: Add CP downstream_info property > drm/i915: Populate downstream info for HDCP1.4 > drm/i915: Populate downstream info for HDCP2.2 > drm/i915: debugfs: HDCP2.2 capability read > > drivers/gpu/drm/drm_atomic_uapi.c | 23 +++ > drivers/gpu/drm/drm_connector.c | 204 ++++++++++++++++++++ > drivers/gpu/drm/i915/i915_debugfs.c | 13 +- > drivers/gpu/drm/i915/intel_ddi.c | 23 ++- > drivers/gpu/drm/i915/intel_drv.h | 11 +- > drivers/gpu/drm/i915/intel_hdcp.c | 373 ++++++++++++++++++++++++++++++++++-- > include/drm/drm_connector.h | 40 ++++ > include/drm/drm_hdcp.h | 35 ++++ > include/uapi/drm/drm_mode.h | 39 ++++ > 9 files changed, 737 insertions(+), 24 deletions(-) > > -- > 2.7.4 >