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 at samsung.com> 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 at samsung.com> >> + * >> + * 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 >
