Re: [RFC] drm/exynos: added hdcp driver for contents protection.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank's for your advice.

Your opinion is very helpful to me.
I will consider your comments, and then I resend it.

Thank's
BR
Eunchul Kim

On 12/21/2012 08:53 PM, Alan Cox wrote:
On Fri, 21 Dec 2012 18:47:57 +0900
Eunchul Kim <chulspro.kim@xxxxxxxxxxx> wrote:

HDCP stands for High-bandwidth Digital Content Protection.
This is a newer form of Digital Rights Management(secure DRM)

was.. the master key was leaked long ago 8)

- Okay, I will change description. :)


that was designed to control digital video and audio content.
Contains an integrated HDCP encryption engine for video/audio content protection.
supports version HDCP v1.1.
Exynos AP supports embedded HDCP key system.
The HDCP key value is fused during fabrication, based on customer's request.

For this code to go into the kernel it must do so in GPL form. Can you
confirm Samsung has the necessary IPR and permissions to grant use of
this to all third parties as the GPL requires not just to specific
customers ? (whether they can use it usefully is a different question as
obviously they need the key.

I ask this because there are currently a lot of lawyers busy trying to
sue makers of some HDCP aware devices.

- I will check about your comments. thank's


+
+	dev_info(dev, "drm hdcp registered successfully.\n");

This sort of stuff ought to be dev_dbg, minor item

- changed it.



diff --git a/drivers/gpu/drm/exynos/exynos_hdcp.h b/drivers/gpu/drm/exynos/exynos_hdcp.h
new file mode 100644
index 0000000..86d0c79
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_hdcp.h
@@ -0,0 +1,47 @@
+/*
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ *
+ * Authors:
+ *	Eunchul Kim <chulspro.kim@xxxxxxxxxxx>
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */


Two things strike me here - firstly kernel code is GPLv2 or later (or
dual licensed) as per the Signed-off-by: certification. I don't see any
problem in the above but to be sure you realise.

Secondly - VA Linux systems ??? has this been copied from some random
file and not updated correctly or does the old VA Linux Systems really
own bits of this code.


- changed it.

Other questions I'll look at later - in particular
- I don't see how the work queue is locked against the main thread of
   execution within the driver

- I want to avoid that main thread is locked by I2C operation with peer device.
  The performance deteriorated when i used callback. so, I used workqueue.
I designed two kind of mechanism about this. first one is based on workqueue.
  second one is based on callback.
  I will consider one more time between synchronization and performance.

- There is a general DRI question here about HDCP and interfaces -
   several out of tree drivers do HDCP and perhaps a common API would be
   sensible ?

- I agree with your opinion.
So, I discussed with our X video driver engineer for common API internally. I think, If we provide connector property for HDCP, then DRI can control HDCP generally.
  I didn't fully implemented yet.


Alan


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


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux