[PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration

[PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration

[Shawn Guo]

I have been working on -rc recently, and have not noticed the failure
until I ran next tree today.  The mxs-mmc driver is broken on next
tree because the DMA_NONE was left over from the dma_transfer_direction
migration for mxs-dma and its client drivers.

This seires is trying to fix it up.

Huang Shijie (1):
      mtd: fix compile error for gpmi-nand

Shawn Guo (3):
      dmaengine: add DMA_TRANS_NONE to dma_transfer_direction
      mmc: mxs-mmc: fix the dma_transfer_direction migration
      mtd: gpmi-nand: move to dma_transfer_direction

 drivers/dma/mxs-dma.c                 |    2 +-
 drivers/mmc/host/mxs-mmc.c            |    3 +
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c |   22 ++++++-----
 include/linux/dmaengine.h             |    1 +
 include/linux/mtd/gpmi-nand.h         |   68 +++++++++++++++++++++++++++++++++
 5 files changed, 85 insertions(+), 11 deletions(-)

[PATCH 1/4] dmaengine: add DMA_TRANS_NONE to dma_transfer_direction

[Shawn Guo]

Before dma_transfer_direction was introduced to replace
dma_data_direction, some dmaengine device uses DMA_NONE of
dma_data_direction for some talk with its client drivers.
The mxs-dma and its clients mxs-mmc and gpmi-nand are such case.

This patch adds DMA_TRANS_NONE to dma_transfer_direction and
migrate the DMA_NONE use in mxs-dma to it.

It also fixes the compile warning below.

CC      drivers/dma/mxs-dma.o
drivers/dma/mxs-dma.c: In function ‘mxs_dma_prep_slave_sg’:
drivers/dma/mxs-dma.c:420:16: warning: comparison between ‘enum dma_transfer_direction’ and ‘enum dma_data_direction’

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 drivers/dma/mxs-dma.c     |    2 +-
 include/linux/dmaengine.h |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index bdf4672..ff89211 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -417,7 +417,7 @@ static struct dma_async_tx_descriptor *mxs_dma_prep_slave_sg(
 		idx = 0;
 	}
 
-	if (direction == DMA_NONE) {
+	if (direction == DMA_TRANS_NONE) {
 		ccw = &mxs_chan->ccw[idx++];
 		pio = (u32 *) sgl;
 
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 5532bb8..679b349 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -88,6 +88,7 @@ enum dma_transfer_direction {
 	DMA_MEM_TO_DEV,
 	DMA_DEV_TO_MEM,
 	DMA_DEV_TO_DEV,
+	DMA_TRANS_NONE,
 };
 
 /**
-- 
1.7.4.1

[PATCH 2/4] mmc: mxs-mmc: fix the dma_transfer_direction migration

[Shawn Guo]

The commit 05f5799 (mmc-host: move to dma_transfer_direction) left out
the DMA_NONE, in turn breaks the driver as below.

[    0.650000] mxs-mmc mxs-mmc.0: initialized
[    0.650000] mxs-mmc mxs-mmc.1: initialized
[    0.690000] mxs-dma mxs-dma-apbh: maximum bytes for sg entry exceeded: -55906
7475 > 65280
[    0.690000] mxs-mmc mxs-mmc.0: mxs_mmc_ac: failed to prep dma

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 drivers/mmc/host/mxs-mmc.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 571c9ff..93c18aa 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -357,6 +357,7 @@ static void mxs_mmc_bc(struct mxs_mmc_host *host)
 	host->ssp_pio_words[1] = cmd0;
 	host->ssp_pio_words[2] = cmd1;
 	host->dma_dir = DMA_NONE;
+	host->slave_dirn = DMA_TRANS_NONE;
 	desc = mxs_mmc_prep_dma(host, 0);
 	if (!desc)
 		goto out;
@@ -396,6 +397,7 @@ static void mxs_mmc_ac(struct mxs_mmc_host *host)
 	host->ssp_pio_words[1] = cmd0;
 	host->ssp_pio_words[2] = cmd1;
 	host->dma_dir = DMA_NONE;
+	host->slave_dirn = DMA_TRANS_NONE;
 	desc = mxs_mmc_prep_dma(host, 0);
 	if (!desc)
 		goto out;
@@ -514,6 +516,7 @@ static void mxs_mmc_adtc(struct mxs_mmc_host *host)
 	host->ssp_pio_words[1] = cmd0;
 	host->ssp_pio_words[2] = cmd1;
 	host->dma_dir = DMA_NONE;
+	host->slave_dirn = DMA_TRANS_NONE;
 	desc = mxs_mmc_prep_dma(host, 0);
 	if (!desc)
 		goto out;
-- 
1.7.4.1

[PATCH 3/4] mtd: fix compile error for gpmi-nand

[Shawn Guo]

From: Huang Shijie <b32955@freescale.com>

The driver gpmi-nand should compile at least.  This patch adds the
missing gpmi-nand.h to fix the compile error below.

  CC      drivers/mtd/nand/gpmi-nand/gpmi-nand.o
  CC      drivers/mtd/nand/gpmi-nand/gpmi-lib.o
drivers/mtd/nand/gpmi-nand/gpmi-nand.c:25:33: fatal error: linux/mtd/gpmi-nand.h: No such file or directory
drivers/mtd/nand/gpmi-nand/gpmi-lib.c:21:33: fatal error: linux/mtd/gpmi-nand.h: No such file or directory

This header is grabbed from patch below, which has not been postponed
for merging.

  [PATCH v8 1/4] ARM: mxs: add GPMI-NAND support for imx23/imx28
  http://permalink.gmane.org/gmane.linux.drivers.mtd/37338

Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 include/linux/mtd/gpmi-nand.h |   68 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 68 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/mtd/gpmi-nand.h

diff --git a/include/linux/mtd/gpmi-nand.h b/include/linux/mtd/gpmi-nand.h
new file mode 100644
index 0000000..69b6dbf
--- /dev/null
+++ b/include/linux/mtd/gpmi-nand.h
@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#ifndef __MACH_MXS_GPMI_NAND_H__
+#define __MACH_MXS_GPMI_NAND_H__
+
+/* The size of the resources is fixed. */
+#define GPMI_NAND_RES_SIZE	6
+
+/* Resource names for the GPMI NAND driver. */
+#define GPMI_NAND_GPMI_REGS_ADDR_RES_NAME  "GPMI NAND GPMI Registers"
+#define GPMI_NAND_GPMI_INTERRUPT_RES_NAME  "GPMI NAND GPMI Interrupt"
+#define GPMI_NAND_BCH_REGS_ADDR_RES_NAME   "GPMI NAND BCH Registers"
+#define GPMI_NAND_BCH_INTERRUPT_RES_NAME   "GPMI NAND BCH Interrupt"
+#define GPMI_NAND_DMA_CHANNELS_RES_NAME    "GPMI NAND DMA Channels"
+#define GPMI_NAND_DMA_INTERRUPT_RES_NAME   "GPMI NAND DMA Interrupt"
+
+/**
+ * struct gpmi_nand_platform_data - GPMI NAND driver platform data.
+ *
+ * This structure communicates platform-specific information to the GPMI NAND
+ * driver that can't be expressed as resources.
+ *
+ * @platform_init:           A pointer to a function the driver will call to
+ *                           initialize the platform (e.g., set up the pin mux).
+ * @min_prop_delay_in_ns:    Minimum propagation delay of GPMI signals to and
+ *                           from the NAND Flash device, in nanoseconds.
+ * @max_prop_delay_in_ns:    Maximum propagation delay of GPMI signals to and
+ *                           from the NAND Flash device, in nanoseconds.
+ * @max_chip_count:          The maximum number of chips for which the driver
+ *                           should configure the hardware. This value most
+ *                           likely reflects the number of pins that are
+ *                           connected to a NAND Flash device. If this is
+ *                           greater than the SoC hardware can support, the
+ *                           driver will print a message and fail to initialize.
+ * @partitions:              An optional pointer to an array of partition
+ *                           descriptions.
+ * @partition_count:         The number of elements in the partitions array.
+ */
+struct gpmi_nand_platform_data {
+	/* SoC hardware information. */
+	int		(*platform_init)(void);
+
+	/* NAND Flash information. */
+	unsigned int	min_prop_delay_in_ns;
+	unsigned int	max_prop_delay_in_ns;
+	unsigned int	max_chip_count;
+
+	/* Medium information. */
+	struct		mtd_partition *partitions;
+	unsigned	partition_count;
+};
+#endif
-- 
1.7.4.1

[PATCH 4/4] mtd: gpmi-nand: move to dma_transfer_direction

[Shawn Guo]

This patch fixes usage of dma direction to adopt dma_transfer_direction.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c |   22 ++++++++++++----------
 1 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index de4db76..c4c4d6d 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -827,7 +827,7 @@ int gpmi_send_command(struct gpmi_nand_data *this)
 	pio[1] = pio[2] = 0;
 	desc = channel->device->device_prep_slave_sg(channel,
 					(struct scatterlist *)pio,
-					ARRAY_SIZE(pio), DMA_NONE, 0);
+					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
 	if (!desc) {
 		pr_err("step 1 error\n");
 		return -1;
@@ -839,7 +839,7 @@ int gpmi_send_command(struct gpmi_nand_data *this)
 	sg_init_one(sgl, this->cmd_buffer, this->command_length);
 	dma_map_sg(this->dev, sgl, 1, DMA_TO_DEVICE);
 	desc = channel->device->device_prep_slave_sg(channel,
-					sgl, 1, DMA_TO_DEVICE, 1);
+					sgl, 1, DMA_MEM_TO_DEV, 1);
 	if (!desc) {
 		pr_err("step 2 error\n");
 		return -1;
@@ -872,7 +872,7 @@ int gpmi_send_data(struct gpmi_nand_data *this)
 	pio[1] = 0;
 	desc = channel->device->device_prep_slave_sg(channel,
 					(struct scatterlist *)pio,
-					ARRAY_SIZE(pio), DMA_NONE, 0);
+					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
 	if (!desc) {
 		pr_err("step 1 error\n");
 		return -1;
@@ -881,7 +881,7 @@ int gpmi_send_data(struct gpmi_nand_data *this)
 	/* [2] send DMA request */
 	prepare_data_dma(this, DMA_TO_DEVICE);
 	desc = channel->device->device_prep_slave_sg(channel, &this->data_sgl,
-						1, DMA_TO_DEVICE, 1);
+						1, DMA_MEM_TO_DEV, 1);
 	if (!desc) {
 		pr_err("step 2 error\n");
 		return -1;
@@ -908,7 +908,7 @@ int gpmi_read_data(struct gpmi_nand_data *this)
 	pio[1] = 0;
 	desc = channel->device->device_prep_slave_sg(channel,
 					(struct scatterlist *)pio,
-					ARRAY_SIZE(pio), DMA_NONE, 0);
+					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
 	if (!desc) {
 		pr_err("step 1 error\n");
 		return -1;
@@ -917,7 +917,7 @@ int gpmi_read_data(struct gpmi_nand_data *this)
 	/* [2] : send DMA request */
 	prepare_data_dma(this, DMA_FROM_DEVICE);
 	desc = channel->device->device_prep_slave_sg(channel, &this->data_sgl,
-						1, DMA_FROM_DEVICE, 1);
+						1, DMA_DEV_TO_MEM, 1);
 	if (!desc) {
 		pr_err("step 2 error\n");
 		return -1;
@@ -964,7 +964,7 @@ int gpmi_send_page(struct gpmi_nand_data *this,
 
 	desc = channel->device->device_prep_slave_sg(channel,
 					(struct scatterlist *)pio,
-					ARRAY_SIZE(pio), DMA_NONE, 0);
+					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
 	if (!desc) {
 		pr_err("step 2 error\n");
 		return -1;
@@ -998,7 +998,8 @@ int gpmi_read_page(struct gpmi_nand_data *this,
 		| BF_GPMI_CTRL0_XFER_COUNT(0);
 	pio[1] = 0;
 	desc = channel->device->device_prep_slave_sg(channel,
-				(struct scatterlist *)pio, 2, DMA_NONE, 0);
+				(struct scatterlist *)pio, 2,
+				DMA_TRANS_NONE, 0);
 	if (!desc) {
 		pr_err("step 1 error\n");
 		return -1;
@@ -1027,7 +1028,7 @@ int gpmi_read_page(struct gpmi_nand_data *this,
 	pio[5] = auxiliary;
 	desc = channel->device->device_prep_slave_sg(channel,
 					(struct scatterlist *)pio,
-					ARRAY_SIZE(pio), DMA_NONE, 1);
+					ARRAY_SIZE(pio), DMA_TRANS_NONE, 1);
 	if (!desc) {
 		pr_err("step 2 error\n");
 		return -1;
@@ -1045,7 +1046,8 @@ int gpmi_read_page(struct gpmi_nand_data *this,
 		| BF_GPMI_CTRL0_XFER_COUNT(geo->page_size);
 	pio[1] = 0;
 	desc = channel->device->device_prep_slave_sg(channel,
-				(struct scatterlist *)pio, 2, DMA_NONE, 1);
+				(struct scatterlist *)pio, 2,
+				DMA_TRANS_NONE, 1);
 	if (!desc) {
 		pr_err("step 3 error\n");
 		return -1;
-- 
1.7.4.1

Re: [PATCH 4/4] mtd: gpmi-nand: move to dma_transfer_direction

[Huang Shijie]

于 2011年12月13日 23:48, Shawn Guo 写道:
> This patch fixes usage of dma direction to adopt dma_transfer_direction.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c |   22 ++++++++++++----------
>  1 files changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> index de4db76..c4c4d6d 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> @@ -827,7 +827,7 @@ int gpmi_send_command(struct gpmi_nand_data *this)
>  	pio[1] = pio[2] = 0;
>  	desc = channel->device->device_prep_slave_sg(channel,
>  					(struct scatterlist *)pio,
> -					ARRAY_SIZE(pio), DMA_NONE, 0);
> +					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
>  	if (!desc) {
>  		pr_err("step 1 error\n");
>  		return -1;
> @@ -839,7 +839,7 @@ int gpmi_send_command(struct gpmi_nand_data *this)
>  	sg_init_one(sgl, this->cmd_buffer, this->command_length);
>  	dma_map_sg(this->dev, sgl, 1, DMA_TO_DEVICE);
>  	desc = channel->device->device_prep_slave_sg(channel,
> -					sgl, 1, DMA_TO_DEVICE, 1);
> +					sgl, 1, DMA_MEM_TO_DEV, 1);
>  	if (!desc) {
>  		pr_err("step 2 error\n");
>  		return -1;
> @@ -872,7 +872,7 @@ int gpmi_send_data(struct gpmi_nand_data *this)
>  	pio[1] = 0;
>  	desc = channel->device->device_prep_slave_sg(channel,
>  					(struct scatterlist *)pio,
> -					ARRAY_SIZE(pio), DMA_NONE, 0);
> +					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
>  	if (!desc) {
>  		pr_err("step 1 error\n");
>  		return -1;
> @@ -881,7 +881,7 @@ int gpmi_send_data(struct gpmi_nand_data *this)
>  	/* [2] send DMA request */
>  	prepare_data_dma(this, DMA_TO_DEVICE);
>  	desc = channel->device->device_prep_slave_sg(channel, &this->data_sgl,
> -						1, DMA_TO_DEVICE, 1);
> +						1, DMA_MEM_TO_DEV, 1);
>  	if (!desc) {
>  		pr_err("step 2 error\n");
>  		return -1;
> @@ -908,7 +908,7 @@ int gpmi_read_data(struct gpmi_nand_data *this)
>  	pio[1] = 0;
>  	desc = channel->device->device_prep_slave_sg(channel,
>  					(struct scatterlist *)pio,
> -					ARRAY_SIZE(pio), DMA_NONE, 0);
> +					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
>  	if (!desc) {
>  		pr_err("step 1 error\n");
>  		return -1;
> @@ -917,7 +917,7 @@ int gpmi_read_data(struct gpmi_nand_data *this)
>  	/* [2] : send DMA request */
>  	prepare_data_dma(this, DMA_FROM_DEVICE);
>  	desc = channel->device->device_prep_slave_sg(channel, &this->data_sgl,
> -						1, DMA_FROM_DEVICE, 1);
> +						1, DMA_DEV_TO_MEM, 1);
>  	if (!desc) {
>  		pr_err("step 2 error\n");
>  		return -1;
> @@ -964,7 +964,7 @@ int gpmi_send_page(struct gpmi_nand_data *this,
>  
>  	desc = channel->device->device_prep_slave_sg(channel,
>  					(struct scatterlist *)pio,
> -					ARRAY_SIZE(pio), DMA_NONE, 0);
> +					ARRAY_SIZE(pio), DMA_TRANS_NONE, 0);
>  	if (!desc) {
>  		pr_err("step 2 error\n");
>  		return -1;
> @@ -998,7 +998,8 @@ int gpmi_read_page(struct gpmi_nand_data *this,
>  		| BF_GPMI_CTRL0_XFER_COUNT(0);
>  	pio[1] = 0;
>  	desc = channel->device->device_prep_slave_sg(channel,
> -				(struct scatterlist *)pio, 2, DMA_NONE, 0);
> +				(struct scatterlist *)pio, 2,
> +				DMA_TRANS_NONE, 0);
>  	if (!desc) {
>  		pr_err("step 1 error\n");
>  		return -1;
> @@ -1027,7 +1028,7 @@ int gpmi_read_page(struct gpmi_nand_data *this,
>  	pio[5] = auxiliary;
>  	desc = channel->device->device_prep_slave_sg(channel,
>  					(struct scatterlist *)pio,
> -					ARRAY_SIZE(pio), DMA_NONE, 1);
> +					ARRAY_SIZE(pio), DMA_TRANS_NONE, 1);
>  	if (!desc) {
>  		pr_err("step 2 error\n");
>  		return -1;
> @@ -1045,7 +1046,8 @@ int gpmi_read_page(struct gpmi_nand_data *this,
>  		| BF_GPMI_CTRL0_XFER_COUNT(geo->page_size);
>  	pio[1] = 0;
>  	desc = channel->device->device_prep_slave_sg(channel,
> -				(struct scatterlist *)pio, 2, DMA_NONE, 1);
> +				(struct scatterlist *)pio, 2,
> +				DMA_TRANS_NONE, 1);
>  	if (!desc) {
>  		pr_err("step 3 error\n");
>  		return -1;
It's ok to me.

Re: [PATCH 3/4] mtd: fix compile error for gpmi-nand

[Huang Shijie]

于 2011年12月13日 23:48, Shawn Guo 写道:
> From: Huang Shijie <b32955@freescale.com>
>
> The driver gpmi-nand should compile at least.  This patch adds the
> missing gpmi-nand.h to fix the compile error below.
>
>   CC      drivers/mtd/nand/gpmi-nand/gpmi-nand.o
>   CC      drivers/mtd/nand/gpmi-nand/gpmi-lib.o
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c:25:33: fatal error: linux/mtd/gpmi-nand.h: No such file or directory
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c:21:33: fatal error: linux/mtd/gpmi-nand.h: No such file or directory
>
> This header is grabbed from patch below, which has not been postponed
> for merging.
>
>   [PATCH v8 1/4] ARM: mxs: add GPMI-NAND support for imx23/imx28
>   http://permalink.gmane.org/gmane.linux.drivers.mtd/37338
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
>  include/linux/mtd/gpmi-nand.h |   68 +++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 68 insertions(+), 0 deletions(-)
>  create mode 100644 include/linux/mtd/gpmi-nand.h
>
> diff --git a/include/linux/mtd/gpmi-nand.h b/include/linux/mtd/gpmi-nand.h
> new file mode 100644
> index 0000000..69b6dbf
> --- /dev/null
> +++ b/include/linux/mtd/gpmi-nand.h
> @@ -0,0 +1,68 @@
> +/*
> + * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +#ifndef __MACH_MXS_GPMI_NAND_H__
> +#define __MACH_MXS_GPMI_NAND_H__
> +
> +/* The size of the resources is fixed. */
> +#define GPMI_NAND_RES_SIZE	6
> +
> +/* Resource names for the GPMI NAND driver. */
> +#define GPMI_NAND_GPMI_REGS_ADDR_RES_NAME  "GPMI NAND GPMI Registers"
> +#define GPMI_NAND_GPMI_INTERRUPT_RES_NAME  "GPMI NAND GPMI Interrupt"
> +#define GPMI_NAND_BCH_REGS_ADDR_RES_NAME   "GPMI NAND BCH Registers"
> +#define GPMI_NAND_BCH_INTERRUPT_RES_NAME   "GPMI NAND BCH Interrupt"
> +#define GPMI_NAND_DMA_CHANNELS_RES_NAME    "GPMI NAND DMA Channels"
> +#define GPMI_NAND_DMA_INTERRUPT_RES_NAME   "GPMI NAND DMA Interrupt"
> +
> +/**
> + * struct gpmi_nand_platform_data - GPMI NAND driver platform data.
> + *
> + * This structure communicates platform-specific information to the GPMI NAND
> + * driver that can't be expressed as resources.
> + *
> + * @platform_init:           A pointer to a function the driver will call to
> + *                           initialize the platform (e.g., set up the pin mux).
> + * @min_prop_delay_in_ns:    Minimum propagation delay of GPMI signals to and
> + *                           from the NAND Flash device, in nanoseconds.
> + * @max_prop_delay_in_ns:    Maximum propagation delay of GPMI signals to and
> + *                           from the NAND Flash device, in nanoseconds.
> + * @max_chip_count:          The maximum number of chips for which the driver
> + *                           should configure the hardware. This value most
> + *                           likely reflects the number of pins that are
> + *                           connected to a NAND Flash device. If this is
> + *                           greater than the SoC hardware can support, the
> + *                           driver will print a message and fail to initialize.
> + * @partitions:              An optional pointer to an array of partition
> + *                           descriptions.
> + * @partition_count:         The number of elements in the partitions array.
> + */
> +struct gpmi_nand_platform_data {
> +	/* SoC hardware information. */
> +	int		(*platform_init)(void);
> +
> +	/* NAND Flash information. */
> +	unsigned int	min_prop_delay_in_ns;
> +	unsigned int	max_prop_delay_in_ns;
> +	unsigned int	max_chip_count;
> +
> +	/* Medium information. */
> +	struct		mtd_partition *partitions;
> +	unsigned	partition_count;
> +};
> +#endif
thanks a lot.

Huang Shijie

[PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic

[Shawn Guo]

The commit 49920bc (dmaengine: add new enum dma_transfer_direction)
changes the type of parameter 'direction' of device_prep_dma_cyclic
from dma_data_direction to dma_transfer_direction.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 sound/soc/mxs/mxs-pcm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sound/soc/mxs/mxs-pcm.c b/sound/soc/mxs/mxs-pcm.c
index 0e12f4e..105f42a 100644
--- a/sound/soc/mxs/mxs-pcm.c
+++ b/sound/soc/mxs/mxs-pcm.c
@@ -136,7 +136,7 @@ static int snd_mxs_pcm_hw_params(struct snd_pcm_substream *substream,
 			iprtd->period_bytes * iprtd->periods,
 			iprtd->period_bytes,
 			substream->stream == SNDRV_PCM_STREAM_PLAYBACK ?
-			DMA_TO_DEVICE : DMA_FROM_DEVICE);
+			DMA_MEM_TO_DEV : DMA_DEV_TO_MEM);
 	if (!iprtd->desc) {
 		dev_err(&chan->dev->device, "cannot prepare slave dma\n");
 		return -EINVAL;
-- 
1.7.4.1

RE: [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic

[Dong Aisheng-B29396]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Shawn Guo
> Sent: Wednesday, December 14, 2011 3:48 PM
> To: Liam Girdwood; Mark Brown
> Cc: Dong Aisheng; alsa-devel@alsa-project.org; linux-
> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Shawn Guo
> Subject: [PATCH 5/5] ASoC: mxs: correct 'direction' of
> device_prep_dma_cyclic
> 
> The commit 49920bc (dmaengine: add new enum dma_transfer_direction)
> changes the type of parameter 'direction' of device_prep_dma_cyclic from
> dma_data_direction to dma_transfer_direction.
> 
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
>  sound/soc/mxs/mxs-pcm.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
Acked-by: Dong Aisheng <dong.aisheng@linaro.org>

Regards
Dong Aisheng

Re: [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic

[Mark Brown]

On Wed, Dec 14, 2011 at 03:47:46PM +0800, Shawn Guo wrote:
> The commit 49920bc (dmaengine: add new enum dma_transfer_direction)
> changes the type of parameter 'direction' of device_prep_dma_cyclic
> from dma_data_direction to dma_transfer_direction.

Applied, thanks.

With patches like this you really need to supply more context - knowing
which release the commit you're talking about appears in is useful for
exammple, as is having some hint as to what the rest of the series is
(does this patch depend on any of the earlier patches, and if not why is
it part of a series).

Re: [alsa-devel] [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic

[Shawn Guo]

On Tue, Dec 20, 2011 at 12:51:01AM +0000, Mark Brown wrote:
> On Wed, Dec 14, 2011 at 03:47:46PM +0800, Shawn Guo wrote:
> > The commit 49920bc (dmaengine: add new enum dma_transfer_direction)
> > changes the type of parameter 'direction' of device_prep_dma_cyclic
> > from dma_data_direction to dma_transfer_direction.
> 
> Applied, thanks.
> 
> With patches like this you really need to supply more context - knowing
> which release the commit you're talking about appears in is useful for
> exammple,

This patch only applies to -next, as the offending patch only sits on
-next.

> as is having some hint as to what the rest of the series is
> (does this patch depend on any of the earlier patches, and if not why is
> it part of a series).

The reason it's in the series is that they are addressing the same
problem.

-- 
Regards,
Shawn

Re: [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration

[Vinod Koul]

On Tue, 2011-12-13 at 23:48 +0800, Shawn Guo wrote:
> I have been working on -rc recently, and have not noticed the failure
> until I ran next tree today.  The mxs-mmc driver is broken on next
> tree because the DMA_NONE was left over from the dma_transfer_direction
> migration for mxs-dma and its client drivers.
> 
For DMA transfer, the NONE direction makes no sense?

In your conetext, what are you trying to achieve?


-- 
~Vinod

Re: [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration

[Shawn Guo]

On Tue, Dec 20, 2011 at 02:54:04PM +0530, Vinod Koul wrote:
> On Tue, 2011-12-13 at 23:48 +0800, Shawn Guo wrote:
> > I have been working on -rc recently, and have not noticed the failure
> > until I ran next tree today.  The mxs-mmc driver is broken on next
> > tree because the DMA_NONE was left over from the dma_transfer_direction
> > migration for mxs-dma and its client drivers.
> > 
> For DMA transfer, the NONE direction makes no sense?
> 
> In your conetext, what are you trying to achieve?
> 
The mxs-dma controller has a feature to program peripheral registers
with given values (mxs-dma PIO mode).  This is designed to pipeline
the operations.  For example, we can put mxs-mmc controller register
values into scatter list as one element together with actual data.
Triggering the mxs-dma, the dma will program the values into mxs-mmc
controller register to set up and enable mxs-mmc, and then dma
continue transfer data from/to mxs-mmc.  All these get done in one
dmaengine_submit().

And DMA_NONE was used to let mxs-dma know this is a PIO operation.

-- 
Regards,
Shawn

Re: [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration

[Vinod Koul]

On Tue, 2011-12-20 at 20:54 +0800, Shawn Guo wrote:
> On Tue, Dec 20, 2011 at 02:54:04PM +0530, Vinod Koul wrote:
> > On Tue, 2011-12-13 at 23:48 +0800, Shawn Guo wrote:
> > > I have been working on -rc recently, and have not noticed the failure
> > > until I ran next tree today.  The mxs-mmc driver is broken on next
> > > tree because the DMA_NONE was left over from the dma_transfer_direction
> > > migration for mxs-dma and its client drivers.
> > > 
> > For DMA transfer, the NONE direction makes no sense?
> > 
> > In your conetext, what are you trying to achieve?
> > 
> The mxs-dma controller has a feature to program peripheral registers
> with given values (mxs-dma PIO mode).  This is designed to pipeline
> the operations.  For example, we can put mxs-mmc controller register
> values into scatter list as one element together with actual data.
> Triggering the mxs-dma, the dma will program the values into mxs-mmc
> controller register to set up and enable mxs-mmc, and then dma
> continue transfer data from/to mxs-mmc.  All these get done in one
> dmaengine_submit().
> 
> And DMA_NONE was used to let mxs-dma know this is a PIO operation.
Sorry am little lost here. Why would DMA driver bother with a PIO mode,
that is something only peripheral driver would know about, mmc in your
case.

So what you are saying is the your dma has the capability to program the
peripheral registers in case of PIO mode, but why wouldn't the
peripheral driver do that instead? 

-- 
~Vinod

Re: [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration

[Vinod Koul]

On Wed, 2011-12-21 at 12:45 +0800, Shawn Guo wrote:
> > 
> The term PIO here may not the one on your mind.  I call it 'mxs-dma
> pio'.  In this mode, mxs-dma hardware can write values into mmc
> controller register without cpu involved.
what do you mean by values here?

-- 
~Vinod

Re: [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration

[Shawn Guo]

On Wed, Dec 21, 2011 at 09:37:04AM +0530, Vinod Koul wrote:
> On Tue, 2011-12-20 at 20:54 +0800, Shawn Guo wrote:
> > On Tue, Dec 20, 2011 at 02:54:04PM +0530, Vinod Koul wrote:
> > > On Tue, 2011-12-13 at 23:48 +0800, Shawn Guo wrote:
> > > > I have been working on -rc recently, and have not noticed the failure
> > > > until I ran next tree today.  The mxs-mmc driver is broken on next
> > > > tree because the DMA_NONE was left over from the dma_transfer_direction
> > > > migration for mxs-dma and its client drivers.
> > > > 
> > > For DMA transfer, the NONE direction makes no sense?
> > > 
> > > In your conetext, what are you trying to achieve?
> > > 
> > The mxs-dma controller has a feature to program peripheral registers
> > with given values (mxs-dma PIO mode).  This is designed to pipeline
> > the operations.  For example, we can put mxs-mmc controller register
> > values into scatter list as one element together with actual data.
> > Triggering the mxs-dma, the dma will program the values into mxs-mmc
> > controller register to set up and enable mxs-mmc, and then dma
> > continue transfer data from/to mxs-mmc.  All these get done in one
> > dmaengine_submit().
> > 
> > And DMA_NONE was used to let mxs-dma know this is a PIO operation.
> Sorry am little lost here. Why would DMA driver bother with a PIO mode,
> that is something only peripheral driver would know about, mmc in your
> case.
> 
The term PIO here may not the one on your mind.  I call it 'mxs-dma
pio'.  In this mode, mxs-dma hardware can write values into mmc
controller register without cpu involved.

> So what you are saying is the your dma has the capability to program the
> peripheral registers in case of PIO mode, but why wouldn't the
> peripheral driver do that instead? 
> 
Yes, I'm saying mxs-dma has the capability to program the peripheral
registers, and that's called 'mxs-dma pio' mode.

-- 
Regards,
Shawn

Re: [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration

[Shawn Guo]

On Wed, Dec 21, 2011 at 10:10:51AM +0530, Vinod Koul wrote:
> On Wed, 2011-12-21 at 12:45 +0800, Shawn Guo wrote:
> > > 
> > The term PIO here may not the one on your mind.  I call it 'mxs-dma
> > pio'.  In this mode, mxs-dma hardware can write values into mmc
> > controller register without cpu involved.
> what do you mean by values here?
> 
The register values that we want to write to mmc controller registers
in this case.

-- 
Regards,
Shawn

Re: [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration

[Vinod Koul]

On Wed, 2011-12-21 at 12:58 +0800, Shawn Guo wrote:
> On Wed, Dec 21, 2011 at 10:10:51AM +0530, Vinod Koul wrote:
> > On Wed, 2011-12-21 at 12:45 +0800, Shawn Guo wrote:
> > > > 
> > > The term PIO here may not the one on your mind.  I call it 'mxs-dma
> > > pio'.  In this mode, mxs-dma hardware can write values into mmc
> > > controller register without cpu involved.
> > what do you mean by values here?
> > 
> The register values that we want to write to mmc controller registers
> in this case.
Okay I am going to put this in my queue as this is fixing a regression
But, I still don't agree that DMA_NONE as a direction is the correct way
to tell dma driver about this. Perhaps we need to find a better
mechanism.


-- 
~Vinod

Re: [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration

[Vinod Koul]

On Tue, 2011-12-13 at 23:48 +0800, Shawn Guo wrote:
> I have been working on -rc recently, and have not noticed the failure
> until I ran next tree today.  The mxs-mmc driver is broken on next
> tree because the DMA_NONE was left over from the dma_transfer_direction
> migration for mxs-dma and its client drivers.
> 
> This seires is trying to fix it up.
Applied, Thanks

> 
> Huang Shijie (1):
>       mtd: fix compile error for gpmi-nand
> 
> Shawn Guo (3):
>       dmaengine: add DMA_TRANS_NONE to dma_transfer_direction
>       mmc: mxs-mmc: fix the dma_transfer_direction migration
>       mtd: gpmi-nand: move to dma_transfer_direction
> 
>  drivers/dma/mxs-dma.c                 |    2 +-
>  drivers/mmc/host/mxs-mmc.c            |    3 +
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c |   22 ++++++-----
>  include/linux/dmaengine.h             |    1 +
>  include/linux/mtd/gpmi-nand.h         |   68 +++++++++++++++++++++++++++++++++
>  5 files changed, 85 insertions(+), 11 deletions(-)
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
~Vinod

Re: [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic

[Vinod Koul]

On Wed, 2011-12-14 at 15:47 +0800, Shawn Guo wrote:
> The commit 49920bc (dmaengine: add new enum dma_transfer_direction)
> changes the type of parameter 'direction' of device_prep_dma_cyclic
> from dma_data_direction to dma_transfer_direction.
> 
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
>  sound/soc/mxs/mxs-pcm.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/sound/soc/mxs/mxs-pcm.c b/sound/soc/mxs/mxs-pcm.c
> index 0e12f4e..105f42a 100644
> --- a/sound/soc/mxs/mxs-pcm.c
> +++ b/sound/soc/mxs/mxs-pcm.c
> @@ -136,7 +136,7 @@ static int snd_mxs_pcm_hw_params(struct snd_pcm_substream *substream,
>  			iprtd->period_bytes * iprtd->periods,
>  			iprtd->period_bytes,
>  			substream->stream == SNDRV_PCM_STREAM_PLAYBACK ?
> -			DMA_TO_DEVICE : DMA_FROM_DEVICE);
> +			DMA_MEM_TO_DEV : DMA_DEV_TO_MEM);
>  	if (!iprtd->desc) {
>  		dev_err(&chan->dev->device, "cannot prepare slave dma\n");
>  		return -EINVAL;

Has this been applied in soc tree? I don't see it in linux-next or do
you want this to go thru slave-dma?

-- 
~Vinod

Re: [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic

[Mark Brown]

On Fri, Dec 23, 2011 at 09:37:00PM +0530, Vinod Koul wrote:

> Has this been applied in soc tree? I don't see it in linux-next or do
> you want this to go thru slave-dma?

I reverted it, it needs to go with the commit that introduces the new
API otherwise it breaks bisection.

Re: [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic

[Vinod Koul]

On Fri, 2011-12-23 at 16:28 +0000, Mark Brown wrote:
> On Fri, Dec 23, 2011 at 09:37:00PM +0530, Vinod Koul wrote:
> 
> > Has this been applied in soc tree? I don't see it in linux-next or do
> > you want this to go thru slave-dma?
> 
> I reverted it, it needs to go with the commit that introduces the new
> API otherwise it breaks bisection.
Okay thanks,

Those are is in my next so I will apply this one to my next as well.

-- 
~Vinod