linux

media: include/(uapi/)media: add SPDX license info Replace the old license information with the corresponding SPDX license for those headers that I authored. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2018-02-07 09:05:46 -05:00

2016-06-25 09:43:58 -03:00

media: cec: add struct cec_connector_info support Define struct cec_connector_info in media/cec.h and define CEC_CAP_CONNECTOR_INFO. In a later patch this will be moved to uapi/linux/cec.h. The CEC_CAP_CONNECTOR_INFO capability can be set by drivers, but cec_allocate_adapter() will remove it again until the public API for this can be enabled once all drm drivers wire this up correctly. Also add the cec_fill_conn_info_from_drm and cec_s_conn_info functions, which are needed by drm drivers to fill in the cec_connector info based on a drm_connector. The cec_notifier_(un)register and cec_register_cec_notifier prototypes were moved from cec-notifier.h to cec.h since cec.h no longer includes cec-notifier.h. These headers included each other before, which caused various problems. Due to these changes the seco-cec driver was changed as well: it should include cec-notifier.h, not cec.h. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2019-06-20 05:17:18 -04:00

media: media/cec.h: add CEC_CAP_DEFAULTS The CEC_CAP_LOG_ADDRS, CEC_CAP_TRANSMIT, CEC_CAP_PASSTHROUGH and CEC_CAP_RC capabilities are normally always present. Add a CEC_CAP_DEFAULTS define that ORs these four caps to simplify drivers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-08-04 06:41:51 -04:00

2016-06-25 09:43:58 -03:00

media: cec: fix a deadlock situation The cec_devnode struct has a lock meant to serialize access to the fields of this struct. This lock is taken during device node (un)registration and when opening or releasing a filehandle to the device node. When the last open filehandle is closed the cec adapter might be disabled by calling the adap_enable driver callback with the devnode.lock held. However, if during that callback a message or event arrives then the driver will call one of the cec_queue_event() variants in cec-adap.c, and those will take the same devnode.lock to walk the open filehandle list. This obviously causes a deadlock. This is quite easy to reproduce with the cec-gpio driver since that uses the cec-pin framework which generated lots of events and uses a kernel thread for the processing, so when adap_enable is called the thread is still running and can generate events. But I suspect that it might also happen with other drivers if an interrupt arrives signaling e.g. a received message before adap_enable had a chance to disable the interrupts. This patch adds a new mutex to serialize access to the fhs list. When adap_enable() is called the devnode.lock mutex is held, but not devnode.lock_fhs. The event functions in cec-adap.c will now use devnode.lock_fhs instead of devnode.lock, ensuring that it is safe to call those functions from the adap_enable callback. This specific issue only happens if the last open filehandle is closed and the physical address is invalid. This is not something that happens during normal operation, but it does happen when monitoring CEC traffic (e.g. cec-ctl --monitor) with an unconfigured CEC adapter. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v5.13 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2021-12-01 13:41:26 +01:00

2016-06-25 09:43:58 -03:00

media: cec: fix a deadlock situation The cec_devnode struct has a lock meant to serialize access to the fields of this struct. This lock is taken during device node (un)registration and when opening or releasing a filehandle to the device node. When the last open filehandle is closed the cec adapter might be disabled by calling the adap_enable driver callback with the devnode.lock held. However, if during that callback a message or event arrives then the driver will call one of the cec_queue_event() variants in cec-adap.c, and those will take the same devnode.lock to walk the open filehandle list. This obviously causes a deadlock. This is quite easy to reproduce with the cec-gpio driver since that uses the cec-pin framework which generated lots of events and uses a kernel thread for the processing, so when adap_enable is called the thread is still running and can generate events. But I suspect that it might also happen with other drivers if an interrupt arrives signaling e.g. a received message before adap_enable had a chance to disable the interrupts. This patch adds a new mutex to serialize access to the fhs list. When adap_enable() is called the devnode.lock mutex is held, but not devnode.lock_fhs. The event functions in cec-adap.c will now use devnode.lock_fhs instead of devnode.lock, ensuring that it is safe to call those functions from the adap_enable callback. This specific issue only happens if the last open filehandle is closed and the physical address is invalid. This is not something that happens during normal operation, but it does happen when monitoring CEC traffic (e.g. cec-ctl --monitor) with an unconfigured CEC adapter. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v5.13 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2021-12-01 13:41:26 +01:00

2016-06-25 09:43:58 -03:00

media: cec: fix a deadlock situation The cec_devnode struct has a lock meant to serialize access to the fields of this struct. This lock is taken during device node (un)registration and when opening or releasing a filehandle to the device node. When the last open filehandle is closed the cec adapter might be disabled by calling the adap_enable driver callback with the devnode.lock held. However, if during that callback a message or event arrives then the driver will call one of the cec_queue_event() variants in cec-adap.c, and those will take the same devnode.lock to walk the open filehandle list. This obviously causes a deadlock. This is quite easy to reproduce with the cec-gpio driver since that uses the cec-pin framework which generated lots of events and uses a kernel thread for the processing, so when adap_enable is called the thread is still running and can generate events. But I suspect that it might also happen with other drivers if an interrupt arrives signaling e.g. a received message before adap_enable had a chance to disable the interrupts. This patch adds a new mutex to serialize access to the fhs list. When adap_enable() is called the devnode.lock mutex is held, but not devnode.lock_fhs. The event functions in cec-adap.c will now use devnode.lock_fhs instead of devnode.lock, ensuring that it is safe to call those functions from the adap_enable callback. This specific issue only happens if the last open filehandle is closed and the physical address is invalid. This is not something that happens during normal operation, but it does happen when monitoring CEC traffic (e.g. cec-ctl --monitor) with an unconfigured CEC adapter. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v5.13 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2021-12-01 13:41:26 +01:00

2016-06-25 09:43:58 -03:00

media: cec: fix a deadlock situation The cec_devnode struct has a lock meant to serialize access to the fields of this struct. This lock is taken during device node (un)registration and when opening or releasing a filehandle to the device node. When the last open filehandle is closed the cec adapter might be disabled by calling the adap_enable driver callback with the devnode.lock held. However, if during that callback a message or event arrives then the driver will call one of the cec_queue_event() variants in cec-adap.c, and those will take the same devnode.lock to walk the open filehandle list. This obviously causes a deadlock. This is quite easy to reproduce with the cec-gpio driver since that uses the cec-pin framework which generated lots of events and uses a kernel thread for the processing, so when adap_enable is called the thread is still running and can generate events. But I suspect that it might also happen with other drivers if an interrupt arrives signaling e.g. a received message before adap_enable had a chance to disable the interrupts. This patch adds a new mutex to serialize access to the fhs list. When adap_enable() is called the devnode.lock mutex is held, but not devnode.lock_fhs. The event functions in cec-adap.c will now use devnode.lock_fhs instead of devnode.lock, ensuring that it is safe to call those functions from the adap_enable callback. This specific issue only happens if the last open filehandle is closed and the physical address is invalid. This is not something that happens during normal operation, but it does happen when monitoring CEC traffic (e.g. cec-ctl --monitor) with an unconfigured CEC adapter. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v5.13 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2021-12-01 13:41:26 +01:00

2016-06-25 09:43:58 -03:00

media: cec: fix a deadlock situation The cec_devnode struct has a lock meant to serialize access to the fields of this struct. This lock is taken during device node (un)registration and when opening or releasing a filehandle to the device node. When the last open filehandle is closed the cec adapter might be disabled by calling the adap_enable driver callback with the devnode.lock held. However, if during that callback a message or event arrives then the driver will call one of the cec_queue_event() variants in cec-adap.c, and those will take the same devnode.lock to walk the open filehandle list. This obviously causes a deadlock. This is quite easy to reproduce with the cec-gpio driver since that uses the cec-pin framework which generated lots of events and uses a kernel thread for the processing, so when adap_enable is called the thread is still running and can generate events. But I suspect that it might also happen with other drivers if an interrupt arrives signaling e.g. a received message before adap_enable had a chance to disable the interrupts. This patch adds a new mutex to serialize access to the fhs list. When adap_enable() is called the devnode.lock mutex is held, but not devnode.lock_fhs. The event functions in cec-adap.c will now use devnode.lock_fhs instead of devnode.lock, ensuring that it is safe to call those functions from the adap_enable callback. This specific issue only happens if the last open filehandle is closed and the physical address is invalid. This is not something that happens during normal operation, but it does happen when monitoring CEC traffic (e.g. cec-ctl --monitor) with an unconfigured CEC adapter. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v5.13 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2021-12-01 13:41:26 +01:00

2016-06-25 09:43:58 -03:00

media: cec-pin: add low-level pin hardware support Add support for CEC hardware that relies on low-level pin polling or GPIO interrupts. One example is the Allwinner SoC. But any GPIO-based CEC implementation can use this as well. A GPIO implementation is very suitable as well for debugging: it can use interrupts to detect state changes and report it. Userspace can then verify if the bus traffic is correct. This also makes error injection possible. The disadvantage is that it is hard to get the timings right since linux isn't a hard realtime system. In general on an idle system it works quite well, but under load the timer will miss its mark every so often. The debugfs file /sys/kernel/debug/cec/cecX/status gives some statistics with respect to the timer overruns. When the adapter is unconfigured and the low-level driver supports interrupts, then the interrupt will be used to detect changes. This should be quite accurate. But when the adapter is configured a hrtimer has to be used. The hrtimer implements a state machine where for each state the code will read the bus or drive the bus and go on to the next state. It will re-arm the timer with a delay based on the next state. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:42 -03:00

media: cec: add struct cec_connector_info support Define struct cec_connector_info in media/cec.h and define CEC_CAP_CONNECTOR_INFO. In a later patch this will be moved to uapi/linux/cec.h. The CEC_CAP_CONNECTOR_INFO capability can be set by drivers, but cec_allocate_adapter() will remove it again until the public API for this can be enabled once all drm drivers wire this up correctly. Also add the cec_fill_conn_info_from_drm and cec_s_conn_info functions, which are needed by drm drivers to fill in the cec_connector info based on a drm_connector. The cec_notifier_(un)register and cec_register_cec_notifier prototypes were moved from cec-notifier.h to cec.h since cec.h no longer includes cec-notifier.h. These headers included each other before, which caused various problems. Due to these changes the seco-cec driver was changed as well: it should include cec-notifier.h, not cec.h. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2019-06-20 05:17:18 -04:00

2016-06-25 09:43:58 -03:00

media: cec: core: add new CEC_MSG_FL_REPLY_VENDOR_ID flag If this flag is set, then the reply is expected to consist of the CEC_MSG_VENDOR_COMMAND_WITH_ID opcode followed by the Vendor ID (as used in bytes 1-4 of the message), followed by the struct cec_msg reply field. Note that this assumes that the byte after the Vendor ID is a vendor-specific opcode. This flag makes it easier to wait for replies to vendor commands, using the same CEC framework support for waiting for regular replies. Support for this flag is indicated by setting the new CEC_CAP_REPLY_VENDOR_ID capability. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2024-07-04 11:01:51 +02:00

2016-06-25 09:43:58 -03:00

media: cec: rework the cec event handling Event handling was always fairly simplistic since there were only two events. With the addition of pin events this needed to be redesigned. The state_change and lost_msgs events are now core events with the guarantee that the last state is always available. The new pin events are a queue of events (up to 64 for each event) and the oldest event will be dropped if the application cannot keep up. Lost events are marked with a new event flag. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:39 -03:00

media: cec: add support for 5V signal testing Add support for the new 5V CEC events Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2018-06-28 07:43:46 -04:00

2016-06-25 09:43:58 -03:00

media: cec: rework the cec event handling Event handling was always fairly simplistic since there were only two events. With the addition of pin events this needed to be redesigned. The state_change and lost_msgs events are now core events with the guarantee that the last state is always available. The new pin events are a queue of events (up to 64 for each event) and the oldest event will be dropped if the application cannot keep up. Lost events are marked with a new event flag. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:39 -03:00

media: cec: improve CEC pin event handling It turns out that the struct cec_fh event buffer size of 64 events (64 for CEC_EVENT_PIN_CEC_LOW and 64 for _HIGH) is too small. It's about 160 ms worth of events and if the Raspberry Pi is busy, then it might take too long for the application to be scheduled so that it can drain the pending events. Increase these buffers to 800 events which is at least 2 seconds worth of events. There is also a FIFO in between the interrupt and the cec-pin thread. The thread passes the events on to the CEC core. It is important that should this FIFO fill up the cec core will be informed that events have been lost so this can be communicated to the user by setting CEC_EVENT_FL_DROPPED_EVENTS. It is very hard to debug CEC problems if events were lost without informing the user of that fact. If events were dropped due to the FIFO filling up, then the debugfs status file will let you know how many events were dropped. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2018-03-06 16:20:00 -05:00

media: cec: rework the cec event handling Event handling was always fairly simplistic since there were only two events. With the addition of pin events this needed to be redesigned. The state_change and lost_msgs events are now core events with the guarantee that the last state is always available. The new pin events are a queue of events (up to 64 for each event) and the oldest event will be dropped if the application cannot keep up. Lost events are marked with a new event flag. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:39 -03:00

2016-06-25 09:43:58 -03:00

media: cec: core: add adap_unconfigured() callback The adap_configured() callback was called with the adap->lock mutex held if the 'configured' argument was false, and without the adap->lock mutex held if that argument was true. That was very confusing, and so split this up in a adap_unconfigured() callback and a high-level configured() callback. This also makes it easier to understand when the mutex is held: all low-level adap_* callbacks are called with the mutex held. All other callbacks are called without that mutex held. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: f1b57164305d ("media: cec: add optional adap_configured callback") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2023-06-12 15:58:38 +02:00

2016-06-25 09:43:58 -03:00

media: cec: add the adap_monitor_pin_enable op Some devices can monitor the CEC pin using an interrupt, but you only want to enable the interrupt if you actually switch to pin monitoring mode. So add a new op that is called when pin monitoring needs to be switched on or off. Also fix a small bug where the initial CEC pin event was sent again when calling S_MODE twice with the same CEC_MODE_MONITOR_PIN mode. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-11-05 07:36:36 -05:00

2016-06-25 09:43:58 -03:00

media: cec: core: add adap_unconfigured() callback The adap_configured() callback was called with the adap->lock mutex held if the 'configured' argument was false, and without the adap->lock mutex held if that argument was true. That was very confusing, and so split this up in a adap_unconfigured() callback and a high-level configured() callback. This also makes it easier to understand when the mutex is held: all low-level adap_* callbacks are called with the mutex held. All other callbacks are called without that mutex held. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: f1b57164305d ("media: cec: add optional adap_configured callback") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2023-06-12 15:58:38 +02:00

2016-06-25 09:43:58 -03:00

media: cec: core: add adap_nb_transmit_canceled() callback A potential deadlock was found by Zheng Zhang with a local syzkaller instance. The problem is that when a non-blocking CEC transmit is canceled by calling cec_data_cancel, that in turn can call the high-level received() driver callback, which can call cec_transmit_msg() to transmit a new message. The cec_data_cancel() function is called with the adap->lock mutex held, and cec_transmit_msg() tries to take that same lock. The root cause is that the received() callback can either be used to pass on a received message (and then adap->lock is not held), or to report a canceled transmit (and then adap->lock is held). This is confusing, so create a new low-level adap_nb_transmit_canceled callback that reports back that a non-blocking transmit was canceled. And the received() callback is only called when a message is received, as was the case before commit f9d0ecbf56f4 ("media: cec: correctly pass on reply results") complicated matters. Reported-by: Zheng Zhang <zheng.zhang@email.ucr.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: f9d0ecbf56f4 ("media: cec: correctly pass on reply results") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2023-06-12 15:58:37 +02:00

2016-06-25 09:43:58 -03:00

media: cec: add adap_free op This is needed for CEC adapters that allocate resources that have to be freed before the cec_adapter is deleted. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:36 -03:00

2016-06-25 09:43:58 -03:00

media: cec: core: add adap_nb_transmit_canceled() callback A potential deadlock was found by Zheng Zhang with a local syzkaller instance. The problem is that when a non-blocking CEC transmit is canceled by calling cec_data_cancel, that in turn can call the high-level received() driver callback, which can call cec_transmit_msg() to transmit a new message. The cec_data_cancel() function is called with the adap->lock mutex held, and cec_transmit_msg() tries to take that same lock. The root cause is that the received() callback can either be used to pass on a received message (and then adap->lock is not held), or to report a canceled transmit (and then adap->lock is held). This is confusing, so create a new low-level adap_nb_transmit_canceled callback that reports back that a non-blocking transmit was canceled. And the received() callback is only called when a message is received, as was the case before commit f9d0ecbf56f4 ("media: cec: correctly pass on reply results") complicated matters. Reported-by: Zheng Zhang <zheng.zhang@email.ucr.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: f9d0ecbf56f4 ("media: cec: correctly pass on reply results") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2023-06-12 15:58:37 +02:00

media: cec: add core error injection support Add two new ops (error_inj_show and error_inj_parse_line) to support error injection functionality for CEC adapters. If both are present, then the core will add a new error-inj debugfs file that can be used to see the current error injection commands and to set error injection commands. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-10-31 09:55:09 -04:00

media: cec: core: add adap_nb_transmit_canceled() callback A potential deadlock was found by Zheng Zhang with a local syzkaller instance. The problem is that when a non-blocking CEC transmit is canceled by calling cec_data_cancel, that in turn can call the high-level received() driver callback, which can call cec_transmit_msg() to transmit a new message. The cec_data_cancel() function is called with the adap->lock mutex held, and cec_transmit_msg() tries to take that same lock. The root cause is that the received() callback can either be used to pass on a received message (and then adap->lock is not held), or to report a canceled transmit (and then adap->lock is held). This is confusing, so create a new low-level adap_nb_transmit_canceled callback that reports back that a non-blocking transmit was canceled. And the received() callback is only called when a message is received, as was the case before commit f9d0ecbf56f4 ("media: cec: correctly pass on reply results") complicated matters. Reported-by: Zheng Zhang <zheng.zhang@email.ucr.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: f9d0ecbf56f4 ("media: cec: correctly pass on reply results") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2023-06-12 15:58:37 +02:00

media: cec: core: add adap_unconfigured() callback The adap_configured() callback was called with the adap->lock mutex held if the 'configured' argument was false, and without the adap->lock mutex held if that argument was true. That was very confusing, and so split this up in a adap_unconfigured() callback and a high-level configured() callback. This also makes it easier to understand when the mutex is held: all low-level adap_* callbacks are called with the mutex held. All other callbacks are called without that mutex held. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: f1b57164305d ("media: cec: add optional adap_configured callback") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2023-06-12 15:58:38 +02:00

2016-06-25 09:43:58 -03:00

[media] cec: limit the size of the transmit queue The size of the transmit queue was unlimited, which meant that in non-blocking mode you could flood the CEC adapter with messages to be transmitted. Limit this to 18 messages. Also print the number of pending transmits and the timeout value in the status debugfs file. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2016-07-17 11:40:05 -03:00

2016-06-25 09:43:58 -03:00

[media] cec: limit the size of the transmit queue The size of the transmit queue was unlimited, which meant that in non-blocking mode you could flood the CEC adapter with messages to be transmitted. Limit this to 18 messages. Also print the number of pending transmits and the timeout value in the status debugfs file. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2016-07-17 11:40:05 -03:00

2016-06-25 09:43:58 -03:00

media: media/cec.h: document cec_adapter fields Document this core CEC structure. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2020-06-20 12:16:41 +02:00

media: cec: abort if the current transmit was canceled If a transmit-in-progress was canceled, then, once the transmit is done, mark it as aborted and refrain from retrying the transmit. To signal this situation the new transmit_in_progress_aborted field is set to true. The old implementation would just set adap->transmitting to NULL and set adap->transmit_in_progress to false, but on the hardware level the transmit was still ongoing. However, the framework would think the transmit was aborted, and if a new transmit was issued, then it could overwrite the HW buffer containing the old transmit with the new transmit, leading to garbled data on the CEC bus. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2022-03-03 14:01:44 +00:00

media: cec: add xfer_timeout_ms field Allow drivers to change the transmit timeout value, i.e. after how long should a transmit be considered 'lost', i.e. the corresponding cec_transmit_done_ts was never called. Some CEC devices have their own timeout, and so this timeout value must be longer than that hardware timeout value. If it is shorter then the framework would consider the transmit lost, even though it is effectively still in progress at the hardware level. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2021-11-13 11:05:24 +00:00

media: cec: cec.h: 2.1 ms -> 2100 ms The transfer timeout is 2100 ms, not 2.1 ms. Fix this in the kerneldoc comment. Link: https://lore.kernel.org/linux-media/17cd1a67-3966-237c-2e0d-2d3ae618f915@xs4all.nl Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2023-08-18 13:12:48 +01:00

media: media/cec.h: document cec_adapter fields Document this core CEC structure. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2020-06-20 12:16:41 +02:00

media: cec-adap.c: drop activate_cnt, use state info instead Using an activation counter to decide when the enable or disable the cec adapter is not the best approach and can lead to race conditions. Change this to determining the current status of the adapter, and enable or disable the adapter accordingly. It now only needs to be called whenever there is a chance that the state changes, and it can handle enabling/disabling monitoring as well if needed. This simplifies the code and it should be a more robust approach as well. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2022-05-10 10:53:05 +02:00

media: cec.h: Fix kerneldoc is_claiming_log_addrs documentation was missing. fix this kernel-doc warning: include/media/cec.h:296: warning: Function parameter or struct member 'is_claiming_log_addrs' not described in 'cec_adapter' Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

2024-05-03 11:33:20 +00:00

media: media/cec.h: document cec_adapter fields Document this core CEC structure. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2020-06-20 12:16:41 +02:00

media: cec-adap.c: reconfigure if the PA changes during configuration If the physical address changes (i.e. becomes invalid, then valid again) while the adapter is still claiming free logical addresses, then trigger a reconfiguration since any claimed LAs may now be stale. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2022-05-06 14:46:46 +02:00

media: media/cec.h: document cec_adapter fields Document this core CEC structure. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2020-06-20 12:16:41 +02:00

media: cec: add adap_controls_phys_addr option Use of the cec notifier framework is required to support CEC_CAP_CONNECTOR_INFO but some devices do not want physical address updates from the notifier. This adds an option to allow registering with a cec notifier without getting address updates. [hans: document the new adap_controls_phys_addr bool] Signed-off-by: Jeff Chase <jnchase@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2020-06-23 01:59:49 +02:00

media: media/cec.h: document cec_adapter fields Document this core CEC structure. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2020-06-20 12:16:41 +02:00

media: cec: core: count low-drive, error and arb-lost conditions Count how many Low Drive, Error and Arbitration Lost transmit status errors occurred, and expose that in debugfs. Also log the first 8 transmits that result in Low Drive or Error conditions. That really should not happen with well-behaved CEC devices and good HDMI cables. This is useful to detect and debug HDMI cable issues. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2023-10-11 10:17:59 +02:00

