Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-13 Thread Russell King - ARM Linux 
On Mon, Oct 12, 2015 at 02:39:42PM +0200, Hans Verkuil wrote:
> On 10/12/2015 02:33 PM, Kamil Debski wrote:
> > The possible status values that are implemented in the CEC framework
> > are following:
> > 
> > +/* cec status field */
> > +#define CEC_TX_STATUS_OK   (0)
> > +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
> > +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
> > +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
> > +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
> > +#define CEC_RX_STATUS_READY(0)
> > 
> > The only two ones I could match with the Exynos CEC module status bits are
> > CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.
> > 
> > The status bits in Exynos HW are:
> > - Tx_Error
> > - Tx_Done
> > - Tx_Transferring
> > - Tx_Running
> > - Tx_Bytes_Transferred
> > 
> > - Tx_Wait
> > - Tx_Sending_Status_Bit
> > - Tx_Sending_Hdr_Blk
> > - Tx_Sending_Data_Blk
> > - Tx_Latest_Initiator
> > 
> > - Tx_Wait_SFT_Succ
> > - Tx_Wait_SFT_New
> > - Tx_Wait_SFT_Retran
> > - Tx_Retrans_Cnt
> > - Tx_ACK_Failed
> 
> So are these all intermediate states? And every transfer always ends with 
> Tx_Done or
> Tx_Error state?
> 
> It does look that way...

For the Synopsis DW CEC, I have:

Bit Field   Description
4   ERROR_INIT  An error is detected on cec line (for initiator only).
3   ARB_LOSTThe initiator losses the CEC line arbitration to a second
initiator. (specification CEC 9).
2   NACKA frame is not acknowledged in a directly addressed message.
Or a frame is negatively acknowledged in a broadcast message
(for initiator only).
0   DONEThe current transmission is successful (for initiator only).

That's about as much of a description that there is for this hardware.
Quite what comprises an "ERROR_INIT", I don't know.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-12 Thread Hans Verkuil 
On 10/06/2015 01:11 AM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
>> +cec->adap = cec_create_adapter(_cec_adap_ops, cec,
>> +CEC_NAME, CEC_CAP_STATE |
>> +CEC_CAP_PHYS_ADDR | CEC_CAP_LOG_ADDRS | CEC_CAP_IO |
>> +CEC_CAP_IS_SOURCE,
>> +0, THIS_MODULE, >dev);
>> +ret = PTR_ERR_OR_ZERO(cec->adap);
>> +if (ret)
>> +return ret;
>> +cec->adap->available_log_addrs = 1;
>> +
>> +platform_set_drvdata(pdev, cec);
>> +pm_runtime_enable(dev);
> 
> This is really not a good interface.
> 
> "cec_create_adapter" creates and registers the adapter, at which point it
> becomes available to userspace.  However, you haven't finished setting it
> up, so it's possible to nip in here and start using it before the setup
> has completed.  This needs fixing.
> 

Good point, I'll split off the registration part into a separate function.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-12 Thread Hans Verkuil 
On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
>> +if (status & CEC_STATUS_TX_DONE) {
>> +if (status & CEC_STATUS_TX_ERROR) {
>> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
>> +cec->tx = STATE_ERROR;
>> +} else {
>> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
>> +cec->tx = STATE_DONE;
>> +}
>> +s5p_clr_pending_tx(cec);
>> +}
> 
> Your CEC implementation seems to be written around the idea that there
> are only two possible outcomes from a CEC message - "done" and "error",
> which get translated to:

This code is for the Samsung exynos CEC implementation. Marek, is this all
that the exynos CEC hardware returns?

> 
>> +case STATE_DONE:
>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
>> +cec->tx = STATE_IDLE;
>> +break;
>> +case STATE_ERROR:
>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
>> +cec->tx = STATE_IDLE;
> 
> "okay" and "retry_timeout".  So, if we have an adapter which can report
> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
> Why this obscure naming - why can't we have something that uses the
> terminology in the spec?
> 

Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC 7.1.
The assumption of the CEC framework is that this is done by the CEC adapter
driver, not by the framework. So if after repeated retransmissions there is
still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
change this to _MAX_RETRIES_REACHED if you prefer.

