NAND: add ts7xxx driver

This patch adds support for the NAND found in Technologic Systems ARM boards[1]. The platform specific parts (IO address and parititoning schemes) have been moved into platform specific files whilst the driver it's self can be used as a complete replacement for the ts7250 NAND driver.

[1] http://www.embeddedarm.com/products/arm-sbc.php

---
 drivers/mtd/nand/Kconfig        |    8 +-
 drivers/mtd/nand/Makefile       |    1 +
 drivers/mtd/nand/ts7xxx.c       |  334 +++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/nand-ts7xxx.h |   35 ++++
 4 files changed, 377 insertions(+), 1 deletions(-)
 create mode 100644 drivers/mtd/nand/ts7xxx.c
 create mode 100644 include/linux/mtd/nand-ts7xxx.h

index f8ae040..6c9d344 100644
@@ -76,10 +76,16 @@ config MTD_NAND_AMS_DELTA
 
 config MTD_NAND_TS7250
 	tristate "NAND Flash device on TS-7250 board"
-	depends on MACH_TS72XX
+	depends on MACH_TS72XX && !MTD_NAND_TS7XXX
 	help
 	  Support for NAND flash on Technologic Systems TS-7250 platform.
 
+config MTD_NAND_TS7XXX
+	tristate "NAND Flash device on TS-7xxx boards"
+	depends on MACH_TS72XX || MACH_TS78XX
+	help
+	  Support for NAND flash on Technologic Systems TS-7xxx platforms.
+
 config MTD_NAND_IDS
 	tristate
 

index b661586..68694c7 100644
@@ -19,6 +19,7 @@ obj-$(CONFIG_MTD_NAND_H1900)		+= h1910.o
 obj-$(CONFIG_MTD_NAND_RTC_FROM4)	+= rtc_from4.o
 obj-$(CONFIG_MTD_NAND_SHARPSL)		+= sharpsl.o
 obj-$(CONFIG_MTD_NAND_TS7250)		+= ts7250.o
+obj-$(CONFIG_MTD_NAND_TS7XXX)		+= ts7xxx.o
 obj-$(CONFIG_MTD_NAND_NANDSIM)		+= nandsim.o
 obj-$(CONFIG_MTD_NAND_CS553X)		+= cs553x_nand.o
 obj-$(CONFIG_MTD_NAND_NDFC)		+= ndfc.o

new file mode 100644
index 0000000..955209a
@@ -0,0 +1,35 @@
+/*
+ * linux/include/linux/mtd/nand-ts7xxx.h
+ *
+ * Copyright (c) 2008 Alexander Clouter <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/mtd/partitions.h>
+
+struct ts7xxx_ioport_entry {
+	unsigned int			res;
+	unsigned int			offset;
+};
+
+struct ts7xxx_ioports {
+	struct ts7xxx_ioport_entry	ctrl;
+	struct ts7xxx_ioport_entry	data;
+
+	struct ts7xxx_ioport_entry	busy;
+};
+
+/*
+ * struct ts7xxx_nand_data - chip level device structure
+ * @nr_partitions:	number of partitions pointed to by partitions (or zero)
+ * @partitions:		mtd partition list
+ */
+struct ts7xxx_nand_data {
+	int				nr_partitions;
+	struct mtd_partition		*partitions;
+
+	struct ts7xxx_ioports		ioports;
+};

1.5.6.5

Why don't you morph the ts7250 into the form you want instead of adding a parallel driver for the same thing?

Hi,

...because when I sent this to you last year for some offlist comment action you did not grumble that it was a separate driver. Then after a year of reposting twice to this list with no comment or feedback what so ever I guess I made the mistake of assuming it was not 'displeasing' to the community.

Sorry to sound grumpy, but after trying to post cpufreq, timeriomem, nand and arm patches over the past two years with a 90% resulting in the silent treatment it feels like a brick has hit me in the face with "hey instead just morph the current driver".

Bah.

</rant>

The driver I threw together makes a rather radical change to put all the partitioning and iomem resources ranges back into the platform specific code where they belong. It was just easier to start clean, plus I learnt a good deal about the MTD subsystem in the process, although that's not a good reason for submission I know.

As the feedback from ts72[056]0 users has been pretty...well...dire and I have no access to the platform I cannot be certain this patch safely works for those users. I had the view that once I can get a solid confirmation that the ts72[056]0 users are happy I was hoping that the 7250.c driver would just become obsolete?

So, is it back to square one for me?

Cheers

Alexander Clouter
.sigmonster says: You will never know hunger.

Hi,

Attached is the kind of change that affects the platform code. Meanwhile if I was to morph the ts7250 driver my first step would be to trim a huge chunk of the platform specific code that's in the NAND driver and then at the same time get the ARM platform driver amended otherwise you end up with a NAND less board.

It's been hard enough to submit my TS-7800 patches and break them up so the different subsystems gracefully get added. To modify the existing ts7250 driver I would have to take on the tinkering and submission cycles with the TS-72[056]0 (when I don't own one) too. As I so far have gotten zero feedback[1] from the community this seems to me the *only* way I can work on my patches with a view for upstream submission.

This way, with a separate driver, when things finally/if-ever get accepted nothing breaks. I think the changes also being made are easier for someone

If you know of a way that the MTD folk are willing to tinker with the ARM subsystem code and vice versa (last time I was told by the ARM people to break up my MTD stuff and submit it to you guys separately) then I'm listening.

I'm stuck in a rut and it really is wearing me down...I'm not even a embedded developer, just a network packet pushing perl monkey who just wants to get his router working :-/

Cheers

[1] and I still do not understand why in the ts7000 mailing list there is all this work on a seperate patch set for ts72[560]0 support when they apparently do not have a NAND driver even? Any ideas?

From: Alexander Clouter <[email protected]>
Date: Sat, 7 Feb 2009 12:38:43 +0000
Subject: [PATCH] [ARM] ep93xx: add hooks to ts7xxx NAND driver

---
 arch/arm/mach-ep93xx/include/mach/ts72xx.h |    8 ++
 arch/arm/mach-ep93xx/ts72xx.c              |  129 +++++++++++++++++++++++++++-
 2 files changed, 136 insertions(+), 1 deletions(-)

index 34ddec0..2244389 100644
@@ -44,6 +44,7 @@
 #define TS72XX_NOR_PHYS_BASE		0x60000000
 #define TS72XX_NOR2_PHYS_BASE		0x62000000
 
+/* MTD_NAND_TS7250 defines */
 #define TS72XX_NAND1_DATA_PHYS_BASE	0x60000000
 #define TS72XX_NAND2_DATA_PHYS_BASE	0x70000000
 #define TS72XX_NAND_DATA_VIRT_BASE	0xfebfc000

@@ -59,6 +60,13 @@
 #define TS72XX_NAND_BUSY_VIRT_BASE	0xfebfa000
 #define TS72XX_NAND_BUSY_SIZE		0x00001000
 
+/* MTD_NAND_TS7XXX defines */
+#define TS72XX_NAND_DATA_PHYS_BASE	0x60000000
+#define TS72XX_NAND_CONTROL_PHYS_BASE	0x60400000
+#define TS72XX_NAND_BUSY_PHYS_BASE	0x60800000
+#define TS72XX_NAND_IO_SIZE		4
+#define TS72XX_NAND1_NAND2_DIFF		0x10000000
+
 
 #define TS72XX_RTC_INDEX_VIRT_BASE	0xfebf9000
 #define TS72XX_RTC_INDEX_PHYS_BASE	0x10800000

1.5.6.5

Hi,

Unsure if it even attached so incase it did not:

http://stuff.digriz.org.uk/ts7xxx-nand/0002--ARM-ep93xx-add-hooks-to-ts7xxx-NAND-driver.patch

Cheers

With a little work the generic plat_nand driver could probably be used instead of this new driver or the original ts7250 driver.

The only thing special about the original ts7250 driver appears to be the fall-back partitioning scheme that uses the size of the device to figure out what static mtd_partition table to use.

This driver uses a similar approach but passes a callback to the platform driver to use instead. It also adds some conditional ecc support.

It might be more useful to create a generic patch for plat_nand that adds this functionality and then obsolete the old ts7250 driver.

I have been using the plat_nand driver on a custom ep93xx based board for quite a while with no problems.

Regards,
Hartley

Hi,

I was always curious if that was the way to go, but as there were more than one platform (TS-7800 and TS-72X0) I thought it would spare the duplication of code in the kernel; as the code between the two platforms is really just in the HW ECC and soon-one-day-maybe DMA support in the TS-7800.

I would have not really put too much effort in that if I was going for a TS-7800 only (plat_nand based driver) as it would have not been worth it. It was only useless in the case of the TS-72X0 as it comes with several different NAND sizes, unlike currently the TS-7800 which only has the one.

Well, from a practical level it would make mainlining the code much easier as it would lurk in the TS-7800 platform code and no one would care other than me. The downside is the duplication of code surely, well I guess the duplicate code is really already in the plat_nand driver anyway?

If you think it's better to go with the plat_nand driver than I'll go for it, I would be interested in seeing your one if you can send me a copy?

I guess there would be no code duplication really, shame, I was quite proud of the parititoning code :)

Cheers

Alexander Clouter
.sigmonster says: Money cannot buy love, nor even friendship.

I think the TS-7800 series is Marvell 88F5182 based but the TS-7200 series is Cirrus ep93xx based.

There is are already a nand driver for each of these, orion_nand.c and ts7250.c. Both appear to be just variations of the plat_nand.c driver.

Hartley

Hi,

You would have hoped TS would use the NAND silicon already on the Marvell chip, but no they decided to use up FPGA LUT's to re-invent the wheel; although I do think their just pulled over the FPGA bitstream they were using in the TS-7200 series.

Cheers

Alexander Clouter
.sigmonster says: Lonely is a man without love.
                  		-- Englebert Humperdinck