Remove code that can never be reached.
Coverity Bug 67
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
No need for a file argument. If we'd really need it it's in vma->vm_file
already. gbefb and sgivwfb used to set vma->vm_file to the file argument, but
the kernel alrady did that.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The ioctl and file arguments to ->fb_mmap are totally unused and there's not
reason a driver should need them.
Also update the ->fb_compat_ioctl prototype to be the same as ->fb_mmap.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Clean up LT and LG chip descriptions.
"Mach64 LG" is called 3D Rage LT in the specs and ATI press releases.
"Mach64 LT" is unclear. XFree86 driver doesn't know this chip at all.
Windows display.inf calls it just "mach64 LT" and it uses the same driver as
VT-A/GT-A and older chips. VT-B/GT-B and better use another driver and all of
those chips have a more descriptive name in the display.inf file. That makes
me think this chip is not a 3D Rage chip.
Signed-off-by: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Clean up VT and GT chip descriptions.
All B revision VT chips are called 264VT3. Verified from pictures of the
chips as the specs are a bit unlear in this.
GT revision B1 is Rage II, B2 is Rage II+. Specs and chip pictures seem
to agree.
VT revision A4 is 264VT2. Revision A3 is probably a plain 264VT.
Signed-off-by: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Force blanking signal and disable display requests when blanked. Don't
disable LCD backlight with FB_BLANK_NORMAL.
Signed-off-by: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Set ECP (scaler/overlay clock) divider. The limits were taken from the
XFree86 ati driver.
Signed-off-by: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The overlay on 3D Rage LT Pro doesn't work correctly if stretching is
enabled when using only a CRT.
Signed-off-by: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Don't complain about invalid modes when FB_ACTIVATE_TEST is used.
Signed-off-by: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
CONFIG_ATYFB_XL_INIT option is broken for a long time. It will always cause a
kernel hang.
Since no one has fixed this problem for some time now, remove it from atyfb.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I have recently been switching from using 2.4.32 on my trusty
old Sparc Blade 100 to using 2.6.15 . Some of the problems I ran into
were distorted video when the console was active (missing first
character, skipped dots) and when running X windows (colored snow,
stripes, missing pixels). A quick examination of the 2.6 versus 2.4
source for the ATY driver revealed alot of changes.
A closer look at the code/data for the 64GR/XL chip revealed
two minor "typos" that the rewriter(s) of the code made. The first is
a incorrect clock value (230 .vs. 235) and the second is a missing
flag (M64F_SDRAM_MAGIC_PLL). Making both these changes seems to have
fixed my problem. I tend to think the 235 value is the correct one,
as there is a 29.4 Mhz clock crystal close to the video chip and 235.2
(29.4*8) is too close to 235 to make it a coincidence.
The flag for M64F_SDRAM_MAGIC_PLL was dropped during the
changes made by adaplas in file revision 1.72 on the old bitkeeper
repository.
The change relating to the clock rate has been there forever,
at least in the 2.6 tree. I'm not sure where to look for the old 2.5
tree or if anyone cares when it happened.
On SPARC Blades 100's, which use the ATY MACH64GR video chipset, the
clock crystal frequency is 235.2 Mhz, not 230 Mhz. The chipset also
requires the use of M64F_SDRAM_MAGIC_PLL in order to setup the PLL
properly for the DRAM.
Signed-off-by: Luis F. Ortiz <lfo@Polyad.Org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Reported by: Jean-Philippe Guérard (Bugzilla Bug 1782)
"I've tried with video=atyfb:debug and video=atyfb:debug,mode:1280x600, \
nomtrr.
In both case, the screen stays black, but seems divided into 4 vertical bands.
Some white lines pop up randomly on each vertical band."
The problem is a combination of an incorrect xclk plus lack of timing
information. The adapter is attached to an LCD device that can do 1280x600
(which is not a standard resolution). The global mode database does not have
an entry for it. Fortunately, the Video BIOS contains the complete timing
info for this display, however, atyfb is not making use of it.
Add support to get the timing information from the BIOS, if available.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
Currently, atyfb has code that sets the hsync and vsync polarity based on the
current video mode, without letting the user override the settings.
Remove this particular code. The sync polarities are set by the PROM, the
user or by the videomode.
Signed-off-by: Alexander Kern <alex.kern@gmx.de>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This adds type-checking to pm_message_t, so that people can't confuse it
with int or u32. It also allows us to fix "disk yoyo" during suspend (disk
spinning down/up/down).
[We've tried that before; since that cpufreq problems were fixed and I've
tried make allyes config and fixed resulting damage.]
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Alexander Nyberg <alexn@telia.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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!
