Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1363527 > unrolled thread

[PATCH v3 13/19] drm: sun4i: Add DT bindings documentation

Started byMaxime Ripard <maxime.ripard@free-electrons.com>
First post2016-03-23 17:40 +0100
Last post2016-03-29 21:00 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH v3 13/19] drm: sun4i: Add DT bindings documentation Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-03-23 17:40 +0100
    Re: [PATCH v3 13/19] drm: sun4i: Add DT bindings documentation Rob Herring <robh@kernel.org> - 2016-03-25 15:20 +0100
      Re: [PATCH v3 13/19] drm: sun4i: Add DT bindings documentation Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-03-29 12:40 +0200
        Re: [PATCH v3 13/19] drm: sun4i: Add DT bindings documentation Rob Herring <robh@kernel.org> - 2016-03-29 21:00 +0200

#1363527 — [PATCH v3 13/19] drm: sun4i: Add DT bindings documentation

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2016-03-23 17:40 +0100
Subject[PATCH v3 13/19] drm: sun4i: Add DT bindings documentation
Message-ID<rfTZ8-69G-23@gated-at.bofh.it>
The display pipeline of the Allwinner A10 is involving several loosely
coupled components.

Add a documentation for the bindings.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 .../bindings/display/sunxi/sun4i-drm.txt           | 254 +++++++++++++++++++++
 1 file changed, 254 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
