From patchwork Wed Feb 12 19:43:13 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Gunthorpe X-Patchwork-Id: 3640331 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 89D499F1EE for ; Wed, 12 Feb 2014 19:43:51 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9D4922020A for ; Wed, 12 Feb 2014 19:43:50 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 988ED201ED for ; Wed, 12 Feb 2014 19:43:49 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WDfif-0006e9-Lg; Wed, 12 Feb 2014 19:43:41 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WDfid-0007Dc-7a; Wed, 12 Feb 2014 19:43:39 +0000 Received: from quartz.orcorp.ca ([184.70.90.242]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WDfiZ-0007C1-Ru for linux-arm-kernel@lists.infradead.org; Wed, 12 Feb 2014 19:43:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=obsidianresearch.com; s=rsa1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=JqpKKTJU4+o6chRWktFHXgVyo+hUuJgy384ZKEGgkTA=; b=qJMJCIk/hkxHk4wNRk/YxRAcVlxGNXmSBp1k6SKnz4QMWpN8HFsys4V/n7mBfM34DvZhSvzs6NO9E7aO0w0ekYGE8rz/D26k+0bzK11MR1fpvxbKO3q8Cocvci34ABSZBDarzgMTh+hq1Ihk9Ec7thvoZQQ7cE83Svh1se7YbZY=; Received: from [10.0.0.161] (helo=jggl.edm.orcorp.ca) by quartz.orcorp.ca with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WDfiE-0005vU-0o; Wed, 12 Feb 2014 12:43:14 -0700 Received: from jgg by jggl.edm.orcorp.ca with local (Exim 4.80) (envelope-from ) id 1WDfiD-0004aP-LC; Wed, 12 Feb 2014 12:43:13 -0700 Date: Wed, 12 Feb 2014 12:43:13 -0700 From: Jason Gunthorpe To: Arnd Bergmann Subject: Re: [PATCH 2/3] PCI: ARM: add support for virtual PCI host controller Message-ID: <20140212194313.GA17248@obsidianresearch.com> References: <1391532784-1953-1-git-send-email-will.deacon@arm.com> <201402092130.25615.arnd@arndb.de> <20140210173450.GA5554@obsidianresearch.com> <2006726.HhIT01YuXY@wuerfel> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <2006726.HhIT01YuXY@wuerfel> User-Agent: Mutt/1.5.21 (2010-09-15) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.161 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140212_144336_022035_4480D402 X-CRM114-Status: GOOD ( 15.87 ) X-Spam-Score: -2.0 (--) Cc: Thomas Petazzoni , "linux-pci@vger.kernel.org" , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,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 Tue, Feb 11, 2014 at 11:42:52AM +0100, Arnd Bergmann wrote: > I looked briefly at the code and found that mach-kirkwood/pcie.c does > both request_resource() and pci_add_resource_offset(), while > drivers/pci/host/pci-mvebu.c only does the latter. Does the patch > below restore the previous behavior? It gets closer: e0000000-f0000000 : e0000000-e00fffff : PCI Bus 0000:01 e0000000-e001ffff : 0000:01:00.0 e0001000-e0001fff : /mbus/pex@e0000000/pcie@1,0/fpga@0/fpga_sysmon@1000 This patch: specific structure .. Jason diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c index 2394e97..7fd54e9 100644 --- a/drivers/bus/mvebu-mbus.c +++ b/drivers/bus/mvebu-mbus.c @@ -876,14 +876,14 @@ static void __init mvebu_mbus_get_pcie_resources(struct device_node *np, ret = of_property_read_u32_array(np, "pcie-mem-aperture", reg, ARRAY_SIZE(reg)); if (!ret) { mem->start = reg[0]; - mem->end = mem->start + reg[1]; + mem->end = mem->start + reg[1] - 1; mem->flags = IORESOURCE_MEM; } ret = of_property_read_u32_array(np, "pcie-io-aperture", reg, ARRAY_SIZE(reg)); if (!ret) { io->start = reg[0]; - io->end = io->start + reg[1]; + io->end = io->start + reg[1] - 1; io->flags = IORESOURCE_IO; } } Fixes the wrong length (e0000000-f0000000 should be e0000000-efffffff) And this fixes the : diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c index ef8691a..fbb89cb 100644 --- a/drivers/pci/host/pci-mvebu.c +++ b/drivers/pci/host/pci-mvebu.c @@ -109,7 +109,9 @@ struct mvebu_pcie { struct mvebu_pcie_port *ports; struct msi_chip *msi; struct resource io; + char io_name[30]; struct resource realio; + char mem_name[30]; struct resource mem; struct resource busn; int nports; @@ -681,10 +683,29 @@ static int mvebu_pcie_setup(int nr, struct pci_sys_data *sys) { struct mvebu_pcie *pcie = sys_to_pcie(sys); int i; + int domain = 0; +#ifdef CONFIG_PCI_DOMAINS + domain = sys->domain; +#endif + + snprintf(pcie->mem_name, sizeof(pcie->mem_name), "PCI MEM %04x", domain); + pcie->mem.name = pcie->mem_name; + + snprintf(pcie->io_name, sizeof(pcie->io_name), "PCI I/O %04x", domain); + pcie->realio.name = pcie->io_name; Still missing release_region.. Thoughts on upstreamining these bits? > Since the mvebu_pcie_setup() function seems very generic at this, > we should probably try to factor out that code into a common > helper, at least for arm64, but ideally shared with arm32 > as well. Yah, especially since people are not getting it completely right.. But some of the trouble here is a lack of a generic pci host driver structure, eg I have to pull the domain number out of the ARM32