| Message ID | 20240524182702.1317935-2-dave.stevenson@raspberrypi.com |
|---|---|
| State | New |
| Headers | show |
| Series | BCM2835 DMA mapping cleanups and fixes | expand |
Hi Christoph Sorry for the delay in coming back to you. On Tue, 28 May 2024 at 07:33, Christoph Hellwig <hch@lst.de> wrote: > > On Fri, May 24, 2024 at 07:26:45PM +0100, Dave Stevenson wrote: > > From: Serge Semin <Sergey.Semin@baikalelectronics.ru> > > > > 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. > > My memory is getting a little bad, but as dma_direct_map_resource is > mostly used for (non-PCIe) peer to peer transfers, any kind of mapping > from the host address should be excluded. Could you elaborate on mapping from the host address being excluded? On BCM283x DMA address != CPU physical address, so some mapping has to occur. Robin Murphy directed us at dma_map_resource() in [1], and referenced this patch as necessary because dma_map_resource() didn't currently use dma-ranges mappings. Mark Brown also hadn't corrected/objected to the statement that dma_map_resource() was the correct call when I was querying how to tackle this historic mismatch in [2]. I'll happily defer to the experts on DMA (I would never classify myself as such), but I'm not clear on the direction you want here. [1] https://lore.kernel.org/lkml/ee19a95d-fe1e-4f3f-bc81-bdef38475469@arm.com/ [2] https://lore.kernel.org/linux-arm-kernel/CAPY8ntBua=wPVUj+SM0WGcUL0fT56uEHo8YZUTMB8Z54X_aPRw@mail.gmail.com/T/ > (dma_direct_map_resource in general is a horrible interface and I'd > prefer everyone to switch to the map_sg based P2P support, but we > have plenty of users for it unfortunately) Is that applicable for mapping device addresses with DMA_DEV_TO_MEM or DMA_MEM_TO_DEV transfers? Example use case on BCM283x is HDMI audio where the HDMI driver should be passing in the CPU physical address of the audio FIFO, and that needs to be mapped to the DMA address for the DMA controller. How do I get a sglist for the peripheral address? As noted in the cover letter for this series, if this isn't the approved mechanism, then please let me know what is. Many thanks Dave
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 4d543b1e9d57..916a16959575 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -509,7 +509,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,