2013-04-30 15:41:51

by Lee Jones

[permalink] [raw]
Subject: [PATCH 1/5] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT

At this moment in time the memcpy channels which can be used by the D40
are fixed, as each supported platform in Mainline uses the same ones.
However, platforms do exist which don't follow this convention, so
these will need to be tailored. Fortunately, these platforms will be DT
only, so this change has very little impact on platform data.

Cc: Vinod Koul <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Per Forlin <[email protected]>
Cc: Rabin Vincent <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
.../devicetree/bindings/dma/ste-dma40.txt | 4 ++
drivers/dma/ste_dma40.c | 40 +++++++++++++++-----
include/linux/platform_data/dma-ste-dma40.h | 2 +
3 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
index 2679a87..02e87e7 100644
--- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -6,6 +6,8 @@ Required properties:
- 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>
+- memcpy-channels: Channels to be used for memcpy
+- memcpy-num-chans: Number of channels to be used for memcpy

Optional properties:
- dma-channels: Number of channels supported by hardware - if not present
@@ -21,6 +23,8 @@ Example:
interrupts = <0 25 0x4>;

#dma-cells = <2>;
+ memcpy-channels = <56, 57, 58, 59, 60>;
+ memcpy-num-chans = <5>;
dma-channels = <8>;
};

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index d5c39e4..4769141 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -58,8 +58,10 @@
#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE 0

+#define D40_MEMCPY_MAX_CHANS 8
+
/* Reserved event lines for memcpy only. */
-static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
+static int dma40_memcpy_channels[D40_MEMCPY_MAX_CHANS] = { 56, 57, 58, 59, 60 };

/* Default configuration for physcial memcpy */
struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
@@ -508,6 +510,8 @@ struct d40_gen_dmac {
* @phy_start: Physical memory start of the DMA registers.
* @phy_size: Size of the DMA register map.
* @irq: The IRQ number.
+ * @num_memcpy_chans: The number of channels used for memcpy (mem-to-mem
+ * transfers).
* @num_phy_chans: The number of physical channels. Read from HW. This
* is the number of available channels for this driver, not counting "Secure
* mode" allocated physical channels.
@@ -551,6 +555,7 @@ struct d40_base {
phys_addr_t phy_start;
resource_size_t phy_size;
int irq;
+ int num_memcpy_chans;
int num_phy_chans;
int num_log_chans;
struct device_dma_parameters dma_parms;
@@ -2920,7 +2925,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, ARRAY_SIZE(dma40_memcpy_channels));
+ base->num_log_chans, base->num_memcpy_chans);

dma_cap_zero(base->dma_memcpy.cap_mask);
dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
@@ -3121,6 +3126,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
struct d40_base *base = NULL;
int num_log_chans = 0;
int num_phy_chans;
+ int num_memcpy_chans;
int clk_ret = -EINVAL;
int i;
u32 pid;
@@ -3191,6 +3197,12 @@ 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;

+ /* The number of channels used for memcpy */
+ if (plat_data->num_of_memcpy_chans)
+ num_memcpy_chans = plat_data->num_of_memcpy_chans;
+ else
+ num_memcpy_chans = ARRAY_SIZE(dma40_memcpy_channels);
+
num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;

dev_info(&pdev->dev,
@@ -3198,7 +3210,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
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)) *
+ (num_phy_chans + num_log_chans + num_memcpy_chans) *
sizeof(struct d40_chan), GFP_KERNEL);

if (base == NULL) {
@@ -3208,6 +3220,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)

