aboutsummaryrefslogtreecommitdiff
path: root/drivers/video/simplefb.c
AgeCommit message (Collapse)Author
2013-08-02fbdev: simplefb: mark as fw and allocate aperturesDavid Herrmann
fbdev-core uses FBINFO_MISC_FIRMWARE to mark drivers that use firmware framebuffers. Furthermore, we now allocate apertures for the fbinfo device. Both information is used by remove_conflicting_framebuffers() to remove a fbdev device whenever a real driver is loaded. This is used heavily on x86 for VGA/vesa/EFI framebuffers, but is also of great use for all other systems. Especially with x86 support for simplefb, this information is needed to unload simplefb before a real hw-driver (like i915, radeon, nouveau) is loaded. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1375445127-15480-3-git-send-email-dh.herrmann@gmail.com Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02fbdev: simplefb: add init through platform_dataDavid Herrmann
If we create proper platform-devices in x86 boot-code, we can use simplefb for VBE or EFI framebuffers, too. However, there is normally no OF support so we introduce a platform_data object so x86 boot-code can pass the parameters via plain old platform-data. This also removes the OF dependency as it is not needed. The headers provide proper dummies for the case OF is disabled. Furthermore, we move the FORMAT-definitions to the common platform header so initialization code can use it to transform "struct screen_info" to the right format-name. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1375445127-15480-2-git-send-email-dh.herrmann@gmail.com Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-05-24drivers/video: implement a simple framebuffer driverStephen Warren
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>