Skip to contentSkip to conversation

ASoC: fsi: update for dmaengine prep_slave_sg fallout.

PATCH In review Paul Mundt 3 participants 8 messages Mar 30, 2012 – Apr 18, 2012

Subsystems (3)
lore
Share & tools
lore

Paul Mundt

author
#0 lore raw

PATCH 1/1 ASoC: fsi: update for dmaengine prep_slave_sg fallout.

Leading up to the ->device_prep_slave_sg change in 185ecb5f4fd43911c35956d4cc7d94a1da30417f 'dmaengine: add context parameter to prep_slave_sg and prep_dma_cyclic' a generic wrapper was added in place to guard against the API change, though the fsi driver wasn't updated in the process (presumably its dmaengine support hadn't been merged yet at the time). This trivially switches over to the new wrapper and gets it building again.

---

 sound/soc/sh/fsi.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
sound/soc/sh/fsi.c +3 -4
index 378cc5b..74ed2df 100644
@@ -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;
 	}
 
Acked-by on v1 1/1
#1 lore raw

Hi

Quoted 11 lines

Leading up to the ->device_prep_slave_sg change in 185ecb5f4fd43911c35956d4cc7d94a1da30417f 'dmaengine: add context parameter to prep_slave_sg and prep_dma_cyclic' a generic wrapper was added in place to guard against the API change, though the fsi driver wasn't updated in the process (presumably its dmaengine support hadn't been merged yet at the time). This trivially switches over to the new wrapper and gets it building again.

---

Best regards
---
Kuninori Morimoto

#2 lore raw
In reply to Paul Mundt

Hi Paul, Mark

Quoted 8 lines
Quoted 8 lines

Leading up to the ->device_prep_slave_sg change in 185ecb5f4fd43911c35956d4cc7d94a1da30417f 'dmaengine: add context parameter to prep_slave_sg and prep_dma_cyclic' a generic wrapper was added in place to guard against the API change, though the fsi driver wasn't updated in the process (presumably its dmaengine support hadn't been merged yet at the time). This trivially switches over to the new wrapper and gets it building again.

Quoted 5 lines
Quoted 3 lines

---

This patch is required for current linux kernel, but it Cc:ed to linux-sh ML only. Who control this? Paul? Mark?

Best regards
---
Kuninori Morimoto

#3 lore raw
In reply to Paul Mundt
Quoted 2 lines · Kuninori Morimoto

This patch is required for current linux kernel, but it Cc:ed to linux-sh ML only. Who control this? Paul? Mark?

Not me at the minute, I don't have the patch.

author
#4 lore raw
In reply to Paul Mundt
Quoted 6 lines · Mark Brown
Quoted 2 lines · Kuninori Morimoto

This patch is required for current linux kernel, but it Cc:ed to linux-sh ML only. Who control this? Paul? Mark?

Not me at the minute, I don't have the patch.

You were Cc'ed on it?

#5 lore raw
In reply to Paul Mundt
Quoted 9 lines · Paul Mundt
Quoted 6 lines · Mark Brown
Quoted 2 lines · Kuninori Morimoto

This patch is required for current linux kernel, but it Cc:ed to linux-sh ML only. Who control this? Paul? Mark?

Not me at the minute, I don't have the patch.

You were Cc'ed on it?

That was in the past. I currently don't have it. Probably I didn't do anything with it as it wasn't sent as an ALSA patch (no CC to either the list or Liam) so it will have looked like you were just CCing for info. If you can resend I'll apply.

#6 lore raw

PATCH 1/1 ASoC: fsi: update for dmaengine prep_slave_sg fallout.

From: Paul Mundt <[email protected]>

Leading up to the ->device_prep_slave_sg change in 185ecb5f4fd43911c35956d4cc7d94a1da30417f 'dmaengine: add context parameter to prep_slave_sg and prep_dma_cyclic' a generic wrapper was added in place to guard against the API change, though the fsi driver wasn't updated in the process (presumably its dmaengine support hadn't been merged yet at the time). This trivially switches over to the new wrapper and gets it building again.

---
Nothing happened on ALSA ML.
So I forward this patch.
I added my Acked-by on it.

 sound/soc/sh/fsi.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
sound/soc/sh/fsi.c +3 -4
index 378cc5b..74ed2df 100644
@@ -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;
 	}
 
#7 lore raw
Quoted 7 lines · On Tue, Apr 17, 2012 at 07:13:04PM -0700, [email protected]…

---
Nothing happened on ALSA ML.
So I forward this patch.
I added my Acked-by on it.

I've applied this since I can see Paul's original version in the archive but when forwarding patches for someone else you should sign off rather than ack the patch - signoff is mostly a statement saying "I know this is OK legally" and so everyone who forwards the patch is supposed to add one.