From: Dave Stevenson <dave.stevenson@raspberrypi.com>
To: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Ray Jui <rjui@broadcom.com>,
Scott Branden <sbranden@broadcom.com>,
Vinod Koul <vkoul@kernel.org>, Maxime Ripard <mripard@kernel.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Ulf Hansson <ulf.hansson@linaro.org>,
Mark Brown <broonie@kernel.org>, Christoph Hellwig <hch@lst.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Vladimir Murzin <vladimir.murzin@arm.com>,
Phil Elwell <phil@raspberrypi.com>,
Stefan Wahren <wahrenst@gmx.net>,
Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: devicetree@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-mmc@vger.kernel.org,
linux-spi@vger.kernel.org, iommu@lists.linux.dev,
linux-sound@vger.kernel.org,
Dave Stevenson <dave.stevenson@raspberrypi.com>
Subject: [PATCH 12/18] dmaengine: bcm2835: Read ranges if dma-ranges aren't mapped
Date: Fri, 24 May 2024 19:26:56 +0100 [thread overview]
Message-ID: <20240524182702.1317935-13-dave.stevenson@raspberrypi.com> (raw)
In-Reply-To: <20240524182702.1317935-1-dave.stevenson@raspberrypi.com>
We have a historical error in the DT files that don't define
the dma-ranges fully, and DMA users have been passing in
DMA addresses instead of CPU physical addresses.
As DT is ABI, we have to be able to work with old DT but new
kernel, which means handling this missing dma-range mapping
somehow.
The "ranges" property has always been defined correctly, so
abuse that in the event that dma-ranges are missing.
There appears to be no easy route to access "ranges", so
duplicate the functions for handling "dma-ranges" here to
keep the hack contained.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
---
drivers/dma/bcm2835-dma.c | 139 ++++++++++++++++++++++++++++++++++++--
1 file changed, 134 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index e48008b06716..06407691ef28 100644
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -25,6 +25,7 @@
#include <linux/interrupt.h>
#include <linux/list.h>
#include <linux/module.h>
+#include <linux/of_address.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/io.h>
@@ -37,6 +38,12 @@
#define BCM2835_DMA_MAX_DMA_CHAN_SUPPORTED 14
#define BCM2835_DMA_CHAN_NAME_SIZE 8
+struct bcm2835_bus_dma_region {
+ phys_addr_t cpu_start;
+ dma_addr_t dma_start;
+ u64 size;
+};
+
/**
* struct bcm2835_dmadev - BCM2835 DMA controller
* @ddev: DMA device
@@ -48,6 +55,8 @@ struct bcm2835_dmadev {
struct dma_device ddev;
void __iomem *base;
dma_addr_t zero_page;
+ bool ranges_initialised;
+ struct bcm2835_bus_dma_region *ranges_map;
};
struct bcm2835_dma_cb {
@@ -71,6 +80,7 @@ struct bcm2835_dma_chan_map {
phys_addr_t slave_addr;
unsigned int xfer_size;
+ bool ranges;
};
struct bcm2835_chan {
@@ -279,6 +289,114 @@ static inline bool need_dst_incr(enum dma_transfer_direction direction)
return false;
};
+static int bcm2835_dma_init_ranges(struct dma_chan *chan)
+{
+ struct bcm2835_dmadev *od = to_bcm2835_dma_dev(chan->device);
+ struct device *dev = chan->device->dev;
+ struct device_node *node = of_node_get(dev->of_node);
+ const __be32 *ranges = NULL;
+ bool found_ranges = false;
+ struct of_range_parser parser;
+ struct of_range range;
+ struct bcm2835_bus_dma_region *r;
+ int len, num_ranges = 0;
+ int ret = 0;
+
+ while (node) {
+ ranges = of_get_property(node, "ranges", &len);
+
+ /* Ignore empty ranges, they imply no translation required */
+ if (ranges && len > 0)
+ break;
+
+ /* Once we find 'dma-ranges', then a missing one is an error */
+ if (found_ranges && !ranges) {
+ ret = -ENODEV;
+ goto out;
+ }
+ found_ranges = true;
+
+ node = of_get_next_parent(node);
+ }
+
+ if (!node || !ranges) {
+ pr_debug("no ranges found for node(%pOF)\n", dev->of_node);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ of_pci_range_parser_init(&parser, node);
+ for_each_of_range(&parser, &range) {
+ if (range.cpu_addr == OF_BAD_ADDR) {
+ pr_err("translation of DMA address(%llx) to CPU address failed node(%pOF)\n",
+ range.bus_addr, node);
+ continue;
+ }
+ num_ranges++;
+ }
+
+ if (!num_ranges) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
+ if (!r) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ /*
+ * Record all info in the generic DMA ranges array for struct device,
+ * returning an error if we don't find any parsable ranges.
+ */
+ od->ranges_map = r;
+ of_pci_range_parser_init(&parser, node);
+ for_each_of_range(&parser, &range) {
+ pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+ range.bus_addr, range.cpu_addr, range.size);
+ if (range.cpu_addr == OF_BAD_ADDR)
+ continue;
+ r->cpu_start = range.cpu_addr;
+ r->dma_start = range.bus_addr;
+ r->size = range.size;
+ r++;
+ }
+out:
+ of_node_put(node);
+ return ret;
+}
+
+static dma_addr_t bcm2835_translate_phys_to_dma(struct bcm2835_dmadev *od,
+ phys_addr_t paddr)
+{
+ const struct bcm2835_bus_dma_region *m;
+
+ for (m = od->ranges_map; m && m->size; m++) {
+ u64 offset = paddr - m->cpu_start;
+
+ if (paddr >= m->cpu_start && offset < m->size)
+ return m->dma_start + offset;
+ }
+
+ /* make sure dma_capable fails when no translation is available */
+ return DMA_MAPPING_ERROR;
+}
+
+static dma_addr_t
+bcm2835_dma_map_using_range(struct dma_chan *chan, phys_addr_t phys_addr,
+ size_t size, enum dma_data_direction dir)
+{
+ struct bcm2835_dmadev *od = to_bcm2835_dma_dev(chan->device);
+
+ if (!od->ranges_initialised) {
+ bcm2835_dma_init_ranges(chan);
+ od->ranges_initialised = true;
+ }
+
+ return bcm2835_translate_phys_to_dma(od, phys_addr);
+}
+
static int bcm2835_dma_map_slave_addr(struct dma_chan *chan,
phys_addr_t dev_addr,
size_t dev_size,
@@ -307,8 +425,11 @@ static int bcm2835_dma_map_slave_addr(struct dma_chan *chan,
dev_dir == map->dir)
return 0;
- /* Remove old mapping if present. */
- if (map->xfer_size) {
+ /*
+ * Remove old mapping if present and we haven't used our own "ranges"
+ * mapping (which has no unmap)
+ */
+ if (map->xfer_size && !map->ranges) {
dev_dbg(chan->device->dev, "chan: unmap %zx@%pap to %pad dir: %s\n",
dev_size, &dev_addr, &map->addr,
dev_dir == DMA_TO_DEVICE ? "DMA_TO_DEVICE" : "DMA_FROM_DEVICE");
@@ -322,9 +443,17 @@ static int bcm2835_dma_map_slave_addr(struct dma_chan *chan,
dev_dir, 0);
if (dma_mapping_error(chan->device->dev, map->addr)) {
- dev_err(chan->device->dev, "chan: failed to map %zx@%pap",
- dev_size, &dev_addr);
- return -EIO;
+ map->addr = bcm2835_dma_map_using_range(chan, dev_addr, dev_size,
+ dev_dir);
+ if (dma_mapping_error(chan->device->dev, map->addr)) {
+ dev_err(chan->device->dev, "chan: failed to map %zx@%pap",
+ dev_size, &dev_addr);
+
+ return -EIO;
+ }
+ map->ranges = true;
+ } else {
+ map->ranges = false;
}
dev_dbg(chan->device->dev, "chan: map %zx@%pap to %pad dir: %s\n",
--
2.34.1
next prev parent reply other threads:[~2024-05-24 18:28 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-24 18:26 [PATCH 00/18] BCM2835 DMA mapping cleanups and fixes Dave Stevenson
2024-05-24 18:26 ` [PATCH 01/18] dma-direct: take dma-ranges/offsets into account in resource mapping Dave Stevenson
2024-05-28 6:33 ` Christoph Hellwig
2024-06-25 16:21 ` Dave Stevenson
2024-05-24 18:26 ` [PATCH 02/18] dmaengine: bcm2835: Support common dma-channel-mask Dave Stevenson
2024-06-05 15:52 ` Frank Li
2024-05-24 18:26 ` [PATCH 03/18] ARM: dts: bcm283x: Update to use dma-channel-mask Dave Stevenson
2024-06-05 12:22 ` Florian Fainelli
2024-05-24 18:26 ` [PATCH 04/18] dmaengine: bcm2835: move CB info generation into separate function Dave Stevenson
2024-06-05 16:05 ` Frank Li
2024-05-24 18:26 ` [PATCH 05/18] dmaengine: bcm2835: move CB final extra info generation into function Dave Stevenson
2024-06-05 16:18 ` Frank Li
2024-05-24 18:26 ` [PATCH 06/18] dmaengine: bcm2835: make address increment platform independent Dave Stevenson
2024-06-05 17:52 ` Frank Li
2024-06-24 17:47 ` Dave Stevenson
2024-05-24 18:26 ` [PATCH 07/18] dmaengine: bcm2385: drop info parameters Dave Stevenson
2024-06-05 18:00 ` Frank Li
2024-05-24 18:26 ` [PATCH 08/18] dmaengine: bcm2835: pass dma_chan to generic functions Dave Stevenson
2024-06-05 18:05 ` Frank Li
2024-06-24 18:10 ` Dave Stevenson
2024-05-24 18:26 ` [PATCH 09/18] dmaengine: bcm2835: Add function to handle DMA mapping Dave Stevenson
2024-06-05 18:13 ` Frank Li
2024-06-24 18:27 ` Dave Stevenson
2024-05-24 18:26 ` [PATCH 10/18] dmaengine: bcm2835: Add backwards compatible handling until clients updated Dave Stevenson
2024-05-24 18:26 ` [PATCH 11/18] dmaengine: bcm2835: Use dma_map_resource to map addresses Dave Stevenson
2024-06-05 18:22 ` Frank Li
2024-05-24 18:26 ` Dave Stevenson [this message]
2024-05-24 18:26 ` [PATCH 13/18] arm: dt: Add dma-ranges to the bcm283x platforms Dave Stevenson
2024-06-05 12:23 ` Florian Fainelli
2024-05-24 18:26 ` [PATCH 14/18] mmc: bcm2835: Use phys addresses for slave DMA config Dave Stevenson
2024-05-24 18:26 ` [PATCH 15/18] spi: " Dave Stevenson
2024-05-24 18:27 ` [PATCH 16/18] drm/vc4: " Dave Stevenson
2024-06-05 18:28 ` Frank Li
2024-05-24 18:27 ` [PATCH 17/18] ASoC: bcm2835-i2s: Use phys addresses for DAI DMA Dave Stevenson
2024-05-24 18:27 ` [PATCH 18/18] dmaengine: bcm2835: Revert the workaround for DMA addresses Dave Stevenson
2024-06-05 12:24 ` [PATCH 00/18] BCM2835 DMA mapping cleanups and fixes Florian Fainelli
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=20240524182702.1317935-13-dave.stevenson@raspberrypi.com \
--to=dave.stevenson@raspberrypi.com \
--cc=Sergey.Semin@baikalelectronics.ru \
--cc=airlied@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=florian.fainelli@broadcom.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=krzk+dt@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=perex@perex.cz \
--cc=phil@raspberrypi.com \
--cc=rjui@broadcom.com \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=sbranden@broadcom.com \
--cc=tiwai@suse.com \
--cc=tzimmermann@suse.de \
--cc=ulf.hansson@linaro.org \
--cc=vkoul@kernel.org \
--cc=vladimir.murzin@arm.com \
--cc=wahrenst@gmx.net \
/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).