code:
Samsung S5P/Exynos SoC Camera Subsystem (FIMC)
----------------------------------------------

The S5P/Exynos SoC Camera subsystem comprises of multiple sub-devices
represented by separate device tree nodes. Currently this includes: FIMC (in
the S5P SoCs series known as CAMIF), MIPI CSIS, FIMC-LITE and FIMC-IS (ISP).

The sub-subdevices are defined as child nodes of the common 'camera' node which
also includes common properties of the whole subsystem not really specific to
any single sub-device, like common camera port pins or the CAMCLK clock outputs
for external image sensors attached to an SoC.

Common 'camera' node
--------------------

Required properties:

- compatible: must be "samsung,fimc", "simple-bus"
- clocks: list of clock specifiers, corresponding to entries in
  the clock-names property;
- clock-names : must contain "sclk_cam0", "sclk_cam1", "pxl_async0",
  "pxl_async1" entries, matching entries in the clocks property.

- #clock-cells: from the common clock bindings (../clock/clock-bindings.txt),
  must be 1. A clock provider is associated with the 'camera' node and it should
  be referenced by external sensors that use clocks provided by the SoC on
  CAM_*_CLKOUT pins. The clock specifier cell stores an index of a clock.
  The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively.

- clock-output-names: from the common clock bindings, should contain names of
  clocks registered by the camera subsystem corresponding to CAM_A_CLKOUT,
  CAM_B_CLKOUT output clocks respectively.

The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used
to define a required pinctrl state named "default" and optional pinctrl states:
"idle", "active-a", active-b". These optional states can be used to switch the
camera port pinmux at runtime. The "idle" state should configure both the camera
ports A and B into high impedance state, especially the CAMCLK clock output
should be inactive. For the "active-a" state the camera port A must be activated
and the port B deactivated and for the state "active-b" it should be the other
way around.

The 'camera' node must include at least one 'fimc' child node.

'fimc' device nodes
-------------------

Required properties:

- compatible: "samsung,s5pv210-fimc" for S5PV210, "samsung,exynos4210-fimc"
  for Exynos4210 and "samsung,exynos4212-fimc" for Exynos4x12 SoCs;
- reg: physical base address and length of the registers set for the device;
- interrupts: should contain FIMC interrupt;
- clocks: list of clock specifiers, must contain an entry for each required
  entry in clock-names;
- clock-names: must contain "fimc", "sclk_fimc" entries.
- samsung,pix-limits: an array of maximum supported image sizes in pixels, for
  details refer to Table 2-1 in the S5PV210 SoC User Manual; The meaning of
  each cell is as follows:
  0 - scaler input horizontal size,
  1 - input horizontal size for the scaler bypassed,
  2 - REAL_WIDTH without input rotation,
  3 - REAL_HEIGHT with input rotation,
- samsung,sysreg: a phandle to the SYSREG node.

Each FIMC device should have an alias in the aliases node, in the form of
fimc<n>, where <n> is an integer specifying the IP block instance.

Optional properties:

- clock-frequency: maximum FIMC local clock (LCLK) frequency;
- samsung,min-pix-sizes: an array specyfing minimum image size in pixels at
  the FIMC input and output DMA, in the first and second cell respectively.
  Default value when this property is not present is <16 16>;
- samsung,min-pix-alignment: minimum supported image height alignment (first
  cell) and the horizontal image offset (second cell). The values are in pixels
  and default to <2 1> when this property is not present;
- samsung,mainscaler-ext: a boolean property indicating whether the FIMC IP
  supports extended image size and has CIEXTEN register;
- samsung,rotators: a bitmask specifying whether this IP has the input and
  the output rotator. Bits 4 and 0 correspond to input and output rotator
  respectively. If a rotator is present its corresponding bit should be set.
  Default value when this property is not specified is 0x11.
- samsung,cam-if: a bolean property indicating whether the IP block includes
  the camera input interface.
- samsung,isp-wb: this property must be present if the IP block has the ISP
  writeback input.
- samsung,lcd-wb: this property must be present if the IP block has the LCD
  writeback input.

'parallel-ports' node
---------------------

This node should contain child 'port' nodes specifying active parallel video
input ports. It includes camera A and camera B inputs. 'reg' property in the
port nodes specifies data input - 1, 2 indicates input A, B respectively.

Optional properties

- samsung,camclk-out (deprecated) : specifies clock output for remote sensor,
  0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;

Image sensor nodes
------------------

The sensor device nodes should be added to their control bus controller (e.g.
I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
using the common video interfaces bindings, defined in video-interfaces.txt.

Example:

	aliases {
		fimc0 = &fimc_0;
	};

	/* Parallel bus IF sensor */
	i2c_0: i2c@13860000 {
		s5k6aa: sensor@3c {
			compatible = "samsung,s5k6aafx";
			reg = <0x3c>;
			vddio-supply = <...>;

			clock-frequency = <24000000>;
			clocks = <&camera 1>;
			clock-names = "mclk";

			port {
				s5k6aa_ep: endpoint {
					remote-endpoint = <&fimc0_ep>;
					bus-width = <8>;
					hsync-active = <0>;
					vsync-active = <1>;
					pclk-sample = <1>;
				};
			};
		};

		/* MIPI CSI-2 bus IF sensor */
		s5c73m3: sensor@1a {
			compatible = "samsung,s5c73m3";
			reg = <0x1a>;
			vddio-supply = <...>;

			clock-frequency = <24000000>;
			clocks = <&camera 0>;
			clock-names = "mclk";

			port {
				s5c73m3_1: endpoint {
					data-lanes = <1 2 3 4>;
					remote-endpoint = <&csis0_ep>;
				};
			};
		};
	};

	camera {
		compatible = "samsung,fimc", "simple-bus";
		clocks = <&clock 132>, <&clock 133>, <&clock 351>,
			 <&clock 352>;
		clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0",
			      "pxl_async1";
		#clock-cells = <1>;
		clock-output-names = "cam_a_clkout", "cam_b_clkout";
		pinctrl-names = "default";
		pinctrl-0 = <&cam_port_a_clk_active>;
		#address-cells = <1>;
		#size-cells = <1>;

		/* parallel camera ports */
		parallel-ports {
			/* camera A input */
			port@1 {
				reg = <1>;
				fimc0_ep: endpoint {
					remote-endpoint = <&s5k6aa_ep>;
					bus-width = <8>;
					hsync-active = <0>;
					vsync-active = <1>;
					pclk-sample = <1>;
				};
			};
		};

		fimc_0: fimc@11800000 {
			compatible = "samsung,exynos4210-fimc";
			reg = <0x11800000 0x1000>;
			interrupts = <0 85 0>;
		};

		csis_0: csis@11880000 {
			compatible = "samsung,exynos4210-csis";
			reg = <0x11880000 0x1000>;
			interrupts = <0 78 0>;
			/* camera C input */
			port@3 {
				reg = <3>;
				csis0_ep: endpoint {
					remote-endpoint = <&s5c73m3_ep>;
					data-lanes = <1 2 3 4>;
					samsung,csis-hs-settle = <12>;
				};
			};
		};
	};

The MIPI-CSIS device binding is defined in samsung-mipi-csis.txt.


code:
Samsung S5P/Exynos SoC series MIPI CSI-2 receiver (MIPI CSIS)
-------------------------------------------------------------

Required properties:

- compatible	  : "samsung,s5pv210-csis" for S5PV210 (S5PC110),
		    "samsung,exynos4210-csis" for Exynos4210 (S5PC210),
		    "samsung,exynos4212-csis" for Exynos4212/Exynos4412,
		    "samsung,exynos5250-csis" for Exynos5250;
- reg		  : offset and length of the register set for the device;
- interrupts      : should contain MIPI CSIS interrupt; the format of the
		    interrupt specifier depends on the interrupt controller;
- bus-width	  : maximum number of data lanes supported (SoC specific);
- vddio-supply    : MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V);
- vddcore-supply  : MIPI CSIS Core voltage supply (e.g. 1.1V);
- clocks	  : list of clock specifiers, corresponding to entries in
		    clock-names property;
- clock-names	  : must contain "csis", "sclk_csis" entries, matching entries
		    in the clocks property.

Optional properties:

- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
		    value when this property is not specified is 166 MHz;
- samsung,csis-wclk : CSI-2 wrapper clock selection. If this property is present
		    external clock from CMU will be used, or the bus clock if
		    if it's not specified.

The device node should contain one 'port' child node with one child 'endpoint'
node, according to the bindings defined in Documentation/devicetree/bindings/
media/video-interfaces.txt. The following are properties specific to those nodes.

port node
---------

- reg		  : (required) must be 3 for camera C input (CSIS0) or 4 for
		    camera D input (CSIS1);

endpoint node
-------------

- data-lanes	  : (required) an array specifying active physical MIPI-CSI2
		    data input lanes and their mapping to logical lanes; the
		    array's content is unused, only its length is meaningful;

- samsung,csis-hs-settle : (optional) differential receiver (HS-RX) settle time;

Example:

	reg0: regulator@0 {
	};

	reg1: regulator@1 {
	};

/* SoC properties */

	csis_0: csis@11880000 {
		compatible = "samsung,exynos4210-csis";
		reg = <0x11880000 0x1000>;
		interrupts = <0 78 0>;
		#address-cells = <1>;
		#size-cells = <0>;
	};

/* Board properties */

	csis_0: csis@11880000 {
		clock-frequency = <166000000>;
		vddio-supply = <&reg0>;
		vddcore-supply = <&reg1>;
		port {
			reg = <3>; /* 3 - CSIS0, 4 - CSIS1 */
			csis0_ep: endpoint {
				remote-endpoint = <...>;
				data-lanes = <1>, <2>;
				samsung,csis-hs-settle = <12>;
			};
		};
	};

repo_name: angery/linux


code:
Samsung S5C73M3 8Mp camera ISP
------------------------------

The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656) video
data busses. The I2C bus is the main control bus and additionally the SPI bus
is used, mostly for transferring the firmware to and from the device. Two
slave device nodes corresponding to these control bus interfaces are required
and should be placed under respective bus controller nodes.

I2C slave device node
---------------------

Required properties:

- compatible	    : "samsung,s5c73m3";
- reg		    : I2C slave address of the sensor;
- vdd-int-supply    : digital power supply (1.2V);
- vdda-supply	    : analog power supply (1.2V);
- vdd-reg-supply    : regulator input power supply (2.8V);
- vddio-host-supply : host I/O power supply (1.8V to 2.8V);
- vddio-cis-supply  : CIS I/O power supply (1.2V to 1.8V);
- vdd-af-supply     : lens power supply (2.8V);
- xshutdown-gpios   : specifier of GPIO connected to the XSHUTDOWN pin;
- standby-gpios     : specifier of GPIO connected to the STANDBY pin;
- clocks	    : should contain list of phandle and clock specifier pairs
		      according to common clock bindings for the clocks described
		      in the clock-names property;
- clock-names	    : should contain "cis_extclk" entry for the CIS_EXTCLK clock;

Optional properties:

- clock-frequency   : the frequency at which the "cis_extclk" clock should be
		      configured to operate, in Hz; if this property is not
		      specified default 24 MHz value will be used.

The common video interfaces bindings (see video-interfaces.txt) should be used
to specify link from the S5C73M3 to an external image data receiver. The S5C73M3
device node should contain one 'port' child node with an 'endpoint' subnode for
this purpose. The data link from a raw image sensor to the S5C73M3 can be
similarly specified, but it is optional since the S5C73M3 ISP and a raw image
sensor are usually inseparable and form a hybrid module.

Following properties are valid for the endpoint node(s):

endpoint subnode
----------------

- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
  video-interfaces.txt. This sensor doesn't support data lane remapping
  and physical lane indexes in subsequent elements of the array should
  be only consecutive ascending values.

SPI device node
---------------

Required properties:

- compatible	    : "samsung,s5c73m3";

For more details see description of the SPI busses bindings
(../spi/spi-bus.txt) and bindings of a specific bus controller.

Example:

i2c@138a000000 {
	...
	s5c73m3@3c {
		compatible = "samsung,s5c73m3";
		reg = <0x3c>;
		vdd-int-supply = <&buck9_reg>;
		vdda-supply = <&ldo17_reg>;
		vdd-reg-supply = <&cam_io_reg>;
		vddio-host-supply = <&ldo18_reg>;
		vddio-cis-supply = <&ldo9_reg>;
		vdd-af-supply = <&cam_af_reg>;
		clock-frequency = <24000000>;
		clocks = <&clk 0>;
		clock-names = "cis_extclk";
		xshutdown-gpios = <&gpf1 3 1>;
		standby-gpios = <&gpm0 1 1>;
		port {
			s5c73m3_ep: endpoint {
				remote-endpoint = <&csis0_ep>;
				data-lanes = <1 2 3 4>;
			};
		};
	};
};

spi@1392000 {
	...
	s5c73m3_spi: s5c73m3@0 {
		compatible = "samsung,s5c73m3";
		reg = <0>;
		...
	};
};


code:
Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor with embedded SoC ISP
--------------------------------------------------------------------

Required properties:

- compatible	  : "samsung,s5k5baf";
- reg		  : I2C slave address of the sensor;
- vdda-supply	  : analog power supply 2.8V (2.6V to 3.0V);
- vddreg-supply	  : regulator input power supply 1.8V (1.7V to 1.9V)
		    or 2.8V (2.6V to 3.0);
- vddio-supply	  : I/O power supply 1.8V (1.65V to 1.95V)
		    or 2.8V (2.5V to 3.1V);
- stbyn-gpios	  : GPIO connected to STDBYN pin;
- rstn-gpios	  : GPIO connected to RSTN pin;
- clocks	  : list of phandle and clock specifier pairs
		    according to common clock bindings for the
		    clocks described in clock-names;
- clock-names	  : should include "mclk" for the sensor's master clock;

Optional properties:

- clock-frequency : the frequency at which the "mclk" clock should be
		    configured to operate, in Hz; if this property is not
		    specified default 24 MHz value will be used.

The device node should contain one 'port' child node with one child 'endpoint'
node, according to the bindings defined in Documentation/devicetree/bindings/
media/video-interfaces.txt. The following are properties specific to those
nodes.

endpoint node
-------------

- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
	       video-interfaces.txt. If present it should be <1> - the device
	       supports only one data lane without re-mapping.

Example:

s5k5bafx@2d {
	compatible = "samsung,s5k5baf";
	reg = <0x2d>;
	vdda-supply = <&cam_io_en_reg>;
	vddreg-supply = <&vt_core_15v_reg>;
	vddio-supply = <&vtcam_reg>;
	stbyn-gpios = <&gpl2 0 1>;
	rstn-gpios = <&gpl2 1 1>;
	clock-names = "mclk";
	clocks = <&clock_cam 0>;
	clock-frequency = <24000000>;

	port {
		s5k5bafx_ep: endpoint {
			remote-endpoint = <&csis1_ep>;
			data-lanes = <1>;
		};
	};
};


code:
Samsung S5K6A3(YX) raw image sensor
---------------------------------

S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
and CCI (I2C compatible) control bus.

Required properties:

- compatible	: "samsung,s5k6a3";
- reg		: I2C slave address of the sensor;
- svdda-supply	: core voltage supply;
- svddio-supply	: I/O voltage supply;
- afvdd-supply	: AF (actuator) voltage supply;
- gpios		: specifier of a GPIO connected to the RESET pin;
- clocks	: should contain list of phandle and clock specifier pairs
		  according to common clock bindings for the clocks described
		  in the clock-names property;
- clock-names	: should contain "extclk" entry for the sensor's EXTCLK clock;

Optional properties:

- clock-frequency : the frequency at which the "extclk" clock should be
		    configured to operate, in Hz; if this property is not
		    specified default 24 MHz value will be used.

The common video interfaces bindings (see video-interfaces.txt) should be
used to specify link to the image data receiver. The S5K6A3(YX) device
node should contain one 'port' child node with an 'endpoint' subnode.

Following properties are valid for the endpoint node:

- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
  video-interfaces.txt.  The sensor supports only one data lane.


code:
* Silicon Labs FM Radio receiver

The Silicon Labs Si470x is family of FM radio receivers with receive power scan
supporting 76-108 MHz, programmable through an I2C interface.
Some of them includes an RDS encoder.

Required Properties:
- compatible: Should contain "silabs,si470x"
- reg: the I2C address of the device

Optional Properties:
- interrupts : The interrupt number
- reset-gpios: GPIO specifier for the chips reset line

Example:

&i2c2 {
        si470x@63 {
                compatible = "silabs,si470x";
                reg = <0x63>;

                interrupt-parent = <&gpj2>;
                interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
                reset-gpios = <&gpj2 5 GPIO_ACTIVE_HIGH>;
        };
};


code:
* Silicon Labs FM Radio transmitter

The Silicon Labs Si4713 is an FM radio transmitter with receive power scan
supporting 76-108 MHz. It includes an RDS encoder and has both, a stereo-analog
and a digital interface, which supports I2S, left-justified and a custom
DSP-mode format. It is programmable through an I2C interface.

Required Properties:
- compatible: Should contain "silabs,si4713"
- reg: the I2C address of the device

Optional Properties:
- interrupts-extended: Interrupt specifier for the chips interrupt
- reset-gpios: GPIO specifier for the chips reset line
- vdd-supply: phandle for Vdd regulator
- vio-supply: phandle for Vio regulator

Example:

&i2c2 {
        fmtx: si4713@63 {
                compatible = "silabs,si4713";
                reg = <0x63>;

                interrupts-extended = <&gpio2 21 IRQ_TYPE_EDGE_FALLING>; /* 53 */
                reset-gpios = <&gpio6 3 GPIO_ACTIVE_HIGH>; /* 163 */
                vio-supply = <&vio>;
                vdd-supply = <&vaux1>;
        };
};


code:
Sony CXD2880 DVB-T2/T tuner + demodulator driver SPI adapter

Required properties:
- compatible: Should be "sony,cxd2880".
- reg: SPI chip select number for the device.
- spi-max-frequency: Maximum bus speed, should be set to <55000000> (55MHz).

Optional properties:
- vcc-supply: Optional phandle to the vcc regulator to power the adapter,
  as described in the file ../regulator/regulator.txt

Example:

cxd2880@0 {
	compatible = "sony,cxd2880";
	reg = <0>; /* CE0 */
	spi-max-frequency = <55000000>; /* 55MHz */
};


code:
* STMicroelectronics DELTA multi-format video decoder

Required properties:
- compatible: should be "st,st-delta".
- clocks: from common clock binding: handle hardware IP needed clocks, the
  number of clocks may depend on the SoC type.
  See ../clock/clock-bindings.txt for details.
- clock-names: names of the clocks listed in clocks property in the same order.

Example:
	delta0 {
		compatible = "st,st-delta";
		clock-names = "delta", "delta-st231", "delta-flash-promip";
		clocks = <&clk_s_c0_flexgen CLK_VID_DMU>,
			 <&clk_s_c0_flexgen CLK_ST231_DMU>,
			 <&clk_s_c0_flexgen CLK_FLASH_PROMIP>;
	};


