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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80D15C2BA2B for ; Wed, 15 Apr 2020 21:25:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4C48220784 for ; Wed, 15 Apr 2020 21:25:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b="N0VtjTbS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729603AbgDOVZD (ORCPT ); Wed, 15 Apr 2020 17:25:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S2442400AbgDOVYJ (ORCPT ); Wed, 15 Apr 2020 17:24:09 -0400 Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88174C061A10 for ; Wed, 15 Apr 2020 14:24:04 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id y4so5412209ljn.7 for ; Wed, 15 Apr 2020 14:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zUiwPngCjCOT149YM1CpaUAyMcgHTCV4FZO5uSdXs+4=; b=N0VtjTbSPmMQI+RlTx1yObqj6x91R6W/fup4bZ4ZAA+dHBABtXgciXtch5GcEGhoHH JmpIDKEpx4dr8jnrsQA60GzCYrlGW1Im7DMFGyc+RQhpSKlgA1M3aP69+t2Ip2Dqd4Qm cEOqAB/oeDbu0bTlvmUdRScVlX+VDAHyy4VjpGfwHVHPml+4gftSkW+dnlvSr7e6+z6K fDyudV/9jxQQ+0tlIrcRokGYM4WOiJjnPRZKJTpxln1seAqdLqi+lqYzf/JdgR32fPD+ 1W0RZJJw1XOxnLJtjsatcvivLOwJtvEPGPqvG+kdDzn390e0JVGwfXJrIfTR1sKBmDuj 2Vtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zUiwPngCjCOT149YM1CpaUAyMcgHTCV4FZO5uSdXs+4=; b=jUvjETmqxUsYf1rtm37td+7x89vgusxYMBvAihCRQafyMp0qpryZhC/1VnYDxPZpQz IsHDSiqaiIuACjiXuKYHmoeuZhDI+Dgopz83wQdfe5cc/I6U5QPsOIWCCDxrKKE3HATj aA+82VKZ9mf44mpn0vn52zMwR9mhbkVGx35tSWyHsQoSxvoSaeEgOOsekfiZnEPMyuEt iJ9igBd5te5KEIl+btGwz1BaJxLbXKCEhlcuMmuwMAszVV4k/3yRdDcmkAql3Uf80aMz 2khJgyNnWmQS40J6BhbjRcg8Y4yjWoc/h9N39Drtfwffqu/wrYbtSmhfp0JCyI+iijPN oTnA== X-Gm-Message-State: AGi0PuYcUA2im8+Yk8b95rM/+6fEgG4B+gI73tL6abY9Yjb5qL4MZgMx YzYD0e9c7P06hz4jIzinQsc7j2LTYR9z6HIWTK2vZA== X-Google-Smtp-Source: APiQypIOBCwRkWiDlV64pN+RvUzocju2VTLfH55G/LdorNT2T1+BVYwjjGnn2AsvN+E5sbPB+MNiKYSe4EI4Mugszi4= X-Received: by 2002:a2e:8056:: with SMTP id p22mr4614252ljg.266.1586985842846; Wed, 15 Apr 2020 14:24:02 -0700 (PDT) MIME-Version: 1.0 References: <1586916464-27727-1-git-send-email-alan.mikhak@sifive.com> In-Reply-To: From: Alan Mikhak Date: Wed, 15 Apr 2020 14:23:51 -0700 Message-ID: Subject: Re: [PATCH RFC] dmaengine: dw-edma: Decouple dw-edma-core.c from struct pci_dev To: Gustavo Pimentel Cc: "dmaengine@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , "dan.j.williams@intel.com" , "vkoul@kernel.org" , "kishon@ti.com" , "paul.walmsley@sifive.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 15, 2020 at 1:58 PM Gustavo Pimentel wrote: > > Hi Alan, > > > > > At the moment, pci-epf-test grabs the first available dma channel on the > > > > endpoint side and uses it for either read, write, or copy operation. it is not > > > > possible at the moment to specify which dma channel to use on the pcitest > > > > command line. This may be possible by modifying the command line option > > > > -D to also specify the name of one or more dma channels. > > > > > > I'm assuming that behavior is due to your code, right? I'm not seen that > > > behavior on the Kernel tree. > > > Check my previous suggestion, it should be something similar to what is > > > been done while you select the MSI/MSI-X interrupt to trigger. > > > > I believe this behavior exists in the kernel tree because the call to > > dma_request_chan_by_mask() always specifies channel zero. The user > > of pcitest has no way of specifying which one of the available dma channels > > to use. > > I think we were discussing different things. I was referring to the > pci-epf-test code, that I wasn't being able to find any instruction to > call the DMA driver which had the described behavior. > > I think you can do it by doing this: > > Pseudo code: > > #define EDMA_TEST_CHANNEL_NAME "dma%uchan%u" > > static bool dw_edma_test_filter(struct dma_chan *chan, void *filter) > { > if (strcmp(dev_name(chan->device->dev), EDMA_TEST_DEVICE_NAME) || > strcmp(dma_chan_name(chan), filter)) > return false; > > return true; > } > > static void dw_edma_test_thread_create(int id, int channel) > { > struct dma_chan *chan; > dma_cap_mask_t mask; > char filter[20]; > > dma_cap_zero(mask); > dma_cap_set(DMA_SLAVE, mask); > dma_cap_set(DMA_CYCLIC, mask); > > snprintf(filter, sizeof(filter), EDMA_TEST_CHANNEL_NAME, id, > channel); > chan = dma_request_channel(mask, dw_edma_test_filter, filter); > > [..] > } Thanks Gustavo, This pseudo code is very useful. Now I know how to do that part of the change. What I have further in mind is to enable the pcitest user to specify some arbitrary string with -D option to select one or more of the dma channels that are available on the endpoint side. Since the user executes pcitest from host-side command prompt and pci-epf-test executes in kernel on the endpoint side, the messaging between userspace pcitest and kernel-space pci_endpoint_test as well as the messaging across the bus between pci_endpoint_test and pci-epf-test needs to be expanded to pass the user string from the host to the endpoint. Upon receiving each read, write, or copy message, pci-epf-test could then try to acquire the specified dma channel and execute the user command or fail it if no such channel is available at that moment. > > > I believe this behavior exists in the kernel tree because the call to > > dma_request_chan_by_mask() happens during the execution of > > pci_epf_test_bind() and the call to dma_release_channel() happens > > during the execution of pci_epf_test_unbind(). As long as pci-epf-test > > is bound, I cannot use another program such as dmatest from the > > endpoint-side command prompt to exercise the same channel. > > Ok, I understood it now. Right, you can't use the dmatest here, even > because, as far as I know, it is only MEM TO MEM operations and we need > DEVICE_TO_MEM and vice-versa. > > > > > What I was suggesting is perhaps pci-epf-test can be modified to > > acquire and release the channel on each call to pci_epf_test_read(), > > ...write(), or ...copy() when the pcitest user specifies -D option. > > Right, you are on the right track. > Perhaps you could take a look at patch [1] that I have done some time ago > for testing the eDMA, I think you have all the tools/guideline there to > do this adaption. > Another thing, > > [1] https://patchwork.kernel.org/patch/10760521/ Thanks for the guidance and reference code patch [1]. I will definitely take a close look at [1]. > > >