RE: [RFC v3 5/9] cec: add new driver for cec support.
Hi Hans, From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Friday, April 17, 2015 2:17 PM > > On 04/13/2015 03:19 PM, Kamil Debski wrote: > > Hi Hans, > > > > Thank you so much for the review. > > > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > ow...@vger.kernel.org] On Behalf Of Hans Verkuil > > Sent: Friday, March 20, 2015 7:08 PM > >> > > > > >>> +In order for a CEC adapter to be configured it needs a physical > >> address. > >>> +This is normally assigned by the driver. It is either 0.0.0.0 for > a > >> TV (aka > >>> +video receiver) or it is derived from the EDID that the source > >> received > >>> +from the sink. This is normally set by the driver before enabling > >> the CEC > >>> +adapter, or it is set from userspace in the case of CEC USB > dongles > >> (although > >>> +embedded systems might also want to set this manually). > >> > >> I would actually expect that USB dongles read out the EDID from the > >> source. > >> I might be wrong, though. > > > > EDID is communicated to the device by the TV on a different bus than > > CEC, it is DDC. It is possible that the dongle also reads DDC > messages. > > My initial understanding was that a CEC USB dongle handles only CEC > > messages and is passing through all other signals, such as DDC. > > I checked against the libcec code (see link here: http://libcec.pulse- > eight.com/) for my usb-cec dongle and it turns out the library reads > out the edid from the monitor using xrandr (I think, see > src/libcec/platform/X11/randr-edid.cpp) in order to get the physical > address. So it is not using the dongle itself for that. Makes sense. > > > > >>> + > >>> +After enabling the CEC adapter it has to be configured. The CEC > >> adapter has > >>> +to be informed for which CEC device types a logical address has to > >> be found. > >> > >> I would say: 'a free (unused) logical address'. > >> > >>> +The CEC framework will attempt to find such logical addresses. If > >> none are > >> > >> And here: 'find and claim' > >> > >>> +found, then it will fall back to logical address Unregistered (15). > >> > >> You probably need to add some documentation regarding > >> cec_claim_log_addrs() > >> and how drivers can use it. Also, while logical addresses are being > >> claimed, are drivers or userspace allowed to transmit/receive other > >> messages? Or just stall until this is finished? > > > > When sending a message the user space is free to set any source and > > destination address. Hence, I see no need to wait until the logical > > address is claimed. > > > > If the user space is not waiting until the address and is sending > > messages, then I guess it is done with full responsibility on the > user > > space. > > > > Regarding receiving, I guess it should be possible to receive > > broadcast messages. > > > > What do you think? > > Fair enough, it just needs to be documented. Ok, will do. > > > > >>> +Promiscuous mode > >>> + > >>> + > >>> +The promiscuous mode enables the userspace applications to read > all > >>> +messages on the CEC bus. This is similar to the promiscuous mode > in > >>> +network devices. In the normal mode messages not directed to the > >> device > >>> +(differentiated by the logical address of the CEC device) are not > >>> +forwarded to the userspace. Same rule applies to the messages > >> contailning > >>> +remote control key codes. When promiscuous mode is enabled all > >> messages > >>> +can be read by userspace. Processing of the messages is still done, > >> thus > >>> +key codes will be both interpreted by the framework and available > >>> +as > >> an > >>> +input device, but also raw messages containing these codes are > sent > >> to > >>> +the userspace. > >> > >> Will messages that are processed by the driver or cec framework also > >> be relayed to userspace in promiscuous mode? Will userspace be able > >> to tell that it has been processed already? > > > > All messages will be relayed to the user space and no there is no > > possibility to check whether the message was processed by the kernel > > already. > > Should we add that? To be honest, I'm not sure about that myself. The promiscuous mode is useful mainly for debug reasons. I would leave it, however it is not a deal breaker for me. It could be added at a later time. > Once thing I notice is that there are no reserved fields at the end of > struct cec_msg. We should add that. Same with the other structs. It > served us well with v4l2, and we should do the same with the cec API. This is indeed a good idea. Thanks :) > > Another upcoming problem is the use of struct timespec: this will have > to change in the near future to one that is year 2038-safe. > Unfortunately, there is no public 'struct timespec64' type yet. This > mailinglist might provide answers w.r.t. the precise plans with > timespec: > http://lwn.net/Articles/640284/ > > Also, we don't have 32-bit compa
Re: [RFC v3 5/9] cec: add new driver for cec support.
On 04/13/2015 03:19 PM, Kamil Debski wrote: > Hi Hans, > > Thank you so much for the review. > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Hans Verkuil > Sent: Friday, March 20, 2015 7:08 PM >> >>> +In order for a CEC adapter to be configured it needs a physical >> address. >>> +This is normally assigned by the driver. It is either 0.0.0.0 for a >> TV (aka >>> +video receiver) or it is derived from the EDID that the source >> received >>> +from the sink. This is normally set by the driver before enabling >> the CEC >>> +adapter, or it is set from userspace in the case of CEC USB dongles >> (although >>> +embedded systems might also want to set this manually). >> >> I would actually expect that USB dongles read out the EDID from the >> source. >> I might be wrong, though. > > EDID is communicated to the device by the TV on a different bus than > CEC, it is DDC. It is possible that the dongle also reads DDC messages. > My initial understanding was that a CEC USB dongle handles only CEC > messages and is passing through all other signals, such as DDC. I checked against the libcec code (see link here: http://libcec.pulse-eight.com/) for my usb-cec dongle and it turns out the library reads out the edid from the monitor using xrandr (I think, see src/libcec/platform/X11/randr-edid.cpp) in order to get the physical address. So it is not using the dongle itself for that. Makes sense. > >>> + >>> +After enabling the CEC adapter it has to be configured. The CEC >> adapter has >>> +to be informed for which CEC device types a logical address has to >> be found. >> >> I would say: 'a free (unused) logical address'. >> >>> +The CEC framework will attempt to find such logical addresses. If >> none are >> >> And here: 'find and claim' >> >>> +found, then it will fall back to logical address Unregistered (15). >> >> You probably need to add some documentation regarding >> cec_claim_log_addrs() >> and how drivers can use it. Also, while logical addresses are being >> claimed, >> are drivers or userspace allowed to transmit/receive other messages? Or >> just >> stall until this is finished? > > When sending a message the user space is free to set any source and > destination address. Hence, I see no need to wait until the logical > address is claimed. > > If the user space is not waiting until the address and is sending > messages, then I guess it is done with full responsibility on the user > space. > > Regarding receiving, I guess it should be possible to receive broadcast > messages. > > What do you think? Fair enough, it just needs to be documented. >>> +Promiscuous mode >>> + >>> + >>> +The promiscuous mode enables the userspace applications to read all >>> +messages on the CEC bus. This is similar to the promiscuous mode in >>> +network devices. In the normal mode messages not directed to the >> device >>> +(differentiated by the logical address of the CEC device) are not >>> +forwarded to the userspace. Same rule applies to the messages >> contailning >>> +remote control key codes. When promiscuous mode is enabled all >> messages >>> +can be read by userspace. Processing of the messages is still done, >> thus >>> +key codes will be both interpreted by the framework and available as >> an >>> +input device, but also raw messages containing these codes are sent >> to >>> +the userspace. >> >> Will messages that are processed by the driver or cec framework also be >> relayed to userspace in promiscuous mode? Will userspace be able to >> tell >> that it has been processed already? > > All messages will be relayed to the user space and no there is no > possibility > to check whether the message was processed by the kernel already. Should we add that? To be honest, I'm not sure about that myself. Once thing I notice is that there are no reserved fields at the end of struct cec_msg. We should add that. Same with the other structs. It served us well with v4l2, and we should do the same with the cec API. Another upcoming problem is the use of struct timespec: this will have to change in the near future to one that is year 2038-safe. Unfortunately, there is no public 'struct timespec64' type yet. This mailinglist might provide answers w.r.t. the precise plans with timespec: http://lwn.net/Articles/640284/ Also, we don't have 32-bit compat code for CEC. I wonder if it is a good idea to improve the layout of the structs to minimize 64/32-bit layout differences. I never paid attention to that when I made these structs as I always planned to do that at the end. 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 v3 5/9] cec: add new driver for cec support.
Hi Hans,
Thank you so much for the review.
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Friday, March 20, 2015 7:08 PM
>
> Hi Kamil,
>
> Once again thank you for continuing this work!
>
> I do have some comments, see below.
>
> On 03/20/2015 05:52 PM, Kamil Debski wrote:
> > Add the CEC framework.
> >
> > Signed-off-by: Hans Verkuil
> > [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 and fixes]
> > [k.deb...@samsung.com: add missing CEC commands to match spec]
> > [k.deb...@samsung.com: add RC framework support]
> > [k.deb...@samsung.com: move and edit documentation]
> > [k.deb...@samsung.com: add vendor id reporting]
> > [k.deb...@samsung.com: add promiscuous mode]
> > [k.deb...@samsung.com: add possibility to clear assigned logical
> > addresses]
> > Signed-off-by: Kamil Debski
> > ---
> > Documentation/cec.txt| 321 +
> > drivers/media/Kconfig|6 +
> > drivers/media/Makefile |2 +
> > drivers/media/cec.c | 1158
> ++
> > include/media/cec.h | 137 ++
> > include/uapi/linux/cec.h | 283 +++
> > 6 files changed, 1907 insertions(+)
> > create mode 100644 Documentation/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/Documentation/cec.txt b/Documentation/cec.txt
> > new file mode 100644
> > index 000..e96fcc0
> > --- /dev/null
> > +++ b/Documentation/cec.txt
> > @@ -0,0 +1,321 @@
> > +CEC Kernel Support
> > +==
> > +
> > +The CEC framework provides a unified kernel interface for use with
> HDMI CEC
> > +hardware. It is designed to handle a multiple variants of hardware.
> Adding to
> > +the flexibility of the framework it enables to set which parts of
> the CEC
> > +protocol processing is handled by the hardware, by the driver and by
> the
> > +userspace application.
> > +
> > +
> > +The CEC Protocol
> > +
> > +
> > +The CEC protocol enables cosumer electronic devices to communicate
> with each
>
> cosumer -> consumer
>
> > +other through the HDMI connection. The protocol uses logical
> addresses in the
> > +communication. The logical address is strictly connected with the
> functionality
> > +provided by the device. The TV acting as the communication hub is
> always
> > +assigned address 0. The physicall addressis determined by physical
> connection
>
> 'physicall addressis' -> 'physical address is'
> s/by/by the/
>
> > +between devices.
> > +
> > +The protocol enables control of compatible devices with a single
> remote.
> > +Synchronous power on/standby, instant playback with changing the
> content source
> > +on the TV.
> > +
> > +The Kernel Interface
> > +
> > +
> > +CEC Adaptor
>
> s/Adaptor/Adapter/
>
> > +---
> > +
> > +#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
> > +
> > +/* 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 CEC_LOG_ADDR_TYPE_AUDIOSYSTEM 4
> > +#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_06
> > +
> > +struct cec_adapter {
> > +
Re: [RFC v3 5/9] cec: add new driver for cec support.
Hi Kamil,
Once again thank you for continuing this work!
I do have some comments, see below.
On 03/20/2015 05:52 PM, Kamil Debski wrote:
> Add the CEC framework.
>
> Signed-off-by: Hans Verkuil
> [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 and fixes]
> [k.deb...@samsung.com: add missing CEC commands to match spec]
> [k.deb...@samsung.com: add RC framework support]
> [k.deb...@samsung.com: move and edit documentation]
> [k.deb...@samsung.com: add vendor id reporting]
> [k.deb...@samsung.com: add promiscuous mode]
> [k.deb...@samsung.com: add possibility to clear assigned logical
> addresses]
> Signed-off-by: Kamil Debski
> ---
> Documentation/cec.txt| 321 +
> drivers/media/Kconfig|6 +
> drivers/media/Makefile |2 +
> drivers/media/cec.c | 1158
> ++
> include/media/cec.h | 137 ++
> include/uapi/linux/cec.h | 283 +++
> 6 files changed, 1907 insertions(+)
> create mode 100644 Documentation/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/Documentation/cec.txt b/Documentation/cec.txt
> new file mode 100644
> index 000..e96fcc0
> --- /dev/null
> +++ b/Documentation/cec.txt
> @@ -0,0 +1,321 @@
> +CEC Kernel Support
> +==
> +
> +The CEC framework provides a unified kernel interface for use with HDMI CEC
> +hardware. It is designed to handle a multiple variants of hardware. Adding to
> +the flexibility of the framework it enables to set which parts of the CEC
> +protocol processing is handled by the hardware, by the driver and by the
> +userspace application.
> +
> +
> +The CEC Protocol
> +
> +
> +The CEC protocol enables cosumer electronic devices to communicate with each
cosumer -> consumer
> +other through the HDMI connection. The protocol uses logical addresses in the
> +communication. The logical address is strictly connected with the
> functionality
> +provided by the device. The TV acting as the communication hub is always
> +assigned address 0. The physicall addressis determined by physical connection
'physicall addressis' -> 'physical address is'
s/by/by the/
> +between devices.
> +
> +The protocol enables control of compatible devices with a single remote.
> +Synchronous power on/standby, instant playback with changing the content
> source
> +on the TV.
> +
> +The Kernel Interface
> +
> +
> +CEC Adaptor
s/Adaptor/Adapter/
> +---
> +
> +#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
> +
> +/* 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_adapter {
> + /* internal fields removed */
> +
> + u16 phys_addr;
> + u32 capabilities;
> + u8 version;
> + u8 num_log_addrs;
> + u8 prim_device[CEC_MAX_LOG_ADDRS];
> + u8 log_addr_type[CEC_MAX_LOG_ADDRS];
> + u8 log_addr[CEC_MAX_LOG_ADDRS];
> +
> + int (*adap_enable)(struct cec_adapter *adap, bool enable);
> + int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
> + int (*adap_transmit)(struct cec_adapter *a
[RFC v3 5/9] cec: add new driver for cec support.
Add the CEC framework.
Signed-off-by: Hans Verkuil
[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 and fixes]
[k.deb...@samsung.com: add missing CEC commands to match spec]
[k.deb...@samsung.com: add RC framework support]
[k.deb...@samsung.com: move and edit documentation]
[k.deb...@samsung.com: add vendor id reporting]
[k.deb...@samsung.com: add promiscuous mode]
[k.deb...@samsung.com: add possibility to clear assigned logical
addresses]
Signed-off-by: Kamil Debski
---
Documentation/cec.txt| 321 +
drivers/media/Kconfig|6 +
drivers/media/Makefile |2 +
drivers/media/cec.c | 1158 ++
include/media/cec.h | 137 ++
include/uapi/linux/cec.h | 283 +++
6 files changed, 1907 insertions(+)
create mode 100644 Documentation/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/Documentation/cec.txt b/Documentation/cec.txt
new file mode 100644
index 000..e96fcc0
--- /dev/null
+++ b/Documentation/cec.txt
@@ -0,0 +1,321 @@
+CEC Kernel Support
+==
+
+The CEC framework provides a unified kernel interface for use with HDMI CEC
+hardware. It is designed to handle a multiple variants of hardware. Adding to
+the flexibility of the framework it enables to set which parts of the CEC
+protocol processing is handled by the hardware, by the driver and by the
+userspace application.
+
+
+The CEC Protocol
+
+
+The CEC protocol enables cosumer electronic devices to communicate with each
+other through the HDMI connection. The protocol uses logical addresses in the
+communication. The logical address is strictly connected with the functionality
+provided by the device. The TV acting as the communication hub is always
+assigned address 0. The physicall addressis determined by physical connection
+between devices.
+
+The protocol enables control of compatible devices with a single remote.
+Synchronous power on/standby, instant playback with changing the content source
+on the TV.
+
+The Kernel Interface
+
+
+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
+
+/* 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 CEC_LOG_ADDR_TYPE_AUDIOSYSTEM 4
+#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_06
+
+struct cec_adapter {
+ /* internal fields removed */
+
+ u16 phys_addr;
+ u32 capabilities;
+ u8 version;
+ u8 num_log_addrs;
+ u8 prim_device[CEC_MAX_LOG_ADDRS];
+ u8 log_addr_type[CEC_MAX_LOG_ADDRS];
+ u8 log_addr[CEC_MAX_LOG_ADDRS];
+
+ int (*adap_enable)(struct cec_adapter *adap, bool enable);
+ int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
+ int (*adap_transmit)(struct cec_adapter *adap, struct cec_msg *msg);
+ void (*adap_transmit_timed_out)(struct cec_adapter *adap);
+
+ int (*received_tv)(struct cec_adapter *adap, struct cec_msg *msg);
+ int (*received_record)(struct cec_adapter *adap, struct cec_msg *msg);
+ int (*received_tuner)(struct cec_adapter *adap, struct cec_msg *msg);
+ int (*received_playback)(struct cec_adapter *adap, struct cec_msg *msg);
+ int (*received_audiosystem)(struct cec_adapter *ada
