Re: [PATCH v3 08/10] drm/i915: Populate downstream info for HDCP2.2

Ramalingam C
2019-03-27T14:49:55Z

On 2019-03-27 at 11:31:12 +0100, Daniel Vetter wrote:
> On Fri, Mar 22, 2019 at 06:14:46AM +0530, Ramalingam C wrote:
> > Populates the downstream info for HDCP2.2 encryption also. On success
> > of encryption Blob is updated.
> >
> > Additional two variable are added to downstream info blob. Such as
> > ver_in_force and content type.
> >
> > v2:
> > s/cp_downstream/content_protection_downstream [daniel]
> > v3:
> > s/content_protection_downstream/hdcp_topology [daniel]
> >
> > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_hdcp.c | 26 +++++++++++++++++++++++++-
> > include/uapi/drm/drm_mode.h | 3 +++
> > 2 files changed, 28 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
> > index 0e3d7afecd5a..1eea553cdf81 100644
> > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > @@ -1281,6 +1281,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.
> > @@ -1472,6 +1478,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);
> > @@ -1658,6 +1669,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;
> > }
> >
> > @@ -1665,12 +1682,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",
> > @@ -1681,8 +1702,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;
> > }
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 733db7283e57..22f5940a47cc 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -223,6 +223,9 @@ struct hdcp_topology_info {
> > /* Version of HDCP authenticated (1.4/2.2) */
> > __u32 ver_in_force;
> >
> > + /* Applicable only for HDCP2.2 */
> > + __u8 content_type;
>
> Even more misplaced hunks. You can't change an uapi struct once it's baked
> in.
I did this under the assumption that the whole series completes the
uAPI.
>
> Same thought as on the hdcp1 patch, perhaps we even want 2 functions: One
> for hdcp1, and one for hdcp2, to avoid the possiblity of screw-ups. After
> all this interface is fairly fragile, and supposed to work across drivers.
>
> Aside: Where's the userspace for this? Kinda wondering how an open source
> hdcp repeater implementation would even work ...
I am afraid that we wont be able to preare the userspace for the
topology property. So we wont be able upstream this new uAPI. :(

-Ram
> -Daniel
>
> > +
> > /* KSV of immediate HDCP Sink. In Little-Endian Format. */
> > char bksv[DRM_MODE_HDCP_KSV_LEN];
> >
> > --
> > 2.19.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org