[PATCH v02 2/2] ARM: DTS: am437x: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/am4372.dtsi | 80 +++--
arch/arm/boot/dts/am437x-gp-evm.dts | 9 +
2 files changed, 62 insertions(+), 27 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index e363af1e17c6..ddcb92ebebbc 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -172,6 +172,14 @@
mboxes = < _wkupm3>;
};
+ edma_xbar: dma-router@f90 {
+ compatible = "ti,am335x-edma-crossbar";
+ reg = <0xf90 0x40>;
+ #dma-cells = <3>;
+ dma-requests = <64>;
+ dma-masters = <>;
+ };
+
scm_clockdomains: clockdomains {
};
};
@@ -184,14 +192,46 @@
};
edma: edma@4900 {
- compatible = "ti,edma3";
- ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
- reg = <0x4900 0x1>,
- <0x44e10f90 0x10>;
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
interrupts = ,
- ,
- ;
- #dma-cells = <1>;
+,
+;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 5>,
+ <_tptc2 0>;
+
+ ti,edma-memcpy-channels = <32 33>;
+ };
+
+ edma_tptc0: tptc@4980 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc0";
+ reg = <0x4980 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc1: tptc@4990 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc1";
+ reg = <0x4990 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc2: tptc@49a0 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc2";
+ reg = <0x49a0 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
};
uart0: serial@44e09000 {
@@ -496,8 +536,8 @@
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
- dmas = < 24
-25>;
+ dmas = < 24 0>,
+ < 25 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabled";
@@ -508,8 +548,8 @@
reg = <0x481d8000 0x1000>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
- dmas = < 2
-3>;
+ dmas = < 2 0>,
+ < 3 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabled";
@@ -777,7
[PATCH v02 1/2] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/am335x-evm.dts| 9 +---
arch/arm/boot/dts/am335x-pepper.dts | 11 +
arch/arm/boot/dts/am33xx.dtsi | 94 ++---
3 files changed, 71 insertions(+), 43 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 4caf074063fe..a55072fb6646 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -743,8 +743,8 @@
{
/* these are on the crossbar and are outlined in the
xbar-event-map element */
- dmas = < 12
-13>;
+ dmas = <_xbar 12 0 1
+ _xbar 13 0 2>;
dma-names = "tx", "rx";
status = "okay";
vmmc-supply = <_en_reg>;
@@ -766,11 +766,6 @@
};
};
- {
- ti,edma-xbar-event-map = /bits/ 16 <1 12
- 2 13>;
-};
-
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/am335x-pepper.dts
b/arch/arm/boot/dts/am335x-pepper.dts
index 9cb77a120319..4dd4f71498e5 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -339,13 +339,6 @@
ti,non-removable;
};
- {
- /* Map eDMA MMC2 Events from Crossbar */
- ti,edma-xbar-event-map = /bits/ 16 <1 12
-2 13>;
-};
-
-
{
/* Wifi & Bluetooth on MMC #3 */
status = "okay";
@@ -354,8 +347,8 @@
vmmmc-supply = <_reg>;
bus-width = <4>;
ti,non-removable;
- dmas = < 12
-13>;
+ dmas = <_xbar 12 0 1
+ _xbar 13 0 2>;
dma-names = "tx", "rx";
};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9b8861891bf0..04885f9f959e 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -161,6 +161,14 @@
mboxes = < _wkupm3>;
};
+ edma_xbar: dma-router@f90 {
+ compatible = "ti,am335x-edma-crossbar";
+ reg = <0xf90 0x40>;
+ #dma-cells = <3>;
+ dma-requests = <32>;
+ dma-masters = <>;
+ };
+
scm_clockdomains: clockdomains {
};
};
@@ -174,12 +182,44 @@
};
edma: edma@4900 {
- compatible = "ti,edma3";
- ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
- reg = <0x4900 0x1>,
- <0x44e10f90 0x40>;
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
interrupts = <12 13 14>;
- #dma-cells = <1>;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 5>,
+ <_tptc2 0>;
+
+ ti,edma-memcpy-channels = <20 21>;
+ };
+
+ edma_tptc0: tptc@4980 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc0";
+ reg = <0x4980 0x10>;
+ interrupts = <112>;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc1: tptc@4990 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc1";
+ reg = <0x4990 0x10>;
+ interrupts = <113>;
+
[PATCH v02 1/6] ARM: DTS: da850: fix edma0 reg space
The size of the eDMA0 CC register space is 0x8000 and not 0x1.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
Tested-by: Sushaanth Srirangapathi <sushaant...@ti.com>
---
arch/arm/boot/dts/da850.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 0bd98cd00816..e73f5efb3aa3 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -152,7 +152,8 @@
};
edma0: edma@01c0 {
compatible = "ti,edma3";
- reg = <0x0 0x1>;
+ /* eDMA3 CC0: 0x01c0 - 0x01c0 7fff */
+ reg = <0x0 0x8000>;
interrupts = <11 13 12>;
#dma-cells = <1>;
};
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 5/6] ARM: DTS: da850: Add node for mmc1
da850 has two MMC controller, MMCSD1 is served by eDMA1
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
Tested-by: Sushaanth Srirangapathi <sushaant...@ti.com>
---
arch/arm/boot/dts/da850.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 1538959f2853..31ca5768fccf 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -239,6 +239,14 @@
dma-names = "rx", "tx";
status = "disabled";
};
+ mmc1: mmc@1e1b000 {
+ compatible = "ti,da830-mmc";
+ reg = <0x21b000 0x1000>;
+ interrupts = <72>;
+ dmas = < 28 0>, < 29 0>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
ehrpwm0: ehrpwm@01f0 {
compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Using the new binding will allow us to reserve PaRAM slots to be used by
the DSP which was not possible before and prevented the da850 boards to be
moved to DT only.
Note that the DMA memcpy is disabled, it can be enabled by reserving
channels for memcpy by adding the following property to the edma node:
ti,edma-memcpy-channels = <20 21>; /* Reserving channel 20 and 21 for memcpy */
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
Tested-by: Sushaanth Srirangapathi <sushaant...@ti.com>
---
arch/arm/boot/dts/da850-enbw-cmc.dts | 4
arch/arm/boot/dts/da850-evm.dts | 4
arch/arm/boot/dts/da850.dtsi | 26 +-
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts
b/arch/arm/boot/dts/da850-enbw-cmc.dts
index e750ab9086d5..1811f8275559 100644
--- a/arch/arm/boot/dts/da850-enbw-cmc.dts
+++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
@@ -28,3 +28,7 @@
};
};
};
+
+ {
+ ti,edma-reserved-slot-ranges = <32 50>;
+};
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index d807285a61cd..94cf9a9b1302 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -243,3 +243,7 @@
tx-num-evt = <32>;
rx-num-evt = <32>;
};
+
+ {
+ ti,edma-reserved-slot-ranges = <32 50>;
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index e73f5efb3aa3..6e39f9b06524 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -151,11 +151,27 @@
};
edma0: edma@01c0 {
- compatible = "ti,edma3";
+ compatible = "ti,edma3-tpcc";
/* eDMA3 CC0: 0x01c0 - 0x01c0 7fff */
reg = <0x0 0x8000>;
- interrupts = <11 13 12>;
- #dma-cells = <1>;
+ reg-names = "edma3_cc";
+ interrupts = <11 12>;
+ interrupt-names = "edma3_ccint", "edma3_ccerrint";
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 0>;
+ };
+ edma0_tptc0: tptc@01c08000 {
+ compatible = "ti,edma3-tptc";
+ reg = <0x8000 0x400>;
+ interrupts = <13>;
+ interrupt-names = "edm3_tcerrint";
+ };
+ edma0_tptc1: tptc@01c08400 {
+ compatible = "ti,edma3-tptc";
+ reg = <0x8400 0x400>;
+ interrupts = <32>;
+ interrupt-names = "edm3_tcerrint";
};
serial0: serial@1c42000 {
compatible = "ns16550a";
@@ -286,8 +302,8 @@
interrupts = <54>;
interrupt-names = "common";
status = "disabled";
- dmas = < 1>,
- < 0>;
+ dmas = < 1 1>,
+ < 0 1>;
dma-names = "tx", "rx";
};
};
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 4/6] ARM: DTS: da850: Enable DMA use for MMC0
Add the needed bindings for MMC0 in order to be able to utilize the DMA
instead of PIO mode.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
Tested-by: Sushaanth Srirangapathi <sushaant...@ti.com>
---
arch/arm/boot/dts/da850.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index c08b6c04fcf1..1538959f2853 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -235,6 +235,8 @@
compatible = "ti,da830-mmc";
reg = <0x4 0x1000>;
interrupts = <16>;
+ dmas = < 16 0>, < 17 0>;
+ dma-names = "rx", "tx";
status = "disabled";
};
ehrpwm0: ehrpwm@01f0 {
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 3/6] ARM: DTS: da850: Enable eDMA1
The eDMA1 in da850 has only one TPTC and for example MMC1 is HW events are
handled by it.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
Tested-by: Sushaanth Srirangapathi <sushaant...@ti.com>
---
arch/arm/boot/dts/da850-enbw-cmc.dts | 4
arch/arm/boot/dts/da850-evm.dts | 4
arch/arm/boot/dts/da850.dtsi | 17 +
3 files changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts
b/arch/arm/boot/dts/da850-enbw-cmc.dts
index 1811f8275559..645549e14237 100644
--- a/arch/arm/boot/dts/da850-enbw-cmc.dts
+++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
@@ -32,3 +32,7 @@
{
ti,edma-reserved-slot-ranges = <32 50>;
};
+
+ {
+ ti,edma-reserved-slot-ranges = <32 90>;
+};
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 94cf9a9b1302..30e2def402ad 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -247,3 +247,7 @@
{
ti,edma-reserved-slot-ranges = <32 50>;
};
+
+ {
+ ti,edma-reserved-slot-ranges = <32 90>;
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 6e39f9b06524..c08b6c04fcf1 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -173,6 +173,23 @@
interrupts = <32>;
interrupt-names = "edm3_tcerrint";
};
+ edma1: edma@01e3 {
+ compatible = "ti,edma3-tpcc";
+ /* eDMA3 CC1: 0x01e3 - 0x01e3 7fff */
+ reg = <0x23 0x8000>;
+ reg-names = "edma3_cc";
+ interrupts = <93 94>;
+ interrupt-names = "edma3_ccint", "edma3_ccerrint";
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>;
+ };
+ edma1_tptc0: tptc@01e38000 {
+ compatible = "ti,edma3-tptc";
+ reg = <0x238000 0x400>;
+ interrupts = <95>;
+ interrupt-names = "edm3_tcerrint";
+ };
serial0: serial@1c42000 {
compatible = "ns16550a";
reg = <0x42000 0x100>;
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 6/6] ARM: DTS: da850: Enable DMA for SPI1
Add the needed bindings so the SPI driver can use DMA with SPI1.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
Tested-by: Sushaanth Srirangapathi <sushaant...@ti.com>
---
arch/arm/boot/dts/da850.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 31ca5768fccf..226cda76e77c 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -285,6 +285,8 @@
num-cs = <4>;
ti,davinci-spi-intr-line = <1>;
interrupts = <56>;
+ dmas = < 18 0>, < 19 0>;
+ dma-names = "rx", "tx";
status = "disabled";
};
mdio: mdio@1e24000 {
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 0/6] ARM: DTS: da850: eDMA new bindings and MMC/SPI DMA support
Hi, Changes since v1: - Added tested by from Sushaanth Srirangapathi - Updated to use the non 16bit arrays [1] - memcpy channels are not reserved as requested by Sekhar - DMA memcpy is disabled for now Switch to use the new eDMA bindings and enable DMA for MMC0, SPI1. Add node for MMC1. [1] As it has been discussed in the following thread: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html the DT bindings has been changes compared to what we had in 4.4-rc1: the arrays now don't have the 16bit type. The changes are now merged to mainline and Vinod provided us a branch: git://git.infradead.org/users/vkoul/slave-dma.git fix/edma Which is based on 4.4-rc1 and only contains the two patch for changing the eDMA bindings. Regards, Peter --- Peter Ujfalusi (6): ARM: DTS: da850: fix edma0 reg space ARM: DTS: da850: Use the new DT bindings for the eDMA3 ARM: DTS: da850: Enable eDMA1 ARM: DTS: da850: Enable DMA use for MMC0 ARM: DTS: da850: Add node for mmc1 ARM: DTS: da850: Enable DMA for SPI1 arch/arm/boot/dts/da850-enbw-cmc.dts | 8 + arch/arm/boot/dts/da850-evm.dts | 8 + arch/arm/boot/dts/da850.dtsi | 58 3 files changed, 68 insertions(+), 6 deletions(-) -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 0/2] ARM: DTS: am33xx/am437x: Use the new eDMA bindings
Hi, Changes since v1: - Updated to use the non 16bit arrays [1] - send the two patch as a series [1] As it has been discussed earlier: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html the DT bindings has been changes compared to what we had in 4.4-rc1: the arrays now don't have the 16bit type. The changes are now merged to mainline and Vinod provided us a branch: git://git.infradead.org/users/vkoul/slave-dma.git fix/edma Which is based on 4.4-rc1 and only contains the two patch for changing the eDMA bindings. Regards, Peter --- Peter Ujfalusi (2): ARM: DTS: am33xx: Use the new DT bindings for the eDMA3 ARM: DTS: am437x: Use the new DT bindings for the eDMA3 arch/arm/boot/dts/am335x-evm.dts| 9 +--- arch/arm/boot/dts/am335x-pepper.dts | 11 + arch/arm/boot/dts/am33xx.dtsi | 94 ++--- arch/arm/boot/dts/am4372.dtsi | 80 +++ arch/arm/boot/dts/am437x-gp-evm.dts | 9 +--- 5 files changed, 133 insertions(+), 70 deletions(-) -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3
On 12/15/2015 11:38 AM, Sekhar Nori wrote:
> Hi Peter,
>
> On Friday 04 December 2015 07:23 PM, Peter Ujfalusi wrote:
>> Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3.
>> With the new bindings boards can customize and tweak the DMA channel
>> priority to match their needs. With the new binding the memcpy is safe
>> to be used since with the old binding it was not possible for a driver
>> to know which channel is allowed to be used as non HW triggered channel.
>> Using the new binding will allow us to reserve PaRAM slots to be used by
>> the DSP which was not possible before and prevented the da850 boards to be
>> moved to DT only.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
>> ---
>> arch/arm/boot/dts/da850-enbw-cmc.dts | 5 +
>> arch/arm/boot/dts/da850-evm.dts | 5 +
>> arch/arm/boot/dts/da850.dtsi | 27 ++-
>> 3 files changed, 32 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts
>> b/arch/arm/boot/dts/da850-enbw-cmc.dts
>> index e750ab9086d5..ca9117624cf9 100644
>> --- a/arch/arm/boot/dts/da850-enbw-cmc.dts
>> +++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
>> @@ -28,3 +28,8 @@
>> };
>> };
>> };
>> +
>> + {
>> +ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
>> +ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>> +};
>> diff --git a/arch/arm/boot/dts/da850-evm.dts
>> b/arch/arm/boot/dts/da850-evm.dts
>> index d807285a61cd..33467feb272a 100644
>> --- a/arch/arm/boot/dts/da850-evm.dts
>> +++ b/arch/arm/boot/dts/da850-evm.dts
>> @@ -243,3 +243,8 @@
>> tx-num-evt = <32>;
>> rx-num-evt = <32>;
>> };
>> +
>> + {
>> +ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
>> +ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>
> These correspond to PRU events. It is true that most likely they will
> never be used for peripheral DMA and can be dedicated as memcpy
> channels. However, since this is being encoded in DT, we need to be sure
> that they will never be used for peripheral DMA on this board.
>
> So, I would prefer if you do not reserve any channels for memcpy until
> there is a real need/usecase for them. I know the board file has these
> reserved but board file could be updated as you liked. With DT we need
> to maintain backward compatibility. So I would rather do it when there
> is an actual need for it.
If we do not reserve channels for memcpy then you will have no support for
memcpy on these boards. Not sure if we use memcpy in any of our drivers in
daVinci, so it might be just fine to not have DMA memcpy support at all.
But how about using edma1's reserved channels as memcpy (19-23, 30-31)? I
don't know which channels the DSP would use on these boards, so it is never
going to be safe from that point.
> In future, if/when we gain QDMA support, the QDMA channels could be used
> for memcopy.
Well, in short there is no way to get the qDMA working in a different way
either. qDMA channel is in essence using 'normal' eDMA channel. This means
that we still need to reserve the eDMA channel to be used for memcpy, but
instead of SW triggering it (as we do it right now), we would need to use the
channel as qDMA and set things up accordingly. I don't really see the benefit
for qDMA mode to be honest.
>
>> +};
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index e73f5efb3aa3..9e46eb51a8da 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -151,11 +151,28 @@
>>
>> };
>> edma0: edma@01c0 {
>> -compatible = "ti,edma3";
>> +compatible = "ti,edma3-tpcc";
>> /* eDMA3 CC0: 0x01c0 - 0x01c0 7fff */
>> reg = <0x0 0x8000>;
>> -interrupts = <11 13 12>;
>> -#dma-cells = <1>;
>> +reg-names = "edma3_cc";
>> +interrupts = <11 12>;
>> +interrupt-names = "edma3_ccint", "edma3_ccerrint";
>> +#dma-cells = <2>;
>> +
>> +ti,tptcs = <_tptc0 7>, <_tptc1 0>;
>> +ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>
> Same here. I would drop this.
OK, I'll drop this part.
>
> Thanks,
> Sekhar
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3
On 12/15/2015 03:48 PM, Sekhar Nori wrote: >>> These correspond to PRU events. It is true that most likely they will >>> never be used for peripheral DMA and can be dedicated as memcpy >>> channels. However, since this is being encoded in DT, we need to be sure >>> that they will never be used for peripheral DMA on this board. >>> >>> So, I would prefer if you do not reserve any channels for memcpy until >>> there is a real need/usecase for them. I know the board file has these >>> reserved but board file could be updated as you liked. With DT we need >>> to maintain backward compatibility. So I would rather do it when there >>> is an actual need for it. >> >> If we do not reserve channels for memcpy then you will have no support for >> memcpy on these boards. Not sure if we use memcpy in any of our drivers in >> daVinci, so it might be just fine to not have DMA memcpy support at all. > > Not that I know of. No driver uses DMA memcpy > >> But how about using edma1's reserved channels as memcpy (19-23, 30-31)? I > > I think this is much more reasonable. > >> don't know which channels the DSP would use on these boards, so it is never >> going to be safe from that point. > > Yeah, and thats why I think its better to add it as and when there is a > real need for it. At least at that point we are sure of the usecase. OK, I'll disable the memcpy for now. >>> In future, if/when we gain QDMA support, the QDMA channels could be used >>> for memcopy. >> >> Well, in short there is no way to get the qDMA working in a different way >> either. qDMA channel is in essence using 'normal' eDMA channel. This means >> that we still need to reserve the eDMA channel to be used for memcpy, but >> instead of SW triggering it (as we do it right now), we would need to use the >> channel as qDMA and set things up accordingly. I don't really see the benefit >> for qDMA mode to be honest. > > I guess the only advantage is that they will not clash with peripheral > mode usage. But even then, some sort of reservation is needed. So I > guess QDMA is no better than the EDMA reserved channels? It will clash with the peripheral mode use since it needs to take one of the eDMA channels. qDMA mode is basically differs from the mode we are using by how the channel is triggered. Currently we start the memcpy with SW trigger. In qDMA mode we can select a paRAM parameter which if it is updated will do the triggering. It is useful if you have mostly constant memcpy parameters and you only need to change one thing in there (reusing the paRAM slot), like you change the dst address. In this case you just update the dst and the qDMA will be triggered. I don't think we can take advantage of this feature via dmaengine. -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH for 4.4 1/2] dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type
This change makes the DT file to be easier to read since the memcpy
channels array does not need the '/bits/ 16' to be specified, which might
confuse some people.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 5 ++---
drivers/dma/edma.c| 22 ++
include/linux/platform_data/edma.h| 2 +-
3 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index d3d0a4fb1c73..ae8b8f1d6e69 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -22,8 +22,7 @@ Required properties:
Optional properties:
- ti,hwmods: Name of the hwmods associated to the eDMA CC
- ti,edma-memcpy-channels: List of channels allocated to be used for memcpy,
iow
- these channels will be SW triggered channels. The list must
- contain 16 bits numbers, see example.
+ these channels will be SW triggered channels. See example.
- ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
the driver, they are allocated to be used by for example the
DSP. See example.
@@ -56,7 +55,7 @@ edma: edma@4900 {
ti,tptcs = <_tptc0 7>, <_tptc1 7>, <_tptc2 0>;
/* Channel 20 and 21 is allocated for memcpy */
- ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+ ti,edma-memcpy-channels = <20 21>;
/* The following PaRAM slots are reserved: 35-45 and 100-110 */
ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
/bits/ 16 <100 10>;
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2af8f32bba0b..89fc17f3a6ff 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1752,16 +1752,14 @@ static enum dma_status edma_tx_status(struct dma_chan
*chan,
return ret;
}
-static bool edma_is_memcpy_channel(int ch_num, u16 *memcpy_channels)
+static bool edma_is_memcpy_channel(int ch_num, s32 *memcpy_channels)
{
- s16 *memcpy_ch = memcpy_channels;
-
if (!memcpy_channels)
return false;
- while (*memcpy_ch != -1) {
- if (*memcpy_ch == ch_num)
+ while (*memcpy_channels != -1) {
+ if (*memcpy_channels == ch_num)
return true;
- memcpy_ch++;
+ memcpy_channels++;
}
return false;
}
@@ -1775,7 +1773,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool
legacy_mode)
{
struct dma_device *s_ddev = >dma_slave;
struct dma_device *m_ddev = NULL;
- s16 *memcpy_channels = ecc->info->memcpy_channels;
+ s32 *memcpy_channels = ecc->info->memcpy_channels;
int i, j;
dma_cap_zero(s_ddev->cap_mask);
@@ -1996,16 +1994,16 @@ static struct edma_soc_info
*edma_setup_info_from_dt(struct device *dev,
prop = of_find_property(dev->of_node, "ti,edma-memcpy-channels", );
if (prop) {
const char pname[] = "ti,edma-memcpy-channels";
- size_t nelm = sz / sizeof(s16);
- s16 *memcpy_ch;
+ size_t nelm = sz / sizeof(s32);
+ s32 *memcpy_ch;
- memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s16),
+ memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s32),
GFP_KERNEL);
if (!memcpy_ch)
return ERR_PTR(-ENOMEM);
- ret = of_property_read_u16_array(dev->of_node, pname,
-(u16 *)memcpy_ch, nelm);
+ ret = of_property_read_u32_array(dev->of_node, pname,
+(u32 *)memcpy_ch, nelm);
if (ret)
return ERR_PTR(ret);
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 105700e62ea1..0a533f94438f 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -76,7 +76,7 @@ struct edma_soc_info {
struct edma_rsv_info*rsv;
/* List of channels allocated for memcpy, terminated with -1 */
- s16 *memcpy_channels;
+ s32 *memcpy_channels;
s8 (*queue_priority_mapping)[2];
const s16 (*xbar_chans)[2];
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH for 4.4 2/2] dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type
This change makes the DT file to be easier to read since the reserved slots
array does not need the '/bits/ 16' to be specified, which might confuse
some people.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 5 ++--
drivers/dma/edma.c| 31 ++-
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index ae8b8f1d6e69..079b42a81d7c 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -56,9 +56,8 @@ edma: edma@4900 {
/* Channel 20 and 21 is allocated for memcpy */
ti,edma-memcpy-channels = <20 21>;
- /* The following PaRAM slots are reserved: 35-45 and 100-110 */
- ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
- /bits/ 16 <100 10>;
+ /* The following PaRAM slots are reserved: 35-44 and 100-109 */
+ ti,edma-reserved-slot-ranges = <35 10>, <100 10>;
};
edma_tptc0: tptc@4980 {
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 89fc17f3a6ff..a0f217349c07 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2015,31 +2015,50 @@ static struct edma_soc_info
*edma_setup_info_from_dt(struct device *dev,
);
if (prop) {
const char pname[] = "ti,edma-reserved-slot-ranges";
+ u32 (*tmp)[2];
s16 (*rsv_slots)[2];
- size_t nelm = sz / sizeof(*rsv_slots);
+ size_t nelm = sz / sizeof(*tmp);
struct edma_rsv_info *rsv_info;
+ int i;
if (!nelm)
return info;
+ tmp = kcalloc(nelm, sizeof(*tmp), GFP_KERNEL);
+ if (!tmp)
+ return ERR_PTR(-ENOMEM);
+
rsv_info = devm_kzalloc(dev, sizeof(*rsv_info), GFP_KERNEL);
- if (!rsv_info)
+ if (!rsv_info) {
+ kfree(tmp);
return ERR_PTR(-ENOMEM);
+ }
rsv_slots = devm_kcalloc(dev, nelm + 1, sizeof(*rsv_slots),
GFP_KERNEL);
- if (!rsv_slots)
+ if (!rsv_slots) {
+ kfree(tmp);
return ERR_PTR(-ENOMEM);
+ }
- ret = of_property_read_u16_array(dev->of_node, pname,
-(u16 *)rsv_slots, nelm * 2);
- if (ret)
+ ret = of_property_read_u32_array(dev->of_node, pname,
+(u32 *)tmp, nelm * 2);
+ if (ret) {
+ kfree(tmp);
return ERR_PTR(ret);
+ }
+ for (i = 0; i < nelm; i++) {
+ rsv_slots[i][0] = tmp[i][0];
+ rsv_slots[i][1] = tmp[i][1];
+ }
rsv_slots[nelm][0] = -1;
rsv_slots[nelm][1] = -1;
+
info->rsv = rsv_info;
info->rsv->rsv_slots = (const s16 (*)[2])rsv_slots;
+
+ kfree(tmp);
}
return info;
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit
Hi, Based on the discussion regarding to (convert am33xx to use the new eDMA bindings): https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html This two patch will convert the new eDMA binding to not use 16bit arrays for memcpy channel selection and for marking slots reserved. The '/bits/ 16' seams to be causing confusion so it is probably better to just use standard type for the arrays. The new bindings for the eDMA is introduced for 4.4 and we do not have users of it, which means that we can still change it w/o the risk of breaking anything and we do not need to maintain the compatibility with 16bit arrays. The changes in the eDMA driver is local to the DT parsing and should not conflict with other changes (like the filter function mapping support). Hrm, there might be trivial conflict in the include/linux/platform_data/edma.h with the "dmaengine 'universal' API". Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches are going to be handled? I would like to send the updated am33xx/am437x conversion for 4.5 based on these changes. Thanks and regards, Peter --- Peter Ujfalusi (2): dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type Documentation/devicetree/bindings/dma/ti-edma.txt | 10 ++--- drivers/dma/edma.c| 53 +++ include/linux/platform_data/edma.h| 2 +- 3 files changed, 40 insertions(+), 25 deletions(-) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for 4.4] DT/dmaengine: edma: Update for the new bindings
Hi Arnd, Vinod, As Arnd suggested, the two patch from the following series: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122201.html plus Acked-by from Arnd is available for pull if you prefer that way. Regards, Péter The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git repository at: https://github.com/omap-audio/linux-audio.git for-4.4/peter/edma_binding_update for you to fetch changes up to af9089852e0ecd6ae7336992d29b04d7d82b404a: dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type (2015-12-09 11:56:56 +0200) Peter Ujfalusi (2): dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type Documentation/devicetree/bindings/dma/ti-edma.txt | 10 -- drivers/dma/edma.c| 53 +++-- include/linux/platform_data/edma.h| 2 +- 3 files changed, 40 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On 12/08/2015 11:51 AM, Arnd Bergmann wrote: > On Tuesday 08 December 2015 09:42:26 Peter Ujfalusi wrote: >> On 12/04/2015 11:51 PM, Tony Lindgren wrote: >>>> >>>> Please just drop the /bits/ 16 and use normal cells. >>> >>> Yeah agreed, makes things less confusing for sure >> >> 4.4 will be the first kernel where we will have the new eDMA bindings. I have >> chosen to use 16bit array for specifying the channels used for memcpy >> (ti,edma-memcpy-channels) and for the reserving paRAM slots >> (ti,edma-reserved-slot-ranges). As of now we have maximum of 64 channels and >> 512 paRAM slots. 16bit is more than enough to store this information and it >> even gives us enough room if ever in the future these numbers are going to >> increase (which they are not). >> >> But in order to change them to 32bit the driver needs to be changed as well. >> Currently we do not have drivers (in 4.4) using the new bindings, 4.4 is not >> yet out, so it might be possible to change the binding document and the >> driver >> to use 32bit arrays. The driver internally uses 16bit type for these which >> I'm >> not going to change, but the code parsing the DT needs to be adjusted for the >> new data type. >> >> If Vinod is willing to take update for the DT binding of eDMA for 4.4-rc, I >> can cook up the patch(es) to do so. > > I hadn't realized that it was already in 4.4-rc. The change should be trivial > enough though, so I'd still do it. If Vinod would rather not change it now, > it's not overly important though. But this change must be done before we have actual users of these properties, which is the am33xx, am437x and the da850 conversion series I have sent recently. We might want to have this changed for 4.4 since it is going to be an LTS release... -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ARM: DTS: da850: eDMA new bindings and MMC/SPI DMA support
Sekhar, On 12/04/2015 03:53 PM, Peter Ujfalusi wrote: > Hi, > > Switch to use the new eDMA bindings and enable DMA for MMC0, SPI1. > Add node for MMC1. Can you hold on this one for a bit since the eDMA bindings might change still. > > Regards, > Peter > --- > Peter Ujfalusi (6): > ARM: DTS: da850: fix edma0 reg space > ARM: DTS: da850: Use the new DT bindings for the eDMA3 > ARM: DTS: da850: Enable eDMA1 > ARM: DTS: da850: Enable DMA use for MMC0 > ARM: DTS: da850: Add node for mmc1 > ARM: DTS: da850: Enable DMA for SPI1 > > arch/arm/boot/dts/da850-enbw-cmc.dts | 9 ++ > arch/arm/boot/dts/da850-evm.dts | 9 ++ > arch/arm/boot/dts/da850.dtsi | 59 > > 3 files changed, 71 insertions(+), 6 deletions(-) > -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On 12/04/2015 11:51 PM, Tony Lindgren wrote:
> * Arnd Bergmann <a...@arndb.de> [151204 13:38]:
>> On Friday 04 December 2015 10:47:07 Tony Lindgren wrote:
>>>> Peter Ujfalusi <peter.ujfal...@ti.com> writes:
>>>>> @@ -174,12 +182,44 @@
>>>>> };
>>>>>
>>>>> edma: edma@4900 {
>>>>> - compatible = "ti,edma3";
>>>>> - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
>>>>> - reg = <0x4900 0x1>,
>>>>> - <0x44e10f90 0x40>;
>>>>> + compatible = "ti,edma3-tpcc";
>>>>> + ti,hwmods = "tpcc";
>>>>> + reg = <0x4900 0x1>;
>>>>> + reg-names = "edma3_cc";
>>>>> interrupts = <12 13 14>;
>>>>> - #dma-cells = <1>;
>>>>> + interrupt-names = "edma3_ccint", "emda3_mperr",
>>>>> + "edma3_ccerrint";
>>>>> + dma-requests = <64>;
>>>>> + #dma-cells = <2>;
>>>>> +
>>>>> + ti,tptcs = <_tptc0 7>, <_tptc1 5>,
>>>>> + <_tptc2 0>;
>>>>> +
>>>>> + ti,edma-memcpy-channels = /bits/ 16 <20 21>;
>>>>
>>>> can you explain this property here ? Are you setting bits 20 and 21 on a
>>>> 16-bit field ?
>>>
>>> I think it's an arry of u16 dma channels.. But could it be just /bits/ 8
>>> instead of /bits/ 16?
>>>
>>
>> Please just drop the /bits/ 16 and use normal cells.
>
> Yeah agreed, makes things less confusing for sure :)
4.4 will be the first kernel where we will have the new eDMA bindings. I have
chosen to use 16bit array for specifying the channels used for memcpy
(ti,edma-memcpy-channels) and for the reserving paRAM slots
(ti,edma-reserved-slot-ranges). As of now we have maximum of 64 channels and
512 paRAM slots. 16bit is more than enough to store this information and it
even gives us enough room if ever in the future these numbers are going to
increase (which they are not).
But in order to change them to 32bit the driver needs to be changed as well.
Currently we do not have drivers (in 4.4) using the new bindings, 4.4 is not
yet out, so it might be possible to change the binding document and the driver
to use 32bit arrays. The driver internally uses 16bit type for these which I'm
not going to change, but the code parsing the DT needs to be adjusted for the
new data type.
If Vinod is willing to take update for the DT binding of eDMA for 4.4-rc, I
can cook up the patch(es) to do so.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On 12/08/2015 02:19 AM, Tony Lindgren wrote: > * Peter Ujfalusi <peter.ujfal...@ti.com> [151204 02:46]: >> + >> +ti,tptcs = <_tptc0 7>, <_tptc1 5>, >> + <_tptc2 0>; >> + >> +ti,edma-memcpy-channels = /bits/ 16 <20 21>; > > Is this safe to change to just ti,edma-memcpy-channels = <20 21> as > suggested by Arnd? The binding document for the eDMA and the driver also needs update to be able to handle this change. -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On 12/04/2015 02:54 AM, Tony Lindgren wrote:
> Hi Peter,
>
> * Peter Ujfalusi <peter.ujfal...@ti.com> [151016 00:23]:
>
> I noticed something while changing dm81xx to use the edma_xbar..
>
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> +
>> +edma_xbar: dma-router@44e10f90 {
>> +compatible = "ti,am335x-edma-crossbar";
>> +reg = <0x44e10f90 0x40>;
>> +
>> +#dma-cells = <3>;
>> +dma-requests = <32>;
>> +
>> +dma-masters = <>;
>> };
>
> The edma_xbar should now be just a child at offset 0xf90 under the
> scm: scm@21. Can you please check the other patches too?
Thanks Tony,
I'll make sure they are in the correct place when resending them.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: DTS: am437x: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/am4372.dtsi | 80 +++--
arch/arm/boot/dts/am437x-gp-evm.dts | 9 +
2 files changed, 62 insertions(+), 27 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index fda655c252f5..2714fa0f8bc8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -172,6 +172,14 @@
mboxes = < _wkupm3>;
};
+ edma_xbar: dma-router@f90 {
+ compatible = "ti,am335x-edma-crossbar";
+ reg = <0xf90 0x40>;
+ #dma-cells = <3>;
+ dma-requests = <64>;
+ dma-masters = <>;
+ };
+
scm_clockdomains: clockdomains {
};
};
@@ -184,14 +192,46 @@
};
edma: edma@4900 {
- compatible = "ti,edma3";
- ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
- reg = <0x4900 0x1>,
- <0x44e10f90 0x10>;
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
interrupts = ,
- ,
- ;
- #dma-cells = <1>;
+,
+;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 5>,
+ <_tptc2 0>;
+
+ ti,edma-memcpy-channels = /bits/ 16 <32 33>;
+ };
+
+ edma_tptc0: tptc@4980 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc0";
+ reg = <0x4980 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc1: tptc@4990 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc1";
+ reg = <0x4990 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc2: tptc@49a0 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc2";
+ reg = <0x49a0 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
};
uart0: serial@44e09000 {
@@ -496,8 +536,8 @@
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
- dmas = < 24
-25>;
+ dmas = < 24 0>,
+ < 25 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabled";
@@ -508,8 +548,8 @@
reg = <0x481d8000 0x1000>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
- dmas = < 2
-3>;
+ dmas = < 2 0>,
+ < 3 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabl
[PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/am335x-evm.dts| 9 +---
arch/arm/boot/dts/am335x-pepper.dts | 11 +
arch/arm/boot/dts/am33xx.dtsi | 94 ++---
3 files changed, 71 insertions(+), 43 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 4caf074063fe..a55072fb6646 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -743,8 +743,8 @@
{
/* these are on the crossbar and are outlined in the
xbar-event-map element */
- dmas = < 12
-13>;
+ dmas = <_xbar 12 0 1
+ _xbar 13 0 2>;
dma-names = "tx", "rx";
status = "okay";
vmmc-supply = <_en_reg>;
@@ -766,11 +766,6 @@
};
};
- {
- ti,edma-xbar-event-map = /bits/ 16 <1 12
- 2 13>;
-};
-
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/am335x-pepper.dts
b/arch/arm/boot/dts/am335x-pepper.dts
index 9cb77a120319..4dd4f71498e5 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -339,13 +339,6 @@
ti,non-removable;
};
- {
- /* Map eDMA MMC2 Events from Crossbar */
- ti,edma-xbar-event-map = /bits/ 16 <1 12
-2 13>;
-};
-
-
{
/* Wifi & Bluetooth on MMC #3 */
status = "okay";
@@ -354,8 +347,8 @@
vmmmc-supply = <_reg>;
bus-width = <4>;
ti,non-removable;
- dmas = < 12
-13>;
+ dmas = <_xbar 12 0 1
+ _xbar 13 0 2>;
dma-names = "tx", "rx";
};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9b8861891bf0..9d414ed31e99 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -161,6 +161,14 @@
mboxes = < _wkupm3>;
};
+ edma_xbar: dma-router@f90 {
+ compatible = "ti,am335x-edma-crossbar";
+ reg = <0xf90 0x40>;
+ #dma-cells = <3>;
+ dma-requests = <32>;
+ dma-masters = <>;
+ };
+
scm_clockdomains: clockdomains {
};
};
@@ -174,12 +182,44 @@
};
edma: edma@4900 {
- compatible = "ti,edma3";
- ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
- reg = <0x4900 0x1>,
- <0x44e10f90 0x40>;
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
interrupts = <12 13 14>;
- #dma-cells = <1>;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 5>,
+ <_tptc2 0>;
+
+ ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+ };
+
+ edma_tptc0: tptc@4980 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc0";
+ reg = <0x4980 0x10>;
+ interrupts = <112>;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc1: tptc@4990 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc1";
+ reg = <0x4990 0x10>;
+ interrupts = <113>;
+
[PATCH 5/6] ARM: DTS: da850: Add node for mmc1
da850 has two MMC controller, MMCSD1 is served by eDMA1
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/da850.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index ccaaf2746aca..edaf69ec03a9 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -240,6 +240,14 @@
dma-names = "rx", "tx";
status = "disabled";
};
+ mmc1: mmc@1e1b000 {
+ compatible = "ti,da830-mmc";
+ reg = <0x21b000 0x1000>;
+ interrupts = <72>;
+ dmas = < 28 0>, < 29 0>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
ehrpwm0: ehrpwm@01f0 {
compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ARM: DTS: da850: Enable DMA use for MMC0
Add the needed bindings for MMC0 in order to be able to utilize the DMA
instead of PIO mode.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/da850.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index e311d73a5265..ccaaf2746aca 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -236,6 +236,8 @@
compatible = "ti,da830-mmc";
reg = <0x4 0x1000>;
interrupts = <16>;
+ dmas = < 16 0>, < 17 0>;
+ dma-names = "rx", "tx";
status = "disabled";
};
ehrpwm0: ehrpwm@01f0 {
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM: DTS: da850: fix edma0 reg space
The size of the eDMA0 CC register space is 0x8000 and not 0x1.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/da850.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 0bd98cd00816..e73f5efb3aa3 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -152,7 +152,8 @@
};
edma0: edma@01c0 {
compatible = "ti,edma3";
- reg = <0x0 0x1>;
+ /* eDMA3 CC0: 0x01c0 - 0x01c0 7fff */
+ reg = <0x0 0x8000>;
interrupts = <11 13 12>;
#dma-cells = <1>;
};
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM: DTS: da850: Enable eDMA1
The eDMA1 in da850 has only one TPTC and for example MMC1 is HW events are
handled by it.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/da850-enbw-cmc.dts | 4
arch/arm/boot/dts/da850-evm.dts | 4
arch/arm/boot/dts/da850.dtsi | 17 +
3 files changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts
b/arch/arm/boot/dts/da850-enbw-cmc.dts
index ca9117624cf9..44f0dd1866f9 100644
--- a/arch/arm/boot/dts/da850-enbw-cmc.dts
+++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
@@ -33,3 +33,7 @@
ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
ti,edma-memcpy-channels = /bits/ 16 <20 21>;
};
+
+ {
+ ti,edma-reserved-slot-ranges = /bits/ 16 <32 90>;
+};
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 33467feb272a..70ef9c642ac9 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -248,3 +248,7 @@
ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
ti,edma-memcpy-channels = /bits/ 16 <20 21>;
};
+
+ {
+ ti,edma-reserved-slot-ranges = /bits/ 16 <32 90>;
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 9e46eb51a8da..e311d73a5265 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -174,6 +174,23 @@
interrupts = <32>;
interrupt-names = "edm3_tcerrint";
};
+ edma1: edma@01e3 {
+ compatible = "ti,edma3-tpcc";
+ /* eDMA3 CC1: 0x01e3 - 0x01e3 7fff */
+ reg = <0x23 0x8000>;
+ reg-names = "edma3_cc";
+ interrupts = <93 94>;
+ interrupt-names = "edma3_ccint", "edma3_ccerrint";
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>;
+ };
+ edma1_tptc0: tptc@01e38000 {
+ compatible = "ti,edma3-tptc";
+ reg = <0x238000 0x400>;
+ interrupts = <95>;
+ interrupt-names = "edm3_tcerrint";
+ };
serial0: serial@1c42000 {
compatible = "ns16550a";
reg = <0x42000 0x100>;
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] ARM: DTS: da850: Enable DMA for SPI1
Add the needed bindings so the SPI driver can use DMA with SPI1.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/da850.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index edaf69ec03a9..fc7866657a4e 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -286,6 +286,8 @@
num-cs = <4>;
ti,davinci-spi-intr-line = <1>;
interrupts = <56>;
+ dmas = < 18 0>, < 19 0>;
+ dma-names = "rx", "tx";
status = "disabled";
};
mdio: mdio@1e24000 {
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Using the new binding will allow us to reserve PaRAM slots to be used by
the DSP which was not possible before and prevented the da850 boards to be
moved to DT only.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/da850-enbw-cmc.dts | 5 +
arch/arm/boot/dts/da850-evm.dts | 5 +
arch/arm/boot/dts/da850.dtsi | 27 ++-
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts
b/arch/arm/boot/dts/da850-enbw-cmc.dts
index e750ab9086d5..ca9117624cf9 100644
--- a/arch/arm/boot/dts/da850-enbw-cmc.dts
+++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
@@ -28,3 +28,8 @@
};
};
};
+
+ {
+ ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
+ ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+};
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index d807285a61cd..33467feb272a 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -243,3 +243,8 @@
tx-num-evt = <32>;
rx-num-evt = <32>;
};
+
+ {
+ ti,edma-reserved-slot-ranges = /bits/ 16 <32 50>;
+ ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index e73f5efb3aa3..9e46eb51a8da 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -151,11 +151,28 @@
};
edma0: edma@01c0 {
- compatible = "ti,edma3";
+ compatible = "ti,edma3-tpcc";
/* eDMA3 CC0: 0x01c0 - 0x01c0 7fff */
reg = <0x0 0x8000>;
- interrupts = <11 13 12>;
- #dma-cells = <1>;
+ reg-names = "edma3_cc";
+ interrupts = <11 12>;
+ interrupt-names = "edma3_ccint", "edma3_ccerrint";
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 0>;
+ ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+ };
+ edma0_tptc0: tptc@01c08000 {
+ compatible = "ti,edma3-tptc";
+ reg = <0x8000 0x400>;
+ interrupts = <13>;
+ interrupt-names = "edm3_tcerrint";
+ };
+ edma0_tptc1: tptc@01c08400 {
+ compatible = "ti,edma3-tptc";
+ reg = <0x8400 0x400>;
+ interrupts = <32>;
+ interrupt-names = "edm3_tcerrint";
};
serial0: serial@1c42000 {
compatible = "ns16550a";
@@ -286,8 +303,8 @@
interrupts = <54>;
interrupt-names = "common";
status = "disabled";
- dmas = < 1>,
- < 0>;
+ dmas = < 1 1>,
+ < 0 1>;
dma-names = "tx", "rx";
};
};
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] ARM: DTS: da850: eDMA new bindings and MMC/SPI DMA support
Hi, Switch to use the new eDMA bindings and enable DMA for MMC0, SPI1. Add node for MMC1. Regards, Peter --- Peter Ujfalusi (6): ARM: DTS: da850: fix edma0 reg space ARM: DTS: da850: Use the new DT bindings for the eDMA3 ARM: DTS: da850: Enable eDMA1 ARM: DTS: da850: Enable DMA use for MMC0 ARM: DTS: da850: Add node for mmc1 ARM: DTS: da850: Enable DMA for SPI1 arch/arm/boot/dts/da850-enbw-cmc.dts | 9 ++ arch/arm/boot/dts/da850-evm.dts | 9 ++ arch/arm/boot/dts/da850.dtsi | 59 3 files changed, 71 insertions(+), 6 deletions(-) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/19/2015 01:25 PM, Arnd Bergmann wrote:
>> If we have two main APIs, one to request slave channels and one to get any
>> channel with given capability
>> dma_request_slave_channel(NULL, NULL, , fn, fn_param); /* Legacy slave
>> */
>> dma_request_slave_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current
>>slave */
>> dma_request_slave_channel(dev, name, , fn, fn_param); /* current
>> compat*/
>>
>> This way we can omit the mask also in cases when the client only want to get
>> DMA_SLAVE, we can just build up the mask within the function. If the mask is
>> provided we would copy the bits from the provided mask, so for example if you
>> want to have DMA_SLAVE+DMA_CYCLIC, the driver only needs to pass DMA_CYCLIC,
>> the DMA_SLAVE is going to be set anyways.
>
> I think it's more logical here to have mask=NULL mean that we want DMA_SLAVE,
> but otherwise pass the full mask as DMA_SLAVE|DMA_CYCLIC etc.
Yep, could be, while I would write the core part to set the DMA_SLAVE
unconditionally anyways. If the API say it is dma_request_slavechan() it is
expected to get channel which is capable of DMA_SLAVE.
>> dma_request_channel(mask); /* memcpy. etc, non slave mostly */
>>
>> Not sure how to name this as reusing existing (good, descriptive) function
>> names would mean changes all over the kernel to start off this.
>>
>> Not used and
>> request_dma_channel(); /* as _irq/_mem_region/_resource, etc */
>> request_dma();
>> dma_channel_request();
>
> dma_request_slavechan();
> dma_request_slave();
> dma_request_mask();
Let me think aloud here a bit...
1. To request slave channel which will return you the channel your device is
bind via DT/ACPI or the platform map table you propose later:
dma_request_chan(struct device *dev, const char *name);
2. To request a channel (any channel) matching with the capabilities the
driver needs, like memcpy, memset, etc:
#define dma_request_chan_by_mask(mask) __dma_request_chan_by_mask(&(mask))
__dma_request_chan_by_mask(const dma_cap_mask_t *mask);
I think the dma_request_chan() does not need mask to be passed, since via this
we request a specific channel which has been defined/set by DT/ACPI or the
lookup map. We could add a mask parameter which could be used to sanity check
the channel we got against the capabilities the driver needs from the channel.
We currently do this in the drivers where the author wanted to make sure that
the channel is capable of what it should be capable.
So two API to request channel:
struct dma_chan *dma_request_chan(struct device *dev, const char *name);
struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
Both will return with the valid channel pointer or in case of failure with
ERR_PTR().
We need to go through the code in regards to return codes also to have sane
mapping.
>
>> All in all, not sure which way would be better...
>
> I think I would prefer the simplest API to have only the dev+name
> arguments, as we tend to move that way for all platforms anyway, and it
> seems silly to have all drivers pass three NULL arguments all the time.
> At the moment, there are 139 references to dma_request_slave_channel_*
> in the kernel, and only 46 of them are dma_request_slave_channel_compat.
> Out of those 46, a couple can already be converted back to use
> dma_request_slave_channel() because the platform now only supports
> devicetree based boots and will not go back to platform data.
>
> How about something like
>
> extern struct dma_chan *
> __dma_request_chan(struct device *dev, const char *name,
> const dma_cap_mask_t *mask, dma_filter_fn fn, void
> *fn_param);
>
> static inline struct dma_chan *
> dma_request_slavechan(struct device *dev, const char *name)
> {
> return __dma_request_chan(dev, name, NULL, NULL, NULL);
> }
>
> static inline struct dma_chan *
> dma_request_chan(const dma_cap_mask_t *mask)
> {
> return __dma_request_chan(NULL, NULL, mask, NULL, NULL);
> }
>
> That way the vast majority of drivers can use one of the two nice interfaces
> and the rest can be converted to use __dma_request_chan().
>
> On a related topic, we had in the past considered providing a way for
> platform code to register a lookup table of some sort, to associate
> a device/name pair with a configuration. That would let us use the
> simplified dma_request_slavechan(dev, name) pair everywhere. We could
> use the same method that we have for clk_register_clkdevs() or
> pinctrl_register_map().
>
> Something like either
>
> static struct dma_chan_map myplatform_dma_map[] = {
> { .devname = "omap-aes0", .slave = "tx", .filter = omap_dma_filter_fn,
> .arg = (void *)65, },
> { .devname = "omap-aes0", .slave = "rx", .filter = omap_dma_filter_fn,
> .arg = (void *)66, },
> };
>
> or
>
> static struct dma_chan_map myplatform_dma_map[] = {
> { .devname = "omap-aes0", .slave = "tx", .master = "omap-dma-engine0",
> .req
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/20/2015 02:24 PM, Andy Shevchenko wrote: > On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann <a...@arndb.de> wrote: >> On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >>> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > >> Another idea would be to remove the filter function from struct dma_chan_map >> and pass the map through platform data > > Why not unified device properties? Is this some Windows/ACPI feature? Quick search gives mostly MSDN and Windows10 related links. We only need dma_chan_map for platforms which has not been converted to DT and still using legacy boot. Or platforms which can still boot in legacy mode. In DT/ACPI mode we do not need this map at all. -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/20/2015 12:58 PM, Arnd Bergmann wrote:
>>> That way the vast majority of drivers can use one of the two nice interfaces
>>> and the rest can be converted to use __dma_request_chan().
>>>
>>> On a related topic, we had in the past considered providing a way for
>>> platform code to register a lookup table of some sort, to associate
>>> a device/name pair with a configuration. That would let us use the
>>> simplified dma_request_slavechan(dev, name) pair everywhere. We could
>>> use the same method that we have for clk_register_clkdevs() or
>>> pinctrl_register_map().
>>>
>>> Something like either
>>>
>>> static struct dma_chan_map myplatform_dma_map[] = {
>>> { .devname = "omap-aes0", .slave = "tx", .filter = omap_dma_filter_fn,
>>> .arg = (void *)65, },
>>> { .devname = "omap-aes0", .slave = "rx", .filter = omap_dma_filter_fn,
>>> .arg = (void *)66, },
>>> };
>>>
>>> or
>>>
>>> static struct dma_chan_map myplatform_dma_map[] = {
>>> { .devname = "omap-aes0", .slave = "tx", .master = "omap-dma-engine0",
>>> .req = 65, },
>>> { .devname = "omap-aes0", .slave = "rx", .master = "omap-dma-engine0",
>>> .req = 66, },
>>
>> sa11x0-dma expects the fn_param as string :o
>
> Some of them do, but the new API requires changes in both the DMA master and
> slave drivers, so that could be changed if we wanted to, or we just allow
> both methods indefinitely and let sa11x0-dma pass the filterfn+data rather
> than
> a number.
Hrm, I would say that we need to push everyone to use the new API. sa11x0
should not be a big deal to fix IMHO and other users should be reasonably
simple to convert.
>>> };
>>
>> Basically we are deprecating the use of IORESOURCE_DMA?
>
> I thought we already had ;-)
For DT boot, yes. Not for the legacy boot.
>> For legacy the filter function is pretty much needed to handle the
>> differences
>> between the platforms as not all of them does the filtering in a same way. So
>> the first type of map would be feasible IMHO.
>
> It certainly makes the transition to a map table much easier.
And the aim anyway is to convert everything to DT, right?
>>> we could even allow a combination of the two, so the simple case just
>>> specifies
>>> master and req number, which requires changes to the dmaengine driver, but
>>> we could
>>> also do a mass-conversion to the .filter/.arg variant.
>>
>> This will get rid of the need for the fn and fn_param parameters when
>> requesting dma channel, but it will not get rid of the exported function from
>> the dma engine drivers since in arch code we need to have visibility to the
>> filter_fn.
>
> Correct. A lot of dmaengine drivers already need to be built-in so the
> platform
> code can put a pointer to the filter function, so it would not be worse for
> them.
>
> Another idea would be to remove the filter function from struct dma_chan_map
> and pass the map through platform data to the dmaengine driver, which then
> registers it to the core along with the mask. Something like:
>
> /* platform code */
> static struct dma_chan_map oma_dma_map[] = {
> { .devname = "omap-aes0", .slave = "tx", .arg = (void *)65, },
> { .devname = "omap-aes0", .slave = "rx", .arg = (void *)66, },
> ...
> {},
> };
>
> static struct omap_system_dma_plat_info dma_plat_info __initdata = {
> .dma_map = _dma_map,
> ...
> };
>
> machine_init(void)
> {
> ...
> platform_device_register_data(NULL, "omap-dma-engine", 0,
> _plat_info, sizeof(dma_plat_info);
> ...
> }
>
> /* dmaengine driver */
>
> static int omap_dma_probe(struct platform_device *pdev)
> {
> struct omap_system_dma_plat_info *pdata = dev_get_platdata(>dev);
> ...
>
> dmam_register_platform_map(>dev, omap_dma_filter_fn,
> pdata->dma_map);
> }
>
> /* dmaengine core */
>
> struct dma_map_list {
> struct list_head node;
> struct device *master;
> dma_filter_fn filter;
> struct dma_chan_map *map;
> };
>
> static LIST_HEAD(dma_map_list);
> static DEFINE_MUTEX(dma_map_mutex);
>
> int dmam_register_platform_map(struct device *dev, dma_filter_fn filter,
> struct dma_chan_map *map)
> {
> struct dma_map_list *list = kmalloc(sizeof(*list), GFP_KERNEL);
>
> if (!list)
> return -ENOMEM;
>
> list->dev = dev;
> list->filter = filter;
> list->map = map;
>
> mutex_lock(_map_mutex);
> list_add(_map_list, >node);
> mutex_unlock(_map_mutex);
> }
>
> Now we can completely remove the dependency on the filter function definition
> from platform code and slave drivers.
Sounds feasible for OMAP and daVinci and for others as well. I think ;)
I would go with this if someone asks my opinion :D
The core change to add the new API + the dma_map support should be pretty
straight forward. It can live alongside with the old API and we can phase out
the users of the old one.
The legacy support would need more time since we need to modify the arch
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/18/2015 05:46 PM, Andy Shevchenko wrote: > On Wed, Nov 18, 2015 at 4:21 PM, Peter Ujfalusi <peter.ujfal...@ti.com> wrote: >> Hi Vinod, >> >> bringing this old thread back to life as I just started to work on this. > > What I remember we need to convert drivers to use new API meanwhile it > is good to keep old one to avoid patch storm which does nothing useful > (IIRC Russel's opinion). I tend to agree. But we need to start converting the users at some point either way. Another issue is the fact that the current dmaengine API is using all the good names I can think of ;) > On the other hand there are a lot of drivers that are used on the set > of platforms starting from legacy and abandoned ones (like AVR32) to > relatively new and newest. > > And I'm not a fan of those thousands of API calls either. > -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/18/2015 05:07 PM, Arnd Bergmann wrote:
> On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote:
>> On 11/18/2015 04:29 PM, Arnd Bergmann wrote:
>>> On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
>>>> 2. non slave channel requests, where only the functionality matters, like
>>>> memcpy, interleaved, memset, etc.
>>>> We could have a simple:
>>>> dma_request_channel(mask);
>>>>
>>>> But looking at the drivers using dmaengine legacy dma_request_channel()
>>>> API:
>>>> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
>>>> drivers/misc/carma/carma-fpga.c
>>>> DMA_INTERRUPT|DMA_SLAVE|DMA_SG
>>>> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
>>>> drivers/media/platform/soc_camera/mx3_camera.c DMA_SLAVE|DMA_PRIVATE
>>>> sound/soc/intel/common/sst-firmware.c DMA_SLAVE|DMA_MEMCPY
>>>>
>>>> as examples.
>>>> Not sure how valid are these...
>
> I just had a look myself. carma has been removed fortunately in linux-next,
> so we don't have to worry about that any more.
>
> I assume that the sst-firmware.c case is a mistake, it should just use a
> plain DMA_SLAVE and not DMA_MEMCPY.
>
> Aside from these, everyone else uses either DMA_CYCLIC in addition to
> DMA_SLAVE, which seems valid, or they use DMA_PRIVATE, which I think is
> redundant in slave drivers and can be removed.
Yep, CYCLIC. How could I forgot that ;)
>>> It's usually not much harder to separate out the legacy case from
>>> the normal dma_request_slave_channel_reason(), so those drivers don't
>>> really need to use the unified compat API.
>>
>> The current dma_request_slave_channel()/_reason() is not the 'legacy' API.
>> Currently there is no way to get the reason why the dma channel request fails
>> when using the _compat() version of the API, which is used by drivers which
>> can be used in DT or in legacy mode as well. Sure, they all could have local
>> if(){}else{} for handling this, but it is not a nice thing.
>>
>> As it was discussed instead of adding the _reason() version for the _compat
>> call, we should simplify the dmaengine API for getting the channel and at the
>> same time we will have ERR_PTR returned instead of NULL.
>
> What I meant was that we don't need to handle them with the unified
> simple interface. The users of DMA_CYCLIC can just keep using
> an internal helper that only deals with the legacy case, or use
> dma_request_slave() or whatever is the new API for the DT case.
I think we can go with a single API, but I don't really like that:
dma_request_channel(dev, name, *mask, fn, fn_param);
This would cover all current uses being legacy, DT/ACPI, compat, etc:
dma_request_channel(NULL, NULL, , fn, fn_param); /* Legacy slave */
dma_request_channel(NULL, NULL, , NULL, NULL); /* memcpy. etc */
dma_request_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current slave */
dma_request_channel(dev, name, , fn, fn_param); /* current compat */
Note, that we need "const dma_cap_mask_t *mask" to be able to make the mask
optional.
If we have two main APIs, one to request slave channels and one to get any
channel with given capability
dma_request_slave_channel(NULL, NULL, , fn, fn_param); /* Legacy slave */
dma_request_slave_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current
slave */
dma_request_slave_channel(dev, name, , fn, fn_param); /* current compat*/
This way we can omit the mask also in cases when the client only want to get
DMA_SLAVE, we can just build up the mask within the function. If the mask is
provided we would copy the bits from the provided mask, so for example if you
want to have DMA_SLAVE+DMA_CYCLIC, the driver only needs to pass DMA_CYCLIC,
the DMA_SLAVE is going to be set anyways.
dma_request_channel(mask); /* memcpy. etc, non slave mostly */
Not sure how to name this as reusing existing (good, descriptive) function
names would mean changes all over the kernel to start off this.
Not used and
request_dma_channel(); /* as _irq/_mem_region/_resource, etc */
request_dma();
dma_channel_request();
All in all, not sure which way would be better...
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/18/2015 04:29 PM, Arnd Bergmann wrote:
> On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
>> 2. non slave channel requests, where only the functionality matters, like
>> memcpy, interleaved, memset, etc.
>> We could have a simple:
>> dma_request_channel(mask);
>>
>> But looking at the drivers using dmaengine legacy dma_request_channel() API:
>> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
>> drivers/misc/carma/carma-fpga.c
>> DMA_INTERRUPT|DMA_SLAVE|DMA_SG
>> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
>> drivers/media/platform/soc_camera/mx3_camera.c DMA_SLAVE|DMA_PRIVATE
>> sound/soc/intel/common/sst-firmware.c DMA_SLAVE|DMA_MEMCPY
>>
>> as examples.
>> Not sure how valid are these...
>
> It's usually not much harder to separate out the legacy case from
> the normal dma_request_slave_channel_reason(), so those drivers don't
> really need to use the unified compat API.
The current dma_request_slave_channel()/_reason() is not the 'legacy' API.
Currently there is no way to get the reason why the dma channel request fails
when using the _compat() version of the API, which is used by drivers which
can be used in DT or in legacy mode as well. Sure, they all could have local
if(){}else{} for handling this, but it is not a nice thing.
As it was discussed instead of adding the _reason() version for the _compat
call, we should simplify the dmaengine API for getting the channel and at the
same time we will have ERR_PTR returned instead of NULL.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
Hi Vinod, bringing this old thread back to life as I just started to work on this. On 06/24/2015 07:24 PM, Vinod Koul wrote: >> We would end up with the following APIs, all returning with error code on >> failure: >> dma_request_slave_channel(dev, name); >> dma_request_channel_legacy(mask, fn, fn_param); >> dma_request_slave_channel_compat(mask, fn, fn_param, dev, name); >> dma_request_any_channel(mask); > This is good idea but still we end up with 4 APIs. Why not just converge to > two API, one legacy + memcpy + filer fn and one untimate API for slave? Looked at the current API and it's use and, well, it is a bit confusing. What I hoped that we can separate users to two category: 1. Slave channel requests, where we request a specific channel to handle HW requests/triggers. For this we could have: dma_request_slave_channel(dev, name, fn, fn_param); In DT/ACPI only drivers we can NULL out the fn and fn_param, in pure legacy mode we null out the name, I would keep the dev so we could print dev specific error in dmaengine core, but it could be optional, IN case of drivers used both DT/ACPI and legacy mode all parameter can be filled and the core will decide what to do. For the legacy needs the dmaengine code would provide the mask dows with DMA_SLAVE flag set. 2. non slave channel requests, where only the functionality matters, like memcpy, interleaved, memset, etc. We could have a simple: dma_request_channel(mask); But looking at the drivers using dmaengine legacy dma_request_channel() API: Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE: drivers/misc/carma/carma-fpga.c DMA_INTERRUPT|DMA_SLAVE|DMA_SG drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG drivers/media/platform/soc_camera/mx3_camera.c DMA_SLAVE|DMA_PRIVATE sound/soc/intel/common/sst-firmware.c DMA_SLAVE|DMA_MEMCPY as examples. Not sure how valid are these... Some drivers do pass fn and fn_param when requesting channel for DMA_MEMCPY drivers/misc/mic/host/mic_device.h drivers/mtd/nand/fsmc_nand.c sound/soc/intel/common/sst-firmware.c (well, this request DMA_SLAVE capability at the same time). Some driver sets the fn_param w/o fn, which means fn_param is ignored. So the dma_request_slave_channel(dev, name, fn, fn_param); dma_request_channel(mask); almost covers the current users and would be pretty clean ;) If we add the mask to the slave channel API - which will become universal, drop in replacement for dma_request_channel, and we might have only one API: dma_request_channel(dev, name, mask, fn, fn_param); > > Internally we may have 4 APIs for cleaner handling... > > Thoughts... ?? Yes, as we need to arrange the code internally to keep things neat. -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/13] [media] omap3isp: Support for deferred probing when requesting DMA channel
Hi Laurent,
On 11/09/2015 09:50 PM, Laurent Pinchart wrote:
> Hi Peter,
>
> Thank you for the patch.
>
> What happened to this patch series ? It looks like
> dma_request_slave_channel_compat_reason() isn't in mainline, so I can't apply
> this patch.
>
> I'll mark this patch as deferred in patchwork, please resubmit it if you
> resubmit the series
The original series - containing this patch - generated a bit of discussion
and it seams that I will need to do bigger change in the dmaengine API
compared to this.
I think this patch can be dropped as the dmaengine changes will not go in as
they were.
(and by the look of it the issue you're trying to fix
> still exists, so it would be nice if you could get it eventually fixed).
Yes, the issue still valid for the OMAP/DaVinci driver the series was touching.
I will try to send a new series in the coming weeks.
Thanks,
Péter
>
> On Tuesday 26 May 2015 16:26:07 Peter Ujfalusi wrote:
>> Switch to use ma_request_slave_channel_compat_reason() to request the DMA
>> channel. Only fall back to pio mode if the error code returned is not
>> -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
>> CC: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
>> CC: Mauro Carvalho Chehab <mche...@osg.samsung.com>
>> ---
>> drivers/media/platform/omap3isp/isphist.c | 12 +---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/platform/omap3isp/isphist.c
>> b/drivers/media/platform/omap3isp/isphist.c index
>> 7138b043a4aa..e690ca13af0e 100644
>> --- a/drivers/media/platform/omap3isp/isphist.c
>> +++ b/drivers/media/platform/omap3isp/isphist.c
>> @@ -499,14 +499,20 @@ int omap3isp_hist_init(struct isp_device *isp)
>> if (res)
>> sig = res->start;
>>
>> -hist->dma_ch = dma_request_slave_channel_compat(mask,
>> +hist->dma_ch = dma_request_slave_channel_compat_reason(mask,
>> omap_dma_filter_fn, , isp->dev, "hist");
>> -if (!hist->dma_ch)
>> +if (IS_ERR(hist->dma_ch)) {
>> +ret = PTR_ERR(hist->dma_ch);
>> +if (ret == -EPROBE_DEFER)
>> +return ret;
>> +
>> +hist->dma_ch = NULL;
>> dev_warn(isp->dev,
>> "hist: DMA channel request failed, using
>> PIO\n");
>> -else
>> +} else {
>> dev_dbg(isp->dev, "hist: using DMA channel %s\n",
>> dma_chan_name(hist->dma_ch));
>> +}
>> }
>>
>> hist->ops = _ops;
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges
On 11/06/2015 11:53 PM, Rob Herring wrote: > On Fri, Oct 30, 2015 at 10:00:37AM +0200, Peter Ujfalusi wrote: >> In eDMA the events are directly mapped to a DMA channel (for example DMA >> event 14 can only be handled by DMA channel 14). If the memcpy is enabled >> on the eDMA, there is a possibility that the crossbar driver would assign >> DMA event number already allocated in eDMA for memcpy. Furthermore the >> eDMA can be shared with DSP in which case the crossbar driver should also >> avoid mapping xbar events to DSP used event numbers (or channels). >> >> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> >> --- >> .../devicetree/bindings/dma/ti-dma-crossbar.txt| 6 +++ >> drivers/dma/ti-dma-crossbar.c | 47 >> -- >> 2 files changed, 49 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt >> b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt >> index b152a75dceae..aead5869a28d 100644 >> --- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt >> +++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt >> @@ -14,6 +14,10 @@ The DMA controller node need to have the following >> poroperties: >> >> Optional properties: >> - ti,dma-safe-map: Safe routing value for unused request lines >> +- ti,reserved-dma-request-ranges: DMA request ranges which should not be >> used >> +when mapping xbar input to DMA request, they are either >> +allocated to be used by for example the DSP or they are used as >> +memcpy channels in eDMA. > > How many requests are there? I think I'd rather see this as a mask > value. The eDMA on dra7 family have 64 channels. I don't have visibility to customer kernels, but at least 32 channels need be allocated to be used by the DSP. This depends on the system design. It could be that only the memcpy channels need to be reserved, but in some setups we do need more than a few. -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On 11/04/2015 10:37 AM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 05:46:05PM +0200, Peter Ujfalusi wrote: >>> Okay I have reverted the two and applied the edma patch sent, can you please >>> verify topic/edma_fix before I merge it and send my PULL request. >> >> The branch looks good. Thank you! >> It would have been great if the DTS changes for am335x/am437x would have been >> in 4.4, but I will send them for 4.5 after rc1 is out. > > Any confirmation that this fixes the reported issue before I send pull > request? Patch 'dmaengine: edma: Add dummy driver skeleton for edma3-tptc' alone is fixing the issue: https://lkml.org/lkml/2015/11/2/297 I have tested it on: OMAP-L138-EVM, am335x-evmsk, am437x-gp-evm, dra7-evm (I have local patches to enable and use eDMA). All looks fine, mmc/audio works and they use eDMA. Olof: can you run a quick test with the linked patch? Thank you, Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dmaengine: of_dma: Correct return code for of_dma_request_slave_channel in case !CONFIG_OF
of_dma_request_slave_channel should return either pointer for valid
dma_chan or ERR_PTR() error code, NULL is not expected to be returned.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
include/linux/of_dma.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index 36112cdd665a..b90d8ec57c1f 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -80,7 +80,7 @@ static inline int of_dma_router_register(struct device_node
*np,
static inline struct dma_chan *of_dma_request_slave_channel(struct device_node
*np,
const char *name)
{
- return NULL;
+ return ERR_PTR(-ENODEV);
}
static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args
*dma_spec,
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Vinod, On 11/02/2015 05:40 PM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 02:13:01PM +0200, Peter Ujfalusi wrote: >> Vinod, >> >> On 11/02/2015 12:04 PM, Vinod Koul wrote: >>> On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: >>>> Hi, >>>> >>>> 1) This seems to have broken BBB in -next for me, bisected down to this >>>> patch. >>>> >>>> For bootlog: >>>> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html >>>> >>>> 2) Please avoid merging DT/platform code in your driver tree, Vinod, >>>> at least without an ack from the platform maintainer. It can be a a >>>> huge mess if they end up causing conflicts, so we always ask to merge >>>> the DT changes through the platform maintainer (Tony in this case) by >>>> default. >>> >>> I did warn when applying that I am doing so without ACK on ARM code, noone >>> said a thing! >>> >>> I knew Tony was following the work by Peter so assumed he must have been >>> okay >>> with it otherwise would have spoken for ~couple of weeks these were in >>> review >>> >>> Anyway now that we have a regression, I can revert this patch if that fixes, >>> please confirm, but might break edma... peter? >> >> Can you revert or drop the last two DTS patches? >> >> I think I will try a different route to get the split of the tpcc and tptc. >> Without the DT patches the driver will fall back to the legacy mode so things >> will work in a same way they did before. >> Or I can send a followup patch for edma.c, with that there is no need to add >> the HWMOD_INIT_NO_IDLE to hwmod and power management looks better. >> Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod >> code will not shut it down but we will keep the possibility to manage the >> power state still. > > Okay I have reverted the two and applied the edma patch sent, can you please > verify topic/edma_fix before I merge it and send my PULL request. The branch looks good. Thank you! It would have been great if the DTS changes for am335x/am437x would have been in 4.4, but I will send them for 4.5 after rc1 is out. > Would appreciate any tested-by > > Thanks > -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dmaengine: edma: Add dummy driver skeleton for edma3-tptc
The eDMA3 TPTC does not need any software configuration, but it is a
separate IP block in the SoC. In order the omap hwmod core to be able to
handle the TPTC resources correctly in regards of PM we need to have a
driver loaded for it.
This patch will add a dummy driver skeleton without probe or remove
callbacks provided.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
Reported-by: Olof Johansson <o...@lixom.net>
---
Hi,
while it would have been possible to add the edma3-tptc compatible to be handled
by the edma-tpcc driver (and when the device is tptc, do nothing) it would
make the driver code a bit harder to follow.
I think having separate structure for the tptc looks better and if we ever need
to have separate driver for the tptc it will be cleaner for us the separate it.
This patch alone w/o any hwmod flag changes will make sure that the edma-tptc is
not powered down after the kernel is finished it's booting.
Regards,
Peter
drivers/dma/edma.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 31722d436a42..6b03e4e84e6b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -269,6 +269,11 @@ static const struct of_device_id edma_of_ids[] = {
{}
};
+static const struct of_device_id edma_tptc_of_ids[] = {
+ { .compatible = "ti,edma3-tptc", },
+ {}
+};
+
static inline unsigned int edma_read(struct edma_cc *ecc, int offset)
{
return (unsigned int)__raw_readl(ecc->base + offset);
@@ -2399,6 +2404,13 @@ static struct platform_driver edma_driver = {
},
};
+static struct platform_driver edma_tptc_driver = {
+ .driver = {
+ .name = "edma3-tptc",
+ .of_match_table = edma_tptc_of_ids,
+ },
+};
+
bool edma_filter_fn(struct dma_chan *chan, void *param)
{
bool match = false;
@@ -2418,6 +2430,12 @@ EXPORT_SYMBOL(edma_filter_fn);
static int edma_init(void)
{
+ int ret;
+
+ ret = platform_driver_register(_tptc_driver);
+ if (ret)
+ return ret;
+
return platform_driver_register(_driver);
}
subsys_initcall(edma_init);
@@ -2425,6 +2443,7 @@ subsys_initcall(edma_init);
static void __exit edma_exit(void)
{
platform_driver_unregister(_driver);
+ platform_driver_unregister(_tptc_driver);
}
module_exit(edma_exit);
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: hwmod: AM33xx/43xx: Add HWMOD_INIT_NO_IDLE flag to tptc
In Linux we do not have driver for TPTCs of eDMA3 since there is no need to
do any configuration within TPTC for the eDMA3 to be operational. All
configuration is via the TPCC.
To prevent the omap_device_late_idle() to disable the TPTCs when they are
no longer bind with the edma driver, the HWMOD_INIT_NO_IDLE need to be
added.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
Vinod, Olof,
This patch somehow got lost in my working branch. It was mixed within the
patches
I will have for 4.5 while it should have been within the new eDMA3 binding
series..
Regards,
Peter
arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 907a452b78ea..3c7106a09801 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -1169,7 +1169,8 @@ struct omap_hwmod am33xx_tptc0_hwmod = {
.name = "tptc0",
.class = _tptc_hwmod_class,
.clkdm_name = "l3_clkdm",
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+ HWMOD_INIT_NO_IDLE),
.main_clk = "l3_gclk",
.prcm = {
.omap4 = {
@@ -1183,7 +1184,8 @@ struct omap_hwmod am33xx_tptc1_hwmod = {
.name = "tptc1",
.class = _tptc_hwmod_class,
.clkdm_name = "l3_clkdm",
- .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+ HWMOD_INIT_NO_IDLE),
.main_clk = "l3_gclk",
.prcm = {
.omap4 = {
@@ -1197,7 +1199,8 @@ struct omap_hwmod am33xx_tptc2_hwmod = {
.name = "tptc2",
.class = _tptc_hwmod_class,
.clkdm_name = "l3_clkdm",
- .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+ HWMOD_INIT_NO_IDLE),
.main_clk = "l3_gclk",
.prcm = {
.omap4 = {
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Hi Olof,
On 11/02/2015 11:21 AM, Olof Johansson wrote:
> Hi,
>
> 1) This seems to have broken BBB in -next for me, bisected down to this patch.
>
> For bootlog:
> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html
Aargh, I had the patch which should have been included to the series (just
sent it):
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg121134.html
It was mixed with the patches I collected for 4.5, I don't know how this
happened, but this is the reason I have not seen the issue you are seeing.
>
> 2) Please avoid merging DT/platform code in your driver tree, Vinod,
> at least without an ack from the platform maintainer. It can be a a
> huge mess if they end up causing conflicts, so we always ask to merge
> the DT changes through the platform maintainer (Tony in this case) by
> default.
>
>
> Thanks,
>
> -Olof
>
> On Fri, Oct 16, 2015 at 12:18 AM, Peter Ujfalusi <peter.ujfal...@ti.com>
> wrote:
>> Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
>> enable the DMA even crossbar with ti,am335x-edma-crossbar.
>> With the new bindings boards can customize and tweak the DMA channel
>> priority to match their needs. With the new binding the memcpy is safe
>> to be used since with the old binding it was not possible for a driver
>> to know which channel is allowed to be used as non HW triggered channel.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
>> ---
>> arch/arm/boot/dts/am335x-evm.dts| 9 +---
>> arch/arm/boot/dts/am335x-pepper.dts | 11 +
>> arch/arm/boot/dts/am33xx.dtsi | 96
>> ++---
>> 3 files changed, 73 insertions(+), 43 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/am335x-evm.dts
>> b/arch/arm/boot/dts/am335x-evm.dts
>> index 1942a5c8132d..507980672c32 100644
>> --- a/arch/arm/boot/dts/am335x-evm.dts
>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>> @@ -743,8 +743,8 @@
>> {
>> /* these are on the crossbar and are outlined in the
>>xbar-event-map element */
>> - dmas = < 12
>> -13>;
>> + dmas = <_xbar 12 0 1
>> + _xbar 13 0 2>;
>> dma-names = "tx", "rx";
>> status = "okay";
>> vmmc-supply = <_en_reg>;
>> @@ -766,11 +766,6 @@
>> };
>> };
>>
>> - {
>> - ti,edma-xbar-event-map = /bits/ 16 <1 12
>> - 2 13>;
>> -};
>> -
>> {
>> status = "okay";
>> };
>> diff --git a/arch/arm/boot/dts/am335x-pepper.dts
>> b/arch/arm/boot/dts/am335x-pepper.dts
>> index 7106114c7464..39073b921664 100644
>> --- a/arch/arm/boot/dts/am335x-pepper.dts
>> +++ b/arch/arm/boot/dts/am335x-pepper.dts
>> @@ -339,13 +339,6 @@
>> ti,non-removable;
>> };
>>
>> - {
>> - /* Map eDMA MMC2 Events from Crossbar */
>> - ti,edma-xbar-event-map = /bits/ 16 <1 12
>> -2 13>;
>> -};
>> -
>> -
>> {
>> /* Wifi & Bluetooth on MMC #3 */
>> status = "okay";
>> @@ -354,8 +347,8 @@
>> vmmmc-supply = <_reg>;
>> bus-width = <4>;
>> ti,non-removable;
>> - dmas = < 12
>> -13>;
>> + dmas = <_xbar 12 0 1
>> + _xbar 13 0 2>;
>> dma-names = "tx", "rx";
>> };
>>
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index d23e2524d694..6053e75c6e99 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -174,12 +174,54 @@
>> };
>>
>> edma: edma@4900 {
>> - compatible = "ti,edma3";
>> - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
>> - reg = <0x4900 0x1>,
>> - <0x44e10f90 0x40>;
>> + compatible = "ti,edma3-tpcc";
>> + ti,hwmods = "tpcc";
>> + reg = <0x4900 0x1>;
>> + reg-names = "edma3_cc";
>> interrupts = <12 13 14>;
>> - #d
Re: [PATCH] ARM: OMAP: hwmod: AM33xx/43xx: Add HWMOD_INIT_NO_IDLE flag to tptc
On 11/02/2015 12:24 PM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 12:11:00PM +0200, Peter Ujfalusi wrote: >> In Linux we do not have driver for TPTCs of eDMA3 since there is no need to >> do any configuration within TPTC for the eDMA3 to be operational. All >> configuration is via the TPCC. >> To prevent the omap_device_late_idle() to disable the TPTCs when they are >> no longer bind with the edma driver, the HWMOD_INIT_NO_IDLE need to be >> added. >> >> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> >> --- >> Vinod, Olof, >> >> This patch somehow got lost in my working branch. It was mixed within the >> patches >> I will have for 4.5 while it should have been within the new eDMA3 binding >> series.. > > Does this fix the issue reported by Olof? Also ACK pls for this Yes, it is fixing the issue, I have this in my branch. everything looks fine on AM335x/AM437x/Dra7xx where I have eDMA in use. -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Vinod, On 11/02/2015 12:04 PM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: >> Hi, >> >> 1) This seems to have broken BBB in -next for me, bisected down to this >> patch. >> >> For bootlog: >> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html >> >> 2) Please avoid merging DT/platform code in your driver tree, Vinod, >> at least without an ack from the platform maintainer. It can be a a >> huge mess if they end up causing conflicts, so we always ask to merge >> the DT changes through the platform maintainer (Tony in this case) by >> default. > > I did warn when applying that I am doing so without ACK on ARM code, noone > said a thing! > > I knew Tony was following the work by Peter so assumed he must have been okay > with it otherwise would have spoken for ~couple of weeks these were in > review > > Anyway now that we have a regression, I can revert this patch if that fixes, > please confirm, but might break edma... peter? Can you revert or drop the last two DTS patches? I think I will try a different route to get the split of the tpcc and tptc. Without the DT patches the driver will fall back to the legacy mode so things will work in a same way they did before. Or I can send a followup patch for edma.c, with that there is no need to add the HWMOD_INIT_NO_IDLE to hwmod and power management looks better. Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod code will not shut it down but we will keep the possibility to manage the power state still. -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: hwmod: AM33xx/43xx: Add HWMOD_INIT_NO_IDLE flag to tptc
On 11/02/2015 12:23 PM, Peter Ujfalusi wrote: > On 11/02/2015 12:24 PM, Vinod Koul wrote: >> On Mon, Nov 02, 2015 at 12:11:00PM +0200, Peter Ujfalusi wrote: >>> In Linux we do not have driver for TPTCs of eDMA3 since there is no need to >>> do any configuration within TPTC for the eDMA3 to be operational. All >>> configuration is via the TPCC. >>> To prevent the omap_device_late_idle() to disable the TPTCs when they are >>> no longer bind with the edma driver, the HWMOD_INIT_NO_IDLE need to be >>> added. >>> >>> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> >>> --- >>> Vinod, Olof, >>> >>> This patch somehow got lost in my working branch. It was mixed within the >>> patches >>> I will have for 4.5 while it should have been within the new eDMA3 binding >>> series.. >> >> Does this fix the issue reported by Olof? Also ACK pls for this > > Yes, it is fixing the issue, I have this in my branch. everything looks fine > on AM335x/AM437x/Dra7xx where I have eDMA in use. Vinod, can you please ignore this patch? I'm going to send a patch agains edma.c which will handle this better. -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] dmaengine: ti-dma-crossbar: channel reserving and edma3-tcc support
Vinod, On 10/29/2015 10:28 AM, Peter Ujfalusi wrote: > Hi, > > This series depends on the eDMA work I have done, which has been now applied: > https://lkml.org/lkml/2015/10/16/64 > > DRA7 family of chips have both sDMA and eDMA. Currently only sDMA can be used > becasue the old driver stack for eDMA did not allowed integration w/o hacks. > > Due to the nature of eDMA the crossbar needs to know which eDMA events it can > use to map incoming events towards the eDMA. In eDMA a channel is wired to be > used with one specific event. For example eDMA event 14 can only be handled by > eDMA channel 14. > The eDMA itself can be shared by different processors in the system (ARM, DSP, > etc) and since ARM/Linux is the master we need to know which channels are used > by other cores. Also we need to mask out channels used for memcpy from the > events we use for HW triggers. Please ignore this series, I have found some issue with it and I just started to debug it. Will post V2 as soon as I found the problem. > > Regards, > Peter > --- > Peter Ujfalusi (3): > dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr > dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event > ranges > dmaengine: ti-dma-crossbar: dra7: Support for eDMA with new bindings > > .../devicetree/bindings/dma/ti-dma-crossbar.txt| 6 ++ > drivers/dma/ti-dma-crossbar.c | 81 > +++--- > 2 files changed, 76 insertions(+), 11 deletions(-) > -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges
In eDMA the events are directly mapped to a DMA channel (for example DMA
event 14 can only be handled by DMA channel 14). If the memcpy is enabled
on the eDMA, there is a possibility that the crossbar driver would assign
DMA event number already allocated in eDMA for memcpy. Furthermore the
eDMA can be shared with DSP in which case the crossbar driver should also
avoid mapping xbar events to DSP used event numbers (or channels).
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
.../devicetree/bindings/dma/ti-dma-crossbar.txt| 6 +++
drivers/dma/ti-dma-crossbar.c | 47 --
2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
index b152a75dceae..aead5869a28d 100644
--- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
+++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
@@ -14,6 +14,10 @@ The DMA controller node need to have the following
poroperties:
Optional properties:
- ti,dma-safe-map: Safe routing value for unused request lines
+- ti,reserved-dma-request-ranges: DMA request ranges which should not be used
+ when mapping xbar input to DMA request, they are either
+ allocated to be used by for example the DSP or they are used as
+ memcpy channels in eDMA.
Notes:
When requesting channel via ti,dra7-dma-crossbar, the DMA clinet must request
@@ -46,6 +50,8 @@ sdma_xbar: dma-router@4a002b78 {
#dma-cells = <1>;
dma-requests = <205>;
ti,dma-safe-map = <0>;
+ /* Protect the sDMA request ranges: 10-14 and 100-126 */
+ ti,reserved-dma-request-ranges = <10 5>, <100 27>;
dma-masters = <>;
};
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 463ad6b18a32..dac7ae06cc58 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -292,14 +292,22 @@ static const struct of_device_id ti_dra7_master_match[] =
{
{},
};
+static inline void ti_dra7_xbar_reserve(int offset, int len, unsigned long *p)
+{
+ for (; len > 0; len--)
+ clear_bit(offset + (len - 1), p);
+}
+
static int ti_dra7_xbar_probe(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
struct device_node *dma_node;
struct ti_dra7_xbar_data *xbar;
+ struct property *prop;
struct resource *res;
u32 safe_val;
+ size_t sz;
void __iomem *iomem;
int i, ret;
@@ -347,6 +355,33 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
if (!of_property_read_u32(node, "ti,dma-safe-map", _val))
xbar->safe_val = (u16)safe_val;
+
+ prop = of_find_property(node, "ti,reserved-dma-request-ranges", );
+ if (prop) {
+ const char pname[] = "ti,reserved-dma-request-ranges";
+ u32 (*rsv_events)[2];
+ size_t nelm = sz / sizeof(*rsv_events);
+ int i;
+
+ if (!nelm)
+ return -EINVAL;
+
+ rsv_events = kcalloc(nelm, sizeof(*rsv_events), GFP_KERNEL);
+ if (!rsv_events)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(node, pname, (u32 *)rsv_events,
+nelm * 2);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < nelm; i++) {
+ ti_dra7_xbar_reserve(rsv_events[i][0], rsv_events[i][1],
+xbar->dma_inuse);
+ }
+ kfree(rsv_events);
+ }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
iomem = devm_ioremap_resource(>dev, res);
if (IS_ERR(iomem))
@@ -362,15 +397,19 @@ static int ti_dra7_xbar_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, xbar);
/* Reset the crossbar */
- for (i = 0; i < xbar->dma_requests; i++)
- ti_dra7_xbar_write(xbar->iomem, i, xbar->safe_val);
+ for (i = 0; i < xbar->dma_requests; i++) {
+ if (!test_bit(i, xbar->dma_inuse))
+ ti_dra7_xbar_write(xbar->iomem, i, xbar->safe_val);
+ }
ret = of_dma_router_register(node, ti_dra7_xbar_route_allocate,
>dmarouter);
if (ret) {
/* Restore the defaults for the crossbar */
- for (i = 0; i < xbar->dma_requests; i++)
- ti_dra7_xbar_write(xbar->iomem, i, i);
+ for (i = 0; i < xbar->dma_requests; i++) {
+ if (!test_bit(i, xbar->dma_
[PATCH v2 1/3] dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr
The use of idr was nice, but it was a bit heavy and we did not need the
features it provides. Using simple bitmap to track allocated DMA channels
is adequate here and it will be easier to add support for reserving
channels later on.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index a415edbe61b1..463ad6b18a32 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -198,7 +197,8 @@ struct ti_dra7_xbar_data {
void __iomem *iomem;
struct dma_router dmarouter;
- struct idr map_idr;
+ struct mutex mutex;
+ unsigned long *dma_inuse;
u16 safe_val; /* Value to rest the crossbar lines */
u32 xbar_requests; /* number of DMA requests connected to XBAR */
@@ -225,7 +225,9 @@ static void ti_dra7_xbar_free(struct device *dev, void
*route_data)
map->xbar_in, map->xbar_out);
ti_dra7_xbar_write(xbar->iomem, map->xbar_out, xbar->safe_val);
- idr_remove(>map_idr, map->xbar_out);
+ mutex_lock(>mutex);
+ clear_bit(map->xbar_out, xbar->dma_inuse);
+ mutex_unlock(>mutex);
kfree(map);
}
@@ -255,8 +257,17 @@ static void *ti_dra7_xbar_route_allocate(struct
of_phandle_args *dma_spec,
return ERR_PTR(-ENOMEM);
}
- map->xbar_out = idr_alloc(>map_idr, NULL, 0, xbar->dma_requests,
- GFP_KERNEL);
+ mutex_lock(>mutex);
+ map->xbar_out = find_first_zero_bit(xbar->dma_inuse,
+ xbar->dma_requests);
+ mutex_unlock(>mutex);
+ if (map->xbar_out == xbar->dma_requests) {
+ dev_err(>dev, "Run out of free DMA requests\n");
+ kfree(map);
+ return ERR_PTR(-ENOMEM);
+ }
+ set_bit(map->xbar_out, xbar->dma_inuse);
+
map->xbar_in = (u16)dma_spec->args[0];
dma_spec->args[0] = map->xbar_out + xbar->dma_offset;
@@ -299,8 +310,6 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
if (!xbar)
return -ENOMEM;
- idr_init(>map_idr);
-
dma_node = of_parse_phandle(node, "dma-masters", 0);
if (!dma_node) {
dev_err(>dev, "Can't get DMA master node\n");
@@ -322,6 +331,12 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
}
of_node_put(dma_node);
+ xbar->dma_inuse = devm_kcalloc(>dev,
+ BITS_TO_LONGS(xbar->dma_requests),
+ sizeof(unsigned long), GFP_KERNEL);
+ if (!xbar->dma_inuse)
+ return -ENOMEM;
+
if (of_property_read_u32(node, "dma-requests", >xbar_requests)) {
dev_info(>dev,
"Missing XBAR input information, using %u.\n",
@@ -343,6 +358,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
xbar->dmarouter.route_free = ti_dra7_xbar_free;
xbar->dma_offset = (u32)match->data;
+ mutex_init(>mutex);
platform_set_drvdata(pdev, xbar);
/* Reset the crossbar */
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] dmaengine: ti-dma-crossbar: dra7: Support for eDMA with new bindings
Allow the crossbar driver to be used with the eDMA node with non legacy
binding.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index dac7ae06cc58..e107779b1a2e 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -289,6 +289,10 @@ static const struct of_device_id ti_dra7_master_match[] = {
.compatible = "ti,edma3",
.data = (void *)TI_XBAR_EDMA_OFFSET,
},
+ {
+ .compatible = "ti,edma3-tpcc",
+ .data = (void *)TI_XBAR_EDMA_OFFSET,
+ },
{},
};
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr
For the record...
On 10/29/2015 10:28 AM, Peter Ujfalusi wrote:
> The use of idr was nice, but it was a bit heavy and we did not need the
> features it provides. Using simple bitmap to track allocated DMA channels
> is adequate here and it will be easier to add support for reserving
> channels later on.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> - map->xbar_out = idr_alloc(>map_idr, NULL, 0, xbar->dma_requests,
> - GFP_KERNEL);
> + mutex_lock(>mutex);
> + map->xbar_out = find_next_zero_bit(xbar->dma_inuse, xbar->dma_requests,
> +0);
find_first_zero_bit() ;)
> + mutex_unlock(>mutex);
> + if (map->xbar_out) {
Well, this is obviously wrong... Should have been:
if (map->xbar_out == xbar->dma_requests) {
> + dev_err(>dev, "Run out of free DMA requests\n");
> + kfree(map);
> + return ERR_PTR(-ENOMEM);
> + }
> + set_bit(map->xbar_out, xbar->dma_inuse);
> +
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] dmaengine: ti-dma-crossbar: channel reserving and edma3-tpcc support
Hi, Changes since v1: - Fixed issue introduced by the bitops patch: wrong error check, also switch to use find_first_zero_bit() instead of find_next_zero_bit() Cover letter: This series depends on the eDMA work I have done, which has been now applied: https://lkml.org/lkml/2015/10/16/64 DRA7 family of chips have both sDMA and eDMA. Currently only sDMA can be used becasue the old driver stack for eDMA did not allowed integration w/o hacks. Due to the nature of eDMA the crossbar needs to know which eDMA events it can use to map incoming events towards the eDMA. In eDMA a channel is wired to be used with one specific event. For example eDMA event 14 can only be handled by eDMA channel 14. The eDMA itself can be shared by different processors in the system (ARM, DSP, etc) and since ARM/Linux is the master we need to know which channels are used by other cores. Also we need to mask out channels used for memcpy from the events we use for HW triggers. Regards, Peter --- Peter Ujfalusi (3): dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges dmaengine: ti-dma-crossbar: dra7: Support for eDMA with new bindings .../devicetree/bindings/dma/ti-dma-crossbar.txt| 6 ++ drivers/dma/ti-dma-crossbar.c | 81 +++--- 2 files changed, 76 insertions(+), 11 deletions(-) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges
In eDMA the events are directly mapped to a DMA channel (for example DMA
event 14 can only be handled by DMA channel 14). If the memcpy is enabled
on the eDMA, there is a possibility that the crossbar driver would assign
DMA event number already allocated in eDMA for memcpy. Furthermore the
eDMA can be shared with DSP in which case the crossbar driver should also
avoid mapping xbar events to DSP used event numbers (or channels).
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
.../devicetree/bindings/dma/ti-dma-crossbar.txt| 6 +++
drivers/dma/ti-dma-crossbar.c | 47 --
2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
index b152a75dceae..aead5869a28d 100644
--- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
+++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
@@ -14,6 +14,10 @@ The DMA controller node need to have the following
poroperties:
Optional properties:
- ti,dma-safe-map: Safe routing value for unused request lines
+- ti,reserved-dma-request-ranges: DMA request ranges which should not be used
+ when mapping xbar input to DMA request, they are either
+ allocated to be used by for example the DSP or they are used as
+ memcpy channels in eDMA.
Notes:
When requesting channel via ti,dra7-dma-crossbar, the DMA clinet must request
@@ -46,6 +50,8 @@ sdma_xbar: dma-router@4a002b78 {
#dma-cells = <1>;
dma-requests = <205>;
ti,dma-safe-map = <0>;
+ /* Protect the sDMA request ranges: 10-14 and 100-126 */
+ ti,reserved-dma-request-ranges = <10 5>, <100 27>;
dma-masters = <>;
};
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 5fe1909d4ec4..1a41f75a4d1f 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -292,14 +292,22 @@ static const struct of_device_id ti_dra7_master_match[] =
{
{},
};
+static inline void ti_dra7_xbar_reserve(int offset, int len, unsigned long *p)
+{
+ for (; len > 0; len--)
+ clear_bit(offset + (len - 1), p);
+}
+
static int ti_dra7_xbar_probe(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
struct device_node *dma_node;
struct ti_dra7_xbar_data *xbar;
+ struct property *prop;
struct resource *res;
u32 safe_val;
+ size_t sz;
void __iomem *iomem;
int i, ret;
@@ -347,6 +355,33 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
if (!of_property_read_u32(node, "ti,dma-safe-map", _val))
xbar->safe_val = (u16)safe_val;
+
+ prop = of_find_property(node, "ti,reserved-dma-request-ranges", );
+ if (prop) {
+ const char pname[] = "ti,reserved-dma-request-ranges";
+ u32 (*rsv_events)[2];
+ size_t nelm = sz / sizeof(*rsv_events);
+ int i;
+
+ if (!nelm)
+ return -EINVAL;
+
+ rsv_events = kcalloc(nelm, sizeof(*rsv_events), GFP_KERNEL);
+ if (!rsv_events)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(node, pname, (u32 *)rsv_events,
+nelm * 2);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < nelm; i++) {
+ ti_dra7_xbar_reserve(rsv_events[i][0], rsv_events[i][1],
+xbar->dma_inuse);
+ }
+ kfree(rsv_events);
+ }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
iomem = devm_ioremap_resource(>dev, res);
if (IS_ERR(iomem))
@@ -362,15 +397,19 @@ static int ti_dra7_xbar_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, xbar);
/* Reset the crossbar */
- for (i = 0; i < xbar->dma_requests; i++)
- ti_dra7_xbar_write(xbar->iomem, i, xbar->safe_val);
+ for (i = 0; i < xbar->dma_requests; i++) {
+ if (!test_bit(i, xbar->dma_inuse))
+ ti_dra7_xbar_write(xbar->iomem, i, xbar->safe_val);
+ }
ret = of_dma_router_register(node, ti_dra7_xbar_route_allocate,
>dmarouter);
if (ret) {
/* Restore the defaults for the crossbar */
- for (i = 0; i < xbar->dma_requests; i++)
- ti_dra7_xbar_write(xbar->iomem, i, i);
+ for (i = 0; i < xbar->dma_requests; i++) {
+ if (!test_bit(i, xbar->dma_
[PATCH 3/3] dmaengine: ti-dma-crossbar: dra7: Support for eDMA with new bindings
Allow the crossbar driver to be used with the eDMA node with non legacy
binding.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 1a41f75a4d1f..b7b21a243e37 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -289,6 +289,10 @@ static const struct of_device_id ti_dra7_master_match[] = {
.compatible = "ti,edma3",
.data = (void *)TI_XBAR_EDMA_OFFSET,
},
+ {
+ .compatible = "ti,edma3-tpcc",
+ .data = (void *)TI_XBAR_EDMA_OFFSET,
+ },
{},
};
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] dmaengine: ti-dma-crossbar: channel reserving and edma3-tcc support
Hi, This series depends on the eDMA work I have done, which has been now applied: https://lkml.org/lkml/2015/10/16/64 DRA7 family of chips have both sDMA and eDMA. Currently only sDMA can be used becasue the old driver stack for eDMA did not allowed integration w/o hacks. Due to the nature of eDMA the crossbar needs to know which eDMA events it can use to map incoming events towards the eDMA. In eDMA a channel is wired to be used with one specific event. For example eDMA event 14 can only be handled by eDMA channel 14. The eDMA itself can be shared by different processors in the system (ARM, DSP, etc) and since ARM/Linux is the master we need to know which channels are used by other cores. Also we need to mask out channels used for memcpy from the events we use for HW triggers. Regards, Peter --- Peter Ujfalusi (3): dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges dmaengine: ti-dma-crossbar: dra7: Support for eDMA with new bindings .../devicetree/bindings/dma/ti-dma-crossbar.txt| 6 ++ drivers/dma/ti-dma-crossbar.c | 81 +++--- 2 files changed, 76 insertions(+), 11 deletions(-) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr
The use of idr was nice, but it was a bit heavy and we did not need the
features it provides. Using simple bitmap to track allocated DMA channels
is adequate here and it will be easier to add support for reserving
channels later on.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index a415edbe61b1..5fe1909d4ec4 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -198,7 +197,8 @@ struct ti_dra7_xbar_data {
void __iomem *iomem;
struct dma_router dmarouter;
- struct idr map_idr;
+ struct mutex mutex;
+ unsigned long *dma_inuse;
u16 safe_val; /* Value to rest the crossbar lines */
u32 xbar_requests; /* number of DMA requests connected to XBAR */
@@ -225,7 +225,9 @@ static void ti_dra7_xbar_free(struct device *dev, void
*route_data)
map->xbar_in, map->xbar_out);
ti_dra7_xbar_write(xbar->iomem, map->xbar_out, xbar->safe_val);
- idr_remove(>map_idr, map->xbar_out);
+ mutex_lock(>mutex);
+ clear_bit(map->xbar_out, xbar->dma_inuse);
+ mutex_unlock(>mutex);
kfree(map);
}
@@ -255,8 +257,17 @@ static void *ti_dra7_xbar_route_allocate(struct
of_phandle_args *dma_spec,
return ERR_PTR(-ENOMEM);
}
- map->xbar_out = idr_alloc(>map_idr, NULL, 0, xbar->dma_requests,
- GFP_KERNEL);
+ mutex_lock(>mutex);
+ map->xbar_out = find_next_zero_bit(xbar->dma_inuse, xbar->dma_requests,
+ 0);
+ mutex_unlock(>mutex);
+ if (map->xbar_out) {
+ dev_err(>dev, "Run out of free DMA requests\n");
+ kfree(map);
+ return ERR_PTR(-ENOMEM);
+ }
+ set_bit(map->xbar_out, xbar->dma_inuse);
+
map->xbar_in = (u16)dma_spec->args[0];
dma_spec->args[0] = map->xbar_out + xbar->dma_offset;
@@ -299,8 +310,6 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
if (!xbar)
return -ENOMEM;
- idr_init(>map_idr);
-
dma_node = of_parse_phandle(node, "dma-masters", 0);
if (!dma_node) {
dev_err(>dev, "Can't get DMA master node\n");
@@ -322,6 +331,12 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
}
of_node_put(dma_node);
+ xbar->dma_inuse = devm_kcalloc(>dev,
+ BITS_TO_LONGS(xbar->dma_requests),
+ sizeof(unsigned long), GFP_KERNEL);
+ if (!xbar->dma_inuse)
+ return -ENOMEM;
+
if (of_property_read_u32(node, "dma-requests", >xbar_requests)) {
dev_info(>dev,
"Missing XBAR input information, using %u.\n",
@@ -343,6 +358,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
xbar->dmarouter.route_free = ti_dra7_xbar_free;
xbar->dma_offset = (u32)match->data;
+ mutex_init(>mutex);
platform_set_drvdata(pdev, xbar);
/* Reset the crossbar */
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/14] dmaengine: edma: Merge the of parsing functions
Instead of nesting functions just merge them since the resulting function
is still small and readable.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index c1b8bb09c221..d4d71e60da1b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1921,31 +1921,23 @@ static int edma_xbar_event_map(struct device *dev,
struct edma_soc_info *pdata,
return 0;
}
-static int edma_of_parse_dt(struct device *dev, struct edma_soc_info *pdata)
-{
- int ret = 0;
- struct property *prop;
- size_t sz;
-
- prop = of_find_property(dev->of_node, "ti,edma-xbar-event-map", );
- if (prop)
- ret = edma_xbar_event_map(dev, pdata, sz);
-
- return ret;
-}
-
static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev)
{
struct edma_soc_info *info;
+ struct property *prop;
+ size_t sz;
int ret;
info = devm_kzalloc(dev, sizeof(struct edma_soc_info), GFP_KERNEL);
if (!info)
return ERR_PTR(-ENOMEM);
- ret = edma_of_parse_dt(dev, info);
- if (ret)
- return ERR_PTR(ret);
+ prop = of_find_property(dev->of_node, "ti,edma-xbar-event-map", );
+ if (prop) {
+ ret = edma_xbar_event_map(dev, info, sz);
+ if (ret)
+ return ERR_PTR(ret);
+ }
return info;
}
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/14] dmaengine: edma: Refactor the dma device and channel struct initialization
Move all code under one function to do the dma device and eDMA channel
related setup so they are not scattered around the driver.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 79 +-
1 file changed, 37 insertions(+), 42 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ea851ab05c8e..e1b0e6864f27 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1756,18 +1756,49 @@ static enum dma_status edma_tx_status(struct dma_chan
*chan,
return ret;
}
-static void __init edma_chan_init(struct edma_cc *ecc, struct dma_device *dma,
- struct edma_chan *echans)
+#define EDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static void edma_dma_init(struct edma_cc *ecc)
{
+ struct dma_device *ddev = >dma_slave;
int i, j;
+ dma_cap_zero(ddev->cap_mask);
+ dma_cap_set(DMA_SLAVE, ddev->cap_mask);
+ dma_cap_set(DMA_CYCLIC, ddev->cap_mask);
+ dma_cap_set(DMA_MEMCPY, ddev->cap_mask);
+
+ ddev->device_prep_slave_sg = edma_prep_slave_sg;
+ ddev->device_prep_dma_cyclic = edma_prep_dma_cyclic;
+ ddev->device_prep_dma_memcpy = edma_prep_dma_memcpy;
+ ddev->device_alloc_chan_resources = edma_alloc_chan_resources;
+ ddev->device_free_chan_resources = edma_free_chan_resources;
+ ddev->device_issue_pending = edma_issue_pending;
+ ddev->device_tx_status = edma_tx_status;
+ ddev->device_config = edma_slave_config;
+ ddev->device_pause = edma_dma_pause;
+ ddev->device_resume = edma_dma_resume;
+ ddev->device_terminate_all = edma_terminate_all;
+
+ ddev->src_addr_widths = EDMA_DMA_BUSWIDTHS;
+ ddev->dst_addr_widths = EDMA_DMA_BUSWIDTHS;
+ ddev->directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+ ddev->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+
+ ddev->dev = ecc->dev;
+
+ INIT_LIST_HEAD(>channels);
+
for (i = 0; i < ecc->num_channels; i++) {
- struct edma_chan *echan = [i];
+ struct edma_chan *echan = >slave_chans[i];
echan->ch_num = EDMA_CTLR_CHAN(ecc->id, i);
echan->ecc = ecc;
echan->vchan.desc_free = edma_desc_free;
- vchan_init(>vchan, dma);
+ vchan_init(>vchan, ddev);
INIT_LIST_HEAD(>node);
for (j = 0; j < EDMA_MAX_SLOTS; j++)
@@ -1775,36 +1806,6 @@ static void __init edma_chan_init(struct edma_cc *ecc,
struct dma_device *dma,
}
}
-#define EDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
-BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
-BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
-BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
-
-static void edma_dma_init(struct edma_cc *ecc, struct dma_device *dma,
- struct device *dev)
-{
- dma->device_prep_slave_sg = edma_prep_slave_sg;
- dma->device_prep_dma_cyclic = edma_prep_dma_cyclic;
- dma->device_prep_dma_memcpy = edma_prep_dma_memcpy;
- dma->device_alloc_chan_resources = edma_alloc_chan_resources;
- dma->device_free_chan_resources = edma_free_chan_resources;
- dma->device_issue_pending = edma_issue_pending;
- dma->device_tx_status = edma_tx_status;
- dma->device_config = edma_slave_config;
- dma->device_pause = edma_dma_pause;
- dma->device_resume = edma_dma_resume;
- dma->device_terminate_all = edma_terminate_all;
-
- dma->src_addr_widths = EDMA_DMA_BUSWIDTHS;
- dma->dst_addr_widths = EDMA_DMA_BUSWIDTHS;
- dma->directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
- dma->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
-
- dma->dev = dev;
-
- INIT_LIST_HEAD(>channels);
-}
-
static int edma_setup_from_hw(struct device *dev, struct edma_soc_info *pdata,
struct edma_cc *ecc)
{
@@ -2137,14 +2138,8 @@ static int edma_probe(struct platform_device *pdev)
}
ecc->info = info;
- dma_cap_zero(ecc->dma_slave.cap_mask);
- dma_cap_set(DMA_SLAVE, ecc->dma_slave.cap_mask);
- dma_cap_set(DMA_CYCLIC, ecc->dma_slave.cap_mask);
- dma_cap_set(DMA_MEMCPY, ecc->dma_slave.cap_mask);
-
- edma_dma_init(ecc, >dma_slave, dev);
-
- edma_chan_init(ecc, >dma_slave, ecc->slave_chans);
+ /* Init the dma device and channels */
+ edma_dma_init(ecc);
for
[PATCH v2 12/14] dmaengine: edma: New device tree binding
With the old binding and driver architecture we had many issues:
No way to assign eDMA channels to event queues, thus not able to tune the
system by moving specific DMA channels to low/high priority servicing. We
moved the cyclic channels to high priority within the code, but that was
just a workaround to this issue.
Memcopy was fundamentally broken: even if the driver scanned the DT/devices
in the booted system for direct DMA users (which is not effective when the
events are going through a crossbar) and created a map of 'used' channels,
this information was not really usable. Since via dmaengien API the eDMA
driver will be called with _some_ channel number, we would try to request
this channel when any channel is requested for memcpy. By luck we got
channel which is not used by any device most of the time so things worked,
but if a device would have been using the given channel, but not requested
it, the memcpy channel would have been waiting for HW event.
The old code had the am33xx/am43xx DMA event router handling embedded. This
should have been done in a separate driver since it is not part of the
actual eDMA IP.
There were no way to 'lock' PaRAM slots to be used by the DSP for example
when booting with DT.
In DT boot the edma node used more than one hwmod which is not a good
practice and the kernel prints warning because of this.
With the new bindings and the changes in the driver we can:
- No regression with Legacy binding and non DT boot
- DMA channels can be assigned to any TC (to set priority)
- PaRAM slots can be reserved for other cores to use
- Dynamic power management for CC and TCs, if only TC0 is used all other TC
can be powered down for example
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 117 +-
drivers/dma/edma.c| 486 +++---
include/linux/platform_data/edma.h| 3 +
3 files changed, 459 insertions(+), 147 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 5ba525a10035..d3d0a4fb1c73 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -1,4 +1,119 @@
-TI EDMA
+Texas Instruments eDMA
+
+The eDMA3 consists of two components: Channel controller (CC) and Transfer
+Controller(s) (TC). The CC is the main entry for DMA users since it is
+responsible for the DMA channel handling, while the TCs are responsible to
+execute the actual DMA tansfer.
+
+--
+eDMA3 Channel Controller
+
+Required properties:
+- compatible: "ti,edma3-tpcc" for the channel controller(s)
+- #dma-cells: Should be set to <2>. The first number is the DMA request
+ number and the second is the TC the channel is serviced on.
+- reg: Memory map of eDMA CC
+- reg-names: "edma3_cc"
+- interrupts: Interrupt lines for CCINT, MPERR and CCERRINT.
+- interrupt-names: "edma3_ccint", "emda3_mperr" and "edma3_ccerrint"
+- ti,tptcs:List of TPTCs associated with the eDMA in the following form:
+ <_phandle TC_priority_number>. The highest priority is 0.
+
+Optional properties:
+- ti,hwmods: Name of the hwmods associated to the eDMA CC
+- ti,edma-memcpy-channels: List of channels allocated to be used for memcpy,
iow
+ these channels will be SW triggered channels. The list must
+ contain 16 bits numbers, see example.
+- ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
+ the driver, they are allocated to be used by for example the
+ DSP. See example.
+
+--
+eDMA3 Transfer Controller
+
+Required properties:
+- compatible: "ti,edma3-tptc" for the transfer controller(s)
+- reg: Memory map of eDMA TC
+- interrupts: Interrupt number for TCerrint.
+
+Optional properties:
+- ti,hwmods: Name of the hwmods associated to the given eDMA TC
+- interrupt-names: "edma3_tcerrint"
+
+--
+Example:
+
+edma: edma@4900 {
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
+ interrupts = <12 13 14>;
+ interrupt-names = "edma3_ccint", "emda3_mperr", "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 7>, <_tptc2 0>;
+
+ /* Channel 20 and 21 is allocated for memcpy */
+ ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+ /* The following
[PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/am335x-evm.dts| 9 +---
arch/arm/boot/dts/am335x-pepper.dts | 11 +
arch/arm/boot/dts/am33xx.dtsi | 96 ++---
3 files changed, 73 insertions(+), 43 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 1942a5c8132d..507980672c32 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -743,8 +743,8 @@
{
/* these are on the crossbar and are outlined in the
xbar-event-map element */
- dmas = < 12
-13>;
+ dmas = <_xbar 12 0 1
+ _xbar 13 0 2>;
dma-names = "tx", "rx";
status = "okay";
vmmc-supply = <_en_reg>;
@@ -766,11 +766,6 @@
};
};
- {
- ti,edma-xbar-event-map = /bits/ 16 <1 12
- 2 13>;
-};
-
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/am335x-pepper.dts
b/arch/arm/boot/dts/am335x-pepper.dts
index 7106114c7464..39073b921664 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -339,13 +339,6 @@
ti,non-removable;
};
- {
- /* Map eDMA MMC2 Events from Crossbar */
- ti,edma-xbar-event-map = /bits/ 16 <1 12
-2 13>;
-};
-
-
{
/* Wifi & Bluetooth on MMC #3 */
status = "okay";
@@ -354,8 +347,8 @@
vmmmc-supply = <_reg>;
bus-width = <4>;
ti,non-removable;
- dmas = < 12
-13>;
+ dmas = <_xbar 12 0 1
+ _xbar 13 0 2>;
dma-names = "tx", "rx";
};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index d23e2524d694..6053e75c6e99 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -174,12 +174,54 @@
};
edma: edma@4900 {
- compatible = "ti,edma3";
- ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
- reg = <0x4900 0x1>,
- <0x44e10f90 0x40>;
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
interrupts = <12 13 14>;
- #dma-cells = <1>;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 5>,
+ <_tptc2 0>;
+
+ ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+ };
+
+ edma_tptc0: tptc@4980 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc0";
+ reg = <0x4980 0x10>;
+ interrupts = <112>;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc1: tptc@4990 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc1";
+ reg = <0x4990 0x10>;
+ interrupts = <113>;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc2: tptc@49a0 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc2";
+ reg = <0x49a0 0x10>;
+ interrupts = <114>;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_xbar: dma-router@44e10f90 {
+ compatible = "ti,am335x-edma-crossbar";
+ reg = <0x44e10f90 0x40>;
+
+ #dma-cells = <3>;
+
[PATCH v2 11/14] dmaengine: Kconfig: edma: Select TI_DMA_CROSSBAR in case of ARCH_OMAP
Since the crossbar is needed for eDMA when it is used on OMAP like platforms (am335x/am437x and later DRA7xx), select the crossbar to be built if ARCH_OMAP is set. Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> --- drivers/dma/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index af81a7a1b597..e6cd1a32025a 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -486,6 +486,7 @@ config TI_EDMA depends on ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE select DMA_ENGINE select DMA_VIRTUAL_CHANNELS + select TI_DMA_CROSSBAR if ARCH_OMAP default n help Enable support for the TI EDMA controller. This DMA -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/14] dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx
The DMA event crossbar on AM33xx/AM43xx is different from the one found in
DRA7x family.
Instead of a single event crossbar it has 64 identical mux attached to each
eDMA event line. When the 0 event mux is selected, the default mapped event
is going to be routed to the corresponding eDMA event line. If different
mux is selected, then the selected event is going to be routed to the given
eDMA event.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
.../devicetree/bindings/dma/ti-dma-crossbar.txt| 15 +-
drivers/dma/ti-dma-crossbar.c | 251 ++---
2 files changed, 234 insertions(+), 32 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
index 63a48928f3a8..b152a75dceae 100644
--- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
+++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
@@ -2,9 +2,10 @@ Texas Instruments DMA Crossbar (DMA request router)
Required properties:
- compatible: "ti,dra7-dma-crossbar" for DRA7xx DMA crossbar
+ "ti,am335x-edma-crossbar" for AM335x and AM437x
- reg: Memory map for accessing module
-- #dma-cells: Should be set to <1>.
- Clients should use the crossbar request number (input)
+- #dma-cells: Should be set to to match with the DMA controller's dma-cells
+ for ti,dra7-dma-crossbar and <3> for ti,am335x-edma-crossbar.
- dma-requests:Number of DMA requests the crossbar can receive
- dma-masters: phandle pointing to the DMA controller
@@ -14,6 +15,15 @@ The DMA controller node need to have the following
poroperties:
Optional properties:
- ti,dma-safe-map: Safe routing value for unused request lines
+Notes:
+When requesting channel via ti,dra7-dma-crossbar, the DMA clinet must request
+the DMA event number as crossbar ID (input to the DMA crossbar).
+
+For ti,am335x-edma-crossbar: the meaning of parameters of dmas for clients:
+dmas = <_xbar 12 0 1>; where <12> is the DMA request number, <0> is the TC
+the event should be assigned and <1> is the mux selection for in the crossbar.
+When mux 0 is used the DMA channel can be requested directly from edma node.
+
Example:
/* DMA controller */
@@ -47,6 +57,7 @@ uart1: serial@4806a000 {
ti,hwmods = "uart1";
clock-frequency = <4800>;
status = "disabled";
+ /* Requesting crossbar input 49 and 50 */
dmas = <_xbar 49>, <_xbar 50>;
dma-names = "tx", "rx";
};
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 5cce8c9d0026..a415edbe61b1 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -17,13 +17,184 @@
#include
#include
-#define TI_XBAR_OUTPUTS127
-#define TI_XBAR_INPUTS 256
+#define TI_XBAR_DRA7 0
+#define TI_XBAR_AM335X 1
+
+static const struct of_device_id ti_dma_xbar_match[] = {
+ {
+ .compatible = "ti,dra7-dma-crossbar",
+ .data = (void *)TI_XBAR_DRA7,
+ },
+ {
+ .compatible = "ti,am335x-edma-crossbar",
+ .data = (void *)TI_XBAR_AM335X,
+ },
+ {},
+};
+
+/* Crossbar on AM335x/AM437x family */
+#define TI_AM335X_XBAR_LINES 64
+
+struct ti_am335x_xbar_data {
+ void __iomem *iomem;
+
+ struct dma_router dmarouter;
+
+ u32 xbar_events; /* maximum number of events to select in xbar */
+ u32 dma_requests; /* number of DMA requests on eDMA */
+};
+
+struct ti_am335x_xbar_map {
+ u16 dma_line;
+ u16 mux_val;
+};
+
+static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u16
val)
+{
+ writeb_relaxed(val & 0x1f, iomem + event);
+}
+
+static void ti_am335x_xbar_free(struct device *dev, void *route_data)
+{
+ struct ti_am335x_xbar_data *xbar = dev_get_drvdata(dev);
+ struct ti_am335x_xbar_map *map = route_data;
+
+ dev_dbg(dev, "Unmapping XBAR event %u on channel %u\n",
+ map->mux_val, map->dma_line);
+
+ ti_am335x_xbar_write(xbar->iomem, map->dma_line, 0);
+ kfree(map);
+}
+
+static void *ti_am335x_xbar_route_allocate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
+ struct ti_am335x_xbar_data *xbar = platform_get_drvdata(pdev);
+ struct ti_am335x_xbar_map *map;
+
+ if (dma_spec->args_count != 3)
+ return ERR_PTR(-EINVAL);
+
+ if (dma_spec->args[2] >= xbar->xbar_events) {
+ dev_err(>dev, "Invalid XBAR event number: %d\n",
+ dma_spec->args[2]);
+ return
[PATCH v2 03/14] dmaengine: edma: Simplify function parameter list for channel operations
Instead of passing a pointer to struct edma_cc and the channel number,
pass only the pointer to the edma_chan structure for the given channel.
This struct contains all the information needed by the functions and the
use of this makes it obvious that most of the sanity checks can be removed
from the driver.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 396 +
1 file changed, 123 insertions(+), 273 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index c0165e3d3396..a64befecf477 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -391,17 +391,19 @@ static inline void clear_bits(int offset, int len,
unsigned long *p)
clear_bit(offset + (len - 1), p);
}
-static void edma_map_dmach_to_queue(struct edma_cc *ecc, unsigned ch_no,
+static void edma_map_dmach_to_queue(struct edma_chan *echan,
enum dma_event_q queue_no)
{
- int bit = (ch_no & 0x7) * 4;
+ struct edma_cc *ecc = echan->ecc;
+ int channel = EDMA_CHAN_SLOT(echan->ch_num);
+ int bit = (channel & 0x7) * 4;
/* default to low priority queue */
if (queue_no == EVENTQ_DEFAULT)
queue_no = ecc->default_queue;
queue_no &= 7;
- edma_modify_array(ecc, EDMA_DMAQNUM, (ch_no >> 3), ~(0x7 << bit),
+ edma_modify_array(ecc, EDMA_DMAQNUM, (channel >> 3), ~(0x7 << bit),
queue_no << bit);
}
@@ -413,10 +415,12 @@ static void edma_assign_priority_to_queue(struct edma_cc
*ecc, int queue_no,
edma_modify(ecc, EDMA_QUEPRI, ~(0x7 << bit), ((priority & 0x7) << bit));
}
-static void edma_set_chmap(struct edma_cc *ecc, int channel, int slot)
+static void edma_set_chmap(struct edma_chan *echan, int slot)
{
+ struct edma_cc *ecc = echan->ecc;
+ int channel = EDMA_CHAN_SLOT(echan->ch_num);
+
if (ecc->chmap_exist) {
- channel = EDMA_CHAN_SLOT(channel);
slot = EDMA_CHAN_SLOT(slot);
edma_write_array(ecc, EDMA_DCHMAP, channel, (slot << 5));
}
@@ -476,18 +480,19 @@ static int prepare_unused_channel_list(struct device
*dev, void *data)
return 0;
}
-static void edma_setup_interrupt(struct edma_cc *ecc, unsigned lch, bool
enable)
+static void edma_setup_interrupt(struct edma_chan *echan, bool enable)
{
- lch = EDMA_CHAN_SLOT(lch);
+ struct edma_cc *ecc = echan->ecc;
+ int channel = EDMA_CHAN_SLOT(echan->ch_num);
if (enable) {
- edma_shadow0_write_array(ecc, SH_ICR, lch >> 5,
-BIT(lch & 0x1f));
- edma_shadow0_write_array(ecc, SH_IESR, lch >> 5,
-BIT(lch & 0x1f));
+ edma_shadow0_write_array(ecc, SH_ICR, channel >> 5,
+BIT(channel & 0x1f));
+ edma_shadow0_write_array(ecc, SH_IESR, channel >> 5,
+BIT(channel & 0x1f));
} else {
- edma_shadow0_write_array(ecc, SH_IECR, lch >> 5,
-BIT(lch & 0x1f));
+ edma_shadow0_write_array(ecc, SH_IECR, channel >> 5,
+BIT(channel & 0x1f));
}
}
@@ -613,40 +618,25 @@ static dma_addr_t edma_get_position(struct edma_cc *ecc,
unsigned slot,
return edma_read(ecc, offs);
}
-/*---*/
-/**
- * edma_start - start dma on a channel
- * @ecc: pointer to edma_cc struct
- * @channel: channel being activated
- *
+/*
* Channels with event associations will be triggered by their hardware
* events, and channels without such associations will be triggered by
* software. (At this writing there is no interface for using software
* triggers except with channels that don't support hardware triggers.)
- *
- * Returns zero on success, else negative errno.
*/
-static int edma_start(struct edma_cc *ecc, unsigned channel)
+static void edma_start(struct edma_chan *echan)
{
- if (ecc->id != EDMA_CTLR(channel)) {
- dev_err(ecc->dev, "%s: ID mismatch for eDMA%d: %d\n", __func__,
- ecc->id, EDMA_CTLR(channel));
- return -EINVAL;
- }
- channel = EDMA_CHAN_SLOT(channel);
-
- if (channel < ecc->num_channels) {
- int j = channel >> 5;
- unsigned int mask = BIT(channel & 0x1f);
+ struct edma_cc *ecc = echan->ecc;
+ int channel = EDMA_CHAN_SLOT(echan->ch_num);
+ int j = (channel >> 5);
+ unsigned int mask = BIT(channel & 0x1f);
+ if (test_bit(
[PATCH v2 06/14] dmaengine: edma: Get qDMA channel information from HW also
Query the number of qDMA channels from CCCFG register.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index eaf1f9e4bde0..ea851ab05c8e 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -107,6 +107,7 @@
/* CCCFG register */
#define GET_NUM_DMACH(x) (x & 0x7) /* bits 0-2 */
+#define GET_NUM_QDMACH(x) (x & 0x70 >> 4) /* bits 4-6 */
#define GET_NUM_PAENTRY(x) ((x & 0x7000) >> 12) /* bits 12-14 */
#define GET_NUM_EVQUE(x) ((x & 0x7) >> 16) /* bits 16-18 */
#define GET_NUM_REGN(x)((x & 0x30) >> 20) /* bits 20-21 */
@@ -220,6 +221,7 @@ struct edma_cc {
/* eDMA3 resource information */
unsignednum_channels;
+ unsignednum_qchannels;
unsignednum_region;
unsignednum_slots;
unsignednum_tc;
@@ -1819,6 +1821,9 @@ static int edma_setup_from_hw(struct device *dev, struct
edma_soc_info *pdata,
value = GET_NUM_DMACH(cccfg);
ecc->num_channels = BIT(value + 1);
+ value = GET_NUM_QDMACH(cccfg);
+ ecc->num_qchannels = value * 2;
+
value = GET_NUM_PAENTRY(cccfg);
ecc->num_slots = BIT(value + 4);
@@ -1830,6 +1835,7 @@ static int edma_setup_from_hw(struct device *dev, struct
edma_soc_info *pdata,
dev_dbg(dev, "eDMA3 CC HW configuration (cccfg: 0x%08x):\n", cccfg);
dev_dbg(dev, "num_region: %u\n", ecc->num_region);
dev_dbg(dev, "num_channels: %u\n", ecc->num_channels);
+ dev_dbg(dev, "num_qchannels: %u\n", ecc->num_qchannels);
dev_dbg(dev, "num_slots: %u\n", ecc->num_slots);
dev_dbg(dev, "num_tc: %u\n", ecc->num_tc);
dev_dbg(dev, "chmap_exist: %s\n", ecc->chmap_exist ? "yes" : "no");
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/14] dmaengine: edma: Do not allocate memory for edma_rsv_info in case of DT boot
The channel/slot reservation is not supported when booted with DT so there is not need to allocate memory. Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> --- drivers/dma/edma.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index e1b0e6864f27..c1b8bb09c221 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -1926,12 +1926,6 @@ static int edma_of_parse_dt(struct device *dev, struct edma_soc_info *pdata) int ret = 0; struct property *prop; size_t sz; - struct edma_rsv_info *rsv_info; - - rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL); - if (!rsv_info) - return -ENOMEM; - pdata->rsv = rsv_info; prop = of_find_property(dev->of_node, "ti,edma-xbar-event-map", ); if (prop) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/14] dmaenigne: edma/ti-crossbar: fixes, new bindings
Hi, Changes since v1: - Comments in the memcpy optimization patch extended - The crossbar patch has been improved: - debug prints changed - fallback xbar parameters now type specific as the fallback values for DRA7 are not valid for AM33xx crossbar. - New patch for Kconfig to select the crossbar in case the eDMA is used on OMAP platforms This series depends on the eDMA driver merger series (v5) [1]. The first two patch is to improve the memcpy functionality by removing the alignment constraint and speed optimization (memcpy speed is up from ~3MB/s to ~15MB/s). The rest of the series consits of smaller cleanup patches and the new DT binding implementation for the eDMA3 and the crossbar found in am33xx/am43xx. The new DT binding was needed for several reasons: - the original binding was 'Documentating' the Linux driver functionality. - the use of multiple ti,hwmod properties in the binding need to be removed. In recent kernels we have kernel warning printed because of this. - No way to set queue priorities - No way to fix the memcpy issue [2] - Missing infrastructure to deal with multi core usage (ARM + DSP) - eDMA behind of a crossbar was not safe to use - it could be hacked to work. While some of these issues migh have been fixed with the old binding by adding new properties all along, but the TPCC and TPTC separation (to fix the hwmod warning and to be able to have better power management) and the need to be able to select TC to execute the given channel demanded new compatible for the eDMA3 components. [1] http://www.spinics.net/lists/arm-kernel/msg452373.html [2] memcpy issue with the old stack ever since the eDMA got support via dmaengine and the memcpy was enabled it has been mostly broken and worked by luck only. The root of the issue was that the channels for the memcpy was taken from the same pool as the slave channels. Since in eDMA a channel number is wired to be used with the same event number (HW request) this had it's faults. With dmaengine the driver will always be asked for a channel since the channel selection for any channel is done in the dmaengine layer. The whole magic of builing the unused channel list and stuff did not help: Let assume that in DT we have users for channel 0,1,2,3,10,11. The eDMA driver would mark these channels as used - which means they are HW syncronized. If we have drivers enabled which uses channel 0,1,10,11 and some driver request for a channel for memcpy, it will get the channel 2 and when this memcpy channel is used it would have been assumed to be HW triggered, so the memcpy would not work at all. There were no way to fix this within the old driver stack and with the old bindings. I'm maintaining this (and other patches) in my linux-next-wip branch if someone wants to try it out w/o needing to hunt for patches: https://github.com/omap-audio/linux-audio.git peter/linux-next-wip Regards, Peter --- Peter Ujfalusi (14): dmaengine: edma: Remove alignment constraint for memcpy dmaengine: edma: Optimize memcpy operation dmaengine: edma: Simplify function parameter list for channel operations dmaengine: edma: Correct PaRAM access function names (_parm_ to _param_) dmaengine: edma: Merge map_dmach_to_queue into assign_channel_eventq dmaengine: edma: Get qDMA channel information from HW also dmaengine: edma: Refactor the dma device and channel struct initialization dmaengine: edma: Do not allocate memory for edma_rsv_info in case of DT boot dmaengine: edma: Merge the of parsing functions dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx dmaengine: Kconfig: edma: Select TI_DMA_CROSSBAR in case of ARCH_OMAP dmaengine: edma: New device tree binding ARM: DTS: am33xx: Use the new DT bindings for the eDMA3 ARM: DTS: am437x: Use the new DT bindings for the eDMA3 .../devicetree/bindings/dma/ti-dma-crossbar.txt| 15 +- Documentation/devicetree/bindings/dma/ti-edma.txt | 117 ++- arch/arm/boot/dts/am335x-evm.dts |9 +- arch/arm/boot/dts/am335x-pepper.dts| 11 +- arch/arm/boot/dts/am33xx.dtsi | 96 +- arch/arm/boot/dts/am4372.dtsi | 82 +- arch/arm/boot/dts/am437x-gp-evm.dts|9 +- drivers/dma/Kconfig|1 + drivers/dma/edma.c | 1066 +++- drivers/dma/ti-dma-crossbar.c | 251 - include/linux/platform_data/edma.h |3 + 11 files changed, 1060 insertions(+), 600 deletions(-) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 14/14] ARM: DTS: am437x: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/am4372.dtsi | 82 -
arch/arm/boot/dts/am437x-gp-evm.dts | 9 +---
2 files changed, 64 insertions(+), 27 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c9701e..a39428dd85b2 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -183,14 +183,56 @@
};
edma: edma@4900 {
- compatible = "ti,edma3";
- ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
- reg = <0x4900 0x1>,
- <0x44e10f90 0x10>;
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
interrupts = ,
- ,
- ;
- #dma-cells = <1>;
+,
+;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 5>,
+ <_tptc2 0>;
+
+ ti,edma-memcpy-channels = /bits/ 16 <32 33>;
+ };
+
+ edma_tptc0: tptc@4980 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc0";
+ reg = <0x4980 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc1: tptc@4990 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc1";
+ reg = <0x4990 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc2: tptc@49a0 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc2";
+ reg = <0x49a0 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_xbar: dma-router@44e10f90 {
+ compatible = "ti,am335x-edma-crossbar";
+ reg = <0x44e10f90 0x40>;
+
+ #dma-cells = <3>;
+ dma-requests = <64>;
+
+ dma-masters = <>;
};
uart0: serial@44e09000 {
@@ -495,8 +537,8 @@
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
- dmas = < 24
-25>;
+ dmas = < 24 0>,
+ < 25 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabled";
@@ -507,8 +549,8 @@
reg = <0x481d8000 0x1000>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
- dmas = < 2
-3>;
+ dmas = < 2 0>,
+ < 3 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabled";
@@ -776,7 +818,7 @@
compatible = "ti,omap5-sham";
ti,hwmods = "sham";
reg = <0x5310 0x300>;
- dmas = < 36>;
+ dmas = < 36 0>;
dma-names = "rx";
[PATCH v2 02/14] dmaengine: edma: Optimize memcpy operation
If the transfer is shorted then 64K we can complete it with one ACNT burst
by configuring ACNT to the length of the copy, this require one paRAM slot.
Otherwise we use two paRAM slots for the copy:
slot1: will copy (length / 32767) number of 32767 byte long blocks
slot2: will be configured to copy the remaining data.
According to tests this patch increases the throughput of memcpy from
~3MB/s to 15MB/s
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 96 ++
1 file changed, 75 insertions(+), 21 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index b36dfa5458cb..c0165e3d3396 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1107,19 +1107,16 @@ static int edma_dma_resume(struct dma_chan *chan)
*/
static int edma_config_pset(struct dma_chan *chan, struct edma_pset *epset,
dma_addr_t src_addr, dma_addr_t dst_addr, u32 burst,
- enum dma_slave_buswidth dev_width,
- unsigned int dma_length,
+ unsigned int acnt, unsigned int dma_length,
enum dma_transfer_direction direction)
{
struct edma_chan *echan = to_edma_chan(chan);
struct device *dev = chan->device->dev;
struct edmacc_param *param = >param;
- int acnt, bcnt, ccnt, cidx;
+ int bcnt, ccnt, cidx;
int src_bidx, dst_bidx, src_cidx, dst_cidx;
int absync;
- acnt = dev_width;
-
/* src/dst_maxburst == 0 is the same case as src/dst_maxburst == 1 */
if (!burst)
burst = 1;
@@ -1320,41 +1317,98 @@ static struct dma_async_tx_descriptor
*edma_prep_dma_memcpy(
struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
size_t len, unsigned long tx_flags)
{
- int ret;
+ int ret, nslots;
struct edma_desc *edesc;
struct device *dev = chan->device->dev;
struct edma_chan *echan = to_edma_chan(chan);
- unsigned int width;
+ unsigned int width, pset_len;
if (unlikely(!echan || !len))
return NULL;
- edesc = kzalloc(sizeof(*edesc) + sizeof(edesc->pset[0]), GFP_ATOMIC);
+ if (len < SZ_64K) {
+ /*
+* Transfer size less than 64K can be handled with one paRAM
+* slot and with one burst.
+* ACNT = length
+*/
+ width = len;
+ pset_len = len;
+ nslots = 1;
+ } else {
+ /*
+* Transfer size bigger than 64K will be handled with maximum of
+* two paRAM slots.
+* slot1: (full_length / 32767) times 32767 bytes bursts.
+*ACNT = 32767, length1: (full_length / 32767) * 32767
+* slot2: the remaining amount of data after slot1.
+*ACNT = full_length - length1, length2 = ACNT
+*
+* When the full_length is multibple of 32767 one slot can be
+* used to complete the transfer.
+*/
+ width = SZ_32K - 1;
+ pset_len = rounddown(len, width);
+ /* One slot is enough for lengths multiple of (SZ_32K -1) */
+ if (unlikely(pset_len == len))
+ nslots = 1;
+ else
+ nslots = 2;
+ }
+
+ edesc = kzalloc(sizeof(*edesc) + nslots * sizeof(edesc->pset[0]),
+ GFP_ATOMIC);
if (!edesc) {
dev_dbg(dev, "Failed to allocate a descriptor\n");
return NULL;
}
- edesc->pset_nr = 1;
-
- width = 1 << __ffs((src | dest | len));
- if (width > DMA_SLAVE_BUSWIDTH_64_BYTES)
- width = DMA_SLAVE_BUSWIDTH_64_BYTES;
+ edesc->pset_nr = nslots;
+ edesc->residue = edesc->residue_stat = len;
+ edesc->direction = DMA_MEM_TO_MEM;
+ edesc->echan = echan;
ret = edma_config_pset(chan, >pset[0], src, dest, 1,
- width, len, DMA_MEM_TO_MEM);
- if (ret < 0)
+ width, pset_len, DMA_MEM_TO_MEM);
+ if (ret < 0) {
+ kfree(edesc);
return NULL;
+ }
edesc->absync = ret;
- /*
-* Enable intermediate transfer chaining to re-trigger channel
-* on completion of every TR, and enable transfer-completion
-* interrupt on completion of the whole transfer.
-*/
edesc->pset[0].param.opt |= ITCCHEN;
- edesc->pset[0].param.opt |= TCINTEN;
+ if (nslots == 1) {
+ /* Enable transfer complete interrupt */
+ edesc->pset[0].param.opt |= TCINTEN;
+ } else {
+ /* Enable t
[PATCH v2 05/14] dmaengine: edma: Merge map_dmach_to_queue into assign_channel_eventq
edma_assign_channel_eventq() is a wrapper around edma_map_dmach_to_queue()
We can merge the content of the later so we will have only one function
to be used for mapping channels to given eventq
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 56 +-
1 file changed, 22 insertions(+), 34 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 051a7c4593d4..eaf1f9e4bde0 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -391,22 +391,6 @@ static inline void clear_bits(int offset, int len,
unsigned long *p)
clear_bit(offset + (len - 1), p);
}
-static void edma_map_dmach_to_queue(struct edma_chan *echan,
- enum dma_event_q queue_no)
-{
- struct edma_cc *ecc = echan->ecc;
- int channel = EDMA_CHAN_SLOT(echan->ch_num);
- int bit = (channel & 0x7) * 4;
-
- /* default to low priority queue */
- if (queue_no == EVENTQ_DEFAULT)
- queue_no = ecc->default_queue;
-
- queue_no &= 7;
- edma_modify_array(ecc, EDMA_DMAQNUM, (channel >> 3), ~(0x7 << bit),
- queue_no << bit);
-}
-
static void edma_assign_priority_to_queue(struct edma_cc *ecc, int queue_no,
int priority)
{
@@ -723,6 +707,25 @@ static void edma_clean_channel(struct edma_chan *echan)
edma_write(ecc, EDMA_CCERRCLR, BIT(16) | BIT(1) | BIT(0));
}
+/* Move channel to a specific event queue */
+static void edma_assign_channel_eventq(struct edma_chan *echan,
+ enum dma_event_q eventq_no)
+{
+ struct edma_cc *ecc = echan->ecc;
+ int channel = EDMA_CHAN_SLOT(echan->ch_num);
+ int bit = (channel & 0x7) * 4;
+
+ /* default to low priority queue */
+ if (eventq_no == EVENTQ_DEFAULT)
+ eventq_no = ecc->default_queue;
+ if (eventq_no >= ecc->num_tc)
+ return;
+
+ eventq_no &= 7;
+ edma_modify_array(ecc, EDMA_DMAQNUM, (channel >> 3), ~(0x7 << bit),
+ eventq_no << bit);
+}
+
static int edma_alloc_channel(struct edma_chan *echan,
enum dma_event_q eventq_no)
{
@@ -751,7 +754,7 @@ static int edma_alloc_channel(struct edma_chan *echan,
edma_setup_interrupt(echan, true);
- edma_map_dmach_to_queue(echan, eventq_no);
+ edma_assign_channel_eventq(echan, eventq_no);
return 0;
}
@@ -764,21 +767,6 @@ static void edma_free_channel(struct edma_chan *echan)
edma_setup_interrupt(echan, false);
}
-/* Move channel to a specific event queue */
-static void edma_assign_channel_eventq(struct edma_chan *echan,
- enum dma_event_q eventq_no)
-{
- struct edma_cc *ecc = echan->ecc;
-
- /* default to low priority queue */
- if (eventq_no == EVENTQ_DEFAULT)
- eventq_no = ecc->default_queue;
- if (eventq_no >= ecc->num_tc)
- return;
-
- edma_map_dmach_to_queue(echan, eventq_no);
-}
-
static inline struct edma_cc *to_edma_cc(struct dma_device *d)
{
return container_of(d, struct edma_cc, dma_slave);
@@ -2154,8 +2142,8 @@ static int edma_probe(struct platform_device *pdev)
for (i = 0; i < ecc->num_channels; i++) {
/* Assign all channels to the default queue */
- edma_map_dmach_to_queue(>slave_chans[i],
- info->default_queue);
+ edma_assign_channel_eventq(>slave_chans[i],
+ info->default_queue);
/* Set entry slot to the dummy slot */
edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
}
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/14] dmaengine: edma: Correct PaRAM access function names (_parm_ to _param_)
These inline functions are designed to modify parts of the PaRAM in eDMA.
Change the names accordingly.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index a64befecf477..051a7c4593d4 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -349,32 +349,32 @@ static inline void edma_shadow0_write_array(struct
edma_cc *ecc, int offset,
edma_write(ecc, EDMA_SHADOW0 + offset + (i << 2), val);
}
-static inline unsigned int edma_parm_read(struct edma_cc *ecc, int offset,
- int param_no)
+static inline unsigned int edma_param_read(struct edma_cc *ecc, int offset,
+ int param_no)
{
return edma_read(ecc, EDMA_PARM + offset + (param_no << 5));
}
-static inline void edma_parm_write(struct edma_cc *ecc, int offset,
- int param_no, unsigned val)
+static inline void edma_param_write(struct edma_cc *ecc, int offset,
+ int param_no, unsigned val)
{
edma_write(ecc, EDMA_PARM + offset + (param_no << 5), val);
}
-static inline void edma_parm_modify(struct edma_cc *ecc, int offset,
- int param_no, unsigned and, unsigned or)
+static inline void edma_param_modify(struct edma_cc *ecc, int offset,
+int param_no, unsigned and, unsigned or)
{
edma_modify(ecc, EDMA_PARM + offset + (param_no << 5), and, or);
}
-static inline void edma_parm_and(struct edma_cc *ecc, int offset, int param_no,
-unsigned and)
+static inline void edma_param_and(struct edma_cc *ecc, int offset, int
param_no,
+ unsigned and)
{
edma_and(ecc, EDMA_PARM + offset + (param_no << 5), and);
}
-static inline void edma_parm_or(struct edma_cc *ecc, int offset, int param_no,
- unsigned or)
+static inline void edma_param_or(struct edma_cc *ecc, int offset, int param_no,
+unsigned or)
{
edma_or(ecc, EDMA_PARM + offset + (param_no << 5), or);
}
@@ -594,8 +594,8 @@ static void edma_link(struct edma_cc *ecc, unsigned from,
unsigned to)
if (from >= ecc->num_slots || to >= ecc->num_slots)
return;
- edma_parm_modify(ecc, PARM_LINK_BCNTRLD, from, 0x,
-PARM_OFFSET(to));
+ edma_param_modify(ecc, PARM_LINK_BCNTRLD, from, 0x,
+ PARM_OFFSET(to));
}
/**
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/14] dmaengine: edma: Remove alignment constraint for memcpy
Despite the claim by the original commit adding the memcpy support, eDMA does not have constraint on the alignment of src, dst or length in increment mode. Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> --- drivers/dma/edma.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 7eefbf1e1c94..b36dfa5458cb 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -1324,6 +1324,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_memcpy( struct edma_desc *edesc; struct device *dev = chan->device->dev; struct edma_chan *echan = to_edma_chan(chan); + unsigned int width; if (unlikely(!echan || !len)) return NULL; @@ -1336,8 +1337,12 @@ static struct dma_async_tx_descriptor *edma_prep_dma_memcpy( edesc->pset_nr = 1; + width = 1 << __ffs((src | dest | len)); + if (width > DMA_SLAVE_BUSWIDTH_64_BYTES) + width = DMA_SLAVE_BUSWIDTH_64_BYTES; + ret = edma_config_pset(chan, >pset[0], src, dest, 1, - DMA_SLAVE_BUSWIDTH_4_BYTES, len, DMA_MEM_TO_MEM); + width, len, DMA_MEM_TO_MEM); if (ret < 0) return NULL; @@ -1903,12 +1908,6 @@ static void edma_dma_init(struct edma_cc *ecc, struct dma_device *dma, dma->dev = dev; - /* -* code using dma memcpy must make sure alignment of -* length is at dma->copy_align boundary. -*/ - dma->copy_align = DMAENGINE_ALIGN_4_BYTES; - INIT_LIST_HEAD(>channels); } -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ARM: OMAP/DTS: dra7/72-evm/beagle-x15: Audio support
Tony,
On 10/12/2015 11:57 PM, Tony Lindgren wrote:
> * Tony Lindgren <t...@atomide.com> [150914 09:32]:
>> * Peter Ujfalusi <peter.ujfal...@ti.com> [150914 01:54]:
>>> Hi Tony,
>>>
>>> On 08/24/2015 10:19 AM, Peter Ujfalusi wrote:
>>>> Hi,
>>>>
>>>> this series will enable analog audio (via onboard aic310x codec) for
>>>> dra7-evm,
>>>> dra72-evm and am57xx-beagle-x15 boards.
>>>> In these board McASP3 is connected to the codec and for the McASP3 we
>>>> needed to
>>>> have the DMA crossbar in place since the request lines are not mapped by
>>>> default.
>>>
>>> Did you had a chance to look at this series?
>>
>> Looks OK to me, will look at it more once we have the fixes merged.
>>
>> Paul may have comments on the hwmod chage, looks like you forgot
>> to Cc him on it. Can you please resend that one with Paul in Cc?
>
> Applying all the dts changes into omap-for-v4.3/dt thanks. Paul
> can pick up the hwmod change then after reviewing it.
Thanks for taking the DTS patches, however if Paul agrees with the way I think
we can handle the McASP in DRA7xx then the patch which adds the mcasp3 node to
dra7.dtsi needs to be replaced by:
>From b6733f9ca96a997fab3d0455783e875dd9ae032b Mon Sep 17 00:00:00 2001
From: Peter Ujfalusi <peter.ujfal...@ti.com>
Date: Tue, 24 Feb 2015 15:12:59 +0200
Subject: [PATCH v2 03/12] ARM: DTS: dra7: Add McASP3 node
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8fedddc35999..cde0a3cbf262 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1404,6 +1404,21 @@
status = "disabled";
};
+ mcasp3: mcasp@48468000 {
+ compatible = "ti,dra7-mcasp-audio";
+ ti,hwmods = "mcasp3";
+ reg = <0x48468000 0x2000>;
+ reg-names = "mpu";
+ interrupts = ,
+;
+ interrupt-names = "tx", "rx";
+ dmas = <_xbar 133>, <_xbar 132>;
+ dma-names = "tx", "rx";
+ clocks = <_aux_gfclk_mux>, <_ahclkx_mux>;
+ clock-names = "fck", "ahclkx";
+ status = "disabled";
+ };
+
crossbar_mpu: crossbar@4a002a48 {
compatible = "ti,irq-crossbar";
reg = <0x4a002a48 0x130>;
--
2.6.1
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/13] dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx
On 10/14/2015 05:48 PM, Vinod Koul wrote:
> On Wed, Oct 14, 2015 at 04:12:21PM +0300, Peter Ujfalusi wrote:
>> The DMA event crossbar on AM33xx/AM43xx is different from the one found in
>> DRA7x family.
>> Instead of a single event crossbar it has 64 identical mux attached to each
>> eDMA event line. When the 0 event mux is selected, the default mapped event
>> is going to be routed to the corresponding eDMA event line. If different
>> mux is selected, then the selected event is going to be routed to the given
>> eDMA event.
>
> Why is crossbar patch in edma series?
The old eDMA binding had xbar support which is not supported by the new
binding since it does not belong to the eDMA driver at all.
We have couple of boards where the crossbar is in use so I included the
crossbar support in this series.
>> +static void ti_am335x_xbar_free(struct device *dev, void *route_data)
>> +{
>> +struct ti_am335x_xbar_data *xbar = dev_get_drvdata(dev);
>> +struct ti_am335x_xbar_map *map = route_data;
>> +
>> +dev_err(dev, "Unmapping XBAR event %u on channel %u\n",
>> +map->mux_val, map->dma_line);
>
> Err ?
Aargh, leftover from debugging.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: edma: Optimize memcpy operation
On 10/14/2015 05:41 PM, Vinod Koul wrote:
> On Wed, Oct 14, 2015 at 04:12:13PM +0300, Peter Ujfalusi wrote:
>> @@ -1320,41 +1317,92 @@ static struct dma_async_tx_descriptor
>> *edma_prep_dma_memcpy(
>> struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
>> size_t len, unsigned long tx_flags)
>> {
>> -int ret;
>> +int ret, nslots;
>> struct edma_desc *edesc;
>> struct device *dev = chan->device->dev;
>> struct edma_chan *echan = to_edma_chan(chan);
>> -unsigned int width;
>> +unsigned int width, pset_len;
>>
>> if (unlikely(!echan || !len))
>> return NULL;
>>
>> -edesc = kzalloc(sizeof(*edesc) + sizeof(edesc->pset[0]), GFP_ATOMIC);
>> +if (len < SZ_64K) {
>> +/*
>> + * Transfer size less than 64K can be handled with one paRAM
>> + * slot. ACNT = length
>> + */
>> +width = len;
>> +pset_len = len;
>> +nslots = 1;
>> +} else {
>> +/*
>> + * Transfer size bigger than 64K will be handled with maximum of
>> + * two paRAM slots.
>> + * slot1: ACNT = 32767, length1: (length / 32767)
>> + * slot2: the remaining amount of data.
>> + */
>> +width = SZ_32K - 1;
>> +pset_len = rounddown(len, width);
>> +/* One slot is enough for lengths multiple of (SZ_32K -1) */
>
> Hmm so does this mean if I have 140K transfer, it will do two 64K for 1st
> slot and 12K in second slot ?
Not exactly. If the size is less than 64K it can be done with one 'burst' but
if it is bigger we need to have two sets of transfer:
1. 32K blocks
2. the remaining data
so in case of 140K:
4 x 32K followed by 12K
>
> Is there a limit on 'blocks' of 64K we can do here?
32767 32K blocks is the limit.
The 64K burst is only possible if the whole transfer is less less than 64K.
With the ACNT counter we can transfer 64K - 1 bytes, but if this is not enough
we need to use the BCNT counter and for that to work the the distance between
the start of 'slot n' and the start of 'slot n+1' need to be less than 32K,
this is the reason why we have 32K 'blocks' to transfer first followed by the
remaining.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/13] dmaengine: edma: Merge map_dmach_to_queue into assign_channel_eventq
edma_assign_channel_eventq() is a wrapper around edma_map_dmach_to_queue()
We can merge the content of the later so we will have only one function
to be used for mapping channels to given eventq
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 56 +-
1 file changed, 22 insertions(+), 34 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index d8639a92f286..a02f84c7c3d7 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -391,22 +391,6 @@ static inline void clear_bits(int offset, int len,
unsigned long *p)
clear_bit(offset + (len - 1), p);
}
-static void edma_map_dmach_to_queue(struct edma_chan *echan,
- enum dma_event_q queue_no)
-{
- struct edma_cc *ecc = echan->ecc;
- int channel = EDMA_CHAN_SLOT(echan->ch_num);
- int bit = (channel & 0x7) * 4;
-
- /* default to low priority queue */
- if (queue_no == EVENTQ_DEFAULT)
- queue_no = ecc->default_queue;
-
- queue_no &= 7;
- edma_modify_array(ecc, EDMA_DMAQNUM, (channel >> 3), ~(0x7 << bit),
- queue_no << bit);
-}
-
static void edma_assign_priority_to_queue(struct edma_cc *ecc, int queue_no,
int priority)
{
@@ -723,6 +707,25 @@ static void edma_clean_channel(struct edma_chan *echan)
edma_write(ecc, EDMA_CCERRCLR, BIT(16) | BIT(1) | BIT(0));
}
+/* Move channel to a specific event queue */
+static void edma_assign_channel_eventq(struct edma_chan *echan,
+ enum dma_event_q eventq_no)
+{
+ struct edma_cc *ecc = echan->ecc;
+ int channel = EDMA_CHAN_SLOT(echan->ch_num);
+ int bit = (channel & 0x7) * 4;
+
+ /* default to low priority queue */
+ if (eventq_no == EVENTQ_DEFAULT)
+ eventq_no = ecc->default_queue;
+ if (eventq_no >= ecc->num_tc)
+ return;
+
+ eventq_no &= 7;
+ edma_modify_array(ecc, EDMA_DMAQNUM, (channel >> 3), ~(0x7 << bit),
+ eventq_no << bit);
+}
+
static int edma_alloc_channel(struct edma_chan *echan,
enum dma_event_q eventq_no)
{
@@ -751,7 +754,7 @@ static int edma_alloc_channel(struct edma_chan *echan,
edma_setup_interrupt(echan, true);
- edma_map_dmach_to_queue(echan, eventq_no);
+ edma_assign_channel_eventq(echan, eventq_no);
return 0;
}
@@ -764,21 +767,6 @@ static void edma_free_channel(struct edma_chan *echan)
edma_setup_interrupt(echan, false);
}
-/* Move channel to a specific event queue */
-static void edma_assign_channel_eventq(struct edma_chan *echan,
- enum dma_event_q eventq_no)
-{
- struct edma_cc *ecc = echan->ecc;
-
- /* default to low priority queue */
- if (eventq_no == EVENTQ_DEFAULT)
- eventq_no = ecc->default_queue;
- if (eventq_no >= ecc->num_tc)
- return;
-
- edma_map_dmach_to_queue(echan, eventq_no);
-}
-
static inline struct edma_cc *to_edma_cc(struct dma_device *d)
{
return container_of(d, struct edma_cc, dma_slave);
@@ -2148,8 +2136,8 @@ static int edma_probe(struct platform_device *pdev)
for (i = 0; i < ecc->num_channels; i++) {
/* Assign all channels to the default queue */
- edma_map_dmach_to_queue(>slave_chans[i],
- info->default_queue);
+ edma_assign_channel_eventq(>slave_chans[i],
+ info->default_queue);
/* Set entry slot to the dummy slot */
edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
}
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/13] ARM: DTS: am437x: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/am4372.dtsi | 82 -
arch/arm/boot/dts/am437x-gp-evm.dts | 9 +---
2 files changed, 64 insertions(+), 27 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c9701e..a39428dd85b2 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -183,14 +183,56 @@
};
edma: edma@4900 {
- compatible = "ti,edma3";
- ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
- reg = <0x4900 0x1>,
- <0x44e10f90 0x10>;
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
interrupts = ,
- ,
- ;
- #dma-cells = <1>;
+,
+;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 5>,
+ <_tptc2 0>;
+
+ ti,edma-memcpy-channels = /bits/ 16 <32 33>;
+ };
+
+ edma_tptc0: tptc@4980 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc0";
+ reg = <0x4980 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc1: tptc@4990 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc1";
+ reg = <0x4990 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc2: tptc@49a0 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc2";
+ reg = <0x49a0 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_xbar: dma-router@44e10f90 {
+ compatible = "ti,am335x-edma-crossbar";
+ reg = <0x44e10f90 0x40>;
+
+ #dma-cells = <3>;
+ dma-requests = <64>;
+
+ dma-masters = <>;
};
uart0: serial@44e09000 {
@@ -495,8 +537,8 @@
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
- dmas = < 24
-25>;
+ dmas = < 24 0>,
+ < 25 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabled";
@@ -507,8 +549,8 @@
reg = <0x481d8000 0x1000>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
- dmas = < 2
-3>;
+ dmas = < 2 0>,
+ < 3 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabled";
@@ -776,7 +818,7 @@
compatible = "ti,omap5-sham";
ti,hwmods = "sham";
reg = <0x5310 0x300>;
- dmas = < 36>;
+ dmas = < 36 0>;
dma-names = "rx";
[PATCH 10/13] dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx
The DMA event crossbar on AM33xx/AM43xx is different from the one found in
DRA7x family.
Instead of a single event crossbar it has 64 identical mux attached to each
eDMA event line. When the 0 event mux is selected, the default mapped event
is going to be routed to the corresponding eDMA event line. If different
mux is selected, then the selected event is going to be routed to the given
eDMA event.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
.../devicetree/bindings/dma/ti-dma-crossbar.txt| 15 +-
drivers/dma/ti-dma-crossbar.c | 237 ++---
2 files changed, 226 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
index 63a48928f3a8..b152a75dceae 100644
--- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
+++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
@@ -2,9 +2,10 @@ Texas Instruments DMA Crossbar (DMA request router)
Required properties:
- compatible: "ti,dra7-dma-crossbar" for DRA7xx DMA crossbar
+ "ti,am335x-edma-crossbar" for AM335x and AM437x
- reg: Memory map for accessing module
-- #dma-cells: Should be set to <1>.
- Clients should use the crossbar request number (input)
+- #dma-cells: Should be set to to match with the DMA controller's dma-cells
+ for ti,dra7-dma-crossbar and <3> for ti,am335x-edma-crossbar.
- dma-requests:Number of DMA requests the crossbar can receive
- dma-masters: phandle pointing to the DMA controller
@@ -14,6 +15,15 @@ The DMA controller node need to have the following
poroperties:
Optional properties:
- ti,dma-safe-map: Safe routing value for unused request lines
+Notes:
+When requesting channel via ti,dra7-dma-crossbar, the DMA clinet must request
+the DMA event number as crossbar ID (input to the DMA crossbar).
+
+For ti,am335x-edma-crossbar: the meaning of parameters of dmas for clients:
+dmas = <_xbar 12 0 1>; where <12> is the DMA request number, <0> is the TC
+the event should be assigned and <1> is the mux selection for in the crossbar.
+When mux 0 is used the DMA channel can be requested directly from edma node.
+
Example:
/* DMA controller */
@@ -47,6 +57,7 @@ uart1: serial@4806a000 {
ti,hwmods = "uart1";
clock-frequency = <4800>;
status = "disabled";
+ /* Requesting crossbar input 49 and 50 */
dmas = <_xbar 49>, <_xbar 50>;
dma-names = "tx", "rx";
};
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 5cce8c9d0026..9c5ee2149052 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -23,7 +23,176 @@
#define TI_XBAR_EDMA_OFFSET0
#define TI_XBAR_SDMA_OFFSET1
-struct ti_dma_xbar_data {
+#define TI_XBAR_DRA7 0
+#define TI_XBAR_AM335X 1
+
+static const struct of_device_id ti_dma_xbar_match[] = {
+ {
+ .compatible = "ti,dra7-dma-crossbar",
+ .data = (void *)TI_XBAR_DRA7,
+ },
+ {
+ .compatible = "ti,am335x-edma-crossbar",
+ .data = (void *)TI_XBAR_AM335X,
+ },
+ {},
+};
+
+/* Crossbar on AM335x/AM437x family */
+struct ti_am335x_xbar_data {
+ void __iomem *iomem;
+
+ struct dma_router dmarouter;
+
+ u32 xbar_events; /* maximum number of events to select in xbar */
+ u32 dma_requests; /* number of DMA requests on eDMA */
+};
+
+struct ti_am335x_xbar_map {
+ u16 dma_line;
+ u16 mux_val;
+};
+
+static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u16
val)
+{
+ writeb_relaxed(val & 0x1f, iomem + event);
+}
+
+static void ti_am335x_xbar_free(struct device *dev, void *route_data)
+{
+ struct ti_am335x_xbar_data *xbar = dev_get_drvdata(dev);
+ struct ti_am335x_xbar_map *map = route_data;
+
+ dev_err(dev, "Unmapping XBAR event %u on channel %u\n",
+ map->mux_val, map->dma_line);
+
+ ti_am335x_xbar_write(xbar->iomem, map->dma_line, 0);
+ kfree(map);
+}
+
+static void *ti_am335x_xbar_route_allocate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
+ struct ti_am335x_xbar_data *xbar = platform_get_drvdata(pdev);
+ struct ti_am335x_xbar_map *map;
+
+ if (dma_spec->args_count != 3)
+ return ERR_PTR(-EINVAL);
+
+ if (dma_spec->args[2] >= xbar->xbar_events) {
+ dev_err(>dev, "Invalid XBAR event number: %d\n",
+ dma_spec->args[2]);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if
[PATCH 08/13] dmaengine: edma: Do not allocate memory for edma_rsv_info in case of DT boot
The channel/slot reservation is not supported when booted with DT so there is not need to allocate memory. Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> --- drivers/dma/edma.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 53188b9383a6..f511684f83a2 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -1920,12 +1920,6 @@ static int edma_of_parse_dt(struct device *dev, struct edma_soc_info *pdata) int ret = 0; struct property *prop; size_t sz; - struct edma_rsv_info *rsv_info; - - rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL); - if (!rsv_info) - return -ENOMEM; - pdata->rsv = rsv_info; prop = of_find_property(dev->of_node, "ti,edma-xbar-event-map", ); if (prop) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/13] dmaengine: edma: Refactor the dma device and channel struct initialization
Move all code under one function to do the dma device and eDMA channel
related setup so they are not scattered around the driver.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 79 +-
1 file changed, 37 insertions(+), 42 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index d064fbc47351..53188b9383a6 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1750,18 +1750,49 @@ static enum dma_status edma_tx_status(struct dma_chan
*chan,
return ret;
}
-static void __init edma_chan_init(struct edma_cc *ecc, struct dma_device *dma,
- struct edma_chan *echans)
+#define EDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static void edma_dma_init(struct edma_cc *ecc)
{
+ struct dma_device *ddev = >dma_slave;
int i, j;
+ dma_cap_zero(ddev->cap_mask);
+ dma_cap_set(DMA_SLAVE, ddev->cap_mask);
+ dma_cap_set(DMA_CYCLIC, ddev->cap_mask);
+ dma_cap_set(DMA_MEMCPY, ddev->cap_mask);
+
+ ddev->device_prep_slave_sg = edma_prep_slave_sg;
+ ddev->device_prep_dma_cyclic = edma_prep_dma_cyclic;
+ ddev->device_prep_dma_memcpy = edma_prep_dma_memcpy;
+ ddev->device_alloc_chan_resources = edma_alloc_chan_resources;
+ ddev->device_free_chan_resources = edma_free_chan_resources;
+ ddev->device_issue_pending = edma_issue_pending;
+ ddev->device_tx_status = edma_tx_status;
+ ddev->device_config = edma_slave_config;
+ ddev->device_pause = edma_dma_pause;
+ ddev->device_resume = edma_dma_resume;
+ ddev->device_terminate_all = edma_terminate_all;
+
+ ddev->src_addr_widths = EDMA_DMA_BUSWIDTHS;
+ ddev->dst_addr_widths = EDMA_DMA_BUSWIDTHS;
+ ddev->directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+ ddev->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+
+ ddev->dev = ecc->dev;
+
+ INIT_LIST_HEAD(>channels);
+
for (i = 0; i < ecc->num_channels; i++) {
- struct edma_chan *echan = [i];
+ struct edma_chan *echan = >slave_chans[i];
echan->ch_num = EDMA_CTLR_CHAN(ecc->id, i);
echan->ecc = ecc;
echan->vchan.desc_free = edma_desc_free;
- vchan_init(>vchan, dma);
+ vchan_init(>vchan, ddev);
INIT_LIST_HEAD(>node);
for (j = 0; j < EDMA_MAX_SLOTS; j++)
@@ -1769,36 +1800,6 @@ static void __init edma_chan_init(struct edma_cc *ecc,
struct dma_device *dma,
}
}
-#define EDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
-BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
-BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
-BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
-
-static void edma_dma_init(struct edma_cc *ecc, struct dma_device *dma,
- struct device *dev)
-{
- dma->device_prep_slave_sg = edma_prep_slave_sg;
- dma->device_prep_dma_cyclic = edma_prep_dma_cyclic;
- dma->device_prep_dma_memcpy = edma_prep_dma_memcpy;
- dma->device_alloc_chan_resources = edma_alloc_chan_resources;
- dma->device_free_chan_resources = edma_free_chan_resources;
- dma->device_issue_pending = edma_issue_pending;
- dma->device_tx_status = edma_tx_status;
- dma->device_config = edma_slave_config;
- dma->device_pause = edma_dma_pause;
- dma->device_resume = edma_dma_resume;
- dma->device_terminate_all = edma_terminate_all;
-
- dma->src_addr_widths = EDMA_DMA_BUSWIDTHS;
- dma->dst_addr_widths = EDMA_DMA_BUSWIDTHS;
- dma->directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
- dma->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
-
- dma->dev = dev;
-
- INIT_LIST_HEAD(>channels);
-}
-
static int edma_setup_from_hw(struct device *dev, struct edma_soc_info *pdata,
struct edma_cc *ecc)
{
@@ -2131,14 +2132,8 @@ static int edma_probe(struct platform_device *pdev)
}
ecc->info = info;
- dma_cap_zero(ecc->dma_slave.cap_mask);
- dma_cap_set(DMA_SLAVE, ecc->dma_slave.cap_mask);
- dma_cap_set(DMA_CYCLIC, ecc->dma_slave.cap_mask);
- dma_cap_set(DMA_MEMCPY, ecc->dma_slave.cap_mask);
-
- edma_dma_init(ecc, >dma_slave, dev);
-
- edma_chan_init(ecc, >dma_slave, ecc->slave_chans);
+ /* Init the dma device and channels */
+ edma_dma_init(ecc);
for
[PATCH 09/13] dmaengine: edma: Merge the of parsing functions
Instead of nesting functions just merge them since the resulting function
is still small and readable.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index f511684f83a2..421c4fd67235 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1915,31 +1915,23 @@ static int edma_xbar_event_map(struct device *dev,
struct edma_soc_info *pdata,
return 0;
}
-static int edma_of_parse_dt(struct device *dev, struct edma_soc_info *pdata)
-{
- int ret = 0;
- struct property *prop;
- size_t sz;
-
- prop = of_find_property(dev->of_node, "ti,edma-xbar-event-map", );
- if (prop)
- ret = edma_xbar_event_map(dev, pdata, sz);
-
- return ret;
-}
-
static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev)
{
struct edma_soc_info *info;
+ struct property *prop;
+ size_t sz;
int ret;
info = devm_kzalloc(dev, sizeof(struct edma_soc_info), GFP_KERNEL);
if (!info)
return ERR_PTR(-ENOMEM);
- ret = edma_of_parse_dt(dev, info);
- if (ret)
- return ERR_PTR(ret);
+ prop = of_find_property(dev->of_node, "ti,edma-xbar-event-map", );
+ if (prop) {
+ ret = edma_xbar_event_map(dev, info, sz);
+ if (ret)
+ return ERR_PTR(ret);
+ }
return info;
}
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/13] dmaenigne: edma/ti-crossbar: fixes, new bindings
Hi, This series depends on the eDMA driver merger series (v5) [1]. The first two patch is to improve the memcpy functionality by removing the alignment constraint and speed optimization (memcpy speed is up from ~3MB/s to ~15MB/s). The rest of the series consits of smaller cleanup patches and the new DT binding implementation for the eDMA3 and the crossbar found in am33xx/am43xx. The new DT binding was needed for several reasons: - the original binding was 'Documentating' the Linux driver functionality. - the use of multiple ti,hwmod properties in the binding need to be removed. In recent kernels we have kernel warning printed because of this. - No way to set queue priorities - No way to fix the memcpy issue [2] - Missing infrastructure to deal with multi core usage (ARM + DSP) - eDMA behind of a crossbar was not safe to use - it could be hacked to work. While some of these issues migh have been fixed with the old binding by adding new properties all along, but the TPCC and TPTC separation (to fix the hwmod warning and to be able to have better power management) and the need to be able to select TC to execute the given channel demanded new compatible for the eDMA3 components. [1] http://www.spinics.net/lists/arm-kernel/msg452373.html [2] memcpy issue with the old stack ever since the eDMA got support via dmaengine and the memcpy was enabled it has been mostly broken and worked by luck only. The root of the issue was that the channels for the memcpy was taken from the same pool as the slave channels. Since in eDMA a channel number is wired to be used with the same event number (HW request) this had it's faults. With dmaengine the driver will always be asked for a channel since the channel selection for any channel is done in the dmaengine layer. The whole magic of builing the unused channel list and stuff did not help: Let assume that in DT we have users for channel 0,1,2,3,10,11. The eDMA driver would mark these channels as used - which means they are HW syncronized. If we have drivers enabled which uses channel 0,1,10,11 and some driver request for a channel for memcpy, it will get the channel 2 and when this memcpy channel is used it would have been assumed to be HW triggered, so the memcpy would not work at all. There were no way to fix this within the old driver stack and with the old bindings. I'm maintaining this (and other patches) in my linux-next-wip branch if someone wants to try it out w/o needing to hunt for patches: https://github.com/omap-audio/linux-audio.git peter/linux-next-wip Regards, Peter --- Peter Ujfalusi (13): dmaengine: edma: Remove alignment constraint for memcpy dmaengine: edma: Optimize memcpy operation dmaengine: edma: Simplify function parameter list for channel operations dmaengine: edma: Correct PaRAM access function names (_parm_ to _param_) dmaengine: edma: Merge map_dmach_to_queue into assign_channel_eventq dmaengine: edma: Get qDMA channel information from HW also dmaengine: edma: Refactor the dma device and channel struct initialization dmaengine: edma: Do not allocate memory for edma_rsv_info in case of DT boot dmaengine: edma: Merge the of parsing functions dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx dmaengine: edma: New device tree binding ARM: DTS: am33xx: Use the new DT bindings for the eDMA3 ARM: DTS: am437x: Use the new DT bindings for the eDMA3 .../devicetree/bindings/dma/ti-dma-crossbar.txt| 15 +- Documentation/devicetree/bindings/dma/ti-edma.txt | 117 ++- arch/arm/boot/dts/am335x-evm.dts |9 +- arch/arm/boot/dts/am335x-pepper.dts| 11 +- arch/arm/boot/dts/am33xx.dtsi | 96 +- arch/arm/boot/dts/am4372.dtsi | 82 +- arch/arm/boot/dts/am437x-gp-evm.dts|9 +- drivers/dma/edma.c | 1060 +++- drivers/dma/ti-dma-crossbar.c | 237 - include/linux/platform_data/edma.h |3 + 10 files changed, 1045 insertions(+), 594 deletions(-) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] dmaengine: edma: Remove alignment constraint for memcpy
Despite the claim by the original commit adding the memcpy support, eDMA does not have constraint on the alignment of src, dst or length in increment mode. Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> --- drivers/dma/edma.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 7eefbf1e1c94..b36dfa5458cb 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -1324,6 +1324,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_memcpy( struct edma_desc *edesc; struct device *dev = chan->device->dev; struct edma_chan *echan = to_edma_chan(chan); + unsigned int width; if (unlikely(!echan || !len)) return NULL; @@ -1336,8 +1337,12 @@ static struct dma_async_tx_descriptor *edma_prep_dma_memcpy( edesc->pset_nr = 1; + width = 1 << __ffs((src | dest | len)); + if (width > DMA_SLAVE_BUSWIDTH_64_BYTES) + width = DMA_SLAVE_BUSWIDTH_64_BYTES; + ret = edma_config_pset(chan, >pset[0], src, dest, 1, - DMA_SLAVE_BUSWIDTH_4_BYTES, len, DMA_MEM_TO_MEM); + width, len, DMA_MEM_TO_MEM); if (ret < 0) return NULL; @@ -1903,12 +1908,6 @@ static void edma_dma_init(struct edma_cc *ecc, struct dma_device *dma, dma->dev = dev; - /* -* code using dma memcpy must make sure alignment of -* length is at dma->copy_align boundary. -*/ - dma->copy_align = DMAENGINE_ALIGN_4_BYTES; - INIT_LIST_HEAD(>channels); } -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/13] dmaengine: edma: Optimize memcpy operation
If the transfer is shorted then 64K we can complete it with one ACNT burst
by configuring ACNT to the length of the copy, this require one paRAM slot.
Otherwise we use two paRAM slots for the copy:
slot1: will copy (length / 32767) number of 32767 byte long blocks
slot2: will be configured to copy the remaining data.
According to tests this patch increases the throughput of memcpy from
~3MB/s to 15MB/s
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 90 +-
1 file changed, 69 insertions(+), 21 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index b36dfa5458cb..6de571f4aa0f 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1107,19 +1107,16 @@ static int edma_dma_resume(struct dma_chan *chan)
*/
static int edma_config_pset(struct dma_chan *chan, struct edma_pset *epset,
dma_addr_t src_addr, dma_addr_t dst_addr, u32 burst,
- enum dma_slave_buswidth dev_width,
- unsigned int dma_length,
+ unsigned int acnt, unsigned int dma_length,
enum dma_transfer_direction direction)
{
struct edma_chan *echan = to_edma_chan(chan);
struct device *dev = chan->device->dev;
struct edmacc_param *param = >param;
- int acnt, bcnt, ccnt, cidx;
+ int bcnt, ccnt, cidx;
int src_bidx, dst_bidx, src_cidx, dst_cidx;
int absync;
- acnt = dev_width;
-
/* src/dst_maxburst == 0 is the same case as src/dst_maxburst == 1 */
if (!burst)
burst = 1;
@@ -1320,41 +1317,92 @@ static struct dma_async_tx_descriptor
*edma_prep_dma_memcpy(
struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
size_t len, unsigned long tx_flags)
{
- int ret;
+ int ret, nslots;
struct edma_desc *edesc;
struct device *dev = chan->device->dev;
struct edma_chan *echan = to_edma_chan(chan);
- unsigned int width;
+ unsigned int width, pset_len;
if (unlikely(!echan || !len))
return NULL;
- edesc = kzalloc(sizeof(*edesc) + sizeof(edesc->pset[0]), GFP_ATOMIC);
+ if (len < SZ_64K) {
+ /*
+* Transfer size less than 64K can be handled with one paRAM
+* slot. ACNT = length
+*/
+ width = len;
+ pset_len = len;
+ nslots = 1;
+ } else {
+ /*
+* Transfer size bigger than 64K will be handled with maximum of
+* two paRAM slots.
+* slot1: ACNT = 32767, length1: (length / 32767)
+* slot2: the remaining amount of data.
+*/
+ width = SZ_32K - 1;
+ pset_len = rounddown(len, width);
+ /* One slot is enough for lengths multiple of (SZ_32K -1) */
+ if (unlikely(pset_len == len))
+ nslots = 1;
+ else
+ nslots = 2;
+ }
+
+ edesc = kzalloc(sizeof(*edesc) + nslots * sizeof(edesc->pset[0]),
+ GFP_ATOMIC);
if (!edesc) {
dev_dbg(dev, "Failed to allocate a descriptor\n");
return NULL;
}
- edesc->pset_nr = 1;
-
- width = 1 << __ffs((src | dest | len));
- if (width > DMA_SLAVE_BUSWIDTH_64_BYTES)
- width = DMA_SLAVE_BUSWIDTH_64_BYTES;
+ edesc->pset_nr = nslots;
+ edesc->residue = edesc->residue_stat = len;
+ edesc->direction = DMA_MEM_TO_MEM;
+ edesc->echan = echan;
ret = edma_config_pset(chan, >pset[0], src, dest, 1,
- width, len, DMA_MEM_TO_MEM);
- if (ret < 0)
+ width, pset_len, DMA_MEM_TO_MEM);
+ if (ret < 0) {
+ kfree(edesc);
return NULL;
+ }
edesc->absync = ret;
- /*
-* Enable intermediate transfer chaining to re-trigger channel
-* on completion of every TR, and enable transfer-completion
-* interrupt on completion of the whole transfer.
-*/
edesc->pset[0].param.opt |= ITCCHEN;
- edesc->pset[0].param.opt |= TCINTEN;
+ if (nslots == 1) {
+ /* Enable transfer complete interrupt */
+ edesc->pset[0].param.opt |= TCINTEN;
+ } else {
+ /* Enable transfer complete chaining for the first slot */
+ edesc->pset[0].param.opt |= TCCHEN;
+
+ if (echan->slot[1] < 0) {
+ echan->slot[1] = edma_alloc_slot(echan->ecc,
+EDMA_SLOT_ANY);
+ if (echan->slot[1] <
[PATCH 12/13] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/am335x-evm.dts| 9 +---
arch/arm/boot/dts/am335x-pepper.dts | 11 +
arch/arm/boot/dts/am33xx.dtsi | 96 ++---
3 files changed, 73 insertions(+), 43 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 1942a5c8132d..507980672c32 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -743,8 +743,8 @@
{
/* these are on the crossbar and are outlined in the
xbar-event-map element */
- dmas = < 12
-13>;
+ dmas = <_xbar 12 0 1
+ _xbar 13 0 2>;
dma-names = "tx", "rx";
status = "okay";
vmmc-supply = <_en_reg>;
@@ -766,11 +766,6 @@
};
};
- {
- ti,edma-xbar-event-map = /bits/ 16 <1 12
- 2 13>;
-};
-
{
status = "okay";
};
diff --git a/arch/arm/boot/dts/am335x-pepper.dts
b/arch/arm/boot/dts/am335x-pepper.dts
index 7106114c7464..39073b921664 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -339,13 +339,6 @@
ti,non-removable;
};
- {
- /* Map eDMA MMC2 Events from Crossbar */
- ti,edma-xbar-event-map = /bits/ 16 <1 12
-2 13>;
-};
-
-
{
/* Wifi & Bluetooth on MMC #3 */
status = "okay";
@@ -354,8 +347,8 @@
vmmmc-supply = <_reg>;
bus-width = <4>;
ti,non-removable;
- dmas = < 12
-13>;
+ dmas = <_xbar 12 0 1
+ _xbar 13 0 2>;
dma-names = "tx", "rx";
};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index d23e2524d694..6053e75c6e99 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -174,12 +174,54 @@
};
edma: edma@4900 {
- compatible = "ti,edma3";
- ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
- reg = <0x4900 0x1>,
- <0x44e10f90 0x40>;
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
interrupts = <12 13 14>;
- #dma-cells = <1>;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 5>,
+ <_tptc2 0>;
+
+ ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+ };
+
+ edma_tptc0: tptc@4980 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc0";
+ reg = <0x4980 0x10>;
+ interrupts = <112>;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc1: tptc@4990 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc1";
+ reg = <0x4990 0x10>;
+ interrupts = <113>;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc2: tptc@49a0 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc2";
+ reg = <0x49a0 0x10>;
+ interrupts = <114>;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_xbar: dma-router@44e10f90 {
+ compatible = "ti,am335x-edma-crossbar";
+ reg = <0x44e10f90 0x40>;
+
+ #dma-cells = <3>;
+
[PATCH 11/13] dmaengine: edma: New device tree binding
With the old binding and driver architecture we had many issues:
No way to assign eDMA channels to event queues, thus not able to tune the
system by moving specific DMA channels to low/high priority servicing. We
moved the cyclic channels to high priority within the code, but that was
just a workaround to this issue.
Memcopy was fundamentally broken: even if the driver scanned the DT/devices
in the booted system for direct DMA users (which is not effective when the
events are going through a crossbar) and created a map of 'used' channels,
this information was not really usable. Since via dmaengien API the eDMA
driver will be called with _some_ channel number, we would try to request
this channel when any channel is requested for memcpy. By luck we got
channel which is not used by any device most of the time so things worked,
but if a device would have been using the given channel, but not requested
it, the memcpy channel would have been waiting for HW event.
The old code had the am33xx/am43xx DMA event router handling embedded. This
should have been done in a separate driver since it is not part of the
actual eDMA IP.
There were no way to 'lock' PaRAM slots to be used by the DSP for example
when booting with DT.
In DT boot the edma node used more than one hwmod which is not a good
practice and the kernel prints warning because of this.
With the new bindings and the changes in the driver we can:
- No regression with Legacy binding and non DT boot
- DMA channels can be assigned to any TC (to set priority)
- PaRAM slots can be reserved for other cores to use
- Dynamic power management for CC and TCs, if only TC0 is used all other TC
can be powered down for example
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 117 +-
drivers/dma/edma.c| 486 +++---
include/linux/platform_data/edma.h| 3 +
3 files changed, 459 insertions(+), 147 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 5ba525a10035..d3d0a4fb1c73 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -1,4 +1,119 @@
-TI EDMA
+Texas Instruments eDMA
+
+The eDMA3 consists of two components: Channel controller (CC) and Transfer
+Controller(s) (TC). The CC is the main entry for DMA users since it is
+responsible for the DMA channel handling, while the TCs are responsible to
+execute the actual DMA tansfer.
+
+--
+eDMA3 Channel Controller
+
+Required properties:
+- compatible: "ti,edma3-tpcc" for the channel controller(s)
+- #dma-cells: Should be set to <2>. The first number is the DMA request
+ number and the second is the TC the channel is serviced on.
+- reg: Memory map of eDMA CC
+- reg-names: "edma3_cc"
+- interrupts: Interrupt lines for CCINT, MPERR and CCERRINT.
+- interrupt-names: "edma3_ccint", "emda3_mperr" and "edma3_ccerrint"
+- ti,tptcs:List of TPTCs associated with the eDMA in the following form:
+ <_phandle TC_priority_number>. The highest priority is 0.
+
+Optional properties:
+- ti,hwmods: Name of the hwmods associated to the eDMA CC
+- ti,edma-memcpy-channels: List of channels allocated to be used for memcpy,
iow
+ these channels will be SW triggered channels. The list must
+ contain 16 bits numbers, see example.
+- ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
+ the driver, they are allocated to be used by for example the
+ DSP. See example.
+
+--
+eDMA3 Transfer Controller
+
+Required properties:
+- compatible: "ti,edma3-tptc" for the transfer controller(s)
+- reg: Memory map of eDMA TC
+- interrupts: Interrupt number for TCerrint.
+
+Optional properties:
+- ti,hwmods: Name of the hwmods associated to the given eDMA TC
+- interrupt-names: "edma3_tcerrint"
+
+--
+Example:
+
+edma: edma@4900 {
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
+ interrupts = <12 13 14>;
+ interrupt-names = "edma3_ccint", "emda3_mperr", "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <_tptc0 7>, <_tptc1 7>, <_tptc2 0>;
+
+ /* Channel 20 and 21 is allocated for memcpy */
+ ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+ /* The following
[PATCH 06/13] dmaengine: edma: Get qDMA channel information from HW also
Query the number of qDMA channels from CCCFG register.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index a02f84c7c3d7..d064fbc47351 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -107,6 +107,7 @@
/* CCCFG register */
#define GET_NUM_DMACH(x) (x & 0x7) /* bits 0-2 */
+#define GET_NUM_QDMACH(x) (x & 0x70 >> 4) /* bits 4-6 */
#define GET_NUM_PAENTRY(x) ((x & 0x7000) >> 12) /* bits 12-14 */
#define GET_NUM_EVQUE(x) ((x & 0x7) >> 16) /* bits 16-18 */
#define GET_NUM_REGN(x)((x & 0x30) >> 20) /* bits 20-21 */
@@ -220,6 +221,7 @@ struct edma_cc {
/* eDMA3 resource information */
unsignednum_channels;
+ unsignednum_qchannels;
unsignednum_region;
unsignednum_slots;
unsignednum_tc;
@@ -1813,6 +1815,9 @@ static int edma_setup_from_hw(struct device *dev, struct
edma_soc_info *pdata,
value = GET_NUM_DMACH(cccfg);
ecc->num_channels = BIT(value + 1);
+ value = GET_NUM_QDMACH(cccfg);
+ ecc->num_qchannels = value * 2;
+
value = GET_NUM_PAENTRY(cccfg);
ecc->num_slots = BIT(value + 4);
@@ -1824,6 +1829,7 @@ static int edma_setup_from_hw(struct device *dev, struct
edma_soc_info *pdata,
dev_dbg(dev, "eDMA3 CC HW configuration (cccfg: 0x%08x):\n", cccfg);
dev_dbg(dev, "num_region: %u\n", ecc->num_region);
dev_dbg(dev, "num_channels: %u\n", ecc->num_channels);
+ dev_dbg(dev, "num_qchannels: %u\n", ecc->num_qchannels);
dev_dbg(dev, "num_slots: %u\n", ecc->num_slots);
dev_dbg(dev, "num_tc: %u\n", ecc->num_tc);
dev_dbg(dev, "chmap_exist: %s\n", ecc->chmap_exist ? "yes" : "no");
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/13] dmaengine: edma: Correct PaRAM access function names (_parm_ to _param_)
These inline functions are designed to modify parts of the PaRAM in eDMA.
Change the names accordingly.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index f33a297f870f..d8639a92f286 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -349,32 +349,32 @@ static inline void edma_shadow0_write_array(struct
edma_cc *ecc, int offset,
edma_write(ecc, EDMA_SHADOW0 + offset + (i << 2), val);
}
-static inline unsigned int edma_parm_read(struct edma_cc *ecc, int offset,
- int param_no)
+static inline unsigned int edma_param_read(struct edma_cc *ecc, int offset,
+ int param_no)
{
return edma_read(ecc, EDMA_PARM + offset + (param_no << 5));
}
-static inline void edma_parm_write(struct edma_cc *ecc, int offset,
- int param_no, unsigned val)
+static inline void edma_param_write(struct edma_cc *ecc, int offset,
+ int param_no, unsigned val)
{
edma_write(ecc, EDMA_PARM + offset + (param_no << 5), val);
}
-static inline void edma_parm_modify(struct edma_cc *ecc, int offset,
- int param_no, unsigned and, unsigned or)
+static inline void edma_param_modify(struct edma_cc *ecc, int offset,
+int param_no, unsigned and, unsigned or)
{
edma_modify(ecc, EDMA_PARM + offset + (param_no << 5), and, or);
}
-static inline void edma_parm_and(struct edma_cc *ecc, int offset, int param_no,
-unsigned and)
+static inline void edma_param_and(struct edma_cc *ecc, int offset, int
param_no,
+ unsigned and)
{
edma_and(ecc, EDMA_PARM + offset + (param_no << 5), and);
}
-static inline void edma_parm_or(struct edma_cc *ecc, int offset, int param_no,
- unsigned or)
+static inline void edma_param_or(struct edma_cc *ecc, int offset, int param_no,
+unsigned or)
{
edma_or(ecc, EDMA_PARM + offset + (param_no << 5), or);
}
@@ -594,8 +594,8 @@ static void edma_link(struct edma_cc *ecc, unsigned from,
unsigned to)
if (from >= ecc->num_slots || to >= ecc->num_slots)
return;
- edma_parm_modify(ecc, PARM_LINK_BCNTRLD, from, 0x,
-PARM_OFFSET(to));
+ edma_param_modify(ecc, PARM_LINK_BCNTRLD, from, 0x,
+ PARM_OFFSET(to));
}
/**
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/13] dmaengine: edma: Simplify function parameter list for channel operations
Instead of passing a pointer to struct edma_cc and the channel number,
pass only the pointer to the edma_chan structure for the given channel.
This struct contains all the information needed by the functions and the
use of this makes it obvious that most of the sanity checks can be removed
from the driver.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/dma/edma.c | 396 +
1 file changed, 123 insertions(+), 273 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 6de571f4aa0f..f33a297f870f 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -391,17 +391,19 @@ static inline void clear_bits(int offset, int len,
unsigned long *p)
clear_bit(offset + (len - 1), p);
}
-static void edma_map_dmach_to_queue(struct edma_cc *ecc, unsigned ch_no,
+static void edma_map_dmach_to_queue(struct edma_chan *echan,
enum dma_event_q queue_no)
{
- int bit = (ch_no & 0x7) * 4;
+ struct edma_cc *ecc = echan->ecc;
+ int channel = EDMA_CHAN_SLOT(echan->ch_num);
+ int bit = (channel & 0x7) * 4;
/* default to low priority queue */
if (queue_no == EVENTQ_DEFAULT)
queue_no = ecc->default_queue;
queue_no &= 7;
- edma_modify_array(ecc, EDMA_DMAQNUM, (ch_no >> 3), ~(0x7 << bit),
+ edma_modify_array(ecc, EDMA_DMAQNUM, (channel >> 3), ~(0x7 << bit),
queue_no << bit);
}
@@ -413,10 +415,12 @@ static void edma_assign_priority_to_queue(struct edma_cc
*ecc, int queue_no,
edma_modify(ecc, EDMA_QUEPRI, ~(0x7 << bit), ((priority & 0x7) << bit));
}
-static void edma_set_chmap(struct edma_cc *ecc, int channel, int slot)
+static void edma_set_chmap(struct edma_chan *echan, int slot)
{
+ struct edma_cc *ecc = echan->ecc;
+ int channel = EDMA_CHAN_SLOT(echan->ch_num);
+
if (ecc->chmap_exist) {
- channel = EDMA_CHAN_SLOT(channel);
slot = EDMA_CHAN_SLOT(slot);
edma_write_array(ecc, EDMA_DCHMAP, channel, (slot << 5));
}
@@ -476,18 +480,19 @@ static int prepare_unused_channel_list(struct device
*dev, void *data)
return 0;
}
-static void edma_setup_interrupt(struct edma_cc *ecc, unsigned lch, bool
enable)
+static void edma_setup_interrupt(struct edma_chan *echan, bool enable)
{
- lch = EDMA_CHAN_SLOT(lch);
+ struct edma_cc *ecc = echan->ecc;
+ int channel = EDMA_CHAN_SLOT(echan->ch_num);
if (enable) {
- edma_shadow0_write_array(ecc, SH_ICR, lch >> 5,
-BIT(lch & 0x1f));
- edma_shadow0_write_array(ecc, SH_IESR, lch >> 5,
-BIT(lch & 0x1f));
+ edma_shadow0_write_array(ecc, SH_ICR, channel >> 5,
+BIT(channel & 0x1f));
+ edma_shadow0_write_array(ecc, SH_IESR, channel >> 5,
+BIT(channel & 0x1f));
} else {
- edma_shadow0_write_array(ecc, SH_IECR, lch >> 5,
-BIT(lch & 0x1f));
+ edma_shadow0_write_array(ecc, SH_IECR, channel >> 5,
+BIT(channel & 0x1f));
}
}
@@ -613,40 +618,25 @@ static dma_addr_t edma_get_position(struct edma_cc *ecc,
unsigned slot,
return edma_read(ecc, offs);
}
-/*---*/
-/**
- * edma_start - start dma on a channel
- * @ecc: pointer to edma_cc struct
- * @channel: channel being activated
- *
+/*
* Channels with event associations will be triggered by their hardware
* events, and channels without such associations will be triggered by
* software. (At this writing there is no interface for using software
* triggers except with channels that don't support hardware triggers.)
- *
- * Returns zero on success, else negative errno.
*/
-static int edma_start(struct edma_cc *ecc, unsigned channel)
+static void edma_start(struct edma_chan *echan)
{
- if (ecc->id != EDMA_CTLR(channel)) {
- dev_err(ecc->dev, "%s: ID mismatch for eDMA%d: %d\n", __func__,
- ecc->id, EDMA_CTLR(channel));
- return -EINVAL;
- }
- channel = EDMA_CHAN_SLOT(channel);
-
- if (channel < ecc->num_channels) {
- int j = channel >> 5;
- unsigned int mask = BIT(channel & 0x1f);
+ struct edma_cc *ecc = echan->ecc;
+ int channel = EDMA_CHAN_SLOT(echan->ch_num);
+ int j = (channel >> 5);
+ unsigned int mask = BIT(channel & 0x1f);
+ if (test_bit(
[PATCH] ARM: DTS: da850: Enable DMA use for MMC0
Add the needed bindings for MMC0 in order to be able to utilize the DMA
instead of PIO mode.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
arch/arm/boot/dts/da850.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index e73f5efb3aa3..f9eea05c0a53 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -202,6 +202,9 @@
compatible = "ti,da830-mmc";
reg = <0x4 0x1000>;
interrupts = <16>;
+ dmas = < 16>,
+ < 17>;
+ dma-names = "rx", "tx";
status = "disabled";
};
ehrpwm0: ehrpwm@01f0 {
--
2.5.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ARM: OMAP/DTS: dra7/72-evm/beagle-x15: Audio support
Hi Tony, On 08/24/2015 10:19 AM, Peter Ujfalusi wrote: > Hi, > > this series will enable analog audio (via onboard aic310x codec) for dra7-evm, > dra72-evm and am57xx-beagle-x15 boards. > In these board McASP3 is connected to the codec and for the McASP3 we needed > to > have the DMA crossbar in place since the request lines are not mapped by > default. Did you had a chance to look at this series? > Regars, > Peter > --- > Peter Ujfalusi (11): > ARM: OMAP: DRA7: hwmod: Add data for McASP3 > ARM: DTS: dra7: Add McASP3 node > ARM: DTS: dra7-evm: Rename mmc2_3v3 supply to evm_3v3_sw > ARM: DTS: dra7-evm: Add fixed regulator to be used by aic3106's DVDD > ARM: DTS: dra7-evm: Enable pcf8575 (0x26 address) on i2c2 bus > ARM: DTS: dra7-evm: Audio support > ARM: DTS: dra72-evm: Add fixed regulator representing DVDD supply for > aic3106 > ARM: DTS: dra72-evm: Add gpio hog for vin6_sel_s0 to select audio > ARM: DTS: dra72-evm: Audio support > ARM: DTS: am57xx-beagle-x15: Add fixed regulator for aic3104's DVDD > ARM: DTS: am57xx-beagle-x15: Enable analog audio support > > arch/arm/boot/dts/am57xx-beagle-x15.dts | 95 > arch/arm/boot/dts/dra7-evm.dts| 142 > +- > arch/arm/boot/dts/dra7.dtsi | 15 > arch/arm/boot/dts/dra72-evm.dts | 138 + > arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 + > 5 files changed, 428 insertions(+), 3 deletions(-) > -- Péter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/5] ASoC: davinci-mcasp: Set .symmetric_rates = 1 in snd_soc_dai_driver
On 09/09/2015 09:27 PM, Jyri Sarha wrote:
> The TX and RX direction share the same bit clock and frame sync, so
> the samplerate must be the same to both directions.
Acked-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> Signed-off-by: Jyri Sarha <jsa...@ti.com>
> ---
> sound/soc/davinci/davinci-mcasp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/davinci/davinci-mcasp.c
> b/sound/soc/davinci/davinci-mcasp.c
> index fa0511b..bbd1987 100644
> --- a/sound/soc/davinci/davinci-mcasp.c
> +++ b/sound/soc/davinci/davinci-mcasp.c
> @@ -1304,6 +1304,7 @@ static struct snd_soc_dai_driver davinci_mcasp_dai[] = {
> .ops= _mcasp_dai_ops,
>
> .symmetric_samplebits = 1,
> + .symmetric_rates= 1,
> },
> {
> .name = "davinci-mcasp.1",
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] ARM: OMAP/DTS: dra7/72-evm/beagle-x15: Audio support
Hi, this series will enable analog audio (via onboard aic310x codec) for dra7-evm, dra72-evm and am57xx-beagle-x15 boards. In these board McASP3 is connected to the codec and for the McASP3 we needed to have the DMA crossbar in place since the request lines are not mapped by default. Regars, Peter --- Peter Ujfalusi (11): ARM: OMAP: DRA7: hwmod: Add data for McASP3 ARM: DTS: dra7: Add McASP3 node ARM: DTS: dra7-evm: Rename mmc2_3v3 supply to evm_3v3_sw ARM: DTS: dra7-evm: Add fixed regulator to be used by aic3106's DVDD ARM: DTS: dra7-evm: Enable pcf8575 (0x26 address) on i2c2 bus ARM: DTS: dra7-evm: Audio support ARM: DTS: dra72-evm: Add fixed regulator representing DVDD supply for aic3106 ARM: DTS: dra72-evm: Add gpio hog for vin6_sel_s0 to select audio ARM: DTS: dra72-evm: Audio support ARM: DTS: am57xx-beagle-x15: Add fixed regulator for aic3104's DVDD ARM: DTS: am57xx-beagle-x15: Enable analog audio support arch/arm/boot/dts/am57xx-beagle-x15.dts | 95 arch/arm/boot/dts/dra7-evm.dts| 142 +- arch/arm/boot/dts/dra7.dtsi | 15 arch/arm/boot/dts/dra72-evm.dts | 138 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 + 5 files changed, 428 insertions(+), 3 deletions(-) -- 2.5.0 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] ARM: OMAP: DRA7: hwmod: Add data for McASP3
McASP3 is used by default on DRA7x based boards for audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247bced49..c38b7fa30c27 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1298,6 +1298,38 @@ static struct omap_hwmod dra7xx_mcspi4_hwmod = {
};
/*
+ * 'mcasp' class
+ *
+ */
+static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = {
+ .sysc_offs = 0x0004,
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type3,
+};
+
+static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = {
+ .name = mcasp,
+ .sysc = dra7xx_mcasp_sysc,
+};
+
+/* mcasp3 */
+static struct omap_hwmod dra7xx_mcasp3_hwmod = {
+ .name = mcasp3,
+ .class = dra7xx_mcasp_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = mcasp3_ahclkx_mux,
+ .flags = HWMOD_SWSUP_SIDLE,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4PER2_MCASP3_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4PER2_MCASP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'mmc' class
*
*/
@@ -2566,6 +2598,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_per2 - mcasp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp3 = {
+ .master = dra7xx_l4_per2_hwmod,
+ .slave = dra7xx_mcasp3_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
{
.pa_start = 0x48078000,
@@ -3338,6 +3378,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_wkup__dcan1,
dra7xx_l4_per2__dcan2,
dra7xx_l4_per2__cpgmac0,
+ dra7xx_l4_per2__mcasp3,
dra7xx_gmac__mdio,
dra7xx_l4_cfg__dma_system,
dra7xx_l3_main_1__dss,
--
2.5.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/11] ARM: DTS: dra72-evm: Audio support
The board uses tlv320aic3106 codec connected to McASP3. The master clock
for the codec and McASP3 is coming from ATL2.
McASP3 is the master on the I2S bus.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/dra72-evm.dts | 114
1 file changed, 114 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 33be5c64bda3..249000d50090 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -9,6 +9,7 @@
#include dra72x.dtsi
#include dt-bindings/gpio/gpio.h
+#include dt-bindings/clk/ti-dra7-atl.h
/ {
model = TI DRA722;
@@ -102,6 +103,40 @@
};
};
};
+
+ sound0: sound@0 {
+ compatible = simple-audio-card;
+ simple-audio-card,name = DRA7xx-EVM;
+ simple-audio-card,widgets =
+ Headphone, Headphone Jack,
+ Line, Line Out,
+ Microphone, Mic Jack,
+ Line, Line In;
+ simple-audio-card,routing =
+ Headphone Jack, HPLOUT,
+ Headphone Jack, HPROUT,
+ Line Out, LLOUT,
+ Line Out, RLOUT,
+ MIC3L,Mic Jack,
+ MIC3R,Mic Jack,
+ Mic Jack, Mic Bias,
+ LINE1L, Line In,
+ LINE1R, Line In;
+ simple-audio-card,format = dsp_b;
+ simple-audio-card,bitclock-master = sound0_master;
+ simple-audio-card,frame-master = sound0_master;
+ simple-audio-card,bitclock-inversion;
+
+ sound0_master: simple-audio-card,cpu {
+ sound-dai = mcasp3;
+ system-clock-frequency = 5644800;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = tlv320aic3106;
+ clocks = atl_clkin2_ck;
+ };
+ };
};
dra7_pmx_core {
@@ -236,6 +271,31 @@
0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
;
};
+
+ atl_pins: pinmux_atl_pins {
+ pinctrl-single,pins =
+ 0x298 (PIN_OUTPUT | MUX_MODE5) /* xref_clk1.atl_clk1 */
+ 0x29c (PIN_OUTPUT | MUX_MODE5) /* xref_clk2.atl_clk2 */
+ ;
+ };
+
+ mcasp3_pins: pinmux_mcasp3_pins {
+ pinctrl-single,pins =
+ 0x324 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_aclkx
*/
+ 0x328 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_fsx */
+ 0x32c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr0
*/
+ 0x330 (PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr1
*/
+ ;
+ };
+
+ mcasp3_sleep_pins: pinmux_mcasp3_sleep_pins {
+ pinctrl-single,pins =
+ 0x324 (PIN_INPUT_PULLDOWN | MUX_MODE15)
+ 0x328 (PIN_INPUT_PULLDOWN | MUX_MODE15)
+ 0x32c (PIN_INPUT_PULLDOWN | MUX_MODE15)
+ 0x330 (PIN_INPUT_PULLDOWN | MUX_MODE15)
+ ;
+ };
};
i2c1 {
@@ -376,6 +436,21 @@
output-low;
};
};
+
+ tlv320aic3106: tlv320aic3106@19 {
+ #sound-dai-cells = 0;
+ compatible = ti,tlv320aic3106;
+ reg = 0x19;
+ adc-settle-ms = 40;
+ ai3x-micbias-vg = 1; /* 2.0V */
+ status = okay;
+
+ /* Regulators */
+ AVDD-supply = evm_3v3;
+ IOVDD-supply = evm_3v3;
+ DRVDD-supply = evm_3v3;
+ DVDD-supply = aic_dvdd;
+ };
};
i2c5 {
@@ -719,3 +794,42 @@
};
};
};
+
+atl {
+ pinctrl-names = default;
+ pinctrl-0 = atl_pins;
+
+ assigned-clocks = abe_dpll_sys_clk_mux,
+ atl_gfclk_mux,
+ dpll_abe_ck,
+ dpll_abe_m2x2_ck,
+ atl_clkin2_ck;
+ assigned-clock-parents = sys_clkin2, dpll_abe_m2_ck;
+ assigned-clock-rates = 0, 0, 180633600, 361267200, 5644800;
+
+ status = okay;
+
+ atl2 {
+ bws = DRA7_ATL_WS_MCASP2_FSX;
+ aws = DRA7_ATL_WS_MCASP3_FSX;
+ };
+};
+
+mcasp3 {
+ #sound-dai-cells = 0;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = mcasp3_pins;
+ pinctrl-1 = mcasp3_sleep_pins;
+
+ assigned-clocks = mcasp3_ahclkx_mux;
+ assigned-clock-parents = atl_clkin2_ck;
+
+ status = okay;
+
+ op-mode = 0
[PATCH 07/11] ARM: DTS: dra72-evm: Add fixed regulator representing DVDD supply for aic3106
The DVDD is supplied via TPS77018DBVT fixed regulator from evm_3v3
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
---
arch/arm/boot/dts/dra72-evm.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 6f6bd98c98df..ac3a29483791 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -30,6 +30,15 @@
regulator-max-microvolt = 330;
};
+ aic_dvdd: fixedregulator-aic_dvdd {
+ /* TPS77018DBVT */
+ compatible = regulator-fixed;
+ regulator-name = aic_dvdd;
+ vin-supply = evm_3v3;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
evm_3v3_sd: fixedregulator-sd {
compatible = regulator-fixed;
regulator-name = evm_3v3_sd;
--
2.5.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/11] ARM: DTS: dra7-evm: Audio support
The board uses tlv320aic3106 codec connected to McASP3. The master clock
for the codec and McASP3 is coming from ATL2.
McASP3 is the master on the I2S bus.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 113 +
1 file changed, 113 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 3694046c29eb..1a66d359f3e3 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -9,6 +9,7 @@
#include dra74x.dtsi
#include dt-bindings/gpio/gpio.h
+#include dt-bindings/clk/ti-dra7-atl.h
/ {
model = TI DRA742;
@@ -64,6 +65,40 @@
enable-active-high;
gpio = gpio7 11 GPIO_ACTIVE_HIGH;
};
+
+ sound0: sound@0 {
+ compatible = simple-audio-card;
+ simple-audio-card,name = DRA7xx-EVM;
+ simple-audio-card,widgets =
+ Headphone, Headphone Jack,
+ Line, Line Out,
+ Microphone, Mic Jack,
+ Line, Line In;
+ simple-audio-card,routing =
+ Headphone Jack, HPLOUT,
+ Headphone Jack, HPROUT,
+ Line Out, LLOUT,
+ Line Out, RLOUT,
+ MIC3L,Mic Jack,
+ MIC3R,Mic Jack,
+ Mic Jack, Mic Bias,
+ LINE1L, Line In,
+ LINE1R, Line In;
+ simple-audio-card,format = dsp_b;
+ simple-audio-card,bitclock-master = sound0_master;
+ simple-audio-card,frame-master = sound0_master;
+ simple-audio-card,bitclock-inversion;
+
+ sound0_master: simple-audio-card,cpu {
+ sound-dai = mcasp3;
+ system-clock-frequency = 5644800;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = tlv320aic3106;
+ clocks = atl_clkin2_ck;
+ };
+ };
};
dra7_pmx_core {
@@ -292,6 +327,31 @@
0x418 (MUX_MODE15 | PULL_UP) /* wakeup0.off */
;
};
+
+ atl_pins: pinmux_atl_pins {
+ pinctrl-single,pins =
+ 0x298 (PIN_OUTPUT | MUX_MODE5) /* xref_clk1.atl_clk1 */
+ 0x29c (PIN_OUTPUT | MUX_MODE5) /* xref_clk2.atl_clk2 */
+ ;
+ };
+
+ mcasp3_pins: pinmux_mcasp3_pins {
+ pinctrl-single,pins =
+ 0x324 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_aclkx
*/
+ 0x328 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_fsx */
+ 0x32c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr0
*/
+ 0x330 (PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr1
*/
+ ;
+ };
+
+ mcasp3_sleep_pins: pinmux_mcasp3_sleep_pins {
+ pinctrl-single,pins =
+ 0x324 (MUX_MODE15)
+ 0x328 (MUX_MODE15)
+ 0x32c (MUX_MODE15)
+ 0x330 (MUX_MODE15)
+ ;
+ };
};
i2c1 {
@@ -431,6 +491,20 @@
#interrupt-cells = 2;
};
+ tlv320aic3106: tlv320aic3106@19 {
+ #sound-dai-cells = 0;
+ compatible = ti,tlv320aic3106;
+ reg = 0x19;
+ adc-settle-ms = 40;
+ ai3x-micbias-vg = 1; /* 2.0V */
+ status = okay;
+
+ /* Regulators */
+ AVDD-supply = evm_3v3_sw;
+ IOVDD-supply = evm_3v3_sw;
+ DRVDD-supply = evm_3v3_sw;
+ DVDD-supply = aic_dvdd;
+ };
};
i2c2 {
@@ -730,3 +804,42 @@
pinctrl-1 = dcan1_pins_sleep;
pinctrl-2 = dcan1_pins_default;
};
+
+atl {
+ pinctrl-names = default;
+ pinctrl-0 = atl_pins;
+
+ assigned-clocks = abe_dpll_sys_clk_mux,
+ atl_gfclk_mux,
+ dpll_abe_ck,
+ dpll_abe_m2x2_ck,
+ atl_clkin2_ck;
+ assigned-clock-parents = sys_clkin2, dpll_abe_m2_ck;
+ assigned-clock-rates = 0, 0, 180633600, 361267200, 5644800;
+
+ status = okay;
+
+ atl2 {
+ bws = DRA7_ATL_WS_MCASP2_FSX;
+ aws = DRA7_ATL_WS_MCASP3_FSX;
+ };
+};
+
+mcasp3 {
+ #sound-dai-cells = 0;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = mcasp3_pins;
+ pinctrl-1 = mcasp3_sleep_pins;
+
+ assigned-clocks = mcasp3_ahclkx_mux;
+ assigned-clock-parents = atl_clkin2_ck;
+
+ status = okay;
+
+ op-mode = 0; /* MCASP_IIS_MODE
[PATCH 05/11] ARM: DTS: dra7-evm: Enable pcf8575 (0x26 address) on i2c2 bus
This GPIO expander is used for controlling various muxes on the board.
By default select audio functionality over VIN6 by setting the P1
(vin6_sel_s0) pin to low.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index add77ac4f302..3694046c29eb 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -438,6 +438,20 @@
pinctrl-names = default;
pinctrl-0 = i2c2_pins;
clock-frequency = 40;
+
+ pcf_hdmi: gpio@26 {
+ compatible = nxp,pcf8575;
+ reg = 0x26;
+ gpio-controller;
+ #gpio-cells = 2;
+ p1 {
+ /* vin6_sel_s0: high: VIN6, low: audio */
+ gpio-hog;
+ gpios = 1 GPIO_ACTIVE_HIGH;
+ output-low;
+ line-name = vin6_sel_s0;
+ };
+ };
};
i2c3 {
--
2.5.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] ARM: DTS: dra7-evm: Add fixed regulator to be used by aic3106's DVDD
TPS77018DBVT is used to create 1.8V from avm_3v3_sw's 3.3V connected to
aic3106's DVDD.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index de02cf5853a9..add77ac4f302 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -35,6 +35,15 @@
regulator-max-microvolt = 330;
};
+ aic_dvdd: fixedregulator-aic_dvdd {
+ /* TPS77018DBVT */
+ compatible = regulator-fixed;
+ regulator-name = aic_dvdd;
+ vin-supply = evm_3v3_sw;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
extcon_usb1: extcon_usb1 {
compatible = linux,extcon-usb-gpio;
id-gpio = pcf_gpio_21 1 GPIO_ACTIVE_HIGH;
--
2.5.0
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
