Re: [PATCH 4/4] DMA: PL330: add device tree property for DMA_MEMCPY capability
On Fri, Nov 30, 2012 at 4:26 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Thank you for explaining it. Here is a patch implementing the idea: From: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Subject: [PATCH] DMA: PL330: add peripherals map to the device tree Add device tree (DT) property (peri-map) for storing indices of peripherals connected to DMAC and fix DT nodes of client drivers to use 'dma peripheral id' instead of 'dma request id'. Also instead of setting DMA_MEMCPY capability unconditionally in pl330_probe() do it only when peri-map DT property is present (idea from Jassi Brar). It fixes the issue on ARM EXYNOS platforms using DT where pdma controller erroneously was used for DMA_MEMCPY operations instead of mdma one (it seems to work correctly but at the cost of worse performance). Sorry, we need to change it as per new generic dma DT bindings http://git.infradead.org/users/vkoul/slave-dma.git/blob/refs/heads/next:/Documentation/devicetree/bindings/dma/dma.txt Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] DMA: PL330: add device tree property for DMA_MEMCPY capability
On Friday 09 November 2012 07:11:30 Jassi Brar wrote:
On 30 October 2012 14:51, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
Hi,
On Monday 29 October 2012 22:45:48 Jassi Brar wrote:
On Mon, Oct 29, 2012 at 10:59 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
* Add device tree (DT) property (pl330,dma-memcpy) for DMA_MEMCPY
capability and instead of setting this capability unconditionally
in pl330_probe() do it only when property is present.
Perhaps we should pass the array of peripheral interfaces via DT, the
lack of which could imply MEMCPY capability ? (while it works, I doubt
if pl330 is supposed to have SLAVE and MEMCPY capabilities in any
instance)
In case of PL330 on EXYNOS4 we have two interfaces with SLAVE capability
and one interface with MEMCPY capability. Could you please explain more
the idea of passing the array of peripherals through DT so we can detect
which interface has MEMCPY capability?
The DT node of a 'pdma' should have the array of indices of
peripherals it caters to (what is currently peri_id of 'struct
dma_pl330_platdata'). The array would be missing in the DT node of
'mdma' since all channels are equal.
During probe if the array, say as property 'peri_map', is missing from
DT node of the dmac, that would imply the dmac is 'mdma' and hence the
pl330.c sets DMA_MEMCPY in its cap_mask. Otherwise the peri_map
implies a 'pdma' and hence SLAVE|CYCLIC is set.
That would also be a step towards discarding struct dma_pl330_platdata.
I don't know if getting rid of struct dma_pl330_platdata is possible
but we still need to come up with some way to pass the needed information
through DT. Do you have an idea how it could be done?
struct dma_pl330_platdata {
u8 nr_valid_peri;
u8 *peri_id;
As explain above, these two should move to DT node of the dma
controller.
dma_cap_mask_t cap_mask;
Should be set in pl330.c : MEMCPY for mdma, SLAVE|CYCLIC for pdma
unsigned mcbuf_sz;
Currently unused and already safe enough default value set in driver.
}
Thank you for explaining it. Here is a patch implementing the idea:
From: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Subject: [PATCH] DMA: PL330: add peripherals map to the device tree
Add device tree (DT) property (peri-map) for storing indices
of peripherals connected to DMAC and fix DT nodes of client
drivers to use 'dma peripheral id' instead of 'dma request id'.
Also instead of setting DMA_MEMCPY capability unconditionally in
pl330_probe() do it only when peri-map DT property is present
(idea from Jassi Brar). It fixes the issue on ARM EXYNOS
platforms using DT where pdma controller erroneously was used
for DMA_MEMCPY operations instead of mdma one (it seems to work
correctly but at the cost of worse performance).
While at it:
- add missing kfree() to pl330_[probe,remove]()
- fix typo in samsung_dmadev_request()
Cc: Jassi Brar jassisinghb...@gmail.com
Cc: Vinod Koul vinod.k...@intel.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Dinh Nguyen dingu...@altera.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
I wonder whether peri-map also needs to be added to following files:
arch/arm/boot/dts/highbank.dts
arch/arm/boot/dts/socfpga.dtsi
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
(since they're also using pl330)?
Documentation/devicetree/bindings/dma/arm-pl330.txt |5
arch/arm/boot/dts/exynos4.dtsi | 21 +-
arch/arm/boot/dts/exynos5250.dtsi | 20 +-
arch/arm/plat-samsung/dma-ops.c |2
arch/arm/plat-samsung/include/plat/dma-pl330.h | 155 +---
drivers/dma/pl330.c | 54 +-
6 files changed, 152 insertions(+), 105 deletions(-)
Index: b/Documentation/devicetree/bindings/dma/arm-pl330.txt
===
--- a/Documentation/devicetree/bindings/dma/arm-pl330.txt 2012-11-28
17:41:36.997626033 +0100
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt 2012-11-28
17:42:23.433626905 +0100
@@ -11,6 +11,7 @@ Required properties:
Optional properties:
- dma-coherent : Present if dma operations are coherent
+- peri-map : An array of indices of peripherals connected to DMAC
Example:
@@ -24,9 +25,9 @@ Client drivers (device nodes requiring d
mem-to-dev) should specify the DMA channel numbers using a two-value pair
as shown below.
- [property name] = [phandle of the dma controller] [dma request id];
+ [property name] = [phandle of the dma controller] [dma peripheral id];
- where 'dma request id' is the dma request number
Re: [PATCH 4/4] DMA: PL330: add device tree property for DMA_MEMCPY capability
On 30 October 2012 14:51, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
Hi,
On Monday 29 October 2012 22:45:48 Jassi Brar wrote:
On Mon, Oct 29, 2012 at 10:59 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:
* Add device tree (DT) property (pl330,dma-memcpy) for DMA_MEMCPY
capability and instead of setting this capability unconditionally
in pl330_probe() do it only when property is present.
Perhaps we should pass the array of peripheral interfaces via DT, the
lack of which could imply MEMCPY capability ? (while it works, I doubt
if pl330 is supposed to have SLAVE and MEMCPY capabilities in any
instance)
In case of PL330 on EXYNOS4 we have two interfaces with SLAVE capability
and one interface with MEMCPY capability. Could you please explain more
the idea of passing the array of peripherals through DT so we can detect
which interface has MEMCPY capability?
The DT node of a 'pdma' should have the array of indices of
peripherals it caters to (what is currently peri_id of 'struct
dma_pl330_platdata'). The array would be missing in the DT node of
'mdma' since all channels are equal.
During probe if the array, say as property 'peri_map', is missing from
DT node of the dmac, that would imply the dmac is 'mdma' and hence the
pl330.c sets DMA_MEMCPY in its cap_mask. Otherwise the peri_map
implies a 'pdma' and hence SLAVE|CYCLIC is set.
That would also be a step towards discarding struct dma_pl330_platdata.
I don't know if getting rid of struct dma_pl330_platdata is possible
but we still need to come up with some way to pass the needed information
through DT. Do you have an idea how it could be done?
struct dma_pl330_platdata {
u8 nr_valid_peri;
u8 *peri_id;
As explain above, these two should move to DT node of the dma controller.
dma_cap_mask_t cap_mask;
Should be set in pl330.c : MEMCPY for mdma, SLAVE|CYCLIC for pdma
unsigned mcbuf_sz;
Currently unused and already safe enough default value set in driver.
}
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] DMA: PL330: add device tree property for DMA_MEMCPY capability
Hi, On Monday 29 October 2012 22:45:48 Jassi Brar wrote: On Mon, Oct 29, 2012 at 10:59 AM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: * Add device tree (DT) property (pl330,dma-memcpy) for DMA_MEMCPY capability and instead of setting this capability unconditionally in pl330_probe() do it only when property is present. Perhaps we should pass the array of peripheral interfaces via DT, the lack of which could imply MEMCPY capability ? (while it works, I doubt if pl330 is supposed to have SLAVE and MEMCPY capabilities in any instance) In case of PL330 on EXYNOS4 we have two interfaces with SLAVE capability and one interface with MEMCPY capability. Could you please explain more the idea of passing the array of peripherals through DT so we can detect which interface has MEMCPY capability? That would also be a step towards discarding struct dma_pl330_platdata. I don't know if getting rid of struct dma_pl330_platdata is possible but we still need to come up with some way to pass the needed information through DT. Do you have an idea how it could be done? Best regards, -- Bartlomiej Zolnierkiewicz Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] DMA: PL330: add device tree property for DMA_MEMCPY capability
* Add device tree (DT) property (pl330,dma-memcpy) for DMA_MEMCPY
capability and instead of setting this capability unconditionally
in pl330_probe() do it only when property is present.
* Set the new pl330,dma-memcpy device tree property for all
current pl330 driver users except pdma controllers on ARM EXYNOS
platforms (so the DT case matches non-DT one).
It fixes the issue on ARM EXYNOS platforms using DT where pdma
controller erroneously was used for DMA_MEMCPY operations instead
of mdma one (it surprisingly seems to work but at the cost of
worse performance).
Cc: Jassi Brar jassisinghb...@gmail.com
Cc: Vinod Koul vinod.k...@intel.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Dinh Nguyen dingu...@altera.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/devicetree/bindings/dma/arm-pl330.txt | 1 +
arch/arm/boot/dts/exynos4.dtsi | 1 +
arch/arm/boot/dts/exynos5250.dtsi | 2 ++
arch/arm/boot/dts/highbank.dts | 1 +
arch/arm/boot/dts/socfpga.dtsi | 1 +
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 1 +
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 1 +
drivers/dma/pl330.c | 11 ---
8 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
index 36e27d5..2661c7b 100644
--- a/Documentation/devicetree/bindings/dma/arm-pl330.txt
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -11,6 +11,7 @@ Required properties:
Optional properties:
- dma-coherent : Present if dma operations are coherent
+- pl330,dma-memcpy : Present if controller has DMA_MEMCPY capability
Example:
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 96d4462..ce5b03f 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -249,6 +249,7 @@
compatible = arm,pl330, arm,primecell;
reg = 0x1285 0x1000;
interrupts = 0 34 0;
+ pl330,dma-memcpy;
};
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 49546bc..d659e7b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -247,12 +247,14 @@
compatible = arm,pl330, arm,primecell;
reg = 0x1080 0x1000;
interrupts = 0 33 0;
+ pl330,dma-memcpy;
};
mdma1: mdma@11C1 {
compatible = arm,pl330, arm,primecell;
reg = 0x11C1 0x1000;
interrupts = 0 124 0;
+ pl330,dma-memcpy;
};
};
diff --git a/arch/arm/boot/dts/highbank.dts b/arch/arm/boot/dts/highbank.dts
index 0c6fc34..87f1d25 100644
--- a/arch/arm/boot/dts/highbank.dts
+++ b/arch/arm/boot/dts/highbank.dts
@@ -297,6 +297,7 @@
interrupts = 0 92 4;
clocks = pclk;
clock-names = apb_pclk;
+ pl330,dma-memcpy;
};
ethernet@fff5 {
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 0772f57..2fe1697 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -71,6 +71,7 @@
compatible = arm,pl330, arm,primecell;
reg = 0xffe01000 0x1000;
interrupts = 0 180 4;
+ pl330,dma-memcpy;
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index d12b34c..d82953c 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -94,6 +94,7 @@
0 89 4,
0 90 4,
0 91 4;
+ pl330,dma-memcpy;
};
timer {
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 4890a81..b9e6ba2 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -114,6 +114,7 @@
0 89 4,
0 90 4,
0 91 4;
+ pl330,dma-memcpy;
};
timer {
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index db7574b..e10290b 100644
--- a/drivers/dma/pl330.c
+++
Re: [PATCH 4/4] DMA: PL330: add device tree property for DMA_MEMCPY capability
On Mon, Oct 29, 2012 at 10:59 AM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: * Add device tree (DT) property (pl330,dma-memcpy) for DMA_MEMCPY capability and instead of setting this capability unconditionally in pl330_probe() do it only when property is present. Perhaps we should pass the array of peripheral interfaces via DT, the lack of which could imply MEMCPY capability ? (while it works, I doubt if pl330 is supposed to have SLAVE and MEMCPY capabilities in any instance) That would also be a step towards discarding struct dma_pl330_platdata. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
