mirror of
https://github.com/a52xq-dev/kernel.git
synced 2026-10-18 21:58:11 +07:00
media updates for v4.16-rc1
-----BEGIN PGP SIGNATURE----- iQIcBAABAgAGBQJacX62AAoJEAhfPr2O5OEVjKYP/R3v+c8ztiHzaeibcZZ8IFNl 58E0Y0yGa8OpoGJx9uqtEOamQmZoHhACfId7joIp/Jv38bgWAdbxOmk3Y4FDCFqG 1bRrpnnmvlfabiMMfLpURLqKhf7rJMtErZkrnmmqg9P/lEMohaZUJAsgBZNfJM8l fZeacSnCSpzlxVcUb9Bf4vWhLk39R+xFzvFrwzbVUIHf3bDVpf4S4kNorMkhSZSF HaISYXqVMhpKca7CngVKytbfacUStUY01cXcjdMuB/sD7ySwdtKogbPMvrOSaexz G/8MB+sGT1JKUgIlh6Qv8hX805KuxBgfP19XSOH46nNU8KbYegdGhN5QXlokwI1m dAOiozkU93r5yBZl6QzkN3uwXe492PoLgczifg97pzAJP0BfWeFStkYqlugLTwwC Slmr7g3FZVJajbPl6WyioAGW7xfqBF7ftScZOHYxmhy41CWCGKJctmsJOjncyz5O GInEIP3KR4CgjR+iM1LoKvE+OvVo4kRc7hrcUsjQNsbfBn6xiixjwH+5M+UVvezA 6UQpmtWGg4pX1djb8j8f6mKF8KZM12Pp3jb4Rl1cLsytN5BOBKaMEKdV3rgL+19P Yo0x/1wK/unkI20Om71vYyQ0nXVF9j7Tpeij5u0M57TeTVYCwloQgHmrcvQJdo8+ Pqw5XEUiDpAIjvKp0XGh =H9AS -----END PGP SIGNATURE----- Merge tag 'media/v4.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media updates from Mauro Carvalho Chehab: - videobuf2 was moved to a media/common dir, as it is now used by the DVB subsystem too - Digital TV core memory mapped support interface - new sensor driver: ov7740 - several improvements at ddbridge driver - new V4L2 driver: IPU3 CIO2 CSI-2 receiver unit, found on some Intel SoCs - new tuner driver: tda18250 - finally got rid of all LIRC staging drivers - as we don't have old lirc drivers anymore, restruct the lirc device code - add support for UVC metadata - add a new staging driver for NVIDIA Tegra Video Decoder Engine - DVB kAPI headers moved to include/media - synchronize the kAPI and uAPI for the DVB subsystem, removing the gap for non-legacy APIs - reduce the kAPI gap for V4L2 - lots of other driver enhancements, cleanups, etc. * tag 'media/v4.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (407 commits) media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic media: v4l2-compat-ioctl32.c: don't copy back the result for certain errors media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type media: v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32 media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32 media: v4l2-compat-ioctl32.c: avoid sizeof(type) media: v4l2-compat-ioctl32.c: move 'helper' functions to __get/put_v4l2_format32 media: v4l2-compat-ioctl32.c: fix the indentation media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF media: v4l2-ioctl.c: don't copy back the result for -ENOTTY media: v4l2-ioctl.c: use check_fmt for enum/g/s/try_fmt media: vivid: fix module load error when enabling fb and no_error_inj=1 media: dvb_demux: improve debug messages media: dvb_demux: Better handle discontinuity errors media: cxusb, dib0700: ignore XC2028_I2C_FLUSH media: ts2020: avoid integer overflows on 32 bit machines media: i2c: ov7740: use gpio/consumer.h instead of gpio.h media: entity: Add a nop variant of media_entity_cleanup ...
This commit is contained in:
Linus Torvalds
commit
68c5735eaa
953 changed files with 21723 additions and 14035 deletions
|
|
@ -4,6 +4,10 @@ The HDMI CEC GPIO module supports CEC implementations where the CEC line
|
|||
is hooked up to a pull-up GPIO line and - optionally - the HPD line is
|
||||
hooked up to another GPIO line.
|
||||
|
||||
Please note: the maximum voltage for the CEC line is 3.63V, for the HPD
|
||||
line it is 5.3V. So you may need some sort of level conversion circuitry
|
||||
when connecting them to a GPIO line.
|
||||
|
||||
Required properties:
|
||||
- compatible: value must be "cec-gpio".
|
||||
- cec-gpios: gpio that the CEC line is connected to. The line should be
|
||||
|
|
@ -21,7 +25,7 @@ the following property is optional:
|
|||
|
||||
Example for the Raspberry Pi 3 where the CEC line is connected to
|
||||
pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
|
||||
connected to pin 11 aka BCM17:
|
||||
connected to pin 11 aka BCM17 (some level shifter is needed for this!):
|
||||
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
|
|
|
|||
|
|
@ -6,6 +6,8 @@ interface.
|
|||
|
||||
Required Properties:
|
||||
- compatible: value should be "micron,mt9m111"
|
||||
- clocks: reference to the master clock.
|
||||
- clock-names: shall be "mclk".
|
||||
|
||||
For further reading on port node refer to
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
|
@ -16,6 +18,8 @@ Example:
|
|||
mt9m111@5d {
|
||||
compatible = "micron,mt9m111";
|
||||
reg = <0x5d>;
|
||||
clocks = <&mclk>;
|
||||
clock-names = "mclk";
|
||||
|
||||
remote = <&pxa_camera>;
|
||||
port {
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
* Omnivision OV5640 MIPI CSI-2 sensor
|
||||
* Omnivision OV5640 MIPI CSI-2 / parallel sensor
|
||||
|
||||
Required Properties:
|
||||
- compatible: should be "ovti,ov5640"
|
||||
|
|
@ -18,7 +18,25 @@ The device node must contain one 'port' child node for its digital output
|
|||
video port, in accordance with the video interface bindings defined in
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
||||
Example:
|
||||
OV5640 can be connected to a MIPI CSI-2 bus or a parallel bus endpoint.
|
||||
|
||||
Endpoint node required properties for CSI-2 connection are:
|
||||
- remote-endpoint: a phandle to the bus receiver's endpoint node.
|
||||
- clock-lanes: should be set to <0> (clock lane on hardware lane 0)
|
||||
- data-lanes: should be set to <1> or <1 2> (one or two CSI-2 lanes supported)
|
||||
|
||||
Endpoint node required properties for parallel connection are:
|
||||
- remote-endpoint: a phandle to the bus receiver's endpoint node.
|
||||
- bus-width: shall be set to <8> for 8 bits parallel bus
|
||||
or <10> for 10 bits parallel bus
|
||||
- data-shift: shall be set to <2> for 8 bits parallel bus
|
||||
(lines 9:2 are used) or <0> for 10 bits parallel bus
|
||||
- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
|
||||
- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
|
||||
- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
|
||||
signal.
|
||||
|
||||
Examples:
|
||||
|
||||
&i2c1 {
|
||||
ov5640: camera@3c {
|
||||
|
|
@ -35,6 +53,7 @@ Example:
|
|||
reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
|
||||
|
||||
port {
|
||||
/* MIPI CSI-2 bus endpoint */
|
||||
ov5640_to_mipi_csi2: endpoint {
|
||||
remote-endpoint = <&mipi_csi2_from_ov5640>;
|
||||
clock-lanes = <0>;
|
||||
|
|
@ -43,3 +62,26 @@ Example:
|
|||
};
|
||||
};
|
||||
};
|
||||
|
||||
&i2c1 {
|
||||
ov5640: camera@3c {
|
||||
compatible = "ovti,ov5640";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_ov5640>;
|
||||
reg = <0x3c>;
|
||||
clocks = <&clk_ext_camera>;
|
||||
clock-names = "xclk";
|
||||
|
||||
port {
|
||||
/* Parallel bus endpoint */
|
||||
ov5640_to_parallel: endpoint {
|
||||
remote-endpoint = <¶llel_from_ov5640>;
|
||||
bus-width = <8>;
|
||||
data-shift = <2>; /* lines 9:2 are used */
|
||||
hsync-active = <0>;
|
||||
vsync-active = <0>;
|
||||
pclk-sample = <1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
47
Documentation/devicetree/bindings/media/i2c/ov7740.txt
Normal file
47
Documentation/devicetree/bindings/media/i2c/ov7740.txt
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
* Omnivision OV7740 CMOS image sensor
|
||||
|
||||
The Omnivision OV7740 image sensor supports multiple output image
|
||||
size, such as VGA, and QVGA, CIF and any size smaller. It also
|
||||
supports the RAW RGB and YUV output formats.
|
||||
|
||||
The common video interfaces bindings (see video-interfaces.txt) should
|
||||
be used to specify link to the image data receiver. The OV7740 device
|
||||
node should contain one 'port' child node with an 'endpoint' subnode.
|
||||
|
||||
Required Properties:
|
||||
- compatible: "ovti,ov7740".
|
||||
- reg: I2C slave address of the sensor.
|
||||
- clocks: Reference to the xvclk input clock.
|
||||
- clock-names: "xvclk".
|
||||
|
||||
Optional Properties:
|
||||
- reset-gpios: Rreference to the GPIO connected to the reset_b pin,
|
||||
if any. Active low with pull-ip resistor.
|
||||
- powerdown-gpios: Reference to the GPIO connected to the pwdn pin,
|
||||
if any. Active high with pull-down resistor.
|
||||
|
||||
Endpoint node mandatory properties:
|
||||
- remote-endpoint: A phandle to the bus receiver's endpoint node.
|
||||
|
||||
Example:
|
||||
|
||||
i2c1: i2c@fc028000 {
|
||||
ov7740: camera@21 {
|
||||
compatible = "ovti,ov7740";
|
||||
reg = <0x21>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_sensor_power &pinctrl_sensor_reset>;
|
||||
clocks = <&isc>;
|
||||
clock-names = "xvclk";
|
||||
assigned-clocks = <&isc>;
|
||||
assigned-clock-rates = <24000000>;
|
||||
reset-gpios = <&pioA 43 GPIO_ACTIVE_LOW>;
|
||||
powerdown-gpios = <&pioA 44 GPIO_ACTIVE_HIGH>;
|
||||
|
||||
port {
|
||||
ov7740_0: endpoint {
|
||||
remote-endpoint = <&isc_0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -20,6 +20,13 @@ Mandatory properties
|
|||
is in hardware standby mode when the signal is in the low state.
|
||||
|
||||
|
||||
Optional properties
|
||||
-------------------
|
||||
|
||||
- flash-leds: See ../video-interfaces.txt
|
||||
- lens-focus: See ../video-interfaces.txt
|
||||
|
||||
|
||||
Endpoint node mandatory properties
|
||||
----------------------------------
|
||||
|
||||
|
|
|
|||
55
Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
Normal file
55
Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
Normal file
|
|
@ -0,0 +1,55 @@
|
|||
NVIDIA Tegra Video Decoder Engine
|
||||
|
||||
Required properties:
|
||||
- compatible : Must contain one of the following values:
|
||||
- "nvidia,tegra20-vde"
|
||||
- "nvidia,tegra30-vde"
|
||||
- "nvidia,tegra114-vde"
|
||||
- "nvidia,tegra124-vde"
|
||||
- "nvidia,tegra132-vde"
|
||||
- reg : Must contain an entry for each entry in reg-names.
|
||||
- reg-names : Must include the following entries:
|
||||
- sxe
|
||||
- bsev
|
||||
- mbe
|
||||
- ppe
|
||||
- mce
|
||||
- tfe
|
||||
- ppb
|
||||
- vdma
|
||||
- frameid
|
||||
- iram : Must contain phandle to the mmio-sram device node that represents
|
||||
IRAM region used by VDE.
|
||||
- interrupts : Must contain an entry for each entry in interrupt-names.
|
||||
- interrupt-names : Must include the following entries:
|
||||
- sync-token
|
||||
- bsev
|
||||
- sxe
|
||||
- clocks : Must include the following entries:
|
||||
- vde
|
||||
- resets : Must include the following entries:
|
||||
- vde
|
||||
|
||||
Example:
|
||||
|
||||
video-codec@6001a000 {
|
||||
compatible = "nvidia,tegra20-vde";
|
||||
reg = <0x6001a000 0x1000 /* Syntax Engine */
|
||||
0x6001b000 0x1000 /* Video Bitstream Engine */
|
||||
0x6001c000 0x100 /* Macroblock Engine */
|
||||
0x6001c200 0x100 /* Post-processing Engine */
|
||||
0x6001c400 0x100 /* Motion Compensation Engine */
|
||||
0x6001c600 0x100 /* Transform Engine */
|
||||
0x6001c800 0x100 /* Pixel prediction block */
|
||||
0x6001ca00 0x100 /* Video DMA */
|
||||
0x6001d800 0x300 /* Video frame controls */>;
|
||||
reg-names = "sxe", "bsev", "mbe", "ppe", "mce",
|
||||
"tfe", "ppb", "vdma", "frameid";
|
||||
iram = <&vde_pool>; /* IRAM region */
|
||||
interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, /* Sync token interrupt */
|
||||
<GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, /* BSE-V interrupt */
|
||||
<GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>; /* SXE interrupt */
|
||||
interrupt-names = "sync-token", "bsev", "sxe";
|
||||
clocks = <&tegra_car TEGRA20_CLK_VDE>;
|
||||
resets = <&tegra_car 61>;
|
||||
};
|
||||
|
|
@ -66,6 +66,6 @@ Example:
|
|||
tpg1_out: endpoint {
|
||||
remote-endpoint = <&switch_in0>;
|
||||
};
|
||||
}:
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -54,3 +54,5 @@ ignore symbol DMX_OUT_DECODER
|
|||
ignore symbol DMX_OUT_TAP
|
||||
ignore symbol DMX_OUT_TS_TAP
|
||||
ignore symbol DMX_OUT_TSDEMUX_TAP
|
||||
|
||||
replace ioctl DMX_DQBUF dmx_qbuf
|
||||
|
|
|
|||
|
|
@ -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::
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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,9 @@ 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
|
||||
|
||||
Digital TV VB2 handler
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. kernel-doc:: include/media/dvb_vb2.h
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Digital TV Network kABI
|
||||
-----------------------
|
||||
|
||||
.. kernel-doc:: drivers/media/dvb-core/dvb_net.h
|
||||
.. kernel-doc:: include/media/dvb_net.h
|
||||
|
|
|
|||
|
|
@ -4,11 +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 <Remote_controllers_Intro>`
|
||||
for more details.
|
||||
|
||||
Remote controller data structures and functions
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. kernel-doc:: include/media/rc-core.h
|
||||
|
||||
.. kernel-doc:: include/media/rc-map.h
|
||||
|
||||
LIRC
|
||||
~~~~
|
||||
|
||||
.. kernel-doc:: include/media/lirc_dev.h
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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'.
|
||||
|
|
|
|||
|
|
@ -28,6 +28,36 @@ ignore define LIRC_CAN_SEND_MASK
|
|||
ignore define LIRC_CAN_REC_MASK
|
||||
ignore define LIRC_CAN_SET_REC_DUTY_CYCLE
|
||||
|
||||
# Obsolete ioctls
|
||||
|
||||
ignore ioctl LIRC_GET_LENGTH
|
||||
|
||||
# rc protocols
|
||||
|
||||
ignore symbol RC_PROTO_UNKNOWN
|
||||
ignore symbol RC_PROTO_OTHER
|
||||
ignore symbol RC_PROTO_RC5
|
||||
ignore symbol RC_PROTO_RC5X_20
|
||||
ignore symbol RC_PROTO_RC5_SZ
|
||||
ignore symbol RC_PROTO_JVC
|
||||
ignore symbol RC_PROTO_SONY12
|
||||
ignore symbol RC_PROTO_SONY15
|
||||
ignore symbol RC_PROTO_SONY20
|
||||
ignore symbol RC_PROTO_NEC
|
||||
ignore symbol RC_PROTO_NECX
|
||||
ignore symbol RC_PROTO_NEC32
|
||||
ignore symbol RC_PROTO_SANYO
|
||||
ignore symbol RC_PROTO_MCIR2_KBD
|
||||
ignore symbol RC_PROTO_MCIR2_MSE
|
||||
ignore symbol RC_PROTO_RC6_0
|
||||
ignore symbol RC_PROTO_RC6_6A_20
|
||||
ignore symbol RC_PROTO_RC6_6A_24
|
||||
ignore symbol RC_PROTO_RC6_6A_32
|
||||
ignore symbol RC_PROTO_RC6_MCE
|
||||
ignore symbol RC_PROTO_SHARP
|
||||
ignore symbol RC_PROTO_XMP
|
||||
ignore symbol RC_PROTO_CEC
|
||||
|
||||
# Undocumented macros
|
||||
|
||||
ignore define PULSE_BIT
|
||||
|
|
@ -40,3 +70,4 @@ ignore define LIRC_VALUE_MASK
|
|||
ignore define LIRC_MODE2_MASK
|
||||
|
||||
ignore define LIRC_MODE_RAW
|
||||
ignore define LIRC_MODE_LIRCCODE
|
||||
|
|
|
|||
88
Documentation/media/uapi/dvb/dmx-expbuf.rst
Normal file
88
Documentation/media/uapi/dvb/dmx-expbuf.rst
Normal file
|
|
@ -0,0 +1,88 @@
|
|||
.. _DMX_EXPBUF:
|
||||
|
||||
****************
|
||||
ioctl DMX_EXPBUF
|
||||
****************
|
||||
|
||||
Name
|
||||
====
|
||||
|
||||
DMX_EXPBUF - Export a buffer as a DMABUF file descriptor.
|
||||
|
||||
.. warning:: this API is still experimental
|
||||
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
.. c:function:: int ioctl( int fd, DMX_EXPBUF, struct dmx_exportbuffer *argp )
|
||||
:name: DMX_EXPBUF
|
||||
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
||||
``fd``
|
||||
File descriptor returned by :ref:`open() <dmx_fopen>`.
|
||||
|
||||
``argp``
|
||||
Pointer to struct :c:type:`dmx_exportbuffer`.
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
This ioctl is an extension to the memory mapping I/O method.
|
||||
It can be used to export a buffer as a DMABUF file at any time after
|
||||
buffers have been allocated with the :ref:`DMX_REQBUFS` ioctl.
|
||||
|
||||
To export a buffer, applications fill struct :c:type:`dmx_exportbuffer`.
|
||||
Applications must set the ``index`` field. Valid index numbers
|
||||
range from zero to the number of buffers allocated with :ref:`DMX_REQBUFS`
|
||||
(struct :c:type:`dmx_requestbuffers` ``count``) minus one.
|
||||
Additional flags may be posted in the ``flags`` field. Refer to a manual
|
||||
for open() for details. Currently only O_CLOEXEC, O_RDONLY, O_WRONLY,
|
||||
and O_RDWR are supported.
|
||||
All other fields must be set to zero. In the
|
||||
case of multi-planar API, every plane is exported separately using
|
||||
multiple :ref:`DMX_EXPBUF` calls.
|
||||
|
||||
After calling :ref:`DMX_EXPBUF` the ``fd`` field will be set by a
|
||||
driver, on success. This is a DMABUF file descriptor. The application may
|
||||
pass it to other DMABUF-aware devices. It is recommended to close a DMABUF
|
||||
file when it is no longer used to allow the associated memory to be reclaimed.
|
||||
|
||||
|
||||
Examples
|
||||
========
|
||||
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
int buffer_export(int v4lfd, enum dmx_buf_type bt, int index, int *dmafd)
|
||||
{
|
||||
struct dmx_exportbuffer expbuf;
|
||||
|
||||
memset(&expbuf, 0, sizeof(expbuf));
|
||||
expbuf.type = bt;
|
||||
expbuf.index = index;
|
||||
if (ioctl(v4lfd, DMX_EXPBUF, &expbuf) == -1) {
|
||||
perror("DMX_EXPBUF");
|
||||
return -1;
|
||||
}
|
||||
|
||||
*dmafd = expbuf.fd;
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
On success 0 is returned, on error -1 and the ``errno`` variable is set
|
||||
appropriately. The generic error codes are described at the
|
||||
:ref:`Generic Error Codes <gen-errors>` chapter.
|
||||
|
||||
EINVAL
|
||||
A queue is not in MMAP mode or DMABUF exporting is not supported or
|
||||
``flags`` or ``index`` fields are invalid.
|
||||
116
Documentation/media/uapi/dvb/dmx-mmap.rst
Normal file
116
Documentation/media/uapi/dvb/dmx-mmap.rst
Normal file
|
|
@ -0,0 +1,116 @@
|
|||
.. _dmx-mmap:
|
||||
|
||||
*****************
|
||||
Digital TV mmap()
|
||||
*****************
|
||||
|
||||
Name
|
||||
====
|
||||
|
||||
dmx-mmap - Map device memory into application address space
|
||||
|
||||
.. warning:: this API is still experimental
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
#include <unistd.h>
|
||||
#include <sys/mman.h>
|
||||
|
||||
|
||||
.. c:function:: void *mmap( void *start, size_t length, int prot, int flags, int fd, off_t offset )
|
||||
:name: dmx-mmap
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
||||
``start``
|
||||
Map the buffer to this address in the application's address space.
|
||||
When the ``MAP_FIXED`` flag is specified, ``start`` must be a
|
||||
multiple of the pagesize and mmap will fail when the specified
|
||||
address cannot be used. Use of this option is discouraged;
|
||||
applications should just specify a ``NULL`` pointer here.
|
||||
|
||||
``length``
|
||||
Length of the memory area to map. This must be a multiple of the
|
||||
DVB packet length (188, on most drivers).
|
||||
|
||||
``prot``
|
||||
The ``prot`` argument describes the desired memory protection.
|
||||
Regardless of the device type and the direction of data exchange it
|
||||
should be set to ``PROT_READ`` | ``PROT_WRITE``, permitting read
|
||||
and write access to image buffers. Drivers should support at least
|
||||
this combination of flags.
|
||||
|
||||
``flags``
|
||||
The ``flags`` parameter specifies the type of the mapped object,
|
||||
mapping options and whether modifications made to the mapped copy of
|
||||
the page are private to the process or are to be shared with other
|
||||
references.
|
||||
|
||||
``MAP_FIXED`` requests that the driver selects no other address than
|
||||
the one specified. If the specified address cannot be used,
|
||||
:ref:`mmap() <dmx-mmap>` will fail. If ``MAP_FIXED`` is specified,
|
||||
``start`` must be a multiple of the pagesize. Use of this option is
|
||||
discouraged.
|
||||
|
||||
One of the ``MAP_SHARED`` or ``MAP_PRIVATE`` flags must be set.
|
||||
``MAP_SHARED`` allows applications to share the mapped memory with
|
||||
other (e. g. child-) processes.
|
||||
|
||||
.. note::
|
||||
|
||||
The Linux Digital TV applications should not set the
|
||||
``MAP_PRIVATE``, ``MAP_DENYWRITE``, ``MAP_EXECUTABLE`` or ``MAP_ANON``
|
||||
flags.
|
||||
|
||||
``fd``
|
||||
File descriptor returned by :ref:`open() <dmx_fopen>`.
|
||||
|
||||
``offset``
|
||||
Offset of the buffer in device memory, as returned by
|
||||
:ref:`DMX_QUERYBUF` ioctl.
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The :ref:`mmap() <dmx-mmap>` function asks to map ``length`` bytes starting at
|
||||
``offset`` in the memory of the device specified by ``fd`` into the
|
||||
application address space, preferably at address ``start``. This latter
|
||||
address is a hint only, and is usually specified as 0.
|
||||
|
||||
Suitable length and offset parameters are queried with the
|
||||
:ref:`DMX_QUERYBUF` ioctl. Buffers must be allocated with the
|
||||
:ref:`DMX_REQBUFS` ioctl before they can be queried.
|
||||
|
||||
To unmap buffers the :ref:`munmap() <dmx-munmap>` function is used.
|
||||
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
On success :ref:`mmap() <dmx-mmap>` returns a pointer to the mapped buffer. On
|
||||
error ``MAP_FAILED`` (-1) is returned, and the ``errno`` variable is set
|
||||
appropriately. Possible error codes are:
|
||||
|
||||
EBADF
|
||||
``fd`` is not a valid file descriptor.
|
||||
|
||||
EACCES
|
||||
``fd`` is not open for reading and writing.
|
||||
|
||||
EINVAL
|
||||
The ``start`` or ``length`` or ``offset`` are not suitable. (E. g.
|
||||
they are too large, or not aligned on a ``PAGESIZE`` boundary.)
|
||||
|
||||
The ``flags`` or ``prot`` value is not supported.
|
||||
|
||||
No buffers have been allocated with the
|
||||
:ref:`DMX_REQBUFS` ioctl.
|
||||
|
||||
ENOMEM
|
||||
Not enough physical or virtual memory was available to complete the
|
||||
request.
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue