From: Daniel Vetter <daniel@ffwll.ch>
To: Ramalingam C <ramalingam.c@intel.com>
Cc: daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org,
uma.shankar@intel.com, tomas.winkler@intel.com,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v8 09/35] drm/i915: Implement HDCP2.2 link integrity check
Date: Thu, 6 Dec 2018 14:41:19 +0100 [thread overview]
Message-ID: <20181206134119.GS21184@phenom.ffwll.local> (raw)
In-Reply-To: <20181206132721.GR21184@phenom.ffwll.local>
On Thu, Dec 06, 2018 at 02:27:21PM +0100, Daniel Vetter wrote:
> On Tue, Nov 27, 2018 at 04:13:07PM +0530, Ramalingam C wrote:
> > Implements the link integrity check once in 500mSec.
> >
> > Once encryption is enabled, an ongoing Link Integrity Check is
> > performed by the HDCP Receiver to check that cipher synchronization
> > is maintained between the HDCP Transmitter and the HDCP Receiver.
> >
> > On the detection of synchronization lost, the HDCP Receiver must assert
> > the corresponding bits of the RxStatus register. The Transmitter polls
> > the RxStatus register and it may initiate re-authentication.
> >
> > v2:
> > Rebased.
> > v3:
> > No Changes.
> > v4:
> > enum check_link_response is used check the link status [Uma]
> > v5:
> > Rebased as part of patch reordering.
> > v6:
> > Required members of intel_hdcp is defined [Sean Paul]
> > v7:
> > hdcp2_check_link is cancelled at required places.
> > v8:
> > Rebased for the component i/f changes.
> > Errors due to the sinks are reported as DEBUG logs.
> >
> > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > Reviewed-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 11 +++--
> > drivers/gpu/drm/i915/intel_drv.h | 5 +++
> > drivers/gpu/drm/i915/intel_hdcp.c | 83 +++++++++++++++++++++++++++++++++++-
> > include/drm/drm_hdcp.h | 8 ++++
> > 4 files changed, 103 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index e9f4e22b2a4e..fc63babce165 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15833,15 +15833,20 @@ static void intel_hpd_poll_fini(struct drm_device *dev)
> > {
> > struct intel_connector *connector;
> > struct drm_connector_list_iter conn_iter;
> > + struct intel_hdcp *hdcp;
> >
> > /* Kill all the work that may have been queued by hpd. */
> > drm_connector_list_iter_begin(dev, &conn_iter);
> > for_each_intel_connector_iter(connector, &conn_iter) {
> > + hdcp = &connector->hdcp;
> > +
> > if (connector->modeset_retry_work.func)
> > cancel_work_sync(&connector->modeset_retry_work);
> > - if (connector->hdcp.shim) {
> > - cancel_delayed_work_sync(&connector->hdcp.check_work);
> > - cancel_work_sync(&connector->hdcp.prop_work);
> > + if (hdcp->shim) {
> > + cancel_delayed_work_sync(&hdcp->check_work);
> > + cancel_work_sync(&hdcp->prop_work);
> > + if (hdcp->hdcp2_supported)
> > + cancel_delayed_work_sync(&hdcp->hdcp2_check_work);
>
> Locking of these workers is always tricky ... why can't we use the same
> worker for both checking hdcp2 and hdcp1 link status?
>
> Of course need to use the right timeout and call the right functions, but
> I think gives us less duplication in the complicated code.
Locking and also the logic to update the content protection property. I
think sharing the entire main function, and splitting to hdcp1 vs. hdcp2
in the check/enable/disable functions would be neat.
-Daniel
>
>
> > }
> > }
> > drm_connector_list_iter_end(&conn_iter);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index 24d258488efe..e6e32bf52568 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -403,6 +403,9 @@ struct intel_hdcp_shim {
> > */
> > int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
> > void *buf, size_t size);
> > +
> > + /* HDCP2.2 Link Integrity Check */
> > + int (*check_2_2_link)(struct intel_digital_port *intel_dig_port);
> > };
> >
> > struct intel_hdcp {
> > @@ -445,6 +448,8 @@ struct intel_hdcp {
> > * over re-Auth has to be triggered.
> > */
> > u32 seq_num_m;
> > +
> > + struct delayed_work hdcp2_check_work;
> > };
> >
> > struct intel_connector {
> > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
> > index 679f3c164582..98b112395a5a 100644
> > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > @@ -1626,6 +1626,81 @@ static int _intel_hdcp2_disable(struct intel_connector *connector)
> > return ret;
> > }
> >
> > +/* Implements the Link Integrity Check for HDCP2.2 */
> > +static int intel_hdcp2_check_link(struct intel_connector *connector)
> > +{
> > + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > + struct intel_hdcp *hdcp = &connector->hdcp;
> > + enum port port = connector->encoder->port;
> > +
> > + int ret = 0;
> > +
> > + if (!hdcp->shim)
> > + return -ENOENT;
>
> Why is this possible? Should we wrap it into at least a WARN_ON?
>
> > +
> > + mutex_lock(&hdcp->mutex);
> > +
> > + if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> > + goto out;
> > +
> > + if (!(I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)) {
> > + DRM_ERROR("HDCP2.2 check failed: link is not encrypted, %x\n",
> > + I915_READ(HDCP2_STATUS_DDI(port)));
> > + ret = -ENXIO;
> > + hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
> > + schedule_work(&hdcp->prop_work);
> > + goto out;
> > + }
> > +
> > + ret = hdcp->shim->check_2_2_link(intel_dig_port);
> > + if (ret == DRM_HDCP_LINK_PROTECTED) {
> > + if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
> > + hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
> > + schedule_work(&hdcp->prop_work);
> > + }
> > + goto out;
> > + }
> > +
> > + DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
> > + connector->base.name, connector->base.base.id);
> > +
> > + ret = _intel_hdcp2_disable(connector);
> > + if (ret) {
> > + DRM_ERROR("[%s:%d] Failed to disable hdcp2.2 (%d)\n",
> > + connector->base.name, connector->base.base.id, ret);
> > + hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
> > + schedule_work(&hdcp->prop_work);
> > + goto out;
> > + }
> > +
> > + ret = _intel_hdcp2_enable(connector);
> > + if (ret) {
> > + DRM_DEBUG_KMS("[%s:%d] Failed to enable hdcp2.2 (%d)\n",
> > + connector->base.name, connector->base.base.id,
> > + ret);
> > + hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
> > + schedule_work(&hdcp->prop_work);
> > + goto out;
> > + }
> > +
> > +out:
> > + mutex_unlock(&hdcp->mutex);
> > + return ret;
> > +}
> > +
> > +static void intel_hdcp2_check_work(struct work_struct *work)
> > +{
> > + struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
> > + struct intel_hdcp,
> > + hdcp2_check_work);
> > + struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
> > +
> > + if (!intel_hdcp2_check_link(connector))
> > + schedule_delayed_work(&hdcp->hdcp2_check_work,
> > + DRM_HDCP2_CHECK_PERIOD_MS);
> > +}
> > +
> > static int i915_hdcp_component_master_bind(struct device *dev)
> > {
> > struct drm_i915_private *dev_priv = kdev_to_i915(dev);
> > @@ -1762,6 +1837,7 @@ static void intel_hdcp2_init(struct intel_connector *connector)
> > return;
> > }
> >
> > + INIT_DELAYED_WORK(&hdcp->hdcp2_check_work, intel_hdcp2_check_work);
> > hdcp->hdcp2_supported = 1;
> > }
> >
> > @@ -1836,8 +1912,12 @@ int intel_hdcp_enable(struct intel_connector *connector)
> > * Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
> > * is capable of HDCP2.2, it is preferred to use HDCP2.2.
> > */
> > - if (intel_hdcp2_capable(connector))
> > + if (intel_hdcp2_capable(connector)) {
> > ret = _intel_hdcp2_enable(connector);
> > + if (!ret)
> > + schedule_delayed_work(&hdcp->hdcp2_check_work,
> > + DRM_HDCP2_CHECK_PERIOD_MS);
> > + }
> >
> > /* When HDCP2.2 fails, HDCP1.4 will be attempted */
> > if (ret && intel_hdcp_capable(connector)) {
> > @@ -1876,6 +1956,7 @@ int intel_hdcp_disable(struct intel_connector *connector)
> >
> > mutex_unlock(&hdcp->mutex);
> > cancel_delayed_work_sync(&hdcp->check_work);
> > + cancel_delayed_work_sync(&hdcp->hdcp2_check_work);
> > return ret;
> > }
> >
> > diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> > index 3e45a7618ab3..be07a2b56d23 100644
> > --- a/include/drm/drm_hdcp.h
> > +++ b/include/drm/drm_hdcp.h
> > @@ -11,6 +11,14 @@
> >
> > /* Period of hdcp checks (to ensure we're still authenticated) */
> > #define DRM_HDCP_CHECK_PERIOD_MS (128 * 16)
> > +#define DRM_HDCP2_CHECK_PERIOD_MS 500
> > +
> > +enum check_link_response {
> > + DRM_HDCP_LINK_PROTECTED = 0,
> > + DRM_HDCP_TOPOLOGY_CHANGE,
> > + DRM_HDCP_LINK_INTEGRITY_FAILURE,
> > + DRM_HDCP_REAUTH_REQUEST
> > +};
>
> The drm_hdcp.h changes need to be all split out into sepearate patches I
> think. Just for highlighting of the new shared bits. Also applies to the
> previous one.
>
> Otherwise looks all reasonable.
> -Daniel
>
>
> >
> > /* Shared lengths/masks between HDMI/DVI/DisplayPort */
> > #define DRM_HDCP_AN_LEN 8
> > --
> > 2.7.4
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-12-06 13:41 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-27 10:42 [PATCH v8 00/35] drm/i915: Implement HDCP2.2 Ramalingam C
2018-11-27 10:42 ` [PATCH v8 01/35] drm/i915: debug log for REPLY_ACK missing Ramalingam C
2018-11-27 10:43 ` [PATCH v8 02/35] drm/i915: Increase timeout for Encrypt status change Ramalingam C
2018-11-27 10:43 ` [PATCH v8 03/35] linux/mei: Header for mei_hdcp driver interface Ramalingam C
2018-12-07 13:53 ` C, Ramalingam
2018-12-07 14:10 ` Daniel Vetter
2018-12-08 20:15 ` Winkler, Tomas
2018-12-10 9:31 ` Daniel Vetter
2018-11-27 10:43 ` [PATCH v8 04/35] drm/i915: Initialize HDCP2.2 Ramalingam C
2018-12-06 10:03 ` Daniel Vetter
2018-12-07 4:54 ` C, Ramalingam
2018-12-07 14:16 ` Daniel Vetter
2018-12-08 18:47 ` Winkler, Tomas
2018-12-10 9:28 ` Daniel Vetter
2018-11-27 10:43 ` [PATCH v8 05/35] drm/i915: MEI interface definition Ramalingam C
2018-12-06 10:23 ` Daniel Vetter
2018-12-07 5:52 ` C, Ramalingam
2018-12-07 10:48 ` C, Ramalingam
2018-12-07 10:48 ` C, Ramalingam
2018-12-07 14:32 ` Daniel Vetter
2018-12-07 14:29 ` Daniel Vetter
2018-12-12 8:58 ` C, Ramalingam
2018-12-12 10:38 ` Daniel Vetter
2018-12-12 11:04 ` C, Ramalingam
2018-12-13 3:55 ` C, Ramalingam
2018-11-27 10:43 ` [PATCH v8 06/35] drm/i915: Enable and Disable of HDCP2.2 Ramalingam C
2018-12-06 10:30 ` Daniel Vetter
2018-12-07 6:22 ` C, Ramalingam
2018-12-07 14:33 ` Daniel Vetter
2018-11-27 10:43 ` [PATCH v8 07/35] drm/i915: Implement HDCP2.2 receiver authentication Ramalingam C
2018-11-27 10:43 ` [PATCH v8 08/35] drm/i915: Implement HDCP2.2 repeater authentication Ramalingam C
2018-12-06 10:45 ` Daniel Vetter
2018-12-12 9:11 ` C, Ramalingam
2018-11-27 10:43 ` [PATCH v8 09/35] drm/i915: Implement HDCP2.2 link integrity check Ramalingam C
2018-12-06 13:27 ` Daniel Vetter
2018-12-06 13:41 ` Daniel Vetter [this message]
2018-12-07 6:46 ` C, Ramalingam
2018-12-07 14:36 ` Daniel Vetter
2018-11-27 10:43 ` [PATCH v8 10/35] drm/i915: Handle HDCP2.2 downstream topology change Ramalingam C
2018-12-06 13:42 ` Daniel Vetter
2018-11-27 10:43 ` [PATCH v8 11/35] drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ Ramalingam C
2018-12-06 13:44 ` Daniel Vetter
2018-11-27 10:43 ` [PATCH v8 12/35] drm/i915: Implement the HDCP2.2 support for DP Ramalingam C
2018-11-27 16:54 ` Bloomfield, Jon
2018-11-27 17:37 ` Daniel Vetter
2018-11-28 5:15 ` C, Ramalingam
2018-11-28 5:26 ` Stéphane Marchesin
2018-11-28 7:24 ` C, Ramalingam
2018-12-06 13:58 ` Daniel Vetter
2018-11-27 10:43 ` [PATCH v8 13/35] drm/i915: Implement the HDCP2.2 support for HDMI Ramalingam C
2018-12-06 14:04 ` Daniel Vetter
2018-11-27 10:43 ` [PATCH v8 14/35] drm/i915: Add HDCP2.2 support for DP connectors Ramalingam C
2018-11-27 10:43 ` [PATCH v8 15/35] drm/i915: Add HDCP2.2 support for HDMI connectors Ramalingam C
2018-11-27 10:43 ` [PATCH v8 16/35] mei: bus: whitelist hdcp client Ramalingam C
2018-11-27 10:43 ` [PATCH v8 17/35] mei: bus: export to_mei_cl_device for mei client device drivers Ramalingam C
2018-11-27 10:43 ` [PATCH v8 18/35] misc/mei/hdcp: Client driver for HDCP application Ramalingam C
2018-11-27 10:43 ` [PATCH v8 19/35] misc/mei/hdcp: Define ME FW interface for HDCP2.2 Ramalingam C
2018-11-27 10:43 ` [PATCH v8 20/35] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session Ramalingam C
2018-11-27 10:43 ` [PATCH v8 21/35] misc/mei/hdcp: Verify Receiver Cert and prepare km Ramalingam C
2018-11-27 10:43 ` [PATCH v8 22/35] misc/mei/hdcp: Verify H_prime Ramalingam C
2018-11-27 10:43 ` [PATCH v8 23/35] misc/mei/hdcp: Store the HDCP Pairing info Ramalingam C
2018-11-27 10:43 ` [PATCH v8 24/35] misc/mei/hdcp: Initiate Locality check Ramalingam C
2018-11-27 10:43 ` [PATCH v8 25/35] misc/mei/hdcp: Verify L_prime Ramalingam C
2018-11-27 10:43 ` [PATCH v8 26/35] misc/mei/hdcp: Prepare Session Key Ramalingam C
2018-11-27 10:43 ` [PATCH v8 27/35] misc/mei/hdcp: Repeater topology verification and ack Ramalingam C
2018-11-27 10:43 ` [PATCH v8 28/35] misc/mei/hdcp: Verify M_prime Ramalingam C
2018-11-27 10:43 ` [PATCH v8 29/35] misc/mei/hdcp: Enabling the HDCP authentication Ramalingam C
2018-11-27 10:43 ` [PATCH v8 30/35] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session Ramalingam C
2018-11-27 10:43 ` [PATCH v8 31/35] misc/mei/hdcp: Component framework for I915 Interface Ramalingam C
2018-11-27 10:43 ` [PATCH v8 32/35] drm/i915: Commit CP without modeset Ramalingam C
2018-12-06 14:19 ` Daniel Vetter
2018-11-27 10:43 ` [PATCH v8 33/35] drm/i915: Fix KBL HDCP2.2 encrypt status signalling Ramalingam C
2018-12-06 14:20 ` Daniel Vetter
2018-12-07 7:03 ` C, Ramalingam
2018-11-27 10:43 ` [PATCH v8 34/35] FOR_TEST: i915/Kconfig: Select mei_hdcp by I915 Ramalingam C
2018-11-27 10:43 ` [PATCH v8 35/35] FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4 Ramalingam C
2018-12-06 14:27 ` [PATCH v8 00/35] drm/i915: Implement HDCP2.2 Daniel Vetter
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=20181206134119.GS21184@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ramalingam.c@intel.com \
--cc=tomas.winkler@intel.com \
--cc=uma.shankar@intel.com \
/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