new file mode 100644
index 000000000000..378edb919eae
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -0,0 +1,254 @@
+Allwinner A10 Display Pipeline
+==============================
+
+The Allwinner A10 Display pipeline is composed of several components
+that are going to be documented below:
+
+TV Encoder
+----------
+
+The TV Encoder supports the composite and VGA output. It is one end of
+the pipeline.
+
+Required properties:
+ - compatible: value should be "allwinner,sun4i-a10-tv-encoder".
+ - reg: base address and size of memory-mapped region
+ - clocks: the clocks driving the TV encoder
+ - resets: phandle to the reset controller driving the encoder
+
+- ports: A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt. The
+  first port should be the input endpoint.
+
+TCON
+----
+
+The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
+
+Required properties:
+ - compatible: value should be "allwinner,sun5i-a13-tcon".
+ - reg: base address and size of memory-mapped region
+ - interrupts: interrupt associated to this IP
+ - clocks: phandles to the clocks feeding the TCON. Three are needed:
+   - 'ahb': the interface clocks
+   - 'tcon-ch0': The clock driving the TCON channel 0
+   - 'tcon-ch1': The clock driving the TCON channel 1
+ - resets: phandles to the reset controllers driving the encoder
+   - "lcd": the reset line for the TCON channel 0
+
+ - clock-names: the clock names mentioned above
+ - reset-names: the reset names mentioned above
+ - clock-output-names: Name of the pixel clock created
+
+- ports: A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt. The
+  first port should be the input endpoint, the second one the output
+
+Endpoints optional property:
+  - allwinner,panel: boolean to indicate that the endpoint is a panel
+
+
+Display Engine Backend
+----------------------
+
+The display engine backend exposes layers and sprites to the
+system.
+
+Required properties:
+  - compatible: value must be one of:
+    * allwinner,sun5i-a13-display-backend
+  - reg: base address and size of the memory-mapped region.
+  - clocks: phandles to the clocks feeding the frontend and backend
+    * ahb: the backend interface clock
+    * mod: the backend module clock
+    * ram: the backend DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset controllers driving the backend
+
+- ports: A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt. The
+  first port should be the input endpoints, the second one the output
+
+Display Engine Frontend
+-----------------------
+
+The display engine frontend does formats conversion, scaling,
+deinterlacing and color space conversion.
+
+Required properties:
+  - compatible: value must be one of:
+    * allwinner,sun5i-a13-display-frontend
+  - reg: base address and size of the memory-mapped region.
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the frontend and backend
+    * ahb: the backend interface clock
+    * mod: the backend module clock
+    * ram: the backend DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset controllers driving the backend
+
+Display Engine Pipeline
+-----------------------
+
+The display engine pipeline (and its entry point, since it can be
+either directly the backend or the frontend) is represented as an
+extra node.
+
+Required properties:
+  - compatible: value must be one of:
+    * allwinner,sun5i-a13-display-engine
+  - allwinner,pipelines: list of phandle to the entry points of the
+    pipelines (either to the frontend or backend)
+
+Example:
+
+panel: panel {
+	compatible = "olimex,lcd-olinuxino-43-ts";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	port@0 {
+		reg = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		panel_input: endpoint@0 {
+			reg = <0>;
+			remote-endpoint = <&tcon0_out_panel>;
+		};
+	};
+};
+
+tve0: tv-encoder@01c0a000 {
+	compatible = "allwinner,sun4i-a10-tv-encoder";
+	reg = <0x01c0a000 0x1000>;
+	clocks = <&ahb_gates 34>;
+	resets = <&tcon_ch0_clk 0>;
+
+	port {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		tve0_in_tcon0: endpoint@0 {
+			reg = <0>;
+			remote-endpoint = <&tcon0_out_tve0>;
+		};
+	};
+};
+
+tcon0: lcd-controller@01c0c000 {
+	compatible = "allwinner,sun5i-a13-tcon";
+	reg = <0x01c0c000 0x1000>;
+	interrupts = <44>;
+	resets = <&tcon_ch0_clk 1>;
+	reset-names = "lcd";
+	clocks = <&ahb_gates 36>,
+		 <&tcon_ch0_clk>,
+		 <&tcon_ch1_clk>;
+	clock-names = "ahb",
+		      "tcon-ch0",
+		      "tcon-ch1";
+	clock-output-names = "tcon-pixel-clock";
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		tcon0_in: port@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+
+			tcon0_in_be0: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&be0_out_tcon0>;
+			};
+		};
+
+		tcon0_out: port@1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+
+			tcon0_out_tve0: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&tve0_in_tcon0>;
+			};
+
+			tcon0_out_panel: endpoint@1 {
+				reg = <1>;
+				remote-endpoint = <&panel_input>;
+				allwinner,panel;
+			};
+		};
+	};
+};
+
+fe0: display-frontend@01e00000 {
+	compatible = "allwinner,sun5i-a13-display-frontend";
+	reg = <0x01e00000 0x20000>;
+	interrupts = <47>;
+	clocks = <&ahb_gates 46>, <&de_fe_clk>,
+		 <&dram_gates 25>;
+	clock-names = "ahb", "mod",
+		      "ram";
+	resets = <&de_fe_clk>;
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		fe0_out: port@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+
+			fe0_out_be0: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&be0_in_fe0>;
+			};
+		};
+	};
+};
+
+be0: display-backend@01e60000 {
+	compatible = "allwinner,sun5i-a13-display-backend";
+	reg = <0x01e60000 0x10000>;
+	clocks = <&ahb_gates 44>, <&de_be_clk>,
+		 <&dram_gates 26>;
+	clock-names = "ahb", "mod",
+		      "ram";
+	resets = <&de_be_clk>;
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		be0_in: port@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+
+			be0_in_fe0: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&fe0_out_be0>;
+			};
+		};
+
+		be0_out: port@1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+
+			be0_out_tcon0: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&tcon0_in_be0>;
+			};
+		};
+	};
+};
+
+display-engine {
+	compatible = "allwinner,sun5i-a13-display-engine";
+	pipelines = <&be0>;
+};
-- 
2.7.3

[toc] | [next] | [standalone]


#1364682

