All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Mikhak <alan.mikhak@sifive.com>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Haotian Wang <haotian.wang@sifive.com>,
	haotian.wang@duke.edu,
	Gustavo Pimentel <Gustavo.Pimentel@synopsys.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"wen.yang99@zte.com.cn" <wen.yang99@zte.com.cn>,
	"kjlu@umn.edu" <kjlu@umn.edu>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"palmer@sifive.com" <palmer@sifive.com>,
	"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
	Vinod Koul <vkoul@kernel.org>
Subject: Re: [PATCH] PCI: endpoint: Add DMA to Linux PCI EP Framework
Date: Fri, 13 Sep 2019 10:39:50 -0700	[thread overview]
Message-ID: <CABEDWGy3VdH40QAz5NVhQHLLXXf2C5W22uUXEw3yCeNz0hfF-Q@mail.gmail.com> (raw)
In-Reply-To: <40fafe93-d2dd-b1f5-bc16-cd84ff07bd13@ti.com>

On Fri, Sep 13, 2019 at 5:11 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>
> + Haotian Wang
>
> On 03/06/19 11:12 PM, Alan Mikhak wrote:
> > On Sun, Jun 2, 2019 at 9:43 PM Kishon Vijay Abraham I <kishon@ti.com> wrote:
> >> Hi Alan,
> >> On 31/05/19 11:46 PM, Alan Mikhak wrote:
> >>> On Thu, May 30, 2019 at 10:08 PM Kishon Vijay Abraham I <kishon@ti.com> wrote:
> >>>> Hi Alan,
> >>>>> Hi Kishon,
> >>>>
> >>>> I still have to look closer into your DMA patch but linked-list mode or single
> >>>> block mode shouldn't be an user select-able option but should be determined by
> >>>> the size of transfer.
> >>>
> >>> Please consider the following when taking a closer look at this patch.
> >>
> >> After seeing comments from Vinod and Arnd, it looks like the better way of
> >> adding DMA support would be to register DMA within PCI endpoint controller to
> >> DMA subsystem (as dmaengine) and use only dmaengine APIs in pci_epf_test.
> >
> > Thanks Kishon. That makes it clear where these pieces should go.
> >
> >>> In my specific use case, I need to verify that any valid block size,
> >>> including a one byte transfer, can be transferred across the PCIe bus
> >>> by memcpy_toio/fromio() or by DMA either as a single block or as
> >>> linked-list. That is why, instead of deciding based on transfer size,
> >>> this patch introduces the '-L' flag for pcitest to communicate the
> >>> user intent across the PCIe bus to pci-epf-test so the endpoint can
> >>> initiate the DMA transfer using a single block or in linked-list mode.
> >> The -L option seems to select an internal DMA configuration which might be
> >> specific to one implementation. As Gustavo already pointed, we should have only
> >> generic options in pcitest. This would no longer be applicable when we move to
> >> dmaengine.
> >
> > Single-block DMA seemed as generic as linked-list DMA and
> > memcpy_toio/fromio. It remains unclear how else to communicate that
> > intent to pci_epf_test each time I invoke pcitest.
> >
> > Regards,
> > Alan
> >

Hi Kishon,

FYI, I integrated your changes for DMAengine client support to PCI
endpoint framework into my development branch. The following is the
link you provided earlier as reference. I have been using it with good
results. Haotian Wang also used it in a recent patch for PCI endpoint
function for virtnet. Would you be able to comment on if and when your
DMAengine client support may be submitted upstream?

http://git.ti.com/cgit/cgit.cgi/ti-linux-kernel/ti-linux-kernel.git/tree/drivers/pci/endpoint/pci-epf-core.c?h=ti-linux-4.19.y

Regards,
Alan Mikhak

WARNING: multiple messages have this Message-ID (diff)
From: Alan Mikhak <alan.mikhak@sifive.com>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: "lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	Gustavo Pimentel <Gustavo.Pimentel@synopsys.com>,
	haotian.wang@duke.edu, "kjlu@umn.edu" <kjlu@umn.edu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	Vinod Koul <vkoul@kernel.org>,
	Haotian Wang <haotian.wang@sifive.com>,
	"palmer@sifive.com" <palmer@sifive.com>,
	"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"wen.yang99@zte.com.cn" <wen.yang99@zte.com.cn>
Subject: Re: [PATCH] PCI: endpoint: Add DMA to Linux PCI EP Framework
Date: Fri, 13 Sep 2019 10:39:50 -0700	[thread overview]
Message-ID: <CABEDWGy3VdH40QAz5NVhQHLLXXf2C5W22uUXEw3yCeNz0hfF-Q@mail.gmail.com> (raw)
In-Reply-To: <40fafe93-d2dd-b1f5-bc16-cd84ff07bd13@ti.com>

