[PATCH 0/7 v2] dma: sh: stop using .private

[PATCH 0/7 v2] dma: sh: stop using .private

[Guennadi Liakhovetski]

This patch series supersedes the one from yesterday with the same title. 
The 4 patches from v1 are all unchanged, v2 just prepends them with 3 more 
preparatory patches. From the original series description:

Here's an attempt to convert the shdma driver to a new method, whereby a 
centrally provided filter function is used and the DMA_SLAVE_CONFIG command 
is enabled for slave operation. The last patch is an illustration of how 
this new method shall be used. If this approach is acceptable, I'll also 
convert the remaining shdma user drivers. This patch series goes on top of 
my earlier patches to split shdma.c.

As suggested yesterday, I've pushed both my current shdma patch series to 
github in branches:

git://github.com/lyakh/linux.git shdma-base
git://github.com/lyakh/linux.git shdma-config

for the preceding base shdma-split series and for this one respectively.

As before, the last patch in the series is FYI only for now.

Guennadi Liakhovetski (7):
  dmaengine: shdma: (cosmetic) simplify a static function
  ASoC: siu: don't use DMA device for channel filtering
  sh: remove unused DMA device pointer from SIU platform data
  dmaengine: shdma: prepare to stop using struct dma_chan::private
  dma: sh: use an integer slave ID to improve API compatibility
  dma: sh: provide a migration path for slave drivers to stop using
    .private
  mmc: sh_mmcif: switch to the new DMA channel allocation and
    configuration

 arch/sh/include/asm/siu.h              |    1 -
 arch/sh/kernel/cpu/sh4a/setup-sh7722.c |    1 -
 drivers/dma/sh/shdma-base.c            |  130 ++++++++++++++++++++++++--------
 drivers/dma/sh/shdma.c                 |   39 +++++-----
 drivers/dma/sh/shdma.h                 |    2 +
 drivers/mmc/host/sh_mmcif.c            |   90 +++++++++++++----------
 include/linux/sh_dma.h                 |   12 ++--
 include/linux/shdma-base.h             |    7 +-
 sound/soc/sh/siu_pcm.c                 |    4 -
 9 files changed, 179 insertions(+), 107 deletions(-)

-- 
1.7.2.5

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH 0/7 v2] dma: sh: stop using .private

[Guennadi Liakhovetski]

This patch series supersedes the one from yesterday with the same title. 
The 4 patches from v1 are all unchanged, v2 just prepends them with 3 more 
preparatory patches. From the original series description:

Here's an attempt to convert the shdma driver to a new method, whereby a 
centrally provided filter function is used and the DMA_SLAVE_CONFIG command 
is enabled for slave operation. The last patch is an illustration of how 
this new method shall be used. If this approach is acceptable, I'll also 
convert the remaining shdma user drivers. This patch series goes on top of 
my earlier patches to split shdma.c.

As suggested yesterday, I've pushed both my current shdma patch series to 
github in branches:

git://github.com/lyakh/linux.git shdma-base
git://github.com/lyakh/linux.git shdma-config

for the preceding base shdma-split series and for this one respectively.

As before, the last patch in the series is FYI only for now.

Guennadi Liakhovetski (7):
  dmaengine: shdma: (cosmetic) simplify a static function
  ASoC: siu: don't use DMA device for channel filtering
  sh: remove unused DMA device pointer from SIU platform data
  dmaengine: shdma: prepare to stop using struct dma_chan::private
  dma: sh: use an integer slave ID to improve API compatibility
  dma: sh: provide a migration path for slave drivers to stop using
    .private
  mmc: sh_mmcif: switch to the new DMA channel allocation and
    configuration

 arch/sh/include/asm/siu.h              |    1 -
 arch/sh/kernel/cpu/sh4a/setup-sh7722.c |    1 -
 drivers/dma/sh/shdma-base.c            |  130 ++++++++++++++++++++++++--------
 drivers/dma/sh/shdma.c                 |   39 +++++-----
 drivers/dma/sh/shdma.h                 |    2 +
 drivers/mmc/host/sh_mmcif.c            |   90 +++++++++++++----------
 include/linux/sh_dma.h                 |   12 ++--
 include/linux/shdma-base.h             |    7 +-
 sound/soc/sh/siu_pcm.c                 |    4 -
 9 files changed, 179 insertions(+), 107 deletions(-)

-- 
1.7.2.5

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH 1/7 v2] dmaengine: shdma: (cosmetic) simplify a static function

[Guennadi Liakhovetski]

dmae_find_slave() needs only the slave_id field from the slave object, no
need to pass the pointer to the object, pass the slave_id directly.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
 drivers/dma/sh/shdma.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
index c393b35..f06906f 100644
--- a/drivers/dma/sh/shdma.c
+++ b/drivers/dma/sh/shdma.c
@@ -304,18 +304,18 @@ static void sh_dmae_setup_xfer(struct shdma_chan *schan,
 }
 
 static const struct sh_dmae_slave_config *dmae_find_slave(
-	struct sh_dmae_chan *sh_chan, struct sh_dmae_slave *slave)
+	struct sh_dmae_chan *sh_chan, unsigned int slave_id)
 {
 	struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
 	struct sh_dmae_pdata *pdata = shdev->pdata;
 	const struct sh_dmae_slave_config *cfg;
 	int i;
 
-	if (slave->shdma_slave.slave_id >= SH_DMA_SLAVE_NUMBER)
+	if (slave_id >= SH_DMA_SLAVE_NUMBER)
 		return NULL;
 
 	for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
-		if (cfg->slave_id = slave->shdma_slave.slave_id)
+		if (cfg->slave_id = slave_id)
 			return cfg;
 
 	return NULL;
@@ -328,7 +328,7 @@ static int sh_dmae_set_slave(struct shdma_chan *schan,
 						    shdma_chan);
 	struct sh_dmae_slave *slave = container_of(sslave, struct sh_dmae_slave,
 						   shdma_slave);
-	const struct sh_dmae_slave_config *cfg = dmae_find_slave(sh_chan, slave);
+	const struct sh_dmae_slave_config *cfg = dmae_find_slave(sh_chan, sslave->slave_id);
 	if (!cfg)
 		return -ENODEV;
 
-- 
1.7.2.5

[PATCH 1/7 v2] dmaengine: shdma: (cosmetic) simplify a static function

[Guennadi Liakhovetski]

dmae_find_slave() needs only the slave_id field from the slave object, no
need to pass the pointer to the object, pass the slave_id directly.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
 drivers/dma/sh/shdma.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
index c393b35..f06906f 100644
--- a/drivers/dma/sh/shdma.c
+++ b/drivers/dma/sh/shdma.c
@@ -304,18 +304,18 @@ static void sh_dmae_setup_xfer(struct shdma_chan *schan,
 }
 
 static const struct sh_dmae_slave_config *dmae_find_slave(
-	struct sh_dmae_chan *sh_chan, struct sh_dmae_slave *slave)
+	struct sh_dmae_chan *sh_chan, unsigned int slave_id)
 {
 	struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
 	struct sh_dmae_pdata *pdata = shdev->pdata;
 	const struct sh_dmae_slave_config *cfg;
 	int i;
 
-	if (slave->shdma_slave.slave_id >= SH_DMA_SLAVE_NUMBER)
+	if (slave_id >= SH_DMA_SLAVE_NUMBER)
 		return NULL;
 
 	for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
-		if (cfg->slave_id == slave->shdma_slave.slave_id)
+		if (cfg->slave_id == slave_id)
 			return cfg;
 
 	return NULL;
@@ -328,7 +328,7 @@ static int sh_dmae_set_slave(struct shdma_chan *schan,
 						    shdma_chan);
 	struct sh_dmae_slave *slave = container_of(sslave, struct sh_dmae_slave,
 						   shdma_slave);
-	const struct sh_dmae_slave_config *cfg = dmae_find_slave(sh_chan, slave);
+	const struct sh_dmae_slave_config *cfg = dmae_find_slave(sh_chan, sslave->slave_id);
 	if (!cfg)
 		return -ENODEV;
 
-- 
1.7.2.5

[PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering

[Guennadi Liakhovetski]

DMA channels are filtered based on slave IDs, no need to additionally filter
on DMA device.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 sound/soc/sh/siu_pcm.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/sound/soc/sh/siu_pcm.c b/sound/soc/sh/siu_pcm.c
index 3fdc801..488f9be 100644
--- a/sound/soc/sh/siu_pcm.c
+++ b/sound/soc/sh/siu_pcm.c
@@ -332,9 +332,6 @@ static bool filter(struct dma_chan *chan, void *slave)
 
 	pr_debug("%s: slave ID %d\n", __func__, param->shdma_slave.slave_id);
 
-	if (unlikely(param->dma_dev != chan->device->dev))
-		return false;
-
 	chan->private = &param->shdma_slave;
 	return true;
 }
@@ -369,7 +366,6 @@ static int siu_pcm_open(struct snd_pcm_substream *ss)
 			pdata->dma_slave_rx_a;
 	}
 
-	param->dma_dev = pdata->dma_dev;
 	/* Get DMA channel */
 	siu_stream->chan = dma_request_channel(mask, filter, param);
 	if (!siu_stream->chan) {
-- 
1.7.2.5

[PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering

[Guennadi Liakhovetski]

DMA channels are filtered based on slave IDs, no need to additionally filter
on DMA device.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 sound/soc/sh/siu_pcm.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/sound/soc/sh/siu_pcm.c b/sound/soc/sh/siu_pcm.c
index 3fdc801..488f9be 100644
--- a/sound/soc/sh/siu_pcm.c
+++ b/sound/soc/sh/siu_pcm.c
@@ -332,9 +332,6 @@ static bool filter(struct dma_chan *chan, void *slave)
 
 	pr_debug("%s: slave ID %d\n", __func__, param->shdma_slave.slave_id);
 
-	if (unlikely(param->dma_dev != chan->device->dev))
-		return false;
-
 	chan->private = &param->shdma_slave;
 	return true;
 }
@@ -369,7 +366,6 @@ static int siu_pcm_open(struct snd_pcm_substream *ss)
 			pdata->dma_slave_rx_a;
 	}
 
-	param->dma_dev = pdata->dma_dev;
 	/* Get DMA channel */
 	siu_stream->chan = dma_request_channel(mask, filter, param);
 	if (!siu_stream->chan) {
-- 
1.7.2.5

Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering

[Mark Brown]

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

On Thu, Jul 05, 2012 at 12:29:38PM +0200, Guennadi Liakhovetski wrote:
> DMA channels are filtered based on slave IDs, no need to additionally filter
> on DMA device.

This doesn't apply, please regenerate against current code.

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

Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering

[Mark Brown]

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

On Thu, Jul 05, 2012 at 12:29:38PM +0200, Guennadi Liakhovetski wrote:
> DMA channels are filtered based on slave IDs, no need to additionally filter
> on DMA device.

This doesn't apply, please regenerate against current code.

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

Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering

[Guennadi Liakhovetski]

On Thu, 5 Jul 2012, Mark Brown wrote:

> On Thu, Jul 05, 2012 at 12:29:38PM +0200, Guennadi Liakhovetski wrote:
> > DMA channels are filtered based on slave IDs, no need to additionally filter
> > on DMA device.
> 
> This doesn't apply, please regenerate against current code.

Sure, as I mentioned in my description mail: "This patch series goes on 
top of my earlier patches to split shdma.c." And that patch series, also 
available at

git://github.com/lyakh/linux.git shdma-base

contains this patch:

commit 553d9459a90e9cc6997da2c34bb637794d6a4ac5
    ASoC: siu: prepare for conversion to the shdma base library

Sorry, I should have mentioned, that various DMA slave drivers also have 
dependencies in that series.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering

[Guennadi Liakhovetski]

On Thu, 5 Jul 2012, Mark Brown wrote:

> On Thu, Jul 05, 2012 at 12:29:38PM +0200, Guennadi Liakhovetski wrote:
> > DMA channels are filtered based on slave IDs, no need to additionally filter
> > on DMA device.
> 
> This doesn't apply, please regenerate against current code.

Sure, as I mentioned in my description mail: "This patch series goes on 
top of my earlier patches to split shdma.c." And that patch series, also 
available at

git://github.com/lyakh/linux.git shdma-base

contains this patch:

commit 553d9459a90e9cc6997da2c34bb637794d6a4ac5
    ASoC: siu: prepare for conversion to the shdma base library

Sorry, I should have mentioned, that various DMA slave drivers also have 
dependencies in that series.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering

[Mark Brown]

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

On Thu, Jul 05, 2012 at 03:54:30PM +0200, Guennadi Liakhovetski wrote:
> On Thu, 5 Jul 2012, Mark Brown wrote:

> > This doesn't apply, please regenerate against current code.

> Sure, as I mentioned in my description mail: "This patch series goes on 
> top of my earlier patches to split shdma.c." And that patch series, also 
> available at

Ah, right.  You didn't send me your cover mail, you only CCed me on the
individual patch, so I hadn't seen this.

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

Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering

[Mark Brown]

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

On Thu, Jul 05, 2012 at 03:54:30PM +0200, Guennadi Liakhovetski wrote:
> On Thu, 5 Jul 2012, Mark Brown wrote:

> > This doesn't apply, please regenerate against current code.

> Sure, as I mentioned in my description mail: "This patch series goes on 
> top of my earlier patches to split shdma.c." And that patch series, also 
> available at

Ah, right.  You didn't send me your cover mail, you only CCed me on the
individual patch, so I hadn't seen this.

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

Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering

[Guennadi Liakhovetski]

On Thu, 5 Jul 2012, Mark Brown wrote:

> On Thu, Jul 05, 2012 at 03:54:30PM +0200, Guennadi Liakhovetski wrote:
> > On Thu, 5 Jul 2012, Mark Brown wrote:
> 
> > > This doesn't apply, please regenerate against current code.
> 
> > Sure, as I mentioned in my description mail: "This patch series goes on 
> > top of my earlier patches to split shdma.c." And that patch series, also 
> > available at
> 
> Ah, right.  You didn't send me your cover mail, you only CCed me on the
> individual patch, so I hadn't seen this.

Indeed, sorry again.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering

[Guennadi Liakhovetski]

On Thu, 5 Jul 2012, Mark Brown wrote:

> On Thu, Jul 05, 2012 at 03:54:30PM +0200, Guennadi Liakhovetski wrote:
> > On Thu, 5 Jul 2012, Mark Brown wrote:
> 
> > > This doesn't apply, please regenerate against current code.
> 
> > Sure, as I mentioned in my description mail: "This patch series goes on 
> > top of my earlier patches to split shdma.c." And that patch series, also 
> > available at
> 
> Ah, right.  You didn't send me your cover mail, you only CCed me on the
> individual patch, so I hadn't seen this.

Indeed, sorry again.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH 3/7 v2] sh: remove unused DMA device pointer from SIU platform data

[Guennadi Liakhovetski]

The SIU ALSA driver is not using the DMA device pointer for DMA channel
filtering any more, it can be now removed.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Paul Mundt <lethal@linux-sh.org>
---
 arch/sh/include/asm/siu.h              |    1 -
 arch/sh/kernel/cpu/sh4a/setup-sh7722.c |    1 -
 2 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/sh/include/asm/siu.h b/arch/sh/include/asm/siu.h
