Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp5834263pxb; Mon, 14 Feb 2022 08:39:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJzK7DUEazZvEGhlrzFnZ0hQNDXNvZsDxO9WHUBuf6f63grZz1xhGurtZazDubONzkIuDbMn X-Received: by 2002:a17:907:1624:: with SMTP id hb36mr386607ejc.42.1644856774184; Mon, 14 Feb 2022 08:39:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644856774; cv=none; d=google.com; s=arc-20160816; b=qruk+ZEhgGZklXStlXAU8HQls0kdYlG7U4SMxjsJZLbMg+cjzPcFWO9AutblgCZ34d JksW3Zr48TebokRxBxoO+u91nlvP21CCbKTWM7ICyov5S7tL9hmyvAzlFcaXGLOEBV5v KvfFpWC9WT/ZfJdSOfUvbb+l7osztCt3AVbnjwfRTRI/X0V1PRKyOMy7cvrmEG1FXVrK SRAmneCs6YVWA8zr5WwfrHSnPAqmLd61zuSBDxybziexJC2Amx8uJaf4f6htkyJPqT2S BY41IyTLjxlA0xyjthKePv/9qnzc3HScorS45AiW6o02xfDMiVd0HmJspEzo4/U+63L4 Iyig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=/S2BvEODEAJUahCS59ViatHoyD/cWLeqwLgA2QTvjE8=; b=XSrLTavPehNVikeJlywwx15Xi0L1k3TEx8Xz2zIG0HmcBpKW2XY08XzjmxCi2G0Qbh KVgYJRSgwC1sFsFBMDETl5DK14mZLEE0n2siDB0SdOriGPniEJzE4NIbq9vz5k9zQruC w2FsrQ+ZrFOu6F/rOgNMW3SvSV5kZ6Q4/Ddba1/0z4cosC222KSYGG8fkdBc2VPBmMmZ 8nBkjUfZTMq5+A4W+O5CVN5h9utyH333dzft6KElGx3BqQn0antgWKeCF2wVnyoUU9uh t4Czk9yWEj2g/tEOTwf3HS+1G1txEGuoRIca6I8hWPFJ8OTG9kNkLsB4jzodpB6g5szP rwVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=JUQGBXn8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gt20si22340705ejc.694.2022.02.14.08.39.10; Mon, 14 Feb 2022 08:39:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=JUQGBXn8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345211AbiBNKKV (ORCPT + 99 others); Mon, 14 Feb 2022 05:10:21 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:35470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345357AbiBNKGI (ORCPT ); Mon, 14 Feb 2022 05:06:08 -0500 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 226327463F for ; Mon, 14 Feb 2022 01:49:30 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id h7-20020a17090a648700b001b927560c2bso14056394pjj.1 for ; Mon, 14 Feb 2022 01:49:30 -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=/S2BvEODEAJUahCS59ViatHoyD/cWLeqwLgA2QTvjE8=; b=JUQGBXn8+euWZUwquBLidxbuLw3TdJfHMe5lIkxyYnB5E5+Phe4SJM/kzbR8LVgZLJ omYavMfQGq1XrSeFoRjwnWMWMy7yRDIgbekO0KHYkv8s0gH2vh8whPhUhPxwrcZ6XVl0 uS0Ib/HK4qNAugHZ10eCwxmb7yWA/ZRPKv6G734jNdINZ+C6YkBZRSoRWZuykoaAmPGE TnqmxBsQNvEOOpJNpyzDQlo8NySA3K8Lle/JgGhv6XZ/I9EG+nyDS9yKwJ9960el5V3+ Gh7T0qVbB5wEVxCp5E5TDp5a643j3lGzBzOp85KvPbiGro5WYSv/D3GfWNHGNWT/Q4DK drSQ== 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=/S2BvEODEAJUahCS59ViatHoyD/cWLeqwLgA2QTvjE8=; b=A9taN2lxGHITQs8p6OT220C/2/82IaSC15EvAyZeaV7XBIaeNq/c7kpjO38AkVJq5Q Q3hZpcmKnAhfrhiQpyzgugUMrTnJ5lUW6LJQzDnJTg5AgOSxOe8njaF9m1eG8aHWab/0 2ShD1uAKAZ+9vY896iZWIs0dX3QkwH6+vt98d09XTiA4KoNCuY5qSXhtIJJf5FCvneG/ UVzapWuBgb8yIo+Lvs7WPrDqwxEkXCusMOczlrtP3Qz46KUETnKYwrkVwYm1pgn+WyFm Y7qqBEveMKSuKGHfw4q8fV8LYO250kdfk9sbHPeeBuvhNe/LAwyh5Q8WZNvj8BXOwRpB lUPw== X-Gm-Message-State: AOAM53012vW7wvUy0nbNkrXYStZuwZS/OPm1JXnk+BLaq3btjS2+68Zs YLjJMrYVwZVx+v2muReDoQ45q9ZTxlNXcQ4= X-Received: by 2002:a17:903:2406:: with SMTP id e6mr13119868plo.21.1644832169511; Mon, 14 Feb 2022 01:49:29 -0800 (PST) Received: from thinkpad ([2409:4072:817:5a6f:3104:62c0:1941:5033]) by smtp.gmail.com with ESMTPSA id l17sm35406780pfu.61.2022.02.14.01.49.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Feb 2022 01:49:29 -0800 (PST) Date: Mon, 14 Feb 2022 15:19:19 +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 2/5] PCI: endpoint: Add support to data transfer using internal dmac Message-ID: <20220214094919.GJ3494@thinkpad> References: <20220126195043.28376-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20220126195043.28376-3-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-3-prabhakar.mahadev-lad.rj@bp.renesas.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 26, 2022 at 07:50:40PM +0000, Lad Prabhakar wrote: > For PCIe EP capable with internal DMAC, transfer data using this > when -d option is used with pcitest. > > Signed-off-by: Lad Prabhakar > --- > drivers/pci/endpoint/functions/pci-epf-test.c | 184 ++++++++++++++---- > 1 file changed, 141 insertions(+), 43 deletions(-) > > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c > index 90d84d3bc868..f792b1a15c44 100644 > --- a/drivers/pci/endpoint/functions/pci-epf-test.c > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c > @@ -55,6 +55,7 @@ struct pci_epf_test { > struct dma_chan *dma_chan; > struct completion transfer_complete; > bool dma_supported; > + bool internal_dmac; Please use "dma" everywhere. > const struct pci_epc_features *epc_features; > }; > > @@ -148,6 +149,40 @@ static int pci_epf_test_data_transfer(struct pci_epf_test *epf_test, > return 0; > } > > +/** > + * pci_epf_test_internal_dmac_data_transfer() - Function that uses internal DMAC > + * to transfer data between PCIe EP and remote PCIe RC > + * @epf_test: the EPF test 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 > + * @dir: Direction of data transfer > + * > + * Function that uses internal dmac supported by the controller to transfer data > + * between PCIe EP and remote PCIe RC. > + * > + * The function returns '0' on success and negative value on failure. > + */ > +static int > +pci_epf_test_internal_dmac_data_transfer(struct pci_epf_test *epf_test, > + dma_addr_t dma_dst, dma_addr_t dma_src, > + size_t len, enum pci_epf_xfr_direction dir) > +{ > + struct pci_epf *epf = epf_test->epf; > + int ret; > + > + if (!epf_test->internal_dmac) > + return -EINVAL; > + > + ret = pci_epf_internal_dmac_xfr(epf, dma_dst, dma_src, len, dir); > + if (ret) > + return -EIO; Why can't you return "ret"? > + > + return 0; > +} > + > /** > * pci_epf_test_init_dma_chan() - Function to initialize EPF test DMA channel > * @epf_test: the EPF test device that performs data transfer operation > @@ -238,6 +273,14 @@ static int pci_epf_test_copy(struct pci_epf_test *epf_test) > struct pci_epc *epc = epf->epc; > enum pci_barno test_reg_bar = epf_test->test_reg_bar; > struct pci_epf_test_reg *reg = epf_test->reg[test_reg_bar]; > + bool internal_dmac = epf_test->internal_dmac; > + > + use_dma = !!(reg->flags & FLAG_USE_DMA); > + > + if (use_dma && internal_dmac) { > + dev_err(dev, "Operation not supported\n"); Here you are erroring out but below you are checking for this condition to do internal DMA transfer. > + return -EINVAL; > + } > > src_addr = pci_epc_mem_alloc_addr(epc, &src_phys_addr, reg->size); > if (!src_addr) { > @@ -272,7 +315,6 @@ static int pci_epf_test_copy(struct pci_epf_test *epf_test) Why internal DMA is not used in pci_epf_test_copy()? > } > > ktime_get_ts64(&start); > - use_dma = !!(reg->flags & FLAG_USE_DMA); > if (use_dma) { > if (!epf_test->dma_supported) { > dev_err(dev, "Cannot transfer data using DMA\n"); > @@ -322,31 +364,49 @@ static int pci_epf_test_read(struct pci_epf_test *epf_test) > struct device *dma_dev = epf->epc->dev.parent; > enum pci_barno test_reg_bar = epf_test->test_reg_bar; > struct pci_epf_test_reg *reg = epf_test->reg[test_reg_bar]; > + bool internal_dmac = epf_test->internal_dmac; > > - src_addr = pci_epc_mem_alloc_addr(epc, &phys_addr, reg->size); > - if (!src_addr) { > - dev_err(dev, "Failed to allocate address\n"); > - reg->status = STATUS_SRC_ADDR_INVALID; > - ret = -ENOMEM; > - goto err; > - } > + use_dma = !!(reg->flags & FLAG_USE_DMA); > > - ret = pci_epc_map_addr(epc, epf->func_no, epf->vfunc_no, phys_addr, > - reg->src_addr, reg->size); > - if (ret) { > - dev_err(dev, "Failed to map address\n"); > - reg->status = STATUS_SRC_ADDR_INVALID; > - goto err_addr; > + if (use_dma && internal_dmac) { Both are mutually exclusive, isn't it? > + phys_addr = reg->src_addr; > + src_addr = NULL; > + } else { > + src_addr = pci_epc_mem_alloc_addr(epc, &phys_addr, reg->size); > + if (!src_addr) { > + dev_err(dev, "Failed to allocate address\n"); > + reg->status = STATUS_SRC_ADDR_INVALID; > + ret = -ENOMEM; > + goto err; > + } > + > + ret = pci_epc_map_addr(epc, epf->func_no, epf->vfunc_no, phys_addr, > + reg->src_addr, reg->size); > + if (ret) { > + dev_err(dev, "Failed to map address\n"); > + reg->status = STATUS_SRC_ADDR_INVALID; > + goto err_addr; > + } > } > [...] > > ret = pci_epf_test_alloc_space(epf); > if (ret) > @@ -868,11 +964,13 @@ static int pci_epf_test_bind(struct pci_epf *epf) > return ret; > } > > - epf_test->dma_supported = true; > + epf_test->dma_supported = false; > > - ret = pci_epf_test_init_dma_chan(epf_test); > - if (ret) > - epf_test->dma_supported = false; > + if (!epf_test->internal_dmac) { > + ret = pci_epf_test_init_dma_chan(epf_test); > + if (!ret) > + epf_test->dma_supported = true; You can set this flag to true inside pci_epf_test_init_dma_chan(). Thanks, Mani > + } > > if (linkup_notifier) { > epf->nb.notifier_call = pci_epf_test_notifier; > -- > 2.25.1 >