video: ARM CLCD: Add DT support

This patch adds basic DT bindings for the PL11x CLCD cells and make their fbdev driver use them.

---
Changes since v4:
- simplified the pads description property and made it optional

Changes since v3:
- changed wording and order of interrupt-names and interrupts properties documentation
- changed wording of arm,pl11x,framebuffer-base property documentation
- cleaned up binding documentation indentation

Changes since v2:
- replaced video-ram phandle with arm,pl11x,framebuffer-base
- replaced panel-* properties with arm,pl11x,panel-data-pads
- replaced max-framebuffer-size with max-memory-bandwidth
- modified clcdfb_of_init_tft_panel() to use the pads data and take differences between PL110 and PL110 into account

Changes since v1:
- minor code cleanups as suggested by Sylwester Nawrocki

 .../devicetree/bindings/video/arm,pl11x.txt        |  83 ++++++++
 drivers/video/Kconfig                              |   1 +
 drivers/video/amba-clcd.c                          | 219 +++++++++++++++++++++
 3 files changed, 303 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt

new file mode 100644
index 0000000..75da7b7
@@ -0,0 +1,83 @@
+* ARM PrimeCell Color LCD Controller PL110/PL111
+
+See also Documentation/devicetree/bindings/arm/primecell.txt
+
+Required properties:
+
+- compatible: must be one of:
+	"arm,pl110", "arm,primecell"
+	"arm,pl111", "arm,primecell"
+
+- reg: base address and size of the control registers block
+
+- interrupt-names: either the single entry "combined" representing a
+	combined interrupt output (CLCDINTR), or the four entries
+	"mbe", "vcomp", "lnbu", "fuf" representing the individual
+	CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts
+
+- interrupts: contains an interrupt specifier for each entry in
+	interrupt-names
+
+- clocks-names: should contain "clcdclk" and "apb_pclk"
+
+- clocks: contains phandle and clock specifier pairs for the entries
+	in the clock-names property. See
+	Documentation/devicetree/binding/clock/clock-bindings.txt
+
+Optional properties:
+
+- arm,pl11x,framebuffer-base: a pair of two 32-bit values, address and size,
+	defining the framebuffer that must be used; if not present, the
+	framebuffer may be located anywhere in the memory
+
+- arm,pl11x,tft-r0g0b0-pads: when connected to a TFT panel, an array of three
+	32-bit values, defining the way CLD pads are wired up; this implicitly
+	defines available color modes, for example:
+	- PL111 TFT 4:4:4 panel:
+		arm,pl11x,tft-r0g0b0-pads = <4 15 20>;
+	- PL110 TFT (1:)5:5:5 panel:
+		arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
+	- PL111 TFT (1:)5:5:5 panel:
+		arm,pl11x,tft-r0g0b0-pads = <3 11 19>;
+	- PL111 TFT 5:6:5 panel:
+		arm,pl11x,tft-r0g0b0-pads = <3 10 19>;
+	- PL110 and PL111 TFT 8:8:8 panel:
+		arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+	- PL110 and PL111 TFT 8:8:8 panel, R & B components swapped:
+		arm,pl11x,tft-r0g0b0-pads = <16 8 0>;
+
+- max-memory-bandwidth: maximum bandwidth in bytes per second that the
+	cell's memory interface can handle
+
+- display-timings: standard display timings sub-node, defining possible
+	video modes of a connected panel; for details see
+	Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+	clcd at 1f0000 {
+		compatible = "arm,pl111", "arm,primecell";
+		reg = <0x1f0000 0x1000>;
+		interrupt-names = "combined";
+		interrupts = <14>;
+		clock-names = "clcdclk", "apb_pclk";
+		clocks = <&v2m_oscclk1>, <&smbclk>;
+
+		arm,pl11x,framebuffer-base = <0x18000000 0x00800000>;
+		arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+		max-memory-bandwidth = <36864000>; /* bps, 640x480 at 60 16bpp */
+		display-timings {
+			native-mode = <&v2m_clcd_timing0>;
+			v2m_clcd_timing0: vga {
+				clock-frequency = <25175000>;
+				hactive = <640>;
+				hback-porch = <40>;
+				hfront-porch = <24>;
+				hsync-len = <96>;
+				vactive = <480>;
+				vback-porch = <32>;
+				vfront-porch = <11>;
+				vsync-len = <2>;
+			};
+		};
+	};

