Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-30 15:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1480520625-13269-4-git-send-email-narmstrong@baylibre.com>

Hi Neil,

Thank you for the patch.

On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/meson/meson-drm.txt           | 101 ++++++++++++++++++
> 1 file changed, 101 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/meson/meson-drm.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
> mode 100644
> index 0000000..e52869a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> @@ -0,0 +1,101 @@
> +Amlogic Meson Display Controller
> +================================
> +
> +The Amlogic Meson Display controller is composed of several components
> +that are going to be documented below:
> +
> +DMC|---------------VPU (Video Processing Unit)------------|------HHI------|
> +   | vd1   _______     _____________    _____________     |               |
> +D  |-------|      |----|            |   |            |    |   HDMI PLL    |
> +D  | vd2   | VIU  |    | Video Post |   | Video Encs |<---|-----VCLK      |
> +R  |-------|      |----| Processing |   |            |    |               |
> +   | osd2  |      |    |            |---| Enci ------|----|-----VDAC------|
> +R  |-------| CSC  |----| Scalers    |   | Encp ------|----|----HDMI-TX----|
> +A  | osd1  |      |    | Blenders   |   | Encl-------|----|---------------|
> +M  |-------|______|----|____________|   |____________|    |               |
> +___|______________________________________________________|_______________|
> +
> +
> +VIU: Video Input Unit
> +---------------------
> +
> +The Video Input Unit is in charge of the pixel scanout from the DDR memory.
> +It fetches the frames addresses, stride and parameters from the "Canvas"
> memory.
> +This part is also in charge of the CSC (Colorspace Conversion).
> +It can handle 2 OSD Planes and 2 Video Planes.
> +
> +VPP: Video Post Processing
> +--------------------------
> +
> +The Video Post Processing is in charge of the scaling and blending of the
> +various planes into a single pixel stream.
> +There is a special "pre-blending" used by the video planes with a dedicated
> +scaler and a "post-blending" to merge with the OSD Planes.
> +The OSD planes also have a dedicated scaler for one of the OSD.
> +
> +VENC: Video Encoders
> +--------------------
> +
> +The VENC is composed of the multiple pixel encoders :
> + - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
> + - ENCP : Progressive Video Encoder for HDMI
> + - ENCL : LCD LVDS Encoder
> +The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and
> clock
> +tree and provides the scanout clock to the VPP and VIU.
> +The ENCI is connected to a single VDAC for Composite Output.
> +The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
> +
> +Device Tree Bindings:
> +---------------------
> +
> +VPU: Video Processing Unit
> +--------------------------
> +
> +Required properties:
> +- compatible: value should be different for each SoC family as :
> +	- GXBB (S905) : "amlogic,meson-gxbb-vpu"
> +	- GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
> +	- GXM (S912) : "amlogic,meson-gxm-vpu"
> +	followed by the common "amlogic,meson-gx-vpu"
> +- reg: base address and size of he following memory-mapped regions :
> +	- vpu
> +	- hhi
> +	- dmc
> +- reg-names: should contain the names of the previous memory regions
> +- interrupts: should contain the VENC Vsync interrupt number
> +
> +- ports: A ports node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +  The first port should be connected to a CVBS connector endpoint if
> available.

This is a bit vague, I propose clarifying it with a description similar to the 
one in the renesas,du.txt bindings.

Required nodes:

The connections to the VPU output video 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 DU output.

                Port 0          Port1           Port2           Port3
-----------------------------------------------------------------------------
 R8A7779 (H1)   DPAD 0          DPAD 1          -               -
 R8A7790 (H2)   DPAD            LVDS 0          LVDS 1          -
 R8A7791 (M2-W) DPAD            LVDS 0          -               -
 R8A7792 (V2H)  DPAD 0          DPAD 1          -               -
 R8A7793 (M2-N) DPAD            LVDS 0          -               -
 R8A7794 (E2)   DPAD 0          DPAD 1          -               -
 R8A7795 (H3)   DPAD            HDMI 0          HDMI 1          LVDS
 R8A7796 (M3-W) DPAD            HDMI            LVDS            -

(You should obviously replace the table with Amlogic data)

It doesn't matter if the current driver implementation only supports CVBS, the 
DT bindings can already document the other ports.

> +
> +Example:
> +
> +tv: connector {
> +	compatible = "composite-video-connector";
> +	label = "cvbs";

I'd remove the label here, as it doesn't bring any additional information. 
Unless the board you're using has a label for the connector, in case that 
label should be used.

Apart from that,

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> +	port {
> +		tv_connector_in: endpoint {
> +			remote-endpoint = <&cvbs_vdac_out>;
> +		};
> +	};
> +};
> +
> +vpu: vpu at d0100000 {
> +	compatible = "amlogic,meson-gxbb-vpu";
> +	reg = <0x0 0xd0100000 0x0 0x100000>,
> +	      <0x0 0xc883c000 0x0 0x1000>,
> +	      <0x0 0xc8838000 0x0 0x1000>;
> +	reg-names = "vpu", "hhi", "dmc";
> +	interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	/* CVBS VDAC output port */
> +	port at 0 {
> +		cvbs_vdac_out: endpoint {
> +			reg = <0>;
> +			remote-endpoint = <&tv_connector_in>;
> +		};
> +	};
> +};

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* [GIT PULL 1/2] SoCFPGA DTS update for v4.10, part 3
From: Arnd Bergmann @ 2016-11-30 15:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161121162309.5408-1-dinguyen@kernel.org>

On Monday, November 21, 2016 10:23:08 AM CET Dinh Nguyen wrote:
> SoCFPGA DTS update for v4.10, part 3
> - Fine tune L2 cache configuration
> 

Pulled into next/dt, thanks!

	Arnd

^ permalink raw reply

* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-30 15:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1480520625-13269-4-git-send-email-narmstrong@baylibre.com>

Hi Neil,

On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  .../bindings/display/meson/meson-drm.txt           | 101 ++++++++++++++++++

