Lines Matching +full:hdmi +full:- +full:cec

1 .. SPDX-License-Identifier: GPL-2.0
3 CEC Kernel Support
6 The CEC framework provides a unified kernel interface for use with HDMI CEC
14 The CEC Protocol
15 ----------------
17 The CEC protocol enables consumer electronic devices to communicate with each
18 other through the HDMI connection. The protocol uses logical addresses in the
24 The CEC framework described here is up to date with the CEC 2.0 specification.
25 It is documented in the HDMI 1.4 specification with the new 2.0 bits documented
26 in the HDMI 2.0 specification. But for most of the features the freely available
27 HDMI 1.3a specification is sufficient:
29 https://www.hdmi.org/spec/index
32 CEC Adapter Interface
33 ---------------------
35 The struct cec_adapter represents the CEC adapter hardware. It is created by
49 adapter operations which are called by the CEC framework and that you
53 will be stored in adap->priv and can be used by the adapter ops.
57 the name of the CEC adapter. Note: this name will be copied.
60 capabilities of the CEC adapter. These capabilities determine the
95 Implementing the Low-Level CEC Adapter
96 --------------------------------------
98 The following low-level adapter operations have to be implemented in
103 .. code-block:: none
107 /* Low-level callbacks */
123 /* High-level callback */
127 These low-level ops deal with various aspects of controlling the CEC adapter
128 hardware. They are all called with the mutex adap->lock held.
135 This callback enables or disables the CEC hardware. Enabling the CEC hardware
138 capability is not set, then the physical address can change while the CEC
139 hardware is enabled. CEC drivers should not set CEC_CAP_NEEDS_HPD unless
142 state of the CEC adapter after calling cec_allocate_adapter() is disabled.
163 If enabled, then the adapter should be put in a mode to also monitor CEC pin
178 should return -ENXIO. Once a logical address is programmed the CEC hardware
210 To pass on the result of a canceled non-blocking transmit::
216 non-blocking transmit with sequence number msg->sequence. This is
223 To log the current CEC hardware status::
227 This optional callback can be used to show the status of the CEC hardware.
228 The status is available through debugfs: cat /sys/kernel/debug/cec/cecX/status
257 arbitration was lost: another CEC initiator
258 took control of the CEC line and you lost the arbitration.
265 low drive was detected on the CEC bus. This indicates that
303 When a CEC message was received:
311 ----------------------------------
313 Typically the CEC hardware provides interrupts that signal when a transmit
315 when a CEC message was received.
317 The CEC driver should always process the transmit interrupts first before
323 ----------------------------------------------
325 If the CEC adapter supports Error Injection functionality, then that can
328 .. code-block:: none
331 /* Low-level callbacks */
338 /* High-level CEC message callback */
342 If both callbacks are set, then an ``error-inj`` file will appear in debugfs.
348 This basic parsing is done in the CEC Framework. It is up to the driver to decide
353 This ensures that you can always do ``echo clear >error-inj`` to clear any error
354 injections without having to know the details of the driver-specific commands.
356 Note that the output of ``error-inj`` shall be valid as input to ``error-inj``.
359 .. code-block:: none
361 $ cat error-inj >einj.txt
362 $ cat einj.txt >error-inj
372 The second callback will parse commands written to the ``error-inj`` file::
378 are no embedded newlines) and it is 0-terminated. The callback is free to
384 Implementing the High-Level CEC Adapter
385 ---------------------------------------
387 The low-level operations drive the hardware, the high-level operations are
388 CEC protocol driven. The high-level callbacks are called without the adap->lock
389 mutex being held. The following high-level callbacks are available:
391 .. code-block:: none
394 /* Low-level callbacks */
400 /* High-level CEC message callback */
415 received CEC message::
419 If the driver wants to process a CEC message, then it can implement this
421 -ENOMSG, otherwise the CEC framework assumes it processed this message and
425 CEC framework functions
426 -----------------------
428 CEC Adapter drivers can call the following CEC framework functions:
434 Transmit a CEC message. If block is true, then wait until the message has been
440 Change the physical address. This function will set adap->phys_addr and
442 the physical address has become valid, then the CEC framework will start
446 When the physical address is set to a valid value the CEC adapter will
448 then the CEC adapter will be disabled. If you change a valid physical address
464 Claim the CEC logical addresses. Should never be called if CEC_CAP_LOG_ADDRS
468 log_addrs->num_log_addrs set to 0. The block argument is ignored when
473 CEC Pin framework
474 -----------------
476 Most CEC hardware operates on full CEC messages where the software provides
477 the message and the hardware handles the low-level CEC protocol. But some
478 hardware only drives the CEC pin and software has to handle the low-level
479 CEC protocol. The CEC pin framework was created to handle such devices.
481 Note that due to the close-to-realtime requirements it can never be guaranteed
486 One advantage of this low-level implementation is that it can be used as
487 a cheap CEC analyser, especially if interrupts can be used to detect
488 CEC pin transitions from low to high or vice versa.
490 .. kernel-doc:: include/media/cec-pin.h
492 CEC Notifier framework
493 ----------------------
495 Most drm HDMI implementations have an integrated CEC implementation and no
496 notifier support is needed. But some have independent CEC implementations
498 completely separate chip that deals with the CEC pin. For those cases a
500 CEC driver about changes in the physical address.
502 .. kernel-doc:: include/media/cec-notifier.h