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
|
|
|
/*
|
|
|
|
* Simplest possible simple frame-buffer driver, as a platform device
|
|
|
|
*
|
|
|
|
* Copyright (c) 2013, Stephen Warren
|
|
|
|
*
|
|
|
|
* Based on q40fb.c, which was:
|
|
|
|
* Copyright (C) 2001 Richard Zidlicky <rz@linux-m68k.org>
|
|
|
|
*
|
|
|
|
* Also based on offb.c, which was:
|
|
|
|
* Copyright (C) 1997 Geert Uytterhoeven
|
|
|
|
* Copyright (C) 1996 Paul Mackerras
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms and conditions of the GNU General Public License,
|
|
|
|
* version 2, as published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
|
|
|
* more details.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/fb.h>
|
|
|
|
#include <linux/io.h>
|
|
|
|
#include <linux/module.h>
|
2013-08-02 12:05:20 +00:00
|
|
|
#include <linux/platform_data/simplefb.h>
|
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
|
|
|
#include <linux/platform_device.h>
|
2014-11-14 12:26:50 +00:00
|
|
|
#include <linux/clk-provider.h>
|
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
|
|
|
|
|
|
|
static struct fb_fix_screeninfo simplefb_fix = {
|
|
|
|
.id = "simple",
|
|
|
|
.type = FB_TYPE_PACKED_PIXELS,
|
|
|
|
.visual = FB_VISUAL_TRUECOLOR,
|
|
|
|
.accel = FB_ACCEL_NONE,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct fb_var_screeninfo simplefb_var = {
|
|
|
|
.height = -1,
|
|
|
|
.width = -1,
|
|
|
|
.activate = FB_ACTIVATE_NOW,
|
|
|
|
.vmode = FB_VMODE_NONINTERLACED,
|
|
|
|
};
|
|
|
|
|
2014-11-14 12:26:48 +00:00
|
|
|
#define PSEUDO_PALETTE_SIZE 16
|
|
|
|
|
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
|
|
|
static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
|
|
|
|
u_int transp, struct fb_info *info)
|
|
|
|
{
|
|
|
|
u32 *pal = info->pseudo_palette;
|
|
|
|
u32 cr = red >> (16 - info->var.red.length);
|
|
|
|
u32 cg = green >> (16 - info->var.green.length);
|
|
|
|
u32 cb = blue >> (16 - info->var.blue.length);
|
|
|
|
u32 value;
|
|
|
|
|
2014-11-14 12:26:48 +00:00
|
|
|
if (regno >= PSEUDO_PALETTE_SIZE)
|
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
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
value = (cr << info->var.red.offset) |
|
|
|
|
(cg << info->var.green.offset) |
|
|
|
|
(cb << info->var.blue.offset);
|
|
|
|
if (info->var.transp.length > 0) {
|
|
|
|
u32 mask = (1 << info->var.transp.length) - 1;
|
|
|
|
mask <<= info->var.transp.offset;
|
|
|
|
value |= mask;
|
|
|
|
}
|
|
|
|
pal[regno] = value;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-10-02 14:58:38 +00:00
|
|
|
static void simplefb_destroy(struct fb_info *info)
|
|
|
|
{
|
|
|
|
if (info->screen_base)
|
|
|
|
iounmap(info->screen_base);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
static struct fb_ops simplefb_ops = {
|
|
|
|
.owner = THIS_MODULE,
|
2013-10-02 14:58:38 +00:00
|
|
|
.fb_destroy = simplefb_destroy,
|
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
|
|
|
.fb_setcolreg = simplefb_setcolreg,
|
|
|
|
.fb_fillrect = cfb_fillrect,
|
|
|
|
.fb_copyarea = cfb_copyarea,
|
|
|
|
.fb_imageblit = cfb_imageblit,
|
|
|
|
};
|
|
|
|
|
2013-08-02 12:05:20 +00:00
|
|
|
static struct simplefb_format simplefb_formats[] = SIMPLEFB_FORMATS;
|
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
|
|
|
|
|
|
|
struct simplefb_params {
|
|
|
|
u32 width;
|
|
|
|
u32 height;
|
|
|
|
u32 stride;
|
|
|
|
struct simplefb_format *format;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int simplefb_parse_dt(struct platform_device *pdev,
|
|
|
|
struct simplefb_params *params)
|
|
|
|
{
|
|
|
|
struct device_node *np = pdev->dev.of_node;
|
|
|
|
int ret;
|
|
|
|
const char *format;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
ret = of_property_read_u32(np, "width", ¶ms->width);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(&pdev->dev, "Can't parse width property\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = of_property_read_u32(np, "height", ¶ms->height);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(&pdev->dev, "Can't parse height property\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = of_property_read_u32(np, "stride", ¶ms->stride);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(&pdev->dev, "Can't parse stride property\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = of_property_read_string(np, "format", &format);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(&pdev->dev, "Can't parse format property\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
params->format = NULL;
|
|
|
|
for (i = 0; i < ARRAY_SIZE(simplefb_formats); i++) {
|
|
|
|
if (strcmp(format, simplefb_formats[i].name))
|
|
|
|
continue;
|
|
|
|
params->format = &simplefb_formats[i];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (!params->format) {
|
|
|
|
dev_err(&pdev->dev, "Invalid format value\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-08-02 12:05:20 +00:00
|
|
|
static int simplefb_parse_pd(struct platform_device *pdev,
|
|
|
|
struct simplefb_params *params)
|
|
|
|
{
|
2013-09-17 05:11:04 +00:00
|
|
|
struct simplefb_platform_data *pd = dev_get_platdata(&pdev->dev);
|
2013-08-02 12:05:20 +00:00
|
|
|
int i;
|
|
|
|
|
|
|
|
params->width = pd->width;
|
|
|
|
params->height = pd->height;
|
|
|
|
params->stride = pd->stride;
|
|
|
|
|
|
|
|
params->format = NULL;
|
|
|
|
for (i = 0; i < ARRAY_SIZE(simplefb_formats); i++) {
|
|
|
|
if (strcmp(pd->format, simplefb_formats[i].name))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
params->format = &simplefb_formats[i];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!params->format) {
|
|
|
|
dev_err(&pdev->dev, "Invalid format value\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-11-14 12:26:48 +00:00
|
|
|
struct simplefb_par {
|
|
|
|
u32 palette[PSEUDO_PALETTE_SIZE];
|
2014-11-14 12:26:50 +00:00
|
|
|
#ifdef CONFIG_OF
|
|
|
|
int clk_count;
|
|
|
|
struct clk **clks;
|
|
|
|
#endif
|
2014-11-14 12:26:48 +00:00
|
|
|
};
|
|
|
|
|
2014-11-14 12:26:50 +00:00
|
|
|
#ifdef CONFIG_OF
|
|
|
|
/*
|
|
|
|
* Clock handling code.
|
|
|
|
*
|
|
|
|
* Here we handle the clocks property of our "simple-framebuffer" dt node.
|
|
|
|
* This is necessary so that we can make sure that any clocks needed by
|
|
|
|
* the display engine that the bootloader set up for us (and for which it
|
|
|
|
* provided a simplefb dt node), stay up, for the life of the simplefb
|
|
|
|
* driver.
|
|
|
|
*
|
|
|
|
* When the driver unloads, we cleanly disable, and then release the clocks.
|
|
|
|
*
|
|
|
|
* We only complain about errors here, no action is taken as the most likely
|
|
|
|
* error can only happen due to a mismatch between the bootloader which set
|
|
|
|
* up simplefb, and the clock definitions in the device tree. Chances are
|
|
|
|
* that there are no adverse effects, and if there are, a clean teardown of
|
|
|
|
* the fb probe will not help us much either. So just complain and carry on,
|
|
|
|
* and hope that the user actually gets a working fb at the end of things.
|
|
|
|
*/
|
|
|
|
static int simplefb_clocks_init(struct simplefb_par *par,
|
|
|
|
struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct device_node *np = pdev->dev.of_node;
|
|
|
|
struct clk *clock;
|
|
|
|
int i, ret;
|
|
|
|
|
|
|
|
if (dev_get_platdata(&pdev->dev) || !np)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
par->clk_count = of_clk_get_parent_count(np);
|
|
|
|
if (par->clk_count <= 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
par->clks = kcalloc(par->clk_count, sizeof(struct clk *), GFP_KERNEL);
|
|
|
|
if (!par->clks)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
for (i = 0; i < par->clk_count; i++) {
|
|
|
|
clock = of_clk_get(np, i);
|
|
|
|
if (IS_ERR(clock)) {
|
|
|
|
if (PTR_ERR(clock) == -EPROBE_DEFER) {
|
|
|
|
while (--i >= 0) {
|
|
|
|
if (par->clks[i])
|
|
|
|
clk_put(par->clks[i]);
|
|
|
|
}
|
|
|
|
kfree(par->clks);
|
|
|
|
return -EPROBE_DEFER;
|
|
|
|
}
|
|
|
|
dev_err(&pdev->dev, "%s: clock %d not found: %ld\n",
|
|
|
|
__func__, i, PTR_ERR(clock));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
par->clks[i] = clock;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < par->clk_count; i++) {
|
|
|
|
if (par->clks[i]) {
|
|
|
|
ret = clk_prepare_enable(par->clks[i]);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(&pdev->dev,
|
|
|
|
"%s: failed to enable clock %d: %d\n",
|
|
|
|
__func__, i, ret);
|
|
|
|
clk_put(par->clks[i]);
|
|
|
|
par->clks[i] = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void simplefb_clocks_destroy(struct simplefb_par *par)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!par->clks)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = 0; i < par->clk_count; i++) {
|
|
|
|
if (par->clks[i]) {
|
|
|
|
clk_disable_unprepare(par->clks[i]);
|
|
|
|
clk_put(par->clks[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
kfree(par->clks);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static int simplefb_clocks_init(struct simplefb_par *par,
|
|
|
|
struct platform_device *pdev) { return 0; }
|
|
|
|
static void simplefb_clocks_destroy(struct simplefb_par *par) { }
|
|
|
|
#endif
|
|
|
|
|
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
|
|
|
static int simplefb_probe(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct simplefb_params params;
|
|
|
|
struct fb_info *info;
|
2014-11-14 12:26:48 +00:00
|
|
|
struct simplefb_par *par;
|
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
|
|
|
struct resource *mem;
|
|
|
|
|
|
|
|
if (fb_get_options("simplefb", NULL))
|
|
|
|
return -ENODEV;
|
|
|
|
|
2013-08-02 12:05:20 +00:00
|
|
|
ret = -ENODEV;
|
2013-09-17 05:11:04 +00:00
|
|
|
if (dev_get_platdata(&pdev->dev))
|
2013-08-02 12:05:20 +00:00
|
|
|
ret = simplefb_parse_pd(pdev, ¶ms);
|
|
|
|
else if (pdev->dev.of_node)
|
|
|
|
ret = simplefb_parse_dt(pdev, ¶ms);
|
|
|
|
|
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
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
|
|
|
|
if (!mem) {
|
|
|
|
dev_err(&pdev->dev, "No memory resource\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2014-11-14 12:26:48 +00:00
|
|
|
info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
|
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
|
|
|
if (!info)
|
|
|
|
return -ENOMEM;
|
|
|
|
platform_set_drvdata(pdev, info);
|
|
|
|
|
2014-11-14 12:26:48 +00:00
|
|
|
par = info->par;
|
|
|
|
|
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
|
|
|
info->fix = simplefb_fix;
|
|
|
|
info->fix.smem_start = mem->start;
|
|
|
|
info->fix.smem_len = resource_size(mem);
|
|
|
|
info->fix.line_length = params.stride;
|
|
|
|
|
|
|
|
info->var = simplefb_var;
|
|
|
|
info->var.xres = params.width;
|
|
|
|
info->var.yres = params.height;
|
|
|
|
info->var.xres_virtual = params.width;
|
|
|
|
info->var.yres_virtual = params.height;
|
|
|
|
info->var.bits_per_pixel = params.format->bits_per_pixel;
|
|
|
|
info->var.red = params.format->red;
|
|
|
|
info->var.green = params.format->green;
|
|
|
|
info->var.blue = params.format->blue;
|
|
|
|
info->var.transp = params.format->transp;
|
|
|
|
|
2013-08-02 12:05:21 +00:00
|
|
|
info->apertures = alloc_apertures(1);
|
|
|
|
if (!info->apertures) {
|
2014-11-14 12:26:49 +00:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto error_fb_release;
|
2013-08-02 12:05:21 +00:00
|
|
|
}
|
|
|
|
info->apertures->ranges[0].base = info->fix.smem_start;
|
|
|
|
info->apertures->ranges[0].size = info->fix.smem_len;
|
|
|
|
|
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
|
|
|
info->fbops = &simplefb_ops;
|
2013-08-02 12:05:21 +00:00
|
|
|
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
|
2013-10-02 14:58:39 +00:00
|
|
|
info->screen_base = ioremap_wc(info->fix.smem_start,
|
|
|
|
info->fix.smem_len);
|
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
|
|
|
if (!info->screen_base) {
|
2014-11-14 12:26:49 +00:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto error_fb_release;
|
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:48 +00:00
|
|
|
info->pseudo_palette = par->palette;
|
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:50 +00:00
|
|
|
ret = simplefb_clocks_init(par, pdev);
|
|
|
|
if (ret < 0)
|
|
|
|
goto error_unmap;
|
|
|
|
|
2013-09-07 14:08:35 +00:00
|
|
|
dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
|
|
|
|
info->fix.smem_start, info->fix.smem_len,
|
|
|
|
info->screen_base);
|
|
|
|
dev_info(&pdev->dev, "format=%s, mode=%dx%dx%d, linelength=%d\n",
|
|
|
|
params.format->name,
|
|
|
|
info->var.xres, info->var.yres,
|
|
|
|
info->var.bits_per_pixel, info->fix.line_length);
|
|
|
|
|
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
|
|
|
ret = register_framebuffer(info);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
|
2014-11-14 12:26:50 +00:00
|
|
|
goto error_clocks;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
|
|
|
|
|
|
|
|
return 0;
|
2014-11-14 12:26:49 +00:00
|
|
|
|
2014-11-14 12:26:50 +00:00
|
|
|
error_clocks:
|
|
|
|
simplefb_clocks_destroy(par);
|
2014-11-14 12:26:49 +00:00
|
|
|
error_unmap:
|
|
|
|
iounmap(info->screen_base);
|
|
|
|
error_fb_release:
|
|
|
|
framebuffer_release(info);
|
|
|
|
return ret;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
static int simplefb_remove(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct fb_info *info = platform_get_drvdata(pdev);
|
2014-11-14 12:26:50 +00:00
|
|
|
struct simplefb_par *par = info->par;
|
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
|
|
|
|
|
|
|
unregister_framebuffer(info);
|
2014-11-14 12:26:50 +00:00
|
|
|
simplefb_clocks_destroy(par);
|
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
|
|
|
framebuffer_release(info);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct of_device_id simplefb_of_match[] = {
|
|
|
|
{ .compatible = "simple-framebuffer", },
|
|
|
|
{ },
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, simplefb_of_match);
|
|
|
|
|
|
|
|
static struct platform_driver simplefb_driver = {
|
|
|
|
.driver = {
|
|
|
|
.name = "simple-framebuffer",
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.of_match_table = simplefb_of_match,
|
|
|
|
},
|
|
|
|
.probe = simplefb_probe,
|
|
|
|
.remove = simplefb_remove,
|
|
|
|
};
|
|
|
|
module_platform_driver(simplefb_driver);
|
|
|
|
|
|
|
|
MODULE_AUTHOR("Stephen Warren <swarren@wwwdotorg.org>");
|
|
|
|
MODULE_DESCRIPTION("Simple framebuffer driver");
|
|
|
|
MODULE_LICENSE("GPL v2");
|