linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Mikhak <alan.mikhak@sifive.com>
To: Gustavo Pimentel <Gustavo.Pimentel@synopsys.com>
Cc: "dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"kishon@ti.com" <kishon@ti.com>,
	"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>
Subject: Re: [PATCH RFC] dmaengine: dw-edma: Decouple dw-edma-core.c from struct pci_dev
Date: Wed, 15 Apr 2020 14:23:51 -0700	[thread overview]
Message-ID: <CABEDWGyUfq4c65K+btmKBcGLv59h6PFVUkSD_52kOw9R0Rtynw@mail.gmail.com> (raw)
In-Reply-To: <DM5PR12MB127673CFDCA38A47E6F6F4DBDADB0@DM5PR12MB1276.namprd12.prod.outlook.com>

On Wed, Apr 15, 2020 at 1:58 PM Gustavo Pimentel
<Gustavo.Pimentel@synopsys.com> 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].

>
>
>

  reply	other threads:[~2020-04-15 21:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15  2:07 [PATCH RFC] dmaengine: dw-edma: Decouple dw-edma-core.c from struct pci_dev Alan Mikhak
2020-04-15 12:13 ` Gustavo Pimentel
2020-04-15 17:24   ` Alan Mikhak
2020-04-15 18:17     ` Gustavo Pimentel
2020-04-15 18:55       ` Alan Mikhak
2020-04-15 20:57         ` Gustavo Pimentel
2020-04-15 21:23           ` Alan Mikhak [this message]
2020-04-15 23:26             ` Alan Mikhak

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=CABEDWGyUfq4c65K+btmKBcGLv59h6PFVUkSD_52kOw9R0Rtynw@mail.gmail.com \
    --to=alan.mikhak@sifive.com \
    --cc=Gustavo.Pimentel@synopsys.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=paul.walmsley@sifive.com \
    --cc=vkoul@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).