pci in arch/powerpc vs arch/ppc

Hi all,
in the old arch/ppc tree, there was a function called pq2ads_setup_pci()  
that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering, where  
are these registers configured now in arch/powerpc? I can't seem to find  
these code now.

Also, I can see that now bus 0, dev 0 (which I think represents the host  
bridge, right?) is now excluded using pq2_pci_exclude_device, but it  
wasn't in older code. Why is that?

thank you in advance...

On Fri, Aug 03, 2007 at 05:58:56PM +0300, Alexandros Kostopoulos wrote:

Hi all,
in the old arch/ppc tree, there was a function called pq2ads_setup_pci()  
that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering, where  
are these registers configured now in arch/powerpc? I can't seem to find  
these code now.

It's done by the firmware or the bootwrapper.

Also, I can see that now bus 0, dev 0 (which I think represents the host  
bridge, right?) is now excluded using pq2_pci_exclude_device, but it  
wasn't in older code. Why is that?

The older code probably either excluded all host bridges by class, or
just lived with the error message that gets printed on boot.

-Scott

On Aug 3, 2007, at 3:10 PM, Scott Wood wrote:

On Fri, Aug 03, 2007 at 05:58:56PM +0300, Alexandros Kostopoulos  
wrote:

quoted

Hi all,
in the old arch/ppc tree, there was a function called  
pq2ads_setup_pci()
that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering,  
where
are these registers configured now in arch/powerpc? I can't seem  
to find
these code now.

It's done by the firmware or the bootwrapper.

quoted

Also, I can see that now bus 0, dev 0 (which I think represents  
the host
bridge, right?) is now excluded using pq2_pci_exclude_device, but it
wasn't in older code. Why is that?

The older code probably either excluded all host bridges by class, or
just lived with the error message that gets printed on boot.

This will change in 2.6.24.  I've fixed the reason we excluded the  
host bridges on Freescale host bridges.

- k

Except from some macros arch/powerpc/include/asm/io.h / mpc8260_pci9.h, I  
can seem to find anywhere the code regarding PCI Erratum 9. The defined  
macros(in io.h) for read/write are sufficient as a workaround for PCI9?  
Who does DMA and register initialization for this (it used to be done in  
arch/ppc/syslib/m8260_pci_erratum9.c in arc/ppc). Maybe u-boot or the  
bootwrapper?

Another question regarding resource allocation: when  
alloc_resource(pci_32.c), called from pcibios_allocate_resources(), during  
pcibios init, attempts to allocate resources using request_resource(), the  
request fails. This seems to happen because the previously scanned PCI  
devices request resources in the form, e.g. 00000- 0000f (i.e. starting  
 from zero), and this should be mapped somewhere else in cpu mem space. My  
question (in order to find my bug) is, who performs this mapping, from PCI  
space to CPU space, the kernel (and if yes, where?) or the host bridge (in  
which case, I've probably failed to configure it properly).

Thank you

On Sat, 04 Aug 2007 19:39:58 +0300, Kumar Gala [off-list ref]  
wrote:

On Aug 3, 2007, at 3:10 PM, Scott Wood wrote:

quoted

On Fri, Aug 03, 2007 at 05:58:56PM +0300, Alexandros Kostopoulos wrote:

quoted

Hi all,
in the old arch/ppc tree, there was a function called  
pq2ads_setup_pci()
that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering, where
are these registers configured now in arch/powerpc? I can't seem to  
find
these code now.

It's done by the firmware or the bootwrapper.

quoted

quoted

Also, I can see that now bus 0, dev 0 (which I think represents the  
host
bridge, right?) is now excluded using pq2_pci_exclude_device, but it
wasn't in older code. Why is that?

The older code probably either excluded all host bridges by class, or
just lived with the error message that gets printed on boot.

This will change in 2.6.24.  I've fixed the reason we excluded the host  
bridges on Freescale host bridges.

- k

Alexandros Kostopoulos wrote:

Except from some macros arch/powerpc/include/asm/io.h / mpc8260_pci9.h, 
I  can seem to find anywhere the code regarding PCI Erratum 9. The 
defined  macros(in io.h) for read/write are sufficient as a workaround 
for PCI9?  Who does DMA and register initialization for this (it used to 
be done in  arch/ppc/syslib/m8260_pci_erratum9.c in arc/ppc). Maybe 
u-boot or the  bootwrapper?

I don't think the workaround exists yet in arch/powerpc, despite the 
config option.

Another question regarding resource allocation: when  
alloc_resource(pci_32.c), called from pcibios_allocate_resources(), 
during  pcibios init, attempts to allocate resources using 
request_resource(), the  request fails. This seems to happen because the 
previously scanned PCI  devices request resources in the form, e.g. 
00000- 0000f (i.e. starting  from zero), and this should be mapped 
somewhere else in cpu mem space. My  question (in order to find my bug) 
is, who performs this mapping, from PCI  space to CPU space, the kernel 
(and if yes, where?) or the host bridge (in  which case, I've probably 
failed to configure it properly).

If the error message is the one I'm thinking of (it always helps to post 
the actual messages), that's normal for when the PCI bus hasn't been 
probed by the firmware.  Linux first tries to use the BARs as they're 
already set, which will obviously fail because they haven't been set, 
and then it will properly allocated them.  It's harmless verbosity, 
though it'd be nice to have a flag to tell the PCI layer to not bother 
trying to preserve any existing BARs.

-Scott

On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood [off-list ref]=
  =

wrote:

Alexandros Kostopoulos wrote:

quoted

Except from some macros arch/powerpc/include/asm/io.h / mpc8260_pci9.=

h,  =

quoted

I  can seem to find anywhere the code regarding PCI Erratum 9. The  =

quoted

defined  macros(in io.h) for read/write are sufficient as a workaroun=

d  =

quoted

for PCI9?  Who does DMA and register initialization for this (it used=

  =

quoted

to be done in  arch/ppc/syslib/m8260_pci_erratum9.c in arc/ppc). Mayb=

e  =

quoted

u-boot or the  bootwrapper?

I don't think the workaround exists yet in arch/powerpc, despite the  =

config option.

Is there a plan to be implemented on arch/powerpc, or devices with the  =

erratum will have to keep on using the legacy arch/ppc code?

quoted

Another question regarding resource allocation: when   =

quoted

alloc_resource(pci_32.c), called from pcibios_allocate_resources(),  =

quoted

during  pcibios init, attempts to allocate resources using  =

quoted

request_resource(), the  request fails. This seems to happen because =

 =

quoted

the previously scanned PCI  devices request resources in the form, e.=

g.  =

quoted

00000- 0000f (i.e. starting  from zero), and this should be mapped  =

quoted

somewhere else in cpu mem space. My  question (in order to find my bu=

g)  =

quoted

is, who performs this mapping, from PCI  space to CPU space, the kern=

el  =

quoted

(and if yes, where?) or the host bridge (in  which case, I've probabl=

y  =

quoted

failed to configure it properly).

If the error message is the one I'm thinking of (it always helps to po=

st  =

the actual messages), that's normal for when the PCI bus hasn't been  =

probed by the firmware.  Linux first tries to use the BARs as they're =

 =

already set, which will obviously fail because they haven't been set, =

 =

and then it will properly allocated them.  It's harmless verbosity,  =

though it'd be nice to have a flag to tell the PCI layer to not bother=

  =

trying to preserve any existing BARs.

Well, the error message is:
PCI:0000:00:16.0: Resource 0: 0000000000000000-0000000000000fff (f=3D200=
)
PCI: Cannot allocate resource region 0 of device 0000:00:16.0
PCI:  parent is c03c4058: 0000000080000000-00000000bfffffff (f=3D200)

The thing is, POBARs are already setup by uboot. However the resource  =

allocation for the PCI devices (not the host bridge) fails in  =