FromRob Herring <robh@kernel.org>
Date2016-03-25 15:20 +0100
Message-ID<rgAKJ-2QC-7@gated-at.bofh.it>
In reply to#1363527
On Wed, Mar 23, 2016 at 05:38:36PM +0100, Maxime Ripard wrote:
> The display pipeline of the Allwinner A10 is involving several loosely
> coupled components.
> 
> Add a documentation for the bindings.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  .../bindings/display/sunxi/sun4i-drm.txt           | 254 +++++++++++++++++++++
>  1 file changed, 254 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> new file mode 100644
> index 000000000000..378edb919eae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -0,0 +1,254 @@
> +Allwinner A10 Display Pipeline
> +==============================
> +
> +The Allwinner A10 Display pipeline is composed of several components
> +that are going to be documented below:
> +
> +TV Encoder
> +----------
> +
> +The TV Encoder supports the composite and VGA output. It is one end of
> +the pipeline.
> +
> +Required properties:
> + - compatible: value should be "allwinner,sun4i-a10-tv-encoder".
> + - reg: base address and size of memory-mapped region
> + - clocks: the clocks driving the TV encoder
> + - resets: phandle to the reset controller driving the encoder
> +
> +- ports: A ports node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> +  first port should be the input endpoint.
> +
> +TCON
> +----
> +
> +The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
> +
> +Required properties:
> + - compatible: value should be "allwinner,sun5i-a13-tcon".
> + - reg: base address and size of memory-mapped region
> + - interrupts: interrupt associated to this IP
> + - clocks: phandles to the clocks feeding the TCON. Three are needed:
> +   - 'ahb': the interface clocks
> +   - 'tcon-ch0': The clock driving the TCON channel 0
> +   - 'tcon-ch1': The clock driving the TCON channel 1
> + - resets: phandles to the reset controllers driving the encoder
> +   - "lcd": the reset line for the TCON channel 0
> +
> + - clock-names: the clock names mentioned above
> + - reset-names: the reset names mentioned above
> + - clock-output-names: Name of the pixel clock created
> +
> +- ports: A ports node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> +  first port should be the input endpoint, the second one the output

The example shows 2 output endpoints. Your diagram shows up to 4 
outputs. The number should be how ever many could coexist in a given h/w 
design. In other words, I'm assuming all 4 can't be used simultaneously, 
but can all 4 be wired up in a h/w design and switched in s/w? 

Just be clear on the numbering.

> +
> +Endpoints optional property:
> +  - allwinner,panel: boolean to indicate that the endpoint is a panel

This can be determined by the endpoint not being TV Encoder (or HDMI).

> +
> +
> +Display Engine Backend
> +----------------------
> +
> +The display engine backend exposes layers and sprites to the
> +system.
> +
> +Required properties:
> +  - compatible: value must be one of:
> +    * allwinner,sun5i-a13-display-backend
> +  - reg: base address and size of the memory-mapped region.
> +  - clocks: phandles to the clocks feeding the frontend and backend
> +    * ahb: the backend interface clock
> +    * mod: the backend module clock
> +    * ram: the backend DRAM clock
> +  - clock-names: the clock names mentioned above
> +  - resets: phandles to the reset controllers driving the backend
> +
> +- ports: A ports node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> +  first port should be the input endpoints, the second one the output
> +
> +Display Engine Frontend
> +-----------------------
> +
> +The display engine frontend does formats conversion, scaling,
> +deinterlacing and color space conversion.
> +
> +Required properties:
> +  - compatible: value must be one of:
> +    * allwinner,sun5i-a13-display-frontend
> +  - reg: base address and size of the memory-mapped region.
> +  - interrupts: interrupt associated to this IP
> +  - clocks: phandles to the clocks feeding the frontend and backend
> +    * ahb: the backend interface clock
> +    * mod: the backend module clock
> +    * ram: the backend DRAM clock
> +  - clock-names: the clock names mentioned above
> +  - resets: phandles to the reset controllers driving the backend
> +
> +Display Engine Pipeline
> +-----------------------
> +
> +The display engine pipeline (and its entry point, since it can be
> +either directly the backend or the frontend) is represented as an
> +extra node.
> +
> +Required properties:
> +  - compatible: value must be one of:
> +    * allwinner,sun5i-a13-display-engine
> +  - allwinner,pipelines: list of phandle to the entry points of the
> +    pipelines (either to the frontend or backend)

