linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Alexander Gordeev <a.gordeev.box@gmail.com>, Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
	Michael Chen <micchen@altera.com>,
	dmaengine@vger.kernel.org
Subject: Re: [PATCH RFC 0/2] staging: Support Avalon-MM DMA Interface for PCIe
Date: Thu, 19 Sep 2019 22:42:46 +0530	[thread overview]
Message-ID: <20190919171246.GS4392@vkoul-mobl> (raw)
In-Reply-To: <20190919113708.GA3153236@kroah.com>

On 19-09-19, 13:37, Greg KH wrote:
> On Thu, Sep 19, 2019 at 11:59:11AM +0200, Alexander Gordeev wrote:
> > The Avalon-MM DMA Interface for PCIe is a design found in hard IPs for
> > Intel Arria, Cyclone or Stratix FPGAs. It transfers data between on-chip
> > memory and system memory. This RFC is an attempt to provide a generic API:
> > 
> > 	typedef void (*avalon_dma_xfer_callback)(void *dma_async_param);
> >  
> > 	int avalon_dma_submit_xfer(
> > 		struct avalon_dma *avalon_dma,
> > 		enum dma_data_direction direction,
> > 		dma_addr_t dev_addr, dma_addr_t host_addr,
> > 		unsigned int size,
> > 		avalon_dma_xfer_callback callback,
> > 		void *callback_param);
> >  
> > 	int avalon_dma_submit_xfer_sg(struct avalon_dma *avalon_dma,
> > 		enum dma_data_direction direction,
> > 		dma_addr_t dev_addr,
> > 		struct sg_table *sg_table,
> > 		avalon_dma_xfer_callback callback,
> > 		void *callback_param);
> >  
> > 	int avalon_dma_issue_pending(struct avalon_dma *avalon_dma);

Why wrap the *existing* kernel APIs with you own!

A quick glance at the code submitted tells me that it mimcks kernel
APIs. But why you folks didnt use the kernel dmaengine APIs in not clear
to me. So please convert it (should be relatively easy as you seem to
have wrappers for dmaengine callbacks)

> > 
> > Patch 1 introduces "avalon-dma" driver that provides the above-mentioned
> > generic interface.
> > 
> > Patch 2 adds "avalon-drv" driver using "avalon-dma" to transfer user-
> > provided data. This driver was used to debug and stress "avalon-dma"
> > and could be used as a code base for other implementations. Strictly
> > speaking, it does not need to be part of the kernel tree.
> > A companion tool using "avalon-drv" to DMA files (not part of this
> > patchset) is located at git@github.com:a-gordeev/avalon-drv-tool.git

Heh! We do have a dmatest driver which does this and much more! why not
use that one instead of adding you own!

> > The suggested interface is developed with the standard "dmaengine"
> > in mind and could be reworked to suit it. I would appreciate, however
> > gathering some feedback on the implemenation first - as the hardware-
> > specific code would persist. It is also a call for testing - I only
> > have access to a single Arria 10 device to try on.

Why not use dmaengine in first place?

> > This series is against v5.3 and could be found at
> > git@github.com:a-gordeev/linux.git avalon-dma-engine
> 
> Why is this being submitted for drivers/staging/ and not the "real" part
> of the kernel tree?
> 
> All staging code must have a TODO file listing what needs to be done in
> order to get it out of staging, and be self-contained (i.e. no files
> include/linux/)
> 
> Please fix that up when resending this series.

-- 
~Vinod

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

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19  9:59 [PATCH RFC 0/2] staging: Support Avalon-MM DMA Interface for PCIe Alexander Gordeev
2019-09-19  9:59 ` [PATCH RFC 1/2] staging: avalon-dma: Avalon DMA engine Alexander Gordeev
2019-09-19  9:59 ` [PATCH RFC 2/2] staging: avalon-drv: Avalon DMA driver Alexander Gordeev
2019-09-19 11:37 ` [PATCH RFC 0/2] staging: Support Avalon-MM DMA Interface for PCIe Greg KH
2019-09-19 17:12   ` Vinod Koul [this message]
2019-10-09 10:17   ` Alexander Gordeev

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=20190919171246.GS4392@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=a.gordeev.box@gmail.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=micchen@altera.com \
    /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).