request_resource (which seems to use the region requested by the device =
as  =

is and not some mapped region in the cpu address space), and I can not  =

find where in the code happens the mapping from PCI to local bus mem  =

region. I mean, each PCI device requests some region, e.g. from 0000-00f=
f  =

and this is mapped to some region in the PCI outbound window, right. For=
  =

some reason this fails in my case, and I cannot find where in the code  =

this mapping should happen.

Thank you for your help

Alex

-Scott

On Wed, 08 Aug 2007 14:42:34 +0300, Alexandros Kostopoulos  =

[off-list ref] wrote:

On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood <scottwood@freescale.co=

m>  =

wrote:

quoted

Alexandros Kostopoulos wrote:

quoted

Except from some macros arch/powerpc/include/asm/io.h /  =

quoted

quoted

mpc8260_pci9.h, I  can seem to find anywhere the code regarding PCI =

 =

quoted

quoted

Erratum 9. The defined  macros(in io.h) for read/write are sufficien=

t  =

quoted

quoted

as a workaround for PCI9?  Who does DMA and register initialization =

 =

quoted

quoted

for this (it used to be done in  arch/ppc/syslib/m8260_pci_erratum9.=

c  =

quoted

quoted

in arc/ppc). Maybe u-boot or the  bootwrapper?

I don't think the workaround exists yet in arch/powerpc, despite the =

 =

quoted

config option.

Is there a plan to be implemented on arch/powerpc, or devices with the=

  =

erratum will have to keep on using the legacy arch/ppc code?

quoted

quoted

Another question regarding resource allocation: when   =

quoted

quoted

alloc_resource(pci_32.c), called from pcibios_allocate_resources(), =

 =

quoted

quoted

during  pcibios init, attempts to allocate resources using  =

quoted

quoted

request_resource(), the  request fails. This seems to happen because=

  =

quoted

quoted

the previously scanned PCI  devices request resources in the form,  =

quoted

quoted

e.g. 00000- 0000f (i.e. starting  from zero), and this should be  =

quoted

quoted

mapped somewhere else in cpu mem space. My  question (in order to fi=

nd  =

quoted

quoted

my bug) is, who performs this mapping, from PCI  space to CPU space,=

  =

quoted

quoted

the kernel (and if yes, where?) or the host bridge (in  which case, =

 =

quoted

quoted

I've probably failed to configure it properly).

If the error message is the one I'm thinking of (it always helps to  =

quoted

post the actual messages), that's normal for when the PCI bus hasn't =

 =

quoted

been probed by the firmware.  Linux first tries to use the BARs as  =

quoted

they're already set, which will obviously fail because they haven't  =

quoted

been set, and then it will properly allocated them.  It's harmless  =

quoted

verbosity, though it'd be nice to have a flag to tell the PCI layer t=

o  =

quoted

not bother trying to preserve any existing BARs.

Well, the error message is:
PCI:0000:00:16.0: Resource 0: 0000000000000000-0000000000000fff (f=3D2=

00)

PCI: Cannot allocate resource region 0 of device 0000:00:16.0
PCI:  parent is c03c4058: 0000000080000000-00000000bfffffff (f=3D200)

The thing is, POBARs are already setup by uboot. However the resource =

 =

allocation for the PCI devices (not the host bridge) fails in  =

request_resource (which seems to use the region requested by the devic=

e  =

as is and not some mapped region in the cpu address space), and I can =

 =

not find where in the code happens the mapping from PCI to local bus m=

em  =

region. I mean, each PCI device requests some region, e.g. from  =

0000-00ff and this is mapped to some region in the PCI outbound window=

,  =

right. For some reason this fails in my case, and I cannot find where =

in  =

the code this mapping should happen.

Thank you for your help

Alex

Oops, I think I found it. I think resources are allocated properly in  =

pci_assign_resource(), and you were probably talking about the PCI devic=
e  =

BAR, not the host bridge POBARs, right. So the error message in my  =

previous mail is the one you say it's ok?

quoted

-Scott

Hi all,

I've noticed the following: In function pci_process_bridge_OF_ranges, wh=
en  =

parsing the ranges for MEM and I/O space, the res->start for mem is  =

correctly set to ranges[na+2], which is the cpu address in the ranges  =

property. However, in I/O related code, res->start is set to ranges[2], =
 =

which is in the PCI address field of the ranges property (and in my case=
  =

is 0, as is also for the mpc8272ads case as well). Thus, the res->start =
of  =

the I/O of the bridge is 0, which leads to the first device with I/O spa=
ce  =

(a davicom ethernet device) been also assigned a I/O region starting at =
0.  =

Finally, the dmfe (davicom ethernet driver over PCI) fails with "dmfe: I=
/O  =

base is zero". So, is the implementation of pci_process_bridge_OF_ranges=
  =

correct ? shouldn't res->start =3D ranges[na+2] for I/O as well?

thank you

Alex

Alexandros Kostopoulos wrote:

quoted

Well, the error message is:
PCI:0000:00:16.0: Resource 0: 0000000000000000-0000000000000fff (f=200)
PCI: Cannot allocate resource region 0 of device 0000:00:16.0
PCI:  parent is c03c4058: 0000000080000000-00000000bfffffff (f=200)

[snip]

Oops, I think I found it. I think resources are allocated properly in  
pci_assign_resource(), and you were probably talking about the PCI 
device  BAR, not the host bridge POBARs, right. So the error message in 
my  previous mail is the one you say it's ok?

Yes.

-Scott

Alexandros Kostopoulos wrote:

On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood 
[off-list ref]  wrote:

quoted

I don't think the workaround exists yet in arch/powerpc, despite the  
config option.

Is there a plan to be implemented on arch/powerpc, or devices with the  
erratum will have to keep on using the legacy arch/ppc code?

I don't have any immediate plans to move it over (and I don't think I 
have easy access to affected hardware to test on); I can't speak for any 
plans others might have.  Patches are of course welcome. :-)

-Scott

Alexandros Kostopoulos wrote:

I've noticed the following: In function pci_process_bridge_OF_ranges, 
when  parsing the ranges for MEM and I/O space, the res->start for mem 
is  correctly set to ranges[na+2], which is the cpu address in the 
ranges  property. However, in I/O related code, res->start is set to 
ranges[2],  which is in the PCI address field of the ranges property 
(and in my case  is 0, as is also for the mpc8272ads case as well). 
Thus, the res->start of  the I/O of the bridge is 0, which leads to the 
first device with I/O space  (a davicom ethernet device) been also 
assigned a I/O region starting at 0.  Finally, the dmfe (davicom 
ethernet driver over PCI) fails with "dmfe: I/O  base is zero". So, is 
the implementation of pci_process_bridge_OF_ranges  correct ? shouldn't 
res->start = ranges[na+2] for I/O as well?

Ideally, yes -- but currently IO-space resources are relative to the 
start of the primary bus's IO-space.

As a workaround, try not setting the primary flag when calling 
pci_process_bridge_OF_ranges.  Note that this means that any legacy I/O 
ports that may exist on cards you plug in (such as VGA cards) will not 
be found.

The proper solution is probably to refuse pre-existing BARs that are 
lower than PCIBIOS_MIN_IO, and/or provide a flag to tell the PCI layer 
to completely ignore pre-existing BARs.

-Scott

Scott Wood [off-list ref] said:

Alexandros Kostopoulos wrote:

quoted

I've noticed the following: In function pci_process_bridge_OF_ranges, 
when  parsing the ranges for MEM and I/O space, the res->start for mem 
is  correctly set to ranges[na+2], which is the cpu address in the 
ranges  property. However, in I/O related code, res->start is set to 
ranges[2],  which is in the PCI address field of the ranges property 
(and in my case  is 0, as is also for the mpc8272ads case as well). 
Thus, the res->start of  the I/O of the bridge is 0, which leads to the 
first device with I/O space  (a davicom ethernet device) been also 
assigned a I/O region starting at 0.  Finally, the dmfe (davicom 
ethernet driver over PCI) fails with "dmfe: I/O  base is zero". So, is 
the implementation of pci_process_bridge_OF_ranges  correct ? shouldn't 
res->start = ranges[na+2] for I/O as well?

Ideally, yes -- but currently IO-space resources are relative to the 
start of the primary bus's IO-space.

As a workaround, try not setting the primary flag when calling 
pci_process_bridge_OF_ranges.  Note that this means that any legacy I/O 
ports that may exist on cards you plug in (such as VGA cards) will not 
be found.

The proper solution is probably to refuse pre-existing BARs that are 
lower than PCIBIOS_MIN_IO, and/or provide a flag to tell the PCI layer 
to completely ignore pre-existing BARs.

I was referring to the allocation of primary bus' IO space based on the 
device tree. I understand that IO-space resources are relative to the start 
of the primary bus' IO space. But I think the primary bus IO space allocation 
itself is broken. Let me explain with an example:

In mpc8272ads.dts, the ranges property for pci is:

ranges = <42000000 0 80000000 80000000 0 20000000
          02000000 0 a0000000 a0000000 0 20000000
          01000000 0 00000000 f6000000 0 02000000>;

The third obviously corresponds to IO space. So, shouldn't the res->start for 
the host bridge be set to f6000000 ? Because, currently, based on what I've 
described in my previous mail, it gets set to 0. It seems to me like a matter 
of incorrect parsing of the device tree from pci_process_bridge_OF_ranges() 
for IO space. Or am I missing something else here, and it should actually be 
0?

thanks

Alex

-Scott

-- 

Alexandros Kostopoulos wrote:

I was referring to the allocation of primary bus' IO space based on the 
device tree. I understand that IO-space resources are relative to the start 
of the primary bus' IO space. But I think the primary bus IO space allocation 
itself is broken. Let me explain with an example:

In mpc8272ads.dts, the ranges property for pci is:

ranges = <42000000 0 80000000 80000000 0 20000000
          02000000 0 a0000000 a0000000 0 20000000
          01000000 0 00000000 f6000000 0 02000000>;

The third obviously corresponds to IO space. So, shouldn't the res->start for 
the host bridge be set to f6000000 ?

No, because as I said, res->start is relative to the start of IO-space. 
  The in/out functions add isa_io_base to the address.

Because, currently, based on what I've 
described in my previous mail, it gets set to 0. It seems to me like a matter 
of incorrect parsing of the device tree from pci_process_bridge_OF_ranges() 
for IO space.

It is not, at least not in this case.  It does appear to be ignoring the 
possibility that it needs to do further translation of the address 
through parent buses, though.

-Scott

No, because as I said, res->start is relative to the start of IO-space. 
  The in/out functions add isa_io_base to the address.

Hi Scott,

please allow me to insist a little bit more on this. 

1. As far as the device tree is concerned, it is defined that the first 3 
numbers in every line of the ranges property (for our case, with #address-
cells=3) is the PCI address of the device (in this case, host bridge), the 
next one is the local bus base address and the last two the local region 
size. In the case of memory space, res->start for the host bridge takes as a 
value ranges[3], which is actually the local bus base address. Why does the 
code for IO space uses ranges[2]. Shouldn't these two use the same field of 
the corresponding ranges property line? 

2. As far as isa_io_base is concerned: When primary (what does this actually 
mean? primary PCI bus ?) is 1, then indeed 
isa_io_base=ranges[na+2]=ranges[3] (in this case) as it should (while res-

start=ranges[2] for some reason I don't understand, as I said earlier). And 

this is indeed added in the i/o address of the device during in/out 
operations. However, the driver I use, drivers/net/tulip/dmfe.c, actually 
checks whether res->start for the PCI device is zero, and if it is so, it 
fails. So, assuming that the pci_process_OF_bridges code is correct as is, 
then there is some problem with the driver? Because the same driver worked in 
arch/ppc, which makes me think that there, res->start was NOT 0, but was 
already offset to the actual I/O space of the local bus. 

I would really appreciate your comments (and forgive me for insisting on this
 :) )