index dade5b7..c1d25c9 100644
@@ -317,6 +317,7 @@ config FB_ARMCLCD
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
+	select VIDEOMODE_HELPERS if OF
 	help
 	  This framebuffer device driver is for the ARM PrimeCell PL110
 	  Colour LCD controller.  ARM PrimeCells provide the building

1.8.3.2

... for V2M-P1 motherboard CLCD (limited to 640x480 16bpp and using dedicated video RAM bank) and for V2P-CA9 (up to 1024x768 16bpp).

---
 arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 21 ++++++++++++++++++++-
 arch/arm/boot/dts/vexpress-v2m.dtsi     | 21 ++++++++++++++++++++-
 arch/arm/boot/dts/vexpress-v2p-ca9.dts  | 18 ++++++++++++++++++
 3 files changed, 58 insertions(+), 2 deletions(-)

index ac870fb..c95a4cb 100644
@@ -230,9 +230,28 @@
 			clcd at 1f0000 {
 				compatible = "arm,pl111", "arm,primecell";
 				reg = <0x1f0000 0x1000>;
+				interrupt-names = "combined";
 				interrupts = <14>;
 				clocks = <&v2m_oscclk1>, <&smbclk>;
 				clock-names = "clcdclk", "apb_pclk";
+
+				arm,pl11x,framebuffer-base = <0x18000000 0x00800000>;
+				arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+				max-memory-bandwidth = <36864000>; /* Bps, 640x480 at 60 16bpp */
+				display-timings {
+					native-mode = <&v2m_clcd_timing0>;
+					v2m_clcd_timing0: vga {
+						clock-frequency = <25175000>;
+						hactive = <640>;
+						hback-porch = <40>;
+						hfront-porch = <24>;
+						hsync-len = <96>;
+						vactive = <480>;
+						vback-porch = <32>;
+						vfront-porch = <11>;
+						vsync-len = <2>;
+					};
+				};
 			};
 		};
 

@@ -282,7 +301,7 @@
 				/* CLCD clock */
 				compatible = "arm,vexpress-osc";
 				arm,vexpress-sysreg,func = <1 1>;
-				freq-range = <23750000 63500000>;
+				freq-range = <23750000 65000000>;
 				#clock-cells = <0>;
 				clock-output-names = "v2m:oscclk1";
 			};

index f142036..9224834 100644
@@ -229,9 +229,28 @@
 			clcd at 1f000 {
 				compatible = "arm,pl111", "arm,primecell";
 				reg = <0x1f000 0x1000>;
+				interrupt-names = "combined";
 				interrupts = <14>;
 				clocks = <&v2m_oscclk1>, <&smbclk>;
 				clock-names = "clcdclk", "apb_pclk";
+
+				arm,pl11x,framebuffer-base = <0x4c000000 0x00800000>;
+				arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+				max-memory-bandwidth = <36864000>; /* Bps, 640x480 at 60 16bpp */
+				display-timings {
+					native-mode = <&v2m_clcd_timing0>;
+					v2m_clcd_timing0: vga {
+						clock-frequency = <25175000>;
+						hactive = <640>;
+						hback-porch = <40>;
+						hfront-porch = <24>;
+						hsync-len = <96>;
+						vactive = <480>;
+						vback-porch = <32>;
+						vfront-porch = <11>;
+						vsync-len = <2>;
+					};
+				};
 			};
 		};
 

@@ -281,7 +300,7 @@
 				/* CLCD clock */
 				compatible = "arm,vexpress-osc";
 				arm,vexpress-sysreg,func = <1 1>;
-				freq-range = <23750000 63500000>;
+				freq-range = <23750000 65000000>;
 				#clock-cells = <0>;
 				clock-output-names = "v2m:oscclk1";
 			};