code:
st-hva: multi-format video encoder for STMicroelectronics SoC.

Required properties:
- compatible: should be "st,st-hva".
- reg: HVA physical address location and length, esram address location and
  length.
- reg-names: names of the registers listed in registers property in the same
  order.
- interrupts: HVA interrupt number.
- clocks: from common clock binding: handle hardware IP needed clocks, the
  number of clocks may depend on the SoC type.
  See ../clock/clock-bindings.txt for details.
- clock-names: names of the clocks listed in clocks property in the same order.

Example:
	hva@8c85000{
		compatible = "st,st-hva";
		reg = <0x8c85000 0x400>, <0x6000000 0x40000>;
		reg-names = "hva_registers", "hva_esram";
		interrupts = <GIC_SPI 58 IRQ_TYPE_NONE>,
			     <GIC_SPI 59 IRQ_TYPE_NONE>;
		clock-names = "clk_hva";
		clocks = <&clk_s_c0_flexgen CLK_HVA>;
	};


code:
STMicroelectronics stih4xx platforms

bdisp: 2D blitter for STMicroelectronics SoC.

Required properties:
- compatible: should be "st,stih407-bdisp".
- reg: BDISP physical address location and length.
- interrupts: BDISP interrupt number.
- clocks: from common clock binding: handle hardware IP needed clocks, the
  number of clocks may depend on the SoC type.
  See ../clocks/clock-bindings.txt for details.
- clock-names: names of the clocks listed in clocks property in the same order.

Example:

	bdisp0:bdisp@9f10000 {
		compatible = "st,stih407-bdisp";
		reg = <0x9f10000 0x1000>;
		interrupts = <GIC_SPI 38 IRQ_TYPE_NONE>;
		clock-names = "bdisp";
		clocks = <&clk_s_c0_flexgen CLK_IC_BDISP_0>;
	};

Aliases:
Each BDISP should have a numbered alias in the aliases node, in the form of
bdispN, N = 0 or 1.

Example:

	aliases {
		bdisp0 = &bdisp0;
	};


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/st,stm32-cec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: STMicroelectronics STM32 CEC bindings

maintainers:
  - Yannick Fertre <yannick.fertre@foss.st.com>

properties:
  compatible:
    const: st,stm32-cec

  reg:
    maxItems: 1

  interrupts:
    maxItems: 1

  clocks:
    items:
      - description: Module Clock
      - description: Bus Clock

  clock-names:
    items:
      - const: cec
      - const: hdmi-cec

required:
  - compatible
  - reg
  - interrupts
  - clocks
  - clock-names

additionalProperties: false

examples:
  - |
    #include <dt-bindings/interrupt-controller/arm-gic.h>
    #include <dt-bindings/clock/stm32mp1-clks.h>
    cec: cec@40006c00 {
        compatible = "st,stm32-cec";
        reg = <0x40006c00 0x400>;
        interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
        clocks = <&rcc CEC_K>, <&clk_lse>;
        clock-names = "cec", "hdmi-cec";
    };

...


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/st,stm32-dcmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: STMicroelectronics STM32 Digital Camera Memory Interface (DCMI) binding

maintainers:
  - Hugues Fruchet <hugues.fruchet@foss.st.com>

properties:
  compatible:
    const: st,stm32-dcmi

  reg:
    maxItems: 1

  interrupts:
    maxItems: 1

  clocks:
    maxItems: 1

  clock-names:
    items:
      - const: mclk

  dmas:
    maxItems: 1

  dma-names:
    items:
      - const: tx

  resets:
    maxItems: 1

  port:
    $ref: /schemas/graph.yaml#/$defs/port-base
    unevaluatedProperties: false
    description:
      DCMI supports a single port node with parallel bus.

    properties:
      endpoint:
        $ref: video-interfaces.yaml#
        unevaluatedProperties: false

        properties:
          bus-type:
            enum: [5, 6]
            default: 5

          bus-width:
            enum: [8, 10, 12, 14]
            default: 8

        allOf:
          - if:
              properties:
                bus-type:
                  const: 6

            then:
              properties:
                hsync-active: false
                vsync-active: false
                bus-width:
                  enum: [8]

        required:
          - bus-type
          - pclk-sample

required:
  - compatible
  - reg
  - interrupts
  - clocks
  - clock-names
  - resets
  - dmas
  - dma-names
  - port

additionalProperties: false

examples:
  - |
    #include <dt-bindings/interrupt-controller/arm-gic.h>
    #include <dt-bindings/clock/stm32mp1-clks.h>
    #include <dt-bindings/media/video-interfaces.h>
    #include <dt-bindings/reset/stm32mp1-resets.h>

    dcmi: dcmi@4c006000 {
        compatible = "st,stm32-dcmi";
        reg = <0x4c006000 0x400>;
        interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
        resets = <&rcc CAMITF_R>;
        clocks = <&rcc DCMI>;
        clock-names = "mclk";
        dmas = <&dmamux1 75 0x400 0x0d>;
        dma-names = "tx";

        port {
             dcmi_0: endpoint {
                   remote-endpoint = <&ov5640_0>;
                   bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
                   bus-width = <8>;
                   hsync-active = <0>;
                   vsync-active = <0>;
                   pclk-sample = <1>;
             };
        };
    };

...


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/st,stm32-dma2d.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: STMicroelectronics STM32 Chrom-Art Accelerator DMA2D binding

description:
  Chrom-ART Accelerator(DMA2D), graphical hardware accelerator
  enabling enhanced graphical user interface with minimum CPU load

  It can perform the following operations.

  - Filling a part or the whole of a destination image with a specific color.
  - Copying a part or the whole of a source image into a part or the whole of
    a destination image.
  - Copying a part or the whole of a source image into a part or the whole of
    a destination image with a pixel format conversion.
  - Blending a part and/or two complete source images with different pixel
    format and copy the result into a part or the whole of a destination image
    with a different color format. (TODO)

maintainers:
  - Dillon Min <dillon.minfei@gmail.com>

properties:
  compatible:
    const: st,stm32-dma2d

  reg:
    maxItems: 1

  interrupts:
    maxItems: 1

  clocks:
    maxItems: 1

  clock-names:
    items:
      - const: dma2d

  resets:
    maxItems: 1

required:
  - compatible
  - reg
  - interrupts
  - clocks
  - clock-names
  - resets

additionalProperties: false

examples:
  - |
    #include <dt-bindings/clock/stm32fx-clock.h>
    #include <dt-bindings/mfd/stm32f4-rcc.h>
    dma2d: dma2d@4002b000 {
        compatible = "st,stm32-dma2d";
        reg = <0x4002b000 0xc00>;
        interrupts = <90>;
        resets = <&rcc STM32F4_AHB1_RESET(DMA2D)>;
        clocks = <&rcc 0 STM32F4_AHB1_CLOCK(DMA2D)>;
        clock-names = "dma2d";
    };

...


code:
Device-Tree bindings for ST IRB IP

Required properties:
	- compatible: Should contain "st,comms-irb".
	- reg: Base physical address of the controller and length of memory
	  mapped region.
	- interrupts: interrupt-specifier for the sole interrupt generated by
	  the device. The interrupt specifier format depends on the interrupt
	  controller parent.
	- rx-mode: can be "infrared" or "uhf". This property specifies the L1
	  protocol used for receiving remote control signals. rx-mode should
	  be present iff the rx pins are wired up.
	- tx-mode: should be "infrared". This property specifies the L1
	  protocol used for transmitting remote control signals. tx-mode should
	  be present iff the tx pins are wired up.

Optional properties:
	- pinctrl-names, pinctrl-0: the pincontrol settings to configure muxing
	  properly for IRB pins.
	- clocks : phandle with clock-specifier pair for IRB.

Example node:

	rc: rc@fe518000 {
		compatible	= "st,comms-irb";
		reg		= <0xfe518000 0x234>;
		interrupts	= <0 203 0>;
		rx-mode		= "infrared";
	};


code:
STMicroelectronics STIH4xx HDMI CEC driver

Required properties:
 - compatible : value should be "st,stih-cec"
 - reg : Physical base address of the IP registers and length of memory
	 mapped region.
 - clocks : from common clock binding: handle to HDMI CEC clock
 - interrupts : HDMI CEC interrupt number to the CPU.
 - pinctrl-names: Contains only one value - "default"
 - pinctrl-0: Specifies the pin control groups used for CEC hardware.
 - resets: Reference to a reset controller
 - hdmi-phandle: Phandle to the HDMI controller, see also cec.txt.

Example for STIH407:

sti-cec@94a087c {
	compatible = "st,stih-cec";
	reg = <0x94a087c 0x64>;
	clocks = <&clk_sysin>;
	clock-names = "cec-clk";
	interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>;
	interrupt-names = "cec-irq";
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_cec0_default>;
	resets = <&softreset STIH407_LPM_SOFTRESET>;
	hdmi-phandle = <&hdmi>;
};


code:
STMicroelectronics STi c8sectpfe binding
============================================

This document describes the c8sectpfe device bindings that is used to get transport
stream data into the SoC on the TS pins, and into DDR for further processing.

It is typically used in conjunction with one or more demodulator and tuner devices
which converts from the RF to digital domain. Demodulators and tuners are usually
located on an external DVB frontend card connected to SoC TS input pins.

Currently 7 TS input (tsin) channels are supported on the stih407 family SoC.

Required properties (controller (parent) node):
- compatible	: Should be "stih407-c8sectpfe"

