From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751453AbcGNGD6 (ORCPT ); Thu, 14 Jul 2016 02:03:58 -0400 Received: from mail-sn1nam02on0080.outbound.protection.outlook.com ([104.47.36.80]:62969 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751239AbcGNGDv convert rfc822-to-8bit (ORCPT ); Thu, 14 Jul 2016 02:03:51 -0400 Authentication-Results: spf=pass (sender IP is 149.199.60.100) smtp.mailfrom=xilinx.com; free-electrons.com; dkim=none (message not signed) header.d=none;free-electrons.com; dmarc=bestguesspass action=none header.from=xilinx.com; From: Bharat Kumar Gogada To: Lorenzo Pieralisi CC: Arnd Bergmann , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Bjorn Helgaas , "Liviu.Dudau@arm.com" , nofooter , "thomas.petazzoni@free-electrons.com" Subject: RE: Purpose of pci_remap_iospace Thread-Topic: Purpose of pci_remap_iospace Thread-Index: AdHcCL/kUAd2y2DJSzGJLmHMsyqJOP//mBqA//4BERCAA5D6gP//OLbggAEfggD//mw2IA== Date: Thu, 14 Jul 2016 06:03:44 +0000 Message-ID: <8520D5D51A55D047800579B094147198258B8E24@XAP-PVEXMBX01.xlnx.xilinx.com> References: <8520D5D51A55D047800579B094147198258B85DC@XAP-PVEXMBX01.xlnx.xilinx.com> <3927657.6zNCtCntSU@wuerfel> <8520D5D51A55D047800579B094147198258B8952@XAP-PVEXMBX01.xlnx.xilinx.com> <4235946.u1vYRsOpTR@wuerfel> <8520D5D51A55D047800579B094147198258B8B06@XAP-PVEXMBX01.xlnx.xilinx.com> <20160713134642.GA29309@red-moon> In-Reply-To: <20160713134642.GA29309@red-moon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.96.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-RCIS-Action: ALLOW X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.0.0.1202-22448.005 X-TM-AS-User-Approved-Sender: Yes;Yes X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:149.199.60.100;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(199003)(189002)(24454002)(189998001)(76176999)(92566002)(356003)(54356999)(50986999)(8676002)(47776003)(110136002)(19580395003)(46406003)(19580405001)(305945005)(5250100002)(11100500001)(7696003)(81166006)(5003600100003)(81156014)(7846002)(7736002)(50466002)(5890100001)(2906002)(8936002)(55846006)(8746002)(97756001)(87936001)(2920100001)(4326007)(2950100001)(2900100001)(106466001)(6116002)(102836003)(23726003)(63266004)(3846002)(586003)(33656002)(93886004)(575784001)(86362001)(107986001)(5001870100001);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1NAM02HT190;H:xsj-pvapsmtpgw02;FPR:;SPF:Pass;PTR:xapps1.xilinx.com,unknown-60-100.xilinx.com;A:1;MX:1;CAT:NONE;LANG:en;CAT:NONE; X-MS-Office365-Filtering-Correlation-Id: f6dc16b2-922d-4163-1756-08d3abac9ed0 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(8251501002);SRVR:SN1NAM02HT190; X-Microsoft-Antispam-PRVS: <3ef5817fa0bf4f2581d26ad6dbc2af16@SN1NAM02HT190.eop-nam02.prod.protection.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(13024025)(13023025)(13017025)(13015025)(5005006)(13018025)(3002001)(10201501046)(6055026);SRVR:SN1NAM02HT190;BCL:0;PCL:0;RULEID:;SRVR:SN1NAM02HT190; X-Forefront-PRVS: 00032065B2 X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2016 06:03:47.2627 (UTC) X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.60.100];Helo=[xsj-pvapsmtpgw02] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT190 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Subject: Re: Purpose of pci_remap_iospace > > On Wed, Jul 13, 2016 at 12:30:44PM +0000, Bharat Kumar Gogada wrote: > > [...] > > > err = of_pci_get_host_bridge_resources(node, 0, 0xff, &res, &iobase); > > if (err) { > > pr_err("Getting bridge resources failed\n"); > > return err; > > } > > resource_list_for_each_entry(window, &res) { //code for io resource > > struct resource *res = window->res; > > u64 restype = resource_type(res); > > > > switch (restype) { > > case IORESOURCE_IO: > > err = pci_remap_iospace(res, iobase); > > if(err) > > pr_info("FAILED TO IPREMAP RESOURCE\n"); > > break; > > default: > > dev_err(pcie->dev, "invalid resource %pR\n", > > res); > > > > } > > } > > > > Other than above code I haven't done any change in driver. > > > Here is your PCI bridge mem space window assignment. I do not see an IO > window assignment which makes me think that IO cycles and relative IO > window is not enabled through the bridge, that's the reason you can't assign > IO space to the endpoint, because it has no parent IO window enabled IIUC. > We sorted this out, enabled the IO base limit / upper 16bit registers in the bridge for 32 bit decode. However my IO address being assigned to EP is different than what I provide in device tree. Device tree property: ranges = <0x01000000 0x00000000 0x00000000 0x00000000 0xe0000000 0 0x00010000 //io 0x02000000 0x00000000 0xe0100000 0x00000000 0xe0100000 0 0x0ef00000>; //non prefetchabe memory Here is the boot log: [ 2.312504] nwl-pcie fd0e0000.pcie: Link is UP [ 2.312548] PCI host bridge /amba/pcie@fd0e0000 ranges: [ 2.312565] No bus range found for /amba/pcie@fd0e0000, using [bus 00-ff] [ 2.312591] IO 0xe0000000..0xe000ffff -> 0x00000000 [ 2.312610] MEM 0xe0100000..0xeeffffff -> 0xe0100000 [ 2.312711] nwl-pcie fd0e0000.pcie: PCI host bridge to bus 0000:00 [ 2.312729] pci_bus 0000:00: root bus resource [bus 00-ff] [ 2.312745] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] [ 2.312761] pci_bus 0000:00: root bus resource [mem 0xe0100000-0xeeffffff] [ 2.312993] pci 0000:00:00.0: cannot attach to SMMU, is it on the same bus? [ 2.313009] iommu: Adding device 0000:00:00.0 to group 1 [ 2.313363] pci 0000:01:00.0: cannot attach to SMMU, is it on the same bus? [ 2.313379] iommu: Adding device 0000:01:00.0 to group 1 [ 2.313434] pci 0000:00:00.0: BAR 8: assigned [mem 0xe0100000-0xe02fffff] [ 2.313452] pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff] [ 2.313469] pci 0000:00:00.0: BAR 6: assigned [mem 0xe0300000-0xe03007ff pref] [ 2.313495] pci 0000:01:00.0: BAR 0: assigned [mem 0xe0100000-0xe01fffff 64bit] [ 2.313529] pci 0000:01:00.0: BAR 2: assigned [mem 0xe0200000-0xe02fffff 64bit] [ 2.313561] pci 0000:01:00.0: BAR 4: assigned [io 0x1000-0x103f] [ 2.313581] pci 0000:00:00.0: PCI bridge to [bus 01-0c] [ 2.313597] pci 0000:00:00.0: bridge window [io 0x1000-0x1fff] [ 2.313614] pci 0000:00:00.0: bridge window [mem 0xe0100000-0xe02fffff] If we are mapping our IO space to 0xe0000000 and 64k size, why kernel is showing 0x1000-0x1fff which is 4k ? Lspci of bridge : 00:00.0 PCI bridge: Xilinx Corporation Device a024 (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR-