Re: [RFC 1/6] cec: add new driver for cec support.
On 12/23/2014 03:32 PM, Kamil Debski wrote:
From: Hans Verkuil hansv...@cisco.com
Add the CEC framework.
Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil]
[k.deb...@samsung.com: Merged Update author commit by Hans Verkuil]
[k.deb...@samsung.com: change kthread handling when setting logical
address]
[k.deb...@samsung.com: code cleanup]
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
cec-rfc.txt | 319 ++
cec.txt | 40 ++
drivers/media/Kconfig|5 +
drivers/media/Makefile |2 +
drivers/media/cec.c | 1048
++
include/media/cec.h | 129 ++
include/uapi/linux/cec.h | 222 ++
7 files changed, 1765 insertions(+)
create mode 100644 cec-rfc.txt
create mode 100644 cec.txt
create mode 100644 drivers/media/cec.c
create mode 100644 include/media/cec.h
create mode 100644 include/uapi/linux/cec.h
...
diff --git a/include/uapi/linux/cec.h b/include/uapi/linux/cec.h
new file mode 100644
index 000..a2c78d7
--- /dev/null
+++ b/include/uapi/linux/cec.h
@@ -0,0 +1,222 @@
+#ifndef _CEC_H
+#define _CEC_H
+
+#include linux/types.h
+
+struct cec_msg {
+ __u32 len;
+ __u8 msg[16];
+ __u32 status;
+ /* If non-zero, then wait for a reply with this opcode.
+If there was an error when sending the msg or FeatureAbort
+was returned, then reply is set to 0.
+If reply is non-zero upon return, then len/msg are set to
+the received message.
+If reply is zero upon return and status has the
CEC_TX_STATUS_FEATURE_ABORT
+bit set, then len/msg are set to the received feature abort message.
+If reply is zero upon return and status has the
CEC_TX_STATUS_REPLY_TIMEOUT
+bit set, then no reply was seen at all.
+This field is ignored with CEC_RECEIVE.
+If reply is non-zero for CEC_TRANSMIT and the message is a broadcast,
+then -EINVAL is returned.
+if reply is non-zero, then timeout is set to 1000 (the required
maximum
+response time).
+ */
+ __u8 reply;
+ /* timeout (in ms) is used to timeout CEC_RECEIVE.
+Set to 0 if you want to wait forever. */
+ __u32 timeout;
+ struct timespec ts;
+};
+
+static inline __u8 cec_msg_initiator(const struct cec_msg *msg)
+{
+ return msg-msg[0] 4;
+}
+
+static inline __u8 cec_msg_destination(const struct cec_msg *msg)
+{
+ return msg-msg[0] 0xf;
+}
+
+static inline bool cec_msg_is_broadcast(const struct cec_msg *msg)
+{
+ return (msg-msg[0] 0xf) == 0xf;
+}
+
+/* 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)
+
+#define CEC_LOG_ADDR_INVALID 0xff
+
+// The maximum number of logical addresses one device can be assigned to.
+// The CEC 2.0 spec allows for only 2 logical addresses at the moment. The
+// Analog Devices CEC hardware supports 3. So let's go wild and go for 4.
+#define CEC_MAX_LOG_ADDRS 4
+
+// You are in a maze of twisty little defines, all alike
+// What were they thinking of when they came up with this mess...
+
+// The Primary Device Type
+#define CEC_PRIM_DEVTYPE_TV 0
+#define CEC_PRIM_DEVTYPE_RECORD 1
+#define CEC_PRIM_DEVTYPE_TUNER 3
+#define CEC_PRIM_DEVTYPE_PLAYBACK4
+#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM 5
+#define CEC_PRIM_DEVTYPE_SWITCH 6
+#define CEC_PRIM_DEVTYPE_VIDEOPROC 7
+
+// The All Device Types flags (CEC 2.0)
+#define CEC_FL_ALL_DEVTYPE_TV(1 7)
+#define CEC_FL_ALL_DEVTYPE_RECORD(1 6)
+#define CEC_FL_ALL_DEVTYPE_TUNER (1 5)
+#define CEC_FL_ALL_DEVTYPE_PLAYBACK (1 4)
+#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 3)
+#define CEC_FL_ALL_DEVTYPE_SWITCH(1 2)
+// And if you wondering what happened to VIDEOPROC devices: those should
+// be mapped to a SWITCH.
+
+// The logical address types that the CEC device wants to claim
+#define CEC_LOG_ADDR_TYPE_TV 0
+#define CEC_LOG_ADDR_TYPE_RECORD 1
+#define CEC_LOG_ADDR_TYPE_TUNER 2
+#define CEC_LOG_ADDR_TYPE_PLAYBACK 3
+#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM4
+#define CEC_LOG_ADDR_TYPE_SPECIFIC 5
+#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6
+// Switches should use UNREGISTERED.
+// Video processors should use SPECIFIC.
+
+// The CEC version
+#define CEC_VERSION_1_4B 5
+#define CEC_VERSION_2_0 6
+
+struct cec_event {
+ __u32 event;
+ struct timespec ts;
+};
+
+/* Userspace has to configure the adapter state (enable/disable) */
+#define CEC_CAP_STATE
Re: [RFC 1/6] cec: add new driver for cec support.
On 12/23/2014 03:32 PM, Kamil Debski wrote: From: Hans Verkuil hansv...@cisco.com Add the CEC framework. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] [k.deb...@samsung.com: change kthread handling when setting logical address] [k.deb...@samsung.com: code cleanup] Signed-off-by: Kamil Debski k.deb...@samsung.com --- cec-rfc.txt | 319 ++ cec.txt | 40 ++ A note regarding these text files: cec-rfc.txt should go to Documentation/cec.txt. I'm not sure if it is up to date (Kamil, did you check?). The cec.txt file is basically a bunch of notes to myself when I was working on this. It contains some of the not-so-obvious CEC protocol specifications. It should either be deleted for the final version of this patch series, or it should be merged with cec-rfc.txt. 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: [RFC 1/6] cec: add new driver for cec support.
Hi Sean, -Original Message- From: Sean Young [mailto:s...@mess.org] Sent: Tuesday, December 30, 2014 2:33 PM To: Kamil Debski Cc: dri-de...@lists.freedesktop.org; linux-media@vger.kernel.org; m.szyprow...@samsung.com; mche...@osg.samsung.com; hverk...@xs4all.nl; kyungmin.p...@samsung.com; Hans Verkuil Subject: Re: [RFC 1/6] cec: add new driver for cec support. On Tue, Dec 23, 2014 at 03:32:17PM +0100, Kamil Debski wrote: +There are still a few todo's, the main one being the remote control +support feature of CEC. I need to research if that should be +implemented via the standard kernel remote control support. I guess a new rc driver type RC_DRIVER_CEC should be introduced (existing types are RC_DRIVER_IR_RAW and RC_DRIVER_SCANCODE). rc_register_device() should not register the sysfs attributes specific for IR, but register sysfs attributes for cec like a link to the device. In addition there should be a new rc_type protocol RC_TYPE_CEC; now rc_keydown_notimeout() can be called for each key press. I guess a new keymap should exist too. Thank you for your suggestions. They are surely helpful and I agree with them. Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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: [RFC 1/6] cec: add new driver for cec support.
On Tue, Dec 23, 2014 at 03:32:17PM +0100, Kamil Debski wrote: +There are still a few todo's, the main one being the remote control support +feature of CEC. I need to research if that should be implemented via the +standard kernel remote control support. I guess a new rc driver type RC_DRIVER_CEC should be introduced (existing types are RC_DRIVER_IR_RAW and RC_DRIVER_SCANCODE). rc_register_device() should not register the sysfs attributes specific for IR, but register sysfs attributes for cec like a link to the device. In addition there should be a new rc_type protocol RC_TYPE_CEC; now rc_keydown_notimeout() can be called for each key press. I guess a new keymap should exist too. HTH Sean -- 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
[RFC 1/6] cec: add new driver for cec support.
From: Hans Verkuil hansv...@cisco.com Add the CEC framework. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] [k.deb...@samsung.com: change kthread handling when setting logical address] [k.deb...@samsung.com: code cleanup] Signed-off-by: Kamil Debski k.deb...@samsung.com --- cec-rfc.txt | 319 ++ cec.txt | 40 ++ drivers/media/Kconfig|5 + drivers/media/Makefile |2 + drivers/media/cec.c | 1048 ++ include/media/cec.h | 129 ++ include/uapi/linux/cec.h | 222 ++ 7 files changed, 1765 insertions(+) create mode 100644 cec-rfc.txt create mode 100644 cec.txt create mode 100644 drivers/media/cec.c create mode 100644 include/media/cec.h create mode 100644 include/uapi/linux/cec.h diff --git a/cec-rfc.txt b/cec-rfc.txt new file mode 100644 index 000..a5b7405 --- /dev/null +++ b/cec-rfc.txt @@ -0,0 +1,319 @@ +RFC CEC Kernel Support +== + +Almost three years ago an initial RFC for HDMI CEC support was posted: + +http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/29747 + +Since that time this work has stalled: partially due to lack of time, but +also because the approach had to be changed due to HDMI 1.4b requirements +and new insights in how this should be implemented. + +The original RFC exposed just the low-level CEC layer (sending and receiving +messages) and relied on userspace to actually implement the higher protocol +levels. + +However, some of the CEC features such as the Standby feature but also +messages relating to audio (both HDMI audio and the Audio Return Channel), +ethernet and CDC (Capability Discovery and Control) all have aspects that +require direct kernel control. I.e., if a standby message is received, then +you might want to handle that in the driver and not have to rely on userspace. +And if ARC and/or ethernet is supported then even the hotplug signal is +going to be sent as a CEC CDC message instead of actually toggling the +hotplug pin. + +What part of the CEC features exactly needs to be implemented in the kernel +will depend entirely on the particular product. You might want to implement +almost everything in userspace for a CEC USB dongle that allows you to +control the CEC pin, you might want to implement everything in the kernel if +you are dealing with a driver for a GPU, or it can be some mix where a set +of standard commands are handled in the kernel, but with the option for +some of the commands to be handled from userspace. + +This does not make it easy to design the CEC support. Other problems are that +the CEC transmission speed is prehistoric: we are talking around 300 bits per +second. So everything has to be done asynchronously. And the protocol is one +big mess of ad-hoc decisions. Also, the CEC API can be used within different +kernel subsystems: GPUs might need it, video capture/output devices might need +it and stand-alone CEC USB dongles need it. + +The proposal has been developed for CEC version 1.4b, but the final version +of this proposal will have support for, or at the very least be prepared for +version 2.0. + +There are still a few todo's, the main one being the remote control support +feature of CEC. I need to research if that should be implemented via the +standard kernel remote control support. + +CEC Adaptor +--- + +#define CEC_LOG_ADDR_INVALID 0xff + +// The maximum number of logical addresses one device can be assigned to. +// The CEC 2.0 spec allows for only 2 logical addresses at the moment. The +// Analog Devices CEC hardware supports 3. So let's go wild and go for 4. +#define CEC_MAX_LOG_ADDRS 4 + +// You are in a maze of twisty little defines, all alike +// What were they thinking of when they came up with this mess... + +// The Primary Device Type +#define CEC_PRIM_DEVTYPE_TV0 +#define CEC_PRIM_DEVTYPE_RECORD1 +#define CEC_PRIM_DEVTYPE_TUNER 3 +#define CEC_PRIM_DEVTYPE_PLAYBACK 4 +#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM 5 +#define CEC_PRIM_DEVTYPE_SWITCH6 +#define CEC_PRIM_DEVTYPE_VIDEOPROC 7 + +// The All Device Types flags (CEC 2.0) +#define CEC_FL_ALL_DEVTYPE_TV (1 7) +#define CEC_FL_ALL_DEVTYPE_RECORD (1 6) +#define CEC_FL_ALL_DEVTYPE_TUNER (1 5) +#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1 4) +#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 3) +#define CEC_FL_ALL_DEVTYPE_SWITCH (1 2) +// And if you wondering what happened to VIDEOPROC devices: those should +// be mapped to a SWITCH. + +// The logical address types that the CEC device wants to claim +#define CEC_LOG_ADDR_TYPE_TV 0 +#define CEC_LOG_ADDR_TYPE_RECORD 1 +#define CEC_LOG_ADDR_TYPE_TUNER2 +#define CEC_LOG_ADDR_TYPE_PLAYBACK 3 +#define