Alex

quoted

Because, currently, based on what I've 
described in my previous mail, it gets set to 0. It seems to me like a 

matter 

quoted

of incorrect parsing of the device tree from 

pci_process_bridge_OF_ranges() 

quoted

for IO space.

It is not, at least not in this case.  It does appear to be ignoring the 
possibility that it needs to do further translation of the address 
through parent buses, though.

-Scott

-- 

On Wed, 2007-08-08 at 17:21 +0300, Alexandros Kostopoulos wrote:

I've noticed the following: In function pci_process_bridge_OF_ranges, when  
parsing the ranges for MEM and I/O space, the res->start for mem is  
correctly set to ranges[na+2], which is the cpu address in the ranges  
property. However, in I/O related code, res->start is set to ranges[2],  
which is in the PCI address field of the ranges property (and in my case  
is 0, as is also for the mpc8272ads case as well). Thus, the res->start of  
the I/O of the bridge is 0, which leads to the first device with I/O space  
(a davicom ethernet device) been also assigned a I/O region starting at 0.  
Finally, the dmfe (davicom ethernet driver over PCI) fails with "dmfe: I/O  
base is zero". So, is the implementation of pci_process_bridge_OF_ranges  
correct ? shouldn't res->start = ranges[na+2] for I/O as well?

The current code indeed assumes that IO space of a PCI host bridges starts
at 0 local always. We "fixed" that in the 64 bits variant but not the 32 bits
one (yet...).

Note that if we're going to fix it, we probably also need to change various
bits of resource fixup code as well that makes that assumption.

Might be worth trying making more of that stuff common between 32 and 64
bits (I hear the noise of people trying to get me merge the pci code .. :-)

Ben.

Alexandros Kostopoulos wrote:

Hi Scott,

please allow me to insist a little bit more on this. 

No problem. :-)

1. As far as the device tree is concerned, it is defined that the first 3 
numbers in every line of the ranges property (for our case, with #address-
cells=3) is the PCI address of the device (in this case, host bridge), the 
next one is the local bus base address and the last two the local region 
size. In the case of memory space, res->start for the host bridge takes as a 
value ranges[3], which is actually the local bus base address. Why does the 
code for IO space uses ranges[2]. Shouldn't these two use the same field of 
the corresponding ranges property line? 

Yes, I see what you mean -- non-primary buses appear to be completely 
broken for IO-space.  One part of the code insists that ranges[2] be 
zero, but later it assumes that it matches the CPU-side offset from the 
start of the primary IO-space (which cannot be zero, because it would 
conflict with the primary bus).

2. As far as isa_io_base is concerned: When primary (what does this actually 
mean? primary PCI bus ?) is 1,

It means the bus on which legacy I/O ports can be found.  It's a fairly 
broken concept; each host bridge should really be treated as a 
completely separate entity, and if something like a VGA card has legacy 
I/O ports that need to be used, they should be looked for on the same 
PCI bus as the card itself.  Legacy ISA ports should be discovered 
through the device tree (or platform devices, or whatever) that 
explicitly state which PCI-to-ISA bridge they're under.

