Re: [Patch 1/1] x86 pci: Add option to not assign BAR's if not alreadyassigned

[Mike Travis]

Jesse Barnes wrote:
> On Fri, 14 May 2010 15:34:01 -0700
> Mike Travis <travis@xxxxxxx> wrote:
>
> > Jesse Barnes wrote:
> > > On Thu, 13 May 2010 14:02:30 -0600
> > > Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote:
> > > > > > This issue is not specific to x86, so I don't really like having
> > > > > > the implementation be x86-specific.
> > > > > I agree this isn't a x86 specific issue but given the 'norom'
> > > > > cmdline option is basically doing the same thing (but for pci
> > > > > Expansion ROM BARs) this code was modeled after it.
> > > > IMHO, we should fix both.
> > > Yeah, that would be good.  Mike, have you looked at this at all?
> > >
> > > Also, to clarify, this isn't affecting users today, right?  Or do you
> > > need all this I/O space for multiple IOHs and the drivers that bind to
> > > them in current UV systems?
> > We have customers that want to install more than 16 PCI-e cards right
> > now.  Our window of opportunity closes very soon (days), so either this
> > patch makes it in as is (or something close), or we wait for another
> > release cycle.  UV shipments start this month.
> >
> > [I wouldn't mind working on an improvement for later.]
>
> Wow and they're using cards that want to use I/O space?  Funky.  It's
> too late to get this into 2.6.34, but that can't be what you were
> expecting... I don't see a problem with getting something like this in
> for 2.6.35.

2.6.35 would be fine.  It's the acceptance that's the key.

And yes, we're using standard cards like everyone else... ;-)

[The message is "UV" is just a really, really big PC. ;-)]

I would appreciate however, some more detail on what's the goal of the
updates to "fix both".  Thanks!

> > > Fundamentally, until we have real dynamic PCI resource management (i.e.
> > > driver hooks for handling relocation, lazy allocation of resources at
> > > driver bind time, etc.) we're going to continue to need hacks like
> > > this.  However, we could make them slightly more automated by making
> > > "nobar" and "norom" the default on systems that typically need them,
> > > maybe with a DMI table.
> > It seems that BIOS changes are much more difficult.  The real solution
> > to this problem is for Card Vendors to not request I/O Bars if they
> > won't be using them.  But that's the hardest option of all to accomplish.
>
> Right.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/