Exposing ROM's though sysfs
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · --- Torrey Hoffman
This sounds interesting, but I'm curious... why? That is, what problem are you solving by making ROMs exposed?
Or is this just for fun? (That's a legitimate reason IMO...)
Secondary video cards need to have code in their ROMs run to reset them. When an x86 PC boots it only reset the primary video device, the secondary ones won't work until their ROMs are run.
Another group needing this is laptop suspend/resume. Some cards won't come back from suspend until their ROM is run to reinitialize them.
A third group is undocumented video hotware where the only way to set the screen mode is by calling INT10 in the video ROMs. (Intel i810,830,915 for example).
Small apps are attached to the hotplug events. These apps then use vm86 or emu86 to run the ROMs. emu86 is needed for ia64 or ppc when running x86 ROMs on them.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
Quoted 4 lines · Jon Smirl
Quoted 3 lines · --- Torrey Hoffman
This sounds interesting, but I'm curious... why? That is, what problem are you solving by making ROMs exposed?
Quoted 8 lines
Quoted 1 line
Or is this just for fun? (That's a legitimate reason IMO...)
Secondary video cards need to have code in their ROMs run to reset them. When an x86 PC boots it only reset the primary video device, the secondary ones won't work until their ROMs are run.
Another group needing this is laptop suspend/resume. Some cards won't come back from suspend until their ROM is run to reinitialize them.
Another trick laptops can do is that after a resume the card is in uninitialized state _and_ the video ROM is not there, because the system BIOS didn't copy it to the right location (when it's stored in a shared flash). Then you definitely need your own copy from the real boot.
Quoted 7 lines
A third group is undocumented video hotware where the only way to set the screen mode is by calling INT10 in the video ROMs. (Intel i810,830,915 for example).
Small apps are attached to the hotplug events. These apps then use vm86 or emu86 to run the ROMs. emu86 is needed for ia64 or ppc when running x86 ROMs on them.
I'm starting to think that using emu86 always (independent on the architecture) would be best. It's not like the execution speed is the limit with video init, and it'll allow to find more bugs in emu86 when it's used on i386 as well. It'll be needed for x86-64 (AMD64 and intel EM64T) anyway.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 5 lines · Vojtech Pavlik
I'm starting to think that using emu86 always (independent on the architecture) would be best. It's not like the execution speed is the limit with video init, and it'll allow to find more bugs in emu86 when it's used on i386 as well. It'll be needed for x86-64 (AMD64 and intel EM64T) anyway.
Yeah, I was thinking the same thing, but emu86 needs some fixes to work on an x86 host apparently...
Jesse
Quoted 9 lines · Jesse Barnes
Quoted 5 lines · Vojtech Pavlik
I'm starting to think that using emu86 always (independent on the architecture) would be best. It's not like the execution speed is the limit with video init, and it'll allow to find more bugs in emu86 when it's used on i386 as well. It'll be needed for x86-64 (AMD64 and intel EM64T) anyway.
Yeah, I was thinking the same thing, but emu86 needs some fixes to work on an x86 host apparently...
emu86 is rather buggy. It can't boot C&T BIOSes for example. qemu might be a better engine for this anyway in truth.
Quoted 3 lines
emu86 is rather buggy. It can't boot C&T BIOSes for example. qemu might be a better engine for this anyway in truth.
And I like the idea of chosing a solution that won't limit us to x86 hosts anyway ;)
With proper support from the "VGA arbitration driver" that Jon talked about earlier, that should be quite portable, the kernel driver doing the job of providing PIO accessors to VGA space and mmap functionality for VGA memory hole if it exist (can modern cards be POST'ed with an x86 BIOS on machines that won't let you access any VGA memory hole, that is that won't let you generate PCI memory cycles to low addresses that overlap RAM ? If yes, then pmacs would be able to soft-boot x86 cards that way).
Ben.
Quoted 5 lines · Benjamin Herrenschmidt
Quoted 2 lines
emu86 is rather buggy. It can't boot C&T BIOSes for example. qemu might be a better engine for this anyway in truth.
And I like the idea of chosing a solution that won't limit us to x86 hosts anyway ;)
Yeah, me too!
Quoted 7 lines
With proper support from the "VGA arbitration driver" that Jon talked about earlier, that should be quite portable, the kernel driver doing the job of providing PIO accessors to VGA space and mmap functionality for VGA memory hole if it exist (can modern cards be POST'ed with an x86 BIOS on machines that won't let you access any VGA memory hole, that is that won't let you generate PCI memory cycles to low addresses that overlap RAM ? If yes, then pmacs would be able to soft-boot x86 cards that way).
So you can do port I/O on low addresses but not memory accesses? For some cards simply throwing away reads and writes to the low memory area is probably ok since it'll just be doing things like printing a BIOS banner or a pretty logo. But then again, I've never disassembled one so I can't be sure. Alan would probably know though :)
If you can't do legacy port I/O on a given bus though, I think you'd be out of luck wrt POSTing a card with an x86 BIOS.
Jesse
Quoted 6 lines
So you can do port I/O on low addresses but not memory accesses? For some cards simply throwing away reads and writes to the low memory area is probably ok since it'll just be doing things like printing a BIOS banner or a pretty logo. But then again, I've never disassembled one so I can't be sure. Alan would probably know though :)
Yes, typically, on Apple north bridges, you have the PIO space memory mapped somewhere in the CPU address space, generating IO cycles from 0 to N (usually 16Mb), but the MMIO space is directly mapped 1:1 from 0x8000000.
Quoted 2 lines
If you can't do legacy port I/O on a given bus though, I think you'd be out of luck wrt POSTing a card with an x86 BIOS.
Port IO should be fine in most cases (there might be one or 2 weird cases with earlier models, but overall, it's fine). The typical case is a machine using Apple "UniNorth" chipset (the one that supports AGP, been out for a while now), since the AGP slot and the PCI bus are on 2 separate domains. Both can do Port IO at any low address, but they are completely separate domains.
All this could be very nicely dealt with by the kernel driver.
Ben.
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
Quoted 1 line · Benjamin Herrenschmidt
All this could be very nicely dealt with by the kernel driver.
So what requirements have we collected so far?
o device selection (presumably domain, bus, slot, function) i.e. select the device you'd like to manipulate
ioctl?
o per-domain & device VGA enable/disable
need to disable VGA ports on cards in the same domain and/or bus ioctl?
o legacy port I/O
for properly routing I/O in multi-domain machines and machines where the kernel or firmware may need to trap master aborts read/write?
o legacy memory mapping
for mapping the legacy VGA framebuffer, may fail
mmap?
Is that a complete list? Of course, the interface mechanisms are up for debate too. We might be able to do it with per-bus or per-domain files in sysfs for the legacy I/O and memory stuff, but that might not represent the fact that legacy devices have interdependencies very well (e.g. VGA ports must be disabled on device A before we poke device B, etc.).
Thanks,
Jesse
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
What should the API for this look like? We could add a VGA={0/1} attribute to all the VGA devices in sysfs.
But then how do you:
1) list all of the conflicting VGA devices in a domain?
2) turn off all the VGA devices in a domain?
We could build a bus like directory structure in /sys/class
/sys/class/vga/domain1/vga1/(device/driver/enable) /sys/class/vga/domain1/vga2/(device/driver/enable) /sys/class/vga/domain2/vga1/(device/driver/enable) /sys/class/vga/domain2/vga2/(device/driver/enable)
Then add an enable attribute in the domain directories that would shut off all of the subdevices.
/sys/class/vga/domain1/enable/sys/class/vga/domain2/enable
But the vga driver is not going to be attached to a device. Is there an easy way to build this is sysfs?
Quoted 30 lines · --- Jesse Barnes
Quoted 1 line · Benjamin Herrenschmidt
All this could be very nicely dealt with by the kernel driver.
So what requirements have we collected so far?
o device selection (presumably domain, bus, slot, function) i.e. select the device you'd like to manipulate ioctl?
o per-domain & device VGA enable/disable
need to disable VGA ports on cards in the same domain and/or bus ioctl?
o legacy port I/O
for properly routing I/O in multi-domain machines and machines
where the
kernel or firmware may need to trap master aborts read/write?
o legacy memory mapping
for mapping the legacy VGA framebuffer, may fail mmap?Is that a complete list? Of course, the interface mechanisms are up for
debate too. We might be able to do it with per-bus or per-domain files in
sysfs for the legacy I/O and memory stuff, but that might not represent the
fact that legacy devices have interdependencies very well (e.g. VGA ports
must be disabled on device A before we poke device B, etc.).
Quoted 3 lines
Thanks,
Jesse
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
Quoted 14 lines · Jon Smirl
What should the API for this look like? We could add a VGA={0/1} attribute to all the VGA devices in sysfs.
But then how do you:
1) list all of the conflicting VGA devices in a domain?
2) turn off all the VGA devices in a domain?We could build a bus like directory structure in
/sys/class/sys/class/vga/domain1/vga1/(device/driver/enable) /sys/class/vga/domain1/vga2/(device/driver/enable) /sys/class/vga/domain2/vga1/(device/driver/enable) /sys/class/vga/domain2/vga2/(device/driver/enable)
Quoted 8 lines
Then add an enable attribute in the domain directories that would shut off all of the subdevices.
/sys/class/vga/domain1/enable/sys/class/vga/domain2/enableBut the vga driver is not going to be attached to a device. Is there an easy way to build this is sysfs?
Maybe we need a display driver class? Could we reuse the dri drivers for that purpose?
Jesse
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
Quoted 2 lines · Jesse Barnes
Maybe we need a display driver class? Could we reuse the dri drivers for that purpose?
Display and VGA devices do not correlate neatly. There are non VGA devices we treat as video, and VGA devices we don't use when using the hardware ourselves because its switched out of the video side (eg on the Oxygen GMX)
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
In reply to Jon SmirlQuoted 6 lines · Jon Smirl
What should the API for this look like? We could add a VGA={0/1} attribute to all the VGA devices in sysfs.
But then how do you:
1) list all of the conflicting VGA devices in a domain?
2) turn off all the VGA devices in a domain?
1. Is part of the PCI specification since there is a PCI class for VGA video devices. 2 follows naturally from 1
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
I know internally how to find the VGA cards using the PCI class. I meant this in the context of how do you enumerate all of the VGA devices in a domain from a user space app. What is the API for this? What is the user space API for turning off all of the VGA devices in a domain?
Quoted 4 lines · --- Alan Cox
Quoted 3 lines · Jon Smirl
What should the API for this look like? We could add a VGA={0/1} attribute to all the VGA devices in sysfs.
Quoted 8 lines
Quoted 3 lines
But then how do you:
1) list all of the conflicting VGA devices in a domain?
2) turn off all the VGA devices in a domain?1. Is part of the PCI specification since there is a PCI class for VGA video devices. 2 follows naturally from 1
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
Quoted 5 lines · Jon Smirl
I know internally how to find the VGA cards using the PCI class. I meant this in the context of how do you enumerate all of the VGA devices in a domain from a user space app. What is the API for this? What is the user space API for turning off all of the VGA devices in a domain?
I don't follow the logic behind the question. Once you have the vga locking device then that needs to handle the vga on/off.
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
What is the API that a user space apps will use to control the state of VGA devices?
For example:
1) a standard device exposing IOCTLs needing an header file describing it.
or 2) Building a new tree in /sys/class/vga that uses attributes to control the state. you turn the device on by copying a '1' to the attribute.
Once we pick sysfs or ioctl API, what should the full set of calls look like?
Quoted 4 lines · --- Alan Cox
Quoted 3 lines · Jon Smirl
I know internally how to find the VGA cards using the PCI class. I meant this in the context of how do you enumerate all of the VGA devices in a domain from a user space app. What is the API for
Quoted 9 lines
this?
Quoted 1 line
What is the user space API for turning off all of the VGA devices
in a
Quoted 1 line
domain?
I don't follow the logic behind the question. Once you have the vga locking device then that needs to handle the vga on/off.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
In reply to Alan CoxAttached is a real world reason why we need a VGA control device. VesaFB loads and marks the VGA screen region as reserved. The driver does not attach to any device.
My new radeon DRM driver load and says no one is using the radeon card, so it can drive it. Radeon loads and fails. It can attach the PCI device but it can't reserve the memory block.
The short term fix for this is to make VesaFB aware of the PCI ROM patch. The PCI ROM patch makes it possible to identify the boot video device. Once VesaFB can identify the boot video device it can properly attach itself to both the device and memory. Then DRM radeon loads after vesafb it will find the PCI device already has a driver attached and revert back into stealth compatibility mode.
Long term we need the vga control device and a unified DRM/fbdev.
The immediate work around is to use the radeonfb driver instead of vesafb. The radeonfb driver marks the PCI device in use and triggers stealth mode in radeon.
Quoted 256 lines · --- Alex Romosan
To: Dave Airlie <[email protected]>
CC: [email protected]
Subject: Re: r200 oops
From: Alex Romosan <[email protected]>
Date: Thu, 19 Aug 2004 17:59:51 -0700Quoted 1 line · Dave Airlie
can you insert the module with drm_opts=debug option and see what
it
Quoted 1 line
says..
[drm] Debug messages ON
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 4 (level, low) -> IRQ 4 [drm:radeon_register_regions] *ERROR* cannot reserve FB regionUnable to handle kernel NULL pointer dereference at virtual address00000000
printing eip:e1195520
*pde = 00000000Oops: 0002 [#1] PREEMPT Modules linked in: radeon sd_mod scsi_mod autofs4 microcode aes_i586 airo ehci_hcd uhci_hcd usbcore parport_pc parport irtty_sir sir_dev irda crc_ccitt joydev evdev nls_iso8859_1 ntfs yenta_socket CPU: 0 EIP: 0060:[<e1195520>] Not tainted EFLAGS: 00010246 (2.6.8.1)EIP is at
radeon_stub_putminor+0x20/0x110[radeon]
eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00000000
esi: 00000000 edi: ffffffea ebp:dc479e6cesp:dc479e5c
ds: 007b es: 007b ss: 0068
Process insmod (pid: 2118, threadinfo=dc478000 task=df6e0cd0)Stack: dc479e78 00000000 00000000 00000000 dc479e84 e1195913 e11a363a e11a00f3 00000000 e11ab9e0 dc479ed0 e1191488 e11a37f0 e119fed0 dc479eac c017c056 41254b8f dbbab424 db054540 00000000 e11a9e18 c15c9c00 00000000 dbbab424 Call Trace: [<c010545a>] show_stack+0x7a/0x90 [<c01055d9>] show_registers+0x149/0x1a0 [<c010576d>] die+0x8d/0x100 [<c0114465>] do_page_fault+0x1e5/0x567 [<c01050f5>] error_code+0x2d/0x38 [<e1195913>] radeon_stub_unregister+0x33/0x60 [radeon] [<e1191488>] drm_probe+0x208/0x270 [radeon] [<c01cc9d9>] pci_device_probe_static+0x49/0x60 [<c01cca27>] __pci_device_probe+0x37/0x50 [<c01cca66>] pci_device_probe+0x26/0x50 [<c0211f75>] bus_match+0x35/0x70 [<c02120a9>] driver_attach+0x59/0x90 [<c021254c>] bus_add_driver+0x8c/0xb0 [<c0212a6b>] driver_register+0x2b/0x30 [<c01ccc99>] pci_register_driver+0x59/0x80 [<e0fee09d>] drm_init+0x9d/0xd7 [radeon] [<c012e178>] sys_init_module+0xf8/0x210 [<c0104f4b>] syscall_call+0x7/0xb Code: c7 04 10 00 00 00 00 a1 f0 d7 1a e1 89 4c 10 04 a1 f0 d7 1a Segmentation faultQuoted 1 line
can you also send on lspci -v and the contents of
/proc/iomemlspci -v:
0000:00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03)
Subsystem: IBM: Unknown device 0529
Flags: bus master, fast devsel, latency 0 Memory atd0000000(32-bit, prefetchable) [size=256M]
Capabilities: [e4] #09 [f104]
Capabilities: [a0] AGP version 2.00000:00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, fast devsel, latency 96 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 00003000-00003fff Memory behind bridge: c0100000-c01fffff Prefetchable memory behind bridge: e0000000-e7ffffff0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI])
Subsystem: IBM: Unknown device 052d
Flags: bus master, medium devsel, latency 0, IRQ 4 I/O ports at 1800 [size=32]0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI])
Subsystem: IBM: Unknown device 052d
Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at 1820 [size=32]0000:00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) (prog-if 00 [UHCI])
Subsystem: IBM: Unknown device 052d
Flags: bus master, medium devsel, latency 0, IRQ 6 I/O ports at 1840 [size=32]0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller (rev 01) (prog-if 20 [EHCI])
Subsystem: IBM: Unknown device 052e
Flags: bus master, medium devsel, latency 0, IRQ 11 Memory atc0000000(32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] #0a [2080]0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=08, sec-latency=64 I/O behind bridge: 00004000-00008fff
Memory behind bridge: c0200000-cfffffff Prefetchable memory behind bridge: e8000000-efffffff0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01)
Flags: bus master, medium devsel, latency 00000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 01) (prog-if 8a [Master SecP PriP])
Subsystem: IBM: Unknown device 052d
Flags: bus master, medium devsel, latency 0, IRQ 6 I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at 1860 [size=16]
Memory at 20000000 (32-bit, non-prefetchable) [size=1K]0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
Subsystem: IBM: Unknown device 052d
Flags: medium devsel, IRQ 5
I/O ports at 1880 [size=32]0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
Subsystem: IBM: Unknown device 0537 Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at 1c00 [size=256] I/O ports at 18c0 [size=64] Memory at c0000c00 (32-bit, non-prefetchable) [size=512] Memory at c0000800 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 20000:00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) (prog-if 00 [Generic])
Subsystem: IBM: Unknown device 0525
Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at 2400 [size=256]
I/O ports at 2000 [size=128]
Capabilities: [50] Power Management version 20000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 02) (prog-if 00 [VGA])
Subsystem: IBM: Unknown device 0531
Flags: bus master, stepping, fast Back2Back, 66MHz, medium devsel,
latency 66, IRQ 4Memory at e0000000 (32-bit, prefetchable) [size=128M] I/O ports at 3000 [size=256] Memory at c0100000 (32-bit, non-prefetchable) [size=64K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 20000:02:00.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01)
Subsystem: IBM ThinkPad T30/T40 Flags: bus master, medium devsel, latency 168, IRQ 4 Memory at b0000000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=03, subordinate=06, sec-latency=176 Memory window 0: 20400000-207ff000 (prefetchable) Memory window 1: 20800000-20bff000 I/O window 0: 00004000-000040ff I/O window 1: 00004400-000044ff 16-bit legacy interface ports at 00010000:02:00.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01)
Subsystem: IBM ThinkPad T30/T40 Flags: bus master, medium devsel, latency 168, IRQ 5 Memory at b1000000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176 Memory window 0: 20c00000-20fff000 (prefetchable) Memory window 1: 21000000-213ff000 I/O window 0: 00004800-000048ff I/O window 1: 00004c00-00004cff 16-bit legacy interface ports at 00010000:02:01.0 Ethernet controller: Intel Corp. 82540EP Gigabit Ethernet Controller (Mobile) (rev 03)
Subsystem: IBM PRO/1000 MT Mobile Connection
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 4 Memory atc0220000(32-bit, non-prefetchable) [size=128K] Memory atc0200000(32-bit, non-prefetchable) [size=64K] I/O ports at 8400 [size=64]
Capabilities: [dc] Power Management version 2
Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0
Enable-0000:02:02.0 Network controller: AIRONET Wireless Communications Cisco Aironet Wireless 802.11b
Subsystem: AIRONET Wireless Communications: Unknown device 5000
Flags: bus master, fast devsel, latency 64, IRQ 6 I/O ports at 8000 [size=256]
Memory atc0210000(32-bit, non-prefetchable) [size=16K] Memory atc0400000(32-bit, non-prefetchable) [size=4M]
Capabilities: [40] Power Management version 2
Capabilities: [48] Vital Product Data
/proc/iomem:00000000-0009efff : System RAM 0009f000-0009ffff : reserved 000a0000-000bffff : Video RAM area 000c0000-000cffff : Video ROM 000e0000-000effff : Extension ROM 000f0000-000fffff : System ROM 00100000-1ff5ffff : System RAM
00100000-003056de : Kernel code 003056df-003dd13f : Kernel data
1ff60000-1ff76fff : ACPI Tables 1ff77000-1ff78fff : ACPI Non-volatile Storage 1ff80000-1fffffff : reserved 20000000-200003ff : 0000:00:1f.1 20400000-207fffff : PCI CardBus #03 20800000-20bfffff : PCI CardBus #03 20c00000-20ffffff : PCI CardBus #07 21000000-213fffff : PCI CardBus #07 b0000000-b0000fff : 0000:02:00.0
b0000000-b0000fff :yenta_socket
b1000000-b1000fff : 0000:02:00.1
b1000000-b1000fff :yenta_socket
c0000000-c00003ff : 0000:00:1d.7
c0000000-c00003ff :ehci_hcd
c0000800-c00008ff : 0000:00:1f.5
c0000800-c00008ff : Intel 82801DB-ICH4 - Controller
c0000c00-c0000dff : 0000:00:1f.5
c0000c00-c0000dff : Intel 82801DB-ICH4 - AC'97
c0100000-c01fffff : PCI Bus #01
c0100000-c010ffff : 0000:01:00.0c0100000-c010ffff : radeonc0200000-c020ffff : 0000:02:01.0
c0200000-c020ffff : e1000
c0210000-c0213fff : 0000:02:02.0
c0210000-c0213fff : eth1
c0220000-c023ffff : 0000:02:01.0
c0220000-c023ffff : e1000
c0400000-c07fffff : 0000:02:02.0
c0400000-c043ffff : eth1
d0000000-dfffffff : 0000:00:00.0
e0000000-e7ffffff : PCI Bus #01
e0000000-e7ffffff : 0000:01:00.0
Quoted 27 lines
e0000000-e059b8bf : vesafbff800000-ffffffff : reserved
i am sending the laptop back to ibm so i won't be able to run any tests for a while. hope this helps.
--alex--
Signature · 17 lines
| I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
Quoted 8 lines · Jon Smirl
Attached is a real world reason why we need a VGA control device. VesaFB loads and marks the VGA screen region as reserved. The driver does not attach to any device.
My new radeon DRM driver load and says no one is using the radeon card, so it can drive it. Radeon loads and fails. It can attach the PCI device but it can't reserve the memory block.
Quoted 6 lines
The short term fix for this is to make VesaFB aware of the PCI ROM patch. The PCI ROM patch makes it possible to identify the boot video device. Once VesaFB can identify the boot video device it can properly attach itself to both the device and memory. Then DRM radeon loads after vesafb it will find the PCI device already has a driver attached and revert back into stealth compatibility mode.
Well, the stealth compatibility mode is even uglier than VesaFB not claiming the PCI device, so I don't think it's really worth it for this reason.
You can just as well enable the stealth mode if you can't get the resources.
Quoted 1 line
Long term we need the vga control device and a unified DRM/fbdev.
We really need that. And we need it to be able to kick VESAfb out using sysfs when it loads. For that you'll need to make VESAfb grab the VGA PCI device.
Quoted 3 lines
The immediate work around is to use the radeonfb driver instead of vesafb. The radeonfb driver marks the PCI device in use and triggers stealth mode in radeon.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
Quoted 3 lines · --- Vojtech Pavlik
Well, the stealth compatibility mode is even uglier than VesaFB not claiming the PCI device, so I don't think it's really worth it for this reason.
Stealth mode will die the minute DRM and fbdev merge but until then we have no choice. DRM has always run in steath mode, the new feature is the mode where DRM claims the resources.
Quoted 3 lines
You can just as well enable the stealth mode if you can't get the resources.
I'll go look and see if I can modify the DRM probe function to claim PCI device and resources before returning instead of just the device. Before this it never occured to me that a driver would claim resources without also claiming the device. Claiming both should be a simpler solution than trying to fix VesaFB.
=====
Jon Smirl
[email protected]
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
Re: legacy VGA device requirements (was: Exposing ROM's though sysfs)
In reply to Jon SmirlQuoted 3 lines · Jon Smirl
Attached is a real world reason why we need a VGA control device. VesaFB loads and marks the VGA screen region as reserved. The driver does not attach to any device.
You'll love this: The vesafb device might not be a VGA device. In certain modes the Weitek P9100 is an example of this as in higher modes it turns off its inbuilt 5286 and flips to the P9x00 engine which is nonvga.
Quoted 4 lines
The short term fix for this is to make VesaFB aware of the PCI ROM patch. The PCI ROM patch makes it possible to identify the boot video device. Once VesaFB can identify the boot video device it can properly attach itself to both the device and memory. Then DRM radeon loads
Device yes, memory we already know. We currently don't register the memory always because it may not be in the ISA/PCI space. However we can certainly walk the bars now you can find the boot video device and use that to see if the video memory reported by the VESA bios is in any of them. The other complication is that we can't use the PCI device level allocator here because some PCI devices have video and other functionality on one chip. Not however a problem if you grab just the single resource.
Alan
Ben, can you put together a first pass on a "VGA arbitration driver"? You probably know more about the quirks necessary on non-x86 platforms than anyone else. I can help from the desktop x86 side but I've never worked on high end hardware that allows things like multiple active VGA devices. I'm sure the Mac machines and ia64 systems will need some special code too.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
Quoted 6 lines · Jon Smirl
Ben, can you put together a first pass on a "VGA arbitration driver"? You probably know more about the quirks necessary on non-x86 platforms than anyone else. I can help from the desktop x86 side but I've never worked on high end hardware that allows things like multiple active VGA devices. I'm sure the Mac machines and ia64 systems will need some special code too.
At this point, even the kernel doesn't have internally the necessary platform hooks for dealing with multi domains legacy port IOs or VGA memory space, it's all plaform hacks. But we can define an API at least for userland and fix the kernel driver afterward.
I'm fairly busy this week, so it would be nice if you guys could come up with some rough idea of the API you think the kernel driver should provide (a /dev entry with ioctl's ? Linus won't be too happy ... something in sysfs ?) and I can sit down & code something hopefully next week end and/or next week.
Jesse did a pretty good summary of what features need to be provided though. Note also that this "arbitration" layer may also need an in-kernel API for things like vgacon or whatever may want to "grab" access to the VGA device.
I suggest that at this point, we don't try to bother with simultaneous access to devices on separate PCI domains, but just use an in-kernel semaphore to arbitrate the single user at a given point in time who "owns" the VGA access, whatever bus it is on. So we need 2 things, both in-kernel and for userland:
- A way to identify a VGA device on a given bus. Could this be a PCI
ID (or in kernel a pci_dev ?). That would mean no support for non-PCI stuffs, how bad would that be ? Or we can try to be more smart and have userland pass an ID string that contains the bus type, leaving us with some room for accomodation of crappy bus types (read: embedded).
Maybe we just need to add to any entry in sysfs that is a VGA device some kind of "vga_token" attribute that contains a "magic string" to be then used with the driver for identification purposes ? For in kernel, we then just use the pci_dev, with a special case for "legacy non-PCI" VGA ?
- Basic API for grabbing/releasing the VGA lock, passing a given ID. This
would both take the exclusive access lock, and "set" IOs to the given device (enable IOs to it). The API doesn't prevent future implementation of per-domain locks if we want to have some concurrency here, though I feel that's useless. The kernel-side is simple, the userland side could be an ioctl (hrm....). However, should it be blocking or of trylock kind ? I don't like the idea of userland beeing able to block the kernel (vgacon or whoever else in the kernel need to do legacy IOs). Also, some console drivers still need to run in 'atomic' environment, though we did move a lot of things down to normal task protected by the console semaphore, the printk and blanking code path, afaik, are still a problem. So a simple semaphore may not do the trick. We could simply abuse the console sem instead for now as our VGA lock, which means that an fb driver would alwyas be called with the lock already held... but then, we still need a call to "set" the current active VGA device while already owning the lock... I liked the idea of having one single call doing both. Alan, what is your opinion there ?
- In kernel API for vga_inX/outX and vga mem access on a given device
- Userland should use read/write for IOs imho, either to a /dev device
(with maybe an ioctl to switch between PIO and VGA mem, though mmap is better for the later) or to some sysfs entry (in which case, can we add mmap call to a sysfs attribute ? last time I looked, it wasn't simple).
Ben.
Quoted 4 lines · Benjamin Herrenschmidt
Jesse did a pretty good summary of what features need to be provided though. Note also that this "arbitration" layer may also need an in-kernel API for things like vgacon or whatever may want to "grab" access to the VGA device.
Good point, I forgot about that. Theoretically, as long as a device has been POSTed, vgacon should work just fine with some small tweaks on platforms that allow mapping of the VGA framebuffer.
Quoted 5 lines
I suggest that at this point, we don't try to bother with simultaneous access to devices on separate PCI domains, but just use an in-kernel semaphore to arbitrate the single user at a given point in time who "owns" the VGA access, whatever bus it is on. So we need 2 things, both in-kernel and for userland:
Sounds good. Cards usually POST pretty quickly, so that won't be a problem until someone puts 32 cards in a system (oh wait, that's not too far off :).
Quoted 3 lines
- A way to identify a VGA device on a given bus. Could this be a PCI
ID (or in kernel apci_dev?). That would mean no support for non-PCI stuffs, how bad would that be ?
I personally don't care about anything but PCI, AGP and PCI-Express, but you make a good point about embedded stuff.
Quoted 4 lines
- Userland should use read/write for IOs imho, either to a /dev device
(with maybe an ioctl to switch between PIO and VGA mem, though mmap is better for the later) or to some sysfs entry (in which case, can we add mmap call to a sysfs attribute ? last time I looked, it wasn't simple).
Yeah, that sounds reasonable. I'd vote for a real device as opposed to sysfs files, for now at least.
Jesse