Commit Graph

13 Commits

Author SHA1 Message Date
Krzysztof Helt
b614ce8b3c tridentfb: fix memory size detection
Fix memory size multiplier during detection.

Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-10 18:01:18 -07:00
Krzysztof Helt
3acd9d4620 tridentfb: register should be left in non-locked state
Remove locking registers after they are unlocked during switch to/from MMIO
mode.  This fixes regression on the Blade3D (Trident 9880) caused by the
previous patch (probe fixes).

Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-10 18:01:17 -07:00
Krzysztof Helt
e8ed857c64 tridentfb: resource management fixes in probe function
Correct error paths in probe function.

The probe function enables mmio mode so it important to disable the mmio
mode before exiting the probe function.  Otherwise, the console is left in
unusable state (garbled fonts at least, lock up at worst).

[akpm@linux-foundation.org: cleanups]
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-04 16:35:12 -08:00
Krzysztof Helt
245a2c2c69 tridentfb: coding style improvement
This patch contains coding style improvements to the tridentfb driver (white
spaces, indentations, long lines).

It also moves fb_ops structure after fb api functions are defined.

Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
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>
2007-10-16 09:43:15 -07:00
Antonino A. Daplas
973d9ab231 tridentfb: fix pseudo_palette array overrun in setcolreg
The pseudo_palette has only 16 elements. Do not write if regno (the array
index) is more than 15.

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>
2007-07-17 10:23:12 -07:00
Amol Lad
a02f6402d5 [PATCH] ioremap balanced with iounmap for drivers/video/tridentfb
ioremap must be balanced by an iounmap and failing to do so can result in a
memory leak.

Signed-off-by: Amol Lad <amol@verismonetworks.com>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-08 08:29:04 -08:00
Jörn Engel
6ab3d5624e 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>
2006-06-30 19:25:36 +02:00
Randy Dunlap
474ab45a1f [PATCH] trident fb section fixes
Priority: not critical.
Change 3 functions from __init to __devinit.
Could be an init/probe problem in theory, but not observed, so not
high priority IMO.

Fix section mismatch warnings:
WARNING: drivers/video/tridentfb.o - Section mismatch: reference to .init.text: from .text between 'trident_pci_probe' (at offset 0x1aad) and 'trident_pci_remove'
WARNING: drivers/video/tridentfb.o - Section mismatch: reference to .init.text: from .text between 'trident_pci_probe' (at offset 0x1b22) and 'trident_pci_remove'
WARNING: drivers/video/tridentfb.o - Section mismatch: reference to .init.text: from .text between 'trident_pci_probe' (at offset 0x1b31) and 'trident_pci_remove'

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-25 10:01:15 -07:00
Antonino A. Daplas
c465e05a03 [PATCH] fbcon/fbdev: Move softcursor out of fbdev to fbcon
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 <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 07:53:50 -08:00
Knut Petersen
9fa68eae9f [PATCH] framebuffer: new driver for cyberblade/i1 graphics core
This is a framebuffer driver for the Cyberblade/i1 graphics core.

Currently tridenfb claims to support the cyberblade/i1 graphics core.  This
is of very limited truth.  Even vesafb is faster and provides more working
modes and a much better quality of the video signal.  There is a great
number of bugs in tridentfb ...  but most often it is impossible to decide
if these bugs are real bugs or if fixing them for the cyberblade/i1 core
would break support for one of the other supported chips.

Tridentfb seems to be unmaintained,and documentation for most of the
supported chips is not available.  So "fixing" cyberblade/i1 support inside
of tridentfb was not an option, it would have caused numerous
if(CYBERBLADEi1) else ...  cases and would have rendered the code to be
almost unmaintainable.

A first version of this driver was published on 2005-07-31.  A fix for a
bug reported by Jochen Hein was integrated as well as some changes
requested by Antonino A.  Daplas.

A message has been added to tridentfb to inform current users of tridentfb
to switch to cyblafb if the cyberblade/i1 graphics core is detected.

This patch is one logical change, but because of the included documentation
it is bigger than 70kb.  Therefore it is not sent to lkml and
linux-fbdev-devel,

Signed-off-by: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Muli Ben-Yehuda <mulix@mulix.org>
Acked-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 13:58:02 -07:00
Antonino A. Daplas
8d894c4797 [PATCH] tridentfb: Fix scrolling artifacts during disk IO
Reported by: Jochen Hein (Bugzilla Bug 4312)

When there is disk I/O happening, the framebuffer has a little snow on
the screen.  Once I/O has finished, no garbage remains on screen.

This bug was explained by: Knut Petersen

Most important is CRTC register 2f, signal quality is also improved for
higher vclk values by changing set_vclk() according to the X drivers and
cyblafb.c

The fix is to set the performance register (0x2f) with a more stable
value.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-01 10:07:53 -07:00
Antonino A. Daplas
8dad46cf38 [PATCH] tridentfb: Fix scrolling artifacts if acceleration is enabled
Reported by: Jochen Hein (Bugzilla Bug 4386)

booting leaves the end of long lines in the last line on screen when
scrolling.  When X is running, scrolling puts garbage on the screen
(looks like X data) Console switch fixes the screen.  Behaviour seems to
be identical with noaccel and without on the video=tridentfb parameter
in lilo.conf.

This bug was explained by: Knut_Petersen

Acceleration is broken for all BLADE 3D chips for all versions of kernel
2.6 except for 32bit modes.  Most important reason is that the u32 col
parameter of the graphics engine needs the color value replicated to all
u8 of the u32 (8bit modes) and to both u16 of the u32.

Fix color value passed to graphics engine, verified by the reporter.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-01 10:07:13 -07:00
Linus Torvalds
1da177e4c3 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!
2005-04-16 15:20:36 -07:00