On 2022-09-12 02:24, Serge Semin wrote:
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.
Sigh, that's a bug. Now I see where the confusion is coming from.
Annoyingly it's basically the exact thing I called out in 951d48855d86
when making dma-ranges work for non-OF PCI devices in the first place,
but apparently neither I nor anyone else thought of this particular edge
case at the time. Sorry about that. I'll have a look at how best to fix it.
Everything else still stands, though. If you can't use the original
platform device for DMA API calls, at least configure the child device
properly by calling of_dma_configure() with the parent's DT node in the
expected manner (and manually remove its dma_range_map if you need an
immediate workaround).
Thanks,
Robin.
