From: Jak <rf...@ei...> - 2003-01-11 13:27:21
|
With so much good development being done on framebuffer drivers at the mo= ment, perhaps the following is only a temporary problem, but I hope the following repor= t is of some use. I seem to be triggering a reproducible bug when loading rivafb, whether i= t is built-in or modular with both 2.5.54 & 2.5.55 ( and, I suspect, 2.5.53 also ). I have tried rivafb on 2 different nVidia cards, both yield the similar r= esults when using recent ( Jan 8 ) fbdev.diff.gz patch. After rivafb is loaded, the display goes bright green. After entering a c= ommand, I get text back, but colours are wrong - there is no visible blue on screen i.e= with colorized ls listing, normally blue text is bright green, normally red is ( brighte= r ) red, normally white is grey. This is from 2.5.55 with fbdev.diff.gz applied, rivafb and fbcon both mod= ular: I have manually insmodded cfbimgblt & vgastate, then insmod rivafb Jan 11 12:30:41 TBird kernel: rivafb: nVidia device/chipset 10DE002C Jan 11 12:30:41 TBird kernel: rivafb: RIVA MTRR set to ON Jan 11 12:30:41 TBird kernel: rivafb: PCI nVidia NV4 framebuffer ver 0.9.= 5b (nVidiaRIVA-VTNT2, 16 MB @ 0xD0000000) Jan 11 12:30:41 TBird kernel: Badness in kobject_register at lib/kobject.= c:129 Jan 11 12:30:41 TBird kernel: Call Trace: Jan 11 12:30:41 TBird kernel: [<d08d43b4>] rivafb_driver+0x54/0xfffddd00= [rivafb] Jan 11 12:30:41 TBird kernel: [<c01c6aa6>] kobject_add+0x56/0x60 Jan 11 12:30:41 TBird kernel: [<d08d43a4>] rivafb_driver+0x44/0xfffddd00= [rivafb] Jan 11 12:30:41 TBird kernel: [<c01f67f9>] bus_remove_device+0x59/0xc0 Jan 11 12:30:41 TBird kernel: [<d08d43a4>] rivafb_driver+0x44/0xfffddd00= [rivafb] Jan 11 12:30:41 TBird kernel: [<d08d3078>] +0x0/0xfffdefe8 [rivafb] Jan 11 12:30:41 TBird kernel: [<c01f6c51>] put_driver+0x31/0x40 Jan 11 12:30:41 TBird kernel: [<d08d4388>] rivafb_driver+0x28/0xfffddd00= [rivafb] Jan 11 12:30:41 TBird kernel: [<c01cb369>] pci_device_resume+0x49/0x60 Jan 11 12:30:41 TBird kernel: [<d08d4388>] rivafb_driver+0x28/0xfffddd00= [rivafb] Jan 11 12:30:41 TBird kernel: [<d08b2032>] 0xd08b2032 Jan 11 12:30:41 TBird kernel: [<d08d4360>] rivafb_driver+0x0/0xfffddd00 = [rivafb] Jan 11 12:30:41 TBird kernel: [<d08d5d00>] +0x0/0xfffdc360 [rivafb] Jan 11 12:30:41 TBird kernel: [<c012ca97>] load_module+0x117/0x1c0 Jan 11 12:30:41 TBird kernel: [<c0109327>] system_call+0x7/0xb Jan 11 12:30:41 TBird kernel: Module Size Used by rivafb 45444 0 cfbimgblt 2880 1 rivafb vgastate 9472 1 rivafb mousedev 7256 1 Now I rmmod rivafb and insmod it again : Module Size Used by cfbimgblt 2880 0 vgastate 9472 0 mousedev 7256 1 Jan 11 12:35:29 TBird kernel: Badness in kobject_register at lib/kobject.= c:129 Jan 11 12:35:29 TBird kernel: Call Trace: Jan 11 12:35:29 TBird kernel: [<d08d43b4>] rivafb_driver+0x54/0xfffddd00= [rivafb] Jan 11 12:35:29 TBird kernel: [<c01c6aa6>] kobject_add+0x56/0x60 Jan 11 12:35:29 TBird kernel: [<d08d43a4>] rivafb_driver+0x44/0xfffddd00= [rivafb] Jan 11 12:35:29 TBird kernel: [<c01f67f9>] bus_remove_device+0x59/0xc0 Jan 11 12:35:29 TBird kernel: [<d08d43a4>] rivafb_driver+0x44/0xfffddd00= [rivafb] Jan 11 12:35:29 TBird kernel: [<d08d3078>] +0x0/0xfffdefe8 [rivafb] Jan 11 12:35:29 TBird kernel: [<c01f6c51>] put_driver+0x31/0x40 Jan 11 12:35:29 TBird kernel: [<d08d4388>] rivafb_driver+0x28/0xfffddd00= [rivafb] Jan 11 12:35:29 TBird kernel: [<c01cb369>] pci_device_resume+0x49/0x60 Jan 11 12:35:29 TBird kernel: [<d08d4388>] rivafb_driver+0x28/0xfffddd00= [rivafb] Jan 11 12:35:29 TBird kernel: [<d08b2032>] 0xd08b2032 Jan 11 12:35:29 TBird kernel: [<d08d4360>] rivafb_driver+0x0/0xfffddd00 = [rivafb] Jan 11 12:35:29 TBird kernel: [<d08d5d00>] +0x0/0xfffdc360 [rivafb] Jan 11 12:35:29 TBird kernel: [<c012ca97>] load_module+0x117/0x1c0 Jan 11 12:35:29 TBird kernel: [<c0109327>] system_call+0x7/0xb Jan 11 12:35:29 TBird kernel: Module Size Used by rivafb 45444 0 cfbimgblt 2880 1 rivafb vgastate 9472 1 rivafb mousedev 7256 1 BTW1: With stock 2.5.5 and modular rivafb, module will not load, this is = what I get : Jan 10 12:49:53 TBird kernel: rivafb: falsely claims to have parameter fo= nt BTW2: the FBCON_ADVANCED "Advanced low level driver options" still shows= up in=20 make *config, but does not seem to do much - should it still be there ? BTW3: the second nVidia card I referred to is on my new laptop, using Gef= orce4 420 Go card, which is not yet supported in 2.4.x, but seems to be detected prope= rly in 2.5.x. Loading fbcon causes bigger problems : serial OOPSes shortly followed by = complete lockup accel_putcs always seems to be implicated. Jan 11 12:36:51 TBird kernel: Call Trace: Jan 11 12:36:51 TBird kernel: [<d08cd437>] accel_putcs+0x157/0xfffe4f95 = [fbcon] Jan 11 12:36:51 TBird kernel: [<d08d2d30>] +0x30/0xfffdf575 [fbcon] Jan 11 12:36:51 TBird kernel: [<d08d2d00>] +0x0/0xfffdf575 [fbcon] Jan 11 12:36:51 TBird kernel: [<c017a731>] ext3_get_block_handle+0x51/0x= 90 Jan 11 12:36:51 TBird kernel: [<c0211b2c>] blk_recount_segments+0xdc/0x1= 50 Jan 11 12:36:51 TBird kernel: [<d08d4da0>] fb_display+0x0/0xfffdd4d5 [fb= con] Jan 11 12:36:51 TBird kernel: [<d08ce976>] fbcon_putcs+0x86/0xfffe3985 [= fbcon] Jan 11 12:36:51 TBird kernel: [<d08d4da0>] fb_display+0x0/0xfffdd4d5 [fb= con] Jan 11 12:36:51 TBird kernel: [<c020b14b>] set_console+0x24b/0x300 Jan 11 12:36:51 TBird kernel: [<c011c350>] sys_syslog+0x60/0x70 Jan 11 12:36:51 TBird kernel: [<c011c42c>] _call_console_drivers+0x5c/0x= 120 Jan 11 12:36:51 TBird kernel: [<c011c73f>] acquire_console_sem+0x3f/0xa0 Jan 11 12:36:51 TBird kernel: [<c011c669>] emit_log_char+0x109/0x140 Jan 11 12:36:51 TBird kernel: [<c0129eb5>] __constant_c_and_count_memset= +0x35/0x40 Jan 11 12:36:51 TBird kernel: [<c0117b3f>] bust_spinlocks+0x21f/0x4b8 Jan 11 12:36:51 TBird kernel: [<c021fbd6>] execute_drive_cmd+0xf6/0x1a0 Jan 11 12:36:51 TBird kernel: [<c021fda7>] ide_stall_queue+0xd7/0x1d0 Jan 11 12:36:51 TBird kernel: [<c021febf>] ide_do_request+0x1f/0x30 Jan 11 12:36:51 TBird kernel: [<c0212152>] blk_remove_plug+0x42/0x50 Jan 11 12:36:51 TBird kernel: [<c0118f9a>] scheduling_functions_start_he= re+0x16a/0x2a0 Jan 11 12:36:51 TBird kernel: [<d08d324f>] +0x54f/0xfffdf575 [fbcon] Jan 11 12:36:51 TBird kernel: [<c0117920>] bust_spinlocks+0x0/0x4b8 Jan 11 12:36:51 TBird kernel: [<c0109d31>] divide_error+0x2d/0x38 Jan 11 12:36:51 TBird kernel: [<d08d324f>] +0x54f/0xfffdf575 [fbcon] Jan 11 12:36:51 TBird kernel: [<d08c1ef0>] fontdata_8x16+0x210/0x2f73e32= 0 [font] Jan 11 12:36:51 TBird kernel: [<d08d4300>] +0x1600/0xfffdf575 [fbcon] Jan 11 12:36:51 TBird kernel: [<d08cd437>] accel_putcs+0x157/0xfffe4f95 = [fbcon] Jan 11 12:36:51 TBird kernel: [<d08d2d50>] +0x50/0xfffdf575 [fbcon] Jan 11 12:36:51 TBird kernel: [<d08d2d00>] +0x0/0xfffdf575 [fbcon] Jan 11 12:36:51 TBird kernel: [<d08d4da0>] fb_display+0x0/0xfffdd4d5 [fb= con] Jan 11 12:36:51 TBird kernel: [<d08ce976>] fbcon_putcs+0x86/0xfffe3985 [= fbcon] Jan 11 12:36:51 TBird kernel: [<d08d4da0>] fb_display+0x0/0xfffdd4d5 [fb= con] Jan 11 12:36:51 TBird kernel: [<c0207224>] scrdown+0x124/0x190 Jan 11 12:36:51 TBird kernel: [<c0207e20>] set_origin+0x150/0x180 Jan 11 12:36:51 TBird kernel: [<c02083f3>] vc_allocate+0x303/0x420 Jan 11 12:36:51 TBird kernel: [<d08ce27d>] fbcon_set_display+0x31d/0xfff= e4315 [fbcon] Jan 11 12:36:51 TBird kernel: [<c0135cb8>] cache_free_debugcheck+0xb8/0x= d0 Jan 11 12:36:51 TBird kernel: [<c0134e36>] kmem_cache_alloc+0x96/0xd0 Jan 11 12:36:51 TBird kernel: [<d08d4da0>] fb_display+0x0/0xfffdd4d5 [fb= con] Jan 11 12:36:51 TBird kernel: [<d08cdac9>] fbcon_init+0x59/0xfffe4805 [f= bcon] Jan 11 12:36:51 TBird kernel: [<d08d1820>] fb_con+0x0/0xfffe0a55 [fbcon] Jan 11 12:36:51 TBird kernel: [<c0207f1c>] vc_cons_allocated+0xac/0x110 Jan 11 12:36:51 TBird kernel: [<c020b8ba>] clear_buffer_attributes+0xaa/= 0x1c0 Jan 11 12:36:51 TBird kernel: [<d08d2bc0>] +0x0/0xfffdf6b5 [fbcon] Jan 11 12:36:51 TBird kernel: [<d08d1939>] +0x1d/0xfffe0959 [fbcon] Jan 11 12:36:51 TBird kernel: [<d08d2bc0>] +0x0/0xfffdf6b5 [fbcon] Jan 11 12:36:51 TBird kernel: [<d08b226d>] 0xd08b226d Jan 11 12:36:51 TBird kernel: [<d08d1820>] fb_con+0x0/0xfffe0a55 [fbcon] Jan 11 12:36:51 TBird kernel: [<c012ca97>] load_module+0x117/0x1c0 Jan 11 12:36:51 TBird kernel: [<c0109327>] system_call+0x7/0xb |
From: James S. <jsi...@in...> - 2003-01-15 00:44:19
|
Can you try the latest pacth at http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz |
From: Jak <rf...@ei...> - 2003-01-18 20:25:17
|
James, =09=09I still see the same problem using 2.5.59. I think this is the same problem as that referred to by Udo A. Steinberg http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D104278873827538&w=3D2 ( I get similar results as him if I compile rivafb built-in ) Is this possibly related to driver-model issues discussed in this thread = ? http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D104283662023857&w=3D2 Good news is that 2.5.59 seems quite stable as regards framebuffer. It no longer locks up after loading fbcon. But rmmod fbcon still causes instant death accompanied by increased whirring noises from inside box. To summarise: insmod rivafb causes "Badness in kobject_register" every time=20 ( after pci_register_driver() in rivafb_init(),see below ) after insmod rivafb, I have a green screen, which can be cleared by fbse= t ( fbset now changes resolution of all VTs, this is different from 2.4.x= ) after clearing green screen using fbset, text colours are wrong now ( 2.5.59 ), I can insmod fbcon, and screen looks OK again ( apart fr= om the left-hand-most column of screen appears at right-hand side of scree= n ) rmmod fbcon locks up machine, no ALT-SYSRQ effective Jan 18 14:44:10 TBird kernel: About to pci_module_init() in rivafb_init() Jan 18 14:44:10 TBird kernel: Entering rivafb_probe() Jan 18 14:44:10 TBird kernel: rivafb: nVidia device/chipset 10DE002C Jan 18 14:44:10 TBird kernel: rivafb: RIVA MTRR set to ON Jan 18 14:44:10 TBird kernel: About to pci_set_drvdata() in rivafb_probe(= ) Jan 18 14:44:10 TBird kernel: rivafb: PCI nVidia NV4 framebuffer ver 0.9.= 5b (nVidiaRIVA-VTNT2, 16MB @ 0xD0000000) Jan 18 14:44:10 TBird kernel: Return OK from rivafb_probe() Jan 18 14:44:10 TBird kernel: About to pci_register_driver() in rivafb_in= it() Jan 18 14:44:10 TBird kernel: Badness in kobject_register at lib/kobject.= c:152 Jan 18 14:44:10 TBird kernel: Call Trace: Jan 18 14:44:10 TBird kernel: [<d08d17b4>] rivafb_driver+0x54/0xfffe0918= [rivafb] Jan 18 14:44:10 TBird kernel: [<c01d1436>] kobject_register+0x56/0x60 Jan 18 14:44:10 TBird kernel: [<d08d17a4>] rivafb_driver+0x44/0xfffe0918= [rivafb] Jan 18 14:44:10 TBird kernel: [<c0202707>] bus_add_driver+0x57/0xf0 Jan 18 14:44:10 TBird kernel: [<d08d17a4>] rivafb_driver+0x44/0xfffe0918= [rivafb] Jan 18 14:44:10 TBird kernel: [<c0202b91>] driver_register+0x31/0x40 Jan 18 14:44:10 TBird kernel: [<d08d1788>] rivafb_driver+0x28/0xfffe0918= [rivafb] Jan 18 14:44:10 TBird kernel: [<c01d5ae9>] pci_register_driver+0x49/0x60 Jan 18 14:44:10 TBird kernel: [<d08d1788>] rivafb_driver+0x28/0xfffe0918= [rivafb] Jan 18 14:44:10 TBird kernel: [<d08b204a>] +0x4a/0x68 [rivafb] Jan 18 14:44:10 TBird kernel: [<d08d1760>] rivafb_driver+0x0/0xfffe0918 = [rivafb] Jan 18 14:44:10 TBird kernel: [<d08d3100>] +0x0/0xfffdef78 [rivafb] Jan 18 14:44:10 TBird kernel: [<c0133e07>] sys_init_module+0x117/0x1c0 Jan 18 14:44:10 TBird kernel: [<c010a393>] syscall_call+0x7/0xb =09=09=09=09Thanks, =09=09=09=09=09=09Jak. On Wednesday 15 January 2003 00:43, James Simmons wrote: > Can you try the latest pacth at > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz |
From: Antonino D. <ad...@po...> - 2003-01-19 15:51:14
|
On Sun, 2003-01-19 at 04:28, Jak wrote: > > James, > I still see the same problem using 2.5.59. I think this > is the same problem as that referred to by Udo A. Steinberg > http://marc.theaimsgroup.com/?l=linux-kernel&m=104278873827538&w=2 > ( I get similar results as him if I compile rivafb built-in ) > > Is this possibly related to driver-model issues discussed in this thread ? > http://marc.theaimsgroup.com/?l=linux-kernel&m=104283662023857&w=2 > > Good news is that 2.5.59 seems quite stable as regards framebuffer. > It no longer locks up after loading fbcon. But rmmod fbcon still > causes instant death accompanied by increased whirring noises from inside > box. > > To summarise: > insmod rivafb causes "Badness in kobject_register" every time > ( after pci_register_driver() in rivafb_init(),see below ) > after insmod rivafb, I have a green screen, which can be cleared by fbset > ( fbset now changes resolution of all VTs, this is different from 2.4.x ) The green screen is expected because the driver partly initializes the hardware (in riva_common_setup()). Running fbset() will complete the initialization, but... > after clearing green screen using fbset, text colours are wrong ...unfortunately, upon exit, the driver restores only the partly initialized state, thus the vga console text colors are wrong. > now ( 2.5.59 ), I can insmod fbcon, and screen looks OK again ( apart from When fbcon is loaded, it goes to graphics mode, so the screen should look okay. > the left-hand-most column of screen appears at right-hand side of screen ) Try running stty to fix your display. > rmmod fbcon locks up machine, no ALT-SYSRQ effective This is wishful thinking :-), as fbcon cannot be unloaded (yet). James, Calling riva_common_setup() calls RivaGetConfig() which modifies the hardware. Since we only need fix->smem_len and the bandwidth from RivaGetConfig(), I isolated them into riva_get_memlen() and riva_get_maxdclk(). RivaGetConfig will be called from rivafb_open() anyway. So can you and Jak try the attached patch? It should prevent VGA console corruption on insmod and it should eliminate the kobject trace messages. Diff is against 2.5.59. Tony diff -Naur linux-2.5.59/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c --- linux-2.5.59/drivers/video/riva/fbdev.c 2003-01-19 15:24:14.000000000 +0000 +++ linux/drivers/video/riva/fbdev.c 2003-01-19 15:23:18.000000000 +0000 @@ -150,7 +150,7 @@ static struct riva_chip_info { const char *name; unsigned arch_rev; -} riva_chip_info[] __devinitdata = { +} riva_chip_info[] __initdata = { { "RIVA-128", NV_ARCH_03 }, { "RIVA-TNT", NV_ARCH_04 }, { "RIVA-TNT2", NV_ARCH_04 }, @@ -193,7 +193,7 @@ { "Quadro4-700-XGL", NV_ARCH_20 } }; -static struct pci_device_id rivafb_pci_tbl[] __devinitdata = { +static struct pci_device_id rivafb_pci_tbl[] __initdata = { { PCI_VENDOR_ID_NVIDIA_SGS, PCI_DEVICE_ID_NVIDIA_SGS_RIVA128, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_RIVA_128 }, { PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_TNT, @@ -1543,7 +1543,7 @@ .fb_sync = rivafb_sync, }; -static int __devinit riva_set_fbinfo(struct fb_info *info) +static int __init riva_set_fbinfo(struct fb_info *info) { struct riva_par *par = (struct riva_par *) info->par; unsigned int cmap_len; @@ -1689,8 +1689,8 @@ * * ------------------------------------------------------------------------- */ -static int __devinit rivafb_probe(struct pci_dev *pd, - const struct pci_device_id *ent) +static int __init rivafb_probe(struct pci_dev *pd, + const struct pci_device_id *ent) { struct riva_chip_info *rci = &riva_chip_info[ent->driver_data]; struct riva_par *default_par; @@ -1788,8 +1788,8 @@ default_par->riva.PCRTC = default_par->riva.PCRTC0 = default_par->riva.PGRAPH; } - rivafb_fix.smem_len = default_par->riva.RamAmountKBytes * 1024; - default_par->dclk_max = default_par->riva.MaxVClockFreqKHz * 1000; + rivafb_fix.smem_len = riva_get_memlen(default_par) * 1024; + default_par->dclk_max = riva_get_maxdclk(default_par) * 1000; if (!request_mem_region(rivafb_fix.smem_start, rivafb_fix.smem_len, "rivafb")) { @@ -1819,12 +1819,6 @@ } #endif /* CONFIG_MTRR */ - /* unlock io */ - CRTCout(default_par, 0x11, 0xFF);/* vgaHWunlock() + riva unlock (0x7F) */ - default_par->riva.LockUnlock(&default_par->riva, 0); - - riva_save_state(default_par, &default_par->initial_state); - if (riva_set_fbinfo(info) < 0) { printk(KERN_ERR PFX "error setting initial video mode\n"); goto err_out_load_state; @@ -1869,7 +1863,7 @@ return -ENODEV; } -static void __devexit rivafb_remove(struct pci_dev *pd) +static void __exit rivafb_remove(struct pci_dev *pd) { struct fb_info *info = pci_get_drvdata(pd); struct riva_par *par = (struct riva_par *) info->par; @@ -1877,8 +1871,6 @@ if (!info) return; - riva_load_state(par, &par->initial_state); - unregister_framebuffer(info); #ifdef CONFIG_MTRR @@ -1948,7 +1940,7 @@ name: "rivafb", id_table: rivafb_pci_tbl, probe: rivafb_probe, - remove: __devexit_p(rivafb_remove), + remove: __exit_p(rivafb_remove), }; @@ -1961,12 +1953,7 @@ int __init rivafb_init(void) { - int err; - err = pci_module_init(&rivafb_driver); - if (err) - return err; - pci_register_driver(&rivafb_driver); - return 0; + return pci_module_init(&rivafb_driver); } diff -Naur linux-2.5.59/drivers/video/riva/nv_driver.c linux/drivers/video/riva/nv_driver.c --- linux-2.5.59/drivers/video/riva/nv_driver.c 2003-01-19 15:24:14.000000000 +0000 +++ linux/drivers/video/riva/nv_driver.c 2003-01-19 15:23:18.000000000 +0000 @@ -35,6 +35,7 @@ 5 20:47:06 mvojkovi Exp $ */ #include <linux/delay.h> +#include <linux/pci.h> #include <linux/pci_ids.h> #include "nv_type.h" #include "rivafb.h" @@ -133,6 +134,159 @@ riva_override_CRTC(par); } +unsigned long riva_get_memlen(struct riva_par *par) +{ + RIVA_HW_INST *chip = &par->riva; + unsigned long memlen = 0; + unsigned int chipset = par->Chipset; + struct pci_dev* dev; + int amt; + + switch (chip->Architecture) { + case NV_ARCH_03: + if (chip->PFB[0x00000000/4] & 0x00000020) { + if (((chip->PMC[0x00000000/4] & 0xF0) == 0x20) + && ((chip->PMC[0x00000000/4] & 0x0F) >= 0x02)) { + /* + * SDRAM 128 ZX. + */ + switch (chip->PFB[0x00000000/4] & 0x03) { + case 2: + memlen = 1024 * 4; + break; + case 1: + memlen = 1024 * 2; + break; + default: + memlen = 1024 * 8; + break; + } + } else { + memlen = 1024 * 8; + } + } else { + /* + * SGRAM 128. + */ + switch (chip->PFB[0x00000000/4] & 0x00000003) { + case 0: + memlen = 1024 * 8; + break; + case 2: + memlen = 1024 * 4; + break; + default: + memlen = 1024 * 2; + break; + } + } + break; + case NV_ARCH_04: + if (chip->PFB[0x00000000/4] & 0x00000100) { + memlen = ((chip->PFB[0x00000000/4] >> 12) & 0x0F) * + 1024 * 2 + 1024 * 2; + } else { + switch (chip->PFB[0x00000000/4] & 0x00000003) { + case 0: + memlen = 1024 * 32; + break; + case 1: + memlen = 1024 * 4; + break; + case 2: + memlen = 1024 * 8; + break; + case 3: + default: + memlen = 1024 * 16; + break; + } + } + break; + case NV_ARCH_10: + case NV_ARCH_20: + if(chipset == NV_CHIP_IGEFORCE2) { + + dev = pci_find_slot(0, 1); + pci_read_config_dword(dev, 0x7C, &amt); + memlen = (((amt >> 6) & 31) + 1) * 1024; + } else if (chipset == NV_CHIP_0x01F0) { + dev = pci_find_slot(0, 1); + pci_read_config_dword(dev, 0x84, &amt); + memlen = (((amt >> 4) & 127) + 1) * 1024; + } else { + switch ((chip->PFB[0x0000020C/4] >> 20) & 0x000000FF){ + case 0x02: + memlen = 1024 * 2; + break; + case 0x04: + memlen = 1024 * 4; + break; + case 0x08: + memlen = 1024 * 8; + break; + case 0x10: + memlen = 1024 * 16; + break; + case 0x20: + memlen = 1024 * 32; + break; + case 0x40: + memlen = 1024 * 64; + break; + case 0x80: + memlen = 1024 * 128; + break; + default: + memlen = 1024 * 16; + break; + } + } + break; + } + return memlen; +} + +unsigned long riva_get_maxdclk(struct riva_par *par) +{ + RIVA_HW_INST *chip = &par->riva; + unsigned long dclk = 0; + + switch (chip->Architecture) { + case NV_ARCH_03: + if (chip->PFB[0x00000000/4] & 0x00000020) { + if (((chip->PMC[0x00000000/4] & 0xF0) == 0x20) + && ((chip->PMC[0x00000000/4] & 0x0F) >= 0x02)) { + /* + * SDRAM 128 ZX. + */ + dclk = 800000; + } else { + dclk = 1000000; + } + } else { + /* + * SGRAM 128. + */ + dclk = 1000000; + } + break; + case NV_ARCH_04: + case NV_ARCH_10: + case NV_ARCH_20: + switch ((chip->PFB[0x00000000/4] >> 3) & 0x00000003) { + case 3: + dclk = 800000; + break; + default: + dclk = 1000000; + break; + } + break; + } + return dclk; +} + void riva_common_setup(struct riva_par *par) { diff -Naur linux-2.5.59/drivers/video/riva/rivafb.h linux/drivers/video/riva/rivafb.h --- linux-2.5.59/drivers/video/riva/rivafb.h 2003-01-19 15:24:17.000000000 +0000 +++ linux/drivers/video/riva/rivafb.h 2003-01-19 15:23:20.000000000 +0000 @@ -55,5 +55,7 @@ }; void riva_common_setup(struct riva_par *); +unsigned long riva_get_memlen(struct riva_par *); +unsigned long riva_get_maxdclk(struct riva_par *); #endif /* __RIVAFB_H */ |
From: James S. <jsi...@in...> - 2003-01-24 20:16:06
|
> > after clearing green screen using fbset, text colours are wrong > ...unfortunately, upon exit, the driver restores only the partly > initialized state, thus the vga console text colors are wrong. We should move the riva_load_state(par->initial_state) in riavfb_remove to rivafb_release. > > rmmod fbcon locks up machine, no ALT-SYSRQ effective > This is wishful thinking :-), as fbcon cannot be unloaded (yet). It works if you have more than one type of VT console system. I use MDA console with FB console. This way I can add and remove fbcon.o at will and test it in detail. > Calling riva_common_setup() calls RivaGetConfig() which modifies the > hardware. Since we only need fix->smem_len and the bandwidth from > RivaGetConfig(), I isolated them into riva_get_memlen() and > riva_get_maxdclk(). RivaGetConfig will be called from rivafb_open() > anyway. I applied part of the patch. I like to avoid changing nv_driver to much because it is based on the X windows driver. Easier to keep them sync. What we could do is move the following riva_common_setup(par); .. par->dclk_max = par->riva.MaxVClock.. from rivafb_probe to riavfb_open. Can you give tht a try and tell me if it works. |
From: Antonino D. <ad...@po...> - 2003-01-30 23:14:39
|
On Sat, 2003-01-25 at 04:14, James Simmons wrote: > > I applied part of the patch. I like to avoid changing nv_driver to much > because it is based on the X windows driver. Easier to keep them sync. > What we could do is move the following > > riva_common_setup(par); > .. > > par->dclk_max = par->riva.MaxVClock.. > > from rivafb_probe to riavfb_open. Can you give tht a try and tell me if it > works. > I haven't tried this yet, but I think it will work. The only (very minor) problem with this is the rivafb's printk output will be incorrect (no info on video memory size). Tony |
From: James S. <jsi...@in...> - 2003-02-12 20:16:14
|
> > from rivafb_probe to riavfb_open. Can you give tht a try and tell me if it > > works. > > > > I haven't tried this yet, but I think it will work. The only (very > minor) problem with this is the rivafb's printk output will be incorrect > (no info on video memory size). True. All to keep in sync with X :-( Maybe we should break nv_driver.c syncing since it already has been altered. Hell with it. Could you update a patch with seperate functions for memsize clock finding. |
From: Antonino D. <ad...@po...> - 2003-02-12 23:37:28
|
On Thu, 2003-02-13 at 04:15, James Simmons wrote: > > > > from rivafb_probe to riavfb_open. Can you give tht a try and tell me if it > > > works. > > > > > > > I haven't tried this yet, but I think it will work. The only (very > > minor) problem with this is the rivafb's printk output will be incorrect > > (no info on video memory size). > > True. All to keep in sync with X :-( Maybe we should break nv_driver.c > syncing since it already has been altered. Hell with it. Could you update > a patch with seperate functions for memsize clock finding. > Will do once you provide an updated patch I can diff against. Tony |
From: James S. <jsi...@in...> - 2003-01-24 19:10:40
|
> Good news is that 2.5.59 seems quite stable as regards framebuffer. > It no longer locks up after loading fbcon. But rmmod fbcon still > causes instant death accompanied by increased whirring noises from inside > box. rmmod is really broken for fbcon. It shuts down the VT console system. It needs work in this area. |
From: Jak <rf...@ei...> - 2003-01-20 19:05:44
|
Tony, =09thanks for your patches, they have fixed most of the problems I had. > > Try running stty to fix your display. > I can't convince stty to do anything useful for me : =09do I need a specific/patched version ? =09do I need to specify anything except rows cols values ? =09how would I change the colour depth ? =09I have 7 different lines in /etc/fb.modes related to 1024x768@8bpp, how can I tell stty that I want to use the equivalent of the timing value= s of any particular one of these 7 modes ( assuming timings are still relevant= ) ? =09what was wrong with fbset which I have to keep for the forseeable future anyway until 2.6 approaches 2.4 reliability ? > > So can you and Jak try the attached patch? It should prevent VGA > console corruption on insmod and it should eliminate the kobject trace > messages. > Using your 3 recent patches together clears up the green screen problem and text corruption as well as kobject "badness". > int __init rivafb_init(void) > { > -=09int err; > -=09err =3D pci_module_init(&rivafb_driver); > -=09if (err) > -=09=09return err; > -=09pci_register_driver(&rivafb_driver); > -=09return 0; > +=09return pci_module_init(&rivafb_driver); > } > This will normally return 1, not 0 as before. Is this intended ? |
From: Antonino D. <ad...@po...> - 2003-01-20 22:54:13
|
On Tue, 2003-01-21 at 03:09, Jak wrote: > Tony, > thanks for your patches, they have fixed most of the problems I had. > > > > Try running stty to fix your display. > > > I can't convince stty to do anything useful for me : > do I need a specific/patched version ? No. > do I need to specify anything except rows cols values ? No. > how would I change the colour depth ? You can still use fbset :-), except that as it currently stands, it might corrupt the display if panning is enabled. rivafb does not support panning at bootup so fbset is safe to use. > I have 7 different lines in /etc/fb.modes related to 1024x768@8bpp, > how can I tell stty that I want to use the equivalent of the timing values of > any particular one of these 7 modes ( assuming timings are still relevant ) ? Bullseye :-) This is one of the reasons I submitted the GTF implementation patch (It's already in fbmon.c). The patch will compute the modelines for you given xres, yres and your monitor's operational limits. It has the advantage of computing the maximum refresh rate your monitor is capable of, and it can theoretically calculate any mode without the use of additional entries in /etc/fb.modes. This is ideal for VESA GTF compliant monitors but I have tested this with old monitors as well. Once you have changed to an appropriate window size, you can then use fbset to fine-tune your display timings. The only problem right now is how do you pass the monitor info to the driver? The best way is to parse the EDID block and use I2C/DDC. Personally, I think passing the monitor info as a boot/module option is the simplest and safest method. Once the above is done, adding support for GTF to a driver is just a 10-liner code. I already did this for some of the drivers including rivafb. Of course, proprietary displays will need their own modeline formula which, if this is the case, the driver has to add its own algorithm or use fbset tricks. You can do something like this: fbset 1600x1200-85 && stty cols 200 rows 75 > what was wrong with fbset which I have to keep for the forseeable > future anyway until 2.6 approaches 2.4 reliability ? Nothing's wrong with fbset, because if fbset becomes unusable, then so will most fbdev-based applications. We don't want that to happen. The main difference is instead of fbdev telling the console to change the window size, it's now the console telling fbdev to change the window size. As the console is blind to color depth, pixelformat, accel, etc, you can still use fbset to change most of the above. > > > > So can you and Jak try the attached patch? It should prevent VGA > > console corruption on insmod and it should eliminate the kobject trace > > messages. > > > Using your 3 recent patches together clears up the green screen problem > and text corruption as well as kobject "badness". > > > int __init rivafb_init(void) > > { > > - int err; > > - err = pci_module_init(&rivafb_driver); > > - if (err) > > - return err; > > - pci_register_driver(&rivafb_driver); > > - return 0; > > + return pci_module_init(&rivafb_driver); > > } > > > This will normally return 1, not 0 as before. Is this intended ? The above should return 0 if successful. Tony |
From: Geert U. <ge...@li...> - 2003-01-21 10:31:19
|
On 21 Jan 2003, Antonino Daplas wrote: > The only problem right now is how do you pass the monitor info to the > driver? The best way is to parse the EDID block and use I2C/DDC. > Personally, I think passing the monitor info as a boot/module option is > the simplest and safest method. Through sysfs? echo MY_MONITOR_LIMITS > /proc/...? Since ioctls are considered evil these days, changing the resolution etc. could work in a similar way as well. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Antonino D. <ad...@po...> - 2003-01-21 11:41:22
|
On Tue, 2003-01-21 at 18:29, Geert Uytterhoeven wrote: > On 21 Jan 2003, Antonino Daplas wrote: > > The only problem right now is how do you pass the monitor info to the > > driver? The best way is to parse the EDID block and use I2C/DDC. > > Personally, I think passing the monitor info as a boot/module option is > > the simplest and safest method. > > Through sysfs? echo MY_MONITOR_LIMITS > /proc/...? > > Since ioctls are considered evil these days, changing the resolution etc. could > work in a similar way as well. > True, but I prefer having the monitor limits at driver load time so I can immediately go into a high resolution. Tony |
From: James S. <jsi...@in...> - 2003-01-24 22:54:46
|
> > The only problem right now is how do you pass the monitor info to the > > driver? The best way is to parse the EDID block and use I2C/DDC. > > Personally, I think passing the monitor info as a boot/module option is > > the simplest and safest method. > > Through sysfs? echo MY_MONITOR_LIMITS > /proc/...? > > Since ioctls are considered evil these days, changing the resolution etc. could > work in a similar way as well. Can you do this with sysfs? This is what I have been waiting for!!! The proc thing is don't care for tho. |
From: Geert U. <ge...@li...> - 2003-01-25 09:02:16
|
On Fri, 24 Jan 2003, James Simmons wrote: > > > The only problem right now is how do you pass the monitor info to the > > > driver? The best way is to parse the EDID block and use I2C/DDC. > > > Personally, I think passing the monitor info as a boot/module option is > > > the simplest and safest method. > > > > Through sysfs? echo MY_MONITOR_LIMITS > /proc/...? > > > > Since ioctls are considered evil these days, changing the resolution etc. could > > work in a similar way as well. > > Can you do this with sysfs? This is what I have been waiting for!!! The > proc thing is don't care for tho. Yes, you can create a fbdev filesystem, which shows frame buffers and information about them. By changing the contents of those virtual files (e.g. a file that corresponds to struct fb_var_screeninfo), you can change the video mode. This can also solve the burden of maintaining backwards compatibility in struct fb_var_screeninfo. You want a new field? Just add a new virtual file to the filesystem. One thing I'm still wondering about is how to keep things synchronized. You don't want to put all fields of struct fb_var_screeninfo in one file, you want separate files for resolution, timings, .... But in the end you usually want to change a video mode by changing all parameters at once, so you want the changes to the different virtual files to be synchronized. Perhaps some lock file? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Antonino D. <ad...@po...> - 2003-01-30 23:14:14
|
On Sat, 2003-01-25 at 17:00, Geert Uytterhoeven wrote: > On Fri, 24 Jan 2003, James Simmons wrote: > > > > The only problem right now is how do you pass the monitor info to the > > > > driver? The best way is to parse the EDID block and use I2C/DDC. > > > > Personally, I think passing the monitor info as a boot/module option is > > > > the simplest and safest method. > > > > > > Through sysfs? echo MY_MONITOR_LIMITS > /proc/...? > > > > > > Since ioctls are considered evil these days, changing the resolution etc. could > > > work in a similar way as well. > > > > Can you do this with sysfs? This is what I have been waiting for!!! The > > proc thing is don't care for tho. > > Yes, you can create a fbdev filesystem, which shows frame buffers and > information about them. By changing the contents of those virtual files (e.g. a > file that corresponds to struct fb_var_screeninfo), you can change the video > mode. This can also solve the burden of maintaining backwards compatibility in > struct fb_var_screeninfo. You want a new field? Just add a new virtual file to > the filesystem. > > One thing I'm still wondering about is how to keep things synchronized. You > don't want to put all fields of struct fb_var_screeninfo in one file, you want > separate files for resolution, timings, .... But in the end you usually want to > change a video mode by changing all parameters at once, so you want the changes > to the different virtual files to be synchronized. Perhaps some lock file? > >From what I understand about sysfs, you can only have one type per file, so each field will have to be in separate files. To synchronize, we can perhaps use a file ('sync', 'lock', 'update' or whatever) which is similar in function to fb_var_screeninfo.activate. Only when the user writes to this file that the new settings are synchronized and we call fb_set_var() or whatever. How do you think sysfs support will be written? Will this mean that the framebuffer system has to register its own kobject as the top level entry in sysfs, no? This would also mean that we need something similar for the console subsystem if it has to support additional features, ie rotation? Tony |
From: James S. <jsi...@in...> - 2003-02-12 20:14:31
|
> >From what I understand about sysfs, you can only have one type per file, > so each field will have to be in separate files. Correct. > To synchronize, we can > perhaps use a file ('sync', 'lock', 'update' or whatever) which is > similar in function to fb_var_screeninfo.activate. Only when the user > writes to this file that the new settings are synchronized and we call > fb_set_var() or whatever. This doesn't bother me. I cna live with that. Actually it is a good idea to do it that way. THis way if we have graphics clients we can invalidate them when switch the entire graphics state. The accel engine will switch behavior on changing the video mode. > How do you think sysfs support will be written? Will this mean that the > framebuffer system has to register its own kobject as the top level > entry in sysfs, no? I think so. I haven't looked down this aveue yet. This is a latter time project. > This would also mean that we need something similar > for the console subsystem if it has to support additional features, ie > rotation? I'm not to thrilled about this idea. |
From: Antonino D. <ad...@po...> - 2003-01-21 00:18:06
|
On Tue, 2003-01-21 at 03:09, Jak wrote: > > > int __init rivafb_init(void) > > { > > - int err; > > - err = pci_module_init(&rivafb_driver); > > - if (err) > > - return err; > > - pci_register_driver(&rivafb_driver); > > - return 0; > > + return pci_module_init(&rivafb_driver); > > } > > Hmm, come to think of it, pci_module_init() is old-style. Using return (pci_register_driver(&rivafb_driver) > 0) ? 0 : -ENODEV; instead is better and will allow the rivafb driver to appear in sysfs. Anyway, pci_module_init() should not be called since pci_register_driver() already does that for you. That's what causing the "Badness" in kobject. Tony |