On Wed, Aug 31, 2022 at 10:17:30AM +0100, Robin Murphy wrote:
On 2022-08-22 19:53, Serge Semin wrote:
DW eDMA doesn't perform any translation of the traffic generated on the
CPU/Application side. It just generates read/write AXI-bus requests with
the specified addresses. But in case if the dma-ranges DT-property is
specified for a platform device node, Linux will use it to map the CPU
memory regions into the DMAable bus ranges. This isn't what we want for
the eDMA embedded into the locally accessed DW PCIe Root Port and
End-point. In order to work that around let's set the chan_dma_dev flag
for each DW eDMA channel thus forcing the client drivers to getting a
custom dma-ranges-less parental device for the mappings.
Note it will only work for the client drivers using the
dmaengine_get_dma_device() method to get the parental DMA device.
No, this is nonsense. If the DMA engine is on the host side of the bridge
then it should not have anything to do with the PCI device at all, it should
be associated with the platform device,
Well. The DMA-engine is embedded into the PCIe Root Port bus, is associated
with the platform device it's embedded to, and it doesn't have
anything to do with any particular PCI device.
and thus any range mapping on the bridge itself would be irrelevant anyway.
Really? I find it otherwise. Please see the way the "dma-ranges"
property is parsed and works during the device-specific memory ranges
mapping when it's applicable for the PCIe Root Ports.