The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-12 Thread Kamil Debski 
Hi,

On 12 October 2015 at 12:50, Hans Verkuil  wrote:
> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
>> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
>>> +if (status & CEC_STATUS_TX_DONE) {
>>> +if (status & CEC_STATUS_TX_ERROR) {
>>> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
>>> +cec->tx = STATE_ERROR;
>>> +} else {
>>> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
>>> +cec->tx = STATE_DONE;
>>> +}
>>> +s5p_clr_pending_tx(cec);
>>> +}
>>
>> Your CEC implementation seems to be written around the idea that there
>> are only two possible outcomes from a CEC message - "done" and "error",
>> which get translated to:
>
> This code is for the Samsung exynos CEC implementation. Marek, is this all
> that the exynos CEC hardware returns?

The possible status values that are implemented in the CEC framework
are following:

+/* cec status field */
+#define CEC_TX_STATUS_OK   (0)
+#define CEC_TX_STATUS_ARB_LOST (1 << 0)
+#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
+#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
+#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
+#define CEC_RX_STATUS_READY(0)

The only two ones I could match with the Exynos CEC module status bits are
CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.

The status bits in Exynos HW are:
- Tx_Error
- Tx_Done
- Tx_Transferring
- Tx_Running
- Tx_Bytes_Transferred

- Tx_Wait
- Tx_Sending_Status_Bit
- Tx_Sending_Hdr_Blk
- Tx_Sending_Data_Blk
- Tx_Latest_Initiator

- Tx_Wait_SFT_Succ
- Tx_Wait_SFT_New
- Tx_Wait_SFT_Retran
- Tx_Retrans_Cnt
- Tx_ACK_Failed

>
>>
>>> +case STATE_DONE:
>>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
>>> +cec->tx = STATE_IDLE;
>>> +break;
>>> +case STATE_ERROR:
>>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
>>> +cec->tx = STATE_IDLE;
>>
>> "okay" and "retry_timeout".  So, if we have an adapter which can report
>> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
>> Why this obscure naming - why can't we have something that uses the
>> terminology in the spec?
>>
>
> Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC 
> 7.1.
> The assumption of the CEC framework is that this is done by the CEC adapter
> driver, not by the framework. So if after repeated retransmissions there is
> still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
> change this to _MAX_RETRIES_REACHED if you prefer.
>
> The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
> for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).
>
> Regards,
>
> Hans

Best wishes,
Kamil
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-12 Thread Hans Verkuil 
On 10/12/2015 02:33 PM, Kamil Debski wrote:
> Hi,
> 
> On 12 October 2015 at 12:50, Hans Verkuil  wrote:
>> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
>>> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
 +if (status & CEC_STATUS_TX_DONE) {
 +if (status & CEC_STATUS_TX_ERROR) {
 +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
 +cec->tx = STATE_ERROR;
 +} else {
 +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
 +cec->tx = STATE_DONE;
 +}
 +s5p_clr_pending_tx(cec);
 +}
>>>
>>> Your CEC implementation seems to be written around the idea that there
>>> are only two possible outcomes from a CEC message - "done" and "error",
>>> which get translated to:
>>
>> This code is for the Samsung exynos CEC implementation. Marek, is this all
>> that the exynos CEC hardware returns?
> 
> The possible status values that are implemented in the CEC framework
> are following:
> 
> +/* cec status field */
> +#define CEC_TX_STATUS_OK   (0)
> +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
> +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
> +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
> +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
> +#define CEC_RX_STATUS_READY(0)
> 
> The only two ones I could match with the Exynos CEC module status bits are
> CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.
> 
> The status bits in Exynos HW are:
> - Tx_Error
> - Tx_Done
> - Tx_Transferring
> - Tx_Running
> - Tx_Bytes_Transferred
> 
> - Tx_Wait
> - Tx_Sending_Status_Bit
> - Tx_Sending_Hdr_Blk
> - Tx_Sending_Data_Blk
> - Tx_Latest_Initiator
> 
> - Tx_Wait_SFT_Succ
> - Tx_Wait_SFT_New
> - Tx_Wait_SFT_Retran
> - Tx_Retrans_Cnt
> - Tx_ACK_Failed

So are these all intermediate states? And every transfer always ends with 
Tx_Done or
Tx_Error state?

It does look that way...

Regards,

Hans

> 
>>
>>>
 +case STATE_DONE:
 +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
 +cec->tx = STATE_IDLE;
 +break;
 +case STATE_ERROR:
 +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
 +cec->tx = STATE_IDLE;
>>>
>>> "okay" and "retry_timeout".  So, if we have an adapter which can report
>>> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
>>> Why this obscure naming - why can't we have something that uses the
>>> terminology in the spec?
>>>
>>
>> Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC 
>> 7.1.
>> The assumption of the CEC framework is that this is done by the CEC adapter
>> driver, not by the framework. So if after repeated retransmissions there is
>> still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
>> change this to _MAX_RETRIES_REACHED if you prefer.
>>
>> The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
>> for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).
>>
>> Regards,
>>
>> Hans
> 
> Best wishes,
> Kamil
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-12 Thread Kamil Debski 
Hi,

On 12 October 2015 at 14:39, Hans Verkuil  wrote:
> On 10/12/2015 02:33 PM, Kamil Debski wrote:
>> Hi,
>>
>> On 12 October 2015 at 12:50, Hans Verkuil  wrote:
>>> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
 On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
> +if (status & CEC_STATUS_TX_DONE) {
> +if (status & CEC_STATUS_TX_ERROR) {
> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
> +cec->tx = STATE_ERROR;
> +} else {
> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
> +cec->tx = STATE_DONE;
> +}
> +s5p_clr_pending_tx(cec);
> +}

 Your CEC implementation seems to be written around the idea that there
 are only two possible outcomes from a CEC message - "done" and "error",
 which get translated to:
>>>
>>> This code is for the Samsung exynos CEC implementation. Marek, is this all
>>> that the exynos CEC hardware returns?
>>
>> The possible status values that are implemented in the CEC framework
>> are following:
>>
>> +/* cec status field */
>> +#define CEC_TX_STATUS_OK   (0)
>> +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
>> +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
>> +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
>> +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
>> +#define CEC_RX_STATUS_READY(0)
>>
>> The only two ones I could match with the Exynos CEC module status bits are
>> CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.
>>
>> The status bits in Exynos HW are:
>> - Tx_Error
>> - Tx_Done
>> - Tx_Transferring
>> - Tx_Running
>> - Tx_Bytes_Transferred
>>
>> - Tx_Wait
>> - Tx_Sending_Status_Bit
>> - Tx_Sending_Hdr_Blk
>> - Tx_Sending_Data_Blk
>> - Tx_Latest_Initiator
>>
>> - Tx_Wait_SFT_Succ
>> - Tx_Wait_SFT_New
>> - Tx_Wait_SFT_Retran
>> - Tx_Retrans_Cnt
>> - Tx_ACK_Failed
>
> So are these all intermediate states? And every transfer always ends with 
> Tx_Done or
> Tx_Error state?

Yes, the Exynos CEC module has a pretty low level status indicator.

> It does look that way...
>
> Regards,
>
> Hans
>

Best wishes,
Kamil

[snip]
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-05 Thread Russell King - ARM Linux 
On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
> + if (status & CEC_STATUS_TX_DONE) {
> + if (status & CEC_STATUS_TX_ERROR) {
> + dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
> + cec->tx = STATE_ERROR;
> + } else {
> + dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
> + cec->tx = STATE_DONE;
> + }
> + s5p_clr_pending_tx(cec);
> + }

Your CEC implementation seems to be written around the idea that there
are only two possible outcomes from a CEC message - "done" and "error",
which get translated to:

> + case STATE_DONE:
> + cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
> + cec->tx = STATE_IDLE;
> + break;
> + case STATE_ERROR:
> + cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
> + cec->tx = STATE_IDLE;

