Mauro Carvalho Chehab | f2ac8ce8 | 2018-08-30 10:20:04 -0400 | [diff] [blame] | 1 | .. SPDX-License-Identifier: GPL-2.0 |
| 2 | |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 3 | CEC Kernel Support |
| 4 | ================== |
| 5 | |
| 6 | The CEC framework provides a unified kernel interface for use with HDMI CEC |
| 7 | hardware. It is designed to handle a multiple types of hardware (receivers, |
| 8 | transmitters, USB dongles). The framework also gives the option to decide |
| 9 | what to do in the kernel driver and what should be handled by userspace |
| 10 | applications. In addition it integrates the remote control passthrough |
| 11 | feature into the kernel's remote control framework. |
| 12 | |
| 13 | |
| 14 | The CEC Protocol |
| 15 | ---------------- |
| 16 | |
| 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 |
| 19 | communication. The logical address is strictly connected with the functionality |
| 20 | provided by the device. The TV acting as the communication hub is always |
| 21 | assigned address 0. The physical address is determined by the physical |
| 22 | connection between devices. |
| 23 | |
| 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: |
| 28 | |
| 29 | http://www.microprocessor.org/HDMISpecification13a.pdf |
| 30 | |
| 31 | |
Sakari Ailus | 3b8b2e1c | 2017-03-09 06:40:18 -0300 | [diff] [blame] | 32 | CEC Adapter Interface |
| 33 | --------------------- |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 34 | |
| 35 | The struct cec_adapter represents the CEC adapter hardware. It is created by |
| 36 | calling cec_allocate_adapter() and deleted by calling cec_delete_adapter(): |
| 37 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 38 | .. c:function:: |
Hans Verkuil | f51e808 | 2016-11-25 06:23:34 -0200 | [diff] [blame] | 39 | struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops, void *priv, |
| 40 | const char *name, u32 caps, u8 available_las); |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 41 | |
| 42 | .. c:function:: |
| 43 | void cec_delete_adapter(struct cec_adapter *adap); |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 44 | |
| 45 | To create an adapter you need to pass the following information: |
| 46 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 47 | ops: |
| 48 | adapter operations which are called by the CEC framework and that you |
| 49 | have to implement. |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 50 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 51 | priv: |
| 52 | will be stored in adap->priv and can be used by the adapter ops. |
Hans Verkuil | 6eae60c | 2017-03-27 06:53:00 -0300 | [diff] [blame] | 53 | Use cec_get_drvdata(adap) to get the priv pointer. |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 54 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 55 | name: |
| 56 | the name of the CEC adapter. Note: this name will be copied. |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 57 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 58 | caps: |
| 59 | capabilities of the CEC adapter. These capabilities determine the |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 60 | capabilities of the hardware and which parts are to be handled |
| 61 | by userspace and which parts are handled by kernelspace. The |
| 62 | capabilities are returned by CEC_ADAP_G_CAPS. |
| 63 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 64 | available_las: |
| 65 | the number of simultaneous logical addresses that this |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 66 | adapter can handle. Must be 1 <= available_las <= CEC_MAX_LOG_ADDRS. |
| 67 | |
Hans Verkuil | 6eae60c | 2017-03-27 06:53:00 -0300 | [diff] [blame] | 68 | To obtain the priv pointer use this helper function: |
| 69 | |
| 70 | .. c:function:: |
| 71 | void *cec_get_drvdata(const struct cec_adapter *adap); |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 72 | |
| 73 | To register the /dev/cecX device node and the remote control device (if |
| 74 | CEC_CAP_RC is set) you call: |
| 75 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 76 | .. c:function:: |
Hans Verkuil | f51e808 | 2016-11-25 06:23:34 -0200 | [diff] [blame] | 77 | int cec_register_adapter(struct cec_adapter *adap, struct device *parent); |
| 78 | |
| 79 | where parent is the parent device. |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 80 | |
| 81 | To unregister the devices call: |
| 82 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 83 | .. c:function:: |
Hans Verkuil | f51e808 | 2016-11-25 06:23:34 -0200 | [diff] [blame] | 84 | void cec_unregister_adapter(struct cec_adapter *adap); |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 85 | |
| 86 | Note: if cec_register_adapter() fails, then call cec_delete_adapter() to |
| 87 | clean up. But if cec_register_adapter() succeeded, then only call |
| 88 | cec_unregister_adapter() to clean up, never cec_delete_adapter(). The |
| 89 | unregister function will delete the adapter automatically once the last user |
| 90 | of that /dev/cecX device has closed its file handle. |
| 91 | |
| 92 | |
| 93 | Implementing the Low-Level CEC Adapter |
| 94 | -------------------------------------- |
| 95 | |
| 96 | The following low-level adapter operations have to be implemented in |
| 97 | your driver: |
| 98 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 99 | .. c:type:: struct cec_adap_ops |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 100 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 101 | .. code-block:: none |
| 102 | |
| 103 | struct cec_adap_ops |
| 104 | { |
| 105 | /* Low-level callbacks */ |
| 106 | int (*adap_enable)(struct cec_adapter *adap, bool enable); |
| 107 | int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable); |
Hans Verkuil | 15ae0be | 2017-11-23 09:05:06 -0500 | [diff] [blame] | 108 | int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable); |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 109 | int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); |
| 110 | int (*adap_transmit)(struct cec_adapter *adap, u8 attempts, |
| 111 | u32 signal_free_time, struct cec_msg *msg); |
Hans Verkuil | e92ca73 | 2016-11-09 06:00:53 -0200 | [diff] [blame] | 112 | void (*adap_status)(struct cec_adapter *adap, struct seq_file *file); |
Hans Verkuil | f987cde | 2017-07-11 03:30:37 -0300 | [diff] [blame] | 113 | void (*adap_free)(struct cec_adapter *adap); |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 114 | |
Hans Verkuil | 6902c88 | 2018-02-25 06:05:55 -0500 | [diff] [blame] | 115 | /* Error injection callbacks */ |
| 116 | ... |
| 117 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 118 | /* High-level callbacks */ |
| 119 | ... |
| 120 | }; |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 121 | |
Hans Verkuil | 6902c88 | 2018-02-25 06:05:55 -0500 | [diff] [blame] | 122 | The seven low-level ops deal with various aspects of controlling the CEC adapter |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 123 | hardware: |
| 124 | |
| 125 | |
| 126 | To enable/disable the hardware: |
| 127 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 128 | .. c:function:: |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 129 | int (*adap_enable)(struct cec_adapter *adap, bool enable); |
| 130 | |
| 131 | This callback enables or disables the CEC hardware. Enabling the CEC hardware |
| 132 | means powering it up in a state where no logical addresses are claimed. This |
| 133 | op assumes that the physical address (adap->phys_addr) is valid when enable is |
| 134 | true and will not change while the CEC adapter remains enabled. The initial |
| 135 | state of the CEC adapter after calling cec_allocate_adapter() is disabled. |
| 136 | |
| 137 | Note that adap_enable must return 0 if enable is false. |
| 138 | |
| 139 | |
| 140 | To enable/disable the 'monitor all' mode: |
| 141 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 142 | .. c:function:: |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 143 | int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable); |
| 144 | |
| 145 | If enabled, then the adapter should be put in a mode to also monitor messages |
| 146 | that not for us. Not all hardware supports this and this function is only |
| 147 | called if the CEC_CAP_MONITOR_ALL capability is set. This callback is optional |
| 148 | (some hardware may always be in 'monitor all' mode). |
| 149 | |
| 150 | Note that adap_monitor_all_enable must return 0 if enable is false. |
| 151 | |
| 152 | |
Hans Verkuil | 15ae0be | 2017-11-23 09:05:06 -0500 | [diff] [blame] | 153 | To enable/disable the 'monitor pin' mode: |
| 154 | |
| 155 | .. c:function:: |
| 156 | int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable); |
| 157 | |
| 158 | If enabled, then the adapter should be put in a mode to also monitor CEC pin |
| 159 | changes. Not all hardware supports this and this function is only called if |
| 160 | the CEC_CAP_MONITOR_PIN capability is set. This callback is optional |
| 161 | (some hardware may always be in 'monitor pin' mode). |
| 162 | |
| 163 | Note that adap_monitor_pin_enable must return 0 if enable is false. |
| 164 | |
| 165 | |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 166 | To program a new logical address: |
| 167 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 168 | .. c:function:: |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 169 | int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); |
| 170 | |
| 171 | If logical_addr == CEC_LOG_ADDR_INVALID then all programmed logical addresses |
| 172 | are to be erased. Otherwise the given logical address should be programmed. |
| 173 | If the maximum number of available logical addresses is exceeded, then it |
| 174 | should return -ENXIO. Once a logical address is programmed the CEC hardware |
| 175 | can receive directed messages to that address. |
| 176 | |
| 177 | Note that adap_log_addr must return 0 if logical_addr is CEC_LOG_ADDR_INVALID. |
| 178 | |
| 179 | |
| 180 | To transmit a new message: |
| 181 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 182 | .. c:function:: |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 183 | int (*adap_transmit)(struct cec_adapter *adap, u8 attempts, |
| 184 | u32 signal_free_time, struct cec_msg *msg); |
| 185 | |
| 186 | This transmits a new message. The attempts argument is the suggested number of |
| 187 | attempts for the transmit. |
| 188 | |
| 189 | The signal_free_time is the number of data bit periods that the adapter should |
| 190 | wait when the line is free before attempting to send a message. This value |
| 191 | depends on whether this transmit is a retry, a message from a new initiator or |
| 192 | a new message for the same initiator. Most hardware will handle this |
| 193 | automatically, but in some cases this information is needed. |
| 194 | |
| 195 | The CEC_FREE_TIME_TO_USEC macro can be used to convert signal_free_time to |
| 196 | microseconds (one data bit period is 2.4 ms). |
| 197 | |
| 198 | |
| 199 | To log the current CEC hardware status: |
| 200 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 201 | .. c:function:: |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 202 | void (*adap_status)(struct cec_adapter *adap, struct seq_file *file); |
| 203 | |
| 204 | This optional callback can be used to show the status of the CEC hardware. |
| 205 | The status is available through debugfs: cat /sys/kernel/debug/cec/cecX/status |
| 206 | |
Hans Verkuil | f987cde | 2017-07-11 03:30:37 -0300 | [diff] [blame] | 207 | To free any resources when the adapter is deleted: |
| 208 | |
| 209 | .. c:function:: |
| 210 | void (*adap_free)(struct cec_adapter *adap); |
| 211 | |
| 212 | This optional callback can be used to free any resources that might have been |
| 213 | allocated by the driver. It's called from cec_delete_adapter. |
| 214 | |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 215 | |
| 216 | Your adapter driver will also have to react to events (typically interrupt |
| 217 | driven) by calling into the framework in the following situations: |
| 218 | |
| 219 | When a transmit finished (successfully or otherwise): |
| 220 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 221 | .. c:function:: |
| 222 | void cec_transmit_done(struct cec_adapter *adap, u8 status, u8 arb_lost_cnt, |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 223 | u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt); |
| 224 | |
Hans Verkuil | c94cdc1 | 2017-06-07 11:46:10 -0300 | [diff] [blame] | 225 | or: |
| 226 | |
| 227 | .. c:function:: |
| 228 | void cec_transmit_attempt_done(struct cec_adapter *adap, u8 status); |
| 229 | |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 230 | The status can be one of: |
| 231 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 232 | CEC_TX_STATUS_OK: |
| 233 | the transmit was successful. |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 234 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 235 | CEC_TX_STATUS_ARB_LOST: |
| 236 | arbitration was lost: another CEC initiator |
| 237 | took control of the CEC line and you lost the arbitration. |
| 238 | |
| 239 | CEC_TX_STATUS_NACK: |
| 240 | the message was nacked (for a directed message) or |
| 241 | acked (for a broadcast message). A retransmission is needed. |
| 242 | |
| 243 | CEC_TX_STATUS_LOW_DRIVE: |
| 244 | low drive was detected on the CEC bus. This indicates that |
| 245 | a follower detected an error on the bus and requested a |
| 246 | retransmission. |
| 247 | |
| 248 | CEC_TX_STATUS_ERROR: |
Hans Verkuil | da634f6 | 2017-09-18 05:23:57 -0400 | [diff] [blame] | 249 | some unspecified error occurred: this can be one of ARB_LOST |
| 250 | or LOW_DRIVE if the hardware cannot differentiate or something |
Hans Verkuil | 6aecad6 | 2018-05-15 03:21:01 -0400 | [diff] [blame] | 251 | else entirely. Some hardware only supports OK and FAIL as the |
| 252 | result of a transmit, i.e. there is no way to differentiate |
| 253 | between the different possible errors. In that case map FAIL |
| 254 | to CEC_TX_STATUS_NACK and not to CEC_TX_STATUS_ERROR. |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 255 | |
| 256 | CEC_TX_STATUS_MAX_RETRIES: |
| 257 | could not transmit the message after trying multiple times. |
| 258 | Should only be set by the driver if it has hardware support for |
| 259 | retrying messages. If set, then the framework assumes that it |
| 260 | doesn't have to make another attempt to transmit the message |
| 261 | since the hardware did that already. |
| 262 | |
Hans Verkuil | da634f6 | 2017-09-18 05:23:57 -0400 | [diff] [blame] | 263 | The hardware must be able to differentiate between OK, NACK and 'something |
| 264 | else'. |
| 265 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 266 | The \*_cnt arguments are the number of error conditions that were seen. |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 267 | This may be 0 if no information is available. Drivers that do not support |
| 268 | hardware retry can just set the counter corresponding to the transmit error |
| 269 | to 1, if the hardware does support retry then either set these counters to |
| 270 | 0 if the hardware provides no feedback of which errors occurred and how many |
| 271 | times, or fill in the correct values as reported by the hardware. |
| 272 | |
Hans Verkuil | 81e3327 | 2018-10-05 08:58:12 -0400 | [diff] [blame] | 273 | Be aware that calling these functions can immediately start a new transmit |
| 274 | if there is one pending in the queue. So make sure that the hardware is in |
| 275 | a state where new transmits can be started *before* calling these functions. |
| 276 | |
Hans Verkuil | c94cdc1 | 2017-06-07 11:46:10 -0300 | [diff] [blame] | 277 | The cec_transmit_attempt_done() function is a helper for cases where the |
| 278 | hardware never retries, so the transmit is always for just a single |
| 279 | attempt. It will call cec_transmit_done() in turn, filling in 1 for the |
| 280 | count argument corresponding to the status. Or all 0 if the status was OK. |
| 281 | |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 282 | When a CEC message was received: |
| 283 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 284 | .. c:function:: |
| 285 | void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg); |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 286 | |
| 287 | Speaks for itself. |
| 288 | |
Hans Verkuil | e92ca73 | 2016-11-09 06:00:53 -0200 | [diff] [blame] | 289 | Implementing the interrupt handler |
| 290 | ---------------------------------- |
| 291 | |
| 292 | Typically the CEC hardware provides interrupts that signal when a transmit |
| 293 | finished and whether it was successful or not, and it provides and interrupt |
| 294 | when a CEC message was received. |
| 295 | |
| 296 | The CEC driver should always process the transmit interrupts first before |
| 297 | handling the receive interrupt. The framework expects to see the cec_transmit_done |
| 298 | call before the cec_received_msg call, otherwise it can get confused if the |
| 299 | received message was in reply to the transmitted message. |
| 300 | |
Hans Verkuil | 6902c88 | 2018-02-25 06:05:55 -0500 | [diff] [blame] | 301 | Optional: Implementing Error Injection Support |
| 302 | ---------------------------------------------- |
| 303 | |
| 304 | If the CEC adapter supports Error Injection functionality, then that can |
| 305 | be exposed through the Error Injection callbacks: |
| 306 | |
| 307 | .. code-block:: none |
| 308 | |
| 309 | struct cec_adap_ops { |
| 310 | /* Low-level callbacks */ |
| 311 | ... |
| 312 | |
| 313 | /* Error injection callbacks */ |
| 314 | int (*error_inj_show)(struct cec_adapter *adap, struct seq_file *sf); |
| 315 | bool (*error_inj_parse_line)(struct cec_adapter *adap, char *line); |
| 316 | |
| 317 | /* High-level CEC message callback */ |
| 318 | ... |
| 319 | }; |
| 320 | |
| 321 | If both callbacks are set, then an ``error-inj`` file will appear in debugfs. |
| 322 | The basic syntax is as follows: |
| 323 | |
| 324 | Leading spaces/tabs are ignored. If the next character is a ``#`` or the end of the |
| 325 | line was reached, then the whole line is ignored. Otherwise a command is expected. |
| 326 | |
| 327 | This basic parsing is done in the CEC Framework. It is up to the driver to decide |
| 328 | what commands to implement. The only requirement is that the command ``clear`` without |
| 329 | any arguments must be implemented and that it will remove all current error injection |
| 330 | commands. |
| 331 | |
| 332 | This ensures that you can always do ``echo clear >error-inj`` to clear any error |
| 333 | injections without having to know the details of the driver-specific commands. |
| 334 | |
| 335 | Note that the output of ``error-inj`` shall be valid as input to ``error-inj``. |
| 336 | So this must work: |
| 337 | |
| 338 | .. code-block:: none |
| 339 | |
| 340 | $ cat error-inj >einj.txt |
| 341 | $ cat einj.txt >error-inj |
| 342 | |
| 343 | The first callback is called when this file is read and it should show the |
| 344 | the current error injection state: |
| 345 | |
| 346 | .. c:function:: |
| 347 | int (*error_inj_show)(struct cec_adapter *adap, struct seq_file *sf); |
| 348 | |
| 349 | It is recommended that it starts with a comment block with basic usage |
| 350 | information. It returns 0 for success and an error otherwise. |
| 351 | |
| 352 | The second callback will parse commands written to the ``error-inj`` file: |
| 353 | |
| 354 | .. c:function:: |
| 355 | bool (*error_inj_parse_line)(struct cec_adapter *adap, char *line); |
| 356 | |
| 357 | The ``line`` argument points to the start of the command. Any leading |
| 358 | spaces or tabs have already been skipped. It is a single line only (so there |
| 359 | are no embedded newlines) and it is 0-terminated. The callback is free to |
| 360 | modify the contents of the buffer. It is only called for lines containing a |
| 361 | command, so this callback is never called for empty lines or comment lines. |
| 362 | |
| 363 | Return true if the command was valid or false if there were syntax errors. |
| 364 | |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 365 | Implementing the High-Level CEC Adapter |
| 366 | --------------------------------------- |
| 367 | |
| 368 | The low-level operations drive the hardware, the high-level operations are |
| 369 | CEC protocol driven. The following high-level callbacks are available: |
| 370 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 371 | .. code-block:: none |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 372 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 373 | struct cec_adap_ops { |
Hans Verkuil | e92ca73 | 2016-11-09 06:00:53 -0200 | [diff] [blame] | 374 | /* Low-level callbacks */ |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 375 | ... |
| 376 | |
Hans Verkuil | 6902c88 | 2018-02-25 06:05:55 -0500 | [diff] [blame] | 377 | /* Error injection callbacks */ |
| 378 | ... |
| 379 | |
Hans Verkuil | e92ca73 | 2016-11-09 06:00:53 -0200 | [diff] [blame] | 380 | /* High-level CEC message callback */ |
| 381 | int (*received)(struct cec_adapter *adap, struct cec_msg *msg); |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 382 | }; |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 383 | |
| 384 | The received() callback allows the driver to optionally handle a newly |
| 385 | received CEC message |
| 386 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 387 | .. c:function:: |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 388 | int (*received)(struct cec_adapter *adap, struct cec_msg *msg); |
| 389 | |
| 390 | If the driver wants to process a CEC message, then it can implement this |
| 391 | callback. If it doesn't want to handle this message, then it should return |
| 392 | -ENOMSG, otherwise the CEC framework assumes it processed this message and |
Hans Verkuil | e92ca73 | 2016-11-09 06:00:53 -0200 | [diff] [blame] | 393 | it will not do anything with it. |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 394 | |
| 395 | |
| 396 | CEC framework functions |
| 397 | ----------------------- |
| 398 | |
| 399 | CEC Adapter drivers can call the following CEC framework functions: |
| 400 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 401 | .. c:function:: |
| 402 | int cec_transmit_msg(struct cec_adapter *adap, struct cec_msg *msg, |
| 403 | bool block); |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 404 | |
| 405 | Transmit a CEC message. If block is true, then wait until the message has been |
| 406 | transmitted, otherwise just queue it and return. |
| 407 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 408 | .. c:function:: |
| 409 | void cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr, |
| 410 | bool block); |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 411 | |
| 412 | Change the physical address. This function will set adap->phys_addr and |
| 413 | send an event if it has changed. If cec_s_log_addrs() has been called and |
| 414 | the physical address has become valid, then the CEC framework will start |
| 415 | claiming the logical addresses. If block is true, then this function won't |
| 416 | return until this process has finished. |
| 417 | |
| 418 | When the physical address is set to a valid value the CEC adapter will |
| 419 | be enabled (see the adap_enable op). When it is set to CEC_PHYS_ADDR_INVALID, |
| 420 | then the CEC adapter will be disabled. If you change a valid physical address |
| 421 | to another valid physical address, then this function will first set the |
| 422 | address to CEC_PHYS_ADDR_INVALID before enabling the new physical address. |
| 423 | |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 424 | .. c:function:: |
Hans Verkuil | 23111ec | 2017-06-07 11:46:08 -0300 | [diff] [blame] | 425 | void cec_s_phys_addr_from_edid(struct cec_adapter *adap, |
| 426 | const struct edid *edid); |
| 427 | |
| 428 | A helper function that extracts the physical address from the edid struct |
| 429 | and calls cec_s_phys_addr() with that address, or CEC_PHYS_ADDR_INVALID |
| 430 | if the EDID did not contain a physical address or edid was a NULL pointer. |
| 431 | |
| 432 | .. c:function:: |
Mauro Carvalho Chehab | 9486f2b | 2016-08-19 08:46:13 -0300 | [diff] [blame] | 433 | int cec_s_log_addrs(struct cec_adapter *adap, |
| 434 | struct cec_log_addrs *log_addrs, bool block); |
Hans Verkuil | efe2938 | 2015-05-04 14:32:59 -0300 | [diff] [blame] | 435 | |
| 436 | Claim the CEC logical addresses. Should never be called if CEC_CAP_LOG_ADDRS |
| 437 | is set. If block is true, then wait until the logical addresses have been |
| 438 | claimed, otherwise just queue it and return. To unconfigure all logical |
| 439 | addresses call this function with log_addrs set to NULL or with |
| 440 | log_addrs->num_log_addrs set to 0. The block argument is ignored when |
| 441 | unconfiguring. This function will just return if the physical address is |
| 442 | invalid. Once the physical address becomes valid, then the framework will |
| 443 | attempt to claim these logical addresses. |
Hans Verkuil | ab2ec7a | 2017-07-11 03:30:43 -0300 | [diff] [blame] | 444 | |
| 445 | CEC Pin framework |
| 446 | ----------------- |
| 447 | |
| 448 | Most CEC hardware operates on full CEC messages where the software provides |
| 449 | the message and the hardware handles the low-level CEC protocol. But some |
| 450 | hardware only drives the CEC pin and software has to handle the low-level |
| 451 | CEC protocol. The CEC pin framework was created to handle such devices. |
| 452 | |
| 453 | Note that due to the close-to-realtime requirements it can never be guaranteed |
| 454 | to work 100%. This framework uses highres timers internally, but if a |
| 455 | timer goes off too late by more than 300 microseconds wrong results can |
| 456 | occur. In reality it appears to be fairly reliable. |
| 457 | |
| 458 | One advantage of this low-level implementation is that it can be used as |
| 459 | a cheap CEC analyser, especially if interrupts can be used to detect |
| 460 | CEC pin transitions from low to high or vice versa. |
| 461 | |
| 462 | .. kernel-doc:: include/media/cec-pin.h |
| 463 | |
| 464 | CEC Notifier framework |
Mauro Carvalho Chehab | 177894b | 2017-07-19 14:29:06 -0400 | [diff] [blame] | 465 | ---------------------- |
Hans Verkuil | ab2ec7a | 2017-07-11 03:30:43 -0300 | [diff] [blame] | 466 | |
| 467 | Most drm HDMI implementations have an integrated CEC implementation and no |
| 468 | notifier support is needed. But some have independent CEC implementations |
| 469 | that have their own driver. This could be an IP block for an SoC or a |
| 470 | completely separate chip that deals with the CEC pin. For those cases a |
| 471 | drm driver can install a notifier and use the notifier to inform the |
| 472 | CEC driver about changes in the physical address. |
| 473 | |
| 474 | .. kernel-doc:: include/media/cec-notifier.h |