Thread (15 messages) 15 messages, 5 authors, 2020-09-12

Re: [PATCH 1/3] ARM/dma-mapping: move various helpers from dma-mapping.h to dma-direct.h

From: Christoph Hellwig <hch@lst.de>
Date: 2020-09-11 06:25:19
Also in: linux-acpi, linux-arm-kernel, linux-iommu, linux-pci, linux-sh, linux-usb, lkml

On Thu, Sep 10, 2020 at 07:02:23PM +0100, Robin Murphy wrote:
On 2020-09-10 06:40, Christoph Hellwig wrote:
quoted
Move the helpers to translate to and from direct mapping DMA addresses
to dma-direct.h.  This not only is the most logical place, but the new
placement also avoids dependency loops with pending commits.
For the straightforward move as it should be,

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

However I do wonder how much of this could be cleaned up further...
quoted
+
+#ifdef __arch_page_to_dma
+#error Please update to __arch_pfn_to_dma
+#endif
This must be long, long dead by now.
Yeah.  I had a patch to remove this which lead me into the rabbit
hole your described later.  A few patches in I decided to give up
and just do the trivial move.  But it probably makes sense to pick
up at least the two trivial dead code removal patches..
quoted
+static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
+{
+	unsigned long pfn = __bus_to_pfn(addr);
+
+	if (dev)
+		pfn += dev->dma_pfn_offset;
+
+	return pfn;
+}
These are only overridden for OMAP1510, and it looks like it wouldn't take 
much for the platform code or ohci-omap driver to set up a generic DMA 
offset for the relevant device.
I sent a ping to the omap maintainers earlier this week to ask for that :)
quoted
+static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
+{
+	if (dev)
+		return pfn_to_dma(dev, virt_to_pfn(addr));
+
+	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
+}
And this is only used for some debug prints in dmabounce.

Similarly the __bus_to_*()/__*_to_bus() calls themselves only appear 
significant to mach-footbridge any more, and could probably also be evolved 
into regular DMA offsets now that all API calls must have a non-NULL 
device. I think I might come back and take a closer look at all this at 
some point in future... :)
Yes,  pretty much all of this should eventually go away.  I just don't
want to bock the ranges work on all kinds of random arm cleanups..
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help