[RFC/PATCH 8/8] LPDDR extended physmap driver to support LPDDR flash.

Lennert Buytenhek buytenh at wantstofly.org
Fri Oct 17 14:01:35 EDT 2008


On Fri, Oct 17, 2008 at 10:27:47AM -0700, Jared Hulbert wrote:

> > IMHO it's fine if physmap gets additional options, but those extra
> > options should be configured via platform data, and not via the legacy
> > CONFIG_MTD_PHYSMAP_xxx kernel config options.
> 
> How?  Maybe I don't understand what you mean by platform data...

There are two ways to instantiate physmap-flash:

1. By setting the legacy CONFIG_MTD_PHYSMAP_xxx kernel config options, eg:

	arch/blackfin/configs/BF537-STAMP_defconfig:CONFIG_MTD_PHYSMAP=m
	arch/blackfin/configs/BF537-STAMP_defconfig:CONFIG_MTD_PHYSMAP_START=0x20000000
	arch/blackfin/configs/BF537-STAMP_defconfig:CONFIG_MTD_PHYSMAP_LEN=0x0
	arch/blackfin/configs/BF537-STAMP_defconfig:CONFIG_MTD_PHYSMAP_BANKWIDTH=2


2. By instantiating a physmap plaform device in your platform code, eg
   arch/arm/mach-iop32x/glantank.c:

	static struct physmap_flash_data glantank_flash_data = {
		.width		= 2,
	};

	static struct resource glantank_flash_resource = {
		.start		= 0xf0000000,
		.end		= 0xf007ffff,
		.flags		= IORESOURCE_MEM,
	};

	static struct platform_device glantank_flash_device = {
		.name		= "physmap-flash",
		.id		= 0,
		.dev		= {
			.platform_data	= &glantank_flash_data,
		},
		.num_resources	= 1,
		.resource	= &glantank_flash_resource,
	};

	platform_device_register(&glantank_flash_device);


(2) is the preferred way, and (1) only still exists because of backward
compatibility.  If we want to add new options to physmap, we shouldn't
introduce new kernel config options but just convert prospective users
over to (2) while we're at it.



More information about the linux-mtd mailing list