I forgot to mention that the file should not be named meson-drm.txt as DRM is 
a Linux-specific concept. You can name it meson.txt, but a better option would 
be amlogic,meson.txt. By the way does it really need a subdirectory ?

>  1 file changed, 101 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/meson/meson-drm.txt

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* [GIT PULL 2/2] SoCFPGA update for v4.10
From: Arnd Bergmann @ 2016-11-30 15:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161121162309.5408-2-dinguyen@kernel.org>

On Monday, November 21, 2016 10:23:09 AM CET Dinh Nguyen wrote:
> SoCFPGA update for v4.10
> - Fixup spelling error
> 

Pulled into next/fixes-non-critical, thanks!

	Arnd

^ permalink raw reply

* [PATCH v2 4/4] MAINTAINERS: add entry for Amlogic DRM drivers
From: Laurent Pinchart @ 2016-11-30 15:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1480520625-13269-5-git-send-email-narmstrong@baylibre.com>

Hi Neil,

Thank you for the patch.

On Wednesday 30 Nov 2016 16:43:45 Neil Armstrong wrote:
> Add myself as maintainer for Amlogic DRM drivers.
> 
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>

After updating this patch due to the rename I proposed in patch 3/4,

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> ---
>  MAINTAINERS | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1cd38a7..b2486fb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4078,6 +4078,15 @@ S:	Supported
>  F:	drivers/gpu/drm/sun4i/
>  F:	Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> 
> +DRM DRIVERS FOR AMLOGIC SOCS
> +M:	Neil Armstrong <narmstrong@baylibre.com>
> +L:	dri-devel at lists.freedesktop.org
> +L:	linux-amlogic at lists.infradead.org
> +W:	http://linux-meson.com/
> +S:	Supported
> +F:	drivers/gpu/drm/meson/
> +F:	Documentation/devicetree/bindings/display/meson/meson-drm.txt
> +
>  DRM DRIVERS FOR EXYNOS
>  M:	Inki Dae <inki.dae@samsung.com>
>  M:	Joonyoung Shim <jy0922.shim@samsung.com>

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <2734274.BAOZxRirYz@avalon>

Hi Laurent,
On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
> Hi Neil,
> 
> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  .../bindings/display/meson/meson-drm.txt           | 101 ++++++++++++++++++
> 
> I forgot to mention that the file should not be named meson-drm.txt as DRM is 
> a Linux-specific concept. You can name it meson.txt, but a better option would 
> be amlogic,meson.txt. By the way does it really need a subdirectory ?

I took example of the sun4i layout the naming, and no it does not need a subdirector..

I will move it to amlogic,meson.txt, seems far better.

Thanks,
Neil

>>  1 file changed, 101 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
> 

^ permalink raw reply

* [PATCH v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Laurent Pinchart @ 2016-11-30 16:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1480520625-13269-3-git-send-email-narmstrong@baylibre.com>

Hi Neil,

Thank you for the patch.

On Wednesday 30 Nov 2016 16:43:43 Neil Armstrong wrote:
> Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
> boards.
> 
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi             | 19 ++++++++++++++++
>  .../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi      | 15 +++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi           |  4 ++++
>  arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi            |  4 ++++
>  arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts   | 15 +++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxm.dtsi            |  4 ++++
>  8 files changed, 91 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi index fc033c0..a27f881 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -356,5 +356,24 @@
>  				status = "disabled";
>  			};
>  		};
> +
> +		vpu: vpu at d0100000 {
> +			compatible = "amlogic,meson-gx-vpu";
> +			reg = <0x0 0xd0100000 0x0 0x100000>,
> +			      <0x0 0xc883c000 0x0 0x1000>,
> +			      <0x0 0xc8838000 0x0 0x1000>;
> +			reg-names = "vpu", "hhi", "dmc";
> +			interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			/* CVBS VDAC output port */
> +			port at 0 {
> +				reg = <0>;
> +
> +				cvbs_vdac_out: endpoint {
> +				};

Endpoints require a remote-endpoint property. You should move the endpoint to 
board DT files.

> +			};
> +		};
>  	};
>  };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts index
> 9696820..390f7db 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> @@ -142,6 +142,17 @@
>  		clocks = <&wifi32k>;
>  		clock-names = "ext_clock";
>  	};
> +
> +	cvbs-connector {
> +		compatible = "composite-video-connector";
> +		label = "cvbs";

Unless the board has a label for the connector (either on the board, on the 
casing or in the user manual) I'd leave this out. Same comment for the other 
boards.

Apart from that,

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> +
> +		port {
> +			cvbs_connector_in: endpoint {
> +				remote-endpoint = <&cvbs_vdac_out>;
> +			};
> +		};
> +	};
>  };
> 
>  &uart_AO {
> @@ -229,3 +240,7 @@
>  	clocks = <&clkc CLKID_FCLK_DIV4>;
>  	clock-names = "clkin0";
>  };
> +
> +&cvbs_vdac_out {
> +	remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi index 203be28..44bdebf
> 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -125,6 +125,17 @@
>  		clocks = <&wifi32k>;
>  		clock-names = "ext_clock";
>  	};
> +
> +	cvbs-connector {
> +		compatible = "composite-video-connector";
> +		label = "cvbs";
> +
> +		port {
> +			cvbs_connector_in: endpoint {
> +				remote-endpoint = <&cvbs_vdac_out>;
> +			};
> +		};
> +	};
>  };
> 
>  /* This UART is brought out to the DB9 connector */
> @@ -234,3 +245,7 @@
>  	clocks = <&clkc CLKID_FCLK_DIV4>;
>  	clock-names = "clkin0";
>  };
> +
> +&cvbs_vdac_out {
> +	remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index ac5ad3b..5353a20 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -506,3 +506,7 @@
>  		 <&clkc CLKID_FCLK_DIV2>;
>  	clock-names = "core", "clkin0", "clkin1";
>  };
> +
> +&vpu {
> +	compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts index
> e99101a..7bd0538 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> @@ -117,6 +117,17 @@
>  		clocks = <&wifi32k>;
>  		clock-names = "ext_clock";
>  	};
> +
> +	cvbs-connector {
> +		compatible = "composite-video-connector";
> +		label = "cvbs";
> +
> +		port {
> +			cvbs_connector_in: endpoint {
> +				remote-endpoint = <&cvbs_vdac_out>;
> +			};
> +		};
> +	};
>  };
> 
>  &uart_AO {
> @@ -203,3 +214,7 @@
>  	clocks = <&clkc CLKID_FCLK_DIV4>;
>  	clock-names = "clkin0";
>  };
> +
> +&cvbs_vdac_out {
> +	remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index 9f89b99..5c7a8fa 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -299,3 +299,7 @@
>  		 <&clkc CLKID_FCLK_DIV2>;
>  	clock-names = "core", "clkin0", "clkin1";
>  };
> +
> +&vpu {
> +	compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts index
> d320727..5b99749 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -90,6 +90,17 @@
>  		compatible = "mmc-pwrseq-emmc";
>  		reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
>  	};
> +
> +	cvbs-connector {
> +		compatible = "composite-video-connector";
> +		label = "cvbs";
> +
> +		port {
> +			cvbs_connector_in: endpoint {
> +				remote-endpoint = <&cvbs_vdac_out>;
> +			};
> +		};
> +	};
>  };
> 
>  /* This UART is brought out to the DB9 connector */
> @@ -167,3 +178,7 @@
>  		max-speed = <1000>;
>  	};
>  };
> +
> +&cvbs_vdac_out {
> +	remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi index c1974bb..eb2f0c3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> @@ -112,3 +112,7 @@
>  		};
>  	};
>  };
> +
> +&vpu {
> +	compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
> +};

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* [PATCH v2 1/4] drm: Add support for Amlogic Meson Graphic Controller
From: Laurent Pinchart @ 2016-11-30 16:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1480520625-13269-2-git-send-email-narmstrong@baylibre.com>

Hi Neil,

Thank you for the patch.

I'm afraid I don't have time for a complete review, but could you please get 
rid of the of_machine_is_compatible() calls and match on the VPU compatible 
string instead ?

On Wednesday 30 Nov 2016 16:43:42 Neil Armstrong wrote:
> The Amlogic Meson Display controller is composed of several components :
> 
> DMC|---------------VPU (Video Processing
> Unit)----------------|------HHI------| |
> vd1   _______     _____________    _________________     |               |
> D  |-------|      |----|            |   |                |    |   HDMI
> PLL    | D  | vd2   | VIU  |    | Video Post |   | Video Encoders
> |<---|-----VCLK      | R  |-------|      |----| Processing
> |   |                |    |               | |
> osd2  |      |    |            |---| Enci ----------|----|-----VDAC------|
> R  |-------| CSC  |----| Scalers    |   | Encp
> ----------|----|----HDMI-TX----| A  | osd1  |      |    | Blenders   |   |
> Encl ----------|----|---------------|
> M  |-------|______|----|____________|   |________________|    |            
>    |
> ___|__________________________________________________________|____________
> ___|
> 
> VIU: Video Input Unit
> ---------------------
> 
> The Video Input Unit is in charge of the pixel scanout from the DDR memory.
> It fetches the frames addresses, stride and parameters from the "Canvas"
> memory. This part is also in charge of the CSC (Colorspace Conversion).
> It can handle 2 OSD Planes and 2 Video Planes.
> 
> VPP: Video Post Processing
> --------------------------
> 
> The Video Post Processing is in charge of the scaling and blending of the
> various planes into a single pixel stream.
> There is a special "pre-blending" used by the video planes with a dedicated
> scaler and a "post-blending" to merge with the OSD Planes.
> The OSD planes also have a dedicated scaler for one of the OSD.
> 
> VENC: Video Encoders
> --------------------
> 
> The VENC is composed of the multiple pixel encoders :
>  - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
>  - ENCP : Progressive Video Encoder for HDMI
>  - ENCL : LCD LVDS Encoder
> The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
> tree and provides the scanout clock to the VPP and VIU.
> The ENCI is connected to a single VDAC for Composite Output.
> The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
> 
> This driver is a DRM/KMS driver using the following DRM components :
>  - GEM-CMA
>  - PRIME-CMA
>  - Atomic Modesetting
>  - FBDev-CMA
> 
> For the following SoCs :
>  - GXBB Family (S905)
>  - GXL Family (S905X, S905D)
>  - GXM Family (S912)
> 
> The current driver only supports the CVBS PAL/NTSC output modes, but the
> CRTC/Planes management should support bigger modes.
> But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in
> a second time.
> 
> The Device Tree bindings makes use of the endpoints video interface
> definitions to connect to the optional CVBS and in the future the HDMI
> Connector nodes.
> 
> HDMI Support is planned for a next release.
> 
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  drivers/gpu/drm/Kconfig                 |    2 +
>  drivers/gpu/drm/Makefile                |    1 +
>  drivers/gpu/drm/meson/Kconfig           |    9 +
>  drivers/gpu/drm/meson/Makefile          |    4 +
>  drivers/gpu/drm/meson/meson_canvas.c    |   68 ++
>  drivers/gpu/drm/meson/meson_canvas.h    |   42 +
>  drivers/gpu/drm/meson/meson_crtc.c      |  208 +++++
>  drivers/gpu/drm/meson/meson_crtc.h      |   32 +
>  drivers/gpu/drm/meson/meson_drv.c       |  343 ++++++++
>  drivers/gpu/drm/meson/meson_drv.h       |   60 ++
>  drivers/gpu/drm/meson/meson_plane.c     |  230 +++++
>  drivers/gpu/drm/meson/meson_plane.h     |   30 +
>  drivers/gpu/drm/meson/meson_registers.h | 1395 ++++++++++++++++++++++++++++
>  drivers/gpu/drm/meson/meson_vclk.c      |  167 ++++
>  drivers/gpu/drm/meson/meson_vclk.h      |   34 +
>  drivers/gpu/drm/meson/meson_venc.c      |  254 ++++++
>  drivers/gpu/drm/meson/meson_venc.h      |   72 ++
>  drivers/gpu/drm/meson/meson_venc_cvbs.c |  293 +++++++
>  drivers/gpu/drm/meson/meson_venc_cvbs.h |   41 +
>  drivers/gpu/drm/meson/meson_viu.c       |  331 ++++++++
>  drivers/gpu/drm/meson/meson_viu.h       |   64 ++
>  drivers/gpu/drm/meson/meson_vpp.c       |  162 ++++
>  drivers/gpu/drm/meson/meson_vpp.h       |   35 +
>  23 files changed, 3877 insertions(+)
>  create mode 100644 drivers/gpu/drm/meson/Kconfig
>  create mode 100644 drivers/gpu/drm/meson/Makefile
>  create mode 100644 drivers/gpu/drm/meson/meson_canvas.c
>  create mode 100644 drivers/gpu/drm/meson/meson_canvas.h
>  create mode 100644 drivers/gpu/drm/meson/meson_crtc.c
>  create mode 100644 drivers/gpu/drm/meson/meson_crtc.h
>  create mode 100644 drivers/gpu/drm/meson/meson_drv.c
>  create mode 100644 drivers/gpu/drm/meson/meson_drv.h
>  create mode 100644 drivers/gpu/drm/meson/meson_plane.c
>  create mode 100644 drivers/gpu/drm/meson/meson_plane.h
>  create mode 100644 drivers/gpu/drm/meson/meson_registers.h
>  create mode 100644 drivers/gpu/drm/meson/meson_vclk.c
>  create mode 100644 drivers/gpu/drm/meson/meson_vclk.h
>  create mode 100644 drivers/gpu/drm/meson/meson_venc.c
>  create mode 100644 drivers/gpu/drm/meson/meson_venc.h
>  create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.c
>  create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.h
>  create mode 100644 drivers/gpu/drm/meson/meson_viu.c
>  create mode 100644 drivers/gpu/drm/meson/meson_viu.h
>  create mode 100644 drivers/gpu/drm/meson/meson_vpp.c
>  create mode 100644 drivers/gpu/drm/meson/meson_vpp.h

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <13104644.f9boR54smD@avalon>

Hi Laurent,

On 11/30/2016 04:56 PM, Laurent Pinchart wrote:
> Hi Neil,
> 
> Thank you for the patch.
> 
> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../bindings/display/meson/meson-drm.txt           | 101 ++++++++++++++++++
>> 1 file changed, 101 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
>> mode 100644
>> index 0000000..e52869a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>> @@ -0,0 +1,101 @@

[...]

>> +
>> +Device Tree Bindings:
>> +---------------------
>> +
>> +VPU: Video Processing Unit
>> +--------------------------
>> +
>> +Required properties:
>> +- compatible: value should be different for each SoC family as :
>> +	- GXBB (S905) : "amlogic,meson-gxbb-vpu"
>> +	- GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
>> +	- GXM (S912) : "amlogic,meson-gxm-vpu"
>> +	followed by the common "amlogic,meson-gx-vpu"
>> +- reg: base address and size of he following memory-mapped regions :
>> +	- vpu
>> +	- hhi
>> +	- dmc
>> +- reg-names: should contain the names of the previous memory regions
>> +- interrupts: should contain the VENC Vsync interrupt number
>> +
>> +- ports: A ports node with endpoint definitions as defined in
>> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +  The first port should be connected to a CVBS connector endpoint if
>> available.
> 
> This is a bit vague, I propose clarifying it with a description similar to the 
> one in the renesas,du.txt bindings.
> 
> Required nodes:
> 
> The connections to the VPU output video 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 DU output.
> 
>                 Port 0          Port1           Port2           Port3
> -----------------------------------------------------------------------------
>  R8A7779 (H1)   DPAD 0          DPAD 1          -               -
>  R8A7790 (H2)   DPAD            LVDS 0          LVDS 1          -
>  R8A7791 (M2-W) DPAD            LVDS 0          -               -
>  R8A7792 (V2H)  DPAD 0          DPAD 1          -               -
>  R8A7793 (M2-N) DPAD            LVDS 0          -               -
>  R8A7794 (E2)   DPAD 0          DPAD 1          -               -
>  R8A7795 (H3)   DPAD            HDMI 0          HDMI 1          LVDS
>  R8A7796 (M3-W) DPAD            HDMI            LVDS            -
> 
> (You should obviously replace the table with Amlogic data)
> 
> It doesn't matter if the current driver implementation only supports CVBS, the 
> DT bindings can already document the other ports.
> 

Ok, it's a pretty table ! Will integrate this.

>> +
>> +Example:
>> +
>> +tv: connector {
>> +	compatible = "composite-video-connector";
>> +	label = "cvbs";
> 
> I'd remove the label here, as it doesn't bring any additional information. 
> Unless the board you're using has a label for the connector, in case that 
> label should be used.

Indeed, I already removed it in the dts.

> 
> Apart from that,
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 

[...]

Thanks for the review,
Neil

^ permalink raw reply

* [PATCH v2 1/4] drm: Add support for Amlogic Meson Graphic Controller
From: Neil Armstrong @ 2016-11-30 16:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <3713265.h5djxipShb@avalon>

On 11/30/2016 05:03 PM, Laurent Pinchart wrote:
> Hi Neil,
> 
> Thank you for the patch.
> 
> I'm afraid I don't have time for a complete review, but could you please get 
> rid of the of_machine_is_compatible() calls and match on the VPU compatible 
> string instead ?

Oops, I knew I forgot to change this one...

I will get rid of these for the v3.

Thanks,
Neil

^ permalink raw reply

* [PATCH v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Neil Armstrong @ 2016-11-30 16:07 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <10006210.eA8q2ZWXP0@avalon>

On 11/30/2016 05:02 PM, Laurent Pinchart wrote:
> Hi Neil,
> 
> Thank you for the patch.
> 
> On Wednesday 30 Nov 2016 16:43:43 Neil Armstrong wrote:
>> Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
>> boards.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi             | 19 ++++++++++++++++
>>  .../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi      | 15 +++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi           |  4 ++++
>>  arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi            |  4 ++++
>>  arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts   | 15 +++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxm.dtsi            |  4 ++++
>>  8 files changed, 91 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi index fc033c0..a27f881 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -356,5 +356,24 @@
>>  				status = "disabled";
>>  			};
>>  		};
>> +
>> +		vpu: vpu at d0100000 {
>> +			compatible = "amlogic,meson-gx-vpu";
>> +			reg = <0x0 0xd0100000 0x0 0x100000>,
>> +			      <0x0 0xc883c000 0x0 0x1000>,
>> +			      <0x0 0xc8838000 0x0 0x1000>;
>> +			reg-names = "vpu", "hhi", "dmc";
>> +			interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +
>> +			/* CVBS VDAC output port */
>> +			port at 0 {
>> +				reg = <0>;
>> +
>> +				cvbs_vdac_out: endpoint {
>> +				};
> 
> Endpoints require a remote-endpoint property. You should move the endpoint to 
> board DT files.

OK, I was wondering, it looked dirty to me.

> 
>> +			};
>> +		};
>>  	};
>>  };
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts index
>> 9696820..390f7db 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> @@ -142,6 +142,17 @@
>>  		clocks = <&wifi32k>;
>>  		clock-names = "ext_clock";
>>  	};
>> +
>> +	cvbs-connector {
>> +		compatible = "composite-video-connector";
>> +		label = "cvbs";
> 
> Unless the board has a label for the connector (either on the board, on the 
> casing or in the user manual) I'd leave this out. Same comment for the other 
> boards.

OK,

Thanks,
Neil

> 
> Apart from that,
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
>> +
>> +		port {
>> +			cvbs_connector_in: endpoint {
>> +				remote-endpoint = <&cvbs_vdac_out>;
>> +			};
>> +		};
>> +	};
>>  };
>>
>>  &uart_AO {
>> @@ -229,3 +240,7 @@
>>  	clocks = <&clkc CLKID_FCLK_DIV4>;
>>  	clock-names = "clkin0";
>>  };
>> +
>> +&cvbs_vdac_out {
>> +	remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi index 203be28..44bdebf
>> 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> @@ -125,6 +125,17 @@
>>  		clocks = <&wifi32k>;
>>  		clock-names = "ext_clock";
>>  	};
>> +
>> +	cvbs-connector {
>> +		compatible = "composite-video-connector";
>> +		label = "cvbs";
>> +
>> +		port {
>> +			cvbs_connector_in: endpoint {
>> +				remote-endpoint = <&cvbs_vdac_out>;
>> +			};
>> +		};
>> +	};
>>  };
>>
>>  /* This UART is brought out to the DB9 connector */
>> @@ -234,3 +245,7 @@
>>  	clocks = <&clkc CLKID_FCLK_DIV4>;
>>  	clock-names = "clkin0";
>>  };
>> +
>> +&cvbs_vdac_out {
>> +	remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index ac5ad3b..5353a20 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> @@ -506,3 +506,7 @@
>>  		 <&clkc CLKID_FCLK_DIV2>;
>>  	clock-names = "core", "clkin0", "clkin1";
>>  };
>> +
>> +&vpu {
>> +	compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts index
>> e99101a..7bd0538 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> @@ -117,6 +117,17 @@
>>  		clocks = <&wifi32k>;
>>  		clock-names = "ext_clock";
>>  	};
>> +
>> +	cvbs-connector {
>> +		compatible = "composite-video-connector";
>> +		label = "cvbs";
>> +
>> +		port {
>> +			cvbs_connector_in: endpoint {
>> +				remote-endpoint = <&cvbs_vdac_out>;
>> +			};
>> +		};
>> +	};
>>  };
>>
>>  &uart_AO {
>> @@ -203,3 +214,7 @@
>>  	clocks = <&clkc CLKID_FCLK_DIV4>;
>>  	clock-names = "clkin0";
>>  };
>> +
>> +&cvbs_vdac_out {
>> +	remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index 9f89b99..5c7a8fa 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> @@ -299,3 +299,7 @@
>>  		 <&clkc CLKID_FCLK_DIV2>;
>>  	clock-names = "core", "clkin0", "clkin1";
>>  };
>> +
>> +&vpu {
>> +	compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts index
>> d320727..5b99749 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> @@ -90,6 +90,17 @@
>>  		compatible = "mmc-pwrseq-emmc";
>>  		reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
>>  	};
>> +
>> +	cvbs-connector {
>> +		compatible = "composite-video-connector";
>> +		label = "cvbs";
>> +
>> +		port {
>> +			cvbs_connector_in: endpoint {
>> +				remote-endpoint = <&cvbs_vdac_out>;
>> +			};
>> +		};
>> +	};
>>  };
>>
>>  /* This UART is brought out to the DB9 connector */
>> @@ -167,3 +178,7 @@
>>  		max-speed = <1000>;
>>  	};
>>  };
>> +
>> +&cvbs_vdac_out {
>> +	remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi index c1974bb..eb2f0c3 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> @@ -112,3 +112,7 @@
>>  		};
>>  	};
>>  };
>> +
>> +&vpu {
>> +	compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
>> +};
> 

^ permalink raw reply

* [GIT PULL v2 9/10] arm64: tegra: Device tree changes for v4.10-rc1
From: Arnd Bergmann @ 2016-11-30 16:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161121102312.19968-1-thierry.reding@gmail.com>

On Monday, November 21, 2016 11:23:12 AM CET Thierry Reding wrote:
> arm64: tegra: Device tree changes for v4.10-rc1
> 
> This adds initial support for Tegra186, the P3310 processor module as
> well as the P2771 development board. Not much is functional, but there
> is enough to boot to an initial ramdisk with debug serial output.
> 

Pulled into next/dt64, thanks!

	Arnd

^ permalink raw reply

* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Grygorii Strashko @ 2016-11-30 16:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5501170.dgvo5UdPBX@wuerfel>



On 11/30/2016 05:37 AM, Arnd Bergmann wrote:
> On Tuesday, November 29, 2016 4:15:08 PM CET Grygorii Strashko wrote:
>>                 range->num_irqs++;
>>
>> -               if (oirq.args_count == 3)
>> +               if (IS_ENABLED(SMP) && oirq.args_count == 3)
>>                         range->irqs[i].cpu_map =
>>                                 (oirq.args[2] & 0x0000ff00) >> 8;
>>
>
> I think you mean CONFIG_SMP, not SMP. With the change above, the
> code will never be executed.
>

Thanks. I'll resend.

-- 
regards,
-grygorii

^ permalink raw reply

* [GIT PULL 10/10] arm64: tegra: Default configuration updates for v4.10-rc1
From: Arnd Bergmann @ 2016-11-30 16:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-10-thierry.reding@gmail.com>

On Friday, November 18, 2016 5:17:19 PM CET Thierry Reding wrote:
> arm64: tegra: Default configuration updates for v4.10-rc1
> 
> Enable Tegra186 support.
> 

This was already in next/arm64 (but I didn't see a notification),
and with the arm64-dt branch now merged as well, we should have
everything you sent.

	Arnd

^ permalink raw reply

* [GIT PULL v2] firmware: SCPI updates for v4.10
From: Arnd Bergmann @ 2016-11-30 16:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161118115615.GB14913@e107155-lin>

On Friday, November 18, 2016 11:56:15 AM CET Sudeep Holla wrote:
> Hi ARM-SoC Team,
> 
> I have decoupled the platform specific binding from generic SCPI. Also
> I have renamed "arm,legacy-scpi" to "arm,scpi-pre-1.0". Since I haven't
> heard back any objections from Olof/Rob for my response, I am sending
> the pull request now.
> 

Pulled into next/drivers now, sorry for the delay.

	Arnd

^ permalink raw reply

* [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration
From: Lorenzo Pieralisi @ 2016-11-30 16:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1480465344-11862-3-git-send-email-sricharan@codeaurora.org>

Sricharan, Robin,

I gave this series a go on ACPI and apart from an SMMU v3 fix-up
it seems to work, more thorough testing required though.

A key question below.

On Wed, Nov 30, 2016 at 05:52:16AM +0530, Sricharan R wrote:
> From: Robin Murphy <robin.murphy@arm.com>
> 
> IOMMU configuration represents unchanging properties of the hardware,
> and as such should only need happen once in a device's lifetime, but
> the necessary interaction with the IOMMU device and driver complicates
> exactly when that point should be.
> 
> Since the only reasonable tool available for handling the inter-device
> dependency is probe deferral, we need to prepare of_iommu_configure()
> to run later than it is currently called (i.e. at driver probe rather
> than device creation), to handle being retried, and to tell whether a
> not-yet present IOMMU should be waited for or skipped (by virtue of
> having declared a built-in driver or not).
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  drivers/iommu/of_iommu.c | 30 +++++++++++++++++++++++++++++-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index ee49081..349bd1d 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -104,12 +104,20 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
>  	int err;
>  
>  	ops = iommu_get_instance(fwnode);
> -	if (!ops || !ops->of_xlate)
> +	if ((ops && !ops->of_xlate) ||
> +	    (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))

IIUC of_match_node() here is there to check there is a driver compiled
in for this device_node (aka compatible string in OF world), correct ?
If that's the case (and I think that's what Sricharan was referring to
in his ACPI query) I need to cook-up something on the ACPI side to
emulate the OF linker table behaviour (or anyway to detect a driver is
actually in the kernel), it is not that difficult but it is key to know,
I will give it some thought to make it as clean as possible.

Thanks,
Lorenzo

>  		return NULL;
>  
>  	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
>  	if (err)
>  		return ERR_PTR(err);
> +	/*
> +	 * The otherwise-empty fwspec handily serves to indicate the specific
> +	 * IOMMU device we're waiting for, which will be useful if we ever get
> +	 * a proper probe-ordering dependency mechanism in future.
> +	 */
> +	if (!ops)
> +		return ERR_PTR(-EPROBE_DEFER);
>  
>  	err = ops->of_xlate(dev, iommu_spec);
>  	if (err)
> @@ -186,14 +194,34 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
>  					   struct device_node *master_np)
>  {
>  	const struct iommu_ops *ops;
> +	struct iommu_fwspec *fwspec = dev->iommu_fwspec;
>  
>  	if (!master_np)
>  		return NULL;
>  
> +	if (fwspec) {
> +		if (fwspec->ops)
> +			return fwspec->ops;
> +
> +		/* In the deferred case, start again from scratch */
> +		iommu_fwspec_free(dev);
> +	}
> +
>  	if (dev_is_pci(dev))
>  		ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>  	else
>  		ops = of_platform_iommu_init(dev, master_np);
> +	/*
> +	 * If we have reason to believe the IOMMU driver missed the initial
> +	 * add_device callback for dev, replay it to get things in order.
> +	 */
> +	if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
> +	    dev->bus && !dev->iommu_group) {
> +		int err = ops->add_device(dev);
> +
> +		if (err)
> +			ops = ERR_PTR(err);
> +	}
>  
>  	return IS_ERR(ops) ? NULL : ops;
>  }
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> 

^ permalink raw reply

* [PATCH v2] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-30 16:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAADWXX_ipJ+pVmV5s2oLCKBrC5qUDASOZf=tpBfJWELExam+hQ@mail.gmail.com>

