Hi!

I hope the fbdev list is still in use. I have just been experimenting
with using my old S3ViRGE PCI card in my Sun Blade 2000 as its primary
display adapter has no X11 driver available for it. 

I put the card into my SPARC and booted up, after compiling in the s3fb
driver into the kernel. 

On boot-up, it uses the e3d framebuffer driver, and detects the s3fb
card but ignores it as seen in dmesg:

s3fb 0000:00:03.0: ignoring secondary device

I then pulled out the primary graphic card (XVR-500) and rebooted. I got
the following lines in dmesg:

vgaarb: device added: PCI:0000:00:03.0,decodes=io
+mem,owns=mem,locks=none
vgaarb: loaded
s3fb 0000:00:03.0: ignoring secondary device

It seems a bit odd that it is still ignoring the S3ViRGE card given that
it is now the only graphic adapter in the system. 

I then commented out the following code in drivers/video/s3fb.c:

      if (! svga_primary_device(dev)) {
                dev_info(&(dev->dev), "ignoring secondary device\n");
                return -ENODEV;
        }

and rebooted. 

It got as far as the switching to console device before it hung. 

I'm aware the s3fb driver has big endian issues, I can help fix those
issues so I can get the card working. Or in other words, I'd welcome
advice on how to proceed with this. 

Thanks!
-- 
Tactical Nuclear Kittens
--

[ message continues ]

From: Alex Buell <alex.buell@munted.org.uk>

It's not endian issues, this driver has other problems.

It uses the VGA register accessors with a NULL regbase, which is not
going to work on sparc64.

It needs to access the VGA register space relative to the I/O space
of the PCI controller domain it is behind.

Probably if you replace the NULL values passes to vga_r*() and
vga_w*() with the I/O space resource base of the chip (should be
resource "1") it might work.
--

[ message continues ]

I've had a look at linux/include/video/vga.h, and yes I see what you
mean now.

Secondly, is Linux fully capable of handling different graphic cards
simultaneously? For example, plug in a pair of monitors and have
consoles on both with disparate graphic cards i.e. XVR-500 and S3ViRGE
etc? 
-- 
Tactical Nuclear Kittens
--

[ message continues ]

From: Alex Buell <alex.buell@munted.org.uk>

Technically I don't think it can do it currently.  Maybe just for
kernel message logging, but not for actual login consoles.

One TTY device is marked as the "console" and that's where all
tty[0-9]+ devices get instantiated upon.
--

[ message continues ]

Hmm, maybe it would be nice to introduce that capability. How doable
would it be? I understand the BKL is going away, perhaps it would now be
easier to introduce such a facility?

I've just started digging into the innards of the s3fb driver, my first
attempt provoked this, simply by commenting out the check to see if it's
not the primary device and exits with -ENODEV: 

Jan  3 20:16:29 sodium kernel: ERROR(1): Cheetah error trap taken
afsr[0030100000000000] afar[00000000000003d0] TL1(0)
Jan  3 20:16:29 sodium kernel: ERROR(1): TPC[105918d8] TNPC[105918dc]
O7[10591884] TSTATE[4411001606]
Jan  3 20:16:29 sodium kernel: ERROR(1): TPC<s3_pci_probe+0x194/0x63c
[s3fb]>
Jan  3 20:16:29 sodium kernel: ERROR(1): M_SYND(0),  E_SYND(0), Multiple
Errors, Privileged
Jan  3 20:16:29 sodium kernel: ERROR(1): Highest priority error
(0000100000000000) "Unmapped error from system bus"
Jan  3 20:16:29 sodium kernel: ERROR(1): D-cache idx[0]
tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
Jan  3 20:16:29 sodium kernel: ERROR(1): D-cache data0[0000000000000000]
data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
Jan  3 20:16:29 sodium kernel: ERROR(1): I-cache idx[0]
tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
u[0000000000000000] l[0000000000000000]
Jan  3 20:16:29 sodium kernel: ERROR(1): I-cache INSN0[0000000000000000]
INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
Jan  3 20:16:29 sodium kernel: ERROR(1): I-cache INSN4[0000000000000000]
INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
Jan  3 20:16:29 sodium kernel: ERROR(1): E-cache idx[3c0]
tag[000000000b040000]
Jan  3 20:16:29 sodium kernel: ERROR(1): E-cache data0[000c5aa000000011]
data1[000f43d800000040] data2[0000000000000109] data3[0000000000000000]
Jan  3 20:16:29 sodium kernel: Kernel panic - not syncing: Irrecoverable
deferred error trap.

