pci in arch/powerpc vs arch/ppc

pci in arch/powerpc vs arch/ppc

[Alexandros Kostopoulos]

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...

Re: pci in arch/powerpc vs arch/ppc

[Scott Wood]

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

Re: pci in arch/powerpc vs arch/ppc

[Kumar Gala]

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

> 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.

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

- k

Re: pci in arch/powerpc vs arch/ppc

[Alexandros Kostopoulos]

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 <galak@kernel.crashing.org>  
wrote:

>
> On Aug 3, 2007, at 3:10 PM, Scott Wood wrote:
>
>> 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.
>
> This will change in 2.6.24.  I've fixed the reason we excluded the host  
> bridges on Freescale host bridges.
>
> - k

Re: pci in arch/powerpc vs arch/ppc

[Scott Wood]

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

Re: pci in arch/powerpc vs arch/ppc

[Alexandros Kostopoulos]

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

wrote:

> 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 workaroun=
d  =

>> 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). Mayb=
e  =

>> 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?

>> 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 bu=
g)  =

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

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

>> 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

Re: pci in arch/powerpc vs arch/ppc

[Alexandros Kostopoulos]

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

<akostop@inaccessnetworks.com> wrote:

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

> wrote:
>
>> 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 sufficien=
t  =

>>> 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.
>>
>
> 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?
>
>>> 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 fi=
nd  =

>>> 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 t=
o  =

>> 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?


>
>> -Scott
>

Re: pci in arch/powerpc vs arch/ppc

[Scott Wood]

Alexandros Kostopoulos wrote:
>> 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

Re: pci in arch/powerpc vs arch/ppc

[Alexandros Kostopoulos]

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

Re: pci in arch/powerpc vs arch/ppc

[Scott Wood]

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

Re: pci in arch/powerpc vs arch/ppc

[Alexandros Kostopoulos]

Scott Wood <scottwood@freescale.com> said:

> 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.

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
> 



-- 

Re: pci in arch/powerpc vs arch/ppc

[Scott Wood]

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

Re: pci in arch/powerpc vs arch/ppc

[Alexandros Kostopoulos]

> 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

> > 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
> 



-- 

Re: pci in arch/powerpc vs arch/ppc

[Scott Wood]

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-
> 
>>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

Re: pci in arch/powerpc vs arch/ppc

[Segher Boessenkool]

> 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

Re: pci in arch/powerpc vs arch/ppc

[Benjamin Herrenschmidt]

On Thu, 2007-08-09 at 17:56 +0200, Segher Boessenkool wrote:
> > 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.

Re: pci in arch/powerpc vs arch/ppc

[Paul Mackerras]

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.

Re: pci in arch/powerpc vs arch/ppc

[Benjamin Herrenschmidt]

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.

MPC8260 PCI9 erratum

[Scott Wood]

Alexandros Kostopoulos wrote:
> On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood 
> <scottwood@freescale.com>  wrote:
>> 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