Re: [PATCH 03/25] dma-direct: take dma-ranges/offsets into account in resource mapping

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022-03-24 01:48, Serge Semin wrote:
A basic device-specific linear memory mapping was introduced back in
commit ("dma: Take into account dma_pfn_offset") as a single-valued offset
preserved in the device.dma_pfn_offset field, which was initialized for
instance by means of the "dma-ranges" DT property. Afterwards the
functionality was extended to support more than one device-specific region
defined in the device.dma_range_map list of maps. But all of these
improvements concerned a single pointer, page or sg DMA-mapping methods,
while the system resource mapping function turned to miss the
corresponding modification. Thus the dma_direct_map_resource() method now
just casts the CPU physical address to the device DMA address with no
dma-ranges-based mapping taking into account, which is obviously wrong.
Let's fix it by using the phys_to_dma_direct() method to get the
device-specific bus address from the passed memory resource for the case
of the directly mapped DMA.

It may not have been well-documented at the time, but this was largely intentional. The assumption based on known systems was that where dma_pfn_offset existed, it would *not* apply to peer MMIO addresses.

For instance, DTs for TI Keystone 2 platforms only describe an offset for RAM:

	dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;

but a DMA controller might also want to access something in the MMIO range 0x0-0x7fffffff, of which it still has an identical non-offset view. If a driver was previously using dma_map_resource() for that, it would now start getting DMA_MAPPING_ERROR because the dma_range_map exists but doesn't describe the MMIO region. I agree that in hindsight it's not an ideal situation, but it's how things have ended up, so at this point I'm wary of making potentially-breaking changes.

May I ask what exactly your setup looks like, if you have a DMA controller with an offset view of its "own" MMIO space?

Thanks,
Robin.

Fixes: 25f1e1887088 ("dma: Take into account dma_pfn_offset")
Signed-off-by: Serge Semin <Sergey.Semin@xxxxxxxxxxxxxxxxxxxx>
---
  kernel/dma/direct.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 50f48e9e4598..9ce8192b29ab 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -497,7 +497,7 @@ int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
  dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
  		size_t size, enum dma_data_direction dir, unsigned long attrs)
  {
-	dma_addr_t dma_addr = paddr;
+	dma_addr_t dma_addr = phys_to_dma_direct(dev, paddr);
if (unlikely(!dma_capable(dev, dma_addr, size, false))) {
  		dev_err_once(dev,



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux