kernel/linux.git/drivers/media/cec, branch v4.19.112

media: cec: check 'transmit_in_progress', not 'transmitting'

2020-01-09T09:19:00+00:00

commit ac479b51f3f4aaa852b5d3f00ecfb9290230cf64 upstream. Currently wait_event_interruptible_timeout is called in cec_thread_func() when adap->transmitting is set. But if the adapter is unconfigured while transmitting, then adap->transmitting is set to NULL. But the hardware is still actually transmitting the message, and that's indicated by adap->transmit_in_progress and we should wait until that is finished or times out before transmitting new messages. As the original commit says: adap->transmitting is the userspace view, adap->transmit_in_progress reflects the hardware state. However, if adap->transmitting is NULL and adap->transmit_in_progress is true, then wait_event_interruptible is called (no timeout), which can get stuck indefinitely if the CEC driver is flaky and never marks the transmit-in-progress as 'done'. So test against transmit_in_progress when deciding whether to use the timeout variant or not, instead of testing against adap->transmitting. Signed-off-by: Hans Verkuil Fixes: 32804fcb612b ("media: cec: keep track of outstanding transmits") Cc: # for v4.19 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: cec: avoid decrementing transmit_queue_sz if it is 0

2020-01-09T09:19:00+00:00

commit 95c29d46ab2a517e4c26d0a07300edca6768db17 upstream. WARN if transmit_queue_sz is 0 but do not decrement it. The CEC adapter will become unresponsive if it goes below 0 since then it thinks there are 4 billion messages in the queue. Obviously this should not happen, but a driver bug could cause this. Signed-off-by: Hans Verkuil Cc: # for v4.12 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: cec: CEC 2.0-only bcast messages were ignored

2020-01-09T09:19:00+00:00

commit cec935ce69fc386f13959578deb40963ebbb85c3 upstream. Some messages are allowed to be a broadcast message in CEC 2.0 only, and should be ignored by CEC 1.4 devices. Unfortunately, the check was wrong, causing such messages to be marked as invalid under CEC 2.0. Signed-off-by: Hans Verkuil Cc: # for v4.10 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: cec: report Vendor ID after initialization

2019-12-13T07:51:38+00:00

[ Upstream commit 7f02ac77c768ba2bcdd0ce719c1fca0870ffe2fb ] The CEC specification requires that the Vendor ID (if any) is reported after a logical address was claimed. This was never done, so add support for this. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: cec-gpio: select correct Signal Free Time

2019-11-24T07:20:25+00:00

[ Upstream commit c439d5c1e13dbf66cff53455432f21d4d0536c51 ] If a receive is in progress or starts before the transmit has a chance, then lower the Signal Free Time of the upcoming transmit to no more than CEC_SIGNAL_FREE_TIME_NEW_INITIATOR. This is per the specification requirements. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: cec-notifier: clear cec_adap in cec_notifier_unregister

2019-10-05T11:09:49+00:00

[ Upstream commit 14d5511691e5290103bc480998bc322e68f139d4 ] If cec_notifier_cec_adap_unregister() is called before cec_unregister_adapter() then everything is OK (and this is the case today). But if it is the other way around, then cec_notifier_unregister() is called first, and that doesn't set n->cec_adap to NULL. So if e.g. cec_notifier_set_phys_addr() is called after cec_notifier_unregister() but before cec_unregister_adapter() then n->cec_adap points to an unregistered and likely deleted cec adapter. So just set n->cec_adap->notifier and n->cec_adap to NULL for rubustness. Eventually cec_notifier_unregister will disappear and this will be simplified substantially. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: cec: remove cec-edid.c

2019-09-16T06:21:46+00:00

[ Upstream commit f94d463f1b7f83d465ed77521821583dbcdaa3c5 ] Move cec_get_edid_phys_addr() to cec-adap.c. It's not worth keeping a separate source for this. Signed-off-by: Hans Verkuil Cc: # for v4.17 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: cec/v4l2: move V4L2 specific CEC functions to V4L2

2019-09-16T06:21:46+00:00

[ Upstream commit 9cfd2753f8f3923f89cbb15f940f3aa0e7202d3e ] Several CEC functions are actually specific for use with receivers, i.e. they should be part of the V4L2 subsystem, not CEC. These functions deal with validating and modifying EDIDs for (HDMI) receivers, and they do not actually have anything to do with the CEC subsystem and whether or not CEC is enabled. The problem was that if the CEC_CORE config option was not set, then these functions would become stubs, but that's not right: they should always be valid. So replace the cec_ prefix by v4l2_ and move them to v4l2-dv-timings.c. Update all drivers that call these accordingly. Signed-off-by: Hans Verkuil Reported-by: Lars-Peter Clausen Cc: # for v4.17 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: cec-pin: fix broken tx_ignore_nack_until_eom error injection

2019-01-09T16:38:46+00:00

commit ac791f19a273a7fe254a7596f193af6534582a9f upstream. If the tx_ignore_nack_until_eom error injection was activated, then tx_nacked was never set instead of setting it when the last byte of the message was transmitted. As a result the transmit was marked as OK, when it should have been NACKed. Modify the condition so that it always sets tx_nacked when the last byte of the message was transmitted. Signed-off-by: Hans Verkuil Cc: # for v4.17 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: cec: keep track of outstanding transmits

2019-01-09T16:38:46+00:00

commit 32804fcb612bf867034a093f459415e485cf044b upstream. 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 Cc: # for v4.18 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman