On 10/14/19 2:54 PM, Robin Murphy wrote: > On 13/10/2019 15:28, Daniele Alessandrelli wrote: >> Hi, >> >> It looks like dma_alloc_coherent() is setting the dma_handle output >> parameter to the memory physical address and not the device bus >> address when the device is using reserved memory regions for DMA >> allocation. This is despite using 'dma_ranges' in the device tree to >> describe the DMA memory mapping. Is this expected behavior or a bug? > > That does sound like a bug :( > >> Here is a reduced version of the device tree I'm using: >> \ { >> reserved-memory { >> #address-cells = <2>; >> #size-cells = <2>; >> ranges; >> mydev_rsvd: rsvd_mem@494800000 { >> compatible = "shared-dma-pool"; >> reg = <0x4 0x94800000 0x0 0x200000>; >> no-map; >> }; >> }; >> soc { >> compatible = "simple-bus"; >> #address-cells = <2>; >> #size-cells = <2>; >> ranges; >> dma_ranges; >> >> mybus { >> ranges = <>; >> dma-ranges = <>; >> compatible = "simple-bus"; >> #address-cells = <2>; >> #size-cells = <2>; >> ranges = <0x0 0x0 0x0 0x0 0x0 0x80000000>; >> dma-ranges = <0x0 0x80000000 0x4 0x80000000 >> 0x0 0x80000000>; >> >> mydevice { >> compatible = "my-compatible-string"; >> memory-region = <&mydev_rsvd>; >> } >> } >> } >> }; >> >> It looks like this issue was previously fixed by commit c41f9ea998f3 >> ("drivers: dma-coherent: Account dma_pfn_offset when used with device >> tree") which introduced a new function ('dma_get_device_base()') to >> return the reserved memory address as seen by the device. However, >> such a function, even if still there, is not used anymore in latest >> code (as of v5.4-rc2). Was that done for a specific reason? Or is it >> just a mistake? > > Hmm, it looks like 43fc509c3efb ("dma-coherent: introduce interface for > default DMA pool") removed the caller of dma_get_device_base() in the alloc > path shortly after it was introduced, which certainly appears as if it may > have been unintentional - Vladimir?
I do not remember it was intentional. Looking at history, default DMA pool was a response to another report. However, now I'm wondering why it was not caught by STM32 - most of that work was required to support "dma-ranges" with NOMMU+caches (Cortex-M7). Alex (or anybody else from ST), maybe you have some input? Cheers Vladimir > > Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu