Merge drm/drm-next into drm-misc-next (d588100b) · Commits · EulixOS / Software / Kernel

Documentation/devicetree/bindings/display/arm,komeda.txt

0 → 100644

+73 −0

Original line number	Diff line number	Diff line
		Device Tree bindings for Arm Komeda display driver

		Required properties:
		- compatible: Should be "arm,mali-d71"
		- reg: Physical base address and length of the registers in the system
		- interrupts: the interrupt line number of the device in the system
		- clocks: A list of phandle + clock-specifier pairs, one for each entry
		in 'clock-names'
		- clock-names: A list of clock names. It should contain:
		- "mclk": for the main processor clock
		- "pclk": for the APB interface clock
		- #address-cells: Must be 1
		- #size-cells: Must be 0

		Required properties for sub-node: pipeline@nq
		Each device contains one or two pipeline sub-nodes (at least one), each
		pipeline node should provide properties:
		- reg: Zero-indexed identifier for the pipeline
		- clocks: A list of phandle + clock-specifier pairs, one for each entry
		in 'clock-names'
		- clock-names: should contain:
		- "pxclk": pixel clock
		- "aclk": AXI interface clock

		- port: each pipeline connect to an encoder input port. The connection is
		modeled using the OF graph bindings specified in
		Documentation/devicetree/bindings/graph.txt

		Optional properties:
		- memory-region: phandle to a node describing memory (see
		Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
		to be used for the framebuffer; if not present, the framebuffer may
		be located anywhere in memory.

		Example:
		/ {
		...

		dp0: display@c00000 {
		#address-cells = <1>;
		#size-cells = <0>;
		compatible = "arm,mali-d71";
		reg = <0xc00000 0x20000>;
		interrupts = <0 168 4>;
		clocks = <&dpu_mclk>, <&dpu_aclk>;
		clock-names = "mclk", "pclk";

		dp0_pipe0: pipeline@0 {
		clocks = <&fpgaosc2>, <&dpu_aclk>;
		clock-names = "pxclk", "aclk";
		reg = <0>;

		port {
		dp0_pipe0_out: endpoint {
		remote-endpoint = <&db_dvi0_in>;
		};
		};
		};

		dp0_pipe1: pipeline@1 {
		clocks = <&fpgaosc2>, <&dpu_aclk>;
		clock-names = "pxclk", "aclk";
		reg = <1>;

		port {
		dp0_pipe1_out: endpoint {
		remote-endpoint = <&db_dvi1_in>;
		};
		};
		};
		};
		...
		};

Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt

+1 −0

Original line number	Diff line number	Diff line
		@@ -8,6 +8,7 @@ Required properties:

		- compatible : Shall contain one of
		- "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders
		- "renesas,r8a7744-lvds" for R8A7744 (RZ/G1N) compatible LVDS encoders
		- "renesas,r8a774c0-lvds" for R8A774C0 (RZ/G2E) compatible LVDS encoders
		- "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders
		- "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders

Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt

+3 −0

Original line number	Diff line number	Diff line
		@@ -238,6 +238,9 @@ of the following host1x client modules:
		- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
		- nvidia,edid: supplies a binary EDID blob
		- nvidia,panel: phandle of a display panel
		- nvidia,xbar-cfg: 5 cells containing the crossbar configuration. Each lane
		of the SOR, identified by the cell's index, is mapped via the crossbar to
		the pad specified by the cell's value.

		Optional properties when driving an eDP output:
		- nvidia,dpaux: phandle to a DispayPort AUX interface

Documentation/devicetree/bindings/gpu/samsung-rotator.txt

+4 −3

Original line number	Diff line number	Diff line
		@@ -2,9 +2,10 @@

		Required properties:
		- compatible : value should be one of the following:
		(a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
		(b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
		(c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250
		* "samsung,s5pv210-rotator" for Rotator IP in S5PV210
		* "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
		* "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
		* "samsung,exynos5250-rotator" for Rotator IP in Exynos5250

		- reg : Physical base address of the IP registers and length of memory
		mapped region.

Documentation/gpu/afbc.rst

0 → 100644

+235 −0

Original line number	Diff line number	Diff line
		.. SPDX-License-Identifier: GPL-2.0+

		===================================
		Arm Framebuffer Compression (AFBC)
		===================================

		AFBC is a proprietary lossless image compression protocol and format.
		It provides fine-grained random access and minimizes the amount of
		data transferred between IP blocks.

		AFBC can be enabled on drivers which support it via use of the AFBC
		format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*).

		All users of the AFBC modifiers must follow the usage guidelines laid
		out in this document, to ensure compatibility across different AFBC
		producers and consumers.

		Components and Ordering
		=======================

		AFBC streams can contain several components - where a component
		corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr).
		The assignment of input/output color channels must be consistent
		between the encoder and the decoder for correct operation, otherwise
		the consumer will interpret the decoded data incorrectly.

		Furthermore, when the lossless colorspace transform is used
		(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for
		maximum compression efficiency), the component order must be:

		* Component 0: R
		* Component 1: G
		* Component 2: B

		The component ordering is communicated via the fourcc code in the
		fourcc:modifier pair. In general, component '0' is considered to
		reside in the least-significant bits of the corresponding linear
		format. For example, COMP(bits):

		* DRM_FORMAT_ABGR8888

		* Component 0: R(8)
		* Component 1: G(8)
		* Component 2: B(8)
		* Component 3: A(8)

		* DRM_FORMAT_BGR888

		* Component 0: R(8)
		* Component 1: G(8)
		* Component 2: B(8)

		* DRM_FORMAT_YUYV

		* Component 0: Y(8)
		* Component 1: Cb(8, 2x1 subsampled)
		* Component 2: Cr(8, 2x1 subsampled)

		In AFBC, 'X' components are not treated any differently from any other
		component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR8888
		encodes with 4 components, like so:

		* DRM_FORMAT_XBGR8888

		* Component 0: R(8)
		* Component 1: G(8)
		* Component 2: B(8)
		* Component 3: X(8)

		Please note, however, that the inclusion of a "wasted" 'X' channel is
		bad for compression efficiency, and so it's recommended to avoid
		formats containing 'X' bits. If a fourth component is
		required/expected by the encoder/decoder, then it is recommended to
		instead use an equivalent format with alpha, setting all alpha bits to
		'1'. If there is no requirement for a fourth component, then a format
		which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888.

		Number of Planes
		================

		Formats which are typically multi-planar in linear layouts (e.g. YUV
		420), can be encoded into one, or multiple, AFBC planes. As with
		component order, the encoder and decoder must agree about the number
		of planes in order to correctly decode the buffer. The fourcc code is
		used to determine the number of encoded planes in an AFBC buffer,
		matching the number of planes for the linear (unmodified) format.
		Within each plane, the component ordering also follows the fourcc
		code:

		For example:

		* DRM_FORMAT_YUYV: nplanes = 1

		* Plane 0:

		* Component 0: Y(8)
		* Component 1: Cb(8, 2x1 subsampled)
		* Component 2: Cr(8, 2x1 subsampled)

		* DRM_FORMAT_NV12: nplanes = 2

		* Plane 0:

		* Component 0: Y(8)

		* Plane 1:

		* Component 0: Cb(8, 2x1 subsampled)
		* Component 1: Cr(8, 2x1 subsampled)

		Cross-device interoperability
		=============================

		For maximum compatibility across devices, the table below defines
		canonical formats for use between AFBC-enabled devices. Formats which
		are listed here must be used exactly as specified when using the AFBC
		modifiers. Formats which are not listed should be avoided.

		.. flat-table:: AFBC formats

		* - Fourcc code
		- Description
		- Planes/Components

		* - DRM_FORMAT_ABGR2101010
		- 10-bit per component RGB, with 2-bit alpha
		- Plane 0: 4 components
		* Component 0: R(10)
		* Component 1: G(10)
		* Component 2: B(10)
		* Component 3: A(2)

		* - DRM_FORMAT_ABGR8888
		- 8-bit per component RGB, with 8-bit alpha
		- Plane 0: 4 components
		* Component 0: R(8)
		* Component 1: G(8)
		* Component 2: B(8)
		* Component 3: A(8)

		* - DRM_FORMAT_BGR888
		- 8-bit per component RGB
		- Plane 0: 3 components
		* Component 0: R(8)
		* Component 1: G(8)
		* Component 2: B(8)

		* - DRM_FORMAT_BGR565
		- 5/6-bit per component RGB
		- Plane 0: 3 components
		* Component 0: R(5)
		* Component 1: G(6)
		* Component 2: B(5)

		* - DRM_FORMAT_ABGR1555
		- 5-bit per component RGB, with 1-bit alpha
		- Plane 0: 4 components
		* Component 0: R(5)
		* Component 1: G(5)
		* Component 2: B(5)
		* Component 3: A(1)

		* - DRM_FORMAT_VUY888
		- 8-bit per component YCbCr 444, single plane
		- Plane 0: 3 components
		* Component 0: Y(8)
		* Component 1: Cb(8)
		* Component 2: Cr(8)

		* - DRM_FORMAT_VUY101010
		- 10-bit per component YCbCr 444, single plane
		- Plane 0: 3 components
		* Component 0: Y(10)
		* Component 1: Cb(10)
		* Component 2: Cr(10)

		* - DRM_FORMAT_YUYV
		- 8-bit per component YCbCr 422, single plane
		- Plane 0: 3 components
		* Component 0: Y(8)
		* Component 1: Cb(8, 2x1 subsampled)
		* Component 2: Cr(8, 2x1 subsampled)

		* - DRM_FORMAT_NV16
		- 8-bit per component YCbCr 422, two plane
		- Plane 0: 1 component
		* Component 0: Y(8)
		Plane 1: 2 components
		* Component 0: Cb(8, 2x1 subsampled)
		* Component 1: Cr(8, 2x1 subsampled)

		* - DRM_FORMAT_Y210
		- 10-bit per component YCbCr 422, single plane
		- Plane 0: 3 components
		* Component 0: Y(10)
		* Component 1: Cb(10, 2x1 subsampled)
		* Component 2: Cr(10, 2x1 subsampled)

		* - DRM_FORMAT_P210
		- 10-bit per component YCbCr 422, two plane
		- Plane 0: 1 component
		* Component 0: Y(10)
		Plane 1: 2 components
		* Component 0: Cb(10, 2x1 subsampled)
		* Component 1: Cr(10, 2x1 subsampled)

		* - DRM_FORMAT_YUV420_8BIT
		- 8-bit per component YCbCr 420, single plane
		- Plane 0: 3 components
		* Component 0: Y(8)
		* Component 1: Cb(8, 2x2 subsampled)
		* Component 2: Cr(8, 2x2 subsampled)

		* - DRM_FORMAT_YUV420_10BIT
		- 10-bit per component YCbCr 420, single plane
		- Plane 0: 3 components
		* Component 0: Y(10)
		* Component 1: Cb(10, 2x2 subsampled)
		* Component 2: Cr(10, 2x2 subsampled)

		* - DRM_FORMAT_NV12
		- 8-bit per component YCbCr 420, two plane
		- Plane 0: 1 component
		* Component 0: Y(8)
		Plane 1: 2 components
		* Component 0: Cb(8, 2x2 subsampled)
		* Component 1: Cr(8, 2x2 subsampled)

		* - DRM_FORMAT_P010
		- 10-bit per component YCbCr 420, two plane
		- Plane 0: 1 component
		* Component 0: Y(10)
		Plane 1: 2 components
		* Component 0: Cb(10, 2x2 subsampled)
		* Component 1: Cr(10, 2x2 subsampled)