* [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration
@ 2011-12-13 15:48 Shawn Guo
2011-12-13 15:48 ` [PATCH 1/4] dmaengine: add DMA_TRANS_NONE to dma_transfer_direction Shawn Guo
` (6 more replies)
0 siblings, 7 replies; 22+ messages in thread
From: Shawn Guo @ 2011-12-13 15:48 UTC (permalink / raw)
To: linux-arm-kernel
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(-)
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 1/4] dmaengine: add DMA_TRANS_NONE to dma_transfer_direction 2011-12-13 15:48 [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Shawn Guo @ 2011-12-13 15:48 ` Shawn Guo 2011-12-13 15:48 ` [PATCH 2/4] mmc: mxs-mmc: fix the dma_transfer_direction migration Shawn Guo ` (5 subsequent siblings) 6 siblings, 0 replies; 22+ messages in thread From: Shawn Guo @ 2011-12-13 15:48 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 2/4] mmc: mxs-mmc: fix the dma_transfer_direction migration 2011-12-13 15:48 [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Shawn Guo 2011-12-13 15:48 ` [PATCH 1/4] dmaengine: add DMA_TRANS_NONE to dma_transfer_direction Shawn Guo @ 2011-12-13 15:48 ` Shawn Guo 2011-12-13 15:48 ` [PATCH 3/4] mtd: fix compile error for gpmi-nand Shawn Guo ` (4 subsequent siblings) 6 siblings, 0 replies; 22+ messages in thread From: Shawn Guo @ 2011-12-13 15:48 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 3/4] mtd: fix compile error for gpmi-nand 2011-12-13 15:48 [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Shawn Guo 2011-12-13 15:48 ` [PATCH 1/4] dmaengine: add DMA_TRANS_NONE to dma_transfer_direction Shawn Guo 2011-12-13 15:48 ` [PATCH 2/4] mmc: mxs-mmc: fix the dma_transfer_direction migration Shawn Guo @ 2011-12-13 15:48 ` Shawn Guo 2011-12-14 2:21 ` Huang Shijie 2011-12-13 15:48 ` [PATCH 4/4] mtd: gpmi-nand: move to dma_transfer_direction Shawn Guo ` (3 subsequent siblings) 6 siblings, 1 reply; 22+ messages in thread From: Shawn Guo @ 2011-12-13 15:48 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 3/4] mtd: fix compile error for gpmi-nand 2011-12-13 15:48 ` [PATCH 3/4] mtd: fix compile error for gpmi-nand Shawn Guo @ 2011-12-14 2:21 ` Huang Shijie 0 siblings, 0 replies; 22+ messages in thread From: Huang Shijie @ 2011-12-14 2:21 UTC (permalink / raw) To: linux-arm-kernel ? 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 4/4] mtd: gpmi-nand: move to dma_transfer_direction 2011-12-13 15:48 [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Shawn Guo ` (2 preceding siblings ...) 2011-12-13 15:48 ` [PATCH 3/4] mtd: fix compile error for gpmi-nand Shawn Guo @ 2011-12-13 15:48 ` Shawn Guo 2011-12-14 2:20 ` Huang Shijie 2011-12-14 7:47 ` [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic Shawn Guo ` (2 subsequent siblings) 6 siblings, 1 reply; 22+ messages in thread From: Shawn Guo @ 2011-12-13 15:48 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 4/4] mtd: gpmi-nand: move to dma_transfer_direction 2011-12-13 15:48 ` [PATCH 4/4] mtd: gpmi-nand: move to dma_transfer_direction Shawn Guo @ 2011-12-14 2:20 ` Huang Shijie 0 siblings, 0 replies; 22+ messages in thread From: Huang Shijie @ 2011-12-14 2:20 UTC (permalink / raw) To: linux-arm-kernel ? 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic 2011-12-13 15:48 [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Shawn Guo ` (3 preceding siblings ...) 2011-12-13 15:48 ` [PATCH 4/4] mtd: gpmi-nand: move to dma_transfer_direction Shawn Guo @ 2011-12-14 7:47 ` Shawn Guo 2011-12-14 8:49 ` Dong Aisheng-B29396 ` (2 more replies) 2011-12-20 9:24 ` [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Vinod Koul 2011-12-23 16:03 ` Vinod Koul 6 siblings, 3 replies; 22+ messages in thread From: Shawn Guo @ 2011-12-14 7:47 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic 2011-12-14 7:47 ` [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic Shawn Guo @ 2011-12-14 8:49 ` Dong Aisheng-B29396 2011-12-20 0:51 ` Mark Brown 2011-12-23 16:07 ` Vinod Koul 2 siblings, 0 replies; 22+ messages in thread From: Dong Aisheng-B29396 @ 2011-12-14 8:49 UTC (permalink / raw) To: linux-arm-kernel > -----Original Message----- > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel- > owner at 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 at alsa-project.org; linux- > kernel at vger.kernel.org; linux-arm-kernel at 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic 2011-12-14 7:47 ` [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic Shawn Guo 2011-12-14 8:49 ` Dong Aisheng-B29396 @ 2011-12-20 0:51 ` Mark Brown 2011-12-20 3:07 ` [alsa-devel] " Shawn Guo 2011-12-23 16:07 ` Vinod Koul 2 siblings, 1 reply; 22+ messages in thread From: Mark Brown @ 2011-12-20 0:51 UTC (permalink / raw) To: linux-arm-kernel 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). ^ permalink raw reply [flat|nested] 22+ messages in thread
* [alsa-devel] [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic 2011-12-20 0:51 ` Mark Brown @ 2011-12-20 3:07 ` Shawn Guo 0 siblings, 0 replies; 22+ messages in thread From: Shawn Guo @ 2011-12-20 3:07 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic 2011-12-14 7:47 ` [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic Shawn Guo 2011-12-14 8:49 ` Dong Aisheng-B29396 2011-12-20 0:51 ` Mark Brown @ 2011-12-23 16:07 ` Vinod Koul 2011-12-23 16:28 ` Mark Brown 2 siblings, 1 reply; 22+ messages in thread From: Vinod Koul @ 2011-12-23 16:07 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic 2011-12-23 16:07 ` Vinod Koul @ 2011-12-23 16:28 ` Mark Brown 2011-12-23 16:32 ` Vinod Koul 0 siblings, 1 reply; 22+ messages in thread From: Mark Brown @ 2011-12-23 16:28 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic 2011-12-23 16:28 ` Mark Brown @ 2011-12-23 16:32 ` Vinod Koul 0 siblings, 0 replies; 22+ messages in thread From: Vinod Koul @ 2011-12-23 16:32 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration 2011-12-13 15:48 [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Shawn Guo ` (4 preceding siblings ...) 2011-12-14 7:47 ` [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic Shawn Guo @ 2011-12-20 9:24 ` Vinod Koul 2011-12-20 12:54 ` Shawn Guo 2011-12-23 16:03 ` Vinod Koul 6 siblings, 1 reply; 22+ messages in thread From: Vinod Koul @ 2011-12-20 9:24 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration 2011-12-20 9:24 ` [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Vinod Koul @ 2011-12-20 12:54 ` Shawn Guo 2011-12-21 4:07 ` Vinod Koul 0 siblings, 1 reply; 22+ messages in thread From: Shawn Guo @ 2011-12-20 12:54 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration 2011-12-20 12:54 ` Shawn Guo @ 2011-12-21 4:07 ` Vinod Koul 2011-12-21 4:45 ` Shawn Guo 0 siblings, 1 reply; 22+ messages in thread From: Vinod Koul @ 2011-12-21 4:07 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration 2011-12-21 4:07 ` Vinod Koul @ 2011-12-21 4:45 ` Shawn Guo 2011-12-21 4:40 ` Vinod Koul 0 siblings, 1 reply; 22+ messages in thread From: Shawn Guo @ 2011-12-21 4:45 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration 2011-12-21 4:45 ` Shawn Guo @ 2011-12-21 4:40 ` Vinod Koul 2011-12-21 4:58 ` Shawn Guo 0 siblings, 1 reply; 22+ messages in thread From: Vinod Koul @ 2011-12-21 4:40 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration 2011-12-21 4:40 ` Vinod Koul @ 2011-12-21 4:58 ` Shawn Guo 2011-12-22 5:13 ` Vinod Koul 0 siblings, 1 reply; 22+ messages in thread From: Shawn Guo @ 2011-12-21 4:58 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration 2011-12-21 4:58 ` Shawn Guo @ 2011-12-22 5:13 ` Vinod Koul 0 siblings, 0 replies; 22+ messages in thread From: Vinod Koul @ 2011-12-22 5:13 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration 2011-12-13 15:48 [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Shawn Guo ` (5 preceding siblings ...) 2011-12-20 9:24 ` [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Vinod Koul @ 2011-12-23 16:03 ` Vinod Koul 6 siblings, 0 replies; 22+ messages in thread From: Vinod Koul @ 2011-12-23 16:03 UTC (permalink / raw) To: linux-arm-kernel 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 at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- ~Vinod ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2011-12-23 16:32 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-13 15:48 [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Shawn Guo 2011-12-13 15:48 ` [PATCH 1/4] dmaengine: add DMA_TRANS_NONE to dma_transfer_direction Shawn Guo 2011-12-13 15:48 ` [PATCH 2/4] mmc: mxs-mmc: fix the dma_transfer_direction migration Shawn Guo 2011-12-13 15:48 ` [PATCH 3/4] mtd: fix compile error for gpmi-nand Shawn Guo 2011-12-14 2:21 ` Huang Shijie 2011-12-13 15:48 ` [PATCH 4/4] mtd: gpmi-nand: move to dma_transfer_direction Shawn Guo 2011-12-14 2:20 ` Huang Shijie 2011-12-14 7:47 ` [PATCH 5/5] ASoC: mxs: correct 'direction' of device_prep_dma_cyclic Shawn Guo 2011-12-14 8:49 ` Dong Aisheng-B29396 2011-12-20 0:51 ` Mark Brown 2011-12-20 3:07 ` [alsa-devel] " Shawn Guo 2011-12-23 16:07 ` Vinod Koul 2011-12-23 16:28 ` Mark Brown 2011-12-23 16:32 ` Vinod Koul 2011-12-20 9:24 ` [PATCH 0/4] Fix the left DMA_NONE from dma_transfer_direction migration Vinod Koul 2011-12-20 12:54 ` Shawn Guo 2011-12-21 4:07 ` Vinod Koul 2011-12-21 4:45 ` Shawn Guo 2011-12-21 4:40 ` Vinod Koul 2011-12-21 4:58 ` Shawn Guo 2011-12-22 5:13 ` Vinod Koul 2011-12-23 16:03 ` Vinod Koul
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).