From: Gavin Shan <gwshan@linux.vnet.ibm.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
"Gavin Shan" <gwshan@linux.vnet.ibm.com>,
"Yinghai Lu" <yinghai@kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"Alexey Voronkov" <zermond@gmail.com>,
"David Airlie" <airlied@linux.ie>,
"Alex Deucher" <alexdeucher@gmail.com>,
"Marek Kordík" <kordikmarek@gmail.com>,
"Richard Yang" <weiyang@linux.vnet.ibm.com>
Subject: Re: Regression: bug 85491: radeon 0000:01:00.0: Fatal error during GPU init
Date: Tue, 9 Dec 2014 10:38:55 +1100 [thread overview]
Message-ID: <20141208233855.GA15713@shangw> (raw)
In-Reply-To: <CAErSpo7pMAL5i2aPGV3u5F178bHeQTtjASckKs9NaUbEGaxv3Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
On Mon, Dec 08, 2014 at 02:46:00PM -0700, Bjorn Helgaas wrote:
>[-cc Saifi (bouncing)]
>
>On Mon, Dec 8, 2014 at 2:38 PM, Benjamin Herrenschmidt
><benh@kernel.crashing.org> wrote:
>> On Mon, 2014-12-08 at 14:04 -0700, Bjorn Helgaas wrote:
>>>
>>> However, I think 5b28541552ef is taking the wrong approach. Consider
>>> a device that, like this Radeon, has a 32-bit prefetchable BAR. If
>>> the upstream bridge has a 32-bit prefetchable window, things work as
>>> expected -- we put the prefetchable BAR in the prefetchable window.
>>> But if the bridge has a 64-bit prefetchable window, we put that same
>>> BAR in a 32-bit non-prefetchable window.
>>
>> Well, that's expected, unless the 64-bit prefetchable window happens to
>> be fully enclosed in 32-bit space ... So maybe the approach is to check
>> that this is the case and "downgrade" such 64-bit prefetchable BARs to
>> 32-bit ...
>
>Yeah, I didn't word that very clearly. I meant that after
>5b28541552ef, that 64-bit window is wasted unless there's a 64-bit BAR
>below it; we can't even place the window below 4GB and use it for
>32-bit prefetchable BARs.
>
Yes, I agree. It's why I suggested to return error from pbus_size_mem()
to indicate the case: 64-bits prefetchable window isn't used and it's
still available to be used by child 32-bits prefetchable BARs. Please
take a look on the attached draft patch, which helps to explain the idea
only.
Thanks,
Gavin
[-- Attachment #2: 0001-PCI-Use-64-bits-pref-window-accomodate-pref-BARs.patch --]
[-- Type: text/x-diff, Size: 1749 bytes --]
>From bef332d8e2bfc464da202daa2c9d1415db1f1224 Mon Sep 17 00:00:00 2001
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
Date: Tue, 9 Dec 2014 10:21:24 +1100
Subject: [PATCH] PCI: Use 64-bits pref window accomodate pref BARs
The PCI resource allocation and reassignment has been changed a
lot by Commit 5b28541552ef ("PCI: Restrict 64-bit prefetchable
bridge windows to 64-bit resources"): If parent bridge has 64-bits
prefetchable window, all child 64-bits prefetchable BARs are
expected to be assigned from the window. The left child BARs are
going to be allocated from parent non-prefetchable window.
If there're no child 64-bits prefetchable BARs, pbus_size_mem()
should return error so that the 64-bits prefetchable window still
can be used to accomodate child 32-bits prefetchable BARs.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
v1: Draft patch to explain idea only
---
drivers/pci/setup-bus.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 0482235..7a7778f 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -989,6 +989,16 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
}
}
+ /*
+ * If we don't have unassigned BARs with indicated type, the
+ * corresponding window won't be used. However, we might use
+ * this window for BARs with other types, e.g. 64-bits pref
+ * window for 32-bits pref BARs. Here to return error to
+ * indicate the case.
+ */
+ if (!size)
+ return -ENODEV;
+
min_align = calculate_mem_align(aligns, max_order);
min_align = max(min_align, window_alignment(bus, b_res->flags));
size0 = calculate_memsize(size, min_size, 0, resource_size(b_res), min_align);
--
1.8.3.2
next prev parent reply other threads:[~2014-12-08 23:39 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-03 22:15 Regression: bug 85491: radeon 0000:01:00.0: Fatal error during GPU init Bjorn Helgaas
2014-12-04 0:51 ` Bjorn Helgaas
2014-12-04 1:44 ` Yinghai Lu
2014-12-04 17:34 ` Bjorn Helgaas
2014-12-04 22:06 ` Yinghai Lu
2014-12-05 10:59 ` Benjamin Herrenschmidt
2014-12-08 0:47 ` Gavin Shan
2014-12-08 21:04 ` Bjorn Helgaas
2014-12-08 21:38 ` Benjamin Herrenschmidt
2014-12-08 21:46 ` Bjorn Helgaas
2014-12-08 23:38 ` Gavin Shan [this message]
2014-12-09 0:21 ` Yinghai Lu
2014-12-19 22:17 ` Bjorn Helgaas
2014-12-20 0:23 ` Bjorn Helgaas
2014-12-20 0:34 ` Yinghai Lu
2014-12-20 0:56 ` Bjorn Helgaas
2014-12-20 1:33 ` Yinghai Lu
2014-12-23 1:53 ` Yinghai Lu
2014-12-23 21:41 ` Bjorn Helgaas
2014-12-24 2:29 ` Yinghai Lu
2014-12-24 17:26 ` Bjorn Helgaas
2014-12-24 20:29 ` Yinghai Lu
2014-12-25 15:46 ` Marek Kordík
2014-12-25 21:12 ` Yinghai Lu
2015-01-09 18:45 ` Bjorn Helgaas
2015-01-09 20:38 ` Yinghai Lu
2014-12-22 8:17 ` Wei Yang
2014-12-22 19:50 ` Bjorn Helgaas
2014-12-04 1:38 ` Yinghai Lu
2014-12-04 1:41 ` Yinghai Lu
2014-12-04 16:15 ` Bjorn Helgaas
2014-12-04 22:15 ` Yinghai Lu
2014-12-04 22:25 ` Bjorn Helgaas
2014-12-04 2:01 ` Yinghai Lu
2014-12-04 16:37 ` Bjorn Helgaas
2014-12-04 22:24 ` Yinghai Lu
2014-12-05 0:24 ` Yinghai Lu
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=20141208233855.GA15713@shangw \
--to=gwshan@linux.vnet.ibm.com \
--cc=airlied@linux.ie \
--cc=alexdeucher@gmail.com \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=kordikmarek@gmail.com \
--cc=linux-pci@vger.kernel.org \
--cc=weiyang@linux.vnet.ibm.com \
--cc=yinghai@kernel.org \
--cc=zermond@gmail.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 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.