[PATCH 00/13] pxa3xx patches to support mvebu builds

[PATCH 00/13] pxa3xx patches to support mvebu builds

[Ezequiel Garcia]

Hello everyone!

This patchset is part of the work I'm doing to enable the pxa3xx-nand
driver to support the NAND controller in Armada 370/XP. While this
work in progress, here's a subet of patches I consider good enough
for mainline.

It's worth noting that using these patches and adding appropriate
DT nodes, the NAND controller in Armada 370/XP SoC can detect
devices that are ONFI-compliant.

It's also worth noting that since pxa3xx has a mach-specific
DMA API, I'm including a few patches to ifdef such pxa-specific
code in non PXA/MMP platforms. This ugly workaround should be
removed once the specific DMA API is replaced by dmaengine.

Since there's no current schedule on when should that move happen,
for now we have no choice but to implement some ifdefs workaround.

Other than that, the rest of the patchset is just assorted cleanups
and minor fixes.

I'm Ccing some past pxa3xx-nand testers and reviewers, with the hope
they can take a look at this new patchset.

Any feedback and testing will be highly appreciated!

Ezequiel Garcia (13):
  mtd: nand: pxa3xx: Handle ECC and DMA enable/disable properly
  mtd: nand: pxa3xx: Allow to set/clear the 'spare enable' field
  mtd: nand: pxa3xx: Support command buffer #3
  mtd: nand: pxa3xx: Use 'length override' in ONFI paramater page read
  mtd: nand: pxa3xx: Add a local loop variable
  mtd: nand: pxa3xx: Remove hardcoded mtd name
  mtd: nand: pxa3xx: Remove uneeded internal cmdset
  mtd: nand: pxa3xx: Move cached registers to info structure
  mtd: nand: pxa3xx: Make dma code dependent on dma capable platforms
  mtd: nand: pxa3xx: Add inline keyword to function enable_int()
  mtd: nand: pxa3xx: Allow devices with no dma resources
  mtd: nand: pxa3xx-nand: Increase data buffer size
  mtd: nand: Allow to build pxa3xx_nand on Orion platforms

 drivers/mtd/nand/Kconfig                      |   2 +-
 drivers/mtd/nand/pxa3xx_nand.c                | 229 +++++++++++++++-----------
 include/linux/platform_data/mtd-nand-pxa3xx.h |  13 --
 3 files changed, 132 insertions(+), 112 deletions(-)

-- 
1.8.1.5

[PATCH 01/13] mtd: nand: pxa3xx: Handle ECC and DMA enable/disable properly

[Ezequiel Garcia]

When ECC is not selected, the ECC enable bit must be cleared
in the NAND control register. Same applies to DMA.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index fdc045d..6f4b62d 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -303,8 +303,17 @@ static void pxa3xx_nand_start(struct pxa3xx_nand_info *info)
 	uint32_t ndcr;
 
 	ndcr = host->reg_ndcr;
-	ndcr |= info->use_ecc ? NDCR_ECC_EN : 0;
-	ndcr |= info->use_dma ? NDCR_DMA_EN : 0;
+
+	if (info->use_ecc)
+		ndcr |= NDCR_ECC_EN;
+	else
+		ndcr &= ~NDCR_ECC_EN;
+
+	if (info->use_dma)
+		ndcr |= NDCR_DMA_EN;
+	else
+		ndcr &= ~NDCR_DMA_EN;
+
 	ndcr |= NDCR_ND_RUN;
 
 	/* clear status bits and run */
-- 
1.8.1.5

[PATCH 02/13] mtd: nand: pxa3xx: Allow to set/clear the 'spare enable' field

[Ezequiel Garcia]

