nhu/kernel_a52xq
Watch
1
Fork
You've already forked kernel_a52xq
 0
mirror of https://github.com/a52xq-dev/kernel.git synced 2026-10-18 21:58:11 +07:00
Code Issues Projects Releases Wiki Activity

media updates for v4.18-rc1

Browse source 
-----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJbGDjcAAoJEAhfPr2O5OEV1KwP/Am2n5Ehc2W0/DLD3K7LlwgN
 8JnMPWNQTCreLRgJD0/KX+HH1M+yBJ05KF/Glm7fcOKpOhWqrUbPgtiQT0GyHHBB
 uvmQfGJrRvCrP+1S1SeWtNhItsyWvCfDaorzsTWJYEF/F9Wtj/Sj92DC1y/BKQaR
 Rcs4yeCqlFEp3rjbXExanFhA3/XeMzK2sby8c51cILTZPkWI64qrHcZRWOW7+zZ6
 fKEVDNOKxa7sfg8I9yaI73lBGXBpCJxLROloJ3jEtuH5gY3nR6PZdXunBC5K0+pX
 UH1vUeBcS/3ExQWL0zmCqHz1aYb6kzTSbIPs+NktxyzTTb8FDjT9JhV/9AxhEQfK
 iIxv81LRBdbEoPxbvx88sj5VVvlRla/NRv03WsXhhVDqx2SZJuNgSXw3XJtGDx3j
 AuUur0AQH4KMNNmwxmyn6wbhm7N63AaGbmYE2sRmaL7lk6b48BSbsUpOM5AMWzZe
 ZsESSsoqjRR86zFtVVzI7ZImCk16D6mNRP94Z0DQReWAJ6zS57/EYfKZ+pEQ6mww
 IyoJalD+pBe160fqsSo59F4k2fqzsqP4p8m29OQWFvyl7+UboMBz7FscWfyT98+R
 MbJolZ8QJNlOVaOusxPYLfdfjVmkHCt4E0cBZVFYIvliTGd5QiKqHAW+kTYQH0No
 Y0nHm4bShsUY8I9YCgsk
 =r/WP
 -----END PGP SIGNATURE-----

Merge tag 'media/v4.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

Pull media updates from Mauro Carvalho Chehab:

 - remove of atomisp driver from staging, as nobody would have time to
   dedicate huge efforts to fix all the problems there. Also, we have a
   feeling that the driver may not even run the way it is.

 - move Zoran driver to staging, in order to be either fixed to use VB2
   and the proper media kAPIs or to be removed

 - remove videobuf-dvb driver, with is unused for a while

 - some V4L2 documentation fixes/improvements

 - new sensor drivers: imx258 and ov7251

 - a new driver was added to allow using I2C transparent drivers

 - several improvements at the ddbridge driver

 - several improvements at the ISDB pt1 driver, making it more coherent
   with the DVB framework

 - added a new platform driver for MIPI CSI-2 RX: cadence

 - now, all media drivers can be compiled on x86 with COMPILE_TEST

 - almost all media drivers now build on non-x86 architectures with
   COMPILE_TEST

 - lots of other random stuff: cleanups, support for new board models,
   bug fixes, etc

* tag 'media/v4.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (464 commits)
  media: omap2: fix compile-testing with FB_OMAP2=m
  media: media/radio/Kconfig: add back RADIO_ISA
  media: v4l2-ioctl.c: fix missing unlock in __video_do_ioctl()
  media: pxa_camera: ignore -ENOIOCTLCMD from v4l2_subdev_call for s_power
  media: arch: sh: migor: Fix TW9910 PDN gpio
  media: staging: tegra-vde: Reset VDE regardless of memory client resetting failure
  media: marvel-ccic: mmp: select VIDEOBUF2_VMALLOC/DMA_CONTIG
  media: marvel-ccic: allow ccic and mmp drivers to coexist
  media: uvcvideo: Prevent setting unavailable flags
  media: ddbridge: conditionally enable fast TS for stv0910-equipped bridges
  media: dvb-frontends/stv0910: make TS speed configurable
  media: ddbridge/mci: add identifiers to function definition arguments
  media: ddbridge/mci: protect against out-of-bounds array access in stop()
  media: rc: ensure input/lirc device can be opened after register
  media: rc: nuvoton: Keep device enabled during reg init
  media: rc: nuvoton: Keep track of users on CIR enable/disable
  media: rc: nuvoton: Tweak the interrupt enabling dance
  media: uvcvideo: Support realtek's UVC 1.5 device
  media: uvcvideo: Fix driver reference counting
  media: gspca_zc3xx: Enable short exposure times for OV7648
  ...
This commit is contained in:
Linus Torvalds 2018-06-07 12:34:37 -07:00
commit 3036bc4536
1168 changed files with 16815 additions and 176700 deletions
Download patch file Download diff file Expand all files Collapse all files

16
Documentation/ABI/testing/sysfs-class-rc
View file

