MPC8343: PCI resource allocation questions

Kumar Gala galak at kernel.crashing.org
Thu Oct 26 00:06:32 EST 2006


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




More information about the Linuxppc-dev mailing list