Seems like using FE or BE would be a function of your framebuffers' 
formats and shouldn't be defined in DT.


> +
> +Example:
> +
> +panel: panel {
> +	compatible = "olimex,lcd-olinuxino-43-ts";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	port@0 {
> +		reg = <0>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		panel_input: endpoint@0 {
> +			reg = <0>;
> +			remote-endpoint = <&tcon0_out_panel>;

You can drop the unit-addresses and reg when there is only 1 (or 
leaving is fine too).

> +		};
> +	};
> +};
> +
> +tve0: tv-encoder@01c0a000 {

Drop the leading 0.

> +	compatible = "allwinner,sun4i-a10-tv-encoder";
> +	reg = <0x01c0a000 0x1000>;
> +	clocks = <&ahb_gates 34>;
> +	resets = <&tcon_ch0_clk 0>;
> +
> +	port {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		tve0_in_tcon0: endpoint@0 {
> +			reg = <0>;
> +			remote-endpoint = <&tcon0_out_tve0>;
> +		};
> +	};
> +};
> +
> +tcon0: lcd-controller@01c0c000 {

ditto...

> +	compatible = "allwinner,sun5i-a13-tcon";
> +	reg = <0x01c0c000 0x1000>;
> +	interrupts = <44>;
> +	resets = <&tcon_ch0_clk 1>;
> +	reset-names = "lcd";
> +	clocks = <&ahb_gates 36>,
> +		 <&tcon_ch0_clk>,
> +		 <&tcon_ch1_clk>;
> +	clock-names = "ahb",
> +		      "tcon-ch0",
> +		      "tcon-ch1";
> +	clock-output-names = "tcon-pixel-clock";

[toc] | [prev] | [next] | [standalone]


#1366119

FromMaxime Ripard <maxime.ripard@free-electrons.com>
Date2016-03-29 12:40 +0200
Message-ID<rhZe1-4MC-1@gated-at.bofh.it>
In reply to#1364682

[Multipart message — attachments visible in raw view] — view raw

Hi Rob,

On Fri, Mar 25, 2016 at 09:11:18AM -0500, Rob Herring wrote:
> On Wed, Mar 23, 2016 at 05:38:36PM +0100, Maxime Ripard wrote:
> > The display pipeline of the Allwinner A10 is involving several loosely
> > coupled components.
> > 
> > Add a documentation for the bindings.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> >  .../bindings/display/sunxi/sun4i-drm.txt           | 254 +++++++++++++++++++++
> >  1 file changed, 254 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > new file mode 100644
> > index 000000000000..378edb919eae
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > @@ -0,0 +1,254 @@
> > +Allwinner A10 Display Pipeline
> > +==============================
> > +
> > +The Allwinner A10 Display pipeline is composed of several components
> > +that are going to be documented below:
> > +
> > +TV Encoder
> > +----------
> > +
> > +The TV Encoder supports the composite and VGA output. It is one end of
> > +the pipeline.
> > +
> > +Required properties:
> > + - compatible: value should be "allwinner,sun4i-a10-tv-encoder".
> > + - reg: base address and size of memory-mapped region
> > + - clocks: the clocks driving the TV encoder
> > + - resets: phandle to the reset controller driving the encoder
> > +
> > +- ports: A ports node with endpoint definitions as defined in
> > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > +  first port should be the input endpoint.
> > +
> > +TCON
> > +----
> > +
> > +The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
> > +
> > +Required properties:
> > + - compatible: value should be "allwinner,sun5i-a13-tcon".
> > + - reg: base address and size of memory-mapped region
> > + - interrupts: interrupt associated to this IP
> > + - clocks: phandles to the clocks feeding the TCON. Three are needed:
> > +   - 'ahb': the interface clocks
> > +   - 'tcon-ch0': The clock driving the TCON channel 0
> > +   - 'tcon-ch1': The clock driving the TCON channel 1
> > + - resets: phandles to the reset controllers driving the encoder
> > +   - "lcd": the reset line for the TCON channel 0
> > +
> > + - clock-names: the clock names mentioned above
> > + - reset-names: the reset names mentioned above
> > + - clock-output-names: Name of the pixel clock created
> > +
> > +- ports: A ports node with endpoint definitions as defined in
> > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > +  first port should be the input endpoint, the second one the output
> 
> The example shows 2 output endpoints. Your diagram shows up to 4 
> outputs. The number should be how ever many could coexist in a given h/w 
> design. In other words, I'm assuming all 4 can't be used simultaneously, 
> but can all 4 be wired up in a h/w design and switched in s/w? 
> 
> Just be clear on the numbering.

Yes, each TCON has two channels, the first one being usable for
RGB/LVDS, the second one for TV/VGA. HDMI is basically implemented
using an in-SoC RGB-to-HDMI bridge, so it would use the first channel
as well.

I don't see how a particular design could use several devices on the
first channel, because they would share the same timings, and I don't
really see how it would work out.

> > +
> > +Endpoints optional property:
> > +  - allwinner,panel: boolean to indicate that the endpoint is a panel
> 
> This can be determined by the endpoint not being TV Encoder (or HDMI).

It wouldn't really scale if you start to consider the bridges
too. Then, you would have to duplicate and maintain a list of all the
bridges supported in Linux and a list of all the panels supported in
Linux, and try to match that to see if it's a panel, a bridge or an
element of our pipeline.

> 
> > +
> > +
> > +Display Engine Backend
> > +----------------------
> > +
> > +The display engine backend exposes layers and sprites to the
> > +system.
> > +
> > +Required properties:
> > +  - compatible: value must be one of:
> > +    * allwinner,sun5i-a13-display-backend
> > +  - reg: base address and size of the memory-mapped region.
> > +  - clocks: phandles to the clocks feeding the frontend and backend
> > +    * ahb: the backend interface clock
> > +    * mod: the backend module clock
> > +    * ram: the backend DRAM clock
> > +  - clock-names: the clock names mentioned above
> > +  - resets: phandles to the reset controllers driving the backend
> > +
> > +- ports: A ports node with endpoint definitions as defined in
> > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > +  first port should be the input endpoints, the second one the output
> > +
> > +Display Engine Frontend
> > +-----------------------
> > +
> > +The display engine frontend does formats conversion, scaling,
> > +deinterlacing and color space conversion.
> > +
> > +Required properties:
> > +  - compatible: value must be one of:
> > +    * allwinner,sun5i-a13-display-frontend
> > +  - reg: base address and size of the memory-mapped region.
> > +  - interrupts: interrupt associated to this IP
> > +  - clocks: phandles to the clocks feeding the frontend and backend
> > +    * ahb: the backend interface clock
> > +    * mod: the backend module clock
> > +    * ram: the backend DRAM clock
> > +  - clock-names: the clock names mentioned above
> > +  - resets: phandles to the reset controllers driving the backend
> > +
> > +Display Engine Pipeline
> > +-----------------------
> > +
> > +The display engine pipeline (and its entry point, since it can be
> > +either directly the backend or the frontend) is represented as an
> > +extra node.
> > +
> > +Required properties:
> > +  - compatible: value must be one of:
> > +    * allwinner,sun5i-a13-display-engine
> > +  - allwinner,pipelines: list of phandle to the entry points of the
> > +    pipelines (either to the frontend or backend)
> 
> Seems like using FE or BE would be a function of your framebuffers' 
> formats and shouldn't be defined in DT.

Well, they are different IP blocks, so it should be defined in DT,
shouldn't it?

> 
> > +
> > +Example:
> > +
> > +panel: panel {
> > +	compatible = "olimex,lcd-olinuxino-43-ts";
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> > +
> > +	port@0 {
> > +		reg = <0>;
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		panel_input: endpoint@0 {
> > +			reg = <0>;
> > +			remote-endpoint = <&tcon0_out_panel>;
> 
> You can drop the unit-addresses and reg when there is only 1 (or 
> leaving is fine too).
> 
> > +		};
> > +	};
> > +};
> > +
> > +tve0: tv-encoder@01c0a000 {
> 
> Drop the leading 0.

Ok.

> 
> > +	compatible = "allwinner,sun4i-a10-tv-encoder";
> > +	reg = <0x01c0a000 0x1000>;
> > +	clocks = <&ahb_gates 34>;
> > +	resets = <&tcon_ch0_clk 0>;
> > +
> > +	port {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		tve0_in_tcon0: endpoint@0 {
> > +			reg = <0>;
> > +			remote-endpoint = <&tcon0_out_tve0>;
> > +		};
> > +	};
> > +};
> > +
> > +tcon0: lcd-controller@01c0c000 {
> 
> ditto...

Ok.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]


#1366551

FromRob Herring <robh@kernel.org>
Date2016-03-29 21:00 +0200
Message-ID<ri71U-1Ri-15@gated-at.bofh.it>
In reply to#1366119
On Tue, Mar 29, 2016 at 12:33:14PM +0200, Maxime Ripard wrote:
> Hi Rob,
> 
> On Fri, Mar 25, 2016 at 09:11:18AM -0500, Rob Herring wrote:
> > On Wed, Mar 23, 2016 at 05:38:36PM +0100, Maxime Ripard wrote:
> > > The display pipeline of the Allwinner A10 is involving several loosely
> > > coupled components.
> > > 
> > > Add a documentation for the bindings.
> > > 
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > ---
> > >  .../bindings/display/sunxi/sun4i-drm.txt           | 254 +++++++++++++++++++++
> > >  1 file changed, 254 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > new file mode 100644
> > > index 000000000000..378edb919eae
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > @@ -0,0 +1,254 @@
> > > +Allwinner A10 Display Pipeline
> > > +==============================
> > > +
> > > +The Allwinner A10 Display pipeline is composed of several components
> > > +that are going to be documented below:
> > > +
> > > +TV Encoder
> > > +----------
> > > +
> > > +The TV Encoder supports the composite and VGA output. It is one end of
> > > +the pipeline.
> > > +
> > > +Required properties:
> > > + - compatible: value should be "allwinner,sun4i-a10-tv-encoder".
> > > + - reg: base address and size of memory-mapped region
> > > + - clocks: the clocks driving the TV encoder
> > > + - resets: phandle to the reset controller driving the encoder
> > > +
> > > +- ports: A ports node with endpoint definitions as defined in
> > > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > > +  first port should be the input endpoint.
> > > +
> > > +TCON
> > > +----
> > > +
> > > +The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
> > > +
> > > +Required properties:
> > > + - compatible: value should be "allwinner,sun5i-a13-tcon".
> > > + - reg: base address and size of memory-mapped region
> > > + - interrupts: interrupt associated to this IP
> > > + - clocks: phandles to the clocks feeding the TCON. Three are needed:
> > > +   - 'ahb': the interface clocks
> > > +   - 'tcon-ch0': The clock driving the TCON channel 0
> > > +   - 'tcon-ch1': The clock driving the TCON channel 1
> > > + - resets: phandles to the reset controllers driving the encoder
> > > +   - "lcd": the reset line for the TCON channel 0
> > > +
> > > + - clock-names: the clock names mentioned above
> > > + - reset-names: the reset names mentioned above
> > > + - clock-output-names: Name of the pixel clock created
> > > +
> > > +- ports: A ports node with endpoint definitions as defined in
> > > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > > +  first port should be the input endpoint, the second one the output
> > 
> > The example shows 2 output endpoints. Your diagram shows up to 4 
> > outputs. The number should be how ever many could coexist in a given h/w 
> > design. In other words, I'm assuming all 4 can't be used simultaneously, 
> > but can all 4 be wired up in a h/w design and switched in s/w? 
> > 
> > Just be clear on the numbering.
> 
> Yes, each TCON has two channels, the first one being usable for
> RGB/LVDS, the second one for TV/VGA. HDMI is basically implemented
> using an in-SoC RGB-to-HDMI bridge, so it would use the first channel
> as well.

So I think you should have 2 ports (1 per channel) and then 2 endpoints 
for 1st (RGB/LVDS/ExtBridge and HDMI) and 1 endpoint (TV/VGA) for 2nd 
port.

> I don't see how a particular design could use several devices on the
> first channel, because they would share the same timings, and I don't
> really see how it would work out.
> 
> > > +
> > > +Endpoints optional property:
> > > +  - allwinner,panel: boolean to indicate that the endpoint is a panel
> > 
> > This can be determined by the endpoint not being TV Encoder (or HDMI).
> 
> It wouldn't really scale if you start to consider the bridges
> too. Then, you would have to duplicate and maintain a list of all the
> bridges supported in Linux and a list of all the panels supported in
> Linux, and try to match that to see if it's a panel, a bridge or an
> element of our pipeline.

So my concern is that no one else has needed this, so why do you? Based 
on the above, you know that a panel is always connected to port 0, 
endpoint 0. If it is an external bridge instead, then that can be 
determined when the bridge driver is bound.


> > > +Display Engine Backend
> > > +----------------------
> > > +
> > > +The display engine backend exposes layers and sprites to the
> > > +system.
> > > +
> > > +Required properties:
> > > +  - compatible: value must be one of:
> > > +    * allwinner,sun5i-a13-display-backend
> > > +  - reg: base address and size of the memory-mapped region.
> > > +  - clocks: phandles to the clocks feeding the frontend and backend
> > > +    * ahb: the backend interface clock
> > > +    * mod: the backend module clock
> > > +    * ram: the backend DRAM clock
> > > +  - clock-names: the clock names mentioned above
> > > +  - resets: phandles to the reset controllers driving the backend
> > > +
> > > +- ports: A ports node with endpoint definitions as defined in
> > > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > > +  first port should be the input endpoints, the second one the output
> > > +
> > > +Display Engine Frontend
> > > +-----------------------
> > > +
> > > +The display engine frontend does formats conversion, scaling,
> > > +deinterlacing and color space conversion.
> > > +
> > > +Required properties:
> > > +  - compatible: value must be one of:
> > > +    * allwinner,sun5i-a13-display-frontend
> > > +  - reg: base address and size of the memory-mapped region.
> > > +  - interrupts: interrupt associated to this IP
> > > +  - clocks: phandles to the clocks feeding the frontend and backend
> > > +    * ahb: the backend interface clock
> > > +    * mod: the backend module clock
> > > +    * ram: the backend DRAM clock
> > > +  - clock-names: the clock names mentioned above
> > > +  - resets: phandles to the reset controllers driving the backend
> > > +
> > > +Display Engine Pipeline
> > > +-----------------------
> > > +
> > > +The display engine pipeline (and its entry point, since it can be
> > > +either directly the backend or the frontend) is represented as an
> > > +extra node.
> > > +
> > > +Required properties:
> > > +  - compatible: value must be one of:
> > > +    * allwinner,sun5i-a13-display-engine
> > > +  - allwinner,pipelines: list of phandle to the entry points of the
> > > +    pipelines (either to the frontend or backend)
> > 
> > Seems like using FE or BE would be a function of your framebuffers' 
> > formats and shouldn't be defined in DT.
> 
> Well, they are different IP blocks, so it should be defined in DT,
> shouldn't it?

They should, but allwinner,sun5i-a13-display-engine is not really an IP 
block. Again, what decides if you use the FE or not?

Rob

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web