[PATCH 00/11] dmaengine: add context parameter to prep_slave_sg and prep_dma_cyclic

[PATCH 00/11] dmaengine: add context parameter to prep_slave_sg and prep_dma_cyclic

[Alexandre Bounine]

As we agreed during our discussion about adding DMA Engine support for RapidIO
subsystem [1], RapidIO and similar clients may benefit from adding an extra
context parameter to device_prep_slave_sg() and device_prep_dma_cyclic() interfaces.

Adding the context parameter will allow to pass client/target specific
information associated with an individual data transfer request.

In the case of RapidIO support this additional information consists of target
destination ID and its buffer address (which is not mapped into the local CPU
memory space). Because a single RapidIO-capable DMA channel may queue data
transfer requests to different target devices, the per-request configuration
is required.

This set of patches presents changes to DMA_SLAVE and DMA_CYCLIC interfaces [2]
and corresponding changes to all affected current drivers/clients.

DMA Engine support for RapidIO and device-specific driver for Tsi721 PCIe-to-SRIO
bridge will follow as a separate set of patches.

[1] https://lkml.org/lkml/2011/10/24/275
[2] https://lkml.org/lkml/2012/1/30/624


Alexandre Bounine (11):
  dmaengine: add context parameter to prep_slave_sg and prep_dma_cyclic
  dmaengine/drivers: add context parameter for DMA_SLAVE and DMA_CYCLIC
  plat-samsung: add context parameter for DMA_SLAVE and DMA_CYCLIC
  media/video: add new context parameter for DMA_SLAVE calls
  mmc/host: add context parameter for DMA_SLAVE and DMA_CYCLIC
  nand/gpmi: add context parameter to prep_slave_sg calls
  net/ks8842: add context parameter to prep_slave_sg call
  spi/serial: add context parameter for DMA_SLAVE and DMA_CYCLIC
  usb/musb: add context parameter to prep_slave_sg call
  usb/renesas: add context parameter to prep_slave_sg call
  sound/soc: add context parameter to prep_slave_sg and prep_dma_cyclic
    calls

 arch/arm/plat-nomadik/include/plat/ste_dma40.h |    2 +-
 arch/arm/plat-samsung/dma-ops.c                |    5 ++-
 drivers/dma/amba-pl08x.c                       |    2 +-
 drivers/dma/at_hdmac.c                         |    7 ++++-
 drivers/dma/coh901318.c                        |    2 +-
 drivers/dma/dw_dmac.c                          |    2 +-
 drivers/dma/ep93xx_dma.c                       |    6 +++-
 drivers/dma/fsldma.c                           |    4 ++-
 drivers/dma/imx-dma.c                          |    5 ++-
 drivers/dma/imx-sdma.c                         |    5 ++-
 drivers/dma/intel_mid_dma.c                    |    3 +-
 drivers/dma/ipu/ipu_idmac.c                    |    3 +-
 drivers/dma/mxs-dma.c                          |    5 ++-
 drivers/dma/pch_dma.c                          |    3 +-
 drivers/dma/pl330.c                            |    5 ++-
 drivers/dma/shdma.c                            |    3 +-
 drivers/dma/sirf-dma.c                         |    2 +-
 drivers/dma/ste_dma40.c                        |    5 ++-
 drivers/dma/timb_dma.c                         |    3 +-
 drivers/dma/txx9dmac.c                         |    2 +-
 drivers/media/video/mx3_camera.c               |    2 +-
 drivers/media/video/timblogiw.c                |    2 +-
 drivers/mmc/host/atmel-mci.c                   |    2 +-
 drivers/mmc/host/mmci.c                        |    2 +-
 drivers/mmc/host/mxcmmc.c                      |    2 +-
 drivers/mmc/host/mxs-mmc.c                     |    2 +-
 drivers/mmc/host/sh_mmcif.c                    |    6 +++-
 drivers/mmc/host/tmio_mmc_dma.c                |    4 +-
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c          |   25 ++++++++++++++---------
 drivers/net/ethernet/micrel/ks8842.c           |    4 +-
 drivers/spi/spi-dw-mid.c                       |    6 +++-
 drivers/spi/spi-ep93xx.c                       |    3 +-
 drivers/spi/spi-pl022.c                        |    6 +++-
 drivers/spi/spi-topcliff-pch.c                 |    6 +++-
 drivers/tty/serial/amba-pl011.c                |    6 +++-
 drivers/tty/serial/pch_uart.c                  |    5 ++-
 drivers/tty/serial/sh-sci.c                    |    4 +-
 drivers/usb/musb/ux500_dma.c                   |    3 +-
 drivers/usb/renesas_usbhs/fifo.c               |    3 +-
 drivers/video/mx3fb.c                          |    6 +++-
 include/linux/dmaengine.h                      |   10 +++++---
 sound/soc/ep93xx/ep93xx-pcm.c                  |    2 +-
 sound/soc/imx/imx-pcm-dma-mx2.c                |    2 +-
 sound/soc/mxs/mxs-pcm.c                        |    2 +-
 sound/soc/sh/siu_pcm.c                         |    6 +++-
 sound/soc/txx9/txx9aclc.c                      |    2 +-
 46 files changed, 120 insertions(+), 77 deletions(-)

-- 
1.7.8.4

[PATCH 01/11] dmaengine: add context parameter to prep_slave_sg and prep_dma_cyclic

[Alexandre Bounine]

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.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Russell King <rmk@arm.linux.org.uk> 
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
---
 include/linux/dmaengine.h |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 679b349..2251bfa 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -575,10 +575,11 @@ struct dma_device {
 	struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
 		struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
-		unsigned long flags);
+		unsigned long flags, void *context);
 	struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
 		struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
-		size_t period_len, enum dma_transfer_direction direction);
+		size_t period_len, enum dma_transfer_direction direction,
+		void *context);
 	struct dma_async_tx_descriptor *(*device_prep_interleaved_dma)(
 		struct dma_chan *chan, struct dma_interleaved_template *xt,
 		unsigned long flags);
@@ -607,12 +608,13 @@ static inline int dmaengine_slave_config(struct dma_chan *chan,
 
 static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
 	struct dma_chan *chan, void *buf, size_t len,
-	enum dma_transfer_direction dir, unsigned long flags)
+	enum dma_transfer_direction dir, unsigned long flags, void *context)
 {
 	struct scatterlist sg;
 	sg_init_one(&sg, buf, len);
 
-	return chan->device->device_prep_slave_sg(chan, &sg, 1, dir, flags);
+	return chan->device->device_prep_slave_sg(chan, &sg, 1, dir, flags,
+						  context);
 }
 
 static inline int dmaengine_terminate_all(struct dma_chan *chan)
-- 
1.7.8.4

Re: [PATCH 01/11] dmaengine: add context parameter to prep_slave_sg and prep_dma_cyclic

[Russell King]

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:

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sg and prep_dma_cyclic

[Bounine, Alexandre]

On Thu, Feb 02, 2012 at 4:44 PM, Russell King wrote:
> 
> 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.
> 
I agree with your concern about "void *" being quite wide-open
definition.
But it may be practically impossible to come up with better definition
that may be equally suitable for different systems or HW combinations
(e.g. definition that is good for ARM peripherals may not fit into the
RapidIO model).

Some level of protection should be expected from filter callbacks
invoked
by dma_request_channel(). This way, for example, RapidIO client will not
acquire DMA channel which does not support RapidIO data transfers. 
 
After saying all above to defend the changes, I have to admit that your
comment made me to look harder for an alternative way to pass
per-transfer
parameter. As a result, I am considering a new idea when per-transfer
configuration data will be passed as the first element of the scatter
list.
Something like a packet header data but it will be used to setup
buffer descriptors instead of being part of data stream.

This new approach will preserve existing DMA engine interface and be
easier
for backporting of RapidIO drivers. Yes, there is a system dependency in
scatter
list format but it is completely protected by channel filtering
mechanism.   

Because of that it may be a good idea to consider this set of patches
being "on hold" unless there are other parties interested in proposed
interface changes.
 
AB.

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sg and prep_dma_cyclic

[Vinod Koul]

On Fri, 2012-02-03 at 07:31 -0800, Bounine, Alexandre wrote:
> On Thu, Feb 02, 2012 at 4:44 PM, Russell King wrote:
> > 
> > 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.
Russell,
Agreed but the problem with new models like RIO, MSM is that they seem
to have some different parameters they depend on, apart from the usual
ones we have. And these are per transfer dependent rather than channel
dependent as we have. So we need some way to pass arch specfic
parameters... so a agenric mechanism this was proposed...
Agreed, this has its own shortcoming. If you have a better way, please
let us know :)

> > 
> > 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.
> > 
> I agree with your concern about "void *" being quite wide-open
> definition.
> But it may be practically impossible to come up with better definition
> that may be equally suitable for different systems or HW combinations
> (e.g. definition that is good for ARM peripherals may not fit into the
> RapidIO model).
> 
> Some level of protection should be expected from filter callbacks
> invoked
> by dma_request_channel(). This way, for example, RapidIO client will not
> acquire DMA channel which does not support RapidIO data transfers. 
>  
> After saying all above to defend the changes, I have to admit that your
> comment made me to look harder for an alternative way to pass
> per-transfer
> parameter. As a result, I am considering a new idea when per-transfer
> configuration data will be passed as the first element of the scatter
> list.
> Something like a packet header data but it will be used to setup
> buffer descriptors instead of being part of data stream.
Alexandre,
dmac gets physical address, so you would need to remap that again to be
able to parse these buffers... Sorry I dont like this idea at all.
> 
> This new approach will preserve existing DMA engine interface and be
> easier
> for backporting of RapidIO drivers. Yes, there is a system dependency in
> scatter
> list format but it is completely protected by channel filtering
> mechanism.   
> 
> Because of that it may be a good idea to consider this set of patches
> being "on hold" unless there are other parties interested in proposed
> interface changes.


-- 
~Vinod

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sg and prep_dma_cyclic

[Bounine, Alexandre]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4196 bytes --]

On Mon, Feb 06, 2012 at 6:53 AM, Vinod Koul wrote:
> On Fri, 2012-02-03 at 07:31 -0800, Bounine, Alexandre wrote:
> > On Thu, Feb 02, 2012 at 4:44 PM, Russell King wrote:
> > >
> > > 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.
> Russell,
> Agreed but the problem with new models like RIO, MSM is that they seem
> to have some different parameters they depend on, apart from the usual
> ones we have. And these are per transfer dependent rather than channel
> dependent as we have. So we need some way to pass arch specfic
> parameters... so a agenric mechanism this was proposed...
> Agreed, this has its own shortcoming. If you have a better way, please
> let us know :)
> 
> > >
> > > 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.
> > >
> > I agree with your concern about "void *" being quite wide-open
> > definition.
> > But it may be practically impossible to come up with better
> definition
> > that may be equally suitable for different systems or HW combinations
> > (e.g. definition that is good for ARM peripherals may not fit into
> the
> > RapidIO model).
> >
> > Some level of protection should be expected from filter callbacks
> > invoked
> > by dma_request_channel(). This way, for example, RapidIO client will
> not
> > acquire DMA channel which does not support RapidIO data transfers.
> >
> > After saying all above to defend the changes, I have to admit that
> your
> > comment made me to look harder for an alternative way to pass
> > per-transfer
> > parameter. As a result, I am considering a new idea when per-transfer
> > configuration data will be passed as the first element of the scatter
> > list.
> > Something like a packet header data but it will be used to setup
> > buffer descriptors instead of being part of data stream.
> Alexandre,
> dmac gets physical address, so you would need to remap that again to be
> able to parse these buffers... Sorry I dont like this idea at all.

