* [PATCH 0/7 v2] dma: sh: stop using .private
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 0/7 v2] dma: sh: stop using .private
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 1/7 v2] dmaengine: shdma: (cosmetic) simplify a static function
2012-07-05 10:29 ` Guennadi Liakhovetski
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 1/7 v2] dmaengine: shdma: (cosmetic) simplify a static function
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering
2012-07-05 10:29 ` Guennadi Liakhovetski
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel, Mark Brown
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 = ¶m->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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel, Mark Brown
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 = ¶m->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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 3/7 v2] sh: remove unused DMA device pointer from SIU platform data
2012-07-05 10:29 ` Guennadi Liakhovetski
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel, Paul Mundt
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 3/7 v2] sh: remove unused DMA device pointer from SIU platform data
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel, Paul Mundt
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 4/7 v2] dmaengine: shdma: prepare to stop using struct dma_chan::private
2012-07-05 10:29 ` Guennadi Liakhovetski
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 4/7 v2] dmaengine: shdma: prepare to stop using struct dma_chan::private
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-05 10:29 ` Guennadi Liakhovetski
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private
2012-07-05 10:29 ` Guennadi Liakhovetski
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 7/7 v2] mmc: sh_mmcif: switch to the new DMA channel allocation and configuration
2012-07-05 10:29 ` Guennadi Liakhovetski
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel, Chris Ball
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH 7/7 v2] mmc: sh_mmcif: switch to the new DMA channel allocation and configuration
@ 2012-07-05 10:29 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 10:29 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel, Chris Ball
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering
2012-07-05 10:29 ` Guennadi Liakhovetski
@ 2012-07-05 12:08 ` Mark Brown
-1 siblings, 0 replies; 58+ messages in thread
From: Mark Brown @ 2012-07-05 12:08 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Vinod Koul, Magnus Damm, linux-sh, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering
@ 2012-07-05 12:08 ` Mark Brown
0 siblings, 0 replies; 58+ messages in thread
From: Mark Brown @ 2012-07-05 12:08 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Vinod Koul, Magnus Damm, linux-sh, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering
2012-07-05 12:08 ` Mark Brown
@ 2012-07-05 13:54 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 13:54 UTC (permalink / raw)
To: Mark Brown; +Cc: Vinod Koul, Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering
@ 2012-07-05 13:54 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 13:54 UTC (permalink / raw)
To: Mark Brown; +Cc: Vinod Koul, Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering
2012-07-05 13:54 ` Guennadi Liakhovetski
@ 2012-07-05 14:00 ` Mark Brown
-1 siblings, 0 replies; 58+ messages in thread
From: Mark Brown @ 2012-07-05 14:00 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Vinod Koul, Magnus Damm, linux-sh, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering
@ 2012-07-05 14:00 ` Mark Brown
0 siblings, 0 replies; 58+ messages in thread
From: Mark Brown @ 2012-07-05 14:00 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Vinod Koul, Magnus Damm, linux-sh, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering
2012-07-05 14:00 ` Mark Brown
@ 2012-07-05 14:08 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 14:08 UTC (permalink / raw)
To: Mark Brown; +Cc: Vinod Koul, Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering
@ 2012-07-05 14:08 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-05 14:08 UTC (permalink / raw)
To: Mark Brown; +Cc: Vinod Koul, Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-05 10:29 ` Guennadi Liakhovetski
@ 2012-07-16 6:19 ` Vinod Koul
-1 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 6:07 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 6:19 ` Vinod Koul
0 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 6:19 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private
2012-07-05 10:29 ` Guennadi Liakhovetski
@ 2012-07-16 6:31 ` Vinod Koul
-1 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 6:19 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private
2012-07-16 6:31 ` Vinod Koul
@ 2012-07-16 6:31 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 6:31 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private
@ 2012-07-16 6:31 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 6:31 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private
@ 2012-07-16 6:31 ` Vinod Koul
0 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 6:31 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 6:19 ` Vinod Koul
@ 2012-07-16 6:37 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 6:37 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 6:37 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 6:37 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 6:37 ` Guennadi Liakhovetski
@ 2012-07-16 6:57 ` Vinod Koul
-1 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 6:53 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 6:57 ` Vinod Koul
0 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 6:57 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 6:57 ` Vinod Koul
@ 2012-07-16 7:13 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 7:13 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 7:13 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 7:13 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 7:13 ` Guennadi Liakhovetski
@ 2012-07-16 8:40 ` Vinod Koul
-1 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 8:28 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 8:40 ` Vinod Koul
0 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 8:40 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 8:40 ` Vinod Koul
@ 2012-07-16 8:47 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 8:47 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 8:47 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 8:47 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 8:47 ` Guennadi Liakhovetski
@ 2012-07-16 9:49 ` Vinod Koul
-1 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 9:37 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 9:49 ` Vinod Koul
0 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 9:49 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 9:49 ` Vinod Koul
@ 2012-07-16 10:01 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 10:01 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 10:01 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 10:01 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 10:01 ` Guennadi Liakhovetski
@ 2012-07-16 10:36 ` Vinod Koul
-1 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 10:24 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 10:36 ` Vinod Koul
0 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 10:36 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 10:36 ` Vinod Koul
@ 2012-07-16 10:55 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 10:55 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 10:55 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 10:55 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 10:55 ` Guennadi Liakhovetski
@ 2012-07-16 11:24 ` Vinod Koul
-1 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 11:12 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 11:24 ` Vinod Koul
0 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-16 11:24 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 11:24 ` Vinod Koul
@ 2012-07-16 12:47 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 12:47 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-16 12:47 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-16 12:47 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-16 12:47 ` Guennadi Liakhovetski
@ 2012-07-18 3:26 ` Vinod Koul
-1 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-18 3:14 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-18 3:26 ` Vinod Koul
0 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-18 3:26 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
2012-07-18 3:26 ` Vinod Koul
@ 2012-07-18 8:34 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-18 8:34 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility
@ 2012-07-18 8:34 ` Guennadi Liakhovetski
0 siblings, 0 replies; 58+ messages in thread
From: Guennadi Liakhovetski @ 2012-07-18 8:34 UTC (permalink / raw)
To: Vinod Koul; +Cc: Magnus Damm, linux-sh, linux-kernel
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/
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 0/7 v2] dma: sh: stop using .private
2012-07-05 10:29 ` Guennadi Liakhovetski
@ 2012-07-20 6:12 ` Vinod Koul
-1 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-20 6:00 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 0/7 v2] dma: sh: stop using .private
@ 2012-07-20 6:12 ` Vinod Koul
0 siblings, 0 replies; 58+ messages in thread
From: Vinod Koul @ 2012-07-20 6:12 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Magnus Damm, linux-sh, linux-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
end of thread, other threads:[~2012-07-20 6:12 UTC | newest]
Thread overview: 58+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-05 10:29 [PATCH 0/7 v2] dma: sh: stop using .private Guennadi Liakhovetski
2012-07-05 10:29 ` Guennadi Liakhovetski
2012-07-05 10:29 ` [PATCH 1/7 v2] dmaengine: shdma: (cosmetic) simplify a static function Guennadi Liakhovetski
2012-07-05 10:29 ` Guennadi Liakhovetski
2012-07-05 10:29 ` [PATCH 2/7 v2] ASoC: siu: don't use DMA device for channel filtering Guennadi Liakhovetski
2012-07-05 10:29 ` Guennadi Liakhovetski
2012-07-05 12:08 ` Mark Brown
2012-07-05 12:08 ` Mark Brown
2012-07-05 13:54 ` Guennadi Liakhovetski
2012-07-05 13:54 ` Guennadi Liakhovetski
2012-07-05 14:00 ` Mark Brown
2012-07-05 14:00 ` Mark Brown
2012-07-05 14:08 ` Guennadi Liakhovetski
2012-07-05 14:08 ` Guennadi Liakhovetski
2012-07-05 10:29 ` [PATCH 3/7 v2] sh: remove unused DMA device pointer from SIU platform data Guennadi Liakhovetski
2012-07-05 10:29 ` Guennadi Liakhovetski
2012-07-05 10:29 ` [PATCH 4/7 v2] dmaengine: shdma: prepare to stop using struct dma_chan::private Guennadi Liakhovetski
2012-07-05 10:29 ` Guennadi Liakhovetski
2012-07-05 10:29 ` [PATCH 5/7 v2] dma: sh: use an integer slave ID to improve API compatibility Guennadi Liakhovetski
2012-07-05 10:29 ` Guennadi Liakhovetski
2012-07-16 6:07 ` Vinod Koul
2012-07-16 6:19 ` Vinod Koul
2012-07-16 6:37 ` Guennadi Liakhovetski
2012-07-16 6:37 ` Guennadi Liakhovetski
2012-07-16 6:53 ` Vinod Koul
2012-07-16 6:57 ` Vinod Koul
2012-07-16 7:13 ` Guennadi Liakhovetski
2012-07-16 7:13 ` Guennadi Liakhovetski
2012-07-16 8:28 ` Vinod Koul
2012-07-16 8:40 ` Vinod Koul
2012-07-16 8:47 ` Guennadi Liakhovetski
2012-07-16 8:47 ` Guennadi Liakhovetski
2012-07-16 9:37 ` Vinod Koul
2012-07-16 9:49 ` Vinod Koul
2012-07-16 10:01 ` Guennadi Liakhovetski
2012-07-16 10:01 ` Guennadi Liakhovetski
2012-07-16 10:24 ` Vinod Koul
2012-07-16 10:36 ` Vinod Koul
2012-07-16 10:55 ` Guennadi Liakhovetski
2012-07-16 10:55 ` Guennadi Liakhovetski
2012-07-16 11:12 ` Vinod Koul
2012-07-16 11:24 ` Vinod Koul
2012-07-16 12:47 ` Guennadi Liakhovetski
2012-07-16 12:47 ` Guennadi Liakhovetski
2012-07-18 3:14 ` Vinod Koul
2012-07-18 3:26 ` Vinod Koul
2012-07-18 8:34 ` Guennadi Liakhovetski
2012-07-18 8:34 ` Guennadi Liakhovetski
2012-07-05 10:29 ` [PATCH 6/7 v2] dma: sh: provide a migration path for slave drivers to stop using .private Guennadi Liakhovetski
2012-07-05 10:29 ` Guennadi Liakhovetski
2012-07-16 6:19 ` Vinod Koul
2012-07-16 6:31 ` Vinod Koul
2012-07-16 6:31 ` Guennadi Liakhovetski
2012-07-16 6:31 ` Guennadi Liakhovetski
2012-07-05 10:29 ` [PATCH 7/7 v2] mmc: sh_mmcif: switch to the new DMA channel allocation and configuration Guennadi Liakhovetski
2012-07-05 10:29 ` Guennadi Liakhovetski
2012-07-20 6:00 ` [PATCH 0/7 v2] dma: sh: stop using .private Vinod Koul
2012-07-20 6:12 ` Vinod Koul
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.