Commit 5d352e69 authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'media/v4.15-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

Pull media updates from Mauro Carvalho Chehab:

 - Documentation for digital TV (both kAPI and uAPI) are now in sync
   with the implementation (except for legacy/deprecated ioctls). This
   is a major step, as there were always a gap there

 - New sensor driver: imx274

 - New cec driver: cec-gpio

 - New platform driver for rockship rga and tegra CEC

 - New RC driver: tango-ir

 - Several cleanups at atomisp driver

 - Core improvements for RC, CEC, V4L2 async probing support and DVB

 - Lots of drivers cleanup, fixes and improvements.

* tag 'media/v4.15-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (332 commits)
  dvb_frontend: don't use-after-free the frontend struct
  media: dib0700: fix invalid dvb_detach argument
  media: v4l2-ctrls: Don't validate BITMASK twice
  media: s5p-mfc: fix lockdep warning
  media: dvb-core: always call invoke_release() in fe_free()
  media: usb: dvb-usb-v2: dvb_usb_core: remove redundant code in dvb_usb_fe_sleep
  media: au0828: make const array addr_list static
  media: cx88: make const arrays default_addr_list and pvr2000_addr_list static
  media: drxd: make const array fastIncrDecLUT static
  media: usb: fix spelling mistake: "synchronuously" -> "synchronously"
  media: ddbridge: fix build warnings
  media: av7110: avoid 2038 overflow in debug print
  media: Don't do DMA on stack for firmware upload in the AS102 driver
  media: v4l: async: fix unregister for implicitly registered sub-device notifiers
  media: v4l: async: fix return of unitialized variable ret
  media: imx274: fix missing return assignment from call to imx274_mode_regs
  media: camss-vfe: always initialize reg at vfe_set_xbar_cfg()
  media: atomisp: make function calls cleaner
  media: atomisp: get rid of storage_class.h
  media: atomisp: get rid of wrong stddef.h include
  ...
