From: Serge Semin <fancer.lancer@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: "Serge Semin" <Sergey.Semin@baikalelectronics.ru>,
"Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
"Vinod Koul" <vkoul@kernel.org>, "Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Jingoo Han" <jingoohan1@gmail.com>,
"Frank Li" <Frank.Li@nxp.com>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
"Alexey Malahov" <Alexey.Malahov@baikalelectronics.ru>,
"Pavel Parkhomenko" <Pavel.Parkhomenko@baikalelectronics.ru>,
"Krzysztof Wilczyński" <kw@linux.com>,
linux-pci@vger.kernel.org, dmaengine@vger.kernel.org,
linux-kernel@vger.kernel.org,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>
Subject: Re: [PATCH RESEND v5 22/24] dmaengine: dw-edma: Bypass dma-ranges mapping for the local setup
Date: Tue, 27 Sep 2022 13:48:31 +0300 [thread overview]
Message-ID: <20220927104831.bovlzl74osb4t5d3@mobilestation> (raw)
In-Reply-To: <5569ad73-9699-e326-c1fb-e0753bbdde78@arm.com>
On Mon, Sep 26, 2022 at 03:08:01PM +0100, Robin Murphy wrote:
> 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.
Finally we are on the same page.) I didn't thought it was a bug
though. Some details of the problem I described in another thread
earlier today:
Link: https://lore.kernel.org/linux-pci/20220926205333.qlhb5ojmx4sktzt5@mobilestation/
(See my note regarding the "dma-ranges" usage, which I accidentally
addressed to William instead of you.)
>
> 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.
You are right. The PCI-specific dma-ranges semantic hasn't been well
thought through in the first place. The child devices should have had
a dedicated method to set their own way of the memory ranges mapping.
Just a thought. As a possible solution for the dma-ranges property
being dedicated for the child devices we could introduce a new "space
code" of the dma-ranges property with a flag which would indicate the
actual bridge/host-controller memory range. If the dma-ranges property
doesn't have an entry with such code the mapping could be considered
as direct (in accordance with the parental dma-ranges properties).
IOMMU-part is applicable for all PCIe-related hierarchy - bridge itself
and peripheral devices.
>
> 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).
Do you mean something like this?
< struct dma_chan *dchan = ...;
< struct dw_edma_chan *chan = ...;
< struct device *parent = chan->dw->chip->dev;
<
< if (dev_of_node(parent)) {
< struct device_node *node = dev_of_node(parent);
<
< ret = of_dma_configure(&chan->dev->device, node, true);
< } else if (has_acpi_companion(parent)) {
< struct acpi_device *adev = to_acpi_device_node(parent->fwnode);
<
< ret = acpi_dma_configure(&chan->dev->device, acpi_get_dma_attr(adev));
< } else {
< ret = -EINVAL;
< }
<
< if (ret)
< return ret;
<
< /* Drop the detected dma-ranges mapping since it isn't applicable for
< * the PCIe RP/EP bridge itself but to the peripheral devices only.
< */
< dchan->dev->device.dma_range_map = NULL;
< dchan->dev->chan_dma_dev = true;
<
< return 0;
What about the DMA-mask? Will it be ok if I copy it from the parental device?
Like this:
< dma_coerce_mask_and_coherent(&dchan->dev->device, dma_get_mask(parent));
Judging by the of_dma_configure_id() method implementation the mask
upper bound is calculated based on the dma-ranges entries. Since the
DT-property isn't applicable for the PCIe host platform device itself
then it' upper bound most like will be invalid for the bridge too.
Regards,
-Sergey
>
> Thanks,
> Robin.
next prev parent reply other threads:[~2022-09-27 10:48 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-22 18:53 [PATCH RESEND v5 00/24] dmaengine: dw-edma: Add RP/EP local DMA controllers support Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 01/24] dmaengine: Fix dma_slave_config.dst_addr description Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 02/24] dmaengine: dw-edma: Release requested IRQs on failure Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 03/24] dmaengine: dw-edma: Convert ll/dt phys-address to PCIe bus/DMA address Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 04/24] dmaengine: dw-edma: Fix missing src/dst address of the interleaved xfers Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 05/24] dmaengine: dw-edma: Don't permit non-inc " Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 06/24] dmaengine: dw-edma: Fix invalid interleaved xfers semantics Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 07/24] dmaengine: dw-edma: Add CPU to PCIe bus address translation Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 08/24] dmaengine: dw-edma: Add PCIe bus address getter to the remote EP glue-driver Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 09/24] dmaengine: dw-edma: Drop chancnt initialization Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 10/24] dmaengine: dw-edma: Fix DebugFS reg entry type Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 11/24] dmaengine: dw-edma: Stop checking debugfs_create_*() return value Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 12/24] dmaengine: dw-edma: Add dw_edma prefix to the DebugFS nodes descriptor Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 13/24] dmaengine: dw-edma: Convert DebugFS descs to being kz-allocated Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 14/24] dmaengine: dw-edma: Rename DebugFS dentry variables to 'dent' Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 15/24] dmaengine: dw-edma: Simplify the DebugFS context CSRs init procedure Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 16/24] dmaengine: dw-edma: Move eDMA data pointer to DebugFS node descriptor Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 17/24] dmaengine: dw-edma: Join Write/Read channels into a single device Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 18/24] dmaengine: dw-edma: Use DMA-engine device DebugFS subdirectory Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 19/24] dmaengine: dw-edma: Use non-atomic io-64 methods Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 20/24] dmaengine: dw-edma: Drop DT-region allocation Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 21/24] dmaengine: dw-edma: Replace chip ID number with device name Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 22/24] dmaengine: dw-edma: Bypass dma-ranges mapping for the local setup Serge Semin
2022-08-31 9:17 ` Robin Murphy
2022-09-12 1:24 ` Serge Semin
2022-09-26 14:08 ` Robin Murphy
2022-09-27 10:48 ` Serge Semin [this message]
2022-08-22 18:53 ` [PATCH RESEND v5 23/24] dmaengine: dw-edma: Skip cleanup procedure if no private data found Serge Semin
2022-08-22 18:53 ` [PATCH RESEND v5 24/24] PCI: dwc: Add DW eDMA engine support Serge Semin
2022-08-23 15:49 ` Manivannan Sadhasivam
2022-08-24 14:22 ` Serge Semin
2022-08-24 16:51 ` Bjorn Helgaas
2022-08-24 18:13 ` Serge Semin
2022-08-24 18:17 ` Bjorn Helgaas
2022-08-25 5:16 ` Serge Semin
2022-08-25 16:04 ` Bjorn Helgaas
2022-08-25 17:06 ` Serge Semin
2022-08-23 15:45 ` [PATCH RESEND v5 00/24] dmaengine: dw-edma: Add RP/EP local DMA controllers support Manivannan Sadhasivam
2022-08-24 14:07 ` Serge Semin
2022-08-25 4:42 ` Vinod Koul
2022-08-25 5:04 ` Serge Semin
2022-08-25 8:44 ` Vinod Koul
2022-08-25 11:28 ` Serge Semin
2022-08-24 16:39 ` Bjorn Helgaas
2022-08-24 18:00 ` Serge Semin
2022-10-25 7:59 ` Manivannan Sadhasivam
2022-10-25 20:50 ` Serge Semin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220927104831.bovlzl74osb4t5d3@mobilestation \
--to=fancer.lancer@gmail.com \
--cc=Alexey.Malahov@baikalelectronics.ru \
--cc=Frank.Li@nxp.com \
--cc=Pavel.Parkhomenko@baikalelectronics.ru \
--cc=Sergey.Semin@baikalelectronics.ru \
--cc=bhelgaas@google.com \
--cc=dmaengine@vger.kernel.org \
--cc=gustavo.pimentel@synopsys.com \
--cc=iommu@lists.linux.dev \
--cc=jingoohan1@gmail.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=manivannan.sadhasivam@linaro.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).