Make physmap into a platform device driver...
I'm working on a system where I want to use the physmap driver but the size or buswidth of the flash device might change depending on the specific board layout. I want to be able to build a single kernel that boots on all boards using this NPU (IXP2350) and with the hardcoded approach to buswidth and such, it makes it rather impossible. On ARM platforms, we've been using the following data structure to pass board-specific flash information to the SOC-specific drivers and I am wondering if it makes sense to move it out of ARM into the generic MTD layer and have the physmap driver use it. The physmap driver could register itself as a platform driver for "phys-mtd" devices and boards would just fill in platform_device structure with the appropriate resource window and the needed fields below as the platform_data. We may want to trim down the structure to remove ARM-specific fields and let ARM have it's own structure that contains the generic structure as a member. Thoughts?
~Deepak
/*
* map_name: the map probe function name
* name: flash device name (eg, as used with mtdparts=)
* width: width of mapped device
* init: method called at driver/device initialisation
* exit: method called at driver/device removal
* set_vpp: method called to enable or disable VPP
* mmcontrol: method called to enable or disable Sync. Burst Read in OneNAND
* parts: optional array of mtd_partitions for static partitioning
* nr_parts: number of mtd_partitions for static partitoning
*/
struct flash_platform_data {
const char *map_name;
const char *name;
unsigned int width;
int (*init)(void);
void (*exit)(void);
void (*set_vpp)(int on);
void (*mmcontrol)(struct mtd_info *mtd, int sync_read);
struct mtd_partition *parts;
unsigned int nr_parts;
};Signature · 4 lines
Deepak Saxena - [email protected] - http://www.plexity.net A starving child in Africa or you in front of your TV? Where's the real tragedy?
Quoted 7 lines · Deepak Saxena
MTD layer and have the physmap driver use it. The physmap driver could register itself as a platform driver for "phys-mtd" devices and boards would just fill in
platform_devicestructure with the appropriate resource window and the needed fields below as theplatform_data. We may want to trim down the structure to remove ARM-specific fields and let ARM have it's own structure that contains the generic structure as a member. Thoughts?
An alternative approach (which Jason Gunthorpe posted a patch for recently IIRC) is to add probe support to the plat-ram driver so it can work with any kind of chip. I have a patch kicking around doing pretty much that but also renaming the driver to make it look less strange when used.
My patch is below - it probably ought to have the re-addition of write protection methods which I had stripped out since I've got partially written support for paging in chips and thought the two might end up related.
drivers/mtd/maps/Kconfig +7 -0
@@ -624,5 +624,12 @@ config MTD_PLATRAM This selection automatically selects the map_ram driver. +config MTD_PLATFLASH + tristate "Map driver for platform device physically mapped flash" + depends on MTD + help + Map driver allowing MTD devices which are physically mapped into + the CPU's address space to be enumerated using the platform bus. + endmenu
drivers/mtd/maps/Makefile +1 -0
@@ -69,4 +69,5 @@ obj-$(CONFIG_MTD_WRSBC8260) += wr_sbc82x obj-$(CONFIG_MTD_DMV182) += dmv182.o obj-$(CONFIG_MTD_SHARP_SL) += sharpsl-flash.o obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o +obj-$(CONFIG_MTD_PLATFLASH) += plat-flash.o obj-$(CONFIG_MTD_OMAP_NOR) += omap_nor.o
drivers/mtd/maps/plat-flash.c +270 -0
270 lines not on this page · raw message
include/linux/mtd/plat-flash.h +29 -0
@@ -0,0 +1,29 @@ +/* linux/include/mtd/plat-flash.h +* +* (c) 2004 Simtec Electronics +* http://www.simtec.co.uk/products/SWLINUX/ +* Ben Dooks <[email protected]> +* +* Generic platform device based flash map +* +* $Id: $ +* +* 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. +* +*/ + +#ifndef __LINUX_MTD_PLATFLASH_H +#define __LINUX_MTD_PLATFLASH_H __FILE__ + +struct platdata_mtd_flash { +char *mapname; +char **chip_probes; +char **partition_probes; +struct mtd_partition *partitions; +int nr_partitions; +int bankwidth; +}; + +#endif /* __LINUX_MTD_PLATRAM_H */
Signature · 1 line
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Quoted 16 lines · Deepak Saxena
I'm working on a system where I want to use the physmap driver but the size or buswidth of the flash device might change depending on the specific board layout. I want to be able to build a single kernel that boots on all boards using this NPU (IXP2350) and with the hardcoded approach to buswidth and such, it makes it rather impossible. On ARM platforms, we've been using the following data structure to pass board-specific flash information to the SOC-specific drivers and I am wondering if it makes sense to move it out of ARM into the generic MTD layer and have the physmap driver use it. The physmap driver could register itself as a platform driver for "phys-mtd" devices and boards would just fill in
platform_devicestructure with the appropriate resource window and the needed fields below as theplatform_data. We may want to trim down the structure to remove ARM-specific fields and let ARM have it's own structure that contains the generic structure as a member. Thoughts?
Several people have said they where going to modify the plat-ram driver I wrote a while ago to support flash...
I think a number of the flash drivers currently in the mtd system could be rolled into a generic mtd flash driver
Signature · 3 lines
Ben ([email protected], http://www.fluff.org/) 'a smiley only costs 4 bytes'
[Resent without GPG signature since the list software rejected my mail due to a "suspicious header".]
Quoted 7 lines · Deepak Saxena
MTD layer and have the physmap driver use it. The physmap driver could register itself as a platform driver for "phys-mtd" devices and boards would just fill in
platform_devicestructure with the appropriate resource window and the needed fields below as theplatform_data. We may want to trim down the structure to remove ARM-specific fields and let ARM have it's own structure that contains the generic structure as a member. Thoughts?
An alternative approach (which Jason Gunthorpe posted a patch for recently IIRC) is to add probe support to the plat-ram driver so it can work with any kind of chip. I have a patch kicking around doing pretty much that but also renaming the driver to make it look less strange when used.
My patch is below - it probably ought to have the re-addition of write protection methods which I had stripped out since I've got partially written support for paging in chips and thought the two might end up related.
drivers/mtd/maps/Kconfig +7 -0
@@ -624,5 +624,12 @@ config MTD_PLATRAM This selection automatically selects the map_ram driver. +config MTD_PLATFLASH + tristate "Map driver for platform device physically mapped flash" + depends on MTD + help + Map driver allowing MTD devices which are physically mapped into + the CPU's address space to be enumerated using the platform bus. + endmenu
drivers/mtd/maps/Makefile +1 -0
@@ -69,4 +69,5 @@ obj-$(CONFIG_MTD_WRSBC8260) += wr_sbc82x obj-$(CONFIG_MTD_DMV182) += dmv182.o obj-$(CONFIG_MTD_SHARP_SL) += sharpsl-flash.o obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o +obj-$(CONFIG_MTD_PLATFLASH) += plat-flash.o obj-$(CONFIG_MTD_OMAP_NOR) += omap_nor.o
drivers/mtd/maps/plat-flash.c +270 -0
270 lines not on this page · raw message
include/linux/mtd/plat-flash.h +29 -0
@@ -0,0 +1,29 @@ +/* linux/include/mtd/plat-flash.h +* +* (c) 2004 Simtec Electronics +* http://www.simtec.co.uk/products/SWLINUX/ +* Ben Dooks <[email protected]> +* +* Generic platform device based flash map +* +* $Id: $ +* +* 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. +* +*/ + +#ifndef __LINUX_MTD_PLATFLASH_H +#define __LINUX_MTD_PLATFLASH_H __FILE__ + +struct platdata_mtd_flash { +char *mapname; +char **chip_probes; +char **partition_probes; +struct mtd_partition *partitions; +int nr_partitions; +int bankwidth; +}; + +#endif /* __LINUX_MTD_PLATRAM_H */
Signature · 1 line
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Quoted 4 lines
My patch is below - it probably ought to have the re-addition of write protection methods which I had stripped out since I've got partially written support for paging in chips and thought the two might end up related.
One thing I would like to see is the addition of something like:
<code>
info->map.cached = ioremap_cached(res->start, info->map.size);
dev_dbg(dev, "cached %p, %lu bytes\n", info->map.cached, info->map.size);
if (info->map.cached == NULL) {
dev_err(dev, "failed to ioremap_cached() region\n");
err = -EIO;
goto exit_free;
}</code>
The problem is how do we populate info->map.inval_cache?
drivers/mtd/maps/mainstone-flash.c does it as follows.
<code>
static void mainstone_map_inval_cache(struct map_info *map, unsigned long from,
ssize_t len)
{
consistent_sync((char *)map->cached + from, len, DMA_FROM_DEVICE);
} static struct map_info mainstone_maps[2] = { {
.size = WINDOW_SIZE,
.phys = PXA_CS0_PHYS,
.inval_cache = mainstone_map_inval_cache,
}, {
.size = WINDOW_SIZE,
.phys = PXA_CS1_PHYS,
.inval_cache = mainstone_map_inval_cache,} };
</code>
Is the consistent_sync() and ioremap_cached() generic enough to include in a platflash.c?