You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
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
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -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>;
|
||||
};
|
||||
...
|
||||
};
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -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.
|
||||
|
||||
@@ -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}|
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -41,6 +41,6 @@ applicable to all devices.
|
||||
extended-controls
|
||||
format
|
||||
planar-apis
|
||||
crop
|
||||
selection-api
|
||||
crop
|
||||
streaming-par
|
||||
|
||||
@@ -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
|
||||
===================
|
||||
|
||||
@@ -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.
|
||||
+1
-1
@@ -41,7 +41,7 @@ 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 over what 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.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user