From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Mike Travis <travis@sgi.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>,
Mike Habeck <habeck@sgi.com>, Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Jacob Pan <jacob.jun.pan@intel.com>,
Tejun Heo <tj@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Yinghai <yinghai.lu@oracle.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Myron Stowe <myron.stowe@hp.com>
Subject: Re: [Patch 1/1] x86 pci: Add option to not assign BAR's if not already assigned
Date: Fri, 14 May 2010 16:06:51 -0700 [thread overview]
Message-ID: <20100514160651.2b4ee3d7@virtuousgeek.org> (raw)
In-Reply-To: <4BEDD5BF.5030005@sgi.com>
On Fri, 14 May 2010 15:59:11 -0700
Mike Travis <travis@sgi.com> wrote:
>
>
> Jesse Barnes wrote:
> > On Fri, 14 May 2010 15:34:01 -0700
> > Mike Travis <travis@sgi.com> wrote:
> >
> >>
> >> Jesse Barnes wrote:
> >>> On Thu, 13 May 2010 14:02:30 -0600
> >>> Bjorn Helgaas <bjorn.helgaas@hp.com> 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!
As Bjorn noted, both the norom and nobar options are listed as x86
specific in the documentation and use x86 specific flags and code to
prevent their respective allocations.
It would be good if we could move the flags and code to the common PCI
layer in drivers/pci so that other arches could take advantage of it,
and we could have less resource management fragmentation.
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2010-05-14 23:07 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-12 18:14 [Patch 1/1] x86 pci: Add option to not assign BAR's if not already assigned Mike Travis
2010-05-13 18:56 ` Bjorn Helgaas
2010-05-13 19:08 ` H. Peter Anvin
2010-05-13 19:12 ` Mike Travis
2010-05-13 19:13 ` Mike Travis
2010-05-13 19:54 ` Bjorn Helgaas
2010-05-13 20:27 ` Mike Habeck
2010-05-13 19:38 ` Mike Habeck
2010-05-13 20:02 ` Bjorn Helgaas
2010-05-13 20:09 ` H. Peter Anvin
2010-05-14 22:25 ` Jesse Barnes
2010-05-14 22:34 ` Mike Travis
2010-05-14 22:35 ` H. Peter Anvin
2010-05-14 22:40 ` Mike Travis
2010-05-15 2:25 ` Mike Travis
2010-05-14 22:47 ` Jesse Barnes
2010-05-14 22:59 ` Mike Travis
2010-05-14 23:06 ` Jesse Barnes [this message]
2010-05-14 23:23 ` Mike Travis
2010-05-14 23:33 ` Jesse Barnes
2010-05-14 23:40 ` H. Peter Anvin
2010-05-15 0:02 ` Jesse Barnes
2010-05-14 23:20 ` H. Peter Anvin
2010-05-14 23:28 ` Jesse Barnes
2010-05-14 23:32 ` H. Peter Anvin
2010-05-14 23:34 ` Jesse Barnes
2010-05-14 23:39 ` H. Peter Anvin
2010-05-15 0:00 ` Jesse Barnes
2010-05-15 0:14 ` H. Peter Anvin
2010-05-13 20:36 ` Yinghai Lu
2010-05-13 20:34 ` H. Peter Anvin
2010-05-13 18:58 ` Bjorn Helgaas
2010-05-28 16:53 ` Mike Travis
2010-05-28 17:00 ` H. Peter Anvin
2010-05-28 17:10 ` Mike Travis
2010-05-28 19:28 ` Jesse Barnes
2010-05-28 20:04 ` H. Peter Anvin
2010-05-31 11:12 ` Mike Travis
2010-05-31 16:36 ` H. Peter Anvin
2010-06-01 22:49 ` Bjorn Helgaas
2010-06-02 7:31 ` H. Peter Anvin
2010-06-02 15:45 ` Bjorn Helgaas
2010-06-02 15:47 ` H. Peter Anvin
2010-06-02 15:53 ` Jesse Barnes
2010-06-09 0:53 ` H. Peter Anvin
2010-06-09 1:26 ` Jesse Barnes
2010-06-09 14:23 ` Mike Habeck
2010-06-02 15:53 ` Mike Habeck
2010-06-02 16:40 ` Bjorn Helgaas
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=20100514160651.2b4ee3d7@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=bjorn.helgaas@hp.com \
--cc=habeck@sgi.com \
--cc=hpa@zytor.com \
--cc=jacob.jun.pan@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=myron.stowe@hp.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=travis@sgi.com \
--cc=x86@kernel.org \
--cc=yinghai.lu@oracle.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).