I was thinking about keeping the original scatterlist for dmac unchanged,
but allocating another scatterlist in rio_dma_prep_slave_sg() and chaining
two lists together. After it passed to device specific function, it parses
first section of the chain for additional transfer parameters and use
following scatterlist as intended for dmac.

But Russell's idea (See https://lkml.org/lkml/2012/2/3/269 ) seems to be
a better way without added complexity and I am ready to take that path and
make new patches if you and Dan agree with it.   

... skip ...

Alex.

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sg and prep_dma_cyclic

[Vinod Koul]

On Mon, 2012-02-06 at 07:04 -0800, Bounine, Alexandre wrote:
> I was thinking about keeping the original scatterlist for dmac unchanged,
> but allocating another scatterlist in rio_dma_prep_slave_sg() and chaining
> two lists together. After it passed to device specific function, it parses
> first section of the chain for additional transfer parameters and use
> following scatterlist as intended for dmac.
hmmm, but that wouldn't make it generic for other systems like proposed
MSM box mode..., right?
> 
> But Russell's idea (See https://lkml.org/lkml/2012/2/3/269 ) seems to be
> a better way without added complexity and I am ready to take that path and
> make new patches if you and Dan agree with it. 
but it still doesn't fix his concerns for the using void pointer.

If we agree that this is the way, then I was thinking to add arch specif
calls which cast the context pointer to void for passing to dmac. The
arch specific struct gets defined in dmaengine_arch.h <or something
similar>. That way clients cant define their own stuff and we continue
to be generic as well as cater to arch specific requirements.

-- 
~Vinod

Re: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sg and prep_dma_cyclic

[Russell King]

On Mon, Feb 06, 2012 at 08:58:54PM +0530, Vinod Koul wrote:
> On Mon, 2012-02-06 at 07:04 -0800, Bounine, Alexandre wrote:
> > I was thinking about keeping the original scatterlist for dmac unchanged,
> > but allocating another scatterlist in rio_dma_prep_slave_sg() and chaining
> > two lists together. After it passed to device specific function, it parses
> > first section of the chain for additional transfer parameters and use
> > following scatterlist as intended for dmac.
> hmmm, but that wouldn't make it generic for other systems like proposed
> MSM box mode..., right?
> > 
> > But Russell's idea (See https://lkml.org/lkml/2012/2/3/269 ) seems to be
> > a better way without added complexity and I am ready to take that path and
> > make new patches if you and Dan agree with it. 
> but it still doesn't fix his concerns for the using void pointer.

It helps because it makes it easier to find those drivers who are not
using the generic interface (and so would be tied to their particular
DMA engine.)

Let's take a step back.

One of the fundamental points for having a DMA engine API is to separate
the DMA users from the DMA engines, and make the two independent.  This
allows DMA users (like MMC, UARTs, etc) to be written in a way that they
are totally independent of the DMA engine.

Why is this important?  We're seeing an increasing number of SoCs with
the same peripheral IP integrated onto them but with different DMA
controllers.  Not only does that happen within an architecture, but you
can bet it'll start happening outside.  For example, AMBA Primecell
peripherals are not only found on ARM but also on SoCs with differing
CPUs.  Some PXA peripherals are now being found on x86 hardware.

So, we need a basic DMA engine API which ensures that users of the API
do not have to know any details about the DMA engine itself for them to
be able to get on with their business.

Now, if we start allowing a 'void *' per-transfer random pointer, then
what will happen is that we'll end up with people abusing it for passing
other stuff, maybe such as DMA request lines because they don't want to
bother with virtual channels in their DMA engine.  At that point, the
peripheral drivers gain knowledge about the DMA engine they're attached
to, and it becomes impossible to reuse them without resorting to ifdeffery
in the peripheral drivers.

This brings up a fundamental question: if you have a DMA engine which
has some unique specific feature, and needs extra data to use that funky
feature passed through the generic API, is it appropriate to use the
generic API, or does it make sense to augment the API in some way?

It might be that the peripherals of this funky feature are soo tied to
the DMA engine that it wouldn't ever be appropriate for them to live
with a different DMA engine.  In that case, does the DMA engine API
actually benefit them, or does it result in an erosion of the API
boundary, and therefore the separation of DMA engine from DMA user?

If the net result will be that the DMA engine API boundaries are blured,
then we've lost, because we need a replacement API to do the job that we
desperately need our existing API to be doing for us.

And that's my biggest concern about nebulous undefined 'void *'
arguments across this API.

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

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma_cyclic

[Bounine, Alexandre]

On Mon, Feb 06, 2012 at 10:53 AM, Russell King wrote:
> 
> On Mon, Feb 06, 2012 at 08:58:54PM +0530, Vinod Koul wrote:
> > On Mon, 2012-02-06 at 07:04 -0800, Bounine, Alexandre wrote:
> > > I was thinking about keeping the original scatterlist for dmac
> unchanged,
> > > but allocating another scatterlist in rio_dma_prep_slave_sg() and
> chaining
> > > two lists together. After it passed to device specific function,
it
> parses
> > > first section of the chain for additional transfer parameters and
> use
> > > following scatterlist as intended for dmac.
> > hmmm, but that wouldn't make it generic for other systems like
> proposed
> > MSM box mode..., right?
> > >
> > > But Russell's idea (See https://lkml.org/lkml/2012/2/3/269 ) seems
> to be
> > > a better way without added complexity and I am ready to take that
> path and
> > > make new patches if you and Dan agree with it.
> > but it still doesn't fix his concerns for the using void pointer.
> 
> It helps because it makes it easier to find those drivers who are not
> using the generic interface (and so would be tied to their particular
> DMA engine.)
> 

What if we introduce another dma_transaction_type like DMA_SLAVE_EXT
(extended?).
In this case all devices that adhere to the generic SLAVE interface
still be
registered as DMA_SLAVE and those that do not follow generic route use
DMA_SLAVE_EXT.

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma_cyclic

[Vinod Koul]

On Mon, 2012-02-06 at 09:02 -0800, Bounine, Alexandre wrote:
> 
> What if we introduce another dma_transaction_type like DMA_SLAVE_EXT
> (extended?).
> In this case all devices that adhere to the generic SLAVE interface
> still be
> registered as DMA_SLAVE and those that do not follow generic route use
> DMA_SLAVE_EXT. 
that way it would be channel specific not transaction specific as you
had asked for...?

Again, how does this solve problem of passing parameters while
preventing abuse...

-- 
~Vinod

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma_cyclic

[Bounine, Alexandre]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1418 bytes --]

On Mon, Feb 06, 2012 at 1:07 PM, Vinod Koul wrote:
> 
> On Mon, 2012-02-06 at 09:02 -0800, Bounine, Alexandre wrote:
> >
> > What if we introduce another dma_transaction_type like DMA_SLAVE_EXT
> > (extended?).
> > In this case all devices that adhere to the generic SLAVE interface
> > still be
> > registered as DMA_SLAVE and those that do not follow generic route
> use
> > DMA_SLAVE_EXT.
> that way it would be channel specific not transaction specific as you
> had asked for...?
> 
> Again, how does this solve problem of passing parameters while
> preventing abuse...

This gives a channel-specific treatment to the parameter. Channels registered
as DMA_SLAVE never expect an extra parameter (BUG_ON if the pointer is not NULL).
In the generic use scenario described by Russell clients are safe to request
any such channel without an additional HW knowledge (as it is now).

Channels registered as DMA_SLAVE_EXT will accept a pointer to parameter structure.
This, combined with configuration specific wrappers as you described
in earlier e-mail with #ifdef CONFIG_RAPIDIO, should ensure that there is no
unexpected treatment of (void *) parameter. Also for channels registered
as DMA_SLAVE_EXT a corresponding filter routine must be provided. 

Alex.

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma_cyclic

[Vinod Koul]

On Mon, 2012-02-06 at 10:45 -0800, Bounine, Alexandre wrote:
> On Mon, Feb 06, 2012 at 1:07 PM, Vinod Koul wrote:
> > 
> > On Mon, 2012-02-06 at 09:02 -0800, Bounine, Alexandre wrote:
> > >
> > > What if we introduce another dma_transaction_type like DMA_SLAVE_EXT
> > > (extended?).
> > > In this case all devices that adhere to the generic SLAVE interface
> > > still be
> > > registered as DMA_SLAVE and those that do not follow generic route
> > use
> > > DMA_SLAVE_EXT.
> > that way it would be channel specific not transaction specific as you
> > had asked for...?
> > 
> > Again, how does this solve problem of passing parameters while
> > preventing abuse...
> 
> This gives a channel-specific treatment to the parameter. Channels registered
> as DMA_SLAVE never expect an extra parameter (BUG_ON if the pointer is not NULL).
> In the generic use scenario described by Russell clients are safe to request
> any such channel without an additional HW knowledge (as it is now).
> 
> Channels registered as DMA_SLAVE_EXT will accept a pointer to parameter structure.
> This, combined with configuration specific wrappers as you described
> in earlier e-mail with #ifdef CONFIG_RAPIDIO, should ensure that there is no
> unexpected treatment of (void *) parameter. Also for channels registered
> as DMA_SLAVE_EXT a corresponding filter routine must be provided. 
Okay this sounds better :)
Sorry I didnt quite get the last line about filter routine?

-- 
~Vinod

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma_cyclic

[Bounine, Alexandre]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2330 bytes --]

On Mon, Feb 06, 2012 at 10:40 PM, Vinod Koul wrote:
> 
> On Mon, 2012-02-06 at 10:45 -0800, Bounine, Alexandre wrote:
> > On Mon, Feb 06, 2012 at 1:07 PM, Vinod Koul wrote:
> > >
> > > On Mon, 2012-02-06 at 09:02 -0800, Bounine, Alexandre wrote:
> > > >
> > > > What if we introduce another dma_transaction_type like
> DMA_SLAVE_EXT
> > > > (extended?).
> > > > In this case all devices that adhere to the generic SLAVE
> interface
> > > > still be
> > > > registered as DMA_SLAVE and those that do not follow generic
> route
> > > use
> > > > DMA_SLAVE_EXT.
> > > that way it would be channel specific not transaction specific as
> you
> > > had asked for...?
> > >
> > > Again, how does this solve problem of passing parameters while
> > > preventing abuse...
> >
> > This gives a channel-specific treatment to the parameter. Channels
> registered
> > as DMA_SLAVE never expect an extra parameter (BUG_ON if the pointer
> is not NULL).
> > In the generic use scenario described by Russell clients are safe to
> request
> > any such channel without an additional HW knowledge (as it is now).
> >
> > Channels registered as DMA_SLAVE_EXT will accept a pointer to
> parameter structure.
> > This, combined with configuration specific wrappers as you described
> > in earlier e-mail with #ifdef CONFIG_RAPIDIO, should ensure that
> there is no
> > unexpected treatment of (void *) parameter. Also for channels
> registered
> > as DMA_SLAVE_EXT a corresponding filter routine must be provided.
> Okay this sounds better :)
> Sorry I didnt quite get the last line about filter routine?
> 
Currently function private_candidate() allows filtering function
not to be specified and therefore skip the filter check.
It may be a good safety measure to ensure that channels specified
as DMA_SLAVE_EXT provide a corresponding filter routine so they
positively identify dma channel that will accept intended extra parameter.
I assume that a system may have more than one dmac registered as DMA_SLAVE_EXT. 

