20 Dec, 2011
1 commit
-
This API will be used to support YUV frame buffer formats in a standard
way.Last but not least, create a much needed fbdev API documentation and
document the format setting APIs.Signed-off-by: Laurent Pinchart
Signed-off-by: Florian Tobias Schandinat
03 Sep, 2011
1 commit
-
A lock ordering issue can cause deadlocks: in framebuffer/console code,
all needed struct fb_info locks are taken before acquire_console_sem(),
in places which need to take console semaphore.But fb_set_suspend is always called with console semaphore held, and
inside it we call lock_fb_info which gets the fb_info lock, inverse
locking order of what the rest of the code does. This causes a real
deadlock issue, when we write to state fb sysfs attribute (which calls
fb_set_suspend) while a framebuffer is being unregistered by
remove_conflicting_framebuffers, as can be shown by following show
blocked state trace on a test program which loads i915 and runs another
forked processes writing to state attribute:Test process with semaphore held and trying to get fb_info lock:
..
fb-test2 D 0000000000000000 0 237 228 0x00000000
ffff8800774f3d68 0000000000000082 00000000000135c0 00000000000135c0
ffff880000000000 ffff8800774f3fd8 ffff8800774f3fd8 ffff880076ee4530
00000000000135c0 ffff8800774f3fd8 ffff8800774f2000 00000000000135c0
Call Trace:
[] __mutex_lock_slowpath+0x11a/0x1e0
[] ? _raw_spin_lock_irq+0x22/0x40
[] mutex_lock+0x23/0x50
[] lock_fb_info+0x25/0x60
[] fb_set_suspend+0x20/0x80
[] store_fbstate+0x4f/0x70
[] dev_attr_store+0x20/0x30
[] sysfs_write_file+0xd4/0x160
[] vfs_write+0xc6/0x190
[] sys_write+0x51/0x90
[] system_call_fastpath+0x16/0x1b
..
modprobe process stalled because has the fb_info lock (got inside
unregister_framebuffer) but waiting for the semaphore held by the
test process which is waiting to get the fb_info lock:
..
modprobe D 0000000000000000 0 230 218 0x00000000
ffff880077a4d618 0000000000000082 0000000000000001 0000000000000001
ffff880000000000 ffff880077a4dfd8 ffff880077a4dfd8 ffff8800775a2e20
00000000000135c0 ffff880077a4dfd8 ffff880077a4c000 00000000000135c0
Call Trace:
[] schedule_timeout+0x215/0x310
[] ? get_parent_ip+0x11/0x50
[] __down+0x6d/0xb0
[] down+0x41/0x50
[] acquire_console_sem+0x2c/0x50
[] unbind_con_driver+0xad/0x2d0
[] fbcon_event_notify+0x457/0x890
[] ? _raw_spin_unlock_irqrestore+0x1f/0x50
[] ? get_parent_ip+0x11/0x50
[] notifier_call_chain+0x4d/0x70
[] __blocking_notifier_call_chain+0x58/0x80
[] blocking_notifier_call_chain+0x16/0x20
[] fb_notifier_call_chain+0x1b/0x20
[] unregister_framebuffer+0x7c/0x130
[] remove_conflicting_framebuffers+0x153/0x180
[] register_framebuffer+0x93/0x2c0
[] drm_fb_helper_single_fb_probe+0x252/0x2f0 [drm_kms_helper]
[] drm_fb_helper_initial_config+0x2f3/0x6d0 [drm_kms_helper]
[] ? drm_fb_helper_single_add_all_connectors+0x5d/0x1c0 [drm_kms_helper]
[] intel_fbdev_init+0xa8/0x160 [i915]
[] i915_driver_load+0x854/0x12b0 [i915]
[] drm_get_pci_dev+0x19e/0x360 [drm]
[] ? sub_preempt_count+0x9d/0xd0
[] i915_pci_probe+0x15/0x17 [i915]
[] local_pci_probe+0x5f/0xd0
[] pci_device_probe+0x119/0x120
[] ? driver_sysfs_add+0x7a/0xb0
[] driver_probe_device+0xa3/0x290
[] ? __driver_attach+0x0/0xb0
[] __driver_attach+0xab/0xb0
[] ? __driver_attach+0x0/0xb0
[] bus_for_each_dev+0x5e/0x90
[] driver_attach+0x1e/0x20
[] bus_add_driver+0xe2/0x320
[] ? i915_init+0x0/0x96 [i915]
[] driver_register+0x76/0x140
[] ? i915_init+0x0/0x96 [i915]
[] __pci_register_driver+0x56/0xd0
[] drm_pci_init+0xe4/0xf0 [drm]
[] ? i915_init+0x0/0x96 [i915]
[] drm_init+0x58/0x70 [drm]
[] i915_init+0x94/0x96 [i915]
[] do_one_initcall+0x44/0x190
[] sys_init_module+0xcb/0x210
[] system_call_fastpath+0x16/0x1b
..fb-test2 which reproduces above is available on kernel.org bug #26232.
To solve this issue, avoid calling lock_fb_info inside fb_set_suspend,
and move it out to where needed (callers of fb_set_suspend must call
lock_fb_info before if needed). So far, the only place which needs to
call lock_fb_info is store_fbstate, all other places which calls
fb_set_suspend are suspend/resume hooks that should not need the lock as
they should be run only when processes are already frozen in
suspend/resume.References: https://bugzilla.kernel.org/show_bug.cgi?id=26232
Signed-off-by: Herton Ronaldo Krzesinski
Signed-off-by: Florian Tobias Schandinat
Cc: stable@kernel.org
15 May, 2011
2 commits
-
This moves the
if (num_registered_fb == FB_MAX)
return -ENXIO;check _AFTER_ the call to do_remove_conflicting_framebuffers() as this
would (now in a safe way) allow a native driver to replace the
conflicting one even if all slots in registered_fb[] are taken.This also prevents unregistering a framebuffer that is no longer
registered (vga16f will unregister at module unload time even if the
frame buffer had been unregistered earlier due to being found
conflicting).Signed-off-by: Bruno Prémont
Signed-off-by: Linus Torvalds -
When a register_framebuffer() call results in us removing old
conflicting framebuffers, the new registration_lock doesn't protect that
situation. And we can't just add the same locking to the function,
because these functions call each other: register_framebuffer() calls
remove_conflicting_framebuffers, which in turn calls
unregister_framebuffer for any conflicting entry.In order to fix it, this just creates wrapper functions around all three
functions and makes the versions that actually do the work be called
"do_xxx()", leaving just the wrapper that gets the lock and calls the
worker function.So the rule becomes simply that "do_xxxx()" has to be called with the
lock held, and now do_register_framebuffer() can just call
do_remove_conflicting_framebuffers(), and that in turn can call
_do_unregister_framebuffer(), and there is no deadlock, and we can hold
the registration lock over the whole sequence, fixing the races.It also makes error cases simpler, and fixes one situation where we
would return from unregister_framebuffer() without releasing the lock,
pointed out by Bruno Prémont.Tested-by: Bruno Prémont
Tested-by: Anca Emanuel
Signed-off-by: Linus Torvalds
12 May, 2011
2 commits
-
read/write/ioctl on a fbcon file descriptor has traditionally used the
fbcon not when it was opened, but as it was at the time of the call.
That makes no sense, but the lack of sense is much more obvious now that
we properly ref-count the usage - it means that the ref-counting doesn't
actually protect operations we do on the frame buffer.This changes it to look at the fb_info that we got at open time, but in
order to avoid using a frame buffer long after it has been unregistered,
we do verify that it is still current, and return -ENODEV if not.Acked-by: Tim Gardner
Tested-by: Daniel J Blueman
Tested-by: Anca Emanuel
Cc: Bruno Prémont
Cc: Alan Cox
Cc: Paul Mundt
Cc: Dave Airlie
Cc: Andy Whitcroft
Signed-off-by: Linus Torvalds -
This just adds the refcount and the new registration lock logic. It
does not (for example) actually change the read/write/ioctl routines to
actually use the frame buffer that was opened: those function still end
up alway susing whatever the current frame buffer is at the time of the
call.Without this, if something holds the frame buffer open over a
framebuffer switch, the close() operation after the switch will access a
fb_info that has been free'd by the unregistering of the old frame
buffer.(The read/write/ioctl operations will normally not cause problems,
because they will - illogically - pick up the new fbcon instead. But a
switch that happens just as one of those is going on might see problems
too, the window is just much smaller: one individual op rather than the
whole open-close sequence.)This use-after-free is apparently fairly easily triggered by the Ubuntu
11.04 boot sequence.Acked-by: Tim Gardner
Tested-by: Daniel J Blueman
Tested-by: Anca Emanuel
Cc: Bruno Prémont
Cc: Alan Cox
Cc: Paul Mundt
Cc: Dave Airlie
Cc: Andy Whitcroft
Signed-off-by: Linus Torvalds
07 Apr, 2011
1 commit
-
It's expected that efifb will conflict with a native driver, so the
handover message should be informational rather than an error.Signed-off-by: Matthew Garrett
Acked-by: Dave Airlie
Signed-off-by: Paul Mundt
26 Jan, 2011
1 commit
-
The -rt patches change the console_semaphore to console_mutex. As a
result, a quite large chunk of the patches changes all
acquire/release_console_sem() to acquire/release_console_mutex()This commit makes things use more neutral function names which dont make
implications about the underlying lock.The only real change is the return value of console_trylock which is
inverted from try_acquire_console_sem()This patch also paves the way to switching console_sem from a semaphore to
a mutex.[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert]
Signed-off-by: Torben Hohn
Cc: Thomas Gleixner
Cc: Greg KH
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
24 Dec, 2010
1 commit
-
On my system with a radeon x2, the first GPU was not overlapping vesa
but the test decided it was.Signed-off-by: Dave Airlie
Reviewed-by: Michel Dänzer
Signed-off-by: Paul Mundt
28 Oct, 2010
2 commits
-
fb_{read,write} access the framebuffer using lots of fb_{read,write}l's
but don't check that the file position is aligned which can cause problems
on some architectures which do not support unaligned accesses.Since the operations are essentially memcpy_{from,to}io, new
fb_memcpy_{from,to}fb macros have been defined and these are used instead.For Sparc, fb_{read,write} macros use sbus_{read,write}, so this defines
new sbus_memcpy_{from,to}io functions the same as memcpy_{from,to}io but
using sbus_{read,write}b instead of {read,write}b.Signed-off-by: James Hogan
Acked-by: David S. Miller
Acked-by: Florian Tobias Schandinat
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Change a few lines of indentation to tabs.
Signed-off-by: James Hogan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Oct, 2010
1 commit
-
All file_operations should get a .llseek operation so we can make
nonseekable_open the default for future file operations without a
.llseek pointer.The three cases that we can automatically detect are no_llseek, seq_lseek
and default_llseek. For cases where we can we can automatically prove that
the file offset is always ignored, we use noop_llseek, which maintains
the current behavior of not returning an error from a seek.New drivers should normally not use noop_llseek but instead use no_llseek
and call nonseekable_open at open time. Existing drivers can be converted
to do the same when the maintainer knows for certain that no user code
relies on calling seek on the device file.The generated code is often incorrectly indented and right now contains
comments that clarify for each added line why a specific variant was
chosen. In the version that gets submitted upstream, the comments will
be gone and I will manually fix the indentation, because there does not
seem to be a way to do that using coccinelle.Some amount of new code is currently sitting in linux-next that should get
the same modifications, which I will do at the end of the merge window.Many thanks to Julia Lawall for helping me learn to write a semantic
patch that does all this.===== begin semantic patch =====
// This adds an llseek= method to all file operations,
// as a preparation for making no_llseek the default.
//
// The rules are
// - use no_llseek explicitly if we do nonseekable_open
// - use seq_lseek for sequential files
// - use default_llseek if we know we access f_pos
// - use noop_llseek if we know we don't access f_pos,
// but we still want to allow users to call lseek
//
@ open1 exists @
identifier nested_open;
@@
nested_open(...)
{}
@ open exists@
identifier open_f;
identifier i, f;
identifier open1.nested_open;
@@
int open_f(struct inode *i, struct file *f)
{}
@ read disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{}
@ read_no_fpos disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{
... when != off
}@ write @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{}
@ write_no_fpos @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{
... when != off
}@ fops0 @
identifier fops;
@@
struct file_operations fops = {
...
};@ has_llseek depends on fops0 @
identifier fops0.fops;
identifier llseek_f;
@@
struct file_operations fops = {
...
.llseek = llseek_f,
...
};@ has_read depends on fops0 @
identifier fops0.fops;
identifier read_f;
@@
struct file_operations fops = {
...
.read = read_f,
...
};@ has_write depends on fops0 @
identifier fops0.fops;
identifier write_f;
@@
struct file_operations fops = {
...
.write = write_f,
...
};@ has_open depends on fops0 @
identifier fops0.fops;
identifier open_f;
@@
struct file_operations fops = {
...
.open = open_f,
...
};// use no_llseek if we call nonseekable_open
////////////////////////////////////////////
@ nonseekable1 depends on !has_llseek && has_open @
identifier fops0.fops;
identifier nso ~= "nonseekable_open";
@@
struct file_operations fops = {
... .open = nso, ...
+.llseek = no_llseek, /* nonseekable */
};@ nonseekable2 depends on !has_llseek @
identifier fops0.fops;
identifier open.open_f;
@@
struct file_operations fops = {
... .open = open_f, ...
+.llseek = no_llseek, /* open uses nonseekable */
};// use seq_lseek for sequential files
/////////////////////////////////////
@ seq depends on !has_llseek @
identifier fops0.fops;
identifier sr ~= "seq_read";
@@
struct file_operations fops = {
... .read = sr, ...
+.llseek = seq_lseek, /* we have seq_read */
};// use default_llseek if there is a readdir
///////////////////////////////////////////
@ fops1 depends on !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier readdir_e;
@@
// any other fop is used that changes pos
struct file_operations fops = {
... .readdir = readdir_e, ...
+.llseek = default_llseek, /* readdir is present */
};// use default_llseek if at least one of read/write touches f_pos
/////////////////////////////////////////////////////////////////
@ fops2 depends on !fops1 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read.read_f;
@@
// read fops use offset
struct file_operations fops = {
... .read = read_f, ...
+.llseek = default_llseek, /* read accesses f_pos */
};@ fops3 depends on !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write.write_f;
@@
// write fops use offset
struct file_operations fops = {
... .write = write_f, ...
+ .llseek = default_llseek, /* write accesses f_pos */
};// Use noop_llseek if neither read nor write accesses f_pos
///////////////////////////////////////////////////////////@ fops4 depends on !fops1 && !fops2 && !fops3 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
identifier write_no_fpos.write_f;
@@
// write fops use offset
struct file_operations fops = {
...
.write = write_f,
.read = read_f,
...
+.llseek = noop_llseek, /* read and write both use no f_pos */
};@ depends on has_write && !has_read && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write_no_fpos.write_f;
@@
struct file_operations fops = {
... .write = write_f, ...
+.llseek = noop_llseek, /* write uses no f_pos */
};@ depends on has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
@@
struct file_operations fops = {
... .read = read_f, ...
+.llseek = noop_llseek, /* read uses no f_pos */
};@ depends on !has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
@@
struct file_operations fops = {
...
+.llseek = noop_llseek, /* no read or write fn */
};
===== End semantic patch =====Signed-off-by: Arnd Bergmann
Cc: Julia Lawall
Cc: Christoph Hellwig
11 Aug, 2010
2 commits
-
When we setup up the VMA flags for the mmap flag and we end up using the
fallback mmap functionality we set the vma->vm_flags |= VM_IO. However we
neglect to propagate the flag to the vma->vm_page_prot.This bug was found when Linux kernel was running under Xen. In that
scenario, any page that has VM_IO flag to it, means that it MUST be a
MMIO/VRAM backend memory , _not_ System RAM. That is what the fbmem.c
does: sets VM_IO, ioremaps the region - everything is peachy.Well, not exactly. The vm_page_prot does not get the relevant PTE flags
set (_PAGE_IOMAP) which under Xen is a death-kneel to pages that are
referencing real physical devices but don't have that flag set.This patch fixes this.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Daniel De Graaf
Tested-by: Eamon Walsh
Cc: Florian Tobias Schandinat
Cc: Dave Airlie
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Replaced !strlen(str) check with !str[0]. Removed the variable which was
used solely to store strlen result.Signed-off-by: Denys Vlasenko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 May, 2010
1 commit
-
Fix printk formats:
drivers/video/fbmem.c: In function 'fb_do_apertures_overlap':
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t'
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'resource_size_t'Signed-off-by: Randy Dunlap
Signed-off-by: Linus Torvalds
18 May, 2010
3 commits
-
let vga16fb claim 0xA0000+0x10000 region as its aperture;
drm drivers don't use it, so we have to detect it and kick
vga16fb manually - but only if drm is driving the primary cardSigned-off-by: Marcin Slusarz
Cc: James Simmons
Cc: Dave Airlie
Cc: Ben Skeggs
Signed-off-by: Dave Airlie -
Currently vesafb/efifb/... is kicked when hardware driver is registering
framebuffer. To do it hardware must be fully functional, so there's a short
window between start of initialisation and framebuffer registration when
two drivers touch the hardware. Unfortunately sometimes it breaks nouveau
initialisation.Fix it by kicking firmware driver(s) before we start touching the hardware.
Reported-by: Didier Spaier
Tested-by: Didier Spaier
Signed-off-by: Marcin Slusarz
Cc: Ben Skeggs
Cc: Peter Jones
Cc: Andrew Morton
Signed-off-by: Dave Airlie -
It removes a hack from nouveau code which had to detect which
region to pass to kick vesafb/efifb.Signed-off-by: Marcin Slusarz
Cc: Eric Anholt
Cc: Ben Skeggs
Cc: Thomas Hellstrom
Cc: Dave Airlie
Cc: Peter Jones
Cc: Benjamin Herrenschmidt
Signed-off-by: Dave Airlie
25 Feb, 2010
1 commit
-
An offb machine has been seen in the fields which adds two
offb nodes, so continue scanning the list after removing one.Signed-off-by: Dave Airlie
30 Sep, 2009
1 commit
-
* 'drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (25 commits)
drm/radeon/kms: Convert R520 to new init path and associated cleanup
drm/radeon/kms: Convert RV515 to new init path and associated cleanup
drm: fix radeon DRM warnings when !CONFIG_DEBUG_FS
drm: fix drm_fb_helper warning when !CONFIG_MAGIC_SYSRQ
drm/r600: fix memory leak introduced with 64k malloc avoidance fix.
drm/kms: make fb helper work for all drivers.
drm/radeon/r600: fix offset handling in CS parser
drm/radeon/kms/r600: fix forcing pci mode on agp cards
drm/radeon/kms: fix for the extra pages copying.
drm/radeon/kms/r600: add support for vline relocs
drm/radeon/kms: fix some bugs in vline reloc
drm/radeon/kms/r600: clamp vram to aperture size
drm/kms: protect against fb helper not being created.
drm/r600: get values from the passed in IB not the copy.
drm: create gitignore file for radeon
drm/radeon/kms: remove unneeded master create/destroy functions.
drm/kms: start adding command line interface using fb.
fb: change rules for global rules match.
drm/radeon/kms: don't require up to 64k allocations. (v2)
drm/radeon/kms: enable dac load detection by default.
...Trivial conflicts in drivers/gpu/drm/radeon/radeon_asic.h due to adding
'->vga_set_state' function pointers.
25 Sep, 2009
1 commit
-
Having a : should be enough 'fb:' isn't really useful
if the fb wants to a kms output ID.Signed-off-by: Dave Airlie
23 Sep, 2009
2 commits
-
At the moment about half of the framebuffer drivers can return an error
code in fb_set_par. Until now it would be silently ignored by fbmem.c
and fbcon.c. This patch fixes fbmem.c to return the error code and
restore var on error.But it is not clear in which video mode the device is when fb_set_par
fails. It would be good and reasonable if it were in the old state but
there is no guarantee that this is true for all existing drivers.
Additionally print a message if a failing fb_set_par is detected in
fbmem.c or fbcon.c.Although most errors should be caught by the previous fb_check_var some
errors can't as they are dynamic (memory allocations, ...) and can only be
detected while performing the operations which is forbidden in
fb_check_var.This patch shouldn't have a negative impact on normal operation as all
drivers return 0 on success. The impact in case of error depends heavily
on the driver and caller but it's expected to be better than before.Signed-off-by: Florian Tobias Schandinat
Cc: Krzysztof Helt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix the range check for panning. The current code fails to detect some
invalid values (very high ones that can occur if an app tries to move
further up/left than 0,0) as the check uses the unknown values for
calculation so that an overflow can occur.To fix this it is sufficient to move the calculation to the right side to
use only trusted values.Kai Jiang detected this problem and proposed an initial patch.
Signed-off-by: Florian Tobias Schandinat
Cc: Kai Jiang
Cc: Krzysztof Helt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Jul, 2009
1 commit
-
* Remove smp_lock.h from files which don't need it (including some headers!)
* Add smp_lock.h to files which do need it
* Make smp_lock.h include conditional in hardirq.h
It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPTThis will make hardirq.h inclusion cheaper for every PREEMPT=n config
(which includes allmodconfig/allyesconfig, BTW)Signed-off-by: Alexey Dobriyan
Signed-off-by: Linus Torvalds
09 Jul, 2009
1 commit
-
This reverts commit 4148df9b0f38bdd362dd91d52076926c11cbe5a9.
Let's hope that the mm_lock initialization is now correct with all
drivers, following Krzysztof's patches.Requested-by: Krzysztof Helt
Signed-off-by: Linus Torvalds
07 Jul, 2009
1 commit
-
This way they'll be properly initialized early enough for users that may
touch them before the framebuffer has been registered.Drivers that allocate their fb_info structure some other way (like
matrocfb's broken static allocation) need to be fixed up appropriately.Signed-off-by: Paul Mundt
Signed-off-by: Linus Torvalds
01 Jul, 2009
1 commit
-
Add a mutex to avoid a circular locking problem between the mm layer
semaphore and fbdev ioctl mutex through the fb_mmap() call.Also, add mutex to all places where smem_start and smem_len fields change
so the mutex inside the fb_mmap() is actually used. Changing of these
fields before calling the framebuffer_register() are not mutexed.This is 2.6.31 material. It removes one lockdep (fb_mmap() and
register_framebuffer()) but there is still another one (fb_release() and
register_framebuffer()). It also cleans up handling of the smem_start and
smem_len fields used by mutexed section of the fb_mmap().Signed-off-by: Krzysztof Helt
Cc: Peter Zijlstra
Cc: "Rafael J. Wysocki"
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Jun, 2009
1 commit
-
With KMS we have ran into an issue where we really want the KMS fb driver
to be the one running the console, so panics etc can be shown by switching
out of X etc.However with vesafb/efifb built-in, we end up with those on fb0 and the
KMS fb driver on fb1, driving the same piece of hw, so this adds an fb
info flag to denote a firmware fbdev, and adds a new aperture base/size
range which can be compared when the hw drivers are installed to see if
there is a conflict with a firmware driver, and if there is the firmware
driver is unregistered and the hw driver takes over.It uses new aperture_base/size members instead of comparing on the fix
smem_start/length, as smem_start/length might for example only cover the
first 1MB of the PCI aperture, and we could allocate the kms fb from 8MB
into the aperture, thus they would never overlap.[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Dave Airlie
Acked-by: Peter Jones
Cc: Geert Uytterhoeven
Cc: Krzysztof Helt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Apr, 2009
1 commit
-
fb_notifier_call_chain() is called with info->lock held, i.e. in
do_fb_ioctl() => FBIOPUT_VSCREENINFO => fb_set_var() and the some
notifier callbacks, like fbcon_event_notify(), try to re-acquire
info->lock again.Remove the lock/unlock_fb_info() in all the framebuffer notifier
callbacks' and be sure to always call fb_notifier_call_chain() with
info->lock held.Reported-by: Pavel Roskin
Reported-by: Eric Miao
Signed-off-by: Andrea Righi
Cc: Stefan Richter
Cc: Krzysztof Helt
Cc: Geert Uytterhoeven
Cc: "Rafael J. Wysocki"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 Apr, 2009
2 commits
-
Before:
text data bss dec hex filename
3648 2910 32 6590 19be drivers/video/backlight/backlight.o
3226 2812 32 6070 17b6 drivers/video/backlight/lcd.o
30990 16688 8480 56158 db5e drivers/video/console/fbcon.o
15488 8400 24 23912 5d68 drivers/video/fbmem.oAfter:
text data bss dec hex filename
3537 2870 32 6439 1927 drivers/video/backlight/backlight.o
3131 2772 32 5935 172f drivers/video/backlight/lcd.o
30876 16648 8480 56004 dac4 drivers/video/console/fbcon.o
15506 8400 24 23930 5d7a drivers/video/fbmem.oCc: Andrea Righi
Cc: Geert Uytterhoeven
Cc: Krzysztof Helt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix a circular locking dependency in the frame buffer console driver
pushing down the mutex fb_info->lock.Circular locking dependecies occur calling the blocking
fb_notifier_call_chain() with fb_info->lock held. Notifier callbacks can
try to acquire mm->mmap_sem, while fb_mmap() acquires the locks in the
reverse order mm->mmap_sem => fb_info->lock.Tested-by: Andrey Borzenkov
Signed-off-by: Andrea Righi
Cc: Geert Uytterhoeven
Cc: Krzysztof Helt
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
06 Feb, 2009
1 commit
-
Avoid calling copy_from/to_user() with fb_info->lock mutex held in fbmem
ioctl().fb_mmap() is called under mm->mmap_sem (A) held, that also acquires
fb_info->lock (B); fb_ioctl() takes fb_info->lock (B) and does
copy_from/to_user() that might acquire mm->mmap_sem (A), causing a
deadlock.NOTE: it doesn't push down the fb_info->lock in each own driver's
fb_ioctl(), so there are still potential deadlocks elsewhere.Signed-off-by: Andrea Righi
Cc: Dave Jones
Cc: "Rafael J. Wysocki"
Cc: Johannes Weiner
Cc: Krzysztof Helt
Cc: Harvey Harrison
Cc: Stefan Richter
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Jan, 2009
1 commit
-
The code to draw penguin logos always uses some properties of the main logo.
This is incorrect if additional logos (CONFIG_FB_LOGO_EXTRA=y) have different
types than the main logo, which causes corrupted logo images.http://bugzilla.kernel.org/show_bug.cgi?id=12181
Hence skip additional logos that are not compatible with the main logo.
Technically, it's possible to draw multiple logos of different types on
truecolor displays, but this would complicate the (already quite
complicated) logo drawing code even more.This patch fixes a problem with Debian's linux-image-2.6.26-1-powerpc64
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508173Signed-off-by: Geert Uytterhoeven
Cc: Krzysztof Helt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
20 Nov, 2008
1 commit
-
When booting in a direct color mode, the penguin has dirty feet, i.e.,
some pixels have the wrong color. This is caused by
fb_set_logo_directpalette() which does not initialize the last 32 palette
entries.Signed-off-by: Clemens Ladisch
Acked-by: Geert Uytterhoeven
Cc: Krzysztof Helt
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Nov, 2008
1 commit
-
commit 3e680aae4e53ab54cdbb0c29257dae0cbb158e1c ("fb: convert
lock/unlock_kernel() into local fb mutex") introduced several deadlocks
in the fb_compat_ioctl() path, as mutex_lock() doesn't allow recursion,
unlike lock_kernel(). This broke frame buffer applications on 64-bit
systems with a 32-bit userland.commit 120a37470c2831fea49fdebaceb5a7039f700ce6 ("framebuffer compat_ioctl
deadlock") fixed one of the deadlocks.This patch fixes the remaining deadlocks:
- Revert commit 120a37470c2831fea49fdebaceb5a7039f700ce6,
- Extract the core logic of fb_ioctl() into a new function do_fb_ioctl(),
- Change all callsites of fb_ioctl() where info->lock is already held to
call do_fb_ioctl() instead,
- Add sparse annotations to all routines that take info->lock.Signed-off-by: Geert Uytterhoeven
Cc: Mikulas Patocka
Cc: Krzysztof Helt
Cc: Alan Cox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
31 Oct, 2008
1 commit
-
Fix deadlock in fb_compat_ioctl. fb_compat_ioctl acquires a mutex and
calls fb_ioctl that tries to acquire that mutex too. A regression added
during BKL removal.Signed-off-by: Mikulas Patocka
Cc: Alan Cox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
20 Oct, 2008
2 commits
-
Change lock_kernel()/unlock_kernel() to local fb mutex. Each frame buffer
instance has its own mutex.The one line try_to_load() function is unrolled to request_module() in two
places for readability.[righi.andrea@gmail.com: fb: fix NULL pointer BUG dereference in fb_open()]
Signed-off-by: Krzysztof Helt
Signed-off-by: Andrea Righi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Framebuffer is heavily BKL dependant at the moment so just wrap the ioctl
handler in the driver as we push down.[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Alan Cox
Cc: Krzysztof Helt
Cc: "Antonino A. Daplas"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Oct, 2008
2 commits
-
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6: (46 commits)
UIO: Fix mapping of logical and virtual memory
UIO: add automata sercos3 pci card support
UIO: Change driver name of uio_pdrv
UIO: Add alignment warnings for uio-mem
Driver core: add bus_sort_breadthfirst() function
NET: convert the phy_device file to use bus_find_device_by_name
kobject: Cleanup kobject_rename and !CONFIG_SYSFS
kobject: Fix kobject_rename and !CONFIG_SYSFS
sysfs: Make dir and name args to sysfs_notify() const
platform: add new device registration helper
sysfs: use ilookup5() instead of ilookup5_nowait()
PNP: create device attributes via default device attributes
Driver core: make bus_find_device_by_name() more robust
usb: turn dev_warn+WARN_ON combos into dev_WARN
debug: use dev_WARN() rather than WARN_ON() in device_pm_add()
debug: Introduce a dev_WARN() function
sysfs: fix deadlock
device model: Do a quickcheck for driver binding before doing an expensive check
Driver core: Fix cleanup in device_create_vargs().
Driver core: Clarify device cleanup.
... -
Now that device_create() has been audited, rename things back to the
original call to be sane.Signed-off-by: Greg Kroah-Hartman