base->rev = rev;
base->clk = clk;
+ base->num_memcpy_chans = num_memcpy_chans;
base->num_phy_chans = num_phy_chans;
base->num_log_chans = num_log_chans;
base->phy_start = res->start;
@@ -3451,12 +3464,7 @@ static int __init d40_of_probe(struct platform_device *pdev,
struct device_node *np)
{
struct stedma40_platform_data *pdata;
-
- /*
- * 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.
- */
+ int num_memcpy = 0;

pdata = devm_kzalloc(&pdev->dev,
sizeof(struct stedma40_platform_data),
@@ -3464,6 +3472,20 @@ static int __init d40_of_probe(struct platform_device *pdev,
if (!pdata)
return -ENOMEM;

+ of_property_read_u32(np, "memcpy-num-chans", &num_memcpy);
+
+ if (num_memcpy > D40_MEMCPY_MAX_CHANS || num_memcpy <= 0) {
+ d40_err(&pdev->dev,
+ "Invalid number of memcpy channels specified (%d)\n",
+ num_memcpy);
+ return -EINVAL;
+ }
+ pdata->num_of_memcpy_chans = num_memcpy;
+
+ of_property_read_u32_array(np, "memcpy-channels",
+ dma40_memcpy_channels,
+ num_memcpy);
+
pdev->dev.platform_data = pdata;

return 0;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index ceba6dc..1bb9b18 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -132,6 +132,7 @@ struct stedma40_chan_cfg {
* @num_of_soft_lli_chans: The number of channels that needs to be configured
* to use SoftLLI.
* @use_esram_lcla: flag for mapping the lcla into esram region
+ * @num_of_memcpy_chans: The number of channels reserved for memcpy.
* @num_of_phy_chans: The number of physical channels implemented in HW.
* 0 means reading the number of channels from DMA HW but this is only valid
* for 'multiple of 4' channels, like 8.
@@ -141,6 +142,7 @@ struct stedma40_platform_data {
int *soft_lli_chans;
int num_of_soft_lli_chans;
bool use_esram_lcla;
+ int num_of_memcpy_chans;
int num_of_phy_chans;
};

--
1.7.10.4


2013-04-30 15:41:59

by Lee Jones

[permalink] [raw]
Subject: [PATCH 2/5] ARM: ux500: Pass DMA memcpy channels though Device Tree

It's not possible to configure memcpy channels dynamically with DT.
We're providing them despite the fact that they're the same as the
hard-coded channels, as they will be removed once the u8500 platform
goes DT-only.

Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/boot/dts/dbx5x0.dtsi | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 838214c..8e80ef7 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -218,6 +218,8 @@
interrupts = <0 25 0x4>;

#dma-cells = <3>;
+ memcpy-channels = <56 57 58 59 60>;
+ memcpy-num-chans = <5>;
};

prcmu: prcmu@80157000 {
--
1.7.10.4

2013-04-30 15:42:08

by Lee Jones

[permalink] [raw]
Subject: [PATCH 5/5] dmaengine: ste_dma40: Fetch disabled channels from DT

Some platforms have channels which are not available for normal use.
This information is currently passed though platform data in internal
BSP kernels. Once those platforms land, they'll need to configure them
appropriately, so we may as well add the infrastructure.

Cc: Vinod Koul <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Per Forlin <[email protected]>
Cc: Rabin Vincent <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
Documentation/devicetree/bindings/dma/ste-dma40.txt | 4 ++++
drivers/dma/ste_dma40.c | 16 +++++++++++++++-
2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
index 02e87e7..f234c75 100644
--- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -12,6 +12,8 @@ Required properties:
Optional properties:
- dma-channels: Number of channels supported by hardware - if not present
the driver will attempt to obtain the information from H/W
+- disabled-channels: Channels which can not be used
+- disabled-num-chans: Number of channels which can not be used

Example:

@@ -25,6 +27,8 @@ Example:
#dma-cells = <2>;
memcpy-channels = <56, 57, 58, 59, 60>;
memcpy-num-chans = <5>;
+ disabled-channels = <12>;
+ disabled-num-chans = <1>;
dma-channels = <8>;
};

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index dbdd67b..b045eb2 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3464,7 +3464,7 @@ static int __init d40_of_probe(struct platform_device *pdev,
struct device_node *np)
{
struct stedma40_platform_data *pdata;
- int num_phy = 0, num_memcpy = 0;
+ int num_phy = 0, num_memcpy = 0, num_disabled = 0;

pdata = devm_kzalloc(&pdev->dev,
sizeof(struct stedma40_platform_data),
@@ -3493,6 +3493,20 @@ static int __init d40_of_probe(struct platform_device *pdev,

pdev->dev.platform_data = pdata;

+ of_property_read_u32(np, "disabled-num-chans", &num_disabled);
+
+ if (num_disabled > STEDMA40_MAX_PHYS || num_disabled < 0) {
+ d40_err(&pdev->dev,
+ "Invalid number of disabled channels specified (%d)\n",
+ num_disabled);
+ return -EINVAL;
+ }
+
+ of_property_read_u32_array(np, "disabled-channels",
+ pdata->disabled_channels,
+ num_disabled);
+ pdata->disabled_channels[num_disabled] = -1;
+
return 0;
}

--
1.7.10.4

2013-04-30 15:41:56

by Lee Jones

[permalink] [raw]
Subject: [PATCH 3/5] ARM: ux500: Stop passing DMA platform data though AUXDATA

The DMA platform data is now empty due to some recent refactoring,
so there is no longer a requirement to pass it though.

Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/mach-ux500/cpu-db8500.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index a2c83c2..2b6cbde 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -264,8 +264,7 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
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),
+ OF_DEV_AUXDATA("stericsson,db8500-dma40", 0x801C0000, "dma40.0", NULL),
{},
};

--
1.7.10.4

2013-04-30 15:42:40

by Lee Jones

[permalink] [raw]
Subject: [PATCH 4/5] dmaengine: ste_dma40: Fetch the number of physical channels from DT

Some platforms insist on obscure physical channel availability. This
information is currently passed though platform data in internal BSP
kernels. Once those platforms land, they'll need to configure them
appropriately, so we may as well add the infrastructure.

Cc: Vinod Koul <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Per Forlin <[email protected]>
Cc: Rabin Vincent <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
---
drivers/dma/ste_dma40.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 4769141..dbdd67b 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3464,7 +3464,7 @@ static int __init d40_of_probe(struct platform_device *pdev,
struct device_node *np)
{
struct stedma40_platform_data *pdata;
- int num_memcpy = 0;
+ int num_phy = 0, num_memcpy = 0;

pdata = devm_kzalloc(&pdev->dev,
sizeof(struct stedma40_platform_data),
@@ -3472,6 +3472,11 @@ static int __init d40_of_probe(struct platform_device *pdev,
if (!pdata)
return -ENOMEM;

+ /* If absent this value will be obtained from h/w. */
+ of_property_read_u32(np, "dma-channels", &num_phy);
+ if (num_phy > 0)
+ pdata->num_of_phy_chans = num_phy;
+
of_property_read_u32(np, "memcpy-num-chans", &num_memcpy);

if (num_memcpy > D40_MEMCPY_MAX_CHANS || num_memcpy <= 0) {
--
1.7.10.4

2013-04-30 20:43:11

by Arnd Bergmann

[permalink] [raw]
Subject: Re: [PATCH 1/5] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT

On Tuesday 30 April 2013, Lee Jones wrote:
> @@ -6,6 +6,8 @@ Required properties:
> - 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>
> +- memcpy-channels: Channels to be used for memcpy
> +- memcpy-num-chans: Number of channels to be used for memcpy
>
> Optional properties:
> - dma-channels: Number of channels supported by hardware - if not present
> @@ -21,6 +23,8 @@ Example:
> interrupts = <0 25 0x4>;
>
> #dma-cells = <2>;
> + memcpy-channels = <56, 57, 58, 59, 60>;
> + memcpy-num-chans = <5>;
> dma-channels = <8>;
> };
>

I think you should remove the memcpy-num-chans property and instead evaluate the
length of the memcpy-channels property. Aside from this, it looks fine.

Arnd

2013-04-30 20:43:09

by Arnd Bergmann

[permalink] [raw]
Subject: Re: [PATCH 3/5] ARM: ux500: Stop passing DMA platform data though AUXDATA

On Tuesday 30 April 2013, Lee Jones wrote:
> The DMA platform data is now empty due to some recent refactoring,
> so there is no longer a requirement to pass it though.
>
> Signed-off-by: Lee Jones <[email protected]>

Acked-by: Arnd Bergmann <[email protected]>

2013-05-01 09:51:19

by Lee Jones

[permalink] [raw]
Subject: Re: [PATCH 1/5] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT

At this moment in time the memcpy channels which can be used by the D40
are fixed, as each supported platform in Mainline uses the same ones.
However, platforms do exist which don't follow this convention, so
these will need to be tailored. Fortunately, these platforms will be DT
only, so this change has very little impact on platform data.

Cc: Vinod Koul <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Per Forlin <[email protected]>
Cc: Rabin Vincent <[email protected]>
Signed-off-by: Lee Jones <[email protected]>

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
index 2679a87..aa272d8 100644
--- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -6,6 +6,7 @@ Required properties:
- 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>
+- memcpy-channels: Channels to be used for memcpy

Optional properties:
- dma-channels: Number of channels supported by hardware - if not present
@@ -21,6 +22,7 @@ Example:
interrupts = <0 25 0x4>;

#dma-cells = <2>;
+ memcpy-channels = <56 57 58 59 60>;
dma-channels = <8>;
};

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index d5c39e4..0077184 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -58,8 +58,10 @@
#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE 0

+#define D40_MEMCPY_MAX_CHANS 8
+
/* Reserved event lines for memcpy only. */
-static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
+static int dma40_memcpy_channels[D40_MEMCPY_MAX_CHANS] = { 56, 57, 58, 59, 60 };

/* Default configuration for physcial memcpy */
struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
@@ -508,6 +510,8 @@ struct d40_gen_dmac {
* @phy_start: Physical memory start of the DMA registers.
* @phy_size: Size of the DMA register map.
* @irq: The IRQ number.
+ * @num_memcpy_chans: The number of channels used for memcpy (mem-to-mem
+ * transfers).
* @num_phy_chans: The number of physical channels. Read from HW. This
* is the number of available channels for this driver, not counting "Secure
* mode" allocated physical channels.
@@ -551,6 +555,7 @@ struct d40_base {
phys_addr_t phy_start;
resource_size_t phy_size;
int irq;
+ int num_memcpy_chans;
int num_phy_chans;
int num_log_chans;
struct device_dma_parameters dma_parms;
@@ -2920,7 +2925,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, ARRAY_SIZE(dma40_memcpy_channels));
+ base->num_log_chans, base->num_memcpy_chans);

dma_cap_zero(base->dma_memcpy.cap_mask);
dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
@@ -3121,6 +3126,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
struct d40_base *base = NULL;
int num_log_chans = 0;
int num_phy_chans;
+ int num_memcpy_chans;
int clk_ret = -EINVAL;
int i;
u32 pid;
@@ -3191,6 +3197,12 @@ 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;

+ /* The number of channels used for memcpy */
+ if (plat_data->num_of_memcpy_chans)
+ num_memcpy_chans = plat_data->num_of_memcpy_chans;
+ else
+ num_memcpy_chans = ARRAY_SIZE(dma40_memcpy_channels);
+
num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;

dev_info(&pdev->dev,
@@ -3198,7 +3210,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
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)) *
+ (num_phy_chans + num_log_chans + num_memcpy_chans) *
sizeof(struct d40_chan), GFP_KERNEL);

if (base == NULL) {
@@ -3208,6 +3220,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)

base->rev = rev;
base->clk = clk;
+ base->num_memcpy_chans = num_memcpy_chans;
base->num_phy_chans = num_phy_chans;
base->num_log_chans = num_log_chans;
base->phy_start = res->start;
@@ -3451,12 +3464,8 @@ static int __init d40_of_probe(struct platform_device *pdev,
struct device_node *np)
{
struct stedma40_platform_data *pdata;
-
- /*
- * 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.
- */
+ int num_memcpy = 0;
+ const const __be32 *list;

pdata = devm_kzalloc(&pdev->dev,
sizeof(struct stedma40_platform_data),
@@ -3464,6 +3473,21 @@ static int __init d40_of_probe(struct platform_device *pdev,
if (!pdata)
return -ENOMEM;

+ list = of_get_property(np, "memcpy-channels", &num_memcpy);
+ num_memcpy /= sizeof(*list);
+
+ if (num_memcpy > D40_MEMCPY_MAX_CHANS || num_memcpy <= 0) {
+ d40_err(&pdev->dev,
+ "Invalid number of memcpy channels specified (%d)\n",
+ num_memcpy);
+ return -EINVAL;
+ }
+ pdata->num_of_memcpy_chans = num_memcpy;
+
+ of_property_read_u32_array(np, "memcpy-channels",
+ dma40_memcpy_channels,
+ num_memcpy);
+
pdev->dev.platform_data = pdata;

return 0;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index ceba6dc..1bb9b18 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -132,6 +132,7 @@ struct stedma40_chan_cfg {
* @num_of_soft_lli_chans: The number of channels that needs to be configured
* to use SoftLLI.
* @use_esram_lcla: flag for mapping the lcla into esram region
+ * @num_of_memcpy_chans: The number of channels reserved for memcpy.
* @num_of_phy_chans: The number of physical channels implemented in HW.
* 0 means reading the number of channels from DMA HW but this is only valid
* for 'multiple of 4' channels, like 8.
@@ -141,6 +142,7 @@ struct stedma40_platform_data {
int *soft_lli_chans;
int num_of_soft_lli_chans;
bool use_esram_lcla;
+ int num_of_memcpy_chans;
int num_of_phy_chans;
};

2013-05-01 09:52:56

by Lee Jones

[permalink] [raw]
Subject: [PATCH 1/5 v2] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT

At this moment in time the memcpy channels which can be used by the D40
are fixed, as each supported platform in Mainline uses the same ones.
However, platforms do exist which don't follow this convention, so
these will need to be tailored. Fortunately, these platforms will be DT
only, so this change has very little impact on platform data.

Cc: Vinod Koul <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Per Forlin <[email protected]>
Cc: Rabin Vincent <[email protected]>
Signed-off-by: Lee Jones <[email protected]>

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
index 2679a87..aa272d8 100644
--- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -6,6 +6,7 @@ Required properties:
- 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>
+- memcpy-channels: Channels to be used for memcpy

Optional properties:
- dma-channels: Number of channels supported by hardware - if not present
@@ -21,6 +22,7 @@ Example:
interrupts = <0 25 0x4>;

#dma-cells = <2>;
+ memcpy-channels = <56 57 58 59 60>;
dma-channels = <8>;
};

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index d5c39e4..0077184 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -58,8 +58,10 @@
#define D40_ALLOC_PHY BIT(30)
#define D40_ALLOC_LOG_FREE 0

+#define D40_MEMCPY_MAX_CHANS 8
+
/* Reserved event lines for memcpy only. */
-static int dma40_memcpy_channels[] = { 56, 57, 58, 59, 60 };
+static int dma40_memcpy_channels[D40_MEMCPY_MAX_CHANS] = { 56, 57, 58, 59, 60 };

/* Default configuration for physcial memcpy */
struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
@@ -508,6 +510,8 @@ struct d40_gen_dmac {
* @phy_start: Physical memory start of the DMA registers.
* @phy_size: Size of the DMA register map.
* @irq: The IRQ number.
+ * @num_memcpy_chans: The number of channels used for memcpy (mem-to-mem
+ * transfers).
* @num_phy_chans: The number of physical channels. Read from HW. This
* is the number of available channels for this driver, not counting "Secure
* mode" allocated physical channels.
@@ -551,6 +555,7 @@ struct d40_base {
phys_addr_t phy_start;
resource_size_t phy_size;
int irq;
+ int num_memcpy_chans;
int num_phy_chans;
int num_log_chans;
struct device_dma_parameters dma_parms;
@@ -2920,7 +2925,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, ARRAY_SIZE(dma40_memcpy_channels));
+ base->num_log_chans, base->num_memcpy_chans);

dma_cap_zero(base->dma_memcpy.cap_mask);
dma_cap_set(DMA_MEMCPY, base->dma_memcpy.cap_mask);
@@ -3121,6 +3126,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
struct d40_base *base = NULL;
int num_log_chans = 0;
int num_phy_chans;
+ int num_memcpy_chans;
int clk_ret = -EINVAL;
int i;
u32 pid;
@@ -3191,6 +3197,12 @@ 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;

+ /* The number of channels used for memcpy */
+ if (plat_data->num_of_memcpy_chans)
+ num_memcpy_chans = plat_data->num_of_memcpy_chans;
+ else
+ num_memcpy_chans = ARRAY_SIZE(dma40_memcpy_channels);
+
num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;

dev_info(&pdev->dev,
@@ -3198,7 +3210,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)
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)) *
+ (num_phy_chans + num_log_chans + num_memcpy_chans) *
sizeof(struct d40_chan), GFP_KERNEL);

if (base == NULL) {
@@ -3208,6 +3220,7 @@ static struct d40_base * __init d40_hw_detect_init(struct platform_device *pdev)

base->rev = rev;
base->clk = clk;
+ base->num_memcpy_chans = num_memcpy_chans;
base->num_phy_chans = num_phy_chans;
base->num_log_chans = num_log_chans;
base->phy_start = res->start;
@@ -3451,12 +3464,8 @@ static int __init d40_of_probe(struct platform_device *pdev,
struct device_node *np)
{
struct stedma40_platform_data *pdata;
-
- /*
- * 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.
- */
+ int num_memcpy = 0;
+ const const __be32 *list;

pdata = devm_kzalloc(&pdev->dev,
sizeof(struct stedma40_platform_data),
@@ -3464,6 +3473,21 @@ static int __init d40_of_probe(struct platform_device *pdev,
if (!pdata)
return -ENOMEM;

+ list = of_get_property(np, "memcpy-channels", &num_memcpy);
+ num_memcpy /= sizeof(*list);
+
+ if (num_memcpy > D40_MEMCPY_MAX_CHANS || num_memcpy <= 0) {
+ d40_err(&pdev->dev,
+ "Invalid number of memcpy channels specified (%d)\n",
+ num_memcpy);
+ return -EINVAL;
+ }
+ pdata->num_of_memcpy_chans = num_memcpy;
+
+ of_property_read_u32_array(np, "memcpy-channels",
+ dma40_memcpy_channels,
+ num_memcpy);
+
pdev->dev.platform_data = pdata;

return 0;
diff --git a/include/linux/platform_data/dma-ste-dma40.h b/include/linux/platform_data/dma-ste-dma40.h
index ceba6dc..1bb9b18 100644
--- a/include/linux/platform_data/dma-ste-dma40.h
+++ b/include/linux/platform_data/dma-ste-dma40.h
@@ -132,6 +132,7 @@ struct stedma40_chan_cfg {
* @num_of_soft_lli_chans: The number of channels that needs to be configured
* to use SoftLLI.
* @use_esram_lcla: flag for mapping the lcla into esram region
+ * @num_of_memcpy_chans: The number of channels reserved for memcpy.
* @num_of_phy_chans: The number of physical channels implemented in HW.
* 0 means reading the number of channels from DMA HW but this is only valid
* for 'multiple of 4' channels, like 8.
@@ -141,6 +142,7 @@ struct stedma40_platform_data {
int *soft_lli_chans;
int num_of_soft_lli_chans;
bool use_esram_lcla;
+ int num_of_memcpy_chans;
int num_of_phy_chans;
};

2013-05-01 09:54:19

by Lee Jones

[permalink] [raw]
Subject: [PATCH 5/5 v2] dmaengine: ste_dma40: Fetch disabled channels from DT

Some platforms have channels which are not available for normal use.
This information is currently passed though platform data in internal
BSP kernels. Once those platforms land, they'll need to configure them
appropriately, so we may as well add the infrastructure.

Cc: Vinod Koul <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Per Forlin <[email protected]>
Cc: Rabin Vincent <[email protected]>
Signed-off-by: Lee Jones <[email protected]>

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
index aa272d8..bea5b73 100644
--- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -11,6 +11,7 @@ Required properties:
Optional properties:
- dma-channels: Number of channels supported by hardware - if not present
the driver will attempt to obtain the information from H/W
+- disabled-channels: Channels which can not be used

Example:

@@ -23,6 +24,7 @@ Example:

#dma-cells = <2>;
memcpy-channels = <56 57 58 59 60>;
+ disabled-channels = <12>;
dma-channels = <8>;
};

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index b14de16..658b53b 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -3464,7 +3464,7 @@ static int __init d40_of_probe(struct platform_device *pdev,
struct device_node *np)
{
struct stedma40_platform_data *pdata;
- int num_phy = 0, num_memcpy = 0;
+ int num_phy = 0, num_memcpy = 0, num_disabled = 0;
const const __be32 *list;

pdata = devm_kzalloc(&pdev->dev,
@@ -3493,6 +3493,21 @@ static int __init d40_of_probe(struct platform_device *pdev,
dma40_memcpy_channels,
num_memcpy);

+ list = of_get_property(np, "disabled-channels", &num_disabled);
+ num_disabled /= sizeof(*list);
+
+ if (num_disabled > STEDMA40_MAX_PHYS || num_disabled < 0) {
+ d40_err(&pdev->dev,
+ "Invalid number of disabled channels specified (%d)\n",
+ num_disabled);
+ return -EINVAL;
+ }
+
+ of_property_read_u32_array(np, "disabled-channels",
+ pdata->disabled_channels,
+ num_disabled);
+ pdata->disabled_channels[num_disabled] = -1;
+
pdev->dev.platform_data = pdata;

return 0;

2013-05-01 10:27:57

by Arnd Bergmann

[permalink] [raw]
Subject: Re: [PATCH 5/5 v2] dmaengine: ste_dma40: Fetch disabled channels from DT

On Wednesday 01 May 2013, Lee Jones wrote:
> Some platforms have channels which are not available for normal use.
> This information is currently passed though platform data in internal
> BSP kernels. Once those platforms land, they'll need to configure them
> appropriately, so we may as well add the infrastructure.
>
> Cc: Vinod Koul <[email protected]>
> Cc: Dan Williams <[email protected]>
> Cc: Per Forlin <[email protected]>
> Cc: Rabin Vincent <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>

Acked-by: Arnd Bergmann <[email protected]>

2013-05-01 10:28:11

by Arnd Bergmann

[permalink] [raw]
Subject: Re: [PATCH 1/5 v2] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT

On Wednesday 01 May 2013, Lee Jones wrote:
> At this moment in time the memcpy channels which can be used by the D40
> are fixed, as each supported platform in Mainline uses the same ones.
> However, platforms do exist which don't follow this convention, so
> these will need to be tailored. Fortunately, these platforms will be DT
> only, so this change has very little impact on platform data.
>
> Cc: Vinod Koul <[email protected]>
> Cc: Dan Williams <[email protected]>
> Cc: Per Forlin <[email protected]>
> Cc: Rabin Vincent <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>

Acked-by: Arnd Bergmann <[email protected]>

2013-05-02 11:59:57

by Srinidhi Kasagar

[permalink] [raw]
Subject: Re: [PATCH 3/5] ARM: ux500: Stop passing DMA platform data though AUXDATA

On Tue, Apr 30, 2013 at 17:41:35 +0200, Lee Jones wrote:
> The DMA platform data is now empty due to some recent refactoring,
> so there is no longer a requirement to pass it though.
>
> Signed-off-by: Lee Jones <[email protected]>
> ---
> arch/arm/mach-ux500/cpu-db8500.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
> index a2c83c2..2b6cbde 100644
> --- a/arch/arm/mach-ux500/cpu-db8500.c
> +++ b/arch/arm/mach-ux500/cpu-db8500.c
> @@ -264,8 +264,7 @@ static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
> 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),
> + OF_DEV_AUXDATA("stericsson,db8500-dma40", 0x801C0000, "dma40.0", NULL),
> {},
> };

Acked-by:srinidhi kasagar <[email protected]>

srinidhi

2013-05-03 11:16:29

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 1/5 v2] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT

On Wed, May 1, 2013 at 11:52 AM, Lee Jones <[email protected]> wrote:

> At this moment in time the memcpy channels which can be used by the D40
> are fixed, as each supported platform in Mainline uses the same ones.
> However, platforms do exist which don't follow this convention, so
> these will need to be tailored. Fortunately, these platforms will be DT
> only, so this change has very little impact on platform data.
>
> Cc: Vinod Koul <[email protected]>
> Cc: Dan Williams <[email protected]>
> Cc: Per Forlin <[email protected]>
> Cc: Rabin Vincent <[email protected]>
> Signed-off-by: Lee Jones <[email protected]>

Real nice!

But can you split this in two patches: one that changes
drivers/dma/ste_dma40* and one sequel patch that changes
Documentation/* and arch/arm/boot/dts/* so I can merge them
out-of-order?

I am trying this development cycle to split changes to the
device trees and bindings off from the rest of the patches
becaused it caused me a mess last cycle.

Yours,
Linus Walleij

2013-05-03 11:57:46

by Lee Jones

[permalink] [raw]
Subject: Re: [PATCH 1/5 v2] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT

On Fri, 03 May 2013, Linus Walleij wrote:

> On Wed, May 1, 2013 at 11:52 AM, Lee Jones <[email protected]> wrote:
>
> > At this moment in time the memcpy channels which can be used by the D40
> > are fixed, as each supported platform in Mainline uses the same ones.
> > However, platforms do exist which don't follow this convention, so
> > these will need to be tailored. Fortunately, these platforms will be DT
> > only, so this change has very little impact on platform data.
> >
> > Cc: Vinod Koul <[email protected]>
> > Cc: Dan Williams <[email protected]>
> > Cc: Per Forlin <[email protected]>
> > Cc: Rabin Vincent <[email protected]>
> > Signed-off-by: Lee Jones <[email protected]>
>
> Real nice!
>
> But can you split this in two patches: one that changes
> drivers/dma/ste_dma40* and one sequel patch that changes
> Documentation/* and arch/arm/boot/dts/* so I can merge them
> out-of-order?
>
> I am trying this development cycle to split changes to the
> device trees and bindings off from the rest of the patches
> becaused it caused me a mess last cycle.

I was under the impression that the documentation went with the
bindings, rather than the Device Tree. Am I wrong?

--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

2013-05-03 12:03:02

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 1/5 v2] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT

On Fri, May 3, 2013 at 1:57 PM, Lee Jones <[email protected]> wrote:
> On Fri, 03 May 2013, Linus Walleij wrote:
>
>> On Wed, May 1, 2013 at 11:52 AM, Lee Jones <[email protected]> wrote:
>>
>> > At this moment in time the memcpy channels which can be used by the D40
>> > are fixed, as each supported platform in Mainline uses the same ones.
>> > However, platforms do exist which don't follow this convention, so
>> > these will need to be tailored. Fortunately, these platforms will be DT
>> > only, so this change has very little impact on platform data.
>> >
>> > Cc: Vinod Koul <[email protected]>
>> > Cc: Dan Williams <[email protected]>
>> > Cc: Per Forlin <[email protected]>
>> > Cc: Rabin Vincent <[email protected]>
>> > Signed-off-by: Lee Jones <[email protected]>
>>
>> Real nice!
>>
>> But can you split this in two patches: one that changes
>> drivers/dma/ste_dma40* and one sequel patch that changes
>> Documentation/* and arch/arm/boot/dts/* so I can merge them
>> out-of-order?
>>
>> I am trying this development cycle to split changes to the
>> device trees and bindings off from the rest of the patches
>> becaused it caused me a mess last cycle.
>
> I was under the impression that the documentation went with the
> bindings, rather than the Device Tree. Am I wrong?

No you're right. The documentation with the bindings and the
patch to the driver...

Then just arch/arm/boot/dts/* separately.

The latter is where I have all my trouble and screwup...

(However when we break the devicetree data out of the kernel
and into its own git we will have to follow the pattern above with
a patch of bindings+DT changes and another one in parallell
changing the kernel, but that is for a more advanced age.)

Yours,
Linus Walleij

2013-05-03 12:11:42

by Lee Jones

[permalink] [raw]
Subject: Re: [PATCH 1/5 v2] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT

On Fri, 03 May 2013, Linus Walleij wrote:

> On Fri, May 3, 2013 at 1:57 PM, Lee Jones <[email protected]> wrote:
> > On Fri, 03 May 2013, Linus Walleij wrote:
> >
> >> On Wed, May 1, 2013 at 11:52 AM, Lee Jones <[email protected]> wrote:
> >>
> >> > At this moment in time the memcpy channels which can be used by the D40
> >> > are fixed, as each supported platform in Mainline uses the same ones.
> >> > However, platforms do exist which don't follow this convention, so
> >> > these will need to be tailored. Fortunately, these platforms will be DT
> >> > only, so this change has very little impact on platform data.
> >> >
> >> > Cc: Vinod Koul <[email protected]>
> >> > Cc: Dan Williams <[email protected]>
> >> > Cc: Per Forlin <[email protected]>
> >> > Cc: Rabin Vincent <[email protected]>
> >> > Signed-off-by: Lee Jones <[email protected]>
> >>
> >> Real nice!
> >>
> >> But can you split this in two patches: one that changes
> >> drivers/dma/ste_dma40* and one sequel patch that changes
> >> Documentation/* and arch/arm/boot/dts/* so I can merge them
> >> out-of-order?
> >>
> >> I am trying this development cycle to split changes to the
> >> device trees and bindings off from the rest of the patches
> >> becaused it caused me a mess last cycle.
> >
> > I was under the impression that the documentation went with the
> > bindings, rather than the Device Tree. Am I wrong?
>
> No you're right. The documentation with the bindings and the
> patch to the driver...
>
> Then just arch/arm/boot/dts/* separately.

I'm confused, that's how it is already:

Documentation/devicetree/bindings/dma/ste-dma40.txt | 2 ++
drivers/dma/ste_dma40.c | 42 +++++++++++++++++++++++++++++++++---------
include/linux/platform_data/dma-ste-dma40.h | 2 ++
3 files changed, 37 insertions(+), 9 deletions(-)

Are you getting enough sleep? ;)

> The latter is where I have all my trouble and screwup...
>
> (However when we break the devicetree data out of the kernel
> and into its own git we will have to follow the pattern above with
> a patch of bindings+DT changes and another one in parallell
> changing the kernel, but that is for a more advanced age.)
>
> Yours,
> Linus Walleij

--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

2013-05-03 13:42:40

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 1/5 v2] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT

On Fri, May 3, 2013 at 2:11 PM, Lee Jones <[email protected]> wrote:

>> Then just arch/arm/boot/dts/* separately.
>
> I'm confused, that's how it is already:

Hm haha yes :-)

> Are you getting enough sleep? ;)

It's more like I'm getting too many patch series...

Yours,
Linus Walleij