"okay" and "retry_timeout".  So, if we have an adapter which can report
(eg) a NACK, we have to report it as the obscure "retry timeout" status?
Why this obscure naming - why can't we have something that uses the
terminology in the spec?

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-05 Thread Russell King - ARM Linux 
On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
> + cec->adap = cec_create_adapter(_cec_adap_ops, cec,
> + CEC_NAME, CEC_CAP_STATE |
> + CEC_CAP_PHYS_ADDR | CEC_CAP_LOG_ADDRS | CEC_CAP_IO |
> + CEC_CAP_IS_SOURCE,
> + 0, THIS_MODULE, >dev);
> + ret = PTR_ERR_OR_ZERO(cec->adap);
> + if (ret)
> + return ret;
> + cec->adap->available_log_addrs = 1;
> +
> + platform_set_drvdata(pdev, cec);
> + pm_runtime_enable(dev);

This is really not a good interface.

"cec_create_adapter" creates and registers the adapter, at which point it
becomes available to userspace.  However, you haven't finished setting it
up, so it's possible to nip in here and start using it before the setup
has completed.  This needs fixing.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-09-07 Thread Hans Verkuil 
From: Kamil Debski 

Add CEC interface driver present in the Samsung Exynos range of
SoCs.

The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c

Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/s5p-cec.txt  |  31 +++
 drivers/media/platform/Kconfig |  12 +
 drivers/media/platform/Makefile|   1 +
 drivers/media/platform/s5p-cec/Makefile|   2 +
 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h   |  37 +++
 .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c   | 208 +++
 drivers/media/platform/s5p-cec/regs-cec.h  |  96 +++
 drivers/media/platform/s5p-cec/s5p_cec.c   | 284 +
 drivers/media/platform/s5p-cec/s5p_cec.h   |  76 ++
 9 files changed, 747 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt
 create mode 100644 drivers/media/platform/s5p-cec/Makefile
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
 create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h

diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
b/Documentation/devicetree/bindings/media/s5p-cec.txt
new file mode 100644
index 000..925ab4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -0,0 +1,31 @@
+* Samsung HDMI CEC driver
+
+The HDMI CEC module is present is Samsung SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be following
+   "samsung,s5p-cec"
+
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+  - interrupts : HDMI CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to HDMI CEC clock.
+  - clock-names : from common clock binding: must contain "hdmicec",
+ corresponding to entry in the clocks property.
+  - samsung,syscon-phandle - phandle to the PMU system controller
+
+Example:
+
+hdmicec: cec@100B {
+   compatible = "samsung,s5p-cec";
+   reg = <0x100B 0x200>;
+   interrupts = <0 114 0>;
+   clocks = < CLK_HDMI_CEC>;
+   clock-names = "hdmicec";
+   samsung,syscon-phandle = <_system_controller>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec>;
+   status = "okay";
+};
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index dc75694..58346e6 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -117,6 +117,18 @@ config VIDEO_S3C_CAMIF
 source "drivers/media/platform/soc_camera/Kconfig"
 source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/s5p-tv/Kconfig"
+
+config VIDEO_SAMSUNG_S5P_CEC
+   tristate "Samsung S5P CEC driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && (PLAT_S5P || ARCH_EXYNOS || 
COMPILE_TEST)
+   select CEC
+   default n
+   ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index efa0295..957af5f 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)   += 
m2m-deinterlace.o
 
 obj-$(CONFIG_VIDEO_S3C_CAMIF)  += s3c-camif/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)   += s5p-jpeg/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/
diff --git a/drivers/media/platform/s5p-cec/Makefile 
b/drivers/media/platform/s5p-cec/Makefile
new file mode 100644
index 000..0e2cf45
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec.o
+s5p-cec-y += s5p_cec.o exynos_hdmi_cecctrl.o
diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h 
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
new file mode 100644
index 000..d008695
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
@@ -0,0 +1,37 @@
+/* drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
+ *
+ * Copyright (c) 2010, 2014 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * Header file for interface of Samsung Exynos hdmi cec