From patchwork Thu Mar 30 09:59:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oza Pawandeep X-Patchwork-Id: 9653521 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 87EFB6034C for ; Thu, 30 Mar 2017 10:04:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 73D842858A for ; Thu, 30 Mar 2017 10:04:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6870B28583; Thu, 30 Mar 2017 10:04:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E4B0028581 for ; Thu, 30 Mar 2017 10:04:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933243AbdC3KAR (ORCPT ); Thu, 30 Mar 2017 06:00:17 -0400 Received: from mail-wr0-f170.google.com ([209.85.128.170]:36156 "EHLO mail-wr0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933240AbdC3KAO (ORCPT ); Thu, 30 Mar 2017 06:00:14 -0400 Received: by mail-wr0-f170.google.com with SMTP id w11so51814596wrc.3 for ; Thu, 30 Mar 2017 03:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=2QwocwBDUZm6NlkRo1c/u97L7qBDqUm4XRWS6sxoWRU=; b=F+aXExOO7AXFA+waiDew65cXZtr8XEkIeWRsnQA1PTNFDUmfYFvD1hBKl3H/T6BhIc fzE7XrlqdegXnuEFgyyZxyXYfOyAEgGcFiYKHIHSDFvMPk054ttePEYKICwkcVCoMcIT uJr9lhxk+aSKGwJHi+in9614T7f7gb4/CV420= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=2QwocwBDUZm6NlkRo1c/u97L7qBDqUm4XRWS6sxoWRU=; b=GUhexWXc7lYg6Wb12U0nmSjFFVgu3hdzHjRyvP5dYf0Jh7ECIPzTvelfMu1QzdHswM EjHQWqY54gW3TnCKljbI4oPpiS1/7hIY8B7QGWhI2344WMRDq6XiAYs+XVpp/3BrDpVv n9Rms04KAqlw3ezUt759tnkDbuHPu23jeiJ2hl7Zk9G6GFNgP8a9DpuJ2DzrsLqptD9+ culxjL5pUgFiNut8A8mpQtD5/x39agMmZ9xb6gGqN6PbujFc+fVMUAnJGG4t5xJ4OMl/ nYyhYARqEitCwGlSwJHyjtFO/okYaCYJJf7IC3qUYwJzT+w7Kc8VW88RjMFtZHhiWcGH +rUQ== X-Gm-Message-State: AFeK/H1yGOkqjWmuvHHryFv28PAcpeEtXmdwubfxf+4f8qypd8yVX9dl8Phvb1tOtWqzdpk8 X-Received: by 10.28.107.13 with SMTP id g13mr2611792wmc.117.1490868011908; Thu, 30 Mar 2017 03:00:11 -0700 (PDT) Received: from anjanavk-OptiPlex-7010.dhcp.avagotech.net ([192.19.237.250]) by smtp.gmail.com with ESMTPSA id k43sm2123802wrk.42.2017.03.30.03.00.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Mar 2017 03:00:11 -0700 (PDT) From: Oza Pawandeep To: Joerg Roedel , Robin Murphy Cc: iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, Oza Pawandeep , Oza Pawandeep Subject: [RFC PATCH 2/2] of/pci: call pci specific dma-ranges instead of memory-mapped. Date: Thu, 30 Mar 2017 15:29:46 +0530 Message-Id: <1490867986-5675-2-git-send-email-oza.oza@broadcom.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1490867986-5675-1-git-send-email-oza.oza@broadcom.com> References: <1490867986-5675-1-git-send-email-oza.oza@broadcom.com> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP it is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. As an example, consider NVME SSD device connected to iproc-PCIe controller. Currently, the IOMMU DMA ops only considers PCI device dma_mask when allocating an IOVA. This is particularly problematic on ARM/ARM64 SOCs where the IOMMU (i.e. SMMU) translates IOVA to PA for in-bound transactions only after PCI Host has forwarded these transactions on SOC IO bus. This means on such ARM/ARM64 SOCs the IOVA of in-bound transactions has to honor the addressing restrictions of the PCI Host. this patch calls pci specific of_pci_dma_get_ranges, instead of calling memory-mapped one, which returns wrong size and also not meant for PCI world. with this, it gets accurate resources back, and largest possible inbound window size. with that largest possible dma_mask can be generated. Signed-off-by: Oza Pawandeep diff --git a/drivers/of/device.c b/drivers/of/device.c index b1e6beb..d6a8dde 100644 --- a/drivers/of/device.c +++ b/drivers/of/device.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include "of_private.h" @@ -89,6 +90,8 @@ void of_dma_configure(struct device *dev, struct device_node *np) bool coherent; unsigned long offset; const struct iommu_ops *iommu; + struct resource_entry *window; + LIST_HEAD(res); /* * Set default coherent_dma_mask to 32 bit. Drivers are expected to @@ -104,7 +107,24 @@ void of_dma_configure(struct device *dev, struct device_node *np) if (!dev->dma_mask) dev->dma_mask = &dev->coherent_dma_mask; - ret = of_dma_get_range(np, &dma_addr, &paddr, &size); + if (dev_is_pci(dev)) { + size = 0; + ret = of_pci_get_dma_ranges(np, &res); + if (!ret) { + resource_list_for_each_entry(window, &res) { + struct resource *res_dma = window->res; + if (size < resource_size(res_dma)) { + dma_addr = res_dma->start - window->offset; + paddr = res_dma->start; + size = resource_size(res_dma); + } + } + } + pci_free_resource_list(&res); + } + else + ret = of_dma_get_range(np, &dma_addr, &paddr, &size); + if (ret < 0) { dma_addr = offset = 0; size = dev->coherent_dma_mask + 1;