This is what I have for RapidIO - the filter call ensures that DMA
channel is associated with a RapidIO controller that provides access
to the specified SRIO device.


Alex.
 
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma_cyclic

[Vinod Koul]

On Tue, 2012-02-07 at 06:01 -0800, Bounine, Alexandre wrote:
> Currently function private_candidate() allows filtering function
> not to be specified and therefore skip the filter check.
> It may be a good safety measure to ensure that channels specified
> as DMA_SLAVE_EXT provide a corresponding filter routine so they
> positively identify dma channel that will accept intended extra
> parameter.
> I assume that a system may have more than one dmac registered as
> DMA_SLAVE_EXT. 
> 
> This is what I have for RapidIO - the filter call ensures that DMA
> channel is associated with a RapidIO controller that provides access
> to the specified SRIO device. 
For slave-dma it's better to have a filter :)
-- 
~Vinod

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sgand prep_dma_cyclic

[Bounine, Alexandre]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 996 bytes --]

On Tue, Feb 07, 2012 9:14 AM, Vinod Koul wrote:
> 
> On Tue, 2012-02-07 at 06:01 -0800, Bounine, Alexandre wrote:
> > Currently function private_candidate() allows filtering function
> > not to be specified and therefore skip the filter check.
> > It may be a good safety measure to ensure that channels specified
> > as DMA_SLAVE_EXT provide a corresponding filter routine so they
> > positively identify dma channel that will accept intended extra
> > parameter.
> > I assume that a system may have more than one dmac registered as
> > DMA_SLAVE_EXT.
> >
> > This is what I have for RapidIO - the filter call ensures that DMA
> > channel is associated with a RapidIO controller that provides access
> > to the specified SRIO device.
> For slave-dma it's better to have a filter :)

Better, but it can get away without it ;))

Alex.


ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sg and prep_dma_cyclic

[Vinod Koul]

On Mon, 2012-02-06 at 15:53 +0000, Russell King wrote:
> On Mon, Feb 06, 2012 at 08:58:54PM +0530, Vinod Koul wrote:
> > On Mon, 2012-02-06 at 07:04 -0800, Bounine, Alexandre wrote:
> > > I was thinking about keeping the original scatterlist for dmac unchanged,
> > > but allocating another scatterlist in rio_dma_prep_slave_sg() and chaining
> > > two lists together. After it passed to device specific function, it parses
> > > first section of the chain for additional transfer parameters and use
> > > following scatterlist as intended for dmac.
> > hmmm, but that wouldn't make it generic for other systems like proposed
> > MSM box mode..., right?
> > > 
> > > But Russell's idea (See https://lkml.org/lkml/2012/2/3/269 ) seems to be
> > > a better way without added complexity and I am ready to take that path and
> > > make new patches if you and Dan agree with it. 
> > but it still doesn't fix his concerns for the using void pointer.
> 
> It helps because it makes it easier to find those drivers who are not
> using the generic interface (and so would be tied to their particular
> DMA engine.)
> 
> Let's take a step back.
> 
> One of the fundamental points for having a DMA engine API is to separate
> the DMA users from the DMA engines, and make the two independent.  This
> allows DMA users (like MMC, UARTs, etc) to be written in a way that they
> are totally independent of the DMA engine.
> 
> Why is this important?  We're seeing an increasing number of SoCs with
> the same peripheral IP integrated onto them but with different DMA
> controllers.  Not only does that happen within an architecture, but you
> can bet it'll start happening outside.  For example, AMBA Primecell
> peripherals are not only found on ARM but also on SoCs with differing
> CPUs.  Some PXA peripherals are now being found on x86 hardware.
Yes this is the basic premise we are working on.
> 
> So, we need a basic DMA engine API which ensures that users of the API
> do not have to know any details about the DMA engine itself for them to
> be able to get on with their business.
For memcpy I believe that is mostly the case.
But problem arises for slave-dma partly due to 
a) controllers need specific channel as only specific channel(s) can
talk to their peripheral, and today we don't have a good way to do this
across arch. (x86, arm, RIO.....)
b) some dmacs which support a generic transfer pattern but need more
information in order to get a transfer done, so some specific parameters
have to be passed. For most of drivers today we have reached a point
where we need to remove any specific params introduced (chan->private).
But for these controllers (RIO, MSM), it seems they would need few more
non generic parameters!!!
So we can
a) say no, don't use dmaengine APIs and invent your own stuff
b) try to accommodate while keeping dmaengine neutral.
> 
> Now, if we start allowing a 'void *' per-transfer random pointer, then
> what will happen is that we'll end up with people abusing it for passing
> other stuff, maybe such as DMA request lines because they don't want to
> bother with virtual channels in their DMA engine.  At that point, the
> peripheral drivers gain knowledge about the DMA engine they're attached
> to, and it becomes impossible to reuse them without resorting to ifdeffery
> in the peripheral drivers.
Yes that was my concern too which was listed when we discussed original
patch from Alexandre and this as possible approach.
> 
> This brings up a fundamental question: if you have a DMA engine which
> has some unique specific feature, and needs extra data to use that funky
> feature passed through the generic API, is it appropriate to use the
> generic API, or does it make sense to augment the API in some way?
> 
> It might be that the peripherals of this funky feature are soo tied to
> the DMA engine that it wouldn't ever be appropriate for them to live
> with a different DMA engine.  In that case, does the DMA engine API
> actually benefit them, or does it result in an erosion of the API
> boundary, and therefore the separation of DMA engine from DMA user?
> 
> If the net result will be that the DMA engine API boundaries are blured,
> then we've lost, because we need a replacement API to do the job that we
> desperately need our existing API to be doing for us.
> 
> And that's my biggest concern about nebulous undefined 'void *'
> arguments across this API.
Okay, so now how about _defining_ these arch specific parameters in
dmaengine_arch (or some better place) and clients which are not on those
will use generic dmaengine_prep_slave_sg() as you outlined, and the ones
like RIO use

#ifdef CONFIG_RIO
struct rio_specfic_data {
...
};

static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg_rio(
	struct dma_chan *chan, struct scatterlist *sg, unsigned sg_len,
	enum dma_transfer_direction direction, unsigned long flags,
	struct rio_specfic_data *data)
{
	return chan->device->device_prep_slave_sg(chan, sg, sglen, dir, flags, (void *)data);
}
#endif

That way no client needs to pass a loose parameter. And we ensure dmacs
are using the last argument only when defined for particular arch.



-- 
~Vinod

RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sg and prep_dma_cyclic

[Bounine, Alexandre]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1952 bytes --]

On Mon, Feb 06, 2012 at 10:29 AM, Vinod Koul wrote:
> 
> On Mon, 2012-02-06 at 07:04 -0800, Bounine, Alexandre wrote:
> > I was thinking about keeping the original scatterlist for dmac
> unchanged,
> > but allocating another scatterlist in rio_dma_prep_slave_sg() and
> chaining
> > two lists together. After it passed to device specific function, it
> parses
> > first section of the chain for additional transfer parameters and use
> > following scatterlist as intended for dmac.
> hmmm, but that wouldn't make it generic for other systems like proposed
> MSM box mode..., right?

Yes, you are right. It is just another way to pass subsystem specific info
while preserving existing DMA API definitions.

> >
> > But Russell's idea (See https://lkml.org/lkml/2012/2/3/269 ) seems to
> be
> > a better way without added complexity and I am ready to take that
> path and
> > make new patches if you and Dan agree with it.
> but it still doesn't fix his concerns for the using void pointer.

At least corresponding inline functions may use specific data types
or hide the new parameter like in Russell's code example. (I believe
he forgot to pass NULL in chan->device->device_prep_slave_sg() as
the new param there).

> 
> If we agree that this is the way, then I was thinking to add arch
> specif
> calls which cast the context pointer to void for passing to dmac. The
> arch specific struct gets defined in dmaengine_arch.h <or something
> similar>. That way clients cant define their own stuff and we continue
> to be generic as well as cater to arch specific requirements.
> 

May we keep arch/subsystem specific calls within a subsystem code?
E.g. I am providing rio_dma_prep_slave_sg() which has an interface defined
in RapidIO terms plus I am filtering for an appropriate dmac. 

Alex.

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sg and prep_dma_cyclic

[Russell King]

On Mon, Feb 06, 2012 at 07:56:57AM -0800, Bounine, Alexandre wrote:
> At least corresponding inline functions may use specific data types
> or hide the new parameter like in Russell's code example. (I believe
> he forgot to pass NULL in chan->device->device_prep_slave_sg() as
> the new param there).

No I didn't - I gave a step by step approach.  Step one is to intrduce
the wrapper with no API changes at all fixing up everyone to use the
wrapper.

Step two is where the call in struct dma_device changes.

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

[PATCH 02/11] dmaengine/drivers: add context parameter for DMA_SLAVE and DMA_CYCLIC

[Alexandre Bounine]

Add new context parameter to DMA drivers that implement DMA_SLAVE
and DMA_CYCLIC interfaces.

Currently existing drivers simply ignore this parameter.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Russell King <rmk@arm.linux.org.uk> 
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: Viresh Kumar <viresh.kumar@st.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Zhang Wei <zw@zh-kernel.org>
Cc: Barry Song <baohua.song@csr.com>
Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Cc: Narayanan G <narayanan.gopalakrishnan@stericsson.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Rabin Vincent <rabin.vincent@stericsson.com>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
---
 arch/arm/plat-nomadik/include/plat/ste_dma40.h |    2 +-
 drivers/dma/amba-pl08x.c                       |    2 +-
 drivers/dma/at_hdmac.c                         |    7 +++++--
 drivers/dma/coh901318.c                        |    2 +-
 drivers/dma/dw_dmac.c                          |    2 +-
 drivers/dma/ep93xx_dma.c                       |    6 ++++--
 drivers/dma/fsldma.c                           |    4 +++-
 drivers/dma/imx-dma.c                          |    5 +++--
 drivers/dma/imx-sdma.c                         |    5 +++--
 drivers/dma/intel_mid_dma.c                    |    3 ++-
 drivers/dma/ipu/ipu_idmac.c                    |    3 ++-
 drivers/dma/mxs-dma.c                          |    5 +++--
 drivers/dma/pch_dma.c                          |    3 ++-
 drivers/dma/pl330.c                            |    5 +++--
 drivers/dma/shdma.c                            |    3 ++-
 drivers/dma/sirf-dma.c                         |    2 +-
 drivers/dma/ste_dma40.c                        |    5 +++--
 drivers/dma/timb_dma.c                         |    3 ++-
 drivers/dma/txx9dmac.c                         |    2 +-
 19 files changed, 43 insertions(+), 26 deletions(-)

