From: yhlu <yhlu.kernel@gmail.com>
To: Greg KH <gregkh@suse.de>
Cc: Linus Torvalds <torvalds@osdl.org>,
Roland Dreier <rolandd@cisco.com>,
linville@tuxdriver.com,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
openib-general@openib.org
Subject: Re: mthca and LinuxBIOS
Date: Fri, 5 Aug 2005 15:25:02 -0700 [thread overview]
Message-ID: <86802c4405080515257ddaa8d2@mail.gmail.com> (raw)
In-Reply-To: <20050805220015.GA3524@suse.de>
In LinuxBIOS, We can allocate 64 bit region ( 0xfc0000000....) to the
mellanox Infiniband card. Some range above 4G. So the mmio below 4G
is some smaller only 128M, Otherwise need 512M. If 4 IB cards are
used, the mmio will be 2G. For new opteron E stepping, We could use
hareware memhole support. But if the CPU is before opteron E, We only
can use SW mem mapping ( will lose some performance) or lose (2G RAM).
at such case We need 64bit pref mem. We only lose 128M even four IB
card are installed.
yesterday, someone add pci_restore_bars...., that will call
pci_update_resource, and it will overwirte upper 32 bit of BAR2 and
BAR4 of IB card.
So the patch make pci_restore_resource
1. don't touch BAR3, and BAR5, if BAR2, and BAR4 are 64 bit MEM IO
2. not assume BAR2 and BAR4 upper 32bit is 0 if if BAR2, and BAR4 are
64 bit MEM IO
YH
On 8/5/05, Greg KH <gregkh@suse.de> wrote:
> On Fri, Aug 05, 2005 at 01:38:37PM -0700, Linus Torvalds wrote:
> >
> > Hmm.. This looks half-way sane, but too ugly for words.
> >
> > I'd much rather see that when we detect a 64-bit resource, we always mark
> > the next resource as being reserved some way, and then we just make
> > pci_update_resource() ignore such reserved resources.
> >
> > The
> >
> > if((resno & 1)==1) {
> > /* check if previous reg is 64 mem */
> > ..
> >
> > stuff is really too ugly.
>
> Yeah, that's not nice.
>
> But what's the real problem we are trying to fix here? I seem to have
> missed that in the email thread somehow.
>
> > Greg? Ivan?
>
> Ivan's the pci resource guru, any thoughts as to how to do this in a
> nicer way?
>
> thanks,
>
> greg k-h
>
next prev parent reply other threads:[~2005-08-05 22:26 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-28 20:31 [PATCH 0/2] REALLY final InfiniBand updates for 2.6.13 Roland Dreier
2005-07-28 20:31 ` [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes Roland Dreier
2005-07-28 20:31 ` [PATCH 2/2] [IPoIB] Handle sending of unicast RARP responses Roland Dreier
2005-08-04 0:58 ` [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes yhlu
2005-08-04 1:39 ` [openib-general] " Grant Grundler
2005-08-04 4:44 ` mthca and LinuxBIOS (was: [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes) Roland Dreier
2005-08-04 16:33 ` yhlu
2005-08-04 16:36 ` mthca and LinuxBIOS Roland Dreier
2005-08-04 17:23 ` yhlu
2005-08-04 18:01 ` yhlu
2005-08-04 18:35 ` Roland Dreier
2005-08-04 19:30 ` yhlu
2005-08-05 3:47 ` Roland Dreier
2005-08-05 18:03 ` yhlu
2005-08-05 18:07 ` yhlu
2005-08-05 18:13 ` Roland Dreier
2005-08-05 18:26 ` yhlu
2005-08-05 19:25 ` yhlu
2005-08-05 19:45 ` yhlu
2005-08-05 20:28 ` yhlu
2005-08-05 20:38 ` Linus Torvalds
2005-08-05 22:00 ` Greg KH
2005-08-05 22:25 ` yhlu [this message]
2005-08-05 23:03 ` Greg KH
2005-08-06 5:29 ` [openib-general] " Grant Grundler
2005-08-05 23:06 ` Linus Torvalds
2005-08-05 23:59 ` [openib-general] " Grant Grundler
2005-08-06 4:33 ` Grant Grundler
2005-08-06 23:52 ` yhlu
2005-08-07 9:49 ` Ivan Kokshaysky
2005-08-05 18:11 ` Roland Dreier
2005-08-06 0:57 ` yhlu
2005-08-06 1:30 ` Roland Dreier
2005-08-06 2:47 ` yhlu
2005-08-04 6:42 ` [PATCH 1/2] [IB/cm]: Correct CM port redirect reject codes Michael S. Tsirkin
2005-08-04 18:22 ` yhlu
2005-08-08 12:21 ` Michael S. Tsirkin
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=86802c4405080515257ddaa8d2@mail.gmail.com \
--to=yhlu.kernel@gmail.com \
--cc=gregkh@suse.de \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=openib-general@openib.org \
--cc=rolandd@cisco.com \
--cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.