Thread (6 messages) 6 messages, 5 authors, 2013-04-30

Re: [PATCH V2] video: implement a simple framebuffer driver

From: Tomi Valkeinen <hidden>
Date: 2013-04-30 07:39:43
Also in: linux-arm-kernel, linux-devicetree

On 04/04/2013 05:39 AM, Stephen Warren wrote:
quoted hunk ↗ jump to hunk
A simple frame-buffer describes a raw memory region that may be rendered
to, with the assumption that the display hardware has already been set
up to scan out from that buffer.

This is useful in cases where a bootloader exists and has set up the
display hardware, but a Linux driver doesn't yet exist for the display
hardware.

Signed-off-by: Stephen Warren <redacted>
---
v2: s/dumb/simple/ throughout. Provide more details on pixel format.

I ended up going with a separate FB driver:
* DRM/KMS look much more complex, and don't provide any benefit that I can
  tell for this simple driver.
* Creating a separate driver rather than adjusting offb.c to work allows a
  new clean binding to be defined, and doesn't require removing or ifdefing
  PPC-isms in offb.c.
---
 .../bindings/video/simple-framebuffer.txt          |   25 +++
 drivers/video/Kconfig                              |   17 ++
 drivers/video/Makefile                             |    1 +
 drivers/video/simplefb.c                           |  234 ++++++++++++++++++++
 4 files changed, 277 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer.txt
 create mode 100644 drivers/video/simplefb.c
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
new file mode 100644
index 0000000..3ea4605
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -0,0 +1,25 @@
+Simple Framebuffer
+
+A simple frame-buffer describes a raw memory region that may be rendered to,
+with the assumption that the display hardware has already been set up to scan
+out from that buffer.
+
+Required properties:
+- compatible: "simple-framebuffer"
+- reg: Should contain the location and size of the framebuffer memory.
+- width: The width of the framebuffer in pixels.
+- height: The height of the framebuffer in pixels.
+- stride: The number of bytes in each line of the framebuffer.
+- format: The format of the framebuffer surface. Valid values are:
+  - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
+
+Example:
+
+	framebuffer {
+		compatible = "simple-framebuffer";
+		reg = <0x1d385000 (1600 * 1200 * 2)>;
+		width = <1600>;
+		height = <1200>;
+		stride = <(1600 * 2)>;
+		format = "r5g6b5";
+	};
I'm not an expert on DT, but I think the point of DT is to describe the
hardware. This doesn't describe the hardware at all.

 Tomi

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help