Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
提交 de161757 编写于 作者: L Linus Torvalds
浏览文件
操作

Merge tag 'media/v5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 

Pull media updates from Mauro Carvalho Chehab:

 - some core fixes in VB2 mem2mem support

 - some improvements and cleanups in V4L2 async kAPI

 - newer controls in V4L2 API for H-264 and HEVC codecs

 - allegro-dvt driver was promoted from staging

 - new i2c sendor drivers: imx334, ov5648, ov8865

 - new automobile camera module: rdacm21

 - ipu3 cio2 driver started gained support for some ACPI BIOSes

 - new ATSC frontend: MaxLinear mxl692 VSB tuner/demod

 - the SMIA/CCS driver gained more support for CSS standard

 - several driver fixes, updates and improvements

* tag 'media/v5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (362 commits)
  media: v4l: async: Fix kerneldoc documentation for async functions
  media: i2c: max9271: Add MODULE_* macros
  media: i2c: Kconfig: Make MAX9271 a module
  media: imx334: 'ret' is uninitialized, should have been PTR_ERR()
  media: i2c: Add imx334 camera sensor driver
  media: dt-bindings: media: Add bindings for imx334
  media: ov8856: Configure sensor for GRBG Bayer for all modes
  media: i2c: imx219: Implement V4L2_CID_LINK_FREQ control
  media: ov5675: fix vflip/hflip control
  media: ipu3-cio2: Build bridge only if ACPI is enabled
  media: Remove the legacy v4l2-clk API
  media: ov6650: Use the generic clock framework
  media: mt9m111: Use the generic clock framework
  media: ov9640: Use the generic clock framework
  media: pxa_camera: Drop the v4l2-clk clock register
  media: mach-pxa: Register the camera sensor fixed-rate clock
  media: i2c: imx258: get clock from device properties and enable it via runtime PM
  media: i2c: imx258: simplify getting state container
  media: i2c: imx258: add support for binding via device tree
  media: dt-bindings: media: imx258: add bindings for IMX258 sensor
  ...
上级 66f73fb3 8f202f8e
展开全部 隐藏空白更改
内联 并排
Showing with 22207 addition and 5288 deletion
Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
浏览文件 @ de161757
......@@ -111,8 +111,8 @@ of the following host1x client modules:
endpoint (required node)
Required properties:
- data-lanes: an array of data lane from 1 to 4. Valid array
lengths are 1/2/4.
- data-lanes: an array of data lane from 1 to 8. Valid array
lengths are 1/2/4/8.
- remote-endpoint: phandle to sensor 'endpoint' node.
port@1 (required node)
......
Documentation/devicetree/bindings/media/allegro,al5e.yaml 0 → 100644
浏览文件 @ de161757
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/allegro,al5e.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allegro DVT Video IP Codecs Device Tree Bindings
maintainers:
- Michael Tretter <m.tretter@pengutronix.de>
description: |-
Allegro DVT video IP codecs present in the Xilinx ZynqMP SoC. The IP core may
either be a H.264/H.265 encoder or H.264/H.265 decoder ip core.
Each actual codec engine is controlled by a microcontroller (MCU). Host
software uses a provided mailbox interface to communicate with the MCU. The
MCUs share an interrupt.
properties:
compatible:
oneOf:
- items:
- const: allegro,al5e-1.1
- const: allegro,al5e
- items:
- const: allegro,al5d-1.1
- const: allegro,al5d
reg:
items:
- description: The registers
- description: The SRAM
reg-names:
items:
- const: regs
- const: sram
interrupts:
maxItems: 1
clocks:
items:
- description: Core clock
- description: MCU clock
- description: Core AXI master port clock
- description: MCU AXI master port clock
- description: AXI4-Lite slave port clock
clock-names:
items:
- const: core_clk
- const: mcu_clk
- const: m_axi_core_aclk
- const: m_axi_mcu_aclk
- const: s_axi_lite_aclk
required:
- compatible
- reg
- reg-names
- interrupts
- clocks
- clock-names
additionalProperties: False
examples:
- |
fpga {
#address-cells = <2>;
#size-cells = <2>;
al5e: video-codec@a0009000 {
compatible = "allegro,al5e-1.1", "allegro,al5e";
reg = <0 0xa0009000 0 0x1000>,
<0 0xa0000000 0 0x8000>;
reg-names = "regs", "sram";
interrupts = <0 96 4>;
clocks = <&xlnx_vcu 0>, <&xlnx_vcu 1>,
<&clkc 71>, <&clkc 71>, <&clkc 71>;
clock-names = "core_clk", "mcu_clk", "m_axi_core_aclk",
"m_axi_mcu_aclk", "s_axi_lite_aclk";
};
};
- |
fpga {
#address-cells = <2>;
#size-cells = <2>;
al5d: video-codec@a0029000 {
compatible = "allegro,al5d-1.1", "allegro,al5d";
reg = <0 0xa0029000 0 0x1000>,
<0 0xa0020000 0 0x8000>;
reg-names = "regs", "sram";
interrupts = <0 96 4>;
clocks = <&xlnx_vcu 2>, <&xlnx_vcu 3>,
<&clkc 71>, <&clkc 71>, <&clkc 71>;
clock-names = "core_clk", "mcu_clk", "m_axi_core_aclk",
"m_axi_mcu_aclk", "s_axi_lite_aclk";
};
};
...
Documentation/devicetree/bindings/media/allegro.txt 已删除 100644 → 0
浏览文件 @ 66f73fb3
Device-tree bindings for the Allegro DVT video IP codecs present in the Xilinx
ZynqMP SoC. The IP core may either be a H.264/H.265 encoder or H.264/H.265
decoder ip core.
Each actual codec engines is controlled by a microcontroller (MCU). Host
software uses a provided mailbox interface to communicate with the MCU. The
MCU share an interrupt.
Required properties:
- compatible: value should be one of the following
"allegro,al5e-1.1", "allegro,al5e": encoder IP core
"allegro,al5d-1.1", "allegro,al5d": decoder IP core
- reg: base and length of the memory mapped register region and base and
length of the memory mapped sram
- reg-names: must include "regs" and "sram"
- interrupts: shared interrupt from the MCUs to the processing system
- clocks: must contain an entry for each entry in clock-names
- clock-names: must include "core_clk", "mcu_clk", "m_axi_core_aclk",
"m_axi_mcu_aclk", "s_axi_lite_aclk"
Example:
al5e: video-codec@a0009000 {
compatible = "allegro,al5e-1.1", "allegro,al5e";
reg = <0 0xa0009000 0 0x1000>,
<0 0xa0000000 0 0x8000>;
reg-names = "regs", "sram";
interrupts = <0 96 4>;
clocks = <&xlnx_vcu 0>, <&xlnx_vcu 1>,
<&clkc 71>, <&clkc 71>, <&clkc 71>;
clock-names = "core_clk", "mcu_clk", "m_axi_core_aclk",
"m_axi_mcu_aclk", "s_axi_lite_aclk"
};
al5d: video-codec@a0029000 {
compatible = "allegro,al5d-1.1", "allegro,al5d";
reg = <0 0xa0029000 0 0x1000>,
<0 0xa0020000 0 0x8000>;
reg-names = "regs", "sram";
interrupts = <0 96 4>;
clocks = <&xlnx_vcu 2>, <&xlnx_vcu 3>,
<&clkc 71>, <&clkc 71>, <&clkc 71>;
clock-names = "core_clk", "mcu_clk", "m_axi_core_aclk",
"m_axi_mcu_aclk", "s_axi_lite_aclk"
};
Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
浏览文件 @ de161757
......@@ -67,14 +67,14 @@ properties:
interconnect-names:
const: dma-mem
# See ./video-interfaces.txt for details
port:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
type: object
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
bus-width:
......@@ -83,7 +83,6 @@ properties:
data-active: true
hsync-active: true
pclk-sample: true
remote-endpoint: true
vsync-active: true
required:
......@@ -91,12 +90,8 @@ properties:
- data-active
- hsync-active
- pclk-sample
- remote-endpoint
- vsync-active
required:
- endpoint
required:
- compatible
- reg
......
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
浏览文件 @ de161757
......@@ -40,17 +40,15 @@ properties:
resets:
maxItems: 1
# See ./video-interfaces.txt for details
port:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:
type: object
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
remote-endpoint: true
bus-width:
enum: [ 8, 10, 12, 16 ]
......@@ -60,10 +58,6 @@ properties:
required:
- bus-width
- remote-endpoint
required:
- endpoint
additionalProperties: false
......
Documentation/devicetree/bindings/media/i2c/adv7180.yaml
浏览文件 @ de161757
......@@ -36,17 +36,9 @@ properties:
maxItems: 1
port:
type: object
description:
A node containing a single endpoint as doucmented in
Documentation/devicetree/bindings/media/video-interfaces.txt
ports:
type: object
description:
A node containing input and output port nodes with endpoint definitions
as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
$ref: /schemas/graph.yaml#/properties/port
ports: true
additionalProperties: false
......@@ -80,25 +72,20 @@ allOf:
then:
properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
port@3:
type: object
$ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-2]$":
type: object
$ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@3
additionalProperties: false
required:
- ports
......@@ -110,25 +97,20 @@ allOf:
then:
properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
port@6:
type: object
$ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-5]$":
type: object
$ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@6
additionalProperties: false
required:
- ports
......
Documentation/devicetree/bindings/media/i2c/adv7604.yaml
浏览文件 @ de161757
......@@ -64,16 +64,12 @@ properties:
description:
Select which input is selected after reset.
ports:
type: object
description:
A node containing input and output port nodes with endpoint definitions
as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
ports: true
required:
- compatible
- reg
- ports
additionalProperties: false
......@@ -86,26 +82,19 @@ allOf:
then:
properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
port@0:
type: object
$ref: /schemas/graph.yaml#/properties/port
description: Input port
port@1:
type: object
$ref: /schemas/graph.yaml#/properties/port
description: Output port
required:
- port@1
additionalProperties: false
required:
- ports
- if:
properties:
compatible:
......@@ -114,28 +103,20 @@ allOf:
then:
properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
port@2:
type: object
$ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-1]$":
type: object
$ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@2
additionalProperties: false
required:
- ports
examples:
- |
#include <dt-bindings/gpio/gpio.h>
......
Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
浏览文件 @ de161757
......@@ -41,9 +41,9 @@ properties:
maxItems: 1
port:
type: object
$ref: /schemas/graph.yaml#/properties/port
description: |
Output video port. See ../video-interfaces.txt.
Output video port.
required:
- compatible
......
Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
浏览文件 @ de161757
......@@ -86,33 +86,9 @@ properties:
maxItems: 3
port:
type: object
additionalProperties: false
description: -|
Connection to the remote GMSL endpoint are modelled using the OF graph
bindings in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
The device node contains a single "port" child node with a single
"endpoint" sub-device.
properties:
endpoint:
type: object
additionalProperties: false
properties:
remote-endpoint:
description: -|
phandle to the remote GMSL endpoint sub-node in the remote node
port.
maxItems: 1
required:
- remote-endpoint
required:
- endpoint
$ref: /schemas/graph.yaml#/properties/port
description:
Connection to the remote GMSL endpoint.
required:
- compatible
......
Documentation/devicetree/bindings/media/i2c/imx219.yaml
浏览文件 @ de161757
......@@ -44,12 +44,15 @@ properties:
Reference to the GPIO connected to the xclr pin, if any.
Must be released (set high) after all supplies are applied.
# See ../video-interfaces.txt for more details
port:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-lanes:
description: |-
......@@ -60,16 +63,8 @@ properties:
- const: 1
- const: 2
clock-noncontinuous:
type: boolean
description: |-
MIPI CSI-2 clock is non-continuous if this property is present,
otherwise it's continuous.
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description:
Allowed data bus frequencies.
clock-noncontinuous: true
link-frequencies: true
required:
- link-frequencies
......
Documentation/devicetree/bindings/media/i2c/imx258.yaml 0 → 100644
浏览文件 @ de161757
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/imx258.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sony IMX258 13 Mpixel CMOS Digital Image Sensor
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
description: |-
IMX258 is a diagonal 5.867mm (Type 1/3.06) 13 Mega-pixel CMOS active pixel
type stacked image sensor with a square pixel array of size 4208 x 3120. It
is programmable through I2C interface. Image data is sent through MIPI
CSI-2.
properties:
compatible:
const: sony,imx258
assigned-clocks: true
assigned-clock-parents: true
assigned-clock-rates: true
clocks:
description:
Clock frequency from 6 to 27 MHz.
maxItems: 1
reg:
maxItems: 1
reset-gpios:
description: |-
Reference to the GPIO connected to the XCLR pin, if any.
vana-supply:
description:
Analog voltage (VANA) supply, 2.7 V
vdig-supply:
description:
Digital I/O voltage (VDIG) supply, 1.2 V
vif-supply:
description:
Interface voltage (VIF) supply, 1.8 V
# See ../video-interfaces.txt for more details
port:
type: object
properties:
endpoint:
type: object
properties:
data-lanes:
oneOf:
- items:
- const: 1
- const: 2
- const: 3
- const: 4
- items:
- const: 1
- const: 2
link-frequencies:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint64-array
description:
Allowed data bus frequencies.
required:
- data-lanes
- link-frequencies
required:
- compatible
- reg
- port
additionalProperties: false
examples:
- |
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
sensor@6c {
compatible = "sony,imx258";
reg = <0x6c>;
clocks = <&imx258_clk>;
port {
endpoint {
remote-endpoint = <&csi1_ep>;
data-lanes = <1 2 3 4>;
link-frequencies = /bits/ 64 <320000000>;
};
};
};
};
/* Oscillator on the camera board */
imx258_clk: clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <19200000>;
};
- |
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
sensor@6c {
compatible = "sony,imx258";
reg = <0x6c>;
clocks = <&imx258_clk>;
assigned-clocks = <&imx258_clk>;
assigned-clock-rates = <19200000>;
port {
endpoint {
remote-endpoint = <&csi1_ep>;
data-lanes = <1 2 3 4>;
link-frequencies = /bits/ 64 <633600000>;
};
};
};
};
Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
浏览文件 @ de161757
......@@ -50,82 +50,62 @@ properties:
'#gpio-cells':
const: 2
ports:
type: object
maxim,reverse-channel-microvolt:
minimum: 30000
maximum: 200000
default: 170000
description: |
The connections to the MAX9286 GMSL and its endpoint nodes are modelled
using the OF graph bindings in accordance with the video interface
bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
The following table lists the port number corresponding to each device
port.
Port Description
----------------------------------------
Port 0 GMSL Input 0
Port 1 GMSL Input 1
Port 2 GMSL Input 2
Port 3 GMSL Input 3
Port 4 CSI-2 Output
Initial amplitude of the reverse control channel, in micro volts.
properties:
'#address-cells':
const: 1
The initial amplitude shall be adjusted to a value compatible with the
configuration of the connected remote serializer.
'#size-cells':
const: 0
Some camera modules (for example RDACM20) include an on-board MCU that
pre-programs the embedded serializer with power supply noise immunity
(high-threshold) enabled. A typical value of the deserializer's reverse
channel amplitude to communicate with pre-programmed serializers is
170000 micro volts.
port@[0-3]:
type: object
properties:
reg:
enum: [ 0, 1, 2, 3 ]
A typical value for the reverse channel amplitude to communicate with
a remote serializer whose high-threshold noise immunity is not enabled
is 100000 micro volts
endpoint:
type: object
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
remote-endpoint:
description: |
phandle to the remote GMSL source endpoint subnode in the
remote node port.
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: GMSL Input 0
required:
- remote-endpoint
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: GMSL Input 1
required:
- reg
- endpoint
port@2:
$ref: /schemas/graph.yaml#/properties/port
description: GMSL Input 2
additionalProperties: false
port@3:
$ref: /schemas/graph.yaml#/properties/port
description: GMSL Input 3
port@4:
type: object
properties:
reg:
const: 4
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: CSI-2 Output
properties:
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
remote-endpoint:
description: phandle to the remote CSI-2 sink endpoint.
data-lanes:
description: array of physical CSI-2 data lane indexes.
data-lanes: true
required:
- remote-endpoint
- data-lanes
required:
- reg
- endpoint
additionalProperties: false
required:
- port@4
......@@ -183,25 +163,8 @@ properties:
requirements of the currently connected remote device.
port:
type: object
properties:
endpoint:
type: object
properties:
remote-endpoint:
description: phandle to the MAX9286 sink endpoint.
required:
- remote-endpoint
additionalProperties: false
required:
- endpoint
additionalProperties: false
$ref: /schemas/graph.yaml#/properties/port
description: Connection to the MAX9286 sink.
required:
- compatible
......@@ -242,6 +205,8 @@ examples:
gpio-controller;
#gpio-cells = <2>;
maxim,reverse-channel-microvolt = <170000>;
ports {
#address-cells = <1>;
#size-cells = <0>;
......
Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
浏览文件 @ de161757
......@@ -71,19 +71,18 @@ properties:
enum: [ 0, 180 ]
port:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description: List of allowed data link frequencies.
data-lanes:
minItems: 1
maxItems: 8
link-frequencies: true
data-lanes: true
bus-type:
description: The type of the data bus.
oneOf:
- const: 1 # CSI-2 C-PHY
- const: 3 # CCP2
......
Documentation/devicetree/bindings/media/i2c/ov8856.yaml
浏览文件 @ de161757
......@@ -57,16 +57,13 @@ properties:
active low.
port:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
description:
A node containing an output port node with an endpoint definition
as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-lanes:
......@@ -79,18 +76,14 @@ properties:
- const: 4
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description:
Allowed data bus frequencies. 360000000, 180000000 Hz or both
are supported by the driver.
description: Frequencies listed are driver, not h/w limitations.
maxItems: 2
items:
enum: [ 360000000, 180000000 ]
required:
- link-frequencies
required:
- endpoint
required:
- compatible
- reg
......@@ -139,4 +132,3 @@ examples:
};
};
...
Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
浏览文件 @ de161757
......@@ -17,6 +17,9 @@ description: |-
@ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
sensor output is available via CSI-2 serial data output.
allOf:
- $ref: /schemas/media/video-interface-devices.yaml#
properties:
compatible:
const: ovti,ov02a10
......@@ -66,42 +69,34 @@ properties:
maxItems: 1
rotation:
description:
Definition of the sensor's placement.
allOf:
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum:
- 0 # Sensor Mounted Upright
- 180 # Sensor Mounted Upside Down
default: 0
# See ../video-interfaces.txt for details
enum:
- 0 # Sensor Mounted Upright
- 180 # Sensor Mounted Upside Down
default: 0
port:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
description:
Output port node, single endpoint describing the CSI-2 transmitter.
properties:
endpoint:
type: object
additionalProperties: false
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
link-frequencies: true
ovti,mipi-clock-voltage:
allOf:
- $ref: "/schemas/types.yaml#/definitions/uint32"
$ref: "/schemas/types.yaml#/definitions/uint32"
description:
Definition of MIPI clock voltage unit. This entry corresponds to
the link speed defined by the 'link-frequencies' property.
If present, the value shall be in the range of 0-4.
default: 4
remote-endpoint: true
required:
- link-frequencies
- remote-endpoint
required:
- endpoint
......
Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
浏览文件 @ de161757
......@@ -50,11 +50,9 @@ properties:
Definition of the regulator used as digital power supply.
port:
type: object
$ref: /schemas/graph.yaml#/properties/port
description:
A node containing an output port node with an endpoint definition
as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
A node containing an output port node.
required:
- compatible
......
Documentation/devicetree/bindings/media/i2c/ov5647.yaml → Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml
浏览文件 @ de161757
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/ov5647.yaml#
$id: http://devicetree.org/schemas/media/i2c/ovti,ov5647.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Omnivision OV5647 raw image sensor
......@@ -31,27 +31,15 @@ properties:
maxItems: 1
port:
type: object
description: |-
Should contain one endpoint sub-node used to model connection to the
video receiver according to the specification defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
$ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
remote-endpoint:
description: |-
phandle to the video receiver input port.
clock-noncontinuous:
type: boolean
description: |-
Set to true to allow MIPI CSI-2 non-continuous clock operations.
additionalProperties: false
clock-noncontinuous: true
additionalProperties: false
......
Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml 0 → 100644
浏览文件 @ de161757
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/ovti,ov5648.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: OmniVision OV5648 Image Sensor Device Tree Bindings
maintainers:
- Paul Kocialkowski <paul.kocialkowski@bootlin.com>
properties:
compatible:
const: ovti,ov5648
reg:
maxItems: 1
clocks:
items:
- description: XVCLK Clock
assigned-clocks:
maxItems: 1
assigned-clock-rates:
maxItems: 1
dvdd-supply:
description: Digital Domain Power Supply
avdd-supply:
description: Analog Domain Power Supply (internal AVDD is used if missing)
dovdd-supply:
description: I/O Domain Power Supply
powerdown-gpios:
maxItems: 1
description: Power Down Pin GPIO Control (active low)
reset-gpios:
maxItems: 1
description: Reset Pin GPIO Control (active low)
port:
type: object
description: MIPI CSI-2 transmitter port
properties:
endpoint:
type: object
properties:
remote-endpoint: true
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description: Allowed MIPI CSI-2 link frequencies
data-lanes:
minItems: 1
maxItems: 2
required:
- data-lanes
- link-frequencies
- remote-endpoint
required:
- endpoint
required:
- compatible
- reg
- clocks
- assigned-clocks
- assigned-clock-rates
- dvdd-supply
- dovdd-supply
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/sun8i-v3s-ccu.h>
#include <dt-bindings/gpio/gpio.h>
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
ov5648: camera@36 {
compatible = "ovti,ov5648";
reg = <0x36>;
dvdd-supply = <&ov5648_dvdd>;
avdd-supply = <&ov5648_avdd>;
dovdd-supply = <&ov5648_dovdd>;
clocks = <&ov5648_xvclk 0>;
assigned-clocks = <&ov5648_xvclk 0>;
assigned-clock-rates = <24000000>;
ov5648_out: port {
ov5648_out_mipi_csi2: endpoint {
data-lanes = <1 2>;
link-frequencies = /bits/ 64 <210000000 168000000>;
remote-endpoint = <&mipi_csi2_in_ov5648>;
};
};
};
};
Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
浏览文件 @ de161757
......@@ -37,13 +37,14 @@ properties:
maxItems: 1
port:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
description: |
Video output port. See ../video-interfaces.txt.
Video output port.
properties:
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
bus-type:
......@@ -91,8 +92,6 @@ properties:
required:
- bus-type
unevaluatedProperties: false
additionalProperties: false
required:
......
Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml 0 → 100644
浏览文件 @ de161757
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/ovti,ov8865.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: OmniVision OV8865 Image Sensor Device Tree Bindings
maintainers:
- Paul Kocialkowski <paul.kocialkowski@bootlin.com>
properties:
compatible:
const: ovti,ov8865
reg:
maxItems: 1
clocks:
items:
- description: EXTCLK Clock
assigned-clocks:
maxItems: 1
assigned-clock-rates:
maxItems: 1
dvdd-supply:
description: Digital Domain Power Supply
avdd-supply:
description: Analog Domain Power Supply
dovdd-supply:
description: I/O Domain Power Supply
powerdown-gpios:
maxItems: 1
description: Power Down Pin GPIO Control (active low)
reset-gpios:
maxItems: 1
description: Reset Pin GPIO Control (active low)
port:
type: object
description: MIPI CSI-2 transmitter port
properties:
endpoint:
type: object
properties:
remote-endpoint: true
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description: Allowed MIPI CSI-2 link frequencies
data-lanes:
minItems: 1
maxItems: 4
required:
- data-lanes
- link-frequencies
- remote-endpoint
required:
- endpoint
required:
- compatible
- reg
- clocks
- assigned-clocks
- assigned-clock-rates
- dvdd-supply
- avdd-supply
- dovdd-supply
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/sun8i-a83t-ccu.h>
#include <dt-bindings/gpio/gpio.h>
i2c2 {
#address-cells = <1>;
#size-cells = <0>;
ov8865: camera@36 {
compatible = "ovti,ov8865";
reg = <0x36>;
pinctrl-names = "default";
pinctrl-0 = <&csi_mclk_pin>;
clocks = <&ccu CLK_CSI_MCLK>;
assigned-clocks = <&ccu CLK_CSI_MCLK>;
assigned-clock-rates = <24000000>;
avdd-supply = <&reg_ov8865_avdd>;
dovdd-supply = <&reg_ov8865_dovdd>;
dvdd-supply = <&reg_ov8865_dvdd>;
powerdown-gpios = <&pio 4 17 GPIO_ACTIVE_LOW>; /* PE17 */
reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
port {
ov8865_out_mipi_csi2: endpoint {
data-lanes = <1 2 3 4>;
link-frequencies = /bits/ 64 <360000000>;
remote-endpoint = <&mipi_csi2_in_ov8865>;
};
};
};
};
...
Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
浏览文件 @ de161757
......@@ -15,6 +15,9 @@ description: |
interface. Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a
maximum throughput of 1.2Gbps/lane.
allOf:
- $ref: ../video-interface-devices.yaml#
properties:
compatible:
const: sony,imx214
......@@ -44,25 +47,21 @@ properties:
vddd-supply:
description: Chip digital core regulator (1.12V).
flash-leds:
description: See ../video-interfaces.txt
lens-focus:
description: See ../video-interfaces.txt
flash-leds: true
lens-focus: true
port:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
description: |
Video output port. See ../video-interfaces.txt.
Video output port.
properties:
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: See ../video-interfaces.txt
anyOf:
- items:
- const: 1
......@@ -73,16 +72,12 @@ properties:
- const: 3
- const: 4
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description: See ../video-interfaces.txt
link-frequencies: true
required:
- data-lanes
- link-frequencies
unevaluatedProperties: false
additionalProperties: false
required:
......
Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
浏览文件 @ de161757
......@@ -41,8 +41,7 @@ properties:
description: Sensor digital IO 1.2 V supply.
port:
type: object
description: Output video port. See ../video-interfaces.txt.
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
......
Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml 0 → 100644
浏览文件 @ de161757
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2021 Intel Corporation
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/sony,imx334.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sony IMX334 Sensor
maintainers:
- Paul J. Murphy <paul.j.murphy@intel.com>
- Daniele Alessandrelli <daniele.alessandrelli@intel.com>
description:
IMX334 sensor is a Sony CMOS active pixel digital image sensor with an active
array size of 3864H x 2202V. It is programmable through I2C interface. The
I2C client address is fixed to 0x1a as per sensor data sheet. Image data is
sent through MIPI CSI-2.
properties:
compatible:
const: sony,imx334
reg:
description: I2C address
maxItems: 1
assigned-clocks: true
assigned-clock-parents: true
assigned-clock-rates: true
clocks:
description: Clock frequency from 6 to 27 MHz, 37.125MHz, 74.25MHz
maxItems: 1
reset-gpios:
description: Reference to the GPIO connected to the XCLR pin, if any.
port:
type: object
additionalProperties: false
$ref: /schemas/graph.yaml#/properties/port
properties:
endpoint:
type: object
properties:
data-lanes:
$ref: ../video-interfaces.yaml#/properties/data-lanes
link-frequencies:
$ref: ../video-interfaces.yaml#/properties/link-frequencies
required:
- data-lanes
- link-frequencies
required:
- endpoint
required:
- compatible
- reg
- clocks
- port
additionalProperties: false
examples:
- |
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
camera@1a {
compatible = "sony,imx334";
reg = <0x1a>;
clocks = <&imx334_clk>;
assigned-clocks = <&imx334_clk>;
assigned-clock-parents = <&imx334_clk_parent>;
assigned-clock-rates = <24000000>;
port {
imx334: endpoint {
remote-endpoint = <&cam>;
data-lanes = <1 2 3 4>;
link-frequencies = /bits/ 64 <891000000>;
};
};
};
};
...
Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
浏览文件 @ de161757
......@@ -27,29 +27,20 @@ properties:
maxItems: 1
port:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
type: object
additionalProperties: false
$ref: video-interfaces.yaml#
unevaluatedProperties: false
# Properties described in
# Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
remote-endpoint: true
hsync-active: true
vsync-active: true
pclk-sample: true
bus-type: true
required:
- remote-endpoint
required:
- endpoint
clocks:
minItems: 1
maxItems: 3
......
Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
浏览文件 @ de161757
......@@ -33,10 +33,7 @@ properties:
- const: mclk
port:
type: object
description:
A node containing input port nodes with endpoint definitions as documented
in Documentation/devicetree/bindings/media/video-interfaces.txt
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
......
Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
浏览文件 @ de161757
......@@ -58,35 +58,22 @@ properties:
Differential receiver (HS-RX) settle time
ports:
type: object
description:
A node containing input and output port nodes with endpoint definitions
as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
$ref: /schemas/graph.yaml#/properties/ports
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
port@0:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port node, single endpoint describing the CSI-2 transmitter.
properties:
reg:
const: 0
endpoint:
type: object
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: See ../video-interfaces.txt
oneOf:
- items:
- const: 1
......@@ -94,18 +81,11 @@ properties:
- const: 1
- const: 2
remote-endpoint: true
required:
- data-lanes
- remote-endpoint
additionalProperties: false
additionalProperties: false
port@1:
type: object
$ref: /schemas/graph.yaml#/properties/port
description:
Output port node
......
Documentation/devicetree/bindings/media/renesas,ceu.yaml
浏览文件 @ de161757
......@@ -34,18 +34,15 @@ properties:
maxItems: 1
port:
type: object
additionalProperties: false
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
properties:
endpoint:
type: object
additionalProperties: false
$ref: video-interfaces.yaml#
unevaluatedProperties: false
# Properties described in
# Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
remote-endpoint: true
hsync-active: true
vsync-active: true
field-even-active: false
......@@ -53,12 +50,6 @@ properties:
enum: [8, 16]
default: 8
required:
- remote-endpoint
required:
- endpoint
required:
- compatible
- reg
......
Documentation/devicetree/bindings/media/renesas,csi2.yaml
浏览文件 @ de161757
......@@ -46,24 +46,19 @@ properties:
maxItems: 1
ports:
type: object
description:
A node containing input and output port nodes with endpoint definitions
as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Input port node, single endpoint describing the CSI-2 transmitter.
properties:
reg:
const: 0
endpoint:
type: object
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
......@@ -72,50 +67,19 @@ properties:
data-lanes:
maxItems: 1
remote-endpoint: true
required:
- clock-lanes
- data-lanes
- remote-endpoint
additionalProperties: false
additionalProperties: false
port@1:
type: object
$ref: /schemas/graph.yaml#/properties/port
description:
Output port node, multiple endpoints describing all the R-Car VIN
modules connected the CSI-2 receiver.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
reg:
const: 1
patternProperties:
"^endpoint@[0-9a-f]$":
type: object
properties:
reg:
maxItems: 1
remote-endpoint: true
required:
- reg
- remote-endpoint
additionalProperties: false
additionalProperties: false
required:
- port@0
- port@1
required:
- compatible
......
Documentation/devicetree/bindings/media/renesas,vin.yaml
浏览文件 @ de161757
......@@ -69,15 +69,15 @@ properties:
#The per-board settings for Gen2 and RZ/G1 platforms:
port:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
A node containing a parallel input with a single endpoint definitions as
documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
A node containing a parallel input
properties:
endpoint:
type: object
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
hsync-active:
......@@ -106,15 +106,6 @@ properties:
data-active: true
remote-endpoint: true
required:
- remote-endpoint
additionalProperties: false
additionalProperties: false
#The per-board settings for Gen3 and RZ/G2 platforms:
renesas,id:
description: VIN channel number
......@@ -123,23 +114,18 @@ properties:
maximum: 15
ports:
type: object
description:
A node containing input nodes with endpoint definitions as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
type: object
$ref: /schemas/graph.yaml#/properties/port
description:
Input port node, single endpoint describing a parallel input source.
properties:
reg:
const: 0
endpoint:
type: object
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
hsync-active:
......@@ -168,98 +154,29 @@ properties:
data-active: true
remote-endpoint: true
required:
- remote-endpoint
additionalProperties: false
required:
- endpoint
additionalProperties: false
port@1:
type: object
$ref: /schemas/graph.yaml#/properties/port
description:
Input port node, multiple endpoints describing all the R-Car CSI-2
modules connected the VIN.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
reg:
const: 1
endpoint@0:
type: object
$ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI20.
properties:
reg:
const: 0
remote-endpoint: true
required:
- reg
- remote-endpoint
additionalProperties: false
endpoint@1:
type: object
$ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI21.
properties:
reg:
const: 1
remote-endpoint: true
required:
- reg
- remote-endpoint
additionalProperties: false
endpoint@2:
type: object
$ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI40.
properties:
reg:
const: 2
remote-endpoint: true
required:
- reg
- remote-endpoint
additionalProperties: false
endpoint@3:
type: object
$ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI41.
properties:
reg:
const: 3
remote-endpoint: true
required:
- reg
- remote-endpoint
additionalProperties: false
anyOf:
- required:
- endpoint@0
......@@ -270,8 +187,6 @@ properties:
- required:
- endpoint@3
additionalProperties: false
required:
- compatible
- reg
......
Documentation/devicetree/bindings/media/rockchip-isp1.yaml
浏览文件 @ de161757
......@@ -56,56 +56,26 @@ properties:
power-domains:
maxItems: 1
# See ./video-interfaces.txt for details
ports:
type: object
additionalProperties: false
$ref: /schemas/graph.yaml#/properties/ports
properties:
"#address-cells":
const: 1
"#size-cells":
const: 0
port@0:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: connection point for sensors at MIPI-DPHY RX0
additionalProperties: false
properties:
"#address-cells":
const: 1
"#size-cells":
const: 0
reg:
const: 0
patternProperties:
endpoint:
type: object
additionalProperties: false
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
reg:
maxItems: 1
data-lanes:
minItems: 1
maxItems: 4
remote-endpoint: true
required:
- reg
- "#address-cells"
- "#size-cells"
required:
- "#address-cells"
- "#size-cells"
- port@0
required:
......
Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
浏览文件 @ de161757
......@@ -37,16 +37,15 @@ properties:
maxItems: 1
port:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
DCMI supports a single port node with parallel bus. It should contain
one 'port' child node with child 'endpoint' node. Please refer to the
bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
DCMI supports a single port node with parallel bus.
properties:
endpoint:
type: object
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
bus-type:
......@@ -57,8 +56,6 @@ properties:
enum: [8, 10, 12, 14]
default: 8
remote-endpoint: true
allOf:
- if:
properties:
......@@ -73,14 +70,9 @@ properties:
enum: [8]
required:
- remote-endpoint
- bus-type
- pclk-sample
unevaluatedProperties: false
additionalProperties: false
required:
- compatible
- reg
......
Documentation/devicetree/bindings/media/ti,cal.yaml
浏览文件 @ de161757
......@@ -15,10 +15,7 @@ description: |-
processing capability to connect CSI2 image-sensor modules to the
DRA72x device.
CAL supports 2 camera port nodes on MIPI bus. Each CSI2 camera port nodes
should contain a 'port' child node with child 'endpoint' node. Please
refer to the bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
CAL supports 2 camera port nodes on MIPI bus.
properties:
compatible:
......@@ -67,31 +64,19 @@ properties:
Documentation/devicetree/bindings/power/power_domain.txt
maxItems: 1
# See ./video-interfaces.txt for details
ports:
type: object
additionalProperties: false
$ref: /schemas/graph.yaml#/properties/ports
properties:
"#address-cells":
const: 1
"#size-cells":
const: 0
port@0:
type: object
additionalProperties: false
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: CSI2 Port #0
properties:
reg:
const: 0
description: CSI2 Port #0
patternProperties:
endpoint:
type: object
additionalProperties: false
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
......@@ -101,24 +86,15 @@ properties:
minItems: 1
maxItems: 4
remote-endpoint: true
required:
- reg
port@1:
type: object
additionalProperties: false
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: CSI2 Port #1
properties:
reg:
const: 1
description: CSI2 Port #1
patternProperties:
endpoint:
type: object
additionalProperties: false
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
......@@ -128,14 +104,7 @@ properties:
minItems: 1
maxItems: 4
remote-endpoint: true
required:
- reg
required:
- "#address-cells"
- "#size-cells"
- port@0
required:
......
Documentation/devicetree/bindings/media/video-interface-devices.yaml 0 → 100644
浏览文件 @ de161757
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/video-interface-devices.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common bindings for video receiver and transmitter devices
maintainers:
- Jacopo Mondi <jacopo@jmondi.org>
- Sakari Ailus <sakari.ailus@linux.intel.com>
properties:
flash-leds:
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
An array of phandles, each referring to a flash LED, a sub-node of the LED
driver device node.
lens-focus:
$ref: /schemas/types.yaml#/definitions/phandle
description:
A phandle to the node of the focus lens controller.
rotation:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 90, 180, 270 ]
description: |
The camera rotation is expressed as the angular difference in degrees
between two reference systems, one relative to the camera module, and one
defined on the external world scene to be captured when projected on the
image sensor pixel array.
A camera sensor has a 2-dimensional reference system 'Rc' defined by its
pixel array read-out order. The origin is set to the first pixel being
read out, the X-axis points along the column read-out direction towards
the last columns, and the Y-axis along the row read-out direction towards
the last row.
A typical example for a sensor with a 2592x1944 pixel array matrix
observed from the front is:
2591 X-axis 0
<------------------------+ 0
.......... ... ..........!
.......... ... ..........! Y-axis
... !
.......... ... ..........!
.......... ... ..........! 1943
V
The external world scene reference system 'Rs' is a 2-dimensional
reference system on the focal plane of the camera module. The origin is
placed on the top-left corner of the visible scene, the X-axis points
towards the right, and the Y-axis points towards the bottom of the scene.
The top, bottom, left and right directions are intentionally not defined
and depend on the environment in which the camera is used.
A typical example of a (very common) picture of a shark swimming from left
to right, as seen from the camera, is:
0 X-axis
0 +------------------------------------->
!
!
!
! |\____)\___
! ) _____ __`<
! |/ )/
!
!
!
V
Y-axis
with the reference system 'Rs' placed on the camera focal plane:
¸.·˙!
¸.·˙ !
_ ¸.·˙ !
+-/ \-+¸.·˙ !
| (o) | ! Camera focal plane
+-----+˙·.¸ !
˙·.¸ !
˙·.¸ !
˙·.¸!
When projected on the sensor's pixel array, the image and the associated
reference system 'Rs' are typically (but not always) inverted, due to the
camera module's lens optical inversion effect.
Assuming the above represented scene of the swimming shark, the lens
inversion projects the scene and its reference system onto the sensor
pixel array, seen from the front of the camera sensor, as follows:
Y-axis
^
!
!
!
! |\_____)\__
! ) ____ ___.<
! |/ )/
!
!
!
0 +------------------------------------->
0 X-axis
Note the shark being upside-down.
The resulting projected reference system is named 'Rp'.
The camera rotation property is then defined as the angular difference in
the counter-clockwise direction between the camera reference system 'Rc'
and the projected scene reference system 'Rp'. It is expressed in degrees
as a number in the range [0, 360[.
Examples
0 degrees camera rotation:
Y-Rp
^
Y-Rc !
^ !
! !
! !
! !
! !
! !
! !
! !
! 0 +------------------------------------->
! 0 X-Rp
0 +------------------------------------->
0 X-Rc
X-Rc 0
<------------------------------------+ 0
X-Rp 0 !
<------------------------------------+ 0 !
! !
! !
! !
! !
! !
! !
! !
! V
! Y-Rc
V
Y-Rp
90 degrees camera rotation:
0 Y-Rc
0 +-------------------->
! Y-Rp
! ^
! !
! !
! !
! !
! !
! !
! !
! !
! !
! 0 +------------------------------------->
! 0 X-Rp
!
!
!
!
V
X-Rc
180 degrees camera rotation:
0
<------------------------------------+ 0
X-Rc !
Y-Rp !
^ !
! !
! !
! !
! !
! !
! !
! V
! Y-Rc
0 +------------------------------------->
0 X-Rp
270 degrees camera rotation:
0 Y-Rc
0 +-------------------->
! 0
! <-----------------------------------+ 0
! X-Rp !
! !
! !
! !
! !
! !
! !
! !
! !
! V
! Y-Rp
!
!
!
!
V
X-Rc
Example one - Webcam
A camera module installed on the user facing part of a laptop screen
casing used for video calls. The captured images are meant to be displayed
in landscape mode (width > height) on the laptop screen.
The camera is typically mounted upside-down to compensate the lens optical
inversion effect:
Y-Rp
Y-Rc ^
^ !
! !
! ! |\_____)\__
! ! ) ____ ___.<
! ! |/ )/
! !
! !
! !
! 0 +------------------------------------->
! 0 X-Rp
0 +------------------------------------->
0 X-Rc
The two reference systems are aligned, the resulting camera rotation is
0 degrees, no rotation correction needs to be applied to the resulting
image once captured to memory buffers to correctly display it to users:
+--------------------------------------+
! !
! !
! !
! |\____)\___ !
! ) _____ __`< !
! |/ )/ !
! !
! !
! !
+--------------------------------------+
If the camera sensor is not mounted upside-down to compensate for the lens
optical inversion, the two reference systems will not be aligned, with
'Rp' being rotated 180 degrees relatively to 'Rc':
X-Rc 0
<------------------------------------+ 0
!
Y-Rp !
^ !
! !
! |\_____)\__ !
! ) ____ ___.< !
! |/ )/ !
! !
! !
! V
! Y-Rc
0 +------------------------------------->
0 X-Rp
The image once captured to memory will then be rotated by 180 degrees:
+--------------------------------------+
! !
! !
! !
! __/(_____/| !
! >.___ ____ ( !
! \( \| !
! !
! !
! !
+--------------------------------------+
A software rotation correction of 180 degrees should be applied to
correctly display the image:
+--------------------------------------+
! !
! !
! !
! |\____)\___ !
! ) _____ __`< !
! |/ )/ !
! !
! !
! !
+--------------------------------------+
Example two - Phone camera
A camera installed on the back side of a mobile device facing away from
the user. The captured images are meant to be displayed in portrait mode
(height > width) to match the device screen orientation and the device
usage orientation used when taking the picture.
The camera sensor is typically mounted with its pixel array longer side
aligned to the device longer side, upside-down mounted to compensate for
the lens optical inversion effect:
0 Y-Rc
0 +-------------------->
! Y-Rp
! ^
! !
! !
! !
! ! |\_____)\__
! ! ) ____ ___.<
! ! |/ )/
! !
! !
! !
! 0 +------------------------------------->
! 0 X-Rp
!
!
!
!
V
X-Rc
The two reference systems are not aligned and the 'Rp' reference system is
rotated by 90 degrees in the counter-clockwise direction relatively to the
'Rc' reference system.
The image once captured to memory will be rotated:
+-------------------------------------+
| _ _ |
| \ / |
| | | |
| | | |
| | > |
| < | |
| | | |
| . |
| V |
+-------------------------------------+
A correction of 90 degrees in counter-clockwise direction has to be
applied to correctly display the image in portrait mode on the device
screen:
+--------------------+
| |
| |
| |
| |
| |
| |
| |\____)\___ |
| ) _____ __`< |
| |/ )/ |
| |
| |
| |
| |
| |
+--------------------+
orientation:
description:
The orientation of a device (typically an image sensor or a flash LED)
describing its mounting position relative to the usage orientation of the
system where the device is installed on.
$ref: /schemas/types.yaml#/definitions/uint32
enum:
# Front. The device is mounted on the front facing side of the system. For
# mobile devices such as smartphones, tablets and laptops the front side
# is the user facing side.
- 0
# Back. The device is mounted on the back side of the system, which is
# defined as the opposite side of the front facing one.
- 1
# External. The device is not attached directly to the system but is
# attached in a way that allows it to move freely.
- 2
additionalProperties: true
...
Documentation/devicetree/bindings/media/video-interfaces.yaml 0 → 100644
浏览文件 @ de161757
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/video-interfaces.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common bindings for video receiver and transmitter interface endpoints
maintainers:
- Sakari Ailus <sakari.ailus@linux.intel.com>
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description: |
Video data pipelines usually consist of external devices, e.g. camera sensors,
controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
video DMA engines and video data processors.
SoC internal blocks are described by DT nodes, placed similarly to other SoC
blocks. External devices are represented as child nodes of their respective
bus controller nodes, e.g. I2C.
Data interfaces on all video devices are described by their child 'port' nodes.
Configuration of a port depends on other devices participating in the data
transfer and is described by 'endpoint' subnodes.
device {
...
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
...
endpoint@0 { ... };
endpoint@1 { ... };
};
port@1 { ... };
};
};
If a port can be configured to work with more than one remote device on the same
bus, an 'endpoint' child node must be provided for each of them. If more than
one port is present in a device node or there is more than one endpoint at a
port, or port node needs to be associated with a selected hardware interface,
a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
used.
All 'port' nodes can be grouped under optional 'ports' node, which allows to
specify #address-cells, #size-cells properties independently for the 'port'
and 'endpoint' nodes and any child device nodes a device might have.
Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
phandles. An endpoint subnode of a device contains all properties needed for
configuration of this device for data exchange with other device. In most
cases properties at the peer 'endpoint' nodes will be identical, however they
might need to be different when there is any signal modifications on the bus
between two devices, e.g. there are logic signal inverters on the lines.
It is allowed for multiple endpoints at a port to be active simultaneously,
where supported by a device. For example, in case where a data interface of
a device is partitioned into multiple data busses, e.g. 16-bit input port
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.
allOf:
- $ref: /schemas/graph.yaml#/$defs/endpoint-base
properties:
slave-mode:
type: boolean
description:
Indicates that the link is run in slave mode. The default when this
property is not specified is master mode. In the slave mode horizontal and
vertical synchronization signals are provided to the slave device (data
source) by the master device (data sink). In the master mode the data
source device is also the source of the synchronization signals.
bus-type:
$ref: /schemas/types.yaml#/definitions/uint32
enum:
- 1 # MIPI CSI-2 C-PHY
- 2 # MIPI CSI1
- 3 # CCP2
- 4 # MIPI CSI-2 D-PHY
- 5 # Parallel
- 6 # BT.656
description:
Data bus type.
bus-width:
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 64
description:
Number of data lines actively used, valid for the parallel busses.
data-shift:
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 64
description:
On the parallel data busses, if bus-width is used to specify the number of
data lines, data-shift can be used to specify which data lines are used,
e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used.
hsync-active:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
description:
Active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
vsync-active:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
description:
Active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. Note,
that if HSYNC and VSYNC polarities are not specified, embedded
synchronization may be required, where supported.
data-active:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
description:
Similar to HSYNC and VSYNC, specifies data line polarity.
data-enable-active:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
description:
Similar to HSYNC and VSYNC, specifies the data enable signal polarity.
field-even-active:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
description:
Field signal level during the even field data transmission.
pclk-sample:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
description:
Sample data on rising (1) or falling (0) edge of the pixel clock signal.
sync-on-green-active:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
description:
Active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively.
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
items:
# Assume up to 9 physical lane indices
maximum: 8
description:
An array of physical data lane indexes. Position of an entry 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. 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:
$ref: /schemas/types.yaml#/definitions/uint32
# Assume up to 9 physical lane indices
maximum: 8
description:
Physical clock lane index. 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>;", which places the
clock lane on hardware lane 0. This property is valid for serial busses
only (e.g. MIPI CSI-2).
clock-noncontinuous:
type: boolean
description:
Allow MIPI CSI-2 non-continuous clock mode.
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description:
Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the
actual frequency of the bus, not bits per clock per lane value. An array
of 64-bit unsigned integers.
lane-polarities:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 9
items:
enum: [ 0, 1 ]
description:
An array of polarities of the lanes starting from the clock lane and
followed by the data lanes in the same order as in data-lanes. Valid
values are 0 (normal) and 1 (inverted). The length of the array should be
the combined length of data-lanes and clock-lanes properties. If the
lane-polarities property is omitted, the value must be interpreted as 0
(normal). This property is valid for serial busses only.
strobe:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
description:
Whether the clock signal is used as clock (0) or strobe (1). Used with
CCP2, for instance.
additionalProperties: true
examples:
# The example snippet below describes two data pipelines. ov772x and imx074
# are camera sensors with a parallel and serial (MIPI CSI-2) video bus
# respectively. Both sensors are on the I2C control bus corresponding to the
# i2c0 controller node. ov772x sensor is linked directly to the ceu0 video
# host interface. imx074 is linked to ceu0 through the MIPI CSI-2 receiver
# (csi2). ceu0 has a (single) DMA engine writing captured data to memory.
# ceu0 node has a single 'port' node which may indicate that at any time
# only one of the following data pipelines can be active:
# ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
- |
ceu@fe910000 {
compatible = "renesas,sh-mobile-ceu";
reg = <0xfe910000 0xa0>;
interrupts = <0x880>;
mclk: master_clock {
compatible = "renesas,ceu-clock";
#clock-cells = <1>;
clock-frequency = <50000000>; /* Max clock frequency */
clock-output-names = "mclk";
};
port {
#address-cells = <1>;
#size-cells = <0>;
/* Parallel bus endpoint */
ceu0_1: endpoint@1 {
reg = <1>; /* Local endpoint # */
remote-endpoint = <&ov772x_1_1>; /* Remote phandle */
bus-width = <8>; /* Used data lines */
data-shift = <2>; /* Lines 9:2 are used */
/* If hsync-active/vsync-active are missing,
embedded BT.656 sync is used */
hsync-active = <0>; /* Active low */
vsync-active = <0>; /* Active low */
data-active = <1>; /* Active high */
pclk-sample = <1>; /* Rising */
};
/* MIPI CSI-2 bus endpoint */
ceu0_0: endpoint@0 {
reg = <0>;
remote-endpoint = <&csi2_2>;
};
};
};
i2c {
#address-cells = <1>;
#size-cells = <0>;
camera@21 {
compatible = "ovti,ov772x";
reg = <0x21>;
vddio-supply = <&regulator1>;
vddcore-supply = <&regulator2>;
clock-frequency = <20000000>;
clocks = <&mclk 0>;
clock-names = "xclk";
port {
/* With 1 endpoint per port no need for addresses. */
ov772x_1_1: endpoint {
bus-width = <8>;
remote-endpoint = <&ceu0_1>;
hsync-active = <1>;
vsync-active = <0>; /* Who came up with an
inverter here ?... */
data-active = <1>;
pclk-sample = <1>;
};
};
};
camera@1a {
compatible = "sony,imx074";
reg = <0x1a>;
vddio-supply = <&regulator1>;
vddcore-supply = <&regulator2>;
clock-frequency = <30000000>; /* Shared clock with ov772x_1 */
clocks = <&mclk 0>;
clock-names = "sysclk"; /* Assuming this is the
name in the datasheet */
port {
imx074_1: endpoint {
clock-lanes = <0>;
data-lanes = <1 2>;
remote-endpoint = <&csi2_1>;
};
};
};
};
csi2: csi2@ffc90000 {
compatible = "renesas,sh-mobile-csi2";
reg = <0xffc90000 0x1000>;
interrupts = <0x17a0>;
#address-cells = <1>;
#size-cells = <0>;
port@1 {
compatible = "renesas,csi2c"; /* One of CSI2I and CSI2C. */
reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S,
PHY_M has port address 0,
is unused. */
csi2_1: endpoint {
clock-lanes = <0>;
data-lanes = <2 1>;
remote-endpoint = <&imx074_1>;
};
};
port@2 {
reg = <2>; /* port 2: link to the CEU */
csi2_2: endpoint {
remote-endpoint = <&ceu0_0>;
};
};
};
...
Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
浏览文件 @ de161757
......@@ -97,24 +97,21 @@ properties:
maxItems: 1
ports:
type: object
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
type: object
$ref: /schemas/graph.yaml#/$defs/port-base
description: |
Input / sink port node, single endpoint describing the
CSI-2 transmitter.
properties:
reg:
const: 0
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-lanes:
description: |
This is required only in the sink port 0 endpoint which
......@@ -130,41 +127,17 @@ properties:
- const: 3
- const: 4
remote-endpoint: true
required:
- data-lanes
- remote-endpoint
additionalProperties: false
additionalProperties: false
unevaluatedProperties: false
port@1:
type: object
$ref: /schemas/graph.yaml#/properties/port
description: |
Output / source port node, endpoint describing modules
connected the CSI-2 receiver.
properties:
reg:
const: 1
endpoint:
type: object
properties:
remote-endpoint: true
required:
- remote-endpoint
additionalProperties: false
additionalProperties: false
required:
- compatible
- reg
......
Documentation/driver-api/media/camera-sensor.rst
浏览文件 @ de161757
......@@ -15,7 +15,7 @@ Camera sensors have an internal clock tree including a PLL and a number of
divisors. The clock tree is generally configured by the driver based on a few
input parameters that are specific to the hardware:: the external clock frequency
and the link frequency. The two parameters generally are obtained from system
firmware. No other frequencies should be used in any circumstances.
firmware. **No other frequencies should be used in any circumstances.**
The reason why the clock frequencies are so important is that the clock signals
come out of the SoC, and in many cases a specific frequency is designed to be
......@@ -23,6 +23,24 @@ used in the system. Using another frequency may cause harmful effects
elsewhere. Therefore only the pre-determined frequencies are configurable by the
user.
ACPI
~~~~
Read the "clock-frequency" _DSD property to denote the frequency. The driver can
rely on this frequency being used.
Devicetree
~~~~~~~~~~
The currently preferred way to achieve this is using "assigned-clock-rates"
property. See Documentation/devicetree/bindings/clock/clock-bindings.txt for
more information. The driver then gets the frequency using clk_get_rate().
This approach has the drawback that there's no guarantee that the frequency
hasn't been modified directly or indirectly by another driver, or supported by
the board's clock tree to begin with. Changes to the Common Clock Framework API
are required to ensure reliability.
Frame size
----------
......
Documentation/driver-api/media/cec-core.rst
浏览文件 @ de161757
......@@ -26,7 +26,7 @@ It is documented in the HDMI 1.4 specification with the new 2.0 bits documented
in the HDMI 2.0 specification. But for most of the features the freely available
HDMI 1.3a specification is sufficient:
http://www.microprocessor.org/HDMISpecification13a.pdf
https://www.hdmi.org/spec/index
CEC Adapter Interface
......
Documentation/driver-api/media/csi2.rst
浏览文件 @ de161757
......@@ -35,7 +35,7 @@ ability to start and stop the stream.
The value of the V4L2_CID_PIXEL_RATE is calculated as follows::
pixel_rate = link_freq * 2 * nr_of_lanes / bits_per_sample
pixel_rate = link_freq * 2 * nr_of_lanes * 16 / k / bits_per_sample
where
......@@ -53,6 +53,8 @@ where
- Two bits are transferred per clock cycle per lane.
* - bits_per_sample
- Number of bits per sample.
* - k
- 16 for D-PHY and 7 for C-PHY
The transmitter drivers must, if possible, configure the CSI-2
transmitter to *LP-11 mode* whenever the transmitter is powered on but
......
Documentation/driver-api/media/drivers/ccs/ccs.rst
浏览文件 @ de161757
......@@ -79,4 +79,17 @@ definitions:
-l drivers/media/i2c/ccs/ccs-limits.c \
-c Documentation/driver-api/media/drivers/ccs/ccs-regs.asc
CCS PLL calculator
==================
The CCS PLL calculator is used to compute the PLL configuration, given sensor's
capabilities as well as board configuration and user specified configuration. As
the configuration space that encompasses all these configurations is vast, the
PLL calculator isn't entirely trivial. Yet it is relatively simple to use for a
driver.
The PLL model implemented by the PLL calculator corresponds to MIPI CCS 1.1.
.. kernel-doc:: drivers/media/i2c/ccs-pll.h
**Copyright** |copy| 2020 Intel Corporation
Documentation/driver-api/media/v4l2-clocks.rst 已删除 100644 → 0
浏览文件 @ 66f73fb3
.. SPDX-License-Identifier: GPL-2.0
V4L2 clocks
-----------
.. attention::
This is a temporary API and it shall be replaced by the generic
clock API, when the latter becomes widely available.
Many subdevices, like camera sensors, TV decoders and encoders, need a clock
signal to be supplied by the system. Often this clock is supplied by the
respective bridge device. The Linux kernel provides a Common Clock Framework for
this purpose. However, it is not (yet) available on all architectures. Besides,
the nature of the multi-functional (clock, data + synchronisation, I2C control)
connection of subdevices to the system might impose special requirements on the
clock API usage. E.g. V4L2 has to support clock provider driver unregistration
while a subdevice driver is holding a reference to the clock. For these reasons
a V4L2 clock helper API has been developed and is provided to bridge and
subdevice drivers.
The API consists of two parts: two functions to register and unregister a V4L2
clock source: v4l2_clk_register() and v4l2_clk_unregister() and calls to control
a clock object, similar to the respective generic clock API calls:
v4l2_clk_get(), v4l2_clk_put(), v4l2_clk_enable(), v4l2_clk_disable(),
v4l2_clk_get_rate(), and v4l2_clk_set_rate(). Clock suppliers have to provide
clock operations that will be called when clock users invoke respective API
methods.
It is expected that once the CCF becomes available on all relevant
architectures this API will be removed.
Documentation/driver-api/media/v4l2-core.rst
浏览文件 @ de161757
......@@ -15,7 +15,6 @@ Video4Linux devices
v4l2-controls
v4l2-videobuf
v4l2-videobuf2
v4l2-clocks
v4l2-dv-timings
v4l2-flash-led-class
v4l2-mc
......
Documentation/driver-api/media/v4l2-subdev.rst
浏览文件 @ de161757
......@@ -122,15 +122,12 @@ Don't forget to cleanup the media entity before the sub-device is destroyed:
media_entity_cleanup(&sd->entity);
If the subdev driver intends to process video and integrate with the media
framework, it must implement format related functionality using
:c:type:`v4l2_subdev_pad_ops` instead of :c:type:`v4l2_subdev_video_ops`.
In that case, the subdev driver may set the link_validate field to provide
its own link validation function. The link validation function is called for
every link in the pipeline where both of the ends of the links are V4L2
sub-devices. The driver is still responsible for validating the correctness
of the format configuration between sub-devices and video nodes.
If a sub-device driver implements sink pads, the subdev driver may set the
link_validate field in :c:type:`v4l2_subdev_pad_ops` to provide its own link
validation function. For every link in the pipeline, the link_validate pad
operation of the sink end of the link is called. In both cases the driver is
still responsible for validating the correctness of the format configuration
between sub-devices and video nodes.
If link_validate op is not set, the default function
:c:func:`v4l2_subdev_link_validate_default` is used instead. This function
......@@ -200,15 +197,45 @@ unregister the notifier the driver has to call
takes two arguments: a pointer to struct :c:type:`v4l2_device` and a
pointer to struct :c:type:`v4l2_async_notifier`.
Before registering the notifier, bridge drivers must do two things:
first, the notifier must be initialized using the
:c:func:`v4l2_async_notifier_init`. Second, bridge drivers can then
begin to form a list of subdevice descriptors that the bridge device
needs for its operation. Subdevice descriptors are added to the notifier
using the :c:func:`v4l2_async_notifier_add_subdev` call. This function
takes two arguments: a pointer to struct :c:type:`v4l2_async_notifier`,
and a pointer to the subdevice descripter, which is of type struct
:c:type:`v4l2_async_subdev`.
Before registering the notifier, bridge drivers must do two things: first, the
notifier must be initialized using the :c:func:`v4l2_async_notifier_init`.
Second, bridge drivers can then begin to form a list of subdevice descriptors
that the bridge device needs for its operation. Several functions are available
to add subdevice descriptors to a notifier, depending on the type of device and
the needs of the driver.
:c:func:`v4l2_async_notifier_add_fwnode_remote_subdev` and
:c:func:`v4l2_async_notifier_add_i2c_subdev` are for bridge and ISP drivers for
registering their async sub-devices with the notifier.
:c:func:`v4l2_async_register_subdev_sensor_common` is a helper function for
sensor drivers registering their own async sub-device, but it also registers a
notifier and further registers async sub-devices for lens and flash devices
found in firmware. The notifier for the sub-device is unregistered with the
async sub-device.
These functions allocate an async sub-device descriptor which is of type struct
:c:type:`v4l2_async_subdev` embedded in a driver-specific struct. The &struct
:c:type:`v4l2_async_subdev` shall be the first member of this struct:
.. code-block:: c
struct my_async_subdev {
struct v4l2_async_subdev asd;
...
};
struct my_async_subdev *my_asd;
struct fwnode_handle *ep;
...
my_asd = v4l2_async_notifier_add_fwnode_remote_subdev(&notifier, ep,
struct my_async_subdev);
fwnode_handle_put(ep);
if (IS_ERR(asd))
return PTR_ERR(asd);
The V4L2 core will then use these descriptors to match asynchronously
registered subdevices to them. If a match is detected the ``.bound()``
......
Documentation/userspace-api/media/drivers/ccs.rst 0 → 100644
浏览文件 @ de161757
.. SPDX-License-Identifier: GPL-2.0-only
.. include:: <isonum.txt>
MIPI CCS camera sensor driver
=============================
The MIPI CCS camera sensor driver is a generic driver for `MIPI CCS
<https://www.mipi.org/specifications/camera-command-set>`_ compliant
camera sensors. It exposes three sub-devices representing the pixel array,
the binner and the scaler.
As the capabilities of individual devices vary, the driver exposes
interfaces based on the capabilities that exist in hardware.
Pixel Array sub-device
----------------------
The pixel array sub-device represents the camera sensor's pixel matrix, as well
as analogue crop functionality present in many compliant devices. The analogue
crop is configured using the ``V4L2_SEL_TGT_CROP`` on the source pad (0) of the
entity. The size of the pixel matrix can be obtained by getting the
``V4L2_SEL_TGT_NATIVE_SIZE`` target.
Binner
------
The binner sub-device represents the binning functionality on the sensor. For
that purpose, selection target ``V4L2_SEL_TGT_COMPOSE`` is supported on the
sink pad (0).
Additionally, if a device has no scaler or digital crop functionality, the
source pad (1) expses another digital crop selection rectangle that can only
crop at the end of the lines and frames.
Scaler
------
The scaler sub-device represents the digital crop and scaling functionality of
the sensor. The V4L2 selection target ``V4L2_SEL_TGT_CROP`` is used to
configure the digital crop on the sink pad (0) when digital crop is supported.
Scaling is configured using selection target ``V4L2_SEL_TGT_COMPOSE`` on the
sink pad (0) as well.
Additionally, if the scaler sub-device exists, its source pad (1) exposes
another digital crop selection rectangle that can only crop at the end of the
lines and frames.
Digital and analogue crop
-------------------------
Digital crop functionality is referred to as cropping that effectively works by
dropping some data on the floor. Analogue crop, on the other hand, means that
the cropped information is never retrieved. In case of camera sensors, the
analogue data is never read from the pixel matrix that are outside the
configured selection rectangle that designates crop. The difference has an
effect in device timing and likely also in power consumption.
Private controls
----------------
The MIPI CCS driver implements a number of private controls under
``V4L2_CID_USER_BASE_CCS`` to control the MIPI CCS compliant camera sensors.
Analogue gain model
~~~~~~~~~~~~~~~~~~~
The CCS defines an analogue gain model where the gain can be calculated using
the following formula:
gain = m0 * x + c0 / (m1 * x + c1)
Either m0 or c0 will be zero. The constants that are device specific, can be
obtained from the following controls:
V4L2_CID_CCS_ANALOGUE_GAIN_M0
V4L2_CID_CCS_ANALOGUE_GAIN_M1
V4L2_CID_CCS_ANALOGUE_GAIN_C0
V4L2_CID_CCS_ANALOGUE_GAIN_C1
The analogue gain (``x`` in the formula) is controlled through
``V4L2_CID_ANALOGUE_GAIN`` in this case.
Alternate analogue gain model
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The CCS defines another analogue gain model called alternate analogue gain. In
this case, the formula to calculate actual gain consists of linear and
exponential parts:
gain = linear * 2 ^ exponent
The ``linear`` and ``exponent`` factors can be set using the
``V4L2_CID_CCS_ANALOGUE_LINEAR_GAIN`` and
``V4L2_CID_CCS_ANALOGUE_EXPONENTIAL_GAIN`` controls, respectively
Shading correction
~~~~~~~~~~~~~~~~~~
The CCS standard supports lens shading correction. The feature can be controlled
using ``V4L2_CID_CCS_SHADING_CORRECTION``. Additionally, the luminance
correction level may be changed using
``V4L2_CID_CCS_LUMINANCE_CORRECTION_LEVEL``, where value 0 indicates no
correction and 128 indicates correcting the luminance in corners to 10 % less
than in the centre.
Shading correction needs to be enabled for luminance correction level to have an
effect.
**Copyright** |copy| 2020 Intel Corporation
Documentation/userspace-api/media/drivers/index.rst
浏览文件 @ de161757
......@@ -31,6 +31,7 @@ For more details see the file COPYING in the source distribution of Linux.
:maxdepth: 5
:numbered:
ccs
cx2341x-uapi
imx-uapi
max2175
......
Documentation/userspace-api/media/dvb/dvbstb.svg
浏览文件 @ de161757
......@@ -2,7 +2,7 @@
<!-- SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later -->
<svg id="svg2" width="15.847cm" height="8.4187cm" fill-rule="evenodd" stroke-linejoin="round" stroke-width="28.222" preserveAspectRatio="xMidYMid" version="1.2" viewBox="0 0 23770.123 12628.122" xml:space="preserve" xmlns="http://www.w3.org/2000/svg" xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><defs id="defs142"><marker id="Arrow1Lend" overflow="visible" orient="auto"><path id="path954" transform="matrix(-.8 0 0 -.8 -10 0)" d="m0 0 5-5-17.5 5 17.5 5z" fill-rule="evenodd" stroke="#000" stroke-width="1pt"/></marker><marker id="marker1243" overflow="visible" orient="auto"><path id="path1241" transform="matrix(-.8 0 0 -.8 -10 0)" d="m0 0 5-5-17.5 5 17.5 5z" fill-rule="evenodd" stroke="#000" stroke-width="1pt"/></marker></defs><metadata id="metadata519"><rdf:RDF><cc:Work
rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/><dc:title/></cc:Work></rdf:RDF></metadata><rect id="rect197" class="BoundingBox" x="5355.1" y="13.122" width="18403" height="9603" fill="none"/><path id="path199" d="m14556 9614.1h-9200v-9600h18400v9600z" fill="#fff"/><path id="path201" d="m14556 9614.1h-9200v-9600h18400v9600z" fill="none" stroke="#000"/><rect id="rect206" class="BoundingBox" x="13.122" y="4013.1" width="4544" height="2403" fill="none"/><path id="path208" d="m2285.1 6414.1h-2271v-2400h4541v2400z" fill="#fff"/><path id="path210" d="m2285.1 6414.1h-2271v-2400h4541v2400z" fill="none" stroke="#000"/><text id="text212" class="TextShape" x="-2443.8779" y="-4585.8779"><tspan id="tspan214" class="TextParagraph" font-family="sans-serif" font-size="635px" font-weight="400"><tspan id="tspan216" class="TextPosition"
x="1281.1219" y="5435.1221"><tspan id="tspan218" fill="#000000">Antena</tspan></tspan></tspan></text>
x="1013.1317" y="5435.1221"><tspan id="tspan218" fill="#000000">Antenna</tspan></tspan></tspan></text>
<rect id="rect223" class="BoundingBox" x="6213.1" y="1813.1" width="4544" height="2403" fill="none"/><path id="path225" d="m8485.1 4214.1h-2271v-2400h4541v2400z" fill="#fff"/><path id="path227" d="m8485.1 4214.1h-2271v-2400h4541v2400z" fill="none" stroke="#000"/><text id="text229" class="TextShape" x="-2443.8779" y="-4585.8779"><tspan id="tspan231" class="TextParagraph" font-family="sans-serif" font-size="635px" font-weight="400"><tspan id="tspan233" class="TextPosition" x="7217.1221" y="3235.1221"><tspan id="tspan235" fill="#000000">Frontend</tspan></tspan></tspan></text>
<rect id="rect240" class="BoundingBox" x="12113" y="1813.1" width="4544" height="2403" fill="none"/><path id="path242" d="m14385 4214.1h-2271v-2400h4541v2400z" fill="#fff"/><path id="path244" d="m14385 4214.1h-2271v-2400h4541v2400z" fill="none" stroke="#000"/><text id="text246" class="TextShape" x="-2443.8779" y="-4585.8779"><tspan id="tspan248" class="TextParagraph" font-family="sans-serif" font-size="635px" font-weight="400"><tspan id="tspan250" class="TextPosition" x="13944.122" y="3235.1221"><tspan id="tspan252" fill="#000000">CA</tspan></tspan></tspan></text>
<rect id="rect257" class="BoundingBox" x="18113" y="1813.1" width="4544" height="2403" fill="none"/><path id="path259" d="m20385 4214.1h-2271v-2400h4541v2400z" fill="#fff"/><path id="path261" d="m20385 4214.1h-2271v-2400h4541v2400z" fill="none" stroke="#000"/><text id="text263" class="TextShape" x="-2443.8779" y="-4585.8779"><tspan id="tspan265" class="TextParagraph" font-family="sans-serif" font-size="635px" font-weight="400"><tspan id="tspan267" class="TextPosition" x="19384.123" y="3235.1221"><tspan id="tspan269" fill="#000000">Demux</tspan></tspan></tspan></text>
......
Documentation/userspace-api/media/mediactl/media-types.rst
浏览文件 @ de161757
......@@ -39,6 +39,7 @@ Types and flags used to represent the media graph elements
.. _MEDIA-ENT-F-PROC-VIDEO-STATISTICS:
.. _MEDIA-ENT-F-PROC-VIDEO-ENCODER:
.. _MEDIA-ENT-F-PROC-VIDEO-DECODER:
.. _MEDIA-ENT-F-PROC-VIDEO-ISP:
.. _MEDIA-ENT-F-VID-MUX:
.. _MEDIA-ENT-F-VID-IF-BRIDGE:
.. _MEDIA-ENT-F-DV-DECODER:
......@@ -201,6 +202,12 @@ Types and flags used to represent the media graph elements
decompressing a compressed video stream into uncompressed video
frames. Must have one sink pad and at least one source pad.
* - ``MEDIA_ENT_F_PROC_VIDEO_ISP``
- An Image Signal Processor (ISP) device. ISPs generally are one of a
kind devices that have their specific control interfaces using a
combination of custom V4L2 controls and IOCTLs, and parameters
supplied in a metadata buffer.
* - ``MEDIA_ENT_F_VID_MUX``
- Video multiplexer. An entity capable of multiplexing must have at
least two sink pads and one source pad, and must pass the video
......
Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
浏览文件 @ de161757
......@@ -1182,6 +1182,18 @@ enum v4l2_mpeg_video_h264_entropy_mode -
V4L2_CID_MPEG_VIDEO_H264_MAX_QP is also set, the quantization parameter
should be chosen to meet both requirements.
``V4L2_CID_MPEG_VIDEO_H264_B_FRAME_MIN_QP (integer)``
Minimum quantization parameter for the H264 B frame to limit B frame
quality to a range. Valid range: from 0 to 51. If
V4L2_CID_MPEG_VIDEO_H264_MIN_QP is also set, the quantization parameter
should be chosen to meet both requirements.
``V4L2_CID_MPEG_VIDEO_H264_B_FRAME_MAX_QP (integer)``
Maximum quantization parameter for the H264 B frame to limit B frame
quality to a range. Valid range: from 0 to 51. If
V4L2_CID_MPEG_VIDEO_H264_MAX_QP is also set, the quantization parameter
should be chosen to meet both requirements.
``V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP (integer)``
Quantization parameter for an I frame for MPEG4. Valid range: from 1
to 31.
......@@ -1501,6 +1513,26 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
* - Bit 16:32
- Layer number
``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L0_BR (integer)``
Indicates bit rate (bps) for hierarchical coding layer 0 for H264 encoder.
``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L1_BR (integer)``
Indicates bit rate (bps) for hierarchical coding layer 1 for H264 encoder.
``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L2_BR (integer)``
Indicates bit rate (bps) for hierarchical coding layer 2 for H264 encoder.
``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L3_BR (integer)``
Indicates bit rate (bps) for hierarchical coding layer 3 for H264 encoder.
``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L4_BR (integer)``
Indicates bit rate (bps) for hierarchical coding layer 4 for H264 encoder.
``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L5_BR (integer)``
Indicates bit rate (bps) for hierarchical coding layer 5 for H264 encoder.
``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L6_BR (integer)``
Indicates bit rate (bps) for hierarchical coding layer 6 for H264 encoder.
.. _v4l2-mpeg-mpeg2:
......@@ -2628,11 +2660,11 @@ HEVC/H.265 Control IDs
``V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (integer)``
Minimum quantization parameter for HEVC.
Valid range: from 0 to 51.
Valid range: from 0 to 51 for 8 bit and from 0 to 63 for 10 bit.
``V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP (integer)``
Maximum quantization parameter for HEVC.
Valid range: from 0 to 51.
Valid range: from 0 to 51 for 8 bit and from 0 to 63 for 10 bit.
``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP (integer)``
Quantization parameter for an I frame for HEVC.
......@@ -2649,6 +2681,42 @@ HEVC/H.265 Control IDs
Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP,
V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP].
``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_MIN_QP (integer)``
Minimum quantization parameter for the HEVC I frame to limit I frame
quality to a range. Valid range: from 0 to 51 for 8 bit and from 0 to 63 for 10 bit.
If V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP is also set, the quantization parameter
should be chosen to meet both requirements.
``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_MAX_QP (integer)``
Maximum quantization parameter for the HEVC I frame to limit I frame
quality to a range. Valid range: from 0 to 51 for 8 bit and from 0 to 63 for 10 bit.
If V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP is also set, the quantization parameter
should be chosen to meet both requirements.
``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_MIN_QP (integer)``
Minimum quantization parameter for the HEVC P frame to limit P frame
quality to a range. Valid range: from 0 to 51 for 8 bit and from 0 to 63 for 10 bit.
If V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP is also set, the quantization parameter
should be chosen to meet both requirements.
``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_MAX_QP (integer)``
Maximum quantization parameter for the HEVC P frame to limit P frame
quality to a range. Valid range: from 0 to 51 for 8 bit and from 0 to 63 for 10 bit.
If V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP is also set, the quantization parameter
should be chosen to meet both requirements.
``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_MIN_QP (integer)``
Minimum quantization parameter for the HEVC B frame to limit B frame
quality to a range. Valid range: from 0 to 51 for 8 bit and from 0 to 63 for 10 bit.
If V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP is also set, the quantization parameter
should be chosen to meet both requirements.
``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_MAX_QP (integer)``
Maximum quantization parameter for the HEVC B frame to limit B frame
quality to a range. Valid range: from 0 to 51 for 8 bit and from 0 to 63 for 10 bit.
If V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP is also set, the quantization parameter
should be chosen to meet both requirements.
``V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP (boolean)``
HIERARCHICAL_QP allows the host to specify the quantization parameter
values for each temporal layer through HIERARCHICAL_QP_LAYER. This is
......@@ -3569,3 +3637,12 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
- Selecting this value specifies that HEVC slices are expected
to be prefixed by Annex B start codes. According to :ref:`hevc`
valid start codes can be 3-bytes 0x000001 or 4-bytes 0x00000001.
``V4L2_CID_MPEG_VIDEO_BASELAYER_PRIORITY_ID (integer)``
Specifies a priority identifier for the NAL unit, which will be applied to
the base layer. By default this value is set to 0 for the base layer,
and the next layer will have the priority ID assigned as 1, 2, 3 and so on.
The video encoder can't decide the priority id to be applied to a layer,
so this has to come from client.
This is applicable to H264 and valid Range is from 0 to 63.
Source Rec. ITU-T H.264 (06/2019); G.7.4.1.1, G.8.8.1.
Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
浏览文件 @ de161757
......@@ -396,9 +396,9 @@ number of lines as the luma plane.
NV24 and NV42
-------------
Semi-planar YUV 4:4:4 formats. The chroma plane is subsampled by 2 in the
horizontal direction. Chroma lines contain half the number of pixels and the
same number of bytes as luma lines, and the chroma plane contains the same
Semi-planar YUV 4:4:4 formats. The chroma plane is not subsampled.
Chroma lines contain the same number of pixels and twice the
number of bytes as luma lines, and the chroma plane contains the same
number of lines as the luma plane.
.. flat-table:: Sample 4x4 NV24 Image
......
MAINTAINERS
浏览文件 @ de161757
......@@ -699,7 +699,8 @@ M: Michael Tretter <m.tretter@pengutronix.de>
R: Pengutronix Kernel Team <kernel@pengutronix.de>
L: linux-media@vger.kernel.org
S: Maintained
F: drivers/staging/media/allegro-dvt/
F: Documentation/devicetree/bindings/media/allegro,al5e.yaml
F: drivers/media/platform/allegro-dvt/
ALLWINNER A10 CSI DRIVER
M: Maxime Ripard <mripard@kernel.org>
......@@ -8979,9 +8980,11 @@ INTEL IPU3 CSI-2 CIO2 DRIVER
M: Yong Zhi <yong.zhi@intel.com>
M: Sakari Ailus <sakari.ailus@linux.intel.com>
M: Bingbu Cao <bingbu.cao@intel.com>
M: Dan Scally <djrscally@gmail.com>
R: Tianshu Qiu <tian.shu.qiu@intel.com>
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/userspace-api/media/v4l/pixfmt-srggb10-ipu3.rst
F: drivers/media/pci/intel/ipu3/
......@@ -11528,7 +11531,7 @@ L: linux-amlogic@lists.infradead.org
S: Supported
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml
F: drivers/media/meson/ge2d/
F: drivers/media/platform/meson/ge2d/
MESON NAND CONTROLLER DRIVER FOR AMLOGIC SOCS
M: Liang Yang <liang.yang@amlogic.com>
......@@ -11811,9 +11814,11 @@ L: linux-media@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
F: Documentation/driver-api/media/drivers/ccs/
F: Documentation/userspace-api/media/drivers/ccs.rst
F: drivers/media/i2c/ccs-pll.c
F: drivers/media/i2c/ccs-pll.h
F: drivers/media/i2c/ccs/
F: include/uapi/linux/ccs.h
F: include/uapi/linux/smiapp.h
MIPS
......@@ -13095,7 +13100,7 @@ M: Jacopo Mondi <jacopo@jmondi.org>
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/ov5647.yaml
F: Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml
F: drivers/media/i2c/ov5647.c
OMNIVISION OV5670 SENSOR DRIVER
......@@ -14941,6 +14946,18 @@ F: drivers/media/i2c/max9271.c
F: drivers/media/i2c/max9271.h
F: drivers/media/i2c/rdacm20.c
RDACM21 Camera Sensor
M: Jacopo Mondi <jacopo+renesas@jmondi.org>
M: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
M: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
M: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
L: linux-media@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/media/i2c/rdacm2x-gmsl.yaml
F: drivers/media/i2c/max9271.c
F: drivers/media/i2c/max9271.h
F: drivers/media/i2c/rdacm21.c
RDC R-321X SoC
M: Florian Fainelli <florian@openwrt.org>
S: Maintained
......@@ -16517,6 +16534,7 @@ M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/imx258.yaml
F: drivers/media/i2c/imx258.c
SONY IMX274 SENSOR DRIVER
......@@ -16542,6 +16560,15 @@ S: Maintained
T: git git://linuxtv.org/media_tree.git
F: drivers/media/i2c/imx319.c
SONY IMX334 SENSOR DRIVER
M: Paul J. Murphy <paul.j.murphy@intel.com>
M: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml
F: drivers/media/i2c/imx334.c
SONY IMX355 SENSOR DRIVER
M: Tianshu Qiu <tian.shu.qiu@intel.com>
L: linux-media@vger.kernel.org
......
arch/arm/mach-pxa/devices.c
浏览文件 @ de161757
......@@ -4,6 +4,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/clkdev.h>
#include <linux/clk-provider.h>
#include <linux/dma-mapping.h>
#include <linux/dmaengine.h>
#include <linux/spi/pxa2xx_spi.h>
......@@ -634,6 +635,13 @@ static struct platform_device pxa27x_device_camera = {
void __init pxa_set_camera_info(struct pxacamera_platform_data *info)
{
struct clk *mclk;
/* Register a fixed-rate clock for camera sensors. */
mclk = clk_register_fixed_rate(NULL, "pxa_camera_clk", NULL, 0,
info->mclk_10khz * 10000);
if (!IS_ERR(mclk))
clkdev_create(mclk, "mclk", NULL);
pxa_register_device(&pxa27x_device_camera, info);
}
......
drivers/acpi/utils.c
浏览文件 @ de161757
......@@ -823,12 +823,13 @@ bool acpi_dev_present(const char *hid, const char *uid, s64 hrv)
EXPORT_SYMBOL(acpi_dev_present);
/**
* acpi_dev_get_first_match_dev - Return the first match of ACPI device
* acpi_dev_get_next_match_dev - Return the next match of ACPI device
* @adev: Pointer to the previous acpi_device matching this @hid, @uid and @hrv
* @hid: Hardware ID of the device.
* @uid: Unique ID of the device, pass NULL to not check _UID
* @hrv: Hardware Revision of the device, pass -1 to not check _HRV
*
* Return the first match of ACPI device if a matching device was present
* Return the next match of ACPI device if another matching device was present
* at the moment of invocation, or NULL otherwise.
*
* The caller is responsible to call put_device() on the returned device.
......@@ -836,8 +837,9 @@ EXPORT_SYMBOL(acpi_dev_present);
* See additional information in acpi_dev_present() as well.
*/
struct acpi_device *
acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv)
acpi_dev_get_next_match_dev(struct acpi_device *adev, const char *hid, const char *uid, s64 hrv)
{
struct device *start = adev ? &adev->dev : NULL;
struct acpi_dev_match_info match = {};
struct device *dev;
......@@ -845,9 +847,29 @@ acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv)
match.uid = uid;
match.hrv = hrv;
dev = bus_find_device(&acpi_bus_type, NULL, &match, acpi_dev_match_cb);
dev = bus_find_device(&acpi_bus_type, start, &match, acpi_dev_match_cb);
return dev ? to_acpi_device(dev) : NULL;
}
EXPORT_SYMBOL(acpi_dev_get_next_match_dev);
/**
* acpi_dev_get_first_match_dev - Return the first match of ACPI device
* @hid: Hardware ID of the device.
* @uid: Unique ID of the device, pass NULL to not check _UID
* @hrv: Hardware Revision of the device, pass -1 to not check _HRV
*
* Return the first match of ACPI device if a matching device was present
* at the moment of invocation, or NULL otherwise.
*
* The caller is responsible to call put_device() on the returned device.
*
* See additional information in acpi_dev_present() as well.
*/
struct acpi_device *
acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv)
{
return acpi_dev_get_next_match_dev(NULL, hid, uid, hrv);
}
EXPORT_SYMBOL(acpi_dev_get_first_match_dev);
/*
......
drivers/base/property.c
浏览文件 @ de161757
......@@ -837,9 +837,15 @@ EXPORT_SYMBOL_GPL(fwnode_handle_put);
/**
* fwnode_device_is_available - check if a device is available for use
* @fwnode: Pointer to the fwnode of the device.
*
* For fwnode node types that don't implement the .device_is_available()
* operation, this function returns true.
*/
bool fwnode_device_is_available(const struct fwnode_handle *fwnode)
{
if (!fwnode_has_op(fwnode, device_is_available))
return true;
return fwnode_call_bool_op(fwnode, device_is_available);
}
EXPORT_SYMBOL_GPL(fwnode_device_is_available);
......@@ -1209,7 +1215,14 @@ fwnode_graph_get_endpoint_by_id(const struct fwnode_handle *fwnode,
best_ep_id = fwnode_ep.id;
}
return best_ep;
if (best_ep)
return best_ep;
if (fwnode && !IS_ERR_OR_NULL(fwnode->secondary))
return fwnode_graph_get_endpoint_by_id(fwnode->secondary, port,
endpoint, flags);
return NULL;
}
EXPORT_SYMBOL_GPL(fwnode_graph_get_endpoint_by_id);
......
drivers/base/swnode.c
浏览文件 @ de161757
......@@ -457,14 +457,18 @@ software_node_get_next_child(const struct fwnode_handle *fwnode,
struct swnode *c = to_swnode(child);
if (!p || list_empty(&p->children) ||
(c && list_is_last(&c->entry, &p->children)))
(c && list_is_last(&c->entry, &p->children))) {
fwnode_handle_put(child);
return NULL;
}
if (c)
c = list_next_entry(c, entry);
else
c = list_first_entry(&p->children, struct swnode, entry);
return &c->fwnode;
fwnode_handle_put(child);
return fwnode_handle_get(&c->fwnode);
}
static struct fwnode_handle *
......@@ -550,6 +554,115 @@ software_node_get_reference_args(const struct fwnode_handle *fwnode,
return 0;
}
static struct fwnode_handle *
swnode_graph_find_next_port(const struct fwnode_handle *parent,
struct fwnode_handle *port)
{
struct fwnode_handle *old = port;
while ((port = software_node_get_next_child(parent, old))) {
/*
* fwnode ports have naming style "port@", so we search for any
* children that follow that convention.
*/
if (!strncmp(to_swnode(port)->node->name, "port@",
strlen("port@")))
return port;
old = port;
}
return NULL;
}
static struct fwnode_handle *
software_node_graph_get_next_endpoint(const struct fwnode_handle *fwnode,
struct fwnode_handle *endpoint)
{
struct swnode *swnode = to_swnode(fwnode);
struct fwnode_handle *parent;
struct fwnode_handle *port;
if (!swnode)
return NULL;
if (endpoint) {
port = software_node_get_parent(endpoint);
parent = software_node_get_parent(port);
} else {
parent = software_node_get_named_child_node(fwnode, "ports");
if (!parent)
parent = software_node_get(&swnode->fwnode);
port = swnode_graph_find_next_port(parent, NULL);
}
for (; port; port = swnode_graph_find_next_port(parent, port)) {
endpoint = software_node_get_next_child(port, endpoint);
if (endpoint) {
fwnode_handle_put(port);
break;
}
}
fwnode_handle_put(parent);
return endpoint;
}
static struct fwnode_handle *
software_node_graph_get_remote_endpoint(const struct fwnode_handle *fwnode)
{
struct swnode *swnode = to_swnode(fwnode);
const struct software_node_ref_args *ref;
const struct property_entry *prop;
if (!swnode)
return NULL;
prop = property_entry_get(swnode->node->properties, "remote-endpoint");
if (!prop || prop->type != DEV_PROP_REF || prop->is_inline)
return NULL;
ref = prop->pointer;
return software_node_get(software_node_fwnode(ref[0].node));
}
static struct fwnode_handle *
software_node_graph_get_port_parent(struct fwnode_handle *fwnode)
{
struct swnode *swnode = to_swnode(fwnode);
swnode = swnode->parent;
if (swnode && !strcmp(swnode->node->name, "ports"))
swnode = swnode->parent;
return swnode ? software_node_get(&swnode->fwnode) : NULL;
}
static int
software_node_graph_parse_endpoint(const struct fwnode_handle *fwnode,
struct fwnode_endpoint *endpoint)
{
struct swnode *swnode = to_swnode(fwnode);
const char *parent_name = swnode->parent->node->name;
int ret;
if (strlen("port@") >= strlen(parent_name) ||
strncmp(parent_name, "port@", strlen("port@")))
return -EINVAL;
/* Ports have naming style "port@n", we need to select the n */
ret = kstrtou32(parent_name + strlen("port@"), 10, &endpoint->port);
if (ret)
return ret;
endpoint->id = swnode->id;
endpoint->local_fwnode = fwnode;
return 0;
}
static const struct fwnode_operations software_node_ops = {
.get = software_node_get,
.put = software_node_put,
......@@ -561,7 +674,11 @@ static const struct fwnode_operations software_node_ops = {
.get_parent = software_node_get_parent,
.get_next_child_node = software_node_get_next_child,
.get_named_child_node = software_node_get_named_child_node,
.get_reference_args = software_node_get_reference_args
.get_reference_args = software_node_get_reference_args,
.graph_get_next_endpoint = software_node_graph_get_next_endpoint,
.graph_get_remote_endpoint = software_node_graph_get_remote_endpoint,
.graph_get_port_parent = software_node_graph_get_port_parent,
.graph_parse_endpoint = software_node_graph_parse_endpoint,
};
/* -------------------------------------------------------------------------- */
......@@ -702,7 +819,11 @@ swnode_register(const struct software_node *node, struct swnode *parent,
* software_node_register_nodes - Register an array of software nodes
* @nodes: Zero terminated array of software nodes to be registered
*
* Register multiple software nodes at once.
* Register multiple software nodes at once. If any node in the array
* has its .parent pointer set (which can only be to another software_node),
* then its parent **must** have been registered before it is; either outside
* of this function or by ordering the array such that parent comes before
* child.
*/
int software_node_register_nodes(const struct software_node *nodes)
{
......@@ -710,14 +831,23 @@ int software_node_register_nodes(const struct software_node *nodes)
int i;
for (i = 0; nodes[i].name; i++) {
ret = software_node_register(&nodes[i]);
if (ret) {
software_node_unregister_nodes(nodes);
return ret;
const struct software_node *parent = nodes[i].parent;
if (parent && !software_node_to_swnode(parent)) {
ret = -EINVAL;
goto err_unregister_nodes;
}
ret = software_node_register(&nodes[i]);
if (ret)
goto err_unregister_nodes;
}
return 0;
err_unregister_nodes:
software_node_unregister_nodes(nodes);
return ret;
}
EXPORT_SYMBOL_GPL(software_node_register_nodes);
......@@ -725,18 +855,23 @@ EXPORT_SYMBOL_GPL(software_node_register_nodes);
* software_node_unregister_nodes - Unregister an array of software nodes
* @nodes: Zero terminated array of software nodes to be unregistered
*
* Unregister multiple software nodes at once.
* Unregister multiple software nodes at once. If parent pointers are set up
* in any of the software nodes then the array **must** be ordered such that
* parents come before their children.
*
* NOTE: Be careful using this call if the nodes had parent pointers set up in
* them before registering. If so, it is wiser to remove the nodes
* individually, in the correct order (child before parent) instead of relying
* on the sequential order of the list of nodes in the array.
* NOTE: If you are uncertain whether the array is ordered such that
* parents will be unregistered before their children, it is wiser to
* remove the nodes individually, in the correct order (child before
* parent).
*/
void software_node_unregister_nodes(const struct software_node *nodes)
{
int i;
unsigned int i = 0;
while (nodes[i].name)
i++;
for (i = 0; nodes[i].name; i++)
while (i--)
software_node_unregister(&nodes[i]);
}
EXPORT_SYMBOL_GPL(software_node_unregister_nodes);
......@@ -771,16 +906,23 @@ EXPORT_SYMBOL_GPL(software_node_register_node_group);
* software_node_unregister_node_group - Unregister a group of software nodes
* @node_group: NULL terminated array of software node pointers to be unregistered
*
* Unregister multiple software nodes at once.
* Unregister multiple software nodes at once. The array will be unwound in
* reverse order (i.e. last entry first) and thus if any members of the array are
* children of another member then the children must appear later in the list such
* that they are unregistered first.
*/
void software_node_unregister_node_group(const struct software_node **node_group)
void software_node_unregister_node_group(
const struct software_node **node_group)
{
unsigned int i;
unsigned int i = 0;
if (!node_group)
return;
for (i = 0; node_group[i]; i++)
while (node_group[i])
i++;
while (i--)
software_node_unregister(node_group[i]);
}
EXPORT_SYMBOL_GPL(software_node_unregister_node_group);
......
drivers/media/cec/core/cec-adap.c
浏览文件 @ de161757
......@@ -1296,7 +1296,7 @@ static int cec_config_log_addr(struct cec_adapter *adap,
/*
* If we are unable to get an OK or a NACK after max_retries attempts
* (and note that each attempt already consists of four polls), then
* then we assume that something is really weird and that it is not a
* we assume that something is really weird and that it is not a
* good idea to try and claim this logical address.
*/
if (i == max_retries)
......@@ -1735,7 +1735,7 @@ int __cec_s_log_addrs(struct cec_adapter *adap,
const u8 feature_sz = ARRAY_SIZE(log_addrs->features[0]);
u8 *features = log_addrs->features[i];
bool op_is_dev_features = false;
unsigned j;
unsigned int j;
log_addrs->log_addr[i] = CEC_LOG_ADDR_INVALID;
if (log_addrs->log_addr_type[i] > CEC_LOG_ADDR_TYPE_UNREGISTERED) {
......
drivers/media/cec/core/cec-api.c
浏览文件 @ de161757
......@@ -40,7 +40,7 @@ static __poll_t cec_poll(struct file *filp,
poll_wait(filp, &fh->wait, poll);
if (!cec_is_registered(adap))
return EPOLLERR | EPOLLHUP;
return EPOLLERR | EPOLLHUP | EPOLLPRI;
mutex_lock(&adap->lock);
if (adap->is_configured &&
adap->transmit_queue_sz < CEC_MAX_MSG_TX_QUEUE_SZ)
......
drivers/media/common/videobuf2/videobuf2-core.c
浏览文件 @ de161757
......@@ -2374,13 +2374,20 @@ __poll_t vb2_core_poll(struct vb2_queue *q, struct file *file,
struct vb2_buffer *vb = NULL;
unsigned long flags;
/*
* poll_wait() MUST be called on the first invocation on all the
* potential queues of interest, even if we are not interested in their
* events during this first call. Failure to do so will result in
* queue's events to be ignored because the poll_table won't be capable
* of adding new wait queues thereafter.
*/
poll_wait(file, &q->done_wq, wait);
if (!q->is_output && !(req_events & (EPOLLIN | EPOLLRDNORM)))
return 0;
if (q->is_output && !(req_events & (EPOLLOUT | EPOLLWRNORM)))
return 0;
poll_wait(file, &q->done_wq, wait);
/*
* Start file I/O emulator only if streaming API has not been used yet.
*/
......
drivers/media/common/videobuf2/videobuf2-v4l2.c
浏览文件 @ de161757
......@@ -487,11 +487,6 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct media_device *md
!q->ops->buf_out_validate))
return -EINVAL;
if (b->request_fd < 0) {
dprintk(q, 1, "%s: request_fd < 0\n", opname);
return -EINVAL;
}
req = media_request_get_by_fd(mdev, b->request_fd);
if (IS_ERR(req)) {
dprintk(q, 1, "%s: invalid request_fd\n", opname);
......
drivers/media/dvb-core/dvb_frontend.c
浏览文件 @ de161757
......@@ -984,6 +984,7 @@ static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
fe->ops.info.symbol_rate_max);
return -EINVAL;
}
break;
default:
break;
}
......
drivers/media/dvb-frontends/Kconfig
浏览文件 @ de161757
......@@ -515,7 +515,7 @@ config DVB_RTL2830
config DVB_RTL2832
tristate "Realtek RTL2832 DVB-T"
depends on DVB_CORE && I2C && I2C_MUX
select REGMAP
select REGMAP_I2C
default m if !MEDIA_SUBDRV_AUTOSELECT
help
Say Y when you want to support this frontend.
......@@ -708,6 +708,15 @@ config DVB_S5H1411
An ATSC 8VSB and QAM64/256 tuner module. Say Y when you want
to support this frontend.
config DVB_MXL692
tristate "MaxLinear MXL692 based"
depends on DVB_CORE && I2C
default m if !MEDIA_SUBDRV_AUTOSELECT
help
MaxLinear MxL692 is a combo tuner-demodulator that
supports ATSC 8VSB and QAM modes. Say Y when you want to
support this frontend.
comment "ISDB-T (terrestrial) frontends"
depends on DVB_CORE
......
drivers/media/dvb-frontends/Makefile
浏览文件 @ de161757
......@@ -55,6 +55,7 @@ obj-$(CONFIG_DVB_S5H1420) += s5h1420.o
obj-$(CONFIG_DVB_LGDT330X) += lgdt330x.o
obj-$(CONFIG_DVB_LGDT3305) += lgdt3305.o
obj-$(CONFIG_DVB_LGDT3306A) += lgdt3306a.o
obj-$(CONFIG_DVB_MXL692) += mxl692.o
obj-$(CONFIG_DVB_LG2160) += lg2160.o
obj-$(CONFIG_DVB_CX24123) += cx24123.o
obj-$(CONFIG_DVB_LNBH25) += lnbh25.o
......
drivers/media/dvb-frontends/af9033.c
浏览文件 @ de161757
......@@ -125,6 +125,7 @@ static int af9033_init(struct dvb_frontend *fe)
if (i == ARRAY_SIZE(clock_adc_lut)) {
dev_err(&client->dev, "Couldn't find ADC config for clock %d\n",
dev->cfg.clock);
ret = -ENODEV;
goto err;
}
......@@ -852,6 +853,7 @@ static int af9033_read_snr(struct dvb_frontend *fe, u16 *snr)
*snr = *snr * 0xffff / 32;
break;
default:
ret = -EINVAL;
goto err;
}
}
......
drivers/media/dvb-frontends/cx24120.c
浏览文件 @ de161757
......@@ -363,6 +363,7 @@ static void cx24120_check_cmd(struct cx24120_state *state, u8 id)
case CMD_DISEQC_BURST:
cx24120_msg_mpeg_output_global_config(state, 0);
/* Old driver would do a msleep(100) here */
return;
default:
return;
}
......
drivers/media/dvb-frontends/cxd2841er.c
浏览文件 @ de161757
......@@ -3338,7 +3338,7 @@ static int cxd2841er_set_frontend_s(struct dvb_frontend *fe)
cxd2841er_tuner_set(fe);
cxd2841er_tune_done(priv);
timeout = ((3000000 + (symbol_rate - 1)) / symbol_rate) + 150;
timeout = DIV_ROUND_UP(3000000, symbol_rate) + 150;
i = 0;
do {
......
drivers/media/dvb-frontends/dib0090.c
浏览文件 @ de161757
......@@ -1765,6 +1765,8 @@ static int dib0090_dc_offset_calibration(struct dib0090_state *state, enum front
dib0090_write_reg(state, 0x1f, 0x7);
*tune_state = CT_TUNER_START; /* reset done -> real tuning can now begin */
state->calibrate &= ~DC_CAL;
break;
default:
break;
}
......
drivers/media/dvb-frontends/drxk_hard.c
浏览文件 @ de161757
......@@ -3294,6 +3294,7 @@ static int dvbt_sc_command(struct drxk_state *state,
case OFDM_SC_RA_RAM_CMD_USER_IO:
case OFDM_SC_RA_RAM_CMD_GET_OP_PARAM:
status = read16(state, OFDM_SC_RA_RAM_PARAM0__A, &(param0));
break;
/* All commands yielding 0 results */
case OFDM_SC_RA_RAM_CMD_SET_ECHO_TIMING:
case OFDM_SC_RA_RAM_CMD_SET_TIMER:
......
drivers/media/dvb-frontends/m88rs2000.c
浏览文件 @ de161757
......@@ -390,6 +390,7 @@ static int m88rs2000_tab_set(struct m88rs2000_state *state,
case 0xff:
if (tab[i].reg == 0xaa && tab[i].val == 0xff)
return 0;
break;
case 0x00:
break;
default:
......
drivers/media/dvb-frontends/mxl692.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/dvb-frontends/mxl692.h 0 → 100644
浏览文件 @ de161757
/* SPDX-License-Identifier: GPL-2.0 */
/*
* Driver for the MaxLinear MxL69x family of tuners/demods
*
* Copyright (C) 2020 Brad Love <brad@nextdimension.cc>
*
* based on code:
* Copyright (c) 2016 MaxLinear, Inc. All rights reserved
* which was released under GPL V2
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2, as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#ifndef _MXL692_H_
#define _MXL692_H_
#include <media/dvb_frontend.h>
#define MXL692_FIRMWARE "dvb-demod-mxl692.fw"
struct mxl692_config {
unsigned char id;
u8 i2c_addr;
/*
* frontend
* returned by driver
*/
struct dvb_frontend **fe;
};
#endif /* _MXL692_H_ */
drivers/media/dvb-frontends/mxl692_defs.h 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/dvb-frontends/rtl2832.c
浏览文件 @ de161757
......@@ -698,6 +698,7 @@ static int rtl2832_read_status(struct dvb_frontend *fe, enum fe_status *status)
goto err;
constellation = (u8tmp >> 2) & 0x03; /* [3:2] */
ret = -EINVAL;
if (constellation > CONSTELLATION_NUM - 1)
goto err;
......
drivers/media/i2c/Kconfig
浏览文件 @ de161757
......@@ -813,6 +813,20 @@ config VIDEO_IMX319
To compile this driver as a module, choose M here: the
module will be called imx319.
config VIDEO_IMX334
tristate "Sony IMX334 sensor support"
depends on OF_GPIO
depends on I2C && VIDEO_V4L2
select VIDEO_V4L2_SUBDEV_API
select MEDIA_CONTROLLER
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the Sony
IMX334 camera.
To compile this driver as a module, choose M here: the
module will be called imx334.
config VIDEO_IMX355
tristate "Sony IMX355 sensor support"
depends on I2C && VIDEO_V4L2
......@@ -936,6 +950,19 @@ config VIDEO_OV5647
To compile this driver as a module, choose M here: the
module will be called ov5647.
config VIDEO_OV5648
tristate "OmniVision OV5648 sensor support"
depends on I2C && PM && VIDEO_V4L2
select MEDIA_CONTROLLER
select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
OV5648 camera.
To compile this driver as a module, choose M here: the
module will be called ov5648.
config VIDEO_OV6650
tristate "OmniVision OV6650 sensor support"
depends on I2C && VIDEO_V4L2
......@@ -1000,6 +1027,7 @@ config VIDEO_OV772X
tristate "OmniVision OV772x sensor support"
depends on I2C && VIDEO_V4L2
select REGMAP_SCCB
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for the OmniVision
OV772x camera.
......@@ -1047,6 +1075,19 @@ config VIDEO_OV8856
To compile this driver as a module, choose M here: the
module will be called ov8856.
config VIDEO_OV8865
tristate "OmniVision OV8865 sensor support"
depends on I2C && PM && VIDEO_V4L2
select MEDIA_CONTROLLER
select VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
help
This is a Video4Linux2 sensor driver for OmniVision
OV8865 camera sensor.
To compile this driver as a module, choose M here: the
module will be called ov8865.
config VIDEO_OV9640
tristate "OmniVision OV9640 sensor support"
depends on I2C && VIDEO_V4L2
......@@ -1199,12 +1240,16 @@ config VIDEO_NOON010PC30
source "drivers/media/i2c/m5mols/Kconfig"
config VIDEO_MAX9271_LIB
tristate
config VIDEO_RDACM20
tristate "IMI RDACM20 camera support"
depends on I2C
select V4L2_FWNODE
select VIDEO_V4L2_SUBDEV_API
select MEDIA_CONTROLLER
select VIDEO_MAX9271_LIB
help
This driver supports the IMI RDACM20 GMSL camera, used in
ADAS systems.
......@@ -1212,6 +1257,20 @@ config VIDEO_RDACM20
This camera should be used in conjunction with a GMSL
deserialiser such as the MAX9286.
config VIDEO_RDACM21
tristate "IMI RDACM21 camera support"
depends on I2C
select V4L2_FWNODE
select VIDEO_V4L2_SUBDEV_API
select MEDIA_CONTROLLER
select VIDEO_MAX9271_LIB
help
This driver supports the IMI RDACM21 GMSL camera, used in
ADAS systems.
This camera should be used in conjunction with a GMSL
deserialiser such as the MAX9286.
config VIDEO_RJ54N1
tristate "Sharp RJ54N1CB0C sensor support"
depends on I2C && VIDEO_V4L2
......
drivers/media/i2c/Makefile
浏览文件 @ de161757
......@@ -72,6 +72,7 @@ obj-$(CONFIG_VIDEO_OV2740) += ov2740.o
obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
obj-$(CONFIG_VIDEO_OV5648) += ov5648.o
obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
obj-$(CONFIG_VIDEO_OV5675) += ov5675.o
obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
......@@ -82,6 +83,7 @@ obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
obj-$(CONFIG_VIDEO_OV8856) += ov8856.o
obj-$(CONFIG_VIDEO_OV8865) += ov8865.o
obj-$(CONFIG_VIDEO_OV9640) += ov9640.o
obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
obj-$(CONFIG_VIDEO_OV9734) += ov9734.o
......@@ -120,10 +122,12 @@ obj-$(CONFIG_VIDEO_IMX258) += imx258.o
obj-$(CONFIG_VIDEO_IMX274) += imx274.o
obj-$(CONFIG_VIDEO_IMX290) += imx290.o
obj-$(CONFIG_VIDEO_IMX319) += imx319.o
obj-$(CONFIG_VIDEO_IMX334) += imx334.o
obj-$(CONFIG_VIDEO_IMX355) += imx355.o
obj-$(CONFIG_VIDEO_MAX9286) += max9286.o
rdacm20-camera_module-objs := rdacm20.o max9271.o
obj-$(CONFIG_VIDEO_RDACM20) += rdacm20-camera_module.o
obj-$(CONFIG_VIDEO_MAX9271_LIB) += max9271.o
obj-$(CONFIG_VIDEO_RDACM20) += rdacm20.o
obj-$(CONFIG_VIDEO_RDACM21) += rdacm21.o
obj-$(CONFIG_VIDEO_ST_MIPID02) += st-mipid02.o
obj-$(CONFIG_SDR_MAX2175) += max2175.o
drivers/media/i2c/ccs-pll.c
浏览文件 @ de161757
......@@ -17,20 +17,20 @@
#include "ccs-pll.h"
/* Return an even number or one. */
static inline uint32_t clk_div_even(uint32_t a)
static inline u32 clk_div_even(u32 a)
{
return max_t(uint32_t, 1, a & ~1);
return max_t(u32, 1, a & ~1);
}
/* Return an even number or one. */
static inline uint32_t clk_div_even_up(uint32_t a)
static inline u32 clk_div_even_up(u32 a)
{
if (a == 1)
return 1;
return (a + 1) & ~1;
}
static inline uint32_t is_one_or_even(uint32_t a)
static inline u32 is_one_or_even(u32 a)
{
if (a == 1)
return 1;
......@@ -40,13 +40,13 @@ static inline uint32_t is_one_or_even(uint32_t a)
return 1;
}
static inline uint32_t one_or_more(uint32_t a)
static inline u32 one_or_more(u32 a)
{
return a ?: 1;
}
static int bounds_check(struct device *dev, uint32_t val,
uint32_t min, uint32_t max, const char *prefix,
static int bounds_check(struct device *dev, u32 val,
u32 min, u32 max, const char *prefix,
char *str)
{
if (val >= min && val <= max)
......@@ -138,12 +138,12 @@ static void print_pll(struct device *dev, struct ccs_pll *pll)
pll->flags & PLL_FL(OP_PIX_DDR) ? " op-pix-ddr" : "");
}
static uint32_t op_sys_ddr(uint32_t flags)
static u32 op_sys_ddr(u32 flags)
{
return flags & CCS_PLL_FLAG_OP_SYS_DDR ? 1 : 0;
}
static uint32_t op_pix_ddr(uint32_t flags)
static u32 op_pix_ddr(u32 flags)
{
return flags & CCS_PLL_FLAG_OP_PIX_DDR ? 1 : 0;
}
......@@ -250,8 +250,8 @@ static int check_ext_bounds(struct device *dev, struct ccs_pll *pll)
static void
ccs_pll_find_vt_sys_div(struct device *dev, const struct ccs_pll_limits *lim,
struct ccs_pll *pll, struct ccs_pll_branch_fr *pll_fr,
uint16_t min_vt_div, uint16_t max_vt_div,
uint16_t *min_sys_div, uint16_t *max_sys_div)
u16 min_vt_div, u16 max_vt_div,
u16 *min_sys_div, u16 *max_sys_div)
{
/*
* Find limits for sys_clk_div. Not all values are possible with all
......@@ -259,11 +259,11 @@ ccs_pll_find_vt_sys_div(struct device *dev, const struct ccs_pll_limits *lim,
*/
*min_sys_div = lim->vt_bk.min_sys_clk_div;
dev_dbg(dev, "min_sys_div: %u\n", *min_sys_div);
*min_sys_div = max_t(uint16_t, *min_sys_div,
*min_sys_div = max_t(u16, *min_sys_div,
DIV_ROUND_UP(min_vt_div,
lim->vt_bk.max_pix_clk_div));
dev_dbg(dev, "min_sys_div: max_vt_pix_clk_div: %u\n", *min_sys_div);
*min_sys_div = max_t(uint16_t, *min_sys_div,
*min_sys_div = max_t(u16, *min_sys_div,
pll_fr->pll_op_clk_freq_hz
/ lim->vt_bk.max_sys_clk_freq_hz);
dev_dbg(dev, "min_sys_div: max_pll_op_clk_freq_hz: %u\n", *min_sys_div);
......@@ -272,11 +272,11 @@ ccs_pll_find_vt_sys_div(struct device *dev, const struct ccs_pll_limits *lim,
*max_sys_div = lim->vt_bk.max_sys_clk_div;
dev_dbg(dev, "max_sys_div: %u\n", *max_sys_div);
*max_sys_div = min_t(uint16_t, *max_sys_div,
*max_sys_div = min_t(u16, *max_sys_div,
DIV_ROUND_UP(max_vt_div,
lim->vt_bk.min_pix_clk_div));
dev_dbg(dev, "max_sys_div: min_vt_pix_clk_div: %u\n", *max_sys_div);
*max_sys_div = min_t(uint16_t, *max_sys_div,
*max_sys_div = min_t(u16, *max_sys_div,
DIV_ROUND_UP(pll_fr->pll_op_clk_freq_hz,
lim->vt_bk.min_pix_clk_freq_hz));
dev_dbg(dev, "max_sys_div: min_vt_pix_clk_freq_hz: %u\n", *max_sys_div);
......@@ -289,15 +289,15 @@ ccs_pll_find_vt_sys_div(struct device *dev, const struct ccs_pll_limits *lim,
static inline int
__ccs_pll_calculate_vt_tree(struct device *dev,
const struct ccs_pll_limits *lim,
struct ccs_pll *pll, uint32_t mul, uint32_t div)
struct ccs_pll *pll, u32 mul, u32 div)
{
const struct ccs_pll_branch_limits_fr *lim_fr = &lim->vt_fr;
const struct ccs_pll_branch_limits_bk *lim_bk = &lim->vt_bk;
struct ccs_pll_branch_fr *pll_fr = &pll->vt_fr;
struct ccs_pll_branch_bk *pll_bk = &pll->vt_bk;
uint32_t more_mul;
uint16_t best_pix_div = SHRT_MAX >> 1, best_div;
uint16_t vt_div, min_sys_div, max_sys_div, sys_div;
u32 more_mul;
u16 best_pix_div = SHRT_MAX >> 1, best_div;
u16 vt_div, min_sys_div, max_sys_div, sys_div;
pll_fr->pll_ip_clk_freq_hz =
pll->ext_clk_freq_hz / pll_fr->pre_pll_clk_div;
......@@ -331,7 +331,7 @@ __ccs_pll_calculate_vt_tree(struct device *dev,
for (sys_div = min_sys_div; sys_div <= max_sys_div;
sys_div += 2 - (sys_div & 1)) {
uint16_t pix_div;
u16 pix_div;
if (vt_div % sys_div)
continue;
......@@ -379,9 +379,9 @@ static int ccs_pll_calculate_vt_tree(struct device *dev,
{
const struct ccs_pll_branch_limits_fr *lim_fr = &lim->vt_fr;
struct ccs_pll_branch_fr *pll_fr = &pll->vt_fr;
uint16_t min_pre_pll_clk_div = lim_fr->min_pre_pll_clk_div;
uint16_t max_pre_pll_clk_div = lim_fr->max_pre_pll_clk_div;
uint32_t pre_mul, pre_div;
u16 min_pre_pll_clk_div = lim_fr->min_pre_pll_clk_div;
u16 max_pre_pll_clk_div = lim_fr->max_pre_pll_clk_div;
u32 pre_mul, pre_div;
pre_div = gcd(pll->pixel_rate_csi,
pll->ext_clk_freq_hz * pll->vt_lanes);
......@@ -390,11 +390,11 @@ static int ccs_pll_calculate_vt_tree(struct device *dev,
/* Make sure PLL input frequency is within limits */
max_pre_pll_clk_div =
min_t(uint16_t, max_pre_pll_clk_div,
min_t(u16, max_pre_pll_clk_div,
DIV_ROUND_UP(pll->ext_clk_freq_hz,
lim_fr->min_pll_ip_clk_freq_hz));
min_pre_pll_clk_div = max_t(uint16_t, min_pre_pll_clk_div,
min_pre_pll_clk_div = max_t(u16, min_pre_pll_clk_div,
pll->ext_clk_freq_hz /
lim_fr->max_pll_ip_clk_freq_hz);
......@@ -406,7 +406,7 @@ static int ccs_pll_calculate_vt_tree(struct device *dev,
pll_fr->pre_pll_clk_div +=
(pll->flags & CCS_PLL_FLAG_EXT_IP_PLL_DIVIDER) ? 1 :
2 - (pll_fr->pre_pll_clk_div & 1)) {
uint32_t mul, div;
u32 mul, div;
int rval;
div = gcd(pre_mul * pll_fr->pre_pll_clk_div, pre_div);
......@@ -440,13 +440,13 @@ ccs_pll_calculate_vt(struct device *dev, const struct ccs_pll_limits *lim,
const struct ccs_pll_branch_limits_bk *op_lim_bk,
struct ccs_pll *pll, struct ccs_pll_branch_fr *pll_fr,
struct ccs_pll_branch_bk *op_pll_bk, bool cphy,
uint32_t phy_const)
u32 phy_const)
{
uint16_t sys_div;
uint16_t best_pix_div = SHRT_MAX >> 1;
uint16_t vt_op_binning_div;
uint16_t min_vt_div, max_vt_div, vt_div;
uint16_t min_sys_div, max_sys_div;
u16 sys_div;
u16 best_pix_div = SHRT_MAX >> 1;
u16 vt_op_binning_div;
u16 min_vt_div, max_vt_div, vt_div;
u16 min_sys_div, max_sys_div;
if (pll->flags & CCS_PLL_FLAG_NO_OP_CLOCKS)
goto out_calc_pixel_rate;
......@@ -500,18 +500,18 @@ ccs_pll_calculate_vt(struct device *dev, const struct ccs_pll_limits *lim,
/* Find smallest and biggest allowed vt divisor. */
dev_dbg(dev, "min_vt_div: %u\n", min_vt_div);
min_vt_div = max_t(uint16_t, min_vt_div,
min_vt_div = max_t(u16, min_vt_div,
DIV_ROUND_UP(pll_fr->pll_op_clk_freq_hz,
lim->vt_bk.max_pix_clk_freq_hz));
dev_dbg(dev, "min_vt_div: max_vt_pix_clk_freq_hz: %u\n",
min_vt_div);
min_vt_div = max_t(uint16_t, min_vt_div, lim->vt_bk.min_pix_clk_div
* lim->vt_bk.min_sys_clk_div);
min_vt_div = max_t(u16, min_vt_div, lim->vt_bk.min_pix_clk_div
* lim->vt_bk.min_sys_clk_div);
dev_dbg(dev, "min_vt_div: min_vt_clk_div: %u\n", min_vt_div);
max_vt_div = lim->vt_bk.max_sys_clk_div * lim->vt_bk.max_pix_clk_div;
dev_dbg(dev, "max_vt_div: %u\n", max_vt_div);
max_vt_div = min_t(uint16_t, max_vt_div,
max_vt_div = min_t(u16, max_vt_div,
DIV_ROUND_UP(pll_fr->pll_op_clk_freq_hz,
lim->vt_bk.min_pix_clk_freq_hz));
dev_dbg(dev, "max_vt_div: min_vt_pix_clk_freq_hz: %u\n",
......@@ -526,12 +526,12 @@ ccs_pll_calculate_vt(struct device *dev, const struct ccs_pll_limits *lim,
* divisor.
*/
for (vt_div = min_vt_div; vt_div <= max_vt_div; vt_div++) {
uint16_t __max_sys_div = vt_div & 1 ? 1 : max_sys_div;
u16 __max_sys_div = vt_div & 1 ? 1 : max_sys_div;
for (sys_div = min_sys_div; sys_div <= __max_sys_div;
sys_div += 2 - (sys_div & 1)) {
uint16_t pix_div;
uint16_t rounded_div;
u16 pix_div;
u16 rounded_div;
pix_div = DIV_ROUND_UP(vt_div, sys_div);
......@@ -588,9 +588,9 @@ ccs_pll_calculate_op(struct device *dev, const struct ccs_pll_limits *lim,
const struct ccs_pll_branch_limits_fr *op_lim_fr,
const struct ccs_pll_branch_limits_bk *op_lim_bk,
struct ccs_pll *pll, struct ccs_pll_branch_fr *op_pll_fr,
struct ccs_pll_branch_bk *op_pll_bk, uint32_t mul,
uint32_t div, uint32_t op_sys_clk_freq_hz_sdr, uint32_t l,
bool cphy, uint32_t phy_const)
struct ccs_pll_branch_bk *op_pll_bk, u32 mul,
u32 div, u32 op_sys_clk_freq_hz_sdr, u32 l,
bool cphy, u32 phy_const)
{
/*
* Higher multipliers (and divisors) are often required than
......@@ -598,9 +598,9 @@ ccs_pll_calculate_op(struct device *dev, const struct ccs_pll_limits *lim,
* There are limits for all values in the clock tree. These
* are the minimum and maximum multiplier for mul.
*/
uint32_t more_mul_min, more_mul_max;
uint32_t more_mul_factor;
uint32_t i;
u32 more_mul_min, more_mul_max;
u32 more_mul_factor;
u32 i;
/*
* Get pre_pll_clk_div so that our pll_op_clk_freq_hz won't be
......@@ -614,7 +614,7 @@ ccs_pll_calculate_op(struct device *dev, const struct ccs_pll_limits *lim,
more_mul_max);
/* Don't go above max pll op frequency. */
more_mul_max =
min_t(uint32_t,
min_t(u32,
more_mul_max,
op_lim_fr->max_pll_op_clk_freq_hz
/ (pll->ext_clk_freq_hz /
......@@ -706,14 +706,14 @@ int ccs_pll_calculate(struct device *dev, const struct ccs_pll_limits *lim,
struct ccs_pll_branch_fr *op_pll_fr;
struct ccs_pll_branch_bk *op_pll_bk;
bool cphy = pll->bus_type == CCS_PLL_BUS_TYPE_CSI2_CPHY;
uint32_t phy_const = cphy ? CPHY_CONST : DPHY_CONST;
uint32_t op_sys_clk_freq_hz_sdr;
uint16_t min_op_pre_pll_clk_div;
uint16_t max_op_pre_pll_clk_div;
uint32_t mul, div;
uint32_t l = (!pll->op_bits_per_lane ||
pll->op_bits_per_lane >= pll->bits_per_pixel) ? 1 : 2;
uint32_t i;
u32 phy_const = cphy ? CPHY_CONST : DPHY_CONST;
u32 op_sys_clk_freq_hz_sdr;
u16 min_op_pre_pll_clk_div;
u16 max_op_pre_pll_clk_div;
u32 mul, div;
u32 l = (!pll->op_bits_per_lane ||
pll->op_bits_per_lane >= pll->bits_per_pixel) ? 1 : 2;
u32 i;
int rval = -EINVAL;
if (!(pll->flags & CCS_PLL_FLAG_LANE_SPEED_MODEL)) {
......@@ -791,11 +791,11 @@ int ccs_pll_calculate(struct device *dev, const struct ccs_pll_limits *lim,
dev_dbg(dev, "min / max op_pre_pll_clk_div: %u / %u\n",
op_lim_fr->min_pre_pll_clk_div, op_lim_fr->max_pre_pll_clk_div);
max_op_pre_pll_clk_div =
min_t(uint16_t, op_lim_fr->max_pre_pll_clk_div,
min_t(u16, op_lim_fr->max_pre_pll_clk_div,
clk_div_even(pll->ext_clk_freq_hz /
op_lim_fr->min_pll_ip_clk_freq_hz));
min_op_pre_pll_clk_div =
max_t(uint16_t, op_lim_fr->min_pre_pll_clk_div,
max_t(u16, op_lim_fr->min_pre_pll_clk_div,
clk_div_even_up(
DIV_ROUND_UP(pll->ext_clk_freq_hz,
op_lim_fr->max_pll_ip_clk_freq_hz)));
......@@ -809,7 +809,7 @@ int ccs_pll_calculate(struct device *dev, const struct ccs_pll_limits *lim,
dev_dbg(dev, "mul %u / div %u\n", mul, div);
min_op_pre_pll_clk_div =
max_t(uint16_t, min_op_pre_pll_clk_div,
max_t(u16, min_op_pre_pll_clk_div,
clk_div_even_up(
mul /
one_or_more(
......@@ -877,4 +877,4 @@ EXPORT_SYMBOL_GPL(ccs_pll_calculate);
MODULE_AUTHOR("Sakari Ailus <sakari.ailus@linux.intel.com>");
MODULE_DESCRIPTION("Generic MIPI CCS/SMIA/SMIA++ PLL calculator");
MODULE_LICENSE("GPL v2");
MODULE_LICENSE("GPL");
drivers/media/i2c/ccs-pll.h
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ccs/ccs-core.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ccs/ccs-data.c
浏览文件 @ de161757
......@@ -10,7 +10,6 @@
#include <linux/limits.h>
#include <linux/mm.h>
#include <linux/slab.h>
#include <linux/types.h>
#include "ccs-data-defs.h"
......@@ -215,7 +214,7 @@ static int ccs_data_parse_regs(struct bin_container *bin,
size_t *__num_regs, const void *payload,
const void *endp, struct device *dev)
{
struct ccs_reg *regs_base, *regs;
struct ccs_reg *regs_base = NULL, *regs = NULL;
size_t num_regs = 0;
u16 addr = 0;
......@@ -286,6 +285,9 @@ static int ccs_data_parse_regs(struct bin_container *bin,
if (!bin->base) {
bin_reserve(bin, len);
} else if (__regs) {
if (!regs)
return -EIO;
regs->addr = addr;
regs->len = len;
regs->value = bin_alloc(bin, len);
......@@ -306,8 +308,12 @@ static int ccs_data_parse_regs(struct bin_container *bin,
if (__num_regs)
*__num_regs = num_regs;
if (bin->base && __regs)
if (bin->base && __regs) {
if (!regs_base)
return -EIO;
*__regs = regs_base;
}
return 0;
}
......@@ -426,7 +432,7 @@ static int ccs_data_parse_rules(struct bin_container *bin,
size_t *__num_rules, const void *payload,
const void *endp, struct device *dev)
{
struct ccs_rule *rules_base, *rules = NULL, *next_rule;
struct ccs_rule *rules_base = NULL, *rules = NULL, *next_rule = NULL;
size_t num_rules = 0;
const void *__next_rule = payload;
int rval;
......@@ -484,6 +490,9 @@ static int ccs_data_parse_rules(struct bin_container *bin,
} else {
unsigned int i;
if (!next_rule)
return -EIO;
rules = next_rule;
next_rule++;
......@@ -556,6 +565,9 @@ static int ccs_data_parse_rules(struct bin_container *bin,
bin_reserve(bin, sizeof(*rules) * num_rules);
*__num_rules = num_rules;
} else {
if (!rules_base)
return -EIO;
*__rules = rules_base;
}
......@@ -691,7 +703,7 @@ static int ccs_data_parse_pdaf(struct bin_container *bin, struct ccs_pdaf_pix_lo
}
for (i = 0; i < max_block_type_id; i++) {
struct ccs_pdaf_pix_loc_pixel_desc_group *pdgroup;
struct ccs_pdaf_pix_loc_pixel_desc_group *pdgroup = NULL;
unsigned int j;
if (!is_contained(__num_pixel_descs, endp))
......@@ -722,6 +734,9 @@ static int ccs_data_parse_pdaf(struct bin_container *bin, struct ccs_pdaf_pix_lo
if (!bin->base)
continue;
if (!pdgroup)
return -EIO;
pdesc = &pdgroup->descs[j];
pdesc->pixel_type = __pixel_desc->pixel_type;
pdesc->small_offset_x = __pixel_desc->small_offset_x;
......
drivers/media/i2c/ccs/ccs-data.h
浏览文件 @ de161757
......@@ -10,6 +10,8 @@
#include <linux/types.h>
struct device;
/**
* struct ccs_data_block_version - CCS static data version
* @version_major: Major version number
......
drivers/media/i2c/ccs/ccs.h
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ccs/smiapp-reg-defs.h
浏览文件 @ de161757
......@@ -535,6 +535,8 @@
#define SMIAPP_DIGITAL_CROP_CAPABILITY_NONE 0
#define SMIAPP_DIGITAL_CROP_CAPABILITY_INPUT_CROP 1
#define SMIAPP_DIGITAL_GAIN_CAPABILITY_PER_CHANNEL 1
#define SMIAPP_BINNING_CAPABILITY_NO 0
#define SMIAPP_BINNING_CAPABILITY_YES 1
......
drivers/media/i2c/imx219.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/imx258.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/imx334.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/max9271.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/max9286.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/mt9m111.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/mt9v111.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ov02a10.c
浏览文件 @ de161757
......@@ -388,7 +388,7 @@ static int ov02a10_check_sensor_id(struct ov02a10 *ov02a10)
if (ret < 0)
return ret;
chip_id = le16_to_cpu(ret);
chip_id = le16_to_cpu((__force __le16)ret);
if ((chip_id & OV02A10_ID_MASK) != OV02A10_ID) {
dev_err(&client->dev, "unexpected sensor id(0x%04x)\n", chip_id);
......
drivers/media/i2c/ov5647.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ov5648.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ov5670.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ov5675.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ov6650.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ov8856.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ov8865.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ov9640.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/ov9640.h
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/rdacm20.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/rdacm21.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/i2c/st-mipid02.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/pci/intel/ipu3/cio2-bridge.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/pci/intel/ipu3/cio2-bridge.h 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/pci/saa7164/saa7164.h
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/Kconfig
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/Makefile
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/allegro-dvt/nal-hevc.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/allegro-dvt/nal-hevc.h 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/allegro-dvt/nal-rbsp.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/allegro-dvt/nal-rbsp.h 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/pxa_camera.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/qcom/venus/hfi_plat_bufs.h 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/qcom/venus/hfi_plat_bufs_v6.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/qcom/venus/hfi_platform.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/qcom/venus/hfi_platform.h 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/qcom/venus/hfi_platform_v4.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/qcom/venus/hfi_platform_v6.c 0 → 100644
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/rcar_drif.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/rcar_fdp1.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/rcar_jpu.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/sh_vou.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/ti-vpe/cal.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/ti-vpe/cal.h
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/ti-vpe/vpe.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/video-mux.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/platform/vsp1/vsp1.h
浏览文件 @ de161757
此差异已折叠。
drivers/media/rc/Kconfig
浏览文件 @ de161757
此差异已折叠。
drivers/media/rc/img-ir/Kconfig
浏览文件 @ de161757
此差异已折叠。
drivers/media/rc/ir_toy.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/rc/mceusb.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/rc/sunxi-cir.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/tuners/it913x.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/tuners/qm1d1c0042.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/cx231xx/Kconfig
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/em28xx/Kconfig
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/em28xx/em28xx.h
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/pwc/pwc-if.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/uvc/uvc_ctrl.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/uvc/uvc_driver.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/uvc/uvc_entity.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/uvc/uvc_isight.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/uvc/uvc_queue.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/uvc/uvc_status.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/uvc/uvc_v4l2.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/uvc/uvc_video.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/uvc/uvcvideo.h
浏览文件 @ de161757
此差异已折叠。
drivers/media/usb/zr364xx/zr364xx.c
浏览文件 @ de161757
此差异已折叠。
drivers/media/v4l2-core/Makefile
浏览文件 @ de161757
此差异已折叠。
drivers/media/v4l2-core/v4l2-clk.c 已删除 100644 → 0
浏览文件 @ 66f73fb3
此差异已折叠。
drivers/media/v4l2-core/v4l2-dev.c
浏览文件 @ de161757
此差异已折叠。
drivers/staging/media/Kconfig
浏览文件 @ de161757
此差异已折叠。
drivers/staging/media/Makefile
浏览文件 @ de161757
此差异已折叠。
drivers/staging/media/allegro-dvt/Kconfig 已删除 100644 → 0
浏览文件 @ 66f73fb3
此差异已折叠。
drivers/staging/media/allegro-dvt/TODO 已删除 100644 → 0
浏览文件 @ 66f73fb3
此差异已折叠。
drivers/staging/media/imx/Kconfig
浏览文件 @ de161757
此差异已折叠。
drivers/staging/media/imx/Makefile
浏览文件 @ de161757
此差异已折叠。
include/acpi/acpi_bus.h
浏览文件 @ de161757
此差异已折叠。
include/linux/fwnode.h
浏览文件 @ de161757
此差异已折叠。
include/media/davinci/vpif_types.h
浏览文件 @ de161757
此差异已折叠。
include/media/v4l2-async.h
浏览文件 @ de161757
此差异已折叠。
include/media/v4l2-clk.h 已删除 100644 → 0
浏览文件 @ 66f73fb3
此差异已折叠。
include/media/v4l2-event.h
浏览文件 @ de161757
此差异已折叠。
include/media/v4l2-fwnode.h
浏览文件 @ de161757
此差异已折叠。
include/uapi/linux/ccs.h 0 → 100644
浏览文件 @ de161757
此差异已折叠。
include/uapi/linux/media.h
浏览文件 @ de161757
此差异已折叠。
include/uapi/linux/v4l2-controls.h
浏览文件 @ de161757
此差异已折叠。
lib/test_printf.c
浏览文件 @ de161757
此差异已折叠。
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或