Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 74b7d6a9 authored by Dave Airlie's avatar Dave Airlie
Browse files

Merge branch 'for-upstream/mali-dp' of git://linux-arm.org/linux-ld into drm-next 



This pull includes the new Arm "komeda" DRM driver. It is currently hosted
in the same repo as the other "mali-dp" driver because it is the next
iteration of the IP.

Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
From: Liviu Dudau <Liviu.Dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190131173600.GN25147@e110455-lin.cambridge.arm.com
parents fb27a3cb dcc9d76b

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/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)

Documentation/gpu/drivers.rst

+2 −0
Original line number Diff line number Diff line
@@ -17,6 +17,8 @@ GPU Driver Documentation 
   vkms

   bridge/dw-hdmi

   xen-front

   afbc

   komeda-kms



.. only::  subproject and html

Documentation/gpu/komeda-kms.rst

0 → 100644
+488 −0

File added.

Preview size limit exceeded, changes collapsed.

MAINTAINERS

+14 −1
Original line number Diff line number Diff line
@@ -1133,13 +1133,26 @@ S: Supported 
F:	drivers/gpu/drm/arm/hdlcd_*

F:	Documentation/devicetree/bindings/display/arm,hdlcd.txt



ARM KOMEDA DRM-KMS DRIVER

M:	James (Qian) Wang <james.qian.wang@arm.com>

M:	Liviu Dudau <liviu.dudau@arm.com>

L:	Mali DP Maintainers <malidp@foss.arm.com>

S:	Supported

T:	git git://linux-arm.org/linux-ld.git for-upstream/mali-dp

F:	drivers/gpu/drm/arm/display/include/

F:	drivers/gpu/drm/arm/display/komeda/

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

F:	Documentation/gpu/komeda-kms.rst



ARM MALI-DP DRM DRIVER

M:	Liviu Dudau <liviu.dudau@arm.com>

M:	Brian Starkey <brian.starkey@arm.com>

M:	Mali DP Maintainers <malidp@foss.arm.com>

L:	Mali DP Maintainers <malidp@foss.arm.com>

S:	Supported

T:	git git://linux-arm.org/linux-ld.git for-upstream/mali-dp

F:	drivers/gpu/drm/arm/

F:	Documentation/devicetree/bindings/display/arm,malidp.txt

F:	Documentation/gpu/afbc.rst



ARM MFM AND FLOPPY DRIVERS

M:	Ian Molton <spyro@f2s.com>