index 1d95c78..580b7ac 100644
--- a/arch/sh/include/asm/siu.h
+++ b/arch/sh/include/asm/siu.h
@@ -14,7 +14,6 @@
 struct device;
 
 struct siu_platform {
-	struct device *dma_dev;
 	unsigned int dma_slave_tx_a;
 	unsigned int dma_slave_rx_a;
 	unsigned int dma_slave_tx_b;
diff --git a/arch/sh/kernel/cpu/sh4a/setup-sh7722.c b/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
index 0f5a219..65786c7 100644
--- a/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
+++ b/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
@@ -512,7 +512,6 @@ static struct platform_device tmu2_device = {
 };
 
 static struct siu_platform siu_platform_data = {
-	.dma_dev	= &dma_device.dev,
 	.dma_slave_tx_a	= SHDMA_SLAVE_SIUA_TX,
 	.dma_slave_rx_a	= SHDMA_SLAVE_SIUA_RX,
 	.dma_slave_tx_b	= SHDMA_SLAVE_SIUB_TX,
-- 
1.7.2.5

[PATCH 3/7 v2] sh: remove unused DMA device pointer from SIU platform data

[Guennadi Liakhovetski]

The SIU ALSA driver is not using the DMA device pointer for DMA channel
filtering any more, it can be now removed.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Paul Mundt <lethal@linux-sh.org>
---
 arch/sh/include/asm/siu.h              |    1 -
 arch/sh/kernel/cpu/sh4a/setup-sh7722.c |    1 -
 2 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/sh/include/asm/siu.h b/arch/sh/include/asm/siu.h
index 1d95c78..580b7ac 100644
--- a/arch/sh/include/asm/siu.h
+++ b/arch/sh/include/asm/siu.h
@@ -14,7 +14,6 @@
 struct device;
 
 struct siu_platform {
-	struct device *dma_dev;
 	unsigned int dma_slave_tx_a;
 	unsigned int dma_slave_rx_a;
 	unsigned int dma_slave_tx_b;
diff --git a/arch/sh/kernel/cpu/sh4a/setup-sh7722.c b/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
index 0f5a219..65786c7 100644
--- a/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
+++ b/arch/sh/kernel/cpu/sh4a/setup-sh7722.c
@@ -512,7 +512,6 @@ static struct platform_device tmu2_device = {
 };
 
 static struct siu_platform siu_platform_data = {
-	.dma_dev	= &dma_device.dev,
 	.dma_slave_tx_a	= SHDMA_SLAVE_SIUA_TX,
 	.dma_slave_rx_a	= SHDMA_SLAVE_SIUA_RX,
 	.dma_slave_tx_b	= SHDMA_SLAVE_SIUB_TX,
-- 
1.7.2.5

[PATCH 4/7 v2] dmaengine: shdma: prepare to stop using struct dma_chan::private

[Guennadi Liakhovetski]

Using struct dma_chan::private is deprecated. To update the shdma driver to
stop using it we first have to eliminate internal runtime uses of it. After
that we will also be able to stop using it for channel configuration.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
 drivers/dma/sh/shdma-base.c |    9 +++++----
 drivers/dma/sh/shdma.c      |   24 ++++++++++--------------
 drivers/dma/sh/shdma.h      |    2 ++
 include/linux/sh_dma.h      |    2 --
 include/linux/shdma-base.h  |    1 +
 5 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
index ff060d0..f75ebfa 100644
--- a/drivers/dma/sh/shdma-base.c
+++ b/drivers/dma/sh/shdma-base.c
@@ -76,7 +76,7 @@ static dma_cookie_t shdma_tx_submit(struct dma_async_tx_descriptor *tx)
 		container_of(tx, struct shdma_desc, async_tx),
 		*last = desc;
 	struct shdma_chan *schan = to_shdma_chan(tx->chan);
-	struct shdma_slave *slave = tx->chan->private;
+	struct shdma_slave *slave = schan->slave;
 	dma_async_tx_callback callback = tx->callback;
 	dma_cookie_t cookie;
 	bool power_up;
@@ -208,6 +208,7 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
 		goto edescalloc;
 	}
 	schan->desc_num = NR_DESCS_PER_CHANNEL;
+	schan->slave = slave;
 
 	for (i = 0; i < NR_DESCS_PER_CHANNEL; i++) {
 		desc = ops->embedded_desc(schan->desc, i);
@@ -365,9 +366,9 @@ static void shdma_free_chan_resources(struct dma_chan *chan)
 	if (!list_empty(&schan->ld_queue))
 		shdma_chan_ld_cleanup(schan, true);
 
-	if (chan->private) {
+	if (schan->slave) {
 		/* The caller is holding dma_list_mutex */
-		struct shdma_slave *slave = chan->private;
+		struct shdma_slave *slave = schan->slave;
 		clear_bit(slave->slave_id, shdma_slave_used);
 		chan->private = NULL;
 	}
@@ -558,7 +559,7 @@ static struct dma_async_tx_descriptor *shdma_prep_slave_sg(
 	struct shdma_chan *schan = to_shdma_chan(chan);
 	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
 	const struct shdma_ops *ops = sdev->ops;
-	struct shdma_slave *slave = chan->private;
+	struct shdma_slave *slave = schan->slave;
 	dma_addr_t slave_addr;
 
 	if (!chan)
diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
index f06906f..9f0a2e5 100644
--- a/drivers/dma/sh/shdma.c
+++ b/drivers/dma/sh/shdma.c
@@ -291,10 +291,8 @@ static void sh_dmae_setup_xfer(struct shdma_chan *schan,
 						    shdma_chan);
 
 	if (sslave) {
-		struct sh_dmae_slave *slave = container_of(sslave,
-					struct sh_dmae_slave, shdma_slave);
 		const struct sh_dmae_slave_config *cfg -			slave->config;
+			sh_chan->config;
 
 		dmae_set_dmars(sh_chan, cfg->mid_rid);
 		dmae_set_chcr(sh_chan, cfg->chcr);
@@ -326,13 +324,11 @@ static int sh_dmae_set_slave(struct shdma_chan *schan,
 {
 	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
 						    shdma_chan);
-	struct sh_dmae_slave *slave = container_of(sslave, struct sh_dmae_slave,
-						   shdma_slave);
 	const struct sh_dmae_slave_config *cfg = dmae_find_slave(sh_chan, sslave->slave_id);
 	if (!cfg)
 		return -ENODEV;
 
-	slave->config = cfg;
+	sh_chan->config = cfg;
 
 	return 0;
 }
@@ -579,13 +575,12 @@ static int sh_dmae_resume(struct device *dev)
 
 	for (i = 0; i < shdev->pdata->channel_num; i++) {
 		struct sh_dmae_chan *sh_chan = shdev->chan[i];
-		struct sh_dmae_slave *param = sh_chan->shdma_chan.dma_chan.private;
 
 		if (!sh_chan->shdma_chan.desc_num)
 			continue;
 
-		if (param) {
-			const struct sh_dmae_slave_config *cfg = param->config;
+		if (sh_chan->shdma_chan.slave) {
+			const struct sh_dmae_slave_config *cfg = sh_chan->config;
 			dmae_set_dmars(sh_chan, cfg->mid_rid);
 			dmae_set_chcr(sh_chan, cfg->chcr);
 		} else {
@@ -609,14 +604,15 @@ const struct dev_pm_ops sh_dmae_pm = {
 
 static dma_addr_t sh_dmae_slave_addr(struct shdma_chan *schan)
 {
-	struct sh_dmae_slave *param = schan->dma_chan.private;
+	struct sh_dmae_chan *sh_chan = container_of(schan,
+					struct sh_dmae_chan, shdma_chan);
 
 	/*
-	 * Implicit BUG_ON(!param)
-	 * if (param != NULL), this is a successfully requested slave channel,
-	 * therefore param->config != NULL too.
+	 * Implicit BUG_ON(!sh_chan->config)
+	 * This is an exclusive slave DMA operation, may only be called after a
+	 * successful slave configuration.
 	 */
-	return param->config->addr;
+	return sh_chan->config->addr;
 }
 
 static struct shdma_desc *sh_dmae_embedded_desc(void *buf, int i)
diff --git a/drivers/dma/sh/shdma.h b/drivers/dma/sh/shdma.h
index 840e47d..9314e93 100644
--- a/drivers/dma/sh/shdma.h
+++ b/drivers/dma/sh/shdma.h
@@ -13,6 +13,7 @@
 #ifndef __DMA_SHDMA_H
 #define __DMA_SHDMA_H
 
+#include <linux/sh_dma.h>
 #include <linux/shdma-base.h>
 #include <linux/dmaengine.h>
 #include <linux/interrupt.h>
@@ -25,6 +26,7 @@ struct device;
 
 struct sh_dmae_chan {
 	struct shdma_chan shdma_chan;
+	const struct sh_dmae_slave_config *config; /* Slave DMA configuration */
 	int xmit_shift;			/* log_2(bytes_per_xfer) */
 	u32 __iomem *base;
 	char dev_id[16];		/* unique name per DMAC of channel */
diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
index 7c8ca41..a79f10a 100644
--- a/include/linux/sh_dma.h
+++ b/include/linux/sh_dma.h
@@ -20,8 +20,6 @@ struct device;
 /* Used by slave DMA clients to request DMA to/from a specific peripheral */
 struct sh_dmae_slave {
 	struct shdma_slave		shdma_slave;	/* Set by the platform */
-	struct device			*dma_dev;	/* Set by the platform */
-	const struct sh_dmae_slave_config *config;	/* Set by the driver */
 };
 
 /*
diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
index 83efd13..c3a19e9 100644
--- a/include/linux/shdma-base.h
+++ b/include/linux/shdma-base.h
@@ -66,6 +66,7 @@ struct shdma_chan {
 	size_t max_xfer_len;		/* max transfer length */
 	int id;				/* Raw id of this channel */
 	int irq;			/* Channel IRQ */
+	struct shdma_slave *slave;	/* Client data for slave DMA */
 	enum shdma_pm_state pm_state;
 };
 
-- 
1.7.2.5

[PATCH 4/7 v2] dmaengine: shdma: prepare to stop using struct dma_chan::private

[Guennadi Liakhovetski]

Using struct dma_chan::private is deprecated. To update the shdma driver to
stop using it we first have to eliminate internal runtime uses of it. After
that we will also be able to stop using it for channel configuration.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
 drivers/dma/sh/shdma-base.c |    9 +++++----
 drivers/dma/sh/shdma.c      |   24 ++++++++++--------------
 drivers/dma/sh/shdma.h      |    2 ++
 include/linux/sh_dma.h      |    2 --
 include/linux/shdma-base.h  |    1 +
 5 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
index ff060d0..f75ebfa 100644
--- a/drivers/dma/sh/shdma-base.c
+++ b/drivers/dma/sh/shdma-base.c
@@ -76,7 +76,7 @@ static dma_cookie_t shdma_tx_submit(struct dma_async_tx_descriptor *tx)
 		container_of(tx, struct shdma_desc, async_tx),
 		*last = desc;
 	struct shdma_chan *schan = to_shdma_chan(tx->chan);
-	struct shdma_slave *slave = tx->chan->private;
+	struct shdma_slave *slave = schan->slave;
 	dma_async_tx_callback callback = tx->callback;
 	dma_cookie_t cookie;
 	bool power_up;
@@ -208,6 +208,7 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
 		goto edescalloc;
 	}
 	schan->desc_num = NR_DESCS_PER_CHANNEL;
+	schan->slave = slave;
 
 	for (i = 0; i < NR_DESCS_PER_CHANNEL; i++) {
 		desc = ops->embedded_desc(schan->desc, i);
@@ -365,9 +366,9 @@ static void shdma_free_chan_resources(struct dma_chan *chan)
 	if (!list_empty(&schan->ld_queue))
 		shdma_chan_ld_cleanup(schan, true);
 
-	if (chan->private) {
+	if (schan->slave) {
 		/* The caller is holding dma_list_mutex */
-		struct shdma_slave *slave = chan->private;
+		struct shdma_slave *slave = schan->slave;
 		clear_bit(slave->slave_id, shdma_slave_used);
 		chan->private = NULL;
 	}
@@ -558,7 +559,7 @@ static struct dma_async_tx_descriptor *shdma_prep_slave_sg(
 	struct shdma_chan *schan = to_shdma_chan(chan);
 	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
 	const struct shdma_ops *ops = sdev->ops;
-	struct shdma_slave *slave = chan->private;
+	struct shdma_slave *slave = schan->slave;
 	dma_addr_t slave_addr;
 
 	if (!chan)
diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
index f06906f..9f0a2e5 100644
--- a/drivers/dma/sh/shdma.c
+++ b/drivers/dma/sh/shdma.c
@@ -291,10 +291,8 @@ static void sh_dmae_setup_xfer(struct shdma_chan *schan,
 						    shdma_chan);
 
 	if (sslave) {
-		struct sh_dmae_slave *slave = container_of(sslave,
-					struct sh_dmae_slave, shdma_slave);
 		const struct sh_dmae_slave_config *cfg =
-			slave->config;
+			sh_chan->config;
 
 		dmae_set_dmars(sh_chan, cfg->mid_rid);
 		dmae_set_chcr(sh_chan, cfg->chcr);
@@ -326,13 +324,11 @@ static int sh_dmae_set_slave(struct shdma_chan *schan,
 {
 	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
 						    shdma_chan);
-	struct sh_dmae_slave *slave = container_of(sslave, struct sh_dmae_slave,
-						   shdma_slave);
 	const struct sh_dmae_slave_config *cfg = dmae_find_slave(sh_chan, sslave->slave_id);
 	if (!cfg)
 		return -ENODEV;
 
-	slave->config = cfg;
+	sh_chan->config = cfg;
 
 	return 0;
 }
@@ -579,13 +575,12 @@ static int sh_dmae_resume(struct device *dev)
 
 	for (i = 0; i < shdev->pdata->channel_num; i++) {
 		struct sh_dmae_chan *sh_chan = shdev->chan[i];
-		struct sh_dmae_slave *param = sh_chan->shdma_chan.dma_chan.private;
 
 		if (!sh_chan->shdma_chan.desc_num)
 			continue;
 
-		if (param) {
-			const struct sh_dmae_slave_config *cfg = param->config;
+		if (sh_chan->shdma_chan.slave) {
+			const struct sh_dmae_slave_config *cfg = sh_chan->config;
 			dmae_set_dmars(sh_chan, cfg->mid_rid);
 			dmae_set_chcr(sh_chan, cfg->chcr);
 		} else {
@@ -609,14 +604,15 @@ const struct dev_pm_ops sh_dmae_pm = {
 
 static dma_addr_t sh_dmae_slave_addr(struct shdma_chan *schan)
 {
-	struct sh_dmae_slave *param = schan->dma_chan.private;
+	struct sh_dmae_chan *sh_chan = container_of(schan,
+					struct sh_dmae_chan, shdma_chan);
 
 	/*
-	 * Implicit BUG_ON(!param)
-	 * if (param != NULL), this is a successfully requested slave channel,
-	 * therefore param->config != NULL too.
+	 * Implicit BUG_ON(!sh_chan->config)
+	 * This is an exclusive slave DMA operation, may only be called after a
+	 * successful slave configuration.
 	 */
-	return param->config->addr;
+	return sh_chan->config->addr;
 }
 
 static struct shdma_desc *sh_dmae_embedded_desc(void *buf, int i)
diff --git a/drivers/dma/sh/shdma.h b/drivers/dma/sh/shdma.h
index 840e47d..9314e93 100644
--- a/drivers/dma/sh/shdma.h
+++ b/drivers/dma/sh/shdma.h
@@ -13,6 +13,7 @@
 #ifndef __DMA_SHDMA_H
 #define __DMA_SHDMA_H
 
+#include <linux/sh_dma.h>
 #include <linux/shdma-base.h>
 #include <linux/dmaengine.h>
 #include <linux/interrupt.h>
@@ -25,6 +26,7 @@ struct device;
 
 struct sh_dmae_chan {
 	struct shdma_chan shdma_chan;
+	const struct sh_dmae_slave_config *config; /* Slave DMA configuration */
 	int xmit_shift;			/* log_2(bytes_per_xfer) */
 	u32 __iomem *base;
 	char dev_id[16];		/* unique name per DMAC of channel */
diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
index 7c8ca41..a79f10a 100644
--- a/include/linux/sh_dma.h
+++ b/include/linux/sh_dma.h
@@ -20,8 +20,6 @@ struct device;
 /* Used by slave DMA clients to request DMA to/from a specific peripheral */
 struct sh_dmae_slave {
 	struct shdma_slave		shdma_slave;	/* Set by the platform */
-	struct device			*dma_dev;	/* Set by the platform */
-	const struct sh_dmae_slave_config *config;	/* Set by the driver */
 };
 
 /*
diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
index 83efd13..c3a19e9 100644
--- a/include/linux/shdma-base.h
+++ b/include/linux/shdma-base.h
@@ -66,6 +66,7 @@ struct shdma_chan {
 	size_t max_xfer_len;		/* max transfer length */
 	int id;				/* Raw id of this channel */
 	int irq;			/* Channel IRQ */
+	struct shdma_slave *slave;	/* Client data for slave DMA */
 	enum shdma_pm_state pm_state;
 };
 
-- 
1.7.2.5

[PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

Initially struct shdma_slave has been introduced with the only member - an
unsigned slave ID - to describe common properties of DMA slaves in an
extensible way. However, experience shows, that a slave ID is indeed the
only parameter, needed to identify DMA slaves. This is also, what is used
by the core dmaengine API in struct dma_slave_config. We switch to using
the slave_id directly, instead of passing a pointer to struct shdma_slave
to improve compatibility with the core. We also make the slave_id signed
for easier error checking.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
 drivers/dma/sh/shdma-base.c |   25 +++++++++++++------------
 drivers/dma/sh/shdma.c      |   12 ++++++------
 include/linux/sh_dma.h      |    8 ++++----
 include/linux/shdma-base.h  |    8 ++++----
 4 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
index f75ebfa..73db282 100644
--- a/drivers/dma/sh/shdma-base.c
+++ b/drivers/dma/sh/shdma-base.c
@@ -76,7 +76,6 @@ static dma_cookie_t shdma_tx_submit(struct dma_async_tx_descriptor *tx)
 		container_of(tx, struct shdma_desc, async_tx),
 		*last = desc;
 	struct shdma_chan *schan = to_shdma_chan(tx->chan);
-	struct shdma_slave *slave = schan->slave;
 	dma_async_tx_callback callback = tx->callback;
 	dma_cookie_t cookie;
 	bool power_up;
@@ -138,7 +137,7 @@ static dma_cookie_t shdma_tx_submit(struct dma_async_tx_descriptor *tx)
 			 * Make it int then, on error remove chunks from the
 			 * queue again
 			 */
-			ops->setup_xfer(schan, slave);
+			ops->setup_xfer(schan, schan->slave_id);
 
 			if (schan->pm_state = SHDMA_PM_PENDING)
 				shdma_chan_xfer_ld_queue(schan);
@@ -186,7 +185,7 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
 	 * never runs concurrently with itself or free_chan_resources.
 	 */
 	if (slave) {
-		if (slave->slave_id >= slave_num) {
+		if (slave->slave_id < 0 || slave->slave_id >= slave_num) {
 			ret = -EINVAL;
 			goto evalid;
 		}
@@ -196,9 +195,13 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
 			goto etestused;
 		}
 
-		ret = ops->set_slave(schan, slave);
+		ret = ops->set_slave(schan, slave->slave_id);
 		if (ret < 0)
 			goto esetslave;
+
+		schan->slave_id = slave->slave_id;
+	} else {
+		schan->slave_id = -EINVAL;
 	}
 
 	schan->desc = kcalloc(NR_DESCS_PER_CHANNEL,
@@ -208,7 +211,6 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
 		goto edescalloc;
 	}
 	schan->desc_num = NR_DESCS_PER_CHANNEL;
-	schan->slave = slave;
 
 	for (i = 0; i < NR_DESCS_PER_CHANNEL; i++) {
 		desc = ops->embedded_desc(schan->desc, i);
@@ -366,10 +368,9 @@ static void shdma_free_chan_resources(struct dma_chan *chan)
 	if (!list_empty(&schan->ld_queue))
 		shdma_chan_ld_cleanup(schan, true);
 
-	if (schan->slave) {
+	if (schan->slave_id >= 0) {
 		/* The caller is holding dma_list_mutex */
-		struct shdma_slave *slave = schan->slave;
-		clear_bit(slave->slave_id, shdma_slave_used);
+		clear_bit(schan->slave_id, shdma_slave_used);
 		chan->private = NULL;
 	}
 
@@ -559,7 +560,7 @@ static struct dma_async_tx_descriptor *shdma_prep_slave_sg(
 	struct shdma_chan *schan = to_shdma_chan(chan);
 	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
 	const struct shdma_ops *ops = sdev->ops;
-	struct shdma_slave *slave = schan->slave;
+	int slave_id = schan->slave_id;
 	dma_addr_t slave_addr;
 
 	if (!chan)
@@ -568,9 +569,9 @@ static struct dma_async_tx_descriptor *shdma_prep_slave_sg(
 	BUG_ON(!schan->desc_num);
 
 	/* Someone calling slave DMA on a generic channel? */
-	if (!slave || !sg_len) {
-		dev_warn(schan->dev, "%s: bad parameter: %p, %d, %d\n",
-			 __func__, slave, sg_len, slave ? slave->slave_id : -1);
+	if (slave_id < 0 || !sg_len) {
+		dev_warn(schan->dev, "%s: bad parameter: len=%d, id=%d\n",
+			 __func__, sg_len, slave_id);
 		return NULL;
 	}
 
diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
index 9f0a2e5..9a10d8b 100644
--- a/drivers/dma/sh/shdma.c
+++ b/drivers/dma/sh/shdma.c
@@ -285,12 +285,12 @@ static bool sh_dmae_channel_busy(struct shdma_chan *schan)
 }
 
 static void sh_dmae_setup_xfer(struct shdma_chan *schan,
-			       struct shdma_slave *sslave)
+			       int slave_id)
 {
 	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
 						    shdma_chan);
 
-	if (sslave) {
+	if (slave_id >= 0) {
 		const struct sh_dmae_slave_config *cfg  			sh_chan->config;
 
@@ -302,7 +302,7 @@ static void sh_dmae_setup_xfer(struct shdma_chan *schan,
 }
 
 static const struct sh_dmae_slave_config *dmae_find_slave(
-	struct sh_dmae_chan *sh_chan, unsigned int slave_id)
+	struct sh_dmae_chan *sh_chan, int slave_id)
 {
 	struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
 	struct sh_dmae_pdata *pdata = shdev->pdata;
@@ -320,11 +320,11 @@ static const struct sh_dmae_slave_config *dmae_find_slave(
 }
 
 static int sh_dmae_set_slave(struct shdma_chan *schan,
-			     struct shdma_slave *sslave)
+			     int slave_id)
 {
 	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
 						    shdma_chan);
-	const struct sh_dmae_slave_config *cfg = dmae_find_slave(sh_chan, sslave->slave_id);
+	const struct sh_dmae_slave_config *cfg = dmae_find_slave(sh_chan, slave_id);
 	if (!cfg)
 		return -ENODEV;
 
@@ -579,7 +579,7 @@ static int sh_dmae_resume(struct device *dev)
 		if (!sh_chan->shdma_chan.desc_num)
 			continue;
 
-		if (sh_chan->shdma_chan.slave) {
+		if (sh_chan->shdma_chan.slave_id >= 0) {
 			const struct sh_dmae_slave_config *cfg = sh_chan->config;
 			dmae_set_dmars(sh_chan, cfg->mid_rid);
 			dmae_set_chcr(sh_chan, cfg->chcr);
diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
index a79f10a..4e83f3e 100644
--- a/include/linux/sh_dma.h
+++ b/include/linux/sh_dma.h
@@ -27,10 +27,10 @@ struct sh_dmae_slave {
  * a certain peripheral
  */
 struct sh_dmae_slave_config {
-	unsigned int			slave_id;
-	dma_addr_t			addr;
-	u32				chcr;
-	char				mid_rid;
+	int		slave_id;
+	dma_addr_t	addr;
+	u32		chcr;
+	char		mid_rid;
 };
 
 struct sh_dmae_channel {
diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
index c3a19e9..6263ad2 100644
--- a/include/linux/shdma-base.h
+++ b/include/linux/shdma-base.h
@@ -43,7 +43,7 @@ struct device;
  */
 
 struct shdma_slave {
-	unsigned int slave_id;
+	int slave_id;
 };
 
 struct shdma_desc {
@@ -66,7 +66,7 @@ struct shdma_chan {
 	size_t max_xfer_len;		/* max transfer length */
 	int id;				/* Raw id of this channel */
 	int irq;			/* Channel IRQ */
-	struct shdma_slave *slave;	/* Client data for slave DMA */
+	int slave_id;			/* Client ID for slave DMA */
 	enum shdma_pm_state pm_state;
 };
 
@@ -93,8 +93,8 @@ struct shdma_ops {
 	dma_addr_t (*slave_addr)(struct shdma_chan *);
 	int (*desc_setup)(struct shdma_chan *, struct shdma_desc *,
 			  dma_addr_t, dma_addr_t, size_t *);
-	int (*set_slave)(struct shdma_chan *, struct shdma_slave *);
-	void (*setup_xfer)(struct shdma_chan *, struct shdma_slave *);
+	int (*set_slave)(struct shdma_chan *, int);
+	void (*setup_xfer)(struct shdma_chan *, int);
 	void (*start_xfer)(struct shdma_chan *, struct shdma_desc *);
 	struct shdma_desc *(*embedded_desc)(void *, int);
 	bool (*chan_irq)(struct shdma_chan *, int);
-- 
1.7.2.5

[PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

Initially struct shdma_slave has been introduced with the only member - an
unsigned slave ID - to describe common properties of DMA slaves in an
extensible way. However, experience shows, that a slave ID is indeed the
only parameter, needed to identify DMA slaves. This is also, what is used
by the core dmaengine API in struct dma_slave_config. We switch to using
the slave_id directly, instead of passing a pointer to struct shdma_slave
to improve compatibility with the core. We also make the slave_id signed
for easier error checking.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
 drivers/dma/sh/shdma-base.c |   25 +++++++++++++------------
 drivers/dma/sh/shdma.c      |   12 ++++++------
 include/linux/sh_dma.h      |    8 ++++----
 include/linux/shdma-base.h  |    8 ++++----
 4 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
index f75ebfa..73db282 100644
--- a/drivers/dma/sh/shdma-base.c
+++ b/drivers/dma/sh/shdma-base.c
@@ -76,7 +76,6 @@ static dma_cookie_t shdma_tx_submit(struct dma_async_tx_descriptor *tx)
 		container_of(tx, struct shdma_desc, async_tx),
 		*last = desc;
 	struct shdma_chan *schan = to_shdma_chan(tx->chan);
-	struct shdma_slave *slave = schan->slave;
 	dma_async_tx_callback callback = tx->callback;
 	dma_cookie_t cookie;
 	bool power_up;
@@ -138,7 +137,7 @@ static dma_cookie_t shdma_tx_submit(struct dma_async_tx_descriptor *tx)
 			 * Make it int then, on error remove chunks from the
 			 * queue again
 			 */
-			ops->setup_xfer(schan, slave);
+			ops->setup_xfer(schan, schan->slave_id);
 
 			if (schan->pm_state == SHDMA_PM_PENDING)
 				shdma_chan_xfer_ld_queue(schan);
@@ -186,7 +185,7 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
 	 * never runs concurrently with itself or free_chan_resources.
 	 */
 	if (slave) {
-		if (slave->slave_id >= slave_num) {
+		if (slave->slave_id < 0 || slave->slave_id >= slave_num) {
 			ret = -EINVAL;
 			goto evalid;
 		}
@@ -196,9 +195,13 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
 			goto etestused;
 		}
 
-		ret = ops->set_slave(schan, slave);
+		ret = ops->set_slave(schan, slave->slave_id);
 		if (ret < 0)
 			goto esetslave;
+
+		schan->slave_id = slave->slave_id;
+	} else {
+		schan->slave_id = -EINVAL;
 	}
 
 	schan->desc = kcalloc(NR_DESCS_PER_CHANNEL,
@@ -208,7 +211,6 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
 		goto edescalloc;
 	}
 	schan->desc_num = NR_DESCS_PER_CHANNEL;
-	schan->slave = slave;
 
 	for (i = 0; i < NR_DESCS_PER_CHANNEL; i++) {
 		desc = ops->embedded_desc(schan->desc, i);
@@ -366,10 +368,9 @@ static void shdma_free_chan_resources(struct dma_chan *chan)
 	if (!list_empty(&schan->ld_queue))
 		shdma_chan_ld_cleanup(schan, true);
 
-	if (schan->slave) {
+	if (schan->slave_id >= 0) {
 		/* The caller is holding dma_list_mutex */
-		struct shdma_slave *slave = schan->slave;
-		clear_bit(slave->slave_id, shdma_slave_used);
+		clear_bit(schan->slave_id, shdma_slave_used);
 		chan->private = NULL;
 	}
 
@@ -559,7 +560,7 @@ static struct dma_async_tx_descriptor *shdma_prep_slave_sg(
 	struct shdma_chan *schan = to_shdma_chan(chan);
 	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
 	const struct shdma_ops *ops = sdev->ops;
-	struct shdma_slave *slave = schan->slave;
+	int slave_id = schan->slave_id;
 	dma_addr_t slave_addr;
 
 	if (!chan)
@@ -568,9 +569,9 @@ static struct dma_async_tx_descriptor *shdma_prep_slave_sg(
 	BUG_ON(!schan->desc_num);
 
 	/* Someone calling slave DMA on a generic channel? */
-	if (!slave || !sg_len) {
-		dev_warn(schan->dev, "%s: bad parameter: %p, %d, %d\n",
-			 __func__, slave, sg_len, slave ? slave->slave_id : -1);
+	if (slave_id < 0 || !sg_len) {
+		dev_warn(schan->dev, "%s: bad parameter: len=%d, id=%d\n",
+			 __func__, sg_len, slave_id);
 		return NULL;
 	}
 
diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
index 9f0a2e5..9a10d8b 100644
--- a/drivers/dma/sh/shdma.c
+++ b/drivers/dma/sh/shdma.c
@@ -285,12 +285,12 @@ static bool sh_dmae_channel_busy(struct shdma_chan *schan)
 }
 
 static void sh_dmae_setup_xfer(struct shdma_chan *schan,
-			       struct shdma_slave *sslave)
+			       int slave_id)
 {
 	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
 						    shdma_chan);
 
-	if (sslave) {
+	if (slave_id >= 0) {
 		const struct sh_dmae_slave_config *cfg =
 			sh_chan->config;
 
@@ -302,7 +302,7 @@ static void sh_dmae_setup_xfer(struct shdma_chan *schan,
 }
 
 static const struct sh_dmae_slave_config *dmae_find_slave(
-	struct sh_dmae_chan *sh_chan, unsigned int slave_id)
+	struct sh_dmae_chan *sh_chan, int slave_id)
 {
 	struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
 	struct sh_dmae_pdata *pdata = shdev->pdata;
@@ -320,11 +320,11 @@ static const struct sh_dmae_slave_config *dmae_find_slave(
 }
 
 static int sh_dmae_set_slave(struct shdma_chan *schan,
-			     struct shdma_slave *sslave)
+			     int slave_id)
 {
 	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
 						    shdma_chan);
-	const struct sh_dmae_slave_config *cfg = dmae_find_slave(sh_chan, sslave->slave_id);
+	const struct sh_dmae_slave_config *cfg = dmae_find_slave(sh_chan, slave_id);
 	if (!cfg)
 		return -ENODEV;
 
@@ -579,7 +579,7 @@ static int sh_dmae_resume(struct device *dev)
 		if (!sh_chan->shdma_chan.desc_num)
 			continue;
 
-		if (sh_chan->shdma_chan.slave) {
+		if (sh_chan->shdma_chan.slave_id >= 0) {
 			const struct sh_dmae_slave_config *cfg = sh_chan->config;
 			dmae_set_dmars(sh_chan, cfg->mid_rid);
 			dmae_set_chcr(sh_chan, cfg->chcr);
diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
index a79f10a..4e83f3e 100644
--- a/include/linux/sh_dma.h
+++ b/include/linux/sh_dma.h
@@ -27,10 +27,10 @@ struct sh_dmae_slave {
  * a certain peripheral
  */
 struct sh_dmae_slave_config {
-	unsigned int			slave_id;
-	dma_addr_t			addr;
-	u32				chcr;
-	char				mid_rid;
+	int		slave_id;
+	dma_addr_t	addr;
+	u32		chcr;
+	char		mid_rid;
 };
 
 struct sh_dmae_channel {
diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
index c3a19e9..6263ad2 100644
--- a/include/linux/shdma-base.h
+++ b/include/linux/shdma-base.h
@@ -43,7 +43,7 @@ struct device;
  */
 
 struct shdma_slave {
-	unsigned int slave_id;
+	int slave_id;
 };
 
 struct shdma_desc {
@@ -66,7 +66,7 @@ struct shdma_chan {
 	size_t max_xfer_len;		/* max transfer length */
 	int id;				/* Raw id of this channel */
 	int irq;			/* Channel IRQ */
-	struct shdma_slave *slave;	/* Client data for slave DMA */
+	int slave_id;			/* Client ID for slave DMA */
 	enum shdma_pm_state pm_state;
 };
 
@@ -93,8 +93,8 @@ struct shdma_ops {
 	dma_addr_t (*slave_addr)(struct shdma_chan *);
 	int (*desc_setup)(struct shdma_chan *, struct shdma_desc *,
 			  dma_addr_t, dma_addr_t, size_t *);
-	int (*set_slave)(struct shdma_chan *, struct shdma_slave *);
-	void (*setup_xfer)(struct shdma_chan *, struct shdma_slave *);
+	int (*set_slave)(struct shdma_chan *, int);
+	void (*setup_xfer)(struct shdma_chan *, int);
 	void (*start_xfer)(struct shdma_chan *, struct shdma_desc *);
 	struct shdma_desc *(*embedded_desc)(void *, int);
 	bool (*chan_irq)(struct shdma_chan *, int);
-- 
1.7.2.5

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> index a79f10a..4e83f3e 100644
> --- a/include/linux/sh_dma.h
> +++ b/include/linux/sh_dma.h
> @@ -27,10 +27,10 @@ struct sh_dmae_slave {
>   * a certain peripheral
>   */
>  struct sh_dmae_slave_config {
> -       unsigned int                    slave_id;
> -       dma_addr_t                      addr;
> -       u32                             chcr;
> -       char                            mid_rid;
> +       int             slave_id;
> +       dma_addr_t      addr;
> +       u32             chcr;
> +       char            mid_rid;
>  }; 
why would you want to keep your own slave_id and addr fields when they
are already provided in struct dma_slave_config. Also while at it, what
would be the use of last tow fields, what do they describe?
Would it be possible to get rid of this structure completely? At least
first two fields should go away.

-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> index a79f10a..4e83f3e 100644
> --- a/include/linux/sh_dma.h
> +++ b/include/linux/sh_dma.h
> @@ -27,10 +27,10 @@ struct sh_dmae_slave {
>   * a certain peripheral
>   */
>  struct sh_dmae_slave_config {
> -       unsigned int                    slave_id;
> -       dma_addr_t                      addr;
> -       u32                             chcr;
> -       char                            mid_rid;
> +       int             slave_id;
> +       dma_addr_t      addr;
> +       u32             chcr;
> +       char            mid_rid;
>  }; 
why would you want to keep your own slave_id and addr fields when they
are already provided in struct dma_slave_config. Also while at it, what
would be the use of last tow fields, what do they describe?
Would it be possible to get rid of this structure completely? At least
first two fields should go away.

-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> > diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> > index a79f10a..4e83f3e 100644
> > --- a/include/linux/sh_dma.h
> > +++ b/include/linux/sh_dma.h
> > @@ -27,10 +27,10 @@ struct sh_dmae_slave {
> >   * a certain peripheral
> >   */
> >  struct sh_dmae_slave_config {
> > -       unsigned int                    slave_id;
> > -       dma_addr_t                      addr;
> > -       u32                             chcr;
> > -       char                            mid_rid;
> > +       int             slave_id;
> > +       dma_addr_t      addr;
> > +       u32             chcr;
> > +       char            mid_rid;
> >  }; 
> why would you want to keep your own slave_id and addr fields when they
> are already provided in struct dma_slave_config.

Modifying the driver's API would break all its clients.

> Also while at it, what
> would be the use of last tow fields, what do they describe?

They tell the driver how the channel has to be configured to support this 
specific client. They are values of two specific registers. In fact, CHCR 
means exactly that - CHannel Control Register.

> Would it be possible to get rid of this structure completely? At least
> first two fields should go away.

Migration has to be performed gradually. If this approach and patches are 
accepted, then all client drivers can be migrated, then thr legacy API can 
be dropped.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> > diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> > index a79f10a..4e83f3e 100644
> > --- a/include/linux/sh_dma.h
> > +++ b/include/linux/sh_dma.h
> > @@ -27,10 +27,10 @@ struct sh_dmae_slave {
> >   * a certain peripheral
> >   */
> >  struct sh_dmae_slave_config {
> > -       unsigned int                    slave_id;
> > -       dma_addr_t                      addr;
> > -       u32                             chcr;
> > -       char                            mid_rid;
> > +       int             slave_id;
> > +       dma_addr_t      addr;
> > +       u32             chcr;
> > +       char            mid_rid;
> >  }; 
> why would you want to keep your own slave_id and addr fields when they
> are already provided in struct dma_slave_config.

Modifying the driver's API would break all its clients.

> Also while at it, what
> would be the use of last tow fields, what do they describe?

They tell the driver how the channel has to be configured to support this 
specific client. They are values of two specific registers. In fact, CHCR 
means exactly that - CHannel Control Register.

> Would it be possible to get rid of this structure completely? At least
> first two fields should go away.

Migration has to be performed gradually. If this approach and patches are 
accepted, then all client drivers can be migrated, then thr legacy API can 
be dropped.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 08:37 +0200, Guennadi Liakhovetski wrote:
> On Mon, 16 Jul 2012, Vinod Koul wrote:
> 
> > On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> > > diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> > > index a79f10a..4e83f3e 100644
> > > --- a/include/linux/sh_dma.h
> > > +++ b/include/linux/sh_dma.h
> > > @@ -27,10 +27,10 @@ struct sh_dmae_slave {
> > >   * a certain peripheral
> > >   */
> > >  struct sh_dmae_slave_config {
> > > -       unsigned int                    slave_id;
> > > -       dma_addr_t                      addr;
> > > -       u32                             chcr;
> > > -       char                            mid_rid;
> > > +       int             slave_id;
> > > +       dma_addr_t      addr;
> > > +       u32             chcr;
> > > +       char            mid_rid;
> > >  }; 
> > why would you want to keep your own slave_id and addr fields when they
> > are already provided in struct dma_slave_config.
> 
> Modifying the driver's API would break all its clients.
rightly so, they need to be moved too.

> 
> > Also while at it, what
> > would be the use of last tow fields, what do they describe?
> 
> They tell the driver how the channel has to be configured to support this 
> specific client. They are values of two specific registers. In fact, CHCR 
> means exactly that - CHannel Control Register.
what exactly does the channel control register do in shdma? Should shdma
driver deduce this value rather than client giving it?
Same question for mid_rid?


-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 08:37 +0200, Guennadi Liakhovetski wrote:
> On Mon, 16 Jul 2012, Vinod Koul wrote:
> 
> > On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> > > diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> > > index a79f10a..4e83f3e 100644
> > > --- a/include/linux/sh_dma.h
> > > +++ b/include/linux/sh_dma.h
> > > @@ -27,10 +27,10 @@ struct sh_dmae_slave {
> > >   * a certain peripheral
> > >   */
> > >  struct sh_dmae_slave_config {
> > > -       unsigned int                    slave_id;
> > > -       dma_addr_t                      addr;
> > > -       u32                             chcr;
> > > -       char                            mid_rid;
> > > +       int             slave_id;
> > > +       dma_addr_t      addr;
> > > +       u32             chcr;
> > > +       char            mid_rid;
> > >  }; 
> > why would you want to keep your own slave_id and addr fields when they
> > are already provided in struct dma_slave_config.
> 
> Modifying the driver's API would break all its clients.
rightly so, they need to be moved too.

> 
> > Also while at it, what
> > would be the use of last tow fields, what do they describe?
> 
> They tell the driver how the channel has to be configured to support this 
> specific client. They are values of two specific registers. In fact, CHCR 
> means exactly that - CHannel Control Register.
what exactly does the channel control register do in shdma? Should shdma
driver deduce this value rather than client giving it?
Same question for mid_rid?


-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 08:37 +0200, Guennadi Liakhovetski wrote:
> > On Mon, 16 Jul 2012, Vinod Koul wrote:
> > 
> > > On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> > > > diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> > > > index a79f10a..4e83f3e 100644
> > > > --- a/include/linux/sh_dma.h
> > > > +++ b/include/linux/sh_dma.h
> > > > @@ -27,10 +27,10 @@ struct sh_dmae_slave {
> > > >   * a certain peripheral
> > > >   */
> > > >  struct sh_dmae_slave_config {
> > > > -       unsigned int                    slave_id;
> > > > -       dma_addr_t                      addr;
> > > > -       u32                             chcr;
> > > > -       char                            mid_rid;
> > > > +       int             slave_id;
> > > > +       dma_addr_t      addr;
> > > > +       u32             chcr;
> > > > +       char            mid_rid;
> > > >  }; 
> > > why would you want to keep your own slave_id and addr fields when they
> > > are already provided in struct dma_slave_config.
> > 
> > Modifying the driver's API would break all its clients.
> rightly so, they need to be moved too.

Sure, that's why patch 6/7 is "providing a migration path" for them.

> > > Also while at it, what
> > > would be the use of last tow fields, what do they describe?
> > 
> > They tell the driver how the channel has to be configured to support this 
> > specific client. They are values of two specific registers. In fact, CHCR 
> > means exactly that - CHannel Control Register.
> what exactly does the channel control register do in shdma? Should shdma
> driver deduce this value rather than client giving it?
> Same question for mid_rid?

See, e.g., arch/arm/mach-shmobile/setup-sh7372.c::sh7372_dmae_slaves[]. 
Platforms are supplying these values with shdma driver platform data, 
together with slave IDs. Them when slaves request channels and supply 
their slave IDs, the driver searches the above array, looking for the 
matching slave ID, then it uses the rest of the information in those 
structs to configure the channel for this client. Again, this is nothing 
new, this is how the driver has been functioning since a long time, this 
driver is not modifying anything there. Any changes to this procedure, 
like providing all thig information from clients themselves instead of 
keeping it with DMACs, requires these patches to be committed first.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 08:37 +0200, Guennadi Liakhovetski wrote:
> > On Mon, 16 Jul 2012, Vinod Koul wrote:
> > 
> > > On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> > > > diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> > > > index a79f10a..4e83f3e 100644
> > > > --- a/include/linux/sh_dma.h
> > > > +++ b/include/linux/sh_dma.h
> > > > @@ -27,10 +27,10 @@ struct sh_dmae_slave {
> > > >   * a certain peripheral
> > > >   */
> > > >  struct sh_dmae_slave_config {
> > > > -       unsigned int                    slave_id;
> > > > -       dma_addr_t                      addr;
> > > > -       u32                             chcr;
> > > > -       char                            mid_rid;
> > > > +       int             slave_id;
> > > > +       dma_addr_t      addr;
> > > > +       u32             chcr;
> > > > +       char            mid_rid;
> > > >  }; 
> > > why would you want to keep your own slave_id and addr fields when they
> > > are already provided in struct dma_slave_config.
> > 
> > Modifying the driver's API would break all its clients.
> rightly so, they need to be moved too.

Sure, that's why patch 6/7 is "providing a migration path" for them.

> > > Also while at it, what
> > > would be the use of last tow fields, what do they describe?
> > 
> > They tell the driver how the channel has to be configured to support this 
> > specific client. They are values of two specific registers. In fact, CHCR 
> > means exactly that - CHannel Control Register.
> what exactly does the channel control register do in shdma? Should shdma
> driver deduce this value rather than client giving it?
> Same question for mid_rid?

See, e.g., arch/arm/mach-shmobile/setup-sh7372.c::sh7372_dmae_slaves[]. 
Platforms are supplying these values with shdma driver platform data, 
together with slave IDs. Them when slaves request channels and supply 
their slave IDs, the driver searches the above array, looking for the 
matching slave ID, then it uses the rest of the information in those 
structs to configure the channel for this client. Again, this is nothing 
new, this is how the driver has been functioning since a long time, this 
driver is not modifying anything there. Any changes to this procedure, 
like providing all thig information from clients themselves instead of 
keeping it with DMACs, requires these patches to be committed first.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 09:13 +0200, Guennadi Liakhovetski wrote:
> > > They tell the driver how the channel has to be configured to
> support this 
> > > specific client. They are values of two specific registers. In
> fact, CHCR 
> > > means exactly that - CHannel Control Register.
> > what exactly does the channel control register do in shdma? Should
> shdma
> > driver deduce this value rather than client giving it?
> > Same question for mid_rid?
> 
> See, e.g.,
> arch/arm/mach-shmobile/setup-sh7372.c::sh7372_dmae_slaves[]. 
> Platforms are supplying these values with shdma driver platform data, 
> together with slave IDs. Them when slaves request channels and supply 
> their slave IDs, the driver searches the above array, looking for the 
> matching slave ID, then it uses the rest of the information in those 
> structs to configure the channel for this client. Again, this is
> nothing 
> new, this is how the driver has been functioning since a long time,
> this 
> driver is not modifying anything there. Any changes to this
> procedure, 
> like providing all thig information from clients themselves instead
> of 
> keeping it with DMACs, requires these patches to be committed first.
That wasn't my question.

I want to know what does ccr and mid_rid mean to dmac here?

-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 09:13 +0200, Guennadi Liakhovetski wrote:
> > > They tell the driver how the channel has to be configured to
> support this 
> > > specific client. They are values of two specific registers. In
> fact, CHCR 
> > > means exactly that - CHannel Control Register.
> > what exactly does the channel control register do in shdma? Should
> shdma
> > driver deduce this value rather than client giving it?
> > Same question for mid_rid?
> 
> See, e.g.,
> arch/arm/mach-shmobile/setup-sh7372.c::sh7372_dmae_slaves[]. 
> Platforms are supplying these values with shdma driver platform data, 
> together with slave IDs. Them when slaves request channels and supply 
> their slave IDs, the driver searches the above array, looking for the 
> matching slave ID, then it uses the rest of the information in those 
> structs to configure the channel for this client. Again, this is
> nothing 
> new, this is how the driver has been functioning since a long time,
> this 
> driver is not modifying anything there. Any changes to this
> procedure, 
> like providing all thig information from clients themselves instead
> of 
> keeping it with DMACs, requires these patches to be committed first.
That wasn't my question.

I want to know what does ccr and mid_rid mean to dmac here?

-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 09:13 +0200, Guennadi Liakhovetski wrote:
> > > > They tell the driver how the channel has to be configured to
> > support this 
> > > > specific client. They are values of two specific registers. In
> > fact, CHCR 
> > > > means exactly that - CHannel Control Register.
> > > what exactly does the channel control register do in shdma? Should
> > shdma
> > > driver deduce this value rather than client giving it?
> > > Same question for mid_rid?
> > 
> > See, e.g.,
> > arch/arm/mach-shmobile/setup-sh7372.c::sh7372_dmae_slaves[]. 
> > Platforms are supplying these values with shdma driver platform data, 
> > together with slave IDs. Them when slaves request channels and supply 
> > their slave IDs, the driver searches the above array, looking for the 
> > matching slave ID, then it uses the rest of the information in those 
> > structs to configure the channel for this client. Again, this is
> > nothing 
> > new, this is how the driver has been functioning since a long time,
> > this 
> > driver is not modifying anything there. Any changes to this
> > procedure, 
> > like providing all thig information from clients themselves instead
> > of 
> > keeping it with DMACs, requires these patches to be committed first.
> That wasn't my question.
> 
> I want to know what does ccr and mid_rid mean to dmac here?

CHCR contains a few fields, some enable various interrupt sources, some 
specify repeat- and renew-modes, others yet specify transfer size, source 
and destination address-modes (incrementing, constant, decrementing), 
others yet select a DMA client category (slave / memcpy / ...), and a 
transfer flag. Some of these fields could be calculated, others are 
pre-defined for various slaves, the exact layout of those fields can also 
vary between SoCs.

MID_RID is actually a slave-selector, it contains a magic value, that 
cannot be calculated.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 09:13 +0200, Guennadi Liakhovetski wrote:
> > > > They tell the driver how the channel has to be configured to
> > support this 
> > > > specific client. They are values of two specific registers. In
> > fact, CHCR 
> > > > means exactly that - CHannel Control Register.
> > > what exactly does the channel control register do in shdma? Should
> > shdma
> > > driver deduce this value rather than client giving it?
> > > Same question for mid_rid?
> > 
> > See, e.g.,
> > arch/arm/mach-shmobile/setup-sh7372.c::sh7372_dmae_slaves[]. 
> > Platforms are supplying these values with shdma driver platform data, 
> > together with slave IDs. Them when slaves request channels and supply 
> > their slave IDs, the driver searches the above array, looking for the 
> > matching slave ID, then it uses the rest of the information in those 
> > structs to configure the channel for this client. Again, this is
> > nothing 
> > new, this is how the driver has been functioning since a long time,
> > this 
> > driver is not modifying anything there. Any changes to this
> > procedure, 
> > like providing all thig information from clients themselves instead
> > of 
> > keeping it with DMACs, requires these patches to be committed first.
> That wasn't my question.
> 
> I want to know what does ccr and mid_rid mean to dmac here?

CHCR contains a few fields, some enable various interrupt sources, some 
specify repeat- and renew-modes, others yet specify transfer size, source 
and destination address-modes (incrementing, constant, decrementing), 
others yet select a DMA client category (slave / memcpy / ...), and a 
transfer flag. Some of these fields could be calculated, others are 
pre-defined for various slaves, the exact layout of those fields can also 
vary between SoCs.

MID_RID is actually a slave-selector, it contains a magic value, that 
cannot be calculated.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > I want to know what does ccr and mid_rid mean to dmac here?
> 
> CHCR contains a few fields, some enable various interrupt sources, some 
> specify repeat- and renew-modes, others yet specify transfer size, source 
> and destination address-modes (incrementing, constant, decrementing), 
> others yet select a DMA client category (slave / memcpy / ...), and a 
> transfer flag. Some of these fields could be calculated, others are 
> pre-defined for various slaves, the exact layout of those fields can also 
> vary between SoCs.
I do not understand how clients would provide these values. 
For pre-defined values, they should be dmac property why should client
like spi or mmc have clue about it?

For others like you mentioned, i guess they could be easily calculated,
right?

> MID_RID is actually a slave-selector, it contains a magic value, that 
> cannot be calculated. 
and again, how does client know this?

-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > I want to know what does ccr and mid_rid mean to dmac here?
> 
> CHCR contains a few fields, some enable various interrupt sources, some 
> specify repeat- and renew-modes, others yet specify transfer size, source 
> and destination address-modes (incrementing, constant, decrementing), 
> others yet select a DMA client category (slave / memcpy / ...), and a 
> transfer flag. Some of these fields could be calculated, others are 
> pre-defined for various slaves, the exact layout of those fields can also 
> vary between SoCs.
I do not understand how clients would provide these values. 
For pre-defined values, they should be dmac property why should client
like spi or mmc have clue about it?

For others like you mentioned, i guess they could be easily calculated,
right?

> MID_RID is actually a slave-selector, it contains a magic value, that 
> cannot be calculated. 
and again, how does client know this?

-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > > I want to know what does ccr and mid_rid mean to dmac here?
> > 
> > CHCR contains a few fields, some enable various interrupt sources, some 
> > specify repeat- and renew-modes, others yet specify transfer size, source 
> > and destination address-modes (incrementing, constant, decrementing), 
> > others yet select a DMA client category (slave / memcpy / ...), and a 
> > transfer flag. Some of these fields could be calculated, others are 
> > pre-defined for various slaves, the exact layout of those fields can also 
> > vary between SoCs.
> I do not understand how clients would provide these values. 
> For pre-defined values, they should be dmac property why should client
> like spi or mmc have clue about it?
> 
> For others like you mentioned, i guess they could be easily calculated,
> right?
> 
> > MID_RID is actually a slave-selector, it contains a magic value, that 
> > cannot be calculated. 
> and again, how does client know this?

I might be misunderstanding you, but from earlier discussions I got an 
impression, that the DMAC should know nothing about clients, i.e., should 
receive no client-specific information from its platform data. Instead 
clients should provide it when configuring the channel. If this is 
correct, then the preferred way would be to specify these values in client 
platform data and then pass it to the DMAC with slave-config calls? Or 
have I misunderstood you and this per-client information should be kept in 
DMAC platform data?

I.e., in both cases magic values are provided by platforms, the only 
difference is - either keep them in DMAC platform data or move them in 
each individual DMA client platform data.

Yes, some CHCR fields can be calculated, but location and width of those 
fields might vary between DMAC versions, so, they will have to be passed 
with DMAC platform data. But this definitely can be done in the future.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > > I want to know what does ccr and mid_rid mean to dmac here?
> > 
> > CHCR contains a few fields, some enable various interrupt sources, some 
> > specify repeat- and renew-modes, others yet specify transfer size, source 
> > and destination address-modes (incrementing, constant, decrementing), 
> > others yet select a DMA client category (slave / memcpy / ...), and a 
> > transfer flag. Some of these fields could be calculated, others are 
> > pre-defined for various slaves, the exact layout of those fields can also 
> > vary between SoCs.
> I do not understand how clients would provide these values. 
> For pre-defined values, they should be dmac property why should client
> like spi or mmc have clue about it?
> 
> For others like you mentioned, i guess they could be easily calculated,
> right?
> 
> > MID_RID is actually a slave-selector, it contains a magic value, that 
> > cannot be calculated. 
> and again, how does client know this?

I might be misunderstanding you, but from earlier discussions I got an 
impression, that the DMAC should know nothing about clients, i.e., should 
receive no client-specific information from its platform data. Instead 
clients should provide it when configuring the channel. If this is 
correct, then the preferred way would be to specify these values in client 
platform data and then pass it to the DMAC with slave-config calls? Or 
have I misunderstood you and this per-client information should be kept in 
DMAC platform data?

I.e., in both cases magic values are provided by platforms, the only 
difference is - either keep them in DMAC platform data or move them in 
each individual DMA client platform data.

Yes, some CHCR fields can be calculated, but location and width of those 
fields might vary between DMAC versions, so, they will have to be passed 
with DMAC platform data. But this definitely can be done in the future.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 12:01 +0200, Guennadi Liakhovetski wrote:
> On Mon, 16 Jul 2012, Vinod Koul wrote:
> 
> > On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > > > I want to know what does ccr and mid_rid mean to dmac here?
> > > 
> > > CHCR contains a few fields, some enable various interrupt sources, some 
> > > specify repeat- and renew-modes, others yet specify transfer size, source 
> > > and destination address-modes (incrementing, constant, decrementing), 
> > > others yet select a DMA client category (slave / memcpy / ...), and a 
> > > transfer flag. Some of these fields could be calculated, others are 
> > > pre-defined for various slaves, the exact layout of those fields can also 
> > > vary between SoCs.
> > I do not understand how clients would provide these values. 
> > For pre-defined values, they should be dmac property why should client
> > like spi or mmc have clue about it?
> > 
> > For others like you mentioned, i guess they could be easily calculated,
> > right?
> > 
> > > MID_RID is actually a slave-selector, it contains a magic value, that 
> > > cannot be calculated. 
> > and again, how does client know this?
> 
> I might be misunderstanding you, but from earlier discussions I got an 
> impression, that the DMAC should know nothing about clients, i.e., should 
> receive no client-specific information from its platform data. Instead 
> clients should provide it when configuring the channel. If this is 
> correct, then the preferred way would be to specify these values in client 
> platform data and then pass it to the DMAC with slave-config calls? Or 
> have I misunderstood you and this per-client information should be kept in 
> DMAC platform data?
You haven't misunderstood me. dmacs should not know of client data and
should be client agnostic. 

BUT, are these parameters ccr and mid_rid client data, i do not think
so, they seem to be dmac controller parameters which you need to
configure channel or is that not the case. If not why bother passing
them to dmac?

Either way something looks fishy to me.
> 
> I.e., in both cases magic values are provided by platforms, the only 
> difference is - either keep them in DMAC platform data or move them in 
> each individual DMA client platform data.
> 
> Yes, some CHCR fields can be calculated, but location and width of those 
> fields might vary between DMAC versions, so, they will have to be passed 
> with DMAC platform data. But this definitely can be done in the future.


-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 12:01 +0200, Guennadi Liakhovetski wrote:
> On Mon, 16 Jul 2012, Vinod Koul wrote:
> 
> > On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > > > I want to know what does ccr and mid_rid mean to dmac here?
> > > 
> > > CHCR contains a few fields, some enable various interrupt sources, some 
> > > specify repeat- and renew-modes, others yet specify transfer size, source 
> > > and destination address-modes (incrementing, constant, decrementing), 
> > > others yet select a DMA client category (slave / memcpy / ...), and a 
> > > transfer flag. Some of these fields could be calculated, others are 
> > > pre-defined for various slaves, the exact layout of those fields can also 
> > > vary between SoCs.
> > I do not understand how clients would provide these values. 
> > For pre-defined values, they should be dmac property why should client
> > like spi or mmc have clue about it?
> > 
> > For others like you mentioned, i guess they could be easily calculated,
> > right?
> > 
> > > MID_RID is actually a slave-selector, it contains a magic value, that 
> > > cannot be calculated. 
> > and again, how does client know this?
> 
> I might be misunderstanding you, but from earlier discussions I got an 
> impression, that the DMAC should know nothing about clients, i.e., should 
> receive no client-specific information from its platform data. Instead 
> clients should provide it when configuring the channel. If this is 
> correct, then the preferred way would be to specify these values in client 
> platform data and then pass it to the DMAC with slave-config calls? Or 
> have I misunderstood you and this per-client information should be kept in 
> DMAC platform data?
You haven't misunderstood me. dmacs should not know of client data and
should be client agnostic. 

BUT, are these parameters ccr and mid_rid client data, i do not think
so, they seem to be dmac controller parameters which you need to
configure channel or is that not the case. If not why bother passing
them to dmac?

Either way something looks fishy to me.
> 
> I.e., in both cases magic values are provided by platforms, the only 
> difference is - either keep them in DMAC platform data or move them in 
> each individual DMA client platform data.
> 
> Yes, some CHCR fields can be calculated, but location and width of those 
> fields might vary between DMAC versions, so, they will have to be passed 
> with DMAC platform data. But this definitely can be done in the future.


-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 12:01 +0200, Guennadi Liakhovetski wrote:
> > On Mon, 16 Jul 2012, Vinod Koul wrote:
> > 
> > > On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > > > > I want to know what does ccr and mid_rid mean to dmac here?
> > > > 
> > > > CHCR contains a few fields, some enable various interrupt sources, some 
> > > > specify repeat- and renew-modes, others yet specify transfer size, source 
> > > > and destination address-modes (incrementing, constant, decrementing), 
> > > > others yet select a DMA client category (slave / memcpy / ...), and a 
> > > > transfer flag. Some of these fields could be calculated, others are 
> > > > pre-defined for various slaves, the exact layout of those fields can also 
> > > > vary between SoCs.
> > > I do not understand how clients would provide these values. 
> > > For pre-defined values, they should be dmac property why should client
> > > like spi or mmc have clue about it?
> > > 
> > > For others like you mentioned, i guess they could be easily calculated,
> > > right?
> > > 
> > > > MID_RID is actually a slave-selector, it contains a magic value, that 
> > > > cannot be calculated. 
> > > and again, how does client know this?
> > 
> > I might be misunderstanding you, but from earlier discussions I got an 
> > impression, that the DMAC should know nothing about clients, i.e., should 
> > receive no client-specific information from its platform data. Instead 
> > clients should provide it when configuring the channel. If this is 
> > correct, then the preferred way would be to specify these values in client 
> > platform data and then pass it to the DMAC with slave-config calls? Or 
> > have I misunderstood you and this per-client information should be kept in 
> > DMAC platform data?
> You haven't misunderstood me. dmacs should not know of client data and
> should be client agnostic. 
> 
> BUT, are these parameters ccr and mid_rid client data, i do not think
> so, they seem to be dmac controller parameters which you need to
> configure channel or is that not the case. If not why bother passing
> them to dmac?

Yes, that's right - these values have to be written to DMAC channel 
configuration registers, so, we do not have to change anything, those 
values can remain DMAC parameters and be passed to it directly from 
platform data.

> Either way something looks fishy to me.

You can always tell me what you don't like about the driver, but I don't 
see why this specific patch should cause any problem - it only changes the 
type of the slave-id variable from unsigned to signed to be able to pass 
negative error values in it too.

> > I.e., in both cases magic values are provided by platforms, the only 
> > difference is - either keep them in DMAC platform data or move them in 
> > each individual DMA client platform data.
> > 
> > Yes, some CHCR fields can be calculated, but location and width of those 
> > fields might vary between DMAC versions, so, they will have to be passed 
> > with DMAC platform data. But this definitely can be done in the future.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 12:01 +0200, Guennadi Liakhovetski wrote:
> > On Mon, 16 Jul 2012, Vinod Koul wrote:
> > 
> > > On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > > > > I want to know what does ccr and mid_rid mean to dmac here?
> > > > 
> > > > CHCR contains a few fields, some enable various interrupt sources, some 
> > > > specify repeat- and renew-modes, others yet specify transfer size, source 
> > > > and destination address-modes (incrementing, constant, decrementing), 
> > > > others yet select a DMA client category (slave / memcpy / ...), and a 
> > > > transfer flag. Some of these fields could be calculated, others are 
> > > > pre-defined for various slaves, the exact layout of those fields can also 
> > > > vary between SoCs.
> > > I do not understand how clients would provide these values. 
> > > For pre-defined values, they should be dmac property why should client
> > > like spi or mmc have clue about it?
> > > 
> > > For others like you mentioned, i guess they could be easily calculated,
> > > right?
> > > 
> > > > MID_RID is actually a slave-selector, it contains a magic value, that 
> > > > cannot be calculated. 
> > > and again, how does client know this?
> > 
> > I might be misunderstanding you, but from earlier discussions I got an 
> > impression, that the DMAC should know nothing about clients, i.e., should 
> > receive no client-specific information from its platform data. Instead 
> > clients should provide it when configuring the channel. If this is 
> > correct, then the preferred way would be to specify these values in client 
> > platform data and then pass it to the DMAC with slave-config calls? Or 
> > have I misunderstood you and this per-client information should be kept in 
> > DMAC platform data?
> You haven't misunderstood me. dmacs should not know of client data and
> should be client agnostic. 
> 
> BUT, are these parameters ccr and mid_rid client data, i do not think
> so, they seem to be dmac controller parameters which you need to
> configure channel or is that not the case. If not why bother passing
> them to dmac?

Yes, that's right - these values have to be written to DMAC channel 
configuration registers, so, we do not have to change anything, those 
values can remain DMAC parameters and be passed to it directly from 
platform data.

> Either way something looks fishy to me.

You can always tell me what you don't like about the driver, but I don't 
see why this specific patch should cause any problem - it only changes the 
type of the slave-id variable from unsigned to signed to be able to pass 
negative error values in it too.

> > I.e., in both cases magic values are provided by platforms, the only 
> > difference is - either keep them in DMAC platform data or move them in 
> > each individual DMA client platform data.
> > 
> > Yes, some CHCR fields can be calculated, but location and width of those 
> > fields might vary between DMAC versions, so, they will have to be passed 
> > with DMAC platform data. But this definitely can be done in the future.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 12:55 +0200, Guennadi Liakhovetski wrote:
> On Mon, 16 Jul 2012, Vinod Koul wrote:
> 
> > On Mon, 2012-07-16 at 12:01 +0200, Guennadi Liakhovetski wrote:
> > > On Mon, 16 Jul 2012, Vinod Koul wrote:
> > > 
> > > > On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > > > > > I want to know what does ccr and mid_rid mean to dmac here?
> > > > > 
> > > > > CHCR contains a few fields, some enable various interrupt sources, some 
> > > > > specify repeat- and renew-modes, others yet specify transfer size, source 
> > > > > and destination address-modes (incrementing, constant, decrementing), 
> > > > > others yet select a DMA client category (slave / memcpy / ...), and a 
> > > > > transfer flag. Some of these fields could be calculated, others are 
> > > > > pre-defined for various slaves, the exact layout of those fields can also 
> > > > > vary between SoCs.
> > > > I do not understand how clients would provide these values. 
> > > > For pre-defined values, they should be dmac property why should client
> > > > like spi or mmc have clue about it?
> > > > 
> > > > For others like you mentioned, i guess they could be easily calculated,
> > > > right?
> > > > 
> > > > > MID_RID is actually a slave-selector, it contains a magic value, that 
> > > > > cannot be calculated. 
> > > > and again, how does client know this?
> > > 
> > > I might be misunderstanding you, but from earlier discussions I got an 
> > > impression, that the DMAC should know nothing about clients, i.e., should 
> > > receive no client-specific information from its platform data. Instead 
> > > clients should provide it when configuring the channel. If this is 
> > > correct, then the preferred way would be to specify these values in client 
> > > platform data and then pass it to the DMAC with slave-config calls? Or 
> > > have I misunderstood you and this per-client information should be kept in 
> > > DMAC platform data?
> > You haven't misunderstood me. dmacs should not know of client data and
> > should be client agnostic. 
> > 
> > BUT, are these parameters ccr and mid_rid client data, i do not think
> > so, they seem to be dmac controller parameters which you need to
> > configure channel or is that not the case. If not why bother passing
> > them to dmac?
> 
> Yes, that's right - these values have to be written to DMAC channel 
> configuration registers, so, we do not have to change anything, those 
> values can remain DMAC parameters and be passed to it directly from 
> platform data.
Can you get that in future fixes.
> 
> > Either way something looks fishy to me.
> 
> You can always tell me what you don't like about the driver, but I don't 
> see why this specific patch should cause any problem - it only changes the 
> type of the slave-id variable from unsigned to signed to be able to pass 
> negative error values in it too.
This question was not specific to this patchset

Btw I am quite happy with this patchset. Good direction for this and
thanks for taking it up.


-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 12:55 +0200, Guennadi Liakhovetski wrote:
> On Mon, 16 Jul 2012, Vinod Koul wrote:
> 
> > On Mon, 2012-07-16 at 12:01 +0200, Guennadi Liakhovetski wrote:
> > > On Mon, 16 Jul 2012, Vinod Koul wrote:
> > > 
> > > > On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > > > > > I want to know what does ccr and mid_rid mean to dmac here?
> > > > > 
> > > > > CHCR contains a few fields, some enable various interrupt sources, some 
> > > > > specify repeat- and renew-modes, others yet specify transfer size, source 
> > > > > and destination address-modes (incrementing, constant, decrementing), 
> > > > > others yet select a DMA client category (slave / memcpy / ...), and a 
> > > > > transfer flag. Some of these fields could be calculated, others are 
> > > > > pre-defined for various slaves, the exact layout of those fields can also 
> > > > > vary between SoCs.
> > > > I do not understand how clients would provide these values. 
> > > > For pre-defined values, they should be dmac property why should client
> > > > like spi or mmc have clue about it?
> > > > 
> > > > For others like you mentioned, i guess they could be easily calculated,
> > > > right?
> > > > 
> > > > > MID_RID is actually a slave-selector, it contains a magic value, that 
> > > > > cannot be calculated. 
> > > > and again, how does client know this?
> > > 
> > > I might be misunderstanding you, but from earlier discussions I got an 
> > > impression, that the DMAC should know nothing about clients, i.e., should 
> > > receive no client-specific information from its platform data. Instead 
> > > clients should provide it when configuring the channel. If this is 
> > > correct, then the preferred way would be to specify these values in client 
> > > platform data and then pass it to the DMAC with slave-config calls? Or 
> > > have I misunderstood you and this per-client information should be kept in 
> > > DMAC platform data?
> > You haven't misunderstood me. dmacs should not know of client data and
> > should be client agnostic. 
> > 
> > BUT, are these parameters ccr and mid_rid client data, i do not think
> > so, they seem to be dmac controller parameters which you need to
> > configure channel or is that not the case. If not why bother passing
> > them to dmac?
> 
> Yes, that's right - these values have to be written to DMAC channel 
> configuration registers, so, we do not have to change anything, those 
> values can remain DMAC parameters and be passed to it directly from 
> platform data.
Can you get that in future fixes.
> 
> > Either way something looks fishy to me.
> 
> You can always tell me what you don't like about the driver, but I don't 
> see why this specific patch should cause any problem - it only changes the 
> type of the slave-id variable from unsigned to signed to be able to pass 
> negative error values in it too.
This question was not specific to this patchset

Btw I am quite happy with this patchset. Good direction for this and
thanks for taking it up.


-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 12:55 +0200, Guennadi Liakhovetski wrote:
> > On Mon, 16 Jul 2012, Vinod Koul wrote:
> > 
> > > On Mon, 2012-07-16 at 12:01 +0200, Guennadi Liakhovetski wrote:
> > > > On Mon, 16 Jul 2012, Vinod Koul wrote:
> > > > 
> > > > > On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > > > > > > I want to know what does ccr and mid_rid mean to dmac here?
> > > > > > 
> > > > > > CHCR contains a few fields, some enable various interrupt sources, some 
> > > > > > specify repeat- and renew-modes, others yet specify transfer size, source 
> > > > > > and destination address-modes (incrementing, constant, decrementing), 
> > > > > > others yet select a DMA client category (slave / memcpy / ...), and a 
> > > > > > transfer flag. Some of these fields could be calculated, others are 
> > > > > > pre-defined for various slaves, the exact layout of those fields can also 
> > > > > > vary between SoCs.
> > > > > I do not understand how clients would provide these values. 
> > > > > For pre-defined values, they should be dmac property why should client
> > > > > like spi or mmc have clue about it?
> > > > > 
> > > > > For others like you mentioned, i guess they could be easily calculated,
> > > > > right?
> > > > > 
> > > > > > MID_RID is actually a slave-selector, it contains a magic value, that 
> > > > > > cannot be calculated. 
> > > > > and again, how does client know this?
> > > > 
> > > > I might be misunderstanding you, but from earlier discussions I got an 
> > > > impression, that the DMAC should know nothing about clients, i.e., should 
> > > > receive no client-specific information from its platform data. Instead 
> > > > clients should provide it when configuring the channel. If this is 
> > > > correct, then the preferred way would be to specify these values in client 
> > > > platform data and then pass it to the DMAC with slave-config calls? Or 
> > > > have I misunderstood you and this per-client information should be kept in 
> > > > DMAC platform data?
> > > You haven't misunderstood me. dmacs should not know of client data and
> > > should be client agnostic. 
> > > 
> > > BUT, are these parameters ccr and mid_rid client data, i do not think
> > > so, they seem to be dmac controller parameters which you need to
> > > configure channel or is that not the case. If not why bother passing
> > > them to dmac?
> > 
> > Yes, that's right - these values have to be written to DMAC channel 
> > configuration registers, so, we do not have to change anything, those 
> > values can remain DMAC parameters and be passed to it directly from 
> > platform data.
> Can you get that in future fixes.

Sorry, what exactly would you like to have fixed here? Above I just 
described how the driver already functions, what changes do you see 
necessary?

> > > Either way something looks fishy to me.
> > 
> > You can always tell me what you don't like about the driver, but I don't 
> > see why this specific patch should cause any problem - it only changes the 
> > type of the slave-id variable from unsigned to signed to be able to pass 
> > negative error values in it too.
> This question was not specific to this patchset
> 
> Btw I am quite happy with this patchset. Good direction for this and
> thanks for taking it up.

Thanks! That's very good to know!

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 12:55 +0200, Guennadi Liakhovetski wrote:
> > On Mon, 16 Jul 2012, Vinod Koul wrote:
> > 
> > > On Mon, 2012-07-16 at 12:01 +0200, Guennadi Liakhovetski wrote:
> > > > On Mon, 16 Jul 2012, Vinod Koul wrote:
> > > > 
> > > > > On Mon, 2012-07-16 at 10:47 +0200, Guennadi Liakhovetski wrote:
> > > > > > > I want to know what does ccr and mid_rid mean to dmac here?
> > > > > > 
> > > > > > CHCR contains a few fields, some enable various interrupt sources, some 
> > > > > > specify repeat- and renew-modes, others yet specify transfer size, source 
> > > > > > and destination address-modes (incrementing, constant, decrementing), 
> > > > > > others yet select a DMA client category (slave / memcpy / ...), and a 
> > > > > > transfer flag. Some of these fields could be calculated, others are 
> > > > > > pre-defined for various slaves, the exact layout of those fields can also 
> > > > > > vary between SoCs.
> > > > > I do not understand how clients would provide these values. 
> > > > > For pre-defined values, they should be dmac property why should client
> > > > > like spi or mmc have clue about it?
> > > > > 
> > > > > For others like you mentioned, i guess they could be easily calculated,
> > > > > right?
> > > > > 
> > > > > > MID_RID is actually a slave-selector, it contains a magic value, that 
> > > > > > cannot be calculated. 
> > > > > and again, how does client know this?
> > > > 
> > > > I might be misunderstanding you, but from earlier discussions I got an 
> > > > impression, that the DMAC should know nothing about clients, i.e., should 
> > > > receive no client-specific information from its platform data. Instead 
> > > > clients should provide it when configuring the channel. If this is 
> > > > correct, then the preferred way would be to specify these values in client 
> > > > platform data and then pass it to the DMAC with slave-config calls? Or 
> > > > have I misunderstood you and this per-client information should be kept in 
> > > > DMAC platform data?
> > > You haven't misunderstood me. dmacs should not know of client data and
> > > should be client agnostic. 
> > > 
> > > BUT, are these parameters ccr and mid_rid client data, i do not think
> > > so, they seem to be dmac controller parameters which you need to
> > > configure channel or is that not the case. If not why bother passing
> > > them to dmac?
> > 
> > Yes, that's right - these values have to be written to DMAC channel 
> > configuration registers, so, we do not have to change anything, those 
> > values can remain DMAC parameters and be passed to it directly from 
> > platform data.
> Can you get that in future fixes.

Sorry, what exactly would you like to have fixed here? Above I just 
described how the driver already functions, what changes do you see 
necessary?

> > > Either way something looks fishy to me.
> > 
> > You can always tell me what you don't like about the driver, but I don't 
> > see why this specific patch should cause any problem - it only changes the 
> > type of the slave-id variable from unsigned to signed to be able to pass 
> > negative error values in it too.
> This question was not specific to this patchset
> 
> Btw I am quite happy with this patchset. Good direction for this and
> thanks for taking it up.

Thanks! That's very good to know!

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 14:47 +0200, Guennadi Liakhovetski wrote:
> > > Yes, that's right - these values have to be written to DMAC channel 
> > > configuration registers, so, we do not have to change anything, those 
> > > values can remain DMAC parameters and be passed to it directly from 
> > > platform data.
> > Can you get that in future fixes.
> 
> Sorry, what exactly would you like to have fixed here? Above I just 
> described how the driver already functions, what changes do you see 
> necessary? 
Why should client pass these two values. So the parameters which can be
calculated should be, and rest should dmacs platform data and not
clients.
And after the removal of the slave and adddr fields, you find that you
no longer need your specific slave structure and that can be elimnated
completely.

-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Vinod Koul]

On Mon, 2012-07-16 at 14:47 +0200, Guennadi Liakhovetski wrote:
> > > Yes, that's right - these values have to be written to DMAC channel 
> > > configuration registers, so, we do not have to change anything, those 
> > > values can remain DMAC parameters and be passed to it directly from 
> > > platform data.
> > Can you get that in future fixes.
> 
> Sorry, what exactly would you like to have fixed here? Above I just 
> described how the driver already functions, what changes do you see 
> necessary? 
Why should client pass these two values. So the parameters which can be
calculated should be, and rest should dmacs platform data and not
clients.
And after the removal of the slave and adddr fields, you find that you
no longer need your specific slave structure and that can be elimnated
completely.

-- 
~Vinod

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

Hi Vinod

On Wed, 18 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 14:47 +0200, Guennadi Liakhovetski wrote:
> > > > Yes, that's right - these values have to be written to DMAC channel 
> > > > configuration registers, so, we do not have to change anything, those 
> > > > values can remain DMAC parameters and be passed to it directly from 
> > > > platform data.
> > > Can you get that in future fixes.
> > 
> > Sorry, what exactly would you like to have fixed here? Above I just 
> > described how the driver already functions, what changes do you see 
> > necessary? 
> Why should client pass these two values. So the parameters which can be
> calculated should be, and rest should dmacs platform data and not
> clients.

Hm, let me try again:

> > > > those
> > > > values can remain DMAC parameters and be passed to it directly from
> > > > platform data.

i.e., from DMAC's platform data, they are _not_ passed from clients. Am I 
still missing something?

> And after the removal of the slave and adddr fields, you find that you
> no longer need your specific slave structure and that can be elimnated
> completely.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility

[Guennadi Liakhovetski]

Hi Vinod

On Wed, 18 Jul 2012, Vinod Koul wrote:

> On Mon, 2012-07-16 at 14:47 +0200, Guennadi Liakhovetski wrote:
> > > > Yes, that's right - these values have to be written to DMAC channel 
> > > > configuration registers, so, we do not have to change anything, those 
> > > > values can remain DMAC parameters and be passed to it directly from 
> > > > platform data.
> > > Can you get that in future fixes.
> > 
> > Sorry, what exactly would you like to have fixed here? Above I just 
> > described how the driver already functions, what changes do you see 
> > necessary? 
> Why should client pass these two values. So the parameters which can be
> calculated should be, and rest should dmacs platform data and not
> clients.

Hm, let me try again:

> > > > those
> > > > values can remain DMAC parameters and be passed to it directly from
> > > > platform data.

i.e., from DMAC's platform data, they are _not_ passed from clients. Am I 
still missing something?

> And after the removal of the slave and adddr fields, you find that you
> no longer need your specific slave structure and that can be elimnated
> completely.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private

[Guennadi Liakhovetski]

This patch extends the sh dmaengine driver to support the preferred channel
selection and configuration method, instead of using the "private" field
from struct dma_chan. We add a standard filter function to be used by
slave drivers instead of implementing their own ones, and add support for
the DMA_SLAVE_CONFIG control operation, which must accompany the new
channel selection method. We still support the legacy .private channel
allocation method to cater for a smooth driver migration.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
 drivers/dma/sh/shdma-base.c |  114 +++++++++++++++++++++++++++++++++---------
 drivers/dma/sh/shdma.c      |    5 +-
 include/linux/sh_dma.h      |    2 +
 include/linux/shdma-base.h  |    2 +-
 4 files changed, 95 insertions(+), 28 deletions(-)

diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
index 73db282..0c34c73 100644
--- a/drivers/dma/sh/shdma-base.c
+++ b/drivers/dma/sh/shdma-base.c
@@ -171,6 +171,65 @@ static struct shdma_desc *shdma_get_desc(struct shdma_chan *schan)
 	return NULL;
 }
 
+static int shdma_setup_slave(struct shdma_chan *schan, int slave_id)
+{
+	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
+	const struct shdma_ops *ops = sdev->ops;
+	int ret;
+
+	if (slave_id < 0 || slave_id >= slave_num)
+		return -EINVAL;
+
+	if (test_and_set_bit(slave_id, shdma_slave_used))
+		return -EBUSY;
+
+	ret = ops->set_slave(schan, slave_id, false);
+	if (ret < 0) {
+		clear_bit(slave_id, shdma_slave_used);
+		return ret;
+	}
+
+	schan->slave_id = slave_id;
+
+	return 0;
+}
+
+/*
+ * This is the standard shdma filter function to be used as a replacement to the
+ * "old" method, using the .private pointer. If for some reason you allocate a
+ * channel without slave data, use something like ERR_PTR(-EINVAL) as a filter
+ * parameter. If this filter is used, the slave driver, after calling
+ * dma_request_channel(), will also have to call dmaengine_slave_config() with
+ * .slave_id, .direction, and either .src_addr or .dst_addr set.
+ * NOTE: this filter doesn't support multiple DMAC drivers with the DMA_SLAVE
+ * capability! If this becomes a requirement, hardware glue drivers, using this
+ * services would have to provide their own filters, which first would check
+ * the device driver, similar to how other DMAC drivers, e.g., sa11x0-dma.c, do
+ * this, and only then, in case of a match, call this common filter.
+ */
+bool shdma_chan_filter(struct dma_chan *chan, void *arg)
+{
+	struct shdma_chan *schan = to_shdma_chan(chan);
+	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
+	const struct shdma_ops *ops = sdev->ops;
+	int slave_id = (int)arg;
+	int ret;
+
+	if (slave_id < 0)
+		/* No slave requested - arbitrary channel */
+		return true;
+
+	if (slave_id >= slave_num)
+		return false;
+
+	ret = ops->set_slave(schan, slave_id, true);
+	if (ret < 0)
+		return false;
+
+	return true;
+}
+EXPORT_SYMBOL(shdma_chan_filter);
+
 static int shdma_alloc_chan_resources(struct dma_chan *chan)
 {
 	struct shdma_chan *schan = to_shdma_chan(chan);
@@ -185,21 +244,10 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
 	 * never runs concurrently with itself or free_chan_resources.
 	 */
 	if (slave) {
-		if (slave->slave_id < 0 || slave->slave_id >= slave_num) {
-			ret = -EINVAL;
-			goto evalid;
-		}
-
-		if (test_and_set_bit(slave->slave_id, shdma_slave_used)) {
-			ret = -EBUSY;
-			goto etestused;
-		}
-
-		ret = ops->set_slave(schan, slave->slave_id);
+		/* Legacy mode: .private is set in filter */
+		ret = shdma_setup_slave(schan, slave->slave_id);
 		if (ret < 0)
 			goto esetslave;
-
-		schan->slave_id = slave->slave_id;
 	} else {
 		schan->slave_id = -EINVAL;
 	}
@@ -228,8 +276,6 @@ edescalloc:
 	if (slave)
 esetslave:
 		clear_bit(slave->slave_id, shdma_slave_used);
-etestused:
-evalid:
 	chan->private = NULL;
 	return ret;
 }
@@ -587,22 +633,40 @@ static int shdma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
 	struct shdma_chan *schan = to_shdma_chan(chan);
 	struct shdma_dev *sdev = to_shdma_dev(chan->device);
 	const struct shdma_ops *ops = sdev->ops;
+	struct dma_slave_config *config;
 	unsigned long flags;
-
-	/* Only supports DMA_TERMINATE_ALL */
-	if (cmd != DMA_TERMINATE_ALL)
-		return -ENXIO;
+	int ret;
 
 	if (!chan)
 		return -EINVAL;
 
-	spin_lock_irqsave(&schan->chan_lock, flags);
-
-	ops->halt_channel(schan);
-
-	spin_unlock_irqrestore(&schan->chan_lock, flags);
+	switch (cmd) {
+	case DMA_TERMINATE_ALL:
+		spin_lock_irqsave(&schan->chan_lock, flags);
+		ops->halt_channel(schan);
+		spin_unlock_irqrestore(&schan->chan_lock, flags);
 
-	shdma_chan_ld_cleanup(schan, true);
+		shdma_chan_ld_cleanup(schan, true);
+		break;
+	case DMA_SLAVE_CONFIG:
+		/*
+		 * So far only .slave_id is used, but the slave drivers are
+		 * encouraged to also set a transfer direction and an address.
+		 */
+		if (!arg)
+			return -EINVAL;
+		/*
+		 * We could lock this, but you shouldn't be configuring the
+		 * channel, while using it...
+		 */
+		config = (struct dma_slave_config*)arg;
+		ret = shdma_setup_slave(schan, config->slave_id);
+		if (ret < 0)
+			return ret;
+		break;
+	default:
+		return -ENXIO;
+	}
 
 	return 0;
 }
diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
index 9a10d8b..027c9be 100644
--- a/drivers/dma/sh/shdma.c
+++ b/drivers/dma/sh/shdma.c
@@ -320,7 +320,7 @@ static const struct sh_dmae_slave_config *dmae_find_slave(
 }
 
 static int sh_dmae_set_slave(struct shdma_chan *schan,
-			     int slave_id)
+			     int slave_id, bool try)
 {
 	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
 						    shdma_chan);
@@ -328,7 +328,8 @@ static int sh_dmae_set_slave(struct shdma_chan *schan,
 	if (!cfg)
 		return -ENODEV;
 
-	sh_chan->config = cfg;
+	if (!try)
+		sh_chan->config = cfg;
 
 	return 0;
 }
diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
index 4e83f3e..b64d6be 100644
--- a/include/linux/sh_dma.h
+++ b/include/linux/sh_dma.h
@@ -99,4 +99,6 @@ struct sh_dmae_pdata {
 #define CHCR_TE	0x00000002
 #define CHCR_IE	0x00000004
 
+bool shdma_chan_filter(struct dma_chan *chan, void *arg);
+
 #endif
diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
index 6263ad2..93f9821 100644
--- a/include/linux/shdma-base.h
+++ b/include/linux/shdma-base.h
@@ -93,7 +93,7 @@ struct shdma_ops {
 	dma_addr_t (*slave_addr)(struct shdma_chan *);
 	int (*desc_setup)(struct shdma_chan *, struct shdma_desc *,
 			  dma_addr_t, dma_addr_t, size_t *);
-	int (*set_slave)(struct shdma_chan *, int);
+	int (*set_slave)(struct shdma_chan *, int, bool);
 	void (*setup_xfer)(struct shdma_chan *, int);
 	void (*start_xfer)(struct shdma_chan *, struct shdma_desc *);
 	struct shdma_desc *(*embedded_desc)(void *, int);
-- 
1.7.2.5

[PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private

[Guennadi Liakhovetski]

This patch extends the sh dmaengine driver to support the preferred channel
selection and configuration method, instead of using the "private" field
from struct dma_chan. We add a standard filter function to be used by
slave drivers instead of implementing their own ones, and add support for
the DMA_SLAVE_CONFIG control operation, which must accompany the new
channel selection method. We still support the legacy .private channel
allocation method to cater for a smooth driver migration.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
 drivers/dma/sh/shdma-base.c |  114 +++++++++++++++++++++++++++++++++---------
 drivers/dma/sh/shdma.c      |    5 +-
 include/linux/sh_dma.h      |    2 +
 include/linux/shdma-base.h  |    2 +-
 4 files changed, 95 insertions(+), 28 deletions(-)

diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
index 73db282..0c34c73 100644
--- a/drivers/dma/sh/shdma-base.c
+++ b/drivers/dma/sh/shdma-base.c
@@ -171,6 +171,65 @@ static struct shdma_desc *shdma_get_desc(struct shdma_chan *schan)
 	return NULL;
 }
 
+static int shdma_setup_slave(struct shdma_chan *schan, int slave_id)
+{
+	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
+	const struct shdma_ops *ops = sdev->ops;
+	int ret;
+
+	if (slave_id < 0 || slave_id >= slave_num)
+		return -EINVAL;
+
+	if (test_and_set_bit(slave_id, shdma_slave_used))
+		return -EBUSY;
+
+	ret = ops->set_slave(schan, slave_id, false);
+	if (ret < 0) {
+		clear_bit(slave_id, shdma_slave_used);
+		return ret;
+	}
+
+	schan->slave_id = slave_id;
+
+	return 0;
+}
+
+/*
+ * This is the standard shdma filter function to be used as a replacement to the
+ * "old" method, using the .private pointer. If for some reason you allocate a
+ * channel without slave data, use something like ERR_PTR(-EINVAL) as a filter
+ * parameter. If this filter is used, the slave driver, after calling
+ * dma_request_channel(), will also have to call dmaengine_slave_config() with
+ * .slave_id, .direction, and either .src_addr or .dst_addr set.
+ * NOTE: this filter doesn't support multiple DMAC drivers with the DMA_SLAVE
+ * capability! If this becomes a requirement, hardware glue drivers, using this
+ * services would have to provide their own filters, which first would check
+ * the device driver, similar to how other DMAC drivers, e.g., sa11x0-dma.c, do
+ * this, and only then, in case of a match, call this common filter.
+ */
+bool shdma_chan_filter(struct dma_chan *chan, void *arg)
+{
+	struct shdma_chan *schan = to_shdma_chan(chan);
+	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
+	const struct shdma_ops *ops = sdev->ops;
+	int slave_id = (int)arg;
+	int ret;
+
+	if (slave_id < 0)
+		/* No slave requested - arbitrary channel */
+		return true;
+
+	if (slave_id >= slave_num)
+		return false;
+
+	ret = ops->set_slave(schan, slave_id, true);
+	if (ret < 0)
+		return false;
+
+	return true;
+}
+EXPORT_SYMBOL(shdma_chan_filter);
+
 static int shdma_alloc_chan_resources(struct dma_chan *chan)
 {
 	struct shdma_chan *schan = to_shdma_chan(chan);
@@ -185,21 +244,10 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
 	 * never runs concurrently with itself or free_chan_resources.
 	 */
 	if (slave) {
-		if (slave->slave_id < 0 || slave->slave_id >= slave_num) {
-			ret = -EINVAL;
-			goto evalid;
-		}
-
-		if (test_and_set_bit(slave->slave_id, shdma_slave_used)) {
-			ret = -EBUSY;
-			goto etestused;
-		}
-
-		ret = ops->set_slave(schan, slave->slave_id);
+		/* Legacy mode: .private is set in filter */
+		ret = shdma_setup_slave(schan, slave->slave_id);
 		if (ret < 0)
 			goto esetslave;
-
-		schan->slave_id = slave->slave_id;
 	} else {
 		schan->slave_id = -EINVAL;
 	}
@@ -228,8 +276,6 @@ edescalloc:
 	if (slave)
 esetslave:
 		clear_bit(slave->slave_id, shdma_slave_used);
-etestused:
-evalid:
 	chan->private = NULL;
 	return ret;
 }
@@ -587,22 +633,40 @@ static int shdma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
 	struct shdma_chan *schan = to_shdma_chan(chan);
 	struct shdma_dev *sdev = to_shdma_dev(chan->device);
 	const struct shdma_ops *ops = sdev->ops;
+	struct dma_slave_config *config;
 	unsigned long flags;
-
-	/* Only supports DMA_TERMINATE_ALL */
-	if (cmd != DMA_TERMINATE_ALL)
-		return -ENXIO;
+	int ret;
 
 	if (!chan)
 		return -EINVAL;
 
-	spin_lock_irqsave(&schan->chan_lock, flags);
-
-	ops->halt_channel(schan);
-
-	spin_unlock_irqrestore(&schan->chan_lock, flags);
+	switch (cmd) {
+	case DMA_TERMINATE_ALL:
+		spin_lock_irqsave(&schan->chan_lock, flags);
+		ops->halt_channel(schan);
+		spin_unlock_irqrestore(&schan->chan_lock, flags);
 
-	shdma_chan_ld_cleanup(schan, true);
+		shdma_chan_ld_cleanup(schan, true);
+		break;
+	case DMA_SLAVE_CONFIG:
+		/*
+		 * So far only .slave_id is used, but the slave drivers are
+		 * encouraged to also set a transfer direction and an address.
+		 */
+		if (!arg)
+			return -EINVAL;
+		/*
+		 * We could lock this, but you shouldn't be configuring the
+		 * channel, while using it...
+		 */
+		config = (struct dma_slave_config*)arg;
+		ret = shdma_setup_slave(schan, config->slave_id);
+		if (ret < 0)
+			return ret;
+		break;
+	default:
+		return -ENXIO;
+	}
 
 	return 0;
 }
diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
index 9a10d8b..027c9be 100644
--- a/drivers/dma/sh/shdma.c
+++ b/drivers/dma/sh/shdma.c
@@ -320,7 +320,7 @@ static const struct sh_dmae_slave_config *dmae_find_slave(
 }
 
 static int sh_dmae_set_slave(struct shdma_chan *schan,
-			     int slave_id)
+			     int slave_id, bool try)
 {
 	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
 						    shdma_chan);
@@ -328,7 +328,8 @@ static int sh_dmae_set_slave(struct shdma_chan *schan,
 	if (!cfg)
 		return -ENODEV;
 
-	sh_chan->config = cfg;
+	if (!try)
+		sh_chan->config = cfg;
 
 	return 0;
 }
diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
index 4e83f3e..b64d6be 100644
--- a/include/linux/sh_dma.h
+++ b/include/linux/sh_dma.h
@@ -99,4 +99,6 @@ struct sh_dmae_pdata {
 #define CHCR_TE	0x00000002
 #define CHCR_IE	0x00000004
 
+bool shdma_chan_filter(struct dma_chan *chan, void *arg);
+
 #endif
diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
index 6263ad2..93f9821 100644
--- a/include/linux/shdma-base.h
+++ b/include/linux/shdma-base.h
@@ -93,7 +93,7 @@ struct shdma_ops {
 	dma_addr_t (*slave_addr)(struct shdma_chan *);
 	int (*desc_setup)(struct shdma_chan *, struct shdma_desc *,
 			  dma_addr_t, dma_addr_t, size_t *);
-	int (*set_slave)(struct shdma_chan *, int);
+	int (*set_slave)(struct shdma_chan *, int, bool);
 	void (*setup_xfer)(struct shdma_chan *, int);
 	void (*start_xfer)(struct shdma_chan *, struct shdma_desc *);
 	struct shdma_desc *(*embedded_desc)(void *, int);
-- 
1.7.2.5

Re: [PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private

[Vinod Koul]

On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> This patch extends the sh dmaengine driver to support the preferred channel
> selection and configuration method, instead of using the "private" field
> from struct dma_chan. We add a standard filter function to be used by
> slave drivers instead of implementing their own ones, and add support for
> the DMA_SLAVE_CONFIG control operation, which must accompany the new
> channel selection method. We still support the legacy .private channel
> allocation method to cater for a smooth driver migration.
There seem to be two things done in this patch, one is to provide a
filter function for people to use for channel filtering, and second the
removal of .private. It would be good to split these two.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>  drivers/dma/sh/shdma-base.c |  114 +++++++++++++++++++++++++++++++++---------
>  drivers/dma/sh/shdma.c      |    5 +-
>  include/linux/sh_dma.h      |    2 +
>  include/linux/shdma-base.h  |    2 +-
>  4 files changed, 95 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
> index 73db282..0c34c73 100644
> --- a/drivers/dma/sh/shdma-base.c
> +++ b/drivers/dma/sh/shdma-base.c
> @@ -171,6 +171,65 @@ static struct shdma_desc *shdma_get_desc(struct shdma_chan *schan)
>  	return NULL;
>  }
>  
> +static int shdma_setup_slave(struct shdma_chan *schan, int slave_id)
> +{
> +	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
> +	const struct shdma_ops *ops = sdev->ops;
> +	int ret;
> +
> +	if (slave_id < 0 || slave_id >= slave_num)
> +		return -EINVAL;
> +
> +	if (test_and_set_bit(slave_id, shdma_slave_used))
> +		return -EBUSY;
> +
> +	ret = ops->set_slave(schan, slave_id, false);
> +	if (ret < 0) {
> +		clear_bit(slave_id, shdma_slave_used);
> +		return ret;
> +	}
> +
> +	schan->slave_id = slave_id;
> +
> +	return 0;
> +}
> +
> +/*
> + * This is the standard shdma filter function to be used as a replacement to the
> + * "old" method, using the .private pointer. If for some reason you allocate a
> + * channel without slave data, use something like ERR_PTR(-EINVAL) as a filter
> + * parameter. If this filter is used, the slave driver, after calling
> + * dma_request_channel(), will also have to call dmaengine_slave_config() with
> + * .slave_id, .direction, and either .src_addr or .dst_addr set.
> + * NOTE: this filter doesn't support multiple DMAC drivers with the DMA_SLAVE
> + * capability! If this becomes a requirement, hardware glue drivers, using this
> + * services would have to provide their own filters, which first would check
> + * the device driver, similar to how other DMAC drivers, e.g., sa11x0-dma.c, do
> + * this, and only then, in case of a match, call this common filter.
> + */
> +bool shdma_chan_filter(struct dma_chan *chan, void *arg)
> +{
> +	struct shdma_chan *schan = to_shdma_chan(chan);
> +	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
> +	const struct shdma_ops *ops = sdev->ops;
> +	int slave_id = (int)arg;
> +	int ret;
> +
> +	if (slave_id < 0)
> +		/* No slave requested - arbitrary channel */
> +		return true;
> +
> +	if (slave_id >= slave_num)
> +		return false;
> +
> +	ret = ops->set_slave(schan, slave_id, true);
> +	if (ret < 0)
> +		return false;
> +
> +	return true;
> +}
> +EXPORT_SYMBOL(shdma_chan_filter);
> +
>  static int shdma_alloc_chan_resources(struct dma_chan *chan)
>  {
>  	struct shdma_chan *schan = to_shdma_chan(chan);
> @@ -185,21 +244,10 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
>  	 * never runs concurrently with itself or free_chan_resources.
>  	 */
>  	if (slave) {
> -		if (slave->slave_id < 0 || slave->slave_id >= slave_num) {
> -			ret = -EINVAL;
> -			goto evalid;
> -		}
> -
> -		if (test_and_set_bit(slave->slave_id, shdma_slave_used)) {
> -			ret = -EBUSY;
> -			goto etestused;
> -		}
> -
> -		ret = ops->set_slave(schan, slave->slave_id);
> +		/* Legacy mode: .private is set in filter */
> +		ret = shdma_setup_slave(schan, slave->slave_id);
>  		if (ret < 0)
>  			goto esetslave;
> -
> -		schan->slave_id = slave->slave_id;
>  	} else {
>  		schan->slave_id = -EINVAL;
>  	}
> @@ -228,8 +276,6 @@ edescalloc:
>  	if (slave)
>  esetslave:
>  		clear_bit(slave->slave_id, shdma_slave_used);
> -etestused:
> -evalid:
>  	chan->private = NULL;
you missed this one
>  	return ret;
>  }
> @@ -587,22 +633,40 @@ static int shdma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
>  	struct shdma_chan *schan = to_shdma_chan(chan);
>  	struct shdma_dev *sdev = to_shdma_dev(chan->device);
>  	const struct shdma_ops *ops = sdev->ops;
> +	struct dma_slave_config *config;
>  	unsigned long flags;
> -
> -	/* Only supports DMA_TERMINATE_ALL */
> -	if (cmd != DMA_TERMINATE_ALL)
> -		return -ENXIO;
> +	int ret;
>  
>  	if (!chan)
>  		return -EINVAL;
>  
> -	spin_lock_irqsave(&schan->chan_lock, flags);
> -
> -	ops->halt_channel(schan);
> -
> -	spin_unlock_irqrestore(&schan->chan_lock, flags);
> +	switch (cmd) {
> +	case DMA_TERMINATE_ALL:
> +		spin_lock_irqsave(&schan->chan_lock, flags);
> +		ops->halt_channel(schan);
> +		spin_unlock_irqrestore(&schan->chan_lock, flags);
>  
> -	shdma_chan_ld_cleanup(schan, true);
> +		shdma_chan_ld_cleanup(schan, true);
> +		break;
> +	case DMA_SLAVE_CONFIG:
> +		/*
> +		 * So far only .slave_id is used, but the slave drivers are
> +		 * encouraged to also set a transfer direction and an address.
> +		 */
> +		if (!arg)
> +			return -EINVAL;
> +		/*
> +		 * We could lock this, but you shouldn't be configuring the
> +		 * channel, while using it...
> +		 */
> +		config = (struct dma_slave_config*)arg;
> +		ret = shdma_setup_slave(schan, config->slave_id);
> +		if (ret < 0)
> +			return ret;
> +		break;
> +	default:
> +		return -ENXIO;
> +	}
>  
>  	return 0;
>  }
> diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
> index 9a10d8b..027c9be 100644
> --- a/drivers/dma/sh/shdma.c
> +++ b/drivers/dma/sh/shdma.c
> @@ -320,7 +320,7 @@ static const struct sh_dmae_slave_config *dmae_find_slave(
>  }
>  
>  static int sh_dmae_set_slave(struct shdma_chan *schan,
> -			     int slave_id)
> +			     int slave_id, bool try)
>  {
>  	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
>  						    shdma_chan);
> @@ -328,7 +328,8 @@ static int sh_dmae_set_slave(struct shdma_chan *schan,
>  	if (!cfg)
>  		return -ENODEV;
>  
> -	sh_chan->config = cfg;
> +	if (!try)
> +		sh_chan->config = cfg;
>  
>  	return 0;
>  }
> diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> index 4e83f3e..b64d6be 100644
> --- a/include/linux/sh_dma.h
> +++ b/include/linux/sh_dma.h
> @@ -99,4 +99,6 @@ struct sh_dmae_pdata {
>  #define CHCR_TE	0x00000002
>  #define CHCR_IE	0x00000004
>  
> +bool shdma_chan_filter(struct dma_chan *chan, void *arg);
> +
>  #endif
> diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
> index 6263ad2..93f9821 100644
> --- a/include/linux/shdma-base.h
> +++ b/include/linux/shdma-base.h
> @@ -93,7 +93,7 @@ struct shdma_ops {
>  	dma_addr_t (*slave_addr)(struct shdma_chan *);
>  	int (*desc_setup)(struct shdma_chan *, struct shdma_desc *,
>  			  dma_addr_t, dma_addr_t, size_t *);
> -	int (*set_slave)(struct shdma_chan *, int);
> +	int (*set_slave)(struct shdma_chan *, int, bool);
>  	void (*setup_xfer)(struct shdma_chan *, int);
>  	void (*start_xfer)(struct shdma_chan *, struct shdma_desc *);
>  	struct shdma_desc *(*embedded_desc)(void *, int);


-- 
~Vinod

Re: [PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private

[Vinod Koul]

On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> This patch extends the sh dmaengine driver to support the preferred channel
> selection and configuration method, instead of using the "private" field
> from struct dma_chan. We add a standard filter function to be used by
> slave drivers instead of implementing their own ones, and add support for
> the DMA_SLAVE_CONFIG control operation, which must accompany the new
> channel selection method. We still support the legacy .private channel
> allocation method to cater for a smooth driver migration.
There seem to be two things done in this patch, one is to provide a
filter function for people to use for channel filtering, and second the
removal of .private. It would be good to split these two.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>  drivers/dma/sh/shdma-base.c |  114 +++++++++++++++++++++++++++++++++---------
>  drivers/dma/sh/shdma.c      |    5 +-
>  include/linux/sh_dma.h      |    2 +
>  include/linux/shdma-base.h  |    2 +-
>  4 files changed, 95 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
> index 73db282..0c34c73 100644
> --- a/drivers/dma/sh/shdma-base.c
> +++ b/drivers/dma/sh/shdma-base.c
> @@ -171,6 +171,65 @@ static struct shdma_desc *shdma_get_desc(struct shdma_chan *schan)
>  	return NULL;
>  }
>  
> +static int shdma_setup_slave(struct shdma_chan *schan, int slave_id)
> +{
> +	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
> +	const struct shdma_ops *ops = sdev->ops;
> +	int ret;
> +
> +	if (slave_id < 0 || slave_id >= slave_num)
> +		return -EINVAL;
> +
> +	if (test_and_set_bit(slave_id, shdma_slave_used))
> +		return -EBUSY;
> +
> +	ret = ops->set_slave(schan, slave_id, false);
> +	if (ret < 0) {
> +		clear_bit(slave_id, shdma_slave_used);
> +		return ret;
> +	}
> +
> +	schan->slave_id = slave_id;
> +
> +	return 0;
> +}
> +
> +/*
> + * This is the standard shdma filter function to be used as a replacement to the
> + * "old" method, using the .private pointer. If for some reason you allocate a
> + * channel without slave data, use something like ERR_PTR(-EINVAL) as a filter
> + * parameter. If this filter is used, the slave driver, after calling
> + * dma_request_channel(), will also have to call dmaengine_slave_config() with
> + * .slave_id, .direction, and either .src_addr or .dst_addr set.
> + * NOTE: this filter doesn't support multiple DMAC drivers with the DMA_SLAVE
> + * capability! If this becomes a requirement, hardware glue drivers, using this
> + * services would have to provide their own filters, which first would check
> + * the device driver, similar to how other DMAC drivers, e.g., sa11x0-dma.c, do
> + * this, and only then, in case of a match, call this common filter.
> + */
> +bool shdma_chan_filter(struct dma_chan *chan, void *arg)
> +{
> +	struct shdma_chan *schan = to_shdma_chan(chan);
> +	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
> +	const struct shdma_ops *ops = sdev->ops;
> +	int slave_id = (int)arg;
> +	int ret;
> +
> +	if (slave_id < 0)
> +		/* No slave requested - arbitrary channel */
> +		return true;
> +
> +	if (slave_id >= slave_num)
> +		return false;
> +
> +	ret = ops->set_slave(schan, slave_id, true);
> +	if (ret < 0)
> +		return false;
> +
> +	return true;
> +}
> +EXPORT_SYMBOL(shdma_chan_filter);
> +
>  static int shdma_alloc_chan_resources(struct dma_chan *chan)
>  {
>  	struct shdma_chan *schan = to_shdma_chan(chan);
> @@ -185,21 +244,10 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
>  	 * never runs concurrently with itself or free_chan_resources.
>  	 */
>  	if (slave) {
> -		if (slave->slave_id < 0 || slave->slave_id >= slave_num) {
> -			ret = -EINVAL;
> -			goto evalid;
> -		}
> -
> -		if (test_and_set_bit(slave->slave_id, shdma_slave_used)) {
> -			ret = -EBUSY;
> -			goto etestused;
> -		}
> -
> -		ret = ops->set_slave(schan, slave->slave_id);
> +		/* Legacy mode: .private is set in filter */
> +		ret = shdma_setup_slave(schan, slave->slave_id);
>  		if (ret < 0)
>  			goto esetslave;
> -
> -		schan->slave_id = slave->slave_id;
>  	} else {
>  		schan->slave_id = -EINVAL;
>  	}
> @@ -228,8 +276,6 @@ edescalloc:
>  	if (slave)
>  esetslave:
>  		clear_bit(slave->slave_id, shdma_slave_used);
> -etestused:
> -evalid:
>  	chan->private = NULL;
you missed this one
>  	return ret;
>  }
> @@ -587,22 +633,40 @@ static int shdma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
>  	struct shdma_chan *schan = to_shdma_chan(chan);
>  	struct shdma_dev *sdev = to_shdma_dev(chan->device);
>  	const struct shdma_ops *ops = sdev->ops;
> +	struct dma_slave_config *config;
>  	unsigned long flags;
> -
> -	/* Only supports DMA_TERMINATE_ALL */
> -	if (cmd != DMA_TERMINATE_ALL)
> -		return -ENXIO;
> +	int ret;
>  
>  	if (!chan)
>  		return -EINVAL;
>  
> -	spin_lock_irqsave(&schan->chan_lock, flags);
> -
> -	ops->halt_channel(schan);
> -
> -	spin_unlock_irqrestore(&schan->chan_lock, flags);
> +	switch (cmd) {
> +	case DMA_TERMINATE_ALL:
> +		spin_lock_irqsave(&schan->chan_lock, flags);
> +		ops->halt_channel(schan);
> +		spin_unlock_irqrestore(&schan->chan_lock, flags);
>  
> -	shdma_chan_ld_cleanup(schan, true);
> +		shdma_chan_ld_cleanup(schan, true);
> +		break;
> +	case DMA_SLAVE_CONFIG:
> +		/*
> +		 * So far only .slave_id is used, but the slave drivers are
> +		 * encouraged to also set a transfer direction and an address.
> +		 */
> +		if (!arg)
> +			return -EINVAL;
> +		/*
> +		 * We could lock this, but you shouldn't be configuring the
> +		 * channel, while using it...
> +		 */
> +		config = (struct dma_slave_config*)arg;
> +		ret = shdma_setup_slave(schan, config->slave_id);
> +		if (ret < 0)
> +			return ret;
> +		break;
> +	default:
> +		return -ENXIO;
> +	}
>  
>  	return 0;
>  }
> diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
> index 9a10d8b..027c9be 100644
> --- a/drivers/dma/sh/shdma.c
> +++ b/drivers/dma/sh/shdma.c
> @@ -320,7 +320,7 @@ static const struct sh_dmae_slave_config *dmae_find_slave(
>  }
>  
>  static int sh_dmae_set_slave(struct shdma_chan *schan,
> -			     int slave_id)
> +			     int slave_id, bool try)
>  {
>  	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
>  						    shdma_chan);
> @@ -328,7 +328,8 @@ static int sh_dmae_set_slave(struct shdma_chan *schan,
>  	if (!cfg)
>  		return -ENODEV;
>  
> -	sh_chan->config = cfg;
> +	if (!try)
> +		sh_chan->config = cfg;
>  
>  	return 0;
>  }
> diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> index 4e83f3e..b64d6be 100644
> --- a/include/linux/sh_dma.h
> +++ b/include/linux/sh_dma.h
> @@ -99,4 +99,6 @@ struct sh_dmae_pdata {
>  #define CHCR_TE	0x00000002
>  #define CHCR_IE	0x00000004
>  
> +bool shdma_chan_filter(struct dma_chan *chan, void *arg);
> +
>  #endif
> diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
> index 6263ad2..93f9821 100644
> --- a/include/linux/shdma-base.h
> +++ b/include/linux/shdma-base.h
> @@ -93,7 +93,7 @@ struct shdma_ops {
>  	dma_addr_t (*slave_addr)(struct shdma_chan *);
>  	int (*desc_setup)(struct shdma_chan *, struct shdma_desc *,
>  			  dma_addr_t, dma_addr_t, size_t *);
> -	int (*set_slave)(struct shdma_chan *, int);
> +	int (*set_slave)(struct shdma_chan *, int, bool);
>  	void (*setup_xfer)(struct shdma_chan *, int);
>  	void (*start_xfer)(struct shdma_chan *, struct shdma_desc *);
>  	struct shdma_desc *(*embedded_desc)(void *, int);


-- 
~Vinod

Re: [PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private

[Guennadi Liakhovetski]

Hi Vinod

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> > This patch extends the sh dmaengine driver to support the preferred channel
> > selection and configuration method, instead of using the "private" field
> > from struct dma_chan. We add a standard filter function to be used by
> > slave drivers instead of implementing their own ones, and add support for
> > the DMA_SLAVE_CONFIG control operation, which must accompany the new
> > channel selection method. We still support the legacy .private channel
> > allocation method to cater for a smooth driver migration.
> There seem to be two things done in this patch, one is to provide a
> filter function for people to use for channel filtering, and second the
> removal of .private. It would be good to split these two.

No, please, see the patch description. This patch only provides a filter 
function. It does _not_ remove the use of .private yet. First all client 
drivers have to be ported over to use the new filter + slave-config 
scheme, only then will the driver be able to drop support for .private.

> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > ---
> >  drivers/dma/sh/shdma-base.c |  114 +++++++++++++++++++++++++++++++++---------
> >  drivers/dma/sh/shdma.c      |    5 +-
> >  include/linux/sh_dma.h      |    2 +
> >  include/linux/shdma-base.h  |    2 +-
> >  4 files changed, 95 insertions(+), 28 deletions(-)
> > 
> > diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
> > index 73db282..0c34c73 100644
> > --- a/drivers/dma/sh/shdma-base.c
> > +++ b/drivers/dma/sh/shdma-base.c
> > @@ -171,6 +171,65 @@ static struct shdma_desc *shdma_get_desc(struct shdma_chan *schan)
> >  	return NULL;
> >  }
> >  
> > +static int shdma_setup_slave(struct shdma_chan *schan, int slave_id)
> > +{
> > +	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
> > +	const struct shdma_ops *ops = sdev->ops;
> > +	int ret;
> > +
> > +	if (slave_id < 0 || slave_id >= slave_num)
> > +		return -EINVAL;
> > +
> > +	if (test_and_set_bit(slave_id, shdma_slave_used))
> > +		return -EBUSY;
> > +
> > +	ret = ops->set_slave(schan, slave_id, false);
> > +	if (ret < 0) {
> > +		clear_bit(slave_id, shdma_slave_used);
> > +		return ret;
> > +	}
> > +
> > +	schan->slave_id = slave_id;
> > +
> > +	return 0;
> > +}
> > +
> > +/*
> > + * This is the standard shdma filter function to be used as a replacement to the
> > + * "old" method, using the .private pointer. If for some reason you allocate a
> > + * channel without slave data, use something like ERR_PTR(-EINVAL) as a filter
> > + * parameter. If this filter is used, the slave driver, after calling
> > + * dma_request_channel(), will also have to call dmaengine_slave_config() with
> > + * .slave_id, .direction, and either .src_addr or .dst_addr set.
> > + * NOTE: this filter doesn't support multiple DMAC drivers with the DMA_SLAVE
> > + * capability! If this becomes a requirement, hardware glue drivers, using this
> > + * services would have to provide their own filters, which first would check
> > + * the device driver, similar to how other DMAC drivers, e.g., sa11x0-dma.c, do
> > + * this, and only then, in case of a match, call this common filter.
> > + */
> > +bool shdma_chan_filter(struct dma_chan *chan, void *arg)
> > +{
> > +	struct shdma_chan *schan = to_shdma_chan(chan);
> > +	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
> > +	const struct shdma_ops *ops = sdev->ops;
> > +	int slave_id = (int)arg;
> > +	int ret;
> > +
> > +	if (slave_id < 0)
> > +		/* No slave requested - arbitrary channel */
> > +		return true;
> > +
> > +	if (slave_id >= slave_num)
> > +		return false;
> > +
> > +	ret = ops->set_slave(schan, slave_id, true);
> > +	if (ret < 0)
> > +		return false;
> > +
> > +	return true;
> > +}
> > +EXPORT_SYMBOL(shdma_chan_filter);
> > +
> >  static int shdma_alloc_chan_resources(struct dma_chan *chan)
> >  {
> >  	struct shdma_chan *schan = to_shdma_chan(chan);
> > @@ -185,21 +244,10 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
> >  	 * never runs concurrently with itself or free_chan_resources.
> >  	 */
> >  	if (slave) {
> > -		if (slave->slave_id < 0 || slave->slave_id >= slave_num) {
> > -			ret = -EINVAL;
> > -			goto evalid;
> > -		}
> > -
> > -		if (test_and_set_bit(slave->slave_id, shdma_slave_used)) {
> > -			ret = -EBUSY;
> > -			goto etestused;
> > -		}
> > -
> > -		ret = ops->set_slave(schan, slave->slave_id);
> > +		/* Legacy mode: .private is set in filter */
> > +		ret = shdma_setup_slave(schan, slave->slave_id);
> >  		if (ret < 0)
> >  			goto esetslave;
> > -
> > -		schan->slave_id = slave->slave_id;
> >  	} else {
> >  		schan->slave_id = -EINVAL;
> >  	}
> > @@ -228,8 +276,6 @@ edescalloc:
> >  	if (slave)
> >  esetslave:
> >  		clear_bit(slave->slave_id, shdma_slave_used);
> > -etestused:
> > -evalid:
> >  	chan->private = NULL;
> you missed this one

Please, see above.

Thanks
Guennadi

> >  	return ret;
> >  }
> > @@ -587,22 +633,40 @@ static int shdma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
> >  	struct shdma_chan *schan = to_shdma_chan(chan);
> >  	struct shdma_dev *sdev = to_shdma_dev(chan->device);
> >  	const struct shdma_ops *ops = sdev->ops;
> > +	struct dma_slave_config *config;
> >  	unsigned long flags;
> > -
> > -	/* Only supports DMA_TERMINATE_ALL */
> > -	if (cmd != DMA_TERMINATE_ALL)
> > -		return -ENXIO;
> > +	int ret;
> >  
> >  	if (!chan)
> >  		return -EINVAL;
> >  
> > -	spin_lock_irqsave(&schan->chan_lock, flags);
> > -
> > -	ops->halt_channel(schan);
> > -
> > -	spin_unlock_irqrestore(&schan->chan_lock, flags);
> > +	switch (cmd) {
> > +	case DMA_TERMINATE_ALL:
> > +		spin_lock_irqsave(&schan->chan_lock, flags);
> > +		ops->halt_channel(schan);
> > +		spin_unlock_irqrestore(&schan->chan_lock, flags);
> >  
> > -	shdma_chan_ld_cleanup(schan, true);
> > +		shdma_chan_ld_cleanup(schan, true);
> > +		break;
> > +	case DMA_SLAVE_CONFIG:
> > +		/*
> > +		 * So far only .slave_id is used, but the slave drivers are
> > +		 * encouraged to also set a transfer direction and an address.
> > +		 */
> > +		if (!arg)
> > +			return -EINVAL;
> > +		/*
> > +		 * We could lock this, but you shouldn't be configuring the
> > +		 * channel, while using it...
> > +		 */
> > +		config = (struct dma_slave_config*)arg;
> > +		ret = shdma_setup_slave(schan, config->slave_id);
> > +		if (ret < 0)
> > +			return ret;
> > +		break;
> > +	default:
> > +		return -ENXIO;
> > +	}
> >  
> >  	return 0;
> >  }
> > diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
> > index 9a10d8b..027c9be 100644
> > --- a/drivers/dma/sh/shdma.c
> > +++ b/drivers/dma/sh/shdma.c
> > @@ -320,7 +320,7 @@ static const struct sh_dmae_slave_config *dmae_find_slave(
> >  }
> >  
> >  static int sh_dmae_set_slave(struct shdma_chan *schan,
> > -			     int slave_id)
> > +			     int slave_id, bool try)
> >  {
> >  	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
> >  						    shdma_chan);
> > @@ -328,7 +328,8 @@ static int sh_dmae_set_slave(struct shdma_chan *schan,
> >  	if (!cfg)
> >  		return -ENODEV;
> >  
> > -	sh_chan->config = cfg;
> > +	if (!try)
> > +		sh_chan->config = cfg;
> >  
> >  	return 0;
> >  }
> > diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> > index 4e83f3e..b64d6be 100644
> > --- a/include/linux/sh_dma.h
> > +++ b/include/linux/sh_dma.h
> > @@ -99,4 +99,6 @@ struct sh_dmae_pdata {
> >  #define CHCR_TE	0x00000002
> >  #define CHCR_IE	0x00000004
> >  
> > +bool shdma_chan_filter(struct dma_chan *chan, void *arg);
> > +
> >  #endif
> > diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
> > index 6263ad2..93f9821 100644
> > --- a/include/linux/shdma-base.h
> > +++ b/include/linux/shdma-base.h
> > @@ -93,7 +93,7 @@ struct shdma_ops {
> >  	dma_addr_t (*slave_addr)(struct shdma_chan *);
> >  	int (*desc_setup)(struct shdma_chan *, struct shdma_desc *,
> >  			  dma_addr_t, dma_addr_t, size_t *);
> > -	int (*set_slave)(struct shdma_chan *, int);
> > +	int (*set_slave)(struct shdma_chan *, int, bool);
> >  	void (*setup_xfer)(struct shdma_chan *, int);
> >  	void (*start_xfer)(struct shdma_chan *, struct shdma_desc *);
> >  	struct shdma_desc *(*embedded_desc)(void *, int);
> 
> 
> -- 
> ~Vinod
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private

[Guennadi Liakhovetski]

Hi Vinod

On Mon, 16 Jul 2012, Vinod Koul wrote:

> On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> > This patch extends the sh dmaengine driver to support the preferred channel
> > selection and configuration method, instead of using the "private" field
> > from struct dma_chan. We add a standard filter function to be used by
> > slave drivers instead of implementing their own ones, and add support for
> > the DMA_SLAVE_CONFIG control operation, which must accompany the new
> > channel selection method. We still support the legacy .private channel
> > allocation method to cater for a smooth driver migration.
> There seem to be two things done in this patch, one is to provide a
> filter function for people to use for channel filtering, and second the
> removal of .private. It would be good to split these two.

No, please, see the patch description. This patch only provides a filter 
function. It does _not_ remove the use of .private yet. First all client 
drivers have to be ported over to use the new filter + slave-config 
scheme, only then will the driver be able to drop support for .private.

> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > ---
> >  drivers/dma/sh/shdma-base.c |  114 +++++++++++++++++++++++++++++++++---------
> >  drivers/dma/sh/shdma.c      |    5 +-
> >  include/linux/sh_dma.h      |    2 +
> >  include/linux/shdma-base.h  |    2 +-
> >  4 files changed, 95 insertions(+), 28 deletions(-)
> > 
> > diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
> > index 73db282..0c34c73 100644
> > --- a/drivers/dma/sh/shdma-base.c
> > +++ b/drivers/dma/sh/shdma-base.c
> > @@ -171,6 +171,65 @@ static struct shdma_desc *shdma_get_desc(struct shdma_chan *schan)
> >  	return NULL;
> >  }
> >  
> > +static int shdma_setup_slave(struct shdma_chan *schan, int slave_id)
> > +{
> > +	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
> > +	const struct shdma_ops *ops = sdev->ops;
> > +	int ret;
> > +
> > +	if (slave_id < 0 || slave_id >= slave_num)
> > +		return -EINVAL;
> > +
> > +	if (test_and_set_bit(slave_id, shdma_slave_used))
> > +		return -EBUSY;
> > +
> > +	ret = ops->set_slave(schan, slave_id, false);
> > +	if (ret < 0) {
> > +		clear_bit(slave_id, shdma_slave_used);
> > +		return ret;
> > +	}
> > +
> > +	schan->slave_id = slave_id;
> > +
> > +	return 0;
> > +}
> > +
> > +/*
> > + * This is the standard shdma filter function to be used as a replacement to the
> > + * "old" method, using the .private pointer. If for some reason you allocate a
> > + * channel without slave data, use something like ERR_PTR(-EINVAL) as a filter
> > + * parameter. If this filter is used, the slave driver, after calling
> > + * dma_request_channel(), will also have to call dmaengine_slave_config() with
> > + * .slave_id, .direction, and either .src_addr or .dst_addr set.
> > + * NOTE: this filter doesn't support multiple DMAC drivers with the DMA_SLAVE
> > + * capability! If this becomes a requirement, hardware glue drivers, using this
> > + * services would have to provide their own filters, which first would check
> > + * the device driver, similar to how other DMAC drivers, e.g., sa11x0-dma.c, do
> > + * this, and only then, in case of a match, call this common filter.
> > + */
> > +bool shdma_chan_filter(struct dma_chan *chan, void *arg)
> > +{
> > +	struct shdma_chan *schan = to_shdma_chan(chan);
> > +	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
> > +	const struct shdma_ops *ops = sdev->ops;
> > +	int slave_id = (int)arg;
> > +	int ret;
> > +
> > +	if (slave_id < 0)
> > +		/* No slave requested - arbitrary channel */
> > +		return true;
> > +
> > +	if (slave_id >= slave_num)
> > +		return false;
> > +
> > +	ret = ops->set_slave(schan, slave_id, true);
> > +	if (ret < 0)
> > +		return false;
> > +
> > +	return true;
> > +}
> > +EXPORT_SYMBOL(shdma_chan_filter);
> > +
> >  static int shdma_alloc_chan_resources(struct dma_chan *chan)
> >  {
> >  	struct shdma_chan *schan = to_shdma_chan(chan);
> > @@ -185,21 +244,10 @@ static int shdma_alloc_chan_resources(struct dma_chan *chan)
> >  	 * never runs concurrently with itself or free_chan_resources.
> >  	 */
> >  	if (slave) {
> > -		if (slave->slave_id < 0 || slave->slave_id >= slave_num) {
> > -			ret = -EINVAL;
> > -			goto evalid;
> > -		}
> > -
> > -		if (test_and_set_bit(slave->slave_id, shdma_slave_used)) {
> > -			ret = -EBUSY;
> > -			goto etestused;
> > -		}
> > -
> > -		ret = ops->set_slave(schan, slave->slave_id);
> > +		/* Legacy mode: .private is set in filter */
> > +		ret = shdma_setup_slave(schan, slave->slave_id);
> >  		if (ret < 0)
> >  			goto esetslave;
> > -
> > -		schan->slave_id = slave->slave_id;
> >  	} else {
> >  		schan->slave_id = -EINVAL;
> >  	}
> > @@ -228,8 +276,6 @@ edescalloc:
> >  	if (slave)
> >  esetslave:
> >  		clear_bit(slave->slave_id, shdma_slave_used);
> > -etestused:
> > -evalid:
> >  	chan->private = NULL;
> you missed this one

Please, see above.

Thanks
Guennadi

> >  	return ret;
> >  }
> > @@ -587,22 +633,40 @@ static int shdma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
> >  	struct shdma_chan *schan = to_shdma_chan(chan);
> >  	struct shdma_dev *sdev = to_shdma_dev(chan->device);
> >  	const struct shdma_ops *ops = sdev->ops;
> > +	struct dma_slave_config *config;
> >  	unsigned long flags;
> > -
> > -	/* Only supports DMA_TERMINATE_ALL */
> > -	if (cmd != DMA_TERMINATE_ALL)
> > -		return -ENXIO;
> > +	int ret;
> >  
> >  	if (!chan)
> >  		return -EINVAL;
> >  
> > -	spin_lock_irqsave(&schan->chan_lock, flags);
> > -
> > -	ops->halt_channel(schan);
> > -
> > -	spin_unlock_irqrestore(&schan->chan_lock, flags);
> > +	switch (cmd) {
> > +	case DMA_TERMINATE_ALL:
> > +		spin_lock_irqsave(&schan->chan_lock, flags);
> > +		ops->halt_channel(schan);
> > +		spin_unlock_irqrestore(&schan->chan_lock, flags);
> >  
> > -	shdma_chan_ld_cleanup(schan, true);
> > +		shdma_chan_ld_cleanup(schan, true);
> > +		break;
> > +	case DMA_SLAVE_CONFIG:
> > +		/*
> > +		 * So far only .slave_id is used, but the slave drivers are
> > +		 * encouraged to also set a transfer direction and an address.
> > +		 */
> > +		if (!arg)
> > +			return -EINVAL;
> > +		/*
> > +		 * We could lock this, but you shouldn't be configuring the
> > +		 * channel, while using it...
> > +		 */
> > +		config = (struct dma_slave_config*)arg;
> > +		ret = shdma_setup_slave(schan, config->slave_id);
> > +		if (ret < 0)
> > +			return ret;
> > +		break;
> > +	default:
> > +		return -ENXIO;
> > +	}
> >  
> >  	return 0;
> >  }
> > diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
> > index 9a10d8b..027c9be 100644
> > --- a/drivers/dma/sh/shdma.c
> > +++ b/drivers/dma/sh/shdma.c
> > @@ -320,7 +320,7 @@ static const struct sh_dmae_slave_config *dmae_find_slave(
> >  }
> >  
> >  static int sh_dmae_set_slave(struct shdma_chan *schan,
> > -			     int slave_id)
> > +			     int slave_id, bool try)
> >  {
> >  	struct sh_dmae_chan *sh_chan = container_of(schan, struct sh_dmae_chan,
> >  						    shdma_chan);
> > @@ -328,7 +328,8 @@ static int sh_dmae_set_slave(struct shdma_chan *schan,
> >  	if (!cfg)
> >  		return -ENODEV;
> >  
> > -	sh_chan->config = cfg;
> > +	if (!try)
> > +		sh_chan->config = cfg;
> >  
> >  	return 0;
> >  }
> > diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> > index 4e83f3e..b64d6be 100644
> > --- a/include/linux/sh_dma.h
> > +++ b/include/linux/sh_dma.h
> > @@ -99,4 +99,6 @@ struct sh_dmae_pdata {
> >  #define CHCR_TE	0x00000002
> >  #define CHCR_IE	0x00000004
> >  
> > +bool shdma_chan_filter(struct dma_chan *chan, void *arg);
> > +
> >  #endif
> > diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
> > index 6263ad2..93f9821 100644
> > --- a/include/linux/shdma-base.h
> > +++ b/include/linux/shdma-base.h
> > @@ -93,7 +93,7 @@ struct shdma_ops {
> >  	dma_addr_t (*slave_addr)(struct shdma_chan *);
> >  	int (*desc_setup)(struct shdma_chan *, struct shdma_desc *,
> >  			  dma_addr_t, dma_addr_t, size_t *);
> > -	int (*set_slave)(struct shdma_chan *, int);
> > +	int (*set_slave)(struct shdma_chan *, int, bool);
> >  	void (*setup_xfer)(struct shdma_chan *, int);
> >  	void (*start_xfer)(struct shdma_chan *, struct shdma_desc *);
> >  	struct shdma_desc *(*embedded_desc)(void *, int);
> 
> 
> -- 
> ~Vinod
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH 7/7 v2] mmc: sh_mmcif: switch to the new DMA channel allocation and configuration

[Guennadi Liakhovetski]

Using the "private" field from struct dma_chan is deprecated. The sh
dmaengine driver now also supports the preferred DMA channel allocation
and configuration method, using a standard filter function and a channel
configuration operation. This patch updates sh_mmcif to use this new
method.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Chris Ball <cjb@laptop.org>
---
 drivers/mmc/host/sh_mmcif.c |   90 ++++++++++++++++++++++++------------------
 1 files changed, 51 insertions(+), 39 deletions(-)

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 9e3b9b1..0f07d28 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -211,8 +211,6 @@ struct sh_mmcif_host {
 	struct mmc_host *mmc;
 	struct mmc_request *mrq;
 	struct platform_device *pd;
-	struct sh_dmae_slave dma_slave_tx;
-	struct sh_dmae_slave dma_slave_rx;
 	struct clk *hclk;
 	unsigned int clk;
 	int bus_width;
@@ -371,52 +369,66 @@ static void sh_mmcif_start_dma_tx(struct sh_mmcif_host *host)
 		desc, cookie);
 }
 
-static bool sh_mmcif_filter(struct dma_chan *chan, void *arg)
-{
-	dev_dbg(chan->device->dev, "%s: slave data %p\n", __func__, arg);
-	chan->private = arg;
-	return true;
-}
-
 static void sh_mmcif_request_dma(struct sh_mmcif_host *host,
 				 struct sh_mmcif_plat_data *pdata)
 {
-	struct sh_dmae_slave *tx, *rx;
+	struct resource *res = platform_get_resource(host->pd, IORESOURCE_MEM, 0);
+	struct dma_slave_config cfg;
+	dma_cap_mask_t mask;
+	int ret;
+
 	host->dma_active = false;
 
+	if (pdata->slave_id_tx <= 0 || pdata->slave_id_rx <= 0)
+		return;
+
 	/* We can only either use DMA for both Tx and Rx or not use it at all */
-	tx = &host->dma_slave_tx;
-	tx->shdma_slave.slave_id = pdata->slave_id_tx;
-	rx = &host->dma_slave_rx;
-	rx->shdma_slave.slave_id = pdata->slave_id_rx;
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	host->chan_tx = dma_request_channel(mask, shdma_chan_filter,
+					    (void *)pdata->slave_id_tx);
+	dev_dbg(&host->pd->dev, "%s: TX: got channel %p\n", __func__,
+		host->chan_tx);
 
-	if (tx->shdma_slave.slave_id > 0 && rx->shdma_slave.slave_id > 0) {
-		dma_cap_mask_t mask;
+	if (!host->chan_tx)
+		return;
 
-		dma_cap_zero(mask);
-		dma_cap_set(DMA_SLAVE, mask);
+	cfg.slave_id = pdata->slave_id_tx;
+	cfg.direction = DMA_MEM_TO_DEV;
+	cfg.dst_addr = res->start + MMCIF_CE_DATA;
+	cfg.src_addr = 0;
+	ret = dmaengine_slave_config(host->chan_tx, &cfg);
+	if (ret < 0)
+		goto ecfgtx;
 
-		host->chan_tx = dma_request_channel(mask, sh_mmcif_filter,
-						    &tx->shdma_slave);
-		dev_dbg(&host->pd->dev, "%s: TX: got channel %p\n", __func__,
-			host->chan_tx);
+	host->chan_rx = dma_request_channel(mask, shdma_chan_filter,
+					    (void *)pdata->slave_id_rx);
+	dev_dbg(&host->pd->dev, "%s: RX: got channel %p\n", __func__,
+		host->chan_rx);
 
-		if (!host->chan_tx)
-			return;
+	if (!host->chan_rx)
+		goto erqrx;
 
-		host->chan_rx = dma_request_channel(mask, sh_mmcif_filter,
-						    &rx->shdma_slave);
-		dev_dbg(&host->pd->dev, "%s: RX: got channel %p\n", __func__,
-			host->chan_rx);
+	cfg.slave_id = pdata->slave_id_rx;
+	cfg.direction = DMA_DEV_TO_MEM;
+	cfg.dst_addr = 0;
+	cfg.src_addr = res->start + MMCIF_CE_DATA;
+	ret = dmaengine_slave_config(host->chan_rx, &cfg);
+	if (ret < 0)
+		goto ecfgrx;
 
-		if (!host->chan_rx) {
-			dma_release_channel(host->chan_tx);
-			host->chan_tx = NULL;
-			return;
-		}
+	init_completion(&host->dma_complete);
 
-		init_completion(&host->dma_complete);
-	}
+	return;
+
+ecfgrx:
+	dma_release_channel(host->chan_rx);
+	host->chan_rx = NULL;
+erqrx:
+ecfgtx:
+	dma_release_channel(host->chan_tx);
+	host->chan_tx = NULL;
 }
 
 static void sh_mmcif_release_dma(struct sh_mmcif_host *host)
-- 
1.7.2.5

[PATCH 7/7 v2] mmc: sh_mmcif: switch to the new DMA channel allocation and configuration

[Guennadi Liakhovetski]

Using the "private" field from struct dma_chan is deprecated. The sh
dmaengine driver now also supports the preferred DMA channel allocation
and configuration method, using a standard filter function and a channel
configuration operation. This patch updates sh_mmcif to use this new
method.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Chris Ball <cjb@laptop.org>
---
 drivers/mmc/host/sh_mmcif.c |   90 ++++++++++++++++++++++++------------------
 1 files changed, 51 insertions(+), 39 deletions(-)

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 9e3b9b1..0f07d28 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -211,8 +211,6 @@ struct sh_mmcif_host {
 	struct mmc_host *mmc;
 	struct mmc_request *mrq;
 	struct platform_device *pd;
-	struct sh_dmae_slave dma_slave_tx;
-	struct sh_dmae_slave dma_slave_rx;
 	struct clk *hclk;
 	unsigned int clk;
 	int bus_width;
@@ -371,52 +369,66 @@ static void sh_mmcif_start_dma_tx(struct sh_mmcif_host *host)
 		desc, cookie);
 }
 
-static bool sh_mmcif_filter(struct dma_chan *chan, void *arg)
-{
-	dev_dbg(chan->device->dev, "%s: slave data %p\n", __func__, arg);
-	chan->private = arg;
-	return true;
-}
-
 static void sh_mmcif_request_dma(struct sh_mmcif_host *host,
 				 struct sh_mmcif_plat_data *pdata)
 {
-	struct sh_dmae_slave *tx, *rx;
+	struct resource *res = platform_get_resource(host->pd, IORESOURCE_MEM, 0);
+	struct dma_slave_config cfg;
+	dma_cap_mask_t mask;
+	int ret;
+
 	host->dma_active = false;
 
+	if (pdata->slave_id_tx <= 0 || pdata->slave_id_rx <= 0)
+		return;
+
 	/* We can only either use DMA for both Tx and Rx or not use it at all */
-	tx = &host->dma_slave_tx;
-	tx->shdma_slave.slave_id = pdata->slave_id_tx;
-	rx = &host->dma_slave_rx;
-	rx->shdma_slave.slave_id = pdata->slave_id_rx;
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	host->chan_tx = dma_request_channel(mask, shdma_chan_filter,
+					    (void *)pdata->slave_id_tx);
+	dev_dbg(&host->pd->dev, "%s: TX: got channel %p\n", __func__,
+		host->chan_tx);
 
-	if (tx->shdma_slave.slave_id > 0 && rx->shdma_slave.slave_id > 0) {
-		dma_cap_mask_t mask;
+	if (!host->chan_tx)
+		return;
 
-		dma_cap_zero(mask);
-		dma_cap_set(DMA_SLAVE, mask);
+	cfg.slave_id = pdata->slave_id_tx;
+	cfg.direction = DMA_MEM_TO_DEV;
+	cfg.dst_addr = res->start + MMCIF_CE_DATA;
+	cfg.src_addr = 0;
+	ret = dmaengine_slave_config(host->chan_tx, &cfg);
+	if (ret < 0)
+		goto ecfgtx;
 
-		host->chan_tx = dma_request_channel(mask, sh_mmcif_filter,
-						    &tx->shdma_slave);
-		dev_dbg(&host->pd->dev, "%s: TX: got channel %p\n", __func__,
-			host->chan_tx);
+	host->chan_rx = dma_request_channel(mask, shdma_chan_filter,
+					    (void *)pdata->slave_id_rx);
+	dev_dbg(&host->pd->dev, "%s: RX: got channel %p\n", __func__,
+		host->chan_rx);
 
-		if (!host->chan_tx)
-			return;
+	if (!host->chan_rx)
+		goto erqrx;
 
-		host->chan_rx = dma_request_channel(mask, sh_mmcif_filter,
-						    &rx->shdma_slave);
-		dev_dbg(&host->pd->dev, "%s: RX: got channel %p\n", __func__,
-			host->chan_rx);
+	cfg.slave_id = pdata->slave_id_rx;
+	cfg.direction = DMA_DEV_TO_MEM;
+	cfg.dst_addr = 0;
+	cfg.src_addr = res->start + MMCIF_CE_DATA;
+	ret = dmaengine_slave_config(host->chan_rx, &cfg);
+	if (ret < 0)
+		goto ecfgrx;
 
-		if (!host->chan_rx) {
-			dma_release_channel(host->chan_tx);
-			host->chan_tx = NULL;
-			return;
-		}
+	init_completion(&host->dma_complete);
 
-		init_completion(&host->dma_complete);
-	}
+	return;
+
+ecfgrx:
+	dma_release_channel(host->chan_rx);
+	host->chan_rx = NULL;
+erqrx:
+ecfgtx:
+	dma_release_channel(host->chan_tx);
+	host->chan_tx = NULL;
 }
 
 static void sh_mmcif_release_dma(struct sh_mmcif_host *host)
-- 
1.7.2.5

Re: [PATCH 0/7 v2] dma: sh: stop using .private

[Vinod Koul]

On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> This patch series supersedes the one from yesterday with the same title. 
> The 4 patches from v1 are all unchanged, v2 just prepends them with 3 more 
> preparatory patches. From the original series description:
> 
> Here's an attempt to convert the shdma driver to a new method, whereby a 
> centrally provided filter function is used and the DMA_SLAVE_CONFIG command 
> is enabled for slave operation. The last patch is an illustration of how 
> this new method shall be used. If this approach is acceptable, I'll also 
> convert the remaining shdma user drivers. This patch series goes on top of 
> my earlier patches to split shdma.c.
Applied thanks.

Fixed one checkpatch issue though!!

ERROR: "(foo*)" should be "(foo *)"
#996: FILE: drivers/dma/sh/shdma-base.c:662:
+		config = (struct dma_slave_config*)arg;

Please *always* run checkpatch on the patches you send

-- 
~Vinod

Re: [PATCH 0/7 v2] dma: sh: stop using .private

[Vinod Koul]

On Thu, 2012-07-05 at 12:29 +0200, Guennadi Liakhovetski wrote:
> This patch series supersedes the one from yesterday with the same title. 
> The 4 patches from v1 are all unchanged, v2 just prepends them with 3 more 
> preparatory patches. From the original series description:
> 
> Here's an attempt to convert the shdma driver to a new method, whereby a 
> centrally provided filter function is used and the DMA_SLAVE_CONFIG command 
> is enabled for slave operation. The last patch is an illustration of how 
> this new method shall be used. If this approach is acceptable, I'll also 
> convert the remaining shdma user drivers. This patch series goes on top of 
> my earlier patches to split shdma.c.
Applied thanks.

Fixed one checkpatch issue though!!

ERROR: "(foo*)" should be "(foo *)"
#996: FILE: drivers/dma/sh/shdma-base.c:662:
+		config = (struct dma_slave_config*)arg;

Please *always* run checkpatch on the patches you send

-- 
~Vinod