On Fri, Sep 13, 2019 at 5:11 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>
> + Haotian Wang
>
> On 03/06/19 11:12 PM, Alan Mikhak wrote:
> > On Sun, Jun 2, 2019 at 9:43 PM Kishon Vijay Abraham I <kishon@ti.com> wrote:
> >> Hi Alan,
> >> On 31/05/19 11:46 PM, Alan Mikhak wrote:
> >>> On Thu, May 30, 2019 at 10:08 PM Kishon Vijay Abraham I <kishon@ti.com> wrote:
> >>>> Hi Alan,
> >>>>> Hi Kishon,
> >>>>
> >>>> I still have to look closer into your DMA patch but linked-list mode or single
> >>>> block mode shouldn't be an user select-able option but should be determined by
> >>>> the size of transfer.
> >>>
> >>> Please consider the following when taking a closer look at this patch.
> >>
> >> After seeing comments from Vinod and Arnd, it looks like the better way of
> >> adding DMA support would be to register DMA within PCI endpoint controller to
> >> DMA subsystem (as dmaengine) and use only dmaengine APIs in pci_epf_test.
> >
> > Thanks Kishon. That makes it clear where these pieces should go.
> >
> >>> In my specific use case, I need to verify that any valid block size,
> >>> including a one byte transfer, can be transferred across the PCIe bus
> >>> by memcpy_toio/fromio() or by DMA either as a single block or as
> >>> linked-list. That is why, instead of deciding based on transfer size,
> >>> this patch introduces the '-L' flag for pcitest to communicate the
> >>> user intent across the PCIe bus to pci-epf-test so the endpoint can
> >>> initiate the DMA transfer using a single block or in linked-list mode.
> >> The -L option seems to select an internal DMA configuration which might be
> >> specific to one implementation. As Gustavo already pointed, we should have only
> >> generic options in pcitest. This would no longer be applicable when we move to
> >> dmaengine.
> >
> > Single-block DMA seemed as generic as linked-list DMA and
> > memcpy_toio/fromio. It remains unclear how else to communicate that
> > intent to pci_epf_test each time I invoke pcitest.
> >
> > Regards,
> > Alan
> >

Hi Kishon,

FYI, I integrated your changes for DMAengine client support to PCI
endpoint framework into my development branch. The following is the
link you provided earlier as reference. I have been using it with good
results. Haotian Wang also used it in a recent patch for PCI endpoint
function for virtnet. Would you be able to comment on if and when your
DMAengine client support may be submitted upstream?

http://git.ti.com/cgit/cgit.cgi/ti-linux-kernel/ti-linux-kernel.git/tree/drivers/pci/endpoint/pci-epf-core.c?h=ti-linux-4.19.y

Regards,
Alan Mikhak

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2019-09-13 17:40 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 22:24 [PATCH] PCI: endpoint: Add DMA to Linux PCI EP Framework Alan Mikhak
2019-05-23 22:24 ` Alan Mikhak
2019-05-24  8:59 ` Gustavo Pimentel
2019-05-24  8:59   ` Gustavo Pimentel
2019-05-24 19:42   ` Alan Mikhak
2019-05-24 19:42     ` Alan Mikhak
2019-05-27  9:09     ` Gustavo Pimentel
2019-05-27  9:09       ` Gustavo Pimentel
2019-05-29 22:37       ` Alan Mikhak
2019-05-29 22:37         ` Alan Mikhak
2019-05-30  5:46         ` Kishon Vijay Abraham I
2019-05-30  5:46           ` Kishon Vijay Abraham I
2019-05-30 17:56           ` Alan Mikhak
2019-05-30 17:56             ` Alan Mikhak
2019-05-31  5:06             ` Kishon Vijay Abraham I
2019-05-31  5:06               ` Kishon Vijay Abraham I
2019-05-31 18:16               ` Alan Mikhak
2019-05-31 18:16                 ` Alan Mikhak
2019-06-03  4:41                 ` Kishon Vijay Abraham I
2019-06-03  4:41                   ` Kishon Vijay Abraham I
2019-06-03 17:42                   ` Alan Mikhak
2019-06-03 17:42                     ` Alan Mikhak
2019-09-13 12:11                     ` Kishon Vijay Abraham I
2019-09-13 12:11                       ` Kishon Vijay Abraham I
2019-09-13 17:39                       ` Alan Mikhak [this message]
2019-09-13 17:39                         ` Alan Mikhak
2019-05-31  5:07           ` Vinod Koul
2019-05-31  5:07             ` Vinod Koul
2019-05-31  5:20             ` Kishon Vijay Abraham I
2019-05-31  5:20               ` Kishon Vijay Abraham I
2019-05-31  6:32               ` Vinod Koul
2019-05-31  6:32                 ` Vinod Koul
2019-05-31  7:49                 ` Arnd Bergmann
2019-05-31  7:49                   ` Arnd Bergmann
2019-06-03  4:29                   ` Kishon Vijay Abraham I
2019-06-03  4:29                     ` Kishon Vijay Abraham I
2019-06-03  4:24                 ` Kishon Vijay Abraham I
2019-06-03  4:24                   ` Kishon Vijay Abraham I
2019-06-03  4:42                   ` Vinod Koul
2019-06-03  4:42                     ` Vinod Koul

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=CABEDWGy3VdH40QAz5NVhQHLLXXf2C5W22uUXEw3yCeNz0hfF-Q@mail.gmail.com \
    --to=alan.mikhak@sifive.com \
    --cc=Gustavo.Pimentel@synopsys.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=haotian.wang@duke.edu \
    --cc=haotian.wang@sifive.com \
    --cc=jingoohan1@gmail.com \
    --cc=kishon@ti.com \
    --cc=kjlu@umn.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.com \
    --cc=vkoul@kernel.org \
    --cc=wen.yang99@zte.com.cn \
    /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.