dual head r128

dual head r128

[Josh Huber]

[-- Attachment #1.1: Type: text/plain, Size: 567 bytes --]

Anyone got dual head r128 up and running on ppc?  I've got a dual G4
system here (running a UP kernel for now), with the shipped AGP r128
card, and another PCI (pc, no fcode) r128 card.

The relevant information is attached, lspci -vv, XF86Config, and the
log of the failed X startup.  X works with just the AGP card, as
expected.

Of note is the:
c000:00b9: 63 ILLEGAL X86 OPCODE!

line in x.log, when trying to run int10 on the secondary card.

Thanks,
-- 
Josh
| huber@mclx.com |
1024D/6B21489A 61F0 6138 BE7B FEBF A223  E9D1 BFE1 2065 6B21 489A

[-- Attachment #1.2: XF86Config.new --]
[-- Type: text/plain, Size: 3214 bytes --]

Section "ServerLayout"
	Identifier     "XFree86 Configured"
	Screen      0  "Screen0" 0 0
	Screen      1  "Screen1" RightOf "Screen0"
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
EndSection

Section "Module"
	Load  "extmod"
	Load  "xie"
	Load  "pex5"
	Load  "glx"
	Load  "dri"
	Load  "GLcore"
	Load  "dbe"
	Load  "record"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "keyboard"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option      "Protocol" "IMPS/2"
	Option      "Device" "/dev/usbmouse"
EndSection

Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "Monitor Vendor"
	ModelName    "Monitor Model"
EndSection

Section "Monitor"
	Identifier   "Monitor1"
	VendorName   "Monitor Vendor"
	ModelName    "Monitor Model"
EndSection

Section "Device"
	### Available Driver options are:-
        #Option     "NoAccel"
        #Option     "SWcursor"
        #Option     "HWcursor"
        #Option     "Dac6Bit"
        #Option     "Dac8Bit"
        #Option     "ForcePCIMode"
        #Option     "CCEPIOMode"
        #Option     "CCENoSecurity"
        #Option     "CCEusecTimeout"
        #Option     "AGPMode"
        #Option     "AGPSize"
        #Option     "RingSize"
        #Option     "VBListSize"
        #Option     "VBSize"
        #Option     "UseCCEfor2D"
        #Option     "EnableFP"
        #Option     "CRTOnly"
        #Option     "UseFBDev"
	Identifier  "Card0"
	Driver      "r128"
	VendorName  "ATI"
	BoardName   "Rage 128 Pro PF"
	BusID       "PCI:0:16:0"
EndSection

Section "Device"
	### Available Driver options are:-
        #Option     "NoAccel"
        #Option     "SWcursor"
        #Option     "HWcursor"
        #Option     "Dac6Bit"
        #Option     "Dac8Bit"
        #Option     "ForcePCIMode"
        #Option     "CCEPIOMode"
        #Option     "CCENoSecurity"
        #Option     "CCEusecTimeout"
        #Option     "AGPMode"
        #Option     "AGPSize"
        #Option     "RingSize"
        #Option     "VBListSize"
        #Option     "VBSize"
        #Option     "UseCCEfor2D"
        #Option     "EnableFP"
        #Option     "CRTOnly"
        #Option     "UseFBDev"
	VideoRam    8192
	Identifier  "Card1"
	Driver      "r128"
	VendorName  "ATI"
	BoardName   "Rage 128 RE"
	BusID       "PCI:1:2:0"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Card0"
	Monitor    "Monitor0"
	SubSection "Display"
		Depth     1
	EndSubSection
	SubSection "Display"
		Depth     4
	EndSubSection
	SubSection "Display"
		Depth     8
	EndSubSection
	SubSection "Display"
		Depth     15
	EndSubSection
	SubSection "Display"
		Depth     16
	EndSubSection
	SubSection "Display"
		Depth     24
	EndSubSection
EndSection

Section "Screen"
	Identifier "Screen1"
	Device     "Card1"
	Monitor    "Monitor1"
	SubSection "Display"
		Depth     1
	EndSubSection
	SubSection "Display"
		Depth     4
	EndSubSection
	SubSection "Display"
		Depth     8
	EndSubSection
	SubSection "Display"
		Depth     15
	EndSubSection
	SubSection "Display"
		Depth     16
	EndSubSection
	SubSection "Display"
		Depth     24
	EndSubSection
EndSection

Section "DRI"
EndSection

[-- Attachment #1.3: lspci.out --]
[-- Type: text/plain, Size: 4874 bytes --]

00:0b.0 Host bridge: Apple Computer Inc.: Unknown device 0020
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 16 set, cache line size 08
	Capabilities: [80] AGP version 1.0
		Status: RQ=7 SBA+ 64bit- FW- Rate=21
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=

00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 set, cache line size 08
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 00001000-00001fff
	Memory behind bridge: 80000000-87ffffff
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- AuxPwr- DSI- D1- D2- PME-
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:10.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF (prog-if 00 [VGA])
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 8 min, 255 set, cache line size 08
	Interrupt: pin A routed to IRQ 48
	Region 0: Memory at 94000000 (32-bit, prefetchable)
	Region 1: I/O ports at 0400 [disabled]
	Region 2: Memory at 90000000 (32-bit, non-prefetchable)
	Expansion ROM at 90020000 [disabled]
	Capabilities: [50] AGP version 2.0
		Status: RQ=31 SBA+ 64bit- FW- Rate=421
		Command: RQ=0 SBA+ AGP- 64bit- FW- Rate=
	Capabilities: [5c] Power Management version 2
		Flags: PMEClk- AuxPwr- DSI- D1+ D2- PME-
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:02.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE (prog-if 00 [VGA])
	Subsystem: ATI Technologies Inc: Unknown device 0008
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 8 min, 16 set, cache line size 08
	Interrupt: pin A routed to IRQ 52
	Region 0: Memory at 84000000 (32-bit, prefetchable) [disabled]
	Region 1: I/O ports at 1000 [disabled]
	Region 2: Memory at 8008c000 (32-bit, non-prefetchable) [disabled]
	Expansion ROM at 800a0000 [disabled]
	Capabilities: [5c] Power Management version 1
		Flags: PMEClk- AuxPwr- DSI- D1+ D2- PME-
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:03.0 Ethernet controller: Alteon Networks Inc. AceNIC Gigabit Ethernet (rev 01)
	Subsystem: Alteon Networks Inc.: Unknown device 0001
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 min, 16 set, cache line size 08
	Interrupt: pin A routed to IRQ 53
	Region 0: Memory at 80088000 (32-bit, non-prefetchable) [disabled]

01:07.0 Class ff00: Apple Computer Inc.: Unknown device 0022 (rev 03)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 16 set, cache line size 08
	Region 0: Memory at 80000000 (32-bit, non-prefetchable)

01:08.0 USB Controller: Apple Computer Inc.: Unknown device 0019 (prog-if 10 [OHCI])
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 3 min, 86 max, 16 set
	Interrupt: pin A routed to IRQ 27
	Region 0: Memory at 80082000 (32-bit, non-prefetchable)

01:09.0 USB Controller: Apple Computer Inc.: Unknown device 0019 (prog-if 10 [OHCI])
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 3 min, 86 max, 16 set
	Interrupt: pin A routed to IRQ 28
	Region 0: Memory at 80081000 (32-bit, non-prefetchable)

01:0a.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020 (prog-if 10 [OHCI])
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 63
	Region 0: Memory at 80080000 (32-bit, non-prefetchable) [disabled]
	Region 1: Memory at 80084000 (32-bit, non-prefetchable) [disabled]
	Capabilities: [44] Power Management version 1
		Flags: PMEClk- AuxPwr+ DSI- D1- D2+ PME-
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-


[-- Attachment #1.4: x.log --]
[-- Type: text/plain, Size: 13127 bytes --]


XFree86 Version 4.0.1c / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 28 August 2000
	If the server is older than 6-12 months, or if your card is newer
	than the above date, look for a newer version before reporting
	problems.  (see http://www.XFree86.Org/FAQ)
Operating System: Linux 2.2.15pre13 ppc [ELF] 
Module Loader present
(==) Log file: "/var/log/XFree86.0.log", Time: Wed Oct 11 07:08:35 2000
(++) Using config file: "./XF86Config.new"
Markers: (--) probed, (**) from config file, (==) default setting,
         (++) from command line, (!!) notice, (II) informational,
         (WW) warning, (EE) error, (??) unknown.
(==) ServerLayout "XFree86 Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor0"
(**) |   |-->Device "Card0"
(**) |-->Screen "Screen1" (1)
(**) |   |-->Monitor "Monitor1"
(**) |   |-->Device "Card1"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(WW) The directory "/usr/X11R6/lib/X11/fonts/CID/" does not exist.
	Entry deleted from font path.
(==) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/"
(==) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(--) using VT number 7

(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 0.1.0
(II) Loading /usr/X11R6/lib/modules/libscanpci.a
(II) Module scanpci: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 0.1.0
(II) Unloading /usr/X11R6/lib/modules/libscanpci.a
(--) PCI: (0:16:0) ATI Rage 128 Pro PF rev 0, Mem @ 0x94000000/26, 0x90000000/14, I/O @ 0x0400/8
(--) PCI: (1:2:0) ATI Rage 128 RE rev 0, Mem @ 0x84000000/26, 0x8008c000/14, I/O @ 0x1000/8
(II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a
(II) Module extmod: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libxie.a
(II) Module xie: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libpex5.a
(II) Module pex5: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.a
(II) Module glx: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
(II) Module dri: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/linux/libdrm.a
(II) Module drm: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a
(II) Module dbe: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/librecord.a
(II) Module record: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.13.0
(II) Loading /usr/X11R6/lib/modules/drivers/r128_drv.o
(II) Module r128: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 3.1.1
(II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o
(II) Module mouse: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) r128: Driver for ATI Rage 128 chipset: ATI Rage 128 RE (PCI),
	ATI Rage 128 RF (AGP), ATI Rage 128 RK (PCI), ATI Rage 128 RL (AGP),
	ATI Rage 128 Pro PF (AGP), ATI Rage 128 PR,
	ATI Rage 128 Mobility LE (PCI), ATI Rage 128 Mobility LF (AGP)
(--) Chipset ATI Rage 128 Pro PF (AGP) found
(--) Chipset ATI Rage 128 RE (PCI) found
(WW) ****INVALID MEM ALLOCATION**** b: 0x8008c000 e: 0x8008ffff correcting\a
NonSys
	[0] -1	0x80084000 - 0x80087fff (0x4000) MX[B]
	[1] -1	0x80080000 - 0x800fffff (0x80000) MX[B]
	[2] -1	0x80081000 - 0x80081fff (0x1000) MX[B]
	[3] -1	0x80082000 - 0x80083fff (0x2000) MX[B]
	[4] -1	0x80000000 - 0x8007ffff (0x80000) MX[B]
	[5] -1	0x80088000 - 0x8008ffff (0x8000) MX[B]
New PCI res 2 base: 0x80100000, size: 0x4000, type Mem
(II) Loading /usr/X11R6/lib/modules/libvgahw.a
(II) Module vgahw: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 0.1.0
(II) r128(0): PCI bus 0 card 16 func 0
(==) r128(0): Depth 8, (==) framebuffer bpp 8
(II) r128(0): Pixel depth = 8 bits stored in 1 byte (8 bpp pixmaps)
(==) r128(0): Default visual is PseudoColor
(II) r128(0): Using 8 bits per RGB (8 bit DAC)
(II) Loading /usr/X11R6/lib/modules/libint10.a
(II) Module int10: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) r128(0): initializing int10
(EE) r128(0): Cannot read V_BIOS (4)
(--) r128(0): Chipset: "ATI Rage 128 Pro PF (AGP)" (ChipID = 0x5046)
(--) r128(0): Linear framebuffer at 0x94000000
(--) r128(0): MMIO registers at 0x90000000
(--) r128(0): BIOS at 0x90020000
(--) r128(0): VideoRAM: 16384 kByte (64-bit SDR SGRAM 1:1)
(II) r128(0): PLL parameters: rf=2950 rd=35 min=12500 max=25000; xclk=14000
(==) r128(0): Using gamma correction (1.0, 1.0, 1.0)
(WW) r128(0): Monitor0: Using default hsync range of 28-33kHz
(WW) r128(0): Monitor0: using default vrefresh range of 43-72Hz
(II) r128(0): Clock range:  12.50 to 250.00 MHz
(WW) r128(0): Mode "640x350" deleted (hsync out of range)
(WW) r128(0): Mode "640x400" deleted (hsync out of range)
(WW) r128(0): Mode "720x400" deleted (hsync out of range)
(WW) r128(0): Mode "640x480" deleted (hsync out of range)
(WW) r128(0): Mode "640x480" deleted (hsync out of range)
(WW) r128(0): Mode "640x480" deleted (hsync out of range)
(WW) r128(0): Mode "800x600" deleted (hsync out of range)
(WW) r128(0): Mode "800x600" deleted (hsync out of range)
(WW) r128(0): Mode "800x600" deleted (hsync out of range)
(WW) r128(0): Mode "800x600" deleted (hsync out of range)
(WW) r128(0): Mode "800x600" deleted (hsync out of range)
(WW) r128(0): Mode "1024x768" deleted (hsync out of range)
(WW) r128(0): Mode "1024x768" deleted (hsync out of range)
(WW) r128(0): Mode "1024x768" deleted (hsync out of range)
(WW) r128(0): Mode "1024x768" deleted (hsync out of range)
(WW) r128(0): Mode "1024x768" deleted (hsync out of range)
(WW) r128(0): Mode "1152x864" deleted (hsync out of range)
(WW) r128(0): Mode "1280x960" deleted (hsync out of range)
(WW) r128(0): Mode "1280x960" deleted (hsync out of range)
(WW) r128(0): Mode "1280x1024" deleted (hsync out of range)
(WW) r128(0): Mode "1280x1024" deleted (hsync out of range)
(WW) r128(0): Mode "1280x1024" deleted (hsync out of range)
(WW) r128(0): Mode "1600x1200" deleted (hsync out of range)
(WW) r128(0): Mode "1600x1200" deleted (hsync out of range)
(WW) r128(0): Mode "1600x1200" deleted (hsync out of range)
(WW) r128(0): Mode "1600x1200" deleted (hsync out of range)
(WW) r128(0): Mode "1600x1200" deleted (hsync out of range)
(WW) r128(0): Mode "1792x1344" deleted (hsync out of range)
(WW) r128(0): Mode "1792x1344" deleted (bad mode clock/interlace/doublescan)
(WW) r128(0): Mode "1856x1392" deleted (hsync out of range)
(WW) r128(0): Mode "1856x1392" deleted (bad mode clock/interlace/doublescan)
(WW) r128(0): Mode "1920x1440" deleted (hsync out of range)
(WW) r128(0): Mode "1920x1440" deleted (bad mode clock/interlace/doublescan)
(--) r128(0): Virtual size is 640x480 (pitch 640)
(**) r128(0): Default mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz
(==) r128(0): DPI set to (75, 75)
(II) Loading /usr/X11R6/lib/modules/libfb.a
(II) Module fb: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/libramdac.a
(II) Module ramdac: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 0.1.0
(II) Loading /usr/X11R6/lib/modules/libxaa.a
(II) Module xaa: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(**) r128(0): CCE in BM mode
(**) r128(0): Using 8 MB AGP aperture
(**) r128(0): Using 1 MB for the ring buffer
(**) r128(0): Using 1 MB for vertex buffers
(**) r128(0): Using 1 MB for indirect buffers
(**) r128(0): Using 5 MB for AGP textures
(**) r128(0): Using 16384 byte vertex buffers
(II) r128(1): PCI bus 1 card 2 func 0
(==) r128(1): Depth 8, (==) framebuffer bpp 8
(II) r128(1): Pixel depth = 8 bits stored in 1 byte (8 bpp pixmaps)
(==) r128(1): Default visual is PseudoColor
(II) r128(1): Using 8 bits per RGB (8 bit DAC)
(II) r128(1): initializing int10
c000:00b9: 63 ILLEGAL X86 OPCODE!
(--) r128(1): Chipset: "ATI Rage 128 RE (PCI)" (ChipID = 0x5245)
(--) r128(1): Linear framebuffer at 0x84000000
(--) r128(1): MMIO registers at 0x80100000
(--) r128(1): BIOS at 0x800a0000
(II) r128(1): Video RAM override, using 8192 kB instead of 0 kB
(**) r128(1): VideoRAM: 8192 kByte (128-bit SDR SGRAM 1:1)
(II) r128(1): PLL parameters: rf=2950 rd=0 min=12500 max=25000; xclk=0
(==) r128(1): Using gamma correction (1.0, 1.0, 1.0)
(WW) r128(1): Monitor1: Using default hsync range of 28-33kHz
(WW) r128(1): Monitor1: using default vrefresh range of 43-72Hz
(II) r128(1): Clock range:  12.50 to 250.00 MHz
(WW) r128(1): Mode "640x350" deleted (hsync out of range)
(WW) r128(1): Mode "640x400" deleted (hsync out of range)
(WW) r128(1): Mode "720x400" deleted (hsync out of range)
(WW) r128(1): Mode "640x480" deleted (hsync out of range)
(WW) r128(1): Mode "640x480" deleted (hsync out of range)
(WW) r128(1): Mode "640x480" deleted (hsync out of range)
(WW) r128(1): Mode "800x600" deleted (hsync out of range)
(WW) r128(1): Mode "800x600" deleted (hsync out of range)
(WW) r128(1): Mode "800x600" deleted (hsync out of range)
(WW) r128(1): Mode "800x600" deleted (hsync out of range)
(WW) r128(1): Mode "800x600" deleted (hsync out of range)
(WW) r128(1): Mode "1024x768" deleted (hsync out of range)
(WW) r128(1): Mode "1024x768" deleted (hsync out of range)
(WW) r128(1): Mode "1024x768" deleted (hsync out of range)
(WW) r128(1): Mode "1024x768" deleted (hsync out of range)
(WW) r128(1): Mode "1024x768" deleted (hsync out of range)
(WW) r128(1): Mode "1152x864" deleted (hsync out of range)
(WW) r128(1): Mode "1280x960" deleted (hsync out of range)
(WW) r128(1): Mode "1280x960" deleted (hsync out of range)
(WW) r128(1): Mode "1280x1024" deleted (hsync out of range)
(WW) r128(1): Mode "1280x1024" deleted (hsync out of range)
(WW) r128(1): Mode "1280x1024" deleted (hsync out of range)
(WW) r128(1): Mode "1600x1200" deleted (hsync out of range)
(WW) r128(1): Mode "1600x1200" deleted (hsync out of range)
(WW) r128(1): Mode "1600x1200" deleted (hsync out of range)
(WW) r128(1): Mode "1600x1200" deleted (hsync out of range)
(WW) r128(1): Mode "1600x1200" deleted (hsync out of range)
(WW) r128(1): Mode "1792x1344" deleted (hsync out of range)
(WW) r128(1): Mode "1792x1344" deleted (bad mode clock/interlace/doublescan)
(WW) r128(1): Mode "1856x1392" deleted (hsync out of range)
(WW) r128(1): Mode "1856x1392" deleted (bad mode clock/interlace/doublescan)
(WW) r128(1): Mode "1920x1440" deleted (hsync out of range)
(WW) r128(1): Mode "1920x1440" deleted (bad mode clock/interlace/doublescan)
(--) r128(1): Virtual size is 640x480 (pitch 640)
(**) r128(1): Default mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz
(==) r128(1): DPI set to (75, 75)
(**) r128(1): CCE in PIO mode
(II) Loading /usr/X11R6/lib/modules/librac.a
(II) Module rac: vendor="The XFree86 Project"
	compiled for 4.0.1c, module version = 1.0.0
(WW) r128(0): Cannot read colourmap from VGA.  Will restore with default
(II) r128(0): Memory manager initialized to (0,0) (640,8191)
(II) r128(0): Reserved area from (0,480) to (640,482)
(II) r128(0): Largest offscreen area available: 640 x 7709
(==) r128(0): Backing store disabled
(II) r128(0): Using XFree86 Acceleration Architecture (XAA)
	Screen to screen bit blits
	Solid filled rectangles
	8x8 mono pattern filled rectangles
	Indirect CPU to Screen color expansion
	Solid Lines
	Dashed Lines
	Offscreen Pixmaps
	Setting up tile and stipple cache:
		32 128x128 slots
		24 256x256 slots
		9 512x512 slots
(II) r128(0): Acceleration enabled
(II) r128(0): Using hardware cursor (scanline 482)
(II) r128(0): Largest offscreen area available: 640 x 7705
(II) r128(0): Direct rendering disabled
(WW) r128(1): Cannot read colourmap from VGA.  Will restore with default
(EE) r128(1): (Ron = 15360) + (Rloop = 16) >= (Roff = 0)

Fatal server error:
AddScreen/ScreenInit failed for driver 1


When reporting a problem related to a server crash, please send
the full server output, not just the last messages.
This can be found in the log file "/var/log/XFree86.0.log".
Please report problems to debian-x@lists.debian.org.


[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: dual head r128

[Michel Dänzer]

Josh Huber wrote:
>
> Anyone got dual head r128 up and running on ppc?  I've got a dual G4
> system here (running a UP kernel for now), with the shipped AGP r128
> card, and another PCI (pc, no fcode) r128 card.
>
> The relevant information is attached, lspci -vv, XF86Config, and the
> log of the failed X startup.  X works with just the AGP card, as
> expected.
>
> Of note is the:
> c000:00b9: 63 ILLEGAL X86 OPCODE!
>
> line in x.log, when trying to run int10 on the secondary card.

I don't think that's the cause, it fails much later.

Have you built X yourself? If yes, you need patches from Ani Joshi. The memory
and clock values it probes are obviously bogus.

Wait a minute, I see you are using debs, which should contain Ani's stuff.
Does aty128fb work on the second card? If yes, try Option "UseFBDev".


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Josh Huber]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

On Wed, Oct 11, 2000 at 08:43:28PM +0200, Michel D?nzer wrote:
> I don't think that's the cause, it fails much later.

That is true, but I thought that if perhaps int10 wasn't able to init
the card fully, that it might cause problems later.  Let's assume
that's not a problem for the moment though :)

> Have you built X yourself? If yes, you need patches from Ani Joshi. The memory
> and clock values it probes are obviously bogus.

> Wait a minute, I see you are using debs, which should contain Ani's stuff.
> Does aty128fb work on the second card? If yes, try Option "UseFBDev".

Yeah, I'm using the debs, but it looks like the latest xserver-xfree86
ppc packages are still at phase2v5, while the other packages are up to
phase2v15.  Perhaps the code is just a little too old?

BTW, no...I don't have aty128fb working on the secondary head -- is
there some option to tell the driver to scan for all cards?  does it
do this by default?

The secondary card is a PC card, so it's not initialized by OF, but I
think the r128 fb driver does a proper initialization of the card, so
that shouldn't be the problem.

btw, I'm using the debian kernel that shipped with potato -- perhaps I
should try a newer one?  ben's or a 2.4 kernel perhaps?

Thanks,
-- 
Josh
| huber@mclx.com |
1024D/6B21489A 61F0 6138 BE7B FEBF A223  E9D1 BFE1 2065 6B21 489A

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: dual head r128

[Tom Rini]

On Wed, Oct 11, 2000 at 02:52:49PM -0400, Josh Huber wrote:
> On Wed, Oct 11, 2000 at 08:43:28PM +0200, Michel D?nzer wrote:
> > I don't think that's the cause, it fails much later.
>
> That is true, but I thought that if perhaps int10 wasn't able to init
> the card fully, that it might cause problems later.  Let's assume
> that's not a problem for the moment though :)
>
> > Have you built X yourself? If yes, you need patches from Ani Joshi. The memory
> > and clock values it probes are obviously bogus.
>
> > Wait a minute, I see you are using debs, which should contain Ani's stuff.
> > Does aty128fb work on the second card? If yes, try Option "UseFBDev".
>
> Yeah, I'm using the debs, but it looks like the latest xserver-xfree86
> ppc packages are still at phase2v5, while the other packages are up to
> phase2v15.  Perhaps the code is just a little too old?

> BTW, no...I don't have aty128fb working on the secondary head -- is
> there some option to tell the driver to scan for all cards?  does it
> do this by default?

I _think_ the problem here is aty128fb cannot setup an uninitalized card.
2.4 _might_ be able to help in this area.

> The secondary card is a PC card, so it's not initialized by OF, but I
> think the r128 fb driver does a proper initialization of the card, so
> that shouldn't be the problem.

You can check this 1st by seeing if dmesg mentions two cards.  If it does
try video=map:000111 (tty1-3 on fb0, 4-6 on fb1).  If you don't have two
cards showing up this will panic (!!!)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Michel Dänzer]

Josh Huber wrote:

> > Have you built X yourself? If yes, you need patches from Ani Joshi. The
> > memory and clock values it probes are obviously bogus.
>
> > Wait a minute, I see you are using debs, which should contain Ani's stuff.
> > Does aty128fb work on the second card? If yes, try Option "UseFBDev".
>
> Yeah, I'm using the debs, but it looks like the latest xserver-xfree86
> ppc packages are still at phase2v5, while the other packages are up to
> phase2v15.  Perhaps the code is just a little too old?

I guess it's because Branden doesn't build the powerpc debs himself or Ani's
patches didn't apply cleanly anymore.


> BTW, no...I don't have aty128fb working on the secondary head -- is
> there some option to tell the driver to scan for all cards?  does it
> do this by default?

I think you need to add a second video=aty128fb and/or video=map:000001 or
similar. Oh, and while we're at it, maybe you also need the libfbdevhw.a from
http://n.ethz.ch/student/daenzerm/download/X4-fbdev-test.tar.bz2 for the
second head to work with fbdev.


> The secondary card is a PC card, so it's not initialized by OF, but I
> think the r128 fb driver does a proper initialization of the card, so
> that shouldn't be the problem.

AFAIK it may be a problem with 2.2 kernels (for aty128fb) though.


> btw, I'm using the debian kernel that shipped with potato -- perhaps I
> should try a newer one?  ben's or a 2.4 kernel perhaps?

That might be a good idea at any rate.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Josh Huber]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

On Wed, Oct 11, 2000 at 09:09:08PM +0200, Michel D?nzer wrote:
> I guess it's because Branden doesn't build the powerpc debs himself or Ani's
> patches didn't apply cleanly anymore.

Yeah, like Tom said, I think it's because the patches broke x86
systems.  What I think I'm going to do is get the source package for
xfree 4, rsync ani's stuff and rebuild a package.

I'll also upgrade to 2.4 to see if that makes a difference.

btw, dmesg shows that the fbcon system only detected one card -- the
AGP one.

Thanks for the help,
-- 
Josh
| huber@mclx.com |
1024D/6B21489A 61F0 6138 BE7B FEBF A223  E9D1 BFE1 2065 6B21 489A

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: dual head r128

[Gabriel Paubert]

On Wed, 11 Oct 2000, Josh Huber wrote:

> Of note is the:
> c000:00b9: 63 ILLEGAL X86 OPCODE!
>
> line in x.log, when trying to run int10 on the secondary card.

Hmmm, 0x63 is the opcode for arpl, a protected mode only instruction which
is related to (shudder) segments and their protection model. If you reach
this code, it might be an emulator bug (but I gave up trying to understand
Xfree's emulator), but I can't remember (and I got rid of my XFree sources
because I needed the disk space for something else) if there is a way to
put a breakpoint in the emulated ROM and step (emulated) instruction by
instruction.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Michel Dänzer]

Josh Huber wrote:

> > I guess it's because Branden doesn't build the powerpc debs himself or
> > Ani's patches didn't apply cleanly anymore.
>
> Yeah, like Tom said, I think it's because the patches broke x86
> systems.  What I think I'm going to do is get the source package for
> xfree 4, rsync ani's stuff and rebuild a package.

The latest powerpc debs do contain patches from Ani though, don't know what he
changed in his tree since then if anything.


> I'll also upgrade to 2.4 to see if that makes a difference.
>
> btw, dmesg shows that the fbcon system only detected one card -- the
> AGP one.

That should work better with a 2.4 kernel. Anyway, have you used two
video=aty128fb: ?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Kostas Gewrgiou]

On Wed, 11 Oct 2000, Josh Huber wrote:

> On Wed, Oct 11, 2000 at 08:43:28PM +0200, Michel D?nzer wrote:
> > I don't think that's the cause, it fails much later.
>
> That is true, but I thought that if perhaps int10 wasn't able to init
> the card fully, that it might cause problems later.  Let's assume
> that's not a problem for the moment though :)

Since the card is a x86 one int10 is needed to initialize it, don't expect
the int10 code to work under linux/ppc though, it needs ISA IO and memory
access which don't work.
I have code to fix PIO for machines with only one iobase, but it
doesn't work with Uni-N machines (i have no idea how to handle code like
inb(0x3C3) in this machines and until someone figures out how to handle it
don't expect int10 to work....)

> > Have you built X yourself? If yes, you need patches from Ani Joshi. The memory
> > and clock values it probes are obviously bogus.
>
> > Wait a minute, I see you are using debs, which should contain Ani's stuff.
> > Does aty128fb work on the second card? If yes, try Option "UseFBDev".
>
> The secondary card is a PC card, so it's not initialized by OF, but I
> think the r128 fb driver does a proper initialization of the card, so
> that shouldn't be the problem.

Kevin Hendricks patches from Ani's tree will fix the memory/clock values
for OF cards only, the patch breaks the calculations for the x86 cards
(thats the reason why its not in the xfree cvs), so don't expect to get
sane values for the x86 card. (aty128fb has the same problem as well btw)
The correct fix will be to check that the ROM is a x86 one and then read
the values from it and if not use the OF values. Unfortunately i don't
have access to a machine with a r128 card anymore so i never managed to
fix this.

  Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Hendricks, Kevin]

Hi,

> the patch breaks the calculations for the x86 cards
> (thats the reason why its not in the xfree cvs), so don't expect to get
> sane values for the x86 card. (aty128fb has the same problem as well btw)

Why?  This should not be unless the bios on the x86 card never initializes the card in any way.  If the bios does do some basic initialization, the patch should work just as well for an x86 card as a ppc one if the main clock rate is the same.  If the main clock rate is different, as long as you can find out what it is, reading and calculating the  timings from those register settings really should work generically, shouldn't it?

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Kostas Gewrgiou]

On Thu, 12 Oct 2000, Hendricks, Kevin wrote:

>
> Hi,
>
> > the patch breaks the calculations for the x86 cards
> > (thats the reason why its not in the xfree cvs), so don't expect to get
> > sane values for the x86 card. (aty128fb has the same problem as well btw)
>
> Why?  This should not be unless the bios on the x86 card never initializes
> the card in any way.  If the bios does do some basic initialization, the
> patch should work just as well for an x86 card as a ppc one if the main
> clock rate is the same.  If the main clock rate is different, as long as
> you can find out what it is, reading and calculating the  timings from
> those register settings really should work generically, shouldn't it?

The reference frequency isn't the same in all cards, your patch assumes that
  /* Assume REF clock is 2950 (in units of 10khz) */
  /* and that all pllclk must be between 125 Mhz and 250Mhz */

>From the comment in r128_driver.c you can see that the possible values are
29.50MHz, 28.63MHz, or 14.32MHz.

  /* These probably aren't going to work for
     the card you are using.  Specifically,
     reference freq can be 29.50MHz,
     28.63MHz, or 14.32MHz.  YMMV. */

Most of the ppc r128 cards have a reference frequency of 29.50MHz so the
code works but i heard that some of the new ones have different reference
freq.

  Kostas.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Hendricks, Kevin]

Hi Kostas,

> If the main clock rate is different, as long as
> > you can find out what it is, reading and calculating the  timings from
> > those register settings really should work generically, shouldn't it?

> The reference frequency isn't the same in all cards, your patch assumes that
>   /* Assume REF clock is 2950 (in units of 10khz) */
>   /* and that all pllclk must be between 125 Mhz and 250Mhz */

Yes, that is what I was referring to above.  That info is generally available in the card docs.  Ben has a whole set of ref clock rates for all the ati cards shipped under mac or clones.  I also have that info and could easily look up the card id to set it for macs in general.

>   /* These probably aren't going to work for
>      the card you are using.  Specifically,
>      reference freq can be 29.50MHz,
>      28.63MHz, or 14.32MHz.  YMMV. */

You can actually use info on the pllclk constraints to rule out the 14.32Mhz cases from the other two cases and then you are left with only 2 to try.

A lookup table would certainly do the trick if the user did not want to simply  use trial and error.  Anything would be better than the complete hard coded values set in the XF 4.0 source.

Perhaps a better idea is allow the REF clock rate to be passed as a parameter in the XF86Config file (much like the video memory parameter and bus ids passed now) for people to have control over if need be.   This value would then only be used if the bios test failed and then in place of the hardcoded values so that my pll register probing routine would be actually work.  A desperate user could then try each of the 3 values until he/she saw something they liked on the screen.

> Most of the ppc r128 cards have a reference frequency of 29.50MHz so the
> code works but i heard that some of the new ones have different reference
> freq.

Yes, there is one new card (of the r128 variety) on Ben's list that does not use the 2950 ref clock value.

Since he has a bios on a ppc card it would be interesting to see the results of some "bios present?" tests to help determine if a bios is really there or not.  The current test sometimes passes on macs without a bios (possibly OF rom?) and garbage values are returned.

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Benjamin Herrenschmidt]

>
>Since the card is a x86 one int10 is needed to initialize it, don't expect
>the int10 code to work under linux/ppc though, it needs ISA IO and memory
>access which don't work.
>I have code to fix PIO for machines with only one iobase, but it
>doesn't work with Uni-N machines (i have no idea how to handle code like
>inb(0x3C3) in this machines and until someone figures out how to handle it
>don't expect int10 to work....)

I'm updating the PCI code in linuxppc_2_5 tree (which is more or less
meant to be merged in _2_3 soon). I'm adding a couple of cases to the
sys_pciconfig_iobase syscall to return the ISA mem and IO bases (if they
exist).

On the kernel side, one of the PCI IO busses will be mapped to ISA. What
I'll do is basically to change the kernel inb/outb functions to do
something like

if (addr < 64k)
  do_io(isa_io_base + addr)
else
  do_io(addr)

This way, PCI IOs will be able to use real physical addresses that will
have been put by the fixup code in the IO resources, while legacy IOs
will tap the IO bus that we have decided is the "legacy" bus.

It's a bit ugly, but AFAIK, we don't have any arch where IOs are memory
mapped below 64K physical. I would have prefered Paul's mecanism for
appending the IO spaces, but...

Unfortunately, there's no simple way to allow two busses to have the
legacy IOs. That means on UniN machines that they'll be available either
on the AGP bus, or the external PCI bus, but not both.
What you might do is to consider the ISA io base to be the IO base of the
bus that holds the card for which you are trying to run the BIOS. (By
using the syscall to retreive this IO base for the VGA card) instead of
asking the kernel for the "legacy" IO base.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Gabriel Paubert]

On Thu, 12 Oct 2000, Benjamin Herrenschmidt wrote:

> >Since the card is a x86 one int10 is needed to initialize it, don't expect
> >the int10 code to work under linux/ppc though, it needs ISA IO and memory
> >access which don't work.
> >I have code to fix PIO for machines with only one iobase, but it
> >doesn't work with Uni-N machines (i have no idea how to handle code like
> >inb(0x3C3) in this machines and until someone figures out how to handle it
> >don't expect int10 to work....)
>
> I'm updating the PCI code in linuxppc_2_5 tree (which is more or less
> meant to be merged in _2_3 soon). I'm adding a couple of cases to the
> sys_pciconfig_iobase syscall to return the ISA mem and IO bases (if they
> exist).
>
> On the kernel side, one of the PCI IO busses will be mapped to ISA. What
> I'll do is basically to change the kernel inb/outb functions to do
> something like
>
> if (addr < 64k)
>   do_io(isa_io_base + addr)
> else
>   do_io(addr)

No please, is there anybody bloat-conscious on this damned list ? Burying
more and more code inside each {in,out}[bwl] is not the solution.

Just define a macro ISA_PORT or something like this and update the kernel
to replace all the in/out to fixed ports to do in/out(ISA_PORT(n)). If you
don't do it you'll get a nice panic so you'll find all the places quite
fast.

Advantages:
- no iobase added in the PCI case: add iobase to all the
pci_resource_start and the driver code shrinks. Have you ever counted
the lwz instructions to access iobase, I have seen sequences where it
represented 1/4 to 1/3 of the instructions!

- for fixed I/O ports, ok, use the ISA_PORT(n)

- for old legacy drivers but with variable addresses (serial for PreP...)
you just need to add the I/O base in the probe code provided the field
used to store the port is wide enough (not 16 bits). BTW, then for
inb/outb the compiler only has to add an offset to a parameter, not
iobase+base+offset, making the code more compact: it directly maps
to reg+offset addresses.

- on x86 ISA_PORT(n) will be (n), so they won't scream too much and the
drivers can be updated gradually.

Drawbacks ?

> This way, PCI IOs will be able to use real physical addresses that will
> have been put by the fixup code in the IO resources, while legacy IOs
> will tap the IO bus that we have decided is the "legacy" bus.

PCI I/O resources will have to be kernel virtual, physical is impossible
with PreP if we want to lift the 2Gbuser space restriction (PreP I/O is
from 2 to 3 Gb physical and the first thing to do is to reallocate devices
which use it since most firmware use it too liberally, like one device
every ... 256Mb). There are other and better ways to increase user
available virtual space, however. And anyway I don't want any stinking add
in each in/out macro.


> Unfortunately, there's no simple way to allow two busses to have the
> legacy IOs. That means on UniN machines that they'll be available either
> on the AGP bus, or the external PCI bus, but not both.

Indeed, this is too awkward (is tere no way to redirect only the VGA
part of the legacy I/O space ? That's what the PCI-PCI bridges do, but
I've not yet used a single machine with AGP so I'm ignorant).

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Kostas Gewrgiou]

On Thu, 12 Oct 2000, Hendricks, Kevin wrote:

> A lookup table would certainly do the trick if the user did not want to
> simply  use trial and error.  Anything would be better than the complete
> hard coded values set in the XF 4.0 source.
>
> Perhaps a better idea is allow the REF clock rate to be passed as a
> parameter in the XF86Config file (much like the video memory parameter and
> bus ids passed now) for people to have control over if need be.   This
> value would then only be used if the bios test failed and then in place of
> the hardcoded values so that my pll register probing routine would be
> actually work.  A desperate user could then try each of the 3 values until
> he/she saw something they liked on the screen.

I prefer to use a lookup table before the config option, most users will
have no idea how to play with the options. I wonder if someone can damage
his card with a bad reference freq setup...

> > Most of the ppc r128 cards have a reference frequency of 29.50MHz so the
> > code works but i heard that some of the new ones have different reference
> > freq.
>
> Yes, there is one new card (of the r128 variety) on Ben's list that does
> not use the 2950 ref clock value.

The new r128 code needs to read extra values from the rom for the flatpanel
setup as well (Michel knows more about this) which we will have to find a
solution too.

> Since he has a bios on a ppc card it would be interesting to see the
> results of some "bios present?" tests to help determine if a bios is
> really there or not.  The current test sometimes passes on macs without a
> bios (possibly OF rom?) and garbage values are returned.

The current test only checks if a rom is present not if a bios or OF segment
is there, it needs to be fixed to check that its really reading from a
bios rom and not from something else (OF).

 Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Hendricks, Kevin]

Hi,

> The current test only checks if a rom is present not if a bios or OF segment
> is there, it needs to be fixed to check that its really reading from a
> bios rom and not from something else (OF).

So that is what is happening.  Perhaps we could simply add a check to make sure the REF clock value read from whatever looks like a bios actually is one of the 3 allowed values (2950, ...) and if so, assume the bios is present and if not default to something else.

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[David Edelsohn]

>>>>> Gabriel Paubert writes:

>> On the kernel side, one of the PCI IO busses will be mapped to ISA. What
>> I'll do is basically to change the kernel inb/outb functions to do
>> something like
>>
>> if (addr < 64k)
>> do_io(isa_io_base + addr)
>> else
>> do_io(addr)

Gabriel> No please, is there anybody bloat-conscious on this damned list ? Burying
Gabriel> more and more code inside each {in,out}[bwl] is not the solution.

Gabriel> Just define a macro ISA_PORT or something like this and update the kernel
Gabriel> to replace all the in/out to fixed ports to do in/out(ISA_PORT(n)). If you
Gabriel> don't do it you'll get a nice panic so you'll find all the places quite
Gabriel> fast.

	Yes, it is very important to avoid adding many layers of branches
to the code if anyone cares about performance.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Kostas Gewrgiou]

On Thu, 12 Oct 2000, Benjamin Herrenschmidt wrote:

> Unfortunately, there's no simple way to allow two busses to have the
> legacy IOs. That means on UniN machines that they'll be available either
> on the AGP bus, or the external PCI bus, but not both.

That wont help much for the xfree side, we need legacy IO/mem access
to both busses.

> What you might do is to consider the ISA io base to be the IO base of the
> bus that holds the card for which you are trying to run the BIOS. (By
> using the syscall to retreive this IO base for the VGA card) instead of
> asking the kernel for the "legacy" IO base.

Thats what i am trying to do at the moment, unfortunately its not very
easy there are many places that legacy IO is used and for most of them
the calls are inside generic modules that usually have no idea about
which card they use.

If as Gabriel suggested is possible to redirect the VGA part of the
IO space then we could talk to all cards which will simplify things.

  Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Kostas Gewrgiou]

On Thu, 12 Oct 2000, Hendricks, Kevin wrote:

> So that is what is happening.  Perhaps we could simply add a check to
> make sure the REF clock value read from whatever looks like a bios
> actually is one of the 3 allowed values (2950, ...) and if so, assume the
> bios is present and if not default to something else.

It shouldn't be hard to check that the image has bios signature i can
send you info about it if you want, checking that the REF clock has
a sane value won't hurt either though :)

 Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Michel Dänzer]

Kostas Gewrgiou wrote:
>
> On Wed, 11 Oct 2000, Josh Huber wrote:
>
> > On Wed, Oct 11, 2000 at 08:43:28PM +0200, Michel D?nzer wrote:
>
> > > Does aty128fb work on the second card? If yes, try Option "UseFBDev".
> >
> > The secondary card is a PC card, so it's not initialized by OF, but I
> > think the r128 fb driver does a proper initialization of the card, so
> > that shouldn't be the problem.
>
> Kevin Hendricks patches from Ani's tree will fix the memory/clock values
> for OF cards only, the patch breaks the calculations for the x86 cards
> (thats the reason why its not in the xfree cvs),

But there is an #ifdef _powerpc_ so it can't break x86 machines?


> On Thu, 12 Oct 2000, Hendricks, Kevin wrote:
>
> The new r128 code needs to read extra values from the rom for the flatpanel
> setup as well (Michel knows more about this) which we will have to find a
> solution too.

And it will be hard. Rumour has it that the correct values are in MacOS and
only Apple knows how to do it right, not even ATI. The default values work
more or less on my Pismo, but there is always the danger of damaging the
panel.

Note that the FP code is only needed for stretching modes with a lower
resolution than the panel's, just disabling it altogether works fine for the
full resolution.


> > Since he has a bios on a ppc card it would be interesting to see the
> > results of some "bios present?" tests to help determine if a bios is
> > really there or not.  The current test sometimes passes on macs without a
> > bios (possibly OF rom?) and garbage values are returned.
>
> The current test only checks if a rom is present not if a bios or OF segment
> is there, it needs to be fixed to check that its really reading from a
> bios rom and not from something else (OF).

So this code from the current X CVS:

    R128ReadBIOS(0x0000, info->VBIOS, R128_VBIOS_SIZE);
    if (info->VBIOS[0] != 0x55 || info->VBIOS[1] != 0xaa) {
        xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
                   "Video BIOS not detected in PCI space!\n");

only checks if there is a ROM, not if it's a BIOS?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Kostas Gewrgiou]

On Thu, 12 Oct 2000, Michel [iso-8859-1] Dδnzer wrote:

> Kostas Gewrgiou wrote:
> >
> > Kevin Hendricks patches from Ani's tree will fix the memory/clock values
> > for OF cards only, the patch breaks the calculations for the x86 cards
> > (thats the reason why its not in the xfree cvs),
>
> But there is an #ifdef _powerpc_ so it can't break x86 machines?

Yes but it *does* break x86 cards used in ppc machines.
(linux/ppc isn't the only ppc os supported in xfree and they won't
be happy if we break things for them)

> > The new r128 code needs to read extra values from the rom for the flatpanel
> > setup as well (Michel knows more about this) which we will have to find a
> > solution too.
>
> And it will be hard. Rumour has it that the correct values are in MacOS and
> only Apple knows how to do it right, not even ATI. The default values work
> more or less on my Pismo, but there is always the danger of damaging the
> panel.

Damn thats not good :(

> Note that the FP code is only needed for stretching modes with a lower
> resolution than the panel's, just disabling it altogether works fine for the
> full resolution.
>
> > The current test only checks if a rom is present not if a bios or OF segment
> > is there, it needs to be fixed to check that its really reading from a
> > bios rom and not from something else (OF).
>
> So this code from the current X CVS:
>
>     R128ReadBIOS(0x0000, info->VBIOS, R128_VBIOS_SIZE);
>     if (info->VBIOS[0] != 0x55 || info->VBIOS[1] != 0xaa) {
>         xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
>                    "Video BIOS not detected in PCI space!\n");
>
> only checks if there is a ROM, not if it's a BIOS?

Right, from the pci spec the table is something like this
Offset    Length    Value    Description
0h          1        55h    ROM Signature, byte 1
1h          1        AAh    ROM Signature, byte 2
...
18h-19h     2        xx     Pointer to PCI Data Structure

PCI Data Structure
Offset    Length  Description
...
14           1    Code Type
..

Code Type is 0 for bios and 1 for OF

So you'll have to add one more test to check for BIOS/OF

 Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Gabriel Paubert]

On Thu, 12 Oct 2000, Benjamin Herrenschmidt wrote:

> Note to linux-kenrel readers: This discussion is the Nth attempt to find
> a solution to handle both legacy IOs and PCI IOs on machines with several
> IO busses memory mapped at different locations in the CPU space.

Yes, I know, but I still suspect that it is a more acceptable solution.
How many ISA drivers are there in real use ?

By decreasing order of importance (others might disagree):

- 8259 (yuck) and RTC/CMOS (always handled by architecture specific code
  AFAICT so it can be done in the way we want)
- serial
- DMA (used by floppy, perhaps parallel)
- floppy
- parallel
- sound ? (I don't know anything about sound, none of my machines have
  sound, I hate sound in computers and all the multimierda stuff, but most
  people don't agree with me so I put it here)
- old legacy devices like modems, SCSI (I have an ISA-SCSI at home)

I don't know where to put RTC/CMOS on this scale, but it should be close
to the top.

> >No please, is there anybody bloat-conscious on this damned list ? Burying
> >more and more code inside each {in,out}[bwl] is not the solution.
>
> Well, that is pretty small overhead, and probably ridiculous compared to
> the overhead of the IO itself. Most fast devices use MMIO anyway.

The problem is not the speed, it is the bloat. And increasing icache
footprint may have impressive side effects. Given the average time
between I/O the code will no more be in the cache when it is executed
again, so it will be fetched from memory. Minimizing icache footprint
is being nice to applications by not thrashing their cache (especially
true for interrupt code). See the mail from David too. OTOH, the first
thing to do is to revert the eieio->sync patch, first it is wrong, second
it will be a killer on SMP machines with 4 or more processors.

> The problem is that whatever solution someone propose, there is _always_
> somebody to reject it.

Let us wait and see. This solution can be adapted little by little. As
soon as you have the major devices working the other drivers can be
upgraded gradually.

> >Just define a macro ISA_PORT or something like this and update the kernel
> >to replace all the in/out to fixed ports to do in/out(ISA_PORT(n)). If you
> >don't do it you'll get a nice panic so you'll find all the places quite
> >fast.
>
> That basically mean making different macros for ISA in/out and PCI in/
> out. I've proposed this several time, but it requires changes to the
> common code, and all I got when talking about this was flames from x86 people.

No it is not the same, it means that we acknowledge that ISA and PCI are
too entangled on x86 to use different functions.

> >PCI I/O resources will have to be kernel virtual, physical is impossible
> >with PreP if we want to lift the 2Gbuser space restriction (PreP I/O is
> >from 2 to 3 Gb physical and the first thing to do is to reallocate devices
> >which use it since most firmware use it too liberally, like one device
> >every ... 256Mb). There are other and better ways to increase user
> >available virtual space, however. And anyway I don't want any stinking add
> >in each in/out macro.
>
> Well, in 2.4 we can easily reassign PCI IOs if we configure the bridge
> with proper resources. If all goes well, my new PCI code should handle
> that fine (should be ready this week-end).
>
> >Indeed, this is too awkward (is tere no way to redirect only the VGA
> >part of the legacy I/O space ? That's what the PCI-PCI bridges do, but
> >I've not yet used a single machine with AGP so I'm ignorant).
>
> No, most bridges used on macs can't do that. In fact, AFAIK, it's not
> possible to access the ISA memory space neither on those machines (on
> UniN, I can't generate memory cycles at lower address than 0x80000000).

Ok, than it's impossible to put a good old VGA and initialize it
with the help of an emulator. It also means that UniN is not CHRP
compliant but we all suspected that.

> My "pet" solution would be to have all legacy drivers request an IO base
> this way
>
>   base = isa_get_IO_base(legacy_addr);
>
> The isa_get_IO_base function could then be "tweaked" to recognize known
> legacy addresses and return different bases. (There might still be
> problems with VGA vs. parallell, I don't know x86 world well enough to be
> sure).

I hate this, if VGA is basically the only problem, instead of using the
ISA_PORT in the drivers, use another macro, something like VGA_PORT(n).
This is reasonable if the problem is VGA versus the rest, you know what
you want to access in the driver, and which kind of device you have.
Other legacy drivers do not have to bother with it, they'll never have to
go to AGP.

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Michel Dänzer]

Kostas Gewrgiou wrote:
>
> On Thu, 12 Oct 2000, Michel [iso-8859-1] Dänzer wrote:
>
> > Kostas Gewrgiou wrote:
> > >
> > > Kevin Hendricks patches from Ani's tree will fix the memory/clock values
> > > for OF cards only, the patch breaks the calculations for the x86 cards
> > > (thats the reason why its not in the xfree cvs),
> >
> > But there is an #ifdef _powerpc_ so it can't break x86 machines?
>
> Yes but it *does* break x86 cards used in ppc machines.
> (linux/ppc isn't the only ppc os supported in xfree and they won't
> be happy if we break things for them)

And the int10 or whatever code works for them?


> > > The current test only checks if a rom is present not if a bios or OF
> > > segment is there, it needs to be fixed to check that its really reading
> > > from a bios rom and not from something else (OF).
> >
> > So this code from the current X CVS:
> >
> >     R128ReadBIOS(0x0000, info->VBIOS, R128_VBIOS_SIZE);
> >     if (info->VBIOS[0] != 0x55 || info->VBIOS[1] != 0xaa) {
> >         xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
> >                    "Video BIOS not detected in PCI space!\n");
> >
> > only checks if there is a ROM, not if it's a BIOS?
>
> Right, from the pci spec the table is something like this
> Offset    Length    Value    Description
> 0h          1        55h    ROM Signature, byte 1
> 1h          1        AAh    ROM Signature, byte 2
> ...
> 18h-19h     2        xx     Pointer to PCI Data Structure
>
> PCI Data Structure
> Offset    Length  Description
> ...
> 14           1    Code Type
> ..
>
> Code Type is 0 for bios and 1 for OF
>
> So you'll have to add one more test to check for BIOS/OF

And then set info->VBIOS = NULL for OF and change the #ifdef _powerpc_ to if
(!info->VBIOS) or similar?


I have my last exam for this year tomorrow and leave for two weeks of vacation
on Saturday, so I wish good luck to any takers :)


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Kostas Gewrgiou]

On Thu, 12 Oct 2000, Michel [iso-8859-1] Dδnzer wrote:

> Kostas Gewrgiou wrote:
> >
> > On Thu, 12 Oct 2000, Michel [iso-8859-1] Dδnzer wrote:
> >
> > > But there is an #ifdef _powerpc_ so it can't break x86 machines?
> >
> > Yes but it *does* break x86 cards used in ppc machines.
> > (linux/ppc isn't the only ppc os supported in xfree and they won't
> > be happy if we break things for them)
>
> And the int10 or whatever code works for them?

ISA IO/MEM works for them so yes int10/vgahw should be fine there, i think
that linux/ppc is the only platform with this broken (with the new syscalls
we its simple to get it working for machines with one iobase and a working
ISA memory)

> And then set info->VBIOS = NULL for OF and change the #ifdef _powerpc_ to if
> (!info->VBIOS) or similar?

Right something along this lines will do, you probably need to change the
R128_BIOS16/32 macros to do byteswapping as well since the fields in the rom
are in little endian format.

> I have my last exam for this year tomorrow and leave for two weeks of vacation
> on Saturday, so I wish good luck to any takers :)

Good luck in your exam, i'll try to write something over the weekend if i
can find some free time.

 Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Geert Uytterhoeven]

On Thu, 12 Oct 2000, Kostas Gewrgiou wrote:
> On Thu, 12 Oct 2000, Michel [iso-8859-1] Dänzer wrote:
> > So this code from the current X CVS:
> >
> >     R128ReadBIOS(0x0000, info->VBIOS, R128_VBIOS_SIZE);
> >     if (info->VBIOS[0] != 0x55 || info->VBIOS[1] != 0xaa) {
> >         xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
> >                    "Video BIOS not detected in PCI space!\n");
> >
> > only checks if there is a ROM, not if it's a BIOS?
>
> Right, from the pci spec the table is something like this
> Offset    Length    Value    Description
> 0h          1        55h    ROM Signature, byte 1
> 1h          1        AAh    ROM Signature, byte 2
> ...
> 18h-19h     2        xx     Pointer to PCI Data Structure
>
> PCI Data Structure
> Offset    Length  Description
> ...
> 14           1    Code Type
> ..
>
> Code Type is 0 for bios and 1 for OF
>
> So you'll have to add one more test to check for BIOS/OF

IIRC, it's also possible to have one ROM that contains both x86 BIOS and
F-Code Open Firmware stuff. It may require compression to achieve this due to
the limited size to the ROM. I think I saw this on the Firmworks website, an
eon ago.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Josh Huber]

On Thu, Oct 12, 2000 at 12:48:33AM +0200, Michel D?nzer wrote:
> > I'll also upgrade to 2.4 to see if that makes a difference.
> >
> > btw, dmesg shows that the fbcon system only detected one card -- the
> > AGP one.
>
> That should work better with a 2.4 kernel. Anyway, have you used two
> video=aty128fb: ?

I tried this, and also tried the 2.4 kernel, with no luck.  2.4 spit
out some messages about pci assignments, but other than that, no other
framebuffer devices were configured, and X didn't function as
expected.

But, someone mentioned later in this thread, there might be a problem
with using a PC video card on ppc because of #ifdef __powerpc__'s in
ani patches?

Thanks for the help,

--
Josh
| huber@mclx.com |
1024D/6B21489A 61F0 6138 BE7B FEBF A223  E9D1 BFE1 2065 6B21 489A

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Benjamin Herrenschmidt]

>But you can fixup all pci_dev's so bus 0 takes 0x00000-0x0fffff, bus 1 takes
>0x10000-0x1ffff, and so on. ioportremap() finds out the bus by looking at the
>region.
>
>I/O space is not limited to 64 kB on non-ia32, we can use the full size of an
>unsigned long.
>
>Legacy I/O mappings (`I have legacy lp0 on bus 0 and legacy lp1 on bus
1') can
>be sorted out in ioportremap() as well.

Ok, If I follow you correctly, that mean that if we have, for example,
bus 1 set to 0x10000-0x1ffff, ioportremap() would return, for an address
in this range, the address + bus_io_base - 0x10000. At least on Macs,
AFAIK, we have only 64k or 128k of IOs available.

I still need to think about this, I'll leave the code in bk _2_5 as it is
now (which is the good old IO_BASE) and leave those IO changes for after
I'm finished with per-hose resources.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Michel Lanners]

> Ok, If I follow you correctly, that mean that if we have, for example,
> bus 1 set to 0x10000-0x1ffff, ioportremap() would return, for an address
> in this range, the address + bus_io_base - 0x10000. At least on Macs,
> AFAIK, we have only 64k or 128k of IOs available.

No, the regions are larger. Apple's doc talks about '23 bits of IO
space', which is 8M, at least for the first-generation bridges (bandit,
that is).

Anyway, the best way to find out the size of this region (unless you can
read it from the bridge) is to look at the OF device tree, and the
bridge's region properties.

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Benjamin Herrenschmidt]

>No, the regions are larger. Apple's doc talks about '23 bits of IO
>space', which is 8M, at least for the first-generation bridges (bandit,
>that is).
>
>Anyway, the best way to find out the size of this region (unless you can
>read it from the bridge) is to look at the OF device tree, and the
>bridge's region properties.

Well, if IO decoding works like memory decoding on those bridges, then
yes, the region size is either 256 or 16Mb (large or sparse decoding).
The way it's currently setup by the BIOS, I beleive it's 16Mb. It's
possible that only 8MB out of the 16 are actually useable, we really lack
documentation about those chips.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Geert Uytterhoeven]

On Fri, 13 Oct 2000, Benjamin Herrenschmidt wrote:
> >But you can fixup all pci_dev's so bus 0 takes 0x00000-0x0fffff, bus 1 takes
> >0x10000-0x1ffff, and so on. ioportremap() finds out the bus by looking at the
> >region.
> >
> >I/O space is not limited to 64 kB on non-ia32, we can use the full size of an
> >unsigned long.
> >
> >Legacy I/O mappings (`I have legacy lp0 on bus 0 and legacy lp1 on bus
> 1') can
> >be sorted out in ioportremap() as well.
>
> Ok, If I follow you correctly, that mean that if we have, for example,
> bus 1 set to 0x10000-0x1ffff, ioportremap() would return, for an address
> in this range, the address + bus_io_base - 0x10000. At least on Macs,
> AFAIK, we have only 64k or 128k of IOs available.

Right.

After that `#define inb	readb' etc. and almost all overhead is gone.

And if you want to map legacy VGA I/O to bus X, you can handle this in
ioportremap(). Since ioportremap() is called only once, the complexity there
isn't of much importance.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Paul Mackerras]

Gabriel Paubert writes:

> On Thu, 12 Oct 2000, Benjamin Herrenschmidt wrote:
>
> > On the kernel side, one of the PCI IO busses will be mapped to ISA. What
> > I'll do is basically to change the kernel inb/outb functions to do
> > something like
> >
> > if (addr < 64k)
> >   do_io(isa_io_base + addr)
> > else
> >   do_io(addr)
>
> No please, is there anybody bloat-conscious on this damned list ? Burying
> more and more code inside each {in,out}[bwl] is not the solution.

I agree that doing that in inb/outb is a bad idea.

> Just define a macro ISA_PORT or something like this and update the kernel
> to replace all the in/out to fixed ports to do in/out(ISA_PORT(n)). If you

You mean everywhere in all the generic code?  I confidently predict
that that wouldn't be accepted into the official kernel sources (and
nor should it be accepted).

> Advantages:
> - no iobase added in the PCI case: add iobase to all the
> pci_resource_start and the driver code shrinks. Have you ever counted
> the lwz instructions to access iobase, I have seen sequences where it
> represented 1/4 to 1/3 of the instructions!

I think iobase should be a constant, and we should set up our virt ->
phys mapping to do anything fancy that we might need.

> PCI I/O resources will have to be kernel virtual, physical is impossible
> with PreP if we want to lift the 2Gbuser space restriction (PreP I/O is
> from 2 to 3 Gb physical and the first thing to do is to reallocate devices
> which use it since most firmware use it too liberally, like one device
> every ... 256Mb). There are other and better ways to increase user
> available virtual space, however. And anyway I don't want any stinking add
> in each in/out macro.

Adding a constant is fine, that's just one instruction.  I think you
need to stop and look at the relative speeds of an I/O access
(hundreds of nanoseconds, if not microseconds) with the speed of a few
instructions or even a cacheable load.  In any case, I/O accesses are
actually very infrequent (if you don't believe me, measure it), unless
you're doing PIO to a high-bandwidth device, in which case it should
be using DMA.

> > Unfortunately, there's no simple way to allow two busses to have the
> > legacy IOs. That means on UniN machines that they'll be available either
> > on the AGP bus, or the external PCI bus, but not both.
>
> Indeed, this is too awkward (is tere no way to redirect only the VGA
> part of the legacy I/O space ? That's what the PCI-PCI bridges do, but
> I've not yet used a single machine with AGP so I'm ignorant).

Could someone fill me in on why we need legacy I/O to the AGP bus?

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Michel Lanners]

On  17 Oct, this message from Paul Mackerras echoed through cyberspace:
> I think iobase should be a constant, and we should set up our virt ->
> phys mapping to do anything fancy that we might need.

The discussion about IO seems to always concentrate on kernel access of
IO space. How would you address user space access? Does the syscall
that's been discussed address this to an acceptable degree?

>> > Unfortunately, there's no simple way to allow two busses to have the
>> > legacy IOs. That means on UniN machines that they'll be available either
>> > on the AGP bus, or the external PCI bus, but not both.
>>
>> Indeed, this is too awkward (is tere no way to redirect only the VGA
>> part of the legacy I/O space ? That's what the PCI-PCI bridges do, but
>> I've not yet used a single machine with AGP so I'm ignorant).
>
> Could someone fill me in on why we need legacy I/O to the AGP bus?

Legacy VGA?

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Benjamin Herrenschmidt]

>> > Unfortunately, there's no simple way to allow two busses to have the
>> > legacy IOs. That means on UniN machines that they'll be available either
>> > on the AGP bus, or the external PCI bus, but not both.
>>
>> Indeed, this is too awkward (is tere no way to redirect only the VGA
>> part of the legacy I/O space ? That's what the PCI-PCI bridges do, but
>> I've not yet used a single machine with AGP so I'm ignorant).
>
>Could someone fill me in on why we need legacy I/O to the AGP bus?

Some display cards (like voodoo) AFAIK, need us to tweak with the VGA IO
registers. The interest in having something like ioportremap or similar
is that we can have the platform specific code return a different base
for VGA than other legacy devices, thus allowing us to have, for example,
such a VGA card in the AGP slot and a legacy serial card in the PCI slots.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Geert Uytterhoeven]

On Tue, 17 Oct 2000, Benjamin Herrenschmidt wrote:
> >Could someone fill me in on why we need legacy I/O to the AGP bus?
>
> Some display cards (like voodoo) AFAIK, need us to tweak with the VGA IO
> registers. The interest in having something like ioportremap or similar
> is that we can have the platform specific code return a different base
> for VGA than other legacy devices, thus allowing us to have, for example,
> such a VGA card in the AGP slot and a legacy serial card in the PCI slots.
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Do these exist? I'm aware of legacy serial cards for ISA slots only.
AFAIK all PCI serial cards use PCI configuration and are handled separately by
serial.c.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dual head r128

[Benjamin Herrenschmidt]

>> Some display cards (like voodoo) AFAIK, need us to tweak with the VGA IO
>> registers. The interest in having something like ioportremap or similar
>> is that we can have the platform specific code return a different base
>> for VGA than other legacy devices, thus allowing us to have, for example,
>> such a VGA card in the AGP slot and a legacy serial card in the PCI slots.
>                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Do these exist? I'm aware of legacy serial cards for ISA slots only.
>AFAIK all PCI serial cards use PCI configuration and are handled
separately by
>serial.c.

Well, maybe they don't... this was an example provided by someone else. I
personally don't own anything that decodes legacy addresses anyway.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/