linux-toradex.git/drivers/media/cec, branch v5.0

media: cec: keep track of outstanding transmits

2018-11-23T10:56:14+00:00

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

media: cec: add debug_phys_addr module option

2018-11-23T10:55:25+00:00

If debug_phys_addr is set, then CEC_CAP_PHYS_ADDR is added to the CEC
adapter capabilities.

This allows for testing CEC even if the physical address isn't set. This
makes it possible to connect two HDMI outputs together and still use CEC.
Very useful for testing CEC if you don't have access to an HDMI receiver
under linux.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cec: report Vendor ID after initialization

2018-11-23T10:54:22+00:00

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

media: cec-pin: fix broken tx_ignore_nack_until_eom error injection

2018-11-23T10:48:44+00:00

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

media: cec: increase debug level for 'queue full'

2018-11-06T10:23:05+00:00

The "transmit queue full" message doesn't warrant debug level 1 since
it is already clear from the error code what's going on.

Bump to level 2.

Signed-off-by: Hans Verkuil 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cec: check for non-OK/NACK conditions while claiming a LA

2018-11-06T10:22:42+00:00

During the configuration phase of a CEC adapter it is trying to claim a
free logical address by polling.

However, the code doesn't check if there were errors other than OK or NACK,
those are just treated as if the poll was NACKed.

Instead check for such errors and retry the poll. And if the problem persists
then don't claim this LA since there is something weird going on.

Signed-off-by: Hans Verkuil 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cec: forgot to cancel delayed work

2018-10-15T13:57:52+00:00

If the wait for completion was interrupted, then make sure to cancel
any delayed work.

This can only happen if a transmit is waiting for a reply, and you press
Ctrl-C or reboot/poweroff or something like that which interrupts the
thread waiting for the reply and then proceeds to delete the CEC message.

Since the delayed work wasn't canceled, once it would trigger it referred
to stale data and resulted in a kernel oops.

Fixes: 7ec2b3b941a6 ("cec: add new tx/rx status bits to detect aborts/timeouts")

Signed-off-by: Hans Verkuil 
Cc:       # for v4.18 and up
Signed-off-by: Mauro Carvalho Chehab

media: cec: name for RC passthrough device does not need 'RC for'

2018-10-05T15:28:13+00:00

An RC device is does not need to be called 'RC for'. Simply the name
will suffice.

Signed-off-by: Sean Young 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cec-gpio: select correct Signal Free Time

2018-10-05T15:27:46+00:00

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

media: cec: fix the Signal Free Time calculation

2018-10-05T15:27:15+00:00

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 
Cc:       # for v4.18 and up
Signed-off-by: Mauro Carvalho Chehab