[PATCH linux-next] dmaengine: add context parameter fixups

This patch fixes drivers that use device_prep_slave_sg() and
device_prep_dma_cyclic() interfaces and have been missed during the initial
release of interface changing patches.

This patch is based on linux-next-20120322 code tree.
See https://lkml.org/lkml/2012/3/22/339 for build failure report.

Signed-off-by: Alexandre Bounine <redacted>
Reported-by: Paul Gortmaker <redacted>
---
 drivers/dma/sa11x0-dma.c      |    2 +-
 drivers/net/irda/sa1100_ir.c  |    2 +-
 sound/soc/sh/fsi.c            |    7 +++----
 sound/soc/soc-dmaengine-pcm.c |    2 +-
 4 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/sa11x0-dma.c b/drivers/dma/sa11x0-dma.c
index 16a6b48..ec78cce 100644
--- a/drivers/dma/sa11x0-dma.c
+++ b/drivers/dma/sa11x0-dma.c

@@ -585,7 +585,7 @@ static dma_cookie_t sa11x0_dma_tx_submit(struct dma_async_tx_descriptor *tx)
 
 static struct dma_async_tx_descriptor *sa11x0_dma_prep_slave_sg(
 	struct dma_chan *chan, struct scatterlist *sg, unsigned int sglen,
-	enum dma_transfer_direction dir, unsigned long flags)
+	enum dma_transfer_direction dir, unsigned long flags, void *context)
 {
 	struct sa11x0_dma_chan *c = to_sa11x0_dma_chan(chan);
 	struct sa11x0_dma_desc *txd;

diff --git a/drivers/net/irda/sa1100_ir.c b/drivers/net/irda/sa1100_ir.c
index a0d1913..e250675 100644
--- a/drivers/net/irda/sa1100_ir.c
+++ b/drivers/net/irda/sa1100_ir.c

@@ -147,7 +147,7 @@ static void sa1100_irda_dma_start(struct sa1100_buf *buf,
 	struct dma_async_tx_descriptor *desc;
 	struct dma_chan *chan = buf->chan;
 
-	desc = chan->device->device_prep_slave_sg(chan, &buf->sg, 1, dir,
+	desc = dmaengine_prep_slave_sg(chan, &buf->sg, 1, dir,
 			DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 	if (desc) {
 		desc->callback = cb;

diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c
index 378cc5b..9e730ad 100644
--- a/sound/soc/sh/fsi.c
+++ b/sound/soc/sh/fsi.c

@@ -1001,11 +1001,10 @@ static void fsi_dma_do_tasklet(unsigned long data)
 	sg_dma_address(&sg) = buf;
 	sg_dma_len(&sg) = len;
 
-	desc = chan->device->device_prep_slave_sg(chan, &sg, 1, dir,
-						  DMA_PREP_INTERRUPT |
-						  DMA_CTRL_ACK);
+	desc = dmaengine_prep_slave_sg(chan, &sg, 1, dir,
+					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 	if (!desc) {
-		dev_err(dai->dev, "device_prep_slave_sg() fail\n");
+		dev_err(dai->dev, "dmaengine_prep_slave_sg() fail\n");
 		return;
 	}
 

diff --git a/sound/soc/soc-dmaengine-pcm.c b/sound/soc/soc-dmaengine-pcm.c
index 4420b70..4756952 100644
--- a/sound/soc/soc-dmaengine-pcm.c
+++ b/sound/soc/soc-dmaengine-pcm.c

@@ -143,7 +143,7 @@ static int dmaengine_pcm_prepare_and_submit(struct snd_pcm_substream *substream)
 	direction = snd_pcm_substream_to_dma_direction(substream);
 
 	prtd->pos = 0;
-	desc = chan->device->device_prep_dma_cyclic(chan,
+	desc = dmaengine_prep_dma_cyclic(chan,
 		substream->runtime->dma_addr,
 		snd_pcm_lib_buffer_bytes(substream),
 		snd_pcm_lib_period_bytes(substream), direction);

-- 
1.7.8.4

On Fri, Mar 23, 2012 at 10:00:42AM -0400, Alexandre Bounine wrote:

This patch fixes drivers that use device_prep_slave_sg() and
device_prep_dma_cyclic() interfaces and have been missed during the initial
release of interface changing patches.

Can you please send a separate patch for the ASoC (sound/soc) bits of
this?

On Fri, Mar 23, 2012 at 11:00 AM, Alexandre Bounine
[off-list ref] wrote:

This patch fixes drivers that use device_prep_slave_sg() and
device_prep_dma_cyclic() interfaces and have been missed during the initial
release of interface changing patches.

This patch is based on linux-next-20120322 code tree.
See https://lkml.org/lkml/2012/3/22/339 for build failure report.

Signed-off-by: Alexandre Bounine <redacted>
Reported-by: Paul Gortmaker <redacted>
---
 drivers/dma/sa11x0-dma.c      |    2 +-
 drivers/net/irda/sa1100_ir.c  |    2 +-
 sound/soc/sh/fsi.c            |    7 +++----
 sound/soc/soc-dmaengine-pcm.c |    2 +-

I have already taken care of sound/soc/soc-dmaengine-pcm.c:
http://permalink.gmane.org/gmane.linux.alsa.devel/96215
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

On Sat, 2012-03-24 at 12:23 -0300, Fabio Estevam wrote:

On Fri, Mar 23, 2012 at 11:00 AM, Alexandre Bounine
[off-list ref] wrote:

quoted

This patch fixes drivers that use device_prep_slave_sg() and
device_prep_dma_cyclic() interfaces and have been missed during the initial
release of interface changing patches.

This patch is based on linux-next-20120322 code tree.
See https://lkml.org/lkml/2012/3/22/339 for build failure report.

Signed-off-by: Alexandre Bounine <redacted>
Reported-by: Paul Gortmaker <redacted>
---
 drivers/dma/sa11x0-dma.c      |    2 +-
 drivers/net/irda/sa1100_ir.c  |    2 +-
 sound/soc/sh/fsi.c            |    7 +++----
 sound/soc/soc-dmaengine-pcm.c |    2 +-

I have already taken care of sound/soc/soc-dmaengine-pcm.c:
http://permalink.gmane.org/gmane.linux.alsa.devel/96215

And this seems to be linux-next.

Mark, Is this part of the sound updates that went to Linus?


-- 
~Vinod

On Mon, Mar 26, 2012 at 11:04:42AM +0530, Vinod Koul wrote:

On Sat, 2012-03-24 at 12:23 -0300, Fabio Estevam wrote:

quoted

http://permalink.gmane.org/gmane.linux.alsa.devel/96215

And this seems to be linux-next.

Mark, Is this part of the sound updates that went to Linus?

No, not yet - it was only sent after the merge window.  Quite why nobody
managed to notice it before then I don't know.  It'll go to him soon, or
at least to Takashi, but don't know if it'll make -rc1 or not.

On Mon, 2012-03-26 at 10:42 +0100, Mark Brown wrote:

On Mon, Mar 26, 2012 at 11:04:42AM +0530, Vinod Koul wrote:

quoted

On Sat, 2012-03-24 at 12:23 -0300, Fabio Estevam wrote:

quoted

quoted

http://permalink.gmane.org/gmane.linux.alsa.devel/96215

quoted

And this seems to be linux-next.

quoted

Mark, Is this part of the sound updates that went to Linus?

No, not yet - it was only sent after the merge window.  Quite why nobody
managed to notice it before then I don't know.  It'll go to him soon, or
at least to Takashi, but don't know if it'll make -rc1 or not.

I should have noticed that sound needs update as well  :(

Now either I drop these from 3.4 or merge Linus's tree and apply
Alexandre's fix (as that is the right fix rather than one in asoc tree)
And since this was required for RIO patches which are still WIP, I think
I am leaning towards former.

-- 
~Vinod

On Mon, Mar 26, 2012 at 03:24:30PM +0530, Vinod Koul wrote:

Now either I drop these from 3.4 or merge Linus's tree and apply
Alexandre's fix (as that is the right fix rather than one in asoc tree)
And since this was required for RIO patches which are still WIP, I think
I am leaning towards former.

Gah, WTF is going on here?  Has this API change not been sent to Linus
already, and what is wrong with the changes which Fabio sent?  I've
already applied Fabio's change on the understanding that this API change
done and dusted.

It seems better to do a minimal fix at this point rather than churning
things again...

On Mon, 2012-03-26 at 11:33 +0100, Mark Brown wrote:

On Mon, Mar 26, 2012 at 03:24:30PM +0530, Vinod Koul wrote:

quoted

Now either I drop these from 3.4 or merge Linus's tree and apply
Alexandre's fix (as that is the right fix rather than one in asoc tree)
And since this was required for RIO patches which are still WIP, I think
I am leaning towards former.

Gah, WTF is going on here?  Has this API change not been sent to Linus
already, and what is wrong with the changes which Fabio sent?  I've
already applied Fabio's change on the understanding that this API change
done and dusted.

It seems better to do a minimal fix at this point rather than churning
things again...

The change is technically correct, so don't worry it wont break
anything, and API is frozen and not changing.

But we don't want the clients to use this additional parameter or be
exposed to it if not required. Every client is expected to use the
dmaengine wrappers for prepare and not invoke .device_ callbacks.


-- 
~Vinod

On Mon, Mar 26, 2012 at 04:18:26PM +0530, Vinod Koul wrote:

But we don't want the clients to use this additional parameter or be
exposed to it if not required. Every client is expected to use the
dmaengine wrappers for prepare and not invoke .device_ callbacks.

Are those wrappers present in what's gone to Linus' tree, and can
someone please send a patch to convert to using them?

On Mon, 2012-03-26 at 12:01 +0100, Mark Brown wrote:

On Mon, Mar 26, 2012 at 04:18:26PM +0530, Vinod Koul wrote:

quoted

But we don't want the clients to use this additional parameter or be
exposed to it if not required. Every client is expected to use the
dmaengine wrappers for prepare and not invoke .device_ callbacks.

Are those wrappers present in what's gone to Linus' tree, and can
someone please send a patch to convert to using them?

Yes that are already there :-)

I will send sound specific update now

-- 
~Vinod

On Mon, March 26, 2012 at 5:55 AM, Vinod Koul wrote:

Subject: Re: [PATCH linux-next] dmaengine: add context parameter fixups

On Mon, 2012-03-26 at 10:42 +0100, Mark Brown wrote:

quoted

On Mon, Mar 26, 2012 at 11:04:42AM +0530, Vinod Koul wrote:

quoted

On Sat, 2012-03-24 at 12:23 -0300, Fabio Estevam wrote:

quoted

quoted

http://permalink.gmane.org/gmane.linux.alsa.devel/96215

quoted

And this seems to be linux-next.

quoted

Mark, Is this part of the sound updates that went to Linus?

No, not yet - it was only sent after the merge window.  Quite why

nobody

quoted

managed to notice it before then I don't know.  It'll go to him soon,

or

quoted

at least to Takashi, but don't know if it'll make -rc1 or not.

I should have noticed that sound needs update as well  :(

Now either I drop these from 3.4 or merge Linus's tree and apply
Alexandre's fix (as that is the right fix rather than one in asoc tree)
And since this was required for RIO patches which are still WIP, I
think
I am leaning towards former.

I do not see any sense in dropping these API changes now.
Some audio files have been missed form the original patch because I did
not have them in the code tree when patch was built.
For those who was not in the list for original patches here is a link to
the patch details: https://lkml.org/lkml/2012/3/8/373

If we drop the API changes now we will need redo these changes again later.
We already dragged these changes long enough since original discussion in October.
I will send new inline wrapper for RapidIO today. 

Alex.

At Mon, 26 Mar 2012 10:42:01 +0100,
Mark Brown wrote:

On Mon, Mar 26, 2012 at 11:04:42AM +0530, Vinod Koul wrote:

quoted

On Sat, 2012-03-24 at 12:23 -0300, Fabio Estevam wrote:

quoted

quoted

http://permalink.gmane.org/gmane.linux.alsa.devel/96215

quoted

And this seems to be linux-next.

quoted

Mark, Is this part of the sound updates that went to Linus?

No, not yet - it was only sent after the merge window.  Quite why nobody
managed to notice it before then I don't know.  It'll go to him soon, or
at least to Takashi, but don't know if it'll make -rc1 or not.

How is the situation now?

FYI, I'm going to send a pull request to Linus tomorrow or on Friday.
If anything needed to be merged in rc1, it must be there in time.


thanks,

Takashi

On Wed, Mar 28, 2012 at 05:44:22PM +0200, Takashi Iwai wrote:

Mark Brown wrote:

quoted

No, not yet - it was only sent after the merge window.  Quite why nobody
managed to notice it before then I don't know.  It'll go to him soon, or
at least to Takashi, but don't know if it'll make -rc1 or not.

How is the situation now?

FYI, I'm going to send a pull request to Linus tomorrow or on Friday.
If anything needed to be merged in rc1, it must be there in time.

It's in my tree, I didn't see an enormous rush to get it in TBH.

On Wed, 2012-03-28 at 16:51 +0100, Mark Brown wrote:

On Wed, Mar 28, 2012 at 05:44:22PM +0200, Takashi Iwai wrote:

quoted

Mark Brown wrote:

quoted

quoted

No, not yet - it was only sent after the merge window.  Quite why nobody
managed to notice it before then I don't know.  It'll go to him soon, or
at least to Takashi, but don't know if it'll make -rc1 or not.

quoted

How is the situation now?

quoted

FYI, I'm going to send a pull request to Linus tomorrow or on Friday.
If anything needed to be merged in rc1, it must be there in time.

It's in my tree, I didn't see an enormous rush to get it in TBH.

I should be sending the pull request for slave-dma to Linus this
evening.
Can you please include the fix I did in your tree in your pull request.


-- 
~Vinod