then indeed 
isa_io_base=ranges[na+2]=ranges[3] (in this case) as it should (while res-

quoted

start=ranges[2] for some reason I don't understand, as I said earlier). And 

this is indeed added in the i/o address of the device during in/out 
operations. However, the driver I use, drivers/net/tulip/dmfe.c, actually 
checks whether res->start for the PCI device is zero, and if it is so, it 
fails. So, assuming that the pci_process_OF_bridges code is correct as is, 

It's not, but even if the above bug were fixed it'd still start at zero 
for the primary bus.

then there is some problem with the driver?

Yes, apparently -- according to a recent thread here, recent versions of 
the PCI spec removed the wording that prohibited a zero BAR (is there 
then no way to disable a BAR?).  Still, it'd be better to avoid it.

Because the same driver worked in 
arch/ppc, which makes me think that there, res->start was NOT 0, but was 
already offset to the actual I/O space of the local bus. 

The m82xx_pci code in arch/ppc seems to set isa_io_base to the start of 
the I/O region, so I'm not sure why you'd get different behavior.

-Scott

It means the bus on which legacy I/O ports can be found.  It's a fairly
broken concept; each host bridge should really be treated as a
completely separate entity, and if something like a VGA card has legacy
I/O ports that need to be used, they should be looked for on the same
PCI bus as the card itself.  Legacy ISA ports should be discovered
through the device tree (or platform devices, or whatever) that
explicitly state which PCI-to-ISA bridge they're under.

Currently, Linux does not allow multiple PCI domains to use
overlapping legacy I/O ranges.  Yeah it's a pain.

Yes, apparently -- according to a recent thread here, recent versions 
of
the PCI spec removed the wording that prohibited a zero BAR (is there
then no way to disable a BAR?).

I couldn't find that prohibition even in ancient versions of
the PCI specification, for what it's worth.  Maybe I'm just
blind.

Still, it'd be better to avoid it.

Yeah, many drivers go bonkers otherwise.  Some devices might
misbehave, too.


Segher

Alexandros Kostopoulos writes:

In mpc8272ads.dts, the ranges property for pci is:

ranges = <42000000 0 80000000 80000000 0 20000000
          02000000 0 a0000000 a0000000 0 20000000
          01000000 0 00000000 f6000000 0 02000000>;

The third obviously corresponds to IO space. So, shouldn't the res->start for 
the host bridge be set to f6000000 ? Because, currently, based on what I've 

No.  The "addresses" in the resource structs for PCI I/O space are
basically PCI I/O port numbers (with a bit of a swizzle for host
bridges other than the primary bridge), whereas the "addresses" in
resource structs for PCI memory space are actually host physical
addresses.

This difference is reflected in the difference between inb() and
readb(); inb() adds pci_io_base on to the port number, which comes
directly from the resource struct.  In contrast, to use readb, you
get the PCI memory space address from the resource struct and pass
that through ioremap to get the cookie (actually the kernel virtual
address) to pass to readb, which doesn't add anything to it before
dereferencing it.

For host bridges other than the primary bridge, we add an offset to
the start/end values in the resource structs in
pcibios_fixup_resources so inb/outb work as expected.

described in my previous mail, it gets set to 0. It seems to me like a matter 
of incorrect parsing of the device tree from pci_process_bridge_OF_ranges() 
for IO space. Or am I missing something else here, and it should actually be 
0?

It should actually be zero.  What you have is a disagreement between
the firmware writer (who thinks 0 is a perfectly valid I/O port
address assignment) and the driver writer (who thinks 0 isn't valid).

Paul.

On Thu, 2007-08-09 at 17:56 +0200, Segher Boessenkool wrote:

quoted

It means the bus on which legacy I/O ports can be found.  It's a fairly
broken concept; each host bridge should really be treated as a
completely separate entity, and if something like a VGA card has legacy
I/O ports that need to be used, they should be looked for on the same
PCI bus as the card itself.  Legacy ISA ports should be discovered
through the device tree (or platform devices, or whatever) that
explicitly state which PCI-to-ISA bridge they're under.

Currently, Linux does not allow multiple PCI domains to use
overlapping legacy I/O ranges.  Yeah it's a pain.

I have a plan I exposed a little while ago to handle that. We need that
for VGA cards among others anyway.

The idea is basically a call around the lines of
pci_convert_legacy_resource(struct resource *r);

You fill up the resource with flags = MEM/IO and start/end being your
legacy range, and it returns a "fixed" resource that you can use with
inX/outX, or whatever else.

Haven't had time to code something up, and we need to provide a default
impl. for all archs too ... but feel free to volunteer and beat me to
it :-)

Ben.