| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Change the phys_mem_access_prot() function to take a pfn instead of an
address. This allows mmap64() to work on /dev/mem for addresses above 4G
on 32-bit architectures. We start with a pfn in mmap_mem(), so there's no
need to convert to an address; in fact, it's actively bad, since the
conversion can overflow when the address is above 4G.
Similarly fix the ppc32 page_is_ram() function to avoid a conversion to an
address by directly comparing to max_pfn. Working with max_pfn instead of
high_memory fixes page_is_ram() to give the right answer for highmem pages.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
|
|
The previous patch adding the ability to nest struct class_device
changed the paramaters to the call class_device_create(). This patch
fixes up all in-kernel users of the function.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
The function bit_putcs() in drivers/video/console/bitblit.c is becoming large.
Break it up into its component functions (bit_putcs_unaligned and
bit_putcs_aligned).
Incorporated fb_pad_aligned_buffer() optimization by Roman Zippel.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The Coordinated Video Timings (CVT) is the latest standard approved by VESA
concerning video timings generation. It addresses the limitation of GTF which
is designed mainly for CRT displays. CRT's have a high blanking requirement
(as much as 25% of the horizontal frame length) which artificially increases
the pixelclock. Digital displays, on the other hand, needs to conserve the
pixelclock as much as possible. The GTF also does not take into account the
different aspect ratios in its calculation.
The new function added is fb_find_mode_cvt(). It is called by fb_find_mode()
if it recognizes a mode option string formatted for CVT. The format is:
<xres>x<yres>[M][R][-<bpp>][<at-sign><refresh>][i][m]
The 'M' tells the function to calculate using CVT. On it's own, it will
compute a timing for CRT displays at 60Hz. If the 'R' is specified, 'reduced
blanking' computation will be used, best for flatpanels. The 'i' and the 'm'
is for 'interlaced mode' and 'with margins' respectively.
To determine if CVT was used, check for dmesg for something like this:
CVT Mode - <pix>M<n>[-R], ie: .480M3-R (800x600 reduced blanking)
where: pix - product of xres and yres, in MB
M - is a CVT mode
n - the aspect ratio (3 - 4:3; 4 - 5:4; 9 - 16:9, 15:9; A - 16:10)
-R - reduced blanking
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Currently, fbcon assumes that the visual FB_VISUAL_MONO* is always 1 bit.
According to Geert, there are old hardware where it's possible to have
monochrome at 8-bit, but has only 2 colors, black - 0x00 and white - 0xff.
Fix color handlers (fb_get_color_depth, and get_color) for this special case.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Add capability to fbdev to listen to the FB_ACTIVATE_ALL flag. If set, it
notifies fbcon that all consoles must be set to the current var.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Reported by: Pavel Kysilka (Bugzilla Bug 5059)
The intelfb driver does not keep resolution set with fbset after
switching to anot console and back.
Steps to reproduce:
initial options: tty1,tty2 - 1024x768-60
1) tty1 - fbset after booting (1024x768-60)
2) tty1 - fbset 800x600-100
tty1: 800x600-100
3) swith to tty2, swith to tty1
tty1: 1024x768-60 (the same resolution as default from kernel booting)
This bug is caused by intelfb unintentionally destroying info->flags in
set_par(). Therefore the flag, FBINFO_MISC_USEREVENT used to notify
fbcon of a mode change was cleared causing the above problem. This bug
though is not intelfb specific, as other drivers may also be affected.
The fix is to save info->flags in a local variable before calling any
of the driver hooks. A more definitive fix (for post 2.6.13) is to
separate info->flags into one that is set by the driver and another that
is set by core fbdev/fbcon.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Do not use memcpy in fb_pad_aligned_buffer. It is suboptimal because only
a few bytes are moved at a time. Replace with a for-loop.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
fbdev is missing unregister_chrdev() on unload.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Several drivers miss filling in the access_align field. So this patch has
them fill it in.
Signed-off-by: James Simmons <jsimmons@www.infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Shrink the stack when calling the drawing alignment functions.
Signed-off-by: James Simmons <jsimmons@www.infradead.org>
Cc: "Antonino A. Daplas" <adaplas@hotpop.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Since no one is using the inbuf, outbuf of struct fb_pixmap I removed their
use in the framebuffer console. The idea is instead move the pixmap
functionality below the accelerated functions intead of on top as the way
it is now. If there is no objection please apply. This is against Linus
latestr GIT tree. Thank you.
Signed-off-by: James Simmons <jsimmons@www.infradead.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
class_simple
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This patch makes some needlessly global identifiers static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Arjan van de Ven <arjanv@infradead.org>
Acked-by: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
I have recompiled Linux kernel 2.6.11.5 documentation for me and our
university students again. The documentation could be extended for more
sources which are equipped by structured comments for recent 2.6 kernels. I
have tried to proceed with that task. I have done that more times from 2.6.0
time and it gets boring to do same changes again and again. Linux kernel
compiles after changes for i386 and ARM targets. I have added references to
some more files into kernel-api book, I have added some section names as well.
So please, check that changes do not break something and that categories are
not too much skewed.
I have changed kernel-doc to accept "fastcall" and "asmlinkage" words reserved
by kernel convention. Most of the other changes are modifications in the
comments to make kernel-doc happy, accept some parameters description and do
not bail out on errors. Changed <pid> to @pid in the description, moved some
#ifdef before comments to correct function to comments bindings, etc.
You can see result of the modified documentation build at
http://cmp.felk.cvut.cz/~pisa/linux/lkdb-2.6.11.tar.gz
Some more sources are ready to be included into kernel-doc generated
documentation. Sources has been added into kernel-api for now. Some more
section names added and probably some more chaos introduced as result of quick
cleanup work.
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Signed-off-by: Martin Waitz <tali@admingilde.org>
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!
|
