[PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Lee Jones]

At this moment in time the Ux500 ASoC driver obtains its DMA information
via AUXDATA platform data passing. To make the driver more independent
we have to start extracting it from the Device Tree.
 
If this patch-set could go through ASoC as a whole, it would drive down
the chance of a dependency mess. Vinod has already provided Acks for his
parts, so it's just between you two Linus and Mark.

 Documentation/devicetree/bindings/dma/ste-dma40.txt |   3 ++
 arch/arm/boot/dts/ste-dbx5x0.dtsi                   |  15 ++++++++++
 arch/arm/mach-ux500/board-mop500-audio.c            |   8 +++---
 drivers/dma/ste_dma40.c                             |   4 +++
 include/linux/platform_data/asoc-ux500-msp.h        |   9 +-----
 sound/soc/ux500/mop500.c                            |   2 ++
 sound/soc/ux500/ux500_msp_dai.c                     | 150 +++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------
 sound/soc/ux500/ux500_msp_i2s.c                     |  56 +++++++++++++++++++++++++++----------
 sound/soc/ux500/ux500_msp_i2s.h                     |   2 +-
 sound/soc/ux500/ux500_pcm.c                         |  32 +++++++++++++++------
 10 files changed, 160 insertions(+), 121 deletions(-)

Cc: Mark Brown <broonie@kernel.org>

[PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Lee Jones]

At this moment in time the Ux500 ASoC driver obtains its DMA information
via AUXDATA platform data passing. To make the driver more independent
we have to start extracting it from the Device Tree.
 
If this patch-set could go through ASoC as a whole, it would drive down
the chance of a dependency mess. Vinod has already provided Acks for his
parts, so it's just between you two Linus and Mark.

 Documentation/devicetree/bindings/dma/ste-dma40.txt |   3 ++
 arch/arm/boot/dts/ste-dbx5x0.dtsi                   |  15 ++++++++++
 arch/arm/mach-ux500/board-mop500-audio.c            |   8 +++---
 drivers/dma/ste_dma40.c                             |   4 +++
 include/linux/platform_data/asoc-ux500-msp.h        |   9 +-----
 sound/soc/ux500/mop500.c                            |   2 ++
 sound/soc/ux500/ux500_msp_dai.c                     | 150 +++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------
 sound/soc/ux500/ux500_msp_i2s.c                     |  56 +++++++++++++++++++++++++++----------
 sound/soc/ux500/ux500_msp_i2s.h                     |   2 +-
 sound/soc/ux500/ux500_pcm.c                         |  32 +++++++++++++++------
 10 files changed, 160 insertions(+), 121 deletions(-)

Cc: Mark Brown <broonie@kernel.org>

[PATCH 01/10] dma: ste_dma40: Expand DT binding to accept 'high-priority channel' flag

[Lee Jones]

This is used for MSP (audio) devices which is about to be fully DT:ed.

Cc: devicetree@vger.kernel.org
Acked-by: Vinod Koul <vinod.koul@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 Documentation/devicetree/bindings/dma/ste-dma40.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
index a8c21c2..1f5729f 100644
--- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -50,6 +50,9 @@ Each dmas request consists of 4 cells:
         0x00000008: Use fixed channel:
                 Use automatic channel selection when unset
                 Use DMA request line number when set
+        0x00000010: Set channel as high priority:
+                Normal priority when unset
+                High priority when set
 
 Example:
 
-- 
1.8.1.2

[PATCH 01/10] dma: ste_dma40: Expand DT binding to accept 'high-priority channel' flag

[Lee Jones]

This is used for MSP (audio) devices which is about to be fully DT:ed.

Cc: devicetree@vger.kernel.org
Acked-by: Vinod Koul <vinod.koul@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 Documentation/devicetree/bindings/dma/ste-dma40.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
index a8c21c2..1f5729f 100644
--- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -50,6 +50,9 @@ Each dmas request consists of 4 cells:
         0x00000008: Use fixed channel:
                 Use automatic channel selection when unset
                 Use DMA request line number when set
+        0x00000010: Set channel as high priority:
+                Normal priority when unset
+                High priority when set
 
 Example:
 
-- 
1.8.1.2

[PATCH 01/10] dma: ste_dma40: Expand DT binding to accept 'high-priority channel' flag

[Lee Jones]

This is used for MSP (audio) devices which is about to be fully DT:ed.

Cc: devicetree at vger.kernel.org
Acked-by: Vinod Koul <vinod.koul@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 Documentation/devicetree/bindings/dma/ste-dma40.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
index a8c21c2..1f5729f 100644
--- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -50,6 +50,9 @@ Each dmas request consists of 4 cells:
         0x00000008: Use fixed channel:
                 Use automatic channel selection when unset
                 Use DMA request line number when set
+        0x00000010: Set channel as high priority:
+                Normal priority when unset
+                High priority when set
 
 Example:
 
-- 
1.8.1.2

[PATCH 02/10] dma: ste_dma40: Parse flags property for new 'high priority channel' request

[Lee Jones]

This is used for MSP (audio) devices which is about to be fully DT:ed.

Acked-by: Vinod Koul <vinod.koul@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/dma/ste_dma40.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index b8c031b..00a2de9 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2409,6 +2409,7 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
 #define D40_DT_FLAGS_DIR(flags)        ((flags >> 1) & 0x1)
 #define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
 #define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
+#define D40_DT_FLAGS_HIGH_PRIO(flags)  ((flags >> 4) & 0x1)
 
 static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
 				  struct of_dma *ofdma)
@@ -2446,6 +2447,9 @@ static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
 		cfg.use_fixed_channel = true;
 	}
 
+	if (D40_DT_FLAGS_HIGH_PRIO(flags))
+		cfg.high_priority = true;
+
 	return dma_request_channel(cap, stedma40_filter, &cfg);
 }
 
-- 
1.8.1.2

[PATCH 02/10] dma: ste_dma40: Parse flags property for new 'high priority channel' request

[Lee Jones]

This is used for MSP (audio) devices which is about to be fully DT:ed.

Acked-by: Vinod Koul <vinod.koul@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/dma/ste_dma40.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index b8c031b..00a2de9 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2409,6 +2409,7 @@ static void d40_set_prio_realtime(struct d40_chan *d40c)
 #define D40_DT_FLAGS_DIR(flags)        ((flags >> 1) & 0x1)
 #define D40_DT_FLAGS_BIG_ENDIAN(flags) ((flags >> 2) & 0x1)
 #define D40_DT_FLAGS_FIXED_CHAN(flags) ((flags >> 3) & 0x1)
+#define D40_DT_FLAGS_HIGH_PRIO(flags)  ((flags >> 4) & 0x1)
 
 static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
 				  struct of_dma *ofdma)
@@ -2446,6 +2447,9 @@ static struct dma_chan *d40_xlate(struct of_phandle_args *dma_spec,
 		cfg.use_fixed_channel = true;
 	}
 
+	if (D40_DT_FLAGS_HIGH_PRIO(flags))
+		cfg.high_priority = true;
+
 	return dma_request_channel(cap, stedma40_filter, &cfg);
 }
 
-- 
1.8.1.2

[PATCH 03/10] ARM: ux500: Don't use enums for MSP IDs - for easy DT conversion

[Lee Jones]

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/mach-ux500/board-mop500-audio.c     | 8 ++++----
 include/linux/platform_data/asoc-ux500-msp.h | 9 +--------
 sound/soc/ux500/ux500_msp_i2s.h              | 2 +-
 3 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index d528059..c5eeee3 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -29,7 +29,7 @@ static struct stedma40_chan_cfg msp0_dma_tx = {
 };
 
 struct msp_i2s_platform_data msp0_platform_data = {
-	.id = MSP_I2S_0,
+	.id = 0,
 	.msp_i2s_dma_rx = &msp0_dma_rx,
 	.msp_i2s_dma_tx = &msp0_dma_tx,
 };
@@ -47,7 +47,7 @@ static struct stedma40_chan_cfg msp1_dma_tx = {
 };
 
 struct msp_i2s_platform_data msp1_platform_data = {
-	.id = MSP_I2S_1,
+	.id = 1,
 	.msp_i2s_dma_rx = NULL,
 	.msp_i2s_dma_tx = &msp1_dma_tx,
 };
@@ -67,13 +67,13 @@ static struct stedma40_chan_cfg msp2_dma_tx = {
 };
 
 struct msp_i2s_platform_data msp2_platform_data = {
-	.id = MSP_I2S_2,
+	.id = 2,
 	.msp_i2s_dma_rx = &msp2_dma_rx,
 	.msp_i2s_dma_tx = &msp2_dma_tx,
 };
 
 struct msp_i2s_platform_data msp3_platform_data = {
-	.id		= MSP_I2S_3,
+	.id		= 3,
 	.msp_i2s_dma_rx	= &msp1_dma_rx,
 	.msp_i2s_dma_tx	= NULL,
 };
diff --git a/include/linux/platform_data/asoc-ux500-msp.h b/include/linux/platform_data/asoc-ux500-msp.h
index 9991aea..2f34bb9 100644
--- a/include/linux/platform_data/asoc-ux500-msp.h
+++ b/include/linux/platform_data/asoc-ux500-msp.h
@@ -10,16 +10,9 @@
 
 #include <linux/platform_data/dma-ste-dma40.h>
 
-enum msp_i2s_id {
-	MSP_I2S_0 = 0,
-	MSP_I2S_1,
-	MSP_I2S_2,
-	MSP_I2S_3,
-};
-
 /* Platform data structure for a MSP I2S-device */
 struct msp_i2s_platform_data {
-	enum msp_i2s_id id;
+	int id;
 	struct stedma40_chan_cfg *msp_i2s_dma_rx;
 	struct stedma40_chan_cfg *msp_i2s_dma_tx;
 };
diff --git a/sound/soc/ux500/ux500_msp_i2s.h b/sound/soc/ux500/ux500_msp_i2s.h
index 258d0bc..875de0f 100644
--- a/sound/soc/ux500/ux500_msp_i2s.h
+++ b/sound/soc/ux500/ux500_msp_i2s.h
@@ -475,7 +475,7 @@ struct ux500_msp_dma_params {
 };
 
 struct ux500_msp {
-	enum msp_i2s_id id;
+	int id;
 	void __iomem *registers;
 	struct device *dev;
 	struct ux500_msp_dma_params playback_dma_data;
-- 
1.8.1.2

[PATCH 03/10] ARM: ux500: Don't use enums for MSP IDs - for easy DT conversion

[Lee Jones]

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/mach-ux500/board-mop500-audio.c     | 8 ++++----
 include/linux/platform_data/asoc-ux500-msp.h | 9 +--------
 sound/soc/ux500/ux500_msp_i2s.h              | 2 +-
 3 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
index d528059..c5eeee3 100644
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ b/arch/arm/mach-ux500/board-mop500-audio.c
@@ -29,7 +29,7 @@ static struct stedma40_chan_cfg msp0_dma_tx = {
 };
 
 struct msp_i2s_platform_data msp0_platform_data = {
-	.id = MSP_I2S_0,
+	.id = 0,
 	.msp_i2s_dma_rx = &msp0_dma_rx,
 	.msp_i2s_dma_tx = &msp0_dma_tx,
 };
@@ -47,7 +47,7 @@ static struct stedma40_chan_cfg msp1_dma_tx = {
 };
 
 struct msp_i2s_platform_data msp1_platform_data = {
-	.id = MSP_I2S_1,
+	.id = 1,
 	.msp_i2s_dma_rx = NULL,
 	.msp_i2s_dma_tx = &msp1_dma_tx,
 };
@@ -67,13 +67,13 @@ static struct stedma40_chan_cfg msp2_dma_tx = {
 };
 
 struct msp_i2s_platform_data msp2_platform_data = {
-	.id = MSP_I2S_2,
+	.id = 2,
 	.msp_i2s_dma_rx = &msp2_dma_rx,
 	.msp_i2s_dma_tx = &msp2_dma_tx,
 };
 
 struct msp_i2s_platform_data msp3_platform_data = {
-	.id		= MSP_I2S_3,
+	.id		= 3,
 	.msp_i2s_dma_rx	= &msp1_dma_rx,
 	.msp_i2s_dma_tx	= NULL,
 };
diff --git a/include/linux/platform_data/asoc-ux500-msp.h b/include/linux/platform_data/asoc-ux500-msp.h
index 9991aea..2f34bb9 100644
--- a/include/linux/platform_data/asoc-ux500-msp.h
+++ b/include/linux/platform_data/asoc-ux500-msp.h
@@ -10,16 +10,9 @@
 
 #include <linux/platform_data/dma-ste-dma40.h>
 
-enum msp_i2s_id {
-	MSP_I2S_0 = 0,
-	MSP_I2S_1,
-	MSP_I2S_2,
-	MSP_I2S_3,
-};
-
 /* Platform data structure for a MSP I2S-device */
 struct msp_i2s_platform_data {
-	enum msp_i2s_id id;
+	int id;
 	struct stedma40_chan_cfg *msp_i2s_dma_rx;
 	struct stedma40_chan_cfg *msp_i2s_dma_tx;
 };
diff --git a/sound/soc/ux500/ux500_msp_i2s.h b/sound/soc/ux500/ux500_msp_i2s.h
index 258d0bc..875de0f 100644
--- a/sound/soc/ux500/ux500_msp_i2s.h
+++ b/sound/soc/ux500/ux500_msp_i2s.h
@@ -475,7 +475,7 @@ struct ux500_msp_dma_params {
 };
 
 struct ux500_msp {
-	enum msp_i2s_id id;
+	int id;
 	void __iomem *registers;
 	struct device *dev;
 	struct ux500_msp_dma_params playback_dma_data;
-- 
1.8.1.2

[PATCH 04/10] ARM: ux500: Add DMA config bindings for MSP devices

[Lee Jones]

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/ste-dbx5x0.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi b/arch/arm/boot/dts/ste-dbx5x0.dtsi
index 7da99fe..50ff5ab 100644
--- a/arch/arm/boot/dts/ste-dbx5x0.dtsi
+++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi
@@ -913,6 +913,10 @@
 			interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
 			v-ape-supply = <&db8500_vape_reg>;
 
+			dmas = <&dma 31 0 0x12>, /* Logical - DevToMem - HighPrio */
+			       <&dma 31 0 0x10>; /* Logical - MemToDev - HighPrio */
+			dma-names = "rx", "tx";
+
 			clocks = <&prcc_kclk 1 3>, <&prcc_pclk 1 3>;
 			clock-names = "msp", "apb_pclk";
 
@@ -925,6 +929,9 @@
 			interrupts = <0 62 IRQ_TYPE_LEVEL_HIGH>;
 			v-ape-supply = <&db8500_vape_reg>;
 
+			dmas = <&dma 30 0 0x10>; /* Logical - MemToDev - HighPrio */
+			dma-names = "tx";
+
 			clocks = <&prcc_kclk 1 4>, <&prcc_pclk 1 4>;
 			clock-names = "msp", "apb_pclk";
 
@@ -938,6 +945,11 @@
 			interrupts = <0 98 IRQ_TYPE_LEVEL_HIGH>;
 			v-ape-supply = <&db8500_vape_reg>;
 
+			dmas = <&dma 14 0 0x12>, /* Logical  - DevToMem - HighPrio */
+			       <&dma 14 1 0x19>; /* Physical Chan 1 - MemToDev
+                                                    HighPrio - Fixed */
+			dma-names = "rx", "tx";
+
 			clocks = <&prcc_kclk 2 3>, <&prcc_pclk 2 5>;
 			clock-names = "msp", "apb_pclk";
 
@@ -950,6 +962,9 @@
 			interrupts = <0 62 IRQ_TYPE_LEVEL_HIGH>;
 			v-ape-supply = <&db8500_vape_reg>;
 
+			dmas = <&dma 30 0 0x12>; /* Logical - DevToMem - HighPrio */
+			dma-names = "rx";
+
 			clocks = <&prcc_kclk 1 10>, <&prcc_pclk 1 11>;
 			clock-names = "msp", "apb_pclk";
 
-- 
1.8.1.2

[PATCH 04/10] ARM: ux500: Add DMA config bindings for MSP devices

[Lee Jones]

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/ste-dbx5x0.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi b/arch/arm/boot/dts/ste-dbx5x0.dtsi
index 7da99fe..50ff5ab 100644
--- a/arch/arm/boot/dts/ste-dbx5x0.dtsi
+++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi
@@ -913,6 +913,10 @@
 			interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
 			v-ape-supply = <&db8500_vape_reg>;
 
+			dmas = <&dma 31 0 0x12>, /* Logical - DevToMem - HighPrio */
+			       <&dma 31 0 0x10>; /* Logical - MemToDev - HighPrio */
+			dma-names = "rx", "tx";
+
 			clocks = <&prcc_kclk 1 3>, <&prcc_pclk 1 3>;
 			clock-names = "msp", "apb_pclk";
 
@@ -925,6 +929,9 @@
 			interrupts = <0 62 IRQ_TYPE_LEVEL_HIGH>;
 			v-ape-supply = <&db8500_vape_reg>;
 
+			dmas = <&dma 30 0 0x10>; /* Logical - MemToDev - HighPrio */
+			dma-names = "tx";
+
 			clocks = <&prcc_kclk 1 4>, <&prcc_pclk 1 4>;
 			clock-names = "msp", "apb_pclk";
 
@@ -938,6 +945,11 @@
 			interrupts = <0 98 IRQ_TYPE_LEVEL_HIGH>;
 			v-ape-supply = <&db8500_vape_reg>;
 
+			dmas = <&dma 14 0 0x12>, /* Logical  - DevToMem - HighPrio */
+			       <&dma 14 1 0x19>; /* Physical Chan 1 - MemToDev
+                                                    HighPrio - Fixed */
+			dma-names = "rx", "tx";
+
 			clocks = <&prcc_kclk 2 3>, <&prcc_pclk 2 5>;
 			clock-names = "msp", "apb_pclk";
 
@@ -950,6 +962,9 @@
 			interrupts = <0 62 IRQ_TYPE_LEVEL_HIGH>;
 			v-ape-supply = <&db8500_vape_reg>;
 
+			dmas = <&dma 30 0 0x12>; /* Logical - DevToMem - HighPrio */
+			dma-names = "rx";
+
 			clocks = <&prcc_kclk 1 10>, <&prcc_pclk 1 11>;
 			clock-names = "msp", "apb_pclk";
 
-- 
1.8.1.2

[PATCH 05/10] ASoC: Ux500: Match platform by device node when booting Device Tree

[Lee Jones]

We're getting closer to fully enabling the Ux500 ASoC driver for Device
Tree. When we switch over from using AUXDATA we'll need to match platform
by only Device Tree nodes. In this patch we NULL out the platform_name,
and supply nodes for each platform device.

Cc: alsa-devel@alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/mop500.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/ux500/mop500.c b/sound/soc/ux500/mop500.c
index 178d1ba..b3b66aa 100644
--- a/sound/soc/ux500/mop500.c
+++ b/sound/soc/ux500/mop500.c
@@ -91,6 +91,8 @@ static int mop500_of_probe(struct platform_device *pdev,
 	for (i = 0; i < 2; i++) {
 		mop500_dai_links[i].cpu_of_node = msp_np[i];
 		mop500_dai_links[i].cpu_dai_name = NULL;
+		mop500_dai_links[i].platform_of_node = msp_np[i];
+		mop500_dai_links[i].platform_name = NULL;
 		mop500_dai_links[i].codec_of_node = codec_np;
 		mop500_dai_links[i].codec_name = NULL;
 	}
-- 
1.8.1.2

[PATCH 05/10] ASoC: Ux500: Match platform by device node when booting Device Tree

[Lee Jones]

We're getting closer to fully enabling the Ux500 ASoC driver for Device
Tree. When we switch over from using AUXDATA we'll need to match platform
by only Device Tree nodes. In this patch we NULL out the platform_name,
and supply nodes for each platform device.

Cc: alsa-devel@alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/mop500.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/ux500/mop500.c b/sound/soc/ux500/mop500.c
index 178d1ba..b3b66aa 100644
--- a/sound/soc/ux500/mop500.c
+++ b/sound/soc/ux500/mop500.c
@@ -91,6 +91,8 @@ static int mop500_of_probe(struct platform_device *pdev,
 	for (i = 0; i < 2; i++) {
 		mop500_dai_links[i].cpu_of_node = msp_np[i];
 		mop500_dai_links[i].cpu_dai_name = NULL;
+		mop500_dai_links[i].platform_of_node = msp_np[i];
+		mop500_dai_links[i].platform_name = NULL;
 		mop500_dai_links[i].codec_of_node = codec_np;
 		mop500_dai_links[i].codec_name = NULL;
 	}
-- 
1.8.1.2

[PATCH 05/10] ASoC: Ux500: Match platform by device node when booting Device Tree

[Lee Jones]

We're getting closer to fully enabling the Ux500 ASoC driver for Device
Tree. When we switch over from using AUXDATA we'll need to match platform
by only Device Tree nodes. In this patch we NULL out the platform_name,
and supply nodes for each platform device.

Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/mop500.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/ux500/mop500.c b/sound/soc/ux500/mop500.c
index 178d1ba..b3b66aa 100644
--- a/sound/soc/ux500/mop500.c
+++ b/sound/soc/ux500/mop500.c
@@ -91,6 +91,8 @@ static int mop500_of_probe(struct platform_device *pdev,
 	for (i = 0; i < 2; i++) {
 		mop500_dai_links[i].cpu_of_node = msp_np[i];
 		mop500_dai_links[i].cpu_dai_name = NULL;
+		mop500_dai_links[i].platform_of_node = msp_np[i];
+		mop500_dai_links[i].platform_name = NULL;
 		mop500_dai_links[i].codec_of_node = codec_np;
 		mop500_dai_links[i].codec_name = NULL;
 	}
-- 
1.8.1.2

[PATCH 06/10] ASoC: ux500_pcm: Extend Device Tree support to deal with DMA data

[Lee Jones]

Soon we will strip out pdata support from the Ux500 set of ASoC drivers.
When this happens it will have to supply a DMA slave_config to the
dmaengine. At the moment a great deal of this comes from pdata via
AUXDATA. We need to become independent of this soon. This patch starts
the process by allocating memory for the associated data structures and
fetches the MSP id used for const struct indexing.

Cc: alsa-devel@alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/ux500_msp_i2s.c | 56 ++++++++++++++++++++++++++++++-----------
 1 file changed, 41 insertions(+), 15 deletions(-)

diff --git a/sound/soc/ux500/ux500_msp_i2s.c b/sound/soc/ux500/ux500_msp_i2s.c
index 1ca8b08..7f2a4ac 100644
--- a/sound/soc/ux500/ux500_msp_i2s.c
+++ b/sound/soc/ux500/ux500_msp_i2s.c
@@ -646,6 +646,34 @@ int ux500_msp_i2s_close(struct ux500_msp *msp, unsigned int dir)
 
 }
 
+int ux500_msp_i2s_of_init_msp(struct platform_device *pdev,
+			      struct ux500_msp *msp,
+			      struct msp_i2s_platform_data **platform_data)
+{
+	struct msp_i2s_platform_data *pdata;
+
+	*platform_data = devm_kzalloc(&pdev->dev,
+				     sizeof(struct msp_i2s_platform_data),
+				     GFP_KERNEL);
+	pdata = *platform_data;
+	if (!pdata)
+		return -ENOMEM;
+
+	msp->playback_dma_data.dma_cfg = devm_kzalloc(&pdev->dev,
+					sizeof(struct stedma40_chan_cfg),
+					GFP_KERNEL);
+	if (!msp->playback_dma_data.dma_cfg)
+		return -ENOMEM;
+
+	msp->capture_dma_data.dma_cfg = devm_kzalloc(&pdev->dev,
+					sizeof(struct stedma40_chan_cfg),
+					GFP_KERNEL);
+	if (!msp->capture_dma_data.dma_cfg)
+		return -ENOMEM;
+
+	return 0;
+}
+
 int ux500_msp_i2s_init_msp(struct platform_device *pdev,
 			struct ux500_msp **msp_p,
 			struct msp_i2s_platform_data *platform_data)
@@ -653,30 +681,28 @@ int ux500_msp_i2s_init_msp(struct platform_device *pdev,
 	struct resource *res = NULL;
 	struct device_node *np = pdev->dev.of_node;
 	struct ux500_msp *msp;
+	int ret;
 
 	*msp_p = devm_kzalloc(&pdev->dev, sizeof(struct ux500_msp), GFP_KERNEL);
 	msp = *msp_p;
 	if (!msp)
 		return -ENOMEM;
 
-	if (np) {
-		if (!platform_data) {
-			platform_data = devm_kzalloc(&pdev->dev,
-				sizeof(struct msp_i2s_platform_data), GFP_KERNEL);
-			if (!platform_data)
-				return -ENOMEM;
-		}
-	} else
-		if (!platform_data)
+	if (!platform_data) {
+		if (np) {
+			ret = ux500_msp_i2s_of_init_msp(pdev, msp,
+							&platform_data);
+			if (ret)
+				return ret;
+		} else
 			return -EINVAL;
+	} else {
+		msp->playback_dma_data.dma_cfg = platform_data->msp_i2s_dma_tx;
+		msp->capture_dma_data.dma_cfg = platform_data->msp_i2s_dma_rx;
+		msp->id = platform_data->id;
+	}
 
-	dev_dbg(&pdev->dev, "%s: Enter (name: %s, id: %d).\n", __func__,
-		pdev->name, platform_data->id);
-
-	msp->id = platform_data->id;
 	msp->dev = &pdev->dev;
-	msp->playback_dma_data.dma_cfg = platform_data->msp_i2s_dma_tx;
-	msp->capture_dma_data.dma_cfg = platform_data->msp_i2s_dma_rx;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (res == NULL) {
-- 
1.8.1.2

[PATCH 06/10] ASoC: ux500_pcm: Extend Device Tree support to deal with DMA data

[Lee Jones]

Soon we will strip out pdata support from the Ux500 set of ASoC drivers.
When this happens it will have to supply a DMA slave_config to the
dmaengine. At the moment a great deal of this comes from pdata via
AUXDATA. We need to become independent of this soon. This patch starts
the process by allocating memory for the associated data structures and
fetches the MSP id used for const struct indexing.

Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/ux500_msp_i2s.c | 56 ++++++++++++++++++++++++++++++-----------
 1 file changed, 41 insertions(+), 15 deletions(-)

diff --git a/sound/soc/ux500/ux500_msp_i2s.c b/sound/soc/ux500/ux500_msp_i2s.c
index 1ca8b08..7f2a4ac 100644
--- a/sound/soc/ux500/ux500_msp_i2s.c
+++ b/sound/soc/ux500/ux500_msp_i2s.c
@@ -646,6 +646,34 @@ int ux500_msp_i2s_close(struct ux500_msp *msp, unsigned int dir)
 
 }
 
+int ux500_msp_i2s_of_init_msp(struct platform_device *pdev,
+			      struct ux500_msp *msp,
+			      struct msp_i2s_platform_data **platform_data)
+{
+	struct msp_i2s_platform_data *pdata;
+
+	*platform_data = devm_kzalloc(&pdev->dev,
+				     sizeof(struct msp_i2s_platform_data),
+				     GFP_KERNEL);
+	pdata = *platform_data;
+	if (!pdata)
+		return -ENOMEM;
+
+	msp->playback_dma_data.dma_cfg = devm_kzalloc(&pdev->dev,
+					sizeof(struct stedma40_chan_cfg),
+					GFP_KERNEL);
+	if (!msp->playback_dma_data.dma_cfg)
+		return -ENOMEM;
+
+	msp->capture_dma_data.dma_cfg = devm_kzalloc(&pdev->dev,
+					sizeof(struct stedma40_chan_cfg),
+					GFP_KERNEL);
+	if (!msp->capture_dma_data.dma_cfg)
+		return -ENOMEM;
+
+	return 0;
+}
+
 int ux500_msp_i2s_init_msp(struct platform_device *pdev,
 			struct ux500_msp **msp_p,
 			struct msp_i2s_platform_data *platform_data)
@@ -653,30 +681,28 @@ int ux500_msp_i2s_init_msp(struct platform_device *pdev,
 	struct resource *res = NULL;
 	struct device_node *np = pdev->dev.of_node;
 	struct ux500_msp *msp;
+	int ret;
 
 	*msp_p = devm_kzalloc(&pdev->dev, sizeof(struct ux500_msp), GFP_KERNEL);
 	msp = *msp_p;
 	if (!msp)
 		return -ENOMEM;
 
-	if (np) {
-		if (!platform_data) {
-			platform_data = devm_kzalloc(&pdev->dev,
-				sizeof(struct msp_i2s_platform_data), GFP_KERNEL);
-			if (!platform_data)
-				return -ENOMEM;
-		}
-	} else
-		if (!platform_data)
+	if (!platform_data) {
+		if (np) {
+			ret = ux500_msp_i2s_of_init_msp(pdev, msp,
+							&platform_data);
+			if (ret)
+				return ret;
+		} else
 			return -EINVAL;
+	} else {
+		msp->playback_dma_data.dma_cfg = platform_data->msp_i2s_dma_tx;
+		msp->capture_dma_data.dma_cfg = platform_data->msp_i2s_dma_rx;
+		msp->id = platform_data->id;
+	}
 
-	dev_dbg(&pdev->dev, "%s: Enter (name: %s, id: %d).\n", __func__,
-		pdev->name, platform_data->id);
-
-	msp->id = platform_data->id;
 	msp->dev = &pdev->dev;
-	msp->playback_dma_data.dma_cfg = platform_data->msp_i2s_dma_tx;
-	msp->capture_dma_data.dma_cfg = platform_data->msp_i2s_dma_rx;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (res == NULL) {
-- 
1.8.1.2

[PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

In this patch we do two things. Firstly, instead of open coding the
store of DMA data in to the DAI for later use, we use the API provided.
Secondly we create and store similar DMA data for the DT case, only
this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
by the core for this very reason.

Cc: alsa-devel@alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/ux500_msp_dai.c | 42 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/sound/soc/ux500/ux500_msp_dai.c b/sound/soc/ux500/ux500_msp_dai.c
index c6fb5cc..8d1b01f 100644
--- a/sound/soc/ux500/ux500_msp_dai.c
+++ b/sound/soc/ux500/ux500_msp_dai.c
@@ -17,12 +17,14 @@
 #include <linux/bitops.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
+#include <linux/of.h>
 #include <linux/regulator/consumer.h>
 #include <linux/mfd/dbx500-prcmu.h>
 #include <linux/platform_data/asoc-ux500-msp.h>
 
 #include <sound/soc.h>
 #include <sound/soc-dai.h>
+#include <sound/dmaengine_pcm.h>
 
 #include "ux500_msp_i2s.h"
 #include "ux500_msp_dai.h"
@@ -654,16 +656,52 @@ static int ux500_msp_dai_trigger(struct snd_pcm_substream *substream,
 	return ret;
 }
 
+static int ux500_msp_dai_of_probe(struct snd_soc_dai *dai)
+{
+	struct ux500_msp_i2s_drvdata *drvdata = dev_get_drvdata(dai->dev);
+	struct snd_dmaengine_dai_dma_data *playback_dma_data;
+	struct snd_dmaengine_dai_dma_data *capture_dma_data;
+
+	playback_dma_data = devm_kzalloc(dai->dev,
+					 sizeof(*playback_dma_data),
+					 GFP_KERNEL);
+	if (!playback_dma_data)
+		return -ENOMEM;
+
+	capture_dma_data = devm_kzalloc(dai->dev,
+					sizeof(*capture_dma_data),
+					GFP_KERNEL);
+	if (!capture_dma_data)
+		return -ENOMEM;
+
+	playback_dma_data->addr = drvdata->msp->playback_dma_data.tx_rx_addr;
+	capture_dma_data->addr = drvdata->msp->capture_dma_data.tx_rx_addr;
+
+	playback_dma_data->maxburst = 4;
+	capture_dma_data->maxburst = 4;
+
+	snd_soc_dai_init_dma_data(dai, playback_dma_data, capture_dma_data);
+
+	return 0;
+}
+
 static int ux500_msp_dai_probe(struct snd_soc_dai *dai)
 {
 	struct ux500_msp_i2s_drvdata *drvdata = dev_get_drvdata(dai->dev);
+	struct device_node *np = dai->dev->of_node;
+	int ret;
 
-	dai->playback_dma_data = &drvdata->msp->playback_dma_data;
-	dai->capture_dma_data = &drvdata->msp->capture_dma_data;
+	if (np) {
+		ret = ux500_msp_dai_of_probe(dai);
+		return ret;
+	}
 
 	drvdata->msp->playback_dma_data.data_size = drvdata->slot_width;
 	drvdata->msp->capture_dma_data.data_size = drvdata->slot_width;
 
+	snd_soc_dai_init_dma_data(dai,
+				  &drvdata->msp->playback_dma_data,
+				  &drvdata->msp->capture_dma_data);
 	return 0;
 }
 
-- 
1.8.1.2

[PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

In this patch we do two things. Firstly, instead of open coding the
store of DMA data in to the DAI for later use, we use the API provided.
Secondly we create and store similar DMA data for the DT case, only
this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
by the core for this very reason.

Cc: alsa-devel@alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/ux500_msp_dai.c | 42 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/sound/soc/ux500/ux500_msp_dai.c b/sound/soc/ux500/ux500_msp_dai.c
index c6fb5cc..8d1b01f 100644
--- a/sound/soc/ux500/ux500_msp_dai.c
+++ b/sound/soc/ux500/ux500_msp_dai.c
@@ -17,12 +17,14 @@
 #include <linux/bitops.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
+#include <linux/of.h>
 #include <linux/regulator/consumer.h>
 #include <linux/mfd/dbx500-prcmu.h>
 #include <linux/platform_data/asoc-ux500-msp.h>
 
 #include <sound/soc.h>
 #include <sound/soc-dai.h>
+#include <sound/dmaengine_pcm.h>
 
 #include "ux500_msp_i2s.h"
 #include "ux500_msp_dai.h"
@@ -654,16 +656,52 @@ static int ux500_msp_dai_trigger(struct snd_pcm_substream *substream,
 	return ret;
 }
 
+static int ux500_msp_dai_of_probe(struct snd_soc_dai *dai)
+{
+	struct ux500_msp_i2s_drvdata *drvdata = dev_get_drvdata(dai->dev);
+	struct snd_dmaengine_dai_dma_data *playback_dma_data;
+	struct snd_dmaengine_dai_dma_data *capture_dma_data;
+
+	playback_dma_data = devm_kzalloc(dai->dev,
+					 sizeof(*playback_dma_data),
+					 GFP_KERNEL);
+	if (!playback_dma_data)
+		return -ENOMEM;
+
+	capture_dma_data = devm_kzalloc(dai->dev,
+					sizeof(*capture_dma_data),
+					GFP_KERNEL);
+	if (!capture_dma_data)
+		return -ENOMEM;
+
+	playback_dma_data->addr = drvdata->msp->playback_dma_data.tx_rx_addr;
+	capture_dma_data->addr = drvdata->msp->capture_dma_data.tx_rx_addr;
+
+	playback_dma_data->maxburst = 4;
+	capture_dma_data->maxburst = 4;
+
+	snd_soc_dai_init_dma_data(dai, playback_dma_data, capture_dma_data);
+
+	return 0;
+}
+
 static int ux500_msp_dai_probe(struct snd_soc_dai *dai)
 {
 	struct ux500_msp_i2s_drvdata *drvdata = dev_get_drvdata(dai->dev);
+	struct device_node *np = dai->dev->of_node;
+	int ret;
 
-	dai->playback_dma_data = &drvdata->msp->playback_dma_data;
-	dai->capture_dma_data = &drvdata->msp->capture_dma_data;
+	if (np) {
+		ret = ux500_msp_dai_of_probe(dai);
+		return ret;
+	}
 
 	drvdata->msp->playback_dma_data.data_size = drvdata->slot_width;
 	drvdata->msp->capture_dma_data.data_size = drvdata->slot_width;
 
+	snd_soc_dai_init_dma_data(dai,
+				  &drvdata->msp->playback_dma_data,
+				  &drvdata->msp->capture_dma_data);
 	return 0;
 }
 
-- 
1.8.1.2

[PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

In this patch we do two things. Firstly, instead of open coding the
store of DMA data in to the DAI for later use, we use the API provided.
Secondly we create and store similar DMA data for the DT case, only
this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
by the core for this very reason.

Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/ux500_msp_dai.c | 42 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/sound/soc/ux500/ux500_msp_dai.c b/sound/soc/ux500/ux500_msp_dai.c
index c6fb5cc..8d1b01f 100644
--- a/sound/soc/ux500/ux500_msp_dai.c
+++ b/sound/soc/ux500/ux500_msp_dai.c
@@ -17,12 +17,14 @@
 #include <linux/bitops.h>
 #include <linux/platform_device.h>
 #include <linux/clk.h>
+#include <linux/of.h>
 #include <linux/regulator/consumer.h>
 #include <linux/mfd/dbx500-prcmu.h>
 #include <linux/platform_data/asoc-ux500-msp.h>
 
 #include <sound/soc.h>
 #include <sound/soc-dai.h>
+#include <sound/dmaengine_pcm.h>
 
 #include "ux500_msp_i2s.h"
 #include "ux500_msp_dai.h"
@@ -654,16 +656,52 @@ static int ux500_msp_dai_trigger(struct snd_pcm_substream *substream,
 	return ret;
 }
 
+static int ux500_msp_dai_of_probe(struct snd_soc_dai *dai)
+{
+	struct ux500_msp_i2s_drvdata *drvdata = dev_get_drvdata(dai->dev);
+	struct snd_dmaengine_dai_dma_data *playback_dma_data;
+	struct snd_dmaengine_dai_dma_data *capture_dma_data;
+
+	playback_dma_data = devm_kzalloc(dai->dev,
+					 sizeof(*playback_dma_data),
+					 GFP_KERNEL);
+	if (!playback_dma_data)
+		return -ENOMEM;
+
+	capture_dma_data = devm_kzalloc(dai->dev,
+					sizeof(*capture_dma_data),
+					GFP_KERNEL);
+	if (!capture_dma_data)
+		return -ENOMEM;
+
+	playback_dma_data->addr = drvdata->msp->playback_dma_data.tx_rx_addr;
+	capture_dma_data->addr = drvdata->msp->capture_dma_data.tx_rx_addr;
+
+	playback_dma_data->maxburst = 4;
+	capture_dma_data->maxburst = 4;
+
+	snd_soc_dai_init_dma_data(dai, playback_dma_data, capture_dma_data);
+
+	return 0;
+}
+
 static int ux500_msp_dai_probe(struct snd_soc_dai *dai)
 {
 	struct ux500_msp_i2s_drvdata *drvdata = dev_get_drvdata(dai->dev);
+	struct device_node *np = dai->dev->of_node;
+	int ret;
 
-	dai->playback_dma_data = &drvdata->msp->playback_dma_data;
-	dai->capture_dma_data = &drvdata->msp->capture_dma_data;
+	if (np) {
+		ret = ux500_msp_dai_of_probe(dai);
+		return ret;
+	}
 
 	drvdata->msp->playback_dma_data.data_size = drvdata->slot_width;
 	drvdata->msp->capture_dma_data.data_size = drvdata->slot_width;
 
+	snd_soc_dai_init_dma_data(dai,
+				  &drvdata->msp->playback_dma_data,
+				  &drvdata->msp->capture_dma_data);
 	return 0;
 }
 
-- 
1.8.1.2

[PATCH 08/10] ASoC: ux500_pcm: Differentiate between pdata and DT initialisation

[Lee Jones]

If booting with full DT support (i.e. DMA too, the last piece of the
puzzle), then we don't need to use the compatible request channel call
back and, due to the work we laid down earlier in this patch-set, we
can use core function calls to populate the DMA slave_config. We also
require slightly different flags to inform the core that we 'are'
booting with DT.

Cc: alsa-devel@alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/ux500_pcm.c | 28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/sound/soc/ux500/ux500_pcm.c b/sound/soc/ux500/ux500_pcm.c
index ce554de..acfec98 100644
--- a/sound/soc/ux500/ux500_pcm.c
+++ b/sound/soc/ux500/ux500_pcm.c
@@ -139,15 +139,33 @@ static const struct snd_dmaengine_pcm_config ux500_dmaengine_pcm_config = {
 	.prepare_slave_config = ux500_pcm_prepare_slave_config,
 };
 
+static const struct snd_dmaengine_pcm_config ux500_dmaengine_of_pcm_config = {
+	.pcm_hardware = &ux500_pcm_hw,
+	.prealloc_buffer_size = 128 * 1024,
+	.prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
+};
+
 int ux500_pcm_register_platform(struct platform_device *pdev)
 {
+	const struct snd_dmaengine_pcm_config *pcm_config;
+	struct device_node *np = pdev->dev.of_node;
+	unsigned int pcm_flags;
 	int ret;
 
-	ret = snd_dmaengine_pcm_register(&pdev->dev,
-			&ux500_dmaengine_pcm_config,
-			SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
-			SND_DMAENGINE_PCM_FLAG_COMPAT |
-			SND_DMAENGINE_PCM_FLAG_NO_DT);
+	if (np) {
+		pcm_config = &ux500_dmaengine_of_pcm_config;
+
+		pcm_flags = SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+			SND_DMAENGINE_PCM_FLAG_COMPAT;
+	} else {
+		pcm_config = &ux500_dmaengine_pcm_config;
+
+		pcm_flags = SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+			SND_DMAENGINE_PCM_FLAG_NO_DT |
+			SND_DMAENGINE_PCM_FLAG_COMPAT;
+	}
+
+	ret = snd_dmaengine_pcm_register(&pdev->dev, pcm_config, pcm_flags);
 	if (ret < 0) {
 		dev_err(&pdev->dev,
 			"%s: ERROR: Failed to register platform '%s' (%d)!\n",
-- 
1.8.1.2

[PATCH 08/10] ASoC: ux500_pcm: Differentiate between pdata and DT initialisation

[Lee Jones]

If booting with full DT support (i.e. DMA too, the last piece of the
puzzle), then we don't need to use the compatible request channel call
back and, due to the work we laid down earlier in this patch-set, we
can use core function calls to populate the DMA slave_config. We also
require slightly different flags to inform the core that we 'are'
booting with DT.

Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/ux500_pcm.c | 28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/sound/soc/ux500/ux500_pcm.c b/sound/soc/ux500/ux500_pcm.c
index ce554de..acfec98 100644
--- a/sound/soc/ux500/ux500_pcm.c
+++ b/sound/soc/ux500/ux500_pcm.c
@@ -139,15 +139,33 @@ static const struct snd_dmaengine_pcm_config ux500_dmaengine_pcm_config = {
 	.prepare_slave_config = ux500_pcm_prepare_slave_config,
 };
 
+static const struct snd_dmaengine_pcm_config ux500_dmaengine_of_pcm_config = {
+	.pcm_hardware = &ux500_pcm_hw,
+	.prealloc_buffer_size = 128 * 1024,
+	.prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
+};
+
 int ux500_pcm_register_platform(struct platform_device *pdev)
 {
+	const struct snd_dmaengine_pcm_config *pcm_config;
+	struct device_node *np = pdev->dev.of_node;
+	unsigned int pcm_flags;
 	int ret;
 
-	ret = snd_dmaengine_pcm_register(&pdev->dev,
-			&ux500_dmaengine_pcm_config,
-			SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
-			SND_DMAENGINE_PCM_FLAG_COMPAT |
-			SND_DMAENGINE_PCM_FLAG_NO_DT);
+	if (np) {
+		pcm_config = &ux500_dmaengine_of_pcm_config;
+
+		pcm_flags = SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+			SND_DMAENGINE_PCM_FLAG_COMPAT;
+	} else {
+		pcm_config = &ux500_dmaengine_pcm_config;
+
+		pcm_flags = SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+			SND_DMAENGINE_PCM_FLAG_NO_DT |
+			SND_DMAENGINE_PCM_FLAG_COMPAT;
+	}
+
+	ret = snd_dmaengine_pcm_register(&pdev->dev, pcm_config, pcm_flags);
 	if (ret < 0) {
 		dev_err(&pdev->dev,
 			"%s: ERROR: Failed to register platform '%s' (%d)!\n",
-- 
1.8.1.2

[PATCH 09/10] ASoC: ux500_pcm: Take out pointless dev_dbg() call

[Lee Jones]

Cc: alsa-devel@alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/ux500_pcm.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/sound/soc/ux500/ux500_pcm.c b/sound/soc/ux500/ux500_pcm.c
index acfec98..fd7f12e 100644
--- a/sound/soc/ux500/ux500_pcm.c
+++ b/sound/soc/ux500/ux500_pcm.c
@@ -65,14 +65,10 @@ static struct dma_chan *ux500_pcm_request_chan(struct snd_soc_pcm_runtime *rtd,
 	struct snd_pcm_substream *substream)
 {
 	struct snd_soc_dai *dai = rtd->cpu_dai;
-	struct device *dev = dai->dev;
 	u16 per_data_width, mem_data_width;
 	struct stedma40_chan_cfg *dma_cfg;
 	struct ux500_msp_dma_params *dma_params;
 
-	dev_dbg(dev, "%s: MSP %d (%s): Enter.\n", __func__, dai->id,
-		snd_pcm_stream_str(substream));
-
 	dma_params = snd_soc_dai_get_dma_data(dai, substream);
 	dma_cfg = dma_params->dma_cfg;
 
-- 
1.8.1.2

[PATCH 09/10] ASoC: ux500_pcm: Take out pointless dev_dbg() call

[Lee Jones]

Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/ux500_pcm.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/sound/soc/ux500/ux500_pcm.c b/sound/soc/ux500/ux500_pcm.c
index acfec98..fd7f12e 100644
--- a/sound/soc/ux500/ux500_pcm.c
+++ b/sound/soc/ux500/ux500_pcm.c
@@ -65,14 +65,10 @@ static struct dma_chan *ux500_pcm_request_chan(struct snd_soc_pcm_runtime *rtd,
 	struct snd_pcm_substream *substream)
 {
 	struct snd_soc_dai *dai = rtd->cpu_dai;
-	struct device *dev = dai->dev;
 	u16 per_data_width, mem_data_width;
 	struct stedma40_chan_cfg *dma_cfg;
 	struct ux500_msp_dma_params *dma_params;
 
-	dev_dbg(dev, "%s: MSP %d (%s): Enter.\n", __func__, dai->id,
-		snd_pcm_stream_str(substream));
-
 	dma_params = snd_soc_dai_get_dma_data(dai, substream);
 	dma_cfg = dma_params->dma_cfg;
 
-- 
1.8.1.2

[PATCH 10/10] ASoC: ux500: Dynamically fill DAI driver data on probe

[Lee Jones]

We no longer have a means to differentiate MSP devices at probe time,
mainline because we don't really have to. So rather than have an over-
sized static data structure in place, where the only difference between
devices is the ID and name (which are unused), we'll create them only
when required and omit the unnecessary information.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/ux500_msp_dai.c | 108 ++++++++++------------------------------
 1 file changed, 26 insertions(+), 82 deletions(-)

diff --git a/sound/soc/ux500/ux500_msp_dai.c b/sound/soc/ux500/ux500_msp_dai.c
index 8d1b01f..153fb3f 100644
--- a/sound/soc/ux500/ux500_msp_dai.c
+++ b/sound/soc/ux500/ux500_msp_dai.c
@@ -718,87 +718,20 @@ static struct snd_soc_dai_ops ux500_msp_dai_ops[] = {
 	}
 };
 
-static struct snd_soc_dai_driver ux500_msp_dai_drv[UX500_NBR_OF_DAI] = {
-	{
-		.name = "ux500-msp-i2s.0",
-		.probe = ux500_msp_dai_probe,
-		.id = 0,
-		.suspend = NULL,
-		.resume = NULL,
-		.playback = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.capture = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.ops = ux500_msp_dai_ops,
-	},
-	{
-		.name = "ux500-msp-i2s.1",
-		.probe = ux500_msp_dai_probe,
-		.id = 1,
-		.suspend = NULL,
-		.resume = NULL,
-		.playback = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.capture = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.ops = ux500_msp_dai_ops,
-	},
-	{
-		.name = "ux500-msp-i2s.2",
-		.id = 2,
-		.probe = ux500_msp_dai_probe,
-		.suspend = NULL,
-		.resume = NULL,
-		.playback = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.capture = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.ops = ux500_msp_dai_ops,
-	},
-	{
-		.name = "ux500-msp-i2s.3",
-		.probe = ux500_msp_dai_probe,
-		.id = 3,
-		.suspend = NULL,
-		.resume = NULL,
-		.playback = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.capture = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.ops = ux500_msp_dai_ops,
-	},
+void ux500_msp_populate_dai_drv(struct snd_soc_dai_driver *ux500_msp_dai_drv)
+{
+	ux500_msp_dai_drv->probe                 = ux500_msp_dai_probe;
+	ux500_msp_dai_drv->suspend               = NULL;
+	ux500_msp_dai_drv->resume                = NULL;
+	ux500_msp_dai_drv->playback.channels_min = UX500_MSP_MIN_CHANNELS;
+	ux500_msp_dai_drv->playback.channels_max = UX500_MSP_MAX_CHANNELS;
+	ux500_msp_dai_drv->playback.rates        = UX500_I2S_RATES;
+	ux500_msp_dai_drv->playback.formats      = UX500_I2S_FORMATS;
+	ux500_msp_dai_drv->capture.channels_min  = UX500_MSP_MIN_CHANNELS;
+	ux500_msp_dai_drv->capture.channels_max  = UX500_MSP_MAX_CHANNELS;
+	ux500_msp_dai_drv->capture.rates         = UX500_I2S_RATES;
+	ux500_msp_dai_drv->capture.formats       = UX500_I2S_FORMATS;
+	ux500_msp_dai_drv->ops                   = ux500_msp_dai_ops;
 };
 
 static const struct snd_soc_component_driver ux500_msp_component = {
@@ -809,6 +742,7 @@ static const struct snd_soc_component_driver ux500_msp_component = {
 static int ux500_msp_drv_probe(struct platform_device *pdev)
 {
 	struct ux500_msp_i2s_drvdata *drvdata;
+	struct snd_soc_dai_driver *ux500_msp_dai_drv;
 	int ret = 0;
 
 	dev_dbg(&pdev->dev, "%s: Enter (pdev->name = %s).\n", __func__,
@@ -863,8 +797,18 @@ static int ux500_msp_drv_probe(struct platform_device *pdev)
 	}
 	dev_set_drvdata(&pdev->dev, drvdata);
 
+	ux500_msp_dai_drv = devm_kzalloc(&pdev->dev,
+					 sizeof(*ux500_msp_dai_drv),
+					 GFP_KERNEL);
+	if (!ux500_msp_dai_drv) {
+		ret = -ENOMEM;
+		goto err_init_msp;
+	}
+
+	ux500_msp_populate_dai_drv(ux500_msp_dai_drv);
+
 	ret = snd_soc_register_component(&pdev->dev, &ux500_msp_component,
-					 &ux500_msp_dai_drv[drvdata->msp->id], 1);
+					 ux500_msp_dai_drv, 1);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Error: %s: Failed to register MSP%d!\n",
 			__func__, drvdata->msp->id);
-- 
1.8.1.2

[PATCH 10/10] ASoC: ux500: Dynamically fill DAI driver data on probe

[Lee Jones]

We no longer have a means to differentiate MSP devices at probe time,
mainline because we don't really have to. So rather than have an over-
sized static data structure in place, where the only difference between
devices is the ID and name (which are unused), we'll create them only
when required and omit the unnecessary information.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 sound/soc/ux500/ux500_msp_dai.c | 108 ++++++++++------------------------------
 1 file changed, 26 insertions(+), 82 deletions(-)

diff --git a/sound/soc/ux500/ux500_msp_dai.c b/sound/soc/ux500/ux500_msp_dai.c
index 8d1b01f..153fb3f 100644
--- a/sound/soc/ux500/ux500_msp_dai.c
+++ b/sound/soc/ux500/ux500_msp_dai.c
@@ -718,87 +718,20 @@ static struct snd_soc_dai_ops ux500_msp_dai_ops[] = {
 	}
 };
 
-static struct snd_soc_dai_driver ux500_msp_dai_drv[UX500_NBR_OF_DAI] = {
-	{
-		.name = "ux500-msp-i2s.0",
-		.probe = ux500_msp_dai_probe,
-		.id = 0,
-		.suspend = NULL,
-		.resume = NULL,
-		.playback = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.capture = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.ops = ux500_msp_dai_ops,
-	},
-	{
-		.name = "ux500-msp-i2s.1",
-		.probe = ux500_msp_dai_probe,
-		.id = 1,
-		.suspend = NULL,
-		.resume = NULL,
-		.playback = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.capture = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.ops = ux500_msp_dai_ops,
-	},
-	{
-		.name = "ux500-msp-i2s.2",
-		.id = 2,
-		.probe = ux500_msp_dai_probe,
-		.suspend = NULL,
-		.resume = NULL,
-		.playback = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.capture = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.ops = ux500_msp_dai_ops,
-	},
-	{
-		.name = "ux500-msp-i2s.3",
-		.probe = ux500_msp_dai_probe,
-		.id = 3,
-		.suspend = NULL,
-		.resume = NULL,
-		.playback = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.capture = {
-			.channels_min = UX500_MSP_MIN_CHANNELS,
-			.channels_max = UX500_MSP_MAX_CHANNELS,
-			.rates = UX500_I2S_RATES,
-			.formats = UX500_I2S_FORMATS,
-		},
-		.ops = ux500_msp_dai_ops,
-	},
+void ux500_msp_populate_dai_drv(struct snd_soc_dai_driver *ux500_msp_dai_drv)
+{
+	ux500_msp_dai_drv->probe                 = ux500_msp_dai_probe;
+	ux500_msp_dai_drv->suspend               = NULL;
+	ux500_msp_dai_drv->resume                = NULL;
+	ux500_msp_dai_drv->playback.channels_min = UX500_MSP_MIN_CHANNELS;
+	ux500_msp_dai_drv->playback.channels_max = UX500_MSP_MAX_CHANNELS;
+	ux500_msp_dai_drv->playback.rates        = UX500_I2S_RATES;
+	ux500_msp_dai_drv->playback.formats      = UX500_I2S_FORMATS;
+	ux500_msp_dai_drv->capture.channels_min  = UX500_MSP_MIN_CHANNELS;
+	ux500_msp_dai_drv->capture.channels_max  = UX500_MSP_MAX_CHANNELS;
+	ux500_msp_dai_drv->capture.rates         = UX500_I2S_RATES;
+	ux500_msp_dai_drv->capture.formats       = UX500_I2S_FORMATS;
+	ux500_msp_dai_drv->ops                   = ux500_msp_dai_ops;
 };
 
 static const struct snd_soc_component_driver ux500_msp_component = {
@@ -809,6 +742,7 @@ static const struct snd_soc_component_driver ux500_msp_component = {
 static int ux500_msp_drv_probe(struct platform_device *pdev)
 {
 	struct ux500_msp_i2s_drvdata *drvdata;
+	struct snd_soc_dai_driver *ux500_msp_dai_drv;
 	int ret = 0;
 
 	dev_dbg(&pdev->dev, "%s: Enter (pdev->name = %s).\n", __func__,
@@ -863,8 +797,18 @@ static int ux500_msp_drv_probe(struct platform_device *pdev)
 	}
 	dev_set_drvdata(&pdev->dev, drvdata);
 
+	ux500_msp_dai_drv = devm_kzalloc(&pdev->dev,
+					 sizeof(*ux500_msp_dai_drv),
+					 GFP_KERNEL);
+	if (!ux500_msp_dai_drv) {
+		ret = -ENOMEM;
+		goto err_init_msp;
+	}
+
+	ux500_msp_populate_dai_drv(ux500_msp_dai_drv);
+
 	ret = snd_soc_register_component(&pdev->dev, &ux500_msp_component,
-					 &ux500_msp_dai_drv[drvdata->msp->id], 1);
+					 ux500_msp_dai_drv, 1);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Error: %s: Failed to register MSP%d!\n",
 			__func__, drvdata->msp->id);
-- 
1.8.1.2

Re: [PATCH 08/10] ASoC: ux500_pcm: Differentiate between pdata and DT initialisation

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

On Tue, Nov 19, 2013 at 11:07:47AM +0000, Lee Jones wrote:

> require slightly different flags to inform the core that we 'are'
> booting with DT.

Is there some situation when we would want to say we're booting from DT
when we aren't?  Just wondering about the quotes.

> +static const struct snd_dmaengine_pcm_config ux500_dmaengine_of_pcm_config = {
> +	.pcm_hardware = &ux500_pcm_hw,
> +	.prealloc_buffer_size = 128 * 1024,

You shouldn't need to set this explicitly, the generic code should be
able to pick a number for you - if you do need this number please
explain why the number was chosen in the comments (or fix the core to
guess better).  At the minute the core just makes up a number too but at
least then it's a consistent random number between platforms.

Can you also get away without the pcm_hardware - the core should also
have support for discovering this by querying the DMA controller?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 08/10] ASoC: ux500_pcm: Differentiate between pdata and DT initialisation

[Mark Brown]

On Tue, Nov 19, 2013 at 11:07:47AM +0000, Lee Jones wrote:

> require slightly different flags to inform the core that we 'are'
> booting with DT.

Is there some situation when we would want to say we're booting from DT
when we aren't?  Just wondering about the quotes.

> +static const struct snd_dmaengine_pcm_config ux500_dmaengine_of_pcm_config = {
> +	.pcm_hardware = &ux500_pcm_hw,
> +	.prealloc_buffer_size = 128 * 1024,

You shouldn't need to set this explicitly, the generic code should be
able to pick a number for you - if you do need this number please
explain why the number was chosen in the comments (or fix the core to
guess better).  At the minute the core just makes up a number too but at
least then it's a consistent random number between platforms.

Can you also get away without the pcm_hardware - the core should also
have support for discovering this by querying the DMA controller?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131119/18068609/attachment.sig>

Re: [PATCH 05/10] ASoC: Ux500: Match platform by device node when booting Device Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

On Tue, Nov 19, 2013 at 11:07:44AM +0000, Lee Jones wrote:
> We're getting closer to fully enabling the Ux500 ASoC driver for Device
> Tree. When we switch over from using AUXDATA we'll need to match platform
> by only Device Tree nodes. In this patch we NULL out the platform_name,
> and supply nodes for each platform device.

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 05/10] ASoC: Ux500: Match platform by device node when booting Device Tree

[Mark Brown]

On Tue, Nov 19, 2013 at 11:07:44AM +0000, Lee Jones wrote:
> We're getting closer to fully enabling the Ux500 ASoC driver for Device
> Tree. When we switch over from using AUXDATA we'll need to match platform
> by only Device Tree nodes. In this patch we NULL out the platform_name,
> and supply nodes for each platform device.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131119/46fd088a/attachment.sig>

Re: [PATCH 06/10] ASoC: ux500_pcm: Extend Device Tree support to deal with DMA data

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On Tue, Nov 19, 2013 at 11:07:45AM +0000, Lee Jones wrote:
> Soon we will strip out pdata support from the Ux500 set of ASoC drivers.
> When this happens it will have to supply a DMA slave_config to the
> dmaengine. At the moment a great deal of this comes from pdata via
> AUXDATA. We need to become independent of this soon. This patch starts
> the process by allocating memory for the associated data structures and
> fetches the MSP id used for const struct indexing.

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 06/10] ASoC: ux500_pcm: Extend Device Tree support to deal with DMA data

[Mark Brown]

On Tue, Nov 19, 2013 at 11:07:45AM +0000, Lee Jones wrote:
> Soon we will strip out pdata support from the Ux500 set of ASoC drivers.
> When this happens it will have to supply a DMA slave_config to the
> dmaengine. At the moment a great deal of this comes from pdata via
> AUXDATA. We need to become independent of this soon. This patch starts
> the process by allocating memory for the associated data structures and
> fetches the MSP id used for const struct indexing.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131119/8bc9423d/attachment.sig>

Re: [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On Tue, Nov 19, 2013 at 11:07:46AM +0000, Lee Jones wrote:
> In this patch we do two things. Firstly, instead of open coding the
> store of DMA data in to the DAI for later use, we use the API provided.
> Secondly we create and store similar DMA data for the DT case, only
> this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
> by the core for this very reason.

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Mark Brown]

On Tue, Nov 19, 2013 at 11:07:46AM +0000, Lee Jones wrote:
> In this patch we do two things. Firstly, instead of open coding the
> store of DMA data in to the DAI for later use, we use the API provided.
> Secondly we create and store similar DMA data for the DT case, only
> this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
> by the core for this very reason.

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131119/9c20a3eb/attachment-0001.sig>

Re: [PATCH 09/10] ASoC: ux500_pcm: Take out pointless dev_dbg() call

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

On Tue, Nov 19, 2013 at 11:07:48AM +0000, Lee Jones wrote:
> Cc: alsa-devel@alsa-project.org
> Cc: Mark Brown <broonie@kernel.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

Applied, thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 09/10] ASoC: ux500_pcm: Take out pointless dev_dbg() call

[Mark Brown]

On Tue, Nov 19, 2013 at 11:07:48AM +0000, Lee Jones wrote:
> Cc: alsa-devel at alsa-project.org
> Cc: Mark Brown <broonie@kernel.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131119/543b9213/attachment.sig>

Re: [PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

On Tue, Nov 19, 2013 at 11:07:39AM +0000, Lee Jones wrote:

> If this patch-set could go through ASoC as a whole, it would drive down
> the chance of a dependency mess. Vinod has already provided Acks for his
> parts, so it's just between you two Linus and Mark.

I applied the refactoring patches since they didn't seem to depend on
the DMA patches - they're on topic/ux500 in ASoC but I can easily drop
them or they can be merged elsewhere if required (I'll rebase once the
merge window closes anyway).  Let me know and I can provide a tag.

I'm happy to merge the first few patches if that's easiest for everyone
else, let me know and send them to me if that's what works for people.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Mark Brown]

On Tue, Nov 19, 2013 at 11:07:39AM +0000, Lee Jones wrote:

> If this patch-set could go through ASoC as a whole, it would drive down
> the chance of a dependency mess. Vinod has already provided Acks for his
> parts, so it's just between you two Linus and Mark.

I applied the refactoring patches since they didn't seem to depend on
the DMA patches - they're on topic/ux500 in ASoC but I can easily drop
them or they can be merged elsewhere if required (I'll rebase once the
merge window closes anyway).  Let me know and I can provide a tag.

I'm happy to merge the first few patches if that's easiest for everyone
else, let me know and send them to me if that's what works for people.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131119/5c472124/attachment.sig>

Re: [PATCH 08/10] ASoC: ux500_pcm: Differentiate between pdata and DT initialisation

[Lee Jones]

On Tue, 19 Nov 2013, Mark Brown wrote:

> On Tue, Nov 19, 2013 at 11:07:47AM +0000, Lee Jones wrote:
> 
> > require slightly different flags to inform the core that we 'are'
> > booting with DT.
> 
> Is there some situation when we would want to say we're booting from DT
> when we aren't?  Just wondering about the quotes.

The quotes do 'not' mean anything special. :)

> > +static const struct snd_dmaengine_pcm_config ux500_dmaengine_of_pcm_config = {
> > +	.pcm_hardware = &ux500_pcm_hw,
> > +	.prealloc_buffer_size = 128 * 1024,
> 
> You shouldn't need to set this explicitly, the generic code should be
> able to pick a number for you - if you do need this number please
> explain why the number was chosen in the comments (or fix the core to
> guess better).  At the minute the core just makes up a number too but at
> least then it's a consistent random number between platforms.
> 
> Can you also get away without the pcm_hardware - the core should also
> have support for discovering this by querying the DMA controller?

Despite the '+'s, I'm not actually adding these parameters, I'm
duplicating the pdata version and removing the stuff I 'know' that's
not required. I don't know what happens when/if these two parameters
are removed. I can add this to my TODO when I rip out platform data
support, which will happen when this stuff lands.

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

[PATCH 08/10] ASoC: ux500_pcm: Differentiate between pdata and DT initialisation

[Lee Jones]

On Tue, 19 Nov 2013, Mark Brown wrote:

> On Tue, Nov 19, 2013 at 11:07:47AM +0000, Lee Jones wrote:
> 
> > require slightly different flags to inform the core that we 'are'
> > booting with DT.
> 
> Is there some situation when we would want to say we're booting from DT
> when we aren't?  Just wondering about the quotes.

The quotes do 'not' mean anything special. :)

> > +static const struct snd_dmaengine_pcm_config ux500_dmaengine_of_pcm_config = {
> > +	.pcm_hardware = &ux500_pcm_hw,
> > +	.prealloc_buffer_size = 128 * 1024,
> 
> You shouldn't need to set this explicitly, the generic code should be
> able to pick a number for you - if you do need this number please
> explain why the number was chosen in the comments (or fix the core to
> guess better).  At the minute the core just makes up a number too but at
> least then it's a consistent random number between platforms.
> 
> Can you also get away without the pcm_hardware - the core should also
> have support for discovering this by querying the DMA controller?

Despite the '+'s, I'm not actually adding these parameters, I'm
duplicating the pdata version and removing the stuff I 'know' that's
not required. I don't know what happens when/if these two parameters
are removed. I can add this to my TODO when I rip out platform data
support, which will happen when this stuff lands.

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

Re: [PATCH 08/10] ASoC: ux500_pcm: Differentiate between pdata and DT initialisation

[Lars-Peter Clausen]

On 11/19/2013 08:33 PM, Lee Jones wrote:
> On Tue, 19 Nov 2013, Mark Brown wrote:
> 
>> On Tue, Nov 19, 2013 at 11:07:47AM +0000, Lee Jones wrote:
>>
>>> require slightly different flags to inform the core that we 'are'
>>> booting with DT.
>>
>> Is there some situation when we would want to say we're booting from DT
>> when we aren't?  Just wondering about the quotes.
> 
> The quotes do 'not' mean anything special. :)
> 
>>> +static const struct snd_dmaengine_pcm_config ux500_dmaengine_of_pcm_config = {
>>> +	.pcm_hardware = &ux500_pcm_hw,
>>> +	.prealloc_buffer_size = 128 * 1024,
>>
>> You shouldn't need to set this explicitly, the generic code should be
>> able to pick a number for you - if you do need this number please
>> explain why the number was chosen in the comments (or fix the core to
>> guess better).  At the minute the core just makes up a number too but at
>> least then it's a consistent random number between platforms.
>>
>> Can you also get away without the pcm_hardware - the core should also
>> have support for discovering this by querying the DMA controller?
> 
> Despite the '+'s, I'm not actually adding these parameters, I'm
> duplicating the pdata version and removing the stuff I 'know' that's
> not required. I don't know what happens when/if these two parameters
> are removed. I can add this to my TODO when I rip out platform data
> support, which will happen when this stuff lands.
> 

I think the patch is fine for now. Once non-DT support has been removed for
ux500 we should be able to remove the whole ux500_pcm.c file (Assuming that
the ux500 DMA engine driver gains dma_slave_caps support).

- Lars

[PATCH 08/10] ASoC: ux500_pcm: Differentiate between pdata and DT initialisation

[Lars-Peter Clausen]

On 11/19/2013 08:33 PM, Lee Jones wrote:
> On Tue, 19 Nov 2013, Mark Brown wrote:
> 
>> On Tue, Nov 19, 2013 at 11:07:47AM +0000, Lee Jones wrote:
>>
>>> require slightly different flags to inform the core that we 'are'
>>> booting with DT.
>>
>> Is there some situation when we would want to say we're booting from DT
>> when we aren't?  Just wondering about the quotes.
> 
> The quotes do 'not' mean anything special. :)
> 
>>> +static const struct snd_dmaengine_pcm_config ux500_dmaengine_of_pcm_config = {
>>> +	.pcm_hardware = &ux500_pcm_hw,
>>> +	.prealloc_buffer_size = 128 * 1024,
>>
>> You shouldn't need to set this explicitly, the generic code should be
>> able to pick a number for you - if you do need this number please
>> explain why the number was chosen in the comments (or fix the core to
>> guess better).  At the minute the core just makes up a number too but at
>> least then it's a consistent random number between platforms.
>>
>> Can you also get away without the pcm_hardware - the core should also
>> have support for discovering this by querying the DMA controller?
> 
> Despite the '+'s, I'm not actually adding these parameters, I'm
> duplicating the pdata version and removing the stuff I 'know' that's
> not required. I don't know what happens when/if these two parameters
> are removed. I can add this to my TODO when I rip out platform data
> support, which will happen when this stuff lands.
> 

I think the patch is fine for now. Once non-DT support has been removed for
ux500 we should be able to remove the whole ux500_pcm.c file (Assuming that
the ux500 DMA engine driver gains dma_slave_caps support).

- Lars

Re: [PATCH 08/10] ASoC: ux500_pcm: Differentiate between pdata and DT initialisation

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

On Tue, Nov 19, 2013 at 08:40:00PM +0100, Lars-Peter Clausen wrote:
> On 11/19/2013 08:33 PM, Lee Jones wrote:

> > Despite the '+'s, I'm not actually adding these parameters, I'm
> > duplicating the pdata version and removing the stuff I 'know' that's
> > not required. I don't know what happens when/if these two parameters
> > are removed. I can add this to my TODO when I rip out platform data
> > support, which will happen when this stuff lands.

> I think the patch is fine for now. Once non-DT support has been removed for
> ux500 we should be able to remove the whole ux500_pcm.c file (Assuming that
> the ux500 DMA engine driver gains dma_slave_caps support).

Yeah, it shouldn't break anything but I'd rather at least have a comment
on any new code that specifies these things by hand explaining why the
automatic stuff doesn't work, it's much nicer to not have to specify the
magic numbers by hand and this will help encourage new code to do the
right thing.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 08/10] ASoC: ux500_pcm: Differentiate between pdata and DT initialisation

[Mark Brown]

On Tue, Nov 19, 2013 at 08:40:00PM +0100, Lars-Peter Clausen wrote:
> On 11/19/2013 08:33 PM, Lee Jones wrote:

> > Despite the '+'s, I'm not actually adding these parameters, I'm
> > duplicating the pdata version and removing the stuff I 'know' that's
> > not required. I don't know what happens when/if these two parameters
> > are removed. I can add this to my TODO when I rip out platform data
> > support, which will happen when this stuff lands.

> I think the patch is fine for now. Once non-DT support has been removed for
> ux500 we should be able to remove the whole ux500_pcm.c file (Assuming that
> the ux500 DMA engine driver gains dma_slave_caps support).

Yeah, it shouldn't break anything but I'd rather at least have a comment
on any new code that specifies these things by hand explaining why the
automatic stuff doesn't work, it's much nicer to not have to specify the
magic numbers by hand and this will help encourage new code to do the
right thing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131119/2d29152b/attachment.sig>

Re: [PATCH 01/10] dma: ste_dma40: Expand DT binding to accept 'high-priority channel' flag

[Linus Walleij]

On Tue, Nov 19, 2013 at 12:07 PM, Lee Jones <lee.jones@linaro.org> wrote:

> This is used for MSP (audio) devices which is about to be fully DT:ed.
>
> Cc: devicetree@vger.kernel.org
> Acked-by: Vinod Koul <vinod.koul@intel.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

Since this was ACKed by Vinod I have applied it to the ux500-devicetree
branch.

Yours,
Linus Walleij

Re: [PATCH 01/10] dma: ste_dma40: Expand DT binding to accept 'high-priority channel' flag

[Linus Walleij]

On Tue, Nov 19, 2013 at 12:07 PM, Lee Jones <lee.jones@linaro.org> wrote:

> This is used for MSP (audio) devices which is about to be fully DT:ed.
>
> Cc: devicetree@vger.kernel.org
> Acked-by: Vinod Koul <vinod.koul@intel.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

Since this was ACKed by Vinod I have applied it to the ux500-devicetree
branch.

Yours,
Linus Walleij

[PATCH 01/10] dma: ste_dma40: Expand DT binding to accept 'high-priority channel' flag

[Linus Walleij]

On Tue, Nov 19, 2013 at 12:07 PM, Lee Jones <lee.jones@linaro.org> wrote:

> This is used for MSP (audio) devices which is about to be fully DT:ed.
>
> Cc: devicetree at vger.kernel.org
> Acked-by: Vinod Koul <vinod.koul@intel.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

Since this was ACKed by Vinod I have applied it to the ux500-devicetree
branch.

Yours,
Linus Walleij

Re: [PATCH 02/10] dma: ste_dma40: Parse flags property for new 'high priority channel' request

[Linus Walleij]

On Tue, Nov 19, 2013 at 12:07 PM, Lee Jones <lee.jones@linaro.org> wrote:

> This is used for MSP (audio) devices which is about to be fully DT:ed.
>
> Acked-by: Vinod Koul <vinod.koul@intel.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

Applied to the ux500-devicetree branch.

Yours,
Linus Walleij

[PATCH 02/10] dma: ste_dma40: Parse flags property for new 'high priority channel' request

[Linus Walleij]

On Tue, Nov 19, 2013 at 12:07 PM, Lee Jones <lee.jones@linaro.org> wrote:

> This is used for MSP (audio) devices which is about to be fully DT:ed.
>
> Acked-by: Vinod Koul <vinod.koul@intel.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

Applied to the ux500-devicetree branch.

Yours,
Linus Walleij

Re: [PATCH 04/10] ARM: ux500: Add DMA config bindings for MSP devices

[Linus Walleij]

On Tue, Nov 19, 2013 at 12:07 PM, Lee Jones <lee.jones@linaro.org> wrote:

> Signed-off-by: Lee Jones <lee.jones@linaro.org>

I have already applied this in the past...

Yours,
Linus Walleij

[PATCH 04/10] ARM: ux500: Add DMA config bindings for MSP devices

[Linus Walleij]

On Tue, Nov 19, 2013 at 12:07 PM, Lee Jones <lee.jones@linaro.org> wrote:

> Signed-off-by: Lee Jones <lee.jones@linaro.org>

I have already applied this in the past...

Yours,
Linus Walleij

Re: [PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Lee Jones]

On Tue, 19 Nov 2013, Lee Jones wrote:

> At this moment in time the Ux500 ASoC driver obtains its DMA information
> via AUXDATA platform data passing. To make the driver more independent
> we have to start extracting it from the Device Tree.
>  
> If this patch-set could go through ASoC as a whole, it would drive down
> the chance of a dependency mess. Vinod has already provided Acks for his
> parts, so it's just between you two Linus and Mark.
> 
>  Documentation/devicetree/bindings/dma/ste-dma40.txt |   3 ++
>  arch/arm/boot/dts/ste-dbx5x0.dtsi                   |  15 ++++++++++
>  arch/arm/mach-ux500/board-mop500-audio.c            |   8 +++---
>  drivers/dma/ste_dma40.c                             |   4 +++
>  include/linux/platform_data/asoc-ux500-msp.h        |   9 +-----
>  sound/soc/ux500/mop500.c                            |   2 ++
>  sound/soc/ux500/ux500_msp_dai.c                     | 150 +++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------
>  sound/soc/ux500/ux500_msp_i2s.c                     |  56 +++++++++++++++++++++++++++----------
>  sound/soc/ux500/ux500_msp_i2s.h                     |   2 +-
>  sound/soc/ux500/ux500_pcm.c                         |  32 +++++++++++++++------
>  10 files changed, 160 insertions(+), 121 deletions(-)
> 
> Cc: Mark Brown <broonie@kernel.org>

Hi Mark,

Are you/did you already tak(e)ing this set?

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

[PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Lee Jones]

On Tue, 19 Nov 2013, Lee Jones wrote:

> At this moment in time the Ux500 ASoC driver obtains its DMA information
> via AUXDATA platform data passing. To make the driver more independent
> we have to start extracting it from the Device Tree.
>  
> If this patch-set could go through ASoC as a whole, it would drive down
> the chance of a dependency mess. Vinod has already provided Acks for his
> parts, so it's just between you two Linus and Mark.
> 
>  Documentation/devicetree/bindings/dma/ste-dma40.txt |   3 ++
>  arch/arm/boot/dts/ste-dbx5x0.dtsi                   |  15 ++++++++++
>  arch/arm/mach-ux500/board-mop500-audio.c            |   8 +++---
>  drivers/dma/ste_dma40.c                             |   4 +++
>  include/linux/platform_data/asoc-ux500-msp.h        |   9 +-----
>  sound/soc/ux500/mop500.c                            |   2 ++
>  sound/soc/ux500/ux500_msp_dai.c                     | 150 +++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------
>  sound/soc/ux500/ux500_msp_i2s.c                     |  56 +++++++++++++++++++++++++++----------
>  sound/soc/ux500/ux500_msp_i2s.h                     |   2 +-
>  sound/soc/ux500/ux500_pcm.c                         |  32 +++++++++++++++------
>  10 files changed, 160 insertions(+), 121 deletions(-)
> 
> Cc: Mark Brown <broonie@kernel.org>

Hi Mark,

Are you/did you already tak(e)ing this set?

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

Re: [PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

On Fri, Nov 29, 2013 at 04:03:58PM +0000, Lee Jones wrote:

> Are you/did you already tak(e)ing this set?

Don't send contentless nags, they're just noise.  Looking at my sent
mail folder I see:

| I'm happy to merge the first few patches if that's easiest for everyone
| else, let me know and send them to me if that's what works for people.

which doesn't seem to have happened.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Mark Brown]

On Fri, Nov 29, 2013 at 04:03:58PM +0000, Lee Jones wrote:

> Are you/did you already tak(e)ing this set?

Don't send contentless nags, they're just noise.  Looking at my sent
mail folder I see:

| I'm happy to merge the first few patches if that's easiest for everyone
| else, let me know and send them to me if that's what works for people.

which doesn't seem to have happened.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131129/95ba8a43/attachment.sig>

Re: [PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Lee Jones]

>> Are you/did you already tak(e)ing this set?
>
> Don't send contentless nags, they're just noise.

Countless. Errr... 1 after 10 days!

> Looking at my sent mail folder I see:
>
> | I'm happy to merge the first few patches if that's easiest for everyone
> | else, let me know and send them to me if that's what works for people.
>
> which doesn't seem to have happened.

I'm confused. Why do you want them to be resent?

What about the patches which are not in the 'first few'?

I took a look at asoc/topic/ux500, which was mentioned in the same
reply, but they don't appear to be there? Am I looking at a different tree?

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

[PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Lee Jones]

>> Are you/did you already tak(e)ing this set?
>
> Don't send contentless nags, they're just noise.

Countless. Errr... 1 after 10 days!

> Looking at my sent mail folder I see:
>
> | I'm happy to merge the first few patches if that's easiest for everyone
> | else, let me know and send them to me if that's what works for people.
>
> which doesn't seem to have happened.

I'm confused. Why do you want them to be resent?

What about the patches which are not in the 'first few'?

I took a look at asoc/topic/ux500, which was mentioned in the same
reply, but they don't appear to be there? Am I looking at a different tree?

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

Re: [PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

On Fri, Nov 29, 2013 at 05:37:30PM +0000, Lee Jones wrote:
> >> Are you/did you already tak(e)ing this set?

> > Don't send contentless nags, they're just noise.

> Countless. Errr... 1 after 10 days!

Contentless means there's no content in the e-mail rather than that it's
too soon or something.  

In general you should either engage with the prior discussion (for
example here by asking where the patches are if they've not appeared as
expected and/or sending the patches you were asked to send) or resend
patches if there was no response at all (since if patches have been
dropped there's a good chance people don't have them any more).

> > Looking at my sent mail folder I see:

> > | I'm happy to merge the first few patches if that's easiest for everyone
> > | else, let me know and send them to me if that's what works for people.

> > which doesn't seem to have happened.

> I'm confused. Why do you want them to be resent?

You only sent me the ASoC portion of the series, I didn't get the
arch/arm bits since you didn't copy me on them.  I assumed those were
the patches you were taking about.

> What about the patches which are not in the 'first few'?

> I took a look at asoc/topic/ux500, which was mentioned in the same
> reply, but they don't appear to be there? Am I looking at a different tree?

Repushed now.  There was one patch I asked for updates to and which (as
I said) I guess probably depends on the patches you didn't send me.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 00/10] ASoC: dma: ARM: ux500: Obtain DMA data from Device Tree

[Mark Brown]

On Fri, Nov 29, 2013 at 05:37:30PM +0000, Lee Jones wrote:
> >> Are you/did you already tak(e)ing this set?

> > Don't send contentless nags, they're just noise.

> Countless. Errr... 1 after 10 days!

Contentless means there's no content in the e-mail rather than that it's
too soon or something.  

In general you should either engage with the prior discussion (for
example here by asking where the patches are if they've not appeared as
expected and/or sending the patches you were asked to send) or resend
patches if there was no response at all (since if patches have been
dropped there's a good chance people don't have them any more).

> > Looking at my sent mail folder I see:

> > | I'm happy to merge the first few patches if that's easiest for everyone
> > | else, let me know and send them to me if that's what works for people.

> > which doesn't seem to have happened.

> I'm confused. Why do you want them to be resent?

You only sent me the ASoC portion of the series, I didn't get the
arch/arm bits since you didn't copy me on them.  I assumed those were
the patches you were taking about.

> What about the patches which are not in the 'first few'?

> I took a look at asoc/topic/ux500, which was mentioned in the same
> reply, but they don't appear to be there? Am I looking at a different tree?

Repushed now.  There was one patch I asked for updates to and which (as
I said) I guess probably depends on the patches you didn't send me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131129/4a04747f/attachment-0001.sig>

Re: [alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Olof Johansson]

Hi,

On Tue, Nov 19, 2013 at 3:07 AM, Lee Jones <lee.jones@linaro.org> wrote:
> In this patch we do two things. Firstly, instead of open coding the
> store of DMA data in to the DAI for later use, we use the API provided.
> Secondly we create and store similar DMA data for the DT case, only
> this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
> by the core for this very reason.
>
> Cc: alsa-devel@alsa-project.org
> Cc: Mark Brown <broonie@kernel.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>


Seems like this hit -next for the first time today, and it panics
snowball on boot of u8500_defconfig. I bisected down to this patch.

The panic is below. Last output is the dev_dbg() in
ux500_pcm_request_chan. dma_cfg seems to be 0x0000004(!) at that
point. It's indeed crashing on first deref of dma_cfg (confirmed via
addr2line).


ux500-msp-i2s ux500-msp-i2s.1: ux500_pcm_request_chan: MSP 1 (Playback): Enter.
Unable to handle kernel NULL pointer dereference at virtual address 0000002c
pgd = c0004000
[0000002c] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-00003-g6bcb570-dirty #19
task: ef060000 ti: ef04a000 task.ti: ef04a000
PC is at ux500_pcm_request_chan+0xbc/0xe4
LR is at ux500_pcm_request_chan+0x8c/0xe4
pc : [<c02edf00>]    lr : [<c02eded0>]    psr: 60000113
sp : ef04bd10  ip : 00000001  fp : 00020000
r10: ef20be10  r9 : 00800000  r8 : ef1ec010
r7 : ef20be10  r6 : ef0e5c90  r5 : 00000004  r4 : ef1f6800
r3 : 00000004  r2 : 00000000  r1 : 00000004  r0 : c01ed7d4
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5787d  Table: 0000404a  DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xef04a240)
Stack: (0xef04bd10 to 0xef04c000)
bd00:                                     ef1f6800 c04b8e9c 00000000 00000000
bd20: ef1f6800 ef1b80c0 ef1b80cc c02eaa44 00000001 ef1b80cc ef1b8000 ef1ec010
bd40: 00000000 00000001 ef1b80cc ef1b8000 ef226d80 00000000 ef04bd70 c02e98a0
bd60: 00000000 ef04bd6c ef0e6100 ef1f6c00 35386261 305f3030 38626120 2d303035
bd80: 65646f63 61642d63 2d302e69 00000030 ef0e6100 ef0e6100 ef0e5e40 ef0e6100
bda0: 00000000 ef0e5e40 c056c630 c00fc240 00000000 c056c4a0 ef1ec010 ef1b8000
bdc0: c056c630 ef226d80 00000000 00000000 00000002 c02dfdec c056c4b0 00000000
bde0: eec10088 c0569050 00000000 c056c5a8 c056c598 c0569050 c0569090 c02da820
be00: c00303a8 ef1f7400 c056c580 c0569050 c04b7ec4 c056c4c0 c022147c c056c4a0
be20: 000005b8 c104138c c10415e4 ef221e10 00000069 ef04a030 00000000 c02e01a4
be40: c056c448 c1041df4 c104138c c10415e4 ef221e10 c02ee0b8 ef221e10 c056c45c
be60: 00000000 c056c45c c052d958 c0220860 c0220848 ef221e10 c05a1f3c c021f0dc
be80: 00000000 ef221e10 c056c45c ef221e44 00000000 c021f2c8 00000000 c056c45c
bea0: c021f23c c021d70c ef03065c ef1a9db4 c056c45c ef1e3200 c055e4d8 c021e8a4
bec0: c04bbd08 c056c45c 00000006 c056c45c 00000006 c0572680 c0572680 c021f8ac
bee0: 00000000 c053de50 00000006 c0008870 ef010900 c04846d4 ef09a100 c03b54e8
bf00: 00000000 c0572680 0000150c c00f3c6c 00000000 c054edd0 a0000013 00000001
bf20: c104273d c03c868c 00000069 c0035398 c04ee1bc 00000006 c1042748 00000006
bf40: c054edc0 c053de50 00000006 c0572680 c0572680 c051150c 00000069 c0535bdc
bf60: c0535bd0 c0511c30 00000006 00000006 c051150c 00000000 80000000 10000000
bf80: 00000000 00000000 c03aa2ac 00000000 00000000 00000000 00000000 00000000
bfa0: 00000000 c03aa2b4 00000000 c000e478 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000002 00000000
[<c02edf00>] (ux500_pcm_request_chan+0xbc/0xe4) from [<c02eaa44>]
(dmaengine_pcm_new+0x16c/0x1a0)
[<c02eaa44>] (dmaengine_pcm_new+0x16c/0x1a0) from [<c02e98a0>]
(soc_new_pcm+0x2bc/0x3c8)
[<c02e98a0>] (soc_new_pcm+0x2bc/0x3c8) from [<c02dfdec>]
(snd_soc_instantiate_card+0xff0/0x113c)
[<c02dfdec>] (snd_soc_instantiate_card+0xff0/0x113c) from [<c02e01a4>]
(snd_soc_register_card+0x26c/0x3a4)
[<c02e01a4>] (snd_soc_register_card+0x26c/0x3a4) from [<c02ee0b8>]
(mop500_probe+0xe0/0x128)
[<c02ee0b8>] (mop500_probe+0xe0/0x128) from [<c0220860>]
(platform_drv_probe+0x18/0x48)
[<c0220860>] (platform_drv_probe+0x18/0x48) from [<c021f0dc>]
(driver_probe_device+0x124/0x240)
[<c021f0dc>] (driver_probe_device+0x124/0x240) from [<c021f2c8>]
(__driver_attach+0x8c/0x90)
[<c021f2c8>] (__driver_attach+0x8c/0x90) from [<c021d70c>]
(bus_for_each_dev+0x60/0x94)
[<c021d70c>] (bus_for_each_dev+0x60/0x94) from [<c021e8a4>]
(bus_add_driver+0x148/0x1f0)
[<c021e8a4>] (bus_add_driver+0x148/0x1f0) from [<c021f8ac>]
(driver_register+0x78/0xf8)
[<c021f8ac>] (driver_register+0x78/0xf8) from [<c0008870>]
(do_one_initcall+0x100/0x14c)
[<c0008870>] (do_one_initcall+0x100/0x14c) from [<c0511c30>]
(kernel_init_freeable+0x138/0x1d8)
[<c0511c30>] (kernel_init_freeable+0x138/0x1d8) from [<c03aa2b4>]
(kernel_init+0x8/0x120)
[<c03aa2b4>] (kernel_init+0x8/0x120) from [<c000e478>] (ret_from_fork+0x14/0x3c)
Code: e1a01005 e30d07d4 e34c001e e3520000 (05853028)

I'm out of time to debug this more until tomorrow night or possibly
later, so I figured I'd report it at least.


-Olof

Re: [alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Olof Johansson]

Hi,

On Tue, Nov 19, 2013 at 3:07 AM, Lee Jones <lee.jones@linaro.org> wrote:
> In this patch we do two things. Firstly, instead of open coding the
> store of DMA data in to the DAI for later use, we use the API provided.
> Secondly we create and store similar DMA data for the DT case, only
> this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
> by the core for this very reason.
>
> Cc: alsa-devel@alsa-project.org
> Cc: Mark Brown <broonie@kernel.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>


Seems like this hit -next for the first time today, and it panics
snowball on boot of u8500_defconfig. I bisected down to this patch.

The panic is below. Last output is the dev_dbg() in
ux500_pcm_request_chan. dma_cfg seems to be 0x0000004(!) at that
point. It's indeed crashing on first deref of dma_cfg (confirmed via
addr2line).


ux500-msp-i2s ux500-msp-i2s.1: ux500_pcm_request_chan: MSP 1 (Playback): Enter.
Unable to handle kernel NULL pointer dereference at virtual address 0000002c
pgd = c0004000
[0000002c] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-00003-g6bcb570-dirty #19
task: ef060000 ti: ef04a000 task.ti: ef04a000
PC is at ux500_pcm_request_chan+0xbc/0xe4
LR is at ux500_pcm_request_chan+0x8c/0xe4
pc : [<c02edf00>]    lr : [<c02eded0>]    psr: 60000113
sp : ef04bd10  ip : 00000001  fp : 00020000
r10: ef20be10  r9 : 00800000  r8 : ef1ec010
r7 : ef20be10  r6 : ef0e5c90  r5 : 00000004  r4 : ef1f6800
r3 : 00000004  r2 : 00000000  r1 : 00000004  r0 : c01ed7d4
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5787d  Table: 0000404a  DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xef04a240)
Stack: (0xef04bd10 to 0xef04c000)
bd00:                                     ef1f6800 c04b8e9c 00000000 00000000
bd20: ef1f6800 ef1b80c0 ef1b80cc c02eaa44 00000001 ef1b80cc ef1b8000 ef1ec010
bd40: 00000000 00000001 ef1b80cc ef1b8000 ef226d80 00000000 ef04bd70 c02e98a0
bd60: 00000000 ef04bd6c ef0e6100 ef1f6c00 35386261 305f3030 38626120 2d303035
bd80: 65646f63 61642d63 2d302e69 00000030 ef0e6100 ef0e6100 ef0e5e40 ef0e6100
bda0: 00000000 ef0e5e40 c056c630 c00fc240 00000000 c056c4a0 ef1ec010 ef1b8000
bdc0: c056c630 ef226d80 00000000 00000000 00000002 c02dfdec c056c4b0 00000000
bde0: eec10088 c0569050 00000000 c056c5a8 c056c598 c0569050 c0569090 c02da820
be00: c00303a8 ef1f7400 c056c580 c0569050 c04b7ec4 c056c4c0 c022147c c056c4a0
be20: 000005b8 c104138c c10415e4 ef221e10 00000069 ef04a030 00000000 c02e01a4
be40: c056c448 c1041df4 c104138c c10415e4 ef221e10 c02ee0b8 ef221e10 c056c45c
be60: 00000000 c056c45c c052d958 c0220860 c0220848 ef221e10 c05a1f3c c021f0dc
be80: 00000000 ef221e10 c056c45c ef221e44 00000000 c021f2c8 00000000 c056c45c
bea0: c021f23c c021d70c ef03065c ef1a9db4 c056c45c ef1e3200 c055e4d8 c021e8a4
bec0: c04bbd08 c056c45c 00000006 c056c45c 00000006 c0572680 c0572680 c021f8ac
bee0: 00000000 c053de50 00000006 c0008870 ef010900 c04846d4 ef09a100 c03b54e8
bf00: 00000000 c0572680 0000150c c00f3c6c 00000000 c054edd0 a0000013 00000001
bf20: c104273d c03c868c 00000069 c0035398 c04ee1bc 00000006 c1042748 00000006
bf40: c054edc0 c053de50 00000006 c0572680 c0572680 c051150c 00000069 c0535bdc
bf60: c0535bd0 c0511c30 00000006 00000006 c051150c 00000000 80000000 10000000
bf80: 00000000 00000000 c03aa2ac 00000000 00000000 00000000 00000000 00000000
bfa0: 00000000 c03aa2b4 00000000 c000e478 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000002 00000000
[<c02edf00>] (ux500_pcm_request_chan+0xbc/0xe4) from [<c02eaa44>]
(dmaengine_pcm_new+0x16c/0x1a0)
[<c02eaa44>] (dmaengine_pcm_new+0x16c/0x1a0) from [<c02e98a0>]
(soc_new_pcm+0x2bc/0x3c8)
[<c02e98a0>] (soc_new_pcm+0x2bc/0x3c8) from [<c02dfdec>]
(snd_soc_instantiate_card+0xff0/0x113c)
[<c02dfdec>] (snd_soc_instantiate_card+0xff0/0x113c) from [<c02e01a4>]
(snd_soc_register_card+0x26c/0x3a4)
[<c02e01a4>] (snd_soc_register_card+0x26c/0x3a4) from [<c02ee0b8>]
(mop500_probe+0xe0/0x128)
[<c02ee0b8>] (mop500_probe+0xe0/0x128) from [<c0220860>]
(platform_drv_probe+0x18/0x48)
[<c0220860>] (platform_drv_probe+0x18/0x48) from [<c021f0dc>]
(driver_probe_device+0x124/0x240)
[<c021f0dc>] (driver_probe_device+0x124/0x240) from [<c021f2c8>]
(__driver_attach+0x8c/0x90)
[<c021f2c8>] (__driver_attach+0x8c/0x90) from [<c021d70c>]
(bus_for_each_dev+0x60/0x94)
[<c021d70c>] (bus_for_each_dev+0x60/0x94) from [<c021e8a4>]
(bus_add_driver+0x148/0x1f0)
[<c021e8a4>] (bus_add_driver+0x148/0x1f0) from [<c021f8ac>]
(driver_register+0x78/0xf8)
[<c021f8ac>] (driver_register+0x78/0xf8) from [<c0008870>]
(do_one_initcall+0x100/0x14c)
[<c0008870>] (do_one_initcall+0x100/0x14c) from [<c0511c30>]
(kernel_init_freeable+0x138/0x1d8)
[<c0511c30>] (kernel_init_freeable+0x138/0x1d8) from [<c03aa2b4>]
(kernel_init+0x8/0x120)
[<c03aa2b4>] (kernel_init+0x8/0x120) from [<c000e478>] (ret_from_fork+0x14/0x3c)
Code: e1a01005 e30d07d4 e34c001e e3520000 (05853028)

I'm out of time to debug this more until tomorrow night or possibly
later, so I figured I'd report it at least.


-Olof

[alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Olof Johansson]

Hi,

On Tue, Nov 19, 2013 at 3:07 AM, Lee Jones <lee.jones@linaro.org> wrote:
> In this patch we do two things. Firstly, instead of open coding the
> store of DMA data in to the DAI for later use, we use the API provided.
> Secondly we create and store similar DMA data for the DT case, only
> this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
> by the core for this very reason.
>
> Cc: alsa-devel at alsa-project.org
> Cc: Mark Brown <broonie@kernel.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>


Seems like this hit -next for the first time today, and it panics
snowball on boot of u8500_defconfig. I bisected down to this patch.

The panic is below. Last output is the dev_dbg() in
ux500_pcm_request_chan. dma_cfg seems to be 0x0000004(!) at that
point. It's indeed crashing on first deref of dma_cfg (confirmed via
addr2line).


ux500-msp-i2s ux500-msp-i2s.1: ux500_pcm_request_chan: MSP 1 (Playback): Enter.
Unable to handle kernel NULL pointer dereference at virtual address 0000002c
pgd = c0004000
[0000002c] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-00003-g6bcb570-dirty #19
task: ef060000 ti: ef04a000 task.ti: ef04a000
PC is at ux500_pcm_request_chan+0xbc/0xe4
LR is at ux500_pcm_request_chan+0x8c/0xe4
pc : [<c02edf00>]    lr : [<c02eded0>]    psr: 60000113
sp : ef04bd10  ip : 00000001  fp : 00020000
r10: ef20be10  r9 : 00800000  r8 : ef1ec010
r7 : ef20be10  r6 : ef0e5c90  r5 : 00000004  r4 : ef1f6800
r3 : 00000004  r2 : 00000000  r1 : 00000004  r0 : c01ed7d4
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5787d  Table: 0000404a  DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xef04a240)
Stack: (0xef04bd10 to 0xef04c000)
bd00:                                     ef1f6800 c04b8e9c 00000000 00000000
bd20: ef1f6800 ef1b80c0 ef1b80cc c02eaa44 00000001 ef1b80cc ef1b8000 ef1ec010
bd40: 00000000 00000001 ef1b80cc ef1b8000 ef226d80 00000000 ef04bd70 c02e98a0
bd60: 00000000 ef04bd6c ef0e6100 ef1f6c00 35386261 305f3030 38626120 2d303035
bd80: 65646f63 61642d63 2d302e69 00000030 ef0e6100 ef0e6100 ef0e5e40 ef0e6100
bda0: 00000000 ef0e5e40 c056c630 c00fc240 00000000 c056c4a0 ef1ec010 ef1b8000
bdc0: c056c630 ef226d80 00000000 00000000 00000002 c02dfdec c056c4b0 00000000
bde0: eec10088 c0569050 00000000 c056c5a8 c056c598 c0569050 c0569090 c02da820
be00: c00303a8 ef1f7400 c056c580 c0569050 c04b7ec4 c056c4c0 c022147c c056c4a0
be20: 000005b8 c104138c c10415e4 ef221e10 00000069 ef04a030 00000000 c02e01a4
be40: c056c448 c1041df4 c104138c c10415e4 ef221e10 c02ee0b8 ef221e10 c056c45c
be60: 00000000 c056c45c c052d958 c0220860 c0220848 ef221e10 c05a1f3c c021f0dc
be80: 00000000 ef221e10 c056c45c ef221e44 00000000 c021f2c8 00000000 c056c45c
bea0: c021f23c c021d70c ef03065c ef1a9db4 c056c45c ef1e3200 c055e4d8 c021e8a4
bec0: c04bbd08 c056c45c 00000006 c056c45c 00000006 c0572680 c0572680 c021f8ac
bee0: 00000000 c053de50 00000006 c0008870 ef010900 c04846d4 ef09a100 c03b54e8
bf00: 00000000 c0572680 0000150c c00f3c6c 00000000 c054edd0 a0000013 00000001
bf20: c104273d c03c868c 00000069 c0035398 c04ee1bc 00000006 c1042748 00000006
bf40: c054edc0 c053de50 00000006 c0572680 c0572680 c051150c 00000069 c0535bdc
bf60: c0535bd0 c0511c30 00000006 00000006 c051150c 00000000 80000000 10000000
bf80: 00000000 00000000 c03aa2ac 00000000 00000000 00000000 00000000 00000000
bfa0: 00000000 c03aa2b4 00000000 c000e478 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000002 00000000
[<c02edf00>] (ux500_pcm_request_chan+0xbc/0xe4) from [<c02eaa44>]
(dmaengine_pcm_new+0x16c/0x1a0)
[<c02eaa44>] (dmaengine_pcm_new+0x16c/0x1a0) from [<c02e98a0>]
(soc_new_pcm+0x2bc/0x3c8)
[<c02e98a0>] (soc_new_pcm+0x2bc/0x3c8) from [<c02dfdec>]
(snd_soc_instantiate_card+0xff0/0x113c)
[<c02dfdec>] (snd_soc_instantiate_card+0xff0/0x113c) from [<c02e01a4>]
(snd_soc_register_card+0x26c/0x3a4)
[<c02e01a4>] (snd_soc_register_card+0x26c/0x3a4) from [<c02ee0b8>]
(mop500_probe+0xe0/0x128)
[<c02ee0b8>] (mop500_probe+0xe0/0x128) from [<c0220860>]
(platform_drv_probe+0x18/0x48)
[<c0220860>] (platform_drv_probe+0x18/0x48) from [<c021f0dc>]
(driver_probe_device+0x124/0x240)
[<c021f0dc>] (driver_probe_device+0x124/0x240) from [<c021f2c8>]
(__driver_attach+0x8c/0x90)
[<c021f2c8>] (__driver_attach+0x8c/0x90) from [<c021d70c>]
(bus_for_each_dev+0x60/0x94)
[<c021d70c>] (bus_for_each_dev+0x60/0x94) from [<c021e8a4>]
(bus_add_driver+0x148/0x1f0)
[<c021e8a4>] (bus_add_driver+0x148/0x1f0) from [<c021f8ac>]
(driver_register+0x78/0xf8)
[<c021f8ac>] (driver_register+0x78/0xf8) from [<c0008870>]
(do_one_initcall+0x100/0x14c)
[<c0008870>] (do_one_initcall+0x100/0x14c) from [<c0511c30>]
(kernel_init_freeable+0x138/0x1d8)
[<c0511c30>] (kernel_init_freeable+0x138/0x1d8) from [<c03aa2b4>]
(kernel_init+0x8/0x120)
[<c03aa2b4>] (kernel_init+0x8/0x120) from [<c000e478>] (ret_from_fork+0x14/0x3c)
Code: e1a01005 e30d07d4 e34c001e e3520000 (05853028)

I'm out of time to debug this more until tomorrow night or possibly
later, so I figured I'd report it at least.


-Olof

Re: [alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

On Sun, 01 Dec 2013, Olof Johansson wrote:

> Hi,
> 
> On Tue, Nov 19, 2013 at 3:07 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > In this patch we do two things. Firstly, instead of open coding the
> > store of DMA data in to the DAI for later use, we use the API provided.
> > Secondly we create and store similar DMA data for the DT case, only
> > this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
> > by the core for this very reason.
> >
> > Cc: alsa-devel@alsa-project.org
> > Cc: Mark Brown <broonie@kernel.org>
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> 
> 
> Seems like this hit -next for the first time today, and it panics
> snowball on boot of u8500_defconfig. I bisected down to this patch.
> 
> The panic is below. Last output is the dev_dbg() in
> ux500_pcm_request_chan. dma_cfg seems to be 0x0000004(!) at that
> point. It's indeed crashing on first deref of dma_cfg (confirmed via
> addr2line).

Okay, I just debugged this.

It's actually my fault. I had two patches round the wrong way in the
series. The imediately subsequent patch in the set fixes this issue:

Author: Lee Jones <lee.jones@linaro.org>
Date:   Tue Nov 5 22:57:31 2013 +0000

    ASoC: ux500_pcm: Differentiate between pdata and DT initialisation
    
    If booting with full DT support (i.e. DMA too, the last piece of the
    puzzle), then we don't need to use the compatible request channel call
    back and, due to the work we laid down earlier in this patch-set, we
    can use core function calls to populate the DMA slave_config. We also
    require slightly different flags to inform the core that we 'are'
    booting with DT.
    
    Cc: alsa-devel@alsa-project.org
    Cc: Mark Brown <broonie@kernel.org>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

diff --git a/sound/soc/ux500/ux500_pcm.c b/sound/soc/ux500/ux500_pcm.c
index ce554de..acfec98 100644
--- a/sound/soc/ux500/ux500_pcm.c
+++ b/sound/soc/ux500/ux500_pcm.c
@@ -139,15 +139,33 @@ static const struct snd_dmaengine_pcm_config ux500_dmaengine_pcm_config = {
 	.prepare_slave_config = ux500_pcm_prepare_slave_config,
 };
 
+static const struct snd_dmaengine_pcm_config ux500_dmaengine_of_pcm_config = {
+	.pcm_hardware = &ux500_pcm_hw,
+	.prealloc_buffer_size = 128 * 1024,
+	.prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
+};
+
 int ux500_pcm_register_platform(struct platform_device *pdev)
 {
+	const struct snd_dmaengine_pcm_config *pcm_config;
+	struct device_node *np = pdev->dev.of_node;
+	unsigned int pcm_flags;
 	int ret;
 
-	ret = snd_dmaengine_pcm_register(&pdev->dev,
-			&ux500_dmaengine_pcm_config,
-			SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
-			SND_DMAENGINE_PCM_FLAG_COMPAT |
-			SND_DMAENGINE_PCM_FLAG_NO_DT);
+	if (np) {
+		pcm_config = &ux500_dmaengine_of_pcm_config;
+
+		pcm_flags = SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+			SND_DMAENGINE_PCM_FLAG_COMPAT;
+	} else {
+		pcm_config = &ux500_dmaengine_pcm_config;
+
+		pcm_flags = SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+			SND_DMAENGINE_PCM_FLAG_NO_DT |
+			SND_DMAENGINE_PCM_FLAG_COMPAT;
+	}
+
+	ret = snd_dmaengine_pcm_register(&pdev->dev, pcm_config, pcm_flags);
 	if (ret < 0) {
 		dev_err(&pdev->dev,
 			"%s: ERROR: Failed to register platform '%s' (%d)!\n",

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

Re: [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

On Sun, 01 Dec 2013, Olof Johansson wrote:

> Hi,
> 
> On Tue, Nov 19, 2013 at 3:07 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > In this patch we do two things. Firstly, instead of open coding the
> > store of DMA data in to the DAI for later use, we use the API provided.
> > Secondly we create and store similar DMA data for the DT case, only
> > this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
> > by the core for this very reason.
> >
> > Cc: alsa-devel@alsa-project.org
> > Cc: Mark Brown <broonie@kernel.org>
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> 
> 
> Seems like this hit -next for the first time today, and it panics
> snowball on boot of u8500_defconfig. I bisected down to this patch.
> 
> The panic is below. Last output is the dev_dbg() in
> ux500_pcm_request_chan. dma_cfg seems to be 0x0000004(!) at that
> point. It's indeed crashing on first deref of dma_cfg (confirmed via
> addr2line).

Okay, I just debugged this.

It's actually my fault. I had two patches round the wrong way in the
series. The imediately subsequent patch in the set fixes this issue:

Author: Lee Jones <lee.jones@linaro.org>
Date:   Tue Nov 5 22:57:31 2013 +0000

    ASoC: ux500_pcm: Differentiate between pdata and DT initialisation
    
    If booting with full DT support (i.e. DMA too, the last piece of the
    puzzle), then we don't need to use the compatible request channel call
    back and, due to the work we laid down earlier in this patch-set, we
    can use core function calls to populate the DMA slave_config. We also
    require slightly different flags to inform the core that we 'are'
    booting with DT.
    
    Cc: alsa-devel@alsa-project.org
    Cc: Mark Brown <broonie@kernel.org>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

diff --git a/sound/soc/ux500/ux500_pcm.c b/sound/soc/ux500/ux500_pcm.c
index ce554de..acfec98 100644
--- a/sound/soc/ux500/ux500_pcm.c
+++ b/sound/soc/ux500/ux500_pcm.c
@@ -139,15 +139,33 @@ static const struct snd_dmaengine_pcm_config ux500_dmaengine_pcm_config = {
 	.prepare_slave_config = ux500_pcm_prepare_slave_config,
 };
 
+static const struct snd_dmaengine_pcm_config ux500_dmaengine_of_pcm_config = {
+	.pcm_hardware = &ux500_pcm_hw,
+	.prealloc_buffer_size = 128 * 1024,
+	.prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
+};
+
 int ux500_pcm_register_platform(struct platform_device *pdev)
 {
+	const struct snd_dmaengine_pcm_config *pcm_config;
+	struct device_node *np = pdev->dev.of_node;
+	unsigned int pcm_flags;
 	int ret;
 
-	ret = snd_dmaengine_pcm_register(&pdev->dev,
-			&ux500_dmaengine_pcm_config,
-			SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
-			SND_DMAENGINE_PCM_FLAG_COMPAT |
-			SND_DMAENGINE_PCM_FLAG_NO_DT);
+	if (np) {
+		pcm_config = &ux500_dmaengine_of_pcm_config;
+
+		pcm_flags = SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+			SND_DMAENGINE_PCM_FLAG_COMPAT;
+	} else {
+		pcm_config = &ux500_dmaengine_pcm_config;
+
+		pcm_flags = SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+			SND_DMAENGINE_PCM_FLAG_NO_DT |
+			SND_DMAENGINE_PCM_FLAG_COMPAT;
+	}
+
+	ret = snd_dmaengine_pcm_register(&pdev->dev, pcm_config, pcm_flags);
 	if (ret < 0) {
 		dev_err(&pdev->dev,
 			"%s: ERROR: Failed to register platform '%s' (%d)!\n",

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

On Sun, 01 Dec 2013, Olof Johansson wrote:

> Hi,
> 
> On Tue, Nov 19, 2013 at 3:07 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > In this patch we do two things. Firstly, instead of open coding the
> > store of DMA data in to the DAI for later use, we use the API provided.
> > Secondly we create and store similar DMA data for the DT case, only
> > this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
> > by the core for this very reason.
> >
> > Cc: alsa-devel at alsa-project.org
> > Cc: Mark Brown <broonie@kernel.org>
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> 
> 
> Seems like this hit -next for the first time today, and it panics
> snowball on boot of u8500_defconfig. I bisected down to this patch.
> 
> The panic is below. Last output is the dev_dbg() in
> ux500_pcm_request_chan. dma_cfg seems to be 0x0000004(!) at that
> point. It's indeed crashing on first deref of dma_cfg (confirmed via
> addr2line).

Okay, I just debugged this.

It's actually my fault. I had two patches round the wrong way in the
series. The imediately subsequent patch in the set fixes this issue:

Author: Lee Jones <lee.jones@linaro.org>
Date:   Tue Nov 5 22:57:31 2013 +0000

    ASoC: ux500_pcm: Differentiate between pdata and DT initialisation
    
    If booting with full DT support (i.e. DMA too, the last piece of the
    puzzle), then we don't need to use the compatible request channel call
    back and, due to the work we laid down earlier in this patch-set, we
    can use core function calls to populate the DMA slave_config. We also
    require slightly different flags to inform the core that we 'are'
    booting with DT.
    
    Cc: alsa-devel at alsa-project.org
    Cc: Mark Brown <broonie@kernel.org>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

diff --git a/sound/soc/ux500/ux500_pcm.c b/sound/soc/ux500/ux500_pcm.c
index ce554de..acfec98 100644
--- a/sound/soc/ux500/ux500_pcm.c
+++ b/sound/soc/ux500/ux500_pcm.c
@@ -139,15 +139,33 @@ static const struct snd_dmaengine_pcm_config ux500_dmaengine_pcm_config = {
 	.prepare_slave_config = ux500_pcm_prepare_slave_config,
 };
 
+static const struct snd_dmaengine_pcm_config ux500_dmaengine_of_pcm_config = {
+	.pcm_hardware = &ux500_pcm_hw,
+	.prealloc_buffer_size = 128 * 1024,
+	.prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
+};
+
 int ux500_pcm_register_platform(struct platform_device *pdev)
 {
+	const struct snd_dmaengine_pcm_config *pcm_config;
+	struct device_node *np = pdev->dev.of_node;
+	unsigned int pcm_flags;
 	int ret;
 
-	ret = snd_dmaengine_pcm_register(&pdev->dev,
-			&ux500_dmaengine_pcm_config,
-			SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
-			SND_DMAENGINE_PCM_FLAG_COMPAT |
-			SND_DMAENGINE_PCM_FLAG_NO_DT);
+	if (np) {
+		pcm_config = &ux500_dmaengine_of_pcm_config;
+
+		pcm_flags = SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+			SND_DMAENGINE_PCM_FLAG_COMPAT;
+	} else {
+		pcm_config = &ux500_dmaengine_pcm_config;
+
+		pcm_flags = SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
+			SND_DMAENGINE_PCM_FLAG_NO_DT |
+			SND_DMAENGINE_PCM_FLAG_COMPAT;
+	}
+
+	ret = snd_dmaengine_pcm_register(&pdev->dev, pcm_config, pcm_flags);
 	if (ret < 0) {
 		dev_err(&pdev->dev,
 			"%s: ERROR: Failed to register platform '%s' (%d)!\n",

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

Re: [alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On Mon, Dec 02, 2013 at 10:12:56AM +0000, Lee Jones wrote:

> It's actually my fault. I had two patches round the wrong way in the
> series. The imediately subsequent patch in the set fixes this issue:

OK, so what do we do about this?  Is there going to be a revision of
that patch adding the note about not using the autoconfiguration stuff
and what (if any) are the dependencies on the arch/arm changes?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On Mon, Dec 02, 2013 at 10:12:56AM +0000, Lee Jones wrote:

> It's actually my fault. I had two patches round the wrong way in the
> series. The imediately subsequent patch in the set fixes this issue:

OK, so what do we do about this?  Is there going to be a revision of
that patch adding the note about not using the autoconfiguration stuff
and what (if any) are the dependencies on the arch/arm changes?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Mark Brown]

On Mon, Dec 02, 2013 at 10:12:56AM +0000, Lee Jones wrote:

> It's actually my fault. I had two patches round the wrong way in the
> series. The imediately subsequent patch in the set fixes this issue:

OK, so what do we do about this?  Is there going to be a revision of
that patch adding the note about not using the autoconfiguration stuff
and what (if any) are the dependencies on the arch/arm changes?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131202/5fc251ff/attachment.sig>

Re: [alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

On Mon, 02 Dec 2013, Mark Brown wrote:

> On Mon, Dec 02, 2013 at 10:12:56AM +0000, Lee Jones wrote:
> 
> > It's actually my fault. I had two patches round the wrong way in the
> > series. The imediately subsequent patch in the set fixes this issue:
> 
> OK, so what do we do about this?  Is there going to be a revision of
> that patch adding the note about not using the autoconfiguration stuff
> and what (if any) are the dependencies on the arch/arm changes?

I can shoot out a revision no problem.

I'm not aware of any dependencies on the ARM changes. I haven't tested
the arch/arm and sound/soc adaptions orthogonally, but I _think_ the
right decisions should be made depending on the information passed
from platform/dt code.

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

Re: [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

On Mon, 02 Dec 2013, Mark Brown wrote:

> On Mon, Dec 02, 2013 at 10:12:56AM +0000, Lee Jones wrote:
> 
> > It's actually my fault. I had two patches round the wrong way in the
> > series. The imediately subsequent patch in the set fixes this issue:
> 
> OK, so what do we do about this?  Is there going to be a revision of
> that patch adding the note about not using the autoconfiguration stuff
> and what (if any) are the dependencies on the arch/arm changes?

I can shoot out a revision no problem.

I'm not aware of any dependencies on the ARM changes. I haven't tested
the arch/arm and sound/soc adaptions orthogonally, but I _think_ the
right decisions should be made depending on the information passed
from platform/dt code.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

On Mon, 02 Dec 2013, Mark Brown wrote:

> On Mon, Dec 02, 2013 at 10:12:56AM +0000, Lee Jones wrote:
> 
> > It's actually my fault. I had two patches round the wrong way in the
> > series. The imediately subsequent patch in the set fixes this issue:
> 
> OK, so what do we do about this?  Is there going to be a revision of
> that patch adding the note about not using the autoconfiguration stuff
> and what (if any) are the dependencies on the arch/arm changes?

I can shoot out a revision no problem.

I'm not aware of any dependencies on the ARM changes. I haven't tested
the arch/arm and sound/soc adaptions orthogonally, but I _think_ the
right decisions should be made depending on the information passed
from platform/dt code.

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

Re: [alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

On Mon, Dec 02, 2013 at 02:03:24PM +0000, Lee Jones wrote:

> I'm not aware of any dependencies on the ARM changes. I haven't tested
> the arch/arm and sound/soc adaptions orthogonally, but I _think_ the
> right decisions should be made depending on the information passed
> from platform/dt code.

OK, that sounds great thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 329 bytes --]

On Mon, Dec 02, 2013 at 02:03:24PM +0000, Lee Jones wrote:

> I'm not aware of any dependencies on the ARM changes. I haven't tested
> the arch/arm and sound/soc adaptions orthogonally, but I _think_ the
> right decisions should be made depending on the information passed
> from platform/dt code.

OK, that sounds great thanks.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[alsa-devel] [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Mark Brown]

On Mon, Dec 02, 2013 at 02:03:24PM +0000, Lee Jones wrote:

> I'm not aware of any dependencies on the ARM changes. I haven't tested
> the arch/arm and sound/soc adaptions orthogonally, but I _think_ the
> right decisions should be made depending on the information passed
> from platform/dt code.

OK, that sounds great thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131202/0109c50b/attachment.sig>

Re: [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Kevin Hilman]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

On Tue, Nov 19, 2013 at 3:07 AM, Lee Jones <lee.jones@linaro.org> wrote:
> In this patch we do two things. Firstly, instead of open coding the
> store of DMA data in to the DAI for later use, we use the API provided.
> Secondly we create and store similar DMA data for the DT case, only
> this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
> by the core for this very reason.
>
> Cc: alsa-devel@alsa-project.org
> Cc: Mark Brown <broonie@kernel.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  sound/soc/ux500/ux500_msp_dai.c | 42 +++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 40 insertions(+), 2 deletions(-)

Today's next (next-20131204) has a new boot failure[1] on
ux500/snowball which bisected down to this commit.  Full boot log
attached.

It doesn't find the alsa device which in turn seems to prevent the
emmc rootfs from being mounted.  It boots fine to an initramfs.

Kevin

[1] http://lists.linaro.org/pipermail/kernel-build-reports/2013-December/001382.html

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: boot-snowball.log --]
[-- Type: text/x-log; charset=US-ASCII; name="boot-snowball.log", Size: 18759 bytes --]

Connected to snowball console [channel connected] (~$quit to exit)
(user:khilman) is already connected
(user:khilman) is already connected

~$hardreset

Command(snowball console)> hardreset
(user:khilman) Reboot snowball
Reboot: snowball ; ip9258 2 2 :  ('off', 6, 'on')
, sleep 6,
L˜LC\x05(WR_MNGT_STARTED 1
About to do AVS calculations
About to exec MEMINIT function 0
Executed MEMINIT function 0
About to ask ISSW to perform MEMINIT
ISSW returned from MEMINIT, Vendor ID 0xFF len 0x10 CS0 density 0x54 CS1 density 0x54
About to exec MEMINIT function 1

SoC settings: INFO: @(#)SOC-SETTINGS v3.0.2-AVS_VMOD_workaround db8500 v2 1000Mhz Jun 30 2011 19:08:06
SoC settings: INFO: Memory size=0x40000000 (1024 MB)
SoC settings: INFO: DDR Test Ended successfully.
SoC settings: INFO: Requesting 1GHz from PRCMU
SoC settings: INFO: Error setting 1GHz dvfs: 0x00000000
Executed MEMINIT function 1
MEMINIT passed OK
About to load NORMAL
After NORMAL loaded
verify_signedheader
TEEC_InvokeCommand TEEC_SUCCESS != result (0xFFFF000F)
Loading raw payload
XL_DisableCachesMmu
Before ENABLE_L2CC
After ENABLE_L2CC
Flush boot issw code
Before call normal


U-Boot 2009.11 (sept. 19 2011 - 17:03:11)

CPU:	ST-Ericsson db8500 v2 (Dual ARM Cortex A9) 998.400 Mhz
I2C:   ready
DRAM:   1 GB
MMC: 	
MCDE:  startup failed
sec_bridge: ISSWAPI_FLUSH_BOOT_CODE: 2
EMMC: 0, MMC: 1
In:    serial
Out:   serial
Err:   serial
Net:   smc911x-0
Hit any key to stop autoboot:  1
 \b\b\b 0 
U8500 $ 
U8500 $ version
version

U-Boot 2009.11 (sept. 19 2011 - 17:03:11)
U8500 $ setenv ethaddr 6e:e6:84:36:8e:9e
setenv ethaddr 6e:e6:84:36:8e:9e
Can't overwrite "ethaddr"
U8500 $ setenv bootargs console=ttyAMA2,115200n8 debug earlyprintk rw root=/dev/mmcblk0p3 rootwait rootfstype=ext4
setenv bootargs console=ttyAMA2,115200n8 debug earlyprintk rw root=/dev/mmcblk0p3 rootwait rootfstype=ext4
U8500 $ setenv netargs 'setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}::::192.168.1.254:none'
setenv netargs 'setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}::::192.168.1.254:none'
U8500 $ if test -n ${initenv}; then run initenv; fi
if test -n ${initenv}; then run initenv; fi
U8500 $ if test -n ${preboot}; then run preboot; fi
if test -n ${preboot}; then run preboot; fi
U8500 $ setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
U8500 $ dhcp
dhcp
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 6e:e6:84:36:8e:9e
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.1.184
U8500 $ setenv serverip 192.168.1.2
setenv serverip 192.168.1.2
U8500 $if test -n ${netargs}; then run netargs; fi
 if test -n ${netargs}; then run netargs; fi
U8500 $ tftp 0x00800000 tmp/snowball-wx0mRt/tmppEJCfC-uImage
tftp 0x00800000 tmp/snowball-wx0mRt/tmppEJCfC-uImage
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 6e:e6:84:36:8e:9e
Using smc911x-0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.184
Filename 'tmp/snowball-wx0mRt/tmppEJCfC-uImage'.
Load address: 0x800000
Loading: *\b#################################################################
	 #################################################################
	 #################################################################
	 ####
done
Bytes transferred = 2908132 (2c5fe4 hex)
U8500 $ printenv bootargs
printenv bootargs
bootargs=console=ttyAMA2,115200n8 debug earlyprintk rw root=/dev/mmcblk0p3 rootwait rootfstype=ext4 ip=192.168.1.184:192.168.1.2:192.168.1.254:255.255.255.0::::192.168.1.254:none
U8500 $ bootm 0x00800000  
bootm 0x00800000  
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2908068 Bytes =  2.8 MB
   Load Address: 00008000
   Entry Point:  00008000
   Loading Kernel Image ... OK
OK

Starting kernel ...

Booting Linux on physical CPU 0x300
Linux version 3.13.0-rc2-next-20131204 (khilman@paris) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-1ubuntu1) ) #14 SMP PREEMPT Wed Dec 4 09:32:43 PST 2013
CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Calao Systems Snowball platform with device tree
Memory policy: Data cache writealloc
DB8500 v2.2 [0x008500b2]
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat c05677c0, node_mem_map c082f000
  Normal zone: 1520 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 194560 pages, LIFO batch:31
  HighMem zone: 528 pages used for memmap
  HighMem zone: 67584 pages, LIFO batch:15
PERCPU: Embedded 7 pages/cpu @c103e000 s7808 r8192 d12672 u32768
pcpu-alloc: s7808 r8192 d12672 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260624
Kernel command line: console=ttyAMA2,115200n8 debug earlyprintk rw root=/dev/mmcblk0p3 rootwait rootfstype=ext4 ip=192.168.1.184:192.168.1.2:192.168.1.254:255.255.255.0::::192.168.1.254:none
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1033660K/1048576K available (3843K kernel code, 200K rwdata, 1268K rodata, 187K init, 231K bss, 14916K reserved, 270336K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
    lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc0505fb0   (5112 kB)
      .init : 0xc0506000 - 0xc0534e80   ( 188 kB)
      .data : 0xc0536000 - 0xc05682a0   ( 201 kB)
       .bss : 0xc05682ac - 0xc05a1f18   ( 232 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65536000000000ns
Switching to timer-based delay loop
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 4.80 BogoMIPS (lpj=24000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
missing device node for CPU 0
missing device node for CPU 1
CPU0: thread -1, cpu 0, socket 3, mpidr 80000300
Setting up static identity map for 0x3a52d0 - 0x3a5328
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c5, AUX_CTRL 0x7ec60800, Cache size: 512 kB
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 3, mpidr 80000301
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 2
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
gpio 8012e000.gpio: at address f812e000
gpio 8012e080.gpio: at address f812e080
gpio 8000e000.gpio: at address f800e000
gpio 8000e080.gpio: at address f800e080
gpio 8000e100.gpio: at address f800e100
gpio 8000e180.gpio: at address f800e180
gpio 8011e000.gpio: at address f811e000
gpio 8011e080.gpio: at address f811e080
gpio a03fe000.gpio: at address fa3fe000
pinctrl-nomadik pinctrl-db8500: initialized Nomadik pin control driver
PRCMU firmware: U8500(2), version 3.4.3
ab8500-core ab8500-core.0: detected chip, AB8500 rev. 3.0
ab8500-core ab8500-core.0: switch off cause(s) (0x20): 
 "Battery level lower than power on reset threshold"
ab8500-core ab8500-core.0: turn on reason(s) (0x20): 
"Vbus Detect (USB)" 
abx500-gpio pinctrl-ab8500.0: added gpiochip
abx500-gpio pinctrl-ab8500.0: registered pin controller
abx500-gpio pinctrl-ab8500.0: initialized abx500 pinctrl driver
DB8500 PRCMU initialized
db8500-vape: no parameters
db8500-varm: no parameters
db8500-vmodem: no parameters
db8500-vpll: no parameters
db8500-vsmps1: no parameters
db8500-vsmps2: no parameters
db8500-vsmps3: no parameters
db8500-vrf1: no parameters
db8500-sva-mmdsp: no parameters
db8500-sva-mmdsp-ret: no parameters
db8500-sva-pipe: no parameters
db8500-sia-mmdsp: no parameters
db8500-sia-mmdsp-ret: no parameters
db8500-sia-pipe: no parameters
db8500-sga: no parameters
db8500-b2r2-mcde: no parameters
db8500-esram12: no parameters
db8500-esram12-ret: no parameters
db8500-esram34: no parameters
db8500-esram34-ret: no parameters
Serial: AMBA PL011 UART driver
80120000.uart: ttyAMA0 at MMIO 0x80120000 (irq = 43, base_baud = 0) is a PL011 rev3
80121000.uart: ttyAMA1 at MMIO 0x80121000 (irq = 51, base_baud = 0) is a PL011 rev3
80007000.uart: ttyAMA2 at MMIO 0x80007000 (irq = 58, base_baud = 0) is a PL011 rev3
console [ttyAMA2] enabled
abx500-clk abx500-clk.0: register clocks for ab850x
bio: create slab <bio-0> at 0
dma40 801c0000.dma-controller: hardware rev: 3 @ 0x801c0000 with 8 physical and 256 logical channels
dma40 801c0000.dma-controller: 7 of 8 physical DMA channels available
dma40 801c0000.dma-controller: [d40_phy_res_init] INFO: channel 4 is misconfigured (0)
dma40 801c0000.dma-controller: [d40_phy_res_init] INFO: channel 5 is misconfigured (0)
dma40 801c0000.dma-controller: [d40_phy_res_init] INFO: channel 6 is misconfigured (0)
dma40 801c0000.dma-controller: initialized
en-3v3-fixed-supply: 3300 mV 
ab8500-ext-supply1: 1800 mV 
ab8500-ext-supply2: 1360 mV 
ab8500-ext-supply3: 3400 mV 
V-DISPLAY: 2500 <--> 2900 mV at 2500 mV 
V-DISPLAY: supplied by ab8500-ext-supply3
V-eMMC1: 1100 <--> 3300 mV at 2900 mV 
V-eMMC1: supplied by ab8500-ext-supply3
V-MMC-SD: 1200 <--> 2910 mV at 2910 mV 
V-MMC-SD: supplied by ab8500-ext-supply3
V-INTCORE: at 1250 mV 
V-TVOUT: 2000 mV 
V-AUD: 2000 mV 
V-AMIC1: 2050 mV 
V-AMIC2: 2050 mV 
V-DMIC: 1800 mV 
V-CSI/DSI: 1200 mV 
V-CSI/DSI: Failed to create debugfs directory
mmci-reg: 1800 <--> 2900 mV at 2900 mV 
ssp-pl022 80002000.ssp: ARM PL022 driver, device ID: 0x01080022
ssp-pl022 80002000.ssp: mapped registers from 0x80002000 to f0084000
ssp-pl022 80003000.ssp: ARM PL022 driver, device ID: 0x01080022
ssp-pl022 80003000.ssp: mapped registers from 0x80003000 to f0086000
ssp-pl022 8011a000.spi: ARM PL022 driver, device ID: 0x00080023
ssp-pl022 8011a000.spi: mapped registers from 0x8011a000 to f0088000
ssp-pl022 80112000.spi: ARM PL022 driver, device ID: 0x00080023
ssp-pl022 80112000.spi: mapped registers from 0x80112000 to f008a000
ssp-pl022 80111000.spi: ARM PL022 driver, device ID: 0x00080023
ssp-pl022 80111000.spi: mapped registers from 0x80111000 to f008c000
ssp-pl022 80129000.spi: ARM PL022 driver, device ID: 0x00080023
ssp-pl022 80129000.spi: mapped registers from 0x80129000 to f008e000
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
abx5x0-usb ab8500-usb.0: revision 0x30 driver initialized
nmk-i2c 80004000.i2c: initialize Nomadik I2C at [mem 0x80004000-0x80004fff] on virtual base f0090000
nmk-i2c 80122000.i2c: initialize Nomadik I2C at [mem 0x80122000-0x80122fff] on virtual base f0092000
nmk-i2c 80128000.i2c: initialize Nomadik I2C at [mem 0x80128000-0x80128fff] on virtual base f0094000
nmk-i2c 80110000.i2c: initialize Nomadik I2C at [mem 0x80110000-0x80110fff] on virtual base f0096000
nmk-i2c 8012a000.i2c: initialize Nomadik I2C at [mem 0x8012a000-0x8012afff] on virtual base f0098000
Advanced Linux Sound Architecture Driver Initialized.
Switched to clocksource dbx500-prcmu-timer
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
bounce pool size: 64 pages
msgmni has been set to 1490
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
uart-pl011 80120000.uart: DMA channel TX dma0chan12
uart-pl011 80120000.uart: DMA channel RX dma0chan13
uart-pl011 80121000.uart: DMA channel TX dma0chan14
uart-pl011 80121000.uart: DMA channel RX dma0chan15
uart-pl011 80007000.uart: DMA channel TX dma0chan16
uart-pl011 80007000.uart: DMA channel RX dma0chan17
brd: module loaded
smsc911x: Driver version 2008-10-21
libphy: smsc911x-mdio: probed
smsc911x 50000000.ethernet eth0: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=50000000.etherne:01, irq=-1)
smsc911x 50000000.ethernet eth0: MAC Address: 7e:0d:bd:3b:6b:68
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 5
musb-hdrc: 28/31 max ep, 8192/262144 memory
musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
mousedev: PS/2 mouse device common for all mice
input: AB8500 POn(PowerOn) Key as /devices/soc0/soc.0/db8500-prcmu/ab8500-core.0/ab8500-poweron-key.0/input/input0
ab8500-rtc ab8500-rtc.0: rtc core: registered ab8500-rtc as rtc0
rtc-pl031 80154000.rtc: rtc core: registered pl031 as rtc1
db8500-thermal db8500-thermal.0: Thermal zone device registered.
genirq: Flags mismatch irq 181. 00006000 (dbx500_temp_low) vs. 00006000 (dbx500_temp_low)
db8500-thermal 801573c0.thermal: Failed to allocate temp low irq.
db8500-thermal: probe of 801573c0.thermal failed with error -16
ux500_wdt ux500_wdt: initialized
dbx500-cpufreq: Available frequencies:
  200 Mhz
  400 Mhz
  800 Mhz
  1000 Mhz
mmci-pl18x sdi0: mmc0: PL180 manf 80 rev4 at 0x80126000 irq 92,0 (pio)
mmci-pl18x sdi0: DMA channels RX dma0chan18, TX dma0chan19
mmci-pl18x sdi4: dummy supplies not allowed
mmci-pl18x sdi4: mmc1: PL180 manf 80 rev4 at 0x80114000 irq 131,0 (pio)
mmci-pl18x sdi4: DMA channels RX dma0chan20, TX dma0chan21
hash1 hash1: successfully registered
[ux500_cryp_mod_init] is called!
cryp1 cryp1: [ux500_cryp_probe]
cryp1 cryp1: [cryp_enable_power]
[cryp_algs_register_all]
cryp1 cryp1: successfully registered
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
of_dma_request_slave_channel: dma-names property of node '/soc/msp@80124000' missing or empty
of_dma_request_slave_channel: dma-names property of node '/soc/msp@80124000' missing or empty
of_dma_request_slave_channel: dma-names property of node '/soc/msp@80125000' missing or empty
mmc1: new high speed MMC card at address 0001
of_dma_request_slave_channel: dma-names property of node '/soc/msp@80125000' missing or empty
mmcblk0: mmc1:0001  7.28 GiB 
mmcblk0boot0: mmc1:0001  partition 1 2.00 MiB
mmcblk0boot1: mmc1:0001  partition 2 2.00 MiB
mmcblk0rpmb: mmc1:0001  partition 3 128 KiB
dma dma0chan22: [d40_config_memcpy] No memcpy
dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22
snd-soc-mop500 snd-soc-mop500.0: ASoC: can't create pcm ab8500_0 :-22
snd-soc-mop500 snd-soc-mop500.0: ASoC: failed to instantiate card -22
snd-soc-mop500 snd-soc-mop500.0: Error: snd_soc_register_card failed (-22)!
snd-soc-mop500: probe of snd-soc-mop500.0 failed with error -22
TCP: cubic registered
NET: Registered protocol family 17
 mmcblk0: p1 p2 p3
NET: Registered protocol family 35
NET: Registered protocol family 37
Registering SWP/SWPB emulation handler
V-CSI/DSI: disabling
db8500-esram34: disabling
db8500-esram12: disabling
input: gpio_keys.8 as /devices/soc0/gpio_keys.8/input/input1
ab8500-rtc ab8500-rtc.0: setting system clock to 2000-01-01 00:00:16 UTC (946684816)
thermal cooling_device0: thermal-cpufreq-0 bind to 0: 0-succeed
 mmcblk0boot1: unknown partition table
thermal cooling_device0: thermal-cpufreq-0 bind to 1: 0-succeed
thermal cooling_device0: thermal-cpufreq-0 bind to 2: 0-succeed
db8500-cpufreq-cooling cpufreq-cooling.5: Cooling device registered: thermal-cpufreq-0
 mmcblk0boot0: unknown partition table
smsc911x 50000000.ethernet eth0: SMSC911x/921x identified at 0xf00a0000, IRQ: 183
IP-Config: Complete:
     device=eth0, hwaddr=7e:0d:bd:3b:6b:68, ipaddr=192.168.1.184, mask=255.255.255.0, gw=192.168.1.254
     host=192.168.1.184, domain=, nis-domain=(none)
     bootserver=192.168.1.2, rootserver=192.168.1.2, rootpath=
     nameserver0=192.168.1.254, nameserver1=109.0.0.0
ALSA device list:
  No soundcards found.
random: nonblocking pool is initialized
EXT4-fs (mmcblk0p3): warning: maximal mount count reached, running e2fsck is recommended
EXT4-fs (mmcblk0p3): recovery complete
EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 179:3.
devtmpfs: mounted
Freeing unused kernel memory: 184K (c0506000 - c0534000)
mmci-pl18x sdi4: error during DMA transfer!
mmcblk0rpmb: error -110 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
mmcblk0rpmb: retrying using single block read
mmci-pl18x sdi4: error during DMA transfer!
mmcblk0rpmb: error -110 transferring data, sector 64, nr 8, cmd response 0x900, card status 0x0
mmcblk0rpmb: retrying using single block read
mmci-pl18x sdi4: error during DMA transfer!
mmcblk0rpmb: error -110 transferring data, sector 16, nr 8, cmd response 0x900, card status 0x0
mmcblk0rpmb: retrying using single block read
mmci-pl18x sdi4: error during DMA transfer!
mmcblk0rpmb: error -110 transferring data, sector 128, nr 8, cmd response 0x900, card status 0x0
mmcblk0rpmb: retrying using single block read
mmci-pl18x sdi4: error during DMA transfer!
mmcblk0rpmb: error -110 transferring data, sector 24, nr 8, cmd response 0x900, card status 0x0
mmcblk0rpmb: retrying using single block read
mmci-pl18x sdi4: error during DMA transfer!
mmcblk0rpmb: error -110 transferring data, sector 32, nr 8, cmd response 0x900, card status 0x0
mmcblk0rpmb: retrying using single block read
mmci-pl18x sdi4: error during DMA transfer!
mmcblk0rpmb: error -110 transferring data, sector 8, nr 8, cmd response 0x900, card status 0x0
mmcblk0rpmb: retrying using single block read
~$off
# PYBOOT: Exception: userspace: ERROR: Never found root shell
# PYBOOT: Time: 44.48 seconds.
# PYBOOT: Result: FAIL

[PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Kevin Hilman]

On Tue, Nov 19, 2013 at 3:07 AM, Lee Jones <lee.jones@linaro.org> wrote:
> In this patch we do two things. Firstly, instead of open coding the
> store of DMA data in to the DAI for later use, we use the API provided.
> Secondly we create and store similar DMA data for the DT case, only
> this time we use 'struct snd_dmaengine_dai_dma_data' which is provided
> by the core for this very reason.
>
> Cc: alsa-devel at alsa-project.org
> Cc: Mark Brown <broonie@kernel.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  sound/soc/ux500/ux500_msp_dai.c | 42 +++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 40 insertions(+), 2 deletions(-)

Today's next (next-20131204) has a new boot failure[1] on
ux500/snowball which bisected down to this commit.  Full boot log
attached.

It doesn't find the alsa device which in turn seems to prevent the
emmc rootfs from being mounted.  It boots fine to an initramfs.

Kevin

[1] http://lists.linaro.org/pipermail/kernel-build-reports/2013-December/001382.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boot-snowball.log
Type: text/x-log
Size: 18759 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131204/88b1b30c/attachment-0001.bin>

Re: [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

> Today's next (next-20131204) has a new boot failure[1] on
> ux500/snowball which bisected down to this commit.  Full boot log
> attached.

Right.

Anyone not on CC (which I think you are Kevin) can follow the fun here:
  http://www.spinics.net/lists/arm-kernel/msg291374.html

> It doesn't find the alsa device which in turn seems to prevent the
> emmc rootfs from being mounted.  It boots fine to an initramfs.

<snip>

> of_dma_request_slave_channel: dma-names property of node '/soc/msp@80124000' missing or empty
> of_dma_request_slave_channel: dma-names property of node '/soc/msp@80124000' missing or empty
> of_dma_request_slave_channel: dma-names property of node '/soc/msp@80125000' missing or empty
> mmc1: new high speed MMC card at address 0001
> of_dma_request_slave_channel: dma-names property of node '/soc/msp@80125000' missing or empty
> mmcblk0: mmc1:0001  7.28 GiB 
> mmcblk0boot0: mmc1:0001  partition 1 2.00 MiB
> mmcblk0boot1: mmc1:0001  partition 2 2.00 MiB
> mmcblk0rpmb: mmc1:0001  partition 3 128 KiB
> dma dma0chan22: [d40_config_memcpy] No memcpy
> dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
> ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
> ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22
> snd-soc-mop500 snd-soc-mop500.0: ASoC: can't create pcm ab8500_0 :-22
> snd-soc-mop500 snd-soc-mop500.0: ASoC: failed to instantiate card -22
> snd-soc-mop500 snd-soc-mop500.0: Error: snd_soc_register_card failed (-22)!
> snd-soc-mop500: probe of snd-soc-mop500.0 failed with error -22

<snip>

> mmci-pl18x sdi4: error during DMA transfer!
> mmcblk0rpmb: error -110 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
> mmcblk0rpmb: retrying using single block read

It's interesting that the MSP failure has managed to fudge the entire
DMA Controller. I have absolutely no idea how that can even happen?


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

Re: [PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

> Today's next (next-20131204) has a new boot failure[1] on
> ux500/snowball which bisected down to this commit.  Full boot log
> attached.

Right.

Anyone not on CC (which I think you are Kevin) can follow the fun here:
  http://www.spinics.net/lists/arm-kernel/msg291374.html

> It doesn't find the alsa device which in turn seems to prevent the
> emmc rootfs from being mounted.  It boots fine to an initramfs.

<snip>

> of_dma_request_slave_channel: dma-names property of node '/soc/msp@80124000' missing or empty
> of_dma_request_slave_channel: dma-names property of node '/soc/msp@80124000' missing or empty
> of_dma_request_slave_channel: dma-names property of node '/soc/msp@80125000' missing or empty
> mmc1: new high speed MMC card at address 0001
> of_dma_request_slave_channel: dma-names property of node '/soc/msp@80125000' missing or empty
> mmcblk0: mmc1:0001  7.28 GiB 
> mmcblk0boot0: mmc1:0001  partition 1 2.00 MiB
> mmcblk0boot1: mmc1:0001  partition 2 2.00 MiB
> mmcblk0rpmb: mmc1:0001  partition 3 128 KiB
> dma dma0chan22: [d40_config_memcpy] No memcpy
> dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
> ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
> ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22
> snd-soc-mop500 snd-soc-mop500.0: ASoC: can't create pcm ab8500_0 :-22
> snd-soc-mop500 snd-soc-mop500.0: ASoC: failed to instantiate card -22
> snd-soc-mop500 snd-soc-mop500.0: Error: snd_soc_register_card failed (-22)!
> snd-soc-mop500: probe of snd-soc-mop500.0 failed with error -22

<snip>

> mmci-pl18x sdi4: error during DMA transfer!
> mmcblk0rpmb: error -110 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
> mmcblk0rpmb: retrying using single block read

It's interesting that the MSP failure has managed to fudge the entire
DMA Controller. I have absolutely no idea how that can even happen?


-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[PATCH 07/10] ASoC: ux500: Store DMA data in the DAI differently in the pdata and DT case

[Lee Jones]

> Today's next (next-20131204) has a new boot failure[1] on
> ux500/snowball which bisected down to this commit.  Full boot log
> attached.

Right.

Anyone not on CC (which I think you are Kevin) can follow the fun here:
  http://www.spinics.net/lists/arm-kernel/msg291374.html

> It doesn't find the alsa device which in turn seems to prevent the
> emmc rootfs from being mounted.  It boots fine to an initramfs.

<snip>

> of_dma_request_slave_channel: dma-names property of node '/soc/msp at 80124000' missing or empty
> of_dma_request_slave_channel: dma-names property of node '/soc/msp at 80124000' missing or empty
> of_dma_request_slave_channel: dma-names property of node '/soc/msp at 80125000' missing or empty
> mmc1: new high speed MMC card at address 0001
> of_dma_request_slave_channel: dma-names property of node '/soc/msp at 80125000' missing or empty
> mmcblk0: mmc1:0001  7.28 GiB 
> mmcblk0boot0: mmc1:0001  partition 1 2.00 MiB
> mmcblk0boot1: mmc1:0001  partition 2 2.00 MiB
> mmcblk0rpmb: mmc1:0001  partition 3 128 KiB
> dma dma0chan22: [d40_config_memcpy] No memcpy
> dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
> ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
> ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22
> snd-soc-mop500 snd-soc-mop500.0: ASoC: can't create pcm ab8500_0 :-22
> snd-soc-mop500 snd-soc-mop500.0: ASoC: failed to instantiate card -22
> snd-soc-mop500 snd-soc-mop500.0: Error: snd_soc_register_card failed (-22)!
> snd-soc-mop500: probe of snd-soc-mop500.0 failed with error -22

<snip>

> mmci-pl18x sdi4: error during DMA transfer!
> mmcblk0rpmb: error -110 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
> mmcblk0rpmb: retrying using single block read

It's interesting that the MSP failure has managed to fudge the entire
DMA Controller. I have absolutely no idea how that can even happen?


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