Merge tag 'drm-misc-next-2017-04-07' of git://anongit.freedesktop.org/git/drm-misc into drm-next

Amlogic specific extensions to the Synopsys Designware HDMI Controller

======================================================================

The Amlogic Meson Synopsys Designware Integration is composed of :

- A Synopsys DesignWare HDMI Controller IP

- A TOP control block controlling the Clocks and PHY

- A custom HDMI PHY in order to convert video to TMDS signal

 ___________________________________

|            HDMI TOP               |<= HPD

|___________________________________|

|                  |                |

|  Synopsys HDMI   |   HDMI PHY     |=> TMDS

|    Controller    |________________|

|___________________________________|<=> DDC

The HDMI TOP block only supports HPD sensing.

The Synopsys HDMI Controller interrupt is routed through the

TOP Block interrupt.

Communication to the TOP Block and the Synopsys HDMI Controller is done

via a pair of dedicated addr+read/write registers.

The HDMI PHY is configured by registers in the HHI register block.

Pixel data arrives in 4:4:4 format from the VENC block and the VPU HDMI mux

selects either the ENCI encoder for the 576i or 480i formats or the ENCP

encoder for all the other formats including interlaced HD formats.

The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate

DVI timings for the HDMI controller.

Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare

HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF

audio source interfaces.

Required properties:

- compatible: value should be different for each SoC family as :

	- GXBB (S905) : "amlogic,meson-gxbb-dw-hdmi"

	- GXL (S905X, S905D) : "amlogic,meson-gxl-dw-hdmi"

	- GXM (S912) : "amlogic,meson-gxm-dw-hdmi"

	followed by the common "amlogic,meson-gx-dw-hdmi"

- reg: Physical base address and length of the controller's registers.

- interrupts: The HDMI interrupt number

- clocks, clock-names : must have the phandles to the HDMI iahb and isfr clocks,

  and the Amlogic Meson venci clocks as described in

  Documentation/devicetree/bindings/clock/clock-bindings.txt,

  the clocks are soc specific, the clock-names should be "iahb", "isfr", "venci"

- resets, resets-names: must have the phandles to the HDMI apb, glue and phy

  resets as described in :

  Documentation/devicetree/bindings/reset/reset.txt,

  the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy"

Required nodes:

The connections to the HDMI ports are modeled using the OF graph

bindings specified in Documentation/devicetree/bindings/graph.txt.

The following table lists for each supported model the port number

corresponding to each HDMI output and input.

		Port 0		Port 1

-----------------------------------------

 S905 (GXBB)	VENC Input	TMDS Output

 S905X (GXL)	VENC Input	TMDS Output

 S905D (GXL)	VENC Input	TMDS Output

 S912 (GXM)	VENC Input	TMDS Output

Example:

hdmi-connector {

	compatible = "hdmi-connector";

	type = "a";

	port {

		hdmi_connector_in: endpoint {

			remote-endpoint = <&hdmi_tx_tmds_out>;

		};

	};

};

hdmi_tx: hdmi-tx@c883a000 {

	compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";

	reg = <0x0 0xc883a000 0x0 0x1c>;

	interrupts = <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;

	resets = <&reset RESET_HDMITX_CAPB3>,

		 <&reset RESET_HDMI_SYSTEM_RESET>,

		 <&reset RESET_HDMI_TX>;

	reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";

	clocks = <&clkc CLKID_HDMI_PCLK>,

		 <&clkc CLKID_CLK81>,

		 <&clkc CLKID_GCLK_VENCI_INT0>;

	clock-names = "isfr", "iahb", "venci";

	#address-cells = <1>;

	#size-cells = <0>;

	/* VPU VENC Input */

	hdmi_tx_venc_port: port@0 {

		reg = <0>;

		hdmi_tx_in: endpoint {

			remote-endpoint = <&hdmi_tx_out>;

		};

	};

	/* TMDS Output */

	hdmi_tx_tmds_port: port@1 {

		reg = <1>;

		hdmi_tx_tmds_out: endpoint {

			remote-endpoint = <&hdmi_connector_in>;

		};

	};

};

