linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Milton Miller <miltonm@bga.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: PCIe enhanced configuration mechanism support on ppc arch
Date: Thu, 31 Aug 2006 09:03:13 +1000	[thread overview]
Message-ID: <1156978993.12526.97.camel@localhost.localdomain> (raw)
In-Reply-To: <7cc604637892c0a00a5e3e38192494d7@bga.com>

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.

  parent reply	other threads:[~2006-08-30 23:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30 16:30 PCIe enhanced configuration mechanism support on ppc arch Milton Miller
2006-08-30 18:30 ` Arnd Bergmann
2006-08-30 23:03 ` Benjamin Herrenschmidt [this message]
2006-08-31 10:11   ` Segher Boessenkool
2006-08-31 12:02     ` Benjamin Herrenschmidt
2006-08-31 21:31       ` Segher Boessenkool
  -- strict thread matches above, loose matches on Subject: below --
2006-08-17 19:01 Shawn Jin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1156978993.12526.97.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=miltonm@bga.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).