kernel.git/drivers/video/fbmem.c, branch linux-2.6.36.y

fbmem: VM_IO set, but not propagated

2010-08-11T15:59:12Z

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

drivers/video/fbmem.c: simplify strlen()==0 check in fb_get_options()

2010-08-11T15:59:09Z

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

fbmem: avoid printk format warning with 32-bit resources

2010-05-22T03:30:33Z

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

vga16fb, drm: vga16fb->drm handoff

2010-05-18T06:19:30Z

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 card Signed-off-by: Marcin Slusarz Cc: James Simmons Cc: Dave Airlie Cc: Ben Skeggs Signed-off-by: Dave Airlie

fbmem, drm/nouveau: kick firmware framebuffers as soon as possible

2010-05-18T06:19:28Z

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

fbdev: allow passing more than one aperture for handoff

2010-05-18T06:19:27Z

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

fb: for framebuffer handover don't exit the loop early.

2010-02-25T04:15:12Z

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

Merge branch 'drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6

2009-09-30T15:03:00Z

* '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.

fb: change rules for global rules match.

2009-09-25T03:08:19Z

Having a : should be enough 'fb:' isn't really useful if the fb wants to a kms output ID. Signed-off-by: Dave Airlie

fb: do not ignore fb_set_par errors

2009-09-23T14:39:56Z

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