| Age | Commit message (Collapse) | Author |
|---|
|
The s1d13xxx chip provides two values of identification value: the
Production id (e.g 13506/13505/13806..) and a revision number 0,1,2,3).
Together these can help us to differentiate between similiar setups.
This patch adds the proper way of grabbing both those values and save them
for future reference (in order to decide what functions a card supports,
e.g acceleration).
We also move away from the concept of all s1d13xxx = s1d13806 when we
really support alot more.
[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: simplify s1d13xxxfb_probe()]
Signed-off-by: Kristoffer Ericson <kristoffer.ericson@gmail.com
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The Epson s1d13xxx hardware is common in many handhelds, but our driver is
currently locked to a single chip revision. This patch adds an array of
known to work revisions (which can be extended).
[akpm@linux-foundation.org: cleanups]
Signed-off-by: Kristoffer Ericson <Kristoffer.Ericson@gmail.com>
Acked-by: Thibaut Varène <varenet@parisc-linux.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Attached patch fixes two compilation problems of s1d13xxxfb.c:
- Fixes outdated dbg() message to fix compilation error with debugging enabled.
- Do not read kernel command line options when compiled as module.
Signed-off-by: Stanislav Brabec <utx@penguin.cz>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
|
struct info may not be released in the driver's error path.
Coverity Bug 672
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This allows us to eliminate the casts in the drivers, and eventually
remove the use of the device_driver function pointer methods for
platform device drivers.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
drivers that do not support hardware cursors is redundant. The soft_cursor
function is usable by all drivers because it is just a wrapper around
fb_imageblit. And because soft_cursor is an fbcon-specific hook, the file is
moved to the console directory.
Thus, drivers that do not support hardware cursors can leave the fb_cursor
field blank. For drivers that do, they can fill up this field with their own
version.
The end result is a smaller code size. And if the framebuffer console is not
loaded, module/kernel size is also reduced because the soft_cursor module will
also not be loaded.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Convert everyone who uses platform_bus_type to include
linux/platform_device.h.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
In PM v1, all devices were called at SUSPEND_DISABLE level. Then
all devices were called at SUSPEND_SAVE_STATE level, and finally
SUSPEND_POWER_DOWN level. However, with PM v2, to maintain
compatibility for platform devices, I arranged for the PM v2
suspend/resume callbacks to call the old PM v1 suspend/resume
callbacks three times with each level in order so that existing
drivers continued to work.
Since this is obsolete infrastructure which is no longer necessary,
we can remove it. Here's an (untested) patch to do exactly that.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Fix remaining bits of u32 vs. pm_message confusion. Should not break
anything.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch is for supporting Epson s1d13xxx framebuffer device for m32r. #
Sorry, a little bigger.
The Epson s1d13806 is already supported by 2.6.12 kernel, and its driver is
placed as drivers/video/s1d13xxxfb.c.
For the m32r, a header file include/asm-m32r/s1d13806.h was prepared for
several m32r target platforms. It was originally generated by an Epson
tool S1D13806CFG.EXE, and modified manually for the m32r platforms.
Signed-off-by: Hayato Fujiwara <fujiwara@linux-m32r.org>
Signed-off-by: Hirokazu Takata <takata@linux-m32r.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
s1d13xxxfb_remove() is referenced from s1d13xxxfb_probe(), which is marked
__devinit(). So s1d13xxxfb_remove() cannot be marked __devexit.
Does this all make sense? Clearly the __devexit section will still be in
core when the __devinit code is run, if the driver was loaded as a module.
But I suppose that if the driver is statically linked, the __devexit section
might be dropped early in boot. Still, we wouldn't drop __devexit prior to
initcall completion, at which point the __devinit code has all been run
anyway.
verdict: this code was legal and made sense. Is this a generic problem, or an
arm-specific problem?
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
`.exit.text' referenced in section `.init.text' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
