From 15ae0be9c671e912a6749d821bc69ccfff766c19 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Thu, 23 Nov 2017 09:05:06 -0500 Subject: media: cec-core.rst: document the new adap_monitor_pin_enable op Document what this op does. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/cec-core.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation/media/kapi') diff --git a/Documentation/media/kapi/cec-core.rst b/Documentation/media/kapi/cec-core.rst index d37e107f2fde..62b9a1448177 100644 --- a/Documentation/media/kapi/cec-core.rst +++ b/Documentation/media/kapi/cec-core.rst @@ -103,6 +103,7 @@ your driver: /* Low-level callbacks */ int (*adap_enable)(struct cec_adapter *adap, bool enable); int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable); + int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable); int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); int (*adap_transmit)(struct cec_adapter *adap, u8 attempts, u32 signal_free_time, struct cec_msg *msg); @@ -144,6 +145,19 @@ called if the CEC_CAP_MONITOR_ALL capability is set. This callback is optional Note that adap_monitor_all_enable must return 0 if enable is false. +To enable/disable the 'monitor pin' mode: + +.. c:function:: + int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable); + +If enabled, then the adapter should be put in a mode to also monitor CEC pin +changes. Not all hardware supports this and this function is only called if +the CEC_CAP_MONITOR_PIN capability is set. This callback is optional +(some hardware may always be in 'monitor pin' mode). + +Note that adap_monitor_pin_enable must return 0 if enable is false. + + To program a new logical address: .. c:function:: -- cgit From a6ddd4fecbb02d8ec5a865621bd2b746d585a01c Mon Sep 17 00:00:00 2001 From: Sean Young Date: Tue, 26 Sep 2017 09:34:47 -0400 Subject: media: lirc: remove last remnants of lirc kapi rc-core has replaced the lirc kapi many years ago, and now with the last driver ported to rc-core, we can finally remove it. Note this has no effect on userspace. All future IR drivers should use the rc-core api. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/rc-core.rst | 5 ----- 1 file changed, 5 deletions(-) (limited to 'Documentation/media/kapi') diff --git a/Documentation/media/kapi/rc-core.rst b/Documentation/media/kapi/rc-core.rst index a45895886257..41c2256dbf6a 100644 --- a/Documentation/media/kapi/rc-core.rst +++ b/Documentation/media/kapi/rc-core.rst @@ -7,8 +7,3 @@ Remote Controller core .. kernel-doc:: include/media/rc-core.h .. kernel-doc:: include/media/rc-map.h - -LIRC -~~~~ - -.. kernel-doc:: include/media/lirc_dev.h -- cgit From cccd6fa435d7e4d1c4f34ac78974519e31aead9a Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 23 Sep 2017 06:49:50 -0400 Subject: media: rc-core.rst: add an introduction for RC core The RC core does several assumptions, but those aren't documented anywhere, with could make harder for ones that want to understand what's there. So, add an introduction explaining the basic concepts of RC and how they're related to the RC core implementation. Acked-by: Sakari Ailus Acked-by: Sean Young Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/rc-core.rst | 77 ++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) (limited to 'Documentation/media/kapi') diff --git a/Documentation/media/kapi/rc-core.rst b/Documentation/media/kapi/rc-core.rst index 41c2256dbf6a..4759f020d6b2 100644 --- a/Documentation/media/kapi/rc-core.rst +++ b/Documentation/media/kapi/rc-core.rst @@ -4,6 +4,83 @@ Remote Controller devices Remote Controller core ~~~~~~~~~~~~~~~~~~~~~~ +The remote controller core implements infrastructure to receive and send +remote controller keyboard keystrokes and mouse events. + +Every time a key is pressed on a remote controller, a scan code is produced. +Also, on most hardware, keeping a key pressed for more than a few dozens of +milliseconds produce a repeat key event. That's somewhat similar to what +a normal keyboard or mouse is handled internally on Linux\ [#f1]_. So, the +remote controller core is implemented on the top of the linux input/evdev +interface. + +.. [#f1] + + The main difference is that, on keyboard events, the keyboard controller + produces one event for a key press and another one for key release. On + infrared-based remote controllers, there's no key release event. Instead, + an extra code is produced to indicate key repeats. + +However, most of the remote controllers use infrared (IR) to transmit signals. +As there are several protocols used to modulate infrared signals, one +important part of the core is dedicated to adjust the driver and the core +system to support the infrared protocol used by the emitter. + +The infrared transmission is done by blinking a infrared emitter using a +carrier. The carrier can be switched on or off by the IR transmitter +hardware. When the carrier is switched on, it is called *PULSE*. +When the carrier is switched off, it is called *SPACE*. + +In other words, a typical IR transmission can be viewed as a sequence of +*PULSE* and *SPACE* events, each with a given duration. + +The carrier parameters (frequency, duty cycle) and the intervals for +*PULSE* and *SPACE* events depend on the protocol. +For example, the NEC protocol uses a carrier of 38kHz, and transmissions +start with a 9ms *PULSE* and a 4.5ms SPACE. It then transmits 16 bits of +scan code, being 8 bits for address (usually it is a fixed number for a +given remote controller), followed by 8 bits of code. A bit "1" is modulated +with 560µs *PULSE* followed by 1690µs *SPACE* and a bit "0" is modulated +with 560µs *PULSE* followed by 560µs *SPACE*. + +At receiver, a simple low-pass filter can be used to convert the received +signal in a sequence of *PULSE/SPACE* events, filtering out the carrier +frequency. Due to that, the receiver doesn't care about the carrier's +actual frequency parameters: all it has to do is to measure the amount +of time it receives *PULSE/SPACE* events. +So, a simple IR receiver hardware will just provide a sequence of timings +for those events to the Kernel. The drivers for hardware with such kind of +receivers are identified by ``RC_DRIVER_IR_RAW``, as defined by +:c:type:`rc_driver_type`\ [#f2]_. Other hardware come with a +microcontroller that decode the *PULSE/SPACE* sequence and return scan +codes to the Kernel. Such kind of receivers are identified +by ``RC_DRIVER_SCANCODE``. + +.. [#f2] + + The RC core also supports devices that have just IR emitters, + without any receivers. Right now, all such devices work only in + raw TX mode. Such kind of hardware is identified as + ``RC_DRIVER_IR_RAW_TX``. + +When the RC core receives events produced by ``RC_DRIVER_IR_RAW`` IR +receivers, it needs to decode the IR protocol, in order to obtain the +corresponding scan code. The protocols supported by the RC core are +defined at enum :c:type:`rc_proto`. + +When the RC code receives a scan code (either directly, by a driver +of the type ``RC_DRIVER_SCANCODE``, or via its IR decoders), it needs +to convert into a Linux input event code. This is done via a mapping +table. + +The Kernel has support for mapping tables available on most media +devices. It also supports loading a table in runtime, via some +sysfs nodes. See the :ref:`RC userspace API ` +for more details. + +Remote controller data structures and functions +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + .. kernel-doc:: include/media/rc-core.h .. kernel-doc:: include/media/rc-map.h -- cgit From 66f1e6078e120d3503ce43de9715538f1122c304 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 22 Sep 2017 13:35:45 -0400 Subject: media: v4l2-event.rst: improve events description Both v4l2-event.rst and v4l2-event.h have an overview of events, but there are some inconsistencies there: - at v4l2-event, the event's ring buffer is called kevent. Its name is, instead, v4l2_kevent; - Some things are mentioned on both places (with different words), others are either on one of the files. In order to cleanup this mess, put everything at v4l2-event.rst and improve it to be a little more coherent and to have cross references. Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-event.rst | 67 ++++++++++++++++++++++++++------- 1 file changed, 54 insertions(+), 13 deletions(-) (limited to 'Documentation/media/kapi') diff --git a/Documentation/media/kapi/v4l2-event.rst b/Documentation/media/kapi/v4l2-event.rst index 9938d21ef4d1..5c7e31224ddc 100644 --- a/Documentation/media/kapi/v4l2-event.rst +++ b/Documentation/media/kapi/v4l2-event.rst @@ -5,27 +5,68 @@ V4L2 events The V4L2 events provide a generic way to pass events to user space. The driver must use :c:type:`v4l2_fh` to be able to support V4L2 events. -Events are defined by a type and an optional ID. The ID may refer to a V4L2 -object such as a control ID. If unused, then the ID is 0. +Events are subscribed per-filehandle. An event specification consists of a +``type`` and is optionally associated with an object identified through the +``id`` field. If unused, then the ``id`` is 0. So an event is uniquely +identified by the ``(type, id)`` tuple. -When the user subscribes to an event the driver will allocate a number of -kevent structs for that event. So every (type, ID) event tuple will have -its own set of kevent structs. This guarantees that if a driver is generating -lots of events of one type in a short time, then that will not overwrite -events of another type. +The :c:type:`v4l2_fh` struct has a list of subscribed events on its +``subscribed`` field. -But if you get more events of one type than the number of kevents that were -reserved, then the oldest event will be dropped and the new one added. +When the user subscribes to an event, a :c:type:`v4l2_subscribed_event` +struct is added to :c:type:`v4l2_fh`\ ``.subscribed``, one for every +subscribed event. + +Each :c:type:`v4l2_subscribed_event` struct ends with a +:c:type:`v4l2_kevent` ringbuffer, with the size given by the caller +of :c:func:`v4l2_event_subscribe`. This ringbuffer is used to store any events +raised by the driver. + +So every ``(type, ID)`` event tuple will have its own +:c:type:`v4l2_kevent` ringbuffer. This guarantees that if a driver is +generating lots of events of one type in a short time, then that will +not overwrite events of another type. + +But if you get more events of one type than the size of the +:c:type:`v4l2_kevent` ringbuffer, then the oldest event will be dropped +and the new one added. + +The :c:type:`v4l2_kevent` struct links into the ``available`` +list of the :c:type:`v4l2_fh` struct so :ref:`VIDIOC_DQEVENT` will +know which event to dequeue first. + +Finally, if the event subscription is associated with a particular object +such as a V4L2 control, then that object needs to know about that as well +so that an event can be raised by that object. So the ``node`` field can +be used to link the :c:type:`v4l2_subscribed_event` struct into a list of +such objects. + +So to summarize: + +- struct :c:type:`v4l2_fh` has two lists: one of the ``subscribed`` events, + and one of the ``available`` events. + +- struct :c:type:`v4l2_subscribed_event` has a ringbuffer of raised + (pending) events of that particular type. + +- If struct :c:type:`v4l2_subscribed_event` is associated with a specific + object, then that object will have an internal list of + struct :c:type:`v4l2_subscribed_event` so it knows who subscribed an + event to that object. Furthermore, the internal struct :c:type:`v4l2_subscribed_event` has ``merge()`` and ``replace()`` callbacks which drivers can set. These callbacks are called when a new event is raised and there is no more room. + The ``replace()`` callback allows you to replace the payload of the old event with that of the new event, merging any relevant data from the old payload into the new payload that replaces it. It is called when this event type has -only one kevent struct allocated. The ``merge()`` callback allows you to merge -the oldest event payload into that of the second-oldest event payload. It is -called when there are two or more kevent structs allocated. +a ringbuffer with size is one, i.e. only one event can be stored in the +ringbuffer. + +The ``merge()`` callback allows you to merge the oldest event payload into +that of the second-oldest event payload. It is called when +the ringbuffer has size is greater than one. This way no status information is lost, just the intermediate steps leading up to that state. @@ -73,7 +114,7 @@ The ops argument allows the driver to specify a number of callbacks: Callback Description ======== ============================================================== add called when a new listener gets added (subscribing to the same - event twice will only cause this callback to get called once) + event twice will only cause this callback to get called once) del called when a listener stops listening replace replace event 'old' with event 'new'. merge merge event 'old' into event 'new'. -- cgit From 4839c58f034ae41e2dfdd097240a69622cab4c73 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 28 Sep 2017 18:39:32 -0400 Subject: media: v4l2-dev: convert VFL_TYPE_* into an enum Using enums makes easier to document, as it can use kernel-doc markups. It also allows cross-referencing, with increases the kAPI readability. Please notice that now cx88_querycap() has to have a default for the VFL type, as there are more types than supported by the driver. Acked-By: Mike Isely Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/v4l2-dev.rst | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) (limited to 'Documentation/media/kapi') diff --git a/Documentation/media/kapi/v4l2-dev.rst b/Documentation/media/kapi/v4l2-dev.rst index b29aa616c267..7bb0505b60f1 100644 --- a/Documentation/media/kapi/v4l2-dev.rst +++ b/Documentation/media/kapi/v4l2-dev.rst @@ -196,11 +196,18 @@ device. Which device is registered depends on the type argument. The following types exist: -- ``VFL_TYPE_GRABBER``: ``/dev/videoX`` for video input/output devices -- ``VFL_TYPE_VBI``: ``/dev/vbiX`` for vertical blank data (i.e. closed captions, teletext) -- ``VFL_TYPE_RADIO``: ``/dev/radioX`` for radio tuners -- ``VFL_TYPE_SDR``: ``/dev/swradioX`` for Software Defined Radio tuners -- ``VFL_TYPE_TOUCH``: ``/dev/v4l-touchX`` for touch sensors +========================== ==================== ============================== +:c:type:`vfl_devnode_type` Device name Usage +========================== ==================== ============================== +``VFL_TYPE_GRABBER`` ``/dev/videoX`` for video input/output devices +``VFL_TYPE_VBI`` ``/dev/vbiX`` for vertical blank data (i.e. + closed captions, teletext) +``VFL_TYPE_RADIO`` ``/dev/radioX`` for radio tuners +``VFL_TYPE_SUBDEV`` ``/dev/v4l-subdevX`` for V4L2 subdevices +``VFL_TYPE_SDR`` ``/dev/swradioX`` for Software Defined Radio + (SDR) tuners +``VFL_TYPE_TOUCH`` ``/dev/v4l-touchX`` for touch sensors +========================== ==================== ============================== The last argument gives you a certain amount of control over the device device node number used (i.e. the X in ``videoX``). Normally you will pass -1 -- cgit From fada1935590f66dc6784981e0d557ca09013c847 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 28 Dec 2017 13:03:51 -0500 Subject: media: move dvb kAPI headers to include/media Except for DVB, all media kAPI headers are at include/media. Move the headers to it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/dtv-ca.rst | 2 +- Documentation/media/kapi/dtv-common.rst | 6 +++--- Documentation/media/kapi/dtv-demux.rst | 8 ++++---- Documentation/media/kapi/dtv-frontend.rst | 8 ++++---- Documentation/media/kapi/dtv-net.rst | 2 +- 5 files changed, 13 insertions(+), 13 deletions(-) (limited to 'Documentation/media/kapi') diff --git a/Documentation/media/kapi/dtv-ca.rst b/Documentation/media/kapi/dtv-ca.rst index a4dd700189b0..fded096b937c 100644 --- a/Documentation/media/kapi/dtv-ca.rst +++ b/Documentation/media/kapi/dtv-ca.rst @@ -1,4 +1,4 @@ Digital TV Conditional Access kABI ---------------------------------- -.. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h +.. kernel-doc:: include/media/dvb_ca_en50221.h diff --git a/Documentation/media/kapi/dtv-common.rst b/Documentation/media/kapi/dtv-common.rst index 40cf1033b5e1..c47843b6c81d 100644 --- a/Documentation/media/kapi/dtv-common.rst +++ b/Documentation/media/kapi/dtv-common.rst @@ -7,7 +7,7 @@ Math functions Provide some commonly-used math functions, usually required in order to estimate signal strength and signal to noise measurements in dB. -.. kernel-doc:: drivers/media/dvb-core/dvb_math.h +.. kernel-doc:: include/media/dvb_math.h DVB devices @@ -15,7 +15,7 @@ DVB devices Those functions are responsible for handling the DVB device nodes. -.. kernel-doc:: drivers/media/dvb-core/dvbdev.h +.. kernel-doc:: include/media/dvbdev.h Digital TV Ring buffer ~~~~~~~~~~~~~~~~~~~~~~ @@ -52,4 +52,4 @@ copy it from/to userspace. Resetting the buffer counts as a read and write operation. Two or more writers must be locked against each other. -.. kernel-doc:: drivers/media/dvb-core/dvb_ringbuffer.h +.. kernel-doc:: include/media/dvb_ringbuffer.h diff --git a/Documentation/media/kapi/dtv-demux.rst b/Documentation/media/kapi/dtv-demux.rst index 7aa865a2b43f..24857133e4e8 100644 --- a/Documentation/media/kapi/dtv-demux.rst +++ b/Documentation/media/kapi/dtv-demux.rst @@ -8,7 +8,7 @@ The Kernel Digital TV Demux kABI defines a driver-internal interface for registering low-level, hardware specific driver to a hardware independent demux layer. It is only of interest for Digital TV device driver writers. The header file for this kABI is named ``demux.h`` and located in -``drivers/media/dvb-core``. +``include/media``. The demux kABI should be implemented for each demux in the system. It is used to select the TS source of a demux and to manage the demux resources. @@ -69,14 +69,14 @@ callbacks. Digital TV Demux device registration functions and data structures ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/media/dvb-core/dmxdev.h +.. kernel-doc:: include/media/dmxdev.h High-level Digital TV demux interface ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/media/dvb-core/dvb_demux.h +.. kernel-doc:: include/media/dvb_demux.h Driver-internal low-level hardware specific driver demux interface ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/media/dvb-core/demux.h +.. kernel-doc:: include/media/demux.h diff --git a/Documentation/media/kapi/dtv-frontend.rst b/Documentation/media/kapi/dtv-frontend.rst index f1a2fdaab5ba..472650cdb100 100644 --- a/Documentation/media/kapi/dtv-frontend.rst +++ b/Documentation/media/kapi/dtv-frontend.rst @@ -8,7 +8,7 @@ The Digital TV Frontend kABI defines a driver-internal interface for registering low-level, hardware specific driver to a hardware independent frontend layer. It is only of interest for Digital TV device driver writers. The header file for this API is named ``dvb_frontend.h`` and located in -``drivers/media/dvb-core``. +``include/media/``. Demodulator driver ^^^^^^^^^^^^^^^^^^ @@ -17,7 +17,7 @@ The demodulator driver is responsible to talk with the decoding part of the hardware. Such driver should implement :c:type:`dvb_frontend_ops`, with tells what type of digital TV standards are supported, and points to a series of functions that allow the DVB core to command the hardware via -the code under ``drivers/media/dvb-core/dvb_frontend.c``. +the code under ``include/media/dvb_frontend.c``. A typical example of such struct in a driver ``foo`` is:: @@ -118,7 +118,7 @@ Satellite TV reception is:: .. |delta| unicode:: U+00394 -The ``drivers/media/dvb-core/dvb_frontend.c`` has a kernel thread with is +The ``include/media/dvb_frontend.c`` has a kernel thread with is responsible for tuning the device. It supports multiple algorithms to detect a channel, as defined at enum :c:func:`dvbfe_algo`. @@ -440,4 +440,4 @@ monotonic stats at the right time. Digital TV Frontend functions and types ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. kernel-doc:: drivers/media/dvb-core/dvb_frontend.h +.. kernel-doc:: include/media/dvb_frontend.h diff --git a/Documentation/media/kapi/dtv-net.rst b/Documentation/media/kapi/dtv-net.rst index ced991b73d69..158c7cbd7600 100644 --- a/Documentation/media/kapi/dtv-net.rst +++ b/Documentation/media/kapi/dtv-net.rst @@ -1,4 +1,4 @@ Digital TV Network kABI ----------------------- -.. kernel-doc:: drivers/media/dvb-core/dvb_net.h +.. kernel-doc:: include/media/dvb_net.h -- cgit From 9f577d6db5bf7d76fb9e26894a92fcb4ecb4c832 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 29 Dec 2017 08:23:41 -0500 Subject: media: dvb kAPI docs: document dvb_vb2.h Document the data structures and functions inside this kAPI header. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/kapi/dtv-common.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation/media/kapi') diff --git a/Documentation/media/kapi/dtv-common.rst b/Documentation/media/kapi/dtv-common.rst index c47843b6c81d..7a9574f03190 100644 --- a/Documentation/media/kapi/dtv-common.rst +++ b/Documentation/media/kapi/dtv-common.rst @@ -53,3 +53,8 @@ copy it from/to userspace. Two or more writers must be locked against each other. .. kernel-doc:: include/media/dvb_ringbuffer.h + +Digital TV VB2 handler +~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/media/dvb_vb2.h -- cgit