- reg		: Address and length of register sets for each device in
		  "reg-names"

- reg-names	: The names of the register addresses corresponding to the
		  registers filled in "reg":
			- c8sectpfe: c8sectpfe registers
			- c8sectpfe-ram: c8sectpfe internal sram

- clocks	: phandle list of c8sectpfe clocks
- clock-names	: should be "c8sectpfe"
See: Documentation/devicetree/bindings/clock/clock-bindings.txt

- pinctrl-names	: a pinctrl state named tsin%d-serial or tsin%d-parallel (where %d is tsin-num)
		   must be defined for each tsin child node.
- pinctrl-0	: phandle referencing pin configuration for this tsin configuration
See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt

Required properties (tsin (child) node):

- tsin-num	: tsin id of the InputBlock (must be between 0 to 6)
- i2c-bus	: phandle to the I2C bus DT node which the demodulators & tuners on this tsin channel are connected.
- reset-gpios	: reset gpio for this tsin channel.

Optional properties (tsin (child) node):

- invert-ts-clk		: Bool property to control sense of ts input clock (data stored on falling edge of clk).
- serial-not-parallel	: Bool property to configure input bus width (serial on ts_data<7>).
- async-not-sync	: Bool property to control if data is received in asynchronous mode
			   (all bits/bytes with ts_valid or ts_packet asserted are valid).

- dvb-card		: Describes the NIM card connected to this tsin channel.

Example:

/* stih410 SoC b2120 + b2004a + stv0367-pll(NIMB) + stv0367-tda18212 (NIMA) DT example) */

	c8sectpfe@8a20000 {
		compatible = "st,stih407-c8sectpfe";
		reg = <0x08a20000 0x10000>, <0x08a00000 0x4000>;
		reg-names = "stfe", "stfe-ram";
		interrupts = <GIC_SPI 34 IRQ_TYPE_NONE>, <GIC_SPI 35 IRQ_TYPE_NONE>;
		interrupt-names = "stfe-error-irq", "stfe-idle-irq";
		pinctrl-0	= <&pinctrl_tsin0_serial>;
		pinctrl-1	= <&pinctrl_tsin0_parallel>;
		pinctrl-2	= <&pinctrl_tsin3_serial>;
		pinctrl-3	= <&pinctrl_tsin4_serial_alt3>;
		pinctrl-4	= <&pinctrl_tsin5_serial_alt1>;
		pinctrl-names	= "tsin0-serial",
				  "tsin0-parallel",
				  "tsin3-serial",
				  "tsin4-serial",
				  "tsin5-serial";
		clocks = <&clk_s_c0_flexgen CLK_PROC_STFE>;
		clock-names = "c8sectpfe";

		/* tsin0 is TSA on NIMA */
		tsin0: port@0 {
			tsin-num		= <0>;
			serial-not-parallel;
			i2c-bus			= <&ssc2>;
			reset-gpios		= <&pio15 4 GPIO_ACTIVE_HIGH>;
			dvb-card		= <STV0367_TDA18212_NIMA_1>;
		};

		tsin3: port@3 {
			tsin-num		= <3>;
			serial-not-parallel;
			i2c-bus			= <&ssc3>;
			reset-gpios		= <&pio15 7 GPIO_ACTIVE_HIGH>;
			dvb-card		= <STV0367_TDA18212_NIMB_1>;
		};
	};


code:
* Tegra HDMI CEC hardware

The HDMI CEC module is present in Tegra SoCs and its purpose is to
handle communication between HDMI connected devices over the CEC bus.

Required properties:
  - compatible : value should be one of the following:
	"nvidia,tegra114-cec"
	"nvidia,tegra124-cec"
	"nvidia,tegra210-cec"
  - reg : Physical base address of the IP registers and length of memory
	  mapped region.
  - interrupts : HDMI CEC interrupt number to the CPU.
  - clocks : from common clock binding: handle to HDMI CEC clock.
  - clock-names : from common clock binding: must contain "cec",
		  corresponding to the entry in the clocks property.
  - hdmi-phandle : phandle to the HDMI controller, see also cec.txt.

Example:

cec@70015000 {
	compatible = "nvidia,tegra124-cec";
	reg = <0x0 0x70015000 0x0 0x00001000>;
	interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
	clocks = <&tegra_car TEGRA124_CLK_CEC>;
	clock-names = "cec";
};


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/ti,cal.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Texas Instruments DRA72x CAMERA ADAPTATION LAYER (CAL)

maintainers:
  - Benoit Parrot <bparrot@ti.com>

description: |-
  The Camera Adaptation Layer (CAL) is a key component for image capture
  applications. The capture module provides the system interface and the
  processing capability to connect CSI2 image-sensor modules to the
  DRA72x device.

  CAL supports 2 camera port nodes on MIPI bus.

properties:
  compatible:
    enum:
      # for DRA72 controllers
      - ti,dra72-cal
      # for DRA72 controllers pre ES2.0
      - ti,dra72-pre-es2-cal
      # for DRA76 controllers
      - ti,dra76-cal
      # for AM654 controllers
      - ti,am654-cal

  reg:
    minItems: 2
    items:
      - description: The CAL main register region
      - description: The RX Core0 (DPHY0) register region
      - description: The RX Core1 (DPHY1) register region

  reg-names:
    minItems: 2
    items:
      - const: cal_top
      - const: cal_rx_core0
      - const: cal_rx_core1

  interrupts:
    maxItems: 1

  ti,camerrx-control:
    $ref: "/schemas/types.yaml#/definitions/phandle-array"
    items:
      - items:
          - description: phandle to device control module
          - description: offset to the control_camerarx_core register
    description:
      phandle to the device control module and offset to the
      control_camerarx_core register

  clocks:
    maxItems: 1

  clock-names:
    const: fck

  power-domains:
    description:
      List of phandle and PM domain specifier as documented in
      Documentation/devicetree/bindings/power/power_domain.txt
    maxItems: 1

  ports:
    $ref: /schemas/graph.yaml#/properties/ports

    properties:
      port@0:
        $ref: /schemas/graph.yaml#/$defs/port-base
        unevaluatedProperties: false
        description: CSI2 Port #0

        properties:
          endpoint:
            $ref: video-interfaces.yaml#
            unevaluatedProperties: false

            properties:
              clock-lanes:
                maxItems: 1

              data-lanes:
                minItems: 1
                maxItems: 4

      port@1:
        $ref: /schemas/graph.yaml#/$defs/port-base
        unevaluatedProperties: false
        description: CSI2 Port #1

        properties:
          endpoint:
            $ref: video-interfaces.yaml#
            unevaluatedProperties: false

            properties:
              clock-lanes:
                maxItems: 1

              data-lanes:
                minItems: 1
                maxItems: 4

    required:
      - port@0

required:
  - compatible
  - reg
  - reg-names
  - interrupts
  - ti,camerrx-control

additionalProperties: false

examples:
  - |
    #include <dt-bindings/interrupt-controller/arm-gic.h>

    cal: cal@4845b000 {
        compatible = "ti,dra72-cal";
        reg = <0x4845B000 0x400>,
              <0x4845B800 0x40>,
              <0x4845B900 0x40>;
        reg-names = "cal_top",
                    "cal_rx_core0",
                    "cal_rx_core1";
        interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
        ti,camerrx-control = <&scm_conf 0xE94>;

        ports {
              #address-cells = <1>;
              #size-cells = <0>;

              csi2_0: port@0 {
                    reg = <0>;
                    csi2_phy0: endpoint {
                           remote-endpoint = <&csi2_cam0>;
                           clock-lanes = <0>;
                           data-lanes = <1 2>;
                    };
              };
        };
    };

    i2c {
        clock-frequency = <400000>;
        #address-cells = <1>;
        #size-cells = <0>;

        camera-sensor@3c {
               compatible = "ovti,ov5640";
               reg = <0x3c>;
               AVDD-supply = <&reg_2p8v>;
               DOVDD-supply = <&reg_1p8v>;
               DVDD-supply = <&reg_1p5v>;
               clocks = <&clk_ov5640_fixed>;
               clock-names = "xclk";

               port {
                    csi2_cam0: endpoint {
                            remote-endpoint = <&csi2_phy0>;
                            clock-lanes = <0>;
                            data-lanes = <1 2>;
                    };
               };
        };
    };

...


code:
Texas Instruments VPIF
----------------------

The TI Video Port InterFace (VPIF) is the primary component for video
capture and display on the DA850/AM18x family of TI DaVinci/Sitara
SoCs.

TI Document reference: SPRUH82C, Chapter 35
http://www.ti.com/lit/pdf/spruh82

Required properties:
- compatible: must be "ti,da850-vpif"
- reg: physical base address and length of the registers set for the device;
- interrupts: should contain IRQ line for the VPIF

Video Capture:

VPIF has a 16-bit parallel bus input, supporting 2 8-bit channels or a
single 16-bit channel. It should contain one or two port child nodes
with child 'endpoint' node. If there are two ports then port@0 must
describe the input and port@1 output channels. Please refer to the
bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.

Example using 2 8-bit input channels, one of which is connected to an
I2C-connected TVP5147 decoder:

	vpif: vpif@217000 {
		compatible = "ti,da850-vpif";
		reg = <0x217000 0x1000>;
		interrupts = <92>;

		port@0 {
			vpif_input_ch0: endpoint@0 {
				reg = <0>;
				bus-width = <8>;
				remote-endpoint = <&composite_in>;
			};

			vpif_input_ch1: endpoint@1 {
				reg = <1>;
				bus-width = <8>;
				data-shift = <8>;
			};
		};

		port@1 {
			vpif_output_ch0: endpoint {
				bus-width = <8>;
				remote-endpoint = <&composite_out>;
			};
		};
	};

