linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oza Pawandeep <oza.oza@broadcom.com>
To: Joerg Roedel <joro@8bytes.org>, Robin Murphy <robin.murphy@arm.com>
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@gmail.com>,
	Oza Pawandeep <oza.oza@broadcom.com>
Subject: [PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges
Date: Wed,  3 May 2017 10:16:35 +0530	[thread overview]
Message-ID: <1493786795-28153-3-git-send-email-oza.oza@broadcom.com> (raw)
In-Reply-To: <1493786795-28153-1-git-send-email-oza.oza@broadcom.com>

current device framework and of framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).

of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.

for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;

this patch fixes this patch fixes the bug in of_dma_get_range,
which with as is, parses the PCI memory ranges and return wrong
size as 0.

in order to get largest possible dma_mask. this patch also
retuns the largest possible size based on dma-ranges,

for e.g.
dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7fffffffff.

based on which iova allocation space will honour PCI host
bridge limitations.

Bug: SOC-5216
Change-Id: I4c534bdd17e70c6b27327d39d1656e8ed0cf56d6
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
Reviewed-on: http://gerrit-ccxsw.broadcom.net/40762
Reviewed-by: vpx_checkpatch status <vpx_checkpatch@broadcom.com>
Reviewed-by: CCXSW <ccxswbuild@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Tested-by: vpx_autobuild status <vpx_autobuild@broadcom.com>
Tested-by: vpx_smoketest status <vpx_smoketest@broadcom.com>

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..f7734fc 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -6,6 +6,7 @@
 #include <linux/ioport.h>
 #include <linux/module.h>
 #include <linux/of_address.h>
+#include <linux/of_pci.h>
 #include <linux/pci.h>
 #include <linux/pci_regs.h>
 #include <linux/sizes.h>
@@ -830,6 +831,54 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
 	int ret = 0;
 	u64 dmaaddr;
 
+#ifdef CONFIG_PCI
+	struct resource_entry *window;
+	LIST_HEAD(res);
+
+	if (!node)
+		return -EINVAL;
+
+	if (of_bus_pci_match(np)) {
+		*size = 0;
+		/*
+		 * PCI dma-ranges is not mandatory property.
+		 * many devices do no need to have it, since
+		 * host bridge does not require inbound memory
+		 * configuration or rather have design limitations.
+		 * so we look for dma-ranges, if missing we
+		 * just return the caller full size, and also
+		 * no dma-ranges suggests that, host bridge allows
+		 * whatever comes in, so we set dma_addr to 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);
+
+		/* ignore the empty ranges. */
+		if (*size == 0) {
+			pr_debug("empty/zero size dma-ranges found for node(%s)\n",
+				np->full_name);
+			*size = DMA_BIT_MASK(sizeof(dma_addr_t) * 8);
+			*dma_addr = *paddr = 0;
+			ret = 0;
+		}
+
+		pr_err("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+			 *dma_addr, *paddr, *size);
+		goto out;
+	}
+#endif
+
 	if (!node)
 		return -EINVAL;
 
-- 
1.9.1

  parent reply	other threads:[~2017-05-03  4:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-03  4:46 [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters Oza Pawandeep
2017-05-03  4:46 ` [PATCH 2/3] iommu/pci: reserve iova " Oza Pawandeep
2017-05-03  5:07   ` Oza Oza
2017-05-04 18:20   ` Robin Murphy
2017-05-04 18:52     ` Oza Oza
2017-05-05 15:51       ` Robin Murphy
2017-05-06  6:01         ` Oza Oza
2017-05-22 16:45         ` Oza Oza
2017-05-05  8:10     ` Oza Oza
2017-05-03  4:46 ` Oza Pawandeep [this message]
2017-05-03  5:07   ` [PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges Oza Oza
2017-05-03 20:06   ` Rob Herring
2017-05-03  5:06 ` [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters Oza Oza
2017-05-03 19:55 ` Rob Herring
2017-05-04 18:02 ` Robin Murphy
2017-05-04 18:41   ` Oza Oza
2017-05-05 15:25     ` Robin Murphy
2017-05-06  5:30       ` Oza Oza
2017-05-16  5:24         ` Oza Oza
2017-05-04 19:12   ` Oza Oza

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1493786795-28153-3-git-send-email-oza.oza@broadcom.com \
    --to=oza.oza@broadcom.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=devicetree@vger.kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=oza.pawandeep@gmail.com \
    --cc=robin.murphy@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).