From: Timothy A. Seufert <hidden> Date: 2000-02-24 09:43:40
I'm having a problem with the assignment of I/O addresses to devices.
Multiple PCI devices end with the same I/O port address base,
presumably because OF didn't fully initialize them. I am using
Michael Lanner's PCI patch (applied to kernel 2.2.15-pre5 from cvs a
while back). After reading the patch, it looks like it only tries to
correct base addresses for being behind a bridge, so I don't think it
is either helping or hurting.
The devices getting the same I/O port are two Adaptec SCSI cards, a
new 39160 dual-channel and an older 2940UW which I've had for a
while. I also have a third SCSI card, an Atto UW (Apple OEM surplus
from the beige G3 era) installed, but it isn't affected by this
problem.
The 39160 isn't recognized. I initially thought this might be a
aic7xxx bug, but after I described all this in an email to Doug
Ledford (the aic7xxx author) he pointed out that the 2940 and the two
39160 channels all have the same I/O port base address, and that the
aic7xxx driver would refuse to init a card if its I/O resources were
already used. The 2940UW gets initialized first, so it wins.
Presumably if I removed it I'd get on one channel of the 39160.
So it would seem to me that we need some kind of a scheme for
allocating I/O port base addresses if OF didn't do it. I'm vaguely
familiar with the concepts behind PCI address space allocation,
having looked at it from the hardware design POV a while back, but
I'm not familiar enough with the kernel code yet to tackle this
problem (or to even be sure that I'm on the right track here).
Comments?
Potentially useful information from my machine:
PCI fixup boot messages:
PCI: Probing PCI hardware
PCI: setting IRQ 22 on device 00:80.
PCI: Correcting IOaddress 2 on device 00:80, now fe002001.
PCI: setting IRQ 21 on device 01:00.
PCI: Enabling memory for device 01:00
PCI: setting IRQ 26 on device 01:08.
PCI: Correcting IOaddress 0 on device 01:08, now fe001841.
PCI: Correcting IOaddress 1 on device 01:08, now fe001831.
PCI: Correcting IOaddress 2 on device 01:08, now fe001821.
PCI: Correcting IOaddress 3 on device 01:08, now fe001811.
PCI: Correcting IOaddress 4 on device 01:08, now fe001801.
PCI: setting IRQ 23 on device 01:10.
PCI: Correcting IOaddress 0 on device 01:10, now fe001401.
PCI: Enabling I/O for device 01:10
PCI: setting IRQ 24 on device 01:18.
PCI: Correcting IOaddress 0 on device 01:18, now fe000001.
PCI: Enabling I/O for device 01:18
PCI: setting IRQ 25 on device 01:20.
PCI: Correcting IOaddress 0 on device 01:20, now fe000001.
PCI: Correcting IOaddress 0 on device 01:21, now fe000001.
PCI: setting IRQ 28 on device 01:30.
(01:18 is the 2940UW, 01:20 and 01:21 are the two channels of the 39160.)
Results of lspci -v:
00:00.0 Host bridge: Motorola MPC106 [Grackle] (rev 40)
Flags: bus master, fast devsel, latency 0
00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev
02) (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: 00001000-00001fff
Memory behind bridge: 80800000-809fffff
Capabilities: [dc] Power Management version 1
00:10.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3
(rev 01) (prog-if 00 [VGA])
Subsystem: 3Dfx Interactive, Inc.: Unknown device 0005
Flags: fast devsel, IRQ 22
Memory at 82000000 (32-bit, non-prefetchable)
Memory at 90000000 (32-bit, prefetchable)
I/O ports at fe002000
Expansion ROM at 80a00000 [disabled]
Capabilities: [60] Power Management version 1
01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE
1394 Link Layer Controller (rev 02) (prog-if 00 [Generic])
Subsystem: Apple Computer Inc.: Unknown device 001c
Flags: bus master, medium devsel, latency 16, IRQ 21
Memory at 80886000 (32-bit, non-prefetchable)
Memory at 808c0000 (32-bit, non-prefetchable)
Memory at 808b0000 (32-bit, non-prefetchable)
Expansion ROM at 808a0000 [disabled]
01:01.0 IDE interface: CMD Technology Inc PCI0646 (rev 05) (prog-if
8f [Master SecP SecO PriP PriO])
Subsystem: CMD Technology Inc: Unknown device 0646
Flags: bus master, medium devsel, latency 64, IRQ 26
I/O ports at fe001840
I/O ports at fe001830
I/O ports at fe001820
I/O ports at fe001810
I/O ports at fe001800
Capabilities: [60] Power Management version 1
01:02.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR)
53c875 (rev 04)
Flags: bus master, medium devsel, latency 255, IRQ 23
I/O ports at fe001400
Memory at 80880000 (32-bit, non-prefetchable)
Memory at 80885000 (32-bit, non-prefetchable)
Expansion ROM at 80940000
01:03.0 SCSI storage controller: Adaptec AIC-7881U
Flags: bus master, medium devsel, latency 16, IRQ 24
I/O ports at fe000000
Memory at 80884000 (32-bit, non-prefetchable)
Expansion ROM at 80890000 [disabled]
01:04.0 SCSI storage controller: Adaptec 7899A (rev 01)
Subsystem: Adaptec: Unknown device f620
Flags: bus master, 66Mhz, medium devsel, latency 16, IRQ 25
BIST result: 00
I/O ports at fe000000
Memory at 80883000 (64-bit, non-prefetchable)
Expansion ROM at 80900000 [disabled]
Capabilities: [dc] Power Management version 2
01:04.1 SCSI storage controller: Adaptec 7899A (rev 01)
Subsystem: Adaptec: Unknown device f620
Flags: bus master, 66Mhz, medium devsel, latency 16
BIST result: 00
I/O ports at fe000000
Memory at 80882000 (64-bit, non-prefetchable)
Expansion ROM at 808e0000 [disabled]
Capabilities: [dc] Power Management version 2
01:05.0 Class ff00: Apple Computer Inc. Paddington Mac I/O
Flags: bus master, medium devsel, latency 16
Memory at 80800000 (32-bit, non-prefetchable)
01:06.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
Subsystem: OPTi Inc.: Unknown device c861
Flags: bus master, medium devsel, latency 16, IRQ 28
Memory at 80881000 (32-bit, non-prefetchable)
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-02-24 11:12:10
On Thu, Feb 24, 2000, Timothy A. Seufert [off-list ref] wrote:
01:04.0 SCSI storage controller: Adaptec 7899A (rev 01)
Subsystem: Adaptec: Unknown device f620
Flags: bus master, 66Mhz, medium devsel, latency 16, IRQ 25
BIST result: 00
I/O ports at fe000000
Memory at 80883000 (64-bit, non-prefetchable)
Expansion ROM at 80900000 [disabled]
Capabilities: [dc] Power Management version 2
01:04.1 SCSI storage controller: Adaptec 7899A (rev 01)
Subsystem: Adaptec: Unknown device f620
Flags: bus master, 66Mhz, medium devsel, latency 16
BIST result: 00
I/O ports at fe000000
Memory at 80882000 (64-bit, non-prefetchable)
Expansion ROM at 808e0000 [disabled]
Capabilities: [dc] Power Management version 2
Hum... Both cards are behind the PCI<->PCI bridges, and so they should
both have io addresses in the range fe001000 -> fe001fff
The fact that they are at fe000000 seems to indicate that the io base
address is 0 (and so was apparently _not_ assigned at all). Could you
break into OF, dev to those devices, and send me the output of
.properties ? (I need the content of the "reg" and "assigned addresses"
properties). I want to see what OF did with the cards exactly.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Timothy A. Seufert <hidden> Date: 2000-02-24 22:13:41
At 12:12 PM +0100 2/24/00, Benjamin Herrenschmidt wrote:
The fact that they are at fe000000 seems to indicate that the io base
address is 0 (and so was apparently _not_ assigned at all). Could you
break into OF, dev to those devices, and send me the output of
.properties ? (I need the content of the "reg" and "assigned addresses"
properties). I want to see what OF did with the cards exactly.
From: Benjamin Herrenschmidt <hidden> Date: 2000-03-02 14:22:44
Hi all !
I need reports about the PCI I/O space conflicts that have been mentioned
here. According to Apple, there is no known OF bug.
Please include your machine model, the dump of /proc/pci, and eventually
the result of lsprop on the offending card /proc/device-tree entries.
Note about the Adaptec problem reported earlier, this is apparently not
an OF bug, but a combination of an OF "feature" along with a bug in
Michel patches.
What I think happens is that the firmware (and I suspect this is done by
the Adaptec OF code on the card, not by OF itself) will "disable" the IO
accesses and decides that the card should use only memory-mapped
registers on PPC. It does this by writing 0 in the io space register, but
doesn't disable IO accesses to the card in the PCI config header (or
maybe they get re-enabled by the kernel fixup code). Also, I still have
to check if the bit 0 is actually 0 or 1.
However, Michel code doesn't see this and do it's fixup, causing a
remapping of the io space to fe000000 instead of leaving 0, which may let
some driver think the address was actually assigned. This is a problem
since in theory, io 0 is perfectly valid, isn't it ? In this case, it
should be considered wrong.
Anyway, I don't see at first why the driver would not work since both
cards have a valid memory base and the driver should be compiled with
MMIO enabled on PPC, and so should not use the IO address anyway.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-03-02 14:41:20
Hi,
Note about the Adaptec problem reported earlier, this is apparently not
an OF bug, but a combination of an OF "feature" along with a bug in
Michel patches.
What I think happens is that the firmware (and I suspect this is done by
the Adaptec OF code on the card, not by OF itself) will "disable" the IO
accesses and decides that the card should use only memory-mapped
registers on PPC. It does this by writing 0 in the io space register, but
doesn't disable IO accesses to the card in the PCI config header (or
maybe they get re-enabled by the kernel fixup code). Also, I still have
to check if the bit 0 is actually 0 or 1.
However, Michel code doesn't see this and do it's fixup, causing a
remapping of the io space to fe000000 instead of leaving 0, which may let
some driver think the address was actually assigned. This is a problem
since in theory, io 0 is perfectly valid, isn't it ? In this case, it
should be considered wrong.
No, 0 is special: if you set all programmable bits to zero (an I/O space
BAR will always have the LSB set), the corresponding decoder is disabled
per the PCI specification. I know devices that do not respect this point
however, and it is a mess for I/O space on machines which have ISA since
it interfers with some ISA standard, well-known, devices.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Hi all !
I need reports about the PCI I/O space conflicts that have been mentioned
here. According to Apple, there is no known OF bug.
Please include your machine model, the dump of /proc/pci, and eventually
the result of lsprop on the offending card /proc/device-tree entries.
Note about the Adaptec problem reported earlier, this is apparently not
an OF bug, but a combination of an OF "feature" along with a bug in
Michel patches.
What I think happens is that the firmware (and I suspect this is done by
the Adaptec OF code on the card, not by OF itself) will "disable" the IO
accesses and decides that the card should use only memory-mapped
registers on PPC. It does this by writing 0 in the io space register, but
doesn't disable IO accesses to the card in the PCI config header (or
maybe they get re-enabled by the kernel fixup code). Also, I still have
to check if the bit 0 is actually 0 or 1.
However, Michel code doesn't see this and do it's fixup, causing a
remapping of the io space to fe000000 instead of leaving 0, which may let
some driver think the address was actually assigned. This is a problem
since in theory, io 0 is perfectly valid, isn't it ? In this case, it
should be considered wrong.
Anyway, I don't see at first why the driver would not work since both
cards have a valid memory base and the driver should be compiled with
MMIO enabled on PPC, and so should not use the IO address anyway.
The driver wants to see a valid IO region in the config registers or else it
interprets the card as disabled. It also wants to see a unique value on each
card or else it interprets everything but the first instance as duplicates of
the first and ignores them (certain PCI busses have resulted in devices being
in the list multiple times, and certain BIOSes use setting the IO space to 0
to signal a card that is disabled in the BIOS). The driver already knows that
on PPC it needs to use MMAP I/O registers, so there isn't any hints needed
from the OF, and those hints only complicate matters further when trying to
keep the driver uniform across multiple architectures. If this is going to be
an ongoing problem, then I can make changes to the driver, it just means
having a few more #ifdef(__powerpc__) type stuff (ick).
--
Doug Ledford [off-list ref] http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-03-03 10:55:13
On Fri, Mar 3, 2000, Doug Ledford [off-list ref] wrote:
The driver wants to see a valid IO region in the config registers or else it
interprets the card as disabled. It also wants to see a unique value on each
card or else it interprets everything but the first instance as duplicates of
the first and ignores them (certain PCI busses have resulted in devices being
in the list multiple times, and certain BIOSes use setting the IO space to 0
to signal a card that is disabled in the BIOS). The driver already
knows that
on PPC it needs to use MMAP I/O registers, so there isn't any hints needed
from the OF, and those hints only complicate matters further when trying to
keep the driver uniform across multiple architectures. If this is going
to be
an ongoing problem, then I can make changes to the driver, it just means
having a few more #ifdef(__powerpc__) type stuff (ick).
In our case, I beleive we need to change the driver so that it ignores
the PIO addresses when they have not been assigned and there's a valid
MMIO address. I'll look at the driver again but I beleive the only place
where it can be a problem is the code that detects multiple instances of
the card. We can probably safely disable that code on all PPCs, or
eventually make it use MMIO when PIO are not available.
I'll see what I can do on my side but I don't have an Adaptec card to
test with.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Fri, Mar 3, 2000, Doug Ledford [off-list ref] wrote:
quoted
The driver wants to see a valid IO region in the config registers or else it
interprets the card as disabled. It also wants to see a unique value on each
card or else it interprets everything but the first instance as duplicates of
the first and ignores them (certain PCI busses have resulted in devices being
in the list multiple times, and certain BIOSes use setting the IO space to 0
to signal a card that is disabled in the BIOS). The driver already
knows that
quoted
on PPC it needs to use MMAP I/O registers, so there isn't any hints needed
from the OF, and those hints only complicate matters further when trying to
keep the driver uniform across multiple architectures. If this is going
to be
quoted
an ongoing problem, then I can make changes to the driver, it just means
having a few more #ifdef(__powerpc__) type stuff (ick).
In our case, I beleive we need to change the driver so that it ignores
the PIO addresses when they have not been assigned and there's a valid
MMIO address. I'll look at the driver again but I beleive the only place
where it can be a problem is the code that detects multiple instances of
the card. We can probably safely disable that code on all PPCs, or
eventually make it use MMIO when PIO are not available.
I'll see what I can do on my side but I don't have an Adaptec card to
test with.
I've made changes to the driver to make this work. However, it does not
compensate for multiple cards that have the same PIO address in the pdev
struct. That is as much a PPC PCI code bug as anything, and not something I
care to work around. It will use MMAPed I/O on PPC and if no PIO is available
and MMAP I/O isn't working then it skips the controller. It also won't detect
multiple instances of a card if the base address (with the PIO bit masked out)
is 0 (at least not based on PIO address, but it will still detect multiple
cards with the same MMAP I/O address). That should solve the problem as long
as the PCI code is fixed so it doesn't put out multiple cards with the same
PIO address any more.
--
Doug Ledford [off-list ref] http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Timothy A. Seufert <hidden> Date: 2000-03-03 08:39:47
At 3:22 PM +0100 3/2/00, Benjamin Herrenschmidt wrote:
Hi all !
I need reports about the PCI I/O space conflicts that have been mentioned
here. According to Apple, there is no known OF bug.
Please include your machine model, the dump of /proc/pci, and eventually
the result of lsprop on the offending card /proc/device-tree entries.
Do you need this info for my system, or was what I sent you enough?
Do you want a straight dump of /proc/pci, or one that has been
filtered for human consumption by lspci?
Note about the Adaptec problem reported earlier, this is apparently not
an OF bug, but a combination of an OF "feature" along with a bug in
Michel patches.
What I think happens is that the firmware (and I suspect this is done by
the Adaptec OF code on the card, not by OF itself) will "disable" the IO
accesses and decides that the card should use only memory-mapped
registers on PPC.
Hmmmm, consider the following: In my system I have two Adaptec
cards, a 2940UW and a 39160. Both are having the I/O base problem I
described to you, but only one card has OF code: I'm running the old
version 3.0 Mac firmware on the 2940UW, which predates New World
booting and has no OF code at all.
I have to run this because all firmware versions will hang during
MacOS boot when scanning a certain device on my bus, unless wide
negotatiation is turned off for that device. (aic7xxx has absolutely
no trouble scanning the same SCSI chain, so I'm pretty sure this is
an Adaptec Mac firmware bug.) Unfortunately, Adaptec took away the
ability to disable wide negotiation in the newer Mac firmware
versions.
If anybody knows a contact at Adaptec to report this bug, I'd
appreciate it -- I dread trying to make it known through their
apparently user-hostile tech support system.
It does this by writing 0 in the io space register, but
doesn't disable IO accesses to the card in the PCI config header (or
maybe they get re-enabled by the kernel fixup code).
I think the fixup code is re-enabling it if it can:
PCI: setting IRQ 24 on device 01:18.
PCI: Correcting IOaddress 0 on device 01:18, now fe000001.
PCI: Enabling I/O for device 01:18
PCI: setting IRQ 25 on device 01:20.
PCI: Correcting IOaddress 0 on device 01:20, now fe000001.
PCI: Correcting IOaddress 0 on device 01:21, now fe000001.
01:18 is the 2940UW, 01:20 and 01:21 the two channels of the 39160.
I remember looking at the code which enables I/O for a device, but it
wasn't clear to me at that time how it decided whether to enable I/O.
By the way, Doug, can you comment on whether the 39160 should get one
or two IRQs? I/O and memory base registers are clearly not shared
between the channels, but according to these boot messages, only one
channel gets assigned an IRQ. (I've confirmed this with lspci.)
I'm guessing only one is required, due to the need to conserve IRQs
in the PC world, but you never know.
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
PCI: setting IRQ 24 on device 01:18.
PCI: Correcting IOaddress 0 on device 01:18, now fe000001.
PCI: Enabling I/O for device 01:18
PCI: setting IRQ 25 on device 01:20.
PCI: Correcting IOaddress 0 on device 01:20, now fe000001.
PCI: Correcting IOaddress 0 on device 01:21, now fe000001.
01:18 is the 2940UW, 01:20 and 01:21 the two channels of the 39160.
I remember looking at the code which enables I/O for a device, but it
wasn't clear to me at that time how it decided whether to enable I/O.
By the way, Doug, can you comment on whether the 39160 should get one
or two IRQs? I/O and memory base registers are clearly not shared
between the channels, but according to these boot messages, only one
channel gets assigned an IRQ. (I've confirmed this with lspci.)
I'm guessing only one is required, due to the need to conserve IRQs
in the PC world, but you never know.
On all the recent dual channel controllers (meaning everything after the
original 3940 cards that had three large chips, a DEC bridge chip and two 7880
chips, where as the later 3940 cards have a 7895 chip and the dual channel
ultra2 and later cards are all single chip designs) the cards will route one
channel's interrupt through the INTA connector on the card edge and will route
the other channel's interrupt through the INTB connector on the card edge.
This is hard wired on the cards, so whether or not the channels share the same
interrupt is determined by whether or not the INTA and INTB connectors on a
single slot share the same interrupt. That is motherboard specific and
typically up to the machine's BIOS to set up in the interrupt tables so that
the kernel PCI code can read it and do the right thing.
--
Doug Ledford [off-list ref] http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-03-03 11:09:00
On Fri, Mar 3, 2000, Timothy A. Seufert [off-list ref] wrote:
No need for more lspci from you now, or eventually just send me what you
already sent, but without running Michel Lanners patch this time.
quoted
It does this by writing 0 in the io space register, but
doesn't disable IO accesses to the card in the PCI config header (or
maybe they get re-enabled by the kernel fixup code).
I think the fixup code is re-enabling it if it can:
PCI: setting IRQ 24 on device 01:18.
PCI: Correcting IOaddress 0 on device 01:18, now fe000001.
PCI: Enabling I/O for device 01:18
PCI: setting IRQ 25 on device 01:20.
PCI: Correcting IOaddress 0 on device 01:20, now fe000001.
PCI: Correcting IOaddress 0 on device 01:21, now fe000001.
01:18 is the 2940UW, 01:20 and 01:21 the two channels of the 39160.
I remember looking at the code which enables I/O for a device, but it
wasn't clear to me at that time how it decided whether to enable I/O.
My understanding for now is that the fixup code thinks the cards are
assigned IO address 0, not that they are disabled. So it does the fixup
of the pointer, but doesn't looks for a free io range. Could you check
if, before entering the fixup code, bit 0 of the IO base register is
actually 0 or 1 ? (If the register contains really 0x00000000 or
0x00000001). The first case would mean a disabled and non-assigned BAR,
the second would mean a valid BAR assigned to address 0.
Also, if you have it, please send me Michel patches as I didn't find them
on his page.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-03-04 10:16:19
Hi Tim,
A few more details on this issue (I've already responded to a later
mail in this thread, but I'm still struggling with my 3-weeks
800-message backlog ;-)
On 24 Feb, this message from Timothy A. Seufert echoed through cyberspace:
I'm having a problem with the assignment of I/O addresses to devices.
Multiple PCI devices end with the same I/O port address base,
presumably because OF didn't fully initialize them. I am using
Michael Lanner's PCI patch (applied to kernel 2.2.15-pre5 from cvs a
while back). After reading the patch, it looks like it only tries to
correct base addresses for being behind a bridge, so I don't think it
is either helping or hurting.
My patch corrects base addresses because the _host_ bridge isn't
address-transparent for IO regions. Memory regions are always
untranslated, and PCI-to-PCI bridges in Macs (as far as I've read
Apple's doc) don't do any address translation.
I've made the patch because I use a PCI IDE controller, and I was
annoyed by the fact that the PMac IDE code applies that translation for
PCI IO addresses in it's IO access macros. I think this translation
should be handled by PCI fixup code. Plus, you sometimes don't even
have a single translation, if you have multiple host bridges (that's
the case as well for UNI-North machines, even though all buses are PCI
0).
So it would seem to me that we need some kind of a scheme for
allocating I/O port base addresses if OF didn't do it. I'm vaguely
familiar with the concepts behind PCI address space allocation,
having looked at it from the hardware design POV a while back, but
I'm not familiar enough with the kernel code yet to tackle this
problem (or to even be sure that I'm on the right track here).
That should be handled by the new, 2.3 PCI code with dynamic resurce
allocation. I've just discovered that part, however, and am not at all
familiar with it. I'm RTFS'ing...
PCI: Correcting IOaddress 0 on device 01:18, now fe000001.
PCI: Enabling I/O for device 01:18
PCI: setting IRQ 25 on device 01:20.
PCI: Correcting IOaddress 0 on device 01:20, now fe000001.
PCI: Correcting IOaddress 0 on device 01:21, now fe000001.
PCI: setting IRQ 28 on device 01:30.
This is OF not initialising the IO spaces, and my patch not checking
for unassigned IO regions.
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/
From: Timothy A. Seufert <hidden> Date: 2000-03-04 12:15:51
At 11:16 AM +0100 3/4/00, Michel Lanners wrote:
quoted
So it would seem to me that we need some kind of a scheme for
allocating I/O port base addresses if OF didn't do it. I'm vaguely
familiar with the concepts behind PCI address space allocation,
having looked at it from the hardware design POV a while back, but
I'm not familiar enough with the kernel code yet to tackle this
problem (or to even be sure that I'm on the right track here).
That should be handled by the new, 2.3 PCI code with dynamic resurce
allocation. I've just discovered that part, however, and am not at all
familiar with it. I'm RTFS'ing...
Another piece of code to look at might be the Alpha arch PCI code in
2.2. From what I can tell it is doing complete configuration of PCI
by itself (apparently the firmware on Alpha boards doesn't do any PCI
config).
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
So it would seem to me that we need some kind of a scheme for
allocating I/O port base addresses if OF didn't do it. I'm vaguely
familiar with the concepts behind PCI address space allocation,
having looked at it from the hardware design POV a while back, but
I'm not familiar enough with the kernel code yet to tackle this
problem (or to even be sure that I'm on the right track here).
That should be handled by the new, 2.3 PCI code with dynamic resurce
allocation. I've just discovered that part, however, and am not at all
familiar with it. I'm RTFS'ing...
Another piece of code to look at might be the Alpha arch PCI code in
2.2. From what I can tell it is doing complete configuration of PCI
by itself (apparently the firmware on Alpha boards doesn't do any PCI
config).
Or the code in drivers/pci in current 2.3.x.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- 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/