- 24 Jul, 2008 40 commits
-
-
Adrian Bunk authored
This patch removes compat code for older kernel versions. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Cc: <thomas@winischhofer.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Roland Kletzing authored
mdacon incorrectly detects MDA hardware on systems without such graphics card. One may load this module by chance, for example when doing some systematical module-testing, and if there is no Monochrome Display Adapter attached , module init renders vc1-16 completely unusable. I and others have run into this more than once. see [Bug 224522 - modprobe mdacon freezes machine -> https://bugzilla.novell.com/show_bug.cgi?id=224522 ] for example Apparently proper MDA detection seems to be broken for a long time - seems to be related to those #ifdef TEST_MDA_B statements added by Edward Betts. this commit back in 2002 made things even worse : http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commit;h=c72757b49c88914433244757fb4967fc63546685 It changed default vc allocation from 13-16 to 1-16 for no apparent reason (!?) , and with that (and without X), mdacon grabs the vc you`re currently sitting on and locks you out. this is from Kconfig : >config MDA_CONSOLE > depends on !M68K && !PARISC && ISA > tristate "MDA text console (dual-headed) (EXPERIMENTAL)" > ---help--- > Say Y here if you have an old MDA or monochrome Hercules graphics > adapter in your system acting as a second head ( = video card). You > will then be able to use two monitors with your Linux system. Do not > say Y here if your MDA card is the primary card in your system; the > normal VGA driver will handle it. As we can see mdacon is just meant as an additional driver for dual-head setup, and since kernel 2.4.36 still defaults to vc13-16 , setting the default back to that value again shouldn`t do any harm. Hereby i'm reverting that change, setting default back to to vc13-16 again. Besides the fact that mdacon may be rarely or never be used these days and could perhaps put to trash anyway (pre-dinosaur hardware!), indeed this is not a real solution, but at least it removes the unfortunate side-effect of messing up the vc you`re working on. Signed-off-by:
Roland Kletzing <devzero@web.de> Cc: James Simmons <jsimmons@infradead.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Tim Schmielau <tim@physik3.uni-rostock.de> Cc: Jan Engelhardt <jengelh@gmx.de> Signed-off-by:
-
Krzysztof Helt authored
The tridentfb driver should handle now all chipsets handled by the cyblafb driver. Remove the message which claims that support will be removed. Signed-off-by:
Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by:
-
Krzysztof Helt authored
Add imageblit acceleration for the Blade3D family of cores. The code is based on code from the cyblafb driver. It is a step toward assimilating back the cyblafb driver into the tridentfb driver. The cyblafb driver handles a subfamily of the Trident Blade3d cores. Signed-off-by:
-
Krzysztof Helt authored
This patch fixes following problems: - does not allow the m parameter to reach 0 as it locks the graphics core (power cycle needed) - for the newer chips (with new clock registers) does not allow of n / m ratio below 4 as it gives unstable image on the Blade3D core - extend shift parameter (k) range to 2 for the newer chips to cope with the n /m >= 4 limit at low resolution (bandwidth) modes - prefer modes with higher n / m ratio (higher k values) Signed-off-by:
-
Krzysztof Helt authored
The Trident cards uses only 20-bit address of screen start in double words. This allows addressing for only 4MB of video memory so check this. Also remove some redundant checks and assignments. Signed-off-by:
-
Krzysztof Helt authored
Fix depth setting for 8 bpp mode. The nice 224 color logo is not displayed in 8 bpp depth without this fix. Signed-off-by:
-
Krzysztof Helt authored
This patch fixes two problems when acceleration is enabled: - console switch from the Xorg locks up the computer because the Xorg code locks some registers and disables the mmio mode, so reenable these in the tridentfb_set_par() and enable_mmio() - blacklist the Image975 chipset from setting PCI burst mode. This helps with random lock ups of the framebuffer on this chip. The same fix is probably needed for the Xorg as well. Signed-off-by:
-
Krzysztof Helt authored
This patch contains general source code improvments: - more simple functions are inline - removes some meaningless output and the VERSION string as it is no use - eng_par is moved into the tridentfb_par - removed small section of code for CyberBladeXPAi1 which is maybe right for only one resolution and refresh rate and is probably redundant now - other minor improvements Signed-off-by:
-
Krzysztof Helt authored
This patch replaces deprecated constant FB_ACCELF_TEXT with FBINFO_HWACCEL_DISABLED and adds constants for Trident families of accelerators. The FBINFO_HWACCEL_DISABLED is correctly used so noaccel parameter works now. Signed-off-by:
-
Krzysztof Helt authored
This patch fixes few issues related to timings and pixclock generation: - disallow the pixclocks with numerator lower than double denominator. This fixes display instability for some modes. - choose the pixelclock with the highest numerator and denominator values. This improve image quality and fixes display instability for some modes. - make interlaced modes work. - set synchronization pulses polarization correctly. - horizontal synchronization timing are now the same as generated by X. Signed-off-by:
-
Krzysztof Helt authored
This patch fixes two problems when acceleration is enabled: - bit for bitblt direction is corrected so scrolling down works as expected on 3DImage chips - initialization of acceleration is done later this helps with initial console malfuntion (on Blade3D chips) well documented here: http://marc.info/?l=linux-fbdev-users&m=111386953124478&w=2Signed-off-by:
-
Krzysztof Helt authored
This patch brings various acceleration improvements: - set copyarea/fillrect for non-accelerated framebuffer (fix) - remove 15 bpp depth handling to simplify code as it hardly works (15 bpp handling was obviously missing in some switches) - add fb_sync call and move waiting before accelerated function to make acceleration more asynchronous to cpu (few % of speed improvement) - add cpu_relax() call in waiting loops - make longer register names and name more registers - move registers' definition to header - general code improvements (shortening, simplifying) Signed-off-by:
-
Krzysztof Helt authored
This patch adds acceleration for TGUI 9440 and 96xx chips. These chips requires line length to be power of 2, so this is also changed. It also moves the troubling enable_mmio() function to its final destination. Signed-off-by:
-
Krzysztof Helt authored
The TGUI 9440 requires doubling clock for 16bpp (hi-color) modes. The patch also moves back enable_mmio() call to the right position. Signed-off-by:
-
Krzysztof Helt authored
Do not overwrite bits which contain memory type settings. It removes noise pixels ("snow") on Blade3D and 3DImage chips. Signed-off-by: -
Krzysztof Helt authored
Do some additional checks (like pixelclock versus ramdac speed) to eliminate modes which do not work. Signed-off-by:
-
Krzysztof Helt authored
Initialize the pseudo_palette pointer properly. This fixes crash when 16bpp or 32bpp mode is selected. Signed-off-by:
-
Krzysztof Helt authored
Add support for TGUI 9440 chip. Signed-off-by:
-
Krzysztof Helt authored
Improved values for some registers after Xorg Trident driver. The main problem was that values set by BIOS have been ignored. This patch completely remove random pixels ("snow") on the TGUI 9680 and 9440 (not supported yet by the driver). It does not help with the "snow" on 3DImage and Blade3D cards. There is also small improvement in timing calculations (hblank start and vblank start) Signed-off-by: -
Krzysztof Helt authored
Add missing release of allocated fb_info structure and move enable_mmio() to fix error path. Signed-off-by:
-
Krzysztof Helt authored
The Xorg code shows that Trident models 9660, 9680 and 9682 require a different clock setting method. Add the second clock setting method for older models. Signed-off-by:
-
Krzysztof Helt authored
Use the mmio outb function instead of direct one. The mmio registers are already mapped (in the probe function). Signed-off-by:
-
Krzysztof Helt authored
Fix broken timings calculations. This patch helps with following problems: - no left part of screen visible (up to half of the screen) - monitor's frequencies are not the ones intended for selected modes - if mode with resoultion y > 1024 is selected at least once then all modes with y < 1024 are "out of sync" (no display) Signed-off-by:
-
Krzysztof Helt authored
Make use of functions and constants from the vga.h header to compact the code and make it more readable. Signed-off-by:
-
Krzysztof Helt authored
This patch moves acceleration hooks into the tridentfb_par structure and removes global hooks. Signed-off-by:
-
Krzysztof Helt authored
This patch converts the is_blade() and is_xp() macros into local functions. Signed-off-by:
-
Krzysztof Helt authored
This patch moves flat panel indicator into tridentfb_par structure and removes related global variables and macros. Signed-off-by:
-
Krzysztof Helt authored
This patch moves the chip_id into tridentfb_par structure and removes global chip_id related constants. It also bumps version of the driver to 0.7.9 Signed-off-by:
-
Krzysztof Helt authored
This patch moves pseudo palette int tridentfb_par structure and removes global default_var. Signed-off-by:
-
Krzysztof Helt authored
This patch converts fb_info structure from global variable to allocatable one. The global default_par is moved into function variable. Signed-off-by:
-
Krzysztof Helt authored
This patch replaces macros with static functions and puts tridentfb_par pointer as the first argument of these functions. These is a step toward multihead support. Additionally, bogus TRIDENT_MMIO define is removed as the driver supports graphics cards only through the mmio mode. Signed-off-by:
-
Sebastian Siewior authored
Basic FB driver for the carmine chip. The driver registers two FB devices for the two possible screens. The DRAM settings can be be switched via Kconfig (between eval board and custom). Signed-off-by:
Sebastian Siewior <bigeasy@linutronix.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by:
-
Yoichi Yuasa authored
Implement the ioctls RTC_PIE_ON, RTC_PIE_OFF, RTC_IRQP_SET and RTC_IRQP_READ in the standard RTC way. Thanks Dave for noticing it. Signed-off-by:
Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Cc: David Brownell <david-b@pacbell.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
David Brownell authored
This fixes kernel http://bugzilla.kernel.org/show_bug.cgi?id=11112 (bogus RTC update IRQs reported) for rtc-cmos, in two ways: - When HPET is stealing the IRQs, use the first IRQ to grab the seconds counter which will be monitored (instead of using whatever was previously in that memory); - In sane IRQ handling modes, scrub out old IRQ status before enabling IRQs. That latter is done by tightening up IRQ handling for rtc-cmos everywhere, also ensuring that when HPET is used it's the only thing triggering IRQ reports to userspace; net object shrink. Also fix a bogus HPET message related to its RTC emulation. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Report-by:
W Unruh <unruh@physics.ubc.ca> Cc: Andrew Victor <avictor.za@gmail.com> Cc: <stable@kernel.org> Signed-off-by:
-
David Brownell authored
This fixes kernel http://bugzilla.kernel.org/show_bug.cgi?id=11112 (bogus RTC update IRQs reported) for rtc-at91rm9200 by scrubbing old IRQ status before enabling IRQs. It also removes nonfunctional periodic IRQ support from this driver; only update IRQs are reported, or provided by the hardware. I suspect some other RTCs probably have versions of #11112; it's easy to overlook, since most non-RTC drivers don't care about spurious IRQs: they're not reported to userspace. Signed-off-by:
-
Ben Dooks authored
The rtc-s3c.c driver has been using its own ioctl() handling to deal with alarm and periodic interrupts to handle what should now be done with the rtc core code. Change to using the .irq_set_freq and .irq_set_state driver entries and remove the .ioctl handling. Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Acked-by:
Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Ben Dooks authored
Add the relevant __devinit and __devexit attributes to the rtc-s3c driver. Signed-off-by:
-
David Brownell authored
Resolve http://bugzilla.kernel.org/show_bug.cgi?id=11051 and other bugs related to the way the HPET glue code in rtc-cmos was incomplete and inconsistent: * Switch the approach so that the basic driver code flow isn't changed by having HPET ... instead, just have HPET shadow the RTC_CONTROL irq enables and RTC_FREQ_SELECT data. It's only coping with IRQ thievery, after all. * Do that consistently (!!) to avoid problems when the HPET code is out of sync with the real RTC intent. Examples include: - cmos_procfs(), which now reports correct data - cmos_irq_set_state() ... also removing the previous PIE_{ON,OFF} ioctl support so only one code path manages "periodic" IRQs - cmos_do_shutdown() ... currently a "just in case" change. - cmos_suspend() and cmos_resume() ... also handling a bug that was specific to HPET's IRQ thievery, where the alarm wasn't disabled after waking the system * Always call that HPET code under the RTC spinlock (it doesn't do its own locking) Also clean up the HPET glue: * Add some comments explaining what's going on. * Switch to having just one #ifdef for the HPET glue, and inline functions (not #defines) to avoid some compiler warnings. * Have the probe message also report when HPET IRQs are involved This still leaves various holes in the HPET glue, like the emulated update IRQs being out of sync with the RTC, alarms never using day or month matches, and many extra IRQs (at 64 Hz). [akpm@linux-foundation.org: fix build] Signed-off-by:
-
Carlos R. Mafra authored
When CONFIG_HPET_EMULATE_RTC is defined the external declaration of hpet_rtc_interrupt is redundant due to the inclusion of hpet.h. When !CONFIG_HPET_EMULATE_RTC we make it clear that hpet_rtc_interrupt is not used by defining it to return zero. Signed-off-by:
Carlos R. Mafra <crmafra@ift.unesp.br> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
