diff --git a/.mailmap b/.mailmap index 8e97cc50218e..634f04850fb7 100644 --- a/.mailmap +++ b/.mailmap @@ -317,6 +317,7 @@ Hans de Goede Hans Verkuil Hans Verkuil Hans Verkuil +Hans Verkuil Hao Ge Harry Yoo <42.hyeyoo@gmail.com> Harry Yoo diff --git a/Documentation/admin-guide/media/mgb4.rst b/Documentation/admin-guide/media/mgb4.rst index 0a8a56e837f7..8e429fd77712 100644 --- a/Documentation/admin-guide/media/mgb4.rst +++ b/Documentation/admin-guide/media/mgb4.rst @@ -74,6 +74,7 @@ Common FPDL3/GMSL input parameters | 0 - OLDI/JEIDA | 1 - SPWG/VESA (default) + | 2 - ZDML **link_status** (R): Video link status. If the link is locked, chips are properly connected and @@ -240,6 +241,13 @@ Common FPDL3/GMSL output parameters *Note: This parameter can not be changed while the output v4l2 device is open.* +**color_mapping** (RW): + Mapping of the outgoing bits in the signal to the colour bits of the pixels. + + | 0 - OLDI/JEIDA + | 1 - SPWG/VESA (default) + | 2 - ZDML + **frame_rate** (RW): Output video signal frame rate limit in frames per second. Due to the limited output pixel clock steps, the card can not always generate diff --git a/Documentation/admin-guide/media/starfive_camss.rst b/Documentation/admin-guide/media/starfive_camss.rst deleted file mode 100644 index ca42e9447c47..000000000000 --- a/Documentation/admin-guide/media/starfive_camss.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -.. include:: - -================================ -Starfive Camera Subsystem driver -================================ - -Introduction ------------- - -This file documents the driver for the Starfive Camera Subsystem found on -Starfive JH7110 SoC. The driver is located under drivers/staging/media/starfive/ -camss. - -The driver implements V4L2, Media controller and v4l2_subdev interfaces. Camera -sensor using V4L2 subdev interface in the kernel is supported. - -The driver has been successfully used on the Gstreamer 1.18.5 with v4l2src -plugin. - - -Starfive Camera Subsystem hardware ----------------------------------- - -The Starfive Camera Subsystem hardware consists of:: - - |\ +---------------+ +-----------+ - +----------+ | \ | | | | - | | | | | | | | - | MIPI |----->| |----->| ISP |----->| | - | | | | | | | | - +----------+ | | | | | Memory | - |MUX| +---------------+ | Interface | - +----------+ | | | | - | | | |---------------------------->| | - | Parallel |----->| | | | - | | | | | | - +----------+ | / | | - |/ +-----------+ - -- MIPI: The MIPI interface, receiving data from a MIPI CSI-2 camera sensor. - -- Parallel: The parallel interface, receiving data from a parallel sensor. - -- ISP: The ISP, processing raw Bayer data from an image sensor and producing - YUV frames. - - -Topology --------- - -The media controller pipeline graph is as follows: - -.. _starfive_camss_graph: - -.. kernel-figure:: starfive_camss_graph.dot - :alt: starfive_camss_graph.dot - :align: center - -The driver has 2 video devices: - -- capture_raw: The capture device, capturing image data directly from a sensor. -- capture_yuv: The capture device, capturing YUV frame data processed by the - ISP module - -The driver has 3 subdevices: - -- stf_isp: is responsible for all the isp operations, outputs YUV frames. -- cdns_csi2rx: a CSI-2 bridge supporting up to 4 CSI lanes in input, and 4 - different pixel streams in output. -- imx219: an image sensor, image data is sent through MIPI CSI-2. diff --git a/Documentation/admin-guide/media/starfive_camss_graph.dot b/Documentation/admin-guide/media/starfive_camss_graph.dot deleted file mode 100644 index 8eff1f161ac7..000000000000 --- a/Documentation/admin-guide/media/starfive_camss_graph.dot +++ /dev/null @@ -1,12 +0,0 @@ -digraph board { - rankdir=TB - n00000001 [label="{{ 0} | stf_isp\n/dev/v4l-subdev0 | { 1}}", shape=Mrecord, style=filled, fillcolor=green] - n00000001:port1 -> n00000008 [style=dashed] - n00000004 [label="capture_raw\n/dev/video0", shape=box, style=filled, fillcolor=yellow] - n00000008 [label="capture_yuv\n/dev/video1", shape=box, style=filled, fillcolor=yellow] - n0000000e [label="{{ 0} | cdns_csi2rx.19800000.csi-bridge\n | { 1 | 2 | 3 | 4}}", shape=Mrecord, style=filled, fillcolor=green] - n0000000e:port1 -> n00000001:port0 [style=dashed] - n0000000e:port1 -> n00000004 [style=dashed] - n00000018 [label="{{} | imx219 6-0010\n/dev/v4l-subdev1 | { 0}}", shape=Mrecord, style=filled, fillcolor=green] - n00000018:port0 -> n0000000e:port0 [style=bold] -} diff --git a/Documentation/admin-guide/media/v4l-drivers.rst b/Documentation/admin-guide/media/v4l-drivers.rst index 393f83e8dc4d..d31da8e0a54f 100644 --- a/Documentation/admin-guide/media/v4l-drivers.rst +++ b/Documentation/admin-guide/media/v4l-drivers.rst @@ -33,7 +33,6 @@ Video4Linux (V4L) driver-specific documentation si470x si4713 si476x - starfive_camss vimc visl vivid diff --git a/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml b/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml index d3329e991d16..ae48dd4ab589 100644 --- a/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml +++ b/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml @@ -8,7 +8,7 @@ title: Allied Vision Alvium Camera maintainers: - Tommaso Merciai - - Martin Hecht + - Martin Hecht allOf: - $ref: /schemas/media/video-interface-devices.yaml# diff --git a/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml index dffd23ca4839..e896f4db2421 100644 --- a/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml +++ b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml @@ -17,7 +17,9 @@ description: |- properties: compatible: - const: onnn,mt9m114 + enum: + - onnn,mt9m114 + - aptina,mi1040 reg: description: I2C device address diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml new file mode 100644 index 000000000000..6f2017c75125 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov08d10.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Omnivision OV08D10 1/4-Inch 8MP CMOS color image sensor + +maintainers: + - Matthias Fend + +description: + The Omnivision OV08D10 is a 1/4-Inch 8MP CMOS color image sensor with an + active array size of 3280 x 2464. It is programmable through I2C + interface. Image data is transmitted via MIPI CSI-2 using 2 lanes. + +allOf: + - $ref: /schemas/media/video-interface-devices.yaml# + +properties: + compatible: + const: ovti,ov08d10 + + reg: + maxItems: 1 + + clocks: + description: MCLK input clock (6 - 27 MHz) + maxItems: 1 + + reset-gpios: + description: Active low XSHUTDN pin + maxItems: 1 + + dovdd-supply: + description: IO power supply (1.8V) + + avdd-supply: + description: Analog power supply (2.8V) + + dvdd-supply: + description: Core power supply (1.2V) + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + required: + - data-lanes + - link-frequencies + + required: + - endpoint + +required: + - compatible + - reg + - clocks + - port + +unevaluatedProperties: false + +examples: + - | + #include + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@36 { + compatible = "ovti,ov08d10"; + reg = <0x36>; + + clocks = <&ov08d10_clk>; + + dovdd-supply = <&ov08d10_vdddo_1v8>; + avdd-supply = <&ov08d10_vdda_2v8>; + dvdd-supply = <&ov08d10_vddd_1v2>; + + orientation = <2>; + rotation = <0>; + + reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + + port { + ov08d10_output: endpoint { + data-lanes = <1 2>; + link-frequencies = /bits/ 64 <360000000 720000000>; + remote-endpoint = <&csi_input>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2732.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2732.yaml new file mode 100644 index 000000000000..814fc568c550 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2732.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov2732.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OmniVision OV2732 Image Sensor + +maintainers: + - Walter Werner Schneider + +description: + The OmniVision OV2732 is a 2MP (1920x1080) color CMOS image sensor controlled + through an I2C-compatible SCCB bus. + +properties: + compatible: + const: ovti,ov2732 + + reg: + maxItems: 1 + + clocks: + items: + - description: XVCLK clock + + avdd-supply: + description: Analog Domain Power Supply + + dovdd-supply: + description: I/O Domain Power Supply + + dvdd-supply: + description: Digital Domain Power Supply + + powerdown-gpios: + maxItems: 1 + description: Reference to the GPIO connected to the pwdn pin. Active low. + + reset-gpios: + maxItems: 1 + description: Reference to the GPIO connected to the reset pin. Active low. + + port: + description: MIPI CSI-2 transmitter port + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + items: + - const: 1 + - const: 2 + + required: + - data-lanes + - link-frequencies + +required: + - compatible + - reg + - clocks + - avdd-supply + - dovdd-supply + - dvdd-supply + - port + +additionalProperties: false + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ov2732: camera@36 { + compatible = "ovti,ov2732"; + reg = <0x36>; + clocks = <&ov2732_clk>; + + avdd-supply = <&ov2732_avdd>; + dovdd-supply = <&ov2732_dovdd>; + dvdd-supply = <&ov2732_dvdd>; + + powerdown-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; + reset-gpios = <&gpio0 8 GPIO_ACTIVE_LOW>; + + port { + camera_out: endpoint { + data-lanes = <1 2>; + link-frequencies = /bits/ 64 <360000000>; + remote-endpoint = <&mipi_in_camera>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml index fa71f24823f2..d0f577363f93 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml @@ -18,6 +18,9 @@ description: |- through I2C and two-wire SCCB. The sensor output is available via CSI-2 serial data output (up to 4-lane). +allOf: + - $ref: /schemas/media/video-interface-devices.yaml# + properties: compatible: const: ovti,ov8856 @@ -57,6 +60,9 @@ properties: This corresponds to the hardware pin XSHUTDOWN which is physically active low. + orientation: true + rotation: true + port: $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml new file mode 100644 index 000000000000..6050d7e7dcfe --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml @@ -0,0 +1,111 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/sony,imx355.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sony IMX355 Sensor + +maintainers: + - Richard Acayan + +description: + The IMX355 sensor is a 3280x2464 image sensor, commonly found as the front + camera in smartphones. + +allOf: + - $ref: /schemas/media/video-interface-devices.yaml# + +properties: + compatible: + const: sony,imx355 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + avdd-supply: + description: Analog power supply. + + dvdd-supply: + description: Digital power supply. + + dovdd-supply: + description: Interface power supply. + + reset-gpios: + description: Reset GPIO (active low). + maxItems: 1 + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 4 + maxItems: 4 + + required: + - link-frequencies + + required: + - endpoint + +required: + - compatible + - reg + - clocks + - avdd-supply + - dvdd-supply + - dovdd-supply + - port + +unevaluatedProperties: false + +examples: + - | + #include + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + camera@1a { + compatible = "sony,imx355"; + reg = <0x1a>; + + clocks = <&camcc CAM_CC_MCLK2_CLK>; + + assigned-clocks = <&camcc CAM_CC_MCLK2_CLK>; + assigned-clock-rates = <24000000>; + + reset-gpios = <&tlmm 9 GPIO_ACTIVE_LOW>; + + avdd-supply = <&cam_front_ldo>; + dvdd-supply = <&cam_front_ldo>; + dovdd-supply = <&cam_vio_ldo>; + + pinctrl-names = "default"; + pinctrl-0 = <&cam_front_default>; + + rotation = <270>; + orientation = <0>; + + port { + cam_front_endpoint: endpoint { + data-lanes = <1 2 3 4>; + link-frequencies = /bits/ 64 <360000000>; + remote-endpoint = <&camss_endpoint1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml index 0539d52de422..8e2b82d6dc81 100644 --- a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml @@ -13,12 +13,10 @@ description: The TI DS90UB9XX devices are FPD-Link video deserializers with I2C and GPIO forwarding. -allOf: - - $ref: /schemas/i2c/i2c-atr.yaml# - properties: compatible: enum: + - ti,ds90ub954-q1 - ti,ds90ub960-q1 - ti,ds90ub9702-q1 @@ -125,109 +123,9 @@ properties: ports: $ref: /schemas/graph.yaml#/properties/ports - - properties: - port@0: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: FPD-Link input 0 - - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - description: - Endpoint for FPD-Link port. If the RX mode for this port is RAW, - hsync-active and vsync-active must be defined. - - port@1: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: FPD-Link input 1 - - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - description: - Endpoint for FPD-Link port. If the RX mode for this port is RAW, - hsync-active and vsync-active must be defined. - - port@2: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: FPD-Link input 2 - - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - description: - Endpoint for FPD-Link port. If the RX mode for this port is RAW, - hsync-active and vsync-active must be defined. - - port@3: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: FPD-Link input 3 - - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - description: - Endpoint for FPD-Link port. If the RX mode for this port is RAW, - hsync-active and vsync-active must be defined. - - port@4: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: CSI-2 Output 0 - - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - - properties: - data-lanes: - minItems: 1 - maxItems: 4 - link-frequencies: - maxItems: 1 - - required: - - data-lanes - - link-frequencies - - port@5: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: CSI-2 Output 1 - - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - - properties: - data-lanes: - minItems: 1 - maxItems: 4 - link-frequencies: - maxItems: 1 - - required: - - data-lanes - - link-frequencies - - required: - - port@0 - - port@1 - - port@2 - - port@3 - - port@4 - - port@5 + description: + Ports represent FPD-Link inputs to the deserializer and CSI TX outputs + from the deserializer. The number of ports is model-dependent. required: - compatible @@ -236,6 +134,117 @@ required: - clock-names - ports +$defs: + FPDLink-input-port: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: FPD-Link input + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + description: + Endpoint for FPD-Link port. If the RX mode for this port is RAW, + hsync-active and vsync-active must be defined. + + CSI2-output-port: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: CSI-2 Output + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + link-frequencies: + maxItems: 1 + + required: + - data-lanes + - link-frequencies + +allOf: + - $ref: /schemas/i2c/i2c-atr.yaml# + - if: + properties: + compatible: + contains: + enum: + - ti,ds90ub960-q1 + - ti,ds90ub9702-q1 + then: + properties: + ports: + properties: + port@0: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 0 + + port@1: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 1 + + port@2: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 2 + + port@3: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 3 + + port@4: + $ref: '#/$defs/CSI2-output-port' + description: CSI-2 Output 0 + + port@5: + $ref: '#/$defs/CSI2-output-port' + description: CSI-2 Output 1 + + required: + - port@0 + - port@1 + - port@2 + - port@3 + - port@4 + - port@5 + + - if: + properties: + compatible: + contains: + const: ti,ds90ub954-q1 + then: + properties: + ports: + properties: + port@0: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 0 + + port@1: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 1 + + port@2: + $ref: '#/$defs/CSI2-output-port' + description: CSI-2 Output 0 + + required: + - port@0 + - port@1 + - port@2 + + links: + properties: + link@2: false + link@3: false + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml index 001a0d9b71e0..b59c4ce30b8b 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml @@ -24,6 +24,7 @@ properties: - fsl,imx8ulp-isi - fsl,imx91-isi - fsl,imx93-isi + - fsl,imx95-isi reg: maxItems: 1 @@ -50,7 +51,7 @@ properties: interrupts: description: Processing pipeline interrupts, one per pipeline minItems: 1 - maxItems: 2 + maxItems: 8 power-domains: maxItems: 1 @@ -99,6 +100,7 @@ allOf: then: properties: interrupts: + minItems: 2 maxItems: 2 ports: properties: @@ -120,6 +122,29 @@ allOf: required: - fsl,blk-ctrl + - if: + properties: + compatible: + contains: + const: fsl,imx95-isi + then: + properties: + interrupts: + minItems: 8 + ports: + properties: + port@0: + description: Pixel Link Slave 0 + port@1: + description: Pixel Link Slave 1 + port@2: + description: MIPI CSI-2 RX 0 + port@3: + description: MIPI CSI-2 RX 1 + required: + - port@2 + - port@3 + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml index 3389bab266a9..4fcfc4fd3565 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml @@ -20,6 +20,7 @@ properties: - enum: - fsl,imx8mq-mipi-csi2 - fsl,imx8qxp-mipi-csi2 + - fsl,imx8ulp-mipi-csi2 - items: - const: fsl,imx8qm-mipi-csi2 - const: fsl,imx8qxp-mipi-csi2 @@ -39,12 +40,16 @@ properties: clock that the RX DPHY receives. - description: ui is the pixel clock (phy_ref up to 333Mhz). See the reference manual for details. + - description: pclk is clock for csr APB interface. + minItems: 3 clock-names: items: - const: core - const: esc - const: ui + - const: pclk + minItems: 3 power-domains: maxItems: 1 @@ -130,21 +135,53 @@ allOf: compatible: contains: enum: - - fsl,imx8qxp-mipi-csi2 + - fsl,imx8mq-mipi-csi2 + then: + properties: + reg: + maxItems: 1 + resets: + minItems: 3 + clocks: + maxItems: 3 + clock-names: + maxItems: 3 + required: + - fsl,mipi-phy-gpr + + - if: + properties: + compatible: + contains: + const: fsl,imx8qxp-mipi-csi2 then: properties: reg: minItems: 2 resets: maxItems: 1 - else: + clocks: + maxItems: 3 + clock-names: + maxItems: 3 + + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8ulp-mipi-csi2 + then: properties: reg: - maxItems: 1 + minItems: 2 resets: - minItems: 3 - required: - - fsl,mipi-phy-gpr + minItems: 2 + maxItems: 2 + clocks: + minItems: 4 + clock-names: + minItems: 4 additionalProperties: false diff --git a/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml index 46cc7fff1599..084b65740d53 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml @@ -124,7 +124,6 @@ properties: maxItems: 4 required: - - clock-lanes - data-lanes port@1: @@ -147,7 +146,6 @@ properties: maxItems: 4 required: - - clock-lanes - data-lanes port@2: @@ -170,7 +168,6 @@ properties: maxItems: 4 required: - - clock-lanes - data-lanes required: diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml index 2c2bd87582eb..4ac4a3b6f406 100644 --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml @@ -17,6 +17,7 @@ description: properties: compatible: enum: + - fsl,imx93-mipi-csi2 - rockchip,rk3568-mipi-csi2 reg: @@ -26,14 +27,23 @@ properties: items: - description: Interrupt that signals changes in CSI2HOST_ERR1. - description: Interrupt that signals changes in CSI2HOST_ERR2. + minItems: 1 interrupt-names: items: - const: err1 - const: err2 + minItems: 1 clocks: - maxItems: 1 + minItems: 1 + maxItems: 2 + + clock-names: + items: + - const: per + - const: pixel + minItems: 1 phys: maxItems: 1 @@ -88,10 +98,43 @@ required: - phys - ports - power-domains - - resets additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,rk3568-mipi-csi2 + then: + properties: + interrupts: + minItems: 2 + interrupt-names: + minItems: 2 + clocks: + maxItems: 1 + clock-names: + maxItems: 1 + required: + - resets + + - if: + properties: + compatible: + contains: + const: fsl,imx93-mipi-csi2 + then: + properties: + interrupts: + maxItems: 1 + interrupt-names: false + clocks: + minItems: 2 + clock-names: + minItems: 2 + examples: - | #include diff --git a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml index 809fda45b3bd..42022401d0ff 100644 --- a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml +++ b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml @@ -28,16 +28,20 @@ properties: reg: minItems: 1 - items: - - description: The function configuration registers base - - description: The link table configuration registers base - - description: The cache configuration registers base + maxItems: 3 reg-names: - items: - - const: function - - const: link - - const: cache + oneOf: + - items: + - const: link + - const: function + - const: cache + - items: + - const: function + - const: link + - const: cache + deprecated: true + description: Use link,function,cache block order instead. interrupts: maxItems: 1 @@ -123,6 +127,8 @@ allOf: minItems: 5 reset-names: minItems: 5 + required: + - reg-names else: properties: reg: diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml index 34147127192f..d9fbb90b0977 100644 --- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml @@ -27,11 +27,14 @@ properties: - const: mclk dmas: - maxItems: 1 + minItems: 1 + maxItems: 2 dma-names: items: - const: tx + - const: mdma_tx + minItems: 1 resets: maxItems: 1 @@ -40,6 +43,15 @@ properties: minItems: 1 maxItems: 2 + power-domains: + maxItems: 1 + + sram: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to a reserved SRAM region which is used as temporary + storage memory between DMA and MDMA engines. + port: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/media/starfive,jh7110-camss.yaml b/Documentation/devicetree/bindings/media/starfive,jh7110-camss.yaml deleted file mode 100644 index c66586d90fa2..000000000000 --- a/Documentation/devicetree/bindings/media/starfive,jh7110-camss.yaml +++ /dev/null @@ -1,180 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/media/starfive,jh7110-camss.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Starfive SoC CAMSS ISP - -maintainers: - - Jack Zhu - - Changhuang Liang - -description: - The Starfive CAMSS ISP is a Camera interface for Starfive JH7110 SoC. It - consists of a VIN controller (Video In Controller, a top-level control unit) - and an ISP. - -properties: - compatible: - const: starfive,jh7110-camss - - reg: - maxItems: 2 - - reg-names: - items: - - const: syscon - - const: isp - - clocks: - maxItems: 7 - - clock-names: - items: - - const: apb_func - - const: wrapper_clk_c - - const: dvp_inv - - const: axiwr - - const: mipi_rx0_pxl - - const: ispcore_2x - - const: isp_axi - - resets: - maxItems: 6 - - reset-names: - items: - - const: wrapper_p - - const: wrapper_c - - const: axird - - const: axiwr - - const: isp_top_n - - const: isp_top_axi - - power-domains: - items: - - description: JH7110 ISP Power Domain Switch Controller. - - interrupts: - maxItems: 4 - - ports: - $ref: /schemas/graph.yaml#/properties/ports - - properties: - port@0: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: Input port for receiving DVP data. - - properties: - endpoint: - $ref: video-interfaces.yaml# - unevaluatedProperties: false - - properties: - bus-type: - enum: [5, 6] - - bus-width: - enum: [8, 10, 12] - - data-shift: - enum: [0, 2] - default: 0 - - hsync-active: - enum: [0, 1] - default: 1 - - vsync-active: - enum: [0, 1] - default: 1 - - required: - - bus-type - - bus-width - - port@1: - $ref: /schemas/graph.yaml#/properties/port - description: Input port for receiving CSI data. - - required: - - port@0 - - port@1 - -required: - - compatible - - reg - - reg-names - - clocks - - clock-names - - resets - - reset-names - - power-domains - - interrupts - - ports - -additionalProperties: false - -examples: - - | - isp@19840000 { - compatible = "starfive,jh7110-camss"; - reg = <0x19840000 0x10000>, - <0x19870000 0x30000>; - reg-names = "syscon", "isp"; - clocks = <&ispcrg 0>, - <&ispcrg 13>, - <&ispcrg 2>, - <&ispcrg 12>, - <&ispcrg 1>, - <&syscrg 51>, - <&syscrg 52>; - clock-names = "apb_func", - "wrapper_clk_c", - "dvp_inv", - "axiwr", - "mipi_rx0_pxl", - "ispcore_2x", - "isp_axi"; - resets = <&ispcrg 0>, - <&ispcrg 1>, - <&ispcrg 10>, - <&ispcrg 11>, - <&syscrg 41>, - <&syscrg 42>; - reset-names = "wrapper_p", - "wrapper_c", - "axird", - "axiwr", - "isp_top_n", - "isp_top_axi"; - power-domains = <&pwrc 5>; - interrupts = <92>, <87>, <88>, <90>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - vin_from_sc2235: endpoint { - remote-endpoint = <&sc2235_to_vin>; - bus-type = <5>; - bus-width = <8>; - data-shift = <2>; - hsync-active = <1>; - vsync-active = <0>; - pclk-sample = <1>; - }; - }; - - port@1 { - reg = <1>; - vin_from_csi2rx: endpoint { - remote-endpoint = <&csi2rx_to_vin>; - }; - }; - }; - }; diff --git a/Documentation/driver-api/media/index.rst b/Documentation/driver-api/media/index.rst index d5593182a3f9..08fc2cfc07a3 100644 --- a/Documentation/driver-api/media/index.rst +++ b/Documentation/driver-api/media/index.rst @@ -26,6 +26,7 @@ Documentation/userspace-api/media/index.rst :numbered: maintainer-entry-profile + media-committers v4l2-core dtv-core diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst index 2127e5b15e8f..c5c00c66d85c 100644 --- a/Documentation/driver-api/media/maintainer-entry-profile.rst +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst @@ -1,45 +1,328 @@ +.. SPDX-License-Identifier: GPL-2.0 + Media Subsystem Profile ======================= Overview -------- -The media subsystem covers support for a variety of devices: stream -capture, analog and digital TV streams, cameras, remote controllers, HDMI CEC -and media pipeline control. +The Linux Media Community (aka: the LinuxTV Community) is formed by +developers working on Linux Kernel Media Subsystem, together with users +who also play an important role in testing the code. -It covers, mainly, the contents of those directories: +The Media Subsystem has code to support a wide variety of media-related +devices: stream capture, analog and digital TV streams, cameras, +video codecs, video processing (resizers, etc.), radio, remote controllers, +HDMI CEC and media pipeline control. + +The Media Subsystem consists of the following directories in the kernel +tree: - drivers/media - drivers/staging/media + - include/media + - Documentation/devicetree/bindings/media/\ [1]_ - Documentation/admin-guide/media - Documentation/driver-api/media - Documentation/userspace-api/media - - Documentation/devicetree/bindings/media/\ [1]_ - - include/media .. [1] Device tree bindings are maintained by the OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS maintainers (see the MAINTAINERS file). So, changes there must be reviewed - by them before being merged via the media subsystem's development + by them before being merged into the media subsystem's development tree. Both media userspace and Kernel APIs are documented and the documentation must be kept in sync with the API changes. It means that all patches that add new features to the subsystem must also bring changes to the -corresponding API files. +corresponding API documentation. -Due to the size and wide scope of the media subsystem, media's -maintainership model is to have sub-maintainers that have a broad -knowledge of a specific aspect of the subsystem. It is the sub-maintainers' -task to review the patches, providing feedback to users if the patches are -following the subsystem rules and are properly using the media kernel and -userspace APIs. +Media Maintainers +----------------- -Patches for the media subsystem must be sent to the media mailing list -at linux-media@vger.kernel.org as plain text only e-mail. Emails with -HTML will be automatically rejected by the mail server. It could be wise -to also copy the sub-maintainer(s). +Media Maintainers are not just people capable of writing code, but they +are developers who have demonstrated their ability to collaborate with +the team, get the most knowledgeable people to review code, contribute +high-quality code, and follow through to fix issues (in code or tests). + +Due to the size and wide scope of the media subsystem, multiple layers of +maintainers are required, each with their own areas of expertise: + +- **Media Driver Maintainer**: + Responsible for one or more drivers within the Media Subsystem. They + are listed in the MAINTAINERS file as maintainer for those drivers. Media + Driver Maintainers review patches for those drivers, provide feedback if + patches do not follow the subsystem rules, or are not using the + media kernel or userspace APIs correctly, or if they have poor code + quality. + + If you are the patch author, you work with other Media + Maintainers to ensure your patches are reviewed. + + Some Media Driver Maintainers have additional responsibilities. They have + been granted Patchwork access and keep + `Patchwork `_ + up to date, decide when patches are ready for merging, and create Pull + Requests for the Media Subsystem Maintainers to merge. + +- **Media Core Maintainer**: + Media Driver Maintainers with Patchwork access who are also responsible for + one or more media core frameworks. + + Core framework changes are done via consensus between the relevant Media + Core Maintainers. Media Maintainers may include core framework changes in + their Pull Requests if they are signed off by the relevant Media Core + Maintainers. + +- **Media Subsystem Maintainers**: + Media Core Maintainers who are also responsible for the subsystem as a + whole, with access to the entire subsystem. Responsible for merging Pull + Requests from other Media Maintainers. + + Userspace API/ABI changes are made via consensus among Media Subsystem + Maintainers\ [2]_. Media Maintainers may include API/ABI changes in + their Pull Requests if they are signed off by all Media Subsystem + Maintainers. + +All Media Maintainers shall agree with the Kernel development process as +described in Documentation/process/index.rst and with the Kernel development +rules in the Kernel documentation, including its code of conduct. + +Media Maintainers are often reachable via the #linux-media IRC channel at OFTC. + +.. [2] Everything that would break backward compatibility with existing + non-kernel code are API/ABI changes. This includes ioctl and sysfs + interfaces, v4l2 controls, and their behaviors. + +Patchwork Access +---------------- + +All Media Maintainers who have been granted Patchwork access shall ensure that +`Patchwork `_ +will reflect the current status, e.g. patches shall be delegated to the Media +Maintainer who is handling them and the patch status shall be updated according +to these rules: + +- ``Under Review``: Used if the patch requires a second opinion + or when it is part of a Pull Request; +- ``Superseded``: There is a newer version of the patch posted to the + mailing list. +- ``Duplicated``: There was another patch doing the same thing from someone + else that was accepted. +- ``Not Applicable``: Use for patch series that are not merged at media.git + tree (e.g. drm, dmabuf, upstream merge, etc.) but were cross-posted to the + linux-media mailing list. +- ``Accepted``: Once a patch is merged in the multi-committer tree. Only Media + Maintainers with commit rights are allowed to set this state. + +If Media Maintainers decide not to accept a patch, they should reply to the +patch authors by e‑mail, explaining why it is not accepted, and +update `Patchwork `_ +accordingly with one of the following statuses: + +- ``Changes Requested``: if a new revision was requested; +- ``Rejected``: if the proposed change is not acceptable at all. + +.. Note:: + + Patchwork supports a couple of clients to help semi-automate + status updates via its REST interface: + + https://patchwork.readthedocs.io/en/latest/usage/clients/ + +For patches that fall within their area of responsibility a Media Maintainer +also decides when those patches are ready for merging, and create Pull Requests +for the Media Subsystem Maintainers to merge. + +The most important aspect of becoming a Media Maintainer with Patchwork access +is that you have demonstrated an ability to give good code reviews. We value +your ability to deliver thorough, constructive code reviews. + +As such, potential maintainers must earn enough credibility and trust from the +Linux Media Community. To do that, developers shall be familiar with the open +source model and have been active in the Linux Kernel community for some time, +and, in particular, in the media subsystem. + +In addition to actually making the code changes, you are basically +demonstrating your: + +- commitment to the project; +- ability to collaborate with the team and communicate well; +- understanding of how upstream and the Linux Media Community work + (policies, processes for testing, code review, ...) +- reasonable knowledge about: + + - the Kernel development process: + Documentation/process/index.rst + + - the Media development profile: + Documentation/driver-api/media/maintainer-entry-profile.rst + +- understanding of the projects' code base and coding style; +- ability to provide feedback to the patch authors; +- ability to judge when a patch might be ready for review and to submit; +- ability to write good code (last but certainly not least). + +Media Driver Maintainers that desire to get Patchwork access are encouraged +to participate at the yearly Linux Media Summit, typically co-located with +a Linux-related conference. These summits are announced on the linux-media +mailing list. + +If you are doing such tasks and have become a valued developer, an +existing Media Maintainer can nominate you to the Media Subsystem Maintainers. + +The ultimate responsibility for accepting a nominated maintainer is up to +the subsystem's maintainers. The nominated maintainer must have earned a trust +relationship with all Media Subsystem Maintainers, as, by being granted +Patchwork access, you will take over part of their maintenance tasks. + +Media Committers +---------------- + +Experienced and trusted Media Maintainers may be granted commit rights +which allow them to directly push patches to the media development tree instead +of posting a Pull Request for the Media Subsystem Maintainers. This helps +offloading some of the work of the Media Subsystem Maintainers. + +More details about Media Committers' roles and responsibilities can be +found here: :ref:`Media Committers`. + +Media development sites +----------------------- + +The `LinuxTV `_ web site hosts news about the subsystem, +together with: + +- `Wiki pages `_; +- `Patchwork `_; +- `Linux Media documentation `_; +- and more. + +The main development trees used by the media subsystem are at: + +- Stable tree: + - https://git.linuxtv.org/media.git/ + +- Media committers tree: + - https://gitlab.freedesktop.org/linux-media/media-committers.git + + Please note that it can be rebased, although only as a last resort. + +- Media development trees, including apps and CI: + + - https://git.linuxtv.org/ + - https://gitlab.freedesktop.org/linux-media/ + + +.. _Media development workflow: + +Media development workflow +++++++++++++++++++++++++++ + +All changes for the media subsystem shall be sent first as e-mails to the +media mailing list, following the process documented at +Documentation/process/index.rst. + +It means that patches shall be submitted as plain text only via e-mail to +linux-media@vger.kernel.org (aka: LMML). While subscription is not mandatory, +you can find details about how to subscribe to it and to see its archives at: + + https://subspace.kernel.org/vger.kernel.org.html + +Emails with HTML will be automatically rejected by the mail server. + +It could be wise to also copy the relevant Media Maintainer(s). You should use +``scripts/get_maintainers.pl`` to identify whom else needs to be copied. +Please always copy driver's authors and maintainers. + +To minimize the chance of merge conflicts for your patch series, and make it +easier to backport patches to stable Kernels, we recommend that you use the +following baseline for your patch series: + +1. Features for the next mainline release: + + - baseline shall be the ``media-committers.git next`` branch; + +2. Bug fixes for the next mainline release: + + - baseline shall be the ``media-committers.git next`` branch. If the + changes depend on a fix from the ``media-committers.git fixes`` + branch, then you can use that as baseline. + +3. Bug fixes for the current mainline release (-rcX): + + - baseline shall be the latest mainline -rcX release or the + ``media-committers.git fixes`` branch if changes depend on a mainline + fix that is not yet merged; + +.. Note:: + + See https://www.kernel.org/category/releases.html for an overview + about Kernel release types. + +Patches with fixes shall have: + +- a ``Fixes:`` tag pointing to the first commit that introduced the bug; +- when applicable, a ``Cc: stable@vger.kernel.org``. + +Patches that were fixing bugs publicly reported by someone at the +linux-media@vger.kernel.org mailing list shall have: + +- a ``Reported-by:`` tag immediately followed by a ``Closes:`` tag. + +Patches that change API shall update documentation accordingly at the +same patch series. + +See Documentation/process/index.rst for more details about e-mail submission. + +Once a patch is submitted, it may follow either one of the following +workflows: + +a. Media Maintainers' workflow: Media Maintainers post the Pull Requests, + which are handled by the Media Subsystem Maintainers:: + + +-------+ +------------+ +------+ +-------+ +---------------------+ + |e-mail |-->|picked up by|-->|code |-->|pull |-->|Subsystem Maintainers| + |to LMML| |Patchwork | |review| |request| |merge in | + | | | | | | | | |media-committers.git | + +-------+ +------------+ +------+ +-------+ +---------------------+ + + For this workflow, Pull Requests are generated by Media Maintainers with + Patchwork access. If you do not have Patchwork access, then please don't + submit Pull Requests, as they will not be processed. + +b. Media Committers' workflow: patches are handled by Media Maintainers with + commit rights:: + + +-------+ +------------+ +------+ +--------------------------+ + |e-mail |-->|picked up by|-->|code |-->|Media Committers merge in | + |to LMML| |Patchwork | |review| |media-committers.git | + +-------+ +------------+ +------+ +--------------------------+ + +When patches are picked up by +`Patchwork `_ +and when merged at media-committers, Media CI bots will check for errors and +may provide e-mail feedback about patch problems. When this happens, the patch +submitter must fix them or explain why the errors are false positives. + +Patches will only be moved to the next stage in these two workflows if they +pass on Media CI or if there are false-positives in the Media CI reports. + +For both workflows, all patches shall be properly reviewed at +linux-media@vger.kernel.org (LMML) before being merged in +``media-committers.git``. Media patches will be reviewed in a timely manner +by the maintainers and reviewers as listed in the MAINTAINERS file. + +Media Maintainers shall request reviews from other Media Maintainers and +developers where applicable, i.e. because those developers have more +knowledge about some areas that are changed by a patch. + +There shall be no open issues or unresolved or conflicting feedback +from anyone. Clear them up first. Defer to the Media Subsystem +Maintainers if needed. + +Failures during e-mail submission ++++++++++++++++++++++++++++++++++ Media's workflow is heavily based on Patchwork, meaning that, once a patch is submitted, the e-mail will first be accepted by the mailing list @@ -47,51 +330,107 @@ server, and, after a while, it should appear at: - https://patchwork.linuxtv.org/project/linux-media/list/ -If it doesn't automatically appear there after a few minutes, then +If it doesn't automatically appear there after some time [3]_, then probably something went wrong on your submission. Please check if the -email is in plain text\ [2]_ only and if your emailer is not mangling +email is in plain text\ [4]_ only and if your emailer is not mangling whitespaces before complaining or submitting them again. -You can check if the mailing list server accepted your patch, by looking at: +To troubleshoot problems, you should first check if the mailing list +server has accepted your patch, by looking at: - https://lore.kernel.org/linux-media/ -.. [2] If your email contains HTML, the mailing list server will simply +If the patch is there and not at +`Patchwork `_, +it is likely that your e-mailer mangled the patch. Patchwork internally +has logic that checks if the received e-mail contains a valid patch. +Any whitespace and new line breakages mangling the patch won't be recognized by +`Patchwork `_, +and such a patch will be rejected. + +.. [3] It usually takes a few minutes for the patch to arrive, but + the e-mail server may be busy, so it may take a longer time + for a patch to be picked by + `Patchwork `_. + +.. [4] If your email contains HTML, the mailing list server will simply drop it, without any further notice. +.. _media-developers-gpg: -Media maintainers -+++++++++++++++++ +Authentication for pull and merge requests +++++++++++++++++++++++++++++++++++++++++++ -At the media subsystem, we have a group of senior developers that -are responsible for doing the code reviews at the drivers (also known as -sub-maintainers), and another senior developer responsible for the -subsystem as a whole. For core changes, whenever possible, multiple -media maintainers do the review. +The authenticity of developers submitting Pull Requests and merge requests +shall be validated by using the Linux Kernel Web of Trust, with PGP signing +at some moment. See: :ref:`kernel_org_trust_repository`. -The media maintainers that work on specific areas of the subsystem are: +With the Pull Request workflow, Pull Requests shall use PGP-signed tags. -- Remote Controllers (infrared): - Sean Young +With the committers' workflow, this is ensured at the time merge request +rights will be granted to the gitlab instance used by the media-committers.git +tree, after receiving the e-mail documented in +:ref:`media-committer-agreement`. -- HDMI CEC: - Hans Verkuil +For more details about PGP signing, please read +Documentation/process/maintainer-pgp-guide.rst. -- Media controller drivers: - Laurent Pinchart +Maintaining media maintainer status +----------------------------------- -- ISP, v4l2-async, v4l2-fwnode, v4l2-flash-led-class and Sensor drivers: - Sakari Ailus +See :ref:`Maintain Media Status`. -- V4L2 drivers and core V4L2 frameworks: - Hans Verkuil +List of Media Maintainers +------------------------- -The subsystem maintainer is: - Mauro Carvalho Chehab +The Media Maintainers listed here all have patchwork access and can +make Pull Requests or have commit rights. -Media maintainers may delegate a patch to other media maintainers as needed. -On such case, checkpatch's ``delegate`` field indicates who's currently -responsible for reviewing a patch. +The Media Subsystem Maintainers are: + - Mauro Carvalho Chehab + - Hans Verkuil + +The Media Core Maintainers are: + - Sakari Ailus + + - Media controller drivers + - Core media controller framework + - ISP + - sensor drivers + - v4l2-async and v4l2-fwnode core frameworks + - v4l2-flash-led-class core framework + + - Mauro Carvalho Chehab + + - DVB + + - Laurent Pinchart + + - Media controller drivers + - Core media controller framework + - ISP + + - Hans Verkuil + + - V4L2 drivers + - V4L2 and videobuf2 core frameworks + - HDMI CEC drivers + - HDMI CEC core framework + + - Sean Young + + - Remote Controller (infrared) drivers + - Remote Controller (infrared) core framework + +The Media Driver Maintainers responsible for specific areas are: + - Nicolas Dufresne + + - Codec drivers + - M2M driver not otherwise delegated + + - Bryan O'Donoghue + + - Qualcomm drivers Submit Checklist Addendum ------------------------- @@ -106,18 +445,15 @@ that should be used in order to check if the drivers are properly implementing the media APIs: ==================== ======================================================= -Type Tool +Type Utility ==================== ======================================================= -V4L2 drivers\ [3]_ ``v4l2-compliance`` +V4L2 drivers\ [5]_ ``v4l2-compliance`` V4L2 virtual drivers ``contrib/test/test-media`` CEC drivers ``cec-compliance`` ==================== ======================================================= -.. [3] The ``v4l2-compliance`` also covers the media controller usage inside - V4L2 drivers. - -Other compliance tools are under development to check other parts of the -subsystem. +.. [5] The ``v4l2-compliance`` utility also covers the media controller usage + inside V4L2 drivers. Those tests need to pass before the patches go upstream. @@ -134,6 +470,8 @@ Where the check script is:: Be sure to not introduce new warnings on your patches without a very good reason. +Please see `Media development workflow`_ for e-mail submission rules. + Style Cleanup Patches +++++++++++++++++++++ @@ -173,34 +511,35 @@ least, simply wrapping the lines. In particular, we accept lines with more than 80 columns: - on strings, as they shouldn't be broken due to line length limits; - - when a function or variable name need to have a big identifier name, - which keeps hard to honor the 80 columns limit; + - when a function or variable name needs to have a long identifier name, + which makes hard to honor the 80 columns limit; - on arithmetic expressions, when breaking lines makes them harder to read; - - when they avoid a line to end with an open parenthesis or an open + - when they avoid a line ending with an open parenthesis or an open bracket. Key Cycle Dates --------------- -New submissions can be sent at any time, but if they intend to hit the +New submissions can be sent at any time, but if they are intended to hit the next merge window they should be sent before -rc5, and ideally stabilized in the linux-media branch by -rc6. Review Cadence -------------- -Provided that your patch is at https://patchwork.linuxtv.org, it should -be sooner or later handled, so you don't need to re-submit a patch. +Provided that your patch has landed in +`Patchwork `_, it +should be sooner or later handled, so you don't need to re-submit a patch. -Except for bug fixes, we don't usually add new patches to the development -tree between -rc6 and the next -rc1. +Except for important bug fixes, we don't usually add new patches to the +development tree between -rc6 and the next -rc1. Please notice that the media subsystem is a high traffic one, so it could take a while for us to be able to review your patches. Feel free to ping if you don't get a feedback in a couple of weeks or to ask -other developers to publicly add Reviewed-by and, more importantly, +other developers to publicly add ``Reviewed-by:`` and, more importantly, ``Tested-by:`` tags. Please note that we expect a detailed description for ``Tested-by:``, -identifying what boards were used at the test and what it was tested. +identifying what boards were used during the test and what it was tested. diff --git a/Documentation/driver-api/media/media-committers.rst b/Documentation/driver-api/media/media-committers.rst new file mode 100644 index 000000000000..a905856f6a61 --- /dev/null +++ b/Documentation/driver-api/media/media-committers.rst @@ -0,0 +1,203 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _Media Committers: + +Media Committers +================ + +Who is a Media Committer? +------------------------- + +A Media Committer is a Media Maintainer with patchwork access who has been +granted commit access to push patches from other developers and their own +patches to the +`media-committers `_ +tree. + +These commit rights are granted with expectation of responsibility: +committers are people who care about the Linux Kernel as a whole and +about the Linux media subsystem and want to advance its development. It +is also based on a trust relationship among other committers, maintainers +and the Linux Media community. + +As Media Committer you have the following additional responsibilities: + +1. Patches you authored must have a ``Signed-off-by``, ``Reviewed-by`` + or ``Acked-by`` from another Media Maintainer; +2. If a patch introduces a regression, then that must be corrected as soon + as possible. Typically the patch is either reverted, or an additional + patch is committed to fix the regression; +3. If patches are fixing bugs against already released Kernels, including + the reverts mentioned above, the Media Committer shall add the needed + tags. Please see :ref:`Media development workflow` for more details. +4. All Media Committers are responsible for maintaining + `Patchwork `_, + updating the state of the patches they review or merge. + + +Becoming a Media Committer +-------------------------- + +Existing Media Committers can nominate a Media Maintainer to be granted +commit rights. The Media Maintainer must have patchwork access, +have been reviewing patches from third parties for some time, and has +demonstrated a good understanding of the maintainer's duties and processes. + +The ultimate responsibility for accepting a nominated committer is up to +the Media Subsystem Maintainers. The nominated committer must have earned a +trust relationship with all Media Subsystem Maintainers, as, by granting you +commit rights, part of their responsibilities are handed over to you. + +Due to that, to become a Media Committer, a consensus between all Media +Subsystem Maintainers is required. + +.. Note:: + + In order to preserve/protect the developers that could have their commit + rights granted, denied or removed as well as the subsystem maintainers who + have the task to accept or deny commit rights, all communication related to + changing commit rights should happen in private as much as possible. + +.. _media-committer-agreement: + +Media Committer's agreement +--------------------------- + +Once a nominated committer is accepted by all Media Subsystem Maintainers, +they will ask if the developer is interested in the nomination and discuss +what area(s) of the media subsystem the committer will be responsible for. +Those areas will typically be the same as the areas that the nominated +committer is already maintaining. + +When the developer accepts being a committer, the new committer shall +explicitly accept the Kernel development policies described under its +Documentation/, and in particular to the rules in this document, by writing +an e-mail to media-committers@linuxtv.org, with a declaration of intent +following the model below:: + + I, John Doe, would like to change my status to: Committer + + As Media Maintainer I accept commit rights for the following areas of + the media subsystem: + + ... + + For the purpose of committing patches to the media-committers tree, + I'll be using my user https://gitlab.freedesktop.org/users/. + +Followed by a formal declaration of agreement with the Kernel development +rules:: + + I agree to follow the Kernel development rules described at: + + https://www.kernel.org/doc/html/latest/driver-api/media/media-committers.rst + + and to the Linux Kernel development process rules. + + I agree to abide by the Code of Conduct as documented in: + https://www.kernel.org/doc/html/latest/process/code-of-conduct.rst + + I am aware that I can, at any point of time, retire. In that case, I will + send an e-mail to notify the Media Subsystem Maintainers for them to revoke + my commit rights. + + I am aware that the Kernel development rules change over time. + By doing a new push to media-committers tree, I understand that I agree + to follow the rules in effect at the time of the commit. + +That e-mail shall be signed via the Kernel Web of trust with a PGP key cross +signed by other Kernel and media developers. As described at +:ref:`media-developers-gpg`, the PGP signature, together with the gitlab user +security are fundamental components that ensure the authenticity of the merge +requests that will happen at the media-committers.git tree. + +In case the kernel development process changes, by merging new commits to the +`media-committers tree `_, +the Media Committer implicitly declares their agreement with the latest +version of the documented process including the contents of this file. + +If a Media Committer decides to retire, it is the committer's duty to +notify the Media Subsystem Maintainers about that decision. + +.. note:: + + 1. Changes to the kernel media development process shall be announced in + the media-committers mailing list with a reasonable review period. All + committers are automatically subscribed to that mailing list; + 2. Due to the distributed nature of the Kernel development, it is + possible that kernel development process changes may end being + reviewed/merged at the Linux Docs and/or at the Linux Kernel mailing + lists, especially for the contents under Documentation/process and for + trivial typo fixes. + +Media Core Committers +--------------------- + +A Media Core Committer is a Media Core Maintainer with commit rights. + +As described in Documentation/driver-api/media/maintainer-entry-profile.rst, +a Media Core Maintainer maintains media core frameworks as well, besides +just drivers, and so is allowed to change core files and the media subsystem's +Kernel API. The extent of the core committer's grants will be detailed by the +Media Subsystem Maintainers when they nominate a Media Core Committer. + +Existing Media Committers may become Media Core Committers and vice versa. +Such decisions will be taken in consensus among the Media Subsystem +Maintainers. + +Media committers rules +---------------------- + +Media committers shall do their best efforts to avoid merging patches that +would break any existing drivers. If it breaks, fixup or revert patches +shall be merged as soon as possible, aiming to be merged at the same Kernel +cycle the bug is reported. + +Media committers shall behave accordingly to the rights granted by +the Media Subsystem Maintainers, especially with regards of the scope of changes +they may apply directly at the media-committers tree. That scope can +change over time on a mutual agreement between Media Committers and +Media Subsystem Maintainers. + +The Media Committer workflow is described at :ref:`Media development workflow`. + +.. _Maintain Media Status: + +Maintaining Media Maintainer or Committer status +------------------------------------------------ + +A community of maintainers working together to move the Linux Kernel +forward is essential to creating successful projects that are rewarding +to work on. If there are problems or disagreements within the community, +they can usually be solved through healthy discussion and debate. + +In the unhappy event that a Media Maintainer or Committer continues to +disregard good citizenship (or actively disrupts the project), we may need +to revoke that person's status. In such cases, if someone suggests the +revocation with a good reason, then after discussing this among the Media +Maintainers, the final decision is taken by the Media Subsystem Maintainers. + +As the decision to become a Media Maintainer or Committer comes from a +consensus between Media Subsystem Maintainers, a single Media Subsystem +Maintainer not trusting the Media Maintainer or Committer anymore is enough +to revoke their maintenance, Patchwork grants and/or commit rights. + +Having commit rights revoked doesn't prevent Media Maintainers to keep +contributing to the subsystem either via the pull request or via email workflow +as documented at the :ref:`Media development workflow`. + +If a maintainer is inactive for more than a couple of Kernel cycles, +maintainers will try to reach you via e-mail. If not possible, they may +revoke their maintainer/patchwork and committer rights and update MAINTAINERS +file entries accordingly. If you wish to resume contributing as maintainer +later on, then contact the Media Subsystem Maintainers to ask if your +maintenance, Patchwork grants and commit rights can be restored. + +References +---------- + +Much of this was inspired by/copied from the committer policies of: + +- `Chromium `_; +- `WebKit `_; +- `Mozilla `_. diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst index bfe877a1a7e4..652dfbe64102 100644 --- a/Documentation/process/maintainer-pgp-guide.rst +++ b/Documentation/process/maintainer-pgp-guide.rst @@ -897,6 +897,8 @@ the new default in GnuPG v2). To set it, add (or modify) the trust-model tofu+pgp +.. _kernel_org_trust_repository: + Using the kernel.org web of trust repository -------------------------------------------- diff --git a/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst b/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst index 81b762ef17c4..99ffda355204 100644 --- a/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst +++ b/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst @@ -444,7 +444,7 @@ Description ~~~~~~~~~~~ A call to `AUDIO_GET_CAPABILITIES`_ returns an unsigned integer with the -following bits set according to the hardwares capabilities. +following bits set according to the hardware's capabilities. ----- diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst index 896177c5334f..c9999b929773 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -159,14 +159,18 @@ formats in memory (a raw Bayer image won't be magically converted to JPEG just by storing it to memory), there is no one-to-one correspondence between them. -The media bus pixel codes document parallel formats. Should the pixel data be -transported over a serial bus, the media bus pixel code that describes a -parallel format that transfers a sample on a single clock cycle is used. For -instance, both MEDIA_BUS_FMT_BGR888_1X24 and MEDIA_BUS_FMT_BGR888_3X8 are used -on parallel busses for transferring an 8 bits per sample BGR data, whereas on -serial busses the data in this format is only referred to using -MEDIA_BUS_FMT_BGR888_1X24. This is because there is effectively only a single -way to transport that format on the serial busses. +While the media bus pixel codes are named based on how pixels are +transmitted on parallel buses, serial buses do not define separate +codes. By convention, they use the codes that transfer a sample on a +single clock cycle, and whose bit orders from LSB to MSB correspond to +the order in which colour components are transmitted on the serial bus. +For instance, the MIPI CSI-2 24-bit RGB (RGB888) format uses the +MEDIA_BUS_FMT_RGB888_1X24 media bus code because CSI-2 transmits the +blue colour component first, followed by green and red, and +MEDIA_BUS_FMT_RGB888_1X24 defines the first bit of blue at bit 0. +While used for 24-bit RGB data on parallel buses, the +MEDIA_BUS_FMT_RGB888_3X8 or MEDIA_BUS_FMT_BGR888_1X24 codes must not be +used for CSI-2. Packed RGB Formats ^^^^^^^^^^^^^^^^^^ diff --git a/MAINTAINERS b/MAINTAINERS index e7dc9e6fad2e..8e48efe8d9fa 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -16136,8 +16136,9 @@ MEDIA INPUT INFRASTRUCTURE (V4L/DVB) M: Mauro Carvalho Chehab L: linux-media@vger.kernel.org S: Maintained +P: Documentation/driver-api/media/maintainer-entry-profile.rst W: https://linuxtv.org -Q: http://patchwork.kernel.org/project/linux-media/list/ +Q: https://patchwork.linuxtv.org/project/linux-media/list/ T: git git://linuxtv.org/media.git F: Documentation/admin-guide/media/ F: Documentation/devicetree/bindings/media/ @@ -19542,9 +19543,11 @@ F: drivers/media/i2c/ov02e10.c OMNIVISION OV08D10 SENSOR DRIVER M: Jimmy Su +R: Matthias Fend L: linux-media@vger.kernel.org S: Maintained T: git git://linuxtv.org/media.git +F: Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml F: drivers/media/i2c/ov08d10.c OMNIVISION OV08X40 SENSOR DRIVER @@ -19585,6 +19588,13 @@ T: git git://linuxtv.org/media.git F: Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml F: drivers/media/i2c/ov2685.c +OMNIVISION OV2732 SENSOR DRIVER +M: Walter Werner Schneider +L: linux-media@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/media/i2c/ovti,ov2732.yaml +F: drivers/media/i2c/ov2732.c + OMNIVISION OV2735 SENSOR DRIVER M: Hardevsinh Palaniya M: Himanshu Bhavani @@ -24586,7 +24596,6 @@ F: include/uapi/rdma/rdma_user_rxe.h SOFTLOGIC 6x10 MPEG CODEC M: Bluecherry Maintainers -M: Andrey Utkin M: Ismael Luceno L: linux-media@vger.kernel.org S: Supported @@ -25237,15 +25246,6 @@ M: Ion Badulescu S: Odd Fixes F: drivers/net/ethernet/adaptec/starfire* -STARFIVE CAMERA SUBSYSTEM DRIVER -M: Jack Zhu -M: Changhuang Liang -L: linux-media@vger.kernel.org -S: Maintained -F: Documentation/admin-guide/media/starfive_camss.rst -F: Documentation/devicetree/bindings/media/starfive,jh7110-camss.yaml -F: drivers/staging/media/starfive/camss - STARFIVE CRYPTO DRIVER M: Jia Jie Ho M: William Qiu @@ -26816,6 +26816,12 @@ F: drivers/char/toshiba.c F: include/linux/toshiba.h F: include/uapi/linux/toshiba.h +TOSHIBA T4KA3 CAMERA SENSOR DRIVER +M: Kate Hsuan +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/i2c/t4ka3.c + TOSHIBA TC358743 DRIVER M: Hans Verkuil L: linux-media@vger.kernel.org @@ -27036,8 +27042,6 @@ F: drivers/platform/x86/tuxedo/ TW5864 VIDEO4LINUX DRIVER M: Bluecherry Maintainers -M: Andrey Utkin -M: Andrey Utkin L: linux-media@vger.kernel.org S: Supported F: drivers/media/pci/tw5864/ diff --git a/drivers/gpio/gpio-tps68470.c b/drivers/gpio/gpio-tps68470.c index d4fbdf90e190..8541acecfbbe 100644 --- a/drivers/gpio/gpio-tps68470.c +++ b/drivers/gpio/gpio-tps68470.c @@ -120,6 +120,17 @@ static int tps68470_gpio_input(struct gpio_chip *gc, unsigned int offset) TPS68470_GPIO_MODE_MASK, 0x00); } +static int tps68470_enable_i2c_daisy_chain(struct gpio_chip *gc) +{ + int ret; + + ret = tps68470_gpio_input(gc, 1); + if (ret) + return ret; + + return tps68470_gpio_input(gc, 2); +} + static const char *tps68470_names[TPS68470_N_GPIO] = { "gpio.0", "gpio.1", "gpio.2", "gpio.3", "gpio.4", "gpio.5", "gpio.6", @@ -129,6 +140,7 @@ static const char *tps68470_names[TPS68470_N_GPIO] = { static int tps68470_gpio_probe(struct platform_device *pdev) { struct tps68470_gpio_data *tps68470_gpio; + int ret; tps68470_gpio = devm_kzalloc(&pdev->dev, sizeof(*tps68470_gpio), GFP_KERNEL); @@ -149,7 +161,14 @@ static int tps68470_gpio_probe(struct platform_device *pdev) tps68470_gpio->gc.base = -1; tps68470_gpio->gc.parent = &pdev->dev; - return devm_gpiochip_add_data(&pdev->dev, &tps68470_gpio->gc, tps68470_gpio); + ret = devm_gpiochip_add_data(&pdev->dev, &tps68470_gpio->gc, tps68470_gpio); + if (ret) + return ret; + + if (device_property_present(&pdev->dev, "daisy-chain-enable")) + ret = tps68470_enable_i2c_daisy_chain(&tps68470_gpio->gc); + + return ret; } static struct platform_driver tps68470_gpio_driver = { diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c b/drivers/gpu/drm/bridge/sil-sii8620.c index d3f238b1f2a9..982306eb4f0a 100644 --- a/drivers/gpu/drm/bridge/sil-sii8620.c +++ b/drivers/gpu/drm/bridge/sil-sii8620.c @@ -2221,6 +2221,7 @@ static void sii8620_detach(struct drm_bridge *bridge) return; rc_unregister_device(ctx->rc_dev); + rc_free_device(ctx->rc_dev); } static int sii8620_is_packing_required(struct sii8620 *ctx, diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c index 2c5aefe9621a..7f25c50621c9 100644 --- a/drivers/gpu/drm/tegra/dsi.c +++ b/drivers/gpu/drm/tegra/dsi.c @@ -14,6 +14,7 @@ #include #include #include +#include #include