Optional properties:

- power-domains: a phandle to mipi dsi power domain node.

- resets: list of phandle + reset specifier pairs, as described in [3].

- reset-names: string reset name, must be "apb".

[1] Documentation/devicetree/bindings/clock/clock-bindings.txt

[2] Documentation/devicetree/bindings/media/video-interfaces.txt

[3] Documentation/devicetree/bindings/reset/reset.txt

Example:

	mipi_dsi: mipi@ff960000 {

		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;

		clocks = <&cru SCLK_MIPI_24M>, <&cru PCLK_MIPI_DSI0>;

		clock-names = "ref", "pclk";

		resets = <&cru SRST_MIPIDSI0>;

		reset-names = "apb";

		rockchip,grf = <&grf>;

		status = "okay";

=======================================================

 drm/bridge/dw-hdmi Synopsys DesignWare HDMI Controller

=======================================================

Synopsys DesignWare HDMI Controller

===================================

This section covers everything related to the Synopsys DesignWare HDMI

Controller implemented as a DRM bridge.

Supported Input Formats and Encodings

-------------------------------------

.. kernel-doc:: include/drm/bridge/dw_hdmi.h

   :doc: Supported input formats and encodings

.. kernel-doc:: drivers/gpu/drm/drm_file.c

   :export:

IOCTLs

------

struct drm_ioctl_desc \*ioctls; int num_ioctls;

    Driver-specific ioctls descriptors table.

Driver-specific ioctls numbers start at DRM_COMMAND_BASE. The ioctls

descriptors table is indexed by the ioctl number offset from the base

value. Drivers can use the DRM_IOCTL_DEF_DRV() macro to initialize

the table entries.

::

    DRM_IOCTL_DEF_DRV(ioctl, func, flags)

``ioctl`` is the ioctl name. Drivers must define the DRM_##ioctl and

DRM_IOCTL_##ioctl macros to the ioctl number offset from

DRM_COMMAND_BASE and the ioctl number respectively. The first macro is

private to the device while the second must be exposed to userspace in a

public header.

``func`` is a pointer to the ioctl handler function compatible with the

``drm_ioctl_t`` type.

::

    typedef int drm_ioctl_t(struct drm_device *dev, void *data,

            struct drm_file *file_priv);

``flags`` is a bitmask combination of the following values. It restricts

how the ioctl is allowed to be called.

-  DRM_AUTH - Only authenticated callers allowed

-  DRM_MASTER - The ioctl can only be called on the master file handle

-  DRM_ROOT_ONLY - Only callers with the SYSADMIN capability allowed

-  DRM_CONTROL_ALLOW - The ioctl can only be called on a control

   device

-  DRM_UNLOCKED - The ioctl handler will be called without locking the

   DRM global mutex. This is the enforced default for kms drivers (i.e.

   using the DRIVER_MODESET flag) and hence shouldn't be used any more

   for new drivers.

.. kernel-doc:: drivers/gpu/drm/drm_ioctl.c

   :export:

Misc Utilities

==============

visible to user-space and accessible beyond open-file boundaries, they

cannot support render nodes.

IOCTL Support on Device Nodes

=============================

.. kernel-doc:: drivers/gpu/drm/drm_ioctl.c

   :doc: driver specific ioctls

.. kernel-doc:: include/drm/drm_ioctl.h

   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_ioctl.c

   :export:

.. kernel-doc:: drivers/gpu/drm/drm_ioc32.c

   :export:

Testing and validation

======================

.. kernel-doc:: drivers/gpu/drm/drm_debugfs.c

   :export:

Sysfs Support

=============

.. kernel-doc:: drivers/gpu/drm/drm_sysfs.c

   :doc: overview

.. kernel-doc:: drivers/gpu/drm/drm_sysfs.c

   :export:

VBlank event handling

=====================