Some commands (such as the ONFI parameter page read) need to
clear the 'spare enable' bit. This commit allows to set/clear
depending on the prepared command, instead of having it always
set.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 6f4b62d..b4d097f 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -174,6 +174,7 @@ struct pxa3xx_nand_info {
 	int			cs;
 	int			use_ecc;	/* use HW ECC ? */
 	int			use_dma;	/* use DMA ? */
+	int			use_spare;	/* use spare ? */
 	int			is_ready;
 
 	unsigned int		page_size;	/* page size of attached chip */
@@ -314,6 +315,11 @@ static void pxa3xx_nand_start(struct pxa3xx_nand_info *info)
 	else
 		ndcr &= ~NDCR_DMA_EN;
 
+	if (info->use_spare)
+		ndcr |= NDCR_SPARE_EN;
+	else
+		ndcr &= ~NDCR_SPARE_EN;
+
 	ndcr |= NDCR_ND_RUN;
 
 	/* clear status bits and run */
@@ -515,6 +521,7 @@ static int prepare_command_pool(struct pxa3xx_nand_info *info, int command,
 	info->buf_count		= 0;
 	info->oob_size		= 0;
 	info->use_ecc		= 0;
+	info->use_spare		= 1;
 	info->use_dma		= (use_dma) ? 1 : 0;
 	info->is_ready		= 0;
 	info->retcode		= ERR_NONE;
-- 
1.8.1.5

[PATCH 03/13] mtd: nand: pxa3xx: Support command buffer #3

[Ezequiel Garcia]

Some newer controllers support a fourth command buffer. This additional
command buffer allows to set an arbitrary length count, using the
NDCB3.NDLENCNT field, to perform non-standard length operations
such as the ONFI parameter page read.

In controllers without this register, the operation has no effect.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index b4d097f..23864ff 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -186,6 +186,7 @@ struct pxa3xx_nand_info {
 	uint32_t		ndcb0;
 	uint32_t		ndcb1;
 	uint32_t		ndcb2;
+	uint32_t		ndcb3;
 };
 
 static bool use_dma = 1;
@@ -485,6 +486,7 @@ static irqreturn_t pxa3xx_nand_irq(int irq, void *devid)
 		nand_writel(info, NDCB0, info->ndcb0);
 		nand_writel(info, NDCB0, info->ndcb1);
 		nand_writel(info, NDCB0, info->ndcb2);
+		nand_writel(info, NDCB0, info->ndcb3);
 	}
 
 	/* clear NDSR to let the controller exit the IRQ */
@@ -543,6 +545,7 @@ static int prepare_command_pool(struct pxa3xx_nand_info *info, int command,
 	default:
 		info->ndcb1 = 0;
 		info->ndcb2 = 0;
+		info->ndcb3 = 0;
 		break;
 	}
 
-- 
1.8.1.5

[PATCH 04/13] mtd: nand: pxa3xx: Use 'length override' in ONFI paramater page read

[Ezequiel Garcia]

The ONFI command 'parameter page read' needs a non-standard length.
Therefore, we enable the 'length override' field in NDCB0 and set
a non-zero 'length count' in NDCB3.

Additionally, the 'spare enable' bit must be disabled for any command
that sets a non-zero 'length count' in NDCB3.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 23864ff..0b73a58 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -80,6 +80,7 @@
 #define NDSR_RDDREQ		(0x1 << 1)
 #define NDSR_WRCMDREQ		(0x1)
 
+#define NDCB0_LEN_OVRD		(0x1 << 28)
 #define NDCB0_ST_ROW_EN         (0x1 << 26)
 #define NDCB0_AUTO_RS		(0x1 << 25)
 #define NDCB0_CSEL		(0x1 << 24)
@@ -539,6 +540,9 @@ static int prepare_command_pool(struct pxa3xx_nand_info *info, int command,
 	case NAND_CMD_READOOB:
 		pxa3xx_set_datasize(info);
 		break;
+	case NAND_CMD_PARAM:
+		info->use_spare = 0;
+		break;
 	case NAND_CMD_SEQIN:
 		exec_cmd = 0;
 		break;
@@ -614,8 +618,10 @@ static int prepare_command_pool(struct pxa3xx_nand_info *info, int command,
 		info->buf_count = 256;
 		info->ndcb0 |= NDCB0_CMD_TYPE(0)
 				| NDCB0_ADDR_CYC(1)
+				| NDCB0_LEN_OVRD
 				| cmd;
 		info->ndcb1 = (column & 0xFF);
+		info->ndcb3 = 256;
 		info->data_size = 256;
 		break;
 
-- 
1.8.1.5

[PATCH 05/13] mtd: nand: pxa3xx: Add a local loop variable

[Ezequiel Garcia]

This is just a cosmetic change, to make the code more readable.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 0b73a58..7c14fc2 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -1279,8 +1279,9 @@ static int pxa3xx_nand_probe(struct platform_device *pdev)
 	info = platform_get_drvdata(pdev);
 	probe_success = 0;
 	for (cs = 0; cs < pdata->num_cs; cs++) {
+		struct mtd_info *mtd = info->host[cs]->mtd;
 		info->cs = cs;
-		ret = pxa3xx_nand_scan(info->host[cs]->mtd);
+		ret = pxa3xx_nand_scan(mtd);
 		if (ret) {
 			dev_warn(&pdev->dev, "failed to scan nand at cs %d\n",
 				cs);
@@ -1288,7 +1289,7 @@ static int pxa3xx_nand_probe(struct platform_device *pdev)
 		}
 
 		ppdata.of_node = pdev->dev.of_node;
-		ret = mtd_device_parse_register(info->host[cs]->mtd, NULL,
+		ret = mtd_device_parse_register(mtd, NULL,
 						&ppdata, pdata->parts[cs],
 						pdata->nr_parts[cs]);
 		if (!ret)
-- 
1.8.1.5

[PATCH 06/13] mtd: nand: pxa3xx: Remove hardcoded mtd name

[Ezequiel Garcia]

There's no advantage in using a hardcoded name for the mtd device.
Instead use the provided by the platform_device.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 7c14fc2..1aa7aea 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -233,8 +233,6 @@ static struct pxa3xx_nand_flash builtin_flash_types[] = {
 /* Define a default flash type setting serve as flash detecting only */
 #define DEFAULT_FLASH_TYPE (&builtin_flash_types[0])
 
-const char *mtd_names[] = {"pxa3xx_nand-0", "pxa3xx_nand-1", NULL};
-
 #define NDTR0_tCH(c)	(min((c), 7) << 19)
 #define NDTR0_tCS(c)	(min((c), 7) << 16)
 #define NDTR0_tWH(c)	(min((c), 7) << 11)
@@ -1068,8 +1066,6 @@ KEEP_CONFIG:
 		host->row_addr_cycles = 3;
 	else
 		host->row_addr_cycles = 2;
-
-	mtd->name = mtd_names[0];
 	return nand_scan_tail(mtd);
 }
 
@@ -1280,6 +1276,8 @@ static int pxa3xx_nand_probe(struct platform_device *pdev)
 	probe_success = 0;
 	for (cs = 0; cs < pdata->num_cs; cs++) {
 		struct mtd_info *mtd = info->host[cs]->mtd;
+
+		mtd->name = pdev->name;
 		info->cs = cs;
 		ret = pxa3xx_nand_scan(mtd);
 		if (ret) {
-- 
1.8.1.5

[PATCH 07/13] mtd: nand: pxa3xx: Remove uneeded internal cmdset

[Ezequiel Garcia]

Use the defined macros for NAND command instead of using a constant
internal structure. This commit is only a cleanup, there's no
functionality modification.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c                | 63 ++++++++-------------------
 include/linux/platform_data/mtd-nand-pxa3xx.h | 13 ------
 2 files changed, 17 insertions(+), 59 deletions(-)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 1aa7aea..18320de 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -126,7 +126,6 @@ enum {
 
 struct pxa3xx_nand_host {
 	struct nand_chip	chip;
-	struct pxa3xx_nand_cmdset *cmdset;
 	struct mtd_info         *mtd;
 	void			*info_data;
 
@@ -194,23 +193,6 @@ static bool use_dma = 1;
 module_param(use_dma, bool, 0444);
 MODULE_PARM_DESC(use_dma, "enable DMA for data transferring to/from NAND HW");
 
-/*
- * Default NAND flash controller configuration setup by the
- * bootloader. This configuration is used only when pdata->keep_config is set
- */
-static struct pxa3xx_nand_cmdset default_cmdset = {
-	.read1		= 0x3000,
-	.read2		= 0x0050,
-	.program	= 0x1080,
-	.read_status	= 0x0070,
-	.read_id	= 0x0090,
-	.erase		= 0xD060,
-	.reset		= 0x00FF,
-	.lock		= 0x002A,
-	.unlock		= 0x2423,
-	.lock_status	= 0x007A,
-};
-
 static struct pxa3xx_nand_timing timing[] = {
 	{ 40, 80, 60, 100, 80, 100, 90000, 400, 40, },
 	{ 10,  0, 20,  40, 30,  40, 11123, 110, 10, },
@@ -507,7 +489,6 @@ static inline int is_buf_blank(uint8_t *buf, size_t len)
 static int prepare_command_pool(struct pxa3xx_nand_info *info, int command,
 		uint16_t column, int page_addr)
 {
-	uint16_t cmd;
 	int addr_cycle, exec_cmd;
 	struct pxa3xx_nand_host *host;
 	struct mtd_info *mtd;
@@ -557,21 +538,17 @@ static int prepare_command_pool(struct pxa3xx_nand_info *info, int command,
 	switch (command) {
 	case NAND_CMD_READOOB:
 	case NAND_CMD_READ0:
-		cmd = host->cmdset->read1;
+		info->buf_start = column;
+		info->ndcb0 |= NDCB0_CMD_TYPE(0)
+				| addr_cycle
+				| NAND_CMD_READ0;
+
 		if (command == NAND_CMD_READOOB)
-			info->buf_start = mtd->writesize + column;
-		else
-			info->buf_start = column;
+			info->buf_start += mtd->writesize;
 
-		if (unlikely(host->page_size < PAGE_CHUNK_SIZE))
-			info->ndcb0 |= NDCB0_CMD_TYPE(0)
-					| addr_cycle
-					| (cmd & NDCB0_CMD1_MASK);
-		else
-			info->ndcb0 |= NDCB0_CMD_TYPE(0)
-					| NDCB0_DBC
-					| addr_cycle
-					| cmd;
+		/* Second command setting for large pages */
+		if (host->page_size >= PAGE_CHUNK_SIZE)
+			info->ndcb0 |= NDCB0_DBC | (NAND_CMD_READSTART << 8);
 
 	case NAND_CMD_SEQIN:
 		/* small page addr setting */
@@ -602,62 +579,58 @@ static int prepare_command_pool(struct pxa3xx_nand_info *info, int command,
 			break;
 		}
 
-		cmd = host->cmdset->program;
 		info->ndcb0 |= NDCB0_CMD_TYPE(0x1)
 				| NDCB0_AUTO_RS
 				| NDCB0_ST_ROW_EN
 				| NDCB0_DBC
-				| cmd
+				| (NAND_CMD_PAGEPROG << 8)
+				| NAND_CMD_SEQIN
 				| addr_cycle;
 		break;
 
 	case NAND_CMD_PARAM:
-		cmd = NAND_CMD_PARAM;
 		info->buf_count = 256;
 		info->ndcb0 |= NDCB0_CMD_TYPE(0)
 				| NDCB0_ADDR_CYC(1)
 				| NDCB0_LEN_OVRD
-				| cmd;
+				| command;
 		info->ndcb1 = (column & 0xFF);
 		info->ndcb3 = 256;
 		info->data_size = 256;
 		break;
 
 	case NAND_CMD_READID:
-		cmd = host->cmdset->read_id;
 		info->buf_count = host->read_id_bytes;
 		info->ndcb0 |= NDCB0_CMD_TYPE(3)
 				| NDCB0_ADDR_CYC(1)
-				| cmd;
+				| command;
 		info->ndcb1 = (column & 0xFF);
 
 		info->data_size = 8;
 		break;
 	case NAND_CMD_STATUS:
-		cmd = host->cmdset->read_status;
 		info->buf_count = 1;
 		info->ndcb0 |= NDCB0_CMD_TYPE(4)
 				| NDCB0_ADDR_CYC(1)
-				| cmd;
+				| command;
 
 		info->data_size = 8;
 		break;
 
 	case NAND_CMD_ERASE1:
-		cmd = host->cmdset->erase;
 		info->ndcb0 |= NDCB0_CMD_TYPE(2)
 				| NDCB0_AUTO_RS
 				| NDCB0_ADDR_CYC(3)
 				| NDCB0_DBC
-				| cmd;
+				| (NAND_CMD_ERASE2 << 8)
+				| NAND_CMD_ERASE1;
 		info->ndcb1 = page_addr;
 		info->ndcb2 = 0;
 
 		break;
 	case NAND_CMD_RESET:
-		cmd = host->cmdset->reset;
 		info->ndcb0 |= NDCB0_CMD_TYPE(5)
-				| cmd;
+				| command;
 
 		break;
 
@@ -853,7 +826,6 @@ static int pxa3xx_nand_config_flash(struct pxa3xx_nand_info *info,
 	}
 
 	/* calculate flash information */
-	host->cmdset = &default_cmdset;
 	host->page_size = f->page_size;
 	host->read_id_bytes = (f->page_size == 2048) ? 4 : 2;
 
@@ -899,7 +871,6 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info)
 	}
 
 	host->reg_ndcr = ndcr & ~NDCR_INT_MASK;
-	host->cmdset = &default_cmdset;
 
 	host->ndtr0cs0 = nand_readl(info, NDTR0CS0);
 	host->ndtr1cs0 = nand_readl(info, NDTR1CS0);
diff --git a/include/linux/platform_data/mtd-nand-pxa3xx.h b/include/linux/platform_data/mtd-nand-pxa3xx.h
index c42f39f..ffb8019 100644
--- a/include/linux/platform_data/mtd-nand-pxa3xx.h
+++ b/include/linux/platform_data/mtd-nand-pxa3xx.h
@@ -16,19 +16,6 @@ struct pxa3xx_nand_timing {
 	unsigned int	tAR;  /* ND_ALE low to ND_nRE low delay */
 };
 
-struct pxa3xx_nand_cmdset {
-	uint16_t	read1;
-	uint16_t	read2;
-	uint16_t	program;
-	uint16_t	read_status;
-	uint16_t	read_id;
-	uint16_t	erase;
-	uint16_t	reset;
-	uint16_t	lock;
-	uint16_t	unlock;
-	uint16_t	lock_status;
-};
-
 struct pxa3xx_nand_flash {
 	char		*name;
 	uint32_t	chip_id;
-- 
1.8.1.5

[PATCH 08/13] mtd: nand: pxa3xx: Move cached registers to info structure

[Ezequiel Garcia]

This registers are not per-chip (aka host) but controller-wise,
so it's better to store them in the global 'info' structure.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 36 +++++++++++++++++-------------------
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 18320de..3b0b456 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -139,10 +139,6 @@ struct pxa3xx_nand_host {
 	unsigned int		row_addr_cycles;
 	size_t			read_id_bytes;
 
-	/* cached register value */
-	uint32_t		reg_ndcr;
-	uint32_t		ndtr0cs0;
-	uint32_t		ndtr1cs0;
 };
 
 struct pxa3xx_nand_info {
@@ -182,6 +178,11 @@ struct pxa3xx_nand_info {
 	unsigned int		oob_size;
 	int 			retcode;
 
+	/* cached register value */
+	uint32_t		reg_ndcr;
+	uint32_t		ndtr0cs0;
+	uint32_t		ndtr1cs0;
+
 	/* generated NDCBx register values */
 	uint32_t		ndcb0;
 	uint32_t		ndcb1;
@@ -247,8 +248,8 @@ static void pxa3xx_nand_set_timing(struct pxa3xx_nand_host *host,
 		NDTR1_tWHR(ns2cycle(t->tWHR, nand_clk)) |
 		NDTR1_tAR(ns2cycle(t->tAR, nand_clk));
 
-	host->ndtr0cs0 = ndtr0;
-	host->ndtr1cs0 = ndtr1;
+	info->ndtr0cs0 = ndtr0;
+	info->ndtr1cs0 = ndtr1;
 	nand_writel(info, NDTR0CS0, ndtr0);
 	nand_writel(info, NDTR1CS0, ndtr1);
 }
@@ -256,7 +257,7 @@ static void pxa3xx_nand_set_timing(struct pxa3xx_nand_host *host,
 static void pxa3xx_set_datasize(struct pxa3xx_nand_info *info)
 {
 	struct pxa3xx_nand_host *host = info->host[info->cs];
-	int oob_enable = host->reg_ndcr & NDCR_SPARE_EN;
+	int oob_enable = info->reg_ndcr & NDCR_SPARE_EN;
 
 	info->data_size = host->page_size;
 	if (!oob_enable) {
@@ -282,10 +283,9 @@ static void pxa3xx_set_datasize(struct pxa3xx_nand_info *info)
  */
 static void pxa3xx_nand_start(struct pxa3xx_nand_info *info)
 {
-	struct pxa3xx_nand_host *host = info->host[info->cs];
 	uint32_t ndcr;
 
-	ndcr = host->reg_ndcr;
+	ndcr = info->reg_ndcr;
 
 	if (info->use_ecc)
 		ndcr |= NDCR_ECC_EN;
@@ -660,7 +660,7 @@ static void pxa3xx_nand_cmdfunc(struct mtd_info *mtd, unsigned command,
 	 * "byte" address into a "word" address appropriate
 	 * for indexing a word-oriented device
 	 */
-	if (host->reg_ndcr & NDCR_DWIDTH_M)
+	if (info->reg_ndcr & NDCR_DWIDTH_M)
 		column /= 2;
 
 	/*
@@ -670,8 +670,8 @@ static void pxa3xx_nand_cmdfunc(struct mtd_info *mtd, unsigned command,
 	 */
 	if (info->cs != host->cs) {
 		info->cs = host->cs;
-		nand_writel(info, NDTR0CS0, host->ndtr0cs0);
-		nand_writel(info, NDTR1CS0, host->ndtr1cs0);
+		nand_writel(info, NDTR0CS0, info->ndtr0cs0);
+		nand_writel(info, NDTR1CS0, info->ndtr1cs0);
 	}
 
 	info->state = STATE_PREPARED;
@@ -847,7 +847,7 @@ static int pxa3xx_nand_config_flash(struct pxa3xx_nand_info *info,
 	ndcr |= NDCR_RD_ID_CNT(host->read_id_bytes);
 	ndcr |= NDCR_SPARE_EN; /* enable spare by default */
 
-	host->reg_ndcr = ndcr;
+	info->reg_ndcr = ndcr;
 
 	pxa3xx_nand_set_timing(host, f->timing);
 	return 0;
@@ -870,11 +870,9 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info)
 		host->read_id_bytes = 2;
 	}
 
-	host->reg_ndcr = ndcr & ~NDCR_INT_MASK;
-
-	host->ndtr0cs0 = nand_readl(info, NDTR0CS0);
-	host->ndtr1cs0 = nand_readl(info, NDTR1CS0);
-
+	info->reg_ndcr = ndcr & ~NDCR_INT_MASK;
+	info->ndtr0cs0 = nand_readl(info, NDTR0CS0);
+	info->ndtr1cs0 = nand_readl(info, NDTR1CS0);
 	return 0;
 }
 
@@ -1021,7 +1019,7 @@ KEEP_CONFIG:
 	chip->ecc.size = host->page_size;
 	chip->ecc.strength = 1;
 
-	if (host->reg_ndcr & NDCR_DWIDTH_M)
+	if (info->reg_ndcr & NDCR_DWIDTH_M)
 		chip->options |= NAND_BUSWIDTH_16;
 
 	if (nand_scan_ident(mtd, 1, def))
-- 
1.8.1.5

[PATCH 09/13] mtd: nand: pxa3xx: Make dma code dependent on dma capable platforms

[Ezequiel Garcia]

This patch adds a macro ARCH_HAS_DMA to compile-out arch specific
dma code, namely pxa_request_dma() and pxa_free_dma(). These symbols
are available only in pxa, which makes impossible to build the driver in
other platforms than ARCH_PXA.

In order to handle non-dma capable platforms, we implement a fallbacks that
allocate buffers as if 'use_dma=false', putting the dma related code
under the ARCH_HAS_DMA conditional.

Please note that the correct way to handle this is to migrate the
dma code to use of the mmp_pdma dmaengine driver. However, currently
this is not possible because the two dmaengine drivers can't work together.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 3b0b456..03346e9 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -25,7 +25,14 @@
 #include <linux/of.h>
 #include <linux/of_device.h>
 
+#if defined(CONFIG_ARCH_PXA) || defined(CONFIG_ARCH_MMP)
+#define ARCH_HAS_DMA
+#endif
+
+#ifdef ARCH_HAS_DMA
 #include <mach/dma.h>
+#endif
+
 #include <linux/platform_data/mtd-nand-pxa3xx.h>
 
 #define	CHIP_DELAY_TIMEOUT	(2 * HZ/10)
@@ -370,6 +377,7 @@ static void handle_data_pio(struct pxa3xx_nand_info *info)
 	}
 }
 
+#ifdef ARCH_HAS_DMA
 static void start_data_dma(struct pxa3xx_nand_info *info)
 {
 	struct pxa_dma_desc *desc = info->data_desc;
@@ -416,6 +424,10 @@ static void pxa3xx_nand_data_dma_irq(int channel, void *data)
 	enable_int(info, NDCR_INT_MASK);
 	nand_writel(info, NDSR, NDSR_WRDREQ | NDSR_RDDREQ);
 }
+#else
+static void start_data_dma(struct pxa3xx_nand_info *info)
+{}
+#endif
 
 static irqreturn_t pxa3xx_nand_irq(int irq, void *devid)
 {
@@ -882,6 +894,7 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info)
  */
 #define MAX_BUFF_SIZE	PAGE_SIZE
 
+#ifdef ARCH_HAS_DMA
 static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info)
 {
 	struct platform_device *pdev = info->pdev;
@@ -927,6 +940,20 @@ static void pxa3xx_nand_free_buff(struct pxa3xx_nand_info *info)
 		kfree(info->data_buff);
 	}
 }
+#else
+static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info)
+{
+	info->data_buff = kmalloc(MAX_BUFF_SIZE, GFP_KERNEL);
+	if (info->data_buff == NULL)
+		return -ENOMEM;
+	return 0;
+}
+
+static void pxa3xx_nand_free_buff(struct pxa3xx_nand_info *info)
+{
+	kfree(info->data_buff);
+}
+#endif
 
 static int pxa3xx_nand_sensing(struct pxa3xx_nand_info *info)
 {
@@ -1225,6 +1252,14 @@ static int pxa3xx_nand_probe(struct platform_device *pdev)
 	struct pxa3xx_nand_info *info;
 	int ret, cs, probe_success;
 
+#ifndef ARCH_HAS_DMA
+	if (use_dma) {
+		use_dma = 0;
+		dev_warn(&pdev->dev,
+			 "This platform can't do DMA on this device\n");
+	}
+#endif
+
 	ret = pxa3xx_nand_probe_dt(pdev);
 	if (ret)
 		return ret;
-- 
1.8.1.5

[PATCH 10/13] mtd: nand: pxa3xx: Add inline keyword to enable_int()

[Ezequiel Garcia]

Now that we have added ARCH_HAS_DMA conditional the function
enable_int() may be unused. So we declare it as inline
in order to remove the following warning, when the function is not used:

drivers/mtd/nand//pxa3xx_nand.c:343:24: warning: 'enable_int' defined
but not used [-Wunused-function]

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 03346e9..da162dd 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -337,7 +337,7 @@ static void pxa3xx_nand_stop(struct pxa3xx_nand_info *info)
 	nand_writel(info, NDSR, NDSR_MASK);
 }
 
-static void enable_int(struct pxa3xx_nand_info *info, uint32_t int_mask)
+static inline void enable_int(struct pxa3xx_nand_info *info, uint32_t int_mask)
 {
 	uint32_t ndcr;
 
-- 
1.8.1.5

Re: [PATCH 10/13] mtd: nand: pxa3xx: Add inline keyword to enable_int()

[Brian Norris]

On Mon, Jul 29, 2013 at 4:24 PM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> Now that we have added ARCH_HAS_DMA conditional the function
> enable_int() may be unused. So we declare it as inline
> in order to remove the following warning, when the function is not used:

I haven't reviewed the rest too well yet, but I think you want the
'__maybe_unused' qualifier, not 'inline'.

> drivers/mtd/nand//pxa3xx_nand.c:343:24: warning: 'enable_int' defined
> but not used [-Wunused-function]

Brian

Re: [PATCH 10/13] mtd: nand: pxa3xx: Add inline keyword to enable_int()

[Ezequiel Garcia]

On Tue, Jul 30, 2013 at 12:47:33AM -0700, Brian Norris wrote:
> On Mon, Jul 29, 2013 at 4:24 PM, Ezequiel Garcia
> <ezequiel.garcia@free-electrons.com> wrote:
> > Now that we have added ARCH_HAS_DMA conditional the function
> > enable_int() may be unused. So we declare it as inline
> > in order to remove the following warning, when the function is not used:
> 
> I haven't reviewed the rest too well yet, but I think you want the
> '__maybe_unused' qualifier, not 'inline'.
> 
> > drivers/mtd/nand//pxa3xx_nand.c:343:24: warning: 'enable_int' defined
> > but not used [-Wunused-function]

Mmm, I guess you're right. I did this patch a long time ago, and now I'm
wondering if there is any reason why I haven't used that in the first place.

Anyway... I'll fix and re-post.

Thanks for the feedback!
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[PATCH 11/13] mtd: nand: pxa3xx: Allow devices with no dma resources

[Ezequiel Garcia]

When use_dma=0 there's no point in requesting resources for dma,
since they won't be used anyway. Therefore we remove that requirement,
therefore allowing devices without dma to pass the driver probe.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 51 +++++++++++++++++++++++-------------------
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index da162dd..ccb8636 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -1117,30 +1117,35 @@ static int alloc_nand_resource(struct platform_device *pdev)
 	if (ret < 0)
 		return ret;
 
-	/*
-	 * This is a dirty hack to make this driver work from devicetree
-	 * bindings. It can be removed once we have a prober DMA controller
-	 * framework for DT.
-	 */
-	if (pdev->dev.of_node && of_machine_is_compatible("marvell,pxa3xx")) {
-		info->drcmr_dat = 97;
-		info->drcmr_cmd = 99;
-	} else {
-		r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
-		if (r == NULL) {
-			dev_err(&pdev->dev, "no resource defined for data DMA\n");
-			ret = -ENXIO;
-			goto fail_disable_clk;
-		}
-		info->drcmr_dat = r->start;
-
-		r = platform_get_resource(pdev, IORESOURCE_DMA, 1);
-		if (r == NULL) {
-			dev_err(&pdev->dev, "no resource defined for command DMA\n");
-			ret = -ENXIO;
-			goto fail_disable_clk;
+	if (use_dma) {
+		/*
+		 * This is a dirty hack to make this driver work from
+		 * devicetree bindings. It can be removed once we have
+		 * a prober DMA controller framework for DT.
+		 */
+		if (pdev->dev.of_node &&
+		    of_machine_is_compatible("marvell,pxa3xx")) {
+			info->drcmr_dat = 97;
+			info->drcmr_cmd = 99;
+		} else {
+			r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
+			if (r == NULL) {
+				dev_err(&pdev->dev,
+					"no resource defined for data DMA\n");
+				ret = -ENXIO;
+				goto fail_disable_clk;
+			}
+			info->drcmr_dat = r->start;
+
+			r = platform_get_resource(pdev, IORESOURCE_DMA, 1);
+			if (r == NULL) {
+				dev_err(&pdev->dev,
+					"no resource defined for cmd DMA\n");
+				ret = -ENXIO;
+				goto fail_disable_clk;
+			}
+			info->drcmr_cmd = r->start;
 		}
-		info->drcmr_cmd = r->start;
 	}
 
 	irq = platform_get_irq(pdev, 0);
-- 
1.8.1.5

[PATCH 12/13] mtd: nand: pxa3xx-nand: Increase data buffer size

[Ezequiel Garcia]

Devices with 4 KiB pages (plus OOB data) can be detected, so we increase
the data buffer size. A better solution would be to allocate a buffer
depending on the detected page size, but that's not possible given
we need the buffer prior to the device detection.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index ccb8636..ed47f14 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -892,7 +892,7 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info)
  * is: 2048 + 64 = 2112 bytes, allocate a page here for both the
  * data buffer and the DMA descriptor
  */
-#define MAX_BUFF_SIZE	PAGE_SIZE
+#define MAX_BUFF_SIZE	(PAGE_SIZE*2)
 
 #ifdef ARCH_HAS_DMA
 static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info)
-- 
1.8.1.5

[PATCH 13/13] mtd: nand: Allow to build pxa3xx_nand on Orion platforms

[Ezequiel Garcia]

The Armada 370 and Armada XP SoC families, selected by PLAT_ORION,
have a Nand Flash Controller (NFC) IP very similar to the one present
in PXA platforms. Therefore, we want to build this driver on PLAT_ORION.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/mtd/nand/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 50543f1..8633f32a 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -354,7 +354,7 @@ config MTD_NAND_ATMEL
 
 config MTD_NAND_PXA3xx
 	tristate "Support for NAND flash devices on PXA3xx"
-	depends on PXA3xx || ARCH_MMP
+	depends on PXA3xx || ARCH_MMP || PLAT_ORION
 	help
 	  This enables the driver for the NAND flash device found on
 	  PXA3xx processors
-- 
1.8.1.5

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Daniel Mack]

Hi Ezequiel,

On 30.07.2013 01:24, Ezequiel Garcia wrote:
> It's also worth noting that since pxa3xx has a mach-specific
> DMA API, I'm including a few patches to ifdef such pxa-specific
> code in non PXA/MMP platforms. This ugly workaround should be
> removed once the specific DMA API is replaced by dmaengine.

Interesting, because I'm working on a dmaengine implementation for PXA
right now. I'm not even half through, but I'm making progress, and I'm
not sure yet how to merge it. Because there won't be any migration path,
it'll be a bigger set that has to go in in one in order to prevent build
breakage.

Your patches will cause merge conflicts against mine, so I'm not sure
whether I should rebase my work on top of yours or if you should wait
until I'm finished.


Daniel

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Thomas Petazzoni]

Dear Daniel Mack,

On Tue, 30 Jul 2013 09:43:54 +0200, Daniel Mack wrote:

> On 30.07.2013 01:24, Ezequiel Garcia wrote:
> > It's also worth noting that since pxa3xx has a mach-specific
> > DMA API, I'm including a few patches to ifdef such pxa-specific
> > code in non PXA/MMP platforms. This ugly workaround should be
> > removed once the specific DMA API is replaced by dmaengine.
> 
> Interesting, because I'm working on a dmaengine implementation for PXA
> right now. I'm not even half through, but I'm making progress, and I'm
> not sure yet how to merge it. Because there won't be any migration path,
> it'll be a bigger set that has to go in in one in order to prevent build
> breakage.

Aren't drivers/dma/mmp_pdma.c and drivers/dma/mmp_tdma.c already
dmaengine drivers for PXA ?

> Your patches will cause merge conflicts against mine, so I'm not sure
> whether I should rebase my work on top of yours or if you should wait
> until I'm finished.

Considering the amount of time it will take for PXA to migrate over to
the dmaengine API, I think we'd want those clean up patches to go in
first, so that in parallel to the work you're doing on PXA dmaengine
usage, we can move forward with improving the pxa3xx_nand driver to
make it usable on Armada 370/XP.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Daniel Mack]

On 30.07.2013 09:53, Thomas Petazzoni wrote:
> On Tue, 30 Jul 2013 09:43:54 +0200, Daniel Mack wrote:
>> Interesting, because I'm working on a dmaengine implementation for PXA
>> right now. I'm not even half through, but I'm making progress, and I'm
>> not sure yet how to merge it. Because there won't be any migration path,
>> it'll be a bigger set that has to go in in one in order to prevent build
>> breakage.
> 
> Aren't drivers/dma/mmp_pdma.c and drivers/dma/mmp_tdma.c already
> dmaengine drivers for PXA ?

Yes, I saw the pdma driver as well, after I started my own
implementation. However, the tree is full of users of the proprietary
API, and moving them over won't be gap-less.

> Considering the amount of time it will take for PXA to migrate over to
> the dmaengine API, I think we'd want those clean up patches to go in
> first, so that in parallel to the work you're doing on PXA dmaengine
> usage, we can move forward with improving the pxa3xx_nand driver to
> make it usable on Armada 370/XP.

Ok, fine. I'll rework my set on top of Ezequiel's then.



Thanks,
Daniel

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Thomas Petazzoni]

Dear Daniel Mack,

On Tue, 30 Jul 2013 10:02:04 +0200, Daniel Mack wrote:
> On 30.07.2013 09:53, Thomas Petazzoni wrote:
> > On Tue, 30 Jul 2013 09:43:54 +0200, Daniel Mack wrote:
> >> Interesting, because I'm working on a dmaengine implementation for
> >> PXA right now. I'm not even half through, but I'm making progress,
> >> and I'm not sure yet how to merge it. Because there won't be any
> >> migration path, it'll be a bigger set that has to go in in one in
> >> order to prevent build breakage.
> > 
> > Aren't drivers/dma/mmp_pdma.c and drivers/dma/mmp_tdma.c already
> > dmaengine drivers for PXA ?
> 
> Yes, I saw the pdma driver as well, after I started my own
> implementation. However, the tree is full of users of the proprietary
> API, and moving them over won't be gap-less.

Indeed. Some patches migrating the pxa3xx_nand driver to use the
dmaengine API have been posted a while ago, but they haven't been
merged because one needs to convert *all* the PXA drivers to the
dmaengine API to get the thing working.

At Linaro Connect earlier this month, I've talked about this with Chao
Xie from Marvell, and he was interested in making progress towards
dmaengine usage on PXA platforms.

> > Considering the amount of time it will take for PXA to migrate over
> > to the dmaengine API, I think we'd want those clean up patches to
> > go in first, so that in parallel to the work you're doing on PXA
> > dmaengine usage, we can move forward with improving the pxa3xx_nand
> > driver to make it usable on Armada 370/XP.
> 
> Ok, fine. I'll rework my set on top of Ezequiel's then.

Excellent, thanks!

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Ezequiel Garcia]

Hello Daniel,

On Tue, Jul 30, 2013 at 10:18:09AM +0200, Thomas Petazzoni wrote:
> On Tue, 30 Jul 2013 10:02:04 +0200, Daniel Mack wrote:
> > On 30.07.2013 09:53, Thomas Petazzoni wrote:
> > > On Tue, 30 Jul 2013 09:43:54 +0200, Daniel Mack wrote:
> > >> Interesting, because I'm working on a dmaengine implementation for
> > >> PXA right now. I'm not even half through, but I'm making progress,
> > >> and I'm not sure yet how to merge it. Because there won't be any
> > >> migration path, it'll be a bigger set that has to go in in one in
> > >> order to prevent build breakage.
> > > 
> > > Aren't drivers/dma/mmp_pdma.c and drivers/dma/mmp_tdma.c already
> > > dmaengine drivers for PXA ?
> > 
> > Yes, I saw the pdma driver as well, after I started my own
> > implementation. However, the tree is full of users of the proprietary
> > API, and moving them over won't be gap-less.
> 

Mmmm.. I'm a bit confused by this: is your dmaengine driver any
different/better from the already existent mmp_{p,t}dma.c ?

(I'm sure I've misunderstood something, otherwise why would you be
working in something that's already available?)

> Indeed. Some patches migrating the pxa3xx_nand driver to use the
> dmaengine API have been posted a while ago, but they haven't been
> merged because one needs to convert *all* the PXA drivers to the
> dmaengine API to get the thing working.
> 

Here's a patch posted in July 2012 converting pxa3xx-nand to dmaengine.
That patch was never merged because (just as Thomas says) both
dma drivers (mmp dmaengine on one side, mach-pxa dma on the other) don't
work together. In other words, you have to convert *all* drivers at the
same time.

Thomas proposed an idea for this conversion a few months ago: (quoting
him from IRC)

"""
First have a patch that reimplements the existing plat-pxa/dma.c API on
top of dmaengine, so that you don't have to change any driver.
Then, go through each driver, one per patch to switch to the dmaengine API.
And finally get rid of the compatibility layer created in the first
patch.
"""

Does this sound sane?
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Daniel Mack]

On 30.07.2013 15:15, Ezequiel Garcia wrote:
> Hello Daniel,
> 
> On Tue, Jul 30, 2013 at 10:18:09AM +0200, Thomas Petazzoni wrote:
>> On Tue, 30 Jul 2013 10:02:04 +0200, Daniel Mack wrote:
>>> On 30.07.2013 09:53, Thomas Petazzoni wrote:
>>>> On Tue, 30 Jul 2013 09:43:54 +0200, Daniel Mack wrote:
>>>>> Interesting, because I'm working on a dmaengine implementation for
>>>>> PXA right now. I'm not even half through, but I'm making progress,
>>>>> and I'm not sure yet how to merge it. Because there won't be any
>>>>> migration path, it'll be a bigger set that has to go in in one in
>>>>> order to prevent build breakage.
>>>>
>>>> Aren't drivers/dma/mmp_pdma.c and drivers/dma/mmp_tdma.c already
>>>> dmaengine drivers for PXA ?
>>>
>>> Yes, I saw the pdma driver as well, after I started my own
>>> implementation. However, the tree is full of users of the proprietary
>>> API, and moving them over won't be gap-less.
>>
> 
> Mmmm.. I'm a bit confused by this: is your dmaengine driver any
> different/better from the already existent mmp_{p,t}dma.c ?

As I said, I saw this after I started my own implementation, which isn't
a big deal. At least, I now understand the internals of dmaengine
drivers :) The mmp_pdma looks suitable for PXA2xx chips, but it doesn't
work yet for me. I'll try and fix this first, and then port over all the
drivers.

> Here's a patch posted in July 2012 converting pxa3xx-nand to dmaengine.

Where?

> That patch was never merged because (just as Thomas says) both
> dma drivers (mmp dmaengine on one side, mach-pxa dma on the other) don't
> work together. In other words, you have to convert *all* drivers at the
> same time.
> 
> Thomas proposed an idea for this conversion a few months ago: (quoting
> him from IRC)
> 
> """
> First have a patch that reimplements the existing plat-pxa/dma.c API on
> top of dmaengine, so that you don't have to change any driver.
> Then, go through each driver, one per patch to switch to the dmaengine API.
> And finally get rid of the compatibility layer created in the first
> patch.
> """
> 
> Does this sound sane?

Unfortunately, no. I thought so too, but the problem is that all users
of the proprietary PXA DMA implementation access the registers directly,
and also allocate their own DMA coherent register space, which is
unneeded with a proper dmaengine implementation.

So there's nothing else we can do than really change all the drivers,
which is what I'm currently doing. I'll put you on Cc: once I post patches.


Thanks,
Daniel

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Ezequiel Garcia]

On Tue, Jul 30, 2013 at 03:22:25PM +0200, Daniel Mack wrote:
[...]
> > Mmmm.. I'm a bit confused by this: is your dmaengine driver any
> > different/better from the already existent mmp_{p,t}dma.c ?
> 
> As I said, I saw this after I started my own implementation, which isn't
> a big deal. At least, I now understand the internals of dmaengine
> drivers :) The mmp_pdma looks suitable for PXA2xx chips, but it doesn't
> work yet for me. I'll try and fix this first, and then port over all the
> drivers.
> 
> > Here's a patch posted in July 2012 converting pxa3xx-nand to dmaengine.
> 
> Where?
> 

Ouch... here it is:

http://permalink.gmane.org/gmane.linux.ports.arm.kernel/178989

(sorry about that...)

That patch was part of this series:

http://comments.gmane.org/gmane.linux.ports.arm.kernel/181731

But as you can see in the above link, they dropped the pxa3xx-nand part.

> > That patch was never merged because (just as Thomas says) both
> > dma drivers (mmp dmaengine on one side, mach-pxa dma on the other) don't
> > work together. In other words, you have to convert *all* drivers at the
> > same time.
> > 
> > Thomas proposed an idea for this conversion a few months ago: (quoting
> > him from IRC)
> > 
> > """
> > First have a patch that reimplements the existing plat-pxa/dma.c API on
> > top of dmaengine, so that you don't have to change any driver.
> > Then, go through each driver, one per patch to switch to the dmaengine API.
> > And finally get rid of the compatibility layer created in the first
> > patch.
> > """
> > 
> > Does this sound sane?
> 
> Unfortunately, no. I thought so too, but the problem is that all users
> of the proprietary PXA DMA implementation access the registers directly,
> and also allocate their own DMA coherent register space, which is
> unneeded with a proper dmaengine implementation.
> 
> So there's nothing else we can do than really change all the drivers,
> which is what I'm currently doing.

Oh, I see. 

> I'll put you on Cc: once I post patches.
> 

Great! That'll be very appreciated.

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

RE: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Chao Xie]

> On 30.07.2013 15:15, Ezequiel Garcia wrote:
> Hello Daniel,
> 
> On Tue, Jul 30, 2013 at 10:18:09AM +0200, Thomas Petazzoni wrote:
>> On Tue, 30 Jul 2013 10:02:04 +0200, Daniel Mack wrote:
>>> On 30.07.2013 09:53, Thomas Petazzoni wrote:
>>>> On Tue, 30 Jul 2013 09:43:54 +0200, Daniel Mack wrote:
>>>>> Interesting, because I'm working on a dmaengine implementation for
>>>>> PXA right now. I'm not even half through, but I'm making progress,
>>>>> and I'm not sure yet how to merge it. Because there won't be any
>>>>> migration path, it'll be a bigger set that has to go in in one in
>>>>> order to prevent build breakage.
>>>>
>>>> Aren't drivers/dma/mmp_pdma.c and drivers/dma/mmp_tdma.c already
>>>> dmaengine drivers for PXA ?
>>>
>>> Yes, I saw the pdma driver as well, after I started my own
>>> implementation. However, the tree is full of users of the proprietary
>>> API, and moving them over won't be gap-less.
>>
> 
> Mmmm.. I'm a bit confused by this: is your dmaengine driver any
> different/better from the already existent mmp_{p,t}dma.c ?
> 
> As I said, I saw this after I started my own implementation, which isn't
> a big deal. At least, I now understand the internals of dmaengine
> drivers :) The mmp_pdma looks suitable for PXA2xx chips, but it doesn't
> work yet for me. I'll try and fix this first, and then port over all the
> drivers.
>
If you are sending the patch for pdma and tdma, please include me as well.
Now we are trying to make audio to use DMA independent of pdma and
tdma(current driver are bound to tdma), and there are some modification for pdma too.

> Here's a patch posted in July 2012 converting pxa3xx-nand to dmaengine.
>
> Where?
>
> That patch was never merged because (just as Thomas says) both
> dma drivers (mmp dmaengine on one side, mach-pxa dma on the other) don't
> work together. In other words, you have to convert *all* drivers at the
> same time.
> 
> Thomas proposed an idea for this conversion a few months ago: (quoting
> him from IRC)
> 
> """
> First have a patch that reimplements the existing plat-pxa/dma.c API on
> top of dmaengine, so that you don't have to change any driver.
> Then, go through each driver, one per patch to switch to the dmaengine API.
> And finally get rid of the compatibility layer created in the first
> patch.
> """
> 
> Does this sound sane?
> 
> Unfortunately, no. I thought so too, but the problem is that all users
> of the proprietary PXA DMA implementation access the registers directly,
> and also allocate their own DMA coherent register space, which is
> unneeded with a proper dmaengine implementation.
> 
> So there's nothing else we can do than really change all the drivers,
> which is what I'm currently doing. I'll put you on Cc: once I post patches.
>
It need many efforts. There are some drivers make use of old pxa DMA driver,
for example camera/smc Ethernet.
The difficult is some platform was produced almost 10 years ago, and I do not 
have such platform in my hand. So will you test them or just pass compilation?
>
> Thanks,
> Daniel

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Daniel Mack]

On 30.07.2013 01:24, Ezequiel Garcia wrote:
> This patchset is part of the work I'm doing to enable the pxa3xx-nand
> driver to support the NAND controller in Armada 370/XP. While this
> work in progress, here's a subet of patches I consider good enough
> for mainline.

What tree did you make this patch set against? I fail to apply it on top
of 3.11-rc3. Any particular patches I need before applying yours? Did
you push them to any public git repository maybe?


Thanks,
Daniel

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Ezequiel Garcia]

On Wed, Jul 31, 2013 at 01:51:00PM +0200, Daniel Mack wrote:
> On 30.07.2013 01:24, Ezequiel Garcia wrote:
> > This patchset is part of the work I'm doing to enable the pxa3xx-nand
> > driver to support the NAND controller in Armada 370/XP. While this
> > work in progress, here's a subet of patches I consider good enough
> > for mainline.
> 
> What tree did you make this patch set against? I fail to apply it on top
> of 3.11-rc3. Any particular patches I need before applying yours? Did
> you push them to any public git repository maybe?
> 

Mmm.. sorry about that, I should have been more explicit.

This patchset applies cleanly on top of a recent (yesterday or today)
linux-next and also on top Artem's l2-mtd:

git://git.infradead.org/users/dedekind/l2-mtd.git

(the above usually has the latest accepted mtd changes).

Thanks!
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Daniel Mack]

On 30.07.2013 01:24, Ezequiel Garcia wrote:
> I'm Ccing some past pxa3xx-nand testers and reviewers, with the hope
> they can take a look at this new patchset.
> 
> Any feedback and testing will be highly appreciated!

I take it that you use this driver without DMA on your Armada 370/XP?

Before implementing the dmaengine bits, I wanted to make sure that the
driver still works on a PXA3xx in PIO mode with your latest patch set.
But unfortunately, it doesn't (ARCH_HAS_DMA is made undefined for this
test):

[    2.534138] pxa3xx-nand pxa3xx-nand: This platform can't do DMA on
this device
[    2.733782] pxa3xx-nand pxa3xx-nand: Wait time out!!!
[    2.933807] pxa3xx-nand pxa3xx-nand: Wait time out!!!
[    3.133806] pxa3xx-nand pxa3xx-nand: Wait time out!!!
[    3.138908] No NAND device found
[    3.142216] pxa3xx-nand pxa3xx-nand: failed to scan nand at cs 0

Any idea?


Thanks,
Daniel

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Ezequiel Garcia]

On Thu, Aug 01, 2013 at 12:16:27PM +0200, Daniel Mack wrote:
> On 30.07.2013 01:24, Ezequiel Garcia wrote:
> > I'm Ccing some past pxa3xx-nand testers and reviewers, with the hope
> > they can take a look at this new patchset.
> > 
> > Any feedback and testing will be highly appreciated!
> 
> I take it that you use this driver without DMA on your Armada 370/XP?
> 
> Before implementing the dmaengine bits, I wanted to make sure that the
> driver still works on a PXA3xx in PIO mode with your latest patch set.
> But unfortunately, it doesn't (ARCH_HAS_DMA is made undefined for this
> test):
> 
> [    2.534138] pxa3xx-nand pxa3xx-nand: This platform can't do DMA on
> this device
> [    2.733782] pxa3xx-nand pxa3xx-nand: Wait time out!!!
> [    2.933807] pxa3xx-nand pxa3xx-nand: Wait time out!!!
> [    3.133806] pxa3xx-nand pxa3xx-nand: Wait time out!!!
> [    3.138908] No NAND device found
> [    3.142216] pxa3xx-nand pxa3xx-nand: failed to scan nand at cs 0
> 
> Any idea?
> 
> 

