Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp621525imu; Thu, 13 Dec 2018 01:19:18 -0800 (PST) X-Google-Smtp-Source: AFSGD/X5Nct4qnBNBZ3+GmoHrgej+fS2qA1Seg+bSwksbIdGjrYUALjHBAC/cJ3o4jxmuhLvUEP5 X-Received: by 2002:a63:2744:: with SMTP id n65mr21048379pgn.65.1544692758903; Thu, 13 Dec 2018 01:19:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544692758; cv=none; d=google.com; s=arc-20160816; b=pAB1elwzr4ZSejj3O/QfoGrO2yfQK72QZREizMoUkRregb7x0P+kRuFlQ/4WuaEAI5 tPr4O2wpxKx81qJFZzuy8FVZumdhbcbRyhF00rC0/sdiy/6AT3Hse0JNNatNuPArzngP ymzdOX+vI7NBAQZhSZ4VUpTIeTi31bFMu4wmJABAax27VmMu/zi+hwERQ0vpzXGxzpTg cg/mEtgsbdGiQwruhZcmHYNOEu7o4GId/CYm3+vpULiaP3Q/gwzhUbfU7GVieTWZWaUN /d/rvi1O7FVPjbPK0kedloZi5TWGscvCuZbpA48hOcQzc+jdhy6RlS45VT0u5L8zpEQL 4CMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=J9y68ZP9FLvJD7+DsuEi7azlVGsBu+pdfu6qn1+HeM8=; b=UPQ9A9HNNipGTKu6xVhFIW6iFcB0yeQs3wYUFatSw44qLtSmz4KQDHXPkD3yZ/tsPp /rhYcgEhdsesKymfuOswlpHzDwsZcqQ0VSmfKrSGWSFhs8PI07kiyv8IwHN3S4MTl2zx r+rpyjAeaB4zK3EbAhTVg5z/ZgTLOOjwwp6zVATpPoiLacC1M2ID0tfQEYWf8ZHS9LF0 nE8Nb/rPjZ25wt1M1OPiJNpf9TZ8L3+19eKrAzF/nkDs4ocTzloeV9O11kK4KjXwZZOj X+2mb3Qgwvp7lMzqS/wOXLNlAS1L/jji9n0WzkmhoPZXxVQb+jRmhJA2ZSGHplQQ7pcf isKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b="ZaGtW9/t"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u2si1139555pgo.544.2018.12.13.01.19.03; Thu, 13 Dec 2018 01:19:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b="ZaGtW9/t"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727890AbeLMJRY (ORCPT + 99 others); Thu, 13 Dec 2018 04:17:24 -0500 Received: from mail-wr1-f66.google.com ([209.85.221.66]:35559 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726578AbeLMJRW (ORCPT ); Thu, 13 Dec 2018 04:17:22 -0500 Received: by mail-wr1-f66.google.com with SMTP id 96so1197624wrb.2 for ; Thu, 13 Dec 2018 01:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J9y68ZP9FLvJD7+DsuEi7azlVGsBu+pdfu6qn1+HeM8=; b=ZaGtW9/thiv3BbI5MrrBEaMkZveH+ALmjKCYEvVg+GkXcpGhLnWRJCcatQQEQuE50w ujjHrOS9to2hoHxxBjHSWMS7nKtLxbrdmSc2di7QRvmmsN3lC1SGU0Rqv+HcUCjWPkQ9 OEsKnbj8ku1tZ3TQqtTiI3jH33UlwVX6zu3qk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J9y68ZP9FLvJD7+DsuEi7azlVGsBu+pdfu6qn1+HeM8=; b=POkgJVF0WsnAGA63KZRdz6eclhJqSL91kxKw09XyfylPjywqy+avIq+sSqINjYPeKF JLJY0h/q+lDqzyJccxNvYBzeSlL3KgRvUYvWB6HCRSz7Pfnr0yw2LwCN9ikh0skpKXBP uJKo1DCRAdM2j+eTf9juWuCAYOd847Aibd/S13h+MwGIS/wz4MQyqmqkTGuxR1zxK/xS 866FrKdZsV6JqM5wOVVUUl0ShN+jXDfarT3+Vj1px16UvbfD1lYZM2mQthxC9dqMP16X Uni2ClqEKO3S39kTAP4x/Oinoe7698msyRFjxfvZKckNaJN8viBOctS8C14lv0iEXlVi FBRQ== X-Gm-Message-State: AA+aEWaO46VuYLnS9Ubg4X5Oj0ybAO2soG/GaMIkGXSsrJgw5b+TQy8q QqNP73v8QTf1e9MAsSe1N4DZYu6f4FaWb3G9G3yx7Q== X-Received: by 2002:adf:f052:: with SMTP id t18mr21522120wro.112.1544692640217; Thu, 13 Dec 2018 01:17:20 -0800 (PST) MIME-Version: 1.0 References: <1544593569-8923-1-git-send-email-srinath.mannam@broadcom.com> <1544593569-8923-4-git-send-email-srinath.mannam@broadcom.com> <117bb87c4567d14f189642b685dd8813@codeaurora.org> In-Reply-To: <117bb87c4567d14f189642b685dd8813@codeaurora.org> From: Srinath Mannam Date: Thu, 13 Dec 2018 14:47:08 +0530 Message-ID: Subject: Re: [RFC PATCH 3/3] PCI: iproc: Add dma reserve resources to host To: poza@codeaurora.org Cc: Bjorn Helgaas , Robin Murphy , Joerg Roedel , Lorenzo Pieralisi , Ray Jui , BCM Kernel Feedback , linux-pci@vger.kernel.org, iommu@lists.linux-foundation.org, Linux Kernel Mailing List , linux-pci-owner@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Oza, Thank you for the review. Please find my comments in lined. On Thu, Dec 13, 2018 at 11:33 AM wrote: > > On 2018-12-12 11:16, Srinath Mannam wrote: > > IPROC host has the limitation that it can use > > only those address ranges given by dma-ranges > > property as inbound address. > > So that the memory address holes in dma-ranges > > should be reserved to allocate as DMA address. > > > > All such reserved addresses are created as resource > > entries and add to dma_resv list of pci host bridge. > > > > These dma reserve resources created by parsing > > dma-ranges parameter. > > > > Ex: > > dma-ranges = < \ > > 0x43000000 0x00 0x80000000 0x00 0x80000000 0x00 0x80000000 \ > > 0x43000000 0x08 0x00000000 0x08 0x00000000 0x08 0x00000000 \ > > 0x43000000 0x80 0x00000000 0x80 0x00000000 0x40 0x00000000> > > > > In the above example of dma-ranges, memory address from > > 0x0 - 0x80000000, > > 0x100000000 - 0x800000000, > > 0x1000000000 - 0x8000000000 and > > 0x10000000000 - 0xffffffffffffffff. > > are not allowed to use as inbound addresses. > > So that we need to add these address range to dma_resv > > list to reserve their IOVA address ranges. > > > > Signed-off-by: Srinath Mannam > > --- > > drivers/pci/controller/pcie-iproc.c | 49 > > +++++++++++++++++++++++++++++++++++++ > > 1 file changed, 49 insertions(+) > > > > diff --git a/drivers/pci/controller/pcie-iproc.c > > b/drivers/pci/controller/pcie-iproc.c > > index 3160e93..43e465a 100644 > > --- a/drivers/pci/controller/pcie-iproc.c > > +++ b/drivers/pci/controller/pcie-iproc.c > > @@ -1154,25 +1154,74 @@ static int iproc_pcie_setup_ib(struct > > iproc_pcie *pcie, > > return ret; > > } > > > > +static int > > +iproc_pcie_add_dma_resv_range(struct device *dev, struct list_head > > *resources, > > + uint64_t start, uint64_t end) > > +{ > > + struct resource *res; > > + > > + res = devm_kzalloc(dev, sizeof(struct resource), GFP_KERNEL); > > + if (!res) > > + return -ENOMEM; > > + > > + res->start = (resource_size_t)start; > > + res->end = (resource_size_t)end; > > + pci_add_resource_offset(resources, res, 0); > > + > > + return 0; > > +} > > + > > static int iproc_pcie_map_dma_ranges(struct iproc_pcie *pcie) > > { > > + struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie); > > struct of_pci_range range; > > struct of_pci_range_parser parser; > > int ret; > > + uint64_t start, end; > > + LIST_HEAD(resources); > > > > /* Get the dma-ranges from DT */ > > ret = of_pci_dma_range_parser_init(&parser, pcie->dev->of_node); > > if (ret) > > return ret; > > > > + start = 0; > > for_each_of_pci_range(&parser, &range) { > > + end = range.pci_addr; > > + /* dma-ranges list expected in sorted order */ > > + if (end < start) { > > + ret = -EINVAL; > > + goto out; > > + } > > /* Each range entry corresponds to an inbound mapping region */ > > ret = iproc_pcie_setup_ib(pcie, &range, IPROC_PCIE_IB_MAP_MEM); > > if (ret) > > return ret; > > + > > + if (end - start) { > > + ret = iproc_pcie_add_dma_resv_range(pcie->dev, > > + &resources, > > + start, end); > > + if (ret) > > + goto out; > > + } > > + start = range.pci_addr + range.size; > > } > > > > + end = ~0; > Hi Srinath, > > this series is based on following patch sets. > > https://lkml.org/lkml/2017/5/16/19 > https://lkml.org/lkml/2017/5/16/23 > https://lkml.org/lkml/2017/5/16/21, > Yes, this patch series is done based on the inputs of the patches you sent earlier. > some comments to be adapted from the patch-set I did. > > end = ~0; > you should consider DMA_MASK, to see iproc controller is in 32 bit or 64 > bit system. > please check following code snippet. > > if (tmp_dma_addr < DMA_BIT_MASK(sizeof(dma_addr_t) * 8)) { > + lo = iova_pfn(iovad, tmp_dma_addr); > + hi = iova_pfn(iovad, > + DMA_BIT_MASK(sizeof(dma_addr_t) * 8) - 1); > + reserve_iova(iovad, lo, hi); > + } > > Also if this controller is integrated to 64bit platform, but decide to > restrict DMA to 32 bit for some reason, the code should address such > scenarios. > so it is always safe to do > > #define BITS_PER_BYTE 8 > DMA_BIT_MASK(sizeof(dma_addr_t) * BITS_PER_BYTE) > so please use kernle macro to find the end of DMA region. > this change done with the assumption, that end_address is max bus address(~0) instead pcie RC dma mask. Even dma-ranges has 64bit size dma-mask of PCIe host is forced to 32bit. // in of_dma_configure function dev->coherent_dma_mask = DMA_BIT_MASK(32); And dma-mask of endpoint was set to 64bit in their drivers. also SMMU supported dma mask is 48-bit. But here requirement is all address ranges except dma-ranges address between 0x0 - ~0x0 have to be reserved. as you suggested I will change ~0 to DMA_BIT_MASK macro it will look more cleaner. > > Also ideally according to SBSA v5 > > 8.3 PCI Express device view of memory > > Transactions from a PCI express device will either directly address the > memory system of the base server system > or be presented to a SMMU for optional address translation and > permission policing. > In systems that are compatible with level 3 or above of the SBSA, the > addresses sent by PCI express devices > must be presented to the memory system or SMMU unmodified. In a system > where the PCI express does not use > an SMMU, the PCI express devices have the same view of physical memory > as the PEs. In a system with a > SMMU for PCI express there are no transformations to addresses being > sent by PCI express devices before they > are presented as an input address to the SMMU. > > which is a limitation of iproc controller, please list the limitation in > detail as it violates SBSA. Inbound address sent by pcie devices to the host will not be translate (unchanged) before it comes to SMMU or directly to PE. but the there is limitation that, few address ranges are not allowed by IPROC PCIe RC and those were filtered out. That is the reason forces this change request. I will append these details in commit message. Regards, Srinath. > > Regards, > Oza. > > > + if (end - start) { > > + ret = iproc_pcie_add_dma_resv_range(pcie->dev, &resources, > > + start, end); > > + if (ret) > > + goto out; > > + } > > + > > + list_splice_init(&resources, &host->dma_resv); > > + > > return 0; > > +out: > > + pci_free_resource_list(&resources); > > + return ret; > > } > > > > static int iproce_pcie_get_msi(struct iproc_pcie *pcie, > > > > >