From patchwork Mon Dec 8 23:38:55 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gavin Shan X-Patchwork-Id: 5459671 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id B3F5FBEEA8 for ; Mon, 8 Dec 2014 23:39:10 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9EEDF2012B for ; Mon, 8 Dec 2014 23:39:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6EE4C20108 for ; Mon, 8 Dec 2014 23:39:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752197AbaLHXjG (ORCPT ); Mon, 8 Dec 2014 18:39:06 -0500 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:34989 "EHLO e23smtp08.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751520AbaLHXjE (ORCPT ); Mon, 8 Dec 2014 18:39:04 -0500 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 9 Dec 2014 09:39:01 +1000 Received: from d23dlp03.au.ibm.com (202.81.31.214) by e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 9 Dec 2014 09:38:59 +1000 Received: from d23relay08.au.ibm.com (d23relay08.au.ibm.com [9.185.71.33]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id 7D1243578048 for ; Tue, 9 Dec 2014 10:38:58 +1100 (EST) Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay08.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sB8Ncv6h42139718 for ; Tue, 9 Dec 2014 10:38:58 +1100 Received: from d23av04.au.ibm.com (localhost [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sB8NcuDV018539 for ; Tue, 9 Dec 2014 10:38:57 +1100 Received: from shangw (haven.au.ibm.com [9.192.253.15]) by d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id sB8NcuAQ018527; Tue, 9 Dec 2014 10:38:56 +1100 Received: by shangw (Postfix, from userid 1000) id 5934B3E0282; Tue, 9 Dec 2014 10:38:55 +1100 (EST) Date: Tue, 9 Dec 2014 10:38:55 +1100 From: Gavin Shan To: Bjorn Helgaas Cc: Benjamin Herrenschmidt , Gavin Shan , Yinghai Lu , "linux-pci@vger.kernel.org" , Alexey Voronkov , David Airlie , Alex Deucher , Marek =?iso-8859-1?Q?Kord=EDk?= , Richard Yang Subject: Re: Regression: bug 85491: radeon 0000:01:00.0: Fatal error during GPU init Message-ID: <20141208233855.GA15713@shangw> Reply-To: Gavin Shan References: <20141204173411.GA5949@google.com> <1417777177.4741.69.camel@kernel.crashing.org> <20141208004735.GA15508@shangw> <1418074683.13358.1.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14120823-0029-0000-0000-000000C5E290 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 > 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 From bef332d8e2bfc464da202daa2c9d1415db1f1224 Mon Sep 17 00:00:00 2001 From: Gavin Shan 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 --- 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