Thread (19 messages) flat view 19 messages, 6 authors, 2007-08-12

Re: pci in arch/powerpc vs arch/ppc

From: Alexandros Kostopoulos <hidden>
Date: 2007-08-08 19:47:02

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


-- 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help