From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: "Kishon Vijay Abraham I" <kishon@ti.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Marek Vasut" <marek.vasut+renesas@gmail.com>,
"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
"Rob Herring" <robh@kernel.org>,
linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-kernel@vger.kernel.org,
Prabhakar <prabhakar.csengg@gmail.com>,
"Biju Das" <biju.das.jz@bp.renesas.com>
Subject: Re: [RFC PATCH 1/5] PCI: endpoint: Add ops and flag to support internal DMAC
Date: Mon, 14 Feb 2022 15:00:12 +0530 [thread overview]
Message-ID: <20220214093012.GI3494@thinkpad> (raw)
In-Reply-To: <20220126195043.28376-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
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 <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> 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
>
next prev parent reply other threads:[~2022-02-14 9:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 19:50 [RFC PATCH 0/5] PCIe EPF support for internal DMAC handling and driver update for R-Car PCIe EP to support DMAC Lad Prabhakar
2022-01-26 19:50 ` [RFC PATCH 1/5] PCI: endpoint: Add ops and flag to support internal DMAC Lad Prabhakar
2022-02-14 9:30 ` Manivannan Sadhasivam [this message]
2022-01-26 19:50 ` [RFC PATCH 2/5] PCI: endpoint: Add support to data transfer using internal dmac Lad Prabhakar
2022-02-14 9:49 ` Manivannan Sadhasivam
2022-01-26 19:50 ` [RFC PATCH 3/5] misc: pci_endpoint_test: Add driver data for Renesas RZ/G2{EHMN} Lad Prabhakar
2022-02-14 10:02 ` Manivannan Sadhasivam
2022-01-26 19:50 ` [RFC PATCH 4/5] misc: pci_endpoint_test: Add support to pass flags for buffer allocation Lad Prabhakar
2022-02-14 10:11 ` Manivannan Sadhasivam
2022-01-26 19:50 ` [RFC PATCH 5/5] PCI: rcar-ep: Add support for DMAC Lad Prabhakar
2022-02-14 10:40 ` Manivannan Sadhasivam
2022-02-21 4:32 ` [EXT] " Li Chen
2022-02-09 4:47 ` [EXT] [RFC PATCH 0/5] PCIe EPF support for internal DMAC handling and driver update for R-Car PCIe EP to support DMAC Li Chen
2022-02-09 8:52 ` Lad, Prabhakar
2022-02-10 5:54 ` Li Chen
2022-02-10 7:47 ` Greg Kroah-Hartman
2022-02-10 8:40 ` Manivannan Sadhasivam
2022-02-10 9:24 ` Lad, Prabhakar
2022-02-10 10:50 ` Manivannan Sadhasivam
2022-02-10 11:05 ` Lad, Prabhakar
2022-02-10 13:22 ` Manivannan Sadhasivam
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=20220214093012.GI3494@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=gregkh@linuxfoundation.org \
--cc=kishon@ti.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=marek.vasut+renesas@gmail.com \
--cc=prabhakar.csengg@gmail.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=robh@kernel.org \
--cc=yoshihiro.shimoda.uh@renesas.com \
/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.