linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: vinod.koul@intel.com, dan.j.williams@intel.com,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	Jassi Brar <jaswinder.singh@linaro.org>,
	Kumar Gala <galak@kernel.crashing.org>,
	Matt Porter <mporter@kernel.crashing.org>,
	Li Yang <leoli@freescale.com>
Subject: Re: [PATCH 01/11] dmaengine: add context parameter to prep_slave_sg and prep_dma_cyclic
Date: Thu, 2 Feb 2012 21:43:50 +0000	[thread overview]
Message-ID: <20120202214350.GB4432@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1328218341-31436-2-git-send-email-alexandre.bounine@idt.com>

On Thu, Feb 02, 2012 at 04:32:11PM -0500, Alexandre Bounine wrote:
> Add context parameter to device_prep_slave_sg() and device_prep_dma_cyclic()
> interfaces to allow passing client/target specific information associated
> with the data transfer.

I'm slightly concerned about having this as a vague 'void *' pointer.
What that means is that the data being passed through it is entirely
unspecified, and quite specific to the DMA engine.

That's rather worrying when we (on ARM) are moving towards a model
where the same peripheral IP can be backed by multiple different DMA
engines.  We already have peripheral drivers (clients of DMA engine)
which can be attached to completely different DMA engine drivers.

If DMA engines continue to operate conventionally with this parameter
NULL then that's fine for current stuff.  I would suggest that it's
made to be something a little better defined though, as the 'void *'
approach encourages each driver writer to invent their own way to
specify, eg, an interleaved transfer.  We'll then end up with N
different ways to specify the same thing.

Not only that, but peripheral drivers won't know what kind of data to
pass there (they would have to have additional knowledge of the DMA
engine which they're attached to.)

Basically, allowing a DMA engine specific blob of data to be passed
destroys the idea of having a consistent API for peripheral drivers
to use, because they can then no longer be independent of their DMA
engine.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

  reply	other threads:[~2012-02-02 21:44 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-02 21:32 [PATCH 00/11] dmaengine: add context parameter to prep_slave_sg and prep_dma_cyclic Alexandre Bounine
2012-02-02 21:32 ` [PATCH 01/11] " Alexandre Bounine
2012-02-02 21:43   ` Russell King [this message]
2012-02-03 15:31     ` [PATCH 01/11] dmaengine: add context parameter toprep_slave_sg " Bounine, Alexandre
2012-02-06 11:53       ` Vinod Koul
2012-02-06 15:04         ` Bounine, Alexandre
2012-02-06 15:28           ` Vinod Koul
2012-02-06 15:53             ` Russell King
2012-02-06 17:02               ` [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma_cyclic Bounine, Alexandre
2012-02-06 18:07                 ` Vinod Koul
2012-02-06 18:45                   ` Bounine, Alexandre
2012-02-07  3:39                     ` Vinod Koul
2012-02-07 14:01                       ` Bounine, Alexandre
2012-02-07 14:14                         ` Vinod Koul
2012-02-07 14:19                           ` Bounine, Alexandre
2012-02-06 18:04               ` [PATCH 01/11] dmaengine: add context parameter toprep_slave_sg and prep_dma_cyclic Vinod Koul
2012-02-06 15:56             ` Bounine, Alexandre
2012-02-06 16:16               ` Russell King
2012-02-02 21:32 ` [PATCH 02/11] dmaengine/drivers: add context parameter for DMA_SLAVE and DMA_CYCLIC Alexandre Bounine
2012-02-02 21:32 ` [PATCH 03/11] plat-samsung: " Alexandre Bounine
2012-02-02 21:32 ` [PATCH 04/11] media/video: add new context parameter for DMA_SLAVE calls Alexandre Bounine
2012-02-02 21:32 ` [PATCH 05/11] mmc/host: add context parameter for DMA_SLAVE and DMA_CYCLIC Alexandre Bounine
2012-02-03  9:20   ` Ulf Hansson
2012-02-03 16:52     ` Bounine, Alexandre
2012-02-03 17:01       ` Russell King
2012-02-03 18:36         ` [PATCH 05/11] mmc/host: add context parameter for DMA_SLAVEand DMA_CYCLIC Bounine, Alexandre
2012-02-02 21:32 ` [PATCH 06/11] nand/gpmi: add context parameter to prep_slave_sg calls Alexandre Bounine
2012-02-02 22:13   ` Marek Vasut
2012-02-03 16:35     ` Bounine, Alexandre
2012-02-02 21:32 ` [PATCH 07/11] net/ks8842: add context parameter to prep_slave_sg call Alexandre Bounine
2012-02-02 21:32 ` [PATCH 08/11] spi/serial: add context parameter for DMA_SLAVE and DMA_CYCLIC Alexandre Bounine
2012-02-02 21:32 ` [PATCH 09/11] usb/musb: add context parameter to prep_slave_sg call Alexandre Bounine
2012-02-02 21:32 ` [PATCH 10/11] usb/renesas: " Alexandre Bounine
2012-02-02 21:32 ` [PATCH 11/11] sound/soc: add context parameter to prep_slave_sg and prep_dma_cyclic calls Alexandre Bounine
2012-02-02 22:22   ` Mark Brown
2012-02-03 16:41     ` Bounine, Alexandre

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=20120202214350.GB4432@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.bounine@idt.com \
    --cc=dan.j.williams@intel.com \
    --cc=galak@kernel.crashing.org \
    --cc=jaswinder.singh@linaro.org \
    --cc=leoli@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mporter@kernel.crashing.org \
    --cc=vinod.koul@intel.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).