Probably one of the patches is wrong. Could you do a git-bisect?

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Daniel Mack]

On 01.08.2013 12:21, Ezequiel Garcia wrote:
> Probably one of the patches is wrong. Could you do a git-bisect?

Sure:

fbd70cb71103051699c7c49b08d5e107736e3a75 is the first bad commit
commit fbd70cb71103051699c7c49b08d5e107736e3a75
Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date:   Mon Jul 29 20:24:13 2013 -0300

    mtd: nand: pxa3xx: Support command buffer #3

    Some newer controllers support a fourth command buffer. This additional
    command buffer allows to set an arbitrary length count, using the
    NDCB3.NDLENCNT field, to perform non-standard length operations
    such as the ONFI parameter page read.

    In controllers without this register, the operation has no effect.

    Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>


With this patch reverted, things are fine again on PXA3xx.


Daniel

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Ezequiel Garcia]

On Thu, Aug 01, 2013 at 12:47:56PM +0200, Daniel Mack wrote:
> On 01.08.2013 12:21, Ezequiel Garcia wrote:
> > Probably one of the patches is wrong. Could you do a git-bisect?
> 
> Sure:
> 

Thanks a lot!

> fbd70cb71103051699c7c49b08d5e107736e3a75 is the first bad commit
> commit fbd70cb71103051699c7c49b08d5e107736e3a75
> Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Date:   Mon Jul 29 20:24:13 2013 -0300
> 
>     mtd: nand: pxa3xx: Support command buffer #3
> 
>     Some newer controllers support a fourth command buffer. This additional
>     command buffer allows to set an arbitrary length count, using the
>     NDCB3.NDLENCNT field, to perform non-standard length operations
>     such as the ONFI parameter page read.
> 
>     In controllers without this register, the operation has no effect.

