Hi All,
The current PCIe EPF framework supports DMA data transfers using external
DMA only, this patch series aims to add support for platforms supporting
internal DMAC on PCIe for data transfers.
R-Car PCIe supports internal DMAC to transfer data between Internal Bus to
PCI Express and vice versa. Last patch fills up the required flags and ops
to support internal DMAC.
Patches 1-3 are for PCIe EPF core to support internal DMAC handling, patch
4/5 is to fix test cases based on the conversation [1].
Patches are based on top of [1] next branch.
[0] https://www.spinics.net/lists/linux-pci/msg92385.html
[1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
Cheers,
Prabhakar
Lad Prabhakar (5):
PCI: endpoint: Add ops and flag to support internal DMAC
PCI: endpoint: Add support to data transfer using internal dmac
misc: pci_endpoint_test: Add driver data for Renesas RZ/G2{EHMN}
misc: pci_endpoint_test: Add support to pass flags for buffer
allocation
PCI: rcar-ep: Add support for DMAC
drivers/misc/pci_endpoint_test.c | 56 ++++-
drivers/pci/controller/pcie-rcar-ep.c | 227 ++++++++++++++++++
drivers/pci/controller/pcie-rcar.h | 23 ++
drivers/pci/endpoint/functions/pci-epf-test.c | 184 ++++++++++----
drivers/pci/endpoint/pci-epf-core.c | 32 +++
include/linux/pci-epc.h | 8 +
include/linux/pci-epf.h | 7 +
7 files changed, 483 insertions(+), 54 deletions(-)
--
2.25.1
Add flag to indicate if PCIe EP supports internal DMAC and also add a
wrapper function which invokes dmac_transfer() callback which lands
in the PCIe EP driver.
Signed-off-by: Lad Prabhakar <[email protected]>
---
drivers/pci/endpoint/pci-epf-core.c | 32 +++++++++++++++++++++++++++++
include/linux/pci-epc.h | 8 ++++++++
include/linux/pci-epf.h | 7 +++++++
3 files changed, 47 insertions(+)
diff --git a/drivers/pci/endpoint/pci-epf-core.c b/drivers/pci/endpoint/pci-epf-core.c
index 9ed556936f48..f70576d0d4b2 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -239,6 +239,38 @@ void pci_epf_remove_vepf(struct pci_epf *epf_pf, struct pci_epf *epf_vf)
}
EXPORT_SYMBOL_GPL(pci_epf_remove_vepf);
+/**
+ * pci_epf_internal_dmac_xfr() - transfer data between EPC and remote PCIe RC
+ * @epf: the EPF device that performs the data transfer operation
+ * @dma_dst: The destination address of the data transfer. It can be a physical
+ * address given by pci_epc_mem_alloc_addr or DMA mapping APIs.
+ * @dma_src: The source address of the data transfer. It can be a physical
+ * address given by pci_epc_mem_alloc_addr or DMA mapping APIs.
+ * @len: The size of the data transfer
+ *
+ * Invoke to transfer data between EPC and remote PCIe RC using internal dmac.
+ */
+int pci_epf_internal_dmac_xfr(struct pci_epf *epf, dma_addr_t dma_dst,
+ dma_addr_t dma_src, size_t len,
+ enum pci_epf_xfr_direction dir)
+{
+ struct pci_epc *epc = epf->epc;
+ int ret;
+
+ if (IS_ERR_OR_NULL(epc) || IS_ERR_OR_NULL(epf))
+ return -EINVAL;
+
+ if (!epc->ops->dmac_transfer)
+ return -EINVAL;
+
+ mutex_lock(&epf->lock);
+ ret = epc->ops->dmac_transfer(epc, epf, dma_dst, dma_src, len, dir);
+ mutex_unlock(&epf->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_epf_internal_dmac_xfr);
+
/**
* pci_epf_free_space() - free the allocated PCI EPF register space
* @epf: the EPF device from whom to free the memory
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index a48778e1a4ee..b55dacd09e1e 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -58,6 +58,7 @@ pci_epc_interface_string(enum pci_epc_interface_type type)
* @map_msi_irq: ops to map physical address to MSI address and return MSI data
* @start: ops to start the PCI link
* @stop: ops to stop the PCI link
+ * @dmac_transfer: ops to transfer data using internal DMAC
* @get_features: ops to get the features supported by the EPC
* @owner: the module owner containing the ops
*/
@@ -86,6 +87,9 @@ struct pci_epc_ops {
u32 *msi_addr_offset);
int (*start)(struct pci_epc *epc);
void (*stop)(struct pci_epc *epc);
+ int (*dmac_transfer)(struct pci_epc *epc, struct pci_epf *epf,
+ dma_addr_t dma_dst, dma_addr_t dma_src,
+ size_t len, enum pci_epf_xfr_direction dir);
const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
u8 func_no, u8 vfunc_no);
struct module *owner;
@@ -159,6 +163,8 @@ struct pci_epc {
* for initialization
* @msi_capable: indicate if the endpoint function has MSI capability
* @msix_capable: indicate if the endpoint function has MSI-X capability
+ * @internal_dmac: indicate if the endpoint function has internal DMAC
+ * @internal_dmac_mask: indicates the DMA mask to be applied for the device
* @reserved_bar: bitmap to indicate reserved BAR unavailable to function driver
* @bar_fixed_64bit: bitmap to indicate fixed 64bit BARs
* @bar_fixed_size: Array specifying the size supported by each BAR
@@ -169,6 +175,8 @@ struct pci_epc_features {
unsigned int core_init_notifier : 1;
unsigned int msi_capable : 1;
unsigned int msix_capable : 1;
+ unsigned int internal_dmac : 1;
+ u64 internal_dmac_mask;
u8 reserved_bar;
u8 bar_fixed_64bit;
u64 bar_fixed_size[PCI_STD_NUM_BARS];
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index 009a07147c61..78d661db085d 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -32,6 +32,11 @@ enum pci_barno {
BAR_5,
};
+enum pci_epf_xfr_direction {
+ PCIE_TO_INTERNAL,
+ INTERNAL_TO_PCIE,
+};
+
/**
* struct pci_epf_header - represents standard configuration header
* @vendorid: identifies device manufacturer
@@ -209,6 +214,8 @@ void pci_epf_free_space(struct pci_epf *epf, void *addr, enum pci_barno bar,
enum pci_epc_interface_type type);
int pci_epf_bind(struct pci_epf *epf);
void pci_epf_unbind(struct pci_epf *epf);
+int pci_epf_internal_dmac_xfr(struct pci_epf *epf, dma_addr_t dma_dst, dma_addr_t dma_src,
+ size_t len, enum pci_epf_xfr_direction dir);
struct config_group *pci_epf_type_add_cfs(struct pci_epf *epf,
struct config_group *group);
int pci_epf_add_vepf(struct pci_epf *epf_pf, struct pci_epf *epf_vf);
--
2.25.1
By default GFP_KERNEL flag is used for buffer allocation in read, write
and copy test and then later mapped using streaming DMA api. But on
Renesas RZ/G2{EHMN} platforms using the default flag causes the tests to
fail. Allocating the buffers from DMA zone (using the GFP_DMA flag) make
the test cases to pass.
To handle such case add flags as part of struct pci_endpoint_test_data
so that platforms can pass the required flags based on the requirement.
Signed-off-by: Lad Prabhakar <[email protected]>
---
Hi All,
This patch is based on the conversation where switching to streaming
DMA api causes read/write/copy tests to fail on Renesas RZ/G2 platforms
when buffers are allocated using GFP_KERNEL.
[0] https://www.spinics.net/lists/linux-pci/msg92385.html
Cheers,
Prabhakar
---
drivers/misc/pci_endpoint_test.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 0a00d45830e9..974546992c5e 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -117,6 +117,7 @@ struct pci_endpoint_test {
enum pci_barno test_reg_bar;
size_t alignment;
size_t dmac_data_alignment;
+ gfp_t flags;
const char *name;
};
@@ -125,6 +126,7 @@ struct pci_endpoint_test_data {
size_t alignment;
int irq_type;
size_t dmac_data_alignment;
+ gfp_t flags;
};
static inline u32 pci_endpoint_test_readl(struct pci_endpoint_test *test,
@@ -381,7 +383,7 @@ static bool pci_endpoint_test_copy(struct pci_endpoint_test *test,
goto err;
}
- orig_src_addr = kzalloc(size + alignment, GFP_KERNEL);
+ orig_src_addr = kzalloc(size + alignment, test->flags);
if (!orig_src_addr) {
dev_err(dev, "Failed to allocate source buffer\n");
ret = false;
@@ -414,7 +416,7 @@ static bool pci_endpoint_test_copy(struct pci_endpoint_test *test,
src_crc32 = crc32_le(~0, src_addr, size);
- orig_dst_addr = kzalloc(size + alignment, GFP_KERNEL);
+ orig_dst_addr = kzalloc(size + alignment, test->flags);
if (!orig_dst_addr) {
dev_err(dev, "Failed to allocate destination address\n");
ret = false;
@@ -518,7 +520,7 @@ static bool pci_endpoint_test_write(struct pci_endpoint_test *test,
goto err;
}
- orig_addr = kzalloc(size + alignment, GFP_KERNEL);
+ orig_addr = kzalloc(size + alignment, test->flags);
if (!orig_addr) {
dev_err(dev, "Failed to allocate address\n");
ret = false;
@@ -619,7 +621,7 @@ static bool pci_endpoint_test_read(struct pci_endpoint_test *test,
goto err;
}
- orig_addr = kzalloc(size + alignment, GFP_KERNEL);
+ orig_addr = kzalloc(size + alignment, test->flags);
if (!orig_addr) {
dev_err(dev, "Failed to allocate destination address\n");
ret = false;
@@ -788,6 +790,7 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
test->alignment = 0;
test->pdev = pdev;
test->irq_type = IRQ_TYPE_UNDEFINED;
+ test->flags = GFP_KERNEL;
if (no_msi)
irq_type = IRQ_TYPE_LEGACY;
@@ -799,6 +802,7 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
test->alignment = data->alignment;
irq_type = data->irq_type;
test->dmac_data_alignment = data->dmac_data_alignment;
+ test->flags = data->flags;
}
init_completion(&test->irq_raised);
@@ -947,23 +951,27 @@ static const struct pci_endpoint_test_data default_data = {
.test_reg_bar = BAR_0,
.alignment = SZ_4K,
.irq_type = IRQ_TYPE_MSI,
+ .flags = GFP_KERNEL,
};
static const struct pci_endpoint_test_data am654_data = {
.test_reg_bar = BAR_2,
.alignment = SZ_64K,
.irq_type = IRQ_TYPE_MSI,
+ .flags = GFP_KERNEL,
};
static const struct pci_endpoint_test_data j721e_data = {
.alignment = 256,
.irq_type = IRQ_TYPE_MSI,
+ .flags = GFP_KERNEL,
};
static const struct pci_endpoint_test_data renesas_rzg2x_data = {
.test_reg_bar = BAR_0,
.irq_type = IRQ_TYPE_MSI,
.dmac_data_alignment = 8,
+ .flags = GFP_KERNEL | GFP_DMA,
};
static const struct pci_device_id pci_endpoint_test_tbl[] = {
--
2.25.1
Hi Prabhakar,
> [0] https://urldefense.com/v3/__https://www.spinics.net/lists/linux-
> pci/msg92385.html__;!!PeEy7nZLVv0!yP0WqYs165riCjWRhZprjgMVVLfQLtkkPfv_
> R7XCoqkqgMsOyor90EZp0YAdxu0$
Can your streaming DMA test case(-d) pass if you use EP's internal DMAC instead of external DMAC?
Regards,
Li
**********************************************************************
This email and attachments contain Ambarella Proprietary and/or Confidential Information and is intended solely for the use of the individual(s) to whom it is addressed. Any unauthorized review, use, disclosure, distribute, copy, or print is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. Thank you.
Hi Chen-san,
On Wed, Feb 9, 2022 at 4:48 AM Li Chen <[email protected]> wrote:
>
> Hi Prabhakar,
>
> > [0] https://urldefense.com/v3/__https://www.spinics.net/lists/linux-
> > pci/msg92385.html__;!!PeEy7nZLVv0!yP0WqYs165riCjWRhZprjgMVVLfQLtkkPfv_
> > R7XCoqkqgMsOyor90EZp0YAdxu0$
>
> Can your streaming DMA test case(-d) pass if you use EP's internal DMAC instead of external DMAC?
>
Sorry I don't quite get you here.
This patch series adds support for EP to transfer using internal DMAC
as no external DMAC is supported, so when "-d" option is passed and if
EP has registered it has internal dmac it will use the same and run
the pcitest.
Cheers,
Prabhakar
> Regards,
> Li
>
> **********************************************************************
> This email and attachments contain Ambarella Proprietary and/or Confidential Information and is intended solely for the use of the individual(s) to whom it is addressed. Any unauthorized review, use, disclosure, distribute, copy, or print is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. Thank you.
Hi Prabhakar,
> -----Original Message-----
> From: Lad, Prabhakar [mailto:[email protected]]
> Sent: Wednesday, February 9, 2022 4:53 PM
> To: Li Chen
> Cc: Lad Prabhakar; Kishon Vijay Abraham I; Bjorn Helgaas; Lorenzo Pieralisi;
> Krzysztof Wilczyński; Arnd Bergmann; Greg Kroah-Hartman; Marek Vasut;
> Yoshihiro Shimoda; Rob Herring; [email protected]; linux-renesas-
> [email protected]; [email protected]; Biju Das
> Subject: Re: [EXT] [RFC PATCH 0/5] PCIe EPF support for internal DMAC handling
> and driver update for R-Car PCIe EP to support DMAC
>
> Hi Chen-san,
>
> On Wed, Feb 9, 2022 at 4:48 AM Li Chen <[email protected]> wrote:
> >
> > Hi Prabhakar,
> >
> > > [0] https://urldefense.com/v3/__https://www.spinics.net/lists/linux-
> > >
> pci/msg92385.html__;!!PeEy7nZLVv0!yP0WqYs165riCjWRhZprjgMVVLfQLtkkPfv_
> > > R7XCoqkqgMsOyor90EZp0YAdxu0$
> >
> > Can your streaming DMA test case(-d) pass if you use EP's internal DMAC
> instead of external DMAC?
> >
> Sorry I don't quite get you here.
>
> This patch series adds support for EP to transfer using internal DMAC
> as no external DMAC is supported, so when "-d" option is passed and if
> EP has registered it has internal dmac it will use the same and run
> the pcitest.
Ok, in my case, read/write via external DMAC always get incorrect data, but read via internal DMAC is correct. Maybe this is our RTL's issue.
Regards,
Li
**********************************************************************
This email and attachments contain Ambarella Proprietary and/or Confidential Information and is intended solely for the use of the individual(s) to whom it is addressed. Any unauthorized review, use, disclosure, distribute, copy, or print is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. Thank you.
Hi,
On Wed, Jan 26, 2022 at 07:50:38PM +0000, Lad Prabhakar wrote:
> Hi All,
>
> The current PCIe EPF framework supports DMA data transfers using external
> DMA only, this patch series aims to add support for platforms supporting
> internal DMAC on PCIe for data transfers.
>
> R-Car PCIe supports internal DMAC to transfer data between Internal Bus to
> PCI Express and vice versa. Last patch fills up the required flags and ops
> to support internal DMAC.
>
> Patches 1-3 are for PCIe EPF core to support internal DMAC handling, patch
> 4/5 is to fix test cases based on the conversation [1].
>
This looks similar to the Synopsys eDMA IP [1] that goes with the Synopsys PCIe
endpoint IP. Why can't you represent it as a dmaengine driver and use the
existing DMA support?
Thanks,
Mani
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/dw-edma
> Patches are based on top of [1] next branch.
>
> [0] https://www.spinics.net/lists/linux-pci/msg92385.html
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
>
> Cheers,
> Prabhakar
>
> Lad Prabhakar (5):
> PCI: endpoint: Add ops and flag to support internal DMAC
> PCI: endpoint: Add support to data transfer using internal dmac
> misc: pci_endpoint_test: Add driver data for Renesas RZ/G2{EHMN}
> misc: pci_endpoint_test: Add support to pass flags for buffer
> allocation
> PCI: rcar-ep: Add support for DMAC
>
> drivers/misc/pci_endpoint_test.c | 56 ++++-
> drivers/pci/controller/pcie-rcar-ep.c | 227 ++++++++++++++++++
> drivers/pci/controller/pcie-rcar.h | 23 ++
> drivers/pci/endpoint/functions/pci-epf-test.c | 184 ++++++++++----
> drivers/pci/endpoint/pci-epf-core.c | 32 +++
> include/linux/pci-epc.h | 8 +
> include/linux/pci-epf.h | 7 +
> 7 files changed, 483 insertions(+), 54 deletions(-)
>
> --
> 2.25.1
>
On Thu, Feb 10, 2022 at 05:54:26AM +0000, Li Chen wrote:
> **********************************************************************
> This email and attachments contain Ambarella Proprietary and/or Confidential Information and is intended solely for the use of the individual(s) to whom it is addressed. Any unauthorized review, use, disclosure, distribute, copy, or print is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. Thank you.
This email footer is not compatible with Linux kernel development,
sorry. Please get your company to remove it so that you can continue to
participate.
On Thu, Feb 10, 2022 at 10:50 AM Manivannan Sadhasivam
<[email protected]> wrote:
>
> On Thu, Feb 10, 2022 at 09:24:19AM +0000, Lad, Prabhakar wrote:
> > Hi,
> >
> > On Thu, Feb 10, 2022 at 8:40 AM Manivannan Sadhasivam
> > <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Jan 26, 2022 at 07:50:38PM +0000, Lad Prabhakar wrote:
> > > > Hi All,
> > > >
> > > > The current PCIe EPF framework supports DMA data transfers using external
> > > > DMA only, this patch series aims to add support for platforms supporting
> > > > internal DMAC on PCIe for data transfers.
> > > >
> > > > R-Car PCIe supports internal DMAC to transfer data between Internal Bus to
> > > > PCI Express and vice versa. Last patch fills up the required flags and ops
> > > > to support internal DMAC.
> > > >
> > > > Patches 1-3 are for PCIe EPF core to support internal DMAC handling, patch
> > > > 4/5 is to fix test cases based on the conversation [1].
> > > >
> > >
> > > This looks similar to the Synopsys eDMA IP [1] that goes with the Synopsys PCIe
> > > endpoint IP. Why can't you represent it as a dmaengine driver and use the
> > > existing DMA support?
> > >
> > Let me have a look. Could you please share a link to the Synopsys PCIe
> > endpoint HW manual (the driver doesn't have a binding doc).
> >
>
> I don't think the PCIe reference manual is available publicly. And you are right
> that the driver is not tied to devicetree. The reason is, it gets probed using
> the PCI ID of the EP and all the resources are defined statically in the driver
> itself.
>
In R-Car PCIe the internal dmac is part of the PCIe block itself [0]
and not a separate block. I don't see any drivers implementing the
internal dmac drivers as a DMA engine driver. For example the Renesas
SDHI driver has internal dmac too, this is handled in the SDHI driver
itself [1] and not implemented as DMA engine driver. Let me know if my
understanding is wrong here.
[0] https://elixir.bootlin.com/linux/v5.17-rc3/source/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml#L76
[1] https://elixir.bootlin.com/linux/v5.17-rc3/source/drivers/mmc/host/renesas_sdhi_internal_dmac.c
Cheers,
Prabhakar
> Thanks,
> Mani
>
> > Cheers,
> > Prabhakar
> >
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/dw-edma
> > >
> > > > Patches are based on top of [1] next branch.
> > > >
> > > > [0] https://www.spinics.net/lists/linux-pci/msg92385.html
> > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
> > > >
> > > > Cheers,
> > > > Prabhakar
> > > >
> > > > Lad Prabhakar (5):
> > > > PCI: endpoint: Add ops and flag to support internal DMAC
> > > > PCI: endpoint: Add support to data transfer using internal dmac
> > > > misc: pci_endpoint_test: Add driver data for Renesas RZ/G2{EHMN}
> > > > misc: pci_endpoint_test: Add support to pass flags for buffer
> > > > allocation
> > > > PCI: rcar-ep: Add support for DMAC
> > > >
> > > > drivers/misc/pci_endpoint_test.c | 56 ++++-
> > > > drivers/pci/controller/pcie-rcar-ep.c | 227 ++++++++++++++++++
> > > > drivers/pci/controller/pcie-rcar.h | 23 ++
> > > > drivers/pci/endpoint/functions/pci-epf-test.c | 184 ++++++++++----
> > > > drivers/pci/endpoint/pci-epf-core.c | 32 +++
> > > > include/linux/pci-epc.h | 8 +
> > > > include/linux/pci-epf.h | 7 +
> > > > 7 files changed, 483 insertions(+), 54 deletions(-)
> > > >
> > > > --
> > > > 2.25.1
> > > >
On Thu, Feb 10, 2022 at 09:24:19AM +0000, Lad, Prabhakar wrote:
> Hi,
>
> On Thu, Feb 10, 2022 at 8:40 AM Manivannan Sadhasivam
> <[email protected]> wrote:
> >
> > Hi,
> >
> > On Wed, Jan 26, 2022 at 07:50:38PM +0000, Lad Prabhakar wrote:
> > > Hi All,
> > >
> > > The current PCIe EPF framework supports DMA data transfers using external
> > > DMA only, this patch series aims to add support for platforms supporting
> > > internal DMAC on PCIe for data transfers.
> > >
> > > R-Car PCIe supports internal DMAC to transfer data between Internal Bus to
> > > PCI Express and vice versa. Last patch fills up the required flags and ops
> > > to support internal DMAC.
> > >
> > > Patches 1-3 are for PCIe EPF core to support internal DMAC handling, patch
> > > 4/5 is to fix test cases based on the conversation [1].
> > >
> >
> > This looks similar to the Synopsys eDMA IP [1] that goes with the Synopsys PCIe
> > endpoint IP. Why can't you represent it as a dmaengine driver and use the
> > existing DMA support?
> >
> Let me have a look. Could you please share a link to the Synopsys PCIe
> endpoint HW manual (the driver doesn't have a binding doc).
>
I don't think the PCIe reference manual is available publicly. And you are right
that the driver is not tied to devicetree. The reason is, it gets probed using
the PCI ID of the EP and all the resources are defined statically in the driver
itself.
Thanks,
Mani
> Cheers,
> Prabhakar
>
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/dw-edma
> >
> > > Patches are based on top of [1] next branch.
> > >
> > > [0] https://www.spinics.net/lists/linux-pci/msg92385.html
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
> > >
> > > Cheers,
> > > Prabhakar
> > >
> > > Lad Prabhakar (5):
> > > PCI: endpoint: Add ops and flag to support internal DMAC
> > > PCI: endpoint: Add support to data transfer using internal dmac
> > > misc: pci_endpoint_test: Add driver data for Renesas RZ/G2{EHMN}
> > > misc: pci_endpoint_test: Add support to pass flags for buffer
> > > allocation
> > > PCI: rcar-ep: Add support for DMAC
> > >
> > > drivers/misc/pci_endpoint_test.c | 56 ++++-
> > > drivers/pci/controller/pcie-rcar-ep.c | 227 ++++++++++++++++++
> > > drivers/pci/controller/pcie-rcar.h | 23 ++
> > > drivers/pci/endpoint/functions/pci-epf-test.c | 184 ++++++++++----
> > > drivers/pci/endpoint/pci-epf-core.c | 32 +++
> > > include/linux/pci-epc.h | 8 +
> > > include/linux/pci-epf.h | 7 +
> > > 7 files changed, 483 insertions(+), 54 deletions(-)
> > >
> > > --
> > > 2.25.1
> > >
Hi,
On Thu, Feb 10, 2022 at 8:40 AM Manivannan Sadhasivam
<[email protected]> wrote:
>
> Hi,
>
> On Wed, Jan 26, 2022 at 07:50:38PM +0000, Lad Prabhakar wrote:
> > Hi All,
> >
> > The current PCIe EPF framework supports DMA data transfers using external
> > DMA only, this patch series aims to add support for platforms supporting
> > internal DMAC on PCIe for data transfers.
> >
> > R-Car PCIe supports internal DMAC to transfer data between Internal Bus to
> > PCI Express and vice versa. Last patch fills up the required flags and ops
> > to support internal DMAC.
> >
> > Patches 1-3 are for PCIe EPF core to support internal DMAC handling, patch
> > 4/5 is to fix test cases based on the conversation [1].
> >
>
> This looks similar to the Synopsys eDMA IP [1] that goes with the Synopsys PCIe
> endpoint IP. Why can't you represent it as a dmaengine driver and use the
> existing DMA support?
>
Let me have a look. Could you please share a link to the Synopsys PCIe
endpoint HW manual (the driver doesn't have a binding doc).
Cheers,
Prabhakar
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/dw-edma
>
> > Patches are based on top of [1] next branch.
> >
> > [0] https://www.spinics.net/lists/linux-pci/msg92385.html
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
> >
> > Cheers,
> > Prabhakar
> >
> > Lad Prabhakar (5):
> > PCI: endpoint: Add ops and flag to support internal DMAC
> > PCI: endpoint: Add support to data transfer using internal dmac
> > misc: pci_endpoint_test: Add driver data for Renesas RZ/G2{EHMN}
> > misc: pci_endpoint_test: Add support to pass flags for buffer
> > allocation
> > PCI: rcar-ep: Add support for DMAC
> >
> > drivers/misc/pci_endpoint_test.c | 56 ++++-
> > drivers/pci/controller/pcie-rcar-ep.c | 227 ++++++++++++++++++
> > drivers/pci/controller/pcie-rcar.h | 23 ++
> > drivers/pci/endpoint/functions/pci-epf-test.c | 184 ++++++++++----
> > drivers/pci/endpoint/pci-epf-core.c | 32 +++
> > include/linux/pci-epc.h | 8 +
> > include/linux/pci-epf.h | 7 +
> > 7 files changed, 483 insertions(+), 54 deletions(-)
> >
> > --
> > 2.25.1
> >
On Thu, Feb 10, 2022 at 11:05:45AM +0000, Lad, Prabhakar wrote:
> On Thu, Feb 10, 2022 at 10:50 AM Manivannan Sadhasivam
> <[email protected]> wrote:
> >
> > On Thu, Feb 10, 2022 at 09:24:19AM +0000, Lad, Prabhakar wrote:
> > > Hi,
> > >
> > > On Thu, Feb 10, 2022 at 8:40 AM Manivannan Sadhasivam
> > > <[email protected]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Wed, Jan 26, 2022 at 07:50:38PM +0000, Lad Prabhakar wrote:
> > > > > Hi All,
> > > > >
> > > > > The current PCIe EPF framework supports DMA data transfers using external
> > > > > DMA only, this patch series aims to add support for platforms supporting
> > > > > internal DMAC on PCIe for data transfers.
> > > > >
> > > > > R-Car PCIe supports internal DMAC to transfer data between Internal Bus to
> > > > > PCI Express and vice versa. Last patch fills up the required flags and ops
> > > > > to support internal DMAC.
> > > > >
> > > > > Patches 1-3 are for PCIe EPF core to support internal DMAC handling, patch
> > > > > 4/5 is to fix test cases based on the conversation [1].
> > > > >
> > > >
> > > > This looks similar to the Synopsys eDMA IP [1] that goes with the Synopsys PCIe
> > > > endpoint IP. Why can't you represent it as a dmaengine driver and use the
> > > > existing DMA support?
> > > >
> > > Let me have a look. Could you please share a link to the Synopsys PCIe
> > > endpoint HW manual (the driver doesn't have a binding doc).
> > >
> >
> > I don't think the PCIe reference manual is available publicly. And you are right
> > that the driver is not tied to devicetree. The reason is, it gets probed using
> > the PCI ID of the EP and all the resources are defined statically in the driver
> > itself.
> >
> In R-Car PCIe the internal dmac is part of the PCIe block itself [0]
> and not a separate block. I don't see any drivers implementing the
> internal dmac drivers as a DMA engine driver. For example the Renesas
> SDHI driver has internal dmac too, this is handled in the SDHI driver
> itself [1] and not implemented as DMA engine driver. Let me know if my
> understanding is wrong here.
>
Okay, thanks for the clarification. I thought that if the IP is same, we could
implement it as a standalone DMA engine driver, but looks like it is customized.
So I guess it is reasonable to have an internal implementation.
Thanks,
Mani
> [0] https://elixir.bootlin.com/linux/v5.17-rc3/source/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml#L76
> [1] https://elixir.bootlin.com/linux/v5.17-rc3/source/drivers/mmc/host/renesas_sdhi_internal_dmac.c
>
> Cheers,
> Prabhakar
>
> > Thanks,
> > Mani
> >
> > > Cheers,
> > > Prabhakar
> > >
> > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/dw-edma
> > > >
> > > > > Patches are based on top of [1] next branch.
> > > > >
> > > > > [0] https://www.spinics.net/lists/linux-pci/msg92385.html
> > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
> > > > >
> > > > > Cheers,
> > > > > Prabhakar
> > > > >
> > > > > Lad Prabhakar (5):
> > > > > PCI: endpoint: Add ops and flag to support internal DMAC
> > > > > PCI: endpoint: Add support to data transfer using internal dmac
> > > > > misc: pci_endpoint_test: Add driver data for Renesas RZ/G2{EHMN}
> > > > > misc: pci_endpoint_test: Add support to pass flags for buffer
> > > > > allocation
> > > > > PCI: rcar-ep: Add support for DMAC
> > > > >
> > > > > drivers/misc/pci_endpoint_test.c | 56 ++++-
> > > > > drivers/pci/controller/pcie-rcar-ep.c | 227 ++++++++++++++++++
> > > > > drivers/pci/controller/pcie-rcar.h | 23 ++
> > > > > drivers/pci/endpoint/functions/pci-epf-test.c | 184 ++++++++++----
> > > > > drivers/pci/endpoint/pci-epf-core.c | 32 +++
> > > > > include/linux/pci-epc.h | 8 +
> > > > > include/linux/pci-epf.h | 7 +
> > > > > 7 files changed, 483 insertions(+), 54 deletions(-)
> > > > >
> > > > > --
> > > > > 2.25.1
> > > > >
On Wed, Jan 26, 2022 at 07:50:39PM +0000, Lad Prabhakar wrote:
> Add flag to indicate if PCIe EP supports internal DMAC and also add a
> wrapper function which invokes dmac_transfer() callback which lands
> in the PCIe EP driver.
>
> Signed-off-by: Lad Prabhakar <[email protected]>
> ---
> drivers/pci/endpoint/pci-epf-core.c | 32 +++++++++++++++++++++++++++++
> include/linux/pci-epc.h | 8 ++++++++
> include/linux/pci-epf.h | 7 +++++++
> 3 files changed, 47 insertions(+)
>
> diff --git a/drivers/pci/endpoint/pci-epf-core.c b/drivers/pci/endpoint/pci-epf-core.c
> index 9ed556936f48..f70576d0d4b2 100644
> --- a/drivers/pci/endpoint/pci-epf-core.c
> +++ b/drivers/pci/endpoint/pci-epf-core.c
> @@ -239,6 +239,38 @@ void pci_epf_remove_vepf(struct pci_epf *epf_pf, struct pci_epf *epf_vf)
> }
> EXPORT_SYMBOL_GPL(pci_epf_remove_vepf);
>
> +/**
> + * pci_epf_internal_dmac_xfr() - transfer data between EPC and remote PCIe RC
Transfer data between EP and host using internal DMA engine
> + * @epf: the EPF device that performs the data transfer operation
> + * @dma_dst: The destination address of the data transfer. It can be a physical
> + * address given by pci_epc_mem_alloc_addr or DMA mapping APIs.
> + * @dma_src: The source address of the data transfer. It can be a physical
> + * address given by pci_epc_mem_alloc_addr or DMA mapping APIs.
> + * @len: The size of the data transfer
> + *
> + * Invoke to transfer data between EPC and remote PCIe RC using internal dmac.
> + */
> +int pci_epf_internal_dmac_xfr(struct pci_epf *epf, dma_addr_t dma_dst,
> + dma_addr_t dma_src, size_t len,
> + enum pci_epf_xfr_direction dir)
How about "pci_epf_internal_dma_xfer"? I think DMAC is somewhat platform
specific so we could just use DMA. And "xfer" is being used more commonly for
"transfer".
> +{
> + struct pci_epc *epc = epf->epc;
> + int ret;
> +
> + if (IS_ERR_OR_NULL(epc) || IS_ERR_OR_NULL(epf))
> + return -EINVAL;
> +
> + if (!epc->ops->dmac_transfer)
> + return -EINVAL;
> +
> + mutex_lock(&epf->lock);
> + ret = epc->ops->dmac_transfer(epc, epf, dma_dst, dma_src, len, dir);
internal_dma_xfer? It doesn't look perfect but I can't think of any other way to
represent it as an internal dma callback.
> + mutex_unlock(&epf->lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(pci_epf_internal_dmac_xfr);
> +
> /**
> * pci_epf_free_space() - free the allocated PCI EPF register space
> * @epf: the EPF device from whom to free the memory
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index a48778e1a4ee..b55dacd09e1e 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -58,6 +58,7 @@ pci_epc_interface_string(enum pci_epc_interface_type type)
> * @map_msi_irq: ops to map physical address to MSI address and return MSI data
> * @start: ops to start the PCI link
> * @stop: ops to stop the PCI link
> + * @dmac_transfer: ops to transfer data using internal DMAC
> * @get_features: ops to get the features supported by the EPC
> * @owner: the module owner containing the ops
> */
> @@ -86,6 +87,9 @@ struct pci_epc_ops {
> u32 *msi_addr_offset);
> int (*start)(struct pci_epc *epc);
> void (*stop)(struct pci_epc *epc);
> + int (*dmac_transfer)(struct pci_epc *epc, struct pci_epf *epf,
> + dma_addr_t dma_dst, dma_addr_t dma_src,
> + size_t len, enum pci_epf_xfr_direction dir);
> const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
> u8 func_no, u8 vfunc_no);
> struct module *owner;
> @@ -159,6 +163,8 @@ struct pci_epc {
> * for initialization
> * @msi_capable: indicate if the endpoint function has MSI capability
> * @msix_capable: indicate if the endpoint function has MSI-X capability
> + * @internal_dmac: indicate if the endpoint function has internal DMAC
> + * @internal_dmac_mask: indicates the DMA mask to be applied for the device
> * @reserved_bar: bitmap to indicate reserved BAR unavailable to function driver
> * @bar_fixed_64bit: bitmap to indicate fixed 64bit BARs
> * @bar_fixed_size: Array specifying the size supported by each BAR
> @@ -169,6 +175,8 @@ struct pci_epc_features {
> unsigned int core_init_notifier : 1;
> unsigned int msi_capable : 1;
> unsigned int msix_capable : 1;
> + unsigned int internal_dmac : 1;
> + u64 internal_dmac_mask;
internal_dma?
> u8 reserved_bar;
> u8 bar_fixed_64bit;
> u64 bar_fixed_size[PCI_STD_NUM_BARS];
> diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
> index 009a07147c61..78d661db085d 100644
> --- a/include/linux/pci-epf.h
> +++ b/include/linux/pci-epf.h
> @@ -32,6 +32,11 @@ enum pci_barno {
> BAR_5,
> };
>
> +enum pci_epf_xfr_direction {
> + PCIE_TO_INTERNAL,
> + INTERNAL_TO_PCIE,
I think we could just use "dma_data_direction" as we are anyway transferring
data between host and device.
Thanks,
Mani
> +};
> +
> /**
> * struct pci_epf_header - represents standard configuration header
> * @vendorid: identifies device manufacturer
> @@ -209,6 +214,8 @@ void pci_epf_free_space(struct pci_epf *epf, void *addr, enum pci_barno bar,
> enum pci_epc_interface_type type);
> int pci_epf_bind(struct pci_epf *epf);
> void pci_epf_unbind(struct pci_epf *epf);
> +int pci_epf_internal_dmac_xfr(struct pci_epf *epf, dma_addr_t dma_dst, dma_addr_t dma_src,
> + size_t len, enum pci_epf_xfr_direction dir);
> struct config_group *pci_epf_type_add_cfs(struct pci_epf *epf,
> struct config_group *group);
> int pci_epf_add_vepf(struct pci_epf *epf_pf, struct pci_epf *epf_vf);
> --
> 2.25.1
>
On Wed, Jan 26, 2022 at 07:50:42PM +0000, Lad Prabhakar wrote:
> By default GFP_KERNEL flag is used for buffer allocation in read, write
> and copy test and then later mapped using streaming DMA api. But on
> Renesas RZ/G2{EHMN} platforms using the default flag causes the tests to
> fail. Allocating the buffers from DMA zone (using the GFP_DMA flag) make
> the test cases to pass.
>
> To handle such case add flags as part of struct pci_endpoint_test_data
> so that platforms can pass the required flags based on the requirement.
>
> Signed-off-by: Lad Prabhakar <[email protected]>
> ---
> Hi All,
>
> This patch is based on the conversation where switching to streaming
> DMA api causes read/write/copy tests to fail on Renesas RZ/G2 platforms
> when buffers are allocated using GFP_KERNEL.
>
> [0] https://www.spinics.net/lists/linux-pci/msg92385.html
>
> Cheers,
> Prabhakar
> ---
> drivers/misc/pci_endpoint_test.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
> index 0a00d45830e9..974546992c5e 100644
> --- a/drivers/misc/pci_endpoint_test.c
> +++ b/drivers/misc/pci_endpoint_test.c
> @@ -117,6 +117,7 @@ struct pci_endpoint_test {
> enum pci_barno test_reg_bar;
> size_t alignment;
> size_t dmac_data_alignment;
> + gfp_t flags;
gfp_flags? Since this is used for allocation.
Thanks,
Mani
> const char *name;
> };
>
> @@ -125,6 +126,7 @@ struct pci_endpoint_test_data {
> size_t alignment;
> int irq_type;
> size_t dmac_data_alignment;
> + gfp_t flags;
> };
>
> static inline u32 pci_endpoint_test_readl(struct pci_endpoint_test *test,
> @@ -381,7 +383,7 @@ static bool pci_endpoint_test_copy(struct pci_endpoint_test *test,
> goto err;
> }
>
> - orig_src_addr = kzalloc(size + alignment, GFP_KERNEL);
> + orig_src_addr = kzalloc(size + alignment, test->flags);
> if (!orig_src_addr) {
> dev_err(dev, "Failed to allocate source buffer\n");
> ret = false;
> @@ -414,7 +416,7 @@ static bool pci_endpoint_test_copy(struct pci_endpoint_test *test,
>
> src_crc32 = crc32_le(~0, src_addr, size);
>
> - orig_dst_addr = kzalloc(size + alignment, GFP_KERNEL);
> + orig_dst_addr = kzalloc(size + alignment, test->flags);
> if (!orig_dst_addr) {
> dev_err(dev, "Failed to allocate destination address\n");
> ret = false;
> @@ -518,7 +520,7 @@ static bool pci_endpoint_test_write(struct pci_endpoint_test *test,
> goto err;
> }
>
> - orig_addr = kzalloc(size + alignment, GFP_KERNEL);
> + orig_addr = kzalloc(size + alignment, test->flags);
> if (!orig_addr) {
> dev_err(dev, "Failed to allocate address\n");
> ret = false;
> @@ -619,7 +621,7 @@ static bool pci_endpoint_test_read(struct pci_endpoint_test *test,
> goto err;
> }
>
> - orig_addr = kzalloc(size + alignment, GFP_KERNEL);
> + orig_addr = kzalloc(size + alignment, test->flags);
> if (!orig_addr) {
> dev_err(dev, "Failed to allocate destination address\n");
> ret = false;
> @@ -788,6 +790,7 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
> test->alignment = 0;
> test->pdev = pdev;
> test->irq_type = IRQ_TYPE_UNDEFINED;
> + test->flags = GFP_KERNEL;
>
> if (no_msi)
> irq_type = IRQ_TYPE_LEGACY;
> @@ -799,6 +802,7 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev,
> test->alignment = data->alignment;
> irq_type = data->irq_type;
> test->dmac_data_alignment = data->dmac_data_alignment;
> + test->flags = data->flags;
> }
>
> init_completion(&test->irq_raised);
> @@ -947,23 +951,27 @@ static const struct pci_endpoint_test_data default_data = {
> .test_reg_bar = BAR_0,
> .alignment = SZ_4K,
> .irq_type = IRQ_TYPE_MSI,
> + .flags = GFP_KERNEL,
> };
>
> static const struct pci_endpoint_test_data am654_data = {
> .test_reg_bar = BAR_2,
> .alignment = SZ_64K,
> .irq_type = IRQ_TYPE_MSI,
> + .flags = GFP_KERNEL,
> };
>
> static const struct pci_endpoint_test_data j721e_data = {
> .alignment = 256,
> .irq_type = IRQ_TYPE_MSI,
> + .flags = GFP_KERNEL,
> };
>
> static const struct pci_endpoint_test_data renesas_rzg2x_data = {
> .test_reg_bar = BAR_0,
> .irq_type = IRQ_TYPE_MSI,
> .dmac_data_alignment = 8,
> + .flags = GFP_KERNEL | GFP_DMA,
> };
>
> static const struct pci_device_id pci_endpoint_test_tbl[] = {
> --
> 2.25.1
>
> -----Original Message-----
> From: Lad, Prabhakar <[email protected]>
> Sent: Thursday, February 10, 2022 3:24 AM
> To: Manivannan Sadhasivam <[email protected]>
> Cc: Lad Prabhakar <[email protected]>; Kishon Vijay
> Abraham I <[email protected]>; Bjorn Helgaas <[email protected]>; Lorenzo
> Pieralisi <[email protected]>; Krzysztof Wilczy?ski <[email protected]>;
> Arnd Bergmann <[email protected]>; Greg Kroah-Hartman
> <[email protected]>; Marek Vasut <[email protected]>;
> Yoshihiro Shimoda <[email protected]>; Rob Herring
> <[email protected]>; linux-pci <[email protected]>; Linux-Renesas
> <[email protected]>; LKML <[email protected]>;
> Biju Das <[email protected]>
> Subject: [EXT] Re: [RFC PATCH 0/5] PCIe EPF support for internal DMAC
> handling and driver update for R-Car PCIe EP to support DMAC
I use standard DMA engine API to implement Designware PCIE EP embedded DMA support.
Please check https://lore.kernel.org/all/[email protected]/T/
Best regards
Frank Li
>
> Caution: EXT Email
>
> Hi,
>
> On Thu, Feb 10, 2022 at 8:40 AM Manivannan Sadhasivam
> <[email protected]> wrote:
> >
> > Hi,
> >
> > On Wed, Jan 26, 2022 at 07:50:38PM +0000, Lad Prabhakar wrote:
> > > Hi All,
> > >
> > > The current PCIe EPF framework supports DMA data transfers using
> external
> > > DMA only, this patch series aims to add support for platforms
> supporting
> > > internal DMAC on PCIe for data transfers.
> > >
> > > R-Car PCIe supports internal DMAC to transfer data between Internal Bus
> to
> > > PCI Express and vice versa. Last patch fills up the required flags and
> ops
> > > to support internal DMAC.
> > >
> > > Patches 1-3 are for PCIe EPF core to support internal DMAC handling,
> patch
> > > 4/5 is to fix test cases based on the conversation [1].
> > >
> >
> > This looks similar to the Synopsys eDMA IP [1] that goes with the
> Synopsys PCIe
> > endpoint IP. Why can't you represent it as a dmaengine driver and use the
> > existing DMA support?
> >
> Let me have a look. Could you please share a link to the Synopsys PCIe
> endpoint HW manual (the driver doesn't have a binding doc).
>
> Cheers,
> Prabhakar
>
> > [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kerne
> l.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdr
> ivers%2Fdma%2Fdw-
> edma&data=04%7C01%7Cfrank.li%40nxp.com%7C95a5831aac544de2211508d9ec772f
> 9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637800819106821404%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000&sdata=yG39L2YBN9blGxTcXyVQwIXol8%2FCo%2FZ3GbGPIlqz6Mg%3D
> &reserved=0
> >
> > > Patches are based on top of [1] next branch.
> > >
> > > [0]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spini
> cs.net%2Flists%2Flinux-
> pci%2Fmsg92385.html&data=04%7C01%7Cfrank.li%40nxp.com%7C95a5831aac544de
> 2211508d9ec772f9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637800819106
> 821404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ieX2gSSHFDumc1k2iWoOfMyHg236aJTE7UZ
> 5D74D9KM%3D&reserved=0
> > > [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kerne
> l.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fhelgaas%2Fpci.git&data=04%7C
> 01%7Cfrank.li%40nxp.com%7C95a5831aac544de2211508d9ec772f9a%7C686ea1d3bc2b4c
> 6fa92cd99c5c301635%7C0%7C0%7C637800819106821404%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&
> sdata=Qc5cW6y5OrxprDjFQ1dNMZ4ZUc656I3FZqClaUMLx%2FM%3D&reserved=0
> > >
> > > Cheers,
> > > Prabhakar
> > >
> > > Lad Prabhakar (5):
> > > PCI: endpoint: Add ops and flag to support internal DMAC
> > > PCI: endpoint: Add support to data transfer using internal dmac
> > > misc: pci_endpoint_test: Add driver data for Renesas RZ/G2{EHMN}
> > > misc: pci_endpoint_test: Add support to pass flags for buffer
> > > allocation
> > > PCI: rcar-ep: Add support for DMAC
> > >
> > > drivers/misc/pci_endpoint_test.c | 56 ++++-
> > > drivers/pci/controller/pcie-rcar-ep.c | 227 ++++++++++++++++++
> > > drivers/pci/controller/pcie-rcar.h | 23 ++
> > > drivers/pci/endpoint/functions/pci-epf-test.c | 184 ++++++++++----
> > > drivers/pci/endpoint/pci-epf-core.c | 32 +++
> > > include/linux/pci-epc.h | 8 +
> > > include/linux/pci-epf.h | 7 +
> > > 7 files changed, 483 insertions(+), 54 deletions(-)
> > >
> > > --
> > > 2.25.1
> > >
Hi Frank,
On Wed, Mar 2, 2022 at 3:42 PM Frank Li <[email protected]> wrote:
>
>
>
> > -----Original Message-----
> > From: Lad, Prabhakar <[email protected]>
> > Sent: Thursday, February 10, 2022 3:24 AM
> > To: Manivannan Sadhasivam <[email protected]>
> > Cc: Lad Prabhakar <[email protected]>; Kishon Vijay
> > Abraham I <[email protected]>; Bjorn Helgaas <[email protected]>; Lorenzo
> > Pieralisi <[email protected]>; Krzysztof Wilczyński <[email protected]>;
> > Arnd Bergmann <[email protected]>; Greg Kroah-Hartman
> > <[email protected]>; Marek Vasut <[email protected]>;
> > Yoshihiro Shimoda <[email protected]>; Rob Herring
> > <[email protected]>; linux-pci <[email protected]>; Linux-Renesas
> > <[email protected]>; LKML <[email protected]>;
> > Biju Das <[email protected]>
> > Subject: [EXT] Re: [RFC PATCH 0/5] PCIe EPF support for internal DMAC
> > handling and driver update for R-Car PCIe EP to support DMAC
>
> I use standard DMA engine API to implement Designware PCIE EP embedded DMA support.
> Please check https://lore.kernel.org/all/[email protected]/T/
>
Thank you for the link. The Designware PCIE EP is implemented as a DMA
engine driver so it's convenient to use the DMA engine API, whereas
the R-Car PCIe-EP is implemented as an actual PCIe EP [0].
[0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml?h=next-20220302
Cheers,
Prabhakar
> Best regards
> Frank Li
>
> >
> > Caution: EXT Email
> >
> > Hi,
> >
> > On Thu, Feb 10, 2022 at 8:40 AM Manivannan Sadhasivam
> > <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Jan 26, 2022 at 07:50:38PM +0000, Lad Prabhakar wrote:
> > > > Hi All,
> > > >
> > > > The current PCIe EPF framework supports DMA data transfers using
> > external
> > > > DMA only, this patch series aims to add support for platforms
> > supporting
> > > > internal DMAC on PCIe for data transfers.
> > > >
> > > > R-Car PCIe supports internal DMAC to transfer data between Internal Bus
> > to
> > > > PCI Express and vice versa. Last patch fills up the required flags and
> > ops
> > > > to support internal DMAC.
> > > >
> > > > Patches 1-3 are for PCIe EPF core to support internal DMAC handling,
> > patch
> > > > 4/5 is to fix test cases based on the conversation [1].
> > > >
> > >
> > > This looks similar to the Synopsys eDMA IP [1] that goes with the
> > Synopsys PCIe
> > > endpoint IP. Why can't you represent it as a dmaengine driver and use the
> > > existing DMA support?
> > >
> > Let me have a look. Could you please share a link to the Synopsys PCIe
> > endpoint HW manual (the driver doesn't have a binding doc).
> >
> > Cheers,
> > Prabhakar
> >
> > > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kerne
> > l.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdr
> > ivers%2Fdma%2Fdw-
> > edma&data=04%7C01%7Cfrank.li%40nxp.com%7C95a5831aac544de2211508d9ec772f
> > 9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637800819106821404%7CUnknow
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> > 6Mn0%3D%7C3000&sdata=yG39L2YBN9blGxTcXyVQwIXol8%2FCo%2FZ3GbGPIlqz6Mg%3D
> > &reserved=0
> > >
> > > > Patches are based on top of [1] next branch.
> > > >
> > > > [0]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spini
> > cs.net%2Flists%2Flinux-
> > pci%2Fmsg92385.html&data=04%7C01%7Cfrank.li%40nxp.com%7C95a5831aac544de
> > 2211508d9ec772f9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637800819106
> > 821404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> > Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ieX2gSSHFDumc1k2iWoOfMyHg236aJTE7UZ
> > 5D74D9KM%3D&reserved=0
> > > > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kerne
> > l.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fhelgaas%2Fpci.git&data=04%7C
> > 01%7Cfrank.li%40nxp.com%7C95a5831aac544de2211508d9ec772f9a%7C686ea1d3bc2b4c
> > 6fa92cd99c5c301635%7C0%7C0%7C637800819106821404%7CUnknown%7CTWFpbGZsb3d8eyJ
> > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&
> > sdata=Qc5cW6y5OrxprDjFQ1dNMZ4ZUc656I3FZqClaUMLx%2FM%3D&reserved=0
> > > >
> > > > Cheers,
> > > > Prabhakar
> > > >
> > > > Lad Prabhakar (5):
> > > > PCI: endpoint: Add ops and flag to support internal DMAC
> > > > PCI: endpoint: Add support to data transfer using internal dmac
> > > > misc: pci_endpoint_test: Add driver data for Renesas RZ/G2{EHMN}
> > > > misc: pci_endpoint_test: Add support to pass flags for buffer
> > > > allocation
> > > > PCI: rcar-ep: Add support for DMAC
> > > >
> > > > drivers/misc/pci_endpoint_test.c | 56 ++++-
> > > > drivers/pci/controller/pcie-rcar-ep.c | 227 ++++++++++++++++++
> > > > drivers/pci/controller/pcie-rcar.h | 23 ++
> > > > drivers/pci/endpoint/functions/pci-epf-test.c | 184 ++++++++++----
> > > > drivers/pci/endpoint/pci-epf-core.c | 32 +++
> > > > include/linux/pci-epc.h | 8 +
> > > > include/linux/pci-epf.h | 7 +
> > > > 7 files changed, 483 insertions(+), 54 deletions(-)
> > > >
> > > > --
> > > > 2.25.1
> > > >