@ -1,7 +1,7 @@
What: /sys/class/rc/
Date: Apr 2010
KernelVersion: 2.6.35
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
The rc/ class sub-directory belongs to the Remote Controller
core and provides a sysfs interface for configuring infrared
@ -10,7 +10,7 @@ Description:
What: /sys/class/rc/rcN/
Date: Apr 2010
KernelVersion: 2.6.35
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
A /sys/class/rc/rcN directory is created for each remote
control receiver device where N is the number of the receiver.
@ -18,7 +18,7 @@ Description:
What: /sys/class/rc/rcN/protocols
Date: Jun 2010
KernelVersion: 2.6.36
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
Reading this file returns a list of available protocols,
something like:
@ -36,7 +36,7 @@ Description:
What: /sys/class/rc/rcN/filter
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
Sets the scancode filter expected value.
Use in combination with /sys/class/rc/rcN/filter_mask to set the
@ -49,7 +49,7 @@ Description:
What: /sys/class/rc/rcN/filter_mask
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
Sets the scancode filter mask of bits to compare.
Use in combination with /sys/class/rc/rcN/filter to set the bits
@ -64,7 +64,7 @@ Description:
What: /sys/class/rc/rcN/wakeup_protocols
Date: Feb 2017
KernelVersion: 4.11
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
Reading this file returns a list of available protocols to use
for the wakeup filter, something like:
@ -83,7 +83,7 @@ Description:
What: /sys/class/rc/rcN/wakeup_filter
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
Sets the scancode wakeup filter expected value.
Use in combination with /sys/class/rc/rcN/wakeup_filter_mask to
@ -98,7 +98,7 @@ Description:
What: /sys/class/rc/rcN/wakeup_filter_mask
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
Sets the scancode wakeup filter mask of bits to compare.
Use in combination with /sys/class/rc/rcN/wakeup_filter to set

2
Documentation/ABI/testing/sysfs-class-rc-nuvoton
View file

@ -1,7 +1,7 @@
What: /sys/class/rc/rcN/wakeup_data
Date: Mar 2016
KernelVersion: 4.6
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Description:
Reading this file returns the stored CIR wakeup sequence.
It starts with a pulse, followed by a space, pulse etc.

14
Documentation/ABI/testing/sysfs-devices-edac
View file

@ -77,7 +77,7 @@ Description: Read/Write attribute file that controls memory scrubbing.
What: /sys/devices/system/edac/mc/mc*/max_location
Date: April 2012
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
linux-edac@vger.kernel.org
Description: This attribute file displays the information about the last
available memory slot in this memory controller. It is used by
@ -85,7 +85,7 @@ Description: This attribute file displays the information about the last
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/size
Date: April 2012
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
linux-edac@vger.kernel.org
Description: This attribute file will display the size of dimm or rank.
For dimm*/size, this is the size, in MB of the DIMM memory
@ -96,14 +96,14 @@ Description: This attribute file will display the size of dimm or rank.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_dev_type
Date: April 2012
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of DRAM device is
being utilized on this DIMM (x1, x2, x4, x8, ...).
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_edac_mode
Date: April 2012
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of Error detection
and correction is being utilized. For example: S4ECD4ED would
@ -111,7 +111,7 @@ Description: This attribute file will display what type of Error detection
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_label
Date: April 2012
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
linux-edac@vger.kernel.org
Description: This control file allows this DIMM to have a label assigned
to it. With this label in the module, when errors occur
@ -126,14 +126,14 @@ Description: This control file allows this DIMM to have a label assigned
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_location
Date: April 2012
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
linux-edac@vger.kernel.org
Description: This attribute file will display the location (csrow/channel,
branch/channel/slot or channel/slot) of the dimm or rank.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_mem_type
Date: April 2012
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of memory is
currently on this csrow. Normally, either buffered or

100
Documentation/devicetree/bindings/media/cdns,csi2rx.txt Normal file
View file

@ -0,0 +1,100 @@
Cadence MIPI-CSI2 RX controller
===============================
The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
lanes in input, and 4 different pixel streams in output.
Required properties:
- compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
- reg: base address and size of the memory mapped region
- clocks: phandles to the clocks driving the controller
- clock-names: must contain:
* sys_clk: main clock
* p_clk: register bank clock
* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
implemented in hardware, between 0 and 3
Optional properties:
- phys: phandle to the external D-PHY, phy-names must be provided
- phy-names: must contain "dphy", if the implementation uses an
external D-PHY
Required subnodes:
- ports: A ports node with one port child node per device input and output
port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt. The
port nodes are numbered as follows:
Port Description
-----------------------------
0 CSI-2 input
1 Stream 0 output
2 Stream 1 output
3 Stream 2 output
4 Stream 3 output
The stream output port nodes are optional if they are not
connected to anything at the hardware level or implemented
in the design.Since there is only one endpoint per port,
the endpoints are not numbered.
Example:
csi2rx: csi-bridge@0d060000 {
compatible = "cdns,csi2rx";
reg = <0x0d060000 0x1000>;
clocks = <&byteclock>, <&byteclock>
<&coreclock>, <&coreclock>,
<&coreclock>, <&coreclock>;
clock-names = "sys_clk", "p_clk",
"pixel_if0_clk", "pixel_if1_clk",
"pixel_if2_clk", "pixel_if3_clk";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
csi2rx_in_sensor: endpoint {
remote-endpoint = <&sensor_out_csi2rx>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
port@1 {
reg = <1>;
csi2rx_out_grabber0: endpoint {
remote-endpoint = <&grabber0_in_csi2rx>;
};
};
port@2 {
reg = <2>;
csi2rx_out_grabber1: endpoint {
remote-endpoint = <&grabber1_in_csi2rx>;
};
};
port@3 {
reg = <3>;
csi2rx_out_grabber2: endpoint {
remote-endpoint = <&grabber2_in_csi2rx>;
};
};
port@4 {
reg = <4>;
csi2rx_out_grabber3: endpoint {
remote-endpoint = <&grabber3_in_csi2rx>;
};
};
};
};

98
Documentation/devicetree/bindings/media/cdns,csi2tx.txt Normal file
View file

@ -0,0 +1,98 @@
Cadence MIPI-CSI2 TX controller
===============================
The Cadence MIPI-CSI2 TX controller is a CSI-2 bridge supporting up to
4 CSI lanes in output, and up to 4 different pixel streams in input.
Required properties:
- compatible: must be set to "cdns,csi2tx"
- reg: base address and size of the memory mapped region
- clocks: phandles to the clocks driving the controller
- clock-names: must contain:
* esc_clk: escape mode clock
* p_clk: register bank clock
* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
implemented in hardware, between 0 and 3
Optional properties
- phys: phandle to the D-PHY. If it is set, phy-names need to be set
- phy-names: must contain "dphy"
Required subnodes:
- ports: A ports node with one port child node per device input and output
port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt. The
port nodes are numbered as follows.
Port Description
-----------------------------
0 CSI-2 output
1 Stream 0 input
2 Stream 1 input
3 Stream 2 input
4 Stream 3 input
The stream input port nodes are optional if they are not
connected to anything at the hardware level or implemented
in the design. Since there is only one endpoint per port,
the endpoints are not numbered.
Example:
csi2tx: csi-bridge@0d0e1000 {
compatible = "cdns,csi2tx";
reg = <0x0d0e1000 0x1000>;
clocks = <&byteclock>, <&byteclock>,
<&coreclock>, <&coreclock>,
<&coreclock>, <&coreclock>;
clock-names = "p_clk", "esc_clk",
"pixel_if0_clk", "pixel_if1_clk",
"pixel_if2_clk", "pixel_if3_clk";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
csi2tx_out: endpoint {
remote-endpoint = <&remote_in>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
port@1 {
reg = <1>;
csi2tx_in_stream0: endpoint {
remote-endpoint = <&stream0_out>;
};
};
port@2 {
reg = <2>;
csi2tx_in_stream1: endpoint {
remote-endpoint = <&stream1_out>;
};
};
port@3 {
reg = <3>;
csi2tx_in_stream2: endpoint {
remote-endpoint = <&stream2_out>;
};
};
port@4 {
reg = <4>;
csi2tx_in_stream3: endpoint {
remote-endpoint = <&stream3_out>;
};
};
};
};

52
Documentation/devicetree/bindings/media/i2c/ov7251.txt Normal file
View file

@ -0,0 +1,52 @@
* Omnivision 1/7.5-Inch B&W VGA CMOS Digital Image Sensor
The Omnivision OV7251 is a 1/7.5-Inch CMOS active pixel digital image sensor
with an active array size of 640H x 480V. It is programmable through a serial
I2C interface.
Required Properties:
- compatible: Value should be "ovti,ov7251".
- clocks: Reference to the xclk clock.
- clock-names: Should be "xclk".
- clock-frequency: Frequency of the xclk clock.
- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This corresponds
to the hardware pin XSHUTDOWN which is physically active low.
- vdddo-supply: Chip digital IO regulator.
- vdda-supply: Chip analog regulator.
- vddd-supply: Chip digital core regulator.
The device node shall contain one 'port' child node with a single 'endpoint'
subnode for its digital output video port, in accordance with the video
interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Example:
&i2c1 {
...
ov7251: camera-sensor@60 {
compatible = "ovti,ov7251";
reg = <0x60>;
enable-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&camera_bw_default>;
clocks = <&clks 200>;
clock-names = "xclk";
clock-frequency = <24000000>;
vdddo-supply = <&camera_dovdd_1v8>;
vdda-supply = <&camera_avdd_2v8>;
vddd-supply = <&camera_dvdd_1v2>;
port {
ov7251_ep: endpoint {
clock-lanes = <1>;
data-lanes = <0>;
remote-endpoint = <&csi0_ep>;
};
};
};
};

40
Documentation/devicetree/bindings/media/i2c/ov772x.txt Normal file
View file

@ -0,0 +1,40 @@
* Omnivision OV7720/OV7725 CMOS sensor
The Omnivision OV7720/OV7725 sensor supports multiple resolutions output,
such as VGA, QVGA, and any size scaling down from CIF to 40x30. It also can
support the YUV422, RGB565/555/444, GRB422 or raw RGB output formats.
Required Properties:
- compatible: shall be one of
"ovti,ov7720"
"ovti,ov7725"
- clocks: reference to the xclk input clock.
Optional Properties:
- reset-gpios: reference to the GPIO connected to the RSTB pin which is
active low, if any.
- powerdown-gpios: reference to the GPIO connected to the PWDN pin which is
active high, if any.
The device node shall contain one 'port' child node with one child 'endpoint'
subnode for its digital output video port, in accordance with the video
interface bindings defined in Documentation/devicetree/bindings/media/
video-interfaces.txt.
Example:
&i2c0 {
ov772x: camera@21 {
compatible = "ovti,ov7725";
reg = <0x21>;
reset-gpios = <&axi_gpio_0 0 GPIO_ACTIVE_LOW>;
powerdown-gpios = <&axi_gpio_0 1 GPIO_ACTIVE_LOW>;
clocks = <&xclk>;
port {
ov772x_0: endpoint {
remote-endpoint = <&vcap1_in0>;
};
};
};
};

19
Documentation/devicetree/bindings/media/i2c/panasonic,amg88xx.txt Normal file
View file

@ -0,0 +1,19 @@
* Panasonic AMG88xx
The Panasonic family of AMG88xx Grid-Eye sensors allow recording
8x8 10Hz video which consists of thermal datapoints
Required Properties:
- compatible : Must be "panasonic,amg88xx"
- reg : i2c address of the device
Example:
i2c0@1c22000 {
...
amg88xx@69 {
compatible = "panasonic,amg88xx";
reg = <0x69>;
};
...
};

138
Documentation/devicetree/bindings/media/rcar_vin.txt
View file

@ -2,20 +2,28 @@ Renesas R-Car Video Input driver (rcar_vin)
-------------------------------------------
The rcar_vin device provides video input capabilities for the Renesas R-Car
family of devices. The current blocks are always slaves and suppot one input
channel which can be either RGB, YUYV or BT656.
family of devices.
Each VIN instance has a single parallel input that supports RGB and YUV video,
with both external synchronization and BT.656 synchronization for the latter.
Depending on the instance the VIN input is connected to external SoC pins, or
on Gen3 platforms to a CSI-2 receiver.
- compatible: Must be one or more of the following
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7793" for the R8A7793 device
- "renesas,vin-r8a7792" for the R8A7792 device
- "renesas,vin-r8a7791" for the R8A7791 device
- "renesas,vin-r8a7790" for the R8A7790 device
- "renesas,vin-r8a7779" for the R8A7779 device
- "renesas,vin-r8a7743" for the R8A7743 device
- "renesas,vin-r8a7745" for the R8A7745 device
- "renesas,vin-r8a7778" for the R8A7778 device
- "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
- "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
- "renesas,vin-r8a7779" for the R8A7779 device
- "renesas,vin-r8a7790" for the R8A7790 device
- "renesas,vin-r8a7791" for the R8A7791 device
- "renesas,vin-r8a7792" for the R8A7792 device
- "renesas,vin-r8a7793" for the R8A7793 device
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7796" for the R8A7796 device
- "renesas,vin-r8a77970" for the R8A77970 device
- "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
device.
When compatible with the generic version nodes must list the
SoC-specific version corresponding to the platform first
@ -28,21 +36,38 @@ channel which can be either RGB, YUYV or BT656.
Additionally, an alias named vinX will need to be created to specify
which video input device this is.
The per-board settings:
The per-board settings Gen2 platforms:
- port sub-node describing a single endpoint connected to the vin
as described in video-interfaces.txt[1]. Only the first one will
be considered as each vin interface has one input port.
These settings are used to work out video input format and widths
into the system.
The per-board settings Gen3 platforms:
Gen3 platforms can support both a single connected parallel input source
from external SoC pins (port0) and/or multiple parallel input sources
from local SoC CSI-2 receivers (port1) depending on SoC.
Device node example
-------------------
- renesas,id - ID number of the VIN, VINx in the documentation.
- ports
- port 0 - sub-node describing a single endpoint connected to the VIN
from external SoC pins described in video-interfaces.txt[1].
Describing more then one endpoint in port 0 is invalid. Only VIN
instances that are connected to external pins should have port 0.
- port 1 - sub-nodes describing one or more endpoints connected to
the VIN from local SoC CSI-2 receivers. The endpoint numbers must
use the following schema.
aliases {
vin0 = &vin0;
};
- Endpoint 0 - sub-node describing the endpoint connected to CSI20
- Endpoint 1 - sub-node describing the endpoint connected to CSI21
- Endpoint 2 - sub-node describing the endpoint connected to CSI40
- Endpoint 3 - sub-node describing the endpoint connected to CSI41
Device node example for Gen2 platforms
--------------------------------------
aliases {
vin0 = &vin0;
};
vin0: vin@e6ef0000 {
compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin";
@ -52,8 +77,8 @@ Device node example
status = "disabled";
};
Board setup example (vin1 composite video input)
------------------------------------------------
Board setup example for Gen2 platforms (vin1 composite video input)
-------------------------------------------------------------------
&i2c2 {
status = "okay";
@ -92,6 +117,77 @@ Board setup example (vin1 composite video input)
};
};
Device node example for Gen3 platforms
--------------------------------------
vin0: video@e6ef0000 {
compatible = "renesas,vin-r8a7795";
reg = <0 0xe6ef0000 0 0x1000>;
interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 811>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 811>;
renesas,id = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
vin0csi20: endpoint@0 {
reg = <0>;
remote-endpoint= <&csi20vin0>;
};
vin0csi21: endpoint@1 {
reg = <1>;
remote-endpoint= <&csi21vin0>;
};
vin0csi40: endpoint@2 {
reg = <2>;
remote-endpoint= <&csi40vin0>;
};
};
};
};
csi20: csi2@fea80000 {
compatible = "renesas,r8a7795-csi2";
reg = <0 0xfea80000 0 0x10000>;
interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 714>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 714>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
csi20_in: endpoint {
clock-lanes = <0>;
data-lanes = <1>;
remote-endpoint = <&adv7482_txb>;
};
};
port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
csi20vin0: endpoint@0 {
reg = <0>;
remote-endpoint = <&vin0csi20>;
};
};
};
};
[1] video-interfaces.txt common video media interface

7
Documentation/devicetree/bindings/media/renesas,ceu.txt
View file

@ -2,14 +2,15 @@ Renesas Capture Engine Unit (CEU)
----------------------------------------------
The Capture Engine Unit is the image capture interface found in the Renesas
SH Mobile and RZ SoCs.
SH Mobile, R-Mobile and RZ SoCs.
The interface supports a single parallel input with data bus width of 8 or 16
bits.
Required properties:
- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1H
and RZ/A1M SoCs.
- compatible: Shall be one of the following values:
"renesas,r7s72100-ceu" for CEU units found in RZ/A1H and RZ/A1M SoCs
"renesas,r8a7740-ceu" for CEU units found in R-Mobile A1 R8A7740 SoCs
- reg: Registers address base and size.
- interrupts: The interrupt specifier.

101
Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt Normal file
View file

@ -0,0 +1,101 @@
Renesas R-Car MIPI CSI-2
------------------------
The R-Car CSI-2 receiver device provides MIPI CSI-2 capabilities for the
Renesas R-Car family of devices. It is used in conjunction with the
R-Car VIN module, which provides the video capture capabilities.
Mandatory properties
--------------------
- compatible: Must be one or more of the following
- "renesas,r8a7795-csi2" for the R8A7795 device.
- "renesas,r8a7796-csi2" for the R8A7796 device.
- "renesas,r8a77965-csi2" for the R8A77965 device.
- "renesas,r8a77970-csi2" for the R8A77970 device.
- reg: the register base and size for the device registers
- interrupts: the interrupt for the device
- clocks: reference to the parent clock
The device node shall contain two 'port' child nodes according to the
bindings defined in Documentation/devicetree/bindings/media/
video-interfaces.txt. port@0 shall connect to the CSI-2 source. port@1
shall connect to all the R-Car VIN modules that have a hardware
connection to the CSI-2 receiver.
- port@0- Video source (mandatory)
- endpoint@0 - sub-node describing the endpoint that is the video source
- port@1 - VIN instances (optional)
- One endpoint sub-node for every R-Car VIN instance which is connected
to the R-Car CSI-2 receiver.
Example:
csi20: csi2@fea80000 {
compatible = "renesas,r8a7796-csi2";
reg = <0 0xfea80000 0 0x10000>;
interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 714>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
resets = <&cpg 714>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
csi20_in: endpoint@0 {
reg = <0>;
clock-lanes = <0>;
data-lanes = <1>;
remote-endpoint = <&adv7482_txb>;
};
};
port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
csi20vin0: endpoint@0 {
reg = <0>;
remote-endpoint = <&vin0csi20>;
};
csi20vin1: endpoint@1 {
reg = <1>;
remote-endpoint = <&vin1csi20>;
};
csi20vin2: endpoint@2 {
reg = <2>;
remote-endpoint = <&vin2csi20>;
};
csi20vin3: endpoint@3 {
reg = <3>;
remote-endpoint = <&vin3csi20>;
};
csi20vin4: endpoint@4 {
reg = <4>;
remote-endpoint = <&vin4csi20>;
};
csi20vin5: endpoint@5 {
reg = <5>;
remote-endpoint = <&vin5csi20>;
};
csi20vin6: endpoint@6 {
reg = <6>;
remote-endpoint = <&vin6csi20>;
};
csi20vin7: endpoint@7 {
reg = <7>;
remote-endpoint = <&vin7csi20>;
};
};
};
};

5
Documentation/media/kapi/cec-core.rst
View file

@ -246,7 +246,10 @@ CEC_TX_STATUS_LOW_DRIVE:
CEC_TX_STATUS_ERROR:
some unspecified error occurred: this can be one of ARB_LOST
or LOW_DRIVE if the hardware cannot differentiate or something
else entirely.
else entirely. Some hardware only supports OK and FAIL as the
result of a transmit, i.e. there is no way to differentiate
between the different possible errors. In that case map FAIL
to CEC_TX_STATUS_NACK and not to CEC_TX_STATUS_ERROR.
CEC_TX_STATUS_MAX_RETRIES:
could not transmit the message after trying multiple times.

24
Documentation/media/uapi/cec/cec-ioc-receive.rst
View file

@ -231,26 +231,32 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
- ``CEC_TX_STATUS_OK``
- 0x01
- The message was transmitted successfully. This is mutually
exclusive with :ref:`CEC_TX_STATUS_MAX_RETRIES <CEC-TX-STATUS-MAX-RETRIES>`. Other bits can still
be set if earlier attempts met with failure before the transmit
was eventually successful.
exclusive with :ref:`CEC_TX_STATUS_MAX_RETRIES <CEC-TX-STATUS-MAX-RETRIES>`.
Other bits can still be set if earlier attempts met with failure before
the transmit was eventually successful.
* .. _`CEC-TX-STATUS-ARB-LOST`:
- ``CEC_TX_STATUS_ARB_LOST``
- 0x02
- CEC line arbitration was lost.
- CEC line arbitration was lost, i.e. another transmit started at the
same time with a higher priority. Optional status, not all hardware
can detect this error condition.
* .. _`CEC-TX-STATUS-NACK`:
- ``CEC_TX_STATUS_NACK``
- 0x04
- Message was not acknowledged.
- Message was not acknowledged. Note that some hardware cannot tell apart
a 'Not Acknowledged' status from other error conditions, i.e. the result
of a transmit is just OK or FAIL. In that case this status will be
returned when the transmit failed.
* .. _`CEC-TX-STATUS-LOW-DRIVE`:
- ``CEC_TX_STATUS_LOW_DRIVE``
- 0x08
- Low drive was detected on the CEC bus. This indicates that a
follower detected an error on the bus and requests a
retransmission.
retransmission. Optional status, not all hardware can detect this
error condition.
* .. _`CEC-TX-STATUS-ERROR`:
- ``CEC_TX_STATUS_ERROR``
@ -258,14 +264,14 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
- Some error occurred. This is used for any errors that do not fit
``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.
tested for other conditions besides those two. Optional status.
* .. _`CEC-TX-STATUS-MAX-RETRIES`:
- ``CEC_TX_STATUS_MAX_RETRIES``
- 0x20
- The transmit failed after one or more retries. This status bit is
mutually exclusive with :ref:`CEC_TX_STATUS_OK <CEC-TX-STATUS-OK>`. Other bits can still
be set to explain which failures were seen.
mutually exclusive with :ref:`CEC_TX_STATUS_OK <CEC-TX-STATUS-OK>`.
Other bits can still be set to explain which failures were seen.
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|

2
Documentation/media/uapi/dvb/dvbapi.rst
View file

@ -62,7 +62,7 @@ Authors:
- Original author of the Digital TV API documentation.
- Carvalho Chehab, Mauro <m.chehab@kernel.org>
- Carvalho Chehab, Mauro <mchehab+samsung@kernel.org>
- Ported document to Docbook XML, addition of DVBv5 API, documentation gaps fix.

2
Documentation/media/uapi/rc/lirc-dev-intro.rst
View file

@ -18,7 +18,7 @@ Example dmesg output upon a driver registering w/LIRC:
.. code-block:: none
$ dmesg |grep lirc_dev
rc rc0: lirc_dev: driver mceusb registered at minor = 0
rc rc0: lirc_dev: driver mceusb registered at minor = 0, raw IR receiver, raw IR transmitter
What you should see for a chardev:

14
Documentation/media/uapi/rc/lirc-set-rec-timeout.rst
View file

@ -1,19 +1,23 @@
.. -*- coding: utf-8; mode: rst -*-
.. _lirc_set_rec_timeout:
.. _lirc_get_rec_timeout:
**************************
ioctl LIRC_SET_REC_TIMEOUT
**************************
***************************************************
ioctl LIRC_GET_REC_TIMEOUT and LIRC_SET_REC_TIMEOUT
***************************************************
Name
====
LIRC_SET_REC_TIMEOUT - sets the integer value for IR inactivity timeout.
LIRC_GET_REC_TIMEOUT/LIRC_SET_REC_TIMEOUT - Get/set the integer value for IR inactivity timeout.
Synopsis
========
.. c:function:: int ioctl( int fd, LIRC_GET_REC_TIMEOUT, __u32 *timeout )
:name: LIRC_GET_REC_TIMEOUT
.. c:function:: int ioctl( int fd, LIRC_SET_REC_TIMEOUT, __u32 *timeout )
:name: LIRC_SET_REC_TIMEOUT
@ -30,7 +34,7 @@ Arguments
Description
===========
Sets the integer value for IR inactivity timeout.
Get and set the integer value for IR inactivity timeout.
If supported by the hardware, setting it to 0 disables all hardware timeouts
and data should be reported as soon as possible. If the exact value

2
Documentation/media/uapi/v4l/common.rst
View file

@ -41,6 +41,6 @@ applicable to all devices.
extended-controls
format
planar-apis
crop
selection-api
crop
streaming-par

22
Documentation/media/uapi/v4l/crop.rst
View file

@ -2,9 +2,18 @@
.. _crop:
*************************************
Image Cropping, Insertion and Scaling
*************************************
*****************************************************
Image Cropping, Insertion and Scaling -- the CROP API
*****************************************************
.. note::
The CROP API is mostly superseded by the newer :ref:`SELECTION API
<selection-api>`. The new API should be preferred in most cases,
with the exception of pixel aspect ratio detection, which is
implemented by :ref:`VIDIOC_CROPCAP <VIDIOC_CROPCAP>` and has no
equivalent in the SELECTION API. See :ref:`selection-vs-crop` for a
comparison of the two APIs.
Some video capture devices can sample a subsection of the picture and
shrink or enlarge it to an image of arbitrary size. We call these
@ -42,10 +51,9 @@ where applicable) will be fixed in this case.
.. note::
All capture and output devices must support the
:ref:`VIDIOC_CROPCAP <VIDIOC_CROPCAP>` ioctl such that applications
can determine if scaling takes place.
All capture and output devices that support the CROP or SELECTION
API will also support the :ref:`VIDIOC_CROPCAP <VIDIOC_CROPCAP>`
ioctl.
Cropping Structures
===================

34
Documentation/media/uapi/v4l/selection-api-005.rst
View file

@ -1,34 +0,0 @@
.. -*- coding: utf-8; mode: rst -*-
********************************
Comparison with old cropping API
********************************
The selection API was introduced to cope with deficiencies of previous
:ref:`API <crop>`, that was designed to control simple capture
devices. Later the cropping API was adopted by video output drivers. The
ioctls are used to select a part of the display were the video signal is
inserted. It should be considered as an API abuse because the described
operation is actually the composing. The selection API makes a clear
distinction between composing and cropping operations by setting the
appropriate targets. The V4L2 API lacks any support for composing to and
cropping from an image inside a memory buffer. The application could
configure a capture device to fill only a part of an image by abusing
V4L2 API. Cropping a smaller image from a larger one is achieved by
setting the field ``bytesperline`` at struct
:c:type:`v4l2_pix_format`.
Introducing an image offsets could be done by modifying field ``m_userptr``
at struct
:c:type:`v4l2_buffer` before calling
:ref:`VIDIOC_QBUF`. Those operations should be avoided because they are not
portable (endianness), and do not work for macroblock and Bayer formats
and mmap buffers. The selection API deals with configuration of buffer
cropping/composing in a clear, intuitive and portable way. Next, with
the selection API the concepts of the padded target and constraints
flags are introduced. Finally, struct :c:type:`v4l2_crop`
and struct :c:type:`v4l2_cropcap` have no reserved
fields. Therefore there is no way to extend their functionality. The new
struct :c:type:`v4l2_selection` provides a lot of place
for future extensions. Driver developers are encouraged to implement
only selection API. The former cropping API would be simulated using the
new one.

137
Documentation/media/uapi/v4l/selection-api-configuration.rst Normal file
View file

@ -0,0 +1,137 @@
.. -*- coding: utf-8; mode: rst -*-
*************
Configuration
*************
Applications can use the :ref:`selection API <VIDIOC_G_SELECTION>` to
select an area in a video signal or a buffer, and to query for default
settings and hardware limits.
Video hardware can have various cropping, composing and scaling
limitations. It may only scale up or down, support only discrete scaling
factors, or have different scaling abilities in the horizontal and
vertical directions. Also it may not support scaling at all. At the same
time the cropping/composing rectangles may have to be aligned, and both
the source and the sink may have arbitrary upper and lower size limits.
Therefore, as usual, drivers are expected to adjust the requested
parameters and return the actual values selected. An application can
control the rounding behaviour using
:ref:`constraint flags <v4l2-selection-flags>`.
Configuration of video capture
==============================
See figure :ref:`sel-targets-capture` for examples of the selection
targets available for a video capture device. It is recommended to
configure the cropping targets before to the composing targets.
The range of coordinates of the top left corner, width and height of
areas that can be sampled is given by the ``V4L2_SEL_TGT_CROP_BOUNDS``
target. It is recommended for the driver developers to put the top/left
corner at position ``(0,0)``. The rectangle's coordinates are expressed
in pixels.
The top left corner, width and height of the source rectangle, that is
the area actually sampled, is given by the ``V4L2_SEL_TGT_CROP`` target.
It uses the same coordinate system as ``V4L2_SEL_TGT_CROP_BOUNDS``. The
active cropping area must lie completely inside the capture boundaries.
The driver may further adjust the requested size and/or position
according to hardware limitations.
Each capture device has a default source rectangle, given by the
``V4L2_SEL_TGT_CROP_DEFAULT`` target. This rectangle shall cover what the
driver writer considers the complete picture. Drivers shall set the
active crop rectangle to the default when the driver is first loaded,
but not later.
The composing targets refer to a memory buffer. The limits of composing
coordinates are obtained using ``V4L2_SEL_TGT_COMPOSE_BOUNDS``. All
coordinates are expressed in pixels. The rectangle's top/left corner
must be located at position ``(0,0)``. The width and height are equal to
the image size set by :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`.
The part of a buffer into which the image is inserted by the hardware is
controlled by the ``V4L2_SEL_TGT_COMPOSE`` target. The rectangle's
coordinates are also expressed in the same coordinate system as the
bounds rectangle. The composing rectangle must lie completely inside
bounds rectangle. The driver must adjust the composing rectangle to fit
to the bounding limits. Moreover, the driver can perform other
adjustments according to hardware limitations. The application can
control rounding behaviour using
:ref:`constraint flags <v4l2-selection-flags>`.
For capture devices the default composing rectangle is queried using
``V4L2_SEL_TGT_COMPOSE_DEFAULT``. It is usually equal to the bounding
rectangle.
The part of a buffer that is modified by the hardware is given by
``V4L2_SEL_TGT_COMPOSE_PADDED``. It contains all pixels defined using
``V4L2_SEL_TGT_COMPOSE`` plus all padding data modified by hardware
during insertion process. All pixels outside this rectangle *must not*
be changed by the hardware. The content of pixels that lie inside the
padded area but outside active area is undefined. The application can
use the padded and active rectangles to detect where the rubbish pixels
are located and remove them if needed.
Configuration of video output
=============================
For output devices targets and ioctls are used similarly to the video
capture case. The *composing* rectangle refers to the insertion of an
image into a video signal. The cropping rectangles refer to a memory
buffer. It is recommended to configure the composing targets before to
the cropping targets.
The cropping targets refer to the memory buffer that contains an image
to be inserted into a video signal or graphical screen. The limits of
cropping coordinates are obtained using ``V4L2_SEL_TGT_CROP_BOUNDS``.
All coordinates are expressed in pixels. The top/left corner is always
point ``(0,0)``. The width and height is equal to the image size
specified using :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
The top left corner, width and height of the source rectangle, that is
the area from which image date are processed by the hardware, is given
by the ``V4L2_SEL_TGT_CROP``. Its coordinates are expressed in in the
same coordinate system as the bounds rectangle. The active cropping area
must lie completely inside the crop boundaries and the driver may
further adjust the requested size and/or position according to hardware
limitations.
For output devices the default cropping rectangle is queried using
``V4L2_SEL_TGT_CROP_DEFAULT``. It is usually equal to the bounding
rectangle.
The part of a video signal or graphics display where the image is
inserted by the hardware is controlled by ``V4L2_SEL_TGT_COMPOSE``
target. The rectangle's coordinates are expressed in pixels. The
composing rectangle must lie completely inside the bounds rectangle. The
driver must adjust the area to fit to the bounding limits. Moreover, the
driver can perform other adjustments according to hardware limitations.
The device has a default composing rectangle, given by the
``V4L2_SEL_TGT_COMPOSE_DEFAULT`` target. This rectangle shall cover what
the driver writer considers the complete picture. It is recommended for
the driver developers to put the top/left corner at position ``(0,0)``.
Drivers shall set the active composing rectangle to the default one when
the driver is first loaded.
The devices may introduce additional content to video signal other than
an image from memory buffers. It includes borders around an image.
However, such a padded area is driver-dependent feature not covered by
this document. Driver developers are encouraged to keep padded rectangle
equal to active one. The padded target is accessed by the
``V4L2_SEL_TGT_COMPOSE_PADDED`` identifier. It must contain all pixels
from the ``V4L2_SEL_TGT_COMPOSE`` target.
Scaling control
===============
An application can detect if scaling is performed by comparing the width
and the height of rectangles obtained using ``V4L2_SEL_TGT_CROP`` and
``V4L2_SEL_TGT_COMPOSE`` targets. If these are not equal then the
scaling is applied. The application can compute the scaling ratios using
these values.

Some files were not shown because too many files have changed in this diff Show more