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

[Eunchul Kim <chulspro.kim@samsung.com>]

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@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@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
>