MPC8343: PCI resource allocation questions

Luong Ngo luong.ngo at gmail.com
Wed Oct 25 13:49:45 EST 2006


Hello,
I am trying to bring up linux kernel 2.6.14 on a system using MPC 8343E and
am having issues with the PCI resource allocation in the kernel. I saw these
messages:
.............
PCI: Cannot allocate resource region 0 of device 0000:00:00.0
PCI: Cannot allocate resource region 2 of device 0000:00:00.0
PCI: Failed to allocate mem resource #2:80000000 at 0 for 0000:00:00.0

After digging into the codes, I realize that the PCI subsystem scan the bus
and reading the BARs in the CPU PCI controller, which give the region 1 from
0x0 to 0x000FFFFF and region 2 from 0x0 to 0x7FFFFFFF. And the values I
assign to the bridge resource in calling pci_init_resource during setup hose
is 0x80000000 - 0x9FFFFFFF (I got this values from the mpc834x_sys.h).  So I
just extend the bridge resource to 0x70000000 - 0xFFFFFFFF to cover all 2
regions in the 2 BAR and this seems to get rid of the above messages.
However this would cause other platform devices to fail to claim its
resources,

fsl-gianfar.1: failed to claim resource 0
unable to register device 0
fsl-gianfar.2: failed to claim resource 0
unable to register device 1
fsl-i2c.1: failed to claim resource 0
unable to register device 2

Could anyone tell me how these PCI resource work and how to resolve this
conflict?
And my other questions are  why is the region 2 in the mpc8343E such huge
and what is it used for?
Also Why the kernel looks into the CPU PCI controller? because as I
understand, in the hose setup step in platform initialization, the host
bridge is skipped while other PCI devices would be probed and have their
BARs assigned the address range to use ( in function pciauto_bus_scan in
arch/ppc/syslib/pci_auto.c )

One more question, are these BARs in the PCI controller related with the PCI
inbound and outbound mapping of the PCI interface? Do the regions in BAR
need to match/derive from the inbound/outbound address mapping?

Thank you,

Luong Ngo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20061024/a73ff18b/attachment.htm>


More information about the Linuxppc-dev mailing list