parents 93ea0eb7 f2ecc3d0
* HDMI CEC GPIO driver
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.
Required properties:
- compatible: value must be "cec-gpio".
- cec-gpios: gpio that the CEC line is connected to. The line should be
tagged as open drain.
If the CEC line is associated with an HDMI receiver/transmitter, then the
following property is also required:
- hdmi-phandle - phandle to the HDMI controller, see also cec.txt.
If the CEC line is not associated with an HDMI receiver/transmitter, then
the following property is optional:
- hpd-gpios: gpio that the HPD line is connected to.
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:
#include <dt-bindings/gpio/gpio.h>
cec-gpio {
compatible = "cec-gpio";
cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
hpd-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
};
......@@ -3,8 +3,11 @@
G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
Required properties:
- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
- compatible: should be one of
"samsung,exynos5250-gsc"
"samsung,exynos5420-gsc"
"samsung,exynos5433-gsc"
"samsung,exynos5-gsc" (deprecated)
- reg: should contain G-Scaler physical address location and length.
- interrupts: should contain G-Scaler interrupt number
......@@ -15,7 +18,7 @@ Optional properties:
Example:
gsc_0: gsc@0x13e00000 {
compatible = "samsung,exynos5-gsc";
compatible = "samsung,exynos5250-gsc";
reg = <0x13e00000 0x1000>;
interrupts = <0 85 0>;
};
......
* Sony 1/2.5-Inch 8.51Mp CMOS Digital Image Sensor
The Sony imx274 is a 1/2.5-inch CMOS active pixel digital image sensor with
an active array size of 3864H x 2202V. It is programmable through I2C
interface. The I2C address is fixed to 0x1a as per sensor data sheet.
Image data is sent through MIPI CSI-2, which is configured as 4 lanes
at 1440 Mbps.
Required Properties:
- compatible: value should be "sony,imx274" for imx274 sensor
- reg: I2C bus address of the device
Optional Properties:
- reset-gpios: Sensor reset GPIO
The imx274 device node should contain one 'port' child node with
an 'endpoint' subnode. For further reading on port node refer to
Documentation/devicetree/bindings/media/video-interfaces.txt.
Example:
sensor@1a {
compatible = "sony,imx274";
reg = <0x1a>;
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&gpio_sensor 0 0>;
port {
sensor_out: endpoint {
remote-endpoint = <&csiss_in>;
};
};
};
......@@ -27,6 +27,8 @@ Optional properties
- nokia,nvm-size: The size of the NVM, in bytes. If the size is not given,
the NVM contents will not be read.
- reset-gpios: XSHUTDOWN GPIO
- flash-leds: See ../video-interfaces.txt
- lens-focus: See ../video-interfaces.txt
Endpoint node mandatory properties
......
device-tree bindings for rockchip 2D raster graphic acceleration controller (RGA)
RGA is a standalone 2D raster graphic acceleration unit. It accelerates 2D
graphics operations, such as point/line drawing, image scaling, rotation,
BitBLT, alpha blending and image blur/sharpness.
Required properties:
- compatible: value should be one of the following
"rockchip,rk3288-rga";
"rockchip,rk3399-rga";
- interrupts: RGA interrupt specifier.
- clocks: phandle to RGA sclk/hclk/aclk clocks
- clock-names: should be "aclk", "hclk" and "sclk"
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: should be "core", "axi" and "ahb"
Example:
SoC-specific DT entry:
rga: rga@ff680000 {
compatible = "rockchip,rk3399-rga";
reg = <0xff680000 0x10000>;
interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru SCLK_RGA_CORE>;
clock-names = "aclk", "hclk", "sclk";
resets = <&cru SRST_RGA_CORE>, <&cru SRST_A_RGA>, <&cru SRST_H_RGA>;
reset-names = "core, "axi", "ahb";
};
Sigma Designs Tango IR NEC/RC-5/RC-6 decoder (SMP86xx and SMP87xx)
Required properties:
- compatible: "sigma,smp8642-ir"
- reg: address/size of NEC+RC5 area, address/size of RC6 area
- interrupts: spec for IR IRQ
- clocks: spec for IR clock (typically the crystal oscillator)
Optional properties:
- linux,rc-map-name: see Documentation/devicetree/bindings/media/rc.txt
Example:
ir@10518 {
compatible = "sigma,smp8642-ir";
reg = <0x10518 0x18>, <0x105e0 0x1c>;
interrupts = <21 IRQ_TYPE_EDGE_RISING>;
clocks = <&xtal>;
};
* Tegra HDMI CEC hardware
The HDMI CEC module is present in Tegra SoCs and its purpose is to
handle communication between HDMI connected devices over the CEC bus.
Required properties:
- compatible : value should be one of the following:
"nvidia,tegra114-cec"
"nvidia,tegra124-cec"
"nvidia,tegra210-cec"
- reg : Physical base address of the IP registers and length of memory
mapped region.
- interrupts : HDMI CEC interrupt number to the CPU.
- clocks : from common clock binding: handle to HDMI CEC clock.
- clock-names : from common clock binding: must contain "cec",
corresponding to the entry in the clocks property.
- hdmi-phandle : phandle to the HDMI controller, see also cec.txt.
Example:
cec@70015000 {
compatible = "nvidia,tegra124-cec";
reg = <0x0 0x70015000 0x0 0x00001000>;
interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA124_CLK_CEC>;
clock-names = "cec";
};
......@@ -55,6 +55,15 @@ divided into two separate ITU-R BT.656 8-bit busses. In such case bus-width
and data-shift properties can be used to assign physical data lines to each
endpoint node (logical bus).
Documenting bindings for devices
--------------------------------
All required and optional bindings the device supports shall be explicitly
documented in device DT binding documentation. This also includes port and
endpoint nodes for the device, including unit-addresses and reg properties where
relevant.
Please also see Documentation/devicetree/bindings/graph.txt .
Required properties
-------------------
......@@ -67,6 +76,16 @@ are required in a relevant parent node:
identifier, should be 1.
- #size-cells : should be zero.
Optional properties
-------------------
- flash-leds: An array of phandles, each referring to a flash LED, a sub-node
of the LED driver device node.
- lens-focus: A phandle to the node of the focus lens controller.
Optional endpoint properties
----------------------------
......@@ -99,7 +118,10 @@ Optional endpoint properties
determines the logical lane number, while the value of an entry indicates
physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have
"data-lanes = <1 2>;", assuming the clock lane is on hardware lane 0.
This property is valid for serial busses only (e.g. MIPI CSI-2).
If the hardware does not support lane reordering, monotonically
incremented values shall be used from 0 or 1 onwards, depending on
whether or not there is also a clock lane. This property is valid for
serial busses only (e.g. MIPI CSI-2).
- clock-lanes: an array of physical clock lane indexes. Position of an entry
determines the logical lane number, while the value of an entry indicates
physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;",
......
......@@ -24,8 +24,6 @@ ignore define CEC_VENDOR_ID_NONE
ignore define CEC_MODE_INITIATOR_MSK
ignore define CEC_MODE_FOLLOWER_MSK
ignore define CEC_EVENT_FL_INITIAL_STATE
# Part of CEC 2.0 spec - shouldn't be documented too?
ignore define CEC_LOG_ADDR_TV
ignore define CEC_LOG_ADDR_RECORD_1
......
......@@ -227,8 +227,8 @@ CEC_TX_STATUS_LOW_DRIVE:
retransmission.
CEC_TX_STATUS_ERROR:
some unspecified error occurred: this can be one of
the previous two if the hardware cannot differentiate or something
some unspecified error occurred: this can be one of ARB_LOST
or LOW_DRIVE if the hardware cannot differentiate or something
else entirely.
CEC_TX_STATUS_MAX_RETRIES:
......@@ -238,6 +238,9 @@ CEC_TX_STATUS_MAX_RETRIES:
doesn't have to make another attempt to transmit the message
since the hardware did that already.
The hardware must be able to differentiate between OK, NACK and 'something
else'.
The \*_cnt arguments are the number of error conditions that were seen.
This may be 0 if no information is available. Drivers that do not support
hardware retry can just set the counter corresponding to the transmit error
......
Digital TV Conditional Access kABI
----------------------------------
.. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h
Digital TV Common functions
---------------------------
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
DVB devices
~~~~~~~~~~~
Those functions are responsible for handling the DVB device nodes.
.. kernel-doc:: drivers/media/dvb-core/dvbdev.h
Digital TV Ring buffer
~~~~~~~~~~~~~~~~~~~~~~
Those routines implement ring buffers used to handle digital TV data and
copy it from/to userspace.
.. note::
1) For performance reasons read and write routines don't check buffer sizes
and/or number of bytes free/available. This has to be done before these
routines are called. For example:
.. code-block:: c
/* write @buflen: bytes */
free = dvb_ringbuffer_free(rbuf);
if (free >= buflen)
count = dvb_ringbuffer_write(rbuf, buffer, buflen);
else
/* do something */
/* read min. 1000, max. @bufsize: bytes */
avail = dvb_ringbuffer_avail(rbuf);
if (avail >= 1000)
count = dvb_ringbuffer_read(rbuf, buffer, min(avail, bufsize));
else
/* do something */
2) If there is exactly one reader and one writer, there is no need
to lock read or write operations.
Two or more readers must be locked against each other.
Flushing the buffer counts as a read operation.
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
This diff is collapsed.
Digital TV Demux kABI
---------------------
Digital TV Demux
~~~~~~~~~~~~~~~~
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``.
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.
When the demux client allocates a resource via the demux kABI, it receives
a pointer to the kABI of that resource.
Each demux receives its TS input from a DVB front-end or from memory, as
set via this demux kABI. In a system with more than one front-end, the kABI
can be used to select one of the DVB front-ends as a TS source for a demux,
unless this is fixed in the HW platform.
The demux kABI only controls front-ends regarding to their connections with
demuxes; the kABI used to set the other front-end parameters, such as
tuning, are devined via the Digital TV Frontend kABI.
The functions that implement the abstract interface demux should be defined
static or module private and registered to the Demux core for external
access. It is not necessary to implement every function in the struct
:c:type:`dmx_demux`. For example, a demux interface might support Section filtering,
but not PES filtering. The kABI client is expected to check the value of any
function pointer before calling the function: the value of ``NULL`` means
that the function is not available.
Whenever the functions of the demux API modify shared data, the
possibilities of lost update and race condition problems should be
addressed, e.g. by protecting parts of code with mutexes.
Note that functions called from a bottom half context must not sleep.
Even a simple memory allocation without using ``GFP_ATOMIC`` can result in a
kernel thread being put to sleep if swapping is needed. For example, the
Linux Kernel calls the functions of a network device interface from a
bottom half context. Thus, if a demux kABI function is called from network
device code, the function must not sleep.
Demux Callback API
~~~~~~~~~~~~~~~~~~
This kernel-space API comprises the callback functions that deliver filtered
data to the demux client. Unlike the other DVB kABIs, these functions are
provided by the client and called from the demux code.
The function pointers of this abstract interface are not packed into a
structure as in the other demux APIs, because the callback functions are
registered and used independent of each other. As an example, it is possible
for the API client to provide several callback functions for receiving TS
packets and no callbacks for PES packets or sections.
The functions that implement the callback API need not be re-entrant: when
a demux driver calls one of these functions, the driver is not allowed to
call the function again before the original call returns. If a callback is
triggered by a hardware interrupt, it is recommended to use the Linux
bottom half mechanism or start a tasklet instead of making the callback
function call directly from a hardware interrupt.
This mechanism is implemented by :c:func:`dmx_ts_cb()` and :c:func:`dmx_section_cb()`
callbacks.
Digital TV Demux device registration functions and data structures
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/media/dvb-core/dmxdev.h
High-level Digital TV demux interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/media/dvb-core/dvb_demux.h
Driver-internal low-level hardware specific driver demux interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/media/dvb-core/demux.h
This diff is collapsed.
Digital TV Network kABI
-----------------------
.. kernel-doc:: drivers/media/dvb-core/dvb_net.h
V4L2 async kAPI
^^^^^^^^^^^^^^^
.. kernel-doc:: include/media/v4l2-async.h
......@@ -19,6 +19,7 @@ Video4Linux devices
v4l2-mc
v4l2-mediabus
v4l2-mem2mem
v4l2-async
v4l2-fwnode
v4l2-rect
v4l2-tuner
......
......@@ -161,6 +161,24 @@ it is guaranteed that the state did change in between the two events.
- Generated if the CEC pin goes from a low voltage to a high voltage.
Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
capability set.
* .. _`CEC-EVENT-PIN-HPD-LOW`:
- ``CEC_EVENT_PIN_HPD_LOW``
- 5
- Generated if the HPD pin goes from a high voltage to a low voltage.
Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
capability set. When open() is called, the HPD pin can be read and
if the HPD is low, then an initial event will be generated for that
filehandle.
* .. _`CEC-EVENT-PIN-HPD-HIGH`:
- ``CEC_EVENT_PIN_HPD_HIGH``
- 6
- Generated if the HPD pin goes from a low voltage to a high voltage.
Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
capability set. When open() is called, the HPD pin can be read and
if the HPD is high, then an initial event will be generated for that
filehandle.
.. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}|
......@@ -172,9 +190,9 @@ it is guaranteed that the state did change in between the two events.
:stub-columns: 0
:widths: 3 1 8
* .. _`CEC-EVENT-FL-INITIAL-VALUE`:
* .. _`CEC-EVENT-FL-INITIAL-STATE`:
- ``CEC_EVENT_FL_INITIAL_VALUE``
- ``CEC_EVENT_FL_INITIAL_STATE``
- 1
- Set for the initial events that are generated when the device is
opened. See the table above for which events do this. This allows
......
......@@ -131,7 +131,7 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
- ``tx_status``
- The status bits of the transmitted message. See
:ref:`cec-tx-status` for the possible status values. It is 0 if
this messages was received, not transmitted.
this message was received, not transmitted.
* - __u8
- ``msg[16]``
- The message payload. For :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` this is filled in by the
......@@ -168,7 +168,7 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
- ``tx_status``
- The status bits of the transmitted message. See
:ref:`cec-tx-status` for the possible status values. It is 0 if
this messages was received, not transmitted.
this message was received, not transmitted.
* - __u8
- ``tx_arb_lost_cnt``
- A counter of the number of transmit attempts that resulted in the
......@@ -256,9 +256,9 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
- ``CEC_TX_STATUS_ERROR``
- 0x10
- Some error occurred. This is used for any errors that do not fit
the previous two, either because the hardware could not tell which
error occurred, or because the hardware tested for other
conditions besides those two.
``CEC_TX_STATUS_ARB_LOST`` or ``CEC_TX_STATUS_LOW_DRIVE``, either because
the hardware could not tell which error occurred, or because the hardware
tested for other conditions besides those two.
* .. _`CEC-TX-STATUS-MAX-RETRIES`:
- ``CEC_TX_STATUS_MAX_RETRIES``
......
This diff is collapsed.
......@@ -48,8 +48,11 @@ depends on the delivery system and on the device:
- This call requires read/write access to the device.
- At return, the values are updated to reflect the actual parameters
used.
.. note::
At return, the values aren't updated to reflect the actual
parameters used. If the actual parameters are needed, an explicit
call to ``FE_GET_PROPERTY`` is needed.