Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755305AbbKRGvw (ORCPT ); Wed, 18 Nov 2015 01:51:52 -0500 Received: from mail-cys01nam02on0086.outbound.protection.outlook.com ([104.47.37.86]:9997 "EHLO NAM02-CY1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932078AbbKRGvt convert rfc822-to-8bit (ORCPT ); Wed, 18 Nov 2015 01:51:49 -0500 Authentication-Results: spf=pass (sender IP is 149.199.60.100) smtp.mailfrom=xilinx.com; arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=bestguesspass action=none header.from=xilinx.com; From: Bharat Kumar Gogada To: Ray Jui , Marc Zyngier CC: "robh+dt@kernel.org" , "pawel.moll@arm.com" , "mark.rutland@arm.com" , "ijc+devicetree@hellion.org.uk" , "galak@codeaurora.org" , Michal Simek , Soren Brinkmann , "bhelgaas@google.com" , "arnd@arndb.de" , "tinamdar@apm.com" , "treding@nvidia.com" , "Minghuan.Lian@freescale.com" , "m-karicheri2@ti.com" , "hauke@hauke-m.de" , "dhdang@apm.com" , "sbranden@broadcom.com" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , Ravikiran Gummaluri , "Robin Murphy" Subject: RE: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller Thread-Topic: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller Thread-Index: AQHRHErso4InQxFa/U6lsZcC7ZFx5Z6eREyAgABx1ICAAPnokP//w9EAgADJluD//4MAgIAAKdGAgAF3q3A= Date: Wed, 18 Nov 2015 06:51:41 +0000 Message-ID: <8520D5D51A55D047800579B0941471982585CEB1@XAP-PVEXMBX01.xlnx.xilinx.com> References: <1447223619-30945-1-git-send-email-bharatku@xilinx.com> <5649F2D9.7070902@arm.com> <564A5255.3020603@broadcom.com> <8520D5D51A55D047800579B0941471982585CBDA@XAP-PVEXMBX01.xlnx.xilinx.com> <20151117092100.76babf7f@arm.com> <8520D5D51A55D047800579B0941471982585CD78@XAP-PVEXMBX01.xlnx.xilinx.com> <564B31BB.3010404@arm.com> <564B54CF.5010307@broadcom.com> In-Reply-To: <564B54CF.5010307@broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.96.164] 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-21946.005 X-TM-AS-User-Approved-Sender: Yes;Yes X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:149.199.60.100;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(2980300002)(438002)(479174004)(189002)(164054003)(199003)(377454003)(24454002)(5003600100002)(63266004)(87936001)(19580395003)(106466001)(106116001)(50466002)(230783001)(76176999)(54356999)(50986999)(86362001)(46406003)(5250100002)(5001920100001)(189998001)(33656002)(6806005)(2920100001)(5007970100001)(2900100001)(5001960100002)(97756001)(5008740100001)(92566002)(55846006)(93886004)(19580405001)(5001770100001)(23726002)(81156007)(5004730100002)(2950100001)(11100500001)(102836002)(47776003)(586003)(7059030)(107986001)(5001870100001);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1NAM02HT106;H:xsj-pvapsmtpgw02;FPR:;SPF:Pass;PTR:xapps1.xilinx.com,unknown-60-100.xilinx.com;MX:1;A:1;LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(8251501001);SRVR:SN1NAM02HT106; X-Microsoft-Antispam-PRVS: <8ac5569065ea4a899604467cce9543dd@SN1NAM02HT106.eop-nam02.prod.protection.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(192813158149592); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046);SRVR:SN1NAM02HT106;BCL:0;PCL:0;RULEID:;SRVR:SN1NAM02HT106; X-Forefront-PRVS: 0764C4A8CD X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2015 06:51:46.0594 (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: SN1NAM02HT106 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4814 Lines: 126 > Subject: Re: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL > PCIe Host Controller > > > > On 11/17/2015 5:55 AM, Marc Zyngier wrote: > > On 17/11/15 13:27, Bharat Kumar Gogada wrote: > >>> > >>> On Tue, 17 Nov 2015 04:59:39 +0000 > >>> Bharat Kumar Gogada wrote: > >>> > >>>>> On 11/16/2015 7:14 AM, Marc Zyngier wrote: > >>>>>> On 11/11/15 06:33, Bharat Kumar Gogada wrote: > >>>>>>> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP. > >>>>>>> > >>>>>>> Signed-off-by: Bharat Kumar Gogada > >>>>>>> Signed-off-by: Ravi Kiran Gummaluri > >>>>>>> --- > >>>>>>> Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc > >>>>> function. > >>>>>>> Moved MSI functionality to separate functions. > >>>>>>> Changed error return values. > >>>>>>> --- > >>>>>>> .../devicetree/bindings/pci/xilinx-nwl-pcie.txt | 68 ++ > >>>>>>> drivers/pci/host/Kconfig | 16 +- > >>>>>>> drivers/pci/host/Makefile | 1 + > >>>>>>> drivers/pci/host/pcie-xilinx-nwl.c | 1062 > >>>>> ++++++++++++++++++++ > >>>>>>> 4 files changed, 1144 insertions(+), 3 deletions(-) > >>>>>>> create mode 100644 > >>>>>>> Documentation/devicetree/bindings/pci/xilinx-nwl- > >>>>> pcie.txt > >>>>>>> create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c > >>>>>>> > >>>>>> > >>>>>> [...] > >>>>>> > >>>>>>> +static int nwl_pcie_enable_msi(struct nwl_pcie *pcie, struct > >>>>>>> +pci_bus > >>>>>>> +*bus) { > >>>>>>> + struct platform_device *pdev = to_platform_device(pcie- > >>>> dev); > >>>>>>> + struct nwl_msi *msi = &pcie->msi; > >>>>>>> + unsigned long base; > >>>>>>> + int ret; > >>>>>>> + > >>>>>>> + mutex_init(&msi->lock); > >>>>>>> + > >>>>>>> + /* Check for msii_present bit */ > >>>>>>> + ret = nwl_bridge_readl(pcie, I_MSII_CAPABILITIES) & > >>> MSII_PRESENT; > >>>>>>> + if (!ret) { > >>>>>>> + dev_err(pcie->dev, "MSI not present\n"); > >>>>>>> + ret = -EIO; > >>>>>>> + goto err; > >>>>>>> + } > >>>>>>> + > >>>>>>> + /* Enable MSII */ > >>>>>>> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, > >>> I_MSII_CONTROL) | > >>>>>>> + MSII_ENABLE, I_MSII_CONTROL); > >>>>>>> + > >>>>>>> + /* Enable MSII status */ > >>>>>>> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, > >>> I_MSII_CONTROL) | > >>>>>>> + MSII_STATUS_ENABLE, I_MSII_CONTROL); > >>>>>>> + > >>>>>>> + /* setup AFI/FPCI range */ > >>>>>>> + msi->pages = __get_free_pages(GFP_KERNEL, 0); > >>>>>>> + base = virt_to_phys((void *)msi->pages); > >>>>>>> + nwl_bridge_writel(pcie, lower_32_bits(base), > >>> I_MSII_BASE_LO); > >>>>>>> + nwl_bridge_writel(pcie, upper_32_bits(base), > >>> I_MSII_BASE_HI); > >>>>>> > >>>>>> BTW, you still haven't answered my question as to why you need to > >>>>>> waste a page of memory here, and why putting a device address > >>>>>> doesn't > >>>>> work. > >>>>>> > >>>>>> As this is (to the best of my knowledge) the only driver doing > >>>>>> so, I'd really like you to explain the rational behind this. > >>>>> > >>>>> Might not be the only driver doing so after I start sending out > >>>>> patches for the iProc MSI support (soon), :) > >>>>> > >>>>> I'm not sure how it works for the Xilinx NWL controller, which > >>>>> Bharat should be able to help to explain. But for the iProc MSI > >>>>> controller, there's no device I/O memory reserved for MSI posted > >>>>> writes > >>> in the ASIC. > >>>>> Therefore one needs to reserve host memory for these writes. > >>>>>> > >>>> > >>>> Our SoC doesn't reserve any memory for MSI, hence we need to assign > >>>> a memory space for it out of RAM. > >>> > >>> Question to both of you: Does the write make it to memory? Or is it > >>> sampled by the bridge and dropped? > >>> > >> No, write will not do any modification in memory, it is consumed by > bridge. > > > > Then you do not need to allocate memory at all. Use whatever memory > > you already have. CC-ing Robin, as this may have interaction with the > SMMU. > > > >> Ok, I will try with some random address, without allocating any memory and test it, and will update accordingly in next patch. > >>> What happens if you replace the page in RAM with a dummy address? > >> What do you mean by dummy address ? > > > > Any random (and suitably aligned) address. 0x00000deadbeef000 for > example. > > In our case, I'm pretty sure the writes make it to memory (RAM). I can try > replacing it with a dummy address, but I'm pretty sure that will not work. > Thanks, Bharat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/