extend physmap.c to support run-time configure and partitioning (take 3)

David,

Since you did not give any preference on how board should pass partition info to physmap, I just picked a reasonable one.

Is this patch now good enough to apply? Thanks.

Jun

diff -Nru linux/arch/mips/mips-boards/malta/malta_setup.c.orig linux/arch/mips/mips-boards/malta/malta_setup.c
@@ -24,6 +24,7 @@
 #ifdef CONFIG_BLK_DEV_IDE
 #include <linux/ide.h>
 #endif
+#include <linux/mtd/physmap.h>
 
 #include <asm/cpu.h>
 #include <asm/bootinfo.h>

@@ -75,6 +76,28 @@
 
 #define STANDARD_IO_RESOURCES (sizeof(standard_io_resources)/sizeof(struct resource))
 
+#if defined(CONFIG_MTD)
+static struct mtd_partition malta_mtd_parts[] __initdata = {
+	{
+		.name = "YAMON",
+		.offset = 0x0,
+		.size = 0x100000,
+		.mask_flags=MTD_WRITEABLE
+	},
+	{
+		.name = "User FS",
+		.offset = 0x100000,
+		.size = 0x2e0000
+	},
+	{
+		.name = "board config",
+		.offset = 0x3e0000,
+		.size = 0x020000,
+		.mask_flags=MTD_WRITEABLE
+	}
+};
+#endif
+
 const char *get_system_type(void)
 {
 	return "MIPS Malta";

@@ -166,6 +189,13 @@
         conswitchp = &dummy_con;
 #endif
 #endif
+
+#if defined(CONFIG_MTD)
+	/* we use generic physmap mapping driver and we use partitions */
+	physmap_configure(0x1e000000, 0x400000, 4, NULL);
+	physmap_set_partitions(malta_mtd_parts, 3);
+#endif
+
 	mips_reboot_setup();
 
 	board_time_init = mips_time_init;

diff -Nru linux/drivers/mtd/maps/Config.in.orig linux/drivers/mtd/maps/Config.in
@@ -8,12 +8,7 @@
 
 bool '  Support for non-linear mappings of flash chips' CONFIG_MTD_COMPLEX_MAPPINGS
 
-dep_tristate '  CFI Flash device in physical memory map' CONFIG_MTD_PHYSMAP $CONFIG_MTD_GEN_PROBE
-if [ "$CONFIG_MTD_PHYSMAP" = "y" -o "$CONFIG_MTD_PHYSMAP" = "m" ]; then
-   hex '    Physical start address of flash mapping' CONFIG_MTD_PHYSMAP_START 0x8000000
-   hex '    Physical length of flash mapping' CONFIG_MTD_PHYSMAP_LEN 0x4000000
-   int '    Bus width in octets' CONFIG_MTD_PHYSMAP_BUSWIDTH 2
-fi
+bool '  CFI Flash device in physical memory map' CONFIG_MTD_PHYSMAP $CONFIG_MTD_GEN_PROBE
 
 if [ "$CONFIG_SPARC" = "y" -o "$CONFIG_SPARC64" = "y" ]; then
    dep_tristate '  Sun Microsystems userflash support' CONFIG_MTD_SUN_UFLASH $CONFIG_MTD_CFI

diff -Nru linux/drivers/mtd/maps/Makefile.orig linux/drivers/mtd/maps/Makefile

Sorry for the lack of response. Been beating up JFFS2 with LTP and it's been, erm, 'interesting'. S'fixed now though :)

I'd still prefer to do it without any static variables in physmap.c.

dwmw2

Hmm, can you be more specific? Here are all static variables that matter in physmap.c. Which ones are you thinking to eliminate? And in what way? (Assuming you do not mean I just drop "static" modifier...)

static struct mtd_info *mymtd;

static struct mtd_partition *mtd_parts;
static int mtd_parts_nb;

static int num_physmap_partitions;
static struct mtd_partition *physmap_partitions;

Jun

I mean mymtd, in particular.

dwmw2

Can you explain how to eliminate that?

All mapping drivers keep a static pointer to remember the mtd info it discovers so that it can free it later. Are you suggesting we get rid of the exit function and we don't free it?

Jun

(This replies to the IRC discussion David and I had:

<jun> around? I am really confued by your comment of eliminating "mymtd" variable. Can you elaborate?
<jun> either we get rid of the exit cleanup function, or somehow we can retrieve this pointer without resorting to the static variable.. <jun> either way the solution is not obvious to me.
<dwmw2> get rid of the exit cleanup function, let the caller do that

)

David,

If I understand you correctly, you essentially want to make physmap_set_map() do what init_physmap() does, and have physmap_unset_map() do what cleanup_physmap() does, right? That would also explain your desire of having

	mtd = physmap_set_map(....)
	...
	physmap_unset_map(mtd)

Well, unfortunately that does _not_ work because run-time configuration should run in the board setup code which is too early for what init_physmap() is doing (for example, such as ioremap() because trap_init() has not run yet).

In order for the whole thing to work, the most obivous solution is to have three steps :

. during board setup time, call run-time configure routine, which remember
arguments in local static variables
. during do_initcalls() time, we do physmap_init() like it is doing right
now,
. during kernel exit time, we clean it up.

Does that make sense? Do you have any more objections to the current patch (take 3)?

Jun