drivers/video: implement a simple framebuffer driver
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.
Examples use-cases include:
* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
devices, and likely many other ARM or embedded systems. These cannot
yet be supported using a full graphics driver, since the panel control
should be provided by the CDF (Common Display Framework), which has been
stuck in design/review for quite some time. One could support these
panels using custom SoC-specific code, but there is a desire to use
common infra-structure rather than having each SoC vendor invent their
own code, hence the desire to wait for CDF.
* Hardware for which a full graphics driver is not yet available, and
the path to obtain one upstream isn't yet clear. For example, the
Raspberry Pi.
* Any hardware in early stages of upstreaming, before a full graphics
driver has been tackled. This driver can provide a graphical boot
console (even full X support) much earlier in the upstreaming process,
thus making new SoC or board support more generally useful earlier.
[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: Rob Clark <robclark@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-05-24 22:55:13 +00:00
|
|
|
Simple Framebuffer
|
|
|
|
|
2014-11-14 12:26:47 +00:00
|
|
|
A simple frame-buffer describes a frame-buffer setup by firmware or
|
|
|
|
the bootloader, with the assumption that the display hardware has already
|
|
|
|
been set up to scan out from the memory pointed to by the reg property.
|
drivers/video: implement a simple framebuffer driver
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.
Examples use-cases include:
* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
devices, and likely many other ARM or embedded systems. These cannot
yet be supported using a full graphics driver, since the panel control
should be provided by the CDF (Common Display Framework), which has been
stuck in design/review for quite some time. One could support these
panels using custom SoC-specific code, but there is a desire to use
common infra-structure rather than having each SoC vendor invent their
own code, hence the desire to wait for CDF.
* Hardware for which a full graphics driver is not yet available, and
the path to obtain one upstream isn't yet clear. For example, the
Raspberry Pi.
* Any hardware in early stages of upstreaming, before a full graphics
driver has been tackled. This driver can provide a graphical boot
console (even full X support) much earlier in the upstreaming process,
thus making new SoC or board support more generally useful earlier.
[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: Rob Clark <robclark@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-05-24 22:55:13 +00:00
|
|
|
|
2014-11-14 12:26:51 +00:00
|
|
|
Since simplefb nodes represent runtime information they must be sub-nodes of
|
|
|
|
the chosen node (*). Simplefb nodes must be named "framebuffer@<address>".
|
|
|
|
|
|
|
|
If the devicetree contains nodes for the display hardware used by a simplefb,
|
|
|
|
then the simplefb node must contain a property called "display", which
|
|
|
|
contains a phandle pointing to the primary display hw node, so that the OS
|
|
|
|
knows which simplefb to disable when handing over control to a driver for the
|
|
|
|
real hardware. The bindings for the hw nodes must specify which node is
|
|
|
|
considered the primary node.
|
|
|
|
|
|
|
|
It is advised to add display# aliases to help the OS determine how to number
|
|
|
|
things. If display# aliases are used, then if the simplefb node contains a
|
|
|
|
"display" property then the /aliases/display# path must point to the display
|
|
|
|
hw node the "display" property points to, otherwise it must point directly
|
|
|
|
to the simplefb node.
|
|
|
|
|
|
|
|
If a simplefb node represents the preferred console for user interaction,
|
|
|
|
then the chosen node's stdout-path property should point to it, or to the
|
|
|
|
primary display hw node, as with display# aliases. If display aliases are
|
|
|
|
used then it should be set to the alias instead.
|
|
|
|
|
|
|
|
It is advised that devicetree files contain pre-filled, disabled framebuffer
|
|
|
|
nodes, so that the firmware only needs to update the mode information and
|
|
|
|
enable them. This way if e.g. later on support for more display clocks get
|
|
|
|
added, the simplefb nodes will already contain this info and the firmware
|
|
|
|
does not need to be updated.
|
|
|
|
|
2014-11-18 11:10:50 +00:00
|
|
|
If pre-filled framebuffer nodes are used, the firmware may need extra
|
|
|
|
information to find the right node. In that case an extra platform specific
|
|
|
|
compatible and platform specific properties should be used and documented,
|
|
|
|
see e.g. simple-framebuffer-sunxi.txt .
|
2014-11-14 12:26:51 +00:00
|
|
|
|
drivers/video: implement a simple framebuffer driver
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.
Examples use-cases include:
* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
devices, and likely many other ARM or embedded systems. These cannot
yet be supported using a full graphics driver, since the panel control
should be provided by the CDF (Common Display Framework), which has been
stuck in design/review for quite some time. One could support these
panels using custom SoC-specific code, but there is a desire to use
common infra-structure rather than having each SoC vendor invent their
own code, hence the desire to wait for CDF.
* Hardware for which a full graphics driver is not yet available, and
the path to obtain one upstream isn't yet clear. For example, the
Raspberry Pi.
* Any hardware in early stages of upstreaming, before a full graphics
driver has been tackled. This driver can provide a graphical boot
console (even full X support) much earlier in the upstreaming process,
thus making new SoC or board support more generally useful earlier.
[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: Rob Clark <robclark@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-05-24 22:55:13 +00:00
|
|
|
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).
|
2013-06-07 07:31:30 +00:00
|
|
|
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
|
drivers/video: implement a simple framebuffer driver
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.
Examples use-cases include:
* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
devices, and likely many other ARM or embedded systems. These cannot
yet be supported using a full graphics driver, since the panel control
should be provided by the CDF (Common Display Framework), which has been
stuck in design/review for quite some time. One could support these
panels using custom SoC-specific code, but there is a desire to use
common infra-structure rather than having each SoC vendor invent their
own code, hence the desire to wait for CDF.
* Hardware for which a full graphics driver is not yet available, and
the path to obtain one upstream isn't yet clear. For example, the
Raspberry Pi.
* Any hardware in early stages of upstreaming, before a full graphics
driver has been tackled. This driver can provide a graphical boot
console (even full X support) much earlier in the upstreaming process,
thus making new SoC or board support more generally useful earlier.
[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: Rob Clark <robclark@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-05-24 22:55:13 +00:00
|
|
|
|
2014-11-14 12:26:47 +00:00
|
|
|
Optional properties:
|
2015-11-17 04:31:02 +00:00
|
|
|
- clocks : List of clocks used by the framebuffer.
|
|
|
|
- *-supply : Any number of regulators used by the framebuffer. These should
|
|
|
|
be named according to the names in the device's design.
|
|
|
|
|
|
|
|
The above resources are expected to already be configured correctly.
|
|
|
|
The OS must ensure they are not modified or disabled while the simple
|
|
|
|
framebuffer remains active.
|
|
|
|
|
2014-11-14 12:26:51 +00:00
|
|
|
- display : phandle pointing to the primary display hardware node
|
2014-11-14 12:26:47 +00:00
|
|
|
|
drivers/video: implement a simple framebuffer driver
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.
Examples use-cases include:
* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
devices, and likely many other ARM or embedded systems. These cannot
yet be supported using a full graphics driver, since the panel control
should be provided by the CDF (Common Display Framework), which has been
stuck in design/review for quite some time. One could support these
panels using custom SoC-specific code, but there is a desire to use
common infra-structure rather than having each SoC vendor invent their
own code, hence the desire to wait for CDF.
* Hardware for which a full graphics driver is not yet available, and
the path to obtain one upstream isn't yet clear. For example, the
Raspberry Pi.
* Any hardware in early stages of upstreaming, before a full graphics
driver has been tackled. This driver can provide a graphical boot
console (even full X support) much earlier in the upstreaming process,
thus making new SoC or board support more generally useful earlier.
[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: Rob Clark <robclark@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-05-24 22:55:13 +00:00
|
|
|
Example:
|
|
|
|
|
2014-11-14 12:26:51 +00:00
|
|
|
aliases {
|
|
|
|
display0 = &lcdc0;
|
|
|
|
}
|
|
|
|
|
|
|
|
chosen {
|
|
|
|
framebuffer0: framebuffer@1d385000 {
|
drivers/video: implement a simple framebuffer driver
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.
Examples use-cases include:
* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
devices, and likely many other ARM or embedded systems. These cannot
yet be supported using a full graphics driver, since the panel control
should be provided by the CDF (Common Display Framework), which has been
stuck in design/review for quite some time. One could support these
panels using custom SoC-specific code, but there is a desire to use
common infra-structure rather than having each SoC vendor invent their
own code, hence the desire to wait for CDF.
* Hardware for which a full graphics driver is not yet available, and
the path to obtain one upstream isn't yet clear. For example, the
Raspberry Pi.
* Any hardware in early stages of upstreaming, before a full graphics
driver has been tackled. This driver can provide a graphical boot
console (even full X support) much earlier in the upstreaming process,
thus making new SoC or board support more generally useful earlier.
[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: Rob Clark <robclark@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-05-24 22:55:13 +00:00
|
|
|
compatible = "simple-framebuffer";
|
|
|
|
reg = <0x1d385000 (1600 * 1200 * 2)>;
|
|
|
|
width = <1600>;
|
|
|
|
height = <1200>;
|
|
|
|
stride = <(1600 * 2)>;
|
|
|
|
format = "r5g6b5";
|
2014-11-14 12:26:51 +00:00
|
|
|
clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
|
2015-11-17 04:31:02 +00:00
|
|
|
lcd-supply = <®_dc1sw>;
|
2014-11-14 12:26:51 +00:00
|
|
|
display = <&lcdc0>;
|
|
|
|
};
|
|
|
|
stdout-path = "display0";
|
|
|
|
};
|
|
|
|
|
|
|
|
soc@01c00000 {
|
|
|
|
lcdc0: lcdc@1c0c000 {
|
|
|
|
compatible = "allwinner,sun4i-a10-lcdc";
|
|
|
|
...
|
drivers/video: implement a simple framebuffer driver
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.
Examples use-cases include:
* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
devices, and likely many other ARM or embedded systems. These cannot
yet be supported using a full graphics driver, since the panel control
should be provided by the CDF (Common Display Framework), which has been
stuck in design/review for quite some time. One could support these
panels using custom SoC-specific code, but there is a desire to use
common infra-structure rather than having each SoC vendor invent their
own code, hence the desire to wait for CDF.
* Hardware for which a full graphics driver is not yet available, and
the path to obtain one upstream isn't yet clear. For example, the
Raspberry Pi.
* Any hardware in early stages of upstreaming, before a full graphics
driver has been tackled. This driver can provide a graphical boot
console (even full X support) much earlier in the upstreaming process,
thus making new SoC or board support more generally useful earlier.
[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: Rob Clark <robclark@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-05-24 22:55:13 +00:00
|
|
|
};
|
2014-11-14 12:26:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
*) Older devicetree files may have a compatible = "simple-framebuffer" node
|
|
|
|
in a different place, operating systems must first enumerate any compatible
|
|
|
|
nodes found under chosen and then check for other compatible nodes.
|