* [PATCH 00/32] dmaengine: Refactor the DMA40 driver
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
The aim of this patch-set is to refactor the DMA40 and its clients to
use the DMA APIs in the correct manor. It also encompasses a few
cleanups along the way.
When a client requests a channel, the driver should only do very basic
channel configuration, as the information passed from clients is very
limited at this stage. Instead, channels should be configured during a
separate call which is invoked after a channel number has been assigned.
This patch-set ensures that only the basic amount of configuration is
attempted at allocation time. By doing this, we're also allowing DMA
configuration to originate from Device Tree.
This process is ongoing, as there is still one outstanding client
waiting to be converted. The MSP (Audio) driver's DMA routines have
recently been adapted to this new way of doing things. Some patches
have been accepted, others are still on the lists. Once they have
all been applied, I can continue the refactoring process.
Ideally, I'd like this patch-set to go in order, as a full patch-set.
As to which tree it should go though, I don't have any strong
preference.
Documentation/devicetree/bindings/dma/ste-dma40.txt | 66 ++++++++++++++++
arch/arm/boot/dts/dbx5x0.dtsi | 46 ++++++++++-
arch/arm/mach-ux500/board-mop500-audio.c | 56 ++------------
arch/arm/mach-ux500/board-mop500-sdi.c | 40 ++--------
arch/arm/mach-ux500/board-mop500.c | 49 +++---------
arch/arm/mach-ux500/board-mop500.h | 1 +
arch/arm/mach-ux500/cpu-db8500.c | 60 +++++----------
arch/arm/mach-ux500/devices-db8500.c | 163 +++++++++++++++------------------------
arch/arm/mach-ux500/ste-dma40-db8500.h | 193 ++++++++++++++++------------------------------
arch/arm/mach-ux500/usb.c | 10 +--
drivers/dma/ste_dma40.c | 376 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------
drivers/dma/ste_dma40_ll.c | 112 +++++++++++++--------------
drivers/dma/ste_dma40_ll.h | 5 +-
include/linux/platform_data/dma-ste-dma40.h | 16 +---
14 files changed, 574 insertions(+), 619 deletions(-)
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 01/32] dmaengine: ste_dma40: Assign memcpy channels in the driver
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
The channels reserved for memcpy are the same for all currently
supported platforms. With this in mind, we can ease the platform
data passing requirement by moving these assignments out from
platform code and place them directly into the driver.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/devices-db8500.c | 12 ------------
drivers/dma/ste_dma40.c | 12 +++++++-----
include/linux/platform_data/dma-ste-dma40.h | 4 ----
3 files changed, 7 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index afa5b04..9b09683 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -146,22 +146,10 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
[DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
};
-/* Reserved event lines for memcpy only */
-static int dma40_memcpy_event[] = {
- DB8500_DMA_MEMCPY_TX_0,
- DB8500_DMA_MEMCPY_TX_1,
- DB8500_DMA_MEMCPY_TX_2,
- DB8500_DMA_MEMCPY_TX_3,
- DB8500_DMA_MEMCPY_TX_4,
- DB8500_DMA_MEMCPY_TX_5,
-};
-
static struct stedma40_platform_data dma40_plat_data = {
.dev_len = DB8500_DMA_NR_DEV,
.dev_rx = dma40_rx_map,
.dev_tx = dma40_tx_map,
- .memcpy = dma40_memcpy_event,
- .memcpy_len = ARRAY_SIZE(dma40_memcpy_event),
.memcpy_conf_phy = &dma40_memcpy_conf_phy,
.memcpy_conf_log = &dma40_memcpy_conf_log,
.disabled_channels = {-1},
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 1734fee..12de79e 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -55,6 +55,9 @@
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
+/* Reserved event lines for memcpy only. */
+static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
+
/**
* enum 40_command - The different commands and/or statuses.
*
@@ -2014,8 +2017,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
- d40c->dma_cfg.dst_dev_type = d40c->base->plat_data->
- memcpy[d40c->chan.chan_id];
+ d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
} else if (dma_has_cap(DMA_MEMCPY, cap) &&
dma_has_cap(DMA_SLAVE, cap)) {
@@ -2927,7 +2929,7 @@ static int __init d40_dmaengine_init(struct d40_base *base,
}
d40_chan_init(base, &base->dma_memcpy, base->log_chans,
- base->num_log_chans, base->plat_data->memcpy_len);
+ base->num_log_chans, ARRAY_SIZE(dma40_memcpy_channels));
dma_cap_zero(base->dma_memcpy.cap_mask);
dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
@@ -3215,7 +3217,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
num_log_chans++;
base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
- (num_phy_chans + num_log_chans + plat_data->memcpy_len) *
+ (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
sizeof(struct d40_chan), GFP_KERNEL);
if (base == NULL) {
@@ -3276,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
if (!base->lookup_phy_chans)
goto failure;
- if (num_log_chans + plat_data->memcpy_len) {
+ if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
/*
* The max number of logical channels are event lines for all
* src devices and dst devices
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 4b78101..a808784 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
* @dev_len: length of dev_tx and dev_rx
* @dev_tx: mapping between destination event line and io address
* @dev_rx: mapping between source event line and io address
- * @memcpy: list of memcpy event lines
- * @memcpy_len: length of memcpy
* @memcpy_conf_phy: default configuration of physical channel memcpy
* @memcpy_conf_log: default configuration of logical channel memcpy
* @disabled_channels: A vector, ending with -1, that marks physical channels
@@ -162,8 +160,6 @@ struct stedma40_platform_data {
u32 dev_len;
const dma_addr_t *dev_tx;
const dma_addr_t *dev_rx;
- int *memcpy;
- u32 memcpy_len;
struct stedma40_chan_cfg *memcpy_conf_phy;
struct stedma40_chan_cfg *memcpy_conf_log;
int disabled_channels[STEDMA40_MAX_PHYS];
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 01/32] dmaengine: ste_dma40: Assign memcpy channels in the driver
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
The channels reserved for memcpy are the same for all currently
supported platforms. With this in mind, we can ease the platform
data passing requirement by moving these assignments out from
platform code and place them directly into the driver.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/devices-db8500.c | 12 ------------
drivers/dma/ste_dma40.c | 12 +++++++-----
include/linux/platform_data/dma-ste-dma40.h | 4 ----
3 files changed, 7 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index afa5b04..9b09683 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -146,22 +146,10 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
[DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
};
-/* Reserved event lines for memcpy only */
-static int dma40_memcpy_event[] = {
- DB8500_DMA_MEMCPY_TX_0,
- DB8500_DMA_MEMCPY_TX_1,
- DB8500_DMA_MEMCPY_TX_2,
- DB8500_DMA_MEMCPY_TX_3,
- DB8500_DMA_MEMCPY_TX_4,
- DB8500_DMA_MEMCPY_TX_5,
-};
-
static struct stedma40_platform_data dma40_plat_data = {
.dev_len = DB8500_DMA_NR_DEV,
.dev_rx = dma40_rx_map,
.dev_tx = dma40_tx_map,
- .memcpy = dma40_memcpy_event,
- .memcpy_len = ARRAY_SIZE(dma40_memcpy_event),
.memcpy_conf_phy = &dma40_memcpy_conf_phy,
.memcpy_conf_log = &dma40_memcpy_conf_log,
.disabled_channels = {-1},
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 1734fee..12de79e 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -55,6 +55,9 @@
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
+/* Reserved event lines for memcpy only. */
+static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
+
/**
* enum 40_command - The different commands and/or statuses.
*
@@ -2014,8 +2017,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
- d40c->dma_cfg.dst_dev_type = d40c->base->plat_data->
- memcpy[d40c->chan.chan_id];
+ d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
} else if (dma_has_cap(DMA_MEMCPY, cap) &&
dma_has_cap(DMA_SLAVE, cap)) {
@@ -2927,7 +2929,7 @@ static int __init d40_dmaengine_init(struct d40_base *base,
}
d40_chan_init(base, &base->dma_memcpy, base->log_chans,
- base->num_log_chans, base->plat_data->memcpy_len);
+ base->num_log_chans, ARRAY_SIZE(dma40_memcpy_channels));
dma_cap_zero(base->dma_memcpy.cap_mask);
dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
@@ -3215,7 +3217,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
num_log_chans++;
base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
- (num_phy_chans + num_log_chans + plat_data->memcpy_len) *
+ (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
sizeof(struct d40_chan), GFP_KERNEL);
if (base == NULL) {
@@ -3276,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
if (!base->lookup_phy_chans)
goto failure;
- if (num_log_chans + plat_data->memcpy_len) {
+ if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
/*
* The max number of logical channels are event lines for all
* src devices and dst devices
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 4b78101..a808784 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
* @dev_len: length of dev_tx and dev_rx
* @dev_tx: mapping between destination event line and io address
* @dev_rx: mapping between source event line and io address
- * @memcpy: list of memcpy event lines
- * @memcpy_len: length of memcpy
* @memcpy_conf_phy: default configuration of physical channel memcpy
* @memcpy_conf_log: default configuration of logical channel memcpy
* @disabled_channels: A vector, ending with -1, that marks physical channels
@@ -162,8 +160,6 @@ struct stedma40_platform_data {
u32 dev_len;
const dma_addr_t *dev_tx;
const dma_addr_t *dev_rx;
- int *memcpy;
- u32 memcpy_len;
struct stedma40_chan_cfg *memcpy_conf_phy;
struct stedma40_chan_cfg *memcpy_conf_log;
int disabled_channels[STEDMA40_MAX_PHYS];
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 01/32] dmaengine: ste_dma40: Assign memcpy channels in the driver
2013-04-18 10:11 ` Lee Jones
@ 2013-04-22 9:22 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:22 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:11:43AM +0100, Lee Jones wrote:
> The channels reserved for memcpy are the same for all currently
> supported platforms. With this in mind, we can ease the platform
> data passing requirement by moving these assignments out from
> platform code and place them directly into the driver.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> arch/arm/mach-ux500/devices-db8500.c | 12 ------------
> drivers/dma/ste_dma40.c | 12 +++++++-----
> include/linux/platform_data/dma-ste-dma40.h | 4 ----
> 3 files changed, 7 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> index afa5b04..9b09683 100644
> --- a/arch/arm/mach-ux500/devices-db8500.c
> +++ b/arch/arm/mach-ux500/devices-db8500.c
> @@ -146,22 +146,10 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
> [DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
> };
>
> -/* Reserved event lines for memcpy only */
> -static int dma40_memcpy_event[] = {
> - DB8500_DMA_MEMCPY_TX_0,
> - DB8500_DMA_MEMCPY_TX_1,
> - DB8500_DMA_MEMCPY_TX_2,
> - DB8500_DMA_MEMCPY_TX_3,
> - DB8500_DMA_MEMCPY_TX_4,
> - DB8500_DMA_MEMCPY_TX_5,
> -};
> -
> static struct stedma40_platform_data dma40_plat_data = {
> .dev_len = DB8500_DMA_NR_DEV,
> .dev_rx = dma40_rx_map,
> .dev_tx = dma40_tx_map,
> - .memcpy = dma40_memcpy_event,
> - .memcpy_len = ARRAY_SIZE(dma40_memcpy_event),
> .memcpy_conf_phy = &dma40_memcpy_conf_phy,
> .memcpy_conf_log = &dma40_memcpy_conf_log,
> .disabled_channels = {-1},
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 1734fee..12de79e 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -55,6 +55,9 @@
>
> #define MAX(a, b) (((a) < (b)) ? (b) : (a))
>
> +/* Reserved event lines for memcpy only. */
> +static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
> +
> /**
> * enum 40_command - The different commands and/or statuses.
> *
> @@ -2014,8 +2017,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
> if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
> d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
> d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
> - d40c->dma_cfg.dst_dev_type = d40c->base->plat_data->
> - memcpy[d40c->chan.chan_id];
> + d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
>
> } else if (dma_has_cap(DMA_MEMCPY, cap) &&
> dma_has_cap(DMA_SLAVE, cap)) {
> @@ -2927,7 +2929,7 @@ static int __init d40_dmaengine_init(struct d40_base *base,
> }
>
> d40_chan_init(base, &base->dma_memcpy, base->log_chans,
> - base->num_log_chans, base->plat_data->memcpy_len);
> + base->num_log_chans, ARRAY_SIZE(dma40_memcpy_channels));
>
> dma_cap_zero(base->dma_memcpy.cap_mask);
> dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
> @@ -3215,7 +3217,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> num_log_chans++;
>
> base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
> - (num_phy_chans + num_log_chans + plat_data->memcpy_len) *
> + (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
> sizeof(struct d40_chan), GFP_KERNEL);
>
> if (base == NULL) {
> @@ -3276,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> if (!base->lookup_phy_chans)
> goto failure;
>
> - if (num_log_chans + plat_data->memcpy_len) {
> + if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
> /*
> * The max number of logical channels are event lines for all
> * src devices and dst devices
> diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
> index 4b78101..a808784 100644
> --- a/include/linux/platform_data/dma-ste-dma40.h
> +++ b/include/linux/platform_data/dma-ste-dma40.h
> @@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
> * @dev_len: length of dev_tx and dev_rx
> * @dev_tx: mapping between destination event line and io address
> * @dev_rx: mapping between source event line and io address
> - * @memcpy: list of memcpy event lines
> - * @memcpy_len: length of memcpy
> * @memcpy_conf_phy: default configuration of physical channel memcpy
> * @memcpy_conf_log: default configuration of logical channel memcpy
> * @disabled_channels: A vector, ending with -1, that marks physical channels
> @@ -162,8 +160,6 @@ struct stedma40_platform_data {
> u32 dev_len;
> const dma_addr_t *dev_tx;
> const dma_addr_t *dev_rx;
> - int *memcpy;
> - u32 memcpy_len;
> struct stedma40_chan_cfg *memcpy_conf_phy;
> struct stedma40_chan_cfg *memcpy_conf_log;
> int disabled_channels[STEDMA40_MAX_PHYS];
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 01/32] dmaengine: ste_dma40: Assign memcpy channels in the driver
@ 2013-04-22 9:22 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:11:43AM +0100, Lee Jones wrote:
> The channels reserved for memcpy are the same for all currently
> supported platforms. With this in mind, we can ease the platform
> data passing requirement by moving these assignments out from
> platform code and place them directly into the driver.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> arch/arm/mach-ux500/devices-db8500.c | 12 ------------
> drivers/dma/ste_dma40.c | 12 +++++++-----
> include/linux/platform_data/dma-ste-dma40.h | 4 ----
> 3 files changed, 7 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> index afa5b04..9b09683 100644
> --- a/arch/arm/mach-ux500/devices-db8500.c
> +++ b/arch/arm/mach-ux500/devices-db8500.c
> @@ -146,22 +146,10 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
> [DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
> };
>
> -/* Reserved event lines for memcpy only */
> -static int dma40_memcpy_event[] = {
> - DB8500_DMA_MEMCPY_TX_0,
> - DB8500_DMA_MEMCPY_TX_1,
> - DB8500_DMA_MEMCPY_TX_2,
> - DB8500_DMA_MEMCPY_TX_3,
> - DB8500_DMA_MEMCPY_TX_4,
> - DB8500_DMA_MEMCPY_TX_5,
> -};
> -
> static struct stedma40_platform_data dma40_plat_data = {
> .dev_len = DB8500_DMA_NR_DEV,
> .dev_rx = dma40_rx_map,
> .dev_tx = dma40_tx_map,
> - .memcpy = dma40_memcpy_event,
> - .memcpy_len = ARRAY_SIZE(dma40_memcpy_event),
> .memcpy_conf_phy = &dma40_memcpy_conf_phy,
> .memcpy_conf_log = &dma40_memcpy_conf_log,
> .disabled_channels = {-1},
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 1734fee..12de79e 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -55,6 +55,9 @@
>
> #define MAX(a, b) (((a) < (b)) ? (b) : (a))
>
> +/* Reserved event lines for memcpy only. */
> +static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
> +
> /**
> * enum 40_command - The different commands and/or statuses.
> *
> @@ -2014,8 +2017,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
> if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
> d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
> d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
> - d40c->dma_cfg.dst_dev_type = d40c->base->plat_data->
> - memcpy[d40c->chan.chan_id];
> + d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
>
> } else if (dma_has_cap(DMA_MEMCPY, cap) &&
> dma_has_cap(DMA_SLAVE, cap)) {
> @@ -2927,7 +2929,7 @@ static int __init d40_dmaengine_init(struct d40_base *base,
> }
>
> d40_chan_init(base, &base->dma_memcpy, base->log_chans,
> - base->num_log_chans, base->plat_data->memcpy_len);
> + base->num_log_chans, ARRAY_SIZE(dma40_memcpy_channels));
>
> dma_cap_zero(base->dma_memcpy.cap_mask);
> dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
> @@ -3215,7 +3217,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> num_log_chans++;
>
> base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
> - (num_phy_chans + num_log_chans + plat_data->memcpy_len) *
> + (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
> sizeof(struct d40_chan), GFP_KERNEL);
>
> if (base == NULL) {
> @@ -3276,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> if (!base->lookup_phy_chans)
> goto failure;
>
> - if (num_log_chans + plat_data->memcpy_len) {
> + if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
> /*
> * The max number of logical channels are event lines for all
> * src devices and dst devices
> diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
> index 4b78101..a808784 100644
> --- a/include/linux/platform_data/dma-ste-dma40.h
> +++ b/include/linux/platform_data/dma-ste-dma40.h
> @@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
> * @dev_len: length of dev_tx and dev_rx
> * @dev_tx: mapping between destination event line and io address
> * @dev_rx: mapping between source event line and io address
> - * @memcpy: list of memcpy event lines
> - * @memcpy_len: length of memcpy
> * @memcpy_conf_phy: default configuration of physical channel memcpy
> * @memcpy_conf_log: default configuration of logical channel memcpy
> * @disabled_channels: A vector, ending with -1, that marks physical channels
> @@ -162,8 +160,6 @@ struct stedma40_platform_data {
> u32 dev_len;
> const dma_addr_t *dev_tx;
> const dma_addr_t *dev_rx;
> - int *memcpy;
> - u32 memcpy_len;
> struct stedma40_chan_cfg *memcpy_conf_phy;
> struct stedma40_chan_cfg *memcpy_conf_log;
> int disabled_channels[STEDMA40_MAX_PHYS];
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 01/32] dmaengine: ste_dma40: Assign memcpy channels in the driver
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 9:20 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 9:20 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Rabin Vincent, Linus WALLEIJ,
Arnd Bergmann, Vinod Koul, Per Forlin, Dan Williams
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The channels reserved for memcpy are the same for all currently
> supported platforms. With this in mind, we can ease the platform
> data passing requirement by moving these assignments out from
> platform code and place them directly into the driver.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(...)
> - if (num_log_chans + plat_data->memcpy_len) {
> + if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
> /*
> * The max number of logical channels are event lines for all
> * src devices and dst devices
So as mentioned in review of another patch there is a kzalloc
right below here where you forget to add + ARRAY_SIZE(dma40_memcpy_channels)
please fix this...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 01/32] dmaengine: ste_dma40: Assign memcpy channels in the driver
@ 2013-04-25 9:20 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 9:20 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The channels reserved for memcpy are the same for all currently
> supported platforms. With this in mind, we can ease the platform
> data passing requirement by moving these assignments out from
> platform code and place them directly into the driver.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(...)
> - if (num_log_chans + plat_data->memcpy_len) {
> + if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
> /*
> * The max number of logical channels are event lines for all
> * src devices and dst devices
So as mentioned in review of another patch there is a kzalloc
right below here where you forget to add + ARRAY_SIZE(dma40_memcpy_channels)
please fix this...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 02/32] dmaengine: ste_dma40: Move default memcpy configs into the driver
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
There are only two default memcpy configurations used for the DMA40
driver; one for physical memcpy and one for logical memcpy. Instead
of invariably passing the same configurations though platform data,
we're moving them into the driver instead.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/devices-db8500.c | 28 -----------------------
drivers/dma/ste_dma40.c | 32 +++++++++++++++++++++++++--
include/linux/platform_data/dma-ste-dma40.h | 4 ----
3 files changed, 30 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 9b09683..5b1f1f7 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -42,32 +42,6 @@ static struct resource dma40_resources[] = {
}
};
-/* Default configuration for physcial memcpy */
-struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
- .mode = STEDMA40_MODE_PHYSICAL,
- .dir = STEDMA40_MEM_TO_MEM,
-
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .src_info.psize = STEDMA40_PSIZE_PHY_1,
- .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.psize = STEDMA40_PSIZE_PHY_1,
- .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-};
-/* Default configuration for logical memcpy */
-struct stedma40_chan_cfg dma40_memcpy_conf_log = {
- .dir = STEDMA40_MEM_TO_MEM,
-
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .src_info.psize = STEDMA40_PSIZE_LOG_1,
- .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.psize = STEDMA40_PSIZE_LOG_1,
- .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-};
-
/*
* Mapping between destination event lines and physical device address.
* The event line is tied to a device and therefore the address is constant.
@@ -150,8 +124,6 @@ static struct stedma40_platform_data dma40_plat_data = {
.dev_len = DB8500_DMA_NR_DEV,
.dev_rx = dma40_rx_map,
.dev_tx = dma40_tx_map,
- .memcpy_conf_phy = &dma40_memcpy_conf_phy,
- .memcpy_conf_log = &dma40_memcpy_conf_log,
.disabled_channels = {-1},
};
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 12de79e..3b83dee 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -58,6 +58,34 @@
/* Reserved event lines for memcpy only. */
static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
+/* Default configuration for physcial memcpy */
+struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
+ .mode = STEDMA40_MODE_PHYSICAL,
+ .dir = STEDMA40_MEM_TO_MEM,
+
+ .src_info.data_width = STEDMA40_BYTE_WIDTH,
+ .src_info.psize = STEDMA40_PSIZE_PHY_1,
+ .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+
+ .dst_info.data_width = STEDMA40_BYTE_WIDTH,
+ .dst_info.psize = STEDMA40_PSIZE_PHY_1,
+ .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+};
+
+/* Default configuration for logical memcpy */
+struct stedma40_chan_cfg dma40_memcpy_conf_log = {
+ .mode = STEDMA40_MODE_LOGICAL,
+ .dir = STEDMA40_MEM_TO_MEM,
+
+ .src_info.data_width = STEDMA40_BYTE_WIDTH,
+ .src_info.psize = STEDMA40_PSIZE_LOG_1,
+ .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+
+ .dst_info.data_width = STEDMA40_BYTE_WIDTH,
+ .dst_info.psize = STEDMA40_PSIZE_LOG_1,
+ .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+};
+
/**
* enum 40_command - The different commands and/or statuses.
*
@@ -2015,13 +2043,13 @@ static int d40_config_memcpy(struct d40_chan *d40c)
dma_cap_mask_t cap = d40c->chan.device->cap_mask;
if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
- d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
+ d40c->dma_cfg = dma40_memcpy_conf_log;
d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
} else if (dma_has_cap(DMA_MEMCPY, cap) &&
dma_has_cap(DMA_SLAVE, cap)) {
- d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_phy;
+ d40c->dma_cfg = dma40_memcpy_conf_phy;
} else {
chan_err(d40c, "No memcpy\n");
return -EINVAL;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index a808784..869c571 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
* @dev_len: length of dev_tx and dev_rx
* @dev_tx: mapping between destination event line and io address
* @dev_rx: mapping between source event line and io address
- * @memcpy_conf_phy: default configuration of physical channel memcpy
- * @memcpy_conf_log: default configuration of logical channel memcpy
* @disabled_channels: A vector, ending with -1, that marks physical channels
* that are for different reasons not available for the driver.
* @soft_lli_chans: A vector, that marks physical channels will use LLI by SW
@@ -160,8 +158,6 @@ struct stedma40_platform_data {
u32 dev_len;
const dma_addr_t *dev_tx;
const dma_addr_t *dev_rx;
- struct stedma40_chan_cfg *memcpy_conf_phy;
- struct stedma40_chan_cfg *memcpy_conf_log;
int disabled_channels[STEDMA40_MAX_PHYS];
int *soft_lli_chans;
int num_of_soft_lli_chans;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 02/32] dmaengine: ste_dma40: Move default memcpy configs into the driver
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
There are only two default memcpy configurations used for the DMA40
driver; one for physical memcpy and one for logical memcpy. Instead
of invariably passing the same configurations though platform data,
we're moving them into the driver instead.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/devices-db8500.c | 28 -----------------------
drivers/dma/ste_dma40.c | 32 +++++++++++++++++++++++++--
include/linux/platform_data/dma-ste-dma40.h | 4 ----
3 files changed, 30 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 9b09683..5b1f1f7 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -42,32 +42,6 @@ static struct resource dma40_resources[] = {
}
};
-/* Default configuration for physcial memcpy */
-struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
- .mode = STEDMA40_MODE_PHYSICAL,
- .dir = STEDMA40_MEM_TO_MEM,
-
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .src_info.psize = STEDMA40_PSIZE_PHY_1,
- .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.psize = STEDMA40_PSIZE_PHY_1,
- .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-};
-/* Default configuration for logical memcpy */
-struct stedma40_chan_cfg dma40_memcpy_conf_log = {
- .dir = STEDMA40_MEM_TO_MEM,
-
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .src_info.psize = STEDMA40_PSIZE_LOG_1,
- .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.psize = STEDMA40_PSIZE_LOG_1,
- .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
-};
-
/*
* Mapping between destination event lines and physical device address.
* The event line is tied to a device and therefore the address is constant.
@@ -150,8 +124,6 @@ static struct stedma40_platform_data dma40_plat_data = {
.dev_len = DB8500_DMA_NR_DEV,
.dev_rx = dma40_rx_map,
.dev_tx = dma40_tx_map,
- .memcpy_conf_phy = &dma40_memcpy_conf_phy,
- .memcpy_conf_log = &dma40_memcpy_conf_log,
.disabled_channels = {-1},
};
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 12de79e..3b83dee 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -58,6 +58,34 @@
/* Reserved event lines for memcpy only. */
static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
+/* Default configuration for physcial memcpy */
+struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
+ .mode = STEDMA40_MODE_PHYSICAL,
+ .dir = STEDMA40_MEM_TO_MEM,
+
+ .src_info.data_width = STEDMA40_BYTE_WIDTH,
+ .src_info.psize = STEDMA40_PSIZE_PHY_1,
+ .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+
+ .dst_info.data_width = STEDMA40_BYTE_WIDTH,
+ .dst_info.psize = STEDMA40_PSIZE_PHY_1,
+ .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+};
+
+/* Default configuration for logical memcpy */
+struct stedma40_chan_cfg dma40_memcpy_conf_log = {
+ .mode = STEDMA40_MODE_LOGICAL,
+ .dir = STEDMA40_MEM_TO_MEM,
+
+ .src_info.data_width = STEDMA40_BYTE_WIDTH,
+ .src_info.psize = STEDMA40_PSIZE_LOG_1,
+ .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+
+ .dst_info.data_width = STEDMA40_BYTE_WIDTH,
+ .dst_info.psize = STEDMA40_PSIZE_LOG_1,
+ .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
+};
+
/**
* enum 40_command - The different commands and/or statuses.
*
@@ -2015,13 +2043,13 @@ static int d40_config_memcpy(struct d40_chan *d40c)
dma_cap_mask_t cap = d40c->chan.device->cap_mask;
if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
- d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
+ d40c->dma_cfg = dma40_memcpy_conf_log;
d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
} else if (dma_has_cap(DMA_MEMCPY, cap) &&
dma_has_cap(DMA_SLAVE, cap)) {
- d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_phy;
+ d40c->dma_cfg = dma40_memcpy_conf_phy;
} else {
chan_err(d40c, "No memcpy\n");
return -EINVAL;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index a808784..869c571 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
* @dev_len: length of dev_tx and dev_rx
* @dev_tx: mapping between destination event line and io address
* @dev_rx: mapping between source event line and io address
- * @memcpy_conf_phy: default configuration of physical channel memcpy
- * @memcpy_conf_log: default configuration of logical channel memcpy
* @disabled_channels: A vector, ending with -1, that marks physical channels
* that are for different reasons not available for the driver.
* @soft_lli_chans: A vector, that marks physical channels will use LLI by SW
@@ -160,8 +158,6 @@ struct stedma40_platform_data {
u32 dev_len;
const dma_addr_t *dev_tx;
const dma_addr_t *dev_rx;
- struct stedma40_chan_cfg *memcpy_conf_phy;
- struct stedma40_chan_cfg *memcpy_conf_log;
int disabled_channels[STEDMA40_MAX_PHYS];
int *soft_lli_chans;
int num_of_soft_lli_chans;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 02/32] dmaengine: ste_dma40: Move default memcpy configs into the driver
2013-04-18 10:11 ` Lee Jones
@ 2013-04-22 9:21 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:21 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:11:44AM +0100, Lee Jones wrote:
> There are only two default memcpy configurations used for the DMA40
> driver; one for physical memcpy and one for logical memcpy. Instead
> of invariably passing the same configurations though platform data,
> we're moving them into the driver instead.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> arch/arm/mach-ux500/devices-db8500.c | 28 -----------------------
> drivers/dma/ste_dma40.c | 32 +++++++++++++++++++++++++--
> include/linux/platform_data/dma-ste-dma40.h | 4 ----
> 3 files changed, 30 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> index 9b09683..5b1f1f7 100644
> --- a/arch/arm/mach-ux500/devices-db8500.c
> +++ b/arch/arm/mach-ux500/devices-db8500.c
> @@ -42,32 +42,6 @@ static struct resource dma40_resources[] = {
> }
> };
>
> -/* Default configuration for physcial memcpy */
> -struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
> - .mode = STEDMA40_MODE_PHYSICAL,
> - .dir = STEDMA40_MEM_TO_MEM,
> -
> - .src_info.data_width = STEDMA40_BYTE_WIDTH,
> - .src_info.psize = STEDMA40_PSIZE_PHY_1,
> - .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -
> - .dst_info.data_width = STEDMA40_BYTE_WIDTH,
> - .dst_info.psize = STEDMA40_PSIZE_PHY_1,
> - .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -};
> -/* Default configuration for logical memcpy */
> -struct stedma40_chan_cfg dma40_memcpy_conf_log = {
> - .dir = STEDMA40_MEM_TO_MEM,
> -
> - .src_info.data_width = STEDMA40_BYTE_WIDTH,
> - .src_info.psize = STEDMA40_PSIZE_LOG_1,
> - .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -
> - .dst_info.data_width = STEDMA40_BYTE_WIDTH,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_1,
> - .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -};
> -
> /*
> * Mapping between destination event lines and physical device address.
> * The event line is tied to a device and therefore the address is constant.
> @@ -150,8 +124,6 @@ static struct stedma40_platform_data dma40_plat_data = {
> .dev_len = DB8500_DMA_NR_DEV,
> .dev_rx = dma40_rx_map,
> .dev_tx = dma40_tx_map,
> - .memcpy_conf_phy = &dma40_memcpy_conf_phy,
> - .memcpy_conf_log = &dma40_memcpy_conf_log,
> .disabled_channels = {-1},
> };
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 12de79e..3b83dee 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -58,6 +58,34 @@
> /* Reserved event lines for memcpy only. */
> static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
>
> +/* Default configuration for physcial memcpy */
> +struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
> + .mode = STEDMA40_MODE_PHYSICAL,
> + .dir = STEDMA40_MEM_TO_MEM,
> +
> + .src_info.data_width = STEDMA40_BYTE_WIDTH,
> + .src_info.psize = STEDMA40_PSIZE_PHY_1,
> + .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +
> + .dst_info.data_width = STEDMA40_BYTE_WIDTH,
> + .dst_info.psize = STEDMA40_PSIZE_PHY_1,
> + .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +};
> +
> +/* Default configuration for logical memcpy */
> +struct stedma40_chan_cfg dma40_memcpy_conf_log = {
> + .mode = STEDMA40_MODE_LOGICAL,
> + .dir = STEDMA40_MEM_TO_MEM,
> +
> + .src_info.data_width = STEDMA40_BYTE_WIDTH,
> + .src_info.psize = STEDMA40_PSIZE_LOG_1,
> + .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +
> + .dst_info.data_width = STEDMA40_BYTE_WIDTH,
> + .dst_info.psize = STEDMA40_PSIZE_LOG_1,
> + .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +};
> +
> /**
> * enum 40_command - The different commands and/or statuses.
> *
> @@ -2015,13 +2043,13 @@ static int d40_config_memcpy(struct d40_chan *d40c)
> dma_cap_mask_t cap = d40c->chan.device->cap_mask;
>
> if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
> - d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
> + d40c->dma_cfg = dma40_memcpy_conf_log;
> d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
> d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
>
> } else if (dma_has_cap(DMA_MEMCPY, cap) &&
> dma_has_cap(DMA_SLAVE, cap)) {
> - d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_phy;
> + d40c->dma_cfg = dma40_memcpy_conf_phy;
> } else {
> chan_err(d40c, "No memcpy\n");
> return -EINVAL;
> diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
> index a808784..869c571 100644
> --- a/include/linux/platform_data/dma-ste-dma40.h
> +++ b/include/linux/platform_data/dma-ste-dma40.h
> @@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
> * @dev_len: length of dev_tx and dev_rx
> * @dev_tx: mapping between destination event line and io address
> * @dev_rx: mapping between source event line and io address
> - * @memcpy_conf_phy: default configuration of physical channel memcpy
> - * @memcpy_conf_log: default configuration of logical channel memcpy
> * @disabled_channels: A vector, ending with -1, that marks physical channels
> * that are for different reasons not available for the driver.
> * @soft_lli_chans: A vector, that marks physical channels will use LLI by SW
> @@ -160,8 +158,6 @@ struct stedma40_platform_data {
> u32 dev_len;
> const dma_addr_t *dev_tx;
> const dma_addr_t *dev_rx;
> - struct stedma40_chan_cfg *memcpy_conf_phy;
> - struct stedma40_chan_cfg *memcpy_conf_log;
> int disabled_channels[STEDMA40_MAX_PHYS];
> int *soft_lli_chans;
> int num_of_soft_lli_chans;
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 02/32] dmaengine: ste_dma40: Move default memcpy configs into the driver
@ 2013-04-22 9:21 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:21 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:11:44AM +0100, Lee Jones wrote:
> There are only two default memcpy configurations used for the DMA40
> driver; one for physical memcpy and one for logical memcpy. Instead
> of invariably passing the same configurations though platform data,
> we're moving them into the driver instead.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> arch/arm/mach-ux500/devices-db8500.c | 28 -----------------------
> drivers/dma/ste_dma40.c | 32 +++++++++++++++++++++++++--
> include/linux/platform_data/dma-ste-dma40.h | 4 ----
> 3 files changed, 30 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> index 9b09683..5b1f1f7 100644
> --- a/arch/arm/mach-ux500/devices-db8500.c
> +++ b/arch/arm/mach-ux500/devices-db8500.c
> @@ -42,32 +42,6 @@ static struct resource dma40_resources[] = {
> }
> };
>
> -/* Default configuration for physcial memcpy */
> -struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
> - .mode = STEDMA40_MODE_PHYSICAL,
> - .dir = STEDMA40_MEM_TO_MEM,
> -
> - .src_info.data_width = STEDMA40_BYTE_WIDTH,
> - .src_info.psize = STEDMA40_PSIZE_PHY_1,
> - .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -
> - .dst_info.data_width = STEDMA40_BYTE_WIDTH,
> - .dst_info.psize = STEDMA40_PSIZE_PHY_1,
> - .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -};
> -/* Default configuration for logical memcpy */
> -struct stedma40_chan_cfg dma40_memcpy_conf_log = {
> - .dir = STEDMA40_MEM_TO_MEM,
> -
> - .src_info.data_width = STEDMA40_BYTE_WIDTH,
> - .src_info.psize = STEDMA40_PSIZE_LOG_1,
> - .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -
> - .dst_info.data_width = STEDMA40_BYTE_WIDTH,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_1,
> - .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> -};
> -
> /*
> * Mapping between destination event lines and physical device address.
> * The event line is tied to a device and therefore the address is constant.
> @@ -150,8 +124,6 @@ static struct stedma40_platform_data dma40_plat_data = {
> .dev_len = DB8500_DMA_NR_DEV,
> .dev_rx = dma40_rx_map,
> .dev_tx = dma40_tx_map,
> - .memcpy_conf_phy = &dma40_memcpy_conf_phy,
> - .memcpy_conf_log = &dma40_memcpy_conf_log,
> .disabled_channels = {-1},
> };
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 12de79e..3b83dee 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -58,6 +58,34 @@
> /* Reserved event lines for memcpy only. */
> static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
>
> +/* Default configuration for physcial memcpy */
> +struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
> + .mode = STEDMA40_MODE_PHYSICAL,
> + .dir = STEDMA40_MEM_TO_MEM,
> +
> + .src_info.data_width = STEDMA40_BYTE_WIDTH,
> + .src_info.psize = STEDMA40_PSIZE_PHY_1,
> + .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +
> + .dst_info.data_width = STEDMA40_BYTE_WIDTH,
> + .dst_info.psize = STEDMA40_PSIZE_PHY_1,
> + .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +};
> +
> +/* Default configuration for logical memcpy */
> +struct stedma40_chan_cfg dma40_memcpy_conf_log = {
> + .mode = STEDMA40_MODE_LOGICAL,
> + .dir = STEDMA40_MEM_TO_MEM,
> +
> + .src_info.data_width = STEDMA40_BYTE_WIDTH,
> + .src_info.psize = STEDMA40_PSIZE_LOG_1,
> + .src_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +
> + .dst_info.data_width = STEDMA40_BYTE_WIDTH,
> + .dst_info.psize = STEDMA40_PSIZE_LOG_1,
> + .dst_info.flow_ctrl = STEDMA40_NO_FLOW_CTRL,
> +};
> +
> /**
> * enum 40_command - The different commands and/or statuses.
> *
> @@ -2015,13 +2043,13 @@ static int d40_config_memcpy(struct d40_chan *d40c)
> dma_cap_mask_t cap = d40c->chan.device->cap_mask;
>
> if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
> - d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_log;
> + d40c->dma_cfg = dma40_memcpy_conf_log;
> d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
> d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
>
> } else if (dma_has_cap(DMA_MEMCPY, cap) &&
> dma_has_cap(DMA_SLAVE, cap)) {
> - d40c->dma_cfg = *d40c->base->plat_data->memcpy_conf_phy;
> + d40c->dma_cfg = dma40_memcpy_conf_phy;
> } else {
> chan_err(d40c, "No memcpy\n");
> return -EINVAL;
> diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
> index a808784..869c571 100644
> --- a/include/linux/platform_data/dma-ste-dma40.h
> +++ b/include/linux/platform_data/dma-ste-dma40.h
> @@ -141,8 +141,6 @@ struct stedma40_chan_cfg {
> * @dev_len: length of dev_tx and dev_rx
> * @dev_tx: mapping between destination event line and io address
> * @dev_rx: mapping between source event line and io address
> - * @memcpy_conf_phy: default configuration of physical channel memcpy
> - * @memcpy_conf_log: default configuration of logical channel memcpy
> * @disabled_channels: A vector, ending with -1, that marks physical channels
> * that are for different reasons not available for the driver.
> * @soft_lli_chans: A vector, that marks physical channels will use LLI by SW
> @@ -160,8 +158,6 @@ struct stedma40_platform_data {
> u32 dev_len;
> const dma_addr_t *dev_tx;
> const dma_addr_t *dev_rx;
> - struct stedma40_chan_cfg *memcpy_conf_phy;
> - struct stedma40_chan_cfg *memcpy_conf_log;
> int disabled_channels[STEDMA40_MAX_PHYS];
> int *soft_lli_chans;
> int num_of_soft_lli_chans;
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 02/32] dmaengine: ste_dma40: Move default memcpy configs into the driver
2013-04-18 10:11 ` Lee Jones
@ 2013-04-24 14:44 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-24 14:44 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> There are only two default memcpy configurations used for the DMA40
> driver; one for physical memcpy and one for logical memcpy. Instead
> of invariably passing the same configurations though platform data,
> we're moving them into the driver instead.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Nice!
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 02/32] dmaengine: ste_dma40: Move default memcpy configs into the driver
@ 2013-04-24 14:44 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-24 14:44 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> There are only two default memcpy configurations used for the DMA40
> driver; one for physical memcpy and one for logical memcpy. Instead
> of invariably passing the same configurations though platform data,
> we're moving them into the driver instead.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Nice!
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
The aim is to make the code that little more readable.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..121c46b 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,9 +49,9 @@
#define MAX_LCLA_ALLOC_ATTEMPTS 256
/* Bit markings for allocation map */
-#define D40_ALLOC_FREE (1 << 31)
-#define D40_ALLOC_PHY (1 << 30)
-#define D40_ALLOC_LOG_FREE 0
+#define D40_ALLOC_FREE BIT(31)
+#define D40_ALLOC_PHY BIT(30)
+#define D40_ALLOC_LOG_FREE BIT(0)
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
int dmalen;
u32 max_w = max(data_width1, data_width2);
u32 min_w = min(data_width1, data_width2);
- u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+ u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
if (seg_max > STEDMA40_MAX_SEG_SIZE)
- seg_max -= (1 << max_w);
+ seg_max -= BIT(max_w);
- if (!IS_ALIGNED(size, 1 << max_w))
+ if (!IS_ALIGNED(size, BIT(max_w)))
return -EINVAL;
if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
>> D40_SREG_ELEM_PHY_ECNT_POS;
}
- return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+ return num_elt * BIT(d40c->dma_cfg.dst_info.data_width);
}
static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
}
/* ACK interrupt */
- writel(1 << idx, base->virtbase + il[row].clr);
+ writel(BIT(idx), base->virtbase + il[row].clr);
spin_lock(&d40c->lock);
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
}
if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
- (1 << conf->src_info.data_width) !=
+ BIT(conf->src_info.data_width) !=
d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
- (1 << conf->dst_info.data_width)) {
+ BIT(conf->dst_info.data_width)) {
/*
* The DMAC hardware only supports
* src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_src == D40_ALLOC_FREE)
phy->allocated_src = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_src & (1 << log_event_line))) {
- phy->allocated_src |= 1 << log_event_line;
+ if (!(phy->allocated_src & BIT(log_event_line))) {
+ phy->allocated_src |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_dst == D40_ALLOC_FREE)
phy->allocated_dst = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_dst & (1 << log_event_line))) {
- phy->allocated_dst |= 1 << log_event_line;
+ if (!(phy->allocated_dst & BIT(log_event_line))) {
+ phy->allocated_dst |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
/* Logical channel */
if (is_src) {
- phy->allocated_src &= ~(1 << log_event_line);
+ phy->allocated_src &= ~BIT(log_event_line);
if (phy->allocated_src == D40_ALLOC_LOG_FREE)
phy->allocated_src = D40_ALLOC_FREE;
} else {
- phy->allocated_dst &= ~(1 << log_event_line);
+ phy->allocated_dst &= ~BIT(log_event_line);
if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
phy->allocated_dst = D40_ALLOC_FREE;
}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
u32 rtreg;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
- u32 bit = 1 << event;
+ u32 bit = BIT(event);
u32 prioreg;
struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
The aim is to make the code that little more readable.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..121c46b 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,9 +49,9 @@
#define MAX_LCLA_ALLOC_ATTEMPTS 256
/* Bit markings for allocation map */
-#define D40_ALLOC_FREE (1 << 31)
-#define D40_ALLOC_PHY (1 << 30)
-#define D40_ALLOC_LOG_FREE 0
+#define D40_ALLOC_FREE BIT(31)
+#define D40_ALLOC_PHY BIT(30)
+#define D40_ALLOC_LOG_FREE BIT(0)
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
int dmalen;
u32 max_w = max(data_width1, data_width2);
u32 min_w = min(data_width1, data_width2);
- u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+ u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
if (seg_max > STEDMA40_MAX_SEG_SIZE)
- seg_max -= (1 << max_w);
+ seg_max -= BIT(max_w);
- if (!IS_ALIGNED(size, 1 << max_w))
+ if (!IS_ALIGNED(size, BIT(max_w)))
return -EINVAL;
if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
>> D40_SREG_ELEM_PHY_ECNT_POS;
}
- return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+ return num_elt * BIT(d40c->dma_cfg.dst_info.data_width);
}
static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
}
/* ACK interrupt */
- writel(1 << idx, base->virtbase + il[row].clr);
+ writel(BIT(idx), base->virtbase + il[row].clr);
spin_lock(&d40c->lock);
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
}
if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
- (1 << conf->src_info.data_width) !=
+ BIT(conf->src_info.data_width) !=
d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
- (1 << conf->dst_info.data_width)) {
+ BIT(conf->dst_info.data_width)) {
/*
* The DMAC hardware only supports
* src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_src == D40_ALLOC_FREE)
phy->allocated_src = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_src & (1 << log_event_line))) {
- phy->allocated_src |= 1 << log_event_line;
+ if (!(phy->allocated_src & BIT(log_event_line))) {
+ phy->allocated_src |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_dst == D40_ALLOC_FREE)
phy->allocated_dst = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_dst & (1 << log_event_line))) {
- phy->allocated_dst |= 1 << log_event_line;
+ if (!(phy->allocated_dst & BIT(log_event_line))) {
+ phy->allocated_dst |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
/* Logical channel */
if (is_src) {
- phy->allocated_src &= ~(1 << log_event_line);
+ phy->allocated_src &= ~BIT(log_event_line);
if (phy->allocated_src == D40_ALLOC_LOG_FREE)
phy->allocated_src = D40_ALLOC_FREE;
} else {
- phy->allocated_dst &= ~(1 << log_event_line);
+ phy->allocated_dst &= ~BIT(log_event_line);
if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
phy->allocated_dst = D40_ALLOC_FREE;
}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
u32 rtreg;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
- u32 bit = 1 << event;
+ u32 bit = BIT(event);
u32 prioreg;
struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:43 ` Russell King - ARM Linux
-1 siblings, 0 replies; 337+ messages in thread
From: Russell King - ARM Linux @ 2013-04-18 10:43 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Rabin Vincent, linus.walleij,
arnd, Vinod Koul, Per Forlin, Dan Williams
On Thu, Apr 18, 2013 at 11:11:45AM +0100, Lee Jones wrote:
> The aim is to make the code that little more readable.
Maybe we should also invent the MULT() macro too, because a * b is just
too ugly as well? Maybe ADD(), SUB() and DIV() macros as well... Think
of all those extra parens you could use! :)
> @@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
> >> D40_SREG_ELEM_PHY_ECNT_POS;
> }
>
> - return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
> + return num_elt * BIT(d40c->dma_cfg.dst_info.data_width);
This should be:
return num_elt << d40c->dma_cfg.dst_info.data_width;
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-18 10:43 ` Russell King - ARM Linux
0 siblings, 0 replies; 337+ messages in thread
From: Russell King - ARM Linux @ 2013-04-18 10:43 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:11:45AM +0100, Lee Jones wrote:
> The aim is to make the code that little more readable.
Maybe we should also invent the MULT() macro too, because a * b is just
too ugly as well? Maybe ADD(), SUB() and DIV() macros as well... Think
of all those extra parens you could use! :)
> @@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
> >> D40_SREG_ELEM_PHY_ECNT_POS;
> }
>
> - return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
> + return num_elt * BIT(d40c->dma_cfg.dst_info.data_width);
This should be:
return num_elt << d40c->dma_cfg.dst_info.data_width;
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-18 10:43 ` Russell King - ARM Linux
@ 2013-04-18 11:00 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 11:00 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-arm-kernel, linux-kernel, Rabin Vincent, linus.walleij,
arnd, Vinod Koul, Per Forlin, Dan Williams
On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> On Thu, Apr 18, 2013 at 11:11:45AM +0100, Lee Jones wrote:
> > The aim is to make the code that little more readable.
>
> Maybe we should also invent the MULT() macro too, because a * b is just
> too ugly as well? Maybe ADD(), SUB() and DIV() macros as well... Think
> of all those extra parens you could use! :)
Very amusing. :)
I just happen to like this macro.
It's more for tidiness than readability to be honest, but still.
> > @@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
> > >> D40_SREG_ELEM_PHY_ECNT_POS;
> > }
> >
> > - return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
> > + return num_elt * BIT(d40c->dma_cfg.dst_info.data_width);
>
> This should be:
> return num_elt << d40c->dma_cfg.dst_info.data_width;
Thanks. I'll fixup.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-18 11:00 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 11:00 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> On Thu, Apr 18, 2013 at 11:11:45AM +0100, Lee Jones wrote:
> > The aim is to make the code that little more readable.
>
> Maybe we should also invent the MULT() macro too, because a * b is just
> too ugly as well? Maybe ADD(), SUB() and DIV() macros as well... Think
> of all those extra parens you could use! :)
Very amusing. :)
I just happen to like this macro.
It's more for tidiness than readability to be honest, but still.
> > @@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
> > >> D40_SREG_ELEM_PHY_ECNT_POS;
> > }
> >
> > - return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
> > + return num_elt * BIT(d40c->dma_cfg.dst_info.data_width);
>
> This should be:
> return num_elt << d40c->dma_cfg.dst_info.data_width;
Thanks. I'll fixup.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 12:16 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 12:16 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
The aim is to make the code that little more readable.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..ddf5ff1 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,9 +49,9 @@
#define MAX_LCLA_ALLOC_ATTEMPTS 256
/* Bit markings for allocation map */
-#define D40_ALLOC_FREE (1 << 31)
-#define D40_ALLOC_PHY (1 << 30)
-#define D40_ALLOC_LOG_FREE 0
+#define D40_ALLOC_FREE BIT(31)
+#define D40_ALLOC_PHY BIT(30)
+#define D40_ALLOC_LOG_FREE BIT(0)
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
int dmalen;
u32 max_w = max(data_width1, data_width2);
u32 min_w = min(data_width1, data_width2);
- u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+ u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
if (seg_max > STEDMA40_MAX_SEG_SIZE)
- seg_max -= (1 << max_w);
+ seg_max -= BIT(max_w);
- if (!IS_ALIGNED(size, 1 << max_w))
+ if (!IS_ALIGNED(size, BIT(max_w)))
return -EINVAL;
if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
>> D40_SREG_ELEM_PHY_ECNT_POS;
}
- return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+ return num_elt << d40c->dma_cfg.dst_info.data_width;
}
static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
}
/* ACK interrupt */
- writel(1 << idx, base->virtbase + il[row].clr);
+ writel(BIT(idx), base->virtbase + il[row].clr);
spin_lock(&d40c->lock);
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
}
if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
- (1 << conf->src_info.data_width) !=
+ BIT(conf->src_info.data_width) !=
d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
- (1 << conf->dst_info.data_width)) {
+ BIT(conf->dst_info.data_width)) {
/*
* The DMAC hardware only supports
* src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_src == D40_ALLOC_FREE)
phy->allocated_src = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_src & (1 << log_event_line))) {
- phy->allocated_src |= 1 << log_event_line;
+ if (!(phy->allocated_src & BIT(log_event_line))) {
+ phy->allocated_src |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_dst == D40_ALLOC_FREE)
phy->allocated_dst = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_dst & (1 << log_event_line))) {
- phy->allocated_dst |= 1 << log_event_line;
+ if (!(phy->allocated_dst & BIT(log_event_line))) {
+ phy->allocated_dst |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
/* Logical channel */
if (is_src) {
- phy->allocated_src &= ~(1 << log_event_line);
+ phy->allocated_src &= ~BIT(log_event_line);
if (phy->allocated_src == D40_ALLOC_LOG_FREE)
phy->allocated_src = D40_ALLOC_FREE;
} else {
- phy->allocated_dst &= ~(1 << log_event_line);
+ phy->allocated_dst &= ~BIT(log_event_line);
if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
phy->allocated_dst = D40_ALLOC_FREE;
}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
u32 rtreg;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
- u32 bit = 1 << event;
+ u32 bit = BIT(event);
u32 prioreg;
struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-18 12:16 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 12:16 UTC (permalink / raw)
To: linux-arm-kernel
The aim is to make the code that little more readable.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..ddf5ff1 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,9 +49,9 @@
#define MAX_LCLA_ALLOC_ATTEMPTS 256
/* Bit markings for allocation map */
-#define D40_ALLOC_FREE (1 << 31)
-#define D40_ALLOC_PHY (1 << 30)
-#define D40_ALLOC_LOG_FREE 0
+#define D40_ALLOC_FREE BIT(31)
+#define D40_ALLOC_PHY BIT(30)
+#define D40_ALLOC_LOG_FREE BIT(0)
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
int dmalen;
u32 max_w = max(data_width1, data_width2);
u32 min_w = min(data_width1, data_width2);
- u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+ u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
if (seg_max > STEDMA40_MAX_SEG_SIZE)
- seg_max -= (1 << max_w);
+ seg_max -= BIT(max_w);
- if (!IS_ALIGNED(size, 1 << max_w))
+ if (!IS_ALIGNED(size, BIT(max_w)))
return -EINVAL;
if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
>> D40_SREG_ELEM_PHY_ECNT_POS;
}
- return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+ return num_elt << d40c->dma_cfg.dst_info.data_width;
}
static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
}
/* ACK interrupt */
- writel(1 << idx, base->virtbase + il[row].clr);
+ writel(BIT(idx), base->virtbase + il[row].clr);
spin_lock(&d40c->lock);
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
}
if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
- (1 << conf->src_info.data_width) !=
+ BIT(conf->src_info.data_width) !=
d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
- (1 << conf->dst_info.data_width)) {
+ BIT(conf->dst_info.data_width)) {
/*
* The DMAC hardware only supports
* src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_src == D40_ALLOC_FREE)
phy->allocated_src = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_src & (1 << log_event_line))) {
- phy->allocated_src |= 1 << log_event_line;
+ if (!(phy->allocated_src & BIT(log_event_line))) {
+ phy->allocated_src |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_dst == D40_ALLOC_FREE)
phy->allocated_dst = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_dst & (1 << log_event_line))) {
- phy->allocated_dst |= 1 << log_event_line;
+ if (!(phy->allocated_dst & BIT(log_event_line))) {
+ phy->allocated_dst |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
/* Logical channel */
if (is_src) {
- phy->allocated_src &= ~(1 << log_event_line);
+ phy->allocated_src &= ~BIT(log_event_line);
if (phy->allocated_src == D40_ALLOC_LOG_FREE)
phy->allocated_src = D40_ALLOC_FREE;
} else {
- phy->allocated_dst &= ~(1 << log_event_line);
+ phy->allocated_dst &= ~BIT(log_event_line);
if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
phy->allocated_dst = D40_ALLOC_FREE;
}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
u32 rtreg;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
- u32 bit = 1 << event;
+ u32 bit = BIT(event);
u32 prioreg;
struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-18 12:16 ` Lee Jones
@ 2013-04-22 10:13 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:13 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 01:16:37PM +0100, Lee Jones wrote:
> The aim is to make the code that little more readable.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 3b83dee..ddf5ff1 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -49,9 +49,9 @@
> #define MAX_LCLA_ALLOC_ATTEMPTS 256
>
> /* Bit markings for allocation map */
> -#define D40_ALLOC_FREE (1 << 31)
> -#define D40_ALLOC_PHY (1 << 30)
> -#define D40_ALLOC_LOG_FREE 0
> +#define D40_ALLOC_FREE BIT(31)
> +#define D40_ALLOC_PHY BIT(30)
> +#define D40_ALLOC_LOG_FREE BIT(0)
>
> #define MAX(a, b) (((a) < (b)) ? (b) : (a))
>
> @@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
> int dmalen;
> u32 max_w = max(data_width1, data_width2);
> u32 min_w = min(data_width1, data_width2);
> - u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
> + u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
>
> if (seg_max > STEDMA40_MAX_SEG_SIZE)
> - seg_max -= (1 << max_w);
> + seg_max -= BIT(max_w);
>
> - if (!IS_ALIGNED(size, 1 << max_w))
> + if (!IS_ALIGNED(size, BIT(max_w)))
> return -EINVAL;
>
> if (size <= seg_max)
> @@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
> >> D40_SREG_ELEM_PHY_ECNT_POS;
> }
>
> - return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
> + return num_elt << d40c->dma_cfg.dst_info.data_width;
> }
>
> static bool d40_tx_is_linked(struct d40_chan *d40c)
> @@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
> }
>
> /* ACK interrupt */
> - writel(1 << idx, base->virtbase + il[row].clr);
> + writel(BIT(idx), base->virtbase + il[row].clr);
>
> spin_lock(&d40c->lock);
>
> @@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
> }
>
> if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
> - (1 << conf->src_info.data_width) !=
> + BIT(conf->src_info.data_width) !=
> d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
> - (1 << conf->dst_info.data_width)) {
> + BIT(conf->dst_info.data_width)) {
> /*
> * The DMAC hardware only supports
> * src (burst x width) == dst (burst x width)
> @@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
> if (phy->allocated_src == D40_ALLOC_FREE)
> phy->allocated_src = D40_ALLOC_LOG_FREE;
>
> - if (!(phy->allocated_src & (1 << log_event_line))) {
> - phy->allocated_src |= 1 << log_event_line;
> + if (!(phy->allocated_src & BIT(log_event_line))) {
> + phy->allocated_src |= BIT(log_event_line);
> goto found;
> } else
> goto not_found;
> @@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
> if (phy->allocated_dst == D40_ALLOC_FREE)
> phy->allocated_dst = D40_ALLOC_LOG_FREE;
>
> - if (!(phy->allocated_dst & (1 << log_event_line))) {
> - phy->allocated_dst |= 1 << log_event_line;
> + if (!(phy->allocated_dst & BIT(log_event_line))) {
> + phy->allocated_dst |= BIT(log_event_line);
> goto found;
> } else
> goto not_found;
> @@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
>
> /* Logical channel */
> if (is_src) {
> - phy->allocated_src &= ~(1 << log_event_line);
> + phy->allocated_src &= ~BIT(log_event_line);
> if (phy->allocated_src == D40_ALLOC_LOG_FREE)
> phy->allocated_src = D40_ALLOC_FREE;
> } else {
> - phy->allocated_dst &= ~(1 << log_event_line);
> + phy->allocated_dst &= ~BIT(log_event_line);
> if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
> phy->allocated_dst = D40_ALLOC_FREE;
> }
> @@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
> u32 rtreg;
> u32 event = D40_TYPE_TO_EVENT(dev_type);
> u32 group = D40_TYPE_TO_GROUP(dev_type);
> - u32 bit = 1 << event;
> + u32 bit = BIT(event);
> u32 prioreg;
> struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-22 10:13 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:13 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 01:16:37PM +0100, Lee Jones wrote:
> The aim is to make the code that little more readable.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 3b83dee..ddf5ff1 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -49,9 +49,9 @@
> #define MAX_LCLA_ALLOC_ATTEMPTS 256
>
> /* Bit markings for allocation map */
> -#define D40_ALLOC_FREE (1 << 31)
> -#define D40_ALLOC_PHY (1 << 30)
> -#define D40_ALLOC_LOG_FREE 0
> +#define D40_ALLOC_FREE BIT(31)
> +#define D40_ALLOC_PHY BIT(30)
> +#define D40_ALLOC_LOG_FREE BIT(0)
>
> #define MAX(a, b) (((a) < (b)) ? (b) : (a))
>
> @@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
> int dmalen;
> u32 max_w = max(data_width1, data_width2);
> u32 min_w = min(data_width1, data_width2);
> - u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
> + u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
>
> if (seg_max > STEDMA40_MAX_SEG_SIZE)
> - seg_max -= (1 << max_w);
> + seg_max -= BIT(max_w);
>
> - if (!IS_ALIGNED(size, 1 << max_w))
> + if (!IS_ALIGNED(size, BIT(max_w)))
> return -EINVAL;
>
> if (size <= seg_max)
> @@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
> >> D40_SREG_ELEM_PHY_ECNT_POS;
> }
>
> - return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
> + return num_elt << d40c->dma_cfg.dst_info.data_width;
> }
>
> static bool d40_tx_is_linked(struct d40_chan *d40c)
> @@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
> }
>
> /* ACK interrupt */
> - writel(1 << idx, base->virtbase + il[row].clr);
> + writel(BIT(idx), base->virtbase + il[row].clr);
>
> spin_lock(&d40c->lock);
>
> @@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
> }
>
> if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
> - (1 << conf->src_info.data_width) !=
> + BIT(conf->src_info.data_width) !=
> d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
> - (1 << conf->dst_info.data_width)) {
> + BIT(conf->dst_info.data_width)) {
> /*
> * The DMAC hardware only supports
> * src (burst x width) == dst (burst x width)
> @@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
> if (phy->allocated_src == D40_ALLOC_FREE)
> phy->allocated_src = D40_ALLOC_LOG_FREE;
>
> - if (!(phy->allocated_src & (1 << log_event_line))) {
> - phy->allocated_src |= 1 << log_event_line;
> + if (!(phy->allocated_src & BIT(log_event_line))) {
> + phy->allocated_src |= BIT(log_event_line);
> goto found;
> } else
> goto not_found;
> @@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
> if (phy->allocated_dst == D40_ALLOC_FREE)
> phy->allocated_dst = D40_ALLOC_LOG_FREE;
>
> - if (!(phy->allocated_dst & (1 << log_event_line))) {
> - phy->allocated_dst |= 1 << log_event_line;
> + if (!(phy->allocated_dst & BIT(log_event_line))) {
> + phy->allocated_dst |= BIT(log_event_line);
> goto found;
> } else
> goto not_found;
> @@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
>
> /* Logical channel */
> if (is_src) {
> - phy->allocated_src &= ~(1 << log_event_line);
> + phy->allocated_src &= ~BIT(log_event_line);
> if (phy->allocated_src == D40_ALLOC_LOG_FREE)
> phy->allocated_src = D40_ALLOC_FREE;
> } else {
> - phy->allocated_dst &= ~(1 << log_event_line);
> + phy->allocated_dst &= ~BIT(log_event_line);
> if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
> phy->allocated_dst = D40_ALLOC_FREE;
> }
> @@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
> u32 rtreg;
> u32 event = D40_TYPE_TO_EVENT(dev_type);
> u32 group = D40_TYPE_TO_GROUP(dev_type);
> - u32 bit = 1 << event;
> + u32 bit = BIT(event);
> u32 prioreg;
> struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-18 12:16 ` Lee Jones
@ 2013-04-24 14:54 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-24 14:54 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 2:16 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The aim is to make the code that little more readable.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 3b83dee..ddf5ff1 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -49,9 +49,9 @@
> #define MAX_LCLA_ALLOC_ATTEMPTS 256
>
> /* Bit markings for allocation map */
> -#define D40_ALLOC_FREE (1 << 31)
> -#define D40_ALLOC_PHY (1 << 30)
> -#define D40_ALLOC_LOG_FREE 0
> +#define D40_ALLOC_FREE BIT(31)
> +#define D40_ALLOC_PHY BIT(30)
> +#define D40_ALLOC_LOG_FREE BIT(0)
No. 0 != BIT(0)
Please fix this...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-24 14:54 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-24 14:54 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 2:16 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The aim is to make the code that little more readable.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 3b83dee..ddf5ff1 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -49,9 +49,9 @@
> #define MAX_LCLA_ALLOC_ATTEMPTS 256
>
> /* Bit markings for allocation map */
> -#define D40_ALLOC_FREE (1 << 31)
> -#define D40_ALLOC_PHY (1 << 30)
> -#define D40_ALLOC_LOG_FREE 0
> +#define D40_ALLOC_FREE BIT(31)
> +#define D40_ALLOC_PHY BIT(30)
> +#define D40_ALLOC_LOG_FREE BIT(0)
No. 0 != BIT(0)
Please fix this...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-24 14:54 ` Linus Walleij
@ 2013-04-24 15:08 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 15:08 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Wed, 24 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 2:16 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > The aim is to make the code that little more readable.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index 3b83dee..ddf5ff1 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -49,9 +49,9 @@
> > #define MAX_LCLA_ALLOC_ATTEMPTS 256
> >
> > /* Bit markings for allocation map */
> > -#define D40_ALLOC_FREE (1 << 31)
> > -#define D40_ALLOC_PHY (1 << 30)
> > -#define D40_ALLOC_LOG_FREE 0
> > +#define D40_ALLOC_FREE BIT(31)
> > +#define D40_ALLOC_PHY BIT(30)
> > +#define D40_ALLOC_LOG_FREE BIT(0)
>
> No. 0 != BIT(0)
>
> Please fix this...
Good spot.
I've already fixed this though.
I'll send it as a v3 now.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 03/32 v2] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-24 15:08 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 15:08 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 24 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 2:16 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > The aim is to make the code that little more readable.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index 3b83dee..ddf5ff1 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -49,9 +49,9 @@
> > #define MAX_LCLA_ALLOC_ATTEMPTS 256
> >
> > /* Bit markings for allocation map */
> > -#define D40_ALLOC_FREE (1 << 31)
> > -#define D40_ALLOC_PHY (1 << 30)
> > -#define D40_ALLOC_LOG_FREE 0
> > +#define D40_ALLOC_FREE BIT(31)
> > +#define D40_ALLOC_PHY BIT(30)
> > +#define D40_ALLOC_LOG_FREE BIT(0)
>
> No. 0 != BIT(0)
>
> Please fix this...
Good spot.
I've already fixed this though.
I'll send it as a v3 now.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-18 10:11 ` Lee Jones
@ 2013-04-24 15:09 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 15:09 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
The aim is to make the code that little more readable.
Acked-by: Vinod Koul <vnod.koul@intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..b3a82bf 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,8 +49,8 @@
#define MAX_LCLA_ALLOC_ATTEMPTS 256
/* Bit markings for allocation map */
-#define D40_ALLOC_FREE (1 << 31)
-#define D40_ALLOC_PHY (1 << 30)
+#define D40_ALLOC_FREE BIT(31)
+#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE 0
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
int dmalen;
u32 max_w = max(data_width1, data_width2);
u32 min_w = min(data_width1, data_width2);
- u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+ u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
if (seg_max > STEDMA40_MAX_SEG_SIZE)
- seg_max -= (1 << max_w);
+ seg_max -= BIT(max_w);
- if (!IS_ALIGNED(size, 1 << max_w))
+ if (!IS_ALIGNED(size, BIT(max_w)))
return -EINVAL;
if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
>> D40_SREG_ELEM_PHY_ECNT_POS;
}
- return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+ return num_elt << d40c->dma_cfg.dst_info.data_width;
}
static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
}
/* ACK interrupt */
- writel(1 << idx, base->virtbase + il[row].clr);
+ writel(BIT(idx), base->virtbase + il[row].clr);
spin_lock(&d40c->lock);
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
}
if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
- (1 << conf->src_info.data_width) !=
+ BIT(conf->src_info.data_width) !=
d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
- (1 << conf->dst_info.data_width)) {
+ BIT(conf->dst_info.data_width)) {
/*
* The DMAC hardware only supports
* src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_src == D40_ALLOC_FREE)
phy->allocated_src = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_src & (1 << log_event_line))) {
- phy->allocated_src |= 1 << log_event_line;
+ if (!(phy->allocated_src & BIT(log_event_line))) {
+ phy->allocated_src |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_dst == D40_ALLOC_FREE)
phy->allocated_dst = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_dst & (1 << log_event_line))) {
- phy->allocated_dst |= 1 << log_event_line;
+ if (!(phy->allocated_dst & BIT(log_event_line))) {
+ phy->allocated_dst |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
/* Logical channel */
if (is_src) {
- phy->allocated_src &= ~(1 << log_event_line);
+ phy->allocated_src &= ~BIT(log_event_line);
if (phy->allocated_src == D40_ALLOC_LOG_FREE)
phy->allocated_src = D40_ALLOC_FREE;
} else {
- phy->allocated_dst &= ~(1 << log_event_line);
+ phy->allocated_dst &= ~BIT(log_event_line);
if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
phy->allocated_dst = D40_ALLOC_FREE;
}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
u32 rtreg;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
- u32 bit = 1 << event;
+ u32 bit = BIT(event);
u32 prioreg;
struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 03/32] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-24 15:09 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 15:09 UTC (permalink / raw)
To: linux-arm-kernel
dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
The aim is to make the code that little more readable.
Acked-by: Vinod Koul <vnod.koul@intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..b3a82bf 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,8 +49,8 @@
#define MAX_LCLA_ALLOC_ATTEMPTS 256
/* Bit markings for allocation map */
-#define D40_ALLOC_FREE (1 << 31)
-#define D40_ALLOC_PHY (1 << 30)
+#define D40_ALLOC_FREE BIT(31)
+#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE 0
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
int dmalen;
u32 max_w = max(data_width1, data_width2);
u32 min_w = min(data_width1, data_width2);
- u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+ u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
if (seg_max > STEDMA40_MAX_SEG_SIZE)
- seg_max -= (1 << max_w);
+ seg_max -= BIT(max_w);
- if (!IS_ALIGNED(size, 1 << max_w))
+ if (!IS_ALIGNED(size, BIT(max_w)))
return -EINVAL;
if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
>> D40_SREG_ELEM_PHY_ECNT_POS;
}
- return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+ return num_elt << d40c->dma_cfg.dst_info.data_width;
}
static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
}
/* ACK interrupt */
- writel(1 << idx, base->virtbase + il[row].clr);
+ writel(BIT(idx), base->virtbase + il[row].clr);
spin_lock(&d40c->lock);
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
}
if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
- (1 << conf->src_info.data_width) !=
+ BIT(conf->src_info.data_width) !=
d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
- (1 << conf->dst_info.data_width)) {
+ BIT(conf->dst_info.data_width)) {
/*
* The DMAC hardware only supports
* src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_src == D40_ALLOC_FREE)
phy->allocated_src = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_src & (1 << log_event_line))) {
- phy->allocated_src |= 1 << log_event_line;
+ if (!(phy->allocated_src & BIT(log_event_line))) {
+ phy->allocated_src |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_dst == D40_ALLOC_FREE)
phy->allocated_dst = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_dst & (1 << log_event_line))) {
- phy->allocated_dst |= 1 << log_event_line;
+ if (!(phy->allocated_dst & BIT(log_event_line))) {
+ phy->allocated_dst |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
/* Logical channel */
if (is_src) {
- phy->allocated_src &= ~(1 << log_event_line);
+ phy->allocated_src &= ~BIT(log_event_line);
if (phy->allocated_src == D40_ALLOC_LOG_FREE)
phy->allocated_src = D40_ALLOC_FREE;
} else {
- phy->allocated_dst &= ~(1 << log_event_line);
+ phy->allocated_dst &= ~BIT(log_event_line);
if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
phy->allocated_dst = D40_ALLOC_FREE;
}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
u32 rtreg;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
- u32 bit = 1 << event;
+ u32 bit = BIT(event);
u32 prioreg;
struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
^ permalink raw reply related [flat|nested] 337+ messages in thread
* [PATCH 03/32 v3] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-18 10:11 ` Lee Jones
@ 2013-04-24 15:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 15:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
The aim is to make the code that little more readable.
Acked-by: Vinod Koul <vnod.koul@intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..b3a82bf 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,8 +49,8 @@
#define MAX_LCLA_ALLOC_ATTEMPTS 256
/* Bit markings for allocation map */
-#define D40_ALLOC_FREE (1 << 31)
-#define D40_ALLOC_PHY (1 << 30)
+#define D40_ALLOC_FREE BIT(31)
+#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE 0
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
int dmalen;
u32 max_w = max(data_width1, data_width2);
u32 min_w = min(data_width1, data_width2);
- u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+ u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
if (seg_max > STEDMA40_MAX_SEG_SIZE)
- seg_max -= (1 << max_w);
+ seg_max -= BIT(max_w);
- if (!IS_ALIGNED(size, 1 << max_w))
+ if (!IS_ALIGNED(size, BIT(max_w)))
return -EINVAL;
if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
>> D40_SREG_ELEM_PHY_ECNT_POS;
}
- return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+ return num_elt << d40c->dma_cfg.dst_info.data_width;
}
static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
}
/* ACK interrupt */
- writel(1 << idx, base->virtbase + il[row].clr);
+ writel(BIT(idx), base->virtbase + il[row].clr);
spin_lock(&d40c->lock);
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
}
if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
- (1 << conf->src_info.data_width) !=
+ BIT(conf->src_info.data_width) !=
d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
- (1 << conf->dst_info.data_width)) {
+ BIT(conf->dst_info.data_width)) {
/*
* The DMAC hardware only supports
* src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_src == D40_ALLOC_FREE)
phy->allocated_src = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_src & (1 << log_event_line))) {
- phy->allocated_src |= 1 << log_event_line;
+ if (!(phy->allocated_src & BIT(log_event_line))) {
+ phy->allocated_src |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_dst == D40_ALLOC_FREE)
phy->allocated_dst = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_dst & (1 << log_event_line))) {
- phy->allocated_dst |= 1 << log_event_line;
+ if (!(phy->allocated_dst & BIT(log_event_line))) {
+ phy->allocated_dst |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
/* Logical channel */
if (is_src) {
- phy->allocated_src &= ~(1 << log_event_line);
+ phy->allocated_src &= ~BIT(log_event_line);
if (phy->allocated_src == D40_ALLOC_LOG_FREE)
phy->allocated_src = D40_ALLOC_FREE;
} else {
- phy->allocated_dst &= ~(1 << log_event_line);
+ phy->allocated_dst &= ~BIT(log_event_line);
if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
phy->allocated_dst = D40_ALLOC_FREE;
}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
u32 rtreg;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
- u32 bit = 1 << event;
+ u32 bit = BIT(event);
u32 prioreg;
struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 03/32 v3] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-24 15:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 15:11 UTC (permalink / raw)
To: linux-arm-kernel
The aim is to make the code that little more readable.
Acked-by: Vinod Koul <vnod.koul@intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 3b83dee..b3a82bf 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -49,8 +49,8 @@
#define MAX_LCLA_ALLOC_ATTEMPTS 256
/* Bit markings for allocation map */
-#define D40_ALLOC_FREE (1 << 31)
-#define D40_ALLOC_PHY (1 << 30)
+#define D40_ALLOC_FREE BIT(31)
+#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE 0
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
@@ -993,12 +993,12 @@ static int d40_size_2_dmalen(int size, u32 data_width1, u32 data_width2)
int dmalen;
u32 max_w = max(data_width1, data_width2);
u32 min_w = min(data_width1, data_width2);
- u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, 1 << max_w);
+ u32 seg_max = ALIGN(STEDMA40_MAX_SEG_SIZE << min_w, BIT(max_w));
if (seg_max > STEDMA40_MAX_SEG_SIZE)
- seg_max -= (1 << max_w);
+ seg_max -= BIT(max_w);
- if (!IS_ALIGNED(size, 1 << max_w))
+ if (!IS_ALIGNED(size, BIT(max_w)))
return -EINVAL;
if (size <= seg_max)
@@ -1448,7 +1448,7 @@ static u32 d40_residue(struct d40_chan *d40c)
>> D40_SREG_ELEM_PHY_ECNT_POS;
}
- return num_elt * (1 << d40c->dma_cfg.dst_info.data_width);
+ return num_elt << d40c->dma_cfg.dst_info.data_width;
}
static bool d40_tx_is_linked(struct d40_chan *d40c)
@@ -1722,7 +1722,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
}
/* ACK interrupt */
- writel(1 << idx, base->virtbase + il[row].clr);
+ writel(BIT(idx), base->virtbase + il[row].clr);
spin_lock(&d40c->lock);
@@ -1804,9 +1804,9 @@ static int d40_validate_conf(struct d40_chan *d40c,
}
if (d40_psize_2_burst_size(is_log, conf->src_info.psize) *
- (1 << conf->src_info.data_width) !=
+ BIT(conf->src_info.data_width) !=
d40_psize_2_burst_size(is_log, conf->dst_info.psize) *
- (1 << conf->dst_info.data_width)) {
+ BIT(conf->dst_info.data_width)) {
/*
* The DMAC hardware only supports
* src (burst x width) == dst (burst x width)
@@ -1848,8 +1848,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_src == D40_ALLOC_FREE)
phy->allocated_src = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_src & (1 << log_event_line))) {
- phy->allocated_src |= 1 << log_event_line;
+ if (!(phy->allocated_src & BIT(log_event_line))) {
+ phy->allocated_src |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1860,8 +1860,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_dst == D40_ALLOC_FREE)
phy->allocated_dst = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_dst & (1 << log_event_line))) {
- phy->allocated_dst |= 1 << log_event_line;
+ if (!(phy->allocated_dst & BIT(log_event_line))) {
+ phy->allocated_dst |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1891,11 +1891,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
/* Logical channel */
if (is_src) {
- phy->allocated_src &= ~(1 << log_event_line);
+ phy->allocated_src &= ~BIT(log_event_line);
if (phy->allocated_src == D40_ALLOC_LOG_FREE)
phy->allocated_src = D40_ALLOC_FREE;
} else {
- phy->allocated_dst &= ~(1 << log_event_line);
+ phy->allocated_dst &= ~BIT(log_event_line);
if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
phy->allocated_dst = D40_ALLOC_FREE;
}
@@ -2394,7 +2394,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
u32 rtreg;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
- u32 bit = 1 << event;
+ u32 bit = BIT(event);
u32 prioreg;
struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 03/32 v3] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-24 15:11 ` Lee Jones
@ 2013-04-24 19:24 ` Rabin Vincent
-1 siblings, 0 replies; 337+ messages in thread
From: Rabin Vincent @ 2013-04-24 19:24 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin
2013/4/24 Lee Jones <lee.jones@linaro.org>:
> The aim is to make the code that little more readable.
>
> Acked-by: Vinod Koul <vnod.koul@intel.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Please pay closer attention to the semantics of each usage instead of
just replacing all x left shifts of 1 by BIT(x) for "readability".
> if (seg_max > STEDMA40_MAX_SEG_SIZE)
> - seg_max -= (1 << max_w);
> + seg_max -= BIT(max_w);
>
> - if (!IS_ALIGNED(size, 1 << max_w))
> + if (!IS_ALIGNED(size, BIT(max_w)))
> return -EINVAL;
Here and in all other places where the values are from cfg->data_width,
the semantic purpose of the shift is not for setting a particular bit
but instead for converting the data_width field into the data width
value in bytes. You should not change these usages to BIT().
It would be instead better to just make the cfg->data_width as the
number of bytes and convert them to the appropriate hardware field
values when the descriptors are constructed. That of course should be
in another patch.
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 03/32 v3] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-24 19:24 ` Rabin Vincent
0 siblings, 0 replies; 337+ messages in thread
From: Rabin Vincent @ 2013-04-24 19:24 UTC (permalink / raw)
To: linux-arm-kernel
2013/4/24 Lee Jones <lee.jones@linaro.org>:
> The aim is to make the code that little more readable.
>
> Acked-by: Vinod Koul <vnod.koul@intel.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Please pay closer attention to the semantics of each usage instead of
just replacing all x left shifts of 1 by BIT(x) for "readability".
> if (seg_max > STEDMA40_MAX_SEG_SIZE)
> - seg_max -= (1 << max_w);
> + seg_max -= BIT(max_w);
>
> - if (!IS_ALIGNED(size, 1 << max_w))
> + if (!IS_ALIGNED(size, BIT(max_w)))
> return -EINVAL;
Here and in all other places where the values are from cfg->data_width,
the semantic purpose of the shift is not for setting a particular bit
but instead for converting the data_width field into the data width
value in bytes. You should not change these usages to BIT().
It would be instead better to just make the cfg->data_width as the
number of bytes and convert them to the appropriate hardware field
values when the descriptors are constructed. That of course should be
in another patch.
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 03/32 v3] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-24 19:24 ` Rabin Vincent
@ 2013-04-25 8:13 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 8:13 UTC (permalink / raw)
To: Rabin Vincent
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin
On Wed, 24 Apr 2013, Rabin Vincent wrote:
> 2013/4/24 Lee Jones <lee.jones@linaro.org>:
> > The aim is to make the code that little more readable.
> >
> > Acked-by: Vinod Koul <vnod.koul@intel.com>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Please pay closer attention to the semantics of each usage instead of
> just replacing all x left shifts of 1 by BIT(x) for "readability".
>
> > if (seg_max > STEDMA40_MAX_SEG_SIZE)
> > - seg_max -= (1 << max_w);
> > + seg_max -= BIT(max_w);
> >
> > - if (!IS_ALIGNED(size, 1 << max_w))
> > + if (!IS_ALIGNED(size, BIT(max_w)))
> > return -EINVAL;
>
> Here and in all other places where the values are from cfg->data_width,
> the semantic purpose of the shift is not for setting a particular bit
> but instead for converting the data_width field into the data width
> value in bytes. You should not change these usages to BIT().
>
> It would be instead better to just make the cfg->data_width as the
> number of bytes and convert them to the appropriate hardware field
> values when the descriptors are constructed. That of course should be
> in another patch.
I'll do that. Thanks for the pointer.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 03/32 v3] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-25 8:13 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 8:13 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 24 Apr 2013, Rabin Vincent wrote:
> 2013/4/24 Lee Jones <lee.jones@linaro.org>:
> > The aim is to make the code that little more readable.
> >
> > Acked-by: Vinod Koul <vnod.koul@intel.com>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Please pay closer attention to the semantics of each usage instead of
> just replacing all x left shifts of 1 by BIT(x) for "readability".
>
> > if (seg_max > STEDMA40_MAX_SEG_SIZE)
> > - seg_max -= (1 << max_w);
> > + seg_max -= BIT(max_w);
> >
> > - if (!IS_ALIGNED(size, 1 << max_w))
> > + if (!IS_ALIGNED(size, BIT(max_w)))
> > return -EINVAL;
>
> Here and in all other places where the values are from cfg->data_width,
> the semantic purpose of the shift is not for setting a particular bit
> but instead for converting the data_width field into the data width
> value in bytes. You should not change these usages to BIT().
>
> It would be instead better to just make the cfg->data_width as the
> number of bytes and convert them to the appropriate hardware field
> values when the descriptors are constructed. That of course should be
> in another patch.
I'll do that. Thanks for the pointer.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 03/32 v4] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-18 10:11 ` Lee Jones
@ 2013-04-26 11:39 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-26 11:39 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
The aim is to make the code that little more readable.
Acked-by: Vinod Koul <vnod.koul@intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index d7e926d..78511ef 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -54,8 +54,8 @@
#define MAX_LCLA_ALLOC_ATTEMPTS 256
/* Bit markings for allocation map */
-#define D40_ALLOC_FREE (1 << 31)
-#define D40_ALLOC_PHY (1 << 30)
+#define D40_ALLOC_FREE BIT(31)
+#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE 0
#define D40_IS_SRC(dir) (dir == STEDMA40_PERIPH_TO_MEM)
@@ -1728,7 +1728,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
}
/* ACK interrupt */
- writel(1 << idx, base->virtbase + il[row].clr);
+ writel(BIT(idx), base->virtbase + il[row].clr);
spin_lock(&d40c->lock);
@@ -1818,8 +1818,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_src == D40_ALLOC_FREE)
phy->allocated_src = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_src & (1 << log_event_line))) {
- phy->allocated_src |= 1 << log_event_line;
+ if (!(phy->allocated_src & BIT(log_event_line))) {
+ phy->allocated_src |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1830,8 +1830,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_dst == D40_ALLOC_FREE)
phy->allocated_dst = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_dst & (1 << log_event_line))) {
- phy->allocated_dst |= 1 << log_event_line;
+ if (!(phy->allocated_dst & BIT(log_event_line))) {
+ phy->allocated_dst |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1861,11 +1861,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
/* Logical channel */
if (is_src) {
- phy->allocated_src &= ~(1 << log_event_line);
+ phy->allocated_src &= ~BIT(log_event_line);
if (phy->allocated_src == D40_ALLOC_LOG_FREE)
phy->allocated_src = D40_ALLOC_FREE;
} else {
- phy->allocated_dst &= ~(1 << log_event_line);
+ phy->allocated_dst &= ~BIT(log_event_line);
if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
phy->allocated_dst = D40_ALLOC_FREE;
}
@@ -2333,7 +2333,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
u32 rtreg;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
- u32 bit = 1 << event;
+ u32 bit = BIT(event);
u32 prioreg;
struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 03/32 v4] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-26 11:39 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-26 11:39 UTC (permalink / raw)
To: linux-arm-kernel
The aim is to make the code that little more readable.
Acked-by: Vinod Koul <vnod.koul@intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index d7e926d..78511ef 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -54,8 +54,8 @@
#define MAX_LCLA_ALLOC_ATTEMPTS 256
/* Bit markings for allocation map */
-#define D40_ALLOC_FREE (1 << 31)
-#define D40_ALLOC_PHY (1 << 30)
+#define D40_ALLOC_FREE BIT(31)
+#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE 0
#define D40_IS_SRC(dir) (dir == STEDMA40_PERIPH_TO_MEM)
@@ -1728,7 +1728,7 @@ static irqreturn_t d40_handle_interrupt(int irq, void *data)
}
/* ACK interrupt */
- writel(1 << idx, base->virtbase + il[row].clr);
+ writel(BIT(idx), base->virtbase + il[row].clr);
spin_lock(&d40c->lock);
@@ -1818,8 +1818,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_src == D40_ALLOC_FREE)
phy->allocated_src = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_src & (1 << log_event_line))) {
- phy->allocated_src |= 1 << log_event_line;
+ if (!(phy->allocated_src & BIT(log_event_line))) {
+ phy->allocated_src |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1830,8 +1830,8 @@ static bool d40_alloc_mask_set(struct d40_phy_res *phy,
if (phy->allocated_dst == D40_ALLOC_FREE)
phy->allocated_dst = D40_ALLOC_LOG_FREE;
- if (!(phy->allocated_dst & (1 << log_event_line))) {
- phy->allocated_dst |= 1 << log_event_line;
+ if (!(phy->allocated_dst & BIT(log_event_line))) {
+ phy->allocated_dst |= BIT(log_event_line);
goto found;
} else
goto not_found;
@@ -1861,11 +1861,11 @@ static bool d40_alloc_mask_free(struct d40_phy_res *phy, bool is_src,
/* Logical channel */
if (is_src) {
- phy->allocated_src &= ~(1 << log_event_line);
+ phy->allocated_src &= ~BIT(log_event_line);
if (phy->allocated_src == D40_ALLOC_LOG_FREE)
phy->allocated_src = D40_ALLOC_FREE;
} else {
- phy->allocated_dst &= ~(1 << log_event_line);
+ phy->allocated_dst &= ~BIT(log_event_line);
if (phy->allocated_dst == D40_ALLOC_LOG_FREE)
phy->allocated_dst = D40_ALLOC_FREE;
}
@@ -2333,7 +2333,7 @@ static void __d40_set_prio_rt(struct d40_chan *d40c, int dev_type, bool src)
u32 rtreg;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
- u32 bit = 1 << event;
+ u32 bit = BIT(event);
u32 prioreg;
struct d40_gen_dmac *dmac = &d40c->base->gen_dmac;
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 03/32 v4] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
2013-04-26 11:39 ` Lee Jones
@ 2013-04-26 15:04 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-26 15:04 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Fri, Apr 26, 2013 at 1:39 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The aim is to make the code that little more readable.
>
> Acked-by: Vinod Koul <vnod.koul@intel.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Fine with me:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 03/32 v4] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
@ 2013-04-26 15:04 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-26 15:04 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Apr 26, 2013 at 1:39 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The aim is to make the code that little more readable.
>
> Acked-by: Vinod Koul <vnod.koul@intel.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Fine with me:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
Devices which utilise DMA tend to use the same channel numbers for
transmitting and receiving. For this reason and the fact that it'll
decrease the burden of platform data passed to each device, we're
amalgamating source and destination device types.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500-audio.c | 18 +--
arch/arm/mach-ux500/board-mop500-sdi.c | 24 ++--
arch/arm/mach-ux500/board-mop500.c | 33 ++---
arch/arm/mach-ux500/cpu-db8500.c | 32 ++---
arch/arm/mach-ux500/devices-db8500.c | 120 ++++++++---------
arch/arm/mach-ux500/ste-dma40-db8500.h | 193 ++++++++++-----------------
arch/arm/mach-ux500/usb.c | 10 +-
drivers/dma/ste_dma40.c | 89 ++++--------
drivers/dma/ste_dma40_ll.c | 4 +-
include/linux/platform_data/dma-ste-dma40.h | 6 +-
10 files changed, 205 insertions(+), 324 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index 7209db7..f012cfa 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -24,8 +24,7 @@ static struct stedma40_chan_cfg msp0_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
.src_info.psize = STEDMA40_PSIZE_LOG_4,
.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -37,8 +36,7 @@ static struct stedma40_chan_cfg msp0_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_DST_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX,
+ .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
.src_info.psize = STEDMA40_PSIZE_LOG_4,
.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -56,8 +54,7 @@ static struct stedma40_chan_cfg msp1_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV30_MSP3_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV30_MSP3,
.src_info.psize = STEDMA40_PSIZE_LOG_4,
.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -69,8 +66,7 @@ static struct stedma40_chan_cfg msp1_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_DST_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV30_MSP1_TX,
+ .dev_type = DB8500_DMA_DEV30_MSP1,
.src_info.psize = STEDMA40_PSIZE_LOG_4,
.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -88,8 +84,7 @@ static struct stedma40_chan_cfg msp2_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV14_MSP2_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV14_MSP2,
/* MSP2 DMA doesn't work with PSIZE == 4 on DB8500v2 */
.src_info.psize = STEDMA40_PSIZE_LOG_1,
@@ -102,8 +97,7 @@ static struct stedma40_chan_cfg msp2_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_DST_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV14_MSP2_TX,
+ .dev_type = DB8500_DMA_DEV14_MSP2,
.src_info.psize = STEDMA40_PSIZE_LOG_4,
.dst_info.psize = STEDMA40_PSIZE_LOG_4,
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 7f2cb6c..5c28216 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -64,8 +64,7 @@ static int mop500_sdi0_ios_handler(struct device *dev, struct mmc_ios *ios)
struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV29_SD_MM0_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV29_SD_MM0,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -73,8 +72,7 @@ struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV29_SD_MM0_TX,
+ .dev_type = DB8500_DMA_DEV29_SD_MM0,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -135,8 +133,7 @@ void mop500_sdi_tc35892_init(struct device *parent)
static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV32_SD_MM1_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV32_SD_MM1,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -144,8 +141,7 @@ static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
static struct stedma40_chan_cfg sdi1_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV32_SD_MM1_TX,
+ .dev_type = DB8500_DMA_DEV32_SD_MM1,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -172,8 +168,7 @@ struct mmci_platform_data mop500_sdi1_data = {
struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV28_SD_MM2_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV28_SD_MM2,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -181,8 +176,7 @@ struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
static struct stedma40_chan_cfg mop500_sdi2_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV28_SD_MM2_TX,
+ .dev_type = DB8500_DMA_DEV28_SD_MM2,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -210,8 +204,7 @@ struct mmci_platform_data mop500_sdi2_data = {
struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV42_SD_MM4_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV42_SD_MM4,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -219,8 +212,7 @@ struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV42_SD_MM4_TX,
+ .dev_type = DB8500_DMA_DEV42_SD_MM4,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 87d2d7b..a8b3ad9 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -452,8 +452,7 @@ void mop500_snowball_ethernet_clock_enable(void)
static struct cryp_platform_data u8500_cryp1_platform_data = {
.mem_to_engine = {
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV48_CAC1_TX,
+ .dev_type = DB8500_DMA_DEV48_CAC1,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
.mode = STEDMA40_MODE_LOGICAL,
@@ -462,8 +461,7 @@ static struct cryp_platform_data u8500_cryp1_platform_data = {
},
.engine_to_mem = {
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV48_CAC1_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV48_CAC1,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
.mode = STEDMA40_MODE_LOGICAL,
@@ -474,8 +472,7 @@ static struct cryp_platform_data u8500_cryp1_platform_data = {
static struct stedma40_chan_cfg u8500_hash_dma_cfg_tx = {
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV50_HAC1_TX,
+ .dev_type = DB8500_DMA_DEV50_HAC1_TX,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
.mode = STEDMA40_MODE_LOGICAL,
@@ -497,8 +494,7 @@ static struct platform_device *mop500_platform_devs[] __initdata = {
static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV8_SSP0_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV8_SSP0,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -506,8 +502,7 @@ static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
static struct stedma40_chan_cfg ssp0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV8_SSP0_TX,
+ .dev_type = DB8500_DMA_DEV8_SSP0,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -538,8 +533,7 @@ static void __init mop500_spi_init(struct device *parent)
static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV13_UART0_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV13_UART0,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -547,8 +541,7 @@ static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV13_UART0_TX,
+ .dev_type = DB8500_DMA_DEV13_UART0,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -556,8 +549,7 @@ static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV12_UART1_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV12_UART1,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -565,8 +557,7 @@ static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV12_UART1_TX,
+ .dev_type = DB8500_DMA_DEV12_UART1,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -574,8 +565,7 @@ static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV11_UART2_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV11_UART2,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -583,8 +573,7 @@ static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
static struct stedma40_chan_cfg uart2_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV11_UART2_TX,
+ .dev_type = DB8500_DMA_DEV11_UART2,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index e027865..f72cc9b 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -167,25 +167,25 @@ static void __init db8500_add_gpios(struct device *parent)
}
static int usb_db8500_rx_dma_cfg[] = {
- DB8500_DMA_DEV38_USB_OTG_IEP_1_9,
- DB8500_DMA_DEV37_USB_OTG_IEP_2_10,
- DB8500_DMA_DEV36_USB_OTG_IEP_3_11,
- DB8500_DMA_DEV19_USB_OTG_IEP_4_12,
- DB8500_DMA_DEV18_USB_OTG_IEP_5_13,
- DB8500_DMA_DEV17_USB_OTG_IEP_6_14,
- DB8500_DMA_DEV16_USB_OTG_IEP_7_15,
- DB8500_DMA_DEV39_USB_OTG_IEP_8
+ DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
+ DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
+ DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
+ DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
+ DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
+ DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
+ DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
+ DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
};
static int usb_db8500_tx_dma_cfg[] = {
- DB8500_DMA_DEV38_USB_OTG_OEP_1_9,
- DB8500_DMA_DEV37_USB_OTG_OEP_2_10,
- DB8500_DMA_DEV36_USB_OTG_OEP_3_11,
- DB8500_DMA_DEV19_USB_OTG_OEP_4_12,
- DB8500_DMA_DEV18_USB_OTG_OEP_5_13,
- DB8500_DMA_DEV17_USB_OTG_OEP_6_14,
- DB8500_DMA_DEV16_USB_OTG_OEP_7_15,
- DB8500_DMA_DEV39_USB_OTG_OEP_8
+ DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
+ DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
+ DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
+ DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
+ DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
+ DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
+ DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
+ DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
};
static const char *db8500_read_soc_id(void)
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 5b1f1f7..03efd4c1 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -50,74 +50,74 @@ static struct resource dma40_resources[] = {
*/
static const dma_addr_t dma40_tx_map[DB8500_DMA_NR_DEV] = {
/* MUSB - these will be runtime-reconfigured */
- [DB8500_DMA_DEV39_USB_OTG_OEP_8] = -1,
- [DB8500_DMA_DEV16_USB_OTG_OEP_7_15] = -1,
- [DB8500_DMA_DEV17_USB_OTG_OEP_6_14] = -1,
- [DB8500_DMA_DEV18_USB_OTG_OEP_5_13] = -1,
- [DB8500_DMA_DEV19_USB_OTG_OEP_4_12] = -1,
- [DB8500_DMA_DEV36_USB_OTG_OEP_3_11] = -1,
- [DB8500_DMA_DEV37_USB_OTG_OEP_2_10] = -1,
- [DB8500_DMA_DEV38_USB_OTG_OEP_1_9] = -1,
+ [DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8] = -1,
+ [DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15] = -1,
+ [DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14] = -1,
+ [DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13] = -1,
+ [DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12] = -1,
+ [DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11] = -1,
+ [DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10] = -1,
+ [DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9] = -1,
/* PrimeCells - run-time configured */
- [DB8500_DMA_DEV0_SPI0_TX] = -1,
- [DB8500_DMA_DEV1_SD_MMC0_TX] = -1,
- [DB8500_DMA_DEV2_SD_MMC1_TX] = -1,
- [DB8500_DMA_DEV3_SD_MMC2_TX] = -1,
- [DB8500_DMA_DEV8_SSP0_TX] = -1,
- [DB8500_DMA_DEV9_SSP1_TX] = -1,
- [DB8500_DMA_DEV11_UART2_TX] = -1,
- [DB8500_DMA_DEV12_UART1_TX] = -1,
- [DB8500_DMA_DEV13_UART0_TX] = -1,
- [DB8500_DMA_DEV28_SD_MM2_TX] = -1,
- [DB8500_DMA_DEV29_SD_MM0_TX] = -1,
- [DB8500_DMA_DEV32_SD_MM1_TX] = -1,
- [DB8500_DMA_DEV33_SPI2_TX] = -1,
- [DB8500_DMA_DEV35_SPI1_TX] = -1,
- [DB8500_DMA_DEV40_SPI3_TX] = -1,
- [DB8500_DMA_DEV41_SD_MM3_TX] = -1,
- [DB8500_DMA_DEV42_SD_MM4_TX] = -1,
- [DB8500_DMA_DEV43_SD_MM5_TX] = -1,
- [DB8500_DMA_DEV14_MSP2_TX] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV30_MSP1_TX] = U8500_MSP1_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV48_CAC1_TX] = U8500_CRYP1_BASE + CRYP1_TX_REG_OFFSET,
+ [DB8500_DMA_DEV0_SPI0] = -1,
+ [DB8500_DMA_DEV1_SD_MMC0] = -1,
+ [DB8500_DMA_DEV2_SD_MMC1] = -1,
+ [DB8500_DMA_DEV3_SD_MMC2] = -1,
+ [DB8500_DMA_DEV8_SSP0] = -1,
+ [DB8500_DMA_DEV9_SSP1] = -1,
+ [DB8500_DMA_DEV11_UART2] = -1,
+ [DB8500_DMA_DEV12_UART1] = -1,
+ [DB8500_DMA_DEV13_UART0] = -1,
+ [DB8500_DMA_DEV28_SD_MM2] = -1,
+ [DB8500_DMA_DEV29_SD_MM0] = -1,
+ [DB8500_DMA_DEV32_SD_MM1] = -1,
+ [DB8500_DMA_DEV33_SPI2] = -1,
+ [DB8500_DMA_DEV35_SPI1] = -1,
+ [DB8500_DMA_DEV40_SPI3] = -1,
+ [DB8500_DMA_DEV41_SD_MM3] = -1,
+ [DB8500_DMA_DEV42_SD_MM4] = -1,
+ [DB8500_DMA_DEV43_SD_MM5] = -1,
+ [DB8500_DMA_DEV14_MSP2] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV30_MSP1] = U8500_MSP1_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV31_MSP0_SLIM0_CH0] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV48_CAC1] = U8500_CRYP1_BASE + CRYP1_TX_REG_OFFSET,
[DB8500_DMA_DEV50_HAC1_TX] = U8500_HASH1_BASE + HASH1_TX_REG_OFFSET,
};
/* Mapping between source event lines and physical device address */
static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
/* MUSB - these will be runtime-reconfigured */
- [DB8500_DMA_DEV39_USB_OTG_IEP_8] = -1,
- [DB8500_DMA_DEV16_USB_OTG_IEP_7_15] = -1,
- [DB8500_DMA_DEV17_USB_OTG_IEP_6_14] = -1,
- [DB8500_DMA_DEV18_USB_OTG_IEP_5_13] = -1,
- [DB8500_DMA_DEV19_USB_OTG_IEP_4_12] = -1,
- [DB8500_DMA_DEV36_USB_OTG_IEP_3_11] = -1,
- [DB8500_DMA_DEV37_USB_OTG_IEP_2_10] = -1,
- [DB8500_DMA_DEV38_USB_OTG_IEP_1_9] = -1,
+ [DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8] = -1,
+ [DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15] = -1,
+ [DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14] = -1,
+ [DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13] = -1,
+ [DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12] = -1,
+ [DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11] = -1,
+ [DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10] = -1,
+ [DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9] = -1,
/* PrimeCells */
- [DB8500_DMA_DEV0_SPI0_RX] = -1,
- [DB8500_DMA_DEV1_SD_MMC0_RX] = -1,
- [DB8500_DMA_DEV2_SD_MMC1_RX] = -1,
- [DB8500_DMA_DEV3_SD_MMC2_RX] = -1,
- [DB8500_DMA_DEV8_SSP0_RX] = -1,
- [DB8500_DMA_DEV9_SSP1_RX] = -1,
- [DB8500_DMA_DEV11_UART2_RX] = -1,
- [DB8500_DMA_DEV12_UART1_RX] = -1,
- [DB8500_DMA_DEV13_UART0_RX] = -1,
- [DB8500_DMA_DEV28_SD_MM2_RX] = -1,
- [DB8500_DMA_DEV29_SD_MM0_RX] = -1,
- [DB8500_DMA_DEV32_SD_MM1_RX] = -1,
- [DB8500_DMA_DEV33_SPI2_RX] = -1,
- [DB8500_DMA_DEV35_SPI1_RX] = -1,
- [DB8500_DMA_DEV40_SPI3_RX] = -1,
- [DB8500_DMA_DEV41_SD_MM3_RX] = -1,
- [DB8500_DMA_DEV42_SD_MM4_RX] = -1,
- [DB8500_DMA_DEV43_SD_MM5_RX] = -1,
- [DB8500_DMA_DEV14_MSP2_RX] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV30_MSP3_RX] = U8500_MSP3_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
+ [DB8500_DMA_DEV0_SPI0] = -1,
+ [DB8500_DMA_DEV1_SD_MMC0] = -1,
+ [DB8500_DMA_DEV2_SD_MMC1] = -1,
+ [DB8500_DMA_DEV3_SD_MMC2] = -1,
+ [DB8500_DMA_DEV8_SSP0] = -1,
+ [DB8500_DMA_DEV9_SSP1] = -1,
+ [DB8500_DMA_DEV11_UART2] = -1,
+ [DB8500_DMA_DEV12_UART1] = -1,
+ [DB8500_DMA_DEV13_UART0] = -1,
+ [DB8500_DMA_DEV28_SD_MM2] = -1,
+ [DB8500_DMA_DEV29_SD_MM0] = -1,
+ [DB8500_DMA_DEV32_SD_MM1] = -1,
+ [DB8500_DMA_DEV33_SPI2] = -1,
+ [DB8500_DMA_DEV35_SPI1] = -1,
+ [DB8500_DMA_DEV40_SPI3] = -1,
+ [DB8500_DMA_DEV41_SD_MM3] = -1,
+ [DB8500_DMA_DEV42_SD_MM4] = -1,
+ [DB8500_DMA_DEV43_SD_MM5] = -1,
+ [DB8500_DMA_DEV14_MSP2] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV30_MSP3] = U8500_MSP3_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV31_MSP0_SLIM0_CH0] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV48_CAC1] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
};
static struct stedma40_platform_data dma40_plat_data = {
diff --git a/arch/arm/mach-ux500/ste-dma40-db8500.h b/arch/arm/mach-ux500/ste-dma40-db8500.h
index a616419..0296ae5 100644
--- a/arch/arm/mach-ux500/ste-dma40-db8500.h
+++ b/arch/arm/mach-ux500/ste-dma40-db8500.h
@@ -12,133 +12,74 @@
#define DB8500_DMA_NR_DEV 64
-enum dma_src_dev_type {
- DB8500_DMA_DEV0_SPI0_RX = 0,
- DB8500_DMA_DEV1_SD_MMC0_RX = 1,
- DB8500_DMA_DEV2_SD_MMC1_RX = 2,
- DB8500_DMA_DEV3_SD_MMC2_RX = 3,
- DB8500_DMA_DEV4_I2C1_RX = 4,
- DB8500_DMA_DEV5_I2C3_RX = 5,
- DB8500_DMA_DEV6_I2C2_RX = 6,
- DB8500_DMA_DEV7_I2C4_RX = 7, /* Only on V1 and later */
- DB8500_DMA_DEV8_SSP0_RX = 8,
- DB8500_DMA_DEV9_SSP1_RX = 9,
- DB8500_DMA_DEV10_MCDE_RX = 10,
- DB8500_DMA_DEV11_UART2_RX = 11,
- DB8500_DMA_DEV12_UART1_RX = 12,
- DB8500_DMA_DEV13_UART0_RX = 13,
- DB8500_DMA_DEV14_MSP2_RX = 14,
- DB8500_DMA_DEV15_I2C0_RX = 15,
- DB8500_DMA_DEV16_USB_OTG_IEP_7_15 = 16,
- DB8500_DMA_DEV17_USB_OTG_IEP_6_14 = 17,
- DB8500_DMA_DEV18_USB_OTG_IEP_5_13 = 18,
- DB8500_DMA_DEV19_USB_OTG_IEP_4_12 = 19,
- DB8500_DMA_DEV20_SLIM0_CH0_RX_HSI_RX_CH0 = 20,
- DB8500_DMA_DEV21_SLIM0_CH1_RX_HSI_RX_CH1 = 21,
- DB8500_DMA_DEV22_SLIM0_CH2_RX_HSI_RX_CH2 = 22,
- DB8500_DMA_DEV23_SLIM0_CH3_RX_HSI_RX_CH3 = 23,
- DB8500_DMA_DEV24_SRC_SXA0_RX_TX = 24,
- DB8500_DMA_DEV25_SRC_SXA1_RX_TX = 25,
- DB8500_DMA_DEV26_SRC_SXA2_RX_TX = 26,
- DB8500_DMA_DEV27_SRC_SXA3_RX_TX = 27,
- DB8500_DMA_DEV28_SD_MM2_RX = 28,
- DB8500_DMA_DEV29_SD_MM0_RX = 29,
- DB8500_DMA_DEV30_MSP1_RX = 30,
+/*
+ * Unless otherwise specified, all channels numbers are used for
+ * TX & RX, and can be used for either source or destination
+ * channels.
+ */
+enum dma_dev_type {
+ DB8500_DMA_DEV0_SPI0 = 0,
+ DB8500_DMA_DEV1_SD_MMC0 = 1,
+ DB8500_DMA_DEV2_SD_MMC1 = 2,
+ DB8500_DMA_DEV3_SD_MMC2 = 3,
+ DB8500_DMA_DEV4_I2C1 = 4,
+ DB8500_DMA_DEV5_I2C3 = 5,
+ DB8500_DMA_DEV6_I2C2 = 6,
+ DB8500_DMA_DEV7_I2C4 = 7, /* Only on V1 and later */
+ DB8500_DMA_DEV8_SSP0 = 8,
+ DB8500_DMA_DEV9_SSP1 = 9,
+ DB8500_DMA_DEV10_MCDE_RX = 10, /* RX only */
+ DB8500_DMA_DEV11_UART2 = 11,
+ DB8500_DMA_DEV12_UART1 = 12,
+ DB8500_DMA_DEV13_UART0 = 13,
+ DB8500_DMA_DEV14_MSP2 = 14,
+ DB8500_DMA_DEV15_I2C0 = 15,
+ DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15 = 16,
+ DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14 = 17,
+ DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13 = 18,
+ DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12 = 19,
+ DB8500_DMA_DEV20_SLIM0_CH0_HSI_CH0 = 20,
+ DB8500_DMA_DEV21_SLIM0_CH1_HSI_CH1 = 21,
+ DB8500_DMA_DEV22_SLIM0_CH2_HSI_CH2 = 22,
+ DB8500_DMA_DEV23_SLIM0_CH3_HSI_CH3 = 23,
+ DB8500_DMA_DEV24_SXA0 = 24,
+ DB8500_DMA_DEV25_SXA1 = 25,
+ DB8500_DMA_DEV26_SXA2 = 26,
+ DB8500_DMA_DEV27_SXA3 = 27,
+ DB8500_DMA_DEV28_SD_MM2 = 28,
+ DB8500_DMA_DEV29_SD_MM0 = 29,
+ DB8500_DMA_DEV30_MSP1 = 30,
/* On DB8500v2, MSP3 RX replaces MSP1 RX */
- DB8500_DMA_DEV30_MSP3_RX = 30,
- DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX = 31,
- DB8500_DMA_DEV32_SD_MM1_RX = 32,
- DB8500_DMA_DEV33_SPI2_RX = 33,
- DB8500_DMA_DEV34_I2C3_RX2 = 34,
- DB8500_DMA_DEV35_SPI1_RX = 35,
- DB8500_DMA_DEV36_USB_OTG_IEP_3_11 = 36,
- DB8500_DMA_DEV37_USB_OTG_IEP_2_10 = 37,
- DB8500_DMA_DEV38_USB_OTG_IEP_1_9 = 38,
- DB8500_DMA_DEV39_USB_OTG_IEP_8 = 39,
- DB8500_DMA_DEV40_SPI3_RX = 40,
- DB8500_DMA_DEV41_SD_MM3_RX = 41,
- DB8500_DMA_DEV42_SD_MM4_RX = 42,
- DB8500_DMA_DEV43_SD_MM5_RX = 43,
- DB8500_DMA_DEV44_SRC_SXA4_RX_TX = 44,
- DB8500_DMA_DEV45_SRC_SXA5_RX_TX = 45,
- DB8500_DMA_DEV46_SLIM0_CH8_RX_SRC_SXA6_RX_TX = 46,
- DB8500_DMA_DEV47_SLIM0_CH9_RX_SRC_SXA7_RX_TX = 47,
- DB8500_DMA_DEV48_CAC1_RX = 48,
- /* 49, 50 and 51 are not used */
- DB8500_DMA_DEV52_SLIM0_CH4_RX_HSI_RX_CH4 = 52,
- DB8500_DMA_DEV53_SLIM0_CH5_RX_HSI_RX_CH5 = 53,
- DB8500_DMA_DEV54_SLIM0_CH6_RX_HSI_RX_CH6 = 54,
- DB8500_DMA_DEV55_SLIM0_CH7_RX_HSI_RX_CH7 = 55,
- /* 56, 57, 58, 59 and 60 are not used */
- DB8500_DMA_DEV61_CAC0_RX = 61,
- /* 62 and 63 are not used */
-};
-
-enum dma_dest_dev_type {
- DB8500_DMA_DEV0_SPI0_TX = 0,
- DB8500_DMA_DEV1_SD_MMC0_TX = 1,
- DB8500_DMA_DEV2_SD_MMC1_TX = 2,
- DB8500_DMA_DEV3_SD_MMC2_TX = 3,
- DB8500_DMA_DEV4_I2C1_TX = 4,
- DB8500_DMA_DEV5_I2C3_TX = 5,
- DB8500_DMA_DEV6_I2C2_TX = 6,
- DB8500_DMA_DEV7_I2C4_TX = 7, /* Only on V1 and later */
- DB8500_DMA_DEV8_SSP0_TX = 8,
- DB8500_DMA_DEV9_SSP1_TX = 9,
- /* 10 is not used*/
- DB8500_DMA_DEV11_UART2_TX = 11,
- DB8500_DMA_DEV12_UART1_TX = 12,
- DB8500_DMA_DEV13_UART0_TX = 13,
- DB8500_DMA_DEV14_MSP2_TX = 14,
- DB8500_DMA_DEV15_I2C0_TX = 15,
- DB8500_DMA_DEV16_USB_OTG_OEP_7_15 = 16,
- DB8500_DMA_DEV17_USB_OTG_OEP_6_14 = 17,
- DB8500_DMA_DEV18_USB_OTG_OEP_5_13 = 18,
- DB8500_DMA_DEV19_USB_OTG_OEP_4_12 = 19,
- DB8500_DMA_DEV20_SLIM0_CH0_TX_HSI_TX_CH0 = 20,
- DB8500_DMA_DEV21_SLIM0_CH1_TX_HSI_TX_CH1 = 21,
- DB8500_DMA_DEV22_SLIM0_CH2_TX_HSI_TX_CH2 = 22,
- DB8500_DMA_DEV23_SLIM0_CH3_TX_HSI_TX_CH3 = 23,
- DB8500_DMA_DEV24_DST_SXA0_RX_TX = 24,
- DB8500_DMA_DEV25_DST_SXA1_RX_TX = 25,
- DB8500_DMA_DEV26_DST_SXA2_RX_TX = 26,
- DB8500_DMA_DEV27_DST_SXA3_RX_TX = 27,
- DB8500_DMA_DEV28_SD_MM2_TX = 28,
- DB8500_DMA_DEV29_SD_MM0_TX = 29,
- DB8500_DMA_DEV30_MSP1_TX = 30,
- DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX = 31,
- DB8500_DMA_DEV32_SD_MM1_TX = 32,
- DB8500_DMA_DEV33_SPI2_TX = 33,
- DB8500_DMA_DEV34_I2C3_TX2 = 34,
- DB8500_DMA_DEV35_SPI1_TX = 35,
- DB8500_DMA_DEV36_USB_OTG_OEP_3_11 = 36,
- DB8500_DMA_DEV37_USB_OTG_OEP_2_10 = 37,
- DB8500_DMA_DEV38_USB_OTG_OEP_1_9 = 38,
- DB8500_DMA_DEV39_USB_OTG_OEP_8 = 39,
- DB8500_DMA_DEV40_SPI3_TX = 40,
- DB8500_DMA_DEV41_SD_MM3_TX = 41,
- DB8500_DMA_DEV42_SD_MM4_TX = 42,
- DB8500_DMA_DEV43_SD_MM5_TX = 43,
- DB8500_DMA_DEV44_DST_SXA4_RX_TX = 44,
- DB8500_DMA_DEV45_DST_SXA5_RX_TX = 45,
- DB8500_DMA_DEV46_SLIM0_CH8_TX_DST_SXA6_RX_TX = 46,
- DB8500_DMA_DEV47_SLIM0_CH9_TX_DST_SXA7_RX_TX = 47,
- DB8500_DMA_DEV48_CAC1_TX = 48,
- DB8500_DMA_DEV49_CAC1_TX_HAC1_TX = 49,
- DB8500_DMA_DEV50_HAC1_TX = 50,
- DB8500_DMA_MEMCPY_TX_0 = 51,
- DB8500_DMA_DEV52_SLIM1_CH4_TX_HSI_TX_CH4 = 52,
- DB8500_DMA_DEV53_SLIM1_CH5_TX_HSI_TX_CH5 = 53,
- DB8500_DMA_DEV54_SLIM1_CH6_TX_HSI_TX_CH6 = 54,
- DB8500_DMA_DEV55_SLIM1_CH7_TX_HSI_TX_CH7 = 55,
- DB8500_DMA_MEMCPY_TX_1 = 56,
- DB8500_DMA_MEMCPY_TX_2 = 57,
- DB8500_DMA_MEMCPY_TX_3 = 58,
- DB8500_DMA_MEMCPY_TX_4 = 59,
- DB8500_DMA_MEMCPY_TX_5 = 60,
- DB8500_DMA_DEV61_CAC0_TX = 61,
- DB8500_DMA_DEV62_CAC0_TX_HAC0_TX = 62,
- DB8500_DMA_DEV63_HAC0_TX = 63,
+ DB8500_DMA_DEV30_MSP3 = 30,
+ DB8500_DMA_DEV31_MSP0_SLIM0_CH0 = 31,
+ DB8500_DMA_DEV32_SD_MM1 = 32,
+ DB8500_DMA_DEV33_SPI2 = 33,
+ DB8500_DMA_DEV34_I2C3_RX2_TX2 = 34,
+ DB8500_DMA_DEV35_SPI1 = 35,
+ DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11 = 36,
+ DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10 = 37,
+ DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9 = 38,
+ DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8 = 39,
+ DB8500_DMA_DEV40_SPI3 = 40,
+ DB8500_DMA_DEV41_SD_MM3 = 41,
+ DB8500_DMA_DEV42_SD_MM4 = 42,
+ DB8500_DMA_DEV43_SD_MM5 = 43,
+ DB8500_DMA_DEV44_SXA4 = 44,
+ DB8500_DMA_DEV45_SXA5 = 45,
+ DB8500_DMA_DEV46_SLIM0_CH8_SRC_SXA6 = 46,
+ DB8500_DMA_DEV47_SLIM0_CH9_SRC_SXA7 = 47,
+ DB8500_DMA_DEV48_CAC1 = 48,
+ DB8500_DMA_DEV49_CAC1_TX_HAC1_TX = 49, /* TX only */
+ DB8500_DMA_DEV50_HAC1_TX = 50, /* TX only */
+ DB8500_DMA_MEMCPY_TX_0 = 51, /* TX only */
+ DB8500_DMA_DEV52_SLIM0_CH4_HSI_CH4 = 52,
+ DB8500_DMA_DEV53_SLIM0_CH5_HSI_CH5 = 53,
+ DB8500_DMA_DEV54_SLIM0_CH6_HSI_CH6 = 54,
+ DB8500_DMA_DEV55_SLIM0_CH7_HSI_CH7 = 55,
+ /* 56 -> 60 are channels reserved for memcpy only */
+ DB8500_DMA_DEV61_CAC0 = 61,
+ DB8500_DMA_DEV62_CAC0_TX_HAC0_TX = 62, /* TX only */
+ DB8500_DMA_DEV63_HAC0_TX = 63, /* TX only */
};
#endif
diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index 78ac65f..e0ea490 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -15,7 +15,6 @@
#define MUSB_DMA40_RX_CH { \
.mode = STEDMA40_MODE_LOGICAL, \
.dir = STEDMA40_PERIPH_TO_MEM, \
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY, \
.src_info.data_width = STEDMA40_WORD_WIDTH, \
.dst_info.data_width = STEDMA40_WORD_WIDTH, \
.src_info.psize = STEDMA40_PSIZE_LOG_16, \
@@ -25,7 +24,6 @@
#define MUSB_DMA40_TX_CH { \
.mode = STEDMA40_MODE_LOGICAL, \
.dir = STEDMA40_MEM_TO_PERIPH, \
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY, \
.src_info.data_width = STEDMA40_WORD_WIDTH, \
.dst_info.data_width = STEDMA40_WORD_WIDTH, \
.src_info.psize = STEDMA40_PSIZE_LOG_16, \
@@ -125,20 +123,20 @@ struct platform_device ux500_musb_device = {
.resource = usb_resources,
};
-static inline void ux500_usb_dma_update_rx_ch_config(int *src_dev_type)
+static inline void ux500_usb_dma_update_rx_ch_config(int *dev_type)
{
u32 idx;
for (idx = 0; idx < UX500_MUSB_DMA_NUM_RX_CHANNELS; idx++)
- musb_dma_rx_ch[idx].src_dev_type = src_dev_type[idx];
+ musb_dma_rx_ch[idx].dev_type = dev_type[idx];
}
-static inline void ux500_usb_dma_update_tx_ch_config(int *dst_dev_type)
+static inline void ux500_usb_dma_update_tx_ch_config(int *dev_type)
{
u32 idx;
for (idx = 0; idx < UX500_MUSB_DMA_NUM_TX_CHANNELS; idx++)
- musb_dma_tx_ch[idx].dst_dev_type = dst_dev_type[idx];
+ musb_dma_tx_ch[idx].dev_type = dev_type[idx];
}
void ux500_add_usb(struct device *parent, resource_size_t base, int irq,
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 121c46b..e50354d 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -1288,21 +1288,17 @@ static void __d40_config_set_event(struct d40_chan *d40c,
static void d40_config_set_event(struct d40_chan *d40c,
enum d40_events event_type)
{
+ u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
+
/* Enable event line connected to device (or memcpy) */
if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
- (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH)) {
- u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
-
+ (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
__d40_config_set_event(d40c, event_type, event,
D40_CHAN_REG_SSLNK);
- }
-
- if (d40c->dma_cfg.dir != STEDMA40_PERIPH_TO_MEM) {
- u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
+ if (d40c->dma_cfg.dir != STEDMA40_PERIPH_TO_MEM)
__d40_config_set_event(d40c, event_type, event,
D40_CHAN_REG_SDLNK);
- }
}
static u32 d40_chan_has_events(struct d40_chan *d40c)
@@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
struct stedma40_chan_cfg *conf)
{
int res = 0;
- u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
- u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
bool is_log = conf->mode == STEDMA40_MODE_LOGICAL;
if (!conf->dir) {
@@ -1753,44 +1747,26 @@ static int d40_validate_conf(struct d40_chan *d40c,
res = -EINVAL;
}
- if (conf->dst_dev_type != STEDMA40_DEV_DST_MEMORY &&
- d40c->base->plat_data->dev_tx[conf->dst_dev_type] == 0 &&
- d40c->runtime_addr == 0) {
-
- chan_err(d40c, "Invalid TX channel address (%d)\n",
- conf->dst_dev_type);
- res = -EINVAL;
- }
-
- if (conf->src_dev_type != STEDMA40_DEV_SRC_MEMORY &&
- d40c->base->plat_data->dev_rx[conf->src_dev_type] == 0 &&
- d40c->runtime_addr == 0) {
- chan_err(d40c, "Invalid RX channel address (%d)\n",
- conf->src_dev_type);
+ if ((is_log && conf->dev_type > d40c->base->num_log_chans) ||
+ (!is_log && conf->dev_type > d40c->base->num_phy_chans) ||
+ (conf->dev_type < 0)) {
+ chan_err(d40c, "Invalid device type (%d)\n", conf->dev_type);
res = -EINVAL;
}
if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
- dst_event_group == STEDMA40_DEV_DST_MEMORY) {
- chan_err(d40c, "Invalid dst\n");
+ d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
+ d40c->runtime_addr == 0) {
+ chan_err(d40c, "Invalid TX channel address (%d)\n",
+ conf->dev_type);
res = -EINVAL;
}
if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
- src_event_group == STEDMA40_DEV_SRC_MEMORY) {
- chan_err(d40c, "Invalid src\n");
- res = -EINVAL;
- }
-
- if (src_event_group == STEDMA40_DEV_SRC_MEMORY &&
- dst_event_group == STEDMA40_DEV_DST_MEMORY && is_log) {
- chan_err(d40c, "No event line\n");
- res = -EINVAL;
- }
-
- if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
- (src_event_group != dst_event_group)) {
- chan_err(d40c, "Invalid event group\n");
+ d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
+ d40c->runtime_addr == 0) {
+ chan_err(d40c, "Invalid RX channel address (%d)\n",
+ conf->dev_type);
res = -EINVAL;
}
@@ -1911,7 +1887,7 @@ out:
static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
{
- int dev_type;
+ int dev_type = d40c->dma_cfg.dev_type;
int event_group;
int event_line;
struct d40_phy_res *phys;
@@ -1926,13 +1902,11 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
num_phy_chans = d40c->base->num_phy_chans;
if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
- dev_type = d40c->dma_cfg.src_dev_type;
log_num = 2 * dev_type;
is_src = true;
} else if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
/* dst event lines are used for logical memcpy */
- dev_type = d40c->dma_cfg.dst_dev_type;
log_num = 2 * dev_type + 1;
is_src = false;
} else
@@ -2044,8 +2018,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
d40c->dma_cfg = dma40_memcpy_conf_log;
- d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
- d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
+ d40c->dma_cfg.dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
} else if (dma_has_cap(DMA_MEMCPY, cap) &&
dma_has_cap(DMA_SLAVE, cap)) {
@@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
{
int res = 0;
- u32 event;
+ u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
struct d40_phy_res *phy = d40c->phy_chan;
bool is_src;
@@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
}
if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
- d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
+ d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
is_src = false;
- } else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
+ else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
is_src = true;
- } else {
+ else {
chan_err(d40c, "Unknown direction\n");
return -EINVAL;
}
@@ -2128,7 +2099,7 @@ static bool d40_is_paused(struct d40_chan *d40c)
unsigned long flags;
void __iomem *active_reg;
u32 status;
- u32 event;
+ u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
spin_lock_irqsave(&d40c->lock, flags);
@@ -2149,10 +2120,8 @@ static bool d40_is_paused(struct d40_chan *d40c)
if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
status = readl(chanbase + D40_CHAN_REG_SDLNK);
} else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
status = readl(chanbase + D40_CHAN_REG_SSLNK);
} else {
chan_err(d40c, "Unknown direction\n");
@@ -2294,9 +2263,9 @@ d40_get_dev_addr(struct d40_chan *chan, enum dma_transfer_direction direction)
return chan->runtime_addr;
if (direction == DMA_DEV_TO_MEM)
- addr = plat->dev_rx[cfg->src_dev_type];
+ addr = plat->dev_rx[cfg->dev_type];
else if (direction == DMA_MEM_TO_DEV)
- addr = plat->dev_tx[cfg->dst_dev_type];
+ addr = plat->dev_tx[cfg->dev_type];
return addr;
}
@@ -2427,11 +2396,11 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
(d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
- __d40_set_prio_rt(d40c, d40c->dma_cfg.src_dev_type, true);
+ __d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, true);
if ((d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH) ||
(d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
- __d40_set_prio_rt(d40c, d40c->dma_cfg.dst_dev_type, false);
+ __d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
}
/* DMA ENGINE functions */
@@ -2741,7 +2710,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
if (config->direction == DMA_DEV_TO_MEM) {
dma_addr_t dev_addr_rx =
- d40c->base->plat_data->dev_rx[cfg->src_dev_type];
+ d40c->base->plat_data->dev_rx[cfg->dev_type];
config_addr = config->src_addr;
if (dev_addr_rx)
@@ -2764,7 +2733,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
} else if (config->direction == DMA_MEM_TO_DEV) {
dma_addr_t dev_addr_tx =
- d40c->base->plat_data->dev_tx[cfg->dst_dev_type];
+ d40c->base->plat_data->dev_tx[cfg->dev_type];
config_addr = config->dst_addr;
if (dev_addr_tx)
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index 7180e0d..5eb6c10 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -63,7 +63,7 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
(cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
/* Set master port to 1 */
src |= 1 << D40_SREG_CFG_MST_POS;
- src |= D40_TYPE_TO_EVENT(cfg->src_dev_type);
+ src |= D40_TYPE_TO_EVENT(cfg->dev_type);
if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
src |= 1 << D40_SREG_CFG_PHY_TM_POS;
@@ -74,7 +74,7 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
(cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
/* Set master port to 1 */
dst |= 1 << D40_SREG_CFG_MST_POS;
- dst |= D40_TYPE_TO_EVENT(cfg->dst_dev_type);
+ dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 869c571..9e42a67 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -109,8 +109,7 @@ struct stedma40_half_channel_info {
* version 3+, i.e DB8500v2+
* @mode: channel mode: physical, logical, or operation
* @mode_opt: options for the chosen channel mode
- * @src_dev_type: Src device type
- * @dst_dev_type: Dst device type
+ * @dev_type: src/dst device type (driver uses dir to figure out which)
* @src_info: Parameters for dst half channel
* @dst_info: Parameters for dst half channel
* @use_fixed_channel: if true, use physical channel specified by phy_channel
@@ -126,8 +125,7 @@ struct stedma40_chan_cfg {
bool realtime;
enum stedma40_mode mode;
enum stedma40_mode_opt mode_opt;
- int src_dev_type;
- int dst_dev_type;
+ int dev_type;
struct stedma40_half_channel_info src_info;
struct stedma40_half_channel_info dst_info;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
Devices which utilise DMA tend to use the same channel numbers for
transmitting and receiving. For this reason and the fact that it'll
decrease the burden of platform data passed to each device, we're
amalgamating source and destination device types.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500-audio.c | 18 +--
arch/arm/mach-ux500/board-mop500-sdi.c | 24 ++--
arch/arm/mach-ux500/board-mop500.c | 33 ++---
arch/arm/mach-ux500/cpu-db8500.c | 32 ++---
arch/arm/mach-ux500/devices-db8500.c | 120 ++++++++---------
arch/arm/mach-ux500/ste-dma40-db8500.h | 193 ++++++++++-----------------
arch/arm/mach-ux500/usb.c | 10 +-
drivers/dma/ste_dma40.c | 89 ++++--------
drivers/dma/ste_dma40_ll.c | 4 +-
include/linux/platform_data/dma-ste-dma40.h | 6 +-
10 files changed, 205 insertions(+), 324 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index 7209db7..f012cfa 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -24,8 +24,7 @@ static struct stedma40_chan_cfg msp0_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
.src_info.psize = STEDMA40_PSIZE_LOG_4,
.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -37,8 +36,7 @@ static struct stedma40_chan_cfg msp0_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_DST_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX,
+ .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
.src_info.psize = STEDMA40_PSIZE_LOG_4,
.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -56,8 +54,7 @@ static struct stedma40_chan_cfg msp1_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV30_MSP3_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV30_MSP3,
.src_info.psize = STEDMA40_PSIZE_LOG_4,
.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -69,8 +66,7 @@ static struct stedma40_chan_cfg msp1_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_DST_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV30_MSP1_TX,
+ .dev_type = DB8500_DMA_DEV30_MSP1,
.src_info.psize = STEDMA40_PSIZE_LOG_4,
.dst_info.psize = STEDMA40_PSIZE_LOG_4,
@@ -88,8 +84,7 @@ static struct stedma40_chan_cfg msp2_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV14_MSP2_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV14_MSP2,
/* MSP2 DMA doesn't work with PSIZE == 4 on DB8500v2 */
.src_info.psize = STEDMA40_PSIZE_LOG_1,
@@ -102,8 +97,7 @@ static struct stedma40_chan_cfg msp2_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_DST_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV14_MSP2_TX,
+ .dev_type = DB8500_DMA_DEV14_MSP2,
.src_info.psize = STEDMA40_PSIZE_LOG_4,
.dst_info.psize = STEDMA40_PSIZE_LOG_4,
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 7f2cb6c..5c28216 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -64,8 +64,7 @@ static int mop500_sdi0_ios_handler(struct device *dev, struct mmc_ios *ios)
struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV29_SD_MM0_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV29_SD_MM0,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -73,8 +72,7 @@ struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV29_SD_MM0_TX,
+ .dev_type = DB8500_DMA_DEV29_SD_MM0,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -135,8 +133,7 @@ void mop500_sdi_tc35892_init(struct device *parent)
static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV32_SD_MM1_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV32_SD_MM1,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -144,8 +141,7 @@ static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
static struct stedma40_chan_cfg sdi1_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV32_SD_MM1_TX,
+ .dev_type = DB8500_DMA_DEV32_SD_MM1,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -172,8 +168,7 @@ struct mmci_platform_data mop500_sdi1_data = {
struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV28_SD_MM2_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV28_SD_MM2,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -181,8 +176,7 @@ struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
static struct stedma40_chan_cfg mop500_sdi2_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV28_SD_MM2_TX,
+ .dev_type = DB8500_DMA_DEV28_SD_MM2,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -210,8 +204,7 @@ struct mmci_platform_data mop500_sdi2_data = {
struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV42_SD_MM4_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV42_SD_MM4,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
@@ -219,8 +212,7 @@ struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV42_SD_MM4_TX,
+ .dev_type = DB8500_DMA_DEV42_SD_MM4,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
};
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 87d2d7b..a8b3ad9 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -452,8 +452,7 @@ void mop500_snowball_ethernet_clock_enable(void)
static struct cryp_platform_data u8500_cryp1_platform_data = {
.mem_to_engine = {
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV48_CAC1_TX,
+ .dev_type = DB8500_DMA_DEV48_CAC1,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
.mode = STEDMA40_MODE_LOGICAL,
@@ -462,8 +461,7 @@ static struct cryp_platform_data u8500_cryp1_platform_data = {
},
.engine_to_mem = {
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV48_CAC1_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV48_CAC1,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
.mode = STEDMA40_MODE_LOGICAL,
@@ -474,8 +472,7 @@ static struct cryp_platform_data u8500_cryp1_platform_data = {
static struct stedma40_chan_cfg u8500_hash_dma_cfg_tx = {
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV50_HAC1_TX,
+ .dev_type = DB8500_DMA_DEV50_HAC1_TX,
.src_info.data_width = STEDMA40_WORD_WIDTH,
.dst_info.data_width = STEDMA40_WORD_WIDTH,
.mode = STEDMA40_MODE_LOGICAL,
@@ -497,8 +494,7 @@ static struct platform_device *mop500_platform_devs[] __initdata = {
static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV8_SSP0_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV8_SSP0,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -506,8 +502,7 @@ static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
static struct stedma40_chan_cfg ssp0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV8_SSP0_TX,
+ .dev_type = DB8500_DMA_DEV8_SSP0,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -538,8 +533,7 @@ static void __init mop500_spi_init(struct device *parent)
static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV13_UART0_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV13_UART0,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -547,8 +541,7 @@ static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV13_UART0_TX,
+ .dev_type = DB8500_DMA_DEV13_UART0,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -556,8 +549,7 @@ static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV12_UART1_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV12_UART1,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -565,8 +557,7 @@ static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV12_UART1_TX,
+ .dev_type = DB8500_DMA_DEV12_UART1,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -574,8 +565,7 @@ static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
- .src_dev_type = DB8500_DMA_DEV11_UART2_RX,
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .dev_type = DB8500_DMA_DEV11_UART2,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
@@ -583,8 +573,7 @@ static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
static struct stedma40_chan_cfg uart2_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
- .dst_dev_type = DB8500_DMA_DEV11_UART2_TX,
+ .dev_type = DB8500_DMA_DEV11_UART2,
.src_info.data_width = STEDMA40_BYTE_WIDTH,
.dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index e027865..f72cc9b 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -167,25 +167,25 @@ static void __init db8500_add_gpios(struct device *parent)
}
static int usb_db8500_rx_dma_cfg[] = {
- DB8500_DMA_DEV38_USB_OTG_IEP_1_9,
- DB8500_DMA_DEV37_USB_OTG_IEP_2_10,
- DB8500_DMA_DEV36_USB_OTG_IEP_3_11,
- DB8500_DMA_DEV19_USB_OTG_IEP_4_12,
- DB8500_DMA_DEV18_USB_OTG_IEP_5_13,
- DB8500_DMA_DEV17_USB_OTG_IEP_6_14,
- DB8500_DMA_DEV16_USB_OTG_IEP_7_15,
- DB8500_DMA_DEV39_USB_OTG_IEP_8
+ DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
+ DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
+ DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
+ DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
+ DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
+ DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
+ DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
+ DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
};
static int usb_db8500_tx_dma_cfg[] = {
- DB8500_DMA_DEV38_USB_OTG_OEP_1_9,
- DB8500_DMA_DEV37_USB_OTG_OEP_2_10,
- DB8500_DMA_DEV36_USB_OTG_OEP_3_11,
- DB8500_DMA_DEV19_USB_OTG_OEP_4_12,
- DB8500_DMA_DEV18_USB_OTG_OEP_5_13,
- DB8500_DMA_DEV17_USB_OTG_OEP_6_14,
- DB8500_DMA_DEV16_USB_OTG_OEP_7_15,
- DB8500_DMA_DEV39_USB_OTG_OEP_8
+ DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
+ DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
+ DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
+ DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
+ DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
+ DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
+ DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
+ DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
};
static const char *db8500_read_soc_id(void)
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 5b1f1f7..03efd4c1 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -50,74 +50,74 @@ static struct resource dma40_resources[] = {
*/
static const dma_addr_t dma40_tx_map[DB8500_DMA_NR_DEV] = {
/* MUSB - these will be runtime-reconfigured */
- [DB8500_DMA_DEV39_USB_OTG_OEP_8] = -1,
- [DB8500_DMA_DEV16_USB_OTG_OEP_7_15] = -1,
- [DB8500_DMA_DEV17_USB_OTG_OEP_6_14] = -1,
- [DB8500_DMA_DEV18_USB_OTG_OEP_5_13] = -1,
- [DB8500_DMA_DEV19_USB_OTG_OEP_4_12] = -1,
- [DB8500_DMA_DEV36_USB_OTG_OEP_3_11] = -1,
- [DB8500_DMA_DEV37_USB_OTG_OEP_2_10] = -1,
- [DB8500_DMA_DEV38_USB_OTG_OEP_1_9] = -1,
+ [DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8] = -1,
+ [DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15] = -1,
+ [DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14] = -1,
+ [DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13] = -1,
+ [DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12] = -1,
+ [DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11] = -1,
+ [DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10] = -1,
+ [DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9] = -1,
/* PrimeCells - run-time configured */
- [DB8500_DMA_DEV0_SPI0_TX] = -1,
- [DB8500_DMA_DEV1_SD_MMC0_TX] = -1,
- [DB8500_DMA_DEV2_SD_MMC1_TX] = -1,
- [DB8500_DMA_DEV3_SD_MMC2_TX] = -1,
- [DB8500_DMA_DEV8_SSP0_TX] = -1,
- [DB8500_DMA_DEV9_SSP1_TX] = -1,
- [DB8500_DMA_DEV11_UART2_TX] = -1,
- [DB8500_DMA_DEV12_UART1_TX] = -1,
- [DB8500_DMA_DEV13_UART0_TX] = -1,
- [DB8500_DMA_DEV28_SD_MM2_TX] = -1,
- [DB8500_DMA_DEV29_SD_MM0_TX] = -1,
- [DB8500_DMA_DEV32_SD_MM1_TX] = -1,
- [DB8500_DMA_DEV33_SPI2_TX] = -1,
- [DB8500_DMA_DEV35_SPI1_TX] = -1,
- [DB8500_DMA_DEV40_SPI3_TX] = -1,
- [DB8500_DMA_DEV41_SD_MM3_TX] = -1,
- [DB8500_DMA_DEV42_SD_MM4_TX] = -1,
- [DB8500_DMA_DEV43_SD_MM5_TX] = -1,
- [DB8500_DMA_DEV14_MSP2_TX] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV30_MSP1_TX] = U8500_MSP1_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV48_CAC1_TX] = U8500_CRYP1_BASE + CRYP1_TX_REG_OFFSET,
+ [DB8500_DMA_DEV0_SPI0] = -1,
+ [DB8500_DMA_DEV1_SD_MMC0] = -1,
+ [DB8500_DMA_DEV2_SD_MMC1] = -1,
+ [DB8500_DMA_DEV3_SD_MMC2] = -1,
+ [DB8500_DMA_DEV8_SSP0] = -1,
+ [DB8500_DMA_DEV9_SSP1] = -1,
+ [DB8500_DMA_DEV11_UART2] = -1,
+ [DB8500_DMA_DEV12_UART1] = -1,
+ [DB8500_DMA_DEV13_UART0] = -1,
+ [DB8500_DMA_DEV28_SD_MM2] = -1,
+ [DB8500_DMA_DEV29_SD_MM0] = -1,
+ [DB8500_DMA_DEV32_SD_MM1] = -1,
+ [DB8500_DMA_DEV33_SPI2] = -1,
+ [DB8500_DMA_DEV35_SPI1] = -1,
+ [DB8500_DMA_DEV40_SPI3] = -1,
+ [DB8500_DMA_DEV41_SD_MM3] = -1,
+ [DB8500_DMA_DEV42_SD_MM4] = -1,
+ [DB8500_DMA_DEV43_SD_MM5] = -1,
+ [DB8500_DMA_DEV14_MSP2] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV30_MSP1] = U8500_MSP1_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV31_MSP0_SLIM0_CH0] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV48_CAC1] = U8500_CRYP1_BASE + CRYP1_TX_REG_OFFSET,
[DB8500_DMA_DEV50_HAC1_TX] = U8500_HASH1_BASE + HASH1_TX_REG_OFFSET,
};
/* Mapping between source event lines and physical device address */
static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
/* MUSB - these will be runtime-reconfigured */
- [DB8500_DMA_DEV39_USB_OTG_IEP_8] = -1,
- [DB8500_DMA_DEV16_USB_OTG_IEP_7_15] = -1,
- [DB8500_DMA_DEV17_USB_OTG_IEP_6_14] = -1,
- [DB8500_DMA_DEV18_USB_OTG_IEP_5_13] = -1,
- [DB8500_DMA_DEV19_USB_OTG_IEP_4_12] = -1,
- [DB8500_DMA_DEV36_USB_OTG_IEP_3_11] = -1,
- [DB8500_DMA_DEV37_USB_OTG_IEP_2_10] = -1,
- [DB8500_DMA_DEV38_USB_OTG_IEP_1_9] = -1,
+ [DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8] = -1,
+ [DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15] = -1,
+ [DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14] = -1,
+ [DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13] = -1,
+ [DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12] = -1,
+ [DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11] = -1,
+ [DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10] = -1,
+ [DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9] = -1,
/* PrimeCells */
- [DB8500_DMA_DEV0_SPI0_RX] = -1,
- [DB8500_DMA_DEV1_SD_MMC0_RX] = -1,
- [DB8500_DMA_DEV2_SD_MMC1_RX] = -1,
- [DB8500_DMA_DEV3_SD_MMC2_RX] = -1,
- [DB8500_DMA_DEV8_SSP0_RX] = -1,
- [DB8500_DMA_DEV9_SSP1_RX] = -1,
- [DB8500_DMA_DEV11_UART2_RX] = -1,
- [DB8500_DMA_DEV12_UART1_RX] = -1,
- [DB8500_DMA_DEV13_UART0_RX] = -1,
- [DB8500_DMA_DEV28_SD_MM2_RX] = -1,
- [DB8500_DMA_DEV29_SD_MM0_RX] = -1,
- [DB8500_DMA_DEV32_SD_MM1_RX] = -1,
- [DB8500_DMA_DEV33_SPI2_RX] = -1,
- [DB8500_DMA_DEV35_SPI1_RX] = -1,
- [DB8500_DMA_DEV40_SPI3_RX] = -1,
- [DB8500_DMA_DEV41_SD_MM3_RX] = -1,
- [DB8500_DMA_DEV42_SD_MM4_RX] = -1,
- [DB8500_DMA_DEV43_SD_MM5_RX] = -1,
- [DB8500_DMA_DEV14_MSP2_RX] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV30_MSP3_RX] = U8500_MSP3_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
- [DB8500_DMA_DEV48_CAC1_RX] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
+ [DB8500_DMA_DEV0_SPI0] = -1,
+ [DB8500_DMA_DEV1_SD_MMC0] = -1,
+ [DB8500_DMA_DEV2_SD_MMC1] = -1,
+ [DB8500_DMA_DEV3_SD_MMC2] = -1,
+ [DB8500_DMA_DEV8_SSP0] = -1,
+ [DB8500_DMA_DEV9_SSP1] = -1,
+ [DB8500_DMA_DEV11_UART2] = -1,
+ [DB8500_DMA_DEV12_UART1] = -1,
+ [DB8500_DMA_DEV13_UART0] = -1,
+ [DB8500_DMA_DEV28_SD_MM2] = -1,
+ [DB8500_DMA_DEV29_SD_MM0] = -1,
+ [DB8500_DMA_DEV32_SD_MM1] = -1,
+ [DB8500_DMA_DEV33_SPI2] = -1,
+ [DB8500_DMA_DEV35_SPI1] = -1,
+ [DB8500_DMA_DEV40_SPI3] = -1,
+ [DB8500_DMA_DEV41_SD_MM3] = -1,
+ [DB8500_DMA_DEV42_SD_MM4] = -1,
+ [DB8500_DMA_DEV43_SD_MM5] = -1,
+ [DB8500_DMA_DEV14_MSP2] = U8500_MSP2_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV30_MSP3] = U8500_MSP3_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV31_MSP0_SLIM0_CH0] = U8500_MSP0_BASE + MSP_TX_RX_REG_OFFSET,
+ [DB8500_DMA_DEV48_CAC1] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
};
static struct stedma40_platform_data dma40_plat_data = {
diff --git a/arch/arm/mach-ux500/ste-dma40-db8500.h b/arch/arm/mach-ux500/ste-dma40-db8500.h
index a616419..0296ae5 100644
--- a/arch/arm/mach-ux500/ste-dma40-db8500.h
+++ b/arch/arm/mach-ux500/ste-dma40-db8500.h
@@ -12,133 +12,74 @@
#define DB8500_DMA_NR_DEV 64
-enum dma_src_dev_type {
- DB8500_DMA_DEV0_SPI0_RX = 0,
- DB8500_DMA_DEV1_SD_MMC0_RX = 1,
- DB8500_DMA_DEV2_SD_MMC1_RX = 2,
- DB8500_DMA_DEV3_SD_MMC2_RX = 3,
- DB8500_DMA_DEV4_I2C1_RX = 4,
- DB8500_DMA_DEV5_I2C3_RX = 5,
- DB8500_DMA_DEV6_I2C2_RX = 6,
- DB8500_DMA_DEV7_I2C4_RX = 7, /* Only on V1 and later */
- DB8500_DMA_DEV8_SSP0_RX = 8,
- DB8500_DMA_DEV9_SSP1_RX = 9,
- DB8500_DMA_DEV10_MCDE_RX = 10,
- DB8500_DMA_DEV11_UART2_RX = 11,
- DB8500_DMA_DEV12_UART1_RX = 12,
- DB8500_DMA_DEV13_UART0_RX = 13,
- DB8500_DMA_DEV14_MSP2_RX = 14,
- DB8500_DMA_DEV15_I2C0_RX = 15,
- DB8500_DMA_DEV16_USB_OTG_IEP_7_15 = 16,
- DB8500_DMA_DEV17_USB_OTG_IEP_6_14 = 17,
- DB8500_DMA_DEV18_USB_OTG_IEP_5_13 = 18,
- DB8500_DMA_DEV19_USB_OTG_IEP_4_12 = 19,
- DB8500_DMA_DEV20_SLIM0_CH0_RX_HSI_RX_CH0 = 20,
- DB8500_DMA_DEV21_SLIM0_CH1_RX_HSI_RX_CH1 = 21,
- DB8500_DMA_DEV22_SLIM0_CH2_RX_HSI_RX_CH2 = 22,
- DB8500_DMA_DEV23_SLIM0_CH3_RX_HSI_RX_CH3 = 23,
- DB8500_DMA_DEV24_SRC_SXA0_RX_TX = 24,
- DB8500_DMA_DEV25_SRC_SXA1_RX_TX = 25,
- DB8500_DMA_DEV26_SRC_SXA2_RX_TX = 26,
- DB8500_DMA_DEV27_SRC_SXA3_RX_TX = 27,
- DB8500_DMA_DEV28_SD_MM2_RX = 28,
- DB8500_DMA_DEV29_SD_MM0_RX = 29,
- DB8500_DMA_DEV30_MSP1_RX = 30,
+/*
+ * Unless otherwise specified, all channels numbers are used for
+ * TX & RX, and can be used for either source or destination
+ * channels.
+ */
+enum dma_dev_type {
+ DB8500_DMA_DEV0_SPI0 = 0,
+ DB8500_DMA_DEV1_SD_MMC0 = 1,
+ DB8500_DMA_DEV2_SD_MMC1 = 2,
+ DB8500_DMA_DEV3_SD_MMC2 = 3,
+ DB8500_DMA_DEV4_I2C1 = 4,
+ DB8500_DMA_DEV5_I2C3 = 5,
+ DB8500_DMA_DEV6_I2C2 = 6,
+ DB8500_DMA_DEV7_I2C4 = 7, /* Only on V1 and later */
+ DB8500_DMA_DEV8_SSP0 = 8,
+ DB8500_DMA_DEV9_SSP1 = 9,
+ DB8500_DMA_DEV10_MCDE_RX = 10, /* RX only */
+ DB8500_DMA_DEV11_UART2 = 11,
+ DB8500_DMA_DEV12_UART1 = 12,
+ DB8500_DMA_DEV13_UART0 = 13,
+ DB8500_DMA_DEV14_MSP2 = 14,
+ DB8500_DMA_DEV15_I2C0 = 15,
+ DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15 = 16,
+ DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14 = 17,
+ DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13 = 18,
+ DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12 = 19,
+ DB8500_DMA_DEV20_SLIM0_CH0_HSI_CH0 = 20,
+ DB8500_DMA_DEV21_SLIM0_CH1_HSI_CH1 = 21,
+ DB8500_DMA_DEV22_SLIM0_CH2_HSI_CH2 = 22,
+ DB8500_DMA_DEV23_SLIM0_CH3_HSI_CH3 = 23,
+ DB8500_DMA_DEV24_SXA0 = 24,
+ DB8500_DMA_DEV25_SXA1 = 25,
+ DB8500_DMA_DEV26_SXA2 = 26,
+ DB8500_DMA_DEV27_SXA3 = 27,
+ DB8500_DMA_DEV28_SD_MM2 = 28,
+ DB8500_DMA_DEV29_SD_MM0 = 29,
+ DB8500_DMA_DEV30_MSP1 = 30,
/* On DB8500v2, MSP3 RX replaces MSP1 RX */
- DB8500_DMA_DEV30_MSP3_RX = 30,
- DB8500_DMA_DEV31_MSP0_RX_SLIM0_CH0_RX = 31,
- DB8500_DMA_DEV32_SD_MM1_RX = 32,
- DB8500_DMA_DEV33_SPI2_RX = 33,
- DB8500_DMA_DEV34_I2C3_RX2 = 34,
- DB8500_DMA_DEV35_SPI1_RX = 35,
- DB8500_DMA_DEV36_USB_OTG_IEP_3_11 = 36,
- DB8500_DMA_DEV37_USB_OTG_IEP_2_10 = 37,
- DB8500_DMA_DEV38_USB_OTG_IEP_1_9 = 38,
- DB8500_DMA_DEV39_USB_OTG_IEP_8 = 39,
- DB8500_DMA_DEV40_SPI3_RX = 40,
- DB8500_DMA_DEV41_SD_MM3_RX = 41,
- DB8500_DMA_DEV42_SD_MM4_RX = 42,
- DB8500_DMA_DEV43_SD_MM5_RX = 43,
- DB8500_DMA_DEV44_SRC_SXA4_RX_TX = 44,
- DB8500_DMA_DEV45_SRC_SXA5_RX_TX = 45,
- DB8500_DMA_DEV46_SLIM0_CH8_RX_SRC_SXA6_RX_TX = 46,
- DB8500_DMA_DEV47_SLIM0_CH9_RX_SRC_SXA7_RX_TX = 47,
- DB8500_DMA_DEV48_CAC1_RX = 48,
- /* 49, 50 and 51 are not used */
- DB8500_DMA_DEV52_SLIM0_CH4_RX_HSI_RX_CH4 = 52,
- DB8500_DMA_DEV53_SLIM0_CH5_RX_HSI_RX_CH5 = 53,
- DB8500_DMA_DEV54_SLIM0_CH6_RX_HSI_RX_CH6 = 54,
- DB8500_DMA_DEV55_SLIM0_CH7_RX_HSI_RX_CH7 = 55,
- /* 56, 57, 58, 59 and 60 are not used */
- DB8500_DMA_DEV61_CAC0_RX = 61,
- /* 62 and 63 are not used */
-};
-
-enum dma_dest_dev_type {
- DB8500_DMA_DEV0_SPI0_TX = 0,
- DB8500_DMA_DEV1_SD_MMC0_TX = 1,
- DB8500_DMA_DEV2_SD_MMC1_TX = 2,
- DB8500_DMA_DEV3_SD_MMC2_TX = 3,
- DB8500_DMA_DEV4_I2C1_TX = 4,
- DB8500_DMA_DEV5_I2C3_TX = 5,
- DB8500_DMA_DEV6_I2C2_TX = 6,
- DB8500_DMA_DEV7_I2C4_TX = 7, /* Only on V1 and later */
- DB8500_DMA_DEV8_SSP0_TX = 8,
- DB8500_DMA_DEV9_SSP1_TX = 9,
- /* 10 is not used*/
- DB8500_DMA_DEV11_UART2_TX = 11,
- DB8500_DMA_DEV12_UART1_TX = 12,
- DB8500_DMA_DEV13_UART0_TX = 13,
- DB8500_DMA_DEV14_MSP2_TX = 14,
- DB8500_DMA_DEV15_I2C0_TX = 15,
- DB8500_DMA_DEV16_USB_OTG_OEP_7_15 = 16,
- DB8500_DMA_DEV17_USB_OTG_OEP_6_14 = 17,
- DB8500_DMA_DEV18_USB_OTG_OEP_5_13 = 18,
- DB8500_DMA_DEV19_USB_OTG_OEP_4_12 = 19,
- DB8500_DMA_DEV20_SLIM0_CH0_TX_HSI_TX_CH0 = 20,
- DB8500_DMA_DEV21_SLIM0_CH1_TX_HSI_TX_CH1 = 21,
- DB8500_DMA_DEV22_SLIM0_CH2_TX_HSI_TX_CH2 = 22,
- DB8500_DMA_DEV23_SLIM0_CH3_TX_HSI_TX_CH3 = 23,
- DB8500_DMA_DEV24_DST_SXA0_RX_TX = 24,
- DB8500_DMA_DEV25_DST_SXA1_RX_TX = 25,
- DB8500_DMA_DEV26_DST_SXA2_RX_TX = 26,
- DB8500_DMA_DEV27_DST_SXA3_RX_TX = 27,
- DB8500_DMA_DEV28_SD_MM2_TX = 28,
- DB8500_DMA_DEV29_SD_MM0_TX = 29,
- DB8500_DMA_DEV30_MSP1_TX = 30,
- DB8500_DMA_DEV31_MSP0_TX_SLIM0_CH0_TX = 31,
- DB8500_DMA_DEV32_SD_MM1_TX = 32,
- DB8500_DMA_DEV33_SPI2_TX = 33,
- DB8500_DMA_DEV34_I2C3_TX2 = 34,
- DB8500_DMA_DEV35_SPI1_TX = 35,
- DB8500_DMA_DEV36_USB_OTG_OEP_3_11 = 36,
- DB8500_DMA_DEV37_USB_OTG_OEP_2_10 = 37,
- DB8500_DMA_DEV38_USB_OTG_OEP_1_9 = 38,
- DB8500_DMA_DEV39_USB_OTG_OEP_8 = 39,
- DB8500_DMA_DEV40_SPI3_TX = 40,
- DB8500_DMA_DEV41_SD_MM3_TX = 41,
- DB8500_DMA_DEV42_SD_MM4_TX = 42,
- DB8500_DMA_DEV43_SD_MM5_TX = 43,
- DB8500_DMA_DEV44_DST_SXA4_RX_TX = 44,
- DB8500_DMA_DEV45_DST_SXA5_RX_TX = 45,
- DB8500_DMA_DEV46_SLIM0_CH8_TX_DST_SXA6_RX_TX = 46,
- DB8500_DMA_DEV47_SLIM0_CH9_TX_DST_SXA7_RX_TX = 47,
- DB8500_DMA_DEV48_CAC1_TX = 48,
- DB8500_DMA_DEV49_CAC1_TX_HAC1_TX = 49,
- DB8500_DMA_DEV50_HAC1_TX = 50,
- DB8500_DMA_MEMCPY_TX_0 = 51,
- DB8500_DMA_DEV52_SLIM1_CH4_TX_HSI_TX_CH4 = 52,
- DB8500_DMA_DEV53_SLIM1_CH5_TX_HSI_TX_CH5 = 53,
- DB8500_DMA_DEV54_SLIM1_CH6_TX_HSI_TX_CH6 = 54,
- DB8500_DMA_DEV55_SLIM1_CH7_TX_HSI_TX_CH7 = 55,
- DB8500_DMA_MEMCPY_TX_1 = 56,
- DB8500_DMA_MEMCPY_TX_2 = 57,
- DB8500_DMA_MEMCPY_TX_3 = 58,
- DB8500_DMA_MEMCPY_TX_4 = 59,
- DB8500_DMA_MEMCPY_TX_5 = 60,
- DB8500_DMA_DEV61_CAC0_TX = 61,
- DB8500_DMA_DEV62_CAC0_TX_HAC0_TX = 62,
- DB8500_DMA_DEV63_HAC0_TX = 63,
+ DB8500_DMA_DEV30_MSP3 = 30,
+ DB8500_DMA_DEV31_MSP0_SLIM0_CH0 = 31,
+ DB8500_DMA_DEV32_SD_MM1 = 32,
+ DB8500_DMA_DEV33_SPI2 = 33,
+ DB8500_DMA_DEV34_I2C3_RX2_TX2 = 34,
+ DB8500_DMA_DEV35_SPI1 = 35,
+ DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11 = 36,
+ DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10 = 37,
+ DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9 = 38,
+ DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8 = 39,
+ DB8500_DMA_DEV40_SPI3 = 40,
+ DB8500_DMA_DEV41_SD_MM3 = 41,
+ DB8500_DMA_DEV42_SD_MM4 = 42,
+ DB8500_DMA_DEV43_SD_MM5 = 43,
+ DB8500_DMA_DEV44_SXA4 = 44,
+ DB8500_DMA_DEV45_SXA5 = 45,
+ DB8500_DMA_DEV46_SLIM0_CH8_SRC_SXA6 = 46,
+ DB8500_DMA_DEV47_SLIM0_CH9_SRC_SXA7 = 47,
+ DB8500_DMA_DEV48_CAC1 = 48,
+ DB8500_DMA_DEV49_CAC1_TX_HAC1_TX = 49, /* TX only */
+ DB8500_DMA_DEV50_HAC1_TX = 50, /* TX only */
+ DB8500_DMA_MEMCPY_TX_0 = 51, /* TX only */
+ DB8500_DMA_DEV52_SLIM0_CH4_HSI_CH4 = 52,
+ DB8500_DMA_DEV53_SLIM0_CH5_HSI_CH5 = 53,
+ DB8500_DMA_DEV54_SLIM0_CH6_HSI_CH6 = 54,
+ DB8500_DMA_DEV55_SLIM0_CH7_HSI_CH7 = 55,
+ /* 56 -> 60 are channels reserved for memcpy only */
+ DB8500_DMA_DEV61_CAC0 = 61,
+ DB8500_DMA_DEV62_CAC0_TX_HAC0_TX = 62, /* TX only */
+ DB8500_DMA_DEV63_HAC0_TX = 63, /* TX only */
};
#endif
diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
index 78ac65f..e0ea490 100644
--- a/arch/arm/mach-ux500/usb.c
+++ b/arch/arm/mach-ux500/usb.c
@@ -15,7 +15,6 @@
#define MUSB_DMA40_RX_CH { \
.mode = STEDMA40_MODE_LOGICAL, \
.dir = STEDMA40_PERIPH_TO_MEM, \
- .dst_dev_type = STEDMA40_DEV_DST_MEMORY, \
.src_info.data_width = STEDMA40_WORD_WIDTH, \
.dst_info.data_width = STEDMA40_WORD_WIDTH, \
.src_info.psize = STEDMA40_PSIZE_LOG_16, \
@@ -25,7 +24,6 @@
#define MUSB_DMA40_TX_CH { \
.mode = STEDMA40_MODE_LOGICAL, \
.dir = STEDMA40_MEM_TO_PERIPH, \
- .src_dev_type = STEDMA40_DEV_SRC_MEMORY, \
.src_info.data_width = STEDMA40_WORD_WIDTH, \
.dst_info.data_width = STEDMA40_WORD_WIDTH, \
.src_info.psize = STEDMA40_PSIZE_LOG_16, \
@@ -125,20 +123,20 @@ struct platform_device ux500_musb_device = {
.resource = usb_resources,
};
-static inline void ux500_usb_dma_update_rx_ch_config(int *src_dev_type)
+static inline void ux500_usb_dma_update_rx_ch_config(int *dev_type)
{
u32 idx;
for (idx = 0; idx < UX500_MUSB_DMA_NUM_RX_CHANNELS; idx++)
- musb_dma_rx_ch[idx].src_dev_type = src_dev_type[idx];
+ musb_dma_rx_ch[idx].dev_type = dev_type[idx];
}
-static inline void ux500_usb_dma_update_tx_ch_config(int *dst_dev_type)
+static inline void ux500_usb_dma_update_tx_ch_config(int *dev_type)
{
u32 idx;
for (idx = 0; idx < UX500_MUSB_DMA_NUM_TX_CHANNELS; idx++)
- musb_dma_tx_ch[idx].dst_dev_type = dst_dev_type[idx];
+ musb_dma_tx_ch[idx].dev_type = dev_type[idx];
}
void ux500_add_usb(struct device *parent, resource_size_t base, int irq,
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 121c46b..e50354d 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -1288,21 +1288,17 @@ static void __d40_config_set_event(struct d40_chan *d40c,
static void d40_config_set_event(struct d40_chan *d40c,
enum d40_events event_type)
{
+ u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
+
/* Enable event line connected to device (or memcpy) */
if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
- (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH)) {
- u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
-
+ (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
__d40_config_set_event(d40c, event_type, event,
D40_CHAN_REG_SSLNK);
- }
-
- if (d40c->dma_cfg.dir != STEDMA40_PERIPH_TO_MEM) {
- u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
+ if (d40c->dma_cfg.dir != STEDMA40_PERIPH_TO_MEM)
__d40_config_set_event(d40c, event_type, event,
D40_CHAN_REG_SDLNK);
- }
}
static u32 d40_chan_has_events(struct d40_chan *d40c)
@@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
struct stedma40_chan_cfg *conf)
{
int res = 0;
- u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
- u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
bool is_log = conf->mode == STEDMA40_MODE_LOGICAL;
if (!conf->dir) {
@@ -1753,44 +1747,26 @@ static int d40_validate_conf(struct d40_chan *d40c,
res = -EINVAL;
}
- if (conf->dst_dev_type != STEDMA40_DEV_DST_MEMORY &&
- d40c->base->plat_data->dev_tx[conf->dst_dev_type] == 0 &&
- d40c->runtime_addr == 0) {
-
- chan_err(d40c, "Invalid TX channel address (%d)\n",
- conf->dst_dev_type);
- res = -EINVAL;
- }
-
- if (conf->src_dev_type != STEDMA40_DEV_SRC_MEMORY &&
- d40c->base->plat_data->dev_rx[conf->src_dev_type] == 0 &&
- d40c->runtime_addr == 0) {
- chan_err(d40c, "Invalid RX channel address (%d)\n",
- conf->src_dev_type);
+ if ((is_log && conf->dev_type > d40c->base->num_log_chans) ||
+ (!is_log && conf->dev_type > d40c->base->num_phy_chans) ||
+ (conf->dev_type < 0)) {
+ chan_err(d40c, "Invalid device type (%d)\n", conf->dev_type);
res = -EINVAL;
}
if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
- dst_event_group == STEDMA40_DEV_DST_MEMORY) {
- chan_err(d40c, "Invalid dst\n");
+ d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
+ d40c->runtime_addr == 0) {
+ chan_err(d40c, "Invalid TX channel address (%d)\n",
+ conf->dev_type);
res = -EINVAL;
}
if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
- src_event_group == STEDMA40_DEV_SRC_MEMORY) {
- chan_err(d40c, "Invalid src\n");
- res = -EINVAL;
- }
-
- if (src_event_group == STEDMA40_DEV_SRC_MEMORY &&
- dst_event_group == STEDMA40_DEV_DST_MEMORY && is_log) {
- chan_err(d40c, "No event line\n");
- res = -EINVAL;
- }
-
- if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
- (src_event_group != dst_event_group)) {
- chan_err(d40c, "Invalid event group\n");
+ d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
+ d40c->runtime_addr == 0) {
+ chan_err(d40c, "Invalid RX channel address (%d)\n",
+ conf->dev_type);
res = -EINVAL;
}
@@ -1911,7 +1887,7 @@ out:
static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
{
- int dev_type;
+ int dev_type = d40c->dma_cfg.dev_type;
int event_group;
int event_line;
struct d40_phy_res *phys;
@@ -1926,13 +1902,11 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
num_phy_chans = d40c->base->num_phy_chans;
if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
- dev_type = d40c->dma_cfg.src_dev_type;
log_num = 2 * dev_type;
is_src = true;
} else if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
/* dst event lines are used for logical memcpy */
- dev_type = d40c->dma_cfg.dst_dev_type;
log_num = 2 * dev_type + 1;
is_src = false;
} else
@@ -2044,8 +2018,7 @@ static int d40_config_memcpy(struct d40_chan *d40c)
if (dma_has_cap(DMA_MEMCPY, cap) && !dma_has_cap(DMA_SLAVE, cap)) {
d40c->dma_cfg = dma40_memcpy_conf_log;
- d40c->dma_cfg.src_dev_type = STEDMA40_DEV_SRC_MEMORY;
- d40c->dma_cfg.dst_dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
+ d40c->dma_cfg.dev_type = dma40_memcpy_channels[d40c->chan.chan_id];
} else if (dma_has_cap(DMA_MEMCPY, cap) &&
dma_has_cap(DMA_SLAVE, cap)) {
@@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
{
int res = 0;
- u32 event;
+ u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
struct d40_phy_res *phy = d40c->phy_chan;
bool is_src;
@@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
}
if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
- d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
+ d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
is_src = false;
- } else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
+ else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
is_src = true;
- } else {
+ else {
chan_err(d40c, "Unknown direction\n");
return -EINVAL;
}
@@ -2128,7 +2099,7 @@ static bool d40_is_paused(struct d40_chan *d40c)
unsigned long flags;
void __iomem *active_reg;
u32 status;
- u32 event;
+ u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
spin_lock_irqsave(&d40c->lock, flags);
@@ -2149,10 +2120,8 @@ static bool d40_is_paused(struct d40_chan *d40c)
if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
status = readl(chanbase + D40_CHAN_REG_SDLNK);
} else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
status = readl(chanbase + D40_CHAN_REG_SSLNK);
} else {
chan_err(d40c, "Unknown direction\n");
@@ -2294,9 +2263,9 @@ d40_get_dev_addr(struct d40_chan *chan, enum dma_transfer_direction direction)
return chan->runtime_addr;
if (direction == DMA_DEV_TO_MEM)
- addr = plat->dev_rx[cfg->src_dev_type];
+ addr = plat->dev_rx[cfg->dev_type];
else if (direction == DMA_MEM_TO_DEV)
- addr = plat->dev_tx[cfg->dst_dev_type];
+ addr = plat->dev_tx[cfg->dev_type];
return addr;
}
@@ -2427,11 +2396,11 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
(d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
- __d40_set_prio_rt(d40c, d40c->dma_cfg.src_dev_type, true);
+ __d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, true);
if ((d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH) ||
(d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
- __d40_set_prio_rt(d40c, d40c->dma_cfg.dst_dev_type, false);
+ __d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
}
/* DMA ENGINE functions */
@@ -2741,7 +2710,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
if (config->direction == DMA_DEV_TO_MEM) {
dma_addr_t dev_addr_rx =
- d40c->base->plat_data->dev_rx[cfg->src_dev_type];
+ d40c->base->plat_data->dev_rx[cfg->dev_type];
config_addr = config->src_addr;
if (dev_addr_rx)
@@ -2764,7 +2733,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
} else if (config->direction == DMA_MEM_TO_DEV) {
dma_addr_t dev_addr_tx =
- d40c->base->plat_data->dev_tx[cfg->dst_dev_type];
+ d40c->base->plat_data->dev_tx[cfg->dev_type];
config_addr = config->dst_addr;
if (dev_addr_tx)
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index 7180e0d..5eb6c10 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -63,7 +63,7 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
(cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
/* Set master port to 1 */
src |= 1 << D40_SREG_CFG_MST_POS;
- src |= D40_TYPE_TO_EVENT(cfg->src_dev_type);
+ src |= D40_TYPE_TO_EVENT(cfg->dev_type);
if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
src |= 1 << D40_SREG_CFG_PHY_TM_POS;
@@ -74,7 +74,7 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
(cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
/* Set master port to 1 */
dst |= 1 << D40_SREG_CFG_MST_POS;
- dst |= D40_TYPE_TO_EVENT(cfg->dst_dev_type);
+ dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 869c571..9e42a67 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -109,8 +109,7 @@ struct stedma40_half_channel_info {
* version 3+, i.e DB8500v2+
* @mode: channel mode: physical, logical, or operation
* @mode_opt: options for the chosen channel mode
- * @src_dev_type: Src device type
- * @dst_dev_type: Dst device type
+ * @dev_type: src/dst device type (driver uses dir to figure out which)
* @src_info: Parameters for dst half channel
* @dst_info: Parameters for dst half channel
* @use_fixed_channel: if true, use physical channel specified by phy_channel
@@ -126,8 +125,7 @@ struct stedma40_chan_cfg {
bool realtime;
enum stedma40_mode mode;
enum stedma40_mode_opt mode_opt;
- int src_dev_type;
- int dst_dev_type;
+ int dev_type;
struct stedma40_half_channel_info src_info;
struct stedma40_half_channel_info dst_info;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 8:06 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:06 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Devices which utilise DMA tend to use the same channel numbers for
> transmitting and receiving. For this reason and the fact that it'll
> decrease the burden of platform data passed to each device, we're
> amalgamating source and destination device types.
I don't think this explains what the patch is actually doing.
Instead describe this:
> @@ -56,8 +54,7 @@ static struct stedma40_chan_cfg msp1_dma_rx = {
> .high_priority = true,
> .dir = STEDMA40_PERIPH_TO_MEM,
>
> - .src_dev_type = DB8500_DMA_DEV30_MSP3_RX,
> - .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
> + .dev_type = DB8500_DMA_DEV30_MSP3,
(...)
What the message should say is that we're encoding pairs of
information for sources and destinations. Since every such
entry contains a .dir entry stating the direction of the transfer
it is implicit whether the channel is for RX or TX and this is what
you're exploiting in this patch.
So channel numbers (as mentioned in the commit) is not
the key issue here.
Now we should ask ourselves why it was done like this from
the beginning. The reason is that DMA40 supports device-to-device
DMA, so if you encoded one device in .src_dev_type and another
device in .dst_dev_type and set .dir to
STEDMA40_PERIPH_TO_PERIPH (which as you can see is
defined in <linux/platform_data/dma-ste-dma40.h>) you get a
device to device transfer.
Are we now sacrificing that ability on the altar of simplification?
I actually think not, but that we should do periph-to-periph transfers
in some other way, and that the .dir attribute should go away from
the struct stedma40_chan_cfg as well but I'm not entirely sure.
Someone else?
(...)
> +++ b/arch/arm/mach-ux500/cpu-db8500.c
> @@ -167,25 +167,25 @@ static void __init db8500_add_gpios(struct device *parent)
> }
>
> static int usb_db8500_rx_dma_cfg[] = {
> - DB8500_DMA_DEV38_USB_OTG_IEP_1_9,
> - DB8500_DMA_DEV37_USB_OTG_IEP_2_10,
> - DB8500_DMA_DEV36_USB_OTG_IEP_3_11,
> - DB8500_DMA_DEV19_USB_OTG_IEP_4_12,
> - DB8500_DMA_DEV18_USB_OTG_IEP_5_13,
> - DB8500_DMA_DEV17_USB_OTG_IEP_6_14,
> - DB8500_DMA_DEV16_USB_OTG_IEP_7_15,
> - DB8500_DMA_DEV39_USB_OTG_IEP_8
> + DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> + DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> + DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> + DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> + DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> + DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> + DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> + DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
> };
>
> static int usb_db8500_tx_dma_cfg[] = {
> - DB8500_DMA_DEV38_USB_OTG_OEP_1_9,
> - DB8500_DMA_DEV37_USB_OTG_OEP_2_10,
> - DB8500_DMA_DEV36_USB_OTG_OEP_3_11,
> - DB8500_DMA_DEV19_USB_OTG_OEP_4_12,
> - DB8500_DMA_DEV18_USB_OTG_OEP_5_13,
> - DB8500_DMA_DEV17_USB_OTG_OEP_6_14,
> - DB8500_DMA_DEV16_USB_OTG_OEP_7_15,
> - DB8500_DMA_DEV39_USB_OTG_OEP_8
> + DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> + DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> + DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> + DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> + DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> + DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> + DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> + DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
> };
If you're doing this change, and after this RX and TX has no semantical
meaning for these lists, join these two config lists
into one.
(...)
> diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
> static u32 d40_chan_has_events(struct d40_chan *d40c)
> @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
> struct stedma40_chan_cfg *conf)
> {
> int res = 0;
> - u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
> - u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
Please explain why this is not important to check anymore, I'm not
following.
> if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
> - dst_event_group == STEDMA40_DEV_DST_MEMORY) {
> - chan_err(d40c, "Invalid dst\n");
> + d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
> + d40c->runtime_addr == 0) {
> + chan_err(d40c, "Invalid TX channel address (%d)\n",
> + conf->dev_type);
Like here. We are checking for inconsistency between group
and channel direction, why is it no longer important to check this?
> if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> - src_event_group == STEDMA40_DEV_SRC_MEMORY) {
> - chan_err(d40c, "Invalid src\n");
> - res = -EINVAL;
> - }
> -
> - if (src_event_group == STEDMA40_DEV_SRC_MEMORY &&
> - dst_event_group == STEDMA40_DEV_DST_MEMORY && is_log) {
> - chan_err(d40c, "No event line\n");
> - res = -EINVAL;
> - }
> -
> - if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
> - (src_event_group != dst_event_group)) {
> - chan_err(d40c, "Invalid event group\n");
> + d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> + d40c->runtime_addr == 0) {
> + chan_err(d40c, "Invalid RX channel address (%d)\n",
> + conf->dev_type);
Same here.
(...)
> @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
> {
>
> int res = 0;
> - u32 event;
> + u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
> struct d40_phy_res *phy = d40c->phy_chan;
> bool is_src;
>
> @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
> }
>
> if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> - event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
> + d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
above?
And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??
This seems like a totally unrelated change and should it be done
it need to be a separate patch with a separate explanation
AFAICT.
This seems to happen in some other places too, and I find it
very hard to follow the changes here ... can you please consider
splitting the changes to groups and types semantics into a separate
patch?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
@ 2013-04-25 8:06 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:06 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Devices which utilise DMA tend to use the same channel numbers for
> transmitting and receiving. For this reason and the fact that it'll
> decrease the burden of platform data passed to each device, we're
> amalgamating source and destination device types.
I don't think this explains what the patch is actually doing.
Instead describe this:
> @@ -56,8 +54,7 @@ static struct stedma40_chan_cfg msp1_dma_rx = {
> .high_priority = true,
> .dir = STEDMA40_PERIPH_TO_MEM,
>
> - .src_dev_type = DB8500_DMA_DEV30_MSP3_RX,
> - .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
> + .dev_type = DB8500_DMA_DEV30_MSP3,
(...)
What the message should say is that we're encoding pairs of
information for sources and destinations. Since every such
entry contains a .dir entry stating the direction of the transfer
it is implicit whether the channel is for RX or TX and this is what
you're exploiting in this patch.
So channel numbers (as mentioned in the commit) is not
the key issue here.
Now we should ask ourselves why it was done like this from
the beginning. The reason is that DMA40 supports device-to-device
DMA, so if you encoded one device in .src_dev_type and another
device in .dst_dev_type and set .dir to
STEDMA40_PERIPH_TO_PERIPH (which as you can see is
defined in <linux/platform_data/dma-ste-dma40.h>) you get a
device to device transfer.
Are we now sacrificing that ability on the altar of simplification?
I actually think not, but that we should do periph-to-periph transfers
in some other way, and that the .dir attribute should go away from
the struct stedma40_chan_cfg as well but I'm not entirely sure.
Someone else?
(...)
> +++ b/arch/arm/mach-ux500/cpu-db8500.c
> @@ -167,25 +167,25 @@ static void __init db8500_add_gpios(struct device *parent)
> }
>
> static int usb_db8500_rx_dma_cfg[] = {
> - DB8500_DMA_DEV38_USB_OTG_IEP_1_9,
> - DB8500_DMA_DEV37_USB_OTG_IEP_2_10,
> - DB8500_DMA_DEV36_USB_OTG_IEP_3_11,
> - DB8500_DMA_DEV19_USB_OTG_IEP_4_12,
> - DB8500_DMA_DEV18_USB_OTG_IEP_5_13,
> - DB8500_DMA_DEV17_USB_OTG_IEP_6_14,
> - DB8500_DMA_DEV16_USB_OTG_IEP_7_15,
> - DB8500_DMA_DEV39_USB_OTG_IEP_8
> + DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> + DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> + DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> + DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> + DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> + DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> + DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> + DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
> };
>
> static int usb_db8500_tx_dma_cfg[] = {
> - DB8500_DMA_DEV38_USB_OTG_OEP_1_9,
> - DB8500_DMA_DEV37_USB_OTG_OEP_2_10,
> - DB8500_DMA_DEV36_USB_OTG_OEP_3_11,
> - DB8500_DMA_DEV19_USB_OTG_OEP_4_12,
> - DB8500_DMA_DEV18_USB_OTG_OEP_5_13,
> - DB8500_DMA_DEV17_USB_OTG_OEP_6_14,
> - DB8500_DMA_DEV16_USB_OTG_OEP_7_15,
> - DB8500_DMA_DEV39_USB_OTG_OEP_8
> + DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> + DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> + DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> + DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> + DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> + DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> + DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> + DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
> };
If you're doing this change, and after this RX and TX has no semantical
meaning for these lists, join these two config lists
into one.
(...)
> diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
> static u32 d40_chan_has_events(struct d40_chan *d40c)
> @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
> struct stedma40_chan_cfg *conf)
> {
> int res = 0;
> - u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
> - u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
Please explain why this is not important to check anymore, I'm not
following.
> if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
> - dst_event_group == STEDMA40_DEV_DST_MEMORY) {
> - chan_err(d40c, "Invalid dst\n");
> + d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
> + d40c->runtime_addr == 0) {
> + chan_err(d40c, "Invalid TX channel address (%d)\n",
> + conf->dev_type);
Like here. We are checking for inconsistency between group
and channel direction, why is it no longer important to check this?
> if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> - src_event_group == STEDMA40_DEV_SRC_MEMORY) {
> - chan_err(d40c, "Invalid src\n");
> - res = -EINVAL;
> - }
> -
> - if (src_event_group == STEDMA40_DEV_SRC_MEMORY &&
> - dst_event_group == STEDMA40_DEV_DST_MEMORY && is_log) {
> - chan_err(d40c, "No event line\n");
> - res = -EINVAL;
> - }
> -
> - if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
> - (src_event_group != dst_event_group)) {
> - chan_err(d40c, "Invalid event group\n");
> + d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> + d40c->runtime_addr == 0) {
> + chan_err(d40c, "Invalid RX channel address (%d)\n",
> + conf->dev_type);
Same here.
(...)
> @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
> {
>
> int res = 0;
> - u32 event;
> + u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
> struct d40_phy_res *phy = d40c->phy_chan;
> bool is_src;
>
> @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
> }
>
> if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> - event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
> + d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
above?
And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??
This seems like a totally unrelated change and should it be done
it need to be a separate patch with a separate explanation
AFAICT.
This seems to happen in some other places too, and I find it
very hard to follow the changes here ... can you please consider
splitting the changes to groups and types semantics into a separate
patch?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
2013-04-25 8:06 ` Linus Walleij
@ 2013-04-25 8:36 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-25 8:36 UTC (permalink / raw)
To: Linus Walleij
Cc: Lee Jones, linux-arm-kernel, linux-kernel, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thursday 25 April 2013, Linus Walleij wrote:
> Are we now sacrificing that ability on the altar of simplification?
>
> I actually think not, but that we should do periph-to-periph transfers
> in some other way, and that the .dir attribute should go away from
> the struct stedma40_chan_cfg as well but I'm not entirely sure.
> Someone else?
The dma-engine core has no support for device-to-device transfers,
and as far as I understand that is neither considered a useful
feature in real life, nor easy to add, so I don't think it matters
much here.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
@ 2013-04-25 8:36 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-25 8:36 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 25 April 2013, Linus Walleij wrote:
> Are we now sacrificing that ability on the altar of simplification?
>
> I actually think not, but that we should do periph-to-periph transfers
> in some other way, and that the .dir attribute should go away from
> the struct stedma40_chan_cfg as well but I'm not entirely sure.
> Someone else?
The dma-engine core has no support for device-to-device transfers,
and as far as I understand that is neither considered a useful
feature in real life, nor easy to add, so I don't think it matters
much here.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
2013-04-25 8:36 ` Arnd Bergmann
@ 2013-04-25 8:55 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lee Jones, linux-arm-kernel, linux-kernel, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 25, 2013 at 10:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 25 April 2013, Linus Walleij wrote:
>> Are we now sacrificing that ability on the altar of simplification?
>>
>> I actually think not, but that we should do periph-to-periph transfers
>> in some other way, and that the .dir attribute should go away from
>> the struct stedma40_chan_cfg as well but I'm not entirely sure.
>> Someone else?
>
> The dma-engine core has no support for device-to-device transfers,
It has this: DMA_DEV_TO_DEV (enum dma_transfer_direction)
so it has been thought of. Alas, it is unused for now.
> and as far as I understand that is neither considered a useful
> feature in real life, nor easy to add, so I don't think it matters
> much here.
It is a very useful feature in real life, we used that for PCM transfer
in U300. (I have heard this from other handset vendors too, so it
is a common thing.)
Consider a high-speed on-chip link from a
modem providing audio in (telephony) from the microphone in
one endpoint and audio out on another endpoint.
We just set that up so we connect a hose from the modem
RX to the PCM sink (D/A-codec) and vice versa as long as
the phone conversation is on.
This gives outstanding power performance since the CPU itself
can actually sleep during the enture voicecall, only the DMA
engine if awake.
We just never got around to modifying the DMAengine framework
to support this and integrate it... it is bound to come back to us,
especially with things like ever more accelerators on chips that
provide such autonomous data streams. (I think.)
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
@ 2013-04-25 8:55 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:55 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 25, 2013 at 10:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 25 April 2013, Linus Walleij wrote:
>> Are we now sacrificing that ability on the altar of simplification?
>>
>> I actually think not, but that we should do periph-to-periph transfers
>> in some other way, and that the .dir attribute should go away from
>> the struct stedma40_chan_cfg as well but I'm not entirely sure.
>> Someone else?
>
> The dma-engine core has no support for device-to-device transfers,
It has this: DMA_DEV_TO_DEV (enum dma_transfer_direction)
so it has been thought of. Alas, it is unused for now.
> and as far as I understand that is neither considered a useful
> feature in real life, nor easy to add, so I don't think it matters
> much here.
It is a very useful feature in real life, we used that for PCM transfer
in U300. (I have heard this from other handset vendors too, so it
is a common thing.)
Consider a high-speed on-chip link from a
modem providing audio in (telephony) from the microphone in
one endpoint and audio out on another endpoint.
We just set that up so we connect a hose from the modem
RX to the PCM sink (D/A-codec) and vice versa as long as
the phone conversation is on.
This gives outstanding power performance since the CPU itself
can actually sleep during the enture voicecall, only the DMA
engine if awake.
We just never got around to modifying the DMAengine framework
to support this and integrate it... it is bound to come back to us,
especially with things like ever more accelerators on chips that
provide such autonomous data streams. (I think.)
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
2013-04-25 8:06 ` Linus Walleij
@ 2013-04-25 9:06 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:06 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
> > Devices which utilise DMA tend to use the same channel numbers for
> > transmitting and receiving. For this reason and the fact that it'll
> > decrease the burden of platform data passed to each device, we're
> > amalgamating source and destination device types.
>
> I don't think this explains what the patch is actually doing.
>
> Instead describe this:
>
> > @@ -56,8 +54,7 @@ static struct stedma40_chan_cfg msp1_dma_rx = {
> > .high_priority = true,
> > .dir = STEDMA40_PERIPH_TO_MEM,
> >
> > - .src_dev_type = DB8500_DMA_DEV30_MSP3_RX,
> > - .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
> > + .dev_type = DB8500_DMA_DEV30_MSP3,
> (...)
>
> What the message should say is that we're encoding pairs of
> information for sources and destinations. Since every such
> entry contains a .dir entry stating the direction of the transfer
> it is implicit whether the channel is for RX or TX and this is what
> you're exploiting in this patch.
>
> So channel numbers (as mentioned in the commit) is not
> the key issue here.
Channel numbers should really be device types in the commit
message. I'll expand using your explanation too though.
> Now we should ask ourselves why it was done like this from
> the beginning. The reason is that DMA40 supports device-to-device
> DMA, so if you encoded one device in .src_dev_type and another
> device in .dst_dev_type and set .dir to
> STEDMA40_PERIPH_TO_PERIPH (which as you can see is
> defined in <linux/platform_data/dma-ste-dma40.h>) you get a
> device to device transfer.
>
> Are we now sacrificing that ability on the altar of simplification?
>
> I actually think not, but that we should do periph-to-periph transfers
> in some other way, and that the .dir attribute should go away from
> the struct stedma40_chan_cfg as well but I'm not entirely sure.
> Someone else?
Although the DMA40 device supports device-to-device transfers, Linux
does not, so this subject is moot AFAICT.
> (...)
> > +++ b/arch/arm/mach-ux500/cpu-db8500.c
> > @@ -167,25 +167,25 @@ static void __init db8500_add_gpios(struct device *parent)
> > }
> >
> > static int usb_db8500_rx_dma_cfg[] = {
> > - DB8500_DMA_DEV38_USB_OTG_IEP_1_9,
> > - DB8500_DMA_DEV37_USB_OTG_IEP_2_10,
> > - DB8500_DMA_DEV36_USB_OTG_IEP_3_11,
> > - DB8500_DMA_DEV19_USB_OTG_IEP_4_12,
> > - DB8500_DMA_DEV18_USB_OTG_IEP_5_13,
> > - DB8500_DMA_DEV17_USB_OTG_IEP_6_14,
> > - DB8500_DMA_DEV16_USB_OTG_IEP_7_15,
> > - DB8500_DMA_DEV39_USB_OTG_IEP_8
> > + DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> > + DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> > + DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> > + DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> > + DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> > + DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> > + DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> > + DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
> > };
> >
> > static int usb_db8500_tx_dma_cfg[] = {
> > - DB8500_DMA_DEV38_USB_OTG_OEP_1_9,
> > - DB8500_DMA_DEV37_USB_OTG_OEP_2_10,
> > - DB8500_DMA_DEV36_USB_OTG_OEP_3_11,
> > - DB8500_DMA_DEV19_USB_OTG_OEP_4_12,
> > - DB8500_DMA_DEV18_USB_OTG_OEP_5_13,
> > - DB8500_DMA_DEV17_USB_OTG_OEP_6_14,
> > - DB8500_DMA_DEV16_USB_OTG_OEP_7_15,
> > - DB8500_DMA_DEV39_USB_OTG_OEP_8
> > + DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> > + DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> > + DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> > + DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> > + DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> > + DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> > + DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> > + DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
> > };
>
>
> If you're doing this change, and after this RX and TX has no semantical
> meaning for these lists, join these two config lists
> into one.
I agree. See patch: ARM: ux500: Strip out duplicate USB DMA configuration
> (...)
> > diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
> > static u32 d40_chan_has_events(struct d40_chan *d40c)
> > @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
> > struct stedma40_chan_cfg *conf)
> > {
> > int res = 0;
> > - u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
> > - u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
>
> Please explain why this is not important to check anymore, I'm not
> following.
>
> > if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
> > - dst_event_group == STEDMA40_DEV_DST_MEMORY) {
> > - chan_err(d40c, "Invalid dst\n");
> > + d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
> > + d40c->runtime_addr == 0) {
> > + chan_err(d40c, "Invalid TX channel address (%d)\n",
> > + conf->dev_type);
>
> Like here. We are checking for inconsistency between group
> and channel direction, why is it no longer important to check this?
I'm not entirely sure how this ever worked:
#define D40_TYPE_TO_GROUP(type) (type / 16)
#define STEDMA40_DEV_DST_MEMORY (-1)
(dev_type / 16) == -1
What number would dev_type have to be for this to be true? -16?
> > if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> > - src_event_group == STEDMA40_DEV_SRC_MEMORY) {
> > - chan_err(d40c, "Invalid src\n");
> > - res = -EINVAL;
> > - }
As above.
> > - if (src_event_group == STEDMA40_DEV_SRC_MEMORY &&
> > - dst_event_group == STEDMA40_DEV_DST_MEMORY && is_log) {
> > - chan_err(d40c, "No event line\n");
> > - res = -EINVAL;
> > - }
We still check for this.
> > - if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
> > - (src_event_group != dst_event_group)) {
> > - chan_err(d40c, "Invalid event group\n");
> > + d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> > + d40c->runtime_addr == 0) {
> > + chan_err(d40c, "Invalid RX channel address (%d)\n",
> > + conf->dev_type);
>
> Same here.
I stopped all 'dev_src/dev_dest' comparisons, as there is only 'dev' now.
> (...)
> > @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
> > {
> >
> > int res = 0;
> > - u32 event;
> > + u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
> > struct d40_phy_res *phy = d40c->phy_chan;
> > bool is_src;
> >
> > @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
> > }
> >
> > if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> > - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> > - event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
> > + d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
>
> Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
> above?
That's not what this is doing. STEDMA40_MEM_TO_MEM is still there.
This patch is doing this:
+ u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
<snip>
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
> And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??
It's not. Look again. :)
> This seems like a totally unrelated change and should it be done
> it need to be a separate patch with a separate explanation
> AFAICT.
>
> This seems to happen in some other places too,
If you could point those out, I'll re-evaluate, or explain.
> and I find it
> very hard to follow the changes here ... can you please consider
> splitting the changes to groups and types semantics into a separate
> patch?
Can you read the patch again and reconsider please?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
@ 2013-04-25 9:06 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:06 UTC (permalink / raw)
To: linux-arm-kernel
> > Devices which utilise DMA tend to use the same channel numbers for
> > transmitting and receiving. For this reason and the fact that it'll
> > decrease the burden of platform data passed to each device, we're
> > amalgamating source and destination device types.
>
> I don't think this explains what the patch is actually doing.
>
> Instead describe this:
>
> > @@ -56,8 +54,7 @@ static struct stedma40_chan_cfg msp1_dma_rx = {
> > .high_priority = true,
> > .dir = STEDMA40_PERIPH_TO_MEM,
> >
> > - .src_dev_type = DB8500_DMA_DEV30_MSP3_RX,
> > - .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
> > + .dev_type = DB8500_DMA_DEV30_MSP3,
> (...)
>
> What the message should say is that we're encoding pairs of
> information for sources and destinations. Since every such
> entry contains a .dir entry stating the direction of the transfer
> it is implicit whether the channel is for RX or TX and this is what
> you're exploiting in this patch.
>
> So channel numbers (as mentioned in the commit) is not
> the key issue here.
Channel numbers should really be device types in the commit
message. I'll expand using your explanation too though.
> Now we should ask ourselves why it was done like this from
> the beginning. The reason is that DMA40 supports device-to-device
> DMA, so if you encoded one device in .src_dev_type and another
> device in .dst_dev_type and set .dir to
> STEDMA40_PERIPH_TO_PERIPH (which as you can see is
> defined in <linux/platform_data/dma-ste-dma40.h>) you get a
> device to device transfer.
>
> Are we now sacrificing that ability on the altar of simplification?
>
> I actually think not, but that we should do periph-to-periph transfers
> in some other way, and that the .dir attribute should go away from
> the struct stedma40_chan_cfg as well but I'm not entirely sure.
> Someone else?
Although the DMA40 device supports device-to-device transfers, Linux
does not, so this subject is moot AFAICT.
> (...)
> > +++ b/arch/arm/mach-ux500/cpu-db8500.c
> > @@ -167,25 +167,25 @@ static void __init db8500_add_gpios(struct device *parent)
> > }
> >
> > static int usb_db8500_rx_dma_cfg[] = {
> > - DB8500_DMA_DEV38_USB_OTG_IEP_1_9,
> > - DB8500_DMA_DEV37_USB_OTG_IEP_2_10,
> > - DB8500_DMA_DEV36_USB_OTG_IEP_3_11,
> > - DB8500_DMA_DEV19_USB_OTG_IEP_4_12,
> > - DB8500_DMA_DEV18_USB_OTG_IEP_5_13,
> > - DB8500_DMA_DEV17_USB_OTG_IEP_6_14,
> > - DB8500_DMA_DEV16_USB_OTG_IEP_7_15,
> > - DB8500_DMA_DEV39_USB_OTG_IEP_8
> > + DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> > + DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> > + DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> > + DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> > + DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> > + DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> > + DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> > + DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
> > };
> >
> > static int usb_db8500_tx_dma_cfg[] = {
> > - DB8500_DMA_DEV38_USB_OTG_OEP_1_9,
> > - DB8500_DMA_DEV37_USB_OTG_OEP_2_10,
> > - DB8500_DMA_DEV36_USB_OTG_OEP_3_11,
> > - DB8500_DMA_DEV19_USB_OTG_OEP_4_12,
> > - DB8500_DMA_DEV18_USB_OTG_OEP_5_13,
> > - DB8500_DMA_DEV17_USB_OTG_OEP_6_14,
> > - DB8500_DMA_DEV16_USB_OTG_OEP_7_15,
> > - DB8500_DMA_DEV39_USB_OTG_OEP_8
> > + DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
> > + DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
> > + DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
> > + DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
> > + DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
> > + DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
> > + DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
> > + DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
> > };
>
>
> If you're doing this change, and after this RX and TX has no semantical
> meaning for these lists, join these two config lists
> into one.
I agree. See patch: ARM: ux500: Strip out duplicate USB DMA configuration
> (...)
> > diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
> > static u32 d40_chan_has_events(struct d40_chan *d40c)
> > @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
> > struct stedma40_chan_cfg *conf)
> > {
> > int res = 0;
> > - u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
> > - u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
>
> Please explain why this is not important to check anymore, I'm not
> following.
>
> > if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
> > - dst_event_group == STEDMA40_DEV_DST_MEMORY) {
> > - chan_err(d40c, "Invalid dst\n");
> > + d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
> > + d40c->runtime_addr == 0) {
> > + chan_err(d40c, "Invalid TX channel address (%d)\n",
> > + conf->dev_type);
>
> Like here. We are checking for inconsistency between group
> and channel direction, why is it no longer important to check this?
I'm not entirely sure how this ever worked:
#define D40_TYPE_TO_GROUP(type) (type / 16)
#define STEDMA40_DEV_DST_MEMORY (-1)
(dev_type / 16) == -1
What number would dev_type have to be for this to be true? -16?
> > if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> > - src_event_group == STEDMA40_DEV_SRC_MEMORY) {
> > - chan_err(d40c, "Invalid src\n");
> > - res = -EINVAL;
> > - }
As above.
> > - if (src_event_group == STEDMA40_DEV_SRC_MEMORY &&
> > - dst_event_group == STEDMA40_DEV_DST_MEMORY && is_log) {
> > - chan_err(d40c, "No event line\n");
> > - res = -EINVAL;
> > - }
We still check for this.
> > - if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
> > - (src_event_group != dst_event_group)) {
> > - chan_err(d40c, "Invalid event group\n");
> > + d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> > + d40c->runtime_addr == 0) {
> > + chan_err(d40c, "Invalid RX channel address (%d)\n",
> > + conf->dev_type);
>
> Same here.
I stopped all 'dev_src/dev_dest' comparisons, as there is only 'dev' now.
> (...)
> > @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
> > {
> >
> > int res = 0;
> > - u32 event;
> > + u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
> > struct d40_phy_res *phy = d40c->phy_chan;
> > bool is_src;
> >
> > @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
> > }
> >
> > if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> > - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> > - event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
> > + d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
>
> Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
> above?
That's not what this is doing. STEDMA40_MEM_TO_MEM is still there.
This patch is doing this:
+ u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
<snip>
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
- event = D40_TYPE_TO_EVENT(d40c->dma_cfg.src_dev_type);
> And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??
It's not. Look again. :)
> This seems like a totally unrelated change and should it be done
> it need to be a separate patch with a separate explanation
> AFAICT.
>
> This seems to happen in some other places too,
If you could point those out, I'll re-evaluate, or explain.
> and I find it
> very hard to follow the changes here ... can you please consider
> splitting the changes to groups and types semantics into a separate
> patch?
Can you read the patch again and reconsider please?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
2013-04-25 9:06 ` Lee Jones
@ 2013-04-25 12:43 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:43 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 25, 2013 at 11:06 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> Are we now sacrificing that ability on the altar of simplification?
>>
>> I actually think not, but that we should do periph-to-periph transfers
>> in some other way, and that the .dir attribute should go away from
>> the struct stedma40_chan_cfg as well but I'm not entirely sure.
>> Someone else?
>
> Although the DMA40 device supports device-to-device transfers, Linux
> does not, so this subject is moot AFAICT.
So while there is no active usecase, Linux surely has the ambition to do
that as can be seen in:
/**
* enum dma_transfer_direction - dma transfer mode and direction indicator
* @DMA_MEM_TO_MEM: Async/Memcpy mode
* @DMA_MEM_TO_DEV: Slave mode & From Memory to Device
* @DMA_DEV_TO_MEM: Slave mode & From Device to Memory
* @DMA_DEV_TO_DEV: Slave mode & From Device to Device
*/
enum dma_transfer_direction {
DMA_MEM_TO_MEM,
DMA_MEM_TO_DEV,
DMA_DEV_TO_MEM,
DMA_DEV_TO_DEV,
DMA_TRANS_NONE,
};
I think we need a handshake with Vinod on this.
>> If you're doing this change, and after this RX and TX has no semantical
>> meaning for these lists, join these two config lists
>> into one.
>
> I agree. See patch: ARM: ux500: Strip out duplicate USB DMA configuration
Please squash the applicable portions into this patch then, I don't
particularly like fix-later patchstack patterns, it makes series hard to
review.
>> (...)
>> > diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
>> > static u32 d40_chan_has_events(struct d40_chan *d40c)
>> > @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
>> > struct stedma40_chan_cfg *conf)
>> > {
>> > int res = 0;
>> > - u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
>> > - u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
>>
>> Please explain why this is not important to check anymore, I'm not
>> following.
>>
>> > if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
>> > - dst_event_group == STEDMA40_DEV_DST_MEMORY) {
>> > - chan_err(d40c, "Invalid dst\n");
>> > + d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
>> > + d40c->runtime_addr == 0) {
>> > + chan_err(d40c, "Invalid TX channel address (%d)\n",
>> > + conf->dev_type);
>>
>> Like here. We are checking for inconsistency between group
>> and channel direction, why is it no longer important to check this?
>
> I'm not entirely sure how this ever worked:
>
> #define D40_TYPE_TO_GROUP(type) (type / 16)
> #define STEDMA40_DEV_DST_MEMORY (-1)
>
> (dev_type / 16) == -1
>
> What number would dev_type have to be for this to be true? -16?
No, since it's u32 it cannot really represent negative numbers.
This is equivalent:
#define D40_TYPE_TO_GROUP(type) (type >> 4)
As -1 is 0xffffffff in u32 it will compare at best
0x0fffffff to 0xfffffff. And that is non-attainable.
So the line checking event group for == DTEDMA40_DEV_DST_MEMORY
should be removed in a separate patch prior to this one, with
something like the above as commit message.
We cannot really mix that cleanup into this patch...
>> > if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
>> > - src_event_group == STEDMA40_DEV_SRC_MEMORY) {
>> > - chan_err(d40c, "Invalid src\n");
>> > - res = -EINVAL;
>> > - }
>
> As above.
And same comment.
>> > - if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
>> > - (src_event_group != dst_event_group)) {
>> > - chan_err(d40c, "Invalid event group\n");
>> > + d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
>> > + d40c->runtime_addr == 0) {
>> > + chan_err(d40c, "Invalid RX channel address (%d)\n",
>> > + conf->dev_type);
>>
>> Same here.
>
> I stopped all 'dev_src/dev_dest' comparisons, as there is only 'dev' now.
It is checking for:
conf->dir == STEDMA40_PERIPH_TO_PERIPH
As we may want to support DEV_TO_DEV at some point.
Then no longer, and that is not related to $SUBJECT.
>> (...)
>> > @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
>> > {
>> >
>> > int res = 0;
>> > - u32 event;
>> > + u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
>> > struct d40_phy_res *phy = d40c->phy_chan;
>> > bool is_src;
>> >
>> > @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
>> > }
>> >
>> > if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
>> > - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
>> > - event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
>> > + d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
>>
>> Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
>> above?
>
> That's not what this is doing. STEDMA40_MEM_TO_MEM is still there.
>
>> And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??
>
> It's not. Look again. :)
Argh I misread == MEM_TO_MEM for = MEM_TO_MEM ...
comparison to assignment. Sorry.
>> This seems like a totally unrelated change and should it be done
>> it need to be a separate patch with a separate explanation
>> AFAICT.
>>
>> This seems to happen in some other places too,
>
> If you could point those out, I'll re-evaluate, or explain.
I'm after that the change to omit checks for some impossible
type/group configs need to be a separate patch.
>> and I find it
>> very hard to follow the changes here ... can you please consider
>> splitting the changes to groups and types semantics into a separate
>> patch?
>
> Can you read the patch again and reconsider please?
Yes and now I am even more convinced that the patch needs
to be split.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
@ 2013-04-25 12:43 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:43 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 25, 2013 at 11:06 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> Are we now sacrificing that ability on the altar of simplification?
>>
>> I actually think not, but that we should do periph-to-periph transfers
>> in some other way, and that the .dir attribute should go away from
>> the struct stedma40_chan_cfg as well but I'm not entirely sure.
>> Someone else?
>
> Although the DMA40 device supports device-to-device transfers, Linux
> does not, so this subject is moot AFAICT.
So while there is no active usecase, Linux surely has the ambition to do
that as can be seen in:
/**
* enum dma_transfer_direction - dma transfer mode and direction indicator
* @DMA_MEM_TO_MEM: Async/Memcpy mode
* @DMA_MEM_TO_DEV: Slave mode & From Memory to Device
* @DMA_DEV_TO_MEM: Slave mode & From Device to Memory
* @DMA_DEV_TO_DEV: Slave mode & From Device to Device
*/
enum dma_transfer_direction {
DMA_MEM_TO_MEM,
DMA_MEM_TO_DEV,
DMA_DEV_TO_MEM,
DMA_DEV_TO_DEV,
DMA_TRANS_NONE,
};
I think we need a handshake with Vinod on this.
>> If you're doing this change, and after this RX and TX has no semantical
>> meaning for these lists, join these two config lists
>> into one.
>
> I agree. See patch: ARM: ux500: Strip out duplicate USB DMA configuration
Please squash the applicable portions into this patch then, I don't
particularly like fix-later patchstack patterns, it makes series hard to
review.
>> (...)
>> > diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
>> > static u32 d40_chan_has_events(struct d40_chan *d40c)
>> > @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
>> > struct stedma40_chan_cfg *conf)
>> > {
>> > int res = 0;
>> > - u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
>> > - u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
>>
>> Please explain why this is not important to check anymore, I'm not
>> following.
>>
>> > if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
>> > - dst_event_group == STEDMA40_DEV_DST_MEMORY) {
>> > - chan_err(d40c, "Invalid dst\n");
>> > + d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
>> > + d40c->runtime_addr == 0) {
>> > + chan_err(d40c, "Invalid TX channel address (%d)\n",
>> > + conf->dev_type);
>>
>> Like here. We are checking for inconsistency between group
>> and channel direction, why is it no longer important to check this?
>
> I'm not entirely sure how this ever worked:
>
> #define D40_TYPE_TO_GROUP(type) (type / 16)
> #define STEDMA40_DEV_DST_MEMORY (-1)
>
> (dev_type / 16) == -1
>
> What number would dev_type have to be for this to be true? -16?
No, since it's u32 it cannot really represent negative numbers.
This is equivalent:
#define D40_TYPE_TO_GROUP(type) (type >> 4)
As -1 is 0xffffffff in u32 it will compare at best
0x0fffffff to 0xfffffff. And that is non-attainable.
So the line checking event group for == DTEDMA40_DEV_DST_MEMORY
should be removed in a separate patch prior to this one, with
something like the above as commit message.
We cannot really mix that cleanup into this patch...
>> > if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
>> > - src_event_group == STEDMA40_DEV_SRC_MEMORY) {
>> > - chan_err(d40c, "Invalid src\n");
>> > - res = -EINVAL;
>> > - }
>
> As above.
And same comment.
>> > - if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
>> > - (src_event_group != dst_event_group)) {
>> > - chan_err(d40c, "Invalid event group\n");
>> > + d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
>> > + d40c->runtime_addr == 0) {
>> > + chan_err(d40c, "Invalid RX channel address (%d)\n",
>> > + conf->dev_type);
>>
>> Same here.
>
> I stopped all 'dev_src/dev_dest' comparisons, as there is only 'dev' now.
It is checking for:
conf->dir == STEDMA40_PERIPH_TO_PERIPH
As we may want to support DEV_TO_DEV at some point.
Then no longer, and that is not related to $SUBJECT.
>> (...)
>> > @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
>> > {
>> >
>> > int res = 0;
>> > - u32 event;
>> > + u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
>> > struct d40_phy_res *phy = d40c->phy_chan;
>> > bool is_src;
>> >
>> > @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
>> > }
>> >
>> > if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
>> > - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
>> > - event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
>> > + d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
>>
>> Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
>> above?
>
> That's not what this is doing. STEDMA40_MEM_TO_MEM is still there.
>
>> And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??
>
> It's not. Look again. :)
Argh I misread == MEM_TO_MEM for = MEM_TO_MEM ...
comparison to assignment. Sorry.
>> This seems like a totally unrelated change and should it be done
>> it need to be a separate patch with a separate explanation
>> AFAICT.
>>
>> This seems to happen in some other places too,
>
> If you could point those out, I'll re-evaluate, or explain.
I'm after that the change to omit checks for some impossible
type/group configs need to be a separate patch.
>> and I find it
>> very hard to follow the changes here ... can you please consider
>> splitting the changes to groups and types semantics into a separate
>> patch?
>
> Can you read the patch again and reconsider please?
Yes and now I am even more convinced that the patch needs
to be split.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
2013-04-25 12:43 ` Linus Walleij
@ 2013-04-25 13:09 ` Russell King - ARM Linux
-1 siblings, 0 replies; 337+ messages in thread
From: Russell King - ARM Linux @ 2013-04-25 13:09 UTC (permalink / raw)
To: Linus Walleij
Cc: Lee Jones, Rabin Vincent, Linus WALLEIJ, Arnd Bergmann,
Vinod Koul, linux-kernel, Per Forlin, Dan Williams,
linux-arm-kernel
On Thu, Apr 25, 2013 at 02:43:16PM +0200, Linus Walleij wrote:
> So while there is no active usecase, Linux surely has the ambition to do
> that as can be seen in:
>
> /**
> * enum dma_transfer_direction - dma transfer mode and direction indicator
> * @DMA_MEM_TO_MEM: Async/Memcpy mode
> * @DMA_MEM_TO_DEV: Slave mode & From Memory to Device
> * @DMA_DEV_TO_MEM: Slave mode & From Device to Memory
> * @DMA_DEV_TO_DEV: Slave mode & From Device to Device
> */
> enum dma_transfer_direction {
> DMA_MEM_TO_MEM,
> DMA_MEM_TO_DEV,
> DMA_DEV_TO_MEM,
> DMA_DEV_TO_DEV,
> DMA_TRANS_NONE,
> };
>
> I think we need a handshake with Vinod on this.
DEV_TO_DEV was added when the change to dma_transfer_direction happened,
to "fill in" the full pattern.
There's a problem with device to device transfers though - you have to
consider the rate at which the devices produce and consume data, and
whether they both can cope with differing data rates.
Take for instance your audio in to audio out idea - even if they are
both operating at the same bits per sample and sample rate, if they are
independently clocked, chances are that the clocks are not exactly the
same, which means you will either underrun or overrun one of the FIFOs
in the system.
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
@ 2013-04-25 13:09 ` Russell King - ARM Linux
0 siblings, 0 replies; 337+ messages in thread
From: Russell King - ARM Linux @ 2013-04-25 13:09 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 25, 2013 at 02:43:16PM +0200, Linus Walleij wrote:
> So while there is no active usecase, Linux surely has the ambition to do
> that as can be seen in:
>
> /**
> * enum dma_transfer_direction - dma transfer mode and direction indicator
> * @DMA_MEM_TO_MEM: Async/Memcpy mode
> * @DMA_MEM_TO_DEV: Slave mode & From Memory to Device
> * @DMA_DEV_TO_MEM: Slave mode & From Device to Memory
> * @DMA_DEV_TO_DEV: Slave mode & From Device to Device
> */
> enum dma_transfer_direction {
> DMA_MEM_TO_MEM,
> DMA_MEM_TO_DEV,
> DMA_DEV_TO_MEM,
> DMA_DEV_TO_DEV,
> DMA_TRANS_NONE,
> };
>
> I think we need a handshake with Vinod on this.
DEV_TO_DEV was added when the change to dma_transfer_direction happened,
to "fill in" the full pattern.
There's a problem with device to device transfers though - you have to
consider the rate at which the devices produce and consume data, and
whether they both can cope with differing data rates.
Take for instance your audio in to audio out idea - even if they are
both operating at the same bits per sample and sample rate, if they are
independently clocked, chances are that the clocks are not exactly the
same, which means you will either underrun or overrun one of the FIFOs
in the system.
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
2013-04-25 13:09 ` Russell King - ARM Linux
@ 2013-04-25 13:21 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 13:21 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Lee Jones, Rabin Vincent, Linus WALLEIJ, Arnd Bergmann,
Vinod Koul, linux-kernel, Per Forlin, Dan Williams,
linux-arm-kernel
On Thu, Apr 25, 2013 at 3:09 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> There's a problem with device to device transfers though - you have to
> consider the rate at which the devices produce and consume data, and
> whether they both can cope with differing data rates.
>
> Take for instance your audio in to audio out idea - even if they are
> both operating at the same bits per sample and sample rate, if they are
> independently clocked, chances are that the clocks are not exactly the
> same, which means you will either underrun or overrun one of the FIFOs
> in the system.
This magically works for us, but yes, I think they had to use the same
clock (simplest solution, anyway).
It is/was a very real usecase, IIRC coming from roundtrip constraints
in the GSM 3GPP spec, wanting to keep the latency as low as possible.
With this scheme there is no more than a FIFO on each end of delay,
which is nice.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
@ 2013-04-25 13:21 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 13:21 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 25, 2013 at 3:09 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> There's a problem with device to device transfers though - you have to
> consider the rate at which the devices produce and consume data, and
> whether they both can cope with differing data rates.
>
> Take for instance your audio in to audio out idea - even if they are
> both operating at the same bits per sample and sample rate, if they are
> independently clocked, chances are that the clocks are not exactly the
> same, which means you will either underrun or overrun one of the FIFOs
> in the system.
This magically works for us, but yes, I think they had to use the same
clock (simplest solution, anyway).
It is/was a very real usecase, IIRC coming from roundtrip constraints
in the GSM 3GPP spec, wanting to keep the latency as low as possible.
With this scheme there is no more than a FIFO on each end of delay,
which is nice.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
2013-04-25 12:43 ` Linus Walleij
@ 2013-04-25 13:20 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 13:20 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 11:06 AM, Lee Jones <lee.jones@linaro.org> wrote:
>
> >> Are we now sacrificing that ability on the altar of simplification?
> >>
> >> I actually think not, but that we should do periph-to-periph transfers
> >> in some other way, and that the .dir attribute should go away from
> >> the struct stedma40_chan_cfg as well but I'm not entirely sure.
> >> Someone else?
> >
> > Although the DMA40 device supports device-to-device transfers, Linux
> > does not, so this subject is moot AFAICT.
>
> So while there is no active usecase, Linux surely has the ambition to do
> that as can be seen in:
>
> /**
> * enum dma_transfer_direction - dma transfer mode and direction indicator
> * @DMA_MEM_TO_MEM: Async/Memcpy mode
> * @DMA_MEM_TO_DEV: Slave mode & From Memory to Device
> * @DMA_DEV_TO_MEM: Slave mode & From Device to Memory
> * @DMA_DEV_TO_DEV: Slave mode & From Device to Device
> */
> enum dma_transfer_direction {
> DMA_MEM_TO_MEM,
> DMA_MEM_TO_DEV,
> DMA_DEV_TO_MEM,
> DMA_DEV_TO_DEV,
> DMA_TRANS_NONE,
> };
>
> I think we need a handshake with Vinod on this.
Sure. He is CC'ed.
> >> If you're doing this change, and after this RX and TX has no semantical
> >> meaning for these lists, join these two config lists
> >> into one.
> >
> > I agree. See patch: ARM: ux500: Strip out duplicate USB DMA configuration
>
> Please squash the applicable portions into this patch then, I don't
> particularly like fix-later patchstack patterns, it makes series hard to
> review.
Okay.
> >> (...)
> >> > diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
> >> > static u32 d40_chan_has_events(struct d40_chan *d40c)
> >> > @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
> >> > struct stedma40_chan_cfg *conf)
> >> > {
> >> > int res = 0;
> >> > - u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
> >> > - u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
> >>
> >> Please explain why this is not important to check anymore, I'm not
> >> following.
> >>
> >> > if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
> >> > - dst_event_group == STEDMA40_DEV_DST_MEMORY) {
> >> > - chan_err(d40c, "Invalid dst\n");
> >> > + d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
> >> > + d40c->runtime_addr == 0) {
> >> > + chan_err(d40c, "Invalid TX channel address (%d)\n",
> >> > + conf->dev_type);
> >>
> >> Like here. We are checking for inconsistency between group
> >> and channel direction, why is it no longer important to check this?
> >
> > I'm not entirely sure how this ever worked:
> >
> > #define D40_TYPE_TO_GROUP(type) (type / 16)
> > #define STEDMA40_DEV_DST_MEMORY (-1)
> >
> > (dev_type / 16) == -1
> >
> > What number would dev_type have to be for this to be true? -16?
>
> No, since it's u32 it cannot really represent negative numbers.
>
> This is equivalent:
> #define D40_TYPE_TO_GROUP(type) (type >> 4)
>
> As -1 is 0xffffffff in u32 it will compare at best
> 0x0fffffff to 0xfffffff. And that is non-attainable.
>
> So the line checking event group for == DTEDMA40_DEV_DST_MEMORY
> should be removed in a separate patch prior to this one, with
> something like the above as commit message.
>
> We cannot really mix that cleanup into this patch...
I'm happy to do that.
> >> > if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> >> > - src_event_group == STEDMA40_DEV_SRC_MEMORY) {
> >> > - chan_err(d40c, "Invalid src\n");
> >> > - res = -EINVAL;
> >> > - }
> >
> > As above.
>
> And same comment.
>
> >> > - if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
> >> > - (src_event_group != dst_event_group)) {
> >> > - chan_err(d40c, "Invalid event group\n");
> >> > + d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> >> > + d40c->runtime_addr == 0) {
> >> > + chan_err(d40c, "Invalid RX channel address (%d)\n",
> >> > + conf->dev_type);
> >>
> >> Same here.
> >
> > I stopped all 'dev_src/dev_dest' comparisons, as there is only 'dev' now.
>
> It is checking for:
> conf->dir == STEDMA40_PERIPH_TO_PERIPH
>
> As we may want to support DEV_TO_DEV at some point.
>
> Then no longer, and that is not related to $SUBJECT.
That's not why I'm removing it. The statement can never be true due to
the fact that the second evaluation (src_event_group != dst_event_group)
can never be true, which is a direct effect of 'THIS_PATCH'.
> >> (...)
> >> > @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
> >> > {
> >> >
> >> > int res = 0;
> >> > - u32 event;
> >> > + u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
> >> > struct d40_phy_res *phy = d40c->phy_chan;
> >> > bool is_src;
> >> >
> >> > @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
> >> > }
> >> >
> >> > if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> >> > - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> >> > - event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
> >> > + d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
> >>
> >> Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
> >> above?
> >
> > That's not what this is doing. STEDMA40_MEM_TO_MEM is still there.
> >
> >> And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??
> >
> > It's not. Look again. :)
>
> Argh I misread == MEM_TO_MEM for = MEM_TO_MEM ...
> comparison to assignment. Sorry.
>
> >> This seems like a totally unrelated change and should it be done
> >> it need to be a separate patch with a separate explanation
> >> AFAICT.
> >>
> >> This seems to happen in some other places too,
> >
> > If you could point those out, I'll re-evaluate, or explain.
>
> I'm after that the change to omit checks for some impossible
> type/group configs need to be a separate patch.
>
> >> and I find it
> >> very hard to follow the changes here ... can you please consider
> >> splitting the changes to groups and types semantics into a separate
> >> patch?
> >
> > Can you read the patch again and reconsider please?
>
> Yes and now I am even more convinced that the patch needs
> to be split.
>
> Yours,
> Linus Walleij
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
@ 2013-04-25 13:20 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 13:20 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 11:06 AM, Lee Jones <lee.jones@linaro.org> wrote:
>
> >> Are we now sacrificing that ability on the altar of simplification?
> >>
> >> I actually think not, but that we should do periph-to-periph transfers
> >> in some other way, and that the .dir attribute should go away from
> >> the struct stedma40_chan_cfg as well but I'm not entirely sure.
> >> Someone else?
> >
> > Although the DMA40 device supports device-to-device transfers, Linux
> > does not, so this subject is moot AFAICT.
>
> So while there is no active usecase, Linux surely has the ambition to do
> that as can be seen in:
>
> /**
> * enum dma_transfer_direction - dma transfer mode and direction indicator
> * @DMA_MEM_TO_MEM: Async/Memcpy mode
> * @DMA_MEM_TO_DEV: Slave mode & From Memory to Device
> * @DMA_DEV_TO_MEM: Slave mode & From Device to Memory
> * @DMA_DEV_TO_DEV: Slave mode & From Device to Device
> */
> enum dma_transfer_direction {
> DMA_MEM_TO_MEM,
> DMA_MEM_TO_DEV,
> DMA_DEV_TO_MEM,
> DMA_DEV_TO_DEV,
> DMA_TRANS_NONE,
> };
>
> I think we need a handshake with Vinod on this.
Sure. He is CC'ed.
> >> If you're doing this change, and after this RX and TX has no semantical
> >> meaning for these lists, join these two config lists
> >> into one.
> >
> > I agree. See patch: ARM: ux500: Strip out duplicate USB DMA configuration
>
> Please squash the applicable portions into this patch then, I don't
> particularly like fix-later patchstack patterns, it makes series hard to
> review.
Okay.
> >> (...)
> >> > diff --git a/arch/arm/mach-ux500/usb.c b/arch/arm/mach-ux500/usb.c
> >> > static u32 d40_chan_has_events(struct d40_chan *d40c)
> >> > @@ -1744,8 +1740,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
> >> > struct stedma40_chan_cfg *conf)
> >> > {
> >> > int res = 0;
> >> > - u32 dst_event_group = D40_TYPE_TO_GROUP(conf->dst_dev_type);
> >> > - u32 src_event_group = D40_TYPE_TO_GROUP(conf->src_dev_type);
> >>
> >> Please explain why this is not important to check anymore, I'm not
> >> following.
> >>
> >> > if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
> >> > - dst_event_group == STEDMA40_DEV_DST_MEMORY) {
> >> > - chan_err(d40c, "Invalid dst\n");
> >> > + d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
> >> > + d40c->runtime_addr == 0) {
> >> > + chan_err(d40c, "Invalid TX channel address (%d)\n",
> >> > + conf->dev_type);
> >>
> >> Like here. We are checking for inconsistency between group
> >> and channel direction, why is it no longer important to check this?
> >
> > I'm not entirely sure how this ever worked:
> >
> > #define D40_TYPE_TO_GROUP(type) (type / 16)
> > #define STEDMA40_DEV_DST_MEMORY (-1)
> >
> > (dev_type / 16) == -1
> >
> > What number would dev_type have to be for this to be true? -16?
>
> No, since it's u32 it cannot really represent negative numbers.
>
> This is equivalent:
> #define D40_TYPE_TO_GROUP(type) (type >> 4)
>
> As -1 is 0xffffffff in u32 it will compare at best
> 0x0fffffff to 0xfffffff. And that is non-attainable.
>
> So the line checking event group for == DTEDMA40_DEV_DST_MEMORY
> should be removed in a separate patch prior to this one, with
> something like the above as commit message.
>
> We cannot really mix that cleanup into this patch...
I'm happy to do that.
> >> > if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> >> > - src_event_group == STEDMA40_DEV_SRC_MEMORY) {
> >> > - chan_err(d40c, "Invalid src\n");
> >> > - res = -EINVAL;
> >> > - }
> >
> > As above.
>
> And same comment.
>
> >> > - if (conf->dir == STEDMA40_PERIPH_TO_PERIPH &&
> >> > - (src_event_group != dst_event_group)) {
> >> > - chan_err(d40c, "Invalid event group\n");
> >> > + d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> >> > + d40c->runtime_addr == 0) {
> >> > + chan_err(d40c, "Invalid RX channel address (%d)\n",
> >> > + conf->dev_type);
> >>
> >> Same here.
> >
> > I stopped all 'dev_src/dev_dest' comparisons, as there is only 'dev' now.
>
> It is checking for:
> conf->dir == STEDMA40_PERIPH_TO_PERIPH
>
> As we may want to support DEV_TO_DEV at some point.
>
> Then no longer, and that is not related to $SUBJECT.
That's not why I'm removing it. The statement can never be true due to
the fact that the second evaluation (src_event_group != dst_event_group)
can never be true, which is a direct effect of 'THIS_PATCH'.
> >> (...)
> >> > @@ -2062,7 +2035,7 @@ static int d40_free_dma(struct d40_chan *d40c)
> >> > {
> >> >
> >> > int res = 0;
> >> > - u32 event;
> >> > + u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
> >> > struct d40_phy_res *phy = d40c->phy_chan;
> >> > bool is_src;
> >> >
> >> > @@ -2081,13 +2054,11 @@ static int d40_free_dma(struct d40_chan *d40c)
> >> > }
> >> >
> >> > if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> >> > - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> >> > - event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dst_dev_type);
> >> > + d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
> >>
> >> Why did you just stop checking dma_cfg.dir for == STEDMA40_MEM_TO_MEM
> >> above?
> >
> > That's not what this is doing. STEDMA40_MEM_TO_MEM is still there.
> >
> >> And why is dma_cfg.dir suddenly hardcoded to MEM_TO_MEM??
> >
> > It's not. Look again. :)
>
> Argh I misread == MEM_TO_MEM for = MEM_TO_MEM ...
> comparison to assignment. Sorry.
>
> >> This seems like a totally unrelated change and should it be done
> >> it need to be a separate patch with a separate explanation
> >> AFAICT.
> >>
> >> This seems to happen in some other places too,
> >
> > If you could point those out, I'll re-evaluate, or explain.
>
> I'm after that the change to omit checks for some impossible
> type/group configs need to be a separate patch.
>
> >> and I find it
> >> very hard to follow the changes here ... can you please consider
> >> splitting the changes to groups and types semantics into a separate
> >> patch?
> >
> > Can you read the patch again and reconsider please?
>
> Yes and now I am even more convinced that the patch needs
> to be split.
>
> Yours,
> Linus Walleij
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
2013-04-25 13:20 ` Lee Jones
@ 2013-04-25 13:24 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 13:24 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 25, 2013 at 3:20 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>> As we may want to support DEV_TO_DEV at some point.
>>
>> Then no longer, and that is not related to $SUBJECT.
>
> That's not why I'm removing it. The statement can never be true due to
> the fact that the second evaluation (src_event_group != dst_event_group)
> can never be true, which is a direct effect of 'THIS_PATCH'.
OK that is correct, I'm fine with this then ... as part of that other
patch dealing with unreacable conditions I keep talking about...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
@ 2013-04-25 13:24 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 13:24 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 25, 2013 at 3:20 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>> As we may want to support DEV_TO_DEV at some point.
>>
>> Then no longer, and that is not related to $SUBJECT.
>
> That's not why I'm removing it. The statement can never be true due to
> the fact that the second evaluation (src_event_group != dst_event_group)
> can never be true, which is a direct effect of 'THIS_PATCH'.
OK that is correct, I'm fine with this then ... as part of that other
patch dealing with unreacable conditions I keep talking about...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
2013-04-25 13:24 ` Linus Walleij
@ 2013-04-26 14:28 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-26 14:28 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 3:20 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 25 Apr 2013, Linus Walleij wrote:
>
> >> As we may want to support DEV_TO_DEV at some point.
> >>
> >> Then no longer, and that is not related to $SUBJECT.
> >
> > That's not why I'm removing it. The statement can never be true due to
> > the fact that the second evaluation (src_event_group != dst_event_group)
> > can never be true, which is a direct effect of 'THIS_PATCH'.
>
> OK that is correct, I'm fine with this then ... as part of that other
> patch dealing with unreacable conditions I keep talking about...
Just looking at this now.
Although I agree that the "dst_event_group == STEDMA40_DEV_DST_MEMORY
(-16)" issue can/should be split out prior, I don't think this
"(src_event_group != dst_event_group)" should be, as it is a direct
result of the code that's being changed in this patch here. It makes
no sense to remove it before this patch, as it's still valid and
removing it afterwards violates your break-now, fix-later stipulation.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 04/32] dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
@ 2013-04-26 14:28 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-26 14:28 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 3:20 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 25 Apr 2013, Linus Walleij wrote:
>
> >> As we may want to support DEV_TO_DEV at some point.
> >>
> >> Then no longer, and that is not related to $SUBJECT.
> >
> > That's not why I'm removing it. The statement can never be true due to
> > the fact that the second evaluation (src_event_group != dst_event_group)
> > can never be true, which is a direct effect of 'THIS_PATCH'.
>
> OK that is correct, I'm fine with this then ... as part of that other
> patch dealing with unreacable conditions I keep talking about...
Just looking at this now.
Although I agree that the "dst_event_group == STEDMA40_DEV_DST_MEMORY
(-16)" issue can/should be split out prior, I don't think this
"(src_event_group != dst_event_group)" should be, as it is a direct
result of the code that's being changed in this patch here. It makes
no sense to remove it before this patch, as it's still valid and
removing it afterwards violates your break-now, fix-later stipulation.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
There are lots of lengthy if() statements located sporadically up and
down the driver. This simple macro should make many of them a little
simpler to decipher. The remainder have to stay in place, as they
detail slightly more specific settings.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 38 ++++++++++++++++++++------------------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index e50354d..b21a8a3 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -55,6 +55,10 @@
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
+#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
+#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
+ (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
+
/* Reserved event lines for memcpy only. */
static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
@@ -823,7 +827,7 @@ static void d40_log_lli_to_lcxa(struct d40_chan *chan, struct d40_desc *desc)
* that uses linked lists.
*/
if (!(chan->phy_chan->use_soft_lli &&
- chan->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM))
+ D40_IS_SRC(chan->dma_cfg.dir)))
curr_lcla = d40_lcla_alloc_one(chan, desc);
first_lcla = curr_lcla;
@@ -1291,12 +1295,12 @@ static void d40_config_set_event(struct d40_chan *d40c,
u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
/* Enable event line connected to device (or memcpy) */
- if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
+ if (D40_IS_SRC(d40c->dma_cfg.dir) ||
(d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
__d40_config_set_event(d40c, event_type, event,
D40_CHAN_REG_SSLNK);
- if (d40c->dma_cfg.dir != STEDMA40_PERIPH_TO_MEM)
+ if (!D40_IS_SRC(d40c->dma_cfg.dir))
__d40_config_set_event(d40c, event_type, event,
D40_CHAN_REG_SDLNK);
}
@@ -1762,7 +1766,7 @@ static int d40_validate_conf(struct d40_chan *d40c,
res = -EINVAL;
}
- if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
+ if (D40_IS_SRC(conf->dir) &&
d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
d40c->runtime_addr == 0) {
chan_err(d40c, "Invalid RX channel address (%d)\n",
@@ -1895,17 +1899,17 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
int j;
int log_num;
int num_phy_chans;
+ int dir = d40c->dma_cfg.dir;
bool is_src;
bool is_log = d40c->dma_cfg.mode == STEDMA40_MODE_LOGICAL;
phys = d40c->base->phy_res;
num_phy_chans = d40c->base->num_phy_chans;
- if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
+ if (D40_IS_SRC(dir)) {
log_num = 2 * dev_type;
is_src = true;
- } else if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
- d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
+ } else if (D40_IS_DST(dir)) {
/* dst event lines are used for logical memcpy */
log_num = 2 * dev_type + 1;
is_src = false;
@@ -1916,7 +1920,7 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
event_line = D40_TYPE_TO_EVENT(dev_type);
if (!is_log) {
- if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
+ if (dir == STEDMA40_MEM_TO_MEM) {
/* Find physical half channel */
if (d40c->dma_cfg.use_fixed_channel) {
i = d40c->dma_cfg.phy_channel;
@@ -2053,11 +2057,10 @@ static int d40_free_dma(struct d40_chan *d40c)
return -EINVAL;
}
- if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
- d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
- is_src = false;
- else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
+ if (D40_IS_SRC(d40c->dma_cfg.dir))
is_src = true;
+ else if (D40_IS_DST(d40c->dma_cfg.dir))
+ is_src = false;
else {
chan_err(d40c, "Unknown direction\n");
return -EINVAL;
@@ -2118,12 +2121,11 @@ static bool d40_is_paused(struct d40_chan *d40c)
goto _exit;
}
- if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
- d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
- status = readl(chanbase + D40_CHAN_REG_SDLNK);
- } else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
+ if (D40_IS_SRC(d40c->dma_cfg.dir))
status = readl(chanbase + D40_CHAN_REG_SSLNK);
- } else {
+ else if (D40_IS_DST(d40c->dma_cfg.dir))
+ status = readl(chanbase + D40_CHAN_REG_SDLNK);
+ else {
chan_err(d40c, "Unknown direction\n");
goto _exit;
}
@@ -2394,7 +2396,7 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
if (d40c->base->rev < 3)
return;
- if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
+ if (D40_IS_SRC(d40c->dma_cfg.dir) ||
(d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, true);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
There are lots of lengthy if() statements located sporadically up and
down the driver. This simple macro should make many of them a little
simpler to decipher. The remainder have to stay in place, as they
detail slightly more specific settings.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 38 ++++++++++++++++++++------------------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index e50354d..b21a8a3 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -55,6 +55,10 @@
#define MAX(a, b) (((a) < (b)) ? (b) : (a))
+#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
+#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
+ (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
+
/* Reserved event lines for memcpy only. */
static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
@@ -823,7 +827,7 @@ static void d40_log_lli_to_lcxa(struct d40_chan *chan, struct d40_desc *desc)
* that uses linked lists.
*/
if (!(chan->phy_chan->use_soft_lli &&
- chan->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM))
+ D40_IS_SRC(chan->dma_cfg.dir)))
curr_lcla = d40_lcla_alloc_one(chan, desc);
first_lcla = curr_lcla;
@@ -1291,12 +1295,12 @@ static void d40_config_set_event(struct d40_chan *d40c,
u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
/* Enable event line connected to device (or memcpy) */
- if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
+ if (D40_IS_SRC(d40c->dma_cfg.dir) ||
(d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
__d40_config_set_event(d40c, event_type, event,
D40_CHAN_REG_SSLNK);
- if (d40c->dma_cfg.dir != STEDMA40_PERIPH_TO_MEM)
+ if (!D40_IS_SRC(d40c->dma_cfg.dir))
__d40_config_set_event(d40c, event_type, event,
D40_CHAN_REG_SDLNK);
}
@@ -1762,7 +1766,7 @@ static int d40_validate_conf(struct d40_chan *d40c,
res = -EINVAL;
}
- if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
+ if (D40_IS_SRC(conf->dir) &&
d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
d40c->runtime_addr == 0) {
chan_err(d40c, "Invalid RX channel address (%d)\n",
@@ -1895,17 +1899,17 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
int j;
int log_num;
int num_phy_chans;
+ int dir = d40c->dma_cfg.dir;
bool is_src;
bool is_log = d40c->dma_cfg.mode == STEDMA40_MODE_LOGICAL;
phys = d40c->base->phy_res;
num_phy_chans = d40c->base->num_phy_chans;
- if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
+ if (D40_IS_SRC(dir)) {
log_num = 2 * dev_type;
is_src = true;
- } else if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
- d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
+ } else if (D40_IS_DST(dir)) {
/* dst event lines are used for logical memcpy */
log_num = 2 * dev_type + 1;
is_src = false;
@@ -1916,7 +1920,7 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
event_line = D40_TYPE_TO_EVENT(dev_type);
if (!is_log) {
- if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
+ if (dir == STEDMA40_MEM_TO_MEM) {
/* Find physical half channel */
if (d40c->dma_cfg.use_fixed_channel) {
i = d40c->dma_cfg.phy_channel;
@@ -2053,11 +2057,10 @@ static int d40_free_dma(struct d40_chan *d40c)
return -EINVAL;
}
- if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
- d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
- is_src = false;
- else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
+ if (D40_IS_SRC(d40c->dma_cfg.dir))
is_src = true;
+ else if (D40_IS_DST(d40c->dma_cfg.dir))
+ is_src = false;
else {
chan_err(d40c, "Unknown direction\n");
return -EINVAL;
@@ -2118,12 +2121,11 @@ static bool d40_is_paused(struct d40_chan *d40c)
goto _exit;
}
- if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
- d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
- status = readl(chanbase + D40_CHAN_REG_SDLNK);
- } else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
+ if (D40_IS_SRC(d40c->dma_cfg.dir))
status = readl(chanbase + D40_CHAN_REG_SSLNK);
- } else {
+ else if (D40_IS_DST(d40c->dma_cfg.dir))
+ status = readl(chanbase + D40_CHAN_REG_SDLNK);
+ else {
chan_err(d40c, "Unknown direction\n");
goto _exit;
}
@@ -2394,7 +2396,7 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
if (d40c->base->rev < 3)
return;
- if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
+ if (D40_IS_SRC(d40c->dma_cfg.dir) ||
(d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, true);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:50 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:50 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> +#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
> +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> + (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> +
The redundant "? true : false" part is redundant. ;-)
Otherwise the patch looks good.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
@ 2013-04-18 10:50 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:50 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> +#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
> +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> + (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> +
The redundant "? true : false" part is redundant. ;-)
Otherwise the patch looks good.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
2013-04-18 10:11 ` Lee Jones
@ 2013-04-22 9:42 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:42 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> There are lots of lengthy if() statements located sporadically up and
> down the driver. This simple macro should make many of them a little
> simpler to decipher. The remainder have to stay in place, as they
> detail slightly more specific settings.
I would like these to be DMAENGINE_IS_SRC... and this patch use the defines
provided in dmaengine
--
~Vinod
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/dma/ste_dma40.c | 38 ++++++++++++++++++++------------------
> 1 file changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index e50354d..b21a8a3 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -55,6 +55,10 @@
>
> #define MAX(a, b) (((a) < (b)) ? (b) : (a))
>
> +#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
> +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> + (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> +
> /* Reserved event lines for memcpy only. */
> static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
>
> @@ -823,7 +827,7 @@ static void d40_log_lli_to_lcxa(struct d40_chan *chan, struct d40_desc *desc)
> * that uses linked lists.
> */
> if (!(chan->phy_chan->use_soft_lli &&
> - chan->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM))
> + D40_IS_SRC(chan->dma_cfg.dir)))
> curr_lcla = d40_lcla_alloc_one(chan, desc);
>
> first_lcla = curr_lcla;
> @@ -1291,12 +1295,12 @@ static void d40_config_set_event(struct d40_chan *d40c,
> u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
>
> /* Enable event line connected to device (or memcpy) */
> - if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
> + if (D40_IS_SRC(d40c->dma_cfg.dir) ||
> (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
> __d40_config_set_event(d40c, event_type, event,
> D40_CHAN_REG_SSLNK);
>
> - if (d40c->dma_cfg.dir != STEDMA40_PERIPH_TO_MEM)
> + if (!D40_IS_SRC(d40c->dma_cfg.dir))
> __d40_config_set_event(d40c, event_type, event,
> D40_CHAN_REG_SDLNK);
> }
> @@ -1762,7 +1766,7 @@ static int d40_validate_conf(struct d40_chan *d40c,
> res = -EINVAL;
> }
>
> - if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> + if (D40_IS_SRC(conf->dir) &&
> d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> d40c->runtime_addr == 0) {
> chan_err(d40c, "Invalid RX channel address (%d)\n",
> @@ -1895,17 +1899,17 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
> int j;
> int log_num;
> int num_phy_chans;
> + int dir = d40c->dma_cfg.dir;
> bool is_src;
> bool is_log = d40c->dma_cfg.mode == STEDMA40_MODE_LOGICAL;
>
> phys = d40c->base->phy_res;
> num_phy_chans = d40c->base->num_phy_chans;
>
> - if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
> + if (D40_IS_SRC(dir)) {
> log_num = 2 * dev_type;
> is_src = true;
> - } else if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> + } else if (D40_IS_DST(dir)) {
> /* dst event lines are used for logical memcpy */
> log_num = 2 * dev_type + 1;
> is_src = false;
> @@ -1916,7 +1920,7 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
> event_line = D40_TYPE_TO_EVENT(dev_type);
>
> if (!is_log) {
> - if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> + if (dir == STEDMA40_MEM_TO_MEM) {
> /* Find physical half channel */
> if (d40c->dma_cfg.use_fixed_channel) {
> i = d40c->dma_cfg.phy_channel;
> @@ -2053,11 +2057,10 @@ static int d40_free_dma(struct d40_chan *d40c)
> return -EINVAL;
> }
>
> - if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
> - is_src = false;
> - else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> + if (D40_IS_SRC(d40c->dma_cfg.dir))
> is_src = true;
> + else if (D40_IS_DST(d40c->dma_cfg.dir))
> + is_src = false;
> else {
> chan_err(d40c, "Unknown direction\n");
> return -EINVAL;
> @@ -2118,12 +2121,11 @@ static bool d40_is_paused(struct d40_chan *d40c)
> goto _exit;
> }
>
> - if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> - status = readl(chanbase + D40_CHAN_REG_SDLNK);
> - } else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
> + if (D40_IS_SRC(d40c->dma_cfg.dir))
> status = readl(chanbase + D40_CHAN_REG_SSLNK);
> - } else {
> + else if (D40_IS_DST(d40c->dma_cfg.dir))
> + status = readl(chanbase + D40_CHAN_REG_SDLNK);
> + else {
> chan_err(d40c, "Unknown direction\n");
> goto _exit;
> }
> @@ -2394,7 +2396,7 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
> if (d40c->base->rev < 3)
> return;
>
> - if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
> + if (D40_IS_SRC(d40c->dma_cfg.dir) ||
> (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
> __d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, true);
>
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
@ 2013-04-22 9:42 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:42 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> There are lots of lengthy if() statements located sporadically up and
> down the driver. This simple macro should make many of them a little
> simpler to decipher. The remainder have to stay in place, as they
> detail slightly more specific settings.
I would like these to be DMAENGINE_IS_SRC... and this patch use the defines
provided in dmaengine
--
~Vinod
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/dma/ste_dma40.c | 38 ++++++++++++++++++++------------------
> 1 file changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index e50354d..b21a8a3 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -55,6 +55,10 @@
>
> #define MAX(a, b) (((a) < (b)) ? (b) : (a))
>
> +#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
> +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> + (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> +
> /* Reserved event lines for memcpy only. */
> static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
>
> @@ -823,7 +827,7 @@ static void d40_log_lli_to_lcxa(struct d40_chan *chan, struct d40_desc *desc)
> * that uses linked lists.
> */
> if (!(chan->phy_chan->use_soft_lli &&
> - chan->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM))
> + D40_IS_SRC(chan->dma_cfg.dir)))
> curr_lcla = d40_lcla_alloc_one(chan, desc);
>
> first_lcla = curr_lcla;
> @@ -1291,12 +1295,12 @@ static void d40_config_set_event(struct d40_chan *d40c,
> u32 event = D40_TYPE_TO_EVENT(d40c->dma_cfg.dev_type);
>
> /* Enable event line connected to device (or memcpy) */
> - if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
> + if (D40_IS_SRC(d40c->dma_cfg.dir) ||
> (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
> __d40_config_set_event(d40c, event_type, event,
> D40_CHAN_REG_SSLNK);
>
> - if (d40c->dma_cfg.dir != STEDMA40_PERIPH_TO_MEM)
> + if (!D40_IS_SRC(d40c->dma_cfg.dir))
> __d40_config_set_event(d40c, event_type, event,
> D40_CHAN_REG_SDLNK);
> }
> @@ -1762,7 +1766,7 @@ static int d40_validate_conf(struct d40_chan *d40c,
> res = -EINVAL;
> }
>
> - if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> + if (D40_IS_SRC(conf->dir) &&
> d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> d40c->runtime_addr == 0) {
> chan_err(d40c, "Invalid RX channel address (%d)\n",
> @@ -1895,17 +1899,17 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
> int j;
> int log_num;
> int num_phy_chans;
> + int dir = d40c->dma_cfg.dir;
> bool is_src;
> bool is_log = d40c->dma_cfg.mode == STEDMA40_MODE_LOGICAL;
>
> phys = d40c->base->phy_res;
> num_phy_chans = d40c->base->num_phy_chans;
>
> - if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
> + if (D40_IS_SRC(dir)) {
> log_num = 2 * dev_type;
> is_src = true;
> - } else if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> + } else if (D40_IS_DST(dir)) {
> /* dst event lines are used for logical memcpy */
> log_num = 2 * dev_type + 1;
> is_src = false;
> @@ -1916,7 +1920,7 @@ static int d40_allocate_channel(struct d40_chan *d40c, bool *first_phy_user)
> event_line = D40_TYPE_TO_EVENT(dev_type);
>
> if (!is_log) {
> - if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> + if (dir == STEDMA40_MEM_TO_MEM) {
> /* Find physical half channel */
> if (d40c->dma_cfg.use_fixed_channel) {
> i = d40c->dma_cfg.phy_channel;
> @@ -2053,11 +2057,10 @@ static int d40_free_dma(struct d40_chan *d40c)
> return -EINVAL;
> }
>
> - if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM)
> - is_src = false;
> - else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> + if (D40_IS_SRC(d40c->dma_cfg.dir))
> is_src = true;
> + else if (D40_IS_DST(d40c->dma_cfg.dir))
> + is_src = false;
> else {
> chan_err(d40c, "Unknown direction\n");
> return -EINVAL;
> @@ -2118,12 +2121,11 @@ static bool d40_is_paused(struct d40_chan *d40c)
> goto _exit;
> }
>
> - if (d40c->dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
> - d40c->dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
> - status = readl(chanbase + D40_CHAN_REG_SDLNK);
> - } else if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
> + if (D40_IS_SRC(d40c->dma_cfg.dir))
> status = readl(chanbase + D40_CHAN_REG_SSLNK);
> - } else {
> + else if (D40_IS_DST(d40c->dma_cfg.dir))
> + status = readl(chanbase + D40_CHAN_REG_SDLNK);
> + else {
> chan_err(d40c, "Unknown direction\n");
> goto _exit;
> }
> @@ -2394,7 +2396,7 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
> if (d40c->base->rev < 3)
> return;
>
> - if ((d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) ||
> + if (D40_IS_SRC(d40c->dma_cfg.dir) ||
> (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
> __d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, true);
>
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
2013-04-22 9:42 ` Vinod Koul
@ 2013-04-22 10:27 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:27 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Mon, 22 Apr 2013, Vinod Koul wrote:
> On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> > There are lots of lengthy if() statements located sporadically up and
> > down the driver. This simple macro should make many of them a little
> > simpler to decipher. The remainder have to stay in place, as they
> > detail slightly more specific settings.
> I would like these to be DMAENGINE_IS_SRC...
I don't understand, as they're DMA40 specific?
> and this patch use the defines provided in dmaengine
I think a subsequent patch doing he following would be more suitable:
s/STEDMA40_MEM_TO_MEM/DMA_MEM_TO_MEM/
s/STEDMA40_MEM_TO_PERIPH/DMA_MEM_TO_DEV/
s/STEDMA40_PERIPH_TO_MEM/DMA_DEV_TO_MEM/
s/STEDMA40_PERIPH_TO_PERIPH/DMA_DEV_TO_DEV/
If you don't mind?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
@ 2013-04-22 10:27 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:27 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 22 Apr 2013, Vinod Koul wrote:
> On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> > There are lots of lengthy if() statements located sporadically up and
> > down the driver. This simple macro should make many of them a little
> > simpler to decipher. The remainder have to stay in place, as they
> > detail slightly more specific settings.
> I would like these to be DMAENGINE_IS_SRC...
I don't understand, as they're DMA40 specific?
> and this patch use the defines provided in dmaengine
I think a subsequent patch doing he following would be more suitable:
s/STEDMA40_MEM_TO_MEM/DMA_MEM_TO_MEM/
s/STEDMA40_MEM_TO_PERIPH/DMA_MEM_TO_DEV/
s/STEDMA40_PERIPH_TO_MEM/DMA_DEV_TO_MEM/
s/STEDMA40_PERIPH_TO_PERIPH/DMA_DEV_TO_DEV/
If you don't mind?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
2013-04-22 10:27 ` Lee Jones
@ 2013-04-22 10:19 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:19 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Mon, Apr 22, 2013 at 11:27:48AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
>
> > On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> > > There are lots of lengthy if() statements located sporadically up and
> > > down the driver. This simple macro should make many of them a little
> > > simpler to decipher. The remainder have to stay in place, as they
> > > detail slightly more specific settings.
> > I would like these to be DMAENGINE_IS_SRC...
>
> I don't understand, as they're DMA40 specific?
>
> > and this patch use the defines provided in dmaengine
>
> I think a subsequent patch doing he following would be more suitable:
>
> s/STEDMA40_MEM_TO_MEM/DMA_MEM_TO_MEM/
> s/STEDMA40_MEM_TO_PERIPH/DMA_MEM_TO_DEV/
> s/STEDMA40_PERIPH_TO_MEM/DMA_DEV_TO_MEM/
> s/STEDMA40_PERIPH_TO_PERIPH/DMA_DEV_TO_DEV/
>
> If you don't mind?
sounds like a good plan
--
~Vinod
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
@ 2013-04-22 10:19 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:19 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Apr 22, 2013 at 11:27:48AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
>
> > On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> > > There are lots of lengthy if() statements located sporadically up and
> > > down the driver. This simple macro should make many of them a little
> > > simpler to decipher. The remainder have to stay in place, as they
> > > detail slightly more specific settings.
> > I would like these to be DMAENGINE_IS_SRC...
>
> I don't understand, as they're DMA40 specific?
>
> > and this patch use the defines provided in dmaengine
>
> I think a subsequent patch doing he following would be more suitable:
>
> s/STEDMA40_MEM_TO_MEM/DMA_MEM_TO_MEM/
> s/STEDMA40_MEM_TO_PERIPH/DMA_MEM_TO_DEV/
> s/STEDMA40_PERIPH_TO_MEM/DMA_DEV_TO_MEM/
> s/STEDMA40_PERIPH_TO_PERIPH/DMA_DEV_TO_DEV/
>
> If you don't mind?
sounds like a good plan
--
~Vinod
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
2013-04-22 10:27 ` Lee Jones
@ 2013-04-24 8:53 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:53 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Mon, 22 Apr 2013, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
>
> > On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> > > There are lots of lengthy if() statements located sporadically up and
> > > down the driver. This simple macro should make many of them a little
> > > simpler to decipher. The remainder have to stay in place, as they
> > > detail slightly more specific settings.
> > I would like these to be DMAENGINE_IS_SRC...
>
> I don't understand, as they're DMA40 specific?
>
> > and this patch use the defines provided in dmaengine
>
> I think a subsequent patch doing he following would be more suitable:
>
> s/STEDMA40_MEM_TO_MEM/DMA_MEM_TO_MEM/
> s/STEDMA40_MEM_TO_PERIPH/DMA_MEM_TO_DEV/
> s/STEDMA40_PERIPH_TO_MEM/DMA_DEV_TO_MEM/
> s/STEDMA40_PERIPH_TO_PERIPH/DMA_DEV_TO_DEV/
>
> If you don't mind?
Are you happy to Ack this one too if I follow up with a subsequent
patch converting all STEDMA direction defines over to the generic DMA
ones? There are also quite a lot in platform data that I'd like to
convert too.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
@ 2013-04-24 8:53 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:53 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 22 Apr 2013, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
>
> > On Thu, Apr 18, 2013 at 11:11:47AM +0100, Lee Jones wrote:
> > > There are lots of lengthy if() statements located sporadically up and
> > > down the driver. This simple macro should make many of them a little
> > > simpler to decipher. The remainder have to stay in place, as they
> > > detail slightly more specific settings.
> > I would like these to be DMAENGINE_IS_SRC...
>
> I don't understand, as they're DMA40 specific?
>
> > and this patch use the defines provided in dmaengine
>
> I think a subsequent patch doing he following would be more suitable:
>
> s/STEDMA40_MEM_TO_MEM/DMA_MEM_TO_MEM/
> s/STEDMA40_MEM_TO_PERIPH/DMA_MEM_TO_DEV/
> s/STEDMA40_PERIPH_TO_MEM/DMA_DEV_TO_MEM/
> s/STEDMA40_PERIPH_TO_PERIPH/DMA_DEV_TO_DEV/
>
> If you don't mind?
Are you happy to Ack this one too if I follow up with a subsequent
patch converting all STEDMA direction defines over to the generic DMA
ones? There are also quite a lot in platform data that I'd like to
convert too.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 8:22 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:22 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Rabin Vincent, Linus WALLEIJ,
Arnd Bergmann, Vinod Koul, Per Forlin, Dan Williams
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> There are lots of lengthy if() statements located sporadically up and
> down the driver. This simple macro should make many of them a little
> simpler to decipher. The remainder have to stay in place, as they
> detail slightly more specific settings.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(...)
> +#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
And when I reas the code and see D40_IS_SRC, what does that
mean? That the channel is a source of .. what exactly?
The older explicit comparison would be more informative.
> +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> + (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> +
The comparison to STEDMA40_MEM_TO_MEM is unintelligible, if I see
that macro it has a very unintuitive name, since it is not just
DST but also SRC.
The latter macro would be named somthing like D40_IS_DST_OR_MEM2MEM
and then it will not simplify the code very much.
You need to come up with something different here, this is just making the
driver harder to understand.
I think this patch should be just dropped.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
@ 2013-04-25 8:22 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> There are lots of lengthy if() statements located sporadically up and
> down the driver. This simple macro should make many of them a little
> simpler to decipher. The remainder have to stay in place, as they
> detail slightly more specific settings.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(...)
> +#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
And when I reas the code and see D40_IS_SRC, what does that
mean? That the channel is a source of .. what exactly?
The older explicit comparison would be more informative.
> +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> + (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> +
The comparison to STEDMA40_MEM_TO_MEM is unintelligible, if I see
that macro it has a very unintuitive name, since it is not just
DST but also SRC.
The latter macro would be named somthing like D40_IS_DST_OR_MEM2MEM
and then it will not simplify the code very much.
You need to come up with something different here, this is just making the
driver harder to understand.
I think this patch should be just dropped.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
2013-04-25 8:22 ` Linus Walleij
@ 2013-04-25 9:19 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:19 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Rabin Vincent, Linus WALLEIJ,
Arnd Bergmann, Vinod Koul, Per Forlin, Dan Williams
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > There are lots of lengthy if() statements located sporadically up and
> > down the driver. This simple macro should make many of them a little
> > simpler to decipher. The remainder have to stay in place, as they
> > detail slightly more specific settings.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> (...)
>
> > +#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
>
> And when I reas the code and see D40_IS_SRC, what does that
> mean? That the channel is a source of .. what exactly?
>
> The older explicit comparison would be more informative.
>
> > +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> > + (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> > +
>
> The comparison to STEDMA40_MEM_TO_MEM is unintelligible, if I see
> that macro it has a very unintuitive name, since it is not just
> DST but also SRC.
>
> The latter macro would be named somthing like D40_IS_DST_OR_MEM2MEM
> and then it will not simplify the code very much.
>
> You need to come up with something different here, this is just making the
> driver harder to understand.
>
> I think this patch should be just dropped.
Okay.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 05/32] dmaengine: ste_dma40: Supply macros to resolve 'src' and 'dst' directions
@ 2013-04-25 9:19 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:19 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > There are lots of lengthy if() statements located sporadically up and
> > down the driver. This simple macro should make many of them a little
> > simpler to decipher. The remainder have to stay in place, as they
> > detail slightly more specific settings.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> (...)
>
> > +#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
>
> And when I reas the code and see D40_IS_SRC, what does that
> mean? That the channel is a source of .. what exactly?
>
> The older explicit comparison would be more informative.
>
> > +#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> > + (dir == STEDMA40_MEM_TO_MEM)) ? true : false)
> > +
>
> The comparison to STEDMA40_MEM_TO_MEM is unintelligible, if I see
> that macro it has a very unintuitive name, since it is not just
> DST but also SRC.
>
> The latter macro would be named somthing like D40_IS_DST_OR_MEM2MEM
> and then it will not simplify the code very much.
>
> You need to come up with something different here, this is just making the
> driver harder to understand.
>
> I think this patch should be just dropped.
Okay.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 06/32] ARM: ux500: Strip out duplicate USB DMA configuration
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
For the moment at least, the TX and RX channels for DB8500 USB are
identical, so this patch generalises them into a single structure
and passes it twice. Once as the TX and again for the RX configuration.
We're keeping the infrastructure the same i.e. passing the TX and RX
separately in case they start to differ on latter incarnations of the
platform.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index f72cc9b..a15678d 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -166,18 +166,7 @@ static void __init db8500_add_gpios(struct device *parent)
dbx500_add_pinctrl(parent, "pinctrl-db8500", U8500_PRCMU_BASE);
}
-static int usb_db8500_rx_dma_cfg[] = {
- DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
- DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
- DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
- DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
- DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
- DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
- DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
- DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
-};
-
-static int usb_db8500_tx_dma_cfg[] = {
+static int usb_db8500_dma_cfg[] = {
DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
@@ -219,7 +208,7 @@ struct device * __init u8500_init_devices(struct ab8500_platform_data *ab8500)
db8500_add_rtc(parent);
db8500_add_gpios(parent);
- db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
+ db8500_add_usb(parent, usb_db8500_dma_cfg, usb_db8500_dma_cfg);
for (i = 0; i < ARRAY_SIZE(platform_devs); i++)
platform_devs[i]->dev.parent = parent;
@@ -238,7 +227,7 @@ static struct device * __init u8500_of_init_devices(void)
{
struct device *parent = db8500_soc_device_init();
- db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
+ db8500_add_usb(parent, usb_db8500_dma_cfg, usb_db8500_dma_cfg);
u8500_dma40_device.dev.parent = parent;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 06/32] ARM: ux500: Strip out duplicate USB DMA configuration
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
For the moment at least, the TX and RX channels for DB8500 USB are
identical, so this patch generalises them into a single structure
and passes it twice. Once as the TX and again for the RX configuration.
We're keeping the infrastructure the same i.e. passing the TX and RX
separately in case they start to differ on latter incarnations of the
platform.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index f72cc9b..a15678d 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -166,18 +166,7 @@ static void __init db8500_add_gpios(struct device *parent)
dbx500_add_pinctrl(parent, "pinctrl-db8500", U8500_PRCMU_BASE);
}
-static int usb_db8500_rx_dma_cfg[] = {
- DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
- DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
- DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
- DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12,
- DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13,
- DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14,
- DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15,
- DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8
-};
-
-static int usb_db8500_tx_dma_cfg[] = {
+static int usb_db8500_dma_cfg[] = {
DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9,
DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10,
DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11,
@@ -219,7 +208,7 @@ struct device * __init u8500_init_devices(struct ab8500_platform_data *ab8500)
db8500_add_rtc(parent);
db8500_add_gpios(parent);
- db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
+ db8500_add_usb(parent, usb_db8500_dma_cfg, usb_db8500_dma_cfg);
for (i = 0; i < ARRAY_SIZE(platform_devs); i++)
platform_devs[i]->dev.parent = parent;
@@ -238,7 +227,7 @@ static struct device * __init u8500_of_init_devices(void)
{
struct device *parent = db8500_soc_device_init();
- db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
+ db8500_add_usb(parent, usb_db8500_dma_cfg, usb_db8500_dma_cfg);
u8500_dma40_device.dev.parent = parent;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 06/32] ARM: ux500: Strip out duplicate USB DMA configuration
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:51 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:51 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, linus.walleij
On Thursday 18 April 2013, Lee Jones wrote:
> For the moment at least, the TX and RX channels for DB8500 USB are
> identical, so this patch generalises them into a single structure
> and passes it twice. Once as the TX and again for the RX configuration.
> We're keeping the infrastructure the same i.e. passing the TX and RX
> separately in case they start to differ on latter incarnations of the
> platform.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 06/32] ARM: ux500: Strip out duplicate USB DMA configuration
@ 2013-04-18 10:51 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:51 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> For the moment at least, the TX and RX channels for DB8500 USB are
> identical, so this patch generalises them into a single structure
> and passes it twice. Once as the TX and again for the RX configuration.
> We're keeping the infrastructure the same i.e. passing the TX and RX
> separately in case they start to differ on latter incarnations of the
> platform.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 06/32] ARM: ux500: Strip out duplicate USB DMA configuration
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 8:24 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:24 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> For the moment at least, the TX and RX channels for DB8500 USB are
> identical, so this patch generalises them into a single structure
> and passes it twice. Once as the TX and again for the RX configuration.
> We're keeping the infrastructure the same i.e. passing the TX and RX
> separately in case they start to differ on latter incarnations of the
> platform.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 06/32] ARM: ux500: Strip out duplicate USB DMA configuration
@ 2013-04-25 8:24 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:24 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> For the moment at least, the TX and RX channels for DB8500 USB are
> identical, so this patch generalises them into a single structure
> and passes it twice. Once as the TX and again for the RX configuration.
> We're keeping the infrastructure the same i.e. passing the TX and RX
> separately in case they start to differ on latter incarnations of the
> platform.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
The DMA40 controller uses two sets of base addresses. In order to have
them automatically setup as resources by the Open Format framework we
have to set names for them. The names have to be the same as the ones
used to fetch them back out of the resource structure.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index aaa63d0..0f462b7 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -186,6 +186,7 @@
compatible = "stericsson,db8500-dma40",
"stericsson,dma40";
reg = <0x801C0000 0x1000 0x40010000 0x800>;
+ reg-names = "base", "lcpa";
interrupts = <0 25 0x4>;
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
The DMA40 controller uses two sets of base addresses. In order to have
them automatically setup as resources by the Open Format framework we
have to set names for them. The names have to be the same as the ones
used to fetch them back out of the resource structure.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index aaa63d0..0f462b7 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -186,6 +186,7 @@
compatible = "stericsson,db8500-dma40",
"stericsson,dma40";
reg = <0x801C0000 0x1000 0x40010000 0x800>;
+ reg-names = "base", "lcpa";
interrupts = <0 25 0x4>;
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* Re: [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:48 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:48 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, linus.walleij
On Thursday 18 April 2013, Lee Jones wrote:
> The DMA40 controller uses two sets of base addresses. In order to have
> them automatically setup as resources by the Open Format framework we
> have to set names for them. The names have to be the same as the ones
> used to fetch them back out of the resource structure.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Typo: s/Open Format/Open Firmware/
To be more specific, just write of_platform framework. Note that we
still get resources without passing the names, they are just not
named in that case and have to be retrieved by index.
You should also document the strings in the binding document.
ARnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
@ 2013-04-18 10:48 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:48 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> The DMA40 controller uses two sets of base addresses. In order to have
> them automatically setup as resources by the Open Format framework we
> have to set names for them. The names have to be the same as the ones
> used to fetch them back out of the resource structure.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Typo: s/Open Format/Open Firmware/
To be more specific, just write of_platform framework. Note that we
still get resources without passing the names, they are just not
named in that case and have to be retrieved by index.
You should also document the strings in the binding document.
ARnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
2013-04-18 10:48 ` Arnd Bergmann
@ 2013-04-18 11:01 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 11:01 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, linus.walleij
On Thu, 18 Apr 2013, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > The DMA40 controller uses two sets of base addresses. In order to have
> > them automatically setup as resources by the Open Format framework we
> > have to set names for them. The names have to be the same as the ones
> > used to fetch them back out of the resource structure.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Typo: s/Open Format/Open Firmware/
>
> To be more specific, just write of_platform framework. Note that we
> still get resources without passing the names, they are just not
> named in that case and have to be retrieved by index.
Okay, I'll fixup.
> You should also document the strings in the binding document.
I'll do that, thanks.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
@ 2013-04-18 11:01 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 11:01 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 18 Apr 2013, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > The DMA40 controller uses two sets of base addresses. In order to have
> > them automatically setup as resources by the Open Format framework we
> > have to set names for them. The names have to be the same as the ones
> > used to fetch them back out of the resource structure.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Typo: s/Open Format/Open Firmware/
>
> To be more specific, just write of_platform framework. Note that we
> still get resources without passing the names, they are just not
> named in that case and have to be retrieved by index.
Okay, I'll fixup.
> You should also document the strings in the binding document.
I'll do that, thanks.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
2013-04-18 10:48 ` Arnd Bergmann
@ 2013-04-18 11:09 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 11:09 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, linus.walleij
On Thu, 18 Apr 2013, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > The DMA40 controller uses two sets of base addresses. In order to have
> > them automatically setup as resources by the Open Format framework we
> > have to set names for them. The names have to be the same as the ones
> > used to fetch them back out of the resource structure.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Typo: s/Open Format/Open Firmware/
>
> To be more specific, just write of_platform framework. Note that we
> still get resources without passing the names, they are just not
> named in that case and have to be retrieved by index.
Changed to:
The DMA40 controller uses two sets of base addresses. In order to have
the resources setup by the of_platform framework so they are searchable
by name instead of index, we have to set names for them. The names have
to be the same as the ones used to fetch them back out of the resource
structure.
> You should also document the strings in the binding document.
Done.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
@ 2013-04-18 11:09 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 11:09 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 18 Apr 2013, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > The DMA40 controller uses two sets of base addresses. In order to have
> > them automatically setup as resources by the Open Format framework we
> > have to set names for them. The names have to be the same as the ones
> > used to fetch them back out of the resource structure.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Typo: s/Open Format/Open Firmware/
>
> To be more specific, just write of_platform framework. Note that we
> still get resources without passing the names, they are just not
> named in that case and have to be retrieved by index.
Changed to:
The DMA40 controller uses two sets of base addresses. In order to have
the resources setup by the of_platform framework so they are searchable
by name instead of index, we have to set names for them. The names have
to be the same as the ones used to fetch them back out of the resource
structure.
> You should also document the strings in the binding document.
Done.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 8:26 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:26 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Linus WALLEIJ, Arnd Bergmann
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The DMA40 controller uses two sets of base addresses. In order to have
> them automatically setup as resources by the Open Format framework we
> have to set names for them. The names have to be the same as the ones
> used to fetch them back out of the resource structure.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This is OK with Arnds suggested changed, but I want the patch
split off from this series and put into a device-tree-specific patch
series so I can apply this to a branch where I try to keep
all patches to the device tree files. (ux500-devicetree).
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
@ 2013-04-25 8:26 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:26 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The DMA40 controller uses two sets of base addresses. In order to have
> them automatically setup as resources by the Open Format framework we
> have to set names for them. The names have to be the same as the ones
> used to fetch them back out of the resource structure.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This is OK with Arnds suggested changed, but I want the patch
split off from this series and put into a device-tree-specific patch
series so I can apply this to a branch where I try to keep
all patches to the device tree files. (ux500-devicetree).
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
2013-04-25 8:26 ` Linus Walleij
@ 2013-04-25 9:17 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:17 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Linus WALLEIJ, Arnd Bergmann
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > The DMA40 controller uses two sets of base addresses. In order to have
> > them automatically setup as resources by the Open Format framework we
> > have to set names for them. The names have to be the same as the ones
> > used to fetch them back out of the resource structure.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> This is OK with Arnds suggested changed, but I want the patch
> split off from this series and put into a device-tree-specific patch
> series so I can apply this to a branch where I try to keep
> all patches to the device tree files. (ux500-devicetree).
Do you want to take this one separately?
Feel free and I'll remove it from this set.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
@ 2013-04-25 9:17 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:17 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > The DMA40 controller uses two sets of base addresses. In order to have
> > them automatically setup as resources by the Open Format framework we
> > have to set names for them. The names have to be the same as the ones
> > used to fetch them back out of the resource structure.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> This is OK with Arnds suggested changed, but I want the patch
> split off from this series and put into a device-tree-specific patch
> series so I can apply this to a branch where I try to keep
> all patches to the device tree files. (ux500-devicetree).
Do you want to take this one separately?
Feel free and I'll remove it from this set.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
2013-04-25 9:17 ` Lee Jones
@ 2013-04-25 12:45 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:45 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Linus WALLEIJ, Arnd Bergmann
On Thu, Apr 25, 2013 at 11:17 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> > The DMA40 controller uses two sets of base addresses. In order to have
>> > them automatically setup as resources by the Open Format framework we
>> > have to set names for them. The names have to be the same as the ones
>> > used to fetch them back out of the resource structure.
>> >
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>>
>> This is OK with Arnds suggested changed, but I want the patch
>> split off from this series and put into a device-tree-specific patch
>> series so I can apply this to a branch where I try to keep
>> all patches to the device tree files. (ux500-devicetree).
>
> Do you want to take this one separately?
>
> Feel free and I'll remove it from this set.
The problem I'm facing in the ux500 tree is that different changes
to the device tree files are colliding like hell.
So I really need those changes (to those files) to come in
separately. Usually the changes are orthogonal anyway, and
the DT stuff "could" be maintained as if it was out-of-tree.
At the core of that is basically that the DT files have a higher
evolutionary pace than the kernel code and that is straining the
merge model.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 07/32] ARM: ux500: Supply address location names for the DMA40 DMA controller
@ 2013-04-25 12:45 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:45 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 25, 2013 at 11:17 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> > The DMA40 controller uses two sets of base addresses. In order to have
>> > them automatically setup as resources by the Open Format framework we
>> > have to set names for them. The names have to be the same as the ones
>> > used to fetch them back out of the resource structure.
>> >
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>>
>> This is OK with Arnds suggested changed, but I want the patch
>> split off from this series and put into a device-tree-specific patch
>> series so I can apply this to a branch where I try to keep
>> all patches to the device tree files. (ux500-devicetree).
>
> Do you want to take this one separately?
>
> Feel free and I'll remove it from this set.
The problem I'm facing in the ux500 tree is that different changes
to the device tree files are colliding like hell.
So I really need those changes (to those files) to come in
separately. Usually the changes are orthogonal anyway, and
the DT stuff "could" be maintained as if it was out-of-tree.
At the core of that is basically that the DT files have a higher
evolutionary pace than the kernel code and that is straining the
merge model.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
The current implementation of the DMA40's local MAX() macro evaluates
its arguments more times than is necessary. This patch strips it
optimises it to only evaluate what's appropriate.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index b21a8a3..7b451b2 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -53,7 +53,7 @@
#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE BIT(0)
-#define MAX(a, b) (((a) < (b)) ? (b) : (a))
+#define MAX(a, b) ((a > b) ? a : b)
#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
The current implementation of the DMA40's local MAX() macro evaluates
its arguments more times than is necessary. This patch strips it
optimises it to only evaluate what's appropriate.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index b21a8a3..7b451b2 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -53,7 +53,7 @@
#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE BIT(0)
-#define MAX(a, b) (((a) < (b)) ? (b) : (a))
+#define MAX(a, b) ((a > b) ? a : b)
#define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
#define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* Re: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:46 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:46 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary. This patch strips it
> optimises it to only evaluate what's appropriate.
No, it does not.
> index b21a8a3..7b451b2 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -53,7 +53,7 @@
> #define D40_ALLOC_PHY BIT(30)
> #define D40_ALLOC_LOG_FREE BIT(0)
>
> -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> +#define MAX(a, b) ((a > b) ? a : b)
This just makes the macro worse in case you pass a complex expression
in, which can now have additional unwanted effects. Just drop this patch.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
@ 2013-04-18 10:46 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:46 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary. This patch strips it
> optimises it to only evaluate what's appropriate.
No, it does not.
> index b21a8a3..7b451b2 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -53,7 +53,7 @@
> #define D40_ALLOC_PHY BIT(30)
> #define D40_ALLOC_LOG_FREE BIT(0)
>
> -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> +#define MAX(a, b) ((a > b) ? a : b)
This just makes the macro worse in case you pass a complex expression
in, which can now have additional unwanted effects. Just drop this patch.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
2013-04-18 10:46 ` Arnd Bergmann
@ 2013-04-18 11:00 ` Russell King - ARM Linux
-1 siblings, 0 replies; 337+ messages in thread
From: Russell King - ARM Linux @ 2013-04-18 11:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lee Jones, Rabin Vincent, linus.walleij, Vinod Koul,
linux-kernel, Per Forlin, Dan Williams, linux-arm-kernel
On Thu, Apr 18, 2013 at 12:46:03PM +0200, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > The current implementation of the DMA40's local MAX() macro evaluates
> > its arguments more times than is necessary. This patch strips it
> > optimises it to only evaluate what's appropriate.
>
> No, it does not.
>
> > index b21a8a3..7b451b2 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -53,7 +53,7 @@
> > #define D40_ALLOC_PHY BIT(30)
> > #define D40_ALLOC_LOG_FREE BIT(0)
> >
> > -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> > +#define MAX(a, b) ((a > b) ? a : b)
>
> This just makes the macro worse in case you pass a complex expression
> in, which can now have additional unwanted effects. Just drop this patch.
Never got the original patch...
A much better idea is to get rid of that buggy MAX() macro altogether
and use the macros already provided by the kernel, which are safe from
side effects - but more importantly are _type_ _safe_. The above goes
wrong when you consider 'a' and 'b' may have different signed-ness.
Consider:
int val_in = -5;
unsigned val = MAX(val_in, 5U);
The resulting value is (unsigned)-5, not (unsigned)5.
Best use the kernel's max() or max_t() _everywhere_.
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
@ 2013-04-18 11:00 ` Russell King - ARM Linux
0 siblings, 0 replies; 337+ messages in thread
From: Russell King - ARM Linux @ 2013-04-18 11:00 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:46:03PM +0200, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > The current implementation of the DMA40's local MAX() macro evaluates
> > its arguments more times than is necessary. This patch strips it
> > optimises it to only evaluate what's appropriate.
>
> No, it does not.
>
> > index b21a8a3..7b451b2 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -53,7 +53,7 @@
> > #define D40_ALLOC_PHY BIT(30)
> > #define D40_ALLOC_LOG_FREE BIT(0)
> >
> > -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> > +#define MAX(a, b) ((a > b) ? a : b)
>
> This just makes the macro worse in case you pass a complex expression
> in, which can now have additional unwanted effects. Just drop this patch.
Never got the original patch...
A much better idea is to get rid of that buggy MAX() macro altogether
and use the macros already provided by the kernel, which are safe from
side effects - but more importantly are _type_ _safe_. The above goes
wrong when you consider 'a' and 'b' may have different signed-ness.
Consider:
int val_in = -5;
unsigned val = MAX(val_in, 5U);
The resulting value is (unsigned)-5, not (unsigned)5.
Best use the kernel's max() or max_t() _everywhere_.
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
2013-04-18 11:00 ` Russell King - ARM Linux
@ 2013-04-18 11:19 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:19 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Lee Jones, Rabin Vincent, linus.walleij, Vinod Koul,
linux-kernel, Per Forlin, Dan Williams, linux-arm-kernel
On Thursday 18 April 2013, Russell King - ARM Linux wrote:
> Never got the original patch...
>
> A much better idea is to get rid of that buggy MAX() macro altogether
> and use the macros already provided by the kernel, which are safe from
> side effects - but more importantly are type _safe_. The above goes
> wrong when you consider 'a' and 'b' may have different signed-ness.
Yes, that's what was suggested before.
> Consider:
>
> int val_in = -5;
> unsigned val = MAX(val_in, 5U);
>
> The resulting value is (unsigned)-5, not (unsigned)5.
>
> Best use the kernel's max() or max_t() _everywhere_.
Unfortunately, the (only) use of this macro is in a structure declaration
where you cannot use the syntax of max():
struct d40_base {
...
u32 reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
...
};
My preferred solution would be to remove the MAX macro here and
define a new constant
#define BACKUP_REGS_SZ ((BACKUP_REGS_SZ_V4A > BACKUP_REGS_SZ_V4B) ? \
BACKUP_REGS_SZ_V4A : BACKUP_REGS_SZ_V4B)
But I don't see it as much of an improvement over what is currently
there.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
@ 2013-04-18 11:19 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:19 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Russell King - ARM Linux wrote:
> Never got the original patch...
>
> A much better idea is to get rid of that buggy MAX() macro altogether
> and use the macros already provided by the kernel, which are safe from
> side effects - but more importantly are type _safe_. The above goes
> wrong when you consider 'a' and 'b' may have different signed-ness.
Yes, that's what was suggested before.
> Consider:
>
> int val_in = -5;
> unsigned val = MAX(val_in, 5U);
>
> The resulting value is (unsigned)-5, not (unsigned)5.
>
> Best use the kernel's max() or max_t() _everywhere_.
Unfortunately, the (only) use of this macro is in a structure declaration
where you cannot use the syntax of max():
struct d40_base {
...
u32 reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
...
};
My preferred solution would be to remove the MAX macro here and
define a new constant
#define BACKUP_REGS_SZ ((BACKUP_REGS_SZ_V4A > BACKUP_REGS_SZ_V4B) ? \
BACKUP_REGS_SZ_V4A : BACKUP_REGS_SZ_V4B)
But I don't see it as much of an improvement over what is currently
there.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
2013-04-18 10:11 ` Lee Jones
@ 2013-04-22 10:10 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:10 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:11:50AM +0100, Lee Jones wrote:
> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary. This patch strips it
> optimises it to only evaluate what's appropriate.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/dma/ste_dma40.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index b21a8a3..7b451b2 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -53,7 +53,7 @@
> #define D40_ALLOC_PHY BIT(30)
> #define D40_ALLOC_LOG_FREE BIT(0)
>
> -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> +#define MAX(a, b) ((a > b) ? a : b)
Am not a big fan of own redefines, can you use kernel max() macro instead
--
~Vinod
>
> #define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
> #define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
@ 2013-04-22 10:10 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:10 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:11:50AM +0100, Lee Jones wrote:
> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary. This patch strips it
> optimises it to only evaluate what's appropriate.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/dma/ste_dma40.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index b21a8a3..7b451b2 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -53,7 +53,7 @@
> #define D40_ALLOC_PHY BIT(30)
> #define D40_ALLOC_LOG_FREE BIT(0)
>
> -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> +#define MAX(a, b) ((a > b) ? a : b)
Am not a big fan of own redefines, can you use kernel max() macro instead
--
~Vinod
>
> #define D40_IS_SRC(dir) ((dir == STEDMA40_PERIPH_TO_MEM) ? true : false)
> #define D40_IS_DST(dir) (((dir == STEDMA40_MEM_TO_PERIPH) || \
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
2013-04-22 10:10 ` Vinod Koul
@ 2013-04-22 10:53 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:53 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Mon, 22 Apr 2013, Vinod Koul wrote:
> On Thu, Apr 18, 2013 at 11:11:50AM +0100, Lee Jones wrote:
> > The current implementation of the DMA40's local MAX() macro evaluates
> > its arguments more times than is necessary. This patch strips it
> > optimises it to only evaluate what's appropriate.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/dma/ste_dma40.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index b21a8a3..7b451b2 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -53,7 +53,7 @@
> > #define D40_ALLOC_PHY BIT(30)
> > #define D40_ALLOC_LOG_FREE BIT(0)
> >
> > -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> > +#define MAX(a, b) ((a > b) ? a : b)
> Am not a big fan of own redefines, can you use kernel max() macro instead
Unfortunately not in this instance, as the kernel max() macro uses
curly braces and is not suitable for this use-case. There is a thread
regarding this on the MLs with Arnd Bergmann, Russell King and myself.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
@ 2013-04-22 10:53 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:53 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 22 Apr 2013, Vinod Koul wrote:
> On Thu, Apr 18, 2013 at 11:11:50AM +0100, Lee Jones wrote:
> > The current implementation of the DMA40's local MAX() macro evaluates
> > its arguments more times than is necessary. This patch strips it
> > optimises it to only evaluate what's appropriate.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/dma/ste_dma40.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index b21a8a3..7b451b2 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -53,7 +53,7 @@
> > #define D40_ALLOC_PHY BIT(30)
> > #define D40_ALLOC_LOG_FREE BIT(0)
> >
> > -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> > +#define MAX(a, b) ((a > b) ? a : b)
> Am not a big fan of own redefines, can you use kernel max() macro instead
Unfortunately not in this instance, as the kernel max() macro uses
curly braces and is not suitable for this use-case. There is a thread
regarding this on the MLs with Arnd Bergmann, Russell King and myself.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 08/32 v2] dmaengine: ste_dma40: Remove home-brew MAX() macro
2013-04-18 10:11 ` Lee Jones
@ 2013-04-24 8:49 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:49 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
The current implementation of the DMA40's local MAX() macro evaluates
its arguments more times than is necessary and it not type checked.
This patch strips replaces it with a new, more efficient constant.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index cc93416..a1984d2 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -53,8 +53,6 @@
#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE 0
-#define MAX(a, b) (((a) < (b)) ? (b) : (a))
-
#define D40_IS_SRC(dir) (dir == STEDMA40_PERIPH_TO_MEM)
#define D40_IS_DST(dir) ((dir == STEDMA40_MEM_TO_PERIPH) || \
(dir == STEDMA40_MEM_TO_MEM))
@@ -206,6 +204,9 @@ static u32 d40_backup_regs_chan[] = {
D40_CHAN_REG_SDLNK,
};
+#define BACKUP_REGS_SZ_MAX ((BACKUP_REGS_SZ_V4A > BACKUP_REGS_SZ_V4B) ? \
+ BACKUP_REGS_SZ_V4A : BACKUP_REGS_SZ_V4B)
+
/**
* struct d40_interrupt_lookup - lookup table for interrupt handler
*
@@ -569,7 +570,7 @@ struct d40_base {
resource_size_t lcpa_size;
struct kmem_cache *desc_slab;
u32 reg_val_backup[BACKUP_REGS_SZ];
- u32 reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
+ u32 reg_val_backup_v4[BACKUP_REGS_SZ_MAX];
u32 *reg_val_backup_chan;
u16 gcc_pwr_off_mask;
bool initialized;
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 08/32 v2] dmaengine: ste_dma40: Remove home-brew MAX() macro
@ 2013-04-24 8:49 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:49 UTC (permalink / raw)
To: linux-arm-kernel
The current implementation of the DMA40's local MAX() macro evaluates
its arguments more times than is necessary and it not type checked.
This patch strips replaces it with a new, more efficient constant.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index cc93416..a1984d2 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -53,8 +53,6 @@
#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE 0
-#define MAX(a, b) (((a) < (b)) ? (b) : (a))
-
#define D40_IS_SRC(dir) (dir == STEDMA40_PERIPH_TO_MEM)
#define D40_IS_DST(dir) ((dir == STEDMA40_MEM_TO_PERIPH) || \
(dir == STEDMA40_MEM_TO_MEM))
@@ -206,6 +204,9 @@ static u32 d40_backup_regs_chan[] = {
D40_CHAN_REG_SDLNK,
};
+#define BACKUP_REGS_SZ_MAX ((BACKUP_REGS_SZ_V4A > BACKUP_REGS_SZ_V4B) ? \
+ BACKUP_REGS_SZ_V4A : BACKUP_REGS_SZ_V4B)
+
/**
* struct d40_interrupt_lookup - lookup table for interrupt handler
*
@@ -569,7 +570,7 @@ struct d40_base {
resource_size_t lcpa_size;
struct kmem_cache *desc_slab;
u32 reg_val_backup[BACKUP_REGS_SZ];
- u32 reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
+ u32 reg_val_backup_v4[BACKUP_REGS_SZ_MAX];
u32 *reg_val_backup_chan;
u16 gcc_pwr_off_mask;
bool initialized;
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 08/32 v2] dmaengine: ste_dma40: Remove home-brew MAX() macro
2013-04-24 8:49 ` Lee Jones
@ 2013-04-25 12:48 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:48 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Wed, Apr 24, 2013 at 10:49 AM, Lee Jones <lee.jones@linaro.org> wrote:
> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary and it not type checked.
> This patch strips replaces it with a new, more efficient constant.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Ah this v2 version is OK, atleast it makes the kernel look nicer.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 08/32 v2] dmaengine: ste_dma40: Remove home-brew MAX() macro
@ 2013-04-25 12:48 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:48 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 24, 2013 at 10:49 AM, Lee Jones <lee.jones@linaro.org> wrote:
> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary and it not type checked.
> This patch strips replaces it with a new, more efficient constant.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Ah this v2 version is OK, atleast it makes the kernel look nicer.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 08/32 v2] dmaengine: ste_dma40: Remove home-brew MAX() macro
2013-04-25 12:48 ` Linus Walleij
@ 2013-05-01 14:28 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-05-01 14:28 UTC (permalink / raw)
To: vinod.koul
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent,
linus.walleij
> > The current implementation of the DMA40's local MAX() macro evaluates
> > its arguments more times than is necessary and it not type checked.
> > This patch strips replaces it with a new, more efficient constant.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Ah this v2 version is OK, atleast it makes the kernel look nicer.
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Vinod, poke.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 08/32 v2] dmaengine: ste_dma40: Remove home-brew MAX() macro
@ 2013-05-01 14:28 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-05-01 14:28 UTC (permalink / raw)
To: linux-arm-kernel
> > The current implementation of the DMA40's local MAX() macro evaluates
> > its arguments more times than is necessary and it not type checked.
> > This patch strips replaces it with a new, more efficient constant.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Ah this v2 version is OK, atleast it makes the kernel look nicer.
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Vinod, poke.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 8:36 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:36 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary. This patch strips it
> optimises it to only evaluate what's appropriate.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(...)
> -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> +#define MAX(a, b) ((a > b) ? a : b)
Much has been said about this patch already, but notice what it is
used for instead, one single thing at compile-time:
struct d40_base {
(...)
u32
reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
(...)
};
i.e. defining the size of that array at compile-time.
The actual size is figured out in d40_hw_detect_init().
So what about you just devm_kmalloc() that array instead and
delete this macro. That is the real fix.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
@ 2013-04-25 8:36 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:36 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The current implementation of the DMA40's local MAX() macro evaluates
> its arguments more times than is necessary. This patch strips it
> optimises it to only evaluate what's appropriate.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(...)
> -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> +#define MAX(a, b) ((a > b) ? a : b)
Much has been said about this patch already, but notice what it is
used for instead, one single thing at compile-time:
struct d40_base {
(...)
u32
reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
(...)
};
i.e. defining the size of that array at compile-time.
The actual size is figured out in d40_hw_detect_init().
So what about you just devm_kmalloc() that array instead and
delete this macro. That is the real fix.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
2013-04-25 8:36 ` Linus Walleij
@ 2013-04-25 9:15 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:15 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > The current implementation of the DMA40's local MAX() macro evaluates
> > its arguments more times than is necessary. This patch strips it
> > optimises it to only evaluate what's appropriate.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> (...)
> > -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> > +#define MAX(a, b) ((a > b) ? a : b)
>
> Much has been said about this patch already, but notice what it is
> used for instead, one single thing at compile-time:
>
> struct d40_base {
> (...)
> u32
> reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
> (...)
> };
>
> i.e. defining the size of that array at compile-time.
>
> The actual size is figured out in d40_hw_detect_init().
>
> So what about you just devm_kmalloc() that array instead and
> delete this macro. That is the real fix.
I'm happy to do it, but please see v2 of this patch first.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 08/32] dmaengine: ste_dma40: Optimise local MAX() macro
@ 2013-04-25 9:15 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:15 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > The current implementation of the DMA40's local MAX() macro evaluates
> > its arguments more times than is necessary. This patch strips it
> > optimises it to only evaluate what's appropriate.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Reported-by: Harvey Harrison <harvey.harrison@gmail.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> (...)
> > -#define MAX(a, b) (((a) < (b)) ? (b) : (a))
> > +#define MAX(a, b) ((a > b) ? a : b)
>
> Much has been said about this patch already, but notice what it is
> used for instead, one single thing at compile-time:
>
> struct d40_base {
> (...)
> u32
> reg_val_backup_v4[MAX(BACKUP_REGS_SZ_V4A, BACKUP_REGS_SZ_V4B)];
> (...)
> };
>
> i.e. defining the size of that array at compile-time.
>
> The actual size is figured out in d40_hw_detect_init().
>
> So what about you just devm_kmalloc() that array instead and
> delete this macro. That is the real fix.
I'm happy to do it, but please see v2 of this patch first.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes from SDI DMA configs
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
DMA configuration data is now allocated in the MMCI driver, so these
are just ignored.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500-sdi.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 5c28216..553ace6 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -65,16 +65,12 @@ struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV29_SD_MM0,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV29_SD_MM0,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
#endif
@@ -134,16 +130,12 @@ static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV32_SD_MM1,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
static struct stedma40_chan_cfg sdi1_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV32_SD_MM1,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
#endif
@@ -169,16 +161,12 @@ struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV28_SD_MM2,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
static struct stedma40_chan_cfg mop500_sdi2_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV28_SD_MM2,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
#endif
@@ -205,16 +193,12 @@ struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV42_SD_MM4,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV42_SD_MM4,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
#endif
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes from SDI DMA configs
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
DMA configuration data is now allocated in the MMCI driver, so these
are just ignored.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500-sdi.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 5c28216..553ace6 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -65,16 +65,12 @@ struct stedma40_chan_cfg mop500_sdi0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV29_SD_MM0,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV29_SD_MM0,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
#endif
@@ -134,16 +130,12 @@ static struct stedma40_chan_cfg sdi1_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV32_SD_MM1,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
static struct stedma40_chan_cfg sdi1_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV32_SD_MM1,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
#endif
@@ -169,16 +161,12 @@ struct stedma40_chan_cfg mop500_sdi2_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV28_SD_MM2,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
static struct stedma40_chan_cfg mop500_sdi2_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV28_SD_MM2,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
#endif
@@ -205,16 +193,12 @@ struct stedma40_chan_cfg mop500_sdi4_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV42_SD_MM4,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV42_SD_MM4,
- .src_info.data_width = STEDMA40_WORD_WIDTH,
- .dst_info.data_width = STEDMA40_WORD_WIDTH,
};
#endif
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes from SDI DMA configs
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 8:44 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:44 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> DMA configuration data is now allocated in the MMCI driver, so these
> are just ignored.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
I tried just applying this (since it's pretty stand-alone) but seems to
be dependent on things not yet in Torvalds tree so lets keep it in this
series then...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes from SDI DMA configs
@ 2013-04-25 8:44 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:44 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> DMA configuration data is now allocated in the MMCI driver, so these
> are just ignored.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
I tried just applying this (since it's pretty stand-alone) but seems to
be dependent on things not yet in Torvalds tree so lets keep it in this
series then...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes from SDI DMA configs
2013-04-25 8:44 ` Linus Walleij
@ 2013-04-25 9:14 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:14 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > DMA configuration data is now allocated in the MMCI driver, so these
> > are just ignored.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> I tried just applying this (since it's pretty stand-alone) but seems to
> be dependent on things not yet in Torvalds tree so lets keep it in this
> series then...
Ideally I'd like to keep them all in the same branch, as it may lead
to confusion/conflicts later down the line (I'm still coding a lot of
this stuff).
Naturally, I'll go with whatever you think is best, but this is my
preference.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes from SDI DMA configs
@ 2013-04-25 9:14 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:14 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > DMA configuration data is now allocated in the MMCI driver, so these
> > are just ignored.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> I tried just applying this (since it's pretty stand-alone) but seems to
> be dependent on things not yet in Torvalds tree so lets keep it in this
> series then...
Ideally I'd like to keep them all in the same branch, as it may lead
to confusion/conflicts later down the line (I'm still coding a lot of
this stuff).
Naturally, I'll go with whatever you think is best, but this is my
preference.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes from SDI DMA configs
2013-04-25 9:14 ` Lee Jones
@ 2013-04-25 12:49 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:49 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 25, 2013 at 11:14 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> > DMA configuration data is now allocated in the MMCI driver, so these
>> > are just ignored.
>> >
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> I tried just applying this (since it's pretty stand-alone) but seems to
>> be dependent on things not yet in Torvalds tree so lets keep it in this
>> series then...
>
> Ideally I'd like to keep them all in the same branch, as it may lead
> to confusion/conflicts later down the line (I'm still coding a lot of
> this stuff).
>
> Naturally, I'll go with whatever you think is best, but this is my
> preference.
This works find for now, I just want the DT changes kept separately
because I'm in hell with these right now and don't want to end up
there again next merge cycle.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes from SDI DMA configs
@ 2013-04-25 12:49 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:49 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 25, 2013 at 11:14 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> > DMA configuration data is now allocated in the MMCI driver, so these
>> > are just ignored.
>> >
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> I tried just applying this (since it's pretty stand-alone) but seems to
>> be dependent on things not yet in Torvalds tree so lets keep it in this
>> series then...
>
> Ideally I'd like to keep them all in the same branch, as it may lead
> to confusion/conflicts later down the line (I'm still coding a lot of
> this stuff).
>
> Naturally, I'll go with whatever you think is best, but this is my
> preference.
This works find for now, I just want the DT changes kept separately
because I'm in hell with these right now and don't want to end up
there again next merge cycle.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes from SDI DMA configs
2013-04-25 12:49 ` Linus Walleij
@ 2013-04-25 13:13 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 13:13 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 11:14 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 25 Apr 2013, Linus Walleij wrote:
> >
> >> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> >>
> >> > DMA configuration data is now allocated in the MMCI driver, so these
> >> > are just ignored.
> >> >
> >> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >>
> >> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> >>
> >> I tried just applying this (since it's pretty stand-alone) but seems to
> >> be dependent on things not yet in Torvalds tree so lets keep it in this
> >> series then...
> >
> > Ideally I'd like to keep them all in the same branch, as it may lead
> > to confusion/conflicts later down the line (I'm still coding a lot of
> > this stuff).
> >
> > Naturally, I'll go with whatever you think is best, but this is my
> > preference.
>
> This works find for now, I just want the DT changes kept separately
> because I'm in hell with these right now and don't want to end up
> there again next merge cycle.
Sure. Just let me know what you plan to manually apply and I'll do my
utmost to keep things sane in the patch-set.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 09/32] ARM: ux500: Remove unused 'data_width' attributes from SDI DMA configs
@ 2013-04-25 13:13 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 13:13 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 11:14 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 25 Apr 2013, Linus Walleij wrote:
> >
> >> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> >>
> >> > DMA configuration data is now allocated in the MMCI driver, so these
> >> > are just ignored.
> >> >
> >> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >>
> >> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> >>
> >> I tried just applying this (since it's pretty stand-alone) but seems to
> >> be dependent on things not yet in Torvalds tree so lets keep it in this
> >> series then...
> >
> > Ideally I'd like to keep them all in the same branch, as it may lead
> > to confusion/conflicts later down the line (I'm still coding a lot of
> > this stuff).
> >
> > Naturally, I'll go with whatever you think is best, but this is my
> > preference.
>
> This works find for now, I just want the DT changes kept separately
> because I'm in hell with these right now and don't want to end up
> there again next merge cycle.
Sure. Just let me know what you plan to manually apply and I'll do my
utmost to keep things sane in the patch-set.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 10/32] ARM: ux500: Remove unused 'data_width' attributes from SSP DMA configs
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
DMA configuration data is now allocated in the SSP driver, so these
are just ignored.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index a8b3ad9..35fd82f 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -495,16 +495,12 @@ static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV8_SSP0,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg ssp0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV8_SSP0,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
#endif
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 10/32] ARM: ux500: Remove unused 'data_width' attributes from SSP DMA configs
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
DMA configuration data is now allocated in the SSP driver, so these
are just ignored.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index a8b3ad9..35fd82f 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -495,16 +495,12 @@ static struct stedma40_chan_cfg ssp0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV8_SSP0,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg ssp0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV8_SSP0,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
#endif
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 10/32] ARM: ux500: Remove unused 'data_width' attributes from SSP DMA configs
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 8:45 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:45 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> DMA configuration data is now allocated in the SSP driver, so these
> are just ignored.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 10/32] ARM: ux500: Remove unused 'data_width' attributes from SSP DMA configs
@ 2013-04-25 8:45 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:45 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> DMA configuration data is now allocated in the SSP driver, so these
> are just ignored.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 11/32] ARM: ux500: Remove unused 'data_width' attributes from UART DMA configs
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
DMA configuration data is now allocated in the UART driver, so these
are just ignored.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 35fd82f..883dc66 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -530,48 +530,36 @@ static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV13_UART0,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV13_UART0,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV12_UART1,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV12_UART1,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV11_UART2,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg uart2_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV11_UART2,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
#endif
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 11/32] ARM: ux500: Remove unused 'data_width' attributes from UART DMA configs
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
DMA configuration data is now allocated in the UART driver, so these
are just ignored.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 35fd82f..883dc66 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -530,48 +530,36 @@ static struct stedma40_chan_cfg uart0_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV13_UART0,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg uart0_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV13_UART0,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg uart1_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV12_UART1,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg uart1_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV12_UART1,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg uart2_dma_cfg_rx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_PERIPH_TO_MEM,
.dev_type = DB8500_DMA_DEV11_UART2,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
static struct stedma40_chan_cfg uart2_dma_cfg_tx = {
.mode = STEDMA40_MODE_LOGICAL,
.dir = STEDMA40_MEM_TO_PERIPH,
.dev_type = DB8500_DMA_DEV11_UART2,
- .src_info.data_width = STEDMA40_BYTE_WIDTH,
- .dst_info.data_width = STEDMA40_BYTE_WIDTH,
};
#endif
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 11/32] ARM: ux500: Remove unused 'data_width' attributes from UART DMA configs
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 8:45 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:45 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> DMA configuration data is now allocated in the UART driver, so these
> are just ignored.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 11/32] ARM: ux500: Remove unused 'data_width' attributes from UART DMA configs
@ 2013-04-25 8:45 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 8:45 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> DMA configuration data is now allocated in the UART driver, so these
> are just ignored.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
'psize' is used to calculate the maximum DMA burst size. However it
is only taken into consideration when editing the DMA channel's
configuration. The Audio DMA platform data is only used to allocate
a channel, not configure it. That will be done at a later date within
the MSP driver.
We're also removing comments which are no longer required, as
'data_width' is no longer set in any device's platform data period.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500-audio.c | 38 ------------------------------
1 file changed, 38 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index f012cfa..972bec0 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -23,25 +23,13 @@
static struct stedma40_chan_cfg msp0_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
-
.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
-
- .src_info.psize = STEDMA40_PSIZE_LOG_4,
- .dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
- /* data_width is set during configuration */
};
static struct stedma40_chan_cfg msp0_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
-
.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
-
- .src_info.psize = STEDMA40_PSIZE_LOG_4,
- .dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
- /* data_width is set during configuration */
};
struct msp_i2s_platform_data msp0_platform_data = {
@@ -53,25 +41,13 @@ struct msp_i2s_platform_data msp0_platform_data = {
static struct stedma40_chan_cfg msp1_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
-
.dev_type = DB8500_DMA_DEV30_MSP3,
-
- .src_info.psize = STEDMA40_PSIZE_LOG_4,
- .dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
- /* data_width is set during configuration */
};
static struct stedma40_chan_cfg msp1_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
-
.dev_type = DB8500_DMA_DEV30_MSP1,
-
- .src_info.psize = STEDMA40_PSIZE_LOG_4,
- .dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
- /* data_width is set during configuration */
};
struct msp_i2s_platform_data msp1_platform_data = {
@@ -83,29 +59,15 @@ struct msp_i2s_platform_data msp1_platform_data = {
static struct stedma40_chan_cfg msp2_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
-
.dev_type = DB8500_DMA_DEV14_MSP2,
-
- /* MSP2 DMA doesn't work with PSIZE == 4 on DB8500v2 */
- .src_info.psize = STEDMA40_PSIZE_LOG_1,
- .dst_info.psize = STEDMA40_PSIZE_LOG_1,
-
- /* data_width is set during configuration */
};
static struct stedma40_chan_cfg msp2_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
-
.dev_type = DB8500_DMA_DEV14_MSP2,
-
- .src_info.psize = STEDMA40_PSIZE_LOG_4,
- .dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
.use_fixed_channel = true,
.phy_channel = 1,
-
- /* data_width is set during configuration */
};
static struct platform_device *db8500_add_msp_i2s(struct device *parent,
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
'psize' is used to calculate the maximum DMA burst size. However it
is only taken into consideration when editing the DMA channel's
configuration. The Audio DMA platform data is only used to allocate
a channel, not configure it. That will be done at a later date within
the MSP driver.
We're also removing comments which are no longer required, as
'data_width' is no longer set in any device's platform data period.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500-audio.c | 38 ------------------------------
1 file changed, 38 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index f012cfa..972bec0 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -23,25 +23,13 @@
static struct stedma40_chan_cfg msp0_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
-
.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
-
- .src_info.psize = STEDMA40_PSIZE_LOG_4,
- .dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
- /* data_width is set during configuration */
};
static struct stedma40_chan_cfg msp0_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
-
.dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
-
- .src_info.psize = STEDMA40_PSIZE_LOG_4,
- .dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
- /* data_width is set during configuration */
};
struct msp_i2s_platform_data msp0_platform_data = {
@@ -53,25 +41,13 @@ struct msp_i2s_platform_data msp0_platform_data = {
static struct stedma40_chan_cfg msp1_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
-
.dev_type = DB8500_DMA_DEV30_MSP3,
-
- .src_info.psize = STEDMA40_PSIZE_LOG_4,
- .dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
- /* data_width is set during configuration */
};
static struct stedma40_chan_cfg msp1_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
-
.dev_type = DB8500_DMA_DEV30_MSP1,
-
- .src_info.psize = STEDMA40_PSIZE_LOG_4,
- .dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
- /* data_width is set during configuration */
};
struct msp_i2s_platform_data msp1_platform_data = {
@@ -83,29 +59,15 @@ struct msp_i2s_platform_data msp1_platform_data = {
static struct stedma40_chan_cfg msp2_dma_rx = {
.high_priority = true,
.dir = STEDMA40_PERIPH_TO_MEM,
-
.dev_type = DB8500_DMA_DEV14_MSP2,
-
- /* MSP2 DMA doesn't work with PSIZE == 4 on DB8500v2 */
- .src_info.psize = STEDMA40_PSIZE_LOG_1,
- .dst_info.psize = STEDMA40_PSIZE_LOG_1,
-
- /* data_width is set during configuration */
};
static struct stedma40_chan_cfg msp2_dma_tx = {
.high_priority = true,
.dir = STEDMA40_MEM_TO_PERIPH,
-
.dev_type = DB8500_DMA_DEV14_MSP2,
-
- .src_info.psize = STEDMA40_PSIZE_LOG_4,
- .dst_info.psize = STEDMA40_PSIZE_LOG_4,
-
.use_fixed_channel = true,
.phy_channel = 1,
-
- /* data_width is set during configuration */
};
static struct platform_device *db8500_add_msp_i2s(struct device *parent,
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 9:00 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 9:00 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ, Ola LILJA2
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> 'psize' is used to calculate the maximum DMA burst size. However it
> is only taken into consideration when editing the DMA channel's
> configuration. The Audio DMA platform data is only used to allocate
> a channel, not configure it. That will be done at a later date within
> the MSP driver.
>
> We're also removing comments which are no longer required, as
> 'data_width' is no longer set in any device's platform data period.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Pls CC patches like this to Ola LILJA.
So if I understand correctly this is now handled by
dmaengine_pcm.c, os that right?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
@ 2013-04-25 9:00 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 9:00 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> 'psize' is used to calculate the maximum DMA burst size. However it
> is only taken into consideration when editing the DMA channel's
> configuration. The Audio DMA platform data is only used to allocate
> a channel, not configure it. That will be done at a later date within
> the MSP driver.
>
> We're also removing comments which are no longer required, as
> 'data_width' is no longer set in any device's platform data period.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Pls CC patches like this to Ola LILJA.
So if I understand correctly this is now handled by
dmaengine_pcm.c, os that right?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
2013-04-18 10:11 ` Lee Jones
@ 2013-05-01 14:42 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-05-01 14:42 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij
On Thu, 18 Apr 2013, Lee Jones wrote:
> 'psize' is used to calculate the maximum DMA burst size. However it
> is only taken into consideration when editing the DMA channel's
> configuration. The Audio DMA platform data is only used to allocate
> a channel, not configure it. That will be done at a later date within
> the MSP driver.
>
> We're also removing comments which are no longer required, as
> 'data_width' is no longer set in any device's platform data period.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/mach-ux500/board-mop500-audio.c | 38 ------------------------------
> 1 file changed, 38 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
> index f012cfa..972bec0 100644
> --- a/arch/arm/mach-ux500/board-mop500-audio.c
> +++ b/arch/arm/mach-ux500/board-mop500-audio.c
> @@ -23,25 +23,13 @@
> static struct stedma40_chan_cfg msp0_dma_rx = {
> .high_priority = true,
> .dir = STEDMA40_PERIPH_TO_MEM,
> -
> .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
> -
> - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> -
> - /* data_width is set during configuration */
> };
>
> static struct stedma40_chan_cfg msp0_dma_tx = {
> .high_priority = true,
> .dir = STEDMA40_MEM_TO_PERIPH,
> -
> .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
> -
> - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> -
> - /* data_width is set during configuration */
> };
>
> struct msp_i2s_platform_data msp0_platform_data = {
> @@ -53,25 +41,13 @@ struct msp_i2s_platform_data msp0_platform_data = {
> static struct stedma40_chan_cfg msp1_dma_rx = {
> .high_priority = true,
> .dir = STEDMA40_PERIPH_TO_MEM,
> -
> .dev_type = DB8500_DMA_DEV30_MSP3,
> -
> - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> -
> - /* data_width is set during configuration */
> };
>
> static struct stedma40_chan_cfg msp1_dma_tx = {
> .high_priority = true,
> .dir = STEDMA40_MEM_TO_PERIPH,
> -
> .dev_type = DB8500_DMA_DEV30_MSP1,
> -
> - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> -
> - /* data_width is set during configuration */
> };
>
> struct msp_i2s_platform_data msp1_platform_data = {
> @@ -83,29 +59,15 @@ struct msp_i2s_platform_data msp1_platform_data = {
> static struct stedma40_chan_cfg msp2_dma_rx = {
> .high_priority = true,
> .dir = STEDMA40_PERIPH_TO_MEM,
> -
> .dev_type = DB8500_DMA_DEV14_MSP2,
> -
> - /* MSP2 DMA doesn't work with PSIZE == 4 on DB8500v2 */
> - .src_info.psize = STEDMA40_PSIZE_LOG_1,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_1,
> -
> - /* data_width is set during configuration */
> };
>
> static struct stedma40_chan_cfg msp2_dma_tx = {
> .high_priority = true,
> .dir = STEDMA40_MEM_TO_PERIPH,
> -
> .dev_type = DB8500_DMA_DEV14_MSP2,
> -
> - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> -
> .use_fixed_channel = true,
> .phy_channel = 1,
> -
> - /* data_width is set during configuration */
> };
>
> static struct platform_device *db8500_add_msp_i2s(struct device *parent,
Linus, poke.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
@ 2013-05-01 14:42 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-05-01 14:42 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 18 Apr 2013, Lee Jones wrote:
> 'psize' is used to calculate the maximum DMA burst size. However it
> is only taken into consideration when editing the DMA channel's
> configuration. The Audio DMA platform data is only used to allocate
> a channel, not configure it. That will be done at a later date within
> the MSP driver.
>
> We're also removing comments which are no longer required, as
> 'data_width' is no longer set in any device's platform data period.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/mach-ux500/board-mop500-audio.c | 38 ------------------------------
> 1 file changed, 38 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
> index f012cfa..972bec0 100644
> --- a/arch/arm/mach-ux500/board-mop500-audio.c
> +++ b/arch/arm/mach-ux500/board-mop500-audio.c
> @@ -23,25 +23,13 @@
> static struct stedma40_chan_cfg msp0_dma_rx = {
> .high_priority = true,
> .dir = STEDMA40_PERIPH_TO_MEM,
> -
> .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
> -
> - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> -
> - /* data_width is set during configuration */
> };
>
> static struct stedma40_chan_cfg msp0_dma_tx = {
> .high_priority = true,
> .dir = STEDMA40_MEM_TO_PERIPH,
> -
> .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
> -
> - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> -
> - /* data_width is set during configuration */
> };
>
> struct msp_i2s_platform_data msp0_platform_data = {
> @@ -53,25 +41,13 @@ struct msp_i2s_platform_data msp0_platform_data = {
> static struct stedma40_chan_cfg msp1_dma_rx = {
> .high_priority = true,
> .dir = STEDMA40_PERIPH_TO_MEM,
> -
> .dev_type = DB8500_DMA_DEV30_MSP3,
> -
> - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> -
> - /* data_width is set during configuration */
> };
>
> static struct stedma40_chan_cfg msp1_dma_tx = {
> .high_priority = true,
> .dir = STEDMA40_MEM_TO_PERIPH,
> -
> .dev_type = DB8500_DMA_DEV30_MSP1,
> -
> - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> -
> - /* data_width is set during configuration */
> };
>
> struct msp_i2s_platform_data msp1_platform_data = {
> @@ -83,29 +59,15 @@ struct msp_i2s_platform_data msp1_platform_data = {
> static struct stedma40_chan_cfg msp2_dma_rx = {
> .high_priority = true,
> .dir = STEDMA40_PERIPH_TO_MEM,
> -
> .dev_type = DB8500_DMA_DEV14_MSP2,
> -
> - /* MSP2 DMA doesn't work with PSIZE == 4 on DB8500v2 */
> - .src_info.psize = STEDMA40_PSIZE_LOG_1,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_1,
> -
> - /* data_width is set during configuration */
> };
>
> static struct stedma40_chan_cfg msp2_dma_tx = {
> .high_priority = true,
> .dir = STEDMA40_MEM_TO_PERIPH,
> -
> .dev_type = DB8500_DMA_DEV14_MSP2,
> -
> - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> -
> .use_fixed_channel = true,
> .phy_channel = 1,
> -
> - /* data_width is set during configuration */
> };
>
> static struct platform_device *db8500_add_msp_i2s(struct device *parent,
Linus, poke.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
2013-05-01 14:42 ` Lee Jones
@ 2013-05-02 8:38 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-05-02 8:38 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij
On Wed, 01 May 2013, Lee Jones wrote:
> On Thu, 18 Apr 2013, Lee Jones wrote:
>
> > 'psize' is used to calculate the maximum DMA burst size. However it
> > is only taken into consideration when editing the DMA channel's
> > configuration. The Audio DMA platform data is only used to allocate
> > a channel, not configure it. That will be done at a later date within
> > the MSP driver.
> >
> > We're also removing comments which are no longer required, as
> > 'data_width' is no longer set in any device's platform data period.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > arch/arm/mach-ux500/board-mop500-audio.c | 38 ------------------------------
> > 1 file changed, 38 deletions(-)
> >
> > diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
> > index f012cfa..972bec0 100644
> > --- a/arch/arm/mach-ux500/board-mop500-audio.c
> > +++ b/arch/arm/mach-ux500/board-mop500-audio.c
> > @@ -23,25 +23,13 @@
> > static struct stedma40_chan_cfg msp0_dma_rx = {
> > .high_priority = true,
> > .dir = STEDMA40_PERIPH_TO_MEM,
> > -
> > .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
> > -
> > - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > static struct stedma40_chan_cfg msp0_dma_tx = {
> > .high_priority = true,
> > .dir = STEDMA40_MEM_TO_PERIPH,
> > -
> > .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
> > -
> > - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > struct msp_i2s_platform_data msp0_platform_data = {
> > @@ -53,25 +41,13 @@ struct msp_i2s_platform_data msp0_platform_data = {
> > static struct stedma40_chan_cfg msp1_dma_rx = {
> > .high_priority = true,
> > .dir = STEDMA40_PERIPH_TO_MEM,
> > -
> > .dev_type = DB8500_DMA_DEV30_MSP3,
> > -
> > - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > static struct stedma40_chan_cfg msp1_dma_tx = {
> > .high_priority = true,
> > .dir = STEDMA40_MEM_TO_PERIPH,
> > -
> > .dev_type = DB8500_DMA_DEV30_MSP1,
> > -
> > - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > struct msp_i2s_platform_data msp1_platform_data = {
> > @@ -83,29 +59,15 @@ struct msp_i2s_platform_data msp1_platform_data = {
> > static struct stedma40_chan_cfg msp2_dma_rx = {
> > .high_priority = true,
> > .dir = STEDMA40_PERIPH_TO_MEM,
> > -
> > .dev_type = DB8500_DMA_DEV14_MSP2,
> > -
> > - /* MSP2 DMA doesn't work with PSIZE == 4 on DB8500v2 */
> > - .src_info.psize = STEDMA40_PSIZE_LOG_1,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_1,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > static struct stedma40_chan_cfg msp2_dma_tx = {
> > .high_priority = true,
> > .dir = STEDMA40_MEM_TO_PERIPH,
> > -
> > .dev_type = DB8500_DMA_DEV14_MSP2,
> > -
> > - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> > -
> > .use_fixed_channel = true,
> > .phy_channel = 1,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > static struct platform_device *db8500_add_msp_i2s(struct device *parent,
>
> Linus, poke.
I've just seen this response from you (it didn't make it to my offline
mail store for some reason):
> Linus Walleij wrote:
> So if I understand correctly this is now handled by dmaengine_pcm.c,
> os that right?
Unfortunately not. At the moment ux500 sound is very broken in
Mainline. I looked at it recently and the driver is almost completely
different to the one maintained internally.
There were DMA changes relating to this driver pending for v3.10,
which I believe have just been taking into -next. I will straighten
out the DMA issues shortly, but there are other ones remaining still -
mostly surrounding widgets. Ideally this is something Ola should fix,
as he has the expertise to do so, but he doesn't appear to have been
very active upstream of late.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
@ 2013-05-02 8:38 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-05-02 8:38 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 01 May 2013, Lee Jones wrote:
> On Thu, 18 Apr 2013, Lee Jones wrote:
>
> > 'psize' is used to calculate the maximum DMA burst size. However it
> > is only taken into consideration when editing the DMA channel's
> > configuration. The Audio DMA platform data is only used to allocate
> > a channel, not configure it. That will be done at a later date within
> > the MSP driver.
> >
> > We're also removing comments which are no longer required, as
> > 'data_width' is no longer set in any device's platform data period.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > arch/arm/mach-ux500/board-mop500-audio.c | 38 ------------------------------
> > 1 file changed, 38 deletions(-)
> >
> > diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
> > index f012cfa..972bec0 100644
> > --- a/arch/arm/mach-ux500/board-mop500-audio.c
> > +++ b/arch/arm/mach-ux500/board-mop500-audio.c
> > @@ -23,25 +23,13 @@
> > static struct stedma40_chan_cfg msp0_dma_rx = {
> > .high_priority = true,
> > .dir = STEDMA40_PERIPH_TO_MEM,
> > -
> > .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
> > -
> > - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > static struct stedma40_chan_cfg msp0_dma_tx = {
> > .high_priority = true,
> > .dir = STEDMA40_MEM_TO_PERIPH,
> > -
> > .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
> > -
> > - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > struct msp_i2s_platform_data msp0_platform_data = {
> > @@ -53,25 +41,13 @@ struct msp_i2s_platform_data msp0_platform_data = {
> > static struct stedma40_chan_cfg msp1_dma_rx = {
> > .high_priority = true,
> > .dir = STEDMA40_PERIPH_TO_MEM,
> > -
> > .dev_type = DB8500_DMA_DEV30_MSP3,
> > -
> > - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > static struct stedma40_chan_cfg msp1_dma_tx = {
> > .high_priority = true,
> > .dir = STEDMA40_MEM_TO_PERIPH,
> > -
> > .dev_type = DB8500_DMA_DEV30_MSP1,
> > -
> > - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > struct msp_i2s_platform_data msp1_platform_data = {
> > @@ -83,29 +59,15 @@ struct msp_i2s_platform_data msp1_platform_data = {
> > static struct stedma40_chan_cfg msp2_dma_rx = {
> > .high_priority = true,
> > .dir = STEDMA40_PERIPH_TO_MEM,
> > -
> > .dev_type = DB8500_DMA_DEV14_MSP2,
> > -
> > - /* MSP2 DMA doesn't work with PSIZE == 4 on DB8500v2 */
> > - .src_info.psize = STEDMA40_PSIZE_LOG_1,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_1,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > static struct stedma40_chan_cfg msp2_dma_tx = {
> > .high_priority = true,
> > .dir = STEDMA40_MEM_TO_PERIPH,
> > -
> > .dev_type = DB8500_DMA_DEV14_MSP2,
> > -
> > - .src_info.psize = STEDMA40_PSIZE_LOG_4,
> > - .dst_info.psize = STEDMA40_PSIZE_LOG_4,
> > -
> > .use_fixed_channel = true,
> > .phy_channel = 1,
> > -
> > - /* data_width is set during configuration */
> > };
> >
> > static struct platform_device *db8500_add_msp_i2s(struct device *parent,
>
> Linus, poke.
I've just seen this response from you (it didn't make it to my offline
mail store for some reason):
> Linus Walleij wrote:
> So if I understand correctly this is now handled by dmaengine_pcm.c,
> os that right?
Unfortunately not. At the moment ux500 sound is very broken in
Mainline. I looked at it recently and the driver is almost completely
different to the one maintained internally.
There were DMA changes relating to this driver pending for v3.10,
which I believe have just been taking into -next. I will straighten
out the DMA issues shortly, but there are other ones remaining still -
mostly surrounding widgets. Ideally this is something Ola should fix,
as he has the expertise to do so, but he doesn't appear to have been
very active upstream of late.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
2013-05-02 8:38 ` Lee Jones
@ 2013-05-03 13:57 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-05-03 13:57 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, May 2, 2013 at 10:38 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > 'psize' is used to calculate the maximum DMA burst size. However it
>> > is only taken into consideration when editing the DMA channel's
>> > configuration. The Audio DMA platform data is only used to allocate
>> > a channel, not configure it. That will be done at a later date within
>> > the MSP driver.
>> >
>> > We're also removing comments which are no longer required, as
>> > 'data_width' is no longer set in any device's platform data period.
>> >
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>> Linus Walleij wrote:
>> So if I understand correctly this is now handled by dmaengine_pcm.c,
>> os that right?
>
> Unfortunately not. At the moment ux500 sound is very broken in
> Mainline. I looked at it recently and the driver is almost completely
> different to the one maintained internally.
I was more thinking that the dmaengine_pcm.c which appears
to have its functions called from the ux500 ASoC driver should
do the calls to slave config to set up proper DMA characteristics
for the channel.
Maybe that part is in the MSP driver as you say, is that so?
> There were DMA changes relating to this driver pending for v3.10,
> which I believe have just been taking into -next. I will straighten
> out the DMA issues shortly, but there are other ones remaining still -
> mostly surrounding widgets. Ideally this is something Ola should fix,
> as he has the expertise to do so, but he doesn't appear to have been
> very active upstream of late.
IIRC there are also patches from Fabio to this stuff so I'm
a bit confused, but if the intention is to merge this through
ASoC with some other stuff, by all means:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
@ 2013-05-03 13:57 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-05-03 13:57 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 2, 2013 at 10:38 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > 'psize' is used to calculate the maximum DMA burst size. However it
>> > is only taken into consideration when editing the DMA channel's
>> > configuration. The Audio DMA platform data is only used to allocate
>> > a channel, not configure it. That will be done at a later date within
>> > the MSP driver.
>> >
>> > We're also removing comments which are no longer required, as
>> > 'data_width' is no longer set in any device's platform data period.
>> >
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>> Linus Walleij wrote:
>> So if I understand correctly this is now handled by dmaengine_pcm.c,
>> os that right?
>
> Unfortunately not. At the moment ux500 sound is very broken in
> Mainline. I looked at it recently and the driver is almost completely
> different to the one maintained internally.
I was more thinking that the dmaengine_pcm.c which appears
to have its functions called from the ux500 ASoC driver should
do the calls to slave config to set up proper DMA characteristics
for the channel.
Maybe that part is in the MSP driver as you say, is that so?
> There were DMA changes relating to this driver pending for v3.10,
> which I believe have just been taking into -next. I will straighten
> out the DMA issues shortly, but there are other ones remaining still -
> mostly surrounding widgets. Ideally this is something Ola should fix,
> as he has the expertise to do so, but he doesn't appear to have been
> very active upstream of late.
IIRC there are also patches from Fabio to this stuff so I'm
a bit confused, but if the intention is to merge this through
ASoC with some other stuff, by all means:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
2013-05-03 13:57 ` Linus Walleij
@ 2013-06-10 9:04 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-06-10 9:04 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Fri, 03 May 2013, Linus Walleij wrote:
> On Thu, May 2, 2013 at 10:38 AM, Lee Jones <lee.jones@linaro.org> wrote:
>
> >> > 'psize' is used to calculate the maximum DMA burst size. However it
> >> > is only taken into consideration when editing the DMA channel's
> >> > configuration. The Audio DMA platform data is only used to allocate
> >> > a channel, not configure it. That will be done at a later date within
> >> > the MSP driver.
> >> >
> >> > We're also removing comments which are no longer required, as
> >> > 'data_width' is no longer set in any device's platform data period.
> >> >
> >> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> >> Linus Walleij wrote:
> >> So if I understand correctly this is now handled by dmaengine_pcm.c,
> >> os that right?
> >
> > Unfortunately not. At the moment ux500 sound is very broken in
> > Mainline. I looked at it recently and the driver is almost completely
> > different to the one maintained internally.
>
> I was more thinking that the dmaengine_pcm.c which appears
> to have its functions called from the ux500 ASoC driver should
> do the calls to slave config to set up proper DMA characteristics
> for the channel.
>
> Maybe that part is in the MSP driver as you say, is that so?
>
> > There were DMA changes relating to this driver pending for v3.10,
> > which I believe have just been taking into -next. I will straighten
> > out the DMA issues shortly, but there are other ones remaining still -
> > mostly surrounding widgets. Ideally this is something Ola should fix,
> > as he has the expertise to do so, but he doesn't appear to have been
> > very active upstream of late.
>
> IIRC there are also patches from Fabio to this stuff so I'm
> a bit confused, but if the intention is to merge this through
> ASoC with some other stuff, by all means:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Linus,
Would you mind taking this through your tree now that the DMA stuff
has gone in please?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
@ 2013-06-10 9:04 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-06-10 9:04 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 03 May 2013, Linus Walleij wrote:
> On Thu, May 2, 2013 at 10:38 AM, Lee Jones <lee.jones@linaro.org> wrote:
>
> >> > 'psize' is used to calculate the maximum DMA burst size. However it
> >> > is only taken into consideration when editing the DMA channel's
> >> > configuration. The Audio DMA platform data is only used to allocate
> >> > a channel, not configure it. That will be done at a later date within
> >> > the MSP driver.
> >> >
> >> > We're also removing comments which are no longer required, as
> >> > 'data_width' is no longer set in any device's platform data period.
> >> >
> >> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> >> Linus Walleij wrote:
> >> So if I understand correctly this is now handled by dmaengine_pcm.c,
> >> os that right?
> >
> > Unfortunately not. At the moment ux500 sound is very broken in
> > Mainline. I looked at it recently and the driver is almost completely
> > different to the one maintained internally.
>
> I was more thinking that the dmaengine_pcm.c which appears
> to have its functions called from the ux500 ASoC driver should
> do the calls to slave config to set up proper DMA characteristics
> for the channel.
>
> Maybe that part is in the MSP driver as you say, is that so?
>
> > There were DMA changes relating to this driver pending for v3.10,
> > which I believe have just been taking into -next. I will straighten
> > out the DMA issues shortly, but there are other ones remaining still -
> > mostly surrounding widgets. Ideally this is something Ola should fix,
> > as he has the expertise to do so, but he doesn't appear to have been
> > very active upstream of late.
>
> IIRC there are also patches from Fabio to this stuff so I'm
> a bit confused, but if the intention is to merge this through
> ASoC with some other stuff, by all means:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Linus,
Would you mind taking this through your tree now that the DMA stuff
has gone in please?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
2013-06-10 9:04 ` Lee Jones
@ 2013-06-10 9:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-06-10 9:12 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
> Linus,
>
> Would you mind taking this through your tree now that the DMA stuff
> has gone in please?
Again, just found this in -next. Sorry for the churn.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 12/32] ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
@ 2013-06-10 9:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-06-10 9:12 UTC (permalink / raw)
To: linux-arm-kernel
> Linus,
>
> Would you mind taking this through your tree now that the DMA stuff
> has gone in please?
Again, just found this in -next. Sorry for the churn.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
This change will cost ~25KB of memory, but it's worth the trade-off,
as it removes a great deal of overhead. It means that instead of only
allocating memory for the logical channels in use, it does so for all
available ones, which is 32 per physical channel. However, this now
means we can remove some platform data and we don't have to worry
about adding vendor specific variables to Device Tree.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/devices-db8500.c | 1 -
drivers/dma/ste_dma40.c | 16 ++++++----------
include/linux/platform_data/dma-ste-dma40.h | 2 --
3 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 03efd4c1..2fcb8c2 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -121,7 +121,6 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
};
static struct stedma40_platform_data dma40_plat_data = {
- .dev_len = DB8500_DMA_NR_DEV,
.dev_rx = dma40_rx_map,
.dev_tx = dma40_tx_map,
.disabled_channels = {-1},
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 7b451b2..a39ef74 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -45,6 +45,9 @@
#define D40_LCLA_LINK_PER_EVENT_GRP 128
#define D40_LCLA_END D40_LCLA_LINK_PER_EVENT_GRP
+/* Max number of logical channels per physical channel */
+#define D40_MAX_LOG_CHAN_PER_PHY 32
+
/* Attempts before giving up to trying to get pages that are aligned */
#define MAX_LCLA_ALLOC_ATTEMPTS 256
@@ -3197,6 +3200,8 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
else
num_phy_chans = 4 * (readl(virtbase + D40_DREG_ICFG) & 0x7) + 4;
+ num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
+
dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
rev, res->start, num_phy_chans);
@@ -3206,15 +3211,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
goto failure;
}
- /* Count the number of logical channels in use */
- for (i = 0; i < plat_data->dev_len; i++)
- if (plat_data->dev_rx[i] != 0)
- num_log_chans++;
-
- for (i = 0; i < plat_data->dev_len; i++)
- if (plat_data->dev_tx[i] != 0)
- num_log_chans++;
-
base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
(num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
sizeof(struct d40_chan), GFP_KERNEL);
@@ -3282,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
* The max number of logical channels are event lines for all
* src devices and dst devices
*/
- base->lookup_log_chans = kzalloc(plat_data->dev_len * 2 *
+ base->lookup_log_chans = kzalloc(num_log_chans *
sizeof(struct d40_chan *),
GFP_KERNEL);
if (!base->lookup_log_chans)
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 9e42a67..c54af61 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -136,7 +136,6 @@ struct stedma40_chan_cfg {
/**
* struct stedma40_platform_data - Configuration struct for the dma device.
*
- * @dev_len: length of dev_tx and dev_rx
* @dev_tx: mapping between destination event line and io address
* @dev_rx: mapping between source event line and io address
* @disabled_channels: A vector, ending with -1, that marks physical channels
@@ -153,7 +152,6 @@ struct stedma40_chan_cfg {
* for 'multiple of 4' channels, like 8.
*/
struct stedma40_platform_data {
- u32 dev_len;
const dma_addr_t *dev_tx;
const dma_addr_t *dev_rx;
int disabled_channels[STEDMA40_MAX_PHYS];
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
This change will cost ~25KB of memory, but it's worth the trade-off,
as it removes a great deal of overhead. It means that instead of only
allocating memory for the logical channels in use, it does so for all
available ones, which is 32 per physical channel. However, this now
means we can remove some platform data and we don't have to worry
about adding vendor specific variables to Device Tree.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/devices-db8500.c | 1 -
drivers/dma/ste_dma40.c | 16 ++++++----------
include/linux/platform_data/dma-ste-dma40.h | 2 --
3 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 03efd4c1..2fcb8c2 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -121,7 +121,6 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
};
static struct stedma40_platform_data dma40_plat_data = {
- .dev_len = DB8500_DMA_NR_DEV,
.dev_rx = dma40_rx_map,
.dev_tx = dma40_tx_map,
.disabled_channels = {-1},
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 7b451b2..a39ef74 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -45,6 +45,9 @@
#define D40_LCLA_LINK_PER_EVENT_GRP 128
#define D40_LCLA_END D40_LCLA_LINK_PER_EVENT_GRP
+/* Max number of logical channels per physical channel */
+#define D40_MAX_LOG_CHAN_PER_PHY 32
+
/* Attempts before giving up to trying to get pages that are aligned */
#define MAX_LCLA_ALLOC_ATTEMPTS 256
@@ -3197,6 +3200,8 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
else
num_phy_chans = 4 * (readl(virtbase + D40_DREG_ICFG) & 0x7) + 4;
+ num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
+
dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
rev, res->start, num_phy_chans);
@@ -3206,15 +3211,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
goto failure;
}
- /* Count the number of logical channels in use */
- for (i = 0; i < plat_data->dev_len; i++)
- if (plat_data->dev_rx[i] != 0)
- num_log_chans++;
-
- for (i = 0; i < plat_data->dev_len; i++)
- if (plat_data->dev_tx[i] != 0)
- num_log_chans++;
-
base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
(num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
sizeof(struct d40_chan), GFP_KERNEL);
@@ -3282,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
* The max number of logical channels are event lines for all
* src devices and dst devices
*/
- base->lookup_log_chans = kzalloc(plat_data->dev_len * 2 *
+ base->lookup_log_chans = kzalloc(num_log_chans *
sizeof(struct d40_chan *),
GFP_KERNEL);
if (!base->lookup_log_chans)
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index 9e42a67..c54af61 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -136,7 +136,6 @@ struct stedma40_chan_cfg {
/**
* struct stedma40_platform_data - Configuration struct for the dma device.
*
- * @dev_len: length of dev_tx and dev_rx
* @dev_tx: mapping between destination event line and io address
* @dev_rx: mapping between source event line and io address
* @disabled_channels: A vector, ending with -1, that marks physical channels
@@ -153,7 +152,6 @@ struct stedma40_chan_cfg {
* for 'multiple of 4' channels, like 8.
*/
struct stedma40_platform_data {
- u32 dev_len;
const dma_addr_t *dev_tx;
const dma_addr_t *dev_rx;
int disabled_channels[STEDMA40_MAX_PHYS];
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
2013-04-18 10:11 ` Lee Jones
@ 2013-04-22 9:23 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:23 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:11:55AM +0100, Lee Jones wrote:
> This change will cost ~25KB of memory, but it's worth the trade-off,
> as it removes a great deal of overhead. It means that instead of only
> allocating memory for the logical channels in use, it does so for all
> available ones, which is 32 per physical channel. However, this now
> means we can remove some platform data and we don't have to worry
> about adding vendor specific variables to Device Tree.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/mach-ux500/devices-db8500.c | 1 -
> drivers/dma/ste_dma40.c | 16 ++++++----------
> include/linux/platform_data/dma-ste-dma40.h | 2 --
> 3 files changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> index 03efd4c1..2fcb8c2 100644
> --- a/arch/arm/mach-ux500/devices-db8500.c
> +++ b/arch/arm/mach-ux500/devices-db8500.c
> @@ -121,7 +121,6 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
> };
>
> static struct stedma40_platform_data dma40_plat_data = {
> - .dev_len = DB8500_DMA_NR_DEV,
> .dev_rx = dma40_rx_map,
> .dev_tx = dma40_tx_map,
> .disabled_channels = {-1},
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 7b451b2..a39ef74 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -45,6 +45,9 @@
> #define D40_LCLA_LINK_PER_EVENT_GRP 128
> #define D40_LCLA_END D40_LCLA_LINK_PER_EVENT_GRP
>
> +/* Max number of logical channels per physical channel */
> +#define D40_MAX_LOG_CHAN_PER_PHY 32
> +
> /* Attempts before giving up to trying to get pages that are aligned */
> #define MAX_LCLA_ALLOC_ATTEMPTS 256
>
> @@ -3197,6 +3200,8 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> else
> num_phy_chans = 4 * (readl(virtbase + D40_DREG_ICFG) & 0x7) + 4;
>
> + num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> +
> dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> rev, res->start, num_phy_chans);
>
> @@ -3206,15 +3211,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> goto failure;
> }
>
> - /* Count the number of logical channels in use */
> - for (i = 0; i < plat_data->dev_len; i++)
> - if (plat_data->dev_rx[i] != 0)
> - num_log_chans++;
> -
> - for (i = 0; i < plat_data->dev_len; i++)
> - if (plat_data->dev_tx[i] != 0)
> - num_log_chans++;
> -
> base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
> (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
> sizeof(struct d40_chan), GFP_KERNEL);
> @@ -3282,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> * The max number of logical channels are event lines for all
> * src devices and dst devices
> */
> - base->lookup_log_chans = kzalloc(plat_data->dev_len * 2 *
> + base->lookup_log_chans = kzalloc(num_log_chans *
you could have used devm_ helper for this.
Still,
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> sizeof(struct d40_chan *),
> GFP_KERNEL);
> if (!base->lookup_log_chans)
> diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
> index 9e42a67..c54af61 100644
> --- a/include/linux/platform_data/dma-ste-dma40.h
> +++ b/include/linux/platform_data/dma-ste-dma40.h
> @@ -136,7 +136,6 @@ struct stedma40_chan_cfg {
> /**
> * struct stedma40_platform_data - Configuration struct for the dma device.
> *
> - * @dev_len: length of dev_tx and dev_rx
> * @dev_tx: mapping between destination event line and io address
> * @dev_rx: mapping between source event line and io address
> * @disabled_channels: A vector, ending with -1, that marks physical channels
> @@ -153,7 +152,6 @@ struct stedma40_chan_cfg {
> * for 'multiple of 4' channels, like 8.
> */
> struct stedma40_platform_data {
> - u32 dev_len;
> const dma_addr_t *dev_tx;
> const dma_addr_t *dev_rx;
> int disabled_channels[STEDMA40_MAX_PHYS];
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
@ 2013-04-22 9:23 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:23 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:11:55AM +0100, Lee Jones wrote:
> This change will cost ~25KB of memory, but it's worth the trade-off,
> as it removes a great deal of overhead. It means that instead of only
> allocating memory for the logical channels in use, it does so for all
> available ones, which is 32 per physical channel. However, this now
> means we can remove some platform data and we don't have to worry
> about adding vendor specific variables to Device Tree.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/mach-ux500/devices-db8500.c | 1 -
> drivers/dma/ste_dma40.c | 16 ++++++----------
> include/linux/platform_data/dma-ste-dma40.h | 2 --
> 3 files changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> index 03efd4c1..2fcb8c2 100644
> --- a/arch/arm/mach-ux500/devices-db8500.c
> +++ b/arch/arm/mach-ux500/devices-db8500.c
> @@ -121,7 +121,6 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
> };
>
> static struct stedma40_platform_data dma40_plat_data = {
> - .dev_len = DB8500_DMA_NR_DEV,
> .dev_rx = dma40_rx_map,
> .dev_tx = dma40_tx_map,
> .disabled_channels = {-1},
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 7b451b2..a39ef74 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -45,6 +45,9 @@
> #define D40_LCLA_LINK_PER_EVENT_GRP 128
> #define D40_LCLA_END D40_LCLA_LINK_PER_EVENT_GRP
>
> +/* Max number of logical channels per physical channel */
> +#define D40_MAX_LOG_CHAN_PER_PHY 32
> +
> /* Attempts before giving up to trying to get pages that are aligned */
> #define MAX_LCLA_ALLOC_ATTEMPTS 256
>
> @@ -3197,6 +3200,8 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> else
> num_phy_chans = 4 * (readl(virtbase + D40_DREG_ICFG) & 0x7) + 4;
>
> + num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> +
> dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> rev, res->start, num_phy_chans);
>
> @@ -3206,15 +3211,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> goto failure;
> }
>
> - /* Count the number of logical channels in use */
> - for (i = 0; i < plat_data->dev_len; i++)
> - if (plat_data->dev_rx[i] != 0)
> - num_log_chans++;
> -
> - for (i = 0; i < plat_data->dev_len; i++)
> - if (plat_data->dev_tx[i] != 0)
> - num_log_chans++;
> -
> base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
> (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
> sizeof(struct d40_chan), GFP_KERNEL);
> @@ -3282,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> * The max number of logical channels are event lines for all
> * src devices and dst devices
> */
> - base->lookup_log_chans = kzalloc(plat_data->dev_len * 2 *
> + base->lookup_log_chans = kzalloc(num_log_chans *
you could have used devm_ helper for this.
Still,
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> sizeof(struct d40_chan *),
> GFP_KERNEL);
> if (!base->lookup_log_chans)
> diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
> index 9e42a67..c54af61 100644
> --- a/include/linux/platform_data/dma-ste-dma40.h
> +++ b/include/linux/platform_data/dma-ste-dma40.h
> @@ -136,7 +136,6 @@ struct stedma40_chan_cfg {
> /**
> * struct stedma40_platform_data - Configuration struct for the dma device.
> *
> - * @dev_len: length of dev_tx and dev_rx
> * @dev_tx: mapping between destination event line and io address
> * @dev_rx: mapping between source event line and io address
> * @disabled_channels: A vector, ending with -1, that marks physical channels
> @@ -153,7 +152,6 @@ struct stedma40_chan_cfg {
> * for 'multiple of 4' channels, like 8.
> */
> struct stedma40_platform_data {
> - u32 dev_len;
> const dma_addr_t *dev_tx;
> const dma_addr_t *dev_rx;
> int disabled_channels[STEDMA40_MAX_PHYS];
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
2013-04-22 9:23 ` Vinod Koul
@ 2013-04-22 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:11 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Mon, 22 Apr 2013, Vinod Koul wrote:
> On Thu, Apr 18, 2013 at 11:11:55AM +0100, Lee Jones wrote:
> > This change will cost ~25KB of memory, but it's worth the trade-off,
> > as it removes a great deal of overhead. It means that instead of only
> > allocating memory for the logical channels in use, it does so for all
> > available ones, which is 32 per physical channel. However, this now
> > means we can remove some platform data and we don't have to worry
> > about adding vendor specific variables to Device Tree.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > arch/arm/mach-ux500/devices-db8500.c | 1 -
> > drivers/dma/ste_dma40.c | 16 ++++++----------
> > include/linux/platform_data/dma-ste-dma40.h | 2 --
> > 3 files changed, 6 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> > index 03efd4c1..2fcb8c2 100644
> > --- a/arch/arm/mach-ux500/devices-db8500.c
> > +++ b/arch/arm/mach-ux500/devices-db8500.c
> > @@ -121,7 +121,6 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
> > };
> >
> > static struct stedma40_platform_data dma40_plat_data = {
> > - .dev_len = DB8500_DMA_NR_DEV,
> > .dev_rx = dma40_rx_map,
> > .dev_tx = dma40_tx_map,
> > .disabled_channels = {-1},
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index 7b451b2..a39ef74 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -45,6 +45,9 @@
> > #define D40_LCLA_LINK_PER_EVENT_GRP 128
> > #define D40_LCLA_END D40_LCLA_LINK_PER_EVENT_GRP
> >
> > +/* Max number of logical channels per physical channel */
> > +#define D40_MAX_LOG_CHAN_PER_PHY 32
> > +
> > /* Attempts before giving up to trying to get pages that are aligned */
> > #define MAX_LCLA_ALLOC_ATTEMPTS 256
> >
> > @@ -3197,6 +3200,8 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > else
> > num_phy_chans = 4 * (readl(virtbase + D40_DREG_ICFG) & 0x7) + 4;
> >
> > + num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> > +
> > dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> > rev, res->start, num_phy_chans);
> >
> > @@ -3206,15 +3211,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > goto failure;
> > }
> >
> > - /* Count the number of logical channels in use */
> > - for (i = 0; i < plat_data->dev_len; i++)
> > - if (plat_data->dev_rx[i] != 0)
> > - num_log_chans++;
> > -
> > - for (i = 0; i < plat_data->dev_len; i++)
> > - if (plat_data->dev_tx[i] != 0)
> > - num_log_chans++;
> > -
> > base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
> > (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
> > sizeof(struct d40_chan), GFP_KERNEL);
> > @@ -3282,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > * The max number of logical channels are event lines for all
> > * src devices and dst devices
> > */
> > - base->lookup_log_chans = kzalloc(plat_data->dev_len * 2 *
> > + base->lookup_log_chans = kzalloc(num_log_chans *
> you could have used devm_ helper for this.
I'll convert the entire driver over to devm_ in a latter patch.
> Acked-by: Vinod Koul <vnod.koul@intel.com>
Thanks.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
@ 2013-04-22 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:11 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 22 Apr 2013, Vinod Koul wrote:
> On Thu, Apr 18, 2013 at 11:11:55AM +0100, Lee Jones wrote:
> > This change will cost ~25KB of memory, but it's worth the trade-off,
> > as it removes a great deal of overhead. It means that instead of only
> > allocating memory for the logical channels in use, it does so for all
> > available ones, which is 32 per physical channel. However, this now
> > means we can remove some platform data and we don't have to worry
> > about adding vendor specific variables to Device Tree.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > arch/arm/mach-ux500/devices-db8500.c | 1 -
> > drivers/dma/ste_dma40.c | 16 ++++++----------
> > include/linux/platform_data/dma-ste-dma40.h | 2 --
> > 3 files changed, 6 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
> > index 03efd4c1..2fcb8c2 100644
> > --- a/arch/arm/mach-ux500/devices-db8500.c
> > +++ b/arch/arm/mach-ux500/devices-db8500.c
> > @@ -121,7 +121,6 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
> > };
> >
> > static struct stedma40_platform_data dma40_plat_data = {
> > - .dev_len = DB8500_DMA_NR_DEV,
> > .dev_rx = dma40_rx_map,
> > .dev_tx = dma40_tx_map,
> > .disabled_channels = {-1},
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index 7b451b2..a39ef74 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -45,6 +45,9 @@
> > #define D40_LCLA_LINK_PER_EVENT_GRP 128
> > #define D40_LCLA_END D40_LCLA_LINK_PER_EVENT_GRP
> >
> > +/* Max number of logical channels per physical channel */
> > +#define D40_MAX_LOG_CHAN_PER_PHY 32
> > +
> > /* Attempts before giving up to trying to get pages that are aligned */
> > #define MAX_LCLA_ALLOC_ATTEMPTS 256
> >
> > @@ -3197,6 +3200,8 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > else
> > num_phy_chans = 4 * (readl(virtbase + D40_DREG_ICFG) & 0x7) + 4;
> >
> > + num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> > +
> > dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> > rev, res->start, num_phy_chans);
> >
> > @@ -3206,15 +3211,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > goto failure;
> > }
> >
> > - /* Count the number of logical channels in use */
> > - for (i = 0; i < plat_data->dev_len; i++)
> > - if (plat_data->dev_rx[i] != 0)
> > - num_log_chans++;
> > -
> > - for (i = 0; i < plat_data->dev_len; i++)
> > - if (plat_data->dev_tx[i] != 0)
> > - num_log_chans++;
> > -
> > base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
> > (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
> > sizeof(struct d40_chan), GFP_KERNEL);
> > @@ -3282,7 +3278,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > * The max number of logical channels are event lines for all
> > * src devices and dst devices
> > */
> > - base->lookup_log_chans = kzalloc(plat_data->dev_len * 2 *
> > + base->lookup_log_chans = kzalloc(num_log_chans *
> you could have used devm_ helper for this.
I'll convert the entire driver over to devm_ in a latter patch.
> Acked-by: Vinod Koul <vnod.koul@intel.com>
Thanks.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 9:13 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 9:13 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> This change will cost ~25KB of memory, but it's worth the trade-off,
> as it removes a great deal of overhead. It means that instead of only
> allocating memory for the logical channels in use, it does so for all
> available ones, which is 32 per physical channel. However, this now
> means we can remove some platform data and we don't have to worry
> about adding vendor specific variables to Device Tree.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(...)
> static struct stedma40_platform_data dma40_plat_data = {
> - .dev_len = DB8500_DMA_NR_DEV,
So that was set to 64 in the platform...
> - /* Count the number of logical channels in use */
> - for (i = 0; i < plat_data->dev_len; i++)
> - if (plat_data->dev_rx[i] != 0)
> - num_log_chans++;
> -
> - for (i = 0; i < plat_data->dev_len; i++)
> - if (plat_data->dev_tx[i] != 0)
> - num_log_chans++;
And I guess this code snippet made it go down to <= 32 all the time,
correct?
Just want to understand it before I ACK. (The idea is sound.)
I notice there is no check whatsoever of the bounds of
plat_data->dev_[rx|tx] but that is a different problem I guess...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
@ 2013-04-25 9:13 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 9:13 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> This change will cost ~25KB of memory, but it's worth the trade-off,
> as it removes a great deal of overhead. It means that instead of only
> allocating memory for the logical channels in use, it does so for all
> available ones, which is 32 per physical channel. However, this now
> means we can remove some platform data and we don't have to worry
> about adding vendor specific variables to Device Tree.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(...)
> static struct stedma40_platform_data dma40_plat_data = {
> - .dev_len = DB8500_DMA_NR_DEV,
So that was set to 64 in the platform...
> - /* Count the number of logical channels in use */
> - for (i = 0; i < plat_data->dev_len; i++)
> - if (plat_data->dev_rx[i] != 0)
> - num_log_chans++;
> -
> - for (i = 0; i < plat_data->dev_len; i++)
> - if (plat_data->dev_tx[i] != 0)
> - num_log_chans++;
And I guess this code snippet made it go down to <= 32 all the time,
correct?
Just want to understand it before I ACK. (The idea is sound.)
I notice there is no check whatsoever of the bounds of
plat_data->dev_[rx|tx] but that is a different problem I guess...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
2013-04-25 9:13 ` Linus Walleij
@ 2013-04-25 9:29 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:29 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > This change will cost ~25KB of memory, but it's worth the trade-off,
> > as it removes a great deal of overhead. It means that instead of only
> > allocating memory for the logical channels in use, it does so for all
> > available ones, which is 32 per physical channel. However, this now
> > means we can remove some platform data and we don't have to worry
> > about adding vendor specific variables to Device Tree.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> (...)
> > static struct stedma40_platform_data dma40_plat_data = {
> > - .dev_len = DB8500_DMA_NR_DEV,
>
> So that was set to 64 in the platform...
>
> > - /* Count the number of logical channels in use */
> > - for (i = 0; i < plat_data->dev_len; i++)
> > - if (plat_data->dev_rx[i] != 0)
> > - num_log_chans++;
> > -
> > - for (i = 0; i < plat_data->dev_len; i++)
> > - if (plat_data->dev_tx[i] != 0)
> > - num_log_chans++;
>
> And I guess this code snippet made it go down to <= 32 all the time,
> correct?
However many were described in dma40_[rx|tx]_map, yes.
> Just want to understand it before I ACK. (The idea is sound.)
>
> I notice there is no check whatsoever of the bounds of
> plat_data->dev_[rx|tx] but that is a different problem I guess...
The array is going away anyway, so we don't need to threat.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
@ 2013-04-25 9:29 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:29 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > This change will cost ~25KB of memory, but it's worth the trade-off,
> > as it removes a great deal of overhead. It means that instead of only
> > allocating memory for the logical channels in use, it does so for all
> > available ones, which is 32 per physical channel. However, this now
> > means we can remove some platform data and we don't have to worry
> > about adding vendor specific variables to Device Tree.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> (...)
> > static struct stedma40_platform_data dma40_plat_data = {
> > - .dev_len = DB8500_DMA_NR_DEV,
>
> So that was set to 64 in the platform...
>
> > - /* Count the number of logical channels in use */
> > - for (i = 0; i < plat_data->dev_len; i++)
> > - if (plat_data->dev_rx[i] != 0)
> > - num_log_chans++;
> > -
> > - for (i = 0; i < plat_data->dev_len; i++)
> > - if (plat_data->dev_tx[i] != 0)
> > - num_log_chans++;
>
> And I guess this code snippet made it go down to <= 32 all the time,
> correct?
However many were described in dma40_[rx|tx]_map, yes.
> Just want to understand it before I ACK. (The idea is sound.)
>
> I notice there is no check whatsoever of the bounds of
> plat_data->dev_[rx|tx] but that is a different problem I guess...
The array is going away anyway, so we don't need to threat.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
2013-04-25 9:29 ` Lee Jones
@ 2013-04-25 12:51 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:51 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 25, 2013 at 11:29 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> > This change will cost ~25KB of memory, but it's worth the trade-off,
>> > as it removes a great deal of overhead. It means that instead of only
>> > allocating memory for the logical channels in use, it does so for all
>> > available ones, which is 32 per physical channel. However, this now
>> > means we can remove some platform data and we don't have to worry
>> > about adding vendor specific variables to Device Tree.
>> >
>> > Cc: Vinod Koul <vinod.koul@intel.com>
>> > Cc: Dan Williams <djbw@fb.com>
>> > Cc: Per Forlin <per.forlin@stericsson.com>
>> > Cc: Rabin Vincent <rabin@rab.in>
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>>
>> (...)
>> > static struct stedma40_platform_data dma40_plat_data = {
>> > - .dev_len = DB8500_DMA_NR_DEV,
>>
>> So that was set to 64 in the platform...
>>
>> > - /* Count the number of logical channels in use */
>> > - for (i = 0; i < plat_data->dev_len; i++)
>> > - if (plat_data->dev_rx[i] != 0)
>> > - num_log_chans++;
>> > -
>> > - for (i = 0; i < plat_data->dev_len; i++)
>> > - if (plat_data->dev_tx[i] != 0)
>> > - num_log_chans++;
>>
>> And I guess this code snippet made it go down to <= 32 all the time,
>> correct?
>
> However many were described in dma40_[rx|tx]_map, yes.
OK how fragile, but definately not your fault.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones
@ 2013-04-25 12:51 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:51 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 25, 2013 at 11:29 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> > This change will cost ~25KB of memory, but it's worth the trade-off,
>> > as it removes a great deal of overhead. It means that instead of only
>> > allocating memory for the logical channels in use, it does so for all
>> > available ones, which is 32 per physical channel. However, this now
>> > means we can remove some platform data and we don't have to worry
>> > about adding vendor specific variables to Device Tree.
>> >
>> > Cc: Vinod Koul <vinod.koul@intel.com>
>> > Cc: Dan Williams <djbw@fb.com>
>> > Cc: Per Forlin <per.forlin@stericsson.com>
>> > Cc: Rabin Vincent <rabin@rab.in>
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>>
>> (...)
>> > static struct stedma40_platform_data dma40_plat_data = {
>> > - .dev_len = DB8500_DMA_NR_DEV,
>>
>> So that was set to 64 in the platform...
>>
>> > - /* Count the number of logical channels in use */
>> > - for (i = 0; i < plat_data->dev_len; i++)
>> > - if (plat_data->dev_rx[i] != 0)
>> > - num_log_chans++;
>> > -
>> > - for (i = 0; i < plat_data->dev_len; i++)
>> > - if (plat_data->dev_tx[i] != 0)
>> > - num_log_chans++;
>>
>> And I guess this code snippet made it go down to <= 32 all the time,
>> correct?
>
> However many were described in dma40_[rx|tx]_map, yes.
OK how fragile, but definately not your fault.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
Before allocating memory for logical channels, the current driver
checks to see if there are any. Well as the dma40_memcpy_channels[]
array is always populated, the check is always true. Best to
remove the check.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index a39ef74..ec0d6ab 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3273,17 +3273,11 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
if (!base->lookup_phy_chans)
goto failure;
- if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
- /*
- * The max number of logical channels are event lines for all
- * src devices and dst devices
- */
- base->lookup_log_chans = kzalloc(num_log_chans *
- sizeof(struct d40_chan *),
- GFP_KERNEL);
- if (!base->lookup_log_chans)
- goto failure;
- }
+ base->lookup_log_chans = kzalloc(num_log_chans *
+ sizeof(struct d40_chan *),
+ GFP_KERNEL);
+ if (!base->lookup_log_chans)
+ goto failure;
base->reg_val_backup_chan = kmalloc(base->num_phy_chans *
sizeof(d40_backup_regs_chan),
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
Before allocating memory for logical channels, the current driver
checks to see if there are any. Well as the dma40_memcpy_channels[]
array is always populated, the check is always true. Best to
remove the check.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index a39ef74..ec0d6ab 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3273,17 +3273,11 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
if (!base->lookup_phy_chans)
goto failure;
- if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
- /*
- * The max number of logical channels are event lines for all
- * src devices and dst devices
- */
- base->lookup_log_chans = kzalloc(num_log_chans *
- sizeof(struct d40_chan *),
- GFP_KERNEL);
- if (!base->lookup_log_chans)
- goto failure;
- }
+ base->lookup_log_chans = kzalloc(num_log_chans *
+ sizeof(struct d40_chan *),
+ GFP_KERNEL);
+ if (!base->lookup_log_chans)
+ goto failure;
base->reg_val_backup_chan = kmalloc(base->num_phy_chans *
sizeof(d40_backup_regs_chan),
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:53 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:53 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> Before allocating memory for logical channels, the current driver
> checks to see if there are any. Well as the dma40_memcpy_channels[]
> array is always populated, the check is always true. Best to
> remove the check.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
@ 2013-04-18 10:53 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:53 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> Before allocating memory for logical channels, the current driver
> checks to see if there are any. Well as the dma40_memcpy_channels[]
> array is always populated, the check is always true. Best to
> remove the check.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
2013-04-18 10:11 ` Lee Jones
@ 2013-04-22 9:44 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:44 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:11:56AM +0100, Lee Jones wrote:
> Before allocating memory for logical channels, the current driver
> checks to see if there are any. Well as the dma40_memcpy_channels[]
> array is always populated, the check is always true. Best to
> remove the check.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
The init should be updated to use devm_ versions..
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 16 +++++-----------
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index a39ef74..ec0d6ab 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3273,17 +3273,11 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> if (!base->lookup_phy_chans)
> goto failure;
>
> - if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
> - /*
> - * The max number of logical channels are event lines for all
> - * src devices and dst devices
> - */
> - base->lookup_log_chans = kzalloc(num_log_chans *
> - sizeof(struct d40_chan *),
> - GFP_KERNEL);
> - if (!base->lookup_log_chans)
> - goto failure;
> - }
> + base->lookup_log_chans = kzalloc(num_log_chans *
> + sizeof(struct d40_chan *),
> + GFP_KERNEL);
> + if (!base->lookup_log_chans)
> + goto failure;
>
> base->reg_val_backup_chan = kmalloc(base->num_phy_chans *
> sizeof(d40_backup_regs_chan),
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
@ 2013-04-22 9:44 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:44 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:11:56AM +0100, Lee Jones wrote:
> Before allocating memory for logical channels, the current driver
> checks to see if there are any. Well as the dma40_memcpy_channels[]
> array is always populated, the check is always true. Best to
> remove the check.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
The init should be updated to use devm_ versions..
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 16 +++++-----------
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index a39ef74..ec0d6ab 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3273,17 +3273,11 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> if (!base->lookup_phy_chans)
> goto failure;
>
> - if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
> - /*
> - * The max number of logical channels are event lines for all
> - * src devices and dst devices
> - */
> - base->lookup_log_chans = kzalloc(num_log_chans *
> - sizeof(struct d40_chan *),
> - GFP_KERNEL);
> - if (!base->lookup_log_chans)
> - goto failure;
> - }
> + base->lookup_log_chans = kzalloc(num_log_chans *
> + sizeof(struct d40_chan *),
> + GFP_KERNEL);
> + if (!base->lookup_log_chans)
> + goto failure;
>
> base->reg_val_backup_chan = kmalloc(base->num_phy_chans *
> sizeof(d40_backup_regs_chan),
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 9:17 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 9:17 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Before allocating memory for logical channels, the current driver
> checks to see if there are any. Well as the dma40_memcpy_channels[]
> array is always populated, the check is always true. Best to
> remove the check.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(...)
> - if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
So I guess this was changed when moving the memcpy channels
into the driver.
> - /*
> - * The max number of logical channels are event lines for all
> - * src devices and dst devices
> - */
> - base->lookup_log_chans = kzalloc(num_log_chans *
> - sizeof(struct d40_chan *),
> - GFP_KERNEL);
And at that point you forgot to rewrite this as
kzalloc((num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)), ...)?
> - if (!base->lookup_log_chans)
> - goto failure;
> - }
> + base->lookup_log_chans = kzalloc(num_log_chans *
> + sizeof(struct d40_chan *),
> + GFP_KERNEL);
> + if (!base->lookup_log_chans)
> + goto failure;
So this change should also include the memcpy channels.
I'll go back and comment again on the patch moving the
memcpy channels into the driver.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
@ 2013-04-25 9:17 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 9:17 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Before allocating memory for logical channels, the current driver
> checks to see if there are any. Well as the dma40_memcpy_channels[]
> array is always populated, the check is always true. Best to
> remove the check.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(...)
> - if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
So I guess this was changed when moving the memcpy channels
into the driver.
> - /*
> - * The max number of logical channels are event lines for all
> - * src devices and dst devices
> - */
> - base->lookup_log_chans = kzalloc(num_log_chans *
> - sizeof(struct d40_chan *),
> - GFP_KERNEL);
And at that point you forgot to rewrite this as
kzalloc((num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)), ...)?
> - if (!base->lookup_log_chans)
> - goto failure;
> - }
> + base->lookup_log_chans = kzalloc(num_log_chans *
> + sizeof(struct d40_chan *),
> + GFP_KERNEL);
> + if (!base->lookup_log_chans)
> + goto failure;
So this change should also include the memcpy channels.
I'll go back and comment again on the patch moving the
memcpy channels into the driver.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
2013-04-25 9:17 ` Linus Walleij
@ 2013-04-25 9:24 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:24 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > Before allocating memory for logical channels, the current driver
> > checks to see if there are any. Well as the dma40_memcpy_channels[]
> > array is always populated, the check is always true. Best to
> > remove the check.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> (...)
>
> > - if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
>
> So I guess this was changed when moving the memcpy channels
> into the driver.
Right.
> > - /*
> > - * The max number of logical channels are event lines for all
> > - * src devices and dst devices
> > - */
> > - base->lookup_log_chans = kzalloc(num_log_chans *
> > - sizeof(struct d40_chan *),
> > - GFP_KERNEL);
>
> And at that point you forgot to rewrite this as
> kzalloc((num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)), ...)?
I guess I didn't notice that, yes.
> > - if (!base->lookup_log_chans)
> > - goto failure;
> > - }
> > + base->lookup_log_chans = kzalloc(num_log_chans *
> > + sizeof(struct d40_chan *),
> > + GFP_KERNEL);
> > + if (!base->lookup_log_chans)
> > + goto failure;
>
> So this change should also include the memcpy channels.
>
> I'll go back and comment again on the patch moving the
> memcpy channels into the driver.
Okay, NP.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 14/32] dmaengine: ste_dma40: Remove 'always true' checking
@ 2013-04-25 9:24 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 9:24 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > Before allocating memory for logical channels, the current driver
> > checks to see if there are any. Well as the dma40_memcpy_channels[]
> > array is always populated, the check is always true. Best to
> > remove the check.
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> (...)
>
> > - if (num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) {
>
> So I guess this was changed when moving the memcpy channels
> into the driver.
Right.
> > - /*
> > - * The max number of logical channels are event lines for all
> > - * src devices and dst devices
> > - */
> > - base->lookup_log_chans = kzalloc(num_log_chans *
> > - sizeof(struct d40_chan *),
> > - GFP_KERNEL);
>
> And at that point you forgot to rewrite this as
> kzalloc((num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)), ...)?
I guess I didn't notice that, yes.
> > - if (!base->lookup_log_chans)
> > - goto failure;
> > - }
> > + base->lookup_log_chans = kzalloc(num_log_chans *
> > + sizeof(struct d40_chan *),
> > + GFP_KERNEL);
> > + if (!base->lookup_log_chans)
> > + goto failure;
>
> So this change should also include the memcpy channels.
>
> I'll go back and comment again on the patch moving the
> memcpy channels into the driver.
Okay, NP.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
During the initial setup of a logical channel, it is necessary to unmask
the GIM in order to receive generated terminal count and error interrupts.
We're separating out this required code so it will be possible to move
the remaining code in d40_phy_cfg(), which is mostly runtime configuration
into the runtime_config() routine.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 3 +++
drivers/dma/ste_dma40_ll.c | 11 ++++++-----
drivers/dma/ste_dma40_ll.h | 2 ++
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index ec0d6ab..178a03c 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2456,6 +2456,9 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
}
+ if (chan_is_logical(d40c))
+ d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
+
dev_dbg(chan2dev(d40c), "allocated %s channel (phy %d%s)\n",
chan_is_logical(d40c) ? "logical" : "physical",
d40c->phy_chan->num,
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index 5eb6c10..b72d3e2 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -50,6 +50,12 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
}
+void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
+
+ *src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
+ *dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
+}
+
/* Sets up SRC and DST CFG register for both logical and physical channels */
void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
u32 *src_cfg, u32 *dst_cfg, bool is_log)
@@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
src |= 1 << D40_SREG_CFG_PRI_POS;
dst |= 1 << D40_SREG_CFG_PRI_POS;
}
-
- } else {
- /* Logical channel */
- dst |= 1 << D40_SREG_CFG_LOG_GIM_POS;
- src |= 1 << D40_SREG_CFG_LOG_GIM_POS;
}
if (cfg->src_info.big_endian)
diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
index fdde8ef..8aad679 100644
--- a/drivers/dma/ste_dma40_ll.h
+++ b/drivers/dma/ste_dma40_ll.h
@@ -430,6 +430,8 @@ enum d40_lli_flags {
LLI_LAST_LINK = 1 << 3,
};
+void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
+
void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
u32 *src_cfg,
u32 *dst_cfg,
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
During the initial setup of a logical channel, it is necessary to unmask
the GIM in order to receive generated terminal count and error interrupts.
We're separating out this required code so it will be possible to move
the remaining code in d40_phy_cfg(), which is mostly runtime configuration
into the runtime_config() routine.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 3 +++
drivers/dma/ste_dma40_ll.c | 11 ++++++-----
drivers/dma/ste_dma40_ll.h | 2 ++
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index ec0d6ab..178a03c 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2456,6 +2456,9 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
}
+ if (chan_is_logical(d40c))
+ d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
+
dev_dbg(chan2dev(d40c), "allocated %s channel (phy %d%s)\n",
chan_is_logical(d40c) ? "logical" : "physical",
d40c->phy_chan->num,
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index 5eb6c10..b72d3e2 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -50,6 +50,12 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
}
+void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
+
+ *src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
+ *dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
+}
+
/* Sets up SRC and DST CFG register for both logical and physical channels */
void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
u32 *src_cfg, u32 *dst_cfg, bool is_log)
@@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
src |= 1 << D40_SREG_CFG_PRI_POS;
dst |= 1 << D40_SREG_CFG_PRI_POS;
}
-
- } else {
- /* Logical channel */
- dst |= 1 << D40_SREG_CFG_LOG_GIM_POS;
- src |= 1 << D40_SREG_CFG_LOG_GIM_POS;
}
if (cfg->src_info.big_endian)
diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
index fdde8ef..8aad679 100644
--- a/drivers/dma/ste_dma40_ll.h
+++ b/drivers/dma/ste_dma40_ll.h
@@ -430,6 +430,8 @@ enum d40_lli_flags {
LLI_LAST_LINK = 1 << 3,
};
+void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
+
void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
u32 *src_cfg,
u32 *dst_cfg,
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:45 ` Russell King - ARM Linux
-1 siblings, 0 replies; 337+ messages in thread
From: Russell King - ARM Linux @ 2013-04-18 10:45 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Rabin Vincent, linus.walleij,
arnd, Vinod Koul, Per Forlin, Dan Williams
On Thu, Apr 18, 2013 at 11:11:57AM +0100, Lee Jones wrote:
> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
> +
> + *src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> + *dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
So, in patch 3, you started using the BIT() macro. But here it's fine
not to because... ?
Use one notation or the other, don't mix them together.
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
@ 2013-04-18 10:45 ` Russell King - ARM Linux
0 siblings, 0 replies; 337+ messages in thread
From: Russell King - ARM Linux @ 2013-04-18 10:45 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:11:57AM +0100, Lee Jones wrote:
> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
> +
> + *src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> + *dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
So, in patch 3, you started using the BIT() macro. But here it's fine
not to because... ?
Use one notation or the other, don't mix them together.
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:54 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:54 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> During the initial setup of a logical channel, it is necessary to unmask
> the GIM in order to receive generated terminal count and error interrupts.
> We're separating out this required code so it will be possible to move
> the remaining code in d40_phy_cfg(), which is mostly runtime configuration
> into the runtime_config() routine.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
@ 2013-04-18 10:54 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:54 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> During the initial setup of a logical channel, it is necessary to unmask
> the GIM in order to receive generated terminal count and error interrupts.
> We're separating out this required code so it will be possible to move
> the remaining code in d40_phy_cfg(), which is mostly runtime configuration
> into the runtime_config() routine.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
2013-04-18 10:11 ` Lee Jones
@ 2013-04-22 9:51 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:51 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:11:57AM +0100, Lee Jones wrote:
> During the initial setup of a logical channel, it is necessary to unmask
> the GIM in order to receive generated terminal count and error interrupts.
> We're separating out this required code so it will be possible to move
> the remaining code in d40_phy_cfg(), which is mostly runtime configuration
> into the runtime_config() routine.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/dma/ste_dma40.c | 3 +++
> drivers/dma/ste_dma40_ll.c | 11 ++++++-----
> drivers/dma/ste_dma40_ll.h | 2 ++
> 3 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index ec0d6ab..178a03c 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2456,6 +2456,9 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
> D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
> }
>
> + if (chan_is_logical(d40c))
> + d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
> +
> dev_dbg(chan2dev(d40c), "allocated %s channel (phy %d%s)\n",
> chan_is_logical(d40c) ? "logical" : "physical",
> d40c->phy_chan->num,
> diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
> index 5eb6c10..b72d3e2 100644
> --- a/drivers/dma/ste_dma40_ll.c
> +++ b/drivers/dma/ste_dma40_ll.c
> @@ -50,6 +50,12 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
>
> }
>
> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
> +
> + *src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> + *dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> +}
> +
> /* Sets up SRC and DST CFG register for both logical and physical channels */
> void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> u32 *src_cfg, u32 *dst_cfg, bool is_log)
> @@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> src |= 1 << D40_SREG_CFG_PRI_POS;
> dst |= 1 << D40_SREG_CFG_PRI_POS;
shouldnt these be converted to BIT() macro and in gim_unmask above?
Driver needs to be consistent in doing things
> }
> -
> - } else {
> - /* Logical channel */
> - dst |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> - src |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> }
>
> if (cfg->src_info.big_endian)
> diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
> index fdde8ef..8aad679 100644
> --- a/drivers/dma/ste_dma40_ll.h
> +++ b/drivers/dma/ste_dma40_ll.h
> @@ -430,6 +430,8 @@ enum d40_lli_flags {
> LLI_LAST_LINK = 1 << 3,
> };
>
> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
> +
> void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> u32 *src_cfg,
> u32 *dst_cfg,
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
@ 2013-04-22 9:51 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:51 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:11:57AM +0100, Lee Jones wrote:
> During the initial setup of a logical channel, it is necessary to unmask
> the GIM in order to receive generated terminal count and error interrupts.
> We're separating out this required code so it will be possible to move
> the remaining code in d40_phy_cfg(), which is mostly runtime configuration
> into the runtime_config() routine.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/dma/ste_dma40.c | 3 +++
> drivers/dma/ste_dma40_ll.c | 11 ++++++-----
> drivers/dma/ste_dma40_ll.h | 2 ++
> 3 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index ec0d6ab..178a03c 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2456,6 +2456,9 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
> D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
> }
>
> + if (chan_is_logical(d40c))
> + d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
> +
> dev_dbg(chan2dev(d40c), "allocated %s channel (phy %d%s)\n",
> chan_is_logical(d40c) ? "logical" : "physical",
> d40c->phy_chan->num,
> diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
> index 5eb6c10..b72d3e2 100644
> --- a/drivers/dma/ste_dma40_ll.c
> +++ b/drivers/dma/ste_dma40_ll.c
> @@ -50,6 +50,12 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
>
> }
>
> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
> +
> + *src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> + *dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> +}
> +
> /* Sets up SRC and DST CFG register for both logical and physical channels */
> void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> u32 *src_cfg, u32 *dst_cfg, bool is_log)
> @@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> src |= 1 << D40_SREG_CFG_PRI_POS;
> dst |= 1 << D40_SREG_CFG_PRI_POS;
shouldnt these be converted to BIT() macro and in gim_unmask above?
Driver needs to be consistent in doing things
> }
> -
> - } else {
> - /* Logical channel */
> - dst |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> - src |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> }
>
> if (cfg->src_info.big_endian)
> diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
> index fdde8ef..8aad679 100644
> --- a/drivers/dma/ste_dma40_ll.h
> +++ b/drivers/dma/ste_dma40_ll.h
> @@ -430,6 +430,8 @@ enum d40_lli_flags {
> LLI_LAST_LINK = 1 << 3,
> };
>
> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
> +
> void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> u32 *src_cfg,
> u32 *dst_cfg,
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
2013-04-22 9:51 ` Vinod Koul
@ 2013-04-22 10:40 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:40 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
> > void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > u32 *src_cfg, u32 *dst_cfg, bool is_log)
> > @@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > src |= 1 << D40_SREG_CFG_PRI_POS;
> > dst |= 1 << D40_SREG_CFG_PRI_POS;
> shouldnt these be converted to BIT() macro and in gim_unmask above?
> Driver needs to be consistent in doing things
Absolutely they do. I haven't converted ste_dma40_ll.c to BIT yet
though. I have this on my TODO and it will happen in the next
patch-set.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
@ 2013-04-22 10:40 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:40 UTC (permalink / raw)
To: linux-arm-kernel
> > void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > u32 *src_cfg, u32 *dst_cfg, bool is_log)
> > @@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > src |= 1 << D40_SREG_CFG_PRI_POS;
> > dst |= 1 << D40_SREG_CFG_PRI_POS;
> shouldnt these be converted to BIT() macro and in gim_unmask above?
> Driver needs to be consistent in doing things
Absolutely they do. I haven't converted ste_dma40_ll.c to BIT yet
though. I have this on my TODO and it will happen in the next
patch-set.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
2013-04-22 10:40 ` Lee Jones
@ 2013-04-24 8:51 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:51 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Mon, 22 Apr 2013, Lee Jones wrote:
> > > void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > > u32 *src_cfg, u32 *dst_cfg, bool is_log)
> > > @@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > > src |= 1 << D40_SREG_CFG_PRI_POS;
> > > dst |= 1 << D40_SREG_CFG_PRI_POS;
> > shouldnt these be converted to BIT() macro and in gim_unmask above?
> > Driver needs to be consistent in doing things
>
> Absolutely they do. I haven't converted ste_dma40_ll.c to BIT yet
> though. I have this on my TODO and it will happen in the next
> patch-set.
Vinod, are you happy to Ack this on the proviso that I follow it up
with a subsequent patch converting the ste_dma40_ll driver to BIT()?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
@ 2013-04-24 8:51 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:51 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 22 Apr 2013, Lee Jones wrote:
> > > void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > > u32 *src_cfg, u32 *dst_cfg, bool is_log)
> > > @@ -107,11 +113,6 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > > src |= 1 << D40_SREG_CFG_PRI_POS;
> > > dst |= 1 << D40_SREG_CFG_PRI_POS;
> > shouldnt these be converted to BIT() macro and in gim_unmask above?
> > Driver needs to be consistent in doing things
>
> Absolutely they do. I haven't converted ste_dma40_ll.c to BIT yet
> though. I have this on my TODO and it will happen in the next
> patch-set.
Vinod, are you happy to Ack this on the proviso that I follow it up
with a subsequent patch converting the ste_dma40_ll driver to BIT()?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 11:00 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:00 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> During the initial setup of a logical channel, it is necessary to unmask
> the GIM in order to receive generated terminal count and error interrupts.
> We're separating out this required code so it will be possible to move
> the remaining code in d40_phy_cfg(), which is mostly runtime configuration
> into the runtime_config() routine.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This commit message needs to reflect the fact that you've observed
that one argument to the d40_phy_cfg() is hardcoded to false in the
runtime config, and that is why we can sink the use into
d40_alloc_chan_resources().
(...)
> @@ -2456,6 +2456,9 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
> D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
> }
>
> + if (chan_is_logical(d40c))
> + d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
The clause right above is already a if (chan_is_logical(c)).
Just insert the function call into that clause.
> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
> +
> + *src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> + *dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> +}
Why create a separate function with two lines which is just called from
one single place?
Just sink this into the d40_alloc_chan_resources() function like that:
if (logical) {
*d40c->src_def_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
*d40c->dst_def_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
No need for a separate function and a separate header.
(...)
> /* Sets up SRC and DST CFG register for both logical and physical channels */
> void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> u32 *src_cfg, u32 *dst_cfg, bool is_log)
Take this opportunity to:
(A) delete the argument is_log since it has no use whatsoever after this.
Why pass it at all!
(B) De-indent the if (!is_log) clause... as a natural consequence.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 15/32] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
@ 2013-04-25 11:00 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:00 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> During the initial setup of a logical channel, it is necessary to unmask
> the GIM in order to receive generated terminal count and error interrupts.
> We're separating out this required code so it will be possible to move
> the remaining code in d40_phy_cfg(), which is mostly runtime configuration
> into the runtime_config() routine.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This commit message needs to reflect the fact that you've observed
that one argument to the d40_phy_cfg() is hardcoded to false in the
runtime config, and that is why we can sink the use into
d40_alloc_chan_resources().
(...)
> @@ -2456,6 +2456,9 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
> D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
> }
>
> + if (chan_is_logical(d40c))
> + d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
The clause right above is already a if (chan_is_logical(c)).
Just insert the function call into that clause.
> +void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
> +
> + *src_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> + *dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> +}
Why create a separate function with two lines which is just called from
one single place?
Just sink this into the d40_alloc_chan_resources() function like that:
if (logical) {
*d40c->src_def_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
*d40c->dst_def_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
No need for a separate function and a separate header.
(...)
> /* Sets up SRC and DST CFG register for both logical and physical channels */
> void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> u32 *src_cfg, u32 *dst_cfg, bool is_log)
Take this opportunity to:
(A) delete the argument is_log since it has no use whatsoever after this.
Why pass it at all!
(B) De-indent the if (!is_log) clause... as a natural consequence.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
All configuration left in d40_phy_cfg() is runtime configurable and
there is already a call into it from d40_runtime_config(), so let's
rely on that.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 178a03c..1c570b6 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2437,9 +2437,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
}
pm_runtime_get_sync(d40c->base->dev);
- /* Fill in basic CFG register values */
- d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
- &d40c->dst_def_cfg, chan_is_logical(d40c));
d40_set_prio_realtime(d40c);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
All configuration left in d40_phy_cfg() is runtime configurable and
there is already a call into it from d40_runtime_config(), so let's
rely on that.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 178a03c..1c570b6 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2437,9 +2437,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
}
pm_runtime_get_sync(d40c->base->dev);
- /* Fill in basic CFG register values */
- d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
- &d40c->dst_def_cfg, chan_is_logical(d40c));
d40_set_prio_realtime(d40c);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* Re: [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:55 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:55 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> All configuration left in d40_phy_cfg() is runtime configurable and
> there is already a call into it from d40_runtime_config(), so let's
> rely on that.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
@ 2013-04-18 10:55 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:55 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> All configuration left in d40_phy_cfg() is runtime configurable and
> there is already a call into it from d40_runtime_config(), so let's
> rely on that.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
2013-04-18 10:11 ` Lee Jones
@ 2013-04-22 9:52 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:52 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:11:58AM +0100, Lee Jones wrote:
> All configuration left in d40_phy_cfg() is runtime configurable and
> there is already a call into it from d40_runtime_config(), so let's
> rely on that.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 178a03c..1c570b6 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2437,9 +2437,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
> }
>
> pm_runtime_get_sync(d40c->base->dev);
> - /* Fill in basic CFG register values */
> - d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
> - &d40c->dst_def_cfg, chan_is_logical(d40c));
>
> d40_set_prio_realtime(d40c);
>
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
@ 2013-04-22 9:52 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:52 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:11:58AM +0100, Lee Jones wrote:
> All configuration left in d40_phy_cfg() is runtime configurable and
> there is already a call into it from d40_runtime_config(), so let's
> rely on that.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 178a03c..1c570b6 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2437,9 +2437,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
> }
>
> pm_runtime_get_sync(d40c->base->dev);
> - /* Fill in basic CFG register values */
> - d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
> - &d40c->dst_def_cfg, chan_is_logical(d40c));
>
> d40_set_prio_realtime(d40c);
>
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 11:09 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:09 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> All configuration left in d40_phy_cfg() is runtime configurable and
> there is already a call into it from d40_runtime_config(), so let's
> rely on that.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
NAK. Have you really tested this with memcpy()?
The runtime config function is *not* called when doing memcpy
DMA, still the channels used for memcpy need to be configured
obviously. Now you're assuming that every time anyone is using
a DMA channel they will first allocate it, then call the runtime
config. This is not true.
Runtime config is only used when doing dev->mem and
mem->dev DMA.
You may just as well compile in the test program that is there right
in the kernel and run it ... it's good! (DMA Test Client in
menuconfig under drivers/dma engine support...)
There was this other patch not taking the memcpy channels
into the array that I think will also cause a crash when doing
memcpy so I'm pretty sure you're not testing this.
When I test these patches I will run it, and just report
that memcpy doesn't work if it doesn't and then you'll
have to figure it out anyway, so enjoy...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 16/32] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
@ 2013-04-25 11:09 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:09 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> All configuration left in d40_phy_cfg() is runtime configurable and
> there is already a call into it from d40_runtime_config(), so let's
> rely on that.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
NAK. Have you really tested this with memcpy()?
The runtime config function is *not* called when doing memcpy
DMA, still the channels used for memcpy need to be configured
obviously. Now you're assuming that every time anyone is using
a DMA channel they will first allocate it, then call the runtime
config. This is not true.
Runtime config is only used when doing dev->mem and
mem->dev DMA.
You may just as well compile in the test program that is there right
in the kernel and run it ... it's good! (DMA Test Client in
menuconfig under drivers/dma engine support...)
There was this other patch not taking the memcpy channels
into the array that I think will also cause a crash when doing
memcpy so I'm pretty sure you're not testing this.
When I test these patches I will run it, and just report
that memcpy doesn't work if it doesn't and then you'll
have to figure it out anyway, so enjoy...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
d40_phy_cfg is now only ever called to configure physical channels, so
there's no requirement to pass though an argument describing the type
of channel and to subsequently test for it.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 3 +-
drivers/dma/ste_dma40_ll.c | 101 +++++++++++++++++++++-----------------------
drivers/dma/ste_dma40_ll.h | 3 +-
3 files changed, 50 insertions(+), 57 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 1c570b6..ff41972 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2799,8 +2799,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
if (chan_is_logical(d40c))
d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
else
- d40_phy_cfg(cfg, &d40c->src_def_cfg,
- &d40c->dst_def_cfg, false);
+ d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
/* These settings will take precedence later */
d40c->runtime_addr = config_addr;
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index b72d3e2..9ab9dff 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -56,63 +56,58 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
*dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
}
-/* Sets up SRC and DST CFG register for both logical and physical channels */
-void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
- u32 *src_cfg, u32 *dst_cfg, bool is_log)
+void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
{
u32 src = 0;
u32 dst = 0;
- if (!is_log) {
- /* Physical channel */
- if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
- (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
- /* Set master port to 1 */
- src |= 1 << D40_SREG_CFG_MST_POS;
- src |= D40_TYPE_TO_EVENT(cfg->dev_type);
-
- if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
- src |= 1 << D40_SREG_CFG_PHY_TM_POS;
- else
- src |= 3 << D40_SREG_CFG_PHY_TM_POS;
- }
- if ((cfg->dir == STEDMA40_MEM_TO_PERIPH) ||
- (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
- /* Set master port to 1 */
- dst |= 1 << D40_SREG_CFG_MST_POS;
- dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
-
- if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
- dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
- else
- dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
- }
- /* Interrupt on end of transfer for destination */
- dst |= 1 << D40_SREG_CFG_TIM_POS;
-
- /* Generate interrupt on error */
- src |= 1 << D40_SREG_CFG_EIM_POS;
- dst |= 1 << D40_SREG_CFG_EIM_POS;
-
- /* PSIZE */
- if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
- src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
- src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
- }
- if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
- dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
- dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
- }
-
- /* Element size */
- src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
- dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
-
- /* Set the priority bit to high for the physical channel */
- if (cfg->high_priority) {
- src |= 1 << D40_SREG_CFG_PRI_POS;
- dst |= 1 << D40_SREG_CFG_PRI_POS;
- }
+ if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
+ (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
+ /* Set master port to 1 */
+ src |= 1 << D40_SREG_CFG_MST_POS;
+ src |= D40_TYPE_TO_EVENT(cfg->dev_type);
+
+ if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
+ src |= 1 << D40_SREG_CFG_PHY_TM_POS;
+ else
+ src |= 3 << D40_SREG_CFG_PHY_TM_POS;
+ }
+ if ((cfg->dir == STEDMA40_MEM_TO_PERIPH) ||
+ (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
+ /* Set master port to 1 */
+ dst |= 1 << D40_SREG_CFG_MST_POS;
+ dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
+
+ if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
+ dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
+ else
+ dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
+ }
+ /* Interrupt on end of transfer for destination */
+ dst |= 1 << D40_SREG_CFG_TIM_POS;
+
+ /* Generate interrupt on error */
+ src |= 1 << D40_SREG_CFG_EIM_POS;
+ dst |= 1 << D40_SREG_CFG_EIM_POS;
+
+ /* PSIZE */
+ if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
+ src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
+ src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
+ }
+ if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
+ dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
+ dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
+ }
+
+ /* Element size */
+ src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
+ dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
+
+ /* Set the priority bit to high for the physical channel */
+ if (cfg->high_priority) {
+ src |= 1 << D40_SREG_CFG_PRI_POS;
+ dst |= 1 << D40_SREG_CFG_PRI_POS;
}
if (cfg->src_info.big_endian)
diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
index 8aad679..e54df09 100644
--- a/drivers/dma/ste_dma40_ll.h
+++ b/drivers/dma/ste_dma40_ll.h
@@ -434,8 +434,7 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
u32 *src_cfg,
- u32 *dst_cfg,
- bool is_log);
+ u32 *dst_cfg);
void d40_log_cfg(struct stedma40_chan_cfg *cfg,
u32 *lcsp1,
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
@ 2013-04-18 10:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
d40_phy_cfg is now only ever called to configure physical channels, so
there's no requirement to pass though an argument describing the type
of channel and to subsequently test for it.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 3 +-
drivers/dma/ste_dma40_ll.c | 101 +++++++++++++++++++++-----------------------
drivers/dma/ste_dma40_ll.h | 3 +-
3 files changed, 50 insertions(+), 57 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 1c570b6..ff41972 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2799,8 +2799,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
if (chan_is_logical(d40c))
d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
else
- d40_phy_cfg(cfg, &d40c->src_def_cfg,
- &d40c->dst_def_cfg, false);
+ d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
/* These settings will take precedence later */
d40c->runtime_addr = config_addr;
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index b72d3e2..9ab9dff 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -56,63 +56,58 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
*dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
}
-/* Sets up SRC and DST CFG register for both logical and physical channels */
-void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
- u32 *src_cfg, u32 *dst_cfg, bool is_log)
+void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
{
u32 src = 0;
u32 dst = 0;
- if (!is_log) {
- /* Physical channel */
- if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
- (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
- /* Set master port to 1 */
- src |= 1 << D40_SREG_CFG_MST_POS;
- src |= D40_TYPE_TO_EVENT(cfg->dev_type);
-
- if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
- src |= 1 << D40_SREG_CFG_PHY_TM_POS;
- else
- src |= 3 << D40_SREG_CFG_PHY_TM_POS;
- }
- if ((cfg->dir == STEDMA40_MEM_TO_PERIPH) ||
- (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
- /* Set master port to 1 */
- dst |= 1 << D40_SREG_CFG_MST_POS;
- dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
-
- if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
- dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
- else
- dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
- }
- /* Interrupt on end of transfer for destination */
- dst |= 1 << D40_SREG_CFG_TIM_POS;
-
- /* Generate interrupt on error */
- src |= 1 << D40_SREG_CFG_EIM_POS;
- dst |= 1 << D40_SREG_CFG_EIM_POS;
-
- /* PSIZE */
- if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
- src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
- src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
- }
- if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
- dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
- dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
- }
-
- /* Element size */
- src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
- dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
-
- /* Set the priority bit to high for the physical channel */
- if (cfg->high_priority) {
- src |= 1 << D40_SREG_CFG_PRI_POS;
- dst |= 1 << D40_SREG_CFG_PRI_POS;
- }
+ if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
+ (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
+ /* Set master port to 1 */
+ src |= 1 << D40_SREG_CFG_MST_POS;
+ src |= D40_TYPE_TO_EVENT(cfg->dev_type);
+
+ if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
+ src |= 1 << D40_SREG_CFG_PHY_TM_POS;
+ else
+ src |= 3 << D40_SREG_CFG_PHY_TM_POS;
+ }
+ if ((cfg->dir == STEDMA40_MEM_TO_PERIPH) ||
+ (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
+ /* Set master port to 1 */
+ dst |= 1 << D40_SREG_CFG_MST_POS;
+ dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
+
+ if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
+ dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
+ else
+ dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
+ }
+ /* Interrupt on end of transfer for destination */
+ dst |= 1 << D40_SREG_CFG_TIM_POS;
+
+ /* Generate interrupt on error */
+ src |= 1 << D40_SREG_CFG_EIM_POS;
+ dst |= 1 << D40_SREG_CFG_EIM_POS;
+
+ /* PSIZE */
+ if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
+ src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
+ src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
+ }
+ if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
+ dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
+ dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
+ }
+
+ /* Element size */
+ src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
+ dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
+
+ /* Set the priority bit to high for the physical channel */
+ if (cfg->high_priority) {
+ src |= 1 << D40_SREG_CFG_PRI_POS;
+ dst |= 1 << D40_SREG_CFG_PRI_POS;
}
if (cfg->src_info.big_endian)
diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
index 8aad679..e54df09 100644
--- a/drivers/dma/ste_dma40_ll.h
+++ b/drivers/dma/ste_dma40_ll.h
@@ -434,8 +434,7 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
u32 *src_cfg,
- u32 *dst_cfg,
- bool is_log);
+ u32 *dst_cfg);
void d40_log_cfg(struct stedma40_chan_cfg *cfg,
u32 *lcsp1,
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
2013-04-18 10:11 ` Lee Jones
@ 2013-04-22 9:34 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:34 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:11:59AM +0100, Lee Jones wrote:
> d40_phy_cfg is now only ever called to configure physical channels, so
> there's no requirement to pass though an argument describing the type
> of channel and to subsequently test for it.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/dma/ste_dma40.c | 3 +-
> drivers/dma/ste_dma40_ll.c | 101 +++++++++++++++++++++-----------------------
> drivers/dma/ste_dma40_ll.h | 3 +-
> 3 files changed, 50 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 1c570b6..ff41972 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2799,8 +2799,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
> if (chan_is_logical(d40c))
> d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> else
> - d40_phy_cfg(cfg, &d40c->src_def_cfg,
> - &d40c->dst_def_cfg, false);
> + d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
>
> /* These settings will take precedence later */
> d40c->runtime_addr = config_addr;
> diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
> index b72d3e2..9ab9dff 100644
> --- a/drivers/dma/ste_dma40_ll.c
> +++ b/drivers/dma/ste_dma40_ll.c
> @@ -56,63 +56,58 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
> *dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> }
>
> -/* Sets up SRC and DST CFG register for both logical and physical channels */
> -void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> - u32 *src_cfg, u32 *dst_cfg, bool is_log)
> +void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
> {
> u32 src = 0;
> u32 dst = 0;
>
> - if (!is_log) {
> - /* Physical channel */
> - if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
> - (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> - /* Set master port to 1 */
> - src |= 1 << D40_SREG_CFG_MST_POS;
> - src |= D40_TYPE_TO_EVENT(cfg->dev_type);
> -
> - if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> - src |= 1 << D40_SREG_CFG_PHY_TM_POS;
> - else
> - src |= 3 << D40_SREG_CFG_PHY_TM_POS;
> - }
> - if ((cfg->dir == STEDMA40_MEM_TO_PERIPH) ||
> - (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> - /* Set master port to 1 */
> - dst |= 1 << D40_SREG_CFG_MST_POS;
> - dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
> -
> - if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> - dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
> - else
> - dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
> - }
> - /* Interrupt on end of transfer for destination */
> - dst |= 1 << D40_SREG_CFG_TIM_POS;
> -
> - /* Generate interrupt on error */
> - src |= 1 << D40_SREG_CFG_EIM_POS;
> - dst |= 1 << D40_SREG_CFG_EIM_POS;
> -
> - /* PSIZE */
> - if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
> - src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> - src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
> - }
> - if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
> - dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> - dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
> - }
> -
> - /* Element size */
> - src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
> - dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
> -
> - /* Set the priority bit to high for the physical channel */
> - if (cfg->high_priority) {
> - src |= 1 << D40_SREG_CFG_PRI_POS;
> - dst |= 1 << D40_SREG_CFG_PRI_POS;
> - }
> + if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
> + (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
Why would you need your own direction defines, I see that there is not much
diff between these and what dmaengine defines, so perhpas you could use
those?
> + /* Set master port to 1 */
> + src |= 1 << D40_SREG_CFG_MST_POS;
> + src |= D40_TYPE_TO_EVENT(cfg->dev_type);
> +
> + if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> + src |= 1 << D40_SREG_CFG_PHY_TM_POS;
> + else
> + src |= 3 << D40_SREG_CFG_PHY_TM_POS;
> + }
> + if ((cfg->dir == STEDMA40_MEM_TO_PERIPH) ||
> + (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> + /* Set master port to 1 */
> + dst |= 1 << D40_SREG_CFG_MST_POS;
> + dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
> +
> + if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> + dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
> + else
> + dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
> + }
> + /* Interrupt on end of transfer for destination */
> + dst |= 1 << D40_SREG_CFG_TIM_POS;
> +
> + /* Generate interrupt on error */
> + src |= 1 << D40_SREG_CFG_EIM_POS;
> + dst |= 1 << D40_SREG_CFG_EIM_POS;
> +
> + /* PSIZE */
> + if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
> + src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> + src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
> + }
> + if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
> + dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> + dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
> + }
> +
> + /* Element size */
> + src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
> + dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
> +
> + /* Set the priority bit to high for the physical channel */
> + if (cfg->high_priority) {
> + src |= 1 << D40_SREG_CFG_PRI_POS;
> + dst |= 1 << D40_SREG_CFG_PRI_POS;
> }
>
> if (cfg->src_info.big_endian)
> diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
> index 8aad679..e54df09 100644
> --- a/drivers/dma/ste_dma40_ll.h
> +++ b/drivers/dma/ste_dma40_ll.h
> @@ -434,8 +434,7 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
>
> void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> u32 *src_cfg,
> - u32 *dst_cfg,
> - bool is_log);
> + u32 *dst_cfg);
>
> void d40_log_cfg(struct stedma40_chan_cfg *cfg,
> u32 *lcsp1,
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
@ 2013-04-22 9:34 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:34 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:11:59AM +0100, Lee Jones wrote:
> d40_phy_cfg is now only ever called to configure physical channels, so
> there's no requirement to pass though an argument describing the type
> of channel and to subsequently test for it.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/dma/ste_dma40.c | 3 +-
> drivers/dma/ste_dma40_ll.c | 101 +++++++++++++++++++++-----------------------
> drivers/dma/ste_dma40_ll.h | 3 +-
> 3 files changed, 50 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 1c570b6..ff41972 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2799,8 +2799,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
> if (chan_is_logical(d40c))
> d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> else
> - d40_phy_cfg(cfg, &d40c->src_def_cfg,
> - &d40c->dst_def_cfg, false);
> + d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
>
> /* These settings will take precedence later */
> d40c->runtime_addr = config_addr;
> diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
> index b72d3e2..9ab9dff 100644
> --- a/drivers/dma/ste_dma40_ll.c
> +++ b/drivers/dma/ste_dma40_ll.c
> @@ -56,63 +56,58 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg) {
> *dst_cfg |= 1 << D40_SREG_CFG_LOG_GIM_POS;
> }
>
> -/* Sets up SRC and DST CFG register for both logical and physical channels */
> -void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> - u32 *src_cfg, u32 *dst_cfg, bool is_log)
> +void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
> {
> u32 src = 0;
> u32 dst = 0;
>
> - if (!is_log) {
> - /* Physical channel */
> - if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
> - (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> - /* Set master port to 1 */
> - src |= 1 << D40_SREG_CFG_MST_POS;
> - src |= D40_TYPE_TO_EVENT(cfg->dev_type);
> -
> - if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> - src |= 1 << D40_SREG_CFG_PHY_TM_POS;
> - else
> - src |= 3 << D40_SREG_CFG_PHY_TM_POS;
> - }
> - if ((cfg->dir == STEDMA40_MEM_TO_PERIPH) ||
> - (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> - /* Set master port to 1 */
> - dst |= 1 << D40_SREG_CFG_MST_POS;
> - dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
> -
> - if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> - dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
> - else
> - dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
> - }
> - /* Interrupt on end of transfer for destination */
> - dst |= 1 << D40_SREG_CFG_TIM_POS;
> -
> - /* Generate interrupt on error */
> - src |= 1 << D40_SREG_CFG_EIM_POS;
> - dst |= 1 << D40_SREG_CFG_EIM_POS;
> -
> - /* PSIZE */
> - if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
> - src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> - src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
> - }
> - if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
> - dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> - dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
> - }
> -
> - /* Element size */
> - src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
> - dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
> -
> - /* Set the priority bit to high for the physical channel */
> - if (cfg->high_priority) {
> - src |= 1 << D40_SREG_CFG_PRI_POS;
> - dst |= 1 << D40_SREG_CFG_PRI_POS;
> - }
> + if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
> + (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
Why would you need your own direction defines, I see that there is not much
diff between these and what dmaengine defines, so perhpas you could use
those?
> + /* Set master port to 1 */
> + src |= 1 << D40_SREG_CFG_MST_POS;
> + src |= D40_TYPE_TO_EVENT(cfg->dev_type);
> +
> + if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> + src |= 1 << D40_SREG_CFG_PHY_TM_POS;
> + else
> + src |= 3 << D40_SREG_CFG_PHY_TM_POS;
> + }
> + if ((cfg->dir == STEDMA40_MEM_TO_PERIPH) ||
> + (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> + /* Set master port to 1 */
> + dst |= 1 << D40_SREG_CFG_MST_POS;
> + dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
> +
> + if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> + dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
> + else
> + dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
> + }
> + /* Interrupt on end of transfer for destination */
> + dst |= 1 << D40_SREG_CFG_TIM_POS;
> +
> + /* Generate interrupt on error */
> + src |= 1 << D40_SREG_CFG_EIM_POS;
> + dst |= 1 << D40_SREG_CFG_EIM_POS;
> +
> + /* PSIZE */
> + if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
> + src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> + src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
> + }
> + if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
> + dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> + dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
> + }
> +
> + /* Element size */
> + src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
> + dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
> +
> + /* Set the priority bit to high for the physical channel */
> + if (cfg->high_priority) {
> + src |= 1 << D40_SREG_CFG_PRI_POS;
> + dst |= 1 << D40_SREG_CFG_PRI_POS;
> }
>
> if (cfg->src_info.big_endian)
> diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
> index 8aad679..e54df09 100644
> --- a/drivers/dma/ste_dma40_ll.h
> +++ b/drivers/dma/ste_dma40_ll.h
> @@ -434,8 +434,7 @@ void d40_log_gim_unmask(u32 *src_cfg, u32 *dst_cfg);
>
> void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> u32 *src_cfg,
> - u32 *dst_cfg,
> - bool is_log);
> + u32 *dst_cfg);
>
> void d40_log_cfg(struct stedma40_chan_cfg *cfg,
> u32 *lcsp1,
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
2013-04-22 9:34 ` Vinod Koul
@ 2013-04-22 10:18 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:18 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
> > + if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
> > + (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> Why would you need your own direction defines, I see that there is not much
> diff between these and what dmaengine defines, so perhpas you could use
> those?
I agree. I'll speak to the STE folk.
For this (and other) patch(es), I'll continue to use the STEDMA40 ones
though. Converting everything over to the generic defines should be a
subsequent patch-set IMHO.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
@ 2013-04-22 10:18 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:18 UTC (permalink / raw)
To: linux-arm-kernel
> > + if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
> > + (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> Why would you need your own direction defines, I see that there is not much
> diff between these and what dmaengine defines, so perhpas you could use
> those?
I agree. I'll speak to the STE folk.
For this (and other) patch(es), I'll continue to use the STEDMA40 ones
though. Converting everything over to the generic defines should be a
subsequent patch-set IMHO.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
2013-04-22 10:18 ` Lee Jones
@ 2013-04-25 11:14 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:14 UTC (permalink / raw)
To: Lee Jones
Cc: Vinod Koul, linux-arm-kernel, linux-kernel, Arnd Bergmann,
Linus WALLEIJ, Dan Williams, Per Forlin, Rabin Vincent
On Mon, Apr 22, 2013 at 12:18 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> > + if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
>> > + (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
>>
>> Why would you need your own direction defines, I see that there is not much
>> diff between these and what dmaengine defines, so perhpas you could use
>> those?
>
> I agree. I'll speak to the STE folk.
This is because the driver was written before the dmaengine had
the enum dma_transfer_direction.
A simple search-and-replace patch would do the trick...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
@ 2013-04-25 11:14 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:14 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Apr 22, 2013 at 12:18 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> > + if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
>> > + (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
>>
>> Why would you need your own direction defines, I see that there is not much
>> diff between these and what dmaengine defines, so perhpas you could use
>> those?
>
> I agree. I'll speak to the STE folk.
This is because the driver was written before the dmaengine had
the enum dma_transfer_direction.
A simple search-and-replace patch would do the trick...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
2013-04-22 9:34 ` Vinod Koul
@ 2013-04-24 8:55 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:55 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
> > + if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
> > + (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> Why would you need your own direction defines, I see that there is not much
> diff between these and what dmaengine defines, so perhpas you could use
> those?
Same with these ones, subsequent patch?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
@ 2013-04-24 8:55 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:55 UTC (permalink / raw)
To: linux-arm-kernel
> > + if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
> > + (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> Why would you need your own direction defines, I see that there is not much
> diff between these and what dmaengine defines, so perhpas you could use
> those?
Same with these ones, subsequent patch?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
2013-04-18 10:11 ` Lee Jones
@ 2013-04-25 11:12 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:12 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> d40_phy_cfg is now only ever called to configure physical channels, so
> there's no requirement to pass though an argument describing the type
> of channel and to subsequently test for it.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
As mentioned, squash this into the patch where this is made redundant,
no point in first making an argument unused in one patch and then
deleting it in another patch.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 17/32] dmaengine: ste_dma40: Remove redundant argument from d40_phy_cfg()
@ 2013-04-25 11:12 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:12 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
> d40_phy_cfg is now only ever called to configure physical channels, so
> there's no requirement to pass though an argument describing the type
> of channel and to subsequently test for it.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
As mentioned, squash this into the patch where this is made redundant,
no point in first making an argument unused in one patch and then
deleting it in another patch.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 18/32] dmaengine: ste_dma40: Don't configure runtime configurable setup during allocate
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
Using the dmaengine API, allocating and configuring a channel are two
separate actions. Here we're removing logical channel configuration from
the channel allocating routines.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index ff41972..04cc75f 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2441,9 +2441,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
d40_set_prio_realtime(d40c);
if (chan_is_logical(d40c)) {
- d40_log_cfg(&d40c->dma_cfg,
- &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
-
if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
d40c->lcpa = d40c->base->lcpa_base +
d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 18/32] dmaengine: ste_dma40: Don't configure runtime configurable setup during allocate
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Using the dmaengine API, allocating and configuring a channel are two
separate actions. Here we're removing logical channel configuration from
the channel allocating routines.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index ff41972..04cc75f 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2441,9 +2441,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
d40_set_prio_realtime(d40c);
if (chan_is_logical(d40c)) {
- d40_log_cfg(&d40c->dma_cfg,
- &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
-
if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
d40c->lcpa = d40c->base->lcpa_base +
d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 18/32] dmaengine: ste_dma40: Don't configure runtime configurable setup during allocate
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:15 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:15 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Using the dmaengine API, allocating and configuring a channel are two
> separate actions. Here we're removing logical channel configuration from
> the channel allocating routines.
NAK: this is not true for memcpy.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 18/32] dmaengine: ste_dma40: Don't configure runtime configurable setup during allocate
@ 2013-04-25 11:15 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:15 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Using the dmaengine API, allocating and configuring a channel are two
> separate actions. Here we're removing logical channel configuration from
> the channel allocating routines.
NAK: this is not true for memcpy.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 19/32] dmaengine: ste_dma40: Move more setup into the configuration routines
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
The less configuration we can do during the allocation of a channel the
better. As this will mean the likelihood of requiring extra information
which isn't normally passed through the dma_request_channel() is lessened.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 04cc75f..28fe153 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2440,16 +2440,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
d40_set_prio_realtime(d40c);
- if (chan_is_logical(d40c)) {
- if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
- d40c->lcpa = d40c->base->lcpa_base +
- d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
- else
- d40c->lcpa = d40c->base->lcpa_base +
- d40c->dma_cfg.dst_dev_type *
- D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
- }
-
if (chan_is_logical(d40c))
d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
@@ -2793,9 +2783,17 @@ static int d40_set_runtime_config(struct dma_chan *chan,
return ret;
/* Fill in register values */
- if (chan_is_logical(d40c))
+ if (chan_is_logical(d40c)) {
+ if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
+ d40c->lcpa = d40c->base->lcpa_base +
+ d40c->dma_cfg.dev_type * D40_LCPA_CHAN_SIZE;
+ else
+ d40c->lcpa = d40c->base->lcpa_base +
+ d40c->dma_cfg.dev_type *
+ D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
+
d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
- else
+ } else
d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
/* These settings will take precedence later */
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 19/32] dmaengine: ste_dma40: Move more setup into the configuration routines
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
The less configuration we can do during the allocation of a channel the
better. As this will mean the likelihood of requiring extra information
which isn't normally passed through the dma_request_channel() is lessened.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 04cc75f..28fe153 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2440,16 +2440,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
d40_set_prio_realtime(d40c);
- if (chan_is_logical(d40c)) {
- if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
- d40c->lcpa = d40c->base->lcpa_base +
- d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
- else
- d40c->lcpa = d40c->base->lcpa_base +
- d40c->dma_cfg.dst_dev_type *
- D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
- }
-
if (chan_is_logical(d40c))
d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
@@ -2793,9 +2783,17 @@ static int d40_set_runtime_config(struct dma_chan *chan,
return ret;
/* Fill in register values */
- if (chan_is_logical(d40c))
+ if (chan_is_logical(d40c)) {
+ if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
+ d40c->lcpa = d40c->base->lcpa_base +
+ d40c->dma_cfg.dev_type * D40_LCPA_CHAN_SIZE;
+ else
+ d40c->lcpa = d40c->base->lcpa_base +
+ d40c->dma_cfg.dev_type *
+ D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
+
d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
- else
+ } else
d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
/* These settings will take precedence later */
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 19/32] dmaengine: ste_dma40: Move more setup into the configuration routines
2013-04-18 10:12 ` Lee Jones
@ 2013-04-22 9:37 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:37 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:12:01AM +0100, Lee Jones wrote:
> The less configuration we can do during the allocation of a channel the
> better. As this will mean the likelihood of requiring extra information
> which isn't normally passed through the dma_request_channel() is lessened.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 22 ++++++++++------------
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 04cc75f..28fe153 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2440,16 +2440,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
>
> d40_set_prio_realtime(d40c);
>
> - if (chan_is_logical(d40c)) {
> - if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> - d40c->lcpa = d40c->base->lcpa_base +
> - d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
> - else
> - d40c->lcpa = d40c->base->lcpa_base +
> - d40c->dma_cfg.dst_dev_type *
> - D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
> - }
> -
> if (chan_is_logical(d40c))
> d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
>
> @@ -2793,9 +2783,17 @@ static int d40_set_runtime_config(struct dma_chan *chan,
> return ret;
>
> /* Fill in register values */
> - if (chan_is_logical(d40c))
> + if (chan_is_logical(d40c)) {
> + if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> + d40c->lcpa = d40c->base->lcpa_base +
> + d40c->dma_cfg.dev_type * D40_LCPA_CHAN_SIZE;
> + else
> + d40c->lcpa = d40c->base->lcpa_base +
> + d40c->dma_cfg.dev_type *
> + D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
> +
> d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> - else
> + } else
> d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
>
> /* These settings will take precedence later */
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 19/32] dmaengine: ste_dma40: Move more setup into the configuration routines
@ 2013-04-22 9:37 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:37 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:12:01AM +0100, Lee Jones wrote:
> The less configuration we can do during the allocation of a channel the
> better. As this will mean the likelihood of requiring extra information
> which isn't normally passed through the dma_request_channel() is lessened.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 22 ++++++++++------------
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 04cc75f..28fe153 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2440,16 +2440,6 @@ static int d40_alloc_chan_resources(struct dma_chan *chan)
>
> d40_set_prio_realtime(d40c);
>
> - if (chan_is_logical(d40c)) {
> - if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> - d40c->lcpa = d40c->base->lcpa_base +
> - d40c->dma_cfg.src_dev_type * D40_LCPA_CHAN_SIZE;
> - else
> - d40c->lcpa = d40c->base->lcpa_base +
> - d40c->dma_cfg.dst_dev_type *
> - D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
> - }
> -
> if (chan_is_logical(d40c))
> d40_log_gim_unmask(&d40c->src_def_cfg, &d40c->dst_def_cfg);
>
> @@ -2793,9 +2783,17 @@ static int d40_set_runtime_config(struct dma_chan *chan,
> return ret;
>
> /* Fill in register values */
> - if (chan_is_logical(d40c))
> + if (chan_is_logical(d40c)) {
> + if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> + d40c->lcpa = d40c->base->lcpa_base +
> + d40c->dma_cfg.dev_type * D40_LCPA_CHAN_SIZE;
> + else
> + d40c->lcpa = d40c->base->lcpa_base +
> + d40c->dma_cfg.dev_type *
> + D40_LCPA_CHAN_SIZE + D40_LCPA_CHAN_DST_DELTA;
> +
> d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> - else
> + } else
> d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
>
> /* These settings will take precedence later */
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 19/32] dmaengine: ste_dma40: Move more setup into the configuration routines
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:17 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:17 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The less configuration we can do during the allocation of a channel the
> better. As this will mean the likelihood of requiring extra information
> which isn't normally passed through the dma_request_channel() is lessened.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
NAK. You're breaking memcpy.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 19/32] dmaengine: ste_dma40: Move more setup into the configuration routines
@ 2013-04-25 11:17 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:17 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The less configuration we can do during the allocation of a channel the
> better. As this will mean the likelihood of requiring extra information
> which isn't normally passed through the dma_request_channel() is lessened.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
NAK. You're breaking memcpy.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 20/32] dmaengine: ste_dma40: Move rev error-check up to revision acquisition
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
At the moment we fetch the hardware revision, then do some stuff, then
check whether the revision is correct and return in error if it's not.
Well we may as well check it as soon as we know what it is, so let's
move the check right up underneath where we acquire the version.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 28fe153..282dd59 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3185,6 +3185,10 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
* DB8540v1 has revision 4
*/
rev = AMBA_REV_BITS(pid);
+ if (rev < 2) {
+ d40_err(&pdev->dev, "hardware revision: %d is not supported", rev);
+ goto failure;
+ }
plat_data = pdev->dev.platform_data;
@@ -3199,12 +3203,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
rev, res->start, num_phy_chans);
- if (rev < 2) {
- d40_err(&pdev->dev, "hardware revision: %d is not supported",
- rev);
- goto failure;
- }
-
base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
(num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
sizeof(struct d40_chan), GFP_KERNEL);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 20/32] dmaengine: ste_dma40: Move rev error-check up to revision acquisition
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
At the moment we fetch the hardware revision, then do some stuff, then
check whether the revision is correct and return in error if it's not.
Well we may as well check it as soon as we know what it is, so let's
move the check right up underneath where we acquire the version.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 28fe153..282dd59 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3185,6 +3185,10 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
* DB8540v1 has revision 4
*/
rev = AMBA_REV_BITS(pid);
+ if (rev < 2) {
+ d40_err(&pdev->dev, "hardware revision: %d is not supported", rev);
+ goto failure;
+ }
plat_data = pdev->dev.platform_data;
@@ -3199,12 +3203,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
rev, res->start, num_phy_chans);
- if (rev < 2) {
- d40_err(&pdev->dev, "hardware revision: %d is not supported",
- rev);
- goto failure;
- }
-
base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
(num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
sizeof(struct d40_chan), GFP_KERNEL);
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 20/32] dmaengine: ste_dma40: Move rev error-check up to revision acquisition
2013-04-18 10:12 ` Lee Jones
@ 2013-04-22 9:41 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:41 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:12:02AM +0100, Lee Jones wrote:
> At the moment we fetch the hardware revision, then do some stuff, then
> check whether the revision is correct and return in error if it's not.
> Well we may as well check it as soon as we know what it is, so let's
> move the check right up underneath where we acquire the version.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 28fe153..282dd59 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3185,6 +3185,10 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> * DB8540v1 has revision 4
> */
> rev = AMBA_REV_BITS(pid);
> + if (rev < 2) {
> + d40_err(&pdev->dev, "hardware revision: %d is not supported", rev);
> + goto failure;
> + }
>
> plat_data = pdev->dev.platform_data;
>
> @@ -3199,12 +3203,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> rev, res->start, num_phy_chans);
>
> - if (rev < 2) {
> - d40_err(&pdev->dev, "hardware revision: %d is not supported",
> - rev);
> - goto failure;
> - }
> -
> base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
> (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
> sizeof(struct d40_chan), GFP_KERNEL);
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 20/32] dmaengine: ste_dma40: Move rev error-check up to revision acquisition
@ 2013-04-22 9:41 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:41 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:12:02AM +0100, Lee Jones wrote:
> At the moment we fetch the hardware revision, then do some stuff, then
> check whether the revision is correct and return in error if it's not.
> Well we may as well check it as soon as we know what it is, so let's
> move the check right up underneath where we acquire the version.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 28fe153..282dd59 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3185,6 +3185,10 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> * DB8540v1 has revision 4
> */
> rev = AMBA_REV_BITS(pid);
> + if (rev < 2) {
> + d40_err(&pdev->dev, "hardware revision: %d is not supported", rev);
> + goto failure;
> + }
>
> plat_data = pdev->dev.platform_data;
>
> @@ -3199,12 +3203,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> rev, res->start, num_phy_chans);
>
> - if (rev < 2) {
> - d40_err(&pdev->dev, "hardware revision: %d is not supported",
> - rev);
> - goto failure;
> - }
> -
> base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
> (num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
> sizeof(struct d40_chan), GFP_KERNEL);
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 20/32] dmaengine: ste_dma40: Move rev error-check up to revision acquisition
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:17 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:17 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> At the moment we fetch the hardware revision, then do some stuff, then
> check whether the revision is correct and return in error if it's not.
> Well we may as well check it as soon as we know what it is, so let's
> move the check right up underneath where we acquire the version.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 20/32] dmaengine: ste_dma40: Move rev error-check up to revision acquisition
@ 2013-04-25 11:17 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:17 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> At the moment we fetch the hardware revision, then do some stuff, then
> check whether the revision is correct and return in error if it's not.
> Well we may as well check it as soon as we know what it is, so let's
> move the check right up underneath where we acquire the version.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
Now we know the total of physical and logical channels, we may as
well report them within the information log.
Before:
dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
After:
<as above ...> and 256 logical channels
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 282dd59..805049c 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
- dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
- rev, res->start, num_phy_chans);
+ dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
+ "%d physical channels and %d logical channels\n",
+ rev, res->start, num_phy_chans, num_log_chans);
base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
(num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Now we know the total of physical and logical channels, we may as
well report them within the information log.
Before:
dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
After:
<as above ...> and 256 logical channels
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 282dd59..805049c 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
- dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
- rev, res->start, num_phy_chans);
+ dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
+ "%d physical channels and %d logical channels\n",
+ rev, res->start, num_phy_chans, num_log_chans);
base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
(num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* Re: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
2013-04-18 10:12 ` Lee Jones
@ 2013-04-22 9:36 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:36 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> Now we know the total of physical and logical channels, we may as
> well report them within the information log.
>
> Before:
> dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
>
> After:
> <as above ...> and 256 logical channels
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/dma/ste_dma40.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 282dd59..805049c 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>
> num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
>
> - dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> - rev, res->start, num_phy_chans);
> + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> + "%d physical channels and %d logical channels\n",
> + rev, res->start, num_phy_chans, num_log_chans);
Splitting log messages across lines is bad idea and sacrifces readablity... also
wasnt splitting logging to multiple lines emit checkpatch warn
--
~Vinod
>
> base = kzalloc(ALIGN(sizeof(struct d40_base), 4) + (num_phy_chans +
> num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) * -- 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
@ 2013-04-22 9:36 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:36 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> Now we know the total of physical and logical channels, we may as
> well report them within the information log.
>
> Before:
> dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
>
> After:
> <as above ...> and 256 logical channels
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/dma/ste_dma40.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 282dd59..805049c 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
>
> num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
>
> - dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> - rev, res->start, num_phy_chans);
> + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> + "%d physical channels and %d logical channels\n",
> + rev, res->start, num_phy_chans, num_log_chans);
Splitting log messages across lines is bad idea and sacrifces readablity... also
wasnt splitting logging to multiple lines emit checkpatch warn
--
~Vinod
>
> base = kzalloc(ALIGN(sizeof(struct d40_base), 4) + (num_phy_chans +
> num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) * -- 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
2013-04-22 9:36 ` Vinod Koul
@ 2013-04-22 10:14 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:14 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Mon, 22 Apr 2013, Vinod Koul wrote:
> On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > Now we know the total of physical and logical channels, we may as
> > well report them within the information log.
> >
> > Before:
> > dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
> >
> > After:
> > <as above ...> and 256 logical channels
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/dma/ste_dma40.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index 282dd59..805049c 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> >
> > num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> >
> > - dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> > - rev, res->start, num_phy_chans);
> > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > + "%d physical channels and %d logical channels\n",
> > + rev, res->start, num_phy_chans, num_log_chans);
> Splitting log messages across lines is bad idea and sacrifces readablity... also
> wasnt splitting logging to multiple lines emit checkpatch warn
You also get a check-patch error if your lines are over 80 chars.
How would you solve this?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
@ 2013-04-22 10:14 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:14 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 22 Apr 2013, Vinod Koul wrote:
> On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > Now we know the total of physical and logical channels, we may as
> > well report them within the information log.
> >
> > Before:
> > dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
> >
> > After:
> > <as above ...> and 256 logical channels
> >
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/dma/ste_dma40.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index 282dd59..805049c 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> >
> > num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> >
> > - dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> > - rev, res->start, num_phy_chans);
> > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > + "%d physical channels and %d logical channels\n",
> > + rev, res->start, num_phy_chans, num_log_chans);
> Splitting log messages across lines is bad idea and sacrifces readablity... also
> wasnt splitting logging to multiple lines emit checkpatch warn
You also get a check-patch error if your lines are over 80 chars.
How would you solve this?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
2013-04-22 10:14 ` Lee Jones
@ 2013-04-22 9:48 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:48 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
>
> > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > Now we know the total of physical and logical channels, we may as
> > > well report them within the information log.
> > >
> > > Before:
> > > dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
> > >
> > > After:
> > > <as above ...> and 256 logical channels
> > >
> > > Cc: Vinod Koul <vinod.koul@intel.com>
> > > Cc: Dan Williams <djbw@fb.com>
> > > Cc: Per Forlin <per.forlin@stericsson.com>
> > > Cc: Rabin Vincent <rabin@rab.in>
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > > drivers/dma/ste_dma40.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > > index 282dd59..805049c 100644
> > > --- a/drivers/dma/ste_dma40.c
> > > +++ b/drivers/dma/ste_dma40.c
> > > @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > >
> > > num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> > >
> > > - dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> > > - rev, res->start, num_phy_chans);
> > > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > + "%d physical channels and %d logical channels\n",
> > > + rev, res->start, num_phy_chans, num_log_chans);
> > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > wasnt splitting logging to multiple lines emit checkpatch warn
>
> You also get a check-patch error if your lines are over 80 chars.
No, you get a warn
>
> How would you solve this?
Use common sense :) I would never sacrfice readablity of code. Erring on 80chars
is fine by me as long as it makes sense.
--
~Vinod
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
@ 2013-04-22 9:48 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:48 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
>
> > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > Now we know the total of physical and logical channels, we may as
> > > well report them within the information log.
> > >
> > > Before:
> > > dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
> > >
> > > After:
> > > <as above ...> and 256 logical channels
> > >
> > > Cc: Vinod Koul <vinod.koul@intel.com>
> > > Cc: Dan Williams <djbw@fb.com>
> > > Cc: Per Forlin <per.forlin@stericsson.com>
> > > Cc: Rabin Vincent <rabin@rab.in>
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > > drivers/dma/ste_dma40.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > > index 282dd59..805049c 100644
> > > --- a/drivers/dma/ste_dma40.c
> > > +++ b/drivers/dma/ste_dma40.c
> > > @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > >
> > > num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> > >
> > > - dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> > > - rev, res->start, num_phy_chans);
> > > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > + "%d physical channels and %d logical channels\n",
> > > + rev, res->start, num_phy_chans, num_log_chans);
> > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > wasnt splitting logging to multiple lines emit checkpatch warn
>
> You also get a check-patch error if your lines are over 80 chars.
No, you get a warn
>
> How would you solve this?
Use common sense :) I would never sacrfice readablity of code. Erring on 80chars
is fine by me as long as it makes sense.
--
~Vinod
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
2013-04-22 9:48 ` Vinod Koul
@ 2013-04-22 10:37 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:37 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Mon, 22 Apr 2013, Vinod Koul wrote:
> On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> > On Mon, 22 Apr 2013, Vinod Koul wrote:
> >
> > > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > > Now we know the total of physical and logical channels, we may as
> > > > well report them within the information log.
> > > >
> > > > Before:
> > > > dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
> > > >
> > > > After:
> > > > <as above ...> and 256 logical channels
> > > >
> > > > Cc: Vinod Koul <vinod.koul@intel.com>
> > > > Cc: Dan Williams <djbw@fb.com>
> > > > Cc: Per Forlin <per.forlin@stericsson.com>
> > > > Cc: Rabin Vincent <rabin@rab.in>
> > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > ---
> > > > drivers/dma/ste_dma40.c | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > > > index 282dd59..805049c 100644
> > > > --- a/drivers/dma/ste_dma40.c
> > > > +++ b/drivers/dma/ste_dma40.c
> > > > @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > > >
> > > > num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> > > >
> > > > - dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> > > > - rev, res->start, num_phy_chans);
> > > > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > > + "%d physical channels and %d logical channels\n",
> > > > + rev, res->start, num_phy_chans, num_log_chans);
> > > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > > wasnt splitting logging to multiple lines emit checkpatch warn
> >
> > You also get a check-patch error if your lines are over 80 chars.
> No, you get a warn
You only get a warning for this too:
WARNING: quoted string split across lines
#33: FILE: drivers/dma/ste_dma40.c:3204:
+ dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
+ "%d physical channels and %d logical channels\n",
> > How would you solve this?
> Use common sense :) I would never sacrfice readablity of code. Erring on 80chars
> is fine by me as long as it makes sense.
Common sense to me says split a string which goes over 100 chars. :)
... and I don't think readability is compromised all that much, if at all.
But you're the maintainer. I'll go with whatever you decide.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
@ 2013-04-22 10:37 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-22 10:37 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 22 Apr 2013, Vinod Koul wrote:
> On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> > On Mon, 22 Apr 2013, Vinod Koul wrote:
> >
> > > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > > Now we know the total of physical and logical channels, we may as
> > > > well report them within the information log.
> > > >
> > > > Before:
> > > > dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
> > > >
> > > > After:
> > > > <as above ...> and 256 logical channels
> > > >
> > > > Cc: Vinod Koul <vinod.koul@intel.com>
> > > > Cc: Dan Williams <djbw@fb.com>
> > > > Cc: Per Forlin <per.forlin@stericsson.com>
> > > > Cc: Rabin Vincent <rabin@rab.in>
> > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > ---
> > > > drivers/dma/ste_dma40.c | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > > > index 282dd59..805049c 100644
> > > > --- a/drivers/dma/ste_dma40.c
> > > > +++ b/drivers/dma/ste_dma40.c
> > > > @@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> > > >
> > > > num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
> > > >
> > > > - dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
> > > > - rev, res->start, num_phy_chans);
> > > > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > > + "%d physical channels and %d logical channels\n",
> > > > + rev, res->start, num_phy_chans, num_log_chans);
> > > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > > wasnt splitting logging to multiple lines emit checkpatch warn
> >
> > You also get a check-patch error if your lines are over 80 chars.
> No, you get a warn
You only get a warning for this too:
WARNING: quoted string split across lines
#33: FILE: drivers/dma/ste_dma40.c:3204:
+ dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
+ "%d physical channels and %d logical channels\n",
> > How would you solve this?
> Use common sense :) I would never sacrfice readablity of code. Erring on 80chars
> is fine by me as long as it makes sense.
Common sense to me says split a string which goes over 100 chars. :)
... and I don't think readability is compromised all that much, if at all.
But you're the maintainer. I'll go with whatever you decide.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
2013-04-22 10:37 ` Lee Jones
@ 2013-04-22 10:23 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:23 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Mon, Apr 22, 2013 at 11:37:15AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
> You only get a warning for this too:
Yup, oh i wrongly mention error
>
> WARNING: quoted string split across lines
> #33: FILE: drivers/dma/ste_dma40.c:3204:
> + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> + "%d physical channels and %d logical channels\n",
>
> > > How would you solve this?
> > Use common sense :) I would never sacrfice readablity of code. Erring on 80chars
> > is fine by me as long as it makes sense.
>
> Common sense to me says split a string which goes over 100 chars. :)
agreed :)
>
> ... and I don't think readability is compromised all that much, if at all.
I think if you start above at next line, you can be in 100chars and still be in
single line...
dev_info(&pdev->dev,
"hardware revision: %d @ 0x%x with %d physical channels and %d logical channels\n",
Plus a truncated one would help too...
s/revision/rev
s/channels/ch
etc
would bring this to saner levels :)
--
~Vinod
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
@ 2013-04-22 10:23 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:23 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Apr 22, 2013 at 11:37:15AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
> You only get a warning for this too:
Yup, oh i wrongly mention error
>
> WARNING: quoted string split across lines
> #33: FILE: drivers/dma/ste_dma40.c:3204:
> + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> + "%d physical channels and %d logical channels\n",
>
> > > How would you solve this?
> > Use common sense :) I would never sacrfice readablity of code. Erring on 80chars
> > is fine by me as long as it makes sense.
>
> Common sense to me says split a string which goes over 100 chars. :)
agreed :)
>
> ... and I don't think readability is compromised all that much, if at all.
I think if you start above at next line, you can be in 100chars and still be in
single line...
dev_info(&pdev->dev,
"hardware revision: %d @ 0x%x with %d physical channels and %d logical channels\n",
Plus a truncated one would help too...
s/revision/rev
s/channels/ch
etc
would bring this to saner levels :)
--
~Vinod
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
2013-04-22 10:37 ` Lee Jones
@ 2013-04-22 10:52 ` Russell King - ARM Linux
-1 siblings, 0 replies; 337+ messages in thread
From: Russell King - ARM Linux @ 2013-04-22 10:52 UTC (permalink / raw)
To: Lee Jones
Cc: Vinod Koul, Rabin Vincent, linus.walleij, arnd, linux-kernel,
Per Forlin, Dan Williams, linux-arm-kernel
On Mon, Apr 22, 2013 at 11:37:15AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
>
> > On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> > > On Mon, 22 Apr 2013, Vinod Koul wrote:
> > >
> > > > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > > > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > > > + "%d physical channels and %d logical channels\n",
> > > > > + rev, res->start, num_phy_chans, num_log_chans);
> > > > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > > > wasnt splitting logging to multiple lines emit checkpatch warn
Yes, but for a different reason...
> > > You also get a check-patch error if your lines are over 80 chars.
> > No, you get a warn
>
> You only get a warning for this too:
>
> WARNING: quoted string split across lines
> #33: FILE: drivers/dma/ste_dma40.c:3204:
> + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> + "%d physical channels and %d logical channels\n",
>From coding style: "However, never break user-visible strings such as
printk messages, because that breaks the ability to grep for them."
You can argue that you wouldn't grep for the above string - but consider
if you grepped for "hardware revision.*channels" to try and find the
above message, which would be a reasonable thing to try if you got lots
of hits on just "hardware revision".
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
@ 2013-04-22 10:52 ` Russell King - ARM Linux
0 siblings, 0 replies; 337+ messages in thread
From: Russell King - ARM Linux @ 2013-04-22 10:52 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Apr 22, 2013 at 11:37:15AM +0100, Lee Jones wrote:
> On Mon, 22 Apr 2013, Vinod Koul wrote:
>
> > On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> > > On Mon, 22 Apr 2013, Vinod Koul wrote:
> > >
> > > > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > > > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > > > + "%d physical channels and %d logical channels\n",
> > > > > + rev, res->start, num_phy_chans, num_log_chans);
> > > > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > > > wasnt splitting logging to multiple lines emit checkpatch warn
Yes, but for a different reason...
> > > You also get a check-patch error if your lines are over 80 chars.
> > No, you get a warn
>
> You only get a warning for this too:
>
> WARNING: quoted string split across lines
> #33: FILE: drivers/dma/ste_dma40.c:3204:
> + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> + "%d physical channels and %d logical channels\n",
>From coding style: "However, never break user-visible strings such as
printk messages, because that breaks the ability to grep for them."
You can argue that you wouldn't grep for the above string - but consider
if you grepped for "hardware revision.*channels" to try and find the
above message, which would be a reasonable thing to try if you got lots
of hits on just "hardware revision".
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
2013-04-22 10:52 ` Russell King - ARM Linux
@ 2013-04-24 8:35 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:35 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Vinod Koul, Rabin Vincent, linus.walleij, arnd, linux-kernel,
Per Forlin, Dan Williams, linux-arm-kernel
On Mon, 22 Apr 2013, Russell King - ARM Linux wrote:
> On Mon, Apr 22, 2013 at 11:37:15AM +0100, Lee Jones wrote:
> > On Mon, 22 Apr 2013, Vinod Koul wrote:
> >
> > > On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> > > > On Mon, 22 Apr 2013, Vinod Koul wrote:
> > > >
> > > > > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > > > > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > > > > + "%d physical channels and %d logical channels\n",
> > > > > > + rev, res->start, num_phy_chans, num_log_chans);
> > > > > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > > > > wasnt splitting logging to multiple lines emit checkpatch warn
>
> Yes, but for a different reason...
>
> > > > You also get a check-patch error if your lines are over 80 chars.
> > > No, you get a warn
> >
> > You only get a warning for this too:
> >
> > WARNING: quoted string split across lines
> > #33: FILE: drivers/dma/ste_dma40.c:3204:
> > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > + "%d physical channels and %d logical channels\n",
>
> From coding style: "However, never break user-visible strings such as
> printk messages, because that breaks the ability to grep for them."
>
> You can argue that you wouldn't grep for the above string - but consider
> if you grepped for "hardware revision.*channels" to try and find the
> above message, which would be a reasonable thing to try if you got lots
> of hits on just "hardware revision".
Okay, this I understand. I'll fixup.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 21/32] dmaengine: ste_dma40: Also report the number of logical channels
@ 2013-04-24 8:35 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:35 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 22 Apr 2013, Russell King - ARM Linux wrote:
> On Mon, Apr 22, 2013 at 11:37:15AM +0100, Lee Jones wrote:
> > On Mon, 22 Apr 2013, Vinod Koul wrote:
> >
> > > On Mon, Apr 22, 2013 at 11:14:55AM +0100, Lee Jones wrote:
> > > > On Mon, 22 Apr 2013, Vinod Koul wrote:
> > > >
> > > > > On Thu, Apr 18, 2013 at 11:12:03AM +0100, Lee Jones wrote:
> > > > > > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > > > > > + "%d physical channels and %d logical channels\n",
> > > > > > + rev, res->start, num_phy_chans, num_log_chans);
> > > > > Splitting log messages across lines is bad idea and sacrifces readablity... also
> > > > > wasnt splitting logging to multiple lines emit checkpatch warn
>
> Yes, but for a different reason...
>
> > > > You also get a check-patch error if your lines are over 80 chars.
> > > No, you get a warn
> >
> > You only get a warning for this too:
> >
> > WARNING: quoted string split across lines
> > #33: FILE: drivers/dma/ste_dma40.c:3204:
> > + dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with "
> > + "%d physical channels and %d logical channels\n",
>
> From coding style: "However, never break user-visible strings such as
> printk messages, because that breaks the ability to grep for them."
>
> You can argue that you wouldn't grep for the above string - but consider
> if you grepped for "hardware revision.*channels" to try and find the
> above message, which would be a reasonable thing to try if you got lots
> of hits on just "hardware revision".
Okay, this I understand. I'll fixup.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 21/32 v2] dmaengine: ste_dma40: Also report the number of logical channels
2013-04-18 10:12 ` Lee Jones
@ 2013-04-24 8:39 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:39 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
dmaengine: ste_dma40: Also report the number of logical channels
Now we know the total of physical and logical channels, we may as
well report them within the information log.
Before:
dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
After:
<as above ...> and 256 logical channels
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 4c6df0e..d5a15ec 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
- dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
- rev, res->start, num_phy_chans);
+ dev_info(&pdev->dev,
+ "hardware rev: %d @ 0x%x with %d physical chans and %d logical chans\n",
+ rev, res->start, num_phy_chans, num_log_chans);
base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
(num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
^ permalink raw reply related [flat|nested] 337+ messages in thread
* [PATCH 21/32 v2] dmaengine: ste_dma40: Also report the number of logical channels
@ 2013-04-24 8:39 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-24 8:39 UTC (permalink / raw)
To: linux-arm-kernel
dmaengine: ste_dma40: Also report the number of logical channels
Now we know the total of physical and logical channels, we may as
well report them within the information log.
Before:
dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
After:
<as above ...> and 256 logical channels
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 4c6df0e..d5a15ec 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3200,8 +3200,9 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
- dev_info(&pdev->dev, "hardware revision: %d @ 0x%x with %d physical channels\n",
- rev, res->start, num_phy_chans);
+ dev_info(&pdev->dev,
+ "hardware rev: %d @ 0x%x with %d physical chans and %d logical chans\n",
+ rev, res->start, num_phy_chans, num_log_chans);
base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
(num_phy_chans + num_log_chans + ARRAY_SIZE(dma40_memcpy_channels)) *
^ permalink raw reply related [flat|nested] 337+ messages in thread
* Re: [PATCH 21/32 v2] dmaengine: ste_dma40: Also report the number of logical channels
2013-04-24 8:39 ` Lee Jones
@ 2013-04-25 11:20 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:20 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Wed, Apr 24, 2013 at 10:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
> dmaengine: ste_dma40: Also report the number of logical channels
>
> Now we know the total of physical and logical channels, we may as
> well report them within the information log.
>
> Before:
> dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
>
> After:
> <as above ...> and 256 logical channels
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 21/32 v2] dmaengine: ste_dma40: Also report the number of logical channels
@ 2013-04-25 11:20 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:20 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 24, 2013 at 10:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
> dmaengine: ste_dma40: Also report the number of logical channels
>
> Now we know the total of physical and logical channels, we may as
> well report them within the information log.
>
> Before:
> dma40 dma40.0: hardware revision: 3 @ 0x801c0000 with 8 physical channels
>
> After:
> <as above ...> and 256 logical channels
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on declaration
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
It's the way that most other drivers do it.
Very trivial clean-up which reduces line count and simplifies code.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 805049c..6f9f801 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3119,7 +3119,7 @@ static int __init d40_phy_res_init(struct d40_base *base)
static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
{
- struct stedma40_platform_data *plat_data;
+ struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
struct clk *clk = NULL;
void __iomem *virtbase = NULL;
struct resource *res = NULL;
@@ -3190,8 +3190,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
goto failure;
}
- plat_data = pdev->dev.platform_data;
-
/* The number of physical channels on this HW */
if (plat_data->num_of_phy_chans)
num_phy_chans = plat_data->num_of_phy_chans;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on declaration
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
It's the way that most other drivers do it.
Very trivial clean-up which reduces line count and simplifies code.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 805049c..6f9f801 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3119,7 +3119,7 @@ static int __init d40_phy_res_init(struct d40_base *base)
static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
{
- struct stedma40_platform_data *plat_data;
+ struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
struct clk *clk = NULL;
void __iomem *virtbase = NULL;
struct resource *res = NULL;
@@ -3190,8 +3190,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
goto failure;
}
- plat_data = pdev->dev.platform_data;
-
/* The number of physical channels on this HW */
if (plat_data->num_of_phy_chans)
num_phy_chans = plat_data->num_of_phy_chans;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on declaration
2013-04-18 10:12 ` Lee Jones
@ 2013-04-22 9:38 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:38 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:12:04AM +0100, Lee Jones wrote:
> It's the way that most other drivers do it.
>
> Very trivial clean-up which reduces line count and simplifies code.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 805049c..6f9f801 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3119,7 +3119,7 @@ static int __init d40_phy_res_init(struct d40_base *base)
>
> static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> {
> - struct stedma40_platform_data *plat_data;
> + struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
> struct clk *clk = NULL;
> void __iomem *virtbase = NULL;
> struct resource *res = NULL;
> @@ -3190,8 +3190,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> goto failure;
> }
>
> - plat_data = pdev->dev.platform_data;
> -
> /* The number of physical channels on this HW */
> if (plat_data->num_of_phy_chans)
> num_phy_chans = plat_data->num_of_phy_chans;
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on declaration
@ 2013-04-22 9:38 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:38 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:12:04AM +0100, Lee Jones wrote:
> It's the way that most other drivers do it.
>
> Very trivial clean-up which reduces line count and simplifies code.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 805049c..6f9f801 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3119,7 +3119,7 @@ static int __init d40_phy_res_init(struct d40_base *base)
>
> static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> {
> - struct stedma40_platform_data *plat_data;
> + struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
> struct clk *clk = NULL;
> void __iomem *virtbase = NULL;
> struct resource *res = NULL;
> @@ -3190,8 +3190,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> goto failure;
> }
>
> - plat_data = pdev->dev.platform_data;
> -
> /* The number of physical channels on this HW */
> if (plat_data->num_of_phy_chans)
> num_phy_chans = plat_data->num_of_phy_chans;
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on declaration
2013-04-18 10:12 ` Lee Jones
@ 2013-04-22 9:40 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:40 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:12:04AM +0100, Lee Jones wrote:
> It's the way that most other drivers do it.
>
> Very trivial clean-up which reduces line count and simplifies code.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 805049c..6f9f801 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3119,7 +3119,7 @@ static int __init d40_phy_res_init(struct d40_base *base)
>
> static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> {
> - struct stedma40_platform_data *plat_data;
> + struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
> struct clk *clk = NULL;
> void __iomem *virtbase = NULL;
> struct resource *res = NULL;
> @@ -3190,8 +3190,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> goto failure;
> }
>
> - plat_data = pdev->dev.platform_data;
> -
> /* The number of physical channels on this HW */
> if (plat_data->num_of_phy_chans)
> num_phy_chans = plat_data->num_of_phy_chans;
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on declaration
@ 2013-04-22 9:40 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 9:40 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:12:04AM +0100, Lee Jones wrote:
> It's the way that most other drivers do it.
>
> Very trivial clean-up which reduces line count and simplifies code.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vnod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 805049c..6f9f801 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3119,7 +3119,7 @@ static int __init d40_phy_res_init(struct d40_base *base)
>
> static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> {
> - struct stedma40_platform_data *plat_data;
> + struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
> struct clk *clk = NULL;
> void __iomem *virtbase = NULL;
> struct resource *res = NULL;
> @@ -3190,8 +3190,6 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
> goto failure;
> }
>
> - plat_data = pdev->dev.platform_data;
> -
> /* The number of physical channels on this HW */
> if (plat_data->num_of_phy_chans)
> num_phy_chans = plat_data->num_of_phy_chans;
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on declaration
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:22 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:22 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> It's the way that most other drivers do it.
>
> Very trivial clean-up which reduces line count and simplifies code.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 22/32] dmaengine: ste_dma40: Allocate plat_data on declaration
@ 2013-04-25 11:22 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> It's the way that most other drivers do it.
>
> Very trivial clean-up which reduces line count and simplifies code.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be probe()able when DT is enabled
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
When booting using Device Tree, devices aren't registered in the normal
way. Instead, they need to be provided with a compatible string which is
held in an OF Match Table for comparison during start-up. Here we provide
the compatible string and prepare the driver to not receive a platform
data pointer.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 42 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 6f9f801..4782ee7 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -17,6 +17,7 @@
#include <linux/pm.h>
#include <linux/pm_runtime.h>
#include <linux/err.h>
+#include <linux/of.h>
#include <linux/amba/bus.h>
#include <linux/regulator/consumer.h>
#include <linux/platform_data/dma-ste-dma40.h>
@@ -3452,17 +3453,48 @@ failure:
return ret;
}
+static int __init d40_of_probe(struct platform_device *pdev,
+ struct device_node *np)
+{
+ /*
+ * FIXME: Fill in this routine as more support is added.
+ * First platform enabled (u8500) doens't need any extra
+ * properties to run, so this is fairly sparce currently.
+ */
+ pdev->dev.platform_data =
+ devm_kzalloc(&pdev->dev,
+ sizeof(struct stedma40_platform_data),
+ GFP_KERNEL);
+ if (!pdev->dev.platform_data)
+ return -ENOMEM;
+
+ return 0;
+}
+
static int __init d40_probe(struct platform_device *pdev)
{
+ struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
+ struct device_node *np = pdev->dev.of_node;
int err;
int ret = -ENOENT;
- struct d40_base *base;
+ struct d40_base *base = NULL;
struct resource *res = NULL;
int num_reserved_chans;
u32 val;
- base = d40_hw_detect_init(pdev);
+ if (!plat_data) {
+ if (np) {
+ if(d40_of_probe(pdev, np)) {
+ ret = -ENOMEM;
+ goto failure;
+ }
+ } else {
+ d40_err(&pdev->dev, "No pdata or Device Tree provided\n");
+ goto failure;
+ }
+ }
+ base = d40_hw_detect_init(pdev);
if (!base)
goto failure;
@@ -3636,11 +3668,17 @@ failure:
return ret;
}
+static const struct of_device_id d40_match[] = {
+ { .compatible = "stericsson,dma40", },
+ {}
+};
+
static struct platform_driver d40_driver = {
.driver = {
.owner = THIS_MODULE,
.name = D40_NAME,
.pm = DMA40_PM_OPS,
+ .of_match_table = d40_match,
},
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be probe()able when DT is enabled
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
When booting using Device Tree, devices aren't registered in the normal
way. Instead, they need to be provided with a compatible string which is
held in an OF Match Table for comparison during start-up. Here we provide
the compatible string and prepare the driver to not receive a platform
data pointer.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/dma/ste_dma40.c | 42 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 6f9f801..4782ee7 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -17,6 +17,7 @@
#include <linux/pm.h>
#include <linux/pm_runtime.h>
#include <linux/err.h>
+#include <linux/of.h>
#include <linux/amba/bus.h>
#include <linux/regulator/consumer.h>
#include <linux/platform_data/dma-ste-dma40.h>
@@ -3452,17 +3453,48 @@ failure:
return ret;
}
+static int __init d40_of_probe(struct platform_device *pdev,
+ struct device_node *np)
+{
+ /*
+ * FIXME: Fill in this routine as more support is added.
+ * First platform enabled (u8500) doens't need any extra
+ * properties to run, so this is fairly sparce currently.
+ */
+ pdev->dev.platform_data =
+ devm_kzalloc(&pdev->dev,
+ sizeof(struct stedma40_platform_data),
+ GFP_KERNEL);
+ if (!pdev->dev.platform_data)
+ return -ENOMEM;
+
+ return 0;
+}
+
static int __init d40_probe(struct platform_device *pdev)
{
+ struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
+ struct device_node *np = pdev->dev.of_node;
int err;
int ret = -ENOENT;
- struct d40_base *base;
+ struct d40_base *base = NULL;
struct resource *res = NULL;
int num_reserved_chans;
u32 val;
- base = d40_hw_detect_init(pdev);
+ if (!plat_data) {
+ if (np) {
+ if(d40_of_probe(pdev, np)) {
+ ret = -ENOMEM;
+ goto failure;
+ }
+ } else {
+ d40_err(&pdev->dev, "No pdata or Device Tree provided\n");
+ goto failure;
+ }
+ }
+ base = d40_hw_detect_init(pdev);
if (!base)
goto failure;
@@ -3636,11 +3668,17 @@ failure:
return ret;
}
+static const struct of_device_id d40_match[] = {
+ { .compatible = "stericsson,dma40", },
+ {}
+};
+
static struct platform_driver d40_driver = {
.driver = {
.owner = THIS_MODULE,
.name = D40_NAME,
.pm = DMA40_PM_OPS,
+ .of_match_table = d40_match,
},
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be probe()able when DT is enabled
2013-04-18 10:12 ` Lee Jones
@ 2013-04-18 10:58 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:58 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> When booting using Device Tree, devices aren't registered in the normal
> way. Instead, they need to be provided with a compatible string which is
> held in an OF Match Table for comparison during start-up. Here we provide
> the compatible string and prepare the driver to not receive a platform
> data pointer.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be probe()able when DT is enabled
@ 2013-04-18 10:58 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 10:58 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> When booting using Device Tree, devices aren't registered in the normal
> way. Instead, they need to be provided with a compatible string which is
> held in an OF Match Table for comparison during start-up. Here we provide
> the compatible string and prepare the driver to not receive a platform
> data pointer.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be probe()able when DT is enabled
2013-04-18 10:12 ` Lee Jones
@ 2013-04-22 10:02 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:02 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:12:05AM +0100, Lee Jones wrote:
> When booting using Device Tree, devices aren't registered in the normal
> way. Instead, they need to be provided with a compatible string which is
> held in an OF Match Table for comparison during start-up. Here we provide
> the compatible string and prepare the driver to not receive a platform
> data pointer.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 42 ++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 6f9f801..4782ee7 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -17,6 +17,7 @@
> #include <linux/pm.h>
> #include <linux/pm_runtime.h>
> #include <linux/err.h>
> +#include <linux/of.h>
> #include <linux/amba/bus.h>
> #include <linux/regulator/consumer.h>
> #include <linux/platform_data/dma-ste-dma40.h>
> @@ -3452,17 +3453,48 @@ failure:
> return ret;
> }
>
> +static int __init d40_of_probe(struct platform_device *pdev,
> + struct device_node *np)
> +{
> + /*
> + * FIXME: Fill in this routine as more support is added.
> + * First platform enabled (u8500) doens't need any extra
> + * properties to run, so this is fairly sparce currently.
> + */
> + pdev->dev.platform_data =
> + devm_kzalloc(&pdev->dev,
> + sizeof(struct stedma40_platform_data),
> + GFP_KERNEL);
> + if (!pdev->dev.platform_data)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> static int __init d40_probe(struct platform_device *pdev)
> {
> + struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
> + struct device_node *np = pdev->dev.of_node;
> int err;
> int ret = -ENOENT;
> - struct d40_base *base;
> + struct d40_base *base = NULL;
> struct resource *res = NULL;
> int num_reserved_chans;
> u32 val;
>
> - base = d40_hw_detect_init(pdev);
> + if (!plat_data) {
> + if (np) {
> + if(d40_of_probe(pdev, np)) {
> + ret = -ENOMEM;
> + goto failure;
> + }
> + } else {
> + d40_err(&pdev->dev, "No pdata or Device Tree provided\n");
> + goto failure;
> + }
> + }
>
> + base = d40_hw_detect_init(pdev);
> if (!base)
> goto failure;
>
> @@ -3636,11 +3668,17 @@ failure:
> return ret;
> }
>
> +static const struct of_device_id d40_match[] = {
> + { .compatible = "stericsson,dma40", },
> + {}
> +};
> +
> static struct platform_driver d40_driver = {
> .driver = {
> .owner = THIS_MODULE,
> .name = D40_NAME,
> .pm = DMA40_PM_OPS,
> + .of_match_table = d40_match,
> },
> };
>
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be probe()able when DT is enabled
@ 2013-04-22 10:02 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:02 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:12:05AM +0100, Lee Jones wrote:
> When booting using Device Tree, devices aren't registered in the normal
> way. Instead, they need to be provided with a compatible string which is
> held in an OF Match Table for comparison during start-up. Here we provide
> the compatible string and prepare the driver to not receive a platform
> data pointer.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/ste_dma40.c | 42 ++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 6f9f801..4782ee7 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -17,6 +17,7 @@
> #include <linux/pm.h>
> #include <linux/pm_runtime.h>
> #include <linux/err.h>
> +#include <linux/of.h>
> #include <linux/amba/bus.h>
> #include <linux/regulator/consumer.h>
> #include <linux/platform_data/dma-ste-dma40.h>
> @@ -3452,17 +3453,48 @@ failure:
> return ret;
> }
>
> +static int __init d40_of_probe(struct platform_device *pdev,
> + struct device_node *np)
> +{
> + /*
> + * FIXME: Fill in this routine as more support is added.
> + * First platform enabled (u8500) doens't need any extra
> + * properties to run, so this is fairly sparce currently.
> + */
> + pdev->dev.platform_data =
> + devm_kzalloc(&pdev->dev,
> + sizeof(struct stedma40_platform_data),
> + GFP_KERNEL);
> + if (!pdev->dev.platform_data)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> static int __init d40_probe(struct platform_device *pdev)
> {
> + struct stedma40_platform_data *plat_data = pdev->dev.platform_data;
> + struct device_node *np = pdev->dev.of_node;
> int err;
> int ret = -ENOENT;
> - struct d40_base *base;
> + struct d40_base *base = NULL;
> struct resource *res = NULL;
> int num_reserved_chans;
> u32 val;
>
> - base = d40_hw_detect_init(pdev);
> + if (!plat_data) {
> + if (np) {
> + if(d40_of_probe(pdev, np)) {
> + ret = -ENOMEM;
> + goto failure;
> + }
> + } else {
> + d40_err(&pdev->dev, "No pdata or Device Tree provided\n");
> + goto failure;
> + }
> + }
>
> + base = d40_hw_detect_init(pdev);
> if (!base)
> goto failure;
>
> @@ -3636,11 +3668,17 @@ failure:
> return ret;
> }
>
> +static const struct of_device_id d40_match[] = {
> + { .compatible = "stericsson,dma40", },
> + {}
> +};
> +
> static struct platform_driver d40_driver = {
> .driver = {
> .owner = THIS_MODULE,
> .name = D40_NAME,
> .pm = DMA40_PM_OPS,
> + .of_match_table = d40_match,
> },
> };
>
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be probe()able when DT is enabled
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:24 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:24 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> When booting using Device Tree, devices aren't registered in the normal
> way. Instead, they need to be provided with a compatible string which is
> held in an OF Match Table for comparison during start-up. Here we provide
> the compatible string and prepare the driver to not receive a platform
> data pointer.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 23/32] dmaengine: ste_dma40: Allow driver to be probe()able when DT is enabled
@ 2013-04-25 11:24 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:24 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> When booting using Device Tree, devices aren't registered in the normal
> way. Instead, they need to be provided with a compatible string which is
> held in an OF Match Table for comparison during start-up. Here we provide
> the compatible string and prepare the driver to not receive a platform
> data pointer.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Lee Jones, Vinod Koul, Dan Williams,
Per Forlin, Rabin Vincent
Using the new DMA DT bindings and API, we can register the DMA40 driver
as Device Tree capable. Now, when a client attempts to allocate a
channel using the DMA DT bindings via its own node, we are able to parse
the request and allocate a channel in the correct manor.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
.../devicetree/bindings/dma/ste-dma40.txt | 66 ++++++++++++++++++++
drivers/dma/ste_dma40.c | 58 +++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ste-dma40.txt
diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 0000000..1eb7958
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,66 @@
+* DMA40 DMA Controller
+
+Required properties:
+- compatible: "stericsson,dma40"
+- reg: Address range of the DMAC registers
+- interrupt: Should contain the DMAC interrupt number
+- dma-channels: Number of channels supported by hardware
+- #dma-cells: must be <3>
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+
+Example:
+
+ dma: dma-controller@801C0000 {
+ compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+ reg = <0x801C0000 0x1000>;
+ reg-names = "base";
+ interrupt-parent = <&intc>;
+ interrupts = <0 25 0x4>;
+
+ #dma-cells = <2>;
+ dma-channels = <0>; /* Zero means read from H/W. */
+ };
+
+Clients
+Required properties:
+- dmas: Comma seperated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+ 1. A phandle pointing to the DMA controller
+ 2. The DMA request line number (only when 'use fixed channel' is set)
+ 3. Device Type
+ 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
+ bits 1-2: Mode:
+ 00: Logical
+ 01: Physical
+ 10: Operation
+ 11: Undefined - will most likely return an error
+ bits 3-4: Direction:
+ 00: Mem to Mem
+ 01: Mem to Dev
+ 10: Dev to Mem
+ 11: Dev to Dev
+ bit 5: Endianess:
+ 0: Little endian
+ 1: Big endian
+ bit 6: Use fixed channel:
+ 0: Use automatic channel selection
+ 1: Use DMA request line number
+
+Example:
+
+ uart@80120000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x80120000 0x1000>;
+ interrupts = <0 11 0x4>;
+
+ dmas = <&dma 0 13 0x8>, /* Logical - DevToMem */
+ <&dma 0 13 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "rx";
+
+ status = "disabled";
+ };
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 4782ee7..9115c0e 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -18,6 +18,7 @@
#include <linux/pm_runtime.h>
#include <linux/err.h>
#include <linux/of.h>
+#include <linux/of_dma.h>
#include <linux/amba/bus.h>
#include <linux/regulator/consumer.h>
#include <linux/platform_data/dma-ste-dma40.h>
@@ -2409,6 +2410,56 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
}
+#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x3)
+#define D40_DT_FLAGS_DIR(flags) ((flags >> 2) & 0x3)
+#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 4) & 0x1)
+#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 5) & 0x1)
+
+static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct stedma40_chan_cfg cfg;
+ dma_cap_mask_t cap;
+ u32 flags;
+
+ memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+
+ cfg.dev_type = dma_spec->args[1];
+ flags = dma_spec->args[2];
+
+ switch (D40_DT_FLAGS_MODE(flags)) {
+ case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
+ case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
+ case 2: cfg.mode = STEDMA40_MODE_OPERATION; break;
+ default:
+ pr_err("dma40: Unknown mode read from DT (%d)\n",
+ D40_DT_FLAGS_MODE(flags));
+ return NULL;
+ }
+
+ switch (D40_DT_FLAGS_DIR(flags)) {
+ case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
+ case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
+ case 2: cfg.dir = STEDMA40_PERIPH_TO_MEM; break;
+ case 3: cfg.dir = STEDMA40_PERIPH_TO_PERIPH; break;
+ }
+
+ if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
+ cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+ if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
+ cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+
+ if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
+ cfg.phy_channel = dma_spec->args[0];
+ cfg.use_fixed_channel = true;
+ }
+
+ return dma_request_channel(cap, stedma40_filter, &cfg);
+}
+
/* DMA ENGINE functions */
static int d40_alloc_chan_resources(struct dma_chan *chan)
{
@@ -3615,6 +3666,13 @@ static int __init d40_probe(struct platform_device *pdev)
d40_hw_init(base);
+ if (np) {
+ err = of_dma_controller_register(np, d40_xlate, NULL);
+ if (err && err != -ENODEV)
+ dev_err(&pdev->dev,
+ "could not register of_dma_controller\n");
+ }
+
dev_info(base->dev, "initialized\n");
return 0;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Using the new DMA DT bindings and API, we can register the DMA40 driver
as Device Tree capable. Now, when a client attempts to allocate a
channel using the DMA DT bindings via its own node, we are able to parse
the request and allocate a channel in the correct manor.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
.../devicetree/bindings/dma/ste-dma40.txt | 66 ++++++++++++++++++++
drivers/dma/ste_dma40.c | 58 +++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ste-dma40.txt
diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 0000000..1eb7958
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,66 @@
+* DMA40 DMA Controller
+
+Required properties:
+- compatible: "stericsson,dma40"
+- reg: Address range of the DMAC registers
+- interrupt: Should contain the DMAC interrupt number
+- dma-channels: Number of channels supported by hardware
+- #dma-cells: must be <3>
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+
+Example:
+
+ dma: dma-controller at 801C0000 {
+ compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+ reg = <0x801C0000 0x1000>;
+ reg-names = "base";
+ interrupt-parent = <&intc>;
+ interrupts = <0 25 0x4>;
+
+ #dma-cells = <2>;
+ dma-channels = <0>; /* Zero means read from H/W. */
+ };
+
+Clients
+Required properties:
+- dmas: Comma seperated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+ 1. A phandle pointing to the DMA controller
+ 2. The DMA request line number (only when 'use fixed channel' is set)
+ 3. Device Type
+ 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
+ bits 1-2: Mode:
+ 00: Logical
+ 01: Physical
+ 10: Operation
+ 11: Undefined - will most likely return an error
+ bits 3-4: Direction:
+ 00: Mem to Mem
+ 01: Mem to Dev
+ 10: Dev to Mem
+ 11: Dev to Dev
+ bit 5: Endianess:
+ 0: Little endian
+ 1: Big endian
+ bit 6: Use fixed channel:
+ 0: Use automatic channel selection
+ 1: Use DMA request line number
+
+Example:
+
+ uart at 80120000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x80120000 0x1000>;
+ interrupts = <0 11 0x4>;
+
+ dmas = <&dma 0 13 0x8>, /* Logical - DevToMem */
+ <&dma 0 13 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "rx";
+
+ status = "disabled";
+ };
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 4782ee7..9115c0e 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -18,6 +18,7 @@
#include <linux/pm_runtime.h>
#include <linux/err.h>
#include <linux/of.h>
+#include <linux/of_dma.h>
#include <linux/amba/bus.h>
#include <linux/regulator/consumer.h>
#include <linux/platform_data/dma-ste-dma40.h>
@@ -2409,6 +2410,56 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
}
+#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x3)
+#define D40_DT_FLAGS_DIR(flags) ((flags >> 2) & 0x3)
+#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 4) & 0x1)
+#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 5) & 0x1)
+
+static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct stedma40_chan_cfg cfg;
+ dma_cap_mask_t cap;
+ u32 flags;
+
+ memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+
+ cfg.dev_type = dma_spec->args[1];
+ flags = dma_spec->args[2];
+
+ switch (D40_DT_FLAGS_MODE(flags)) {
+ case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
+ case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
+ case 2: cfg.mode = STEDMA40_MODE_OPERATION; break;
+ default:
+ pr_err("dma40: Unknown mode read from DT (%d)\n",
+ D40_DT_FLAGS_MODE(flags));
+ return NULL;
+ }
+
+ switch (D40_DT_FLAGS_DIR(flags)) {
+ case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
+ case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
+ case 2: cfg.dir = STEDMA40_PERIPH_TO_MEM; break;
+ case 3: cfg.dir = STEDMA40_PERIPH_TO_PERIPH; break;
+ }
+
+ if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
+ cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+ if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
+ cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+
+ if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
+ cfg.phy_channel = dma_spec->args[0];
+ cfg.use_fixed_channel = true;
+ }
+
+ return dma_request_channel(cap, stedma40_filter, &cfg);
+}
+
/* DMA ENGINE functions */
static int d40_alloc_chan_resources(struct dma_chan *chan)
{
@@ -3615,6 +3666,13 @@ static int __init d40_probe(struct platform_device *pdev)
d40_hw_init(base);
+ if (np) {
+ err = of_dma_controller_register(np, d40_xlate, NULL);
+ if (err && err != -ENODEV)
+ dev_err(&pdev->dev,
+ "could not register of_dma_controller\n");
+ }
+
dev_info(base->dev, "initialized\n");
return 0;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 10:12 ` Lee Jones
@ 2013-04-18 11:06 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:06 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manor.
s/manor/manner/ ?
> +Optional properties:
> +- interrupt-parent: Should be the phandle for the interrupt controller
> + that services interrupts for this device
I would not bother listing the interrupt-parent.
> +Clients
> +Required properties:
> +- dmas: Comma seperated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> + 1. A phandle pointing to the DMA controller
> + 2. The DMA request line number (only when 'use fixed channel' is set)
> + 3. Device Type
> + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> + bits 1-2: Mode:
> + 00: Logical
> + 01: Physical
> + 10: Operation
> + 11: Undefined - will most likely return an error
The statement "will most likely return an error" is not very
specification-like. ;-) Maybe better call it "reserved".
What is actually an "Operation" channel? Do we need it for slaves?
> + bits 3-4: Direction:
> + 00: Mem to Mem
> + 01: Mem to Dev
> + 10: Dev to Mem
> + 11: Dev to Dev
For slave channels, we only need mem-to-dev and dev-to-mem, so I would
use only one bit here.
> + bit 5: Endianess:
> + 0: Little endian
> + 1: Big endian
> + bit 6: Use fixed channel:
> + 0: Use automatic channel selection
> + 1: Use DMA request line number
I think you have mixed up the "device type" and "request line number".
The request line is what identifies the slave device (which you call
the device type), and I would put that number first.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 11:06 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:06 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manor.
s/manor/manner/ ?
> +Optional properties:
> +- interrupt-parent: Should be the phandle for the interrupt controller
> + that services interrupts for this device
I would not bother listing the interrupt-parent.
> +Clients
> +Required properties:
> +- dmas: Comma seperated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> + 1. A phandle pointing to the DMA controller
> + 2. The DMA request line number (only when 'use fixed channel' is set)
> + 3. Device Type
> + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> + bits 1-2: Mode:
> + 00: Logical
> + 01: Physical
> + 10: Operation
> + 11: Undefined - will most likely return an error
The statement "will most likely return an error" is not very
specification-like. ;-) Maybe better call it "reserved".
What is actually an "Operation" channel? Do we need it for slaves?
> + bits 3-4: Direction:
> + 00: Mem to Mem
> + 01: Mem to Dev
> + 10: Dev to Mem
> + 11: Dev to Dev
For slave channels, we only need mem-to-dev and dev-to-mem, so I would
use only one bit here.
> + bit 5: Endianess:
> + 0: Little endian
> + 1: Big endian
> + bit 6: Use fixed channel:
> + 0: Use automatic channel selection
> + 1: Use DMA request line number
I think you have mixed up the "device type" and "request line number".
The request line is what identifies the slave device (which you call
the device type), and I would put that number first.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 11:06 ` Arnd Bergmann
@ 2013-04-18 11:31 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 11:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, 18 Apr 2013, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > Using the new DMA DT bindings and API, we can register the DMA40 driver
> > as Device Tree capable. Now, when a client attempts to allocate a
> > channel using the DMA DT bindings via its own node, we are able to parse
> > the request and allocate a channel in the correct manor.
>
> s/manor/manner/ ?
>
> > +Optional properties:
> > +- interrupt-parent: Should be the phandle for the interrupt controller
> > + that services interrupts for this device
>
> I would not bother listing the interrupt-parent.
>
> > +Clients
> > +Required properties:
> > +- dmas: Comma seperated list of dma channel requests
> > +- dma-names: Names of the aforementioned requested channels
> > +
> > +Each dmas request consists of 4 cells:
> > + 1. A phandle pointing to the DMA controller
> > + 2. The DMA request line number (only when 'use fixed channel' is set)
> > + 3. Device Type
> > + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> > + bits 1-2: Mode:
> > + 00: Logical
> > + 01: Physical
> > + 10: Operation
> > + 11: Undefined - will most likely return an error
>
> The statement "will most likely return an error" is not very
> specification-like. ;-) Maybe better call it "reserved".
Actually, I wrote this before I wrote the code.
It definitely does return an error. :)
I'll fixup as you requested anyway.
> What is actually an "Operation" channel? Do we need it for slaves?
No idea. It was in the header file, so I thought I'd better reserve a
bit for it early in case it comes in handy later.
> > + bits 3-4: Direction:
> > + 00: Mem to Mem
> > + 01: Mem to Dev
> > + 10: Dev to Mem
> > + 11: Dev to Dev
>
> For slave channels, we only need mem-to-dev and dev-to-mem, so I would
> use only one bit here.
Okay.
> > + bit 5: Endianess:
> > + 0: Little endian
> > + 1: Big endian
> > + bit 6: Use fixed channel:
> > + 0: Use automatic channel selection
> > + 1: Use DMA request line number
>
> I think you have mixed up the "device type" and "request line number".
>
> The request line is what identifies the slave device (which you call
> the device type)
You're right, I am a little confused by them.
I call them 'device type' because that's what they're called already.
Grep for 'dma_dev_type'. This is the number which gets split into
event group and line, like this:
event_group = D40_TYPE_TO_GROUP(dev_type);
event_line = D40_TYPE_TO_EVENT(dev_type);
> and I would put that number first.
So you want me to switch that round so it looks like:
dmas = <<phandle> <dev_type> <fixed_chan> <flags>;
Instead of what I have at the moment:
dmas = <<phandle> <fixed_chan> <dev_type> <flags>;
Correct?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 11:31 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 11:31 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 18 Apr 2013, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > Using the new DMA DT bindings and API, we can register the DMA40 driver
> > as Device Tree capable. Now, when a client attempts to allocate a
> > channel using the DMA DT bindings via its own node, we are able to parse
> > the request and allocate a channel in the correct manor.
>
> s/manor/manner/ ?
>
> > +Optional properties:
> > +- interrupt-parent: Should be the phandle for the interrupt controller
> > + that services interrupts for this device
>
> I would not bother listing the interrupt-parent.
>
> > +Clients
> > +Required properties:
> > +- dmas: Comma seperated list of dma channel requests
> > +- dma-names: Names of the aforementioned requested channels
> > +
> > +Each dmas request consists of 4 cells:
> > + 1. A phandle pointing to the DMA controller
> > + 2. The DMA request line number (only when 'use fixed channel' is set)
> > + 3. Device Type
> > + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> > + bits 1-2: Mode:
> > + 00: Logical
> > + 01: Physical
> > + 10: Operation
> > + 11: Undefined - will most likely return an error
>
> The statement "will most likely return an error" is not very
> specification-like. ;-) Maybe better call it "reserved".
Actually, I wrote this before I wrote the code.
It definitely does return an error. :)
I'll fixup as you requested anyway.
> What is actually an "Operation" channel? Do we need it for slaves?
No idea. It was in the header file, so I thought I'd better reserve a
bit for it early in case it comes in handy later.
> > + bits 3-4: Direction:
> > + 00: Mem to Mem
> > + 01: Mem to Dev
> > + 10: Dev to Mem
> > + 11: Dev to Dev
>
> For slave channels, we only need mem-to-dev and dev-to-mem, so I would
> use only one bit here.
Okay.
> > + bit 5: Endianess:
> > + 0: Little endian
> > + 1: Big endian
> > + bit 6: Use fixed channel:
> > + 0: Use automatic channel selection
> > + 1: Use DMA request line number
>
> I think you have mixed up the "device type" and "request line number".
>
> The request line is what identifies the slave device (which you call
> the device type)
You're right, I am a little confused by them.
I call them 'device type' because that's what they're called already.
Grep for 'dma_dev_type'. This is the number which gets split into
event group and line, like this:
event_group = D40_TYPE_TO_GROUP(dev_type);
event_line = D40_TYPE_TO_EVENT(dev_type);
> and I would put that number first.
So you want me to switch that round so it looks like:
dmas = <<phandle> <dev_type> <fixed_chan> <flags>;
Instead of what I have at the moment:
dmas = <<phandle> <fixed_chan> <dev_type> <flags>;
Correct?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 11:31 ` Lee Jones
@ 2013-04-18 11:37 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:37 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> You're right, I am a little confused by them.
>
> I call them 'device type' because that's what they're called already.
> Grep for 'dma_dev_type'. This is the number which gets split into
> event group and line, like this:
>
> event_group = D40_TYPE_TO_GROUP(dev_type);
> event_line = D40_TYPE_TO_EVENT(dev_type);
>
> > and I would put that number first.
>
> So you want me to switch that round so it looks like:
>
> dmas = <<phandle> <dev_type> <fixed_chan> <flags>;
>
> Instead of what I have at the moment:
>
> dmas = <<phandle> <fixed_chan> <dev_type> <flags>;
>
> Correct?
Yes, that's probably better and more in line with what the other
drivers do. You could also put the fixed_chan last if that helps.
I would still like to get a confirmation that we actually still
require the fixed channel assignment, since it's just used
in one driver, and that might only be needed for some buggy
hardware revision if we're lucky.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 11:37 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:37 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> You're right, I am a little confused by them.
>
> I call them 'device type' because that's what they're called already.
> Grep for 'dma_dev_type'. This is the number which gets split into
> event group and line, like this:
>
> event_group = D40_TYPE_TO_GROUP(dev_type);
> event_line = D40_TYPE_TO_EVENT(dev_type);
>
> > and I would put that number first.
>
> So you want me to switch that round so it looks like:
>
> dmas = <<phandle> <dev_type> <fixed_chan> <flags>;
>
> Instead of what I have at the moment:
>
> dmas = <<phandle> <fixed_chan> <dev_type> <flags>;
>
> Correct?
Yes, that's probably better and more in line with what the other
drivers do. You could also put the fixed_chan last if that helps.
I would still like to get a confirmation that we actually still
require the fixed channel assignment, since it's just used
in one driver, and that might only be needed for some buggy
hardware revision if we're lucky.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 11:37 ` Arnd Bergmann
@ 2013-04-18 11:47 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 11:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, 18 Apr 2013, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > You're right, I am a little confused by them.
> >
> > I call them 'device type' because that's what they're called already.
> > Grep for 'dma_dev_type'. This is the number which gets split into
> > event group and line, like this:
> >
> > event_group = D40_TYPE_TO_GROUP(dev_type);
> > event_line = D40_TYPE_TO_EVENT(dev_type);
> >
> > > and I would put that number first.
> >
> > So you want me to switch that round so it looks like:
> >
> > dmas = <<phandle> <dev_type> <fixed_chan> <flags>;
> >
> > Instead of what I have at the moment:
> >
> > dmas = <<phandle> <fixed_chan> <dev_type> <flags>;
> >
> > Correct?
>
> Yes, that's probably better and more in line with what the other
> drivers do. You could also put the fixed_chan last if that helps.
I'd rather keep the flags as the final cell if it's all the same to you?
> I would still like to get a confirmation that we actually still
> require the fixed channel assignment, since it's just used
> in one driver, and that might only be needed for some buggy
> hardware revision if we're lucky.
Unfortunately not:
`git grep "\.use_fixed_channel" <internal_kernel> | grep true | wc -l`
8
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 11:47 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 11:47 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 18 Apr 2013, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > You're right, I am a little confused by them.
> >
> > I call them 'device type' because that's what they're called already.
> > Grep for 'dma_dev_type'. This is the number which gets split into
> > event group and line, like this:
> >
> > event_group = D40_TYPE_TO_GROUP(dev_type);
> > event_line = D40_TYPE_TO_EVENT(dev_type);
> >
> > > and I would put that number first.
> >
> > So you want me to switch that round so it looks like:
> >
> > dmas = <<phandle> <dev_type> <fixed_chan> <flags>;
> >
> > Instead of what I have at the moment:
> >
> > dmas = <<phandle> <fixed_chan> <dev_type> <flags>;
> >
> > Correct?
>
> Yes, that's probably better and more in line with what the other
> drivers do. You could also put the fixed_chan last if that helps.
I'd rather keep the flags as the final cell if it's all the same to you?
> I would still like to get a confirmation that we actually still
> require the fixed channel assignment, since it's just used
> in one driver, and that might only be needed for some buggy
> hardware revision if we're lucky.
Unfortunately not:
`git grep "\.use_fixed_channel" <internal_kernel> | grep true | wc -l`
8
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 11:47 ` Lee Jones
@ 2013-04-18 12:23 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 12:23 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> > Yes, that's probably better and more in line with what the other
> > drivers do. You could also put the fixed_chan last if that helps.
>
> I'd rather keep the flags as the final cell if it's all the same to you?
Ok, no problem.
> > I would still like to get a confirmation that we actually still
> > require the fixed channel assignment, since it's just used
> > in one driver, and that might only be needed for some buggy
> > hardware revision if we're lucky.
>
> Unfortunately not:
>
> `git grep "\.use_fixed_channel" <internal_kernel> | grep true | wc -l`
> 8
I see.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 12:23 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 12:23 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> > Yes, that's probably better and more in line with what the other
> > drivers do. You could also put the fixed_chan last if that helps.
>
> I'd rather keep the flags as the final cell if it's all the same to you?
Ok, no problem.
> > I would still like to get a confirmation that we actually still
> > require the fixed channel assignment, since it's just used
> > in one driver, and that might only be needed for some buggy
> > hardware revision if we're lucky.
>
> Unfortunately not:
>
> `git grep "\.use_fixed_channel" <internal_kernel> | grep true | wc -l`
> 8
I see.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 10:12 ` Lee Jones
@ 2013-04-18 11:07 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:07 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> + dma-channels = <0>; /* Zero means read from H/W. */
One more thing: I would not make this a magic value. Better make the property
optional and require it to be correct if present and autodetected if absent.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 11:07 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:07 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> + dma-channels = <0>; /* Zero means read from H/W. */
One more thing: I would not make this a magic value. Better make the property
optional and require it to be correct if present and autodetected if absent.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 10:12 ` Lee Jones
@ 2013-04-18 12:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 12:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
Using the new DMA DT bindings and API, we can register the DMA40 driver
as Device Tree capable. Now, when a client attempts to allocate a
channel using the DMA DT bindings via its own node, we are able to parse
the request and allocate a channel in the correct manner.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 0000000..0aca55f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,62 @@
+* DMA40 DMA Controller
+
+Required properties:
+- compatible: "stericsson,dma40"
+- reg: Address range of the DMAC registers
+- reg-names: Names of the above areas to use during resource look-up
+- interrupt: Should contain the DMAC interrupt number
+- #dma-cells: must be <3>
+
+Optional properties:
+- dma-channels: Number of channels supported by hardware - if not present
+ the driver will attempt to obtain the information from H/W
+
+Example:
+
+ dma: dma-controller@801C0000 {
+ compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+ reg = <0x801C0000 0x1000 0x40010000 0x800>;
+ reg-names = "base", "lcpa";
+ interrupt-parent = <&intc>;
+ interrupts = <0 25 0x4>;
+
+ #dma-cells = <2>;
+ dma-channels = <8>;
+ };
+
+Clients
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+ 1. A phandle pointing to the DMA controller
+ 2. Device Type
+ 3. The DMA request line number (only when 'use fixed channel' is set)
+ 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
+ bit 1: Mode:
+ 0: Logical
+ 1: Physical
+ bit 2: Direction:
+ 0: Mem to Mem
+ 1: Mem to Dev
+ bit 3: Endianess:
+ 0: Little endian
+ 1: Big endian
+ bit 4: Use fixed channel:
+ 0: Use automatic channel selection
+ 1: Use DMA request line number
+
+Example:
+
+ uart@80120000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x80120000 0x1000>;
+ interrupts = <0 11 0x4>;
+
+ dmas = <&dma 13 0 0x8>, /* Logical - DevToMem */
+ <&dma 13 0 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "rx";
+
+ status = "disabled";
+ };
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index c70660d..f551b27 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -18,6 +18,7 @@
#include <linux/pm_runtime.h>
#include <linux/err.h>
#include <linux/of.h>
+#include <linux/of_dma.h>
#include <linux/amba/bus.h>
#include <linux/regulator/consumer.h>
#include <linux/platform_data/dma-ste-dma40.h>
@@ -2409,6 +2410,53 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
}
+#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x1)
+#define D40_DT_FLAGS_DIR(flags) ((flags >> 1) & 0x1)
+#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
+#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
+
+static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct stedma40_chan_cfg cfg;
+ dma_cap_mask_t cap;
+ u32 flags;
+
+ memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+
+ cfg.dev_type = dma_spec->args[0];
+ flags = dma_spec->args[2];
+
+ switch (D40_DT_FLAGS_MODE(flags)) {
+ case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
+ case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
+ default:
+ pr_err("dma40: Unknown mode read from DT (%d)\n",
+ D40_DT_FLAGS_MODE(flags));
+ return NULL;
+ }
+
+ switch (D40_DT_FLAGS_DIR(flags)) {
+ case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
+ case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
+ }
+
+ if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
+ cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+ if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
+ cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+
+ if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
+ cfg.phy_channel = dma_spec->args[1];
+ cfg.use_fixed_channel = true;
+ }
+
+ return dma_request_channel(cap, stedma40_filter, &cfg);
+}
+
/* DMA ENGINE functions */
static int d40_alloc_chan_resources(struct dma_chan *chan)
{
@@ -3615,6 +3663,13 @@ static int __init d40_probe(struct platform_device *pdev)
d40_hw_init(base);
+ if (np) {
+ err = of_dma_controller_register(np, d40_xlate, NULL);
+ if (err && err != -ENODEV)
+ dev_err(&pdev->dev,
+ "could not register of_dma_controller\n");
+ }
+
dev_info(base->dev, "initialized\n");
return 0;
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 12:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 12:12 UTC (permalink / raw)
To: linux-arm-kernel
Using the new DMA DT bindings and API, we can register the DMA40 driver
as Device Tree capable. Now, when a client attempts to allocate a
channel using the DMA DT bindings via its own node, we are able to parse
the request and allocate a channel in the correct manner.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 0000000..0aca55f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,62 @@
+* DMA40 DMA Controller
+
+Required properties:
+- compatible: "stericsson,dma40"
+- reg: Address range of the DMAC registers
+- reg-names: Names of the above areas to use during resource look-up
+- interrupt: Should contain the DMAC interrupt number
+- #dma-cells: must be <3>
+
+Optional properties:
+- dma-channels: Number of channels supported by hardware - if not present
+ the driver will attempt to obtain the information from H/W
+
+Example:
+
+ dma: dma-controller at 801C0000 {
+ compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+ reg = <0x801C0000 0x1000 0x40010000 0x800>;
+ reg-names = "base", "lcpa";
+ interrupt-parent = <&intc>;
+ interrupts = <0 25 0x4>;
+
+ #dma-cells = <2>;
+ dma-channels = <8>;
+ };
+
+Clients
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+ 1. A phandle pointing to the DMA controller
+ 2. Device Type
+ 3. The DMA request line number (only when 'use fixed channel' is set)
+ 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
+ bit 1: Mode:
+ 0: Logical
+ 1: Physical
+ bit 2: Direction:
+ 0: Mem to Mem
+ 1: Mem to Dev
+ bit 3: Endianess:
+ 0: Little endian
+ 1: Big endian
+ bit 4: Use fixed channel:
+ 0: Use automatic channel selection
+ 1: Use DMA request line number
+
+Example:
+
+ uart at 80120000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x80120000 0x1000>;
+ interrupts = <0 11 0x4>;
+
+ dmas = <&dma 13 0 0x8>, /* Logical - DevToMem */
+ <&dma 13 0 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "rx";
+
+ status = "disabled";
+ };
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index c70660d..f551b27 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -18,6 +18,7 @@
#include <linux/pm_runtime.h>
#include <linux/err.h>
#include <linux/of.h>
+#include <linux/of_dma.h>
#include <linux/amba/bus.h>
#include <linux/regulator/consumer.h>
#include <linux/platform_data/dma-ste-dma40.h>
@@ -2409,6 +2410,53 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
}
+#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x1)
+#define D40_DT_FLAGS_DIR(flags) ((flags >> 1) & 0x1)
+#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
+#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
+
+static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct stedma40_chan_cfg cfg;
+ dma_cap_mask_t cap;
+ u32 flags;
+
+ memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+
+ cfg.dev_type = dma_spec->args[0];
+ flags = dma_spec->args[2];
+
+ switch (D40_DT_FLAGS_MODE(flags)) {
+ case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
+ case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
+ default:
+ pr_err("dma40: Unknown mode read from DT (%d)\n",
+ D40_DT_FLAGS_MODE(flags));
+ return NULL;
+ }
+
+ switch (D40_DT_FLAGS_DIR(flags)) {
+ case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
+ case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
+ }
+
+ if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
+ cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+ if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
+ cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+
+ if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
+ cfg.phy_channel = dma_spec->args[1];
+ cfg.use_fixed_channel = true;
+ }
+
+ return dma_request_channel(cap, stedma40_filter, &cfg);
+}
+
/* DMA ENGINE functions */
static int d40_alloc_chan_resources(struct dma_chan *chan)
{
@@ -3615,6 +3663,13 @@ static int __init d40_probe(struct platform_device *pdev)
d40_hw_init(base);
+ if (np) {
+ err = of_dma_controller_register(np, d40_xlate, NULL);
+ if (err && err != -ENODEV)
+ dev_err(&pdev->dev,
+ "could not register of_dma_controller\n");
+ }
+
dev_info(base->dev, "initialized\n");
return 0;
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 12:12 ` Lee Jones
@ 2013-04-18 12:32 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 12:32 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> +Clients
> +Required properties:
> +- dmas: Comma separated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> + 1. A phandle pointing to the DMA controller
> + 2. Device Type
> + 3. The DMA request line number (only when 'use fixed channel' is set)
> + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> + bit 1: Mode:
> + 0: Logical
> + 1: Physical
> + bit 2: Direction:
> + 0: Mem to Mem
> + 1: Mem to Dev
You probably mean
0: Dev to mem
Related to this, I would recommend not listing bit numbers like this, since there
is some amount of confusion regarding how they are counted: zero-based on one-based
and LSB-to-MSB or MSB-to-LSB
You can completely avoid this problem by listing them as bit masks:
0x00000002:
Logical channel when unset
Physical channel when set
0x00000004:
Direction from device when unset
Direction to device when unset
...
> + dmas = <&dma 13 0 0x8>, /* Logical - DevToMem */
> + <&dma 13 0 0x4>; /* Logical - MemToDev */
The bit in the example no longer matches the description.
> +
> + switch (D40_DT_FLAGS_DIR(flags)) {
> + case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
> + case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
> + }
Same typo above.
> + if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
> + cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
> + cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
You can fold these two into the switch statement above.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 12:32 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 12:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> +Clients
> +Required properties:
> +- dmas: Comma separated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> + 1. A phandle pointing to the DMA controller
> + 2. Device Type
> + 3. The DMA request line number (only when 'use fixed channel' is set)
> + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> + bit 1: Mode:
> + 0: Logical
> + 1: Physical
> + bit 2: Direction:
> + 0: Mem to Mem
> + 1: Mem to Dev
You probably mean
0: Dev to mem
Related to this, I would recommend not listing bit numbers like this, since there
is some amount of confusion regarding how they are counted: zero-based on one-based
and LSB-to-MSB or MSB-to-LSB
You can completely avoid this problem by listing them as bit masks:
0x00000002:
Logical channel when unset
Physical channel when set
0x00000004:
Direction from device when unset
Direction to device when unset
...
> + dmas = <&dma 13 0 0x8>, /* Logical - DevToMem */
> + <&dma 13 0 0x4>; /* Logical - MemToDev */
The bit in the example no longer matches the description.
> +
> + switch (D40_DT_FLAGS_DIR(flags)) {
> + case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
> + case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
> + }
Same typo above.
> + if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
> + cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
> + cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
You can fold these two into the switch statement above.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 12:32 ` Arnd Bergmann
@ 2013-04-18 13:43 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 13:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, 18 Apr 2013, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > +Clients
> > +Required properties:
> > +- dmas: Comma separated list of dma channel requests
> > +- dma-names: Names of the aforementioned requested channels
> > +
> > +Each dmas request consists of 4 cells:
> > + 1. A phandle pointing to the DMA controller
> > + 2. Device Type
> > + 3. The DMA request line number (only when 'use fixed channel' is set)
> > + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> > + bit 1: Mode:
> > + 0: Logical
> > + 1: Physical
> > + bit 2: Direction:
> > + 0: Mem to Mem
> > + 1: Mem to Dev
>
> You probably mean
>
> 0: Dev to mem
>
> Related to this, I would recommend not listing bit numbers like this, since there
> is some amount of confusion regarding how they are counted: zero-based on one-based
> and LSB-to-MSB or MSB-to-LSB
>
> You can completely avoid this problem by listing them as bit masks:
>
> 0x00000002:
> Logical channel when unset
> Physical channel when set
> 0x00000004:
> Direction from device when unset
> Direction to device when unset
> ...
>
> > + dmas = <&dma 13 0 0x8>, /* Logical - DevToMem */
> > + <&dma 13 0 0x4>; /* Logical - MemToDev */
>
> The bit in the example no longer matches the description.
>
> > +
> > + switch (D40_DT_FLAGS_DIR(flags)) {
> > + case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
> > + case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
> > + }
>
> Same typo above.
>
> > + if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
> > + cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> > + if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
> > + cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
>
> You can fold these two into the switch statement above.
This is what happens when you rush a fixup. :)
I'll do it properly now.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 13:43 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 13:43 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 18 Apr 2013, Arnd Bergmann wrote:
> On Thursday 18 April 2013, Lee Jones wrote:
> > +Clients
> > +Required properties:
> > +- dmas: Comma separated list of dma channel requests
> > +- dma-names: Names of the aforementioned requested channels
> > +
> > +Each dmas request consists of 4 cells:
> > + 1. A phandle pointing to the DMA controller
> > + 2. Device Type
> > + 3. The DMA request line number (only when 'use fixed channel' is set)
> > + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> > + bit 1: Mode:
> > + 0: Logical
> > + 1: Physical
> > + bit 2: Direction:
> > + 0: Mem to Mem
> > + 1: Mem to Dev
>
> You probably mean
>
> 0: Dev to mem
>
> Related to this, I would recommend not listing bit numbers like this, since there
> is some amount of confusion regarding how they are counted: zero-based on one-based
> and LSB-to-MSB or MSB-to-LSB
>
> You can completely avoid this problem by listing them as bit masks:
>
> 0x00000002:
> Logical channel when unset
> Physical channel when set
> 0x00000004:
> Direction from device when unset
> Direction to device when unset
> ...
>
> > + dmas = <&dma 13 0 0x8>, /* Logical - DevToMem */
> > + <&dma 13 0 0x4>; /* Logical - MemToDev */
>
> The bit in the example no longer matches the description.
>
> > +
> > + switch (D40_DT_FLAGS_DIR(flags)) {
> > + case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
> > + case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
> > + }
>
> Same typo above.
>
> > + if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
> > + cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> > + if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
> > + cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
>
> You can fold these two into the switch statement above.
This is what happens when you rush a fixup. :)
I'll do it properly now.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 12:12 ` Lee Jones
@ 2013-04-18 14:17 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 14:17 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent
Using the new DMA DT bindings and API, we can register the DMA40 driver
as Device Tree capable. Now, when a client attempts to allocate a
channel using the DMA DT bindings via its own node, we are able to parse
the request and allocate a channel in the correct manner.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 0000000..2679a87
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,62 @@
+* DMA40 DMA Controller
+
+Required properties:
+- compatible: "stericsson,dma40"
+- reg: Address range of the DMAC registers
+- reg-names: Names of the above areas to use during resource look-up
+- interrupt: Should contain the DMAC interrupt number
+- #dma-cells: must be <3>
+
+Optional properties:
+- dma-channels: Number of channels supported by hardware - if not present
+ the driver will attempt to obtain the information from H/W
+
+Example:
+
+ dma: dma-controller@801C0000 {
+ compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+ reg = <0x801C0000 0x1000 0x40010000 0x800>;
+ reg-names = "base", "lcpa";
+ interrupt-parent = <&intc>;
+ interrupts = <0 25 0x4>;
+
+ #dma-cells = <2>;
+ dma-channels = <8>;
+ };
+
+Clients
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+ 1. A phandle pointing to the DMA controller
+ 2. Device Type
+ 3. The DMA request line number (only when 'use fixed channel' is set)
+ 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
+ 0x00000001: Mode:
+ Logical channel when unset
+ Physical channel when set
+ 0x00000002: Direction:
+ Memory to Device when unset
+ Device to Memory when set
+ 0x00000004: Endianess:
+ Little endian when unset
+ Big endian when set
+ 0x00000008: Use fixed channel:
+ Use automatic channel selection when unset
+ Use DMA request line number when set
+
+Example:
+
+ uart@80120000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x80120000 0x1000>;
+ interrupts = <0 11 0x4>;
+
+ dmas = <&dma 13 0 0x2>, /* Logical - DevToMem */
+ <&dma 13 0 0x0>; /* Logical - MemToDev */
+ dma-names = "rx", "rx";
+
+ status = "disabled";
+ };
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index bad8753..94d0edb 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -18,6 +18,7 @@
#include <linux/pm_runtime.h>
#include <linux/err.h>
#include <linux/of.h>
+#include <linux/of_dma.h>
#include <linux/amba/bus.h>
#include <linux/regulator/consumer.h>
#include <linux/platform_data/dma-ste-dma40.h>
@@ -2409,6 +2410,50 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
}
+#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x1)
+#define D40_DT_FLAGS_DIR(flags) ((flags >> 1) & 0x1)
+#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
+#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
+
+static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct stedma40_chan_cfg cfg;
+ dma_cap_mask_t cap;
+ u32 flags;
+
+ memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+
+ cfg.dev_type = dma_spec->args[0];
+ flags = dma_spec->args[2];
+
+ switch (D40_DT_FLAGS_MODE(flags)) {
+ case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
+ case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
+ }
+
+ switch (D40_DT_FLAGS_DIR(flags)) {
+ case 0:
+ cfg.dir = STEDMA40_MEM_TO_PERIPH;
+ cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+ break;
+ case 1:
+ cfg.dir = STEDMA40_PERIPH_TO_MEM;
+ cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+ break;
+ }
+
+ if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
+ cfg.phy_channel = dma_spec->args[1];
+ cfg.use_fixed_channel = true;
+ }
+
+ return dma_request_channel(cap, stedma40_filter, &cfg);
+}
+
/* DMA ENGINE functions */
static int d40_alloc_chan_resources(struct dma_chan *chan)
{
@@ -3615,6 +3660,13 @@ static int __init d40_probe(struct platform_device *pdev)
d40_hw_init(base);
+ if (np) {
+ err = of_dma_controller_register(np, d40_xlate, NULL);
+ if (err && err != -ENODEV)
+ dev_err(&pdev->dev,
+ "could not register of_dma_controller\n");
+ }
+
dev_info(base->dev, "initialized\n");
return 0;
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 14:17 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 14:17 UTC (permalink / raw)
To: linux-arm-kernel
Using the new DMA DT bindings and API, we can register the DMA40 driver
as Device Tree capable. Now, when a client attempts to allocate a
channel using the DMA DT bindings via its own node, we are able to parse
the request and allocate a channel in the correct manner.
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Per Forlin <per.forlin@stericsson.com>
Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 0000000..2679a87
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,62 @@
+* DMA40 DMA Controller
+
+Required properties:
+- compatible: "stericsson,dma40"
+- reg: Address range of the DMAC registers
+- reg-names: Names of the above areas to use during resource look-up
+- interrupt: Should contain the DMAC interrupt number
+- #dma-cells: must be <3>
+
+Optional properties:
+- dma-channels: Number of channels supported by hardware - if not present
+ the driver will attempt to obtain the information from H/W
+
+Example:
+
+ dma: dma-controller at 801C0000 {
+ compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+ reg = <0x801C0000 0x1000 0x40010000 0x800>;
+ reg-names = "base", "lcpa";
+ interrupt-parent = <&intc>;
+ interrupts = <0 25 0x4>;
+
+ #dma-cells = <2>;
+ dma-channels = <8>;
+ };
+
+Clients
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+ 1. A phandle pointing to the DMA controller
+ 2. Device Type
+ 3. The DMA request line number (only when 'use fixed channel' is set)
+ 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
+ 0x00000001: Mode:
+ Logical channel when unset
+ Physical channel when set
+ 0x00000002: Direction:
+ Memory to Device when unset
+ Device to Memory when set
+ 0x00000004: Endianess:
+ Little endian when unset
+ Big endian when set
+ 0x00000008: Use fixed channel:
+ Use automatic channel selection when unset
+ Use DMA request line number when set
+
+Example:
+
+ uart at 80120000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x80120000 0x1000>;
+ interrupts = <0 11 0x4>;
+
+ dmas = <&dma 13 0 0x2>, /* Logical - DevToMem */
+ <&dma 13 0 0x0>; /* Logical - MemToDev */
+ dma-names = "rx", "rx";
+
+ status = "disabled";
+ };
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index bad8753..94d0edb 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -18,6 +18,7 @@
#include <linux/pm_runtime.h>
#include <linux/err.h>
#include <linux/of.h>
+#include <linux/of_dma.h>
#include <linux/amba/bus.h>
#include <linux/regulator/consumer.h>
#include <linux/platform_data/dma-ste-dma40.h>
@@ -2409,6 +2410,50 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
__d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
}
+#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x1)
+#define D40_DT_FLAGS_DIR(flags) ((flags >> 1) & 0x1)
+#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
+#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
+
+static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct stedma40_chan_cfg cfg;
+ dma_cap_mask_t cap;
+ u32 flags;
+
+ memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+
+ cfg.dev_type = dma_spec->args[0];
+ flags = dma_spec->args[2];
+
+ switch (D40_DT_FLAGS_MODE(flags)) {
+ case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
+ case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
+ }
+
+ switch (D40_DT_FLAGS_DIR(flags)) {
+ case 0:
+ cfg.dir = STEDMA40_MEM_TO_PERIPH;
+ cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+ break;
+ case 1:
+ cfg.dir = STEDMA40_PERIPH_TO_MEM;
+ cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
+ break;
+ }
+
+ if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
+ cfg.phy_channel = dma_spec->args[1];
+ cfg.use_fixed_channel = true;
+ }
+
+ return dma_request_channel(cap, stedma40_filter, &cfg);
+}
+
/* DMA ENGINE functions */
static int d40_alloc_chan_resources(struct dma_chan *chan)
{
@@ -3615,6 +3660,13 @@ static int __init d40_probe(struct platform_device *pdev)
d40_hw_init(base);
+ if (np) {
+ err = of_dma_controller_register(np, d40_xlate, NULL);
+ if (err && err != -ENODEV)
+ dev_err(&pdev->dev,
+ "could not register of_dma_controller\n");
+ }
+
dev_info(base->dev, "initialized\n");
return 0;
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 14:17 ` Lee Jones
@ 2013-04-18 21:53 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 21:53 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, linus.walleij, Vinod Koul,
Dan Williams, Per Forlin, Rabin Vincent
On Thursday 18 April 2013, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-18 21:53 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 21:53 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 14:17 ` Lee Jones
@ 2013-04-22 10:18 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:18 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 03:17:52PM +0100, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Okay read vN if there is one, before replying!
so..
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
>
> diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> new file mode 100644
> index 0000000..2679a87
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> @@ -0,0 +1,62 @@
> +* DMA40 DMA Controller
> +
> +Required properties:
> +- compatible: "stericsson,dma40"
> +- reg: Address range of the DMAC registers
> +- reg-names: Names of the above areas to use during resource look-up
> +- interrupt: Should contain the DMAC interrupt number
> +- #dma-cells: must be <3>
> +
> +Optional properties:
> +- dma-channels: Number of channels supported by hardware - if not present
> + the driver will attempt to obtain the information from H/W
> +
> +Example:
> +
> + dma: dma-controller@801C0000 {
> + compatible = "stericsson,db8500-dma40", "stericsson,dma40";
> + reg = <0x801C0000 0x1000 0x40010000 0x800>;
> + reg-names = "base", "lcpa";
> + interrupt-parent = <&intc>;
> + interrupts = <0 25 0x4>;
> +
> + #dma-cells = <2>;
> + dma-channels = <8>;
> + };
> +
> +Clients
> +Required properties:
> +- dmas: Comma separated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> + 1. A phandle pointing to the DMA controller
> + 2. Device Type
> + 3. The DMA request line number (only when 'use fixed channel' is set)
> + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> + 0x00000001: Mode:
> + Logical channel when unset
> + Physical channel when set
> + 0x00000002: Direction:
> + Memory to Device when unset
> + Device to Memory when set
> + 0x00000004: Endianess:
> + Little endian when unset
> + Big endian when set
> + 0x00000008: Use fixed channel:
> + Use automatic channel selection when unset
> + Use DMA request line number when set
> +
> +Example:
> +
> + uart@80120000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x80120000 0x1000>;
> + interrupts = <0 11 0x4>;
> +
> + dmas = <&dma 13 0 0x2>, /* Logical - DevToMem */
> + <&dma 13 0 0x0>; /* Logical - MemToDev */
> + dma-names = "rx", "rx";
> +
> + status = "disabled";
> + };
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index bad8753..94d0edb 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -18,6 +18,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/err.h>
> #include <linux/of.h>
> +#include <linux/of_dma.h>
> #include <linux/amba/bus.h>
> #include <linux/regulator/consumer.h>
> #include <linux/platform_data/dma-ste-dma40.h>
> @@ -2409,6 +2410,50 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
> __d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
> }
>
> +#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x1)
> +#define D40_DT_FLAGS_DIR(flags) ((flags >> 1) & 0x1)
> +#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
> +#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
> +
> +static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct stedma40_chan_cfg cfg;
> + dma_cap_mask_t cap;
> + u32 flags;
> +
> + memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
> +
> + dma_cap_zero(cap);
> + dma_cap_set(DMA_SLAVE, cap);
> +
> + cfg.dev_type = dma_spec->args[0];
> + flags = dma_spec->args[2];
> +
> + switch (D40_DT_FLAGS_MODE(flags)) {
> + case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> + case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
> + }
> +
> + switch (D40_DT_FLAGS_DIR(flags)) {
> + case 0:
> + cfg.dir = STEDMA40_MEM_TO_PERIPH;
> + cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + break;
> + case 1:
> + cfg.dir = STEDMA40_PERIPH_TO_MEM;
> + cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + break;
> + }
> +
> + if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
> + cfg.phy_channel = dma_spec->args[1];
> + cfg.use_fixed_channel = true;
> + }
> +
> + return dma_request_channel(cap, stedma40_filter, &cfg);
> +}
> +
> /* DMA ENGINE functions */
> static int d40_alloc_chan_resources(struct dma_chan *chan)
> {
> @@ -3615,6 +3660,13 @@ static int __init d40_probe(struct platform_device *pdev)
>
> d40_hw_init(base);
>
> + if (np) {
> + err = of_dma_controller_register(np, d40_xlate, NULL);
> + if (err && err != -ENODEV)
> + dev_err(&pdev->dev,
> + "could not register of_dma_controller\n");
> + }
> +
> dev_info(base->dev, "initialized\n");
> return 0;
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-22 10:18 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:18 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 03:17:52PM +0100, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Okay read vN if there is one, before replying!
so..
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
>
> diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> new file mode 100644
> index 0000000..2679a87
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> @@ -0,0 +1,62 @@
> +* DMA40 DMA Controller
> +
> +Required properties:
> +- compatible: "stericsson,dma40"
> +- reg: Address range of the DMAC registers
> +- reg-names: Names of the above areas to use during resource look-up
> +- interrupt: Should contain the DMAC interrupt number
> +- #dma-cells: must be <3>
> +
> +Optional properties:
> +- dma-channels: Number of channels supported by hardware - if not present
> + the driver will attempt to obtain the information from H/W
> +
> +Example:
> +
> + dma: dma-controller at 801C0000 {
> + compatible = "stericsson,db8500-dma40", "stericsson,dma40";
> + reg = <0x801C0000 0x1000 0x40010000 0x800>;
> + reg-names = "base", "lcpa";
> + interrupt-parent = <&intc>;
> + interrupts = <0 25 0x4>;
> +
> + #dma-cells = <2>;
> + dma-channels = <8>;
> + };
> +
> +Clients
> +Required properties:
> +- dmas: Comma separated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> + 1. A phandle pointing to the DMA controller
> + 2. Device Type
> + 3. The DMA request line number (only when 'use fixed channel' is set)
> + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> + 0x00000001: Mode:
> + Logical channel when unset
> + Physical channel when set
> + 0x00000002: Direction:
> + Memory to Device when unset
> + Device to Memory when set
> + 0x00000004: Endianess:
> + Little endian when unset
> + Big endian when set
> + 0x00000008: Use fixed channel:
> + Use automatic channel selection when unset
> + Use DMA request line number when set
> +
> +Example:
> +
> + uart at 80120000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x80120000 0x1000>;
> + interrupts = <0 11 0x4>;
> +
> + dmas = <&dma 13 0 0x2>, /* Logical - DevToMem */
> + <&dma 13 0 0x0>; /* Logical - MemToDev */
> + dma-names = "rx", "rx";
> +
> + status = "disabled";
> + };
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index bad8753..94d0edb 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -18,6 +18,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/err.h>
> #include <linux/of.h>
> +#include <linux/of_dma.h>
> #include <linux/amba/bus.h>
> #include <linux/regulator/consumer.h>
> #include <linux/platform_data/dma-ste-dma40.h>
> @@ -2409,6 +2410,50 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
> __d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
> }
>
> +#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x1)
> +#define D40_DT_FLAGS_DIR(flags) ((flags >> 1) & 0x1)
> +#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
> +#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
> +
> +static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct stedma40_chan_cfg cfg;
> + dma_cap_mask_t cap;
> + u32 flags;
> +
> + memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
> +
> + dma_cap_zero(cap);
> + dma_cap_set(DMA_SLAVE, cap);
> +
> + cfg.dev_type = dma_spec->args[0];
> + flags = dma_spec->args[2];
> +
> + switch (D40_DT_FLAGS_MODE(flags)) {
> + case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> + case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
> + }
> +
> + switch (D40_DT_FLAGS_DIR(flags)) {
> + case 0:
> + cfg.dir = STEDMA40_MEM_TO_PERIPH;
> + cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + break;
> + case 1:
> + cfg.dir = STEDMA40_PERIPH_TO_MEM;
> + cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + break;
> + }
> +
> + if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
> + cfg.phy_channel = dma_spec->args[1];
> + cfg.use_fixed_channel = true;
> + }
> +
> + return dma_request_channel(cap, stedma40_filter, &cfg);
> +}
> +
> /* DMA ENGINE functions */
> static int d40_alloc_chan_resources(struct dma_chan *chan)
> {
> @@ -3615,6 +3660,13 @@ static int __init d40_probe(struct platform_device *pdev)
>
> d40_hw_init(base);
>
> + if (np) {
> + err = of_dma_controller_register(np, d40_xlate, NULL);
> + if (err && err != -ENODEV)
> + dev_err(&pdev->dev,
> + "could not register of_dma_controller\n");
> + }
> +
> dev_info(base->dev, "initialized\n");
> return 0;
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 14:17 ` Lee Jones
(?)
@ 2013-04-25 11:33 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:33 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent, Rob Herring,
devicetree-discuss
On Thu, Apr 18, 2013 at 4:17 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This needs to be CC: to devicetree-discussed so it can be checked for OS
independence and such... Also consider including Rob Herring on posts.
> diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> new file mode 100644
> index 0000000..2679a87
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> @@ -0,0 +1,62 @@
> +* DMA40 DMA Controller
> +
> +Required properties:
> +- compatible: "stericsson,dma40"
> +- reg: Address range of the DMAC registers
> +- reg-names: Names of the above areas to use during resource look-up
> +- interrupt: Should contain the DMAC interrupt number
> +- #dma-cells: must be <3>
> +
> +Optional properties:
> +- dma-channels: Number of channels supported by hardware - if not present
> + the driver will attempt to obtain the information from H/W
I want you to define the memcpy channels in device tree as well.
Right now these are hardcoded into the driver and there is no way
to check whether they happen to overlap with other channels from the
device tree, i.e. a source of confusion.
Please add configuration for the static memcpy channels here.
> +#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x1)
> +#define D40_DT_FLAGS_DIR(flags) ((flags >> 1) & 0x1)
> +#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
> +#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
> +
> +static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct stedma40_chan_cfg cfg;
> + dma_cap_mask_t cap;
> + u32 flags;
> +
> + memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
> +
> + dma_cap_zero(cap);
> + dma_cap_set(DMA_SLAVE, cap);
> +
> + cfg.dev_type = dma_spec->args[0];
> + flags = dma_spec->args[2];
> +
> + switch (D40_DT_FLAGS_MODE(flags)) {
> + case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> + case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
> + }
> +
> + switch (D40_DT_FLAGS_DIR(flags)) {
> + case 0:
> + cfg.dir = STEDMA40_MEM_TO_PERIPH;
> + cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + break;
> + case 1:
> + cfg.dir = STEDMA40_PERIPH_TO_MEM;
> + cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + break;
> + }
> +
> + if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
> + cfg.phy_channel = dma_spec->args[1];
> + cfg.use_fixed_channel = true;
> + }
> +
> + return dma_request_channel(cap, stedma40_filter, &cfg);
> +}
Nice! But please include handling of the memcpy channels.
(Unclear to me how to do that, but now i becomes your problem ;-)
> + if (np) {
> + err = of_dma_controller_register(np, d40_xlate, NULL);
> + if (err && err != -ENODEV)
> + dev_err(&pdev->dev,
> + "could not register of_dma_controller\n");
> + }
> +
> dev_info(base->dev, "initialized\n");
> return 0;
Is it really OK to just fall through after failing to register the controller
from the device tree?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-25 11:33 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:33 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 4:17 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This needs to be CC: to devicetree-discussed so it can be checked for OS
independence and such... Also consider including Rob Herring on posts.
> diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> new file mode 100644
> index 0000000..2679a87
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> @@ -0,0 +1,62 @@
> +* DMA40 DMA Controller
> +
> +Required properties:
> +- compatible: "stericsson,dma40"
> +- reg: Address range of the DMAC registers
> +- reg-names: Names of the above areas to use during resource look-up
> +- interrupt: Should contain the DMAC interrupt number
> +- #dma-cells: must be <3>
> +
> +Optional properties:
> +- dma-channels: Number of channels supported by hardware - if not present
> + the driver will attempt to obtain the information from H/W
I want you to define the memcpy channels in device tree as well.
Right now these are hardcoded into the driver and there is no way
to check whether they happen to overlap with other channels from the
device tree, i.e. a source of confusion.
Please add configuration for the static memcpy channels here.
> +#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x1)
> +#define D40_DT_FLAGS_DIR(flags) ((flags >> 1) & 0x1)
> +#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
> +#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
> +
> +static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct stedma40_chan_cfg cfg;
> + dma_cap_mask_t cap;
> + u32 flags;
> +
> + memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
> +
> + dma_cap_zero(cap);
> + dma_cap_set(DMA_SLAVE, cap);
> +
> + cfg.dev_type = dma_spec->args[0];
> + flags = dma_spec->args[2];
> +
> + switch (D40_DT_FLAGS_MODE(flags)) {
> + case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> + case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
> + }
> +
> + switch (D40_DT_FLAGS_DIR(flags)) {
> + case 0:
> + cfg.dir = STEDMA40_MEM_TO_PERIPH;
> + cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + break;
> + case 1:
> + cfg.dir = STEDMA40_PERIPH_TO_MEM;
> + cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + break;
> + }
> +
> + if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
> + cfg.phy_channel = dma_spec->args[1];
> + cfg.use_fixed_channel = true;
> + }
> +
> + return dma_request_channel(cap, stedma40_filter, &cfg);
> +}
Nice! But please include handling of the memcpy channels.
(Unclear to me how to do that, but now i becomes your problem ;-)
> + if (np) {
> + err = of_dma_controller_register(np, d40_xlate, NULL);
> + if (err && err != -ENODEV)
> + dev_err(&pdev->dev,
> + "could not register of_dma_controller\n");
> + }
> +
> dev_info(base->dev, "initialized\n");
> return 0;
Is it really OK to just fall through after failing to register the controller
from the device tree?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread* Re: [PATCH 24/32 v3] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-25 11:33 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:33 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ,
Vinod Koul, Dan Williams, Per Forlin, Rabin Vincent, Rob Herring,
devicetree-discuss
On Thu, Apr 18, 2013 at 4:17 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This needs to be CC: to devicetree-discussed so it can be checked for OS
independence and such... Also consider including Rob Herring on posts.
> diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> new file mode 100644
> index 0000000..2679a87
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> @@ -0,0 +1,62 @@
> +* DMA40 DMA Controller
> +
> +Required properties:
> +- compatible: "stericsson,dma40"
> +- reg: Address range of the DMAC registers
> +- reg-names: Names of the above areas to use during resource look-up
> +- interrupt: Should contain the DMAC interrupt number
> +- #dma-cells: must be <3>
> +
> +Optional properties:
> +- dma-channels: Number of channels supported by hardware - if not present
> + the driver will attempt to obtain the information from H/W
I want you to define the memcpy channels in device tree as well.
Right now these are hardcoded into the driver and there is no way
to check whether they happen to overlap with other channels from the
device tree, i.e. a source of confusion.
Please add configuration for the static memcpy channels here.
> +#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x1)
> +#define D40_DT_FLAGS_DIR(flags) ((flags >> 1) & 0x1)
> +#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
> +#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
> +
> +static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct stedma40_chan_cfg cfg;
> + dma_cap_mask_t cap;
> + u32 flags;
> +
> + memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
> +
> + dma_cap_zero(cap);
> + dma_cap_set(DMA_SLAVE, cap);
> +
> + cfg.dev_type = dma_spec->args[0];
> + flags = dma_spec->args[2];
> +
> + switch (D40_DT_FLAGS_MODE(flags)) {
> + case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> + case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
> + }
> +
> + switch (D40_DT_FLAGS_DIR(flags)) {
> + case 0:
> + cfg.dir = STEDMA40_MEM_TO_PERIPH;
> + cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + break;
> + case 1:
> + cfg.dir = STEDMA40_PERIPH_TO_MEM;
> + cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + break;
> + }
> +
> + if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
> + cfg.phy_channel = dma_spec->args[1];
> + cfg.use_fixed_channel = true;
> + }
> +
> + return dma_request_channel(cap, stedma40_filter, &cfg);
> +}
Nice! But please include handling of the memcpy channels.
(Unclear to me how to do that, but now i becomes your problem ;-)
> + if (np) {
> + err = of_dma_controller_register(np, d40_xlate, NULL);
> + if (err && err != -ENODEV)
> + dev_err(&pdev->dev,
> + "could not register of_dma_controller\n");
> + }
> +
> dev_info(base->dev, "initialized\n");
> return 0;
Is it really OK to just fall through after failing to register the controller
from the device tree?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 12:12 ` Lee Jones
@ 2013-04-22 10:17 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:17 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 01:12:53PM +0100, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
> +
> + switch (D40_DT_FLAGS_MODE(flags)) {
> + case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> + case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
ah there was a v2, i need to see the thread, this one still needs to be fixed
though
--
~Vinod
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 24/32 v2] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-22 10:17 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:17 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 01:12:53PM +0100, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manner.
> +
> + switch (D40_DT_FLAGS_MODE(flags)) {
> + case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> + case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
ah there was a v2, i need to see the thread, this one still needs to be fixed
though
--
~Vinod
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
2013-04-18 10:12 ` Lee Jones
@ 2013-04-22 10:16 ` Vinod Koul
-1 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:16 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, arnd, linus.walleij,
Dan Williams, Per Forlin, Rabin Vincent
On Thu, Apr 18, 2013 at 11:12:06AM +0100, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manor.
typo ^^^^^
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> .../devicetree/bindings/dma/ste-dma40.txt | 66 ++++++++++++++++++++
> drivers/dma/ste_dma40.c | 58 +++++++++++++++++
> 2 files changed, 124 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/ste-dma40.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> new file mode 100644
> index 0000000..1eb7958
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> @@ -0,0 +1,66 @@
> +* DMA40 DMA Controller
> +
> +Required properties:
> +- compatible: "stericsson,dma40"
> +- reg: Address range of the DMAC registers
> +- interrupt: Should contain the DMAC interrupt number
> +- dma-channels: Number of channels supported by hardware
> +- #dma-cells: must be <3>
> +
> +Optional properties:
> +- interrupt-parent: Should be the phandle for the interrupt controller
> + that services interrupts for this device
> +
> +Example:
> +
> + dma: dma-controller@801C0000 {
> + compatible = "stericsson,db8500-dma40", "stericsson,dma40";
> + reg = <0x801C0000 0x1000>;
> + reg-names = "base";
> + interrupt-parent = <&intc>;
> + interrupts = <0 25 0x4>;
> +
> + #dma-cells = <2>;
> + dma-channels = <0>; /* Zero means read from H/W. */
> + };
> +
This needs to be Acked-By Arnd..
> +Clients
> +Required properties:
> +- dmas: Comma seperated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> + 1. A phandle pointing to the DMA controller
> + 2. The DMA request line number (only when 'use fixed channel' is set)
> + 3. Device Type
> + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> + bits 1-2: Mode:
> + 00: Logical
> + 01: Physical
> + 10: Operation
> + 11: Undefined - will most likely return an error
> + bits 3-4: Direction:
> + 00: Mem to Mem
> + 01: Mem to Dev
> + 10: Dev to Mem
> + 11: Dev to Dev
> + bit 5: Endianess:
> + 0: Little endian
> + 1: Big endian
> + bit 6: Use fixed channel:
> + 0: Use automatic channel selection
> + 1: Use DMA request line number
> +
> +Example:
> +
> + uart@80120000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x80120000 0x1000>;
> + interrupts = <0 11 0x4>;
> +
> + dmas = <&dma 0 13 0x8>, /* Logical - DevToMem */
> + <&dma 0 13 0x4>; /* Logical - MemToDev */
> + dma-names = "rx", "rx";
> +
> + status = "disabled";
> + };
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 4782ee7..9115c0e 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -18,6 +18,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/err.h>
> #include <linux/of.h>
> +#include <linux/of_dma.h>
> #include <linux/amba/bus.h>
> #include <linux/regulator/consumer.h>
> #include <linux/platform_data/dma-ste-dma40.h>
> @@ -2409,6 +2410,56 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
> __d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
> }
>
> +#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x3)
> +#define D40_DT_FLAGS_DIR(flags) ((flags >> 2) & 0x3)
> +#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 4) & 0x1)
> +#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 5) & 0x1)
> +
> +static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct stedma40_chan_cfg cfg;
> + dma_cap_mask_t cap;
> + u32 flags;
> +
> + memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
> +
> + dma_cap_zero(cap);
> + dma_cap_set(DMA_SLAVE, cap);
> +
> + cfg.dev_type = dma_spec->args[1];
> + flags = dma_spec->args[2];
> +
> + switch (D40_DT_FLAGS_MODE(flags)) {
> + case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> + case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
> + case 2: cfg.mode = STEDMA40_MODE_OPERATION; break;
> + default:
> + pr_err("dma40: Unknown mode read from DT (%d)\n",
> + D40_DT_FLAGS_MODE(flags));
> + return NULL;
> + }
> +
> + switch (D40_DT_FLAGS_DIR(flags)) {
> + case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
> + case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
> + case 2: cfg.dir = STEDMA40_PERIPH_TO_MEM; break;
> + case 3: cfg.dir = STEDMA40_PERIPH_TO_PERIPH; break;
this looks ugly to me, Checkpatch should have complained..
Break could be on subsequent lines...
> + }
> +
> + if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
> + cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
> + cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> +
> + if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
> + cfg.phy_channel = dma_spec->args[0];
> + cfg.use_fixed_channel = true;
> + }
> +
> + return dma_request_channel(cap, stedma40_filter, &cfg);
> +}
> +
> /* DMA ENGINE functions */
> static int d40_alloc_chan_resources(struct dma_chan *chan)
> {
> @@ -3615,6 +3666,13 @@ static int __init d40_probe(struct platform_device *pdev)
>
> d40_hw_init(base);
>
> + if (np) {
> + err = of_dma_controller_register(np, d40_xlate, NULL);
> + if (err && err != -ENODEV)
> + dev_err(&pdev->dev,
> + "could not register of_dma_controller\n");
> + }
> +
> dev_info(base->dev, "initialized\n");
> return 0;
>
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread* [PATCH 24/32] dmaengine: ste_dma40: Supply full Device Tree parsing support
@ 2013-04-22 10:16 ` Vinod Koul
0 siblings, 0 replies; 337+ messages in thread
From: Vinod Koul @ 2013-04-22 10:16 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 11:12:06AM +0100, Lee Jones wrote:
> Using the new DMA DT bindings and API, we can register the DMA40 driver
> as Device Tree capable. Now, when a client attempts to allocate a
> channel using the DMA DT bindings via its own node, we are able to parse
> the request and allocate a channel in the correct manor.
typo ^^^^^
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> .../devicetree/bindings/dma/ste-dma40.txt | 66 ++++++++++++++++++++
> drivers/dma/ste_dma40.c | 58 +++++++++++++++++
> 2 files changed, 124 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/ste-dma40.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> new file mode 100644
> index 0000000..1eb7958
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> @@ -0,0 +1,66 @@
> +* DMA40 DMA Controller
> +
> +Required properties:
> +- compatible: "stericsson,dma40"
> +- reg: Address range of the DMAC registers
> +- interrupt: Should contain the DMAC interrupt number
> +- dma-channels: Number of channels supported by hardware
> +- #dma-cells: must be <3>
> +
> +Optional properties:
> +- interrupt-parent: Should be the phandle for the interrupt controller
> + that services interrupts for this device
> +
> +Example:
> +
> + dma: dma-controller at 801C0000 {
> + compatible = "stericsson,db8500-dma40", "stericsson,dma40";
> + reg = <0x801C0000 0x1000>;
> + reg-names = "base";
> + interrupt-parent = <&intc>;
> + interrupts = <0 25 0x4>;
> +
> + #dma-cells = <2>;
> + dma-channels = <0>; /* Zero means read from H/W. */
> + };
> +
This needs to be Acked-By Arnd..
> +Clients
> +Required properties:
> +- dmas: Comma seperated list of dma channel requests
> +- dma-names: Names of the aforementioned requested channels
> +
> +Each dmas request consists of 4 cells:
> + 1. A phandle pointing to the DMA controller
> + 2. The DMA request line number (only when 'use fixed channel' is set)
> + 3. Device Type
> + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
> + bits 1-2: Mode:
> + 00: Logical
> + 01: Physical
> + 10: Operation
> + 11: Undefined - will most likely return an error
> + bits 3-4: Direction:
> + 00: Mem to Mem
> + 01: Mem to Dev
> + 10: Dev to Mem
> + 11: Dev to Dev
> + bit 5: Endianess:
> + 0: Little endian
> + 1: Big endian
> + bit 6: Use fixed channel:
> + 0: Use automatic channel selection
> + 1: Use DMA request line number
> +
> +Example:
> +
> + uart at 80120000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x80120000 0x1000>;
> + interrupts = <0 11 0x4>;
> +
> + dmas = <&dma 0 13 0x8>, /* Logical - DevToMem */
> + <&dma 0 13 0x4>; /* Logical - MemToDev */
> + dma-names = "rx", "rx";
> +
> + status = "disabled";
> + };
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 4782ee7..9115c0e 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -18,6 +18,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/err.h>
> #include <linux/of.h>
> +#include <linux/of_dma.h>
> #include <linux/amba/bus.h>
> #include <linux/regulator/consumer.h>
> #include <linux/platform_data/dma-ste-dma40.h>
> @@ -2409,6 +2410,56 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
> __d40_set_prio_rt(d40c, d40c->dma_cfg.dev_type, false);
> }
>
> +#define D40_DT_FLAGS_MODE(flags) ((flags >> 0) & 0x3)
> +#define D40_DT_FLAGS_DIR(flags) ((flags >> 2) & 0x3)
> +#define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 4) & 0x1)
> +#define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 5) & 0x1)
> +
> +static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct stedma40_chan_cfg cfg;
> + dma_cap_mask_t cap;
> + u32 flags;
> +
> + memset(&cfg, 0, sizeof(struct stedma40_chan_cfg));
> +
> + dma_cap_zero(cap);
> + dma_cap_set(DMA_SLAVE, cap);
> +
> + cfg.dev_type = dma_spec->args[1];
> + flags = dma_spec->args[2];
> +
> + switch (D40_DT_FLAGS_MODE(flags)) {
> + case 0: cfg.mode = STEDMA40_MODE_LOGICAL; break;
> + case 1: cfg.mode = STEDMA40_MODE_PHYSICAL; break;
> + case 2: cfg.mode = STEDMA40_MODE_OPERATION; break;
> + default:
> + pr_err("dma40: Unknown mode read from DT (%d)\n",
> + D40_DT_FLAGS_MODE(flags));
> + return NULL;
> + }
> +
> + switch (D40_DT_FLAGS_DIR(flags)) {
> + case 0: cfg.dir = STEDMA40_MEM_TO_MEM; break;
> + case 1: cfg.dir = STEDMA40_MEM_TO_PERIPH; break;
> + case 2: cfg.dir = STEDMA40_PERIPH_TO_MEM; break;
> + case 3: cfg.dir = STEDMA40_PERIPH_TO_PERIPH; break;
this looks ugly to me, Checkpatch should have complained..
Break could be on subsequent lines...
> + }
> +
> + if (cfg.dir == STEDMA40_PERIPH_TO_MEM)
> + cfg.src_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> + if (cfg.dir == STEDMA40_MEM_TO_PERIPH)
> + cfg.dst_info.big_endian = D40_DT_FLAGS_BIG_ENDIAN(flags);
> +
> + if (D40_DT_FLAGS_FIXED_CHAN(flags)) {
> + cfg.phy_channel = dma_spec->args[0];
> + cfg.use_fixed_channel = true;
> + }
> +
> + return dma_request_channel(cap, stedma40_filter, &cfg);
> +}
> +
> /* DMA ENGINE functions */
> static int d40_alloc_chan_resources(struct dma_chan *chan)
> {
> @@ -3615,6 +3666,13 @@ static int __init d40_probe(struct platform_device *pdev)
>
> d40_hw_init(base);
>
> + if (np) {
> + err = of_dma_controller_register(np, d40_xlate, NULL);
> + if (err && err != -ENODEV)
> + dev_err(&pdev->dev,
> + "could not register of_dma_controller\n");
> + }
> +
> dev_info(base->dev, "initialized\n");
> return 0;
>
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 25/32] ARM: ux500: Setup the DMA40 driver's DT node using the new DMA API
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
The new DMA is now available, so let's use it to setup ST-Ericsson's
DMA40 driver when Device Tree is enabled.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 0f462b7..e2fa20f 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -182,12 +182,14 @@
interrupts = <0 23 0x4>;
};
- dma-controller@801C0000 {
- compatible = "stericsson,db8500-dma40",
- "stericsson,dma40";
+ dma: dma-controller@801C0000 {
+ compatible = "stericsson,db8500-dma40", "stericsson,dma40";
reg = <0x801C0000 0x1000 0x40010000 0x800>;
reg-names = "base", "lcpa";
interrupts = <0 25 0x4>;
+
+ #dma-cells = <3>;
+ dma-channels = <0>; /* Zero means read from H/W. */
};
prcmu: prcmu@80157000 {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 25/32] ARM: ux500: Setup the DMA40 driver's DT node using the new DMA API
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
The new DMA is now available, so let's use it to setup ST-Ericsson's
DMA40 driver when Device Tree is enabled.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 0f462b7..e2fa20f 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -182,12 +182,14 @@
interrupts = <0 23 0x4>;
};
- dma-controller at 801C0000 {
- compatible = "stericsson,db8500-dma40",
- "stericsson,dma40";
+ dma: dma-controller at 801C0000 {
+ compatible = "stericsson,db8500-dma40", "stericsson,dma40";
reg = <0x801C0000 0x1000 0x40010000 0x800>;
reg-names = "base", "lcpa";
interrupts = <0 25 0x4>;
+
+ #dma-cells = <3>;
+ dma-channels = <0>; /* Zero means read from H/W. */
};
prcmu: prcmu at 80157000 {
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 25/32] ARM: ux500: Setup the DMA40 driver's DT node using the new DMA API
2013-04-18 10:12 ` Lee Jones
@ 2013-04-18 11:08 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:08 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, linus.walleij
On Thursday 18 April 2013, Lee Jones wrote:
> The new DMA is now available, so let's use it to setup ST-Ericsson's
> DMA40 driver when Device Tree is enabled.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 25/32] ARM: ux500: Setup the DMA40 driver's DT node using the new DMA API
@ 2013-04-18 11:08 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:08 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> The new DMA is now available, so let's use it to setup ST-Ericsson's
> DMA40 driver when Device Tree is enabled.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 25/32] ARM: ux500: Setup the DMA40 driver's DT node using the new DMA API
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:35 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:35 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The new DMA is now available, so let's use it to setup ST-Ericsson's
> DMA40 driver when Device Tree is enabled.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This is one of those patches I want to put on a special devicetree
branch, but looks allright, Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 25/32] ARM: ux500: Setup the DMA40 driver's DT node using the new DMA API
@ 2013-04-25 11:35 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:35 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The new DMA is now available, so let's use it to setup ST-Ericsson's
> DMA40 driver when Device Tree is enabled.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This is one of those patches I want to put on a special devicetree
branch, but looks allright, Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 26/32] ARM: ux500: Supply UART's DMA configuration via Device Tree
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
When requesting a channel, a DMA client needs to pass some pieces of
information such as; request channel, device type, channel type and
direction etc. Normally we do this in the form of platform data, but
when DT is enabled we need to pass it using the driver's bindings
instead.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index e2fa20f..bd0fe5f 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -569,18 +569,35 @@
compatible = "arm,pl011", "arm,primecell";
reg = <0x80120000 0x1000>;
interrupts = <0 11 0x4>;
+
+ dmas = <&dma 0 13 0x8>, /* Logical - DevToMem */
+ <&dma 0 13 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
+
uart@80121000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x80121000 0x1000>;
interrupts = <0 19 0x4>;
+
+ dmas = <&dma 0 12 0x8>, /* Logical - DevToMem */
+ <&dma 0 12 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
+
uart@80007000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x80007000 0x1000>;
interrupts = <0 26 0x4>;
+
+ dmas = <&dma 0 11 0x8>, /* Logical - DevToMem */
+ <&dma 0 11 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 26/32] ARM: ux500: Supply UART's DMA configuration via Device Tree
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
When requesting a channel, a DMA client needs to pass some pieces of
information such as; request channel, device type, channel type and
direction etc. Normally we do this in the form of platform data, but
when DT is enabled we need to pass it using the driver's bindings
instead.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index e2fa20f..bd0fe5f 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -569,18 +569,35 @@
compatible = "arm,pl011", "arm,primecell";
reg = <0x80120000 0x1000>;
interrupts = <0 11 0x4>;
+
+ dmas = <&dma 0 13 0x8>, /* Logical - DevToMem */
+ <&dma 0 13 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
+
uart at 80121000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x80121000 0x1000>;
interrupts = <0 19 0x4>;
+
+ dmas = <&dma 0 12 0x8>, /* Logical - DevToMem */
+ <&dma 0 12 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
+
uart at 80007000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x80007000 0x1000>;
interrupts = <0 26 0x4>;
+
+ dmas = <&dma 0 11 0x8>, /* Logical - DevToMem */
+ <&dma 0 11 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 26/32] ARM: ux500: Supply UART's DMA configuration via Device Tree
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:36 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:36 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> When requesting a channel, a DMA client needs to pass some pieces of
> information such as; request channel, device type, channel type and
> direction etc. Normally we do this in the form of platform data, but
> when DT is enabled we need to pass it using the driver's bindings
> instead.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 26/32] ARM: ux500: Supply UART's DMA configuration via Device Tree
@ 2013-04-25 11:36 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:36 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> When requesting a channel, a DMA client needs to pass some pieces of
> information such as; request channel, device type, channel type and
> direction etc. Normally we do this in the form of platform data, but
> when DT is enabled we need to pass it using the driver's bindings
> instead.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 27/32] ARM: ux500: Stop registering DMA40 from platform data when DT is enabled
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
Now the DMA40 has been DT:ed, there's no requirement to register it
using traditional methods. This is the penultimate device to be DT:ed.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index a15678d..eae3e3a 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -229,16 +229,6 @@ static struct device * __init u8500_of_init_devices(void)
db8500_add_usb(parent, usb_db8500_dma_cfg, usb_db8500_dma_cfg);
- u8500_dma40_device.dev.parent = parent;
-
- /*
- * Devices to be DT:ed:
- * u8500_dma40_device = todo
- * db8500_pmu_device = done
- * db8500_prcmu_device = done
- */
- platform_device_register(&u8500_dma40_device);
-
return parent;
}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* [PATCH 27/32] ARM: ux500: Stop registering DMA40 from platform data when DT is enabled
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Now the DMA40 has been DT:ed, there's no requirement to register it
using traditional methods. This is the penultimate device to be DT:ed.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index a15678d..eae3e3a 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -229,16 +229,6 @@ static struct device * __init u8500_of_init_devices(void)
db8500_add_usb(parent, usb_db8500_dma_cfg, usb_db8500_dma_cfg);
- u8500_dma40_device.dev.parent = parent;
-
- /*
- * Devices to be DT:ed:
- * u8500_dma40_device = todo
- * db8500_pmu_device = done
- * db8500_prcmu_device = done
- */
- platform_device_register(&u8500_dma40_device);
-
return parent;
}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* Re: [PATCH 27/32] ARM: ux500: Stop registering DMA40 from platform data when DT is enabled
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:37 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:37 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Now the DMA40 has been DT:ed, there's no requirement to register it
> using traditional methods. This is the penultimate device to be DT:ed.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 27/32] ARM: ux500: Stop registering DMA40 from platform data when DT is enabled
@ 2013-04-25 11:37 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:37 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Now the DMA40 has been DT:ed, there's no requirement to register it
> using traditional methods. This is the penultimate device to be DT:ed.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 28/32] ARM: ux500: Pass remnant platform data though to DMA40 driver
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
Ironically, in order to remove lots of the auxdata assignments, we have
to add just one more. A lot of them require DMA information to be passed
into clients for DMA channel allocation, but we now have this capability
in Device Tree. However, the DMA40 driver still relies on a reverse table
look-up to obtain DMA addresses. Until all of the clients are converted,
over to the new API, we're stuck with this.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500.h | 1 +
arch/arm/mach-ux500/cpu-db8500.c | 3 +++
arch/arm/mach-ux500/devices-db8500.c | 2 +-
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
index d38951b..2c5139d 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -93,6 +93,7 @@ extern struct amba_pl011_data uart0_plat;
extern struct amba_pl011_data uart1_plat;
extern struct amba_pl011_data uart2_plat;
extern struct pl022_ssp_controller ssp0_plat;
+extern struct stedma40_platform_data dma40_plat_data;
extern void mop500_sdi_init(struct device *parent);
extern void snowball_sdi_init(struct device *parent);
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index eae3e3a..b216233 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -273,6 +273,9 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
"ux500-msp-i2s.2", &msp2_platform_data),
OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80125000,
"ux500-msp-i2s.3", &msp3_platform_data),
+ /* Requires clock name bindings and channel address lookup table. */
+ OF_DEV_AUXDATA("stericsson,db8500-dma40", 0x801C0000,
+ "dma40.0", &dma40_plat_data),
{},
};
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 2fcb8c2..3e4993e 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -120,7 +120,7 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
[DB8500_DMA_DEV48_CAC1] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
};
-static struct stedma40_platform_data dma40_plat_data = {
+struct stedma40_platform_data dma40_plat_data = {
.dev_rx = dma40_rx_map,
.dev_tx = dma40_tx_map,
.disabled_channels = {-1},
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 28/32] ARM: ux500: Pass remnant platform data though to DMA40 driver
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Ironically, in order to remove lots of the auxdata assignments, we have
to add just one more. A lot of them require DMA information to be passed
into clients for DMA channel allocation, but we now have this capability
in Device Tree. However, the DMA40 driver still relies on a reverse table
look-up to obtain DMA addresses. Until all of the clients are converted,
over to the new API, we're stuck with this.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/board-mop500.h | 1 +
arch/arm/mach-ux500/cpu-db8500.c | 3 +++
arch/arm/mach-ux500/devices-db8500.c | 2 +-
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
index d38951b..2c5139d 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -93,6 +93,7 @@ extern struct amba_pl011_data uart0_plat;
extern struct amba_pl011_data uart1_plat;
extern struct amba_pl011_data uart2_plat;
extern struct pl022_ssp_controller ssp0_plat;
+extern struct stedma40_platform_data dma40_plat_data;
extern void mop500_sdi_init(struct device *parent);
extern void snowball_sdi_init(struct device *parent);
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index eae3e3a..b216233 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -273,6 +273,9 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
"ux500-msp-i2s.2", &msp2_platform_data),
OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80125000,
"ux500-msp-i2s.3", &msp3_platform_data),
+ /* Requires clock name bindings and channel address lookup table. */
+ OF_DEV_AUXDATA("stericsson,db8500-dma40", 0x801C0000,
+ "dma40.0", &dma40_plat_data),
{},
};
diff --git a/arch/arm/mach-ux500/devices-db8500.c b/arch/arm/mach-ux500/devices-db8500.c
index 2fcb8c2..3e4993e 100644
--- a/arch/arm/mach-ux500/devices-db8500.c
+++ b/arch/arm/mach-ux500/devices-db8500.c
@@ -120,7 +120,7 @@ static const dma_addr_t dma40_rx_map[DB8500_DMA_NR_DEV] = {
[DB8500_DMA_DEV48_CAC1] = U8500_CRYP1_BASE + CRYP1_RX_REG_OFFSET,
};
-static struct stedma40_platform_data dma40_plat_data = {
+struct stedma40_platform_data dma40_plat_data = {
.dev_rx = dma40_rx_map,
.dev_tx = dma40_tx_map,
.disabled_channels = {-1},
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 28/32] ARM: ux500: Pass remnant platform data though to DMA40 driver
2013-04-18 10:12 ` Lee Jones
@ 2013-04-18 11:11 ` Arnd Bergmann
-1 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:11 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, linus.walleij
On Thursday 18 April 2013, Lee Jones wrote:
> Ironically, in order to remove lots of the auxdata assignments, we have
> to add just one more. A lot of them require DMA information to be passed
> into clients for DMA channel allocation, but we now have this capability
> in Device Tree. However, the DMA40 driver still relies on a reverse table
> look-up to obtain DMA addresses. Until all of the clients are converted,
> over to the new API, we're stuck with this.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
but please fold this together with patch 27, since applying one without the
other breaks booting.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 28/32] ARM: ux500: Pass remnant platform data though to DMA40 driver
@ 2013-04-18 11:11 ` Arnd Bergmann
0 siblings, 0 replies; 337+ messages in thread
From: Arnd Bergmann @ 2013-04-18 11:11 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 18 April 2013, Lee Jones wrote:
> Ironically, in order to remove lots of the auxdata assignments, we have
> to add just one more. A lot of them require DMA information to be passed
> into clients for DMA channel allocation, but we now have this capability
> in Device Tree. However, the DMA40 driver still relies on a reverse table
> look-up to obtain DMA addresses. Until all of the clients are converted,
> over to the new API, we're stuck with this.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
but please fold this together with patch 27, since applying one without the
other breaks booting.
Arnd
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 28/32] ARM: ux500: Pass remnant platform data though to DMA40 driver
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:39 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:39 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Ironically, in order to remove lots of the auxdata assignments, we have
> to add just one more. A lot of them require DMA information to be passed
> into clients for DMA channel allocation, but we now have this capability
> in Device Tree. However, the DMA40 driver still relies on a reverse table
> look-up to obtain DMA addresses. Until all of the clients are converted,
> over to the new API, we're stuck with this.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
As mentioned merge into patch 27, then ACK.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 28/32] ARM: ux500: Pass remnant platform data though to DMA40 driver
@ 2013-04-25 11:39 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:39 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Ironically, in order to remove lots of the auxdata assignments, we have
> to add just one more. A lot of them require DMA information to be passed
> into clients for DMA channel allocation, but we now have this capability
> in Device Tree. However, the DMA40 driver still relies on a reverse table
> look-up to obtain DMA addresses. Until all of the clients are converted,
> over to the new API, we're stuck with this.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
As mentioned merge into patch 27, then ACK.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 29/32] ARM: ux500: Stop passing UART's platform data for Device Tree boots
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
It was required to pass DMA channel configuration information to the
UART driver before the new DMA API was in place. Now that it is, and
is fully compatible with Device Tree we can stop doing that.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index b216233..27d75c8 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -236,9 +236,9 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
/* Requires call-back bindings. */
OF_DEV_AUXDATA("arm,cortex-a9-pmu", 0, "arm-pmu", &db8500_pmu_platdata),
/* Requires DMA bindings. */
- OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", &uart0_plat),
- OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", &uart1_plat),
- OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", &uart2_plat),
+ OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", NULL),
+ OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", NULL),
+ OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", NULL),
OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0", &ssp0_plat),
OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0", &mop500_sdi0_data),
OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1", &mop500_sdi1_data),
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 29/32] ARM: ux500: Stop passing UART's platform data for Device Tree boots
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
It was required to pass DMA channel configuration information to the
UART driver before the new DMA API was in place. Now that it is, and
is fully compatible with Device Tree we can stop doing that.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index b216233..27d75c8 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -236,9 +236,9 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
/* Requires call-back bindings. */
OF_DEV_AUXDATA("arm,cortex-a9-pmu", 0, "arm-pmu", &db8500_pmu_platdata),
/* Requires DMA bindings. */
- OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", &uart0_plat),
- OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", &uart1_plat),
- OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", &uart2_plat),
+ OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", NULL),
+ OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", NULL),
+ OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", NULL),
OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0", &ssp0_plat),
OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0", &mop500_sdi0_data),
OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1", &mop500_sdi1_data),
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 29/32] ARM: ux500: Stop passing UART's platform data for Device Tree boots
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:41 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:41 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> It was required to pass DMA channel configuration information to the
> UART driver before the new DMA API was in place. Now that it is, and
> is fully compatible with Device Tree we can stop doing that.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Removes a nasty dependency to the board file as well!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 29/32] ARM: ux500: Stop passing UART's platform data for Device Tree boots
@ 2013-04-25 11:41 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:41 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> It was required to pass DMA channel configuration information to the
> UART driver before the new DMA API was in place. Now that it is, and
> is fully compatible with Device Tree we can stop doing that.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Removes a nasty dependency to the board file as well!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device Tree
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
When requesting a channel, a DMA client needs to pass some pieces of
information such as; request channel, device type, channel type and
direction etc. Normally we do this in the form of platform data, but
when DT is enabled we need to pass it using the driver's bindings
instead.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index bd0fe5f..c064a9a 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -605,6 +605,11 @@
compatible = "arm,pl18x", "arm,primecell";
reg = <0x80126000 0x1000>;
interrupts = <0 60 0x4>;
+
+ dmas = <&dma 0 29 0x8>, /* Logical - DevToMem */
+ <&dma 0 29 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
@@ -612,6 +617,11 @@
compatible = "arm,pl18x", "arm,primecell";
reg = <0x80118000 0x1000>;
interrupts = <0 50 0x4>;
+
+ dmas = <&dma 0 32 0x8>, /* Logical - DevToMem */
+ <&dma 0 32 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
@@ -619,6 +629,11 @@
compatible = "arm,pl18x", "arm,primecell";
reg = <0x80005000 0x1000>;
interrupts = <0 41 0x4>;
+
+ dmas = <&dma 0 28 0x8>, /* Logical - DevToMem */
+ <&dma 0 28 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
@@ -633,6 +648,11 @@
compatible = "arm,pl18x", "arm,primecell";
reg = <0x80114000 0x1000>;
interrupts = <0 99 0x4>;
+
+ dmas = <&dma 0 42 0x8>, /* Logical - DevToMem */
+ <&dma 0 42 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device Tree
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
When requesting a channel, a DMA client needs to pass some pieces of
information such as; request channel, device type, channel type and
direction etc. Normally we do this in the form of platform data, but
when DT is enabled we need to pass it using the driver's bindings
instead.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/dbx5x0.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index bd0fe5f..c064a9a 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -605,6 +605,11 @@
compatible = "arm,pl18x", "arm,primecell";
reg = <0x80126000 0x1000>;
interrupts = <0 60 0x4>;
+
+ dmas = <&dma 0 29 0x8>, /* Logical - DevToMem */
+ <&dma 0 29 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
@@ -612,6 +617,11 @@
compatible = "arm,pl18x", "arm,primecell";
reg = <0x80118000 0x1000>;
interrupts = <0 50 0x4>;
+
+ dmas = <&dma 0 32 0x8>, /* Logical - DevToMem */
+ <&dma 0 32 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
@@ -619,6 +629,11 @@
compatible = "arm,pl18x", "arm,primecell";
reg = <0x80005000 0x1000>;
interrupts = <0 41 0x4>;
+
+ dmas = <&dma 0 28 0x8>, /* Logical - DevToMem */
+ <&dma 0 28 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
@@ -633,6 +648,11 @@
compatible = "arm,pl18x", "arm,primecell";
reg = <0x80114000 0x1000>;
interrupts = <0 99 0x4>;
+
+ dmas = <&dma 0 42 0x8>, /* Logical - DevToMem */
+ <&dma 0 42 0x4>; /* Logical - MemToDev */
+ dma-names = "rx", "tx";
+
status = "disabled";
};
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread
* Re: [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device Tree
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:43 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:43 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> When requesting a channel, a DMA client needs to pass some pieces of
> information such as; request channel, device type, channel type and
> direction etc. Normally we do this in the form of platform data, but
> when DT is enabled we need to pass it using the driver's bindings
> instead.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This requires that the pending MMCI patch get merged *first* right?
So you need to make sure Russell will merge that (or ACK it
and include it) before you send any pull requests to me.
Apart from that it looks allright:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device Tree
@ 2013-04-25 11:43 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:43 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> When requesting a channel, a DMA client needs to pass some pieces of
> information such as; request channel, device type, channel type and
> direction etc. Normally we do this in the form of platform data, but
> when DT is enabled we need to pass it using the driver's bindings
> instead.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
This requires that the pending MMCI patch get merged *first* right?
So you need to make sure Russell will merge that (or ACK it
and include it) before you send any pull requests to me.
Apart from that it looks allright:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device Tree
2013-04-25 11:43 ` Linus Walleij
@ 2013-04-25 11:49 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 11:49 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > When requesting a channel, a DMA client needs to pass some pieces of
> > information such as; request channel, device type, channel type and
> > direction etc. Normally we do this in the form of platform data, but
> > when DT is enabled we need to pass it using the driver's bindings
> > instead.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> This requires that the pending MMCI patch get merged *first* right?
No, it doesn't. There is no harm in applying this *before*.
It will just lay dormant until it is.
> So you need to make sure Russell will merge that (or ACK it
> and include it) before you send any pull requests to me.
>
> Apart from that it looks allright:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device Tree
@ 2013-04-25 11:49 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 11:49 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > When requesting a channel, a DMA client needs to pass some pieces of
> > information such as; request channel, device type, channel type and
> > direction etc. Normally we do this in the form of platform data, but
> > when DT is enabled we need to pass it using the driver's bindings
> > instead.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> This requires that the pending MMCI patch get merged *first* right?
No, it doesn't. There is no harm in applying this *before*.
It will just lay dormant until it is.
> So you need to make sure Russell will merge that (or ACK it
> and include it) before you send any pull requests to me.
>
> Apart from that it looks allright:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device Tree
2013-04-25 11:49 ` Lee Jones
@ 2013-04-25 12:56 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:56 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 25, 2013 at 1:49 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> > When requesting a channel, a DMA client needs to pass some pieces of
>> > information such as; request channel, device type, channel type and
>> > direction etc. Normally we do this in the form of platform data, but
>> > when DT is enabled we need to pass it using the driver's bindings
>> > instead.
>> >
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>>
>> This requires that the pending MMCI patch get merged *first* right?
>
> No, it doesn't. There is no harm in applying this *before*.
>
> It will just lay dormant until it is.
Ah yeah, right. But the patch stripping out the platform data (no 31) will
wreak havoc if applied before the MMCI patch right?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device Tree
@ 2013-04-25 12:56 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 12:56 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 25, 2013 at 1:49 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 25 Apr 2013, Linus Walleij wrote:
>
>> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> > When requesting a channel, a DMA client needs to pass some pieces of
>> > information such as; request channel, device type, channel type and
>> > direction etc. Normally we do this in the form of platform data, but
>> > when DT is enabled we need to pass it using the driver's bindings
>> > instead.
>> >
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>>
>> This requires that the pending MMCI patch get merged *first* right?
>
> No, it doesn't. There is no harm in applying this *before*.
>
> It will just lay dormant until it is.
Ah yeah, right. But the patch stripping out the platform data (no 31) will
wreak havoc if applied before the MMCI patch right?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device Tree
2013-04-25 12:56 ` Linus Walleij
@ 2013-04-25 13:11 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 13:11 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 1:49 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 25 Apr 2013, Linus Walleij wrote:
> >
> >> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> >>
> >> > When requesting a channel, a DMA client needs to pass some pieces of
> >> > information such as; request channel, device type, channel type and
> >> > direction etc. Normally we do this in the form of platform data, but
> >> > when DT is enabled we need to pass it using the driver's bindings
> >> > instead.
> >> >
> >> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >>
> >> This requires that the pending MMCI patch get merged *first* right?
> >
> > No, it doesn't. There is no harm in applying this *before*.
> >
> > It will just lay dormant until it is.
>
> Ah yeah, right. But the patch stripping out the platform data (no 31) will
> wreak havoc if applied before the MMCI patch right?
Yes, that will cause problems. It will most likely go into PIO mode.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 30/32] ARM: ux500: Supply MMC DMA configuration via Device Tree
@ 2013-04-25 13:11 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-25 13:11 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 25, 2013 at 1:49 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 25 Apr 2013, Linus Walleij wrote:
> >
> >> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> >>
> >> > When requesting a channel, a DMA client needs to pass some pieces of
> >> > information such as; request channel, device type, channel type and
> >> > direction etc. Normally we do this in the form of platform data, but
> >> > when DT is enabled we need to pass it using the driver's bindings
> >> > instead.
> >> >
> >> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >>
> >> This requires that the pending MMCI patch get merged *first* right?
> >
> > No, it doesn't. There is no harm in applying this *before*.
> >
> > It will just lay dormant until it is.
>
> Ah yeah, right. But the patch stripping out the platform data (no 31) will
> wreak havoc if applied before the MMCI patch right?
Yes, that will cause problems. It will most likely go into PIO mode.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 31/32] ARM: ux500: Stop passing MMC's platform data for Device Tree boots
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
It was required to pass DMA channel configuration information to the
MMC driver before the new DMA API was in place. Now that it is, and
is fully compatible with Device Tree we can stop doing that.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 27d75c8..501281c 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -240,10 +240,10 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", NULL),
OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", NULL),
OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0", &ssp0_plat),
- OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0", &mop500_sdi0_data),
- OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1", &mop500_sdi1_data),
- OF_DEV_AUXDATA("arm,pl18x", 0x80005000, "sdi2", &mop500_sdi2_data),
- OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4", &mop500_sdi4_data),
+ OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0", NULL),
+ OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1", NULL),
+ OF_DEV_AUXDATA("arm,pl18x", 0x80005000, "sdi2", NULL),
+ OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4", NULL),
/* Requires clock name bindings. */
OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 31/32] ARM: ux500: Stop passing MMC's platform data for Device Tree boots
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
It was required to pass DMA channel configuration information to the
MMC driver before the new DMA API was in place. Now that it is, and
is fully compatible with Device Tree we can stop doing that.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 27d75c8..501281c 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -240,10 +240,10 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", NULL),
OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", NULL),
OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0", &ssp0_plat),
- OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0", &mop500_sdi0_data),
- OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1", &mop500_sdi1_data),
- OF_DEV_AUXDATA("arm,pl18x", 0x80005000, "sdi2", &mop500_sdi2_data),
- OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4", &mop500_sdi4_data),
+ OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0", NULL),
+ OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1", NULL),
+ OF_DEV_AUXDATA("arm,pl18x", 0x80005000, "sdi2", NULL),
+ OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4", NULL),
/* Requires clock name bindings. */
OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 31/32] ARM: ux500: Stop passing MMC's platform data for Device Tree boots
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:44 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:44 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> It was required to pass DMA channel configuration information to the
> MMC driver before the new DMA API was in place. Now that it is, and
> is fully compatible with Device Tree we can stop doing that.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Really nice provided the dependencies are in place.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 31/32] ARM: ux500: Stop passing MMC's platform data for Device Tree boots
@ 2013-04-25 11:44 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:44 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> It was required to pass DMA channel configuration information to the
> MMC driver before the new DMA API was in place. Now that it is, and
> is fully compatible with Device Tree we can stop doing that.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Really nice provided the dependencies are in place.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 32/32] ARM: ux500: Move SDI (MMC) and UART devices under more descriptive heading
2013-04-18 10:11 ` Lee Jones
@ 2013-04-18 10:12 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: arnd, linus.walleij, Lee Jones
Now DMA DT bindings exist and are in use by he MMC and UART drivers, it
should be possible to remove them from the auxdata structure. However,
after doing so the drivers fail. Something must be reliant on the dev
name applied by using auxdata; probably common clk.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 501281c..f56e2da0 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -236,15 +236,15 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
/* Requires call-back bindings. */
OF_DEV_AUXDATA("arm,cortex-a9-pmu", 0, "arm-pmu", &db8500_pmu_platdata),
/* Requires DMA bindings. */
+ OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0", &ssp0_plat),
+ /* Requires clock name bindings. */
OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", NULL),
OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", NULL),
OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", NULL),
- OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0", &ssp0_plat),
OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0", NULL),
OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1", NULL),
OF_DEV_AUXDATA("arm,pl18x", 0x80005000, "sdi2", NULL),
OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4", NULL),
- /* Requires clock name bindings. */
OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
OF_DEV_AUXDATA("st,nomadik-gpio", 0x8000e000, "gpio.2", NULL),
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* [PATCH 32/32] ARM: ux500: Move SDI (MMC) and UART devices under more descriptive heading
@ 2013-04-18 10:12 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Now DMA DT bindings exist and are in use by he MMC and UART drivers, it
should be possible to remove them from the auxdata structure. However,
after doing so the drivers fail. Something must be reliant on the dev
name applied by using auxdata; probably common clk.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 501281c..f56e2da0 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -236,15 +236,15 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
/* Requires call-back bindings. */
OF_DEV_AUXDATA("arm,cortex-a9-pmu", 0, "arm-pmu", &db8500_pmu_platdata),
/* Requires DMA bindings. */
+ OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0", &ssp0_plat),
+ /* Requires clock name bindings. */
OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", NULL),
OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", NULL),
OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", NULL),
- OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0", &ssp0_plat),
OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0", NULL),
OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1", NULL),
OF_DEV_AUXDATA("arm,pl18x", 0x80005000, "sdi2", NULL),
OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4", NULL),
- /* Requires clock name bindings. */
OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
OF_DEV_AUXDATA("st,nomadik-gpio", 0x8000e000, "gpio.2", NULL),
--
1.7.10.4
^ permalink raw reply related [flat|nested] 337+ messages in thread* Re: [PATCH 32/32] ARM: ux500: Move SDI (MMC) and UART devices under more descriptive heading
2013-04-18 10:12 ` Lee Jones
@ 2013-04-25 11:46 ` Linus Walleij
-1 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:46 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Now DMA DT bindings exist and are in use by he MMC and UART drivers, it
> should be possible to remove them from the auxdata structure. However,
> after doing so the drivers fail. Something must be reliant on the dev
> name applied by using auxdata; probably common clk.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
You can remove "probably" from that sentence. Common clock is
still relying on dev_name() to match the device name.
There are some example of how to fix this, I recently sent a patch
series fixing DT probed clocks for the Nomadik, check it out.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 32/32] ARM: ux500: Move SDI (MMC) and UART devices under more descriptive heading
@ 2013-04-25 11:46 ` Linus Walleij
0 siblings, 0 replies; 337+ messages in thread
From: Linus Walleij @ 2013-04-25 11:46 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Now DMA DT bindings exist and are in use by he MMC and UART drivers, it
> should be possible to remove them from the auxdata structure. However,
> after doing so the drivers fail. Something must be reliant on the dev
> name applied by using auxdata; probably common clk.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
You can remove "probably" from that sentence. Common clock is
still relying on dev_name() to match the device name.
There are some example of how to fix this, I recently sent a patch
series fixing DT probed clocks for the Nomadik, check it out.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 337+ messages in thread
* Re: [PATCH 32/32] ARM: ux500: Move SDI (MMC) and UART devices under more descriptive heading
2013-04-25 11:46 ` Linus Walleij
@ 2013-04-26 13:42 ` Lee Jones
-1 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-26 13:42 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-kernel, Arnd Bergmann, Linus WALLEIJ
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > Now DMA DT bindings exist and are in use by he MMC and UART drivers, it
> > should be possible to remove them from the auxdata structure. However,
> > after doing so the drivers fail. Something must be reliant on the dev
> > name applied by using auxdata; probably common clk.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> You can remove "probably" from that sentence. Common clock is
> still relying on dev_name() to match the device name.
>
> There are some example of how to fix this, I recently sent a patch
> series fixing DT probed clocks for the Nomadik, check it out.
You could have me some time here by giving me the $SUBJECT. :)
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread
* [PATCH 32/32] ARM: ux500: Move SDI (MMC) and UART devices under more descriptive heading
@ 2013-04-26 13:42 ` Lee Jones
0 siblings, 0 replies; 337+ messages in thread
From: Lee Jones @ 2013-04-26 13:42 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 25 Apr 2013, Linus Walleij wrote:
> On Thu, Apr 18, 2013 at 12:12 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > Now DMA DT bindings exist and are in use by he MMC and UART drivers, it
> > should be possible to remove them from the auxdata structure. However,
> > after doing so the drivers fail. Something must be reliant on the dev
> > name applied by using auxdata; probably common clk.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> You can remove "probably" from that sentence. Common clock is
> still relying on dev_name() to match the device name.
>
> There are some example of how to fix this, I recently sent a patch
> series fixing DT probed clocks for the Nomadik, check it out.
You could have me some time here by giving me the $SUBJECT. :)
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 337+ messages in thread