[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 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 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

[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

[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 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

[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 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 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>

[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 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>

[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 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>

[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

[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

[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>

[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

[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>

[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>

[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

[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 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>

[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

[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

[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>

[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 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>

[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 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>

[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

[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>

[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

[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>