aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/video/intelfb/intelfbhw.h
Commit message (Collapse)AuthorAgeFilesLines
* intelfb: fix setting of active pipe with LVDS displaysKrzysztof Helt2009-12-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The intelfb driver sets color map depending on currently active pipe. However, if an LVDS display is attached (like in laptop) the active pipe variable is never set. The default value is PIPE_A and can be wrong. Set up the pipe variable during driver initialization after hardware state was read. Also, the detection of the active display (and hence the pipe) is wrong. The pipes are assigned to so called planes. Both pipes are always enabled on my laptop but only one plane is enabled (the plane A for the CRT or the plane B for the LVDS). Change active pipe detection code to take into account a status of the plane assigned to each pipe. The problem is visible in the 8 bpp mode if colors above 15 are used. The first 16 color entries are displayed correctly. The graphics chip description is here (G45 vol. 3): http://intellinuxgraphics.org/documentation.html Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13285 Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> Cc: Michal Suchanek <hramrach@centrum.cz> Cc: Dean Menezes <samanddeanus@yahoo.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Intel FB: more interlaced mode supportKrzysztof Halasa2007-10-161-1/+29
| | | | | | | | | | | Intel FB: allow odd- and even-field-first in interlaced modes, and proper sync to vertical retrace Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: <sylvain.meyer@worldonline.fr> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Intel FB: obvious changes and correctionsKrzysztof Halasa2007-10-161-1/+3
| | | | | | | | | | Intel FB: obvious changes and corrections Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: <sylvain.meyer@worldonline.fr> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Intel FB: whitespace, bracket and other clean-upsKrzysztof Halasa2007-10-161-7/+7
| | | | | | | | | | Intel FB: whitespace, bracket and other clean-ups Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: <sylvain.meyer@worldonline.fr> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Intel FB: support for interlaced video modesKrzysztof Halasa2007-10-161-0/+4
| | | | | | | | | | Intel framebuffer now supports interlaced video modes. Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* intelfb: add preliminary i2c supportDennis Munsie2006-07-031-0/+6
| | | | | | [02/07] intelfb: add GPIO registers. Signed-off-by: Dennis Munsie <dmunsie@cecropia.com>
* intelfb: add vsync interrupt supportEric Hustvedt2006-07-031-0/+1
| | | | | | | | [04/05] intelfb: implement FBIO_WAITFORVSYNC ioctl The (unofficial) FBIO_WAITFORVSYNC ioctl is implemented by sleeping on the appropriate waitqueue, as defined in my earlier patch. Currently, only display 0 (aka pipe A) is supported. Signed-off-by: Eric Hustvedt <ehustvedt@cecropia.com>
* intelfb: add vsync interrupt supportEric Hustvedt2006-07-031-0/+2
| | | | | | | | | | | | [03/05] intelfb: Implement basic interrupt handling Functions have been added to enable and disable interrupts using the MMIO registers. Currently only pipe A vsync interrupts are enabled. A generalized vsync accounting struct is defined, with the intent that it can encapsulate per-pipe vsync related info in the future. Currently a single instance is hard-coded. The interrupt service routine currently only looks for vsync interrupts on pipe A, and increments a counter and wakes up anyone waiting on it. This implementation is heavily influenced by similar implementations in the atyfb and matroxfb drivers. Signed-off-by: Eric Hustvedt <ehustvedt@cecropia.com>
* intelfb: add vsync interrupt supportEric Hustvedt2006-07-031-0/+13
| | | | | | | | | | [02/05] intelfb: Add interrupt related register definitions Add constants for accessing HWSTAM, IER, IIR, and IMR registers. Add constants for interrupt types supported by the 8xx and 9xx chipsets. The registers are also stored in the hwstate struct and dumped in the debug routine. Signed-off-by: Eric Hustvedt <ehustvedt@cecropia.com>
* intelfb: add vsync interrupt supportEric Hustvedt2006-07-031-0/+3
| | | | | | | | [01/05] intelfb: Add 16-bit register access macros This patch adds macros to read and write two-byte MMIO registers. The interrupt-related registers are all word-sized, rather than long-sized. Signed-off-by: Eric Hustvedt <ehustvedt@cecropia.com>
* intelfb: fixup p calculationDave Airlie2006-04-031-0/+1
| | | | | | | This fixes up the p calculation of p1 and p2 for the i9xx chipsets. This seems to work a lot better for lower pixel clocks.. Signed-off-by: Dave Airlie <airlied@linux.ie>
* intelfb: add pll index to the intelfb structureDave Airlie2006-04-031-8/+1
| | | | | Add the pll index into the information structure, change get_chipset to take only the info structure, use plls in correct places
* intelfb: prepare for i9xx support.Dave Airlie2006-04-031-15/+0
| | | | | | | This code just moves the PLL min/max calculations variables into a structure, it doesn't change or add any new functionality. Signed-off-by: Dave Airlie <airlied@linux.ie>
* Linux-2.6.12-rc2Linus Torvalds2005-04-161-0/+570
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!