[ ... ]

&i2c0 {

	tvp5147@5d {
		compatible = "ti,tvp5147";
		reg = <0x5d>;

		port {
			composite_in: endpoint {
				hsync-active = <1>;
				vsync-active = <1>;
				pclk-sample = <0>;

				/* VPIF channel 0 (lower 8-bits) */
				remote-endpoint = <&vpif_input_ch0>;
				bus-width = <8>;
			};
		};
	};

	adv7343@2a {
		compatible = "adi,adv7343";
		reg = <0x2a>;

		port {
			composite_out: endpoint {
				adi,dac-enable = <1 1 1>;
				adi,sd-dac-enable = <1>;

				remote-endpoint = <&vpif_output_ch0>;
				bus-width = <8>;
			};
		};
	};
};

Alternatively, an example when the bus is configured as a single
16-bit input (e.g. for raw-capture mode):

	vpif: vpif@217000 {
		compatible = "ti,da850-vpif";
		reg = <0x217000 0x1000>;
		interrupts = <92>;

		port {
			vpif_ch0: endpoint {
				  bus-width = <16>;
			};
		};
	};


code:
OMAP 3 ISP Device Tree bindings
===============================

The DT definitions can be found in include/dt-bindings/media/omap3-isp.h.

Required properties
===================

compatible	: must contain "ti,omap3-isp"

reg		: the two registers sets (physical address and length) for the
		  ISP. The first set contains the core ISP registers up to
		  the end of the SBL block. The second set contains the
		  CSI PHYs and receivers registers.
interrupts	: the ISP interrupt specifier
iommus		: phandle and IOMMU specifier for the IOMMU that serves the ISP
syscon		: the phandle and register offset to the Complex I/O or CSI-PHY
		  register
ti,phy-type	: 0 -- OMAP3ISP_PHY_TYPE_COMPLEX_IO (e.g. 3430)
		  1 -- OMAP3ISP_PHY_TYPE_CSIPHY (e.g. 3630)
#clock-cells	: Must be 1 --- the ISP provides two external clocks,
		  cam_xclka and cam_xclkb, at indices 0 and 1,
		  respectively. Please find more information on common
		  clock bindings in ../clock/clock-bindings.txt.

Port nodes (optional)
---------------------

More documentation on these bindings is available in
video-interfaces.txt in the same directory.

reg		: The interface:
		  0 - parallel (CCDC)
		  1 - CSIPHY1 -- CSI2C / CCP2B on 3630;
		      CSI1 -- CSIb on 3430
		  2 - CSIPHY2 -- CSI2A / CCP2B on 3630;
		      CSI2 -- CSIa on 3430

Optional properties
===================

vdd-csiphy1-supply : voltage supply of the CSI-2 PHY 1
vdd-csiphy2-supply : voltage supply of the CSI-2 PHY 2

Endpoint nodes
--------------

lane-polarities	: lane polarity (required on CSI-2)
		  0 -- not inverted; 1 -- inverted
data-lanes	: an array of data lanes from 1 to 3. The length can
		  be either 1 or 2. (required on CSI-2)
clock-lanes	: the clock lane (from 1 to 3). (required on CSI-2)

Example
=======

		isp@480bc000 {
			compatible = "ti,omap3-isp";
			reg = <0x480bc000 0x12fc
			       0x480bd800 0x0600>;
			interrupts = <24>;
			iommus = <&mmu_isp>;
			syscon = <&scm_conf 0x2f0>;
			ti,phy-type = <OMAP3ISP_PHY_TYPE_CSIPHY>;
			#clock-cells = <1>;
			ports {
				#address-cells = <1>;
				#size-cells = <0>;
			};
		};


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/ti,vpe.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Texas Instruments DRA7x Video Processing Engine (VPE)

maintainers:
  - Benoit Parrot <bparrot@ti.com>

description: |-
  The Video Processing Engine (VPE) is a key component for image post
  processing applications. VPE consist of a single memory to memory
  path which can perform chroma up/down sampling, deinterlacing,
  scaling and color space conversion.

properties:
  compatible:
    const: ti,dra7-vpe

  reg:
    items:
      - description: The VPE main register region
      - description: Scaler (SC) register region
      - description: Color Space Conversion (CSC) register region
      - description: Video Port Direct Memory Access (VPDMA) register region

  reg-names:
    items:
      - const: vpe_top
      - const: sc
      - const: csc
      - const: vpdma

  interrupts:
    maxItems: 1

required:
  - compatible
  - reg
  - reg-names
  - interrupts

additionalProperties: false

examples:
  - |
    #include <dt-bindings/interrupt-controller/arm-gic.h>

    vpe: vpe@489d0000 {
        compatible = "ti,dra7-vpe";
        reg = <0x489d0000 0x120>,
              <0x489d0700 0x80>,
              <0x489d5700 0x18>,
              <0x489dd000 0x400>;
        reg-names = "vpe_top",
                    "sc",
                    "csc",
                    "vpdma";
        interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
    };

...


code:
Texas Instruments AM437x CAMERA (VPFE)
--------------------------------------

The Video Processing Front End (VPFE) is a key component for image capture
applications. The capture module provides the system interface and the
processing capability to connect RAW image-sensor modules and video decoders
to the AM437x device.

Required properties:
- compatible: must be "ti,am437x-vpfe"
- reg: physical base address and length of the registers set for the device;
- interrupts: should contain IRQ line for the VPFE;
- ti,am437x-vpfe-interface: can be one of the following,
	0 - Raw Bayer Interface.
	1 - 8 Bit BT656 Interface.
	2 - 10 Bit BT656 Interface.
	3 - YCbCr 8 Bit Interface.
	4 - YCbCr 16 Bit Interface.

VPFE 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.

Example:
	vpfe: vpfe@f0034000 {
		compatible = "ti,am437x-vpfe";
		reg = <0x48328000 0x2000>;
		interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;

		pinctrl-names = "default", "sleep";
		pinctrl-0 = <&vpfe_pins_default>;
		pinctrl-1 = <&vpfe_pins_sleep>;

		port {
			#address-cells = <1>;
			#size-cells = <0>;

			vpfe0_ep: endpoint {
				remote-endpoint = <&ov2659_1>;
				ti,am437x-vpfe-interface = <0>;
				bus-width = <8>;
				hsync-active = <0>;
				vsync-active = <0>;
			};
		};
	};

	i2c1: i2c@4802a000 {

		ov2659@30 {
			compatible = "ti,ov2659";
			reg = <0x30>;

			port {
				ov2659_1: endpoint {
					remote-endpoint = <&vpfe0_ep>;
					bus-width = <8>;
					mclk-frequency = <12000000>;
				};
			};
	};


code:
# 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

...


code: This file has moved to video-interfaces.yaml and video-interface-devices.yaml.


code:
# 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
      - 7 # DPI
    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, 2 ]
    description:
      Sample data on falling (0), rising (1) or both (2) edges 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


code:
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/video-mux.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Video Multiplexer

maintainers:
  - Sakari Ailus <sakari.ailus@linux.intel.com>
  - Laurent Pinchart <laurent.pinchart@ideasonboard.com>

description:
  Video multiplexers allow to select between multiple input ports. Video
  received on the active input port is passed through to the output port. Muxes
  described by this binding are controlled by a multiplexer controller.

properties:
  compatible:
    const: video-mux

  mux-controls:
    maxItems: 1

  '#address-cells':
    const: 1

  '#size-cells':
    const: 0

  ports:
    $ref: /schemas/graph.yaml#/properties/ports

    patternProperties:
      '^port@':
        $ref: /schemas/graph.yaml#/properties/port

    required:
      - port@0
      - port@1
      - port@2

patternProperties:
  '^port@':
    $ref: /schemas/graph.yaml#/properties/port
    description:
      At least three port nodes containing endpoints connecting to the source
      and sink devices according to of_graph bindings. The last port is the
      output port, all others are inputs.

required:
  - compatible
  - mux-controls

oneOf:
  - required:
      - ports
  - required:
      - port@0
      - port@1
      - port@2

additionalProperties: false

examples:
  - |
    #include <dt-bindings/gpio/gpio.h>

    mux: mux-controller {
        compatible = "gpio-mux";
        #mux-control-cells = <0>;

        mux-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
    };

    video-mux {
        compatible = "video-mux";
        mux-controls = <&mux>;
        #address-cells = <1>;
        #size-cells = <0>;

        port@0 {
            reg = <0>;

            mux_in0: endpoint {
                remote-endpoint = <&video_source0_out>;
            };
        };

        port@1 {
            reg = <1>;

            mux_in1: endpoint {
                remote-endpoint = <&video_source1_out>;
            };
        };

        port@2 {
            reg = <2>;

            mux_out: endpoint {
                remote-endpoint = <&capture_interface_in>;
            };
        };
    };
...


code:
DT bindings for Xilinx video IP cores
-------------------------------------

Xilinx video IP cores process video streams by acting as video sinks and/or
sources. They are connected by links through their input and output ports,
creating a video pipeline.

Each video IP core is represented by an AMBA bus child node in the device
tree using bindings documented in this directory. Connections between the IP
cores are represented as defined in ../video-interfaces.txt.

The whole  pipeline is represented by an AMBA bus child node in the device
tree using bindings documented in ./xlnx,video.txt.

Common properties
-----------------

The following properties are common to all Xilinx video IP cores.