media: cec/core: add error-inj-tx-timeouts debugfs entry Add a new debugfs entry that makes it possible to do error injection of failing the next N transmits by a timeout. This can be used to test what happens in that case during the claiming of a free logical address. Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2026-07-10 13:07:36 +02:00

media: media/cec.h: document cec_adapter fields Document this core CEC structure. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2020-06-20 12:16:41 +02:00

2016-06-25 09:43:58 -03:00

[media] cec: limit the size of the transmit queue The size of the transmit queue was unlimited, which meant that in non-blocking mode you could flood the CEC adapter with messages to be transmitted. Limit this to 18 messages. Also print the number of pending transmits and the timeout value in the status debugfs file. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2016-07-17 11:40:05 -03:00

2016-06-25 09:43:58 -03:00

media: cec: keep track of outstanding transmits I noticed that repeatedly running 'cec-ctl --playback' would occasionally select 'Playback Device 2' instead of 'Playback Device 1', even though there were no other Playback devices in the HDMI topology. This happened both with 'real' hardware and with the vivid CEC emulation, suggesting that this was an issue in the core code that claims a logical address. What 'cec-ctl --playback' does is to first clear all existing logical addresses, and immediately after that configure the new desired device type. The core code will poll the logical addresses trying to find a free address. When found it will issue a few standard messages as per the CEC spec and return. Those messages are queued up and will be transmitted asynchronously. What happens is that if you run two 'cec-ctl --playback' commands in quick succession, there is still a message of the first cec-ctl command being transmitted when you reconfigure the adapter again in the second cec-ctl command. When the logical addresses are cleared, then all information about outstanding transmits inside the CEC core is also cleared, and the core is no longer aware that there is still a transmit in flight. When the hardware finishes the transmit it calls transmit_done and the CEC core thinks it is actually in response of a POLL messages that is trying to find a free logical address. The result of all this is that the core thinks that the logical address for Playback Device 1 is in use, when it is really an earlier transmit that ended. The main transmit thread looks at adap->transmitting to check if a transmit is in progress, but that is set to NULL when the adapter is unconfigured. adap->transmitting represents the view of userspace, not that of the hardware. So when unconfiguring the adapter the message is marked aborted from the point of view of userspace, but seen from the PoV of the hardware it is still ongoing. So introduce a new bool transmit_in_progress that represents the hardware state and use that instead of adap->transmitting. Now the CEC core waits until the hardware finishes the transmit before starting a new transmit. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v4.18 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2018-10-19 03:55:34 -04:00

media: cec: abort if the current transmit was canceled If a transmit-in-progress was canceled, then, once the transmit is done, mark it as aborted and refrain from retrying the transmit. To signal this situation the new transmit_in_progress_aborted field is set to true. The old implementation would just set adap->transmitting to NULL and set adap->transmit_in_progress to false, but on the hardware level the transmit was still ongoing. However, the framework would think the transmit was aborted, and if a new transmit was issued, then it could overwrite the HW buffer containing the old transmit with the new transmit, leading to garbled data on the CEC bus. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2022-03-03 14:01:44 +00:00

media: cec: add xfer_timeout_ms field Allow drivers to change the transmit timeout value, i.e. after how long should a transmit be considered 'lost', i.e. the corresponding cec_transmit_done_ts was never called. Some CEC devices have their own timeout, and so this timeout value must be longer than that hardware timeout value. If it is shorter then the framework would consider the transmit lost, even though it is effectively still in progress at the hardware level. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2021-11-13 11:05:24 +00:00

2016-06-25 09:43:58 -03:00

[media] cec: add CEC_CAP_NEEDS_HPD Add a new capability CEC_CAP_NEEDS_HPD. If this capability is set then the hardware can only use CEC if the HDMI Hotplug Detect pin is high. Such hardware cannot handle the corner case in the CEC specification where it is possible to transmit messages even if no hotplug signal is present (needed for some displays that turn off the HPD when in standby, but still have CEC enabled). Typically hardware that needs this capability have the HPD wired to the CEC block, often to a 'power' or 'active' pin. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-06-07 11:46:12 -03:00

media: cec-adap.c: drop activate_cnt, use state info instead Using an activation counter to decide when the enable or disable the cec adapter is not the best approach and can lead to race conditions. Change this to determining the current status of the adapter, and enable or disable the adapter accordingly. It now only needs to be called whenever there is a chance that the state changes, and it can handle enabling/disabling monitoring as well if needed. This simplifies the code and it should be a more robust approach as well. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2022-05-10 10:53:05 +02:00

media: cec: core: avoid recursive cec_claim_log_addrs Keep track if cec_claim_log_addrs() is running, and return -EBUSY if it is when calling CEC_ADAP_S_LOG_ADDRS. This prevents a case where cec_claim_log_addrs() could be called while it was still in progress. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by: Yang, Chenyuan <cy54@illinois.edu> Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/ Fixes: ca684386e6e2 ("[media] cec: add HDMI CEC framework (api)") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2024-02-22 16:17:33 +00:00

2016-06-25 09:43:58 -03:00

media: cec-adap.c: reconfigure if the PA changes during configuration If the physical address changes (i.e. becomes invalid, then valid again) while the adapter is still claiming free logical addresses, then trigger a reconfiguration since any claimed LAs may now be stale. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2022-05-06 14:46:46 +02:00

2016-06-25 09:43:58 -03:00

media: cec: replace pin->cur_value by adap->cec_pin_is_high The current CEC pin value (0 or 1) was part of the cec_pin struct, but that assumes that CEC pin monitoring can only be used with a driver that uses the low-level CEC pin framework. But hardware that has both a high-level API and can monitor the CEC pin at low-level at the same time does not need to depend on the cec pin framework. To support such devices remove the cur_value field from struct cec_pin and add a cec_pin_is_high field to cec_adapter. This also makes it possible to drop the '#ifdef CONFIG_CEC_PIN' in cec-api.c. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-08-20 06:53:10 -04:00

