From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F667C433F5 for ; Mon, 14 Feb 2022 09:31:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243589AbiBNJb4 (ORCPT ); Mon, 14 Feb 2022 04:31:56 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:42650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243533AbiBNJbT (ORCPT ); Mon, 14 Feb 2022 04:31:19 -0500 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 364D3AE47 for ; Mon, 14 Feb 2022 01:30:22 -0800 (PST) Received: by mail-pj1-x102c.google.com with SMTP id m7so14012483pjk.0 for ; Mon, 14 Feb 2022 01:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=VcnEn/2NWd+/RTs+MullchxIkZjgGZxkU+9opOFbT/E=; b=gBTRLGlaAj4HJU+BV6EKy1c7SRjH3ZcYNjesOBAIUBrh/uJhWfqNl4nuvTvank74fG 0Fll3ywyLTal5NaXfV95mwYlAMez8rk1khrDRLlKR6cGCIwsm79cmXPrFfb1qEXUy5QF XUpcU2pDxOq6U/6ODZq3rCeT/5yti0Vz6XB/gUKZDMsy9nxIV+889Bo3t1Ar5w/NkiY/ QbN9Q7xhG5aqC1ykGXzg3frw8QOXhjXr8K2osJ7VypdPmuUuU9S91ig7qh8E6uomgVNJ TJlU2PasI8nha32acKj4h5iCGfQRiJoUopwJyYmHBNpTJToSexWQtID9cnFfcBB6eTZz 0jiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=VcnEn/2NWd+/RTs+MullchxIkZjgGZxkU+9opOFbT/E=; b=iKSIZVrk8uhdZeImfc15MdBZQNrAR7jCTwTBeL4PRP72AAKxEyZKK1LcWDmdBXruSI UIhFq4RuupyjIljxHKd5ShK0wqheyxnMLmuEivCCRILum/0UDPj4PX10dH14ZUA5gBwE S5aB9L0+aJXrMji16v5hg2OZo5EnbTw7JMYRXC8NtwTVyUAR0Xa2cZYxQJVi910ToU5g Mw+CIhK5z+FIZJhOQDvTT3HlpS+PEV22Zb/jirM1PjWSPo9EYmvwYJhoqOw02TYio+qQ dnBZSk1I6lFn1yuxSPCKpey3ZLAS74ont4FiTuWzz78/AvmqlZz5C69CIWFf5h/fni9h yafA== X-Gm-Message-State: AOAM533Zi3Amnb67bjaKKf3CNNcWA7sMszW2j73zGsYkXzEIvms+wbif Jt/9aNrGRtuhzkYi8arZrvZBzkVDvU0z0NA= X-Google-Smtp-Source: ABdhPJw+/gbE94SUWsRBzGerqbSwRwYgZd0xqI8AQd5IBANHze8aVI2ksk/Qqd2UmHldJ+0vAgxYEw== X-Received: by 2002:a17:902:d88f:: with SMTP id b15mr13442997plz.44.1644831021418; Mon, 14 Feb 2022 01:30:21 -0800 (PST) Received: from thinkpad ([2409:4072:817:5a6f:3104:62c0:1941:5033]) by smtp.gmail.com with ESMTPSA id g4sm35616188pfv.63.2022.02.14.01.30.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Feb 2022 01:30:21 -0800 (PST) Date: Mon, 14 Feb 2022 15:00:12 +0530 From: Manivannan Sadhasivam To: Lad Prabhakar Cc: Kishon Vijay Abraham I , Bjorn Helgaas , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Arnd Bergmann , Greg Kroah-Hartman , Marek Vasut , Yoshihiro Shimoda , Rob Herring , linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org, Prabhakar , Biju Das Subject: Re: [RFC PATCH 1/5] PCI: endpoint: Add ops and flag to support internal DMAC Message-ID: <20220214093012.GI3494@thinkpad> References: <20220126195043.28376-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20220126195043.28376-2-prabhakar.mahadev-lad.rj@bp.renesas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220126195043.28376-2-prabhakar.mahadev-lad.rj@bp.renesas.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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 >