- xlnx,video-format: This property represents a video format transmitted on an
  AXI bus between video IP cores, using its VF code as defined in "AXI4-Stream
  Video IP and System Design Guide" [UG934]. How the format relates to the IP
  core is described in the IP core bindings documentation.

- xlnx,video-width: This property qualifies the video format with the sample
  width expressed as a number of bits per pixel component. All components must
  use the same width.

- xlnx,cfa-pattern: When the video format is set to Mono/Sensor, this property
  describes the sensor's color filter array pattern. Supported values are
  "bggr", "gbrg", "grbg", "rggb" and "mono". If not specified, the pattern
  defaults to "mono".

[UG934] https://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/v1_0/ug934_axi_videoIP.pdf


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/xilinx/xlnx,csi2rxss.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Xilinx MIPI CSI-2 Receiver Subsystem

maintainers:
  - Vishal Sagar <vishal.sagar@xilinx.com>

description: |
  The Xilinx MIPI CSI-2 Receiver Subsystem is used to capture MIPI CSI-2
  traffic from compliant camera sensors and send the output as AXI4 Stream
  video data for image processing.
  The subsystem consists of a MIPI D-PHY in slave mode which captures the
  data packets. This is passed along the MIPI CSI-2 Rx IP which extracts the
  packet data. The optional Video Format Bridge (VFB) converts this data to
  AXI4 Stream video data.
  For more details, please refer to PG232 Xilinx MIPI CSI-2 Receiver Subsystem.
  Please note that this bindings includes only the MIPI CSI-2 Rx controller
  and Video Format Bridge and not D-PHY.

properties:
  compatible:
    items:
      - enum:
          - xlnx,mipi-csi2-rx-subsystem-5.0

  reg:
    maxItems: 1

  interrupts:
    maxItems: 1

  clocks:
    description: List of clock specifiers
    items:
      - description: AXI Lite clock
      - description: Video clock

  clock-names:
    items:
      - const: lite_aclk
      - const: video_aclk

  xlnx,csi-pxl-format:
    description: |
      This denotes the CSI Data type selected in hw design.
      Packets other than this data type (except for RAW8 and
      User defined data types) will be filtered out.
      Possible values are as below -
      0x1e - YUV4228B
      0x1f - YUV42210B
      0x20 - RGB444
      0x21 - RGB555
      0x22 - RGB565
      0x23 - RGB666
      0x24 - RGB888
      0x28 - RAW6
      0x29 - RAW7
      0x2a - RAW8
      0x2b - RAW10
      0x2c - RAW12
      0x2d - RAW14
      0x2e - RAW16
      0x2f - RAW20
    $ref: /schemas/types.yaml#/definitions/uint32
    oneOf:
      - minimum: 0x1e
        maximum: 0x24
      - minimum: 0x28
        maximum: 0x2f

  xlnx,vfb:
    type: boolean
    description: Present when Video Format Bridge is enabled in IP configuration

  xlnx,en-csi-v2-0:
    type: boolean
    description: Present if CSI v2 is enabled in IP configuration.

  xlnx,en-vcx:
    type: boolean
    description: |
      When present, there are maximum 16 virtual channels, else only 4.

  xlnx,en-active-lanes:
    type: boolean
    description: |
      Present if the number of active lanes can be re-configured at
      runtime in the Protocol Configuration Register. Otherwise all lanes,
      as set in IP configuration, are always active.

  video-reset-gpios:
    description: Optional specifier for a GPIO that asserts video_aresetn.
    maxItems: 1

  ports:
    $ref: /schemas/graph.yaml#/properties/ports

    properties:
      port@0:
        $ref: /schemas/graph.yaml#/$defs/port-base
        description: |
          Input / sink port node, single endpoint describing the
          CSI-2 transmitter.

        properties:
          endpoint:
            $ref: /schemas/media/video-interfaces.yaml#
            unevaluatedProperties: false

            properties:
              data-lanes:
                description: |
                  This is required only in the sink port 0 endpoint which
                  connects to MIPI CSI-2 source like sensor.
                  The possible values are -
                  1       - For 1 lane enabled in IP.
                  1 2     - For 2 lanes enabled in IP.
                  1 2 3   - For 3 lanes enabled in IP.
                  1 2 3 4 - For 4 lanes enabled in IP.
                items:
                  - const: 1
                  - const: 2
                  - const: 3
                  - const: 4

            required:
              - data-lanes

        unevaluatedProperties: false

      port@1:
        $ref: /schemas/graph.yaml#/properties/port
        description: |
          Output / source port node, endpoint describing modules
          connected the CSI-2 receiver.

required:
  - compatible
  - reg
  - interrupts
  - clocks
  - clock-names
  - ports

allOf:
  - if:
      required:
        - xlnx,vfb
    then:
      required:
        - xlnx,csi-pxl-format
    else:
      properties:
        xlnx,csi-pxl-format: false

  - if:
      not:
        required:
          - xlnx,en-csi-v2-0
    then:
      properties:
        xlnx,en-vcx: false

additionalProperties: false

examples:
  - |
    #include <dt-bindings/gpio/gpio.h>
    xcsi2rxss_1: csi2rx@a0020000 {
        compatible = "xlnx,mipi-csi2-rx-subsystem-5.0";
        reg = <0xa0020000 0x10000>;
        interrupt-parent = <&gic>;
        interrupts = <0 95 4>;
        xlnx,csi-pxl-format = <0x2a>;
        xlnx,vfb;
        xlnx,en-active-lanes;
        xlnx,en-csi-v2-0;
        xlnx,en-vcx;
        clock-names = "lite_aclk", "video_aclk";
        clocks = <&misc_clk_0>, <&misc_clk_1>;
        video-reset-gpios = <&gpio 86 GPIO_ACTIVE_LOW>;

        ports {
            #address-cells = <1>;
            #size-cells = <0>;

            port@0 {
                /* Sink port */
                reg = <0>;
                csiss_in: endpoint {
                    data-lanes = <1 2 3 4>;
                    /* MIPI CSI-2 Camera handle */
                    remote-endpoint = <&camera_out>;
                };
            };
            port@1 {
                /* Source port */
                reg = <1>;
                csiss_out: endpoint {
                    remote-endpoint = <&vproc_in>;
                };
            };
        };
    };
...


code:
Xilinx Video Timing Controller (VTC)
------------------------------------

The Video Timing Controller is a general purpose video timing generator and
detector.

Required properties:

  - compatible: Must be "xlnx,v-tc-6.1".

  - reg: Physical base address and length of the registers set for the device.

  - clocks: Must contain a clock specifier for the VTC core and timing
    interfaces clock.

Optional properties:

  - xlnx,detector: The VTC has a timing detector
  - xlnx,generator: The VTC has a timing generator

  At least one of the xlnx,detector and xlnx,generator properties must be
  specified.

Example:

	vtc: vtc@43c40000 {
		compatible = "xlnx,v-tc-6.1";
		reg = <0x43c40000 0x10000>;

		clocks = <&clkc 15>;
		xlnx,generator;
	};


code:
Xilinx Video Test Pattern Generator (TPG)
-----------------------------------------

Required properties:

- compatible: Must contain at least one of

    "xlnx,v-tpg-5.0" (TPG version 5.0)
    "xlnx,v-tpg-6.0" (TPG version 6.0)

  TPG versions backward-compatible with previous versions should list all
  compatible versions in the newer to older order.

- reg: Physical base address and length of the registers set for the device.

- clocks: Reference to the video core clock.

- xlnx,video-format, xlnx,video-width: Video format and width, as defined in
  video.txt.

- port: Video port, using the DT bindings defined in ../video-interfaces.txt.
  The TPG has a single output port numbered 0.

Optional properties:

- xlnx,vtc: A phandle referencing the Video Timing Controller that generates
  video timings for the TPG test patterns.

- timing-gpios: Specifier for a GPIO that controls the timing mux at the TPG
  input. The GPIO active level corresponds to the selection of VTC-generated
  video timings.

The xlnx,vtc and timing-gpios properties are mandatory when the TPG is
synthesized with two ports and forbidden when synthesized with one port.

Example:

	tpg_0: tpg@40050000 {
		compatible = "xlnx,v-tpg-6.0", "xlnx,v-tpg-5.0";
		reg = <0x40050000 0x10000>;
		clocks = <&clkc 15>;

		xlnx,vtc = <&vtc_3>;
		timing-gpios = <&ps7_gpio_0 55 GPIO_ACTIVE_LOW>;

		ports {
			#address-cells = <1>;
			#size-cells = <0>;

			port@0 {
				reg = <0>;

				xlnx,video-format = <XVIP_VF_YUV_422>;
				xlnx,video-width = <8>;

				tpg_in: endpoint {
					remote-endpoint = <&adv7611_out>;
				};
			};
			port@1 {
				reg = <1>;

				xlnx,video-format = <XVIP_VF_YUV_422>;
				xlnx,video-width = <8>;

				tpg1_out: endpoint {
					remote-endpoint = <&switch_in0>;
				};
			};
		};
	};


code:
Xilinx Video IP Pipeline (VIPP)
-------------------------------

General concept
---------------

Xilinx video IP pipeline processes video streams through one or more Xilinx
video IP cores. Each video IP core is represented as documented in video.txt
and IP core specific documentation, xlnx,v-*.txt, in this directory. The DT
node of the VIPP represents as a top level node of the pipeline and defines
mappings between DMAs and the video IP cores.

Required properties:

- compatible: Must be "xlnx,video".