diff --git a/arch/arm/plat-nomadik/include/plat/ste_dma40.h b/arch/arm/plat-nomadik/include/plat/ste_dma40.h
index fd0ee84..908a934 100644
--- a/arch/arm/plat-nomadik/include/plat/ste_dma40.h
+++ b/arch/arm/plat-nomadik/include/plat/ste_dma40.h
@@ -201,7 +201,7 @@ dma_async_tx_descriptor *stedma40_slave_mem(struct dma_chan *chan,
 	sg.length = size;
 
 	return chan->device->device_prep_slave_sg(chan, &sg, 1,
-						  direction, flags);
+						  direction, flags, NULL);
 }
 
 #else
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 8a28158..776f9e2 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -1326,7 +1326,7 @@ static struct dma_async_tx_descriptor *pl08x_prep_dma_memcpy(
 static struct dma_async_tx_descriptor *pl08x_prep_slave_sg(
 		struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
-		unsigned long flags)
+		unsigned long flags, void *context)
 {
 	struct pl08x_dma_chan *plchan = to_pl08x_chan(chan);
 	struct pl08x_driver_data *pl08x = plchan->host;
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 97f87b2..4ca746a 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -659,11 +659,12 @@ err_desc_get:
  * @sg_len: number of entries in @scatterlist
  * @direction: DMA direction
  * @flags: tx descriptor status flags
+ * @context: transaction-specific context
  */
 static struct dma_async_tx_descriptor *
 atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
-		unsigned long flags)
+		unsigned long flags, void *context)
 {
 	struct at_dma_chan	*atchan = to_at_dma_chan(chan);
 	struct at_dma_slave	*atslave = chan->private;
@@ -860,10 +861,12 @@ atc_dma_cyclic_fill_desc(struct at_dma_slave *atslave, struct at_desc *desc,
  * @buf_len: total number of bytes for the entire buffer
  * @period_len: number of bytes for each period
  * @direction: transfer direction, to or from device
+ * @context: transaction-specific context
  */
 static struct dma_async_tx_descriptor *
 atc_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
-		size_t period_len, enum dma_transfer_direction direction)
+		size_t period_len, enum dma_transfer_direction direction,
+		void *context)
 {
 	struct at_dma_chan	*atchan = to_at_dma_chan(chan);
 	struct at_dma_slave	*atslave = chan->private;
diff --git a/drivers/dma/coh901318.c b/drivers/dma/coh901318.c
index d65a718..f42b54e 100644
--- a/drivers/dma/coh901318.c
+++ b/drivers/dma/coh901318.c
@@ -1035,7 +1035,7 @@ coh901318_prep_memcpy(struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
 static struct dma_async_tx_descriptor *
 coh901318_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 			unsigned int sg_len, enum dma_transfer_direction direction,
-			unsigned long flags)
+			unsigned long flags, void *context)
 {
 	struct coh901318_chan *cohc = to_coh901318_chan(chan);
 	struct coh901318_lli *lli;
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 9b592b0..058bddf 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -731,7 +731,7 @@ err_desc_get:
 static struct dma_async_tx_descriptor *
 dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
-		unsigned long flags)
+		unsigned long flags, void *context)
 {
 	struct dw_dma_chan	*dwc = to_dw_dma_chan(chan);
 	struct dw_dma_slave	*dws = chan->private;
diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
index 59e7a96..613c9ff 100644
--- a/drivers/dma/ep93xx_dma.c
+++ b/drivers/dma/ep93xx_dma.c
@@ -983,13 +983,14 @@ fail:
  * @sg_len: number of entries in @sgl
  * @dir: direction of tha DMA transfer
  * @flags: flags for the descriptor
+ * @context: transaction-specific context
  *
  * Returns a valid DMA descriptor or %NULL in case of failure.
  */
 static struct dma_async_tx_descriptor *
 ep93xx_dma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 			 unsigned int sg_len, enum dma_transfer_direction dir,
-			 unsigned long flags)
+			 unsigned long flags, void *context)
 {
 	struct ep93xx_dma_chan *edmac = to_ep93xx_dma_chan(chan);
 	struct ep93xx_dma_desc *desc, *first;
@@ -1056,6 +1057,7 @@ fail:
  * @buf_len: length of the buffer (in bytes)
  * @period_len: lenght of a single period
  * @dir: direction of the operation
+ * @context: operation-specific context
  *
  * Prepares a descriptor for cyclic DMA operation. This means that once the
  * descriptor is submitted, we will be submitting in a @period_len sized
@@ -1068,7 +1070,7 @@ fail:
 static struct dma_async_tx_descriptor *
 ep93xx_dma_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t dma_addr,
 			   size_t buf_len, size_t period_len,
-			   enum dma_transfer_direction dir)
+			   enum dma_transfer_direction dir, void *context)
 {
 	struct ep93xx_dma_chan *edmac = to_ep93xx_dma_chan(chan);
 	struct ep93xx_dma_desc *desc, *first;
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index b98070c..1cbc934 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -765,6 +765,7 @@ fail:
  * @sg_len: number of entries in @scatterlist
  * @direction: DMA direction
  * @flags: DMAEngine flags
+ * @context: transaction-specific context
  *
  * Prepare a set of descriptors for a DMA_SLAVE transaction. Following the
  * DMA_SLAVE API, this gets the device-specific information from the
@@ -772,7 +773,8 @@ fail:
  */
 static struct dma_async_tx_descriptor *fsl_dma_prep_slave_sg(
 	struct dma_chan *dchan, struct scatterlist *sgl, unsigned int sg_len,
-	enum dma_transfer_direction direction, unsigned long flags)
+	enum dma_transfer_direction direction, unsigned long flags,
+	void *context)
 {
 	/*
 	 * This operation is not supported on the Freescale DMA controller
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index e4383ee..42d5dc5 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -225,7 +225,7 @@ static void imxdma_free_chan_resources(struct dma_chan *chan)
 static struct dma_async_tx_descriptor *imxdma_prep_slave_sg(
 		struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
-		unsigned long flags)
+		unsigned long flags, void *context)
 {
 	struct imxdma_channel *imxdmac = to_imxdma_chan(chan);
 	struct scatterlist *sg;
@@ -271,7 +271,8 @@ static struct dma_async_tx_descriptor *imxdma_prep_slave_sg(
 
 static struct dma_async_tx_descriptor *imxdma_prep_dma_cyclic(
 		struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
-		size_t period_len, enum dma_transfer_direction direction)
+		size_t period_len, enum dma_transfer_direction direction,
+		void *context)
 {
 	struct imxdma_channel *imxdmac = to_imxdma_chan(chan);
 	struct imxdma_engine *imxdma = imxdmac->imxdma;
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index a8af379..21b1ab7 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -917,7 +917,7 @@ static void sdma_free_chan_resources(struct dma_chan *chan)
 static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
 		struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
-		unsigned long flags)
+		unsigned long flags, void *context)
 {
 	struct sdma_channel *sdmac = to_sdma_chan(chan);
 	struct sdma_engine *sdma = sdmac->sdma;
@@ -1015,7 +1015,8 @@ err_out:
 
 static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
 		struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
-		size_t period_len, enum dma_transfer_direction direction)
+		size_t period_len, enum dma_transfer_direction direction,
+		void *context)
 {
 	struct sdma_channel *sdmac = to_sdma_chan(chan);
 	struct sdma_engine *sdma = sdmac->sdma;
diff --git a/drivers/dma/intel_mid_dma.c b/drivers/dma/intel_mid_dma.c
index 74f70aa..3bfc225 100644
--- a/drivers/dma/intel_mid_dma.c
+++ b/drivers/dma/intel_mid_dma.c
@@ -732,13 +732,14 @@ err_desc_get:
  * @sg_len: length of sg txn
  * @direction: DMA transfer dirtn
  * @flags: DMA flags
+ * @context: txn-specific context
  *
  * Prepares LLI based periphral transfer
  */
 static struct dma_async_tx_descriptor *intel_mid_dma_prep_slave_sg(
 			struct dma_chan *chan, struct scatterlist *sgl,
 			unsigned int sg_len, enum dma_transfer_direction direction,
-			unsigned long flags)
+			unsigned long flags, void *context)
 {
 	struct intel_mid_dma_chan *midc = NULL;
 	struct intel_mid_dma_slave *mids = NULL;
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index 6212b16..aadd57c 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1341,7 +1341,8 @@ static void ipu_gc_tasklet(unsigned long arg)
 /* Allocate and initialise a transfer descriptor. */
 static struct dma_async_tx_descriptor *idmac_prep_slave_sg(struct dma_chan *chan,
 		struct scatterlist *sgl, unsigned int sg_len,
-		enum dma_transfer_direction direction, unsigned long tx_flags)
+		enum dma_transfer_direction direction, unsigned long tx_flags,
+		void *context)
 {
 	struct idmac_channel *ichan = to_idmac_chan(chan);
 	struct idmac_tx_desc *desc = NULL;
diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index b06cd4c..3e65974 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -352,7 +352,7 @@ static void mxs_dma_free_chan_resources(struct dma_chan *chan)
 static struct dma_async_tx_descriptor *mxs_dma_prep_slave_sg(
 		struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
-		unsigned long append)
+		unsigned long append, void *context)
 {
 	struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(chan);
 	struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma;
@@ -447,7 +447,8 @@ err_out:
 
 static struct dma_async_tx_descriptor *mxs_dma_prep_dma_cyclic(
 		struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
-		size_t period_len, enum dma_transfer_direction direction)
+		size_t period_len, enum dma_transfer_direction direction,
+		void *context)
 {
 	struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(chan);
 	struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma;
diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index 823f581..7ad3d79 100644
--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -607,7 +607,8 @@ static void pd_issue_pending(struct dma_chan *chan)
 
 static struct dma_async_tx_descriptor *pd_prep_slave_sg(struct dma_chan *chan,
 			struct scatterlist *sgl, unsigned int sg_len,
-			enum dma_transfer_direction direction, unsigned long flags)
+			enum dma_transfer_direction direction,
+			unsigned long flags, void *context)
 {
 	struct pch_dma_chan *pd_chan = to_pd_chan(chan);
 	struct pch_dma_slave *pd_slave = chan->private;
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index b8ec03e..1e8dee6 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -621,7 +621,8 @@ static inline int get_burst_len(struct dma_pl330_desc *desc, size_t len)
 
 static struct dma_async_tx_descriptor *pl330_prep_dma_cyclic(
 		struct dma_chan *chan, dma_addr_t dma_addr, size_t len,
-		size_t period_len, enum dma_transfer_direction direction)
+		size_t period_len, enum dma_transfer_direction direction,
+		void *context)
 {
 	struct dma_pl330_desc *desc;
 	struct dma_pl330_chan *pch = to_pchan(chan);
@@ -711,7 +712,7 @@ pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dst,
 static struct dma_async_tx_descriptor *
 pl330_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
-		unsigned long flg)
+		unsigned long flg, void *context)
 {
 	struct dma_pl330_desc *first, *desc = NULL;
 	struct dma_pl330_chan *pch = to_pchan(chan);
diff --git a/drivers/dma/shdma.c b/drivers/dma/shdma.c
index 54043cd..8b15e06 100644
--- a/drivers/dma/shdma.c
+++ b/drivers/dma/shdma.c
@@ -673,7 +673,8 @@ static struct dma_async_tx_descriptor *sh_dmae_prep_memcpy(
 
 static struct dma_async_tx_descriptor *sh_dmae_prep_slave_sg(
 	struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
-	enum dma_transfer_direction direction, unsigned long flags)
+	enum dma_transfer_direction direction, unsigned long flags,
+	void *context)
 {
 	struct sh_dmae_slave *param;
 	struct sh_dmae_chan *sh_chan;
diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
index 2333810..b899a86 100644
--- a/drivers/dma/sirf-dma.c
+++ b/drivers/dma/sirf-dma.c
@@ -497,7 +497,7 @@ err_dir:
 static struct dma_async_tx_descriptor *
 sirfsoc_dma_prep_cyclic(struct dma_chan *chan, dma_addr_t addr,
 	size_t buf_len, size_t period_len,
-	enum dma_transfer_direction direction)
+	enum dma_transfer_direction direction, void *context)
 {
 	struct sirfsoc_dma_chan *schan = dma_chan_to_sirfsoc_dma_chan(chan);
 	struct sirfsoc_dma_desc *sdesc = NULL;
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index cc5ecbc..3cbf78e 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2299,7 +2299,8 @@ static struct dma_async_tx_descriptor *d40_prep_slave_sg(struct dma_chan *chan,
 							 struct scatterlist *sgl,
 							 unsigned int sg_len,
 							 enum dma_transfer_direction direction,
-							 unsigned long dma_flags)
+							 unsigned long dma_flags,
+							 void *context)
 {
 	if (direction != DMA_DEV_TO_MEM && direction != DMA_MEM_TO_DEV)
 		return NULL;
@@ -2310,7 +2311,7 @@ static struct dma_async_tx_descriptor *d40_prep_slave_sg(struct dma_chan *chan,
 static struct dma_async_tx_descriptor *
 dma40_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t dma_addr,
 		     size_t buf_len, size_t period_len,
-		     enum dma_transfer_direction direction)
+		     enum dma_transfer_direction direction, void *context)
 {
 	unsigned int periods = buf_len / period_len;
 	struct dma_async_tx_descriptor *txd;
diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
index a6f9c16..a4c61ed 100644
--- a/drivers/dma/timb_dma.c
+++ b/drivers/dma/timb_dma.c
@@ -558,7 +558,8 @@ static void td_issue_pending(struct dma_chan *chan)
 
 static struct dma_async_tx_descriptor *td_prep_slave_sg(struct dma_chan *chan,
 	struct scatterlist *sgl, unsigned int sg_len,
-	enum dma_transfer_direction direction, unsigned long flags)
+	enum dma_transfer_direction direction, unsigned long flags,
+	void *context)
 {
 	struct timb_dma_chan *td_chan =
 		container_of(chan, struct timb_dma_chan, chan);
diff --git a/drivers/dma/txx9dmac.c b/drivers/dma/txx9dmac.c
index 6122c36..fa66ebb 100644
--- a/drivers/dma/txx9dmac.c
+++ b/drivers/dma/txx9dmac.c
@@ -846,7 +846,7 @@ txx9dmac_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
 static struct dma_async_tx_descriptor *
 txx9dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
-		unsigned long flags)
+		unsigned long flags, void *context)
 {
 	struct txx9dmac_chan *dc = to_txx9dmac_chan(chan);
 	struct txx9dmac_dev *ddev = dc->ddev;
-- 
1.7.8.4

[PATCH 03/11] plat-samsung: add context parameter for DMA_SLAVE and DMA_CYCLIC

[Alexandre Bounine]

Fixup for added context parameter to DMA_SLAVE and DMA_CYCLIC interfaces.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Russell King <linux@arm.linux.org.uk>
---
 arch/arm/plat-samsung/dma-ops.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-samsung/dma-ops.c b/arch/arm/plat-samsung/dma-ops.c
index 0747c77..726dc30 100644
--- a/arch/arm/plat-samsung/dma-ops.c
+++ b/arch/arm/plat-samsung/dma-ops.c
@@ -80,11 +80,12 @@ static int samsung_dmadev_prepare(unsigned ch,
 		sg_dma_address(&sg) = info->buf;
 
 		desc = chan->device->device_prep_slave_sg(chan,
-			&sg, 1, info->direction, DMA_PREP_INTERRUPT);
+			&sg, 1, info->direction, DMA_PREP_INTERRUPT, NULL);
 		break;
 	case DMA_CYCLIC:
 		desc = chan->device->device_prep_dma_cyclic(chan,
-			info->buf, info->len, info->period, info->direction);
+			info->buf, info->len, info->period, info->direction,
+			NULL);
 		break;
 	default:
 		dev_err(&chan->dev->device, "unsupported format\n");
-- 
1.7.8.4

[PATCH 04/11] media/video: add new context parameter for DMA_SLAVE calls

[Alexandre Bounine]

Fixup for calls affected by adding the new context parameter to DMA_SLAVE
and DMA_CYCLIC interfaces.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Alberto Panizzo <maramaopercheseimorto@gmail.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/media/video/mx3_camera.c |    2 +-
 drivers/media/video/timblogiw.c  |    2 +-
 drivers/video/mx3fb.c            |    6 ++++--
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 7452277..60b64ed4 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -288,7 +288,7 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
 
 		txd = ichan->dma_chan.device->device_prep_slave_sg(
 			&ichan->dma_chan, sg, 1, DMA_DEV_TO_MEM,
-			DMA_PREP_INTERRUPT);
+			DMA_PREP_INTERRUPT, NULL);
 		if (!txd)
 			goto error;
 
diff --git a/drivers/media/video/timblogiw.c b/drivers/media/video/timblogiw.c
index 4ed1c7c2..14aa89d 100644
--- a/drivers/media/video/timblogiw.c
+++ b/drivers/media/video/timblogiw.c
@@ -566,7 +566,7 @@ static void buffer_queue(struct videobuf_queue *vq, struct videobuf_buffer *vb)
 
 	desc = fh->chan->device->device_prep_slave_sg(fh->chan,
 		buf->sg, sg_elems, DMA_DEV_TO_MEM,
-		DMA_PREP_INTERRUPT | DMA_COMPL_SKIP_SRC_UNMAP);
+		DMA_PREP_INTERRUPT | DMA_COMPL_SKIP_SRC_UNMAP, NULL);
 	if (!desc) {
 		spin_lock_irq(&fh->queue_lock);
 		list_del_init(&vb->queue);
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index 727a514..81a33ae 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -338,7 +338,8 @@ static void sdc_enable_channel(struct mx3fb_info *mx3_fbi)
 	/* This enables the channel */
 	if (mx3_fbi->cookie < 0) {
 		mx3_fbi->txd = dma_chan->device->device_prep_slave_sg(dma_chan,
-		      &mx3_fbi->sg[0], 1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT);
+		      &mx3_fbi->sg[0], 1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT,
+		      NULL);
 		if (!mx3_fbi->txd) {
 			dev_err(mx3fb->dev, "Cannot allocate descriptor on %d\n",
 				dma_chan->chan_id);
@@ -1092,7 +1093,8 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
 		async_tx_ack(mx3_fbi->txd);
 
 	txd = dma_chan->device->device_prep_slave_sg(dma_chan, sg +
-		mx3_fbi->cur_ipu_buf, 1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT);
+		mx3_fbi->cur_ipu_buf, 1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT,
+		NULL);
 	if (!txd) {
 		dev_err(fbi->device,
 			"Error preparing a DMA transaction descriptor.\n");
-- 
1.7.8.4

[PATCH 05/11] mmc/host: add context parameter for DMA_SLAVE and DMA_CYCLIC

[Alexandre Bounine]

Fixups for calls affected by adding the new context parameter to DMA_SLAVE
and DMA_CYCLIC interfaces.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Ulf Hansson <ulf.hansson@stericsson.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Anton Vorontsov <cbouatmailru@gmail.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Viresh Kumar <viresh.kumar@st.com>
---
 drivers/mmc/host/atmel-mci.c    |    2 +-
 drivers/mmc/host/mmci.c         |    2 +-
 drivers/mmc/host/mxcmmc.c       |    2 +-
 drivers/mmc/host/mxs-mmc.c      |    2 +-
 drivers/mmc/host/sh_mmcif.c     |    6 ++++--
 drivers/mmc/host/tmio_mmc_dma.c |    4 ++--
 6 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index fcfe1eb..8e2d1f9 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -874,7 +874,7 @@ atmci_prepare_data_dma(struct atmel_mci *host, struct mmc_data *data)
 
 	desc = chan->device->device_prep_slave_sg(chan,
 			data->sg, sglen, slave_dirn,
-			DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+			DMA_PREP_INTERRUPT | DMA_CTRL_ACK, NULL);
 	if (!desc)
 		goto unmap_exit;
 
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 0d955ff..39b574d 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -412,7 +412,7 @@ static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
 
 	dmaengine_slave_config(chan, &conf);
 	desc = device->device_prep_slave_sg(chan, data->sg, nr_sg,
-					    conf.direction, DMA_CTRL_ACK);
+					    conf.direction, DMA_CTRL_ACK, NULL);
 	if (!desc)
 		goto unmap_exit;
 
diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
index 4184b79..870f94f 100644
--- a/drivers/mmc/host/mxcmmc.c
+++ b/drivers/mmc/host/mxcmmc.c
@@ -256,7 +256,7 @@ static int mxcmci_setup_data(struct mxcmci_host *host, struct mmc_data *data)
 
 	host->desc = host->dma->device->device_prep_slave_sg(host->dma,
 		data->sg, data->sg_len, slave_dirn,
-		DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+		DMA_PREP_INTERRUPT | DMA_CTRL_ACK, NULL);
 
 	if (!host->desc) {
 		dma_unmap_sg(host->dma->device->dev, data->sg, data->sg_len,
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 382c835..2bd7066 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -325,7 +325,7 @@ static struct dma_async_tx_descriptor *mxs_mmc_prep_dma(
 	}
 
 	desc = host->dmach->device->device_prep_slave_sg(host->dmach,
-				sgl, sg_len, host->slave_dirn, append);
+				sgl, sg_len, host->slave_dirn, append, NULL);
 	if (desc) {
 		desc->callback = mxs_mmc_dma_irq_callback;
 		desc->callback_param = host;
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index f5d8b53..deff2fa 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -286,7 +286,8 @@ static void sh_mmcif_start_dma_rx(struct sh_mmcif_host *host)
 	if (ret > 0) {
 		host->dma_active = true;
 		desc = chan->device->device_prep_slave_sg(chan, sg, ret,
-			DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+			DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+			NULL);
 	}
 
 	if (desc) {
@@ -335,7 +336,8 @@ static void sh_mmcif_start_dma_tx(struct sh_mmcif_host *host)
 	if (ret > 0) {
 		host->dma_active = true;
 		desc = chan->device->device_prep_slave_sg(chan, sg, ret,
-			DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+			DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+			NULL);
 	}
 
 	if (desc) {
diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index 7a6e6cc..3fb4286 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -77,7 +77,7 @@ static void tmio_mmc_start_dma_rx(struct tmio_mmc_host *host)
 	ret = dma_map_sg(chan->device->dev, sg, host->sg_len, DMA_FROM_DEVICE);
 	if (ret > 0)
 		desc = chan->device->device_prep_slave_sg(chan, sg, ret,
-			DMA_DEV_TO_MEM, DMA_CTRL_ACK);
+			DMA_DEV_TO_MEM, DMA_CTRL_ACK, NULL);
 
 	if (desc) {
 		cookie = dmaengine_submit(desc);
@@ -158,7 +158,7 @@ static void tmio_mmc_start_dma_tx(struct tmio_mmc_host *host)
 	ret = dma_map_sg(chan->device->dev, sg, host->sg_len, DMA_TO_DEVICE);
 	if (ret > 0)
 		desc = chan->device->device_prep_slave_sg(chan, sg, ret,
-			DMA_MEM_TO_DEV, DMA_CTRL_ACK);
+			DMA_MEM_TO_DEV, DMA_CTRL_ACK, NULL);
 
 	if (desc) {
 		cookie = dmaengine_submit(desc);
-- 
1.7.8.4

Re: [PATCH 05/11] mmc/host: add context parameter for DMA_SLAVE and DMA_CYCLIC

[Ulf Hansson]

Alexandre Bounine wrote:
> Fixups for calls affected by adding the new context parameter to DMA_SLAVE
> and DMA_CYCLIC interfaces.
> 
> Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> Cc: Ian Molton <ian@mnementh.co.uk>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Ulf Hansson <ulf.hansson@stericsson.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Anton Vorontsov <cbouatmailru@gmail.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
> Cc: Viresh Kumar <viresh.kumar@st.com>
> ---
>  drivers/mmc/host/atmel-mci.c    |    2 +-
>  drivers/mmc/host/mmci.c         |    2 +-
>  drivers/mmc/host/mxcmmc.c       |    2 +-
>  drivers/mmc/host/mxs-mmc.c      |    2 +-
>  drivers/mmc/host/sh_mmcif.c     |    6 ++++--
>  drivers/mmc/host/tmio_mmc_dma.c |    4 ++--
>  6 files changed, 10 insertions(+), 8 deletions(-)
> 

I have not been following the patches for changing the API. But does 
that mean that before this patch we are getting compile errors/warnings? 
Is so, the complete API change should have been included in this patch 
as well, right?

Otherwise, looks good to me!

Acked-by: Ulf Hansson <ulf.hansson@stericsson.com>

RE: [PATCH 05/11] mmc/host: add context parameter for DMA_SLAVE and DMA_CYCLIC

[Bounine, Alexandre]

On Fri, Feb 03, 2012 at 4:20 AM, Ulf Hansson wrote:
> 
> Alexandre Bounine wrote:
> > Fixups for calls affected by adding the new context parameter to
DMA_SLAVE
> > and DMA_CYCLIC interfaces.
... skip ...
> >
> 
> I have not been following the patches for changing the API. But does
> that mean that before this patch we are getting compile
> errors/warnings?

No. This is a new API change in [01/11]. This change was in discussion
some time ago.
Now I am getting back to it. See https://lkml.org/lkml/2012/2/2/461 for
more details.

> Is so, the complete API change should have been included in this patch
> as well, right?
> 
Yes, this patch better to be submitted as a single patch combined with
the proposed API change. Sorry for inconvenience.
If these API changes will be approved I will resubmit these changes as
one patch.

Alex.

Re: [PATCH 05/11] mmc/host: add context parameter for DMA_SLAVE and DMA_CYCLIC

[Russell King]

On Fri, Feb 03, 2012 at 08:52:07AM -0800, Bounine, Alexandre wrote:
> If these API changes will be approved I will resubmit these changes as
> one patch.

I'd like to suggest an alternative approach, if you still want to add a
void * parameter to this.

1. A patch which adds this, and convert users over to it:

static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
	struct dma_chan *chan, struct scatterlist *sg, unsigned sg_len,
	enum dma_transfer_direction direction, unsigned long flags)
{
	return chan->device->device_prep_slave_sg(chan, sg, sglen, dir, flags);
}

2. Change device->device_prep_slave_sg() to have a new prototype, and
   update the above inline function to cope with the change.  This API
   change is then restricted to just the DMA engine code.

3. Introduce a new inline function to deal with rapidio slave sg
   submission.

This means all drivers which aren't capable of using the special rapidio
features get to ignore the new details about rapidio entirely.

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

RE: [PATCH 05/11] mmc/host: add context parameter for DMA_SLAVEand DMA_CYCLIC

[Bounine, Alexandre]

On Fri, Feb 03, 2012 at 12:02 PM, Russell King wrote:
> 
> On Fri, Feb 03, 2012 at 08:52:07AM -0800, Bounine, Alexandre wrote:
> > If these API changes will be approved I will resubmit these changes
> > as one patch.
> 
> I'd like to suggest an alternative approach, if you still want to add
a
> void * parameter to this.
> 
> 1. A patch which adds this, and convert users over to it:
> 
> static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
> 	struct dma_chan *chan, struct scatterlist *sg, unsigned sg_len,
> 	enum dma_transfer_direction direction, unsigned long flags)
> {
> 	return chan->device->device_prep_slave_sg(chan, sg, sglen, dir,
> flags);
> }
> 
> 2. Change device->device_prep_slave_sg() to have a new prototype, and
>    update the above inline function to cope with the change.  This API
>    change is then restricted to just the DMA engine code.
> 
> 3. Introduce a new inline function to deal with rapidio slave sg
>    submission.
> 
> This means all drivers which aren't capable of using the special
> rapidio
> features get to ignore the new details about rapidio entirely.
> 

This looks like a great improvement to the original proposal.
I will just add another inline function (with specific type for
parameter)
inside of RapidIO subsystem.

If DMA engine maintainers agree with this approach, I will build a new
patch within next week (changes to existing drivers first, RapidIO to
follow).

Thank you,

Alex.

[PATCH 06/11] nand/gpmi: add context parameter to prep_slave_sg calls

[Alexandre Bounine]

Fixups for calls affected by adding the new context parameter to DMA_SLAVE
and DMA_CYCLIC interfaces.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Huang Shijie <b32955@freescale.com>
Cc: Artem Bityutskiy <artem.bityutskiy@intel.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c |   25 +++++++++++++++----------
 1 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 7f68042..c52964e 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -827,7 +827,8 @@ int gpmi_send_command(struct gpmi_nand_data *this)
 	pio[1] = pio[2] = 0;
 	desc = channel->device->device_prep_slave_sg(channel,
 					(struct scatterlist *)pio,
-					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
+					ARRAY_SIZE(pio), DMA_TRANS_NONE,
+					0, NULL);
 	if (!desc) {
 		pr_err("step 1 error\n");
 		return -1;
@@ -839,7 +840,7 @@ int gpmi_send_command(struct gpmi_nand_data *this)
 	sg_init_one(sgl, this->cmd_buffer, this->command_length);
 	dma_map_sg(this->dev, sgl, 1, DMA_TO_DEVICE);
 	desc = channel->device->device_prep_slave_sg(channel,
-					sgl, 1, DMA_MEM_TO_DEV, 1);
+					sgl, 1, DMA_MEM_TO_DEV, 1, NULL);
 	if (!desc) {
 		pr_err("step 2 error\n");
 		return -1;
@@ -872,7 +873,8 @@ int gpmi_send_data(struct gpmi_nand_data *this)
 	pio[1] = 0;
 	desc = channel->device->device_prep_slave_sg(channel,
 					(struct scatterlist *)pio,
-					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
+					ARRAY_SIZE(pio), DMA_TRANS_NONE,
+					0, NULL);
 	if (!desc) {
 		pr_err("step 1 error\n");
 		return -1;
@@ -881,7 +883,7 @@ int gpmi_send_data(struct gpmi_nand_data *this)
 	/* [2] send DMA request */
 	prepare_data_dma(this, DMA_TO_DEVICE);
 	desc = channel->device->device_prep_slave_sg(channel, &this->data_sgl,
-						1, DMA_MEM_TO_DEV, 1);
+						1, DMA_MEM_TO_DEV, 1, NULL);
 	if (!desc) {
 		pr_err("step 2 error\n");
 		return -1;
@@ -908,7 +910,8 @@ int gpmi_read_data(struct gpmi_nand_data *this)
 	pio[1] = 0;
 	desc = channel->device->device_prep_slave_sg(channel,
 					(struct scatterlist *)pio,
-					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
+					ARRAY_SIZE(pio), DMA_TRANS_NONE,
+					0, NULL);
 	if (!desc) {
 		pr_err("step 1 error\n");
 		return -1;
@@ -917,7 +920,7 @@ int gpmi_read_data(struct gpmi_nand_data *this)
 	/* [2] : send DMA request */
 	prepare_data_dma(this, DMA_FROM_DEVICE);
 	desc = channel->device->device_prep_slave_sg(channel, &this->data_sgl,
-						1, DMA_DEV_TO_MEM, 1);
+						1, DMA_DEV_TO_MEM, 1, NULL);
 	if (!desc) {
 		pr_err("step 2 error\n");
 		return -1;
@@ -964,7 +967,8 @@ int gpmi_send_page(struct gpmi_nand_data *this,
 
 	desc = channel->device->device_prep_slave_sg(channel,
 					(struct scatterlist *)pio,
-					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
+					ARRAY_SIZE(pio), DMA_TRANS_NONE,
+					0, NULL);
 	if (!desc) {
 		pr_err("step 2 error\n");
 		return -1;
@@ -999,7 +1003,7 @@ int gpmi_read_page(struct gpmi_nand_data *this,
 	pio[1] = 0;
 	desc = channel->device->device_prep_slave_sg(channel,
 				(struct scatterlist *)pio, 2,
-				DMA_TRANS_NONE, 0);
+				DMA_TRANS_NONE, 0, NULL);
 	if (!desc) {
 		pr_err("step 1 error\n");
 		return -1;
@@ -1028,7 +1032,8 @@ int gpmi_read_page(struct gpmi_nand_data *this,
 	pio[5] = auxiliary;
 	desc = channel->device->device_prep_slave_sg(channel,
 					(struct scatterlist *)pio,
-					ARRAY_SIZE(pio), DMA_TRANS_NONE, 1);
+					ARRAY_SIZE(pio), DMA_TRANS_NONE,
+					1, NULL);
 	if (!desc) {
 		pr_err("step 2 error\n");
 		return -1;
@@ -1047,7 +1052,7 @@ int gpmi_read_page(struct gpmi_nand_data *this,
 	pio[1] = 0;
 	desc = channel->device->device_prep_slave_sg(channel,
 				(struct scatterlist *)pio, 2,
-				DMA_TRANS_NONE, 1);
+				DMA_TRANS_NONE, 1, NULL);
 	if (!desc) {
 		pr_err("step 3 error\n");
 		return -1;
-- 
1.7.8.4

Re: [PATCH 06/11] nand/gpmi: add context parameter to prep_slave_sg calls

[Marek Vasut]

> Fixups for calls affected by adding the new context parameter to DMA_SLAVE
> and DMA_CYCLIC interfaces.

Thanks!
> 
> Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Marek Vasut <marek.vasut@gmail.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Huang Shijie <b32955@freescale.com>
> Cc: Artem Bityutskiy <artem.bityutskiy@intel.com>
> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c |   25 +++++++++++++++----------
>  1 files changed, 15 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c index 7f68042..c52964e 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> @@ -827,7 +827,8 @@ int gpmi_send_command(struct gpmi_nand_data *this)
>  	pio[1] = pio[2] = 0;
>  	desc = channel->device->device_prep_slave_sg(channel,
>  					(struct scatterlist *)pio,
> -					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
> +					ARRAY_SIZE(pio), DMA_TRANS_NONE,
> +					0, NULL);
>  	if (!desc) {
>  		pr_err("step 1 error\n");
>  		return -1;
> @@ -839,7 +840,7 @@ int gpmi_send_command(struct gpmi_nand_data *this)
>  	sg_init_one(sgl, this->cmd_buffer, this->command_length);
>  	dma_map_sg(this->dev, sgl, 1, DMA_TO_DEVICE);
>  	desc = channel->device->device_prep_slave_sg(channel,
> -					sgl, 1, DMA_MEM_TO_DEV, 1);
> +					sgl, 1, DMA_MEM_TO_DEV, 1, NULL);
>  	if (!desc) {
>  		pr_err("step 2 error\n");
>  		return -1;
> @@ -872,7 +873,8 @@ int gpmi_send_data(struct gpmi_nand_data *this)
>  	pio[1] = 0;
>  	desc = channel->device->device_prep_slave_sg(channel,
>  					(struct scatterlist *)pio,
> -					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
> +					ARRAY_SIZE(pio), DMA_TRANS_NONE,
> +					0, NULL);
>  	if (!desc) {
>  		pr_err("step 1 error\n");
>  		return -1;
> @@ -881,7 +883,7 @@ int gpmi_send_data(struct gpmi_nand_data *this)
>  	/* [2] send DMA request */
>  	prepare_data_dma(this, DMA_TO_DEVICE);
>  	desc = channel->device->device_prep_slave_sg(channel, &this->data_sgl,
> -						1, DMA_MEM_TO_DEV, 1);
> +						1, DMA_MEM_TO_DEV, 1, NULL);
>  	if (!desc) {
>  		pr_err("step 2 error\n");
>  		return -1;
> @@ -908,7 +910,8 @@ int gpmi_read_data(struct gpmi_nand_data *this)
>  	pio[1] = 0;
>  	desc = channel->device->device_prep_slave_sg(channel,
>  					(struct scatterlist *)pio,
> -					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
> +					ARRAY_SIZE(pio), DMA_TRANS_NONE,
> +					0, NULL);
>  	if (!desc) {
>  		pr_err("step 1 error\n");
>  		return -1;
> @@ -917,7 +920,7 @@ int gpmi_read_data(struct gpmi_nand_data *this)
>  	/* [2] : send DMA request */
>  	prepare_data_dma(this, DMA_FROM_DEVICE);
>  	desc = channel->device->device_prep_slave_sg(channel, &this->data_sgl,
> -						1, DMA_DEV_TO_MEM, 1);
> +						1, DMA_DEV_TO_MEM, 1, NULL);
>  	if (!desc) {
>  		pr_err("step 2 error\n");
>  		return -1;
> @@ -964,7 +967,8 @@ int gpmi_send_page(struct gpmi_nand_data *this,
> 
>  	desc = channel->device->device_prep_slave_sg(channel,
>  					(struct scatterlist *)pio,
> -					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
> +					ARRAY_SIZE(pio), DMA_TRANS_NONE,
> +					0, NULL);
>  	if (!desc) {
>  		pr_err("step 2 error\n");
>  		return -1;
> @@ -999,7 +1003,7 @@ int gpmi_read_page(struct gpmi_nand_data *this,
>  	pio[1] = 0;
>  	desc = channel->device->device_prep_slave_sg(channel,
>  				(struct scatterlist *)pio, 2,
> -				DMA_TRANS_NONE, 0);
> +				DMA_TRANS_NONE, 0, NULL);
>  	if (!desc) {
>  		pr_err("step 1 error\n");
>  		return -1;
> @@ -1028,7 +1032,8 @@ int gpmi_read_page(struct gpmi_nand_data *this,
>  	pio[5] = auxiliary;
>  	desc = channel->device->device_prep_slave_sg(channel,
>  					(struct scatterlist *)pio,
> -					ARRAY_SIZE(pio), DMA_TRANS_NONE, 1);
> +					ARRAY_SIZE(pio), DMA_TRANS_NONE,
> +					1, NULL);
>  	if (!desc) {
>  		pr_err("step 2 error\n");
>  		return -1;
> @@ -1047,7 +1052,7 @@ int gpmi_read_page(struct gpmi_nand_data *this,
>  	pio[1] = 0;
>  	desc = channel->device->device_prep_slave_sg(channel,
>  				(struct scatterlist *)pio, 2,
> -				DMA_TRANS_NONE, 1);
> +				DMA_TRANS_NONE, 1, NULL);
>  	if (!desc) {
>  		pr_err("step 3 error\n");
>  		return -1;

RE: [PATCH 06/11] nand/gpmi: add context parameter to prep_slave_sg calls

[Bounine, Alexandre]

On Thu, Feb 02, 2012 at 5:14 PM, Marek Vasut wrote:
> 
> > Fixups for calls affected by adding the new context parameter to
DMA_SLAVE
> > and DMA_CYCLIC interfaces.
> 
> Thanks!
Please note that this depends on changes introduced by patch [01/11]
from the set.
The changes to DMA_SLAVE interface have not been accepted yet.
I probably had to pack all changes together as it was suggested in
comments to
other parts of this patchset.  

> >
... skip ....

[PATCH 07/11] net/ks8842: add context parameter to prep_slave_sg call

[Alexandre Bounine]

Fixups for calls affected by adding the new context parameter to DMA_SLAVE
and DMA_CYCLIC interfaces.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Dennis Aberilla <denzzzhome@yahoo.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Wan ZongShun <mcuos.com@gmail.com>
---
 drivers/net/ethernet/micrel/ks8842.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/micrel/ks8842.c b/drivers/net/ethernet/micrel/ks8842.c
index 0a85690..afc6b57 100644
--- a/drivers/net/ethernet/micrel/ks8842.c
+++ b/drivers/net/ethernet/micrel/ks8842.c
@@ -460,7 +460,7 @@ static int ks8842_tx_frame_dma(struct sk_buff *skb, struct net_device *netdev)
 
 	ctl->adesc = ctl->chan->device->device_prep_slave_sg(ctl->chan,
 		&ctl->sg, 1, DMA_MEM_TO_DEV,
-		DMA_PREP_INTERRUPT | DMA_COMPL_SKIP_SRC_UNMAP);
+		DMA_PREP_INTERRUPT | DMA_COMPL_SKIP_SRC_UNMAP, NULL);
 	if (!ctl->adesc)
 		return NETDEV_TX_BUSY;
 
@@ -572,7 +572,7 @@ static int __ks8842_start_new_rx_dma(struct net_device *netdev)
 
 		ctl->adesc = ctl->chan->device->device_prep_slave_sg(ctl->chan,
 			sg, 1, DMA_DEV_TO_MEM,
-			DMA_PREP_INTERRUPT | DMA_COMPL_SKIP_SRC_UNMAP);
+			DMA_PREP_INTERRUPT | DMA_COMPL_SKIP_SRC_UNMAP, NULL);
 
 		if (!ctl->adesc)
 			goto out;
-- 
1.7.8.4

[PATCH 08/11] spi/serial: add context parameter for DMA_SLAVE and DMA_CYCLIC

[Alexandre Bounine]

Fixups for calls affected by adding the new context parameter to DMA_SLAVE
and DMA_CYCLIC interfaces.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/spi/spi-dw-mid.c        |    6 ++++--
 drivers/spi/spi-ep93xx.c        |    3 ++-
 drivers/spi/spi-pl022.c         |    6 ++++--
 drivers/spi/spi-topcliff-pch.c  |    6 ++++--
 drivers/tty/serial/amba-pl011.c |    6 ++++--
 drivers/tty/serial/pch_uart.c   |    5 +++--
 drivers/tty/serial/sh-sci.c     |    4 ++--
 7 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
index 8418eb0..bbb92d5 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -148,7 +148,8 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
 				&dws->tx_sgl,
 				1,
 				DMA_MEM_TO_DEV,
-				DMA_PREP_INTERRUPT | DMA_COMPL_SKIP_DEST_UNMAP);
+				DMA_PREP_INTERRUPT | DMA_COMPL_SKIP_DEST_UNMAP,
+				NULL);
 	txdesc->callback = dw_spi_dma_done;
 	txdesc->callback_param = dws;
 
@@ -170,7 +171,8 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, int cs_change)
 				&dws->rx_sgl,
 				1,
 				DMA_DEV_TO_MEM,
-				DMA_PREP_INTERRUPT | DMA_COMPL_SKIP_DEST_UNMAP);
+				DMA_PREP_INTERRUPT | DMA_COMPL_SKIP_DEST_UNMAP,
+				NULL);
 	rxdesc->callback = dw_spi_dma_done;
 	rxdesc->callback_param = dws;
 
diff --git a/drivers/spi/spi-ep93xx.c b/drivers/spi/spi-ep93xx.c
index d46e55c..fdb622d 100644
--- a/drivers/spi/spi-ep93xx.c
+++ b/drivers/spi/spi-ep93xx.c
@@ -634,7 +634,8 @@ ep93xx_spi_dma_prepare(struct ep93xx_spi *espi, enum dma_data_direction dir)
 		return ERR_PTR(-ENOMEM);
 
 	txd = chan->device->device_prep_slave_sg(chan, sgt->sgl, nents,
-						 slave_dirn, DMA_CTRL_ACK);
+						 slave_dirn, DMA_CTRL_ACK,
+						 NULL);
 	if (!txd) {
 		dma_unmap_sg(chan->device->dev, sgt->sgl, sgt->nents, dir);
 		return ERR_PTR(-ENOMEM);
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 2f9cb43..1e1e0a4 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -1042,7 +1042,8 @@ static int configure_dma(struct pl022 *pl022)
 				      pl022->sgt_rx.sgl,
 				      rx_sglen,
 				      DMA_DEV_TO_MEM,
-				      DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+				      DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+				      NULL);
 	if (!rxdesc)
 		goto err_rxdesc;
 
@@ -1050,7 +1051,8 @@ static int configure_dma(struct pl022 *pl022)
 				      pl022->sgt_tx.sgl,
 				      tx_sglen,
 				      DMA_MEM_TO_DEV,
-				      DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+				      DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+				      NULL);
 	if (!txdesc)
 		goto err_txdesc;
 
diff --git a/drivers/spi/spi-topcliff-pch.c b/drivers/spi/spi-topcliff-pch.c
index 2a6429d..cf83a8d 100644
--- a/drivers/spi/spi-topcliff-pch.c
+++ b/drivers/spi/spi-topcliff-pch.c
@@ -1080,7 +1080,8 @@ static void pch_spi_handle_dma(struct pch_spi_data *data, int *bpw)
 	sg = dma->sg_rx_p;
 	desc_rx = dma->chan_rx->device->device_prep_slave_sg(dma->chan_rx, sg,
 					num, DMA_DEV_TO_MEM,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+					DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+					NULL);
 	if (!desc_rx) {
 		dev_err(&data->master->dev, "%s:device_prep_slave_sg Failed\n",
 			__func__);
@@ -1125,7 +1126,8 @@ static void pch_spi_handle_dma(struct pch_spi_data *data, int *bpw)
 	sg = dma->sg_tx_p;
 	desc_tx = dma->chan_tx->device->device_prep_slave_sg(dma->chan_tx,
 					sg, num, DMA_MEM_TO_DEV,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+					DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+					NULL);
 	if (!desc_tx) {
 		dev_err(&data->master->dev, "%s:device_prep_slave_sg Failed\n",
 			__func__);
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 6800f5f..1026f64 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -482,7 +482,8 @@ static int pl011_dma_tx_refill(struct uart_amba_port *uap)
 	}
 
 	desc = dma_dev->device_prep_slave_sg(chan, &dmatx->sg, 1, DMA_MEM_TO_DEV,
-					     DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+					     DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+					     NULL);
 	if (!desc) {
 		dma_unmap_sg(dma_dev->dev, &dmatx->sg, 1, DMA_TO_DEVICE);
 		uap->dmatx.queued = false;
@@ -678,7 +679,8 @@ static int pl011_dma_rx_trigger_dma(struct uart_amba_port *uap)
 	dma_dev = rxchan->device;
 	desc = rxchan->device->device_prep_slave_sg(rxchan, &sgbuf->sg, 1,
 					DMA_DEV_TO_MEM,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+					DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+					NULL);
 	/*
 	 * If the DMA engine is busy and cannot prepare a
 	 * channel, no big deal, the driver will fall back
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 17ae657..7b59490 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -765,7 +765,7 @@ static int dma_handle_rx(struct eg20t_port *priv)
 
 	desc = priv->chan_rx->device->device_prep_slave_sg(priv->chan_rx,
 			sg, 1, DMA_DEV_TO_MEM,
-			DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+			DMA_PREP_INTERRUPT | DMA_CTRL_ACK, NULL);
 
 	if (!desc)
 		return 0;
@@ -924,7 +924,8 @@ static unsigned int dma_handle_tx(struct eg20t_port *priv)
 
 	desc = priv->chan_tx->device->device_prep_slave_sg(priv->chan_tx,
 					priv->sg_tx_p, nent, DMA_MEM_TO_DEV,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+					DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+					NULL);
 	if (!desc) {
 		dev_err(priv->port.dev, "%s:device_prep_slave_sg Failed\n",
 			__func__);
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 7508579..dce0a9a 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1339,7 +1339,7 @@ static void sci_submit_rx(struct sci_port *s)
 		struct dma_async_tx_descriptor *desc;
 
 		desc = chan->device->device_prep_slave_sg(chan,
-			sg, 1, DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
+			sg, 1, DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT, NULL);
 
 		if (desc) {
 			s->desc_rx[i] = desc;
@@ -1455,7 +1455,7 @@ static void work_fn_tx(struct work_struct *work)
 
 	desc = chan->device->device_prep_slave_sg(chan,
 			sg, s->sg_len_tx, DMA_MEM_TO_DEV,
-			DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+			DMA_PREP_INTERRUPT | DMA_CTRL_ACK, NULL);
 	if (!desc) {
 		/* switch to PIO */
 		sci_tx_dma_release(s, true);
-- 
1.7.8.4

[PATCH 09/11] usb/musb: add context parameter to prep_slave_sg call

[Alexandre Bounine]

Fixups for calls affected by adding the new context parameter to DMA_SLAVE
and DMA_CYCLIC interfaces.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/usb/musb/ux500_dma.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index 97cb459..b3cd9a7 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -121,7 +121,8 @@ static bool ux500_configure_channel(struct dma_channel *channel,
 
 	dma_desc = dma_chan->device->
 			device_prep_slave_sg(dma_chan, &sg, 1, direction,
-					     DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+					     DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+					     NULL);
 	if (!dma_desc)
 		return false;
 
-- 
1.7.8.4

[PATCH 10/11] usb/renesas: add context parameter to prep_slave_sg call

[Alexandre Bounine]

Fixup for calls affected by adding the new context parameter to DMA_SLAVE
interface.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/renesas_usbhs/fifo.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index 72339bd..089622f 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -785,7 +785,8 @@ static void usbhsf_dma_prepare_tasklet(unsigned long data)
 
 	desc = chan->device->device_prep_slave_sg(chan, &sg, 1, dir,
 						  DMA_PREP_INTERRUPT |
-						  DMA_CTRL_ACK);
+						  DMA_CTRL_ACK,
+						  NULL);
 	if (!desc)
 		return;
 
-- 
1.7.8.4

[PATCH 11/11] sound/soc: add context parameter to prep_slave_sg and prep_dma_cyclic calls

[Alexandre Bounine]

Fixups for calls affected by adding the new context parameter to DMA_SLAVE
and DMA_CYCLIC interfaces.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Mika Westerberg <mika.westerberg@iki.fi>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
Cc: Dong Aisheng <dong.aisheng@linaro.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
---
 sound/soc/ep93xx/ep93xx-pcm.c   |    2 +-
 sound/soc/imx/imx-pcm-dma-mx2.c |    2 +-
 sound/soc/mxs/mxs-pcm.c         |    2 +-
 sound/soc/sh/siu_pcm.c          |    6 ++++--
 sound/soc/txx9/txx9aclc.c       |    2 +-
 5 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/sound/soc/ep93xx/ep93xx-pcm.c b/sound/soc/ep93xx/ep93xx-pcm.c
index de83904..942c794 100644
--- a/sound/soc/ep93xx/ep93xx-pcm.c
+++ b/sound/soc/ep93xx/ep93xx-pcm.c
@@ -149,7 +149,7 @@ static int ep93xx_pcm_dma_submit(struct snd_pcm_substream *substream)
 	desc = dma_dev->device_prep_dma_cyclic(chan, runtime->dma_addr,
 					       rtd->period_bytes * rtd->periods,
 					       rtd->period_bytes,
-					       rtd->dma_data.direction);
+					       rtd->dma_data.direction, NULL);
 	if (!desc)
 		return -EINVAL;
 
diff --git a/sound/soc/imx/imx-pcm-dma-mx2.c b/sound/soc/imx/imx-pcm-dma-mx2.c
index 5780c9b..7fb9439 100644
--- a/sound/soc/imx/imx-pcm-dma-mx2.c
+++ b/sound/soc/imx/imx-pcm-dma-mx2.c
@@ -161,7 +161,7 @@ static int snd_imx_pcm_hw_params(struct snd_pcm_substream *substream,
 			iprtd->period_bytes * iprtd->periods,
 			iprtd->period_bytes,
 			substream->stream == SNDRV_PCM_STREAM_PLAYBACK ?
-			DMA_MEM_TO_DEV : DMA_DEV_TO_MEM);
+			DMA_MEM_TO_DEV : DMA_DEV_TO_MEM, NULL);
 	if (!iprtd->desc) {
 		dev_err(&chan->dev->device, "cannot prepare slave dma\n");
 		return -EINVAL;
diff --git a/sound/soc/mxs/mxs-pcm.c b/sound/soc/mxs/mxs-pcm.c
index 105f42a..ccddc5d 100644
--- a/sound/soc/mxs/mxs-pcm.c
+++ b/sound/soc/mxs/mxs-pcm.c
@@ -136,7 +136,7 @@ static int snd_mxs_pcm_hw_params(struct snd_pcm_substream *substream,
 			iprtd->period_bytes * iprtd->periods,
 			iprtd->period_bytes,
 			substream->stream == SNDRV_PCM_STREAM_PLAYBACK ?
-			DMA_MEM_TO_DEV : DMA_DEV_TO_MEM);
+			DMA_MEM_TO_DEV : DMA_DEV_TO_MEM, NULL);
 	if (!iprtd->desc) {
 		dev_err(&chan->dev->device, "cannot prepare slave dma\n");
 		return -EINVAL;
diff --git a/sound/soc/sh/siu_pcm.c b/sound/soc/sh/siu_pcm.c
index 0193e59..c89ae9e 100644
--- a/sound/soc/sh/siu_pcm.c
+++ b/sound/soc/sh/siu_pcm.c
@@ -131,7 +131,8 @@ static int siu_pcm_wr_set(struct siu_port *port_info,
 	sg_dma_address(&sg) = buff;
 
 	desc = siu_stream->chan->device->device_prep_slave_sg(siu_stream->chan,
-		&sg, 1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+		&sg, 1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+		NULL);
 	if (!desc) {
 		dev_err(dev, "Failed to allocate a dma descriptor\n");
 		return -ENOMEM;
@@ -181,7 +182,8 @@ static int siu_pcm_rd_set(struct siu_port *port_info,
 	sg_dma_address(&sg) = buff;
 
 	desc = siu_stream->chan->device->device_prep_slave_sg(siu_stream->chan,
-		&sg, 1, DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+		&sg, 1, DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+		NULL);
 	if (!desc) {
 		dev_err(dev, "Failed to allocate dma descriptor\n");
 		return -ENOMEM;
diff --git a/sound/soc/txx9/txx9aclc.c b/sound/soc/txx9/txx9aclc.c
index 2155461..252b8d4 100644
--- a/sound/soc/txx9/txx9aclc.c
+++ b/sound/soc/txx9/txx9aclc.c
@@ -135,7 +135,7 @@ txx9aclc_dma_submit(struct txx9aclc_dmadata *dmadata, dma_addr_t buf_dma_addr)
 	desc = chan->device->device_prep_slave_sg(chan, &sg, 1,
 		dmadata->substream->stream == SNDRV_PCM_STREAM_PLAYBACK ?
 		DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
-		DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+		DMA_PREP_INTERRUPT | DMA_CTRL_ACK, NULL);
 	if (!desc) {
 		dev_err(&chan->dev->device, "cannot prepare slave dma\n");
 		return NULL;
-- 
1.7.8.4

Re: [PATCH 11/11] sound/soc: add context parameter to prep_slave_sg and prep_dma_cyclic calls

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

On Thu, Feb 02, 2012 at 04:32:21PM -0500, Alexandre Bounine wrote:
> Fixups for calls affected by adding the new context parameter to DMA_SLAVE
> and DMA_CYCLIC interfaces.

This really ought to be squashed in with the original commit both to
avoid build breaks in bisection and to let people review what this
parameter does.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: [PATCH 11/11] sound/soc: add context parameter to prep_slave_sg and prep_dma_cyclic calls

[Bounine, Alexandre]

On Thu, Feb 02, 2012 at 5:22 PM, Mark Brown wrote:
> 
> On Thu, Feb 02, 2012 at 04:32:21PM -0500, Alexandre Bounine wrote:
> > Fixups for calls affected by adding the new context parameter to
DMA_SLAVE
> > and DMA_CYCLIC interfaces.
> 
> This really ought to be squashed in with the original commit both to
> avoid build breaks in bisection and to let people review what this
> parameter does.

Agree. Will pack it together to resubmit if it will be decided to go
ahead with this change.
This will make quite large patch but it will help to track it properly.