On Tue, Nov 29, 2016 at 03:39:11PM -0800, Linus Torvalds wrote:
> Bjorn, this email was marked as spam, because:
> 
>   It has a from address in google.com but has failed google.com's
> required tests for authentication
> 
> in particular, it looks like you used a non-google smtp server
> (kernel.org) to send the email, so there is no DKIM hash (or perhaps
> google just uses some other non-standard marker for "this actually
> came from google"). So gmail marks it as spam because dmarc fails:
> 
>        dmarc=fail (p=REJECT dis=NONE) header.from=google.com
> 
> Just to let you know. If you use your google.com email, you do need to
> go through the google smtp server.
> 
> This may or may not be new - I didn't go and look at old messages of
> yours, but it is possible that google.com enabled dmarc/dkim recently.

Argh, thanks for letting me know.  Looks like I've had this broken for a
long time, but I didn't notice.  I think I have it fixed so git will record
the author as bhelgaas at google.com, but git/stgit will send email from
helgaas at kernel.org via the kernel.org smtp server.

^ permalink raw reply

* [PATCH v5 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Wolfram Sang @ 2016-11-30 16:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <e5c36597-d917-0555-89cd-35f68087c1c5@free-electrons.com>


> What do you prefer everything in one commit or two seperated commit ? (one
> including the new fields for fm_mask and another one to add support for
> a3700-i2c).

One commit is fine!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/0fcbc15f/attachment-0001.sig>

^ permalink raw reply

* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Kevin Hilman @ 2016-11-30 16:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <2e1b16c6-eec5-8cf3-5795-d6de02f36570@baylibre.com>

Neil Armstrong <narmstrong@baylibre.com> writes:

> Hi Laurent,
> On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
>> Hi Neil,
>> 
>> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>> ---
>>>  .../bindings/display/meson/meson-drm.txt           | 101 ++++++++++++++++++
>> 
>> I forgot to mention that the file should not be named meson-drm.txt as DRM is 
>> a Linux-specific concept. You can name it meson.txt, but a better option would 
>> be amlogic,meson.txt. By the way does it really need a subdirectory ?
>
> I took example of the sun4i layout the naming, and no it does not need a subdirector..
>
> I will move it to amlogic,meson.txt, seems far better.
>

To me, amlogic,meson is redundant.  Probably should be amlogic,vpu.txt?

Kevin

^ permalink raw reply

* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <m21sxtkkg1.fsf@baylibre.com>

On 11/30/2016 05:21 PM, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
> 
>> Hi Laurent,
>> On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
>>> Hi Neil,
>>>
>>> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>>  .../bindings/display/meson/meson-drm.txt           | 101 ++++++++++++++++++
>>>
>>> I forgot to mention that the file should not be named meson-drm.txt as DRM is 
>>> a Linux-specific concept. You can name it meson.txt, but a better option would 
>>> be amlogic,meson.txt. By the way does it really need a subdirectory ?
>>
>> I took example of the sun4i layout the naming, and no it does not need a subdirector..
>>
>> I will move it to amlogic,meson.txt, seems far better.
>>
> 
> To me, amlogic,meson is redundant.  Probably should be amlogic,vpu.txt?
> 
> Kevin
> 

Yes, seems more coherent.

Thanks,
Neil

^ permalink raw reply

* [PATCH v3 2/5] i2c: Add STM32F4 I2C driver
From: Wolfram Sang @ 2016-11-30 16:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAOAejn0BZNH82kY_7UR1EjV7M1G+9jGihGb4-uCs9=XiPHUYxQ@mail.gmail.com>

Hi,

> I was too busy in another project but now I am ready to complete the
> upstream of the STM32F4 I2C driver.

Nice.

> >> +static void stm32f4_i2c_set_periph_clk_freq(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> +     u32 clk_rate, cr2, freq;
> >> +
> >> +     cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
> >> +     cr2 &= ~STM32F4_I2C_CR2_FREQ_MASK;
> >> +
> >> +     clk_rate = clk_get_rate(i2c_dev->clk);
> >> +     freq = clk_rate / MHZ_TO_HZ;
> >> +
> >> +     if (freq > STM32F4_I2C_MAX_FREQ)
> >> +             freq = STM32F4_I2C_MAX_FREQ;
> >> +     if (freq < STM32F4_I2C_MIN_FREQ)
> >> +             freq = STM32F4_I2C_MIN_FREQ;
> >
> > clamp() to enforce the range?
> Sorry but what do you mean by "clamp()" ?

The kernel has a clamp() function which would fit this purpose, I think.

Regards,

   Wolfram

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/e13dca49/attachment.sig>

^ permalink raw reply

* [PATCH 2/2] ACPI: Ignore Consumer/Producer for QWord/DWord/Word Address Space
From: Lorenzo Pieralisi @ 2016-11-30 16:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161130155616.GA9693@bhelgaas-glaptop.roam.corp.google.com>

On Wed, Nov 30, 2016 at 09:56:17AM -0600, Bjorn Helgaas wrote:
> On Wed, Nov 30, 2016 at 12:04:25PM +0000, Lorenzo Pieralisi wrote:
> > On Tue, Nov 29, 2016 at 12:43:34PM -0600, Bjorn Helgaas wrote:
> > > Per ACPI spec r6.0, sec 6.4.3.5.1, 2, 3, Bit [0] of General Flags (the
> > > Consumer/Producer bit) should be ignored for QWord/DWord/Word Address Space
> > > descriptors.  The Consumer/Producer bit is defined only for the Extended
> > > Address Space descriptor.
> > > 
> > > Ignore Consumer/Producer except for Extended Address Space descriptors.
> > > 
> > > Note that for QWord/DWord/Word descriptors, we previously applied the
> > > translation offset (_TRA) only when the Consumer/Producer bit was set.
> > 
> > "..Consumer/Producer bit was clear" ? If that bit was set:
> > 
> > struct acpi_resource_address->producer_consumer == ACPI_CONSUMER
> > 
> > and we are not applying the _TRA offset in that case, right ?
> 
> Right, of course.  How about this instead?
> 
>     Note that for QWord/DWord/Word descriptors, we previously applied the
>     translation offset (_TRA) only for Producers, i.e., when the Consumer/
>     Producer bit was clear.  This patch changes that: for those descriptors,
>     we ignore Consumer/Producer and always apply the translation offset.

Yes that's a perfect description, thanks a lot !

Lorenzo

> > > This patch changes that: for those descriptors, we ignore Consumer/Producer
> > > and always apply the translation offset.
> > > 
> > > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> > > ---
> > >  drivers/acpi/resource.c |   16 +++++++++++-----
> > >  1 file changed, 11 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> > > index 2732d39e..b45cd8f 100644
> > > --- a/drivers/acpi/resource.c
> > > +++ b/drivers/acpi/resource.c
> > > @@ -261,11 +261,16 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> > >  	 * primary side. Non-bridge devices must list 0 for all Address
> > >  	 * Translation offset bits.
> > >  	 */
> > > -	if (addr->producer_consumer == ACPI_PRODUCER)
> > > +	if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64) {
> > > +		if (addr->producer_consumer == ACPI_PRODUCER)
> > > +			offset = attr->translation_offset;
> > > +		else if (attr->translation_offset)
> > > +			pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> > > +				 attr->translation_offset);
> > > +	} else {
> > >  		offset = attr->translation_offset;
> > > -	else if (attr->translation_offset)
> > > -		pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> > > -			 attr->translation_offset);
> > > +	}
> > > +
> > >  	start = attr->minimum + offset;
> > >  	end = attr->maximum + offset;
> > >  
> > > @@ -294,7 +299,8 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> > >  		return false;
> > >  	}
> > >  
> > > -	if (addr->producer_consumer == ACPI_PRODUCER)
> > > +	if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64 &&
> > > +	    addr->producer_consumer == ACPI_PRODUCER)
> > >  		res->flags |= IORESOURCE_WINDOW;
> > >  
> > >  	if (addr->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > > the body of a message to majordomo at vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [sample] A sample program for MRS emulation
From: Dave Martin @ 2016-11-30 16:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1480518901-18544-11-git-send-email-suzuki.poulose@arm.com>

On Wed, Nov 30, 2016 at 03:15:01PM +0000, Suzuki K Poulose wrote:
> Here is a sample program which demonstrates how to use mrs
> emulation to fetch the ID registers.

Are we planning to add this in Documentation/?  If so, we might want
some tweaks (noted below).

> 
> ----8>----
> /*
>  * Sample program to demonstrate the MRS emulation
>  * ABI.

overwrapped?

>  * Copyright (C) 2015-2016, ARM Ltd
>  *
>  * Author: Suzuki K Poulose <suzuki.poulose@arm.com>
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  *
>  * This program is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  * GNU General Public License for more details.
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  *
>  * This program is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  * GNU General Public License for more details.
>  */
> 
> #include <stdio.h>
> 
> #define get_cpu_ftr(id) ({					\
> 		unsigned long long __val;			\
> 		asm("mrs %0, "#id : "=r" (__val));		\
> 		printf("%-20s: 0x%016lx\n", #id, __val);	\
> 	})
> 
> int main()

(void)

> {

We don't wan't people using the MRS emulation without checking for its
availability first.

Something like this may work (untested), with the caveat that getauxval()
is a GNU libc extension, and other environments may require a different
mechanism to obtain the hwcaps.

--8<--

#include <sys/auxv.h>
#include <asm/hwcap.h>

/* ... */

	if (!getauxval(AT_HWCAP) & HWCAP_CPUID) {
		fputs("CPUID registers unavailable\n", stderr);
		return 1;
	}

-->8--

Cheers
---Dave

> 
> 	get_cpu_ftr(ID_AA64ISAR0_EL1);
> 	get_cpu_ftr(ID_AA64ISAR1_EL1);
> 	get_cpu_ftr(ID_AA64MMFR0_EL1);
> 	get_cpu_ftr(ID_AA64MMFR1_EL1);
> 	get_cpu_ftr(ID_AA64PFR0_EL1);
> 	get_cpu_ftr(ID_AA64PFR1_EL1);
> 	get_cpu_ftr(ID_AA64DFR0_EL1);
> 	get_cpu_ftr(ID_AA64DFR1_EL1);
> 
> 	get_cpu_ftr(MIDR_EL1);
> 	get_cpu_ftr(MPIDR_EL1);
> 	get_cpu_ftr(REVIDR_EL1);
> 	return 0;
> }
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] arm64: dts: juno: Correct PCI IO window
From: Sudeep Holla @ 2016-11-30 16:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1480452310-29286-1-git-send-email-jeremy.linton@arm.com>