^^^
So the above does not hold :-(

Given this shows a significant distinction between PXA NAND controller
(what we could call NFCv1) and Armada 370/XP NAND controller (NFCv2)
I see no way but to introduce a new compatible string for this driver.

Following the convention of choosing the first SoC that introduces the
controller, the new compatible would be "marvell,armada370-nand".

How does this sound?
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Daniel Mack]

On 01.08.2013 12:59, Ezequiel Garcia wrote:
> Given this shows a significant distinction between PXA NAND controller
> (what we could call NFCv1) and Armada 370/XP NAND controller (NFCv2)
> I see no way but to introduce a new compatible string for this driver.
> 
> Following the convention of choosing the first SoC that introduces the
> controller, the new compatible would be "marvell,armada370-nand".

Sure, that sounds about right. That's what compatibility string are for,
after all :)


Daniel

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Daniel Mack]

Hi Ezequiel,

On 01.08.2013 12:59, Ezequiel Garcia wrote:
> On Thu, Aug 01, 2013 at 12:47:56PM +0200, Daniel Mack wrote:

>> fbd70cb71103051699c7c49b08d5e107736e3a75 is the first bad commit
>> commit fbd70cb71103051699c7c49b08d5e107736e3a75
>> Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>> Date:   Mon Jul 29 20:24:13 2013 -0300
>>
>>     mtd: nand: pxa3xx: Support command buffer #3
>>
>>     Some newer controllers support a fourth command buffer. This additional
>>     command buffer allows to set an arbitrary length count, using the
>>     NDCB3.NDLENCNT field, to perform non-standard length operations
>>     such as the ONFI parameter page read.
>>
>>     In controllers without this register, the operation has no effect.
> 
> ^^^
> So the above does not hold :-(
> 
> Given this shows a significant distinction between PXA NAND controller
> (what we could call NFCv1) and Armada 370/XP NAND controller (NFCv2)
> I see no way but to introduce a new compatible string for this driver.
> 
> Following the convention of choosing the first SoC that introduces the
> controller, the new compatible would be "marvell,armada370-nand".
> 
> How does this sound?
> 

Are you planning a new version of this series? I'd like to base my
pxa-dma patches on top of yours ...


Thanks,
Daniel

Re: [PATCH 00/13] pxa3xx patches to support mvebu builds

[Ezequiel Garcia]

On Wed, Aug 07, 2013 at 02:04:51PM +0200, Daniel Mack wrote:
> Hi Ezequiel,
> 
> On 01.08.2013 12:59, Ezequiel Garcia wrote:
> > On Thu, Aug 01, 2013 at 12:47:56PM +0200, Daniel Mack wrote:
> 
> >> fbd70cb71103051699c7c49b08d5e107736e3a75 is the first bad commit
> >> commit fbd70cb71103051699c7c49b08d5e107736e3a75
> >> Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> >> Date:   Mon Jul 29 20:24:13 2013 -0300
> >>
> >>     mtd: nand: pxa3xx: Support command buffer #3
> >>
> >>     Some newer controllers support a fourth command buffer. This additional
> >>     command buffer allows to set an arbitrary length count, using the
> >>     NDCB3.NDLENCNT field, to perform non-standard length operations
> >>     such as the ONFI parameter page read.
> >>
> >>     In controllers without this register, the operation has no effect.
> > 
> > ^^^
> > So the above does not hold :-(
> > 
> > Given this shows a significant distinction between PXA NAND controller
> > (what we could call NFCv1) and Armada 370/XP NAND controller (NFCv2)
> > I see no way but to introduce a new compatible string for this driver.
> > 
> > Following the convention of choosing the first SoC that introduces the
> > controller, the new compatible would be "marvell,armada370-nand".
> > 
> > How does this sound?
> > 
> 
> Are you planning a new version of this series? I'd like to base my
> pxa-dma patches on top of yours ...
> 
> 

Yes, I was just about to send it.

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com