summaryrefslogtreecommitdiff
path: root/drivers/video/simplefb.c
AgeCommit message (Collapse)Author
2013-10-30simplefb: use write-combined remappingDavid Herrmann
Framebuffers shouldn't be cached and it is usually very uncommon to read them. Therefore, use ioremap_wc() to get significant speed improvements on systems which provide it. On all other systems it's aliased to ioremap_nocache() which is also fine. Reported-by: Tom Gundersen <teg@jklm.no> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Tested-by: Tom Gundersen <teg@jklm.no> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-10-30simplefb: fix unmapping fb during destructionDavid Herrmann
Unfortunately, fbdev does not create its own "struct device" for framebuffers. Instead, it attaches to the device of the parent layer. This has the side-effect that devm_* managed resources are not cleaned up on framebuffer-destruction but rather during destruction of the parent-device. In case of fbdev this might be too late, though. remove_conflicting_framebuffer() may remove fbdev devices but keep the parent device as it is. Therefore, we now use plain ioremap() and unmap the framebuffer in the fb_destroy() callback. Note that we must not free the device here as this might race with the parent-device removal. Instead, we rely on unregister_framebuffer() as barrier and we're safe. Reported-by: Tom Gundersen <teg@jklm.no> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-10-09simplefb: print some info about the registered fbTom Gundersen
This is similar to the output printed by efifb. Signed-off-by: Tom Gundersen <teg@jklm.no> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Cc: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-09-20video: simplefb: use dev_get_platdata()Jingoo Han
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. This is a cosmetic change to make the code simpler and enhance the readability. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
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>