linux.git/drivers/video/matrox, branch v2.6.15

[PATCH] matroxfb: Set maxhipri to 0

2005-11-07T15:53:54+00:00

The current init code sets hiprilvl to 0 and maxhipri to 5.  According to the
specs those values are illegal on both G200 and G400.  It also causes
distortions on the TV-out at least when CRTC2 is in YUV mode as is the case
with DirectFB.  This patch resets both values to 0.

Signed-off-by: Ville Syrj�l� 
Signed-off-by: Petr Vandrovec 
Cc: "Antonino A. Daplas" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] matroxfb: Kill a useless message

2005-11-07T15:53:54+00:00

No point in spamming the logs with a message about xres rounding.

Signed-off-by: Ville Syrj�l� 
Signed-off-by: Petr Vandrovec 
Cc: "Antonino A. Daplas" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] matroxfb: Use CACHEFLUSH on all chips

2005-11-07T15:53:54+00:00

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� 
Signed-off-by: Petr Vandrovec 
Cc: "Antonino A. Daplas" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] matroxfb: Add support for Mystique AGP

2005-11-07T15:53:54+00:00

Add new entries for Mystique AGP with the PCI ID 0x051e.

I don't actually have such boards but according to google they do exist.
Curiosly X.Org doesn't recognize that PCI ID.  And what's even more
interesting is that Matrox's own Windows drivers don't recognize it either.
After going through about a dozen different versions I did find one older
driver that does list this particular ID.  It is also listed in the pci.ids
file.

I'm not sure if non-220 AGP chips exist.  I left the chip revision check
intact for AGP chips nonetheless.

Signed-off-by: Ville Syrj�l� 
Signed-off-by: Petr Vandrovec 
Cc: "Antonino A. Daplas" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] matroxfb: Remove an unused wait queue entry

2005-11-07T15:53:54+00:00

wait_event_event_interruptible() uses a private wait queue entry so there's no
need for the caller to initialize one.

Signed-off-by: Ville Syrj�l� 
Signed-off-by: Petr Vandrovec 
Cc: "Antonino A. Daplas" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] fbcon/fbdev: Move softcursor out of fbdev to fbcon

2005-11-07T15:53:50+00:00

According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
drivers that do not support hardware cursors is redundant.  The soft_cursor
function is usable by all drivers because it is just a wrapper around
fb_imageblit.  And because soft_cursor is an fbcon-specific hook, the file is
moved to the console directory.

Thus, drivers that do not support hardware cursors can leave the fb_cursor
field blank.  For drivers that do, they can fill up this field with their own
version.

The end result is a smaller code size.  And if the framebuffer console is not
loaded, module/kernel size is also reduced because the soft_cursor module will
also not be loaded.

Signed-off-by: Antonino Daplas 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] matroxfb adjustments

2005-09-13T15:22:32+00:00

Some adjustments to the matroxfb code, for one part preventing the display
to be disabled for longer than necessary, and for the other part to make
information about the frame buffer position available so that a kernel
debugger might obtain that before the initial mode change.

Finally, some return code corrections to fit the generic fb code.

Signed-off-by: Jan Beulich 
Acked-by: Petr Vandrovec 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] matroxfb: read MGA PInS data on PowerPC

2005-09-09T20:58:01+00:00

This updates the matroxfb code so that it can find the PInS data embedded
in the BIOS on PowerPC cards.  The process for finding the data is
different on OpenFirmware cards than on x86 cards, and the code for doing
so was missing.

After patching, building, installing, and booting a kernel, you should grep
for "PInS" in /var/log/messages.  You should see two messages in the log:

PInS data found at offset XXXXX
PInS memtype = X

On the GXT135p card I get "31168" and "5".  The first value is irrelevant,
but it's presence lets me know that the PInS data was actually found.  On a
GXT130p, the second value should be 3.  Since I don't have access to that
hardware, if someone can verify that, I will submit a follow-on patch that
rips out all the memtype parameter stuff.

Signed-off-by: Ian Romanick 
Signed-off-by: Petr Vandrovec 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] I2C: Kill i2c_algorithm.id (5/7)

2005-09-05T16:14:31+00:00

Merge the algorithm id part (16 upper bits) of the i2c adapters ids
into the definition of the adapters ids directly. After that, we don't
need to OR both ids together for each i2c_adapter structure.

Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

[PATCH] drivers/video/matrox/matroxfb_misc.c: remove dead code

2005-06-25T23:25:04+00:00

This patch removes some obviously dead code found by the Coverity
checker.

This patch was already ACK'ed by Petr Vandrovec.

Signed-off-by: Adrian Bunk 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds