MPC8343: PCI resource allocation questions

MPC8343: PCI resource allocation questions

[Luong Ngo]

[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2016 bytes --]

Re: MPC8343: PCI resource allocation questions

[Kumar Gala]

On Oct 24, 2006, at 10:49 PM, Luong Ngo wrote:

> 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@0 for 0000:00:00.0

You can ignore these, they can usually be handled by adding a  
pci_exclude call back to ignore the host controller itself.

something like:

int mpc83xx_exclude_device(u_char bus, u_char devfn)
{
         if (bus == 0 && PCI_SLOT(devfn) == 0)
                 return PCIBIOS_DEVICE_NOT_FOUND;
         return PCIBIOS_SUCCESSFUL;
}

> 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

You are not leaving any memory space for any of the onchip devices,  
the error messages are because the regions of memory that the devices  
are expected to be at are already occupied by the PCI space.

> Could anyone tell me how these PCI resource work and how to resolve  
> this conflict?

The PCI resources are used for any PCI devices that need memory  
mapped space allocated to them.  What devices are you connecting over  
PCI?

> And my other questions are  why is the region 2 in the mpc8343E  
> such huge and what is it used for?

The region was large since the reference board has general purpose  
PCI slots for any number of various cards.  We provide a large space  
to allow for those cards to be allocated into.  Depending on your  
application you can adjust this as you need.

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

This is because when the kernel code scan's for devices the host  
bridge responses as a device.  You can use the exclude function as a  
way to override the scanning code and have it ignore the host bridge.

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

Yes, but you should only need to setup the inbound/outbound address  
mapping registers.  The actually PCI BARs are only important if you  
are using the MPC8343 as a PCI agent, it sounds like you are using it  
as a host.

- kumar

Re: MPC8343: PCI resource allocation questions

[Luong Ngo]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]

Kumar, thanks a lot for your prompt and clear answers. But I still have a
couple questions about the BARs.


> The PCI resources are used for any PCI devices that need memory
> mapped space allocated to them.  What devices are you connecting over
> PCI?


I am connecting Broadcom BCM56502 controllers over PCI.

The region was large since the reference board has general purpose
PCI slots for any number of various cards.  We provide a large space
to allow for those cards to be allocated into.  Depending on your
application you can adjust this as you need.

I'm a bit confused here. If the host bridge is ignored/excluded, then the
region size in BARs will not be allocated corresponding resource by the PCI
subsystem, then how would other PCI devices in the slots could be allocated
in the BAR's range? If I understand correctly, the PCI devices's resources
are allocated based on the bridge resource, which is assigned statically by
PCI subsystem using hose->mem_space and hose->io_space instead of reading it
from the BARs. Maybe you are saying in the case the CPU is in agent mode and
its PCI host bridge is functioning as a PCI-PCI bridge?

You are not leaving any memory space for any of the onchip devices,
the error messages are because the regions of memory that the devices
are expected to be at are already occupied by the PCI space.

Isn't it the PCI IO and PCI MEM space are separated from local memory space?
I believe I see the global io_resource and mem_resource have the range of
0x0 - 0xFFFFFFFF.

I appreciate your help,

Thanks,
Luong Ngo

[-- Attachment #2: Type: text/html, Size: 2062 bytes --]

Re: MPC8343: PCI resource allocation questions

[Kumar Gala]

> I'm a bit confused here. If the host bridge is ignored/excluded,  
> then the region size in BARs will not be allocated corresponding  
> resource by the PCI subsystem, then how would other PCI devices in  
> the slots could be allocated in the BAR's range? If I understand  
> correctly, the PCI devices's resources are allocated based on the  
> bridge resource, which is assigned statically by PCI subsystem  
> using hose->mem_space and hose->io_space instead of reading it from  
> the BARs. Maybe you are saying in the case the CPU is in agent mode  
> and its PCI host bridge is functioning as a PCI-PCI bridge?

The problem is the host bridge shouldn't be included in BAR  
assignment since its the host bridge.  The problem is FSL devices  
show up when they scan themselves and the kernel then tries to  
allocate resources to them as if they were any other device.

you are correct, the pci subsystem is setup via the hose structure  
and not by trying to read BARs on the host controller itself.

- kumar

Re: MPC8343: PCI resource allocation questions

[Luong Ngo]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

Would you mind explain me the last question in previous email?

  You are not leaving any memory space for any of the onchip devices,
the error messages are because the regions of memory that the devices
are expected to be at are already occupied by the PCI space.

Isn't it the PCI IO and PCI MEM space are separated from local memory space?
I think I see the global IO resource and MEM resource have the range of 0x0
- 0xFFFFFFFF.

Thanks,
Luong Ngo

On 10/24/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>
>
> > I'm a bit confused here. If the host bridge is ignored/excluded,
> > then the region size in BARs will not be allocated corresponding
> > resource by the PCI subsystem, then how would other PCI devices in
> > the slots could be allocated in the BAR's range? If I understand
> > correctly, the PCI devices's resources are allocated based on the
> > bridge resource, which is assigned statically by PCI subsystem
> > using hose->mem_space and hose->io_space instead of reading it from
> > the BARs. Maybe you are saying in the case the CPU is in agent mode
> > and its PCI host bridge is functioning as a PCI-PCI bridge?
>
> The problem is the host bridge shouldn't be included in BAR
> assignment since its the host bridge.  The problem is FSL devices
> show up when they scan themselves and the kernel then tries to
> allocate resources to them as if they were any other device.
>
> you are correct, the pci subsystem is setup via the hose structure
> and not by trying to read BARs on the host controller itself.
>
> - kumar
>

[-- Attachment #2: Type: text/html, Size: 2105 bytes --]

Re: MPC8343: PCI resource allocation questions

[Kumar Gala]

On Oct 25, 2006, at 2:16 AM, Luong Ngo wrote:

>
> Would you mind explain me the last question in previous email?
>
>
> You are not leaving any memory space for any of the onchip devices,
> the error messages are because the regions of memory that the devices
> are expected to be at are already occupied by the PCI space.
>
> Isn't it the PCI IO and PCI MEM space are separated from local  
> memory space? I think I see the global IO resource and MEM resource  
> have the range of 0x0 - 0xFFFFFFFF.

PCI MEM space mapped into the processors physical address space, so  
you can't easily have access to all 4G of PCI MEM space.  Instead we  
usually just allocate 256M or 512M or physical address space for PCI  
MEM.  (the same is roughly true for PCI IO).


- kumar

>
> Thanks,
> Luong Ngo
>
> On 10/24/06, Kumar Gala <galak@kernel.crashing.org> wrote:
> > I'm a bit confused here. If the host bridge is ignored/excluded,
> > then the region size in BARs will not be allocated corresponding
> > resource by the PCI subsystem, then how would other PCI devices in
> > the slots could be allocated in the BAR's range? If I understand
> > correctly, the PCI devices's resources are allocated based on the
> > bridge resource, which is assigned statically by PCI subsystem
> > using hose->mem_space and hose->io_space instead of reading it from
> > the BARs. Maybe you are saying in the case the CPU is in agent mode
> > and its PCI host bridge is functioning as a PCI-PCI bridge?
>
> The problem is the host bridge shouldn't be included in BAR
> assignment since its the host bridge.  The problem is FSL devices
> show up when they scan themselves and the kernel then tries to
> allocate resources to them as if they were any other device.
>
> you are correct, the pci subsystem is setup via the hose structure
> and not by trying to read BARs on the host controller itself.
>
> - kumar
>