media: cec: add adap_controls_phys_addr option Use of the cec notifier framework is required to support CEC_CAP_CONNECTOR_INFO but some devices do not want physical address updates from the notifier. This adds an option to allow registering with a cec notifier without getting address updates. [hans: document the new adap_controls_phys_addr bool] Signed-off-by: Jeff Chase <jnchase@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2020-06-23 01:59:49 +02:00

media: cec: fix the Signal Free Time calculation The calculation of the Signal Free Time in the framework was not correct. If a message was received, then the next transmit should be considered a New Initiator and use a shorter SFT value. This was not done with the result that if both sides where continually sending messages, they both could use the same SFT value and one side could deny the other side access to the bus. Note that this fix does not take the corner case into account where a receive is in progress when you call adap_transmit. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: <stable@vger.kernel.org> # for v4.18 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2018-10-05 08:00:21 -04:00

2016-06-25 09:43:58 -03:00

media: cec: add core support for low-level CEC pin monitoring Add support for the new MONITOR_PIN mode. Add the cec_pin_event function that the CEC pin code will call to queue pin change events. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:41 -03:00

2016-06-25 09:43:58 -03:00

media: cec: add struct cec_connector_info support Define struct cec_connector_info in media/cec.h and define CEC_CAP_CONNECTOR_INFO. In a later patch this will be moved to uapi/linux/cec.h. The CEC_CAP_CONNECTOR_INFO capability can be set by drivers, but cec_allocate_adapter() will remove it again until the public API for this can be enabled once all drm drivers wire this up correctly. Also add the cec_fill_conn_info_from_drm and cec_s_conn_info functions, which are needed by drm drivers to fill in the cec_connector info based on a drm_connector. The cec_notifier_(un)register and cec_register_cec_notifier prototypes were moved from cec-notifier.h to cec.h since cec.h no longer includes cec-notifier.h. These headers included each other before, which caused various problems. Due to these changes the seco-cec driver was changed as well: it should include cec-notifier.h, not cec.h. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2019-06-20 05:17:18 -04:00

2016-06-25 09:43:58 -03:00

media: cec: core: count low-drive, error and arb-lost conditions Count how many Low Drive, Error and Arbitration Lost transmit status errors occurred, and expose that in debugfs. Also log the first 8 transmits that result in Low Drive or Error conditions. That really should not happen with well-behaved CEC devices and good HDMI cables. This is useful to detect and debug HDMI cable issues. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

2023-10-11 10:17:59 +02:00

media: cec: improve transmit timeout logging Kernel logging messes up the upcoming low-level CEC monitoring support which is very time-sensitive. So change the debug level of this message but keep a counter that is shown in the debugfs status log. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:34 -03:00

media: cec/core: add error-inj-tx-timeouts debugfs entry Add a new debugfs entry that makes it possible to do error injection of failing the next N transmits by a timeout. This can be used to test what happens in that case during the claiming of a free logical address. Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2026-07-10 13:07:36 +02:00

[media] cec: rename MEDIA_CEC_NOTIFIER to CEC_NOTIFIER This config option is strictly speaking independent of the media subsystem since it can be used by drm as well. Besides, it looks odd when drivers select CEC_CORE and MEDIA_CEC_NOTIFIER, that's inconsistent naming. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-05-28 05:58:04 -03:00

[media] cec: integrate CEC notifier support Support the CEC notifier framework, simplifying drivers that depend on this. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2016-12-13 12:15:57 -02:00

media: cec-pin: add low-level pin hardware support Add support for CEC hardware that relies on low-level pin polling or GPIO interrupts. One example is the Allwinner SoC. But any GPIO-based CEC implementation can use this as well. A GPIO implementation is very suitable as well for debugging: it can use interrupts to detect state changes and report it. Userspace can then verify if the bus traffic is correct. This also makes error injection possible. The disadvantage is that it is hard to get the timings right since linux isn't a hard realtime system. In general on an idle system it works quite well, but under load the timer will miss its mark every so often. The debugfs file /sys/kernel/debug/cec/cecX/status gives some statistics with respect to the timer overruns. When the adapter is unconfigured and the low-level driver supports interrupts, then the interrupt will be used to detect changes. This should be quite accurate. But when the adapter is configured a hrtimer has to be used. The hrtimer implements a state machine where for each state the code will read the bus or drive the bus and go on to the next state. It will re-arm the timer with a delay based on the next state. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:42 -03:00

[media] cec: integrate CEC notifier support Support the CEC notifier framework, simplifying drivers that depend on this. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2016-12-13 12:15:57 -02:00

2016-06-25 09:43:58 -03:00

media: cec.h: increase input_phys buffer Fixes this compiler warning: drivers/media/cec/core/cec-core.c: In function 'cec_allocate_adapter': drivers/media/cec/core/cec-core.c:317:21: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=] 317 | "%s/input0", adap->name); | ^~~~~~~ drivers/media/cec/core/cec-core.c:316:9: note: 'snprintf' output between 8 and 39 bytes into a destination of size 32 316 | snprintf(adap->input_phys, sizeof(adap->input_phys), | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 317 | "%s/input0", adap->name); | ~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

2023-09-23 17:20:52 +02:00

2016-06-25 09:43:58 -03:00

media: cec: move cec_get/put_device to header Move cec_get/put_device to the media/cec.h header. This allows CEC drivers to use this. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

2024-08-02 12:19:48 +02:00

[media] cec: Add cec_get_drvdata() Add a helper function to get driver private data from CEC adapter. This helps the readability a little bit and allows to change the 'priv' field name to something else without needing to touch all drivers. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-03-24 13:47:52 -03:00

2016-06-25 09:43:58 -03:00

media: cec: disable the hardware when unregistered When the device is being unregistered disable the hardware, don't wait until cec_delete_adapter is called as the hardware may have disappeared by then. This would be the case for hotplugable devices. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reported-by: Bård Eirik Winther <bwinther@cisco.com> Tested-by: Bård Eirik Winther <bwinther@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-11-22 04:12:39 -05:00

