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

viafb: use proper register for colour when doing fill ops

2010-12-09T21:32:38Z

commit efd4f6398dc92b5bf392670df862f42a19f34cf2 upstream. The colour was written to a wrong register for fillrect operations. This sometimes caused empty console space (for example after 'clear') to have a different colour than desired. Fix this by writing to the correct register. Many thanks to Daniel Drake and Jon Nettleton for pointing out this issue and pointing me in the right direction for the fix. Fixes http://dev.laptop.org/ticket/9323 Signed-off-by: Florian Tobias Schandinat Cc: Joseph Chan Cc: Daniel Drake Cc: Jon Nettleton Signed-off-by: Greg Kroah-Hartman

viafb: fix i2c_transfer error handling

2010-12-09T21:32:15Z

commit 85c5702ac046b14713f776d59768252d8ed8018f upstream. i2c_transfer returns negative errno on error and number of messages processed on success. Just returning this value would give a poor interface as it is not obvious that you must compare with 2 after reading 1 or n bytes and with 1 after writing 1 byte to determine if it was successful. To avoid this error prone interface convert the error code of a successful read/write to zero and all other non-negative values to an negative error code. This fixes a regression introduced by via: Rationalize vt1636 detection which resulted in no longer detecting a VT1636 chip and therefore has broken the output in configurations which contain this chip. Signed-off-by: Florian Tobias Schandinat Acked-by: Jonathan Corbet Cc: Joseph Chan Signed-off-by: Greg Kroah-Hartman

drivers/video/via/ioctl.c: prevent reading uninitialized stack memory

2010-09-15T23:43:53Z

The VIAFB_GET_INFO device ioctl allows unprivileged users to read 246 bytes of uninitialized stack memory, because the "reserved" member of the viafb_ioctl_info struct declared on the stack is not altered or zeroed before being copied back to the user. This patch takes care of it. Signed-off-by: Dan Rosenberg Signed-off-by: Florian Tobias Schandinat

drivers/video/via/via-gpio.c: fix warning

2010-08-05T22:36:27Z

drivers/video/via/via-gpio.c: In function 'viafb_gpio_probe': drivers/video/via/via-gpio.c:216: warning: assignment from incompatible pointer type Cc: Joseph Chan Cc: Scott Fang Cc: Jonathan Corbet Signed-off-by: Andrew Morton Signed-off-by: Florian Tobias Schandinat

fbdev: section cleanup in viafb driver

2010-08-05T21:58:15Z

This patch moves two functions from .devexit to .text, which are called on the probe error path. Also a function which is called by probe is moved from .text to .devinit. WARNING: vmlinux.o(.devinit.text+0x2ca5): Section mismatch in reference from the function via_pci_probe() to the function devexit.text:via_teardown_subdevs() The function __devinit via_pci_probe() references a function __devexit via_teardown_subdevs(). This is often seen when error handling in the init function uses functionality in the exit path. The fix is often to remove the __devexit annotation of via_teardown_subdevs() so it may be used outside an exit section. WARNING: vmlinux.o(.devinit.text+0x2cb1): Section mismatch in reference from the function via_pci_probe() to the function devexit.text:via_pci_teardown_mmio() The function __devinit via_pci_probe() references a function __devexit via_pci_teardown_mmio(). This is often seen when error handling in the init function uses functionality in the exit path. The fix is often to remove the __devexit annotation of via_pci_teardown_mmio() so it may be used outside an exit section. Signed-off-by: Henrik Kretzschmar Signed-off-by: Florian Tobias Schandinat

viafb: fix accel_flags check_var bug

2010-07-23T14:46:11Z

viafb: fix accel_flags check_var bug In check_var we should check and modify the var given and not the one which is currently active. So this code was obviously wrong. Probably this was doing no harm because all acceleration functions also check whether acceleration is possible. (otherwise I would expect this to lead to a null pointer dereference) Signed-off-by: Florian Tobias Schandinat Cc: Joseph Chan

viafb: probe cleanups

2010-07-23T14:44:52Z

viafb: probe cleanups Removal of strange special cases that must not exist as well as a useless check. Signed-off-by: Florian Tobias Schandinat Cc: Joseph Chan

viafb: remove ioctls which break the framebuffer interface

2010-07-23T14:43:05Z

viafb: remove ioctls which break the framebuffer interface The ioctls VIAFB_SET_DEVICE, VIAFB_SET_DEVICE_INFO and VIAFB_SET_SECOND_MODE are removed because they prevent a clean framebuffer driver because they modify the hardware and/or the internal structures. There are no known applications using these ioctls so no breakage is expected. Additionaly the main functionality was duplicating the framebuffer interface so there really should not exist any user. Signed-off-by: Florian Tobias Schandinat Cc: Joseph Chan

viafb: update fix before calculating depth

2010-07-23T14:41:06Z

viafb: update fix before calculating depth As the depth calculation depends on information in fix it is saner to do the update first. No runtime change expected as the value visual in fix used never changes to MONO. Signed-off-by: Florian Tobias Schandinat Cc: Joseph Chan

viafb: PLL value cleanup

2010-07-23T14:37:05Z

viafb: PLL value cleanup This is a big change of how PLL values are handled on the road to dynamic PLL value generation. The table was converted automatically in the relevant parameters for frequency generation. Sadly there were some bits set whose meaning is unknown. Those differences are documented but ignored as the unichrome code implies that they are not important (a big thanks to Luc for his amazing work). The PLL values for 31490000 and 133308000 are deleted as they were more than 5% off and not used anyway. The values for CX700@60466000 and VX855@153920000 are corrected as they were wrong and easily correctable as enough correct values was available because CX700 and VX855 support the same values only with a little difference in hardware format. All remaining values are not more than 2% off. Additionally the surrounding code is changed as needed especially the byte order of the values written to hardware to allow nicer conversion functions. This is mostly a change preparing for dynamic PLL generation and the two corrected values aside no runtime change is expected. Signed-off-by: Florian Tobias Schandinat Cc: Joseph Chan