4 The CEC framework provides a unified kernel interface for use with HDMI CEC
5 hardware. It is designed to handle a multiple types of hardware (receivers,
6 transmitters, USB dongles). The framework also gives the option to decide
7 what to do in the kernel driver and what should be handled by userspace
8 applications. In addition it integrates the remote control passthrough
9 feature into the kernel's remote control framework.
15 The CEC protocol enables consumer electronic devices to communicate with each
16 other through the HDMI connection. The protocol uses logical addresses in the
17 communication. The logical address is strictly connected with the functionality
18 provided by the device. The TV acting as the communication hub is always
19 assigned address 0. The physical address is determined by the physical
20 connection between devices.
22 The CEC framework described here is up to date with the CEC 2.0 specification.
23 It is documented in the HDMI 1.4 specification with the new 2.0 bits documented
24 in the HDMI 2.0 specification. But for most of the features the freely available
25 HDMI 1.3a specification is sufficient:
27 http://www.microprocessor.org/HDMISpecification13a.pdf
33 The struct cec_adapter represents the CEC adapter hardware. It is created by
34 calling cec_allocate_adapter() and deleted by calling cec_delete_adapter():
37 struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops, void *priv,
38 const char *name, u32 caps, u8 available_las);
41 void cec_delete_adapter(struct cec_adapter *adap);
43 To create an adapter you need to pass the following information:
46 adapter operations which are called by the CEC framework and that you
50 will be stored in adap->priv and can be used by the adapter ops.
51 Use cec_get_drvdata(adap) to get the priv pointer.
54 the name of the CEC adapter. Note: this name will be copied.
57 capabilities of the CEC adapter. These capabilities determine the
58 capabilities of the hardware and which parts are to be handled
59 by userspace and which parts are handled by kernelspace. The
60 capabilities are returned by CEC_ADAP_G_CAPS.
63 the number of simultaneous logical addresses that this
64 adapter can handle. Must be 1 <= available_las <= CEC_MAX_LOG_ADDRS.
66 To obtain the priv pointer use this helper function:
69 void *cec_get_drvdata(const struct cec_adapter *adap);
71 To register the /dev/cecX device node and the remote control device (if
72 CEC_CAP_RC is set) you call:
75 int cec_register_adapter(struct cec_adapter *adap, struct device *parent);
77 where parent is the parent device.
79 To unregister the devices call:
82 void cec_unregister_adapter(struct cec_adapter *adap);
84 Note: if cec_register_adapter() fails, then call cec_delete_adapter() to
85 clean up. But if cec_register_adapter() succeeded, then only call
86 cec_unregister_adapter() to clean up, never cec_delete_adapter(). The
87 unregister function will delete the adapter automatically once the last user
88 of that /dev/cecX device has closed its file handle.
91 Implementing the Low-Level CEC Adapter
92 --------------------------------------
94 The following low-level adapter operations have to be implemented in
97 .. c:type:: struct cec_adap_ops
103 /* Low-level callbacks */
104 int (*adap_enable)(struct cec_adapter *adap, bool enable);
105 int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable);
106 int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable);
107 int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
108 int (*adap_transmit)(struct cec_adapter *adap, u8 attempts,
109 u32 signal_free_time, struct cec_msg *msg);
110 void (*adap_status)(struct cec_adapter *adap, struct seq_file *file);
111 void (*adap_free)(struct cec_adapter *adap);
113 /* Error injection callbacks */
116 /* High-level callbacks */
120 The seven low-level ops deal with various aspects of controlling the CEC adapter
124 To enable/disable the hardware:
127 int (*adap_enable)(struct cec_adapter *adap, bool enable);
129 This callback enables or disables the CEC hardware. Enabling the CEC hardware
130 means powering it up in a state where no logical addresses are claimed. This
131 op assumes that the physical address (adap->phys_addr) is valid when enable is
132 true and will not change while the CEC adapter remains enabled. The initial
133 state of the CEC adapter after calling cec_allocate_adapter() is disabled.
135 Note that adap_enable must return 0 if enable is false.
138 To enable/disable the 'monitor all' mode:
141 int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable);
143 If enabled, then the adapter should be put in a mode to also monitor messages
144 that not for us. Not all hardware supports this and this function is only
145 called if the CEC_CAP_MONITOR_ALL capability is set. This callback is optional
146 (some hardware may always be in 'monitor all' mode).
148 Note that adap_monitor_all_enable must return 0 if enable is false.
151 To enable/disable the 'monitor pin' mode:
154 int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable);
156 If enabled, then the adapter should be put in a mode to also monitor CEC pin
157 changes. Not all hardware supports this and this function is only called if
158 the CEC_CAP_MONITOR_PIN capability is set. This callback is optional
159 (some hardware may always be in 'monitor pin' mode).
161 Note that adap_monitor_pin_enable must return 0 if enable is false.
164 To program a new logical address:
167 int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
169 If logical_addr == CEC_LOG_ADDR_INVALID then all programmed logical addresses
170 are to be erased. Otherwise the given logical address should be programmed.
171 If the maximum number of available logical addresses is exceeded, then it
172 should return -ENXIO. Once a logical address is programmed the CEC hardware
173 can receive directed messages to that address.
175 Note that adap_log_addr must return 0 if logical_addr is CEC_LOG_ADDR_INVALID.
178 To transmit a new message:
181 int (*adap_transmit)(struct cec_adapter *adap, u8 attempts,
182 u32 signal_free_time, struct cec_msg *msg);
184 This transmits a new message. The attempts argument is the suggested number of
185 attempts for the transmit.
187 The signal_free_time is the number of data bit periods that the adapter should
188 wait when the line is free before attempting to send a message. This value
189 depends on whether this transmit is a retry, a message from a new initiator or
190 a new message for the same initiator. Most hardware will handle this
191 automatically, but in some cases this information is needed.
193 The CEC_FREE_TIME_TO_USEC macro can be used to convert signal_free_time to
194 microseconds (one data bit period is 2.4 ms).
197 To log the current CEC hardware status:
200 void (*adap_status)(struct cec_adapter *adap, struct seq_file *file);
202 This optional callback can be used to show the status of the CEC hardware.
203 The status is available through debugfs: cat /sys/kernel/debug/cec/cecX/status
205 To free any resources when the adapter is deleted:
208 void (*adap_free)(struct cec_adapter *adap);
210 This optional callback can be used to free any resources that might have been
211 allocated by the driver. It's called from cec_delete_adapter.
214 Your adapter driver will also have to react to events (typically interrupt
215 driven) by calling into the framework in the following situations:
217 When a transmit finished (successfully or otherwise):
220 void cec_transmit_done(struct cec_adapter *adap, u8 status, u8 arb_lost_cnt,
221 u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);
226 void cec_transmit_attempt_done(struct cec_adapter *adap, u8 status);
228 The status can be one of:
231 the transmit was successful.
233 CEC_TX_STATUS_ARB_LOST:
234 arbitration was lost: another CEC initiator
235 took control of the CEC line and you lost the arbitration.
238 the message was nacked (for a directed message) or
239 acked (for a broadcast message). A retransmission is needed.
241 CEC_TX_STATUS_LOW_DRIVE:
242 low drive was detected on the CEC bus. This indicates that
243 a follower detected an error on the bus and requested a
247 some unspecified error occurred: this can be one of ARB_LOST
248 or LOW_DRIVE if the hardware cannot differentiate or something
249 else entirely. Some hardware only supports OK and FAIL as the
250 result of a transmit, i.e. there is no way to differentiate
251 between the different possible errors. In that case map FAIL
252 to CEC_TX_STATUS_NACK and not to CEC_TX_STATUS_ERROR.
254 CEC_TX_STATUS_MAX_RETRIES:
255 could not transmit the message after trying multiple times.
256 Should only be set by the driver if it has hardware support for
257 retrying messages. If set, then the framework assumes that it
258 doesn't have to make another attempt to transmit the message
259 since the hardware did that already.
261 The hardware must be able to differentiate between OK, NACK and 'something
264 The \*_cnt arguments are the number of error conditions that were seen.
265 This may be 0 if no information is available. Drivers that do not support
266 hardware retry can just set the counter corresponding to the transmit error
267 to 1, if the hardware does support retry then either set these counters to
268 0 if the hardware provides no feedback of which errors occurred and how many
269 times, or fill in the correct values as reported by the hardware.
271 Be aware that calling these functions can immediately start a new transmit
272 if there is one pending in the queue. So make sure that the hardware is in
273 a state where new transmits can be started *before* calling these functions.
275 The cec_transmit_attempt_done() function is a helper for cases where the
276 hardware never retries, so the transmit is always for just a single
277 attempt. It will call cec_transmit_done() in turn, filling in 1 for the
278 count argument corresponding to the status. Or all 0 if the status was OK.
280 When a CEC message was received:
283 void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
287 Implementing the interrupt handler
288 ----------------------------------
290 Typically the CEC hardware provides interrupts that signal when a transmit
291 finished and whether it was successful or not, and it provides and interrupt
292 when a CEC message was received.
294 The CEC driver should always process the transmit interrupts first before
295 handling the receive interrupt. The framework expects to see the cec_transmit_done
296 call before the cec_received_msg call, otherwise it can get confused if the
297 received message was in reply to the transmitted message.
299 Optional: Implementing Error Injection Support
300 ----------------------------------------------
302 If the CEC adapter supports Error Injection functionality, then that can
303 be exposed through the Error Injection callbacks:
307 struct cec_adap_ops {
308 /* Low-level callbacks */
311 /* Error injection callbacks */
312 int (*error_inj_show)(struct cec_adapter *adap, struct seq_file *sf);
313 bool (*error_inj_parse_line)(struct cec_adapter *adap, char *line);
315 /* High-level CEC message callback */
319 If both callbacks are set, then an ``error-inj`` file will appear in debugfs.
320 The basic syntax is as follows:
322 Leading spaces/tabs are ignored. If the next character is a ``#`` or the end of the
323 line was reached, then the whole line is ignored. Otherwise a command is expected.
325 This basic parsing is done in the CEC Framework. It is up to the driver to decide
326 what commands to implement. The only requirement is that the command ``clear`` without
327 any arguments must be implemented and that it will remove all current error injection
330 This ensures that you can always do ``echo clear >error-inj`` to clear any error
331 injections without having to know the details of the driver-specific commands.
333 Note that the output of ``error-inj`` shall be valid as input to ``error-inj``.
338 $ cat error-inj >einj.txt
339 $ cat einj.txt >error-inj
341 The first callback is called when this file is read and it should show the
342 the current error injection state:
345 int (*error_inj_show)(struct cec_adapter *adap, struct seq_file *sf);
347 It is recommended that it starts with a comment block with basic usage
348 information. It returns 0 for success and an error otherwise.
350 The second callback will parse commands written to the ``error-inj`` file:
353 bool (*error_inj_parse_line)(struct cec_adapter *adap, char *line);
355 The ``line`` argument points to the start of the command. Any leading
356 spaces or tabs have already been skipped. It is a single line only (so there
357 are no embedded newlines) and it is 0-terminated. The callback is free to
358 modify the contents of the buffer. It is only called for lines containing a
359 command, so this callback is never called for empty lines or comment lines.
361 Return true if the command was valid or false if there were syntax errors.
363 Implementing the High-Level CEC Adapter
364 ---------------------------------------
366 The low-level operations drive the hardware, the high-level operations are
367 CEC protocol driven. The following high-level callbacks are available:
371 struct cec_adap_ops {
372 /* Low-level callbacks */
375 /* Error injection callbacks */
378 /* High-level CEC message callback */
379 int (*received)(struct cec_adapter *adap, struct cec_msg *msg);
382 The received() callback allows the driver to optionally handle a newly
386 int (*received)(struct cec_adapter *adap, struct cec_msg *msg);
388 If the driver wants to process a CEC message, then it can implement this
389 callback. If it doesn't want to handle this message, then it should return
390 -ENOMSG, otherwise the CEC framework assumes it processed this message and
391 it will not do anything with it.
394 CEC framework functions
395 -----------------------
397 CEC Adapter drivers can call the following CEC framework functions:
400 int cec_transmit_msg(struct cec_adapter *adap, struct cec_msg *msg,
403 Transmit a CEC message. If block is true, then wait until the message has been
404 transmitted, otherwise just queue it and return.
407 void cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr,
410 Change the physical address. This function will set adap->phys_addr and
411 send an event if it has changed. If cec_s_log_addrs() has been called and
412 the physical address has become valid, then the CEC framework will start
413 claiming the logical addresses. If block is true, then this function won't
414 return until this process has finished.
416 When the physical address is set to a valid value the CEC adapter will
417 be enabled (see the adap_enable op). When it is set to CEC_PHYS_ADDR_INVALID,
418 then the CEC adapter will be disabled. If you change a valid physical address
419 to another valid physical address, then this function will first set the
420 address to CEC_PHYS_ADDR_INVALID before enabling the new physical address.
423 void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
424 const struct edid *edid);
426 A helper function that extracts the physical address from the edid struct
427 and calls cec_s_phys_addr() with that address, or CEC_PHYS_ADDR_INVALID
428 if the EDID did not contain a physical address or edid was a NULL pointer.
431 int cec_s_log_addrs(struct cec_adapter *adap,
432 struct cec_log_addrs *log_addrs, bool block);
434 Claim the CEC logical addresses. Should never be called if CEC_CAP_LOG_ADDRS
435 is set. If block is true, then wait until the logical addresses have been
436 claimed, otherwise just queue it and return. To unconfigure all logical
437 addresses call this function with log_addrs set to NULL or with
438 log_addrs->num_log_addrs set to 0. The block argument is ignored when
439 unconfiguring. This function will just return if the physical address is
440 invalid. Once the physical address becomes valid, then the framework will
441 attempt to claim these logical addresses.
446 Most CEC hardware operates on full CEC messages where the software provides
447 the message and the hardware handles the low-level CEC protocol. But some
448 hardware only drives the CEC pin and software has to handle the low-level
449 CEC protocol. The CEC pin framework was created to handle such devices.
451 Note that due to the close-to-realtime requirements it can never be guaranteed
452 to work 100%. This framework uses highres timers internally, but if a
453 timer goes off too late by more than 300 microseconds wrong results can
454 occur. In reality it appears to be fairly reliable.
456 One advantage of this low-level implementation is that it can be used as
457 a cheap CEC analyser, especially if interrupts can be used to detect
458 CEC pin transitions from low to high or vice versa.
460 .. kernel-doc:: include/media/cec-pin.h
462 CEC Notifier framework
463 ----------------------
465 Most drm HDMI implementations have an integrated CEC implementation and no
466 notifier support is needed. But some have independent CEC implementations
467 that have their own driver. This could be an IP block for an SoC or a
468 completely separate chip that deals with the CEC pin. For those cases a
469 drm driver can install a notifier and use the notifier to inform the
470 CEC driver about changes in the physical address.
472 .. kernel-doc:: include/media/cec-notifier.h