From patchwork Fri Feb 21 09:39:36 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Petazzoni X-Patchwork-Id: 3695161 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 4B32CBF13A for ; Fri, 21 Feb 2014 09:39:57 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 662F9201B6 for ; Fri, 21 Feb 2014 09:39:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8127F2017D for ; Fri, 21 Feb 2014 09:39:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754491AbaBUJjy (ORCPT ); Fri, 21 Feb 2014 04:39:54 -0500 Received: from top.free-electrons.com ([176.31.233.9]:35597 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753499AbaBUJjw (ORCPT ); Fri, 21 Feb 2014 04:39:52 -0500 Received: by mail.free-electrons.com (Postfix, from userid 106) id 972EC895; Fri, 21 Feb 2014 10:39:52 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from skate (col31-4-88-188-83-94.fbx.proxad.net [88.188.83.94]) by mail.free-electrons.com (Postfix) with ESMTPSA id BB388859; Fri, 21 Feb 2014 10:39:39 +0100 (CET) Date: Fri, 21 Feb 2014 10:39:36 +0100 From: Thomas Petazzoni To: Gerlando Falauto Cc: Jason Gunthorpe , Bjorn Helgaas , "linux-pci@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Andrew Lunn , Sebastian Hesselbarth , Jason Cooper , "Longchamp, Valentin" , Ezequiel Garcia , Lior Amsalem , Gregory =?UTF-8?B?Q2zDqW1lbnQ=?= Subject: Re: pci-mvebu driver on km_kirkwood Message-ID: <20140221103936.56b3d9f8@skate> In-Reply-To: <53071970.1040400@keymile.com> References: <53039894.10905@keymile.com> <20140218212751.07c2aeb5@skate> <53046D98.6020801@keymile.com> <20140219102658.76eec91e@skate> <53047BBB.6040108@keymile.com> <20140219143749.65ff3155@skate> <20140220095518.7ca36f0a@skate> <20140220173518.GA19893@obsidianresearch.com> <20140220212914.29ddc031@skate> <20140221003227.GF19893@obsidianresearch.com> <20140221093444.35870a73@skate> <5307152D.3020804@keymile.com> <20140221101218.45766e8a@skate> <53071970.1040400@keymile.com> Organization: Free Electrons X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Dear Gerlando Falauto, On Fri, 21 Feb 2014 10:16:32 +0100, Gerlando Falauto wrote: > > Sure, but whichever choice we make, the Linux PCI core must know by how > > much we've enlarge the bridge window BAR, otherwise the Linux PCI core > > may allocate for the next bridge window BAR a range of addresses that > > doesn't overlap with what it has allocate for the previous bridge > > window BAR, but that ends up overlapping due to us "extending" the > > previous bridge window BAR to match the MBus requirements. > > > > Gerlando, would you be able to test a quick hack that creates 2 windows > > to cover exactly 128 MB + 64 MB ? This would at least allow us to > > confirm that the strategy of splitting in multiple windows is usable. > > Sure, though probably not until next week. No problem at all. > I guess it would then also be useful to restore my previous setup, where > the total PCIe aperture is 192MB, right? Yes, that's the case I'm interested in at the moment. If you could try the above (ugly) patch, and see if you can access all your device BARs, it would be interesting. It would tell us if two separate windows having the same target/attribute and consecutive placement in the physical address space can actually work to address a given PCIe device. As you will see, the patch makes a very ugly special case for 192 MB :-) diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c index 2394e97..f763ecc 100644 --- a/drivers/bus/mvebu-mbus.c +++ b/drivers/bus/mvebu-mbus.c @@ -223,11 +223,13 @@ static int mvebu_mbus_window_conflicts(struct mvebu_mbus_state *mbus, if ((u64)base < wend && end > wbase) return 0; +#if 0 /* * Check if target/attribute conflicts */ if (target == wtarget && attr == wattr) return 0; +#endif } return 1; diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c index 2aa7b77c..67fe6df 100644 --- a/drivers/pci/host/pci-mvebu.c +++ b/drivers/pci/host/pci-mvebu.c @@ -361,8 +361,15 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port) (((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) - port->memwin_base; - mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr, - port->memwin_base, port->memwin_size); + if (port->memwin_size == (SZ_128M + SZ_64M)) { + mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr, + port->memwin_base, SZ_128M); + mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr, + port->memwin_base + SZ_128M, SZ_64M); + } else { + mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr, + port->memwin_base, port->memwin_size); + } } /*