linux.git/include/media/cec.h, branch v5.3

media: cec: add struct cec_connector_info support

2019-06-27T11:18:43+00:00

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 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

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: 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: 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

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

2018-09-24T13:11:04+00:00

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

media: cec: make cec_get_edid_spa_location() an inline function

2018-09-24T13:09:07+00:00

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

media: cec: add support for 5V signal testing

2018-07-25T11:11:48+00:00

Add support for the new 5V CEC events

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

media: cec: improve CEC pin event handling

2018-03-22T12:16:52+00:00

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 
Signed-off-by: Mauro Carvalho Chehab

media: cec: add core error injection support

2018-03-22T11:59:31+00:00

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 
Signed-off-by: Mauro Carvalho Chehab

media: include/(uapi/)media: add SPDX license info

2018-02-14T18:23:51+00:00

Replace the old license information with the corresponding SPDX
license for those headers that I authored.

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