linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Vinod Koul <vkoul@kernel.org>
Cc: Kishon Vijay Abraham I <kishon@ti.com>,
	Alan Mikhak <alan.mikhak@sifive.com>,
	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>,
	"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>
Subject: Re: [PATCH] PCI: endpoint: Add DMA to Linux PCI EP Framework
Date: Fri, 31 May 2019 09:49:53 +0200	[thread overview]
Message-ID: <CAK8P3a2jePe7Qfjciq4fdfngAudzCb-cai4fr3_BG_evnbjhvw@mail.gmail.com> (raw)
In-Reply-To: <20190531063247.GP15118@vkoul-mobl>

On Fri, May 31, 2019 at 8:32 AM Vinod Koul <vkoul@kernel.org> wrote:
> On 31-05-19, 10:50, Kishon Vijay Abraham I wrote:
> > On 31/05/19 10:37 AM, Vinod Koul wrote:
> > > On 30-05-19, 11:16, Kishon Vijay Abraham I wrote:
> > >>
> > >> right, my initial thought process was to use only dmaengine APIs in
> > >> pci-epf-test so that the system DMA or DMA within the PCIe controller can be
> > >> used transparently. But can we register DMA within the PCIe controller to the
> > >> DMA subsystem? AFAIK only system DMA should register with the DMA subsystem.
> > >> (ADMA in SDHCI doesn't use dmaengine). Vinod Koul can confirm.
> > >
> > > So would this DMA be dedicated for PCI and all PCI devices on the bus?
> >
> > Yes, this DMA will be used only by PCI ($patch is w.r.t PCIe device mode. So
> > all endpoint functions both physical and virtual functions will use the DMA in
> > the controller).
> > > If so I do not see a reason why this cannot be using dmaengine. The use
> >
> > Thanks for clarifying. I was under the impression any DMA within a peripheral
> > controller shouldn't use DMAengine.
>
> That is indeed a correct assumption. The dmaengine helps in cases where
> we have a dma controller with multiple users, for a single user case it
> might be overhead to setup dma driver and then use it thru framework.
>
> Someone needs to see the benefit and cost of using the framework and
> decide.

I think the main question is about how generalized we want this to be.
There are lots of difference PCIe endpoint implementations, and in
case of some licensable IP cores like the designware PCIe there are
many variants, as each SoC will do the implementation in a slightly
different way.

If we can have a single endpoint driver than can either have an
integrated DMA engine or use an external one, then abstracting that
DMA engine helps make the driver work more readily either way.

Similarly, there may be PCIe endpoint implementations that have
a dedicated DMA engine in them that is not usable for anything else,
but that is closely related to an IP core we already have a dmaengine
driver for. In this case, we can avoid duplication.

      Arnd

  reply	other threads:[~2019-05-31  7:50 UTC|newest]

Thread overview: 20+ 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-24  8:59 ` Gustavo Pimentel
2019-05-24 19:42   ` Alan Mikhak
2019-05-27  9:09     ` Gustavo Pimentel
2019-05-29 22:37       ` Alan Mikhak
2019-05-30  5:46         ` Kishon Vijay Abraham I
2019-05-30 17:56           ` Alan Mikhak
2019-05-31  5:06             ` Kishon Vijay Abraham I
2019-05-31 18:16               ` Alan Mikhak
2019-06-03  4:41                 ` Kishon Vijay Abraham I
2019-06-03 17:42                   ` Alan Mikhak
2019-09-13 12:11                     ` Kishon Vijay Abraham I
2019-09-13 17:39                       ` Alan Mikhak
2019-05-31  5:07           ` Vinod Koul
2019-05-31  5:20             ` Kishon Vijay Abraham I
2019-05-31  6:32               ` Vinod Koul
2019-05-31  7:49                 ` Arnd Bergmann [this message]
2019-06-03  4:29                   ` Kishon Vijay Abraham I
2019-06-03  4:24                 ` Kishon Vijay Abraham I
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=CAK8P3a2jePe7Qfjciq4fdfngAudzCb-cai4fr3_BG_evnbjhvw@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=Gustavo.Pimentel@synopsys.com \
    --cc=alan.mikhak@sifive.com \
    --cc=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --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 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).