- dmas, dma-names: List of one DMA specifier and identifier string (as defined
  in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port
  requires a DMA channel with the identifier string set to "port" followed by
  the port index.

- ports: Video port, using the DT bindings defined in ../video-interfaces.txt.

Required port properties:

- direction: should be either "input" or "output" depending on the direction
  of stream.

Example:

	video_cap {
		compatible = "xlnx,video";
		dmas = <&vdma_1 1>, <&vdma_3 1>;
		dma-names = "port0", "port1";

		ports {
			#address-cells = <1>;
			#size-cells = <0>;

			port@0 {
				reg = <0>;
				direction = "input";
				vcap0_in0: endpoint {
					remote-endpoint = <&scaler0_out>;
				};
			};
			port@1 {
				reg = <1>;
				direction = "input";
				vcap0_in1: endpoint {
					remote-endpoint = <&switch_out1>;
				};
			};
		};
	};


code:
* Device tree bindings for ARM PL172/PL175/PL176 MultiPort Memory Controller

Required properties:

- compatible:		Must be "arm,primecell" and exactly one from
			"arm,pl172", "arm,pl175" or "arm,pl176".

- reg:			Must contains offset/length value for controller.

- #address-cells:	Must be 2. The partition number has to be encoded in the
			first address cell and it may accept values 0..N-1
			(N - total number of partitions). The second cell is the
			offset into the partition.

- #size-cells:		Must be set to 1.

- ranges:		Must contain one or more chip select memory regions.

- clocks:		Must contain references to controller clocks.

- clock-names:		Must contain "mpmcclk" and "apb_pclk".

- clock-ranges:		Empty property indicating that child nodes can inherit
			named clocks. Required only if clock tree data present
			in device tree.
			See clock-bindings.txt

Child chip-select (cs) nodes contain the memory devices nodes connected to
such as NOR (e.g. cfi-flash) and NAND.

Required child cs node properties:

- #address-cells:	Must be 2.

- #size-cells:		Must be 1.

- ranges:		Empty property indicating that child nodes can inherit
			memory layout.

- clock-ranges:		Empty property indicating that child nodes can inherit
			named clocks. Required only if clock tree data present
			in device tree.

- mpmc,cs:		Chip select number. Indicates to the pl0172 driver
			which chipselect is used for accessing the memory.

- mpmc,memory-width:	Width of the chip select memory. Must be equal to
			either 8, 16 or 32.

Optional child cs node config properties:

- mpmc,async-page-mode:	Enable asynchronous page mode.

- mpmc,cs-active-high:	Set chip select polarity to active high.

- mpmc,byte-lane-low:	Set byte lane state to low.

- mpmc,extended-wait:	Enable extended wait.

- mpmc,buffer-enable:	Enable write buffer, option is not supported by
			PL175 and PL176 controllers.

- mpmc,write-protect:	Enable write protect.

Optional child cs node timing properties:

- mpmc,write-enable-delay:	Delay from chip select assertion to write
				enable (WE signal) in nano seconds.

- mpmc,output-enable-delay:	Delay from chip select assertion to output
				enable (OE signal) in nano seconds.

- mpmc,write-access-delay:	Delay from chip select assertion to write
				access in nano seconds.

- mpmc,read-access-delay:	Delay from chip select assertion to read
				access in nano seconds.

- mpmc,page-mode-read-delay:	Delay for asynchronous page mode sequential
				accesses in nano seconds.

- mpmc,turn-round-delay:	Delay between access to memory banks in nano
				seconds.

If any of the above timing parameters are absent, current parameter value will
be taken from the corresponding HW reg.

Example for pl172 with nor flash on chip select 0 shown below.

emc: memory-controller@40005000 {
	compatible = "arm,pl172", "arm,primecell";
	reg = <0x40005000 0x1000>;
	clocks = <&ccu1 CLK_CPU_EMCDIV>, <&ccu1 CLK_CPU_EMC>;
	clock-names = "mpmcclk", "apb_pclk";
	#address-cells = <2>;
	#size-cells = <1>;
	ranges = <0 0 0x1c000000 0x1000000
		  1 0 0x1d000000 0x1000000
		  2 0 0x1e000000 0x1000000
		  3 0 0x1f000000 0x1000000>;

	cs0 {
		#address-cells = <2>;
		#size-cells = <1>;
		ranges;

		mpmc,cs = <0>;
		mpmc,memory-width = <16>;
		mpmc,byte-lane-low;
		mpmc,write-enable-delay = <0>;
		mpmc,output-enable-delay = <0>;
		mpmc,read-enable-delay = <70>;
		mpmc,page-mode-read-delay = <70>;

		flash@0,0 {
			compatible = "sst,sst39vf320", "cfi-flash";
			reg = <0 0 0x400000>;
			bank-width = <2>;
			#address-cells = <1>;
			#size-cells = <1>;
			partition@0 {
				label = "data";
				reg = <0 0x400000>;
			};
		};
	};
};


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/arm,pl35x-smc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Arm PL35x Series Static Memory Controller (SMC)

maintainers:
  - Miquel Raynal <miquel.raynal@bootlin.com>
  - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com>

description: |
  The PL35x Static Memory Controller is a bus where you can connect two kinds
  of memory interfaces, which are NAND and memory mapped interfaces (such as
  SRAM or NOR) depending on the specific configuration.

  The TRM is available here:
  https://documentation-service.arm.com/static/5e8e2524fd977155116a58aa

# We need a select here so we don't match all nodes with 'arm,primecell'
select:
  properties:
    compatible:
      contains:
        enum:
          - arm,pl353-smc-r2p1
          - arm,pl354
  required:
    - compatible

properties:
  $nodename:
    pattern: "^memory-controller@[0-9a-f]+$"

  compatible:
    items:
      - enum:
          - arm,pl353-smc-r2p1
          - arm,pl354
      - const: arm,primecell

  "#address-cells":
    const: 2

  "#size-cells":
    const: 1

  reg:
    items:
      - description:
          Configuration registers for the host and sub-controllers.
          The three chip select regions are defined in 'ranges'.

  clocks:
    minItems: 1
    maxItems: 2

  clock-names:
    minItems: 1
    maxItems: 2

  ranges:
    minItems: 1
    maxItems: 8

  interrupts:
    minItems: 1
    items:
      - description: Combined or Memory interface 0 IRQ
      - description: Memory interface 1 IRQ

patternProperties:
  "@[0-7],[a-f0-9]+$":
    type: object
    description: |
      The child device node represents the controller connected to the SMC
      bus. The controller can be a NAND controller or a pair of any memory
      mapped controllers such as NOR and SRAM controllers.

    properties:
      compatible:
        description:
          Compatible of memory controller.

      reg:
        items:
          - items:
              - description: |
                  Chip-select ID, as in the parent range property.
                minimum: 0
                maximum: 7
              - description: |
                  Offset of the memory region requested by the device.
              - description: |
                  Length of the memory region requested by the device.

    required:
      - compatible
      - reg

required:
  - compatible
  - reg
  - clock-names
  - clocks

additionalProperties: false

allOf:
  - if:
      properties:
        compatible:
          contains:
            const: arm,pl354
    then:
      properties:
        clocks:
          # According to TRM, really should be 3 clocks
          maxItems: 1

        clock-names:
          const: apb_pclk

    else:
      properties:
        clocks:
          items:
            - description: clock for the memory device bus
            - description: main clock of the SMC

        clock-names:
          items:
            - const: memclk
            - const: apb_pclk

examples:
  - |
    smcc: memory-controller@e000e000 {
      compatible = "arm,pl353-smc-r2p1", "arm,primecell";
      reg = <0xe000e000 0x0001000>;
      clock-names = "memclk", "apb_pclk";
      clocks = <&clkc 11>, <&clkc 44>;
      ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */
                0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */
                0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */
      #address-cells = <2>;
      #size-cells = <1>;

      nfc0: nand-controller@0,0 {
        compatible = "arm,pl353-nand-r2p1";
        reg = <0 0 0x1000000>;
        #address-cells = <1>;
        #size-cells = <0>;
      };
    };


code:
* Device tree bindings for Atmel EBI

The External Bus Interface (EBI) controller is a bus where you can connect
asynchronous (NAND, NOR, SRAM, ....) and synchronous memories (SDR/DDR SDRAMs).
The EBI provides a glue-less interface to asynchronous memories through the SMC
(Static Memory Controller).

Required properties:

- compatible:		"atmel,at91sam9260-ebi"
			"atmel,at91sam9261-ebi"
			"atmel,at91sam9263-ebi0"
			"atmel,at91sam9263-ebi1"
			"atmel,at91sam9rl-ebi"
			"atmel,at91sam9g45-ebi"
			"atmel,at91sam9x5-ebi"
			"atmel,sama5d3-ebi"
			"microchip,sam9x60-ebi"

- reg:			Contains offset/length value for EBI memory mapping.
			This property might contain several entries if the EBI
			memory range is not contiguous

- #address-cells:	Must be 2.
			The first cell encodes the CS.
			The second cell encode the offset into the CS memory
			range.

- #size-cells:		Must be set to 1.

- ranges:		Encodes CS to memory region association.

- clocks:		Clock feeding the EBI controller.
			See clock-bindings.txt

Children device nodes are representing device connected to the EBI bus.

Required device node properties:

- reg:			Contains the chip-select id, the offset and the length
			of the memory region requested by the device.

EBI bus configuration will be defined directly in the device subnode.

Optional EBI/SMC properties:

- atmel,smc-bus-width:		width of the asynchronous device's data bus
				8, 16 or 32.
				Default to 8 when undefined.

- atmel,smc-byte-access-type	"write" or "select" (see Atmel datasheet).
				Default to "select" when undefined.

- atmel,smc-read-mode		"nrd" or "ncs".
				Default to "ncs" when undefined.

- atmel,smc-write-mode		"nwe" or "ncs".
				Default to "ncs" when undefined.

- atmel,smc-exnw-mode		"disabled", "frozen" or "ready".
				Default to "disabled" when undefined.

- atmel,smc-page-mode		enable page mode if present. The provided value
				defines the page size (supported values: 4, 8,
				16 and 32).

- atmel,smc-tdf-mode:		"normal" or "optimized". When set to
				"optimized" the data float time is optimized
				depending on the next device being accessed
				(next device setup time is subtracted to the
				current device data float time).
				Default to "normal" when undefined.

If at least one atmel,smc- property is defined the following SMC timing
properties become mandatory. In the other hand, if none of the atmel,smc-
properties are specified, we assume that the EBI bus configuration will be
handled by the sub-device driver, and none of those properties should be
defined.

All the timings are expressed in nanoseconds (see Atmel datasheet for a full
description).

- atmel,smc-ncs-rd-setup-ns
- atmel,smc-nrd-setup-ns
- atmel,smc-ncs-wr-setup-ns
- atmel,smc-nwe-setup-ns
- atmel,smc-ncs-rd-pulse-ns
- atmel,smc-nrd-pulse-ns
- atmel,smc-ncs-wr-pulse-ns
- atmel,smc-nwe-pulse-ns
- atmel,smc-nwe-cycle-ns
- atmel,smc-nrd-cycle-ns
- atmel,smc-tdf-ns

Example:

	ebi: ebi@10000000 {
		compatible = "atmel,sama5d3-ebi";
		#address-cells = <2>;
		#size-cells = <1>;
		atmel,smc = <&hsmc>;
		atmel,matrix = <&matrix>;
		reg = <0x10000000 0x10000000
		       0x40000000 0x30000000>;
		ranges = <0x0 0x0 0x10000000 0x10000000
			  0x1 0x0 0x40000000 0x10000000
			  0x2 0x0 0x50000000 0x10000000
			  0x3 0x0 0x60000000 0x10000000>;
		clocks = <&mck>;

		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_ebi_addr>;

		nor: flash@0,0 {
			compatible = "cfi-flash";
			#address-cells = <1>;
			#size-cells = <1>;
			reg = <0x0 0x0 0x1000000>;
			bank-width = <2>;

			atmel,smc-read-mode = "nrd";
			atmel,smc-write-mode = "nwe";
			atmel,smc-bus-width = <16>;
			atmel,smc-ncs-rd-setup-ns = <0>;
			atmel,smc-ncs-wr-setup-ns = <0>;
			atmel,smc-nwe-setup-ns = <8>;
			atmel,smc-nrd-setup-ns = <16>;
			atmel,smc-ncs-rd-pulse-ns = <84>;
			atmel,smc-ncs-wr-pulse-ns = <84>;
			atmel,smc-nrd-pulse-ns = <76>;
			atmel,smc-nwe-pulse-ns = <76>;
			atmel,smc-nrd-cycle-ns = <107>;
			atmel,smc-nwe-cycle-ns = <84>;
			atmel,smc-tdf-ns = <16>;
		};
	};


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/baikal,bt1-l2-ctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Baikal-T1 L2-cache Control Block

maintainers:
  - Serge Semin <fancer.lancer@gmail.com>

description: |
  By means of the System Controller Baikal-T1 SoC exposes a few settings to
  tune the MIPS P5600 CM2 L2 cache performance up. In particular it's possible
  to change the Tag, Data and Way-select RAM access latencies. Baikal-T1
  L2-cache controller block is responsible for the tuning. Its DT node is
  supposed to be a child of the system controller.

properties:
  compatible:
    const: baikal,bt1-l2-ctl

  reg:
    maxItems: 1

  baikal,l2-ws-latency:
    $ref: /schemas/types.yaml#/definitions/uint32
    description: Cycles of latency for Way-select RAM accesses
    default: 0
    minimum: 0
    maximum: 3

  baikal,l2-tag-latency:
    $ref: /schemas/types.yaml#/definitions/uint32
    description: Cycles of latency for Tag RAM accesses
    default: 0
    minimum: 0
    maximum: 3

  baikal,l2-data-latency:
    $ref: /schemas/types.yaml#/definitions/uint32
    description: Cycles of latency for Data RAM accesses
    default: 1
    minimum: 0
    maximum: 3

additionalProperties: false

required:
  - compatible

examples:
  - |
    l2@1f04d028 {
      compatible = "baikal,bt1-l2-ctl";
      reg = <0x1f04d028 0x004>;

      baikal,l2-ws-latency = <1>;
      baikal,l2-tag-latency = <1>;
      baikal,l2-data-latency = <2>;
    };
...


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/brcm,brcmstb-memc-ddr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Memory controller (MEMC) for Broadcom STB

maintainers:
  - Florian Fainelli <f.fainelli@gmail.com>

properties:
  compatible:
    items:
      - enum:
          - brcm,brcmstb-memc-ddr-rev-b.1.x
          - brcm,brcmstb-memc-ddr-rev-b.2.0
          - brcm,brcmstb-memc-ddr-rev-b.2.1
          - brcm,brcmstb-memc-ddr-rev-b.2.2
          - brcm,brcmstb-memc-ddr-rev-b.2.3
          - brcm,brcmstb-memc-ddr-rev-b.2.5
          - brcm,brcmstb-memc-ddr-rev-b.2.6
          - brcm,brcmstb-memc-ddr-rev-b.2.7
          - brcm,brcmstb-memc-ddr-rev-b.2.8
          - brcm,brcmstb-memc-ddr-rev-b.3.0
          - brcm,brcmstb-memc-ddr-rev-b.3.1
          - brcm,brcmstb-memc-ddr-rev-c.1.0
          - brcm,brcmstb-memc-ddr-rev-c.1.1
          - brcm,brcmstb-memc-ddr-rev-c.1.2
          - brcm,brcmstb-memc-ddr-rev-c.1.3
          - brcm,brcmstb-memc-ddr-rev-c.1.4
      - const: brcm,brcmstb-memc-ddr

  reg:
    maxItems: 1

  clock-frequency:
    description: DDR PHY frequency in Hz

required:
  - compatible
  - reg

additionalProperties: false

examples:
  - |
    memory-controller@9902000 {
        compatible = "brcm,brcmstb-memc-ddr-rev-c.1.1", "brcm,brcmstb-memc-ddr";
        reg = <0x9902000 0x600>;
        clock-frequency = <2133000000>;
    };


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/brcm,dpfe-cpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: DDR PHY Front End (DPFE) for Broadcom STB

maintainers:
  - Krzysztof Kozlowski <krzk@kernel.org>
  - Markus Mayer <mmayer@broadcom.com>

properties:
  compatible:
    items:
      - enum:
          - brcm,bcm7271-dpfe-cpu
          - brcm,bcm7268-dpfe-cpu
      - const: brcm,dpfe-cpu

  reg:
    items:
      - description: DCPU register space
      - description: DCPU data memory space
      - description: DCPU instruction memory space

  reg-names:
    items:
      - const: dpfe-cpu
      - const: dpfe-dmem
      - const: dpfe-imem

required:
  - compatible
  - reg
  - reg-names

additionalProperties: false

examples:
  - |
    dpfe-cpu@f1132000 {
        compatible = "brcm,bcm7271-dpfe-cpu", "brcm,dpfe-cpu";
        reg = <0xf1132000 0x180>,
              <0xf1134000 0x1000>,
              <0xf1138000 0x4000>;
        reg-names = "dpfe-cpu", "dpfe-dmem", "dpfe-imem";
    };


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/calxeda-ddr-ctrlr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Calxeda DDR memory controller binding

description: |
  The Calxeda DDR memory controller is initialised and programmed by the
  firmware, but an OS might want to read its registers for error reporting
  purposes and to learn about the DRAM topology.

maintainers:
  - Andre Przywara <andre.przywara@arm.com>

properties:
  compatible:
    enum:
      - calxeda,hb-ddr-ctrl
      - calxeda,ecx-2000-ddr-ctrl

  reg:
    maxItems: 1

  interrupts:
    maxItems: 1

required:
  - compatible
  - reg
  - interrupts

additionalProperties: false

examples:
  - |
    memory-controller@fff00000 {
        compatible = "calxeda,hb-ddr-ctrl";
        reg = <0xfff00000 0x1000>;
        interrupts = <0 91 4>;
    };


code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/canaan,k210-sram.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Canaan K210 SRAM memory controller

description:
  The Canaan K210 SRAM memory controller is responsible for the system's 8 MiB
  of SRAM. The controller is initialised by the bootloader, which configures
  its clocks, before OS bringup.

maintainers:
  - Conor Dooley <conor@kernel.org>

properties:
  compatible:
    enum:
      - canaan,k210-sram

  clocks:
    minItems: 1
    items:
      - description: sram0 clock
      - description: sram1 clock
      - description: aisram clock

  clock-names:
    minItems: 1
    items:
      - const: sram0
      - const: sram1
      - const: aisram

required:
  - compatible
  - clocks
  - clock-names

additionalProperties: false

examples:
  - |
    #include <dt-bindings/clock/k210-clk.h>
    memory-controller {
        compatible = "canaan,k210-sram";
        clocks = <&sysclk K210_CLK_SRAM0>,
                 <&sysclk K210_CLK_SRAM1>,
                 <&sysclk K210_CLK_AI>;
        clock-names = "sram0", "sram1", "aisram";
    };