From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eunchul Kim Subject: Re: [RFC] drm/exynos: added hdcp driver for contents protection. Date: Sat, 22 Dec 2012 14:59:46 +0900 Message-ID: <50D54C52.7010908@samsung.com> References: <1356083277-11676-1-git-send-email-chulspro.kim@samsung.com> <1356083277-11676-2-git-send-email-chulspro.kim@samsung.com> <20121221115328.10a54df4@pyramind.ukuu.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by gabe.freedesktop.org (Postfix) with ESMTP id 92DC7E5C1E for ; Fri, 21 Dec 2012 22:00:04 -0800 (PST) Received: from epcpsbgm2.samsung.com (epcpsbgm2 [203.254.230.27]) by mailout2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MFF005UW4O25Y60@mailout2.samsung.com> for dri-devel@lists.freedesktop.org; Sat, 22 Dec 2012 15:00:02 +0900 (KST) Received: from [10.90.54.32] by mmp2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0MFF00BW14NNZT10@mmp2.samsung.com> for dri-devel@lists.freedesktop.org; Sat, 22 Dec 2012 15:00:02 +0900 (KST) In-reply-to: <20121221115328.10a54df4@pyramind.ukuu.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Alan Cox Cc: jy0.jeon@samsung.com, sw0312.kim@samsung.com, jaejoon.seo@samsung.com, dri-devel@lists.freedesktop.org, kyungmin.park@samsung.com, jmock.shin@samsung.com, lsmin.lee@samsung.com, th908.kim@samsung.com List-Id: dri-devel@lists.freedesktop.org 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 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 >> + * >> + * 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 >