[media] cec.h: merge cec-edid.h into cec.h Drop the separate cec-edid.h header and merge it into cec.h. There was really no need to have a separate header for this. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-04-17 07:54:37 -03:00

[media] cec: add cec_s_phys_addr_from_edid helper function This function simplifies the integration of CEC in DRM drivers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-06-07 11:46:08 -03:00

media: cec: add struct cec_connector_info support Define struct cec_connector_info in media/cec.h and define CEC_CAP_CONNECTOR_INFO. In a later patch this will be moved to uapi/linux/cec.h. The CEC_CAP_CONNECTOR_INFO capability can be set by drivers, but cec_allocate_adapter() will remove it again until the public API for this can be enabled once all drm drivers wire this up correctly. Also add the cec_fill_conn_info_from_drm and cec_s_conn_info functions, which are needed by drm drivers to fill in the cec_connector info based on a drm_connector. The cec_notifier_(un)register and cec_register_cec_notifier prototypes were moved from cec-notifier.h to cec.h since cec.h no longer includes cec-notifier.h. These headers included each other before, which caused various problems. Due to these changes the seco-cec driver was changed as well: it should include cec-notifier.h, not cec.h. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2019-06-20 05:17:18 -04:00

[media] cec: add cec_s_phys_addr_from_edid helper function This function simplifies the integration of CEC in DRM drivers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-06-07 11:46:08 -03:00

