Re: [PATCH RESEND v5 22/24] dmaengine: dw-edma: Bypass dma-ranges mapping for the local setup

[Robin Murphy <robin.murphy@arm.com>]

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.