diff options
Diffstat (limited to 'Documentation/media/kapi/cec-core.rst')
| -rw-r--r-- | Documentation/media/kapi/cec-core.rst | 38 |
1 files changed, 24 insertions, 14 deletions
diff --git a/Documentation/media/kapi/cec-core.rst b/Documentation/media/kapi/cec-core.rst index 88c33b53ec13..81c6d8e93774 100644 --- a/Documentation/media/kapi/cec-core.rst +++ b/Documentation/media/kapi/cec-core.rst @@ -37,9 +37,8 @@ The struct cec_adapter represents the CEC adapter hardware. It is created by calling cec_allocate_adapter() and deleted by calling cec_delete_adapter(): .. c:function:: - struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops, - void *priv, const char *name, u32 caps, u8 available_las, - struct device *parent); + struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops, void *priv, + const char *name, u32 caps, u8 available_las); .. c:function:: void cec_delete_adapter(struct cec_adapter *adap); @@ -66,20 +65,19 @@ available_las: the number of simultaneous logical addresses that this adapter can handle. Must be 1 <= available_las <= CEC_MAX_LOG_ADDRS. -parent: - the parent device. - To register the /dev/cecX device node and the remote control device (if CEC_CAP_RC is set) you call: .. c:function:: - int cec_register_adapter(struct cec_adapter \*adap); + int cec_register_adapter(struct cec_adapter *adap, struct device *parent); + +where parent is the parent device. To unregister the devices call: .. c:function:: - void cec_unregister_adapter(struct cec_adapter \*adap); + void cec_unregister_adapter(struct cec_adapter *adap); Note: if cec_register_adapter() fails, then call cec_delete_adapter() to clean up. But if cec_register_adapter() succeeded, then only call @@ -106,13 +104,13 @@ your driver: int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); int (*adap_transmit)(struct cec_adapter *adap, u8 attempts, u32 signal_free_time, struct cec_msg *msg); - void (\*adap_log_status)(struct cec_adapter *adap); + void (*adap_status)(struct cec_adapter *adap, struct seq_file *file); /* High-level callbacks */ ... }; -The three low-level ops deal with various aspects of controlling the CEC adapter +The five low-level ops deal with various aspects of controlling the CEC adapter hardware: @@ -238,6 +236,18 @@ When a CEC message was received: Speaks for itself. +Implementing the interrupt handler +---------------------------------- + +Typically the CEC hardware provides interrupts that signal when a transmit +finished and whether it was successful or not, and it provides and interrupt +when a CEC message was received. + +The CEC driver should always process the transmit interrupts first before +handling the receive interrupt. The framework expects to see the cec_transmit_done +call before the cec_received_msg call, otherwise it can get confused if the +received message was in reply to the transmitted message. + Implementing the High-Level CEC Adapter --------------------------------------- @@ -247,11 +257,11 @@ CEC protocol driven. The following high-level callbacks are available: .. code-block:: none struct cec_adap_ops { - /\* Low-level callbacks \*/ + /* Low-level callbacks */ ... - /\* High-level CEC message callback \*/ - int (\*received)(struct cec_adapter \*adap, struct cec_msg \*msg); + /* High-level CEC message callback */ + int (*received)(struct cec_adapter *adap, struct cec_msg *msg); }; The received() callback allows the driver to optionally handle a newly @@ -263,7 +273,7 @@ received CEC message If the driver wants to process a CEC message, then it can implement this callback. If it doesn't want to handle this message, then it should return -ENOMSG, otherwise the CEC framework assumes it processed this message and -it will not no anything with it. +it will not do anything with it. CEC framework functions |