From: Niklas Cassel <cassel@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Vinod Koul" <vkoul@kernel.org>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Jingoo Han" <jingoohan1@gmail.com>,
"Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
linux-pci@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, mhi@lists.linux.dev,
linux-tegra@vger.kernel.org,
"Damien Le Moal" <dlemoal@kernel.org>,
"Frank Li" <Frank.Li@nxp.com>
Subject: Re: [PATCH 05/11] PCI: epf-{mhi/test}: Move DMA initialization to EPC init callback
Date: Mon, 22 Apr 2024 11:30:09 +0200 [thread overview]
Message-ID: <ZiYuIaX7ZV0exKMt@ryzen> (raw)
In-Reply-To: <20240422075521.GB9775@thinkpad>
On Mon, Apr 22, 2024 at 01:25:21PM +0530, Manivannan Sadhasivam wrote:
> >
> > What I would like is more consistency between the EPF drivers.
> >
> > I guess an if-statement that skips the pci_epc_map_addr() in pci-epf-test
> > if using eDMA would make pci-epf-mhi and pci-epf-test most consistent.
> >
>
> Agree.
> > 1) Do we want to rely on the fact that hopefully none of the iATUs in the DWC
> > controller has configured a mapping that might mess things up for us?
> > I don't see why the PCI/DMA address of the remote buffer, supplied to
> > pci-epf-test via test_reg BAR, might not fall within the physical iATU window
> > on the local EP system. (As long as the PCI EPF driver has mapped any address
> > using pci_epc_map_addr().)
> >
> > This is a big argument that EPF drivers running on a DWC-based EPC should
> > definitely NOT call pci_epc_map_addr() needlessly when using eDMA, as it
> > can be catastrophic. (pci-epf-test needs to be patched.)
> >
>
> Right. There is no need to do iATU translation for DMA. I avoid that in MHI
> driver.
There is no need for pci_epc_map_addr() when using DMA_SLAVE *for DWC-based
controllers*.
Are we certain that this will not break pci-epf-test for non DWC-based
controllers?
> > 2) Can we really assume that both pci-epf-test and pci-epf-mhi does not need
> > to call pci_epc_map_addr() when using a DMA_SLAVE DMA controller?
> > This seems to be designed only with DWC in mind. Other PCIe endpoint
> > controllers might require this.
> > (Yes, for DWC-based controllers, this definitely should be skipped, but EPF
> > drivers are supposed to be independent from a specific EPC.)
> >
>
> For TEST yes, but for MHI, no. In MHI, I kind of mix both iATU and DMA to ripe
> most of the performance (small vs big transactions). But for the TEST driver, it
> is fair to not call pci_epc_map_addr() when DMA_SLAVE is supported.
I agree that we should definitely skip pci_epc_map_addr() in pci-epf-test when
using DMA_SLAVE on DWC-based controllers, but I don't feel comfortable in
submitting a patch that does this unconditionally for pci-epf-test.c,
as I don't know how the DMA hardware in:
drivers/pci/controller/cadence/pcie-cadence-ep.c
drivers/pci/controller/pcie-rcar-ep.c
drivers/pci/controller/pcie-rockchip-ep.c
works, and I do not want to regress them.
I did suggest that DWC-based drivers could set a DMA_SLAVE_SKIP_MEM_MAP flag
or similar when registering the eDMA, which pci-epf-test then could check,
but I got no response if anoyone else thought that this was a good idea.
Kind regards,
Niklas
next prev parent reply other threads:[~2024-04-22 9:30 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 15:23 [PATCH 00/11] PCI: endpoint: Make host reboot handling more robust Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 01/11] PCI: qcom-ep: Disable resources unconditionally during PERST# assert Manivannan Sadhasivam
2024-03-22 16:08 ` Niklas Cassel
2024-03-26 7:44 ` Manivannan Sadhasivam
2024-03-26 10:24 ` Niklas Cassel
2024-03-26 11:10 ` Manivannan Sadhasivam
2024-03-26 13:47 ` Niklas Cassel
2024-03-26 13:55 ` Manivannan Sadhasivam
2024-03-26 10:37 ` Niklas Cassel
2024-03-14 15:23 ` [PATCH 02/11] PCI: endpoint: Decouple EPC and PCIe bus specific events Manivannan Sadhasivam
2024-03-22 16:08 ` Niklas Cassel
2024-03-26 7:49 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 03/11] PCI: endpoint: Rename core_init() callback in 'struct pci_epc_event_ops' to init() Manivannan Sadhasivam
2024-03-22 16:08 ` Niklas Cassel
2024-03-26 7:56 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 04/11] PCI: epf-test: Refactor pci_epf_test_unbind() function Manivannan Sadhasivam
2024-03-22 16:09 ` Niklas Cassel
2024-03-26 7:58 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 05/11] PCI: epf-{mhi/test}: Move DMA initialization to EPC init callback Manivannan Sadhasivam
2024-03-22 16:10 ` Niklas Cassel
2024-03-26 8:26 ` Manivannan Sadhasivam
2024-03-26 11:05 ` Niklas Cassel
2024-03-26 14:27 ` Niklas Cassel
2024-03-27 6:20 ` Manivannan Sadhasivam
2024-03-27 6:18 ` Manivannan Sadhasivam
2024-03-27 11:39 ` Niklas Cassel
2024-03-28 18:42 ` Vinod Koul
2024-04-04 8:44 ` Niklas Cassel
2024-04-22 7:55 ` Manivannan Sadhasivam
2024-04-22 9:30 ` Niklas Cassel [this message]
2024-03-14 15:23 ` [PATCH 06/11] PCI: endpoint: Introduce EPC 'deinit' event and notify the EPF drivers Manivannan Sadhasivam
2024-03-22 16:10 ` Niklas Cassel
2024-03-26 8:31 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 07/11] PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown() API to handle Link Down event Manivannan Sadhasivam
2024-03-22 16:10 ` Niklas Cassel
2024-03-27 18:06 ` Niklas Cassel
2024-04-01 16:34 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 08/11] PCI: qcom-ep: Use the " Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 09/11] PCI: epf-test: Handle " Manivannan Sadhasivam
2024-03-22 16:10 ` Niklas Cassel
2024-03-14 15:23 ` [PATCH 10/11] PCI: qcom-ep: Rework {start/stop}_link() callbacks implementation Manivannan Sadhasivam
2024-03-22 16:10 ` Niklas Cassel
2024-03-26 8:33 ` Manivannan Sadhasivam
2024-03-14 15:23 ` [PATCH 11/11] PCI: tegra194: " Manivannan Sadhasivam
2024-03-22 16:11 ` Niklas Cassel
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=ZiYuIaX7ZV0exKMt@ryzen \
--to=cassel@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=bhelgaas@google.com \
--cc=dlemoal@kernel.org \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=kishon@kernel.org \
--cc=kw@linux.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mhi@lists.linux.dev \
--cc=robh@kernel.org \
--cc=thierry.reding@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.