From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moutng.kundenserver.de ([212.227.17.13]:54388 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752108AbaCOI7M (ORCPT ); Sat, 15 Mar 2014 04:59:12 -0400 From: Arnd Bergmann To: Tanmay Inamdar Subject: Re: [PATCH v4 2/4] arm64: dts: APM X-Gene PCIe device tree nodes Date: Sat, 15 Mar 2014 09:58:52 +0100 Cc: Bjorn Helgaas , Jason Gunthorpe , Grant Likely , Rob Herring , Catalin Marinas , Rob Landley , Liviu Dudau , "linux-pci@vger.kernel.org" , "devicetree@vger.kernel.org" , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, patches , Jon Masters References: <1394085963-27553-1-git-send-email-tinamdar@apm.com> <201403141307.23286.arnd@arndb.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Message-Id: <201403150958.52419.arnd@arndb.de> Sender: linux-pci-owner@vger.kernel.org List-ID: On Saturday 15 March 2014, Tanmay Inamdar wrote: > On Fri, Mar 14, 2014 at 5:07 AM, Arnd Bergmann wrote: > > On Thursday 06 March 2014, Tanmay Inamdar wrote: > >> + pcie0: pcie@1f2b0000 { > >> + status = "disabled"; > >> + device_type = "pci"; > >> + compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie"; > >> + #interrupt-cells = <1>; > >> + #size-cells = <2>; > >> + #address-cells = <3>; > >> + reg = < 0x00 0x1f2b0000 0x0 0x00010000 /* Controller registers */ > >> + 0xe0 0xd0000000 0x0 0x00200000>; /* PCI config space */ > >> + reg-names = "csr", "cfg"; > >> + ranges = <0x01000000 0x00 0x00000000 0xe0 0x00000000 0x00 0x00010000 /* io */ > >> + 0x02000000 0x00 0x10000000 0xe0 0x10000000 0x00 0x80000000>; /* mem */ > >> + dma-ranges = <0x42000000 0x40 0x00000000 0x40 0x00000000 0x40 0x00000000>; > >> + interrupt-map-mask = <0x0 0x0 0x0 0x7>; > >> + interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1 > >> + 0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1 > >> + 0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1 > >> + 0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>; > >> + clocks = <&pcie0clk 0>; > >> + }; > > > > Is 0x40.0x00000000 the start of your RAM? I had expected RAM to start at 0.0, > > and in that case the dma-ranges property would be wrong. > > RAM starting address is 0x40_00000000. Ok, it's good then. Thanks for the clarification, I keep losing track of how each of the ~40 SoCs I'm dealing with handles these things. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Sat, 15 Mar 2014 09:58:52 +0100 Subject: [PATCH v4 2/4] arm64: dts: APM X-Gene PCIe device tree nodes In-Reply-To: References: <1394085963-27553-1-git-send-email-tinamdar@apm.com> <201403141307.23286.arnd@arndb.de> Message-ID: <201403150958.52419.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Saturday 15 March 2014, Tanmay Inamdar wrote: > On Fri, Mar 14, 2014 at 5:07 AM, Arnd Bergmann wrote: > > On Thursday 06 March 2014, Tanmay Inamdar wrote: > >> + pcie0: pcie at 1f2b0000 { > >> + status = "disabled"; > >> + device_type = "pci"; > >> + compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie"; > >> + #interrupt-cells = <1>; > >> + #size-cells = <2>; > >> + #address-cells = <3>; > >> + reg = < 0x00 0x1f2b0000 0x0 0x00010000 /* Controller registers */ > >> + 0xe0 0xd0000000 0x0 0x00200000>; /* PCI config space */ > >> + reg-names = "csr", "cfg"; > >> + ranges = <0x01000000 0x00 0x00000000 0xe0 0x00000000 0x00 0x00010000 /* io */ > >> + 0x02000000 0x00 0x10000000 0xe0 0x10000000 0x00 0x80000000>; /* mem */ > >> + dma-ranges = <0x42000000 0x40 0x00000000 0x40 0x00000000 0x40 0x00000000>; > >> + interrupt-map-mask = <0x0 0x0 0x0 0x7>; > >> + interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1 > >> + 0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1 > >> + 0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1 > >> + 0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>; > >> + clocks = <&pcie0clk 0>; > >> + }; > > > > Is 0x40.0x00000000 the start of your RAM? I had expected RAM to start at 0.0, > > and in that case the dma-ranges property would be wrong. > > RAM starting address is 0x40_00000000. Ok, it's good then. Thanks for the clarification, I keep losing track of how each of the ~40 SoCs I'm dealing with handles these things. Arnd