[media] media/cec.h: use IS_REACHABLE instead of IS_ENABLED Fix messages like this: adv7842.c:(.text+0x2edadd): undefined reference to `cec_unregister_adapter' when CEC_CORE=m but the driver including media/cec.h is built-in. In that case the static inlines provided in media/cec.h should be used by that driver. Reported-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-06-08 15:37:44 -03:00

2016-06-25 09:43:58 -03:00

[media] cec: pass parent device in register(), not allocate() The cec_allocate_adapter function doesn't need the parent device, only the cec_register_adapter function needs it. Drop the cec_devnode parent field, since devnode.dev.parent can be used instead. This change makes the framework consistent with other frameworks where the parent device is not used until the device is registered. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2016-11-25 06:23:34 -02:00

2016-06-25 09:43:58 -03:00

[media] cec: add cec_s_phys_addr_from_edid helper function This function simplifies the integration of CEC in DRM drivers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-06-07 11:46:08 -03:00

media: cec: add struct cec_connector_info support Define struct cec_connector_info in media/cec.h and define CEC_CAP_CONNECTOR_INFO. In a later patch this will be moved to uapi/linux/cec.h. The CEC_CAP_CONNECTOR_INFO capability can be set by drivers, but cec_allocate_adapter() will remove it again until the public API for this can be enabled once all drm drivers wire this up correctly. Also add the cec_fill_conn_info_from_drm and cec_s_conn_info functions, which are needed by drm drivers to fill in the cec_connector info based on a drm_connector. The cec_notifier_(un)register and cec_register_cec_notifier prototypes were moved from cec-notifier.h to cec.h since cec.h no longer includes cec-notifier.h. These headers included each other before, which caused various problems. Due to these changes the seco-cec driver was changed as well: it should include cec-notifier.h, not cec.h. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2019-06-20 05:17:18 -04:00

2016-06-25 09:43:58 -03:00

media: cec: add *_ts variants for transmit_done/received_msg Currently the transmit_(attempt_)done and received_msg functions set the timestamp themselves. For the upcoming low-level pin API we need to pass this as an argument instead. So make _ts variants that allow the caller to specify the timestamp. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:35 -03:00

[media] cec: add cec_transmit_attempt_done helper function A simpler variant of cec_transmit_done to be used where the HW does just a single attempt at a transmit. So if the status indicates an error, then the corresponding error count will always be 1 and this function figures that out based on the status argument. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-06-07 11:46:10 -03:00

media: cec: add *_ts variants for transmit_done/received_msg Currently the transmit_(attempt_)done and received_msg functions set the timestamp themselves. For the upcoming low-level pin API we need to pass this as an argument instead. So make _ts variants that allow the caller to specify the timestamp. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:35 -03:00

2016-06-25 09:43:58 -03:00

media: cec: add core support for low-level CEC pin monitoring Add support for the new MONITOR_PIN mode. Add the cec_pin_event function that the CEC pin code will call to queue pin change events. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:41 -03:00

media: cec: rename pin events/function The CEC_EVENT_PIN_LOW/HIGH defines and the cec_queue_pin_event() function did not specify that these were about CEC pin events. Since in the future there will also be HPD pin events it is wise to rename the event defines and function to CEC_EVENT_PIN_CEC_LOW/HIGH and cec_queue_pin_cec_event() now before these become part of the ABI. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-08-15 15:26:25 -04:00

media: cec: add core support for low-level CEC pin monitoring Add support for the new MONITOR_PIN mode. Add the cec_pin_event function that the CEC pin code will call to queue pin change events. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:41 -03:00

media: cec: rename pin events/function The CEC_EVENT_PIN_LOW/HIGH defines and the cec_queue_pin_event() function did not specify that these were about CEC pin events. Since in the future there will also be HPD pin events it is wise to rename the event defines and function to CEC_EVENT_PIN_CEC_LOW/HIGH and cec_queue_pin_cec_event() now before these become part of the ABI. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-08-15 15:26:25 -04:00

media: cec: improve CEC pin event handling It turns out that the struct cec_fh event buffer size of 64 events (64 for CEC_EVENT_PIN_CEC_LOW and 64 for _HIGH) is too small. It's about 160 ms worth of events and if the Raspberry Pi is busy, then it might take too long for the application to be scheduled so that it can drain the pending events. Increase these buffers to 800 events which is at least 2 seconds worth of events. There is also a FIFO in between the interrupt and the cec-pin thread. The thread passes the events on to the CEC core. It is important that should this FIFO fill up the cec core will be informed that events have been lost so this can be communicated to the user by setting CEC_EVENT_FL_DROPPED_EVENTS. It is very hard to debug CEC problems if events were lost without informing the user of that fact. If events were dropped due to the FIFO filling up, then the debugfs status file will let you know how many events were dropped. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2018-03-06 16:20:00 -05:00

media: cec: add core support for low-level CEC pin monitoring Add support for the new MONITOR_PIN mode. Add the cec_pin_event function that the CEC pin code will call to queue pin change events. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:41 -03:00

media: cec: improve CEC pin event handling It turns out that the struct cec_fh event buffer size of 64 events (64 for CEC_EVENT_PIN_CEC_LOW and 64 for _HIGH) is too small. It's about 160 ms worth of events and if the Raspberry Pi is busy, then it might take too long for the application to be scheduled so that it can drain the pending events. Increase these buffers to 800 events which is at least 2 seconds worth of events. There is also a FIFO in between the interrupt and the cec-pin thread. The thread passes the events on to the CEC core. It is important that should this FIFO fill up the cec core will be informed that events have been lost so this can be communicated to the user by setting CEC_EVENT_FL_DROPPED_EVENTS. It is very hard to debug CEC problems if events were lost without informing the user of that fact. If events were dropped due to the FIFO filling up, then the debugfs status file will let you know how many events were dropped. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2018-03-06 16:20:00 -05:00

media: cec: add core support for low-level CEC pin monitoring Add support for the new MONITOR_PIN mode. Add the cec_pin_event function that the CEC pin code will call to queue pin change events. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-07-11 03:30:41 -03:00

media: cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events Add support for two new low-level events: PIN_HPD_LOW and PIN_HPD_HIGH. This is specifically meant for use with the upcoming cec-gpio driver and makes it possible to trace when the HPD pin changes. Some HDMI sinks do strange things with the HPD and this makes it easy to debug this. Note that this also moves the initialization of a devnode mutex and list to the allocate_adapter function: if the HPD is high, then as soon as the HPD interrupt is created an interrupt occurs and cec_queue_pin_hpd_event() is called which requires that the devnode mutex and list are initialized. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-08-15 10:07:25 -04:00

media: cec: add support for 5V signal testing Add support for the new 5V CEC events Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2018-06-28 07:43:46 -04:00

[media] cec.h: merge cec-edid.h into cec.h Drop the separate cec-edid.h header and merge it into cec.h. There was really no need to have a separate header for this. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-04-17 07:54:37 -03:00

media: cec: add struct cec_connector_info support Define struct cec_connector_info in media/cec.h and define CEC_CAP_CONNECTOR_INFO. In a later patch this will be moved to uapi/linux/cec.h. The CEC_CAP_CONNECTOR_INFO capability can be set by drivers, but cec_allocate_adapter() will remove it again until the public API for this can be enabled once all drm drivers wire this up correctly. Also add the cec_fill_conn_info_from_drm and cec_s_conn_info functions, which are needed by drm drivers to fill in the cec_connector info based on a drm_connector. The cec_notifier_(un)register and cec_register_cec_notifier prototypes were moved from cec-notifier.h to cec.h since cec.h no longer includes cec-notifier.h. These headers included each other before, which caused various problems. Due to these changes the seco-cec driver was changed as well: it should include cec-notifier.h, not cec.h. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2019-06-20 05:17:18 -04:00

2016-06-25 09:43:58 -03:00

[media] cec: pass parent device in register(), not allocate() The cec_allocate_adapter function doesn't need the parent device, only the cec_register_adapter function needs it. Drop the cec_devnode parent field, since devnode.dev.parent can be used instead. This change makes the framework consistent with other frameworks where the parent device is not used until the device is registered. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2016-11-25 06:23:34 -02:00

2016-06-25 09:43:58 -03:00

[media] cec: add cec_s_phys_addr_from_edid helper function This function simplifies the integration of CEC in DRM drivers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-06-07 11:46:08 -03:00

[media] cec.h: merge cec-edid.h into cec.h Drop the separate cec-edid.h header and merge it into cec.h. There was really no need to have a separate header for this. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-04-17 07:54:37 -03:00

media: cec: add struct cec_connector_info support Define struct cec_connector_info in media/cec.h and define CEC_CAP_CONNECTOR_INFO. In a later patch this will be moved to uapi/linux/cec.h. The CEC_CAP_CONNECTOR_INFO capability can be set by drivers, but cec_allocate_adapter() will remove it again until the public API for this can be enabled once all drm drivers wire this up correctly. Also add the cec_fill_conn_info_from_drm and cec_s_conn_info functions, which are needed by drm drivers to fill in the cec_connector info based on a drm_connector. The cec_notifier_(un)register and cec_register_cec_notifier prototypes were moved from cec-notifier.h to cec.h since cec.h no longer includes cec-notifier.h. These headers included each other before, which caused various problems. Due to these changes the seco-cec driver was changed as well: it should include cec-notifier.h, not cec.h. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2019-06-20 05:17:18 -04:00

[media] cec: add cec_phys_addr_invalidate() helper function Simplifies setting the physical address to CEC_PHYS_ADDR_INVALID. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

2017-06-07 11:46:09 -03:00

media: cec: make cec_get_edid_spa_location() an inline function This function is needed by both V4L2 and CEC, so move this to cec.h as a static inline since there are no obvious shared modules between the two subsystems. This patch, together with the following ones, fixes a dependency bug: if CEC_CORE is disabled, then building adv7604 (and other HDMI receivers) will fail because an essential function is now stubbed out. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: <stable@vger.kernel.org> # for v4.17 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

2018-09-13 03:25:59 -04:00

2016-06-25 09:43:58 -03:00

599 lines 18 KiB Raw Permalink Normal View History

599 lines

18 KiB

Raw Permalink Normal View History