index 62d9b22..ed4f223 100644
@@ -70,9 +70,27 @@
 	clcd at 10020000 {
 		compatible = "arm,pl111", "arm,primecell";
 		reg = <0x10020000 0x1000>;
+		interrupt-names = "combined";
 		interrupts = <0 44 4>;
 		clocks = <&oscclk1>, <&oscclk2>;
 		clock-names = "clcdclk", "apb_pclk";
+
+		arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+		max-memory-bandwidth = <94371840>; /* Bps, 1024x768 at 60 16bpp */
+		display-timings {
+			native-mode = <&clcd_timing0>;
+			clcd_timing0: xga {
+				clock-frequency = <63500127>;
+				hactive = <1024>;
+				hback-porch = <152>;
+				hfront-porch = <48>;
+				hsync-len = <104>;
+				vactive = <768>;
+				vback-porch = <23>;
+				vfront-porch = <3>;
+				vsync-len = <4>;
+			};
+		};
 	};
 
 	memory-controller at 100e0000 {

1.8.3.2

Hi Pawel,

Is this an old HW, and presumably there won't be new users for it? If yes, this is probably fine. If not, you might want to look at the video ports and endpoints, which is used by at least three not-yet-merged series:

[PATCHv3 00/41] OMAPDSS: DT support v3
[PATCH v5 00/11] imx-drm dt bindings
[RFC PATCH v2 00/21] Add DSI display support for Exynos based boards

Using bindings like that would be more future proof, even if the current driver doesn't use them.

Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140306/96146f79/attachment.sig>

There is a DRM driver in the works, actually...

... and this makes me try to get out of its way. In other words, I fully agree with you, but I don't think this applies to this particular patch, as I'm not even trying to represent the display pipeline. The (optional) "display-timings" sub-node has been "borrowed" from other older drivers and can be easily deprecated in the future, replaced by standard ones (whatever final shape they will take :-). All other extra properties are CLCD-specific and orthogonal.

Pawel

Right, you are not, at the moment. My point was, if the driver is extended later to support pipelines, or common panel/encoder drivers, you (most likely) need to have similar bindings than the other people use.

Note that the same DT bindings you add here should also work for the DRM driver in the future. So, in fact, the question is extended to: will the fbdev or drm driver support common panels/encoders?

Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140307/91a78354/attachment-0001.sig>

No argument here.

No, I don't think so. It's a end of line for it, I believe. From my personal point of view the main goal is to fill the last gap between DT and non-DT support on one of the Versatile Express boards - CLCD works fine when booted with ATAGs, doesn't work when booted with DT. It looks bad.

I would hope so, yes. VE display pipeline is quite complex (more than I would hope ;-) so to implement KMS in a proper way (with hotplugging, bells and whistles) it will have to know more than now. But it's out of scope for me.

Pawel

The DT describes the hardware, and there should be only one description of it, no matter what the used SW is. I see compatible = "arm,pl111" in the dts. PL111 is the LCD controller, right? What will the DRM driver use, then, if the "arm,pl111" DT data is designed to work only for the fbdev?

Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140310/b28a4f0a/attachment.sig>

If we could move forward with things like DT bindings for DRM (which seems impossible) then we might be able to move forward with a proper DT implementation for componentised video systems which would solve this as you'd have the pl111 as just a CRTC component in a larger subsystem representation which included things like encoders and connectors - even for something as simple as the Versatile Express boards.

These boards have a DVI connector which offers analogue (and probably digital) output. Previous boards like Versatile and Integrator have offered VGA output and a connector for various LCD panels (sometimes the connected LCD panel is identified via a set of GPIOs.)

So, going ahead with some bindings which include stuff like timing information in a pl111 node seems wrong and boxes us in if we're going to start representing connectors as well - as the timing should be part of the panel node or similar.

So basically all movement on display subsystem DT representations is now blocked because no one can agree how they should be represented in a decent way.

Maybe board files were much better than this frigging DT crap.

FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Correct.

Exactly the same properties, plus (hopefully) the generic display data, when (if) ready.

The binding I proposed is *not* designed to work only with the fbdev driver, no. That's what I was trying to say all way long, if I failed - apologies.

So let me say it again: with the exception display timings subnode, all other properties will be important for the DRM scan out driver as well. As to the display timings, being optional can be easily marked as deprecated and replaced with the proper solution.

Now, if you find any other property I proposed being non generic enough (ie. fbdev-specific), I will happily discuss it. Once you get generic display bindings in place, I will gladly do all that will be required to make CLCD driver(s) use them. But I will rather drop and forget this patch completely that get dragged into another "display/video/CDF/DRM/whatever" discussion. Hope I made myself clear.

Pawel

AFAICT ARM really like to re-synthesize this piece of HW in every new reference design they make. Plus a number of manufacturers have used it in elder systems.

I take it that it shouldn't matter if the driver is for framebuffer or DRM (as was implied by some answer here) the hardware description should be the same no matter what, so the more furture-proof the better.

Yours,
Linus Walleij

Not for long now, hopefully...

Again, no argument here - the clcd-specific properties will be of use whatever happens in the future (the "immediate" display timing subnode is optional and is cloned from other existing bindings, so no new problem is introduced here). I'm just shying away from the discussions on generic display (or CDF or video or whatever) bindings. Call me coward if you wish (maybe just tired to death with this subject ;-)

Pawel