PCIe enhanced configuration mechanism support on ppc arch

PCIe enhanced configuration mechanism support on ppc arch

[Shawn Jin]

Hi,

I'm trying to find out if the current PCI subsystem supports the PCIe
enhanced configuration mechanism, in particular, on the ppc/powerpc
arch, which is basically a MMIO access with the address containing all
bus, device, function, and offset info.

Could someone here give an authoritative answer? Or point me to
somewhere I can look for it by myself, such as which file or directory
in the kernel tree. I searched at arch/ppc/kernel,
arch/powerpc/kernel, and drivers/pci but couldn't find an answer. :(

Thanks,
-Shawn.

Re: PCIe enhanced configuration mechanism support on ppc arch

[Milton Miller]

On Fri Aug 18 05:01:48 EST 2006, Shawn Jin wrote:
> I'm trying to find out if the current PCI subsystem supports the PCIe
> enhanced configuration mechanism, in particular, on the ppc/powerpc
> arch, which is basically a MMIO access with the address containing all
> bus, device, function, and offset info.

If what you are really trying to find is the 4k extended config space,
then there are some platforms that support that on some slots.

If you are trying to find the mmio address for your adapter, then the
answer is I am not aware of any PowerPC platforms that provide that,
although I am not familiar with the embedded processor platforms nor
the pci express Apple boxes.

> Could someone here give an authoritative answer? Or point me to
> somewhere I can look for it by myself, such as which file or directory
> in the kernel tree. I searched at arch/ppc/kernel,
> arch/powerpc/kernel, and drivers/pci but couldn't find an answer. :(

The config access support is in arch/powerpc/kernel/rtas_pci.c,
the setting of pci_ext_config_space is at arch/powerpc/kernel/pci_dn.c.

milton

Re: PCIe enhanced configuration mechanism support on ppc arch

[Arnd Bergmann]

On Wednesday 30 August 2006 18:30, Milton Miller wrote:
> The config access support is in arch/powerpc/kernel/rtas_pci.c,
> the setting of pci_ext_config_space is at arch/powerpc/kernel/pci_dn.c.
> 
Well, so far that is only true for pseries and cell, as the others
normally don't use rtas for config space access.

Other platforms have their config space implementation in
arch/powerpc/platforms/<platform>/pci.c and may not support
this.

	Arnd <><

Re: PCIe enhanced configuration mechanism support on ppc arch

[Benjamin Herrenschmidt]

On Wed, 2006-08-30 at 11:30 -0500, Milton Miller wrote:
> On Fri Aug 18 05:01:48 EST 2006, Shawn Jin wrote:
> > I'm trying to find out if the current PCI subsystem supports the PCIe
> > enhanced configuration mechanism, in particular, on the ppc/powerpc
> > arch, which is basically a MMIO access with the address containing all
> > bus, device, function, and offset info.
> 
> If what you are really trying to find is the 4k extended config space,
> then there are some platforms that support that on some slots.
> 
> If you are trying to find the mmio address for your adapter, then the
> answer is I am not aware of any PowerPC platforms that provide that,
> although I am not familiar with the embedded processor platforms nor
> the pci express Apple boxes.
> 
> > Could someone here give an authoritative answer? Or point me to
> > somewhere I can look for it by myself, such as which file or directory
> > in the kernel tree. I searched at arch/ppc/kernel,
> > arch/powerpc/kernel, and drivers/pci but couldn't find an answer. :(
> 
> The config access support is in arch/powerpc/kernel/rtas_pci.c,
> the setting of pci_ext_config_space is at arch/powerpc/kernel/pci_dn.c.

Actually, that only sets the variable used by the RTAS PCI accessors.
Other platforms might do differently. The PCI probe code uses the
generic pci_cfg_space_size() function to determine wether extended
config space is supported for a given device.

An example of platform not using RTAS and that does support extended
config space is the PCI Express link out of the U4 northbridge on
PowerMac (though not the other PCIe slots connected to the HT<->PCIe
tunnel, at least not for now).

It's basically just a matter of having your low level config access
routines supporting those >=256 offsets. The generic code tests that by
doing a dummy access and checks for an error return.

Ben.

Re: PCIe enhanced configuration mechanism support on ppc arch

[Segher Boessenkool]

> An example of platform not using RTAS and that does support extended
> config space is the PCI Express link out of the U4 northbridge on
> PowerMac (though not the other PCIe slots connected to the HT<->PCIe
> tunnel, at least not for now).
>
> It's basically just a matter of having your low level config access
> routines supporting those >=256 offsets. The generic code tests  
> that by
> doing a dummy access and checks for an error return.

The U3/U4 HT config access code never returns the error though; it
happily accesses the config space of the next device instead.  Got
a patch, will send it later -- it's not a regression, there's no big
hurry for 2.6.18.


Segher

Re: PCIe enhanced configuration mechanism support on ppc arch

[Benjamin Herrenschmidt]

On Thu, 2006-08-31 at 12:11 +0200, Segher Boessenkool wrote:
> > An example of platform not using RTAS and that does support extended
> > config space is the PCI Express link out of the U4 northbridge on
> > PowerMac (though not the other PCIe slots connected to the HT<->PCIe
> > tunnel, at least not for now).
> >
> > It's basically just a matter of having your low level config access
> > routines supporting those >=256 offsets. The generic code tests  
> > that by
> > doing a dummy access and checks for an error return.
> 
> The U3/U4 HT config access code never returns the error though; it
> happily accesses the config space of the next device instead.  Got
> a patch, will send it later -- it's not a regression, there's no big
> hurry for 2.6.18.

Better to have it in if possible though. Thanks

Ben.

Re: PCIe enhanced configuration mechanism support on ppc arch

[Segher Boessenkool]

>> The U3/U4 HT config access code never returns the error though; it
>> happily accesses the config space of the next device instead.  Got
>> a patch, will send it later -- it's not a regression, there's no big
>> hurry for 2.6.18.
>
> Better to have it in if possible though. Thanks

I'm more worried about having 2.6.18 work at all, sorry.  I might
be fast enough of course (ahem), but no promises :-)


Segher