kernel.git/drivers/video/intelfb, branch linux-2.6.13.y

[PATCH] intelfb: Do not ioremap entire graphics aperture

2005-08-15T16:53:34Z

Reported by: Pavel Kysilka (Bugzilla Bug 4738) modprobe of intelfb results in the following error message: intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G chi intelfb: Version 0.9.2 ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 allocation failed: out of vmalloc space - use vmalloc= to increase siz intelfb: Cannot remap FB region. This will fail if the graphics aperture size is greater than 128 MB. Fix is to ioremap only from the beginning of graphics aperture to the end of the used framebuffer memory. Signed-off-by: Sylvain Meyer Signed-off-by: Antonino Daplas Signed-off-by: Linus Torvalds

[PATCH] fbdev: fill in the access_align field.

2005-06-22T02:07:42Z

Several drivers miss filling in the access_align field. So this patch has them fill it in. Signed-off-by: James Simmons Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] intelfb: fix accel detection when changing video modes

2005-06-22T02:07:40Z

Changed the tests in intelfb_set_par to check also the parameter var.accel_flags. If null, do nothing about ring buffers. Now, the DirectFB i830 driver could nicely work even if intelfb is hw accelerated. Just change the /etc/fb.modes file to disable console hw acceleration when starting a DirectFB app. Signed-off-by: Sylvain Meyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] intelfb: Add voffset option to avoid conficts with Xorg i810 driver

2005-06-22T02:07:40Z

- Add voffset option to avoid conficts with Xorg i810 driver Signed-off-by: Sylvain Meyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] intelfbdrv naming fix

2005-06-22T02:07:39Z

Can't use this fancy name, because it's used to generate a sysfs filename: kobject_register failed for Intel(R) 830M/845G/852GM/855GM/865G/915G Framebuffer Driver (-13) [] kobject_register+0x43/0x70 [] bus_add_driver+0x52/0xa0 [] pci_device_shutdown+0x0/0x20 [] pci_register_driver+0x61/0x80 [] intelfb_init+0x59/0x70 [] do_initcalls+0x2c/0xc0 [] kern_mount+0x15/0x17 [] init+0x0/0x100 [] init+0x2a/0x100 [] kernel_thread_helper+0x0/0x18 [] kernel_thread_helper+0x5/0x18 Cc: "Antonino A. Daplas" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] intelfb section fix

2005-05-28T23:46:09Z

On Nov 16 2004 a change to intelfbdrv.c was commited (as part of 0.9.2 it looks like) that added __initdata to all of the module param variables that seems to create the opportunity for an oops. I've recently been chasing an OOPS (http://marc.theaimsgroup.com/?l=linux-kernel&m=111552250920370&w=2) I created by reading every file on the /sys file system and I've traced it back to this code in the intelfbdrv. Though I had root privs in my initial problem report, it turns out they are un-necessary to generate the oops - all you've got to do is "cat /sys/module/intelfb/parameters/mode" enough times and eventually it will oops. This is because sysfs automatically exports all module_param declarations to the sysfs file system.. which means those variables can be dynamically evaluated at any later time, which of course means marking them __initdata is a bad idea ;).. when they happen to be char *'s it is an especially bad idea ;). Applying the patch below clears up the OOPS for me. Signed-off-by: Patrick McManus Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] intelfb: Remove intelfbdrv.h

2005-05-01T15:59:23Z

Ingo Oeser noticed that all that intelfbdrv.h contains are prototypes for static functions - and such prototypes don't belong into header files. This patch therefore removes drivers/video/intelfb/intelfbdrv.h and moves the prototypes to intelfbdrv.c . Signed-off-by: Adrian Bunk Signed-off-by: Antonino Daplas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Linux-2.6.12-rc2

2005-04-16T22:20:36Z

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!