From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: linux-pci@vger.kernel.org,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Probing unconfigured PCI bridge resouces
Date: Sat, 28 Jan 2012 09:16:06 +1100 [thread overview]
Message-ID: <1327702566.24487.26.camel@pasglop> (raw)
In-Reply-To: <20120127093658.27dc258b@jbarnes-desktop>
On Fri, 2012-01-27 at 09:36 -0800, Jesse Barnes wrote:
> > Ok, I think I was missing pci_bridge_check_ranges(), gotta figure now
> > why this didn't kick in properly for me, probably some arch code
> > crackpot.
> >
> > One thing I noticed is that we do clear IORESOURCE_UNSET in setup-res.c
> > when setting up a device resource but we don't clear it for bridges in
> > generic code ever, so it leaks all the way through from my early arch
> > code. Not a big deal but annoying.
>
> Maybe you can fix that when you unify your arch resource handling code
> with the core one day. :)
>
> There have been a lot of changes to handle re-allocation and such, and
> I'm sure there's more duplication now...
There isn't much the my arch does that isn't just calling into core
nowadays on powerpc, look at my resource survey :-)
I have some slightly different (arguably better ?) logic to deal with
unassigned resources in the initial allocation pass before re-assigning
(or assigning unassigned) and flags to enable ignoring the initial state
of devices (which should be improved with core changes one of these
days, for example we still read all bridge bases even when we know we
are just going to re-assign everything etc...).
The one thing I cannot unify is actually new in 3.3, it's the code to
assign resources on the new "powernv" platform which requires its own
logic unfortunately and I'm not sure I can make the core do what I want
without major uglyness.
The main reason is that on p7ioc and similar recent IBM host bridges, we
have a domain mechanism which allows error isolation, dma isolation
etc... which also encompass MMIO (in order to properly assign MMIO
errors such as target aborts etc... with a domain).
The way this works is by segmenting the MMIO space, which means that all
BARs of a all devices in a given domain shall be assigned to a group of
segments. Now I -can- renumber 32-bit segments so in theory I could get
away with alignment tricks (tho nasty ones) only but I can't always
renumber 64-bit segments (tho in my current scheme I simply don't use
64-bit MMIO segments at all, in part due to that complication).
The consequence is that I need to pre-assign domains at boot based on
various constraints and policy decisions which unfortunately have to be
made by the kernel arbitrarily, and then tweak the MMIO resource
allocation to assign BARs of devices accordingly so they fit into
"segments" that can be made to correspond with the domains.
Cheers,
Ben.
prev parent reply other threads:[~2012-01-27 22:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 4:25 Probing unconfigured PCI bridge resouces Benjamin Herrenschmidt
2012-01-24 4:50 ` Benjamin Herrenschmidt
2012-01-27 17:36 ` Jesse Barnes
2012-01-27 22:16 ` Benjamin Herrenschmidt [this message]
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=1327702566.24487.26.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/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).