Hi Jeremy,

On 29/11/16 20:45, Jeremy Linton wrote:
> The PCIe root complex on Juno translates the MMIO mapped
> at 0x5f800000 to the PIO address range starting at 0
> (which is common because PIO addresses are generally < 64k).
> Correct the DT to reflect this.
>

I have another DT fix that I have asked ARM-SoC guys to pick up directly
from the list. If that doesn't happen, I will send PR including both.

If that happens then we need to send this to them to be picked directly.
At this point I want to wait for couple of days to avoid confusion.

-- 
Regards,
Sudeep

^ permalink raw reply

* [GIT PULL 10/10] arm64: tegra: Default configuration updates for v4.10-rc1
From: Thierry Reding @ 2016-11-30 16:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <6706502.us21ohNYZA@wuerfel>

On Wed, Nov 30, 2016 at 05:10:43PM +0100, Arnd Bergmann wrote:
> On Friday, November 18, 2016 5:17:19 PM CET Thierry Reding wrote:
> > arm64: tegra: Default configuration updates for v4.10-rc1
> > 
> > Enable Tegra186 support.
> > 
> 
> This was already in next/arm64 (but I didn't see a notification),
> and with the arm64-dt branch now merged as well, we should have
> everything you sent.

I had also sent a couple of individual patches that seemed to not have
it made into v4.9 and v4.8 for some reason (they were part of the pull
requests, as far as I can tell). Do you think you could pull those in
as well?

Thanks,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/b14ea724/attachment.sig>

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox