All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Gupta <anshuman.gupta@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915/hdcp: Update CP as per the kernel internal state
Date: Tue, 28 Jan 2020 21:45:45 +0530	[thread overview]
Message-ID: <20200128161545.GF24118@intel.com> (raw)
In-Reply-To: <20200128154444.GE24118@intel.com>

On 2020-01-28 at 21:14:44 +0530, Anshuman Gupta wrote:
> On 2020-01-28 at 16:19:31 +0200, Jani Nikula wrote:
> > On Tue, 28 Jan 2020, Anshuman Gupta <anshuman.gupta@intel.com> wrote:
> > > Content Protection property should be updated as per the kernel
> > > internal state. Let's say if Content protection is disabled
> > > by userspace, CP property should be set to UNDESIRED so that
> > > reauthentication will not happen until userspace request it again,
> > > but when kernel disables the HDCP due to any DDI disabling sequences
> > > like modeset/DPMS operation, kernel should set the property to
> > > DESIRED, so that when opportunity arises, kernel will start the
> > > HDCP authentication on its own.
> > >
> > > Somewhere in the line, state machine to set content protection to
> > > DESIRED from kernel was broken and IGT coverage was missing for it.
> > > This patch fixes it.
> > > IGT patch to catch further regression on this features is being
> > > worked upon.
> > >
> > > CC: Ramalingam C <ramalingam.c@intel.com>
> > > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c |  4 +++
> > >  drivers/gpu/drm/i915/display/intel_hdcp.c    | 26 ++++++++++++++++++++
> > >  drivers/gpu/drm/i915/display/intel_hdcp.h    |  2 ++
> > >  3 files changed, 32 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> > > index da5266e76738..934cdf1f1858 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -14595,6 +14595,10 @@ static int intel_atomic_check(struct drm_device *dev,
> > >  		goto fail;
> > >  
> > >  	if (any_ms) {
> > > +		/*
> > > +		 * When there is modeset fix the hdcp uapi CP state.
> > > +		 */
> > > +		intel_hdcp_post_need_modeset_check(state);
> > >  		ret = intel_modeset_checks(state);
> > >  		if (ret)
> > >  			goto fail;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > index 0fdbd39f6641..be083136eee2 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > @@ -2074,6 +2074,32 @@ void intel_hdcp_atomic_check(struct drm_connector *connector,
> > >  	crtc_state->mode_changed = true;
> > >  }
> > >  
> > > +/**
> > > + * intel_hdcp_post_need_modeset_check.
> > > + * @state: intel atomic state.
> > > + *
> > > + * This function fix the HDCP uapi state when hdcp disabling initiated from
> > > + * modeset DDI disabling sequence. It updates uapi CP state from ENABLED to
> > > + * DESIRED so that HDCP uapi state can be restored as per HDCP Auth state.
> > > + * This function should be called only in case of in case of modeset.
> > > + * FIXME: As per HDCP content protection property uapi doc, an uevent()
> > > + * need to be sent if there is transition from ENABLED->DESIRED.
> > > + */
> > > +void intel_hdcp_post_need_modeset_check(struct intel_atomic_state *state)
> > > +{
> > > +	struct drm_connector *connector;
> > > +	struct drm_connector_state *old_state;
> > > +	struct drm_connector_state *new_state;
> > > +	int i;
> > > +
> > > +	for_each_oldnew_connector_in_state(&state->base, connector, old_state,
> > > +					   new_state, i) {
> > > +		if (old_state->content_protection == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> > > +		    new_state->content_protection != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> > > +			new_state->content_protection = DRM_MODE_CONTENT_PROTECTION_DESIRED;
> > > +	}
> > > +}
> > > +
> > 
> > Why does this feel like duplication of what you already have in
> > intel_hdcp_atomic_check()?
> intel_hdcp_atomic_check() have checks that for disconnected connector and it doesn't look for 
typo here, "intel_hdcp_atomic_check() checks that for disconnected connector and it doesn't check for new state shouldn't be UNDESIRED" 
> old state, that is not sufficient to fix the hdcp CP uapi state, it need to be fix only in case of
> modeset, Later on a fastset check can disable the modeset and we would endup calling intel_hdcp_enable
> while hdcp is already enabled. That is the reason i think we would require a new API to
> fix the uapi state.
> Thanks ,
> Anshuman Gupta.
> > 
> > BR,
> > Jani.
> > 
> > 
> > >  /* Handles the CP_IRQ raised from the DP HDCP sink */
> > >  void intel_hdcp_handle_cp_irq(struct intel_connector *connector)
> > >  {
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h b/drivers/gpu/drm/i915/display/intel_hdcp.h
> > > index f3c3272e712a..7bf46bc3c348 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
> > > @@ -13,6 +13,7 @@
> > >  struct drm_connector;
> > >  struct drm_connector_state;
> > >  struct drm_i915_private;
> > > +struct intel_atomic_state;
> > >  struct intel_connector;
> > >  struct intel_hdcp_shim;
> > >  enum port;
> > > @@ -21,6 +22,7 @@ enum transcoder;
> > >  void intel_hdcp_atomic_check(struct drm_connector *connector,
> > >  			     struct drm_connector_state *old_state,
> > >  			     struct drm_connector_state *new_state);
> > > +void intel_hdcp_post_need_modeset_check(struct intel_atomic_state *state);
> > >  int intel_hdcp_init(struct intel_connector *connector,
> > >  		    const struct intel_hdcp_shim *hdcp_shim);
> > >  int intel_hdcp_enable(struct intel_connector *connector,
> > 
> > -- 
> > Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-01-28 16:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-28 13:54 [Intel-gfx] [PATCH 0/4] HDCP Misc series Anshuman Gupta
2020-01-28 13:54 ` [Intel-gfx] [PATCH 1/4] drm/i915/hdcp: Update CP as per the kernel internal state Anshuman Gupta
2020-01-28 14:19   ` Jani Nikula
2020-01-28 15:44     ` Anshuman Gupta
2020-01-28 16:15       ` Anshuman Gupta [this message]
2020-02-05  5:07         ` Anshuman Gupta
2020-03-03 14:36           ` Maarten Lankhorst
2020-03-03 16:35             ` Anshuman Gupta
2020-03-04  8:43               ` Maarten Lankhorst
2020-03-05  5:56                 ` Anshuman Gupta
2020-01-28 13:54 ` [Intel-gfx] [PATCH 2/4] drm/i915: HDCP support on above PORT_E Anshuman Gupta
2020-01-28 14:20   ` Jani Nikula
2020-01-28 14:21     ` Jani Nikula
2020-01-29 13:26   ` [Intel-gfx] [PATCH v2 " Anshuman Gupta
2020-02-07 14:03     ` Ramalingam C
2020-01-28 13:54 ` [Intel-gfx] [PATCH 3/4] drm/i915: debugfs info print "HDCP shim isn't available" Anshuman Gupta
2020-02-07 14:13   ` Ramalingam C
2020-01-28 13:54 ` [Intel-gfx] [PATCH 4/4] drm/i915: Add HDCP2.2 capable debug print Anshuman Gupta
2020-01-28 14:23   ` Jani Nikula
2020-02-07 14:16   ` 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=20200128161545.GF24118@intel.com \
    --to=anshuman.gupta@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.