History log of /drivers/video/matrox/matroxfb_base.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
25985edcedea6396277003854657b5f3cb31a628 31-Mar-2011 Lucas De Marchi <lucas.demarchi@profusion.mobi> Fix common misspellings

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
/drivers/video/matrox/matroxfb_base.h
c81476df1b4241aefba4ff83a7701b3a926bd7ce 19-Aug-2010 Ondrej Zary <linux@rainbow-software.org> matroxfb: fix incorrect use of memcpy_toio()

Screen is completely corrupted since 2.6.34. Bisection revealed that it's
caused by commit 6175ddf06b61720 ("x86: Clean up mem*io functions.").

H. Peter Anvin explained that memcpy_toio() does not copy data in 32bit
chunks anymore on x86.

Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: <stable@kernel.org> [2.6.34.x, 2.6.35.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/drivers/video/matrox/matroxfb_base.h
a690606d1f54845b018d033ac32e91df25cb2680 23-Sep-2009 Jean Delvare <khali@linux-fr.org> matroxfb: get rid of CONFIG_FB_MATROX_32MB

CONFIG_FB_MATROX_32MB is always enabled, so there is no point in having
ifdefs all around. And it is bad practice to use CONFIG_* as a name for
something which is not a Kconfig option.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/drivers/video/matrox/matroxfb_base.h
ee5a27497957e55a520788f88536401e7b12bf41 23-Sep-2009 Jean Delvare <khali@linux-fr.org> matroxfb: get rid of unneeded macro MINFO_FROM

With multihead support always enabled, macros MINFO_FROM and
MINFO_FROM_INFO are no longer needed and make the code harder to read.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/drivers/video/matrox/matroxfb_base.h
316b4d644caceb2cf7432d8a27e45b88f57ef2a0 23-Sep-2009 Jean Delvare <khali@linux-fr.org> matroxfb: get rid of unneeded macros WPMINFO and friends

With multihead support always enabled, these macros are no longer needed
and make the code harder to read.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/drivers/video/matrox/matroxfb_base.h
fc2d10ddfc8989e82f74d2a38c7d6bfa45bcaba9 23-Sep-2009 Jean Delvare <khali@linux-fr.org> matroxfb: get rid of unneeded macros ACCESS_FBINFO and MINFO

With multihead support always enabled, these macros are no longer needed
and make the code harder to read.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/drivers/video/matrox/matroxfb_base.h
0728bacbba3b0267fa8ca8be69aa43d81b57ab51 23-Sep-2009 Jean Delvare <khali@linux-fr.org> matroxfb: make CONFIG_FB_MATROX_MULTIHEAD=y mandatory

I would like to get rid of option CONFIG_FB_MATROX_MULTIHEAD and just
always enable it. There are many reasons for doing this:

* CONFIG_FB_MATROX_MULTIHEAD=y is what all x86 distributions do, so it
definitely works or we would know by now.

* Building the matroxfb driver with CONFIG_FB_MATROX_MULTIHEAD not set
results in the following build warning:

drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_open':
drivers/video/matrox/matroxfb_crtc2.c:265: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true'
drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_release':
drivers/video/matrox/matroxfb_crtc2.c:285: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true'

This is nothing to be worried about, the driver will work fine, but build
warnings are still annoying.

* The trick to get multihead support without CONFIG_FB_MATROX_MULTIHEAD,
which is described in the config help text, no longer works: you can't
load the same kernel module more than once.

* I fail to see how CONFIG_FB_MATROX_MULTIHEAD=y would make the code
significantly slower, contrary to what the help text says. A few extra
parameters on the stack here and there can't really slow things down in
comaprison to the rest of the code, and register access.

* The driver built without CONFIG_FB_MATROX_MULTIHEAD is larger than the
driver build with CONFIG_FB_MATROX_MULTIHEAD=y by 8%.

* One less configuration option makes things simpler. We add options
all the time, being able to remove one for once is nice. It improves
testing coverage. And I don't think the Matrox adapters are still
popular enough to warrant overdetailed configuration settings.

* We should be able to unobfuscate the driver code quite a bit after
this change (patches follow.)

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/drivers/video/matrox/matroxfb_base.h
5e2daeb3c982ea19ecad0c2e720a4052034be14b 23-May-2008 Harvey Harrison <harvey.harrison@gmail.com> fbdev: fix integer as NULL pointer warning

drivers/video/aty/atyfb_base.c:3359:26: warning: Using plain integer as NULL pointer
drivers/video/aty/radeon_base.c:2280:32: warning: Using plain integer as NULL pointer
drivers/video/matrox/matroxfb_base.h:203:25: warning: Using plain integer as NULL pointer
drivers/video/matrox/matroxfb_base.h:203:25: warning: Using plain integer as NULL pointer
drivers/video/sis/sis_main.c:5790:44: warning: Using plain integer as NULL pointer

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/drivers/video/matrox/matroxfb_base.h
e798bd95b61918e653f3d28f9176237236f2d103 10-Aug-2007 Paul A. Clarke <pc@us.ibm.com> matroxfb: rectify jitter (G450/G550)

This builds upon my previous attempts to resolve some jitter problems seen
with the Matrox G450 and G550 -based cards, including odd disparities observed
between x86 and Power -based machines in a somewhat less hackish way (removing
the hacked ifdefs).

Apparently, preference should be given to use the DVI PLL when frequencies
permit, the Standard PLL otherwise. The max pixel clock for the panellink
interface is extracted from the PInS information on the card and used as a
limit to determine which PLL to use.

Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Acked-by: Petr Vandrovec <petr@vandrovec.name>
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/drivers/video/matrox/matroxfb_base.h
08a498de79727d63a011f2583e9aba4d3083c3a0 17-Jul-2007 Antonino A. Daplas <adaplas@gmail.com> matroxfb: color setting fixes

- the pseudo_palette is only 16 elements long.
- do not write to the pseudo_palette if regno (array index) is more than 15
- remove code that writes to the 17th entry of the pseudo_palette

Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Acked-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/drivers/video/matrox/matroxfb_base.h
a8f340e394ff30b79ab5b03c67ab4c94b2ac3646 10-Jul-2006 Jon Smirl <jonsmir@gmail.com> [PATCH] vt: Remove VT-specific declarations and definitions from tty.h

MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a
function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h
allows all of the framebuffer and VT console drivers to remove their
dependency on tty.h.

[akpm@osdl.org: fix alpha build]
Signed-off-by: Jon Smirl <jonsmir@gmail.com>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/drivers/video/matrox/matroxfb_base.h
6ab3d5624e172c553004ecc862bfeac16d9d68b7 30-Jun-2006 Jörn Engel <joern@wohnheim.fh-wedel.de> Remove obsolete #include <linux/config.h>

Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
/drivers/video/matrox/matroxfb_base.h
6d39bedc47fbf18a940f5843981767c221d22cfe 20-May-2006 Paul A. Clarke <pc@us.ibm.com> [PATCH] matroxfb: fix DVI setup to be more compatible

There has been a longstanding problem with the Matrox G450 and perhaps
other similar cards, with modes "above" 1280x1024-60 on ppc/ppc64 boxes
running Linux. Higher resolutions and/or higher refresh rates resulted in
a very noticably "jittery" display, and sometimes no display, depending on
the physical monitor. This patch fixes that problem on the systems I have
easy access to...

I've tested with SLES9SP3 (2.6.5+ kernel) and 2.6.16-rc6 custom kernels on
an IBM eServer p5 520 w/G450 (a.k.a GXT135P on IBM's ppc64 systems), and a
colleague of mine (Ian Romanick) tested it successfully on an Apple ppc32
box (w/GXT135P). I also tested it on IA32 box I have with a GXT135P to
verify that it didn't obviously break anything. In my testing, I covered
single-card, single and dual-head setups using both HD15 and DVI-D signals,
on both the IA32 and ppc64 boxes. While everything appeared fine on both
boxes, I did encounter one problem: I can't get any signal on the DVI-D
output on the ppc64 box. However, this is also the case without my patch.

I just noticed that screen-blanking only occurs on the primary display as
well.

Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Signed-off-by: Ian Romanick <idr@us.ibm.com>
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/drivers/video/matrox/matroxfb_base.h
f3e21169b84a80b35d81a2b9fd97eb0b7d73d3f9 10-Jan-2006 Antonino A. Daplas <adaplas@gmail.com> [PATCH] matroxfb: Remove fbcon.h from the main header file

matroxfb has no need for struct display and fbcon.h. Remove.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/drivers/video/matrox/matroxfb_base.h
6c12f30554f29069afd485ecd05a1d54c8aece9f 07-Nov-2005 Ville Syrj�l� <syrjala@sci.fi> [PATCH] matroxfb: Use CACHEFLUSH on all chips

Use the CACHEFLUSH register on all chip types. The register is listed in all
other specs except 2064W. However I have verified that the register does work
on a 2064W despite being marked reserved in the specs. There were no
noticeable side effects after writing to the register.

Signed-off-by: Ville Syrj�l� <syrjala@sci.fi>
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
/drivers/video/matrox/matroxfb_base.h
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 17-Apr-2005 Linus Torvalds <torvalds@ppc970.osdl.org> Linux-2.6.12-rc2

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!
/drivers/video/matrox/matroxfb_base.h