Heh. ;)
-- 
Tactical Nuclear Kittens
--

[ message continues ]

From: Alex Buell <alex.buell@munted.org.uk>


I know, this is what happens if you call vga_*() with a NULL first parameter
on sparc64.  It's accessing garbage addresses.
--

[ message continues ]

OK. 

 # lspci -vvxx -s 0:0:03
0000:00:03.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01)
(prog-if 00 [VGA controller])
        Subsystem: S3 Inc. ViRGE/DX
        Physical Slot: PCI 3
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 23
        Region 0: Memory at 14000000 (32-bit, non-prefetchable)
[size=64M]
        Region 1: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
        Region 2: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
        Region 3: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
        Region 4: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
        Region 5: [virtual] Memory at fffff80200000000 (32-bit,
non-prefetchable) [size=1]
        Expansion ROM at 00130000 [disabled] [size=64K]
        Kernel driver in use: s3fb
        Kernel modules: s3fb
00: 33 53 01 8a 02 00 00 02 01 00 00 03 00 40 00 00
10: 00 00 00 14 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 33 53 01 8a
30: 00 00 13 00 00 00 00 00 00 00 00 00 00 01 04 ff

Those are 32 bit addresses, so I suppose I should be getting the base
address for the registers accesses from region 1, right? 
-- 
Tactical Nuclear Kittens
--

[ message continues ]

From: Alex Buell <alex.buell@munted.org.uk>

Yes, and pre-computed addresses exist in pci_region_start(pdev, 1).
--

[ message continues ]

Do you have any tips for reducing the amount of reboots I have to do
whenever I try loading the s3fb module after changing code? 
-- 
Tactical Nuclear Kittens
--

[ message continues ]

From: Alex Buell <alex.buell@munted.org.uk>

You should build s3fb as a module, block it from auto-loading in
/etc/modules.conf, and then load it explicitly by hand as you
make changes and recompile.
--

[ message continues ]

I'm already doing that. In the instances where it results in a crash and
reboots are impossible, dropping into the OpenPROM results in a total
system freeze, cannot type anything in, this means a big red switch
time. Solaris didn't have this problem. Any ideas why Linux does this to
the OpenPROM? 
-- 
Tactical Nuclear Kittens
--

[ message continues ]

From: Alex Buell <alex.buell@munted.org.uk>

First of all, the machine dies because those illegal I/O accesses
generate an unrecoverable asynchronous memory error, we cannot recover
from it so we have to panic the entire machine.

Secondly, the keyboard doesn't work because I never implemented the
monstrous amount of code necessary to allow USB keyboard to work with
OpenPROM after booting up.

You have to essentially reset the entire USB host controller, unload
all of the pending queued URBs in the host controller, put it into a
quiescent state, and then asynchronously process all USB keyboard
device events via USB host controller polling implemented via OpenPROM
backcalls into the kernel, and from there feed the characters to
OpenPROM so it can see the keypresses.  Upon return from OpenPROM you
have to reload all of the unloaded URBs back onto the USB host
controller queues so the kernel can use USB again.

I never considered this enormous amount of work worth doing, the
payback is just too small.
--

[ message continues ]

Thank you for that explanation, it's much appreciated.
-- 
Tactical Nuclear Kittens
--

[ message continues ]

Not currently, since you would also need some way to sanely route input.

You can put different VTs on different consoles but thats about it.

Dave.
--

[ message continues ]