Re: [RFC 1/6] cec: add new driver for cec support.

2015-01-12 Thread Hans Verkuil
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.

2015-01-12 Thread Hans Verkuil
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.

2015-01-08 Thread Kamil Debski
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.

2014-12-30 Thread Sean Young
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