All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramalingam C <ramalingam.c@intel.com>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v11 1/6] drm: Add Content protection type property
Date: Thu, 1 Aug 2019 15:48:42 +0530	[thread overview]
Message-ID: <20190801101841.GB16303@intel.com> (raw)
In-Reply-To: <20190801130502.1a4d4a4e@ferris.localdomain>

On 2019-08-01 at 13:05:02 +0300, Pekka Paalanen wrote:
> On Mon, 29 Jul 2019 15:03:16 +0530
> Ramalingam C <ramalingam.c@intel.com> wrote:
> 
> > On 2019-07-29 at 17:20:40 +0300, Pekka Paalanen wrote:
> > > On Sun, 14 Jul 2019 16:30:08 +0530
> > > Ramalingam C <ramalingam.c@intel.com> wrote:
> > >   
> > > > This patch adds a DRM ENUM property to the selected connectors.
> > > > This property is used for mentioning the protected content's type
> > > > from userspace to kernel HDCP authentication.
> > > > 
> > > > Type of the stream is decided by the protected content providers.
> > > > Type 0 content can be rendered on any HDCP protected display wires.
> > > > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> > > > 
> > > > So when a userspace sets this property to Type 1 and starts the HDCP
> > > > enable, kernel will honour it only if HDCP2.2 authentication is through
> > > > for type 1. Else HDCP enable will be failed.
> > > > 
> > > > Need ACK for this new conenctor property from userspace consumer.
> > > > 
> > > > v2:
> > > >   cp_content_type is replaced with content_protection_type [daniel]
> > > >   check at atomic_set_property is removed [Maarten]
> > > > v3:
> > > >   %s/content_protection_type/hdcp_content_type [Pekka]
> > > > v4:
> > > >   property is created for the first requested connector and then reused.
> > > > 	[Danvet]
> > > > v5:
> > > >   kernel doc nits addressed [Daniel]
> > > >   Rebased as part of patch reordering.
> > > > v6:
> > > >   Kernel docs are modified [pekka]
> > > > v7:
> > > >   More details in Kernel docs. [pekka]
> > > > v8:
> > > >   Few more clarification into kernel doc of content type [pekka]
> > > > v9:
> > > >   Small fixes in coding style.
> > > > 
> > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > ---
> > > >  drivers/gpu/drm/drm_atomic_uapi.c         |  4 ++
> > > >  drivers/gpu/drm/drm_connector.c           | 51 +++++++++++++++++++++++
> > > >  drivers/gpu/drm/drm_hdcp.c                | 36 +++++++++++++++-
> > > >  drivers/gpu/drm/i915/display/intel_hdcp.c |  4 +-
> > > >  include/drm/drm_connector.h               |  7 ++++
> > > >  include/drm/drm_hdcp.h                    |  2 +-
> > > >  include/drm/drm_mode_config.h             |  6 +++
> > > >  include/uapi/drm/drm_mode.h               |  4 ++
> > > >  8 files changed, 111 insertions(+), 3 deletions(-)  
> > > 
> > > 
> > > Snip - sorry, gmail simply refuses to deliver my mail without trimming
> > > it hard.
> > >   
> > > >  
> > > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > > index 5ab331e5dc23..5c954394093f 100644
> > > > --- a/include/uapi/drm/drm_mode.h
> > > > +++ b/include/uapi/drm/drm_mode.h
> > > > @@ -218,6 +218,10 @@ extern "C" {
> > > >  #define DRM_MODE_CONTENT_PROTECTION_DESIRED     1
> > > >  #define DRM_MODE_CONTENT_PROTECTION_ENABLED     2
> > > >  
> > > > +/* Content Type classification for HDCP2.2 vs others */
> > > > +#define DRM_MODE_HDCP_CONTENT_TYPE0		0
> > > > +#define DRM_MODE_HDCP_CONTENT_TYPE1		1  
> > > 
> > > Hi,
> > > 
> > > I still believe that these definitions do not belong in the uapi
> > > header. Userspace must use the string names instead.
> > > 
> > > Otherwise the patch looks fine, though my Weston review is still
> > > on-going.  
> > 
> > I assume that still we need to wait for the weston review completion.
> > 
> > Hence I request you to respond here once you are comfortable with this new uAPI.
> 
> Hi,
> 
> yes.
> 
> I have completed the Weston DRM-backend review in
> https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and
> the UAPI for HDCP 2.2 looks good. That Weston MR has some other
> not-UAPI-related bits I need to read through still, but they have
> no impact on the UAPI. The userspace is accepted in Weston.
> 
> I am also happy with the documentation in these kernel patches.
> 
> Therefore, with DRM_MODE_HDCP_CONTENT_TYPE0 and
> DRM_MODE_HDCP_CONTENT_TYPE1 removed from the kernel UAPI headers,
> for the kernel documentation and userspace consumer in Weston I
> give for these HDCP 2.2 Phase II kernel patches:
> 
> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Thank you pq.

I will remove those macros from uAPI header as weston dont need it.
And use your Acked-by for all the patches in the series.

BR,
-Ram

> 
> Let me know, preferably as a comment in the Weston MR, when the
> kernel patches have landed in the appropriate git tree to unblock
> merging in Weston, please.
> 
> 
> Thanks,
> pq


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-08-01 10:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-12  7:00 [PATCH v10 0/6] HDCP2.2 Phase II Ramalingam C
2019-07-12  7:00 ` [PATCH v10 1/6] drm: Add Content protection type property Ramalingam C
2019-07-14 11:00   ` [PATCH v11 " Ramalingam C
2019-07-29 14:20     ` Pekka Paalanen
2019-07-29  9:33       ` Ramalingam C
2019-08-01 10:05         ` Pekka Paalanen
2019-08-01 10:18           ` Ramalingam C [this message]
2019-07-12  7:00 ` [PATCH v10 2/6] drm/i915: Attach content " Ramalingam C
2019-07-12  7:00 ` [PATCH v10 3/6] drm: uevent for connector status change Ramalingam C
2019-07-12  7:00 ` [PATCH v10 4/6] drm/hdcp: update content protection property with uevent Ramalingam C
2019-07-12  7:00 ` [PATCH v10 5/6] drm/i915: update the hdcp state " Ramalingam C
2019-07-12  7:00 ` [PATCH v10 6/6] drm/hdcp: reference for srm file format Ramalingam C
2019-08-01 10:36   ` Sharma, Shashank
2019-08-01 10:43     ` Ramalingam C
2019-07-12 17:48 ` ✗ Fi.CI.CHECKPATCH: warning for HDCP2.2 Phase II (rev12) Patchwork
2019-07-12 18:07 ` ✓ Fi.CI.BAT: success " Patchwork
2019-07-14  9:25 ` ✓ Fi.CI.IGT: " Patchwork
2019-07-14 18:05 ` ✗ Fi.CI.CHECKPATCH: warning for HDCP2.2 Phase II (rev13) Patchwork
2019-07-14 18:24 ` ✓ Fi.CI.BAT: success " Patchwork
2019-07-15  3:09 ` ✓ Fi.CI.IGT: " Patchwork

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=20190801101841.GB16303@intel.com \
    --to=ramalingam.c@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ppaalanen@gmail.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.